harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Griffiths <david.griffi...@gmail.com>
Subject Re: Terminology etc
Date Tue, 24 May 2005 09:31:39 GMT
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? :)



On 5/24/05, Steve Blackburn <Steve.Blackburn@anu.edu.au> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message