7 ms·

> "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 backward

> "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 ago
Where it matters, you can just write that part in a low-level language and call out to that.
- yjftsjthsd-h 3y ago
  Thus 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 ago
    FFI boundaries are inherently unsafe regardless of language.
  - kaba0 3y ago
    But 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 ago
      Copying is safer but bad performance, so I'm not sure how that helps here?
  - pron 3y ago
    You 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 ago
  Or 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 ago
  This 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 ago
      Java today is used and works fine for many high performance applications.
    - bitcharmer 3y ago
      Yes, 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 ago
    Yes 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 ago
      You 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 ago
        In 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 ago
Yes, 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 ago
  Citation 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 ago
    I 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.

> "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 ago

Where it matters, you can just write that part in a low-level language and call out to that.

yjftsjthsd-h 3y ago
Thus 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 ago
  FFI boundaries are inherently unsafe regardless of language.
- kaba0 3y ago
  But 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 ago
    Copying is safer but bad performance, so I'm not sure how that helps here?
- pron 3y ago
  You 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 ago
Or 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 ago
This 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 ago
    Java today is used and works fine for many high performance applications.
  - bitcharmer 3y ago
    Yes, 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 ago
  Yes 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 ago
    You 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 ago
      In 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 ago

Yes, 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 ago
Citation 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 ago
  I 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.