#12313: Fix yet another memory leak caused by caching of coercion data
--------------------------------------------------------+-------------------
Reporter: SimonKing | Owner:
Type: defect | Status:
needs_work
Priority: major | Milestone:
sage-5.7
Component: memleak | Resolution:
Keywords: coercion weak dictionary | Work issues: Speed
regression
Report Upstream: N/A | Reviewers: Simon
King, Jean-Pierre Flori, John Perry, Nils Bruin
Authors: Simon King, Jean-Pierre Flori | Merged in:
Dependencies: #715, #11521, #12215, #13746, #13378 | Stopgaps:
--------------------------------------------------------+-------------------
Comment (by SimonKing):
Replying to [comment:289 jdemeyer]:
> A priori, many other parts of the Sage library might also be affected.
And on the other hand, many other parts of the Sage library are affected
by keeping garbage in memory indefinitely.
I think the normal behaviour of a CAS should be that a structure S is
considered garbage and can be collected, unless the user has constructed
some object O and keeps a reference to it, and O keeps a chain of
references to S. Sadly, that was not the case for Sage, but this ticket is
part of an attempt to make Sage behave "normally" in that department.
Hence, if the same structure is needed repeatedly during a computation,
then the programmer should keep a reference to it locally, rather than
relying on an external cache. And if different methods of an object O will
use the same structure S, then it makes sense to store S as an attribute
of O, in order to prevent S from being garbage collected as long as O is
alive (but not longer than that).
I think what Nils wanted to say is: If other parts of the Sage library do
not obey the general rules formulated in the preceding paragraph, but rely
on an infinite external cache, then they need to be fixed. But the need to
fix them should not prevent us from changing the infinite external cache
to a finite external cache, because that is of benefit for all parts in
the Sage library that follow the general rules.
Jeroen, I guess you have access to doc test timings for various versions
of Sage. Would it be possible for you to find out which tests become
slower with #12313? That might give us an idea how bad of a regression we
would have.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12313#comment:291>
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.
