Hi, on the subject of terminology, when you say "scheduling", what do you mean exactly? Are you talking about monitors and other sync issues or are you talking about some kind of m:n thread scheduling? Or neither? :)
Cheers, Dave On 5/24/05, Steve Blackburn <[EMAIL PROTECTED]> wrote: > > 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 >
