#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:38 SimonKing]:
> Hmm. I guess it isn't very clear yet. Perhaps it is best to try and
provide a proof of concept, sometimes in the next days.
I'm pretty sure you'll find it to be incredibly painful. A homset and a
homomorphism are only healthy if their domains and codomains exist. They
should therefore have strong references to them. The protocols required to
correctly handle homsets and homomorphisms without those strong references
will be very painful. What's worse, those homomorphisms will often still
work correctly if the proper protocol isn't followed, because domain and
codomain will usually not be very quickly reclaimed by GC. So you'll very
likely have very hard to find bugs.
Maps in the coercion system are a little different: We'd only be looking
up the map if we HAVE domain and codomain (in fact, the lookup would be
keyed on them). One way of dealing with this is not to have full-blown
maps as mathematical objects, but just have a "premap" ... the minimal
data to define the coercion map. I think it's a mistake to allow our full-
blown maps to also stand in for such "premaps". Note that a premap will
usually need strong references to the codomain anyway. Most of the time, a
premap is just a sequence of images of the generators of the domain.
Certainly, "premaps" don't need to have a reference to a homset.
I think the easier solution is to devise a strategy to store coercions on
either domain or codomain.
Any complication in lookup from these could be alleviated by having a
global, fully weak, triple dict keyed on domain and codomain, containing
the coercion map (weakly referenced). That way, it's not important whether
the coercion is stored in `_coerce_from` or in `_coerce_to`. Those list
would only be responsible for keeping a strong reference. The lookup could
happen in a global, fully weak, associative lookup. I think you ended up
with a similar structure around actions or homsets somewhere.
The main thing this gets us is flexibility in WHO is keeping the strong
refs to our coercion maps (usually either domain or codomain; are there
other possibilities?). I'm not sure it fully solves our problems. It does
if we can make a "mortality hierarchy", and store the ref on the more
mortal one (preferring the codomain in case of a draw).
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:39>
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.
