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

[Peter Levart]

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