Opened 13 years ago

Last modified 8 years ago

#715 closed defect

Parents probably not reclaimed due to too much caching — at Version 7

Reported by: robertwb Owned by: somebody
Priority: major Milestone: sage-5.5
Component: coercion Keywords: weak cache coercion Cernay2012
Cc: jpflori, zimmerma, vbraun, robertwb, nbruin, malb, mjo Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by jpflori)

Here is a small example illustrating the issue.

The memory footprint of the following piece of code grows indefinitely.

sage: K = GF(1<<55,'t') 
sage: a = K.random_element() 
sage: while 1: 
....:     E = EllipticCurve(j=a); P = E.random_point(); 2*P; del E, P;

E and P get deleted, but when 2*P is computed, the action of integers on A, the abelian group of rational points of the ellitpic curve, gets cached in the corecion model.

A key-value pair is left in coercion_model._action_maps dict:

(ZZ,A,*) : IntegerMulAction?

Moreover there is at least also references to A in the IntegerMulAction? and one in ZZ._action_hash.

So weak refs should be used in all these places if it does not slow things too much.

Change History (7)

comment:1 Changed 13 years ago by mabshoff

  • Milestone set to sage-feature

comment:2 Changed 13 years ago by mabshoff

  • Milestone changed from sage-feature to sage-2.10.2

comment:3 Changed 12 years ago by mhansen

I think this is a bit too vague for a ticket. Robert, could you be more specific or close this?

comment:4 Changed 12 years ago by robertwb

The coercion model needs to use weakrefs so that parents aren't needlessly referenced when they're discarded. It is nontrivial to see where the weakrefs need to go, and how to do so without slowing the code down.

The ticket is still valid.

comment:5 Changed 10 years ago by davidloeffler

  • Component changed from basic arithmetic to coercion
  • Description modified (diff)
  • Report Upstream set to N/A

comment:6 Changed 9 years ago by jpflori

  • Cc jpflori added

comment:7 Changed 9 years ago by jpflori

  • Description modified (diff)

With the piece of code in the desrciption, there is only one reference to these objects in that ZZ._hash_actions dictionary because to build it we test if A1 == A2 and not A1 is A2 as in coercion_model._action_maps, and because of the current implementation of ellitpic curves, see and #11474, and decause the above code use only one j-invariant, only ones gets finally stored.

However with random curves, I guess there would be all of them.

About the weakref, the idea should more be to build something like WeakKeyDictionnary? if it does not slow down coercion too much...

Note: See TracTickets for help on using tickets.