[foreign-memaccess+abi] Integrated: 8264386: LibraryLookup should be more friendly with implicit unloading

[Maurizio Cimadamore]

Addressable main task is to unify MemorySegment and MemoryAddress, so 
that you can pass one where the other is expected.

It is also used by VaList.

In other words, it's something that all stuff that can be passed "by 
reference" implement (which, perhaps suggests a better name).

While we could go all minimal and drop the interface (note that this was 
recently debated in [1]), I'm not really sure what gain we would 
achieve. We have added it to avoid the proliferation of calls of the 
kind "segment.address()". If we remove that interface we'd be back to 
square one (e.g. have all the calls to MemorySegment::address be 
explicit). Adding more overloads (again, discussed in [1]) is a no go 
there, since if a method takes N address arguments you'd need 2^N 
overloads to cover all combinations.

(btw, a lot of these issues have to do with Java not having language 
support for implicit conversions - which means we have to "make do" in 
some other way).

Maurizio

[1] - 
https://mail.openjdk.java.net/pipermail/panama-dev/2021-March/012684.html


On 30/03/2021 05:00, Ty Young wrote:
> Is the Addressable interface still necessary after removing Symbol? 
> IIRC it was added to get a MemoryAddress from Symbol, MemoryAddress, 
> MemorySegment, and MappedMemorySegment in a unified way, however with 
> Symbol gone you either have a MemoryAddress already or you can just 
> call MemorySegment.address(). The MemoryAddress.address() method was 
> already silly with Addressable as you could redundantly create new 
> MemoryAddress objects that represent the same thing, but now there 
> doesn't seem to be any justification for it that I can tell.
>
>
> On 3/29/21 6:47 PM, Maurizio Cimadamore wrote:
>> On Mon, 29 Mar 2021 15:36:13 GMT, Maurizio Cimadamore 
>> <mcimadamore at openjdk.org> wrote:
>>
>>> Quoting from the PR:
>>>
>>> Dereferencing a segment from a LibraryLookup is possible, in the 
>>> following form:
>>>
>>> LibraryLookup libLookup = ...
>>> MemorySegment segment = 
>>> libLookup.lookup("foo").asSegmentRestricted(....)
>>>
>>> The above code has a problem: there is no link between the produced 
>>> segment and the original library lookup - meaning that, in 
>>> principle, it's possible for the library to be unloaded when 
>>> dereference occurs.
>>>
>>> After having discussed many alternatives with Jorn, the best way to 
>>> address this conundrum would be to add an overload of 
>>> `LibraryLookup::lookup` which takes a lyout and returns a segment.
>>>
>>> As part of this change I have also removed the LibraryLookup.Symbol 
>>> API which seems unnecessary - now you can lookup an address or a 
>>> segment. Of course, looking up a segment is creating a restricted 
>>> segment (so it should be treated as unsafe).
>>>
>>> I've added a test to make sure that the new API works as expected.
>> This pull request has now been integrated.
>>
>> Changeset: d70c1e40
>> Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
>> URL: https://git.openjdk.java.net/panama-foreign/commit/d70c1e40
>> Stats:     126 lines in 11 files changed: 48 ins; 30 del; 48 mod
>>
>> 8264386: LibraryLookup should be more friendly with implicit unloading
>>
>> Reviewed-by: psandoz, jvernee
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/panama-foreign/pull/480