On Thu, 8 May 2025 00:19:17 GMT, Calvin Cheung wrote:
> This fix adds the `--add-reads` support for CDS and AOTClassLinking.
> Before the fix, if the `--add-reads` is specified during CDS archive dumping,
> the user will see the following log if `-Xlog:cds=info` is enabled:
> `[0.000s][info][cds
On Wed, 7 May 2025 11:02:43 GMT, Jatin Bhateja wrote:
>> Hi @jatin-bhateja It is feasible. But I was thinking about whether another
>> solution would be better, which is to turn `VectorMask.fromLong(SPECIES,
>> -1L)` into `MaskAll(true)` in the mid-end. In this way, we don't need to
>> check
On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG wrote:
> This Pull Request proposes an implementation for
> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
> dstBegin)` to the `CharSequence` inter
This fix adds the `--add-reads` support for CDS and AOTClassLinking.
Before the fix, if the `--add-reads` is specified during CDS archive dumping,
the user will see the following log if `-Xlog:cds=info` is enabled:
`[0.000s][info][cds] optimized module handling: disabled due to incompatible
prope
On Wed, 7 May 2025 23:21:20 GMT, Benjamin Peterson wrote:
> > So is it correct to say that the link resolution appears correct but
> > `LoadLibrary`'s quirks cause the intended behavior to fail?
>
> Yes. The `getCanonicalPath` canonicalization indeed produces the file pointed
> to by the symli
On Wed, 7 May 2025 23:02:41 GMT, Brian Burkhalter wrote:
> > > > At this point, the path to load will be `$PWD\rando` due to symlink
> > > > resolution.
> > >
> > >
> > > Which is in fact correct, no?
> >
> >
> > Correct in that that's the library that should be loaded. `LoadLibrary`
> > do
On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs wrote:
>> Refactor AbstractStringBuilder to maintain consistency among count, coder,
>> and value buffers while the buffer capacity is being expanded and/or
>> inflated from Latin1 to UTF16 representations.
>> The refactoring pattern is to read and
On Wed, 7 May 2025 21:47:37 GMT, Benjamin Peterson wrote:
> > > At this point, the path to load will be `$PWD\rando` due to symlink
> > > resolution.
> >
> >
> > Which is in fact correct, no?
>
> Correct in that that's the library that should be loaded. `LoadLibrary`
> doesn't want to cooper
On Wed, 7 May 2025 02:07:03 GMT, Alexander Matveev wrote:
>> - Symbolic links will not be followed for `--app-content` on all platforms.
>> - Added test to cover this case.
>> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG,
>> since "cp -r" on macOS is not documented
On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs wrote:
>> Refactor AbstractStringBuilder to maintain consistency among count, coder,
>> and value buffers while the buffer capacity is being expanded and/or
>> inflated from Latin1 to UTF16 representations.
>> The refactoring pattern is to read and
On Fri, 2 May 2025 15:28:39 GMT, Raffaello Giulietti
wrote:
>> If I understand correctly, we are talking about several (primitive) array
>> type fields having a `@Stable` annotation, in a single class, right? So we
>> aren't really talking about levels?
>> If so, given what `@Stable` is docume
On Wed, 7 May 2025 21:19:41 GMT, Brian Burkhalter wrote:
> > > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value
> > > .\rando
>
> What if instead this were the following
>
> ```
> > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value
> > .\rando.dll
> ```
On Wed, 7 May 2025 19:21:38 GMT, Benjamin Peterson wrote:
> > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando
What if instead this were the following
> New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value
> .\rando.dll
where `.dll` is appended to t
On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourgès wrote:
>> * improved mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and
>> has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>>
On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote:
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
> called on the target library file before it was passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote:
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
> called on the target library file before it was passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Wed, 7 May 2025 16:17:07 GMT, Joe Wang wrote:
> This is a refactor patch, no change in functionality.
>
> This patch refactor the configuration code. Rather than for each factory to
> go through the whole configuration process, a base configuration as
> represented in JdkXmlConfig is create
On Wed, 7 May 2025 11:57:02 GMT, Aggelos Biboudis
wrote:
> While the compiler does not allow invalid queries to flow into
> `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch`
> does not prevent such usage pattern errors resulting in erroneous evaluation.
>
> For exam
On Wed, 7 May 2025 17:28:23 GMT, Alan Bateman wrote:
> Are you the submitter of JDK-8348828?
Yes, I am.
> Asking because the configuration described seems very unusual and sounds like
> something that changed the JDK image so the DLLs from the JDK bin directory
> are moved to somewhere else a
On Wed, 7 May 2025 07:52:37 GMT, Alan Bateman wrote:
>> Volkan Yazici has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typo in pre-existing JavaDoc
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 332:
>
>
On Sun, 4 May 2025 22:37:21 GMT, Chen Liang wrote:
> Credit to @lukellmann that the duplication arg handling in #24742 avoided
> throwing exceptions but produced a wrong option. This patch fixes that and
> removed stream usages in CaptureCallState to speed up bootstrap.
>
> Also, the previous
> Document preconditions on certain `JavaLangAccess` methods that use
> operations either unsafe and/or without range checks.
Volkan Yazici has updated the pull request incrementally with one additional
commit since the last revision:
Prefix touched methods with `unchecked`
-
Ch
On Wed, 7 May 2025 13:22:11 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 355:
>>
>>> 353: * UTF-16 representation.
>>> 354: *
>>> 355: * WARNING: This method does not perform any bound checks.
>>
>> Maybe not this P
On Wed, 7 May 2025 18:10:36 GMT, Raffaello Giulietti
wrote:
> I mean, if B strictly implies A, then B is more restrictive (stronger). Since
> B is equivalent to your original formulation, to me it means that it was more
> restrictive.
Exactly.
-
PR Review Comment: https://git.op
> 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
> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
> `pow()` is not concerned most on execution time, but rather in memory
> optimization, because the PR implementation does the "shift of the exponent"
> squaring the result rather than the base, so the base is not squar
On Tue, 6 May 2025 22:11:49 GMT, Chen Liang wrote:
>> Credit to @lukellmann that the duplication arg handling in #24742 avoided
>> throwing exceptions but produced a wrong option. This patch fixes that and
>> removed stream usages in CaptureCallState to speed up bootstrap.
>>
>> Also, the prev
On Wed, 7 May 2025 16:36:09 GMT, Chen Liang wrote:
>> While the compiler does not allow invalid queries to flow into
>> `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch`
>> does not prevent such usage pattern errors resulting in erroneous evaluation.
>>
>> For exampl
On Wed, 7 May 2025 18:01:24 GMT, fabioromano1 wrote:
>> OK.
>>
>> But then your original expression
>>
>> (((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH
>>
>> was a bit too restrictive as well, right?
>
>> OK.
>>
>> But then your original expression
>>
>> ```
>> (((bitLength()
On Wed, 7 May 2025 17:58:11 GMT, Raffaello Giulietti
wrote:
> OK.
>
> But then your original expression
>
> ```
> (((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH
> ```
>
> was a bit too restrictive as well, right?
On the contrary, it was too loose, as it admitted a bit length
On Wed, 7 May 2025 17:13:19 GMT, Lance Andersen wrote:
>> Henry Jen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Restore Validator access level
>
> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 127:
>
>> 125:
>> 12
On Wed, 7 May 2025 17:51:05 GMT, fabioromano1 wrote:
>> At some point you proposed
>>
>> (bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5
>>
>> Given the value of `MAX_MAG_LENGTH`, which is 2^26, this is equivalent to
>>
>> (bitLength() - 1L) * exponent >= 1L << 31
>>
>> that is, t
On Wed, 7 May 2025 17:43:30 GMT, Raffaello Giulietti
wrote:
>>> Ah right, but you probably want
>>
>> No, the sufficient condition to get the overflow is `(bitLength() - 1L) *
>> exponent + 1L > Integer.MAX_VALUE`, which is equivalent to that one I wrote
>> above.
>
> At some point you propos
On Tue, 6 May 2025 18:21:30 GMT, Henry Jen wrote:
>> This PR check the jar file to ensure entries are consistent from the central
>> directory and local file header. Also check there is no duplicate entry
>> names that could override the desired content by accident.
>
> Henry Jen has updated th
On Wed, 7 May 2025 17:34:27 GMT, fabioromano1 wrote:
>> Ah right, but you probably want
>> Suggestion:
>>
>> if ((bitLength() - 1L) * exponent > Integer.MAX_VALUE) {
>>
>> I mean `>` rather than `>=`
>
>> Ah right, but you probably want
>
> No, the sufficient condition to get the o
On Wed, 7 May 2025 17:32:06 GMT, Raffaello Giulietti
wrote:
> Ah right, but you probably want
No, the sufficient condition to get the overflow is `(bitLength() - 1L) *
exponent + 1L > Integer.MAX_VALUE`, which is equivalent to that one I wrote
above.
-
PR Review Comment: https:/
On Wed, 7 May 2025 17:14:19 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 2643:
>>
>>> 2641: : new BigInteger(result,
>>> newSign).shiftLeft(bitsToShift);
>>> 2642: } else {
>>> 2643: if ((bitLength() - 1L) * expon
On Wed, 7 May 2025 07:52:22 GMT, Per Minborg wrote:
> This PR proposes to skip a stress test if the `main` thread is a virtual
> thread.
This pull request has now been integrated.
Changeset: 1bdff3cc
Author:Per Minborg
URL:
https://git.openjdk.org/jdk/commit/1bdff3ccd069142e21c8b0a
On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote:
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
> called on the target library file before it was passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Mon, 28 Apr 2025 17:44:31 GMT, Benjamin Peterson wrote:
>> This issue has the "oca" label so we cannot engage, sorry.
>
>> This issue has the "oca" label so we cannot engage, sorry.
>
> Ah, sorry. I only asked because I saw a colleague of yours helping out with
> OCA verification over at
>
On Mon, 28 Apr 2025 16:42:35 GMT, Alan Bateman wrote:
> This issue has the "oca" label so we cannot engage, sorry.
Ah, sorry. I only asked because I saw a colleague of yours helping out with OCA
verification over at
https://github.com/openjdk/jdk/pull/23905#issuecomment-2762865417. Also, the
On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote:
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
> called on the target library file before it was passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote:
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
> called on the target library file before it was passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
called on the target library file before it was passed to the system library
loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
symlinks on Windows. This had unintended consequences for passing a
On Wed, 7 May 2025 15:38:41 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed needless brackets
>
> src/java.base/share/classes/java/math/BigInteger.java line 2643:
>
>> 2641:
On Wed, 7 May 2025 16:56:47 GMT, Naoto Sato wrote:
> Simple clarification of the `Console.charset()` method description, making
> explicit how the charset is applied.
Looks all right to me.
-
Marked as reviewed by bpb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/25103#
Simple clarification of the `Console.charset()` method description, making
explicit how the charset is applied.
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/25103/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25103&range=00
Issue: https
On Wed, 7 May 2025 10:43:55 GMT, kabutz wrote:
>> @kabutz Thanks for opening this PR—just confirming that it's on my to-review
>> queue.
>
> @viktorklang-ora any idea whom else we can ask to approve this PR?
> @kabutz I think @AlanBateman might be able to have a look as well.
>
> As for timing
On Wed, 7 May 2025 05:11:01 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-comm
On Wed, 7 May 2025 11:57:02 GMT, Aggelos Biboudis
wrote:
> While the compiler does not allow invalid queries to flow into
> `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch`
> does not prevent such usage pattern errors resulting in erroneous evaluation.
>
> For exam
On Wed, 7 May 2025 12:56:20 GMT, Chen Liang wrote:
> I guess a better approach may be to allow periodical reminders if a thread
> gets no reply - many of us gets quite a few hundred mails every day on
> workdays.
I think it is time to move this discussion into its own thread, but just a last
On Tue, 6 May 2025 20:52:34 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegin)` to the `CharSequence` in
On Tue, 6 May 2025 20:52:34 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegin)` to the `CharSequence` in
This is a refactor patch, no change in functionality.
This patch refactor the configuration code. Rather than for each factory to go
through the whole configuration process, a base configuration as represented in
JdkXmlConfig is created once, which includes loading of the JAXP Configuration
fil
On Tue, 6 May 2025 20:52:34 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegin)` to the `CharSequence` in
On Wed, 7 May 2025 15:46:16 GMT, Raffaello Giulietti
wrote:
> Did you make sure that the existing tests also cover the `unsignedLongPow()`
> sufficiently well?
@rgiulietti There are already the tests for `BigInteger`'s
[pow](https://github.com/fabioromano1/jdk/blob/BigInteger-nth-root/test/jd
While the compiler does not allow invalid queries to flow into
`SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch`
does not prevent such usage pattern errors resulting in erroneous evaluation.
For example this is not valid Java (and protected) by javac:
byte b = 1;
swi
> This sketch shows how "Stable Updaters" can be used to create stable
> computations of `@Stable` fields. Only one updater is needed per class,
> similar to `AtomicIntegerFieldUpdater`.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
On Wed, 7 May 2025 15:28:59 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed needless brackets
>
> src/java.base/share/classes/java/math/BigInteger.java line 2607:
>
>> 2605:
>> 2
On Wed, 7 May 2025 15:03:36 GMT, fabioromano1 wrote:
>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
>> `pow()` is not concerned most on execution time, but rather in memory
>> optimization, because the PR implementation does the "shift of the exponent"
>> squarin
> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
> `pow()` is not concerned most on execution time, but rather in memory
> optimization, because the PR implementation does the "shift of the exponent"
> squaring the result rather than the base, so the base is not squar
On Wed, 7 May 2025 15:03:36 GMT, fabioromano1 wrote:
>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
>> `pow()` is not concerned most on execution time, but rather in memory
>> optimization, because the PR implementation does the "shift of the exponent"
>> squarin
On Wed, 7 May 2025 15:03:36 GMT, fabioromano1 wrote:
>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
>> `pow()` is not concerned most on execution time, but rather in memory
>> optimization, because the PR implementation does the "shift of the exponent"
>> squarin
On Wed, 7 May 2025 06:06:08 GMT, Alan Bateman wrote:
> I assume the CSR will be expanded, e.g. to list deleteOnExit
Done.
-
PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2859058406
On Wed, 7 May 2025 15:03:57 GMT, Per Minborg wrote:
>> This sketch shows how "Stable Updaters" can be used to create stable
>> computations of `@Stable` fields. Only one updater is needed per class,
>> similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incremen
> This sketch shows how "Stable Updaters" can be used to create stable
> computations of `@Stable` fields. Only one updater is needed per class,
> similar to `AtomicIntegerFieldUpdater`.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
On Wed, 7 May 2025 14:58:33 GMT, Per Minborg wrote:
>> This sketch shows how "Stable Updaters" can be used to create stable
>> computations of `@Stable` fields. Only one updater is needed per class,
>> similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incremen
> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
> `pow()` is not concerned most on execution time, but rather in memory
> optimization, because the PR implementation does the "shift of the exponent"
> squaring the result rather than the base, so the base is not squar
> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
> `pow()` is not concerned most on execution time, but rather in memory
> optimization, because the PR implementation does the "shift of the exponent"
> squaring the result rather than the base, so the base is not squar
On Mon, 28 Apr 2025 20:50:58 GMT, Chen Liang wrote:
> Some dynamic constant pool entries with heavy symbolic descriptors currently
> don't share them, yet they are used by stack map generation, and computing a
> new descriptor every time introduces a heavy cost.
>
> This cost is obvious if byt
On Wed, 7 May 2025 09:23:45 GMT, Per Minborg wrote:
>> This sketch shows how "Stable Updaters" can be used to create stable
>> computations of `@Stable` fields. Only one updater is needed per class,
>> similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incremen
On Mon, 28 Apr 2025 20:50:58 GMT, Chen Liang wrote:
> Some dynamic constant pool entries with heavy symbolic descriptors currently
> don't share them, yet they are used by stack map generation, and computing a
> new descriptor every time introduces a heavy cost.
>
> This cost is obvious if byt
On Wed, 7 May 2025 07:34:32 GMT, Shaojin Wen wrote:
>> Jaikiran Pai has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 16 commits:
>>
>> - merge latest from master branch
>> - merge latest from master branch
>> - merge latest from
> This sketch shows how "Stable Updaters" can be used to create stable
> computations of `@Stable` fields. Only one updater is needed per class,
> similar to `AtomicIntegerFieldUpdater`.
Per Minborg has updated the pull request with a new target base due to a merge
or a rebase. The incremental
On Wed, 7 May 2025 11:54:09 GMT, David Beaumont wrote:
>> Per Minborg has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Reformat
>> - Revert changes in public classes
>
> test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java
On Wed, 7 May 2025 08:02:28 GMT, Alan Bateman wrote:
>> Volkan Yazici has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typo in pre-existing JavaDoc
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 355:
>
>
> This sketch shows how "Stable Updaters" can be used to create stable
> computations of `@Stable` fields. Only one updater is needed per class,
> similar to `AtomicIntegerFieldUpdater`.
Per Minborg has updated the pull request incrementally with two additional
commits since the last revision:
On Wed, 7 May 2025 12:57:13 GMT, Chen Liang wrote:
>> test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 72:
>>
>>> 70:
>>> 71: new Runner(opt).run();
>>> 72: }
>>
>> There's no need for these lines.
>
> These are here for convenience when a benchmark is run standalone.
On Wed, 7 May 2025 11:45:14 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplify long power computing
>
> test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 72:
>
>> 70:
On Sun, 4 May 2025 16:21:41 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new
>> method `public static Writer Writer.of(StringBuilder)`, providing a
>> non-synchronized Writer implementatio
On Wed, 7 May 2025 10:43:55 GMT, kabutz wrote:
>> @kabutz Thanks for opening this PR—just confirming that it's on my to-review
>> queue.
>
> @viktorklang-ora any idea whom else we can ask to approve this PR?
@kabutz I think @AlanBateman might be able to have a look as well.
As for timing, it s
On Wed, 30 Apr 2025 15:59:05 GMT, fabioromano1 wrote:
>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
>> `pow()` is not concerned most on execution time, but rather in memory
>> optimization, because the PR implementation does the "shift of the exponent"
>> squari
On Wed, 7 May 2025 09:23:45 GMT, Per Minborg wrote:
>> This sketch shows how "Stable Updaters" can be used to create stable
>> computations of `@Stable` fields. Only one updater is needed per class,
>> similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incremen
On Wed, 30 Apr 2025 15:59:05 GMT, fabioromano1 wrote:
>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
>> `pow()` is not concerned most on execution time, but rather in memory
>> optimization, because the PR implementation does the "shift of the exponent"
>> squari
On Wed, 7 May 2025 07:37:48 GMT, Alan Bateman wrote:
>> Volkan Yazici has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typo in pre-existing JavaDoc
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 302:
>
>
On Wed, 7 May 2025 02:10:56 GMT, erifan wrote:
>> 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))
>> => (VectorMas
On Wed, 7 May 2025 10:24:14 GMT, erifan wrote:
>> src/hotspot/share/opto/vectornode.cpp line 2231:
>>
>>> 2229: }
>>> 2230: if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() > 1 ||
>>> 2231: !((VectorMaskCmpNode*) in1)->predicate_can_be_inverted() ||
>>
>> Do you plan to extend
On Tue, 6 May 2025 12:23:44 GMT, Chen Liang wrote:
>> This would require another implementation to be written. Maybe we can add
>> that later?
>
> I feel like declaring a function is declaring redundant classes when we can
> just reuse a DirectMethodHandle pointing to an actual method. Also the
On Fri, 25 Apr 2025 09:17:02 GMT, Jatin Bhateja wrote:
>> Thanks for telling me this information. Another more important reason to
>> check outcnt here is to prevent this optimization when the uses of
>> VectorMaskCmp is greater than 1, because this optimization may not be
>> worthwhile. For e
On Wed, 7 May 2025 10:53:09 GMT, Markus KARG wrote:
> Thank you, Jaikiran! Will this result convince everybody to actively mark
> this PR as officially reviewed, so I can finally integrate it? 😃
@liach For example, you could approve your outdated approval so this PR finally
has to *current* re
> This PR proposes to skip a stress test if the `main` thread is a virtual
> thread.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Cleanup merges
-
Changes:
- all: https://git.openjdk.org/jdk/pull/25084/files
- new
On Wed, 7 May 2025 10:05:12 GMT, Jaikiran Pai wrote:
> tier1 through tier3 testing of this PR passed without issues. The CSR has
> been approved and the changes in this PR look good to me.
Thank you, Jaikiran! Will this result convince everybody to actively mark this
PR as officially reviewed,
On Mon, 28 Apr 2025 19:48:40 GMT, Viktor Klang wrote:
>> @viktorklang-ora @DougLea @AlanBateman
>
> @kabutz Thanks for opening this PR—just confirming that it's on my to-review
> queue.
@viktorklang-ora any idea whom else we can ask to approve this PR?
-
PR Comment: https://git.op
On Wed, 7 May 2025 06:59:34 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 Tue, 6 May 2025 20:52:34 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegin)` to the `CharSequence` in
On Tue, 6 May 2025 20:52:34 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegin)` to the `CharSequence` in
On Wed, 7 May 2025 07:14:58 GMT, Shaojin Wen wrote:
>> Alan Bateman has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 20 commits:
>>
>> - Merge branch 'master' into JDK-8342486
>> - Merge branch 'master' into JDK-8342486
>> - Mer
On Tue, 6 May 2025 21:54:59 GMT, Jesper Wilhelmsson
wrote:
> We must remember that the OpenJDK community is built by individuals with
> different backgrounds and motivations to engaging. Some people get paid to
> work on OpenJDK development, others do it in their own time. It would be next
>
On Tue, 6 May 2025 21:45:34 GMT, Mohamed Issa wrote:
>> The goal of this PR is to implement an x86_64 intrinsic for
>> java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are
>> included to check the performance of specific input value ranges to help
>> prevent regressions
On Tue, 6 May 2025 15:34:11 GMT, Daniel Fuchs wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix raw long updater under 32-bit mode
>
> src/java.base/share/classes/java/net/URI.java line 558:
>
>> 556:
>> 557:
1 - 100 of 134 matches
Mail list logo
