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