testbug: java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java fails on MacOS

The test is regularly erroring out with the log
----------System.err:(15/937)----------

java.lang.RuntimeException: The sub process has not exited!
at RemoveDropTargetCrashTest.runProcess(RemoveDropTargetCrashTest.java:325)
at RemoveDropTargetCrashTest.main(RemoveDropTargetCrashTest.java:80)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:830)

JavaTest Message: Test threw exception: java.lang.RuntimeException: The sub process has not exited!
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: The sub process has not exited!

----------------

This is a self-inflicted test timeout, that reports as a failure rather than a jtreg timeout error.

It execs a child process and waits for 100 seconds.

By instrumenting the test running on the system I was able to see that the test
takes about 114 seconds on this system !

execing test at : 1558570189 <<< system time in secs at which the parent execs the child
test exited at : 1558570290 <<< system time in secs at which the parent stops waiting
starting test at : 1558570190 <<< time the test loop (within the child) starts
starting loop 0 at : 1558570190
starting loop 1 at : 1558570203
starting loop 2 at : 1558570214
starting loop 3 at : 1558570225
starting loop 4 at : 1558570236
starting loop 5 at : 1558570247
starting loop 6 at : 1558570258
starting loop 7 at : 1558570270
starting loop 8 at : 1558570281
starting loop 9 at : 1558570292
ending test at : 1558570303 <<< time the test loop is done and the child is ready to exit.

So this seems like a case where upping the timeout to 200 should cure it ..