On 10/07/2013 10:36 PM, Peter Levart wrote:
The back-off before retrying looks good, I just wonder if 1ms is too
low to start with.
The tests show that in majority of calls (at least on fast CPUs),
thread does not sleep at all and if it really must sleep, a single
sleep(1) is usually enough. So why sleep more? We have exponential
back-off, so on slower CPUs, where longer sleeps might be needed, a
couple of iterations more will be enough to reach the right point in
time. I'll try the measurement on Raspberry PI. I wonder how it
behaves there...
Hi,
I have found some time to incorporate the review comments and created
new webrev which is attatched to JIRA task:
https://bugs.openjdk.java.net/browse/JDK-6857566
I'm not asking to re-review this yet, since I'll bring it up again when
JDK9 is started. I just wanted to inform you that I did some testing on
Raspbery PI and the patch behaves similarly. I had to spawn 4 allocating
threads to provoke OOME on unpatched JDK8. With the patch, running 16
allocating threads, I see about 90% of allocations being done without
helping ReferenceHandler thread, 5% of allocations while helping but
before System.gc() and another 5% while helping and after System.gc()
but before any sleeps. I have not yet seen a situation where a single
sleep(1) was needed on Raspbery PI. So this makes me believe that
sleeping up to 9 times (up to 0.5 s) before throwing OOME is very
conservative. The worst situation I noticed was a very rare case of two
consecutive sleeps: sleep(1) followed by sleep(2) before satisfying the
reservation request.
Regards, Peter
