JDK-6581734 : CMS Old Gen's collection usage is zero after GC which is incorrect
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 5.0,6,6u2
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2007-07-17
  • Updated: 2022-01-25
  • Resolved: 2011-04-19
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.
Other Other Other JDK 6 JDK 7
1.3-poolResolved 5.0u26-revFixed 5.0u27Fixed 6u21-revFixed 7 b109Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
MemoryPoolMXBean.getCollectionUsage() returns zero but it's expected to be non-zero after GC.

Comments
The current dev workspace has the same issue, FWIW. The "fix" is to simply elide those lines (and the variable collectorsWithTime, its uses and updates entirely).
05-06-2019

I'll check what the test looks like on current production tip and, as appropriate file a ticket. Please let me know what you think. Thanks!
04-06-2019

I believe there is a small error in the test here: if (collectorsWithTime<collectorsFound) { throw new RuntimeException("collectors found with zero time"); } Since the collectorsWithTime variable accumulates time with resolution of 1 ms, if the only collection associated with a collector occurs in less time than 1 ms, then the boolean test will succeed and the test will fail with the exception message "collectors found with zero time". I recently ran into this issue when testing with a JDK 11 build on a modern machine. Since the test is fragile, I think this check should be elided since machines will continue to get faster no matter how much load you try to place on GC to cause the value to exceed 1 ms in the test today.
04-06-2019

EVALUATION http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/1339e02bc576
22-04-2011

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f6f3eef8a521
31-07-2010

EVALUATION MemoryService::gc_end(bool fullGC) calls a GCMemoryManager's gc_end() method, using "fullGC" to choose either its _major_gc_manager or _minor_gc_manager. CMS is the _major_gc_manager, but fullGC isn't true when it is invoked. "Full collection" probably means stop the world, not old gen, but the meaning is mixed up. At this point we need to know which generations have been collected rather than saying "full collection".
12-08-2009