Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1

shanliang shanliang.jiang at oracle.com
Wed Jan 22 08:29:05 PST 2014


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
>



More information about the serviceability-dev mailing list