On Wednesday, 29 May 2013 at 07:18:49 UTC, Rainer Schuetze wrote:
>
>
> On 29.05.2013 02:46, Steven Schveighoffer wrote:
>> On Tue, 28 May 2013 20:40:03 -0400, Manu <turkeyman@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
>
> 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.

There is a nice document where it is described alongside all restrictions,

https://developer.apple.com/library/mac/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226

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

>
>
> On 29.05.2013 02:46, Steven Schveighoffer wrote:
>
>> On Tue, 28 May 2013 20:40:03 -0400, Manu <turkeyman@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.

On 2013-05-29 09:05, Paulo Pinto wrote:

> The main reason was that the GC never worked properly given the C
> underpinnings of Objective-C.
>
> Too many libraries failed to work properly with GC enabled, plus you
> needed to fill your code with GC friendly annotations.
>
> So I imagine Apple tried to find a compromises that would work better in
> a language with C "safety".
>
> Even that is only supported at the Objective-C language level and it
> requires both compiler support and that objects inherit from NSObject as
> top most class, as far as I am aware.
>
> Anyway it is way better than pure manual memory management.

I'm pretty it works for their CoreFoundation framework which is a C library. NSObject, NSString and other classes are built on top of CoreFoundation.

-- 
/Jacob Carlborg

On 2013-05-29 08:06:15 +0000, Manu <turkeyman@gmail.com> said:

> 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.

Given that both require calling a function of some sort on pointer assignment, I'd say they're pretty much equivalent in implementation effort. One thing the compiler should do with RC that might require some effort is cancel out redundant increments/decrement pairs inside functions, and also offer some kind of weak pointer to deal with cycles. On the GC side, well you have to write the new GC.

Also, with RC, you have to be careful not to create cycles with closures. Those are often hard to spot absent of an explicit list of captured variables.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

On 2013-05-29 09:46:20 +0000, Jacob Carlborg <doob@me.com> said:

> On 2013-05-29 09:05, Paulo Pinto wrote:
> 
>> The main reason was that the GC never worked properly given the C
>> underpinnings of Objective-C.
>> 
>> Too many libraries failed to work properly with GC enabled, plus you
>> needed to fill your code with GC friendly annotations.
>> 
>> So I imagine Apple tried to find a compromises that would work better in
>> a language with C "safety".
>> 
>> Even that is only supported at the Objective-C language level and it
>> requires both compiler support and that objects inherit from NSObject as
>> top most class, as far as I am aware.
>> 
>> Anyway it is way better than pure manual memory management.
> 
> I'm pretty it works for their CoreFoundation framework which is a C library. NSObject, NSString and other classes are built on top of CoreFoundation.

It does for CF types which are toll-free bridged, if you mark them to be GC managed while casting.
http://developer.apple.com/library/ios/#documentation/CoreFoundation/Conceptual/CFDesignConcepts/Articles/tollFreeBridgedTypes.html

For 

instance, CFString and NSString are just different APIs for the same underlying object, so you can cast between them. But CoreFoundation itself won't use the GC if you don't involve Objective-C APIs. The interesting thing is that objects managed by the now deprecated Objective-C GC also have a reference count, and won't be candidate for garbage collection until the reference count reaches zero. You can use CFRetain/CFRelease on GC-managed Objective-C objects if you want, it's not a noop.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

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 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.

>
> 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.

On 30 May 2013 19:50, Rainer Schuetze <r.sagitario@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?

On Thursday, 30 May 2013 at 11:17:08 UTC, Manu wrote:
> 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?

Well, anything that is done by OS can also be done by program itself ;) I am more curious - is it possible to have a sane design for both cases within one code base?

On 30 May 2013 21:20, Dicebot <m.strashun@gmail.com> wrote:

> On Thursday, 30 May 2013 at 11:17:08 UTC, Manu wrote:
>
>> 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?
>>
>
> Well, anything that is done by OS can also be done by program itself ;) I am more curious - is it possible to have a sane design for both cases within one code base?
>

Which 'both' cases?

On Thursday, 30 May 2013 at 11:31:53 UTC, Manu wrote:
> Which 'both' cases?

"OS support for fork+CoW" vs "no support, own implementation"