This project is read-only.

Collectible dynamic (assembly) modules

Topics: APIs, General
Sep 4, 2014 at 3:38 PM
Edited Sep 4, 2014 at 4:45 PM
Hi all,

Our company has a .NET software program that is running during several months at the site of the customers. It constantly executes very complex calculations based on varying inputs with high sample frequencies; these calculations are done in blocks of 50 ms of data. Mostly, we just execute mathematical formula (e.g.: 5 * x + log10(5*y) + skewness(Pow(y,3 + z))). These formula can be changed at any time by the customer via a GUI.

In December 2013 we saw the opportunities of Roslyn to fasten the execution of these calculations, and we redesigned our calculations using a preliminary dll for .NET 4.0. We decided to inline the mathematical formula at run time based on dynamic code generation. This gave a speedup with a factor 5 to 15.

0) We created the CSharp code with a string builder
1) We created a Roslyn.Compilers.CSharp.Compilation object
2) We call the method DefineDynamicModule on a dynamic assemblybuilder to get a dynamic modulebuilder. The assemblybuilder has the setting "AssemblyBuilderAccess.RunAndCollect"
3) We emit the compilation object to the dynamic (collectible) module

It is extremely important that these dynamic modules are collectible!!! This is because our software is running for months without interruptions, yet allowing the formula to be changed by the customers at any time.

Now we want to upgrade our software to .NET 4.5 and Visual Studio 13, we have noticed that the Roslyn "emit" method, does no longer provide an overload allowing a "module" as a parameter.

Is this intentional?

I did not yet find a way to use the "stream" parameter of the "emit" method in such a way that our dynamic code is collected when necessary...... Because of performance reasons, obviously, the use of different application domains is not possible.
Sep 4, 2014 at 4:34 PM
Edited Sep 4, 2014 at 5:24 PM
Yes they removed that intentionally, including the whole scripting concept:
We have removed the support for collectible assemblies since the underlying implementation in the CLR doesn't provide us the capabilities we need to build a fully functional C#/VB code gen on top of it. The implementation we had was mostly experimental with a lot of workarounds and problems.

The scripting stuff is going to come back later. While nobody said anything about the ability to GC generated code I think they'll have to provide something when the scripting system comes back, because it kinda needs it. It would be bad if interactive shells needed to be restarted every few hours to prevent OOM ;-)

At the current point your only options (as far as I know) are separate processes or separate app domains. Note that while these are expensive to create you don't need to recreate them for every request. Just let them run and accumulate garbage for a while, and when they are getting too full just terminate/unload them.

That is what I would try if I were in your position, assuming you currently don't have any other working solution.
Marked as answer by TomasMatousek on 11/14/2014 at 11:35 PM
Nov 15, 2014 at 7:35 AM
Nov 15, 2014 at 6:11 PM
Edited Nov 15, 2014 at 6:14 PM
Seconded (and voted). The entire Roslyn project is great and I'm 100% behind the need to firm up the complier APIs etc. But for some of us the scripting API was the thing that really stood out as being something totally new and powerful in the CTP that could add huge value to so many applications.

The announcement that scripting wasn't in the initial release made sense, but it's been so long now without any further word it would just be nice to hear something official about whether this really is on the roadmap and what the priority is? Should we just be looking for alternative solutions to the kind of problems the scripting API solved, or should we hold on a bit longer?

Please don't take this as a complaint! I understand resources are limited and you guys are working really hard on the project. I just think it would be helpful for those of us with an investment in the scripting API to have some firmer indication of the direction we can expect the project to head in with regards scripting, even if it is just at a very high level.
Nov 18, 2014 at 5:04 PM
TomasMatousek wrote:
Please vote here: to help us prioritize collectible code gen improvements.
To be fair VisualStudio.UserVoice is now AlmostEveryTechnology.UserVoice. I have already spent my voices on stuff other teams are dealing with.

How related are e.g. WPF and Roslyn teams?

Also none of the top 5 requests got addressed, which sends kind of a negative signal.

Roslyn team is doing a fantastic job, but since you brought it up :).
Sep 24, 2015 at 9:53 AM
Dear all,

We are one year later now. I created this post one year ago.
Is there any progress concerning collectible dynamic modules yet?

Kind regards
Sep 24, 2015 at 10:39 AM
Oct 2, 2015 at 10:38 AM

Is it possible to provide a link with the post in the other forum. I do not find it…

Oct 2, 2015 at 2:09 PM
There isn't necessarily a post about this on the GitHub issues, but there won't be an answer on this one.

You can always create an issue for that.