D on next-gen consoles and for game development

Paulo Pinto pjmlp at progtools.org
Wed May 29 00:01:02 PDT 2013


On Wednesday, 29 May 2013 at 00:40:16 UTC, Manu wrote:
> On 29 May 2013 03:27, Paulo Pinto <pjmlp at progtools.org> wrote:
>
>> Am 28.05.2013 15:33, schrieb Steven Schveighoffer:
>>
>>> On Sat, 25 May 2013 01:52:10 -0400, Manu 
>>> <turkeyman at gmail.com> wrote:
>>>
>>>  What does ObjC do? It seems to work okay on embedded hardware
>>>> (although not
>>>> particularly memory-constrained hardware).
>>>> Didn't ObjC recently reject GC in favour of refcounting?
>>>>
>>>
>>> Having used ObjC for the last year or so working on iOS, it 
>>> is a very
>>> nice memory management model.
>>>
>>> Essentially, all objects (and only objects) are ref-counted
>>> automatically by the compiler.  In code, whenever you assign 
>>> or pass a
>>> pointer to an object, the compiler automatically inserts 
>>> retains and
>>> releases extremely conservatively.
>>>
>>> Then, the optimizer comes along and factors out extra retains 
>>> and
>>> releases, if it can prove they are necessary.
>>>
>>> What I really like about this is, unlike a library-based 
>>> solution where
>>> every assignment to a 'smart pointer' incurs a 
>>> release/retain, the
>>> compiler knows what this means and will factor them out, 
>>> removing almost
>>> all of them.  It's as if you inserted the retains and 
>>> releases in the
>>> most optimized way possible, and it's all for free.
>>>
>>> Also, I believe the compiler is then free to reorder retains 
>>> and
>>> releases since it understands how they work.  Of course, a
>>> retain/release is an atomic operation, and requires memory 
>>> barriers, so
>>> the CPU/cache cannot reorder, but the compiler still can.
>>> ...
>>>
>>
>> I imagine Microsoft also does a similar thing with their 
>> C++/CX language
>> extensions (WinRT handles).
>>
>
> Yeah certainly. It's ref counted, not garbage collected. And 
> Android's V8
> uses a 
> "generational<http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Generational_GC_.28ephemeral_GC.29>
>  
> incremental<http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Stop-the-world_vs._incremental_vs._concurrent>
> collector"...
> That'd be nice!
> 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.
>
> Implementing a ref-counted GC would probably be much simpler 
> than V8's
> mythical incremental collector that probably relies on Java 
> restrictions to
> operate?

Actually what I was implying was the cleverness of the compiler 
to remove unnecessary increment/decrement operations via 
dataflows, similar to what Clang does.

Otherwise you pay too much for performance impact specially if 
multiple threads access the same objects. An incremental real 
time GC wins hands down in such scenarios.

Google IO is always a nice source of information on how V8 works,

https://developers.google.com/events/io/sessions/324431687
https://developers.google.com/events/io/sessions/324908972

--
Paulo




More information about the Digitalmars-d mailing list