GC and static data (Was: Projects)

Mon May 1 16:57:00 GMT 2000

In theory, I think the two uses of SIGSEGV should be compatible. So long as
you install the gcj handler first, things should just work. (I said, "in
theory", ...)
The GC handler has to decode the fault address. If the address is not one
that it protected (i.e. currently if it's not in the heap), it invokes the
prior handler. Presumably the gcj handler should only be invoked if the
fault address is zero, which is guaranteed to never be in the heap.
(In fact, I suspect the fault address decoding may be a little buggy on some
platforms if I can't assume that it was caused by a store instruction. But
that can be fixed.)
I'm not sure whether a compiler enforced write barier is a win in this
context. It would be interesting to try, though.
Hans
-----Original Message-----
From: Tom Tromey [ mailto:tromey@cygnus.com ]
Sent: Monday, May 01, 2000 3:54 PM
To: Boehm, Hans
Cc: 'minyard@acm.org'; Per Bothner; java-discuss@sourceware.cygnus.com
Subject: RE: GC and static data (Was: Projects)
>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:

Hans> What is actually preventing somone from turning on incremental
Hans> GC in the current collector? It seems to me there are three
Hans> likely issues:
Hans> 3) Native code doesn't tolerate the SIGSEGV's used to implement
Hans> the write barrier.
In our case we trap SIGSEGV and turn it into a NullPointerException.
So it seems we would have runtime clash: both libgcj and the GC want
to trap this signal.
Hans> If you use a non-VM write barrier, native code becomes even more
Hans> of an issue, it seems to me.
Our basic plan has been to change both gcj *and* g++ to implement the
write barrier (at least for Java objects). This seems like a
reasonable approach. Perhaps there are difficulties I don't know of.
No one has looked at the problem in a very serious way yet.
Tom