Fwd: RFR(s-m): 8243535: NMT may show wrong numbers for CDS and CCS
Thomas Stüfe
thomas.stuefe at gmail.com
Mon Jun 8 12:14:45 UTC 2020
---------- Forwarded message ---------
From: Zhengyu Gu <zgu at redhat.com>
Date: Mon, Jun 8, 2020 at 2:11 PM
Subject: Re: RFR(s-m): 8243535: NMT may show wrong numbers for CDS and CCS
To: Thomas Stüfe <thomas.stuefe at gmail.com>, Ioi Lam <ioi.lam at oracle.com>
Hi Thomas,
NMT part looks good to me.
Thanks,
-Zhengyu
On 6/8/20 4:43 AM, Thomas Stüfe wrote:
> Hi Zhengyu and Ioi,
>
> would it be possible to get a review for this this week?
>
> I understand if this is not possible, but it would be nice to get this
> into 15.
>
> Thanks, Thomas
>
>
>
> On Tue, May 26, 2020 at 8:38 AM Thomas Stüfe <thomas.stuefe at gmail.com
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
> Hi,
>
> please take a look at this fix:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8243535?filter=-3
> Webrev:
>
http://cr.openjdk.java.net/~stuefe/webrevs/8243535--nmt-does-not-handle-os--split_reserved_space()/webrev.00/webrev/
>
> NMT is not able to correctly follow os::split_reserved_memory
> operations. This causes misreports for cds and class space (see JBS
> for details).
>
> The patch adds support to NMT for following split operations, and
> fixes up the CDS side of things.
>
> Changes in NMT:
>
> - In virtualMemoryTracker.hpp/cpp, we now have a new
> operation "split_reserved_region()". This one takes a reserved
> region in NMT and splits it in two adjacent regions while keeping
> the MEMFLAG tags and the original call stack intact.
>
> - For that to work I needed to officially abandon the notion that we
> collapse adjacent regions in NMT. In practice, we did never do this
> due to a coding error, but now we also do not want this. See
> discussion with Zhengyu about this here:
>
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-May/039525.html
>
> - As a small cleanup I also moved the implementation of
> (Virtual|Committed)MemoryRegion::compare() and
> (Virtual|Committed)MemoryRegion::equals() up to the base class,
> since they were identical, and simplified compare() a bit.
>
> - In memTracker.hpp I just marshall the new call through like it is
> done here
>
> - MemTracker::record_virtual_memory_split_reserved gets now called
> from the Posix version of os::split_reserved_memory() to register
> the split. On Windows, this is not necessary, since a split involves
> releasing and re-reserving.
>
> ---
>
> Changes to/for CDS:
>
> CDS maps archive files into pre-reserved space (on Posix) and
> mapping into reserved space is not handled by NMT on a general
> level, that is why inside NMT there exists special logic to deal
> with CDS archive file mappings. I left those alone.
>
> But I simplified/changed the logic of registration somewhat. In
> FileMapInfo::map_region(), before, we would register the archive
> spaces with NMT explicitly after mapping. This was done with two
> separate calls to NMT: the first one for the case where we map into
> pre-reserved space (which inside NMT actually is a noop since this
> case is ignored, see above) and once for the case that we mapped
> archive files into unreserved space (windows only).
>
> I needed a while to understand the logic. Then I simplified as
> follows: I added a MEMFLAGS parameter to os::map_memory() which gets
> uses when registering the mapping with NMT now. That way, no follow
> up tag correction is needed, the mapping has the right tag right
> away. This takes care of the case when we map into unreserved regions.
>
> In addition to this, in
> MetaspaceShared::reserve_address_space_for_archives(), when
> establishing the space for archive and class space, I now register
> those two spaces with NMT after creating them.
>
> That makes for three different cases:
>
> -> case 1 (posix):
> 1 we create the spaces
> in MetaspaceShared::reserve_address_space_for_archives(). Register
> them with NMT.
> 2 in FileMapInfo::map_region(), we then map the archive files in
> one by one using os::map_memory(). This will attempt to register
> these regions, but inside NMT this case is ignored.
>
> -> case 2 (windows, first attempt)
> 1 we create the spaces
> in MetaspaceShared::reserve_address_space_for_archives(). Register
> them with NMT.
> 2 we then delete the archive space again to make space for
> windows file mapping. This removes in NMT the registered address
> range for the archive space.
> 3 in FileMapInfo::map_region(), we then map the archive files in
> one by one using os::map_memory(). This will register each region
> separately with NMT.
>
> -> case 3 (windows, second attempt)
> 1 we create the spaces
> in MetaspaceShared::reserve_address_space_for_archives(). Register
> them with NMT.
> 2 in FileMapInfo::map_region(), we read the content of the
> archive file sequentially. Nothing happens at NMT.
>
> If all this sounds complicated, it is less complicated than it was
> before :)
>
> Note that since we do not merge adjacent regions, in detail report
> the archive files may now appear as separate entities. I do not
> really care, I even think this may be a feature. But if this is not
> wanted, Zhengyu proposed to merge adjacent regions when displaying
> them:
>
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-May/039534.html
.
> That would be a separate issue though.
>
> Tests ran at SAP CI tonight sucessfully.
>
> Thanks, Thomas
>
>
>
>
>
>
>
>
More information about the hotspot-runtime-dev
mailing list