RE: incremental linking

[gurr@pop.mrs.med.ge.com (David Gurr)]

<---- 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