Re: Garbage collection and mutable data structures
- To: mathgroup at smc.vnet.net
- Subject: [mg85741] Re: Garbage collection and mutable data structures
- From: Szabolcs Horvát <szhorvat at gmail.com>
- Date: Wed, 20 Feb 2008 07:05:07 -0500 (EST)
- Organization: University of Bergen
- References: <200802160833.DAA05441@smc.vnet.net> <fp99hk$1i0$1@smc.vnet.net> <fpdv2h$rgj$1@smc.vnet.net>
massyah at gmail.com wrote:
> Thanks for all the answers!
>
>> It looks like if you let a temporary escape from the Module[] (i.e. you
>> create references to it outside the Module[] by returning it), then it
>> won't be cleaned up.
>
> Yes, this is exactly my problem, as I want a module to create some
> references, while being able to free them automatically afterwards.
>
>
>> The temporary 'c' variables are still in use because Up Values are
>> attached to them!
>
> Yes, but should'nt they be freed anyway, regardless of the info
> attached to them ? My point of view (coming from other languages with
> garbage collection / reference couting) is that any variable with a
> ref count of 0 should be freed. Here, all the "c" returned by the
> module should have a ref count of 0 since I can't access them (except
> by listing all the variables in the kernel). And the same problem
> arise if I use the dual (downvalues attached to "c")
>
>
>> Why not describe what it is you are trying to do.
>
> Because I thought it was not significant for this problem.
>
> Basically, I want to describe mutable data structures with pointers
> (i.e. any kind of graph). Let's say I want to encode the chained list
> c0 -> c1 -> c2
> where (for a memory-wise approach) the only way to access to c2 is to
> traverse the structure by using a "NextCell" pointer. I thought of
> using upvalues in this scheme:
> * c1 == NextCell[c0]
> * c2 == NextCell[NextCell[c0]]
> etc.
>
> In e.g. python, whenever I "release" c0 by assigning it a new value,
> the whole graph is discarded (since I don't have any way to access
> c1,c2 etc.). I want to replicate this in Mathematica, without
> explicitly having to free all the graph via a traversal.
>
>
>
>> try
>> Information /@ Names["c$*"]
>>
>> and find out where the reference to c$* is keept.
>
> All the references to c are kept in the global module, with a
> downvalue attached to them.
>
> Global`c$100
> Attributes[c$100]={Temporary}
> c$100[CellVal]=26
>
>
>
>
>> I don' think so, have you accounted for the memory used to hold the =A0
>> values of CellVac[c]?
>
>
> Since I'm using upvalues, all the info is kept in the "c"s and CellVal
> stays empty:
>
> ?CellVal
> Global`CellVal
Hayssam,
It seems to me that you are a bit confused about how Mathematica works.
Mathematica is very different from Python. The preferred way of
working with Mathematica is using a functional approach to problems, and
this doesn't work well with mutable data structures.
I am not very familiar with Python, but if I understand correctly,
Python variables are just handles (pointers) to objects in memory. You
can have several handles to the same object (in fact, this is the
default behaviour when "assigning" one variable to the other). In
Mathematica one doesn't use handles. In fact it is not even possible to
have two variables that refer to the *same* object in memory.
When you work with Mathematica, you don't generally change objects
(data). Instead, you apply functions to them, which return entirely new
objects. (Whether the returned object actually uses the same piece of
memory that was occupied by the original object depends on the
implementation. Of course, in many cases it would be a waste to
reallocate the memory and copy the data. But conceptually the returned
object is still completely different from the one you applied the
function to; and you have no access to any handles.)
Of course it is possible to change data like this:
arr[[12]] = newValue
But this is slow, and when performance matters it is better avoided.
And strictly speaking, allowing this does not even require mutability of
data. What happens (conceptually) is that the Part function uses the
old OwnValue of arr to compute a new OwnValue and attach it to arr.
To summarize, you can't have real mutability because you can't have
handles to the data.
I am not a programmer and I have no training in computer science, so
what I said above may have faults and errors, but I hope that it is at
least useful to you. :)
Szabolcs
P.S. If a symbol is returned from a Module[], it is reasonable to
expect that it will continue to exists, together with all the data
attahced to it (*Values, Attributes etc.). Ohterwise why would one want
to return a symbol at all?
- References:
- Garbage collection and mutable data structures
- From: massyah@gmail.com
- Garbage collection and mutable data structures