RFR: 8157023: Integrate NMT with JFR [v2]

[Thomas Stuefe]

On Mon, 5 Dec 2022 11:30:44 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > I have a test with 20k threads. On my machine time under ThreadCritical fluctuates between 30 and 70 ms (I measured debug before accidentally, this is for a release VM). When there is high thread activity (e.g. 20k threads joining), time until we get ThreadCritical can be up to 20 seconds.
> 
> Yes, looked a bit at the code and having a lot of threads getting created and dying looks problematic. But I assume this would be problematic even without anyone reading the NMT data. A lot of threads being created would still compete for the `ThreadCritical` (when NMT is enabled), right?

Sure, but the time windows are tiny compared to thread stack probing. 

My base concern is that you now use NMT queries in a new context that puts more demands on performance and pause time. With a jcmd, nobody cared if it took two seconds.

One example where this could matter: https://github.com/openjdk/jdk/pull/11401 introduces displaying shareable memory, but only for a single use case (CDS). One could conceivably want to expand on that and display all shareable memory. A very trivial and cool way to implement that would be to ask the OS when printing: is this memory region private or shareable? This would spare us any bookkeeping and print what arguably is the "truth". But this probing depends on the number of memory segments, and may take time, and that may not be admissible if running under JFR.

That is why I think a custom API as I proposed before would be good. Because ~90% of NMT data can be queried without any problems. So you could have a very nice 90% solution now, and for the problem cases like thread stacks we think of something down the road. E.g. a low priority low frequency sampler thread that updates thread stack sizes once per 10 seconds or so. Or that is adaptive wrt number of threads.

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

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