[pron]

I'm not sure what is meant here by "on par with the JVM." I'm not trying to claim that one or the other is better, but there is a basic difference in how they're designed and continue to evolve. .NET believes in a language that gives more control on top of a more basic runtime, while Java believes in a language that's smaller built on top of a more advanced runtime. They just make different tradeoffs. .NET doesn't "need" a more advanced runtime because limitations in its runtime can be overcome by more explicit control in the language; Java doesn't "need" a more elaborate language because limitations in the level of control offered by the language can be overcome by a more sophisticated runtime.

I'm not saying these are huge differences, but they're real. C# has more features than the Java language, while Java's compiler and GCs are more sophisticated than the CLR's. Both of these differences are due to conscious choices made by both teams, and they each have their pros and cons. I think these differences are very apparent in how these two platforms tackled high-scale concurrency: .NET did it in the language; Java did it in the runtime. When it comes to value types, we see a similar difference: in C# you have classes and structs (with autoboxing); in Java we'll just have classes that declare whether they care about identity, and the runtime will then choose how to represent each instance in memory (earlier designs did explore "structs with autoboxing" but things have moved on from there, to the point of redefining autoboxing even for Java primitives; for a type that doesn't care about identity, autoboxing becomes an implementation detail - transparently made by the compiler - with no semantic difference, as a pointer or a value cannot be distinguidhed in such a case - hence https://openjdk.org/jeps/390 - unlike before, when an Integer instance could be distinguished from an int).

[pjmlp]

It means that it does the same JIT optimization tricks that Hotspot performs, escape analysis, devirtualization, inlining method calls, removing marshaling layers when calling into native code, PGO feedback,....

I would like to someday have someone write blog posts about performance like the famous ones from the .NET team, and also not having to depend on something external like JIT Watch, instead of having it in box like .NET.

Example for upcoming .NET 10,

https://devblogs.microsoft.com/dotnet/performance-improvemen...

Also C# and .NET low level programming features are here today, Project Valhala delivery is still in future, to be done across several versions, assuming that Oracle's management doesn't lose interest funding the effort after all these years.

It is kind of interesting how after all these years, the solution is going to be similar in spirit to what Eiffel expanded types were already offering in 1986.

https://wiki.liberty-eiffel.org/index.php/Expanded_or_refere...

https://archive.eiffel.com/doc/online/eiffel50/intro/languag...

I guess that is what happens when language adoption turns out to go in a different path than originally planned, given Java's origins.

[pron]

> It means that it does the same JIT optimization tricks that Hotspot performs, escape analysis, devirtualization, inlining method calls, removing marshaling layers when calling into native code, PGO feedback,....

It has rather recently started using most (or perhaps all) of the same techniques; it does not actually perform all the same optimisations. C2 is still significantly more advanced. Of course, some optimisations are more difficult in C#, as its "low level" features expose more implementation details, giving the compiler less freedom.

> It is kind of interesting how after all these years, the solution is going to be similar in spirit to what Eiffel expanded types were already offering in 1986.

I don't have time to compare the details (and I don't work on Valhalla), but it doesn't seem to me to be the same thing. In Eiffel, the class says whether or not it's expanded. In Java, the compiler decides, as an optimisation, whether to inline or box different object instances (on a per-object, not per-class basis). It's just that classes with certain characteristics give the compiler more freedom to inline in more cases.

Think about it this way: In Java 8, Integer and int are two different types with very different behaviours, albeit with an autoboxing relationship. You can't synchronize on an int instance or assign null to an int variable; equality comparisons on Integer compare object identity, not numeric value. We'll gradually turn Integer and int into effectively the same type (with two names, for historical reasons), and turn the decision of whether a particular instance is inlined or not up to the compiler, as an optimisation decision. It's not that autoboxing will expand to user defined types, but rather it will become nonexistent.

But generally, almost anything we do in Java is something that's been done (more or less) somewhere else a while ago, because we like to avoid ideas that have not been tested. Basically, for X to be considered for Java, there must exist some language that tried X in 1986. It's just that it's not always the same language.