On Fri, 30 May 2025 19:30:50 GMT, Vladimir Ivanov wrote:
>> Much of the point of this change is to let us later remove the interpreter/c1
>> intrinsics for this function. I think what you are saying is that might be
>> tricky if `get()` is the intrinsic. So maybe I should just go ahead now with
>
On Fri, 30 May 2025 11:25:01 GMT, Kim Barrett wrote:
> If get0() is the intrinsic, then I think that referenced snippet from the
Compile ctor can go away?
Yes.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2116517383
On Thu, 29 May 2025 18:45:20 GMT, Vladimir Ivanov wrote:
>> 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.
>
> FTR the special case in
On Thu, 29 May 2025 18:43:31 GMT, Vladimir Ivanov wrote:
>> 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
On Thu, 29 May 2025 13:08:25 GMT, Kim Barrett 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 prob
On Thu, 29 May 2025 01:14:30 GMT, Vladimir Ivanov wrote:
>> The comment is about why we have native `get0` at all, rather than just
>> making
>> `get` also be native.
>>
>>> [...] JDK-8271862 was about migrating to non-virtual intrinsic method.
>>
>> That's not a correct summary of JDK-8271862
On Sat, 24 May 2025 04:57:39 GMT, Kim Barrett wrote:
>> As I understand, `JDK-8271862` was about migrating to non-virtual intrinsic
>> method.
>> In case of `Reference::get()`, you already have a virtual public method
>> marked as `@IntrinsicCandidate`. And the patch doesn't change anything
>>
On Fri, 23 May 2025 23:01:02 GMT, Vladimir Ivanov wrote:
>> See review thread slightly above here, specifically
>> https://github.com/openjdk/jdk/pull/24315/files#r2094884157.
>> I've looked at the intrinsics for Object.clone() and Object.hashCode(), but
>> only enough to decide I
>> understand
On Tue, 20 May 2025 22:14:42 GMT, Kim Barrett wrote:
>> src/java.base/share/classes/java/lang/ref/Reference.java line 366:
>>
>>> 364:
>>> 365: /* Implementation of unintrinsified get(). Making get() native
>>> may lead
>>> 366: * C2 to sometimes prefer the native implementation over
On Tue, 20 May 2025 18:43:16 GMT, Vladimir Ivanov wrote:
>> Kim Barrett has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 10 additional
>> commits
On Fri, 9 May 2025 15:59:38 GMT, Kim Barrett wrote:
>> Please review this change which adds a native method providing the
>> implementation of Reference::get. Referece::get is an intrinsic candidate,
>> so
>> this native method implementation is only used when the intrinsic is not.
>>
>> Curre
> Please review this change which adds a native method providing the
> implementation of Reference::get. Referece::get is an intrinsic candidate, so
> this native method implementation is only used when the intrinsic is not.
>
> Currently there is intrinsic support by the interpreter, C1, C2, and
12 matches
Mail list logo
