RFR: 8319897: Move StackWatermark handling out of LockStack::contains [v3]

[Stefan Karlsson]

> There are StackWatermark handling inside LockStack::contains. This is an indication that either:
> 1) some thread has failed to start it's own StackWatermark processing, or
> 2) that some thread is looking into the oops of another thread without starting the StackWatermark handling. The latter is usually more common.
> 
> I propose that we hoist the StackWatermark processing out of the LockStack into the code that actually performs pokes around in other thread's data. This is usually where we put the StackWatermark processing calls.
> 
> Note: that this doesn't fix a bug, it merely moves the processing code nearer the source of the problematic calls. I've found that jmm_GetThreadInfo looks straight into running thread's lock stacks without while those threads are running. That is a race that we should get rid of and I've created [JDK-8319899](https://bugs.openjdk.org/browse/JDK-8319899) for that issue.

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge remote-tracking branch 'upstream/master' into 8319897_StackWatermark_in_LockStack
 - Stream line the assert
 - 8319897: Move StackWatermark handling out of LockStack::contains
 - 8319896: Remove monitor deflation from final audit
 - Remove the limit for deflation requests
 - Remove reinitialization in test
 - Update comments
 - Tweak the flag comment a bit
 - Add AsyncMonitorDeflationForThreadDumpLimit flag
 - Typos
 - ... and 10 more: https://git.openjdk.org/jdk/compare/369bbecc...a423816b

-------------

Changes: https://git.openjdk.org/jdk/pull/16609/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16609&range=02
  Stats: 17 lines in 2 files changed: 7 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16609/head:pull/16609

PR: https://git.openjdk.org/jdk/pull/16609