RE: Can boehm-gc be made to finalize more promptly?

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

Is it acceptable to run the garbage collector frequently enough so tha the finalizers run promptly?  Once the collector has run, finalizers should run shortly thereafter.  (If they don't, that's a bug, and probably easily fixable.)  The issue is really GC frequency.

If this sounds plausible, we would need something to at least inform the collector of how much finalization-dependent memory has been allocated with system malloc, so that it can adjust the GC-triggering heuristic correspondingly.  Is it possible to guess about how much memory those xlib calls allocate?  Or to redirect them through the GC?  (I believe the relevant GC hook isn't quite there, but wouldn't be difficult to add.  And it's on my list anyway.)

Explicitly deallocating xlib memory sounds cheaper, but ugly.

Hans

-----Original Message-----
From: Scott Gilbertson
To: java@gcc.gnu.org
Sent: 1/15/03 6:26 PM
Subject: Can boehm-gc be made to finalize more promptly?

Further to my "Out of Memory" crash post, I'm now pretty sure I know, in
general terms, why my program is crashing.

It seems like the fundamental problem is that the native xlib code
allocates
a lot of memory, and the associated java objects don't get finalized
right
away.  That's presumably because the java parts of those objects are
small,
so the garbage collector is in no great hurry to clear them off
(particularly if several of them are in the same memory page, and only
some
are collectable).  The total memory used by the program therefore grows
quickly, while the garbage collector thinks it's growing slowly.  The
garbage collector thinks there's lots of memory left, right up to the
point
where the memory runs out.

For example, every time an awt component gets a paint event, it calls
getGraphics on the nearest heavyweight.  That function ultimately calls
XCanvasPeer.getGraphics, which creates, among other things, a new
XGraphics.
Somewhere in there, a new gnu.gcj.xlib.GC is created.  The associated
native
library (natGC.cc) calls XCreateGC (which allocates some memory) when a
GC
is constructed, and XFreeGC when the GC is finalized.  I instrumented
the
constructor and finalize for xlib.GC, and did a whole bunch of repaints
in
my program.  The program crashed, having constructed 97 GC objects and
having finalized none of them, even though each one was no longer needed
once its paint event was finished.  Calling System.gc very frequently
prevents the crash, but it makes the program unusably slow.

Is there a way to get the GC to finalize "small" java objects which have
large natively-allocated blocks more promptly?

How about a way to code the xlib native stuff which helps the garbage
collector to tell when too much memory is in use?

Perhaps we could do gfx.finalize at the end of
java.awt.Component.processPaintEvent, and write the finalizers so each
class
calls finalize for every object it has constructed or cloned (i.e. make
them
look kind of like C++ destructors).  This way all the natively-allocated
stuff would be deallocated each time we finish processPaintEvent.  The
java
part would hang around on the heap until the garbage collector found it.
We'd only do this for things like xlib that have the potential to
allocate a
lot of memory from native code.  Comments on that?