problem with ClassLayout.parseClass
Nezih Yigitbasi
nyigitbasi at netflix.com
Wed Nov 5 19:33:29 UTC 2014
Hi everyone,
We are seeing a weird GC problem with the jol library with the
ClassLayout.parseClass() call. The problem is that the calling thread
spends a lot of time doing full GCs and it’s kind of stuck in a GC loop. We
only observed this problem with the -XX:+UseConcMarkSweepGC and
-XX:+ExplicitGCInvokesConcurrent flags where the explicit System.gc() call
in the VMSupport.guessAlignment() method cause full GCs that are very slow
(when these flags are removed I see less number of full GCs that are much
faster and I don’t see the problem anymore). This seemed like a bug to me,
but I just wanted to check with you to understand it better. Our current
workaround is to disable explicit GC calls. Btw my environment is EC2/Linux
with openjdk 1.7.
Thanks,
Nezih
"main" prio=10 tid=0x00007fe1d8019000 nid=0x4aeb runnable [0x00007fe1dee84000]
java.lang.Thread.State: RUNNABLE
at java.lang.Runtime.gc(Native Method)
at java.lang.System.gc(System.java:984)
at org.openjdk.jol.util.VMSupport.guessAlignment(VMSupport.java:226)
at org.openjdk.jol.util.VMSupport.access$1500(VMSupport.java:56)
at org.openjdk.jol.util.VMSupport$VMOptions.<init>(VMSupport.java:335)
at org.openjdk.jol.util.VMSupport$VMOptions.getHotspotSpecifics(VMSupport.java:395)
at org.openjdk.jol.util.VMSupport$VMOptions.getOptions(VMSupport.java:350)
at org.openjdk.jol.util.VMSupport$VMOptions.access$000(VMSupport.java:304)
at org.openjdk.jol.util.VMSupport.<clinit>(VMSupport.java:115)
at org.openjdk.jol.info.FieldData.computeOffset(FieldData.java:80)
at org.openjdk.jol.info.FieldData.parse(FieldData.java:58)
at org.openjdk.jol.info.ClassData.parseClass(ClassData.java:87)
at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:59)
at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:48)
at com.facebook.presto.ml.LearnStateFactory.<clinit>(LearnStateFactory.java:28)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at com.facebook.presto.operator.aggregation.state.StateCompiler.generateStateFactory(StateCompiler.java:348)
at com.facebook.presto.operator.aggregation.AggregationCompiler.generateAggregationFunctions(AggregationCompiler.java:108)
at com.facebook.presto.operator.aggregation.GenericAggregationFunctionFactory.fromAggregationDefinition(GenericAggregationFunctionFactory.java:34)
at com.facebook.presto.metadata.FunctionListBuilder.aggregate(FunctionListBuilder.java:129)
at com.facebook.presto.ml.MLFunctionFactory.listFunctions(MLFunctionFactory.java:36)
at com.facebook.presto.server.PluginManager.installPlugin(PluginManager.java:211)
at com.facebook.presto.server.PluginManager.loadPlugin(PluginManager.java:179)
at com.facebook.presto.server.PluginManager.loadPlugin(PluginManager.java:162)
at com.facebook.presto.server.PluginManager.loadPlugins(PluginManager.java:145)
at com.facebook.presto.server.PrestoServer.run(PrestoServer.java:111)
at com.facebook.presto.server.PrestoServer.main(PrestoServer.java:61)
More information about the jol-dev
mailing list