RFR: 8342818: Implement CPU Time Profiling for JFR [v15]

[Erik Gahlin]

On Wed, 6 Nov 2024 14:02:06 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> If you disable the stackTrace, you will still get the thread. Perhaps not that useful, but that could be said about many events that have a stack trace. I think we should keep it consistent.
>
> But doesn't the user expect that they get a stack trace when they write a settings file with:
> 
> 
> <event name="jdk.CPUTimeSample">
>     <setting name="enabled">true</setting>
>     <setting name="throttle">150/s</setting>
>   </event>
> 
> 
> Because when they write
> 
> 
> <event name="jdk.ExecutionSample">
>     <setting name="enabled">true</setting>
>     <setting name="period">10ms</setting>
>   </event>
> 
> 
> They also get one. So I think we should not force the user to set the stacktrace.

Stack trace is enabled by default, so a user should not need to do additional work with a stackTrace setting.

I could be wrong, but I think the reason the ExecutionSample event looks like that is due to legacy. Then we just copied that when we created the NativeMethodSample event. Maybe we should change ExecutionSample and NativeMethodSample so they work like other events (but not in this PR)?

I can look into it in the next few days and see if there is a reason they don't have a stackTrace setting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1832683303