Exquisite

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

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 offrom 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.

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

It only happens whengc_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.

Hrm. Okay, different observation then: aren't we now running the risk ofevery 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")?

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