On Mon, 9 Aug 2021 13:13:33 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. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5052
