February 19, 2013
On Monday, 18 February 2013 at 17:49:28 UTC, JoeCoder wrote:
> On 2/18/2013 5:35 AM, Benjamin Thaut wrote:
>> I wen't down this path already and I ended up not using the GC at all:
>>
>> http://3d.benjamin-thaut.de/?p=20
>
> I very much enjoyed this article.  Hopefully your changes can be applied upstream.
>
> A couple of my own ideas, in hopes that those with more knowledge can comment:
>
> 1.  A @nogc attribute.  This would work similarly to pure/safe/nothrow and would check at compile time that annotated functions or any they call allocate any memory enforced by the GC.  Then phobos would no longer be a "landmine" for those with realtime requirements.
>
> 2.  GC.collect(timeout).  This would run a collection only until timeout is reached.  It could be called with timeout=remaining frame time, and would allow expensive collections to span multiple frames.

Maybe a DIP should be written up to get this idea on the radar. Some means to safely disable the GC without fear of using features that perform hidden allocations is a real necessity. Even with a better GC, there will still be a requirement to disable it for some applications.

--rt
February 19, 2013
On Tuesday, 19 February 2013 at 07:36:43 UTC, Dicebot wrote:
> This is unreasonable. D targets itself as a system programming language, among the others usage cases, and thus request to have a compiler-enforced memory usage guard is perfectly valid. What shall it do if something "fancy" is attempted in @nogc? Issue a compile-time error, profit!

I have nothing against @nogc. It seems to be a nice idea. I would like to see a way to "talk to GC" in D.

What I'm saying is things seem not to be that bad right now.
February 19, 2013
On Tuesday, 19 February 2013 at 08:11:10 UTC, Don wrote:
> CDGC is not abandoned. We've been using it in production code for a very long time, in an extremely demanding environment. Luca is presenting a talk about it at the D conference.

Is that so? What state is it in? It appears not to have been spoken of or worked on for quite a while now.
February 19, 2013
On Monday, 18 February 2013 at 18:00:58 UTC, Benjamin Thaut wrote:
> Am 18.02.2013 18:49, schrieb JoeCoder:
>>
>> 1.  A @nogc attribute.  This would work similarly to pure/safe/nothrow
>> and would check at compile time that annotated functions or any they
>> call allocate any memory enforced by the GC.  Then phobos would no
>> longer be a "landmine" for those with realtime requirements.
>>
>
> I really would love to have that too. The problem with this still would be exceptions because D throws by reference and not by value like C++. To make this work there would be the need to add a special Exception allocator and make the compiler emit delete calls in case the exception is caught and not rethrown or something similar.
>
> Kind Regards
> Benjamin Thaut

perhaps a @nogc attribute that forbade everything *except* exceptions to use the GC would be still useful. After all, exceptions probably aren't going to be used in the normal execution path of high performance code.
February 19, 2013
On Tuesday, 19 February 2013 at 10:41:38 UTC, Nicholas Smith wrote:
> On Tuesday, 19 February 2013 at 08:11:10 UTC, Don wrote:
>> CDGC is not abandoned. We've been using it in production code for a very long time, in an extremely demanding environment. Luca is presenting a talk about it at the D conference.
>
> Is that so? What state is it in? It appears not to have been spoken of or worked on for quite a while now.

It's quite strange. Seems it was included in an experimental branch back in 2010: http://www.dsource.org/projects/druntime/changeset/418
February 19, 2013
On Tuesday, 19 February 2013 at 08:11:10 UTC, Don wrote:
> CDGC is not abandoned. We've been using it in production code for a very long time, in an extremely demanding environment. Luca is presenting a talk about it at the D conference.

I wish you Sociomantic guys could be a bit more open about your use of D. It would be great for advertising and having more feedback from real-world production environments would be good for development. But I guess company policy prevents that?

David
February 19, 2013
John Colvin:

> perhaps a @nogc attribute that forbade everything *except* exceptions to use the GC would be still useful. After all, exceptions probably aren't going to be used in the normal execution path of high performance code.

There is some discussion here:
http://d.puremagic.com/issues/show_bug.cgi?id=5219

Bye,
bearophile
February 19, 2013
On Monday, 18 February 2013 at 08:33:41 UTC, Nicholas Smith wrote:
> ...

> I'm not so knowledgable in the theory behind GCs but I know that in natively compiled languages your options are much more limited.
>
> ...

It is always a question of what semantics a given language has, not how it is implemented.

--
Paulo
February 19, 2013
On Monday, 18 February 2013 at 17:58:56 UTC, Benjamin Thaut wrote:
> Yes correct. But if you would do them otherwise you wouldn't need a GC in the first place. The whole point of the GC is that you can be more productive by not caring about this stuff.
>

That a very limited view of things. GC avoid many bookeping that you would have done with manual memory management, and depending on the code, granted you can tolerate some floating garbage, it can even be faster.

Coupled with immutability, GC allow to get rid of ownership. It allow to avoid many copies and allocation you'd have done with other memory management systems.

GC is surely not the magic tool that solve all problems, but it does way more that what you claim. It does open new doors.
February 19, 2013
@nogc sounds nice, but how could someone use classes(OOP) with this?