RFR: 8352565: Add native method implementation of Reference.get() [v6]

Vladimir Ivanov vlivanov at openjdk.org
Thu May 29 18:47:54 UTC 2025


On Thu, 29 May 2025 13:08:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> The current limitation of intrinsics support in C1/C2 is that intrinsics are always applied in the context of some method (as part of inlining). If a method is at the root of the compilation, it is never intrinsified.
>> 
>> The problem with virtual intrinsic methods is that when devirtualization fails, the call site ends up permanently calling into non-intrinsified version. That's what `refersTo0` initially suffered (fixed by JDK-8271862). `Reference::refersTo0` was virtual intrinsic method (no intrinsic when no inlining, hence call into native) and once it was untangled (virtual `refersToImpl` calls non-virtual intrinsic  method `refersTo0`) intrinsification happens reliably in the context of `refersToImpl`.
>
> We already have this to address that issue for the specific case of Reference.get:
> https://github.com/openjdk/jdk/blob/4cf729cfac57c9aec692a52c1f3f95f2403e7958/src/hotspot/share/opto/compile.cpp#L786-L792
> I think if we made the non-virtual native method be the intrinsic then we
> could remove that special handling? Maybe that's a good enough reason to cover
> the cost of renaming churn. Or maybe that's better done as a later cleanup?

Yes, I find it much cleaner when intrinsic is non-virtual.

> Or maybe that's better done as a later cleanup?

Up to you. I'm fine with the current PR if you remove the comment referring to C2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2114543162


More information about the hotspot-dev mailing list