RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

[Alan Bateman]

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.