5 ms·
The cost of bounds checks, which is already low, could be reduced further the vast majority of uses with even more enhancements to the compiler's inlining decis
by pron 3y ago
The cost of bounds checks, which is already low, could be reduced further the vast majority of uses with even more enhancements to the compiler's inlining decisions, so we're talking about an API whose value is already small and constantly declining. However, those who think they absolutely need to avoid bounds checks could, indeed, use a flag to access the JDK's internals. We don't think that such a small benefit (especially when integrated over all users) merits a supported API.
- iscoelho 3y ago> "which is already low", "such a small benefit" This is subjective. In my opinion, even 10%~ is massive. Performance matters and this would be a step backwards.
- kaba0 3y agoWhere it matters, you can just write that part in a low-level language and call out to that.
- yjftsjthsd-h 3y agoThus bringing us back to the same unsafety with extra steps and glue required; what did we gain from this? Edit: Unless you FFI to Rust / Ada / formally verified C, in which case perhaps we can claw back the performance and safety at the cost of a lot more dev work.
- eptcyka 3y agoFFI boundaries are inherently unsafe regardless of language.
- kaba0 3y agoBut more “distance” between the two might be better, like, copying some value-like objects and doing the operation on that and copying back the result is much safer, than passing pointers between the two worlds. And this change might push the balance a bit to this side.
- yjftsjthsd-h 3y agoCopying is safer but bad performance, so I'm not sure how that helps here?
- pron 3y agoYou don't need FFI -- you could reach for JDK internals if you conclude you must; all that requires is a flag. What we gain from this is that the vast majority of programs using Unsafe will gain safety with the new supported APIs and will not lose performance. Also, FFI to Rust will buy you nothing. Safe Rust performs the same bound checks as Java while unsafe Rust would be just as unsafe as using JDK internals. If you want to prove the safety of unsafe code in some other unsafe language, you might as well do the same for unsafe Java code using JDK internals (it would probably even be easier).
- pjmlp 3y agoOr use C#, Go, Rust instead, which is sadly a loss for Java. We are no longer in the Sun days, with Java being the answer for everything.
- bitcharmer 3y agoThis is incorrect. Native calls whether it's via JNI (even with CriticalJNINatives) or Panama still have a transition cost formerly referred to as gc locker. I'm in a field where performance is number one requirement. Removing unsafe is a terrible idea.
- _w1tm 3y ago> I'm in a field where performance is number one requirement. Removing unsafe is a terrible idea. Are you sure you should be using Java if your use-case is performance sensitive?
- iscoelho 3y agoJava today is used and works fine for many high performance applications.
- bitcharmer 3y agoYes, I have no doubt about it. You might be stuck in 1990s perception of Java like a good portion of HN commenters who haven't had any real experience with it in the last 10-20 years.
- kaba0 3y agoYes they have, but you can always just go a “scope” higher, and instead of doing a loop that calls out to FFI, you call out to a loop itself.
- bitcharmer 3y agoYou mean expedite whole chunks of logic to a different language, then make your build process much more complicated by having to maintain a completely new ecosystem and compiler infrastructure and make testing more cumbersome? Sorry, but this is just a bad advice.
- kaba0 3y agoIn the very very rare case you might need it, than I guess, yeah. But if it turns out to be a real problem, it might still be possible that they will add a way to disable checks with the foreign memory API. It would actually allow for a better user experience, you could do “debug” builds with extensive checking for correctness, which could be disabled via some flag.
- pron 3y agoYes, 10% would be massive, but that's nowhere near the case. The vast majority of Unsafe-using programs would see no or negligible performance degradation and without the unsafety of Unsafe. The 0.01% of Java programs that would see a performance degradation of 10% or more will still be able to get it all back, if they feel it's absolutely needed at the expense of safety, by using JDK internals. That's a win for everyone.
- iscoelho 3y agoCitation needed. You make a lot of claims without evidence. Dropbox's experience https://dropbox.tech/infrastructure/lossless-compression-with-brotli https://dropbox.tech/infrastructure/lossless-compression-wit... shows a >10% performance difference caused by bounds checks in a similar context for a real world application. And before you say it: the Java JIT is not capable of optimizing bounds check elimination more than LLVM at this point in time. The JIT is not magical.
- pron 3y agoI think you misunderstand. There are cases where the performance hit would be significant, but there is absolutely no indication or reason to assume they're widespread. The JDK itself has switched away from Unsafe years ago (mostly except for cases it's not possible, but not due to performance, but technical reasons specific to the JDK alone) and performance overall has largely improved. In the special cases where there might be a performance hit, a single flag can take care of that, but we're concerned with improving the safety and performance of the ecosystem as a whole. If there's something that improves the average but harms some individual cases, we hide it -- as in this case -- behind a flag. Everyone who needs to be convinced that on average the benefit outweighs the cost has been convinced. It is those who think otherwise that would need to make a convincing case that on average Java applications will be harmed rather than helped.
- pjmlp 3y agoIt will be the difference between using Java, or the better suited low level coding features from C#, Go, Rust, assuming library parity for the task being solved. If after this change, Java is no longer able to compete in "The One Billion Row Challenge", it is a loss for the ecosystem.
- anonymoushn 3y agoJava is already at a significant disadvantage compared to native code for this vectorized string-parsing contest.
- pjmlp 3y agoWhy should it be, it provides the tools, as proven by the results. The matter is one of these tools is being taken away.
- anonymoushn 3y agoThe results are significantly behind other languages, in part because of instruction sequences that Java users cannot use. I agree that it's unfortunate to add an additional disadvantage, and this one seems particularly brutal, because people who write automated trading systems commonly use Unsafe to emulate arrays of structs, and MemorySegment is not a good substitute.
- MrBuddyCasino 3y agoGiven that automated trading systems are in fierce competition between each other, and thus have a never-ending thirst for tiny performance advantages, maybe the JVM with its emphasis on abstract high-level language constructs and runtime safety isn't the best platform and shouldn't bend itself into unnatural contortions to satisfy this niche? We've got Rust now, offering both low-level control and safety. No need to take the SUV on the racing track, it is not at home there.
- 3y ago
- jmaker 3y agoI’m all for trimming the stdlib and rectifying mistakes, but have you evaluated how much of the ecosystem, particularly the data processing systems, such as Kafka, Cassandra, Elasticsearch, HBase to name a few, depend on it? You say “integrated over all users”—whom are you referring to?
- pjmlp 3y agoPeople on those platforms are already adding C++ and Rust written alternatives with compatible networking protocols, if this goes badly, it will only accelerate the transition.
- jmaker 3y agoI’ve been using the C++ rewrites for a while and been enjoying it, are there also drop-in replacements in Rust now? Never happened to come across one, would be interested to learn more about it.