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

[dean.long at oracle.com]

I don't see anything to upstream to Graal here.  Do you mean jvmci-8?

dl

On 6/24/19 12:23 PM, Vladimir Kozlov wrote:
> +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
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>