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 commentedon Dec 8, 2025
cc @vstinner
SpecLad commentedon 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
mmapobject? E.g.mm = mmap.mmap(...); mm.set_name("foobar"). That way you could also change the name multiple times.vstinner commentedon 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 commentedon Dec 10, 2025
Another option would be doing the same thing as with thread names: add this as a Python
nameproperty (that is allow theget_nameoperation as well as theset_name), and do a "best effort" to synchronize it with the OS.vstinner commentedon Dec 10, 2025
The threading module design requires to ignore silently errors which is not great :-(
threading.py:encukou commentedon 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 commentedon 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 commentedon 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 commentedon Dec 11, 2025
Yes. One of the nice things about the thread API is that you can get the name from the Python
Threadobject.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…