[netcore] Add Monitor.LockContentionCount icall

[filipnavara]

Contributes to #14828.

The PR just wires up the Monitor.LockContentionCount API to an icall. The actual implementation is not done yet.

I wanted to reuse the existing thread_contentions performance counter but all performance counters unconditionally disabled on netcore builds. Also, the counter is 32-bit only while the managed API returns 64-bit values.

The CoreCLR implementation uses a neat trick to reduce the cost of counting. It stores a per-thread contention counter (eg. in MonoInternalThread field) and a global overflow counter. Up to 2^32 contentions could be recorded in the per-thread field with simple volatile incrementation. Once an overflow happens a slow path is taken that updates a global overflow counter. The LockContentionCount API enumerates all threads and adds up together all the per-thread values along with the global overflow counter. I tried to reimplement that in Mono but I didn't find any way to enumerate all threads and get MonoInternalThread from them.

[filipnavara]

I guess I need to bump MONO_CORLIB_VERSION, right?

[jaykrell]

Please favor if over #if, such as leaving the pointer null if not enabled.

[filipnavara]

That is preexisting code that is already compiled-out in this way.

[jaykrell]

I was going to say that:

C:\s\mono2\msvc>findstr /i perl ..\*ac
..\configure.ac:# perl -pi.bak -e "s/^MONO_CORLIB_VERSION=\S+/MONO_CORLIB_VERSION=`uuidgen`/" configure.ac
..\configure.ac:                dnl we need to set some flags to build our 32-bit binaries on 10.6 properly

but for netcore I don't think so.

[filipnavara]

In general, MONO_CORLIB_VERSION is also used on netcore builds, but there is no monolite bootstrapping issue that would force me to use it.

[EgorBo]

nit: #ifdef (we have a mix of #if ENABLE_NETCORE and #ifdef ENABLE_NETCORE makes sense to unify it

[filipnavara]

Yeah, I wanted to do that... but then I reverted the whole experiment and lost this small change. :)

I noticed that there's a mix already. Unless I will need to amend the PR due to some other change I'd prefer to do the #if/#ifdef unification in separate PR once there is agreement on the preferred way.

[jaykrell]

Not #if vs. #ifdef, though that is something, but if vs. #if[def]. Less code should be explicitly configuration dependent.

[filipnavara]

@jaykrell I don't disagree, in general. In this specific instance it is really #if vs #ifdef though. The netcore version is significantly different from the regular runtime. It is not just an optional feature where we can easily rely on compiler dead code elimination and regular if.

[vargaz]

@monojenkins build failed

[CoffeeFlux]

Nit: ifdef here as well. Would be nice to get that consistent.

[marek-safar]

@steveisok could we enable corefx tests for this?

[filipnavara]

@marek-safar Unfortunately the test would not work yet. Performance counters are globally disabled in netcore build in configure script. We'd either need to re-enable it or offer an alternate implementation here.