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

[shanliang]

Jaroslav Bachorik wrote:
> Looks good.
>
> Just a side question - why are you using the divider of 10 (and the 
> original divider is 20)?
Did change to 20 in the last version :)

I tested with different dividers and got almost same running time with 
10 and 20.

Thanks,
Shanliang
>
> -JB-
>
> On 22.1.2014 17:29, 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
>>>
>>
>