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

Tom Rodriguez tom.rodriguez at oracle.com
Mon Jun 24 19:08:16 UTC 2019


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


More information about the hotspot-compiler-dev mailing list