How to get to 100% precise tracing GC?

Rainer Schuetze r.sagitario at gmx.de
Sun Nov 15 22:29:27 UTC 2020



On 15/11/2020 06:38, Ola Fosheim Grøstad wrote:
> On Saturday, 14 November 2020 at 12:39:25 UTC, Rainer Schuetze wrote:
>>
>> On 12/11/2020 09:43, Ola Fosheim Grøstad wrote:
>> These are not a problem with the current implementation, because
>> precise scanning is not done by the pointer type, but the type used
>> for the allocation. Pointer types don't contain enough information for
>> polymorphic classes or pointers to fields of structs.
> 
> The docs says that one can allocate arrays of void pointers to emplace
> in, which makes the collector less precise though.

That's where the mentioned gc_emplace() function can help, too.

> If destuctors on
> structs arent called then it should be ok to only keep the struct field
> alive?

It would disallow some patterns, for example intrinsic lists, with the
node of a list being part of a larger struct, and the offset to the
start of the struct is known.

> 
>> It's mostly untyped allocations. For example delegate closures don't
>> come with type information.
> 
> If the gc involves a modified compiler then this could change,

Sure. The generated debug information already declares the closure as a
struct.

> 
>> Another problem is precise scanning of the stack. There is no info
>> generated by the compiler. It could be implemented similar to
>> exception unwinding data, but would have to be more precise as a
>> thread can get suspended by a GC at any instruction.
> 
> Maybe the LLVM GC infrastucture can help? I haven't looked on the
> details, but that seems like a possibility.

Indeed, that could work, although the "stack map" seems a bit too
simple. It prevents some common optimizations, like having pointers only
in registers, or reusing the same stack area in different scopes inside
a function.


More information about the Digitalmars-d mailing list