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

[Vladimir Kozlov]

+1

Dean, did you file PR to fix it upstream?

Thanks,
Vladimir

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
>>>>>>>>
>>>>>>>
>>>>>
>>