Add ITTAPI hooks to jl_mutex_wait

[pchintalapudi]

This allows identifying our jl_mutex_ts as mutexes by VTune

[vchuravy]

@topolarity you might want to take a look at this for tracy integration

[vchuravy]

@pchintalapudi can you split this into two PRs?
This one for jl_mutex_wait, and a second one instead of hooking the probe points we should use ittapi as a timings backend like tracy #49140

[vchuravy]

@pchintalapudi Can you also share some of the screenshots we looked at earlier?

[pchintalapudi]

Examples:

[pchintalapudi]

The profiling events have been split into #49448.

[topolarity]

Thanks for this work! The bulk of the changes look great to me, although I did request a bit of re-factoring to better align with jl_timing_*

Nice to see some example data already too 🙂 Out of curiosity/ignorance, are any of these mutexes considerably "hot" or are they rare enough that we essentially don't need to worry about overhead?

P.S. Can you think of any significant locks that this change leaves out? I believe I/O has non-jl_mutex_t locks, or am I mistaken?

[topolarity]

Would it be possible to move these definitions into timing.c/.h?

Ideally this would follow the conventions established there to provide backend-specific implementations (in particular, it should be possible to turn on multiple back-end implementations at once)

[topolarity]

I'm also OK if these stay local to threading.c, but I would like to try to support multiple back-ends being enabled at once

[pchintalapudi]

I believe @vchuravy preferred them as macros here specifically to avoid them showing up in the profile.

[topolarity]

Would a static inline function fix that problem?

[vchuravy]

Yeah... Let's go with the static_inline

[pchintalapudi]

I/O and task switching have uv_mutex_t locks, but VTune at least picks those up automatically by tapping pthread_mutex_wait.

[pchintalapudi]

WRT hot locks, this workload was an intentionally bad one for the codegen lock, and I've seen the method's write lock get heavily contended when type inference runs in parallel trying to infer the same method with different arguments.

[topolarity]

I think I'm less worried about contention (which I'd want the profiler to show) and more worried about hot locks that are uncontended, where the profiler overhead might be significant relative to the lock / critical section

[pchintalapudi]

I can't think of a case where we acquire and release a lock in a hot loop, but if there was such a case I think it would be better to fix the acquire and release in the user code? We could also just insert a single trial of the cmpxchg that doesn't run the profiler to skip out on the uncontended case as well.

[topolarity]

We could also just insert a single trial of the cmpxchg that doesn't run the profiler to skip out on the uncontended case as well.

Yeah, that's a nice idea - I think there's a lot of effective tricks we could do to catch exceptional events for very hot locks.

If our existing locks aren't that hot though, let's just record all the events for now. If the overhead becomes suspect later, we can go back and try to use some tricks to reduce it.

[topolarity]

All good on my end 👍