Project Snowflake: Non-blocking safe manual memory management in .NET | Hacker News Reader

Project Snowflake: Non-blocking safe manual memory management in .NET

microsoft.com

126 pointsingve22 comments

This work was also published in PLDI as "Simple, Fast and Safe Manual Memory Management" (https://www.microsoft.com/en-us/research/wp-content/uploads/...). The presentation from the conference is also online: https://www.youtube.com/watch?v=C07s5LTuTmE

No, this is a different paper and a different technique.

This paper cites "Simple, fast and safe..." in section 7 and explains the differences.

Freaking awesome! So... the inevitable question... will this get merged into CoreCLR and become mainstream?

I would be surprised if MS wasn't intending to merge this in if it pans out the way they hope it will. Why else invest the resources to try and make it?

I know as someone who slings c# for the day job I'm super excited to try it out.

True, there are many research projects of Microsoft which ended up in production. Take the Linux Subsystem for Windows (Bash) for instance, or a little closer to home: Code contracts.

And f#

Aren't code contracts dead?

The Linux Subsystem for Windows isn't a great example. Folks in MSR Cambridge had Linux running on Windows circa Y2K. The Linux Subsystem today comes from a second effort using Drawbridge.

Great work - +1 CLR vs JVM battle. Hoping this will get merged with CoreCLR soon. Any info on this ?

Does anyone know of a game engine that uses CoreCLR instead of Mono (like in Unity)?

I've written an amateur, hobby-level engine, described here: https://mellinoe.wordpress.com/2017/01/18/net-core-game-engi.... This was more of a personal exercise for learning and experimenting than a serious attempt at game design, so the engine isn't that advanced.

For something more professional and polished, there is Xenko, which runs on CoreCLR for some of its non-mobile targets. https://xenko.com/

Also, Unity itself doesn't really run on Mono -- it just has a scripting layer that hosts Mono on top of its C++ core. Perhaps not a useful distinction for you, but I thought I'd mention it.

(Note: I work on .NET Core at Microsoft)

Do you know if this memory management work might also make it into .NET Native?

I don't know. From what I understand, this is still just a research project, and not something we have immediate plans to integrate into .NET Core. If we did that, though, I don't see why .NET Native wouldn't be considered as well.

Unity doesn't use C# for its runtime.

that isn't really coherent. it doea use c# as the main languahe for game logic and for some platforms the mono runtime

I've never used it, but know it uses C#; but after a quick perusal of the docs seems to use mono, not the Microsoft implementation even on windows:

https://docs.unity3d.com/Manual/WindowsDebugging.html

I assume conflicting terminology: Unity calls the core of the engine "runtime", and that is written in C++. If you write C# logic, then that calls through fairly thin bindings into that.

At the same time the C#/.net programs are executed by the Common Language Runtime.

It seems like this relies for some of its safety guarantees on checks in (their fork of) the C# compiler. For example, owner non-copy guarantees seem to be enforced at the C# front end level rather than in the CLR. That could cause problems for getting it into CoreCLR (and much more so the desktop CLR), as this is meant to support multiple languages; relying on a specific language front-end for safe use of a feature feels at odds with the 'common language runtime' philosophy... It would be great to see it though!

What I wouldn't give to have this in Go. Literally have been playing with Mmap system calls recreating something similar with mixed results...

Am I reading it right?

If you want to manage the memory allocation yourself you can.

Why not just pre-allocate a lost of objects and re-use / free those?

Think I'm missing something

It's a particular technique for managing the memory that helps you avoid accidentally using it after it's been freed/reused.

And you don't incur tracing overhead for objects in the manual heap. Reused objects from the GC still incur this cost.

Reply on news.ycombinator.com