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

[Daniel Fuchs]

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
>>
>