JDK-8251358 : Clean up Access configuration after Shenandoah barrier change
- Type: Enhancement
- Component: hotspot
- Sub-Component: gc
- Affected Version: 11,16
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2020-08-10
- Updated: 2021-08-18
- Resolved: 2020-09-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.
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 16 |
|---|
16 b18Fixed  |
Related Reports
|
Blocks :
|
|
|
Relates :
|
|
|
Relates :
|
Description
Shenandoah changed their barriers to no longer break the to-space invariant, and to no longer need barriers on primitives. As a result, the "SUPPORT" macros in barrierSetConfig.hpp (SUPPORT_BARRIER_ON_PRIMITIVES and SUPPORT_NOT_TO_SPACE_INVARIANT) are never set. So the conditionalization on them can be removed. A a result, INTERNAL_BT_BARRIER_ON_PRIMITIVES can always be assumed clear and INTERNAL_BT_TO_SPACE_INVARIANT can always be assumed set. So the (small number) of places examining them can be hard-coded and those decorators can be removed. The Access::resolve function should also no longer be needed; callers can be cleaned up and it can be removed.
Comments
|