JDK-8232620 : General sampling heap allocation event
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 14
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2019-10-18
  • Updated: 2021-03-09
  • Resolved: 2021-03-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16
16Resolved
Related Reports
Duplicate :  
Description
After seeing first hand how useful allocation profiling events are in production, but also how extremely expensive they are, we really need to introduce a less costly sampling heap allocation event. One that gives a statistically accurate picture of how much memory is allocated along with the stack traces, but that has a more configurable emission rate. For certain high allocation loads, the recordings can get quite large and they can also introduce quite a bit of overhead.
Comments
https://github.com/openjdk/jdk/pull/738
19-10-2020

Taking this one step further, we'll go with a simple control for the event emission rate. This is similar to the approach we've taken with the exception profiler that we've implemented in Datadog's continuous profiler for Java.
02-10-2020

The new event should operate under the same principles as https://openjdk.java.net/jeps/331. A new setting would be introduced which would be the average allocated bytes between the events. We would need to do some in-house testing to figure out what a reasonable default setting would be for the profiling template. I would suggest disabling the inside/outside of TLAB events in the profiling template after this event has been introduced.
21-04-2020