Hi Shanliang, This looks reasonable to me. I'm not sure that using freeMemory() will always work - but at the worst it means that there are still some cases where the test that used to fail will continue to fail ;-)
We have both seen that it fixes the original issue which was encountered on Mac with JDK 6 & -XX:+UseG1GC (which looks to be the unique known config that seems to return a MemoryUsage whose getMax() is -1). Please run the test through jprt before pushing though - just to check that it still passes on all archs :-) cheers, -- daniel On 1/22/14 5:29 PM, shanliang wrote:
Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-6980984/01/ with the modifications for: 1) synchronization issues raised by Daniel 2) "setUsatgeThreshold" -> "setUsageThreshold" The odd issue about getting slower with: chunkSize = 1M; maybe was from the "old gen" behavior, but that seems not important for the test. Thanks, Shanliang Daniel Fuchs wrote:Hi Shanliang, I just notice that there are some synchronization issues in the test as well: all static variables used by the allocator thread should be declared volatile (chunkSize, mpool ...). -- daniel On 1/22/14 2:27 PM, shanliang wrote:Hi, The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9. We can have several solutions, like to use: Runtime.getRuntime().maxMemory() Runtime.getRuntime().totalMemory; MemoryUsage.getCommitted() or hard-code chunkSize to be 1M. I found that the test ran much faster with: chunkSize = Runtime.getRuntime().freeMemory()/10; than: chunkSize = 1M; webrev: http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/ bug: https://bugs.openjdk.java.net/browse/JDK-6980984 Thanks, Shanliang
