3 ms·

> 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

> 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

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