On Tue, 9 Apr 2024 01:27:29 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test-only change which proposes to address
>> the intermittent failures in
>> `java/util/Properties/StoreReproducibilityTest.java`? This should address
>> https://bugs.openjdk.org/browse/JDK-8329729.
>>
On Tue, 23 Jan 2024 13:04:43 GMT, SendaoYan wrote:
>> 8323640: [TESTBUG]testMemoryFailCount in
>> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail
>> because OOM killed
>
> SendaoYan has updated the pull request incrementally with one additional
> commit since the last
On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan wrote:
> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all
> the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
>
>
On Mon, 11 Mar 2024 15:15:39 GMT, Naoto Sato wrote:
> LGTM
@naotoj Thanks for the review.
-
PR Comment: https://git.openjdk.org/jdk/pull/18155#issuecomment-2043989340
On Sat, 9 Mar 2024 13:18:14 GMT, SendaoYan wrote:
>> Date.toString() uses Locale.US explicitly for printing the time zone, so
>> replace Locale.ROOT to Locale.US in this testcase for fix the test failure.
>>
>> This testcase fixed has been verified.
>>
>> Only change the testcase, risk is
On Tue, 9 Apr 2024 00:52:43 GMT, Jaikiran Pai wrote:
>> The code should reference the constants in Instant.java (though may need to
>> make them package private.)
>>
>> The javadoc can/should reference Instant.MIN and Instant.MAX (as the test
>> does).
>
> Hello Roger,
>
>> The code should
> Can I please get a review of this test-only change which proposes to address
> the intermittent failures in
> `java/util/Properties/StoreReproducibilityTest.java`? This should address
> https://bugs.openjdk.org/browse/JDK-8329729.
>
> These failures in `StoreReproducibilityTest` have been
Can I please get a review of this test-only change which proposes to address
the intermittent failures in
`java/util/Properties/StoreReproducibilityTest.java`? This should address
https://bugs.openjdk.org/browse/JDK-8329729.
These failures in `StoreReproducibilityTest` have been observed in
On Mon, 8 Apr 2024 18:16:04 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/java/time/temporal/ChronoField.java line 590:
>>
>>> 588: * This is necessary to ensure interoperation between calendars.
>>> 589: */
>>> 590: // ValueRange matches the min and max epoch second
On Mon, 8 Apr 2024 19:11:19 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall
On Mon, 8 Apr 2024 10:50:00 GMT, Evgeny Nikitin wrote:
> Improve RNG usage in said tests:
>
> 1. The RNG is not created by our Utils class, as suggested in our JTReg tests;
> 2. The seed, accordingly, is not a fixed value now, but truly random;
> 3. The tests that had been creating their own
Improve RNG usage in said tests:
1. The RNG is not created by our Utils class, as suggested in our JTReg tests;
2. The seed, accordingly, is not a fixed value now, but truly random;
3. The tests that had been creating their own Random instances, are now using
RAND static member from the
>"could" not "would"?
If the operation is strictly many-to-one, then it will always emit a single
element, this means that it might need to track as a part of its state whether
it has emitted something in its integrator and if not then emit it in the
finisher.
But I, guess that one could
On Mon, 8 Apr 2024 18:44:51 GMT, Suchismith Roy wrote:
>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request
> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
> this change.
>
> Overall, making this an intrinsic improves overall performance of
> `Unsafe::setMemory` by up to 4x for all buffer sizes.
> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
Suchismith Roy has updated the pull request incrementally with one additional
commit since the last revision:
> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
Suchismith Roy has updated the pull request incrementally with one additional
commit since the last revision:
> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
Suchismith Roy has updated the pull request incrementally with one additional
commit since the last revision:
On Mon, 8 Apr 2024 18:00:02 GMT, Naoto Sato wrote:
>> Can I please get a review of this change which proposes to fix the issue
>> noted in https://bugs.openjdk.org/browse/JDK-8212895?
>>
>> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is
>> initialized to have a minimum
> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
Suchismith Roy has updated the pull request incrementally with one additional
commit since the last revision:
On Mon, 8 Apr 2024 09:52:39 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the issue
> noted in https://bugs.openjdk.org/browse/JDK-8212895?
>
> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is
> initialized to have a minimum
On Fri, 5 Apr 2024 17:44:38 GMT, Roger Riggs wrote:
> When encoding a vary large string in String.getBytes(StandardCharset.UTF_8)
> computation of the buffer size may exceed the range of a positive 32-bit
> Integer.
> If the estimated size for the result byte array is too large, pre-compute
On Fri, 5 Apr 2024 18:14:36 GMT, Suchismith Roy wrote:
>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request
On Mon, 8 Apr 2024 16:21:19 GMT, Jan Lahoda wrote:
>> This is a patch for javac, that adds the Derived Record Creation
>> expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>>
>> The
Filter isn't many-to-... At all, at no point it collapses a
subsequence of elements, it only works on one element at a time
I was conflating the behavior of a specific intermediate operation with
a black box view of an operation. Looking at an operation as a black box
is useless (maybe mildly
On Fri, 5 Apr 2024 17:22:36 GMT, Naoto Sato wrote:
> Fix a file/class name in the `CLDRConverter` build tool, with some clean-up
> for a switch statement.
This pull request has now been integrated.
Changeset: dd930c57
Author:Naoto Sato
URL:
On Fri, 5 Apr 2024 17:22:36 GMT, Naoto Sato wrote:
> Fix a file/class name in the `CLDRConverter` build tool, with some clean-up
> for a switch statement.
Thanks for the reviews!
-
PR Comment: https://git.openjdk.org/jdk/pull/18662#issuecomment-2043177032
> This is a patch for javac, that adds the Derived Record Creation expressions.
> The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>
> The current CSR is here:
>
On Fri, 5 Apr 2024 17:44:38 GMT, Roger Riggs wrote:
> When encoding a vary large string in String.getBytes(StandardCharset.UTF_8)
> computation of the buffer size may exceed the range of a positive 32-bit
> Integer.
> If the estimated size for the result byte array is too large, pre-compute
On Mon, 8 Apr 2024 13:46:03 GMT, Roger Riggs wrote:
>> Indeed, different OOMEs are thrown in the two cases triggered by different
>> limits, min +2 is due to integer overflow, while min +1 is due a VM limit
>> on the size of byte[Integer.MAX_VALUE]. Different VM implementations may
>> have
On Fri, 5 Apr 2024 18:28:58 GMT, Jan Lahoda wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 4443:
>>
>>> 4441: }
>>> 4442:
>>> 4443: @Override
>>
>> As usual, I suggest to add some brief comment with the shape of the
>> generated code.
>
> Done here:
On Mon, 8 Apr 2024 13:39:34 GMT, Roger Riggs wrote:
>> test/jdk/java/lang/String/CompactString/MaxSizeUTF16String.java line 143:
>>
>>> 141: // Strings of size min+1...min+2, throw OOME
>>> 142: // The resulting byte array would exceed implementation limits
>>> 143: for
On Mon, 8 Apr 2024 08:54:21 GMT, Raffaello Giulietti
wrote:
>> When encoding a vary large string in String.getBytes(StandardCharset.UTF_8)
>> computation of the buffer size may exceed the range of a positive 32-bit
>> Integer.
>> If the estimated size for the result byte array is too large,
On Fri, 5 Apr 2024 18:14:36 GMT, Suchismith Roy wrote:
>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request
On Mon, 8 Apr 2024 09:52:39 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the issue
> noted in https://bugs.openjdk.org/browse/JDK-8212895?
>
> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is
> initialized to have a minimum
On Fri, 5 Apr 2024 18:14:36 GMT, Suchismith Roy wrote:
>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request
On Fri, 5 Apr 2024 18:14:36 GMT, Suchismith Roy wrote:
>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request
Can I please get a review of this change which proposes to fix the issue noted
in https://bugs.openjdk.org/browse/JDK-8212895?
As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is
initialized to have a minimum and maximum values of `Long.MIN_VALUE` and
`LONG.MAX_VALUE`
On Fri, 5 Apr 2024 17:44:38 GMT, Roger Riggs wrote:
> When encoding a vary large string in String.getBytes(StandardCharset.UTF_8)
> computation of the buffer size may exceed the range of a positive 32-bit
> Integer.
> If the estimated size for the result byte array is too large, pre-compute
39 matches
Mail list logo
