Request for review: 7173044: Memory monitor demo hangs if MemoryUsage obj returns -1 in getMax

[Sean Chou]

Hi Erik,

     In fact there is no technical reason. I hope 1024K might keep the
start
usage in the middle of the graph and 1 is too small which will make the
painting start at the top of the graph.

On Fri, Jun 1, 2012 at 5:20 AM, Erik Gahlin <erik.gahlin at oracle.com> wrote:

> Hi,
>
> I'm not an offical reviewer, but why do you initialize the array to 1024K
> and not 1?
>
> Do you get problems with lower values?
>
> Best regards
> Erik
>
> Sean Chou skrev 2012-05-31 09:17:
>
>> Hi all,
>>
>>    MemoryMonitor demo will hang if MemoryUsage obj returns -1 in getMax
>> method.
>> The demo obtains totalMemory from getMax method, and it is used in
>> following loop:
>>
>> "    // .. Memory Free ..
>>     big.setColor(mfColor);
>>     int MemUsage = (int) (((totalMemory - usedMemory) / totalMemory) *
>> 10);
>>     int i = 0;
>>     for ( ; i < MemUsage ; i++) {
>>          mfRect.setRect(x1+5,(float) y1+ssH+i*blockHeight,
>>                    blockWidth, blockHeight-1);
>>          big.fill(mfRect);
>>     }
>> "
>>   If -1 is returned, MemUsage becomes a very large positive value and the
>> loop hangs
>> the demo.
>>
>>   The bug is not seen in current openjdk because the beans returned all
>> has a Max
>> value returned. However, -1 is allowed by spec when Max is not set for
>> the bean, and
>> other jdk might return.
>>
>>   In the patch, max is set to 1m or the max memory usage in history for
>> the bean
>> if there is no max specified. Please take a look.
>>
>> Bug: http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7173044<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173044>
>> Webrev: http://cr.openjdk.java.net/~**zhouyx/7173044/webrev.01/<http://cr.openjdk.java.net/~zhouyx/7173044/webrev.01/><
>> http://cr.openjdk.java.net/%**7Ezhouyx/7173044/webrev.01/<http://cr.openjdk.java.net/%7Ezhouyx/7173044/webrev.01/>>
>>  .
>>
>>
>>
>> --
>> Best Regards,
>> Sean Chou
>>
>>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120601/d4a47e01/attachment.html