On 02/17/2011 11:17 AM, John Rose wrote:
Here's the way I see the problem of startup: It requires tuning throughout the
stack. The tuning has been done (long ago) at the OS process level, by
allowing applications to be composed from shared libraries, which are compiled
to load quickly. (The OS sometimes helps out by pre-mapping the DLLs.) One of
the key challenges for Java is to embrace the DLL concept. The modularity
initiative is one piece of this, but after modules are defined, we also need
ways to pre-construct code and data in a form which can be quickly loaded and
linked. (As people have pointed out, this is hard because Java initializers
can run arbitrary code. But Lisps have solved this decades ago.) Moving up
the stack, once Java has a better story for tuning, it will be your turn to
think about what forms of pre-construction are helpful to make JRuby start up
faster.
Historical note:
One of the possible advantages of the GCJ approach was that we
constructed the
internal data structures at compile-time, in the data segment. A
problem was
that these data structures were fairly pointer-heavy, requiring lots of
load-time
relocation. This might be OK for staticly linked binaries (no relocation).
I think the Linux "prelink" mechanism may have reduced this problem for
DLLs, and
I think other changes to the data structures were attempted, but if so
it happened
when I was no longer heavily involved.
--
--Per Bothner
[email protected] http://per.bothner.com/
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
