-
Bug
-
Resolution: Unresolved
-
P4
-
repo-valhalla
To implement JDK-8348608, core libraries need runtime API support to access atomic-compatible layout flat values.
Critical APIs requested for flat values from runtime, for modes:
get/setVolatile, compareAndSet, compareAndExchange.
Please name their native methods with a 0 suffix like getFlatValueVolatile0 to allow core library to add check to ensure the incoming layout is valid.
Other APIs can be implemented by core library's unsafe, such as:
getAcquire, setRelease, get/setOpaque, getAndSet...
Also, core library will need to check if a layout value is valid. That is probably best done in Java to avoid native overheads. Maybe we can add a native method that return a bit mask, marking layouts that are flat atomics with 1, and unsafe call this in an initializer. Otherwise, future layout changes in runtime may forget to update core libs code and cause crashes.
Critical APIs requested for flat values from runtime, for modes:
get/setVolatile, compareAndSet, compareAndExchange.
Please name their native methods with a 0 suffix like getFlatValueVolatile0 to allow core library to add check to ensure the incoming layout is valid.
Other APIs can be implemented by core library's unsafe, such as:
getAcquire, setRelease, get/setOpaque, getAndSet...
Also, core library will need to check if a layout value is valid. That is probably best done in Java to avoid native overheads. Maybe we can add a native method that return a bit mask, marking layouts that are flat atomics with 1, and unsafe call this in an initializer. Otherwise, future layout changes in runtime may forget to update core libs code and cause crashes.
- relates to
-
JDK-8351569 [lworld] Revisit atomic access modes in flat var handles
-
- Resolved
-