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
