RFR: JDK-8157850 Jar tests should pass through VM options

Andrey Nazarov andrey.x.nazarov at oracle.com
Thu May 26 16:20:42 UTC 2016


Thanks for feedback guys.

I've updated review http://cr.openjdk.java.net/~anazarov/8157850/webrev.02/

Please sponsor this patch if you are OK.

My use case is to run tests with different -Xms and -Xmx options. Mostly 
due to I need to increase heap size to gather code coverage by jcov.

--Andrey

On 25.05.2016 23:42, Jonathan Gibbons wrote:
>
>
> On 05/25/2016 01:33 PM, David Holmes wrote:
>> On 26/05/2016 6:04 AM, Jonathan Gibbons wrote:
>>> Using JAVA_OPTIONS for tools is conceptually wrong.
>>>
>>> JAVA_OPTIONS is specifically intended to pass options to VM instances,
>>> as created by a "java" command.  It is not intended that you should
>>> prefix the options with -J and use them for arbitrary tools.
>>
>> I have to agree. There is no guarantee the options being passed for 
>> the VM under test make any sense for the running of the jar tool in 
>> the jar tests. I think a number of hotspot related test options could 
>> cause problems here.
>>
>> Are there specific VM options that people think should be passed 
>> through? The bug report has no detail at all.
>>
>> David
>
> Generally, I think that blindly passing through all the options 
> regardless is as bad a programming practice as never passing them 
> though.  There are some that make sense to all VMs, like -ea, -esa 
> etc, and maybe system properties, but for those, the VM options 
> mechanism is generally good enough.  (i.e. system properties 
> test.vm.opts, test.tool.vm.opts)
>
> From a jtreg point of view, I'd be interested to know uses cases for 
> passing additional more specific options to the VMs used to run tools 
> like jar, jlink, javac, etc
>
> -- Jon.
>
>
>
>>
>>> The code in the webrev is also perverse for taking the trouble to split
>>> the string to a stream, collect the results into a list, convert the
>>> list back into a stream again and use .forEach.
>>>
>>> You could do better, and much simpler, with something like
>>>
>>>     if (!option.isEmpty()) {
>>> commands.addAll(Arrays.asList(option.split("\\s+",-1)));
>>>     }
>>>
>>> -- Jon
>>>
>>>
>>> On 05/25/2016 10:48 AM, Martin Buchholz wrote:
>>>> Hi Andrey,
>>>>
>>>> Looking at http://openjdk.java.net/jtreg/vmoptions.html,
>>>> I see we have both test.vm.opts and test.tool.vm.opts
>>>> and the latter is supposed to take care of adding "-J".
>>>>
>>>> +        VM_OPTIONS.stream().map(opt -> "-J" +
>>>> opt).forEach(commands::add);
>>>> +        JAVA_OPTIONS.stream().map(opt -> "-J" +
>>>> opt).forEach(commands::add);
>>>>
>>>> ---
>>>>
>>>> Maybe splitting on "\\s+" would be better.
>>>>
>>>> ---
>>>>
>>>> I think we should have test library methods to return the List<String>
>>>> for java subprocesses, one that could try hard to get the option
>>>> tokenization correct.
>>>>
>>>> ---
>>>>
>>>>
>>>> On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov
>>>> <andrey.x.nazarov at oracle.com> wrote:
>>>>> Some jar tests start VMs without passing vmoptions from jtreg.
>>>>>
>>>>> This fix pass jtreg's vmoptions and javaoptions to processes(java, 
>>>>> jar,
>>>>> javac) started by tests.
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/
>>>>>
>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8157850
>>>>>
>>>>> --Andrey
>>>>>
>>>
>




More information about the core-libs-dev mailing list