Re: RFR: 8303916: ThreadLists.java inconsistent results
On Thu, 15 Jun 2023 09:17:24 GMT, Kevin Walls wrote: > I did look at the history and this test exists because of previous confusion > about thread groups, where the top thread group and the MXBean thread lists > could be different. So if this test creates new threads and checks they are > in both lists, it loses the original purpose as I read it. Can you elaborate what the issue was please. I would have to suspect the wrong "top" ThreadGroup was being used (main vs. system). - PR Comment: https://git.openjdk.org/jdk/pull/14465#issuecomment-1596332757
Re: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v10]
On Sat, 17 Jun 2023 01:22:54 GMT, Alex Menkov wrote: > This change adds new option. most likely this requires CSR Hi @alexmenkov, it seems that adding new parameters to jcmd does not require a CSR, only changes like those to jmap do. - PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1233444531
Integrated: JDK-8310191: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on AIX
On Fri, 16 Jun 2023 10:44:47 GMT, Matthias Baesken wrote: > After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , > the following test started to fail on AIX : > com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output : > > java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded > dynamically' found in stderr > at > jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320) > at > DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308) > at > DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > > Should be handled in a similar way to > [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) . This pull request has now been integrated. Changeset: 6a63badd Author:Matthias Baesken URL: https://git.openjdk.org/jdk/commit/6a63badd8ea3e79cd9fc3cb33aff499fc9a6d3f1 Stats: 20 lines in 1 file changed: 8 ins; 8 del; 4 mod 8310191: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on AIX Reviewed-by: alanb, cjplummer - PR: https://git.openjdk.org/jdk/pull/14515
Re: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
> 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.ZSingelgen` will be true.
>
> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and
> `vm.gc.ZSingelgen` will also be true.
>
> If `-XX:{+,-}ZGenerational` is supplied then either `vm.gc.ZGenerational` or
> `vm.gc.ZSingelgen` be true depending on the flags value.
>
> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`
> 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.ZSingelgen` 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 ...
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
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14509/files
- new: https://git.openjdk.org/jdk/pull/14509/files/e571b87f..b262d48b
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=01-02
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/14509.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/14509/head:pull/14509
PR: https://git.openjdk.org/jdk/pull/14509
