There is a high misprediction rate for the common path in JIT_MonExit_Portable
With the common path action == AwareLock::LeaveHelperAction_None not being arranged as the common path in asm.
I've tried rearranging this in the C++; however it seems quite resistant to ordering change; perhaps PGO is incorrectly enforcing the order here?
Aside: I assume it needs to be a cmpxchg rather than just a volatile write because it may have changed from a lock to a lock+hashcode or perhaps signaling? Would there be any scope to having a lock object type that doesn't allow a hashcode or signaling, so it could just be a volatile write to unlock a non-recursive non-signaled lock? (as JIT_MonExit_Portable is quite expensive in the code I'm looking at as 3rd highest cost method)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4
