[9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls

[Vladimir Ivanov]

>> Updated version:
>> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.03/
>
> Good, ship it!
Thanks, John!

>> 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
> resolved,
> and always goes through SharedRuntime.
Got it. Thanks for the clarifications.

>>> Also, please consider walking the parallel argument lists for the MH
>>> calls
>>> 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 
requested information.

Best regards,
Vladimir Ivanov