From stefank at openjdk.java.net Fri Oct 1 07:17:25 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 1 Oct 2021 07:17:25 GMT Subject: RFR: JDK-8274435: EXCEPTION_ACCESS_VIOLATION in BFSClosure::closure_impl [v2] In-Reply-To: References: <-Ldaoep1vhfQK4H2S1mW6gUt2EJP34-HqhBdyS9N228=.f9ca5726-16a9-41e2-a8b9-1474867a2529@github.com> Message-ID: On Thu, 30 Sep 2021 21:54:05 GMT, Ekaterina Vergizova wrote: >> Hi, >> please review this small change that prevents EXCEPTION_ACCESS_VIOLATION on some Windows machines. >> The crash is intermittently reproducible on win32 client jvm when running e.g. jdk/jfr/jcmd/TestJcmdDumpPathToGCRoots.java test. >> It is caused by BitSet::get_fragment_bits method which returns null for the newly initialized BitSet if granule (= addr >> _bitmap_granularity_shift) is equal to 0. >> >> Testing: >> jdk/jfr/* with win32 and win64 builds, no crashes or regression after the fix. > > Ekaterina Vergizova has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8274435: EXCEPTION_ACCESS_VIOLATION in BFSClosure::closure_impl Looks good! ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5736 From evergizova at openjdk.java.net Fri Oct 1 12:56:31 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 1 Oct 2021 12:56:31 GMT Subject: Integrated: JDK-8274435: EXCEPTION_ACCESS_VIOLATION in BFSClosure::closure_impl In-Reply-To: <-Ldaoep1vhfQK4H2S1mW6gUt2EJP34-HqhBdyS9N228=.f9ca5726-16a9-41e2-a8b9-1474867a2529@github.com> References: <-Ldaoep1vhfQK4H2S1mW6gUt2EJP34-HqhBdyS9N228=.f9ca5726-16a9-41e2-a8b9-1474867a2529@github.com> Message-ID: On Tue, 28 Sep 2021 11:08:48 GMT, Ekaterina Vergizova wrote: > Hi, > please review this small change that prevents EXCEPTION_ACCESS_VIOLATION on some Windows machines. > The crash is intermittently reproducible on win32 client jvm when running e.g. jdk/jfr/jcmd/TestJcmdDumpPathToGCRoots.java test. > It is caused by BitSet::get_fragment_bits method which returns null for the newly initialized BitSet if granule (= addr >> _bitmap_granularity_shift) is equal to 0. > > Testing: > jdk/jfr/* with win32 and win64 builds, no crashes or regression after the fix. This pull request has now been integrated. Changeset: c05dc268 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk/commit/c05dc268acaf87236f30cf700ea3ac778e3b20e5 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8274435: EXCEPTION_ACCESS_VIOLATION in BFSClosure::closure_impl Reviewed-by: stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/5736 From stefank at openjdk.java.net Fri Oct 1 14:06:39 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 1 Oct 2021 14:06:39 GMT Subject: RFR: JDK-8274435: EXCEPTION_ACCESS_VIOLATION in BFSClosure::closure_impl [v2] In-Reply-To: References: <-Ldaoep1vhfQK4H2S1mW6gUt2EJP34-HqhBdyS9N228=.f9ca5726-16a9-41e2-a8b9-1474867a2529@github.com> Message-ID: On Thu, 30 Sep 2021 21:54:05 GMT, Ekaterina Vergizova wrote: >> Hi, >> please review this small change that prevents EXCEPTION_ACCESS_VIOLATION on some Windows machines. >> The crash is intermittently reproducible on win32 client jvm when running e.g. jdk/jfr/jcmd/TestJcmdDumpPathToGCRoots.java test. >> It is caused by BitSet::get_fragment_bits method which returns null for the newly initialized BitSet if granule (= addr >> _bitmap_granularity_shift) is equal to 0. >> >> Testing: >> jdk/jfr/* with win32 and win64 builds, no crashes or regression after the fix. > > Ekaterina Vergizova has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8274435: EXCEPTION_ACCESS_VIOLATION in BFSClosure::closure_impl @kvergizova @yan-too FYI: We typically require two reviews for most HotSpot changes. I've asked @fisk to make a post-review of this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/5736 From eosterlund at openjdk.java.net Fri Oct 1 14:06:39 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 1 Oct 2021 14:06:39 GMT Subject: RFR: JDK-8274435: EXCEPTION_ACCESS_VIOLATION in BFSClosure::closure_impl [v2] In-Reply-To: References: <-Ldaoep1vhfQK4H2S1mW6gUt2EJP34-HqhBdyS9N228=.f9ca5726-16a9-41e2-a8b9-1474867a2529@github.com> Message-ID: <9Xs8UiMcfYgaqxJee9i7fVIerwW6HishYpkaQfeKs8A=.767db809-3257-4646-9511-f8e413e5daf5@github.com> On Thu, 30 Sep 2021 21:54:05 GMT, Ekaterina Vergizova wrote: >> Hi, >> please review this small change that prevents EXCEPTION_ACCESS_VIOLATION on some Windows machines. >> The crash is intermittently reproducible on win32 client jvm when running e.g. jdk/jfr/jcmd/TestJcmdDumpPathToGCRoots.java test. >> It is caused by BitSet::get_fragment_bits method which returns null for the newly initialized BitSet if granule (= addr >> _bitmap_granularity_shift) is equal to 0. >> >> Testing: >> jdk/jfr/* with win32 and win64 builds, no crashes or regression after the fix. > > Ekaterina Vergizova has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8274435: EXCEPTION_ACCESS_VIOLATION in BFSClosure::closure_impl Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/5736 From yan at openjdk.java.net Fri Oct 1 14:42:45 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 1 Oct 2021 14:42:45 GMT Subject: RFR: JDK-8274435: EXCEPTION_ACCESS_VIOLATION in BFSClosure::closure_impl [v2] In-Reply-To: References: <-Ldaoep1vhfQK4H2S1mW6gUt2EJP34-HqhBdyS9N228=.f9ca5726-16a9-41e2-a8b9-1474867a2529@github.com> Message-ID: On Fri, 1 Oct 2021 13:59:39 GMT, Stefan Karlsson wrote: >> Ekaterina Vergizova has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8274435: EXCEPTION_ACCESS_VIOLATION in BFSClosure::closure_impl > > @kvergizova @yan-too FYI: We typically require two reviews for most HotSpot changes. I've asked @fisk to make a post-review of this change. @stefank Oops! Next time we will be more cautious. I'm afraid Skara cannot help here without costly extra JBS requests. ------------- PR: https://git.openjdk.java.net/jdk/pull/5736 From egahlin at openjdk.java.net Mon Oct 4 11:14:18 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 4 Oct 2021 11:14:18 GMT Subject: RFR: 8274559: JFR: Typo in 'jfr help configure' text Message-ID: Hi, Could I have review of a typo. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/5803/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5803&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274559 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5803/head:pull/5803 PR: https://git.openjdk.java.net/jdk/pull/5803 From shade at openjdk.java.net Mon Oct 4 12:39:11 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 4 Oct 2021 12:39:11 GMT Subject: RFR: 8274563: jfr/event/oldobject/TestClassLoaderLeak.java fails when GC cycles are not happening In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 16:24:55 GMT, Erik Gahlin wrote: >> This reliably fails with Serial (ignored by @requires), Shenandoah and Z: >> >> >> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=jdk/jfr/event/oldobject/TestClassLoaderLeak.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> >> ... >> >> STDERR: >> java.lang.RuntimeException: Could not find class leak >> at jdk.test.lib.Asserts.fail(Asserts.java:594) >> at jdk.jfr.event.oldobject.TestClassLoaderLeak.main(TestClassLoaderLeak.java:80) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:568) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:833) >> >> >> I believe this test implicitly wants at least one GC cycle to happen so that `ObjectSampler::oop_storage_gc_notification` turns the sampled objects "old". An easy way to do this is to trim the Java heap size. If that does not work, we would need to go to MXBeans and watch GC cycles happening. >> >> Additional testing: >> - [x] Affected test with `-XX:+UseShenandoahGC`, 10 times >> - [x] Affected test with `-XX:+UseZGC`, 10 times >> - [x] Affected test with `-XX:+UseSerialGC`, 10 times >> - [x] Affected test with `-XX:+UseParallelGC`, 10 times >> - [x] Affected test with `-XX:+UseG1GC`, 10 times > > Marked as reviewed by egahlin (Reviewer). Thanks @egahlin! ------------- PR: https://git.openjdk.java.net/jdk/pull/5775 From shade at openjdk.java.net Mon Oct 4 12:39:12 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 4 Oct 2021 12:39:12 GMT Subject: Integrated: 8274563: jfr/event/oldobject/TestClassLoaderLeak.java fails when GC cycles are not happening In-Reply-To: References: Message-ID: <2F_kSHu6nX4aKyP5i9U8ZeVU83XWwOIBoDGBUdd0KQY=.53188864-cb05-408b-91e0-7c6e5ab3d964@github.com> On Thu, 30 Sep 2021 11:35:52 GMT, Aleksey Shipilev wrote: > This reliably fails with Serial (ignored by @requires), Shenandoah and Z: > > > $ CONF=linux-x86_64-server-fastdebug make run-test TEST=jdk/jfr/event/oldobject/TestClassLoaderLeak.java TEST_VM_OPTS="-XX:+UseShenandoahGC" > > ... > > STDERR: > java.lang.RuntimeException: Could not find class leak > at jdk.test.lib.Asserts.fail(Asserts.java:594) > at jdk.jfr.event.oldobject.TestClassLoaderLeak.main(TestClassLoaderLeak.java:80) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:833) > > > I believe this test implicitly wants at least one GC cycle to happen so that `ObjectSampler::oop_storage_gc_notification` turns the sampled objects "old". An easy way to do this is to trim the Java heap size. If that does not work, we would need to go to MXBeans and watch GC cycles happening. > > Additional testing: > - [x] Affected test with `-XX:+UseShenandoahGC`, 10 times > - [x] Affected test with `-XX:+UseZGC`, 10 times > - [x] Affected test with `-XX:+UseSerialGC`, 10 times > - [x] Affected test with `-XX:+UseParallelGC`, 10 times > - [x] Affected test with `-XX:+UseG1GC`, 10 times This pull request has now been integrated. Changeset: 47bfc8aa Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/47bfc8aa9367ff852ea5d901f1fa3c6ef316913e Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8274563: jfr/event/oldobject/TestClassLoaderLeak.java fails when GC cycles are not happening Reviewed-by: egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/5775 From iris at openjdk.java.net Mon Oct 4 17:10:08 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 4 Oct 2021 17:10:08 GMT Subject: RFR: 8274559: JFR: Typo in 'jfr help configure' text In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 11:02:51 GMT, Erik Gahlin wrote: > Hi, > > Could I have review of a typo. > > Testing: jdk/jdk/jfr > > Thanks > Erik Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5803 From mikael at openjdk.java.net Mon Oct 4 18:43:07 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Mon, 4 Oct 2021 18:43:07 GMT Subject: RFR: 8274559: JFR: Typo in 'jfr help configure' text In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 11:02:51 GMT, Erik Gahlin wrote: > Hi, > > Could I have review of a typo. > > Testing: jdk/jdk/jfr > > Thanks > Erik Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5803 From egahlin at openjdk.java.net Mon Oct 4 21:22:13 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 4 Oct 2021 21:22:13 GMT Subject: Integrated: 8274559: JFR: Typo in 'jfr help configure' text In-Reply-To: References: Message-ID: <6UVXlUVvgfgqhEuGS-bvZ57m2NeuKTiKWFoBUB96aLI=.9e2a67c6-dc5c-44bc-b93f-47712e387029@github.com> On Mon, 4 Oct 2021 11:02:51 GMT, Erik Gahlin wrote: > Hi, > > Could I have review of a typo. > > Testing: jdk/jdk/jfr > > Thanks > Erik This pull request has now been integrated. Changeset: 7e757f6a Author: Erik Gahlin URL: https://git.openjdk.java.net/jdk/commit/7e757f6a2cbfd03ba9ac602b800d15ba33f6f5f4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8274559: JFR: Typo in 'jfr help configure' text Reviewed-by: iris, mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/5803 From aoqi at openjdk.java.net Fri Oct 8 09:06:26 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Fri, 8 Oct 2021 09:06:26 GMT Subject: RFR: 8274952: jdk/jfr/api/consumer/TestRecordedFrameType.java failed when c1 disabled Message-ID: jdk/jfr/api/consumer/TestRecordedFrameType.java requires c1: 73 if (!WB.enqueueMethodForCompilation(mtd, 1)) { 74 throw new Exception("Could not enqueue method for CompLevel_simple"); 75 } When c1 is disabled, the test failed: STDOUT: 2 compiler directives added WB error: no compiler for requested compilation level 1 STDERR: java.lang.Exception: Could not enqueue method for CompLevel_simple at jdk.jfr.api.consumer.TestRecordedFrameType.main(TestRecordedFrameType.java:74) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51) at java.base/java.lang.reflect.Method.invoke(Method.java:569) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:833) JavaTest Message: Test threw exception: java.lang.Exception: Could not enqueue method for CompLevel_simple JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.Exception: Could not enqueue method for CompLevel_simple ------------- Commit messages: - 8274952: jdk/jfr/api/consumer/TestRecordedFrameType.java failed when c1 disabled Changes: https://git.openjdk.java.net/jdk/pull/5862/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5862&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274952 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5862.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5862/head:pull/5862 PR: https://git.openjdk.java.net/jdk/pull/5862 From egahlin at openjdk.java.net Fri Oct 8 14:47:37 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 8 Oct 2021 14:47:37 GMT Subject: RFR: 8274319: Replace usages of Collections.sort with List.sort call in jdk.jfr In-Reply-To: <7OOxsZXj4QSYc1PqjYz2VdGKmLpNEp8mbt0SVlmb-II=.c7d9d977-9f9f-4450-a992-6678880b3c28@github.com> References: <7OOxsZXj4QSYc1PqjYz2VdGKmLpNEp8mbt0SVlmb-II=.c7d9d977-9f9f-4450-a992-6678880b3c28@github.com> Message-ID: <5W7APRLN8c1RayuO4edQldp68UDhmXB5Ez3GiHz_asU=.bb77a272-e2a8-4fee-85e3-9e31498b2459@github.com> On Sat, 25 Sep 2021 11:08:16 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. > > Also Comparator's implementation can be cleaned up with help of static methods in `Comparator` class. > E.g `(u, v) -> Long.compare(v.count, u.count)` can be replaced with `Comparator.comparingLong(v -> v.count)` Changes requested by egahlin (Reviewer). src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java line 172: > 170: protected final List getRecordings() { > 171: List list = new ArrayList<>(getFlightRecorder().getRecordings()); > 172: list.sort(Comparator.comparing(Recording::getId)); Use Comparator.comparingLong instead? src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Summary.java line 146: > 144: println(" Duration: " + (totalDuration + 500_000_000) / 1_000_000_000 + " s"); > 145: List statsList = new ArrayList<>(stats.values()); > 146: statsList.sort(Comparator.comparingLong(v -> v.count)); This looks incorrect. the order is reversed compared to before. Events with a high count should appear on top. ------------- PR: https://git.openjdk.java.net/jdk/pull/5696 From egahlin at openjdk.java.net Fri Oct 8 15:07:12 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 8 Oct 2021 15:07:12 GMT Subject: RFR: 8274952: jdk/jfr/api/consumer/TestRecordedFrameType.java failed when c1 disabled In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 08:57:24 GMT, Ao Qi wrote: > jdk/jfr/api/consumer/TestRecordedFrameType.java requires c1: > > > 73 if (!WB.enqueueMethodForCompilation(mtd, 1)) { > 74 throw new Exception("Could not enqueue method for CompLevel_simple"); > 75 } > > > When c1 is disabled, the test failed: > > > STDOUT: > 2 compiler directives added > WB error: no compiler for requested compilation level 1 > STDERR: > java.lang.Exception: Could not enqueue method for CompLevel_simple > at jdk.jfr.api.consumer.TestRecordedFrameType.main(TestRecordedFrameType.java:74) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51) > at java.base/java.lang.reflect.Method.invoke(Method.java:569) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:833) > > JavaTest Message: Test threw exception: java.lang.Exception: Could not enqueue method for CompLevel_simple > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.Exception: Could not enqueue method for CompLevel_simple Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5862 From rkennke at redhat.com Fri Oct 8 15:43:50 2021 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 8 Oct 2021 17:43:50 +0200 Subject: RFC: (How to?) Replace use of mark-word in leak-profiler (Lilliput) Message-ID: Hi there, I'm currently thinking about an issue that came up when I tested JFR/Leakprofiler with Lilliput. First come context: In Lilliput I am storing a (compressed) Klass* in the object header, and want to phase out all uses of the dedicated Klass*-word and then remove that. This means that we need to be a little more careful when accessing the object header and/or the object's klass. In the leak-profiler, we (temporarily) store an Edge* into the object header, and preserve the actual mark in a table. However, that means that the heap traversal would not work anymore because the object doesn't have a valid Klass* anymore. Therefore I'm thinking about alternative ways to associate objects with an Edge*: 1. Use a (hash-)table for it (oop->Edge*), in EdgeStore. 2. Compress the Edge* to 32bits and store that only in the lower 32bits of the header (the Klass* is in the upper 32bits, currently). Not quite sure how to do this, though, it means we have to control allocation of the Edge instances in a contiguous space. 3. Store the object Klass* somewhere as long as we have it (before overriding it in EdgeStore::associate_leak_content_with_candidate()), and use that for iterating the object (in BFSClosure::iterate()). But where? Maybe in the Edge to the object? I.o.w. each Edge would also store the Klass* of its pointee? I wanted to check with you if any of those approaches make sense to you, or maybe you have even better ideas? Thanks for helping, Roman From github.com+741251+turbanoff at openjdk.java.net Fri Oct 8 20:14:32 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 8 Oct 2021 20:14:32 GMT Subject: RFR: 8274319: Replace usages of Collections.sort with List.sort call in jdk.jfr [v2] In-Reply-To: <7OOxsZXj4QSYc1PqjYz2VdGKmLpNEp8mbt0SVlmb-II=.c7d9d977-9f9f-4450-a992-6678880b3c28@github.com> References: <7OOxsZXj4QSYc1PqjYz2VdGKmLpNEp8mbt0SVlmb-II=.c7d9d977-9f9f-4450-a992-6678880b3c28@github.com> Message-ID: > Collections.sort is just a wrapper, so it is better to use an instance method directly. > > Also Comparator's implementation can be cleaned up with help of static methods in `Comparator` class. > E.g. > > Collections.sort(sorted, new Comparator() { > @Override > public int compare(EventType e1, EventType e2) { > return e1.getName().compareTo(e2.getName()); > } > }); > > can be replaced with > > sorted.sort(Comparator.comparing(EventType::getName)); Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8274319: Replace usages of Collections.sort with List.sort call in jdk.jfr fix post-review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5696/files - new: https://git.openjdk.java.net/jdk/pull/5696/files/1f2de662..0003b0e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5696&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5696&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5696.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5696/head:pull/5696 PR: https://git.openjdk.java.net/jdk/pull/5696 From github.com+741251+turbanoff at openjdk.java.net Fri Oct 8 20:14:34 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 8 Oct 2021 20:14:34 GMT Subject: RFR: 8274319: Replace usages of Collections.sort with List.sort call in jdk.jfr [v2] In-Reply-To: <5W7APRLN8c1RayuO4edQldp68UDhmXB5Ez3GiHz_asU=.bb77a272-e2a8-4fee-85e3-9e31498b2459@github.com> References: <7OOxsZXj4QSYc1PqjYz2VdGKmLpNEp8mbt0SVlmb-II=.c7d9d977-9f9f-4450-a992-6678880b3c28@github.com> <5W7APRLN8c1RayuO4edQldp68UDhmXB5Ez3GiHz_asU=.bb77a272-e2a8-4fee-85e3-9e31498b2459@github.com> Message-ID: On Fri, 8 Oct 2021 14:43:20 GMT, Erik Gahlin wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274319: Replace usages of Collections.sort with List.sort call in jdk.jfr >> fix post-review comments > > src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java line 172: > >> 170: protected final List getRecordings() { >> 171: List list = new ArrayList<>(getFlightRecorder().getRecordings()); >> 172: list.sort(Comparator.comparing(Recording::getId)); > > Use Comparator.comparingLong instead? Changed > src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Summary.java line 146: > >> 144: println(" Duration: " + (totalDuration + 500_000_000) / 1_000_000_000 + " s"); >> 145: List statsList = new ArrayList<>(stats.values()); >> 146: statsList.sort(Comparator.comparingLong(v -> v.count)); > > This looks incorrect. the order is reversed compared to before. > > Events with a high count should appear on top. Oops. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5696 From egahlin at openjdk.java.net Fri Oct 8 20:42:07 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 8 Oct 2021 20:42:07 GMT Subject: RFR: 8274319: Replace usages of Collections.sort with List.sort call in jdk.jfr [v2] In-Reply-To: References: <7OOxsZXj4QSYc1PqjYz2VdGKmLpNEp8mbt0SVlmb-II=.c7d9d977-9f9f-4450-a992-6678880b3c28@github.com> Message-ID: On Fri, 8 Oct 2021 20:14:32 GMT, Andrey Turbanov wrote: >> Collections.sort is just a wrapper, so it is better to use an instance method directly. >> >> Also Comparator's implementation can be cleaned up with help of static methods in `Comparator` class. >> E.g. >> >> Collections.sort(sorted, new Comparator() { >> @Override >> public int compare(EventType e1, EventType e2) { >> return e1.getName().compareTo(e2.getName()); >> } >> }); >> >> can be replaced with >> >> sorted.sort(Comparator.comparing(EventType::getName)); > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8274319: Replace usages of Collections.sort with List.sort call in jdk.jfr > fix post-review comments Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5696 From ysuenaga at openjdk.java.net Mon Oct 11 00:12:21 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 11 Oct 2021 00:12:21 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v5] In-Reply-To: References: Message-ID: <67RAzkHDzTjkp9z3OI2oBsi6BpQuTJzp8vtNIhMFe-I=.a4c109db-d399-4204-9182-a7f96072fafe@github.com> On Wed, 15 Sep 2021 00:56:37 GMT, Yasumasa Suenaga wrote: >> We set `dumppath` in `-XX:FlightRecorderOptions` or `JFR.configure dumppath` jcmd when we want to set emergency dump path. However they do not afffect. >> >> ### -XX:FlightRecorderOptions >> >> >> $ java -XX:FlightRecorderOptions=dumppath=`pwd` -XX:StartFlightRecording -Xlog:exceptions=info --version >> [0.032s][info][exceptions] Exception (0x00000007470163b8) >> thrown [open/src/hotspot/share/services/diagnosticFramework.cpp, line 215] >> for thread 0x00007f4f700236a0 >> [0.033s][error][arguments ] Unknown argument 'dumppath' in diagnostic command. >> Error occurred during initialization of VM >> Failure when starting JFR on_create_vm_2 >> >> >> ### jcmd >> >> `jcmd` shows the configuration change was succeeded, but it would not affect. >> >> >> $ jcmd 1046 JFR.configure dumppath=/tmp >> 1046: >> Dump path: /tmp > > Yasumasa Suenaga 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 eight additional commits since the last revision: > > - Print warning message instead of throwing exception if JFR will not write emergency dump > - Merge remote-tracking branch 'upstream/master' into JDK-8271949 > - Set absolute path to JFR emergency dump path > - Check write permission on JFR emergency dump path in configuration > - Update testcase > - Merge remote-tracking branch 'upstream/master' into JDK-8271949 > - Remove USER_HOME > - 8271949: dumppath in -XX:FlightRecorderOptions does not affect Ping! ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From aoqi at openjdk.java.net Mon Oct 11 02:00:08 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Mon, 11 Oct 2021 02:00:08 GMT Subject: RFR: 8274952: jdk/jfr/api/consumer/TestRecordedFrameType.java failed when c1 disabled In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 15:04:05 GMT, Erik Gahlin wrote: >> jdk/jfr/api/consumer/TestRecordedFrameType.java requires c1: >> >> >> 73 if (!WB.enqueueMethodForCompilation(mtd, 1)) { >> 74 throw new Exception("Could not enqueue method for CompLevel_simple"); >> 75 } >> >> >> When c1 is disabled, the test failed: >> >> >> STDOUT: >> 2 compiler directives added >> WB error: no compiler for requested compilation level 1 >> STDERR: >> java.lang.Exception: Could not enqueue method for CompLevel_simple >> at jdk.jfr.api.consumer.TestRecordedFrameType.main(TestRecordedFrameType.java:74) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51) >> at java.base/java.lang.reflect.Method.invoke(Method.java:569) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:833) >> >> JavaTest Message: Test threw exception: java.lang.Exception: Could not enqueue method for CompLevel_simple >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.lang.Exception: Could not enqueue method for CompLevel_simple > > Marked as reviewed by egahlin (Reviewer). Thanks, @egahlin ! Is a second reviewer needed? I think this is a trivial patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/5862 From jiefu at openjdk.java.net Mon Oct 11 02:09:07 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 11 Oct 2021 02:09:07 GMT Subject: RFR: 8274952: jdk/jfr/api/consumer/TestRecordedFrameType.java failed when c1 disabled In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 08:57:24 GMT, Ao Qi wrote: > jdk/jfr/api/consumer/TestRecordedFrameType.java requires c1: > > > 73 if (!WB.enqueueMethodForCompilation(mtd, 1)) { > 74 throw new Exception("Could not enqueue method for CompLevel_simple"); > 75 } > > > When c1 is disabled, the test failed: > > > STDOUT: > 2 compiler directives added > WB error: no compiler for requested compilation level 1 > STDERR: > java.lang.Exception: Could not enqueue method for CompLevel_simple > at jdk.jfr.api.consumer.TestRecordedFrameType.main(TestRecordedFrameType.java:74) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51) > at java.base/java.lang.reflect.Method.invoke(Method.java:569) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:833) > > JavaTest Message: Test threw exception: java.lang.Exception: Could not enqueue method for CompLevel_simple > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.Exception: Could not enqueue method for CompLevel_simple Marked as reviewed by jiefu (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5862 From aoqi at openjdk.java.net Mon Oct 11 02:18:09 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Mon, 11 Oct 2021 02:18:09 GMT Subject: RFR: 8274952: jdk/jfr/api/consumer/TestRecordedFrameType.java failed when c1 disabled In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 02:05:59 GMT, Jie Fu wrote: >> jdk/jfr/api/consumer/TestRecordedFrameType.java requires c1: >> >> >> 73 if (!WB.enqueueMethodForCompilation(mtd, 1)) { >> 74 throw new Exception("Could not enqueue method for CompLevel_simple"); >> 75 } >> >> >> When c1 is disabled, the test failed: >> >> >> STDOUT: >> 2 compiler directives added >> WB error: no compiler for requested compilation level 1 >> STDERR: >> java.lang.Exception: Could not enqueue method for CompLevel_simple >> at jdk.jfr.api.consumer.TestRecordedFrameType.main(TestRecordedFrameType.java:74) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51) >> at java.base/java.lang.reflect.Method.invoke(Method.java:569) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:833) >> >> JavaTest Message: Test threw exception: java.lang.Exception: Could not enqueue method for CompLevel_simple >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.lang.Exception: Could not enqueue method for CompLevel_simple > > Marked as reviewed by jiefu (Reviewer). Thanks, @DamonFool ! ------------- PR: https://git.openjdk.java.net/jdk/pull/5862 From aoqi at openjdk.java.net Mon Oct 11 02:21:09 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Mon, 11 Oct 2021 02:21:09 GMT Subject: Integrated: 8274952: jdk/jfr/api/consumer/TestRecordedFrameType.java failed when c1 disabled In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 08:57:24 GMT, Ao Qi wrote: > jdk/jfr/api/consumer/TestRecordedFrameType.java requires c1: > > > 73 if (!WB.enqueueMethodForCompilation(mtd, 1)) { > 74 throw new Exception("Could not enqueue method for CompLevel_simple"); > 75 } > > > When c1 is disabled, the test failed: > > > STDOUT: > 2 compiler directives added > WB error: no compiler for requested compilation level 1 > STDERR: > java.lang.Exception: Could not enqueue method for CompLevel_simple > at jdk.jfr.api.consumer.TestRecordedFrameType.main(TestRecordedFrameType.java:74) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51) > at java.base/java.lang.reflect.Method.invoke(Method.java:569) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:833) > > JavaTest Message: Test threw exception: java.lang.Exception: Could not enqueue method for CompLevel_simple > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.Exception: Could not enqueue method for CompLevel_simple This pull request has now been integrated. Changeset: a05873a2 Author: Ao Qi Committer: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/a05873a225c40d12e60870794b9c993d1ea89cfe Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8274952: jdk/jfr/api/consumer/TestRecordedFrameType.java failed when c1 disabled Reviewed-by: egahlin, jiefu ------------- PR: https://git.openjdk.java.net/jdk/pull/5862 From shade at openjdk.java.net Mon Oct 11 11:10:08 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 11:10:08 GMT Subject: RFR: 8274560: JFR: Add test for OldObjectSample event when using Shenandoah In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 10:57:13 GMT, Aleksey Shipilev wrote: > Similar to JDK-8248302, we would like to have a test for Shenandoah. Current `jdk/jfr/event/oldobject/TestObjectDescription.java` fails with Shenandoah and should be excluded. > > Additional testing: > - [x] `jdk/jfr/event/oldobject/TestObjectDescription.java`, default: still passes > - [x] `jdk/jfr/event/oldobject/TestObjectDescription.java`, `-XX:+UseShenandoahGC`: now skipped > - [x] `jdk/jfr/event/oldobject/TestObjectDescription.java`, `-XX:+UseZGC`: still skipped > - [x] `jdk/jfr/event/oldobject/TestShenandoah.java`, out of box: passes > - [x] `jdk/jfr/event/oldobject/TestShenandoah.java`, `-XX:+UseShenandoahGC`: passes > - [x] `jdk/jfr/event/oldobject/TestShenandoah.java`, `-XX:+UseZGC`: skipped Any takers? :) ------------- PR: https://git.openjdk.java.net/jdk/pull/5773 From mgronlun at openjdk.java.net Mon Oct 11 18:29:38 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 11 Oct 2021 18:29:38 GMT Subject: RFR: 8274560: JFR: Add test for OldObjectSample event when using Shenandoah In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 10:57:13 GMT, Aleksey Shipilev wrote: > Similar to JDK-8248302, we would like to have a test for Shenandoah. Current `jdk/jfr/event/oldobject/TestObjectDescription.java` fails with Shenandoah and should be excluded. > > Additional testing: > - [x] `jdk/jfr/event/oldobject/TestObjectDescription.java`, default: still passes > - [x] `jdk/jfr/event/oldobject/TestObjectDescription.java`, `-XX:+UseShenandoahGC`: now skipped > - [x] `jdk/jfr/event/oldobject/TestObjectDescription.java`, `-XX:+UseZGC`: still skipped > - [x] `jdk/jfr/event/oldobject/TestShenandoah.java`, out of box: passes > - [x] `jdk/jfr/event/oldobject/TestShenandoah.java`, `-XX:+UseShenandoahGC`: passes > - [x] `jdk/jfr/event/oldobject/TestShenandoah.java`, `-XX:+UseZGC`: skipped Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5773 From rkennke at openjdk.java.net Mon Oct 11 19:08:07 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 11 Oct 2021 19:08:07 GMT Subject: RFR: 8275074: Cleanup unused code in JFR LeakProfiler Message-ID: While doing some fixes for Lilliput in JFR I noticed a couple of unused code paths. Let's remove them. Specifically, it's the entirety of saveRestore.hpp/cpp and a helper method in edgeUtils.hpp/cpp. Testing: - [x] tier1 - [x] jdk/jfr ------------- Commit messages: - 8275074: Cleanup unused code in JFR LeakProfiler Changes: https://git.openjdk.java.net/jdk/pull/5899/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5899&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275074 Stats: 245 lines in 4 files changed: 0 ins; 245 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5899.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5899/head:pull/5899 PR: https://git.openjdk.java.net/jdk/pull/5899 From mgronlun at openjdk.java.net Mon Oct 11 20:47:51 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 11 Oct 2021 20:47:51 GMT Subject: RFR: 8275074: Cleanup unused code in JFR LeakProfiler In-Reply-To: References: Message-ID: <8tjQVnPJhM3qHg9cRe7zeOlgo4Sa9wmQxflZ39MYN0Y=.5f25e03d-dfe2-4d88-bbda-a3a0f87d6725@github.com> On Mon, 11 Oct 2021 18:57:45 GMT, Roman Kennke wrote: > While doing some fixes for Lilliput in JFR I noticed a couple of unused code paths. Let's remove them. > Specifically, it's the entirety of saveRestore.hpp/cpp and a helper method in edgeUtils.hpp/cpp. > > Testing: > - [x] tier1 > - [x] jdk/jfr Looks good, thanks for noticing. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5899 From shade at openjdk.java.net Tue Oct 12 05:59:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Oct 2021 05:59:53 GMT Subject: RFR: 8274560: JFR: Add test for OldObjectSample event when using Shenandoah In-Reply-To: References: Message-ID: <4hyAwayng5cVFPTItSv8gsRFalMjskfAOZ_4FljRwgc=.0597e186-89b6-4e60-8d58-fb569e988afc@github.com> On Thu, 30 Sep 2021 10:57:13 GMT, Aleksey Shipilev wrote: > Similar to JDK-8248302, we would like to have a test for Shenandoah. Current `jdk/jfr/event/oldobject/TestObjectDescription.java` fails with Shenandoah and should be excluded. > > Additional testing: > - [x] `jdk/jfr/event/oldobject/TestObjectDescription.java`, default: still passes > - [x] `jdk/jfr/event/oldobject/TestObjectDescription.java`, `-XX:+UseShenandoahGC`: now skipped > - [x] `jdk/jfr/event/oldobject/TestObjectDescription.java`, `-XX:+UseZGC`: still skipped > - [x] `jdk/jfr/event/oldobject/TestShenandoah.java`, out of box: passes > - [x] `jdk/jfr/event/oldobject/TestShenandoah.java`, `-XX:+UseShenandoahGC`: passes > - [x] `jdk/jfr/event/oldobject/TestShenandoah.java`, `-XX:+UseZGC`: skipped Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/5773 From shade at openjdk.java.net Tue Oct 12 05:59:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Oct 2021 05:59:56 GMT Subject: Integrated: 8274560: JFR: Add test for OldObjectSample event when using Shenandoah In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 10:57:13 GMT, Aleksey Shipilev wrote: > Similar to JDK-8248302, we would like to have a test for Shenandoah. Current `jdk/jfr/event/oldobject/TestObjectDescription.java` fails with Shenandoah and should be excluded. > > Additional testing: > - [x] `jdk/jfr/event/oldobject/TestObjectDescription.java`, default: still passes > - [x] `jdk/jfr/event/oldobject/TestObjectDescription.java`, `-XX:+UseShenandoahGC`: now skipped > - [x] `jdk/jfr/event/oldobject/TestObjectDescription.java`, `-XX:+UseZGC`: still skipped > - [x] `jdk/jfr/event/oldobject/TestShenandoah.java`, out of box: passes > - [x] `jdk/jfr/event/oldobject/TestShenandoah.java`, `-XX:+UseShenandoahGC`: passes > - [x] `jdk/jfr/event/oldobject/TestShenandoah.java`, `-XX:+UseZGC`: skipped This pull request has now been integrated. Changeset: ef0922e8 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/ef0922e88528bdf4fe75537ddf4e82123e3f58b3 Stats: 80 lines in 2 files changed: 79 ins; 0 del; 1 mod 8274560: JFR: Add test for OldObjectSample event when using Shenandoah Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/5773 From duke at openjdk.java.net Tue Oct 12 07:52:00 2021 From: duke at openjdk.java.net (kabutz) Date: Tue, 12 Oct 2021 07:52:00 GMT Subject: RFR: JDK-8275091 : /src/jdk.management.jfr/share/classes/module-info.java has non-canonical order Message-ID: The canonical order of declarations inside the module-info.java file seems to follow the order: `module some.module.name { requires ... requires transitive ... exports ... exports ... to ... opens ... to ... uses ... provides ... with ... } ` The "requires" was changed to "requires transitive" as part of a larger change [8248564](https://github.com/openjdk/jdk/commit/738efea9c6306308fbb134003796b2bdd3f888dd), but not reordered. This is the only module-info.java file in the src/** directory that deviates from what appears to be the canonical order. ------------- Commit messages: - Merge branch 'openjdk:master' into maintain_canonical_order_in_module-info.java - Maintain the canonical order in module-info.java Changes: https://git.openjdk.java.net/jdk/pull/5738/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5738&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275091 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5738.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5738/head:pull/5738 PR: https://git.openjdk.java.net/jdk/pull/5738 From duke at openjdk.java.net Tue Oct 12 07:52:00 2021 From: duke at openjdk.java.net (kabutz) Date: Tue, 12 Oct 2021 07:52:00 GMT Subject: RFR: JDK-8275091 : /src/jdk.management.jfr/share/classes/module-info.java has non-canonical order In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 14:11:15 GMT, kabutz wrote: > The canonical order of declarations inside the module-info.java file seems to follow the order: > > `module some.module.name { > requires ... > > requires transitive ... > > exports ... > > exports ... to ... > > opens ... to ... > > uses ... > > provides ... with ... > } > ` > > The "requires" was changed to "requires transitive" as part of a larger change [8248564](https://github.com/openjdk/jdk/commit/738efea9c6306308fbb134003796b2bdd3f888dd), but not reordered. > > This is the only module-info.java file in the src/** directory that deviates from what appears to be the canonical order. Submitted a bug report, internal ID 9071602 ------------- PR: https://git.openjdk.java.net/jdk/pull/5738 From mgronlun at openjdk.java.net Tue Oct 12 11:23:48 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 12 Oct 2021 11:23:48 GMT Subject: RFR: JDK-8275091 : /src/jdk.management.jfr/share/classes/module-info.java has non-canonical order In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 14:11:15 GMT, kabutz wrote: > The canonical order of declarations inside the module-info.java file seems to follow the order: > > `module some.module.name { > requires ... > > requires transitive ... > > exports ... > > exports ... to ... > > opens ... to ... > > uses ... > > provides ... with ... > } > ` > > The "requires" was changed to "requires transitive" as part of a larger change [8248564](https://github.com/openjdk/jdk/commit/738efea9c6306308fbb134003796b2bdd3f888dd), but not reordered. > > This is the only module-info.java file in the src/** directory that deviates from what appears to be the canonical order. Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5738 From mgronlun at openjdk.java.net Tue Oct 12 11:36:03 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 12 Oct 2021 11:36:03 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v5] In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 00:56:37 GMT, Yasumasa Suenaga wrote: >> We set `dumppath` in `-XX:FlightRecorderOptions` or `JFR.configure dumppath` jcmd when we want to set emergency dump path. However they do not afffect. >> >> ### -XX:FlightRecorderOptions >> >> >> $ java -XX:FlightRecorderOptions=dumppath=`pwd` -XX:StartFlightRecording -Xlog:exceptions=info --version >> [0.032s][info][exceptions] Exception (0x00000007470163b8) >> thrown [open/src/hotspot/share/services/diagnosticFramework.cpp, line 215] >> for thread 0x00007f4f700236a0 >> [0.033s][error][arguments ] Unknown argument 'dumppath' in diagnostic command. >> Error occurred during initialization of VM >> Failure when starting JFR on_create_vm_2 >> >> >> ### jcmd >> >> `jcmd` shows the configuration change was succeeded, but it would not affect. >> >> >> $ jcmd 1046 JFR.configure dumppath=/tmp >> 1046: >> Dump path: /tmp > > Yasumasa Suenaga 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 eight additional commits since the last revision: > > - Print warning message instead of throwing exception if JFR will not write emergency dump > - Merge remote-tracking branch 'upstream/master' into JDK-8271949 > - Set absolute path to JFR emergency dump path > - Check write permission on JFR emergency dump path in configuration > - Update testcase > - Merge remote-tracking branch 'upstream/master' into JDK-8271949 > - Remove USER_HOME > - 8271949: dumppath in -XX:FlightRecorderOptions does not affect So how do you handle the case when it cannot be written to the specified location? What's the fallback strategy? I would recommend a fallback to the existing behaviour, that is to write it to $PWD as to not disrupt support organizations. ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From duke at openjdk.java.net Tue Oct 12 11:41:54 2021 From: duke at openjdk.java.net (kabutz) Date: Tue, 12 Oct 2021 11:41:54 GMT Subject: Integrated: JDK-8275091 : /src/jdk.management.jfr/share/classes/module-info.java has non-canonical order In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 14:11:15 GMT, kabutz wrote: > The canonical order of declarations inside the module-info.java file seems to follow the order: > > `module some.module.name { > requires ... > > requires transitive ... > > exports ... > > exports ... to ... > > opens ... to ... > > uses ... > > provides ... with ... > } > ` > > The "requires" was changed to "requires transitive" as part of a larger change [8248564](https://github.com/openjdk/jdk/commit/738efea9c6306308fbb134003796b2bdd3f888dd), but not reordered. > > This is the only module-info.java file in the src/** directory that deviates from what appears to be the canonical order. This pull request has now been integrated. Changeset: b460d6dd Author: kabutz Committer: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/b460d6ddafcd1be76bcf407254f843df6bbfb70b Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 8275091: /src/jdk.management.jfr/share/classes/module-info.java has non-canonical order Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/5738 From rkennke at openjdk.java.net Tue Oct 12 12:20:51 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 12 Oct 2021 12:20:51 GMT Subject: RFR: 8275074: Cleanup unused code in JFR LeakProfiler In-Reply-To: <8tjQVnPJhM3qHg9cRe7zeOlgo4Sa9wmQxflZ39MYN0Y=.5f25e03d-dfe2-4d88-bbda-a3a0f87d6725@github.com> References: <8tjQVnPJhM3qHg9cRe7zeOlgo4Sa9wmQxflZ39MYN0Y=.5f25e03d-dfe2-4d88-bbda-a3a0f87d6725@github.com> Message-ID: On Mon, 11 Oct 2021 20:44:32 GMT, Markus Gr?nlund wrote: > Looks good, thanks for noticing. Thanks! I am unsure whether or not JFR code / this particular change requires two reviews (as Hotspot in general) or if I can go ahead and integrate the PR. Please let me know! ------------- PR: https://git.openjdk.java.net/jdk/pull/5899 From mgronlun at openjdk.java.net Tue Oct 12 12:30:48 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 12 Oct 2021 12:30:48 GMT Subject: RFR: 8275074: Cleanup unused code in JFR LeakProfiler In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 18:57:45 GMT, Roman Kennke wrote: > While doing some fixes for Lilliput in JFR I noticed a couple of unused code paths. Let's remove them. > Specifically, it's the entirety of saveRestore.hpp/cpp and a helper method in edgeUtils.hpp/cpp. > > Testing: > - [x] tier1 > - [x] jdk/jfr We are so few working on JFR so we have decided that one Reviewer is ok - please go ahead. ------------- PR: https://git.openjdk.java.net/jdk/pull/5899 From markus.gronlund at oracle.com Tue Oct 12 12:37:28 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 12 Oct 2021 12:37:28 +0000 Subject: RFC: (How to?) Replace use of mark-word in leak-profiler (Lilliput) In-Reply-To: References: Message-ID: Hi Roman, Thank you for bringing this up. I am exploring a few ideas, and I will get back to you soon. Cheers Markus -----Original Message----- From: hotspot-jfr-dev On Behalf Of Roman Kennke Sent: den 8 oktober 2021 17:44 To: hotspot-jfr-dev ; lilliput-dev at openjdk.java.net Subject: RFC: (How to?) Replace use of mark-word in leak-profiler (Lilliput) Hi there, I'm currently thinking about an issue that came up when I tested JFR/Leakprofiler with Lilliput. First come context: In Lilliput I am storing a (compressed) Klass* in the object header, and want to phase out all uses of the dedicated Klass*-word and then remove that. This means that we need to be a little more careful when accessing the object header and/or the object's klass. In the leak-profiler, we (temporarily) store an Edge* into the object header, and preserve the actual mark in a table. However, that means that the heap traversal would not work anymore because the object doesn't have a valid Klass* anymore. Therefore I'm thinking about alternative ways to associate objects with an Edge*: 1. Use a (hash-)table for it (oop->Edge*), in EdgeStore. 2. Compress the Edge* to 32bits and store that only in the lower 32bits of the header (the Klass* is in the upper 32bits, currently). Not quite sure how to do this, though, it means we have to control allocation of the Edge instances in a contiguous space. 3. Store the object Klass* somewhere as long as we have it (before overriding it in EdgeStore::associate_leak_content_with_candidate()), and use that for iterating the object (in BFSClosure::iterate()). But where? Maybe in the Edge to the object? I.o.w. each Edge would also store the Klass* of its pointee? I wanted to check with you if any of those approaches make sense to you, or maybe you have even better ideas? Thanks for helping, Roman From rkennke at redhat.com Tue Oct 12 13:19:56 2021 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 12 Oct 2021 15:19:56 +0200 Subject: RFC: (How to?) Replace use of mark-word in leak-profiler (Lilliput) In-Reply-To: References: Message-ID: Thank you, Markus! In the meantime I implemented proposal #1, map oop->Edge* using a hashtable: https://github.com/openjdk/lilliput/pull/18 If you find a better way to do that, I would appreciate it! Meanwhile, I will leave that PR#18 open. Thanks, Roman > Hi Roman, > > Thank you for bringing this up. > > I am exploring a few ideas, and I will get back to you soon. > > Cheers > Markus > > -----Original Message----- > From: hotspot-jfr-dev On Behalf Of Roman Kennke > Sent: den 8 oktober 2021 17:44 > To: hotspot-jfr-dev ; lilliput-dev at openjdk.java.net > Subject: RFC: (How to?) Replace use of mark-word in leak-profiler (Lilliput) > > Hi there, > > I'm currently thinking about an issue that came up when I tested JFR/Leakprofiler with Lilliput. > > First come context: In Lilliput I am storing a (compressed) Klass* in the object header, and want to phase out all uses of the dedicated Klass*-word and then remove that. This means that we need to be a little more careful when accessing the object header and/or the object's klass. > > In the leak-profiler, we (temporarily) store an Edge* into the object header, and preserve the actual mark in a table. However, that means that the heap traversal would not work anymore because the object doesn't have a valid Klass* anymore. > > Therefore I'm thinking about alternative ways to associate objects with an Edge*: > > 1. Use a (hash-)table for it (oop->Edge*), in EdgeStore. > 2. Compress the Edge* to 32bits and store that only in the lower 32bits of the header (the Klass* is in the upper 32bits, currently). Not quite sure how to do this, though, it means we have to control allocation of the Edge instances in a contiguous space. > 3. Store the object Klass* somewhere as long as we have it (before overriding it in EdgeStore::associate_leak_content_with_candidate()), > and use that for iterating the object (in BFSClosure::iterate()). But where? Maybe in the Edge to the object? I.o.w. each Edge would also store the Klass* of its pointee? > > I wanted to check with you if any of those approaches make sense to you, or maybe you have even better ideas? > > Thanks for helping, > Roman > From rkennke at openjdk.java.net Tue Oct 12 13:20:51 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 12 Oct 2021 13:20:51 GMT Subject: Integrated: 8275074: Cleanup unused code in JFR LeakProfiler In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 18:57:45 GMT, Roman Kennke wrote: > While doing some fixes for Lilliput in JFR I noticed a couple of unused code paths. Let's remove them. > Specifically, it's the entirety of saveRestore.hpp/cpp and a helper method in edgeUtils.hpp/cpp. > > Testing: > - [x] tier1 > - [x] jdk/jfr This pull request has now been integrated. Changeset: e393c5ea Author: Roman Kennke URL: https://git.openjdk.java.net/jdk/commit/e393c5ea9d9a254cdacbd311498c55c560e8ab25 Stats: 245 lines in 4 files changed: 0 ins; 245 del; 0 mod 8275074: Cleanup unused code in JFR LeakProfiler Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/5899 From markus.gronlund at oracle.com Tue Oct 12 22:52:27 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 12 Oct 2021 22:52:27 +0000 Subject: RFC: (How to?) Replace use of mark-word in leak-profiler (Lilliput) In-Reply-To: References: Message-ID: Hi Roman, Providing another hashtable works fine to solve this problem, but I am a little bit concerned that the overhead might not fully warrant it. The default hashtable has 1009 buckets IIRC, but the number of leak candidates (samples) found during heap traversal might only be a relatively small number (default queue size is 256). I was trying to come up with something more lightweight, albeit the hashtable solution might be more straightforward to understand. This solution still uses space available in the markword, since we have already provisioned to use this as a "scratch area" as part of setup - but it is now limited to accommodate Lilliput (i.e. restricted to use only the lower 32-bits only). I hope this will enable you and the Lilliput team to make progress. https://github.com/openjdk/jdk/pull/5918 Thanks Markus -----Original Message----- From: Roman Kennke Sent: den 12 oktober 2021 15:20 To: Markus Gronlund ; hotspot-jfr-dev ; lilliput-dev at openjdk.java.net Subject: Re: RE: RFC: (How to?) Replace use of mark-word in leak-profiler (Lilliput) Thank you, Markus! In the meantime I implemented proposal #1, map oop->Edge* using a hashtable: https://urldefense.com/v3/__https://github.com/openjdk/lilliput/pull/18__;!!ACWV5N9M2RV99hQ!ZmQY9j8-lGVFEdImbsZ59XMHW7lZ3Z-y_m468GDj-fk7Diiu714wMSWlaQFJqekrscIc$ If you find a better way to do that, I would appreciate it! Meanwhile, I will leave that PR#18 open. Thanks, Roman > Hi Roman, > > Thank you for bringing this up. > > I am exploring a few ideas, and I will get back to you soon. > > Cheers > Markus > > -----Original Message----- > From: hotspot-jfr-dev On > Behalf Of Roman Kennke > Sent: den 8 oktober 2021 17:44 > To: hotspot-jfr-dev ; > lilliput-dev at openjdk.java.net > Subject: RFC: (How to?) Replace use of mark-word in leak-profiler > (Lilliput) > > Hi there, > > I'm currently thinking about an issue that came up when I tested JFR/Leakprofiler with Lilliput. > > First come context: In Lilliput I am storing a (compressed) Klass* in the object header, and want to phase out all uses of the dedicated Klass*-word and then remove that. This means that we need to be a little more careful when accessing the object header and/or the object's klass. > > In the leak-profiler, we (temporarily) store an Edge* into the object header, and preserve the actual mark in a table. However, that means that the heap traversal would not work anymore because the object doesn't have a valid Klass* anymore. > > Therefore I'm thinking about alternative ways to associate objects with an Edge*: > > 1. Use a (hash-)table for it (oop->Edge*), in EdgeStore. > 2. Compress the Edge* to 32bits and store that only in the lower 32bits of the header (the Klass* is in the upper 32bits, currently). Not quite sure how to do this, though, it means we have to control allocation of the Edge instances in a contiguous space. > 3. Store the object Klass* somewhere as long as we have it (before > overriding it in EdgeStore::associate_leak_content_with_candidate()), > and use that for iterating the object (in BFSClosure::iterate()). But where? Maybe in the Edge to the object? I.o.w. each Edge would also store the Klass* of its pointee? > > I wanted to check with you if any of those approaches make sense to you, or maybe you have even better ideas? > > Thanks for helping, > Roman > From ysuenaga at openjdk.java.net Wed Oct 13 01:08:22 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 13 Oct 2021 01:08:22 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v6] In-Reply-To: References: Message-ID: > We set `dumppath` in `-XX:FlightRecorderOptions` or `JFR.configure dumppath` jcmd when we want to set emergency dump path. However they do not afffect. > > ### -XX:FlightRecorderOptions > > > $ java -XX:FlightRecorderOptions=dumppath=`pwd` -XX:StartFlightRecording -Xlog:exceptions=info --version > [0.032s][info][exceptions] Exception (0x00000007470163b8) > thrown [open/src/hotspot/share/services/diagnosticFramework.cpp, line 215] > for thread 0x00007f4f700236a0 > [0.033s][error][arguments ] Unknown argument 'dumppath' in diagnostic command. > Error occurred during initialization of VM > Failure when starting JFR on_create_vm_2 > > > ### jcmd > > `jcmd` shows the configuration change was succeeded, but it would not affect. > > > $ jcmd 1046 JFR.configure dumppath=/tmp > 1046: > Dump path: /tmp Yasumasa Suenaga 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 10 additional commits since the last revision: - Use current directory if emergency dump fails on specified path - Merge remote-tracking branch 'upstream/master' into JDK-8271949 - Print warning message instead of throwing exception if JFR will not write emergency dump - Merge remote-tracking branch 'upstream/master' into JDK-8271949 - Set absolute path to JFR emergency dump path - Check write permission on JFR emergency dump path in configuration - Update testcase - Merge remote-tracking branch 'upstream/master' into JDK-8271949 - Remove USER_HOME - 8271949: dumppath in -XX:FlightRecorderOptions does not affect ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5019/files - new: https://git.openjdk.java.net/jdk/pull/5019/files/b8da8def..d4a7674d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5019&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5019&range=04-05 Stats: 43314 lines in 1367 files changed: 28430 ins; 8430 del; 6454 mod Patch: https://git.openjdk.java.net/jdk/pull/5019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5019/head:pull/5019 PR: https://git.openjdk.java.net/jdk/pull/5019 From ysuenaga at openjdk.java.net Wed Oct 13 01:08:23 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 13 Oct 2021 01:08:23 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v5] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 11:33:21 GMT, Markus Gr?nlund wrote: > I would recommend a fallback to the existing behaviour, that is to write it to $PWD as to not disrupt support organizations. I updated this PR to fallback to use current directory if emergency dump fails on `dumppath`. Could you review again? ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From mgronlun at openjdk.java.net Wed Oct 13 12:04:01 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Oct 2021 12:04:01 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v6] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 01:08:22 GMT, Yasumasa Suenaga wrote: >> We set `dumppath` in `-XX:FlightRecorderOptions` or `JFR.configure dumppath` jcmd when we want to set emergency dump path. However they do not afffect. >> >> ### -XX:FlightRecorderOptions >> >> >> $ java -XX:FlightRecorderOptions=dumppath=`pwd` -XX:StartFlightRecording -Xlog:exceptions=info --version >> [0.032s][info][exceptions] Exception (0x00000007470163b8) >> thrown [open/src/hotspot/share/services/diagnosticFramework.cpp, line 215] >> for thread 0x00007f4f700236a0 >> [0.033s][error][arguments ] Unknown argument 'dumppath' in diagnostic command. >> Error occurred during initialization of VM >> Failure when starting JFR on_create_vm_2 >> >> >> ### jcmd >> >> `jcmd` shows the configuration change was succeeded, but it would not affect. >> >> >> $ jcmd 1046 JFR.configure dumppath=/tmp >> 1046: >> Dump path: /tmp > > Yasumasa Suenaga 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 10 additional commits since the last revision: > > - Use current directory if emergency dump fails on specified path > - Merge remote-tracking branch 'upstream/master' into JDK-8271949 > - Print warning message instead of throwing exception if JFR will not write emergency dump > - Merge remote-tracking branch 'upstream/master' into JDK-8271949 > - Set absolute path to JFR emergency dump path > - Check write permission on JFR emergency dump path in configuration > - Update testcase > - Merge remote-tracking branch 'upstream/master' into JDK-8271949 > - Remove USER_HOME > - 8271949: dumppath in -XX:FlightRecorderOptions does not affect This is now causing secondary crashes: jvm!VMError::report+0xb7a [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 726] jvm!VMError::report_and_die+0x6ce [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 1652] jvm!VMError::report_and_die+0x81 [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 1437] jvm!report_vm_error+0x9d [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\debug.cpp @ 283] jvm!create_emergency_dump_path+0x2f [d:\dev\github\jdk_copy\open\src\hotspot\share\jfr\recorder\repository\jfrEmergencyDump.cpp @ 113] jvm!JfrEmergencyDump::open_emergency_dump_file+0x7b [d:\dev\github\jdk_copy\open\src\hotspot\share\jfr\recorder\repository\jfrEmergencyDump.cpp @ 146] jvm!JfrEmergencyDump::on_vm_error_report+0x57 [d:\dev\github\jdk_copy\open\src\hotspot\share\jfr\recorder\repository\jfrEmergencyDump.cpp @ 185] jvm!JfrRepository::on_vm_error_report+0x1c [d:\dev\github\jdk_copy\open\src\hotspot\share\jfr\recorder\repository\jfrRepository.cpp @ 94] jvm!Jfr::on_vm_error_report+0x1f [d:\dev\github\jdk_copy\open\src\hotspot\share\jfr\jfr.cpp @ 105] jvm!VMError::report+0xb7a [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 726] jvm!VMError::report_and_die+0x5b8 [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 1621] jvm!VMError::report_and_die+0x8d [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 1425] jvm!VMError::report_and_die+0x51 [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 1431] jvm!report_error+0x39 [d:\dev\github\jdk_copy\open\src\hotspot\os\windows\os_windows.cpp @ 2477] jvm!topLevelExceptionFilter+0x5a5 [d:\dev\github\jdk_copy\open\src\hotspot\os\windows\os_windows.cpp @ 2680] jvm!`thread_native_entry'::`1'::filt$0+0x22 [d:\dev\github\jdk_copy\open\src\hotspot\os\windows\os_windows.cpp @ 545] VCRUNTIME140!__C_specific_handler+0xa0 [d:\A01_work\12\s\src\vctools\crt\vcruntime\src\eh\riscchandler.cpp @ 389] ntdll!RtlpExecuteHandlerForException+0xf ntdll!RtlDispatchException+0x40f ntdll!KiUserExceptionDispatch+0x2e ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From mgronlun at openjdk.java.net Wed Oct 13 17:49:18 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Oct 2021 17:49:18 GMT Subject: RFR: 8266936: Add a finalization JFR event [v15] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Merge branch '8266936-alt' of github.com:mgronlun/jdk into 8266936-alt - symbols-unix - jvm.h and JVM_Entry - no precompiled headers and mtServiceability nmt classification - remove rehashing and rely on default grow_hint for table resize - mtStatistics - localize - cleanup - FinalizerStatistics - Model as finalizerService - ... and 34 more: https://git.openjdk.java.net/jdk/compare/124f8237...5359a793 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4731/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=14 Stats: 1893 lines in 36 files changed: 1375 ins; 409 del; 109 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Wed Oct 13 18:03:25 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Oct 2021 18:03:25 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - cleanup - rebased and adjusted for new lock rankings ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/5359a793..96a9d6bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=14-15 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From duke at openjdk.java.net Wed Oct 13 18:46:08 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 13 Oct 2021 18:46:08 GMT Subject: RFR: 8275241: Unused ArrayList is created in RequestEngine.addHooks Message-ID: Local `ArrayList` is created in a method `RequestEngine.addHooks`. Elements are added to it, but then content is unused. Seems leftovers from some refactoring. Found by IntelliJ IDEA inspection "Mismatched query and update of collection" ------------- Commit messages: - [PATCH] Unused ArrayList is created in RequestEngine.addHooks Changes: https://git.openjdk.java.net/jdk/pull/5629/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5629&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275241 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5629.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5629/head:pull/5629 PR: https://git.openjdk.java.net/jdk/pull/5629 From egahlin at openjdk.java.net Wed Oct 13 22:07:48 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 13 Oct 2021 22:07:48 GMT Subject: RFR: 8275241: Unused ArrayList is created in RequestEngine.addHooks In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 07:48:10 GMT, Andrey Turbanov wrote: > Local `ArrayList` is created in a method `RequestEngine.addHooks`. Elements are added to it, but then content is unused. Seems leftovers from some refactoring. > Found by IntelliJ IDEA inspection "Mismatched query and update of collection" Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5629 From ysuenaga at openjdk.java.net Thu Oct 14 00:10:10 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 14 Oct 2021 00:10:10 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v7] In-Reply-To: References: Message-ID: <-EZberUoK6Q_0qV8QJWWSxKhgHrhAOGt76RUD0u_Ipc=.4a14ae1e-0f73-47df-9d6e-49f862a40afd@github.com> > We set `dumppath` in `-XX:FlightRecorderOptions` or `JFR.configure dumppath` jcmd when we want to set emergency dump path. However they do not afffect. > > ### -XX:FlightRecorderOptions > > > $ java -XX:FlightRecorderOptions=dumppath=`pwd` -XX:StartFlightRecording -Xlog:exceptions=info --version > [0.032s][info][exceptions] Exception (0x00000007470163b8) > thrown [open/src/hotspot/share/services/diagnosticFramework.cpp, line 215] > for thread 0x00007f4f700236a0 > [0.033s][error][arguments ] Unknown argument 'dumppath' in diagnostic command. > Error occurred during initialization of VM > Failure when starting JFR on_create_vm_2 > > > ### jcmd > > `jcmd` shows the configuration change was succeeded, but it would not affect. > > > $ jcmd 1046 JFR.configure dumppath=/tmp > 1046: > Dump path: /tmp Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Clear _path_buffer when emergency dump fallbacks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5019/files - new: https://git.openjdk.java.net/jdk/pull/5019/files/d4a7674d..55600a87 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5019&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5019&range=05-06 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5019/head:pull/5019 PR: https://git.openjdk.java.net/jdk/pull/5019 From ysuenaga at openjdk.java.net Thu Oct 14 00:10:14 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 14 Oct 2021 00:10:14 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v6] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 12:00:32 GMT, Markus Gr?nlund wrote: >> Yasumasa Suenaga 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 10 additional commits since the last revision: >> >> - Use current directory if emergency dump fails on specified path >> - Merge remote-tracking branch 'upstream/master' into JDK-8271949 >> - Print warning message instead of throwing exception if JFR will not write emergency dump >> - Merge remote-tracking branch 'upstream/master' into JDK-8271949 >> - Set absolute path to JFR emergency dump path >> - Check write permission on JFR emergency dump path in configuration >> - Update testcase >> - Merge remote-tracking branch 'upstream/master' into JDK-8271949 >> - Remove USER_HOME >> - 8271949: dumppath in -XX:FlightRecorderOptions does not affect > > This is now causing secondary crashes: > > jvm!VMError::report+0xb7a [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 726] > jvm!VMError::report_and_die+0x6ce [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 1652] > jvm!VMError::report_and_die+0x81 [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 1437] > jvm!report_vm_error+0x9d [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\debug.cpp @ 283] > jvm!create_emergency_dump_path+0x2f [d:\dev\github\jdk_copy\open\src\hotspot\share\jfr\recorder\repository\jfrEmergencyDump.cpp @ 113] > jvm!JfrEmergencyDump::open_emergency_dump_file+0x7b [d:\dev\github\jdk_copy\open\src\hotspot\share\jfr\recorder\repository\jfrEmergencyDump.cpp @ 146] > jvm!JfrEmergencyDump::on_vm_error_report+0x57 [d:\dev\github\jdk_copy\open\src\hotspot\share\jfr\recorder\repository\jfrEmergencyDump.cpp @ 185] > jvm!JfrRepository::on_vm_error_report+0x1c [d:\dev\github\jdk_copy\open\src\hotspot\share\jfr\recorder\repository\jfrRepository.cpp @ 94] > jvm!Jfr::on_vm_error_report+0x1f [d:\dev\github\jdk_copy\open\src\hotspot\share\jfr\jfr.cpp @ 105] > jvm!VMError::report+0xb7a [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 726] > jvm!VMError::report_and_die+0x5b8 [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 1621] > jvm!VMError::report_and_die+0x8d [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 1425] > jvm!VMError::report_and_die+0x51 [d:\dev\github\jdk_copy\open\src\hotspot\share\utilities\vmError.cpp @ 1431] > jvm!report_error+0x39 [d:\dev\github\jdk_copy\open\src\hotspot\os\windows\os_windows.cpp @ 2477] > jvm!topLevelExceptionFilter+0x5a5 [d:\dev\github\jdk_copy\open\src\hotspot\os\windows\os_windows.cpp @ 2680] > jvm!`thread_native_entry'::`1'::filt$0+0x22 [d:\dev\github\jdk_copy\open\src\hotspot\os\windows\os_windows.cpp @ 545] > VCRUNTIME140!__C_specific_handler+0xa0 [d:\A01_work\12\s\src\vctools\crt\vcruntime\src\eh\riscchandler.cpp @ 389] > ntdll!RtlpExecuteHandlerForException+0xf > ntdll!RtlDispatchException+0x40f > ntdll!KiUserExceptionDispatch+0x2e @mgronlun Thanks for your report! I fixed it in new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From mgronlun at openjdk.java.net Thu Oct 14 10:26:51 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Oct 2021 10:26:51 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v7] In-Reply-To: <-EZberUoK6Q_0qV8QJWWSxKhgHrhAOGt76RUD0u_Ipc=.4a14ae1e-0f73-47df-9d6e-49f862a40afd@github.com> References: <-EZberUoK6Q_0qV8QJWWSxKhgHrhAOGt76RUD0u_Ipc=.4a14ae1e-0f73-47df-9d6e-49f862a40afd@github.com> Message-ID: On Thu, 14 Oct 2021 00:10:10 GMT, Yasumasa Suenaga wrote: >> We set `dumppath` in `-XX:FlightRecorderOptions` or `JFR.configure dumppath` jcmd when we want to set emergency dump path. However they do not afffect. >> >> ### -XX:FlightRecorderOptions >> >> >> $ java -XX:FlightRecorderOptions=dumppath=`pwd` -XX:StartFlightRecording -Xlog:exceptions=info --version >> [0.032s][info][exceptions] Exception (0x00000007470163b8) >> thrown [open/src/hotspot/share/services/diagnosticFramework.cpp, line 215] >> for thread 0x00007f4f700236a0 >> [0.033s][error][arguments ] Unknown argument 'dumppath' in diagnostic command. >> Error occurred during initialization of VM >> Failure when starting JFR on_create_vm_2 >> >> >> ### jcmd >> >> `jcmd` shows the configuration change was succeeded, but it would not affect. >> >> >> $ jcmd 1046 JFR.configure dumppath=/tmp >> 1046: >> Dump path: /tmp > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Clear _path_buffer when emergency dump fallbacks Looks good. Can you please add the following diff. It adds a warning to let users know that it was not possible to create the file in their preferred location. It complements the warning written at start time, with up-to-date information should a problem have arisen at dump time.

diff --git a/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp b/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
index 91d2be766da..c00bed02b52 100644
--- a/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
+++ b/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
@@ -140,8 +140,8 @@ bool JfrEmergencyDump::open_emergency_dump_file() {

   bool result = open_emergency_dump_fd(create_emergency_dump_path());
   if (!result && *_dump_path != '\0') {
-    // Attempt to create emergency dump to current directory
-    // if we couldn't create it on `dumppath=`.
+    log_warning(jfr)("Unable to create an emergency dump file at the location set by dumppath=%s", _dump_path);
+    // Fallback. Try to create it in the current directory.
     *_dump_path = '\0';
     *_path_buffer = '\0';
     result = open_emergency_dump_fd(create_emergency_dump_path());

------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From ysuenaga at openjdk.java.net Thu Oct 14 10:45:10 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 14 Oct 2021 10:45:10 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v8] In-Reply-To: References: Message-ID: > We set `dumppath` in `-XX:FlightRecorderOptions` or `JFR.configure dumppath` jcmd when we want to set emergency dump path. However they do not afffect. > > ### -XX:FlightRecorderOptions > > > $ java -XX:FlightRecorderOptions=dumppath=`pwd` -XX:StartFlightRecording -Xlog:exceptions=info --version > [0.032s][info][exceptions] Exception
(0x00000007470163b8) > thrown [open/src/hotspot/share/services/diagnosticFramework.cpp, line 215] > for thread 0x00007f4f700236a0 > [0.033s][error][arguments ] Unknown argument 'dumppath' in diagnostic command. > Error occurred during initialization of VM > Failure when starting JFR on_create_vm_2 > > > ### jcmd > > `jcmd` shows the configuration change was succeeded, but it would not affect. > > > $ jcmd 1046 JFR.configure dumppath=/tmp > 1046: > Dump path: /tmp Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Add warning message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5019/files - new: https://git.openjdk.java.net/jdk/pull/5019/files/55600a87..feb72290 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5019&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5019&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5019/head:pull/5019 PR: https://git.openjdk.java.net/jdk/pull/5019 From ysuenaga at openjdk.java.net Thu Oct 14 10:45:11 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 14 Oct 2021 10:45:11 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v7] In-Reply-To: References: <-EZberUoK6Q_0qV8QJWWSxKhgHrhAOGt76RUD0u_Ipc=.4a14ae1e-0f73-47df-9d6e-49f862a40afd@github.com> Message-ID: On Thu, 14 Oct 2021 10:21:23 GMT, Markus Gr?nlund wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear _path_buffer when emergency dump fallbacks > > Looks good. > > Can you please add the following diff. It adds a warning to let users know that it was not possible to create the file in their preferred location. It complements the warning written at start time, with up-to-date information should a problem have arisen at dump time. >
> 
> diff --git a/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp b/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> index 91d2be766da..c00bed02b52 100644
> --- a/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> +++ b/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> @@ -140,8 +140,8 @@ bool JfrEmergencyDump::open_emergency_dump_file() {
> 
>    bool result = open_emergency_dump_fd(create_emergency_dump_path());
>    if (!result && *_dump_path != '\0') {
> -    // Attempt to create emergency dump to current directory
> -    // if we couldn't create it on `dumppath=`.
> +    log_warning(jfr)("Unable to create an emergency dump file at the location set by dumppath=%s", _dump_path);
> +    // Fallback. Try to create it in the current directory.
>      *_dump_path = '\0';
>      *_path_buffer = '\0';
>      result = open_emergency_dump_fd(create_emergency_dump_path());
> 
> 
Thanks @mgronlun ! I pushed your change to this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From mgronlun at openjdk.java.net Thu Oct 14 10:48:48 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Oct 2021 10:48:48 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v8] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 10:45:10 GMT, Yasumasa Suenaga wrote: >> We set `dumppath` in `-XX:FlightRecorderOptions` or `JFR.configure dumppath` jcmd when we want to set emergency dump path. However they do not afffect. >> >> ### -XX:FlightRecorderOptions >> >> >> $ java -XX:FlightRecorderOptions=dumppath=`pwd` -XX:StartFlightRecording -Xlog:exceptions=info --version >> [0.032s][info][exceptions] Exception
(0x00000007470163b8) >> thrown [open/src/hotspot/share/services/diagnosticFramework.cpp, line 215] >> for thread 0x00007f4f700236a0 >> [0.033s][error][arguments ] Unknown argument 'dumppath' in diagnostic command. >> Error occurred during initialization of VM >> Failure when starting JFR on_create_vm_2 >> >> >> ### jcmd >> >> `jcmd` shows the configuration change was succeeded, but it would not affect. >> >> >> $ jcmd 1046 JFR.configure dumppath=/tmp >> 1046: >> Dump path: /tmp > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add warning message Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From egahlin at openjdk.java.net Thu Oct 14 11:22:51 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 14 Oct 2021 11:22:51 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v8] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 10:45:10 GMT, Yasumasa Suenaga wrote: >> We set `dumppath` in `-XX:FlightRecorderOptions` or `JFR.configure dumppath` jcmd when we want to set emergency dump path. However they do not afffect. >> >> ### -XX:FlightRecorderOptions >> >> >> $ java -XX:FlightRecorderOptions=dumppath=`pwd` -XX:StartFlightRecording -Xlog:exceptions=info --version >> [0.032s][info][exceptions] Exception (0x00000007470163b8) >> thrown [open/src/hotspot/share/services/diagnosticFramework.cpp, line 215] >> for thread 0x00007f4f700236a0 >> [0.033s][error][arguments ] Unknown argument 'dumppath' in diagnostic command. >> Error occurred during initialization of VM >> Failure when starting JFR on_create_vm_2 >> >> >> ### jcmd >> >> `jcmd` shows the configuration change was succeeded, but it would not affect. >> >> >> $ jcmd 1046 JFR.configure dumppath=/tmp >> 1046: >> Dump path: /tmp > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add warning message Since DCmdArgument was not part of the "startup dcmd" (in jfrOptionSet.cpp), I think a CSR request is needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From ysuenaga at openjdk.java.net Thu Oct 14 12:17:52 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 14 Oct 2021 12:17:52 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v8] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 11:18:12 GMT, Erik Gahlin wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Add warning message > > Since DCmdArgument was not part of the "startup dcmd" (in jfrOptionSet.cpp), I think a CSR request is needed. @egahlin > Since DCmdArgument was not part of the "startup dcmd" (in jfrOptionSet.cpp), I think a CSR request is needed. However DCmdConfigure.java already has `dumppath` so we can see it on JFR.configure dcmd. $ jcmd 1046 JFR.configure dumppath=/tmp 1046: Dump path: /tmp Do we still need a CSR? ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From egahlin at openjdk.java.net Thu Oct 14 12:57:50 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 14 Oct 2021 12:57:50 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v8] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 10:45:10 GMT, Yasumasa Suenaga wrote: >> We set `dumppath` in `-XX:FlightRecorderOptions` or `JFR.configure dumppath` jcmd when we want to set emergency dump path. However they do not afffect. >> >> ### -XX:FlightRecorderOptions >> >> >> $ java -XX:FlightRecorderOptions=dumppath=`pwd` -XX:StartFlightRecording -Xlog:exceptions=info --version >> [0.032s][info][exceptions] Exception (0x00000007470163b8) >> thrown [open/src/hotspot/share/services/diagnosticFramework.cpp, line 215] >> for thread 0x00007f4f700236a0 >> [0.033s][error][arguments ] Unknown argument 'dumppath' in diagnostic command. >> Error occurred during initialization of VM >> Failure when starting JFR on_create_vm_2 >> >> >> ### jcmd >> >> `jcmd` shows the configuration change was succeeded, but it would not affect. >> >> >> $ jcmd 1046 JFR.configure dumppath=/tmp >> 1046: >> Dump path: /tmp > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add warning message Command-line options are public interfaces and if we change those, there should be a CSR. There is overlap in functionality between -XX:FlightRecorderOption and 'jfr configure', but they are not the same interface. I can review the CSR. A few sentences describing the change and the relevant diff of jfrOptionSet.cpp should be sufficient. ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From coleenp at openjdk.java.net Thu Oct 14 22:06:49 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Oct 2021 22:06:49 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 18:03:25 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. >> >> We also like to assist users in replacing and mitigating uses in non-JDK code. >> >> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). >> >> Thanks >> Markus > > Markus Gr?nlund has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. src/hotspot/share/jfr/support/jfrSymbolTable.cpp line 75: > 73: > 74: JfrSymbolTable::JfrSymbolTable() : > 75: _symbol_table(new SymbolTable(this)), I'm confused about which symbol table this is. Is this the same SymbolTable as classfile/symbolTable.cpp? that instance is assumed to be a singleton. Is this a different SymbolTable and can it have a different name (thought it was JfrSymbolTable). src/hotspot/share/jfr/support/jfrSymbolTable.hpp line 68: > 66: template class, typename, size_t> > 67: friend class HashTableHost; > 68: typedef HashTableHost SymbolTable; Oh here it is. Since it's an enclosed type, can you rename it something simpler like Symbols and the other Strings? ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From coleenp at openjdk.java.net Thu Oct 14 22:06:50 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Oct 2021 22:06:50 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 10:54:18 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/services/finalizerService.cpp line 44: >> >>> 42: _ik(ik), >>> 43: _objects_on_heap(0), >>> 44: _total_finalizers_run(0) {} >> >> Is this hashtable for every InstanceKlass that defines a finalizer? How many are there generally? Why couldn't this be a simple hashtable like ResourceHashtable (soon to be renamed) which you can write in only a few lines of code? > > This hashtable holds a FinalizerEntry for every InstanceKlass that provides a non-empty finalizer method and have allocated at least one object. How many there are in general depends on the application. A ResourceHashtable does not have the concurrency property required, as lookups and inserts will happen as part of object allocation. ok. >> src/hotspot/share/services/finalizerService.cpp line 331: >> >>> 329: } >>> 330: Thread* const thread = Thread::current(); >>> 331: // We use current size >> >> Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup. >> You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive() > > "Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup." > Thank you, that is true. The only concurrent work required will be to grow the table. > > "You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive()" > > A precondition is that the code doing the lookup hold the ClassLoaderDataGraph_lock or is at a safepoint. Is that still the case? Would not purge_unloaded() take out the InstanceKlass from the table, as part of unloading, before !ik->is_loader_alive() is published to the outside world? Ok, I see - grow the table. I'm not sure if you need to ask ik->is_loader_alive() or not, but I think you do. The InstanceKlass is removed from your table during class unloading but before that during concurrent class unloading, the class might not be alive while you look at it and concurrent class unloading hasn't gotten around to removing it yet. Since you save classes regardless of CLD, you have to check if it's alive. See classLoaderDataGraph.cpp ClassLoaderDataGraphIterator for example. The CLDG_lock only keeps the graph from not getting modified, but the classes in it might be dead. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From coleenp at openjdk.java.net Thu Oct 14 22:06:50 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Oct 2021 22:06:50 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 21:58:42 GMT, Coleen Phillimore wrote: >> "Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup." >> Thank you, that is true. The only concurrent work required will be to grow the table. >> >> "You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive()" >> >> A precondition is that the code doing the lookup hold the ClassLoaderDataGraph_lock or is at a safepoint. Is that still the case? Would not purge_unloaded() take out the InstanceKlass from the table, as part of unloading, before !ik->is_loader_alive() is published to the outside world? > > Ok, I see - grow the table. > > I'm not sure if you need to ask ik->is_loader_alive() or not, but I think you do. The InstanceKlass is removed from your table during class unloading but before that during concurrent class unloading, the class might not be alive while you look at it and concurrent class unloading hasn't gotten around to removing it yet. Since you save classes regardless of CLD, you have to check if it's alive. See classLoaderDataGraph.cpp ClassLoaderDataGraphIterator for example. The CLDG_lock only keeps the graph from not getting modified, but the classes in it might be dead. That said, I don't see where you return an InstanceKlass in the table, which would need this check. Not in class_unloading_do because this follows the _unloading list. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Thu Oct 14 22:31:54 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Oct 2021 22:31:54 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:02:43 GMT, Coleen Phillimore wrote: >> Ok, I see - grow the table. >> >> I'm not sure if you need to ask ik->is_loader_alive() or not, but I think you do. The InstanceKlass is removed from your table during class unloading but before that during concurrent class unloading, the class might not be alive while you look at it and concurrent class unloading hasn't gotten around to removing it yet. Since you save classes regardless of CLD, you have to check if it's alive. See classLoaderDataGraph.cpp ClassLoaderDataGraphIterator for example. The CLDG_lock only keeps the graph from not getting modified, but the classes in it might be dead. > > That said, I don't see where you return an InstanceKlass in the table, which would need this check. Not in class_unloading_do because this follows the _unloading list. So there is already support for concurrent class unloading today in JFR, and the protocol is built around the CLDG_lock. If JFR holds it, concurrent class unloading cannot run. If GC holds it, JFR cannot inspect classes. That's why the table inspection is guarded via the CLDG_lock, for mutual exclusion to avoid this problem. I.e. if concurrent class unloading is in progress, JFR will not inspect the table. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Thu Oct 14 22:39:50 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Oct 2021 22:39:50 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 21:46:36 GMT, Coleen Phillimore wrote: >> Markus Gr?nlund has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/hotspot/share/jfr/support/jfrSymbolTable.hpp line 68: > >> 66: template class, typename, size_t> >> 67: friend class HashTableHost; >> 68: typedef HashTableHost SymbolTable; > > Oh here it is. Since it's an enclosed type, can you rename it something simpler like Symbols and the other Strings? Maybe :) ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From ysuenaga at openjdk.java.net Fri Oct 15 00:00:50 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 15 Oct 2021 00:00:50 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v8] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 12:54:50 GMT, Erik Gahlin wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Add warning message > > Command-line options are public interfaces and if we change those, there should be a CSR. There is overlap in functionality between -XX:FlightRecorderOption and 'jfr configure', but they are not the same interface. > > I can review the CSR. > > A few sentences describing the change and the relevant diff of jfrOptionSet.cpp should be sufficient. @egahlin I've filed [CSR](https://bugs.openjdk.java.net/browse/JDK-8275314) for this PR. Could you review it? I appreciate to edit it if it is not enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From mgronlun at openjdk.java.net Fri Oct 15 09:27:54 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Oct 2021 09:27:54 GMT Subject: RFR: 8266936: Add a finalization JFR event [v17] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: - renames - spelling ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/96a9d6bf..9b418149 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=15-16 Stats: 80 lines in 6 files changed: 0 ins; 0 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Fri Oct 15 09:30:52 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Oct 2021 09:30:52 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 21:43:27 GMT, Coleen Phillimore wrote: >> Markus Gr?nlund has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/hotspot/share/jfr/support/jfrSymbolTable.cpp line 75: > >> 73: >> 74: JfrSymbolTable::JfrSymbolTable() : >> 75: _symbol_table(new SymbolTable(this)), > > I'm confused about which symbol table this is. Is this the same SymbolTable as classfile/symbolTable.cpp? that instance is assumed to be a singleton. Is this a different SymbolTable and can it have a different name (thought it was JfrSymbolTable). Renamed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Fri Oct 15 09:30:53 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Oct 2021 09:30:53 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:36:30 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/jfr/support/jfrSymbolTable.hpp line 68: >> >>> 66: template class, typename, size_t> >>> 67: friend class HashTableHost; >>> 68: typedef HashTableHost SymbolTable; >> >> Oh here it is. Since it's an enclosed type, can you rename it something simpler like Symbols and the other Strings? > > Maybe :) Renamed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From coleenp at openjdk.java.net Fri Oct 15 18:16:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Oct 2021 18:16:55 GMT Subject: RFR: 8266936: Add a finalization JFR event [v17] In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 09:27:54 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. >> >> We also like to assist users in replacing and mitigating uses in non-JDK code. >> >> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: > > - renames > - spelling Thanks for doing the renames. Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Sat Oct 16 15:24:52 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Sat, 16 Oct 2021 15:24:52 GMT Subject: RFR: 8266936: Add a finalization JFR event [v18] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: ThreadBlockInVM instead of ThreadToNativeFromVM for sampling exclusion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/9b418149..d10eb309 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=16-17 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From ysuenaga at openjdk.java.net Sun Oct 17 12:16:52 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 17 Oct 2021 12:16:52 GMT Subject: Integrated: 8271949: dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 13:13:12 GMT, Yasumasa Suenaga wrote: > We set `dumppath` in `-XX:FlightRecorderOptions` or `JFR.configure dumppath` jcmd when we want to set emergency dump path. However they do not afffect. > > ### -XX:FlightRecorderOptions > > > $ java -XX:FlightRecorderOptions=dumppath=`pwd` -XX:StartFlightRecording -Xlog:exceptions=info --version > [0.032s][info][exceptions] Exception (0x00000007470163b8) > thrown [open/src/hotspot/share/services/diagnosticFramework.cpp, line 215] > for thread 0x00007f4f700236a0 > [0.033s][error][arguments ] Unknown argument 'dumppath' in diagnostic command. > Error occurred during initialization of VM > Failure when starting JFR on_create_vm_2 > > > ### jcmd > > `jcmd` shows the configuration change was succeeded, but it would not affect. > > > $ jcmd 1046 JFR.configure dumppath=/tmp > 1046: > Dump path: /tmp This pull request has now been integrated. Changeset: 31500692 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/31500692d1503cb73249e0425e6930aaaa49258a Stats: 170 lines in 10 files changed: 138 ins; 3 del; 29 mod 8271949: dumppath in -XX:FlightRecorderOptions does not affect Reviewed-by: ddong, mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From mgronlun at openjdk.java.net Sun Oct 17 13:10:08 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Sun, 17 Oct 2021 13:10:08 GMT Subject: RFR: 8274298: JFR Thread Sampler thread must not acquire malloc lock after suspending a thread because of possible deadlock Message-ID: <2yR6FiLU3rbaeGMe4VGRTiZcVDjBbqWrq44VbB3iMd0=.8b9f231f-8f87-43c3-acad-733815c50fe2@github.com> Greetings, [JDK-8233705](https://bugs.openjdk.java.net/browse/JDK-8233705) introduced a means to only iterate the incrementally tagged Klasses, instead of the entire set of Klasses in the JVM, as part of serializing metadata information. The newly tagged Klasses are enqueued onto a thread-local buffer using a load barrier. If the buffer runs out of space, a new buffer is accommodated, either from a free list or via a new allocation. This is problematic for the JfrThreadSampler because the thread it has suspended could hold the malloc lock. For example, this could be the case if the suspended thread was in the process of deoptimization. The Deoptimization::UnrollBlock is a CHeapObj, and the vframes arrays use the NEW_C_HEAP_ARRAY macro. The solution to this problem is to explicitly monitor the size of the thread-local buffer of the JfrThreadSampler thread, and pre-emptively renew it before thread suspension. Testing: jdk_jfr, stress testing Thanks Markus ------------- Commit messages: - newline - no malloc by JfrThreadSampler Changes: https://git.openjdk.java.net/jdk/pull/5977/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5977&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274298 Stats: 93 lines in 9 files changed: 84 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5977.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5977/head:pull/5977 PR: https://git.openjdk.java.net/jdk/pull/5977 From dholmes at openjdk.java.net Sun Oct 17 23:58:51 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 17 Oct 2021 23:58:51 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v8] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 10:45:10 GMT, Yasumasa Suenaga wrote: >> We set `dumppath` in `-XX:FlightRecorderOptions` or `JFR.configure dumppath` jcmd when we want to set emergency dump path. However they do not afffect. >> >> ### -XX:FlightRecorderOptions >> >> >> $ java -XX:FlightRecorderOptions=dumppath=`pwd` -XX:StartFlightRecording -Xlog:exceptions=info --version >> [0.032s][info][exceptions] Exception (0x00000007470163b8) >> thrown [open/src/hotspot/share/services/diagnosticFramework.cpp, line 215] >> for thread 0x00007f4f700236a0 >> [0.033s][error][arguments ] Unknown argument 'dumppath' in diagnostic command. >> Error occurred during initialization of VM >> Failure when starting JFR on_create_vm_2 >> >> >> ### jcmd >> >> `jcmd` shows the configuration change was succeeded, but it would not affect. >> >> >> $ jcmd 1046 JFR.configure dumppath=/tmp >> 1046: >> Dump path: /tmp > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add warning message This change seems to have caused a number of JFR test failures: https://bugs.openjdk.java.net/browse/JDK-8275373 https://bugs.openjdk.java.net/browse/JDK-8275375 ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From ysuenaga at openjdk.java.net Mon Oct 18 01:56:51 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 18 Oct 2021 01:56:51 GMT Subject: RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v8] In-Reply-To: References: Message-ID: On Sun, 17 Oct 2021 23:55:57 GMT, David Holmes wrote: > This change seems to have caused a number of JFR test failures: https://bugs.openjdk.java.net/browse/JDK-8275373 https://bugs.openjdk.java.net/browse/JDK-8275375 I've sent PR as https://github.com/openjdk/jdk/pull/5984 to fix them. ------------- PR: https://git.openjdk.java.net/jdk/pull/5019 From ysuenaga at openjdk.java.net Mon Oct 18 01:58:59 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 18 Oct 2021 01:58:59 GMT Subject: RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException Message-ID: We can see AccessControlException in some JFR tests since [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). It is caused that SecurityException happens in both `File::canWrite` and `Path::toRealPath`. We should fall-through with empty path because the path will be evaluated when emergency dump happens. ------------- Commit messages: - 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException Changes: https://git.openjdk.java.net/jdk/pull/5984/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5984&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275375 Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5984.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5984/head:pull/5984 PR: https://git.openjdk.java.net/jdk/pull/5984 From egahlin at openjdk.java.net Mon Oct 18 02:49:54 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 18 Oct 2021 02:49:54 GMT Subject: RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 01:52:22 GMT, Yasumasa Suenaga wrote: > We can see AccessControlException in some JFR tests since [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). It is caused that SecurityException happens in both `File::canWrite` and `Path::toRealPath`. We should fall-through with empty path because the path will be evaluated when emergency dump happens. Why do you get a SecurityException? This doesn't happen with "JFR.start filename=...." and is ignoring the path (and logging) really the correct way to handle it? I would expect jcmd users to be informed (in their client) if there is a problem, similar to other incorrect options with JFR.configure. Logging in JVM process seems incorrect (and also the log tag set, JFR_DCMD seems more appropriate). ------------- PR: https://git.openjdk.java.net/jdk/pull/5984 From ysuenaga at openjdk.java.net Mon Oct 18 07:08:55 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 18 Oct 2021 07:08:55 GMT Subject: RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException In-Reply-To: References: Message-ID: <3mdL8QvTtPQFAFn7ymXDU4pIy0FxY_HsdFztw8VBuiA=.03992cef-60c6-4f8e-9353-877bcca315b0@github.com> On Mon, 18 Oct 2021 02:46:24 GMT, Erik Gahlin wrote: > Why do you get a SecurityException? > > This doesn't happen with "JFR.start filename=...." and is ignoring the path (and logging) really the correct way to handle it? We can see this error when SecurityManager is enabled (e.g. TestStreamingRemote.java). `Options::setDumpPath` calls both `File::canWrite` and `Path::toRealPath`, then they requires `("java.io.FilePermission" "." "write")` - `SecurityManager::checkWrite` performs correctly. In case of `filename` of JFR.start does not seem to check with same way. > I would expect jcmd users to be informed (in their client) if there is a problem, similar to other incorrect options with JFR.configure. Logging in JVM process seems incorrect (and also the log tag set, JFR_DCMD seems more appropriate). I can change log tag to JFR_DCMD, but it is difficult to propagate warnings to jcmd user because the problem can happen in out of jcmd like this case (remote recording). In addition, similar logs would happen in other places (e.g. `PlatformRecorder::destroy`). I think it would be better to fix in other JBS ticket if we should fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/5984 From egahlin at openjdk.java.net Mon Oct 18 07:59:49 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 18 Oct 2021 07:59:49 GMT Subject: RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException In-Reply-To: <3mdL8QvTtPQFAFn7ymXDU4pIy0FxY_HsdFztw8VBuiA=.03992cef-60c6-4f8e-9353-877bcca315b0@github.com> References: <3mdL8QvTtPQFAFn7ymXDU4pIy0FxY_HsdFztw8VBuiA=.03992cef-60c6-4f8e-9353-877bcca315b0@github.com> Message-ID: On Mon, 18 Oct 2021 07:05:26 GMT, Yasumasa Suenaga wrote: > > Why do you get a SecurityException? > > This doesn't happen with "JFR.start filename=...." and is ignoring the path (and logging) really the correct way to handle it? > > We can see this error when SecurityManager is enabled (e.g. TestStreamingRemote.java). `Options::setDumpPath` calls both `File::canWrite` and `Path::toRealPath`, then they requires `("java.io.FilePermission" "." "write")` - `SecurityManager::checkWrite` performs correctly. In case of `filename` of JFR.start does not seem to check with same way. > I looked at this more. The reason you get a SecurityException is because setDumpPath is set during initialization with DEFAULT_DUMP_PATH. when the JVM and Options class are initialized. It's not related to "JFR.configure dumppath=..." This means this will always happen when a security manager is in use and JFR is initialized. I don't think what you have is a proper solution. As I understand it, the reason you need to resolve the path in Java is because you can't just use the text (in user.home) as is (it will not work with native). Correct? I'm not sure we should use user.home at all. Shouldn't the default path be where the JVM process started? A more appropriate solution seems to be to get the path using SecuritySupport, either using an existing method or one you add as part of this fix. This will however slow down startup. Perhaps an even better solution is to let "null" be the process starting directory and let native handle it? No need to resolve it in Java during startup. Remove DEFAULT_USER_HOME in the SecuritySupport class. One problem with this approach is that Options.getDumpPath() needs to be updated to return the process start directory when it is null. This can perhaps be done using a call to native, or using SecuritySupport, so we don't get a SecurityException. This will only happen when jfr=debug is set, or somebody calls "JFR.configure". If you choose this approach, make sure it works in those scenarios. In general, always run tests in open/test/jdk/jdk/jfr before integrating a JFR fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/5984 From mgronlun at openjdk.java.net Mon Oct 18 08:29:46 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 08:29:46 GMT Subject: RFR: 8266936: Add a finalization JFR event [v19] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: relax memory ordering constraint ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/d10eb309..85a46263 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=17-18 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From ysuenaga at openjdk.java.net Mon Oct 18 11:27:53 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 18 Oct 2021 11:27:53 GMT Subject: RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException In-Reply-To: References: <3mdL8QvTtPQFAFn7ymXDU4pIy0FxY_HsdFztw8VBuiA=.03992cef-60c6-4f8e-9353-877bcca315b0@github.com> Message-ID: On Mon, 18 Oct 2021 07:57:15 GMT, Erik Gahlin wrote: > The reason you get a SecurityException is because setDumpPath is set during initialization with DEFAULT_DUMP_PATH. when the JVM and Options class are initialized. It's not related to "JFR.configure dumppath=..." I concern SecurityException would happen when "JFR.configure dumppath=..." with security manager because the exception says `access denied ("java.io.FilePermission" "." "write")` - it is caused by security constraint. > This means this will always happen when a security manager is in use and JFR is initialized. I don't think what you have is a proper solution. As I understand it, the reason you need to resolve the path in Java is because you can't just use the text (in user.home) as is (it will not work with native). Correct? This behavior is request by @mgronlun in https://github.com/openjdk/jdk/pull/5019#issuecomment-912619347 . We need to resolve the path `setDumpPath` to keep original behavior (before JDK-8271949). > I'm not sure we should use user.home at all. Shouldn't the default path be where the JVM process started? I think you mean current work directory ( `/proc/self/cwd` in Linux). It is not home directory. So I set `.` to `DEFAULT_DUMP_PATH` as default. (I removed `USER_HOME` from SecuritySupport in JDK-8271949) > A more appropriate solution seems to be to get the path using SecuritySupport, either using an existing method or one you add as part of this fix. This will however slow down startup. > > Perhaps an even better solution is to let "null" be the process starting directory and let native handle it? No need to resolve it in Java during startup. `null` might be a solution for default value, but we cannot resolve this problem when relative path is passed to `dumppath`. We need to resolve it at first, otherwise we will see SecurityException again. We can fix as you said if we can ignore original behavior (path resolution). ------------- PR: https://git.openjdk.java.net/jdk/pull/5984 From egahlin at openjdk.java.net Mon Oct 18 16:27:55 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 18 Oct 2021 16:27:55 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 15:23:35 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. >> >> We also like to assist users in replacing and mitigating uses in non-JDK code. >> >> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision: > > - localize > - cleanup > - FinalizerStatistics Marked as reviewed by egahlin (Reviewer). src/java.base/share/classes/java/lang/ref/Finalizer.java line 71: > 69: } > 70: > 71: extraneous whitespace? test/jdk/jdk/jfr/event/runtime/TestFinalizerStatisticsEvent.java line 98: > 96: case TEST_CLASS_NAME: { > 97: Asserts.assertTrue(event.getString("codeSource").startsWith("file://")); > 98: foundTestClassName = true; Could we (sanity) check "objects" and "totalFinalzersRun" fields as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:38:50 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:38:50 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 08:42:58 GMT, Erik Gahlin wrote: >> Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision: >> >> - localize >> - cleanup >> - FinalizerStatistics > > test/jdk/jdk/jfr/event/runtime/TestFinalizerStatisticsEvent.java line 98: > >> 96: case TEST_CLASS_NAME: { >> 97: Asserts.assertTrue(event.getString("codeSource").startsWith("file://")); >> 98: foundTestClassName = true; > > Could we (sanity) check "objects" and "totalFinalzersRun" fields as well? It's risky to do because of the non-deterministic nature of when the Finalizer thread runs (if at all). The best I could think of is to check if either field is 0 or more, but that becomes so weak it's not much of a sanity check. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:51:53 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:51:53 GMT Subject: RFR: 8266936: Add a finalization JFR event [v20] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: no constexpr for constant values ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/85a46263..b3268c90 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=18-19 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:51:54 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:51:54 GMT Subject: RFR: 8266936: Add a finalization JFR event [v12] In-Reply-To: References: <7qUo6JdWeitC5Tw90sAEdokNLL1B0cp7nU8pBRLFoOc=.9d912b5c-41f6-42cd-a393-85f46daad623@github.com> Message-ID: <_fUcg-t8JOZ8qDTmngQnSHCnofBQLQIbClMfd0V92i0=.67daf704-61cc-4b14-8a54-dd41da28482c@github.com> On Fri, 24 Sep 2021 22:31:18 GMT, Mandy Chung wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> no precompiled headers and mtServiceability nmt classification > > Hi Markus, > > It's a little surprised to see Finalizer.c to depend JMM interface which is used by `java.management` and `jdk.management` modules only. It's more appropriate for it to be a JVM_* entry point for Finalizer to report completion of the finalization instead. I understand that you want to make FinalizerService to be a conditional feature which is a good idea. Such JVM entry can be made as a nop if not INCLUDE_SERVICES. Thank you for staying around with this protracted PR. Thanks @mlchung , @coleenp and @egahlin for your reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:51:55 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:51:55 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 08:45:54 GMT, Erik Gahlin wrote: >> Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision: >> >> - localize >> - cleanup >> - FinalizerStatistics > > src/java.base/share/classes/java/lang/ref/Finalizer.java line 71: > >> 69: } >> 70: >> 71: > > extraneous whitespace? I think this version is outdated, and the extra whitespace was removed in later versions. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:55:56 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:55:56 GMT Subject: Integrated: 8266936: Add a finalization JFR event In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 19:47:26 GMT, Markus Gr?nlund wrote: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus This pull request has now been integrated. Changeset: 72a976ef Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/72a976ef05fc2c62657920a560a0abc60b27c852 Stats: 1917 lines in 36 files changed: 1375 ins; 409 del; 133 mod 8266936: Add a finalization JFR event Reviewed-by: coleenp, mchung, egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 17:38:59 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 17:38:59 GMT Subject: RFR: 8275415: Prepare Leak Profiler for Lilliput Message-ID: Greetings, Currently, the associated chain for a leak candidate (represented by the leak context edge) is stored as a pointer in the mark word. With Lilliput, this will not work. Providing another hashtable works fine to solve this problem, but the overhead might not fully warrant it. The default hashtable has 1009 buckets IIRC, but the number of leak candidates (samples) found during heap traversal might only be a relatively small number (default queue size is 256). A solution is to still use space available in the mark word, since we have already provisioned to use this as a "scratch area" as part of setup. It is now limited to accommodate the anticipated changes under the Lilliput project (i.e. restricted to use only the lower 32-bits only) and instead of storing a pointer to the leak context edge, we store an index into an array. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - Prepare Leak Profiler for Lilliput Changes: https://git.openjdk.java.net/jdk/pull/5992/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5992&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275415 Stats: 105 lines in 3 files changed: 75 ins; 23 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5992.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5992/head:pull/5992 PR: https://git.openjdk.java.net/jdk/pull/5992 From dcubed at openjdk.java.net Mon Oct 18 18:06:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 18 Oct 2021 18:06:09 GMT Subject: RFR: JDK-8275436 [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect Message-ID: This reverts commit 31500692d1503cb73249e0425e6930aaaa49258a. ------------- Commit messages: - JDK-8275436 [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect Changes: https://git.openjdk.java.net/jdk/pull/5994/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5994&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275436 Stats: 170 lines in 10 files changed: 3 ins; 138 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/5994.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5994/head:pull/5994 PR: https://git.openjdk.java.net/jdk/pull/5994 From dcubed at openjdk.java.net Mon Oct 18 18:07:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 18 Oct 2021 18:07:56 GMT Subject: RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 01:52:22 GMT, Yasumasa Suenaga wrote: > We can see AccessControlException in some JFR tests since [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). It is caused that SecurityException happens in both `File::canWrite` and `Path::toRealPath`. We should fall-through with empty path because the path will be evaluated when emergency dump happens. It looks to me like this issue will take a bit of time to resolve so I've created this PR: JDK-8275436 [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect https://github.com/openjdk/jdk/pull/5994 for doing a [BACKOUT] of the fix that caused these failures. ------------- PR: https://git.openjdk.java.net/jdk/pull/5984 From mgronlun at openjdk.java.net Mon Oct 18 18:19:01 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 18:19:01 GMT Subject: RFR: JDK-8275436 [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 17:58:25 GMT, Daniel D. Daugherty wrote: > This reverts commit 31500692d1503cb73249e0425e6930aaaa49258a. Thanks for creating the backout Dan, looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5994 From dcubed at openjdk.java.net Mon Oct 18 18:19:02 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 18 Oct 2021 18:19:02 GMT Subject: RFR: JDK-8275436 [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 18:14:16 GMT, Markus Gr?nlund wrote: >> This reverts commit 31500692d1503cb73249e0425e6930aaaa49258a. > > Thanks for creating the backout Dan, looks good. @mgronlun - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/5994 From dcubed at openjdk.java.net Mon Oct 18 18:28:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 18 Oct 2021 18:28:56 GMT Subject: Integrated: JDK-8275436 [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 17:58:25 GMT, Daniel D. Daugherty wrote: > This reverts commit 31500692d1503cb73249e0425e6930aaaa49258a. This pull request has now been integrated. Changeset: a03119ce Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/a03119ce1a34642565c669bd2471f52eec088b96 Stats: 170 lines in 10 files changed: 3 ins; 138 del; 29 mod 8275436: [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/5994 From rkennke at openjdk.java.net Mon Oct 18 18:29:59 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 18 Oct 2021 18:29:59 GMT Subject: RFR: 8275415: Prepare Leak Profiler for Lilliput In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 17:31:13 GMT, Markus Gr?nlund wrote: > Greetings, > > Currently, the associated chain for a leak candidate (represented by the leak context edge) is stored as a pointer in the mark word. With Lilliput, this will not work. > > Providing another hashtable works fine to solve this problem, but the overhead might not fully warrant it. The default hashtable has 1009 buckets IIRC, but the number of leak candidates (samples) found during heap traversal might only be a relatively small number (default queue size is 256). > > A solution is to still use space available in the mark word, since we have already provisioned to use this as a "scratch area" as part of setup. It is now limited to accommodate the anticipated changes under the Lilliput project (i.e. restricted to only use the lower 32-bits) and instead of storing a pointer to the leak context edge, we store an index into an array. > > Testing: jdk_jfr > > Thanks > Markus The change looks good to me, and I can confirm that it works as intended in the context of Lilliput. Thank you! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5992 From dcubed at openjdk.java.net Mon Oct 18 18:40:58 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 18 Oct 2021 18:40:58 GMT Subject: RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 01:52:22 GMT, Yasumasa Suenaga wrote: > We can see AccessControlException in some JFR tests since [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). It is caused that SecurityException happens in both `File::canWrite` and `Path::toRealPath`. We should fall-through with empty path because the path will be evaluated when emergency dump happens. I've changed JDK-8275375 into the [REDO] bug for JDK-8271949 so this PR will need to have its title updated to match the revised bug. I usually do this with "/issue JDK-8275375". Or this PR can be closed and a new PR opened with the original changes from JDK-8271949 along with the fix for the test failures. In any case, I would like to see this [REDO] run thru Mach5 testing prior to integration. Please coordinate this testing with someone from Oracle. ------------- PR: https://git.openjdk.java.net/jdk/pull/5984 From egahlin at openjdk.java.net Mon Oct 18 18:48:49 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 18 Oct 2021 18:48:49 GMT Subject: RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 01:52:22 GMT, Yasumasa Suenaga wrote: > We can see AccessControlException in some JFR tests since [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). It is caused that SecurityException happens in both `File::canWrite` and `Path::toRealPath`. We should fall-through with empty path because the path will be evaluated when emergency dump happens. Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5984 From egahlin at openjdk.java.net Mon Oct 18 18:53:53 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 18 Oct 2021 18:53:53 GMT Subject: RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 01:52:22 GMT, Yasumasa Suenaga wrote: > We can see AccessControlException in some JFR tests since [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). It is caused that SecurityException happens in both `File::canWrite` and `Path::toRealPath`. We should fall-through with empty path because the path will be evaluated when emergency dump happens. Sorry, I meant to review the backout. ------------- PR: https://git.openjdk.java.net/jdk/pull/5984 From egahlin at openjdk.java.net Mon Oct 18 18:53:54 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 18 Oct 2021 18:53:54 GMT Subject: RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException In-Reply-To: References: <3mdL8QvTtPQFAFn7ymXDU4pIy0FxY_HsdFztw8VBuiA=.03992cef-60c6-4f8e-9353-877bcca315b0@github.com> Message-ID: On Mon, 18 Oct 2021 11:24:57 GMT, Yasumasa Suenaga wrote: > `null` might be a solution for default value, but we cannot resolve this problem when relative path is passed to `dumppath`. We need to resolve it at first, otherwise we will see SecurityException again. If you pass in a value, it's OK to resolve, but use SecuritySupport (to avoid security checks) ------------- PR: https://git.openjdk.java.net/jdk/pull/5984 From ysuenaga at openjdk.java.net Tue Oct 19 02:18:56 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 19 Oct 2021 02:18:56 GMT Subject: RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 18:38:25 GMT, Daniel D. Daugherty wrote: >> We can see AccessControlException in some JFR tests since [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). It is caused that SecurityException happens in both `File::canWrite` and `Path::toRealPath`. We should fall-through with empty path because the path will be evaluated when emergency dump happens. > > Or this PR can be closed and a new PR opened with the original changes > from JDK-8271949 along with the fix for the test failures. In any case, I > would like to see this [REDO] run thru Mach5 testing prior to integration. > Please coordinate this testing with someone from Oracle. @dcubed-ojdk I've sent PR for redo process as #6000 , so I close this PR. @egahlin @mgronlun Can you take a look #6000 ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5984 From ysuenaga at openjdk.java.net Tue Oct 19 02:18:56 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 19 Oct 2021 02:18:56 GMT Subject: Withdrawn: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 01:52:22 GMT, Yasumasa Suenaga wrote: > We can see AccessControlException in some JFR tests since [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). It is caused that SecurityException happens in both `File::canWrite` and `Path::toRealPath`. We should fall-through with empty path because the path will be evaluated when emergency dump happens. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5984 From ysuenaga at openjdk.java.net Tue Oct 19 02:21:00 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 19 Oct 2021 02:21:00 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect Message-ID: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> This PR is for redo-ing [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). I changed to use `SecuritySupport` at `Options::setDumpPath` as @egahlin mentioned. Please see change both Options.java and SecuritySupport.java . I've tested this change with all jdk/jfr tests on Linux x64, and they works fine. @egahlin @mgronlun Can you run Mach5 tests with this change? ------------- Commit messages: - 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect Changes: https://git.openjdk.java.net/jdk/pull/6000/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6000&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275375 Stats: 173 lines in 10 files changed: 139 ins; 3 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/6000.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6000/head:pull/6000 PR: https://git.openjdk.java.net/jdk/pull/6000 From egahlin at openjdk.java.net Tue Oct 19 02:43:46 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 19 Oct 2021 02:43:46 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> Message-ID: On Tue, 19 Oct 2021 02:13:01 GMT, Yasumasa Suenaga wrote: > This PR is for redo-ing [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). > I changed to use `SecuritySupport` at `Options::setDumpPath` as @egahlin mentioned. Please see change both Options.java and SecuritySupport.java . > > I've tested this change with all jdk/jfr tests on Linux x64, and they works fine. > @egahlin @mgronlun Can you run Mach5 tests with this change? There are three ways setDumpPath is used: 1) When JFR is initialized 2) jcmd JFR.configure dumppath= 3) -XX:FllightRecorderOptions:dumppath= If something goes wrong (IOException/InvalidPathException) when doing 2 or 3, users should ideally be informed, so they can correct it, at command-line or jcmd. Perhaps throw DCmdException? Do we really need to resolve for 1? Can we handle it in native, similar to what we already do with hs_err_pid (which is not resolved in Java). For example, null could be used to indicate that the working directory should be used. I think we first need to nail the design, before doing the implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From ysuenaga at openjdk.java.net Tue Oct 19 03:15:48 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 19 Oct 2021 03:15:48 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> Message-ID: <30M8W1CHMsik0YQvt7xnynuf_eW5xqcU-h4a61I90sg=.341910e4-4168-44d4-93d4-24b047773379@github.com> On Tue, 19 Oct 2021 02:13:01 GMT, Yasumasa Suenaga wrote: > This PR is for redo-ing [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). > I changed to use `SecuritySupport` at `Options::setDumpPath` as @egahlin mentioned. Please see change both Options.java and SecuritySupport.java . > > I've tested this change with all jdk/jfr tests on Linux x64, and they works fine. > @egahlin @mgronlun Can you run Mach5 tests with this change? > There are three ways setDumpPath is used: > > 1. When JFR is initialized > 2. jcmd JFR.configure dumppath= > 3. -XX:FllightRecorderOptions:dumppath= > > If something goes wrong (IOException/InvalidPathException) when doing 2 or 3, users should ideally be informed, so they can correct it, at command-line or jcmd. Perhaps throw DCmdException? Agree, we can use DCmdException if IOE happens. However we need to concider 1 because some processes might be run on "/" with unprivileged user. > Do we really need to resolve for 1? Can we handle it in native, similar to what we already do with hs_err_pid (which is not resolved in Java). For example, null could be used to indicate that the working directory should be used. In hs_err log, the path would not resolved, it uses `os::get_current_directory()` at `VMError::prepare_log_file()` when -XX:ErrorFile is not set. For example, we can see following message on the console when we set -XX:ErrorFile=error.log, and error.log is located at current directory. # An error report file with more information is saved as: # error.log I'm not particular path resolution if we can ignore original behavior (resolved dump path will also be shown at UL). We will not have to think about SecurityException if we don't need to resolve dump path at `setDumpPath()`. In addition we can implement it more simple. So I agree with you to be honest that to pass `null`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From egahlin at openjdk.java.net Tue Oct 19 03:45:51 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 19 Oct 2021 03:45:51 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: <30M8W1CHMsik0YQvt7xnynuf_eW5xqcU-h4a61I90sg=.341910e4-4168-44d4-93d4-24b047773379@github.com> References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> <30M8W1CHMsik0YQvt7xnynuf_eW5xqcU-h4a61I90sg=.341910e4-4168-44d4-93d4-24b047773379@github.com> Message-ID: On Tue, 19 Oct 2021 03:12:32 GMT, Yasumasa Suenaga wrote: > > There are three ways setDumpPath is used: > > > > 1. When JFR is initialized > > 2. jcmd JFR.configure dumppath= > > 3. -XX:FllightRecorderOptions:dumppath= > > > > If something goes wrong (IOException/InvalidPathException) when doing 2 or 3, users should ideally be informed, so they can correct it, at command-line or jcmd. Perhaps throw DCmdException? > > Agree, we can use DCmdException if IOE happens. However we need to concider 1 because some processes might be run on "/" with unprivileged user. > > > Do we really need to resolve for 1? Can we handle it in native, similar to what we already do with hs_err_pid (which is not resolved in Java). For example, null could be used to indicate that the working directory should be used. > > In hs_err log, the path would not resolved, it uses `os::get_current_directory()` at `VMError::prepare_log_file()` when -XX:ErrorFile is not set. For example, we can see following message on the console when we set -XX:ErrorFile=error.log, and error.log is located at current directory. > > ``` > # An error report file with more information is saved as: > # error.log > ``` > > I'm not particular path resolution if we can ignore original behavior (resolved dump path will also be shown at UL). We will not have to think about SecurityException if we don't need to resolve dump path at `setDumpPath()`. In addition we can implement it more simple. So I agree with you to be honest that to pass `null`. I'm not sure I follow completely, but how about this: 1) Remove setDumpPath(DEFAULT_DUMP_PATH) in Options::reset(). If no path has been set, os::get_current_directory() will be used when doing an emergency dump. 2) Use the SecuritySupport::canWrite check, but instead of logging, let setDumpPath throw IOException. 3) Catch IOException in DCmdConfigure and throw DCmdExceotion, similar to what is done with repository path Would that work? ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From ysuenaga at openjdk.java.net Tue Oct 19 07:02:11 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 19 Oct 2021 07:02:11 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect [v2] In-Reply-To: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> Message-ID: > This PR is for redo-ing [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). > I changed to use `SecuritySupport` at `Options::setDumpPath` as @egahlin mentioned. Please see change both Options.java and SecuritySupport.java . > > I've tested this change with all jdk/jfr tests on Linux x64, and they works fine. > @egahlin @mgronlun Can you run Mach5 tests with this change? Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Refactoring setDumpPath related code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6000/files - new: https://git.openjdk.java.net/jdk/pull/6000/files/a3f67961..77a48a11 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6000&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6000&range=00-01 Stats: 33 lines in 5 files changed: 11 ins; 9 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/6000.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6000/head:pull/6000 PR: https://git.openjdk.java.net/jdk/pull/6000 From ysuenaga at openjdk.java.net Tue Oct 19 07:10:48 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 19 Oct 2021 07:10:48 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> <30M8W1CHMsik0YQvt7xnynuf_eW5xqcU-h4a61I90sg=.341910e4-4168-44d4-93d4-24b047773379@github.com> Message-ID: On Tue, 19 Oct 2021 03:43:01 GMT, Erik Gahlin wrote: >>> There are three ways setDumpPath is used: >>> >>> 1. When JFR is initialized >>> 2. jcmd JFR.configure dumppath= >>> 3. -XX:FllightRecorderOptions:dumppath= >>> >>> If something goes wrong (IOException/InvalidPathException) when doing 2 or 3, users should ideally be informed, so they can correct it, at command-line or jcmd. Perhaps throw DCmdException? >> >> Agree, we can use DCmdException if IOE happens. However we need to concider 1 because some processes might be run on "/" with unprivileged user. >> >>> Do we really need to resolve for 1? Can we handle it in native, similar to what we already do with hs_err_pid (which is not resolved in Java). For example, null could be used to indicate that the working directory should be used. >> >> In hs_err log, the path would not resolved, it uses `os::get_current_directory()` at `VMError::prepare_log_file()` when -XX:ErrorFile is not set. For example, we can see following message on the console when we set -XX:ErrorFile=error.log, and error.log is located at current directory. >> >> >> # An error report file with more information is saved as: >> # error.log >> >> >> I'm not particular path resolution if we can ignore original behavior (resolved dump path will also be shown at UL). We will not have to think about SecurityException if we don't need to resolve dump path at `setDumpPath()`. In addition we can implement it more simple. So I agree with you to be honest that to pass `null`. > >> > There are three ways setDumpPath is used: >> > >> > 1. When JFR is initialized >> > 2. jcmd JFR.configure dumppath= >> > 3. -XX:FllightRecorderOptions:dumppath= >> > >> > If something goes wrong (IOException/InvalidPathException) when doing 2 or 3, users should ideally be informed, so they can correct it, at command-line or jcmd. Perhaps throw DCmdException? >> >> Agree, we can use DCmdException if IOE happens. However we need to concider 1 because some processes might be run on "/" with unprivileged user. >> >> > Do we really need to resolve for 1? Can we handle it in native, similar to what we already do with hs_err_pid (which is not resolved in Java). For example, null could be used to indicate that the working directory should be used. >> >> In hs_err log, the path would not resolved, it uses `os::get_current_directory()` at `VMError::prepare_log_file()` when -XX:ErrorFile is not set. For example, we can see following message on the console when we set -XX:ErrorFile=error.log, and error.log is located at current directory. >> >> ``` >> # An error report file with more information is saved as: >> # error.log >> ``` >> >> I'm not particular path resolution if we can ignore original behavior (resolved dump path will also be shown at UL). We will not have to think about SecurityException if we don't need to resolve dump path at `setDumpPath()`. In addition we can implement it more simple. So I agree with you to be honest that to pass `null`. > > I'm not sure I follow completely, but how about this: > > 1) Remove setDumpPath(DEFAULT_DUMP_PATH) in Options::reset(). If no path has been set, os::get_current_directory() will be used when doing an emergency dump. > 2) Use the SecuritySupport::canWrite check, but instead of logging, let setDumpPath throw IOException. > 3) Catch IOException in DCmdConfigure and throw DCmdExceotion, similar to what is done with repository path > > Would that work? @egahlin Thanks for your comment! > 1. Remove setDumpPath(DEFAULT_DUMP_PATH) in Options::reset(). If no path has been set, os::get_current_directory() will be used when doing an emergency dump. `Options::getDumpPath()` would be called at `FlightRecorder::getFlightRecorder` to log the configuration. So we need to replace `null` to current working directory. My new change will do so. > 2. Use the SecuritySupport::canWrite check, but instead of logging, let setDumpPath throw IOException. I use `SecuritySupport::isWritable` because `SecuritySupport` does not have `canWrite` and we can use `isWritable` for this purpose. We will throw IllegalArgumentException when IOException happens because IOE is check exception. > 3. Catch IOException in DCmdConfigure and throw DCmdExceotion, similar to what is done with repository path DCmdConfigure would throw DCmdException when it catches IAE because I don't want to change method declaration (`setDumpPath()`). New commit works expectedly, and it passed all jdk/jfr tests on Linux x64. ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From mgronlun at openjdk.java.net Tue Oct 19 10:05:15 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Oct 2021 10:05:15 GMT Subject: RFR: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" [v2] In-Reply-To: References: Message-ID: > Greetings, > > This fixes the issue seen in testing when accessing an oop as part of unloading (introduced with [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)). > > Instead, oop accesses will be done outside of unloading and the result, i.e the codesource attribute, will be cached and reused in the FinalizerEntry. > > Testing: in progress > > Thanks > Markus > > PS one effect of this is that classes that unload before they have allocated anything will not have a codesource attribute. This can be fixed by letting classes register with the table as part of class loading, instead of during allocation. I will follow-up with a separate change for that. Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: header ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6001/files - new: https://git.openjdk.java.net/jdk/pull/6001/files/a5de3988..7b17ff5f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6001&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6001&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6001/head:pull/6001 PR: https://git.openjdk.java.net/jdk/pull/6001 From egahlin at openjdk.java.net Tue Oct 19 12:00:53 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 19 Oct 2021 12:00:53 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> <30M8W1CHMsik0YQvt7xnynuf_eW5xqcU-h4a61I90sg=.341910e4-4168-44d4-93d4-24b047773379@github.com> Message-ID: On Tue, 19 Oct 2021 07:07:24 GMT, Yasumasa Suenaga wrote: > I use `SecuritySupport::isWritable` because `SecuritySupport` does not have `canWrite` and we can use `isWritable` for this purpose. OK > We will throw IllegalArgumentException when IOException happens because IOE is check exception. > DCmdConfigure would throw DCmdException when it catches IAE because I don't want to change method declaration (`setDumpPath()`). > Why not? It's better to throw a checked exception so any call to it, now or in the future, will have to deal with IO issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From egahlin at openjdk.java.net Tue Oct 19 12:22:56 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 19 Oct 2021 12:22:56 GMT Subject: RFR: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" [v2] In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 10:05:15 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> This fixes the issue seen in testing when accessing an oop as part of unloading (introduced with [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)). >> >> Instead, oop accesses will be done outside of unloading and the result, i.e the codesource attribute, will be cached and reused in the FinalizerEntry. >> >> Testing: tier1-3, jdk_jfr >> >> Thanks >> Markus >> >> PS one effect of this is that classes that unload before they have allocated anything will not have a codesource attribute. This can be fixed by letting classes register with the table as part of class loading, instead of during allocation. I will follow-up with a separate change for that. > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > header Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6001 From marcus at hirt.se Tue Oct 19 12:42:00 2021 From: marcus at hirt.se (Marcus Hirt) Date: Tue, 19 Oct 2021 14:42:00 +0200 Subject: OpenJDK Serviceability Meetup Message-ID: <078301d7c4e6$b5c6dd30$21549790$@hirt.se> Hi all, I am trying to put together a two-day OpenJDK Serviceability Meetup in Stockholm. We will be discussing JFR, JMC, JVMTI and whatever else the participants believe would be interesting to discuss. Date: 2-3 December 2021 Location: AtSix (https://hotelatsix.com/) We only have 12 spots, and 9 are currently taken. Please let me know if you would like to attend. Kind regards, Marcus From coleenp at openjdk.java.net Tue Oct 19 12:44:50 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 19 Oct 2021 12:44:50 GMT Subject: RFR: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" [v2] In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 10:05:15 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> This fixes the issue seen in testing when accessing an oop as part of unloading (introduced with [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)). >> >> Instead, oop accesses will be done outside of unloading and the result, i.e the codesource attribute, will be cached and reused in the FinalizerEntry. >> >> Testing: tier1-3, jdk_jfr >> >> Thanks >> Markus >> >> PS one effect of this is that classes that unload before they have allocated anything will not have a codesource attribute. This can be fixed by letting classes register with the table as part of class loading, instead of during allocation. I will follow-up with a separate change for that. > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > header Looks good Markus. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6001 From mgronlun at openjdk.java.net Tue Oct 19 12:53:51 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Oct 2021 12:53:51 GMT Subject: RFR: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" [v2] In-Reply-To: References: Message-ID: <4TQA0uU_CuXYg8_37BgSE4ltrZ_PjkYKVG5RAR8L2w8=.b7b0028c-437b-4134-bc2e-1d1a81d6adc2@github.com> On Tue, 19 Oct 2021 12:19:24 GMT, Erik Gahlin wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> header > > Marked as reviewed by egahlin (Reviewer). Thanks, @egahlin and @coleenp, for your quick reviews. I will proceed to integrate this to restore testing in the CI. ------------- PR: https://git.openjdk.java.net/jdk/pull/6001 From mgronlun at openjdk.java.net Tue Oct 19 13:03:57 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Oct 2021 13:03:57 GMT Subject: Integrated: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" In-Reply-To: References: Message-ID: <6tkPfLd6OEyTujY4e03WWYA6RmCFUynq9Rfp7Sd69Vg=.90d78563-e326-48bd-8203-c9c961e0907f@github.com> On Tue, 19 Oct 2021 09:39:06 GMT, Markus Gr?nlund wrote: > Greetings, > > This fixes the issue seen in testing when accessing an oop as part of unloading (introduced with [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)). > > Instead, oop accesses will be done outside of unloading and the result, i.e the codesource attribute, will be cached and reused in the FinalizerEntry. > > Testing: tier1-3, jdk_jfr > > Thanks > Markus > > PS one effect of this is that classes that unload before they have allocated anything will not have a codesource attribute. This can be fixed by letting classes register with the table as part of class loading, instead of during allocation. I will follow-up with a separate change for that. This pull request has now been integrated. Changeset: 98ab4b03 Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/98ab4b03b311dcd8374cbbb21a898298798750d6 Stats: 109 lines in 4 files changed: 64 ins; 44 del; 1 mod 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" Reviewed-by: egahlin, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/6001 From mgronlun at openjdk.java.net Tue Oct 19 16:24:12 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Oct 2021 16:24:12 GMT Subject: Integrated: 8275517: Off-by-one error in allocation Message-ID: Greetings (again), The quick fix for [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an off-by-one error as part of the allocation. :-( Sorry for this inconvenience. Markus ------------- Commit messages: - Off-by-one error in allocation Changes: https://git.openjdk.java.net/jdk/pull/6018/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6018&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275517 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6018.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6018/head:pull/6018 PR: https://git.openjdk.java.net/jdk/pull/6018 From tschatzl at openjdk.java.net Tue Oct 19 16:24:13 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 16:24:13 GMT Subject: Integrated: 8275517: Off-by-one error in allocation In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 15:31:39 GMT, Markus Gr?nlund wrote: > Greetings (again), > > The quick fix for [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an off-by-one error as part of the allocation. :-( > > Sorry for this inconvenience. > > Markus Lgtm. Fingers crossed that this fixes the issues in CI. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6018 From mgronlun at openjdk.java.net Tue Oct 19 16:24:13 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Oct 2021 16:24:13 GMT Subject: Integrated: 8275517: Off-by-one error in allocation In-Reply-To: References: Message-ID: <5TmbJhfbi201gbA3Ap-SRVxaP5MrCFpUaRhTZsI1DO8=.053527b9-dde1-411e-9699-8a0bf0a23fca@github.com> On Tue, 19 Oct 2021 15:34:13 GMT, Thomas Schatzl wrote: >> Greetings (again), >> >> The quick fix for [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an off-by-one error as part of the allocation. :-( >> >> Sorry for this inconvenience. >> >> Markus > > Lgtm. Fingers crossed that this fixes the issues in CI. Thanks @tschatzl for bringing this to attention, apologies for the inconvenience. ------------- PR: https://git.openjdk.java.net/jdk/pull/6018 From mgronlun at openjdk.java.net Tue Oct 19 16:24:13 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Oct 2021 16:24:13 GMT Subject: Integrated: 8275517: Off-by-one error in allocation In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 15:31:39 GMT, Markus Gr?nlund wrote: > Greetings (again), > > The quick fix for [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an off-by-one error as part of the allocation. :-( > > Sorry for this inconvenience. > > Markus This pull request has now been integrated. Changeset: 99bf7dd8 Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/99bf7dd8ddac1b5870534af50c97bec554004248 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod 8275517: Off-by-one error in allocation Reviewed-by: tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/6018 From ysuenaga at openjdk.java.net Wed Oct 20 00:13:38 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 20 Oct 2021 00:13:38 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect [v3] In-Reply-To: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> Message-ID: > This PR is for redo-ing [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). > I changed to use `SecuritySupport` at `Options::setDumpPath` as @egahlin mentioned. Please see change both Options.java and SecuritySupport.java . > > I've tested this change with all jdk/jfr tests on Linux x64, and they works fine. > @egahlin @mgronlun Can you run Mach5 tests with this change? Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Propagate IOException at setDumpPath() to the caller ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6000/files - new: https://git.openjdk.java.net/jdk/pull/6000/files/77a48a11..9e11ae4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6000&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6000&range=01-02 Stats: 17 lines in 2 files changed: 4 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/6000.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6000/head:pull/6000 PR: https://git.openjdk.java.net/jdk/pull/6000 From ysuenaga at openjdk.java.net Wed Oct 20 00:19:08 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 20 Oct 2021 00:19:08 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> <30M8W1CHMsik0YQvt7xnynuf_eW5xqcU-h4a61I90sg=.341910e4-4168-44d4-93d4-24b047773379@github.com> Message-ID: On Tue, 19 Oct 2021 11:57:51 GMT, Erik Gahlin wrote: > Why not? It's better to throw a checked exception so any call to it, now or in the future, will have to deal with IO issues. I thought it would be betteer if we don't change `setDumpPath()` decralation if possible. Ok, I added `throws IOException` to it in new commit. I added try-catch statement around `setDumpPath(DEFAULT_DUMP_PATH)` as a result. You suggested to remove this, but I think it is better to leave because it is in `reset()`. This method does not have Javadoc, but it is nature that the developer guesses all of parameters in `Options` would be reset after this call. `dumppath` should be included of course. ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From egahlin at openjdk.java.net Wed Oct 20 00:41:07 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 20 Oct 2021 00:41:07 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> <30M8W1CHMsik0YQvt7xnynuf_eW5xqcU-h4a61I90sg=.341910e4-4168-44d4-93d4-24b047773379@github.com> Message-ID: On Wed, 20 Oct 2021 00:16:18 GMT, Yasumasa Suenaga wrote: > > Why not? It's better to throw a checked exception so any call to it, now or in the future, will have to deal with IO issues. > > I thought it would be betteer if we don't change `setDumpPath()` decralation if possible. Ok, I added `throws IOException` to it in new commit. I added try-catch statement around `setDumpPath(DEFAULT_DUMP_PATH)` as a result. You suggested to remove this, but I think it is better to leave because it is in `reset()`. This method does not have Javadoc, but it is nature that the developer guesses all of parameters in `Options` would be reset after this call. `dumppath` should be included of course. The reset() method is legacy and the contents could move into the static initializer (and setDumpPath() be removed), but it's outside the scope of this enhancement, so I'm fine with what you have. I will try it out on other platforms in the next few days and get back to you with the final review. ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From ysuenaga at openjdk.java.net Wed Oct 20 01:21:07 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 20 Oct 2021 01:21:07 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> <30M8W1CHMsik0YQvt7xnynuf_eW5xqcU-h4a61I90sg=.341910e4-4168-44d4-93d4-24b047773379@github.com> Message-ID: On Wed, 20 Oct 2021 00:37:38 GMT, Erik Gahlin wrote: > The reset() method is legacy and the contents could move into the static initializer (and setDumpPath() be removed), but it's outside the scope of this enhancement, so I'm fine with what you have. Ok. > I will try it out on other platforms in the next few days and get back to you with the final review. Thanks! I'm looking forward to your feedback! ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From mgronlun at openjdk.java.net Thu Oct 21 10:16:07 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 21 Oct 2021 10:16:07 GMT Subject: Integrated: 8275415: Prepare Leak Profiler for Lilliput In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 17:31:13 GMT, Markus Gr?nlund wrote: > Greetings, > > Currently, the associated chain for a leak candidate (represented by the leak context edge) is stored as a pointer in the mark word. With Lilliput, this will not work. > > Providing another hashtable works fine to solve this problem, but the overhead might not fully warrant it. The default hashtable has 1009 buckets IIRC, but the number of leak candidates (samples) found during heap traversal might only be a relatively small number (default queue size is 256). > > A solution is to still use space available in the mark word, since we have already provisioned to use this as a "scratch area" as part of setup. It is now limited to accommodate the anticipated changes under the Lilliput project (i.e. restricted to only use the lower 32-bits) and instead of storing a pointer to the leak context edge, we store an index into an array. > > Testing: jdk_jfr > > Thanks > Markus This pull request has now been integrated. Changeset: c41ce6d1 Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/c41ce6d159e59a8c05dbeacde2d2612b58733d46 Stats: 105 lines in 3 files changed: 75 ins; 23 del; 7 mod 8275415: Prepare Leak Profiler for Lilliput Reviewed-by: rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/5992 From zgu at openjdk.java.net Thu Oct 21 17:23:18 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 21 Oct 2021 17:23:18 GMT Subject: RFR: 8275730: Relax memory constraint on MultiThreadedRefCounter Message-ID: It is just an atomic counter, only needs atomic guarantee. ------------- Commit messages: - v0 Changes: https://git.openjdk.java.net/jdk/pull/6069/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6069&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275730 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6069.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6069/head:pull/6069 PR: https://git.openjdk.java.net/jdk/pull/6069 From mgronlun at openjdk.java.net Thu Oct 21 18:51:06 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 21 Oct 2021 18:51:06 GMT Subject: RFR: 8275730: Relax memory constraint on MultiThreadedRefCounter In-Reply-To: References: Message-ID: <23xWeqQ3t6P15dfCe2xecbunvEBZ_5bmANVY8aD8hRE=.7213b9b6-0946-4afd-9ca3-76f6b6e1be5e@github.com> On Thu, 21 Oct 2021 17:08:45 GMT, Zhengyu Gu wrote: > It is just an atomic counter, only needs atomic guarantee. Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6069 From zgu at openjdk.java.net Thu Oct 21 19:00:00 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 21 Oct 2021 19:00:00 GMT Subject: RFR: 8275730: Relax memory constraint on MultiThreadedRefCounter In-Reply-To: <23xWeqQ3t6P15dfCe2xecbunvEBZ_5bmANVY8aD8hRE=.7213b9b6-0946-4afd-9ca3-76f6b6e1be5e@github.com> References: <23xWeqQ3t6P15dfCe2xecbunvEBZ_5bmANVY8aD8hRE=.7213b9b6-0946-4afd-9ca3-76f6b6e1be5e@github.com> Message-ID: On Thu, 21 Oct 2021 18:47:48 GMT, Markus Gr?nlund wrote: >> It is just an atomic counter, only needs atomic guarantee. > > Looks good. Thanks for the review, @mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/6069 From egahlin at openjdk.java.net Mon Oct 25 16:53:08 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 25 Oct 2021 16:53:08 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect [v3] In-Reply-To: References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> Message-ID: On Wed, 20 Oct 2021 00:13:38 GMT, Yasumasa Suenaga wrote: >> This PR is for redo-ing [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). >> I changed to use `SecuritySupport` at `Options::setDumpPath` as @egahlin mentioned. Please see change both Options.java and SecuritySupport.java . >> >> I've tested this change with all jdk/jfr tests on Linux x64, and they works fine. >> @egahlin @mgronlun Can you run Mach5 tests with this change? > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Propagate IOException at setDumpPath() to the caller When I run "java -XX:FlightRecorderOptions:dumppath=incorrect" there seems to be a missing line break between "Cannot write JFR emergency dump to koko" and "Error occurred during initialization of VM" When I try "$ jcmd JFR.configure" I see "Repository path: N/A", which is perhaps OK. Then I run "jcmd JFR.configure dumppath=/directory/somewhere" and it prints "Dump path: /directory/somewhere", but when I run JFR.configure again, it still prints "Repository path: N/A" ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From ysuenaga at openjdk.java.net Tue Oct 26 05:22:42 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 26 Oct 2021 05:22:42 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect [v4] In-Reply-To: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> Message-ID: > This PR is for redo-ing [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). > I changed to use `SecuritySupport` at `Options::setDumpPath` as @egahlin mentioned. Please see change both Options.java and SecuritySupport.java . > > I've tested this change with all jdk/jfr tests on Linux x64, and they works fine. > @egahlin @mgronlun Can you run Mach5 tests with this change? Yasumasa Suenaga 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 six additional commits since the last revision: - Add dumppath to JFR.configure dcmd - Add "\n" after printing exception - Merge remote-tracking branch 'upstream/master' into JDK-8275375-2 - Propagate IOException at setDumpPath() to the caller - Refactoring setDumpPath related code - 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6000/files - new: https://git.openjdk.java.net/jdk/pull/6000/files/9e11ae4e..42633f22 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6000&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6000&range=02-03 Stats: 17680 lines in 375 files changed: 14813 ins; 1866 del; 1001 mod Patch: https://git.openjdk.java.net/jdk/pull/6000.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6000/head:pull/6000 PR: https://git.openjdk.java.net/jdk/pull/6000 From ysuenaga at openjdk.java.net Tue Oct 26 05:29:09 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 26 Oct 2021 05:29:09 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect [v3] In-Reply-To: References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> Message-ID: On Mon, 25 Oct 2021 16:50:12 GMT, Erik Gahlin wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Propagate IOException at setDumpPath() to the caller > > When I run "java -XX:FlightRecorderOptions:dumppath=incorrect" there seems to be a missing line break between "Cannot write JFR emergency dump to incorrect" and "Error occurred during initialization of VM" > > When I try "$ jcmd JFR.configure" I see "Repository path: N/A", which is perhaps OK. Then I run "jcmd JFR.configure dumppath=/directory/somewhere" and it prints "Dump path: /directory/somewhere", but when I run JFR.configure again, it still prints "Repository path: N/A" > > Tests passes. @egahlin Thanks for your report ! I pushed several commits, and they work fine with jdk/jfr tests on my Linux x64. > When I run "java -XX:FlightRecorderOptions:dumppath=incorrect" there seems to be a missing line break between "Cannot write JFR emergency dump to incorrect" and "Error occurred during initialization of VM" I fixed it in https://github.com/openjdk/jdk/pull/6000/commits/e9e9d60543a01678125a92da838cb059feb8ad16 . However, I think all we have to do is clear the exception in following code because the exception will be recorded to UL as error level. ```c++ if (HAS_PENDING_EXCEPTION) { java_lang_Throwable::print(PENDING_EXCEPTION, tty); CLEAR_PENDING_EXCEPTION; tty->cr(); // java_lang_Throwable::print will not print '\n' return false; } > When I try "$ jcmd JFR.configure" I see "Repository path: N/A", which is perhaps OK. Then I run "jcmd JFR.configure dumppath=/directory/somewhere" and it prints "Dump path: /directory/somewhere", but when I run JFR.configure again, it still prints "Repository path: N/A" Originally dump path would not be reported to the user. I added it in https://github.com/openjdk/jdk/pull/6000/commits/42633f225b529b4b2eb54563e7f838164c7162cd . ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From egahlin at openjdk.java.net Tue Oct 26 07:30:14 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 26 Oct 2021 07:30:14 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect [v4] In-Reply-To: References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> Message-ID: On Tue, 26 Oct 2021 05:22:42 GMT, Yasumasa Suenaga wrote: >> This PR is for redo-ing [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). >> I changed to use `SecuritySupport` at `Options::setDumpPath` as @egahlin mentioned. Please see change both Options.java and SecuritySupport.java . >> >> I've tested this change with all jdk/jfr tests on Linux x64, and they works fine. >> @egahlin @mgronlun Can you run Mach5 tests with this change? > > Yasumasa Suenaga 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 six additional commits since the last revision: > > - Add dumppath to JFR.configure dcmd > - Add "\n" after printing exception > - Merge remote-tracking branch 'upstream/master' into JDK-8275375-2 > - Propagate IOException at setDumpPath() to the caller > - Refactoring setDumpPath related code > - 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect If I remember correctly, if the exception is cleared, the exit status of the process will be incorrect. That said, it would be good to get rid of "jdk.jfr.internal.dcmd.DCmdException: Could not ...", but it doesn't necessary need to be fixed in this PR and it must work with other options as well, for example JFR.configure samplethreads=incorrect ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From ysuenaga at openjdk.java.net Tue Oct 26 10:09:11 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 26 Oct 2021 10:09:11 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect [v4] In-Reply-To: References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> Message-ID: On Tue, 26 Oct 2021 05:22:42 GMT, Yasumasa Suenaga wrote: >> This PR is for redo-ing [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). >> I changed to use `SecuritySupport` at `Options::setDumpPath` as @egahlin mentioned. Please see change both Options.java and SecuritySupport.java . >> >> I've tested this change with all jdk/jfr tests on Linux x64, and they works fine. >> @egahlin @mgronlun Can you run Mach5 tests with this change? > > Yasumasa Suenaga 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 six additional commits since the last revision: > > - Add dumppath to JFR.configure dcmd > - Add "\n" after printing exception > - Merge remote-tracking branch 'upstream/master' into JDK-8275375-2 > - Propagate IOException at setDumpPath() to the caller > - Refactoring setDumpPath related code > - 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect > but it doesn't necessary need to be fixed in this PR and it must work with other options as well, for example JFR.configure samplethreads=incorrect Ok, I will not make more change around them, so can you review this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/6000