Method to unmap MappedByteBuffer

[Alan Bateman]

On 07/01/2019 12:11, Luke Hutchison wrote:
> :
>
> On (2): In JDK 9+, this method gives an ugly (and unsuppressable) "An 
> illegal reflective access operation has occurred" warning on stderr.
If you are using core reflection to invoke 
sun.nio.ch.DirectBuffer.cleaner() then you will get a warning on first 
usage. This warning is to make developers aware that their code will 
break once java.base is fully encapsulated and sun.nio.ch.* types cannot 
be accessed. You can use the --add-exports option to temporarily export 
sun.nio.ch, this will suppress the warning.

> You can instead call sun.misc.Unsafe.invokeCleaner(buf) , and that 
> makes the same call shown above in (2), without the warning. But it 
> appears that sun.misc.Unsafe is going away.
I'm not aware of any proposal to remove sun.misc.Unsafe. Some of the 
reasons to use Unsafe went away when VarHandles was introduced in JDK 9 
but there are several other cases, particularly with off-heap access, 
that will need projects such as Panama to be integrated before there can 
be many significant pruning of Unsafe.  There were a number misleading 
blogs and articles about this during JDK 9, I think some of the articles 
were written before JEP 260 was published (or the writers didn't fully 
grok JEP 260).

> Most of the calls in that class have been directly proxied to 
> jdk.internal.misc.Unsafe , with one exception: the 
> invokeCleaner(ByteBuffer) method is not proxied across to 
> jdk.internal.misc.Unsafe , and there is no corresponding method 
> jdk.internal.misc.Unsafe::invokeCleaner . *Was that an intentional or 
> unintentional omission?*
Intentional. It was added to sun.misc.Unsafe as a convenience but you 
have to super careful using it as you can easily crash the VM or 
introduce security or reliability issues by releasing or unmapping 
memory for buffers/memory-mapping that are reachable. You'll need to go 
back through the archives of core-libs-dev and jigsaw-dev to find the 
discussion on this.

>
> Right now solution (2) necessitates a "requires jdk.unsupported" line 
> in the module descriptor. *What are the ramifications of depending 
> upon jdk.unsupported*, other than that your code may not work on 
> future JDK versions? For example, I saw somewhere that callers of any 
> library that depends upon a dependency like jdk.unsupported may have 
> to add --add-modules=ALL-DEFAULT to their runtime to work?
The jdk.unsupported module is resolved by default when running code on 
the class path. If you are deploying everything as modules on the module 
path then the module that makes use of sun.misc.Unsafe will `requires 
jdk.unsupported`. I don't know what you were reading but it might have 
been someone running with a library that uses sun.misc.Unsafe but it was 
deployed as an automatic module. In that case you might need 
`--add-modules jdk.unsupported` then no module explicit requires it.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190107/1d099e64/attachment.html>