harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <Robin.Gar...@anu.edu.au>
Subject Re: [arch] Modular JVM component diagram
Date Fri, 23 Sep 2005 09:27:39 GMT
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.

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.  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 ?
- It's not explicitly specified in the API, but I assume gc_alloc_fast 
is inlined (or is a macro) ?
- Doesn't supporting gc_pin_object restrict the GC implementation 
significantly ?
- I was under the impression ORP doesn't yet support weak references or 
finalizers.  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 ?

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.


View raw message