Re: RFR: 8288907: serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java fails with -XX:TieredStopAtLevel=2,3
On Thu, 29 Sep 2022 07:21:46 GMT, Serguei Spitsyn wrote:
> The test SuspendResume fails on linux-aarch64 with timeouts.
> However, it never fails when test timeout is set to a bigger value:
>
> diff --git
> a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
>
> b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
> index cd5b8251fce..562f2eae921 100644
> ---
> a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
> +++
> b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
> @@ -29,7 +29,7 @@
> * @library /test/lib
> * @compile --enable-preview -source ${jdk.version} SuspendResume1.java
> * @run driver jdk.test.lib.FileInstaller . .
> - * @run main/othervm/native
> + * @run main/othervm/native/timeout=600
> * --enable-preview
> * -Djava.util.concurrent.ForkJoinPool.common.parallelism=1
> * -agentlib:SuspendResume1
>
>
> I'd like to push this as a trivial fix.
>
> Testing: Submitted mach5 test runs on multiple platforms.
Thank you for the comment, Chris. I agree, this test is executed on
linux-aarch64 much slower than on other platforms. Now, I can move this bug to
the Compiler team plate or push my fix and open a Compiler bug separately. It
feels like you prefer the former.
-
PR: https://git.openjdk.org/jdk/pull/10480
Re: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE
On Fri, 30 Sep 2022 04:37:58 GMT, David Holmes wrote: > Why is `JVMTI_ERROR_WRONG_PHASE` a valid result here? I think, it is because the testing `suspendResumeThread` tread is a daemon thread. I'm not sure why it was set to be a daemon thread though. - PR: https://git.openjdk.org/jdk/pull/10502
Re: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE
On Fri, 30 Sep 2022 01:32:44 GMT, Leonid Mesnik wrote: > 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: > JVMTI_ERROR_WRONG_PHASE Why is `JVMTI_ERROR_WRONG_PHASE` a valid result here? - PR: https://git.openjdk.org/jdk/pull/10502
Re: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to >> URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before >> any push. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > http -> https Marked as reviewed by iris (Reviewer). src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: > 32: * the following link: > 33: * > 34: * > http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c The domain for hg wasn't changed to openjdk.org. The original URL is correct. - PR: https://git.openjdk.org/jdk/pull/10501
Re: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
On Fri, 30 Sep 2022 00:48:02 GMT, Mikael Vidstedt wrote: > Switch to https where needed/applicable while at it? Good idea; might as well do the update in a single changeset. - PR: https://git.openjdk.org/jdk/pull/10501
Re: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
> With the domain change from openjdk.java.net to openjdk.org, references to > URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before > any push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: http -> https - Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/04dfc3ef..cee96d0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02-03 Stats: 22 lines in 6 files changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501
Re: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v3]
> With the domain change from openjdk.java.net to openjdk.org, references to > URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before > any push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Undo manpage update. - Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/2f257762..04dfc3ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501
Re: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy wrote: > With the domain change from openjdk.java.net to openjdk.org, references to > URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before > any push. Switch to https where needed/applicable while at it? - PR: https://git.openjdk.org/jdk/pull/10501
Re: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2]
On Fri, 30 Sep 2022 00:50:13 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to >> URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before >> any push. > > Joe Darcy has updated the pull request incrementally with two additional > commits since the last revision: > > - Update copyright. > - Revert unintended update to binary file. Marked as reviewed by mikael (Reviewer). - PR: https://git.openjdk.org/jdk/pull/10501
Re: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2]
> With the domain change from openjdk.java.net to openjdk.org, references to > URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before > any push. Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Update copyright. - Revert unintended update to binary file. - Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/b12d774f..2f257762 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00-01 Stats: 10 lines in 11 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501
RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. Updates were made using a shell script. I"ll run a copyright updater before any push. - Commit messages: - JDK-8294618: Update openjdk.java.net => openjdk.org Changes: https://git.openjdk.org/jdk/pull/10501/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294618 Stats: 79 lines in 39 files changed: 0 ins; 0 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501
Re: RFR: 8289711: Add container configuration data to mbeans [v10]
On Wed, 10 Aug 2022 02:10:25 GMT, xpbob wrote:
>> Container configuration information is useful for troubleshooting
>> problems,Exposing information in MBeans is ideal for monitoring, jConsole,
>> and other scenarios.
>> Results the following
>> 
>
> xpbob has updated the pull request incrementally with one additional commit
> since the last revision:
>
> add bean to list
src/jdk.management/share/classes/com/sun/management/ContainerInfoMXBean.java
line 31:
> 29: * This is a special bean , only available on Linux systems
> 30: */
> 31: public interface ContainerInfoMXBean extends PlatformManagedObject {
let's remove one redundant space before `extends`
-
PR: https://git.openjdk.org/jdk/pull/9372
Integrated: 8294547: HotSpotAgent.setupVM() should include "cause" exception when throwing DebuggerException
On Wed, 28 Sep 2022 22:38:44 GMT, Chris Plummer wrote: > In `HotSpotAgent.setupVM()`, if there is an underlying exception in the vm > setup, the exception is consumed and a `DebuggerException` is thrown, hiding > the root cause. When throwing the `DebuggerException`, the "cause" exception > should be included. This provides a more detailed exception stack trace, such > as the following: > > > Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in > remote process) > sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM > (could not find symbol "gHotSpotVMTypes" in remote process) > at > jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:428) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:338) > at > jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:158) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:210) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:69) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) > Caused by: sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not find > symbol "gHotSpotVMTypes" in any of the known library names (jvm.dll) > at > jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.lookupInProcess(HotSpotTypeDataBase.java:622) > at > jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:154) > at > jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.(HotSpotTypeDataBase.java:89) > at > jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:407) > ... 7 more > > > I'd like to push this as a trivial change. This pull request has now been integrated. Changeset: 5f6ad926 Author:Chris Plummer URL: https://git.openjdk.org/jdk/commit/5f6ad926d7ea763bf61aa98c7be7087a7aa6089c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8294547: HotSpotAgent.setupVM() should include "cause" exception when throwing DebuggerException Reviewed-by: sspitsyn, coleenp - PR: https://git.openjdk.org/jdk/pull/10474
Integrated: 8294548: Problem list SA core file tests on macosx-x64 due to JDK-8294316
On Wed, 28 Sep 2022 23:32:24 GMT, Chris Plummer wrote: > The SA core file tests are already problem listed on macosx-x64 due to > [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433), but they should > also be due to [JDK-8294316](https://bugs.openjdk.org/browse/JDK-8294316), > which is actually the much more serious of the two issues. > > I'd like to push this as a trivial change. This pull request has now been integrated. Changeset: 545ded1a Author:Chris Plummer URL: https://git.openjdk.org/jdk/commit/545ded1a82baf62ef551b2be2a08ee29ab5d9311 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod 8294548: Problem list SA core file tests on macosx-x64 due to JDK-8294316 Reviewed-by: sspitsyn - PR: https://git.openjdk.org/jdk/pull/10476
Re: RFR: 8294547: HotSpotAgent.setupVM() should include "cause" exception when throwing DebuggerException
On Wed, 28 Sep 2022 22:38:44 GMT, Chris Plummer wrote: > In `HotSpotAgent.setupVM()`, if there is an underlying exception in the vm > setup, the exception is consumed and a `DebuggerException` is thrown, hiding > the root cause. When throwing the `DebuggerException`, the "cause" exception > should be included. This provides a more detailed exception stack trace, such > as the following: > > > Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in > remote process) > sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM > (could not find symbol "gHotSpotVMTypes" in remote process) > at > jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:428) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:338) > at > jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:158) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:210) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:69) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) > Caused by: sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not find > symbol "gHotSpotVMTypes" in any of the known library names (jvm.dll) > at > jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.lookupInProcess(HotSpotTypeDataBase.java:622) > at > jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:154) > at > jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.(HotSpotTypeDataBase.java:89) > at > jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:407) > ... 7 more > > > I'd like to push this as a trivial change. Thank you! - Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/10474
Re: RFR: 8288907: serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java fails with -XX:TieredStopAtLevel=2,3
On Thu, 29 Sep 2022 07:21:46 GMT, Serguei Spitsyn wrote:
> The test SuspendResume fails on linux-aarch64 with timeouts.
> However, it never fails when test timeout is set to a bigger value:
>
> diff --git
> a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
>
> b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
> index cd5b8251fce..562f2eae921 100644
> ---
> a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
> +++
> b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
> @@ -29,7 +29,7 @@
> * @library /test/lib
> * @compile --enable-preview -source ${jdk.version} SuspendResume1.java
> * @run driver jdk.test.lib.FileInstaller . .
> - * @run main/othervm/native
> + * @run main/othervm/native/timeout=600
> * --enable-preview
> * -Djava.util.concurrent.ForkJoinPool.common.parallelism=1
> * -agentlib:SuspendResume1
>
>
> I'd like to push this as a trivial fix.
>
> Testing: Submitted mach5 test runs on multiple platforms.
I also tried the same with product builds. linux-aarch64 got worse, with 4 out
of 5 timing out. linux-x64 improved with only one run over 1m.
-
PR: https://git.openjdk.org/jdk/pull/10480
Re: RFR: 8288907: serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java fails with -XX:TieredStopAtLevel=2,3
On Thu, 29 Sep 2022 07:21:46 GMT, Serguei Spitsyn wrote:
> The test SuspendResume fails on linux-aarch64 with timeouts.
> However, it never fails when test timeout is set to a bigger value:
>
> diff --git
> a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
>
> b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
> index cd5b8251fce..562f2eae921 100644
> ---
> a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
> +++
> b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
> @@ -29,7 +29,7 @@
> * @library /test/lib
> * @compile --enable-preview -source ${jdk.version} SuspendResume1.java
> * @run driver jdk.test.lib.FileInstaller . .
> - * @run main/othervm/native
> + * @run main/othervm/native/timeout=600
> * --enable-preview
> * -Djava.util.concurrent.ForkJoinPool.common.parallelism=1
> * -agentlib:SuspendResume1
>
>
> I'd like to push this as a trivial fix.
>
> Testing: Submitted mach5 test runs on multiple platforms.
I'm not so sure increasing the timeout is the right thing to do. Here are the
results of running 5 times on each of our 5 platforms with
`-XX:TieredStopAtLevel=2"`
macosx-aarch64-debug22s
windows-x64-debug 23s
windows-x64-debug 23s
macosx-aarch64-debug23s
macosx-aarch64-debug24s
macosx-aarch64-debug24s
windows-x64-debug 24s
macosx-x64-debug24s
macosx-aarch64-debug25s
macosx-x64-debug26s
macosx-x64-debug26s
macosx-x64-debug26s
macosx-x64-debug26s
windows-x64-debug 28s
windows-x64-debug 33s
linux-x64-debug 43s
linux-x64-debug 45s
linux-aarch64-debug 2m 17s
linux-x64-debug 2m 20s
linux-x64-debug 2m 42s
linux-x64-debug 2m 59s
linux-aarch64-debug 3m 22s
linux-aarch64-debug 4m 31s
linux-aarch64-debug 6m 30s
linux-aarch64-debug 9m 22s
The last one was a timeout. So it seems that linux-aarch64 is consistently
slow. linux-x64 is also a bit slow in some cases. It seems it would be worth
understanding these performance differences.
-
PR: https://git.openjdk.org/jdk/pull/10480
Integrated: 8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace()
On Mon, 26 Sep 2022 14:23:38 GMT, Patricio Chilano Mateo wrote: > Please review this small fix in async_get_stack_trace(). The GrowableArrays > created to store the bci and Method* of each frame found while traversing the > stack are allocated in the resource area of the thread that calls > async_get_stack_trace(). But if the handshake is executed by the target and > if the number of frames in the stack exceeds the initial size of the > GrowableArrays then we will hit an assertion when trying to grow the size of > the arrays (see bug description). > Currently we don't see any issues because the initial size of the > GrowableArrays is 512 and our tests don't test beyond that (the maximum value > of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be > easily reproduced by either decreasing the initial size of the GrowableArrays > or by increasing the value of DEPTH in those strace tests. > To fix it I allocated the arrays in the C heap instead. Also I lowered the > initial size of the arrays since 512 seemed too much to start with. > Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 5d48da45 Author:Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/5d48da4574f6aacb0db445dd5750566330aa383d Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod 8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace() Reviewed-by: dholmes, sspitsyn - PR: https://git.openjdk.org/jdk/pull/10424
Re: RFR: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts [v5]
> Similar issue to the hotspot change discussed in > https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation > may get the resource limits wrong if there are additional cgroup fs mounts. > Apparently that's more common than one might think. I've reproduced this with > these existing tests on cg v2: > > > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java > test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java > > > I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` > and amended > `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which > unconditionally fails (irrespective of cgroup version in use). The fix is > fairly straight forward and is an extension which we already do for the > `cpuset` controller: Allow duplicates, and if there are any prefer those > mounted at `/sys/fs/cgroup`. > > Testing: > - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the > product fix) > - [x] added tests fail before, pass after the product fix. > - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still > pass. > - [x] GHA all pass. > > Please review! Many thanks in advance. Severin Gehwolf 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 commits since the last revision: - Merge branch 'master' into JDK-8293540-metrics-cgroups-mounts - Add comments/@bug in tests - 8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts - Changes: - all: https://git.openjdk.org/jdk/pull/10248/files - new: https://git.openjdk.org/jdk/pull/10248/files/6061a475..3ecb3b9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=03-04 Stats: 30991 lines in 1069 files changed: 14803 ins; 10731 del; 5457 mod Patch: https://git.openjdk.org/jdk/pull/10248.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248 PR: https://git.openjdk.org/jdk/pull/10248
Re: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3]
On Wed, 28 Sep 2022 13:41:06 GMT, Johan Sjölen wrote: >> Or you could have the class that requires dynamic mtFlag be declared with >> mtNone and assert in one place in AllocateHeap that mt != mtNone. Actually >> that assert might already be there. Can't really puzzle out what Kim's >> change does. > > I added a mtInvalid flag and did the assert. mtNone seems to be dealt with in > some code, I'm not sure if it's appropriate to use it as an invalid value. > Regardless, mtInvalid is a better name (for this purpose), so maybe we can > change mtNone to mtInvalid in the future? A much simpler (in the sense of avoiding the use of advanced template features) alternative to the one I posted earlier. (Thanks to @stefank for the suggestion.) https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:dynamic-memflags-specialize I dislike the current proposed approach of adding an optional MEMFLAGS argument to all the CHeapObj allocation functions. - PR: https://git.openjdk.org/jdk/pull/10412
Re: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3]
On Wed, 28 Sep 2022 13:45:53 GMT, Johan Sjölen wrote:
>> Here's a suggested solution for the ticket mentioned and a use case for
>> outputStream. I'm not attached to the name.
>>
>> This saves space for all allocated outputStreams, which is nice. It also
>> makes the purpose of ResourceObj more clear ("please handle the life cycle
>> for me"), reducing the need for it.
>>
>> Thank you for considering it.
>
> Johan Sjölen has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains six commits:
>
> - Introduce new, invalid, memory flag
> - delete _print_inlining_stream
> - Merge remote-tracking branch 'origin/master' into dyn-cheapobj
> - Avoid leaking predString
> - Try out Coleen's suggestion
> - DynCHeapObj
I still have to go through all of this and check for memory leaks, just FYI.
-
PR: https://git.openjdk.org/jdk/pull/10412
Re: RFR: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts [v3]
On Wed, 28 Sep 2022 05:45:14 GMT, Ioi Lam wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains one commit:
>>
>> 8293540: [Metrics] Potentially incorrectly detected resource limits with
>> additional cgroup fs mounts
>
> The JDK change looks good to me. Some nits for the test cases.
Thanks for the review @iklam!
> test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 26:
>
>> 24: /*
>> 25: * @test
>> 26: * @summary Verify that -XshowSettings:system works
>
> Add `@bug 8293540`
Thanks, added.
> test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 64:
>
>> 62: opts.addDockerOpts("--memory", "300m");
>> 63: if (addCgroupMounts) {
>> 64: opts.addDockerOpts("--volume",
>> "/sys/fs/cgroup:/cgroup-in:ro");
>
> Add comments that the extra mount should be ignored by the cgroup set-up
> code. (Same for other test cases).
OK. Added in the updated version.
-
PR: https://git.openjdk.org/jdk/pull/10248
Re: RFR: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts [v4]
> Similar issue to the hotspot change discussed in > https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation > may get the resource limits wrong if there are additional cgroup fs mounts. > Apparently that's more common than one might think. I've reproduced this with > these existing tests on cg v2: > > > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java > test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java > > > I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` > and amended > `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which > unconditionally fails (irrespective of cgroup version in use). The fix is > fairly straight forward and is an extension which we already do for the > `cpuset` controller: Allow duplicates, and if there are any prefer those > mounted at `/sys/fs/cgroup`. > > Testing: > - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the > product fix) > - [x] added tests fail before, pass after the product fix. > - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still > pass. > - [x] GHA all pass. > > Please review! Many thanks in advance. Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Add comments/@bug in tests - Changes: - all: https://git.openjdk.org/jdk/pull/10248/files - new: https://git.openjdk.org/jdk/pull/10248/files/8059dd81..6061a475 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=02-03 Stats: 6 lines in 4 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10248.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248 PR: https://git.openjdk.org/jdk/pull/10248
Re: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3]
On Wed, 28 Sep 2022 18:21:09 GMT, Coleen Phillimore wrote: >> Johan Sjölen has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains six commits: >> >> - Introduce new, invalid, memory flag >> - delete _print_inlining_stream >> - Merge remote-tracking branch 'origin/master' into dyn-cheapobj >> - Avoid leaking predString >> - Try out Coleen's suggestion >> - DynCHeapObj > > src/hotspot/share/opto/compile.hpp line 1064: > >> 1062: delete _print_inlining_stream; >> 1063: }; >> 1064: > > compile.cpp has print_inlining_stream_free() calls which will leak the > stringStream now if called. I think this function needs to be removed and it > should call the reset function to reinitialize the stream. > There should be compiler tests that will fail if print_inlining_stream_free() > is called with a null _print_inlining_stream pointer (I think the delete > should fail (?) with null) This is removed as part of https://github.com/openjdk/jdk/pull/10396 . The function used to be here but I merged with upstream when that went in. delete on null is OK, just like with free. - PR: https://git.openjdk.org/jdk/pull/10412
Re: RFR: 8288907: serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java fails with -XX:TieredStopAtLevel=2,3
On Thu, 29 Sep 2022 07:21:46 GMT, Serguei Spitsyn wrote:
> The test SuspendResume fails on linux-aarch64 with timeouts.
> However, it never fails when test timeout is set to a bigger value:
>
> diff --git
> a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
>
> b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
> index cd5b8251fce..562f2eae921 100644
> ---
> a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
> +++
> b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
> @@ -29,7 +29,7 @@
> * @library /test/lib
> * @compile --enable-preview -source ${jdk.version} SuspendResume1.java
> * @run driver jdk.test.lib.FileInstaller . .
> - * @run main/othervm/native
> + * @run main/othervm/native/timeout=600
> * --enable-preview
> * -Djava.util.concurrent.ForkJoinPool.common.parallelism=1
> * -agentlib:SuspendResume1
>
>
> I'd like to push this as a trivial fix.
>
> Testing: Submitted mach5 test runs on multiple platforms.
Seems fine and trivial to me.
Thanks.
-
Marked as reviewed by dholmes (Reviewer).
PR: https://git.openjdk.org/jdk/pull/10480
RFR: 8288907: serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java fails with -XX:TieredStopAtLevel=2,3
The test SuspendResume fails on linux-aarch64 with timeouts.
However, it never fails when test timeout is set to a bigger value:
diff --git
a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
index cd5b8251fce..562f2eae921 100644
---
a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
+++
b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
@@ -29,7 +29,7 @@
* @library /test/lib
* @compile --enable-preview -source ${jdk.version} SuspendResume1.java
* @run driver jdk.test.lib.FileInstaller . .
- * @run main/othervm/native
+ * @run main/othervm/native/timeout=600
* --enable-preview
* -Djava.util.concurrent.ForkJoinPool.common.parallelism=1
* -agentlib:SuspendResume1
I'd like to push this as a trivial fix.
Testing: Submitted mach5 test runs on multiple platforms.
-
Commit messages:
- 8288907: serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
fails with -XX:TieredStopAtLevel=2,3
Changes: https://git.openjdk.org/jdk/pull/10480/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10480&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8288907
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/10480.diff
Fetch: git fetch https://git.openjdk.org/jdk pull/10480/head:pull/10480
PR: https://git.openjdk.org/jdk/pull/10480
