[9] RFR (XS): 8145137: Incorrent call signature can be used in nmethod::preserve_callee_argument_oops

[Vladimir Ivanov]

http://cr.openjdk.java.net/~vlivanov/8145137/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8145137

It's a followup on JDK-8072008 [1]. I missed one place where VM consults 
bytecode, but it is inaccurate when there's an attached method in 
generated code.

Consider MH.linkTo*(..., MemberName) case. When C2 inlines through the 
linker, but doesn't inline callee, it issues a virtual/direct call and 
attaches a method to the call site. There's no MemberName oop pushed on 
stack, it is present only in scopes for deoptimization purposes.

But GC uses method signature from bytecode, so it tries to extract 
MemberName from the stack and usually gets some garbage. The crash 
happens when GC tries to make sense out of it.

The fix is to use attached method signature when it is present.

Also, adjusted the unit test to deoptimize everyting. WB::deoptimize() 
doesn't work as expected since it triggers deoptimization only in 
f1/f2/... nmethods (marked w/ @DontInline) and not linkTo* where call 
sites are.

Testing: JPRT, failing test case with focused changes to trigger 
problematic case (GC during call site resolution - 
SharedRuntime::resolve_*_C)

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8072008
     "Emit direct call instead of linkTo* for recursive indy/MH.invoke* 
calls"