Idea #1 on integrating RC with GC
ixid
nuaccount at gmail.com
Sat Feb 8 02:21:26 PST 2014
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.
More information about the Digitalmars-d
mailing list