P3
Rate-limited sampling of events has been discussed since the inception of JFR, but the challenge has always been how sampling should work.
With JDK 16, rate-limited sampling was introduced in the ObjectAllocationSample event. I haven't heard a single complaint, in contrast to the many issues raised with TLAB events. I think we can deem it a success.
What made the ObjectAllocationSample event easier to design was:
- The event was new, so it didn't break any existing functionality.
- The event was instantaneous (no threshold to consider).
- The event did not have user-defined settings.
It might be worth drawing conclusions from this and to consider the following:
- Avoid changes to existing events in the JDK (e.g., SocketRead). Instead, create a new event, such as SocketReadSample.
- Do not allow rate-limited events to have a threshold.
- Do not allow rate-limited events to have user-defined settings.
If outliers and samples are split into two events, it becomes easier for users to understand, as they can now appear as two different tables in a GUI.
It is not clear how thresholds or user-defined settings should combine with sampling in the same event. Should sampling work independently of the threshold, or should it only apply above the threshold? What about sampling an event with a user-defined setting, like a thread filter. Must both settings be true to commit, or is it sufficient for only one of them? If both are required, shouldn't the same apply to thresholds for consistency? Sampling would then only occur above the threshold. If so, the threshold would need to be set to zero to obtain an unbiased sample, which would be equivalent to ignoring the threshold altogether.
With JDK 16, rate-limited sampling was introduced in the ObjectAllocationSample event. I haven't heard a single complaint, in contrast to the many issues raised with TLAB events. I think we can deem it a success.
What made the ObjectAllocationSample event easier to design was:
- The event was new, so it didn't break any existing functionality.
- The event was instantaneous (no threshold to consider).
- The event did not have user-defined settings.
It might be worth drawing conclusions from this and to consider the following:
- Avoid changes to existing events in the JDK (e.g., SocketRead). Instead, create a new event, such as SocketReadSample.
- Do not allow rate-limited events to have a threshold.
- Do not allow rate-limited events to have user-defined settings.
If outliers and samples are split into two events, it becomes easier for users to understand, as they can now appear as two different tables in a GUI.
It is not clear how thresholds or user-defined settings should combine with sampling in the same event. Should sampling work independently of the threshold, or should it only apply above the threshold? What about sampling an event with a user-defined setting, like a thread filter. Must both settings be true to commit, or is it sufficient for only one of them? If both are required, shouldn't the same apply to thresholds for consistency? Sampling would then only occur above the threshold. If so, the threshold would need to be set to zero to obtain an unbiased sample, which would be equivalent to ignoring the threshold altogether.