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

21–30 of 33 posts

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

#21

Post by pjmlp »

akkad33 wrote: post #9

I haven't read the article fully, but can anyone please explain why value types seem so much more complicated in the JVM than DotNet, where they have had it for a long time?

Besides what everyone else is describing, people forget that JVM was designed for Java only, while Common Language Runtime was designed as a polyglot runtime, including support for C and C++, and to this day C++ is officially supported, even if only on Windows (as Visual C++ is the only production compiler with a CLR backend).

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

#22

Post by pjmlp »

pron wrote: post #15
akkad33 wrote: post #9

I haven't read the article fully, but can anyone please explain why value types seem so much more complicated in the JVM than DotNet, where they have had it for a long time?

First, .NET structs are flattenable but they're not value types, which are immutable and so pose further problems. But the two main challenges for adding any new big feature to Java are forward compatibility and simplicity. 1. Forward compatibility: While backward compatibility means that old code continues to run and so is easy to do (add the new feature "on the side"), forward compatibility, or migration compatibil…

> as early as the late eighties MS was "the C++" company.

Which to me was always ironic that they get perceived like that, given that C++ was born at Bell Labs alongside C and UNIX, and CORBA was born on UNIX, IBM and Apple were equally pushing for C++, and Borland always had better C++ tooling (to this day even as Embarcadero) than Microsoft has done during the last 30 years.

Now it is certainly true that WinDev is pretty much a C++ shop to detriment of anything else, including .NET.

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

#24

Post by DarkNova6 »

quelltext wrote: post #7

From the start I was wondering if there's no way for the JVM to solve this with less cruft on the bytecode level. Of course, that doesn't mean I was aware of the challenges, just an intuition. I do think they must have had similar intuitions in the beginning. Then identified big challenges with that and that what would be needed to overcome it more streamlined is some set of features or optimizations. It seems though…

This was not so much a „change in direction“ but rather having a guiding model which assumes the worst case. But by now enough evidence has emerged that the same performance can be achieved with object descriptors.

Discussion on the mailing list: https://mail.openjdk.org/pipermail/valhalla-spec-experts/202...

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

#25

Post by kaba0 »

whizzter wrote: post #11
akkad33 wrote: post #9

I haven't read the article fully, but can anyone please explain why value types seem so much more complicated in the JVM than DotNet, where they have had it for a long time?

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.

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

#27

Post by samus »

akkad33 wrote: post #9

I haven't read the article fully, but can anyone please explain why value types seem so much more complicated in the JVM than DotNet, where they have had it for a long time?

A non-obvious difficulty is that on the bytecode level constructor invocation are "special", i.e., a separate bytecode command has to be used to call it. Therefore, introducing separate instructions for value types would have required recompilation (or rewriting at startup) of user code that calls constructors of value classes. This would have been an ongoing migration issue and a potential source of bugs, not just because of Java Core legacy like the primitive wrapper types. Fortunately, it turns out that the JVM can be adapted to smoothly hide the difference behind the scenes.

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

#28

Post by kaba0 »

Kwpolska wrote: post #16
eonwe wrote: post #13

Earlier quoted context omitted.

I’d say that it’s backwards compatibility. My understanding is that moving from 1.1 to 2.0 (that introduced reified generics) required work from developers of libraries. It was also done in relative infancy of the ecosystem. But I trust some c# oldtimer to tell me how it actually was as I only remember that some tools I used insisted to have older .net runtime installed.

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.

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

#29

Post by tadfisher »

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.

A short way to describe this: you have to throw away all high-level type information in order to execute code on real machines, so the choice becomes when to throw it away.

CLR languages throw it away in the runtime, JVM languages throw some away in bytecode, and Haskell throws it all away in the compiler.

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

#30

Post by Kwpolska »

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.

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).
Post reply on HN