[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