RFR (S) JDK-8149023: Event based tracing should cover safepoint begin and end
david.simms at oracle.com
Fri Feb 12 09:41:22 UTC 2016
After further discussion with event folks, I updated the
"ExecuteVMOperation" event to carry the safepointId (relation).
Updated webrev: http://cr.openjdk.java.net/~dsimms/8149023/webrev1/
On 11/02/16 08:09, David Holmes wrote:
> Hi David,
> On 10/02/2016 1:45 AM, David Simms wrote:
>> Greetings all,
>> I have small request for review, for adding event based tracing to
>> "SafepointSynchronize::begin()" and "end()"
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149023
>> Webrev: http://cr.openjdk.java.net/~dsimms/8149023/webrev0/
> Repeating what I said in email for the public record ...
> I'm always concerned about the overhead of tracing when it is not
> being used.
Disabled events have the overhead of an extra stack allocation, followed
by a compare, which the branch predictor will take care of.
"#INCLUDE_TRACING" may be disabled to compile most of it out.
> I'm also concerned that it is not obvious what gets executed when
> these events are created, destroyed or committed. We have to be sure
> there are no actions that might interfere with the safepoint protocol,
> or which might themselves introduce latency into the safepoint process.
That concern would be a separate issue for the event frame-work, they
are designed to be used any where, any time.
> A new comment is that the event.commit blocks seems highly repetitive
> in many cases - dare I suggest using a macro? :)
That would against the Hotspot "Style Guide" and the existing event code.
More information about the hotspot-runtime-dev