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:32:09 PST 2014


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