RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

[Alan Bateman]

On 07/10/2013 21:36, Peter Levart wrote:
> :
>
> Ask not what reference handler can do for you,  ask what you can do 
> for reference handler! ;-)
Indeed.
>
> :
>         }
>
> I get:
>
> sleep(1) takes 1079078 ns
> sleep(2) takes 2058245 ns
> sleep(3) takes 3060258 ns
> sleep(4) takes 4060121 ns
> sleep(5) takes 5061263 ns
> sleep(6) takes 6063189 ns
> sleep(7) takes 7075132 ns
> sleep(8) takes 8071381 ns
> sleep(9) takes 9062244 ns
> ...
>
> ...which seems pretty accurate.
Okay although I must admit that I didn't expect to see any difference up 
to 5 or 10ms (but it is of course highly platform/config specific).


> :
>
>>
>> A related piece of work is the FileChannel map implementation where 
>> there is a gc + retry if mmap fails. This could be changed to have a 
>> similar back-off/retry.
>>
>
> I see. Would it make sense to do it in same patch or separately. This 
> too, will need JavaLangRefAccess.tryHandlePendingReference(), I think, 
> since it similarly ties unmap0 to a Cleaner referencing 
> MappedByteBuffer. The tryMap0 would just be a call to map0 with 
> catching of OOME and returning true/false, right?
>
> Do you happen to know what defines the limit of how many bytes or 
> blocks can be mapped at one time? Is this some parameter for VM or is 
> this just plain OS limit?
It's okay to separate this into a separate patch, I was really just 
pointing out that we file mappings is another case where this could 
help. There isn't a limit for this in the JDK so it does depend on the 
OS. A tryMap as you suggest should be okay, alternatively we could 
change the native method to return 0 for the ENOMEM case.


> :
>
> Ok then, I'll finish this nevertheless and then it can sit and wait 
> for JDK9.
>
I don't know when a jdk9 project will be proposed but I expect so very 
soon because we will all be holding onto patches after the ZBB date.

-Alan.