On Fri, Jun 10, 2011 at 2:45 PM, BGB <cr88...@gmail.com> wrote: > just had an idle thought of a JVM starting up as a prebuilt "image" (say, > methods are pre-JIT'ed and pre-linked, static fields are pre-initialized, > ...). > unless of course, they already started doing this (sadly, I am not much an > expert on the JVM).
Yes, they do this already; but this was part of the startup-time optimizations which weren't initially present in the JVM. > or, maybe it is that, within the class library, most classes are tangled up > with many other classes, essentially turning the class library into some > large bulk-loaded glob?... Yes, that was a large part of the initial problem. A particular culprit was the String class, which wanted to have lots of convenient hooks for different features (including locale-specific stuff like uppercase/lowercase & sorting, regexs, etc) but that tangled it up with everything else. The basic JVM bytecode demanded intern'ed strings, which required String class initialization, which then required on-the-fly locale loaded based on environment variables (removing the ability to precompile and image), and things went rapidly downhill from there. > a sad result of this is that using executable statements/expressions in the > toplevel, it is possible to fetch 'null' from slots prior to them being > initialized, creating ordering issues in some cases. Yes, this was another fundamental problem with the JVM. You needed intimate knowledge of the library implementation in order to do initial class initialization in the proper order to avoid crashes. --scott -- ( http://cscott.net ) _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
