[foreign-memaccess] [Rev 01] RFR: JDK-8243284: Remove Foreign class

[Maurizio Cimadamore]

On Wed, 22 Apr 2020 09:34:58 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * simplified API to take Runnable instead of AutoCloseable
>>   * renamed all occurrences of "unsafe" with "restricted" (e.g. as in "restricted foreign")
>>   * cleaned up the code which performs the restricted access check
>
> Marked as reviewed by sundar (Committer).

> 
> That's a lot of arguments. Could simplified overrides be provided too?
> For example:
> 
> static MemorySegment ofNativeUnsafe(MemoryAddress addr, long bytesSize,
> AutoCloseable cleanup)

The point of this API is to provide a very general way to construct any kind of native segments. I understand there are
many arguments - but then you have a tradeoff between having multiple unsafe API points vs. just one, and I'm not sure
that usability is the main concern when stepping onto the unsafe path. This is mostly to allow devs to link their own
custom allocators with memory segments, so I don't think the extra arguments should be a big issue (but lack of
generality could be).

As for providing pre-baked Runnable cleanup actions, I thought about that and I also thought that we should keep in
mind what will happen once we have the ABI work - having a call to "free" won't require writing any JNI code, so by
putting these pieces together it should be possible to implement pretty much any behavior.

In terms of usability, I think having a 'resize' method on (unchecked) MemoryAddress would probably be the most
appealing choice. For now I think there is a certain appeal in keeping the number of unsafe entry points as low as
possible, so that the user can reason about them.

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

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