D Language Foundation July 2026 Quarterly Meeting Summary

[Mike Parker]

The D Language Foundation’s quarterly meeting for July 2026 took 
place on Friday the 3rd. It lasted a little under fifty minutes.

Our quarterly meetings are where representatives from businesses 
big and small can bring us their most pressing D issues, status 
reports on their use of D, and so on.

## The Attendees

The following people attended the meeting:

* Walter Bright (DLF)
* Luís Ferreira (Weka)
* Dennis Korpel (DLF/SARC)
* Mathias Lang (DLF/Symmetry)
* Mike Parker (DLF)
* Bastiaan Veelo (SARC)
* Nicholas Wilson (DLF)

## The Summary

### Bastiaan

Bastiaan said SARC had no pressing issues. They were inching 
closer to D-Day. They weren't quite there yet, but things were 
looking promising.

Dennis asked whether they had solved the garbage collector thread 
contention. Bastiaan said they had solved it in one central 
module that was called billions of times in a session. He had 
seen another test that was taking a little longer, though, and 
still needed to dive into it.

He said a university had asked if they had a project that a group 
of bachelor’s students could work on. SARC had some command-line 
programs that they wanted to run as Windows services, so they 
came up with an assignment to build something that could turn any 
command-line program into a service, with a user interface living 
in the dock. The service needed to start without anyone logging 
in and launching it manually. One of the project requirements was 
that it be written in D.

Four students took it on. Bastiaan said they had been very 
positive about D, two of them especially so, and he thought those 
two would continue working with the language. The project itself 
was a success and had produced a complete, finished product. He 
had encouraged the students to publish it on code.dlang.org.

He said the whole thing had been a very nice experience. Nicholas 
thought it sounded like a good candidate for the D blog if the 
students were interested. I agreed and asked Bastiaan to give 
them my email address. He said he would.

__UPDATE__: The students emailed me and we've discussed the blog 
post.

### Me

I passed along an update from Mario about Funkwerk. They had two 
problems to solve, but the good news was that neither of them was 
caused by D. Everything was working after Mathis pushed some 
immutable utilities forward in their codebase.

### Luís

__serve-d on macOS__

Luís said he had asked people at Weka what questions they thought 
would be useful to raise at the meeting. One issue was their 
development experience on macOS. More and more people at the 
company were using Macs, [and 
serve-d](https://code.dlang.org/packages/serve-d) wasn't working 
the way they needed it to. Luís had used it without any problems 
on Linux, both on his previous work laptop and on his personal 
machine, but on macOS it crashed.

He asked whether the foundation would be willing to support an 
official, stable LSP server that worked across all platforms. He 
also thought it would be valuable to have one based on the 
compiler so that it could provide full semantic information, 
which serve-d did not.

I said we were working toward putting an LSP interface in the 
compiler. There had been talk of running the compiler as a daemon 
with the LSP server built in, but another possibility was 
exposing DMD as a library for another process to use. I didn't 
know what final form it would take.

Walter said progress was being made, but it was frustratingly 
slow. The front end had been designed as a standalone program, 
not as a library, and converting it was not easy. I said this was 
the kind of project it would be useful to hire a contractor to 
push through if we had the funding.

As a short-term solution for Weka, Luís had created an LDC plugin 
that traversed the DMD front end and generated something similar 
to Ctags. It was good enough for their purposes, but the 
resulting file was huge. He thought serve-d’s macOS crashes might 
likewise come from high memory consumption. Weka had a monorepo 
containing all of its code, and serve-d couldn't load the whole 
project. They had to limit it to specific directories.

Weka had sponsored some serve-d work to get issues fixed, but 
Luís wasn't sure whether they had a list of the problems that 
remained. One issue was that they had to build serve-d themselves 
for every Mac user. That was manageable for people already at 
Weka, but it made setup a pain for new people. He thought the 
deeper memory problem was in DCD. Rather than keeping every 
symbol in memory, maybe DCD could index them in a memory-mapped 
database on disk and look them up only when needed.

I found [an existing serve-d issue from July 
2025](https://github.com/Pure-D/serve-d/issues/393) about a 
segmentation fault on macOS. Luís thought it might be related to 
an Apple API change affecting thread-local storage. He had also 
tried the official DMD installer on macOS and seen it segfault, 
apparently because DRuntime made an assumption about the TLS 
regions that was no longer valid. The runtime fix had not yet 
been released.

He added that debugging that sort of thing was harder because D 
support in LLDB on macOS wasn't working properly. He accepted 
some responsibility for that because he had worked on the 
project. The good news was that he was pushing again to get his 
changes upstreamed.

__Very high compile-time memory usage__

His other major topic was Weka’s compile-time memory consumption. 
Their builds had become enormous. They had recently increased 
their build servers from one terabyte of memory to one and a half 
terabytes, and the builds were still memory-bound. One source of 
the problem was Weka’s system for versioning reference types. As 
the number of versions grew, the compiler had to perform more 
comparisons during CTFE to generate the structs, and all of that 
data had to remain in memory.

He said that the proper solution on Weka’s side was to split the 
compilation into much smaller pieces. Still, he wanted to know 
whether more of the compiler work could be cached, particularly 
CTFE, so that repeated invocations could share results and 
incremental builds could be faster. LDC could cache back end 
work, but not the front end.

Walter pointed out that caching normally consumed more memory, 
which was already their limiting resource. Luís agreed that it 
could, but said there might still be a net gain. Their larger 
build servers had not reduced build time. Meanwhile, DMD's normal 
strategy was to allocate until it exited. Using its low-memory 
mode reduced memory use, but made the build much slower because 
the collector ran more frequently over a very large number of 
objects. If CTFE results could be cached, he thought the overall 
memory cost might fall rather than rise.

Walter asked whether Weka could break the program into smaller 
programs or shared libraries. Luís said that was exactly what he 
was advocating internally. Their current approach was the wrong 
solution for their problem, and they needed to split it up. 
Walter said he could trim a few bytes here and there from 
compiler data structures, but that would only fiddle around the 
edges and wouldn't solve a problem of this scale.

Luís had already experimented with CTFE optimization in a branch 
of Weka’s LDC fork. Their generated structs contained many 
zero-initialized arrays. CTFE currently materialized every 
element as an expression node even when code only needed 
something like the array's length. He changed it so the array 
could be represented as a repeated-value range and materialized 
only when something actually touched its elements. On Weka's 
workload, that alone saved roughly fifty gigabytes of memory.

The branch was only a proof of concept. It worked on Weka's 
codebase, but he hadn't run thorough tests, and there were likely 
edge cases where he had failed to materialize an AST node that 
needed it. He wasn't claiming it was ready to ship. Still, it had 
led him to consider reviving Stefan Koch's old CTFE engine, which 
used a bytecode VM rather than interpreting everything through 
AST nodes.

Walter thought a JIT would increase memory consumption, since the 
AST still had to exist and the generated code would be additional 
data. Nicholas explained that the major cost was not just the 
fixed AST for the function. The existing interpreter represented 
the intermediate values created while executing the function as 
still more AST nodes. Translating the function into bytecode and 
executing that could avoid most of those temporary expression 
objects. Walter understood the distinction and agreed Nicholas 
was right.

Walter had once spent a fair amount of time trying to free 
temporary nodes generated during CTFE, but the problem had been 
much more difficult than he expected. Generated nodes that had to 
survive as part of the final result were mixed together with the 
intermediate nodes. He hadn't found a safe way to tease them 
apart.

I asked whether improving the CTFE engine could be a Symmetry 
Autumn of Code project. Luís thought something related might 
already be on the project list, but the biggest problem was 
finding time to mentor it. Dennis thought the current CTFE engine 
would be a very demanding project for a student and require heavy 
mentor involvement. If Walter had struggled with reclaiming its 
memory, that showed how complex the code was.

Nicholas proposed duplicating the result nodes that needed to 
live and allocating the copies separately. That could leave the 
long-lived CTFE objects on one set of pages and make it possible 
to discard the pages containing temporary garbage. He said it was 
probably a stupid idea, but Walter said it wasn't a bad germ of 
one. Another possibility was to mark every node created during 
CTFE, walk the result at the end to unmark the nodes that had 
survived into it, and free whatever remained.

Nicholas suggested that if the task was too difficult for a SAOC 
student, our intern might be able to look into it. He already had 
some compiler context. He asked Luís for links to both Stefan's 
old engine and Weka's branch so he could pass them along and see 
what came of the discussion.

Luís had also found another source of extreme memory use while 
building his test case. Weka used only the conservative garbage 
collector, but the compiler still generated precise-GC bitmaps. 
For large arrays, the precise-GC information was lowered to a 
runtime template whose elements became part of the mangled name. 
Those mangled symbols could grow to megabytes or even gigabytes.

LDC hashed template parameters in its backend, but by then the 
enormous name had already eaten up memory in the front end. The 
front end only had back references. Luís thought official 
mangling should use hashing rather than relying on repeated back 
references, which he worried could be abused to produce explosive 
expansion. He had added experimental work on this to his branch 
as well.

He hoped to upstream some of these changes and work on a more 
complete CTFE solution if he could find the time. This was 
hurting Weka more and more, so if the company chose to prioritize 
it, he wanted to make an attempt.

He asked if there had been any progress on the new garbage 
collector Symmetry had been working on. Mathias said he thought 
it was finished and working in Symmetry's projects. Luís said 
Weka was well behind the current compiler versions, which was why 
he hadn't realized the collector was already in use. He had 
recently moved Weka from LLVM 14 to LLVM 18 and next needed to 
get them to LLVM 22. Mathias confirmed that Symmetry used the new 
collector every day and that it was working well. Luís said that 
was great news.

### Mathias

Mathias said he had no problems with D to report.

### Dennis

Dennis had nothing to report with his industry hat on. On the DLF 
side, he had been experimenting with a couple of things we 
discussed earlier in the meeting.

First, he had been toying with an LSP implementation for DMD. He 
had shown a demo at DConf and was considering making a serious 
push to release it at some point.

Dennis had also been experimenting with a WebAssembly backend for 
DMD, potentially for use in CTFE as well. He recalled that 
Stefan's CTFE project had been a bytecode interpreter rather than 
a JIT. Since Stefan had moved on to his own metaprogramming 
language, Dennis wasn't sure there was a future for it.

With Claude's help, he had produced a fairly advanced WebAssembly 
backend prototype that passed most of the DMD test suite. Walter 
warned him that the last ten percent was the killer. Dennis knew 
that. He could pass most tests, but there were still obstacles 
between that and running real programs.

He wanted to know how receptive everyone would be to adding a 
WebAssembly backend to DMD. He wondered whether people would 
consider it redundant because LDC already supported WebAssembly. 
He thought it had value in its own right, particularly for macOS, 
and Mathias said the CTFE angle sounded promising. If we wanted 
to use it for CTFE, then it had to be part of DMD.

Nicholas noted that there was also ongoing work around the 
WebAssembly System Interface. WASI effectively provided the 
operating-system layer, and newer versions were adding more 
runtime support, including areas such as exception handling, 
garbage collection, and C bindings.

Dennis left it there. He said he might have something for the 
blog and would email me about it.

### Nicholas

Nicholas said the GSoC students were doing well. The interim 
report was coming up. The reporting period didn't open until the 
following Monday, which annoyingly meant he couldn't complete it 
yet, but his student was making good progress.

Walter thanked Nicholas for all his help with Walter's pull 
requests. Nicholas asked which ones. Walter said Nicholas had 
simply been doing a great job helping him get them finished. 
Nicholas said it was his pleasure.

### Walter

Walter said he was still plugging away at that blasted AArch64 
code generator, moving it forward bit by bit.

Fixup generation was currently a giant mystery. He spent a lot of 
time writing small pieces of code, running them through GCC, 
examining the fixups it generated, and then integrating support 
into the code generator one case at a time.

Dennis asked whether he had been using an AI agent to help debug 
it. Walter said he didn't use AI to generate the code. What he 
found productive was generating sample object files himself and 
asking an AI whether the fixups were correct. It would then point 
out his mistakes.

Dennis said an agent could go further than that. It could compile 
test programs, inspect the binaries, and locate bugs 
autonomously, saving Walter from copying information back and 
forth. This had been very useful during Dennis's WebAssembly 
work. The agent could sometimes fix an entire bug by itself, then 
he only had to verify that it had identified the real root cause. 
He worked on Linux using QEMU for ARM, which was also how he had 
set up the ARM CI.

Nicholas asked whether Walter used Compiler Explorer to change 
small examples and immediately inspect the output. Walter said 
he'd used it for much of the initial work. When he needed to find 
the AArch64 instruction for an operation like multiplying 
floating-point numbers, he could write a two-line C function, 
compile it in Compiler Explorer, and see the right instruction. 
That had been extremely useful given the architecture's thousands 
of instructions and how unclear many of them were to him.

Compiler Explorer was less helpful with debug information and 
fixups, but AI had been useful there. He'd been using ChatGPT. 
Dennis [linked him to a pull 
request](https://github.com/dlang/dmd/pull/23157/changes) where 
Claude had independently found a bad relocation whose addend 
accidentally contained an opcode instead of the offset. It was an 
example of what an agent could do. Walter said he would look at 
it after the meeting.

## Conclusion

Our next meeting was the July monthly meeting on the 10th. Our 
next quarterly meeting is set for the first Friday in October.

If you're running or working for a business using D, large or 
small, and would like to join our quarterly meetings periodically 
or regularly to share your problems or experiences, please let me 
know.