RFR(T): 8229925: [s390] Exception check missing in interpreter
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.
>> 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)
> Best regards,
More information about the hotspot-runtime-dev