• RazvanN (10/10) Jun 26 2017 Hi all,
• safety0ff (11/16) Jun 26 2017 If my memory serve me correctly:

RazvanN <razvan.nitu1305 gmail.com> writes:

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

safety0ff <safety0ff.dev gmail.com> writes:

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