On Sun, 27 Apr 2025 04:50: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
On Sun, 27 Apr 2025 04:50: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
On Sun, 27 Apr 2025 04:50: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
> 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 Fri, 21 Mar 2025 19:44:48 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 Fri, 21 Mar 2025 19:44:48 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 Sun, 27 Apr 2025 02:04:30 GMT, Chen Liang wrote:
> Internal explicit counter support for Code max_stack and max_locals has been
> already added in #24807. Since that example works well, we may consider
> opening this functionality up to general users under strict restrictions.
>
> This is a
> Internal explicit counter support for Code max_stack and max_locals has been
> already added in #24807. Since that example works well, we may consider
> opening this functionality up to general users under strict restrictions.
>
> This is an advanced API; thus, I chose a more complex name
> `
On Sun, 27 Apr 2025 02:04:30 GMT, Chen Liang wrote:
> Internal explicit counter support for Code max_stack and max_locals has been
> already added in #24807. Since that example works well, we may consider
> opening this functionality up to general users under strict restrictions.
>
> This is a
Reorder the calling of a custom "post-image" script in MSI packaging.
Add a relevant test.
-
Commit messages:
- Test the current directory of the post-image script is the root directory
for app image.
- 8355651: Premature execution of post-image hook
Changes: https://git.openjdk.
On Sat, 26 Apr 2025 21:31:35 GMT, Alexey Semenyuk wrote:
> Reorder the calling of a custom "post-image" script in MSI packaging.
>
> Add a relevant test.
@sashamatveev PTAL
-
PR Comment: https://git.openjdk.org/jdk/pull/24899#issuecomment-2832921058
On Fri, 21 Mar 2025 19:44:48 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
> Take the class file version to reject flags not yet defined, redefined, or
> obsoleted. The non-cffv version can return the preview flags when the current
> runtime is in preview.
Chen Liang has updated the pull request incrementally with two additional
commits since the last revision:
- Mi
Internal explicit counter support for Code max_stack and max_locals has been
already added in #24807. Since that example works well, we may consider opening
this functionality up to general users under strict restrictions.
This is an advanced API; thus, I chose a more complex name
`withExplicit
> Currently, we are not generating all possible field lambda forms.
>
> Field lambda forms have these dimensions:
> - get/set
> - instance/static/static+class init barrier
> - plain/volatile
> - 8 primitive types, no-cast object, object with cast
>
> Bringing to a total of 2 × 3 × 2 × 10 = 120 la
> In the Throwable::printStackTrace method, StringBuilder is created multiple
> times to build String. By sharing StringBuilder to build String, object
> allocation and copying are reduced.
>
> In the scenario without suppressed and ourCause, unused IdentityHashMap is
> not created.
>
> Throug
On Fri, 25 Apr 2025 20:30:15 GMT, Chen Liang wrote:
> Currently, we are not generating all possible field lambda forms.
>
> Field lambda forms have these dimensions:
> - get/set
> - instance/static/static+class init barrier
> - plain/volatile
> - 8 primitive types, no-cast object, object with ca
> 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 Sat, 26 Apr 2025 13:17:16 GMT, Oliver Kopp wrote:
> I would expect that all files are available before the "Post-image script"
> are available
Definitely. Thank you for reporting the issue. Filed
https://bugs.openjdk.org/browse/JDK-8355651 to track fixing the issue
-
PR Commen
> 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
Hmm, thanks for the reminder; unfortunately I did not pay close attention to
the progress of amber and don't know about the details. I might ask Amber folks
in private and share if we have a roadmap for this feature.
From: David Alayachew
Sent: Saturday, April 26
> 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
Didn't Brian or one of the Amber folks say that we might (some time in the
near future) get a .match() method on streams, which can take in a pattern?
It's the pattern version of .map().
On Sat, Apr 26, 2025 at 3:13 PM Chen Liang wrote:
> Hi Nir, I think currently the most similar code pattern i
> Take the class file version to reject flags not yet defined, redefined, or
> obsoleted. The non-cffv version can return the preview flags when the current
> runtime is in preview.
Chen Liang has updated the pull request with a new target base due to a merge
or a rebase. The pull request now c
> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in
> a location. However, there is no easy way to check what flag mask bits or
> what flags are valid for a location. We need such APIs to check, specific to
> each class file format version.
>
> Also in the investigat
On Sat, 26 Apr 2025 19:24:21 GMT, fabioromano1 wrote:
> It seems your new `unsignedIntPow` already covers `base.mag.length == 1` case
> - your `unsignedLongPow` and `unsignedIntPow` are otherwise identical. Can we
> just remove this long shortcut and `unsignedLongPow` and use the newly
> estab
> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in
> a location. However, there is no easy way to check what flag mask bits or
> what flags are valid for a location. We need such APIs to check, specific to
> each class file format version.
>
> Also in the investigat
Hi Nir, I think currently the most similar code pattern in stream that enjoys a
good performance is:
.mapMulti((x, sink) -> {
if (x instanceof MyClass myClass) {
sink.accept(myClass);
}
})
>From the language point of view, such pattern-match-and-map-0/1 operations may
>be common
> 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 Sat, 26 Apr 2025 19:16:14 GMT, Chen Liang wrote:
> It seems your new `unsignedIntPow` already covers `base.mag.length == 1` case
> - your `unsignedLongPow` and `unsignedIntPow` are otherwise identical. Can we
> just remove this long shortcut and `unsignedLongPow` and use the newly
> establi
On Sat, 26 Apr 2025 19:11:01 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
Hi,
instanceof has been refitted to include an auto-cast ("pattern matching on
instanceof"). Unfortunately, doing this as an intermediate operation on a
stream requires first to filter via instanceof and then map via a cast.
This is because
x instanceof MyClass myClass
returns a boolean, not
On Sat, 26 Apr 2025 17:22:09 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 2721:
>>
>>> 2719: if (!pow.equals(ONE)) {
>>> 2720: for (int i = 0; i < blockLen; i++)
>>> 2721: pow = pow.multiply(pow);
>>
>> Majo
On Sat, 26 Apr 2025 17:19:30 GMT, Chen Liang wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed method used by nth-root
>
> src/java.base/share/classes/java/math/BigInteger.java line 2721:
>
>> 2719:
On Sat, 26 Apr 2025 16:44:26 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 Sat, 26 Apr 2025 16:44:26 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
> 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` interface, providing a **bulk-read**
> facility including a
On Sat, 26 Apr 2025 16:44:26 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
> 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
This PR implements nth root computation for BigIntegers using Newton method.
This PR is dependent by this [PR](https://github.com/openjdk/jdk/pull/24690).
-
Commit messages:
- Merge branch 'openjdk:master' into BigInteger-nth-root
- Optimized nth root iteration loop
- Systematizat
> In the Throwable::printStackTrace method, StringBuilder is created multiple
> times to build String. By sharing StringBuilder to build String, object
> allocation and copying are reduced.
>
> In the scenario without suppressed and ourCause, unused IdentityHashMap is
> not created.
>
> Throug
> This PR implements nth root computation for `BigInteger`s using Newton method
> and optimizes `BigInteger.pow(int)` method.
fabioromano1 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 merg
On Thu, 24 Apr 2025 20:18:42 GMT, fabioromano1 wrote:
>> @fabioromano1 I just had a cursory glance at this PR.
>>
>> AFAIU, there are two main contributions here:
>>
>> - Performance enhancements in `pow()`, which is of general interest and does
>> not require submitting a [CSR](https://wiki.o
On Thu, 6 Jun 2024 12:41:17 GMT, Alexey Semenyuk wrote:
> jpackage allows override of main WiX source file (main.wxs), do you know what
> will happen if user will add main.wxs with format features available only in
> WiX 5 and will have WiX 5 toolkit installed?
@alexeysemenyukoracle Related qu
> In the Throwable::printStackTrace method, StringBuilder is created multiple
> times to build String. By sharing StringBuilder to build String, object
> allocation and copying are reduced.
>
> In the scenario without suppressed and ourCause, unused IdentityHashMap is
> not created.
>
> Throug
On Sun, 6 Apr 2025 03:48:22 GMT, Mohamed Issa wrote:
> the built in **cbrt** micro-benchmark
How should we run that benchmark? Thanks.
-
PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2832035668
On Sat, 26 Apr 2025 09:21:32 GMT, Shaojin Wen wrote:
>> In the Throwable::printStackTrace method, StringBuilder is created multiple
>> times to build String. By sharing StringBuilder to build String, object
>> allocation and copying are reduced.
>>
>> In the scenario without suppressed and our
On Sun, 6 Apr 2025 03:48:22 GMT, Mohamed Issa wrote:
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.cbrt() using libm.
>
> The results of all tests posted below were captured with an [Intel® Xeon
> 6761P](https://www.intel.com/content/www/us/en/products/sku/2418
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 08:41:28 GMT, Eirik Bjørsnøs wrote:
> Even if that was the case, for any printing to be useful to any human beeing
> it would require IO to disk, database or have some form of external effect
> rather than just printing it to a NullOutputStream which is what the
> benchmark
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 the test I used locally to test
> In the Throwable::printStackTrace method, StringBuilder is created multiple
> times to build String. By sharing StringBuilder to build String, object
> allocation and copying are reduced.
>
> In the scenario without suppressed and ourCause, unused IdentityHashMap is
> not created.
>
> Throug
> In the Throwable::printStackTrace method, StringBuilder is created multiple
> times to build String. By sharing StringBuilder to build String, object
> allocation and copying are reduced.
>
> In the scenario without suppressed and ourCause, unused IdentityHashMap is
> not created.
>
> Throug
On Sat, 26 Apr 2025 07:01:46 GMT, Shaojin Wen wrote:
>> In the Throwable::printStackTrace method, StringBuilder is created multiple
>> times to build String. By sharing StringBuilder to build String, object
>> allocation and copying are reduced.
>>
>> In the scenario without suppressed and our
On Sat, 26 Apr 2025 07:28:03 GMT, Shaojin Wen wrote:
> I hope the discussion can return to this PR and discuss specific technical
> points instead of philosophy.
Discussing technical points about code in this PR seems premature at this point.
Reviewers have raised concerns about the larger pic
On Sat, 26 Apr 2025 07:28:03 GMT, Shaojin Wen wrote:
> The goal of the optimization is also very clear, which is to make the program
> perform better when a large number of exceptions are thrown when an error
> occurs. This is a very typical scenario.
But that's not what's happening here. Whil
On Sat, 26 Apr 2025 07:01:46 GMT, Shaojin Wen wrote:
>> In the Throwable::printStackTrace method, StringBuilder is created multiple
>> times to build String. By sharing StringBuilder to build String, object
>> allocation and copying are reduced.
>>
>> In the scenario without suppressed and our
58 matches
Mail list logo
