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