RFR: 8298992: runtime/NMT/SummarySanityCheck.java failed with "Total commi…tted (MMMMMM) did not match the summarized committed (NNNNNN)

[Gerard Ziemski]

On Wed, 23 Aug 2023 05:11:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> My understanding is that we make a snapshot of 2 moving parts: `_all_mallocs` and `_malloc[nmt_type]`
>> 
>> The problem is that after we snapshot `_all_mallocs`, `_malloc[nmt_type]` can change, so that:
>> 
>> `s._all_mallocs.size() != s._malloc[nmt_type1] + s._malloc[nmt_type2] + ...`
>> 
>> so we keep trying in a loop until we catch the system in a quiet enough period where:
>> 
>> `s._all_mallocs.size() == s._malloc[nmt_type1] + s._malloc[nmt_type2] + ...`
>> 
>> so when we come out of the loop then the **assert** is guaranteed never to trigger, because we made copies that are not going to change.
>
>> so we keep trying in a loop until we catch the system in a quiet enough period where:
>> 
>> `s._all_mallocs.size() == s._malloc[nmt_type1] + s._malloc[nmt_type2] + ...`
> 
> Either that or until the loop count is exhausted. That's what I meant - the assert could only fire if 100 tries were not enough to get a consistent picture.

I see now what you meant. On one hand it would be nice to know if the loop was unable to get consistent copy, on the other hand if we do get an assert, the only thing we can do is increase the count.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15306#discussion_r1303153650