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.
