RFR: 8258414: OldObjectSample events too expensive

Florian David fdavid at openjdk.java.net
Fri Feb 19 14:26:52 UTC 2021


The purpose of this change is to reduce the size of JFR recordings when the OldObjectSample event is enabled.

## Problem

JFR recordings size blows up when the `OldObjectSample` is enabled. The memory allocation events are known to be very high traffic and will cause a lot of data, just the sheer number of events produced, and if stacktraces are added to this, the associated metadata can be huge as well. Sampled object are stored in a priority queue and their associated stack traces stored in `JFRStackTraceRepository`. When sample candidates are removed from the priority queue, their stacktraces remain in the repository, which will be later written at chunk rotation even if the sample has been removed.

## Implementation

This PR adds a `JFRStackTraceRepository` dedicated to store stack traces for the `OldObjectSample` event. At chunk rotation, every sample stack trace is looked up in this repository and is serialized. Other stack traces are simply removed.

## Benchmarks
On an AWS c5.metal instance (96 cores, 192 Gib), running SPECjvm2008 with default profile.jfc configuration with OldObjectSample event enabled gives
- a recording size 2.78Mb with the PR fix
- a recording size 20.73Mb with the PR fix

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

Commit messages:
 - Add ObjectSamplerStackTraceRepository
 - Add objecetSampleCheckpoint.cpp StackTraceChunkWriter
 - Instanciate leak profiler StackTraceRepository
 - Add leak profiler StackTraceRepository
 - Un-statify jfrStackTraceRepository

Changes: https://git.openjdk.java.net/jdk/pull/2644/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2644&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258414
  Stats: 189 lines in 16 files changed: 163 ins; 1 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2644.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2644/head:pull/2644

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


More information about the hotspot-jfr-dev mailing list