RFR: 8258414: OldObjectSample events too expensive

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR: 8258414: OldObjectSample events too expensive

Florian David
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:
 - Make JFRRecorder serialize Leak Profiler stack traces
 - Serialize ObjectSampler's stack traces to Chunk
 - Instanciate leak profiler StackTraceRepository
 - Add leak profiler StackTraceRepository
 - Un-statify jfrStackTraceRepository

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

PR: https://git.openjdk.java.net/jdk/pull/2645
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8258414: OldObjectSample events too expensive

Jaroslav Bachorik-3
On Fri, 19 Feb 2021 14:45:00 GMT, Florian David <[hidden email]> wrote:

> 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 of 20.73Mb without the PR fix
> - a recording size of 2.78Mb with the PR fix

Ok, kicking off the review.
The implementation is doing the right thing (AFAICT) and I have no strong objections, just minor things regarding slightly more detailed comments.

src/hotspot/share/jfr/recorder/jfrRecorder.cpp line 284:

> 282:     return false;
> 283:   }
> 284:   if (!create_leak_profiler_stacktrace_repository()) {

Can you add a comment here explaining the purpose of having a separate leak profiler stacktrace repository?

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

> 25: #include "precompiled.hpp"
> 26: #include "jfr/leakprofiler/sampling/objectSample.hpp"
> 27: #include "jfr/leakprofiler/sampling/objectSampler.hpp"

Are those 2 extra includes needed?

src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp line 200:

> 198: }
> 199:
> 200: class StackTraceChunkWriter {

Perhaps, a detailed comment explaining how this is working with the regular stacktrace writer would be good to have here.

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

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