On 4/17/2014 2:32 AM, Paulo Pinto wrote:
> Similar approach was taken by Microsoft with their C++/CX and COM integration.
>
> So any pure GC basher now uses Apple's example, with a high probability of not
> knowing the technical issues why it came to be like that.

I also wish to reiterate that GC's use of COM with ref counting contains many, many escapes where the user "knows" that he can just use a pointer directly without dealing with the ref count. This is critical to making ref counting perform.

But the escapes come with a huge risk for memory corruption, i.e. user mistakes.

Also, in C++ COM, relatively few of the data structures a C++ program uses will be in COM. But ARC would mean using ref counting for EVERYTHING.

Using ARC for *everything* means slow and bloat, unless Manu's assumption that a sufficiently smart compiler could eliminate nearly all of that bloat is possible.

Which I am not nearly as confident of.

On 4/17/2014 5:34 AM, Manu via Digitalmars-d wrote:
> People who care would go to the effort of manually marking weak references.

And that's not compatible with having a guarantee of memory safety.

Walter Bright:

> I know that you bring up the array literal issue and gc a lot, but this is simply not a major issue with @nogc. The @nogc will tell you if it will allocate on the gc or not, on a case by case basis, and you can use easy workarounds as necessary.

Assuming you have seen my examples with dmd/ldcs, so are you saying that according to the compilation level the compiler will accept or not accept the @nogc attribute on a function?

Bye,
bearophile

On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright wrote:
>> With current limitations @nogc is only useful to verify that embedded code which
>> does not have GC at all does not use any GC-triggering language features before
>> it comes to weird linker errors / rt-asserts. But that does not work good either
>> because of next problem:
>
> Remember that @nogc will be inferred for template functions. That means that whether it is @nogc or not will depend on its arguments being @nogc, which is just what is needed.

No, it looks like I have stated that very wrong because everyone understood it in completely opposite way. What I mean is that `put()` is NOT @nogc and it still should work. Same as weakly pure is kind of pure but allowed to mutate its arguments, proposed "weakly @nogc" can only call GC via functions directly accessible from its arguments.

>> === Problem #2 ===
>>
>> The point where "I told ya" statement is extremely tempting :) bearophile has
>> already pointed this out - for some of language features like array literals you
>> can't be sure about possible usage of GC at compile-time as it depends on
>> optimizations in backend. And making @nogc conservative in that regard and
>> marking all literals as @nogc-prohibited will cripple the language beyond reason.
>>
>> I can see only one fix for that - defining clear set of array literal use cases
>> where optimizing GC away is guaranteed by spec and relying on it.
>
> I know that you bring up the array literal issue and gc a lot, but this is simply not a major issue with @nogc. The @nogc will tell you if it will allocate on the gc or not, on a case by case basis, and you can use easy workarounds as necessary.

Beg my pardon, I have overstated this one indeed but temptation was just too high :) On actual topic - what "case by case" basis do you have in mind? There are no cases mentioned in spec when literals are guaranteed to not allocated AFAIK. Probably compiler developers know them but definitely not me.

On Thursday, 17 April 2014 at 15:49:44 UTC, Dicebot wrote:
> put() may call GC to grow the buffer, this is the very point. What is desired is to check if anything _else_ does call GC, thus the "weak @nogc" parallel.

What do you need that for?

>> Of course, resorting to templates requires some thinking-ahead, and makes reuse more difficult.
>
> I don't see how templates can help here right now.

Wasn't the problem that the type-interface was less constrained than the type-interface allowed by a @nogc constrained function?

I perceive the problem as being this: you cannot fully specify all types because of the combinatorial explosion. In which case templates tend to be the easy-hack-solution where the type system falls short?

On Thursday, 17 April 2014 at 17:48:39 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 17 April 2014 at 15:49:44 UTC, Dicebot wrote:
>> put() may call GC to grow the buffer, this is the very point. What is desired is to check if anything _else_ does call GC, thus the "weak @nogc" parallel.
>
> What do you need that for?

As a middle-ground between hard-core low level real-time code and applications that don't care about garbage at all. As soon as you keep your buffers growing and shrink only occasionally "GC vs malloc" issues becomes less important. But it is important to not generate any actual garbage as it may trigger collection cycles.

Such weak @nogc could help to avoid triggering allocations by an accident and encourage usage of output ranges / buffers. Currently code in Sociomantic uses similar idioms but having compiler help to verify it would help in my opinion.

>>> Of course, resorting to templates requires some thinking-ahead, and makes reuse more difficult.
>>
>> I don't see how templates can help here right now.
>
> Wasn't the problem that the type-interface was less constrained than the type-interface allowed by a @nogc constrained function?

No, this is something completely different, see my answer before.

On Thursday, 17 April 2014 at 18:00:25 UTC, Dicebot wrote:
> Such weak @nogc could help to avoid triggering allocations by an accident and encourage usage of output ranges / buffers.

Ok, more like a "lintish" feature of the "remind me if I use too much of feature X in these sections" variety.

I view @nogc as a safeguard against crashes when I let threads run while the garbage collector is in a collection phase. A means to bypass "stop-the-world" collection by having pure @nogc threads.

> No, this is something completely different, see my answer before.

Got it, I didn't see that answer until after I wrote my reply.

Ola.

On Thursday, 17 April 2014 at 18:18:49 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 17 April 2014 at 18:00:25 UTC, Dicebot wrote:
>> Such weak @nogc could help to avoid triggering allocations by an accident and encourage usage of output ranges / buffers.
>
> Ok, more like a "lintish" feature of the "remind me if I use too much of feature X in these sections" variety.
>
> I view @nogc as a safeguard against crashes when I let threads run while the garbage collector is in a collection phase. A means to bypass "stop-the-world" collection by having pure @nogc threads.

Yeah for me @nogc is more of a lint thing in general. But it can't be done by lint because @nogc needs to affect mangling to work with separate compilation reliably.

I think for your scenario having dedicated @nogc threads makes more sense, this can be built on top of plain function attribute @nogc.

On Thursday, 17 April 2014 at 18:26:25 UTC, Dicebot wrote:
> I think for your scenario having dedicated @nogc threads makes more sense, this can be built on top of plain function attribute @nogc.

Yes, that could be a life saver. Nothing is more annoying than random crashes due to concurrency issues because something "slipped in".

But I think both you and Bearophile are right in pointing out that it needs more thinking through. Especially the distinction between calling into GC code and dealing with GC memory.

For instance, maybe it is possible to have a memory pool split in two, so that the no-GC thread can allocate during a collection cycle, but be required to have a lock-free book-keeping system for all GC memory referenced from the no-GC thread. That way you might be able to use GC allocation from the no-GC thread.

Maybe that is a reasonable trade-off.

(I haven't thought this through, it just occurred to me)

Ola.

On 4/17/2014 10:05 AM, Steven Schveighoffer wrote:
>> Obj-C only uses ARC for a minority of the objects.
> Really? Every Obj-C API I've seen uses Objective-C objects, which all use RC.

And what about all allocated items?


>> A UI is a good use case for ARC. A UI doesn't require high performance.
> I've written video processing/players on iOS, they all use blocks and reference
> counting, including to do date/time processing per frame. All while using RC
> network buffers. And it works quite smoothly.

And did you use ref counting for all allocations and all pointers?

There's no doubt that ref counting can be used successfully here and there, with a competent programmer knowing when he can just convert it to a raw pointer and use that.

It's another thing entirely to use ref counting for ALL pointers.

And remember that if you have exceptions, then all the dec code needs to be in exception unwind handlers.