Library for fast mapping of Java records to native memory • Hacker News Board

Re: Library for fast mapping of Java records to native memory

#11

Post by joe_mwangi » Mon, May 11, 2026, 8:56 PM UTC

matt_heimer wrote: post #8

What is the positioning for this and how does it work? A comparison to SBE might be nice. I understand the issue about using Layout and MemorySegment being verbose but the reason I'm using those things it to develop high performance software that uses off-help memory and bypasses object allocation. What does "map Java record types onto native memory" actually mean? Did you somehow turn a Java record into a flyweight…

I use c-struct layout. I should be more explicit in the readme. I use classfile api to generate bytecode during initialisation of the Mem and bytecode stored in cache in case if initialised again somewhere based on the same record type (I don't cache for records that are declared locally in a method). The class created from implementing Mem is a hidden class. So, basically, given a record, one can be able to analyse the layout based on record state description, and then for that Mem implementation (hidden class) we generate static final field varhandles + layout, segment is an instance field, and then generate bytecode the get and set to avoid reflection (actually, this is where most headache is in implementation). Go to the test package and see simple code for some adhoc rudimentary java (and native) files for benchmarks. Planning to test JMH benchmarks soon.

Re: Library for fast mapping of Java records to native memory

#12

Post by steve_barham » Mon, May 11, 2026, 8:59 PM UTC

I did something similar a few years back, with a slightly different approach to declaration, using interfaces to denote the layout of the struct. Mutation was opt-in by exposing setters using the (of the time) standard JavaBeans layout and an annotation processor took care of the codegen of an implementing class, which could be used where you wanted an on-heap box of an off-heap structure.

One benefit of this approach was that by using the interface as the type you could fairly easily support a flyweight pattern, reducing GC pressure when working with large off-heap collections. The parallels between stateless interfaces and offheap structs was also quite pleasing.

I'd love to see a similar effort using more modern techniques than Unsafe et al.

Re: Library for fast mapping of Java records to native memory

#13

Post by joe_mwangi » Mon, May 11, 2026, 9:01 PM UTC

fweimer wrote: post #9

joe_mwangi wrote: post #4

Earlier quoted context omitted.

Yup. Totally agree. Java does needs an array of structs. Hopefully value classes will help out through flattened array. But in future, one can use value records with this library with probable zero cost allocation. But the library doesn't use any reflection calls for get and set hence high performance as a result, and using records helps a lot with escape analysis. Planning to do some serious benchmarks soon. Some pr…

I doubt value classes will be helpful here because the array would have to be immutable. Context: https://openjdk.org/jeps/401

Yeaaah. You might be right. Hopefully we have this one day https://openjdk.org/jeps/8261007

Re: Library for fast mapping of Java records to native memory

#14

Post by joe_mwangi » Mon, May 11, 2026, 9:01 PM UTC

jayd16 wrote: post #10

At first glance it reminds me of C#'s Span .

Hahaha... inspired by it actually.

Re: Library for fast mapping of Java records to native memory

#15

Post by joe_mwangi » Mon, May 11, 2026, 9:02 PM UTC

PaulHoule wrote: post #7

joe_mwangi wrote: post #4

Earlier quoted context omitted.

Yup. Totally agree. Java does needs an array of structs. Hopefully value classes will help out through flattened array. But in future, one can use value records with this library with probable zero cost allocation. But the library doesn't use any reflection calls for get and set hence high performance as a result, and using records helps a lot with escape analysis. Planning to do some serious benchmarks soon. Some pr…

The thing I coded where I felt the weight of the GC the most was a chess engine in Java that needed transposition tables. Like using regular HashMap(s) or anything similar it was too slow to really speed up the engine. If my son had stayed interested in chess I would have coded up an off-heap transposition tables but he switched to guitar which changed my side projects.

Hope you come back. Would be cool to venture in this new data oriented programming phase java has invested a lot in.

Re: Library for fast mapping of Java records to native memory

#16

Post by c-fe » Mon, May 11, 2026, 9:16 PM UTC

This is very similar to SBE encoder/decoder flyweights over raw memory? What are the differences?

Re: Library for fast mapping of Java records to native memory

#17

Post by joe_mwangi » Mon, May 11, 2026, 9:18 PM UTC

steve_barham wrote: post #12

I did something similar a few years back, with a slightly different approach to declaration, using interfaces to denote the layout of the struct. Mutation was opt-in by exposing setters using the (of the time) standard JavaBeans layout and an annotation processor took care of the codegen of an implementing class, which could be used where you wanted an on-heap box of an off-heap structure. One benefit of this approac…

Interesting approach. I think Project Babylon did the same thing https://github.com/openjdk/babylon/blob/code-reflection/hat/...

I had tested it and it's quite fast. Actually, you don't need to generate any bytecode on the fly. Problem is when you deal with array as fields, implementation becomes difficult. You can revisit if interested to come back to such an implementation one day.

Re: Library for fast mapping of Java records to native memory

#18

Post by naxios_official » Mon, May 11, 2026, 9:18 PM UTC

steve_barham wrote: post #12

I did something similar a few years back, with a slightly different approach to declaration, using interfaces to denote the layout of the struct. Mutation was opt-in by exposing setters using the (of the time) standard JavaBeans layout and an annotation processor took care of the codegen of an implementing class, which could be used where you wanted an on-heap box of an off-heap structure. One benefit of this approac…

[flagged]

Re: Library for fast mapping of Java records to native memory

#19

Post by naxios_official » Mon, May 11, 2026, 9:20 PM UTC

steve_barham wrote: post #12

I did something similar a few years back, with a slightly different approach to declaration, using interfaces to denote the layout of the struct. Mutation was opt-in by exposing setters using the (of the time) standard JavaBeans layout and an annotation processor took care of the codegen of an implementing class, which could be used where you wanted an on-heap box of an off-heap structure. One benefit of this approac…

[dead]

Re: Library for fast mapping of Java records to native memory

#20

Post by spockz » Mon, May 11, 2026, 9:34 PM UTC

fweimer wrote: post #9

joe_mwangi wrote: post #4

Earlier quoted context omitted.

Yup. Totally agree. Java does needs an array of structs. Hopefully value classes will help out through flattened array. But in future, one can use value records with this library with probable zero cost allocation. But the library doesn't use any reflection calls for get and set hence high performance as a result, and using records helps a lot with escape analysis. Planning to do some serious benchmarks soon. Some pr…

I doubt value classes will be helpful here because the array would have to be immutable. Context: https://openjdk.org/jeps/401

Why does the array need to be immutable? Isn’t it enough to allocate the pessimistic max size of the record times the size of the array? In go slices work quite nicely to deal with “immutable” arrays and still be able to work on views on those arrays while keeping the same memory backing.