Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Project Valhalla, Simple as it can be, but not simpler

cr.openjdk.org

Post reply on HN
Print view View original

31–33 of 33 posts

Re: Project Valhalla, Simple as it can be, but not simpler

#31

Post by miffy900 »

kaba0 wrote: post #28
Kwpolska wrote: post #16

Earlier quoted context omitted.

Value types (structs) were in C# 1.0, and they’re used e.g. in native code interop. Java generics use erasure, and they are backwards-compatible with non-generic-using code. You can still say `var l = new ArrayList();` in the latest Java versions; you’ll get a compiler warning, but the code will compile and run as well as code using `ArrayList ` would. C# uses reified generics (which are faster, saner, and more expre…

> reified generics (which are faster, saner, and more expressive I wouldn’t go as far to claim that, e.g. it is often claimed to be the reason behind why the JVM has a blooming language ecosystem, while the CLR, not so much. Generics have language-level semantics and they may decide to do it differently, in which case erasure gives better results.

The way generics are implemented is definitely not the reason why the CLR has a non-existent language ecosystem. The real reason is because .NET Framework for years was a Microsoft/Windows-only thing, and is still perceieved that way despite .NET being cross-platform now; yes Mono existed since 2005, but why would anyone invest time in writing a whole new programming language for a platform that was Windows only until 2016? This, despite the technical facilities that allow for multi-langauge implementations in the CLR. All the langauges that support the CLR are Microsoft developed ones: C#, VB.NET, F#, and C++/CLI, the last one still being Windows-only. Even then VB.NET and C++/CLI exist because Microsft internally needed to support old code for a bunch of already existing projects at Microsoft anyway.

Also generics in the CLR isn't mandatory - you can implement a language without buying into the CLR-way of generics. For instance in C++/CLI, you can mix and match templates with CLR generics, but it's in no way mandatory. You can still write C++/CLI code using C++'s native template system: https://learn.microsoft.com/en-us/cpp/extensions/generics-an...

Re: Project Valhalla, Simple as it can be, but not simpler

#32

Post by kaba0 »

Kwpolska wrote: post #30
kaba0 wrote: post #28

Earlier quoted context omitted.

> reified generics (which are faster, saner, and more expressive I wouldn’t go as far to claim that, e.g. it is often claimed to be the reason behind why the JVM has a blooming language ecosystem, while the CLR, not so much. Generics have language-level semantics and they may decide to do it differently, in which case erasure gives better results.

Which languages that are built on top of the JVM would have significant issues if generics weren’t implemented via erasure? I’m pretty sure Scala would be happier with reified generics. I think the CLR might not be as popular a target because of the Microsoft ties (and the main implementation being Windows-only and closed-source for most of the CLR’s existence).

Scala actually was implemented for the CLR, but was later dropped. Here is what its creator said: https://news.ycombinator.com/item?id=14179881

Re: Project Valhalla, Simple as it can be, but not simpler

#33

Post by whizzter »

kaba0 wrote: post #25
whizzter wrote: post #11

Earlier quoted context omitted.

Value types was in the CLR(_Common_ Language Runtime) from day one as the runtime supported (variations of) C/C++,etc. Iirc proper generics didn't appear in version 1 of C# but since the foundation was there generics could become an addon in terms of new collection classes that could be properly parametrized. Java generics took a shortcut by reusing the old classes and just layering them on in the language but erasin…

Regarding List and specializing it to an int[] has more to do with generics than value types. The most important semantic info about a value type is not having identity, that is modifying it is not observable from another thread that were holding the same value previously. This alone lets one do things like freely copy/share/modify them, that directly allows for flattening.

In theory you're right, in practice however the details of the JVM instruction set and the existing generics system throws wrenches into it.

The JVM has instructions like iload, aload, dload,etc (integer, reference, double) to load values from stack slots, the simple instructions were probably chosen to support direct HW execution that was attempted for various embedded Java scenarios. They were unwilling to extend the instruction set back in the day when generics were introduced due to these type specific instructions and they just decided that everything generic could be an object.

The CLR(.NET/C#) equivalent of iload,aload,etc is ldloc , a single instruction whose type depends on the stack slot, generic classes "just" need to specialize the type of slots,etc to have a specialized class, be it a primitive, reference or value.

What they're doing now according to the article is to make aload and the a- family of instructions behave more like the CLR counterparts by adding slot flags, analysis and optimizations to detect "value-cases", so List would be List and then optimized back down to List.

It's basically a hack upon the hack because they want to preserve backwards compat to the previous hack. If they can get the engineering sorted then sure, I'm mostly glad I won't have to maintain any code related to all this machinery.

And I'm quite curious about how the JVM-lang ecosystem feels about this, maybe they're open to it if it solves backwards compat under the hood for them also, but I wouldn't be surprised if we're going to see pre-JVM 25 versions in addition to post JVM 25 versions of JVM langs in some cases.

Post reply on HN