Value Classes Still Need Compiler Sympathy(johan-sjolen.github.io) |
Value Classes Still Need Compiler Sympathy(johan-sjolen.github.io) |
``` Declaring a value class is first and foremost a semantic decision. It tells our fellow programmers that its instances are defined entirely by their state and do not need identity. That clearer model is valuable in itself! The JVM’s additional freedom to optimize how those values are represented is a welcome bonus. ```
Many developers seem to think that "go value go broom", but the truth is much more nuanced and the idea should not be to think about "but performance" but to think about the nature of your underlying data. At the very least this integrates some core DDD lessons directly into language. I'm glad tearing isn't turned on by default exactly for this reason.
Java was always a language that geared itself towards making libraries easy to use, putting much faith in the library author and strong encapsulation. Now, experts can gain significantly more performance from the JVM, while more humble programmers are avoided from creating bugs they will not expect.
(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.
I guess I follow the technical reason that the interface doesn’t override the method so there can’t be a specialized version of it. But that’s only visible through reflection right? Not in the direct language semantics?
I think that your misunderstanding comes from the fact that you base your understanding in Java semantics, but we really need to deal with the JVM's semantics. Your suggestion only makes sense when:
a) All of the typing information is preserved across a whole build b) The build is entirely static, no new classes can be loaded
Both of these are at odds with how the JVM functions. First: We lose type parameters on compilation, so we only see that Frobber extends Fun, the type parameters are lost and its usages are converted to Object.
Second: The JVM loads code by lazily loading classfiles. All classfiles are independent, and more can be added to a system.
Would including the specialized method in the derived interface bytecode preemptively take us all the way to C++ templates and ruin everything that’s good about Java? Or is it a matter of type erasure being consistently applied and if it were ignored selectively it would make everything more confusing?
Like if we had final class Foo implements Func<…> then we’d presumably need to supply a typed implementation of apply, so the fact that we can get away with the generic one in a specialized interface feels surprising, even though I can see why it’s technically correct.
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 developers. It was the same "cpus are cheaper than developers" idea that is repeated today with "tokens/cpu are cheaper than developers". With that philosophy, James Gosling talked about Java's "everything-is-an-object" as a mental simplification for developers. All the extra indirections of pointer-chasing to box unbox primitives and/or iterate through arrays of objects wasn't seen as a penalty (again, "CPUs are cheap; devs are expensive").
However, the later evolution in 2000s of CPU hardware vs RAM hardware changed that performance tradeoff thesis: https://en.wikipedia.org/wiki/Random-access_memory#Memory_wa...
Now having value types that are contiguous in RAM is a big deal for performance. Avoid a bunch of pointer chasing. Even C++ best practices were affected. E.g. the traditional tradeoffs you learned from from classroom textbooks of linked-lists being faster than arrays for middle-of-list insertions was no longer always correct in the new world where CPUs are caching adjacent RAM areas to try to reduce the memory wall issue. 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.
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.
> Project Valhalla got its start in 2014, with the goal of bringing more flexible flattened data types to JVM-based languages, in order to restore alignment between the programming model and the performance characteristics of modern hardware. (In some ways, it got started much earlier; the designers of Java wanted to include value types in the initial version of the language.)
That's hard when you have type erasure and polymorphism and runtime class loading. And even if they pulled it off it would blow up compile times and be programmer unfriendly because adding one line could deoptimize an important class defined in another package. So they decided to bite the bullet and add a way to statically opt in for faster but incompatible behavior.
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 kind of gave good guardrails for those of us who had to switch to a wild west nonsense of JavaScript tempered with some hints from typescript.
I wasn't aware that you could `==` two objects in Java and that it would, like, deconstruct them somehow and see if their contents matched rather than just telling you whether they referenced the same object. I'm not even sure if that is what you're saying, because that's wild and insane and it's the whole reason for observable classes in other languages (which are sort of hackish). But after so many years of like, figuring out the quickest ways to diff similar objects, relying on the VM to do it would feel like never the best solution to any given problem, and more of a footgun than a feature...?
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 changes. These value classes are still nullable, lack a guaranteed layout, and can't be observed torn, unlike in C++/C#/Go.
Go isn't much better.
Second, the reason why the compiler cannot infer on its own that a class does or does not need identity without you declaring it is that the use of identity can be in a different module.
My 2 is your 2. We don't have different 2s because it makes no sense.
But sometimes you don't just want a 2, you want a pair (2,3). All of a sudden, my (2,3) isn't your (2,3), unless you call equals instead of ==, and remember to implement equals() (and that demands implementing .hashcode() too, and probably a toString() while you're at it). While it's easy to forget about if you've been using Java for a while, 2 gets passed by value, but your pair gets passed by pointer-value.
So I'd come at it from the other side. Pick a value representation of (2,3), reap the simplicity, and hope the sufficiently smart compiler is smart enough to do good things with it.
And looking at all the edge-cases and possible data-races via tearing, declaring something as a value must be an explicit design decision that cannot be inferred by a compiler or optimizer alone.
Personally, I don't care about the tiny optimizations possible in cases of just using few of them, e.g. Integer, as int[] is an option, and even writing custom maps where the keys are placed the said array ain't difficult.
As for performance, often times I had to PrintAssembly (the article mentions that at the bottom) to ensure the compiler did its bests, e.g. optimizing away boundary checks, inlining calls, etc.
Note that this is only relevant with the way Project Valhalla works for tiny value classes. A Point value class with two double coordinates can not be stored in line in an array, on an x86-64 processor, even after non-nullability is added to get one extra bit: the largest class that can be in-lined in that way has to be 64 bits in total size.
So, ultimately, the performance advantages are only going to materialize for []Integer and (in the future) []Long, and for some very specific byte-level processing code.
Part of the issue is that this was never low-level stuff. When you're selecting between the two you're making a semantic choice, and that's not something a compiler can do for you.
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.
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 until we get non-nullability) will not be compactible. An array of 1M (long, long) pairs will hold 1M pointers to (long, long) pairs allocated in the GC heap, forever. An array of 1M (int, int) pairs will as well, but in some future release when non-nullability makes it in, it will actually work as hoped.
Go isn't even memory-safe under data races, because they don't want to pick between slower loads (like .NET's Memory<T>.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.
But whether your data’s integrity can be broken by such must be decided by the class author.
Yes, exactly.
> So if you truly want the best performance (cache lines etc.) you must enable it.
Someone was saying that this is planned as an option in some future version of Java. As it stands, this is just not possible, and to me this suggests that the performance gains from Project Valhalla in this Java will be minimal.
Does this also mean we need to worry about word aligning our fields?? What about strings?