Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8258414: OldObjectSample events too expensive #2645

Closed
wants to merge 5 commits into from

Conversation

flodav
Copy link

@flodav flodav commented Feb 19, 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 of 20.73Mb without the PR fix
  • a recording size of 2.78Mb with the PR fix

Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2645/head:pull/2645
$ git checkout pull/2645

@flodav
Copy link
Author

flodav commented Feb 19, 2021

/label add hotspot-jfr, hotspot

@bridgekeeper
Copy link

bridgekeeper bot commented Feb 19, 2021

👋 Welcome back fdavid! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added rfr Pull request is ready for review hotspot-jfr hotspot-jfr-dev@openjdk.org hotspot hotspot-dev@openjdk.org labels Feb 19, 2021
@openjdk
Copy link

openjdk bot commented Feb 19, 2021

@flodav
The hotspot-jfr label was successfully added.

The hotspot label was successfully added.

@mlbridge
Copy link

mlbridge bot commented Feb 19, 2021

Webrevs

Copy link

@jbachorik jbachorik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -281,6 +281,9 @@ bool JfrRecorder::create_components() {
if (!create_stacktrace_repository()) {
return false;
}
if (!create_leak_profiler_stacktrace_repository()) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +26 to +27
#include "jfr/leakprofiler/sampling/objectSample.hpp"
#include "jfr/leakprofiler/sampling/objectSampler.hpp"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are those 2 extra includes needed?

@@ -197,6 +197,57 @@ static bool stack_trace_precondition(const ObjectSample* sample) {
return sample->has_stack_trace_id() && !sample->is_dead();
}

class StackTraceChunkWriter {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@flodav flodav closed this Mar 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot hotspot-dev@openjdk.org hotspot-jfr hotspot-jfr-dev@openjdk.org rfr Pull request is ready for review
Development

Successfully merging this pull request may close these issues.

2 participants