Shenandoah Events

[Ken Dobson]

Hi Aleksey,

Just following up on the possibility of running the benchmarks to measure
the performance overhead. Please let me know if this would be possible and
what I would have to do to get this done.

Thanks,

Ken

On Thu, Jan 24, 2019 at 11:28 AM Ken Dobson <kdobson at redhat.com> wrote:

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