Prev: TPS
Next: Style, or lack thereof in Graham's ANSI CL
From: Kaz Kylheku on 21 Dec 2009 12:49
On 2009-12-21, Vend <vend82(a)virgilio.it> wrote:
> On Dec 16, 7:04 pm, Kaz Kylheku <kkylh...(a)gmail.com> wrote:
>
>> Refcounting does not eliminate ``pauses'' from the program execution.
>> If you drop the last reference on an object which is itself the last
>> reference a large number of other objects, this triggers a cascade of
>> refcounts dropping to zero, which takes time to complete.
>
> You can defer deallocation, or run it concurrently in another thread.
>
>> Refcounting can't be deferred, so even a short-lived program whose heap
>> is cleaned up by the operating system has to waste cycles on
>> refcounting, whereas the program with GC wins simply by never invoking
>> GC over its lifetime.
>
> Many hybrid approaches defer counter updates.

Hybrid means that you have a puzzlingly pointless mix of real garbage
collection, and a dumb reference counting hacks.

>> So what you have to do is banish all variable assignment.
>
> Reference cycles can be handled in a reference counted memory
> mangagment system too.

If you can do this, there is no reason not to implement normal garbage
collection. People use reference counting hacks because they don't have
the support from the language to be able to implement proper gc.

> When an object reference count drops to a non-zero value, you put it
> in a set that is periodically scanned by a cycle detector.

Object reference counts drop to non-zero all the time, so this set is
going to have every object in the system, except for ones with simple
lifetimes that come into life existence with one reference, which
is then dropped.

>> Without cycles, you can't express graph structures, so an entire branch
>> of computer science goes out the window.
>
> You can do that using lazy evaluation.

I don't think so, and suspect that you're confusing implicitly infinite
lazy structures with cyclic structures (which also appear
infinite).
From: Vend on 21 Dec 2009 15:25
On Dec 21, 6:49 pm, Kaz Kylheku <kkylh...(a)gmail.com> wrote:
> On 2009-12-21, Vend <ven...(a)virgilio.it> wrote:
>
> > On Dec 16, 7:04 pm, Kaz Kylheku <kkylh...(a)gmail.com> wrote:
>
> >> Refcounting does not eliminate ``pauses'' from the program execution.
> >> If you drop the last reference on an object which is itself the last
> >> reference a large number of other objects, this triggers a cascade of
> >> refcounts dropping to zero, which takes time to complete.
>
> > You can defer deallocation, or run it concurrently in another thread.
>
> >> Refcounting can't be deferred, so even a short-lived program whose heap
> >> is cleaned up by the operating system has to waste cycles on
> >> refcounting, whereas the program with GC wins simply by never invoking
> >> GC over its lifetime.
>
> > Many hybrid approaches defer counter updates.
>
> Hybrid means that you have a puzzlingly pointless mix of real garbage
> collection, and a dumb reference counting hacks.

No argument?

> >> So what you have to do is banish all variable assignment.
>
> > Reference cycles can be handled in a reference counted memory
> > mangagment system too.
>
> If you can do this, there is no reason not to implement normal garbage
> collection. People use reference counting hacks because they don't have
> the support from the language to be able to implement proper gc.

Reference counting is a method that can be used by language compilers/
runtimes to implement proper gc.

> > When an object reference count drops to a non-zero value, you put it
> > in a set that is periodically scanned by a cycle detector.
>
> Object reference counts drop to non-zero all the time, so this set is
> going to have every object in the system, except for ones with simple
> lifetimes that come into life existence with one reference, which
> is then dropped.

As far as I know, statistically most object will have at most one
reference. Since these object can't appear in reference cycles, there
is no need to run the cycle detection algorthm on them.

> >> Without cycles, you can't express graph structures, so an entire branch
> >> of computer science goes out the window.
>
> > You can do that using lazy evaluation.
>
> I don't think so, and suspect that you're confusing implicitly infinite
> lazy structures with cyclic structures (which also appear
> infinite).

Cyclic data structures are substantially equivalent to infinite
periodic data structures.
From: Kaz Kylheku on 21 Dec 2009 16:09
On 2009-12-21, Tim Bradshaw <tfb(a)cley.com> wrote:
> On 2009-12-21 11:22:09 +0000, Vend <vend82(a)virgilio.it> said:
>
>> Reference counting memory managment is a form of garbage collection.
>
> That depends on who you ask, of course.

If you ask me, no. Reference counting is not garbage collection.

I may have thought so once, but I changed my mind, and I'm still getting
smarter. Therefore, it's smarter to regard refcounting as something
other than, or less than garbage collection. Q.E.D. :)

To me, garbage collection means: computing the lifetimes of objects without any
help from extra memory-management-related instructions added to the compiled
program.

Under garbage collection, the application program only ever makes one kind of
memory-management call: a request for the creation of a new object. It is
otherwise completely, void of all memory management concerns, both at the
source level, and in the compiled code.
From: Vend on 21 Dec 2009 17:26
> If you ask me, no. Reference counting is not garbage collection.
>
> I may have thought so once, but I changed my mind, and I'm still getting
> smarter. Therefore, it's smarter to regard refcounting as something
> other than, or less than garbage collection. Q.E.D. :)
>
> To me, garbage collection means: computing the lifetimes of objects without any
> help from extra memory-management-related instructions added to the compiled
> program.

In generational garbage collectors, the program will execute
additional instructions each time a reference to a young object is
stored inside an old object.

Do you consider generational GC a proper form of GC?

Even in non-generational tracing collectors, some instructions are
required to generate typing information for stack-allocated pointers
and heap-allocated objects for the marker (unless you perform
conservative GC, which sucks.)

From: Vend on 21 Dec 2009 17:27
On Dec 21, 12:57 pm, Tim Bradshaw <t...(a)cley.com> wrote:
> On 2009-12-21 11:22:09 +0000, Vend <ven...(a)virgilio.it> said:
>
> > Reference counting memory managment is a form of garbage collection.
>
> That depends on who you ask, of course.
>
>
>
> > Possibly you mean tracing garbage collection, which either sweeps dead
> > objects or moves live objects around the heap, in both cases affecting
> > caching performance.
>
> Yes.  I suspect copying collectors have rather good cache behaviour,
> since they almost inevitably mean that (some of) the live data is
> cached after the GC has run.

That's probably true of young-generation collection of generational
GC.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: TPS
Next: Style, or lack thereof in Graham's ANSI CL