How to get rid of MethodHandle::linkTo* call when target method is known but not inlined?

[John Rose]

On Feb 16, 2015, at 10:12 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> Yes, either an additional pass over code cache to update all stale Method* or a level of indirection (MemberName) is needed to keep class redefinition working.
> 
> Having MemberName instance instead of Method* for java.lang.invoke use case looks fine to me. But if it is useful for other use cases, working with VM metadata is more flexible IMO.

Yes.  We have to fix redef. bugs with MemberName anyway, so we can use it here too.  I like that, for the moment.

On Feb 16, 2015, at 10:53 AM, Dean Long <dean.long at oracle.com> wrote:
> 
> Another option could be to attach a constant pool to the nmethod, then add Method *'s to that constant pool.
> The reason for using a constant pool is because that's what the resolve logic is already using.

That is appealing, since constant pools also need to interactive properly with the redef. mechanism.

Downsides:  CPs are 1-1 with classes, and so we'd have to introduce an ad hoc class also.  But classes respect access checking, so we'd have to punch a hole in access checking for these injected Method references, leading to bug tail.  Also, CPs are really models of (parsed) classfiles, so it's a "code smell" to use one to inject a hard-coded Method ref. into compiled code.

I would prefer to reify the state of a linkable or linked reference using something more "internal" than a CP.  I have a very old placeholder RFE for this:  https://bugs.openjdk.java.net/browse/JDK-6711913

— John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150216/bf521419/attachment.html>