In a language with "pointer" types, reference counting cannot work. If you create a cycle (like a linked list where the last element points to the first one) you can never reach count 0 for all the objects in the cycle. The only way to properly manage memory environments where you allow pointers to keep alive objects (.NET, Java, and so on) and where you want "automatic" memory management (not C++), is to walk a different path (hoping I am not preaching to the converted...). Dyalog APL, where something similar to a pointer object was introduced years ago, implements both a simple reference counting scheme for simple allocation patterns and a much more complex (and unfortunately, expensive because bolted on top of the other one) mechanism to reclaim unreferenced cycles.
Example (pseudosyntax): A<-New Obj(1) Obj(1) has refcount = 1 B<-New Obj(2) Obj(2) has refcount = 1 A.x <- B Obj(2) has refcount = 2 B.x <- A Obj(1) has refcount = 2 Erase'A' Obj(1) has refcount = 1 Erase'B' Obj(2) has refcount = 1 In theory nothing is now keeping alive either A or B, they are "unreachable" but their refcounts are non-zero, so their cleaners cannot run. Game over: memory leak. -----Original Message----- From: Programming [mailto:[email protected]] On Behalf Of 'Jon Hough' via Programming Sent: giovedì 12 ottobre 2017 16:57 To: [email protected] Subject: Re: [Jprogramming] Garbage Collection and Objects By "explicitly release" you mean dereference in the following sense right? thingy=: ? 1000 * 1000 $ 0 NB. Lots of memory allocated. thingy=. 1 NB. The 1000x1000 matrix was dereferenced and is eventually GCed. But objects don't work like this: thingy =: 100 conew 'A' NB. Memory allocated for instance of A thingy=: 1 NB. instance of A was dereferenced, but memory not reclaimed - memory leak. My only question is, why not automatically reclaim dereferenced objects? I guess it is difficult to decide if an object is no longer reachable, since objects are referenced as boxed literals. Any boxed literal could inadvertently "reference" an object that would otherwise be ready for GC. In an imaginary J with a "Pointer" datatype, or whatnot, it would be easier to figure out that an object is not reachable, just by reference counting the "Pointers" to the object. -------------------------------------------- On Thu, 10/12/17, Raul Miller <[email protected]> wrote: Subject: Re: [Jprogramming] Garbage Collection and Objects To: "Programming forum" <[email protected]> Date: Thursday, October 12, 2017, 9:21 PM Anything involving names in locales needs explicit GC. So, for example: thingy=: i.1e6 That name - thingy - will persist until you explicitly release it. Locales actually make this a bit easier (since you can erase the entire locale rather than having to erase all the names in it). The problem comes when you have been trained to use millions of tiny objects. That's a bad habit not just because of "GC", but because it's a poor use of space and time, in J. Generally speaking, in J you want to arrange things so the low level structures are regular and the complexity bubbles up to the top levels. This tends to be great for comprehension, but painful or worse when you are not supposed to be able to understand what you are working on. Thanks, -- Raul On Thu, Oct 12, 2017 at 5:50 AM, 'Jon Hough' via Programming <[email protected]> wrote: > Is there a reason J doesn't perform GC on objects? I was unaware we had to destroy our own objects > (In retrospect, I guess the existence of codestroy was a hint ). > > Example: > > oclass 'B' > > create=: 3 : 0 > > Mat=: ? (y,y) $ 0 > ) > > destroy=: codestroy > > > > > coclass 'A' > > > create=: 3 : 0 > iterations=: y > myB=: '' > ) > > > runLoop=: 3 : 0 > ctr=: 0 > while. ctr < iterations do. > myB=: 400 conew 'B' > ctr=:>:ctr > end. > 'finished' > ) > > > destroy=: codestroy > > > myA=: 1000 conew 'A' > runLoop__myA 0 > NB. Let myB reference an int now. It might be expected that the > NB. > 400x400 matrix's memory allocation was freed, but it > NB. is still there. > myB__myA=: 1 > > Viewing memory usage in htop or Activity Monitor, this program goes into the Gigabytes quickly and as far as I can see the > memory is never reclaimed. > I am not complaining, I am just wondering, why unreferenced objects are > not GCed, > and also recommend that OOP explanations in the Wiki, JforC > (assuming a new edition) be a little more explicit > in the necessity of > codestroy. > > This is A's runLoop that destroy unreferenced objects > runLoop=: 3 : 0 > ctr=: 0 > while. ctr < iterations do. > if.-. myB -: '' do. > destroy__myB '' > end. > myB=: 400 conew 'B' > ctr=:>:ctr > end. > 'finished' > ) > > > Using this, memory allocation does not increase. I'm sure this is probably obvious to J experts, but as far as I can see, doing there is > no explicit explanaiton of this anywhere. > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
