Committed should not larger than max_size in ContiguousSpacePool while using ParNew with UseAdaptiveSizePolicy

[Bengt Rutisson]

Hi Hongxi

Thanks for supplying the patch.

What Java version are you using? I think that using adaptive sizing with
ParNew has never worked very well. In fact this feature has been
disabled in the main branch about a year ago (I think it went in to
7u4). See:

7112413 : JVM Crash, possibly GC-related
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7112413

So, I would not recommend using -XX:+UseAdaptiveSizePolicy with
-XX:+UseConcMarkSweepGC. The only supported GC for adaptive size policy
is the parallel GC. Even with your patch I think you will see crashes if
you continue running with the command line you supplied.

I have only looked briefly at your patch, but I think that it may be
hiding a problem more than fixing it. I think we should in fact have max
size set up properly. If capacity turns out to be larger than max size
we have a real problem. Just hiding this by updating the max size seems
a bit scary to me.

Bengt



On 3/19/13 3:48 AM, Daniel D. Daugherty wrote:
> Hongxi,
>
> I'm redirecting this message to the HotSpot GC OpenJDK alias
> and the Serviceability OpenJDK alias. JMX is owned by the
> Serviceability team and you've also got some GC questions
> here...
>
> Dan
>
> P.S.
> Bcc'ed the Runtime OpenJDK so you folks know that this message
> has been redirected...
>
> On 3/18/13 7:59 PM, ºéÎõ(hongxi) wrote:
>>
>> Hi all£º
>>
>> Sorry if here is not the right place to submit this small fix.
>>
>> Days ago, some of our systems occur this exception:
>>
>> 2013-01-22 16:59:07,351 ERROR protocol.MBeanServerMessageHandler
>> {141} - handle message error objectName=com.alibaba.dragoon:type=GC
>>
>> javax.management.RuntimeErrorException: java.lang.InternalError:
>> Memory Pool not found
>>
>> at
>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:858)
>>
>> at
>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:869)
>>
>> at
>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:670)
>>
>> at
>> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638)
>>
>> at
>> com.alibaba.dragoon.common.protocol.MBeanServerMessageHandler.getAttributeInternal(MBeanServerMessageHandler.java:242)
>>
>> at
>> com.alibaba.dragoon.common.protocol.MBeanServerMessageHandler.handle(MBeanServerMessageHandler.java:113)
>>
>> at
>> com.alibaba.dragoon.common.protocol.MessageHandlerAdapter.handle(MessageHandlerAdapter.java:53)
>>
>> at
>> com.alibaba.dragoon.common.protocol.DragoonSession.receiveMessageIntenal(DragoonSession.java:204)
>>
>> at
>> com.alibaba.dragoon.common.protocol.DragoonSession.receiveMessage(DragoonSession.java:178)
>>
>> at
>> com.alibaba.dragoon.common.protocol.transport.socket.SocketSessionImpl$1.run(SocketSessionImpl.java:211)
>>
>> Caused by: java.lang.InternalError: Memory Pool not found
>>
>> at sun.management.MemoryPoolImpl.getUsage0(Native Method)
>>
>> at sun.management.MemoryPoolImpl.getUsage(MemoryPoolImpl.java:77)
>>
>> at com.alibaba.dragoon.client.jmx.GC.getEdenSpaceUsed(GC.java:185)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:597)
>>
>> at
>> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
>>
>> at
>> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
>>
>> at
>> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
>>
>> at
>> com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:65)
>>
>> at
>> com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:216)
>>
>> at
>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:666)
>>
>> ... 7 more
>>
>> The jvm argument is as bellow£º
>>
>> /usr/java/bin/java -server -Xmx5g -Xms5g -Xmn512m -XX:PermSize=128m
>> -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC
>> -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection
>>
>> -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly
>> -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCompressedOops
>> -XX:ParallelGCThreads=4 -XX:+UseAdaptiveSizePolicy
>>
>> -Dcom.sun.management.jmxremote.port=1100
>> -Dcom.sun.management.jmxremote.ssl=false
>> -Dcom.sun.management.jmxremote.authenticate=false
>> -Djava.rmi.server.hostname=localhost
>>
>> -Dhummock.output.logs=/home/admin/output/logs
>> -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true
>>
>> At last, we found it¡¯s possible a jvm bug, when UseAdaptiveSizePolicy
>> + ParNew, if the eden is expanded the max size of eden¡¯s
>> ContiguousSpacePool will not be updated, perhaps the commited is
>> larger than max_size. Though at last I know UseAdaptiveSizePolicy has
>> some problems with CMS and it has been disabled in the latest jdk7u,
>> I think I should submit a patch to fix this small bug. My patch is in
>> the attachment.
>>
>> Regrads
>>
>> hongxi
>>
>>
>> ------------------------------------------------------------------------
>>
>> This email (including any attachments) is confidential and may be
>> legally privileged. If you received this email in error, please
>> delete it immediately and do not copy it or use it for any purpose or
>> disclose its contents to any other person. Thank you.
>>
>> ±¾µçÓÊ(°üÀ¨Èκθ½¼þ)¿ÉÄܺ¬ÓлúÃÜ×ÊÁϲ¢ÊÜ·¨Âɱ£»¤¡£ÈçÄú²»ÊÇÕýÈ·µÄÊÕ¼þ
>> ÈË£¬ÇëÄúÁ¢¼´É¾³ý±¾Óʼþ¡£Çë²»Òª½«±¾µçÓʽøÐи´ÖƲ¢ÓÃ×÷ÈÎ ºÎÆä ËûÓÃ;¡¢
>> »ò͸¶±¾ÓʼþÖ®ÄÚÈÝ¡£Ð»Ð»¡£
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130319/669bd1ba/attachment.html