GeezerVison is showing github.com — Expose annotation to anonymous virtual memory ranges to mmap module · Issue #142419 · python/cpython
Expose annotation to anonymous virtual memory ranges to mmap module #142419DescriptionFeature or enhancement
Proposal:
Since the annotation of anonymous virtual memory ranges has landed
(c4ccaf4),
We can now consider exposing this feature to end users as well.
#141770 (comment)
@encukou proposed adding a name parameter to mmap.mmap, and I think this would be a great addition.
It would make debugging much easier by allowing people to identify and track individual mmap allocations.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
#141770 (comment)
Linked PRs
Activitycorona10 commented on Dec 8, 2025 SpecLad commented on Dec 8, 2025 Since the underlying system call annotates an existing memory range, wouldn't it more natural for this to be a method call on the mmap object? E.g. mm = mmap.mmap(...); mm.set_name("foobar"). That way you could also change the name multiple times. vstinner commented on Dec 9, 2025 I like the idea of a method. If prctl() fails, we can raise an exception. It allows ignoring the error in the caller. And it's easier to document that the method is only available on Linux 5.17 or newer. encukou commented on Dec 10, 2025 Another option would be doing the same thing as with thread names: add this as a Python name property (that is allow the get_name operation as well as the set_name), and do a "best effort" to synchronize it with the OS. vstinner commented on Dec 10, 2025
Another option would be doing the same thing as with thread names: add this as a Python name property (that is allow the get_name operation as well as the set_name), and do a "best effort" to synchronize it with the OS.
The threading module design requires to ignore silently errors which is not great :-( threading.py:
try:
_set_name(self._name)
except OSError:
passencukou commented on Dec 10, 2025 Yeah, because in that model you primarily set the Python property. This can store any string losslessly, so it's the preferred way to get the name back; it also works the same on all platforms.
Syncing the OS-level annotation is then "just" for easier debugging. No guarantees there; data loss is expected -- full (incompatible OS) or partial (long strings, non-ASCII strings, embedded NULs, ...). SpecLad commented on Dec 10, 2025 I don't think reading the name back from the OS makes much sense. I don't think Linux requires that the entire mmapped range have the same name - so 3rd-party code could set one name for the first half, and another name for the second half.
It would also require parsing /proc/<pid>/maps, which seems rather pricey for a property read. SpecLad commented on Dec 10, 2025
The threading module design requires to ignore silently errors which is not great :-(
Honestly, given that this is mainly intended for debugging, I don't see what else one would do with an error other than silently ignore it. This feature seems inherently best-effort. encukou commented on Dec 11, 2025
I don't think reading the name back from the OS makes much sense.
Yes. One of the nice things about the thread API is that you can get the name from the Python Thread object.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|