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.reinh...@oracle.com wrote:
2013/10/2 15:13 -0700, alan.bate...@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
