NMT uses ThreadCritical to guard access to its global structures; it should use a hotspot Mutex instead that is scoped to NMT. It would not share that mutex with anyone, unlike ThreadCritical. Also, it would open up the possibility of using try_lock, which would make a lot of sense in NMT reporting to prevent hangs, and assert_lock, which would mean we can check for appropiate locking.

That needs special handling during initialization: Mutexes are initialized at VM init, but NMT lives before that. However, before VM init - and during, really - we are effectively single threaded (effectively since libvm dlopen-induced C++ init and CJVM may run on different threads, and usually do, but they don't run concurrently). That means we don't need synchronization via mutex anyway.

Part of the work would be to come up with the correct mutex lock rank in order to not trigger deadlock errors. Another part would be to add "assert_locked" into sections that should happen under lock protection, and to make sure that all code paths are properly locked.