-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8274379: Allow process of unsafe access errors in check_special_condition_for_native_trans #5741
Changes from all commits
f01f3dd
922462f
79e7454
4b1eb04
1dbbca9
2d4bace
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1001,8 +1001,10 @@ JavaThread::JavaThread() : | |
_monitor_chunks(nullptr), | ||
|
||
_suspend_flags(0), | ||
_async_exception_condition(_no_async_condition), | ||
_pending_async_exception(nullptr), | ||
#ifdef ASSERT | ||
_is_unsafe_access_error(false), | ||
#endif | ||
|
||
_thread_state(_thread_new), | ||
_saved_exception_pc(nullptr), | ||
|
@@ -1572,9 +1574,6 @@ void JavaThread::remove_monitor_chunk(MonitorChunk* chunk) { | |
|
||
// Asynchronous exceptions support | ||
// | ||
// Note: this function shouldn't block if it's called in | ||
// _thread_in_native_trans state (such as from | ||
// check_special_condition_for_native_trans()). | ||
void JavaThread::check_and_handle_async_exceptions() { | ||
if (has_last_Java_frame() && has_async_exception_condition()) { | ||
// If we are at a polling page safepoint (not a poll return) | ||
|
@@ -1600,21 +1599,12 @@ void JavaThread::check_and_handle_async_exceptions() { | |
} | ||
} | ||
|
||
AsyncExceptionCondition condition = clear_async_exception_condition(); | ||
if (condition == _no_async_condition) { | ||
// Conditions have changed since has_special_runtime_exit_condition() | ||
// was called: | ||
// - if we were here only because of an external suspend request, | ||
// then that was taken care of above (or cancelled) so we are done | ||
// - if we were here because of another async request, then it has | ||
// been cleared between the has_special_runtime_exit_condition() | ||
// and now so again we are done | ||
if (!clear_async_exception_condition()) { | ||
return; | ||
} | ||
|
||
// Check for pending async. exception | ||
if (_pending_async_exception != NULL) { | ||
// Only overwrite an already pending exception, if it is not a threadDeath. | ||
// Only overwrite an already pending exception if it is not a threadDeath. | ||
if (!has_pending_exception() || !pending_exception()->is_a(vmClasses::ThreadDeath_klass())) { | ||
|
||
// We cannot call Exceptions::_throw(...) here because we cannot block | ||
|
@@ -1631,25 +1621,23 @@ void JavaThread::check_and_handle_async_exceptions() { | |
} | ||
ls.print_cr(" of type: %s", _pending_async_exception->klass()->external_name()); | ||
} | ||
_pending_async_exception = NULL; | ||
// Clear condition from _suspend_flags since we have finished processing it. | ||
clear_suspend_flag(_has_async_exception); | ||
} | ||
} | ||
// Always null out the _pending_async_exception oop here since the async condition was | ||
// already cleared above and thus considered handled. | ||
_pending_async_exception = NULL; | ||
} else { | ||
assert(_is_unsafe_access_error, "must be"); | ||
DEBUG_ONLY(_is_unsafe_access_error = false); | ||
|
||
if (condition == _async_unsafe_access_error && !has_pending_exception()) { | ||
// We may be at method entry which requires we save the do-not-unlock flag. | ||
UnlockFlagSaver fs(this); | ||
switch (thread_state()) { | ||
case _thread_in_vm: { | ||
JavaThread* THREAD = this; | ||
Exceptions::throw_unsafe_access_internal_error(THREAD, __FILE__, __LINE__, "a fault occurred in an unsafe memory access operation"); | ||
return; | ||
} | ||
case _thread_in_native: { | ||
ThreadInVMfromNative tiv(this); | ||
JavaThread* THREAD = this; | ||
Exceptions::throw_unsafe_access_internal_error(THREAD, __FILE__, __LINE__, "a fault occurred in an unsafe memory access operation"); | ||
// We might have blocked in a ThreadBlockInVM wrapper in the call above so make sure we process pending | ||
// suspend requests and object reallocation operations if any since we might be going to Java after this. | ||
SafepointMechanism::process_if_requested_with_exit_check(this, true /* check asyncs */); | ||
return; | ||
} | ||
case _thread_in_Java: { | ||
|
@@ -1662,8 +1650,6 @@ void JavaThread::check_and_handle_async_exceptions() { | |
ShouldNotReachHere(); | ||
} | ||
} | ||
|
||
assert(has_pending_exception(), "must have handled the async condition if no exception"); | ||
} | ||
|
||
void JavaThread::handle_special_runtime_exit_condition(bool check_asyncs) { | ||
|
@@ -1696,9 +1682,8 @@ class InstallAsyncExceptionClosure : public HandshakeClosure { | |
} | ||
}; | ||
|
||
void JavaThread::send_async_exception(oop java_thread, oop java_throwable) { | ||
void JavaThread::send_async_exception(JavaThread* target, oop java_throwable) { | ||
Handle throwable(Thread::current(), java_throwable); | ||
JavaThread* target = java_lang_Thread::thread(java_thread); | ||
InstallAsyncExceptionClosure vm_stop(throwable); | ||
Handshake::execute(&vm_stop, target); | ||
} | ||
|
@@ -1847,21 +1832,17 @@ void JavaThread::check_special_condition_for_native_trans(JavaThread *thread) { | |
assert(thread->thread_state() == _thread_in_native_trans, "wrong state"); | ||
assert(!thread->has_last_Java_frame() || thread->frame_anchor()->walkable(), "Unwalkable stack in native->Java transition"); | ||
|
||
thread->set_thread_state(_thread_in_vm); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems odd to change the thread-state explicitly here when this logic is being processed in the middle of a transition from native->java. So what we end up doing is native->native_trans->in_vm->in_java (and possibly some additional changes from in_vm to blocked and back). I understand why we need to be "in vm" before calling process_if_requested... but it makes the thread state transition story rather messy (just imagine trying to draw a state machine model for this :) ). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Once we call JavaThread::check_special_condition_for_native_trans() we are calling into the vm so to me it actually makes more sense to set the state to _thread_in_vm there. Specially given that this is not some leaf method, but we actually process safepoint/handshakes/stackwatermarks and all other operations we check for in handle_special_runtime_exit_condition(). Note: As a future change I think we could just avoid the native_trans state altogether and just poll in a state of _thread_in_vm, since the only purpose of it is to poll in an unsafe state. Or we could even set the state to _thread_in_Java already, so that when there is nothing to process there are no extra changes of state needed, and when there are pending operations we can use a ThreadInVMfromJava wrapper here. |
||
|
||
// Enable WXWrite: called directly from interpreter native wrapper. | ||
MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread)); | ||
|
||
SafepointMechanism::process_if_requested_with_exit_check(thread, false /* check asyncs */); | ||
SafepointMechanism::process_if_requested_with_exit_check(thread, true /* check asyncs */); | ||
|
||
// After returning from native, it could be that the stack frames are not | ||
// yet safe to use. We catch such situations in the subsequent stack watermark | ||
// barrier, which will trap unsafe stack frames. | ||
StackWatermarkSet::before_unwind(thread); | ||
|
||
if (thread->has_async_exception_condition(false /* check unsafe access error */)) { | ||
// We are in _thread_in_native_trans state, don't handle unsafe | ||
// access error since that may block. | ||
thread->check_and_handle_async_exceptions(); | ||
} | ||
} | ||
|
||
#ifndef PRODUCT | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to wonder why this isn't handled in the TBIVM?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In 8270085 we had to disable by default processing of suspend requests due to possible deadlocks. So although suspend requests are implemented with handshakes, calls to process_if_requested() from ~TBIVM will not process them. As for object reallocation I'm not sure but I think it's just because there is no need to process them until we are about to go back to Java.