[GR-51851] Add initial support for native memory tracking.

[graalvmbot]

Based on #7883.

@roberttoyonaga: please review the core parts of the PR (most other changes are just minor changes):

• NativeMemory and everything else in the same package
• NativeMemoryTracking and everything else in the same package

Unfortunately, we can't add native memory tracking to UnmanagedMemory because it is public API. This PR still contains a few temporary changes (e.g., NMT is enabled by default at the moment) that I will remove before merging. Naming is still up for discussion as well.

Regarding the NMT categories: is there any need to stick closely to the categories that HotSpot has?

[roberttoyonaga]

please review the core parts of the PR

Thank you @christianhaeubl . I'll look over this.

Regarding the NMT categories: is there any need to stick closely to the categories that HotSpot has?

I do not think there is any need to conform to exactly the same categories. If we need new ones, it should be fine to add them. If there are categories that do not apply to SVM, we can ignore them. I do think it's worth retaining any Hotspot categories that apply in SVM to make it simpler for a user that may be relying/accustomed to them.

Edit: I think the changed categories in NmtCategory are fine as well. It makes sense for each VM to have it's own unique categories because the low-level implementations will be different.

[roberttoyonaga]

Why have UntrackedNullableNativeMemory wrap UnmanagedMemorySupport if they serve a similar purpose? Is it a concern that a caller could either call UnmanagedMemorySupport or UntrackedNullableNativeMemory directly to accomplish the same thing? They could even use LibC directly, if they are determined.

[christianhaeubl]

UnmanagedMemory and UnmanagedMemorySupport shouldn't be used internally. By not using it internally, it makes it easier to distinguish between code that bypasses NMT on purpose and code that accidentally uses the public API. Note that UnmanagedMemorySupport is platform-specific and only some implementations delegate to LibC.

[roberttoyonaga]

Unfortunately, we can't add native memory tracking to UnmanagedMemory because it is public API.

Now that NMT hooks are added at a level higher than UnmanagedMemory, this means we need to worry about people breaking convention and using UnmanagedMemorySupport to create mismatched allocation/frees with NativeMemory (not just LibC).

Just an idea: What if we kept the NMT code at the level of UnmanagedMemorySupport and kept UnmanagedMemory unaltered. Then if callers useUnmanagedMemory, we can assign a header and aggregate into a "default" category. By doing this, we reduce the the number of untracked mallocs and are less likely to have mismatched allocation/frees.

[roberttoyonaga]

Is it impossible to be using theNmtCategory.Code category concurrently with the test?

[christianhaeubl]

Yes, as there is no JIT compilation happening.

[christianhaeubl]

Just an idea: What if we kept the NMT code at the level of UnmanagedMemorySupport and kept UnmanagedMemory unaltered. Then if callers use UnmanagedMemory, we can assign a header and aggregate into a "default" category. By doing this, we reduce the the number of untracked mallocs and are less likely to have mismatched allocation/frees.

We can't use NMT for our public API classes (UnmanagedMemorySupport and UnmanagedMemory) because we don't know how people use that API. At the moment, it is for example possible to allocate memory via UnmanagedMemory and to free that memory in C code. UnmanagedMemory can also be used to free memory that was allocated in C code. We would break that behavior if we added NMT to those classes.

[roberttoyonaga]

Thank you for working on integrating this @christianhaeubl