Repository navigation
Expose annotation to anonymous virtual memory ranges to mmap module #142419
Description
Feature 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.
@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
Activity
corona10 commented on Dec 8, 2025
cc @vstinner
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.
pythongh-142419: Add mmap.set_name method for annotation
Merge remote-tracking branch 'upstream/main' into pythongh-142419
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
The threading module design requires to ignore silently errors which is not great :-( threading.py:
encukou 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
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
Yes. One of the nice things about the thread API is that you can get the name from the Python Thread object.
Merge pull request #65 from vstinner/pythongh-142419
gh-142419: Add mmap.set_name method for user custom annotation (gh-14…
pythongh-142419: Add mmap.set_name method for user custom annotation (p…