<div dir="ltr">Hi all,<br><br>I am currently working on <a href="https://bugs.openjdk.org/browse/JDK-8296360" target="_blank">https://bugs.openjdk.org/browse/JDK-8296360</a>; I was preparing the final PR [1], but then Alan did ask me to discuss this on core-libs first.<br><br>Backstory:<br><br>NMT tracks hotspot native allocations but does not cover the JDK libraries (small exception: Unsafe.AllocateMemory). However, the native memory footprint of JDK libraries can be significant. We have no in-VM tracker for these and need tools like valgrind or our SapMachine MallocTracer [2] to observe them.<br><br>At SAP, in our proprietary VM, we have instrumented the whole JDK. Not via NMT, but with an older tracker we developed 15 years ago. It has run stable and productively on many platforms for ~15 years now, atop quite different libc implementations. It is impractical to contribute it upstream, however. Would not make much sense either since it overlaps a lot with NMT.<br><br>2018 I discussed the possibility of extending NMT across the JDK wholesale, and the associated risks and difficulties [3]. The reception was not great, so I backed off and did other things.<br><br>But the issue of JDK native footprint comes up regularly. It is a thorn in our foot. Recently we had a customer whose zlib footprint exploded into the tens of GB range. Luckily the customer used our proprietary VM, so we pinpointed the cause quickly. With the OpenJDK we would have flown blind. I want to change that.<br><br><br>Proposal:<br><br>In contrast to my first proposal from 2018 I'd like to instrument the core libs only in small steps, and only for selected allocation hotspots. There are not that many. And I start with the zlib.<br><br>My proposal does not touch the zlib itself. The solution works with both bundled zlib and system zlib. All the instrumentation happens in the JVM zlib wrapper. It mainly uses the zalloc mechanism of zlib streams to reroute the allocations.<br><br><br>Costs and risks:<br><br>There is a risk involved with instrumentations like these. If we overlook instrumentation points we end up with unbalanced malloc/frees (instrumented malloc+raw free, or vice versa) which would corrupt the C-heap since NMT uses malloc headers. But in this case, the risk is very small since the instrumentations are few.<br><br>(Side note: our internal tracker sidesteps this problem entirely by avoiding malloc headers. Instead, it uses a hash tables to match pointers with their meta information. But that has other cons and I do not plan to change the way NMT works.)<br><br>Performance-wise, instead of calling into the libc directly, we would call into the hotspot, then into the libc. That indirection will cost some cycles. If NMT is off, there does not happen much more beside the real malloc call. Even NMT summary mode is very cheap. So I don't expect this to be a problem but will run performance tests.<br><br>--------<br><br>My patch [1] works and can be built and tested. But the PR is still a work in progress. I just wanted to make sure nobody generally objects to my work.<br><br>Cheers, Thomas<br><br>[1] <a href="https://github.com/openjdk/jdk/pull/10988" target="_blank">https://github.com/openjdk/jdk/pull/10988</a><br>[2] <a href="https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer" target="_blank">https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer</a><br>[3] <a href="https://mail.openjdk.org/pipermail/hotspot-dev/2018-November/035358.html" target="_blank">https://mail.openjdk.org/pipermail/hotspot-dev/2018-November/035358.html</a><br></div>