Re:JEP Draft: Deprecate memory-access methods in sun.misc.un...
by xxs on Wednesday January 17, 2024 @02:15AM
(#39024341)
>With that said, convincing a compiler to elide bounds checks (especially Java's JIT compiler) is a hugely frustrating (and for some algorithms futile) task.
Adding explicit checks does work to a certain degree but it can change with the compiler, and it requires to keep checking the generated assembly - not fun (no unsafe, either but still)
Re:JEP Draft: Deprecate memory-access methods in sun.misc.un...
by iscoelho on Wednesday January 17, 2024 @03:49AM
(#39025081)
These explicit checks are basically what I mean by "convincing the compiler" (and sometimes, it isn't quite convinced!) - Yeah. Not fun at all.
Especially in Java, because "the assembly" can change as the JIT evolves. What is optimized today may not be tomorrow.
Re:JEP Draft: Deprecate memory-access methods in sun.misc.un...
by xxs on Wednesday January 17, 2024 @03:56AM
(#39025146)
Some 12-13y back (time does fly) Cliff Click (hotspot architect) had a series of blogs on optimizations, incl. the lattice checks (i.e. within bounds). Was quite insightful. It was called: "Too Much Theory" [0]
>What is optimized today may not be tomorrow.
Exactly. (Also most developers will have exceptionally hard time maintaining such code)
[0]: https://web.archive.org/web/20120328222841/http://cliffc.org...
Re:JEP Draft: Deprecate memory-access methods in sun.misc.un...
by sitkack on Wednesday January 17, 2024 @05:33PM
(#39034524)
I understand where you are coming from, but without comparing the generated assembly, we are comparing an implementation of bounds checks. I think we should have a bounds check instruction and operates concurrently.
I should play around this with this using a couple RISC-V cores.
> Performance matters!
https://www.youtube.com/watch?v=r-TLSBdHe1A by Emery Berger
Another, yesbut, encryption and compression are and will handled by on die accelerators.
With that said, convincing a compiler to elide bounds checks (especially Java's JIT compiler) is a hugely frustrating (and for some algorithms futile) task.
It could be an argument that bounds checks make up a small percentage of total application performance. However, I've profiled production Java servers where >50% of the CPU was encryption/compression. JDK implementations of those algorithms are heavily impacted by (and commonly fail to elide) bounds checks.
Performance matters!