On Thursday, 15 May 2014 at 12:44:56 UTC, Marc Schütz wrote:
> On Wednesday, 14 May 2014 at 20:02:08 UTC, Ola Fosheim Grøstad wrote:
>> However, you could have rules for collection and FFI (calling C). Like only allowing collection if all C parameters that point to GC memory have a shorter life span than other D pointers to the same memory (kind of like borrowed pointers in Rust).
>
> Some kind of lifetime annotation would be required for this. Not that this is a bad idea, but it will require some work...

Isn't it sufficient to let the backend always push pointers that could be to GC memory on the stack in the functions that calls C?

>> The easy solution is to use something that is to define safe zones where you can freeze  (kind of like rendezvous semaphores, but not quite).
>
> This helps with getting the registers on the stack, but we still need type information for them.

Yes, but you have that in the description of the stack frame that you look up when doing precise collection? You need such stack frame identification utilities for doing exception handling too.

> Which of course requires type information. And existing unions need to be updated to implement this function. I guess sometimes it might not even be possible to implement it, because the state information is not present in the union itself.

Then the compiler could complain or insist that you use a conservative GC.

On Thursday, 15 May 2014 at 12:56:13 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 15 May 2014 at 12:44:56 UTC, Marc Schütz wrote:
>> On Wednesday, 14 May 2014 at 20:02:08 UTC, Ola Fosheim Grøstad wrote:
>>> However, you could have rules for collection and FFI (calling C). Like only allowing collection if all C parameters that point to GC memory have a shorter life span than other D pointers to the same memory (kind of like borrowed pointers in Rust).
>>
>> Some kind of lifetime annotation would be required for this. Not that this is a bad idea, but it will require some work...
>
> Isn't it sufficient to let the backend always push pointers that could be to GC memory on the stack in the functions that calls C?

You don't know what the C function does with them. `scope` can be used to tell the compiler that the function doesn't keep them after it returned. Of course the compiler can't verify it, but it could only allow GC pointers to be passed as scope arguments.

And of course, it would need to know which pointers _are_ GC pointers in the first place.

>
>>> The easy solution is to use something that is to define safe zones where you can freeze  (kind of like rendezvous semaphores, but not quite).
>>
>> This helps with getting the registers on the stack, but we still need type information for them.
>
> Yes, but you have that in the description of the stack frame that you look up when doing precise collection? You need such stack frame identification utilities for doing exception handling too.

Exception handling info is not detailed enough. It only contains addresses of cleanup code that needs to be called during stack unwinding, but nothing about the objects on the stack, AFAIK.

>
>> Which of course requires type information. And existing unions need to be updated to implement this function. I guess sometimes it might not even be possible to implement it, because the state information is not present in the union itself.
>
> Then the compiler could complain or insist that you use a conservative GC.

On Thursday, 15 May 2014 at 12:28:47 UTC, Marc Schütz wrote:
> 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...

A couple of not freed resources should not cause the program run out of resources. With precise GC you can get memory leaks too, it's always a gamble, so GC may or may not save you, but it still can.