RFR: 8258414: OldObjectSample events too expensive

[Jaroslav Bachorik]

On Mon, 1 Mar 2021 13:59:51 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

> Hi Florian,
> 
> thanks for your great attempt to fix this issue, it is indeed a complex area with many interrelations.
> 
> I think your suggestion has two problems that we need to solve:
> 
> 1) If we separate the Leak Profiler stacktraces from the "regular" traces, there is a disconnect at the stacktrace record site, because the stacktrace id is cached to the thread. This means other events (ObjectAllocationSample and other memory allocation events) will attempt to reuse the id. Since this id is no longer valid for reuse, it must be handled.
> 
> 2) The division into two separate stacktrace repositories now also separates the stacktrace id assignment, with a consequence that separate stacktraces can now end up having overlapping and conflicting ids.
> 
> I also appreciated your effort in trying to incorporate the count of the traces written, to be tallied in the "regular" process. I do think we can simplify this a bit by not having them tallied (they are only a very small number, max 256 by default).
> 
> Please take a look and let me know what you think about this suggestion.
> 
> Thanks!
> Markus
> 
> PS If we go with this suggestion, I will put you down as a contributor.

src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp line 223:

> 221: 
> 222: // invariant is that the entry to be resolved actually exists in the table
> 223: const JfrStackTrace* JfrStackTraceRepository::lookup(unsigned int hash, traceid id) {

Could the comment be extended to make it explicit that the lookup will be done only in the leak profiler stacktrace repo? Or, better yet the method renamed to `lookup_in_leak_profiler()` (but it might be too long ...).

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

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