On 2012-02-22 20:40, H. S. Teoh wrote:
On Wed, Feb 22, 2012 at 07:56:15PM +0100, Benjamin Thaut wrote:
As I'm not satisfied with the current GC D has and don't see the
situation improving in the future without significant changes to the
compiler I wrote the following document that points out all the
possible issues with garbage collection I could think of and
possible solutions for them. This document is just a draft and only
a proposal, critics and comments are welcome.
Have you seen this?
http://www.llucax.com.ar/proj/dgc/index.html
[...]
2) Tracking references on the stack:
The D compiler always needs to emit a full stack frame so that the
GC can walk up the stack at any time in the program. The stack frame
of every function generated by the D compiler starts which a
bitfield (usually the size of a machine register) where each bit
indicates that these bytes are a pointer / reference. The bitfield
needs to be large enough to cover the whole stack frame of the
function.
This adds a lot of overhead to the runtime stack, esp. if you have deep
recursion. It's also not necessarily faster, since the GC now has to
parse a bitfield (a variable-length encoded bitfield, no less), instead
of just scanning words directly, which can be optimized by CPU-specific
microcode depending on the target platform.
[...]
Every scope generated by the D compiler would need additional code
at the start and end of the scope. When the scope is entered the
bitfield would be patched to represent the new variables inside the
scope and when the scope is left the bitfield is patched again to
remove the changes that were made on entering the scope.
This would introduce quite a lot of overhead per scope. It will also
lead to strange things like:
if (x) y(); // faster
if (x) { y(); } // slower
which will encourage people to omit {} after if, which makes code more
fragile and hard to read.
Doesn't the "faster" example introduces an implicit scope?
--
/Jacob Carlborg
