3 ms·

Why is good GC basically incompatible with compiling to C? Because there's no portable way to scan the stack for live objects?

pcwalton 11y ago
That, and the fact that you can't tell the compiler that it needs to be aware of pointers that can move across function calls. In fact, there isn't any dialect of C, standard or not, that I'm aware of that allows you to do this in a fashion that works with precise, moving GC. (Mostly-copying doesn't count.) Maybe C++/CLI, but the object model you're opting into with that brings you so far from C as to barely be considered "compiling to C".
- saurik 11y ago
  Add a hidden argument to every function marked as capable of transient reference: a pointer to a pointer to a structure (just another object) which serves as a "stack frame". In that function, if you do reference stuff, build your own "stack frame" and use that to maintain a shadow stack. If you allow threads to transiently access objects between "sync points" this won't even be all that inefficient, as you will only be using it to track sub-graph roots as you make calls to other functions... for various reasons many of the more legit mechanisms have that same limitation anyway (where threads are only stopped to be scanned at moments they mark as safe). Maybe you don't consider this to be "good gc", but if your criteria is simply "precise GC with only a minor performance penalty" I don't see any reason to doubt that C is up for the challenge. (And as you are uniquely aware, one would hope that if you were buying the static compilation argument you are also likely to not stress a garbage collector much in the first place, so I would expect the shadow stack to get very little use.) Is there something I'm missing? I really would be interested in a more expansive explanation as to why building a GC with C as a compilation target (as opposed to as a library for people you are expecting to program in C) is considered such a serious showstopping issue.
  - pcwalton 11y ago
    That's precise GC with a huge performance penalty, not a minor one. The problem is not so much the spilling and reloading (though that is a large issue) as what that is going to do to the ability of the optimizer to reason about the code. (If you're curious how I'm so sure it's a huge performance penalty, I have been spending a fair amount of time of the last month working with others to debug large performance problems caused by a variant of exactly this technique used in Servo.) :)

pcwalton 11y ago

That, and the fact that you can't tell the compiler that it needs to be aware of pointers that can move across function calls. In fact, there isn't any dialect of C, standard or not, that I'm aware of that allows you to do this in a fashion that works with precise, moving GC. (Mostly-copying doesn't count.) Maybe C++/CLI, but the object model you're opting into with that brings you so far from C as to barely be considered "compiling to C".

saurik 11y ago
Add a hidden argument to every function marked as capable of transient reference: a pointer to a pointer to a structure (just another object) which serves as a "stack frame". In that function, if you do reference stuff, build your own "stack frame" and use that to maintain a shadow stack. If you allow threads to transiently access objects between "sync points" this won't even be all that inefficient, as you will only be using it to track sub-graph roots as you make calls to other functions... for various reasons many of the more legit mechanisms have that same limitation anyway (where threads are only stopped to be scanned at moments they mark as safe). Maybe you don't consider this to be "good gc", but if your criteria is simply "precise GC with only a minor performance penalty" I don't see any reason to doubt that C is up for the challenge. (And as you are uniquely aware, one would hope that if you were buying the static compilation argument you are also likely to not stress a garbage collector much in the first place, so I would expect the shadow stack to get very little use.) Is there something I'm missing? I really would be interested in a more expansive explanation as to why building a GC with C as a compilation target (as opposed to as a library for people you are expecting to program in C) is considered such a serious showstopping issue.
- pcwalton 11y ago
  That's precise GC with a huge performance penalty, not a minor one. The problem is not so much the spilling and reloading (though that is a large issue) as what that is going to do to the ability of the optimizer to reason about the code. (If you're curious how I'm so sure it's a huge performance penalty, I have been spending a fair amount of time of the last month working with others to debug large performance problems caused by a variant of exactly this technique used in Servo.) :)