NPE when generating benchmark code

Mark Price Mark.Price at lmax.com
Wed May 21 13:46:41 UTC 2014 

Yes, and happy to use that as a workaround. 

Now that I have a microbenchmark.jar, I am having troubles running the benchmark. Generated files are all present and correct, but are not found when executing the jar.



[pricem at host jmh-benchmark]$ ../opt/jdk/bin/java -jar build/microbenchmarks.jar ".*HandlerChainBenchmark.*" -v EXTRA  -wi 5 -i 5 -f 1
No matching benchmarks. Miss-spelled regexp?
Benchmarks: 


[pricem at host jmh-benchmark]$ jar tf build/microbenchmarks.jar | grep HandlerChainBenchmark
com/lmax/exchange/benchmark/AsyncGatewayHandlerChainBenchmark.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testAcceptedMessage$AsyncGatewayHandlerChainBenchmark_1_jmh.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testAcceptedMessage$AsyncGatewayHandlerChainBenchmark_1_jmh_B1.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testAcceptedMessage$AsyncGatewayHandlerChainBenchmark_1_jmh_B2.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testAcceptedMessage$AsyncGatewayHandlerChainBenchmark_1_jmh_B3.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testAcceptedMessage$BlackHole_1_jmh.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testAcceptedMessage$BlackHole_1_jmh_B1.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testAcceptedMessage$BlackHole_1_jmh_B2.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testAcceptedMessage$BlackHole_1_jmh_B3.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testAcceptedMessage.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testAcceptedMessage.java
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testRejectionDueToHighWaterMark$AsyncGatewayHandlerChainBenchmark_1_jmh.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testRejectionDueToHighWaterMark$AsyncGatewayHandlerChainBenchmark_1_jmh_B1.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testRejectionDueToHighWaterMark$AsyncGatewayHandlerChainBenchmark_1_jmh_B2.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testRejectionDueToHighWaterMark$AsyncGatewayHandlerChainBenchmark_1_jmh_B3.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testRejectionDueToHighWaterMark$BlackHole_1_jmh.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testRejectionDueToHighWaterMark$BlackHole_1_jmh_B1.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testRejectionDueToHighWaterMark$BlackHole_1_jmh_B2.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testRejectionDueToHighWaterMark$BlackHole_1_jmh_B3.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testRejectionDueToHighWaterMark.class
com/lmax/exchange/benchmark/generated/AsyncGatewayHandlerChainBenchmark_testRejectionDueToHighWaterMark.java



Anything obviously wrong?

Mark

----- Original Message -----
> (sigh)
> 
> I think that's a javac problem, and it is triggered by some class on
> your classpath. This is probably why we can't replicate it with
> jmh-ant-sample.
> 
> You can still compile the benchmark with 7u51 and -target 1.6, right?
> 
> -Aleksey.
> 
> On 05/21/2014 05:28 PM, Mark Price wrote:
> > 6u45 fails with the same problem:
> > 
> >     [javac] error: Compiler control generators had thrown the unexpected
> >     exception java.lang.NullPointerException
> >     [javac] 	at
> >     com.sun.tools.javac.code.Symbol$MethodSymbol.params(Symbol.java:1196)
> >     [javac] 	at
> >     com.sun.tools.javac.jvm.ClassReader.attachParameterAnnotations(ClassReader.java:1111)
> >     [javac] 	at
> >     com.sun.tools.javac.jvm.ClassReader.readMemberAttr(ClassReader.java:873)
> >     [javac] 	at
> >     com.sun.tools.javac.jvm.ClassReader.readMemberAttrs(ClassReader.java:1027)
> >     [javac] 	at
> >     com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:1490)
> >     [javac] 	at
> >     com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:1586)
> >     [javac] 	at
> >     com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:1658)
> >     [javac] 	at
> >     com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:1845)
> >     [javac] 	at
> >     com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1777)
> > ...
> > 
> > [pricem at host tfx]$ ant -v
> > Apache Ant(TM) version 1.9.2 compiled on July 8 2013
> > Trying the default build file: build.xml
> > Buildfile: /mnt/scratch/pricem/dev/tfx-git/tfx/build.xml
> > Detected Java version: 1.6 in: /home/pricem/tmp/jdk1.6.0_45/jre
> > 
> > 
> > 
> > Mark
> > 
> > 
> > ----- Original Message -----
> >> So you are saying your benchmark compiles well with 7u51, but not with
> >> 6u37? This seems to be consistent with JDK-6889255, although its
> >> backport [2] seems to indicate it is fixed in 6u21 as well. Can you try
> >> latest 6u45?
> >>
> >> -Aleksey.
> >>
> >> [1] https://bugs.openjdk.java.net/browse/JDK-6889255
> >> [2] https://bugs.openjdk.java.net/browse/JDK-2183844
> >>
> >> On 05/21/2014 05:12 PM, Mark Price wrote:
> >>> Unfortunately, removing the ignore.symbol.file flag has no effect.
> >>>
> >>> Running the original sample with jdk 1.7.0_51 is successful (though
> >>> required 512m heap vs 256m).
> >>>
> >>>
> >>>
> >>> Mark
> >>>
> >>> ----- Original Message -----
> >>>> Thanks.
> >>>>
> >>>> So I put the same into jmh-ant-sample and added some @CompilerControl
> >>>> annotations. Works fine on JDK 6u38 and Ant 1.8.2.
> >>>>
> >>>> Given the exception apparently NPEs on looking up the symbol within
> >>>> javac, maybe you need to drop <compilerarg
> >>>> value="-XDignore.symbol.file"/>?
> >>>>
> >>>> -Aleksey.
> >>>>
> >>>> On 05/21/2014 04:41 PM, Mark Price wrote:
> >>>>> Hi Aleksey,
> >>>>> thanks for the response.
> >>>>>
> >>>>> ant version is 1.9.2
> >>>>> java version is 1.6.0_37
> >>>>>
> >>>>> the ant file is embarrassingly tangled, but it boils down to:
> >>>>>
> >>>>> <javac srcdir="src/test/java" destdir="build/test/classes" debug="on"
> >>>>> fork="yes" encoding="UTF-8" target="1.6"
> >>>>>                    source="1.6" debuglevel="lines,source,vars"
> >>>>>                    deprecation="on" includeantruntime="no"
> >>>>>                    memorymaximumsize="256m">
> >>>>>                 <compilerarg value="-Xlint:unchecked"/>
> >>>>>                 <compilerarg value="-XDignore.symbol.file"/>
> >>>>>                 <compilerarg value="-s"/>
> >>>>>                 <compilerarg value="build/test/classes"/>
> >>>>>                 <classpath>
> >>>>>                     <path
> >>>>>                     refid="${@{module}.@{artifact}.conf.compile}-path"/>
> >>>>>                     <extra-classpath/>
> >>>>>                 </classpath>
> >>>>>             </javac>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Mark
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> Hi Mark,
> >>>>>>
> >>>>>> On 05/21/2014 03:51 PM, Mark Price wrote:
> >>>>>>> Hi, I'm using JMH in the non-recommended ant mode, and seeing an
> >>>>>>> exception while compiling my benchmark.
> >>>>>>
> >>>>>> Just checked our jmh-ant-sample and it works, which means the problem
> >>>>>> is
> >>>>>> specific to your scenario. The attachments were scrubbed, but I got
> >>>>>> them
> >>>>>> in the moderator note. Can you publish the Ant build file as well?
> >>>>>> "ant
> >>>>>> -v" and "java -version" would also be appreciated.
> >>>>>>
> >>>>>> These lines are important:
> >>>>>>
> >>>>>>> [javac] error: Compiler control generators had thrown the unexpected
> >>>>>>> exception java.lang.NullPointerException
> >>>>>> ...
> >>>>>>> [javac] 	at
> >>>>>>> org.openjdk.jmh.generators.core.CompilerControlPlugin.process(CompilerControlPlugin.java:67)
> >>>>>>
> >>>>>> That's a separate @CompilerControl processor, and this is why the
> >>>>>> benchmark is still generated.
> >>>>>>
> >>>>>>> though it seems to generate a file for the single benchmark that I
> >>>>>>> have included (attached, along with original benchmark source).
> >>>>>>
> >>>>>> No need to publish the generated source.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> -Aleksey.
> >>>>>>
> >>>>
> >>>>
> >>
> >>
> 
> 
>

More information about the jmh-dev mailing list