RFR: 8195972: Refactor oops in JNI to use the Access API (original) (raw)
Kim Barrett kim.barrett at oracle.com
Thu Mar 29 21:38:35 UTC 2018
- Previous message: RFR: 8195972: Refactor oops in JNI to use the Access API
- Next message: [8u] RFR for backport of "JDK-8164480: Crash with assert(handler_address == SharedRuntime::compute_compiled_exc_handler(..) failed: Must be the same" to jdk8u-dev
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mar 29, 2018, at 3:49 PM, coleen.phillimore at oracle.com wrote: Kim's change looks correct as far as I can tell. INCONCURRENTROOT is equivalent to INROOT right now, isn't it?
No, they are not equivalent.
RootAccess::oop_store(…) must generate the SATB pre-barrier. RootAccess<>::oop_store(…) should not generate the SATB pre-barrier.
RootAccess<...> is just Access<IN_ROOT | …> (Currently RootAccess is a class, in C++11 it could be a template type alias.)
I feel a bit unhappy that IN_CONCURRENT_ROOT and IN_ROOT are not mutually exclusive. If I recall correctly, IN_CONCURRENT_ROOT will actually default in IN_ROOT if the latter is not present, but I might be mis-remembering. (Or alternatively, that we don’t have a distinct name for non-concurrent-root.)
And I have no idea what the relation between either of those and IN_ARCHIVE_ROOT might be; the latter has no documentation (see JDK-8198381).
- Previous message: RFR: 8195972: Refactor oops in JNI to use the Access API
- Next message: [8u] RFR for backport of "JDK-8164480: Crash with assert(handler_address == SharedRuntime::compute_compiled_exc_handler(..) failed: Must be the same" to jdk8u-dev
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]