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
On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing wrote:
>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert fix in the CTW Makefile.
Looks good.
-
On Tue, 24 Dec 2024 03:26:23 GMT, Qizheng Xing wrote:
>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with three additional
> commits since the last revision:
>
> - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.
On Tue, 24 Dec 2024 20:27:37 GMT, Kim Barrett wrote:
>> Hmm, apparently this is not run as part of tier 1-3, which I ran in my
>> patch. I wonder how this test is run. And it means this patch needs to be
>> backported to 24.
>
> Only this small piece would be approp
On Tue, 24 Dec 2024 15:45:24 GMT, Chen Liang wrote:
>> I've tested this by running `make`, and the previous Makefile reports an
>> error like file `test/lib/jtreg/SkippedException.java)` not found. So this
>> fix is necessary.
>>
>> I also checked the git log, this change was introduced in
>>
On Mon, 23 Dec 2024 19:33:36 GMT, Kim Barrett wrote:
> That makes it harder to review and to manage the review, because it is large
> and affects a wide range of areas, so may need many reviewers.
And many of the appropriate reviewers might be unavailable for a while, since
it's r
On Mon, 23 Dec 2024 09:45:00 GMT, Qizheng Xing wrote:
> This patch fixes unmatched brackets in some source files.
I strongly suggest avoiding omnibus changes like this when possible (which it
is here). Just because it's all about one "kind" of change doesn't make it a
cohesive change. This is to
On Fri, 13 Dec 2024 09:45:27 GMT, SendaoYan wrote:
> Can you try with add configure options `--enable-asan --enable-ubsan`
Does either asan or ubsan alone have this problem? I was under the impression
that using both at the same time could
lead to strange conflicts between them, but that's an
On 12/8/24 1:56 PM, Davide Perini wrote:
I tried attaching gdb, but it’s clear that jvm doesn’t like debuggers
attached. Right from the start it got sigstop handlers invoked, and
then a segfault in libjvm.
I can't comment on the rest of your message, but I might be able to help
with
this. T
On Thu, 28 Nov 2024 02:21:55 GMT, David Holmes wrote:
>> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783)
>> was integrated, the handling of certain symbol lookup code can be
>> simplified. The old code needed to support 32-bit Windows, where names had a
>> trailing `@
On Wed, 27 Nov 2024 05:20:16 GMT, David Holmes wrote:
>> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783)
>> was integrated, the handling of certain symbol lookup code can be
>> simplified. The old code needed to support 32-bit Windows, where names had a
>> trailing `@
On Fri, 8 Nov 2024 18:26:25 GMT, Saint Wesonga wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Inline buildJniFunctionName
>
> src/hotspot/os/posix/include/jvm_md.h line 41:
>
>> 39:
>> 40: #define JNI_ONLO
On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A
> future me chasing
On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Wed, 6 Nov 2024 15:27:16 GMT, Magnus Ihse Bursie wrote:
>> src/java.base/share/native/libjava/NativeLibraries.c line 67:
>>
>>> 65: strcat(jniEntryName, "_");
>>> 66: strcat(jniEntryName, cname);
>>> 67: }
>>
>> I would prefer this be directly inlined at the sole call (in
On Mon, 4 Nov 2024 20:42:59 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Mon, 4 Nov 2024 09:11:16 GMT, David Holmes wrote:
>> The deletion is apparently working, else we'd be getting build failures. So
>> while there are some potential issues and opportunities for further cleanup
>> in
>> this file, I think they ought to be addressed separately from this PR. See
>
On Mon, 4 Nov 2024 02:34:13 GMT, David Holmes wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove superfluous check for 64-bit on Windows in
>> MacroAssembler::call_clobbered_xmm_registers
>> - Remove
1 - 100 of 178 matches
Mail list logo
