Pass unions by value with the C ABI's register classes - #9702
Conversation
union_spec.rb and UnionTest.c match the ffi gem's March 2026 versions without its JRuby skips; union_by_value_spec.rb adds mixed-class, nested, oversize and callback shapes.
Pick the libffi filler from the union's leaves: the float type for a homogeneous floating aggregate, per-eightbyte SSE/INTEGER cells on SysV x86_64, an integer of the union's alignment otherwise.
A 4-aligned union whose cells differ in class, nested at offset 4, takes the enclosing struct's eightbytes: (INTEGER, SSE) on SysV x86_64. Argument, return and callback forms.
libffi merges the cells into eightbytes at the union's offset inside an enclosing struct; a per-cell class is exact there and unchanged for a union passed on its own.
No behaviour change: the one-argument newUnion hands the host platform to the overload, which tests can call with any CPU and OS.
A union of one floating type is a floating-point aggregate on AArch64, ARM, PPC64 ELFv2 and x86_64; riscv64, loongarch64 and s390x pass every union in integer registers, so the integer filler must stay there.
riscv64, loongarch64 and s390x pass unions in integer registers while libffi would put a struct of doubles into FP registers; keep the integer filler there and the float one on AArch64, ARM, PPC64 ELFv2 and x86_64.
JRuby's FFI rejects :long_double layout members, so no union has a long double leaf or an alignment of 16; the integer filler list is now what its name says.
master names riscv64 as a CPU of its own (jruby-10.0 reports it as UNKNOWN); like s390x and loongarch64 it must keep the integer filler.
A failing assertion printed the jffi Type objects by identity; it now prints the cell names, so a wrong filler reads as SINT64 versus DOUBLE.
|
Thank you @aminmansuri for fixing this issue! It looks similar complex as ffi/ffi#1178 , so there seems to be no easier way to implement these unions. Libffi should directly support unions, IMHO. While implementing this, did you notice anything that should be ported back to or improved in the ffi project? |
|
Yeah. I agree that union support would simplify things. I think what would be most useful is:
|
|
Yeah all the platform-specific bits are clearly something that should live in libffi. In our case, I'm thinking most of that should probably move into jnr-ffi or jffi, but I haven't thought through it much yet. |
|
Here's the class in Java's FFM that handles union layouts: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/foreign/UnionLayout.html Eventually this will be moot once we finally land jnr-ffi support for FFM, but we're not there yet. @aminmansuri @larskanis if you're interested in the FFM-based jnr-ffi check out the branch here: https://github.com/jnr/jnr-ffi/tree/panama-22-unsquashed |
|
Would you take this in JRuby now and move it to jnr-ffi later, or should it go to jnr-ffi directly? |
|
@aminmansuri Let's get this merged in now so we have the functionality fixed in JRuby, and we can explore how to move this back into jnr-ffi in the future. |
3 participants
Fixes #9329.
Makes JRuby pass C unions by value the way a C compiler does.
Before, every 8-byte union went in an integer register, so a union of floats came back as garbage and a callback receiving one crashed the JVM.
Now the union's members decide the register class, on x86_64 and ARM64.
Same commits as #9693, rebased onto master as requested.