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
lesshaste has joined #pypy
leshaste has quit [Read error: Connection reset by peer]
Flawed_Logic has left #pypy [Leaving]
jinsun has quit [Ping timeout: 245 seconds]
<graingert> which branch should I PR into if I have a patch for both pypy2.7 and pypy3.10 - does it go into main and get backported or branch/default?
<graingert> and is there a way to benchmark a PR?
<cfbolz> goes to main
<cfbolz> graingert: then we merge forward to py3.10
<cfbolz> graingert: benchmarking a pr is possible, unfortunately only for branches on the main repo :-(
<cfbolz> but if you tell me, I'm happy to kick off a run
<graingert> it's a bit nasty change
<graingert> but it gets rid of a reference to gateway scope_w values in all functions just for the benefit of gc.get_referrers https://github.com/pypy/pypy/pull/5085/files
<cfbolz> graingert: I see. does it help?
<graingert> it means gc.get_referrers doesn't make a new referrer and return it
<graingert> another option is to reverse scope_w and use `def scopenext(self): return "scope_w.pop()"`
<cfbolz> both feel pretty heavy handed I must say
<cfbolz> graingert: how about the following idea: in the get_referrers implementation we make a copy of the scope_w list and then zero the original one?
<graingert> get_referrers would need it's own gateway?
<cfbolz> no,
<cfbolz> sorry, I meant the args_w list
<cfbolz> I can quickly try it
<graingert> get_referrers doesn't see the scope_w list it gets a copy of the tuple as self.behavior(space, space.fixedview(scope_w[0]))
<graingert> Then scope_w lives in the Activation._run frame and the BuiltinCode.funcrun_obj frames
<cfbolz> args_w
<graingert> That doesn't hold a reference to the tuple
<cfbolz> no, but the tuple holds a reference to it
<cfbolz> graingert: this kind of diff seems to work for me https://usercontent.irccloud-cdn.com/file/yxDAdhrG/image.png
<cfbolz> and I would prefer something along the lines, because it's a lot less invasive
<cfbolz> graingert: did you manage to write a unit test for this problem, by chance?
<graingert> I've been testing it manually in the interactive interpreter
<graingert> so mutating args_w mutates the tuple?
<graingert> Eg args_w is W_TupleObject.wrappeditems so clearing it drops the ref from the tuple nice
<cfbolz> yeah
<cfbolz> it's a bit weird to mutate the tuple
<cfbolz> but it's unreachable at this point
<cfbolz> graingert: do you want to do the pr with this approach?
<graingert> sure!
<cfbolz> thx
<graingert> another weirdness is this: https://www.irccloud.com/pastebin/oqUglnMf/
<graingert> foo() returns a frame and that tuple
<cfbolz> graingert: that's because the A instance is still on the evaluation stack of the frame until the function get_referrers returns
<graingert> That feels like it might keep objects alive longer than it should
<cfbolz> graingert: maybe, but not doing so would make every single function call slower
[Arfrever] has quit [Read error: Connection reset by peer]
[Arfrever] has joined #pypy
[Arfrever] has quit [Read error: Connection reset by peer]
[Arfrever] has joined #pypy
lesshaste has quit [Remote host closed the connection]
lesshaste has joined #pypy
otisolsen70 has joined #pypy
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #pypy
otisolsen70 has quit [Quit: Leaving]
<graingert> cfbolz: why would it be slower?
<graingert> cfbolz: https://github.com/pypy/pypy/commit/f2cb953e89b769af0b0fe68c78903899352c9a15 I tried this but I don't know how to benchmark it
jinsun has joined #pypy
<cfbolz> graingert: dropvalues costs some time, right? it has to zero the stack etc.
<cfbolz> do you have a concrete usecase where the longer lifetimes are noticeable?
<graingert> dropvalues is called the same number of times in my commit
<graingert> cfbolz: I can't think of any examples it's just a distinct difference to how cpython behaves
<cfbolz> sure, but thats really not fixable at all, because the root cause is us using a GC, which will free objects much later anyway
<cfbolz> cpython is moving towards more flexibility in that regard too, with eg deferred refcounting coming up eventually
<graingert> But it's a problem if you move a variable into a function, and say that's the rest of your program and it deletes the object passed in
<graingert> Later is fine, this issue results in stuff never getting collected
<graingert> Consider
<graingert> The file contents stick around for the full rest_of_program()
<cfbolz> in this case v is collectable after the del by pypy
<cfbolz> ah
<cfbolz> ok I see
<graingert> It's not collectable because main incorrectly owns it
<cfbolz> hmmm, are you 100% sure cpython doesnt do the same?
ztrawhcse has quit [Read error: Connection reset by peer]
ztrawhcse has joined #pypy
jinsun has quit [Read error: Connection reset by peer]
<graingert> cfbolz: for pypy you can add a callback that sets a nonlocal flag, then run `while flag: gc.collect()` and it should terminate
Dejan has quit [Quit: Leaving]
lesshaste has quit [Remote host closed the connection]
lesshaste has joined #pypy