Smart pointers instead of GC?

[Adam Wilson]

On Mon, 03 Feb 2014 15:26:22 -0800, Frustrated <c1514843 at drdrb.com> wrote:

> On Monday, 3 February 2014 at 21:42:59 UTC, Shammah Chancellor
> wrote:
>>
>> You can always force the GC to run between cycles in your game, and
>> turn off automatic sweeps.  This is how most games operate nowadays.
>> It's also probably possible to create a drop-in replacement for the GC
>> to do something else.   I could see if being *VERY* useful to make the
>> GC take a compile-time parameter to select which GC engine is used.
>
>
> This is just non-sense. Maybe this is why modern games suck then?
> How do you guarantee that the GC won't kick in at the most
> inopportune times? Oh, you manually trigger it? When? Right at
> the moment when the player is about to down the boss after a 45
> min fight?
>
> Oh, right.. you just segfault cause there is no memory left.
>
> On Monday, 3 February 2014 at 22:51:50 UTC, Frank Bauer wrote:
>
>> I'm not quite sure that I understand what you mean by GC avoidance  
>> being a major focus of 2014 though. In the long term, can I look  
>> forward to writing an absolutely, like in 100 %, like in guaranteed, GC  
>> free D app with all of current D's and Phobos' features if I choose to?  
>> Or does it mean: well for the most part it will avoid the GC, but if  
>> you're unlucky the GC might still kick in if you don't pay attention  
>> and when you least expect it?
>
> It's either got to be 100% or nothing. The only issue of the GC
> is the non-determinism.... or if you do corner it and trigger it
> manually you end up with exactly the types of problems Mr.
> Chancellor thinks doesn't exist... i.e., the longer you have to
> put off the GC the worse it becomes(the more time it takes to run
> or the less memory you have to work with).
>

Why is this myth of non-determinism still alive? The only truly  
non-deterministic GC's are concurrent collectors, but alas concurrent  
collects don't routinely stop-the-world either, so there really aren't any  
pauses to complain about. D's Mark-Sweep GC is *perfectly* deterministic.  
It can  *only* pause on allocation. Ergo you can determine exactly which  
allocation caused the problem. You might not expect the function you  
called to GC-allocate, but that doesn't make it non-deterministic, just  
not what you expected. Please, stop blaming your missed expectations on  
the GC. This non-determinism thing is a red herring that is repeated over  
and over by people who obviously have no idea what they are talking about.

> It might work ok with some concurrent AGC that you can use for
> non-critical parts. e.g., have phobo's use the GC for non-real
> time sections of the app(boot up, menu's for games, etc...) then
> disable it and use ARC for when the app is meant for optimal
> and/or deterministic performance.
>
> One could argue that if one goes this around why not use ARC or
> manual memory mangement(MMM?) the whole time... but by using the
> GC during the non-critical parts of the program one can focus
> less on memory leaks as usual with the GC.
>
> What would be nice is to be able to write code that is oblivious
> to how it's memory is managed, but be able to switch between
> different methods.
>
> [Sartup->menu's and other non-performance section of the game] <-
> use GC
> [real-time areas of game] <- use ARC or manual
>


-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator