On 2014-08-10, Nils Bruin <nbr...@sfu.ca> wrote:
> ------=_Part_313_345193229.1407685130291
> Content-Type: text/plain; charset=UTF-8
>
> On Sunday, August 10, 2014 6:31:03 AM UTC-7, Dima Pasechnik wrote:
>>
>> if this is the case then how one would to to reclaim the memory?
>> And why this is not a memory leak?
>
>
> It's not necessarily a leak from the perspective of ecl: the memory
> obtained from the operating system may well sit there, ready to be filled
> with new lisp objects. From the python perspective you could call this a
> memory leak, though. But it's a virtually unavoidable one if you place
> multiple memory management systems in the same process that are not
> designed to cooperate: each thinks they have a complete view of the world
> but they don't. It may well be that ecl/boehm does unmap memory pages every
> now and again. But really, in our case the same scenarios can arise with
> pari/gp, libsingular, libgap
hmm, AFAIK GAP will call its GC now and then, thus libGAP better be
able to cope with this...
>
> Would at least restarting ecl release the memory?
>>
>
> Possibly.
my understanding is that it is possible to register with ECL external pointers
to
Lisp objects, so if such a pointer goes away (i.e. the corresponding Python
object is gone)
then it will become possible for ECL to collect its garbage related to this Lisp
object (i.e. calling in ECL (system:gc <level>) will do the right thing).
>
>> (it's not clear how the latter can be done; would maxima_calculus.reset()
>> do the job?)
>>
>
> restarting ecl is currently not a supported operation, because it would be
> a terribly difficult operation to do correctly: all EclObjects in python
> memory would somehow have to be "invalidated", a state that currently
> doesn't even exist for them. That also means *finding* those objects (or
> knowing that there are none-which will never happen because we have plenty
> of global EclObjects), which would require an extra expensive facility.
if the registration I talk about above is implemented, I imagine that
one can also create a database of EclObjects to maintain.
Although this is some extra cost, indeed.
>
> Regardless, of this, symbolics leak anyway:
>
> sage: for i in range(10000000): _=SR.var("t%d"%i)
>
> will steadily eat memory. Probably the pynac symbol table doesn't get
> garbage collected. Even if that wouldn't leak then
>
> sage: for i in range(10000000): _=maxima_calculus(SR.var("t%d"%i))
>
> and
>
> sage: from sage.interfaces.maxima_lib import sr_to_max
> sage: for i in range(10000000): _=sr_to_max(SR.var("t%d"%i))
>
> would leak for sure via slightly different mechanisms, but for the same
> reason: we need to keep symbols alive in python and in maxima, depending on
> the lifetime of objects in the other. To garbage collect these, you'd need
> cycle detection *across the python/ecl boundary*. So currently, symbols
> that have been transported across to maxima have eternal life. It seems
> that symbols in SR proper already have eternal life, so it doesn't really
> matter. Solving this leak would be really quite hard, so we should probably
> call it a "feature".
>
> The solution is to restart sage early and often. It has good facilities for
> it, see @parallel.
>
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
