RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls
vladimir.x.ivanov at oracle.com
Tue Nov 24 10:33:46 UTC 2015
>> Updated version:
> Good, ship it!
>> Actually, I'm not sure why the code doesn't compute a receiver for
>> invokehandle case. MH.invokeBasic is instance method and NPE should be
>> through if the receiver is null. Is it because the adapter is
>> responsible for throwing the exception?
> A non-constant MH, if it goes null, will cause a SEGV due to the
> indirection to MH.form.vmentry.
> So we'd get a crash if MH invokeBasic dispatcher were ever called on NULL.
> But the interpreter and JITs emit null checks first.
> See TemplateTable::invokehandle,
> DirectCallGenerator::generate, GraphBuilder::invoke.
> The special null checks done in SharedRuntime are corner cases which
> only apply
> to the first execution of a given invocation bytecode. I think there
> might be a
> corner-of-a-corner case where a pathological invocation is never fully
> and always goes through SharedRuntime.
Got it. Thanks for the clarifications.
>>> Also, please consider walking the parallel argument lists for the MH
>>> to check for oop/32/64 mismatches. You can do it easily with a pair of
>>> SignatureStream iterators.
>> Done. It was not that easy (see check_inlined_mh_linker_info in
>> doCall.cpp). The main complication is virtual vs static methods in
>> MH.invokeBasic case.
> Well, there were a number of moving parts in there. I'm glad you did
> this; it provides useful documentation of how MH infra. works.
> Did that check find any bugs? If not, you might inject one fault (e.g.
> linkToStatic instead of linkToSpecial) and verify that the pre-crash
> dumping code works.
I saw crashes while tuning the logic and VM successfully dumped all
More information about the hotspot-compiler-dev