Hi Dmitry,
I have no particular problem with LingeredApp but it is one more special
purpose test function.
I had a similar problem with the process tests and created a JavaChild that
accepts commands and produces useful stream output used to synchronize.
It was just a thought that now with jshell there is a controllable,
flexible command driven
java runtime. It is quite a bit more complex and that might be an
issue for test reliability.
Roger
On 1/27/2016 10:36 AM, Dmitry Samersoff wrote:
Roger,
If a test need multiple processes, parent process have to control its
child. I.e. parent process have to know when child is ready to do some
work, parent process should have a way to terminate child etc.
Current tests uses different methods to control child process and not
all of them works reliably on all platforms. This problem used to create
lots of noise in test results.
About a year ago, I introduced LingeredApp.java[1] as a solution for
this problem.
It works well, and now I try to extend it to all cases where the test
need to launch a child process.
1.
http://hg.openjdk.java.net/jdk9/hs-rt/file/tip/test/lib/share/classes/jdk/test/lib/apps/LingeredApp.java
-Dmitry
On 2016-01-27 17:29, Roger Riggs wrote:
As an alternative to a specific child application would it be possible /
reasonable to use jshell
as the child? Or use the jshell API to manage the child?
Then you can feed it any java expressions/functions that are interesting
and get back any data needed.
$.02, Roger
On 1/27/2016 9:09 AM, Staffan Larsen wrote:
Have you looked at the com/sun/jdi test framework? The java framework
is quite good and stable. The shell script framework should be removed.
/Staffan
On 27 jan. 2016, at 13:02, Dmitry Samersoff
<dmitry.samers...@oracle.com> wrote:
Staffan,
1. This is one more small step forward to remove wide variety of
Exit0.java (and similar) programs from jdk tests.
I will not happen today, but I hope, sometimes in a future, all tests
that launch a child process will do it the same way.
2. We have couple of old SA-JDI tests in jdk.hotspot.agent/test these
tests have to be cleaned up and ported to JTREG, we need a framework to
do it.
3. It's hard to debug JDI failures that comes from nightly without small
standalone reproducer. Especially if emulator or slow hardware is
involved.
I use this class as a base for such reproducer, find it helpful, and
would like to have it in the test library.
-Dmitry
On 2016-01-27 10:23, Staffan Larsen wrote:
Can you explain more? There is very little information here or in the
bug about what problem you are trying to solve. Why aren’t the
current JDI tests (jdk/test/com/sun/jdi) sufficient? I have not read
your code, and I would like more background before I do so.
On 26 jan. 2016, at 22:53, Dmitry Samersoff
<dmitry.samers...@oracle.com> wrote:
Everybody,
Please review an RFE
http://cr.openjdk.java.net/~dsamersoff/JDK-8148315/webrev.01/
This fix adds basic LingeredApp based reproducer (and template for
more sophisticated reproducers) to debug JDI and underlying JVMTI
issues.
-Dmitry
-- Dmitry Samersoff Oracle Java development team, Saint Petersburg,
Russia * I would love to change the world, but they won't give me
the sources.
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
