10 ms·

Java's Magic Sauce

108 points by wheresvic1 8y ago

kodablah 8y ago
> I’ll leave you with a question to ponder, would Java have been as successful as it has been had sun.misc.Unsafe not been hidden in the library code but still accessible? Yes, and it would have been as successful if Unsafe was never added. The language choice rarely hinged on this, it was just used to improve performance and could have been done natively if it had to.
- chrisseaton 8y ago
  > could have been done natively if it had to I don't think so. Do you mean by something like JNI? The use-cases of Unsafe that I see most often would not have been tractable using JNI. They rely on intrinsification. > it was just used to improve performance But to the point where Java is not suitable at all without the performance, so it's not a nice-to-have for some people, it's essential.
  - kodablah 8y ago
    The use cases I saw were memory alloc, but I admit not being too familiar with its common uses. The other uses I saw were just for perf improvement over existing synchronization/reflection approaches. While I agree that performance is often essential, I don't think the gains from unsafe measurably affected the language's success. Even without, the performance was still a draw compared to many other high level options. If anything, I do think it kept a bunch of libs from dipping into JNI.
- jsight 8y ago
  I tend to agree with you. Unsafe was great and useful, but Java was rarely used for the kind of things that would have been impossible without it. I think the real impact on its share was minimal, tbh. I'm glad that it is moving into a fully supported state, though.
  - doombolt 8y ago
    Java was rarely used for that kind of things, but now it is used widely. There's a new crop of Java databases, starting from Apache Cassandra and towards memory grids such as Apache Ignite or Apache Geode. And they benefit tremendously from access to Unsafe. Yes it's probably 1% of code ever written in Java by line count, but with potential of being 20-50% by CPU and RAM usage. It is sine qua non, a vital piece of infrastructure.
- vvanders 8y ago
  Hardly, I spent a lot of time in spaces where Java and others languages would be considered. If there was ever any hint if performance being a bottleneck we chose C++ over it. Even moreso because unsafe doesnt exist on some variants(Android). What unsafe gets you is good cache usage. JNI and other approches negate that benefit(also disables inlining and other things).
  - kodablah 8y ago
    We just have different experiences, as in a lot of shops I was in, performance was not the primary factor in language choice, but it could be its primary detractor of course if poor. Rarely did we ever find the bottleneck of the language the issue, and we dropped into JNI as needed (or more often reworked away from our original assumptions). I would say the majority of Java's success came from these kinds of shops, and the ones where performance made so much of a difference you would abandon the language altogether, I still doubt unsafe saved that abandonment from happening. This is not to say Unsafe was not appreciated by lots of places, esp wrt high performance libs, embedded dev, HFT shops, etc. But I don't believe that Unsafe really affected success/popularity of the language, heck, it's not even the most important pert of the performance story around the success/popularity of the language not to mention all the other non-performance-related aspects that really did affect its success.
    - vvanders 8y ago
      Not denying that Java is/was popular, just that it's popularity was curbed by the lack of value types, direct memory allocation(unsafe) and a few other performance sensitive features. The same reason that you see Unity dominate the game space is that the native interop and cache usage story is much clearer. FWIW JNI is not a silver bullet to performance problems by any means. The actual overhead of the JNI call either into or out of the VM is non-trivial and usually evicted whatever cache line you were touching. For things that are performance critical you'd usually see a drop of 10-50x between mixed JNI and code that was more cache aware but did the same work(in C++/C/C#).
      - 8y ago
sreque 8y ago
Oracle went the wrong direction with unsafe. Unsafe memory access is a feature of .NET and the CLR, not a hidden API where you get reprimanded by the community for using it. Not surprisingly, c# has succeeded where Java has failed in being cross platform, used for instance in game development with the unity engine or multi platform mobile development via xamarin. On the other hand, no one in the .NET community is complaining that their code is segfaulting all the time. The jdk API developers should not be granted a special API because they are more trustworthy than the rest of us "average" developers. Unsafe should be made public, not removed and replaced.
- jontro 8y ago
  Did you read the article? The point is that they have done this in java 9 with http://openjdk.java.net/jeps/193 http://openjdk.java.net/jeps/193
  - sreque 8y ago
    I read it, thanks. That wasn't the point of the article at all. Also, Variable handles only represent a small part of what unsafe is used for.
    - cogman10 8y ago
      Right, and they are just one example of unsafe apis moved into the public jdk. Oracle took a fairly measured approach here, they saw what was used and made public apis that are either clones of the private ones or that better capture common usage. That it took so long isn't great, but they are certainly going the right way.
      - didibus 8y ago
        I think OP means, how in C#, you have the unsafe keyword, which restricts unsafe usage to particular unsafe code blocks, and allows any unsafe operation to be contained.
  - _asummers 8y ago
yawaramin 8y ago
Can I just ask–why not do manual memory management with just arrays? Why Unsafe?
- guipsp 8y ago
  Arrays are stored on the gc while unsafe is off the gc
- chrisseaton 8y ago
  - You cannot get the native address of arrays in order to pass them to native code. - Arrays are subject to being moved by the GC, so even if you could get the address they could move. - Arrays are limited to around 16 GB, and that's if you're packing data into longs. - Accessing an array involves a bounds check, which may float out of a loop, but may well not. - Arrays cannot be allocated with memory that is anything except mapped private. I use Unsafe to put memory into a location where I can get a stable native address in order to make native calls using it. Using an array would not allow that.
  - needusername 8y ago
    > Arrays are limited to around 16 GB On HotSpot arrays are limited to 2 GB
    - pjmlp 8y ago
      Correct, however Hotspot isn't the only JIT compiler around in the Java world. At least J9, Azul and now Graal, and then there is the plethora of embedded ones, but those ones wouldn't be able to use that much memory anyway.
      - needusername 8y ago
        It's not a JIT problem, it's a VM problem. Graal uses the same VM with a different (or additional JIT) JIT and inherits the same (intentional) 2 GB limitations. While J9 can give you larger arrays AFAIK you're not guaranteed to get a single, contiguous memory region. You won't notice in Java but JNI criticals may return copies. I haven't tested Zing, but Zulu is just HotSpot.
johannes1234321 8y ago
> There are many ways you can use these methods that will return a result that is meaningless (if you’re lucky) or causes the JVM to stop abruptly (if you’re not). In my world I prefer a hard crash than me wingless results, which I then have a hard time reading down ...
ram_rar 8y ago
I see many of non-trivial java projects using UnSafe. At this point, why not make UnSafe a feature and let programmers use memory outside the purview of Garbage Collector ?
- pjmlp 8y ago
  I don't know, maybe because that is what Oracle is doing with Project Panama? http://openjdk.java.net/projects/panama/ http://openjdk.java.net/projects/panama/

108 points by wheresvic1 8y ago

> I’ll leave you with a question to ponder, would Java have been as successful as it has been had sun.misc.Unsafe not been hidden in the library code but still accessible? Yes, and it would have been as successful if Unsafe was never added. The language choice rarely hinged on this, it was just used to improve performance and could have been done natively if it had to.

chrisseaton 8y ago
> could have been done natively if it had to I don't think so. Do you mean by something like JNI? The use-cases of Unsafe that I see most often would not have been tractable using JNI. They rely on intrinsification. > it was just used to improve performance But to the point where Java is not suitable at all without the performance, so it's not a nice-to-have for some people, it's essential.
- kodablah 8y ago
  The use cases I saw were memory alloc, but I admit not being too familiar with its common uses. The other uses I saw were just for perf improvement over existing synchronization/reflection approaches. While I agree that performance is often essential, I don't think the gains from unsafe measurably affected the language's success. Even without, the performance was still a draw compared to many other high level options. If anything, I do think it kept a bunch of libs from dipping into JNI.
jsight 8y ago
I tend to agree with you. Unsafe was great and useful, but Java was rarely used for the kind of things that would have been impossible without it. I think the real impact on its share was minimal, tbh. I'm glad that it is moving into a fully supported state, though.
- doombolt 8y ago
  Java was rarely used for that kind of things, but now it is used widely. There's a new crop of Java databases, starting from Apache Cassandra and towards memory grids such as Apache Ignite or Apache Geode. And they benefit tremendously from access to Unsafe. Yes it's probably 1% of code ever written in Java by line count, but with potential of being 20-50% by CPU and RAM usage. It is sine qua non, a vital piece of infrastructure.
vvanders 8y ago
Hardly, I spent a lot of time in spaces where Java and others languages would be considered. If there was ever any hint if performance being a bottleneck we chose C++ over it. Even moreso because unsafe doesnt exist on some variants(Android). What unsafe gets you is good cache usage. JNI and other approches negate that benefit(also disables inlining and other things).
- kodablah 8y ago
  We just have different experiences, as in a lot of shops I was in, performance was not the primary factor in language choice, but it could be its primary detractor of course if poor. Rarely did we ever find the bottleneck of the language the issue, and we dropped into JNI as needed (or more often reworked away from our original assumptions). I would say the majority of Java's success came from these kinds of shops, and the ones where performance made so much of a difference you would abandon the language altogether, I still doubt unsafe saved that abandonment from happening. This is not to say Unsafe was not appreciated by lots of places, esp wrt high performance libs, embedded dev, HFT shops, etc. But I don't believe that Unsafe really affected success/popularity of the language, heck, it's not even the most important pert of the performance story around the success/popularity of the language not to mention all the other non-performance-related aspects that really did affect its success.
  - vvanders 8y ago
    Not denying that Java is/was popular, just that it's popularity was curbed by the lack of value types, direct memory allocation(unsafe) and a few other performance sensitive features. The same reason that you see Unity dominate the game space is that the native interop and cache usage story is much clearer. FWIW JNI is not a silver bullet to performance problems by any means. The actual overhead of the JNI call either into or out of the VM is non-trivial and usually evicted whatever cache line you were touching. For things that are performance critical you'd usually see a drop of 10-50x between mixed JNI and code that was more cache aware but did the same work(in C++/C/C#).
    - 8y ago

sreque 8y ago

Oracle went the wrong direction with unsafe. Unsafe memory access is a feature of .NET and the CLR, not a hidden API where you get reprimanded by the community for using it. Not surprisingly, c# has succeeded where Java has failed in being cross platform, used for instance in game development with the unity engine or multi platform mobile development via xamarin. On the other hand, no one in the .NET community is complaining that their code is segfaulting all the time. The jdk API developers should not be granted a special API because they are more trustworthy than the rest of us "average" developers. Unsafe should be made public, not removed and replaced.

jontro 8y ago
Did you read the article? The point is that they have done this in java 9 with http://openjdk.java.net/jeps/193 http://openjdk.java.net/jeps/193
- sreque 8y ago
  I read it, thanks. That wasn't the point of the article at all. Also, Variable handles only represent a small part of what unsafe is used for.
  - cogman10 8y ago
    Right, and they are just one example of unsafe apis moved into the public jdk. Oracle took a fairly measured approach here, they saw what was used and made public apis that are either clones of the private ones or that better capture common usage. That it took so long isn't great, but they are certainly going the right way.
    - didibus 8y ago
      I think OP means, how in C#, you have the unsafe keyword, which restricts unsafe usage to particular unsafe code blocks, and allows any unsafe operation to be contained.
- _asummers 8y ago

yawaramin 8y ago

Can I just ask–why not do manual memory management with just arrays? Why Unsafe?

guipsp 8y ago
Arrays are stored on the gc while unsafe is off the gc
chrisseaton 8y ago
- You cannot get the native address of arrays in order to pass them to native code. - Arrays are subject to being moved by the GC, so even if you could get the address they could move. - Arrays are limited to around 16 GB, and that's if you're packing data into longs. - Accessing an array involves a bounds check, which may float out of a loop, but may well not. - Arrays cannot be allocated with memory that is anything except mapped private. I use Unsafe to put memory into a location where I can get a stable native address in order to make native calls using it. Using an array would not allow that.
- needusername 8y ago
  > Arrays are limited to around 16 GB On HotSpot arrays are limited to 2 GB
  - pjmlp 8y ago
    Correct, however Hotspot isn't the only JIT compiler around in the Java world. At least J9, Azul and now Graal, and then there is the plethora of embedded ones, but those ones wouldn't be able to use that much memory anyway.
    - needusername 8y ago
      It's not a JIT problem, it's a VM problem. Graal uses the same VM with a different (or additional JIT) JIT and inherits the same (intentional) 2 GB limitations. While J9 can give you larger arrays AFAIK you're not guaranteed to get a single, contiguous memory region. You won't notice in Java but JNI criticals may return copies. I haven't tested Zing, but Zulu is just HotSpot.

johannes1234321 8y ago

> There are many ways you can use these methods that will return a result that is meaningless (if you’re lucky) or causes the JVM to stop abruptly (if you’re not). In my world I prefer a hard crash than me wingless results, which I then have a hard time reading down ...

ram_rar 8y ago

I see many of non-trivial java projects using UnSafe. At this point, why not make UnSafe a feature and let programmers use memory outside the purview of Garbage Collector ?

pjmlp 8y ago
I don't know, maybe because that is what Oracle is doing with Project Panama? http://openjdk.java.net/projects/panama/ http://openjdk.java.net/projects/panama/