testsuite problems on darwin was: [patch] HAVE_LC_MESSAGES f ornatSystem.cc

Wed Jan 23 12:17:00 GMT 2002

I'm not sure that importing this is a major issue. This isn't relevant
unless you turn on incremental GC. (Getting rid of the wrapper does speed
things up a bit, but that's probably minor.) My impression is that
incremental GC is basically not being used, in part because it's very hard
to do so. If you do use it now, the current read wrapper is a problem, in
that it holds the GC lock during a potentially blocking read. Thus I'm not
at all sure this risks breaking anything that isn't already both
undocumented and broken.
The plan was to 
1) Only turn on incremental GC if things like primitive arrays can be
allocated as pointerfree objects. (Currently there is no official way to
turn it on at all, I believe. My current tree lets you turn it on with an
environment variable, but that will never be the right way to turn it on for
gcj.)
2) Only read into pointerfree chunks of the heap, such as primitve arrays.
Hans
> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Wednesday, January 23, 2002 11:49 AM
> To: Boehm, Hans
> Cc: 'Jeff Sturm'; Andreas Tobler; Stan Shebs; GCC-Java
> Subject: Re: testsuite problems on darwin was: [patch] 
> HAVE_LC_MESSAGES
> f ornatSystem.cc
>>> >>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:
>> Hans> It seemed to be causing more harm than good. I believe the plan
> Hans> for gcj is to no longer protect pointer-free pages when it can
> Hans> be avoided, to enable incremental GC only if it can be avoided,
> Hans> and to avoid making system calls from libgcj that write to the
> Hans> pointer-containing heap. The interface to support that is in
> Hans> the latest GC alpha releases. In this was gcj should never need
> Hans> the wrappers.
>> Does this mean libgcj will have to make calls like GC_read() or
> something like that? Or that we'll somehow only read into
> non-protected parts of the heap?
>> Anyway, I think we should hold off on importing this until after the
> 3.1 branch is made. That is due Feb 15, I think, so it isn't a long
> wait.
>> Tom
>