-
Bug
-
Resolution: Fixed
-
P4
-
19
ProgrammableUpcallHandler::on_entry modifies:
context->new_handles = JNIHandleBlock::allocate_block(thread);
thread->clear_pending_exception();
Before transitioning to Java. Which means there can be a concurrent safepoint/handshake.
ProgrammableUpcallHandler::on_exit modify and access same fields here:
JNIHandleBlock::release_block(context->new_handles, thread);
assert(!thread->has_pending_exception(), "Upcall can not throw an exception");
After transitioning back to native.
E.g. _free_handle_block, _pending_exception.
This have two issues:
- Is it safe today? I traced some code and FAICT it is.
- These fields are now only allowed to be modified in a safepoint/handshake if target thread is waiting for the safepoint/handshake or by the thread it self. (I.e. it is not enough that thread is safepoint safe, it must actively be waiting for the safepoint/handshake)
Is this a restriction that we want, and am I correct in saying that is safe?
context->new_handles = JNIHandleBlock::allocate_block(thread);
thread->clear_pending_exception();
Before transitioning to Java. Which means there can be a concurrent safepoint/handshake.
ProgrammableUpcallHandler::on_exit modify and access same fields here:
JNIHandleBlock::release_block(context->new_handles, thread);
assert(!thread->has_pending_exception(), "Upcall can not throw an exception");
After transitioning back to native.
E.g. _free_handle_block, _pending_exception.
This have two issues:
- Is it safe today? I traced some code and FAICT it is.
- These fields are now only allowed to be modified in a safepoint/handshake if target thread is waiting for the safepoint/handshake or by the thread it self. (I.e. it is not enough that thread is safepoint safe, it must actively be waiting for the safepoint/handshake)
Is this a restriction that we want, and am I correct in saying that is safe?
- links to
-
Commit(master) openjdk/jdk/461ffafe
-
Review(master) openjdk/jdk/21742