[13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails

[dean.long at oracle.com]

Thanks Tom.

dl

On 6/24/19 12:08 PM, Tom Rodriguez wrote:
>
>>> Please, keep name the same for consistency with jvmci-8.
>>>
>>
>> OK, here's the webrev that removes the unused method, but does not 
>> rename:
>>
>> http://cr.openjdk.java.net/~dlong/8225369/remove/
>>
>> While I was at it, I merged ResolveConstantInPoolTest into 
>> ResolvePossiblyCachedConstantInPoolTest, but it's not strictly 
>> necessary.  I could keep them separate.
>
> Looks great to me.
>
> tom
>
>>
>> dl
>>
>>> Vladimir
>>>
>>>>
>>>> tom
>>>>
>>>>>
>>>>> dl
>>>>>> tom
>>>>>>
>>>>>>>
>>>>>>> dl
>>>>>>>
>>>>>>> On 6/21/19 1:09 PM, dean.long at oracle.com wrote:
>>>>>>>> On 6/21/19 9:42 AM, Tom Rodriguez wrote:
>>>>>>>>> Doesn't that make resolveConstantInPool completely unused?
>>>>>>>>
>>>>>>>> Yes, except for a jtreg test, which can be removed.
>>>>>>>>
>>>>>>>>> It should probably be deleted and the javadoc updated for 
>>>>>>>>> resolvePossiblyCachedConstantInPool.
>>>>>>>>
>>>>>>>> OK.
>>>>>>>>
>>>>>>>> dl
>>>>>>>>
>>>>>>>>>
>>>>>>>>> tom
>>>>>>>>>
>>>>>>>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225369
>>>>>>>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/
>>>>>>>>>>
>>>>>>>>>> This test triggers a race, which can result in different 
>>>>>>>>>> resolved values of the MethodHandle constant.  The VM chooses 
>>>>>>>>>> a winner and stores that value in the constant pool cache, 
>>>>>>>>>> however Graal is not checking the cache.  The trivial fix is 
>>>>>>>>>> to use the proper API that goes through the cache.
>>>>>>>>>>
>>>>>>>>>> dl
>>>>>>>>
>>>>>>>
>>>>>
>>