JDK-8220028 : [JVMCI] simplify management of speculations
- Type: Enhancement
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 13
- Priority: P4
- Status: Closed
- Resolution: Duplicate
- Submitted: 2019-03-03
- Updated: 2019-05-01
- Resolved: 2019-05-01
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 13 |
|---|
13Resolved  |
Related Reports
|
Blocks :
|
|
|
Duplicate :
|
Description
Currently, HotSpotSpeculationLog encapsulates and stores object representing speculations across all compilations of a method (or a Truffle AST). This complicates GC which has to find these logs and also presents concurrency issues when there can be multiple compilations of a Method. It is better to have a compilation serialize speculations into bytes. An nmethod will directly store these bytes and when a speculation fails, the relevant bytes are appended to a list hanging of a Method* (or Truffle AST). This has the following advantages: * speculation lifetimes work out of the box (i.e. they are reclaimed when their holder is collected) * in the context of libgraal, there is no need to worry about managing objects on the SVM heap that outlive a compilation
Comments
|