#14711: Weak references in the coercion graph
-------------------------------------+-------------------------------------
       Reporter:  jpflori            |        Owner:  davidloeffler
           Type:  defect             |       Status:  needs_work
       Priority:  critical           |    Milestone:  sage-5.13
      Component:  number fields      |   Resolution:
       Keywords:  memleak, number    |    Merged in:
  field, QuadraticField              |    Reviewers:
        Authors:  Simon King         |  Work issues:  String repr. of
Report Upstream:  N/A                |  weakened maps; copying/pickling of
         Branch:                     |  maps
  u/SimonKing/ticket/14711           |       Commit:
   Dependencies:                     |  364b9856b28d7060e3ea9825144de66c8f11ca2a
                                     |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by SimonKing):

 Replying to [comment:122 nbruin]:
 > Replying to [comment:121 SimonKing]:
 > > Suppose you have two non-weakened maps phi and psi, and then do chi =
 phi*psi (a composite map). When you then weaken chi, neither phi nor psi
 would be changed. So, why copying?
 >
 > Well, if you'd do that then `chi` wouldn't really be a weakened map.
 Assuming maps act on the left, i.e. `chi.domain()=psi.domain()`, the
 resulting structure would have a strong reference to its domain, via
 psi.domain().

 Correct. Would this be a problem? Let's see:

 Let `psi: A -> B` and `phi: B -> C` be coerce maps, hence, `chi=phi*psi: A
 -> C` is a coerce map as well. Assume that we have done
 `B.register_coercion(psi)`, so that B prevents A from garbage collection.
 Assume that `phi` is only stored in `C._coerce_from_hash`, i.e., C would
 not prevent B from garbage collection. In other words, we assume that phi
 is weakened but psi isn't.

 Let us assume first that we did not discover `chi` as a coercion yet. If
 we have a strong reference to C but no external reference to B, then B and
 A could of course be garbage collected.

 Now, let us assume that we ''did'' discover that `chi` is a coercion and
 put it into `C._coerce_from_hash`, in the attempt of weakening it. C would
 have a strong reference to `chi`, which has a strong reference to its
 first map, `psi`, which has a strong reference to both its domain A and
 codomain B. Hence, C would prevent both A and B from garbage collection.

 I think this indeed qualifies as a memory leak, according to the
 definition I gave in some post above.

 Difficult. Can this be solved, even ''with'' copying? I have to think
 about it.

 > > This is already done in my current branch, and it is called
 `_registered_domains` (simply a list).
 >
 > And the maps inserted into `_coerce_from_hash` are weakened or not?

 In my current branch, it is not weakened. Perhaps it should be. It would
 indeed be conceptually easier if a map is in the coercion system if and
 only if it is weakened. One ''could'' do it, since `_registered_domains`
 would keep the domain alive, Note, however, that this would not suffice
 for fixing the memory leak described above. We would still have that `chi`
 refers to `psi`, which strongly refers to its ''codomain'' B (the codomain
 is always strong), and then `B._registered_domains` strongly refers to
 `A`.

 In this situation,
 - we want to have a strong reference from B to A, since we used
 `B.register_coercion(mor)`.
 - we must not have a strong reference from C to A, since `chi` was
 discovered but not registered.
 - we must not have a strong reference from C to B, since `phi` was not
 registered.
 - we could live with a strong reference from A to B, I guess.

 If C is alive, then we want that it does not prevent A or B from garbage
 collection. But if both A and C are alive, then `chi` must remain a valid
 map, hence, B must be prevented from garbage collection. It follows that
 if C is alive then either A and B get collected ''together'', or they both
 stay alive.

 I should catch some sleep now, perhaps I'll find a solution to the puzzle
 tomorrow.

--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:124>
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.

Reply via email to