Forking benchmarks with long classpath on Windows (7)

[Dávid Karnok]

Hi.

I have found those posts but they don't work for me as the code to be
benchmarked is part of a library, not a Java app or Spring boot.

As I understand, the main JMH program is started with the very same large
set of classpath entries successfully. The problem after that is with the
forking of new JMH instances by a parent JMH itself.

2017-10-16 18:56 GMT+02:00 Dmitry Chuyko <dmitry.chuyko at bell-sw.com>:

> 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.
>>
>>
>


-- 
Best regards,
David Karnok