On Tuesday, 30 September 2014 at 21:19:44 UTC, Ethan wrote:
Hello. AAA developer (Remedy) here using D. Custom tech, with a
custom binding solution written originally by Manu and
continued by myself.
A GC itself is not a bad thing. The implementation, however, is.
With a codebase like ours (mostly C++, some D), there's a few
things we need. Deterministic garbage collection is a big one -
when our C++ object is being destroyed, we need the D object to
be destroyed at the same time in most cases. This can be
handled by calling GC.collect() often, but that's where the
next thing comes in - the time the GC needs. If the time isn't
being scheduled at object destruction, then it all gets lumped
together in the GC collect. It automatically moves the time
cost to a place where we may not want it.
Not a GC specialist here, so maybe the thought arises - why not
turn off automatic GC until such times in the code where you can
afford the cost of it, then call GC.collect explicitly -
essentially eliminating the opportunity for the GC to run at
random times and force running at deterministic times? Is memory
usage so constrained that failing to execute runs in-between
those deterministic blocks could lead to OOM? Does such a
strategy have other nasty side-effects which make it impractical?
