[foreign-abi] RFR: 8248420: Add a variant of VaList::make which takes a NativeScope [v3]

[Jorn Vernee]

On Thu, 16 Jul 2020 10:25:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> It seems to me that, no matter how we put it, either the behavior of close(), or isAlive() might end up being platform
>> dependent. To me, the fact that you can call close() but then isAlive is still "true" is a bit smelly; I guess an
>> exception (and a non-closeable view) would be more in spirit with the rest of the API.  But, if we don't want to
>> reinvent the wheel, we could simply have a `segment()` accessor (which could be `null`). And then the user might
>> interact with the segment directly if he so wishes. But again that would raise issues when it comes to specify which
>> access modes will the segment be created with (again, platform dependent).  I think that if we want to avoid platform
>> dependency, as Paul suggested, we could create fake segments that are used as temporal scopes - and make it so that
>> _every_ VaList has an associated segment (either real or fake), and can be closed independently. That said, one problem
>> I see with such an approach is that, for those platforms which do NOT require instantiation, a VaList copy has a
>> lifecycle which is really dependent on that of the VaList being copied, so, if the original VaList is closed, all the
>> copies should be inaccessible too. You could achieve something like this by using acquire() on the original segment,
>> maybe?
>
> Re-wrapping `ptr` on copy is problematic since we lose the lifetime safety of the original pointer, so if the original
> VaList is closed, we can do illegal accesses through the copy.
> What I mean is having an additional dummy memory segment for the copies, and then doing this when checking liveness:
> 
> if (dummySegment != null) {
>     return dummySegment.isAlive();
> return ptr.segment().isAlive();
> 
> In `close()` we also close this dummy segment when it's not null. But access is still performed through the original
> `ptr`, so if the underlying segment is closed, we get an exception.

Using acquire seems to be a possibility, but it puts a restriction on the order in which the VaList and it's copies are
closed. i.e. all copies have to be closed before the original can be closed.

This seems like the best solution so far though.

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

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