[ping] Re: RFR 8141526: Allow to collect stdout/stderr from the FinalizationRunner even before the process returns
Jaroslav Bachorik
jaroslav.bachorik at oracle.com
Wed Nov 25 16:41:23 UTC 2015
On 6.11.2015 17:11, Jaroslav Bachorik wrote:
> [wider audience included]
>
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8141526
> Webrev:
> top> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00
> hotspot> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/hotspot
> jdk> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/jdk
>
> After the fix for https://bugs.openjdk.java.net/browse/JDK-8135188 we
> are not able to get the debug info about the run of the launcher
> FinalizationRunner application in case it gets stuck and harness times
> out. This is because the stdout/err of the application started via
> ProcessTools.executeProcess() is collected only after the application
> has exited.
>
> The solution is to use ProcessTools.startProcess() and consume the
> application stdout/err in a streaming mode. Because this method has only
> been available in the 'jdk' version of ProcessTools and not in the
> 'hotspot' one I decided to merge both of those versions and place the
> merged version into the shared location 'test/lib/share/classes/'.
> During this I decided to change the package for the shared ProcessTools
> class to be 'jdk.test.lib.process' to be more in line with the way this
> shared library is structured. I had to move few other lib classes
> required by ProcessTools to the shared lib as well. All the moved lib
> classes have been marked as deprecated in their original location.
>
>
> Thanks,
>
> -JB-
>
More information about the serviceability-dev
mailing list