On Sat, 12 Jul 2025 17:36:54 GMT, Matthias Baesken wrote:
>> The following is reported when building with the gcc static analyzer
>> (-fanalyzer) :
>>
>>
>> /jdk/src/java.base/unix/native/libjava/java_props_md.c:244:17: warning: leak
>> of 'temp' [CWE-401] [-Wanalyzer-malloc-leak]
>> 244 |
On Sat, 5 Jul 2025 00:05:39 GMT, Kim Barrett wrote:
> Please review this change that removes the class jdk.internal.ref.Cleaner.
> It is no longer used after JDK-8344332.
>
> Testing: mach5 tier1-3
This pull request has now been integrated.
Changeset: 117f0b40
Author: Kim
On Tue, 8 Jul 2025 04:59:04 GMT, Jaikiran Pai wrote:
>> Please review this change that removes the class jdk.internal.ref.Cleaner.
>> It is no longer used after JDK-8344332.
>>
>> Testing: mach5 tier1-3
>
> This looks OK to me and matches with what was discussed about this in a
> recent PR http
On Tue, 8 Jul 2025 04:59:04 GMT, Jaikiran Pai wrote:
>> Please review this change that removes the class jdk.internal.ref.Cleaner.
>> It is no longer used after JDK-8344332.
>>
>> Testing: mach5 tier1-3
>
> This looks OK to me and matches with what was discussed about this in a
> recent PR http
Please review this change that removes the class jdk.internal.ref.Cleaner.
It is no longer used after JDK-8344332.
Testing: mach5 tier1-3
-
Commit messages:
- remove jdk.internal.ref.Cleaner
Changes: https://git.openjdk.org/jdk/pull/26141/files
Webrev: https://webrevs.openjdk.org
On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett wrote:
> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed
On Fri, 4 Jul 2025 03:02:07 GMT, Roger Riggs wrote:
>> Kim Barrett has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - add @Override for clean() method
>> - more commentary for reserveMemory
>
> Ma
rences. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
>
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there
On Fri, 27 Jun 2025 17:43:34 GMT, Brent Christian 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 cont
On Fri, 27 Jun 2025 19:29:18 GMT, Brent Christian wrote:
>> I intentionally (re)used the "Cleaner" name to avoid a bunch of renames that
>> would increase the size of the change and distract from the meat of it. I
>> think the name to use might be affected by how the implementation of the set
>>
On Fri, 27 Jun 2025 21:06:03 GMT, Brent Christian 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 cont
On Fri, 27 Jun 2025 20:57:01 GMT, Brent Christian 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 cont
On Fri, 27 Jun 2025 20:21:07 GMT, Brent Christian 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 cont
On Fri, 27 Jun 2025 18:24:46 GMT, Brent Christian 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 cont
On Fri, 27 Jun 2025 01:03:30 GMT, Kim Barrett wrote:
>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165,
rences. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
>
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there
On Sat, 29 Mar 2025 21:47:18 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.
>
On Mon, 16 Jun 2025 07:09:39 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 w
rences. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
>
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there
insics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
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 1
On Wed, 4 Jun 2025 17:39:55 GMT, Chen Liang wrote:
>> Kim Barrett has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - add pseudo-native entry for Reference.get0
>> - tidy CallGenerator lookup in Compile c
On Fri, 6 Jun 2025 05:57:16 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 w
insics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
Kim Barrett has updated the pull request incrementally with two additional
commits since the last revision:
- add pseudo-native entry for Reference.get0
- tidy CallGenerator lookup in Compile ctor
--
insics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
Kim Barrett has updated the pull request incrementally with one additional
commit since the last revision:
fix comment alignment
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24315/fi
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
>
insics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
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 1
On Wed, 21 May 2025 05:42:34 GMT, Kim Barrett wrote:
>> Kim Barrett has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - add description of BufferCleaner class
>> - exception handling in cleaner for backw
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 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
rences. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
>
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there
insics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
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 1
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 Wed, 21 May 2025 02:36:16 GMT, Kim Barrett wrote:
>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165,
On Mon, 19 May 2025 19:16:14 GMT, Roger Riggs wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Buffer
rences. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
>
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there i
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 cont
On Mon, 19 May 2025 19:08:31 GMT, Roger Riggs wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio
On Mon, 19 May 2025 19:24:57 GMT, Roger Riggs wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Direct-
On Mon, 19 May 2025 19:27:27 GMT, Roger Riggs wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/sun/nio/
On Mon, 19 May 2025 18:30:45 GMT, ExE Boss wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio
On Mon, 19 May 2025 19:37:58 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 209:
>>
>>> 207: super(-1, 0, cap, cap, fd, isSync, segment);
>>> 208: address = addr;
>>> 209:cleaner = (unmapper == null) ? null :
>>> Buffer
On Fri, 11 Apr 2025 10:52:03 GMT, Aleksey Shipilev wrote:
>> As far as I can tell, intrinsic selection only applies when the call target
>> is
>> exactly the intrinsically attributed method. (Possibly after optimizations
>> that lead to a call to that specific method.) And that's obviously neces
On Sun, 18 May 2025 12:11:21 GMT, Alan Bateman wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/jdk/int
On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett wrote:
> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed
rences. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
>
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find ther
This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
use java.lang.ref.Cleaner.
This change is algorithmically similar
On Sat, 10 May 2025 20:28:39 GMT, Vicente Romero wrote:
>> This PR is defining a new internal annotation,
>> `@jdk.internal.RequiresIdentity`, with target types PARAMETER and
>> TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation
>> that an argument to a given method or
On Fri, 11 Apr 2025 08:14:29 GMT, Kim Barrett wrote:
>> test/hotspot/jtreg/gc/TestNativeReferenceGet.java line 137:
>>
>>> 135: }
>>> 136: checkQueue(); // One last check after refproc
>>> complete.
>>> 137:
insics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
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 1
insics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
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 nin
On Sun, 4 May 2025 03:49:44 GMT, Brent Christian wrote:
> Right now, the test just it prints a single line: `waitForReferenceProcessing
> returned: false` and I expect this to continue to be true.
If reference processing is being slow because of load, that will be different.
> For intermittent
On Thu, 1 May 2025 21:47:01 GMT, Brent Christian wrote:
>> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear
>> up the intermittent failures:
>>
>> * run with `othervm`: this test blocks the (global) finalizer thread, and
>> also requires the (global) finalizer thread
On Thu, 1 May 2025 21:47:01 GMT, Brent Christian wrote:
>> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear
>> up the intermittent failures:
>>
>> * run with `othervm`: this test blocks the (global) finalizer thread, and
>> also requires the (global) finalizer thread
On Tue, 18 Feb 2025 14:33:16 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Wed, 30 Apr 2025 20:23:13 GMT, Brent Christian wrote:
> It spins until at least one `MyObject` has entered `finalize()` before
> proceeding to fetch the histogram.
My eyes must be going. Somehow I read that as a `-1`.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/24143
On Thu, 1 May 2025 19:17:42 GMT, Kim Barrett wrote:
>> It spins until at least one `MyObject` has entered `finalize()` before
>> proceeding to fetch the histogram.
>
>> It spins until at least one `MyObject` has entered `finalize()` before
>> proceeding to fetch
On Wed, 30 Apr 2025 14:29:45 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 353:
>>
>>> 351: for (ReferenceKey key : map.keySet()) {
>>> 352: Object referent = key.get();
>>> 353: if (referent == null) {
>>
>> S
On Wed, 30 Apr 2025 00:56:19 GMT, Ioi Lam wrote:
>> This PR contains 2 parts
>>
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the
>> Leyden
>> repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjS
On Tue, 29 Apr 2025 22:46:22 GMT, Brent Christian wrote:
>> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear
>> up the intermittent failures:
>>
>> * run with `othervm`: this test blocks the (global) finalizer thread, and
>> also requires the (global) finalizer threa
On Mon, 28 Apr 2025 19:21:05 GMT, Brent Christian wrote:
>> The newly-added `WhiteBox.waitForReferenceProcessing()` (see
>> [8305186](https://bugs.openjdk.org/browse/JDK-8305186)) always fails with
>> assertions enabled.
>> I've updated the assertion, and also added the test I used locally to t
On Fri, 25 Apr 2025 21:30:10 GMT, Brent Christian wrote:
>> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear
>> up the intermittent failures:
>>
>> * run with `othervm`: this test blocks the (global) finalizer thread, and
>> also requires the (global) finalizer threa
On Fri, 25 Apr 2025 23:37:13 GMT, Brent Christian wrote:
> The newly-added `WhiteBox.waitForReferenceProcessing()` (see
> [8305186](https://bugs.openjdk.org/browse/JDK-8305186)) always fails with
> assertions enabled.
> I've updated the assertion, and also added the test I used locally to test
On Sat, 26 Apr 2025 09:18:35 GMT, Kim Barrett wrote:
>> The newly-added `WhiteBox.waitForReferenceProcessing()` (see
>> [8305186](https://bugs.openjdk.org/browse/JDK-8305186)) always fails with
>> assertions enabled.
>> I've updated the assertion, and also added th
On Wed, 23 Apr 2025 17:45:29 GMT, Brent Christian wrote:
>> Certain specific types of tests involving GC and reference processing need
>> to account for the delay between a GC completing (during which the GC clears
>> a Reference), and the Reference being added to its associated queue. At
>> p
On Wed, 23 Apr 2025 00:23:57 GMT, Brent Christian wrote:
>> Certain specific types of tests involving GC and reference processing need
>> to account for the delay between a GC completing (during which the GC clears
>> a Reference), and the Reference being added to its associated queue. At
>> p
On Tue, 15 Apr 2025 05:50:03 GMT, Jaikiran Pai wrote:
> Can I please get a review of this cleanup in the jtreg timeout handler
> `GatherProcessInfoTimeoutHandler`?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8354565, this is a leftover
> after the change done in https://bugs.openjdk.ja
On Tue, 15 Apr 2025 00:00:35 GMT, Hans Boehm wrote:
> > Racy initialization is fine, the field can be static and the last one (any
> > racy init would all the same) wins:
>
> How did you conclude that? From what I can see, Method has non-final fields.
> If another thread reads waitForReferenceP
On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` that is shipped with
On Fri, 11 Apr 2025 23:31:16 GMT, Brent Christian wrote:
>> Certain specific types of tests involving GC and reference processing need
>> to account for the delay between a GC completing (during which the GC clears
>> a Reference), and the Reference being added to its associated queue. At
>> p
On Sat, 12 Apr 2025 05:47:06 GMT, Kim Barrett wrote:
>> Brent Christian has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Make *the method* static, also
>> - Make Method static
>
> test/lib/jdk/
On Sun, 13 Apr 2025 23:14:41 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` that is shipped with
On Fri, 11 Apr 2025 23:31:16 GMT, Brent Christian wrote:
>> Certain specific types of tests involving GC and reference processing need
>> to account for the delay between a GC completing (during which the GC clears
>> a Reference), and the Reference being added to its associated queue. At
>> p
On Fri, 11 Apr 2025 23:26:45 GMT, Brent Christian wrote:
>> test/lib/jdk/test/whitebox/WhiteBox.java line 568:
>>
>>> 566: private Method getWaitForReferenceProcessingMethod() {
>>> 567: Method wfrp = waitForReferenceProcessingMethod;
>>> 568: if (wfrp == null) {
>>
>> Racy initializa
On Fri, 11 Apr 2025 08:51:56 GMT, Aleksey Shipilev wrote:
>> I think it would be "easier" to shift `@IntrinsicCandidate` to a private
>> `Reference.getImpl/get0` pair of methods, and intrinsify one of those
>> instead. Pretty much like current `clear` and `refersTo` are doing it now.
>> And it
On Wed, 2 Apr 2025 18:38:17 GMT, Kim Barrett wrote:
>> Kim Barrett has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - remove timeout by using waitForReferenceProcessing
>> - make ill-timed gc in n
On Thu, 10 Apr 2025 22:24:04 GMT, Brent Christian wrote:
>> Certain specific types of tests involving GC and reference processing need
>> to account for the delay between a GC completing (during which the GC clears
>> a Reference), and the Reference being added to its associated queue. At
>> p
On Wed, 9 Apr 2025 23:12:00 GMT, Brent Christian wrote:
>> Certain specific types of tests involving GC and reference processing need
>> to account for the delay between a GC completing (during which the GC clears
>> a Reference), and the Reference being added to its associated queue. At
>> pr
On Wed, 9 Apr 2025 19:54:55 GMT, Brent Christian wrote:
>> Certain specific types of tests involving GC and reference processing need
>> to account for the delay between a GC completing (during which the GC clears
>> a Reference), and the Reference being added to its associated queue. At
>> pr
On Tue, 8 Apr 2025 20:20:56 GMT, Brent Christian wrote:
> Certain specific types of tests involving GC and reference processing need to
> account for the delay between a GC completing (during which the GC clears a
> Reference), and the Reference being added to its associated queue. At
> presen
insics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
Kim Barrett has updated the pull request incrementally with one additional
commit since the last revision:
add package decl to test
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24315/fi
On Tue, 1 Apr 2025 22:01:55 GMT, Brent Christian wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> parameterized return type of native get0
>
> test/hotspot/jtreg/gc/TestNativeReferen
On Wed, 2 Apr 2025 18:33:16 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 w
insics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
Kim Barrett has updated the pull request incrementally with three additional
commits since the last revision:
- remove timeout by using waitForReferenceProcessing
- make ill-timed gc in non-concurrent case
On Tue, 1 Apr 2025 01:54:13 GMT, Chen Liang wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> parameterized return type of native get0
>
> src/java.base/share/classes/java/lang/ref/Refe
insics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
Kim Barrett has updated the pull request incrementally with one additional
commit since the last revision:
parameterized return type of native get0
-
Changes:
- all: https://git.openjdk.org
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 graal,
wh
On Mon, 17 Mar 2025 17:22:10 GMT, Kim Barrett wrote:
>> Please review this revision of a previously puzzling comment intending to
>> provide the rationale for a bit of non-obvious code.
>
> Kim Barrett has updated the pull request incrementally with one additional
>
On Fri, 7 Mar 2025 23:17:53 GMT, Kim Barrett wrote:
> Please review this revision of a previously puzzling comment intending to
> provide the rationale for a bit of non-obvious code.
This pull request has now been integrated.
Changeset: 355b2f3b
Author: Kim Barrett
URL:
> Please review this revision of a previously puzzling comment intending to
> provide the rationale for a bit of non-obvious code.
Kim Barrett has updated the pull request incrementally with one additional
commit since the last revision:
bchristi-git review
-
Changes:
On Mon, 10 Mar 2025 23:14:23 GMT, Brent Christian wrote:
>> Please review this revision of a previously puzzling comment intending to
>> provide the rationale for a bit of non-obvious code.
>
> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 142:
>
>> 140: // w
Please review this revision of a previously puzzling comment intending to
provide the rationale for a bit of non-obvious code.
-
Commit messages:
- improve comment
Changes: https://git.openjdk.org/jdk/pull/23952/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23952&range=00
On Mon, 24 Feb 2025 07:25:41 GMT, Alan Bateman wrote:
> If you are suggesting exposing this as a public API then I don't think we
> should do this,
Not at this time, quite possibly never. As mentioned, I made some things
public for ease of prototyping.
I even commented it as such.
> I actual
On Mon, 24 Feb 2025 05:50:40 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only change which proposes to address
> an intermittent failure in the
> `test/jdk/java/util/zip/ZipFile/TestCleaner.java` test?
>
> This test does operations on Inflater/Deflater/ZipFile and closes
On Tue, 18 Feb 2025 14:33:16 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Tue, 18 Feb 2025 14:33:16 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Mon, 10 Feb 2025 09:28:45 GMT, Aleksey Shipilev wrote:
>> @AlanBateman I've not done any work on JDK-8305186. There has also been
>> discussion about making
>> that function non-private or even public (though with concerns about
>> specification difficulty) for use in
>> places like this.
>
On Thu, 30 Jan 2025 08:36:34 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/nio/Bits.java line 146:
>>
>>> 144: }
>>> 145:
>>> 146: if (canary == null || canary.isDead()) {
>>
>> If we're keeping Reference.waitForPendingReferences, why not continue
On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Sat, 25 Jan 2025 07:14:51 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
1 - 100 of 196 matches
Mail list logo
