
Java's Magic Sauce - wheresvic1
https://www.azul.com/javas-magic-sauce/
======
sreque
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.

~~~
bitmapbrother
>Not surprisingly, c# has succeeded where Java has failed in being cross
platform, used for instance in game development with the unity engine

C# succeeded in game development? That's its claim to fame? Being an optional
scripting language used by Unity? The real work is done by the graphics engine
that's written in C++.

>or multi platform mobile development via xamarin

Last time I checked the percentage of apps on the App Store and Google Play
that were written with Xamarin tools were so low that they barely even
registered.

~~~
ivm
It's not optional, it's the only language used in Unity by developers since
UnityScript got deprecated.

At least Google Play has more apps in Xamarin[0] than in ReactNative[1] but RN
is used in many top apps while Xamarin apps are mostly obscure.

[0]:
[https://www.appbrain.com/stats/libraries/details/xamarin/xam...](https://www.appbrain.com/stats/libraries/details/xamarin/xamarin)

[1]:
[https://www.appbrain.com/stats/libraries/details/react_nativ...](https://www.appbrain.com/stats/libraries/details/react_native/react-
native)

~~~
pjmlp
And even more in Java and C++ than those two summed up together.

------
kodablah
> 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.

~~~
vvanders
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
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
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#).

~~~
peterashford
The irony here is that although C# has had direct memory and structs available
for ages, Unity never took advantage of that - until just now - the in-
development ECS / C# Jobs / Burst compiler architecture is utilising packed
structs and manual memory allocation heavily. Why I say this is ironic is that
Unity/C# have succeeded _despite_ not using these features that you claim curb
Java's popularity in the same space

------
ram_rar
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
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/)

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

~~~
chrisseaton
\- 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
> Arrays are limited to around 16 GB

On HotSpot arrays are limited to 2 GB

~~~
pjmlp
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
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
> 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 ...

