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

[Daniel Fuchs]

On 1/22/14 3:32 PM, 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.
>>

This is strange Shanliang: you must have made a mistake
somewhere, because on my Mac with chunkSize = 1M when max == -1 it
only needs 2 iterations (as it should - and not 145).

FYI - I have added a trace to print both MemoryUsage
and Runtime.freeMemory() in the test, and I have observed
that the result of Runtime.freeMemory() is very close to
mu.getCommitted():

Memory Usage: init = 127926272(124928K) used = 0(0K) committed = 
126877696(123904K) max = -1(-1K)
Free memory: 128325536

Here is the full trace (with cheukSize=1M when max=-1):

ACTION: main -- Passed. Execution successful
REASON: User specified action: run main/othervm/timeout=600 -XX:+UseG1GC 
MemoryManagement
TIME:   0.54 seconds
messages:
command: main -XX:+UseG1GC MemoryManagement
reason: User specified action: run main/othervm/timeout=600 -XX:+UseG1GC 
MemoryManagement
elapsed time (seconds): 0.54
STDOUT:
Memory Usage: init = 127926272(124928K) used = 0(0K) committed = 
126877696(123904K) max = -1(-1K)
Free memory: 128325536
Setting threshold for G1 Old Gen from 0 to 2000000.  Current used = 0
Starting an AllocatorThread to allocate memory.
Notification for G1 Old Gen [type = 
java.management.memory.threshold.exceeded count = 1]
     usage = init = 127926272(124928K) used = 2951472(2882K) committed = 
126877696(123904K) max = -1(-1K)
AllocatedThread finished memory allocation  num_iteration = 2
Test passed.

-- daniel

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