5 ms·
It looks like majority of this gains are related to memory management and garbage collector or am I missing something? JDK 8 -> JDK 11 gains were huge thanks t
by jakozaur 5y ago
It looks like majority of this gains are related to memory management and garbage collector or am I missing something?
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).
- RNCTX 5y agoMy knee-jerk reply when click on the topic was "depends on how much memory it demands." Good to find that the assumption was correct, lol.
- lmilcin 5y agoAnything more than couple percent just due to improved memory management is phenomenal improvement.
- mumblemumble 5y agoI'm not super surprised? That seems to be where most improvement happens across a variety of languages nowadays. 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.
- pulse7 5y agoJava's value objects (inline classes) will "maximize locality of reference". [1] [1] https://openjdk.java.net/jeps/169 https://openjdk.java.net/jeps/169
- hn_go_brrrrr 5y agoOr at least partially mitigate one of Java's biggest performance weaknesses.
- kllrnohj 5y agoThat draft is approaching 10 years old now. Has there been any indication of progress on this front in the recent JDK versions? 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.
- pulse7 5y agoIt takes time to make such a fundamental, but backwards compatible change for 10 million developers... Nobody wants Python 2 -> 3...
- kllrnohj 5y agoIt's a new keyword & bytecode feature, so there's no backwards compatible risks to it. Nobody's existing code would be impacted as nobody's existing code is using user-defined value types in the byte code. 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 https://jaxenter.com/java-value-type-163446.html ), but there doesn't seem to be any updates since then
- Sindisil 5y ago> 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 https://news.ycombinator.com/item?id=28364500
- lsuresh 5y agoIt's being actively worked on [1, 2]. [1] https://github.com/openjdk/valhalla/ https://github.com/openjdk/valhalla/ [2] https://mail.openjdk.java.net/pipermail/valhalla-dev/ https://mail.openjdk.java.net/pipermail/valhalla-dev/
- kaba0 5y ago