#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 SimonKing):
Replying to [comment:39 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.
Not at all. Admittedly I had no time yet to run all tests. But Sage starts
and the memleak is fixed. I'll update the branch shortly.
> A homset and a homomorphism are only healthy if their domains and
codomains exist.
Correct.
> They should therefore have strong references to them.
No. If there is no external strong reference to domain/codomain and no
element of the homset exists that is stored outside of the coercion model,
then I think there is no reason to keep the homset valid. The
domain/codomain together with the coerce maps ''and'' together with the
homset should be garbage collected.
> The protocols required to correctly handle homsets and homomorphisms
without those strong references will be very painful.
No idea what you are talking about here. "Protocol" in the sense of
"interface"? Well, the interface will be the same. There is a callable
attribute ".domain()" of homsets and of maps. Currently, these callable
attributes are methods. With my patch, they are either `ConstantFunction`
or `weakref.ref`. At least for maps, there will be methods
`_make_weak_references()` and `_make_strong_references()` to choose
between the two.
> 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.
If you have a homomorphism outside of the coercion framework, then the
domain and codomain will be kept alive, unless you call
`_make_weak_references()` on the map (which the user shouldn't do---it is
an underscore method after all).
Otherwise, if you have no external strong reference to, say, the domain of
a coerce map, then there will be no supported way to access the coerce map
(namely, for `codomain.coerce_map_from(domain)` you'd need a reference to
the domain). So, I don't think there is a problem here.
> Maps in the coercion system are a little different: We'd only be looking
up the map if we HAVE domain and codomain
Exactly. And all other maps will keep the domain and codomain alive and
will thus keep the homset valid.
> 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).
Problem: If this is a global object, then you will have a strong reference
to it, hence, you will have a strong reference to all the coerce maps, and
thus (at least when you have strong references to domain and codomain)
''all'' parents that are ''ever'' involved in a coercion or conversion
''either'' as domain or codomain will be immortal.
> That way, it's not important whether the coercion is stored in
`_coerce_from` or in `_coerce_to`.
By the way, in the branch that I am preparing there is still only
`_coerce_from`. As it has turned out, a `_coerce_to` is not needed.
I am confident that my branch will have the following property: If a map
from P1 to P2 is cached in the coercion model, and you don't keep a strong
external reference to P1 (or P2), then P1 (or P2) can be garbage
collected. But if you keep a strong external reference to both P1 and P2,
then the map will stay in the cache.
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:40>
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.
