I think this might just be a more general issue of generating too much data at VM startup, but I'm currently seeing it with +PrintInterpreter. The debuggee hangs on a write() call after printing about 64k of interpreter assembly. write() blocked in a syscall, so I'm assuming its buffers are full and it's waiting for some reads to be done. Meanwhile on the debugger side, the java backtrace looks like:

os_prio=0 tid=0x00007f85f8018800 nid=0x64da in Object.wait() [0x00007f85ffeca000]
   java.lang.Thread.State: WAITING (on object monitor)
   JavaThread state: _thread_blocked
Thread: 0x00007f85f8018800 [0x64da] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
   JavaThread state: _thread_blocked
at java.lang.Object.wait(java.base/Native Method)
- waiting on <0x00000006d6e8ad48> (a com.sun.tools.jdi.AbstractLauncher$Helper)
at java.lang.Object.wait(java.base/Object.java:516)
at com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept(jdk.jdi/AbstractLauncher.java:188)
- waiting to re-lock in wait() <0x00000006d6e8ad48> (a com.sun.tools.jdi.AbstractLauncher$Helper)
at com.sun.tools.jdi.AbstractLauncher.launch(jdk.jdi/AbstractLauncher.java:132)
at com.sun.tools.jdi.SunCommandLineLauncher.launch(jdk.jdi/SunCommandLineLauncher.java:225)
at nsk.share.jdi.Binder.localDefaultLaunchDebugee(Binder.java:266)
at nsk.share.jdi.Binder.bindToDebugeeNoWait(Binder.java:182)
at nsk.share.jdi.Binder.bindToDebugee(Binder.java:237)
at nsk.share.jdi.TestDebuggerType2.init(TestDebuggerType2.java:156)
at nsk.share.jdi.TestDebuggerType2.runIt(TestDebuggerType2.java:192)
at nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn009.forceEarlyReturn009.run(forceEarlyReturn009.java:25)
at nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn009.forceEarlyReturn009.main(forceEarlyReturn009.java:17)

As you can see this happened during the forceEarlyReturn009 test, but I'm assuming it's a more general problem. The debugger side has done some redirecting of the debuggee stdout/stderr. I haven't quite figured it all out yet. TestDebuggerType2.init() is a good place to start.