On 7/1/2013 6:08 AM, Steven Schveighoffer wrote:
> On Jul 1, 2013, at 3:11 AM, Walter Bright wrote:
>
>> On 6/30/2013 7:36 PM, Steven Schveighoffer wrote:
>>> I think that's a tall order presently.  For instance, on linux, the threads are all stopped using a signal.  It's a very bad idea to run destructors in a signal handler.
>>>
>>> What it seems like you are saying is that a prerequisite for ref counting is to have thread-local GC working.  If that is the case, we need to start a thread-local GC "thread" before this goes any further.
>> Not really. This doesn't make anything worse. Also, the proposed solution to this issue is to post the "destruct" list to the appropriate thread, and that thread runs it next time it calls the GC.
> I really urge you to make this a separate project.  It's not trivial. Logically, it's sound, but the implementation will be very difficult.  I also think Sean (and probably others) should be involved for that discussion.

Make what a separate project? The destruction of objects by the GC in local threads? It already is not part of the ref counting proposal.

Steven Schveighoffer wrote:

On Jul 1, 2013, at 12:17 PM, Walter Bright wrote:

>> I really urge you to make this a separate project.  It's not trivial. Logically, it's sound, but the implementation will be very difficult.  I also think Sean (and probably others) should be involved for that discussion.
>
> Make what a separate project? The destruction of objects by the GC in local threads? It already is not part of the ref counting proposal.
>


As far as I can tell, the ref counting proposal is not viable without it, as long as you insist on non-atomic RC increments and decrements.  How can it possibly not be a prerequisite to this, and therefore part of the proposal?

Unless you are saying now that atomic ref counting is OK?

I'm going by your previous statement:

> I very much want to avoid requiring atomic counts - it's a major performance penalty.


-Steve

On 10/9/2013 7:21 PM, deadalnix wrote:
> It means OOP is completely broken with that design.

I know. The thread kind of petered out as we began to realize the obstacles with this approach. But it's important to have the conversation in the record so we don't have to go through it again.

On 2013-10-10 04:35, Walter Bright wrote:
> Steven Schveighoffer wrote:
>
> On Jul 1, 2013, at 12:17 PM, Walter Bright wrote:
>
>  >> I really urge you to make this a separate project.  It's not
> trivial. Logically, it's sound, but the implementation will be very
> difficult.  I also think Sean (and probably others) should be involved
> for that discussion.
>  >
>  > Make what a separate project? The destruction of objects by the GC in
> local threads? It already is not part of the ref counting proposal.
>  >
>
>
> As far as I can tell, the ref counting proposal is not viable without
> it, as long as you insist on non-atomic RC increments and decrements.
> How can it possibly not be a prerequisite to this, and therefore part of
> the proposal?
>
> Unless you are saying now that atomic ref counting is OK?
>
> I'm going by your previous statement:
>
>  > I very much want to avoid requiring atomic counts - it's a major
> performance penalty.
>
>
> -Steve

Is this the last email in the conversation? In that case I think you clearly mark that with a post.

-- 
/Jacob Carlborg

And that's the last email in the original thread!

On 10/10/2013 12:31 AM, Walter Bright wrote:
> And that's the last email in the original thread!

Durn, no it isn't.

On 10/9/2013 11:52 PM, Jacob Carlborg wrote:
> Is this the last email in the conversation?

Yes, I posted them in chronological order.

On 10/10/2013 03:45 AM, Walter Bright wrote:
> Rainer Schuetze wrote:
>
> You have to put the lock around the pair of AddRef and Release, but if the compiler already splits this into two function calls, this cannot be done in the implementation.
I would imagine the counter to be manipulated with atomic_add_and_fetch operations, so no locks are required.

> What are the plans for coalescing and optimizing away some reference counts updates?

There is now a discussion and paper on optimizing a reference counter:
http://lambda-the-ultimate.org/node/4825

Bye,
bearophile

On 10/11/13 10:28 AM, bearophile wrote:
>> What are the plans for coalescing and optimizing away some reference
>> counts updates?
>
> There is now a discussion and paper on optimizing a reference counter:
> http://lambda-the-ultimate.org/node/4825
>
> Bye,
> bearophile

Yes, I think that's great work.

Andrei