RE: Looking for ideas to fix X server crash running GCJ-compiled program

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

> From: Scott Gilbertson [mailto:scottg at mantatest dot com]
> 
> Hans> 1) You should be able to set GC_free_space_divisor to a 
> large number
> instead of fixing
> Hans>  the heap size.
> 
> That's an interesting approach.  I tried 10, which results in really
> frequent collection under heavy "garbage load", and a maximum 
> heap size
> under six megs.  Unfortunately, each collection takes 
> 200-300ms, which is
> kind of annoying.  For snappy response, I'd think incremental 
> GC was the way
> to go, but when I tried that the application didn't work at 
> all. I also
> found that this setting increased the startup time of my 
> application, but I
> suspect I could run with one set of GC settings during startup (using
> System.gc() to keep the heap reasonable) and another once startup is
> complete.
You might want to combine that with a larger initial heap size (e.g. 8MB) to avoid the frequent GCs on startup.  Setting the maximum heap size is normally a bit drastic, though perhaps not with a hard memory limit as in your case.

I don't think all the support needed for incremental GC is in the tree.  Currently it requires some custom tweaking to get it to work.
> 
> Hans> If you are running in a workstation environment, this 
> is likely to be
> more robust.
> 
> It's an embedded system with 128M RAM but no swap.
> 
> Hans> 2) Setting GC_max_retries to essentially infinite will 
> essentially
> force the collector into an infinite
> Hans> GC loop when it runs out of memory.  That's usually not 
> desirable.
> 
> The only alternative (using a max heap limit), as far as I 
> can tell,  is to
> let the application crash if a few tries doesn't get the free 
> space high
> enough.  That's not desirable either. I tried a small number 
> (5, I think)
> and it wasn't enough -- the app crashed on "out of memory".
That's surprising to me.  The problem may be that GC_fail_count gets reset only if you successfully allocate a large (page-sized) chunk.  If it never encounters completely empty pages, it never gets reset.  I just changed that in my version.  Were you allocating exclusively small objects?

Hans