On Tue, 10 Aug 2021 08:59:59 GMT, Per Liden <pli...@openjdk.org> wrote:
>> While fixing JDK-8270626 it was discovered that the C2 intrinsic for >> `Reference.refersTo()` is not used as often as one would think. Instead C2 >> often prefers using the native implementation, which is much slower which >> defeats the purpose of having an intrinsic in the first place. >> >> The problem arise from having `refersTo0()` be virtual, native and >> @IntrinsicCandidate. This can be worked around by introducing an virtual >> method layer and so that `refersTo0()` can be made `final`. That's what this >> patch does, by adding a virtual `refersToImpl()` which in turn calls the now >> final `refersTo0()`. >> >> It should be noted that `Object.clone()` and `Object.hashCode()` are also >> virtual, native and @IntrinsicCandidate and these methods get special >> treatment by C2 to get the intrinsic generated more optimally. We might want >> to do a similar optimization for `Reference.refersTo0()`. In that case, it >> is suggested that such an improvement could come later and be handled as a >> separate enhancement, and @kimbarrett has already filed JDK-8272140 to track >> that. >> >> Testing: >> I found this hard to test without instrumenting Hotspot to tell me that the >> intrinsic was called instead of the native method. So, for that reason >> testing was ad-hoc, using an instrumented Hotspot in combination with the >> test >> (`vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java`) >> that initially uncovered the problem. See JDK-8270626 for additional >> information. > > Per Liden has updated the pull request incrementally with one additional > commit since the last revision: > > Private implies final Thanks all for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/5052
