From shade at openjdk.java.net Thu Nov 19 11:22:14 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 Nov 2020 11:22:14 GMT Subject: RFR: 7902762: JMH: Use "blackhole" compiler command Message-ID: JMH can be enabled to use the "blackhole" compile command from [JDK-8252505](https://bugs.openjdk.java.net/browse/JDK-8252505). ------------- Commit messages: - 7902762: JMH: Use "blackhole" compiler command Changes: https://git.openjdk.java.net/jmh/pull/8/files Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=8&range=00 Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7902762 Stats: 207 lines in 15 files changed: 108 ins; 38 del; 61 mod Patch: https://git.openjdk.java.net/jmh/pull/8.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/8/head:pull/8 PR: https://git.openjdk.java.net/jmh/pull/8 From mcervena at redhat.com Wed Nov 25 10:55:01 2020 From: mcervena at redhat.com (Michal Cervenansky) Date: Wed, 25 Nov 2020 11:55:01 +0100 Subject: JMH problem with State referencing Message-ID: Hello, I have come across a use case where I need to reference class with @State Scope.Benchmark in class with @State Scope.Thread. This is possible in JMH. However, when I tried to use it twice, for example in both setup and teardown methods, then the build failed. I believe it is because parameter names are generated based on their type, so two parameters of the same type lead to generating the same parameter name, and that causes the error. Please see this example, where I showcase the problem as well as how this feature could be still used: https://github.com/MichalCervenansky/Demo-JMH-State-Referencing-Problem May I ask if there are any plans regarding this feature? To either better document it and hopefully fix the problem I have encountered or it might get removed in future versions? Many thanks, Michal ?erve?ansk?. From simonis at openjdk.java.net Wed Nov 25 19:22:13 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Wed, 25 Nov 2020 19:22:13 GMT Subject: RFR: CODETOOLS-7902799: perfasm still handles event modifiers incorrectly Message-ID: Using the perfasm profiler with an event specification like `-prof perfasm:events=cycles:ppp` will result in no output because JMH won't find any events: Secondary result "io.simonis.jmh.Synchronization.synchronizedIncrementGlobal:?asm": PrintAssembly processed: 142164 total address lines. Perf output processed (skipped 7.859 seconds): Column 1: cycles:ppp (0 events) This is because since [CODETOOLS-7901905](https://bugs.openjdk.java.net/browse/CODETOOLS-7902799) the tags are removed from the events when the perf output is parsed. But the list of profiled events (which is kept in the `AbstractPerfAsmProfiler` base class of `LinuxPerfAsmProfiler`) still keeps the original event specification with the tag. I've tried to normalize all event name usages in `LinuxPerfAsmProfiler` to use the event name without tags but doing so is not easy because in the end the base class will check the original events against the parsed ones in `processAssembly()/PerfEvents()` and fail (i.e. in the sense that it won't find any events). So in the end I gave up and simple removed the part of [CODETOOLS-7901905](https://bugs.openjdk.java.net/browse/CODETOOLS-7902799) which chops the tags from the event name. I don't think that's necessary and everything seems to still work just fine with the full name plus tags (except for a tests in `PerfParseTest.java` which had to be removed because it specifically checked that `LinuxPerfAsmProfiler.parsePerfLine()` removes tags from event names which are parsed from the `perf` output). This fix will make it possible to use the `:ppp` tag which prevents instruction skew in `perf` results (see http://www.brendangregg.com/perf.html#EventProfiling). So the following output: PrintAssembly processed: 142764 total address lines. Perf output processed (skipped 7.898 seconds): Column 1: cycles (10247 events) Hottest code regions (>10.00% "cycles" events): ....[Hottest Region 1].............................................................................. c2, level 4, io.simonis.jmh.Synchronization::synchronizedIncrementGlobal, version 468 (221 bytes) 0.03% 0x00007fffe01e1f37: test $0x2,%rax ? 0x00007fffe01e1f3d: jne 0x00007fffe01e1f63 ? 0x00007fffe01e1f3f: or $0x1,%rax ? 0x00007fffe01e1f43: mov %rax,(%rbx) ? 0x00007fffe01e1f46: lock cmpxchg %rbx,(%rsi) ?? 0x00007fffe01e1f4b: je 0x00007fffe01e1f76 ?? 0x00007fffe01e1f51: sub %rsp,%rax ?? 0x00007fffe01e1f54: and $0xfffffffffffff007,%rax ?? 0x00007fffe01e1f5b: mov %rax,(%rbx) ??? 0x00007fffe01e1f5e: jmpq 0x00007fffe01e1f76 0.32% ??? 0x00007fffe01e1f63: mov %rax,%r11 0.01% ?? 0x00007fffe01e1f66: xor %rax,%rax 0.07% ?? 0x00007fffe01e1f69: lock cmpxchg %r15,0x3e(%r11) 35.31% ?? 0x00007fffe01e1f6f: movq $0x3,(%rbx) 0.15% ??? 0x00007fffe01e1f76: jne 0x00007fffe01e202b ;*synchronization entry which obviously suffers from instruction skew because it attributes 35% of the cycles to the `movq` instruction after the `lock cmpxchg` will be fixed and look correctly like this: PrintAssembly processed: 143768 total address lines. Perf output processed (skipped 7.921 seconds): Column 1: cycles:ppp (10074 events) Hottest code regions (>10.00% "cycles:ppp" events): ....[Hottest Region 1].............................................................................. c2, level 4, io.simonis.jmh.Synchronization::synchronizedIncrementGlobal, version 481 (137 bytes) 0x00007fffe01e3fb7: test $0x2,%rax 0.32% ? 0x00007fffe01e3fbd: jne 0x00007fffe01e3fe3 ? 0x00007fffe01e3fbf: or $0x1,%rax ? 0x00007fffe01e3fc3: mov %rax,(%rbx) ? 0x00007fffe01e3fc6: lock cmpxchg %rbx,(%rsi) ?? 0x00007fffe01e3fcb: je 0x00007fffe01e3ff6 ?? 0x00007fffe01e3fd1: sub %rsp,%rax ?? 0x00007fffe01e3fd4: and $0xfffffffffffff007,%rax ?? 0x00007fffe01e3fdb: mov %rax,(%rbx) ??? 0x00007fffe01e3fde: jmpq 0x00007fffe01e3ff6 0.01% ??? 0x00007fffe01e3fe3: mov %rax,%r11 0.05% ?? 0x00007fffe01e3fe6: xor %rax,%rax 35.03% ?? 0x00007fffe01e3fe9: lock cmpxchg %r15,0x3e(%r11) 0.21% ?? 0x00007fffe01e3fef: movq $0x3,(%rbx) 0.26% ?? 0x00007fffe01e3ff6: jne 0x00007fffe01e40ab ;*synchronization entry ------------- Commit messages: - CODETOOLS-7902799: perfasm still handles event modifiers incorrectly Changes: https://git.openjdk.java.net/jmh/pull/9/files Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=9&range=00 Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7902799 Stats: 26 lines in 2 files changed: 0 ins; 26 del; 0 mod Patch: https://git.openjdk.java.net/jmh/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/9/head:pull/9 PR: https://git.openjdk.java.net/jmh/pull/9 From shade at openjdk.java.net Wed Nov 25 19:25:08 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 Nov 2020 19:25:08 GMT Subject: RFR: CODETOOLS-7902799: perfasm still handles event modifiers incorrectly In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 19:17:47 GMT, Volker Simonis wrote: > Using the perfasm profiler with an event specification like `-prof perfasm:events=cycles:ppp` will result in no output because JMH won't find any events: > Secondary result "io.simonis.jmh.Synchronization.synchronizedIncrementGlobal:?asm": > PrintAssembly processed: 142164 total address lines. > Perf output processed (skipped 7.859 seconds): > Column 1: cycles:ppp (0 events) > This is because since [CODETOOLS-7901905](https://bugs.openjdk.java.net/browse/CODETOOLS-7902799) the tags are removed from the events when the perf output is parsed. But the list of profiled events (which is kept in the `AbstractPerfAsmProfiler` base class of `LinuxPerfAsmProfiler`) still keeps the original event specification with the tag. > > I've tried to normalize all event name usages in `LinuxPerfAsmProfiler` to use the event name without tags but doing so is not easy because in the end the base class will check the original events against the parsed ones in `processAssembly()/PerfEvents()` and fail (i.e. in the sense that it won't find any events). > > So in the end I gave up and simple removed the part of [CODETOOLS-7901905](https://bugs.openjdk.java.net/browse/CODETOOLS-7902799) which chops the tags from the event name. I don't think that's necessary and everything seems to still work just fine with the full name plus tags (except for a tests in `PerfParseTest.java` which had to be removed because it specifically checked that `LinuxPerfAsmProfiler.parsePerfLine()` removes tags from event names which are parsed from the `perf` output). > > > This fix will make it possible to use the `:ppp` tag which prevents instruction skew in `perf` results (see http://www.brendangregg.com/perf.html#EventProfiling). So the following output: > PrintAssembly processed: 142764 total address lines. > Perf output processed (skipped 7.898 seconds): > Column 1: cycles (10247 events) > > Hottest code regions (>10.00% "cycles" events): > > ....[Hottest Region 1].............................................................................. > c2, level 4, io.simonis.jmh.Synchronization::synchronizedIncrementGlobal, version 468 (221 bytes) > > 0.03% 0x00007fffe01e1f37: test $0x2,%rax > ? 0x00007fffe01e1f3d: jne 0x00007fffe01e1f63 > ? 0x00007fffe01e1f3f: or $0x1,%rax > ? 0x00007fffe01e1f43: mov %rax,(%rbx) > ? 0x00007fffe01e1f46: lock cmpxchg %rbx,(%rsi) > ?? 0x00007fffe01e1f4b: je 0x00007fffe01e1f76 > ?? 0x00007fffe01e1f51: sub %rsp,%rax > ?? 0x00007fffe01e1f54: and $0xfffffffffffff007,%rax > ?? 0x00007fffe01e1f5b: mov %rax,(%rbx) > ??? 0x00007fffe01e1f5e: jmpq 0x00007fffe01e1f76 > 0.32% ??? 0x00007fffe01e1f63: mov %rax,%r11 > 0.01% ?? 0x00007fffe01e1f66: xor %rax,%rax > 0.07% ?? 0x00007fffe01e1f69: lock cmpxchg %r15,0x3e(%r11) > 35.31% ?? 0x00007fffe01e1f6f: movq $0x3,(%rbx) > 0.15% ??? 0x00007fffe01e1f76: jne 0x00007fffe01e202b ;*synchronization entry > which obviously suffers from instruction skew because it attributes 35% of the cycles to the `movq` instruction after the `lock cmpxchg` will be fixed and look correctly like this: > PrintAssembly processed: 143768 total address lines. > Perf output processed (skipped 7.921 seconds): > Column 1: cycles:ppp (10074 events) > > Hottest code regions (>10.00% "cycles:ppp" events): > > ....[Hottest Region 1].............................................................................. > c2, level 4, io.simonis.jmh.Synchronization::synchronizedIncrementGlobal, version 481 (137 bytes) > > 0x00007fffe01e3fb7: test $0x2,%rax > 0.32% ? 0x00007fffe01e3fbd: jne 0x00007fffe01e3fe3 > ? 0x00007fffe01e3fbf: or $0x1,%rax > ? 0x00007fffe01e3fc3: mov %rax,(%rbx) > ? 0x00007fffe01e3fc6: lock cmpxchg %rbx,(%rsi) > ?? 0x00007fffe01e3fcb: je 0x00007fffe01e3ff6 > ?? 0x00007fffe01e3fd1: sub %rsp,%rax > ?? 0x00007fffe01e3fd4: and $0xfffffffffffff007,%rax > ?? 0x00007fffe01e3fdb: mov %rax,(%rbx) > ??? 0x00007fffe01e3fde: jmpq 0x00007fffe01e3ff6 > 0.01% ??? 0x00007fffe01e3fe3: mov %rax,%r11 > 0.05% ?? 0x00007fffe01e3fe6: xor %rax,%rax > 35.03% ?? 0x00007fffe01e3fe9: lock cmpxchg %r15,0x3e(%r11) > 0.21% ?? 0x00007fffe01e3fef: movq $0x3,(%rbx) > 0.26% ?? 0x00007fffe01e3ff6: jne 0x00007fffe01e40ab ;*synchronization entry I'll take a deeper look later, but right off the bat... jmh-core/src/test/java/org/openjdk/jmh/profile/PerfParseTest.java line 65: > 63: } > 64: > 65: @Test Please don't remove this test. It should verify that it parses the proper event names, now with event modifiers. This would verify that `:` are parsed/stripped correctly. ------------- Changes requested by shade (Committer). PR: https://git.openjdk.java.net/jmh/pull/9 From simonis at openjdk.java.net Thu Nov 26 10:32:17 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 26 Nov 2020 10:32:17 GMT Subject: RFR: CODETOOLS-7902799: perfasm still handles event modifiers incorrectly [v2] In-Reply-To: References: Message-ID: > Using the perfasm profiler with an event specification like `-prof perfasm:events=cycles:ppp` will result in no output because JMH won't find any events: > Secondary result "io.simonis.jmh.Synchronization.synchronizedIncrementGlobal:?asm": > PrintAssembly processed: 142164 total address lines. > Perf output processed (skipped 7.859 seconds): > Column 1: cycles:ppp (0 events) > This is because since [CODETOOLS-7901905](https://bugs.openjdk.java.net/browse/CODETOOLS-7902799) the tags are removed from the events when the perf output is parsed. But the list of profiled events (which is kept in the `AbstractPerfAsmProfiler` base class of `LinuxPerfAsmProfiler`) still keeps the original event specification with the tag. > > I've tried to normalize all event name usages in `LinuxPerfAsmProfiler` to use the event name without tags but doing so is not easy because in the end the base class will check the original events against the parsed ones in `processAssembly()/PerfEvents()` and fail (i.e. in the sense that it won't find any events). > > So in the end I gave up and simple removed the part of [CODETOOLS-7901905](https://bugs.openjdk.java.net/browse/CODETOOLS-7902799) which chops the tags from the event name. I don't think that's necessary and everything seems to still work just fine with the full name plus tags (except for a tests in `PerfParseTest.java` which had to be removed because it specifically checked that `LinuxPerfAsmProfiler.parsePerfLine()` removes tags from event names which are parsed from the `perf` output). > > > This fix will make it possible to use the `:ppp` tag which prevents instruction skew in `perf` results (see http://www.brendangregg.com/perf.html#EventProfiling). So the following output: > PrintAssembly processed: 142764 total address lines. > Perf output processed (skipped 7.898 seconds): > Column 1: cycles (10247 events) > > Hottest code regions (>10.00% "cycles" events): > > ....[Hottest Region 1].............................................................................. > c2, level 4, io.simonis.jmh.Synchronization::synchronizedIncrementGlobal, version 468 (221 bytes) > > 0.03% 0x00007fffe01e1f37: test $0x2,%rax > ? 0x00007fffe01e1f3d: jne 0x00007fffe01e1f63 > ? 0x00007fffe01e1f3f: or $0x1,%rax > ? 0x00007fffe01e1f43: mov %rax,(%rbx) > ? 0x00007fffe01e1f46: lock cmpxchg %rbx,(%rsi) > ?? 0x00007fffe01e1f4b: je 0x00007fffe01e1f76 > ?? 0x00007fffe01e1f51: sub %rsp,%rax > ?? 0x00007fffe01e1f54: and $0xfffffffffffff007,%rax > ?? 0x00007fffe01e1f5b: mov %rax,(%rbx) > ??? 0x00007fffe01e1f5e: jmpq 0x00007fffe01e1f76 > 0.32% ??? 0x00007fffe01e1f63: mov %rax,%r11 > 0.01% ?? 0x00007fffe01e1f66: xor %rax,%rax > 0.07% ?? 0x00007fffe01e1f69: lock cmpxchg %r15,0x3e(%r11) > 35.31% ?? 0x00007fffe01e1f6f: movq $0x3,(%rbx) > 0.15% ??? 0x00007fffe01e1f76: jne 0x00007fffe01e202b ;*synchronization entry > which obviously suffers from instruction skew because it attributes 35% of the cycles to the `movq` instruction after the `lock cmpxchg` will be fixed and look correctly like this: > PrintAssembly processed: 143768 total address lines. > Perf output processed (skipped 7.921 seconds): > Column 1: cycles:ppp (10074 events) > > Hottest code regions (>10.00% "cycles:ppp" events): > > ....[Hottest Region 1].............................................................................. > c2, level 4, io.simonis.jmh.Synchronization::synchronizedIncrementGlobal, version 481 (137 bytes) > > 0x00007fffe01e3fb7: test $0x2,%rax > 0.32% ? 0x00007fffe01e3fbd: jne 0x00007fffe01e3fe3 > ? 0x00007fffe01e3fbf: or $0x1,%rax > ? 0x00007fffe01e3fc3: mov %rax,(%rbx) > ? 0x00007fffe01e3fc6: lock cmpxchg %rbx,(%rsi) > ?? 0x00007fffe01e3fcb: je 0x00007fffe01e3ff6 > ?? 0x00007fffe01e3fd1: sub %rsp,%rax > ?? 0x00007fffe01e3fd4: and $0xfffffffffffff007,%rax > ?? 0x00007fffe01e3fdb: mov %rax,(%rbx) > ??? 0x00007fffe01e3fde: jmpq 0x00007fffe01e3ff6 > 0.01% ??? 0x00007fffe01e3fe3: mov %rax,%r11 > 0.05% ?? 0x00007fffe01e3fe6: xor %rax,%rax > 35.03% ?? 0x00007fffe01e3fe9: lock cmpxchg %r15,0x3e(%r11) > 0.21% ?? 0x00007fffe01e3fef: movq $0x3,(%rbx) > 0.26% ?? 0x00007fffe01e3ff6: jne 0x00007fffe01e40ab ;*synchronization entry Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: Added back test for tag parsing ------------- Changes: - all: https://git.openjdk.java.net/jmh/pull/9/files - new: https://git.openjdk.java.net/jmh/pull/9/files/49710367..18671528 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=9&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=9&range=00-01 Stats: 22 lines in 1 file changed: 22 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmh/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/9/head:pull/9 PR: https://git.openjdk.java.net/jmh/pull/9 From simonis at openjdk.java.net Thu Nov 26 10:32:18 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 26 Nov 2020 10:32:18 GMT Subject: RFR: CODETOOLS-7902799: perfasm still handles event modifiers incorrectly [v2] In-Reply-To: References: Message-ID: <3JzWTjyiPkzx_LTdj1KXIOjkhHIyxYlibvcBT5vBg20=.b68afed3-df16-4fb6-b868-631fed3ebb56@github.com> On Wed, 25 Nov 2020 19:22:09 GMT, Aleksey Shipilev wrote: >> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: >> >> Added back test for tag parsing > > jmh-core/src/test/java/org/openjdk/jmh/profile/PerfParseTest.java line 65: > >> 63: } >> 64: >> 65: @Test > > Please don't remove this test. It should verify that it parses the proper event names, now with event modifiers. This would verify that `:` are parsed/stripped correctly. Sure, I've added the test back. ------------- PR: https://git.openjdk.java.net/jmh/pull/9 From godin at openjdk.java.net Mon Nov 30 16:13:10 2020 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Mon, 30 Nov 2020 16:13:10 GMT Subject: RFR: Upgrade ASM to 9.0 Message-ID: Without this change execution of mvn archetype:generate \ -DinteractiveMode=false \ -DarchetypeGroupId=org.openjdk.jmh \ -DarchetypeArtifactId=jmh-kotlin-benchmark-archetype \ -DgroupId=org.sample \ -DartifactId=test \ -Dversion=1.0 cd test mvn package \ -Dkotlin.version=1.4.20 \ -Dkotlin.compiler.jvmTarget=11 \ -Djmh.generator=asm using JDK 11 fails with [INFO] --- exec-maven-plugin:1.2.1:java (default) @ test --- Processing 1 classes from /private/tmp/j/test/target/classes with "asm" generator Writing out Java source to /private/tmp/j/test/target/generated-sources/jmh and resources to /private/tmp/j/test/target/classes [WARNING] java.lang.reflect.InvocationTargetException at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:566) at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:297) at java.lang.Thread.run (Thread.java:834) Caused by: java.lang.IllegalArgumentException at org.objectweb.asm.ClassReader. (Unknown Source) at org.objectweb.asm.ClassReader. (Unknown Source) at org.objectweb.asm.ClassReader. (Unknown Source) at org.openjdk.jmh.generators.asm.ASMGeneratorSource.processClass (ASMGeneratorSource.java:59) at org.openjdk.jmh.generators.asm.ASMGeneratorSource.processClass (ASMGeneratorSource.java:53) at org.openjdk.jmh.generators.asm.ASMGeneratorSource.processClasses (ASMGeneratorSource.java:47) at org.openjdk.jmh.generators.bytecode.JmhBytecodeGenerator.main (JmhBytecodeGenerator.java:81) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:566) at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:297) at java.lang.Thread.run (Thread.java:834) [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE ------------- Commit messages: - Upgrade ASM to 9.0 Changes: https://git.openjdk.java.net/jmh/pull/10/files Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=10&range=00 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmh/pull/10.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/10/head:pull/10 PR: https://git.openjdk.java.net/jmh/pull/10 From shade at openjdk.java.net Mon Nov 30 17:42:09 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 30 Nov 2020 17:42:09 GMT Subject: RFR: Upgrade ASM to 9.0 In-Reply-To: References: Message-ID: <8zO4rKse1K6HtsCHJHhWONkB_kiB8r2hDUhzaWFuN3I=.7919c525-05cf-4994-8c11-0a2e1190308b@github.com> On Mon, 30 Nov 2020 10:37:19 GMT, Evgeny Mandrikov wrote: > Without this change execution of > > mvn archetype:generate \ > -DinteractiveMode=false \ > -DarchetypeGroupId=org.openjdk.jmh \ > -DarchetypeArtifactId=jmh-kotlin-benchmark-archetype \ > -DgroupId=org.sample \ > -DartifactId=test \ > -Dversion=1.0 > > cd test > > mvn package \ > -Dkotlin.version=1.4.20 \ > -Dkotlin.compiler.jvmTarget=11 \ > -Djmh.generator=asm > > using JDK 11 fails with > > [INFO] --- exec-maven-plugin:1.2.1:java (default) @ test --- > Processing 1 classes from /private/tmp/j/test/target/classes with "asm" generator > Writing out Java source to /private/tmp/j/test/target/generated-sources/jmh and resources to /private/tmp/j/test/target/classes > [WARNING] > java.lang.reflect.InvocationTargetException > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) > at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:566) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:297) > at java.lang.Thread.run (Thread.java:834) > Caused by: java.lang.IllegalArgumentException > at org.objectweb.asm.ClassReader. (Unknown Source) > at org.objectweb.asm.ClassReader. (Unknown Source) > at org.objectweb.asm.ClassReader. (Unknown Source) > at org.openjdk.jmh.generators.asm.ASMGeneratorSource.processClass (ASMGeneratorSource.java:59) > at org.openjdk.jmh.generators.asm.ASMGeneratorSource.processClass (ASMGeneratorSource.java:53) > at org.openjdk.jmh.generators.asm.ASMGeneratorSource.processClasses (ASMGeneratorSource.java:47) > at org.openjdk.jmh.generators.bytecode.JmhBytecodeGenerator.main (JmhBytecodeGenerator.java:81) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) > at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:566) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:297) > at java.lang.Thread.run (Thread.java:834) > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE You are good to go. (Ignore the test failure on Mac OS, it seems intermittent) ------------- Marked as reviewed by shade (Committer). PR: https://git.openjdk.java.net/jmh/pull/10