[foreign-memaccess] RFR: JDK-8243284: Remove Foreign class
Henry Jen
henryjen at openjdk.java.net
Tue Apr 21 18:59:14 UTC 2020
On Tue, 21 Apr 2020 16:15:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
> The Foreign class is currently used for 3 methods:
>
> * withSize, which takes an unchecked address and gives it a size
> * asUnconfined, which takes an existing segment and turns it into an unconfined segment
> * asMallocSegment, which takes an unchecked address and converts that into a segment which can be closed, and where
> closed is mapped into "free"
>
> This patch replaces all these with this method:
>
> static MemorySegment ofNativeUnsafe(MemoryAddress addr, long bytesSize, Thread owner, AutoCloseable cleanup, Object
> attachment)
> Which is then moved directly into MemorySegment - so that we can garbage-collect the Foreign class.
>
> I've also made some changes on the JDK property - new name is simply "jdk.foreign" and I now made sure that it cannot
> be bypassed with a simple static initializer.
Mostly looks good to me, and I like the customizable cleanup routine. Given ability to derive a MS from another raises
the usual question of what to expect on calling close() method.
src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line 89:
> 88: s
> 89: .forEach(f -> sb.append(System.lineSeparator()).append("\tat ").append(f));
> 90: return null;
Is this format intentional? Also it seems to me this can be replaced with
StackWalker().getInstance().forEach()?
src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 494:
> 493: segment,
> 494: null);
> 495: * }</pre></blockquote>
In such use case, close() called on either segment will affect the other as well, correct?
I am assuming in use case like this, the new segment close is preferred to the old segment and developer most likely
should not keep reference to the old segment?
-------------
Marked as reviewed by henryjen (Committer).
PR: https://git.openjdk.java.net/panama-foreign/pull/122
More information about the panama-dev
mailing list