On Thu, Feb 17, 2011 at 9:51 AM, Jochen Theodorou <[email protected]> wrote: > you mean only for the rt.jar and maybe other internal jars. > > So it is not usable for us language guys... For many languages it would be > very good to be able to make some kind of root image that can be used. > Basically that is what the fork for the JVM is intending to do as well. > Something like that is really badly needed I think
Saving an image would certainly help startup in many cases, but in general what we're seeing in JRuby is that startup time is now governed largely by cold code performance rather than code-loading performance. JRuby's default command-line loads the jruby.jar and related jars all into the boot classloader, skipping verification. That trims off a good 1s to 0.5s on OS X, and more than that on other platforms. But the startup of a typical Rails app is still anywhere from 10-15 seconds. This is largely due to the parser being cold (parsing a lot of code on startup) and other logic in JRuby being cold (method defining logic, interpreter, etc). So image-saving in the form of class data sharing would help some things, but not all...and possibly not the areas that most impact JRuby startup time. A JVM-level "fork" on the other hand could be used to re-launch a new JVM that's already loaded, initialized, *and hot*, avoiding all startup-time problems we currently face. It would also allow application-specific boot logic to be done once and reused by several child instances. I'm all for getting the JVM to save more boot-time metadata (all the way up to last run's jitted code) or potentially full executing images, but my current interest is understanding how forking could be supported in current JVMs. - Charlie -- 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.
