cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake https://pypy.org | IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end and https://libera.irclog.whitequark.org/pypy | the pypy angle is to shrug and copy the implementation of CPython as closely as possible, and staying out of design decisions
Hodgestar has quit [Server closed connection]
Hodgestar has joined #pypy
cahoots_ has quit [Quit: leaving]
<arigato> komasa: (1) looking at that line you pointed out: locs_to_defs might grow to be a large dict containing many large sets as values
<arigato> (2) pypy's GC is known to not release memory back to the OS. I seem to remember that "rawmalloced" memory sometimes includes "all memory used by GC objects >= 1KB or so"
<arigato> more precisely: it does not release the virtual memory allocated, but on some platforms at least it uses special system calls that will mark pages as free again, even though they remain virtually allocated
<arigato> so you need to be careful when measuring the memory actually used
<arigato> a simple "top" on Linux will show you potentially very large amounts of virtual memory allocated, but not that much actually in use
<komasa> arigato: thanks that's helpful. There is likely some bug in the actual Python code that makes entries in `locs_to_defs` grow way too large, so we will now be tracking that down. The memory releasing problem comes after that analysis has finished, where it _looks_ like the memory isn't released, but I don't have concrete evidence that this actually causing the OOM issues we are seeing, or maybe just a
<komasa> display quirk like you said
nimaje has quit [Server closed connection]
nimaje has joined #pypy
xcm_ has quit [Remote host closed the connection]
xcm has joined #pypy
derpydoo has joined #pypy