RFR: 8281946: VM.native_memory should report size of shareable memory [v3]

[Thomas Stuefe]

On Tue, 6 Dec 2022 16:55:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > > The choice to use readonly over shareable was another suggestion by @iklam. Here is some rationale: "Other mmaped pages can be shareable if they are writable but has not been modified by the JVM process (ie copy-on-write pages)"
> > 
> > 
> > I still don't get it... @iklam ?
> > Writeable and shareable are orthogonal properties. You can have every permutation. And in the JDK we have:
> > 
> > * RO + shared: CDS ro segments, text segments, ...
> > * RW + shared: things like perfmem at least, but possibly other things too.
> > * RO + private: guard pages,  ...
> > * RW + private: normal memory.
> > 
> > Here, we want to tell the user if something is shared: if the memory footprint is shouldered by several processes or by this process alone. The user does not really care about writeability, that's incidental. Therefore I think we should name it sharable.
> 
> I agree that the user might be more interested in shareability than writeability. However, that's not something that we can accurately report.

Okay, I think I get it.

We map CDS with MAP_PRIVATE, either ro or rw. I thought we map with MAP_SHARED, and then just don't write to it.

We don't do anything explicit to share, apart from avoiding having to write to the segments. E.g. by avoiding relocations. We count on mapped private memory we don't write to being shared automatically by the kernel with other processes. But there is no easy way to observe the effect unless we look at /proc/pid/smaps Shared_Clean.

> 
> Regarding the ` Shared class space` part of the output, it covers only the `MetaspaceShared::ro` and `MetaspaceShared::rw` sections. Part of the `rw` sections may be shareable across processes because they are not written into during runtime. However, we cannot tell which pages are shared (unless we go through the `/proc/self/smaps` file, which would be too complicated for this RFE **)
> 
> If we report only the `ro` section as `shareable`, I think that's not accurate.
> 
> I see your point that adding `readonly` to these two lines is problematic, as we don't include the `PROT_READ` only mmap pages that are used for stackguards, for example.

Yes, its inaccurate either way. Because we can share a lot more than CDS RO sections. I think the biggest effect comes from sharing the text segments.

> 
> ```
> Total: reserved=33890498670, committed=2360907886, readonly=8315472
>        mmap:   reserved=33815339008, committed=2285748224, readonly=8315472
> ```
> 
> So for the output to be accurate, I think we should only change this one line, and leave the above two lines unchanged.
> 
> ```
> -        Shared class space (reserved=16777216, committed=13545472, readonly=8315472)
> ```
> 

I like this better too.

> ** Perhaps in a future RFE, we could go through the smaps file and report something like this for all the `mmap` lines:
> 
> ```
>        mmap:   reserved=33815339008, committed=2285748224, shared=12345
> ```

Sure, that would be possible. Note though that since we only report in NMT for mmap segments NMT knows about, the total number can always be misleading (as the others). E.g. we would not see sharing from text segments.

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

PR: https://git.openjdk.org/jdk/pull/11401