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

[Maurizio Cimadamore]

On Wed, 15 Jul 2020 22:01:10 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> I think it's possible by creating a dummy segment when doing the copy on Windows. The dummy segment can then be used to
>> check if the VaList is alive or not, and we can also register it with the NativeScope so it gets closed by that. Feels
>> kinda hacky though.  A proper solution is probably to create a Resource abstraction that has a close() method, as well
>> as a way to transfer the resource to another owner (i.e. the NativeScope). Then we can have a register(Resource) method
>> on NativeScope that transfers the resource to the scope. One of the problems currently is that NativeScope doesn't call
>> the close() method of VaList, but the close() method of the MemorySegment that we allocate through it, so we have to
>> piggy back on the current NativeScope capabilities, or create an internal-only way of registering a VaList with it (the
>> latter feels kinda hacky again).
>
> I see FWIW I don't consider it that terrible to create a segment such as on construction
> MemorySegment segment = MemorySegment.ofNativeRestricted(addr, Long.MAX_VALUE, Thread.currentThread(), null, null);
> or on copy:
> MemorySegment segment = MemorySegment.ofNativeRestricted(ptr, Long.MAX_VALUE, Thread.currentThread(), null, null);
> for such purposes. It's reasonably self contained and requires no new abstraction. I do agree its awkward to treat this
> as a "unit", but if this problem is just constrained to va_list it may be ok.

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?

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

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