RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file

David Holmes david.holmes at oracle.com
Thu Apr 9 00:35:27 UTC 2020


Looks good.

Thanks,
David

On 9/04/2020 3:27 am, Evgeny Nikitin wrote:
> Thanks to Igor Ignatyev, a new version is available at
> 
> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.02
> 
> Regards,
> Evgeny.
> 
> 
> On 2020-04-08 17:19, Igor Ignatev wrote:
>> You can use %n in printf to get a system-specific newline.
>>
>> — Igor
>>
>>> On Apr 8, 2020, at 8:12 AM, Evgeny Nikitin 
>>> <evgeny.nikitin at oracle.com> wrote:
>>>
>>> Hi David,
>>>
>>>>   > You can use printf rather than making a separate call to format.
>>>> Good point, I've missed that method. I'll fix it and ask Igor to change
>>>> the webrev.
>>>
>>> I finally decided to leave it as it is now, since printf doesn't add 
>>> a newline and System.lineSeparator() is not shorter than 
>>> String.format() :). Please let me know if you disagree.
>>>
>>> Best regards,
>>> Evgeny.
>>>
>>>
>>>> On 2020-04-07 16:09, Evgeny Nikitin wrote:
>>>> Hi David,
>>>>> why did you introduce a new block scope?
>>>> To separate the action block from the other code. "A Poor/lazy man's 
>>>> method". I've preferred to lay it out this way because it makes the 
>>>> code more compact and easy to read (as opposing to looking for a 
>>>> only-once used method in some other part of the file) and due to the 
>>>> confusing name of OutputAnalyzer type (which I need as a storage for 
>>>> output, not as some analyzer). Creating a method with OutputAnalyzer 
>>>> as a parameter would make this method's purpose even more confusing.
>>>>> You can use printf rather than making a separate call to format.
>>>> Good point, I've missed that method. I'll fix it and ask Igor to 
>>>> change the webrev.
>>>> Regards,
>>>> Evgeny.
>>>>> On 2020-04-07 14:50, David Holmes wrote:
>>>>> Hi Evgeny,
>>>>>
>>>>> On 7/04/2020 6:33 pm, Evgeny Nikitin wrote:
>>>>>> Hi David,
>>>>>>
>>>>>>> I'm not at all sure this is generally what we want for every 
>>>>>>> single test that uses ProcessTools! But I'm willing it to see it 
>>>>>>> trialed.
>>>>>>
>>>>>> Well, it's mostly used for test VM runs. In runs I performed 
>>>>>> (artificial "failures" included) the amounts of output were very 
>>>>>> small.
>>>>>>
>>>>>>> Please run full tier testing at least to tier 6 and ideally 
>>>>>>> beyond before pushing this. There are potential implications for 
>>>>>>> temporary (and more permanent) disk usage as well as additional 
>>>>>>> time needed to write files out to disk. (Hopefully these are 
>>>>>>> generally small enough that this doesn't make a noticeable 
>>>>>>> difference.)
>>>>>> Done, thanks for suggestion. The additional runs showed no problems.
>>>>>
>>>>> Good to know - thanks.
>>>>>
>>>>>> I've provided Igor with a slightly modified version (Added 
>>>>>> notification about the output file into the main test's log). 
>>>>>> Please review:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.01/
>>>>>
>>>>> A couple of minor nits:
>>>>>
>>>>>   397             {
>>>>>
>>>>> why did you introduce a new block scope?
>>>>>
>>>>>   404                 System.out.println(String.format(
>>>>>
>>>>> You can use printf rather than making a separate call to format.
>>>>>
>>>>> No need to see any update if you chose to make it.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> -----
>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Evgeny.
>>>>>>
>>>>>> On 2020-04-02 02:07, David Holmes wrote:
>>>>>>> Thanks for sharing this Igor!
>>>>>>>
>>>>>>> I'm not at all sure this is generally what we want for every 
>>>>>>> single test that uses ProcessTools! But I'm willing it to see it 
>>>>>>> trialed.
>>>>>>>
>>>>>>> Evgeny: Please run full tier testing at least to tier 6 and 
>>>>>>> ideally beyond before pushing this. There are potential 
>>>>>>> implications for temporary (and more permanent) disk usage as 
>>>>>>> well as additional time needed to write files out to disk. 
>>>>>>> (Hopefully these are generally small enough that this doesn't 
>>>>>>> make a noticeable difference.)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> On 2/04/2020 5:13 am, Igor Ignatyev wrote:
>>>>>>>> Hi Evgeny,
>>>>>>>>
>>>>>>>> (widening the audience, given this affects not just hotspot 
>>>>>>>> compiler, but hotspot tests as well as core libs tests in general)
>>>>>>>>
>>>>>>>> overall that looks good to me. one suggestion, for the ease of 
>>>>>>>> failure analysis it might be worth to print out the names of 
>>>>>>>> created files, although this might potentially clutter the 
>>>>>>>> output, I don't think it'll be a problem given we already print 
>>>>>>>> out things like 'Gathering output for process ...' , 'Waiting 
>>>>>>>> for completion...' in LazyOutputBuffer.
>>>>>>>>
>>>>>>>>> The change has been tested via a mach5 test runs (jdk-tier1 
>>>>>>>>> through 4) on the 4 common platforms (linux-x64, windows-x64, 
>>>>>>>>> macosx-x64, sparcv9).
>>>>>>>> this doesn't include any of hotspot tiers, could you please also 
>>>>>>>> run hs-tier1--4?
>>>>>>>> // you can use tierN jobs which include both jdk and hs parts.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -- Igor
>>>>>>>>
>>>>>>>>> On Mar 30, 2020, at 3:55 AM, Evgeny Nikitin 
>>>>>>>>> <evgeny.nikitin at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174768
>>>>>>>>>
>>>>>>>>> Webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.00/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The bug had been created as a request to simplify investigation 
>>>>>>>>> for compiler control tests failures.
>>>>>>>>> I found the functionality pretty generic and useful and made 
>>>>>>>>> ProcessTools dump output as well as some diagnostic information 
>>>>>>>>> for every executed process into a separate file.
>>>>>>>>> The diagnostic information contains cmdline, exit code, stdout 
>>>>>>>>> and stderr. The output files are named like 
>>>>>>>>> 'pid-<PID>-output.log'.
>>>>>>>>>
>>>>>>>>> The change has been tested via a mach5 test runs (jdk-tier1 
>>>>>>>>> through 4) on the 4 common platforms (linux-x64, windows-x64, 
>>>>>>>>> macosx-x64, sparcv9).
>>>>>>>>>
>>>>>>>>> Please review,
>>>>>>>>> /Evgeny Nikitin.
>>>>>>>>
>>


More information about the core-libs-dev mailing list