iPhone vs Android

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 13 September 2016 at 18:04:19 UTC, Jonathan M Davis 
wrote:
> On Tuesday, September 13, 2016 17:48:38 Laeeth Isharc via 
> Digitalmars-d wrote:
>> On Tuesday, 13 September 2016 at 11:59:46 UTC, Shachar Shemesh
>>
>> wrote:
>> > On 13/09/16 02:21, deadalnix wrote:
>> >> I stay convinced that an hybrid approach is inevitable and 
>> >> am
>> >> surprised
>> >> why few are going there (hello PHP, here right).
>> >
>> > Here's my worries about the hybrid approach. The GC run time 
>> > is proportional not to the amount of memory you manage with 
>> > the GC, but to the amount of memory that might hold a 
>> > pointer to a GC managed memory. In other words, if most of 
>> > my memory is RC managed, but some of it is GC, I pay the 
>> > price of both memory manager on most of my memory.
>> >
>> > Shachar
>>
>> Hi Shachar.
>>
>> I hope you're well.
>>
>> Would you mind elaborating a bit on why the cost of GC managed 
>> memory is as high as you imply when combined with other 
>> approaches, at least on a 64 bit machine and presuming you 
>> have a degree of hygiene and don't directly use a pointer 
>> allowed to point to either.   Eg if you use GC for long lived 
>> allocations and RC for short lived ones (and the RC 
>> constructor makes sure the thing is not registered with the GC 
>> so that takes care of short lived parts of long lived 
>> structures),  how in practice would this be a problem  ? I am 
>> no GC expert,  but keen to update my mental model.
>
> As I understand it, the problem is that the length of time that 
> the GC scan takes - and therefore that the world is stopped - 
> depends on how much memory it has to scan, not on how much 
> memory has been allocated by the GC. In many cases, that's just 
> the GC heap plus the stack, but if you're malloc-ing memory, 
> and that memory can hold references to GC-allocated memory, 
> then you have to tell the GC to scan that memory too in order 
> to avoid having anything it references being prematurely 
> collected. So, ultimately, how expensive the GC is in terms of 
> performance generally depends on how much memory can hold 
> referencs to GC-allocated objects and not how many such objects 
> there are, meaning that avoiding allocating with the GC in a 
> lot of your code doesn't necessarily save you from the 
> performance cost of the GC. To avoid that cost, you'd need to 
> either not have many places in malloc-ed memory which could 
> refer to GC-allocated memory, or you'd need to write your code 
> in a way that the it was guaranteed that the GC-allocated 
> objects that were referenced in malloc-ed memory would have 
> other references in memory that was scanned that lived longer 
> htan the malloc-ed memory so that the malloc-ed memory wouldn't 
> need to be scanned (which is quite possible in some 
> circumstances but potentially risky).
>
> Using a 64-bit system significantly reduces the risk of false
> pointers, but it doesn't reduce the amount of memory that 
> actually needs to be scanned. And whether using the GC for 
> long-lived allocations and RC for short-lived ones would help 
> would depend primarily on  how many such objects would be 
> around at any one time - and of course, whether they refer to 
> GC-allocated memory and would thus need to be scanned. But 
> reducing the amount of memory that the GC needs to scan and 
> reduce how much is GC-allocated are two separate - albeit 
> related - problems.
>
> - Jonathan M Davis

Thanks you for the clear explanation.   So if you don't have GC 
allocations within RC structures and pick one or the other,  then 
the concern does not apply?