June 26, 2017
Hi all,

Currently the compiler disbles the GC before doing anything, so I am doing the same thing with the parser library implementation which was merged a little while ago. Since its unacceptable for a library to not be GCed, I was wondering what would it be necessary to make the compiler GCable. Last time I tried to build dmd with GC, I couldn't compile druntime or phobos, so I wanted to know what was the first feature that needed GC.disable()?

Best regards,
RazvanN
June 26, 2017
On Monday, 26 June 2017 at 11:32:30 UTC, RazvanN wrote:
>
> I was wondering what would it be necessary to make the
> compiler GCable.

If my memory serve me correctly:
You need to verify that all allocations are either GC managed or registered via the addRoot/addRange API.
Some allocations bypass the current wrapper for switching between GC allocation and normal allocation.
To catch these you can switch dmd to use GC and wrap malloc / global operator::new  display a stack trace so you can review the code for GC compatibility.

IIRC, allocation operator::new was the key to making it work.

>
> Last time I tried to build dmd with GC, I couldn't compile
> druntime or phobos, so I wanted to know what was the first
> feature that needed GC.disable()?

AFAIK it's all in the name of performance