答复: Committed should not larger than max_size in ContiguousSpacePool while using ParNew with UseAdaptiveSizePolicy
洪熙(hongxi)
hongxi.sy at taobao.com
Tue Mar 19 07:27:35 UTC 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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130319/955f08b8/attachment.htm>
More information about the hotspot-gc-dev
mailing list