Shenandoah Events

Ken Dobson kdobson at redhat.com
Thu Jan 24 16:28:20 UTC 2019


On Thu, Jan 24, 2019 at 5:10 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 1/23/19 5:04 PM, Ken Dobson wrote:
> > Do you know of a good way to test the performance overhead of these
> events when they are enabled?
>
> Apart from measuring the actual benchmarks, I don't know.
>
> Would measuring the benchmarks (or a small subset of them) with jfr
enabled and the events emitting be a relatively small task?

> As well, the goal with these events is to create something similar to the
> G1 Heap Layout in JMC
> > (screenshot: https://gyazo.com/224574751d48804814163c280764bde5). It is
> used by selecting a GC event
> > in the table on the right which will play the recorded heap information
> beginning at that GC,
> > displaying the Heap Region state changes in a very similar manner to the
> Shenandoah Visualizer. Do
> > you have any recommendations for changes or additional features you
> think would make it more useful
> > for Shenandoah?
>
> What Shenandoah Visualizer does would be good to have in JFR. Per-region
> history data would be nice
> to have, as long as overhead is low.
>
> As Mario said I've ported the Visualizer over to JMC. It currently
requires a little bit of work such as downloading the repo and adding the
feature to your own JMC repo. Once JMC is able to add plugins correctly the
plan is to package it in an update site and it should be easily available
to those with just a build.

Come to think about, I think intercepting the individual region transitions
> is too fine-grained for
> this to have small theoretical overhead, because region states can change
> a lot. Do we have any idea
> of the JFR sampling overhead both when enabled and disabled? That should
> indeed be our first question.
>
> The G1 version currently intercepts individual transitions so I'd hope
they've measured the overhead and found it was acceptable but can't be
certain of that. Yes I agree that's definitely the first step. Generally
the default JFR profiling configuration is ~2% overhead but detailed events
such as these are not enabled in that configuration. When using these
events I think it would be best to disable all the default events and only
enable the two Shenandoah Events to reduce the overhead. If you think
measuring the benchmarks is the best way to get this data I'd be happy to
do this if you can point me in the right direction.

Thanks,

Ken


More information about the shenandoah-dev mailing list