[foreign-memaccess+abi] RFR: MemorySegmentPool + Allocator [v9]

[Radoslaw Smogura]

On Fri, 23 Apr 2021 01:23:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> That's depressing to admit, but the slow size reading is not caused by external circumstances.
>> 
>> I was returning cached segment to the client using direct API.
>> 
>> This segment can have bigger size than requested (bucketing), and one allocated with malloc. So if upper bound of read was segment size more data could be read. So I have to admit it's a bug in test.
>
>> That's depressing to admit, but the slow size reading is not caused by external circumstances.
>> 
>> I was returning cached segment to the client using direct API.
>> 
>> This segment can have bigger size than requested (bucketing), and one allocated with malloc. So if upper bound of read was segment size more data could be read. So I have to admit it's a bug in test.
> 
> I see - but shouldn't the high level API resize the segment?
> 
> I think a more robust approach would be:
> 
> * drop the low level API
> * implement pool entries just in terms of a MemoryAddress (what has been returned by malloc)
> * when the pool is created, add a cleanup action, so that all the entries in the pool are "freed"
> * when clients request a segment, and an entry exists of matching size, take the address and create a sized segment from it with the right scope
> * as now, register a cleanup action on the requesting scope, so that the segments allocated are returned to the pool when closed

Hi @mcimadamore ,

I hope it looks more better. I wonder if you see some obvious issues here (I understand it's probably still not this stage to handle more complicated memory operations in Panama).

After finding issue with tests, a lot of things get simplified.

To summarize changes:
Dropped internal API

Result segment is created based on address (I miss a bit a fast way to create segment without checking scope - something like plain constructor call)

Added separated cleaner to clean pool on pool's scope closure - in case of implicate scope the hard reference to scope was kept via cleaner ref -> lambda to free method -> this -> scope. That's somehow quite fragile part for cleaner as it's easy to create memory leak.

I think I've found possible race in shared resource list (but put it in other thread) - if two add threads t1, t2 will start to race with close thread. They can leave list in following state cleaner2 -> cleaner 1 -> close marker.

While outcome will be t2 -> ok, t1 -> exception, cleaner -> cleans what was before.

Thanks for previews reviews & help,
Rado

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/509