DirectByteBuffer change proposal
Peter Levart
peter.levart at gmail.com
Tue Aug 11 21:22:13 UTC 2015
Hi Biju,
When I was preparing this patch for JDK9, I did the following
measurement: Using LongAdders (to avoid Heisenberg) I counted various
exit paths from Bits.reserveMemory() during a test that spawned 128
allocating threads on a 4-core i7 machine, allocating direct buffers
randomly sized between 256KB and 1MB for 60 seconds, using
-XX:MaxDirectMemorySize=512m:
Total of 909960 allocations were performed:
- 247993 were satisfied before attempting to help ReferenceHandler thread
- 660184 were satisfied while helping ReferenceHandler thread but before
triggering System.gc()
- 1783 were satisfied after triggering System.gc() but before doing any
sleep
- no sleeping has been performed
The same test, just changing -XX:MaxDirectMemorySize=128m (that means
1MB per thread each allocating direct buffers randomly sized between
256KB and 1MB):
Total of 579943 allocations were performed:
- 131547 were satisfied before attempting to help ReferenceHandler thread
- 438345 were satisfied while helping ReferenceHandler thread but before
triggering System.gc()
- 10016 were satisfied after triggering System.gc() but before doing any
sleep
- 34 were satisfied after sleep(1)
- 1 was satisfied after sleep(1) followed by sleep(2)
Have your observations been different? Did you observe sleep() been
called in a real-world application?
Regards, Peter
On 08/11/2015 04:11 PM, Biju G.S Nair wrote:
> Hello All,
> While the patch https://bugs.openjdk.java.net/browse/JDK-6857566
> currently applied to jdk 9 (which I had requested to be back ported to JDK
> 8 & 7) fixes the OOM exception during memory allocation by exponentially
> increasing the sleep time, this can negatively impact low latency
> applications using DirectByteBuffers. If we are able to provide a new JVM
> parameter which the users can set to a percentage value of DirectBuffer use
> as threshold when the "System.gc()" call in java/nio/Bits.java to be made,
> then the probability of sleep time being much lower is high. Also it gives
> users some control over when the gc() need to be requested instead of
> starting the gc() at the last moment when the direct memory is used fully.
> Without knowing all the details, to me it looks like a straight forward
> change. Let me know if there is any issue with the proposed change. If this
> change is a possibility let me know how I can make a request for this
> change.
>
> Thanks,
> Biju
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150811/4aa50dc7/attachment-0001.html>
More information about the nio-dev
mailing list