Possible memory leak in source generator

[sandervanteinde]

Lately we've been experiencing much more issues with our analyzers causing quite some memory usage.

While debugging our own analyzers I was unable to find a culprit (could of course be my own debugging skills ;-) ). During memory profiling, I saw that there's quite some memory which is allocated from the Orleans source generated which is persisted.

Thus, I cloned the repo, gave the predicement to AI and it came with the following conclusion:

2. Static unbounded caches in SymbolExtensions.cs — High severity
   This is the real leak. Two static ConcurrentDictionary instances in SymbolExtensions.cs accumulate data permanently across all build invocations in a long-running compiler host (e.g., VBCSCompiler):

private static readonly ConcurrentDictionary<ITypeSymbol, TypeSyntax> TypeCache = new(...);
private static readonly ConcurrentDictionary<ISymbol, string>  NameCache  = new(...);

Because ITypeSymbol/ISymbol keys are associated with their parent Compilation, these caches effectively root entire Compilation object graphs indefinitely. They are never cleared or bounded. In a long-running dev session or CI that builds many projects in the same process, this will grow monotonically.

After doing some manual digging through the repo, I do think AI might be correct here. Can this be verified by the Orleans team and if verified, fixed?

Also, any temporary workaround would be greatly appreciated if this indeed is an issue on Orleans' side.

[ReubenBond]

This looks correct. The code gen was originally designed as a one-and-done generator, so this leak wasn't a leak. I have a PR open to convert to an incremental source generator that I want to merge after the next minor release, so that changes the design.

I can't think of a temporary workaround other than stopping the build server periodically. Orleans current source gen tries to avoid running inside of VS, so that might avoid some of these issues in practice. Which IDE do you use?

[sandervanteinde]

Hi @ReubenBond ,

Thanks for the explanation!

I myself use Rider. But I do feel that our visual studio users also experience this issue from a process called devhub.exe.

If you have a prerelease with the incremental generator in place I can definitely give that a shot to see if that resolves the issue on our end.