RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

[Peter Levart]

Hi,

I agree the problem with de-allocation of native memory blocks should be 
studied deeply and this takes time.

What I have observed so far on Linux platform (other platforms may 
behave differently) is the following:

Deallocation of native memory with Unsafe.freeMemory(address) can take 
various amounts of time. It can grow to a constant amount  of several 
milliseconds to free a 1MB block, for example, when there's already lots 
of blocks allocated and multiple threads are constantly allocating more. 
I'm not sure yet about the main reasons for that, but it could either be 
a contention with allocation from multiple threads, interaction with GC, 
or even the algorithm used in the native allocator. Deallocation is also 
not very parallelizable. My observation is that deallocating with 2 
threads (on a 4 core CPU) does not help much.

Current scheme of deallocating in ReferenceHandler thread means that a 
lot of "pending" Cleaner objects can accumulate and although VM has 
promptly processed Cleaner PhantomReferences (hooked them on the pending 
list), a lot of work is still to be done to actually free the native 
blocks. This clogs ReferenceHandler thread and affects other Reference 
processing. It also presents difficulties for back-off strategy for 
allocating native memory. The strategy has no information that would be 
needed to decide whether to wait more or to fail with OOME.

I'm currently experimenting with approach where Cleaner and 
ReferenceHandler code stays as is, but the Cheaner's thunk (the 
Deallocator in DirectByteBuffer) is modified so that it performs some 
actions synchronously (announcing what will be de-allocated) and 
delegates the actual deallocation and unreservation to a background 
thread. Reservation strategy has more information to base it's back-off 
strategy that way. I'll let you know if I get some results from that.

Regards, Peter

On 10/04/2013 08:39 PM, mark.reinhold at oracle.com wrote:
> 2013/10/2 15:13 -0700, alan.bateman at oracle.com:
>> BTW: Is this important enough to attempt to do this late in 8? I just
>> wonder about a significant change like switching to weak references and
>> whether it would be more sensible to hold it back to do early in 9.
> I share your concern.  This is extraordinarily sensitive code.
> Now is not the time to rewrite it for JDK 8.
>
> - Mark