On Wed, 15 Jan 2025 14:14:37 GMT, Richard Reingruber wrote:
> This PR reverts the fix from
> [JDK-8339166](https://bugs.openjdk.org/browse/JDK-8339166) because it
> increases the runtime of the test a lot.
> Instead a full gc is requested via the whitebox api. This solves the issues
> (see bug
On Thu, 16 Jan 2025 18:37:36 GMT, Tom Rodriguez wrote:
>> Deoptimization with escape analysis can fail when trying to rematerialize
>> objects as described in JDK-8227309. In this test this can happen in Xcomp
>> mode in the framework of the test resulting in a test failure. Making the
>> nu
I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()`
with Java code. This removes hacks in
`SystemDictionary::resolve_with_circularity_detection()` to facilitate future
clean-ups there that are planned by @coleenp. Please see the [JBS
issue](https://bugs.openjdk.org/b
Just wanted to say, I've been experimenting with replacing ThreadLocal
with ScopedValue, this is a great new API, I love the way ScopedValue
uses recursion, we can have multiple immutable instances representing a
scoped value for a short period and we're not worried about managing
state as it g
On Tue, 21 Jan 2025 23:48:14 GMT, Vladimir Ivanov wrote:
>> The synchronized scope was reduced from whole methods to sections that need
>> hash map access control. The tier1 and jaxp tests are OK. The score of the
>> specjvm2008:xml.transform improved a little bit. On the Xeon 8480+ reported
>
> The synchronized scope was reduced from whole methods to sections that need
> hash map access control. The tier1 and jaxp tests are OK. The score of the
> specjvm2008:xml.transform improved a little bit. On the Xeon 8480+ reported
> scores are:
> original: 1vCPU - 148.4, 112vCPU - 12743.4, 224
On Tue, 21 Jan 2025 13:03:45 GMT, Johny Jose wrote:
> Changes to Update Timezone Data to 2025a
Marked as reviewed by coffeys (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/23212#pullrequestreview-2565771402
On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik wrote:
>> Some VM flags might depend on the environment and it makes sense to log
>> final flags so it is possible to get their value when investigating failures.
>>
>> I added them to VMProps, so it is always dump final flags before running
>> t
On Sun, 12 Jan 2025 06:08:02 GMT, Leonid Mesnik wrote:
> Some VM flags might depend on the environment and it makes sense to log final
> flags so it is possible to get their value when investigating failures.
>
> I added them to VMProps, so it is always dump final flags before running
> tests
On Wed, 8 Jan 2025 20:13:50 GMT, Hannes Wallnöfer wrote:
> Please review a doc-only change to mostly add missing `@serial` javadoc tags.
> This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc
> `-serialwarn` option in the JDK doc build, which has been disabled since JDK
> 1
On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote:
> Please review this PR which contains the l10n translations for between RDP1
> and RDP2 for the JDK24 stabilization branch.
>
> Note that these translations are only associated with changes made to the
> stabilization branch. This PR will not
On Tue, 21 Jan 2025 13:24:41 GMT, Matthias Baesken wrote:
> We were running into this error :
> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>
> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from
> address 0x34144e30 (expected type Ja
On Tue, 14 Jan 2025 21:47:06 GMT, Brian Burkhalter wrote:
> Fix the means of determining whether an exception is to be expected in the
> Windows test.
This pull request has now been integrated.
Changeset: f2a9d26b
Author:Brian Burkhalter
URL:
https://git.openjdk.org/jdk/commit/f2a9
On Tue, 21 Jan 2025 18:34:52 GMT, Daniel Jeliński wrote:
> LGTM.
Thanks for the re-review!
-
PR Comment: https://git.openjdk.org/jdk/pull/23117#issuecomment-2605526172
On Thu, 16 Jan 2025 23:38:48 GMT, Naoto Sato wrote:
> This fix is a follow on for
> [JDK-8342550](https://bugs.openjdk.org/browse/JDK-8342550). Replaces/Removes
> usages of those deprecated time zone ids in tests.
This pull request has now been integrated.
Changeset: 81912e95
Author:Naoto
On Sat, 18 Jan 2025 01:29:01 GMT, Chen Liang wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> provide message for test assertion
>
> src/java.base/share/classes/java/util/Currency.java line 469:
>
>> 467:
>> 468:
On Mon, 20 Jan 2025 09:46:05 GMT, Viktor Klang wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> provide message for test assertion
>
> src/java.base/share/classes/java/util/Currency.java line 494:
>
>> 492:
>> 493:
> Please review this PR and CSR which adds a method to _java.util.Currency_
> which returns a stream of the available Currencies.
>
> The motivation can be found in the CSR.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
reflect feedb
On Fri, 17 Jan 2025 20:27:54 GMT, Brian Burkhalter wrote:
>> Fix the means of determining whether an exception is to be expected in the
>> Windows test.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8347740: Remove v
On Fri, 17 Jan 2025 00:45:54 GMT, Naoto Sato wrote:
>> This fix is a follow on for
>> [JDK-8342550](https://bugs.openjdk.org/browse/JDK-8342550). Replaces/Removes
>> usages of those deprecated time zone ids in tests.
>
> Naoto Sato has updated the pull request incrementally with one additional
On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote:
> Please review this PR which contains the l10n translations for between RDP1
> and RDP2 for the JDK24 stabilization branch.
>
> Note that these translations are only associated with changes made to the
> stabilization branch. This PR will not
On Tue, 21 Jan 2025 17:04:01 GMT, Jorn Vernee wrote:
> Talking to Maurizio offline, and we realized that if we just pin the
> continuation when we acquire the buffer, and unpin when releasing, we don't
> have to worry about buffers floating between threads between acquire &
> release, and we c
On Fri, 17 Jan 2025 23:53:06 GMT, Naoto Sato wrote:
> IANAL, but my understanding is that it reflects the year the last change was
> open to the public. It does not seem to matter from copyright point if the
> file is a translation of English one or not.
While that has been my understanding as
On Mon, 20 Jan 2025 18:43:54 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Thu, 16 Jan 2025 18:37:36 GMT, Tom Rodriguez wrote:
>> Deoptimization with escape analysis can fail when trying to rematerialize
>> objects as described in JDK-8227309. In this test this can happen in Xcomp
>> mode in the framework of the test resulting in a test failure. Making the
>> nu
On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik wrote:
>> Some VM flags might depend on the environment and it makes sense to log
>> final flags so it is possible to get their value when investigating failures.
>>
>> I added them to VMProps, so it is always dump final flags before running
>> t
On Tue, 21 Jan 2025 13:56:30 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which updates a total of 12 links to external
>> documentation or references in `java.base` to use https instead of plain
>> text http.
>>
>> Links in `java.security` and `share/data/tzdata` are excluded f
On Tue, 21 Jan 2025 13:45:50 GMT, Alan Bateman wrote:
> Okay, there is much more significant change now and will require time to
> review very closely.
Sure. I was hoping we could avoid changing the feedback path in allocation
code, but testing disagreed :)
I remember when we built that feedb
> Please review this cleanup PR which updates a total of 12 links to external
> documentation or references in `java.base` to use https instead of plain text
> http.
>
> Links in `java.security` and `share/data/tzdata` are excluded from this PR.
>
> This is a documentaton-only cleanup. No tests
On Tue, 21 Jan 2025 12:55:31 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Tue, 21 Jan 2025 06:51:10 GMT, Thomas Stuefe wrote:
> > @tstuefe And you also agree that the link should be removed? (Which is what
> > this PR is about)
>
> The 20+ years old link to the PASC error report I would probably remove; it
> is likely outdated now. If one wanted to invest the tim
> Please review this cleanup PR which updates a total of 12 links to external
> documentation or references in `java.base` to use https instead of plain text
> http.
>
> Links in `java.security` and `share/data/tzdata` are excluded from this PR.
>
> This is a documentaton-only cleanup. No tests
We were running into this error :
sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
stderr: [java.lang.RuntimeException: Unable to deduce type of thread from
address 0x34144e30 (expected type JavaThread, CompilerThread,
MonitorDeflationThread, AttachListenerThrea
Changes to Update Timezone Data to 2025a
-
Commit messages:
- 8347965: (tz) Update Timezone Data to 2025a
Changes: https://git.openjdk.org/jdk/pull/23212/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23212&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8347965
St
> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
> implementation. That implementation carries a doubly-linked list, and so
> makes DBB suffer from the same issue fixed for generic
> `java.lang.ref.Cleaner` users with
> [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704
On Tue, 21 Jan 2025 09:46:58 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Tue, 21 Jan 2025 09:46:58 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
Hi Daniel,
Making changes locally and use the tests to verify your assumptions is a great
way to validate your understanding.
Then you can use the benches to validate the performance impact of your
modifications, then it becomes easier to discuss the pros/cons of potential
changes here on the
On Tue, 21 Jan 2025 03:05:06 GMT, Tom Rodriguez wrote:
>> Tom Rodriguez 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 three additional
>> comm
On Thu, 14 Nov 2024 21:34:08 GMT, Larry Cable wrote:
> c.f:
> [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420)
>
> Summary
> ---
>
> Add `jcmd Thread.vthread_summary` to print summary information that is
> useful when trying to diagnose issues wi
On Mon, 20 Jan 2025 19:12:22 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
> implementation. That implementation carries a doubly-linked list, and so
> makes DBB suffer from the same issue fixed for generic
> `java.lang.ref.Cleaner` users with
> [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704
On Wed, 15 Jan 2025 14:14:37 GMT, Richard Reingruber wrote:
> This PR reverts the fix from
> [JDK-8339166](https://bugs.openjdk.org/browse/JDK-8339166) because it
> increases the runtime of the test a lot.
> Instead a full gc is requested via the whitebox api. This solves the issues
> (see bug
Wouldn't this already be possible with today's union types?
static & SequencedSet> S of(E... elements) { ... }
Then again, I do not think that the regular Set and Map implementations
should be sequenced, mainly to avoid that tests suffer from this sequencing.
Am So., 19. Jan. 2025 um 16:18 Uhr
On Tue, 21 Jan 2025 08:14:22 GMT, Matthias Baesken wrote:
> LGTM; probably you do not need 2000 iterations now with the full GC, a
> smaller number would do as well, correct ? But it is okay for me as it is.
Thanks for reviewing. I've tried 1000 iterations but the runtime hardly changed
so I r
On Tue, 14 Jan 2025 04:08:28 GMT, Claes Redestad wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix comment
>
> Always good to see some methods removed from `JavaLangAccess` - but it
> appears these are already un
On Mon, 20 Jan 2025 14:32:22 GMT, Shaojin Wen wrote:
>> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
>> offset overflow issue has been fixed.
>>
>> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication.
>>
>> 2) HexDigi
On Wed, 15 Jan 2025 14:14:37 GMT, Richard Reingruber wrote:
> This PR reverts the fix from
> [JDK-8339166](https://bugs.openjdk.org/browse/JDK-8339166) because it
> increases the runtime of the test a lot.
> Instead a full gc is requested via the whitebox api. This solves the issues
> (see bug
48 matches
Mail list logo
