Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Library for fast mapping of Java records to native memory

github.com

Post reply on HN
Print view View original

21–30 of 44 posts

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

#21

Post by joe_mwangi »

c-fe wrote: post #16

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

I have not used SBE but looking at it, my understanding is that it starts from an explicit schema, typically XML, and generates encoder/decoder flyweights over a binary buffer. That gives much more control to the user in terms of field order (very important), sizes. Here, TypedMemory takes a different starting point in which the Java record shape is the schema, and the library derives the FFM MemoryLayout/accessors from that. I think the difference is schema/codegen/protocol orientation vs Java-type/FFM/in memorylayout orientation.

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

#22

Post by traderj0e »

joe_mwangi wrote: post #15
PaulHoule wrote: post #7

Earlier quoted context omitted.

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.

I'm glad they saw the light. Last time I used Java was in high school when it was version 7, when it was pure OOP. Didn't even have lambdas. After I learned other languages, I didn't want to use Java again, seemed like a lot of boilerplate for something that didn't even give good performance.

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

#24

Post by cindyllm »

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.

[dead]

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

#25

Post by zmmmmm »

wood_spirit wrote: post #2

This is interesting. Java desperately needs an array of struct for type safe sugar over high performance arenas, but the areas you’d turn to this would be in a zero allocation effort where the cost of the this library’s off-heap and the object allocation in the getters and setters etc largely negate the advantages for a lot of use cases.

I find it weird that the people steering Java have been seemingly willing to sit out the use case high performance computation while it has so dominated the computing landscape. They are just patiently incrementally iterating on all these JEP's that would support dramatically improved capabilities and make Java a very attractive platform for ML - but they keep fretting over minor interface adjustments, cycle after cycle. I get there is a philosophy of keeping the language stable and well designed, but this is really taking it to an extreme in the face of missing an entire segment of computing.

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

#26

Post by [deleted] »

spockz wrote: post #20
fweimer wrote: post #9

Earlier quoted context omitted.

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.

[deleted]

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

#27

Post by kbolino »

spockz wrote: post #20
fweimer wrote: post #9

Earlier quoted context omitted.

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.

There's two problems as I see it.

The first is that value types themselves are immutable. This affects code generation and optimization. If you were to modify the value with unmanaged code then you may not observe the modification properly from managed code. Maybe this restriction will get relaxed, but I don't see that on any roadmap any time soon.

The second problem is that value types are still nullable. The flattened array is not going to be identical to a Go slice or a C# Span etc. because it has to track the nullness of each element. It seems they don't want to nail down the exact storage format for that yet, possibly to change it in the future, and possibly because they want to add language-level control over nullability eventually too.

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

#28

Post by PaulHoule »

traderj0e wrote: post #22
joe_mwangi wrote: post #15

Earlier quoted context omitted.

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

I'm glad they saw the light. Last time I used Java was in high school when it was version 7, when it was pure OOP. Didn't even have lambdas. After I learned other languages, I didn't want to use Java again, seemed like a lot of boilerplate for something that didn't even give good performance.

I use Java all the time for ordinary programming at work, I think it is great, but I'm not in a hurry to mess with stuff off-heap.

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

#29

Post by dionian »

traderj0e wrote: post #22
joe_mwangi wrote: post #15

Earlier quoted context omitted.

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

I'm glad they saw the light. Last time I used Java was in high school when it was version 7, when it was pure OOP. Didn't even have lambdas. After I learned other languages, I didn't want to use Java again, seemed like a lot of boilerplate for something that didn't even give good performance.

Java has always given good performance for most of my use cases. Like backend servers where startup time is mostly irrelevant.

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

#30

Post by J-Kuhn »

Inspired by this, I wrote a quick prototype using MethodHandle combinators: https://gist.github.com/DasBrain/19804df69c78cee257dd0294b00...

It doesn't have all the bells and whistles - so no support for annotations or arrays, but for ~2h of work, it shows what is possible without resorting to bytecode generation.

Post reply on HN