There is support to JNI launch the VM in process with something else. Might you be able to do something with that? As for caching compiled classes, isn't this like what Davlik and GIJ do?
I remember the harmony guys talked about doing "ahead of time" caching of JIT'd classes. It doesn't appear to have been implemented, but if you did a combination of: 1. a c wrapper to launch JVMs 2. a jni hook 3. serialized class state 4. JIT caching You could probably do something sick and wrong. Granted it would be specific to a JVM implementation. -Andy On Thu, Feb 17, 2011 at 11:18 AM, Charles Oliver Nutter <[email protected]> wrote: > 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. > > -- 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.
