JFR sampling question
Thomas Stüfe
thomas.stuefe at gmail.com
Wed Nov 4 16:26:43 UTC 2020
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?
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?
3) I did not find any specification for the jfc files, is there one? From
experimenting and looking at the jfc file, looks like MetaspaceSummary is
only sent when a GC happened, is that correct? 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)?
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
>>
>> 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
>>
>>
More information about the hotspot-jfr-dev
mailing list