harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Augart <saug...@yahoo.com>
Subject GC Compatibility (was: Re: State of the World)
Date Mon, 09 May 2005 20:08:43 GMT

--- Tom Tromey <tromey@redhat.com> wrote:
> * Fragmentation.  I think there are too many free JVMs. 

Amen to that.  I hate to say it, since my own favorite VM is one of the
ones keeping that space big.  But a "state of the art" optimizing
compiler stops being "state of the art" when the art progresses without
hte optimizing compiler getting upgraded too.

>   It ought to be possible,
>   though difficult, to write a configurable core VM that can be reused
>   by other projects.  The idea here is, have a reusable reference
>   implementation, and reduce writing a VM to writing an execution
>   engine (and perhaps a GC).

This idea sounds really cool in the abstract.  I have difficulty
understanding what it would really mean in the specifics, though.

I'd like to take off on a tangent here.  At one point I had the naive
idea that I could make Jikes RVM able to play nicely with GCJ.  What
really quashed the idea was the issue of garbage collection -- GCC is not
designed to pass type information down to the lower levels of the
compiler, so GCJ doesn't build a "gc map", which you need in order to be
use any GC other than a Boehm-style conservative non-copying collector. 
In other words, GCJ is restricted to using a garbage collection that
looks for any bit patterns in the data that might be pointers, and it has
to assume that all of them are pointers.  If I am mis-stating the
problem, I would appreciate someone publicly correcting me. 

Further, I've heard (have not looked at it myself, nor am I competent to
do so) that it would be an enormous amount of work to retrofit GCC so
that GCJ could build GC maps.

Still, though, I would very very much like to have Jikes RVM able to link
with stuff made by an ahead-of-time compiler like GCJ.  

So, GC compatibility is a serious issue here.  For instance, if I pass
any reference to an object from Jikes RVM's code into GCJ's code, right
now I would have to assume that that object is forever afterwards
immovable.  Perhaps there's some way that we could have the two types of
GC talk to each other, and stay in their own separate spaces?  Jikes RVM
would have to pin down any object it passed into GCJ land, but then
perhaps it could tell the GCJ garbage collector something like "I have
pinned down the object at this address for your sake.  Please tell me
once you no longer have any references to it."  GCJ's garbage collector
would have a much easier job, since it could just go ahead and use its
conservative "examine every piece of data" algorithm on the Jikes RVM
heap and stack as well as on its own.

Does this make sense, or am I off the wall here?  Criticisms welcomed.

--Steve Augart

Jikes RVM: A free, open source, Virtual Machine

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

View raw message