JDK-8033440 : jmap reports unexpected used/free size of concurrent mark-sweep generation
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25,8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-02-03
  • Updated: 2015-09-29
  • Resolved: 2014-02-20
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 8 JDK 9
8u60Fixed 9 b04Fixed
Description
[2014-01-29T11:25:46.26] concurrent mark-sweep generation:
[2014-01-29T11:25:46.26]    capacity = 32243712 (30.75MB)
[2014-01-29T11:25:46.26]    used     = 12317382499127 MB
[2014-01-29T11:25:46.26]    free     = 5531032402336477368 (5.274803545319059E12MB)
[2014-01-29T11:25:46.26]    -1.7153832667604256E13% used
Comments
The fix applies clean, so I will do the backport to jdk8u/hs-dev.
12-02-2015
Can we backport this to 8u, please? We have external users that are affected by this.
11-02-2015
ILW => LHH => P4 Impact: Low, you get the wrong value when using jmap. Likelihood: High, running with CMS you will get this Workaround: High, no other workaround than using a different collector.
04-02-2014
The problem seem to be that the SA (used by jmap) expects the _indexedFreeList field in CompactibleFreeListSpace to be of type FreeList<FreeChunk> but in JDK8 it is an AdaptiveFreeList<FreeChunk>. When the SA tries to calculate how much free memory there is, the size of FreeList<FreeChunk> is used to offset to the next entry, but this offset is not correct and the size calculation will be incorrect.
04-02-2014
Is it reproducible with the latest 8 build?
03-02-2014