RFR: 8258431: Provide a JFR event with live set size estimate [v12]

[Thomas Schatzl]

On Tue, 16 Mar 2021 10:47:22 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > For the liveness value to be useful it would have to be updated at each GC, and we need to investigate further to see how we can do that in a "cheap" way. I would prefer if G1 did just return used() in live() as a start and we can create a follow-up task to investigate how to best add a better estimate. Do you see any problem with this?
> 
> Actually yes - this event was meant to be a cheap way to see whether the _known_ live size is growing (has an upwards trend) which would using the `used()` value make more difficult and unreliable.

So one of the actual purposes seems to be some kind of leak detection: there is this JFR leak detector (I only know the feature name, not completely how it works and what its overhead is) for this purpose, wouldn't that work?

Also, for this purpose, why would used() not be a good substitute for liveness? If e.g. used() average grows over time you can deduce the same I would assume (particularly used() after mixed gc phase in g1).

Do you have any numbers on what the impact of using used() vs. this live() would be in such a use case?

What I'm afraid of is that mixing values taken at different times - used and capacity are taken at the time of the event, and the liveness estimated updated at other, irregular intervals may cause significiant amount of confusion in interpreting this value. It might be obvious to you, but there will be other users.

One option could be detaching the liveness estimate from used()/capacity() (I see a value in having some heap usage summary at regular intervals) and send the liveness estimate event just when they are generated? Then the various collectors could send this liveness value at times when they think they are fairly accurate, not when the collectors must and particularly not in conjunction with samples taken at completely different times.

Independent of whether used/capacity and liveness are sent, the receiver needs to do statistics (trend lines) on those anyway.

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

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