RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation
Aleksey Shipilev
aleksey.shipilev at oracle.com
Mon Oct 7 12:43:10 UTC 2013
Hi Peter,
On 10/07/2013 02:56 AM, Peter Levart wrote:
> http://cr.openjdk.java.net/~plevart/jdk8-tl/DyrectBufferAlloc/webrev.01/
The 1 hour run of this on my 1x2x2 i5, directMem=16m, original
DirectByteBufferTest yields no failures! Oh my. Good job!
Comments on the code:
Bits.java:
- Thread.currentThread().interrupt() only sets the interruption flag,
it does not break the control flow. You can call it directly in the
exception handler, sparing some boiler-plate code.
- Given that you about to retry, do you think catching the interrupt
during sleep should immediately return? Or, try the last time to reserve
some memory, and either return or throw OOME?
- Please avoid inline assignments.
- I'd like to embed the comment why 9 is the magic number.
Reference.java:
- Please move the static initializer block back, that will be cleaner
change.
- Please keep the (r instanceof Cleaner) block as the separate if;
makes it visually different from the common code path.
DirectBufferAllocTest.java:
- "for(;;)" -> "while(true)"
- Can we turn the 60*1000 into the constant?
- I think 10 seconds is enough for regression test.
- Can we fold the relevant into Integer.getInteger("...", #const) to
make them tunable, while still claiming it to be the regtest in the
default mode? Put the comment which settings should be used to turn this
test into the stress test.
> 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)
>
Thank you! I was meant to do this for my original patch. (In fact I did
some debug printing on the recovery paths, only to see we almost never
hit them).
> So what do you think? Is this still too risky for JDK8?
I think that the patch is great. We are near the JDK 8 endgame though.
As much as I will be happy to have that in 8u0, this is probably
something for early JDK 9, with a backport to 8u2?
-Aleksey.
More information about the core-libs-dev
mailing list