JDK-8166188 : G1 Needs pre barrier on dereference of weak JNI handles
- Type: Bug
- Component: hotspot
- Sub-Component: gc
- Affected Version: 9
- Priority: P2
- Status: Closed
- Resolution: Fixed
- Submitted: 2016-09-16
- Updated: 2017-07-26
- Resolved: 2017-02-16
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 10 | JDK 9 |
|---|---|
10Fixed  |
9 b159Fixed |
Related Reports
|
Blocks :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
Description
After discussions around possible weak reference object resurrection through Unsafe::getObjectVolatile it was realized that weak JNI handles suffer from the same problem. Code dereferencing a jweak must ensure that the oop is marked by SATB since the jweak may have been the only remaining reference to the object. Unfortunately the JNI spec allows jweak parameters in place of any jobject parameter to any JNI entry point so we would either need to be able to detect a jweak parameter or unconditionally ensure that all resolved objects are marked.
Comments
|