[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: incremental linking
<---- MLj users ---- http://www.dcs.ed.ac.uk/home/mlj/doc/users.html ---->
Ian Stark writes:
> One problem with recompiling from scratch in MLj is that the
> post-link optimisation takes such a long time - and as Andrew points
> out, pickling intermediate information won't help this too much.
> This is because there is some genuinely hard work going on to get
> reasonable code size and execution time.
I appreciate this and want to keep it. As I wrote in my reply to
Andrew, I want the post-link optimisation, but I want to make it
incremental; ie
- link the first entity and optimize and emit a jarfile of any
instanciated code,
- link the next entity and optimize the added code and emit any
addtional instanciated code.
This depends on being able to make optimization and classfile
generation incremental. If linking in a new entity requires
re-optimizing the whole expression, then incremental linking is no
good. But if the post-link optimisation can be done like a
merge sort things would be great.
> However, for development work optimisation isn't as important, so
> perhaps one could sort out a switch to adjust between doing poor
> compilation quickly, and decent compilation slowly. Would this
> help?
This would help, but it would not address the fact that recompilation
from scratch negates a major strength of JVM -- dynamic linking.
With the batch compiler one is limited to dynamic linking through
Java interfaces. This is clumsy and inhibits optimization.
> (I'm going to regret this, as Andrew Kennedy will now tell me
> just how bad poor compilation would be.)
The O'Caml "word code" compiler & interpreter are a good comprimise
between fast compilation and fast execution. Perhaps a non-
standard VM using a uniform representation (put the tag bits
in a header or use a conservative collector) would be what is
desired for development work. This would avoid the need to
incrementalize the optimizer and the JVM backend for developement
work.
-David Gurr