[foreign-memaccess+abi] RFR: 8263018: Improve API for lifecycle of native resources [v2]

[Maurizio Cimadamore]

On Wed, 10 Mar 2021 14:58:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 602:
>> 
>>> 600:         /**
>>> 601:          * Returns the resource scope associated with this instance.
>>> 602:          * @return the resource scope associated with this instance.
>> 
>> Why was this method removed? Doesn't it make sense to specify an allocator for the copy? (if it needs to allocate)
>
> I think when I looked at it in depth, having the scope didn't seem to have any effect in there - but I'll need to double check.

I double checked - I think the problem is that some implementations need to allocate, some don't. On SysV and Aarch, it seems to make sense to pass a scope, since you can actually create a new VaList, with a completely different scope. But on Windows? It seems like we're just creating another instance, backed by the same segment - so it's not clear how the scope would be used here. In other words, on Windows, the specified scope will say nothing about the lifecycle of the copy.

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

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