Bug ID: JDK-8218049 Survivor MemoryMXBean used() size granularity is region based

JDK-8218049 : Survivor MemoryMXBean used() size granularity is region based

Type: Bug
Component: hotspot
Sub-Component: gc
Affected Version: 8u192,9,10,11,12,13

Priority: P4
Status: Resolved
Resolution: Fixed

Submitted: 2019-01-30
Updated: 2024-01-03
Resolved: 2019-04-08

Versions (Unresolved/Resolved/Fixed)

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 11	JDK 13
11.0.23-oracleFixed	13 b16Fixed

Related Reports

Blocks :	JDK-8081688 - SurvivorAlignmentInBytes tests too lenient
Blocks :	JDK-8209062 - Clean up G1MonitoringSupport
Blocks :	JDK-8220089 - G1 reuse survivor region as eden region at the end of gc
Duplicate :	JDK-8177765 - gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java: Actual memory usage should not deviate from expected
Duplicate :	JDK-8129886 - Test TestPromotionToSurvivor fails with jimage refresh
Duplicate :	JDK-8190277 - TestPromotionToSurvivor - Actual memory usage should not deviate from expected
Relates :	JDK-8221994 - Improve consistency between actual values and MemoryUsage.used() in MBeans

Description

The used() of survivor space MemoryMXBean is based on region granularity. I.e. a survivor region can either be fully used or not.

This causes failures for tests that use the used() value of that MemoryMXBean (linked below) as they do not expect such large jumps in usage after allocation of a few (more) objects in survivor space.

This is day one behavior (and some of these tests have been excluded from testing for a long time now).

After fixing, also re-enable the corresponding tests, verifying that they work again.

Comments

[11u] I assume this depends on changes we did not do for 11.0.22 as 8207200, 8208498, 8209061, 8209062.
03-01-2024
Git URL: https://github.com/openjdk/jdk/commit/bb31c7d085d82a8535d1b9cb3567201022c1ed27
03-01-2024
URL: http://hg.openjdk.java.net/jdk/jdk/rev/0c5d713cf43f User: sangheki Date: 2019-04-08 19:16:14 +0000
08-04-2019
Only linked this issue as "blocker" for JDK-8081688 that issue is a cause of this issue, i.e. we need to set the threshold for detecting wrong allocation so high. After fixing this it should be easy to decrease the threshold.
30-01-2019
These tests could already be enabled for non-g1 GCs.
30-01-2019