RFR(T): 8229925: [s390] Exception check missing in interpreter

David Holmes david.holmes at oracle.com
Thu Aug 22 05:56:59 UTC 2019

On 22/08/2019 12:46 am, Doerr, Martin wrote:
> Hi David,
>> Update looks good.
> Thanks.
>> The fact we may generate an OOME suggests straight away that we may hit
>> a safepoint which violates the rules for JRT_LEAF.
> No, just the pre-allocated Universe::_out_of_memory_error_metaspace or Universe::_out_of_memory_error_class_metaspace may get installed.

Okay - I didn't deep dive into exactly where all those codepaths may 
lead. The point is JPRT_LEAF has a number of rules and its far from 
obvious to me that this code necessarily always obeys them.

> JRT_LEAF contains a NoSafepointVerifier so we should notice a violation.
>> If it were a leaf then the exception check would be missing,
>> reintroducing the test failure that highlighted the issue.
> Note that the safepoint at which the async exception gets installed is part of the ThreadInVMfromJava destructor.

I'm not following. The original issue is caused by not passing "true" 
for the check_exceptions parameter of call_VM. If you call call_VM_leaf 
then its effectively the same as the original problematic code in that 
there is no exception check.


> And InterpreterRuntime::build_method_counters uses CLEAR_PENDING_EXCEPTION before that.
> If we use JRT_LEAF: no safepoint => no exception at this point.
>> Thread* THREAD = thread;
>> would be clearer (and consistent with VM_ENTRY macros)
> Agreed.
> Best regards,
> Martin

More information about the hotspot-runtime-dev mailing list