A followup for JDK-8258414 (OldObjectSample event usability)

[Jaroslav Bachorík]

Helo,

I would like to pick up the thread from the JIRA to pre-discuss the
possible course of action here.

As I've already mentioned in JIRA the performance hit was
significantly reduced with the stacktrace hashcode fix coming in the
upcoming updates. Unfortunately, it does not solve the gigantic
recording size - at >100MB per recording (1 minute) we must turn off
OldObjectSample event stacktrace collection for our customers :(

The reason is that the stacktrace is collected for all OldObjectSample
event instantiations and it is never removed from the constant pool
even if there are no events referring to it.

Unfortunately, the option of delaying the stacktrace collection only
after a successful try-lock will only reduce the overhead thanks to
limiting the number of collections but, eventually, the constant pool
will grow significantly if we are to keep the limit of the most recent
N old object samples.

Employing throttling, on the other hand, will guarantee that only used
stacktraces will be in the constant pool - at the price of not being
able to get N most recent events as the events would be randomly
distributed across a time period.

At this point I am trying to understand the importance of having 'most
recent' events vs. a sampled event set. If most recent events are
required and inevitable we will have to come up with a way to purge
unused entries from the stacktrace constant pool.

Thanks and looking for feedback!

-JB-