From egahlin at openjdk.org Mon Mar 3 18:18:09 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 3 Mar 2025 18:18:09 GMT Subject: RFR: 8351064: JFR: Consistent timestamps Message-ID: Could I have review of a PR that makes time conversion uses offsets taken from the first chunk even if user-defined events are registered and parsers are reconstructed. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/23870/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23870&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351064 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23870.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23870/head:pull/23870 PR: https://git.openjdk.org/jdk/pull/23870 From mgronlun at openjdk.org Mon Mar 3 20:37:02 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 3 Mar 2025 20:37:02 GMT Subject: RFR: 8351064: JFR: Consistent timestamps In-Reply-To: References: Message-ID: On Mon, 3 Mar 2025 18:07:54 GMT, Erik Gahlin wrote: > Could I have review of a PR that makes time conversion uses offsets taken from the first chunk even if user-defined events are registered and parsers are reconstructed. > > Testing: jdk/jdk/jfr > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23870#pullrequestreview-2655227775 From shade at openjdk.org Tue Mar 4 11:08:07 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 4 Mar 2025 11:08:07 GMT Subject: RFR: 8351146: JFR: Reconsider thresholds for monitor-related events Message-ID: There are two issues with current thresholds for monitor-related events: 1. The threshold for enter/wait is too high for practical use. @coleenp separately said during related CSR review that 5ms is more practical value: https://bugs.openjdk.org/browse/JDK-8348833?focusedId=14744853#comment-14744853 -- I think we should trim those even further. 2. There is a threshold for inflate event. But the operation that is covered by that event is very fast, and often lock-free, so the threshold would filter many events. This would be important as we add deflation event ([JDK-8351142](https://bugs.openjdk.org/browse/JDK-8351142)), which should match inflations. The PR changes `locking-threshold` default, so it affects a few other events as well. I am picking 1ms as the practical value that we usually deal with in production environments, as we chase down single-digit-ms latency hogs. I am open for suggestions about the values, though. Maybe `default.jfc` values should be higher? Additional testing: - [x] Linux x86_64 server fastdebug, `jdk_jfr` still passes ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/23891/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23891&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351146 Stats: 12 lines in 2 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/23891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23891/head:pull/23891 PR: https://git.openjdk.org/jdk/pull/23891 From egahlin at openjdk.org Tue Mar 4 17:43:16 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 4 Mar 2025 17:43:16 GMT Subject: Integrated: 8351064: JFR: Consistent timestamps In-Reply-To: References: Message-ID: On Mon, 3 Mar 2025 18:07:54 GMT, Erik Gahlin wrote: > Could I have review of a PR that makes time conversion use offsets taken from the first chunk (even when a user-defined event is registered and new parsers are reconstructed) > > Testing: jdk/jdk/jfr > > Thanks > Erik This pull request has now been integrated. Changeset: 55987925 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/55987925fd8ba5d7782934194141fe425a9041be Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8351064: JFR: Consistent timestamps Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/23870 From egahlin at openjdk.org Tue Mar 4 22:32:56 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 4 Mar 2025 22:32:56 GMT Subject: RFR: 8351146: JFR: Reconsider thresholds for monitor-related events In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 11:03:03 GMT, Aleksey Shipilev wrote: > There are two issues with current thresholds for monitor-related events: > > 1. The threshold for enter/wait is too high for practical use. @coleenp separately said during related CSR review that 5ms is more practical value: https://bugs.openjdk.org/browse/JDK-8348833?focusedId=14744853#comment-14744853 -- I think we should trim those even further. > > 2. There is a threshold for inflate event. But the operation that is covered by that event is very fast, and often lock-free, so the threshold would filter many events. This would be important as we add deflation event ([JDK-8351142](https://bugs.openjdk.org/browse/JDK-8351142)), which should match inflations. > > The PR changes `locking-threshold` default, so it affects a few other events as well. I am picking 1ms as the practical value that we usually deal with in production environments, as we chase down single-digit-ms latency hogs. I am open for suggestions about the values, though. Maybe `default.jfc` values should be higher? > > Additional testing: > - [x] Linux x86_64 server fastdebug, `jdk_jfr` still passes We looked into this when we created the initial configurations and are aware that the values are rather high. The default configuration should be able to handle pathological applications. A user should never have to learn how to disable an event to use JFR, or risk running into more than 1% CPU overhead. Users can always opt-in, i.e. -XX:StartFlightRecording:locking-threshold=1ms. The profile configuration is more targeted to what can be expected to work in typical applications. That said, our plan is to introduce rate-limited sampling, so we can set an upper bound, i.e. 300/s, similar to what we have for the ObjectAllocationSample event. We probably want to have both outliers/thresholds and samples at the same time, so there are design issues that need to be sorted out. For example, should we sample above the threshold or should they be independent. There is also another feature coming, contextual events, that could impact the design. We have similar issues with socket events. I think we should keep things as-is until we implement rate-limited sampling, to avoid flipping settings back and forth between releases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23891#issuecomment-2699108603 From shade at openjdk.org Wed Mar 5 09:03:52 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 5 Mar 2025 09:03:52 GMT Subject: RFR: 8351146: JFR: Reconsider thresholds for monitor-related events In-Reply-To: References: Message-ID: <22YA1wEPW1HsFZor10Ltv2NV0x0HUUfMvY6QALzSQOw=.a72abf61-713d-4cd2-b0f1-f078917e2717@github.com> On Tue, 4 Mar 2025 11:03:03 GMT, Aleksey Shipilev wrote: > There are two issues with current thresholds for monitor-related events: > > 1. The threshold for enter/wait is too high for practical use. @coleenp separately said during related CSR review that 5ms is more practical value: https://bugs.openjdk.org/browse/JDK-8348833?focusedId=14744853#comment-14744853 -- I think we should trim those even further. > > 2. There is a threshold for inflate event. But the operation that is covered by that event is very fast, and often lock-free, so the threshold would filter many events. This would be important as we add deflation event ([JDK-8351142](https://bugs.openjdk.org/browse/JDK-8351142)), which should match inflations. > > The PR changes `locking-threshold` default, so it affects a few other events as well. I am picking 1ms as the practical value that we usually deal with in production environments, as we chase down single-digit-ms latency hogs. I am open for suggestions about the values, though. Maybe `default.jfc` values should be higher? > > Additional testing: > - [x] Linux x86_64 server fastdebug, `jdk_jfr` still passes Understood, thanks for the context. Would you agree to drop the threshold from `JavaMonitorInflate` event? That event does not involve actual locking, and so it is weird to have it with a time threshold. The event is disabled, so there should be no impact on default/profile configs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23891#issuecomment-2700282019 From egahlin at openjdk.org Wed Mar 5 20:32:56 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 5 Mar 2025 20:32:56 GMT Subject: RFR: 8351146: JFR: Reconsider thresholds for monitor-related events In-Reply-To: <22YA1wEPW1HsFZor10Ltv2NV0x0HUUfMvY6QALzSQOw=.a72abf61-713d-4cd2-b0f1-f078917e2717@github.com> References: <22YA1wEPW1HsFZor10Ltv2NV0x0HUUfMvY6QALzSQOw=.a72abf61-713d-4cd2-b0f1-f078917e2717@github.com> Message-ID: On Wed, 5 Mar 2025 09:01:36 GMT, Aleksey Shipilev wrote: > Understood, thanks for the context. > > Would you agree to drop the threshold from `JavaMonitorInflate` event? That event does not involve actual locking, and so it is weird to have it with a time threshold. The event is disabled in `default.jfc`, so there should be no impact there. It is enabled in `profile.jfc`, but I believe inflations are self-limiting in realistic applications that do not churn the monitors. We can disable the `JavaMonitorInflate` event in `profile.jfc` if we want to be extra-safe. With current threshold it is effectively disabled anyway, I think. I'm fine with removing the threshold if the duration is useless, but I would prefer to have the JavaMonitorInflate event disabled. Maybe it's OK to have it enabled, but I would need to look into it further before making a decision. The JavaMonitorInflate event would function well with adaptive rate-sampling. With an upper limit in place, we don't need to speculate about how often locks are inflated in a typical application. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23891#issuecomment-2701996669 From shade at openjdk.org Thu Mar 6 10:55:36 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 6 Mar 2025 10:55:36 GMT Subject: RFR: 8351146: JFR: JavaMonitorInflate event should default to no threshold and be disabled [v2] In-Reply-To: References: Message-ID: > There is a threshold for inflate event. But the operation that is covered by that event is very fast, and often lock-free, so the threshold would filter many events. This would be important as we add deflation event ([JDK-8351142](https://bugs.openjdk.org/browse/JDK-8351142)), which should match inflations. > > The only way I see this event be longer than default threshold of 10ms is transiently waiting for another thread to complete inflation. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `jdk_jfr` still passes Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Disable JavaMonitorInflate and put the low default threshold - Merge branch 'master' into JDK-8351146-jfr-monitor-thresholds - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23891/files - new: https://git.openjdk.org/jdk/pull/23891/files/f0156c68..9b5ba84d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23891&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23891&range=00-01 Stats: 10214 lines in 310 files changed: 5879 ins; 2446 del; 1889 mod Patch: https://git.openjdk.org/jdk/pull/23891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23891/head:pull/23891 PR: https://git.openjdk.org/jdk/pull/23891 From shade at openjdk.org Thu Mar 6 10:55:36 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 6 Mar 2025 10:55:36 GMT Subject: RFR: 8351146: JFR: JavaMonitorInflate event should default to no threshold and be disabled In-Reply-To: References: <22YA1wEPW1HsFZor10Ltv2NV0x0HUUfMvY6QALzSQOw=.a72abf61-713d-4cd2-b0f1-f078917e2717@github.com> Message-ID: <1EoybDAJmQMq5646DaR1s--FnY1x6NKDh1xv1fLevhc=.916c0100-c0d8-4a3d-aad7-64612ec2323b@github.com> On Wed, 5 Mar 2025 20:30:19 GMT, Erik Gahlin wrote: > I'm fine with removing the threshold if the duration is useless, but I would prefer to have the JavaMonitorInflate event disabled. Cool. Done both in new version, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23891#issuecomment-2703495172 From coleenp at openjdk.org Fri Mar 7 13:00:53 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 7 Mar 2025 13:00:53 GMT Subject: RFR: 8351146: JFR: JavaMonitorInflate event should default to no threshold and be disabled [v2] In-Reply-To: References: Message-ID: On Thu, 6 Mar 2025 10:55:36 GMT, Aleksey Shipilev wrote: >> There is a threshold for inflate event. But the operation that is covered by that event is very fast, and often lock-free, so the threshold would filter many events. This would be important as we add deflation event ([JDK-8351142](https://bugs.openjdk.org/browse/JDK-8351142)), which should match inflations. >> >> The only way I see this event be longer than default threshold of 10ms is transiently waiting for another thread to complete inflation. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `jdk_jfr` still passes > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Disable JavaMonitorInflate and put the low default threshold > - Merge branch 'master' into JDK-8351146-jfr-monitor-thresholds > - Fix This makes sense. I guess this is better than leaving it as 20 and having someone know to change it to 0 in their jfc file. Is there a command line way to enable the event, or does that require a custom jfc file? ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23891#pullrequestreview-2667185356 From egahlin at openjdk.org Fri Mar 7 15:52:52 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 7 Mar 2025 15:52:52 GMT Subject: RFR: 8351146: JFR: JavaMonitorInflate event should default to no threshold and be disabled [v2] In-Reply-To: References: Message-ID: On Fri, 7 Mar 2025 12:57:55 GMT, Coleen Phillimore wrote: > This makes sense. I guess this is better than leaving it as 20 and having someone know to change it to 0 in their jfc file. Is there a command line way to enable the event, or does that require a custom jfc file? That's true, with a 20 ms threshold, users can specify -XX:StartFlightRecording:locking-threshold=0ms to enable the event, which may be easier than -XX:StartFlightRecording:jdk.JavaMonitorInflate#enabled=true. That said, if the duration/threshold is useless, I think it's a good idea to remove it. I would assume that few users set locking-threshold=0ms anyway, as it results in an enormous amount of events, not just JavaMonitorInflate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23891#issuecomment-2706794728 From egahlin at openjdk.org Sun Mar 9 23:50:49 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Sun, 9 Mar 2025 23:50:49 GMT Subject: RFR: 8351266: JFR: -XX:StartFlightRecording:report-on-exit Message-ID: Could I have a review of an enhancement that prints 'jfr view' when the JVM exits? The purpose is to simplify usage and avoid the need to dump to a file. For more details, see the [CSR](https://bugs.openjdk.org/browse/JDK-8351370) Example usage: $ java -XX:StartFlightRecording:report-on-exit=hot-methods ... [0.166s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default. [0.166s][info][jfr,startup] [0.166s][info][jfr,startup] Use jcmd 66977 JFR.dump name=1 filename=FILEPATH to copy recording data to file. Java Methods that Executes the Most Method Samples Percent ------------------------------------------------------------------------------------------------------- ------- ------- sun.java2d.marlin.Renderer._endRendering(int, int) 120 33.99% sun.java2d.marlin.MarlinTileGenerator.getAlphaRLE(byte[], int, int) 22 6.23% sun.awt.image.PNGImageDecoder.produceImage() 19 5.38% sun.java2d.marlin.MarlinCache.copyAARowRLE_WithBlockFlags(int[], int[], int, int, int) 14 3.97% sun.java2d.marlin.MarlinTileGenerator.getAlphaNoRLE(byte[], int, int) 7 1.98% sun.java2d.marlin.Renderer.copyAARow(int[], int, int, int, boolean) 7 1.98% sun.awt.image.PNGImageDecoder.filterRow(byte[], byte[], int, int, int) 7 1.98% sun.java2d.marlin.MarlinCache.copyAARowNoRLE(int[], int, int, int) 5 1.42% sun.java2d.pipe.BufferedContext.validate(...) 5 1.42% java.awt.GradientPaintContext.clipFillRaster(int[], int, int, int, int, double, double, double) 3 0.85% Testing: jdk/jdk/jfr ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/23958/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23958&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351266 Stats: 292 lines in 15 files changed: 275 ins; 3 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/23958.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23958/head:pull/23958 PR: https://git.openjdk.org/jdk/pull/23958 From shade at openjdk.org Mon Mar 10 11:41:00 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 10 Mar 2025 11:41:00 GMT Subject: RFR: 8351146: JFR: JavaMonitorInflate event should default to no threshold and be disabled [v2] In-Reply-To: References: Message-ID: On Fri, 7 Mar 2025 15:50:09 GMT, Erik Gahlin wrote: > That said, if the duration/threshold is useless, I think it's a good idea to remove it. Yes, I believe duration/threshold for this event is useless. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23891#issuecomment-2710293313 From egahlin at openjdk.org Tue Mar 11 02:12:35 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 11 Mar 2025 02:12:35 GMT Subject: RFR: 8351266: JFR: -XX:StartFlightRecording:report-on-exit [v2] In-Reply-To: References: Message-ID: > Could I have a review of an enhancement that prints 'jfr view' when the JVM exits? The purpose is to simplify usage and avoid the need to dump to a file. > > For more details, see the [CSR](https://bugs.openjdk.org/browse/JDK-8351370) > > Example usage: > > $ java -XX:StartFlightRecording:report-on-exit=hot-methods ... > [0.166s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default. > [0.166s][info][jfr,startup] > [0.166s][info][jfr,startup] Use jcmd 66977 JFR.dump name=1 filename=FILEPATH to copy recording data to file. > > Java Methods that Executes the Most > > Method Samples Percent > ------------------------------------------------------------------------------------------------------- ------- ------- > sun.java2d.marlin.Renderer._endRendering(int, int) 120 33.99% > sun.java2d.marlin.MarlinTileGenerator.getAlphaRLE(byte[], int, int) 22 6.23% > sun.awt.image.PNGImageDecoder.produceImage() 19 5.38% > sun.java2d.marlin.MarlinCache.copyAARowRLE_WithBlockFlags(int[], int[], int, int, int) 14 3.97% > sun.java2d.marlin.MarlinTileGenerator.getAlphaNoRLE(byte[], int, int) 7 1.98% > sun.java2d.marlin.Renderer.copyAARow(int[], int, int, int, boolean) 7 1.98% > sun.awt.image.PNGImageDecoder.filterRow(byte[], byte[], int, int, int) 7 1.98% > sun.java2d.marlin.MarlinCache.copyAARowNoRLE(int[], int, int, int) 5 1.42% > sun.java2d.pipe.BufferedContext.validate(...) 5 1.42% > java.awt.GradientPaintContext.clipFillRaster(int[], int, int, int, int, double, double, double) 3 0.85% > > Testing: jdk/jdk/jfr Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Only allow report-on-exit with -XX:StartFlightRecording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23958/files - new: https://git.openjdk.org/jdk/pull/23958/files/6d6723e0..2f0d5a0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23958&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23958&range=00-01 Stats: 48 lines in 3 files changed: 33 ins; 11 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23958.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23958/head:pull/23958 PR: https://git.openjdk.org/jdk/pull/23958 From egahlin at openjdk.org Tue Mar 11 14:56:59 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 11 Mar 2025 14:56:59 GMT Subject: RFR: 8351146: JFR: JavaMonitorInflate event should default to no threshold and be disabled [v2] In-Reply-To: References: Message-ID: <93qcHLRS8Wtc6HB6XXy4QPW4avL07VC-6nMaydOt1sQ=.9e456450-c6ea-41d3-9ba6-a670f62fdda2@github.com> On Thu, 6 Mar 2025 10:55:36 GMT, Aleksey Shipilev wrote: >> There is a threshold for inflate event. But the operation that is covered by that event is very fast, and often lock-free, so the threshold would filter many events. This would be important as we add deflation event ([JDK-8351142](https://bugs.openjdk.org/browse/JDK-8351142)), which should match inflations. >> >> The only way I see this event be longer than default threshold of 10ms is transiently waiting for another thread to complete inflation. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `jdk_jfr` still passes > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Disable JavaMonitorInflate and put the low default threshold > - Merge branch 'master' into JDK-8351146-jfr-monitor-thresholds > - Fix Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23891#pullrequestreview-2674921077 From shade at openjdk.org Tue Mar 11 15:31:04 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 11 Mar 2025 15:31:04 GMT Subject: RFR: 8351146: JFR: JavaMonitorInflate event should default to no threshold and be disabled [v2] In-Reply-To: References: Message-ID: On Thu, 6 Mar 2025 10:55:36 GMT, Aleksey Shipilev wrote: >> There is a threshold for inflate event. But the operation that is covered by that event is very fast, and often lock-free, so the threshold would filter many events. This would be important as we add deflation event ([JDK-8351142](https://bugs.openjdk.org/browse/JDK-8351142)), which should match inflations. >> >> The only way I see this event be longer than default threshold of 10ms is transiently waiting for another thread to complete inflation. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `jdk_jfr` still passes > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Disable JavaMonitorInflate and put the low default threshold > - Merge branch 'master' into JDK-8351146-jfr-monitor-thresholds > - Fix Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23891#issuecomment-2714760051 From shade at openjdk.org Tue Mar 11 15:31:05 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 11 Mar 2025 15:31:05 GMT Subject: Integrated: 8351146: JFR: JavaMonitorInflate event should default to no threshold and be disabled In-Reply-To: References: Message-ID: <26lopZKgldRNBIux8-3feRtDx3klBGn8zPR7ExaMVjI=.f89a8d69-f0d8-4a83-8ec8-836ce8176cbd@github.com> On Tue, 4 Mar 2025 11:03:03 GMT, Aleksey Shipilev wrote: > There is a threshold for inflate event. But the operation that is covered by that event is very fast, and often lock-free, so the threshold would filter many events. This would be important as we add deflation event ([JDK-8351142](https://bugs.openjdk.org/browse/JDK-8351142)), which should match inflations. > > The only way I see this event be longer than default threshold of 10ms is transiently waiting for another thread to complete inflation. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `jdk_jfr` still passes This pull request has now been integrated. Changeset: 0ad9a104 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/0ad9a104e2fed2dd80494cec22e9d9332d37821b Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8351146: JFR: JavaMonitorInflate event should default to no threshold and be disabled Reviewed-by: coleenp, egahlin ------------- PR: https://git.openjdk.org/jdk/pull/23891 From shade at openjdk.org Thu Mar 13 10:29:02 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 13 Mar 2025 10:29:02 GMT Subject: RFR: 8351925: JFR: Microsecond time format precision for JFR tool Message-ID: Currently, JFR tool formats the times with millisecond precision: jdk.ThreadSleep { startTime = 10:48:56.668 (2025-03-13) duration = 100 ms time = 100 ms eventThread = "main" (javaThreadId = 3) stackTrace = [...] } In modern world, a lot can happen within a millisecond. So it would be better to default to microsecond precision. Both timesources supported by JFR (RDTSC and os::elapsed_counter()) have enough enough precision to satisfy microsecond output, so microseconds are meaningful. After the patch: jdk.ThreadSleep { startTime = 11:23:32.314580 (2025-03-13) duration = 100 ms time = 100 ms eventThread = "main" (javaThreadId = 3) stackTrace = [...] } I think durations should also be more precise -- for example to compute the endTime precisely from (startTime+duration), but that is a more controversial/style question, so I would like to handle it separately. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/24029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24029&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351925 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24029.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24029/head:pull/24029 PR: https://git.openjdk.org/jdk/pull/24029 From egahlin at openjdk.org Thu Mar 13 13:42:22 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 13 Mar 2025 13:42:22 GMT Subject: RFR: 8351266: JFR: -XX:StartFlightRecording:report-on-exit [v3] In-Reply-To: References: Message-ID: > Could I have a review of an enhancement that prints 'jfr view' when the JVM exits? The purpose is to simplify usage and avoid the need to dump to a file. > > For more details, see the [CSR](https://bugs.openjdk.org/browse/JDK-8351370) > > Example usage: > > $ java -XX:StartFlightRecording:report-on-exit=hot-methods ... > [0.166s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default. > [0.166s][info][jfr,startup] > [0.166s][info][jfr,startup] Use jcmd 66977 JFR.dump name=1 filename=FILEPATH to copy recording data to file. > > Java Methods that Executes the Most > > Method Samples Percent > ------------------------------------------------------------------------------------------------------- ------- ------- > sun.java2d.marlin.Renderer._endRendering(int, int) 120 33.99% > sun.java2d.marlin.MarlinTileGenerator.getAlphaRLE(byte[], int, int) 22 6.23% > sun.awt.image.PNGImageDecoder.produceImage() 19 5.38% > sun.java2d.marlin.MarlinCache.copyAARowRLE_WithBlockFlags(int[], int[], int, int, int) 14 3.97% > sun.java2d.marlin.MarlinTileGenerator.getAlphaNoRLE(byte[], int, int) 7 1.98% > sun.java2d.marlin.Renderer.copyAARow(int[], int, int, int, boolean) 7 1.98% > sun.awt.image.PNGImageDecoder.filterRow(byte[], byte[], int, int, int) 7 1.98% > sun.java2d.marlin.MarlinCache.copyAARowNoRLE(int[], int, int, int) 5 1.42% > sun.java2d.pipe.BufferedContext.validate(...) 5 1.42% > java.awt.GradientPaintContext.clipFillRaster(int[], int, int, int, int, double, double, double) 3 0.85% > > Testing: jdk/jdk/jfr Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23958/files - new: https://git.openjdk.org/jdk/pull/23958/files/2f0d5a0b..c0a2ae4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23958&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23958&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23958.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23958/head:pull/23958 PR: https://git.openjdk.org/jdk/pull/23958 From mgronlun at openjdk.org Thu Mar 13 13:42:22 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 13 Mar 2025 13:42:22 GMT Subject: RFR: 8351266: JFR: -XX:StartFlightRecording:report-on-exit [v3] In-Reply-To: References: Message-ID: <988J9liS9iRgyTw5YDsq0ys7nT-8PNZzuGk3czhZngg=.43d9cd54-34a5-4143-b374-1b4b4b2687e7@github.com> On Thu, 13 Mar 2025 13:39:38 GMT, Erik Gahlin wrote: >> Could I have a review of an enhancement that prints 'jfr view' when the JVM exits? The purpose is to simplify usage and avoid the need to dump to a file. >> >> For more details, see the [CSR](https://bugs.openjdk.org/browse/JDK-8351370) >> >> Example usage: >> >> $ java -XX:StartFlightRecording:report-on-exit=hot-methods ... >> [0.166s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default. >> [0.166s][info][jfr,startup] >> [0.166s][info][jfr,startup] Use jcmd 66977 JFR.dump name=1 filename=FILEPATH to copy recording data to file. >> >> Java Methods that Executes the Most >> >> Method Samples Percent >> ------------------------------------------------------------------------------------------------------- ------- ------- >> sun.java2d.marlin.Renderer._endRendering(int, int) 120 33.99% >> sun.java2d.marlin.MarlinTileGenerator.getAlphaRLE(byte[], int, int) 22 6.23% >> sun.awt.image.PNGImageDecoder.produceImage() 19 5.38% >> sun.java2d.marlin.MarlinCache.copyAARowRLE_WithBlockFlags(int[], int[], int, int, int) 14 3.97% >> sun.java2d.marlin.MarlinTileGenerator.getAlphaNoRLE(byte[], int, int) 7 1.98% >> sun.java2d.marlin.Renderer.copyAARow(int[], int, int, int, boolean) 7 1.98% >> sun.awt.image.PNGImageDecoder.filterRow(byte[], byte[], int, int, int) 7 1.98% >> sun.java2d.marlin.MarlinCache.copyAARowNoRLE(int[], int, int, int) 5 1.42% >> sun.java2d.pipe.BufferedContext.validate(...) 5 1.42% >> java.awt.GradientPaintContext.clipFillRaster(int[], int, int, int, int, double, double, double) 3 0.85% >> >> Testing: jdk/jdk/jfr > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace Very convenient feature, Erik! Well done. ------------- Marked as reviewed by mgronlun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23958#pullrequestreview-2681938062 From egahlin at openjdk.org Thu Mar 13 15:14:21 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 13 Mar 2025 15:14:21 GMT Subject: RFR: 8351266: JFR: -XX:StartFlightRecording:report-on-exit [v4] In-Reply-To: References: Message-ID: > Could I have a review of an enhancement that prints 'jfr view' when the JVM exits? The purpose is to simplify usage and avoid the need to dump to a file. > > For more details, see the [CSR](https://bugs.openjdk.org/browse/JDK-8351370) > > Example usage: > > $ java -XX:StartFlightRecording:report-on-exit=hot-methods ... > [0.166s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default. > [0.166s][info][jfr,startup] > [0.166s][info][jfr,startup] Use jcmd 66977 JFR.dump name=1 filename=FILEPATH to copy recording data to file. > > Java Methods that Executes the Most > > Method Samples Percent > ------------------------------------------------------------------------------------------------------- ------- ------- > sun.java2d.marlin.Renderer._endRendering(int, int) 120 33.99% > sun.java2d.marlin.MarlinTileGenerator.getAlphaRLE(byte[], int, int) 22 6.23% > sun.awt.image.PNGImageDecoder.produceImage() 19 5.38% > sun.java2d.marlin.MarlinCache.copyAARowRLE_WithBlockFlags(int[], int[], int, int, int) 14 3.97% > sun.java2d.marlin.MarlinTileGenerator.getAlphaNoRLE(byte[], int, int) 7 1.98% > sun.java2d.marlin.Renderer.copyAARow(int[], int, int, int, boolean) 7 1.98% > sun.awt.image.PNGImageDecoder.filterRow(byte[], byte[], int, int, int) 7 1.98% > sun.java2d.marlin.MarlinCache.copyAARowNoRLE(int[], int, int, int) 5 1.42% > sun.java2d.pipe.BufferedContext.validate(...) 5 1.42% > java.awt.GradientPaintContext.clipFillRaster(int[], int, int, int, int, double, double, double) 3 0.85% > > Testing: jdk/jdk/jfr Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Fix typo in help ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23958/files - new: https://git.openjdk.org/jdk/pull/23958/files/c0a2ae4a..4cf2ecde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23958&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23958&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23958.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23958/head:pull/23958 PR: https://git.openjdk.org/jdk/pull/23958 From mgronlun at openjdk.org Thu Mar 13 18:09:27 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 13 Mar 2025 18:09:27 GMT Subject: RFR: 8351967: JFR: Bug in AnnotationIterator Message-ID: Greetings, A tiny adjustment to cover a corner case related to the processing of the RuntimeVisibleAnnotations attribute. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8351967 Changes: https://git.openjdk.org/jdk/pull/24037/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24037&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351967 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24037.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24037/head:pull/24037 PR: https://git.openjdk.org/jdk/pull/24037 From egahlin at openjdk.org Thu Mar 13 19:13:52 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 13 Mar 2025 19:13:52 GMT Subject: RFR: 8351967: JFR: Bug in AnnotationIterator In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 18:03:05 GMT, Markus Gr?nlund wrote: > Greetings, > > A tiny adjustment to cover a corner case related to the processing of the RuntimeVisibleAnnotations attribute. > > Testing: jdk_jfr > > Thanks > Markus Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24037#pullrequestreview-2683120992 From mgronlun at openjdk.org Thu Mar 13 19:16:59 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 13 Mar 2025 19:16:59 GMT Subject: RFR: 8351266: JFR: -XX:StartFlightRecording:report-on-exit [v4] In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 15:14:21 GMT, Erik Gahlin wrote: >> Could I have a review of an enhancement that prints 'jfr view' when the JVM exits? The purpose is to simplify usage and avoid the need to dump to a file. >> >> For more details, see the [CSR](https://bugs.openjdk.org/browse/JDK-8351370) >> >> Example usage: >> >> $ java -XX:StartFlightRecording:report-on-exit=hot-methods ... >> [0.166s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default. >> [0.166s][info][jfr,startup] >> [0.166s][info][jfr,startup] Use jcmd 66977 JFR.dump name=1 filename=FILEPATH to copy recording data to file. >> >> Java Methods that Executes the Most >> >> Method Samples Percent >> ------------------------------------------------------------------------------------------------------- ------- ------- >> sun.java2d.marlin.Renderer._endRendering(int, int) 120 33.99% >> sun.java2d.marlin.MarlinTileGenerator.getAlphaRLE(byte[], int, int) 22 6.23% >> sun.awt.image.PNGImageDecoder.produceImage() 19 5.38% >> sun.java2d.marlin.MarlinCache.copyAARowRLE_WithBlockFlags(int[], int[], int, int, int) 14 3.97% >> sun.java2d.marlin.MarlinTileGenerator.getAlphaNoRLE(byte[], int, int) 7 1.98% >> sun.java2d.marlin.Renderer.copyAARow(int[], int, int, int, boolean) 7 1.98% >> sun.awt.image.PNGImageDecoder.filterRow(byte[], byte[], int, int, int) 7 1.98% >> sun.java2d.marlin.MarlinCache.copyAARowNoRLE(int[], int, int, int) 5 1.42% >> sun.java2d.pipe.BufferedContext.validate(...) 5 1.42% >> java.awt.GradientPaintContext.clipFillRaster(int[], int, int, int, int, double, double, double) 3 0.85% >> >> Testing: jdk/jdk/jfr > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in help Still good. ------------- Marked as reviewed by mgronlun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23958#pullrequestreview-2683127830 From egahlin at openjdk.org Thu Mar 13 19:24:02 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 13 Mar 2025 19:24:02 GMT Subject: Integrated: 8351266: JFR: -XX:StartFlightRecording:report-on-exit In-Reply-To: References: Message-ID: On Sun, 9 Mar 2025 23:34:39 GMT, Erik Gahlin wrote: > Could I have a review of an enhancement that prints 'jfr view' when the JVM exits? The purpose is to simplify usage and avoid the need to dump to a file. > > For more details, see the [CSR](https://bugs.openjdk.org/browse/JDK-8351370) > > Example usage: > > $ java -XX:StartFlightRecording:report-on-exit=hot-methods ... > [0.166s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default. > [0.166s][info][jfr,startup] > [0.166s][info][jfr,startup] Use jcmd 66977 JFR.dump name=1 filename=FILEPATH to copy recording data to file. > > Java Methods that Executes the Most > > Method Samples Percent > ------------------------------------------------------------------------------------------------------- ------- ------- > sun.java2d.marlin.Renderer._endRendering(int, int) 120 33.99% > sun.java2d.marlin.MarlinTileGenerator.getAlphaRLE(byte[], int, int) 22 6.23% > sun.awt.image.PNGImageDecoder.produceImage() 19 5.38% > sun.java2d.marlin.MarlinCache.copyAARowRLE_WithBlockFlags(int[], int[], int, int, int) 14 3.97% > sun.java2d.marlin.MarlinTileGenerator.getAlphaNoRLE(byte[], int, int) 7 1.98% > sun.java2d.marlin.Renderer.copyAARow(int[], int, int, int, boolean) 7 1.98% > sun.awt.image.PNGImageDecoder.filterRow(byte[], byte[], int, int, int) 7 1.98% > sun.java2d.marlin.MarlinCache.copyAARowNoRLE(int[], int, int, int) 5 1.42% > sun.java2d.pipe.BufferedContext.validate(...) 5 1.42% > java.awt.GradientPaintContext.clipFillRaster(int[], int, int, int, int, double, double, double) 3 0.85% > > Testing: jdk/jdk/jfr This pull request has now been integrated. Changeset: 248c373b Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/248c373b5b066b6b3eaa5a7461f30733f30b0a13 Stats: 314 lines in 15 files changed: 297 ins; 3 del; 14 mod 8351266: JFR: -XX:StartFlightRecording:report-on-exit Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/23958 From mgronlun at openjdk.org Thu Mar 13 21:04:03 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 13 Mar 2025 21:04:03 GMT Subject: RFR: 8351976: assert(vthread_epoch == current_epoch) failed: invariant Message-ID: <4Jh42AViCPQIfaDyGquZmGAI5v7i5_tCaAxRSTi-caI=.db438a61-0f98-46a9-ad65-fd9126978304@github.com> Greetings, This fix adjusts for an epoch mismatch for excluded virtual threads that become included after being mounted. The JIRA issue has more details. Testing: jdk_jfr, stress testing Thanks Markus ------------- Commit messages: - 8351976 Changes: https://git.openjdk.org/jdk/pull/24041/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24041&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351976 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24041.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24041/head:pull/24041 PR: https://git.openjdk.org/jdk/pull/24041 From egahlin at openjdk.org Thu Mar 13 21:40:53 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 13 Mar 2025 21:40:53 GMT Subject: RFR: 8351976: assert(vthread_epoch == current_epoch) failed: invariant In-Reply-To: <4Jh42AViCPQIfaDyGquZmGAI5v7i5_tCaAxRSTi-caI=.db438a61-0f98-46a9-ad65-fd9126978304@github.com> References: <4Jh42AViCPQIfaDyGquZmGAI5v7i5_tCaAxRSTi-caI=.db438a61-0f98-46a9-ad65-fd9126978304@github.com> Message-ID: <3awtgi4g-k9QF1jWyZp3Hi91AK2_OiL9czr0fmGYNgc=.b258998c-5e29-418a-89e3-f396cbe43121@github.com> On Thu, 13 Mar 2025 20:59:31 GMT, Markus Gr?nlund wrote: > Greetings, > > This fix adjusts for an epoch mismatch for excluded virtual threads that become included after being mounted. The JIRA issue has more details. > > Testing: jdk_jfr, stress testing > > Thanks > Markus Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24041#pullrequestreview-2683424647 From egahlin at openjdk.org Fri Mar 14 10:51:12 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 14 Mar 2025 10:51:12 GMT Subject: RFR: 8351999: JFR: Incorrect scaling of throttled values Message-ID: Could I have a review of a PR that fixes an incorrect scaling of samples for the ThrottleSetting. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/24045/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24045&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351999 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24045.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24045/head:pull/24045 PR: https://git.openjdk.org/jdk/pull/24045 From shade at openjdk.org Fri Mar 14 12:18:57 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 14 Mar 2025 12:18:57 GMT Subject: RFR: 8351999: JFR: Incorrect scaling of throttled values In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 01:52:15 GMT, Erik Gahlin wrote: > Could I have a review of a PR that fixes an incorrect scaling of samples for the ThrottleSetting. > > Testing: jdk/jdk/jfr > > Thanks > Erik Marked as reviewed by shade (Reviewer). src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java line 97: > 95: if (unit.nanos < SECONDS.nanos) { > 96: long perSecond = SECONDS.nanos / unit.nanos; > 97: samples = Utils.multiplyOverflow(samples, perSecond, Long.MAX_VALUE); Reasoning from the math alone, it looks obvious that `samples *= samples` is not correct. So that part looks fine. Thinking about `unit.nanos == SECONDS.nanos` case. This means the unit is exactly "seconds", so no adjustment is needed? ------------- PR Review: https://git.openjdk.org/jdk/pull/24045#pullrequestreview-2685332765 PR Review Comment: https://git.openjdk.org/jdk/pull/24045#discussion_r1995449423 From mgronlun at openjdk.org Fri Mar 14 15:00:14 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 14 Mar 2025 15:00:14 GMT Subject: RFR: 8352066: JVM.commit() and JVM.flush() exhibit race conditions against JFR epochs Message-ID: Greetings, This change set removes some race conditions involving JFR epochs. For details, please see the JIRA issue. Testing: jdk_jfr, TestChunkIntegrity testing Thanks Markus ------------- Commit messages: - 8352066 Changes: https://git.openjdk.org/jdk/pull/24061/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24061&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352066 Stats: 64 lines in 9 files changed: 5 ins; 36 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/24061.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24061/head:pull/24061 PR: https://git.openjdk.org/jdk/pull/24061 From egahlin at openjdk.org Fri Mar 14 16:19:59 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 14 Mar 2025 16:19:59 GMT Subject: RFR: 8351925: JFR: Microsecond time format precision for JFR tool In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 10:24:08 GMT, Aleksey Shipilev wrote: > Currently, JFR tool formats the times with millisecond precision: > > > jdk.ThreadSleep { > startTime = 10:48:56.668 (2025-03-13) > duration = 100 ms > time = 100 ms > eventThread = "main" (javaThreadId = 3) > stackTrace = [...] > } > > > In modern world, a lot can happen within a millisecond. So it would be better to default to microsecond precision. Both timesources supported by JFR (RDTSC and os::elapsed_counter()) have enough enough precision to satisfy microsecond output, so microseconds are meaningful. > > After the patch: > > > jdk.ThreadSleep { > startTime = 11:23:32.314580 (2025-03-13) > duration = 100 ms > time = 100 ms > eventThread = "main" (javaThreadId = 3) > stackTrace = [...] > } > > > I think durations should also be more precise -- for example to compute the endTime precisely from (startTime+duration), but that is a more controversial/style question, so I would like to handle it separately. The default mode (PrettyWriter) aims to present human-readable output, striking a balance between clarity and concision. For more detailed information, including timestamps and time spans with nine-digit precision, `jfr print --json` is available as an alternative. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24029#issuecomment-2725159598 From egahlin at openjdk.org Fri Mar 14 16:22:30 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 14 Mar 2025 16:22:30 GMT Subject: RFR: 8351995: JFR: Leftovers from removal of Security Manager Message-ID: <1CDZGleD4HS1WKiGAkshKTy2ResVB4UCP8VINGcw1m4=.d7788ddb-0857-4723-bd4c-9a45f30b0995@github.com> Could I have a review of a PR that removes leftovers from the removal of the Security Manager. Testing: jdk/jdk/jfr + tier1 Thanks Erik ------------- Commit messages: - Log exception on exit - Initial Changes: https://git.openjdk.org/jdk/pull/24044/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24044&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351995 Stats: 129 lines in 7 files changed: 0 ins; 127 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24044/head:pull/24044 PR: https://git.openjdk.org/jdk/pull/24044 From egahlin at openjdk.org Fri Mar 14 16:22:44 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 14 Mar 2025 16:22:44 GMT Subject: RFR: 8351992: JFR: Improve robustness of the SettingControl examples Message-ID: Could I have a review of PR that improves the robustness of the SettingControl examples. Testing: jdk/jdk/jfr + tier1 Thanks Erik ------------- Commit messages: - Minor changes - Initial Changes: https://git.openjdk.org/jdk/pull/24056/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24056&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351992 Stats: 42 lines in 2 files changed: 31 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/24056.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24056/head:pull/24056 PR: https://git.openjdk.org/jdk/pull/24056 From egahlin at openjdk.org Fri Mar 14 16:29:54 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 14 Mar 2025 16:29:54 GMT Subject: RFR: 8351999: JFR: Incorrect scaling of throttled values In-Reply-To: References: Message-ID: <5w52Lf3JUgGHwUYbjmW7zAce1Vic5T4EKWOd0vSLOB8=.25b14773-cabd-42d4-83c1-e07adb648665@github.com> On Fri, 14 Mar 2025 12:16:40 GMT, Aleksey Shipilev wrote: >> Could I have a review of a PR that fixes an incorrect scaling of samples for the ThrottleSetting. >> >> Testing: jdk/jdk/jfr >> >> Thanks >> Erik > > src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java line 97: > >> 95: if (unit.nanos < SECONDS.nanos) { >> 96: long perSecond = SECONDS.nanos / unit.nanos; >> 97: samples = Utils.multiplyOverflow(samples, perSecond, Long.MAX_VALUE); > > Reasoning from the math alone, it looks obvious that `samples *= samples` is not correct. So that part looks fine. > > Thinking about `unit.nanos == SECONDS.nanos` case. This means the unit is exactly "seconds", so no adjustment is needed? Native expects the value in milliseconds, and the default value is 1000 ms, so it seems fine to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24045#discussion_r1995881185 From egahlin at openjdk.org Fri Mar 14 16:42:52 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 14 Mar 2025 16:42:52 GMT Subject: RFR: 8352066: JVM.commit() and JVM.flush() exhibit race conditions against JFR epochs In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 14:55:40 GMT, Markus Gr?nlund wrote: > Greetings, > > This change set removes some race conditions involving JFR epochs. For details, please see the JIRA issue. > > Testing: jdk_jfr, TestChunkIntegrity testing > > Thanks > Markus I noticed that a boolean flag was added to the JfrCheckpointManager::on_rotation, but couldn't see where it was being used. Was this by design or a mistake? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24061#issuecomment-2725210691 From mgronlun at openjdk.org Fri Mar 14 17:56:02 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 14 Mar 2025 17:56:02 GMT Subject: RFR: 8352066: JVM.commit() and JVM.flush() exhibit race conditions against JFR epochs In-Reply-To: References: Message-ID: <1GIz3AwsXhrE3efn3ICvek1OrU5kZH57y2R1RS08c5w=.6647e664-297e-4550-8513-fdc3159dbd2f@github.com> On Fri, 14 Mar 2025 14:55:40 GMT, Markus Gr?nlund wrote: > Greetings, > > This change set removes some race conditions involving JFR epochs. For details, please see the JIRA issue. > > Testing: jdk_jfr, TestChunkIntegrity testing > > Thanks > Markus > I noticed a boolean flag was added to the JfrCheckpointManager::on_rotation, but I couldn't see where it was used. Was this by design or a mistake? Good, you noticed, and I forgot to describe this. I am adding the notify_threads() call also for Safepoint::clear(), not only for Safepoint::write(), to ensure ongoing commits are also aborted when a new physical recording starts. Should a thread, for example, get severely unscheduled after, let's say, returning from, or get stuck in the VM for a more extended period during a commit. It seems very unlikely to be necessary now that I am writing this, but it's another "clearing" activity when a physical recording begins. I don't have tangible proof that is not necessary yet. If we find out it's not needed later, we can remove it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24061#issuecomment-2725386494 From mgronlun at openjdk.org Fri Mar 14 18:35:57 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 14 Mar 2025 18:35:57 GMT Subject: RFR: 8351992: JFR: Improve robustness of the SettingControl examples In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:57:32 GMT, Erik Gahlin wrote: > Could I have a review of PR that improves the robustness of the SettingControl examples. > > Testing: jdk/jdk/jfr + tier1 > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24056#pullrequestreview-2686385062 From mgronlun at openjdk.org Fri Mar 14 18:38:26 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 14 Mar 2025 18:38:26 GMT Subject: RFR: 8352066: JVM.commit() and JVM.flush() exhibit race conditions against JFR epochs [v2] In-Reply-To: References: Message-ID: > Greetings, > > This change set removes some race conditions involving JFR epochs. For details, please see the JIRA issue. > > Testing: jdk_jfr, TestChunkIntegrity testing > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: restore checkpoint manager on_rotation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24061/files - new: https://git.openjdk.org/jdk/pull/24061/files/2f4d1827..349045dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24061&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24061&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24061.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24061/head:pull/24061 PR: https://git.openjdk.org/jdk/pull/24061 From egahlin at openjdk.org Fri Mar 14 18:38:26 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 14 Mar 2025 18:38:26 GMT Subject: RFR: 8352066: JVM.commit() and JVM.flush() exhibit race conditions against JFR epochs [v2] In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 18:35:06 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> This change set removes some race conditions involving JFR epochs. For details, please see the JIRA issue. >> >> Testing: jdk_jfr, TestChunkIntegrity testing >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > restore checkpoint manager on_rotation Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24061#pullrequestreview-2686490467 From mgronlun at openjdk.org Fri Mar 14 18:38:26 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 14 Mar 2025 18:38:26 GMT Subject: RFR: 8352066: JVM.commit() and JVM.flush() exhibit race conditions against JFR epochs In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 14:55:40 GMT, Markus Gr?nlund wrote: > Greetings, > > This change set removes some race conditions involving JFR epochs. For details, please see the JIRA issue. > > Testing: jdk_jfr, TestChunkIntegrity testing > > Thanks > Markus > I noticed that a boolean flag was added to the JfrCheckpointManager::on_rotation, but couldn't see where it was being used. Was this by design or a mistake? These are remnants from a previous iteration. Thanks for noticing. I will remove it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24061#issuecomment-2725405512 From lmesnik at openjdk.org Sat Mar 15 00:05:01 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 15 Mar 2025 00:05:01 GMT Subject: RFR: 8352096: Test jdk/jfr/event/profiling/TestFullStackTrace.java shouldn't be executed with -XX:+DeoptimizeALot Message-ID: The test create a lot of threads long stacks and overhead of often deoptimization with DeoptimizeALot causes timeouts. ------------- Commit messages: - test fixed Changes: https://git.openjdk.org/jdk/pull/24070/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24070&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352096 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24070.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24070/head:pull/24070 PR: https://git.openjdk.org/jdk/pull/24070 From egahlin at openjdk.org Sat Mar 15 09:38:51 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Sat, 15 Mar 2025 09:38:51 GMT Subject: RFR: 8352096: Test jdk/jfr/event/profiling/TestFullStackTrace.java shouldn't be executed with -XX:+DeoptimizeALot In-Reply-To: References: Message-ID: On Sat, 15 Mar 2025 00:00:05 GMT, Leonid Mesnik wrote: > The test create a lot of threads long stacks and overhead of often deoptimization with DeoptimizeALot causes timeouts. Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24070#pullrequestreview-2687561442 From egahlin at openjdk.org Sun Mar 16 21:50:07 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Sun, 16 Mar 2025 21:50:07 GMT Subject: Integrated: 8351992: JFR: Improve robustness of the SettingControl examples In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:57:32 GMT, Erik Gahlin wrote: > Could I have a review of PR that improves the robustness of the SettingControl examples. > > Testing: jdk/jdk/jfr + tier1 > > Thanks > Erik This pull request has now been integrated. Changeset: 63bf7918 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/63bf79183d27d79333c4ab58dbec1820e935f426 Stats: 42 lines in 2 files changed: 31 ins; 0 del; 11 mod 8351992: JFR: Improve robustness of the SettingControl examples Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/24056 From duke at openjdk.org Sun Mar 16 23:48:53 2025 From: duke at openjdk.org (Abdelhak Zaaim) Date: Sun, 16 Mar 2025 23:48:53 GMT Subject: RFR: 8352096: Test jdk/jfr/event/profiling/TestFullStackTrace.java shouldn't be executed with -XX:+DeoptimizeALot In-Reply-To: References: Message-ID: On Sat, 15 Mar 2025 00:00:05 GMT, Leonid Mesnik wrote: > The test create a lot of threads long stacks and overhead of often deoptimization with DeoptimizeALot causes timeouts. Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/24070#pullrequestreview-2688864043 From mgronlun at openjdk.org Mon Mar 17 09:59:01 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 17 Mar 2025 09:59:01 GMT Subject: Integrated: 8351967: JFR: AnnotationIterator should handle num_annotations = 0 In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 18:03:05 GMT, Markus Gr?nlund wrote: > Greetings, > > A tiny adjustment to cover a corner case related to the processing of the RuntimeVisibleAnnotations attribute. > > Testing: jdk_jfr > > Thanks > Markus This pull request has now been integrated. Changeset: 2eecf159 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/2eecf159afac32fe3a8141aec467d83cb63ef92b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8351967: JFR: AnnotationIterator should handle num_annotations = 0 Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/24037 From mgronlun at openjdk.org Mon Mar 17 10:07:03 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 17 Mar 2025 10:07:03 GMT Subject: Integrated: 8351976: assert(vthread_epoch == current_epoch) failed: invariant In-Reply-To: <4Jh42AViCPQIfaDyGquZmGAI5v7i5_tCaAxRSTi-caI=.db438a61-0f98-46a9-ad65-fd9126978304@github.com> References: <4Jh42AViCPQIfaDyGquZmGAI5v7i5_tCaAxRSTi-caI=.db438a61-0f98-46a9-ad65-fd9126978304@github.com> Message-ID: On Thu, 13 Mar 2025 20:59:31 GMT, Markus Gr?nlund wrote: > Greetings, > > This fix adjusts for an epoch mismatch for excluded virtual threads that become included after being mounted. The JIRA issue has more details. > > Testing: jdk_jfr, stress testing > > Thanks > Markus This pull request has now been integrated. Changeset: e5666f56 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/e5666f56ff6993cbfe52d91e5cadcb4d0b8f4ec2 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8351976: assert(vthread_epoch == current_epoch) failed: invariant Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/24041 From egahlin at openjdk.org Mon Mar 17 10:35:01 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 17 Mar 2025 10:35:01 GMT Subject: Integrated: 8351999: JFR: Incorrect scaling of throttled values In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 01:52:15 GMT, Erik Gahlin wrote: > Could I have a review of a PR that fixes an incorrect scaling of samples for the ThrottleSetting. > > Testing: jdk/jdk/jfr > > Thanks > Erik This pull request has now been integrated. Changeset: 0450ba9b Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/0450ba9b65d0a41d086d04554e3f9c3852345267 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8351999: JFR: Incorrect scaling of throttled values Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/24045 From mgronlun at openjdk.org Mon Mar 17 10:43:56 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 17 Mar 2025 10:43:56 GMT Subject: RFR: 8351995: JFR: Leftovers from removal of Security Manager In-Reply-To: <1CDZGleD4HS1WKiGAkshKTy2ResVB4UCP8VINGcw1m4=.d7788ddb-0857-4723-bd4c-9a45f30b0995@github.com> References: <1CDZGleD4HS1WKiGAkshKTy2ResVB4UCP8VINGcw1m4=.d7788ddb-0857-4723-bd4c-9a45f30b0995@github.com> Message-ID: On Fri, 14 Mar 2025 01:03:11 GMT, Erik Gahlin wrote: > Could I have a review of a PR that removes leftovers from the removal of the Security Manager. > > Testing: jdk/jdk/jfr + tier1 > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24044#pullrequestreview-2689995360 From mgronlun at openjdk.org Mon Mar 17 10:50:00 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 17 Mar 2025 10:50:00 GMT Subject: Integrated: 8352066: JVM.commit() and JVM.flush() exhibit race conditions against JFR epochs In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 14:55:40 GMT, Markus Gr?nlund wrote: > Greetings, > > This change set removes some race conditions involving JFR epochs. For details, please see the JIRA issue. > > Testing: jdk_jfr, TestChunkIntegrity testing > > Thanks > Markus This pull request has now been integrated. Changeset: d207ed3f Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/d207ed3f7cb810e3c0c8a8cd4d9aaa65164c6d16 Stats: 59 lines in 8 files changed: 3 ins; 36 del; 20 mod 8352066: JVM.commit() and JVM.flush() exhibit race conditions against JFR epochs Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/24061 From egahlin at openjdk.org Mon Mar 17 15:31:57 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 17 Mar 2025 15:31:57 GMT Subject: Integrated: 8351995: JFR: Leftovers from removal of Security Manager In-Reply-To: <1CDZGleD4HS1WKiGAkshKTy2ResVB4UCP8VINGcw1m4=.d7788ddb-0857-4723-bd4c-9a45f30b0995@github.com> References: <1CDZGleD4HS1WKiGAkshKTy2ResVB4UCP8VINGcw1m4=.d7788ddb-0857-4723-bd4c-9a45f30b0995@github.com> Message-ID: On Fri, 14 Mar 2025 01:03:11 GMT, Erik Gahlin wrote: > Could I have a review of a PR that removes leftovers from the removal of the Security Manager. > > Testing: jdk/jdk/jfr + tier1 > > Thanks > Erik This pull request has now been integrated. Changeset: d68775d7 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/d68775d7118c926cacb7e9e4c02b85bdb0705521 Stats: 129 lines in 7 files changed: 0 ins; 127 del; 2 mod 8351995: JFR: Leftovers from removal of Security Manager Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/24044 From lmesnik at openjdk.org Mon Mar 17 16:30:07 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 17 Mar 2025 16:30:07 GMT Subject: Integrated: 8352096: Test jdk/jfr/event/profiling/TestFullStackTrace.java shouldn't be executed with -XX:+DeoptimizeALot In-Reply-To: References: Message-ID: On Sat, 15 Mar 2025 00:00:05 GMT, Leonid Mesnik wrote: > The test create a lot of threads long stacks and overhead of often deoptimization with DeoptimizeALot causes timeouts. This pull request has now been integrated. Changeset: 4c6a523e Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/4c6a523e89e077a6697abb30863eb70bc977757c Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8352096: Test jdk/jfr/event/profiling/TestFullStackTrace.java shouldn't be executed with -XX:+DeoptimizeALot Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/24070