RFR: 8259647: Add support for JFR event ObjectCountAfterGC to Shenandoah

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR: 8259647: Add support for JFR event ObjectCountAfterGC to Shenandoah

Zhengyu Gu-3
Please review this patch that adds JFR ObjectCountAfterGC event support.

AFAICT, the event is off by default. If it is enabled, it distorts Shenandoah pause characteristics, since it performs heap walk during final mark pause.

When event is disabled:
`[191.033s][info][gc,stats] Pause Init Mark (G)                 454 us`
`[191.033s][info][gc,stats] Pause Init Mark (N)                  13 us`

When event is enabled:
`[396.631s][info][gc,stats] Pause Final Mark (G)              43199 us`
`[396.631s][info][gc,stats] Pause Final Mark (N)              42982 us`

Test:
- [x] hotspot_gc_shenandoah

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

Commit messages:
 - JDK-8259647-object_count_jfr

Changes: https://git.openjdk.java.net/jdk/pull/2386/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2386&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259647
  Stats: 12 lines in 3 files changed: 6 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2386.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2386/head:pull/2386

PR: https://git.openjdk.java.net/jdk/pull/2386
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8259647: Add support for JFR event ObjectCountAfterGC to Shenandoah

earthling-amzn
On Wed, 3 Feb 2021 20:05:33 GMT, Zhengyu Gu <[hidden email]> wrote:

> Please review this patch that adds JFR ObjectCountAfterGC event support.
>
> AFAICT, the event is off by default. If it is enabled, it distorts Shenandoah pause characteristics, since it performs heap walk during final mark pause.
>
> When event is disabled:
> `[191.033s][info][gc,stats] Pause Init Mark (G)                 454 us`
> `[191.033s][info][gc,stats] Pause Init Mark (N)                  13 us`
>
> When event is enabled:
> `[396.631s][info][gc,stats] Pause Final Mark (G)              43199 us`
> `[396.631s][info][gc,stats] Pause Final Mark (N)              42982 us`
>
> Test:
> - [x] hotspot_gc_shenandoah

That certainly is bad news for pause times. Do you think it'd be feasible to "piggyback" the object count calculation on concurrent marking? Might address https://bugs.openjdk.java.net/browse/JDK-8258431 also.

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

PR: https://git.openjdk.java.net/jdk/pull/2386
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8259647: Add support for JFR event ObjectCountAfterGC to Shenandoah

Roman Kennke
On Thu, 4 Feb 2021 18:17:46 GMT, earthling-amzn <[hidden email]> wrote:

> That certainly is bad news for pause times. Do you think it'd be feasible to "piggyback" the object count calculation on concurrent marking? Might address https://bugs.openjdk.java.net/browse/JDK-8258431 also.

This could certainly be done, in a similar fashion as liveness counting. However, it would have to be done such that it only actually counts objects when JFR is requesting it, and otherwise stays out of the way, because this costs marking performance. Which means doubling the number of mark-loops, and select the correct loop based on whether or not we need object counts.

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

PR: https://git.openjdk.java.net/jdk/pull/2386
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8259647: Add support for JFR event ObjectCountAfterGC to Shenandoah

Zhengyu Gu-3
On Thu, 4 Feb 2021 18:44:24 GMT, Roman Kennke <[hidden email]> wrote:

> That certainly is bad news for pause times. Do you think it'd be feasible to "piggyback" the object count calculation on concurrent marking? Might address https://bugs.openjdk.java.net/browse/JDK-8258431 also.

It dose not just count number of objects, but number of objects by type,  much more than liveness counting. Just add a branch in hot marking loop, I can foresee negative impact on performance.

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

PR: https://git.openjdk.java.net/jdk/pull/2386
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8259647: Add support for JFR event ObjectCountAfterGC to Shenandoah

earthling-amzn
On Thu, 4 Feb 2021 19:19:35 GMT, Zhengyu Gu <[hidden email]> wrote:

>>> That certainly is bad news for pause times. Do you think it'd be feasible to "piggyback" the object count calculation on concurrent marking? Might address https://bugs.openjdk.java.net/browse/JDK-8258431 also.
>>
>> This could certainly be done, in a similar fashion as liveness counting. However, it would have to be done such that it only actually counts objects when JFR is requesting it, and otherwise stays out of the way, because this costs marking performance. Which means doubling the number of mark-loops, and select the correct loop based on whether or not we need object counts.
>
>> That certainly is bad news for pause times. Do you think it'd be feasible to "piggyback" the object count calculation on concurrent marking? Might address https://bugs.openjdk.java.net/browse/JDK-8258431 also.
>
> It dose not just count number of objects, but number of objects by type,  much more than liveness counting. Just add a branch in hot marking loop, I can foresee negative impact on performance.

Would it be possible to combine the object _counting_ closure and the object _marking_ closure into one aggregate closure and complete both calculations in one pass over the live objects? Of course, only do this when the JFR event is enabled (and even then, perhaps only do it periodically).

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

PR: https://git.openjdk.java.net/jdk/pull/2386
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8259647: Add support for JFR event ObjectCountAfterGC to Shenandoah

Roman Kennke
In reply to this post by Zhengyu Gu-3
On Thu, 4 Feb 2021 19:19:35 GMT, Zhengyu Gu <[hidden email]> wrote:

> > That certainly is bad news for pause times. Do you think it'd be feasible to "piggyback" the object count calculation on concurrent marking? Might address https://bugs.openjdk.java.net/browse/JDK-8258431 also.
>
> It dose not just count number of objects, but number of objects by type, much more than liveness counting. Just add a branch in hot marking loop, I can foresee negative impact on performance.

Yes, as I suggested earlier, I'd only turn it on when requested by JFR, and otherwise leave it off. It definitely will impact performance. That means another set of mark loops that we need to generate at compile-time.

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

PR: https://git.openjdk.java.net/jdk/pull/2386
Reply | Threaded
Open this post in threaded view
|

Withdrawn: 8259647: Add support for JFR event ObjectCountAfterGC to Shenandoah

Zhengyu Gu-3
In reply to this post by Zhengyu Gu-3
On Wed, 3 Feb 2021 20:05:33 GMT, Zhengyu Gu <[hidden email]> wrote:

> Please review this patch that adds JFR ObjectCountAfterGC event support.
>
> AFAICT, the event is off by default. If it is enabled, it distorts Shenandoah pause characteristics, since it performs heap walk during final mark pause.
>
> When event is disabled:
> `[191.033s][info][gc,stats] Pause Init Mark (G)                 454 us`
> `[191.033s][info][gc,stats] Pause Init Mark (N)                  13 us`
>
> When event is enabled:
> `[396.631s][info][gc,stats] Pause Final Mark (G)              43199 us`
> `[396.631s][info][gc,stats] Pause Final Mark (N)              42982 us`
>
> Test:
> - [x] hotspot_gc_shenandoah

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/2386