Store records in off-heap memory

[JohannesLichtenberger]

In order to keep GC to a minimum (despite of low latency Garbage Collectors as for instance Shenandoah), we could try to store the records/nodes off-heap using the foreign memory API for instance, and compare performance.

[JohannesLichtenberger]

Probably we should simply store the trx intent log in a Chronicle map instead of a simple HashMap.

[JohannesLichtenberger]

https://minborgsjavapot.blogspot.com/2019/07/java-chroniclemap-part-1-go-off-heap.html

Should'nt be hard to implement.

[abhinax4991]

Hey @JohannesLichtenberger Guten tag , would like to work on this can you please assign this to me.

[JohannesLichtenberger]

@abhin-dynamify I wonder if serialization of page (fragments) and deserialization will be an issue and if it's faster or even slower. Same for Caffeine caches (the lightweight buffer manager)... that said, with the Caffeine caches, if the maximum sizes are too large, I've had severe performance issues regarding the GC (especially with the ZGC, apparently maybe because it is not generational yet).

[JohannesLichtenberger]

We can try and compare performance in a separate branch 👍

[JohannesLichtenberger]

@abhin-dynamify hope it makes sense. Do you work on this?

[abhinax4991]

@abhin-dynamify hope it makes sense. Do you work on this?

yeah i am working on it

[JohannesLichtenberger]

@abhin-dynamify did you have time?

[Sung-Heon]

@JohannesLichtenberger Can I try this?

[JohannesLichtenberger]

In the KeyValueLeafPage, we store the slots as a byte array of byte arrays. Maybe we could instead use a single MemorySegment which may have to grow.

[JohannesLichtenberger]

@Sung-Heon still interested?

[Sung-Heon]

Yes~!

[JohannesLichtenberger]

We currently have a way too high allocation rate, I think (2,7Gb/s with a single read-only trx). Can you try to replace the slots byte[][] array in KeyValueLeafPage with a single MemorySegment?

[JohannesLichtenberger]

We probably need an indirection array at the start of the page though with offset/lengths. Furthermore, the pages are variable sized, so the MemorySegment might have to be reassigned with a bigger one, copying all data. Also, for instance if variable sized data as Strings are reassigned and bigger as before... getting a bit tricky.

[JohannesLichtenberger]

You can probably join the Discord channel.

[JohannesLichtenberger]

@Sung-Heon do you have experience with this or database architecture stuff in general? It's of utmost importance to change this to reduce allocation pressure, I'd otherwise assign it to myself.

The records perhaps should be backed by MemorySegments, too. Once a new record/node is created it should be serialized to the backing MemorySegment, which in turn should be set as the slot data as part of the large page MemorySegment. We can probably read from the MemorySegment directly, too, at least most stuff...