<div dir="ltr"><div dir="ltr"><div dir="ltr">On a related note, is there any way to do zero-copy reads from files using MemorySegments for non-Memory-Mapped files?<div><br></div><div>Currently I'm using "SeekableByteChannel" and wrapping the MemorySegment using ".asByteBuffer()"</div><div>Is this the most performant way?</div><div><br></div><div>========================</div><div><br></div><div><div>class DiskManager {</div><div>    private final RandomAccessFile raf;</div><div>    private final SeekableByteChannel dbFileChannel;</div><div><br></div><div>    public void readPage(PageId pageId, MemorySegment pageBuffer) {</div><div>        int pageOffset = pageId.value() * Constants.PAGE_SIZE;</div><div>        dbFileChannel.position(pageOffset);</div><div>        dbFileChannel.read(pageBuffer.asByteBuffer());</div><div>    }</div><div><br></div><div>    public void writePage(PageId pageId, MemorySegment pageBuffer) {</div><div>        int pageOffset = pageId.value() * Constants.PAGE_SIZE;</div><div>        dbFileChannel.position(pageOffset);</div><div>        dbFileChannel.write(pageBuffer.asByteBuffer());</div><div>    }</div><div>}</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 1, 2022 at 6:13 PM Johannes Lichtenberger <<a href="mailto:lichtenberger.johannes@gmail.com">lichtenberger.johannes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I think it's a really good idea to use off-heap memory for the Buffer Manager/the pages with the stored records. In my case, I'm working on an immutable, persistent DBMS currently storing JSON and XML with only one read-write trx per resource concurrently and if desired in parallel to N read-only trx bound to specific revisions (in the relational world the term for a resource is a relation/table). During an import of a close to 4Gb JSON file with intermediate commits, I found out that depending on the number of records/nodes accumulated in the trx intent log (a trx private map more or less), after which a commit and thus a sync to disk with removing the pages from the log is issued, the GC runs are >= 100ms most of the times and the objects are long-lived and are promoted to the old gen obviously, which seems to take these >= 100ms. That is I'll have to study how Shenandoah works, but in this case, it brings no advantage regarding the latency.<div><br></div><div>Maybe it would make sense to store the data in the record instances also off-head, as Gavin did with his simple Buffer Manager :-) that said lowering the max records number after which to commit and sync to disk also has a tremendous effect and with Shenandoah, the GC times are less than a few ms at least.</div><div><br></div><div>I'm using the Foreign Memory API however already to store the data in memory-mapped files, once the pages (or page fragments) and records therein are serialized and then written to the memory segment after compression and hopefully soon encyrption.</div><div><br></div><div>Kind regards</div><div>Johannes</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 1. Sept. 2022 um 22:52 Uhr schrieb Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 01/09/2022 19:26, Gavin Ray wrote:<br>
> I think this is where my impression of verbosity is coming from, in <br>
> [1] I've linked a gist of ByteBuffer vs MemorySegment implementation <br>
> of a page header struct,<br>
> and it's the layout/varhandles that are the only difference, really.<br>
><br>
Ok, I see what you mean, of course; thanks for the Gist.<br>
<br>
In this case I think the instance accessor we added on MemorySegment <br>
will bring the code more or less to the same shape as what it used to be <br>
with the ByteBuffer API.<br>
<br>
Using var handles is very useful when you want to access elements (e.g. <br>
structs inside other structs inside arrays) as it takes all the offset <br>
computation out of the way.<br>
<br>
If you're happy enough with hardwired offsets (and I agree that in this <br>
case things might be good enough), then there's nothing wrong with using <br>
the ready-made accessor methods.<br>
<br>
Maurizio<br>
<br>
</blockquote></div>
</blockquote></div></div>