This isn’t mine, but I just saw it on /r/programming and thought I’d share here.
Github: https://github.com/boundary/fasttuple
Blog post: http://boundary.com/blog/2014/05/15/dynamic-tuple-performance-on-the-jvm/
There’s been a lot of talk about value types and the like recently, and here’s another related development: heterogeneous primitive tuples bia bytecode generation. At least mildly ingenious, what do you guys think?
Not impressed. I doubt many people actually value this combination:
This feels like a step backwards from using ByteBuffer (and all its primitive getters and setters) directly.
Yeah, I felt it certainly wasn’t amazing, but an interesting take at it. I’d say your LibStruct is still the state of the art out of what I’ve seen yet, although they are geared towards different problems: SOA vs. AOS+Stack allocation.
My biggest issue with it is that they explain why boxes are bad for performance because of indirection and then immediately reveal that they’re making “boxes for several primitives are once.” I only main real benefit I see is that you can create VecN or similar dynamically by looping addField(), then it starts for become more like array-of-structs. But it’s still using heap allocation, so yeah…
SOA is not much use for OpenGL. Anyway, LibStruct is pretty much geared towards OpenGL, although, now, beyond basic mapping. We also have [icode]StructEnv.malloc(Vec3.class)[/icode] and [icode]StructEnv.free(…)[/icode], to avoid the hassle of purely stack allocated structs - as they have limited use - but it also has this awesome GC that never blocks. So it’s not just about AOS+SA any longer ^.^
awkward silence
Just like LibStruct, their FastTuple library will most likely have a user base of one. :point:
He is The One!
That said I plan on using LibStruct as soon as I have a use-case. 
I’m sure people would use it if they knew about it, although you may not want them to yet. At what point would consider it “mature” or otherwise ready?
This is also why I’ve been enjoying following Rust development, these issues are basically the core of the language. It’s shaping up to be very performant once they get LLVM to exploit everything.
So… Me? I’m using LibStruct a bit. xd
Yes, you, as I’m not using it, just developing it
I think most people read that as “The only one using it will be yourself”. =P
Yes, I realized that - it was meant to be our own little inside joke :point:
Anyway, pull the latest version, because the GC behind malloc/free just got 50x (!) faster: it can now collect 20M freed handles per second! Oh, and StructUtil.emptyArray(Vec3.class, length) was added.
Confirmed! I was mapping a huge ByteBuffer before to work around that, but saving that space is always nice. ^^
I’ve looked at your code…does that count? I’ve a mental block about anything that uses the ASM library for some weird reason.
It’s technically impressive, but I wouldn’t use it. I would just make do without value types until the next JVM alpha builds are available. I definitely trust the official JVM alpha builds over an amateur effort for correctness, stability, performance, and of course future compatibility. No one will use or support this once the JVM alpha builds have this functionality.
Notice that the linked github project and the linked blog post are all after the JDK architects started making public noise about value types being the next big JDK feature.
Famous JDK architect John Rose from Oracle went public with this on April 30:
https://blogs.oracle.com/jrose/entry/value_types_in_the_vm1
BTW, the big difference I see between Java value types and C# structs is the immutability constraint. In hindsight, the C# architects think allowing mutable structs was a bad idea:
Java, is fortunately doing it correctly from the start.
The tl;dr version quoted from C# senior architect Eric Lippert:
I don’t mind value types being immutable. What I do care about is that they don’t have identity - as in: you can’t reach them through a reference, which means you can’t map then, which means they are of little use in native libraries like OpenGL. We need headerless objects with controllable identity, IMHO.
Wouldn’t it be enough if the identity is only accessible at the native interop layer? They could add stuff to JNI (or the new interface they are planing?) and nobody would care in Java land.
Everybody dealing with performance and throughput cares a lot about configurable identity (it makes mapping possible).
Clarify. I know what maps are but I don’t see how the proposed immutable value types inhibit “mapping”.