JDK-8059837 : G1 may not tenure objects after MaxTenuringThreshold young GCs
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P1
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2014-10-07
  • Updated: 2015-04-03
  • Resolved: 2014-12-05
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 9
9Resolved
Related Reports
Duplicate :  
Description
While working on JDK-8037968 I've faced with following issue: G1 intermittently does not tenure several regions which contain only objects whose age greater than MaxTenuringThreshold.

I've created two test cases to illustrate this issue: one uses WhiteBox::youngGC to force required amount of young GCs (TestUsingWB.java), second do not use WB API (I've created it to be sure that issue is not related to WB::youngGC).

Here is how it looks in gc log (from wb/log.25158):
...
{Heap before GC invocations=16 (full 1):
 garbage-first heap   total 262144K, used 36493K [0x00000000f0000000, 0x00000000f0800100, 0x0000000100000000)
  region size 8192K, 4 young (32768K), 4 survivors (32768K)
 Metaspace       used 3758K, capacity 4614K, committed 4864K, reserved 1056768K
  class space    used 390K, capacity 434K, committed 512K, reserved 1048576K
#16: [GC pause (WhiteBox Initiated Young GC) (young) G1HR #StartGC 17

Desired survivor size 33554432 bytes, new threshold 15 (max threshold 15)
- age  15:   16778280 bytes,   16778280 total
 G1HR CSET 0x00000000fc800000
 G1HR CSET 0x00000000fd000000
 G1HR CSET 0x00000000fe000000
 G1HR CSET 0x00000000ff000000
 G1HR ALLOC(Old) 0x00000000f1000000
 G1HR ALLOC(Old) 0x00000000f1800000
 G1HR ALLOC(Old) 0x00000000f2000000
 G1HR ALLOC(Survivor) 0x00000000ff800000
 G1HR RETIRE 0x00000000ff800000 0x00000000ffa66708
 G1HR RETIRE 0x00000000f2000000 0x00000000f2022000
 G1HR #EndGC 17
 35M->22M(256M), 0.2036432 secs]
Heap after GC invocations=17 (full 1):
 garbage-first heap   total 262144K, used 23521K [0x00000000f0000000, 0x00000000f0800100, 0x0000000100000000)
  region size 8192K, 1 young (8192K), 1 survivors (8192K)
 Metaspace       used 3758K, capacity 4614K, committed 4864K, reserved 1056768K
  class space    used 390K, capacity 434K, committed 512K, reserved 1048576K
}

When survivor regions exist the test prints out appropriate message and enters infinite loop, so you can attach to process and take a look at regions' content.
I've create core files (see attachment) and here is content of 0x00000000ff800000 region mentioned in log above obtained using CLHSDB:

hsdb> scanoops 0x00000000ff800000 0x00000000ffc00000
0x00000000ff800000 [I
0x00000000ffa66708 java/lang/String
0x00000000ffa66720 java/lang/String
0x00000000ffa66738 java/lang/String
0x00000000ffa66750 java/lang/String
0x00000000ffa66768 [B
0x00000000ffa66778 [B
0x00000000ffa66788 [B
0x00000000ffa66798 [B
0x00000000ffa667a8 [B
0x00000000ffa667b8 [B
0x00000000ffa667c8 [B
0x00000000ffa667d8 [B
0x00000000ffa667e8 [B
0x00000000ffa667f8 [B
...

int array @ 0x00000000ff800000 is filler object, byte arrays starting from 0x00000000ffa66768 are arrays allocated before minor GC invocations and four strings are string used in main:

hsdb> inspect 0x00000000ff800000
instance of [I @ 0x00000000ff800000 @ 0x00000000ff800000 (size = 2516744)
_mark: 1
_metadata._compressed_klass: TypeArrayKlass for [I
0: -558908738
1: -558908738
2: -558908738
3: -558908738
4: -55890873
...

hsdb> inspect 0x00000000ffa66708
instance of "Unable to find MemoryPoolMXBean for survivor space" @ 0x00000000ffa66708 @ 0x00000000ffa66708 (size = 24)
_mark: 4278190267
_metadata._compressed_klass: InstanceKlass for java/lang/String
value: [C @ 0x00000000fdb008d0 Oop for [C @ 0x00000000fdb008d0
hash: 0

hsdb> inspect 0x00000000ffa66768
instance of [B @ 0x00000000ffa66768 @ 0x00000000ffa66768 (size = 16)
_mark: 4244964979
_metadata._compressed_klass: TypeArrayKlass for [B
Comments
Took a look at this and after some digging this seems to be a duplicate of a bug recently fixed: https://bugs.openjdk.java.net/browse/JDK-8064473 After this fix I can't reproduce the problem with the attached repro, but backing it out I'm able to reproduce. I'm going to close this bug as a dup, even though the RULE still matches some failures. The same RULE is present in https://bugs.openjdk.java.net/browse/JDK-8066143, so I expect that that bug is the root cause of the nightly failures.
05-12-2014

This bug shows up in nightly GC testing so I increased the priority.
04-12-2014

ILW: I: medium -> potentially some performance hit L: medium -> 1/10 W: high -> none -> P3
07-10-2014

How to run attached test case: $JAVA_HOME/bin/java -XX:+UseG1GC -XX:MaxNewSize=64m -XX:NewSize=64m -XX:MaxHeapSize=256m -XX:G1HeapRegionSize=4m -XX:+PrintHeapAtGC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=1 -XX:InitialTenuringThreshold=15 -XX:+PrintTenuringDistribution -XX:+PrintGC -XX:+G1PrintHeapRegions -cp $HOTSPOT_WS/test/testlibrary/whitebox/:. -Xbootclasspath/a:$HOTSPOT_WS/test/testlibrary/whitebox -XX:+UnlockExperimentalVMOptions -XX:+WhiteBoxAPI TestUsingWB On my linux-x64 desktop issue reproduces quite ofter (~ 1/10 runs).
07-10-2014