[PATCH]: Forking benchmarks with long classpath on Windows (7)

[Dávid Karnok]

Hello!

I'd like to submit a patch (attached) to JMH's
org.openjdk.jmh.runner.Runner.java that creates a temporary jar file with
all classpath entries on Windows so that the command line doesn't overflow.



2017-10-16 19:09 GMT+02:00 Dávid Karnok <akarnokd at gmail.com>:

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



-- 
Best regards,
David Karnok