NMT and adjacent reserved regions

[Thomas Stüfe]

Hi Zhengyu,



On Thu, May 14, 2020 at 2:51 PM Zhengyu Gu <zgu at redhat.com> wrote:

> Hi Thomas,
>
> IIRC, we do intend to collapse neighboring reserved regions, iff
>
> 1) same memory type
> 2) same allocation site
>
>
Hm okay. Something to keep in mind when splitting memory regions. My
original plan was to split the underlying NMT region into two, with both
keeping the original stack + flags. I guess I have to avoid doing that.

Thinking about this I am not sure collapsing is worth the trouble though.
Lets say I were to reserve two regions with mtInternal, but the reservation
calls are hidden in deep call stacks, the call stacks would be identical
and look like the same allocation site to NMT, right? So it could happen
that two reservations are collapsed and the caller is not aware of that.
So, I later could not re-assign different flags to those regions.

Thanks, Thomas


> Thanks,
>
> -Zhengyu
>
> On 5/14/20 7:30 AM, Thomas Stüfe wrote:
> > Hi,
> >
> > I am currently working at a fix for JDK-8243535
> > <https://bugs.openjdk.java.net/browse/JDK-8243535> (NMT does not handle
> > os::split_reserved_space()).
> >
> > I was looking at how NMT treats adjacent reserved regions. Do we collapse
> > them in NMT? The code here
> >
> >
> http://hg.openjdk.java.net/jdk/jdk/file/a44396903fd8/src/hotspot/share/services/virtualMemoryTracker.cpp#l351
> >
> > seems to suggest we do.
> >
> > However I believe we never enter this case since the region was obtained
> > using _reserved_regions->find(rgn); which only returns overlapping
> regions,
> > excluding neighbors.
> >
> > So IIUC currently we do not collapse adjacent regions. I think this is
> also
> > the correct behavior. Is above posted code snippet an overlook then?
> >
> > Or do we want to collapse regions? I think this makes not much sense
> > though, since neighboring reservations may and do come from different
> > callers with different memory flags.
> >
> > Thanks for clarifying,
> >
> > Thomas
> >
>
>