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

[Gerard Ziemski]

On Fri, 25 Apr 2025 07:34:31 GMT, Stefan Karlsson <stefank 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.
> > > 
> > > 
> > > My concern is that if you use this tool to motivate changes to malloc, then the motivation could be incomplete if it doesn't also think about multi-threaded use-cases. Just a heads up for the future.
> > 
> > 
> > Ah, you mean like the realloc/malloc refactoring, noted.
> 
> No. I mean in general. If someone, for example, decide to always have NMT turned on and use a lock in NMT then that will affect os::malloc's multi-threaded characteristics, but it is not clear that that would show any significant performance loss in a single-threaded benchmark.

Correct, that would not be caught by this benchmark, but many other instances (not dependent on multithreaded perf) will be caught.

Again, we already found it useful when switching from linked list to treaps data structure for tracking virtual allocations - the time numbers came in handy there and we were able to track optimizations and get performance not to regress.

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

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