On Tue, Nov 29, 2011 at 4:34 PM, Thomas Wuerthinger <thomas.wuerthin...@oracle.com> wrote: > What kind of initialization work is this? Could the result of that work > be cached?
I can describe the work done in JRuby's boot. We have managed to get JRuby's basic runtime to start up pretty fast; about 0.3 to 0.5s on my high-end MBP. However on other systems, especially on 64-bit Linux, startup time is still quite a bit slower. The Apple JDK does an amazing job of speeding startup that no other builds seem to have matched yet. JRuby's base init involves: * Constructing metaclasses for all the core Ruby classes like String, Array, etc. It's difficult or impossible to cache this because they are essentially key/value tables of pointers to methods...in our case, thousands of tiny classes that subclass DynamicMethod. * Initializing native bindings for POSIX features. Loading the libffi binding dynamically and programmatically wiring up all the functions we use takes a bit of startup time. * Loading additional .rb sources from classloader resources. Parts of JRuby (more and more) are implemented in Ruby; as a result, we have to load a bunch of Ruby code on boot. The bigger part of startup is loading all the third-party libraries that a user might need in their app. Those sources need to be parsed every time, turned into an AST, and partially executed to boot. All the code that does parsing and interpretation is cold initially, and so we have slow startup no matter what we do. We have experimented with serializing the parse tree or precompiling to bytecode, but neither case was actually faster than our parser. If the JVM had the ability to fork, users could potentially boot a baseline application image and then fork instances from that to run iterative tests, etc, rather than having to re-boot the entire runtime and application's dependencies every time. I'm also looking into the possibility of doing this on Dalvik; we could keep a running JRuby image in memory and then fork off that for JRuby-based applications, reducing startup time significantly. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
