RFR(T): 8229925: [s390] Exception check missing in interpreter
Reingruber, Richard
richard.reingruber at sap.com
Fri Aug 23 09:34:05 UTC 2019
Hi Martin,
> - VM Thread installs _pending_async_exception into T1 at safepoint.
> - Thread T1 converts it to a _pending_exception (check_and_handle_async_exceptions) when the safepoint is over and returns to Method::build_method_counters.
I think this happens later when returning to java. handle_special_runtime_exit_condition() is ment
to be called when returning from the runtime to the java app, i.e. when changing to _thread_in_Java
or _thread_in_native. Therefore SafepointSynchronize::block() does not call
handle_special_runtime_exit_condition() if the thread state is _thread_blocked_trans or
_thread_in_vm_trans. And its comment says:
// Check for pending. async. exceptions or suspends - except if the
// thread was blocked inside the VM
So async exceptions can override other exceptions, but not the other way round.
Cheers, Richard.
-----Original Message-----
From: Doerr, Martin
Sent: Donnerstag, 22. August 2019 16:59
To: David Holmes <david.holmes at oracle.com>; hotspot-runtime-dev at openjdk.java.net; Reingruber, Richard <richard.reingruber at sap.com>
Subject: RE: RFR(T): 8229925: [s390] Exception check missing in interpreter
Hi David and Richard,
thanks for the reviews. I've pushed it.
Nevertheless, I think it was worth looking into InterpreterRuntime::build_method_counters which may not work as expected.
Consider the following scenario:
- JVMTI thread calls JvmtiEnv::StopThread to install an asynchronous exception into thread T1.
- VM Thread initiates a safepoint when executing the VM operation VM_ThreadStop (mode _async_safepoint).
- Thread T1 is executing InterpreterRuntime::build_method_counters and attempts to acquire Heap_lock (in satisfy_failed_metadata_allocation) which checks for safepoint.
- VM Thread installs _pending_async_exception into T1 at safepoint.
- Thread T1 converts it to a _pending_exception (check_and_handle_async_exceptions) when the safepoint is over and returns to Method::build_method_counters.
It misinterprets the exception as a metaspace OOM, clears it and returns NULL!
(Debug build should run into assert((PENDING_EXCEPTION->is_a(SystemDictionary::OutOfMemoryError_klass())), "we expect only an OOM error here");)
I guess I should open a bug for that.
Best regards,
Martin
More information about the hotspot-runtime-dev
mailing list