[jdk21] RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
Clean backport from latest jdk repo to jdk21 for the fix of: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING Testing: - TBD: mach5 tiers 1-5 - Commit messages: - Backport f91e9ba757f04983655c23542e06973805465249 Changes: https://git.openjdk.org/jdk21/pull/43/files Webrev: https://webrevs.openjdk.org/?repo=jdk21=43=00 Issue: https://bugs.openjdk.org/browse/JDK-8309612 Stats: 96 lines in 4 files changed: 76 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk21/pull/43.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/43/head:pull/43 PR: https://git.openjdk.org/jdk21/pull/43
Re: [jdk21] RFR: 8303916: ThreadLists.java inconsistent results
On Fri, 16 Jun 2023 09:15:52 GMT, Kevin Walls wrote: > Clean backport from latest jdk repo to jdk21 for the test change: > 8303916: ThreadLists.java inconsistent results The backport looks clean. Thanks, Serguei - Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk21/pull/24#pullrequestreview-1489465539
Re: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas
wrote:
>> The current implementation for testing generational ZGC with jtreg is
>> implemented with a filter on the mode flag `ZGenerational`. Because of this
>> only environments which set this flag explicitly will run most of the tests.
>> So they get missed in Github Actions and for developers running jtreg
>> locally without supplying the `ZGenerational` flag.
>>
>> The proposed change here is to introduce two new jtreg requirement
>> properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will
>> effectively behave the same as the existing `vm.gc.` flags but also take
>> the specific ZGC mode in account.
>>
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build
>> includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
>>
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and
>> `vm.gc.ZSinglegen` will also be true.
>>
>> If `-XX:{+,-}ZGenerational` is supplied then either `vm.gc.ZGenerational`
>> or `vm.gc.ZSinglegen` be true depending on the flags value.
>>
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen`
>> will be false.
>>
>> This change also splits the relevant tests into two distinct runs for the
>> two modes. And the respective test ids are set to `ZGenerational` or
>> `ZSinglegen` to make it easier to distinguish the runs.
>>
>> This also solves the issue that some compiler tests will never run with
>> generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the
>> current filter `vm.opt.final.ZGenerational` requires the flag to be
>> explicit, but these compiler tests uses `vm.flagless`.
>>
>> The introduction of `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes
>> the way you specify generational / single gen ZGC test with the way it is
>> done for other gcs with `vm.gc.`
>>
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag`
>> to enable checking if `ZGenerational` is default or not.
>>
>> `vm.opt.final.ZGenerational` is still kept because we still have some
>> reasons to filter based on the supplied flags.
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when
>> running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different
>> max heap size for ZGenerational, but it is not the intent to dispatch the
>> test to both G1 and generational ZGC if Generational ZGC is not specified.
>>
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also
>> changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add explicit id to all Skynet.java @test
I have no issues with the enhanced Java 2D tests to cover both generational and
original ZGC.
But I'll leave it to hotspot reviews to formally approve the fix since those
tests are such a tiny part of this.
-
PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1599445397
Re: [jdk21] RFR: 8308499: Test vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java failed: VMDisconnectedException
On Tue, 20 Jun 2023 18:25:02 GMT, Chris Plummer wrote: > Clean backport of [JDK-8308499](https://bugs.openjdk.org/browse/JDK-8308499) Looks good. - Marked as reviewed by kevinw (Committer). PR Review: https://git.openjdk.org/jdk21/pull/41#pullrequestreview-1488944096
[jdk21] RFR: 8308499: Test vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java failed: VMDisconnectedException
Clean backport of [JDK-8308499](https://bugs.openjdk.org/browse/JDK-8308499) - Commit messages: - Backport 79ff72a7762deb6010b57e5ac0ccede3d035ab4c Changes: https://git.openjdk.org/jdk21/pull/41/files Webrev: https://webrevs.openjdk.org/?repo=jdk21=41=00 Issue: https://bugs.openjdk.org/browse/JDK-8308499 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk21/pull/41.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/41/head:pull/41 PR: https://git.openjdk.org/jdk21/pull/41
RFR: 8294316: SA core file support is broken on macosx-x64 starting with macOS 12.x
This is a minor fix to core file reading on macos x. I can confirm that after this fix I can run the problem listed SA core file tests on Ventura. - Commit messages: - 8294316: SA core file support is broken on macosx-x64 starting with macOS 12.x Changes: https://git.openjdk.org/jdk/pull/14569/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14569=00 Issue: https://bugs.openjdk.org/browse/JDK-8294316 Stats: 20 lines in 2 files changed: 7 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/14569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14569/head:pull/14569 PR: https://git.openjdk.org/jdk/pull/14569
Re: RFR: 8242152: SA does not include StackMapTables when dumping .class files
On Tue, 20 Jun 2023 14:02:35 GMT, Ashutosh Mehra wrote: > On another note since you mentioned > [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) I should let you > know I have a fix for it and am planning to open a PR soon. Good news! Never mind and thanks for your notice . - PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1598870945
Re: RFR: 8242152: SA does not include StackMapTables when dumping .class files
On Tue, 20 Jun 2023 11:31:40 GMT, Daohan Qu wrote: > This patch adds `StackMapTable` for the class files generated by `clhsdb`'s > `buildreplayjars` command. This bug manifests itself during my diagnosing > [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be > fixed first. > > I have run jtreg test `tier1-3` of release build on x86 linux finding only > one failure in `tier2` caused by > [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). > `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` > also passed. @quadhier you beat me to this! Changes look good. On another note since you mentioned [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) I should let you know I have a fix for it and am planning to open a PR soon. My bad that I didn't assign that issue to myself before starting working on it. - PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1598858991
Integrated: 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap
On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson wrote: > Generational ZGC changed the location where the heap object iterator called > the visit function. It used to be called when the objects were popped and > then followed, but it was changed so that the function where called > immediately when the objects are marked. This gave the benefit that the > verification code code show exactly what root had a broken object. > Unfortunately, this change started to apply non-GC closure during the root > iteration. This could lead to lock order issues, just like the one described > in the JBS entry. > > This fix moves the visit calls for non-GC closures back to the follow calls. This pull request has now been integrated. Changeset: 4e4e586d Author:Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/4e4e586dac3f4be15a6488a6b72aa9e2cd5d43db Stats: 203 lines in 5 files changed: 103 ins; 37 del; 63 mod 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap Reviewed-by: eosterlund, aboldtch - PR: https://git.openjdk.org/jdk/pull/14518
Re: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap
On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson wrote: > Generational ZGC changed the location where the heap object iterator called > the visit function. It used to be called when the objects were popped and > then followed, but it was changed so that the function where called > immediately when the objects are marked. This gave the benefit that the > verification code code show exactly what root had a broken object. > Unfortunately, this change started to apply non-GC closure during the root > iteration. This could lead to lock order issues, just like the one described > in the JBS entry. > > This fix moves the visit calls for non-GC closures back to the follow calls. Thanks for reviewing! - PR Comment: https://git.openjdk.org/jdk/pull/14518#issuecomment-1598821180
RFR: JDK-8310380: Handle problems in core-related tests on macOS when codesign tool does not work
Currently, a number of tests fail on macOS because they miss the core file
(e.g. serviceability/sa/TestJmapCore.java).
The reason is that configure detects on some setups that codesign does not work
("checking if debug mode codesign is possible... no) .
So adding the needed entitlement to generate cores is not done in the build.
This is currently not checked later in the tests.
But without the entitlement, a core is not generated.
-
Commit messages:
- JDK-8310380
Changes: https://git.openjdk.org/jdk/pull/14562/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=14562=00
Issue: https://bugs.openjdk.org/browse/JDK-8310380
Stats: 36 lines in 3 files changed: 35 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/14562.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/14562/head:pull/14562
PR: https://git.openjdk.org/jdk/pull/14562
RFR: 8242152: SA does not include StackMapTables when dumping .class files
This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first. I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). And `jtreg:test/hotspot/jtreg/serviceability` also passed. - Commit messages: - Add StackMapTable for the class file generated by jhsdb Changes: https://git.openjdk.org/jdk/pull/14556/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14556=00 Issue: https://bugs.openjdk.org/browse/JDK-8242152 Stats: 57 lines in 3 files changed: 57 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14556/head:pull/14556 PR: https://git.openjdk.org/jdk/pull/14556
Re: [jdk21] RFR: 8310187: Improve Generational ZGC jtreg testing
On Tue, 20 Jun 2023 11:17:40 GMT, Axel Boldt-Christmas wrote: > Hi all, > > This pull request contains a backport of commit > [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Axel Boldt-Christmas on 20 Jun > 2023 and was reviewed by Stefan Karlsson, Erik Österlund and Thomas Stuefe. > > Thanks! Looks good. - Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk21/pull/37#pullrequestreview-1487924209
[jdk21] RFR: 8310187: Improve Generational ZGC jtreg testing
Hi all, This pull request contains a backport of commit [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Axel Boldt-Christmas on 20 Jun 2023 and was reviewed by Stefan Karlsson, Erik Österlund and Thomas Stuefe. Thanks! - Commit messages: - Backport a0595761ef35c4eec8cb84326a869b9473cd5bba Changes: https://git.openjdk.org/jdk21/pull/37/files Webrev: https://webrevs.openjdk.org/?repo=jdk21=37=00 Issue: https://bugs.openjdk.org/browse/JDK-8310187 Stats: 619 lines in 70 files changed: 447 ins; 5 del; 167 mod Patch: https://git.openjdk.org/jdk21/pull/37.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/37/head:pull/37 PR: https://git.openjdk.org/jdk21/pull/37
Integrated: 8310187: Improve Generational ZGC jtreg testing
On Fri, 16 Jun 2023 09:14:10 GMT, Axel Boldt-Christmas
wrote:
> The current implementation for testing generational ZGC with jtreg is
> implemented with a filter on the mode flag `ZGenerational`. Because of this
> only environments which set this flag explicitly will run most of the tests.
> So they get missed in Github Actions and for developers running jtreg locally
> without supplying the `ZGenerational` flag.
>
> The proposed change here is to introduce two new jtreg requirement
> properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will
> effectively behave the same as the existing `vm.gc.` flags but also take
> the specific ZGC mode in account.
>
> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build
> includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
>
> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and
> `vm.gc.ZSinglegen` will also be true.
>
> If `-XX:{+,-}ZGenerational` is supplied then either `vm.gc.ZGenerational` or
> `vm.gc.ZSinglegen` be true depending on the flags value.
>
> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen`
> will be false.
>
> This change also splits the relevant tests into two distinct runs for the two
> modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen`
> to make it easier to distinguish the runs.
>
> This also solves the issue that some compiler tests will never run with
> generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the
> current filter `vm.opt.final.ZGenerational` requires the flag to be explicit,
> but these compiler tests uses `vm.flagless`.
>
> The introduction of `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes
> the way you specify generational / single gen ZGC test with the way it is
> done for other gcs with `vm.gc.`
>
> To support this feature the Whitebox API is extended with `isDefaultVMFlag`
> to enable checking if `ZGenerational` is default or not.
>
> `vm.opt.final.ZGenerational` is still kept because we still have some reasons
> to filter based on the supplied flags.
> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running
> with ZGenerational
> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different
> max heap size for ZGenerational, but it is not the intent to dispatch the
> test to both G1 and generational ZGC if Generational ZGC is not specified.
>
> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed
> to not filter but instead dispatch. However unsure if this change should be
> included. The change ...
This pull request has now been integrated.
Changeset: a0595761
Author:Axel Boldt-Christmas
URL:
https://git.openjdk.org/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba
Stats: 619 lines in 70 files changed: 447 ins; 5 del; 167 mod
8310187: Improve Generational ZGC jtreg testing
Reviewed-by: stefank, eosterlund, stuefe
-
PR: https://git.openjdk.org/jdk/pull/14509
Re: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas
wrote:
>> The current implementation for testing generational ZGC with jtreg is
>> implemented with a filter on the mode flag `ZGenerational`. Because of this
>> only environments which set this flag explicitly will run most of the tests.
>> So they get missed in Github Actions and for developers running jtreg
>> locally without supplying the `ZGenerational` flag.
>>
>> The proposed change here is to introduce two new jtreg requirement
>> properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will
>> effectively behave the same as the existing `vm.gc.` flags but also take
>> the specific ZGC mode in account.
>>
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build
>> includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
>>
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and
>> `vm.gc.ZSinglegen` will also be true.
>>
>> If `-XX:{+,-}ZGenerational` is supplied then either `vm.gc.ZGenerational`
>> or `vm.gc.ZSinglegen` be true depending on the flags value.
>>
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen`
>> will be false.
>>
>> This change also splits the relevant tests into two distinct runs for the
>> two modes. And the respective test ids are set to `ZGenerational` or
>> `ZSinglegen` to make it easier to distinguish the runs.
>>
>> This also solves the issue that some compiler tests will never run with
>> generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the
>> current filter `vm.opt.final.ZGenerational` requires the flag to be
>> explicit, but these compiler tests uses `vm.flagless`.
>>
>> The introduction of `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes
>> the way you specify generational / single gen ZGC test with the way it is
>> done for other gcs with `vm.gc.`
>>
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag`
>> to enable checking if `ZGenerational` is default or not.
>>
>> `vm.opt.final.ZGenerational` is still kept because we still have some
>> reasons to filter based on the supplied flags.
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when
>> running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different
>> max heap size for ZGenerational, but it is not the intent to dispatch the
>> test to both G1 and generational ZGC if Generational ZGC is not specified.
>>
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also
>> changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add explicit id to all Skynet.java @test
Thanks for all the reviews.
-
PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1598489642
Re: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
On Mon, 19 Jun 2023 09:04:17 GMT, Thomas Stuefe wrote: > How much time do we spend now in GHAs on the additional Zgenerational tests? > In any case, this makes sense. This adds around 40 more tests per platform. The runtime of GHA seems to have a lot of run to run variance. Most new tests are in the `hs/tier1 gc` which has a lower runtime than a few other jobs. So until the heavies jobs gets split into multiple jobs, this should have a negligible affect the overall GHA runtime - PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1598488556
Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v4]
On Wed, 12 Apr 2023 07:12:10 GMT, Julian Waters wrote: >> C11 has been stable for a long time on all platforms, so native code can use >> the standard alignas operator for alignment requirements > > Julian Waters has updated the pull request incrementally with four additional > commits since the last revision: > > - Restore visCPP > - Restore gcc attribute > - Revert gcc > - Revert Bumping - PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1598236477
Re: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v5]
> C11 has been stable for a long time on all platforms, so native code can use > the standard alignas operator for alignment requirements Julian Waters has updated the pull request incrementally with three additional commits since the last revision: - Whitespace - Revert - _MSC_VER - Changes: - all: https://git.openjdk.org/jdk/pull/13258/files - new: https://git.openjdk.org/jdk/pull/13258/files/e63d5938..2fed50f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=13258=04 - incr: https://webrevs.openjdk.org/?repo=jdk=13258=03-04 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13258/head:pull/13258 PR: https://git.openjdk.org/jdk/pull/13258
Re: RFR: 8309671: Avoid using jvmci.Compiler property to determine if Graal is enabled
On Fri, 9 Jun 2023 12:14:46 GMT, Doug Simon wrote: > > Is JVMCI used by the Graal compiler only? > > So far this is true and will probably remain true for the foreseeable future. > However, the Right Thing to do long term is to add a > `jdk.test.whitebox.code.Compiler.uncommonTrapsHavePreciseBCIs()` method. I created https://bugs.openjdk.org/browse/JDK-8310346 for this enhancement. - PR Comment: https://git.openjdk.org/jdk/pull/14381#issuecomment-1598205886
