#14711: Memleak when creating QuadraticField
-------------------------------------------------+-------------------------
Reporter: jpflori | Owner:
Type: defect | davidloeffler
Priority: critical | Status: new
Component: number fields | Milestone: sage-5.12
Keywords: memleak, number field, | Resolution:
QuadraticField | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: u/SimonKing/ticket/14711 | Commit:
Dependencies: | Stopgaps:
-------------------------------------------------+-------------------------
Comment (by nbruin):
Replying to [comment:54 SimonKing]:
> It ''could'' in principle mean that the composite map gets deallocated,
while `__first` stays somewhere else in the coercion system, and now keeps
a parent (namely the middle one) alive that may be collectable. I'll worry
about it later...
Hm. Any time you have different versions of the same map that may diverge
in the strength with which they refer to one of their domain, codomain,
parent, etc., you'll need to make a copy to accommodate the divergence in
strength. So it probably makes sense to only have two levels: either
domain,codomain, and parent are referenced strongly or domain and codomain
are referenced weakly (and probably there's no reference to parent at
all).
That means that "weak" map compositions in the coercion system need to
have a strong reference to the middle domain. That shouldn't be too bad.
Apart from possible efficiency problems, I think this idea can be made to
work. The main programming penalty is the added burden on writing new map
classes: maps must be able to generate a copy of themselves. You could
make this optional: maps unable to copy themselves would be just stored
as-is in the coercion framework, with all the memory leak consequences
this has. If it's cheap to figure out if maps are weak and/or are capable
of generating a weak/strong version of themselves, we could just
accommodate both: If a "weakened" map arrives into the coercion framework
it can just be used as-is. If a normal map arrives, we see if it can be
weakened. If so, we make a weakened copy and store that. Otherwise the map
is used as-is.
If a map is about to be passed out of the coercion framework, we check if
it's weakened. If not, we can just give out the map itself. Otherwise, we
make a strengthened copy and give that. If making a strengthened copy is
not possible, we'd have to raise an error.
Of course the main point whether this is acceptable is whether it can be
done with little to no increase to overhead compared to now. Costs come at
two points
- map access: domain and codomain must always be accessed via the methods
rather than the (lightning fast) cdeffed attributes _domain and _codomain,
since they may be stored via weakref or not. Coercion lookup itself
shouldn't really be affected, but coercion application might. If the
parent of coercion maps is accessed in the process, we might see a
slowdown due to that too.
- coercion discovery and registration: This will likely involve copying
maps now, so this might slow down considerably. This shouldn't really be
an inner loop operation, but it may affect things: multimodular algorithms
may create lots of, say, matrix rings over finite fields. The computation
itself may be relatively cheap, so the construction of the parent and the
registration of its coercions may be a significant part of the total cost.
I guess the only way to see whether this is worth it is by trying. At
least the semantics are clear. I find it a little scary to weigh down the
entire interface for "Maps" but if we can make it opt-in it's perhaps not
too much of a burden. (We could just gradually upgrade map classes to be
"weakenable" as we find them to be responsible for memory leaks)
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:56>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
