Proposal: track zlib native memory usage with NMT

[Alan Bateman]

On 04/11/2022 16:54, Thomas Stüfe wrote:
> Hi all,
>
> I am currently working on https://bugs.openjdk.org/browse/JDK-8296360; 
> I was preparing the final PR [1], but then Alan did ask me to discuss 
> this on core-libs first.
>
> Backstory:
>
> 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.

Thanks for starting a discussion on this as this is a topic that 
requires agreement from several areas. If this is the start of something 
bigger, where you want to have all allocation sites in the libraries 
using NMT, then I think it needs a write-up, maybe a JEP.

For starters, I think it needs some agreement on using NMT for memory 
allocated outside of libjvm. You mentioned Unsafe as an exception but 
that is implemented in the VM so you get tracking for free, albeit I 
think all allocations are in the "mtOther" category.

A general concern is that it creates more coupling between the VM code 
and the libraries code. As you probably know, we've removed most of the 
dependences on JVM_* functions from non-core areas over many years. So I 
think that needs consideration as I assume we don't want 
memory/allocation.hpp declaring a dozen catagories for allocations done 
in say java.desktop module for example. Maybe your proposal will be 
strictly limited to java.base but even then, do we really want the VM 
even knowing about categories that are specific to zip compression or 
decompression?

There are probably longer term trends that should be part of the 
discussion too. One general trend is that "run time" is becoming more 
and more a hybrid of code in libvm and the Java libraries. Lambdas, 
module system, virtual threads implementations are a few examples in the 
last few release. This comes with many "Java on Java" challenges, 
including serviceability where users of the platform will expect tools 
to just work and won't care where the code is. NMT is probably more for 
support teams and not something that most developers will ever use but I 
think is part of the challenge of having serviceability solutions "just 
work".

In addition to having more of the Java runtime written in Java, there 
will likely be less JNI code in the future. It's very possible that the 
JNI code (including the JNI methods in libzip) will be replaced with 
code that uses Panama memory and linker APIs once they are become 
permanent. The effect of that would to have a lot of the memory 
allocations be tracked in the mtOther category again. Maybe integration 
with memory tracking should be looked at in conjunction with these APIs 
and this migration. I could imagine the proposed "Arena" API 
(MemorySession in Java 19) having some integration with NMT and it might 
be interesting to look into that.

So yes, this topic does need broader discussion and it might be a bit 
premature to start with a PR for libzip without talking about the bigger 
picture first.

-Alan