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

Hi, Dawid Weiss and I are both involved in the Apache Lucene project and we know the problems with MappedByteBuffer and unmapping. Dawid already responded with a source code link to our impl (which needs to use the hacky cleaner() approach; also look at the heavy documentation in this class):

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

Thanks for the contribution, Uwe. So far I think I like Andrew's suggestion of a guard page the most. Unmapping the guard page boils down to a kind of thread-local variable without the actual cost of reading anything (in theory). So by write-protecting the guard page and then unmapping the file,

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

Hi Uwe, As I thought, the problem for some seems to be non-prompt unmapping of mapped address space held by otherwise unreachable mapped byte buffers. The mapped address space doesn't live in the Java heap and doesn't represent a heap memory pressure, so GC doesn't kick-in automatically when

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

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

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

Hi, > As I thought, the problem for some seems to be non-prompt unmapping of > mapped address space held by otherwise unreachable mapped byte buffers. > The mapped address space doesn't live in the Java heap and doesn't > represent a heap memory pressure, so GC doesn't kick-in automatically >

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

> - you track the number of mapped buffers (or mapped address space) that you > "know" is active in the application manually. The problem is you really can't do it on a global, JVM-scale, Peter. It's enough that the same JVM process starts two isolated class loaders with Lucene in each and such

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

On 09/09/2015 04:21 PM, Peter Levart wrote: Hi Uwe, As I thought, the problem for some seems to be non-prompt unmapping of mapped address space held by otherwise unreachable mapped byte buffers. The mapped address space doesn't live in the Java heap and doesn't represent a heap memory

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

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

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

> 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

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

On Wed, Sep 9, 2015 at 11:46 AM, Peter Levart wrote: > > 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

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

Hi, > As I thought, the problem for some seems to be non-prompt unmapping of > mapped address space held by otherwise unreachable mapped byte buffers. > The mapped address space doesn't live in the Java heap and doesn't > represent a heap memory pressure, so GC doesn't kick-in automatically >