D on next-gen consoles and for game development

[Manu]

On 29 May 2013 17:18, Rainer Schuetze <r.sagitario at gmx.de> wrote:

>
>
> On 29.05.2013 02:46, Steven Schveighoffer wrote:
>
>> On Tue, 28 May 2013 20:40:03 -0400, Manu <turkeyman at gmail.com> wrote:
>>
>>
>>  ObjC and WinRT are both used successfully on embedded hardware, I'm
>>> really
>>> wondering if this is the way to go for embedded in D.
>>> V8 uses an incremental collector (somehow?), which I've been saying is
>>> basically mandatory for embedded/realtime use. Apparently Google agree.
>>> Clearly others have already had this quarrel, their resolutions are worth
>>> consideration.
>>>
>>
>> An interesting thing to note, Apple tried garbage collection with Obj-C,
>> but only on MacOS, and it's now been deprecated since automatic
>> reference counting was introduced [1].  It never was on iOS.
>>
>> So that is a telling omission I think.
>>
>> -Steve
>>
>> [1] https://en.wikipedia.org/wiki/**Objective-C#Garbage_collection<https://en.wikipedia.org/wiki/Objective-C#Garbage_collection>
>>
>
> Please note that you have to deal with circular references manually in
> Objective-C, introducing two types of pointers, strong and weak. I don't
> think this is optimal. If you want to deal with circular references
> automatically you again need some other kind of other garbage collection
> running.
>
> A problem with the naive approach of atomic reference counting a counter
> inside the object (as usually done in COM interfaces, I don't know how it
> is done in Objective-C) is that it is not thread-safe to modify a pointer
> without locking (or a CAS2 operation that you don't have on popular
> processors). You can avoid that using deferred reference counting (logging
> pointer changes to some thread local buffer), but that introduces back a
> garbage collection step with possibly massive destruction. This step might
> be done concurrently, but that adds another layer of complexity to finding
> circles.
>
> Another issue might be that incrementing a reference of an object when
> taking an interior pointer (like you do when using slices) can be pretty
> expensive because you usually have to find the base of the object to access
> the counter.
>
> I won't dismiss RC garbage collection as impossible, but doing it
> efficiently and concurrently is not so easy.
>

What do you think is easier, or perhaps even POSSIBLE in D?
A good RC approach, or a V8 quality concurrent+incremental GC?
I get the feeling either would be acceptable, but I still kinda like idea
of the determinism an RC collector offers.

I reckon this should probably be the next big ticket for D. The
long-standing shared library problems seem to be being addressed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130529/803bd62e/attachment-0001.html>