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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
