On Tue, 13 May 2025 16:37:12 GMT, Alan Bateman wrote:
>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 208:
>>
>>> 206: boolean shouldCreate = isTrue(env, "create");
>>> 207: if (shouldCreate && forceReadOnly) {
>>> 208: throw new IllegalArgumentEx
On Wed, 14 May 2025 06:32:30 GMT, Magnus Ihse Bursie wrote:
> That seems reasonable, yes. However, I'd like to keep this change to the
> absolute minimum. Feel free to open a separate issue for fixing this.
FIled: https://bugs.openjdk.org/browse/JDK-8356937
-
PR Review Comment: ht
On Thu, 17 Apr 2025 14:42:37 GMT, Magnus Ihse Bursie wrote:
> As part of the UTF-8 cleaning up done in
> [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where
> and how we are using unicode sequences (`\u`). In several string
> literals, I think the unicode sequence
On Tue, 13 May 2025 00:10:50 GMT, Sergey Bylokhov wrote:
>> A handful of html and xml files in the JDK source tree claims to have
>> encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>>
>> While perhaps technically correct, this is misleading, and goes contrary to
>> the
On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote:
> A handful of html and xml files in the JDK source tree claims to have
> encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>
> While perhaps technically correct, this is misleading, and goes contrary to
> the eff
> This is the implementation of the draft [JEP: Ahead-of-time Command Line
> Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT
> cache using the "one-command workflow"
> - Added processing of the `JAVA_AOT_OPT
On Wed, 7 May 2025 11:13:23 GMT, Jatin Bhateja wrote:
>> erifan 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 eight additional commits
>> sinc
On Fri, 9 May 2025 09:37:22 GMT, erifan wrote:
>> Yes, converting `VectorMask.fromLong(SPECIES, -1L)` to `MaskAll()` would be
>> better, and that will benefit AArch64 as well, since `MaskAll()` is much
>> more cheaper than `fromLong()` on AArch64. We can add such a transformation
>> with anoth
> This patch optimizes the following patterns:
> For integer types:
>
> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
> => (VectorMaskCmp src1 src2 ncond)
> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
> => (VectorMaskCmp src1 src2 ncond)
>
> cond can be eq, ne, le, ge, l
On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong wrote:
> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs
> for X86 platforms [1]. However, the current implementation is not optimal for
> AArch64 SVE platform, which natively supports vector instructions for subword
>
On Tue, 11 Mar 2025 14:23:02 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix an issue
> `java.util.zip.ZipFile` which would cause failures when multiple instances of
> `ZipFile` using non-UTF8 `Charset` were operating against the same underlying
> ZIP
On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix an issue
>> `java.util.zip.ZipFile` which would cause failures when multiple instances
>> of `ZipFile` using non-UTF8 `Charset` were operating against the same
>> underlying
On Tue, 13 May 2025 12:51:56 GMT, Thomas Stuefe wrote:
>> You are right and I am confused. I always assumed that the primary function
>> of jspawnhelper was to make vfork safe. Historically, that was the typical
>> reason for an intermediate exec() to a helper - basically, you first exec()
>>
On Mon, 12 May 2025 02:18:05 GMT, Chen Liang wrote:
> These two subclass audits in ObjectInputStream and ObjectOutputStream were
> only used when security managers are present, which is no longer the case in
> releases 24 and newer. Thus, we can remove these two redundant `ClassValue`
> and th
On Tue, 13 May 2025 03:15:25 GMT, Naoto Sato wrote:
>> With the introduction of `stdin.encoding`
>> ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance
>> for users to decode `System.in` would be desirable. Adding examples in the
>> field description would help.
>
> Nao
On Wed, 7 May 2025 09:25:30 GMT, Andrew Haley wrote:
>> Mohamed Issa has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add new set of cbrt micro-benchmarks
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 62:
>
>> 60: {
>> 61:
Please review this PR for skipping
jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the
context from https://bugs.openjdk.org/browse/JDK-8356904 description:
jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a
native test launcher executable, ex
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Update names
-
Changes:
- all: https://git
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Same optimization of previous commit
-
Chang
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
An optimization
-
Changes:
- all: https://
On Wed, 26 Mar 2025 20:31:07 GMT, Justin Lu wrote:
> Please review this PR which clarifies the behavior for integer and fraction
> limits in NumberFormat and implementing classes. An associated CSR is filed.
>
> There have been a few bugs submitted which indicate a misconception that
> these l
On Fri, 18 Apr 2025 02:25:24 GMT, Chen Liang wrote:
>> Vicente Romero has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 34 commits:
>>
>> - Merge branch 'master' into JDK-8354556
>> - Update src/jdk.compiler/share/classes/com/sun/
> 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 constructor parameter will be an object
> with a unique ident
On Tue, 13 May 2025 15:51:12 GMT, Alan Bateman wrote:
>> Volkan Yazici 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 nine additional
>> commit
On Wed, 7 May 2025 11:17:19 GMT, Volkan Yazici wrote:
>> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 302:
>>
>>> 300: * WARNING: This method does not perform any bound checks.
>>> 301: */
>>> 302: int countPositives(byte[] ba, int off, int len);
>>
>>
On Mon, May 12, 2025 at 12:00 PM Archie Cobbs
wrote:
> I would like to offer to do the following:
>
>- Change the title of this bug from "retrofit ArrayDeque to implement
>List" to "Add indexed get() and set() methods to ArrayDeque"
>
>
>- Propose a corresponding PR and CSR to add get
On Tue, 13 May 2025 12:34:01 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/io/InputStreamReader.java line 59:
>>
>>> 57: * new InputStreamReader(System.in,
>>> System.getProperty("stdin.encoding"));
>>> 58: * }
>>> 59: *
>>
>> There are several places in the sources that st
On Tue, 13 May 2025 16:21:36 GMT, Naoto Sato wrote:
>> How did you search for those sources? I searched for literal `System.in` and
>> my comments are the only ones I could find in the JDK.
>
> There are several locations in the jdk source (I simply grep'ed for `new
> InputStreamReader(System.i
On Sun, 11 May 2025 16:08:25 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 2828:
>>
>>> 2826: * assuming there are no leading zero ints.
>>> 2827: */
>>> 2828: private static int bitLength(int[] val, int len) {
>>
>> This should really be r
On Tue, 13 May 2025 00:30:08 GMT, Alexander Matveev
wrote:
> `openssl` from macOS will ignore `faketime` and as result expired
> certificates will not be generated correctly. By default we should use these
> tools from Homebrew.
This pull request has now been integrated.
Changeset: 1569925a
On Sun, 11 May 2025 16:12:38 GMT, fabioromano1 wrote:
>>> This should really be refactored to an instance method `bitLengthUnsigned`
>>> or `magBitCount`
>>
>> I would prefer `magBitLength` as a name, since `bitCount` is usually
>> referred to one's bit count. But before do this, I'd hear the
On Sun, 11 May 2025 16:00:55 GMT, Chen Liang wrote:
> This should really be refactored to an instance method `bitLengthUnsigned` or
> `magBitCount`
I would prefer `magBitLength` as a name, since `bitCount` is usually referred
to one's bit count. But before do this, I'd hear the opinion of @rgi
On Sat, 10 May 2025 16:41:17 GMT, fabioromano1 wrote:
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
src/java.base/share/classes/java/math/BigInteger.java line 2828:
> 2826: * assuming there are no leading zer
On Mon, 12 May 2025 01:46:25 GMT, David Schlosnagle wrote:
>> Some changes in `Biginteger`s' bit operations that increase the code
>> readability and slightly optimize the execution time.
>
> src/java.base/share/classes/java/math/BigInteger.java line 2642:
>
>> 2640: }
>> 2641:
On Mon, 12 May 2025 01:52:51 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 2642:
>>
>>> 2640: }
>>> 2641: // (this.abs().bitLength() - 1L) * exponent + 1L >
>>> Integer.MAX_VALUE
>>> 2642: if (scaleFactor + bitsToShift - exponent >=
On Mon, 12 May 2025 13:45:08 GMT, fabioromano1 wrote:
>> @fabioromano1 While reviewers can of course file JBS issues on behalf of
>> contributors, the recommende way is for the latter to file a [bug
>> report](https://bugreport.java.com/bugreport/), as they know what they will
>> work on bette
On Sat, 10 May 2025 16:41:17 GMT, fabioromano1 wrote:
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
src/java.base/share/classes/java/math/BigInteger.java line 2642:
> 2640: }
> 2641: // (this.abs()
On Sat, 10 May 2025 16:41:17 GMT, fabioromano1 wrote:
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
@fabioromano1 While reviewers can of course file JBS issues on behalf of
contributors, the recommende way is for
On Mon, 12 May 2025 13:13:36 GMT, Raffaello Giulietti
wrote:
>> Some changes in `Biginteger`s' bit operations that increase the code
>> readability and slightly optimize the execution time.
>
> @fabioromano1 While reviewers can of course file JBS issues on behalf of
> contributors, the recomme
Some changes in `Biginteger`s' bit operations that increase the code
readability and slightly optimize the execution time.
-
Commit messages:
- More clear comment
- An optimization
- Code simplification
- Code simplification
- Avoiding redundant code
- Code simplification
- Co
On Mon, 12 May 2025 18:24:27 GMT, Archie Cobbs wrote:
> Because it is backed by an array, the `ArrayDeque` class has the ability to
> get and replace any element in the list (accessed by index) in constant time.
> However, this capability is not exposed in the API.
>
> Please review this PR wh
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Code simplification
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24898/files
- new:
On Fri, 9 May 2025 23:23:27 GMT, Brent Christian wrote:
> For `java.lang` tests, use the `@requires` facility in place of checking the
> `os.name` system property or `File.separatorChar`.
>
> Automated test results are omitted as expected.
This pull request has now been integrated.
Changeset:
On Thu, 8 May 2025 18:07:42 GMT, Justin Lu wrote:
>> Please review this PR which clarifies the behavior for integer and fraction
>> limits in NumberFormat and implementing classes. An associated CSR is filed.
>>
>> There have been a few bugs submitted which indicate a misconception that
>> the
On Tue, 13 May 2025 16:26:31 GMT, Jaikiran Pai wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 208:
>
On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix an issue
>> `java.util.zip.ZipFile` which would cause failures when multiple instances
>> of `ZipFile` using non-UTF8 `Charset` were operating against the same
>> underlying
On Mon, 12 May 2025 10:16:33 GMT, David Beaumont wrote:
>> Adding read-only support to ZipFileSystem.
>>
>> The new `accessMode` environment property allows for readOnly and readWrite
>> values, and ensures that the requested mode is consistent with what's
>> returned.
>>
>> This involved a l
On Mon, 12 May 2025 09:39:48 GMT, Andrew Haley wrote:
> > Looking at the improvements made, I suggest we also change (in
> > `SegmentBulkOperations`):
> > ```
> > private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill",
> > Architecture.isAARCH64() ? 18 : 5);
> > ```
> > to
>
> This intrinsic is generally faster than the current implementation for Panama
> segment operations for all writes larger than about 8 bytes in size,
> increasing to more than 2* the performance on larger memory blocks on
> Graviton 2, between "panama" (C2 generated, what we use now) and "unsaf
On Tue, 13 May 2025 12:34:01 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/io/InputStreamReader.java line 59:
>>
>>> 57: * new InputStreamReader(System.in,
>>> System.getProperty("stdin.encoding"));
>>> 58: * }
>>> 59: *
>>
>> There are several places in the sources that st
On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOException`. So, if the
>> ap
On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici wrote:
>> Document preconditions on certain `JavaLangAccess` methods that use
>> operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request with a new target base due to a
> merge or a rebase. The incremen
Well, probably I formulated it not so clearly. I'd like to have the
following additions:
public interface Comparator {
...
default T max(T a, T b) {
return compare(a, b) > 0 ? a : b;
}
default T min(T a, T b) {
return compare(a, b) > 0 ? b : a;
}
stati
On Tue, 13 May 2025 10:55:50 GMT, Alan Bateman wrote:
>> Brian Burkhalter 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 21 additional
>> commi
On Tue, 13 May 2025 15:25:57 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/Reader.java line 430:
>>
>>> 428: * The behavior for the case where the reader is
>>> 429: * asynchronously closed, or the thread interrupted during
>>> the
>>> 430: * read, is highl
On Tue, 13 May 2025 14:47:53 GMT, Roger Riggs wrote:
> I think this (with fix above for stream -> reader) is ready to create the CSR
> ...
Will do today. Thanks.
-
PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2876983943
> Implement the requested methods and add a test thereof.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8354724: "stream" -> "reader"
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24728/files
- new: https:
Hello, Brian!
On Tue, May 13, 2025 at 4:30 PM Brian Goetz wrote:
> So with that as background, I am very cautious to consider adding methods to
> Comparable, because it is a highly abstract type that was designed for
> extension, and the risk of the above kind of clash seems "not low".
Sure, e
On Tue, 13 May 2025 08:58:28 GMT, ExE Boss wrote:
>> Because it is backed by an array, the `ArrayDeque` class has the ability to
>> get and replace any element in the list (accessed by index) in constant
>> time. However, this capability is not exposed in the API.
>>
>> Please review this PR w
On Mon, 12 May 2025 18:24:27 GMT, Archie Cobbs wrote:
> Because it is backed by an array, the `ArrayDeque` class has the ability to
> get and replace any element in the list (accessed by index) in constant time.
> However, this capability is not exposed in the API.
>
> Please review this PR wh
Because it is backed by an array, the `ArrayDeque` class has the ability to get
and replace any element in the list (accessed by index) in constant time.
However, this capability is not exposed in the API.
Please review this PR which adds the following two new methods to `ArrayDeque`:
* `public
On Mon, 12 May 2025 23:51:19 GMT, Brian Burkhalter wrote:
>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter 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 m
On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOException`. So, if the
>> ap
On Tue, 13 May 2025 13:56:37 GMT, Chen Liang wrote:
>> The recent patch #23866 makes calling `ClassValue::remove()` from
>> `ClassValue::computeValue()` end up in infinite loops while fixing the stale
>> value risk from the method.
>>
>> The proposed fix is to preserve the stale value risk fix
> From: "Brian Goetz"
> To: "Tagir Valeev" , "core-libs-dev"
>
> Sent: Tuesday, May 13, 2025 4:30:33 PM
> Subject: Re: Finding max or min of exactly two objects
> When we did Lambda, we made a few mistakes in the category of adding default
> methods to some "highly abstract" types, such as Funct
On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOException`. So, if the
>> ap
Hello!
Several times already when writing Java programs, I stumbled with a simple
task: given two objects with natural order, find the maximal of them. The
algorithm I need could be formulated like this:
> T max(T a, T b) {
return a.compareTo(b) > 0 ? a : b;
}
Writing manually co
On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY wrote:
>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Refactor container runtime version code
The change
On Tue, 13 May 2025 07:57:15 GMT, Per Minborg wrote:
>> This PR proposes to address comments in the initial PR for Stable Values,
>> which were deferred until after integration.
>>
>> Most of the efforts in this PR are to retain "stability" as long as possible
>> so that views of stable collec
On Tue, 13 May 2025 14:39:36 GMT, Luca Kellermann wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address comments
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 1732:
>
>> 1730:
When we did Lambda, we made a few mistakes in the category of adding
default methods to some "highly abstract" types, such as
Function::andThen. You were there; these were well-intentioned, but we
neglected to think sufficiently about the consequences for subclasses.
For example:
interf
> This intrinsic is generally faster than the current implementation for Panama
> segment operations for all writes larger than about 8 bytes in size,
> increasing to more than 2* the performance on larger memory blocks on
> Graviton 2, between "panama" (C2 generated, what we use now) and "unsaf
On Tue, 13 May 2025 03:06:44 GMT, Ioi Lam wrote:
>> This is the implementation of the draft [JEP: Ahead-of-time Command Line
>> Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>>
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT
>> cache using the "one-com
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with two additional
commits since the last revision:
- Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into
nth-root-branch
- Compute re
On Wed, 30 Apr 2025 16:06:23 GMT, Roger Riggs wrote:
>> Aleksey Shipilev 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 six additional
>> commi
On Mon, 12 May 2025 10:16:33 GMT, David Beaumont wrote:
>> Adding read-only support to ZipFileSystem.
>>
>> The new `accessMode` environment property allows for readOnly and readWrite
>> values, and ensures that the requested mode is consistent with what's
>> returned.
>>
>> This involved a l
On Fri, 2 May 2025 11:47:32 GMT, Raffaello Giulietti
wrote:
> Add `powExact()` and `unsignedPowExact()` methods that operate on integer
> values arguments.
> Further, add `unsignedMultiplyExact` methods as well.
This pull request has now been integrated.
Changeset: 64a858c7
Author:Raffael
On Tue, 13 May 2025 03:56:25 GMT, Hai-May Chao wrote:
> It is nice to refactor the common code for algorithm constraints checking
> into a new class, `X509KeyManagerConstraints.java`, used by both
> `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a
> new system propert
On Tue, 13 May 2025 13:31:25 GMT, Chen Liang wrote:
>> Not really: if you have an original token and a current token created during
>> the computeValue of the original token, they are compatible but not really
>> "equivalent" (i.e. the threadId case)
>
> Maybe `canAssociate`?
`allowsAssociatio
> The recent patch #23866 makes calling `ClassValue::remove()` from
> `ClassValue::computeValue()` end up in infinite loops while fixing the stale
> value risk from the method.
>
> The proposed fix is to preserve the stale value risk fix, and update the
> remove-from-compute behavior from the o
On Tue, 13 May 2025 13:34:38 GMT, Chen Liang wrote:
>> The recent patch #23866 makes calling `ClassValue::remove()` from
>> `ClassValue::computeValue()` end up in infinite loops while fixing the stale
>> value risk from the method.
>>
>> The proposed fix is to preserve the stale value risk fix
On Tue, 13 May 2025 13:28:27 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/ClassValue.java line 99:
>>
>>> 97: * that computed the value to associate. A new invocation to {@code
>>> 98: * computeValue}, which that {@code remove} call happens-before,
>>> happens to
>
On Mon, 12 May 2025 10:16:33 GMT, David Beaumont wrote:
>> Adding read-only support to ZipFileSystem.
>>
>> The new `accessMode` environment property allows for readOnly and readWrite
>> values, and ensures that the requested mode is consistent with what's
>> returned.
>>
>> This involved a l
On Tue, 13 May 2025 07:57:15 GMT, Per Minborg wrote:
>> This PR proposes to address comments in the initial PR for Stable Values,
>> which were deferred until after integration.
>>
>> Most of the efforts in this PR are to retain "stability" as long as possible
>> so that views of stable collec
On Fri, 2 May 2025 12:13:39 GMT, Per Minborg wrote:
> This PR proposes to address comments in the initial PR for Stable Values,
> which were deferred until after integration.
>
> Most of the efforts in this PR are to retain "stability" as long as possible
> so that views of stable collections
On Tue, 13 May 2025 12:47:12 GMT, Viktor Klang wrote:
>> Chen Liang 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 22 additional
>> commits sin
On Wed, 26 Feb 2025 19:46:41 GMT, Alan Bateman wrote:
> Data structures that are accessed by both virtual threads and their carriers
> require the virtual thread to pin the continuation to avoid potential
> deadlock. A deadlock can arise when a virtual thread is preempted, is
> selected and sc
On Sat, 10 May 2025 20:43:20 GMT, Chen Liang wrote:
>> The recent patch #23866 makes calling `ClassValue::remove()` from
>> `ClassValue::computeValue()` end up in infinite loops while fixing the stale
>> value risk from the method.
>>
>> The proposed fix is to preserve the stale value risk fix
On Tue, 13 May 2025 13:30:18 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/ClassValue.java line 348:
>>
>>> 346:
>>> 347: // Arguments are nullable, intentionally to allow initial
>>> tokens
>>> 348: static boolean areCompatible(RemovalToken current,
>>> Remo
> The recent patch #23866 makes calling `ClassValue::remove()` from
> `ClassValue::computeValue()` end up in infinite loops while fixing the stale
> value risk from the method.
>
> The proposed fix is to preserve the stale value risk fix, and update the
> remove-from-compute behavior from the o
On Mon, 12 May 2025 14:01:16 GMT, Alan Bateman wrote:
>> Data structures that are accessed by both virtual threads and their carriers
>> require the virtual thread to pin the continuation to avoid potential
>> deadlock. A deadlock can arise when a virtual thread is preempted, is
>> selected an
On Tue, 13 May 2025 12:44:38 GMT, Viktor Klang wrote:
> About a month or so.
Perfect, thanks @viktorklang-ora. I've marked the other issues as closed -
duplicates, and referenced this single umbrella PR.
-
PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2876484773
> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead
> of converting to decimal string and then parsing it. This results in an
> approximate 6x improvement for me.
Johannes Graham has updated the pull request incrementally with one additional
commit since the last revis
On Tue, 8 Apr 2025 18:39:30 GMT, kabutz wrote:
> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are
> dynamically created upon each insertion unless this would bring the deque
> above capacity." However, in the current implementation, nodes are always
> created, even if the de
Hi Markus,
A main point was to avoid trying to do everything at once.
The PR comments become hard to follow and intermingled and it takes
longer to get agreement because of the thrash in the PR.
Roger
On 5/13/25 5:05 AM, Markus KARG wrote:
Thank you, Roger.
Actually the method helps in the
On Wed, 5 Feb 2025 15:36:15 GMT, kabutz wrote:
> The LinkedBlockingDeque does not behave consistently with other concurrency
> components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with
> a thread that is interrupted, it does not immediately throw an
> InterruptedException,
On Mon, 7 Apr 2025 11:55:08 GMT, kabutz wrote:
> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by
> linking f.prev and f.next back to f, allowing the iterators to continue from
> the first or last respectively. This would be consistent with how the other
> node-based
On Tue, 8 Apr 2025 18:39:30 GMT, kabutz wrote:
> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are
> dynamically created upon each insertion unless this would bring the deque
> above capacity." However, in the current implementation, nodes are always
> created, even if the de
On Mon, 7 Apr 2025 11:55:08 GMT, kabutz wrote:
> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by
> linking f.prev and f.next back to f, allowing the iterators to continue from
> the first or last respectively. This would be consistent with how the other
> node-based
On Wed, 9 Apr 2025 06:24:30 GMT, kabutz wrote:
> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then
> add that chain in bulk to the existing nodes. We count the nodes in "int n"
> and then whilst holding the lock, we check that we haven't exceeded the
> capacity with
1 - 100 of 133 matches
Mail list logo
