JDK-8129886 : Test TestPromotionToSurvivor fails with jimage refresh
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P5
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2015-06-25
  • Updated: 2023-10-09
  • 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.
Other
tbd_majorResolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
jimage seems to add just enough instances to the heap to cross the test boundary.
jimage change alone doesn't make the test to fails. But applied on top of 24-June-2015 hs-rt, it fails.

For now we are ignoring it (as suggested by test owner).

Motivation:

The test wants to find out whether the GC properly aligns objects in the
survivor space by checking whether a fixed amount of objects with a
given size gets "expanded" to the right amount of memory after it has
been copied with alignment.

This is problematic because if somebody else than the test allocated
some memory on the Java heap inbetween, then it fails. There is this 1M
slack to avoid that. That slack has basically been sized to "work".
There is also some detection if some other threads, like an attached VM
agent, allocates memory inbetween, but that one is not particularly
good. (E.g. in https://bugs.openjdk.java.net/browse/JDK-8081688 it very
often detects this situation wrongly, making the test pass without
checking anything).

So if for some reason with the change you have the VM allocates more
Java objects during the test period (like if some background thread is
still busy loading non-essential classes when the test is running, and
this additional memory use is intentional/known/okay), the test breaks.
Comments
The problem is that recent changes increased the amount of allocated bytes during the checked GC, just enough to require G1 to use a fresh region for allocating objects during GC. This additional fresh region (1M), which is almost empty after GC, is part of the number of bytes returned in the MX bean in full, causing an additional 1M difference that makes the test fail. Not sure how to fix this: one could either increase the threshold (like there must be some slack for a single additional region to be allocated), or somehow provide the actual amount of bytes copied during GC to the test application.
01-07-2015