[Dlang-internal] DMD with GC

Rainer Schuetze r.sagitario at gmx.de
Tue Nov 7 21:14:07 UTC 2017



On 07.11.2017 10:04, RazvanN wrote:
> Hi all,
> 
> Currently the compiler is not garbage collected due to the fact that the 
> GC slows it down. This means that at some point you could enable the GC, 
> while at the moment if you do that you get ugly segfaults (see [1]). I 
> am interested in this because the compiler library should have the 
> possibility of being garbage collected and I am curios if somebody knows 
> what was the change which made the compiler incompatible with the GC.
> 
> Thanks,
> RazvanN
> 
> [1] http://forum.dlang.org/thread/dywncjvlezvrbjkfkbsz@forum.dlang.org

I recently built a semantic server for Visual D from the dmd front end 
with the GC enabled, and it didn't crash AFAICT. I don't think I had to 
make any patch but the one to make it compile 
(https://github.com/dlang/dmd/pull/7156), but you have to stop the GC 
before calling the backend and actually generate code.

It has some other issues though prohibiting it to be a viable solution 
for an IDE ATM:

- the allocation through the rmem module has the disadvantage that type 
information is lost, so that every block has to be scanned 
conservatively, even if it never contains pointers. This makes it more 
likely to have false pointers.

- there are a number of (private or function static) global variables 
that are populated during compilation, and it's not simple (though 
possible) to reset them to restart the analysis

- it eats memory like crazy. One problem I identified is that there are 
a number of pools that allocate memory in large chunks that continue to 
contain old references.

- the semantic analysis does quite a bit of transformations that make it 
difficult to match the AST to the source. Worst of all: the error 
propagation prunes complete sub trees of the AST, so there is no 
information to lookup while the code doesn't compile. This prohibits any 
help while editing, e.g. code completion or tool tips with inferred type 
information.

So it worked for displaying semantic errors during editing (Visual D 
currently only displays parsing errors), but it's not really fast.
It would be nice to have some reasonable dependency tracking so that a 
complete analysis doesn't have to be redone with every edit.


More information about the Dlang-internal mailing list