On Thursday, 15 May 2014 at 12:05:27 UTC, Kagamin wrote:
On Wednesday, 14 May 2014 at 19:45:20 UTC, Marc Schütz wrote:
- We have external code programmed in languages other than D,
most prominently C and C++. These don't provide any type
information, therefore the GC needs to handle their memory
conservatively, which means there can be false pointers => no
deterministic destruction.
It's a very rare scenario to escape GC memory into foreign
opaque data structures. Usually you don't see, where your
pointer goes, as foreign API is usually completely opaque, so
you have nothing to scan, even if you have a precise GC.
Sometimes C API will notify your code, where it releases your
data, in other cases you can store your data in a managed
memory and release it after you release the foreign data
structure.
Fair point. But can this be made safer? Currently you don't get
any warning if a GC pointer escapes into C land.
- Variables on the stack and in registers. In theory, the
compiler could generate that information, or existing debug
information might be used, but that's complicated for the GC
to handle and will probably have runtime costs. I guess it's
unlikely to happen. And of course, when we call a C function,
we're lost again.
Precise GC is needed to implement moving GC, it's not needed to
implement good memory management, at least on 64-bit
architecture. On 32-bit architecture false pointers are
possible, when you have lots of data without pointers on 32-bit
architecture. It could be treated simply by allocating data
without pointers (like strings) in not scanned blocks. The more
valid pointers you have in your data, the smaller is
probability of false pointers. The smaller is handle wrapper,
the smaller is probability of a false pointer holding it. If
you manage resources well, probability of handle leak goes even
smaller (in C# it doesn't pose any notable difficulty even
though you don't have any mechanism of eager resource
management at all, only GC, in D you have non-zero opportunity
for eager resource management). All these small probabilities
multiply, and you get even smaller probability of an eventual
resource leak.
But as long as there can be false pointers, no matter how
improbable, there can be no guaranteed destruction, which was my
point. Maybe it becomes acceptable at very low probabilities, but
it's still a gamble...
