An article I just read. It even mentions D:

http://sebastiansylvan.wordpress.com/2012/12/01/garbage-collection-thoughts/

I my opinion he especially has a point with the "each object consists mostly out of pointers" argument.

Kind Regards
Benjamin Thaut

Benjamin Thaut:

> http://sebastiansylvan.wordpress.com/2012/12/01/garbage-collection-thoughts/

It seems a nice blog post. I don't remember what D does regarding per-thread heaps.

Maybe Phobos emplace() is not enough and a bigger/better gun is needed to safely allocate in-place a higher percentage of class instances.

Bye,
bearophile

On Wed, 19 Dec 2012 16:58:59 -0600, bearophile <bearophileHUGS@lycos.com> wrote:

> Benjamin Thaut:
>
>> http://sebastiansylvan.wordpress.com/2012/12/01/garbage-collection-thoughts/
>
> It seems a nice blog post. I don't remember what D does regarding per-thread heaps.

It's been proposed and (sadly) rejected.

> Maybe Phobos emplace() is not enough and a bigger/better gun is needed to safely allocate in-place a higher percentage of class instances.

It would be fairly easy to build a library function(i.e. Scope!T or InPlace!T) that uses emplace to store a class inside of a wrapper struct.

> It would be fairly easy to build a library function(i.e. Scope!T or InPlace!T) that uses emplace to store a class inside of a wrapper struct.

There already is such function, std.typecons.scoped.

jerro:

> There already is such function, std.typecons.scoped.

In your D code what's the percentage of class instantiations done with scoped()?

Bye,
bearophile

> In your D code what's the percentage of class instantiations done with scoped()?
>
> Bye,
> bearophile

I don't think I've ever actually used it (other than just trying it). When I use classes, I usually want them to be heap allocated. But if you need a class instance on the stack, scoped() looks useful. Are there some issues with it that I'm not aware of?

On Thursday, 20 December 2012 at 00:56:30 UTC, jerro wrote:
>> In your D code what's the percentage of class instantiations done with scoped()?
>>
>> Bye,
>> bearophile
>
> I don't think I've ever actually used it (other than just trying it). When I use classes, I usually want them to be heap allocated. But if you need a class instance on the stack, scoped() looks useful. Are there some issues with it that I'm not aware of?

It is unsafe :D But otherwise works properly.

LDC also plan to provide a pass that remove many allocation when it can prove that thing don't escape scope. I don't know if that went into the lastest version, last time I heard of it it was experimental.

On Thursday, 20 December 2012 at 01:15:51 UTC, deadalnix wrote:
> LDC also plan to provide a pass that remove many allocation when it can prove that thing don't escape scope.

Unfortunately, »many« is not quite true, as escape analysis is hard (and we e.g. currently don't lower D 'scope' on parameters to LLVM's equivalent) – »some« would be better.

> I don't know if that went into the lastest version, last time I heard of it it was experimental.

It's quite an old pass, but has been disabled for a long time. I recently resurrected it, but unfortunately it triggers an unrelated miscompilation, so I couldn't merge it into Git master (and the release) yet: https://github.com/ldc-developers/ldc/pull/206

David

jerro:

>> I don't think I've ever actually used it (other than just trying it). When I use classes, I usually want them to be heap allocated.

I think to make a difference for the GC (and to improve locality for the cache, and reduce the fan out discussed in the blog post), a good percentage (50%? 70%?) of the class instances need to be allocated in-place.

I say "in-place", because a fixed-sized array is allocated in place inside a class instance, even if the instance is allocated on the heap.

------------------------

deadalnix:

> It is unsafe :D But otherwise works properly.

In this thread there are some notes:
http://d.puremagic.com/issues/show_bug.cgi?id=5115

Maybe some language support is needed to improve the situation. And this stuff can't want D3. Taking a good look at the design of Rust language is an option.


> LDC also plan to provide a pass that remove many allocation when it can prove that thing don't escape scope. I don't know if that went into the lastest version, last time I heard of it it was experimental.

Escape analysis helps, but it's not a good enough solution. This is said in that blog post too.

Bye,
bearophile

On Wednesday, 19 December 2012 at 20:47:39 UTC, Benjamin Thaut wrote:
> An article I just read. It even mentions D:
>
> http://sebastiansylvan.wordpress.com/2012/12/01/garbage-collection-thoughts/
>
> I my opinion he especially has a point with the "each object consists mostly out of pointers" argument.
>

He neglect to consider immutability (or maybe wasn't aware of) and how, combined with GC it allow some idioms that are very fast. Very good article overall.

D's GC should really be aware of TL and immutability of what it does allocate.