Am 09.10.2013 01:29, schrieb Adam D. Ruppe:
>
> It is nice to have stdlib functions available that can be used anywhere.
> For std.algorithm, Andrei has said if you ever implement an algorithm by
> hand, it means the library has failed. But there's two places where that
> falls short (IMO at least): using it without allocating, and using it
> without bringing in a bazillion dependencies.
>

This. Exactly this was one of my biggest problems when writing GC free code. I started with "hey I just patch all places in phobos that do allocations". I planed to do so, so I can use std.algorithm and others. After trying for a while the dependencies killed me. So I just stopped altogether and rewrote whatever algorithm I would need myself. The dependencies between the modules in phobos are catastrophic. If you need one module, you basically need all of them.

Kind Regards
Benjamin Thaut

On Wednesday, 9 October 2013 at 07:33:38 UTC, Manu wrote:
> Is there more to it? Cleaning up circular references I guess... what does Apple do?
> It's an uncommon edge case, so there's gotta be heaps of room for efficient solutions to that (afaik) one edge case. Are there others?

There is a research paper people linked in a similar debate, that states systems that detect ARC circular references are actually not that far from an actual GC.
I can't find it right now.

On Wednesday, 9 October 2013 at 07:33:38 UTC, Manu wrote:
> On 9 October 2013 16:05, dennis luehring <dl.soluz@gmx.net> wrote:
>
>> Am 09.10.2013 07:23, schrieb PauloPinto:
>>
>>  Apple dropped the GC and went ARC instead, because they never
>>> managed to make it work properly.
>>>
>>> It was full of corner cases, and the application could crash if
>>> those cases were not fully taken care of.
>>>
>>> Or course the PR message is "We dropped GC because ARC is better"
>>> and not "We dropped GC because we failed".
>>>
>>> Now having said this, of course D needs a better GC as the
>>> current one doesn't fulfill the needs of potential users of the
>>> language.
>>>
>>
>> the question is - could ARC be an option for automatic memory managment
>> in D - so that the compiler generated ARC code when not using gc - but
>> using gc-needed code?
>>
>> or is that a hard to reach goal due to gc-using+arc-using lib combine
>> problems?
>>
>
> It sounds pretty easy to reach to me. Compiler generating inc/dec ref calls
> can't possibly be difficult. An optimisation that simplifies redundant
> inc/dec sequences doesn't sound hard either... :/
> Is there more to it? Cleaning up circular references I guess... what does
> Apple do?
> It's an uncommon edge case, so there's gotta be heaps of room for efficient
> solutions to that (afaik) one edge case. Are there others?

Apple's compiler does flow analysis.

First all inc/dec operations are generated as usual.

Then flow analysis is applied and all redundant inc/dec are removed before the native code generation takes place.

There is a WWDC session where this was explained.

--
Paulo

Am 09.10.2013 07:15, schrieb Manu:
>
> I've had a lot of conversations with a lot of experts, plenty of
> conversations at dconf, and nobody could even offer me a vision for a GC
> that is acceptable.
> As far as I can tell, nobody I talked to really thinks a GC that doesn't
> stop the world, which can be carefully scheduled/time-sliced (ie, an
> incremental, thread-local GC, or whatever), is even possible.
>

I have to fully agree here. I recently bought and read the book "The handbook of garbage collection". And the base requirement they make for basically every garbage collector that is a little bit more advancted then a impercise mark & sweep is that you know the _exact_ location of _all_ your pointers. And thats where D's problems come from. Its quite easy to know all pointers on the heap but the real problem are the pointers on the stack. If we really want a state of the art GC we need fully working pointer discovery first.

Regarding the GC D's biggest problem is, that it was designed to require a GC but it was not designed to actually support a GC.

And thats why I don't believe that there will ever be a GC good enough in D to fullfill realtime or soft-realtime requirements.

Kind Regards
Benjamin Thaut

On 10/9/13 12:01 AM, Mehrdad wrote:
> On Wednesday, 9 October 2013 at 03:39:38 UTC, Andrei Alexandrescu wrote:
>> On 10/8/13 4:45 PM, Jonathan M Davis wrote:
>>> On Wednesday, October 09, 2013 01:04:39 Tourist wrote:
>>>> I thought about an alternative approach:
>>>> Instead of using a (yet another) annotation, how about
>>>> introducing a flag similar to -cov, which would output lines in
>>>> which the GC is used.
>>>> This information can be used by an IDE to highlight those lines.
>>>> Then you could quickly navigate through your performance-critical
>>>> loop and make sure it's clean of GC.
>>>
>>> That sounds like a much less invasive approach no a @nogc attribute.
>>
>> Problem is with functions that have no source available.
>>
>> Andrei
>
>
> Mangle the @nogc it into the name?

That would work. Then anything that doesn't have @nogc counts as an allocation, and the corresponding line will be labeled as such. (I suspect that would cause a bunch of false positives in systems that don't add @nogc systematically.)


Andrei

Am 09.10.2013 09:51, schrieb Andrei Alexandrescu:
> On 10/9/13 12:01 AM, Mehrdad wrote:
>> On Wednesday, 9 October 2013 at 03:39:38 UTC, Andrei Alexandrescu wrote:
>>> On 10/8/13 4:45 PM, Jonathan M Davis wrote:
>>>> On Wednesday, October 09, 2013 01:04:39 Tourist wrote:
>>>>> I thought about an alternative approach:
>>>>> Instead of using a (yet another) annotation, how about
>>>>> introducing a flag similar to -cov, which would output lines in
>>>>> which the GC is used.
>>>>> This information can be used by an IDE to highlight those lines.
>>>>> Then you could quickly navigate through your performance-critical
>>>>> loop and make sure it's clean of GC.
>>>>
>>>> That sounds like a much less invasive approach no a @nogc attribute.
>>>
>>> Problem is with functions that have no source available.
>>>
>>> Andrei
>>
>>
>> Mangle the @nogc it into the name?
>
> That would work. Then anything that doesn't have @nogc counts as an
> allocation, and the corresponding line will be labeled as such. (I
> suspect that would cause a bunch of false positives in systems that
> don't add @nogc systematically.)
>
>
> Andrei
>

but maybe combined with adam ruppes idea in thread

http://forum.dlang.org/post/l322df$1n8o$1@digitalmars.com

will reduce the false postive amount faster

On 10/9/13 12:58 AM, dennis luehring wrote:
> Am 09.10.2013 09:51, schrieb Andrei Alexandrescu:
>> On 10/9/13 12:01 AM, Mehrdad wrote:
>>> On Wednesday, 9 October 2013 at 03:39:38 UTC, Andrei Alexandrescu wrote:
>>>> On 10/8/13 4:45 PM, Jonathan M Davis wrote:
>>>>> On Wednesday, October 09, 2013 01:04:39 Tourist wrote:
>>>>>> I thought about an alternative approach:
>>>>>> Instead of using a (yet another) annotation, how about
>>>>>> introducing a flag similar to -cov, which would output lines in
>>>>>> which the GC is used.
>>>>>> This information can be used by an IDE to highlight those lines.
>>>>>> Then you could quickly navigate through your performance-critical
>>>>>> loop and make sure it's clean of GC.
>>>>>
>>>>> That sounds like a much less invasive approach no a @nogc attribute.
>>>>
>>>> Problem is with functions that have no source available.
>>>>
>>>> Andrei
>>>
>>>
>>> Mangle the @nogc it into the name?
>>
>> That would work. Then anything that doesn't have @nogc counts as an
>> allocation, and the corresponding line will be labeled as such. (I
>> suspect that would cause a bunch of false positives in systems that
>> don't add @nogc systematically.)
>>
>>
>> Andrei
>>
>
> but maybe combined with adam ruppes idea in thread
>
> http://forum.dlang.org/post/l322df$1n8o$1@digitalmars.com
>
> will reduce the false postive amount faster

I'm hesitant about stuff that computes function summaries such as __traits(getFunctionsCalled, function) without allowing those summaries to make it into the function's signature or attributes. It makes separate compilation difficult.


Andrei

Am 09.10.2013 10:05, schrieb Andrei Alexandrescu:
> On 10/9/13 12:58 AM, dennis luehring wrote:
>> Am 09.10.2013 09:51, schrieb Andrei Alexandrescu:
>>> On 10/9/13 12:01 AM, Mehrdad wrote:
>>>> On Wednesday, 9 October 2013 at 03:39:38 UTC, Andrei Alexandrescu wrote:
>>>>> On 10/8/13 4:45 PM, Jonathan M Davis wrote:
>>>>>> On Wednesday, October 09, 2013 01:04:39 Tourist wrote:
>>>>>>> I thought about an alternative approach:
>>>>>>> Instead of using a (yet another) annotation, how about
>>>>>>> introducing a flag similar to -cov, which would output lines in
>>>>>>> which the GC is used.
>>>>>>> This information can be used by an IDE to highlight those lines.
>>>>>>> Then you could quickly navigate through your performance-critical
>>>>>>> loop and make sure it's clean of GC.
>>>>>>
>>>>>> That sounds like a much less invasive approach no a @nogc attribute.
>>>>>
>>>>> Problem is with functions that have no source available.
>>>>>
>>>>> Andrei
>>>>
>>>>
>>>> Mangle the @nogc it into the name?
>>>
>>> That would work. Then anything that doesn't have @nogc counts as an
>>> allocation, and the corresponding line will be labeled as such. (I
>>> suspect that would cause a bunch of false positives in systems that
>>> don't add @nogc systematically.)
>>>
>>>
>>> Andrei
>>>
>>
>> but maybe combined with adam ruppes idea in thread
>>
>> http://forum.dlang.org/post/l322df$1n8o$1@digitalmars.com
>>
>> will reduce the false postive amount faster
>
> I'm hesitant about stuff that computes function summaries such as
> __traits(getFunctionsCalled, function) without allowing those summaries
> to make it into the function's signature or attributes. It makes
> separate compilation difficult.

what speaks against doing it so (after thinking about it a long long time...) i think D needs a proper way of express the function "features" compatible with seperated compilation, and there is nothing else as the signature - as long as D don't get its own internal object format, and still want to be C link compatible

On Wednesday, 9 October 2013 at 02:22:35 UTC, Andrei Alexandrescu wrote:
> * Get Robert Schadek's precise GC in. Walter and I have become 101% convinced a precise GC is the one way to go about GC.

An orthogonal question, but is Lucarella's CDGC (still) being ported? There's nothing mutually exclusive between a precise and a concurrent gc, no?

On 10/9/2013 1:59 AM, JR wrote:
> On Wednesday, 9 October 2013 at 02:22:35 UTC, Andrei Alexandrescu wrote:
>> * Get Robert Schadek's precise GC in. Walter and I have become 101% convinced
>> a precise GC is the one way to go about GC.
>
> An orthogonal question, but is Lucarella's CDGC (still) being ported? There's
> nothing mutually exclusive between a precise and a concurrent gc, no?

I thought that got stuck on the problem that the linux system libraries had some sort of threading problem with them.