Idea #1 on integrating RC with GC

[Paulo Pinto]

Am 08.02.2014 11:21, schrieb ixid:
> On Wednesday, 5 February 2014 at 16:50:40 UTC, Ola Fosheim Grøstad wrote:
>> On Wednesday, 5 February 2014 at 16:04:06 UTC, Dicebot wrote:
>>> It is up to programmer to decide. Right now he does not have a choice
>>> and sometimes you can't afford to have GC in your program at all (as
>>> in can't have it linked to the binary), not just can't call
>>> collection cycles. Having sane fallback is very desired.
>>
>> Yes, if D is going to be a system level programming language then
>> there is no other option than.
>>
>>> Proposed solution does not seem to save you from uncontrollably long
>>> collection cycles anyway as it still uses same memory pool so I don't
>>> see how it can help even games, not even speaking about more
>>> demanding applications.
>>
>> Well, for games and game servers I think a 100ms delay once or twice
>> per hour is inconsequential in terms of impact.
>>
>> If you can reduce the GC load by various means it might work out for
>> most applications.
>>
>> 1. Reduce the set considered for GC by having the GC not scanning
>> paths that are known to be covered by RC.
>>
>> 2. Improving speed of GC by avoiding interior pointers etc.
>>
>> 3. Reducing the number of calls to GC by having RC take care of the
>> majority of the memory releases.
>>
>> 4. Have local GC by collecting roots of nodes that are known to create
>> cycles.
>>
>> I don't think ARC is an option for OS-level development  and critical
>> applications anyway. :-)
>>
>>>> Different scenarios have different needs.
>>>
>>> Haven't you just basically confirmed my opinion? :)
>>
>> In a way. :-) But what if the question is this:
>>
>> How can you in a pragmatic way come up with a solution that cover most
>> soft real time applications?
>>
>> A compiler switch that default to RC (i.e. turn standard GC features
>> into standard RC features) could in theory get you pretty close, but I
>> think clever RC/GC memory management requires whole program analysis…
>
> For a competitive game 100ms delays during gameplay would be completely
> unacceptable.

In the stock exchange there are Java and .NET systems doing transactions 
at faster speed than that.

100ms is too much money to be lost if the transaction course changes.

--
Paulo