RFR: 8157023: Integrate NMT with JFR
Stefan Johansson
sjohanss at openjdk.org
Fri Dec 2 11:54:07 UTC 2022
On Fri, 2 Dec 2022 10:42:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> I think we do, since summary info contains information about committed thread stack size.
You are totally correct, somehow missed that part of `VirtualMemorySummary::snapshot()`. So yes, we should really look at only doing one snapshot per period. Any feeling for exactly how expensive this walk is?
> To serialize jcmds running in parallel. Since jcmd is done by the attach listener thread, the only way I can think of would be if someone in parallel executes the command via mbean? Not sure.
Ok, so if executed via the mbean it would be executed in another thread but still use `DCMD::execute()` and the lock to make sure those are synchronized. Anyhow, do you agree with my above understanding that what is protected by the lock is the "cached baseline"? So as long as JFR doesn't use it, the lock should not be needed?
> Note that there is no way to get consistent counter values across all categories anyway. All the counters are updated atomically without lock, and that is all we can afford in malloc. Counters are not synchronized among themselves.
Agreed, this is a snapshot at a given point of a moving target.
-------------
PR: https://git.openjdk.org/jdk/pull/11449
More information about the hotspot-dev
mailing list