On Sat, 4 Oct 2025 07:04:03 GMT, Eirik Bjørsnøs wrote:
> ```
> // Currently Float16 is a value-based class and in future it is
> ```
>
> in _the_ future
>
> ```
> // IEEEremainder / remainder operator remainder
> ```
>
> Would one remainder suffice for this remainder reminder?
>
> ```
> priva
Upon further inspection, found a few more opportunities to refine the use of
constants in the Float16 implementation.
-
Commit messages:
- JDK-8369123: Still more small Float16 refactorings
Changes: https://git.openjdk.org/jdk/pull/27625/files
Webrev: https://webrevs.openjdk.org/
On Thu, 2 Oct 2025 16:22:56 GMT, Joe Darcy wrote:
> As a follow-up to https://git.openjdk.org/jdk/pull/27587, I went through the
> code of Float16.java and found a few more cases where hex integer constants
> could be replaced by symbolic constants. A few other small changes includ
As a follow-up to https://git.openjdk.org/jdk/pull/27587, I went through the
code of Float16.java and found a few more cases where hex integer constants
could be replaced by symbolic constants. A few other small changes included too.
-
Commit messages:
- JDK-8369051: More small Flo
On Wed, 1 Oct 2025 18:30:25 GMT, Eirik Bjørsnøs wrote:
> Just an observation: Constants in this class are some times qualified using
> the class name, in other cases not.
>
> This was probably the case before this PR, but the PR seems itself to be a
> bit inconsistent.
>
> Since the class use
> A few more small cleanups to Float16 and its tests.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Respond to review feedback.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/27587/files
- new: ht
On Wed, 1 Oct 2025 16:46:26 GMT, Raffaello Giulietti
wrote:
> IMHO, `isNan()` and `isInfinite()` should look almost identical, except for
> the significand bits. Maybe for another time.
Fair point; updated. Thanks.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/27587#discu
On Wed, 1 Oct 2025 06:43:25 GMT, Eirik Bjørsnøs wrote:
> Should the leftover 0x7c00 also be replaced with the constant?
Good catch; I meant to do that too. Thanks.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/27587#discussion_r2395116573
On Sun, 28 Sep 2025 19:21:22 GMT, Joe Darcy wrote:
> Refactoring to express the code more in terms of symbolic concepts rather
> than raw constants.
This pull request has now been integrated.
Changeset: 63688d89
Author: Joe Darcy
URL:
https://git.openjdk.org/jdk/
On Tue, 23 Sep 2025 17:11:01 GMT, Raffaello Giulietti
wrote:
> I checked 754-2008, which requires a 0 sign bit, and 754-1985 (reaffirmed in
> 1990), which in the annex on recommended functions reads
>
> > Copysign(x,y) returns x with the sign of y. Hence, abs(x) =
> > copysign(x,1.0), even it
On Tue, 23 Sep 2025 13:06:05 GMT, Raffaello Giulietti
wrote:
> @jddarcy Why can't we simply require a zero sign bit, like IEEE 754 does?
> After all, IIUC this is exactly what the implementation does.
As an intrinsic candidate, the method could be replaced with a hardware
instruction and earl
Add apiNote linking {Math, StrictMath}.abs to the IEEE 754 abs operation.
-
Commit messages:
- JDK-8368349: Add library notes discussing abs and IEEE 754 operations
Changes: https://git.openjdk.org/jdk/pull/27443/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27443&range=0
On Thu, 18 Sep 2025 03:31:30 GMT, Joe Darcy wrote:
> Add a total that the total order used by {Double, Float}.compareTo is
> different than the total order defined by IEEE 754, starting the 2008 version
> of that standard.
This pull request has now been integrated.
Changeset: 488255
On Mon, 22 Sep 2025 17:02:44 GMT, Raffaello Giulietti
wrote:
> When both arguments are NaNs, IEEE 754 also specifies (§5.10.d.5.ii)
>
> > signaling orders below quiet for +NaN, reverse for −NaN
>
> and leaves more fine grained details to the implementation.
>
> Otherwise looks fine.
Hmm. I d
> Add a total that the total order used by {Double, Float}.compareTo is
> different than the total order defined by IEEE 754, starting the 2008 version
> of that standard.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
On Thu, 18 Sep 2025 21:50:08 GMT, Brian Burkhalter wrote:
> Looks all right to me once the placeholder text is replaced.
Placeholder text now replaced.
-
PR Comment: https://git.openjdk.org/jdk/pull/27356#issuecomment-3321430800
On Fri, 12 Sep 2025 08:51:22 GMT, Raffaello Giulietti
wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typo found in code review.
>
> src/java.base/share/classes/java/lang/
Analogous to recent updates made in Float and Double, along with a double ->
Float16 typo fix.
-
Commit messages:
- JDK-8367787: Expand use of representation equivalence terminology in Float16
Changes: https://git.openjdk.org/jdk/pull/27322/files
Webrev: https://webrevs.openjdk.o
> Add a total that the total order used by {Double, Float}.compareTo is
> different than the total order defined by IEEE 754, starting the 2008 version
> of that standard.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
R
On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs wrote:
> This PR adds a new compiler warning for `@SuppressWarnings` annotations that
> don't actually suppress any warnings.
>
> Summary of code changes:
>
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` t
On Thu, 18 Sep 2025 04:44:28 GMT, Chen Liang wrote:
>> Add a total that the total order used by {Double, Float}.compareTo is
>> different than the total order defined by IEEE 754, starting the 2008
>> version of that standard.
>
> src/java.base/share/classes/java/lang/Double.java line 1443:
>
Add a total that the total order used by {Double, Float}.compareTo is different
than the total order defined by IEEE 754, starting the 2008 version of that
standard.
-
Commit messages:
- JDK-8367942: Add API note discussing Double.compareTo total order and IEEE
754 total order
Ch
On Tue, 16 Sep 2025 20:33:00 GMT, Joe Darcy wrote:
> Analogous to recent updates made in Float and Double, along with a double ->
> Float16 typo fix.
This pull request has now been integrated.
Changeset: 919f5faa
Author:Joe Darcy
URL:
https://git.openjdk.org/j
On Tue, 16 Sep 2025 17:10:18 GMT, Pavel Rappo wrote:
>> Please review this documentation-only change, which I believe does **NOT**
>> require CSR.
>>
>> The change touches java.time.** classes that I happen to have been using a
>> lot recently. While the diff is pretty self-describing, here's
On Tue, 16 Sep 2025 20:03:45 GMT, Archie Cobbs wrote:
>> Hi @archiecobbs , are there bugs filed to clean the causes of the warnings?
>
>> Hi @archiecobbs , are there bugs filed to clean the causes of the warnings?
>
> Hi @jddarcy,
>
> At the beginning of this project as a preliminary step I fil
On Mon, 15 Sep 2025 07:39:00 GMT, fabioromano1 wrote:
>> A formula to lower the overestimate for the precision of an exact quotient,
>> without introducing too expensive operations of division on numerator and
>> denominator.
>
> fabioromano1 has updated the pull request incrementally with one
On Thu, 11 Sep 2025 17:56:29 GMT, Joe Darcy wrote:
> Small doc enhancement to use the term "representation equivalence" in a few
> more locations.
This pull request has now been integrated.
Changeset: 58c9fbc9
Author:Joe Darcy
URL:
https://git.openjd
> Small doc enhancement to use the term "representation equivalence" in a few
> more locations.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Respond to review feedback.
-
Changes:
- all: https://git
Small doc enhancement to use the term "representation equivalence" in a few
more locations.
-
Commit messages:
- JDK-8367382: Expand use of representation equivalence terminology
Changes: https://git.openjdk.org/jdk/pull/27232/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&p
On Thu, 11 Sep 2025 19:10:57 GMT, Eirik Bjørsnøs wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typo found in code review.
>
> src/java.base/share/classes/java/lang/Record.java li
> Small doc enhancement to use the term "representation equivalence" in a few
> more locations.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Fix typo found in code review.
-
Changes:
- all: https:/
On Thu, 4 Sep 2025 08:45:33 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:
>
> Small optimization and format comments
sr
On Thu, 4 Sep 2025 08:45:33 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:
>
> Small optimization and format comments
sr
On Thu, 28 Aug 2025 15:08:04 GMT, fabioromano1 wrote:
>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 120 commits:
>
> - Merge branch
On Sat, 3 May 2025 00:56:00 GMT, Chen Liang wrote:
>> Sometimes, for version-specific feature access APIs, we wish to access the
>> preview features of the current Java SE release. To reduce the impact of
>> adding one preview-specific version on every site, we can add a constant
>> modeling t
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.
This pull request has now been integrated.
Changeset: 9593730a
Author: Joe Darcy
URL:
https://git.openjdk.org/jdk/com
> 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:
Small refinement and add test cases
-
Changes:
- all: https://git.openjdk.org/jdk/pull/26
On Fri, 18 Jul 2025 16:54:36 GMT, Joe Darcy wrote:
> > This array unrolling looks right to me.
>
> I'll write a regression test case to make sure.
Catching up after JVMLS, added a few test cases for pow and exp code that was
changed.
-
PR Comment: https://gi
> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
Joe Darcy has updated the pull request incrementally with two additional
commits since the last revision:
- Cleanup and respond to review comments.
- Respond to review feedback.
-
Changes:
- all: ht
On Tue, 29 Jul 2025 15:00:11 GMT, Nizar Benalla wrote:
>> Please review this patch that extends the javadoc of
>> `UnsupportedOperationException` no-arg constructor, to clear up that the
>> detail message is null.
>
> Nizar Benalla has updated the pull request incrementally with one additional
On Tue, 22 Jul 2025 15:20:24 GMT, Chen Liang wrote:
> Re @turbanoff and @ExE-Boss's style fixes: this code is ported from the c
> code of fdlibm so it has a lot of irregular styles. I think we might look
> into updating the implementation to be more Java-ish in the future in another
> patch.
On Tue, 24 Jun 2025 22:32:30 GMT, Chen Liang wrote:
> Currently, fake parameters are created with "arg0" etc. strings that are
> retained for class file methods with no MethodParameters attribute. The
> original issue report observes many of these strings present in the heap. To
> address this
On Fri, 18 Jul 2025 13:40:15 GMT, Chen Liang wrote:
> This array unrolling looks right to me.
I'll write a regression test case to make sure.
-
PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3090070661
On Thu, 17 Jul 2025 18:16:33 GMT, Chen Liang wrote:
> I think local arrays require more structural changes to the code, which might
> be why this patch did not include that change. However, note as said in
> #26355, such conversions are meaningful and would potentially allow
> performance boos
> 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.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/26341/fi
On Thu, 17 Jul 2025 18:04:31 GMT, Raffaello Giulietti
wrote:
> The arrays at L.2257-2262 could be declared `static` and `@Stable` as well,
> and moved outside the method.
Right; those were the ones I was referring to when I wrote "Some small
refactorings could be used to make a few non-static
> 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:
Respond to review feedback and update copyright.
-
Changes:
- all: https://git.openjdk.org/
On Thu, 17 Jul 2025 10:58:30 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/FdLibm.java line 815:
>>
>>> 813: */
>>> 814:
>>> 815: private static final int init_jk[] = {2, 3, 4, 6}; // initial
>>> value for jk
>>
>> Suggestion:
>>
>> @Stable private
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 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
tan
On Wed, 16 Jul 2025 18:32:13 GMT, John R Rose wrote:
> The effect of this PR is to make the affected array elements eligible for
> constant-folding by the JIT.
>
> The contract of `@Stable` is private to the JDK, since it is a trusted
> annotation. The trusted user promises not to change the a
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
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.
Some small refactorings could be used to make a few non-static arrays static.
-
PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3076738696
Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
-
Commit messages:
- JDK-8362376: Use @Stable annotation in Java FDLIBM implementation
Changes: https://git.openjdk.org/jdk/pull/26341/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26341&range=00
On Mon, 30 Jun 2025 18:05:58 GMT, Raffaello Giulietti
wrote:
>> 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
> br
>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-precision and Float16-precision fused multiple add method
On Thu, 10 Jul 2025 14:31:02 GMT, Mohamed Issa wrote:
> > What is the accuracy of the algorithm in ulps (units the last place)?
> > The java.lang.Math specification has max error and various other accuracy
> > requirements any implementation must meet.
>
> 0.51 ulps
Please add that as a commen
On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa wrote:
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.sinh() 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 in
On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa wrote:
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.sinh() 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 in
On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa wrote:
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.sinh() 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 in
t; > so, I'd be happy to do it).
>
> I don't think it's strictly needed here, Joe Darcy is going to give an
> opinion today.
Okay -- I've taken a quick look over the proposed changes. While most of the
changes are clearly informative (and thus don't need a CS
On Fri, 13 Jun 2025 21:46:42 GMT, Raffaello Giulietti
wrote:
>> 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.
Marked as reviewed by darcy (R
On Fri, 13 Jun 2025 15:21:38 GMT, Raffaello Giulietti
wrote:
> Documenting a suggestion for `float` arguments.
src/java.base/share/classes/java/math/BigDecimal.java line 1380:
> 1378: * Double#toString(double)}.
> 1379: *
> 1380: * While a {@code float} argument {@code v} can b
On Fri, 13 Jun 2025 18:39:14 GMT, Brian Burkhalter wrote:
>> I usually start a sentence on a new line because that generates less noise
>> when diffing in the future.
>> The HTML renders it in the same paragraph as the preceding text.
>
> Makes sense.
> I usually start a sentence on a new line
On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote:
>> Get JDK 26 underway.
>
> Nizar Benalla 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.8355746
> - Problemlist JavaBaseChec
On Tue, 3 Jun 2025 20:14:13 GMT, Stuart Marks wrote:
>> src/java.base/share/classes/java/util/SequencedMap.java line 296:
>>
>>> 294: return view().hashCode();
>>> 295: }
>>> 296: public void addFirst(K k) { throw new
>>> UnsupportedOperationException();
On Sat, 31 May 2025 00:47:16 GMT, Stuart Marks wrote:
>> For a full explanation, see the bug report
>> [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
>>
>> This PR includes three related changes:
>> * New overrides in SequencedMap view collection implementations, which
>> improve
On Wed, 21 May 2025 00:59:34 GMT, Sergey Bylokhov wrote:
> Both fields were added by the
> [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777):
> see
> https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8
> And the usage were deleted by the
> [JDK-8341402](http
On Mon, 19 May 2025 11:31:23 GMT, Nizar Benalla wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341:
>>
>>> 1339: * @throws ClassNotFoundException if one of the component classes
>>> cannot be resolved
>>> 1340: * @see MethodType.readResolve()
>>> 1341:
On Sun, 18 May 2025 21:15:21 GMT, Chen Liang wrote:
> > Did you consider calling getComponentType(), which already returns the
> > field?
>
> I don't think we want an extra indirection here - The logic here is quite
> simple. Counterargument could be that `MethodType::descriptorString` calls
On Sat, 17 May 2025 02:15:42 GMT, Chen Liang wrote:
> `isArray` and null return is now redundant when `componentType` is changed to
> an explicit field.
src/java.base/share/classes/java/lang/Class.java line 3985:
> 3983: @Override
> 3984: public Class componentType() {
> 3985:
On Thu, 8 May 2025 15:13:19 GMT, Raffaello Giulietti
wrote:
>> Add `powExact()` and `unsignedPowExact()` methods that operate on integer
>> values arguments.
>> Further, add `unsignedMultiplyExact` methods as well.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> a
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.
src/java.base/share/classes/jdk/internal/math/Fo
On Sat, 10 May 2025 10:08:39 GMT, Raffaello Giulietti
wrote:
>> 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.
Marked as reviewed by darcy (Reviewer).
On Mon, 12 May 2025 23:21:15 GMT, Chen Liang wrote:
> Do we need a CSR for this?
No; from a quick look, I don't see a need for a CSR here as the semantics
aren't being changed. HTH
-
PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2874629944
On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy wrote:
> Fix javadoc tags.
This pull request has now been integrated.
Changeset: bed29a03
Author: Joe Darcy
URL:
https://git.openjdk.org/jdk/commit/bed29a03d198a9717f7d258ee21330462775136e
Stats: 4 lines in 1 file changed: 0 ins; 0
> Fix javadoc tags.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Respond to review feedback.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/25131/files
- new: https://git.openjdk.org/jdk/pull/25131/fi
On Fri, 9 May 2025 10:32:27 GMT, Nizar Benalla wrote:
> I just noticed there are a couple more javadoc tags that need to be fixed in
> this class, I still see two more warnings. I should have included these in
> the JBS issue when filling it.
>
> ```
> src/java.base/share/classes/java/math/Big
Fix javadoc tags.
-
Commit messages:
- JDK-8356555: Incorrect use of {@link} in BigDecimal
Changes: https://git.openjdk.org/jdk/pull/25131/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25131&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8356555
Stats: 2 lines in
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 Thu, 1 May 2025 17:18:07 GMT, Markus KARG wrote:
>> There are subtleties and perhaps surprises in `@inheritDoc`, but that
>> doesn't necessarily imply the current behavior is buggy.
>
> So it is actually *wanted* behavior that in one situation the text *is*
> inherited, but at `String.java`
On Fri, 2 May 2025 17:49:54 GMT, Raffaello Giulietti
wrote:
> Yes, I'm familiar with both this Java code and the intrinsic code.
>
> Compare this with the much simpler proposed code. The checked multiplication
> `unsignedMultiplyExact` apparently performs two 64x64->64 multiplications,
> but
On Fri, 2 May 2025 16:55:49 GMT, Chen Liang wrote:
> May I prepare a quick patch to bring this in line with `TraverseProc` so we
> can skip this site for future start of release updates?
I know it is possible to write getSupportedSourceVersion to return the latest
version, but I don't think it
On Fri, 2 May 2025 16:54:59 GMT, Chen Liang wrote:
> I have asked @nizarbenalla in offline communications for a list of failing
> hotspot tests. I aim to update them on a case-by-case basis, to determine if
> the compile arguments should provide a `--release ` argument or migrate
> class file
On Fri, 2 May 2025 15:47:43 GMT, Chen Liang wrote:
>> Get JDK 26 underway.
>
> make/conf/version-numbers.conf line 36:
>
>> 34: DEFAULT_VERSION_EXTRA2=0
>> 35: DEFAULT_VERSION_EXTRA3=0
>> 36: DEFAULT_VERSION_DATE=2026-03-16
>
> Is this accurate?
One day off; should be 2026-03-17.
I should hav
On Thu, 24 Apr 2025 16:24:53 GMT, Stuart Marks wrote:
>> Hi Joe, yes `adjustTimeout` will scale based on the jtreg timeout factor. I
>> believe the behaviour is to multiply whatever hardcoded timeout is passed by
>> the timeout factor.
>> On lower tiers, in our CI, I beleive it means the test w
On Thu, 1 May 2025 13:03:47 GMT, Markus KARG wrote:
>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 488:
>>
>>> 486: /**
>>> 487: * {@inheritDoc CharSequence}
>>> 488: */
>>
>> Suggestion:
>>
>> * {@inheritDoc CharSequence}
>> * @param srcBegin
On Wed, 30 Apr 2025 17:59:55 GMT, Markus KARG wrote:
>> Could this be a Javadoc bug? What does a simple `{@inheritDoc}` do?
>
> Unfortunately the same happens. 🙁
The following javadoc for String's getChars method has, I believe, the desired
effect:
/**
* {@inheritDoc CharSequence}
On Fri, 25 Apr 2025 00:34:39 GMT, Shaojin Wen wrote:
>> Again, what goal is this PR trying to accomplish?
>
> The goal of this PR is to simplify the code by using new language features.
To what end?
- "I was reading Throwable and noticed this possible refactoring."
- "I've run an analysis of th
On Thu, 24 Apr 2025 23:52:09 GMT, Shaojin Wen wrote:
>>> What should we replace it with? Do you have any suggestions?
>>
>> The wrapper classes were needed when there were was a mix of synchronized
>> and j.u.concurrent locks in use. With JEP 491 integrated it meant that the
>> java.io classes
On Wed, 16 Apr 2025 17:37:07 GMT, David Beaumont wrote:
>> Increasing timeout for deadlock detection and adjusting for the timeout
>> factor in higher tiers.
>
> David Beaumont has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Removing test
On Tue, 18 Mar 2025 14:46:01 GMT, fabioromano1 wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> An optimization
>
> This comment is to avoid closing this PR.
> @fabioromano1 Thanks so much for your great work and p
On Sat, 22 Mar 2025 11:09:03 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Mon, 24 Mar 2025 21:29:29 GMT, Chen Liang wrote:
>> Core reflection's generic signature parsing system is used for many aspects,
>> including annotations and enclosing methods, yet it is under-tested. It is
>> better for us to set up tests to ensure that sensitive error behaviors of
>> core
On Thu, 27 Feb 2025 17:41:48 GMT, Chen Liang wrote:
>> Core reflection's generic signature parsing system is used for many aspects,
>> including annotations and enclosing methods, yet it is under-tested. It is
>> better for us to set up tests to ensure that sensitive error behaviors of
>> core
On Thu, 6 Mar 2025 20:01:47 GMT, Andrey Turbanov wrote:
>> src/java.base/share/classes/java/lang/String.java line 3649:
>>
>>> 3647: Iterable elements) {
>>> 3648: Objects.requireNonNull(delimiter);
>>> 3649: Objects.requireNonNull(elements);
>>
>> Hello Andrey, I ha
On Wed, 5 Mar 2025 15:16:03 GMT, Eric Caspole wrote:
> The normal SQE process runs all the repo JMH with -ea to get the last bit of
> extra testing. This DremFrem JMH contained some asserts that would always
> fire on the correct answer, disturbing this normal SQE process. I removed a
> lot mo
On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs wrote:
>> Please review this patch which removes unnecessary `@SuppressWarnings`
>> annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 22 commits:
>
> - Me
On Mon, 10 Feb 2025 09:17:51 GMT, Per Minborg wrote:
> This PR seems to be targeting performance, yet no benchmarks are provided
> comparing the current vs. proposed branch with respect to performance. We
> need to understand the upside of the proposed changes.
At my request, reimplementing Bi
On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes wrote:
> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>
> JDK-8348190: Framework for tracing makefile inclusion and parsing
>
> The above issue caused problems in the Oracle closed builds and so needs to
> be backed out until that
On Sat, 1 Feb 2025 08:42:32 GMT, Shaojin Wen wrote:
>> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString
>> and BigDecimal::toPlainString performance and reduce duplicate code
>
> Shaojin Wen has updated the pull request with a new target base due to a
> merge or a re
1 - 100 of 1053 matches
Mail list logo
