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

Value Classes Still Need Compiler Sympathy

johan-sjolen.github.io

Post reply on HN
Print view View original

31–40 of 51 posts

Re: Value Classes Still Need Compiler Sympathy

#31

Post by debugnik »

pjmlp wrote: post #27
debugnik wrote: post #6

Earlier quoted context omitted.

Even a smart compiler can't break the program semantics, and without a closed world assumption it simply can't assume that an entirely different part of the program doesn't expect to observe object identity for a type. Java is adding small, orthogonal features that amount to the same feature set as value types in other languages, but can be cherry-picked into existing code for partial advantages without significant c…

Nullability is coming later, and already with Panama you have plenty of room to do C like stuff. Go isn't much better.

Right, I didn't mean those are bad things! Just that value classes don't change the semantics of regular objects as much as value semantics do in other language. I like that the remaining features will be orthogonal and opt-in.

Go isn't even memory-safe under data races, because they don't want to pick between slower loads (like .NET's Memory.Span) or removing fat pointers. Meanwhile the JVM never had value types until now so they'd silently break a lot of code if a single keyword applied willy-nilly introduced torn reads like struct does in C#. It's coming but as a separate opt-in.

Re: Value Classes Still Need Compiler Sympathy

#32

Post by afdbcreid »

inigyou wrote: post #24
SkiFire13 wrote: post #14

Earlier quoted context omitted.

> So O(n) could be faster than O(log n) depending on the size of the data structure and interactions with RAM pre-fetch, etc. This has always been the case. The RAM effects only changed at which point the O(n) stops being faster than the O(log n) solution.

Apparently linear search now beats hashmap if you have less than TWO HUNDRED elements. Crazy!

But when you compare native integers, not something more complicated, right?

Re: Value Classes Still Need Compiler Sympathy

#33

Post by debugnik »

tsimionescu wrote: post #28
pjmlp wrote: post #27

Earlier quoted context omitted.

Nullability is coming later, and already with Panama you have plenty of room to do C like stuff. Go isn't much better.

You probably mean non-nullability. And the big limitation is the rule that object writes can't tear - while this remains in place, it means that only tiny value classes will get any of the performance advantages being discussed, on regular processors. Specifically, the largest guaranteed atomic norma read/write in x86-64 is 64 bits, so any class that is larger than that (say, a pair of longs, or even a pair of ints u…

Torn reads are probably coming as a separate attribute to opt-in. It's technically already there but not stable, and I don't think it does anything yet to unbox values on fields/arrays.

Re: Value Classes Still Need Compiler Sympathy

#34

Post by tsimionescu »

noduerme wrote: post #7
tancop wrote: post #3

Earlier quoted context omitted.

Java is so dynamic that it's impossible to prove a class will only be used in "value friendly" ways. When objects have no identity the meaning of `==` is different, and the compiler would have to do some kind of whole program analysis to find out if there is any way an instance of the class could ever be checked for equality. That's hard when you have type erasure and polymorphism and runtime class loading. And even…

This is really interesting. I've worked and lived alongside Java since, like, becoming extremely proficient in AS3/ECMA5(ish) and understanding the low-level quirks of that VM, but I never dealt in Java. What's funny to me is that by your description, AS3 started almost as dynamic as the objective mess you're describing, and somewhat correctly headed down a path of compile-time type safety along its trajectory, which…

I think there is some major misunderstanding here.

The point the OP was making is that a Sufficiently Smart Compiler should be able tell if a class is a reference class (and must be allocated on the heap and referenced by pointer) or a value class (that can be copied around and stored in-line in arrays or other classes).

Specifically, a class can only be a Value Class if two instances of this class are never compared using reference comparison, ==. If the program never uses this operation on two instances of this class, that means that the program would never be affected if copies are passed around instead of the original object being referenced around.

The GP was pointing out that this verification is not actually feasible, as it requires access to the entire source of the entire program, it can't be decided locally.

Re: Value Classes Still Need Compiler Sympathy

#35

Post by spockz »

inigyou wrote: post #24
SkiFire13 wrote: post #14

Earlier quoted context omitted.

> So O(n) could be faster than O(log n) depending on the size of the data structure and interactions with RAM pre-fetch, etc. This has always been the case. The RAM effects only changed at which point the O(n) stops being faster than the O(log n) solution.

Apparently linear search now beats hashmap if you have less than TWO HUNDRED elements. Crazy!

So now the result of `new HashMap()` should be backed by an array for the first 200 elements or so? Potentially the size depending on the L1 size etc.

Re: Value Classes Still Need Compiler Sympathy

#37

Post by inigyou »

spockz wrote: post #35
inigyou wrote: post #24

Earlier quoted context omitted.

Apparently linear search now beats hashmap if you have less than TWO HUNDRED elements. Crazy!

So now the result of `new HashMap ()` should be backed by an array for the first 200 elements or so? Potentially the size depending on the L1 size etc.

Not in Java, because a linear search map in Java means traversing over 100 (on average) pointers.

Re: Value Classes Still Need Compiler Sympathy

#38

Post by pfdietz »

Common Lisp has some value types, specifically numbers and characters. Any implementation is allowed to copy these objects at any time. For this reason the EQ function should not be used on numbers or characters, as the results may be unpredictable. The comparison function EQL should be used normally in its place.

(Integers and characters also are often represented by "immediate" values that reside inside what would otherwise be a pointer; for these EQL and EQ always do the same thing. But bignums and larger floats allocated on the heap can be different.)

It would be interesting to extend Common Lisp to have types that operate similarly. For example, structures that are not compared by object identity but by EQL of their fields. I presume these are the value types being discussed here for Java.

One nice thing about value types is they play well with distributed computing. Serialize/deserialize and the values stay the same; no need to have references to objects sitting off in another computer.

Re: Value Classes Still Need Compiler Sympathy

#39

Post by PaulHoule »

jasode wrote: post #12
dist-epoch wrote: post #2

Since being created, the Java pitch was "don't worry about low-level stuff like value/reference classes, a Sufficiently Smart Compiler will automatically pick the best option given your code and runtime profiling". What changed, why suddenly they adopt C++ features they explicitly excluded? https://wiki.c2.com/?SufficientlySmartCompiler

>What changed, why suddenly they adopt C++ features they explicitly excluded? Project Valhalla, which includes the effort to add value types was announced in 2014. They've been working on it for a while. As for "what changed" ... Back in 1990s when Java was conceived, there was an idea that CPUs in desktops had plenty of extra cycles that were being wasted and could therefore be used to reduce mental load on develope…

The 1990s were the peak of "you will be able to buy a better computer in a year and a half" and "the cost of computing power is going down rapidly" and, for me, the 2010s were the decade where you couldn't sell specialist VCs on any non-columnar query engine because they were all impressed by mechanical sympathy, more so than the mainstream programmer.

Today we're in the age where we can't count on your next computer being faster than your current computer or being more affordable, so the trade-offs look quite different -- it is feeling more like the 1980s where the Apple ][ line lasted almost a decade longer than Apple expected with (mainly) minor improvements in performance.

Post reply on HN