I'd say that, normally speaking, a cache is something of limited size,
and managed - once it is full, the least used objects are removed to
make room for new objects. I don't know if there are CASs which use
such a design.
An unlimited size cache is easier and more efficient - as long as you have RAM.
On Sun, Sep 8, 2024 at 9:18 PM Marc Culler <marc.cul...@gmail.com> wrote:
>
> As I said above this does not happen with either cypari or cypari2 when using
> getno.
>
> This is not a cypari issue. The issue is that Sage creates a "unique" object
> for each new number field, where new means that the input parameters for the
> NumberField function have not been used before. The number field objects are
> stored in a cache indexed by a key generated from the input parameters.
> Those cached objects live for the entire session. This is by design. The
> design did not anticipate creating a billion number fields in one Sage
> session. That was not necessarily a bad choice.
>
> Perhaps there is a way of disabling caching or clearing the cache.
>
> - Marc
>
> On Sun, Sep 8, 2024, 1:02 PM Dima Pasechnik <dimp...@gmail.com> wrote:
>>
>> Can this be reproduced in plain Python with cypari2 installed?
>> One would need to replace the call to NumberField with the corresponding
>> cypari2 equivalent.
>> This would at least tell whether it's a leak in cypari2, or not.
>>
>> Dima
>>
>>
>>
>>
>>
>> On 8 September 2024 17:03:54 BST, Nils Bruin <nbr...@sfu.ca> wrote:
>>>
>>> This example is definitely leaving loads of stuff on the python heap, so if
>>> there is a leak onto the cython heap then it is not the only one. My guess
>>> would be an interaction with the coercion system or UniqueRepresentation,
>>> which both keeps global weak references to objects. If the key information
>>> ends up containing objects that hold a reference to the values in a weakly
>>> valued dictionary, the garbage collector can not remove the cycle. These
>>> things are hellish to debug. The code below does find the relevant objects
>>> on the heap, though, so you can plot the backwards reference graphs of some
>>> of these objects to see what kinds of links are involved. We have resolved
>>> some of these bugs in the past.
>>>
>>> ```
>>> import gc
>>> from collections import Counter
>>>
>>> gc.collect()
>>> pre={id(a) for a in gc.get_objects()}
>>>
>>> for A2 in range(1, 1000):
>>> Kn=NumberField(x^2+A2,'w')
>>> m=Kn.class_group().order()
>>> del Kn, m
>>>
>>> gc.collect()
>>> gc.collect()
>>> T=Counter(str(type(a)) for a in gc.get_objects() if id(a) not in pre)
>>> T
>>> ```
>>> Notes for the code above:
>>> - if you run it twice you get a nearly empty list from T, which is
>>> consistent with UniqueRepresentation objects remaining (they would not be
>>> recreated if they already exist).
>>> - this is confirmed by rerunning the loop but now with another name than
>>> 'w' for Kn. Now new objects do get created!
>>>
>>> On Wednesday 4 September 2024 at 06:09:37 UTC-7 Georgi Guninski wrote:
>>>>
>>>> Probably this shares the same bug as [1]
>>>>
>>>> Calling `NumberField().class_group().order()` in a loop of size N:
>>>> #10^3 leaks: 40.03 MB 40026112 pari= [7950, 1451665]
>>>> #10^4 leaks: 338.49 MB 338493440 pari= [83505, 19297360]
>>>>
>>>> The leak appears to be in the pari heap.
>>>>
>>>> Code .sage:
>>>> ====
>>>> #Author Georgi Guninski Wed Sep 4 12:58:18 PM UTC 2024
>>>> #10^3 leaks: 40.03 MB 40026112 pari= [7950, 1451665]
>>>> #10^4 leaks: 338.49 MB 338493440 pari= [83505, 19297360]
>>>>
>>>> import psutil,gc,sys
>>>>
>>>> from sage.all import EllipticCurve
>>>> ps = psutil.Process()
>>>> num=10**3 #10**5 // 2
>>>> x=var('x')
>>>> def leaknf5(N=10**3):
>>>> gc.collect()
>>>> base = ps.memory_info().rss
>>>> for A2 in range(1, N):
>>>> Kn=NumberField(x^2+A2,'w')
>>>> m=Kn.class_group().order()
>>>> gc.collect()
>>>> mem = ps.memory_info().rss - base
>>>> print(f"{mem/1e6 :.2f} MB ",mem," pari=",pari.getheap())
>>>>
>>>> leaknf5(10**4)
>>>> ====
>>>>
>>>> [1]: https://groups.google.com/g/sage-devel/c/fWBls6YbXmw
>>>> Memory leak in |EllipticCurve([n,0]).root_number()| and problem in
>>>> algebraic geometry
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "sage-devel" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/sage-devel/kbzd2uhTypU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> sage-devel+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sage-devel/6658541E-8E9B-446A-906E-1CE7E043E16C%40gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/CALcZXRGrcVy6g1puui87KR4SJzdbm6nMPhMk9pzYPRvZafy%3DJw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3rVR2rExMsQwFyg9%3D01NZ4zs2%2BA9sbmUFEKbo0RF3Y6g%40mail.gmail.com.
