Status of Riven's LibStruct?

Engines, Libraries and Tools
#1

Does anyone know the current status or details of Riven’s “LibStruct” project? (github: https://github.com/riven8192/LibStruct, original forum post: http://www.java-gaming.org/index.php?;topic=34282.0)

Obviously it hasn’t been updated in a while, but I would LOVE to integrate this or something similar into my current project. A reply from him himself would be miraculous… (unfortunately PMing appears to be broken atm.)

Specifically, I’m wondering if there are any major caveats as to why I wouldn’t use this in Java 8. For larger classes I could see issues, but for simple vector-like objects this would make my life so, SO much easier. Naturally, I’m not really able to wait 2-4 years for Project Valhalla to be released (http://openjdk.java.net/projects/valhalla/). Otherwise, my use cases are: small vector-like objects, and uniform-buffer updates in OpenGL 3+, for which this seems absolutely perfect.

This is, of course, for a game being developed semi-professionally in Java. (Demo: https://youtu.be/dInNbVjta5M) If Riven happens across this, I would love to get in touch with him!

#2

I’d say you’re chances of him running across this post are quite high (probability approaching 1).

#3

[quote=“Frizzil,post:1,topic:57484”]
Good luck with the cancer treatments!
Your engine is very, very pretty!

It’s worth noting that Riven in the owner/admin of JGO so it’s very likely that he’ll come across your post at some point.

#4

Ah crap, I forgot I talked about that in the video, haha. Yeah, chemo ended a few months back, scan recently came back clean, so no worries. But thanks!

#5

:persecutioncomplex:

LibStruct basically has these advantages:

  • zero-copy
  • zero-garbage
  • convenience (on sourcecode level)

The disadvantages are:

  • struct values are never pushed into registers by HotSpot
  • structs are not eligible for escape analysis
  • struct I/O is never reordered by HotSpot

There are quite a few pitfalls when using LibStruct:

  • a NPE or AIOOBE turns into a segfault/memory-access-violation
  • structs must never be used as objects (like adding them to a Collection, or in general: passing them to a function accepting a java.lang.Object)
  • conceptually wrong struct code but valid Java code can be rather hard to debug, as the JVM typically crashes.

As to come back to the original post: LibStruct is currently frozen, as the number of users is zero (me included).

#6

I see, well thank you for the insight. I’m basically trying to avoid young-gen-worthy allocations so the GC doesn’t invoke, so I think this would do nicely. I may also look into tuning young-gen, but my research on the subject has not convinced me that I can get it reasonably fast (< 2-3 ms).

When you say structs don’t get pushed into registers, do you mean that even the individual fields don’t get pushed? I assumed that declaring a struct was semantically equivalent to declaring all of its fields in place. Otherwise, I have no expectations of this pushing entire structs into SIMD registers or anything. (Bytecode has no way of representing this, to my knowledge.)

I’m guessing the best way to support OpenGL uniform buffer updates would be to “map” ByteBuffers as the desired structs, purely for the purpose of setting named fields?

Thanks for the hasty response. I get that LibStruct is inherently, er, risky, but I’m amazed that it even exists. I wonder how the folks working Project Valhalla would react if they knew about your library :slight_smile:

EDIT: Also, an amazing idea occurred to me… I’m betting a Minecraft mod that utilized your library could solve a massive amount of the game’s performance problems. It’d be a good stability test (lots of users), to see how viable the library is in a production environment.

#7

Let’s say you have this code:


thing.a = vec.x * -1;
thing.b = vec.y * 2;
thing.c = vec.x * -3;

With POJOs, [icode]vec.x[/icode] will be stored into a register after the first read, with structs however, the memory (or L1-cache in this case) will be read twice.

As for the reordering: with POJOs, HotSpot will very likely swap line 2 and 3, whereas it won’t with structs.

Both factors can result in a slowdown, depending on the bottleneck.