Smart pointers instead of GC?

[Shammah Chancellor]

On 2014-02-01 07:35:44 +0000, Manu said:

> On 1 February 2014 16:26, Adam Wilson <flyboynw at gmail.com> wrote:
> On Fri, 31 Jan 2014 21:29:04 -0800, Manu <turkeyman at gmail.com> wrote:
> 
> On 26 December 2012 00:48, Sven Over <dlang at svenover.de> wrote:
> 
>  std.typecons.RefCounted!T
> 
> core.memory.GC.disable();
> 
> 
> Wow. That was easy.
> 
> I see, D's claim of being a multi-paradigm language is not false.
> 
> 
> It's not a realistic suggestion. Everything you want to link uses the GC,
> and the language its self also uses the GC. Unless you write software in
> complete isolation and forego many valuable features, it's not a solution.
> 
> 
>  Phobos does rely on the GC to some extent. Most algorithms and ranges do
> not though.
> 
> 
> Running (library) code that was written with GC in mind and turning GC off
> doesn't sound ideal.
> 
> But maybe this allows me to familiarise myself more with D. Who knows,
> maybe I can learn to stop worrying and love garbage collection.
> 
> Thanks for your help!
> 
> 
> I've been trying to learn to love the GC for as long as I've been around
> here. I really wanted to break that mental barrier, but it hasn't happened.
> In fact, I am more than ever convinced that the GC won't do. My current #1
> wishlist item for D is the ability to use a reference counted collector in
> place of the built-in GC.
> You're not alone :)
> 
> I write realtime and memory-constrained software (console games), and for
> me, I think the biggest issue that can never be solved is the
> non-deterministic nature of the collect cycles, and the unknowable memory
> footprint of the application. You can't make any guarantees or predictions
> about the GC, which is fundamentally incompatible with realtime software.
> Language-level ARC would probably do quite nicely for the miscellaneous
> allocations. Obviously, bulk allocations are still usually best handled in
> a context sensitive manner; ie, regions/pools/freelists/whatever, but the
> convenience of the GC paradigm does offer some interesting and massively
> time-saving features to D.
> Everyone will always refer you to RefCounted, which mangles your types and
> pollutes your code, but aside from that, for ARC to be useful, it needs to
> be supported at the language-level, such that the language/optimiser is
> able to optimise out redundant incref/decref calls, and also that it is
> compatible with immutable (you can't manage a refcount if the object is
> immutable).
> 
> The problem isn't GC's per se. But D's horribly naive implementation, 
> games are written on GC languages now all the time (Unity/.NET). And 
> let's be honest, games are kind of a speciality, games do things most 
> programs will never do.
> 
> You might want to read the GC Handbook. GC's aren't bad, but most, like 
> the D GC, are just to simplistic for common usage today.
> 
> Maybe a sufficiently advanced GC could address the performance 
> non-determinism to an acceptable level, but you're still left with the 
> memory non-determinism, and the conundrum that when your heap 
> approaches full (which is _always_ on a games console), the GC has to 
> work harder and harder, and more often to try and keep the tiny little 
> bit of overhead available.
> A GC heap by nature expects you to have lots of memory, and also lots 
> of FREE memory.
> 
> No serious console game I'm aware of has ever been written in a 
> language with a GC. Casual games, or games that don't attempt to raise 
> the bar may get away with it, but that's not the industry I work in.

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.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140203/b36aadb5/attachment.html>