Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor

John Rose john.r.rose at oracle.com
Mon Feb 11 21:56:54 PST 2013


On Feb 11, 2013, at 6:34 PM, Krystal Mo <krystal.mo at oracle.com> wrote:

> Let's get John's comment and see if my understanding of that part is correct.

The new code treats findSpecial and unreflectSpecial as corner cases.  In these corner cases, refKind is invokespecial, *and* this is visible to the user.  These cases are covered by a special subclass of DMH (called DMH.Special).  This guy always reports invokespecial as his refKind.

Meanwhile, all other "normal" DMHs report invokevirtual (or invokeinterface for interfaces).  This is true even if they internally use an optimized refKind of invokespecial.

So there are three different cases:

Lookup call, external refKind, internal refKind, DMH class
findVirtual(Object::hashCode), invokevirtual, invokevirtual, DMH
findVirtual(String::hashCode), invokevirtual, invokespecial, DMH
findSpecial(Object::hashCode), invokespecial, invokespecial, DMH.Special

For plain non-special DMH, an internal reference kind of invokespecial is always rewritten to a user-visible invokevirtual.

(I suppose if "final default" methods were allowed, they might need rewriting from internal invokespecial to user-visible invokeinterface.)

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130211/1185cde7/attachment-0001.html 


More information about the hotspot-compiler-dev mailing list