Re: Garbage collection and mutable data structuresDavid Bailey,http://www.dbaileyconsultancy.co.uk
- To: mathgroup at smc.vnet.net
- Subject: [mg85720] Re: Garbage collection and mutable data structuresDavid Bailey,http://www.dbaileyconsultancy.co.uk
- From: David Bailey <dave at Remove_Thisdbailey.co.uk>
- Date: Wed, 20 Feb 2008 06:54:10 -0500 (EST)
- 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
>
>
> Thanks again for your answers,
> Hayssam.
>
As I mentioned above, I think using UpValues creates a loop of
references which reference counting can't handle. NewCell must contain a
reference to c$961 (or whatever) for it to work, and c$961 contains
references to NewCell embedded in its UpValues.
I have not tried this, but perhaps you could get what you want with
something like this:
C$1=Hold[{c$2,c$3,c$4}]
This would represent a link between c$1 and each of the other local
variables(i.e. more general than a linked list). The Hold is necessary
because in general the other nodes would have values too.
Note however, that if the structure you were describing was a general
graph, then the closed loops in that would presumably defeat the
reference counting strategy anyway!
Working with unevaluated data can take a bit of getting used to (!!),
but it can be quite powerful.
David Bailey
http://www.dbaileyconsultancy.co.uk
- References:
- Garbage collection and mutable data structures
- From: massyah@gmail.com
- Garbage collection and mutable data structures