<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Nov 23, 2015, at 10:31 AM, Vladimir Ivanov <<a href="mailto:vladimir.x.ivanov@oracle.com" class="">vladimir.x.ivanov@oracle.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class="">Updated version:<br class="">  <a href="http://cr.openjdk.java.net/~vlivanov/8072008/webrev.03/" class="">http://cr.openjdk.java.net/~vlivanov/8072008/webrev.03/</a><br class=""></div></blockquote><div><br class=""></div><div>Good, ship it!</div></div><div><br class=""><blockquote type="cite" class=""><div class="">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?<br class=""></div></blockquote><div><br class=""></div><div>A non-constant MH, if it goes null, will cause a SEGV due to the indirection to MH.form.vmentry.</div><div>So we'd get a crash if MH invokeBasic dispatcher were ever called on NULL.</div><div>But the interpreter and JITs emit null checks first.</div><div>See TemplateTable::invokehandle, DirectCallGenerator::generate, GraphBuilder::invoke.</div><div><br class=""></div><div>The special null checks done in SharedRuntime are corner cases which only apply</div><div>to the first execution of a given invocation bytecode.  I think there might be a</div><div>corner-of-a-corner case where a pathological invocation is never fully resolved,</div><div>and always goes through SharedRuntime.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">In fact, now I wonder how an inlined linkToSpecial will perform a receiver<br class="">null check correctly, in the present logic.<br class=""></blockquote>Null check during resolution should happen here:<br class="">Handle SharedRuntime::find_callee_info_helper(JavaThread* thread,<br class="">  ...<br class="">  bool has_receiver = bc != Bytecodes::_invokestatic &&<br class="">                      bc != Bytecodes::_invokedynamic &&<br class="">                      bc != Bytecodes::_invokehandle;<br class=""><br class="">  // Find receiver for non-static call<br class="">  if (has_receiver) {<br class="">...<br class="">    if (<a href="http://receiver.is" class="">receiver.is</a>_null()) {<br class="">      THROW_(vmSymbols::java_lang_NullPointerException(), nullHandle);<br class="">    }<br class=""><br class="">Or do you have another scenario on your mind?<br class=""></div></blockquote><div><br class=""></div><div>If the bc that controls has_receiver is rewritten from invokestatic (for linkToSpecial)</div><div>to invokespecial (for the target method), then the null check will happen.</div><div>I suppose I was confused which bc was which.  It looks good now.</div><div><div>(I am also permanently confused about why there is null checking during resolution.</div><div>I think there's a reason, but it's not one I want to spend gray matter on.)</div></div><div class=""><br class=""></div><div class="">…</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="">Also, please consider walking the parallel argument lists for the MH calls</blockquote><blockquote type="cite" class="">to check for oop/32/64 mismatches.  You can do it easily with a pair of<br class="">SignatureStream iterators.<br class=""></blockquote>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.</div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>Thank you!</div><div><br class=""></div><div>— John</div></div></body></html>