Foreign memory access with classes

[Gavin Ray]

I'm not sure how the JVM GC works, but I think that MemorySegment
allocation probably calls "malloc" somewhere down the line

malloc has an allocation threshold past which it delegates to mmap() -- (in
glibc, this threshold is 128KiB and adjusted dynamically based on alloc
patterns)
You can mmap() sort of an arbitrary amount of memory.

For instance, in the Umbra DB system, it's buffer pool uses a strategy
where it allocates some ~20 different buffer pool page sizes,
where each buffer pool page size takes up an arena that calls:

mmap(HALF_AVAILABLE_SYSTEM_MEM)

So you wind up with a total memory allocation of about x10 the system's
available memory
In theory, shouldn't this work the same with MemorySegments if you do large
allocations, because they should trigger mmap() calls?

On Tue, Nov 8, 2022 at 9:56 AM Johannes Lichtenberger <
lichtenberger.johannes at gmail.com> wrote:

> 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).
>>
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> In my day to day job I'm working on other stuff, so it might well be, that
> I'm missing something completely ;-)
>
> Kind regards
> Johannes
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221108/9c5e988c/attachment.htm>