#715: Parents probably not reclaimed due to too much caching
--------------------------------+-------------------------------------------
Reporter: robertwb | Owner: somebody
Type: defect | Status: needs_work
Priority: major | Milestone: sage-4.8
Component: coercion | Keywords: weak cache coercion
Work_issues: avoid regression | Upstream: N/A
Reviewer: | Author: Simon King
Merged: | Dependencies: #9138, #11900
--------------------------------+-------------------------------------------
Comment(by jpflori):
Replying to [comment:82 SimonKing]:
> An action of G on S stores direct references to G and to S. The action
is a functor, and as a functor, it additionally stores a reference to
`Groupoid(G)`, which stores another reference to G, and to the category of
S. In some cases, the category of S will store references to the base ring
of S (for example, if S is an algebra), which might have a pointer back to
S (for example if the action of `S.base_ring()` on S was registered during
initialisation). In this case, we are lost, since categories are unique
parents and thus strongly cached (unless we apply #12215, which poses some
problems). For the same reason, creating the groupoid of G will result in
an eternal reference on G (`Groupoid(G)` is strongly cached and it points
to G). So, the best that we can hope for is that we can free S at some
point, but we will never be able to free G. It starts to be complicated.
Time to call it a day... Perhaps the idea to register actions in the
parents (in addition to a weak cache in the coercion model) is better?
But if you store the actions in both parents (with strong references), you
will never be able to free any of the two domain and codomain.
In the ticket example for example you would get a strong reference to the
action in the ZZ cache (which will hopefully never get deleted) (in fact
that is what is happening with the current Sage version anyway, isn't that
strange according to what you posted, because I guess is already
initialized once the for loop is executed?) so the elliptic curves (in the
ticket example you only get one stored in that cache because comarison was
made with "==", if you let the j invariant change within the for loop you
would get a growing number of curves in that cache) will stay strongly
refed forever as well...
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/715#comment:83>
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.
