D on next-gen consoles and for game development

[Rainer Schuetze]

On 30.05.2013 13:16, Manu wrote:
> On 30 May 2013 19:50, Rainer Schuetze <r.sagitario at gmx.de
> <mailto:r.sagitario at gmx.de>> wrote:
>
>
>
>     On 29.05.2013 10:06, Manu wrote:
>
>
>         What do you think is easier, or perhaps even POSSIBLE in D?
>         A good RC approach, or a V8 quality concurrent+incremental GC?
>
>
>     I think none of them is feasible without write-barriers on pointer
>     modifications in heap memory. That means extra code needs to be
>     generated for each pointer modification (if the compiler cannot
>     optimize it away as LLVM seems to be doing in case of Objectve-C).
>     As an alternative, Leandros concurrent GC implements them with
>     hardware support by COW, though at a pretty large granularity (page
>     size). I'm not sure if this approach can be sensibly combined with
>     RC or incremental collection.
>
>
> I'm talking about embedded hardware. No virtualisation, tight memory
> limit, no significant OS. Is it possible?
>
>         I get the feeling either would be acceptable, but I still kinda like
>         idea of the determinism an RC collector offers.
>
>
>     If you want it to be safe and efficient, it needs to use deferred
>     reference counting, and this ain't so deterministic anymore. The
>     good thing about it is that you usually don't have to scan the whole
>     heap to find candidates for reclamation.
>
>
> Well, it's a bit more deterministic, at least you could depend on the
> deferred free happening within a frame let's say, rather than at some
> un-knowable future time when the GC feels like performing a collect...
>
> That said, I'd be interested to try it without a deferred free.
> Performance impact depends on the amount of temporaries/frees... I don't
> imagine it would impact much/at-all since there is so little memory
> allocation or pointer assignments in realtime software.
> People use horrific C++ smart pointer templates successfully, without
> any compiler support at all. It works because the frequency of pointer
> assignments is so low.
> RC is key to avoid scanning the whole heap, which completely destroys
> your dcache.
>
>         I reckon this should probably be the next big ticket for D. The
>         long-standing shared library problems seem to be being addressed.
>
>
>     The GC proposed by Leandro looks very promising, though it needs
>     support by the hardware and the OS. I think we should see how far we
>     can get with this approach.
>
>
> His GC looked good, clearly works better for the sociomantic guys, but I
> can't imagine it, or anything like it, will ever work on embedded platforms?
> No hardware/OS support... is it possible to emulate the requires features?

I suspected embedded systems would not have enough support for COW. I 
think the only way to emulate it would be with write barriers, and then 
you can do better than emulating page protection.

The way Michel Fortin proposed to implement it (lowering pointer writes 
to some druntime-defined template) is also how imagine it. A template 
argument that specifies whether the compiler knows that it is a stack 
access would be nice aswell.
One possible complication: memory block operations would have to treat 
pointer fields differently somehow.