Dmitry Serebrennikov wrote:
A quick proposal: perhaps "VM bootstrap" as used below should really
be something like "VM initialization," "VM init," or even "VM
startup", since the word "bootstrap" is very specific and to me at
least, indicates something more akin to the "VM bootloader" + "VM boot
image" (as used below).
That sounds fine with me. It is hard to move outside one's own
(limited) terminology :-). We have "boot()" methods on each of the key
components and a "boot()" method in the vm core which calls these.
That's the origins of my terminology. Init seems reasonable and
disambiguates the role of the bootloader. Probably the original
rationale for using the "boot" word is that there is a higher level of
"bootstrapping" going on here---getting the classloader loaded before
you have a class loader ;-) etc etc. But I agree, "init" may be helpful.
* "OS interface" is perhaps one place where some code can be shared.
If C version can benefit from an OS abstraction layer for portability,
then it seems like this layer could be shared between the C and the
Java implementations.
I agree. It turns out to be a tiny amount of code though (in the case
of Jikes RVM, at least).
* The meat of the VM seems to be in the "spokes" that connect to the
"VM core-hub". It seems that this is where it would make the most
sense to mix components written in C with those written in Java, to
see which one can do a better job. If all spokes were in C, it would
make little sense to have the hub be in Java... On the other hand if
spokes are all Java, it makes little sense to have the hub be in C.
Steve, if the spokes were in Java but the hub in C, would we then lose
all of the aggressive inlining benefits that Java-in-Java solution can
provide?
I don't know. These are really interesting questions and ones I think
we need to hear lots of informed opinion on. My experience with mixing
C & Java inside the VM is limited to the interface to the MM. The
inlining issue is key there because of the fine grain at which those
interactions occur. Scheduling, compilation and classloading are very
much coarser grained, so those issues are much less critical there...
Cheers,
--Steve
