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

[Jorn Vernee]

On Wed, 10 Mar 2021 16:32:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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.
> 
> So the idea behind the change was to say that the copy will still be bound by the same allocation scope (which, if you think about it - it kind of makes sense); e.g. copy is a way to reuse the _same_ valist multiple times (e.g. obtaining a new cursor over the same data) - but not a way to duplicate the underlying data.

Ok. I was thinking more along the lines of being able to pick the allocation algorithm, but that is not supported any ways when creating a VaList. So it seems fine to delete this function, like you've done.

(thanks for the answer)

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

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