radical ideas about GC and ARC : need to be time driven?

[Kagamin via Digitalmars-d]

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.

> - 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.