JDK 8 -> JDK 11 gains were huge thanks to String optimisations (e.g. GC could dedup strings and store one char as byte in many cases).
JDK 8 -> JDK 11 gains were huge thanks to String optimisations (e.g. GC could dedup strings and store one char as byte in many cases).
I recently listened to an interview with someone working on Intel's C++, and he indicated that, contrary to popular assumption, most of the speed boost you can get with it isn't from better instruction-level micro-optimization, it's from analyzing information flows and maximizing locality of reference.
Perhaps this is an inevitable result of that ever growing processor-memory performance gap. Nowadays, the cost of having to take a walk of shame out to the RAM chips is so great compared to everything else that I would assume that minimizing the number of times you have to do that is by far the lowest-hanging fruit.
The kotlin workaround hacks are clever but also nasty and having real VM support for this would be great. But it also is starting to seem like the type of issue that just won't ever be fixed, despite how hugely important it is for performance.
It looks like there were some experiments and prototyping out of Valhalla from 2014-2018 (including a publicly available build: https://jaxenter.com/java-value-type-163446.html ), but there doesn't seem to be any updates since then
Oracle (Brian Goetz in particular) regularly gives talks and interviews and publishes updates.
There was even a link on this site a couple weeks ago: https://news.ycombinator.com/item?id=28364500
[1] https://github.com/openjdk/valhalla/ [2] https://mail.openjdk.java.net/pipermail/valhalla-dev/
Good to find that the assumption was correct, lol.