RFR(S, TESTONLY): JDK-8148315 Create a basic reproducer for JDI issues

Roger Riggs Roger.Riggs at Oracle.com
Wed Jan 27 15:45:26 UTC 2016


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.samersoff at 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.samersoff at 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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160127/8fd2c5c4/attachment.html>


More information about the serviceability-dev mailing list