harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo Kumpera <kump...@gmail.com>
Subject Re: GC Compatibility (was: Re: State of the World)
Date Mon, 09 May 2005 21:09:02 GMT
On 5/9/05, Steven Augart <saugart@yahoo.com> wrote:
> --- 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.

There are way more issues than just the GC, what about
synchronization, for example?

It must export a hook to the runtime executive to manage object
synchonization so mixed code can work, doesn't seen to be hard (if
it's not already implemented) but forbit advanced optimizations like
inlining the synchronization code (ORP does that, I believe).

The best way would be to have a full java binary ABI, but this is no
simple task.

View raw message