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