Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

[Peter Levart]

On 09/09/2015 04:56 PM, Dawid Weiss wrote:
>> I think it would be best to leave to the application to decide and
>> implement the tracking and also triggering GC at times when it approaches
>> the limit.
> I disagree. The GC -- when and how it is triggered -- should be
> transparent to the application. We don't want to manage GC, we want to
> (truly) release the resources we allocated (and we know when they are
> no longer needed).
>
> What you suggest is essentially managing GC from application level. I
> don't think it's the right approach to solve the problem.
>
> Dawid

Hi Dawid,

By wanting to truly release the resources you allocated, you are 
essentially wanting to manage the resources yourself. If you are willing 
to track the active mapped byte buffers manually yourself, then what 
about the following idea:

- you track the number of mapped buffers (or mapped address space) that 
you "know" is active in the application manually.
- you track the number of mapped buffers (or mapped address space) that 
is actually mapped at a particular time (by utilizing an after-unmap 
call-back that would have to be added to MappedByteBuffer API)
- when the difference of those two tracked quantities reaches certain 
amount or percentage, you give a kick to GC to do it's job, as it is 
lagging behind.

I would not call this managing GC, but just hinting GC at the right 
time. The most burden in this approach would be the manual tracking of 
active buffers, but you are willing to do that anyway by wanting to 
manually release the resources. Everything else can be made automatic.


Regards, Peter