On 2015-05-28 16:45, Yekaterina Kantserova wrote:
Hi,
due to https://bugs.openjdk.java.net/browse/JDK-8081381 I wasn't able
to push this fix. The problem is LingeredApp.java contains JDK 9
feature java.lang.Process.getPid() but the test library is compiled
with JDK 8 today. This issue is not trivial to solve so I suggest a
temporary fix to test/lib/Makefile.
webrev root: http://cr.openjdk.java.net/~ykantser/8081037/webrev.01
The temporary fix looks good from a build perspective, I guess, as long
as you're satisfied with the lib including just the files in hprof.
It looks like https://bugs.openjdk.java.net/browse/JDK-8081381 is in the
intersection between hotspot testing and the build infrastructure.
Please keep us in the loop when discussion solutions to that.
/Magnus
Thanks,
Katja
On 05/27/2015 03:02 PM, Yekaterina Kantserova wrote:
Hi,
Could I please have a review of this fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8081037
webrev root: http://cr.openjdk.java.net/~ykantser/8081037/webrev.00
webrev jdk: http://cr.openjdk.java.net/~ykantser/8081037.jdk/webrev.00
webrev hotspot:
http://cr.openjdk.java.net/~ykantser/8081037.hotspot/webrev.00
From the bug:
"The problem is most likely that SA will pause the target process
while it is running. In this case, the target process is the same as
the process that launched SA. That process is also handling the
output from SA over a pipe, but when that pipe fills up the process
cannot empty it and the SA process is blocked because it cannot write
any more output. Deadlock."
The solutions is to start a separate target process. Dmitry Samersoff
has already created a test application for such cases so I've decided
to move it on the top level library instead of duplicating it. The
test application will reside under
test/lib/share/classes/jdk/test/lib/apps and the test under
test/lib-test/jdk/test/lib/apps.
Thanks,
Katja
