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
Related Reports
Duplicate :  
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.

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.

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.