RFR: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default)

Mukilesh Sethu github.com+26284057+mybloodtop at openjdk.java.net
Wed Dec 9 22:23:37 UTC 2020


On Mon, 7 Dec 2020 22:37:20 GMT, Mukilesh Sethu <github.com+26284057+myBloodTop at openjdk.org> wrote:

>> Greetings,
>> 
>> please help review this enhancement to let JFR sample object allocations by default.
>> 
>> A description is provided in the JIRA issue.
>> 
>> Thanks
>> Markus
>
> This is great! It would be awesome to have this capability.
> 
> One query on the way you are throttling the events (please correct me if I'm wrong here as I am new to this codebase),
> 
> If I understood correctly, you are throttling the events at the time of committing, specifically part of `should_write` or `should_commit` in `jfrEvent.hpp`. If so, how would we be able to add throttling to events which might require it early on like `ObjectCountAfterGC` or `ObjectCount` events ? 
> 
> I think it makes perfect sense to have it part of commit for allocation events because most of the time consuming tasks like stack walking or storing stack trace in global table is done part of event commit and we will be able to throttle it. However, for events like `ObjectCountAfterGC` the time consuming task is iterating the heap which is unavoidable if we add throttling part of commit. So, I am just curious how can we extend this solution to such events ?

> Hi, @myBloodTop, thanks for your comment.
> 
> For more special events (for example periodic events), it will be possible, although not yet supported, to use the throttling mechanism directly. For example:
> 
> TRACE_REQUEST_FUNC(ObjectCount) {
> if (JfrEventThrottler::accept(JfrObjectCountEvent)) {
> VM_GC_SendObjectCountEvent op;
> VMThread::execute(&op);
> }
> }
> 
> Evaluating the throttle predicate as part of commit or should_commit() is an optimization to avoid having to take the clock twice, but for cases such as the above, if you don't pass a timestamp, a timestamp will be taken for you as part of the evaluation.
> 
> Now, ObjectCount and ObjectCountAfterGC are also special in another respect, in that they are UNTIMED, meaning the events are timestamped outside of JFR. For other, non-UNTIMED events, it would be sufficient to only use the should_commit() tester, since the throttler evaluation is incorporated (post enable and threshold checks evaluations). For example:
> 
> MyEvent event;
> ...
> if (event.should_commit()) { <<-- throttle evaluation
> event.set_field(...);
> event.commit();
> }
> 
> Thanks
> Markus

Thank you for the clarification :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/1624



More information about the hotspot-gc-dev mailing list