JFR sampling question

[Thomas Stüfe]

Hi Erik,

On Thu, Nov 5, 2020 at 3:27 AM Erik Gahlin <erik.gahlin at oracle.com> wrote:

> Hi Thomas,
>
> On 4 Nov 2020, at 17:26, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
> Hi Eric,
>
> may I ask some more questions?
>
> 1) Via experiments I found that in JMC, the graphs under "JVM
> Internals->Garbage Collections" which describe Metaspace
> development (reserved, committed, used) seem to be calculated from the
> MetaspaceSummary Event. Is that correct?
>
>
> Sorry. I don’t know what the GUI shows.
>
> You may want to check with jmc-dev at openjdk.java.net, or the JMC source
> code:
>
>
> https://github.com/openjdk/jmc/tree/master/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages
>
>
> 2) These graphs seem to be interpolated, right? Since regardless of how
> many events I actually have, they look smooth. Is there a way to show the
> actual samples instead of the graphs, or maybe the sample points interposed
> on the line?
>
>
> You need to check with JMC team.
>
>
> 3) I did not find any specification for the jfc files, is there one?
>
>
> See:
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/jfc.xsd
>
> From experimenting and looking at the jfc file, looks like
> MetaspaceSummary is only sent when a GC happened, is that correct?
>
>
> I have not implemented the event, but it does a have gcId field which
> means it is tied to a GC.
>
>
> The problem with that is that a lot of information goes missing since
> metaspace state can change a lot outside of GCs. What would be the correct
> way to change these events to periodic delivery (if that is even possible)?
>
>
> Events can be made periodic in which case they are fired at an interval.
> You would set the “period” attribute, see src/hotspot/share/jfr/metadata,
> and then emit your event in src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
>
> Perhaps there should be two events, one that happens every GC and one that
> is emitted periodically? The periodic one can’t have a gcId.
>
> There is some precedence for creating ordinary events and statistical
> events where the latter aggregate data over time.  Not sure if it applies
> in your case? There is also events like ObjectCount and ObjectCountAfterGC
> that looks identical but one is emitted periodically and the other after a
> GC.
>
> Do you have any numbers of the cost of aggregating data for the event?
>
> You can regulate the overhead by setting the period. “endChunk” which
> means it is included at least once in every recording, or you can set the
> interval “1 s”, “10 s”, “30 s” or “60 s” depending on what is needed for
> troubleshooting and the overhead (space, CPU) the event creates.
>
> I hope this helps.
>
> If you want more guidance, it may be easiest to just set upp 30 min zoom
> meeting.
>

Thanks for the offer! Let me gather some more experience, so that I don't
waste your time.

Cheers, Thomas


>
> Cheers.
> Erik
>
>
> Thanks a lot!
> ..Thomas
>
>
> On Wed, Nov 4, 2020 at 1:27 PM Thomas Stüfe <thomas.stuefe at gmail.com>
> wrote:
>
>> Thank you Erik, that is exactly what I needed.
>>
>> On Wed, Nov 4, 2020 at 1:13 PM Erik Gahlin <erik.gahlin at oracle.com>
>> wrote:
>>
>>> Hi Thomas,
>>>
>>> I don’t know what the event is called, but you can look at the
>>> configuration files and the period setting for the event.
>>>
>>> https://github.com/openjdk/jdk/tree/master/src/jdk.jfr/share/conf/jfr
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/src/jdk.jfr/share/conf/jfr__;!!GqivPVa7Brio!I66M-vBapUnyoKtZf-uHXqM4jTZkZL9TN8pWFKesEyzfV0MUyl3z6lDdJtvc84Z6$>
>>>
>>> Erik
>>>
>>> > On 4 Nov 2020, at 13:07, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>>> >
>>> > Hi,
>>> >
>>> > I am currently reworking the Metaspace information shown in JMC, which
>>> is
>>> > outdated after JEP387.
>>> >
>>> > How often is this information sampled? How expensive can the sampling
>>> code
>>> > get?
>>> >
>>> > For example, post-JEP387, the metachunk freelists contain committed as
>>> well
>>> > as uncommitted areas. While it may be interesting to know how much
>>> area is
>>> > committed, that would require walking the freelists, which could get
>>> > expensive.
>>> >
>>> > Thanks, Thomas
>>>
>>>
>