RFR: 8317453: NMT: Performance benchmarks are needed to measure speed and memory

[Gerard Ziemski]

On Wed, 23 Apr 2025 09:51:09 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> When benchmarking malloc the multi-threaded performance is important. If you take a lock while malloc:ing you probably don't get any significant performance degradation a single-threaded run, but if you malloc from multiple threads you will likely see a significant performance / latency degradation. Has this been considered when thinking about the performance of NMT and this tool?

I thought about this and I think  the appropriate answer is "multithreaded malloc performance" is out of scope of this benchmark. We are not really interested in minute perf characteristics of native calls.

We are interested in impact of NMT code on the hotspot.

Switching from an algorithm that asks for many small malloc memory chunks to replace a few large malloc requests would be caught. We have successfully used it already when we were comparing VMATree implementation of VirtualMemoryAllocation requests from linked list to VMTree for example. A synchronized representation of allocation is just fine for our purpose.

Notice that we could also completely remove the time tracking of os level malloc APIs and only measure the hotspot os:: level API to describe NMT overhead. This is the type of performance measurement we are seeking here and this gives us a platform to start doing it.

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

PR Comment: https://git.openjdk.org/jdk/pull/23786#issuecomment-2828742913