<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Of course using native segments still incurs into some (hopefully
negligible) GC cost for maintaining these memory segment
instances.</p>
<p>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).</p>
<p>On the other side of the spectrum you might have applications
which desire to materialize a memory segment memory into an
immutable Java object - perhaps to expose it with saner API to the
outside world. In this case the GC will have of course to do more
work. Maybe escape analysis will help a little if these
allocations are short-lived and/or used in a structured way.
Valhalla will surely help in this regard, since you can declare a
value record:</p>
<p>```<br>
value record Point(int x, int y) { ... }<br>
```</p>
<p>Which you can construct from a segment (maybe a big shared
segment that contains other 1024 points). Thanks to Valhalla,
allocation of this Point object is cheap, and GC overhead might
still be small.</p>
<p>I believe having immutable views such as the one above is
superior to having instances wrapping a memory segment. Although,
in practice, you can still wrap the share memory segment (the one
with 1024 points) and store maybe an offset to the start of the
slice.</p>
<p>Also, once we have Valhalla, I believe MemorySegment will try to
take advantage of it. So MemorySegment could be a sealed interface
whose all implementations are de facto "primitive". With enough VM
magic, this might further reduce the cost associated with
allocating lots and lots of memory segment slices.</p>
<p>Maurizio<br>
</p>
<div class="moz-cite-prefix">On 08/11/2022 12:32, Johannes
Lichtenberger wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAGXNUvayWL+G7nOAzTQQpvHoTiovL09ApfvPhRmEDvDFVJaMaw@mail.gmail.com">
<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" moz-do-not-send="true" class="moz-txt-link-freetext">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://urldefense.com/v3/__https://github.com/boulder-on/JPassport/__;!!ACWV5N9M2RV99hQ!LjgyPEt1F69CBaEFf3KrF_sXMKLPtPvLSlTMxTTJ3ylEyKgPBUZl-PerIyVO_laZvfihmfvXU3Pdms5COZ79evl8Czl_iUXQ2g$" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">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>
</blockquote>
</body>
</html>