JDK-8241841 : Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion
- Type: Enhancement
- Component: hotspot
- Sub-Component: gc
- Affected Version: 8-shenandoah,11-shenandoah,14,15
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2020-03-30
- Updated: 2022-02-24
- Resolved: 2020-03-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.
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 14 | JDK 15 |
|---|---|
| 14.0.2Fixed | 15 b18Fixed  |
Related Reports
|
Blocks :
|
|
|
Blocks :
|
Description
We currently count the allocation by type: TLAB, GCLAB, shared allocs. All together, they should add up to the "used" space in the region. That means we can ditch one of the counters, and infer it from the already tracked "used" size. "Shared" counter seems to be the most profitable to go: it usually means either a small allocation that does not need another small roadbump on allocation path, or the humongous allocation that does increments for every region in the humongous chain.
Comments
|