Annotate mmap ranges using PR_SET_VMA

[wks]

We demand that every invocation of mmap within mmtk-core to be accompanied with an "annotation" for the purpose of the mmap. On Linux, we will use PR_SET_VMA_ANON_NAME to set the attribute after mmap so that it can be seen in /proc/pid/maps. This will greatly improve the debugging experience.

This is a DRAFT:

• mmap entry fragmentation in Map32: PR_SET_VMA prevents adjacent mmap entries to be merged if they have different attributes. It is OK for Map64 where each space occupies a large contiguous memory range. However, for Map32, spaces may interleave at chunk granularity in the shared discontiguous memory range. The maximum number of mmap entries per process can be looked up with sysctl vm.max_map_count which is 65530 by default, 65530 on Ubuntu 22.04, 655360 on Ubuntu 24.04 and 1048560 on ArchLinux. If Map32 is used on a 32-bit address space and the Chunk size is 4MB, there will be a maximum of 1024 chunks. But Map32 is not specific to 32-bit architectures (and in fact Map32 is a misnomer). Anyway, this annotation feature should be disabled by default.
• It should be guarded by a run-time option (e.g. MMTK_MMAP_ANNO=true), and should be default to false. The MmapAnno struct is cheap to construct, and the full annotation will only be formatted when mmap succeeds. So we can leave the code paths that construct and pass MmapAnno around enabled in production setting.
• Enable it only on Linux: This is a Linux-specific feature anyway. And we should ignore the error if prctl fails with EINVAL because this feature is only available since Linux 5.17.

[k-sareen]

Why not just use the space/metadata spec name instead? Also there's a 80-byte limit for the string (including the NUL byte).

However, for Map32, spaces may interleave at chunk granularity in the shared discontiguous memory range.

Why is this a problem? If a chunk is recycled, then we should just rename it.

[wks]

Why not just use the space/metadata spec name instead?

• For space, I just use its name.
• For side metadata, I use both space name and metadata spec name to distinguish between metadata for different spaces.
• And there are mmap invocations for other purposes, too, such as SFTMap.

Also there's a 80-byte limit for the string (including the NUL byte).

Good point. Although I don't think any space name + metadata name would exceed this limit, it's safe to perform the check when formatting.

Why is this a problem? If a chunk is recycled, then we should just rename it.

The number of mmap entries is limited at the OS level. So whenever possible, we should merge adjacent entries. If no chunk in the discontiguous space has name (annotated with PR_SET_VMA_ANON_NAME), the OS may merge adjacent entries; but if adjacent entries have different names, they can't be merged.

[k-sareen]

And there are mmap invocations for other purposes, too, such as SFTMap.

Yes that is a good point. Though in my branch I just use an Option<&str> because it's not always clear what name to give to an mmap region such as the side metadata implementation for 32-bits and for panic_if_unmapped.

The number of mmap entries is limited at the OS level. So whenever possible, we should merge adjacent entries. If no chunk in the discontiguous space has name (annotated with PR_SET_VMA_ANON_NAME), the OS may merge adjacent entries; but if adjacent entries have different names, they can't be merged.

I'm not sure this is a real concern? I don't imagine we'll ever be hitting the limit even for 32-bit machines. Even Android always has the annotations enabled. I strongly suggest having these on by default. If we ever hit the limit then we can disable it.