Foreign memory access with classes

[Johannes Lichtenberger]

Stupid question, but what's suggested is something like

`class Record(MemorySegment segment) {}`

and read from the MemorySegment or write to it, right?

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.

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? :-)

Kind regards
Johannes



Am Di., 8. Nov. 2022 um 11:44 Uhr schrieb Maurizio Cimadamore <
maurizio.cimadamore at oracle.com>:

> I believe adding Java syntax to model objects backed by memory segments
> might be pushing things a little too far. From a pedagogical perspective
> you would now have to explain to _every_ Java developers that there are
> two different kinds of objects, plain and native, and the rules which
> govern their access would be different (plain objects are
> garbage-collected, native objects are not).
>
> Seems like a nightmare, for a relatively little pay off. Note that, if
> you declare a record class with components X and Y, it is relatively
> easy to construct a function that can read a segment, with given struct
> layout into a record with matching components. I believe JPassport [1]
> does something in this direction. With something like this you get
> basically 90% of what you are aiming for, without the need to change the
> language by adding a new keyword, and making the programming model more
> complex for all the developers out there, including those who do not
> care about off-heap access.
>
> Cheers
> Maurizio
>
> [1] - https://github.com/boulder-on/JPassport/
>
>
> On 08/11/2022 06:52, Red IO wrote:
> > I just had a crazy idea on how to make foreign memory access work and
> > feel like java native class member access.
> > The idea is that you define special classes maybe with an interface or
> > a special class keyword. This class can then be "constructed" using a
> > MemorySegment being bound by its special and temporal bounds. The
> > object would be either null or every memory access throws an exception
> > when the bounds are breached. The class would be implicitly final and
> > would extend a class Native.
> > This could look something like this :
> >
> > //c struct
> > typedef struct {
> > int x;
> > int y;
> > } Point;
> >
> > //java native class
> > public native class Point {
> >
> > int x;
> > int y;
> >
> > //implicit and forced private constructor
> > //normal creation would make things difficult
> > }
> >
> > MemorySegment data =... //native memory
> > Point p = data.object(Point.class);
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221108/43bb443b/attachment-0001.htm>