RFR(S): 8009981: nashorn tests fail with -XX:+VerifyStack

[John Rose]

On Mar 18, 2013, at 7:11 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:

>> src/share/vm/runtime/deoptimization.cpp:
>> 
>> I'm confused by that code.  Does Bytecode_invoke invoke represent the instruction at cur_code?  If so you could replace:
>> 
>> if (cur_code != Bytecodes::_invokestatic && cur_code != Bytecodes::_invokedynamic) {
>> 
>> by:
>> 
>> if (invoke.has_receiver()) {
> 
> Yes, the two are the same. I'll make the change you suggest.

The code after, which calls MethodHandles::has_member_arg, seems wrong to me.  That applies to sig-poly intrinsics like linkToStatic.  Those guys always take a trailing MemberName (low-level function pointer) after all the normal arguments.  But, that trailing MemberName is fully represented in the signature of the call.

Example:  A direct call of out.println("foo") is:
	push out; push "foo"; invokevirtual PrintStream.println(String)V
while the corresponding indirect call is:
	push out; push "foo"; push println_MN; invokestatic MethodHandle.linkToVirtual(PrintStream,String,MemberName)V

Both calls end up at exactly the same entry point (some println(String) after dispatch).  The println_MN value is quietly dropped (interpreter) or ignored (compiler).

Because the bytecodes mention the MemberName as an argument, it is does not really qualify as an "appendix".

An "appendix" is a property of a resolved call site.  If present (non-null) it is pushed after any normal arguments.  (In that sense it is like the MemberName above.)  But it is not represented in the signature at the call site.  (So it's not like the MemberName.)  The linkage of the call site takes care that, if an appendix is present, then the method linked to (at the same call site) accepts the extra argument.  This is how invokedynamic and invokehandle manage to smuggled additional bits of call-site-specific information into a call.  The LambdaForm method (adapter logic) at the call site has a signature which expects the extra appendix argument, so once into the LF method, the appendix has a real presence in the JVM (as a local variable).

All this background is to say, maybe (maybe!) the logic in deoptimization.cpp should be calling has_appendix on the call site, not has_member_arg on the method.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130318/596ee7dd/attachment.html