14 ms·

Inside D's GC

144 points by arunc 9y ago

Dzugaru 9y ago
D is the most promising "one to rule them all" languages for me, given it's expressive power, speed, compilation speed and support for multiple paradigms. That said, D severely lacks manpower in its development. I'd like to port author's effort to Windows, but I don't have OS-level programming experience, so I don't even know what are the differences and how they affect GC algorithms described.
papaf 9y ago
Good luck with this. I find GC programming really hard as any small mistake snowballs and becomes super hard to find during debugging. Some of the mistakes seen by the author could just be the original programmers being tired of painful debugging.
- WalterBright 9y ago
  The mistakes seen by the author aren't bugs. They're just less performant algorithmic choices. One charge not leveled at D's GC is bugginess. The GC has proven to be pretty robust.
- gwbas1c 9y ago
  What are you talking about? GC programming is usually the easiest to avoid small mistakes. Circular references? GC will collect them! (Reference counting does not handle circular references.) Usually the two mistakes with GC are forgetting to empty collections, (which is also a problem with manual memory management,) and relying on finalizers to clean up resources. GC will not "read your mind" and magically close your open sockets, release your file handles, and dereference your static references. It just frees you from the tedium of releasing transient memory, like strings; and it frees you from tracking lifetimes of memory when you don't need to. In my experience, the programmers who have trouble with GC are the ones who don't understand the difference between memory management and resource management.
  - distances 9y ago
    They meant implementing the GC itself.
pcwalton 9y ago
Immix is a copying collector. It's late and I may be misreading, but glancing at the code I don't see any precise object layout info for the heap in D's GC. That is, D seems conservative for both stack and heap. How can you make Immix work with this kind of conservative GC?
- YorickPeterse 9y ago
  One simple "solution" is to not implement evacuation, thereby not moving objects. In my opinion this somewhat defeats the purpose of using Immix, but some projects decided to take this route (e.g. Rubinius has/had an Immix GC but never implemented evacuation if I'm not mistaken).
- chrisseaton 9y ago
  Presumably adding precise stack maps and object maps would be the first step of adding IMMIX. I mean it's the compiler that chooses where to place things in the heap and the stack, so it already knows where they are.
  - readittwice 9y ago
    Since, I don't know D, I am curious whether D-code is written in such a way that objects are assumed to be non-moving, especially when interfacing with C.
    - chrisseaton 9y ago
      Ah, yes maybe FFI and also perhaps inner pointers.
    - biotronic 9y ago
      The spec says the GC may move, though the current GC doesn't do that: https://dlang.org/spec/garbage.html#obj_pinning_and_gc https://dlang.org/spec/garbage.html#obj_pinning_and_gc There's also been some work on a precise GC for D: https://forum.dlang.org/post/hdwwkzqswwtffjehenjt@forum.dlang.org https://forum.dlang.org/post/hdwwkzqswwtffjehenjt@forum.dlan...
dawg 9y ago
The D language is currently heading towards deterministic and safe memory management, making it possible to avoid the GC overall, hence further work on GC improvements was deprioritized. http://dlang.org/blog/2017/06/16/life-in-the-fast-lane/ http://dlang.org/blog/2017/06/16/life-in-the-fast-lane/ The problems are known and indeed a full rewrite on this ancient GC would be in order. Since D 2.072.0 it's possible to link and use different GCs, so a faster one could be written as an external library which would be a very welcome effort. https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-added https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-ad... I'd be interested in experimenting with a Connectivity-Based GC (https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf), leveraging type information to do partial collections. Write barriers come with a performance penalty (~3-5%) that we don't want to impose on people using deterministic memory management, but most GCs capable of performing partial collections, e.g. generational GCs, do require write barriers, Connectivity-Based GCs do not. For the time being the pragmatic advise is to replace major sources of GC allocations with deterministic memory management when the GC heap grows too big (~1GB) and performance becomes a problem. So far this hasn't prevented various people from writing extremely fast D programs.
- deleted 9y ago
  [deleted]
- amelius 9y ago
  > The D language is currently heading towards deterministic and safe memory management, making it possible to avoid the GC overall Is this really true?
  - mhh__ 9y ago
    Yes, but the D community isn't structured enough to have such a specific goal. The main effort that I can think of is dip1008, which aims to add reference counted exceptions (Thus eliminating one of the few truly difficult things to get around, e.g. @nogc exceptions require user cooperation else memory gets leaked)
  - deleted 9y ago
    [deleted]
deleted 9y ago
[deleted]
jacquesm 9y ago
If D manages to side-step the GC completely then Rust suddenly has a formidable competitor.
- gwbas1c 9y ago
  I find Rust's lack of a GC it's biggest weakness; the language has a lot of complexity to avoid using a GC. That being said, I anticipate that I'll write a lot of Rust in the future!
  - jjnoakes 9y ago
    Which complexity in Rust is due to the lack of GC, and not due to, say, the desire for thread safety?
    - jnbiche 9y ago
      > Which complexity in Rust is due to the lack of GC, and not due to, say, the desire for thread safety? The whole lifetimes business, which is done more generally for memory safety. It adds a lot of complexity. On the other hand, there's clearly a niche need for a language with no GC at the systems level, so I can appreciate the reasons for Rust's decision. But after playing around with Rust for quite a bit, I'm come to the decision that at least for me, Rust's lifetimes are too complex, and (partly as a result of no GC), the overall language is just not functional enough to be a general purpose programming language. Scala is currently filling that role for me.
      - dbaupp 9y ago
        Thread safety (specifically, freedom from data races) is memory safety. Additionally, lifetimes are also part of the system that statically avoids problems that appear in GC'd languages like iterator invalidation (for instance, ConcurrentModificationException).
        rbehrends 9y ago

144 points by arunc 9y ago

D is the most promising "one to rule them all" languages for me, given it's expressive power, speed, compilation speed and support for multiple paradigms. That said, D severely lacks manpower in its development. I'd like to port author's effort to Windows, but I don't have OS-level programming experience, so I don't even know what are the differences and how they affect GC algorithms described.

papaf 9y ago

Good luck with this. I find GC programming really hard as any small mistake snowballs and becomes super hard to find during debugging. Some of the mistakes seen by the author could just be the original programmers being tired of painful debugging.

WalterBright 9y ago
The mistakes seen by the author aren't bugs. They're just less performant algorithmic choices. One charge not leveled at D's GC is bugginess. The GC has proven to be pretty robust.
gwbas1c 9y ago
What are you talking about? GC programming is usually the easiest to avoid small mistakes. Circular references? GC will collect them! (Reference counting does not handle circular references.) Usually the two mistakes with GC are forgetting to empty collections, (which is also a problem with manual memory management,) and relying on finalizers to clean up resources. GC will not "read your mind" and magically close your open sockets, release your file handles, and dereference your static references. It just frees you from the tedium of releasing transient memory, like strings; and it frees you from tracking lifetimes of memory when you don't need to. In my experience, the programmers who have trouble with GC are the ones who don't understand the difference between memory management and resource management.
- distances 9y ago
  They meant implementing the GC itself.

pcwalton 9y ago

Immix is a copying collector. It's late and I may be misreading, but glancing at the code I don't see any precise object layout info for the heap in D's GC. That is, D seems conservative for both stack and heap. How can you make Immix work with this kind of conservative GC?

YorickPeterse 9y ago
One simple "solution" is to not implement evacuation, thereby not moving objects. In my opinion this somewhat defeats the purpose of using Immix, but some projects decided to take this route (e.g. Rubinius has/had an Immix GC but never implemented evacuation if I'm not mistaken).
chrisseaton 9y ago
Presumably adding precise stack maps and object maps would be the first step of adding IMMIX. I mean it's the compiler that chooses where to place things in the heap and the stack, so it already knows where they are.
- readittwice 9y ago
  Since, I don't know D, I am curious whether D-code is written in such a way that objects are assumed to be non-moving, especially when interfacing with C.
  - chrisseaton 9y ago
    Ah, yes maybe FFI and also perhaps inner pointers.
  - biotronic 9y ago
    The spec says the GC may move, though the current GC doesn't do that: https://dlang.org/spec/garbage.html#obj_pinning_and_gc https://dlang.org/spec/garbage.html#obj_pinning_and_gc There's also been some work on a precise GC for D: https://forum.dlang.org/post/hdwwkzqswwtffjehenjt@forum.dlang.org https://forum.dlang.org/post/hdwwkzqswwtffjehenjt@forum.dlan...

dawg 9y ago

The D language is currently heading towards deterministic and safe memory management, making it possible to avoid the GC overall, hence further work on GC improvements was deprioritized. http://dlang.org/blog/2017/06/16/life-in-the-fast-lane/ http://dlang.org/blog/2017/06/16/life-in-the-fast-lane/ The problems are known and indeed a full rewrite on this ancient GC would be in order. Since D 2.072.0 it's possible to link and use different GCs, so a faster one could be written as an external library which would be a very welcome effort. https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-added https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-ad... I'd be interested in experimenting with a Connectivity-Based GC (https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf), leveraging type information to do partial collections. Write barriers come with a performance penalty (~3-5%) that we don't want to impose on people using deterministic memory management, but most GCs capable of performing partial collections, e.g. generational GCs, do require write barriers, Connectivity-Based GCs do not. For the time being the pragmatic advise is to replace major sources of GC allocations with deterministic memory management when the GC heap grows too big (~1GB) and performance becomes a problem. So far this hasn't prevented various people from writing extremely fast D programs.

deleted 9y ago
[deleted]
amelius 9y ago
> The D language is currently heading towards deterministic and safe memory management, making it possible to avoid the GC overall Is this really true?
- mhh__ 9y ago
  Yes, but the D community isn't structured enough to have such a specific goal. The main effort that I can think of is dip1008, which aims to add reference counted exceptions (Thus eliminating one of the few truly difficult things to get around, e.g. @nogc exceptions require user cooperation else memory gets leaked)
- deleted 9y ago
  [deleted]

deleted 9y ago

[deleted]

jacquesm 9y ago

If D manages to side-step the GC completely then Rust suddenly has a formidable competitor.

gwbas1c 9y ago
I find Rust's lack of a GC it's biggest weakness; the language has a lot of complexity to avoid using a GC. That being said, I anticipate that I'll write a lot of Rust in the future!
- jjnoakes 9y ago
  Which complexity in Rust is due to the lack of GC, and not due to, say, the desire for thread safety?
  - jnbiche 9y ago
    > Which complexity in Rust is due to the lack of GC, and not due to, say, the desire for thread safety? The whole lifetimes business, which is done more generally for memory safety. It adds a lot of complexity. On the other hand, there's clearly a niche need for a language with no GC at the systems level, so I can appreciate the reasons for Rust's decision. But after playing around with Rust for quite a bit, I'm come to the decision that at least for me, Rust's lifetimes are too complex, and (partly as a result of no GC), the overall language is just not functional enough to be a general purpose programming language. Scala is currently filling that role for me.
    - dbaupp 9y ago
      Thread safety (specifically, freedom from data races) is memory safety. Additionally, lifetimes are also part of the system that statically avoids problems that appear in GC'd languages like iterator invalidation (for instance, ConcurrentModificationException).
      - rbehrends 9y ago