=?gb2312?B?tPC4tDogQ29tbWl0dGVkIHNob3VsZCBub3QgbGFyZ2VyIHRoYW4gbWF4X3Np?= =?gb2312?B?emUgaW4gQ29udGlndW91c1NwYWNlUG9vbCB3aGlsZSB1c2luZyBQYXJOZXcg?= =?gb2312?Q?with_UseAdaptiveSizePolicy?=

Tue Mar 19 00:27:35 PDT 2013

Our java version is 6u32 ,an old version.  Actually The patch can only fix the exception  list in the last email. Now our system has closed UseAdaptiveSizePolicy while using CMS,  it¡¯s runs happily.

Regards
hongxi

·¢¼þÈË: Bengt Rutisson [mailto:bengt.rutisson at oracle.com]
·¢ËÍÊ±¼ä: 2013Äê3ÔÂ19ÈÕ 14:53
ÊÕ¼þÈË: daniel.daugherty at oracle.com
³ËÍ: ºéÎõ(hongxi); serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Ö÷Ìâ: Re: Committed should not larger than max_size in ContiguousSpacePool while using ParNew with UseAdaptiveSizePolicy

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.

±¾µçÓÊ(°üÀ¨ÈÎºÎ¸½¼þ)¿ÉÄÜº¬ÓÐ»úÃÜ×ÊÁÏ²¢ÊÜ·¨ÂÉ±£»¤¡£ÈçÄú²»ÊÇÕýÈ·µÄÊÕ¼þÈË£¬ÇëÄúÁ¢¼´É¾³ý±¾ÓÊ¼þ¡£Çë²»Òª½«±¾µçÓÊ½øÐÐ¸´ÖÆ²¢ÓÃ×÷ÈÎ ºÎÆä ËûÓÃÍ¾¡¢»òÍ¸Â¶±¾ÓÊ¼þÖ®ÄÚÈÝ¡£Ð»Ð»¡£

________________________________

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/955f08b8/attachment-0001.html 