Re: Storage management, was Compiler writers will love this

Dobes Vandermeer <dobes@dobesland.com>
25 Jul 2003 21:09:07 -0400

          From comp.compilers

Related articles
[6 earlier articles]
Re: Compiler writers will love this language ericmuttta@email.com (2003-07-02)
Re: Storage management, was Compiler writers will love this language rodney.bates@wichita.edu (Rodney M. Bates) (2003-07-04)
Re: Storage management, was Compiler writers will love this language nmm1@cus.cam.ac.uk (2003-07-13)
Re: Storage management, was Compiler writers will love this dobes@dobesland.com (Dobes Vandermeer) (2003-07-13)
Re: Storage management, was Compiler writers will love this language haberg@matematik.su.se (2003-07-17)
Re: Storage management, was Compiler writers will love this language waxlex@yahoo.co.uk (ikhnos) (2003-07-21)
Re: Storage management, was Compiler writers will love this dobes@dobesland.com (Dobes Vandermeer) (2003-07-25)
| List of all articles for this month |

From: Dobes Vandermeer <dobes@dobesland.com>
Newsgroups: comp.compilers
Date: 25 Jul 2003 21:09:07 -0400
Organization: Compilers Central
References: 03-05-211 03-06-015 03-06-054 03-06-057 03-06-078 03-06-106 03-07-023 03-07-044 03-07-064 03-07-118 03-07-154
Keywords: GC
Posted-Date: 25 Jul 2003 21:09:07 EDT

From: "ikhnos" <waxlex@yahoo.co.uk>


>> This works so that the objects are numbered consecutively as they
>> are created. A cycle can then be detected if it points to another
>> object with (depending on the setup) higher/lower number, which can
>> be used to adjust the ref count so that deletion takes place
>> appropriately also in cycles (which initially must have some
>> external ref pointing at them). A problem arises though if, after
>> an initial setup of references have been achieved, they are
>> relocated dynamically, creating new cycles. That is hard to track
>> down. But if that does not happen, one can make a version building
>> one this SCC algorithm to remove the cycles as well (or so I
>> remember).


> This is interesting.
>
> If P acquires a reference to a newer object Q, then Q's ref-count is
> incremented. If P acquires a reference to an older object Q, then Q's
> ref-count is NOT incremented.
>
> This makes the objects-and-references graph acyclic, overcoming the
> cyclic-reference problem.
>
> So: Question: What are the problems?


Well, what if you only have references from younger/older objects?


e.g. only younger objects
InputStream i = socket.getInputStream();
DataInputStream d = new DataInputStream(i);


If you only retain younger objects, "i" won't be ref'd and might be deleted
too soon.


or:


ArrayList a1 = new ArrayList();
ArrayList a2 = new ArrayList();
a1.add(a2);


If you only retain older objects, than a2 hasn't been ref'd, and will
be deleted once the scope falls away...


In languages without assignment, objects can't take pointers to
anything newer than them -- once they are created they stay the same.
Nevertheless, you can't create cycles in these language so reference
counting is already just fine. Typically, however, copying collectors
are more efficient for these languages; they don't need to run
destructors, they allocate short-lived objects like crazy, and so bulk
freeing of memory is a big win.


CU
Dobes


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.