Oracle doing a survey on sun.misc.Unsafe usage
blogs.oracle.com
blogs.oracle.com
They plan to drop all private APIs people have been using, while providing an upgrade path with public APIs.
Hence the survey.
((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...
It will show which APIs are being used, but not WHY they are being used.
http://vanillajava.blogspot.ca/2014/01/sunmiscunsafe-and-off...
"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.
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.
Stop and copy still has to traverse all objects that contain pointers, even ones in the nursery (otherwise you'd incorrectly free objects in the nursery that are only referenced by other objects in the nursery). So the amount of scanning you do is proportional to all objects in the nursery (also the size of your stack/root set), and only the copy is linearly related to objects to be tenured.
> The second reason is that stack memory is usually a very small percentage of the total memory for interesting programs.
A small percentage of the long-lived memory, sure. But programs spend a lot of their time working on ephemeral data, and this is precisely why the generational hypothesis holds. There's no faster nursery than the stack: allocation fits nicely into the function prolog and deallocation requires no traversal of interior pointers.
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?
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.
If you haven't witnessed these effects I suspect it's only because you haven't had the reference to compare with.
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.
http://download.java.net/jdk8/docs/technotes/tools/windows/j...
So you will have Java 8 timeframe to make your code behave nicely.
http://mishadoff.github.io/blog/java-magic-part-4-sun-dot-mi...
Java's like the language that's supposed to have encapsulation and types, but actually has neither in practice. (everyone uses reflection / casting)
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.