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

From syan at openjdk.org  Fri Mar 21 09:02:11 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Mar 2025 09:02:11 GMT
Subject: RFR: 8350386: Test TestCodeCacheFull.java fails with option
 -XX:-UseCodeCacheFlushing
In-Reply-To: <laAqUCgaqW5DnbmI7FhlXEfD6vBqd0BpcPPwBqpmRQA=.3f801860-3de4-48af-b033-6a066888e404@github.com>
References: <laAqUCgaqW5DnbmI7FhlXEfD6vBqd0BpcPPwBqpmRQA=.3f801860-3de4-48af-b033-6a066888e404@github.com>
Message-ID: <w_eY6wglBW4W84wM9CgsCFZDcG32ZCkDBvocE60v_5Q=.7135cb0a-2f17-4ea8-99d6-9afc52a1b499@github.com>

On Fri, 21 Feb 2025 03:31:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test jdk/jfr/event/compiler/TestCodeCacheFull.java fails with option `-XX:-UseCodeCacheFlushing`, because this test is incompatible with `-XX:-UseCodeCacheFlushing` when `-XX:+SegmentedCodeCache` is enable, the detail analyze has been recorded by [JDK-8350386](https://bugs.openjdk.org/browse/JDK-8350386). This PR add `-XX:+UseCodeCacheFlushing` JVM option to test header make this test run passes whenever test receive `-XX:-UseCodeCacheFlushing` from outside or not.
> 
> Change has been verified locally, test-fix only, no risk.

Hi, can anyone take look this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23721#issuecomment-2742729827

From tschatzl at openjdk.org  Fri Mar 21 09:51:18 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 21 Mar 2025 09:51:18 GMT
Subject: RFR: 8350386: Test TestCodeCacheFull.java fails with option
 -XX:-UseCodeCacheFlushing
In-Reply-To: <laAqUCgaqW5DnbmI7FhlXEfD6vBqd0BpcPPwBqpmRQA=.3f801860-3de4-48af-b033-6a066888e404@github.com>
References: <laAqUCgaqW5DnbmI7FhlXEfD6vBqd0BpcPPwBqpmRQA=.3f801860-3de4-48af-b033-6a066888e404@github.com>
Message-ID: <KELS4C_vU7GHtvXNiyfIdttqQfNwIoQzLCZQ5OpXZW0=.c901be22-2517-48b6-972c-e944a918e830@github.com>

On Fri, 21 Feb 2025 03:31:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test jdk/jfr/event/compiler/TestCodeCacheFull.java fails with option `-XX:-UseCodeCacheFlushing`, because this test is incompatible with `-XX:-UseCodeCacheFlushing` when `-XX:+SegmentedCodeCache` is enable, the detail analyze has been recorded by [JDK-8350386](https://bugs.openjdk.org/browse/JDK-8350386). This PR add `-XX:+UseCodeCacheFlushing` JVM option to test header make this test run passes whenever test receive `-XX:-UseCodeCacheFlushing` from outside or not.
> 
> Change has been verified locally, test-fix only, no risk.

test/jdk/jdk/jfr/event/compiler/TestCodeCacheFull.java line 48:

> 46:  * @run main/othervm -Xbootclasspath/a:.
> 47:  *     -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
> 48:  *     -XX:+UseCodeCacheFlushing

That is one option, what about having a

* @requires vm.opt.UseCodeCacheFlushing == null | vm.opt.UseCodeCacheFlushing == true

or

  * @requires @requires vm.opt.final.UseCodeCacheFlushing [== true]


instead to only run the test if the flag in question is not set or true, or the final value is true?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23721#discussion_r2007219517

From syan at openjdk.org  Sat Mar 22 04:00:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Mar 2025 04:00:53 GMT
Subject: RFR: 8350386: Test TestCodeCacheFull.java fails with option
 -XX:-UseCodeCacheFlushing [v2]
In-Reply-To: <laAqUCgaqW5DnbmI7FhlXEfD6vBqd0BpcPPwBqpmRQA=.3f801860-3de4-48af-b033-6a066888e404@github.com>
References: <laAqUCgaqW5DnbmI7FhlXEfD6vBqd0BpcPPwBqpmRQA=.3f801860-3de4-48af-b033-6a066888e404@github.com>
Message-ID: <hnMpW-m99y7EC1j2eHFxpSEOYvdtYYhdVoYeqjEQfUk=.0548c78c-7508-4d1a-990e-f02d8d447bdc@github.com>

> Hi all,
> 
> Test jdk/jfr/event/compiler/TestCodeCacheFull.java fails with option `-XX:-UseCodeCacheFlushing`, because this test is incompatible with `-XX:-UseCodeCacheFlushing` when `-XX:+SegmentedCodeCache` is enable, the detail analyze has been recorded by [JDK-8350386](https://bugs.openjdk.org/browse/JDK-8350386). This PR add `-XX:+UseCodeCacheFlushing` JVM option to test header make this test run passes whenever test receive `-XX:-UseCodeCacheFlushing` from outside or not.
> 
> Change has been verified locally, test-fix only, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Use "* @requires vm.opt.UseCodeCacheFlushing == null | vm.opt.UseCodeCacheFlushing == true" instead of enable UseCodeCacheFlushing in options

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23721/files
  - new: https://git.openjdk.org/jdk/pull/23721/files/5afda39f..cf9a4353

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23721&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23721&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23721.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23721/head:pull/23721

PR: https://git.openjdk.org/jdk/pull/23721

From syan at openjdk.org  Sat Mar 22 04:03:18 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Mar 2025 04:03:18 GMT
Subject: RFR: 8350386: Test TestCodeCacheFull.java fails with option
 -XX:-UseCodeCacheFlushing [v2]
In-Reply-To: <KELS4C_vU7GHtvXNiyfIdttqQfNwIoQzLCZQ5OpXZW0=.c901be22-2517-48b6-972c-e944a918e830@github.com>
References: <laAqUCgaqW5DnbmI7FhlXEfD6vBqd0BpcPPwBqpmRQA=.3f801860-3de4-48af-b033-6a066888e404@github.com>
 <KELS4C_vU7GHtvXNiyfIdttqQfNwIoQzLCZQ5OpXZW0=.c901be22-2517-48b6-972c-e944a918e830@github.com>
Message-ID: <3qjYztx_Q9iPRSUYZ8co2991Ppv7goaWhqiQYDrpT-I=.b254fcba-6ce6-4db5-9c04-8a9b8a09ab7b@github.com>

On Fri, 21 Mar 2025 09:48:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use "* @requires vm.opt.UseCodeCacheFlushing == null | vm.opt.UseCodeCacheFlushing == true" instead of enable UseCodeCacheFlushing in options
>
> test/jdk/jdk/jfr/event/compiler/TestCodeCacheFull.java line 48:
> 
>> 46:  * @run main/othervm -Xbootclasspath/a:.
>> 47:  *     -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
>> 48:  *     -XX:+UseCodeCacheFlushing
> 
> That is one option, what about having a
> 
> * @requires vm.opt.UseCodeCacheFlushing == null | vm.opt.UseCodeCacheFlushing == true
> 
> or
> 
>   * @requires @requires vm.opt.final.UseCodeCacheFlushing [== true]
> 
> 
> instead to only run the test if the flag in question is not set or true, or the final value is true?

Thanks, use `@requires` to check the flag is not set or true, is more elegant and more clear.

The PR has been updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23721#discussion_r2008643120

From syan at openjdk.org  Sat Mar 22 04:06:06 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Mar 2025 04:06:06 GMT
Subject: RFR: 8350386: Test TestCodeCacheFull.java fails with option
 -XX:-UseCodeCacheFlushing [v2]
In-Reply-To: <hnMpW-m99y7EC1j2eHFxpSEOYvdtYYhdVoYeqjEQfUk=.0548c78c-7508-4d1a-990e-f02d8d447bdc@github.com>
References: <laAqUCgaqW5DnbmI7FhlXEfD6vBqd0BpcPPwBqpmRQA=.3f801860-3de4-48af-b033-6a066888e404@github.com>
 <hnMpW-m99y7EC1j2eHFxpSEOYvdtYYhdVoYeqjEQfUk=.0548c78c-7508-4d1a-990e-f02d8d447bdc@github.com>
Message-ID: <uKeF73w1E61qU22zyaMgaJb8IxoIU7uyzqKG8nxTD7k=.1ea43692-58e1-4035-862e-da2f5cea50f4@github.com>

On Sat, 22 Mar 2025 04:00:53 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test jdk/jfr/event/compiler/TestCodeCacheFull.java fails with option `-XX:-UseCodeCacheFlushing`, because this test is incompatible with `-XX:-UseCodeCacheFlushing` when `-XX:+SegmentedCodeCache` is enable, the detail analyze has been recorded by [JDK-8350386](https://bugs.openjdk.org/browse/JDK-8350386). This PR add `* @requires vm.opt.UseCodeCacheFlushing == null | vm.opt.UseCodeCacheFlushing == true` to make sure `UseCodeCacheFlushing` is not set or set as true.
>> 
>> Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "* @requires vm.opt.UseCodeCacheFlushing == null | vm.opt.UseCodeCacheFlushing == true" instead of enable UseCodeCacheFlushing in options

PR description has been updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23721#issuecomment-2744966679

From egahlin at openjdk.org  Sun Mar 23 19:04:39 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 23 Mar 2025 19:04:39 GMT
Subject: RFR: 8352648: JFR: 'jfr query' should not be available in product
 builds
Message-ID: <NBQshQkn4MLhm-AiYHxnaTh6bBgVqQDKtKwti_7ewp8=.ab0ba70c-2537-453e-80a2-19d58ce70e59@github.com>

Could I have a review of a PR that removes the 'jfr query' command in product builds. The command was accidentally activated a couple of months ago, but it has never made it into a release.

Testing: tier1 + test/jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/24178/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24178&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352648
  Stats: 30 lines in 6 files changed: 26 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24178/head:pull/24178

PR: https://git.openjdk.org/jdk/pull/24178

From mgronlun at openjdk.org  Mon Mar 24 09:20:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 24 Mar 2025 09:20:08 GMT
Subject: RFR: 8352648: JFR: 'jfr query' should not be available in product
 builds
In-Reply-To: <NBQshQkn4MLhm-AiYHxnaTh6bBgVqQDKtKwti_7ewp8=.ab0ba70c-2537-453e-80a2-19d58ce70e59@github.com>
References: <NBQshQkn4MLhm-AiYHxnaTh6bBgVqQDKtKwti_7ewp8=.ab0ba70c-2537-453e-80a2-19d58ce70e59@github.com>
Message-ID: <PrzWh-TMeDH6CW6gP66LensEjRT9-sZ7AWG7UiGCYwM=.45a3a548-83c8-4c95-9881-34ffaca0a1e7@github.com>

On Sun, 23 Mar 2025 18:30:39 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that removes the 'jfr query' command in product builds. The command was accidentally activated a couple of months ago, but it has never made it into a release.
> 
> Testing: tier1 + test/jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24178#pullrequestreview-2709673279

From shade at openjdk.org  Mon Mar 24 09:30:15 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 24 Mar 2025 09:30:15 GMT
Subject: RFR: 8352648: JFR: 'jfr query' should not be available in product
 builds
In-Reply-To: <NBQshQkn4MLhm-AiYHxnaTh6bBgVqQDKtKwti_7ewp8=.ab0ba70c-2537-453e-80a2-19d58ce70e59@github.com>
References: <NBQshQkn4MLhm-AiYHxnaTh6bBgVqQDKtKwti_7ewp8=.ab0ba70c-2537-453e-80a2-19d58ce70e59@github.com>
Message-ID: <Y2OCzfy0yG1fDmdQSyQn3eQIRn_bg0A9HRhX8JJ05G8=.155dcaa4-1da6-4bf1-865f-9ed32c7f1abb@github.com>

On Sun, 23 Mar 2025 18:30:39 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that removes the 'jfr query' command in product builds. The command was accidentally activated a couple of months ago, but it has never made it into a release.
> 
> Testing: tier1 + test/jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24178#pullrequestreview-2709701948

From tschatzl at openjdk.org  Mon Mar 24 11:43:14 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 24 Mar 2025 11:43:14 GMT
Subject: RFR: 8350386: Test TestCodeCacheFull.java fails with option
 -XX:-UseCodeCacheFlushing [v2]
In-Reply-To: <hnMpW-m99y7EC1j2eHFxpSEOYvdtYYhdVoYeqjEQfUk=.0548c78c-7508-4d1a-990e-f02d8d447bdc@github.com>
References: <laAqUCgaqW5DnbmI7FhlXEfD6vBqd0BpcPPwBqpmRQA=.3f801860-3de4-48af-b033-6a066888e404@github.com>
 <hnMpW-m99y7EC1j2eHFxpSEOYvdtYYhdVoYeqjEQfUk=.0548c78c-7508-4d1a-990e-f02d8d447bdc@github.com>
Message-ID: <cBnZ5uW_qYq1wz-MpG-KtQpSCSDEnQ_6ZyIWLaMN1U8=.ce518d10-5303-43bc-bfe3-eed650e9e5c4@github.com>

On Sat, 22 Mar 2025 04:00:53 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test jdk/jfr/event/compiler/TestCodeCacheFull.java fails with option `-XX:-UseCodeCacheFlushing`, because this test is incompatible with `-XX:-UseCodeCacheFlushing` when `-XX:+SegmentedCodeCache` is enable, the detail analyze has been recorded by [JDK-8350386](https://bugs.openjdk.org/browse/JDK-8350386). This PR add `* @requires vm.opt.UseCodeCacheFlushing == null | vm.opt.UseCodeCacheFlushing == true` to make sure `UseCodeCacheFlushing` is not set or set as true.
>> 
>> Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "* @requires vm.opt.UseCodeCacheFlushing == null | vm.opt.UseCodeCacheFlushing == true" instead of enable UseCodeCacheFlushing in options

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23721#pullrequestreview-2710077291

From mgronlun at openjdk.org  Mon Mar 24 11:44:48 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 24 Mar 2025 11:44:48 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path
Message-ID: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>

Greetings,

In debug builds, we can sometimes assert because C2's Escape Analysis does not recognize a pattern where one input of memory Phi node is a MergeMem node, and another is a RAW store.

This pattern is created by the jdk.jfr.internal.JVM.commit() intrinsic, which is inlined because of inlining JFR events, for example jdk.VirtualThreadStart.

As a result, EA complains about a strange memory graph. 

Testing: jdk_jfr

Thanks
Markus

-------------

Commit messages:
 - 8352696

Changes: https://git.openjdk.org/jdk/pull/24192/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24192&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352696
  Stats: 125 lines in 2 files changed: 121 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24192/head:pull/24192

PR: https://git.openjdk.org/jdk/pull/24192

From thartmann at openjdk.org  Mon Mar 24 12:04:13 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 24 Mar 2025 12:04:13 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path
In-Reply-To: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
Message-ID: <Mjqu02XXFiG-Bl1r8Qvtvt05_N_5Fu6rTQESNkK1bmY=.11de1e6c-942d-42b7-aec7-2708833a620f@github.com>

On Mon, 24 Mar 2025 11:35:03 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> In debug builds, we can sometimes assert because C2's Escape Analysis does not recognize a pattern where one input of memory Phi node is a MergeMem node, and another is a RAW store.
> 
> This pattern is created by the jdk.jfr.internal.JVM.commit() intrinsic, which is inlined because of inlining JFR events, for example jdk.VirtualThreadStart.
> 
> As a result, EA complains about a strange memory graph. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

test/jdk/jdk/jfr/jvm/TestJvmCommitIntrinsicAndEA.java line 85:

> 83: public final class TestJvmCommitIntrinsicAndEA {
> 84: 
> 85:      public static void main(String[] args) throws Throwable {

Quick drive-by comment: The indentation is off, also below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24192#discussion_r2010043449

From thartmann at openjdk.org  Mon Mar 24 12:14:25 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 24 Mar 2025 12:14:25 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path
In-Reply-To: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
Message-ID: <X8cEbMT7Aol-woA34MTr_Jq57qwEQz1v6uXNBYOTrSE=.8cfe6096-03e5-4d4f-998e-59dd3f2b5fd1@github.com>

On Mon, 24 Mar 2025 11:35:03 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> In debug builds, we can sometimes assert because C2's Escape Analysis does not recognize a pattern where one input of memory Phi node is a MergeMem node, and another is a RAW store.
> 
> This pattern is created by the jdk.jfr.internal.JVM.commit() intrinsic, which is inlined because of inlining JFR events, for example jdk.VirtualThreadStart.
> 
> As a result, EA complains about a strange memory graph. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Looks good to me otherwise.

test/jdk/jdk/jfr/jvm/TestJvmCommitIntrinsicAndEA.java line 79:

> 77:  * @bug 8352696
> 78:  * @requires vm.flagless
> 79:  * @requires vm.hasJFR & vm.debug

Could be merged.

test/jdk/jdk/jfr/jvm/TestJvmCommitIntrinsicAndEA.java line 81:

> 79:  * @requires vm.hasJFR & vm.debug
> 80:  * @library /test/lib /test/jdk
> 81:  * @run main/othervm jdk.jfr.jvm.TestJvmCommitIntrinsicAndEA

Maybe use `-Xbatch`?

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24192#pullrequestreview-2710145599
PR Review Comment: https://git.openjdk.org/jdk/pull/24192#discussion_r2010058606
PR Review Comment: https://git.openjdk.org/jdk/pull/24192#discussion_r2010046632

From mgronlun at openjdk.org  Mon Mar 24 12:22:10 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 24 Mar 2025 12:22:10 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v2]
In-Reply-To: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
Message-ID: <tQe0NAt3WP5ZxIJXQJnyI4voRh5KdqmwcOGXA_9gnls=.2f8f6f55-180f-4a77-8c64-41dea7a88b4e@github.com>

> Greetings,
> 
> In debug builds, we can sometimes assert because C2's Escape Analysis does not recognize a pattern where one input of memory Phi node is a MergeMem node, and another is a RAW store.
> 
> This pattern is created by the jdk.jfr.internal.JVM.commit() intrinsic, which is inlined because of inlining JFR events, for example jdk.VirtualThreadStart.
> 
> As a result, EA complains about a strange memory graph. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:

 - merged requires
 - indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24192/files
  - new: https://git.openjdk.org/jdk/pull/24192/files/8e4185c2..e072153b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24192&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24192&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24192/head:pull/24192

PR: https://git.openjdk.org/jdk/pull/24192

From mgronlun at openjdk.org  Mon Mar 24 12:22:11 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 24 Mar 2025 12:22:11 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v2]
In-Reply-To: <X8cEbMT7Aol-woA34MTr_Jq57qwEQz1v6uXNBYOTrSE=.8cfe6096-03e5-4d4f-998e-59dd3f2b5fd1@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
 <X8cEbMT7Aol-woA34MTr_Jq57qwEQz1v6uXNBYOTrSE=.8cfe6096-03e5-4d4f-998e-59dd3f2b5fd1@github.com>
Message-ID: <s-X4ZadpArPcBv8GTnNQafnmOmzrc_GPcHuGxfvpMUM=.f3cff2c6-4cb1-430e-8483-51c03702b734@github.com>

On Mon, 24 Mar 2025 12:11:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Looks good to me otherwise.

Thanks so much for taking a look @TobiHartmann !

> test/jdk/jdk/jfr/jvm/TestJvmCommitIntrinsicAndEA.java line 81:
> 
>> 79:  * @requires vm.hasJFR & vm.debug
>> 80:  * @library /test/lib /test/jdk
>> 81:  * @run main/othervm jdk.jfr.jvm.TestJvmCommitIntrinsicAndEA
> 
> Maybe use `-Xbatch`?

What would it give?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24192#issuecomment-2747938310
PR Review Comment: https://git.openjdk.org/jdk/pull/24192#discussion_r2010065975

From mgronlun at openjdk.org  Mon Mar 24 12:26:12 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 24 Mar 2025 12:26:12 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v2]
In-Reply-To: <s-X4ZadpArPcBv8GTnNQafnmOmzrc_GPcHuGxfvpMUM=.f3cff2c6-4cb1-430e-8483-51c03702b734@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
 <X8cEbMT7Aol-woA34MTr_Jq57qwEQz1v6uXNBYOTrSE=.8cfe6096-03e5-4d4f-998e-59dd3f2b5fd1@github.com>
 <s-X4ZadpArPcBv8GTnNQafnmOmzrc_GPcHuGxfvpMUM=.f3cff2c6-4cb1-430e-8483-51c03702b734@github.com>
Message-ID: <5ASdY5jtvoX2wp-xEWbHSe_fLBiRuWklQra9T0MYG4U=.55746d71-6689-4212-8443-6a2cace9a8f1@github.com>

On Mon, 24 Mar 2025 12:16:02 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> test/jdk/jdk/jfr/jvm/TestJvmCommitIntrinsicAndEA.java line 81:
>> 
>>> 79:  * @requires vm.hasJFR & vm.debug
>>> 80:  * @library /test/lib /test/jdk
>>> 81:  * @run main/othervm jdk.jfr.jvm.TestJvmCommitIntrinsicAndEA
>> 
>> Maybe use `-Xbatch`?
>
> What would it give?

Disabling background compilation makes it more deterministic?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24192#discussion_r2010076673

From mgronlun at openjdk.org  Mon Mar 24 12:34:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 24 Mar 2025 12:34:53 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v3]
In-Reply-To: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
Message-ID: <VSAqQsT8_ttbi_7c7H3ke2T-cDrWByFGlK8Hljp4-p4=.151c123e-d46a-46f6-aa26-a5b94db6c60c@github.com>

> Greetings,
> 
> In debug builds, we can sometimes assert because C2's Escape Analysis does not recognize a pattern where one input of memory Phi node is a MergeMem node, and another is a RAW store.
> 
> This pattern is created by the jdk.jfr.internal.JVM.commit() intrinsic, which is inlined because of inlining JFR events, for example jdk.VirtualThreadStart.
> 
> As a result, EA complains about a strange memory graph. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  Xbatch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24192/files
  - new: https://git.openjdk.org/jdk/pull/24192/files/e072153b..0ba8abfb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24192&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24192&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24192/head:pull/24192

PR: https://git.openjdk.org/jdk/pull/24192

From shade at openjdk.org  Mon Mar 24 12:34:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 24 Mar 2025 12:34:54 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v2]
In-Reply-To: <tQe0NAt3WP5ZxIJXQJnyI4voRh5KdqmwcOGXA_9gnls=.2f8f6f55-180f-4a77-8c64-41dea7a88b4e@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
 <tQe0NAt3WP5ZxIJXQJnyI4voRh5KdqmwcOGXA_9gnls=.2f8f6f55-180f-4a77-8c64-41dea7a88b4e@github.com>
Message-ID: <73iiU00Ahqm8b_DiUS97EgegNnSJh-mxJEqUUSGJSZg=.8dd13ae9-2d35-4130-8350-ad0b9f7bf695@github.com>

On Mon, 24 Mar 2025 12:22:10 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> In debug builds, we can sometimes assert because C2's Escape Analysis does not recognize a pattern where one input of memory Phi node is a MergeMem node, and another is a RAW store.
>> 
>> This pattern is created by the jdk.jfr.internal.JVM.commit() intrinsic, which is inlined because of inlining JFR events, for example jdk.VirtualThreadStart.
>> 
>> As a result, EA complains about a strange memory graph. 
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - merged requires
>  - indentation

src/hotspot/share/opto/library_call.cpp line 3179:

> 3177:   store_to_memory(control(), java_buffer_pos_offset, next_pos_X, T_LONG, MemNode::release);
> 3178: #else
> 3179:   store_to_memory(control(), java_buffer_pos_offset, next_pos_X, T_INT, MemNode::release);

BTW, you can write this is less duplication, like:


store_to_memory(control(), java_buffer_pos_offset, next_pos_X, LP64_ONLY(T_LONG) NOT_LP64(T_INT), MemNode::release);


(I wish there was a `X`-style macro like `MakeConX`, but I don't think there is one for `BasicType`)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24192#discussion_r2010087366

From mgronlun at openjdk.org  Mon Mar 24 12:34:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 24 Mar 2025 12:34:54 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v2]
In-Reply-To: <73iiU00Ahqm8b_DiUS97EgegNnSJh-mxJEqUUSGJSZg=.8dd13ae9-2d35-4130-8350-ad0b9f7bf695@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
 <tQe0NAt3WP5ZxIJXQJnyI4voRh5KdqmwcOGXA_9gnls=.2f8f6f55-180f-4a77-8c64-41dea7a88b4e@github.com>
 <73iiU00Ahqm8b_DiUS97EgegNnSJh-mxJEqUUSGJSZg=.8dd13ae9-2d35-4130-8350-ad0b9f7bf695@github.com>
Message-ID: <Phyk_VwOSl37EBA9IR99O1f2rTwcDq6EBWrur_9us80=.cc2167d2-4d16-4d2d-8d5f-6ce980c219c9@github.com>

On Mon, 24 Mar 2025 12:29:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - merged requires
>>  - indentation
>
> src/hotspot/share/opto/library_call.cpp line 3179:
> 
>> 3177:   store_to_memory(control(), java_buffer_pos_offset, next_pos_X, T_LONG, MemNode::release);
>> 3178: #else
>> 3179:   store_to_memory(control(), java_buffer_pos_offset, next_pos_X, T_INT, MemNode::release);
> 
> BTW, you can write this is less duplication, like:
> 
> 
> store_to_memory(control(), java_buffer_pos_offset, next_pos_X, LP64_ONLY(T_LONG) NOT_LP64(T_INT), MemNode::release);
> 
> 
> (I wish there was a `X`-style macro like `MakeConX`, but I don't think there is one for `BasicType`)

Nice!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24192#discussion_r2010089591

From mgronlun at openjdk.org  Mon Mar 24 12:39:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 24 Mar 2025 12:39:56 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v4]
In-Reply-To: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
Message-ID: <hlVqWo4ra1EObywPuvHcIkcbmzNxJD3wMZVxzLIITMA=.9d78e549-8bef-46f2-92c8-f7e8ee4d657d@github.com>

> Greetings,
> 
> In debug builds, we can sometimes assert because C2's Escape Analysis does not recognize a pattern where one input of memory Phi node is a MergeMem node, and another is a RAW store.
> 
> This pattern is created by the jdk.jfr.internal.JVM.commit() intrinsic, which is inlined because of inlining JFR events, for example jdk.VirtualThreadStart.
> 
> As a result, EA complains about a strange memory graph. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  fold

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24192/files
  - new: https://git.openjdk.org/jdk/pull/24192/files/0ba8abfb..c63fb608

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24192&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24192&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24192/head:pull/24192

PR: https://git.openjdk.org/jdk/pull/24192

From egahlin at openjdk.org  Mon Mar 24 15:20:15 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 24 Mar 2025 15:20:15 GMT
Subject: Integrated: 8352648: JFR: 'jfr query' should not be available in
 product builds
In-Reply-To: <NBQshQkn4MLhm-AiYHxnaTh6bBgVqQDKtKwti_7ewp8=.ab0ba70c-2537-453e-80a2-19d58ce70e59@github.com>
References: <NBQshQkn4MLhm-AiYHxnaTh6bBgVqQDKtKwti_7ewp8=.ab0ba70c-2537-453e-80a2-19d58ce70e59@github.com>
Message-ID: <KtVgQNP3hVaIH9af4H0RN0NpFJUA2B38O6o1TbZXq6w=.9e9e0645-f8df-4d3f-b3d9-6644cfc894d1@github.com>

On Sun, 23 Mar 2025 18:30:39 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that removes the 'jfr query' command in product builds. The command was accidentally activated a couple of months ago, but it has never made it into a release.
> 
> Testing: tier1 + test/jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 5709f79c
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5709f79cf86d532b38133a7fc11e6388af573723
Stats:     30 lines in 6 files changed: 26 ins; 0 del; 4 mod

8352648: JFR: 'jfr query' should not be available in product builds

Reviewed-by: mgronlun, shade

-------------

PR: https://git.openjdk.org/jdk/pull/24178

From kvn at openjdk.org  Mon Mar 24 17:16:22 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 24 Mar 2025 17:16:22 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v4]
In-Reply-To: <hlVqWo4ra1EObywPuvHcIkcbmzNxJD3wMZVxzLIITMA=.9d78e549-8bef-46f2-92c8-f7e8ee4d657d@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
 <hlVqWo4ra1EObywPuvHcIkcbmzNxJD3wMZVxzLIITMA=.9d78e549-8bef-46f2-92c8-f7e8ee4d657d@github.com>
Message-ID: <1_pSpJqymSS7Cmxl8RUbULH2toJC5A_HbbRLyXTpTnc=.5cd6f2fc-d4ef-4507-b2b4-2d215c3955fa@github.com>

On Mon, 24 Mar 2025 12:39:56 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> In debug builds, we can sometimes assert because C2's Escape Analysis does not recognize a pattern where one input of memory Phi node is a MergeMem node, and another is a RAW store.
>> 
>> This pattern is created by the jdk.jfr.internal.JVM.commit() intrinsic, which is inlined because of inlining JFR events, for example jdk.VirtualThreadStart.
>> 
>> As a result, EA complains about a strange memory graph. 
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fold

Looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24192#pullrequestreview-2711139109

From mgronlun at openjdk.org  Mon Mar 24 19:23:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 24 Mar 2025 19:23:56 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v5]
In-Reply-To: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
Message-ID: <PnW4hXM1VwCdhjK90wUHLStF3zXiYJgbjhNaOnjieXk=.60e098ed-c505-4397-9915-efd3793c8db5@github.com>

> Greetings,
> 
> In debug builds, we can sometimes assert because C2's Escape Analysis does not recognize a pattern where one input of memory Phi node is a MergeMem node, and another is a RAW store.
> 
> This pattern is created by the jdk.jfr.internal.JVM.commit() intrinsic, which is inlined because of inlining JFR events, for example jdk.VirtualThreadStart.
> 
> As a result, EA complains about a strange memory graph. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  simplified test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24192/files
  - new: https://git.openjdk.org/jdk/pull/24192/files/c63fb608..cae054c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24192&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24192&range=03-04

  Stats: 38 lines in 1 file changed: 4 ins; 25 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24192/head:pull/24192

PR: https://git.openjdk.org/jdk/pull/24192

From mgronlun at openjdk.org  Mon Mar 24 22:33:23 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 24 Mar 2025 22:33:23 GMT
Subject: RFR: 8348907: Stress times out when is executed with ZGC
Message-ID: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>

Greetings,

Here is a suggested solution for solving the intricate deadlock issues involving virtual threads, ZGC load barriers, and JFR.

A JFR event can be allocated and committed in specific sensitive contexts, such as inside mutex-protected load barriers. If the thread is a virtual thread, JFR determines its thread name by loading the oop from the thread (jt->vthread()) as part of the event commit.

This operation again triggers the load barrier, which contains a non-reentrant lock, effectively deadlocking the thread with itself.

So, for specific sensitive event sites, JFR mustn't recurse or reenter into the same event site as part of the event commit.

After a few iterations and prototypes, which failed because they eventually ended up touching some oop, I came up with the following.

>From a user perspective, an event (site) can now be marked as "non-reentrant" by wrapping it in a helper class.

This instruction now guarantees JFR will not reenter this site again as part of the event.commit().

The tradeoff is that we cannot write the virtual thread name for these sensitive event sites; we will instead report "" as the virtual thread name, which is the default virtual thread name in Java. All other information about the thread, such as the thread ID, virtual thread, etc., will still be reported.

I believe it is a reasonable tradeoff and a general solution for sensitive JFR event sites, which are rare in practice, with minimal impact on event programming.

Testing: jdk_jfr, stress testing

Let me know what you think.

Thanks
Markus

-------------

Commit messages:
 - 8348907

Changes: https://git.openjdk.org/jdk/pull/24209/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348907
  Stats: 160 lines in 10 files changed: 139 ins; 12 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24209/head:pull/24209

PR: https://git.openjdk.org/jdk/pull/24209

From shade at openjdk.org  Tue Mar 25 08:01:20 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Mar 2025 08:01:20 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v5]
In-Reply-To: <PnW4hXM1VwCdhjK90wUHLStF3zXiYJgbjhNaOnjieXk=.60e098ed-c505-4397-9915-efd3793c8db5@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
 <PnW4hXM1VwCdhjK90wUHLStF3zXiYJgbjhNaOnjieXk=.60e098ed-c505-4397-9915-efd3793c8db5@github.com>
Message-ID: <Tz9nWql2cKLUO6tTeKjTcIQ5ahoQzxALSuct2rlafLI=.4277a266-d90d-4251-9d36-58dac9f4c9f1@github.com>

On Mon, 24 Mar 2025 19:23:56 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> In debug builds, we can sometimes assert because C2's Escape Analysis does not recognize a pattern where one input of memory Phi node is a MergeMem node, and another is a RAW store.
>> 
>> This pattern is created by the jdk.jfr.internal.JVM.commit() intrinsic, which is inlined because of inlining JFR events, for example jdk.VirtualThreadStart.
>> 
>> As a result, EA complains about a strange memory graph. 
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplified test

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24192#pullrequestreview-2712743344

From thartmann at openjdk.org  Tue Mar 25 08:28:10 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 25 Mar 2025 08:28:10 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v5]
In-Reply-To: <PnW4hXM1VwCdhjK90wUHLStF3zXiYJgbjhNaOnjieXk=.60e098ed-c505-4397-9915-efd3793c8db5@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
 <PnW4hXM1VwCdhjK90wUHLStF3zXiYJgbjhNaOnjieXk=.60e098ed-c505-4397-9915-efd3793c8db5@github.com>
Message-ID: <QlRUTtfzjpDAAR_LxD3oTRZp_5LqmpPzCquy_yKiEYU=.7359ff39-e060-4e14-9ac9-68fea5a11b10@github.com>

On Mon, 24 Mar 2025 19:23:56 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> In debug builds, we can sometimes assert because C2's Escape Analysis does not recognize a pattern where one input of memory Phi node is a MergeMem node, and another is a RAW store.
>> 
>> This pattern is created by the jdk.jfr.internal.JVM.commit() intrinsic, which is inlined because of inlining JFR events, for example jdk.VirtualThreadStart.
>> 
>> As a result, EA complains about a strange memory graph. 
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplified test

Looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24192#pullrequestreview-2712815298

From thartmann at openjdk.org  Tue Mar 25 08:28:11 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 25 Mar 2025 08:28:11 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v5]
In-Reply-To: <5ASdY5jtvoX2wp-xEWbHSe_fLBiRuWklQra9T0MYG4U=.55746d71-6689-4212-8443-6a2cace9a8f1@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
 <X8cEbMT7Aol-woA34MTr_Jq57qwEQz1v6uXNBYOTrSE=.8cfe6096-03e5-4d4f-998e-59dd3f2b5fd1@github.com>
 <s-X4ZadpArPcBv8GTnNQafnmOmzrc_GPcHuGxfvpMUM=.f3cff2c6-4cb1-430e-8483-51c03702b734@github.com>
 <5ASdY5jtvoX2wp-xEWbHSe_fLBiRuWklQra9T0MYG4U=.55746d71-6689-4212-8443-6a2cace9a8f1@github.com>
Message-ID: <WTJVfZCYEtJknXD-fAKiE58NU9-KEpn218_-BTLE-RQ=.7c3d5d8e-6ea2-4f69-99ef-5fc4b8ebd21c@github.com>

On Mon, 24 Mar 2025 12:23:18 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> What would it give?
>
> Disabling background compilation makes it more deterministic?

Yes and you might need fewer runs to trigger compilation and wait for it to finish.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24192#discussion_r2011557304

From mgronlun at openjdk.org  Tue Mar 25 10:40:16 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 25 Mar 2025 10:40:16 GMT
Subject: RFR: 8352696: JFR: assert(false): EA: missing memory path [v5]
In-Reply-To: <QlRUTtfzjpDAAR_LxD3oTRZp_5LqmpPzCquy_yKiEYU=.7359ff39-e060-4e14-9ac9-68fea5a11b10@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
 <PnW4hXM1VwCdhjK90wUHLStF3zXiYJgbjhNaOnjieXk=.60e098ed-c505-4397-9915-efd3793c8db5@github.com>
 <QlRUTtfzjpDAAR_LxD3oTRZp_5LqmpPzCquy_yKiEYU=.7359ff39-e060-4e14-9ac9-68fea5a11b10@github.com>
Message-ID: <2qZ6KK0j0Fx8gytx2f51ikfN3DRydC1bc14AfgEGBhM=.68348a98-14a2-46fa-9f33-b9a25b4b283b@github.com>

On Tue, 25 Mar 2025 08:25:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplified test
>
> Looks good.

Thank you @TobiHartmann, @shipilev and @vnkozlov for your reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24192#issuecomment-2750817188

From mgronlun at openjdk.org  Tue Mar 25 10:40:17 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 25 Mar 2025 10:40:17 GMT
Subject: Integrated: 8352696: JFR: assert(false): EA: missing memory path
In-Reply-To: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
References: <rZQxlLciP5LNeIOLBAXsQn5ipsf_GV8H3E_AyLAjQOY=.b84f94f8-55f8-4d71-b99a-cc72a2310db9@github.com>
Message-ID: <dr00665Na3Y7MBsXw0m_MhQgZJZ9ZhhUjGnnk8w341Q=.af76d5b4-ce49-4512-abcc-8cb26bf85a84@github.com>

On Mon, 24 Mar 2025 11:35:03 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> In debug builds, we can sometimes assert because C2's Escape Analysis does not recognize a pattern where one input of memory Phi node is a MergeMem node, and another is a RAW store.
> 
> This pattern is created by the jdk.jfr.internal.JVM.commit() intrinsic, which is inlined because of inlining JFR events, for example jdk.VirtualThreadStart.
> 
> As a result, EA complains about a strange memory graph. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 721ef767
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/721ef76738a2145bdff9b8534d3512282c61db8b
Stats:     101 lines in 2 files changed: 94 ins; 2 del; 5 mod

8352696: JFR: assert(false): EA: missing memory path

Reviewed-by: thartmann, shade, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/24192

From mgronlun at openjdk.org  Tue Mar 25 13:18:41 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 25 Mar 2025 13:18:41 GMT
Subject: RFR: 8348907: Stress times out when is executed with ZGC [v2]
In-Reply-To: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
References: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
Message-ID: <-Lq8r8IewtCDh2Y7b548AHXu-k-3q9maqk0s9W5H5ac=.7fc9e5c4-d94c-46f7-af4a-5bcdc93a6b28@github.com>

> Greetings,
> 
> Here is a suggested solution for solving the intricate deadlock issues involving virtual threads, ZGC load barriers, and JFR.
> 
> A JFR event can be allocated and committed in specific sensitive contexts, such as inside mutex-protected load barriers. If the thread is a virtual thread, JFR determines its thread name by loading the oop from the thread (jt->vthread()) as part of the event commit.
> 
> This operation again triggers the load barrier, which contains a non-reentrant lock, effectively deadlocking the thread with itself.
> 
> So, for specific sensitive event sites, JFR mustn't recurse or reenter into the same event site as part of the event commit.
> 
> After a few iterations and prototypes, which failed because they eventually ended up touching some oop, I came up with the following.
> 
> From a user perspective, an event (site) can now be marked as "non-reentrant" by wrapping it in a helper class.
> 
> This instruction now guarantees JFR will not reenter this site again as part of the event.commit().
> 
> The tradeoff is that we cannot write the virtual thread name for these sensitive event sites; we will instead report "" as the virtual thread name, which is the default virtual thread name in Java. All other information about the thread, such as the thread ID, virtual thread, etc., will still be reported.
> 
> I believe it is a reasonable tradeoff and a general solution for sensitive JFR event sites, which are rare in practice, with minimal impact on event programming.
> 
> Testing: jdk_jfr, stress testing
> 
> Let me know what you think.
> 
> Thanks
> Markus

Markus Gr?nlund 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 four additional commits since the last revision:

 - autogenerate helper classes for non-reentrancy
 - Merge branch '8348907' of github.com:mgronlun/jdk into 8348907
 - 8348907
 - 8348907

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24209/files
  - new: https://git.openjdk.org/jdk/pull/24209/files/8aa59c8b..29064afa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=00-01

  Stats: 10002 lines in 187 files changed: 6686 ins; 888 del; 2428 mod
  Patch: https://git.openjdk.org/jdk/pull/24209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24209/head:pull/24209

PR: https://git.openjdk.org/jdk/pull/24209

From mgronlun at openjdk.org  Tue Mar 25 13:23:41 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 25 Mar 2025 13:23:41 GMT
Subject: RFR: 8348907: Stress times out when is executed with ZGC [v3]
In-Reply-To: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
References: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
Message-ID: <eXBdhF6WIeVB7CVucIWVxZ6TvOdJbnN5C8TDCpoXdyc=.5ef7ed98-0e80-4fee-96d4-b1ada2e7cd7f@github.com>

> Greetings,
> 
> Here is a suggested solution for solving the intricate deadlock issues involving virtual threads, ZGC load barriers, and JFR.
> 
> A JFR event can be allocated and committed in specific sensitive contexts, such as inside mutex-protected load barriers. If the thread is a virtual thread, JFR determines its thread name by loading the oop from the thread (jt->vthread()) as part of the event commit.
> 
> This operation again triggers the load barrier, which contains a non-reentrant lock, effectively deadlocking the thread with itself.
> 
> So, for specific sensitive event sites, JFR mustn't recurse or reenter into the same event site as part of the event commit.
> 
> After a few iterations and prototypes, which failed because they eventually ended up touching some oop, I came up with the following.
> 
> From a user perspective, an event (site) can now be marked as "non-reentrant" by wrapping it in a helper class.
> 
> This instruction now guarantees JFR will not reenter this site again as part of the event.commit().
> 
> The tradeoff is that we cannot write the virtual thread name for these sensitive event sites; we will instead report "" as the virtual thread name, which is the default virtual thread name in Java. All other information about the thread, such as the thread ID, virtual thread, etc., will still be reported.
> 
> I believe it is a reasonable tradeoff and a general solution for sensitive JFR event sites, which are rare in practice, with minimal impact on event programming.
> 
> Testing: jdk_jfr, stress testing
> 
> Let me know what you think.
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  fake commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24209/files
  - new: https://git.openjdk.org/jdk/pull/24209/files/29064afa..5ca42d01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24209/head:pull/24209

PR: https://git.openjdk.org/jdk/pull/24209

From mgronlun at openjdk.org  Tue Mar 25 13:38:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 25 Mar 2025 13:38:56 GMT
Subject: RFR: 8348907: Stress times out when is executed with ZGC [v4]
In-Reply-To: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
References: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
Message-ID: <3DfXgxoWFc07J6yfhjREbhiABvhwPSclqG0RvAjVtP8=.8ad57991-14b9-4c9d-90ef-35daa81f7d9d@github.com>

> Greetings,
> 
> Here is a suggested solution for solving the intricate deadlock issues involving virtual threads, ZGC load barriers, and JFR.
> 
> A JFR event can be allocated and committed in specific sensitive contexts, such as inside mutex-protected load barriers. If the thread is a virtual thread, JFR determines its thread name by loading the oop from the thread (jt->vthread()) as part of the event commit.
> 
> This operation again triggers the load barrier, which contains a non-reentrant lock, effectively deadlocking the thread with itself.
> 
> So, for specific sensitive event sites, JFR mustn't recurse or reenter into the same event site as part of the event commit.
> 
> After a few iterations and prototypes, which failed because they eventually ended up touching some oop, I came up with the following.
> 
> From a user perspective, an event (site) can now be marked as "non-reentrant" by wrapping it in a helper class.
> 
> This instruction now guarantees JFR will not reenter this site again as part of the event.commit().
> 
> The tradeoff is that we cannot write the virtual thread name for these sensitive event sites; we will instead report "" as the virtual thread name, which is the default virtual thread name in Java. All other information about the thread, such as the thread ID, virtual thread, etc., will still be reported.
> 
> I believe it is a reasonable tradeoff and a general solution for sensitive JFR event sites, which are rare in practice, with minimal impact on event programming.
> 
> Testing: jdk_jfr, stress testing
> 
> Let me know what you think.
> 
> Thanks
> Markus

Markus Gr?nlund has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:

  8348907

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24209/files
  - new: https://git.openjdk.org/jdk/pull/24209/files/5ca42d01..ee5be9da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=02-03

  Stats: 91 lines in 3 files changed: 57 ins; 34 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24209/head:pull/24209

PR: https://git.openjdk.org/jdk/pull/24209

From mgronlun at openjdk.org  Tue Mar 25 13:42:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 25 Mar 2025 13:42:03 GMT
Subject: RFR: 8348907: Stress times out when is executed with ZGC [v5]
In-Reply-To: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
References: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
Message-ID: <-nNSX0SdDXDwR7kJGugqsJs36XLLKjH_UpvZEAvyt_c=.e32dbc05-2ef1-4765-a3fb-5c7bb83c2c15@github.com>

> Greetings,
> 
> Here is a suggested solution for solving the intricate deadlock issues involving virtual threads, ZGC load barriers, and JFR.
> 
> A JFR event can be allocated and committed in specific sensitive contexts, such as inside mutex-protected load barriers. If the thread is a virtual thread, JFR determines its thread name by loading the oop from the thread (jt->vthread()) as part of the event commit.
> 
> This operation again triggers the load barrier, which contains a non-reentrant lock, effectively deadlocking the thread with itself.
> 
> So, for specific sensitive event sites, JFR mustn't recurse or reenter into the same event site as part of the event commit.
> 
> After a few iterations and prototypes, which failed because they eventually ended up touching some oop, I came up with the following.
> 
> From a user perspective, an event (site) can now be marked as "non-reentrant" by wrapping it in a helper class.
> 
> This instruction now guarantees JFR will not reenter this site again as part of the event.commit().
> 
> The tradeoff is that we cannot write the virtual thread name for these sensitive event sites; we will instead report "" as the virtual thread name, which is the default virtual thread name in Java. All other information about the thread, such as the thread ID, virtual thread, etc., will still be reported.
> 
> I believe it is a reasonable tradeoff and a general solution for sensitive JFR event sites, which are rare in practice, with minimal impact on event programming.
> 
> Testing: jdk_jfr, stress testing
> 
> Let me know what you think.
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  autogenerate helper classes for non-reentrancy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24209/files
  - new: https://git.openjdk.org/jdk/pull/24209/files/ee5be9da..72116f34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=03-04

  Stats: 91 lines in 3 files changed: 34 ins; 57 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24209/head:pull/24209

PR: https://git.openjdk.org/jdk/pull/24209

From mgronlun at openjdk.org  Tue Mar 25 17:03:24 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 25 Mar 2025 17:03:24 GMT
Subject: RFR: 8348907: Stress times out when is executed with ZGC [v6]
In-Reply-To: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
References: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
Message-ID: <GTMEPhQg9b7jZhkRn8htzay1ZDhbmAGUqq3sWY_vA_g=.06d898b7-f325-40c0-b49a-395e0bb48461@github.com>

> Greetings,
> 
> Here is a suggested solution for solving the intricate deadlock issues involving virtual threads, ZGC load barriers, and JFR.
> 
> A JFR event can be allocated and committed in specific sensitive contexts, such as inside mutex-protected load barriers. If the thread is a virtual thread, JFR determines its thread name by loading the oop from the thread (jt->vthread()) as part of the event commit.
> 
> This operation again triggers the load barrier, which contains a non-reentrant lock, effectively deadlocking the thread with itself.
> 
> So, for specific sensitive event sites, JFR mustn't recurse or reenter into the same event site as part of the event commit.
> 
> After a few iterations and prototypes, which failed because they eventually ended up touching some oop, I came up with the following.
> 
> From a user perspective, an event (site) can now be marked as "non-reentrant" by wrapping it in a helper class.
> 
> This instruction now guarantees JFR will not reenter this site again as part of the event.commit().
> 
> The tradeoff is that we cannot write the virtual thread name for these sensitive event sites; we will instead report "" as the virtual thread name, which is the default virtual thread name in Java. All other information about the thread, such as the thread ID, virtual thread, etc., will still be reported.
> 
> I believe it is a reasonable tradeoff and a general solution for sensitive JFR event sites, which are rare in practice, with minimal impact on event programming.
> 
> Testing: jdk_jfr, stress testing
> 
> Let me know what you think.
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  renames

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24209/files
  - new: https://git.openjdk.org/jdk/pull/24209/files/72116f34..f11f33bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=04-05

  Stats: 18 lines in 8 files changed: 3 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24209/head:pull/24209

PR: https://git.openjdk.org/jdk/pull/24209

From mgronlun at openjdk.org  Tue Mar 25 17:13:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 25 Mar 2025 17:13:55 GMT
Subject: RFR: 8348907: Stress times out when is executed with ZGC [v7]
In-Reply-To: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
References: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
Message-ID: <ppX8fsx74X3xogl5drStjP81pvPFE59rmSJLZcrZAdw=.565fb31d-1195-42d8-bb1c-ba287d3e12ff@github.com>

> Greetings,
> 
> Here is a suggested solution for solving the intricate deadlock issues involving virtual threads, ZGC load barriers, and JFR.
> 
> A JFR event can be allocated and committed in specific sensitive contexts, such as inside mutex-protected load barriers. If the thread is a virtual thread, JFR determines its thread name by loading the oop from the thread (jt->vthread()) as part of the event commit.
> 
> This operation again triggers the load barrier, which contains a non-reentrant lock, effectively deadlocking the thread with itself.
> 
> So, for specific sensitive event sites, JFR mustn't recurse or reenter into the same event site as part of the event commit.
> 
> After a few iterations and prototypes, which failed because they eventually ended up touching some oop, I came up with the following.
> 
> From a user perspective, an event (site) can now be marked as "non-reentrant" by wrapping it in a helper class.
> 
> This instruction now guarantees JFR will not reenter this site again as part of the event.commit().
> 
> The tradeoff is that we cannot write the virtual thread name for these sensitive event sites; we will instead report "" as the virtual thread name, which is the default virtual thread name in Java. All other information about the thread, such as the thread ID, virtual thread, etc., will still be reported.
> 
> I believe it is a reasonable tradeoff and a general solution for sensitive JFR event sites, which are rare in practice, with minimal impact on event programming.
> 
> Testing: jdk_jfr, stress testing
> 
> Let me know what you think.
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  delegate thread assert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24209/files
  - new: https://git.openjdk.org/jdk/pull/24209/files/f11f33bc..8d9e14bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24209&range=05-06

  Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24209/head:pull/24209

PR: https://git.openjdk.org/jdk/pull/24209

From egahlin at openjdk.org  Tue Mar 25 17:50:27 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 25 Mar 2025 17:50:27 GMT
Subject: RFR: 8348907: Stress times out when is executed with ZGC [v7]
In-Reply-To: <ppX8fsx74X3xogl5drStjP81pvPFE59rmSJLZcrZAdw=.565fb31d-1195-42d8-bb1c-ba287d3e12ff@github.com>
References: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
 <ppX8fsx74X3xogl5drStjP81pvPFE59rmSJLZcrZAdw=.565fb31d-1195-42d8-bb1c-ba287d3e12ff@github.com>
Message-ID: <rkwLZavbMm7e9WxxYo5zPSHrqVNBd9iAwnAB_8fhDeU=.0e9e742d-afc3-4fea-b22d-a4695ff8a608@github.com>

On Tue, 25 Mar 2025 17:13:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Here is a suggested solution for solving the intricate deadlock issues involving virtual threads, ZGC load barriers, and JFR.
>> 
>> A JFR event can be allocated and committed in specific sensitive contexts, such as inside mutex-protected load barriers. If the thread is a virtual thread, JFR determines its thread name by loading the oop from the thread (jt->vthread()) as part of the event commit.
>> 
>> This operation again triggers the load barrier, which contains a non-reentrant lock, effectively deadlocking the thread with itself.
>> 
>> So, for specific sensitive event sites, JFR mustn't recurse or reenter into the same event site as part of the event commit.
>> 
>> After a few iterations and prototypes, which failed because they eventually ended up touching some oop, I came up with the following.
>> 
>> From a user perspective, an event (site) can now be marked as "non-reentrant" by wrapping it in a helper class.
>> 
>> This instruction now guarantees JFR will not reenter this site again as part of the event.commit().
>> 
>> The tradeoff is that we cannot write the virtual thread name for these sensitive event sites; we will instead report "" as the virtual thread name, which is the default virtual thread name in Java. All other information about the thread, such as the thread ID, virtual thread, etc., will still be reported.
>> 
>> I believe it is a reasonable tradeoff and a general solution for sensitive JFR event sites, which are rare in practice, with minimal impact on event programming.
>> 
>> Testing: jdk_jfr, stress testing
>> 
>> Let me know what you think.
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delegate thread assert

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24209#pullrequestreview-2714656423

From egahlin at openjdk.org  Wed Mar 26 10:19:21 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 26 Mar 2025 10:19:21 GMT
Subject: RFR: 8352738: JFR: Implementation of JFR Method Timing and Tracing
Message-ID: <IJErhA0y4fcc-LMiz2WhK7trZw2jtcdMH-mKsbnAaEs=.e8e297a7-ed20-48cc-b8c5-7de55197bf74@github.com>

Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.

Testing: tier 1-3, test/jdk/jdk/jfr 

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/24205/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24205&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352738
  Stats: 6510 lines in 103 files changed: 6060 ins; 362 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/24205.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24205/head:pull/24205

PR: https://git.openjdk.org/jdk/pull/24205

From alanb at openjdk.org  Wed Mar 26 10:27:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Mar 2025 10:27:12 GMT
Subject: RFR: 8352738: JFR: Implementation of JFR Method Timing and Tracing
In-Reply-To: <IJErhA0y4fcc-LMiz2WhK7trZw2jtcdMH-mKsbnAaEs=.e8e297a7-ed20-48cc-b8c5-7de55197bf74@github.com>
References: <IJErhA0y4fcc-LMiz2WhK7trZw2jtcdMH-mKsbnAaEs=.e8e297a7-ed20-48cc-b8c5-7de55197bf74@github.com>
Message-ID: <F886lQMchf2OEDnd13A6rjbSc06z2HcstiSNe-LBY2E=.206d4e01-2ccb-4df3-866f-bf3f3af9ab65@github.com>

On Mon, 24 Mar 2025 17:25:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr 
> 
> Thanks
> Erik

Are the suboptions/parameters specified to -XX:StartFlightRecording a supported interface that is tracked by the CSR? I'm just wondering about the method-timing review specified to report-on-exit for example.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24205#issuecomment-2753909790

From aboldtch at openjdk.org  Wed Mar 26 13:59:17 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 26 Mar 2025 13:59:17 GMT
Subject: RFR: 8348907: Stress times out when is executed with ZGC [v7]
In-Reply-To: <ppX8fsx74X3xogl5drStjP81pvPFE59rmSJLZcrZAdw=.565fb31d-1195-42d8-bb1c-ba287d3e12ff@github.com>
References: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
 <ppX8fsx74X3xogl5drStjP81pvPFE59rmSJLZcrZAdw=.565fb31d-1195-42d8-bb1c-ba287d3e12ff@github.com>
Message-ID: <9fC_0ZRvvRL_WvqU-OVI4HvQzJ3nOVGBkVN1891k4Uk=.a3f4d0ee-6cba-4db0-85b6-f5544790438e@github.com>

On Tue, 25 Mar 2025 17:13:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Here is a suggested solution for solving the intricate deadlock issues involving virtual threads, ZGC load barriers, and JFR.
>> 
>> A JFR event can be allocated and committed in specific sensitive contexts, such as inside mutex-protected load barriers. If the thread is a virtual thread, JFR determines its thread name by loading the oop from the thread (jt->vthread()) as part of the event commit.
>> 
>> This operation again triggers the load barrier, which contains a non-reentrant lock, effectively deadlocking the thread with itself.
>> 
>> So, for specific sensitive event sites, JFR mustn't recurse or reenter into the same event site as part of the event commit.
>> 
>> After a few iterations and prototypes, which failed because they eventually ended up touching some oop, I came up with the following.
>> 
>> From a user perspective, an event (site) can now be marked as "non-reentrant" by wrapping it in a helper class.
>> 
>> This instruction now guarantees JFR will not reenter this site again as part of the event.commit().
>> 
>> The tradeoff is that we cannot write the virtual thread name for these sensitive event sites; we will instead report "" as the virtual thread name, which is the default virtual thread name in Java. All other information about the thread, such as the thread ID, virtual thread, etc., will still be reported.
>> 
>> I believe it is a reasonable tradeoff and a general solution for sensitive JFR event sites, which are rare in practice, with minimal impact on event programming.
>> 
>> Testing: jdk_jfr, stress testing
>> 
>> Let me know what you think.
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delegate thread assert

Looks like a pragmatic solution.

I am not reviewing the the implications of not setting the epoch, as my understanding here is a bit lacking.

The name `JfrNonReentrant` seems a little general for how tightly coupled the property is to running on a virtual thread and loading an oop. At the same time this is currently the only interaction which exhibits problems with reentry, and I am not sure if there is a better name.

-------------

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24209#pullrequestreview-2717293129

From eosterlund at openjdk.org  Wed Mar 26 15:11:14 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 26 Mar 2025 15:11:14 GMT
Subject: RFR: 8348907: Stress times out when is executed with ZGC [v7]
In-Reply-To: <ppX8fsx74X3xogl5drStjP81pvPFE59rmSJLZcrZAdw=.565fb31d-1195-42d8-bb1c-ba287d3e12ff@github.com>
References: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
 <ppX8fsx74X3xogl5drStjP81pvPFE59rmSJLZcrZAdw=.565fb31d-1195-42d8-bb1c-ba287d3e12ff@github.com>
Message-ID: <ABztQO5FRyu5MvK3PIAKFo3U7Lol8nCjr_P-dOQ72hE=.173336b4-b1fd-4de4-969b-3798bc1dc353@github.com>

On Tue, 25 Mar 2025 17:13:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Here is a suggested solution for solving the intricate deadlock issues involving virtual threads, ZGC load barriers, and JFR.
>> 
>> A JFR event can be allocated and committed in specific sensitive contexts, such as inside mutex-protected load barriers. If the thread is a virtual thread, JFR determines its thread name by loading the oop from the thread (jt->vthread()) as part of the event commit.
>> 
>> This operation again triggers the load barrier, which contains a non-reentrant lock, effectively deadlocking the thread with itself.
>> 
>> So, for specific sensitive event sites, JFR mustn't recurse or reenter into the same event site as part of the event commit.
>> 
>> After a few iterations and prototypes, which failed because they eventually ended up touching some oop, I came up with the following.
>> 
>> From a user perspective, an event (site) can now be marked as "non-reentrant" by wrapping it in a helper class.
>> 
>> This instruction now guarantees JFR will not reenter this site again as part of the event.commit().
>> 
>> The tradeoff is that we cannot write the virtual thread name for these sensitive event sites; we will instead report "" as the virtual thread name, which is the default virtual thread name in Java. All other information about the thread, such as the thread ID, virtual thread, etc., will still be reported.
>> 
>> I believe it is a reasonable tradeoff and a general solution for sensitive JFR event sites, which are rare in practice, with minimal impact on event programming.
>> 
>> Testing: jdk_jfr, stress testing
>> 
>> Let me know what you think.
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delegate thread assert

This seems like a pragmatic workaround for the problem. We might want to revisit this at some point to make it easier to use JFR in the GC code, but I think this is an appropriate fix for the bug right now. Thanks for fixing this Markus.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24209#pullrequestreview-2717616819

From shade at openjdk.org  Wed Mar 26 15:47:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Mar 2025 15:47:28 GMT
Subject: RFR: 8351925: JFR: Microsecond time format precision for JFR tool
In-Reply-To: <Xt2ThwDjnuvu-MAdTEZfRLFhW23XmrpcFBXbRnavz5U=.aa06bc60-b3d1-4e1d-af6b-0b6d81760890@github.com>
References: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>
 <Xt2ThwDjnuvu-MAdTEZfRLFhW23XmrpcFBXbRnavz5U=.aa06bc60-b3d1-4e1d-af6b-0b6d81760890@github.com>
Message-ID: <QcC4SRcjstUTLW7G9NK-eBH8coDLPNJs6nriDxnuuGE=.e301807a-8b92-4e97-a9ae-84ea7907127a@github.com>

On Fri, 14 Mar 2025 16:17:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 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.

I understand, no pressure.

I do see folks in my vicinity (myself included) reaching for human-readable output for quick and dirty analysis. Very often that human-readable output is really great to quickly capture what is going on. At the scales we operate on, it is useful to see microseconds to correlate events happening within a millisecond. Switching to JSON does work, but it feels like an unnecessary friction.

Microsecond precision for timings is not uncommon. For example, Linux perf tools routinely report ISO 8601 timestamps with microsecond precision.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24029#issuecomment-2754890252

From mgronlun at openjdk.org  Wed Mar 26 17:33:22 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 26 Mar 2025 17:33:22 GMT
Subject: Integrated: 8348907: Stress times out when is executed with ZGC
In-Reply-To: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
References: <HwzfSwqgFeiLm9DKuvdb8nePYtQ6jrL5XiP_xVPyfII=.fe37ce60-76de-43bb-b660-3d0af7a1b6d9@github.com>
Message-ID: <r-rVcio-xzckAn5QKWUt4Pa8QpfWR2UFpocKdQ2LCKQ=.d8d81412-3287-4f02-b724-473f7edd6ed7@github.com>

On Mon, 24 Mar 2025 22:26:57 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Here is a suggested solution for solving the intricate deadlock issues involving virtual threads, ZGC load barriers, and JFR.
> 
> A JFR event can be allocated and committed in specific sensitive contexts, such as inside mutex-protected load barriers. If the thread is a virtual thread, JFR determines its thread name by loading the oop from the thread (jt->vthread()) as part of the event commit.
> 
> This operation again triggers the load barrier, which contains a non-reentrant lock, effectively deadlocking the thread with itself.
> 
> So, for specific sensitive event sites, JFR mustn't recurse or reenter into the same event site as part of the event commit.
> 
> After a few iterations and prototypes, which failed because they eventually ended up touching some oop, I came up with the following.
> 
> From a user perspective, an event (site) can now be marked as "non-reentrant" by wrapping it in a helper class.
> 
> This instruction now guarantees JFR will not reenter this site again as part of the event.commit().
> 
> The tradeoff is that we cannot write the virtual thread name for these sensitive event sites; we will instead report "" as the virtual thread name, which is the default virtual thread name in Java. All other information about the thread, such as the thread ID, virtual thread, etc., will still be reported.
> 
> I believe it is a reasonable tradeoff and a general solution for sensitive JFR event sites, which are rare in practice, with minimal impact on event programming.
> 
> Testing: jdk_jfr, stress testing
> 
> Let me know what you think.
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: c2a4fed9
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2a4fed98c4e17880dd40c19cb73072efea8c583
Stats:     142 lines in 10 files changed: 119 ins; 13 del; 10 mod

8348907: Stress times out when is executed with ZGC

Reviewed-by: egahlin, aboldtch, eosterlund

-------------

PR: https://git.openjdk.org/jdk/pull/24209

From shade at openjdk.org  Fri Mar 28 20:15:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Mar 2025 20:15:21 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <B6rSckDzEk7ZqJxFp-RwScurGZN-XbCy0inEHXomHMI=.028a6f99-3905-4888-9821-d9f848db2686@github.com>

On Fri, 28 Mar 2025 15:38:59 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

A drive-by comment, since I am cleaning up some of x86 code after x86_32 removals:

src/hotspot/cpu/x86/interp_masm_x86.cpp line 791:

> 789: 
> 790:   // Thread argument
> 791:   mov(c_rarg0, r15_thread);

`movptr`, I'd think?

src/hotspot/cpu/x86/interp_masm_x86.cpp line 796:

> 794:   Label L_ljf, L_valid_rbp;
> 795:   testptr(rbp, rbp);
> 796:   jcc(Assembler::notZero, L_valid_rbp);

Little trivia about x86: "normal" jumps are fairly long (6 bytes, IIRC), but you can have a "short jump" (about 3 bytes, IIRC) if the offset is small. This is normally handled by assembler itself, when it knows where the branch target is. That is known for _backward_ branches. For _forward_ branches like this, we unfortunately often need to claim the jump is short ahead of time. See `jccb` (note `b`). 

Basically, if you are sure the branch target is within 128 bytes (or, more likely, a few instructions) away, use `jccb`.

Same thing with `jmp` -> `jmpb`.

src/hotspot/cpu/x86/interp_masm_x86.cpp line 1045:

> 1043:   Label slow_path;
> 1044:   Label fast_path;
> 1045:   safepoint_poll(slow_path, rthread, current_fp, true /* at_return */, false /* in_nmethod */);

A little heads-up: I am going to propose a little cleanup soon to drop `rthread` from x86 safepoint_pool (we can trust it is `r15_thread` always). That would probably yield a minor merge conflict here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24296#pullrequestreview-2726620088
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2019283641
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2019283404
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2019285766

From mgronlun at openjdk.org  Fri Mar 28 21:17:24 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 28 Mar 2025 21:17:24 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v2]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <IWnT-075RvnHn2VFoGXU5g4lDXOQAWtJouBmFjCkxh8=.b16e19cb-cb35-4be4-bc59-92123b11b803@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  refactoring

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/cb6e5aab..7998b7c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=00-01

  Stats: 218 lines in 8 files changed: 48 ins; 106 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Fri Mar 28 21:24:15 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 28 Mar 2025 21:24:15 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v3]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <LJwcoksfWjpZ74bA0juZMkhC4gZxToXp8ppAob6YpuE=.e38e120a-9d59-4f01-aa7e-5cb104c436d0@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:

 - align params
 - adjustments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/7998b7c1..1015a8c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=01-02

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From duke at openjdk.org  Sat Mar 29 11:23:27 2025
From: duke at openjdk.org (Zihao Lin)
Date: Sat, 29 Mar 2025 11:23:27 GMT
Subject: RFR: 8352879: TestPeriod.java and TestGetContentType.java run wrong
 test class
Message-ID: <Q2QOW7-ruK2gS4To9MTq9_YUsjCYjbYn0Gyz2JEgFSk=.fa295a3f-baf2-4c9a-82b7-e71fe1dea28d@github.com>

Fix TestPeriod.java and TestGetContentType.java run wrong test class.

-------------

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8352879
 - fix tests

Changes: https://git.openjdk.org/jdk/pull/24312/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24312&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352879
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24312.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24312/head:pull/24312

PR: https://git.openjdk.org/jdk/pull/24312

From mgronlun at openjdk.org  Sat Mar 29 13:06:10 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 29 Mar 2025 13:06:10 GMT
Subject: RFR: 8352879: TestPeriod.java and TestGetContentType.java run
 wrong test class
In-Reply-To: <Q2QOW7-ruK2gS4To9MTq9_YUsjCYjbYn0Gyz2JEgFSk=.fa295a3f-baf2-4c9a-82b7-e71fe1dea28d@github.com>
References: <Q2QOW7-ruK2gS4To9MTq9_YUsjCYjbYn0Gyz2JEgFSk=.fa295a3f-baf2-4c9a-82b7-e71fe1dea28d@github.com>
Message-ID: <Kcnr6CI5Qj1gkQdeV_juFA6MHF64lUkmnxJRsra_dsU=.a99f36d3-cba5-416a-8bb7-0d9fd29fa404@github.com>

On Sat, 29 Mar 2025 11:18:27 GMT, Zihao Lin <duke at openjdk.org> wrote:

> Fix TestPeriod.java and TestGetContentType.java run wrong test class.

Marked as reviewed by mgronlun (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24312#pullrequestreview-2727363662

From duke at openjdk.org  Sat Mar 29 13:06:11 2025
From: duke at openjdk.org (duke)
Date: Sat, 29 Mar 2025 13:06:11 GMT
Subject: RFR: 8352879: TestPeriod.java and TestGetContentType.java run
 wrong test class
In-Reply-To: <Q2QOW7-ruK2gS4To9MTq9_YUsjCYjbYn0Gyz2JEgFSk=.fa295a3f-baf2-4c9a-82b7-e71fe1dea28d@github.com>
References: <Q2QOW7-ruK2gS4To9MTq9_YUsjCYjbYn0Gyz2JEgFSk=.fa295a3f-baf2-4c9a-82b7-e71fe1dea28d@github.com>
Message-ID: <iqG87aGBh2dLtpFrMPYR5hrNrm3kH66vz5y3cgaLD40=.6304d7fe-47e8-4b22-9d0f-c3b3d883fb80@github.com>

On Sat, 29 Mar 2025 11:18:27 GMT, Zihao Lin <duke at openjdk.org> wrote:

> Fix TestPeriod.java and TestGetContentType.java run wrong test class.

@linzihao1999 
Your change (at version 87b5bbaa21026ab7c2d927f8c328d1ac623433f4) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24312#issuecomment-2763355644

From mgronlun at openjdk.org  Sun Mar 30 12:13:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 30 Mar 2025 12:13:55 GMT
Subject: RFR: 8353226: JFR: emit old object samples must be transitive closure
 complete for segment
Message-ID: <s-xrITYe1SlIE7vkI94ZXXuY34fyXmeki2s6doOFIQc=.8671e792-3341-451c-8a6f-fde067291255@github.com>

Greetings,

EventEmitter::write_events() only serializes blobified stack traces as part of old object checkpoint serialization. Still, it categorically writes a stack trace id as part of the event, even for non-blobified stack traces. As a result, the segment is incomplete. Stack traces must be serialized directly from the leak profiler repository to ensure closure. 

Testing: jdk_jfr

Thanks
Markus

-------------

Commit messages:
 - 8353226

Changes: https://git.openjdk.org/jdk/pull/24316/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24316&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353226
  Stats: 63 lines in 5 files changed: 59 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24316.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24316/head:pull/24316

PR: https://git.openjdk.org/jdk/pull/24316

From mgronlun at openjdk.org  Sun Mar 30 12:17:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 30 Mar 2025 12:17:52 GMT
Subject: RFR: 8353226: JFR: emit old object samples must be transitive
 closure complete for segment [v2]
In-Reply-To: <s-xrITYe1SlIE7vkI94ZXXuY34fyXmeki2s6doOFIQc=.8671e792-3341-451c-8a6f-fde067291255@github.com>
References: <s-xrITYe1SlIE7vkI94ZXXuY34fyXmeki2s6doOFIQc=.8671e792-3341-451c-8a6f-fde067291255@github.com>
Message-ID: <IS97W-3TLpv7YJ1OWJpHeHrwghWxVwc4f2yehnSVZKE=.e7c0eb17-5bcb-44e2-ac24-40969f7df9da@github.com>

> Greetings,
> 
> EventEmitter::write_events() only serializes blobified stack traces as part of old object checkpoint serialization. Still, it categorically writes a stack trace id as part of the event, even for non-blobified stack traces. As a result, the segment is incomplete. Stack traces must be serialized directly from the leak profiler repository to ensure closure. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  align

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24316/files
  - new: https://git.openjdk.org/jdk/pull/24316/files/e0c8f1a3..61f2a8ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24316&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24316&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24316.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24316/head:pull/24316

PR: https://git.openjdk.org/jdk/pull/24316

From duke at openjdk.org  Sun Mar 30 13:17:20 2025
From: duke at openjdk.org (Zihao Lin)
Date: Sun, 30 Mar 2025 13:17:20 GMT
Subject: Integrated: 8352879: TestPeriod.java and TestGetContentType.java run
 wrong test class
In-Reply-To: <Q2QOW7-ruK2gS4To9MTq9_YUsjCYjbYn0Gyz2JEgFSk=.fa295a3f-baf2-4c9a-82b7-e71fe1dea28d@github.com>
References: <Q2QOW7-ruK2gS4To9MTq9_YUsjCYjbYn0Gyz2JEgFSk=.fa295a3f-baf2-4c9a-82b7-e71fe1dea28d@github.com>
Message-ID: <hhl4094msFDlSgZUUqfb8I9WrGKRWYYTeb0cTKzu1Lc=.7fb23f27-f5a9-4dd8-8779-5226e62b0055@github.com>

On Sat, 29 Mar 2025 11:18:27 GMT, Zihao Lin <duke at openjdk.org> wrote:

> Fix TestPeriod.java and TestGetContentType.java run wrong test class.

This pull request has now been integrated.

Changeset: b9d7a75a
Author:    Zihao Lin <linzihao1999 at outlook.com>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9d7a75adee8a96cf47bbe73e3009102ceda9589
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8352879: TestPeriod.java and TestGetContentType.java run wrong test class

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.org/jdk/pull/24312

From mgronlun at openjdk.org  Sun Mar 30 14:24:21 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 30 Mar 2025 14:24:21 GMT
Subject: RFR: 8353227: JFR: Prepare tests for strong parser validation
Message-ID: <1zSx97jayNH2vCa2KAfPPckBZwQ-EaInBQXl7gMVbJM=.cfdb8caa-ccd8-48da-bce7-0fd383af7b53@github.com>

Greetings,

Tests:

- jdk/jfr/jvm/TestDumpOnCrash.java
- jdk/jfr/event/runtime/TestShutdownEvent.java

Cannot run with -esa in combination with [JDK-8351698](https://bugs.openjdk.org/browse/JDK-8351698), because parser invariants are not guaranteed for emergency dumps, which are provided on a best-effort basis only.

Testing: jdk_jfr

Thanks
Markus

-------------

Commit messages:
 - 8353227

Changes: https://git.openjdk.org/jdk/pull/24317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24317&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353227
  Stats: 38 lines in 2 files changed: 38 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24317/head:pull/24317

PR: https://git.openjdk.org/jdk/pull/24317

From dholmes at openjdk.org  Mon Mar 31 00:39:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Mar 2025 00:39:14 GMT
Subject: RFR: 8352879: TestPeriod.java and TestGetContentType.java run
 wrong test class
In-Reply-To: <Q2QOW7-ruK2gS4To9MTq9_YUsjCYjbYn0Gyz2JEgFSk=.fa295a3f-baf2-4c9a-82b7-e71fe1dea28d@github.com>
References: <Q2QOW7-ruK2gS4To9MTq9_YUsjCYjbYn0Gyz2JEgFSk=.fa295a3f-baf2-4c9a-82b7-e71fe1dea28d@github.com>
Message-ID: <gbS1uktH3KoVqnjaqkOaRkAc2QZyuGvEOTA4d2Nfs_w=.830c5325-444b-41dc-94c3-d75871638ee5@github.com>

On Sat, 29 Mar 2025 11:18:27 GMT, Zihao Lin <duke at openjdk.org> wrote:

> Fix TestPeriod.java and TestGetContentType.java run wrong test class.

TestPeriod.java now fails on all platforms for us - JDK-8353235

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24312#issuecomment-2764843368

From duke at openjdk.org  Mon Mar 31 02:46:14 2025
From: duke at openjdk.org (Zihao Lin)
Date: Mon, 31 Mar 2025 02:46:14 GMT
Subject: RFR: 8352879: TestPeriod.java and TestGetContentType.java run
 wrong test class
In-Reply-To: <Q2QOW7-ruK2gS4To9MTq9_YUsjCYjbYn0Gyz2JEgFSk=.fa295a3f-baf2-4c9a-82b7-e71fe1dea28d@github.com>
References: <Q2QOW7-ruK2gS4To9MTq9_YUsjCYjbYn0Gyz2JEgFSk=.fa295a3f-baf2-4c9a-82b7-e71fe1dea28d@github.com>
Message-ID: <yNZCG70o0vgUAEjTks7ugArPMbb01whxQje2_bd6Y_w=.b3723d51-1d89-442c-b827-6141ed2be6fb@github.com>

On Sat, 29 Mar 2025 11:18:27 GMT, Zihao Lin <duke at openjdk.org> wrote:

> Fix TestPeriod.java and TestGetContentType.java run wrong test class.

Sorry I also notice that. What is next step, Should I revert this commit?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24312#issuecomment-2764963676

From syan at openjdk.org  Mon Mar 31 03:31:24 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 31 Mar 2025 03:31:24 GMT
Subject: RFR: 8352879: TestPeriod.java and TestGetContentType.java run
 wrong test class
In-Reply-To: <gbS1uktH3KoVqnjaqkOaRkAc2QZyuGvEOTA4d2Nfs_w=.830c5325-444b-41dc-94c3-d75871638ee5@github.com>
References: <Q2QOW7-ruK2gS4To9MTq9_YUsjCYjbYn0Gyz2JEgFSk=.fa295a3f-baf2-4c9a-82b7-e71fe1dea28d@github.com>
 <gbS1uktH3KoVqnjaqkOaRkAc2QZyuGvEOTA4d2Nfs_w=.830c5325-444b-41dc-94c3-d75871638ee5@github.com>
Message-ID: <bL-AzpA5eO7LL6Aim05R4SN0R3-zppnFTE7oClDfVm0=.f55d4d3f-605b-4c22-8edd-bcca02026050@github.com>

On Mon, 31 Mar 2025 00:36:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> TestPeriod.java now fails on all platforms for us - JDK-8353235

Seems that it has a bug in the original test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24312#issuecomment-2765006544

From syan at openjdk.org  Mon Mar 31 03:44:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 31 Mar 2025 03:44:04 GMT
Subject: RFR: 8353235: Test jdk/jfr/api/metadata/annotations/TestPeriod.java
 fails with IllegalArgumentException
Message-ID: <8o3hWsX49I5eRgUxWTKwD6Wdzscd0qEJ7Qxu1wUF-qU=.31c3a91d-7091-4097-ab59-2876eb7c867d@github.com>

Hi all,

In test jdk/jfr/api/metadata/annotations/TestPeriod.java, the tested class `PeriodicEvent` extends `Event`, bug `Event` has three event types `enabled/stackTrace/threshold` by default. So we need to add `period` event type before test manually.

Change has been verified locally, test-fix only, no risk.

-------------

Commit messages:
 - 8353235: Test jdk/jfr/api/metadata/annotations/TestPeriod.java fails with IllegalArgumentException

Changes: https://git.openjdk.org/jdk/pull/24320/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24320&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353235
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24320.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24320/head:pull/24320

PR: https://git.openjdk.org/jdk/pull/24320

From egahlin at openjdk.org  Mon Mar 31 10:58:13 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 31 Mar 2025 10:58:13 GMT
Subject: RFR: 8351925: JFR: Microsecond time format precision for JFR tool
In-Reply-To: <QcC4SRcjstUTLW7G9NK-eBH8coDLPNJs6nriDxnuuGE=.e301807a-8b92-4e97-a9ae-84ea7907127a@github.com>
References: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>
 <Xt2ThwDjnuvu-MAdTEZfRLFhW23XmrpcFBXbRnavz5U=.aa06bc60-b3d1-4e1d-af6b-0b6d81760890@github.com>
 <QcC4SRcjstUTLW7G9NK-eBH8coDLPNJs6nriDxnuuGE=.e301807a-8b92-4e97-a9ae-84ea7907127a@github.com>
Message-ID: <7KKSaBY0O-xQR0XKyJPiOLpduAfTbUKa5ZLrhNnR3Eg=.8e5318ef-141d-4fc1-8ba8-db212a65301c@github.com>

On Wed, 26 Mar 2025 15:44:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I do see folks in my vicinity (myself included) reaching for human-readable output for quick and dirty analysis. Very often that human-readable output is really great to quickly capture what is going on. At the scales we operate on, it is useful to see microseconds to correlate events happening within a millisecond. Switching to JSON does work, but it feels like an unnecessary friction.
> 
> Microsecond precision for timings is not uncommon. For example, Linux perf tools routinely report ISO 8601 timestamps with microsecond precision.

The output from PrettyWriter is used by RecordedEvent::toString(), so it serves more than one purpose. What is the primary friction you see in --json? The verbose stack traces, too much precision, or the need to specify a command-line flag?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24029#issuecomment-2765870818

From shade at openjdk.org  Mon Mar 31 11:07:19 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 31 Mar 2025 11:07:19 GMT
Subject: RFR: 8351925: JFR: Microsecond time format precision for JFR tool
In-Reply-To: <7KKSaBY0O-xQR0XKyJPiOLpduAfTbUKa5ZLrhNnR3Eg=.8e5318ef-141d-4fc1-8ba8-db212a65301c@github.com>
References: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>
 <Xt2ThwDjnuvu-MAdTEZfRLFhW23XmrpcFBXbRnavz5U=.aa06bc60-b3d1-4e1d-af6b-0b6d81760890@github.com>
 <QcC4SRcjstUTLW7G9NK-eBH8coDLPNJs6nriDxnuuGE=.e301807a-8b92-4e97-a9ae-84ea7907127a@github.com>
 <7KKSaBY0O-xQR0XKyJPiOLpduAfTbUKa5ZLrhNnR3Eg=.8e5318ef-141d-4fc1-8ba8-db212a65301c@github.com>
Message-ID: <qqyuRJPVBXk5BpVdzvU-mqDnh0sbsSN2XjFwOIC8PkI=.08703bd2-fd6e-48fe-bd47-dcb47867d34b@github.com>

On Mon, 31 Mar 2025 10:55:30 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> What is the primary friction you see in --json? The verbose stack traces, too much precision, or the need to specify a command-line flag?

JSON is too verbose for human consumption. I think this is mostly due to stack traces, but there are also other parts that are relatively noisy. So I cannot easily show the pair of events in a bug report / chat message to show a particular piece of JFR-captured info, without first truncating the output.

Compare the human-readable output for the same event:


jdk.JavaMonitorNotify {
  startTime = 19:09:11.996
  duration = 0.000602 ms
  monitorClass = java.lang.Object (classLoader = bootstrap)
  notifiedCount = 1
  address = 0x7C6F54001250
  eventThread = "main" (javaThreadId = 3)
  stackTrace = [
    java.lang.Object.notifyAll()
    NotifyWaitLatency.work() line: 22
    NotifyWaitLatency.main(String[]) line: 4
    jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Object, Object[]) line: 104
    java.lang.reflect.Method.invoke(Object, Object[]) line: 565
  ] 
}


...and JSON one:


      "type": "jdk.JavaMonitorNotify", 
      "values": {
        "startTime": "2025-03-14T19:09:11.996604879+01:00", 
        "duration": "PT0.000000602S", 
        "eventThread": {
          "osName": "main", 
          "osThreadId": 963561, 
          "javaName": "main", 
          "javaThreadId": 3, 
          "group": {
            "parent": {
              "parent": null, 
              "name": "system"
            }, 
            "name": "main"
          }, 
          "virtual": false
        }, 
        "stackTrace": {
          "truncated": false, 
          "frames": [{
            "method": {
              "type": {
                "classLoader": {
                  "type": null, 
                  "name": "bootstrap"
                }, 
                "name": "java/lang/Object", 
                "package": {
                  "name": "java/lang", 
                  "module": {
                    "name": "java.base", 
                    "version": "25-internal", 
                    "location": "jrt:/java.base", 
                    "classLoader": {
                      "type": null, 
                      "name": "bootstrap"
                    }
                  }, 
                  "exported": true
                }, 
                "modifiers": 1, 
                "hidden": false
              }, 
              "name": "notifyAll", 
              "descriptor": "()V", 
              "modifiers": 273, 
              "hidden": false
            }, 
            "lineNumber": -1, 
            "bytecodeIndex": 0, 
            "type": "Native"
          }, {
            "method": {
              "type": {
                "classLoader": {
                  "type": {
                    "classLoader": {
                      "type": {
                        "classLoader": {
                          "type": null, 
                          "name": "bootstrap"
                        }, 
                        "name": "jdk/internal/loader/ClassLoaders$AppClassLoader", 
                        "package": {
                          "name": "jdk/internal/loader", 
                          "module": {
                            "name": "java.base", 
                            "version": "25-internal", 
                            "location": "jrt:/java.base", 
                            "classLoader": {
                              "type": null, 
                              "name": "bootstrap"
                            }
                          }, 
                          "exported": true
                        }, 
                        "modifiers": 10, 
                        "hidden": false
                      }, 
                      "name": "app"
                    }, 
                    "name": "com/sun/tools/javac/launcher/MemoryClassLoader", 
                    "package": {
                      "name": "com/sun/tools/javac/launcher", 
                      "module": {
                        "name": "jdk.compiler", 
                        "version": "25-internal", 
                        "location": "jrt:/jdk.compiler", 
                        "classLoader": {
                          "type": {
                            "classLoader": {
                              "type": null, 
                              "name": "bootstrap"
                            }, 
                            "name": "jdk/internal/loader/ClassLoaders$AppClassLoader", 
                            "package": {
                              "name": "jdk/internal/loader", 
                              "module": {
                                "name": "java.base", 
                                "version": "25-internal", 
                                "location": "jrt:/java.base", 
                                "classLoader": {
                                  "type": null, 
                                  "name": "bootstrap"
                                }
                              }, 
                              "exported": true
                            }, 
                            "modifiers": 10, 
                            "hidden": false
                          }, 
                          "name": "app"
                        }
                      }, 
                      "exported": false
                    }, 
                    "modifiers": 16, 
                    "hidden": false
                  }, 
                  "name": null
                }, 
                "name": "NotifyWaitLatency", 
                "package": null, 
                "modifiers": 1, 
                "hidden": false
              }, 
              "name": "work", 
              "descriptor": "()V", 
              "modifiers": 9, 
              "hidden": false
            }, 
            "lineNumber": 22, 
            "bytecodeIndex": 44, 
            "type": "Interpreted"
          }, {
            "method": {
              "type": {
                "classLoader": {
                  "type": {
                    "classLoader": {
                      "type": {
                        "classLoader": {
                          "type": null, 
                          "name": "bootstrap"
                        }, 
                        "name": "jdk/internal/loader/ClassLoaders$AppClassLoader", 
                        "package": {
                          "name": "jdk/internal/loader", 
                          "module": {
                            "name": "java.base", 
                            "version": "25-internal", 
                            "location": "jrt:/java.base", 
                            "classLoader": {
                              "type": null, 
                              "name": "bootstrap"
                            }
                          }, 
                          "exported": true
                        }, 
                        "modifiers": 10, 
                        "hidden": false
                      }, 
                      "name": "app"
                    }, 
                    "name": "com/sun/tools/javac/launcher/MemoryClassLoader", 
                    "package": {
                      "name": "com/sun/tools/javac/launcher", 
                      "module": {
                        "name": "jdk.compiler", 
                        "version": "25-internal", 
                        "location": "jrt:/jdk.compiler", 
                        "classLoader": {
                          "type": {
                            "classLoader": {
                              "type": null, 
                              "name": "bootstrap"
                            }, 
                            "name": "jdk/internal/loader/ClassLoaders$AppClassLoader", 
                            "package": {
                              "name": "jdk/internal/loader", 
                              "module": {
                                "name": "java.base", 
                                "version": "25-internal", 
                                "location": "jrt:/java.base", 
                                "classLoader": {
                                  "type": null, 
                                  "name": "bootstrap"
                                }
                              }, 
                              "exported": true
                            }, 
                            "modifiers": 10, 
                            "hidden": false
                          }, 
                          "name": "app"
                        }
                      }, 
                      "exported": false
                    }, 
                    "modifiers": 16, 
                    "hidden": false
                  }, 
                  "name": null
                }, 
                "name": "NotifyWaitLatency", 
                "package": null, 
                "modifiers": 1, 
                "hidden": false
              }, 
              "name": "main", 
              "descriptor": "([Ljava/lang/String;)V", 
              "modifiers": 137, 
              "hidden": false
            }, 
            "lineNumber": 4, 
            "bytecodeIndex": 8, 
            "type": "Interpreted"
          }, {
            "method": {
              "type": {
                "classLoader": null, 
                "name": "java.lang.invoke.LambdaForm$DMH/0x00007c6fe7001400", 
                "package": {
                  "name": "java/lang/invoke", 
                  "module": {
                    "name": "java.base", 
                    "version": "25-internal", 
                    "location": "jrt:/java.base", 
                    "classLoader": {
                      "type": null, 
                      "name": "bootstrap"
                    }
                  }, 
                  "exported": true
                }, 
                "modifiers": 16, 
                "hidden": true
              }, 
              "name": "invokeStatic", 
              "descriptor": "(Ljava/lang/Object;Ljava/lang/Object;)V", 
              "modifiers": 8, 
              "hidden": true
            }, 
            "lineNumber": -1, 
            "bytecodeIndex": 10, 
            "type": "Interpreted"
          }, {
            "method": {
              "type": {
                "classLoader": null, 
                "name": "java.lang.invoke.LambdaForm$MH/0x00007c6fe7191000", 
                "package": {
                  "name": "java/lang/invoke", 
                  "module": {
                    "name": "java.base", 
                    "version": "25-internal", 
                    "location": "jrt:/java.base", 
                    "classLoader": {
                      "type": null, 
                      "name": "bootstrap"
                    }
                  }, 
                  "exported": true
                }, 
                "modifiers": 16, 
                "hidden": true
              }, 
              "name": "invoke", 
              "descriptor": "(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;", 
              "modifiers": 8, 
              "hidden": true
            }, 
            "lineNumber": -1, 
            "bytecodeIndex": 33, 
            "type": "Interpreted"
          }]
        }, 
        "monitorClass": {
          "classLoader": {
            "type": null, 
            "name": "bootstrap"
          }, 
          "name": "java/lang/Object", 
          "package": {
            "name": "java/lang", 
            "module": {
              "name": "java.base", 
              "version": "25-internal", 
              "location": "jrt:/java.base", 
              "classLoader": {
                "type": null, 
                "name": "bootstrap"
              }
            }, 
            "exported": true
          }, 
          "modifiers": 1, 
          "hidden": false
        }, 
        "notifiedCount": 1, 
        "address": 136817592504912
      }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24029#issuecomment-2765898065

From egahlin at openjdk.org  Mon Mar 31 13:45:37 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 31 Mar 2025 13:45:37 GMT
Subject: RFR: 8353226: JFR: emit old object samples must be transitive
 closure complete for segment [v2]
In-Reply-To: <IS97W-3TLpv7YJ1OWJpHeHrwghWxVwc4f2yehnSVZKE=.e7c0eb17-5bcb-44e2-ac24-40969f7df9da@github.com>
References: <s-xrITYe1SlIE7vkI94ZXXuY34fyXmeki2s6doOFIQc=.8671e792-3341-451c-8a6f-fde067291255@github.com>
 <IS97W-3TLpv7YJ1OWJpHeHrwghWxVwc4f2yehnSVZKE=.e7c0eb17-5bcb-44e2-ac24-40969f7df9da@github.com>
Message-ID: <oYVQuL6mq3mTXTH_YNk7i0-J1aZexlW0FwhaaQVZlok=.dae99cbe-35f5-4dd3-a9bf-0b86453415f3@github.com>

On Sun, 30 Mar 2025 12:17:52 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> EventEmitter::write_events() only serializes blobified stack traces as part of old object checkpoint serialization. Still, it categorically writes a stack trace id as part of the event, even for non-blobified stack traces. As a result, the segment is incomplete. Stack traces must be serialized directly from the leak profiler repository to ensure closure. 
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   align

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24316#pullrequestreview-2729349102

From egahlin at openjdk.org  Mon Mar 31 13:46:08 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 31 Mar 2025 13:46:08 GMT
Subject: RFR: 8353227: JFR: Prepare tests for strong parser validation
In-Reply-To: <1zSx97jayNH2vCa2KAfPPckBZwQ-EaInBQXl7gMVbJM=.cfdb8caa-ccd8-48da-bce7-0fd383af7b53@github.com>
References: <1zSx97jayNH2vCa2KAfPPckBZwQ-EaInBQXl7gMVbJM=.cfdb8caa-ccd8-48da-bce7-0fd383af7b53@github.com>
Message-ID: <lXm85QmVa4_1AUEubWgwXxTG-PWbjCCCwZFxyiqkQGU=.5d66b36d-f4bf-478d-af30-90605e0689ed@github.com>

On Sun, 30 Mar 2025 14:19:31 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Tests:
> 
> - jdk/jfr/jvm/TestDumpOnCrash.java
> - jdk/jfr/event/runtime/TestShutdownEvent.java
> 
> Cannot run with -esa in combination with [JDK-8351698](https://bugs.openjdk.org/browse/JDK-8351698), because parser invariants are not guaranteed for emergency dumps, which are provided on a best-effort basis only.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24317#pullrequestreview-2729351581

From mgronlun at openjdk.org  Mon Mar 31 14:22:36 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 31 Mar 2025 14:22:36 GMT
Subject: RFR: 8353227: JFR: Prepare tests for strong parser validation [v2]
In-Reply-To: <1zSx97jayNH2vCa2KAfPPckBZwQ-EaInBQXl7gMVbJM=.cfdb8caa-ccd8-48da-bce7-0fd383af7b53@github.com>
References: <1zSx97jayNH2vCa2KAfPPckBZwQ-EaInBQXl7gMVbJM=.cfdb8caa-ccd8-48da-bce7-0fd383af7b53@github.com>
Message-ID: <OEPXthOID27y9KZqgd9zFeF6LGo03TeunZwPf5Roc6A=.3b8f69d7-4941-4554-b30a-b2df7978476e@github.com>

> Greetings,
> 
> Tests:
> 
> - jdk/jfr/jvm/TestDumpOnCrash.java
> - jdk/jfr/event/runtime/TestShutdownEvent.java
> 
> Cannot run with -esa in combination with [JDK-8351698](https://bugs.openjdk.org/browse/JDK-8351698), because parser invariants are not guaranteed for emergency dumps, which are provided on a best-effort basis only.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  include also stream TestJVMCrash.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24317/files
  - new: https://git.openjdk.org/jdk/pull/24317/files/a36ee311..7937b3dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24317&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24317&range=00-01

  Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24317/head:pull/24317

PR: https://git.openjdk.org/jdk/pull/24317

From egahlin at openjdk.org  Mon Mar 31 14:55:34 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 31 Mar 2025 14:55:34 GMT
Subject: RFR: 8353235: Test
 jdk/jfr/api/metadata/annotations/TestPeriod.java fails with
 IllegalArgumentException
In-Reply-To: <8o3hWsX49I5eRgUxWTKwD6Wdzscd0qEJ7Qxu1wUF-qU=.31c3a91d-7091-4097-ab59-2876eb7c867d@github.com>
References: <8o3hWsX49I5eRgUxWTKwD6Wdzscd0qEJ7Qxu1wUF-qU=.31c3a91d-7091-4097-ab59-2876eb7c867d@github.com>
Message-ID: <0ZtLfrqRKs_QDvjhd_OgP89Yn4gxk1CdcJ2CpefKFKA=.5cc6189d-4c80-45c5-9529-303a6c62a2ca@github.com>

On Mon, 31 Mar 2025 03:38:34 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> In test jdk/jfr/api/metadata/annotations/TestPeriod.java, the tested class `PeriodicEvent` extends `Event`, bug `Event` has three event types `enabled/stackTrace/threshold` by default. So we need to add `period` event type before test manually.
> 
> Change has been verified locally, test-fix only, no risk.

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24320#pullrequestreview-2729581763

From syan at openjdk.org  Mon Mar 31 15:50:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 31 Mar 2025 15:50:15 GMT
Subject: RFR: 8353235: Test
 jdk/jfr/api/metadata/annotations/TestPeriod.java fails with
 IllegalArgumentException
In-Reply-To: <0ZtLfrqRKs_QDvjhd_OgP89Yn4gxk1CdcJ2CpefKFKA=.5cc6189d-4c80-45c5-9529-303a6c62a2ca@github.com>
References: <8o3hWsX49I5eRgUxWTKwD6Wdzscd0qEJ7Qxu1wUF-qU=.31c3a91d-7091-4097-ab59-2876eb7c867d@github.com>
 <0ZtLfrqRKs_QDvjhd_OgP89Yn4gxk1CdcJ2CpefKFKA=.5cc6189d-4c80-45c5-9529-303a6c62a2ca@github.com>
Message-ID: <dlpHthQPMDf79yESilHauDlxO5pkDGKbAcjftH0mSz0=.b890f767-2e32-469c-a5fb-e3d32277e3f4@github.com>

On Mon, 31 Mar 2025 14:52:36 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Hi all,
>> 
>> In test jdk/jfr/api/metadata/annotations/TestPeriod.java, the tested class `PeriodicEvent` extends `Event`, bug `Event` has three event types `enabled/stackTrace/threshold` by default. So we need to add `period` event type before test manually.
>> 
>> Change has been verified locally, test-fix only, no risk.
>
> Marked as reviewed by egahlin (Reviewer).

Thanks for the review @egahlin.

I think I should integrate this PR now, to avoid test noisy of CI/CD. Do not wait 24 hours.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24320#issuecomment-2766641795

From syan at openjdk.org  Mon Mar 31 15:50:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 31 Mar 2025 15:50:15 GMT
Subject: Integrated: 8353235: Test
 jdk/jfr/api/metadata/annotations/TestPeriod.java fails with
 IllegalArgumentException
In-Reply-To: <8o3hWsX49I5eRgUxWTKwD6Wdzscd0qEJ7Qxu1wUF-qU=.31c3a91d-7091-4097-ab59-2876eb7c867d@github.com>
References: <8o3hWsX49I5eRgUxWTKwD6Wdzscd0qEJ7Qxu1wUF-qU=.31c3a91d-7091-4097-ab59-2876eb7c867d@github.com>
Message-ID: <MbH7JBJjg_4DEGQWtiilskPQcTPVFKjBF11nLy_wiIA=.30ef205d-9635-45df-81b8-54a33bd87bb6@github.com>

On Mon, 31 Mar 2025 03:38:34 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> In test jdk/jfr/api/metadata/annotations/TestPeriod.java, the tested class `PeriodicEvent` extends `Event`, bug `Event` has three event types `enabled/stackTrace/threshold` by default. So we need to add `period` event type before test manually.
> 
> Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: b7ca76ef
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b7ca76ef4bfc640668492e655acc6d755411a92f
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8353235: Test jdk/jfr/api/metadata/annotations/TestPeriod.java fails with IllegalArgumentException

Reviewed-by: egahlin

-------------

PR: https://git.openjdk.org/jdk/pull/24320