On 23/01/2016 19:23, Uwe Schindler wrote:
:
What is the replacement for the following code (see marked BufferCleaner impl,
which is our abstraction): https://goo.gl/DGYZZj
The main reason why sun.misc.Cleaner was on the critical API list is NOT the
case that somebody wanted to implement their own cleaner as replacement for
finalization. The main reason (and this is *not* solved by the new APIs in
java.lang.ref.Cleaner) is to *force* unmapping of direct and mmapped byte
buffers.
JEP 260 was updated recently to move this to an open issue and I think
the text captures the issue correctly. Part of it that we can't have
types in java.base depending on types in other modules and this is why
Buffers can't have fields of type sun.misc.Cleaner or any type in sun.misc.
As has come several times, there are huge security and reliability
issues that arise when releasing or unmapping memory that is still
accessible via reachable objects. Proposed solutions over the years have
traded performance or were limited to platforms where we could
atomically remap. JDK 9 may be the time to try yet again or else just
introduce a JDK-specific API to unmap that comes with a warning in 96pt
font. It might have to be disabled completely when running with a
security manager. Alternatively the burden of the current hack could be
reduced by having Cleaner implement Runnable with a run method that
invokes clean. That would avoid needing to cast to a JDK-internal type
and so avoiding needing to use -XaddExports to break encapsulation.
-Alan.
