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

[via Digitalmars-d]

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