But this all will disappear with Java 1.9, therefore it doesn’t give us anything what is available in the internal classes.
PS: Sorry but that is probably the most horrible code style I’ve ever seen 
+1! I’d have you hung by the toenails until sorry if you committed it looking like that.
Cas
Well, it is a truly unusual experience of revolution, after all.
My code path for OpenJDK and Oracle Java doesn’t rely on any classes removed in Java 1.9, it uses sun.misc.Cleaner which won’t be removed yet according to the JEP 260. I just wanted to point out that I’m not the only one who thought about a free() method for OpenJDK and Oracle Java. Some similar methods are in GNU Classpath, Apache Harmony and Android (see platform/libcore).
There is something wrong in my Eclipse settings, it mixes up the tabs and the space, the result is quite… horrible. Sorry.
Edit.: I’ve just edited the formatting settings, it should be less horrible now.
i gave it a try and rewrote the sun.misc.unsafe getByte(pointer), getChar(…), setByte(pointer,value), etc. into JNI and it turned out to be devastating.
micro tests looked good but a real-world-example, iterating over trees to write sequences to feed glDrawArrays etc turned out to run at 50% performance. memory access is already the bottleneck.
it surely is related to the intrinsic implementation of unsafe into the VM. 
isn’t JNA affected by that too ?
That’s the reason why JNI is no real solution. JNR does some tricks to spin native code at runtime to call the native function with less transition time. JNR is also the base for the new FFI in Java (Project Panama) and therefore, eventually, we get inlining right to the call itself. With cutom intrinsics that would be like heaven
I wonder how that is actually possible right now. I mean for any native library, be it JNR or anything else, there is only JNI to bridge the gap between Java and native.
Even JNR must use JNI to go from Java to native - whether or not that native is statically compiled or dynamically generated during runtime.
I see JNR only as a Java-friendly way to declare native functions and structures, and thusly it can be the basis for Project Panama on the API-side.
But on the inside, right now as it stands, it just - as any other JNI bridge - has to use JNI somewhere along the road to call into native.
Surely on the inside this will change with Project Panama.
Indeed, JNR uses LibFFI internally and you must go through JNI to invoke LibFFI functions. Details here.
[quote=“basil,post:85,topic:55436”]
This should have been pretty obvious, what were you trying to test exactly? If an alternative to Unsafe without VarHandles/Panama is viable?
I’m not Charles, so I guess the trick is that they pretty much prevent parameters from being passed and just transfer length and memory location, doing the unpacking of the parameters natively (probably the spinned native code). That means the JVM has to do way less translation between Java and C types.
Disclaimer: As I said I’m not Charly and I never worked with the internals of JNR, however for Panama it is a goal to inline everything right down to the native call into the JVMs jitted code and callsites.
@Spasi : yes, that was expectable. and yes, as an alternative. i wouldn’t have thought that the impact would be that big tho’ :-/
Very exciting )
IMHO: but examples code quality makes me cry
http://hg.openjdk.java.net/panama/panama/jdk/file/091cdacf28e5/test/panama/snippets/CPUID.java
http://pastebin.java-gaming.org/af8c110923c11
[spoiler]pss… it’s not only in examples such code[/spoiler]
With such code quality Java Doomed https://www.youtube.com/watch?v=fqcn_TPu4qQ
Can I have a TL;DR of this? What are the potential gains of this?
Faster JOML matrix operations -> higher FPS in WSW 
higher FPS in WSW
If this is not in the Java 9 change log I will be disappointed. 
[quote=“theagentd,post:93,topic:55436”]
The main benefit is that you don’t need JVM intrinsics anymore. Anything that required an intrinsic before can now be done by anyone. It works with raw machine code, so you have access to everything the hardware provides, for example vector instructions or the x86 PAUSE instruction for spin loops. Single instructions are not a problem (the worst-case for JNI).
[quote=“theagentd,post:95,topic:55436”]
Project Panama won’t make it to Java 9, even with the delayed schedule.
I know this topic is quite a bit older but it might still be interesting to somebody. Just gave a talk about the after-unsafe area and in-flight proposals. Obviously lots of information share the same base as the original post on infoq, anyhow the slidedeck has some more details in certain parts and will be updated more frequently when new proposals come around: http://de.slideshare.net/ChristophEngelbert/a-postapocalyptic-sunmiscunsafe-world
PS: What’s your opinion on JEP 286? http://openjdk.java.net/jeps/286 Did you vote already, if not please do, last day: https://www.surveymonkey.com/r/KGPTHCG
My thoughts are: Just yesterday I said java would never consider type inference.
I am absolutely not a fan of type declaration obfuscation - which is what they’re basically proposing here. When I read code I want to understand what assertions a programmer is making about the nature of the things they are dealing with and this “var” keyword does exactly the opposite: it lets the compiler figure it out for me (yay!) but then it hides all that extra rich information from my own internal brain compiler which I use to reason about code with (shit). It’s almost like the exact opposite of what generics was trying to achieve: List gives me information about the kinds of things that I’m expecting to have inside a list, where a plain List does not and the Java language correctly identified this as an area where we could add visible reasoning to our types instead of just hiding it all away.
What I would like to see is type inference to remove irrelevant casting:
String x = (String) thing.foo(); // What is the point of the (String) cast here?
might just as expressively be written
String x = thing.foo();
because the cast is implicit. Implicit casting can easily be inferred from the code and will fail at compile time from impossible casts eg. due to previous narrowing assertions on type.
Cas
Just yesterday, if you’d bothered to follow the link in my comment before responding you’d have found the JEP!
I think this whole proposal is horrible - it’s a needless reduction in verbosity which really reduces legibility. @noctarius, thanks for the SurveyMonkey link, I’ve registered my dislike. And, yes, I’m an old fuddy-duddy!
@princec - interesting you mention generics - I compared this to the diamond operator in my response, which I think is useful and reduces verbosity while maintaining intent. Not sure about your implicit casting. It’s not the impossible casts that bother me, it’s the unintended ones. Mind you, I remember seeing an idea for an instanceof block that combined that with implicit casting - that would be better.