JDK-8324823 : G1: Provide automated way to check for pin count underflows
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 23
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-01-29
  • Updated: 2024-01-29
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
tbdUnresolved
Related Reports
Relates :  
JDK-8322484 - 22-b26 Regression in J2dBench-bimg_misc-G1 (and more) on Windows-x64 and macOS-x64
Description
G1 maintains a pin count value for every region that indicates how many times an object has been pinned in a region.

Typically these calls to pin/unpin (Get/ReleasePrimitiveCritical) need to be paired exactly to avoid memory leaks (the region can't be reclaimed while the pin count != 0).

Currently gc+heap+region=trace provides a way to monitor the region's pin count, allowing a user to track pin counts. This makes debugging issues in that area possible, but tedious.

For a bit more convenience we could add a pin count "red zone", particularly in the negative range (-1 ... -4096 -  random numbers) where if the aggregated pin count is within that area, error out.

Maybe guarded with CheckJNI or something flag.