https://groups.google.com/forum/?hl=en-GB#!forum/jep-off-heap
What?
JEP = Java enhancement proposal. Unsafe = sun.misc.Unsafe a useful class that isn’t public. This is a forum for discussing making it public.
This was talked about a few months ago. You could fill out a form regarding how you used Unsafe, and what additional features were required for future functionality.
Never heard of this before. Can you please explain it to me? What uses does it has? If it’s private, why not use reflection to access it?
It’s not about accessibility. It’s about guaranteed availability.
[quote=“SHC,post:5,topic:48421”]
Dirty hacks. I’ve seen it used to do custom serialisation, exploiting its ability to instantiate an object without calling its constructor and to set the values of its final fields.
[quote=“pjt33,post:7,topic:48421”]
Or my latest hacky project: https://github.com/riven8192/LibStruct - true stack allocated structs - wouldn’t have been possible without sun.misc.Unsafe
A heck of alot of high performance libraries use Unsafe. You can reduce GC load by moving data off-heap. etc. etc.
Eh ???
Faulty network connection between brain and hands…corrected.
I don’t get it… I can access Unsafe normally, it’s a public class. I can normally use ‘Unsafe.getInstance()’. So, of what are you talking about?
Did you try that? It’ll give you a Security exception.
Oops, sorry, didn’t noticed that!
Well, I know that you are not talking about accesibility… but in case anyone want it, you can easily access the Unsafe class…
Field field = Unsafe.class.getDeclaredField("theUnsafe");
field.setAccessible(true);
return (Unsafe) field.get(null); // Return the Unsafe instance
It’s not that you can’t access it, it that can you always guarantee that you can access it? Currently Unsafe resides in sun.misc, and is not guaranteed to be present in any given JVM as sun.misc is not a part of the standard library. This JEP proposes making Unsafe a part of the standard library.
And in Android Unsafe lacks methods to read and write single primitives at abritrary addresses: putFloat, getFloat, etc. Making the API official forces every vendor to expose the same functionality.
Wild hair thought. Does android have the equivalent of Unsafe.defineClass ? Thinking: Allocate a large off-heap array (which probably lies about its size for range-checking). Then define a helper class with static methods 'like":
[icode] public static float[] asF(Object obj) { return (float[])obj; }[/icode]
which in JVM bytecodes is: [icode]aload_0; areturn;[/icode]. with the checkcast removed (aka now illegal and the reason a mechanism to load a class without verification). The bodies of all 'type conversions" are the same. You need the android IR equivalent. You can now access the data in the array without using the prim setters/getters.
(Humm…or just one: public static T asT(Object obj) { return (T)obj; } (EDIT: This doesn’t work because the checking of the type is in the caller and not the method itself.)
Well if it works for off-heap, it would work for on-heap as well (within range-check limitation).
Unfortunately Google is not really a Java Vendor, so I don’t know if this would help the situation on Android, would it?
[quote=“Roquen,post:17,topic:48421”]
When the GC moves it, you’re screwed. Either way, faking raw memory access by having huge ‘fake’ arrays (byte[], short[], int[], float[], long[], double[]), all pointing to the same memory address, is still no solution to mapping structs to a ByteBuffer, regardless of whether the GC will pull the rug from underneath you.
Off-heap the GC doesn’t come into play. On-heap: I can’t see a reason why it wouldn’t work. You only have references which are lying about their types and not raw memory addresses.