JDK-6396794 : REGRESSION: Contents of GarbageCollectorMXBean's LastGcInfo attribute are incorrect
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-03-10
  • Updated: 2017-05-16
  • Resolved: 2006-04-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b79Fixed
Related Reports
Relates :  
Relates :  
Description
Since the java.lang.management MXBeans have been switched over to using the generic MXBean framework, a problem has come to light with the GarbageCollectorMXBean.  This MXBean has a Hotspot-specific extension that defines an attribute "LastGcInfo" of type GcInfo.  The GcInfo class implements CompositeData, and the Tiger MXBean framework used to interpret this as meaning that it should be mapped into itself (as a CompositeData).  Hotspot added additional fields to the CompositeData in question, reflecting gc-type-specific information.

The Mustang MXBean framework does not have a special case for a class implementing CompositeData, because it defines the OpenType of all mapped types, and it would not be apparent what the OpenType for GcInfo would be.  Therefore it translates GcInfo naively, not including the extra fields that were present in Tiger, but erroneously including a field called "compositeType" implied by the method CompositeData.getCompositeType().

The attached test program shows the difference in behaviour.  In Tiger, the output begins like this:

CompositeType {
    GcThreadCount: javax.management.openmbean.SimpleType(name=java.lang.Integer)
    endTime: javax.management.openmbean.SimpleType(name=java.lang.Long)
    id: javax.management.openmbean.SimpleType(name=java.lang.Long)
    memoryUsageAfterGc: TabularType[key]: CompositeType {

In Mustang, it begins like this:

CompositeType {
    compositeType: CompositeType {
        array: javax.management.openmbean.SimpleType(name=java.lang.Boolean)
        className: javax.management.openmbean.SimpleType(name=java.lang.String)
        description: javax.management.openmbean.SimpleType(name=java.lang.String)
        typeName: javax.management.openmbean.SimpleType(name=java.lang.String)
    }
    duration: javax.management.openmbean.SimpleType(name=java.lang.Long)
    endTime: javax.management.openmbean.SimpleType(name=java.lang.Long)
    id: javax.management.openmbean.SimpleType(name=java.lang.Long)
    memoryUsageAfterGc: TabularType[key]: CompositeType {

Notice that the GcThreadCount field has disappeared, whereas a bogus "compositeType" field has appeared.  (Also the "duration" field which was specified in Tiger was not actually present there, which is a bug, though an unimportant once since the value is redundantly equal to endTime - startTime.)

Comments
EVALUATION The fix should proceed as follows. We make GcInfo implement CompositeDataView so that it can return its custom CompositeData value with the extra fields. We add a hack to the MXBean framework to recognize the GcInfo class and remove its bogus "compositeType" field. Ideally, we implement RFE 5072004 so that the values returned by GcInfo are conformant with the declared CompositeType despite their extra fields.
10-03-2006