harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Weldon Washburn <weldon...@gmail.com>
Subject Re: [arch] Modular JVM component diagram
Date Sat, 24 Sep 2005 16:31:45 GMT
On 9/23/05, Robin Garner <Robin.Garner@anu.edu.au> wrote:
> Weldon Washburn wrote:
>
> > Everyone,
> > I just posted the basics of the GC/VM interface to
> > http://wiki.apache.org/harmony/HarmonyArchitecture.  The VM calls into
> > the GC using gc_interface.txt.  The GC calls into the VM using
> > vm_gc_interface.txt.
> >   Weldon
> >
> >
> Thanks Weldon, it makes very interesting reading.  I've posted a
> description of MMTk's VM interface on my web page,
> http://cs.anu.edu.au/people/Robin.Garner/, for comparison.  This is the
> GC -> VM interface.

Great!  Its good you are documenting MMTk interface.  I will take a
look at it soon.  Please think of the interfaces that I posted as a
starting point.  Also, don't feel shy about ripping apart the
interfaces I have posted.  The whole point is to quickly evolve
Harmony into something more sophisticated than the existing JVMs.

>
> As described in my thesis (although if you want to read it, remember it
> is now nearly 2 years out of date, and MMTk has moved on - link is also
> on my ANU web page), we follow a "wedge" model of the interface, rather
> than specifying a simple flat API.  So while JikesRVM (and Rotor and
> JNode) have a definite API that they code to, there is a package that
> translates this to fit the services MMTk offers.  And that's a large
> set, not yet documented (beyond source and javadoc in any case).
>
> I'm going to look more closely at the interface you've posted, and will
> probably have more questions in a short while, but my first
> impressions/questions are:
> - The interface seems tightly coupled to ORP and Sapphire.

Sapphire has been backed out of the source base.  As far as I know,
the GC interface I posted has not been used any place but ORP and its
follow-ons.

>  For example,
> since there aren't any API calls to do it, I presume the GC knows how
> the object header is laid out ?  And knows about something called a
> vtable ?
True and true.

> - It's not explicitly specified in the API, but I assume gc_alloc_fast
> is inlined (or is a macro) ?
gc_alloc_fast is intended to be inlined.

> - Doesn't supporting gc_pin_object restrict the GC implementation
> significantly ?
This might have been one of the APIs left over from when we extended
ORP to run ECMA CLI (.net).  I might have forgotten to remove it.

> - I was under the impression ORP doesn't yet support weak references or
> finalizers.
Stay tuned for more info.

> There appears to be support for the GC to tell the VM about
> reference types, but not the other way round.  Is this right ?  Or is
> this the gc_add_weak_root_set_entry call ?
> - How does the VM enumerate the thread stacks ?  Is this the
> gc_add_root_set_entry call ?
I will have to take a look and get back to you.

>
> Do you have any documentation specifying what else the GC talks to ?
> I'm assuming that for its own synchronization, interfacing with the OS
> (mmap etc) it talks directly with the OS, glibc etc.

Yes.  I have been waiting to see what response I get to what's already
posted before posting more stuff.

>
> Cheers,
> Robin
>
>


--
Weldon Washburn
Intel Managed Runtime Division

Mime
View raw message