Am 25.05.2013 07:52, schrieb Manu:
On 25 May 2013 15:29, deadalnix <deadal...@gmail.com
<mailto:deadal...@gmail.com>> wrote:

    On Saturday, 25 May 2013 at 05:18:12 UTC, Manu wrote:

        On 25 May 2013 15:00, deadalnix <deadal...@gmail.com
        <mailto:deadal...@gmail.com>> wrote:

            On Saturday, 25 May 2013 at 01:56:42 UTC, Manu wrote:

                Understand, I have no virtual-memory manager, it won't
                page, it's not a
                performance problem, it will just crash if I
                mis-calculate this value.


            So the GC is kind of out.


        Yeah, I'm wondering if that's just a basic truth for embedded.
        Can D implement a ref-counting GC? That would probably still be
        okay, since
        collection is immediate.


    This is technically possible, but you said you make few allocations.
    So with the tax on pointer write or the reference counting, you'll
    pay a lot to collect very few garbages. I'm not sure the tradeoff is
    worthwhile.


But it would be deterministic, and if the allocations are few, the cost
should be negligible.


    Paradoxically, when you create few garbage, GC are really goos as
    they don't need to trigger often. But if you need to add a tax on
    each reference write/copy, you'll probably pay more tax than you get
    out of it.


They're still non-deterministic though. And unless (even if?) they're
precise, they might leak.

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?

Yes, but is was mainly for not being able to have a stable working GC able to cope with the Objective-C code available in the wild. It had quite a few issues.

Objective-C reference counting requires compiler and runtime support.

Basically it is based in how Cocoa does reference counting, but instead of requiring the developers to manually write the [retain], [release] and [autorelease] messages, the compiler is able to infer them based on
Cocoa memory access patterns.

Additionally it makes use of dataflow analysis to remove superfluous use of those calls.

There is a WWDC talk on iTunes where they explain that. I can look for it if there is interest.

Microsoft did the same thing with their C++/CX language extensions and COM for WinRT.

--
Paulo

Reply via email to