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: <N9mkPPHT9zjVXyPKBbL85I1xaY8TbdBRONAMMEbfN3c=.c3abcb61-2e8b-4b2b-93fb-8534d9607698@github.com>

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: <N9mkPPHT9zjVXyPKBbL85I1xaY8TbdBRONAMMEbfN3c=.c3abcb61-2e8b-4b2b-93fb-8534d9607698@github.com>
References: <N9mkPPHT9zjVXyPKBbL85I1xaY8TbdBRONAMMEbfN3c=.c3abcb61-2e8b-4b2b-93fb-8534d9607698@github.com>
Message-ID: <NipISXG2dRT_CH-AU14to-mvEvZPJ2j6nrc2H1JF84I=.abbd03c0-7a89-42f5-9740-b1ff27434805@github.com>

On Mon, 3 Mar 2025 18:07:54 GMT, Erik Gahlin <egahlin at openjdk.org> 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: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>

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: <N9mkPPHT9zjVXyPKBbL85I1xaY8TbdBRONAMMEbfN3c=.c3abcb61-2e8b-4b2b-93fb-8534d9607698@github.com>
References: <N9mkPPHT9zjVXyPKBbL85I1xaY8TbdBRONAMMEbfN3c=.c3abcb61-2e8b-4b2b-93fb-8534d9607698@github.com>
Message-ID: <QP4V_XsvmsrRBwP2EbdNHkqzobGSRTtay-60ncfv_O0=.69cc7f0b-ab86-4e1e-975f-c5affa0f66c9@github.com>

On Mon, 3 Mar 2025 18:07:54 GMT, Erik Gahlin <egahlin at openjdk.org> 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 <egahlin at openjdk.org>
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: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
References: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
Message-ID: <OcMMeQrMEn00wPE_s-O2jzZDrAvTeqfxym5WfJan5DY=.abb5e8c6-6507-4338-bd73-4ecd554e8406@github.com>

On Tue, 4 Mar 2025 11:03:03 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
References: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
Message-ID: <22YA1wEPW1HsFZor10Ltv2NV0x0HUUfMvY6QALzSQOw=.a72abf61-713d-4cd2-b0f1-f078917e2717@github.com>

On Tue, 4 Mar 2025 11:03:03 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
 <22YA1wEPW1HsFZor10Ltv2NV0x0HUUfMvY6QALzSQOw=.a72abf61-713d-4cd2-b0f1-f078917e2717@github.com>
Message-ID: <QqpNmXF9y_3ZciLwSWpWUKZcw_g1HYmpFEBCTKlCfGk=.2e057856-104b-458d-8119-42d8f17c0633@github.com>

On Wed, 5 Mar 2025 09:01:36 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
References: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
Message-ID: <d70uCmaoBaOLtgta_LMUdq3bSGvcsgPKAYgOToZFav4=.04140e7d-dea5-439c-bc01-44bec8e629bc@github.com>

> 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: <QqpNmXF9y_3ZciLwSWpWUKZcw_g1HYmpFEBCTKlCfGk=.2e057856-104b-458d-8119-42d8f17c0633@github.com>
References: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
 <22YA1wEPW1HsFZor10Ltv2NV0x0HUUfMvY6QALzSQOw=.a72abf61-713d-4cd2-b0f1-f078917e2717@github.com>
 <QqpNmXF9y_3ZciLwSWpWUKZcw_g1HYmpFEBCTKlCfGk=.2e057856-104b-458d-8119-42d8f17c0633@github.com>
Message-ID: <1EoybDAJmQMq5646DaR1s--FnY1x6NKDh1xv1fLevhc=.916c0100-c0d8-4a3d-aad7-64612ec2323b@github.com>

On Wed, 5 Mar 2025 20:30:19 GMT, Erik Gahlin <egahlin at openjdk.org> 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: <d70uCmaoBaOLtgta_LMUdq3bSGvcsgPKAYgOToZFav4=.04140e7d-dea5-439c-bc01-44bec8e629bc@github.com>
References: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
 <d70uCmaoBaOLtgta_LMUdq3bSGvcsgPKAYgOToZFav4=.04140e7d-dea5-439c-bc01-44bec8e629bc@github.com>
Message-ID: <vSWvMqrduSCfdZKuIKmxtm3znv68jKHvVQxgQKDVXK4=.dd4ddfad-deb6-4d9b-9533-fe3b76c355ab@github.com>

On Thu, 6 Mar 2025 10:55:36 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <vSWvMqrduSCfdZKuIKmxtm3znv68jKHvVQxgQKDVXK4=.dd4ddfad-deb6-4d9b-9533-fe3b76c355ab@github.com>
References: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
 <d70uCmaoBaOLtgta_LMUdq3bSGvcsgPKAYgOToZFav4=.04140e7d-dea5-439c-bc01-44bec8e629bc@github.com>
 <vSWvMqrduSCfdZKuIKmxtm3znv68jKHvVQxgQKDVXK4=.dd4ddfad-deb6-4d9b-9533-fe3b76c355ab@github.com>
Message-ID: <awmnG-mj-WP65ocRjeo9MHwmnTLI16IYmoEtEIBPM44=.609859c6-a53c-44fa-965e-a015a5ec3fd4@github.com>

On Fri, 7 Mar 2025 12:57:55 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <MFjgG4CTjeh2t1eI4UR0CzllalSRlEWoZuBnWdUHvxQ=.232b2320-61b5-4157-acae-30ac460d2097@github.com>

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: <awmnG-mj-WP65ocRjeo9MHwmnTLI16IYmoEtEIBPM44=.609859c6-a53c-44fa-965e-a015a5ec3fd4@github.com>
References: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
 <d70uCmaoBaOLtgta_LMUdq3bSGvcsgPKAYgOToZFav4=.04140e7d-dea5-439c-bc01-44bec8e629bc@github.com>
 <vSWvMqrduSCfdZKuIKmxtm3znv68jKHvVQxgQKDVXK4=.dd4ddfad-deb6-4d9b-9533-fe3b76c355ab@github.com>
 <awmnG-mj-WP65ocRjeo9MHwmnTLI16IYmoEtEIBPM44=.609859c6-a53c-44fa-965e-a015a5ec3fd4@github.com>
Message-ID: <IWZXoGOatHTa3Tfz1dOrp-Rh63qF6h5VTDwOfzFyDP0=.ffbde41a-21dc-41a3-8c81-f62b4ed02db7@github.com>

On Fri, 7 Mar 2025 15:50:09 GMT, Erik Gahlin <egahlin at openjdk.org> 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: <MFjgG4CTjeh2t1eI4UR0CzllalSRlEWoZuBnWdUHvxQ=.232b2320-61b5-4157-acae-30ac460d2097@github.com>
References: <MFjgG4CTjeh2t1eI4UR0CzllalSRlEWoZuBnWdUHvxQ=.232b2320-61b5-4157-acae-30ac460d2097@github.com>
Message-ID: <QPVqA2kBtZK3IT9uYCLdaUCILaLXRAIUutnIsuBSAaQ=.1486985c-bcc8-49dc-9e96-e6f5a9f4ee32@github.com>

> 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: <d70uCmaoBaOLtgta_LMUdq3bSGvcsgPKAYgOToZFav4=.04140e7d-dea5-439c-bc01-44bec8e629bc@github.com>
References: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
 <d70uCmaoBaOLtgta_LMUdq3bSGvcsgPKAYgOToZFav4=.04140e7d-dea5-439c-bc01-44bec8e629bc@github.com>
Message-ID: <93qcHLRS8Wtc6HB6XXy4QPW4avL07VC-6nMaydOt1sQ=.9e456450-c6ea-41d3-9ba6-a670f62fdda2@github.com>

On Thu, 6 Mar 2025 10:55:36 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <d70uCmaoBaOLtgta_LMUdq3bSGvcsgPKAYgOToZFav4=.04140e7d-dea5-439c-bc01-44bec8e629bc@github.com>
References: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
 <d70uCmaoBaOLtgta_LMUdq3bSGvcsgPKAYgOToZFav4=.04140e7d-dea5-439c-bc01-44bec8e629bc@github.com>
Message-ID: <Fv5NEk4Nr6t4-Mkp3hqJsJyPyB4HhkaWMK2kKr9QRAY=.4a853dcd-5438-440c-9c83-80a009754b2a@github.com>

On Thu, 6 Mar 2025 10:55:36 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
References: <SOxgWgJlIp4ASyCOgYZaJZZgtB9SGEtIuvk3w4-4xLU=.0aa5ca98-6962-47bc-908f-c735984ceb8c@github.com>
Message-ID: <26lopZKgldRNBIux8-3feRtDx3klBGn8zPR7ExaMVjI=.f89a8d69-f0d8-4a83-8ec8-836ce8176cbd@github.com>

On Tue, 4 Mar 2025 11:03:03 GMT, Aleksey Shipilev <shade at openjdk.org> 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 <shade at openjdk.org>
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: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>

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: <MFjgG4CTjeh2t1eI4UR0CzllalSRlEWoZuBnWdUHvxQ=.232b2320-61b5-4157-acae-30ac460d2097@github.com>
References: <MFjgG4CTjeh2t1eI4UR0CzllalSRlEWoZuBnWdUHvxQ=.232b2320-61b5-4157-acae-30ac460d2097@github.com>
Message-ID: <p5vueJQ2dZeTVBdXA2M-YK7SAMQMSOhWjZ1zIDf_L8g=.9a2d77e0-4b81-4fa2-ba27-e0fa861ab492@github.com>

> 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: <p5vueJQ2dZeTVBdXA2M-YK7SAMQMSOhWjZ1zIDf_L8g=.9a2d77e0-4b81-4fa2-ba27-e0fa861ab492@github.com>
References: <MFjgG4CTjeh2t1eI4UR0CzllalSRlEWoZuBnWdUHvxQ=.232b2320-61b5-4157-acae-30ac460d2097@github.com>
 <p5vueJQ2dZeTVBdXA2M-YK7SAMQMSOhWjZ1zIDf_L8g=.9a2d77e0-4b81-4fa2-ba27-e0fa861ab492@github.com>
Message-ID: <988J9liS9iRgyTw5YDsq0ys7nT-8PNZzuGk3czhZngg=.43d9cd54-34a5-4143-b374-1b4b4b2687e7@github.com>

On Thu, 13 Mar 2025 13:39:38 GMT, Erik Gahlin <egahlin at openjdk.org> 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: <MFjgG4CTjeh2t1eI4UR0CzllalSRlEWoZuBnWdUHvxQ=.232b2320-61b5-4157-acae-30ac460d2097@github.com>
References: <MFjgG4CTjeh2t1eI4UR0CzllalSRlEWoZuBnWdUHvxQ=.232b2320-61b5-4157-acae-30ac460d2097@github.com>
Message-ID: <YdjPJjAr5b0INKTg0j1TsJfVjk5AbdY2oTIvulcM5Do=.c15cfda2-6dec-412b-9af9-f97c2619d48a@github.com>

> 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: <HsDeK-jj6dtzMICWstA9DK9sdEHpUuwZuW9ZPGdJiyU=.00effeba-b82e-446f-abd9-c9b7b96a70dd@github.com>

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: <HsDeK-jj6dtzMICWstA9DK9sdEHpUuwZuW9ZPGdJiyU=.00effeba-b82e-446f-abd9-c9b7b96a70dd@github.com>
References: <HsDeK-jj6dtzMICWstA9DK9sdEHpUuwZuW9ZPGdJiyU=.00effeba-b82e-446f-abd9-c9b7b96a70dd@github.com>
Message-ID: <LcXsweTd-xnZwKNmI1KSVL5X_kCFvHnN0tG_p3qE714=.255881fc-cf7a-4158-b166-f40a6a264948@github.com>

On Thu, 13 Mar 2025 18:03:05 GMT, Markus Gr?nlund <mgronlun at openjdk.org> 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: <YdjPJjAr5b0INKTg0j1TsJfVjk5AbdY2oTIvulcM5Do=.c15cfda2-6dec-412b-9af9-f97c2619d48a@github.com>
References: <MFjgG4CTjeh2t1eI4UR0CzllalSRlEWoZuBnWdUHvxQ=.232b2320-61b5-4157-acae-30ac460d2097@github.com>
 <YdjPJjAr5b0INKTg0j1TsJfVjk5AbdY2oTIvulcM5Do=.c15cfda2-6dec-412b-9af9-f97c2619d48a@github.com>
Message-ID: <fiYJ0jHSouTv2L_qx844XVXGiVS2qQ6cLCHL2_JAzR4=.577cfca5-a861-46ab-856f-b25a2d81bfeb@github.com>

On Thu, 13 Mar 2025 15:14:21 GMT, Erik Gahlin <egahlin at openjdk.org> 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: <MFjgG4CTjeh2t1eI4UR0CzllalSRlEWoZuBnWdUHvxQ=.232b2320-61b5-4157-acae-30ac460d2097@github.com>
References: <MFjgG4CTjeh2t1eI4UR0CzllalSRlEWoZuBnWdUHvxQ=.232b2320-61b5-4157-acae-30ac460d2097@github.com>
Message-ID: <IfO9HgMytNkruhltCGXBzaD7SyxK8fFvICQ_husAbGI=.c2711239-0486-4d9c-bdef-ade0eddfae2a@github.com>

On Sun, 9 Mar 2025 23:34:39 GMT, Erik Gahlin <egahlin at openjdk.org> 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 <egahlin at openjdk.org>
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 <mgronlun at openjdk.org> 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: <i3c7rxQtbvy8FyeJEkeg_Km1gs38uFklAsUGpp1uSfg=.1e7c47d3-c50e-45b7-8b68-a489e65bd92f@github.com>

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: <i3c7rxQtbvy8FyeJEkeg_Km1gs38uFklAsUGpp1uSfg=.1e7c47d3-c50e-45b7-8b68-a489e65bd92f@github.com>
References: <i3c7rxQtbvy8FyeJEkeg_Km1gs38uFklAsUGpp1uSfg=.1e7c47d3-c50e-45b7-8b68-a489e65bd92f@github.com>
Message-ID: <t8HjMgl5e2B2hFqOCiy5ta-PK5rCdWoLCc44rhefrk8=.c15c0b1a-2830-4aa8-a304-4bb5ad651c69@github.com>

On Fri, 14 Mar 2025 01:52:15 GMT, Erik Gahlin <egahlin at openjdk.org> 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: <lP5SI-HsQpcSWVhUGC1t66tawxjxDdCTVDVwQX8cvtI=.db040113-66d3-454c-857c-dd0b85c582a9@github.com>

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: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>
References: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>
Message-ID: <Xt2ThwDjnuvu-MAdTEZfRLFhW23XmrpcFBXbRnavz5U=.aa06bc60-b3d1-4e1d-af6b-0b6d81760890@github.com>

On Thu, 13 Mar 2025 10:24:08 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <WvdN8VJSdbl6C1cJ0aAvNHfyjN8_l04orACMx_zfSlY=.553487c0-0e6c-487c-a3c0-f5cc2363d649@github.com>

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: <t8HjMgl5e2B2hFqOCiy5ta-PK5rCdWoLCc44rhefrk8=.c15c0b1a-2830-4aa8-a304-4bb5ad651c69@github.com>
References: <i3c7rxQtbvy8FyeJEkeg_Km1gs38uFklAsUGpp1uSfg=.1e7c47d3-c50e-45b7-8b68-a489e65bd92f@github.com>
 <t8HjMgl5e2B2hFqOCiy5ta-PK5rCdWoLCc44rhefrk8=.c15c0b1a-2830-4aa8-a304-4bb5ad651c69@github.com>
Message-ID: <5w52Lf3JUgGHwUYbjmW7zAce1Vic5T4EKWOd0vSLOB8=.25b14773-cabd-42d4-83c1-e07adb648665@github.com>

On Fri, 14 Mar 2025 12:16:40 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <lP5SI-HsQpcSWVhUGC1t66tawxjxDdCTVDVwQX8cvtI=.db040113-66d3-454c-857c-dd0b85c582a9@github.com>
References: <lP5SI-HsQpcSWVhUGC1t66tawxjxDdCTVDVwQX8cvtI=.db040113-66d3-454c-857c-dd0b85c582a9@github.com>
Message-ID: <XlWUZUQWvbkwcxwma1Zu8wU0mE073eO6F8YVp8PQC7c=.b99f3d20-1c43-431a-b9ed-1d220a4b147b@github.com>

On Fri, 14 Mar 2025 14:55:40 GMT, Markus Gr?nlund <mgronlun at openjdk.org> 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: <lP5SI-HsQpcSWVhUGC1t66tawxjxDdCTVDVwQX8cvtI=.db040113-66d3-454c-857c-dd0b85c582a9@github.com>
References: <lP5SI-HsQpcSWVhUGC1t66tawxjxDdCTVDVwQX8cvtI=.db040113-66d3-454c-857c-dd0b85c582a9@github.com>
Message-ID: <1GIz3AwsXhrE3efn3ICvek1OrU5kZH57y2R1RS08c5w=.6647e664-297e-4550-8513-fdc3159dbd2f@github.com>

On Fri, 14 Mar 2025 14:55:40 GMT, Markus Gr?nlund <mgronlun at openjdk.org> 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: <WvdN8VJSdbl6C1cJ0aAvNHfyjN8_l04orACMx_zfSlY=.553487c0-0e6c-487c-a3c0-f5cc2363d649@github.com>
References: <WvdN8VJSdbl6C1cJ0aAvNHfyjN8_l04orACMx_zfSlY=.553487c0-0e6c-487c-a3c0-f5cc2363d649@github.com>
Message-ID: <i11xuTVeT-OXYlUAVtaHVK10DFJlrRbRmFI-Fr4iOMY=.766e86f2-0640-4498-aef6-d98894ed6167@github.com>

On Fri, 14 Mar 2025 11:57:32 GMT, Erik Gahlin <egahlin at openjdk.org> 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: <lP5SI-HsQpcSWVhUGC1t66tawxjxDdCTVDVwQX8cvtI=.db040113-66d3-454c-857c-dd0b85c582a9@github.com>
References: <lP5SI-HsQpcSWVhUGC1t66tawxjxDdCTVDVwQX8cvtI=.db040113-66d3-454c-857c-dd0b85c582a9@github.com>
Message-ID: <eugXZo0U2TlH7FyOPBaI47HGctzTjyjyAI05hAJgE1g=.44936e16-a176-4945-b348-f4b799f32326@github.com>

> 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: <eugXZo0U2TlH7FyOPBaI47HGctzTjyjyAI05hAJgE1g=.44936e16-a176-4945-b348-f4b799f32326@github.com>
References: <lP5SI-HsQpcSWVhUGC1t66tawxjxDdCTVDVwQX8cvtI=.db040113-66d3-454c-857c-dd0b85c582a9@github.com>
 <eugXZo0U2TlH7FyOPBaI47HGctzTjyjyAI05hAJgE1g=.44936e16-a176-4945-b348-f4b799f32326@github.com>
Message-ID: <dHecGc65neA-1lQbKB18on6WflhaaK3ny07Kgm39s_0=.cf7e1bee-0a7b-4686-95f1-df767469df7c@github.com>

On Fri, 14 Mar 2025 18:35:06 GMT, Markus Gr?nlund <mgronlun at openjdk.org> 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: <lP5SI-HsQpcSWVhUGC1t66tawxjxDdCTVDVwQX8cvtI=.db040113-66d3-454c-857c-dd0b85c582a9@github.com>
References: <lP5SI-HsQpcSWVhUGC1t66tawxjxDdCTVDVwQX8cvtI=.db040113-66d3-454c-857c-dd0b85c582a9@github.com>
Message-ID: <yH_hGNucpVB7C2EyzB6isTswadL3pyCRTkroAA-d9IE=.07a2c1ba-566f-4d35-8960-b95e68e9fc1b@github.com>

On Fri, 14 Mar 2025 14:55:40 GMT, Markus Gr?nlund <mgronlun at openjdk.org> 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: <Icadm25lbWbQ0KWNnIOTHiI0CslZTkS5_OeRGdkifCI=.8d65e386-a5c7-4a60-b586-2f5b347a7643@github.com>

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: <Icadm25lbWbQ0KWNnIOTHiI0CslZTkS5_OeRGdkifCI=.8d65e386-a5c7-4a60-b586-2f5b347a7643@github.com>
References: <Icadm25lbWbQ0KWNnIOTHiI0CslZTkS5_OeRGdkifCI=.8d65e386-a5c7-4a60-b586-2f5b347a7643@github.com>
Message-ID: <fbjeaZcwc-gq5VeajsdTyfHyZh_Q3RAClsrpJS_QBUU=.bb932c8b-3c7f-41c8-95ab-c207c4765316@github.com>

On Sat, 15 Mar 2025 00:00:05 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <WvdN8VJSdbl6C1cJ0aAvNHfyjN8_l04orACMx_zfSlY=.553487c0-0e6c-487c-a3c0-f5cc2363d649@github.com>
References: <WvdN8VJSdbl6C1cJ0aAvNHfyjN8_l04orACMx_zfSlY=.553487c0-0e6c-487c-a3c0-f5cc2363d649@github.com>
Message-ID: <itQxK3Ew4TYpYjQOrhfKybKLRyeyDodccLeJtgLCMCo=.53f799e8-7f15-49c6-9cda-5fe1ad8bdd49@github.com>

On Fri, 14 Mar 2025 11:57:32 GMT, Erik Gahlin <egahlin at openjdk.org> 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 <egahlin at openjdk.org>
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: <Icadm25lbWbQ0KWNnIOTHiI0CslZTkS5_OeRGdkifCI=.8d65e386-a5c7-4a60-b586-2f5b347a7643@github.com>
References: <Icadm25lbWbQ0KWNnIOTHiI0CslZTkS5_OeRGdkifCI=.8d65e386-a5c7-4a60-b586-2f5b347a7643@github.com>
Message-ID: <jXWYds4RdKSaZFnH_a8dl7qMsYjpeK1PKZfLxMQ08Mw=.2225506f-9ecd-4c7b-b965-1c2f68fdfe1d@github.com>

On Sat, 15 Mar 2025 00:00:05 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <HsDeK-jj6dtzMICWstA9DK9sdEHpUuwZuW9ZPGdJiyU=.00effeba-b82e-446f-abd9-c9b7b96a70dd@github.com>
References: <HsDeK-jj6dtzMICWstA9DK9sdEHpUuwZuW9ZPGdJiyU=.00effeba-b82e-446f-abd9-c9b7b96a70dd@github.com>
Message-ID: <MbFKf7d22kK4GzCGxUxWq1p_Z_bPnu4oMVkuK_Fq6yE=.87b69c58-a4db-4cf1-87cc-23ad941e7c7d@github.com>

On Thu, 13 Mar 2025 18:03:05 GMT, Markus Gr?nlund <mgronlun at openjdk.org> 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 <mgronlun at openjdk.org>
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: <MZQwj2hixXH0KsXaOjetxYDh0zmVISAJTspJuoyQ5gI=.9064908a-859c-483a-847e-9b3cc50334d7@github.com>

On Thu, 13 Mar 2025 20:59:31 GMT, Markus Gr?nlund <mgronlun at openjdk.org> 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 <mgronlun at openjdk.org>
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: <i3c7rxQtbvy8FyeJEkeg_Km1gs38uFklAsUGpp1uSfg=.1e7c47d3-c50e-45b7-8b68-a489e65bd92f@github.com>
References: <i3c7rxQtbvy8FyeJEkeg_Km1gs38uFklAsUGpp1uSfg=.1e7c47d3-c50e-45b7-8b68-a489e65bd92f@github.com>
Message-ID: <ZLDQ5w0RfqwdCRYUUjBtm8B-Gzrb588Oke1J0J0sC50=.03e979a6-a895-4d57-95d8-7b3ca7c79d4c@github.com>

On Fri, 14 Mar 2025 01:52:15 GMT, Erik Gahlin <egahlin at openjdk.org> 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 <egahlin at openjdk.org>
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: <qYqXZnShM5dF82jTk-F6i0ZB_L16GdWw6Z2YHtPYZyI=.b5896e0b-e207-49f7-9f9f-e1aa5d46b652@github.com>

On Fri, 14 Mar 2025 01:03:11 GMT, Erik Gahlin <egahlin at openjdk.org> 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: <lP5SI-HsQpcSWVhUGC1t66tawxjxDdCTVDVwQX8cvtI=.db040113-66d3-454c-857c-dd0b85c582a9@github.com>
References: <lP5SI-HsQpcSWVhUGC1t66tawxjxDdCTVDVwQX8cvtI=.db040113-66d3-454c-857c-dd0b85c582a9@github.com>
Message-ID: <Tl7iv6Gdny2sxqMX35w59OiLYMTw4Rm6nGXuJR8eIxI=.5b4dae0d-cac6-4888-86fb-e48f7c960914@github.com>

On Fri, 14 Mar 2025 14:55:40 GMT, Markus Gr?nlund <mgronlun at openjdk.org> 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 <mgronlun at openjdk.org>
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: <olCph6LRQbiQ8XcILCZB1pP85EJ9i3BoRToTECfqxB4=.bd2aa458-f418-47ff-a8fc-dd1daa8d6fc7@github.com>

On Fri, 14 Mar 2025 01:03:11 GMT, Erik Gahlin <egahlin at openjdk.org> 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 <egahlin at openjdk.org>
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: <Icadm25lbWbQ0KWNnIOTHiI0CslZTkS5_OeRGdkifCI=.8d65e386-a5c7-4a60-b586-2f5b347a7643@github.com>
References: <Icadm25lbWbQ0KWNnIOTHiI0CslZTkS5_OeRGdkifCI=.8d65e386-a5c7-4a60-b586-2f5b347a7643@github.com>
Message-ID: <oP05tYJp3wzumdMXMgscLdWZ7TIoMokcl0V_rXSQtKQ=.391e643b-5c5b-45e9-8d5b-723c2f73f8fa@github.com>

On Sat, 15 Mar 2025 00:00:05 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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 <lmesnik at openjdk.org>
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