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