<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Hi Johannes,</div><div dir="ltr"><br></div><div dir="ltr">I think that this issue can be due to setData method called with on-heap and off-heap segments (if I see this well).</div><div dir="ltr"><br></div><div dir="ltr">Unfortunately JVM can’t perform memory operations fast for both kinds of pointers a.</div><div dir="ltr"><br></div><div dir="ltr">If this is a case try to “clone” setData method, to setNativeData, setDeweyData.</div><div dir="ltr"><br></div><div dir="ltr">Best regards,</div><div dir="ltr">Rado</div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On 14 Sep 2024, at 16:19, Johannes Lichtenberger <lichtenberger.johannes@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto"><div dir="auto"><span style="font-size:12.8px">Hello,</span><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto">I'm currently refactoring my little database project in my spare time from using a very simple byte[][] slots array of byte-arrays to a single MemorySegment (or two depending on if DeweyIDs are stored or not (usually not)):</div><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto">from</div><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto"><a href="https://github.com/sirixdb/sirix/blob/main/bundles/sirix-core/src/main/java/io/sirix/page/KeyValueLeafPage.java" style="text-decoration-line:none;color:rgb(66,133,244)">https://github.com/sirixdb/sirix/blob/main/bundles/sirix-core/src/main/java/io/sirix/page/KeyValueLeafPage.java</a><br></div><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto">to</div><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto"><a href="https://github.com/sirixdb/sirix/blob/1aaafd13693c0cf7e073d400766525eed7a24ad6/bundles/sirix-core/src/main/java/io/sirix/page/KeyValueLeafPage.java" style="text-decoration-line:none;color:rgb(66,133,244)">https://github.com/sirixdb/sirix/blob/1aaafd13693c0cf7e073d400766525eed7a24ad6/bundles/sirix-core/src/main/java/io/sirix/page/KeyValueLeafPage.java</a><br></div><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto">However, now I had to introduce reference counting / pinning/unpinning of the pages, and they have to be closed, for instance, once they are evicted from cache(s).</div><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto">Implementing a "real" slotted page with shifting and resizing... has gotten much more complicated. Furthermore (besides that, pinning/unpinning and deterministic closing is tricky ;-)) I'm also facing much worse GC performance (attached).</div><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto">Of course, I'm in the middle of refactoring, and I'd give the nodes/records in the page a slice from the MemorySegment of the page. Currently, I have to convert back and forth for serialization/deserialization from byte-arrays to MemorySegments, then copying these to the page MemorySegment... which is currently one issue, but I'm not sure if that's all.</div><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto">All in all I'm not sure if there's other stuff I'm missing because I'm now using `Arena.ofShared()` and I think this stuff is a bit strange:<br><br>[3,127s][info ][gc ] GC(7) Pause Young (Normal) (G1 Evacuation Pause) (Evacuation Failure: Pinned) 645M->455M(5124M) 9,563ms<br>[3,253s][info ][gc ] GC(8) Pause Young (Normal) (G1 Evacuation Pause) 783M->460M(5124M) 4,580ms<br>[5,094s][info ][gc ] GC(9) Pause Young (Normal) (G1 Evacuation Pause) 3524M->897M(5124M) 40,103ms<br>[5,200s][info ][gc ] GC(10) Pause Young (Normal) (G1 Evacuation Pause) (Evacuation Failure: Pinned) 1381M->947M(5124M) 29,005ms<br>[5,696s][info ][gc ] GC(11) Pause Young (Normal) (G1 Evacuation Pause) 1499M->1191M(5124M) 25,405ms<br>[5,942s][info ][gc ] GC(12) Pause Young (Normal) (G1 Evacuation Pause) (Evacuation Failure: Pinned) 1647M->1379M(5124M) 22,006ms<br>[5,979s][info ][gc ] GC(13) Pause Young (Normal) (G1 Evacuation Pause) (Evacuation Failure: Pinned) 1899M->1411M(5124M) 7,634ms<br>[6,628s][info ][gc ] GC(14) Pause Young (Normal) (G1 Evacuation Pause) 2243M->1801M(5124M) 36,093ms<br>[6,725s][info ][gc ] GC(15) Pause Young (Normal) (G1 Evacuation Pause) (Evacuation Failure: Pinned) 2469M->1873M(5124M) 13,836ms<br>[7,436s][info ][gc ] GC(16) Pause Young (Normal) (G1 Evacuation Pause) 2857M->2283M(5740M) 64,219ms<br>[7,525s][info ][gc ] GC(17) Pause Young (Normal) (G1 Evacuation Pause) (Evacuation Failure: Pinned) 3115M->2343M(5740M) 14,110ms<br>[8,274s][info ][gc ] GC(18) Pause Young (Normal) (G1 Evacuation Pause) 3659M->2783M(5740M) 42,159ms<br>[9,011s][info ][gc ] GC(19) Pause Young (Concurrent Start) (G1 Evacuation Pause) (Evacuation Failure: Pinned) 4027M->3239M(5740M) 51,686ms<br>[9,011s][info ][gc ] GC(20) Concurrent Mark Cycle<br>[9,165s][info ][gc ] GC(20) Pause Remark 4171M->2535M(5360M) 3,315ms<br>[9,446s][info ][gc ] GC(20) Pause Cleanup 2759M->2759M(5360M) 0,253ms<br>[9,448s][info ][gc ] GC(20) Concurrent Mark Cycle 436,601ms<br>[9,500s][info ][gc ] GC(21) Pause Young (Prepare Mixed) (G1 Evacuation Pause) 2783M->1789M(5360M) 30,267ms<br>[10,575s][info ][gc ] GC(22) Pause Young (Mixed) (G1 Evacuation Pause) 3745M->2419M(5360M) 73,025ms<br>[11,266s][info ][gc ] GC(23) Pause Young (Normal) (G1 Evacuation Pause) 3987M->2829M(5360M) 55,028ms<br>[11,762s][info ][gc ] GC(24) Pause Young (Concurrent Start) (G1 Evacuation Pause) 4149M->3051M(6012M) 65,550ms<br>[11,762s][info ][gc ] GC(25) Concurrent Mark Cycle<br>[11,869s][info ][gc ] GC(25) Pause Remark 3143M->1393M(5120M) 4,415ms<br>[12,076s][info ][gc ] GC(25) Pause Cleanup 1593M->1593M(5120M) 0,240ms<br>[12,078s][info ][gc ] GC(25) Concurrent Mark Cycle 316,410ms<br><br>I've rarely had these "Evacuation Failure: Pinned" log entries regarding the current "master" branch on Github, but now it's even worse. Plus, I think I'm still missing to close/clear pages in all cases (to close the arenas), which turned out to be tricky. I'm also storing the two most recently accessed pages in fields; sometimes, they are not read/put into a cache; there are page "fragments" that must be recombined for a full page...</div><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto">So maybe you know why the GC is much worse now (I guess even if I fail to close a page, I'd get an OutOfMemoryError or something like that, as the segments are off-heap (despite my array-based memory segments (ofArray), which may be a problem, hmm).</div><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto">All in all I faced a much worse performance with N-read only trxs traversing a large file in parallel, likely due to ~2,7Gb object allocation rate for a single trx already (and maybe not that much read from the page caches), that's why I thought I'd have to try the single MemorySegment approach for each page.</div><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto"><div dir="auto" style="font-size:large"><div dir="auto" style="color:rgb(136,136,136);font-size:12.8px"><div dir="auto">The G1 log:</div></div></div><div dir="auto" style="font-size:large"><br></div><span style="font-size:large"><a href="https://raw.githubusercontent.com/sirixdb/sirix/main/g1.log.4">https://raw.githubusercontent.com/sirixdb/sirix/main/g1.log.4</a></span><br></div><div style="font-size:12.8px" dir="auto"><br></div><div style="font-size:12.8px" dir="auto">kind regards</div><div style="color:rgb(136,136,136);font-size:12.8px" dir="auto"><div>Johannes</div><div dir="auto"><br></div><div dir="auto"><br></div></div></div></div>
</div></blockquote></body></html>