While I was downloading 1.4.1 yesterday, Greg Vaughn was reading the release notes and IMing me about them:
Known issues: no incremental gc :-(
What about concurrent?
It doesn’t say
That’s OK, really … incremental GC had serious problems in 1.3, and they weren’t fixed for 1.4; instead, nearly all of the GC work went into the concurrent collector, which arrived with Sun’s 1.4.1.
But I started wondering about the concurrent collector. It occurred to me that I could probably tell whether the concurrent collector was included by turning on verbose GC output and watching.
First, I ran the SwingSet2 demo with the default collector. I saw what I expected: lots of young generation collections, with full heap collections occurring just under 10% of the time. Then I tried -Xincgc, and saw the same behavior; the release notes were telling the truth about the incremental collector.
With the -Xconcgc option, I saw very different behavior. In some cases I’ve seen up to 500 young collections before any attempt is made at a full sweep. Looks like the concurrent collector is there.
But there’s a race condition. On 3 out of 4 runs, roughly, when it did finally attempt a full GC, I saw this:
[GC 14014K->14001K(58108K), 0.0069902 secs] [GC 13975K->13975K(58944K), 0.0093674 secs] [Full GC[Unloading class sun.reflect.GeneratedMethodAccessor4] [Unloading class sun.reflect.GeneratedMethodAccessor3] # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://bugreport.apple.com/ # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-14 mixed mode) # # ShouldNotReachHere() # # Error happened during: generation collection for allocation # # Error ID: /SourceCache/HotSpot14/HotSpot14-14/src/share/vm/memory/generation.hpp, 346 # # Problematic Thread: prio=3 tid=0x0fd9ecf0 nid=0xedc8c70 waiting on condition # Abort trap