On Sunday, August 10, 2014 1:06:44 PM UTC-7, Dima Pasechnik wrote: > > hmm, AFAIK GAP will call its GC now and then, thus libGAP better be > able to cope with this... >
It will garbarge collect just fine. It's a question on the side of the memory manager whether unmapping memory pages or keeping them around for meeting the next allocation requests is better. Getting pages from and releasing pages to the operating system is generally quite expensive, so memory managers specialized for handling many (small) allocs/deallocs tend to keep an ample amount of memory around (never mind that fragmentation might lead to many barely filled pages, none of which *could* be returned. There's plenty of memory available to the memory manager, but memory allocations via other managers might fail. This problem is not a memory leak in any one of the memory managers individually, but it's a "memory page mapping" leak, which is only a leak when considered on the level of multiple long-lived processes or when you put multiple memory managers in the same process. 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). > Yes, we do that via a very simple mechanism: All EclObjects register their pointer to a lisp pointer to a global double-linked list within ecl/boehm's scope, and deregister that link upon their __dealloc__. This is an extremely cheap and effective mechanism, which was recommended by the main ecl developer at the time. EclObject by itself doesn't leak. The corresponding lisp objects have their lifetime bounded below by the referring EclObject, but not more than that (and with a mark/sweep collector like boehm, that's all you need). > 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. > Do you mean: also have a way to link "back" from ecl to python objects, i.e., let lisp objects impose lower bounds on lifetimes of certain python objects? Then cycle detection indeed becomes a problem, and doing that across the python/ecl boundary would require very careful coordination of *both* garbage collectors. This would entail a significant rewrite of *both*. The leak with symbols, however, would not even be solved by that. Certainly, currently, symbols in Pynac are immortal anyway, so there are no lifetimes to coordinate. Probably, given the age of Maxima, symbols are effectively immortal there too (maxima symbols are instantiated as lisp symbols, which are normally interned. If you don't manually unintern them, they would likely be immortal), so even solving the Pynac side would probably not solve the pynac/maxima leak, because maxima would still leak. It's rather fundamental: The "state" of computer algebra systems like maxima normally consists of all computations done until this moment (maxima has an unlimited history by default--we disable that). That includes all instantiated symbols. Finally, the string-based interface means that we fundamentally cannot tie lifetimes of python objects unambiguously to ecl objects: every (interned) symbol is alive, because it can be retrieved via its name. You'd have to be very careful in deciding when a symbol (and all its assumptions and other properties, including its translations to other computer algebra systems) can be discarded. Currently there is nothing to manage, because symbols are immortal anyway. If they weren't, you'd either need to artificially put lower bounds on their existence or be prepared to reinstall things like assumptions on them any time you are translating a symbol from one system to another. -- 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.
