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

Jaroslav Bachorik jaroslav.bachorik at oracle.com
Wed Jan 22 06:14:43 PST 2014


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?

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


And just a nits:
1. While you are changing the source you might fix the type at L28 
"setUsatgeThreshold" -> "setUsageThreshold"
2. Should the @bug annotation contain the test issues? Just asking - I 
saw fixes without the test issue number added to the @bug annotation.

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