> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Refactoring to paramaterized tests.
-
Changes:
- all: https://git.openjdk.org/
On Thu, 17 Jul 2025 23:15:44 GMT, John R Rose wrote:
>> Yep, to distinguish access and the encapsulated read-modify-write atomicity,
>> I decided to avoid using "atomic"/"non-atomic" altogether - now it is just
>> "make no atomicity guarantee"
>
> Not sure this is relevant, but isn't "opaque" a
On Thu, 17 Jul 2025 21:40:13 GMT, Joe Darcy wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Implement review feedback.
Since the refactoring
> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Removed temporary comment from tests.
-
Changes:
- all: https://git.openjdk.org/
> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Added tests.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/26364/files
-
On Thu, 17 Jul 2025 21:40:13 GMT, Joe Darcy wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Implement review feedback.
Looks fine
--
On Thu, 17 Jul 2025 18:28:04 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Thu, 17 Jul 2025 18:26:14 GMT, Naoto Sato wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added comment to COMPAT static field.
>
> Good to see this enhancement, Raffaell
On Thu, 17 Jul 2025 17:58:51 GMT, Justin Lu wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added comment to COMPAT static field.
>
> src/java.base/share/classes/jdk/internal/
On Wed, 16 Jul 2025 18:51:41 GMT, Joe Darcy wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> The methods directly affected by this update are atan, exp, and sin, cos,
> tan. The sin, cos, and tan method are affected by the updates to
> KernelRemPio2 and ta
On Thu, 17 Jul 2025 14:29:08 GMT, Raffaello Giulietti
wrote:
> What is the thinking when an `@IntrinsicCandidate` method invokes another
> `@IntrinsicCandidate` method? Which part is responsible for the checks?
>
> For example, the Java code of `StringCoding.encodeISOArray
On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
On Thu, 10 Jul 2025 12:18:25 GMT, Volkan Yazici wrote:
>> Volkan Yazici has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replace casting with `as_Region()` in `generate_string_range_check`
>
> src/java.base/share/classes/java/lang/StringC
On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
On Thu, 17 Jul 2025 13:41:06 GMT, Roger Riggs wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added comment to COMPAT static field.
>
> src/java.base/share/classes/jdk/interna
> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Added comment to COMPAT static field.
-
Changes:
- all: https://git.openjdk.org/
On Wed, 16 Jul 2025 04:53:04 GMT, Joe Darcy wrote:
> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
The arrays at L.2257-2262 could be declared `static` and `@Stable` as well, and
moved outside the method.
src/java.base/share/classes/java/lang/FdLibm.java line 815:
Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
-
Commit messages:
- Merge branch 'master' into 8362448
- 8362448: Make use of the Double.toString(double) algorithm in
java.text.DecimalFormat
- Remove some unused methods from FloatingDecimal.
- Rename
On Wed, 16 Jul 2025 10:32:41 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 2755:
>>
>>> 2753: * is even and this BigInteger is negative, an {@code
>>> ArithmeticException} will be
>>> 2754: * thrown.
>>> 2755: *
>>
>> I think this specifi
On Sat, 12 Jul 2025 09:18:27 GMT, fabioromano1 wrote:
>> 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:
>
> Removed useless instruction
src/java.bas
On Fri, 11 Jul 2025 19:02:31 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Tue, 15 Jul 2025 01:10:05 GMT, Joe Darcy wrote:
> From discussions related to IEEE 754, a few explicit test cases were
> identified where plausible, but incorrect, implementations of fma using
> higher precision. These test cases are useful to include in the regression
> tests of the float-
On Wed, 4 Jun 2025 13:12:33 GMT, Shaojin Wen wrote:
>> Some static final arrays of BigInteger and BigDecimal are stable and
>> immutable. We should add `@Stable` to give the optimizer more information
>
> Shaojin Wen has updated the pull request with a new target base due to a
> merge or a reba
On Wed, 4 Jun 2025 14:22:43 GMT, Raffaello Giulietti
wrote:
> Another step in enhancing floating-point <-> decimal conversions.
This pull request has now been integrated.
Changeset: 563e8762
Author:Raffaello Giulietti
URL:
https://git.openjdk.org/j
On Mon, 14 Jul 2025 15:46:47 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1936:
>>
>>> 1934: * where {@code nthRoot(., n)} denotes the mathematical {@code
>>> n}th root.
>>> 1935: * The contents of {@code this} are not changed. The
>>>
On Mon, 14 Jul 2025 15:40:18 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1964:
>>
>>> 1962: final double rad = Math.nextUp(x >= 0 ? x : x + 0x1p64);
>>> 1963: final double approx = n == 3 ? Math.cbrt(rad) :
>>> Math.pow(r
On Sat, 12 Jul 2025 09:18:27 GMT, fabioromano1 wrote:
>> 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:
>
> Removed useless instruction
I'm looking
On Sat, 12 Jul 2025 09:18:27 GMT, fabioromano1 wrote:
>> 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:
>
> Removed useless instruction
I agree that
On Fri, 11 Jul 2025 19:02:31 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 11 Jul 2025 14:27:21 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 6 Jun 2025 08:08:09 GMT, fabioromano1 wrote:
>> 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:
>
> Update "since" version
Right.
--
On Fri, 11 Jul 2025 08:19:43 GMT, Aleksey Shipilev wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borr
On Fri, 6 Jun 2025 08:08:09 GMT, fabioromano1 wrote:
>> 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:
>
> Update "since" version
Sure, the initial
On Sat, 17 May 2025 11:25:58 GMT, fabioromano1 wrote:
>> The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is
>> about 3 weeks from now.
>>
>> I think it's a bit too late for API additions to be approved in due time.
>> And even if we could rush this work for 25, it mak
On Sat, 2 Dec 2023 15:42:18 GMT, fabioromano1 wrote:
>> A faster and simpler way to generate random BigIntegers, avoiding eventually
>> trimming of leading zeros in magnitude array.
>
> fabioromano1 has updated the pull request incrementally with one additional
> commit since the last revision:
On Wed, 6 Dec 2023 15:07:59 GMT, fabioromano1 wrote:
>> So, item 1 is a non-issue and item 2 is not likely a problem in practice.
>> What, if anything, will be done about item 3?
>
> @bplb Maybe an assertion at the end of `randomBits(int, Random)` method, or a
> test class.
@fabioromano1 Do yo
On Tue, 1 Jul 2025 15:20:07 GMT, Jaikiran Pai wrote:
>> The uniqueness comes not just from the timestamp but also from the random
>> data in the other bytes that are generated for each new UUID.
>
> Hello Roger, that's true about the uniqueness semantics. However, from what I
> understand of RF
> Another step in enhancing floating-point <-> decimal conversions.
Raffaello Giulietti 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 conta
On Fri, 13 Jun 2025 15:21:38 GMT, Raffaello Giulietti
wrote:
> Documenting a suggestion for `float` arguments.
This pull request has now been integrated.
Changeset: 26848a7d
Author: Raffaello Giulietti
URL:
https://git.openjdk.org/jdk/commit/26848a7d6ce4c573b679a690fd36e6d708224
> Documenting a suggestion for `float` arguments.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Suggestion by reviewer.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/25805/files
- new: ht
On Fri, 13 Jun 2025 17:39:38 GMT, Brian Burkhalter wrote:
>> Documenting a suggestion for `float` arguments.
>
> src/java.base/share/classes/java/math/BigDecimal.java line 1383:
>
>> 1381: * the result usually contains too many trailing digits compared
>> 1382: * to the precision of a
Documenting a suggestion for `float` arguments.
-
Commit messages:
- 8358804: Improve the API Note of BigDecimal.valueOf(double)
Changes: https://git.openjdk.org/jdk/pull/25805/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25805&range=00
Issue: https://bugs.openjdk.org/
> Another step in enhancing floating-point <-> decimal conversions.
Raffaello Giulietti 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 two a
On Sat, 17 May 2025 11:25:58 GMT, fabioromano1 wrote:
>> The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is
>> about 3 weeks from now.
>>
>> I think it's a bit too late for API additions to be approved in due time.
>> And even if we could rush this work for 25, it mak
On Wed, 4 Jun 2025 14:22:43 GMT, Raffaello Giulietti
wrote:
> Another step in enhancing floating-point <-> decimal conversions.
Changes include, but are not limited to:
- Accessing `g0()` and `g1()` with the exponent rather than the negated
exponent.
- Inverting the order of the `Ma
Another step in enhancing floating-point <-> decimal conversions.
-
Commit messages:
- 8358540: Enhance MathUtils in view of FloatingDecimal enhancements
Changes: https://git.openjdk.org/jdk/pull/25641/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25641&range=00
Issue:
On Wed, 4 Jun 2025 13:53:09 GMT, Raffaello Giulietti
wrote:
>> BigInteger is an object that is considered immutable, but its field mag is
>> actually changed. This is incredible and should be fixed here. It is easy to
>> make mistakes.
>
> Please do _not_ fix th
On Fri, 30 May 2025 22:21:34 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 192:
>>
>>> 190: * zero-length mag array.
>>> 191: */
>>> 192: @Stable
>>
>> `BigInteger.mag` gets written to a few times during computation in
>> `BigInteger.large
On Tue, 27 May 2025 21:42:37 GMT, fabioromano1 wrote:
>> 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
On Mon, 26 May 2025 18:44:58 GMT, Raffaello Giulietti
wrote:
> Add a `-Dcount=N` command line option to specify the number of random samples
> per test (default is 10'000).
This pull request has now been integrated.
Changeset: efeb050e
Author: Raffaello Giulietti
URL:
On Tue, 27 May 2025 17:14:32 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 4732:
>>
>>> 4730: /* Allocate output array. If all non-sign ints are 0x00, we
>>> must
>>> 4731: * allocate space for one extra output int. */
>>> 4732:
On Wed, 21 May 2025 09:12:49 GMT, fabioromano1 wrote:
>> 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
> Add a `-Dcount=N` command line option to specify the number of random samples
> per test (default is 10'000).
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Changed option name to "samples".
-
Add a `-Dcount=N` command line option to specify the number of random samples
per test (default is 10'000).
-
Commit messages:
- 8357808: Add a command line option for specifying a counter in
TestRandomFloatingDecimal
Changes: https://git.openjdk.org/jdk/pull/25460/files
Webrev:
Depending on which static final arrays, this might be fine.
On 2025-05-26 01:57, wenshao wrote:
Some static final arrays of BigInteger and BigDecimal are stable and
immutable. We should add @Stable to give the optimizer more information
-
Shaojin Wen
On Sat, 24 May 2025 07:19:24 GMT, Shaojin Wen wrote:
>> Integer::digits type can use byte[] instead of char[], which can reduce the
>> conversion from char to byte in the process of Integer.toString. Using
>> byte[] can also save memory.
>
> Shaojin Wen has updated the pull request incrementall
On Sat, 24 May 2025 07:19:24 GMT, Shaojin Wen wrote:
>> Integer::digits type can use byte[] instead of char[], which can reduce the
>> conversion from char to byte in the process of Integer.toString. Using
>> byte[] can also save memory.
>
> Shaojin Wen has updated the pull request incrementall
On Wed, 21 May 2025 09:09:15 GMT, Tagir F. Valeev wrote:
>> Implementation of Comparator.min and Comparator.max methods. Preliminary
>> discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max a
On Fri, 16 May 2025 10:10:28 GMT, fabioromano1 wrote:
>> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you
>> please crosscheck?
>
>> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you
>> please crosscheck?
>
> @rgiulietti It seems there is a s
On Tue, 20 May 2025 13:20:10 GMT, fabioromano1 wrote:
>> 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
On Fri, 16 May 2025 10:10:28 GMT, fabioromano1 wrote:
>> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you
>> please crosscheck?
>
>> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you
>> please crosscheck?
>
> @rgiulietti It seems there is a s
On Mon, 19 May 2025 17:16:58 GMT, fabioromano1 wrote:
>> I think the suggestion is fine.
>
> Yes, but perhaps in the current version it's more clear what is the returned
> value according to the condition.
One could see the suggested variant as "return magBitLength(), except for a
corrective t
On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev wrote:
> Implementation of Comparator.min and Comparator.max methods. Preliminary
> discussion is in this thread:
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
> The specification is mostly composed of Math.min/max and C
On Fri, 16 May 2025 13:30:01 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 3860:
>>
>>> 3858: && Integer.lowestOneBit(mag[0]) == mag[0]
>>> 3859: && numberOfTrailingZeroInts() == mag.length - 1
>>> 3860: ? magBi
On Mon, 19 May 2025 15:02:57 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> An optimization
>
> src/java.base/share/classes/java/math/BigInte
On Fri, 16 May 2025 11:10:12 GMT, fabioromano1 wrote:
>> 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
Since the parser is specified to be lazy, the backing store needs to be
immutable.
On 2025-05-16 18:52, Markus KARG wrote:
When instead allowing the
general interface CharSequence, *any* kind of text source can be parsed,
for example, an off-heap located direct CharBuffer, without the need to
On Fri, 16 May 2025 11:43:18 GMT, fabioromano1 wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> make magBitLength() an instance method
>
> src/java.base/share/classes/java/math/BigInteger.java line 3619:
>
>> 3617:
On Thu, 15 May 2025 06:24:44 GMT, Shaojin Wen wrote:
> Similar to PR #24982
> Document preconditions on certain DecimalDigits methods that use operations
> either unsafe and/or without range checks.
The renaming is nice and useful.
But #24982, in addition to renaming, emphasizes the expectatio
On Thu, 15 May 2025 15:37:39 GMT, fabioromano1 wrote:
>> 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
On Thu, 15 May 2025 17:56:10 GMT, Archie Cobbs wrote:
>> test/jdk/java/util/ArrayDeque/ClearBenchmarkTestJMH.java line 64:
>>
>>> 62: @Measurement(iterations = 10)
>>> 63: @Warmup(iterations = 3)
>>> 64: public void fillAndClear() {
>>
>> I think you need to return the collection or
On Thu, 15 May 2025 06:24:44 GMT, Shaojin Wen wrote:
> Similar to PR #24982
> Document preconditions on certain DecimalDigits methods that use operations
> either unsafe and/or without range checks.
@wenshao I understand this is a kind of followup of #24982, but why this title?
It seems just
ham has updated the pull request incrementally with three
> additional commits since the last revision:
>
> - Update
> src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java
>
>Align better with spec
>
>Co-authored-by: Raffaello Giulietti
On Tue, 13 May 2025 21:24:08 GMT, fabioromano1 wrote:
>> 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
On Tue, 13 May 2025 21:24:08 GMT, fabioromano1 wrote:
>> 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
On Tue, 13 May 2025 21:24:08 GMT, fabioromano1 wrote:
>> 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
On Thu, 15 May 2025 09:17:42 GMT, Magnus Ihse Bursie wrote:
>>> So, this exactly reverses what was done in the fix for JDK-8301991
>>
>> No, it doesn't. I still agree with that fix -- the overwhelming majority of
>> characters should indeed be UTF-8 instead of unicode sequences.
>>
>> This is
On Wed, 14 May 2025 18:07:08 GMT, fabioromano1 wrote:
>> 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:
>
> Revert "Use type long for bitLength inste
On Wed, 14 May 2025 18:07:08 GMT, fabioromano1 wrote:
>> 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:
>
> Revert "Use type long for bitLength inste
On Mon, 12 May 2025 19:23:16 GMT, fabioromano1 wrote:
>> @fabioromano1 Is [this
>> proof](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)
>> still relevant?
>
> @rgiulietti No, the proof of the recurrence used is the one by Zimmermann
> linked in the code
On Sun, 11 May 2025 16:32:02 GMT, Johannes Graham wrote:
>> 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.
>
> On Aarch64 M4:
>
> Benchmark
On Wed, 14 May 2025 13:33:32 GMT, Johannes Graham wrote:
>> test/jdk/java/math/BigDecimal/ValueOfDouble.java line 41:
>>
>>> 39:
>>> 40: public class ValueOfDouble {
>>> 41: private static final String DIGITS = "1234567899123456789"; //
>>> Enough digits to fill a long
>>
>> Suggestion:
>
On Wed, 14 May 2025 13:47:11 GMT, Johannes Graham wrote:
>> 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 reque
On Tue, 13 May 2025 13:03:42 GMT, Johannes Graham wrote:
>> 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 reque
On Fri, 13 Dec 2024 15:04:12 GMT, Raffaello Giulietti
wrote:
> See the JBS bug for some details.
This pull request has now been integrated.
Changeset: d1032d71
Author: Raffaello Giulietti
URL:
https://git.openjdk.org/jdk/commit/d1032d71bfd50ebc4b328ce9b0cc81cbb80554b0
St
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.
@fabioromano1 While reviewers can of course file JBS issues on behalf of
contributors, the recommende way is for
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: 64a858
On Tue, 13 May 2025 03:58:44 GMT, Joe Darcy wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Addressed reviewer comments.
>
> src/java.base/share/classes/jdk/internal/math/
On Mon, 12 May 2025 15:53:42 GMT, Roger Riggs wrote:
> The failure of the new StringBuilder HugeCapacity test testHugePlus is
> intermittent with some GC's.
> It could be reliably reproduced with the serialGC and parallelGC's.
>
> Raise the memory limit from 6G to 8G to accommodate the new test
On Sat, 10 May 2025 11:57:32 GMT, fabioromano1 wrote:
>> 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
On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham wrote:
> 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.
macOS 15.4.1 / M1 Pro / 32 GiB RAM
BigDecimals.
On Sun, 11 May 2025 16:32:02 GMT, Johannes Graham wrote:
>> 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.
>
> On Aarch64 M4:
>
> Benchmark
> See the JBS bug for some details.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Addressed reviewer comments.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/22737/files
- new: https://git.openjdk.
On Fri, 9 May 2025 22:58:19 GMT, Chen Liang wrote:
>> Raffaello Giulietti 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
> See the JBS bug for some details.
Raffaello Giulietti 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 12 additional commits
since the last revis
> See the JBS bug for some details.
Raffaello Giulietti 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 14 additional commits
since the last revis
On Fri, 9 May 2025 16:41: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 Thu, 8 May 2025 16:48:40 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
1 - 100 of 971 matches
Mail list logo
