RE: gc problem?

["Boehm, Hans" <hans_boehm at hp dot com>]

It's not terribly significant.  It means that the test tried to allocate a
large array, and there wasn't any space in the heap that was large enough
for it, and didn't have known false pointers somewhere into it.  Thus
there's some danger that the array won't be reclaimed.  (Given that this is
X86, and the collector is built to only recognize interior pointers from the
stack, I would guess this danger is actually small, or at least the danger
of retaining a growing number of copies if you ran the benchmark repeatedly
would be small.)

It's easy to "fix" this by turning off warnings.  Anything else is much
harder:

1) (Hard, though might happen anyway when the compiler is taught about
GC-safety.) Teach the compiler that it needs to keep pointers to the
beginning of potentially large arrays, and then allocate them with the
ignore_off_page functions, or

2) (Harder, may not ever happen.) Teach the compiler to generate descriptors
for the stack layout, and the collector to interpret them, so that we can
scan the stack (mostly) nonconservatively.

I expect that either of those should fix the problem.

There are probably also other ways to reduce the probability of this by
minimizing the amount of scanned garbage on the stack.

Tom and I had this discussion before.  I thought the test suite ignored such
warnings?

Hans

> -----Original Message-----
> From: Anthony Green [mailto:green@redhat.com]
> Sent: Tuesday, October 23, 2001 5:41 PM
> To: Java@Gcc. Gnu. Org
> Subject: gc problem?
> 
> 
> `make check' on the trunk results in messages like...
> 
> Needed to allocate blacklisted block at 0x80dc000
> 
> ..while running Primes.java on x86 Linux.  What does this mean?
> 
> AG
> 
>