Codereview request: 6980984 java/lang/management/MemoryMXBean/MemoryManagement is not robust when getMax() returns -1
shanliang
shanliang.jiang at oracle.com
Wed Jan 22 06:42:09 PST 2014
Jaroslav Bachorik wrote:
> On 22.1.2014 15:32, shanliang wrote:
>> Jaroslav Bachorik wrote:
>>> Hi Shanliang,
>>> On 22.1.2014 14:27, 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()
>>>
>>> You were also mentioning passing -XMaxHeapSize argument to force G1 to
>>> put restriction on the max heap size in the issue. Does it work?
>> Yes it worked too, as other solutions I mentioned above.
>>>
>>>>
>>>> or hard-code chunkSize to be 1M.
>>>>
>>>> I found that the test ran much faster with:
>>>> chunkSize = Runtime.getRuntime().freeMemory()/10;
>>>> than:
>>>> chunkSize = 1M;
>>>
>>> That's odd - unless "Runtime.getRuntime().freeMemory()/10" gives you a
>>> chunk much smaller than 1M. BTW, why do you divide the amount of free
>>> memory by 10? The "mu.getMax()" based calculation is using 20.
>>> Wouldn't this give you a bigger chunk when calculating it from
>>> "freeMemory()". And this would also increase the expected threshold
>>> since the chunk is multiplied by NUM_CHUNKS to get the threshold.
>> Yes it is interesting, it took 15 seconds and num_iteration = 145 with
>> chunkSize = 1M, but with Runtime.getRuntime().freeMemory()/10, it worked
>> as without G1GC, took less 1 second and num_iteration = 2, at least on
>> my Mac.
>
> Just out of curiosity - what is the chunk size when calculating via
> "Runtime.getRuntime().freeMemory()/10"?
8325091
>
> -JB-
>
>>>
>>>
>>> And just a nits:
>>> 1. While you are changing the source you might fix the type at L28
>>> "setUsatgeThreshold" -> "setUsageThreshold"
>> OK, good catch.
>>> 2. Should the @bug annotation contain the test issues? Just asking - I
>>> saw fixes without the test issue number added to the @bug annotation.
>> Not sure, but remember that once I was suggested to add it.
>>
>> Thanks,
>> Shanliang
>>>
>>> Cheers,
>>>
>>> -JB-
>>>
>>>>
>>>> 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