On 6/10/2011 12:17 PM, C. Scott Ananian wrote:
On Fri, Jun 10, 2011 at 2:45 PM, BGB<[email protected]> 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.
yes, ok.
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.
I noted this before...
in constrast, my VM has strings as a built-in type, partly due to some
of the nastiness I had observed in the JVM, and partly because having
them as a built-in types allowed a more efficient implementation (I
store strings directly into in-memory globs of characters, rather than
needing instances and arrays, which would eat a fair number of
additional bytes per-string...).
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.
yeah, sadly, it is also an issue in my VM, with no real good/obvious fix.
granted... one could just be like "ok, don't use any executable
expressions outside function/method scope" (possibly making the compiler
complain, basically, like in C and C++) but this is overly limiting.
the least effort route has been to allow this, at the cost that code
will have to pay attention to any initialization-order dependencies.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
