[13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails
dean.long at oracle.com
dean.long at oracle.com
Fri Jun 21 20:14:07 UTC 2019
If we only have one API, renaming resolvePossiblyCachedConstantInPool to
resolveConstantInPool would make it more consistent with other resolve
methods. What do you think?
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