MemorySegment off-heap usage and GC

[Maurizio Cimadamore]

My opinions are based on partial understanding of how your framework 
works. To make actual actionable recommendation I'd need to play around 
with your repo a bit, which I might get around to do (or not, due to 
other stuff I have on the plate).

The high-level description of what you are doing seems sound - my 
comments were mostly focusin on the serialization/deserialization aspect 
- and it seems like the code right now is caught between state A 
(everything on-heap) and state B (everything off-heap). This 
intermediate state might well be the worst of both worlds - but that 
doesn't mean that your intuition on "state B is better than state A" is 
wrong.

Being able to slice off a big segment is a good thing.

As to go from byte[] to big memory segment, you can copy your byte[] 
into a memory segment (at desired offset) w/o need to make a new memory 
segment, or slice, using this:

https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/foreign/MemorySegment.html#copy(java.lang.Object,int,java.lang.foreign.MemorySegment,java.lang.foreign.ValueLayout,long,int)

If you do this, all the intermediate segment creation should be 
eliminated. At which point you are probably left with the "resizing" 
problem. E.g. how do you determine the size of the big memory segment, 
and how much time is lost in resizing and copying everything from 
scratch. If you are confident that this doesn't happen frequently, that 
simply using the copy method above might get you close enough to state 
B, at which point you might take another stab at comparing before/after.

Maurizio




On 18/09/2024 17:36, Johannes Lichtenberger wrote:
> That said it's some work for me to update all nodes, too, to work with 
> MemorySegments and to also change serialization/deserialization...if 
> you say it makes no sense, I can safe a lot of my spare time (and I'm 
> also a Software Engineer in my day to day job ;))