nascheme · GitHub

@nascheme

@nascheme nascheme commented

May 5, 2025

edited by github-actions Bot

Loading

Copy link Copy Markdown

Member

Closed

@nascheme

@nascheme

@nascheme

nascheme marked this pull request as ready for review

May 5, 2025 20:46

@nascheme

pablogsal

@pablogsal

Copy link Copy Markdown

Member

Exquisite

@nascheme

@Yhg1s

Copy link Copy Markdown

Member

Yikes, reading a file in /proc to determine whether the GC should run? That feels... ugh. Also, we primarily care about allocations of from Python, right? Doesn't mimalloc already have enough information to tell us the total heap size or something?

@pablogsal

Copy link Copy Markdown

Member

Yikes, reading a file in /proc to determine whether the GC should run? That feels... ugh.

Well that's technically the official Linux interface to get this info so as long as you like the approach of making GC runs depend on memory watermark this is the correct way.

Also, we primarily care about allocations of from Python, right? Doesn't mimalloc already have enough information to tell us the total heap size or something?

Yep, See also my comment in #133399 (review)

On the other hand we don't necessarily want to count Python only memory. If an object holds a big buffer allocated by malloc you also want to delete that object anyway. Is a less clear cut that the GC actually will do anything but is also not correct to say that's independent.

@nascheme

Copy link Copy Markdown

Member Author

Yikes, reading a file in /proc to determine whether the GC should run? That feels... ugh. Also, we primarily care about allocations of from Python, right? Doesn't mimalloc already have enough information to tell us the total heap size or something?

It only happens when gc_should_collect() would have previously run a full collection. If it ran on every call, that would be bad. On Linux, it seems the only API to get that info. Using mimalloc info, while presumably fast, doesn't account to memory used by other allocators or from mmap, etc. I think this approach is better.

@Yhg1s

Copy link Copy Markdown

Member

Hrm. Okay, different observation then: aren't we now running the risk of every thread reading the file (and doing all the work of checking the limits) in order to schedule the GC, even if it's already scheduled? I mean, we did that before as well, but that was when "all the work" was just checking a couple of oft-used memory locations. Now it actually consumes system resources (open files), which feels more fraught. Should we skip doing the check if the GC is already scheduled (or even "already being checked")?

@pablogsal

Copy link Copy Markdown

Member

I still think a hybrid approach is best where we can weight the mimalloc side independently in the general resident size.

Pranjal095 pushed a commit to Pranjal095/cpython that referenced this pull request

Jul 12, 2025

Open

Merged

Read the original on github.com ↗