cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
_whitelogger has joined #pypy
i9zO5AP has joined #pypy
Ai9zO5AP has quit [Ping timeout: 240 seconds]
speeder39_ has quit [Quit: Connection closed for inactivity]
jcea has quit [Ping timeout: 240 seconds]
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
marself has joined #pypy
<mattip>
some progress with the pypy3.7 extra_tests crash on win32 in test_recursion.py
<mattip>
it succeeds when run alone, but fails when run after test_binop_overriding.py
oberstet has quit [Remote host closed the connection]
<mattip>
it is an import in the top line
<mattip>
from pypy.conftest import option
<mattip>
if I add that to test_recursion.py, it crashes
marvin_ has quit [Remote host closed the connection]
marvin has joined #pypy
rfgpfeiffer has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
<arigato>
mattip: I think step one would be to make the win32 stack size 3MB instead of 1MB, to give it roughly the same recursion ability as CPython
<arigato>
unless you are debugging with visual studio and you know that these crashes are not stack exhaustion
<mattip>
I made the stack 2MB via "editbin /STACK ..." but will try 3
<mattip>
I could also try to lower the fraction from 15/16 to something ridiculous like 1/2 and see if that makes a difference
<arigato>
if you try with a fraction of 1/2, make sure you set "/STACK 6" then
<arigato>
...
<arigato>
right, no, I'm not making sense
<arigato>
sorry, please ignore
<mattip>
:)
<arigato>
feel free to add "editbin /STACK" or another similar option to the default translation of pypy(3).exe, too
<arigato>
also feel free to make it a bit higher than 3, which still feels like it is low
<mattip>
vefified that editbin /stack:3145728 makes the extra_tests pass, good idea
fangerer___ has quit [Read error: Network is unreachable]
fangerer___ has joined #pypy
EWDurbin has quit [Read error: Connection reset by peer]
DRMacIver has quit [Read error: Connection reset by peer]
Olorin has quit [Read error: Connection reset by peer]
DRMacIver has joined #pypy
Olorin has joined #pypy
EWDurbin has joined #pypy
DRMacIver has quit [Ping timeout: 244 seconds]
DRMacIver has joined #pypy
<arigato>
mattip: yes, I think we should always do it on windows
<mattip>
ok
Olorin has quit [Read error: Connection reset by peer]
Olorin has joined #pypy
fling has quit [Remote host closed the connection]
<arigato>
re #3289 "increase in memory usage with reloading of module when JIT is enabled"
<arigato>
I think it's just "leaks" in the JIT, in the sense that random bits of data are kept around by machine code that won't be freed because of various reasons
<arigato>
for example, a guard_class(<type 'X'>) will by itself keep alive the user class 'X', even long after the last instance is gone and the guard can never pass any longer
<arigato>
I wonder if we could, as a workaround, have a function pypyjit.releaseall() or so, that would try to free all JIT stuff
<mattip>
so a gc for JITted stuff?
<arigato>
no, we're supposed to have a GC already, it's just not always good enough
<arigato>
it can be improved but that gets exponentially harder for little gains
<mattip>
how do you know if class 'X' is gone for good? The code could cycle back to needing it at some point, no?
<arigato>
pypyjit.releaseall() would be the workaround I'm thinking about now: "don't try to do GC, free it all now"
<arigato>
the example was just an example
<arigato>
but no, if the last reference to a class object is from a guard_class(), then in theory the class object can be freed---in practice it won't because the guard_class() keeps it alive
jcea has joined #pypy
<arigato>
what I'm saying is also that it's not just about freeing the class object, too: the machine code that contains the guard_class() is probably not relevant either and should itself also be freed, which might not occur depending on various conditions
fling has joined #pypy
<LarstiQ>
so `pypyjit.releaseall()` would be a heavy hammer to get back to roughly the state of initial interpreter startup?
<arigato>
yes
tsaka__ has joined #pypy
todda7 has joined #pypy
tsaka__ has quit [Ping timeout: 244 seconds]
speeder39_ has joined #pypy
i9zO5AP has quit [Ping timeout: 240 seconds]
i9zO5AP has joined #pypy
todda7 has quit [Remote host closed the connection]
todda7 has joined #pypy
jacob22 has quit [Quit: Konversation terminated!]
jacob22 has joined #pypy
i9zO5AP has quit [Remote host closed the connection]