On Feb 17, 2011, at 10:46 AM, Charles Oliver Nutter wrote: > FWIW, I'm interested in any and all tech for improving startup of > JVM-based stuff. Current Hotspot simply does not start fast enough to > be used for command-line utilities, even though it has been improved. > It's not because of the boot-time stuff anymore, but now cold > performance comes into play. For commands that only run for a couple > seconds, running cold (at many times slower than hot) just isn't > acceptable. > > fork is one way to address that, by keeping a "hot" VM and spawning > instances of it, but JVMs that save their jit products (like Excelsior > JET) do an excellent job too (once primed. JET starts up JRuby stuff > *much* faster than Hotspot).
That is a good data point. 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. -- John -- 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.
