Prev: TPS
Next: Style, or lack thereof in Graham's ANSI CL
From: George Neuner on 21 Dec 2009 00:55
On Sat, 19 Dec 2009 07:48:20 +0000 (UTC), Kaz Kylheku
<kkylheku(a)gmail.com> wrote:

>On 2009-12-18, George Neuner <gneuner2(a)comcast.net> wrote:
>> On Fri, 18 Dec 2009 21:27:17 +0000 (UTC), Kaz Kylheku
>><kkylheku(a)gmail.com> wrote:
>>
>>>On 2009-12-16, George Neuner <gneuner2(a)comcast.net> wrote:
>>>> On Wed, 16 Dec 2009 18:04:14 +0000 (UTC), Kaz Kylheku
>>>><kkylheku(a)gmail.com> wrote:
>>>>
>>>>>Refcounting can't be deferred,
>>>>
>>>> There are lazy refcounters which defer recycling until the memory is
>>>
>>>But do they defer the counting? The actual bumping up and down of refcounts?
>>>That's a cost.
>>
>> With compiler cooperation, count manipulation can be elided in many
>> circumstances.
>>
>> For example, temporary references that exist under
>> strict stack semantics do not require object counter updates as they
>> come and go.
>
>Yes, been there done that; in C++ you can express it directly like this:
>
> void function(const ref_type &objref)
> {
> }
>
>I.e. pass the refcounted smart pointer by reference binding, rather
>than by value.
>
>This doesn't require special compiler cooperation; only that
>it implement C++ references properly.

True, but I'm not assuming the compiler targets C++ ... strict stack
semantics allow for any pointer-like representation to elide reference
counts for temporaries in any language.

George
From: Vend on 21 Dec 2009 04:30
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.

> So what you have to do is banish all variable assignment.

Reference cycles can be handled in a reference counted memory
mangagment system too.
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.

> 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.
From: Tim Bradshaw on 21 Dec 2009 04:54
On 2009-12-21 09:30:19 +0000, Vend <vend82(a)virgilio.it> said:
>> [...]
> You can defer deallocation, or run it concurrently in another thread.
>> [...]
> Many hybrid approaches defer counter updates.
>> [...]
> Reference cycles can be handled in a reference counted memory
> mangagment system too.
> 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.
>> [...]
> You can do that using lazy evaluation.

Or in other words: you can make a reference counting system do a lot of
what GC'd system does anyway, except for the toxic
look-at-all-the-dead-objects-thus-trashing-the-cache stuff.

Alternatively, you could, you know, use a garbage collector.

--tim

From: Vend on 21 Dec 2009 06:22
On Dec 21, 10:54 am, Tim Bradshaw <t...(a)cley.com> wrote:
> On 2009-12-21 09:30:19 +0000, Vend <ven...(a)virgilio.it> said:
>
> >> [...]
> > You can defer deallocation, or run it concurrently in another thread.
> >> [...]
> > Many hybrid approaches defer counter updates.
> >> [...]
> > Reference cycles can be handled in a reference counted memory
> > mangagment system too.
> > 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.
> >> [...]
> > You can do that using lazy evaluation.
>
> Or in other words: you can make a reference counting system do a lot of
> what  GC'd system does anyway, except for the toxic
> look-at-all-the-dead-objects-thus-trashing-the-cache stuff.
>
> Alternatively, you could, you know, use a garbage collector.

Reference counting memory managment is a form of garbage collection.

Possibly you mean tracing garbage collection, which either sweeps dead
objects or moves live objects around the heap, in both cases affecting
caching performance.
From: Tim Bradshaw on 21 Dec 2009 06:57
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.
>
> 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. Anything that spends its time walking all
over dead data is kind of inherently awful.

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