On Thu, 8 Feb 2024 14:09:35 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which suggests we speed up the `Zip64SizeTest` using a
>> small-sized ZIP64 ZIP file specifically created to reproduce the issue being
>> tested.
>>
>> The disk space requirement of this test is known to cause
On Thu, 8 Feb 2024 14:09:35 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which suggests we speed up the `Zip64SizeTest` using a
>> small-sized ZIP64 ZIP file specifically created to reproduce the issue being
>> tested.
>>
>> The disk space requirement of this test is known to cause
On Thu, 8 Feb 2024 17:01:15 GMT, Joshua Cao wrote:
>> I think we should step back from benchmarks a bit and examine the various
>> tradeoffs occurring here. Certainly we can speed things up by pre-resizing
>> the map to be larger. However, this can result in a map that is too large
>> for the
> In addition to the goals, scope, motivation, specification and requirement
> notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would
> like to describe the most relevant decisions taken during the implementation
> of this enhancement. These notes are organized by
> Many crypto service classes require a `SecureRandom` object at
> initialization. This test goes through each of them and calculates (generate,
> encrypt, sign,...) twice with the same `SecureRandom` object and ensures the
> output is the same.
Weijun Wang has updated the pull request
On Thu, 8 Feb 2024 20:53:03 GMT, Kevin Driver wrote:
>> Many crypto service classes require a `SecureRandom` object at
>> initialization. This test goes through each of them and calculates
>> (generate, encrypt, sign,...) twice with the same `SecureRandom` object and
>> ensures the output is
On Thu, 8 Feb 2024 20:57:51 GMT, Alexey Semenyuk wrote:
> Tested with the use case from the CR.
>
> The idea of the fix is to prevent grandchildren processes from being
> automatically attached to the job killing all processes attached to it when
> the job object is destroyed.
>
> Filed a
Tests updated to use jtreg vm flags.
Tested by running tests with different flags and tier1.
-
Commit messages:
- 8316451
Changes: https://git.openjdk.org/jdk/pull/17781/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17781=00
Issue:
There are several .sh tests which use ${TESTVMOPTS} only. Updated them to use
${TESTJAVAOPTS} also.
Tested by running them with different options and tier1.
-
Commit messages:
- 8319578: Few java/lang/instrument ignore test.java.opts and accept
test.vm.opts only
Changes:
On Wed, 10 Jan 2024 12:35:56 GMT, Thiago Henrique Hüpner
wrote:
> 8325505: Fix Javadoc ResourceBundle::getString
This pull request has now been integrated.
Changeset: d91fb17a
Author:Thiago Henrique Hüpner
Committer: Naoto Sato
URL:
On Thu, 8 Feb 2024 21:29:19 GMT, Justin Lu wrote:
>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
>> which adds MessageFormat pattern support for the following subformats:
>> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
>> intended to
On Thu, 8 Feb 2024 21:16:45 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move the if-else nFmt checking to a package-private method in NumberFormat
>
>
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
> which adds MessageFormat pattern support for the following subformats:
> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
> intended to provide pattern support for the more recently added JDK
On Thu, 8 Feb 2024 20:37:18 GMT, Justin Lu wrote:
>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
>> which adds MessageFormat pattern support for the following subformats:
>> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
>> intended to
On Thu, 8 Feb 2024 20:57:51 GMT, Alexey Semenyuk wrote:
> Tested with the use case from the CR.
>
> The idea of the fix is to prevent grandchildren processes from being
> automatically attached to the job killing all processes attached to it when
> the job object is destroyed.
>
> Filed a
Tested with the use case from the CR.
Filed a follow-up https://bugs.openjdk.org/browse/JDK-8325525 CR to track
adding a jtreg test for the issue.
-
Commit messages:
- 8325203: System.exit(0) kills the launched 3rd party application
Changes:
On Thu, 8 Feb 2024 16:34:00 GMT, Weijun Wang wrote:
> Many crypto service classes require a `SecureRandom` object at
> initialization. This test goes through each of them and calculates (generate,
> encrypt, sign,...) twice with the same `SecureRandom` object and ensures the
> output is the
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
> which adds MessageFormat pattern support for the following subformats:
> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
> intended to provide pattern support for the more recently added JDK
On Thu, 8 Feb 2024 01:54:45 GMT, Srinivas Vamsi Parasa wrote:
>> Hello Vamsi (@vamsi-parasa),
>>
>> Many thanks for the results! Now we can see that intrinsics are applied in
>> all cases,
>> but there are big differences between the same code.
>>
>> For example,
>> parallelSort REPEATED
On Thu, 8 Feb 2024 17:31:15 GMT, Thiago Henrique Hüpner
wrote:
>> 8325505: Fix Javadoc ResourceBundle::getString
>
> Thiago Henrique Hüpner has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Apply changes from review
Marked as reviewed by
On Thu, 8 Feb 2024 17:31:15 GMT, Thiago Henrique Hüpner
wrote:
>> 8325505: Fix Javadoc ResourceBundle::getString
>
> Thiago Henrique Hüpner has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Apply changes from review
LGTM
-
On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Thu, 11 Jan 2024 16:21:38 GMT, Peter Levart wrote:
>> I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It
>> returns `-1` (meaning that regions are equal) when passing the same instance
>> of MemorySegment as both `srcSegment` and `dstSegment` parameters regardless
> 8325505: Fix Javadoc ResourceBundle::getString
Thiago Henrique Hüpner has updated the pull request incrementally with one
additional commit since the last revision:
Apply changes from review
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17346/files
- new:
On Wed, 10 Jan 2024 12:35:56 GMT, Thiago Henrique Hüpner
wrote:
> 8325505: Fix Javadoc ResourceBundle::getString
Thanks for the fix, looks correct. In addition to the other comment I left, can
you also bump the latter copyright year at the top of the file to 2024.
On Wed, 7 Feb 2024 20:50:57 GMT, Stuart Marks wrote:
>> Joshua Cao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> extract msize variable
>
> I think we should step back from benchmarks a bit and examine the various
> tradeoffs
Many crypto service classes require a `SecureRandom` object at initialization.
This test goes through each of them and calculates (generate, encrypt,
sign,...) twice with the same `SecureRandom` object and ensures the output is
the same.
-
Commit messages:
- initial change
8325505: Fix Javadoc ResourceBundle::getString
-
Commit messages:
- Fix Javadoc ResourceBundle::getString
Changes: https://git.openjdk.org/jdk/pull/17346/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17346=00
Issue: https://bugs.openjdk.org/browse/JDK-8325505
Stats: 1
On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Once more, remove AIX dirent64 et al defines
>
> And also `#define statvfs statvfs64` is not necessary with the
On Thu, 8 Feb 2024 14:09:35 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which suggests we speed up the `Zip64SizeTest` using a
>> small-sized ZIP64 ZIP file specifically created to reproduce the issue being
>> tested.
>>
>> The disk space requirement of this test is known to cause
> Please review this PR which suggests we speed up the `Zip64SizeTest` using a
> small-sized ZIP64 ZIP file specifically created to reproduce the issue being
> tested.
>
> The disk space requirement of this test is known to cause problems in some
> builds, see
On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Once more, remove AIX dirent64 et al defines
>
> And also `#define statvfs statvfs64` is not necessary with the
ClassFile API provides two sets of instructions implementations (bound and
unbound).
Unbound implementation of `IncrementInstruction::constant` returns invalid
value.
This bug discovered a hole in the ClassFile API test coverage.
This patch provides very simple fix of `IncrementInstruction`
On Thu, 1 Feb 2024 12:07:52 GMT, Per Minborg wrote:
> 8325001: Typo in the javadocs for the Arena::ofShared method
This pull request has now been integrated.
Changeset: 6d9a50ea
Author:Per Minborg
URL:
https://git.openjdk.org/jdk22/commit/6d9a50ea148c1c37b9a1d0475d4aae78ea8f822b
Hello Thomas, hello Core-Libs-Dev,
thank you for cc'ing my email. In deed my idea/suggestion is to modify
the AbstractQueuedSynchronizer$ConditionNode handling in such a way that
it gets unlinked from the chain of condition nodes if it is not needed
any more (it might be the "nextWaiter" node),
On Thu, 1 Feb 2024 12:07:52 GMT, Per Minborg wrote:
> 8325001: Typo in the javadocs for the Arena::ofShared method
Marked as reviewed by mcimadamore (Reviewer).
-
PR Review: https://git.openjdk.org/jdk22/pull/100#pullrequestreview-1869843579
On Wed, 31 Jan 2024 13:04:07 GMT, Per Minborg wrote:
> This PR proposes to implement `hashCode()` and `equals()` methods for
> implementations of `PathElement`.
>
> In doing so, the previous `PathElementImpl` was removed and replaced in favor
> of distinct `record` implementations, each
Hi,
since this looks like a suggestion for a change to the libraries
similar to the mentioned JDK-6805775, and not actually GC, cc'ing the
core-libs-dev mailing list.
Hth,
Thomas
On 07.02.24 15:20, Frank Kretschmer wrote:
Hi Java GC-experts,
I'm facing an interesting G1 garbage
On Wed, 7 Feb 2024 15:18:09 GMT, Roger Riggs wrote:
>> Would it work with custom implementations for say NumberFormat via the SPI?
>
> Just moving the if...then... else code to a package-private static method in
> the respective XXFormat class would work the same.
> I had not thought of an
On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken wrote:
>>> I hope finally the AIX part of this PR is done.
>>
>> Thanks for the AIX related effort ; I put it again into our internal
>> build/test queue.
>
>>
>> Thanks for the AIX related effort ; I put it again into our internal
>>
On Wed, 7 Feb 2024 08:45:40 GMT, Johny Jose wrote:
> Timezone data 2024a changes
This pull request has now been integrated.
Changeset: 917838e0
Author:Johny Jose
Committer: Sean Coffey
URL:
https://git.openjdk.org/jdk/commit/917838e0a564b1f2cbfb6cc214ccbfd1a237019f
Stats: 195
On Sat, 3 Feb 2024 11:28:51 GMT, ExE Boss wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make all PathElements records
>
> src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 494:
>
>> 492:
> This PR proposes to implement `hashCode()` and `equals()` methods for
> implementations of `PathElement`.
>
> In doing so, the previous `PathElementImpl` was removed and replaced in favor
> of distinct `record` implementations, each reflecting its own path element
> selection type. This also
On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken wrote:
> On some Windows machines we see sometimes OOM errors because of high resource
> (memory/swap) consumption. This is especially seen when the jtreg runs have
> higher concurrency. A solution is to put the java/lang/StringBuilder tests
45 matches
Mail list logo
