Any update?

[LifeIsStrange]

Hi @jagotu ! Your project looks amazing :) Any update?? What kinds of programs can it currently run? I know it's a bit early but your project would get public attention if you published interesting benchmarks.

[jagotu]

Hi,

the project is far away from running anything useful - almost nothing of the .NET "standard library" is implemented, so it's mostly a fancy calculator for fibonacci numbers and such :)

One part that should be pretty much complete is the parser. Important omissions by the runtime include generic types, 22 CIL instructions, and others.

I am currently completing the thesis text which should describe the state of the implementation as close as possible. Performance benchmarks will come in the next weeks.

[LifeIsStrange]

That's cool, I'm very enthusiastic about this project! Do you expect any major difficulties?

1. you have to implement the C# library or to make it work? I would expect the stdlib to compile to plain CIL? If the former, couldn't you reuse an existing Java/other language port of the stdlib and interop with it via polyglotism?
2. the C# runtime has some features that the JVM doesn't have (yet) (C++/cli, value types,??)

[steve-s]

I hope @jagotu won't mind if I comment on this.

The path forward is IMO to reuse as much as possible from the reference implementation, which is OSS with suitable license AFAIK, so basically to follow the approach of the Java bytecode interpreter Espresso (AKA Truffle Java): implement the P/Invoke and any other features/compiler intrinsics that the standard library is using.

From our experience of implementing alternative language runtimes reimplementing standard library is:

• time consuming and complex effort
• the otherwise decent documentation for users is usually not enough to create 100% compatible clone
• sometimes we had to fake bugs in the reference implementation that user code relies upon
• the library is a moving target, while the interface between the standard library and the VM tends to stay bit more stable

JVM does not directly support value types or stack allocation, but Graal compiler's escape analysis may remove allocations/stack allocate those C# constructs in many cases if the interpreter is crafted well. On top of that it may escape analyze even C# reference classes. tl;dr: for now I am not aware of any feature that could not be implemented on top of Truffle/GraalVM.

[LifeIsStrange]

Great points! About the escape analysis though that would only works X% of the time, so it would be bug prone for value types semantics (pass by copy)? I would be surprised if escape analysis can be designed to work in all cases.

Note that there was this proposal from Microsoft: https://github.com/microsoft/openjdk-proposals

A missing feature would be explicit SIMD. I mean yes openjdk has gained the vector api and it is great, but it doesn't have feature parity with the C# equivalent.

Also C# do not have type erasure. Java will support reified generics once value types ships but it's not there. Kotlin can emulate reified generics on the JVM but only for inline functions. (or they could for all but don't because of java interop? I don't know)

While the 2 first needs are not generally used in common C# code, type erasure might show more frequently. Indeed even without thoses, the project would still work for a majority of programs.

[steve-s]

The semantic aspects of all those things like that structs are value types or reflection on generic C# types will be emulated in Truffle CIL interpreter, but the interpreter should be crafted in a way the the emulation compiles down to the same/similar machine code as C#/MSIL JIT compiler would produce. We are not talking about some CIL to Java bytecode translator. C# classes will not be directly translated for Java classes etc. They will be emulated, but thanks to Truffle this emulation will eventually compile down to efficient machine code.

One thing that can be exciting is the project loom on JDK. Truffle CIL interpreter would allow to run C# on lightweight user space threads.

[jagotu]

@LifeIsStrange I completed the completeness and benchmarks chapters in the thesis.

To answer the question "What kinds of programs can it currently run?", the short answer is that it's just a fancy calculator - don't expect it to run anything more than calculations and basic operations on classes and structures. While we tried to defer to .NET's standard library implementation, it heavily relies on generics and other features we don't support, so calling any library methods usually ends with an error.

The benchmarks are also there, with the conclusion being (after warmup) it's within order of magnitude of .NET's performance.