Escape analysis doing the heavy lifting here. Until it's fully reliable you're still guessing at allocation.
Value Classes Still Need Compiler Sympathy
11–20 of 51 posts
Re: Value Classes Still Need Compiler Sympathy
#12Since 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 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.
Re: Value Classes Still Need Compiler Sympathy
#13Since 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
> don't worry about low-level stuff like value/reference classes
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.
Re: Value Classes Still Need Compiler Sympathy
#14Since 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…
> 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.
Re: Value Classes Still Need Compiler Sympathy
#15Escape analysis doing the heavy lifting here. Until it's fully reliable you're still guessing at allocation.
I'd say it's the other way around than escape analysis. The method ABI can always scalarize value class types without escape analysis, but if they ever need to get type-erased or written atomically you end up with extra allocations for what would have been a single object before. Similar to boxing value types in C# really.
Re: Value Classes Still Need Compiler Sympathy
#16Since 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…
https://openjdk.org/projects/valhalla/design-notes/state-of-...
> 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.)
Re: Value Classes Still Need Compiler Sympathy
#17Since 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
This was pretty much always wrong. Nobody writing performance critical code in Java trusts the compiler to magically figure things out, and the sort of code you arrive at if you want Java to go fast is generally unidiomatic.
Re: Value Classes Still Need Compiler Sympathy
#18Since 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
The object header overhead was always present and expensive in massive arrays - the classic example would be the Point class that has two "double x, y". Realistically the value classes make sense most (only) if they are placed in arrays. In order to use tons of points you'd end up having two arrays, double[] x, double[] y... or go even with direct buffers.
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.
Re: Value Classes Still Need Compiler Sympathy
#19JVM escape analysis has always been hit or miss. Nice to see it getting more predictable.
Re: Value Classes Still Need Compiler Sympathy
#20Of course they do, regardless of the language. That is why we have things such as string interning for instance. :)