On Monday, 23 February 2015 at 08:27:52 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 23 February 2015 at 01:41:17 UTC, Adam D. Ruppe wrote:
>> On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:
>>> All my ref counting types fiddle with the ref in every assignment, or every function call and return.
>>
>> Hmm, the optimizer could potentially tell "inc X; dec X;" is useless and remove it without knowing what it is for.
>
> INPUT:
>
> try{
> nonsharedobj._rc++;
> …
> }
> finally {
> nonsharedobj._rc--;
> if(nonsharedobj._rc==0) destroy…
> }
>
> OPTIMIZED:
>
> try{
> …
> }
> finally {
> if(nonsharedobj._rc==0) destroy…
> }
>
> ----
> Thanks to the messed up modular arithmetics that D has chosen you cannot assume the a non-shared live object does not have a rc==0 due to wrapping integers, in the general case.

You mean when there are more than 2^64 references to the object?

On 2/23/2015 12:33 AM, Tobias Pankrath wrote:
> On Monday, 23 February 2015 at 08:27:52 UTC, Ola Fosheim Grøstad wrote:
>> Thanks to the messed up modular arithmetics that D has chosen you cannot
>> assume the a non-shared live object does not have a rc==0 due to wrapping
>> integers, in the general case.
>
> You mean when there are more than 2^64 references to the object?

Yeah, it'll wrap when there are more references than can even theoretically fit in the address space.

I'm not worried about it :-)

On Monday, 23 February 2015 at 06:51:21 UTC, Walter Bright wrote:
> 4. DIP25, now implemented, is a way to address memory safety in D while using reference counting. Any proposal for ARC needs to, at least, understand that proposal.

I asked further up in the thread if coroutines can hold onto "return ref", e.g. does the compiler prevent a yield?

It would be nice if you and Andrei admitted that you are in the land of complicated linear typing with "return ref".

On Monday, 23 February 2015 at 08:33:59 UTC, Tobias Pankrath wrote:
> You mean when there are more than 2^64 references to the object?

I mean that the optimizer does not know what _rc is. The optimizer can only elide what it can prove, by sound logic, not by assumptions.

"Ola Fosheim Grøstad" " wrote in message news:hwwotfmkjvwsempqibla@forum.dlang.org...

> I mean that the optimizer does not know what _rc is. The optimizer can only elide what it can prove, by sound logic, not by assumptions.

The whole point of compiler-supported RC is that the optimizer can make assumptions. 

On Monday, 23 February 2015 at 08:50:28 UTC, Walter Bright wrote:
> On 2/23/2015 12:33 AM, Tobias Pankrath wrote:
>> On Monday, 23 February 2015 at 08:27:52 UTC, Ola Fosheim Grøstad wrote:
>>> Thanks to the messed up modular arithmetics that D has chosen you cannot
>>> assume the a non-shared live object does not have a rc==0 due to wrapping
>>> integers, in the general case.
>>
>> You mean when there are more than 2^64 references to the object?
>
> Yeah, it'll wrap when there are more references than can even theoretically fit in the address space.
>
> I'm not worried about it :-)

You don't worry about a lot of things that you ought to worry about :-P

On Monday, 23 February 2015 at 09:01:23 UTC, Daniel Murphy wrote:
> "Ola Fosheim Grøstad" " wrote in message news:hwwotfmkjvwsempqibla@forum.dlang.org...
>
>> I mean that the optimizer does not know what _rc is. The optimizer can only elide what it can prove, by sound logic, not by assumptions.
>
> The whole point of compiler-supported RC is that the optimizer can make assumptions.

Yes, but then it makes no sense to tell Manu that he should use a library RC...

It is nice to see at least one person admit that D needs to depart from modular arithmetic to solve real world problems... Because that is the implication of your statement. ;)

On Monday, 23 February 2015 at 07:19:56 UTC, Paulo Pinto wrote:
> Personally I think what matters is getting D's situation regarding memory management sorted out, regardless out it will look like in the end.

This is exactly right, either

1.  The compiler takes care of allocation/deallocations and makes refcounting part of the language implementation (but not necessarily the semantics).

or

2. If allocation/deallocation is not the compiler's responsibility then RC should be a library solution based on efficient generally useful counter-semantics build blocks.

A compiler solution for RC and manual allocations is a firefighter solution where all similar use cases suffers. I.e. when you want something similar to, but not exactly like what the compiler provides...

> If I am a bit too quick jumping the gun about GC, is that I have embraced GC languages in my line of work, so I tend to be aware that not all GCs are made alike and some like the ones from e.g. Aonix are good enough for real time situations, the ones someone dies if the GC runs on the wrong moment.
>
> Maybe such GC quality is impossible to achieve in D, I don't know.

Well, hard real time does not mean fast, it means "bounded execution time". GC will is not suitable for a lot of reasons when you want to get the most out of the hardware (just memory requirements on diskless systems is sufficient to disqualify GC). When people use the term "real time" on the forums, they usually just mean hardware-efficient and low latency.

On 23 February 2015 at 16:50, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/22/2015 9:53 PM, Manu via Digitalmars-d wrote:
>>
>> It's got nothing to do with doing work. ARC (or something like it) is almost religiously opposed. We can't even have a reasonable conversation about it, or really explore it's implications before someone (that ideally know's what they're doing) thinks about writing code.
>
>
> I participated in a very technical thread here on implementing ARC in D. I wanted to make it work - nothing was off the table, language changes, special features, etc.
>
> http://www.digitalmars.com/d/archives/digitalmars/D/draft_proposal_for_ref_counting_in_D_211885.html
>
> It was just unworkable, and nobody who participated in that thread had workable ideas on moving forward with it. Nothing since has come up that changes that. If you've got some ideas, please present them taking into account the issues brought up in that thread.

Wow, I missed that one it seems.
I'll catch up.


> Also, please take into account; proposals will not get much of a reception if they ignore these points:
>
> 1. Increment and decrement, ESPECIALLY DECREMENT, is EXPENSIVE in time and bloat because of exceptions. Swift does it by NOT HAVING EXCEPTIONS. This is not an option for D.

This is going to sound really stupid... but do people actually use
exceptions regularly?
I've never used one. When I encounter code that does, I just find it
really annoying to debug. I've never 'gotten' exceptions. I'm not sure
why error codes are insufficient, other than the obvious fact that
they hog the one sacred return value.
D is just a whisker short of practical multiple-return-values. If we
cracked that, we could use alternative (superior?) error state return
mechanisms. I'd be really into that.

I'll agree though that this can't be changed at this point in the game. You say that's a terminal case? Generating code to properly implement a decrement chain during unwind impacts on the non-exceptional code path?


> 2. As far as I can tell, the idea of flipping a compiler switch and the GC switches to ref counting is a pipe dream fantasy. You can probably make such a scheme work with a very limited language like Javascript, but it is never going to work with D's support for low level programming. The way RC and GC work is different enough that different user coding techniques will be used for them.

I agree. I would suggest if ARC were proven possible, we would like, switch.


> 3. Memory safety is a requirement for any ARC proposal for D. Swift ignores memory safety concerns.

What makes RC implicitly unsafe?

On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:
> On 23 February 2015 at 07:47, Walter Bright via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 2/22/2015 8:36 AM, Manu via Digitalmars-d wrote:
>>>
>>> I have no idea where to start.
>>
>>
>> Start by making a ref counted type and see what the pain points are.
>
> All my ref counting types fiddle with the ref in every assignment, or
> every function call and return. Unless the language has some sort of
> support for ref counting, I don't know how we can do anything about
> that.

There's no move constructor in D, so how did you manage that?