This is another case where we could potentially see runtime size reductions, but it's a bit more complicated than some other Threading classes due to runtime integration.

Difficulties:

1. Monitor.Enter/TryEnter/Exit are all JIT intrinsics with a fast path and fast slowpath via icall and a slow slowpath via another icall
2. We don't materialize a lock for every object instance - only the ones where someone tries to create a monitor for them. So there's System.Object layout stuff
3. There will probably be a perf hit if we don't inline the managed methods. Possibly a memory hit on Android.

Also if it will end up using ConditionalWeakTable under the hood, we will need to make sure that's not using monitors for synchronization. And probably we'll need to see if our Ephemerons need perf work.

It would probably be best to start with the interpreter and AOT and put the managed impl behind a feature flag.