RFR: 8164214: [JVMCI] include VarHandle in signature polymorphic method test

[Paul Sandoz]

> On 22 Aug 2016, at 13:37, Doug Simon <doug.simon at oracle.com> wrote:
> 
> 
>> On 22 Aug 2016, at 19:38, Christian Thalinger <cthalinger at twitter.com> wrote:
>> 
>>> 
>>> On Aug 19, 2016, at 9:59 PM, Doug Simon <doug.simon at oracle.com> wrote:
>>> 
>>> 
>>>> On 20 Aug 2016, at 02:26, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>>> 
>>>> It may be better to expose a new enum value in Flags and set the bit based on the _intrinsic_id, rather than JVMCI checking the range.
>>>> 
>>>> Thus the Flags enum value for sig-poly remains constant even if the _intrinsic_id values do not (IIUC they will change when new intrinsics are added), thus less needs to be exposed to JVMCI.
>>> 
>>> Yes, that’s what I was thinking. The intrinsic_id range seems more subject to change than a flag.
>>> 
>>>> e.g. something like below (not tested)?
>>> 
>>> In the context of 8164214, I’ve just realised that making it possible to query whether a Method*/HotSpotResolvedJavaMethodImpl is sig-poly is a red herring. In this context, we’re dealing with constant pool resolution so have neither a Method* nor HotSpotResolvedJavaMethodImpl in hand.
>>> 
>>> Based on this (late - sorry!) realization, I propose to add `String[] CompilerToVM.getSignaturePolymorphicHolderNames()`:
>>> 
>>> http://cr.openjdk.java.net/~dnsimon/8164214v2
>> 
>> I don’t see why this is any better in terms of “duplicating” logic:
> 
> It’s only slightly better in that it’s now in C++ VM code. I would hope that someone updating the well known sig-poly holder class set would grep the VM sources for VarHandle but I agree that it’s an unrealistic expectation. The real solution as you say is to contain it all in methodHandles.[cpp|hpp]. I’m happy to give that a shot but I’m not sure it should be done as part of this change. Paul, what do you think?
> 

I think we should log another issue to clean up the sig-poly checks in hotspot and in that issue make special note of the explicit JMVCI check that should be updated.

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160822/fe032053/signature.asc>