Garbage collector problem ???

[Boehm, Hans]

This sounds like a combination of 2 problems, one of which is easy to fix.
With luck, fixing that one will give you acceptable results.

1) (easy) I believe the gcj version of the collector normally uses the
default "medium" configuration (except in a cross-compiled environment,
where it uses SMALL_CONFIG).  Performance in the medium configuration starts
to degrade around 64MB heaps.  In particular, heap blocks get spuriously
blacklisted because you start getting collisions in the simple bit-per-page
hash table that tracks these things.  (A bit in the table is set if any of
the pages that maps to it is black-listed.)  The workaround here is to build
the collector with -DLARGE_CONFIG.  I'll increase the parameter values in
the 6.0 collector version to keep up with the times.  (My guess is the
default configuration should be good for 256MB, which is currently slightly
less than the LARGE_CONFIG (soft) limit.  This means the hash tables, of
which there are about 4 allocated,  will grow to 8KB each.  Most of that is
not touched for small heaps.  I'll leave SMALL_CONFIG roughly where it is
now.  I might also look at dynamically sizing these things.)

2) (hard) There is an inherent problem with allocating very large arrays.  I
think this can really only be addressed with the garbage-collector-safety
issue in the compiler.  (If this indeed is an issue that you need to
address, an ugly and expensive source-level workaround would be to break
large one-dimensional arrays up into a 2-dimensional array, which is
currently allocated in multiple chunks.  That's probably a last resort.)

Details for (2):

Since the collector always recognizes interior pointers from at least the
stack, very large arrays have a large probability of being referenced by a
false pointer.  The collector keeps track of pages that are known to have
false pointers into them (using the hash tables from (1)).  Thus it usually
notices when it can't find a large enough "hole" between these false
references to place the array, and issues the warnings you see.

The alternative is to allocate these arrays such that pointers to the
interior are ignored (with something like GC_malloc_ignore_off_page).  This
allows them to be allocated in regions with known false pointer references,
so long as the false pointers don't reference the beginning of the object.
That would be safe for Java arrays if we knew that the compiler always kept
a pointer to the array itself while the array could still be dereferenced.
It should really do that anyway for reasons I mentioned in an earlier
message.  I believe currently the front end ensures that, but not in a way
that ensures the back end will preserve the property.

Thus it's easy to change libgcj to avoid the problem.  But until the
compiler really does the right thing, I'm concerned that this may provoke
other failures, and I'd be more comfortable keeping it the way it is, at
least in the official distribution.  (If you want to try this in your
version, I can tell you what needs to be changed.)

Hans


> -----Original Message-----
> From: balrog@amena.com [ mailto:balrog@amena.com ]
> Sent: Friday, January 19, 2001 5:52 AM
> To: Lista Discusión GCJ
> Subject: Garbage collector problem ???
> 
> 
> Hi,
> 
>   Recently I have run on what I think it's a garbage collector
> problem...
> 
> 
>  When I simulate small Fluid Dynamics problems (about 64 Mb) 
> everything
> is Ok. But when I face huge problems (>256 Mb) I got a lot of ...
> 
> "Needed to allocate blacklisted block at <address>"
> 
>  ... messages. It seems to work... but the RAM required by the program
> grows slowly until it fills de RAM.
> 
>  No -50% RAM benefit there, :,,(. But it keeps going really fast!
> 
>  Anyone can help me? By the way, I run a SuSE Linux v7.0, GCJ 
> version is
> 2.95.2 .
> 
> 
>  Thank you ---
> 
> ---------------------------------------------------
> Alejandro Rodríguez Gallego <balrog@amena.com>
>