CTFE and minimizing the GC

Jacob Carlborg via Digitalmars-d digitalmars-d at puremagic.com
Mon Oct 31 13:23:13 PDT 2016


One of the big features of D and a feature that is show cased is CTFE. 
The regex module and the PEG parser generator are projects that are 
often mentioned when talking about what CTFE can do.

One of the, or _the_, major goal now for D is to reduce the dependency 
on the GC in the standard library.

These two features/goals don't mix very well together. For CTFE, 
basically the only way to allocate memory is using the GC or stack 
allocated memory.

One way to minimize the dependency on the GC is to use allocators, i.e. 
std.experimental.allocator. It's understandable that an allocator that 
uses malloc/free under the hood doesn't work at CTFE. But there's both a 
GC allocator and a stack allocator, which in theory sounds like they 
could work. One could imagine a function taking an allocator as a 
policy, using a custom well optimized allocator that will be used at 
runtime. But when the function is used at CTFE, pass in the GC allocator 
instead. Unfortunately neither the GC allocator nor the stack allocator 
work at CTFE.

Using StackFront at CTFE will give you the following error:

region.d(323,20): Error: null - null cannot be interpreted at compile 
time: cannot subtract pointers to two different memory blocks

Trying to use GCAllocator at CTFE will give you:

Error: static variable instance cannot be read at compile time

Or trying to create your own instance to bypass the above error:

memory.d(368,25): Error: gc_malloc cannot be interpreted at compile 
time, because it has no available source code

Is this something that the D core team is aware of and is planning to 
address?

Is it possible to have an allocator fulfilling the allocator interface 
at the same time works at CTFE?

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list