[GR-47109] Support JFR event throttling and `jdk.ObjectAllocationSample`

[roberttoyonaga]

TL;DR

Implement JFR event throttling in native images. Throttling allows for sub-sampling of events for more deterministic overhead. This is useful for events that are very frequently emitted.

Goals

Implement throttling for jdk.ObjectAllocationSample. Throttling should be able to be switched on/off and users should be able to specify a "rate".

Non-Goals

Do not yet implement throttling for events other than jdk.ObjectAllocationSample. Hotspot only supports throttling for this event so far, but has the infrastructure in place to support it for other events in the future. Do not yet consider additional throttling parameters other than rate (only rate is present in Hotspot so far too).

Details

Event throttling was introduced to limit overhead of enabling very busy events such as jdk.ObjectAllocationInNewTLAB and jdk.ObjectAllocationOutsideTLAB. Enabling these events is very useful for determining the cause of object allocations, but can be very costly (as they are too frequently emitted). They also result in undesirably large JFR snapshots. Throttling and the jdk.ObjectAllocationSample aim to solve these problems.

Similar to jdk.ObjectAllocationInNewTLAB, jdk.ObjectAllocationSample is emitted along the allocation slow path so already only considers a sub-sample of total allocations. Throttling adds another layer of sub-sampling and also defines a specific rate that should not be exceeded, thus providing a degree of determinism the overhead of enabling the event.

The actual throttling/sub-sampling happens at the time of event emission. When an event is about to be committed, the throttler will decide whether to veto the commit. In SVM it would make sense to do the throttling at the same point we check whether an event is enabled (between the start of emission and committing). This is before expensive operations like getting the stack trace or writing any buffers are done.

In Hotspot, the intention is for each event that allows for throttling to have its own dedicated throttler instance. I think a similar approach would be good in SVM. However, in practice, only a throttler for jdk.ObjectAllocationSample needs to be implemented for now.

Throttling in Hotspot uses an adaptive method that predicts the density of events in the future and adjusts the sampling parameters accordingly in an effort to evenly distribute the samples and achieve as close to the specified limit as possible. It achieves this using a windowing scheme. A similar scheme should be attempted in SVM. But as a first step it may be acceptable to reduce to a simpler implementation, and later upgrade to something more complex.

The throttling/adaptive sampling implementation does not relate to the code in com.oracle.svm.core.sampler package. Instead it simply decides about whether a particular JFR instance event should be emitted at the time of emission.

There is more info about event throttling in Hotspot here.

Express whether you'd like to help contributing this feature

I volunteer to help work on this.

[fniephaus]

This was addressed in #6899, which then got merged via #8316.