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.
