RFR: 8319650: Improve heap dump performance with class metadata caching [v2]

[Aleksey Shipilev]

On Thu, 9 Nov 2023 07:10:53 GMT, Yi Yang <yyang at openjdk.org> wrote:

> What is the proportion of RSS growth caused by class caching during heapdump? As we create class cache entry(num_of_fields*8+ len_of_sig + u4_instance_size + u4_entries) per instance klass

Good question!

On simple Hello World like scenarios, NMT shows about 80 bytes of additional `mtServiceability` per class. This should include cache entry, table overhead itself, etc. This means means for 1M classes (this is the highest I seen in real world), it is 80M additional memory. But then for parallel heap dumps, each thread would have its own table, so memory costs grow proportionally. For 1K core machine (thinking ahead here), it would take 80G (!) of additional memory.

But then nothing really requires us to cache all the classes all the time, or track the class popularity. We can just clear the entire table every so often, and let it regenerate with the most frequent classes again and again. If we cache only the 256 most recently popular classes, then the final number from the extreme example above gets to the modest 20M of additional memory. In practice, with normal thread counts, I would expect the overhead to be in double-digit KBs.

Implemented in new commit. I checked with `CACHE_TOP = 0` to stress the scenario we always get for the table lookup/purge (not the worst case, since we are purging an empty table), and the performance is not worse than the baseline.

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

PR Comment: https://git.openjdk.org/jdk/pull/16545#issuecomment-1803582324