
Oracle doing a survey on sun.misc.Unsafe usage - pjmlp
https://blogs.oracle.com/dave/entry/do_you_use_sun_misc
======
delinka
Usage of the Java package sun.misc.Unsafe. For some reason, I was thinking
NNTP groups ...

~~~
pjmlp
After Java 8 gets released, the long due modularization will take place.

They plan to drop all private APIs people have been using, while providing an
upgrade path with public APIs.

Hence the survey.

~~~
MrBuddyCasino
I do hope they don't forget DirectBuffer, bug #4724038. This incantation is
required to unmap a memory-mapped FileChannel, which you need to do so that
you can delete it, because the OS of course locks it:

((sun.nio.ch.DirectBuffer) buf).cleaner().clean();

Apparently they didn't want to make it public because there is no portable way
to make it thread safe. Which is just great if you have to work with temporary
mmapped files...

------
kodablah
I'm sure a Maven mirror can give you enough JARs to do your own survey. I
don't believe a poll like this, unless really publicized, will be accurate.
Also, Unsafe (and maybe another one or two of the unpublic APIs) should have
an opt-in shim/polyfill that you can put in newer versions of the JDK/JRE
after these APIs are taken out.

~~~
mbreese
I doubt it. Any publicly available JAR shouldn't use a private namespace call.
However, private repositories in an Enterprise that has "standardized" on the
Oracle JVM is much more likely to use private methods. Hence the need for a
survey.

------
dave809
An interesting post on c++ like memory management in java:

[http://vanillajava.blogspot.ca/2014/01/sunmiscunsafe-and-
off...](http://vanillajava.blogspot.ca/2014/01/sunmiscunsafe-and-off-heap-
memory.html?q=unsafe)

~~~
AndrewBissell
This is also a good post, along the same lines: [http://mechanical-
sympathy.blogspot.com/2012/10/compact-off-...](http://mechanical-
sympathy.blogspot.com/2012/10/compact-off-heap-structurestuples-in.html)

~~~
acqq
The most interesting quote:

"Lately, I was comparing standard data structures between Java and .Net. In
some cases I observed a 6-10X performance advantage to .Net for things like
maps and dictionaries when .Net used native structure support."

The ".Net" can be much faster than Java because Java has to have the things on
the heap which can be on the stack.

~~~
pron
> The ".Net" can be much faster than Java because Java has to have the things
> on the heap which can be on the stack.

This is a famous fallacy (except in some very specific circumstances). The
reason for the performance difference is probably due to packed structures and
better CPU cache behavior.

Stack/heap makes very little difference in most circumstances for two reasons:
first, Java heap allocation is as fast as stack allocation – it is a thread-
local pointer bump. Deallocation for short-lived objects is free. You do incur
an indirect cost of triggering a young-generation GC which causes a pause
linearly related to the size of new-but-not-so-young objects. These pauses add
up to very little (under 1% of total time). The second reason is that stack
memory is usually a very small percentage of the total memory for interesting
programs. Programs manipulate data. Non trivial programs usually manipulate
lots of it, otherwise we wouldn't need so many gigabytes of RAM. A thread's
stack is rarely over a few megabytes in size, so to have a significant portion
of your data on stack you need tens of thousands of threads which the OS can't
handle anyway.

To sum up: 1) Java's handling of short-lived memory is extremely fast; 2) all
interesting data lives on the heap anyway.

Stack allocation can make a difference in reducing the number of young gen
GCs, but it's not a huge difference in most circumstances. Packing your heap
data structures better is more important.

~~~
bermanoid
I hear this sort of claim over and over again. Yet whenever I've had to
optimize Java code that does heavy math (particularly work with vectors,
matrices, complex numbers, etc) the number one optimization is to more or less
maintain my own small object stack, or manually put aside and reuse objects
within individual functions. We're talking 10x speed improvements by making
sure that garbage created per-iteration is near zero as opposed to just making
a mess and letting GC sort it out.

These are objects that have basically no-op constructors, and never stay live
for more than a method call, which makes me think that the observed speed
boosts must have something to do with GC. Am I missing something?

~~~
pron
Yes, vectors is one of those cases where stack allocation has a significant
advantage. This will hopefully be resolved (along with cache related issues)
when value types are introduced, hopefully in Java 9.

~~~
bermanoid
Sadly I'm not holding my breath. For the past ten years we've been upvoting
requests for value types, being told that they were not necessary because the
JVM was brilliant already, then after much argument and ample proof being told
that stack allocation in the JVM was a better solution, then having it
delayed, finding out that the implementation didn't really work that well,
etc. Sun has been pretty shit about prioritizing this issue, perhaps Oracle
will be better, but it's a far shittier company than even Sun was so I'm
skeptical.

It's also possible I'm jusy raging because this is a problem that has been
well known for well over a decade but has been played down by the folks in
charge of the JVM every time it comes up, even though it remains a real
problem with the platform.

~~~
pron
The difference is that this time you hear Doug Lea and Brian Goetz talking
about this as if it's definitely going into Java 9. This time it's not coming
from users but form Oracle. Also theres a JEP and a prototype by John Rose. In
fact, it is mention by Oracle as one of the first features of the core
platforms planned for 9. This has never been the case before.

------
gojomo
Oracle might want to offer a survey tool (rather than a SurveyMonkey) which
analyzes a codebase (or even optionally tallies dynamic usage).

The reports could in a standard format, and reviewed by respondents before
submission - letting the respondent add comments or elide sensitive info.

This could catch a lot more usage – including deep-hidden in third-party
libraries or old code.

~~~
pjmlp
They have a tool for you to use. It is called jdeps.

[http://download.java.net/jdk8/docs/technotes/tools/windows/j...](http://download.java.net/jdk8/docs/technotes/tools/windows/jdeps.html)

So you will have Java 8 timeframe to make your code behave nicely.

------
thepumpkin1979
I found a good article explaining all it's power. The Multiple Inheritance
trick is cool.

[http://mishadoff.github.io/blog/java-magic-part-4-sun-dot-
mi...](http://mishadoff.github.io/blog/java-magic-part-4-sun-dot-misc-dot-
unsafe/)

------
ivank
[https://github.com/search?l=java&p=1&q=sun.misc.Unsafe&ref=s...](https://github.com/search?l=java&p=1&q=sun.misc.Unsafe&ref=searchresults&type=Code)
(log in if you get throttled)

------
lhgaghl
LOL. I actually laughed IRL when I read the article title. Java is a language
that's supposed to have encapsulation. Now they are wondering if developers
are breaking encapsulation to the point that they need a survey? What a joke.

Java's like the language that's supposed to have encapsulation and types, but
actually has neither in practice. (everyone uses reflection / casting)

~~~
virmundi
I didn't down vote you, but I would like to take a moment to respond to your
statements.

The survey is due to some people such as library makers using this feature to
make really advanced, complex, rule-breaking things in Java. It wasn't
intended to get out, but it is. So Oracle, and by extension OpenJDK, want to
know what would happen if they got rid of it. Presumably they would replace it
with a more open API.

Now as to encapsulation and types not being used, I've seldom seen that be the
case pretty much ever. Normal developers will use casting, yes, but probably
not reflection directly. They will use libraries that will use reflection,
sure. For example, few on my team use reflection directly (I know, we've
talked, they've been confused because they've never done it). I'm the team
lead. I use it a lot. We have data parsers. That data needs to get mapped into
a canonical model. My code, the mapper factory, uses reflection and naming
standards and code generation to automatically pick the proper mapper based on
the inbound parsed object. So my code really does have an API of "interface
Converter:public Object mapper(Object)". Behind the scenes, using the
reflection API, the first step is to determine the parsed object's package.
Replace a keyword in that package to find another package for the mapper and
the reflectively load the mapper that implements that interface if it doesn't
exist. Thus the SingletonFactoryFactory of Java!

But following that scant 50-100 lines of code is about 15k of plan old,
getString->setString, auto-generated mapper code. Boring, encapsulated, typed.
And all of that allows me to know if the mapping documents the BAs created are
good. If they compile, they're good. If not, got to talk to the BAs.

