RFR: 8258414: OldObjectSample events too expensive

Markus Grönlund mgronlun at openjdk.java.net
Mon Mar 1 14:04:54 UTC 2021


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 what you think about this suggestion.

Thanks!
Markus

PS If we go with this suggestion, I will put you down as a contributor.

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

Commit messages:
 - 8258414

Changes: https://git.openjdk.java.net/jdk/pull/2780/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2780&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258414
  Stats: 122 lines in 7 files changed: 59 ins; 18 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2780.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2780/head:pull/2780

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


More information about the hotspot-jfr-dev mailing list