JDK-8190277 : TestPromotionToSurvivor - Actual memory usage should not deviate from expected
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9,10,11
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2017-10-27
  • Updated: 2019-01-30
  • Resolved: 2019-01-30
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 13
13Resolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Sub Tasks
JDK-8206396 :  
Description
Testsuite name: /hotspot/test gc/survivorAlignment (jtreg)
Test name(s): TestPromotionToSurvivor.java
Product(s) tested: JDK 9.0.4 1
OS/architecture: Linux x64, Mac OS x64, Sparc v9
Reproducible: Always
Is it a Regression: No, reproducible in 9 GA (9 181)
Log: 
----------System.out:(76/1905)----------
SurvivorAlignmentTestMain info:
Desired object size: 16
Memory to fill: 10485760
Objects to be allocated: 655360
Alignment helpers to be used: 
For space EDEN:
AlignmentHelper for memory pool 'G1 Eden Space':
Memory usage measurement precision: -1
Min object size in this space: 16
Object alignment in this space: 8

For space SURVIVOR:
AlignmentHelper for memory pool 'G1 Survivor Space':
Memory usage measurement precision: -1
Min object size in this space: 16
Object alignment in this space: 32

For space TENURED:
AlignmentHelper for memory pool 'G1 Old Gen':
Memory usage measurement precision: 8
Min object size in this space: 16
Object alignment in this space: 8


Verifying amount of memory allocated by threads:
Thread 13
baseline allocation: 4452712
current allocation:14941296
"MainThread" prio=5 Id=13 RUNNABLE


Thread 10
baseline allocation: 0
current allocation:0
"Common-Cleaner" daemon prio=8 Id=10 TIMED_WAITING on java.lang.ref.ReferenceQueue$Lock@723c8991


Thread 5
baseline allocation: 0
current allocation:0
"Attach Listener" daemon prio=5 Id=5 RUNNABLE


Thread 4
baseline allocation: 0
current allocation:0
"Signal Dispatcher" daemon prio=9 Id=4 RUNNABLE


Thread 3
baseline allocation: 272
current allocation:272
"Finalizer" daemon prio=8 Id=3 WAITING on java.lang.ref.ReferenceQueue$Lock@3378172e


Thread 2
baseline allocation: 0
current allocation:0
"Reference Handler" daemon prio=10 Id=2 RUNNABLE


Thread 1
baseline allocation: 2308952
current allocation:2308952
"main" prio=5 Id=1 WAITING on java.lang.Thread@558413c4


Verifying memory usage in space: SURVIVOR
Allocated objects count: 655360
Desired object size: 16
Actual object size: 16
Expected object size in space: 32
Expected memory usage: 20971518
Actual memory usage: 22020096
Memory usage diff: 1048578
Max allowed usage diff: 1048573
----------System.err:(17/1353)----------
java.lang.RuntimeException: Actual memory usage should not deviate from expected for more then 1048573: expected that 1048578 <= 1048573
	at jdk.test.lib.Asserts.fail(Asserts.java:594)
	at jdk.test.lib.Asserts.assertLessThanOrEqual(Asserts.java:154)
	at jdk.test.lib.Asserts.assertLTE(Asserts.java:125)
	at SurvivorAlignmentTestMain.verifyMemoryUsage(SurvivorAlignmentTestMain.java:333)
	at TestPromotionToSurvivor.main(TestPromotionToSurvivor.java:85)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
	at java.base/java.lang.Thread.run(Thread.java:844)
Comments
The issue is that G1 compared to other collectors reports survivor size usage in region increments (because it can't reuse space at the end of the last survivor region) _and_ when allocating a TLAB of a given size X, there is only X - AlignmentReserve space available for allocation there. I.e. all collectors use a little more space (and a few more PLABs) than actually needed for the allocation, which causes G1 to start using an extra region.
05-07-2018

The reason why this issue is not "reproducable" in 10 or 11 is because it has been added to the ProblemList in JDK 9 (JDK-8028450). Reopening.
05-07-2018