[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