<div dir="auto"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Different applications might have different requirements re. how much GC allocation is considered "acceptable". In principle you can create a single big memory segment for each "page" and just peek and poke at memory through it, never materializing a single instance. If you do that, GC overhead will be fairly low (if any).<br></blockquote><div><br></div><div>That's not possible, IMHO. Initially, the pages, once instantiated, are "empty", thus no nodes/records are stored. Thus we'd need a growable MemorySegment somehow.</div><div><br></div><div>That said, the records/nodes themselves are causing GC pressure, as there are up to 1024 records per page. Thus, many objects are created (the pages themselves "only" have a 1/1024 ratio). It would be awesome to define a point where all the memory used by those objects on the heap magically disappears (as after serializing the objects and then the pages and clearing the in-memory map, they are not referenced anymore).</div><div><br></div><div>Thus, my idea was to provide small-sized MemorySegments for the records themselves, but I might have the same problem, that a MemorySegment has a fixed size / spacial bound.</div><div dir="auto"><br></div><div dir="auto">I think a queue as e.g. Chronicle Queue doesn't have this problem, because they do not accumulate data in-memory, but they merely write into the underlying memory mapped file directly.</div><div dir="auto"><br></div><div dir="auto">In my day to day job I'm working on other stuff, so it might well be, that I'm missing something completely ;-)</div><div dir="auto"><br></div><div dir="auto">Kind regards</div><div dir="auto">Johannes</div></div></div>