This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: heap fragmentation?
- From: Jeff Sturm <jsturm at one-point dot com>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: java at gcc dot gnu dot org, boehm at acm dot org
- Date: Wed, 5 Jun 2002 21:05:01 -0400 (EDT)
- Subject: RE: heap fragmentation?
On Wed, 5 Jun 2002, Boehm, Hans wrote:
> 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.
.eh_frame isn't needed in the root set. That takes care of ~1MB.
Uninitialized classes shouldn't be scanned. That'll be much of the rest
of the data segment. It's not clear what the easiest/best way to go about
that is. If, for example, we could arrange for no class objects to be in
the root set, then we could hook into GC_push_other_roots() to walk the
initialized classes and push their static members.
> Is HotSpot really that much more efficient in terms of maximum
> footprint?
I haven't compared to Hotspot. Sun's ExactVM has a precise, copying
collector too. If I enable hash synchronization and download the new
64-bit Hotspot VM I'll have a better basis for comparison.
> Or is the difference that it shrinks the heap when memory
> requirements decrease?
If so, I don't know what conditions trigger it. Here's a log excerpt from
a long-running application that is currently idle:
Jun 05 20:46:38 web-app1 INFO: total VM memory: 356253696
Jun 05 20:46:38 web-app1 INFO: avail VM memory: 151306560
No evidence of shrinkage there.
Perhaps I should look at getting USE_MUNMAP working. I'm suspecting it
would win vs. carving out a static-sized heap for each VM.
Jeff