Mathematica 9 is now available
Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

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?


  • Prev by Date: Re: A Use for Interpretation
  • Next by Date: Re: Differential Equation
  • Previous by thread: Re: Garbage collection and mutable data structuresDavid Bailey,http://www.dbaileyconsultancy.co.uk
  • Next by thread: Re: Garbage collection and mutable data structures