RFR (S) JDK-8149023: Event based tracing should cover safepoint begin and end

[David Simms]

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/

Reply in-line...

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.

/Mr. Simms