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

[Mark Miller]

It seems less than ideal to count on System.gc to do this as a library
though.

Now the user has to worry about what affect System.gc has on what JVM with
what Garbage Collector and whether or not ExplicitGCInvokesConcurrent was
turned on for the JVM, or...

- Mark

On Wed, Sep 9, 2015 at 11:46 AM Peter Levart <peter.levart at gmail.com> wrote:

>
>
> 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-unsubscribe at lucene.apache.org
> For additional commands, e-mail: dev-help at lucene.apache.org
>
> --
- Mark
about.me/markrmiller