The .NET Foundation was set up to foster open source innovation and collaboration around .NET and so I'm very pleased to announce that we have released an initial version of a new project called LLILC (pronounced "lilac") on GitHub. This is a new LLVM-based native code compiler for .NET Core which is being contributed to the .NET Foundation by Microsoft. LLVM is a very popular open source compiler framework which supports targeting multiple CPU types. LLILC creates a bridge into LLVM for .NET, making LLVM's broad chip support and tools available to .NET Core.

We are envisioning using the LLVM infrastructure for a number of scenarios. The first tool in LLILC is a Just in Time(JIT) compiler for CoreCLR.

Why a new JIT for CoreCLR?

While the CoreCLR already has JIT, we saw an opportunity to provide a new code generator that has the potential to run across all the targets and platforms supported by LLVM. To enable this, as part of the LLILC project we're opening a CIL reader that operates directly against the same common JIT interface as the production JIT (RyuJIT). This new JIT will allow any C# program written for the .NET Core class libraries to run on any platform that CoreCLR can be ported to and that LLVM will target.

There are several ongoing efforts to compile MSIL in the LLVM community. Why build another one?

When we started thinking about the fastest way to get a LLVM based code generation working we looked around at the current open source projects (SharpLang is a very cool one and LLVMSharp is also good) as well as code Microsoft had internally. While a number of the OSS projects already targeted LLVM BitCode, no one had anything yet that was a close match for the new CoreCLR interface. Looking at the options it was quickest for us to refactor and modify a working MSIL reader to target BitCode then get an existing project to support the contracts and APIs the CoreCLR uses for JIT'ing MSIL. Using an existing MSIL reader let us get the project bootsrapped using a number of building-block components that we think the wider community will also be able to take advantage of. This rapid bootstrap for C# across multiple platforms was the idea that was the genesis of this project and the compelling reason to start a new effort. We hope LLILC will provide a useful example - and a set of reusable components - for the whole community and make it easier for lots of other projects to interoperate with the CoreCLR runtime.

Why LLVM?

Basically LLVM is awesome. It's already got great support across many platforms and chipsets and the community is amazingly active. The ability for LLVM to operate as both a JIT and as an AOT compiler was especially attractive. By bringing MSIL semantics to LLVM we plan to construct a number of tools that can work against CoreCLR or some sub set of its components. By putting all this out in an early state, we also hope folks will be able to produce tools and technologies that we haven't even thought of yet.

Roadmap

As we said, it's early days for the LLILC project but the current plan is to start with a classic JIT, then move to Install-time JIT (what we talk of as "NGen" in the .NET world). Next the LLILC project team want to look at an Ahead of Time compiler (AOT) - a build lab compiler that produces standalone native executables for many platforms, using some shared components from CoreCLR. The AOT compiler could also be used to improve startup time for important command line applications like the Roslyn Compiler.

The LLIC JIT will be a functionally correct and complete JIT for the CoreCLR runtime and a great reference implementation. It's too early to say but it may not have sufficient throughput to be a first-tier JIT, but it is expected to produce high-quality code and so might make a very interesting second-tier or later JIT, or a good vehicle for prototyping codegen changes to feed back into RyuJIT.

Right now the core LLILC project team have been focusing on Windows along with Linux and Mac OS X but we would be very keen on folks getting involved that wanted to widen th platform base.

Current Status

Today on Windows we have the MSIL reader & LLVM JIT implemented well enough to compile a significant number of methods in the JIT bring up the tests included in CoreCLR. In these tests we compile about half the methods and then fall back to RyuJIT for cases we can't handle yet. The testing experience is pretty decent for developers. The tests we run can be seen in the CoreCLR test repo. All tests run against the CoreCLR GC in conservative mode - which scans the frame for roots - rather than precise mode. We don't yet support Exception Handling.

We've established builds on Linux and Mac OSX and are pulling together mscorlib, the base .NET Core library from CoreFx, and test asset dependencies to get testing off-the-ground for those platforms.

The LLILC team are starting to engage with the very cool folks in the LLVM community on the project (see the LLVM blog post) but we also hope that developers and academics who are familiar with LLVM will also get involved, helping C# and the other .NET languages be supported for LLVM.

The LLILC team will be working in the LLILC and LLVM repos over the next several months. They will be posting to the Forums as they make progress. As .NET Core becomes more fully supported on Linux and OS X, it is their intention to provide an LLILC implementation at a similar quality, so that you can use both projects together. It is also a great opportunity for us to get feedback, since we expect a lot of experimentation with .NET Core.

While it is early days, we'd love to have you join in and help bring the potential that LLILC offers to .NET Core via LLVM a reality. We want to know about your experience, either positive or issues that you encounter. If you have LLVM experience or want to gain that experience by working on the project, please do engage directly with the LLILC project. The team will actively be monitoring for any PRs, responding to issues and wanting to discuss any changes we are proposing to LLVM to help it support .NET.

LLVM and .NET are an interesting combination. .NET provides multiple-language support via a common language runtime, while LLVM supports "compilation of arbitrary programming languages" to multiple CPU targets. By combining these two worlds, LLILC provides a promising path to multiple platform support for .NET languages and by extension to the .NET developers across the globe. Exciting stuff.

Martin Woodward
Executive Director, .NET Foundation

Time flies. Exactly one year ago today, Microsoft Corp. announced the creation of an independent .NET Foundation to foster open development and collaboration around the Microsoft .NET development framework. At the end of February we announced our Advisory Council, a group of nine leaders who are bringing their passion and experience to help steward the future of .NET as an open source community. Today, I am pleased to announce that the .NET Foundation Board appointed a full time Executive Director to the .NET Foundation: Martin Woodward.

In his new role, Martin will remain an employee of Microsoft, where he has been involved in the open source world for some time. He came from the Microsoft MVP community where he worked on Eclipse, Java, Unix and Mac tooling for Team Foundation Server, bringing this functionality to Microsoft’s Developer Division. He helped drive the introduction of Git to Microsoft and ensured it was done in collaboration with the open source community. Behind the scenes, Martin lent his expertise to several Microsoft open source initiatives that you’re familiar with, including some of the projects brought into the .NET Foundation. Additionally, he has been part of a cross-company effort to improve the internal processes and tooling at Microsoft, enabling the company to do more in the open source space.

Over the past year, we have been honored by the level of community involvement in the .NET Foundation. Community collaboration levels are frankly staggering. While Microsoft has utilized its full engineering teams, including the Core CLR, Core Framework, ASP.NET, F# and Roslyn Compiler teams, working in the open on GitHub, more than 60 percent of pull requests approved for those repositories are coming from outside of Microsoft. The core project teams remain heavily focused on being responsive to those pull requests, often responding in a matter of minutes.

More important, however, is the passion of the volunteers in the .NET community that is driving the success of those projects. Until now, the .NET Foundation Board of Directors has relied on a team effort to manage the organization. But with the scale of activity that we have seen in the last year, it is time to bring someone to the team who can be fully dedicated to ensuring the rapid growth and continued innovation of the .NET open source ecosystem. I’m thrilled to have Martin onboard to do just that.

Please join me in welcoming our new executive director, Martin Woodward, to the .NET Foundation team and community!

Jay Schmelzer
President, .NET Foundation
Director Program Management, Microsoft