Off heap vs on heap memory access performance for a DBS

[Johannes Lichtenberger]

Hello,

I think I mentioned it already, but currently I'm thinking about it again.

Regarding the index trie in my spare time project I'm thinking if it makes
sense, as currently I'm creating fine granular on heap nodes during
insertions/updates/deletes (1024 per page). Once a page is read again from
storage I'm storing these nodes in a byte array of byte arrays until read
for the first time. One thing though is, that the nodes may store strings
inline and thus are of variable size (and thus, the pages are of variable
size, too, padded to word aligned IIRC).

I'm currently auto-committing after approx 500_000 nodes have been created
(afterwards they can be garbage collected) and in total there are more than
320 million nodes in one test.

I think I could store the nodes in MemorySegments instead of using on heap
classes / instances and dynamically reallocate memory if a node value is
changed.

However, I'm not sure as it means a lot of work and maybe off heap memory
access is always slightly worse than on heap!?

I'll check GC pressure again by logging it, but an IntelliJ profiler (async
profiler JFR) output of a run to store a big JSON file in SirixDB can be
seen here:
https://github.com/sirixdb/sirix/blob/refactoring-serialization/JsonShredderTest_testChicago_2023_07_27_131637.jfr

I think I had better performance/latency with Shenandoah (not
generational), but ZGC was worse in other workloads due to caffeine caches
and not being generational (but that's changing of course).

So, by looking at the profiler output and probably the flame graph where G1
work seems to be prominent do you think a refactoring would be appropriate
using MemorySegments or maybe it's an ideal "big data" use case for the
generational low latency GCs and the amount of objects is not an issue at
all!?

Kind regards
Johannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230728/f5cf8cf8/attachment.htm>