Forking benchmarks with long classpath on Windows (7)
Dmitry Chuyko
dmitry.chuyko at bell-sw.com
Mon Oct 16 16:56:11 UTC 2017
Hi Dávid,
Looks more like common Gradle problem. It could be probably solved by
using manifest instead, like
http://tuhrig.de/gradles-bootrun-and-windows-command-length-limit/
There's probably also an option to process dependencies and remove
transitive ones.
-Dmitry
On 10/16/2017 05:18 PM, Dávid Karnok wrote:
> Hi,
>
> I've been running JMH via Gradle from some time now on Windows (and Java
> 8u144), but my recent upgrade to Gradle 4+ lead to some problems. Gradle 4+
> seems to add so many of its own jar files (irrelevant from the target
> benchmark's perspective) to the classpath that when JMH tries to fork an
> instance, the generated command line (in Runner::getForkedMainCommand,
> System.getProperty("java.class.path")) creates a long String that, along
> with the other short parameters of JMH, now exceed Windows' 32kb limit on
> command lines, resulting in an IOException pointing to CreateProcess.
> Linux doesn't have this problem, however, the project needs at least
> someone who tests and benchmarks on Windows.
>
> Would it be possible that the Runner passed this long classpath string to
> the to-be-forked java.exe in some other way (a temporary pathing jar)?
> Alternatively, how feasible would be to support some kind of exclude filter
> at this point in the Runner?
>
> Unfortunately, I couldn't find a way to prevent Gradle (or the JMH plugin)
> itself from passing that many classpath entries when it runs JMH.
>
More information about the jmh-dev
mailing list