#12313: Fix yet another memory leak caused by caching of coercion data
--------------------------------------------------+-------------------------
Reporter: SimonKing | Owner:
Type: defect | Status:
needs_review
Priority: major | Milestone: sage-5.3
Component: memleak | Resolution:
Keywords: coercion weak dictionary | Work issues: Rebase wrt
the new version of #715. Take into account Nils' comments
Report Upstream: N/A | Reviewers: Simon King,
Jean-Pierre Flori, John Perry
Authors: Simon King, Jean-Pierre Flori | Merged in:
Dependencies: #11521, #11599, #12969, #12215 | Stopgaps:
--------------------------------------------------+-------------------------
Comment (by nbruin):
Replying to [comment:139 jpflori]:
> I think the point of this ticket is exactly to solve the small example
you posted (which is nothing but what the ticket description suggests if
I'm not getting too tired):
> * maps are cached in ZZ in a MonoDict which key is a weakref to k
Yes, but the map stores a refcounted ref to k so the presence of the map
on ZZ prevents k from being collected.
We still get the benefit on this patch that the ''absence'' of a map
(which is the case with `GF(p)` to `ZZ`) gets cached by `None` so in that
case only the weakref to k exists on `ZZ` and `k` can be collected.
> * k dies, and the MonoDict is smart enough to let garbage collection
occurs.
Only if the stored value doesn't strongly reference `k`.
> The other way around (maps from ZZ to k, then k dies) should be trivial
as well.
Not "should be trivial as well" but "is already trivial thanks to cyclic
garbage removal". The map is cached on `k` and not on `ZZ`. The map
references `k`, but if all other references to `k` disappear we just have
a cyclic reference, which python's GC should be able to figure out.
So: YES, this ticket is an improvement over what we had before (and once
all issues are worked out should be merged) but it doesn't offer a
complete solution to leaking due to caching yet:
{{{#!python
for p in prime_range(1,1000):
_=SR.coerce_map_from(GF(p))
}}}
will still leak like a disgruntled intelligence chief.
Conversion is a bit worse because conversion maps exist more often, but is
also slightly better because the system won't ask for them by itself and
won't investigate the transitive closure of the conversion graph.
Therefore, I'm not sure conversion should be given the same caching
treatment as coercion. The proposed patch is propagating such a caching
treatment (but didn't introduce it).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12313#comment:140>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
