RFR: JDK-8131784 : Add tracing info to LowMemoryTest.java to help 8130339 diagnosis

[olivier.lagneau at oracle.com]

Hi Jaroslav,

Thanks for reviewing this fix. Comments inlined.

Olivier.

On 30/07/2015 19:13, Jaroslav Bachorik wrote:
> Hi Olivier,
>
> On 30.7.2015 18:55, olivier.lagneau at oracle.com wrote:
>> Hi,
>>
>> Could you please review this fix:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8131784
>> webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.00/
>>
>> We add tracing information to help diagnosing master bug problem
>> (https://bugs.openjdk.java.net/browse/JDK-8130339),
>> and we will monitor the quarantined runs to check for any failure and
>> get more diagnosis info.
>>
>> Since the test already provides some information which is not collected
>> when it fails with timeout,
>> the idea is to collect subprocess I/O (stdout, stderr) by using
>> ProcessTools.startProcess rather
>> that OutputAnalyzer.executeProcess. The subprocess I/Os will be
>> collected while it's running
>> rather than waiting the subprocess termination.
>>
>> A few additional infos have also been added to get more information.
>>
>> Note that this "tracing" change should be temporary and will be removed
>> when a fix for 8130339 has been found.
>
> Instead of `ProcessTools.startProcess(prefixName, pb, (l) -> {return 
> true;} );` at line 132 you can do 
> `ProcessTools.startProcess(prefixName, pb, null);`. It will have the 
> same effect.
This needs to be casted : "ProcessTools.startProcess(prefixName, pb, 
(Consumer<String>) null)",
but then it's identical to startProcess(prefixName, pb) call available 
in ProcessTools. I tried that
first a few days ago and that did not work (could not find reason), thus 
explored others possibilities
and "(l) -> {return true;}" worked. Thus kept that.

Retried today and StartProcess(prefixName, pb) worked ! So moving back 
to that.

>
> Why is that 2 seconds sleep necessary at line 135?
A few days ago I got intertwined output messages coming from 
subprocesses (like a serialGC message
in the middle of ParallelGC messages). Having this sleep solved these 
mixed messages.
Anyway tried again today without the sleep call lot of times and did not 
get this mix.
Thus suppressing this sleep.

>
> L373 and L384 - better use 'SweeperThread' instead of 'SweepThread' to 
> correspond to the class name.
Already existing messages where using SweepThread. Kept that spelling 
(even if unhappy with that).

But right It's better using SweeperThread. Changing it.


>
> -JB-
>
>>
>> Thanks,
>> Olivier.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150731/0cded151/attachment-0001.html>