<div dir="auto"><div dir="ltr">Stupid question, but what's suggested is something like<div><br></div><div>`class Record(MemorySegment segment) {}`</div><div><br></div><div>and read from the MemorySegment or write to it, right?</div><div dir="auto"><br></div><div dir="auto">Would it make sense for a database project to eliminate GC work due to high allocation counts of objects, e.g., in an in-memory buffer? In my case in SirixDB, we currently have 1024 records per page at most, and a single writer per resource accumulates these pages in a simple map only visible to this transaction. Regarding GC, these potentially long accumulations, until the in-memory cache is made durable, have high costs (thus, it's better to, for instance, to sync after every 500_000th record instead of 5_000_000th record, even if we have enough memory. However, there's a tradeoff as syncing to disk after more data has been accumulated in a long-running auto-commit trx is better for parallel serialization of the pages into buffers.</div><div><br></div><div>With the off-heap memory due to the MemorySegment the instances are still created and the GC would have to mark the objects, or am I missing something? Maybe with value classes created on the stack it makes the big difference? :-)</div><div dir="auto"><br></div><div dir="auto">Kind regards</div><div dir="auto">Johannes</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Di., 8. Nov. 2022 um 11:44 Uhr schrieb Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank" rel="noreferrer">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">I believe adding Java syntax to model objects backed by memory segments <br>
might be pushing things a little too far. From a pedagogical perspective <br>
you would now have to explain to _every_ Java developers that there are <br>
two different kinds of objects, plain and native, and the rules which <br>
govern their access would be different (plain objects are <br>
garbage-collected, native objects are not).<br>
<br>
Seems like a nightmare, for a relatively little pay off. Note that, if <br>
you declare a record class with components X and Y, it is relatively <br>
easy to construct a function that can read a segment, with given struct <br>
layout into a record with matching components. I believe JPassport [1] <br>
does something in this direction. With something like this you get <br>
basically 90% of what you are aiming for, without the need to change the <br>
language by adding a new keyword, and making the programming model more <br>
complex for all the developers out there, including those who do not <br>
care about off-heap access.<br>
<br>
Cheers<br>
Maurizio<br>
<br>
[1] - <a href="https://github.com/boulder-on/JPassport/" rel="noreferrer noreferrer" target="_blank">https://github.com/boulder-on/JPassport/</a><br>
<br>
<br>
On 08/11/2022 06:52, Red IO wrote:<br>
> I just had a crazy idea on how to make foreign memory access work and <br>
> feel like java native class member access.<br>
> The idea is that you define special classes maybe with an interface or <br>
> a special class keyword. This class can then be "constructed" using a <br>
> MemorySegment being bound by its special and temporal bounds. The <br>
> object would be either null or every memory access throws an exception <br>
> when the bounds are breached. The class would be implicitly final and <br>
> would extend a class Native.<br>
> This could look something like this :<br>
><br>
> //c struct<br>
> typedef struct {<br>
> int x;<br>
> int y;<br>
> } Point;<br>
><br>
> //java native class<br>
> public native class Point {<br>
><br>
> int x;<br>
> int y;<br>
><br>
> //implicit and forced private constructor<br>
> //normal creation would make things difficult<br>
> }<br>
><br>
> MemorySegment data =... //native memory<br>
> Point p = data.object(Point.class);<br>
><br>
</blockquote></div>