RE: heap fragmentation?

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

Comments in-line, much of Jeff's reply was deleted:

> From: Jeff Sturm [mailto:jsturm@one-point.com]
> 
> More than 90% of that 6MB comes from Java code, of which very little
> actually points to the heap.  We've talked about reducing 
> that before.  I
> wish uninitialized classes in particular weren't scanned at all.
If we can identify what shouldn't be scanned, it should be fairly easy to avoid doing so.  Reducing that number by 5 MB should reduce the heap size by about 7MB, while leaving the time spent in the GC roughly unchanged.
> 
> I'm a little concerned about the policy of automatically expanding the
> heap to manage allocation failure before the GC thinks it is ready for
> another collection.  A great deal of objects allocated are extremely
> short-lived so a collection is always productive, e.g. if 5 
> MB have been
> allocated since the last collection I can usually count on getting at
> least 4 MB back.  For my purposes I would rather spend the cycles to
> reclaim those (if possible) than expand.  I realize that some minimum
> free space should be maintained to prevent thrashing.
I think the right way to deal with this is by adjusting GC_free_space_divisor.  This approach has the decided advantage that the number of bytes you scan per byte of allocation is roughly constant.  Thus the fraction of time you spend in the collector is usually bounded by something reasonable.

There have been proposals to do someething more sophisticated (e.g. the paper by Brecht et al in OOPSLA 2001).  But I don't know of anything that is as robust in the presence of other processes.

If you want to limit the heap to a fixed size, that's also easily possible.  There should probably be better ways to get at some of these hooks from within Java.
> 
> To that end I need fast collections, which is why I'm looking at
> incremental/generational mode.  A problem is that fetching dirty bits
> and scanning root sets currently requires a great deal of the 
> 50ms limit.
Yet another reason to reduce the size of the root set ...
> 
> On Solaris GET_MEM uses calloc() because mmap() confuses the collector
> into blacklisting too much.  We figured that out last year.  Perhaps 
> it could free() unused blocks, not that it would do much good.
That's not really possible with the current setup.  It's also not likely to be useful, since you would have to deallocate the entire calloc'ed block, and it's not likely to be completely empty.
> 
> > Incremental collection generally hurts the memory footprint.
> 
> Well that's just confusing to me... surely smaller, more frequent
> collections ought to help?  If not, why is Sun's VM so space efficient
> (besides compacting of course).
Yes and no.  More frequent collections help.  Letting old garbage hang around because it happened to get promoted doesn't.  Letting allocation continue while you're collecting also doesn't, though that doesn't happen in pure generational mode.  (I added some better support for that recently, which might not yet be in the gcc tree.)

Is HotSpot really that much more efficient in terms of maximum footprint?  Or is the difference that it shrinks the heap when memory requirements decrease?  Aside from the 6MB root set and 64 vs. 32 bit issues, I would expect that we should be competitive in terms of maximum heap size for most apps. 

Hans