5 ms·

Thanks for the thorough explanation - you summarised the issue well, as well as explaining the impact and flow on effects. I have to say, I agree with the engi

by Daneel_ 11y ago

Thanks for the thorough explanation - you summarised the issue well, as well as explaining the impact and flow on effects. I have to say, I agree with the engineer.. I'm cringing just knowing this sort of practice is seen as acceptable, and it reinforces my distaste for Java. If you have to resort to insecure practices to achieve performance, there's something wrong with the framework.

alextgordon 11y ago
Reading this thread as C programmer has me scratching my head. Of course you have to resort to low-level functionality to achieve performance. That's how computers work. We can't all live in fuzzy wuzzy land. Surely Unsafe is safer than writing the whole thing in C and using JNI?
- trb8 11y ago
  Yes. Also there are many "safe" operations on "unsafe". Such as memory fences.
  - vardump 11y ago
    Multithreading is somewhat unsafe in general. And so is ability to do most I/O, you might overwhelm the system.
    - trb8 11y ago
      Sure. Unsafe in terms of program correctness. By that measure, new Thread() is unsafe. But that's not a reasonable definition of "unsafe". This could crash the JVM is a reasonable definition. And fences and ordered instructions cannot.
- Daneel_ 11y ago
  I completely agree - I have no problem with leveraging low-level functionality, but there's usually a safe and and unsafe way to approach it - and from what I've read 'unsafe' doesn't take the secure approach. (separately: why the downvote? I get downvoted for having the opinion that it's worth a tiny bit of performance for improved security?)
jakevn 11y ago
This sort of practice is present in the implementation of every mainstream programming language. 'Unsafe' operations are the bread and butter of computation. As far as use in libraries, you wont get the same performance without it in most of the places it is used. This is much like Python's 'unsafe' use of C modules for performance.
- dikaiosune 11y ago
  As a corollary, many Java programs rely really heavily on very thick layers of abstraction (in my day-to-day on a multi-node "enterprise" Java app I regularly see stack traces of 200-500 function calls), and it's important to keep each slice of those abstractions as thin as possible. As another reply pointed out, much better to do some hinky things with the JVM then to call out through the native interface every time you need high performance for a tight loop.

by Daneel_ 11y ago

alextgordon 11y ago

Reading this thread as C programmer has me scratching my head. Of course you have to resort to low-level functionality to achieve performance. That's how computers work. We can't all live in fuzzy wuzzy land. Surely Unsafe is safer than writing the whole thing in C and using JNI?

trb8 11y ago
Yes. Also there are many "safe" operations on "unsafe". Such as memory fences.
- vardump 11y ago
  Multithreading is somewhat unsafe in general. And so is ability to do most I/O, you might overwhelm the system.
  - trb8 11y ago
    Sure. Unsafe in terms of program correctness. By that measure, new Thread() is unsafe. But that's not a reasonable definition of "unsafe". This could crash the JVM is a reasonable definition. And fences and ordered instructions cannot.
Daneel_ 11y ago
I completely agree - I have no problem with leveraging low-level functionality, but there's usually a safe and and unsafe way to approach it - and from what I've read 'unsafe' doesn't take the secure approach. (separately: why the downvote? I get downvoted for having the opinion that it's worth a tiny bit of performance for improved security?)

jakevn 11y ago

This sort of practice is present in the implementation of every mainstream programming language. 'Unsafe' operations are the bread and butter of computation. As far as use in libraries, you wont get the same performance without it in most of the places it is used. This is much like Python's 'unsafe' use of C modules for performance.

dikaiosune 11y ago
As a corollary, many Java programs rely really heavily on very thick layers of abstraction (in my day-to-day on a multi-node "enterprise" Java app I regularly see stack traces of 200-500 function calls), and it's important to keep each slice of those abstractions as thin as possible. As another reply pointed out, much better to do some hinky things with the JVM then to call out through the native interface every time you need high performance for a tight loop.