RFR: 8312132: Add tracking of multiple address spaces in NMT [v120]

[Thomas Stuefe]

On Thu, 30 May 2024 13:17:17 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

> This is a form of close-to-but-not-really double-accounting. My question is: Is this acceptable? I'm asking the ZGC people about this now.

My opinion: short term, yes. If we want to get this into 23, we should avoid making any functional changes now. 

Long term, maybe also yes. The problem is, regardless of what we do, ZGC semantics are difficult to press into the normal reserved/commit scheme. 

IIUC (and I may not :), ZGC does 1 memfd_create, *then* 2 fallocate, *then* 3 maps that into the user address space. So, after (2), there is a time window where the process uses more memory than its vsize. That is because, IIUC, the allocation done with fallocate() allocates memory in the kernel on behalf of out process. But its not accounted to our process, right? Not visible in any metric.

A) If we count the fallocate as only committed, not reserved, we can have the situation where the sum of committed memory is larger than reserved, which will confuse every analyst.

B) If we count the fallocate as reserve+commit, we can see too much reserved memory, possibly larger than the vsize of the process. 

I still think (B) is the lesser of two evils. Also, less chance to trip of sanity tests that test reserved vs committed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18289#issuecomment-2144783898