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?

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.

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":

publicstaticfloat[] asF(Objectobj) { return (float[])obj; }

which in JVM bytecodes is:

aload_0; areturn;

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

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.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Small usability problem with getting a raw address. The GC must be exactly tracking references so if the instance is moved after getting the address the reconstructed reference be foo-bared. (I just checked) Easy enough to shore up.

Had some trouble with multithreaded access in this regard. In between getting the address of a heap based object and writing the data to it - literally a couple of instructions later - the objects were being moved when I added another thread in to the mix.

I was trying to get some cache-friendly way of storing processed sprite vertex data actually inside the sprites themselves (as I was having to touch the sprites anyways whilst iterating through them). So I had a big chunk of vertex00, vertex01, vertex02, vertex03, etc floats in each sprite, and I'd stick a direct FloatBuffer window over them pointing at vertex00, and write the transformed data out there; next time I had to write the sprite out to a VBO I'd point the window at it and do a bulk FloatBuffer copy straight into the VBO.

Alas, when I started to add more threads, it would mysteriously glitch now and again, and after ruling out concurrency issues with the cheeky Unsafe hacks, it turned out that the underlying sprite objects were indeed moving at arbitrary moments after I'd pointed the FloatBuffer window at them. So I gave up on that idea.

So has anyone looked at how hotspot expands the various get/put methods after compiling?

BTW: Since I never stated my reservation about the llegal method + (edit: the tech doesn't matter) lie about type of the array is that the compiler will end up seeing after it inlines:

pointer integerArray = byteArray

so it's almost insured to eliminate 'integerArray' since it's simply an alias of 'byteArray'. Although it has all the information to still do the right thing, we're falling into an untested situation. However if in some instances accessing memory via an array is actually faster (like potentially where range-checks can be eliminated) then get/put, then there's a fall-back position of making the conversion more involved such that the compiler can't determine that the two pointers are aliases. Obviously it'd be nice if it does work with the alias elimination 'cause that'd be faster.

(EDIT: Oh and I added alternate lie-about-types methods into that playground code using riven's construction and a loop to nod about the GC maybe moving it)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org