On Thu, 29 May 2014 13:07:17 -0400, safety0ff <[email protected]>
wrote:
On Thursday, 29 May 2014 at 16:13:40 UTC, Ary Borenszweig wrote:
If you add reference counting or a GC to the compiler, it will make
those large projects compile, but it will inevitably be slower than
now. That's why Walter disabled GC completely in the compiler (turning
it on made the compiler really slow).
AFAIK, he was talking about a whole compiler GC and not a CTFE only
GC/RC.
AFAIK, before the data structures created by CTFE join the AST, they get
"scrubbed" which could help us implement a self-contained memory
managing strategy for CTFE.
If by "he" you mean me, I was talking only about CTFE, not the whole
compiler.
In general, any data the compiler generates while actually compiling is
stored for later reference. Using a GC is not going to help, because the
compiler doesn't generally create much garbage.
But CTFE is full of code that expects to have a GC running, e.g. string
concatenation for mixins, etc. Not only that, CTFE functions are generally
run under the same (or even more strict) rules as strong-pure functions.
It would be entirely conceivable to just throw away all memory it
allocates except for the return value. But I don't know how that would
fare.
But it does REALLY stupid things with memory management within CTFE
functions. I think this is where RC would help. That bug you referred to
doesn't even use something that would normally allocate in normal code!
-Steve
