-
-
Notifications
You must be signed in to change notification settings - Fork 557
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a callback with a weak reference to WeakValueDictionary #15432
Comments
Branch: u/nbruin/ticket/15432 |
New commits:
|
Commit: |
comment:4
Replying to @simon-king-jena:
The branch here descends directly from master, which recently had 5.13beta3 merged. Therefore, as posted, this ticket has no dependencies. Since it only touches one file, that isn't even present in the branch for #15367 (its branch split off before 5.13beta3 merger), I expect no merge problems with that ticket. I actually have a bit of trouble coming up with an example that shows a difference in behaviour for WeakValueDictionary (before this ticket it's not weakly refererrable, making examples particularly tricky). With the following code:
I'm getting with a self-referencing class:
The test doesn't work for dict itself (they have their own freelist etc. so
For this patched
Whereas python's own is clean:
As is (at least our old)
So my guess is that we've overlooked another self reference in Note that our previous |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:6
And of course there is another circular reference from the Note that if you have objects chained by keys in a So, I think this patch could have real effect of memory footprint in sage code. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:8
Incidentally, I think we can do away with the
So instead of using a
where New commits:
|
Author: Nils Bruin |
comment:11
The code looks good, and using a cdef method instead of a Python context is very likely to be faster (I am not going to benchmark, though). I am running the tests now and will give a positive review if stuff passes. |
comment:12
Did I do something wrong? With the branch, I still get
|
comment:13
Question: What exactly is the purpose of this ticket? Is the |
comment:14
Replying to @simon-king-jena:
Correct. |
comment:15
Replying to @nbruin:
Really? But it doesn't, see comment:12. |
comment:16
Strange. For whatever reason, my local version of your branch has been commit 9bb9241, not 4ac686. So, I am trying |
comment:17
|
comment:18
Anyway, the |
comment:19
Pull pulls (=fetches & merges) into the current branch, whatever that currently is. |
comment:20
|
comment:21
Hooray! After pulling the correct commit, I get
and the answer came a lot faster than before. All tests pass, and the patch (i.e., the diff between the develop branch and this branch after merging with the develop branch) looks reasonable to me. Hence, I can almost give it a positive review. How can I do a review patch? Is it possible to make some changes and then do |
Reviewer: Simon King |
comment:22
PS: Shall I revert the merge with the develop branch before creating the review "patch"? |
comment:23
Yes to both.
|
comment:24
How can I do the job without the dev script? I.e., how to do it manually with git? |
comment:25
See also the developer guide (in Sage, not the old one that is still on www.sagemath.org) |
comment:26
Replying to @vbraun:
Thank you! I already found the guide (but I did |
Changed branch from u/nbruin/ticket/15432 to u/SimonKing/ticket/15432 |
Following http://bugs.python.org/issue417795, we should probably only reference the dict weakly from the callback object to avoid unnecessary circular references.
As we found in #15367 comment:39, if an object C involved in a reference cycle becomes unreachable as a side effect of circular GC (e.g., a callback somewhere), the object C will only be collected by GC in the next round. A non-circularly referenced object C would have its reference count hit 0 and would be collected immediately. That is already a good reason to try and avoid circular references, even now that Python does clean them up eventually.
See also #13394 comment:19 (reasoning the validity of using a strongly referencing closure should be fine in theory -- this didn't take into account the practical consideration above).
CC: @simon-king-jena
Component: memleak
Author: Nils Bruin
Branch/Commit: u/SimonKing/ticket/15432 @
13112a9
Reviewer: Simon King
Issue created by migration from https://trac.sagemath.org/ticket/15432
The text was updated successfully, but these errors were encountered: