RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

[Mandy Chung]

Hi Peter,

> On Apr 5, 2016, at 7:41 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> The bottom line is that we need a mechanism that:
> 
> - triggers reference discovery when native memory limit is approached or reached
> - retires native memory reservation at appropriate time slots until succeeding or until all pending references have been processed and Cleanables executed at which time native memory reservation can fail with OOME.
> - if possible, doesn't execute cleanup functions by the allocating thread but just waits for system threads to do the job.
> - when triggered, does not make native memory allocation a bottleneck.
> 
> I think that what I did in my latest webrevs with ReferenceHandler thread is an improvement in minimizing contended synchronization and interference of allocating thread(s) with Reference enqueue-ing. But interaction of allocating thread(s) with Cleaner background thread could be improved and I have a couple of ideas to explore.

This is about timely native memory deallocation.  Since direct byte buffer is the only one using jdk.internal.ref.Cleaner, I am inclined to suggest keep jdk.internal.ref.Cleaner as is and replaced it with a better mechanism when it’s available, either panama or better pending reference enqueuing that you and Per discussed.   Given the time we have, I think it’s likely post JDK 9 timeframe.

Minimizing contention and interference of allocating threads and ReferenceHandler may worth exploring.
 
Mandy