From robert.field at oracle.com Fri Jul 10 19:36:33 2020 From: robert.field at oracle.com (Robert Field) Date: Fri, 10 Jul 2020 12:36:33 -0700 Subject: RFR 8248157: JShell: throws AssertionError when creating a variable with some unicode chars Message-ID: <91f89609-5615-d447-5332-119f601369d0@oracle.com> Unicode in JShell is a broader issue, as covered in the issues I've just added as falling out from this: ?? 8249197: JShell: variable declaration with unicode type name gets garbled result https://bugs.openjdk.java.net/browse/JDK-8249197 ?? 8249199: JShell: Consistent representation of unicode https://bugs.openjdk.java.net/browse/JDK-8249199 This fix is for the narrow problem specified in the bug report. Webrev: http://cr.openjdk.java.net/~rfield/8248157v0.webrev/ Thanks, Robert From talden at gmail.com Mon Jul 13 02:24:23 2020 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Mon, 13 Jul 2020 14:24:23 +1200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> Message-ID: This still exists in JDK 15 build 31. Is any other Windows user able to reproduce this? I have two machines, one laptop and one desktop that show a CPU thread constantly @ 100% just by starting JShell. For the desktop machine that's not a major issue but for the laptop this spins up the fans and eats the battery. JShell in JDK 14 is fine. I've yet to hear of any other user confirming this issue. -- Aaron Scott-Boddendijk On Fri, Jun 26, 2020 at 2:00 PM Aaron Scott-Boddendijk wrote: > Just confirming that: > > * This still exists in JDK 15 build 29 > * Occurs on multiple unrelated Windows 10 machines with differing major > versions of the OS. > * Does not occur in JDK 14.01 on these machines (OpenJDK 64-Bit Server VM > Zulu14.28+21-CA) > * Does not appear to occur on Linux > > -- > Aaron Scott-Boddendijk > > > On Tue, Jun 16, 2020 at 11:16 AM Aaron Scott-Boddendijk > wrote: > >> This is the thread-dump from the JVM that VisualVM sees as using a core... >> >> 2020-06-16 11:07:35 >> Full thread dump OpenJDK 64-Bit Server VM (15-ea+27-1372 mixed mode, >> sharing): >> >> Threads class SMR info: >> _java_thread_list=0x000001e34a6040f0, length=23, elements={ >> 0x000001e31c1a1dc0, 0x000001e349035ee0, 0x000001e349037250, >> 0x000001e349058ae0, >> 0x000001e34905c5b0, 0x000001e34905f710, 0x000001e3490603f0, >> 0x000001e349065140, >> 0x000001e34906d620, 0x000001e349b36a20, 0x000001e349b8c690, >> 0x000001e349da3400, >> 0x000001e349daa7c0, 0x000001e349dbb640, 0x000001e34a141140, >> 0x000001e349d555c0, >> 0x000001e34b07f030, 0x000001e34a461c90, 0x000001e34a45fae0, >> 0x000001e34a45ffb0, >> 0x000001e34a4617c0, 0x000001e34a462160, 0x000001e34a45f610 >> } >> >> "main" #1 prio=5 os_prio=0 cpu=1078.13ms elapsed=341.81s >> tid=0x000001e31c1a1dc0 nid=0x16b0 in Object.wait() [0x000000340d9fe000] >> java.lang.Thread.State: TIMED_WAITING (on object monitor) >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> - waiting on >> at >> jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 15-ea >> /NonBlockingInputStreamImpl.java:139) >> - locked <0x000000060fe87338> (a >> jdk.internal.jshell.tool.ConsoleIOContext$1) >> at >> jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea >> /NonBlockingInputStream.java:62) >> at >> jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 15-ea >> /NonBlocking.java:168) >> at >> jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea >> /NonBlockingReader.java:57) >> at >> jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 15-ea >> /BindingReader.java:160) >> at >> jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea >> /BindingReader.java:110) >> at >> jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea >> /BindingReader.java:61) >> at >> jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 15-ea >> /LineReaderImpl.java:913) >> at >> jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 15-ea >> /LineReaderImpl.java:946) >> at >> jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 15-ea >> /ConsoleIOContext.java:154) >> at >> jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea >> /LineReaderImpl.java:637) >> at >> jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea >> /LineReaderImpl.java:454) >> at >> jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 15-ea >> /ConsoleIOContext.java:229) >> at jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 15-ea >> /JShellTool.java:1254) >> at jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 15-ea >> /JShellTool.java:1190) >> at jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 15-ea >> /JShellTool.java:991) >> at >> jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 15-ea >> /JShellToolBuilder.java:254) >> at >> jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 15-ea >> /JShellToolProvider.java:120) >> >> Locked ownable synchronizers: >> - None >> >> "Reference Handler" #2 daemon prio=10 os_prio=2 cpu=0.00ms >> elapsed=341.79s tid=0x000001e349035ee0 nid=0x13fc waiting on condition >> [0x000000340e0fe000] >> java.lang.Thread.State: RUNNABLE >> at >> java.lang.ref.Reference.waitForReferencePendingList(java.base at 15-ea/Native >> Method) >> at >> java.lang.ref.Reference.processPendingReferences(java.base at 15-ea >> /Reference.java:241) >> at java.lang.ref.Reference$ReferenceHandler.run(java.base at 15-ea >> /Reference.java:213) >> >> Locked ownable synchronizers: >> - None >> >> "Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=341.79s >> tid=0x000001e349037250 nid=0x2a60 in Object.wait() [0x000000340e1fe000] >> java.lang.Thread.State: WAITING (on object monitor) >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> - waiting on <0x0000000601400bc0> (a >> java.lang.ref.ReferenceQueue$Lock) >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea >> /ReferenceQueue.java:155) >> - locked <0x0000000601400bc0> (a >> java.lang.ref.ReferenceQueue$Lock) >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea >> /ReferenceQueue.java:176) >> at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 15-ea >> /Finalizer.java:170) >> >> Locked ownable synchronizers: >> - None >> >> "Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=341.78s >> tid=0x000001e349058ae0 nid=0x35c8 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> Locked ownable synchronizers: >> - None >> >> "Attach Listener" #5 daemon prio=5 os_prio=2 cpu=125.00ms elapsed=341.78s >> tid=0x000001e34905c5b0 nid=0x3e0c waiting on condition [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> Locked ownable synchronizers: >> - None >> >> "Service Thread" #6 daemon prio=9 os_prio=0 cpu=0.00ms elapsed=341.78s >> tid=0x000001e34905f710 nid=0x398c runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> Locked ownable synchronizers: >> - None >> >> "C2 CompilerThread0" #7 daemon prio=9 os_prio=2 cpu=1781.25ms >> elapsed=341.78s tid=0x000001e3490603f0 nid=0xcf0 waiting on condition >> [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> No compile task >> >> Locked ownable synchronizers: >> - None >> >> "C1 CompilerThread0" #10 daemon prio=9 os_prio=2 cpu=765.63ms >> elapsed=341.78s tid=0x000001e349065140 nid=0x3e54 waiting on condition >> [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> No compile task >> >> Locked ownable synchronizers: >> - None >> >> "Sweeper thread" #11 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=341.78s >> tid=0x000001e34906d620 nid=0x38bc runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> Locked ownable synchronizers: >> - None >> >> "Notification Thread" #12 daemon prio=9 os_prio=0 cpu=0.00ms >> elapsed=341.76s tid=0x000001e349b36a20 nid=0x49b8 runnable >> [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> Locked ownable synchronizers: >> - None >> >> "Common-Cleaner" #13 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=341.75s >> tid=0x000001e349b8c690 nid=0x26e4 in Object.wait() [0x000000340eaff000] >> java.lang.Thread.State: TIMED_WAITING (on object monitor) >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> - waiting on >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea >> /ReferenceQueue.java:155) >> - locked <0x0000000601401a78> (a >> java.lang.ref.ReferenceQueue$Lock) >> at jdk.internal.ref.CleanerImpl.run(java.base at 15-ea >> /CleanerImpl.java:148) >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> at jdk.internal.misc.InnocuousThread.run(java.base at 15-ea >> /InnocuousThread.java:134) >> >> Locked ownable synchronizers: >> - None >> >> "JDI Internal Event Handler" #17 daemon prio=5 os_prio=0 cpu=15.63ms >> elapsed=341.39s tid=0x000001e349da3400 nid=0x68 in Object.wait() >> [0x000000340effe000] >> java.lang.Thread.State: WAITING (on object monitor) >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> - waiting on >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) >> at com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea >> /EventQueueImpl.java:190) >> - locked <0x000000060154b630> (a com.sun.tools.jdi.EventQueueImpl) >> at com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 15-ea >> /EventQueueImpl.java:125) >> at com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 15-ea >> /InternalEventHandler.java:61) >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> Locked ownable synchronizers: >> - None >> >> "JDI Target VM Interface" #16 daemon prio=5 os_prio=0 cpu=46.88ms >> elapsed=341.39s tid=0x000001e349daa7c0 nid=0x3d04 runnable >> [0x000000340f0fe000] >> java.lang.Thread.State: RUNNABLE >> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native >> Method) >> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea >> /SocketDispatcher.java:46) >> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea >> /NioSocketImpl.java:261) >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea >> /NioSocketImpl.java:312) >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea >> /NioSocketImpl.java:350) >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea >> /NioSocketImpl.java:803) >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >> /Socket.java:981) >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >> /Socket.java:976) >> at com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 15-ea >> /SocketConnection.java:82) >> - locked <0x000000060154b998> (a java.lang.Object) >> at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 15-ea >> /TargetVM.java:124) >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> Locked ownable synchronizers: >> - <0x0000000601577110> (a >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> >> "event-handler" #18 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=341.38s >> tid=0x000001e349dbb640 nid=0x203c in Object.wait() [0x000000340edfe000] >> java.lang.Thread.State: WAITING (on object monitor) >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> - waiting on >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) >> at com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea >> /EventQueueImpl.java:190) >> - locked <0x000000060154bc28> (a com.sun.tools.jdi.EventQueueImpl) >> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea >> /EventQueueImpl.java:97) >> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea >> /EventQueueImpl.java:83) >> at jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 15-ea >> /JdiEventHandler.java:79) >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> Locked ownable synchronizers: >> - None >> >> "output reader" #19 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=341.31s >> tid=0x000001e34a141140 nid=0x49c0 runnable [0x000000340eeff000] >> java.lang.Thread.State: RUNNABLE >> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native >> Method) >> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea >> /SocketDispatcher.java:46) >> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea >> /NioSocketImpl.java:261) >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea >> /NioSocketImpl.java:312) >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea >> /NioSocketImpl.java:350) >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea >> /NioSocketImpl.java:803) >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >> /Socket.java:981) >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >> /Socket.java:976) >> at java.io.FilterInputStream.read(java.base at 15-ea >> /FilterInputStream.java:82) >> at jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 15-ea >> /DemultiplexInput.java:58) >> >> Locked ownable synchronizers: >> - <0x0000000601553510> (a >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> >> "Thread-0" #21 daemon prio=5 os_prio=0 cpu=312.50ms elapsed=341.22s >> tid=0x000001e349d555c0 nid=0x4d88 waiting on condition [0x000000340f1fe000] >> java.lang.Thread.State: WAITING (parking) >> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native Method) >> - parking to wait for <0x0000000601550fc0> (a >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >> at java.util.concurrent.locks.LockSupport.park(java.base at 15-ea >> /LockSupport.java:341) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 15-ea >> /AbstractQueuedSynchronizer.java:505) >> at java.util.concurrent.ForkJoinPool.managedBlock(java.base at 15-ea >> /ForkJoinPool.java:3137) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea >> /AbstractQueuedSynchronizer.java:1614) >> at java.util.concurrent.LinkedBlockingQueue.take(java.base at 15-ea >> /LinkedBlockingQueue.java:435) >> at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea >> /ThreadPoolExecutor.java:1056) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea >> /ThreadPoolExecutor.java:1116) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea >> /ThreadPoolExecutor.java:630) >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> Locked ownable synchronizers: >> - None >> >> "Thread-2" #23 daemon prio=5 os_prio=0 cpu=338859.38ms elapsed=340.58s >> tid=0x000001e34b07f030 nid=0xac0 runnable [0x000000340f3fe000] >> java.lang.Thread.State: RUNNABLE >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea >> /AbstractQueuedSynchronizer.java:1749) >> at >> jdk.internal.org.jline.utils.NonBlockingPumpReader.read(jdk.internal.le at 15-ea >> /NonBlockingPumpReader.java:77) >> at >> jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea >> /NonBlockingReader.java:57) >> at >> jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read(jdk.internal.le at 15-ea >> /NonBlocking.java:104) >> at >> jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea >> /NonBlockingInputStream.java:36) >> at >> jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 15-ea >> /StopDetectingInputStream.java:66) >> at >> jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$410/0x0000000800d2eb28.run(jdk.jshell at 15-ea/Unknown >> Source) >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> Locked ownable synchronizers: >> - <0x00000006028b4318> (a >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> >> "WindowsStreamPump" #25 daemon prio=5 os_prio=0 cpu=0.00ms >> elapsed=340.53s tid=0x000001e34a461c90 nid=0x3688 runnable >> [0x000000340f4fe000] >> java.lang.Thread.State: RUNNABLE >> at >> jdk.internal.org.jline.terminal.impl.jna.win.Kernel32Impl.WaitForSingleObject(jdk.internal.le at 15-ea/Native >> Method) >> at >> jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.readConsoleInput(jdk.internal.le at 15-ea >> /JnaWinSysTerminal.java:185) >> at >> jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.processConsoleInput(jdk.internal.le at 15-ea >> /JnaWinSysTerminal.java:108) >> at >> jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal.pump(jdk.internal.le at 15-ea >> /AbstractWindowsTerminal.java:465) >> at >> jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal$$Lambda$417/0x0000000800d310f8.run(jdk.internal.le at 15-ea/Unknown >> Source) >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> Locked ownable synchronizers: >> - None >> >> "null non blocking reader thread" #26 daemon prio=5 os_prio=0 cpu=0.00ms >> elapsed=340.26s tid=0x000001e34a45fae0 nid=0x488 in Object.wait() >> [0x000000340f6ff000] >> java.lang.Thread.State: WAITING (on object monitor) >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> - waiting on >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) >> at >> jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 15-ea >> /StopDetectingInputStream.java:98) >> - locked <0x0000000601e2b650> (a >> jdk.internal.jshell.tool.StopDetectingInputStream) >> at >> jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 15-ea >> /NonBlockingInputStreamImpl.java:216) >> at >> jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$584/0x0000000800d4f088.run(jdk.internal.le at 15-ea/Unknown >> Source) >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> Locked ownable synchronizers: >> - None >> >> "RMI TCP Accept-0" #27 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=180.89s >> tid=0x000001e34a45ffb0 nid=0x45f0 runnable [0x000000340d8fe000] >> java.lang.Thread.State: RUNNABLE >> at sun.nio.ch.Net.accept(java.base at 15-ea/Native Method) >> at sun.nio.ch.NioSocketImpl.accept(java.base at 15-ea >> /NioSocketImpl.java:755) >> at java.net.ServerSocket.implAccept(java.base at 15-ea >> /ServerSocket.java:684) >> at java.net.ServerSocket.platformImplAccept(java.base at 15-ea >> /ServerSocket.java:650) >> at java.net.ServerSocket.implAccept(java.base at 15-ea >> /ServerSocket.java:626) >> at java.net.ServerSocket.implAccept(java.base at 15-ea >> /ServerSocket.java:583) >> at java.net.ServerSocket.accept(java.base at 15-ea >> /ServerSocket.java:540) >> at >> sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(jdk.management.agent at 15-ea >> /LocalRMIServerSocketFactory.java:52) >> at >> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi at 15-ea >> /TCPTransport.java:413) >> at >> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi at 15-ea >> /TCPTransport.java:377) >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> Locked ownable synchronizers: >> - <0x0000000602e53118> (a >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> >> "RMI TCP Connection(1)-10.0.201.131" #28 daemon prio=5 os_prio=0 >> cpu=437.50ms elapsed=180.87s tid=0x000001e34a4617c0 nid=0x4790 runnable >> [0x000000340fbfe000] >> java.lang.Thread.State: RUNNABLE >> at sun.nio.ch.Net.poll(java.base at 15-ea/Native Method) >> at sun.nio.ch.NioSocketImpl.park(java.base at 15-ea >> /NioSocketImpl.java:181) >> at sun.nio.ch.NioSocketImpl.timedRead(java.base at 15-ea >> /NioSocketImpl.java:285) >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea >> /NioSocketImpl.java:309) >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea >> /NioSocketImpl.java:350) >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea >> /NioSocketImpl.java:803) >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >> /Socket.java:981) >> at java.io.BufferedInputStream.fill(java.base at 15-ea >> /BufferedInputStream.java:244) >> at java.io.BufferedInputStream.read(java.base at 15-ea >> /BufferedInputStream.java:263) >> - locked <0x0000000602e19470> (a java.io.BufferedInputStream) >> at java.io.FilterInputStream.read(java.base at 15-ea >> /FilterInputStream.java:82) >> at >> sun.rmi.transport.tcp.TCPTransport.handleMessages(java.rmi at 15-ea >> /TCPTransport.java:569) >> at >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(java.rmi at 15-ea >> /TCPTransport.java:828) >> at >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(java.rmi at 15-ea >> /TCPTransport.java:705) >> at >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$686/0x0000000800da3998.run(java.rmi at 15-ea/Unknown >> Source) >> at >> java.security.AccessController.executePrivileged(java.base at 15-ea >> /AccessController.java:753) >> at java.security.AccessController.doPrivileged(java.base at 15-ea >> /AccessController.java:391) >> at >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(java.rmi at 15-ea >> /TCPTransport.java:704) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea >> /ThreadPoolExecutor.java:1130) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea >> /ThreadPoolExecutor.java:630) >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> Locked ownable synchronizers: >> - <0x0000000602e19708> (a >> java.util.concurrent.ThreadPoolExecutor$Worker) >> - <0x0000000602e59038> (a >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> >> "RMI Scheduler(0)" #29 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=180.86s >> tid=0x000001e34a462160 nid=0x1df0 waiting on condition [0x000000340fcfe000] >> java.lang.Thread.State: TIMED_WAITING (parking) >> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native Method) >> - parking to wait for <0x0000000602e1af00> (a >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >> at >> java.util.concurrent.locks.LockSupport.parkNanos(java.base at 15-ea >> /LockSupport.java:252) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 15-ea >> /AbstractQueuedSynchronizer.java:1661) >> at >> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea >> /ScheduledThreadPoolExecutor.java:1182) >> at >> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea >> /ScheduledThreadPoolExecutor.java:899) >> at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea >> /ThreadPoolExecutor.java:1056) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea >> /ThreadPoolExecutor.java:1116) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea >> /ThreadPoolExecutor.java:630) >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> Locked ownable synchronizers: >> - None >> >> "JMX server connection timeout 30" #30 daemon prio=5 os_prio=0 cpu=0.00ms >> elapsed=180.86s tid=0x000001e34a45f610 nid=0x2fe8 in Object.wait() >> [0x000000340fdff000] >> java.lang.Thread.State: TIMED_WAITING (on object monitor) >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> - waiting on >> at >> com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(java.management at 15-ea >> /ServerCommunicatorAdmin.java:171) >> - locked <0x0000000602e1ca08> (a [I) >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> Locked ownable synchronizers: >> - None >> >> "VM Thread" os_prio=2 cpu=515.63ms elapsed=341.79s tid=0x000001e349031eb0 >> nid=0x540 runnable >> >> "GC Thread#0" os_prio=2 cpu=328.13ms elapsed=341.80s >> tid=0x000001e31c218710 nid=0x19e8 runnable >> >> "GC Thread#1" os_prio=2 cpu=265.63ms elapsed=341.53s >> tid=0x000001e349b353d0 nid=0x1cc4 runnable >> >> "GC Thread#2" os_prio=2 cpu=218.75ms elapsed=340.37s >> tid=0x000001e349b350a0 nid=0x1ddc runnable >> >> "GC Thread#3" os_prio=2 cpu=187.50ms elapsed=338.82s >> tid=0x000001e349b35700 nid=0x4a48 runnable >> >> "GC Thread#4" os_prio=2 cpu=140.63ms elapsed=338.82s >> tid=0x000001e349b340b0 nid=0x32e8 runnable >> >> "GC Thread#5" os_prio=2 cpu=156.25ms elapsed=338.82s >> tid=0x000001e349b35a30 nid=0x38cc runnable >> >> "GC Thread#6" os_prio=2 cpu=171.88ms elapsed=338.82s >> tid=0x000001e349b35d60 nid=0x3ed0 runnable >> >> "G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=341.80s >> tid=0x000001e31c229930 nid=0x21c runnable >> >> "G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=341.80s tid=0x000001e31c22a5a0 >> nid=0x3920 runnable >> >> "G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=341.80s tid=0x000001e31c253f10 >> nid=0x1f84 runnable >> >> "G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms elapsed=341.80s >> tid=0x000001e31c254b90 nid=0x27ac runnable >> >> "VM Periodic Task Thread" os_prio=2 cpu=15.63ms elapsed=341.76s >> tid=0x000001e349b39710 nid=0x838 waiting on condition >> >> JNI global refs: 33, weak refs: 0 >> >> -- >> Aaron Scott-Boddendijk >> >> On Tue, Jun 16, 2020 at 10:15 AM Robert Field >> wrote: >> >>> Make that jps/jstack >>> >>> -R >>> >>> On 2020-06-15 15:12, Robert Field wrote: >>> > Thanks for the report. >>> > >>> > What, if anything, is the Java stack for this thread (jps)? >>> > >>> > -Robert >>> > >>> > >>> > On 2020-06-15 14:41, Aaron Scott-Boddendijk wrote: >>> >> System: >>> >> * Windows 10 >>> >> * Powershell >>> >> >>> >> When I start JShell, without executing anything, a CPU core is always >>> at >>> >> 100% (a single thread though I haven't identified what it's doing). >>> >> >>> >> The thread stack is as follows (with only the last two items sometimes >>> >> change - but I don't know the internals of the JVM to know if this >>> >> useful >>> >> or significant): >>> >> >>> >> ntoskrnl.exe!KeSynchronizeExecution+0x5b46 >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x1c2d >>> >> ntoskrnl.exe!KeWaitForSingleObject+0xab4 >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x255 >>> >> ntoskrnl.exe!RtlClearBitsEx+0x15a7 >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x3828 >>> >> ntoskrnl.exe!KeSynchronizeExecution+0x3120 >>> >> jvm.dll!c2v_notifyCompilerInliningEvent+0x201797 >>> >> >>> >> The JDK 14 version of JShell does not have this issue but several of >>> the >>> >> recent JDK 15 builds have done this. >>> >> >>> >> -- >>> >> Aaron Scott-Boddendijk >>> >> From sormuras at gmail.com Mon Jul 13 02:52:23 2020 From: sormuras at gmail.com (Christian Stein) Date: Mon, 13 Jul 2020 04:52:23 +0200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> Message-ID: Hi Aaron, I observe the same behaviour of JShell 15 build 30. Here, the 100% CPU workload is split on to 3-4 logical processors. Grabbed an animated GIF of "jshell.exe -- /exit" session at [0]. To me, it looks like a loop is running wild, w/o a Thread.yield()/.sleep() call. Microsoft Windows [Version 10.0.19041.329] openjdk 15-ea 2020-09-15 OpenJDK Runtime Environment (build 15-ea+30-1476) OpenJDK 64-Bit Server VM (build 15-ea+30-1476, mixed mode, sharing) Cheers, Christian [0]: https://drive.google.com/file/d/1KOQO5B9WrM4C43K3AB7H9VVPuh9hdCOe/view?usp=sharing On Mon, Jul 13, 2020 at 4:24 AM Aaron Scott-Boddendijk wrote: > This still exists in JDK 15 build 31. > > Is any other Windows user able to reproduce this? I have two machines, one > laptop and one desktop that show a CPU thread constantly @ 100% just by > starting JShell. For the desktop machine that's not a major issue but for > the laptop this spins up the fans and eats the battery. > > JShell in JDK 14 is fine. > > I've yet to hear of any other user confirming this issue. > > -- > Aaron Scott-Boddendijk > > > On Fri, Jun 26, 2020 at 2:00 PM Aaron Scott-Boddendijk > wrote: > > > Just confirming that: > > > > * This still exists in JDK 15 build 29 > > * Occurs on multiple unrelated Windows 10 machines with differing major > > versions of the OS. > > * Does not occur in JDK 14.01 on these machines (OpenJDK 64-Bit Server VM > > Zulu14.28+21-CA) > > * Does not appear to occur on Linux > > > > -- > > Aaron Scott-Boddendijk > > > > > > On Tue, Jun 16, 2020 at 11:16 AM Aaron Scott-Boddendijk < > talden at gmail.com> > > wrote: > > > >> This is the thread-dump from the JVM that VisualVM sees as using a > core... > >> > >> 2020-06-16 11:07:35 > >> Full thread dump OpenJDK 64-Bit Server VM (15-ea+27-1372 mixed mode, > >> sharing): > >> > >> Threads class SMR info: > >> _java_thread_list=0x000001e34a6040f0, length=23, elements={ > >> 0x000001e31c1a1dc0, 0x000001e349035ee0, 0x000001e349037250, > >> 0x000001e349058ae0, > >> 0x000001e34905c5b0, 0x000001e34905f710, 0x000001e3490603f0, > >> 0x000001e349065140, > >> 0x000001e34906d620, 0x000001e349b36a20, 0x000001e349b8c690, > >> 0x000001e349da3400, > >> 0x000001e349daa7c0, 0x000001e349dbb640, 0x000001e34a141140, > >> 0x000001e349d555c0, > >> 0x000001e34b07f030, 0x000001e34a461c90, 0x000001e34a45fae0, > >> 0x000001e34a45ffb0, > >> 0x000001e34a4617c0, 0x000001e34a462160, 0x000001e34a45f610 > >> } > >> > >> "main" #1 prio=5 os_prio=0 cpu=1078.13ms elapsed=341.81s > >> tid=0x000001e31c1a1dc0 nid=0x16b0 in Object.wait() [0x000000340d9fe000] > >> java.lang.Thread.State: TIMED_WAITING (on object monitor) > >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >> - waiting on > >> at > >> > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 15-ea > >> /NonBlockingInputStreamImpl.java:139) > >> - locked <0x000000060fe87338> (a > >> jdk.internal.jshell.tool.ConsoleIOContext$1) > >> at > >> > jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > >> /NonBlockingInputStream.java:62) > >> at > >> > jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 15-ea > >> /NonBlocking.java:168) > >> at > >> > jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > >> /NonBlockingReader.java:57) > >> at > >> > jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 15-ea > >> /BindingReader.java:160) > >> at > >> > jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > >> /BindingReader.java:110) > >> at > >> > jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > >> /BindingReader.java:61) > >> at > >> > jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 15-ea > >> /LineReaderImpl.java:913) > >> at > >> > jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 15-ea > >> /LineReaderImpl.java:946) > >> at > >> jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 15-ea > >> /ConsoleIOContext.java:154) > >> at > >> > jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > >> /LineReaderImpl.java:637) > >> at > >> > jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > >> /LineReaderImpl.java:454) > >> at > >> jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 15-ea > >> /ConsoleIOContext.java:229) > >> at jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 15-ea > >> /JShellTool.java:1254) > >> at jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 15-ea > >> /JShellTool.java:1190) > >> at jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 15-ea > >> /JShellTool.java:991) > >> at > >> jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 15-ea > >> /JShellToolBuilder.java:254) > >> at > >> jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 15-ea > >> /JShellToolProvider.java:120) > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "Reference Handler" #2 daemon prio=10 os_prio=2 cpu=0.00ms > >> elapsed=341.79s tid=0x000001e349035ee0 nid=0x13fc waiting on condition > >> [0x000000340e0fe000] > >> java.lang.Thread.State: RUNNABLE > >> at > >> java.lang.ref.Reference.waitForReferencePendingList(java.base at 15-ea > /Native > >> Method) > >> at > >> java.lang.ref.Reference.processPendingReferences(java.base at 15-ea > >> /Reference.java:241) > >> at java.lang.ref.Reference$ReferenceHandler.run(java.base at 15-ea > >> /Reference.java:213) > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=341.79s > >> tid=0x000001e349037250 nid=0x2a60 in Object.wait() [0x000000340e1fe000] > >> java.lang.Thread.State: WAITING (on object monitor) > >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >> - waiting on <0x0000000601400bc0> (a > >> java.lang.ref.ReferenceQueue$Lock) > >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >> /ReferenceQueue.java:155) > >> - locked <0x0000000601400bc0> (a > >> java.lang.ref.ReferenceQueue$Lock) > >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >> /ReferenceQueue.java:176) > >> at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 15-ea > >> /Finalizer.java:170) > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms > elapsed=341.78s > >> tid=0x000001e349058ae0 nid=0x35c8 runnable [0x0000000000000000] > >> java.lang.Thread.State: RUNNABLE > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "Attach Listener" #5 daemon prio=5 os_prio=2 cpu=125.00ms > elapsed=341.78s > >> tid=0x000001e34905c5b0 nid=0x3e0c waiting on condition > [0x0000000000000000] > >> java.lang.Thread.State: RUNNABLE > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "Service Thread" #6 daemon prio=9 os_prio=0 cpu=0.00ms elapsed=341.78s > >> tid=0x000001e34905f710 nid=0x398c runnable [0x0000000000000000] > >> java.lang.Thread.State: RUNNABLE > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "C2 CompilerThread0" #7 daemon prio=9 os_prio=2 cpu=1781.25ms > >> elapsed=341.78s tid=0x000001e3490603f0 nid=0xcf0 waiting on condition > >> [0x0000000000000000] > >> java.lang.Thread.State: RUNNABLE > >> No compile task > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "C1 CompilerThread0" #10 daemon prio=9 os_prio=2 cpu=765.63ms > >> elapsed=341.78s tid=0x000001e349065140 nid=0x3e54 waiting on condition > >> [0x0000000000000000] > >> java.lang.Thread.State: RUNNABLE > >> No compile task > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "Sweeper thread" #11 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=341.78s > >> tid=0x000001e34906d620 nid=0x38bc runnable [0x0000000000000000] > >> java.lang.Thread.State: RUNNABLE > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "Notification Thread" #12 daemon prio=9 os_prio=0 cpu=0.00ms > >> elapsed=341.76s tid=0x000001e349b36a20 nid=0x49b8 runnable > >> [0x0000000000000000] > >> java.lang.Thread.State: RUNNABLE > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "Common-Cleaner" #13 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=341.75s > >> tid=0x000001e349b8c690 nid=0x26e4 in Object.wait() [0x000000340eaff000] > >> java.lang.Thread.State: TIMED_WAITING (on object monitor) > >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >> - waiting on > >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >> /ReferenceQueue.java:155) > >> - locked <0x0000000601401a78> (a > >> java.lang.ref.ReferenceQueue$Lock) > >> at jdk.internal.ref.CleanerImpl.run(java.base at 15-ea > >> /CleanerImpl.java:148) > >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >> at jdk.internal.misc.InnocuousThread.run(java.base at 15-ea > >> /InnocuousThread.java:134) > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "JDI Internal Event Handler" #17 daemon prio=5 os_prio=0 cpu=15.63ms > >> elapsed=341.39s tid=0x000001e349da3400 nid=0x68 in Object.wait() > >> [0x000000340effe000] > >> java.lang.Thread.State: WAITING (on object monitor) > >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >> - waiting on > >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >> at > com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > >> /EventQueueImpl.java:190) > >> - locked <0x000000060154b630> (a > com.sun.tools.jdi.EventQueueImpl) > >> at com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 15-ea > >> /EventQueueImpl.java:125) > >> at com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 15-ea > >> /InternalEventHandler.java:61) > >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "JDI Target VM Interface" #16 daemon prio=5 os_prio=0 cpu=46.88ms > >> elapsed=341.39s tid=0x000001e349daa7c0 nid=0x3d04 runnable > >> [0x000000340f0fe000] > >> java.lang.Thread.State: RUNNABLE > >> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native > >> Method) > >> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > >> /SocketDispatcher.java:46) > >> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > >> /NioSocketImpl.java:261) > >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >> /NioSocketImpl.java:312) > >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >> /NioSocketImpl.java:350) > >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >> /NioSocketImpl.java:803) > >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >> /Socket.java:981) > >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >> /Socket.java:976) > >> at com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 15-ea > >> /SocketConnection.java:82) > >> - locked <0x000000060154b998> (a java.lang.Object) > >> at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 15-ea > >> /TargetVM.java:124) > >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >> > >> Locked ownable synchronizers: > >> - <0x0000000601577110> (a > >> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >> > >> "event-handler" #18 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=341.38s > >> tid=0x000001e349dbb640 nid=0x203c in Object.wait() [0x000000340edfe000] > >> java.lang.Thread.State: WAITING (on object monitor) > >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >> - waiting on > >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >> at > com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > >> /EventQueueImpl.java:190) > >> - locked <0x000000060154bc28> (a > com.sun.tools.jdi.EventQueueImpl) > >> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > >> /EventQueueImpl.java:97) > >> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > >> /EventQueueImpl.java:83) > >> at jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 15-ea > >> /JdiEventHandler.java:79) > >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "output reader" #19 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=341.31s > >> tid=0x000001e34a141140 nid=0x49c0 runnable [0x000000340eeff000] > >> java.lang.Thread.State: RUNNABLE > >> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native > >> Method) > >> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > >> /SocketDispatcher.java:46) > >> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > >> /NioSocketImpl.java:261) > >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >> /NioSocketImpl.java:312) > >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >> /NioSocketImpl.java:350) > >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >> /NioSocketImpl.java:803) > >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >> /Socket.java:981) > >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >> /Socket.java:976) > >> at java.io.FilterInputStream.read(java.base at 15-ea > >> /FilterInputStream.java:82) > >> at jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 15-ea > >> /DemultiplexInput.java:58) > >> > >> Locked ownable synchronizers: > >> - <0x0000000601553510> (a > >> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >> > >> "Thread-0" #21 daemon prio=5 os_prio=0 cpu=312.50ms elapsed=341.22s > >> tid=0x000001e349d555c0 nid=0x4d88 waiting on condition > [0x000000340f1fe000] > >> java.lang.Thread.State: WAITING (parking) > >> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native Method) > >> - parking to wait for <0x0000000601550fc0> (a > >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > >> at java.util.concurrent.locks.LockSupport.park(java.base at 15-ea > >> /LockSupport.java:341) > >> at > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 15-ea > >> /AbstractQueuedSynchronizer.java:505) > >> at > java.util.concurrent.ForkJoinPool.managedBlock(java.base at 15-ea > >> /ForkJoinPool.java:3137) > >> at > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > >> /AbstractQueuedSynchronizer.java:1614) > >> at java.util.concurrent.LinkedBlockingQueue.take(java.base at 15-ea > >> /LinkedBlockingQueue.java:435) > >> at > java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > >> /ThreadPoolExecutor.java:1056) > >> at > >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >> /ThreadPoolExecutor.java:1116) > >> at > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >> /ThreadPoolExecutor.java:630) > >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "Thread-2" #23 daemon prio=5 os_prio=0 cpu=338859.38ms elapsed=340.58s > >> tid=0x000001e34b07f030 nid=0xac0 runnable [0x000000340f3fe000] > >> java.lang.Thread.State: RUNNABLE > >> at > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > >> /AbstractQueuedSynchronizer.java:1749) > >> at > >> > jdk.internal.org.jline.utils.NonBlockingPumpReader.read(jdk.internal.le at 15-ea > >> /NonBlockingPumpReader.java:77) > >> at > >> > jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > >> /NonBlockingReader.java:57) > >> at > >> > jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read(jdk.internal.le at 15-ea > >> /NonBlocking.java:104) > >> at > >> > jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > >> /NonBlockingInputStream.java:36) > >> at > >> > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 15-ea > >> /StopDetectingInputStream.java:66) > >> at > >> > jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$410/0x0000000800d2eb28.run(jdk.jshell at 15-ea > /Unknown > >> Source) > >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >> > >> Locked ownable synchronizers: > >> - <0x00000006028b4318> (a > >> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >> > >> "WindowsStreamPump" #25 daemon prio=5 os_prio=0 cpu=0.00ms > >> elapsed=340.53s tid=0x000001e34a461c90 nid=0x3688 runnable > >> [0x000000340f4fe000] > >> java.lang.Thread.State: RUNNABLE > >> at > >> > jdk.internal.org.jline.terminal.impl.jna.win.Kernel32Impl.WaitForSingleObject(jdk.internal.le at 15-ea > /Native > >> Method) > >> at > >> > jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.readConsoleInput(jdk.internal.le at 15-ea > >> /JnaWinSysTerminal.java:185) > >> at > >> > jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.processConsoleInput(jdk.internal.le at 15-ea > >> /JnaWinSysTerminal.java:108) > >> at > >> > jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal.pump(jdk.internal.le at 15-ea > >> /AbstractWindowsTerminal.java:465) > >> at > >> > jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal$$Lambda$417/0x0000000800d310f8.run(jdk.internal.le at 15-ea > /Unknown > >> Source) > >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "null non blocking reader thread" #26 daemon prio=5 os_prio=0 cpu=0.00ms > >> elapsed=340.26s tid=0x000001e34a45fae0 nid=0x488 in Object.wait() > >> [0x000000340f6ff000] > >> java.lang.Thread.State: WAITING (on object monitor) > >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >> - waiting on > >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >> at > >> jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 15-ea > >> /StopDetectingInputStream.java:98) > >> - locked <0x0000000601e2b650> (a > >> jdk.internal.jshell.tool.StopDetectingInputStream) > >> at > >> > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 15-ea > >> /NonBlockingInputStreamImpl.java:216) > >> at > >> > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$584/0x0000000800d4f088.run(jdk.internal.le at 15-ea > /Unknown > >> Source) > >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "RMI TCP Accept-0" #27 daemon prio=5 os_prio=0 cpu=0.00ms > elapsed=180.89s > >> tid=0x000001e34a45ffb0 nid=0x45f0 runnable [0x000000340d8fe000] > >> java.lang.Thread.State: RUNNABLE > >> at sun.nio.ch.Net.accept(java.base at 15-ea/Native Method) > >> at sun.nio.ch.NioSocketImpl.accept(java.base at 15-ea > >> /NioSocketImpl.java:755) > >> at java.net.ServerSocket.implAccept(java.base at 15-ea > >> /ServerSocket.java:684) > >> at java.net.ServerSocket.platformImplAccept(java.base at 15-ea > >> /ServerSocket.java:650) > >> at java.net.ServerSocket.implAccept(java.base at 15-ea > >> /ServerSocket.java:626) > >> at java.net.ServerSocket.implAccept(java.base at 15-ea > >> /ServerSocket.java:583) > >> at java.net.ServerSocket.accept(java.base at 15-ea > >> /ServerSocket.java:540) > >> at > >> > sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(jdk.management.agent at 15-ea > >> /LocalRMIServerSocketFactory.java:52) > >> at > >> > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi at 15-ea > >> /TCPTransport.java:413) > >> at > >> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi at 15-ea > >> /TCPTransport.java:377) > >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >> > >> Locked ownable synchronizers: > >> - <0x0000000602e53118> (a > >> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >> > >> "RMI TCP Connection(1)-10.0.201.131" #28 daemon prio=5 os_prio=0 > >> cpu=437.50ms elapsed=180.87s tid=0x000001e34a4617c0 nid=0x4790 runnable > >> [0x000000340fbfe000] > >> java.lang.Thread.State: RUNNABLE > >> at sun.nio.ch.Net.poll(java.base at 15-ea/Native Method) > >> at sun.nio.ch.NioSocketImpl.park(java.base at 15-ea > >> /NioSocketImpl.java:181) > >> at sun.nio.ch.NioSocketImpl.timedRead(java.base at 15-ea > >> /NioSocketImpl.java:285) > >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >> /NioSocketImpl.java:309) > >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >> /NioSocketImpl.java:350) > >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >> /NioSocketImpl.java:803) > >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >> /Socket.java:981) > >> at java.io.BufferedInputStream.fill(java.base at 15-ea > >> /BufferedInputStream.java:244) > >> at java.io.BufferedInputStream.read(java.base at 15-ea > >> /BufferedInputStream.java:263) > >> - locked <0x0000000602e19470> (a java.io.BufferedInputStream) > >> at java.io.FilterInputStream.read(java.base at 15-ea > >> /FilterInputStream.java:82) > >> at > >> sun.rmi.transport.tcp.TCPTransport.handleMessages(java.rmi at 15-ea > >> /TCPTransport.java:569) > >> at > >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(java.rmi at 15-ea > >> /TCPTransport.java:828) > >> at > >> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(java.rmi at 15-ea > >> /TCPTransport.java:705) > >> at > >> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$686/0x0000000800da3998.run(java.rmi at 15-ea > /Unknown > >> Source) > >> at > >> java.security.AccessController.executePrivileged(java.base at 15-ea > >> /AccessController.java:753) > >> at java.security.AccessController.doPrivileged(java.base at 15-ea > >> /AccessController.java:391) > >> at > >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(java.rmi at 15-ea > >> /TCPTransport.java:704) > >> at > >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >> /ThreadPoolExecutor.java:1130) > >> at > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >> /ThreadPoolExecutor.java:630) > >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >> > >> Locked ownable synchronizers: > >> - <0x0000000602e19708> (a > >> java.util.concurrent.ThreadPoolExecutor$Worker) > >> - <0x0000000602e59038> (a > >> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >> > >> "RMI Scheduler(0)" #29 daemon prio=5 os_prio=0 cpu=0.00ms > elapsed=180.86s > >> tid=0x000001e34a462160 nid=0x1df0 waiting on condition > [0x000000340fcfe000] > >> java.lang.Thread.State: TIMED_WAITING (parking) > >> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native Method) > >> - parking to wait for <0x0000000602e1af00> (a > >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > >> at > >> java.util.concurrent.locks.LockSupport.parkNanos(java.base at 15-ea > >> /LockSupport.java:252) > >> at > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 15-ea > >> /AbstractQueuedSynchronizer.java:1661) > >> at > >> > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > >> /ScheduledThreadPoolExecutor.java:1182) > >> at > >> > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > >> /ScheduledThreadPoolExecutor.java:899) > >> at > java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > >> /ThreadPoolExecutor.java:1056) > >> at > >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >> /ThreadPoolExecutor.java:1116) > >> at > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >> /ThreadPoolExecutor.java:630) > >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "JMX server connection timeout 30" #30 daemon prio=5 os_prio=0 > cpu=0.00ms > >> elapsed=180.86s tid=0x000001e34a45f610 nid=0x2fe8 in Object.wait() > >> [0x000000340fdff000] > >> java.lang.Thread.State: TIMED_WAITING (on object monitor) > >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >> - waiting on > >> at > >> > com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(java.management at 15-ea > >> /ServerCommunicatorAdmin.java:171) > >> - locked <0x0000000602e1ca08> (a [I) > >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >> > >> Locked ownable synchronizers: > >> - None > >> > >> "VM Thread" os_prio=2 cpu=515.63ms elapsed=341.79s > tid=0x000001e349031eb0 > >> nid=0x540 runnable > >> > >> "GC Thread#0" os_prio=2 cpu=328.13ms elapsed=341.80s > >> tid=0x000001e31c218710 nid=0x19e8 runnable > >> > >> "GC Thread#1" os_prio=2 cpu=265.63ms elapsed=341.53s > >> tid=0x000001e349b353d0 nid=0x1cc4 runnable > >> > >> "GC Thread#2" os_prio=2 cpu=218.75ms elapsed=340.37s > >> tid=0x000001e349b350a0 nid=0x1ddc runnable > >> > >> "GC Thread#3" os_prio=2 cpu=187.50ms elapsed=338.82s > >> tid=0x000001e349b35700 nid=0x4a48 runnable > >> > >> "GC Thread#4" os_prio=2 cpu=140.63ms elapsed=338.82s > >> tid=0x000001e349b340b0 nid=0x32e8 runnable > >> > >> "GC Thread#5" os_prio=2 cpu=156.25ms elapsed=338.82s > >> tid=0x000001e349b35a30 nid=0x38cc runnable > >> > >> "GC Thread#6" os_prio=2 cpu=171.88ms elapsed=338.82s > >> tid=0x000001e349b35d60 nid=0x3ed0 runnable > >> > >> "G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=341.80s > >> tid=0x000001e31c229930 nid=0x21c runnable > >> > >> "G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=341.80s tid=0x000001e31c22a5a0 > >> nid=0x3920 runnable > >> > >> "G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=341.80s > tid=0x000001e31c253f10 > >> nid=0x1f84 runnable > >> > >> "G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms elapsed=341.80s > >> tid=0x000001e31c254b90 nid=0x27ac runnable > >> > >> "VM Periodic Task Thread" os_prio=2 cpu=15.63ms elapsed=341.76s > >> tid=0x000001e349b39710 nid=0x838 waiting on condition > >> > >> JNI global refs: 33, weak refs: 0 > >> > >> -- > >> Aaron Scott-Boddendijk > >> > >> On Tue, Jun 16, 2020 at 10:15 AM Robert Field > >> wrote: > >> > >>> Make that jps/jstack > >>> > >>> -R > >>> > >>> On 2020-06-15 15:12, Robert Field wrote: > >>> > Thanks for the report. > >>> > > >>> > What, if anything, is the Java stack for this thread (jps)? > >>> > > >>> > -Robert > >>> > > >>> > > >>> > On 2020-06-15 14:41, Aaron Scott-Boddendijk wrote: > >>> >> System: > >>> >> * Windows 10 > >>> >> * Powershell > >>> >> > >>> >> When I start JShell, without executing anything, a CPU core is > always > >>> at > >>> >> 100% (a single thread though I haven't identified what it's doing). > >>> >> > >>> >> The thread stack is as follows (with only the last two items > sometimes > >>> >> change - but I don't know the internals of the JVM to know if this > >>> >> useful > >>> >> or significant): > >>> >> > >>> >> ntoskrnl.exe!KeSynchronizeExecution+0x5b46 > >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x1c2d > >>> >> ntoskrnl.exe!KeWaitForSingleObject+0xab4 > >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x255 > >>> >> ntoskrnl.exe!RtlClearBitsEx+0x15a7 > >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x3828 > >>> >> ntoskrnl.exe!KeSynchronizeExecution+0x3120 > >>> >> jvm.dll!c2v_notifyCompilerInliningEvent+0x201797 > >>> >> > >>> >> The JDK 14 version of JShell does not have this issue but several of > >>> the > >>> >> recent JDK 15 builds have done this. > >>> >> > >>> >> -- > >>> >> Aaron Scott-Boddendijk > >>> > >> > From sormuras at gmail.com Mon Jul 13 03:05:01 2020 From: sormuras at gmail.com (Christian Stein) Date: Mon, 13 Jul 2020 05:05:01 +0200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> Message-ID: Seems like "read line" from "jline" is underlying reason: Thread-2 [31] (RUNNABLE) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await line: 1749 jdk.internal.org.jline.utils.NonBlockingPumpReader.read line: 77 jdk.internal.org.jline.utils.NonBlockingReader.read line: 57 jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read line: 104 jdk.internal.org.jline.utils.NonBlockingInputStream.read line: 36 jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 line: 66 jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$347/0x0000000800cff330.run line: not available java.lang.Thread.run line: 832 It produces a constant high CPU usage and allocates a lot of RAM per second. Thread Name Thread State Blocked Count Total CPU Usage Deadlocked Allocated Memory Thread-2 RUNNABLE 1 0.06252084028009336 Not Enabled 196198305136 B On Mon, Jul 13, 2020 at 4:52 AM Christian Stein wrote: > Hi Aaron, > > I observe the same behaviour of JShell 15 build 30. > > Here, the 100% CPU workload is split on to 3-4 logical processors. > Grabbed an animated GIF of "jshell.exe -- /exit" session at [0]. > To me, it looks like a loop is running wild, w/o a Thread.yield()/.sleep() > call. > > Microsoft Windows [Version 10.0.19041.329] > > openjdk 15-ea 2020-09-15 > OpenJDK Runtime Environment (build 15-ea+30-1476) > OpenJDK 64-Bit Server VM (build 15-ea+30-1476, mixed mode, sharing) > > Cheers, > Christian > > [0]: > https://drive.google.com/file/d/1KOQO5B9WrM4C43K3AB7H9VVPuh9hdCOe/view?usp=sharing > > > On Mon, Jul 13, 2020 at 4:24 AM Aaron Scott-Boddendijk > wrote: > >> This still exists in JDK 15 build 31. >> >> Is any other Windows user able to reproduce this? I have two machines, one >> laptop and one desktop that show a CPU thread constantly @ 100% just by >> starting JShell. For the desktop machine that's not a major issue but for >> the laptop this spins up the fans and eats the battery. >> >> JShell in JDK 14 is fine. >> >> I've yet to hear of any other user confirming this issue. >> >> -- >> Aaron Scott-Boddendijk >> >> >> On Fri, Jun 26, 2020 at 2:00 PM Aaron Scott-Boddendijk >> wrote: >> >> > Just confirming that: >> > >> > * This still exists in JDK 15 build 29 >> > * Occurs on multiple unrelated Windows 10 machines with differing major >> > versions of the OS. >> > * Does not occur in JDK 14.01 on these machines (OpenJDK 64-Bit Server >> VM >> > Zulu14.28+21-CA) >> > * Does not appear to occur on Linux >> > >> > -- >> > Aaron Scott-Boddendijk >> > >> > >> > On Tue, Jun 16, 2020 at 11:16 AM Aaron Scott-Boddendijk < >> talden at gmail.com> >> > wrote: >> > >> >> This is the thread-dump from the JVM that VisualVM sees as using a >> core... >> >> >> >> 2020-06-16 11:07:35 >> >> Full thread dump OpenJDK 64-Bit Server VM (15-ea+27-1372 mixed mode, >> >> sharing): >> >> >> >> Threads class SMR info: >> >> _java_thread_list=0x000001e34a6040f0, length=23, elements={ >> >> 0x000001e31c1a1dc0, 0x000001e349035ee0, 0x000001e349037250, >> >> 0x000001e349058ae0, >> >> 0x000001e34905c5b0, 0x000001e34905f710, 0x000001e3490603f0, >> >> 0x000001e349065140, >> >> 0x000001e34906d620, 0x000001e349b36a20, 0x000001e349b8c690, >> >> 0x000001e349da3400, >> >> 0x000001e349daa7c0, 0x000001e349dbb640, 0x000001e34a141140, >> >> 0x000001e349d555c0, >> >> 0x000001e34b07f030, 0x000001e34a461c90, 0x000001e34a45fae0, >> >> 0x000001e34a45ffb0, >> >> 0x000001e34a4617c0, 0x000001e34a462160, 0x000001e34a45f610 >> >> } >> >> >> >> "main" #1 prio=5 os_prio=0 cpu=1078.13ms elapsed=341.81s >> >> tid=0x000001e31c1a1dc0 nid=0x16b0 in Object.wait() >> [0x000000340d9fe000] >> >> java.lang.Thread.State: TIMED_WAITING (on object monitor) >> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> >> - waiting on >> >> at >> >> >> jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 15-ea >> >> /NonBlockingInputStreamImpl.java:139) >> >> - locked <0x000000060fe87338> (a >> >> jdk.internal.jshell.tool.ConsoleIOContext$1) >> >> at >> >> >> jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea >> >> /NonBlockingInputStream.java:62) >> >> at >> >> >> jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 15-ea >> >> /NonBlocking.java:168) >> >> at >> >> >> jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea >> >> /NonBlockingReader.java:57) >> >> at >> >> >> jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 15-ea >> >> /BindingReader.java:160) >> >> at >> >> >> jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea >> >> /BindingReader.java:110) >> >> at >> >> >> jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea >> >> /BindingReader.java:61) >> >> at >> >> >> jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 15-ea >> >> /LineReaderImpl.java:913) >> >> at >> >> >> jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 15-ea >> >> /LineReaderImpl.java:946) >> >> at >> >> >> jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 15-ea >> >> /ConsoleIOContext.java:154) >> >> at >> >> >> jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea >> >> /LineReaderImpl.java:637) >> >> at >> >> >> jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea >> >> /LineReaderImpl.java:454) >> >> at >> >> jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 15-ea >> >> /ConsoleIOContext.java:229) >> >> at >> jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 15-ea >> >> /JShellTool.java:1254) >> >> at jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 15-ea >> >> /JShellTool.java:1190) >> >> at jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 15-ea >> >> /JShellTool.java:991) >> >> at >> >> jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 15-ea >> >> /JShellToolBuilder.java:254) >> >> at >> >> jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 15-ea >> >> /JShellToolProvider.java:120) >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "Reference Handler" #2 daemon prio=10 os_prio=2 cpu=0.00ms >> >> elapsed=341.79s tid=0x000001e349035ee0 nid=0x13fc waiting on condition >> >> [0x000000340e0fe000] >> >> java.lang.Thread.State: RUNNABLE >> >> at >> >> java.lang.ref.Reference.waitForReferencePendingList(java.base at 15-ea >> /Native >> >> Method) >> >> at >> >> java.lang.ref.Reference.processPendingReferences(java.base at 15-ea >> >> /Reference.java:241) >> >> at java.lang.ref.Reference$ReferenceHandler.run(java.base at 15-ea >> >> /Reference.java:213) >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=341.79s >> >> tid=0x000001e349037250 nid=0x2a60 in Object.wait() >> [0x000000340e1fe000] >> >> java.lang.Thread.State: WAITING (on object monitor) >> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> >> - waiting on <0x0000000601400bc0> (a >> >> java.lang.ref.ReferenceQueue$Lock) >> >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea >> >> /ReferenceQueue.java:155) >> >> - locked <0x0000000601400bc0> (a >> >> java.lang.ref.ReferenceQueue$Lock) >> >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea >> >> /ReferenceQueue.java:176) >> >> at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 15-ea >> >> /Finalizer.java:170) >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms >> elapsed=341.78s >> >> tid=0x000001e349058ae0 nid=0x35c8 runnable [0x0000000000000000] >> >> java.lang.Thread.State: RUNNABLE >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "Attach Listener" #5 daemon prio=5 os_prio=2 cpu=125.00ms >> elapsed=341.78s >> >> tid=0x000001e34905c5b0 nid=0x3e0c waiting on condition >> [0x0000000000000000] >> >> java.lang.Thread.State: RUNNABLE >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "Service Thread" #6 daemon prio=9 os_prio=0 cpu=0.00ms elapsed=341.78s >> >> tid=0x000001e34905f710 nid=0x398c runnable [0x0000000000000000] >> >> java.lang.Thread.State: RUNNABLE >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "C2 CompilerThread0" #7 daemon prio=9 os_prio=2 cpu=1781.25ms >> >> elapsed=341.78s tid=0x000001e3490603f0 nid=0xcf0 waiting on condition >> >> [0x0000000000000000] >> >> java.lang.Thread.State: RUNNABLE >> >> No compile task >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "C1 CompilerThread0" #10 daemon prio=9 os_prio=2 cpu=765.63ms >> >> elapsed=341.78s tid=0x000001e349065140 nid=0x3e54 waiting on condition >> >> [0x0000000000000000] >> >> java.lang.Thread.State: RUNNABLE >> >> No compile task >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "Sweeper thread" #11 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=341.78s >> >> tid=0x000001e34906d620 nid=0x38bc runnable [0x0000000000000000] >> >> java.lang.Thread.State: RUNNABLE >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "Notification Thread" #12 daemon prio=9 os_prio=0 cpu=0.00ms >> >> elapsed=341.76s tid=0x000001e349b36a20 nid=0x49b8 runnable >> >> [0x0000000000000000] >> >> java.lang.Thread.State: RUNNABLE >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "Common-Cleaner" #13 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=341.75s >> >> tid=0x000001e349b8c690 nid=0x26e4 in Object.wait() >> [0x000000340eaff000] >> >> java.lang.Thread.State: TIMED_WAITING (on object monitor) >> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> >> - waiting on >> >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea >> >> /ReferenceQueue.java:155) >> >> - locked <0x0000000601401a78> (a >> >> java.lang.ref.ReferenceQueue$Lock) >> >> at jdk.internal.ref.CleanerImpl.run(java.base at 15-ea >> >> /CleanerImpl.java:148) >> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> at jdk.internal.misc.InnocuousThread.run(java.base at 15-ea >> >> /InnocuousThread.java:134) >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "JDI Internal Event Handler" #17 daemon prio=5 os_prio=0 cpu=15.63ms >> >> elapsed=341.39s tid=0x000001e349da3400 nid=0x68 in Object.wait() >> >> [0x000000340effe000] >> >> java.lang.Thread.State: WAITING (on object monitor) >> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> >> - waiting on >> >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) >> >> at >> com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea >> >> /EventQueueImpl.java:190) >> >> - locked <0x000000060154b630> (a >> com.sun.tools.jdi.EventQueueImpl) >> >> at >> com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 15-ea >> >> /EventQueueImpl.java:125) >> >> at com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 15-ea >> >> /InternalEventHandler.java:61) >> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "JDI Target VM Interface" #16 daemon prio=5 os_prio=0 cpu=46.88ms >> >> elapsed=341.39s tid=0x000001e349daa7c0 nid=0x3d04 runnable >> >> [0x000000340f0fe000] >> >> java.lang.Thread.State: RUNNABLE >> >> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native >> >> Method) >> >> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea >> >> /SocketDispatcher.java:46) >> >> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea >> >> /NioSocketImpl.java:261) >> >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea >> >> /NioSocketImpl.java:312) >> >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea >> >> /NioSocketImpl.java:350) >> >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea >> >> /NioSocketImpl.java:803) >> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >> >> /Socket.java:981) >> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >> >> /Socket.java:976) >> >> at com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 15-ea >> >> /SocketConnection.java:82) >> >> - locked <0x000000060154b998> (a java.lang.Object) >> >> at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 15-ea >> >> /TargetVM.java:124) >> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> >> >> Locked ownable synchronizers: >> >> - <0x0000000601577110> (a >> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> >> >> >> "event-handler" #18 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=341.38s >> >> tid=0x000001e349dbb640 nid=0x203c in Object.wait() >> [0x000000340edfe000] >> >> java.lang.Thread.State: WAITING (on object monitor) >> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> >> - waiting on >> >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) >> >> at >> com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea >> >> /EventQueueImpl.java:190) >> >> - locked <0x000000060154bc28> (a >> com.sun.tools.jdi.EventQueueImpl) >> >> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea >> >> /EventQueueImpl.java:97) >> >> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea >> >> /EventQueueImpl.java:83) >> >> at jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 15-ea >> >> /JdiEventHandler.java:79) >> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "output reader" #19 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=341.31s >> >> tid=0x000001e34a141140 nid=0x49c0 runnable [0x000000340eeff000] >> >> java.lang.Thread.State: RUNNABLE >> >> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native >> >> Method) >> >> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea >> >> /SocketDispatcher.java:46) >> >> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea >> >> /NioSocketImpl.java:261) >> >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea >> >> /NioSocketImpl.java:312) >> >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea >> >> /NioSocketImpl.java:350) >> >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea >> >> /NioSocketImpl.java:803) >> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >> >> /Socket.java:981) >> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >> >> /Socket.java:976) >> >> at java.io.FilterInputStream.read(java.base at 15-ea >> >> /FilterInputStream.java:82) >> >> at jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 15-ea >> >> /DemultiplexInput.java:58) >> >> >> >> Locked ownable synchronizers: >> >> - <0x0000000601553510> (a >> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> >> >> >> "Thread-0" #21 daemon prio=5 os_prio=0 cpu=312.50ms elapsed=341.22s >> >> tid=0x000001e349d555c0 nid=0x4d88 waiting on condition >> [0x000000340f1fe000] >> >> java.lang.Thread.State: WAITING (parking) >> >> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native >> Method) >> >> - parking to wait for <0x0000000601550fc0> (a >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >> >> at java.util.concurrent.locks.LockSupport.park(java.base at 15-ea >> >> /LockSupport.java:341) >> >> at >> >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 15-ea >> >> /AbstractQueuedSynchronizer.java:505) >> >> at >> java.util.concurrent.ForkJoinPool.managedBlock(java.base at 15-ea >> >> /ForkJoinPool.java:3137) >> >> at >> >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea >> >> /AbstractQueuedSynchronizer.java:1614) >> >> at >> java.util.concurrent.LinkedBlockingQueue.take(java.base at 15-ea >> >> /LinkedBlockingQueue.java:435) >> >> at >> java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea >> >> /ThreadPoolExecutor.java:1056) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea >> >> /ThreadPoolExecutor.java:1116) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea >> >> /ThreadPoolExecutor.java:630) >> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "Thread-2" #23 daemon prio=5 os_prio=0 cpu=338859.38ms elapsed=340.58s >> >> tid=0x000001e34b07f030 nid=0xac0 runnable [0x000000340f3fe000] >> >> java.lang.Thread.State: RUNNABLE >> >> at >> >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea >> >> /AbstractQueuedSynchronizer.java:1749) >> >> at >> >> >> jdk.internal.org.jline.utils.NonBlockingPumpReader.read(jdk.internal.le at 15-ea >> >> /NonBlockingPumpReader.java:77) >> >> at >> >> >> jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea >> >> /NonBlockingReader.java:57) >> >> at >> >> >> jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read(jdk.internal.le at 15-ea >> >> /NonBlocking.java:104) >> >> at >> >> >> jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea >> >> /NonBlockingInputStream.java:36) >> >> at >> >> >> jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 15-ea >> >> /StopDetectingInputStream.java:66) >> >> at >> >> >> jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$410/0x0000000800d2eb28.run(jdk.jshell at 15-ea >> /Unknown >> >> Source) >> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> >> >> Locked ownable synchronizers: >> >> - <0x00000006028b4318> (a >> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> >> >> >> "WindowsStreamPump" #25 daemon prio=5 os_prio=0 cpu=0.00ms >> >> elapsed=340.53s tid=0x000001e34a461c90 nid=0x3688 runnable >> >> [0x000000340f4fe000] >> >> java.lang.Thread.State: RUNNABLE >> >> at >> >> >> jdk.internal.org.jline.terminal.impl.jna.win.Kernel32Impl.WaitForSingleObject(jdk.internal.le at 15-ea >> /Native >> >> Method) >> >> at >> >> >> jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.readConsoleInput(jdk.internal.le at 15-ea >> >> /JnaWinSysTerminal.java:185) >> >> at >> >> >> jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.processConsoleInput(jdk.internal.le at 15-ea >> >> /JnaWinSysTerminal.java:108) >> >> at >> >> >> jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal.pump(jdk.internal.le at 15-ea >> >> /AbstractWindowsTerminal.java:465) >> >> at >> >> >> jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal$$Lambda$417/0x0000000800d310f8.run(jdk.internal.le at 15-ea >> /Unknown >> >> Source) >> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "null non blocking reader thread" #26 daemon prio=5 os_prio=0 >> cpu=0.00ms >> >> elapsed=340.26s tid=0x000001e34a45fae0 nid=0x488 in Object.wait() >> >> [0x000000340f6ff000] >> >> java.lang.Thread.State: WAITING (on object monitor) >> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> >> - waiting on >> >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) >> >> at >> >> jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 15-ea >> >> /StopDetectingInputStream.java:98) >> >> - locked <0x0000000601e2b650> (a >> >> jdk.internal.jshell.tool.StopDetectingInputStream) >> >> at >> >> >> jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 15-ea >> >> /NonBlockingInputStreamImpl.java:216) >> >> at >> >> >> jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$584/0x0000000800d4f088.run(jdk.internal.le at 15-ea >> /Unknown >> >> Source) >> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "RMI TCP Accept-0" #27 daemon prio=5 os_prio=0 cpu=0.00ms >> elapsed=180.89s >> >> tid=0x000001e34a45ffb0 nid=0x45f0 runnable [0x000000340d8fe000] >> >> java.lang.Thread.State: RUNNABLE >> >> at sun.nio.ch.Net.accept(java.base at 15-ea/Native Method) >> >> at sun.nio.ch.NioSocketImpl.accept(java.base at 15-ea >> >> /NioSocketImpl.java:755) >> >> at java.net.ServerSocket.implAccept(java.base at 15-ea >> >> /ServerSocket.java:684) >> >> at java.net.ServerSocket.platformImplAccept(java.base at 15-ea >> >> /ServerSocket.java:650) >> >> at java.net.ServerSocket.implAccept(java.base at 15-ea >> >> /ServerSocket.java:626) >> >> at java.net.ServerSocket.implAccept(java.base at 15-ea >> >> /ServerSocket.java:583) >> >> at java.net.ServerSocket.accept(java.base at 15-ea >> >> /ServerSocket.java:540) >> >> at >> >> >> sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(jdk.management.agent at 15-ea >> >> /LocalRMIServerSocketFactory.java:52) >> >> at >> >> >> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi at 15-ea >> >> /TCPTransport.java:413) >> >> at >> >> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi at 15-ea >> >> /TCPTransport.java:377) >> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> >> >> Locked ownable synchronizers: >> >> - <0x0000000602e53118> (a >> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> >> >> >> "RMI TCP Connection(1)-10.0.201.131" #28 daemon prio=5 os_prio=0 >> >> cpu=437.50ms elapsed=180.87s tid=0x000001e34a4617c0 nid=0x4790 runnable >> >> [0x000000340fbfe000] >> >> java.lang.Thread.State: RUNNABLE >> >> at sun.nio.ch.Net.poll(java.base at 15-ea/Native Method) >> >> at sun.nio.ch.NioSocketImpl.park(java.base at 15-ea >> >> /NioSocketImpl.java:181) >> >> at sun.nio.ch.NioSocketImpl.timedRead(java.base at 15-ea >> >> /NioSocketImpl.java:285) >> >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea >> >> /NioSocketImpl.java:309) >> >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea >> >> /NioSocketImpl.java:350) >> >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea >> >> /NioSocketImpl.java:803) >> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >> >> /Socket.java:981) >> >> at java.io.BufferedInputStream.fill(java.base at 15-ea >> >> /BufferedInputStream.java:244) >> >> at java.io.BufferedInputStream.read(java.base at 15-ea >> >> /BufferedInputStream.java:263) >> >> - locked <0x0000000602e19470> (a java.io.BufferedInputStream) >> >> at java.io.FilterInputStream.read(java.base at 15-ea >> >> /FilterInputStream.java:82) >> >> at >> >> sun.rmi.transport.tcp.TCPTransport.handleMessages(java.rmi at 15-ea >> >> /TCPTransport.java:569) >> >> at >> >> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(java.rmi at 15-ea >> >> /TCPTransport.java:828) >> >> at >> >> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(java.rmi at 15-ea >> >> /TCPTransport.java:705) >> >> at >> >> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$686/0x0000000800da3998.run(java.rmi at 15-ea >> /Unknown >> >> Source) >> >> at >> >> java.security.AccessController.executePrivileged(java.base at 15-ea >> >> /AccessController.java:753) >> >> at java.security.AccessController.doPrivileged(java.base at 15-ea >> >> /AccessController.java:391) >> >> at >> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(java.rmi at 15-ea >> >> /TCPTransport.java:704) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea >> >> /ThreadPoolExecutor.java:1130) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea >> >> /ThreadPoolExecutor.java:630) >> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> >> >> Locked ownable synchronizers: >> >> - <0x0000000602e19708> (a >> >> java.util.concurrent.ThreadPoolExecutor$Worker) >> >> - <0x0000000602e59038> (a >> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >> >> >> >> "RMI Scheduler(0)" #29 daemon prio=5 os_prio=0 cpu=0.00ms >> elapsed=180.86s >> >> tid=0x000001e34a462160 nid=0x1df0 waiting on condition >> [0x000000340fcfe000] >> >> java.lang.Thread.State: TIMED_WAITING (parking) >> >> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native >> Method) >> >> - parking to wait for <0x0000000602e1af00> (a >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >> >> at >> >> java.util.concurrent.locks.LockSupport.parkNanos(java.base at 15-ea >> >> /LockSupport.java:252) >> >> at >> >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 15-ea >> >> /AbstractQueuedSynchronizer.java:1661) >> >> at >> >> >> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea >> >> /ScheduledThreadPoolExecutor.java:1182) >> >> at >> >> >> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea >> >> /ScheduledThreadPoolExecutor.java:899) >> >> at >> java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea >> >> /ThreadPoolExecutor.java:1056) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea >> >> /ThreadPoolExecutor.java:1116) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea >> >> /ThreadPoolExecutor.java:630) >> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "JMX server connection timeout 30" #30 daemon prio=5 os_prio=0 >> cpu=0.00ms >> >> elapsed=180.86s tid=0x000001e34a45f610 nid=0x2fe8 in Object.wait() >> >> [0x000000340fdff000] >> >> java.lang.Thread.State: TIMED_WAITING (on object monitor) >> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >> >> - waiting on >> >> at >> >> >> com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(java.management at 15-ea >> >> /ServerCommunicatorAdmin.java:171) >> >> - locked <0x0000000602e1ca08> (a [I) >> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >> >> >> >> Locked ownable synchronizers: >> >> - None >> >> >> >> "VM Thread" os_prio=2 cpu=515.63ms elapsed=341.79s >> tid=0x000001e349031eb0 >> >> nid=0x540 runnable >> >> >> >> "GC Thread#0" os_prio=2 cpu=328.13ms elapsed=341.80s >> >> tid=0x000001e31c218710 nid=0x19e8 runnable >> >> >> >> "GC Thread#1" os_prio=2 cpu=265.63ms elapsed=341.53s >> >> tid=0x000001e349b353d0 nid=0x1cc4 runnable >> >> >> >> "GC Thread#2" os_prio=2 cpu=218.75ms elapsed=340.37s >> >> tid=0x000001e349b350a0 nid=0x1ddc runnable >> >> >> >> "GC Thread#3" os_prio=2 cpu=187.50ms elapsed=338.82s >> >> tid=0x000001e349b35700 nid=0x4a48 runnable >> >> >> >> "GC Thread#4" os_prio=2 cpu=140.63ms elapsed=338.82s >> >> tid=0x000001e349b340b0 nid=0x32e8 runnable >> >> >> >> "GC Thread#5" os_prio=2 cpu=156.25ms elapsed=338.82s >> >> tid=0x000001e349b35a30 nid=0x38cc runnable >> >> >> >> "GC Thread#6" os_prio=2 cpu=171.88ms elapsed=338.82s >> >> tid=0x000001e349b35d60 nid=0x3ed0 runnable >> >> >> >> "G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=341.80s >> >> tid=0x000001e31c229930 nid=0x21c runnable >> >> >> >> "G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=341.80s tid=0x000001e31c22a5a0 >> >> nid=0x3920 runnable >> >> >> >> "G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=341.80s >> tid=0x000001e31c253f10 >> >> nid=0x1f84 runnable >> >> >> >> "G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms elapsed=341.80s >> >> tid=0x000001e31c254b90 nid=0x27ac runnable >> >> >> >> "VM Periodic Task Thread" os_prio=2 cpu=15.63ms elapsed=341.76s >> >> tid=0x000001e349b39710 nid=0x838 waiting on condition >> >> >> >> JNI global refs: 33, weak refs: 0 >> >> >> >> -- >> >> Aaron Scott-Boddendijk >> >> >> >> On Tue, Jun 16, 2020 at 10:15 AM Robert Field > > >> >> wrote: >> >> >> >>> Make that jps/jstack >> >>> >> >>> -R >> >>> >> >>> On 2020-06-15 15:12, Robert Field wrote: >> >>> > Thanks for the report. >> >>> > >> >>> > What, if anything, is the Java stack for this thread (jps)? >> >>> > >> >>> > -Robert >> >>> > >> >>> > >> >>> > On 2020-06-15 14:41, Aaron Scott-Boddendijk wrote: >> >>> >> System: >> >>> >> * Windows 10 >> >>> >> * Powershell >> >>> >> >> >>> >> When I start JShell, without executing anything, a CPU core is >> always >> >>> at >> >>> >> 100% (a single thread though I haven't identified what it's doing). >> >>> >> >> >>> >> The thread stack is as follows (with only the last two items >> sometimes >> >>> >> change - but I don't know the internals of the JVM to know if this >> >>> >> useful >> >>> >> or significant): >> >>> >> >> >>> >> ntoskrnl.exe!KeSynchronizeExecution+0x5b46 >> >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x1c2d >> >>> >> ntoskrnl.exe!KeWaitForSingleObject+0xab4 >> >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x255 >> >>> >> ntoskrnl.exe!RtlClearBitsEx+0x15a7 >> >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x3828 >> >>> >> ntoskrnl.exe!KeSynchronizeExecution+0x3120 >> >>> >> jvm.dll!c2v_notifyCompilerInliningEvent+0x201797 >> >>> >> >> >>> >> The JDK 14 version of JShell does not have this issue but several >> of >> >>> the >> >>> >> recent JDK 15 builds have done this. >> >>> >> >> >>> >> -- >> >>> >> Aaron Scott-Boddendijk >> >>> >> >> >> > From sormuras at gmail.com Mon Jul 13 03:25:26 2020 From: sormuras at gmail.com (Christian Stein) Date: Mon, 13 Jul 2020 05:25:26 +0200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> Message-ID: It's coming from the "while(true)"-loop in StopDetectingInputStream.java [0]. Aaron, try to open an external editor within the JShell session via /edit The CPU usage should drop immediately to normal levels. As soon as you close the editor (it's the internal JShell Edit Pad for me) the thread is again eating CPU cycles. Can you confirm this? While the editor is opened, the thread waits via jdk.internal.jshell.tool.StopDetectingInputStream.waitInputNeeded line: 164 If no editor is open, the "input.read()" method does never wait: jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 line: 66 Cheers, Christian [0]: https://github.com/openjdk/jdk/blob/faf4d7ccb792b16092c791c0ac77acdd440dbca1/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java#L57-L74 On Mon, Jul 13, 2020 at 5:05 AM Christian Stein wrote: > Seems like "read line" from "jline" is underlying reason: > > Thread-2 [31] (RUNNABLE) > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await > line: 1749 > jdk.internal.org.jline.utils.NonBlockingPumpReader.read line: 77 > jdk.internal.org.jline.utils.NonBlockingReader.read line: 57 > > jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read > line: 104 > jdk.internal.org.jline.utils.NonBlockingInputStream.read line: 36 > > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > line: 66 > > jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$347/0x0000000800cff330.run > line: not available > java.lang.Thread.run line: 832 > > It produces a constant high CPU usage and allocates a lot of RAM per > second. > > Thread Name Thread State Blocked Count Total CPU Usage Deadlocked > Allocated Memory > Thread-2 RUNNABLE 1 0.06252084028009336 Not Enabled 196198305136 B > > > > > > On Mon, Jul 13, 2020 at 4:52 AM Christian Stein > wrote: > >> Hi Aaron, >> >> I observe the same behaviour of JShell 15 build 30. >> >> Here, the 100% CPU workload is split on to 3-4 logical processors. >> Grabbed an animated GIF of "jshell.exe -- /exit" session at [0]. >> To me, it looks like a loop is running wild, w/o a >> Thread.yield()/.sleep() call. >> >> Microsoft Windows [Version 10.0.19041.329] >> >> openjdk 15-ea 2020-09-15 >> OpenJDK Runtime Environment (build 15-ea+30-1476) >> OpenJDK 64-Bit Server VM (build 15-ea+30-1476, mixed mode, sharing) >> >> Cheers, >> Christian >> >> [0]: >> https://drive.google.com/file/d/1KOQO5B9WrM4C43K3AB7H9VVPuh9hdCOe/view?usp=sharing >> >> >> On Mon, Jul 13, 2020 at 4:24 AM Aaron Scott-Boddendijk >> wrote: >> >>> This still exists in JDK 15 build 31. >>> >>> Is any other Windows user able to reproduce this? I have two machines, >>> one >>> laptop and one desktop that show a CPU thread constantly @ 100% just by >>> starting JShell. For the desktop machine that's not a major issue but for >>> the laptop this spins up the fans and eats the battery. >>> >>> JShell in JDK 14 is fine. >>> >>> I've yet to hear of any other user confirming this issue. >>> >>> -- >>> Aaron Scott-Boddendijk >>> >>> >>> On Fri, Jun 26, 2020 at 2:00 PM Aaron Scott-Boddendijk >> > >>> wrote: >>> >>> > Just confirming that: >>> > >>> > * This still exists in JDK 15 build 29 >>> > * Occurs on multiple unrelated Windows 10 machines with differing major >>> > versions of the OS. >>> > * Does not occur in JDK 14.01 on these machines (OpenJDK 64-Bit Server >>> VM >>> > Zulu14.28+21-CA) >>> > * Does not appear to occur on Linux >>> > >>> > -- >>> > Aaron Scott-Boddendijk >>> > >>> > >>> > On Tue, Jun 16, 2020 at 11:16 AM Aaron Scott-Boddendijk < >>> talden at gmail.com> >>> > wrote: >>> > >>> >> This is the thread-dump from the JVM that VisualVM sees as using a >>> core... >>> >> >>> >> 2020-06-16 11:07:35 >>> >> Full thread dump OpenJDK 64-Bit Server VM (15-ea+27-1372 mixed mode, >>> >> sharing): >>> >> >>> >> Threads class SMR info: >>> >> _java_thread_list=0x000001e34a6040f0, length=23, elements={ >>> >> 0x000001e31c1a1dc0, 0x000001e349035ee0, 0x000001e349037250, >>> >> 0x000001e349058ae0, >>> >> 0x000001e34905c5b0, 0x000001e34905f710, 0x000001e3490603f0, >>> >> 0x000001e349065140, >>> >> 0x000001e34906d620, 0x000001e349b36a20, 0x000001e349b8c690, >>> >> 0x000001e349da3400, >>> >> 0x000001e349daa7c0, 0x000001e349dbb640, 0x000001e34a141140, >>> >> 0x000001e349d555c0, >>> >> 0x000001e34b07f030, 0x000001e34a461c90, 0x000001e34a45fae0, >>> >> 0x000001e34a45ffb0, >>> >> 0x000001e34a4617c0, 0x000001e34a462160, 0x000001e34a45f610 >>> >> } >>> >> >>> >> "main" #1 prio=5 os_prio=0 cpu=1078.13ms elapsed=341.81s >>> >> tid=0x000001e31c1a1dc0 nid=0x16b0 in Object.wait() >>> [0x000000340d9fe000] >>> >> java.lang.Thread.State: TIMED_WAITING (on object monitor) >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>> >> - waiting on >>> >> at >>> >> >>> jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 15-ea >>> >> /NonBlockingInputStreamImpl.java:139) >>> >> - locked <0x000000060fe87338> (a >>> >> jdk.internal.jshell.tool.ConsoleIOContext$1) >>> >> at >>> >> >>> jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea >>> >> /NonBlockingInputStream.java:62) >>> >> at >>> >> >>> jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 15-ea >>> >> /NonBlocking.java:168) >>> >> at >>> >> >>> jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea >>> >> /NonBlockingReader.java:57) >>> >> at >>> >> >>> jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 15-ea >>> >> /BindingReader.java:160) >>> >> at >>> >> >>> jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea >>> >> /BindingReader.java:110) >>> >> at >>> >> >>> jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea >>> >> /BindingReader.java:61) >>> >> at >>> >> >>> jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 15-ea >>> >> /LineReaderImpl.java:913) >>> >> at >>> >> >>> jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 15-ea >>> >> /LineReaderImpl.java:946) >>> >> at >>> >> >>> jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 15-ea >>> >> /ConsoleIOContext.java:154) >>> >> at >>> >> >>> jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea >>> >> /LineReaderImpl.java:637) >>> >> at >>> >> >>> jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea >>> >> /LineReaderImpl.java:454) >>> >> at >>> >> jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 15-ea >>> >> /ConsoleIOContext.java:229) >>> >> at >>> jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 15-ea >>> >> /JShellTool.java:1254) >>> >> at jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 15-ea >>> >> /JShellTool.java:1190) >>> >> at jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 15-ea >>> >> /JShellTool.java:991) >>> >> at >>> >> jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 15-ea >>> >> /JShellToolBuilder.java:254) >>> >> at >>> >> jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 15-ea >>> >> /JShellToolProvider.java:120) >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "Reference Handler" #2 daemon prio=10 os_prio=2 cpu=0.00ms >>> >> elapsed=341.79s tid=0x000001e349035ee0 nid=0x13fc waiting on condition >>> >> [0x000000340e0fe000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> at >>> >> java.lang.ref.Reference.waitForReferencePendingList(java.base at 15-ea >>> /Native >>> >> Method) >>> >> at >>> >> java.lang.ref.Reference.processPendingReferences(java.base at 15-ea >>> >> /Reference.java:241) >>> >> at >>> java.lang.ref.Reference$ReferenceHandler.run(java.base at 15-ea >>> >> /Reference.java:213) >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=341.79s >>> >> tid=0x000001e349037250 nid=0x2a60 in Object.wait() >>> [0x000000340e1fe000] >>> >> java.lang.Thread.State: WAITING (on object monitor) >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>> >> - waiting on <0x0000000601400bc0> (a >>> >> java.lang.ref.ReferenceQueue$Lock) >>> >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea >>> >> /ReferenceQueue.java:155) >>> >> - locked <0x0000000601400bc0> (a >>> >> java.lang.ref.ReferenceQueue$Lock) >>> >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea >>> >> /ReferenceQueue.java:176) >>> >> at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 15-ea >>> >> /Finalizer.java:170) >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms >>> elapsed=341.78s >>> >> tid=0x000001e349058ae0 nid=0x35c8 runnable [0x0000000000000000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "Attach Listener" #5 daemon prio=5 os_prio=2 cpu=125.00ms >>> elapsed=341.78s >>> >> tid=0x000001e34905c5b0 nid=0x3e0c waiting on condition >>> [0x0000000000000000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "Service Thread" #6 daemon prio=9 os_prio=0 cpu=0.00ms elapsed=341.78s >>> >> tid=0x000001e34905f710 nid=0x398c runnable [0x0000000000000000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "C2 CompilerThread0" #7 daemon prio=9 os_prio=2 cpu=1781.25ms >>> >> elapsed=341.78s tid=0x000001e3490603f0 nid=0xcf0 waiting on condition >>> >> [0x0000000000000000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> No compile task >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "C1 CompilerThread0" #10 daemon prio=9 os_prio=2 cpu=765.63ms >>> >> elapsed=341.78s tid=0x000001e349065140 nid=0x3e54 waiting on condition >>> >> [0x0000000000000000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> No compile task >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "Sweeper thread" #11 daemon prio=9 os_prio=2 cpu=0.00ms >>> elapsed=341.78s >>> >> tid=0x000001e34906d620 nid=0x38bc runnable [0x0000000000000000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "Notification Thread" #12 daemon prio=9 os_prio=0 cpu=0.00ms >>> >> elapsed=341.76s tid=0x000001e349b36a20 nid=0x49b8 runnable >>> >> [0x0000000000000000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "Common-Cleaner" #13 daemon prio=8 os_prio=1 cpu=0.00ms >>> elapsed=341.75s >>> >> tid=0x000001e349b8c690 nid=0x26e4 in Object.wait() >>> [0x000000340eaff000] >>> >> java.lang.Thread.State: TIMED_WAITING (on object monitor) >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>> >> - waiting on >>> >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea >>> >> /ReferenceQueue.java:155) >>> >> - locked <0x0000000601401a78> (a >>> >> java.lang.ref.ReferenceQueue$Lock) >>> >> at jdk.internal.ref.CleanerImpl.run(java.base at 15-ea >>> >> /CleanerImpl.java:148) >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>> >> at jdk.internal.misc.InnocuousThread.run(java.base at 15-ea >>> >> /InnocuousThread.java:134) >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "JDI Internal Event Handler" #17 daemon prio=5 os_prio=0 cpu=15.63ms >>> >> elapsed=341.39s tid=0x000001e349da3400 nid=0x68 in Object.wait() >>> >> [0x000000340effe000] >>> >> java.lang.Thread.State: WAITING (on object monitor) >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>> >> - waiting on >>> >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) >>> >> at >>> com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea >>> >> /EventQueueImpl.java:190) >>> >> - locked <0x000000060154b630> (a >>> com.sun.tools.jdi.EventQueueImpl) >>> >> at >>> com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 15-ea >>> >> /EventQueueImpl.java:125) >>> >> at com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 15-ea >>> >> /InternalEventHandler.java:61) >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "JDI Target VM Interface" #16 daemon prio=5 os_prio=0 cpu=46.88ms >>> >> elapsed=341.39s tid=0x000001e349daa7c0 nid=0x3d04 runnable >>> >> [0x000000340f0fe000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native >>> >> Method) >>> >> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea >>> >> /SocketDispatcher.java:46) >>> >> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea >>> >> /NioSocketImpl.java:261) >>> >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea >>> >> /NioSocketImpl.java:312) >>> >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea >>> >> /NioSocketImpl.java:350) >>> >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea >>> >> /NioSocketImpl.java:803) >>> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >>> >> /Socket.java:981) >>> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >>> >> /Socket.java:976) >>> >> at com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 15-ea >>> >> /SocketConnection.java:82) >>> >> - locked <0x000000060154b998> (a java.lang.Object) >>> >> at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 15-ea >>> >> /TargetVM.java:124) >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>> >> >>> >> Locked ownable synchronizers: >>> >> - <0x0000000601577110> (a >>> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >>> >> >>> >> "event-handler" #18 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=341.38s >>> >> tid=0x000001e349dbb640 nid=0x203c in Object.wait() >>> [0x000000340edfe000] >>> >> java.lang.Thread.State: WAITING (on object monitor) >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>> >> - waiting on >>> >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) >>> >> at >>> com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea >>> >> /EventQueueImpl.java:190) >>> >> - locked <0x000000060154bc28> (a >>> com.sun.tools.jdi.EventQueueImpl) >>> >> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea >>> >> /EventQueueImpl.java:97) >>> >> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea >>> >> /EventQueueImpl.java:83) >>> >> at jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 15-ea >>> >> /JdiEventHandler.java:79) >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "output reader" #19 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=341.31s >>> >> tid=0x000001e34a141140 nid=0x49c0 runnable [0x000000340eeff000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native >>> >> Method) >>> >> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea >>> >> /SocketDispatcher.java:46) >>> >> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea >>> >> /NioSocketImpl.java:261) >>> >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea >>> >> /NioSocketImpl.java:312) >>> >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea >>> >> /NioSocketImpl.java:350) >>> >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea >>> >> /NioSocketImpl.java:803) >>> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >>> >> /Socket.java:981) >>> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >>> >> /Socket.java:976) >>> >> at java.io.FilterInputStream.read(java.base at 15-ea >>> >> /FilterInputStream.java:82) >>> >> at jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 15-ea >>> >> /DemultiplexInput.java:58) >>> >> >>> >> Locked ownable synchronizers: >>> >> - <0x0000000601553510> (a >>> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >>> >> >>> >> "Thread-0" #21 daemon prio=5 os_prio=0 cpu=312.50ms elapsed=341.22s >>> >> tid=0x000001e349d555c0 nid=0x4d88 waiting on condition >>> [0x000000340f1fe000] >>> >> java.lang.Thread.State: WAITING (parking) >>> >> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native >>> Method) >>> >> - parking to wait for <0x0000000601550fc0> (a >>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >>> >> at java.util.concurrent.locks.LockSupport.park(java.base at 15-ea >>> >> /LockSupport.java:341) >>> >> at >>> >> >>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 15-ea >>> >> /AbstractQueuedSynchronizer.java:505) >>> >> at >>> java.util.concurrent.ForkJoinPool.managedBlock(java.base at 15-ea >>> >> /ForkJoinPool.java:3137) >>> >> at >>> >> >>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea >>> >> /AbstractQueuedSynchronizer.java:1614) >>> >> at >>> java.util.concurrent.LinkedBlockingQueue.take(java.base at 15-ea >>> >> /LinkedBlockingQueue.java:435) >>> >> at >>> java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea >>> >> /ThreadPoolExecutor.java:1056) >>> >> at >>> >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea >>> >> /ThreadPoolExecutor.java:1116) >>> >> at >>> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea >>> >> /ThreadPoolExecutor.java:630) >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "Thread-2" #23 daemon prio=5 os_prio=0 cpu=338859.38ms elapsed=340.58s >>> >> tid=0x000001e34b07f030 nid=0xac0 runnable [0x000000340f3fe000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> at >>> >> >>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea >>> >> /AbstractQueuedSynchronizer.java:1749) >>> >> at >>> >> >>> jdk.internal.org.jline.utils.NonBlockingPumpReader.read(jdk.internal.le at 15-ea >>> >> /NonBlockingPumpReader.java:77) >>> >> at >>> >> >>> jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea >>> >> /NonBlockingReader.java:57) >>> >> at >>> >> >>> jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read(jdk.internal.le at 15-ea >>> >> /NonBlocking.java:104) >>> >> at >>> >> >>> jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea >>> >> /NonBlockingInputStream.java:36) >>> >> at >>> >> >>> jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 15-ea >>> >> /StopDetectingInputStream.java:66) >>> >> at >>> >> >>> jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$410/0x0000000800d2eb28.run(jdk.jshell at 15-ea >>> /Unknown >>> >> Source) >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>> >> >>> >> Locked ownable synchronizers: >>> >> - <0x00000006028b4318> (a >>> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >>> >> >>> >> "WindowsStreamPump" #25 daemon prio=5 os_prio=0 cpu=0.00ms >>> >> elapsed=340.53s tid=0x000001e34a461c90 nid=0x3688 runnable >>> >> [0x000000340f4fe000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> at >>> >> >>> jdk.internal.org.jline.terminal.impl.jna.win.Kernel32Impl.WaitForSingleObject(jdk.internal.le at 15-ea >>> /Native >>> >> Method) >>> >> at >>> >> >>> jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.readConsoleInput(jdk.internal.le at 15-ea >>> >> /JnaWinSysTerminal.java:185) >>> >> at >>> >> >>> jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.processConsoleInput(jdk.internal.le at 15-ea >>> >> /JnaWinSysTerminal.java:108) >>> >> at >>> >> >>> jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal.pump(jdk.internal.le at 15-ea >>> >> /AbstractWindowsTerminal.java:465) >>> >> at >>> >> >>> jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal$$Lambda$417/0x0000000800d310f8.run(jdk.internal.le at 15-ea >>> /Unknown >>> >> Source) >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "null non blocking reader thread" #26 daemon prio=5 os_prio=0 >>> cpu=0.00ms >>> >> elapsed=340.26s tid=0x000001e34a45fae0 nid=0x488 in Object.wait() >>> >> [0x000000340f6ff000] >>> >> java.lang.Thread.State: WAITING (on object monitor) >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>> >> - waiting on >>> >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) >>> >> at >>> >> >>> jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 15-ea >>> >> /StopDetectingInputStream.java:98) >>> >> - locked <0x0000000601e2b650> (a >>> >> jdk.internal.jshell.tool.StopDetectingInputStream) >>> >> at >>> >> >>> jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 15-ea >>> >> /NonBlockingInputStreamImpl.java:216) >>> >> at >>> >> >>> jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$584/0x0000000800d4f088.run(jdk.internal.le at 15-ea >>> /Unknown >>> >> Source) >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "RMI TCP Accept-0" #27 daemon prio=5 os_prio=0 cpu=0.00ms >>> elapsed=180.89s >>> >> tid=0x000001e34a45ffb0 nid=0x45f0 runnable [0x000000340d8fe000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> at sun.nio.ch.Net.accept(java.base at 15-ea/Native Method) >>> >> at sun.nio.ch.NioSocketImpl.accept(java.base at 15-ea >>> >> /NioSocketImpl.java:755) >>> >> at java.net.ServerSocket.implAccept(java.base at 15-ea >>> >> /ServerSocket.java:684) >>> >> at java.net.ServerSocket.platformImplAccept(java.base at 15-ea >>> >> /ServerSocket.java:650) >>> >> at java.net.ServerSocket.implAccept(java.base at 15-ea >>> >> /ServerSocket.java:626) >>> >> at java.net.ServerSocket.implAccept(java.base at 15-ea >>> >> /ServerSocket.java:583) >>> >> at java.net.ServerSocket.accept(java.base at 15-ea >>> >> /ServerSocket.java:540) >>> >> at >>> >> >>> sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(jdk.management.agent at 15-ea >>> >> /LocalRMIServerSocketFactory.java:52) >>> >> at >>> >> >>> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi at 15-ea >>> >> /TCPTransport.java:413) >>> >> at >>> >> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi at 15-ea >>> >> /TCPTransport.java:377) >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>> >> >>> >> Locked ownable synchronizers: >>> >> - <0x0000000602e53118> (a >>> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >>> >> >>> >> "RMI TCP Connection(1)-10.0.201.131" #28 daemon prio=5 os_prio=0 >>> >> cpu=437.50ms elapsed=180.87s tid=0x000001e34a4617c0 nid=0x4790 >>> runnable >>> >> [0x000000340fbfe000] >>> >> java.lang.Thread.State: RUNNABLE >>> >> at sun.nio.ch.Net.poll(java.base at 15-ea/Native Method) >>> >> at sun.nio.ch.NioSocketImpl.park(java.base at 15-ea >>> >> /NioSocketImpl.java:181) >>> >> at sun.nio.ch.NioSocketImpl.timedRead(java.base at 15-ea >>> >> /NioSocketImpl.java:285) >>> >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea >>> >> /NioSocketImpl.java:309) >>> >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea >>> >> /NioSocketImpl.java:350) >>> >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea >>> >> /NioSocketImpl.java:803) >>> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >>> >> /Socket.java:981) >>> >> at java.io.BufferedInputStream.fill(java.base at 15-ea >>> >> /BufferedInputStream.java:244) >>> >> at java.io.BufferedInputStream.read(java.base at 15-ea >>> >> /BufferedInputStream.java:263) >>> >> - locked <0x0000000602e19470> (a java.io.BufferedInputStream) >>> >> at java.io.FilterInputStream.read(java.base at 15-ea >>> >> /FilterInputStream.java:82) >>> >> at >>> >> sun.rmi.transport.tcp.TCPTransport.handleMessages(java.rmi at 15-ea >>> >> /TCPTransport.java:569) >>> >> at >>> >> >>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(java.rmi at 15-ea >>> >> /TCPTransport.java:828) >>> >> at >>> >> >>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(java.rmi at 15-ea >>> >> /TCPTransport.java:705) >>> >> at >>> >> >>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$686/0x0000000800da3998.run(java.rmi at 15-ea >>> /Unknown >>> >> Source) >>> >> at >>> >> java.security.AccessController.executePrivileged(java.base at 15-ea >>> >> /AccessController.java:753) >>> >> at java.security.AccessController.doPrivileged(java.base at 15-ea >>> >> /AccessController.java:391) >>> >> at >>> >> >>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(java.rmi at 15-ea >>> >> /TCPTransport.java:704) >>> >> at >>> >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea >>> >> /ThreadPoolExecutor.java:1130) >>> >> at >>> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea >>> >> /ThreadPoolExecutor.java:630) >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>> >> >>> >> Locked ownable synchronizers: >>> >> - <0x0000000602e19708> (a >>> >> java.util.concurrent.ThreadPoolExecutor$Worker) >>> >> - <0x0000000602e59038> (a >>> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) >>> >> >>> >> "RMI Scheduler(0)" #29 daemon prio=5 os_prio=0 cpu=0.00ms >>> elapsed=180.86s >>> >> tid=0x000001e34a462160 nid=0x1df0 waiting on condition >>> [0x000000340fcfe000] >>> >> java.lang.Thread.State: TIMED_WAITING (parking) >>> >> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native >>> Method) >>> >> - parking to wait for <0x0000000602e1af00> (a >>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >>> >> at >>> >> java.util.concurrent.locks.LockSupport.parkNanos(java.base at 15-ea >>> >> /LockSupport.java:252) >>> >> at >>> >> >>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 15-ea >>> >> /AbstractQueuedSynchronizer.java:1661) >>> >> at >>> >> >>> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea >>> >> /ScheduledThreadPoolExecutor.java:1182) >>> >> at >>> >> >>> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea >>> >> /ScheduledThreadPoolExecutor.java:899) >>> >> at >>> java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea >>> >> /ThreadPoolExecutor.java:1056) >>> >> at >>> >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea >>> >> /ThreadPoolExecutor.java:1116) >>> >> at >>> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea >>> >> /ThreadPoolExecutor.java:630) >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "JMX server connection timeout 30" #30 daemon prio=5 os_prio=0 >>> cpu=0.00ms >>> >> elapsed=180.86s tid=0x000001e34a45f610 nid=0x2fe8 in Object.wait() >>> >> [0x000000340fdff000] >>> >> java.lang.Thread.State: TIMED_WAITING (on object monitor) >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>> >> - waiting on >>> >> at >>> >> >>> com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(java.management at 15-ea >>> >> /ServerCommunicatorAdmin.java:171) >>> >> - locked <0x0000000602e1ca08> (a [I) >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>> >> >>> >> Locked ownable synchronizers: >>> >> - None >>> >> >>> >> "VM Thread" os_prio=2 cpu=515.63ms elapsed=341.79s >>> tid=0x000001e349031eb0 >>> >> nid=0x540 runnable >>> >> >>> >> "GC Thread#0" os_prio=2 cpu=328.13ms elapsed=341.80s >>> >> tid=0x000001e31c218710 nid=0x19e8 runnable >>> >> >>> >> "GC Thread#1" os_prio=2 cpu=265.63ms elapsed=341.53s >>> >> tid=0x000001e349b353d0 nid=0x1cc4 runnable >>> >> >>> >> "GC Thread#2" os_prio=2 cpu=218.75ms elapsed=340.37s >>> >> tid=0x000001e349b350a0 nid=0x1ddc runnable >>> >> >>> >> "GC Thread#3" os_prio=2 cpu=187.50ms elapsed=338.82s >>> >> tid=0x000001e349b35700 nid=0x4a48 runnable >>> >> >>> >> "GC Thread#4" os_prio=2 cpu=140.63ms elapsed=338.82s >>> >> tid=0x000001e349b340b0 nid=0x32e8 runnable >>> >> >>> >> "GC Thread#5" os_prio=2 cpu=156.25ms elapsed=338.82s >>> >> tid=0x000001e349b35a30 nid=0x38cc runnable >>> >> >>> >> "GC Thread#6" os_prio=2 cpu=171.88ms elapsed=338.82s >>> >> tid=0x000001e349b35d60 nid=0x3ed0 runnable >>> >> >>> >> "G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=341.80s >>> >> tid=0x000001e31c229930 nid=0x21c runnable >>> >> >>> >> "G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=341.80s >>> tid=0x000001e31c22a5a0 >>> >> nid=0x3920 runnable >>> >> >>> >> "G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=341.80s >>> tid=0x000001e31c253f10 >>> >> nid=0x1f84 runnable >>> >> >>> >> "G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms elapsed=341.80s >>> >> tid=0x000001e31c254b90 nid=0x27ac runnable >>> >> >>> >> "VM Periodic Task Thread" os_prio=2 cpu=15.63ms elapsed=341.76s >>> >> tid=0x000001e349b39710 nid=0x838 waiting on condition >>> >> >>> >> JNI global refs: 33, weak refs: 0 >>> >> >>> >> -- >>> >> Aaron Scott-Boddendijk >>> >> >>> >> On Tue, Jun 16, 2020 at 10:15 AM Robert Field < >>> robert.field at oracle.com> >>> >> wrote: >>> >> >>> >>> Make that jps/jstack >>> >>> >>> >>> -R >>> >>> >>> >>> On 2020-06-15 15:12, Robert Field wrote: >>> >>> > Thanks for the report. >>> >>> > >>> >>> > What, if anything, is the Java stack for this thread (jps)? >>> >>> > >>> >>> > -Robert >>> >>> > >>> >>> > >>> >>> > On 2020-06-15 14:41, Aaron Scott-Boddendijk wrote: >>> >>> >> System: >>> >>> >> * Windows 10 >>> >>> >> * Powershell >>> >>> >> >>> >>> >> When I start JShell, without executing anything, a CPU core is >>> always >>> >>> at >>> >>> >> 100% (a single thread though I haven't identified what it's >>> doing). >>> >>> >> >>> >>> >> The thread stack is as follows (with only the last two items >>> sometimes >>> >>> >> change - but I don't know the internals of the JVM to know if this >>> >>> >> useful >>> >>> >> or significant): >>> >>> >> >>> >>> >> ntoskrnl.exe!KeSynchronizeExecution+0x5b46 >>> >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x1c2d >>> >>> >> ntoskrnl.exe!KeWaitForSingleObject+0xab4 >>> >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x255 >>> >>> >> ntoskrnl.exe!RtlClearBitsEx+0x15a7 >>> >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x3828 >>> >>> >> ntoskrnl.exe!KeSynchronizeExecution+0x3120 >>> >>> >> jvm.dll!c2v_notifyCompilerInliningEvent+0x201797 >>> >>> >> >>> >>> >> The JDK 14 version of JShell does not have this issue but several >>> of >>> >>> the >>> >>> >> recent JDK 15 builds have done this. >>> >>> >> >>> >>> >> -- >>> >>> >> Aaron Scott-Boddendijk >>> >>> >>> >> >>> >> From talden at gmail.com Mon Jul 13 04:00:58 2020 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Mon, 13 Jul 2020 16:00:58 +1200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> Message-ID: I can confirm the CPU behaves as suggested with a sequence of entering and leaving `/edit`. Thanks Christian. -- Aaron Scott-Boddendijk On Mon, Jul 13, 2020 at 3:27 PM Christian Stein wrote: > It's coming from the "while(true)"-loop in StopDetectingInputStream.java > [0]. > > Aaron, try to open an external editor within the JShell session via > > /edit > > The CPU usage should drop immediately to normal levels. > As soon as you close the editor (it's the internal JShell Edit Pad for me) > the thread is again eating CPU cycles. Can you confirm this? > > While the editor is opened, the thread waits via > > jdk.internal.jshell.tool.StopDetectingInputStream.waitInputNeeded line: > 164 > > If no editor is open, the "input.read()" method does never wait: > > > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > line: 66 > > Cheers, > Christian > > [0]: > > https://github.com/openjdk/jdk/blob/faf4d7ccb792b16092c791c0ac77acdd440dbca1/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java#L57-L74 > > On Mon, Jul 13, 2020 at 5:05 AM Christian Stein > wrote: > > > Seems like "read line" from "jline" is underlying reason: > > > > Thread-2 [31] (RUNNABLE) > > > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await > > line: 1749 > > jdk.internal.org.jline.utils.NonBlockingPumpReader.read line: 77 > > jdk.internal.org.jline.utils.NonBlockingReader.read line: 57 > > > > > jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read > > line: 104 > > jdk.internal.org.jline.utils.NonBlockingInputStream.read line: 36 > > > > > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > > line: 66 > > > > > jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$347/0x0000000800cff330.run > > line: not available > > java.lang.Thread.run line: 832 > > > > It produces a constant high CPU usage and allocates a lot of RAM per > > second. > > > > Thread Name Thread State Blocked Count Total CPU Usage Deadlocked > > Allocated Memory > > Thread-2 RUNNABLE 1 0.06252084028009336 Not Enabled 196198305136 B > > > > > > > > > > > > On Mon, Jul 13, 2020 at 4:52 AM Christian Stein > > wrote: > > > >> Hi Aaron, > >> > >> I observe the same behaviour of JShell 15 build 30. > >> > >> Here, the 100% CPU workload is split on to 3-4 logical processors. > >> Grabbed an animated GIF of "jshell.exe -- /exit" session at [0]. > >> To me, it looks like a loop is running wild, w/o a > >> Thread.yield()/.sleep() call. > >> > >> Microsoft Windows [Version 10.0.19041.329] > >> > >> openjdk 15-ea 2020-09-15 > >> OpenJDK Runtime Environment (build 15-ea+30-1476) > >> OpenJDK 64-Bit Server VM (build 15-ea+30-1476, mixed mode, sharing) > >> > >> Cheers, > >> Christian > >> > >> [0]: > >> > https://drive.google.com/file/d/1KOQO5B9WrM4C43K3AB7H9VVPuh9hdCOe/view?usp=sharing > >> > >> > >> On Mon, Jul 13, 2020 at 4:24 AM Aaron Scott-Boddendijk < > talden at gmail.com> > >> wrote: > >> > >>> This still exists in JDK 15 build 31. > >>> > >>> Is any other Windows user able to reproduce this? I have two machines, > >>> one > >>> laptop and one desktop that show a CPU thread constantly @ 100% just by > >>> starting JShell. For the desktop machine that's not a major issue but > for > >>> the laptop this spins up the fans and eats the battery. > >>> > >>> JShell in JDK 14 is fine. > >>> > >>> I've yet to hear of any other user confirming this issue. > >>> > >>> -- > >>> Aaron Scott-Boddendijk > >>> > >>> > >>> On Fri, Jun 26, 2020 at 2:00 PM Aaron Scott-Boddendijk < > talden at gmail.com > >>> > > >>> wrote: > >>> > >>> > Just confirming that: > >>> > > >>> > * This still exists in JDK 15 build 29 > >>> > * Occurs on multiple unrelated Windows 10 machines with differing > major > >>> > versions of the OS. > >>> > * Does not occur in JDK 14.01 on these machines (OpenJDK 64-Bit > Server > >>> VM > >>> > Zulu14.28+21-CA) > >>> > * Does not appear to occur on Linux > >>> > > >>> > -- > >>> > Aaron Scott-Boddendijk > >>> > > >>> > > >>> > On Tue, Jun 16, 2020 at 11:16 AM Aaron Scott-Boddendijk < > >>> talden at gmail.com> > >>> > wrote: > >>> > > >>> >> This is the thread-dump from the JVM that VisualVM sees as using a > >>> core... > >>> >> > >>> >> 2020-06-16 11:07:35 > >>> >> Full thread dump OpenJDK 64-Bit Server VM (15-ea+27-1372 mixed mode, > >>> >> sharing): > >>> >> > >>> >> Threads class SMR info: > >>> >> _java_thread_list=0x000001e34a6040f0, length=23, elements={ > >>> >> 0x000001e31c1a1dc0, 0x000001e349035ee0, 0x000001e349037250, > >>> >> 0x000001e349058ae0, > >>> >> 0x000001e34905c5b0, 0x000001e34905f710, 0x000001e3490603f0, > >>> >> 0x000001e349065140, > >>> >> 0x000001e34906d620, 0x000001e349b36a20, 0x000001e349b8c690, > >>> >> 0x000001e349da3400, > >>> >> 0x000001e349daa7c0, 0x000001e349dbb640, 0x000001e34a141140, > >>> >> 0x000001e349d555c0, > >>> >> 0x000001e34b07f030, 0x000001e34a461c90, 0x000001e34a45fae0, > >>> >> 0x000001e34a45ffb0, > >>> >> 0x000001e34a4617c0, 0x000001e34a462160, 0x000001e34a45f610 > >>> >> } > >>> >> > >>> >> "main" #1 prio=5 os_prio=0 cpu=1078.13ms elapsed=341.81s > >>> >> tid=0x000001e31c1a1dc0 nid=0x16b0 in Object.wait() > >>> [0x000000340d9fe000] > >>> >> java.lang.Thread.State: TIMED_WAITING (on object monitor) > >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>> >> - waiting on > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 15-ea > >>> >> /NonBlockingInputStreamImpl.java:139) > >>> >> - locked <0x000000060fe87338> (a > >>> >> jdk.internal.jshell.tool.ConsoleIOContext$1) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > >>> >> /NonBlockingInputStream.java:62) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 15-ea > >>> >> /NonBlocking.java:168) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > >>> >> /NonBlockingReader.java:57) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 15-ea > >>> >> /BindingReader.java:160) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > >>> >> /BindingReader.java:110) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > >>> >> /BindingReader.java:61) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 15-ea > >>> >> /LineReaderImpl.java:913) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 15-ea > >>> >> /LineReaderImpl.java:946) > >>> >> at > >>> >> > >>> > jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 15-ea > >>> >> /ConsoleIOContext.java:154) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > >>> >> /LineReaderImpl.java:637) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > >>> >> /LineReaderImpl.java:454) > >>> >> at > >>> >> jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 15-ea > >>> >> /ConsoleIOContext.java:229) > >>> >> at > >>> jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 15-ea > >>> >> /JShellTool.java:1254) > >>> >> at jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 15-ea > >>> >> /JShellTool.java:1190) > >>> >> at > jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 15-ea > >>> >> /JShellTool.java:991) > >>> >> at > >>> >> jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 15-ea > >>> >> /JShellToolBuilder.java:254) > >>> >> at > >>> >> jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 15-ea > >>> >> /JShellToolProvider.java:120) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "Reference Handler" #2 daemon prio=10 os_prio=2 cpu=0.00ms > >>> >> elapsed=341.79s tid=0x000001e349035ee0 nid=0x13fc waiting on > condition > >>> >> [0x000000340e0fe000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> at > >>> >> java.lang.ref.Reference.waitForReferencePendingList(java.base at 15-ea > >>> /Native > >>> >> Method) > >>> >> at > >>> >> java.lang.ref.Reference.processPendingReferences(java.base at 15-ea > >>> >> /Reference.java:241) > >>> >> at > >>> java.lang.ref.Reference$ReferenceHandler.run(java.base at 15-ea > >>> >> /Reference.java:213) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=341.79s > >>> >> tid=0x000001e349037250 nid=0x2a60 in Object.wait() > >>> [0x000000340e1fe000] > >>> >> java.lang.Thread.State: WAITING (on object monitor) > >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>> >> - waiting on <0x0000000601400bc0> (a > >>> >> java.lang.ref.ReferenceQueue$Lock) > >>> >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >>> >> /ReferenceQueue.java:155) > >>> >> - locked <0x0000000601400bc0> (a > >>> >> java.lang.ref.ReferenceQueue$Lock) > >>> >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >>> >> /ReferenceQueue.java:176) > >>> >> at > java.lang.ref.Finalizer$FinalizerThread.run(java.base at 15-ea > >>> >> /Finalizer.java:170) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms > >>> elapsed=341.78s > >>> >> tid=0x000001e349058ae0 nid=0x35c8 runnable [0x0000000000000000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "Attach Listener" #5 daemon prio=5 os_prio=2 cpu=125.00ms > >>> elapsed=341.78s > >>> >> tid=0x000001e34905c5b0 nid=0x3e0c waiting on condition > >>> [0x0000000000000000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "Service Thread" #6 daemon prio=9 os_prio=0 cpu=0.00ms > elapsed=341.78s > >>> >> tid=0x000001e34905f710 nid=0x398c runnable [0x0000000000000000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "C2 CompilerThread0" #7 daemon prio=9 os_prio=2 cpu=1781.25ms > >>> >> elapsed=341.78s tid=0x000001e3490603f0 nid=0xcf0 waiting on > condition > >>> >> [0x0000000000000000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> No compile task > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "C1 CompilerThread0" #10 daemon prio=9 os_prio=2 cpu=765.63ms > >>> >> elapsed=341.78s tid=0x000001e349065140 nid=0x3e54 waiting on > condition > >>> >> [0x0000000000000000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> No compile task > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "Sweeper thread" #11 daemon prio=9 os_prio=2 cpu=0.00ms > >>> elapsed=341.78s > >>> >> tid=0x000001e34906d620 nid=0x38bc runnable [0x0000000000000000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "Notification Thread" #12 daemon prio=9 os_prio=0 cpu=0.00ms > >>> >> elapsed=341.76s tid=0x000001e349b36a20 nid=0x49b8 runnable > >>> >> [0x0000000000000000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "Common-Cleaner" #13 daemon prio=8 os_prio=1 cpu=0.00ms > >>> elapsed=341.75s > >>> >> tid=0x000001e349b8c690 nid=0x26e4 in Object.wait() > >>> [0x000000340eaff000] > >>> >> java.lang.Thread.State: TIMED_WAITING (on object monitor) > >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>> >> - waiting on > >>> >> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >>> >> /ReferenceQueue.java:155) > >>> >> - locked <0x0000000601401a78> (a > >>> >> java.lang.ref.ReferenceQueue$Lock) > >>> >> at jdk.internal.ref.CleanerImpl.run(java.base at 15-ea > >>> >> /CleanerImpl.java:148) > >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>> >> at jdk.internal.misc.InnocuousThread.run(java.base at 15-ea > >>> >> /InnocuousThread.java:134) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "JDI Internal Event Handler" #17 daemon prio=5 os_prio=0 cpu=15.63ms > >>> >> elapsed=341.39s tid=0x000001e349da3400 nid=0x68 in Object.wait() > >>> >> [0x000000340effe000] > >>> >> java.lang.Thread.State: WAITING (on object monitor) > >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>> >> - waiting on > >>> >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >>> >> at > >>> com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > >>> >> /EventQueueImpl.java:190) > >>> >> - locked <0x000000060154b630> (a > >>> com.sun.tools.jdi.EventQueueImpl) > >>> >> at > >>> com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 15-ea > >>> >> /EventQueueImpl.java:125) > >>> >> at com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 15-ea > >>> >> /InternalEventHandler.java:61) > >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "JDI Target VM Interface" #16 daemon prio=5 os_prio=0 cpu=46.88ms > >>> >> elapsed=341.39s tid=0x000001e349daa7c0 nid=0x3d04 runnable > >>> >> [0x000000340f0fe000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native > >>> >> Method) > >>> >> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > >>> >> /SocketDispatcher.java:46) > >>> >> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > >>> >> /NioSocketImpl.java:261) > >>> >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >>> >> /NioSocketImpl.java:312) > >>> >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >>> >> /NioSocketImpl.java:350) > >>> >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >>> >> /NioSocketImpl.java:803) > >>> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>> >> /Socket.java:981) > >>> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>> >> /Socket.java:976) > >>> >> at > com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 15-ea > >>> >> /SocketConnection.java:82) > >>> >> - locked <0x000000060154b998> (a java.lang.Object) > >>> >> at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 15-ea > >>> >> /TargetVM.java:124) > >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - <0x0000000601577110> (a > >>> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>> >> > >>> >> "event-handler" #18 daemon prio=5 os_prio=0 cpu=0.00ms > elapsed=341.38s > >>> >> tid=0x000001e349dbb640 nid=0x203c in Object.wait() > >>> [0x000000340edfe000] > >>> >> java.lang.Thread.State: WAITING (on object monitor) > >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>> >> - waiting on > >>> >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >>> >> at > >>> com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > >>> >> /EventQueueImpl.java:190) > >>> >> - locked <0x000000060154bc28> (a > >>> com.sun.tools.jdi.EventQueueImpl) > >>> >> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > >>> >> /EventQueueImpl.java:97) > >>> >> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > >>> >> /EventQueueImpl.java:83) > >>> >> at jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 15-ea > >>> >> /JdiEventHandler.java:79) > >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "output reader" #19 daemon prio=5 os_prio=0 cpu=0.00ms > elapsed=341.31s > >>> >> tid=0x000001e34a141140 nid=0x49c0 runnable [0x000000340eeff000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native > >>> >> Method) > >>> >> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > >>> >> /SocketDispatcher.java:46) > >>> >> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > >>> >> /NioSocketImpl.java:261) > >>> >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >>> >> /NioSocketImpl.java:312) > >>> >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >>> >> /NioSocketImpl.java:350) > >>> >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >>> >> /NioSocketImpl.java:803) > >>> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>> >> /Socket.java:981) > >>> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>> >> /Socket.java:976) > >>> >> at java.io.FilterInputStream.read(java.base at 15-ea > >>> >> /FilterInputStream.java:82) > >>> >> at > jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 15-ea > >>> >> /DemultiplexInput.java:58) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - <0x0000000601553510> (a > >>> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>> >> > >>> >> "Thread-0" #21 daemon prio=5 os_prio=0 cpu=312.50ms elapsed=341.22s > >>> >> tid=0x000001e349d555c0 nid=0x4d88 waiting on condition > >>> [0x000000340f1fe000] > >>> >> java.lang.Thread.State: WAITING (parking) > >>> >> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native > >>> Method) > >>> >> - parking to wait for <0x0000000601550fc0> (a > >>> >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > >>> >> at > java.util.concurrent.locks.LockSupport.park(java.base at 15-ea > >>> >> /LockSupport.java:341) > >>> >> at > >>> >> > >>> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 15-ea > >>> >> /AbstractQueuedSynchronizer.java:505) > >>> >> at > >>> java.util.concurrent.ForkJoinPool.managedBlock(java.base at 15-ea > >>> >> /ForkJoinPool.java:3137) > >>> >> at > >>> >> > >>> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > >>> >> /AbstractQueuedSynchronizer.java:1614) > >>> >> at > >>> java.util.concurrent.LinkedBlockingQueue.take(java.base at 15-ea > >>> >> /LinkedBlockingQueue.java:435) > >>> >> at > >>> java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > >>> >> /ThreadPoolExecutor.java:1056) > >>> >> at > >>> >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >>> >> /ThreadPoolExecutor.java:1116) > >>> >> at > >>> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >>> >> /ThreadPoolExecutor.java:630) > >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "Thread-2" #23 daemon prio=5 os_prio=0 cpu=338859.38ms > elapsed=340.58s > >>> >> tid=0x000001e34b07f030 nid=0xac0 runnable [0x000000340f3fe000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> at > >>> >> > >>> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > >>> >> /AbstractQueuedSynchronizer.java:1749) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.utils.NonBlockingPumpReader.read(jdk.internal.le at 15-ea > >>> >> /NonBlockingPumpReader.java:77) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > >>> >> /NonBlockingReader.java:57) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read(jdk.internal.le at 15-ea > >>> >> /NonBlocking.java:104) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > >>> >> /NonBlockingInputStream.java:36) > >>> >> at > >>> >> > >>> > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 15-ea > >>> >> /StopDetectingInputStream.java:66) > >>> >> at > >>> >> > >>> > jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$410/0x0000000800d2eb28.run(jdk.jshell at 15-ea > >>> /Unknown > >>> >> Source) > >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - <0x00000006028b4318> (a > >>> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>> >> > >>> >> "WindowsStreamPump" #25 daemon prio=5 os_prio=0 cpu=0.00ms > >>> >> elapsed=340.53s tid=0x000001e34a461c90 nid=0x3688 runnable > >>> >> [0x000000340f4fe000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.terminal.impl.jna.win.Kernel32Impl.WaitForSingleObject(jdk.internal.le at 15-ea > >>> /Native > >>> >> Method) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.readConsoleInput(jdk.internal.le at 15-ea > >>> >> /JnaWinSysTerminal.java:185) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.processConsoleInput(jdk.internal.le at 15-ea > >>> >> /JnaWinSysTerminal.java:108) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal.pump(jdk.internal.le at 15-ea > >>> >> /AbstractWindowsTerminal.java:465) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal$$Lambda$417/0x0000000800d310f8.run(jdk.internal.le at 15-ea > >>> /Unknown > >>> >> Source) > >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "null non blocking reader thread" #26 daemon prio=5 os_prio=0 > >>> cpu=0.00ms > >>> >> elapsed=340.26s tid=0x000001e34a45fae0 nid=0x488 in Object.wait() > >>> >> [0x000000340f6ff000] > >>> >> java.lang.Thread.State: WAITING (on object monitor) > >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>> >> - waiting on > >>> >> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >>> >> at > >>> >> > >>> jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 15-ea > >>> >> /StopDetectingInputStream.java:98) > >>> >> - locked <0x0000000601e2b650> (a > >>> >> jdk.internal.jshell.tool.StopDetectingInputStream) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 15-ea > >>> >> /NonBlockingInputStreamImpl.java:216) > >>> >> at > >>> >> > >>> > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$584/0x0000000800d4f088.run(jdk.internal.le at 15-ea > >>> /Unknown > >>> >> Source) > >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "RMI TCP Accept-0" #27 daemon prio=5 os_prio=0 cpu=0.00ms > >>> elapsed=180.89s > >>> >> tid=0x000001e34a45ffb0 nid=0x45f0 runnable [0x000000340d8fe000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> at sun.nio.ch.Net.accept(java.base at 15-ea/Native Method) > >>> >> at sun.nio.ch.NioSocketImpl.accept(java.base at 15-ea > >>> >> /NioSocketImpl.java:755) > >>> >> at java.net.ServerSocket.implAccept(java.base at 15-ea > >>> >> /ServerSocket.java:684) > >>> >> at java.net.ServerSocket.platformImplAccept(java.base at 15-ea > >>> >> /ServerSocket.java:650) > >>> >> at java.net.ServerSocket.implAccept(java.base at 15-ea > >>> >> /ServerSocket.java:626) > >>> >> at java.net.ServerSocket.implAccept(java.base at 15-ea > >>> >> /ServerSocket.java:583) > >>> >> at java.net.ServerSocket.accept(java.base at 15-ea > >>> >> /ServerSocket.java:540) > >>> >> at > >>> >> > >>> > sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(jdk.management.agent at 15-ea > >>> >> /LocalRMIServerSocketFactory.java:52) > >>> >> at > >>> >> > >>> > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi at 15-ea > >>> >> /TCPTransport.java:413) > >>> >> at > >>> >> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi at 15-ea > >>> >> /TCPTransport.java:377) > >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - <0x0000000602e53118> (a > >>> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>> >> > >>> >> "RMI TCP Connection(1)-10.0.201.131" #28 daemon prio=5 os_prio=0 > >>> >> cpu=437.50ms elapsed=180.87s tid=0x000001e34a4617c0 nid=0x4790 > >>> runnable > >>> >> [0x000000340fbfe000] > >>> >> java.lang.Thread.State: RUNNABLE > >>> >> at sun.nio.ch.Net.poll(java.base at 15-ea/Native Method) > >>> >> at sun.nio.ch.NioSocketImpl.park(java.base at 15-ea > >>> >> /NioSocketImpl.java:181) > >>> >> at sun.nio.ch.NioSocketImpl.timedRead(java.base at 15-ea > >>> >> /NioSocketImpl.java:285) > >>> >> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >>> >> /NioSocketImpl.java:309) > >>> >> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >>> >> /NioSocketImpl.java:350) > >>> >> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >>> >> /NioSocketImpl.java:803) > >>> >> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>> >> /Socket.java:981) > >>> >> at java.io.BufferedInputStream.fill(java.base at 15-ea > >>> >> /BufferedInputStream.java:244) > >>> >> at java.io.BufferedInputStream.read(java.base at 15-ea > >>> >> /BufferedInputStream.java:263) > >>> >> - locked <0x0000000602e19470> (a > java.io.BufferedInputStream) > >>> >> at java.io.FilterInputStream.read(java.base at 15-ea > >>> >> /FilterInputStream.java:82) > >>> >> at > >>> >> sun.rmi.transport.tcp.TCPTransport.handleMessages(java.rmi at 15-ea > >>> >> /TCPTransport.java:569) > >>> >> at > >>> >> > >>> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(java.rmi at 15-ea > >>> >> /TCPTransport.java:828) > >>> >> at > >>> >> > >>> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(java.rmi at 15-ea > >>> >> /TCPTransport.java:705) > >>> >> at > >>> >> > >>> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$686/0x0000000800da3998.run(java.rmi at 15-ea > >>> /Unknown > >>> >> Source) > >>> >> at > >>> >> java.security.AccessController.executePrivileged(java.base at 15-ea > >>> >> /AccessController.java:753) > >>> >> at > java.security.AccessController.doPrivileged(java.base at 15-ea > >>> >> /AccessController.java:391) > >>> >> at > >>> >> > >>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(java.rmi at 15-ea > >>> >> /TCPTransport.java:704) > >>> >> at > >>> >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >>> >> /ThreadPoolExecutor.java:1130) > >>> >> at > >>> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >>> >> /ThreadPoolExecutor.java:630) > >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - <0x0000000602e19708> (a > >>> >> java.util.concurrent.ThreadPoolExecutor$Worker) > >>> >> - <0x0000000602e59038> (a > >>> >> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>> >> > >>> >> "RMI Scheduler(0)" #29 daemon prio=5 os_prio=0 cpu=0.00ms > >>> elapsed=180.86s > >>> >> tid=0x000001e34a462160 nid=0x1df0 waiting on condition > >>> [0x000000340fcfe000] > >>> >> java.lang.Thread.State: TIMED_WAITING (parking) > >>> >> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native > >>> Method) > >>> >> - parking to wait for <0x0000000602e1af00> (a > >>> >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > >>> >> at > >>> >> java.util.concurrent.locks.LockSupport.parkNanos(java.base at 15-ea > >>> >> /LockSupport.java:252) > >>> >> at > >>> >> > >>> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 15-ea > >>> >> /AbstractQueuedSynchronizer.java:1661) > >>> >> at > >>> >> > >>> > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > >>> >> /ScheduledThreadPoolExecutor.java:1182) > >>> >> at > >>> >> > >>> > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > >>> >> /ScheduledThreadPoolExecutor.java:899) > >>> >> at > >>> java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > >>> >> /ThreadPoolExecutor.java:1056) > >>> >> at > >>> >> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >>> >> /ThreadPoolExecutor.java:1116) > >>> >> at > >>> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >>> >> /ThreadPoolExecutor.java:630) > >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "JMX server connection timeout 30" #30 daemon prio=5 os_prio=0 > >>> cpu=0.00ms > >>> >> elapsed=180.86s tid=0x000001e34a45f610 nid=0x2fe8 in Object.wait() > >>> >> [0x000000340fdff000] > >>> >> java.lang.Thread.State: TIMED_WAITING (on object monitor) > >>> >> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>> >> - waiting on > >>> >> at > >>> >> > >>> > com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(java.management at 15-ea > >>> >> /ServerCommunicatorAdmin.java:171) > >>> >> - locked <0x0000000602e1ca08> (a [I) > >>> >> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>> >> > >>> >> Locked ownable synchronizers: > >>> >> - None > >>> >> > >>> >> "VM Thread" os_prio=2 cpu=515.63ms elapsed=341.79s > >>> tid=0x000001e349031eb0 > >>> >> nid=0x540 runnable > >>> >> > >>> >> "GC Thread#0" os_prio=2 cpu=328.13ms elapsed=341.80s > >>> >> tid=0x000001e31c218710 nid=0x19e8 runnable > >>> >> > >>> >> "GC Thread#1" os_prio=2 cpu=265.63ms elapsed=341.53s > >>> >> tid=0x000001e349b353d0 nid=0x1cc4 runnable > >>> >> > >>> >> "GC Thread#2" os_prio=2 cpu=218.75ms elapsed=340.37s > >>> >> tid=0x000001e349b350a0 nid=0x1ddc runnable > >>> >> > >>> >> "GC Thread#3" os_prio=2 cpu=187.50ms elapsed=338.82s > >>> >> tid=0x000001e349b35700 nid=0x4a48 runnable > >>> >> > >>> >> "GC Thread#4" os_prio=2 cpu=140.63ms elapsed=338.82s > >>> >> tid=0x000001e349b340b0 nid=0x32e8 runnable > >>> >> > >>> >> "GC Thread#5" os_prio=2 cpu=156.25ms elapsed=338.82s > >>> >> tid=0x000001e349b35a30 nid=0x38cc runnable > >>> >> > >>> >> "GC Thread#6" os_prio=2 cpu=171.88ms elapsed=338.82s > >>> >> tid=0x000001e349b35d60 nid=0x3ed0 runnable > >>> >> > >>> >> "G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=341.80s > >>> >> tid=0x000001e31c229930 nid=0x21c runnable > >>> >> > >>> >> "G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=341.80s > >>> tid=0x000001e31c22a5a0 > >>> >> nid=0x3920 runnable > >>> >> > >>> >> "G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=341.80s > >>> tid=0x000001e31c253f10 > >>> >> nid=0x1f84 runnable > >>> >> > >>> >> "G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms elapsed=341.80s > >>> >> tid=0x000001e31c254b90 nid=0x27ac runnable > >>> >> > >>> >> "VM Periodic Task Thread" os_prio=2 cpu=15.63ms elapsed=341.76s > >>> >> tid=0x000001e349b39710 nid=0x838 waiting on condition > >>> >> > >>> >> JNI global refs: 33, weak refs: 0 > >>> >> > >>> >> -- > >>> >> Aaron Scott-Boddendijk > >>> >> > >>> >> On Tue, Jun 16, 2020 at 10:15 AM Robert Field < > >>> robert.field at oracle.com> > >>> >> wrote: > >>> >> > >>> >>> Make that jps/jstack > >>> >>> > >>> >>> -R > >>> >>> > >>> >>> On 2020-06-15 15:12, Robert Field wrote: > >>> >>> > Thanks for the report. > >>> >>> > > >>> >>> > What, if anything, is the Java stack for this thread (jps)? > >>> >>> > > >>> >>> > -Robert > >>> >>> > > >>> >>> > > >>> >>> > On 2020-06-15 14:41, Aaron Scott-Boddendijk wrote: > >>> >>> >> System: > >>> >>> >> * Windows 10 > >>> >>> >> * Powershell > >>> >>> >> > >>> >>> >> When I start JShell, without executing anything, a CPU core is > >>> always > >>> >>> at > >>> >>> >> 100% (a single thread though I haven't identified what it's > >>> doing). > >>> >>> >> > >>> >>> >> The thread stack is as follows (with only the last two items > >>> sometimes > >>> >>> >> change - but I don't know the internals of the JVM to know if > this > >>> >>> >> useful > >>> >>> >> or significant): > >>> >>> >> > >>> >>> >> ntoskrnl.exe!KeSynchronizeExecution+0x5b46 > >>> >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x1c2d > >>> >>> >> ntoskrnl.exe!KeWaitForSingleObject+0xab4 > >>> >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x255 > >>> >>> >> ntoskrnl.exe!RtlClearBitsEx+0x15a7 > >>> >>> >> ntoskrnl.exe!KeWaitForSingleObject+0x3828 > >>> >>> >> ntoskrnl.exe!KeSynchronizeExecution+0x3120 > >>> >>> >> jvm.dll!c2v_notifyCompilerInliningEvent+0x201797 > >>> >>> >> > >>> >>> >> The JDK 14 version of JShell does not have this issue but > several > >>> of > >>> >>> the > >>> >>> >> recent JDK 15 builds have done this. > >>> >>> >> > >>> >>> >> -- > >>> >>> >> Aaron Scott-Boddendijk > >>> >>> > >>> >> > >>> > >> > From michel.trudeau at oracle.com Mon Jul 13 22:04:44 2020 From: michel.trudeau at oracle.com (Michel Trudeau) Date: Mon, 13 Jul 2020 15:04:44 -0700 Subject: =?utf-8?Q?Re=3A_Records_are_called_=E2=80=9Emethods=E2=80=9C_in_J?= =?utf-8?Q?Shell?= In-Reply-To: <20200712163507.b6ff8ab09a6c540215cae158a90d7e03.44006f1d63.wbe@email17.godaddy.com> References: <20200712163507.b6ff8ab09a6c540215cae158a90d7e03.44006f1d63.wbe@email17.godaddy.com> Message-ID: [Moving this to kulla-dev] On Jul 12, 2020, at 4:35 PM, Lingo Coder wrote: java -version openjdk version "15-ea" 2020-09-15 OpenJDK Runtime Environment (build 15-ea+31-1502) OpenJDK 64-Bit Server VM (build 15-ea+31-1502, mixed mode, sharing) OS: Windows amd64 Steps to reproduce 1. Create some records... jshell>public record ConstExpr(Expr e) implements Expr{} jshell>public record PlusExpr(Expr a, Expr b) implements Expr{} jshell>public record TimesExpr(Expr x, Expr y) implements Expr{} jshell>public record NegExpr(Expr n) implements Expr{} 2. Observe that JShell calls the records you just created, ?methods?... jshell> ... | created method ConstExpr() ... | created method PlusExpr() ... | created method TimesExpr() ... | created method NegExpr() ... 3. Delete those records. JShell says they're ?methods?... jshell> /drop ConstExpr | dropped method ConstExpr() jshell> /drop PlusExpr | dropped method PlusExpr() jshell> /drop TimesExpr | dropped method TimesExpr() jshell> /drop NegExpr | dropped method NegExpr() Same deal with /edit. I did a screen recording if it's any help. [1] I couldn't reproduce this in Linux with the same JDK release/build. It only happens on Windows. ---- [1] https://i.imgur.com/ee8sJMf.gif From plugins at lingocoder.com Tue Jul 14 16:15:30 2020 From: plugins at lingocoder.com (Lingo Coder) Date: Tue, 14 Jul 2020 09:15:30 -0700 Subject: Records are called =?UTF-8?Q?=E2=80=9Emethods=E2=80=9C=20in=20JShell?= Message-ID: <20200714091530.b6ff8ab09a6c540215cae158a90d7e03.47025e54f8.wbe@email17.godaddy.com> Hi, Thanks for looking into this, Jorn. > ?...Are you sure that you are using the right jshell executable, and it's not picking up another one that's on the PATH as well?..? I'm sure :) I checked, rechecked and then, finally, rechecked that I rechecked. How I (re)checked: 1. I cleared the value of $PATH in the terminal where I run JShell 2. I then set the value of $PATH to be the file system location of the one and only installation of OpenJDK 15-ea (build 15-ea+31-1502) 3. I checked that the value of $PATH had only the one single entry 4. Does java -version report build 15-ea+31-1502? Confirmed! 5. I launched JShell 6. Created a record named ?JShellChecker?; 7. Observed JShell reports: ?created *method* JShellChecker? 8. Edited the record to implement a JShell .exe location check 9. JShell reports: ?replaced *method* JShellChecker? Observe [1] to check that it is really happening as I describe. TIA. ---- [1] https://imgur.com/NYBdYhn -------- Original Message -------- Subject: Re:_Records_are_called_?methods?_in_JSh ell From: Jorn Vernee Date: Tue, July 14, 2020 3:01 am To: Lingo Coder Cc: kulla-dev Hi, I was not able to reproduce this with JDK 15 build 31 (the same version that you are using). PS C:\Program Files\Java\jdk-15-b31\bin> ./jshell.exe --enable-preview | Welcome to JShell -- Version 15-ea | For an introduction type: /help intro jshell> public record Point(int x, int y) {} | created record Point jshell> /drop Point | dropped record Point Are you sure that you are using the right jshell executable, and it's not picking up another one that's on the PATH as well? Jorn On 14/07/2020 00:04, Michel Trudeau wrote: > [Moving this to kulla-dev] > > On Jul 12, 2020, at 4:35 PM, Lingo Coder wrote: > > java -version > openjdk version "15-ea" 2020-09-15 > OpenJDK Runtime Environment (build 15-ea+31-1502) > OpenJDK 64-Bit Server VM (build 15-ea+31-1502, mixed mode, sharing) > > OS: Windows amd64 > > Steps to reproduce > > 1. Create some records... > > jshell>public record ConstExpr(Expr e) implements Expr{} > > jshell>public record PlusExpr(Expr a, Expr b) implements Expr{} > > jshell>public record TimesExpr(Expr x, Expr y) implements Expr{} > > jshell>public record NegExpr(Expr n) implements Expr{} > > > 2. Observe that JShell calls the records you just created, > ?methods?... > > jshell> ... > | created method ConstExpr() ... > | created method PlusExpr() ... > | created method TimesExpr() ... > | created method NegExpr() ... > > 3. Delete those records. JShell says they're ?methods?... > > jshell> /drop ConstExpr > | dropped method ConstExpr() > > jshell> /drop PlusExpr > | dropped method PlusExpr() > > jshell> /drop TimesExpr > | dropped method TimesExpr() > > jshell> /drop NegExpr > | dropped method NegExpr() > > Same deal with /edit. I did a screen recording if it's any help. [1] > > I couldn't reproduce this in Linux with the same JDK release/build. It > only happens on Windows. > > ---- > > [1] https://i.imgur.com/ee8sJMf.gif > > From jan.lahoda at oracle.com Tue Jul 14 16:36:48 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 14 Jul 2020 18:36:48 +0200 Subject: =?UTF-8?Q?Re=3a_Records_are_called_=e2=80=9emethods=e2=80=9c_in_JSh?= =?UTF-8?Q?ell?= In-Reply-To: <20200714091530.b6ff8ab09a6c540215cae158a90d7e03.47025e54f8.wbe@email17.godaddy.com> References: <20200714091530.b6ff8ab09a6c540215cae158a90d7e03.47025e54f8.wbe@email17.godaddy.com> Message-ID: Hi, Would you have a small reproducible test case? I don't seem to be able to reproduce either. Thanks, Jan On 14. 07. 20 18:15, Lingo Coder wrote: > Hi, > > Thanks for looking into this, Jorn. > >> ?...Are you sure that you are using the right jshell executable, and > it's not picking up another one that's on the PATH as well?..? > > I'm sure :) > > I checked, rechecked and then, finally, rechecked that I rechecked. > > How I (re)checked: > > 1. I cleared the value of $PATH in the terminal where I run JShell > 2. I then set the value of $PATH to be the file system location of the > one and only installation of OpenJDK 15-ea (build 15-ea+31-1502) > 3. I checked that the value of $PATH had only the one single entry > 4. Does java -version report build 15-ea+31-1502? Confirmed! > 5. I launched JShell > 6. Created a record named ?JShellChecker?; > 7. Observed JShell reports: ?created *method* JShellChecker? > 8. Edited the record to implement a JShell .exe location check > 9. JShell reports: ?replaced *method* JShellChecker? > > Observe [1] to check that it is really happening as I describe. > > TIA. > > ---- > [1] https://imgur.com/NYBdYhn > > > > > -------- Original Message -------- > Subject: Re:_Records_are_called_?methods?_in_JSh ell > From: Jorn Vernee > Date: Tue, July 14, 2020 3:01 am > To: Lingo Coder > Cc: kulla-dev > > Hi, > > I was not able to reproduce this with JDK 15 build 31 (the same version > that you are using). > > PS C:\Program Files\Java\jdk-15-b31\bin> ./jshell.exe --enable-preview > | Welcome to JShell -- Version 15-ea > | For an introduction type: /help intro > > jshell> public record Point(int x, int y) {} > | created record Point > > jshell> /drop Point > | dropped record Point > > Are you sure that you are using the right jshell executable, and it's > not picking up another one that's on the PATH as well? > > Jorn > > On 14/07/2020 00:04, Michel Trudeau wrote: >> [Moving this to kulla-dev] >> >> On Jul 12, 2020, at 4:35 PM, Lingo Coder wrote: >> >> java -version >> openjdk version "15-ea" 2020-09-15 >> OpenJDK Runtime Environment (build 15-ea+31-1502) >> OpenJDK 64-Bit Server VM (build 15-ea+31-1502, mixed mode, sharing) >> >> OS: Windows amd64 >> >> Steps to reproduce >> >> 1. Create some records... >> >> jshell>public record ConstExpr(Expr e) implements Expr{} >> >> jshell>public record PlusExpr(Expr a, Expr b) implements Expr{} >> >> jshell>public record TimesExpr(Expr x, Expr y) implements Expr{} >> >> jshell>public record NegExpr(Expr n) implements Expr{} >> >> >> 2. Observe that JShell calls the records you just created, >> ?methods?... >> >> jshell> ... >> | created method ConstExpr() ... >> | created method PlusExpr() ... >> | created method TimesExpr() ... >> | created method NegExpr() ... >> >> 3. Delete those records. JShell says they're ?methods?... >> >> jshell> /drop ConstExpr >> | dropped method ConstExpr() >> >> jshell> /drop PlusExpr >> | dropped method PlusExpr() >> >> jshell> /drop TimesExpr >> | dropped method TimesExpr() >> >> jshell> /drop NegExpr >> | dropped method NegExpr() >> >> Same deal with /edit. I did a screen recording if it's any help. [1] >> >> I couldn't reproduce this in Linux with the same JDK release/build. It >> only happens on Windows. >> >> ---- >> >> [1] https://i.imgur.com/ee8sJMf.gif >> >> From plugins at lingocoder.com Tue Jul 14 16:58:59 2020 From: plugins at lingocoder.com (Lingo Coder) Date: Tue, 14 Jul 2020 09:58:59 -0700 Subject: Records are called =?UTF-8?Q?=E2=80=9Emethods=E2=80=9C=20in=20JShell?= Message-ID: <20200714095859.b6ff8ab09a6c540215cae158a90d7e03.713463ff39.wbe@email17.godaddy.com> Hi, Thanks for looking into this, Jan. > ?...Would you have a small reproducible test case?...? Sure. In what form would you prefer that? A .jsh or something? For what it's worth, I'm on Windows 7 Professional 64 bit. I mention that for completeness. It would be surprising to learn that the JDK behaved differently on 7 than it does on 10. Would you agree? TIA. -------- Original Message -------- Subject: Re:_Records_are_called_?methods?_in_JSh ell From: Jan Lahoda Date: Tue, July 14, 2020 9:36 am To: Lingo Coder , kulla-dev Cc: Jorn Vernee Hi, Would you have a small reproducible test case? I don't seem to be able to reproduce either. Thanks, Jan On 14. 07. 20 18:15, Lingo Coder wrote: > Hi, > > Thanks for looking into this, Jorn. > >> ?...Are you sure that you are using the right jshell executable, and > it's not picking up another one that's on the PATH as well?..? > > I'm sure :) > > I checked, rechecked and then, finally, rechecked that I rechecked. > > How I (re)checked: > > 1. I cleared the value of $PATH in the terminal where I run JShell > 2. I then set the value of $PATH to be the file system location of the > one and only installation of OpenJDK 15-ea (build 15-ea+31-1502) > 3. I checked that the value of $PATH had only the one single entry > 4. Does java -version report build 15-ea+31-1502? Confirmed! > 5. I launched JShell > 6. Created a record named ?JShellChecker?; > 7. Observed JShell reports: ?created *method* JShellChecker? > 8. Edited the record to implement a JShell .exe location check > 9. JShell reports: ?replaced *method* JShellChecker? > > Observe [1] to check that it is really happening as I describe. > > TIA. > > ---- > [1] https://imgur.com/NYBdYhn > > > > > -------- Original Message -------- > Subject: Re:_Records_are_called_?methods?_in_JSh ell > From: Jorn Vernee > Date: Tue, July 14, 2020 3:01 am > To: Lingo Coder > Cc: kulla-dev > > Hi, > > I was not able to reproduce this with JDK 15 build 31 (the same version > that you are using). > > PS C:\Program Files\Java\jdk-15-b31\bin> ./jshell.exe --enable-preview > | Welcome to JShell -- Version 15-ea > | For an introduction type: /help intro > > jshell> public record Point(int x, int y) {} > | created record Point > > jshell> /drop Point > | dropped record Point > > Are you sure that you are using the right jshell executable, and it's > not picking up another one that's on the PATH as well? > > Jorn > > On 14/07/2020 00:04, Michel Trudeau wrote: >> [Moving this to kulla-dev] >> >> On Jul 12, 2020, at 4:35 PM, Lingo Coder wrote: >> >> java -version >> openjdk version "15-ea" 2020-09-15 >> OpenJDK Runtime Environment (build 15-ea+31-1502) >> OpenJDK 64-Bit Server VM (build 15-ea+31-1502, mixed mode, sharing) >> >> OS: Windows amd64 >> >> Steps to reproduce >> >> 1. Create some records... >> >> jshell>public record ConstExpr(Expr e) implements Expr{} >> >> jshell>public record PlusExpr(Expr a, Expr b) implements Expr{} >> >> jshell>public record TimesExpr(Expr x, Expr y) implements Expr{} >> >> jshell>public record NegExpr(Expr n) implements Expr{} >> >> >> 2. Observe that JShell calls the records you just created, >> ?methods?... >> >> jshell> ... >> | created method ConstExpr() ... >> | created method PlusExpr() ... >> | created method TimesExpr() ... >> | created method NegExpr() ... >> >> 3. Delete those records. JShell says they're ?methods?... >> >> jshell> /drop ConstExpr >> | dropped method ConstExpr() >> >> jshell> /drop PlusExpr >> | dropped method PlusExpr() >> >> jshell> /drop TimesExpr >> | dropped method TimesExpr() >> >> jshell> /drop NegExpr >> | dropped method NegExpr() >> >> Same deal with /edit. I did a screen recording if it's any help. [1] >> >> I couldn't reproduce this in Linux with the same JDK release/build. It >> only happens on Windows. >> >> ---- >> >> [1] https://i.imgur.com/ee8sJMf.gif >> >> From jan.lahoda at oracle.com Tue Jul 14 18:11:58 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 14 Jul 2020 20:11:58 +0200 Subject: =?UTF-8?Q?Re=3a_Records_are_called_=e2=80=9emethods=e2=80=9c_in_JSh?= =?UTF-8?Q?ell?= In-Reply-To: <20200714095859.b6ff8ab09a6c540215cae158a90d7e03.713463ff39.wbe@email17.godaddy.com> References: <20200714095859.b6ff8ab09a6c540215cae158a90d7e03.713463ff39.wbe@email17.godaddy.com> Message-ID: <981b85ba-06e5-07f6-d725-5f15d78fec58@oracle.com> On 14. 07. 20 18:58, Lingo Coder wrote: > Hi, > > Thanks for looking into this, Jan. > >> ?...Would you have a small reproducible test case?...? > > Sure. In what form would you prefer that? A .jsh or something? I am hoping the problem can be seen by running a few commands in JShell - if you could just write them here, that'd be enough. (I tried several commands based on the animations, but didn't succeed, so I am probably missing some detail somewhere.) Thanks, Jan > > For what it's worth, I'm on Windows 7 Professional 64 bit. I > mention that for completeness. It would be surprising to learn > that the JDK behaved differently on 7 than it does on 10. > Would you agree? > > TIA. > > -------- Original Message -------- > Subject: Re:_Records_are_called_?methods?_in_JSh ell > From: Jan Lahoda > Date: Tue, July 14, 2020 9:36 am > To: Lingo Coder , kulla-dev > > Cc: Jorn Vernee > > Hi, > > Would you have a small reproducible test case? I don't seem to be able > to reproduce either. > > Thanks, > Jan > > On 14. 07. 20 18:15, Lingo Coder wrote: >> Hi, >> >> Thanks for looking into this, Jorn. >> >>> ?...Are you sure that you are using the right jshell executable, and >> it's not picking up another one that's on the PATH as well?..? >> >> I'm sure :) >> >> I checked, rechecked and then, finally, rechecked that I rechecked. >> >> How I (re)checked: >> >> 1. I cleared the value of $PATH in the terminal where I run JShell >> 2. I then set the value of $PATH to be the file system location of the >> one and only installation of OpenJDK 15-ea (build 15-ea+31-1502) >> 3. I checked that the value of $PATH had only the one single entry >> 4. Does java -version report build 15-ea+31-1502? Confirmed! >> 5. I launched JShell >> 6. Created a record named ?JShellChecker?; >> 7. Observed JShell reports: ?created *method* JShellChecker? >> 8. Edited the record to implement a JShell .exe location check >> 9. JShell reports: ?replaced *method* JShellChecker? >> >> Observe [1] to check that it is really happening as I describe. >> >> TIA. >> >> ---- >> [1] https://imgur.com/NYBdYhn >> >> >> >> >> -------- Original Message -------- >> Subject: Re:_Records_are_called_?methods?_in_JSh ell >> From: Jorn Vernee >> Date: Tue, July 14, 2020 3:01 am >> To: Lingo Coder >> Cc: kulla-dev >> >> Hi, >> >> I was not able to reproduce this with JDK 15 build 31 (the same version >> that you are using). >> >> PS C:\Program Files\Java\jdk-15-b31\bin> ./jshell.exe --enable-preview >> | Welcome to JShell -- Version 15-ea >> | For an introduction type: /help intro >> >> jshell> public record Point(int x, int y) {} >> | created record Point >> >> jshell> /drop Point >> | dropped record Point >> >> Are you sure that you are using the right jshell executable, and it's >> not picking up another one that's on the PATH as well? >> >> Jorn >> >> On 14/07/2020 00:04, Michel Trudeau wrote: >>> [Moving this to kulla-dev] >>> >>> On Jul 12, 2020, at 4:35 PM, Lingo Coder wrote: >>> >>> java -version >>> openjdk version "15-ea" 2020-09-15 >>> OpenJDK Runtime Environment (build 15-ea+31-1502) >>> OpenJDK 64-Bit Server VM (build 15-ea+31-1502, mixed mode, sharing) >>> >>> OS: Windows amd64 >>> >>> Steps to reproduce >>> >>> 1. Create some records... >>> >>> jshell>public record ConstExpr(Expr e) implements Expr{} >>> >>> jshell>public record PlusExpr(Expr a, Expr b) implements Expr{} >>> >>> jshell>public record TimesExpr(Expr x, Expr y) implements Expr{} >>> >>> jshell>public record NegExpr(Expr n) implements Expr{} >>> >>> >>> 2. Observe that JShell calls the records you just created, >>> ?methods?... >>> >>> jshell> ... >>> | created method ConstExpr() ... >>> | created method PlusExpr() ... >>> | created method TimesExpr() ... >>> | created method NegExpr() ... >>> >>> 3. Delete those records. JShell says they're ?methods?... >>> >>> jshell> /drop ConstExpr >>> | dropped method ConstExpr() >>> >>> jshell> /drop PlusExpr >>> | dropped method PlusExpr() >>> >>> jshell> /drop TimesExpr >>> | dropped method TimesExpr() >>> >>> jshell> /drop NegExpr >>> | dropped method NegExpr() >>> >>> Same deal with /edit. I did a screen recording if it's any help. [1] >>> >>> I couldn't reproduce this in Linux with the same JDK release/build. It >>> only happens on Windows. >>> >>> ---- >>> >>> [1] https://i.imgur.com/ee8sJMf.gif >>> >>> From plugins at lingocoder.com Tue Jul 14 18:47:12 2020 From: plugins at lingocoder.com (Lingo Coder) Date: Tue, 14 Jul 2020 11:47:12 -0700 Subject: Records are called =?UTF-8?Q?=E2=80=9Emethods=E2=80=9C=20in=20JShell?= Message-ID: <20200714114712.b6ff8ab09a6c540215cae158a90d7e03.33bea43126.wbe@email17.godaddy.com> Thanks Jan, > ?...the problem can be seen by running a few commands in JShell.? While I was awaiting your reply, I went ahead and did a script that contains exactly what I typed in the most recent screen recording [1]. TIL ? but you will already know ? that running .jsh scripts don't produce the output typically seen in the REPL's interactive mode. So to repeat what I did in the recordings, you'll need to manually copy & paste the code into JShell interactively. Please correct me if I'm wrong, Jan. But am I correct in assuming that the JDK shouldn't behave differently on Windows 7 vs 10? TIA. ---- [1] https://bit.ly/jshRecMeth -------- Original Message -------- Subject: Re:_Records_are_called_?methods?_in_JSh ell From: Jan Lahoda Date: Tue, July 14, 2020 11:11 am To: Lingo Coder , kulla-dev Cc: Jorn Vernee On 14. 07. 20 18:58, Lingo Coder wrote: > Hi, > > Thanks for looking into this, Jan. > >> ?...Would you have a small reproducible test case?...? > > Sure. In what form would you prefer that? A .jsh or something? I am hoping the problem can be seen by running a few commands in JShell - if you could just write them here, that'd be enough. (I tried several commands based on the animations, but didn't succeed, so I am probably missing some detail somewhere.) Thanks, Jan > > For what it's worth, I'm on Windows 7 Professional 64 bit. I > mention that for completeness. It would be surprising to learn > that the JDK behaved differently on 7 than it does on 10. > Would you agree? > > TIA. > > -------- Original Message -------- > Subject: Re:_Records_are_called_?methods?_in_JSh ell > From: Jan Lahoda > Date: Tue, July 14, 2020 9:36 am > To: Lingo Coder , kulla-dev > > Cc: Jorn Vernee > > Hi, > > Would you have a small reproducible test case? I don't seem to be able > to reproduce either. > > Thanks, > Jan > > On 14. 07. 20 18:15, Lingo Coder wrote: >> Hi, >> >> Thanks for looking into this, Jorn. >> >>> ?...Are you sure that you are using the right jshell executable, and >> it's not picking up another one that's on the PATH as well?..? >> >> I'm sure :) >> >> I checked, rechecked and then, finally, rechecked that I rechecked. >> >> How I (re)checked: >> >> 1. I cleared the value of $PATH in the terminal where I run JShell >> 2. I then set the value of $PATH to be the file system location of the >> one and only installation of OpenJDK 15-ea (build 15-ea+31-1502) >> 3. I checked that the value of $PATH had only the one single entry >> 4. Does java -version report build 15-ea+31-1502? Confirmed! >> 5. I launched JShell >> 6. Created a record named ?JShellChecker?; >> 7. Observed JShell reports: ?created *method* JShellChecker? >> 8. Edited the record to implement a JShell .exe location check >> 9. JShell reports: ?replaced *method* JShellChecker? >> >> Observe [1] to check that it is really happening as I describe. >> >> TIA. >> >> ---- >> [1] https://imgur.com/NYBdYhn >> >> >> >> >> -------- Original Message -------- >> Subject: Re:_Records_are_called_?methods?_in_JSh ell >> From: Jorn Vernee >> Date: Tue, July 14, 2020 3:01 am >> To: Lingo Coder >> Cc: kulla-dev >> >> Hi, >> >> I was not able to reproduce this with JDK 15 build 31 (the same version >> that you are using). >> >> PS C:\Program Files\Java\jdk-15-b31\bin> ./jshell.exe --enable-preview >> | Welcome to JShell -- Version 15-ea >> | For an introduction type: /help intro >> >> jshell> public record Point(int x, int y) {} >> | created record Point >> >> jshell> /drop Point >> | dropped record Point >> >> Are you sure that you are using the right jshell executable, and it's >> not picking up another one that's on the PATH as well? >> >> Jorn >> >> On 14/07/2020 00:04, Michel Trudeau wrote: >>> [Moving this to kulla-dev] >>> >>> On Jul 12, 2020, at 4:35 PM, Lingo Coder wrote: >>> >>> java -version >>> openjdk version "15-ea" 2020-09-15 >>> OpenJDK Runtime Environment (build 15-ea+31-1502) >>> OpenJDK 64-Bit Server VM (build 15-ea+31-1502, mixed mode, sharing) >>> >>> OS: Windows amd64 >>> >>> Steps to reproduce >>> >>> 1. Create some records... >>> >>> jshell>public record ConstExpr(Expr e) implements Expr{} >>> >>> jshell>public record PlusExpr(Expr a, Expr b) implements Expr{} >>> >>> jshell>public record TimesExpr(Expr x, Expr y) implements Expr{} >>> >>> jshell>public record NegExpr(Expr n) implements Expr{} >>> >>> >>> 2. Observe that JShell calls the records you just created, >>> ?methods?... >>> >>> jshell> ... >>> | created method ConstExpr() ... >>> | created method PlusExpr() ... >>> | created method TimesExpr() ... >>> | created method NegExpr() ... >>> >>> 3. Delete those records. JShell says they're ?methods?... >>> >>> jshell> /drop ConstExpr >>> | dropped method ConstExpr() >>> >>> jshell> /drop PlusExpr >>> | dropped method PlusExpr() >>> >>> jshell> /drop TimesExpr >>> | dropped method TimesExpr() >>> >>> jshell> /drop NegExpr >>> | dropped method NegExpr() >>> >>> Same deal with /edit. I did a screen recording if it's any help. [1] >>> >>> I couldn't reproduce this in Linux with the same JDK release/build. It >>> only happens on Windows. >>> >>> ---- >>> >>> [1] https://i.imgur.com/ee8sJMf.gif >>> >>> From jan.lahoda at oracle.com Tue Jul 14 19:05:24 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 14 Jul 2020 21:05:24 +0200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> Message-ID: Hi, Thanks for the report and analysis. I've filled: https://bugs.openjdk.java.net/browse/JDK-8249367 I think the issue is in: http://hg.openjdk.java.net/jdk/jdk/file/1e249ca8d585/src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlocking.java#l104 If the timeout is zero (which it is when invoked from StopDetectingInputStream, as it calls the read method without timeout), the method invocation will exit immediately, and it will be immediately called again, etc. Jan On 13. 07. 20 6:00, Aaron Scott-Boddendijk wrote: > I can confirm the CPU behaves as suggested with a sequence of entering and > leaving `/edit`. > > Thanks Christian. > > -- > Aaron Scott-Boddendijk > > On Mon, Jul 13, 2020 at 3:27 PM Christian Stein wrote: > >> It's coming from the "while(true)"-loop in StopDetectingInputStream.java >> [0]. >> >> Aaron, try to open an external editor within the JShell session via >> >> /edit >> >> The CPU usage should drop immediately to normal levels. >> As soon as you close the editor (it's the internal JShell Edit Pad for me) >> the thread is again eating CPU cycles. Can you confirm this? >> >> While the editor is opened, the thread waits via >> >> jdk.internal.jshell.tool.StopDetectingInputStream.waitInputNeeded line: >> 164 >> >> If no editor is open, the "input.read()" method does never wait: >> >> >> jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 >> line: 66 >> >> Cheers, >> Christian >> >> [0]: >> >> https://github.com/openjdk/jdk/blob/faf4d7ccb792b16092c791c0ac77acdd440dbca1/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java#L57-L74 >> >> On Mon, Jul 13, 2020 at 5:05 AM Christian Stein >> wrote: >> >>> Seems like "read line" from "jline" is underlying reason: >>> >>> Thread-2 [31] (RUNNABLE) >>> >>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await >>> line: 1749 >>> jdk.internal.org.jline.utils.NonBlockingPumpReader.read line: 77 >>> jdk.internal.org.jline.utils.NonBlockingReader.read line: 57 >>> >>> >> jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read >>> line: 104 >>> jdk.internal.org.jline.utils.NonBlockingInputStream.read line: 36 >>> >>> >> jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 >>> line: 66 >>> >>> >> jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$347/0x0000000800cff330.run >>> line: not available >>> java.lang.Thread.run line: 832 >>> >>> It produces a constant high CPU usage and allocates a lot of RAM per >>> second. >>> >>> Thread Name Thread State Blocked Count Total CPU Usage Deadlocked >>> Allocated Memory >>> Thread-2 RUNNABLE 1 0.06252084028009336 Not Enabled 196198305136 B >>> >>> >>> >>> >>> >>> On Mon, Jul 13, 2020 at 4:52 AM Christian Stein >>> wrote: >>> >>>> Hi Aaron, >>>> >>>> I observe the same behaviour of JShell 15 build 30. >>>> >>>> Here, the 100% CPU workload is split on to 3-4 logical processors. >>>> Grabbed an animated GIF of "jshell.exe -- /exit" session at [0]. >>>> To me, it looks like a loop is running wild, w/o a >>>> Thread.yield()/.sleep() call. >>>> >>>> Microsoft Windows [Version 10.0.19041.329] >>>> >>>> openjdk 15-ea 2020-09-15 >>>> OpenJDK Runtime Environment (build 15-ea+30-1476) >>>> OpenJDK 64-Bit Server VM (build 15-ea+30-1476, mixed mode, sharing) >>>> >>>> Cheers, >>>> Christian >>>> >>>> [0]: >>>> >> https://drive.google.com/file/d/1KOQO5B9WrM4C43K3AB7H9VVPuh9hdCOe/view?usp=sharing >>>> >>>> >>>> On Mon, Jul 13, 2020 at 4:24 AM Aaron Scott-Boddendijk < >> talden at gmail.com> >>>> wrote: >>>> >>>>> This still exists in JDK 15 build 31. >>>>> >>>>> Is any other Windows user able to reproduce this? I have two machines, >>>>> one >>>>> laptop and one desktop that show a CPU thread constantly @ 100% just by >>>>> starting JShell. For the desktop machine that's not a major issue but >> for >>>>> the laptop this spins up the fans and eats the battery. >>>>> >>>>> JShell in JDK 14 is fine. >>>>> >>>>> I've yet to hear of any other user confirming this issue. >>>>> >>>>> -- >>>>> Aaron Scott-Boddendijk >>>>> >>>>> >>>>> On Fri, Jun 26, 2020 at 2:00 PM Aaron Scott-Boddendijk < >> talden at gmail.com >>>>>> >>>>> wrote: >>>>> >>>>>> Just confirming that: >>>>>> >>>>>> * This still exists in JDK 15 build 29 >>>>>> * Occurs on multiple unrelated Windows 10 machines with differing >> major >>>>>> versions of the OS. >>>>>> * Does not occur in JDK 14.01 on these machines (OpenJDK 64-Bit >> Server >>>>> VM >>>>>> Zulu14.28+21-CA) >>>>>> * Does not appear to occur on Linux >>>>>> >>>>>> -- >>>>>> Aaron Scott-Boddendijk >>>>>> >>>>>> >>>>>> On Tue, Jun 16, 2020 at 11:16 AM Aaron Scott-Boddendijk < >>>>> talden at gmail.com> >>>>>> wrote: >>>>>> >>>>>>> This is the thread-dump from the JVM that VisualVM sees as using a >>>>> core... >>>>>>> >>>>>>> 2020-06-16 11:07:35 >>>>>>> Full thread dump OpenJDK 64-Bit Server VM (15-ea+27-1372 mixed mode, >>>>>>> sharing): >>>>>>> >>>>>>> Threads class SMR info: >>>>>>> _java_thread_list=0x000001e34a6040f0, length=23, elements={ >>>>>>> 0x000001e31c1a1dc0, 0x000001e349035ee0, 0x000001e349037250, >>>>>>> 0x000001e349058ae0, >>>>>>> 0x000001e34905c5b0, 0x000001e34905f710, 0x000001e3490603f0, >>>>>>> 0x000001e349065140, >>>>>>> 0x000001e34906d620, 0x000001e349b36a20, 0x000001e349b8c690, >>>>>>> 0x000001e349da3400, >>>>>>> 0x000001e349daa7c0, 0x000001e349dbb640, 0x000001e34a141140, >>>>>>> 0x000001e349d555c0, >>>>>>> 0x000001e34b07f030, 0x000001e34a461c90, 0x000001e34a45fae0, >>>>>>> 0x000001e34a45ffb0, >>>>>>> 0x000001e34a4617c0, 0x000001e34a462160, 0x000001e34a45f610 >>>>>>> } >>>>>>> >>>>>>> "main" #1 prio=5 os_prio=0 cpu=1078.13ms elapsed=341.81s >>>>>>> tid=0x000001e31c1a1dc0 nid=0x16b0 in Object.wait() >>>>> [0x000000340d9fe000] >>>>>>> java.lang.Thread.State: TIMED_WAITING (on object monitor) >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>>>>>> - waiting on >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 15-ea >>>>>>> /NonBlockingInputStreamImpl.java:139) >>>>>>> - locked <0x000000060fe87338> (a >>>>>>> jdk.internal.jshell.tool.ConsoleIOContext$1) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea >>>>>>> /NonBlockingInputStream.java:62) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 15-ea >>>>>>> /NonBlocking.java:168) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea >>>>>>> /NonBlockingReader.java:57) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 15-ea >>>>>>> /BindingReader.java:160) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea >>>>>>> /BindingReader.java:110) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea >>>>>>> /BindingReader.java:61) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 15-ea >>>>>>> /LineReaderImpl.java:913) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 15-ea >>>>>>> /LineReaderImpl.java:946) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 15-ea >>>>>>> /ConsoleIOContext.java:154) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea >>>>>>> /LineReaderImpl.java:637) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea >>>>>>> /LineReaderImpl.java:454) >>>>>>> at >>>>>>> jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 15-ea >>>>>>> /ConsoleIOContext.java:229) >>>>>>> at >>>>> jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 15-ea >>>>>>> /JShellTool.java:1254) >>>>>>> at jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 15-ea >>>>>>> /JShellTool.java:1190) >>>>>>> at >> jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 15-ea >>>>>>> /JShellTool.java:991) >>>>>>> at >>>>>>> jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 15-ea >>>>>>> /JShellToolBuilder.java:254) >>>>>>> at >>>>>>> jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 15-ea >>>>>>> /JShellToolProvider.java:120) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "Reference Handler" #2 daemon prio=10 os_prio=2 cpu=0.00ms >>>>>>> elapsed=341.79s tid=0x000001e349035ee0 nid=0x13fc waiting on >> condition >>>>>>> [0x000000340e0fe000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> at >>>>>>> java.lang.ref.Reference.waitForReferencePendingList(java.base at 15-ea >>>>> /Native >>>>>>> Method) >>>>>>> at >>>>>>> java.lang.ref.Reference.processPendingReferences(java.base at 15-ea >>>>>>> /Reference.java:241) >>>>>>> at >>>>> java.lang.ref.Reference$ReferenceHandler.run(java.base at 15-ea >>>>>>> /Reference.java:213) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=341.79s >>>>>>> tid=0x000001e349037250 nid=0x2a60 in Object.wait() >>>>> [0x000000340e1fe000] >>>>>>> java.lang.Thread.State: WAITING (on object monitor) >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>>>>>> - waiting on <0x0000000601400bc0> (a >>>>>>> java.lang.ref.ReferenceQueue$Lock) >>>>>>> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea >>>>>>> /ReferenceQueue.java:155) >>>>>>> - locked <0x0000000601400bc0> (a >>>>>>> java.lang.ref.ReferenceQueue$Lock) >>>>>>> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea >>>>>>> /ReferenceQueue.java:176) >>>>>>> at >> java.lang.ref.Finalizer$FinalizerThread.run(java.base at 15-ea >>>>>>> /Finalizer.java:170) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms >>>>> elapsed=341.78s >>>>>>> tid=0x000001e349058ae0 nid=0x35c8 runnable [0x0000000000000000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "Attach Listener" #5 daemon prio=5 os_prio=2 cpu=125.00ms >>>>> elapsed=341.78s >>>>>>> tid=0x000001e34905c5b0 nid=0x3e0c waiting on condition >>>>> [0x0000000000000000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "Service Thread" #6 daemon prio=9 os_prio=0 cpu=0.00ms >> elapsed=341.78s >>>>>>> tid=0x000001e34905f710 nid=0x398c runnable [0x0000000000000000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "C2 CompilerThread0" #7 daemon prio=9 os_prio=2 cpu=1781.25ms >>>>>>> elapsed=341.78s tid=0x000001e3490603f0 nid=0xcf0 waiting on >> condition >>>>>>> [0x0000000000000000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> No compile task >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "C1 CompilerThread0" #10 daemon prio=9 os_prio=2 cpu=765.63ms >>>>>>> elapsed=341.78s tid=0x000001e349065140 nid=0x3e54 waiting on >> condition >>>>>>> [0x0000000000000000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> No compile task >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "Sweeper thread" #11 daemon prio=9 os_prio=2 cpu=0.00ms >>>>> elapsed=341.78s >>>>>>> tid=0x000001e34906d620 nid=0x38bc runnable [0x0000000000000000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "Notification Thread" #12 daemon prio=9 os_prio=0 cpu=0.00ms >>>>>>> elapsed=341.76s tid=0x000001e349b36a20 nid=0x49b8 runnable >>>>>>> [0x0000000000000000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "Common-Cleaner" #13 daemon prio=8 os_prio=1 cpu=0.00ms >>>>> elapsed=341.75s >>>>>>> tid=0x000001e349b8c690 nid=0x26e4 in Object.wait() >>>>> [0x000000340eaff000] >>>>>>> java.lang.Thread.State: TIMED_WAITING (on object monitor) >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>>>>>> - waiting on >>>>>>> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea >>>>>>> /ReferenceQueue.java:155) >>>>>>> - locked <0x0000000601401a78> (a >>>>>>> java.lang.ref.ReferenceQueue$Lock) >>>>>>> at jdk.internal.ref.CleanerImpl.run(java.base at 15-ea >>>>>>> /CleanerImpl.java:148) >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>>>>>> at jdk.internal.misc.InnocuousThread.run(java.base at 15-ea >>>>>>> /InnocuousThread.java:134) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "JDI Internal Event Handler" #17 daemon prio=5 os_prio=0 cpu=15.63ms >>>>>>> elapsed=341.39s tid=0x000001e349da3400 nid=0x68 in Object.wait() >>>>>>> [0x000000340effe000] >>>>>>> java.lang.Thread.State: WAITING (on object monitor) >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>>>>>> - waiting on >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) >>>>>>> at >>>>> com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea >>>>>>> /EventQueueImpl.java:190) >>>>>>> - locked <0x000000060154b630> (a >>>>> com.sun.tools.jdi.EventQueueImpl) >>>>>>> at >>>>> com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 15-ea >>>>>>> /EventQueueImpl.java:125) >>>>>>> at com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 15-ea >>>>>>> /InternalEventHandler.java:61) >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "JDI Target VM Interface" #16 daemon prio=5 os_prio=0 cpu=46.88ms >>>>>>> elapsed=341.39s tid=0x000001e349daa7c0 nid=0x3d04 runnable >>>>>>> [0x000000340f0fe000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native >>>>>>> Method) >>>>>>> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea >>>>>>> /SocketDispatcher.java:46) >>>>>>> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea >>>>>>> /NioSocketImpl.java:261) >>>>>>> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea >>>>>>> /NioSocketImpl.java:312) >>>>>>> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea >>>>>>> /NioSocketImpl.java:350) >>>>>>> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea >>>>>>> /NioSocketImpl.java:803) >>>>>>> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >>>>>>> /Socket.java:981) >>>>>>> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >>>>>>> /Socket.java:976) >>>>>>> at >> com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 15-ea >>>>>>> /SocketConnection.java:82) >>>>>>> - locked <0x000000060154b998> (a java.lang.Object) >>>>>>> at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 15-ea >>>>>>> /TargetVM.java:124) >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - <0x0000000601577110> (a >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) >>>>>>> >>>>>>> "event-handler" #18 daemon prio=5 os_prio=0 cpu=0.00ms >> elapsed=341.38s >>>>>>> tid=0x000001e349dbb640 nid=0x203c in Object.wait() >>>>> [0x000000340edfe000] >>>>>>> java.lang.Thread.State: WAITING (on object monitor) >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>>>>>> - waiting on >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) >>>>>>> at >>>>> com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea >>>>>>> /EventQueueImpl.java:190) >>>>>>> - locked <0x000000060154bc28> (a >>>>> com.sun.tools.jdi.EventQueueImpl) >>>>>>> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea >>>>>>> /EventQueueImpl.java:97) >>>>>>> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea >>>>>>> /EventQueueImpl.java:83) >>>>>>> at jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 15-ea >>>>>>> /JdiEventHandler.java:79) >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "output reader" #19 daemon prio=5 os_prio=0 cpu=0.00ms >> elapsed=341.31s >>>>>>> tid=0x000001e34a141140 nid=0x49c0 runnable [0x000000340eeff000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native >>>>>>> Method) >>>>>>> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea >>>>>>> /SocketDispatcher.java:46) >>>>>>> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea >>>>>>> /NioSocketImpl.java:261) >>>>>>> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea >>>>>>> /NioSocketImpl.java:312) >>>>>>> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea >>>>>>> /NioSocketImpl.java:350) >>>>>>> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea >>>>>>> /NioSocketImpl.java:803) >>>>>>> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >>>>>>> /Socket.java:981) >>>>>>> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >>>>>>> /Socket.java:976) >>>>>>> at java.io.FilterInputStream.read(java.base at 15-ea >>>>>>> /FilterInputStream.java:82) >>>>>>> at >> jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 15-ea >>>>>>> /DemultiplexInput.java:58) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - <0x0000000601553510> (a >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) >>>>>>> >>>>>>> "Thread-0" #21 daemon prio=5 os_prio=0 cpu=312.50ms elapsed=341.22s >>>>>>> tid=0x000001e349d555c0 nid=0x4d88 waiting on condition >>>>> [0x000000340f1fe000] >>>>>>> java.lang.Thread.State: WAITING (parking) >>>>>>> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native >>>>> Method) >>>>>>> - parking to wait for <0x0000000601550fc0> (a >>>>>>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >>>>>>> at >> java.util.concurrent.locks.LockSupport.park(java.base at 15-ea >>>>>>> /LockSupport.java:341) >>>>>>> at >>>>>>> >>>>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 15-ea >>>>>>> /AbstractQueuedSynchronizer.java:505) >>>>>>> at >>>>> java.util.concurrent.ForkJoinPool.managedBlock(java.base at 15-ea >>>>>>> /ForkJoinPool.java:3137) >>>>>>> at >>>>>>> >>>>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea >>>>>>> /AbstractQueuedSynchronizer.java:1614) >>>>>>> at >>>>> java.util.concurrent.LinkedBlockingQueue.take(java.base at 15-ea >>>>>>> /LinkedBlockingQueue.java:435) >>>>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea >>>>>>> /ThreadPoolExecutor.java:1056) >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea >>>>>>> /ThreadPoolExecutor.java:1116) >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea >>>>>>> /ThreadPoolExecutor.java:630) >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "Thread-2" #23 daemon prio=5 os_prio=0 cpu=338859.38ms >> elapsed=340.58s >>>>>>> tid=0x000001e34b07f030 nid=0xac0 runnable [0x000000340f3fe000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> at >>>>>>> >>>>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea >>>>>>> /AbstractQueuedSynchronizer.java:1749) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.utils.NonBlockingPumpReader.read(jdk.internal.le at 15-ea >>>>>>> /NonBlockingPumpReader.java:77) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea >>>>>>> /NonBlockingReader.java:57) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read(jdk.internal.le at 15-ea >>>>>>> /NonBlocking.java:104) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea >>>>>>> /NonBlockingInputStream.java:36) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 15-ea >>>>>>> /StopDetectingInputStream.java:66) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$410/0x0000000800d2eb28.run(jdk.jshell at 15-ea >>>>> /Unknown >>>>>>> Source) >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - <0x00000006028b4318> (a >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) >>>>>>> >>>>>>> "WindowsStreamPump" #25 daemon prio=5 os_prio=0 cpu=0.00ms >>>>>>> elapsed=340.53s tid=0x000001e34a461c90 nid=0x3688 runnable >>>>>>> [0x000000340f4fe000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.terminal.impl.jna.win.Kernel32Impl.WaitForSingleObject(jdk.internal.le at 15-ea >>>>> /Native >>>>>>> Method) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.readConsoleInput(jdk.internal.le at 15-ea >>>>>>> /JnaWinSysTerminal.java:185) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.processConsoleInput(jdk.internal.le at 15-ea >>>>>>> /JnaWinSysTerminal.java:108) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal.pump(jdk.internal.le at 15-ea >>>>>>> /AbstractWindowsTerminal.java:465) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal$$Lambda$417/0x0000000800d310f8.run(jdk.internal.le at 15-ea >>>>> /Unknown >>>>>>> Source) >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "null non blocking reader thread" #26 daemon prio=5 os_prio=0 >>>>> cpu=0.00ms >>>>>>> elapsed=340.26s tid=0x000001e34a45fae0 nid=0x488 in Object.wait() >>>>>>> [0x000000340f6ff000] >>>>>>> java.lang.Thread.State: WAITING (on object monitor) >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>>>>>> - waiting on >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) >>>>>>> at >>>>>>> >>>>> jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 15-ea >>>>>>> /StopDetectingInputStream.java:98) >>>>>>> - locked <0x0000000601e2b650> (a >>>>>>> jdk.internal.jshell.tool.StopDetectingInputStream) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 15-ea >>>>>>> /NonBlockingInputStreamImpl.java:216) >>>>>>> at >>>>>>> >>>>> >> jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$584/0x0000000800d4f088.run(jdk.internal.le at 15-ea >>>>> /Unknown >>>>>>> Source) >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "RMI TCP Accept-0" #27 daemon prio=5 os_prio=0 cpu=0.00ms >>>>> elapsed=180.89s >>>>>>> tid=0x000001e34a45ffb0 nid=0x45f0 runnable [0x000000340d8fe000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> at sun.nio.ch.Net.accept(java.base at 15-ea/Native Method) >>>>>>> at sun.nio.ch.NioSocketImpl.accept(java.base at 15-ea >>>>>>> /NioSocketImpl.java:755) >>>>>>> at java.net.ServerSocket.implAccept(java.base at 15-ea >>>>>>> /ServerSocket.java:684) >>>>>>> at java.net.ServerSocket.platformImplAccept(java.base at 15-ea >>>>>>> /ServerSocket.java:650) >>>>>>> at java.net.ServerSocket.implAccept(java.base at 15-ea >>>>>>> /ServerSocket.java:626) >>>>>>> at java.net.ServerSocket.implAccept(java.base at 15-ea >>>>>>> /ServerSocket.java:583) >>>>>>> at java.net.ServerSocket.accept(java.base at 15-ea >>>>>>> /ServerSocket.java:540) >>>>>>> at >>>>>>> >>>>> >> sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(jdk.management.agent at 15-ea >>>>>>> /LocalRMIServerSocketFactory.java:52) >>>>>>> at >>>>>>> >>>>> >> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi at 15-ea >>>>>>> /TCPTransport.java:413) >>>>>>> at >>>>>>> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi at 15-ea >>>>>>> /TCPTransport.java:377) >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - <0x0000000602e53118> (a >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) >>>>>>> >>>>>>> "RMI TCP Connection(1)-10.0.201.131" #28 daemon prio=5 os_prio=0 >>>>>>> cpu=437.50ms elapsed=180.87s tid=0x000001e34a4617c0 nid=0x4790 >>>>> runnable >>>>>>> [0x000000340fbfe000] >>>>>>> java.lang.Thread.State: RUNNABLE >>>>>>> at sun.nio.ch.Net.poll(java.base at 15-ea/Native Method) >>>>>>> at sun.nio.ch.NioSocketImpl.park(java.base at 15-ea >>>>>>> /NioSocketImpl.java:181) >>>>>>> at sun.nio.ch.NioSocketImpl.timedRead(java.base at 15-ea >>>>>>> /NioSocketImpl.java:285) >>>>>>> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea >>>>>>> /NioSocketImpl.java:309) >>>>>>> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea >>>>>>> /NioSocketImpl.java:350) >>>>>>> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea >>>>>>> /NioSocketImpl.java:803) >>>>>>> at java.net.Socket$SocketInputStream.read(java.base at 15-ea >>>>>>> /Socket.java:981) >>>>>>> at java.io.BufferedInputStream.fill(java.base at 15-ea >>>>>>> /BufferedInputStream.java:244) >>>>>>> at java.io.BufferedInputStream.read(java.base at 15-ea >>>>>>> /BufferedInputStream.java:263) >>>>>>> - locked <0x0000000602e19470> (a >> java.io.BufferedInputStream) >>>>>>> at java.io.FilterInputStream.read(java.base at 15-ea >>>>>>> /FilterInputStream.java:82) >>>>>>> at >>>>>>> sun.rmi.transport.tcp.TCPTransport.handleMessages(java.rmi at 15-ea >>>>>>> /TCPTransport.java:569) >>>>>>> at >>>>>>> >>>>> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(java.rmi at 15-ea >>>>>>> /TCPTransport.java:828) >>>>>>> at >>>>>>> >>>>> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(java.rmi at 15-ea >>>>>>> /TCPTransport.java:705) >>>>>>> at >>>>>>> >>>>> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$686/0x0000000800da3998.run(java.rmi at 15-ea >>>>> /Unknown >>>>>>> Source) >>>>>>> at >>>>>>> java.security.AccessController.executePrivileged(java.base at 15-ea >>>>>>> /AccessController.java:753) >>>>>>> at >> java.security.AccessController.doPrivileged(java.base at 15-ea >>>>>>> /AccessController.java:391) >>>>>>> at >>>>>>> >>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(java.rmi at 15-ea >>>>>>> /TCPTransport.java:704) >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea >>>>>>> /ThreadPoolExecutor.java:1130) >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea >>>>>>> /ThreadPoolExecutor.java:630) >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - <0x0000000602e19708> (a >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker) >>>>>>> - <0x0000000602e59038> (a >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) >>>>>>> >>>>>>> "RMI Scheduler(0)" #29 daemon prio=5 os_prio=0 cpu=0.00ms >>>>> elapsed=180.86s >>>>>>> tid=0x000001e34a462160 nid=0x1df0 waiting on condition >>>>> [0x000000340fcfe000] >>>>>>> java.lang.Thread.State: TIMED_WAITING (parking) >>>>>>> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native >>>>> Method) >>>>>>> - parking to wait for <0x0000000602e1af00> (a >>>>>>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >>>>>>> at >>>>>>> java.util.concurrent.locks.LockSupport.parkNanos(java.base at 15-ea >>>>>>> /LockSupport.java:252) >>>>>>> at >>>>>>> >>>>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 15-ea >>>>>>> /AbstractQueuedSynchronizer.java:1661) >>>>>>> at >>>>>>> >>>>> >> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea >>>>>>> /ScheduledThreadPoolExecutor.java:1182) >>>>>>> at >>>>>>> >>>>> >> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea >>>>>>> /ScheduledThreadPoolExecutor.java:899) >>>>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea >>>>>>> /ThreadPoolExecutor.java:1056) >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea >>>>>>> /ThreadPoolExecutor.java:1116) >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea >>>>>>> /ThreadPoolExecutor.java:630) >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "JMX server connection timeout 30" #30 daemon prio=5 os_prio=0 >>>>> cpu=0.00ms >>>>>>> elapsed=180.86s tid=0x000001e34a45f610 nid=0x2fe8 in Object.wait() >>>>>>> [0x000000340fdff000] >>>>>>> java.lang.Thread.State: TIMED_WAITING (on object monitor) >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) >>>>>>> - waiting on >>>>>>> at >>>>>>> >>>>> >> com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(java.management at 15-ea >>>>>>> /ServerCommunicatorAdmin.java:171) >>>>>>> - locked <0x0000000602e1ca08> (a [I) >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) >>>>>>> >>>>>>> Locked ownable synchronizers: >>>>>>> - None >>>>>>> >>>>>>> "VM Thread" os_prio=2 cpu=515.63ms elapsed=341.79s >>>>> tid=0x000001e349031eb0 >>>>>>> nid=0x540 runnable >>>>>>> >>>>>>> "GC Thread#0" os_prio=2 cpu=328.13ms elapsed=341.80s >>>>>>> tid=0x000001e31c218710 nid=0x19e8 runnable >>>>>>> >>>>>>> "GC Thread#1" os_prio=2 cpu=265.63ms elapsed=341.53s >>>>>>> tid=0x000001e349b353d0 nid=0x1cc4 runnable >>>>>>> >>>>>>> "GC Thread#2" os_prio=2 cpu=218.75ms elapsed=340.37s >>>>>>> tid=0x000001e349b350a0 nid=0x1ddc runnable >>>>>>> >>>>>>> "GC Thread#3" os_prio=2 cpu=187.50ms elapsed=338.82s >>>>>>> tid=0x000001e349b35700 nid=0x4a48 runnable >>>>>>> >>>>>>> "GC Thread#4" os_prio=2 cpu=140.63ms elapsed=338.82s >>>>>>> tid=0x000001e349b340b0 nid=0x32e8 runnable >>>>>>> >>>>>>> "GC Thread#5" os_prio=2 cpu=156.25ms elapsed=338.82s >>>>>>> tid=0x000001e349b35a30 nid=0x38cc runnable >>>>>>> >>>>>>> "GC Thread#6" os_prio=2 cpu=171.88ms elapsed=338.82s >>>>>>> tid=0x000001e349b35d60 nid=0x3ed0 runnable >>>>>>> >>>>>>> "G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=341.80s >>>>>>> tid=0x000001e31c229930 nid=0x21c runnable >>>>>>> >>>>>>> "G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=341.80s >>>>> tid=0x000001e31c22a5a0 >>>>>>> nid=0x3920 runnable >>>>>>> >>>>>>> "G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=341.80s >>>>> tid=0x000001e31c253f10 >>>>>>> nid=0x1f84 runnable >>>>>>> >>>>>>> "G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms elapsed=341.80s >>>>>>> tid=0x000001e31c254b90 nid=0x27ac runnable >>>>>>> >>>>>>> "VM Periodic Task Thread" os_prio=2 cpu=15.63ms elapsed=341.76s >>>>>>> tid=0x000001e349b39710 nid=0x838 waiting on condition >>>>>>> >>>>>>> JNI global refs: 33, weak refs: 0 >>>>>>> >>>>>>> -- >>>>>>> Aaron Scott-Boddendijk >>>>>>> >>>>>>> On Tue, Jun 16, 2020 at 10:15 AM Robert Field < >>>>> robert.field at oracle.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Make that jps/jstack >>>>>>>> >>>>>>>> -R >>>>>>>> >>>>>>>> On 2020-06-15 15:12, Robert Field wrote: >>>>>>>>> Thanks for the report. >>>>>>>>> >>>>>>>>> What, if anything, is the Java stack for this thread (jps)? >>>>>>>>> >>>>>>>>> -Robert >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2020-06-15 14:41, Aaron Scott-Boddendijk wrote: >>>>>>>>>> System: >>>>>>>>>> * Windows 10 >>>>>>>>>> * Powershell >>>>>>>>>> >>>>>>>>>> When I start JShell, without executing anything, a CPU core is >>>>> always >>>>>>>> at >>>>>>>>>> 100% (a single thread though I haven't identified what it's >>>>> doing). >>>>>>>>>> >>>>>>>>>> The thread stack is as follows (with only the last two items >>>>> sometimes >>>>>>>>>> change - but I don't know the internals of the JVM to know if >> this >>>>>>>>>> useful >>>>>>>>>> or significant): >>>>>>>>>> >>>>>>>>>> ntoskrnl.exe!KeSynchronizeExecution+0x5b46 >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x1c2d >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0xab4 >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x255 >>>>>>>>>> ntoskrnl.exe!RtlClearBitsEx+0x15a7 >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x3828 >>>>>>>>>> ntoskrnl.exe!KeSynchronizeExecution+0x3120 >>>>>>>>>> jvm.dll!c2v_notifyCompilerInliningEvent+0x201797 >>>>>>>>>> >>>>>>>>>> The JDK 14 version of JShell does not have this issue but >> several >>>>> of >>>>>>>> the >>>>>>>>>> recent JDK 15 builds have done this. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Aaron Scott-Boddendijk >>>>>>>> >>>>>>> >>>>> >>>> >> From robert.field at oracle.com Tue Jul 14 22:57:15 2020 From: robert.field at oracle.com (Robert Field) Date: Tue, 14 Jul 2020 15:57:15 -0700 Subject: =?UTF-8?Q?Re=3a_Records_are_called_=e2=80=9emethods=e2=80=9c_in_JSh?= =?UTF-8?Q?ell?= In-Reply-To: <20200714114712.b6ff8ab09a6c540215cae158a90d7e03.33bea43126.wbe@email17.godaddy.com> References: <20200714114712.b6ff8ab09a6c540215cae158a90d7e03.33bea43126.wbe@email17.godaddy.com> Message-ID: <567b5f7d-5f3b-4e61-2593-8755dc8edc28@oracle.com> I'm guessing you may be using an older JDK.? I get: jshell> public record ConstExpr(Expr e) implements Expr{} |? created record ConstExpr jshell> /drop ConstExpr |? dropped record ConstExpr Can you do: jshell --full-version Thanks, Robert On 2020-07-14 11:47, Lingo Coder wrote: > Thanks Jan, > >> ?...the problem can be seen by running a few commands in JShell.? > While I was awaiting your reply, I went ahead and did a script that > contains exactly what I typed in the most recent screen recording [1]. > > TIL ? but you will already know ? that running .jsh scripts don't > produce the output typically seen in the REPL's interactive mode. > > So to repeat what I did in the recordings, you'll need to manually > copy & paste the code into JShell interactively. > > Please correct me if I'm wrong, Jan. But am I correct in assuming > that the JDK shouldn't behave differently on Windows 7 vs 10? > > TIA. > > ---- > [1] https://bit.ly/jshRecMeth > > -------- Original Message -------- > Subject: Re:_Records_are_called_?methods?_in_JSh ell > From: Jan Lahoda > Date: Tue, July 14, 2020 11:11 am > To: Lingo Coder , kulla-dev > > Cc: Jorn Vernee > > On 14. 07. 20 18:58, Lingo Coder wrote: >> Hi, >> >> Thanks for looking into this, Jan. >> >>> ?...Would you have a small reproducible test case?...? >> Sure. In what form would you prefer that? A .jsh or something? > I am hoping the problem can be seen by running a few commands in JShell > - if you could just write them here, that'd be enough. (I tried several > commands based on the animations, but didn't succeed, so I am probably > missing some detail somewhere.) > > Thanks, > Jan > >> For what it's worth, I'm on Windows 7 Professional 64 bit. I >> mention that for completeness. It would be surprising to learn >> that the JDK behaved differently on 7 than it does on 10. >> Would you agree? >> >> TIA. >> >> -------- Original Message -------- >> Subject: Re:_Records_are_called_?methods?_in_JSh ell >> From: Jan Lahoda >> Date: Tue, July 14, 2020 9:36 am >> To: Lingo Coder , kulla-dev >> >> Cc: Jorn Vernee >> >> Hi, >> >> Would you have a small reproducible test case? I don't seem to be able >> to reproduce either. >> >> Thanks, >> Jan >> >> On 14. 07. 20 18:15, Lingo Coder wrote: >>> Hi, >>> >>> Thanks for looking into this, Jorn. >>> >>>> ?...Are you sure that you are using the right jshell executable, and >>> it's not picking up another one that's on the PATH as well?..? >>> >>> I'm sure :) >>> >>> I checked, rechecked and then, finally, rechecked that I rechecked. >>> >>> How I (re)checked: >>> >>> 1. I cleared the value of $PATH in the terminal where I run JShell >>> 2. I then set the value of $PATH to be the file system location of the >>> one and only installation of OpenJDK 15-ea (build 15-ea+31-1502) >>> 3. I checked that the value of $PATH had only the one single entry >>> 4. Does java -version report build 15-ea+31-1502? Confirmed! >>> 5. I launched JShell >>> 6. Created a record named ?JShellChecker?; >>> 7. Observed JShell reports: ?created *method* JShellChecker? >>> 8. Edited the record to implement a JShell .exe location check >>> 9. JShell reports: ?replaced *method* JShellChecker? >>> >>> Observe [1] to check that it is really happening as I describe. >>> >>> TIA. >>> >>> ---- >>> [1] https://imgur.com/NYBdYhn >>> >>> >>> >>> >>> -------- Original Message -------- >>> Subject: Re:_Records_are_called_?methods?_in_JSh ell >>> From: Jorn Vernee >>> Date: Tue, July 14, 2020 3:01 am >>> To: Lingo Coder >>> Cc: kulla-dev >>> >>> Hi, >>> >>> I was not able to reproduce this with JDK 15 build 31 (the same version >>> that you are using). >>> >>> PS C:\Program Files\Java\jdk-15-b31\bin> ./jshell.exe --enable-preview >>> | Welcome to JShell -- Version 15-ea >>> | For an introduction type: /help intro >>> >>> jshell> public record Point(int x, int y) {} >>> | created record Point >>> >>> jshell> /drop Point >>> | dropped record Point >>> >>> Are you sure that you are using the right jshell executable, and it's >>> not picking up another one that's on the PATH as well? >>> >>> Jorn >>> >>> On 14/07/2020 00:04, Michel Trudeau wrote: >>>> [Moving this to kulla-dev] >>>> >>>> On Jul 12, 2020, at 4:35 PM, Lingo Coder wrote: >>>> >>>> java -version >>>> openjdk version "15-ea" 2020-09-15 >>>> OpenJDK Runtime Environment (build 15-ea+31-1502) >>>> OpenJDK 64-Bit Server VM (build 15-ea+31-1502, mixed mode, sharing) >>>> >>>> OS: Windows amd64 >>>> >>>> Steps to reproduce >>>> >>>> 1. Create some records... >>>> >>>> jshell>public record ConstExpr(Expr e) implements Expr{} >>>> >>>> jshell>public record PlusExpr(Expr a, Expr b) implements Expr{} >>>> >>>> jshell>public record TimesExpr(Expr x, Expr y) implements Expr{} >>>> >>>> jshell>public record NegExpr(Expr n) implements Expr{} >>>> >>>> >>>> 2. Observe that JShell calls the records you just created, >>>> ?methods?... >>>> >>>> jshell> ... >>>> | created method ConstExpr() ... >>>> | created method PlusExpr() ... >>>> | created method TimesExpr() ... >>>> | created method NegExpr() ... >>>> >>>> 3. Delete those records. JShell says they're ?methods?... >>>> >>>> jshell> /drop ConstExpr >>>> | dropped method ConstExpr() >>>> >>>> jshell> /drop PlusExpr >>>> | dropped method PlusExpr() >>>> >>>> jshell> /drop TimesExpr >>>> | dropped method TimesExpr() >>>> >>>> jshell> /drop NegExpr >>>> | dropped method NegExpr() >>>> >>>> Same deal with /edit. I did a screen recording if it's any help. [1] >>>> >>>> I couldn't reproduce this in Linux with the same JDK release/build. It >>>> only happens on Windows. >>>> >>>> ---- >>>> >>>> [1] https://i.imgur.com/ee8sJMf.gif >>>> >>>> From plugins at lingocoder.com Wed Jul 15 01:35:35 2020 From: plugins at lingocoder.com (Lingo Coder) Date: Tue, 14 Jul 2020 18:35:35 -0700 Subject: Records are called =?UTF-8?Q?=E2=80=9Emethods=E2=80=9C=20in=20JShell?= Message-ID: <20200714183535.b6ff8ab09a6c540215cae158a90d7e03.5a71985bc7.wbe@email17.godaddy.com> Thanks Robert, > ?...Can you do: > jshell --full-version...? I did that. It says jshell 15-ea+31-1502 [1] What version of Windows are you other guys trying this in? I'm on Windows 7. > ?...I'm guessing you may be using an older JDK...? As I show in [1] and in earlier screen recordings, I completely clear my $PATH to confirm that there is no other jshell.exe on the $PATH. I have not installed any JDKs with an installer or anything like that. For that reason, I rule out anything registry-related. I do have an early access release of 14-Valhalla build 14-valhalla+4-55 on my workstation. But, that was installed by simply unzipping the archive into a jdk-14.L.world.Build.14-valhalla+4-55 folder. More importantly, that build doesn't even have the records nor the sealed types features. I also have GA releases of OpenJDK 12 & 13 in their own folders. But again, not only are they isolated well out of the way of the $PATH I run jshell 15 in, they don't even have records and sealed types functionality. If _any_ other JDK were somehow in the $PATH, it would be surprising if records and sealed types even worked _at all_; let alone the misnaming as ?methods? issue Right? Please correct me if I'm wrong? [1] https://imgur.com/cMsAl5f -------- Original Message -------- Subject: Re:_Records_are_called_?methods?_in_JSh ell From: Robert Field Date: Tue, July 14, 2020 3:57 pm To: kulla-dev at openjdk.java.net, jorn.vernee at oracle.com, plugins at lingocoder.com I'm guessing you may be using an older JDK. I get: jshell> public record ConstExpr(Expr e) implements Expr{} | created record ConstExpr jshell> /drop ConstExpr | dropped record ConstExpr Can you do: jshell --full-version Thanks, Robert From robert.field at oracle.com Wed Jul 15 03:07:23 2020 From: robert.field at oracle.com (Robert Field) Date: Tue, 14 Jul 2020 20:07:23 -0700 Subject: =?UTF-8?Q?Re=3a_Records_are_called_=e2=80=9emethods=e2=80=9c_in_JSh?= =?UTF-8?Q?ell?= In-Reply-To: <20200714183535.b6ff8ab09a6c540215cae158a90d7e03.5a71985bc7.wbe@email17.godaddy.com> References: <20200714183535.b6ff8ab09a6c540215cae158a90d7e03.5a71985bc7.wbe@email17.godaddy.com> Message-ID: <921d011c-ccb1-88b7-6a66-cc3f0def5317@oracle.com> I have a theory, maybe the following can illuminate... Couple more things to try: ?? /set feedback ?? /set format normal typeKind And send us what it prints. Also, after you have entered: ?? public record ConstExpr(Expr e) implements Expr{} Type: ?? /type and ?? /method Separately, what do they print? Oh, and if you want to try one more thing: ?? /set feedback verbose ?? public record ConstExpr(Expr e) implements Expr{} Sorry, I don't have Windows, but I believe Jan has access. -Robert On 2020-07-14 18:35, Lingo Coder wrote: > Thanks Robert, > >> ?...Can you do: >> jshell --full-version...? > > I did that. It says jshell 15-ea+31-1502 [1] > > What version of Windows are you other guys trying this in? I'm on > Windows 7. > >> ?...I'm guessing you may be using an older JDK...? > As I show in [1] and in earlier screen recordings, I completely > clear my $PATH to confirm that there is no other jshell.exe on > the $PATH. > > I have not installed any JDKs with an installer or anything > like that. For that reason, I rule out anything registry-related. > > I do have an early access release of 14-Valhalla > build 14-valhalla+4-55 on my workstation. But, that was > installed by simply unzipping the archive into a > jdk-14.L.world.Build.14-valhalla+4-55 folder. More importantly, > that build doesn't even have the records nor the sealed types > features. > > I also have GA releases of OpenJDK 12 & 13 in their own folders. > But again, not only are they isolated well out of the way of > the $PATH I run jshell 15 in, they don't even have records and > sealed types functionality. > > If _any_ other JDK were somehow in the $PATH, it would be > surprising if records and sealed types even worked _at all_; > let alone the misnaming as ?methods? issue Right? Please > correct me if I'm wrong? > > > [1] https://imgur.com/cMsAl5f > > -------- Original Message -------- > Subject: Re:_Records_are_called_?methods?_in_JSh ell > From: Robert Field > Date: Tue, July 14, 2020 3:57 pm > To: kulla-dev at openjdk.java.net, jorn.vernee at oracle.com, > plugins at lingocoder.com > > I'm guessing you may be using an older JDK. I get: > jshell> public record ConstExpr(Expr e) implements Expr{} > | created record ConstExpr > > jshell> /drop ConstExpr > | dropped record ConstExpr > > > Can you do: > jshell --full-version > > Thanks, > Robert > > > From sormuras at gmail.com Wed Jul 15 07:15:49 2020 From: sormuras at gmail.com (Christian Stein) Date: Wed, 15 Jul 2020 09:15:49 +0200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> Message-ID: JShell 16-ea is affected, too. Hoping that the fix is as simple as you think, Jan. Perhaps, it can make its way into JShell 15 before GA. Cheers, Christian On Tue, Jul 14, 2020 at 9:05 PM Jan Lahoda wrote: > Hi, > > Thanks for the report and analysis. I've filled: > https://bugs.openjdk.java.net/browse/JDK-8249367 > > I think the issue is in: > > http://hg.openjdk.java.net/jdk/jdk/file/1e249ca8d585/src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlocking.java#l104 > > If the timeout is zero (which it is when invoked from > StopDetectingInputStream, as it calls the read method without timeout), > the method invocation will exit immediately, and it will be immediately > called again, etc. > > Jan > > On 13. 07. 20 6:00, Aaron Scott-Boddendijk wrote: > > I can confirm the CPU behaves as suggested with a sequence of entering > and > > leaving `/edit`. > > > > Thanks Christian. > > > > -- > > Aaron Scott-Boddendijk > > > > On Mon, Jul 13, 2020 at 3:27 PM Christian Stein > wrote: > > > >> It's coming from the "while(true)"-loop in StopDetectingInputStream.java > >> [0]. > >> > >> Aaron, try to open an external editor within the JShell session via > >> > >> /edit > >> > >> The CPU usage should drop immediately to normal levels. > >> As soon as you close the editor (it's the internal JShell Edit Pad for > me) > >> the thread is again eating CPU cycles. Can you confirm this? > >> > >> While the editor is opened, the thread waits via > >> > >> jdk.internal.jshell.tool.StopDetectingInputStream.waitInputNeeded > line: > >> 164 > >> > >> If no editor is open, the "input.read()" method does never wait: > >> > >> > >> > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > >> line: 66 > >> > >> Cheers, > >> Christian > >> > >> [0]: > >> > >> > https://github.com/openjdk/jdk/blob/faf4d7ccb792b16092c791c0ac77acdd440dbca1/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java#L57-L74 > >> > >> On Mon, Jul 13, 2020 at 5:05 AM Christian Stein > >> wrote: > >> > >>> Seems like "read line" from "jline" is underlying reason: > >>> > >>> Thread-2 [31] (RUNNABLE) > >>> > >>> > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await > >>> line: 1749 > >>> jdk.internal.org.jline.utils.NonBlockingPumpReader.read line: 77 > >>> jdk.internal.org.jline.utils.NonBlockingReader.read line: 57 > >>> > >>> > >> > jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read > >>> line: 104 > >>> jdk.internal.org.jline.utils.NonBlockingInputStream.read line: 36 > >>> > >>> > >> > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > >>> line: 66 > >>> > >>> > >> > jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$347/0x0000000800cff330.run > >>> line: not available > >>> java.lang.Thread.run line: 832 > >>> > >>> It produces a constant high CPU usage and allocates a lot of RAM per > >>> second. > >>> > >>> Thread Name Thread State Blocked Count Total CPU Usage Deadlocked > >>> Allocated Memory > >>> Thread-2 RUNNABLE 1 0.06252084028009336 Not Enabled 196198305136 B > >>> > >>> > >>> > >>> > >>> > >>> On Mon, Jul 13, 2020 at 4:52 AM Christian Stein > >>> wrote: > >>> > >>>> Hi Aaron, > >>>> > >>>> I observe the same behaviour of JShell 15 build 30. > >>>> > >>>> Here, the 100% CPU workload is split on to 3-4 logical processors. > >>>> Grabbed an animated GIF of "jshell.exe -- /exit" session at [0]. > >>>> To me, it looks like a loop is running wild, w/o a > >>>> Thread.yield()/.sleep() call. > >>>> > >>>> Microsoft Windows [Version 10.0.19041.329] > >>>> > >>>> openjdk 15-ea 2020-09-15 > >>>> OpenJDK Runtime Environment (build 15-ea+30-1476) > >>>> OpenJDK 64-Bit Server VM (build 15-ea+30-1476, mixed mode, sharing) > >>>> > >>>> Cheers, > >>>> Christian > >>>> > >>>> [0]: > >>>> > >> > https://drive.google.com/file/d/1KOQO5B9WrM4C43K3AB7H9VVPuh9hdCOe/view?usp=sharing > >>>> > >>>> > >>>> On Mon, Jul 13, 2020 at 4:24 AM Aaron Scott-Boddendijk < > >> talden at gmail.com> > >>>> wrote: > >>>> > >>>>> This still exists in JDK 15 build 31. > >>>>> > >>>>> Is any other Windows user able to reproduce this? I have two > machines, > >>>>> one > >>>>> laptop and one desktop that show a CPU thread constantly @ 100% just > by > >>>>> starting JShell. For the desktop machine that's not a major issue but > >> for > >>>>> the laptop this spins up the fans and eats the battery. > >>>>> > >>>>> JShell in JDK 14 is fine. > >>>>> > >>>>> I've yet to hear of any other user confirming this issue. > >>>>> > >>>>> -- > >>>>> Aaron Scott-Boddendijk > >>>>> > >>>>> > >>>>> On Fri, Jun 26, 2020 at 2:00 PM Aaron Scott-Boddendijk < > >> talden at gmail.com > >>>>>> > >>>>> wrote: > >>>>> > >>>>>> Just confirming that: > >>>>>> > >>>>>> * This still exists in JDK 15 build 29 > >>>>>> * Occurs on multiple unrelated Windows 10 machines with differing > >> major > >>>>>> versions of the OS. > >>>>>> * Does not occur in JDK 14.01 on these machines (OpenJDK 64-Bit > >> Server > >>>>> VM > >>>>>> Zulu14.28+21-CA) > >>>>>> * Does not appear to occur on Linux > >>>>>> > >>>>>> -- > >>>>>> Aaron Scott-Boddendijk > >>>>>> > >>>>>> > >>>>>> On Tue, Jun 16, 2020 at 11:16 AM Aaron Scott-Boddendijk < > >>>>> talden at gmail.com> > >>>>>> wrote: > >>>>>> > >>>>>>> This is the thread-dump from the JVM that VisualVM sees as using a > >>>>> core... > >>>>>>> > >>>>>>> 2020-06-16 11:07:35 > >>>>>>> Full thread dump OpenJDK 64-Bit Server VM (15-ea+27-1372 mixed > mode, > >>>>>>> sharing): > >>>>>>> > >>>>>>> Threads class SMR info: > >>>>>>> _java_thread_list=0x000001e34a6040f0, length=23, elements={ > >>>>>>> 0x000001e31c1a1dc0, 0x000001e349035ee0, 0x000001e349037250, > >>>>>>> 0x000001e349058ae0, > >>>>>>> 0x000001e34905c5b0, 0x000001e34905f710, 0x000001e3490603f0, > >>>>>>> 0x000001e349065140, > >>>>>>> 0x000001e34906d620, 0x000001e349b36a20, 0x000001e349b8c690, > >>>>>>> 0x000001e349da3400, > >>>>>>> 0x000001e349daa7c0, 0x000001e349dbb640, 0x000001e34a141140, > >>>>>>> 0x000001e349d555c0, > >>>>>>> 0x000001e34b07f030, 0x000001e34a461c90, 0x000001e34a45fae0, > >>>>>>> 0x000001e34a45ffb0, > >>>>>>> 0x000001e34a4617c0, 0x000001e34a462160, 0x000001e34a45f610 > >>>>>>> } > >>>>>>> > >>>>>>> "main" #1 prio=5 os_prio=0 cpu=1078.13ms elapsed=341.81s > >>>>>>> tid=0x000001e31c1a1dc0 nid=0x16b0 in Object.wait() > >>>>> [0x000000340d9fe000] > >>>>>>> java.lang.Thread.State: TIMED_WAITING (on object monitor) > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>>>>>> - waiting on > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingInputStreamImpl.java:139) > >>>>>>> - locked <0x000000060fe87338> (a > >>>>>>> jdk.internal.jshell.tool.ConsoleIOContext$1) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingInputStream.java:62) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlocking.java:168) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingReader.java:57) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 15-ea > >>>>>>> /BindingReader.java:160) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > >>>>>>> /BindingReader.java:110) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > >>>>>>> /BindingReader.java:61) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 15-ea > >>>>>>> /LineReaderImpl.java:913) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 15-ea > >>>>>>> /LineReaderImpl.java:946) > >>>>>>> at > >>>>>>> > >>>>> > >> jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 15-ea > >>>>>>> /ConsoleIOContext.java:154) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > >>>>>>> /LineReaderImpl.java:637) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > >>>>>>> /LineReaderImpl.java:454) > >>>>>>> at > >>>>>>> jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 15-ea > >>>>>>> /ConsoleIOContext.java:229) > >>>>>>> at > >>>>> jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 15-ea > >>>>>>> /JShellTool.java:1254) > >>>>>>> at > jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 15-ea > >>>>>>> /JShellTool.java:1190) > >>>>>>> at > >> jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 15-ea > >>>>>>> /JShellTool.java:991) > >>>>>>> at > >>>>>>> jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 15-ea > >>>>>>> /JShellToolBuilder.java:254) > >>>>>>> at > >>>>>>> jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 15-ea > >>>>>>> /JShellToolProvider.java:120) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "Reference Handler" #2 daemon prio=10 os_prio=2 cpu=0.00ms > >>>>>>> elapsed=341.79s tid=0x000001e349035ee0 nid=0x13fc waiting on > >> condition > >>>>>>> [0x000000340e0fe000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> at > >>>>>>> java.lang.ref.Reference.waitForReferencePendingList(java.base at 15-ea > >>>>> /Native > >>>>>>> Method) > >>>>>>> at > >>>>>>> java.lang.ref.Reference.processPendingReferences(java.base at 15-ea > >>>>>>> /Reference.java:241) > >>>>>>> at > >>>>> java.lang.ref.Reference$ReferenceHandler.run(java.base at 15-ea > >>>>>>> /Reference.java:213) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=341.79s > >>>>>>> tid=0x000001e349037250 nid=0x2a60 in Object.wait() > >>>>> [0x000000340e1fe000] > >>>>>>> java.lang.Thread.State: WAITING (on object monitor) > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>>>>>> - waiting on <0x0000000601400bc0> (a > >>>>>>> java.lang.ref.ReferenceQueue$Lock) > >>>>>>> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >>>>>>> /ReferenceQueue.java:155) > >>>>>>> - locked <0x0000000601400bc0> (a > >>>>>>> java.lang.ref.ReferenceQueue$Lock) > >>>>>>> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >>>>>>> /ReferenceQueue.java:176) > >>>>>>> at > >> java.lang.ref.Finalizer$FinalizerThread.run(java.base at 15-ea > >>>>>>> /Finalizer.java:170) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms > >>>>> elapsed=341.78s > >>>>>>> tid=0x000001e349058ae0 nid=0x35c8 runnable [0x0000000000000000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "Attach Listener" #5 daemon prio=5 os_prio=2 cpu=125.00ms > >>>>> elapsed=341.78s > >>>>>>> tid=0x000001e34905c5b0 nid=0x3e0c waiting on condition > >>>>> [0x0000000000000000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "Service Thread" #6 daemon prio=9 os_prio=0 cpu=0.00ms > >> elapsed=341.78s > >>>>>>> tid=0x000001e34905f710 nid=0x398c runnable [0x0000000000000000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "C2 CompilerThread0" #7 daemon prio=9 os_prio=2 cpu=1781.25ms > >>>>>>> elapsed=341.78s tid=0x000001e3490603f0 nid=0xcf0 waiting on > >> condition > >>>>>>> [0x0000000000000000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> No compile task > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "C1 CompilerThread0" #10 daemon prio=9 os_prio=2 cpu=765.63ms > >>>>>>> elapsed=341.78s tid=0x000001e349065140 nid=0x3e54 waiting on > >> condition > >>>>>>> [0x0000000000000000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> No compile task > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "Sweeper thread" #11 daemon prio=9 os_prio=2 cpu=0.00ms > >>>>> elapsed=341.78s > >>>>>>> tid=0x000001e34906d620 nid=0x38bc runnable [0x0000000000000000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "Notification Thread" #12 daemon prio=9 os_prio=0 cpu=0.00ms > >>>>>>> elapsed=341.76s tid=0x000001e349b36a20 nid=0x49b8 runnable > >>>>>>> [0x0000000000000000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "Common-Cleaner" #13 daemon prio=8 os_prio=1 cpu=0.00ms > >>>>> elapsed=341.75s > >>>>>>> tid=0x000001e349b8c690 nid=0x26e4 in Object.wait() > >>>>> [0x000000340eaff000] > >>>>>>> java.lang.Thread.State: TIMED_WAITING (on object monitor) > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>>>>>> - waiting on > >>>>>>> at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >>>>>>> /ReferenceQueue.java:155) > >>>>>>> - locked <0x0000000601401a78> (a > >>>>>>> java.lang.ref.ReferenceQueue$Lock) > >>>>>>> at jdk.internal.ref.CleanerImpl.run(java.base at 15-ea > >>>>>>> /CleanerImpl.java:148) > >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> at jdk.internal.misc.InnocuousThread.run(java.base at 15-ea > >>>>>>> /InnocuousThread.java:134) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "JDI Internal Event Handler" #17 daemon prio=5 os_prio=0 > cpu=15.63ms > >>>>>>> elapsed=341.39s tid=0x000001e349da3400 nid=0x68 in Object.wait() > >>>>>>> [0x000000340effe000] > >>>>>>> java.lang.Thread.State: WAITING (on object monitor) > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>>>>>> - waiting on > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >>>>>>> at > >>>>> com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > >>>>>>> /EventQueueImpl.java:190) > >>>>>>> - locked <0x000000060154b630> (a > >>>>> com.sun.tools.jdi.EventQueueImpl) > >>>>>>> at > >>>>> com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 15-ea > >>>>>>> /EventQueueImpl.java:125) > >>>>>>> at > com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 15-ea > >>>>>>> /InternalEventHandler.java:61) > >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "JDI Target VM Interface" #16 daemon prio=5 os_prio=0 cpu=46.88ms > >>>>>>> elapsed=341.39s tid=0x000001e349daa7c0 nid=0x3d04 runnable > >>>>>>> [0x000000340f0fe000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea > /Native > >>>>>>> Method) > >>>>>>> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > >>>>>>> /SocketDispatcher.java:46) > >>>>>>> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:261) > >>>>>>> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:312) > >>>>>>> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:350) > >>>>>>> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:803) > >>>>>>> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>>>>>> /Socket.java:981) > >>>>>>> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>>>>>> /Socket.java:976) > >>>>>>> at > >> com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 15-ea > >>>>>>> /SocketConnection.java:82) > >>>>>>> - locked <0x000000060154b998> (a java.lang.Object) > >>>>>>> at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 15-ea > >>>>>>> /TargetVM.java:124) > >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - <0x0000000601577110> (a > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>>>>>> > >>>>>>> "event-handler" #18 daemon prio=5 os_prio=0 cpu=0.00ms > >> elapsed=341.38s > >>>>>>> tid=0x000001e349dbb640 nid=0x203c in Object.wait() > >>>>> [0x000000340edfe000] > >>>>>>> java.lang.Thread.State: WAITING (on object monitor) > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>>>>>> - waiting on > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >>>>>>> at > >>>>> com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > >>>>>>> /EventQueueImpl.java:190) > >>>>>>> - locked <0x000000060154bc28> (a > >>>>> com.sun.tools.jdi.EventQueueImpl) > >>>>>>> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > >>>>>>> /EventQueueImpl.java:97) > >>>>>>> at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > >>>>>>> /EventQueueImpl.java:83) > >>>>>>> at > jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 15-ea > >>>>>>> /JdiEventHandler.java:79) > >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "output reader" #19 daemon prio=5 os_prio=0 cpu=0.00ms > >> elapsed=341.31s > >>>>>>> tid=0x000001e34a141140 nid=0x49c0 runnable [0x000000340eeff000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> at sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea > /Native > >>>>>>> Method) > >>>>>>> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > >>>>>>> /SocketDispatcher.java:46) > >>>>>>> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:261) > >>>>>>> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:312) > >>>>>>> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:350) > >>>>>>> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:803) > >>>>>>> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>>>>>> /Socket.java:981) > >>>>>>> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>>>>>> /Socket.java:976) > >>>>>>> at java.io.FilterInputStream.read(java.base at 15-ea > >>>>>>> /FilterInputStream.java:82) > >>>>>>> at > >> jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 15-ea > >>>>>>> /DemultiplexInput.java:58) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - <0x0000000601553510> (a > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>>>>>> > >>>>>>> "Thread-0" #21 daemon prio=5 os_prio=0 cpu=312.50ms elapsed=341.22s > >>>>>>> tid=0x000001e349d555c0 nid=0x4d88 waiting on condition > >>>>> [0x000000340f1fe000] > >>>>>>> java.lang.Thread.State: WAITING (parking) > >>>>>>> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native > >>>>> Method) > >>>>>>> - parking to wait for <0x0000000601550fc0> (a > >>>>>>> > >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > >>>>>>> at > >> java.util.concurrent.locks.LockSupport.park(java.base at 15-ea > >>>>>>> /LockSupport.java:341) > >>>>>>> at > >>>>>>> > >>>>> > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 15-ea > >>>>>>> /AbstractQueuedSynchronizer.java:505) > >>>>>>> at > >>>>> java.util.concurrent.ForkJoinPool.managedBlock(java.base at 15-ea > >>>>>>> /ForkJoinPool.java:3137) > >>>>>>> at > >>>>>>> > >>>>> > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > >>>>>>> /AbstractQueuedSynchronizer.java:1614) > >>>>>>> at > >>>>> java.util.concurrent.LinkedBlockingQueue.take(java.base at 15-ea > >>>>>>> /LinkedBlockingQueue.java:435) > >>>>>>> at > >>>>> java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:1056) > >>>>>>> at > >>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:1116) > >>>>>>> at > >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:630) > >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "Thread-2" #23 daemon prio=5 os_prio=0 cpu=338859.38ms > >> elapsed=340.58s > >>>>>>> tid=0x000001e34b07f030 nid=0xac0 runnable [0x000000340f3fe000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> at > >>>>>>> > >>>>> > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > >>>>>>> /AbstractQueuedSynchronizer.java:1749) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingPumpReader.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingPumpReader.java:77) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingReader.java:57) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlocking.java:104) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingInputStream.java:36) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 15-ea > >>>>>>> /StopDetectingInputStream.java:66) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$410/0x0000000800d2eb28.run(jdk.jshell at 15-ea > >>>>> /Unknown > >>>>>>> Source) > >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - <0x00000006028b4318> (a > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>>>>>> > >>>>>>> "WindowsStreamPump" #25 daemon prio=5 os_prio=0 cpu=0.00ms > >>>>>>> elapsed=340.53s tid=0x000001e34a461c90 nid=0x3688 runnable > >>>>>>> [0x000000340f4fe000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.terminal.impl.jna.win.Kernel32Impl.WaitForSingleObject(jdk.internal.le at 15-ea > >>>>> /Native > >>>>>>> Method) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.readConsoleInput(jdk.internal.le at 15-ea > >>>>>>> /JnaWinSysTerminal.java:185) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.processConsoleInput(jdk.internal.le at 15-ea > >>>>>>> /JnaWinSysTerminal.java:108) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal.pump(jdk.internal.le at 15-ea > >>>>>>> /AbstractWindowsTerminal.java:465) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal$$Lambda$417/0x0000000800d310f8.run(jdk.internal.le at 15-ea > >>>>> /Unknown > >>>>>>> Source) > >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "null non blocking reader thread" #26 daemon prio=5 os_prio=0 > >>>>> cpu=0.00ms > >>>>>>> elapsed=340.26s tid=0x000001e34a45fae0 nid=0x488 in Object.wait() > >>>>>>> [0x000000340f6ff000] > >>>>>>> java.lang.Thread.State: WAITING (on object monitor) > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>>>>>> - waiting on > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >>>>>>> at > >>>>>>> > >>>>> > jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 15-ea > >>>>>>> /StopDetectingInputStream.java:98) > >>>>>>> - locked <0x0000000601e2b650> (a > >>>>>>> jdk.internal.jshell.tool.StopDetectingInputStream) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingInputStreamImpl.java:216) > >>>>>>> at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$584/0x0000000800d4f088.run(jdk.internal.le at 15-ea > >>>>> /Unknown > >>>>>>> Source) > >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "RMI TCP Accept-0" #27 daemon prio=5 os_prio=0 cpu=0.00ms > >>>>> elapsed=180.89s > >>>>>>> tid=0x000001e34a45ffb0 nid=0x45f0 runnable [0x000000340d8fe000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> at sun.nio.ch.Net.accept(java.base at 15-ea/Native Method) > >>>>>>> at sun.nio.ch.NioSocketImpl.accept(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:755) > >>>>>>> at java.net.ServerSocket.implAccept(java.base at 15-ea > >>>>>>> /ServerSocket.java:684) > >>>>>>> at > java.net.ServerSocket.platformImplAccept(java.base at 15-ea > >>>>>>> /ServerSocket.java:650) > >>>>>>> at java.net.ServerSocket.implAccept(java.base at 15-ea > >>>>>>> /ServerSocket.java:626) > >>>>>>> at java.net.ServerSocket.implAccept(java.base at 15-ea > >>>>>>> /ServerSocket.java:583) > >>>>>>> at java.net.ServerSocket.accept(java.base at 15-ea > >>>>>>> /ServerSocket.java:540) > >>>>>>> at > >>>>>>> > >>>>> > >> > sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(jdk.management.agent at 15-ea > >>>>>>> /LocalRMIServerSocketFactory.java:52) > >>>>>>> at > >>>>>>> > >>>>> > >> > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi at 15-ea > >>>>>>> /TCPTransport.java:413) > >>>>>>> at > >>>>>>> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi at 15-ea > >>>>>>> /TCPTransport.java:377) > >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - <0x0000000602e53118> (a > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>>>>>> > >>>>>>> "RMI TCP Connection(1)-10.0.201.131" #28 daemon prio=5 os_prio=0 > >>>>>>> cpu=437.50ms elapsed=180.87s tid=0x000001e34a4617c0 nid=0x4790 > >>>>> runnable > >>>>>>> [0x000000340fbfe000] > >>>>>>> java.lang.Thread.State: RUNNABLE > >>>>>>> at sun.nio.ch.Net.poll(java.base at 15-ea/Native Method) > >>>>>>> at sun.nio.ch.NioSocketImpl.park(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:181) > >>>>>>> at sun.nio.ch.NioSocketImpl.timedRead(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:285) > >>>>>>> at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:309) > >>>>>>> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:350) > >>>>>>> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:803) > >>>>>>> at java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>>>>>> /Socket.java:981) > >>>>>>> at java.io.BufferedInputStream.fill(java.base at 15-ea > >>>>>>> /BufferedInputStream.java:244) > >>>>>>> at java.io.BufferedInputStream.read(java.base at 15-ea > >>>>>>> /BufferedInputStream.java:263) > >>>>>>> - locked <0x0000000602e19470> (a > >> java.io.BufferedInputStream) > >>>>>>> at java.io.FilterInputStream.read(java.base at 15-ea > >>>>>>> /FilterInputStream.java:82) > >>>>>>> at > >>>>>>> sun.rmi.transport.tcp.TCPTransport.handleMessages(java.rmi at 15-ea > >>>>>>> /TCPTransport.java:569) > >>>>>>> at > >>>>>>> > >>>>> > >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(java.rmi at 15-ea > >>>>>>> /TCPTransport.java:828) > >>>>>>> at > >>>>>>> > >>>>> > >> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(java.rmi at 15-ea > >>>>>>> /TCPTransport.java:705) > >>>>>>> at > >>>>>>> > >>>>> > >> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$686/0x0000000800da3998.run(java.rmi at 15-ea > >>>>> /Unknown > >>>>>>> Source) > >>>>>>> at > >>>>>>> java.security.AccessController.executePrivileged(java.base at 15-ea > >>>>>>> /AccessController.java:753) > >>>>>>> at > >> java.security.AccessController.doPrivileged(java.base at 15-ea > >>>>>>> /AccessController.java:391) > >>>>>>> at > >>>>>>> > >>>>> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(java.rmi at 15-ea > >>>>>>> /TCPTransport.java:704) > >>>>>>> at > >>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:1130) > >>>>>>> at > >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:630) > >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - <0x0000000602e19708> (a > >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker) > >>>>>>> - <0x0000000602e59038> (a > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>>>>>> > >>>>>>> "RMI Scheduler(0)" #29 daemon prio=5 os_prio=0 cpu=0.00ms > >>>>> elapsed=180.86s > >>>>>>> tid=0x000001e34a462160 nid=0x1df0 waiting on condition > >>>>> [0x000000340fcfe000] > >>>>>>> java.lang.Thread.State: TIMED_WAITING (parking) > >>>>>>> at jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native > >>>>> Method) > >>>>>>> - parking to wait for <0x0000000602e1af00> (a > >>>>>>> > >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > >>>>>>> at > >>>>>>> java.util.concurrent.locks.LockSupport.parkNanos(java.base at 15-ea > >>>>>>> /LockSupport.java:252) > >>>>>>> at > >>>>>>> > >>>>> > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 15-ea > >>>>>>> /AbstractQueuedSynchronizer.java:1661) > >>>>>>> at > >>>>>>> > >>>>> > >> > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > >>>>>>> /ScheduledThreadPoolExecutor.java:1182) > >>>>>>> at > >>>>>>> > >>>>> > >> > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > >>>>>>> /ScheduledThreadPoolExecutor.java:899) > >>>>>>> at > >>>>> java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:1056) > >>>>>>> at > >>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:1116) > >>>>>>> at > >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:630) > >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "JMX server connection timeout 30" #30 daemon prio=5 os_prio=0 > >>>>> cpu=0.00ms > >>>>>>> elapsed=180.86s tid=0x000001e34a45f610 nid=0x2fe8 in Object.wait() > >>>>>>> [0x000000340fdff000] > >>>>>>> java.lang.Thread.State: TIMED_WAITING (on object monitor) > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native Method) > >>>>>>> - waiting on > >>>>>>> at > >>>>>>> > >>>>> > >> > com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(java.management at 15-ea > >>>>>>> /ServerCommunicatorAdmin.java:171) > >>>>>>> - locked <0x0000000602e1ca08> (a [I) > >>>>>>> at java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>> Locked ownable synchronizers: > >>>>>>> - None > >>>>>>> > >>>>>>> "VM Thread" os_prio=2 cpu=515.63ms elapsed=341.79s > >>>>> tid=0x000001e349031eb0 > >>>>>>> nid=0x540 runnable > >>>>>>> > >>>>>>> "GC Thread#0" os_prio=2 cpu=328.13ms elapsed=341.80s > >>>>>>> tid=0x000001e31c218710 nid=0x19e8 runnable > >>>>>>> > >>>>>>> "GC Thread#1" os_prio=2 cpu=265.63ms elapsed=341.53s > >>>>>>> tid=0x000001e349b353d0 nid=0x1cc4 runnable > >>>>>>> > >>>>>>> "GC Thread#2" os_prio=2 cpu=218.75ms elapsed=340.37s > >>>>>>> tid=0x000001e349b350a0 nid=0x1ddc runnable > >>>>>>> > >>>>>>> "GC Thread#3" os_prio=2 cpu=187.50ms elapsed=338.82s > >>>>>>> tid=0x000001e349b35700 nid=0x4a48 runnable > >>>>>>> > >>>>>>> "GC Thread#4" os_prio=2 cpu=140.63ms elapsed=338.82s > >>>>>>> tid=0x000001e349b340b0 nid=0x32e8 runnable > >>>>>>> > >>>>>>> "GC Thread#5" os_prio=2 cpu=156.25ms elapsed=338.82s > >>>>>>> tid=0x000001e349b35a30 nid=0x38cc runnable > >>>>>>> > >>>>>>> "GC Thread#6" os_prio=2 cpu=171.88ms elapsed=338.82s > >>>>>>> tid=0x000001e349b35d60 nid=0x3ed0 runnable > >>>>>>> > >>>>>>> "G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=341.80s > >>>>>>> tid=0x000001e31c229930 nid=0x21c runnable > >>>>>>> > >>>>>>> "G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=341.80s > >>>>> tid=0x000001e31c22a5a0 > >>>>>>> nid=0x3920 runnable > >>>>>>> > >>>>>>> "G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=341.80s > >>>>> tid=0x000001e31c253f10 > >>>>>>> nid=0x1f84 runnable > >>>>>>> > >>>>>>> "G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms elapsed=341.80s > >>>>>>> tid=0x000001e31c254b90 nid=0x27ac runnable > >>>>>>> > >>>>>>> "VM Periodic Task Thread" os_prio=2 cpu=15.63ms elapsed=341.76s > >>>>>>> tid=0x000001e349b39710 nid=0x838 waiting on condition > >>>>>>> > >>>>>>> JNI global refs: 33, weak refs: 0 > >>>>>>> > >>>>>>> -- > >>>>>>> Aaron Scott-Boddendijk > >>>>>>> > >>>>>>> On Tue, Jun 16, 2020 at 10:15 AM Robert Field < > >>>>> robert.field at oracle.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Make that jps/jstack > >>>>>>>> > >>>>>>>> -R > >>>>>>>> > >>>>>>>> On 2020-06-15 15:12, Robert Field wrote: > >>>>>>>>> Thanks for the report. > >>>>>>>>> > >>>>>>>>> What, if anything, is the Java stack for this thread (jps)? > >>>>>>>>> > >>>>>>>>> -Robert > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 2020-06-15 14:41, Aaron Scott-Boddendijk wrote: > >>>>>>>>>> System: > >>>>>>>>>> * Windows 10 > >>>>>>>>>> * Powershell > >>>>>>>>>> > >>>>>>>>>> When I start JShell, without executing anything, a CPU core is > >>>>> always > >>>>>>>> at > >>>>>>>>>> 100% (a single thread though I haven't identified what it's > >>>>> doing). > >>>>>>>>>> > >>>>>>>>>> The thread stack is as follows (with only the last two items > >>>>> sometimes > >>>>>>>>>> change - but I don't know the internals of the JVM to know if > >> this > >>>>>>>>>> useful > >>>>>>>>>> or significant): > >>>>>>>>>> > >>>>>>>>>> ntoskrnl.exe!KeSynchronizeExecution+0x5b46 > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x1c2d > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0xab4 > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x255 > >>>>>>>>>> ntoskrnl.exe!RtlClearBitsEx+0x15a7 > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x3828 > >>>>>>>>>> ntoskrnl.exe!KeSynchronizeExecution+0x3120 > >>>>>>>>>> jvm.dll!c2v_notifyCompilerInliningEvent+0x201797 > >>>>>>>>>> > >>>>>>>>>> The JDK 14 version of JShell does not have this issue but > >> several > >>>>> of > >>>>>>>> the > >>>>>>>>>> recent JDK 15 builds have done this. > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Aaron Scott-Boddendijk > >>>>>>>> > >>>>>>> > >>>>> > >>>> > >> > From jan.lahoda at oracle.com Wed Jul 15 12:15:08 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 15 Jul 2020 14:15:08 +0200 Subject: RFR: JDK-8249367: JShell uses 100% of one core all the time Message-ID: Hi, JShell consumes basically a 100% of one CPU thread on Windows all the time while waiting for a user input. The reason is that: -JShell's StopDetectingInputStream invokes "read()" method on NonBlockingReaderInputStream (without a timeout, which is an addition of JLine's non blocking streams and readers), which is converted to a read with timeout 0. The NonBlockingReaderInputStream then delegates to NonBlockingPumpReader, using its read method with timeout 0. But with timeout zero, this particular reader returns immediately, and because there was no input, and no timeout set to NonBlockingReaderInputStream, it will loop and ask the NonBlockingPumpReader again, and ultimately NonBlockingReaderInputStream.read spins in a loop. The ultimate problem is, I believe, in NonBlockingPumpReader, which should not return immediately for timeout 0 (other non blocking streams/readers wait indefinitely for input for timeout 0). I have filled a bug to JLine for this: https://github.com/jline/jline3/issues/552 But, mostly as a workaround, I suggest that StopDetectingInputStream uses a timeout while reading from non blocking streams. That should be safe, and we can revert to the current state when the above bug is fixed. Proposed patch: http://cr.openjdk.java.net/~jlahoda/8249367/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8249367 What do you think? Thanks, Jan From jan.lahoda at oracle.com Wed Jul 15 12:18:38 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 15 Jul 2020 14:18:38 +0200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> Message-ID: FWIW, I've sent: https://mail.openjdk.java.net/pipermail/kulla-dev/2020-July/002551.html I'd be happy if someone else could verify it solves the issue (given the upcoming RDP2). Thanks, Jan On 15. 07. 20 9:15, Christian Stein wrote: > JShell 16-ea is affected, too. > > Hoping that the fix is as simple as you think, Jan. > Perhaps, it can make its way into JShell 15 before GA. > > Cheers, > Christian > > > On Tue, Jul 14, 2020 at 9:05 PM Jan Lahoda > wrote: > > Hi, > > Thanks for the report and analysis. I've filled: > https://bugs.openjdk.java.net/browse/JDK-8249367 > > I think the issue is in: > http://hg.openjdk.java.net/jdk/jdk/file/1e249ca8d585/src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlocking.java#l104 > > If the timeout is zero (which it is when invoked from > StopDetectingInputStream, as it calls the read method without timeout), > the method invocation will exit immediately, and it will be immediately > called again, etc. > > Jan > > On 13. 07. 20 6:00, Aaron Scott-Boddendijk wrote: > > I can confirm the CPU behaves as suggested with a sequence of > entering and > > leaving `/edit`. > > > > Thanks Christian. > > > > -- > > Aaron Scott-Boddendijk > > > > On Mon, Jul 13, 2020 at 3:27 PM Christian Stein > > wrote: > > > >> It's coming from the "while(true)"-loop in > StopDetectingInputStream.java > >> [0]. > >> > >> Aaron, try to open an external editor within the JShell session via > >> > >>? ? /edit > >> > >> The CPU usage should drop immediately to normal levels. > >> As soon as you close the editor (it's the internal JShell Edit > Pad for me) > >> the thread is again eating CPU cycles. Can you confirm this? > >> > >> While the editor is opened, the thread waits via > >> > >> > ?jdk.internal.jshell.tool.StopDetectingInputStream.waitInputNeeded > line: > >> 164 > >> > >> If no editor is open, the "input.read()" method does never wait: > >> > >> > >> > ?jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > >> line: 66 > >> > >> Cheers, > >> Christian > >> > >> [0]: > >> > >> > https://github.com/openjdk/jdk/blob/faf4d7ccb792b16092c791c0ac77acdd440dbca1/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java#L57-L74 > >> > >> On Mon, Jul 13, 2020 at 5:05 AM Christian Stein > > > >> wrote: > >> > >>> Seems like "read line" from "jline" is underlying reason: > >>> > >>> Thread-2 [31] (RUNNABLE) > >>> > >>> > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await > >>> line: 1749 > >>>? ? ?jdk.internal.org.jline.utils.NonBlockingPumpReader.read > line: 77 > >>>? ? ?jdk.internal.org.jline.utils.NonBlockingReader.read line: 57 > >>> > >>> > >> > jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read > >>> line: 104 > >>>? ? ?jdk.internal.org.jline.utils.NonBlockingInputStream.read > line: 36 > >>> > >>> > >> > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > >>> line: 66 > >>> > >>> > >> > jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$347/0x0000000800cff330.run > >>> line: not available > >>>? ? ?java.lang.Thread.run line: 832 > >>> > >>> It produces a constant high CPU usage and allocates a lot of > RAM per > >>> second. > >>> > >>> Thread Name Thread State Blocked Count Total CPU Usage Deadlocked > >>> Allocated Memory > >>> Thread-2 RUNNABLE 1 0.06252084028009336 Not Enabled 196198305136 B > >>> > >>> > >>> > >>> > >>> > >>> On Mon, Jul 13, 2020 at 4:52 AM Christian Stein > > > >>> wrote: > >>> > >>>> Hi Aaron, > >>>> > >>>> I observe the same behaviour of JShell 15 build 30. > >>>> > >>>> Here, the 100% CPU workload is split on to 3-4 logical processors. > >>>> Grabbed an animated GIF of "jshell.exe -- /exit" session at [0]. > >>>> To me, it looks like a loop is running wild, w/o a > >>>> Thread.yield()/.sleep() call. > >>>> > >>>> Microsoft Windows [Version 10.0.19041.329] > >>>> > >>>> openjdk 15-ea 2020-09-15 > >>>> OpenJDK Runtime Environment (build 15-ea+30-1476) > >>>> OpenJDK 64-Bit Server VM (build 15-ea+30-1476, mixed mode, > sharing) > >>>> > >>>> Cheers, > >>>> Christian > >>>> > >>>> [0]: > >>>> > >> > https://drive.google.com/file/d/1KOQO5B9WrM4C43K3AB7H9VVPuh9hdCOe/view?usp=sharing > >>>> > >>>> > >>>> On Mon, Jul 13, 2020 at 4:24 AM Aaron Scott-Boddendijk < > >> talden at gmail.com > > >>>> wrote: > >>>> > >>>>> This still exists in JDK 15 build 31. > >>>>> > >>>>> Is any other Windows user able to reproduce this? I have two > machines, > >>>>> one > >>>>> laptop and one desktop that show a CPU thread constantly @ > 100% just by > >>>>> starting JShell. For the desktop machine that's not a major > issue but > >> for > >>>>> the laptop this spins up the fans and eats the battery. > >>>>> > >>>>> JShell in JDK 14 is fine. > >>>>> > >>>>> I've yet to hear of any other user confirming this issue. > >>>>> > >>>>> -- > >>>>> Aaron Scott-Boddendijk > >>>>> > >>>>> > >>>>> On Fri, Jun 26, 2020 at 2:00 PM Aaron Scott-Boddendijk < > >> talden at gmail.com > >>>>>> > >>>>> wrote: > >>>>> > >>>>>> Just confirming that: > >>>>>> > >>>>>> * This still exists in JDK 15 build 29 > >>>>>> * Occurs on multiple unrelated Windows 10 machines with > differing > >> major > >>>>>> versions of the OS. > >>>>>> * Does not occur in JDK 14.01 on these machines (OpenJDK 64-Bit > >> Server > >>>>> VM > >>>>>> Zulu14.28+21-CA) > >>>>>> * Does not appear to occur on Linux > >>>>>> > >>>>>> -- > >>>>>> Aaron Scott-Boddendijk > >>>>>> > >>>>>> > >>>>>> On Tue, Jun 16, 2020 at 11:16 AM Aaron Scott-Boddendijk < > >>>>> talden at gmail.com > > >>>>>> wrote: > >>>>>> > >>>>>>> This is the thread-dump from the JVM that VisualVM sees as > using a > >>>>> core... > >>>>>>> > >>>>>>> 2020-06-16 11:07:35 > >>>>>>> Full thread dump OpenJDK 64-Bit Server VM (15-ea+27-1372 > mixed mode, > >>>>>>> sharing): > >>>>>>> > >>>>>>> Threads class SMR info: > >>>>>>> _java_thread_list=0x000001e34a6040f0, length=23, elements={ > >>>>>>> 0x000001e31c1a1dc0, 0x000001e349035ee0, 0x000001e349037250, > >>>>>>> 0x000001e349058ae0, > >>>>>>> 0x000001e34905c5b0, 0x000001e34905f710, 0x000001e3490603f0, > >>>>>>> 0x000001e349065140, > >>>>>>> 0x000001e34906d620, 0x000001e349b36a20, 0x000001e349b8c690, > >>>>>>> 0x000001e349da3400, > >>>>>>> 0x000001e349daa7c0, 0x000001e349dbb640, 0x000001e34a141140, > >>>>>>> 0x000001e349d555c0, > >>>>>>> 0x000001e34b07f030, 0x000001e34a461c90, 0x000001e34a45fae0, > >>>>>>> 0x000001e34a45ffb0, > >>>>>>> 0x000001e34a4617c0, 0x000001e34a462160, 0x000001e34a45f610 > >>>>>>> } > >>>>>>> > >>>>>>> "main" #1 prio=5 os_prio=0 cpu=1078.13ms elapsed=341.81s > >>>>>>> tid=0x000001e31c1a1dc0 nid=0x16b0 in Object.wait() > >>>>> [0x000000340d9fe000] > >>>>>>>? ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) > >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > Method) > >>>>>>>? ? ? ? ? - waiting on > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingInputStreamImpl.java:139) > >>>>>>>? ? ? ? ? - locked <0x000000060fe87338> (a > >>>>>>> jdk.internal.jshell.tool.ConsoleIOContext$1) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingInputStream.java:62) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlocking.java:168) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingReader.java:57) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 15-ea > >>>>>>> /BindingReader.java:160) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > >>>>>>> /BindingReader.java:110) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > >>>>>>> /BindingReader.java:61) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 15-ea > >>>>>>> /LineReaderImpl.java:913) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 15-ea > >>>>>>> /LineReaderImpl.java:946) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 15-ea > >>>>>>> /ConsoleIOContext.java:154) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > >>>>>>> /LineReaderImpl.java:637) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > >>>>>>> /LineReaderImpl.java:454) > >>>>>>>? ? ? ? ? at > >>>>>>> > jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 15-ea > >>>>>>> /ConsoleIOContext.java:229) > >>>>>>>? ? ? ? ? at > >>>>> jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 15-ea > >>>>>>> /JShellTool.java:1254) > >>>>>>>? ? ? ? ? at > jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 15-ea > >>>>>>> /JShellTool.java:1190) > >>>>>>>? ? ? ? ? at > >> jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 15-ea > >>>>>>> /JShellTool.java:991) > >>>>>>>? ? ? ? ? at > >>>>>>> > jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 15-ea > >>>>>>> /JShellToolBuilder.java:254) > >>>>>>>? ? ? ? ? at > >>>>>>> > jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 15-ea > >>>>>>> /JShellToolProvider.java:120) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "Reference Handler" #2 daemon prio=10 os_prio=2 cpu=0.00ms > >>>>>>> elapsed=341.79s tid=0x000001e349035ee0 nid=0x13fc waiting on > >> condition > >>>>>>>? ?[0x000000340e0fe000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>>? ? ? ? ? at > >>>>>>> > java.lang.ref.Reference.waitForReferencePendingList(java.base at 15-ea > >>>>> /Native > >>>>>>> Method) > >>>>>>>? ? ? ? ? at > >>>>>>> > java.lang.ref.Reference.processPendingReferences(java.base at 15-ea > >>>>>>> /Reference.java:241) > >>>>>>>? ? ? ? ? at > >>>>> java.lang.ref.Reference$ReferenceHandler.run(java.base at 15-ea > >>>>>>> /Reference.java:213) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms > elapsed=341.79s > >>>>>>> tid=0x000001e349037250 nid=0x2a60 in Object.wait() > >>>>> [0x000000340e1fe000] > >>>>>>>? ? ?java.lang.Thread.State: WAITING (on object monitor) > >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > Method) > >>>>>>>? ? ? ? ? - waiting on <0x0000000601400bc0> (a > >>>>>>> java.lang.ref.ReferenceQueue$Lock) > >>>>>>>? ? ? ? ? at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >>>>>>> /ReferenceQueue.java:155) > >>>>>>>? ? ? ? ? - locked <0x0000000601400bc0> (a > >>>>>>> java.lang.ref.ReferenceQueue$Lock) > >>>>>>>? ? ? ? ? at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >>>>>>> /ReferenceQueue.java:176) > >>>>>>>? ? ? ? ? at > >> java.lang.ref.Finalizer$FinalizerThread.run(java.base at 15-ea > >>>>>>> /Finalizer.java:170) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms > >>>>> elapsed=341.78s > >>>>>>> tid=0x000001e349058ae0 nid=0x35c8 runnable > [0x0000000000000000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "Attach Listener" #5 daemon prio=5 os_prio=2 cpu=125.00ms > >>>>> elapsed=341.78s > >>>>>>> tid=0x000001e34905c5b0 nid=0x3e0c waiting on condition > >>>>> [0x0000000000000000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "Service Thread" #6 daemon prio=9 os_prio=0 cpu=0.00ms > >> elapsed=341.78s > >>>>>>> tid=0x000001e34905f710 nid=0x398c runnable > [0x0000000000000000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "C2 CompilerThread0" #7 daemon prio=9 os_prio=2 cpu=1781.25ms > >>>>>>> elapsed=341.78s tid=0x000001e3490603f0 nid=0xcf0 waiting on > >> condition > >>>>>>>? ?[0x0000000000000000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>>? ? ?No compile task > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "C1 CompilerThread0" #10 daemon prio=9 os_prio=2 cpu=765.63ms > >>>>>>> elapsed=341.78s tid=0x000001e349065140 nid=0x3e54 waiting on > >> condition > >>>>>>>? ?[0x0000000000000000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>>? ? ?No compile task > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "Sweeper thread" #11 daemon prio=9 os_prio=2 cpu=0.00ms > >>>>> elapsed=341.78s > >>>>>>> tid=0x000001e34906d620 nid=0x38bc runnable > [0x0000000000000000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "Notification Thread" #12 daemon prio=9 os_prio=0 cpu=0.00ms > >>>>>>> elapsed=341.76s tid=0x000001e349b36a20 nid=0x49b8 runnable > >>>>>>>? ?[0x0000000000000000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "Common-Cleaner" #13 daemon prio=8 os_prio=1 cpu=0.00ms > >>>>> elapsed=341.75s > >>>>>>> tid=0x000001e349b8c690 nid=0x26e4 in Object.wait() > >>>>> [0x000000340eaff000] > >>>>>>>? ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) > >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > Method) > >>>>>>>? ? ? ? ? - waiting on > >>>>>>>? ? ? ? ? at java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >>>>>>> /ReferenceQueue.java:155) > >>>>>>>? ? ? ? ? - locked <0x0000000601401a78> (a > >>>>>>> java.lang.ref.ReferenceQueue$Lock) > >>>>>>>? ? ? ? ? at jdk.internal.ref.CleanerImpl.run(java.base at 15-ea > >>>>>>> /CleanerImpl.java:148) > >>>>>>>? ? ? ? ? at > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>>? ? ? ? ? at > jdk.internal.misc.InnocuousThread.run(java.base at 15-ea > >>>>>>> /InnocuousThread.java:134) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "JDI Internal Event Handler" #17 daemon prio=5 os_prio=0 > cpu=15.63ms > >>>>>>> elapsed=341.39s tid=0x000001e349da3400 nid=0x68 in > Object.wait() > >>>>>>>? ?[0x000000340effe000] > >>>>>>>? ? ?java.lang.Thread.State: WAITING (on object monitor) > >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > Method) > >>>>>>>? ? ? ? ? - waiting on > >>>>>>>? ? ? ? ? at > java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >>>>>>>? ? ? ? ? at > >>>>> com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > >>>>>>> /EventQueueImpl.java:190) > >>>>>>>? ? ? ? ? - locked <0x000000060154b630> (a > >>>>> com.sun.tools.jdi.EventQueueImpl) > >>>>>>>? ? ? ? ? at > >>>>> com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 15-ea > >>>>>>> /EventQueueImpl.java:125) > >>>>>>>? ? ? ? ? at > com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 15-ea > >>>>>>> /InternalEventHandler.java:61) > >>>>>>>? ? ? ? ? at > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "JDI Target VM Interface" #16 daemon prio=5 os_prio=0 > cpu=46.88ms > >>>>>>> elapsed=341.39s tid=0x000001e349daa7c0 nid=0x3d04 runnable > >>>>>>>? ?[0x000000340f0fe000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>>? ? ? ? ? at > sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native > >>>>>>> Method) > >>>>>>>? ? ? ? ? at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > >>>>>>> /SocketDispatcher.java:46) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:261) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:312) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:350) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:803) > >>>>>>>? ? ? ? ? at > java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>>>>>> /Socket.java:981) > >>>>>>>? ? ? ? ? at > java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>>>>>> /Socket.java:976) > >>>>>>>? ? ? ? ? at > >> com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 15-ea > >>>>>>> /SocketConnection.java:82) > >>>>>>>? ? ? ? ? - locked <0x000000060154b998> (a java.lang.Object) > >>>>>>>? ? ? ? ? at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 15-ea > >>>>>>> /TargetVM.java:124) > >>>>>>>? ? ? ? ? at > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - <0x0000000601577110> (a > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>>>>>> > >>>>>>> "event-handler" #18 daemon prio=5 os_prio=0 cpu=0.00ms > >> elapsed=341.38s > >>>>>>> tid=0x000001e349dbb640 nid=0x203c in Object.wait() > >>>>> [0x000000340edfe000] > >>>>>>>? ? ?java.lang.Thread.State: WAITING (on object monitor) > >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > Method) > >>>>>>>? ? ? ? ? - waiting on > >>>>>>>? ? ? ? ? at > java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >>>>>>>? ? ? ? ? at > >>>>> com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > >>>>>>> /EventQueueImpl.java:190) > >>>>>>>? ? ? ? ? - locked <0x000000060154bc28> (a > >>>>> com.sun.tools.jdi.EventQueueImpl) > >>>>>>>? ? ? ? ? at > com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > >>>>>>> /EventQueueImpl.java:97) > >>>>>>>? ? ? ? ? at > com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > >>>>>>> /EventQueueImpl.java:83) > >>>>>>>? ? ? ? ? at > jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 15-ea > >>>>>>> /JdiEventHandler.java:79) > >>>>>>>? ? ? ? ? at > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "output reader" #19 daemon prio=5 os_prio=0 cpu=0.00ms > >> elapsed=341.31s > >>>>>>> tid=0x000001e34a141140 nid=0x49c0 runnable > [0x000000340eeff000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>>? ? ? ? ? at > sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native > >>>>>>> Method) > >>>>>>>? ? ? ? ? at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > >>>>>>> /SocketDispatcher.java:46) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:261) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:312) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:350) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:803) > >>>>>>>? ? ? ? ? at > java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>>>>>> /Socket.java:981) > >>>>>>>? ? ? ? ? at > java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>>>>>> /Socket.java:976) > >>>>>>>? ? ? ? ? at java.io.FilterInputStream.read(java.base at 15-ea > >>>>>>> /FilterInputStream.java:82) > >>>>>>>? ? ? ? ? at > >> jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 15-ea > >>>>>>> /DemultiplexInput.java:58) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - <0x0000000601553510> (a > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>>>>>> > >>>>>>> "Thread-0" #21 daemon prio=5 os_prio=0 cpu=312.50ms > elapsed=341.22s > >>>>>>> tid=0x000001e349d555c0 nid=0x4d88 waiting on condition > >>>>> [0x000000340f1fe000] > >>>>>>>? ? ?java.lang.Thread.State: WAITING (parking) > >>>>>>>? ? ? ? ? at > jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native > >>>>> Method) > >>>>>>>? ? ? ? ? - parking to wait for? <0x0000000601550fc0> (a > >>>>>>> > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > >>>>>>>? ? ? ? ? at > >> java.util.concurrent.locks.LockSupport.park(java.base at 15-ea > >>>>>>> /LockSupport.java:341) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 15-ea > >>>>>>> /AbstractQueuedSynchronizer.java:505) > >>>>>>>? ? ? ? ? at > >>>>> java.util.concurrent.ForkJoinPool.managedBlock(java.base at 15-ea > >>>>>>> /ForkJoinPool.java:3137) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > >>>>>>> /AbstractQueuedSynchronizer.java:1614) > >>>>>>>? ? ? ? ? at > >>>>> java.util.concurrent.LinkedBlockingQueue.take(java.base at 15-ea > >>>>>>> /LinkedBlockingQueue.java:435) > >>>>>>>? ? ? ? ? at > >>>>> java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:1056) > >>>>>>>? ? ? ? ? at > >>>>>>> > java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:1116) > >>>>>>>? ? ? ? ? at > >>>>>>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:630) > >>>>>>>? ? ? ? ? at > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "Thread-2" #23 daemon prio=5 os_prio=0 cpu=338859.38ms > >> elapsed=340.58s > >>>>>>> tid=0x000001e34b07f030 nid=0xac0 runnable? [0x000000340f3fe000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > >>>>>>> /AbstractQueuedSynchronizer.java:1749) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingPumpReader.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingPumpReader.java:77) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingReader.java:57) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlocking.java:104) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingInputStream.java:36) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 15-ea > >>>>>>> /StopDetectingInputStream.java:66) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$410/0x0000000800d2eb28.run(jdk.jshell at 15-ea > >>>>> /Unknown > >>>>>>> Source) > >>>>>>>? ? ? ? ? at > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - <0x00000006028b4318> (a > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>>>>>> > >>>>>>> "WindowsStreamPump" #25 daemon prio=5 os_prio=0 cpu=0.00ms > >>>>>>> elapsed=340.53s tid=0x000001e34a461c90 nid=0x3688 runnable > >>>>>>>? ?[0x000000340f4fe000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.terminal.impl.jna.win.Kernel32Impl.WaitForSingleObject(jdk.internal.le at 15-ea > >>>>> /Native > >>>>>>> Method) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.readConsoleInput(jdk.internal.le at 15-ea > >>>>>>> /JnaWinSysTerminal.java:185) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.processConsoleInput(jdk.internal.le at 15-ea > >>>>>>> /JnaWinSysTerminal.java:108) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal.pump(jdk.internal.le at 15-ea > >>>>>>> /AbstractWindowsTerminal.java:465) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal$$Lambda$417/0x0000000800d310f8.run(jdk.internal.le at 15-ea > >>>>> /Unknown > >>>>>>> Source) > >>>>>>>? ? ? ? ? at > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "null non blocking reader thread" #26 daemon prio=5 os_prio=0 > >>>>> cpu=0.00ms > >>>>>>> elapsed=340.26s tid=0x000001e34a45fae0 nid=0x488 in > Object.wait() > >>>>>>>? ?[0x000000340f6ff000] > >>>>>>>? ? ?java.lang.Thread.State: WAITING (on object monitor) > >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > Method) > >>>>>>>? ? ? ? ? - waiting on > >>>>>>>? ? ? ? ? at > java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 15-ea > >>>>>>> /StopDetectingInputStream.java:98) > >>>>>>>? ? ? ? ? - locked <0x0000000601e2b650> (a > >>>>>>> jdk.internal.jshell.tool.StopDetectingInputStream) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 15-ea > >>>>>>> /NonBlockingInputStreamImpl.java:216) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$584/0x0000000800d4f088.run(jdk.internal.le at 15-ea > >>>>> /Unknown > >>>>>>> Source) > >>>>>>>? ? ? ? ? at > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "RMI TCP Accept-0" #27 daemon prio=5 os_prio=0 cpu=0.00ms > >>>>> elapsed=180.89s > >>>>>>> tid=0x000001e34a45ffb0 nid=0x45f0 runnable > [0x000000340d8fe000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>>? ? ? ? ? at sun.nio.ch.Net.accept(java.base at 15-ea/Native > Method) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl.accept(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:755) > >>>>>>>? ? ? ? ? at java.net.ServerSocket.implAccept(java.base at 15-ea > >>>>>>> /ServerSocket.java:684) > >>>>>>>? ? ? ? ? at > java.net.ServerSocket.platformImplAccept(java.base at 15-ea > >>>>>>> /ServerSocket.java:650) > >>>>>>>? ? ? ? ? at java.net.ServerSocket.implAccept(java.base at 15-ea > >>>>>>> /ServerSocket.java:626) > >>>>>>>? ? ? ? ? at java.net.ServerSocket.implAccept(java.base at 15-ea > >>>>>>> /ServerSocket.java:583) > >>>>>>>? ? ? ? ? at java.net.ServerSocket.accept(java.base at 15-ea > >>>>>>> /ServerSocket.java:540) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(jdk.management.agent at 15-ea > >>>>>>> /LocalRMIServerSocketFactory.java:52) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi at 15-ea > >>>>>>> /TCPTransport.java:413) > >>>>>>>? ? ? ? ? at > >>>>>>> > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi at 15-ea > >>>>>>> /TCPTransport.java:377) > >>>>>>>? ? ? ? ? at > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - <0x0000000602e53118> (a > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>>>>>> > >>>>>>> "RMI TCP Connection(1)-10.0.201.131" #28 daemon prio=5 > os_prio=0 > >>>>>>> cpu=437.50ms elapsed=180.87s tid=0x000001e34a4617c0 nid=0x4790 > >>>>> runnable > >>>>>>>? ?[0x000000340fbfe000] > >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >>>>>>>? ? ? ? ? at sun.nio.ch.Net.poll(java.base at 15-ea/Native Method) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:181) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:285) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:309) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:350) > >>>>>>>? ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >>>>>>> /NioSocketImpl.java:803) > >>>>>>>? ? ? ? ? at > java.net.Socket$SocketInputStream.read(java.base at 15-ea > >>>>>>> /Socket.java:981) > >>>>>>>? ? ? ? ? at java.io.BufferedInputStream.fill(java.base at 15-ea > >>>>>>> /BufferedInputStream.java:244) > >>>>>>>? ? ? ? ? at java.io.BufferedInputStream.read(java.base at 15-ea > >>>>>>> /BufferedInputStream.java:263) > >>>>>>>? ? ? ? ? - locked <0x0000000602e19470> (a > >> java.io.BufferedInputStream) > >>>>>>>? ? ? ? ? at java.io.FilterInputStream.read(java.base at 15-ea > >>>>>>> /FilterInputStream.java:82) > >>>>>>>? ? ? ? ? at > >>>>>>> > sun.rmi.transport.tcp.TCPTransport.handleMessages(java.rmi at 15-ea > >>>>>>> /TCPTransport.java:569) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(java.rmi at 15-ea > >>>>>>> /TCPTransport.java:828) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(java.rmi at 15-ea > >>>>>>> /TCPTransport.java:705) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$686/0x0000000800da3998.run(java.rmi at 15-ea > >>>>> /Unknown > >>>>>>> Source) > >>>>>>>? ? ? ? ? at > >>>>>>> > java.security.AccessController.executePrivileged(java.base at 15-ea > >>>>>>> /AccessController.java:753) > >>>>>>>? ? ? ? ? at > >> java.security.AccessController.doPrivileged(java.base at 15-ea > >>>>>>> /AccessController.java:391) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(java.rmi at 15-ea > >>>>>>> /TCPTransport.java:704) > >>>>>>>? ? ? ? ? at > >>>>>>> > java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:1130) > >>>>>>>? ? ? ? ? at > >>>>>>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:630) > >>>>>>>? ? ? ? ? at > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - <0x0000000602e19708> (a > >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker) > >>>>>>>? ? ? ? ? - <0x0000000602e59038> (a > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >>>>>>> > >>>>>>> "RMI Scheduler(0)" #29 daemon prio=5 os_prio=0 cpu=0.00ms > >>>>> elapsed=180.86s > >>>>>>> tid=0x000001e34a462160 nid=0x1df0 waiting on condition > >>>>> [0x000000340fcfe000] > >>>>>>>? ? ?java.lang.Thread.State: TIMED_WAITING (parking) > >>>>>>>? ? ? ? ? at > jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native > >>>>> Method) > >>>>>>>? ? ? ? ? - parking to wait for? <0x0000000602e1af00> (a > >>>>>>> > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > >>>>>>>? ? ? ? ? at > >>>>>>> > java.util.concurrent.locks.LockSupport.parkNanos(java.base at 15-ea > >>>>>>> /LockSupport.java:252) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 15-ea > >>>>>>> /AbstractQueuedSynchronizer.java:1661) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > >>>>>>> /ScheduledThreadPoolExecutor.java:1182) > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > >>>>>>> /ScheduledThreadPoolExecutor.java:899) > >>>>>>>? ? ? ? ? at > >>>>> java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:1056) > >>>>>>>? ? ? ? ? at > >>>>>>> > java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:1116) > >>>>>>>? ? ? ? ? at > >>>>>>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >>>>>>> /ThreadPoolExecutor.java:630) > >>>>>>>? ? ? ? ? at > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "JMX server connection timeout 30" #30 daemon prio=5 os_prio=0 > >>>>> cpu=0.00ms > >>>>>>> elapsed=180.86s tid=0x000001e34a45f610 nid=0x2fe8 in > Object.wait() > >>>>>>>? ?[0x000000340fdff000] > >>>>>>>? ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) > >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > Method) > >>>>>>>? ? ? ? ? - waiting on > >>>>>>>? ? ? ? ? at > >>>>>>> > >>>>> > >> > com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(java.management at 15-ea > >>>>>>> /ServerCommunicatorAdmin.java:171) > >>>>>>>? ? ? ? ? - locked <0x0000000602e1ca08> (a [I) > >>>>>>>? ? ? ? ? at > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >>>>>>> > >>>>>>>? ? ?Locked ownable synchronizers: > >>>>>>>? ? ? ? ? - None > >>>>>>> > >>>>>>> "VM Thread" os_prio=2 cpu=515.63ms elapsed=341.79s > >>>>> tid=0x000001e349031eb0 > >>>>>>> nid=0x540 runnable > >>>>>>> > >>>>>>> "GC Thread#0" os_prio=2 cpu=328.13ms elapsed=341.80s > >>>>>>> tid=0x000001e31c218710 nid=0x19e8 runnable > >>>>>>> > >>>>>>> "GC Thread#1" os_prio=2 cpu=265.63ms elapsed=341.53s > >>>>>>> tid=0x000001e349b353d0 nid=0x1cc4 runnable > >>>>>>> > >>>>>>> "GC Thread#2" os_prio=2 cpu=218.75ms elapsed=340.37s > >>>>>>> tid=0x000001e349b350a0 nid=0x1ddc runnable > >>>>>>> > >>>>>>> "GC Thread#3" os_prio=2 cpu=187.50ms elapsed=338.82s > >>>>>>> tid=0x000001e349b35700 nid=0x4a48 runnable > >>>>>>> > >>>>>>> "GC Thread#4" os_prio=2 cpu=140.63ms elapsed=338.82s > >>>>>>> tid=0x000001e349b340b0 nid=0x32e8 runnable > >>>>>>> > >>>>>>> "GC Thread#5" os_prio=2 cpu=156.25ms elapsed=338.82s > >>>>>>> tid=0x000001e349b35a30 nid=0x38cc runnable > >>>>>>> > >>>>>>> "GC Thread#6" os_prio=2 cpu=171.88ms elapsed=338.82s > >>>>>>> tid=0x000001e349b35d60 nid=0x3ed0 runnable > >>>>>>> > >>>>>>> "G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=341.80s > >>>>>>> tid=0x000001e31c229930 nid=0x21c runnable > >>>>>>> > >>>>>>> "G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=341.80s > >>>>> tid=0x000001e31c22a5a0 > >>>>>>> nid=0x3920 runnable > >>>>>>> > >>>>>>> "G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=341.80s > >>>>> tid=0x000001e31c253f10 > >>>>>>> nid=0x1f84 runnable > >>>>>>> > >>>>>>> "G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms elapsed=341.80s > >>>>>>> tid=0x000001e31c254b90 nid=0x27ac runnable > >>>>>>> > >>>>>>> "VM Periodic Task Thread" os_prio=2 cpu=15.63ms elapsed=341.76s > >>>>>>> tid=0x000001e349b39710 nid=0x838 waiting on condition > >>>>>>> > >>>>>>> JNI global refs: 33, weak refs: 0 > >>>>>>> > >>>>>>> -- > >>>>>>> Aaron Scott-Boddendijk > >>>>>>> > >>>>>>> On Tue, Jun 16, 2020 at 10:15 AM Robert Field < > >>>>> robert.field at oracle.com > > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Make that jps/jstack > >>>>>>>> > >>>>>>>> -R > >>>>>>>> > >>>>>>>> On 2020-06-15 15:12, Robert Field wrote: > >>>>>>>>> Thanks for the report. > >>>>>>>>> > >>>>>>>>> What, if anything, is the Java stack for this thread (jps)? > >>>>>>>>> > >>>>>>>>> -Robert > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 2020-06-15 14:41, Aaron Scott-Boddendijk wrote: > >>>>>>>>>>? ? System: > >>>>>>>>>> * Windows 10 > >>>>>>>>>> * Powershell > >>>>>>>>>> > >>>>>>>>>> When I start JShell, without executing anything, a CPU > core is > >>>>> always > >>>>>>>> at > >>>>>>>>>> 100% (a single thread though I haven't identified what it's > >>>>> doing). > >>>>>>>>>> > >>>>>>>>>> The thread stack is as follows (with only the last two items > >>>>> sometimes > >>>>>>>>>> change - but I don't know the internals of the JVM to > know if > >> this > >>>>>>>>>> useful > >>>>>>>>>> or significant): > >>>>>>>>>> > >>>>>>>>>> ntoskrnl.exe!KeSynchronizeExecution+0x5b46 > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x1c2d > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0xab4 > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x255 > >>>>>>>>>> ntoskrnl.exe!RtlClearBitsEx+0x15a7 > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x3828 > >>>>>>>>>> ntoskrnl.exe!KeSynchronizeExecution+0x3120 > >>>>>>>>>> jvm.dll!c2v_notifyCompilerInliningEvent+0x201797 > >>>>>>>>>> > >>>>>>>>>> The JDK 14 version of JShell does not have this issue but > >> several > >>>>> of > >>>>>>>> the > >>>>>>>>>> recent JDK 15 builds have done this. > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Aaron Scott-Boddendijk > >>>>>>>> > >>>>>>> > >>>>> > >>>> > >> > From plugins at lingocoder.com Wed Jul 15 14:33:02 2020 From: plugins at lingocoder.com (Lingo Coder) Date: Wed, 15 Jul 2020 07:33:02 -0700 Subject: Records are called =?UTF-8?Q?=E2=80=9Emethods=E2=80=9C=20in=20JShell?= Message-ID: <20200715073302.b6ff8ab09a6c540215cae158a90d7e03.994e717af6.wbe@email17.godaddy.com> Thank you Robert, > ?...And send us what it prints...? You'll see below that right after I did `/set format normal typeKind` it still said, ?created *method*...?. I also recorded it. [1] But then right after `/set feedback verbose`, it said ?created *record*?. However, after an `/exit` and a relaunch of `jshell --enable-preview`, it reverted back to ?created *method*...?/?dropped *method*... ?. I _vaguely_ recall creating `mymode` and doing `/set feedback -retain mymode` way back in 2017 when JShell first came out. I think. I'm not 100% sure tho. So I'm guessing I need to do `/set feedback -retain verbose` to permanently get ?created *record*...? Correct? TIA. ---- ... jshell> /set feedback | /set feedback -retain mymode | | Retained feedback modes: | mymode | Available feedback modes: | concise | mymode | normal | silent | verbose jshell> /set format normal typeKind | /set format normal typeKind "class" class | /set format normal typeKind "interface" interface | /set format normal typeKind "enum" enum | /set format normal typeKind "annotation interface" annotation | /set format normal typeKind "record" record jshell> public record ConstExpr(Expr e) implements Expr{} | created method ConstExpr(), however, it cannot be referenced until class Expr is declared jshell> /type | record ConstExpr | which cannot be referenced until class Expr is declared jshell> /types | record ConstExpr | which cannot be referenced until class Expr is declared jshell> /method | void print(boolean) | void print(char) | void print(int) | void print(long) | void print(float) | void print(double) | void print(char s[]) | void print(String) | void print(Object) | void println() | void println(boolean) | void println(char) | void println(int) | void println(long) | void println(float) | void println(double) | void println(char s[]) | void println(String) | void println(Object) | void printf(java.util.Locale,String,Object...) | void printf(String,Object...) jshell> /drop ConstExpr | dropped method ConstExpr() jshell> /set feedback verbose | Feedback mode: verbose jshell> public record ConstExpr(Expr e) implements Expr{} | created record ConstExpr, however, it cannot be referenced until class Expr is declared jshell> /type | record ConstExpr | which cannot be referenced until class Expr is declared jshell> class Expr{} | created class Expr jshell> /types | record ConstExpr | which cannot be referenced until this error is corrected: | interface expected here | public record ConstExpr(Expr e) implements Expr{} | ^--^ | class Expr jshell> /drop Expr | dropped class Expr jshell> interface Expr{} | created interface Expr | update replaced record ConstExpr jshell> /types | record ConstExpr | interface Expr jshell> /drop ConstExpr | dropped record ConstExpr ... ---- [1] https://imgur.com/ePyilYo -------- Original Message -------- Subject: Re:_Records_are_called_?methods?_in_JSh ell From: Robert Field Date: Tue, July 14, 2020 8:07 pm To: Lingo Coder , "kulla-dev at openjdk.java.net" , "jorn.vernee at oracle.com" I have a theory, maybe the following can illuminate... Couple more things to try: /set feedback /set format normal typeKind And send us what it prints. Also, after you have entered: public record ConstExpr(Expr e) implements Expr{} Type: /type and /method Separately, what do they print? Oh, and if you want to try one more thing: /set feedback verbose public record ConstExpr(Expr e) implements Expr{} Sorry, I don't have Windows, but I believe Jan has access. -Robert On 2020-07-14 18:35, Lingo Coder wrote: > Thanks Robert, > >> ?...Can you do: >> jshell --full-version...? > > I did that. It says jshell 15-ea+31-1502 [1] > > What version of Windows are you other guys trying this in? I'm on > Windows 7. > >> ?...I'm guessing you may be using an older JDK...? > As I show in [1] and in earlier screen recordings, I completely > clear my $PATH to confirm that there is no other jshell.exe on > the $PATH. > > I have not installed any JDKs with an installer or anything > like that. For that reason, I rule out anything registry-related. > > I do have an early access release of 14-Valhalla > build 14-valhalla+4-55 on my workstation. But, that was > installed by simply unzipping the archive into a > jdk-14.L.world.Build.14-valhalla+4-55 folder. More importantly, > that build doesn't even have the records nor the sealed types > features. > > I also have GA releases of OpenJDK 12 & 13 in their own folders. > But again, not only are they isolated well out of the way of > the $PATH I run jshell 15 in, they don't even have records and > sealed types functionality. > > If _any_ other JDK were somehow in the $PATH, it would be > surprising if records and sealed types even worked _at all_; > let alone the misnaming as ?methods? issue Right? Please > correct me if I'm wrong? > > > [1] https://imgur.com/cMsAl5f > > -------- Original Message -------- > Subject: Re:_Records_are_called_?methods?_in_JSh ell > From: Robert Field > Date: Tue, July 14, 2020 3:57 pm > To: kulla-dev at openjdk.java.net, jorn.vernee at oracle.com, > plugins at lingocoder.com > > I'm guessing you may be using an older JDK. I get: > jshell> public record ConstExpr(Expr e) implements Expr{} > | created record ConstExpr > > jshell> /drop ConstExpr > | dropped record ConstExpr > > > Can you do: > jshell --full-version > > Thanks, > Robert > > > From sormuras at gmail.com Wed Jul 15 17:23:02 2020 From: sormuras at gmail.com (Christian Stein) Date: Wed, 15 Jul 2020 19:23:02 +0200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> Message-ID: Hi Jan, I reviewed your CR on the webrev and think it resolves the issue. I also +1'ed https://github.com/jline/jline3/issues/552 Two questions: - Does it only happen on Windows? If yes, why? - How can I, without compiling JShell on my own, verify it? Patch that class (*) in my JDK installation temporarily? Cheers, Christian (*) If you could send the compiled class via mail, that would be great. On Wed, Jul 15, 2020 at 2:18 PM Jan Lahoda wrote: > FWIW, I've sent: > https://mail.openjdk.java.net/pipermail/kulla-dev/2020-July/002551.html > > I'd be happy if someone else could verify it solves the issue (given the > upcoming RDP2). > > Thanks, > Jan > > On 15. 07. 20 9:15, Christian Stein wrote: > > JShell 16-ea is affected, too. > > > > Hoping that the fix is as simple as you think, Jan. > > Perhaps, it can make its way into JShell 15 before GA. > > > > Cheers, > > Christian > > > > > > On Tue, Jul 14, 2020 at 9:05 PM Jan Lahoda > > wrote: > > > > Hi, > > > > Thanks for the report and analysis. I've filled: > > https://bugs.openjdk.java.net/browse/JDK-8249367 > > > > I think the issue is in: > > > http://hg.openjdk.java.net/jdk/jdk/file/1e249ca8d585/src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlocking.java#l104 > > > > If the timeout is zero (which it is when invoked from > > StopDetectingInputStream, as it calls the read method without > timeout), > > the method invocation will exit immediately, and it will be > immediately > > called again, etc. > > > > Jan > > > > On 13. 07. 20 6:00, Aaron Scott-Boddendijk wrote: > > > I can confirm the CPU behaves as suggested with a sequence of > > entering and > > > leaving `/edit`. > > > > > > Thanks Christian. > > > > > > -- > > > Aaron Scott-Boddendijk > > > > > > On Mon, Jul 13, 2020 at 3:27 PM Christian Stein > > > wrote: > > > > > >> It's coming from the "while(true)"-loop in > > StopDetectingInputStream.java > > >> [0]. > > >> > > >> Aaron, try to open an external editor within the JShell session > via > > >> > > >> /edit > > >> > > >> The CPU usage should drop immediately to normal levels. > > >> As soon as you close the editor (it's the internal JShell Edit > > Pad for me) > > >> the thread is again eating CPU cycles. Can you confirm this? > > >> > > >> While the editor is opened, the thread waits via > > >> > > >> > > jdk.internal.jshell.tool.StopDetectingInputStream.waitInputNeeded > > line: > > >> 164 > > >> > > >> If no editor is open, the "input.read()" method does never wait: > > >> > > >> > > >> > > > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > > >> line: 66 > > >> > > >> Cheers, > > >> Christian > > >> > > >> [0]: > > >> > > >> > > > https://github.com/openjdk/jdk/blob/faf4d7ccb792b16092c791c0ac77acdd440dbca1/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java#L57-L74 > > >> > > >> On Mon, Jul 13, 2020 at 5:05 AM Christian Stein > > > > > >> wrote: > > >> > > >>> Seems like "read line" from "jline" is underlying reason: > > >>> > > >>> Thread-2 [31] (RUNNABLE) > > >>> > > >>> > > >> > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await > > >>> line: 1749 > > >>> jdk.internal.org.jline.utils.NonBlockingPumpReader.read > > line: 77 > > >>> jdk.internal.org.jline.utils.NonBlockingReader.read line: 57 > > >>> > > >>> > > >> > > > jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read > > >>> line: 104 > > >>> jdk.internal.org.jline.utils.NonBlockingInputStream.read > > line: 36 > > >>> > > >>> > > >> > > > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > > >>> line: 66 > > >>> > > >>> > > >> > > > jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$347/0x0000000800cff330.run > > >>> line: not available > > >>> java.lang.Thread.run line: 832 > > >>> > > >>> It produces a constant high CPU usage and allocates a lot of > > RAM per > > >>> second. > > >>> > > >>> Thread Name Thread State Blocked Count Total CPU Usage > Deadlocked > > >>> Allocated Memory > > >>> Thread-2 RUNNABLE 1 0.06252084028009336 Not Enabled > 196198305136 B > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> On Mon, Jul 13, 2020 at 4:52 AM Christian Stein > > > > > >>> wrote: > > >>> > > >>>> Hi Aaron, > > >>>> > > >>>> I observe the same behaviour of JShell 15 build 30. > > >>>> > > >>>> Here, the 100% CPU workload is split on to 3-4 logical > processors. > > >>>> Grabbed an animated GIF of "jshell.exe -- /exit" session at > [0]. > > >>>> To me, it looks like a loop is running wild, w/o a > > >>>> Thread.yield()/.sleep() call. > > >>>> > > >>>> Microsoft Windows [Version 10.0.19041.329] > > >>>> > > >>>> openjdk 15-ea 2020-09-15 > > >>>> OpenJDK Runtime Environment (build 15-ea+30-1476) > > >>>> OpenJDK 64-Bit Server VM (build 15-ea+30-1476, mixed mode, > > sharing) > > >>>> > > >>>> Cheers, > > >>>> Christian > > >>>> > > >>>> [0]: > > >>>> > > >> > > > https://drive.google.com/file/d/1KOQO5B9WrM4C43K3AB7H9VVPuh9hdCOe/view?usp=sharing > > >>>> > > >>>> > > >>>> On Mon, Jul 13, 2020 at 4:24 AM Aaron Scott-Boddendijk < > > >> talden at gmail.com > > > >>>> wrote: > > >>>> > > >>>>> This still exists in JDK 15 build 31. > > >>>>> > > >>>>> Is any other Windows user able to reproduce this? I have two > > machines, > > >>>>> one > > >>>>> laptop and one desktop that show a CPU thread constantly @ > > 100% just by > > >>>>> starting JShell. For the desktop machine that's not a major > > issue but > > >> for > > >>>>> the laptop this spins up the fans and eats the battery. > > >>>>> > > >>>>> JShell in JDK 14 is fine. > > >>>>> > > >>>>> I've yet to hear of any other user confirming this issue. > > >>>>> > > >>>>> -- > > >>>>> Aaron Scott-Boddendijk > > >>>>> > > >>>>> > > >>>>> On Fri, Jun 26, 2020 at 2:00 PM Aaron Scott-Boddendijk < > > >> talden at gmail.com > > >>>>>> > > >>>>> wrote: > > >>>>> > > >>>>>> Just confirming that: > > >>>>>> > > >>>>>> * This still exists in JDK 15 build 29 > > >>>>>> * Occurs on multiple unrelated Windows 10 machines with > > differing > > >> major > > >>>>>> versions of the OS. > > >>>>>> * Does not occur in JDK 14.01 on these machines (OpenJDK > 64-Bit > > >> Server > > >>>>> VM > > >>>>>> Zulu14.28+21-CA) > > >>>>>> * Does not appear to occur on Linux > > >>>>>> > > >>>>>> -- > > >>>>>> Aaron Scott-Boddendijk > > >>>>>> > > >>>>>> > > >>>>>> On Tue, Jun 16, 2020 at 11:16 AM Aaron Scott-Boddendijk < > > >>>>> talden at gmail.com > > > >>>>>> wrote: > > >>>>>> > > >>>>>>> This is the thread-dump from the JVM that VisualVM sees as > > using a > > >>>>> core... > > >>>>>>> > > >>>>>>> 2020-06-16 11:07:35 > > >>>>>>> Full thread dump OpenJDK 64-Bit Server VM (15-ea+27-1372 > > mixed mode, > > >>>>>>> sharing): > > >>>>>>> > > >>>>>>> Threads class SMR info: > > >>>>>>> _java_thread_list=0x000001e34a6040f0, length=23, elements={ > > >>>>>>> 0x000001e31c1a1dc0, 0x000001e349035ee0, 0x000001e349037250, > > >>>>>>> 0x000001e349058ae0, > > >>>>>>> 0x000001e34905c5b0, 0x000001e34905f710, 0x000001e3490603f0, > > >>>>>>> 0x000001e349065140, > > >>>>>>> 0x000001e34906d620, 0x000001e349b36a20, 0x000001e349b8c690, > > >>>>>>> 0x000001e349da3400, > > >>>>>>> 0x000001e349daa7c0, 0x000001e349dbb640, 0x000001e34a141140, > > >>>>>>> 0x000001e349d555c0, > > >>>>>>> 0x000001e34b07f030, 0x000001e34a461c90, 0x000001e34a45fae0, > > >>>>>>> 0x000001e34a45ffb0, > > >>>>>>> 0x000001e34a4617c0, 0x000001e34a462160, 0x000001e34a45f610 > > >>>>>>> } > > >>>>>>> > > >>>>>>> "main" #1 prio=5 os_prio=0 cpu=1078.13ms elapsed=341.81s > > >>>>>>> tid=0x000001e31c1a1dc0 nid=0x16b0 in Object.wait() > > >>>>> [0x000000340d9fe000] > > >>>>>>> java.lang.Thread.State: TIMED_WAITING (on object > monitor) > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native > > Method) > > >>>>>>> - waiting on > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 15-ea > > >>>>>>> /NonBlockingInputStreamImpl.java:139) > > >>>>>>> - locked <0x000000060fe87338> (a > > >>>>>>> jdk.internal.jshell.tool.ConsoleIOContext$1) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > > >>>>>>> /NonBlockingInputStream.java:62) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 15-ea > > >>>>>>> /NonBlocking.java:168) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > > >>>>>>> /NonBlockingReader.java:57) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 15-ea > > >>>>>>> /BindingReader.java:160) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > > >>>>>>> /BindingReader.java:110) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > > >>>>>>> /BindingReader.java:61) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 15-ea > > >>>>>>> /LineReaderImpl.java:913) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 15-ea > > >>>>>>> /LineReaderImpl.java:946) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 15-ea > > >>>>>>> /ConsoleIOContext.java:154) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > > >>>>>>> /LineReaderImpl.java:637) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > > >>>>>>> /LineReaderImpl.java:454) > > >>>>>>> at > > >>>>>>> > > jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 15-ea > > >>>>>>> /ConsoleIOContext.java:229) > > >>>>>>> at > > >>>>> jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 15-ea > > >>>>>>> /JShellTool.java:1254) > > >>>>>>> at > > jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 15-ea > > >>>>>>> /JShellTool.java:1190) > > >>>>>>> at > > >> jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 15-ea > > >>>>>>> /JShellTool.java:991) > > >>>>>>> at > > >>>>>>> > > jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 15-ea > > >>>>>>> /JShellToolBuilder.java:254) > > >>>>>>> at > > >>>>>>> > > jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 15-ea > > >>>>>>> /JShellToolProvider.java:120) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "Reference Handler" #2 daemon prio=10 os_prio=2 cpu=0.00ms > > >>>>>>> elapsed=341.79s tid=0x000001e349035ee0 nid=0x13fc waiting on > > >> condition > > >>>>>>> [0x000000340e0fe000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> at > > >>>>>>> > > java.lang.ref.Reference.waitForReferencePendingList(java.base at 15-ea > > >>>>> /Native > > >>>>>>> Method) > > >>>>>>> at > > >>>>>>> > > java.lang.ref.Reference.processPendingReferences(java.base at 15-ea > > >>>>>>> /Reference.java:241) > > >>>>>>> at > > >>>>> java.lang.ref.Reference$ReferenceHandler.run(java.base at 15-ea > > >>>>>>> /Reference.java:213) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms > > elapsed=341.79s > > >>>>>>> tid=0x000001e349037250 nid=0x2a60 in Object.wait() > > >>>>> [0x000000340e1fe000] > > >>>>>>> java.lang.Thread.State: WAITING (on object monitor) > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native > > Method) > > >>>>>>> - waiting on <0x0000000601400bc0> (a > > >>>>>>> java.lang.ref.ReferenceQueue$Lock) > > >>>>>>> at > java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > > >>>>>>> /ReferenceQueue.java:155) > > >>>>>>> - locked <0x0000000601400bc0> (a > > >>>>>>> java.lang.ref.ReferenceQueue$Lock) > > >>>>>>> at > java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > > >>>>>>> /ReferenceQueue.java:176) > > >>>>>>> at > > >> java.lang.ref.Finalizer$FinalizerThread.run(java.base at 15-ea > > >>>>>>> /Finalizer.java:170) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms > > >>>>> elapsed=341.78s > > >>>>>>> tid=0x000001e349058ae0 nid=0x35c8 runnable > > [0x0000000000000000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "Attach Listener" #5 daemon prio=5 os_prio=2 cpu=125.00ms > > >>>>> elapsed=341.78s > > >>>>>>> tid=0x000001e34905c5b0 nid=0x3e0c waiting on condition > > >>>>> [0x0000000000000000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "Service Thread" #6 daemon prio=9 os_prio=0 cpu=0.00ms > > >> elapsed=341.78s > > >>>>>>> tid=0x000001e34905f710 nid=0x398c runnable > > [0x0000000000000000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "C2 CompilerThread0" #7 daemon prio=9 os_prio=2 > cpu=1781.25ms > > >>>>>>> elapsed=341.78s tid=0x000001e3490603f0 nid=0xcf0 waiting on > > >> condition > > >>>>>>> [0x0000000000000000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> No compile task > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "C1 CompilerThread0" #10 daemon prio=9 os_prio=2 > cpu=765.63ms > > >>>>>>> elapsed=341.78s tid=0x000001e349065140 nid=0x3e54 waiting on > > >> condition > > >>>>>>> [0x0000000000000000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> No compile task > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "Sweeper thread" #11 daemon prio=9 os_prio=2 cpu=0.00ms > > >>>>> elapsed=341.78s > > >>>>>>> tid=0x000001e34906d620 nid=0x38bc runnable > > [0x0000000000000000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "Notification Thread" #12 daemon prio=9 os_prio=0 cpu=0.00ms > > >>>>>>> elapsed=341.76s tid=0x000001e349b36a20 nid=0x49b8 runnable > > >>>>>>> [0x0000000000000000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "Common-Cleaner" #13 daemon prio=8 os_prio=1 cpu=0.00ms > > >>>>> elapsed=341.75s > > >>>>>>> tid=0x000001e349b8c690 nid=0x26e4 in Object.wait() > > >>>>> [0x000000340eaff000] > > >>>>>>> java.lang.Thread.State: TIMED_WAITING (on object > monitor) > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native > > Method) > > >>>>>>> - waiting on > > >>>>>>> at > java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > > >>>>>>> /ReferenceQueue.java:155) > > >>>>>>> - locked <0x0000000601401a78> (a > > >>>>>>> java.lang.ref.ReferenceQueue$Lock) > > >>>>>>> at jdk.internal.ref.CleanerImpl.run(java.base at 15-ea > > >>>>>>> /CleanerImpl.java:148) > > >>>>>>> at > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > >>>>>>> at > > jdk.internal.misc.InnocuousThread.run(java.base at 15-ea > > >>>>>>> /InnocuousThread.java:134) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "JDI Internal Event Handler" #17 daemon prio=5 os_prio=0 > > cpu=15.63ms > > >>>>>>> elapsed=341.39s tid=0x000001e349da3400 nid=0x68 in > > Object.wait() > > >>>>>>> [0x000000340effe000] > > >>>>>>> java.lang.Thread.State: WAITING (on object monitor) > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native > > Method) > > >>>>>>> - waiting on > > >>>>>>> at > > java.lang.Object.wait(java.base at 15-ea/Object.java:321) > > >>>>>>> at > > >>>>> > com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > > >>>>>>> /EventQueueImpl.java:190) > > >>>>>>> - locked <0x000000060154b630> (a > > >>>>> com.sun.tools.jdi.EventQueueImpl) > > >>>>>>> at > > >>>>> com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 15-ea > > >>>>>>> /EventQueueImpl.java:125) > > >>>>>>> at > > com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 15-ea > > >>>>>>> /InternalEventHandler.java:61) > > >>>>>>> at > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "JDI Target VM Interface" #16 daemon prio=5 os_prio=0 > > cpu=46.88ms > > >>>>>>> elapsed=341.39s tid=0x000001e349daa7c0 nid=0x3d04 runnable > > >>>>>>> [0x000000340f0fe000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> at > > sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native > > >>>>>>> Method) > > >>>>>>> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > > >>>>>>> /SocketDispatcher.java:46) > > >>>>>>> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:261) > > >>>>>>> at > sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:312) > > >>>>>>> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:350) > > >>>>>>> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:803) > > >>>>>>> at > > java.net.Socket$SocketInputStream.read(java.base at 15-ea > > >>>>>>> /Socket.java:981) > > >>>>>>> at > > java.net.Socket$SocketInputStream.read(java.base at 15-ea > > >>>>>>> /Socket.java:976) > > >>>>>>> at > > >> com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 15-ea > > >>>>>>> /SocketConnection.java:82) > > >>>>>>> - locked <0x000000060154b998> (a java.lang.Object) > > >>>>>>> at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 15-ea > > >>>>>>> /TargetVM.java:124) > > >>>>>>> at > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - <0x0000000601577110> (a > > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > > >>>>>>> > > >>>>>>> "event-handler" #18 daemon prio=5 os_prio=0 cpu=0.00ms > > >> elapsed=341.38s > > >>>>>>> tid=0x000001e349dbb640 nid=0x203c in Object.wait() > > >>>>> [0x000000340edfe000] > > >>>>>>> java.lang.Thread.State: WAITING (on object monitor) > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native > > Method) > > >>>>>>> - waiting on > > >>>>>>> at > > java.lang.Object.wait(java.base at 15-ea/Object.java:321) > > >>>>>>> at > > >>>>> > com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > > >>>>>>> /EventQueueImpl.java:190) > > >>>>>>> - locked <0x000000060154bc28> (a > > >>>>> com.sun.tools.jdi.EventQueueImpl) > > >>>>>>> at > > com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > > >>>>>>> /EventQueueImpl.java:97) > > >>>>>>> at > > com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > > >>>>>>> /EventQueueImpl.java:83) > > >>>>>>> at > > jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 15-ea > > >>>>>>> /JdiEventHandler.java:79) > > >>>>>>> at > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "output reader" #19 daemon prio=5 os_prio=0 cpu=0.00ms > > >> elapsed=341.31s > > >>>>>>> tid=0x000001e34a141140 nid=0x49c0 runnable > > [0x000000340eeff000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> at > > sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native > > >>>>>>> Method) > > >>>>>>> at sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > > >>>>>>> /SocketDispatcher.java:46) > > >>>>>>> at sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:261) > > >>>>>>> at > sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:312) > > >>>>>>> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:350) > > >>>>>>> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:803) > > >>>>>>> at > > java.net.Socket$SocketInputStream.read(java.base at 15-ea > > >>>>>>> /Socket.java:981) > > >>>>>>> at > > java.net.Socket$SocketInputStream.read(java.base at 15-ea > > >>>>>>> /Socket.java:976) > > >>>>>>> at java.io.FilterInputStream.read(java.base at 15-ea > > >>>>>>> /FilterInputStream.java:82) > > >>>>>>> at > > >> jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 15-ea > > >>>>>>> /DemultiplexInput.java:58) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - <0x0000000601553510> (a > > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > > >>>>>>> > > >>>>>>> "Thread-0" #21 daemon prio=5 os_prio=0 cpu=312.50ms > > elapsed=341.22s > > >>>>>>> tid=0x000001e349d555c0 nid=0x4d88 waiting on condition > > >>>>> [0x000000340f1fe000] > > >>>>>>> java.lang.Thread.State: WAITING (parking) > > >>>>>>> at > > jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native > > >>>>> Method) > > >>>>>>> - parking to wait for <0x0000000601550fc0> (a > > >>>>>>> > > >> > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > > >>>>>>> at > > >> java.util.concurrent.locks.LockSupport.park(java.base at 15-ea > > >>>>>>> /LockSupport.java:341) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 15-ea > > >>>>>>> /AbstractQueuedSynchronizer.java:505) > > >>>>>>> at > > >>>>> java.util.concurrent.ForkJoinPool.managedBlock(java.base at 15-ea > > >>>>>>> /ForkJoinPool.java:3137) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > > >>>>>>> /AbstractQueuedSynchronizer.java:1614) > > >>>>>>> at > > >>>>> java.util.concurrent.LinkedBlockingQueue.take(java.base at 15-ea > > >>>>>>> /LinkedBlockingQueue.java:435) > > >>>>>>> at > > >>>>> > java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > > >>>>>>> /ThreadPoolExecutor.java:1056) > > >>>>>>> at > > >>>>>>> > > java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > > >>>>>>> /ThreadPoolExecutor.java:1116) > > >>>>>>> at > > >>>>>>> > > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > > >>>>>>> /ThreadPoolExecutor.java:630) > > >>>>>>> at > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "Thread-2" #23 daemon prio=5 os_prio=0 cpu=338859.38ms > > >> elapsed=340.58s > > >>>>>>> tid=0x000001e34b07f030 nid=0xac0 runnable > [0x000000340f3fe000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > > >>>>>>> /AbstractQueuedSynchronizer.java:1749) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.utils.NonBlockingPumpReader.read(jdk.internal.le at 15-ea > > >>>>>>> /NonBlockingPumpReader.java:77) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > > >>>>>>> /NonBlockingReader.java:57) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read(jdk.internal.le at 15-ea > > >>>>>>> /NonBlocking.java:104) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > > >>>>>>> /NonBlockingInputStream.java:36) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 15-ea > > >>>>>>> /StopDetectingInputStream.java:66) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$410/0x0000000800d2eb28.run(jdk.jshell at 15-ea > > >>>>> /Unknown > > >>>>>>> Source) > > >>>>>>> at > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - <0x00000006028b4318> (a > > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > > >>>>>>> > > >>>>>>> "WindowsStreamPump" #25 daemon prio=5 os_prio=0 cpu=0.00ms > > >>>>>>> elapsed=340.53s tid=0x000001e34a461c90 nid=0x3688 runnable > > >>>>>>> [0x000000340f4fe000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.terminal.impl.jna.win.Kernel32Impl.WaitForSingleObject(jdk.internal.le at 15-ea > > >>>>> /Native > > >>>>>>> Method) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.readConsoleInput(jdk.internal.le at 15-ea > > >>>>>>> /JnaWinSysTerminal.java:185) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.processConsoleInput(jdk.internal.le at 15-ea > > >>>>>>> /JnaWinSysTerminal.java:108) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal.pump(jdk.internal.le at 15-ea > > >>>>>>> /AbstractWindowsTerminal.java:465) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal$$Lambda$417/0x0000000800d310f8.run(jdk.internal.le at 15-ea > > >>>>> /Unknown > > >>>>>>> Source) > > >>>>>>> at > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "null non blocking reader thread" #26 daemon prio=5 > os_prio=0 > > >>>>> cpu=0.00ms > > >>>>>>> elapsed=340.26s tid=0x000001e34a45fae0 nid=0x488 in > > Object.wait() > > >>>>>>> [0x000000340f6ff000] > > >>>>>>> java.lang.Thread.State: WAITING (on object monitor) > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native > > Method) > > >>>>>>> - waiting on > > >>>>>>> at > > java.lang.Object.wait(java.base at 15-ea/Object.java:321) > > >>>>>>> at > > >>>>>>> > > >>>>> > > > jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 15-ea > > >>>>>>> /StopDetectingInputStream.java:98) > > >>>>>>> - locked <0x0000000601e2b650> (a > > >>>>>>> jdk.internal.jshell.tool.StopDetectingInputStream) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 15-ea > > >>>>>>> /NonBlockingInputStreamImpl.java:216) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$584/0x0000000800d4f088.run(jdk.internal.le at 15-ea > > >>>>> /Unknown > > >>>>>>> Source) > > >>>>>>> at > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "RMI TCP Accept-0" #27 daemon prio=5 os_prio=0 cpu=0.00ms > > >>>>> elapsed=180.89s > > >>>>>>> tid=0x000001e34a45ffb0 nid=0x45f0 runnable > > [0x000000340d8fe000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> at sun.nio.ch.Net.accept(java.base at 15-ea/Native > > Method) > > >>>>>>> at sun.nio.ch.NioSocketImpl.accept(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:755) > > >>>>>>> at java.net.ServerSocket.implAccept(java.base at 15-ea > > >>>>>>> /ServerSocket.java:684) > > >>>>>>> at > > java.net.ServerSocket.platformImplAccept(java.base at 15-ea > > >>>>>>> /ServerSocket.java:650) > > >>>>>>> at java.net.ServerSocket.implAccept(java.base at 15-ea > > >>>>>>> /ServerSocket.java:626) > > >>>>>>> at java.net.ServerSocket.implAccept(java.base at 15-ea > > >>>>>>> /ServerSocket.java:583) > > >>>>>>> at java.net.ServerSocket.accept(java.base at 15-ea > > >>>>>>> /ServerSocket.java:540) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(jdk.management.agent at 15-ea > > >>>>>>> /LocalRMIServerSocketFactory.java:52) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi at 15-ea > > >>>>>>> /TCPTransport.java:413) > > >>>>>>> at > > >>>>>>> > > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi at 15-ea > > >>>>>>> /TCPTransport.java:377) > > >>>>>>> at > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - <0x0000000602e53118> (a > > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > > >>>>>>> > > >>>>>>> "RMI TCP Connection(1)-10.0.201.131" #28 daemon prio=5 > > os_prio=0 > > >>>>>>> cpu=437.50ms elapsed=180.87s tid=0x000001e34a4617c0 > nid=0x4790 > > >>>>> runnable > > >>>>>>> [0x000000340fbfe000] > > >>>>>>> java.lang.Thread.State: RUNNABLE > > >>>>>>> at sun.nio.ch.Net.poll(java.base at 15-ea/Native > Method) > > >>>>>>> at sun.nio.ch.NioSocketImpl.park(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:181) > > >>>>>>> at > sun.nio.ch.NioSocketImpl.timedRead(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:285) > > >>>>>>> at > sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:309) > > >>>>>>> at sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:350) > > >>>>>>> at sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > > >>>>>>> /NioSocketImpl.java:803) > > >>>>>>> at > > java.net.Socket$SocketInputStream.read(java.base at 15-ea > > >>>>>>> /Socket.java:981) > > >>>>>>> at java.io.BufferedInputStream.fill(java.base at 15-ea > > >>>>>>> /BufferedInputStream.java:244) > > >>>>>>> at java.io.BufferedInputStream.read(java.base at 15-ea > > >>>>>>> /BufferedInputStream.java:263) > > >>>>>>> - locked <0x0000000602e19470> (a > > >> java.io.BufferedInputStream) > > >>>>>>> at java.io.FilterInputStream.read(java.base at 15-ea > > >>>>>>> /FilterInputStream.java:82) > > >>>>>>> at > > >>>>>>> > > sun.rmi.transport.tcp.TCPTransport.handleMessages(java.rmi at 15-ea > > >>>>>>> /TCPTransport.java:569) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(java.rmi at 15-ea > > >>>>>>> /TCPTransport.java:828) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(java.rmi at 15-ea > > >>>>>>> /TCPTransport.java:705) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$686/0x0000000800da3998.run(java.rmi at 15-ea > > >>>>> /Unknown > > >>>>>>> Source) > > >>>>>>> at > > >>>>>>> > > java.security.AccessController.executePrivileged(java.base at 15-ea > > >>>>>>> /AccessController.java:753) > > >>>>>>> at > > >> java.security.AccessController.doPrivileged(java.base at 15-ea > > >>>>>>> /AccessController.java:391) > > >>>>>>> at > > >>>>>>> > > >>>>> > > > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(java.rmi at 15-ea > > >>>>>>> /TCPTransport.java:704) > > >>>>>>> at > > >>>>>>> > > java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > > >>>>>>> /ThreadPoolExecutor.java:1130) > > >>>>>>> at > > >>>>>>> > > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > > >>>>>>> /ThreadPoolExecutor.java:630) > > >>>>>>> at > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - <0x0000000602e19708> (a > > >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker) > > >>>>>>> - <0x0000000602e59038> (a > > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > > >>>>>>> > > >>>>>>> "RMI Scheduler(0)" #29 daemon prio=5 os_prio=0 cpu=0.00ms > > >>>>> elapsed=180.86s > > >>>>>>> tid=0x000001e34a462160 nid=0x1df0 waiting on condition > > >>>>> [0x000000340fcfe000] > > >>>>>>> java.lang.Thread.State: TIMED_WAITING (parking) > > >>>>>>> at > > jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native > > >>>>> Method) > > >>>>>>> - parking to wait for <0x0000000602e1af00> (a > > >>>>>>> > > >> > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > > >>>>>>> at > > >>>>>>> > > java.util.concurrent.locks.LockSupport.parkNanos(java.base at 15-ea > > >>>>>>> /LockSupport.java:252) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 15-ea > > >>>>>>> /AbstractQueuedSynchronizer.java:1661) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > > >>>>>>> /ScheduledThreadPoolExecutor.java:1182) > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > > >>>>>>> /ScheduledThreadPoolExecutor.java:899) > > >>>>>>> at > > >>>>> > java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > > >>>>>>> /ThreadPoolExecutor.java:1056) > > >>>>>>> at > > >>>>>>> > > java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > > >>>>>>> /ThreadPoolExecutor.java:1116) > > >>>>>>> at > > >>>>>>> > > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > > >>>>>>> /ThreadPoolExecutor.java:630) > > >>>>>>> at > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "JMX server connection timeout 30" #30 daemon prio=5 > os_prio=0 > > >>>>> cpu=0.00ms > > >>>>>>> elapsed=180.86s tid=0x000001e34a45f610 nid=0x2fe8 in > > Object.wait() > > >>>>>>> [0x000000340fdff000] > > >>>>>>> java.lang.Thread.State: TIMED_WAITING (on object > monitor) > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea/Native > > Method) > > >>>>>>> - waiting on > > >>>>>>> at > > >>>>>>> > > >>>>> > > >> > > > com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(java.management at 15-ea > > >>>>>>> /ServerCommunicatorAdmin.java:171) > > >>>>>>> - locked <0x0000000602e1ca08> (a [I) > > >>>>>>> at > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > >>>>>>> > > >>>>>>> Locked ownable synchronizers: > > >>>>>>> - None > > >>>>>>> > > >>>>>>> "VM Thread" os_prio=2 cpu=515.63ms elapsed=341.79s > > >>>>> tid=0x000001e349031eb0 > > >>>>>>> nid=0x540 runnable > > >>>>>>> > > >>>>>>> "GC Thread#0" os_prio=2 cpu=328.13ms elapsed=341.80s > > >>>>>>> tid=0x000001e31c218710 nid=0x19e8 runnable > > >>>>>>> > > >>>>>>> "GC Thread#1" os_prio=2 cpu=265.63ms elapsed=341.53s > > >>>>>>> tid=0x000001e349b353d0 nid=0x1cc4 runnable > > >>>>>>> > > >>>>>>> "GC Thread#2" os_prio=2 cpu=218.75ms elapsed=340.37s > > >>>>>>> tid=0x000001e349b350a0 nid=0x1ddc runnable > > >>>>>>> > > >>>>>>> "GC Thread#3" os_prio=2 cpu=187.50ms elapsed=338.82s > > >>>>>>> tid=0x000001e349b35700 nid=0x4a48 runnable > > >>>>>>> > > >>>>>>> "GC Thread#4" os_prio=2 cpu=140.63ms elapsed=338.82s > > >>>>>>> tid=0x000001e349b340b0 nid=0x32e8 runnable > > >>>>>>> > > >>>>>>> "GC Thread#5" os_prio=2 cpu=156.25ms elapsed=338.82s > > >>>>>>> tid=0x000001e349b35a30 nid=0x38cc runnable > > >>>>>>> > > >>>>>>> "GC Thread#6" os_prio=2 cpu=171.88ms elapsed=338.82s > > >>>>>>> tid=0x000001e349b35d60 nid=0x3ed0 runnable > > >>>>>>> > > >>>>>>> "G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=341.80s > > >>>>>>> tid=0x000001e31c229930 nid=0x21c runnable > > >>>>>>> > > >>>>>>> "G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=341.80s > > >>>>> tid=0x000001e31c22a5a0 > > >>>>>>> nid=0x3920 runnable > > >>>>>>> > > >>>>>>> "G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=341.80s > > >>>>> tid=0x000001e31c253f10 > > >>>>>>> nid=0x1f84 runnable > > >>>>>>> > > >>>>>>> "G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms > elapsed=341.80s > > >>>>>>> tid=0x000001e31c254b90 nid=0x27ac runnable > > >>>>>>> > > >>>>>>> "VM Periodic Task Thread" os_prio=2 cpu=15.63ms > elapsed=341.76s > > >>>>>>> tid=0x000001e349b39710 nid=0x838 waiting on condition > > >>>>>>> > > >>>>>>> JNI global refs: 33, weak refs: 0 > > >>>>>>> > > >>>>>>> -- > > >>>>>>> Aaron Scott-Boddendijk > > >>>>>>> > > >>>>>>> On Tue, Jun 16, 2020 at 10:15 AM Robert Field < > > >>>>> robert.field at oracle.com > > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>>> Make that jps/jstack > > >>>>>>>> > > >>>>>>>> -R > > >>>>>>>> > > >>>>>>>> On 2020-06-15 15:12, Robert Field wrote: > > >>>>>>>>> Thanks for the report. > > >>>>>>>>> > > >>>>>>>>> What, if anything, is the Java stack for this thread > (jps)? > > >>>>>>>>> > > >>>>>>>>> -Robert > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On 2020-06-15 14:41, Aaron Scott-Boddendijk wrote: > > >>>>>>>>>> System: > > >>>>>>>>>> * Windows 10 > > >>>>>>>>>> * Powershell > > >>>>>>>>>> > > >>>>>>>>>> When I start JShell, without executing anything, a CPU > > core is > > >>>>> always > > >>>>>>>> at > > >>>>>>>>>> 100% (a single thread though I haven't identified what > it's > > >>>>> doing). > > >>>>>>>>>> > > >>>>>>>>>> The thread stack is as follows (with only the last two > items > > >>>>> sometimes > > >>>>>>>>>> change - but I don't know the internals of the JVM to > > know if > > >> this > > >>>>>>>>>> useful > > >>>>>>>>>> or significant): > > >>>>>>>>>> > > >>>>>>>>>> ntoskrnl.exe!KeSynchronizeExecution+0x5b46 > > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x1c2d > > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0xab4 > > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x255 > > >>>>>>>>>> ntoskrnl.exe!RtlClearBitsEx+0x15a7 > > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x3828 > > >>>>>>>>>> ntoskrnl.exe!KeSynchronizeExecution+0x3120 > > >>>>>>>>>> jvm.dll!c2v_notifyCompilerInliningEvent+0x201797 > > >>>>>>>>>> > > >>>>>>>>>> The JDK 14 version of JShell does not have this issue but > > >> several > > >>>>> of > > >>>>>>>> the > > >>>>>>>>>> recent JDK 15 builds have done this. > > >>>>>>>>>> > > >>>>>>>>>> -- > > >>>>>>>>>> Aaron Scott-Boddendijk > > >>>>>>>> > > >>>>>>> > > >>>>> > > >>>> > > >> > > > From robert.field at oracle.com Wed Jul 15 18:01:12 2020 From: robert.field at oracle.com (Robert Field) Date: Wed, 15 Jul 2020 11:01:12 -0700 Subject: RFR: JDK-8249367: JShell uses 100% of one core all the time In-Reply-To: References: Message-ID: <8eba70cb-794b-84f5-bfbc-a45018e247cb@oracle.com> Thanks Jan! +1 -Robert On 7/15/20 5:15 AM, Jan Lahoda wrote: > Hi, > > JShell consumes basically a 100% of one CPU thread on Windows all the > time while waiting for a user input. The reason is that: > -JShell's StopDetectingInputStream invokes "read()" method? on > NonBlockingReaderInputStream (without a timeout, which is an addition > of JLine's non blocking streams and readers), which is converted to a > read with timeout 0. The NonBlockingReaderInputStream then delegates > to NonBlockingPumpReader, using its read method with timeout 0. But > with timeout zero, this particular reader returns immediately, and > because there was no input, and no timeout set to > NonBlockingReaderInputStream, it will loop and ask the > NonBlockingPumpReader again, and ultimately > NonBlockingReaderInputStream.read spins in a loop. > > The ultimate problem is, I believe, in NonBlockingPumpReader, which > should not return immediately for timeout 0 (other non blocking > streams/readers wait indefinitely for input for timeout 0). I have > filled a bug to JLine for this: > https://github.com/jline/jline3/issues/552 > > But, mostly as a workaround, I suggest that StopDetectingInputStream > uses a timeout while reading from non blocking streams. That should be > safe, and we can revert to the current state when the above bug is fixed. > > Proposed patch: > http://cr.openjdk.java.net/~jlahoda/8249367/webrev.00/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8249367 > > What do you think? > > Thanks, > ??? Jan From robert.field at oracle.com Wed Jul 15 18:09:23 2020 From: robert.field at oracle.com (Robert Field) Date: Wed, 15 Jul 2020 11:09:23 -0700 Subject: =?UTF-8?Q?Re=3a_Records_are_called_=e2=80=9emethods=e2=80=9c_in_JSh?= =?UTF-8?Q?ell?= In-Reply-To: <20200715073302.b6ff8ab09a6c540215cae158a90d7e03.994e717af6.wbe@email17.godaddy.com> References: <20200715073302.b6ff8ab09a6c540215cae158a90d7e03.994e717af6.wbe@email17.godaddy.com> Message-ID: OK! There is the root of your issue.? You have your own mode, but it probably hasn't been updated for records.? You aren't using normal mode so, instead, show the output of: /set format mymode typeKind Hopefully, /set format mymode typeKind "record" record Will fix your issue. -Robert On 7/15/20 7:33 AM, Lingo Coder wrote: > Thank you Robert, > >> ?...And send us what it prints...? > You'll see below that right after I did `/set format normal typeKind` > it still said, ?created *method*...?. I also recorded it. [1] > > But then right after `/set feedback verbose`, it said ?created > *record*?. > > However, after an `/exit` and a relaunch of `jshell --enable-preview`, > it > reverted back to ?created *method*...?/?dropped *method*... ?. > > I _vaguely_ recall creating `mymode` and doing `/set feedback -retain > mymode` > way back in 2017 when JShell first came out. I think. I'm not 100% sure > tho. > So I'm guessing I need to do `/set feedback -retain verbose` to > permanently > get ?created *record*...? Correct? > > TIA. > > ---- > ... > > jshell> /set feedback > | /set feedback -retain mymode > | > | Retained feedback modes: > | mymode > | Available feedback modes: > | concise > | mymode > | normal > | silent > | verbose > > jshell> /set format normal typeKind > | /set format normal typeKind "class" class > | /set format normal typeKind "interface" interface > | /set format normal typeKind "enum" enum > | /set format normal typeKind "annotation interface" annotation > | /set format normal typeKind "record" record > > jshell> public record ConstExpr(Expr e) implements Expr{} > | created method ConstExpr(), however, it cannot be referenced until > class Expr is declared > > jshell> /type > | record ConstExpr > | which cannot be referenced until class Expr is declared > > jshell> /types > | record ConstExpr > | which cannot be referenced until class Expr is declared > > jshell> /method > | void print(boolean) > | void print(char) > | void print(int) > | void print(long) > | void print(float) > | void print(double) > | void print(char s[]) > | void print(String) > | void print(Object) > | void println() > | void println(boolean) > | void println(char) > | void println(int) > | void println(long) > | void println(float) > | void println(double) > | void println(char s[]) > | void println(String) > | void println(Object) > | void printf(java.util.Locale,String,Object...) > | void printf(String,Object...) > > jshell> /drop ConstExpr > | dropped method ConstExpr() > > jshell> /set feedback verbose > | Feedback mode: verbose > > jshell> public record ConstExpr(Expr e) implements Expr{} > | created record ConstExpr, however, it cannot be referenced until > class Expr is declared > > jshell> /type > | record ConstExpr > | which cannot be referenced until class Expr is declared > > jshell> class Expr{} > | created class Expr > > jshell> /types > | record ConstExpr > | which cannot be referenced until this error is corrected: > | interface expected here > | public record ConstExpr(Expr e) implements Expr{} > | ^--^ > | class Expr > > jshell> /drop Expr > | dropped class Expr > > jshell> interface Expr{} > | created interface Expr > | update replaced record ConstExpr > > jshell> /types > | record ConstExpr > | interface Expr > > jshell> /drop ConstExpr > | dropped record ConstExpr > > ... > > ---- > [1] https://imgur.com/ePyilYo > > > > -------- Original Message -------- > Subject: Re:_Records_are_called_?methods?_in_JSh ell > From: Robert Field > Date: Tue, July 14, 2020 8:07 pm > To: Lingo Coder , > "kulla-dev at openjdk.java.net" , > "jorn.vernee at oracle.com" > > I have a theory, maybe the following can illuminate... > > Couple more things to try: > > /set feedback > > /set format normal typeKind > > And send us what it prints. > > Also, after you have entered: > > public record ConstExpr(Expr e) implements Expr{} > > Type: > > /type > > and > > /method > > Separately, what do they print? > > Oh, and if you want to try one more thing: > > /set feedback verbose > > public record ConstExpr(Expr e) implements Expr{} > > Sorry, I don't have Windows, but I believe Jan has access. > > -Robert > > > On 2020-07-14 18:35, Lingo Coder wrote: >> Thanks Robert, >> >>> ?...Can you do: >>> jshell --full-version...? >> I did that. It says jshell 15-ea+31-1502 [1] >> >> What version of Windows are you other guys trying this in? I'm on >> Windows 7. >> >>> ?...I'm guessing you may be using an older JDK...? >> As I show in [1] and in earlier screen recordings, I completely >> clear my $PATH to confirm that there is no other jshell.exe on >> the $PATH. >> >> I have not installed any JDKs with an installer or anything >> like that. For that reason, I rule out anything registry-related. >> >> I do have an early access release of 14-Valhalla >> build 14-valhalla+4-55 on my workstation. But, that was >> installed by simply unzipping the archive into a >> jdk-14.L.world.Build.14-valhalla+4-55 folder. More importantly, >> that build doesn't even have the records nor the sealed types >> features. >> >> I also have GA releases of OpenJDK 12 & 13 in their own folders. >> But again, not only are they isolated well out of the way of >> the $PATH I run jshell 15 in, they don't even have records and >> sealed types functionality. >> >> If _any_ other JDK were somehow in the $PATH, it would be >> surprising if records and sealed types even worked _at all_; >> let alone the misnaming as ?methods? issue Right? Please >> correct me if I'm wrong? >> >> >> [1] https://imgur.com/cMsAl5f >> >> -------- Original Message -------- >> Subject: Re:_Records_are_called_?methods?_in_JSh ell >> From: Robert Field >> Date: Tue, July 14, 2020 3:57 pm >> To: kulla-dev at openjdk.java.net, jorn.vernee at oracle.com, >> plugins at lingocoder.com >> >> I'm guessing you may be using an older JDK. I get: >> jshell> public record ConstExpr(Expr e) implements Expr{} >> | created record ConstExpr >> >> jshell> /drop ConstExpr >> | dropped record ConstExpr >> >> >> Can you do: >> jshell --full-version >> >> Thanks, >> Robert >> >> >> From plugins at lingocoder.com Wed Jul 15 20:47:07 2020 From: plugins at lingocoder.com (Lingo Coder) Date: Wed, 15 Jul 2020 13:47:07 -0700 Subject: Records are called =?UTF-8?Q?=E2=80=9Emethods=E2=80=9C=20in=20JShell?= Message-ID: <20200715134707.b6ff8ab09a6c540215cae158a90d7e03.e36a4b0541.wbe@email17.godaddy.com> Thank you so much, Robert! > Hopefully, > > /set format mymode typeKind "record" record > > Will fix your issue. I had high hopes for that [1] but... jshell> /set format mymode typeKind | /set format mymode typeKind "class" class | /set format mymode typeKind "interface" interface | /set format mymode typeKind "enum" enum | /set format mymode typeKind "annotation interface" annotation jshell> public record ConstExpr(Expr e) implements Expr{} | created method ConstExpr(), however, it cannot be referenced until class Expr is declared jshell> /set format mymode typeKind "record" record jshell> /set format mymode typeKind | /set format mymode typeKind "class" class | /set format mymode typeKind "interface" interface | /set format mymode typeKind "enum" enum | /set format mymode typeKind "annotation interface" annotation | /set format mymode typeKind "record" record jshell> public record ConstExpr(Expr e) implements Expr{} | modified method ConstExpr(), however, it cannot be referenced until class Expr is declared ---- [1] https://imgur.com/GaIgkOb -------- Original Message -------- Subject: Re:_Records_are_called_?methods?_in_JSh ell From: Robert Field Date: Wed, July 15, 2020 11:09 am To: Lingo Coder , "kulla-dev at openjdk.java.net" , "jorn.vernee at oracle.com" OK! There is the root of your issue. You have your own mode, but it probably hasn't been updated for records. You aren't using normal mode so, instead, show the output of: /set format mymode typeKind Hopefully, /set format mymode typeKind "record" record Will fix your issue. -Robert On 7/15/20 7:33 AM, Lingo Coder wrote: > Thank you Robert, > >> ?...And send us what it prints...? > You'll see below that right after I did `/set format normal typeKind` > it still said, ?created *method*...?. I also recorded it. [1] > > But then right after `/set feedback verbose`, it said ?created > *record*?. > > However, after an `/exit` and a relaunch of `jshell --enable-preview`, > it > reverted back to ?created *method*...?/?dropped *method*... ?. > > I _vaguely_ recall creating `mymode` and doing `/set feedback -retain > mymode` > way back in 2017 when JShell first came out. I think. I'm not 100% sure > tho. > So I'm guessing I need to do `/set feedback -retain verbose` to > permanently > get ?created *record*...? Correct? > > TIA. > > ---- > ... > > jshell> /set feedback > | /set feedback -retain mymode > | > | Retained feedback modes: > | mymode > | Available feedback modes: > | concise > | mymode > | normal > | silent > | verbose > > jshell> /set format normal typeKind > | /set format normal typeKind "class" class > | /set format normal typeKind "interface" interface > | /set format normal typeKind "enum" enum > | /set format normal typeKind "annotation interface" annotation > | /set format normal typeKind "record" record > > jshell> public record ConstExpr(Expr e) implements Expr{} > | created method ConstExpr(), however, it cannot be referenced until > class Expr is declared > > jshell> /type > | record ConstExpr > | which cannot be referenced until class Expr is declared > > jshell> /types > | record ConstExpr > | which cannot be referenced until class Expr is declared > > jshell> /method > | void print(boolean) > | void print(char) > | void print(int) > | void print(long) > | void print(float) > | void print(double) > | void print(char s[]) > | void print(String) > | void print(Object) > | void println() > | void println(boolean) > | void println(char) > | void println(int) > | void println(long) > | void println(float) > | void println(double) > | void println(char s[]) > | void println(String) > | void println(Object) > | void printf(java.util.Locale,String,Object...) > | void printf(String,Object...) > > jshell> /drop ConstExpr > | dropped method ConstExpr() > > jshell> /set feedback verbose > | Feedback mode: verbose > > jshell> public record ConstExpr(Expr e) implements Expr{} > | created record ConstExpr, however, it cannot be referenced until > class Expr is declared > > jshell> /type > | record ConstExpr > | which cannot be referenced until class Expr is declared > > jshell> class Expr{} > | created class Expr > > jshell> /types > | record ConstExpr > | which cannot be referenced until this error is corrected: > | interface expected here > | public record ConstExpr(Expr e) implements Expr{} > | ^--^ > | class Expr > > jshell> /drop Expr > | dropped class Expr > > jshell> interface Expr{} > | created interface Expr > | update replaced record ConstExpr > > jshell> /types > | record ConstExpr > | interface Expr > > jshell> /drop ConstExpr > | dropped record ConstExpr > > ... > > ---- > [1] https://imgur.com/ePyilYo > > > > -------- Original Message -------- > Subject: Re:_Records_are_called_?methods?_in_JSh ell > From: Robert Field > Date: Tue, July 14, 2020 8:07 pm > To: Lingo Coder , > "kulla-dev at openjdk.java.net" , > "jorn.vernee at oracle.com" > > I have a theory, maybe the following can illuminate... > > Couple more things to try: > > /set feedback > > /set format normal typeKind > > And send us what it prints. > > Also, after you have entered: > > public record ConstExpr(Expr e) implements Expr{} > > Type: > > /type > > and > > /method > > Separately, what do they print? > > Oh, and if you want to try one more thing: > > /set feedback verbose > > public record ConstExpr(Expr e) implements Expr{} > > Sorry, I don't have Windows, but I believe Jan has access. > > -Robert > > > On 2020-07-14 18:35, Lingo Coder wrote: >> Thanks Robert, >> >>> ?...Can you do: >>> jshell --full-version...? >> I did that. It says jshell 15-ea+31-1502 [1] >> >> What version of Windows are you other guys trying this in? I'm on >> Windows 7. >> >>> ?...I'm guessing you may be using an older JDK...? >> As I show in [1] and in earlier screen recordings, I completely >> clear my $PATH to confirm that there is no other jshell.exe on >> the $PATH. >> >> I have not installed any JDKs with an installer or anything >> like that. For that reason, I rule out anything registry-related. >> >> I do have an early access release of 14-Valhalla >> build 14-valhalla+4-55 on my workstation. But, that was >> installed by simply unzipping the archive into a >> jdk-14.L.world.Build.14-valhalla+4-55 folder. More importantly, >> that build doesn't even have the records nor the sealed types >> features. >> >> I also have GA releases of OpenJDK 12 & 13 in their own folders. >> But again, not only are they isolated well out of the way of >> the $PATH I run jshell 15 in, they don't even have records and >> sealed types functionality. >> >> If _any_ other JDK were somehow in the $PATH, it would be >> surprising if records and sealed types even worked _at all_; >> let alone the misnaming as ?methods? issue Right? Please >> correct me if I'm wrong? >> >> >> [1] https://imgur.com/cMsAl5f >> >> -------- Original Message -------- >> Subject: Re:_Records_are_called_?methods?_in_JSh ell >> From: Robert Field >> Date: Tue, July 14, 2020 3:57 pm >> To: kulla-dev at openjdk.java.net, jorn.vernee at oracle.com, >> plugins at lingocoder.com >> >> I'm guessing you may be using an older JDK. I get: >> jshell> public record ConstExpr(Expr e) implements Expr{} >> | created record ConstExpr >> >> jshell> /drop ConstExpr >> | dropped record ConstExpr >> >> >> Can you do: >> jshell --full-version >> >> Thanks, >> Robert >> >> >> From robert.field at oracle.com Thu Jul 16 04:04:21 2020 From: robert.field at oracle.com (Robert Field) Date: Wed, 15 Jul 2020 21:04:21 -0700 Subject: =?UTF-8?Q?Re=3a_Records_are_called_=e2=80=9emethods=e2=80=9c_in_JSh?= =?UTF-8?Q?ell?= In-Reply-To: <20200715134707.b6ff8ab09a6c540215cae158a90d7e03.e36a4b0541.wbe@email17.godaddy.com> References: <20200715134707.b6ff8ab09a6c540215cae158a90d7e03.e36a4b0541.wbe@email17.godaddy.com> Message-ID: <6e20ebd3-0028-fa29-ccf9-9fc82264f0c5@oracle.com> Thanks for persisting with this! I have filed a bug: https://bugs.openjdk.java.net/browse/JDK-8249566 I am able to reproduce it (see bug). You should be able to see it working correctly by doing: jshell> /set feedback normal jshell> public record ConstExpr(Expr e) implements Expr{} See work-around suggestions in bug. I will be looking into fixes. Thanks, Robert On 2020-07-15 13:47, Lingo Coder wrote: > Thank you so much, Robert! > >> Hopefully, >> >> /set format mymode typeKind "record" record >> >> Will fix your issue. > > I had high hopes for that [1] but... > > jshell> /set format mymode typeKind > | /set format mymode typeKind "class" class > | /set format mymode typeKind "interface" interface > | /set format mymode typeKind "enum" enum > | /set format mymode typeKind "annotation interface" annotation > > jshell> public record ConstExpr(Expr e) implements Expr{} > | created method ConstExpr(), however, it cannot be referenced until > class Expr is declared > > jshell> /set format mymode typeKind "record" record > > jshell> /set format mymode typeKind > | /set format mymode typeKind "class" class > | /set format mymode typeKind "interface" interface > | /set format mymode typeKind "enum" enum > | /set format mymode typeKind "annotation interface" annotation > | /set format mymode typeKind "record" record > > jshell> public record ConstExpr(Expr e) implements Expr{} > | modified method ConstExpr(), however, it cannot be referenced until > class Expr is declared > > ---- > > [1] https://imgur.com/GaIgkOb > > > > -------- Original Message -------- > Subject: Re:_Records_are_called_?methods?_in_JSh ell > From: Robert Field > Date: Wed, July 15, 2020 11:09 am > To: Lingo Coder , > "kulla-dev at openjdk.java.net" , > "jorn.vernee at oracle.com" > > OK! There is the root of your issue. You have your own mode, but it > probably hasn't been updated for records. You aren't using normal mode > so, instead, show the output of: > > /set format mymode typeKind > > Hopefully, > > /set format mymode typeKind "record" record > > Will fix your issue. > > -Robert > > On 7/15/20 7:33 AM, Lingo Coder wrote: >> Thank you Robert, >> >>> ?...And send us what it prints...? >> You'll see below that right after I did `/set format normal typeKind` >> it still said, ?created *method*...?. I also recorded it. [1] >> >> But then right after `/set feedback verbose`, it said ?created >> *record*?. >> >> However, after an `/exit` and a relaunch of `jshell --enable-preview`, >> it >> reverted back to ?created *method*...?/?dropped *method*... ?. >> >> I _vaguely_ recall creating `mymode` and doing `/set feedback -retain >> mymode` >> way back in 2017 when JShell first came out. I think. I'm not 100% sure >> tho. >> So I'm guessing I need to do `/set feedback -retain verbose` to >> permanently >> get ?created *record*...? Correct? >> >> TIA. >> >> ---- >> ... >> >> jshell> /set feedback >> | /set feedback -retain mymode >> | >> | Retained feedback modes: >> | mymode >> | Available feedback modes: >> | concise >> | mymode >> | normal >> | silent >> | verbose >> >> jshell> /set format normal typeKind >> | /set format normal typeKind "class" class >> | /set format normal typeKind "interface" interface >> | /set format normal typeKind "enum" enum >> | /set format normal typeKind "annotation interface" annotation >> | /set format normal typeKind "record" record >> >> jshell> public record ConstExpr(Expr e) implements Expr{} >> | created method ConstExpr(), however, it cannot be referenced until >> class Expr is declared >> >> jshell> /type >> | record ConstExpr >> | which cannot be referenced until class Expr is declared >> >> jshell> /types >> | record ConstExpr >> | which cannot be referenced until class Expr is declared >> >> jshell> /method >> | void print(boolean) >> | void print(char) >> | void print(int) >> | void print(long) >> | void print(float) >> | void print(double) >> | void print(char s[]) >> | void print(String) >> | void print(Object) >> | void println() >> | void println(boolean) >> | void println(char) >> | void println(int) >> | void println(long) >> | void println(float) >> | void println(double) >> | void println(char s[]) >> | void println(String) >> | void println(Object) >> | void printf(java.util.Locale,String,Object...) >> | void printf(String,Object...) >> >> jshell> /drop ConstExpr >> | dropped method ConstExpr() >> >> jshell> /set feedback verbose >> | Feedback mode: verbose >> >> jshell> public record ConstExpr(Expr e) implements Expr{} >> | created record ConstExpr, however, it cannot be referenced until >> class Expr is declared >> >> jshell> /type >> | record ConstExpr >> | which cannot be referenced until class Expr is declared >> >> jshell> class Expr{} >> | created class Expr >> >> jshell> /types >> | record ConstExpr >> | which cannot be referenced until this error is corrected: >> | interface expected here >> | public record ConstExpr(Expr e) implements Expr{} >> | ^--^ >> | class Expr >> >> jshell> /drop Expr >> | dropped class Expr >> >> jshell> interface Expr{} >> | created interface Expr >> | update replaced record ConstExpr >> >> jshell> /types >> | record ConstExpr >> | interface Expr >> >> jshell> /drop ConstExpr >> | dropped record ConstExpr >> >> ... >> >> ---- >> [1] https://imgur.com/ePyilYo >> >> >> >> -------- Original Message -------- >> Subject: Re:_Records_are_called_?methods?_in_JSh ell >> From: Robert Field >> Date: Tue, July 14, 2020 8:07 pm >> To: Lingo Coder , >> "kulla-dev at openjdk.java.net" , >> "jorn.vernee at oracle.com" >> >> I have a theory, maybe the following can illuminate... >> >> Couple more things to try: >> >> /set feedback >> >> /set format normal typeKind >> >> And send us what it prints. >> >> Also, after you have entered: >> >> public record ConstExpr(Expr e) implements Expr{} >> >> Type: >> >> /type >> >> and >> >> /method >> >> Separately, what do they print? >> >> Oh, and if you want to try one more thing: >> >> /set feedback verbose >> >> public record ConstExpr(Expr e) implements Expr{} >> >> Sorry, I don't have Windows, but I believe Jan has access. >> >> -Robert >> >> >> On 2020-07-14 18:35, Lingo Coder wrote: >>> Thanks Robert, >>> >>>> ?...Can you do: >>>> jshell --full-version...? >>> I did that. It says jshell 15-ea+31-1502 [1] >>> >>> What version of Windows are you other guys trying this in? I'm on >>> Windows 7. >>> >>>> ?...I'm guessing you may be using an older JDK...? >>> As I show in [1] and in earlier screen recordings, I completely >>> clear my $PATH to confirm that there is no other jshell.exe on >>> the $PATH. >>> >>> I have not installed any JDKs with an installer or anything >>> like that. For that reason, I rule out anything registry-related. >>> >>> I do have an early access release of 14-Valhalla >>> build 14-valhalla+4-55 on my workstation. But, that was >>> installed by simply unzipping the archive into a >>> jdk-14.L.world.Build.14-valhalla+4-55 folder. More importantly, >>> that build doesn't even have the records nor the sealed types >>> features. >>> >>> I also have GA releases of OpenJDK 12 & 13 in their own folders. >>> But again, not only are they isolated well out of the way of >>> the $PATH I run jshell 15 in, they don't even have records and >>> sealed types functionality. >>> >>> If _any_ other JDK were somehow in the $PATH, it would be >>> surprising if records and sealed types even worked _at all_; >>> let alone the misnaming as ?methods? issue Right? Please >>> correct me if I'm wrong? >>> >>> >>> [1] https://imgur.com/cMsAl5f >>> >>> -------- Original Message -------- >>> Subject: Re:_Records_are_called_?methods?_in_JSh ell >>> From: Robert Field >>> Date: Tue, July 14, 2020 3:57 pm >>> To: kulla-dev at openjdk.java.net, jorn.vernee at oracle.com, >>> plugins at lingocoder.com >>> >>> I'm guessing you may be using an older JDK. I get: >>> jshell> public record ConstExpr(Expr e) implements Expr{} >>> | created record ConstExpr >>> >>> jshell> /drop ConstExpr >>> | dropped record ConstExpr >>> >>> >>> Can you do: >>> jshell --full-version >>> >>> Thanks, >>> Robert >>> >>> >>> From jan.lahoda at oracle.com Thu Jul 16 09:43:05 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 16 Jul 2020 11:43:05 +0200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> Message-ID: <40adde2b-0b93-51e1-471d-9ca5cb8ae313@oracle.com> On 15. 07. 20 19:23, Christian Stein wrote: > Hi Jan, > > I reviewed your CR on the webrev and think it resolves the issue. > > I also?+1'ed https://github.com/jline/jline3/issues/552 > > Two questions: > > - Does it only happen on Windows? If yes, why? I believe Windows only. The reason is that inputs work differently on Linux and on Windows. On Linux, reading goes basically from System.in, with some wrapping, but not through NonBlockingReaderInputStream, as no Reader->InputStream conversion is needed. On Windows, the primary source of data is a Reader, based on reading characters directly from the console (System.in is basically ignored, to my knowledge). That gets converted to InputStream using NonBlockingReaderInputStream. > - How can I, without compiling JShell on my own, verify it? > ? Patch that class (*) in my JDK installation temporarily? It should be easy to compile the class and apply it: -create a directory called 8249367 somewhere -download: http://hg.openjdk.java.net/jdk/jdk15/raw-file/244298608b49/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java into: 8249367/src/jdk/internal/jshell/tool/StopDetectingInputStream.java -using a recent JDK 15 build, inside the 8249367 directory do: javac --patch-module jdk.jshell=src -d classes src/jdk/internal/jshell/tool/StopDetectingInputStream.java jshell --enable-preview -J--patch-module=jdk.jshell=classes That should run JShell with the patch. Jan > > Cheers, > Christian > > (*) If you could send the compiled class via mail,?that would be great. > > On Wed, Jul 15, 2020 at 2:18 PM Jan Lahoda > wrote: > > FWIW, I've sent: > https://mail.openjdk.java.net/pipermail/kulla-dev/2020-July/002551.html > > I'd be happy if someone else could verify it solves the issue (given > the > upcoming RDP2). > > Thanks, > ? ? ?Jan > > On 15. 07. 20 9:15, Christian Stein wrote: > > JShell 16-ea is affected, too. > > > > Hoping that the fix is as simple as you think, Jan. > > Perhaps, it can make its way into JShell 15 before GA. > > > > Cheers, > > Christian > > > > > > On Tue, Jul 14, 2020 at 9:05 PM Jan Lahoda > > >> wrote: > > > >? ? ?Hi, > > > >? ? ?Thanks for the report and analysis. I've filled: > > https://bugs.openjdk.java.net/browse/JDK-8249367 > > > >? ? ?I think the issue is in: > > > http://hg.openjdk.java.net/jdk/jdk/file/1e249ca8d585/src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlocking.java#l104 > > > >? ? ?If the timeout is zero (which it is when invoked from > >? ? ?StopDetectingInputStream, as it calls the read method without > timeout), > >? ? ?the method invocation will exit immediately, and it will be > immediately > >? ? ?called again, etc. > > > >? ? ?Jan > > > >? ? ?On 13. 07. 20 6:00, Aaron Scott-Boddendijk wrote: > >? ? ? > I can confirm the CPU behaves as suggested with a sequence of > >? ? ?entering and > >? ? ? > leaving `/edit`. > >? ? ? > > >? ? ? > Thanks Christian. > >? ? ? > > >? ? ? > -- > >? ? ? > Aaron Scott-Boddendijk > >? ? ? > > >? ? ? > On Mon, Jul 13, 2020 at 3:27 PM Christian Stein > >? ? ? > >> wrote: > >? ? ? > > >? ? ? >> It's coming from the "while(true)"-loop in > >? ? ?StopDetectingInputStream.java > >? ? ? >> [0]. > >? ? ? >> > >? ? ? >> Aaron, try to open an external editor within the JShell > session via > >? ? ? >> > >? ? ? >>? ? /edit > >? ? ? >> > >? ? ? >> The CPU usage should drop immediately to normal levels. > >? ? ? >> As soon as you close the editor (it's the internal JShell > Edit > >? ? ?Pad for me) > >? ? ? >> the thread is again eating CPU cycles. Can you confirm this? > >? ? ? >> > >? ? ? >> While the editor is opened, the thread waits via > >? ? ? >> > >? ? ? >> > > > ?jdk.internal.jshell.tool.StopDetectingInputStream.waitInputNeeded > >? ? ?line: > >? ? ? >> 164 > >? ? ? >> > >? ? ? >> If no editor is open, the "input.read()" method does > never wait: > >? ? ? >> > >? ? ? >> > >? ? ? >> > > > ?jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > >? ? ? >> line: 66 > >? ? ? >> > >? ? ? >> Cheers, > >? ? ? >> Christian > >? ? ? >> > >? ? ? >> [0]: > >? ? ? >> > >? ? ? >> > > > https://github.com/openjdk/jdk/blob/faf4d7ccb792b16092c791c0ac77acdd440dbca1/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java#L57-L74 > >? ? ? >> > >? ? ? >> On Mon, Jul 13, 2020 at 5:05 AM Christian Stein > >? ? ? > >> > >? ? ? >> wrote: > >? ? ? >> > >? ? ? >>> Seems like "read line" from "jline" is underlying reason: > >? ? ? >>> > >? ? ? >>> Thread-2 [31] (RUNNABLE) > >? ? ? >>> > >? ? ? >>> > >? ? ? >> > > > ?java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await > >? ? ? >>> line: 1749 > >? ? ? >>>? ? ?jdk.internal.org.jline.utils.NonBlockingPumpReader.read > >? ? ?line: 77 > >? ? ? >>>? ? ?jdk.internal.org.jline.utils.NonBlockingReader.read > line: 57 > >? ? ? >>> > >? ? ? >>> > >? ? ? >> > > > ?jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read > >? ? ? >>> line: 104 > >? ? ? >>>? ? ?jdk.internal.org.jline.utils.NonBlockingInputStream.read > >? ? ?line: 36 > >? ? ? >>> > >? ? ? >>> > >? ? ? >> > > > ?jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > >? ? ? >>> line: 66 > >? ? ? >>> > >? ? ? >>> > >? ? ? >> > > > ?jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$347/0x0000000800cff330.run > >? ? ? >>> line: not available > >? ? ? >>>? ? ?java.lang.Thread.run line: 832 > >? ? ? >>> > >? ? ? >>> It produces a constant high CPU usage and allocates a lot of > >? ? ?RAM per > >? ? ? >>> second. > >? ? ? >>> > >? ? ? >>> Thread Name Thread State Blocked Count Total CPU Usage > Deadlocked > >? ? ? >>> Allocated Memory > >? ? ? >>> Thread-2 RUNNABLE 1 0.06252084028009336 Not Enabled > 196198305136 B > >? ? ? >>> > >? ? ? >>> > >? ? ? >>> > >? ? ? >>> > >? ? ? >>> > >? ? ? >>> On Mon, Jul 13, 2020 at 4:52 AM Christian Stein > >? ? ? > >> > >? ? ? >>> wrote: > >? ? ? >>> > >? ? ? >>>> Hi Aaron, > >? ? ? >>>> > >? ? ? >>>> I observe the same behaviour of JShell 15 build 30. > >? ? ? >>>> > >? ? ? >>>> Here, the 100% CPU workload is split on to 3-4 logical > processors. > >? ? ? >>>> Grabbed an animated GIF of "jshell.exe -- /exit" > session at [0]. > >? ? ? >>>> To me, it looks like a loop is running wild, w/o a > >? ? ? >>>> Thread.yield()/.sleep() call. > >? ? ? >>>> > >? ? ? >>>> Microsoft Windows [Version 10.0.19041.329] > >? ? ? >>>> > >? ? ? >>>> openjdk 15-ea 2020-09-15 > >? ? ? >>>> OpenJDK Runtime Environment (build 15-ea+30-1476) > >? ? ? >>>> OpenJDK 64-Bit Server VM (build 15-ea+30-1476, mixed mode, > >? ? ?sharing) > >? ? ? >>>> > >? ? ? >>>> Cheers, > >? ? ? >>>> Christian > >? ? ? >>>> > >? ? ? >>>> [0]: > >? ? ? >>>> > >? ? ? >> > > > https://drive.google.com/file/d/1KOQO5B9WrM4C43K3AB7H9VVPuh9hdCOe/view?usp=sharing > >? ? ? >>>> > >? ? ? >>>> > >? ? ? >>>> On Mon, Jul 13, 2020 at 4:24 AM Aaron Scott-Boddendijk < > >? ? ? >> talden at gmail.com > >> > >? ? ? >>>> wrote: > >? ? ? >>>> > >? ? ? >>>>> This still exists in JDK 15 build 31. > >? ? ? >>>>> > >? ? ? >>>>> Is any other Windows user able to reproduce this? I > have two > >? ? ?machines, > >? ? ? >>>>> one > >? ? ? >>>>> laptop and one desktop that show a CPU thread constantly @ > >? ? ?100% just by > >? ? ? >>>>> starting JShell. For the desktop machine that's not a > major > >? ? ?issue but > >? ? ? >> for > >? ? ? >>>>> the laptop this spins up the fans and eats the battery. > >? ? ? >>>>> > >? ? ? >>>>> JShell in JDK 14 is fine. > >? ? ? >>>>> > >? ? ? >>>>> I've yet to hear of any other user confirming this issue. > >? ? ? >>>>> > >? ? ? >>>>> -- > >? ? ? >>>>> Aaron Scott-Boddendijk > >? ? ? >>>>> > >? ? ? >>>>> > >? ? ? >>>>> On Fri, Jun 26, 2020 at 2:00 PM Aaron Scott-Boddendijk < > >? ? ? >> talden at gmail.com > > > >? ? ? >>>>>> > >? ? ? >>>>> wrote: > >? ? ? >>>>> > >? ? ? >>>>>> Just confirming that: > >? ? ? >>>>>> > >? ? ? >>>>>> * This still exists in JDK 15 build 29 > >? ? ? >>>>>> * Occurs on multiple unrelated Windows 10 machines with > >? ? ?differing > >? ? ? >> major > >? ? ? >>>>>> versions of the OS. > >? ? ? >>>>>> * Does not occur in JDK 14.01 on these machines > (OpenJDK 64-Bit > >? ? ? >> Server > >? ? ? >>>>> VM > >? ? ? >>>>>> Zulu14.28+21-CA) > >? ? ? >>>>>> * Does not appear to occur on Linux > >? ? ? >>>>>> > >? ? ? >>>>>> -- > >? ? ? >>>>>> Aaron Scott-Boddendijk > >? ? ? >>>>>> > >? ? ? >>>>>> > >? ? ? >>>>>> On Tue, Jun 16, 2020 at 11:16 AM Aaron Scott-Boddendijk < > >? ? ? >>>>> talden at gmail.com > >> > >? ? ? >>>>>> wrote: > >? ? ? >>>>>> > >? ? ? >>>>>>> This is the thread-dump from the JVM that VisualVM > sees as > >? ? ?using a > >? ? ? >>>>> core... > >? ? ? >>>>>>> > >? ? ? >>>>>>> 2020-06-16 11:07:35 > >? ? ? >>>>>>> Full thread dump OpenJDK 64-Bit Server VM (15-ea+27-1372 > >? ? ?mixed mode, > >? ? ? >>>>>>> sharing): > >? ? ? >>>>>>> > >? ? ? >>>>>>> Threads class SMR info: > >? ? ? >>>>>>> _java_thread_list=0x000001e34a6040f0, length=23, > elements={ > >? ? ? >>>>>>> 0x000001e31c1a1dc0, 0x000001e349035ee0, > 0x000001e349037250, > >? ? ? >>>>>>> 0x000001e349058ae0, > >? ? ? >>>>>>> 0x000001e34905c5b0, 0x000001e34905f710, > 0x000001e3490603f0, > >? ? ? >>>>>>> 0x000001e349065140, > >? ? ? >>>>>>> 0x000001e34906d620, 0x000001e349b36a20, > 0x000001e349b8c690, > >? ? ? >>>>>>> 0x000001e349da3400, > >? ? ? >>>>>>> 0x000001e349daa7c0, 0x000001e349dbb640, > 0x000001e34a141140, > >? ? ? >>>>>>> 0x000001e349d555c0, > >? ? ? >>>>>>> 0x000001e34b07f030, 0x000001e34a461c90, > 0x000001e34a45fae0, > >? ? ? >>>>>>> 0x000001e34a45ffb0, > >? ? ? >>>>>>> 0x000001e34a4617c0, 0x000001e34a462160, > 0x000001e34a45f610 > >? ? ? >>>>>>> } > >? ? ? >>>>>>> > >? ? ? >>>>>>> "main" #1 prio=5 os_prio=0 cpu=1078.13ms elapsed=341.81s > >? ? ? >>>>>>> tid=0x000001e31c1a1dc0 nid=0x16b0 in Object.wait() > >? ? ? >>>>> [0x000000340d9fe000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: TIMED_WAITING (on object > monitor) > >? ? ? >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > >? ? ?Method) > >? ? ? >>>>>>>? ? ? ? ? - waiting on > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /NonBlockingInputStreamImpl.java:139) > >? ? ? >>>>>>>? ? ? ? ? - locked <0x000000060fe87338> (a > >? ? ? >>>>>>> jdk.internal.jshell.tool.ConsoleIOContext$1) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /NonBlockingInputStream.java:62) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /NonBlocking.java:168) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /NonBlockingReader.java:57) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /BindingReader.java:160) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /BindingReader.java:110) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /BindingReader.java:61) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /LineReaderImpl.java:913) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /LineReaderImpl.java:946) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 15-ea > >? ? ? >>>>>>> /ConsoleIOContext.java:154) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /LineReaderImpl.java:637) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /LineReaderImpl.java:454) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > > > ?jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 15-ea > >? ? ? >>>>>>> /ConsoleIOContext.java:229) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>> > jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 15-ea > >? ? ? >>>>>>> /JShellTool.java:1254) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 15-ea > >? ? ? >>>>>>> /JShellTool.java:1190) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >> jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 15-ea > >? ? ? >>>>>>> /JShellTool.java:991) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ?jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 15-ea > >? ? ? >>>>>>> /JShellToolBuilder.java:254) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ?jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 15-ea > >? ? ? >>>>>>> /JShellToolProvider.java:120) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "Reference Handler" #2 daemon prio=10 os_prio=2 > cpu=0.00ms > >? ? ? >>>>>>> elapsed=341.79s tid=0x000001e349035ee0 nid=0x13fc > waiting on > >? ? ? >> condition > >? ? ? >>>>>>>? ?[0x000000340e0fe000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > > > ?java.lang.ref.Reference.waitForReferencePendingList(java.base at 15-ea > >? ? ? >>>>> /Native > >? ? ? >>>>>>> Method) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ?java.lang.ref.Reference.processPendingReferences(java.base at 15-ea > >? ? ? >>>>>>> /Reference.java:241) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>> > java.lang.ref.Reference$ReferenceHandler.run(java.base at 15-ea > >? ? ? >>>>>>> /Reference.java:213) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms > >? ? ?elapsed=341.79s > >? ? ? >>>>>>> tid=0x000001e349037250 nid=0x2a60 in Object.wait() > >? ? ? >>>>> [0x000000340e1fe000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: WAITING (on object monitor) > >? ? ? >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > >? ? ?Method) > >? ? ? >>>>>>>? ? ? ? ? - waiting on <0x0000000601400bc0> (a > >? ? ? >>>>>>> java.lang.ref.ReferenceQueue$Lock) > >? ? ? >>>>>>>? ? ? ? ? at > java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >? ? ? >>>>>>> /ReferenceQueue.java:155) > >? ? ? >>>>>>>? ? ? ? ? - locked <0x0000000601400bc0> (a > >? ? ? >>>>>>> java.lang.ref.ReferenceQueue$Lock) > >? ? ? >>>>>>>? ? ? ? ? at > java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >? ? ? >>>>>>> /ReferenceQueue.java:176) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >> java.lang.ref.Finalizer$FinalizerThread.run(java.base at 15-ea > >? ? ? >>>>>>> /Finalizer.java:170) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "Signal Dispatcher" #4 daemon prio=9 os_prio=2 > cpu=0.00ms > >? ? ? >>>>> elapsed=341.78s > >? ? ? >>>>>>> tid=0x000001e349058ae0 nid=0x35c8 runnable > >? ? ?[0x0000000000000000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "Attach Listener" #5 daemon prio=5 os_prio=2 > cpu=125.00ms > >? ? ? >>>>> elapsed=341.78s > >? ? ? >>>>>>> tid=0x000001e34905c5b0 nid=0x3e0c waiting on condition > >? ? ? >>>>> [0x0000000000000000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "Service Thread" #6 daemon prio=9 os_prio=0 cpu=0.00ms > >? ? ? >> elapsed=341.78s > >? ? ? >>>>>>> tid=0x000001e34905f710 nid=0x398c runnable > >? ? ?[0x0000000000000000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "C2 CompilerThread0" #7 daemon prio=9 os_prio=2 > cpu=1781.25ms > >? ? ? >>>>>>> elapsed=341.78s tid=0x000001e3490603f0 nid=0xcf0 > waiting on > >? ? ? >> condition > >? ? ? >>>>>>>? ?[0x0000000000000000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>>? ? ?No compile task > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "C1 CompilerThread0" #10 daemon prio=9 os_prio=2 > cpu=765.63ms > >? ? ? >>>>>>> elapsed=341.78s tid=0x000001e349065140 nid=0x3e54 > waiting on > >? ? ? >> condition > >? ? ? >>>>>>>? ?[0x0000000000000000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>>? ? ?No compile task > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "Sweeper thread" #11 daemon prio=9 os_prio=2 cpu=0.00ms > >? ? ? >>>>> elapsed=341.78s > >? ? ? >>>>>>> tid=0x000001e34906d620 nid=0x38bc runnable > >? ? ?[0x0000000000000000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "Notification Thread" #12 daemon prio=9 os_prio=0 > cpu=0.00ms > >? ? ? >>>>>>> elapsed=341.76s tid=0x000001e349b36a20 nid=0x49b8 > runnable > >? ? ? >>>>>>>? ?[0x0000000000000000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "Common-Cleaner" #13 daemon prio=8 os_prio=1 cpu=0.00ms > >? ? ? >>>>> elapsed=341.75s > >? ? ? >>>>>>> tid=0x000001e349b8c690 nid=0x26e4 in Object.wait() > >? ? ? >>>>> [0x000000340eaff000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: TIMED_WAITING (on object > monitor) > >? ? ? >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > >? ? ?Method) > >? ? ? >>>>>>>? ? ? ? ? - waiting on > >? ? ? >>>>>>>? ? ? ? ? at > java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > >? ? ? >>>>>>> /ReferenceQueue.java:155) > >? ? ? >>>>>>>? ? ? ? ? - locked <0x0000000601401a78> (a > >? ? ? >>>>>>> java.lang.ref.ReferenceQueue$Lock) > >? ? ? >>>>>>>? ? ? ? ? at > jdk.internal.ref.CleanerImpl.run(java.base at 15-ea > >? ? ? >>>>>>> /CleanerImpl.java:148) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?jdk.internal.misc.InnocuousThread.run(java.base at 15-ea > >? ? ? >>>>>>> /InnocuousThread.java:134) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "JDI Internal Event Handler" #17 daemon prio=5 os_prio=0 > >? ? ?cpu=15.63ms > >? ? ? >>>>>>> elapsed=341.39s tid=0x000001e349da3400 nid=0x68 in > >? ? ?Object.wait() > >? ? ? >>>>>>>? ?[0x000000340effe000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: WAITING (on object monitor) > >? ? ? >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > >? ? ?Method) > >? ? ? >>>>>>>? ? ? ? ? - waiting on > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>> > com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > >? ? ? >>>>>>> /EventQueueImpl.java:190) > >? ? ? >>>>>>>? ? ? ? ? - locked <0x000000060154b630> (a > >? ? ? >>>>> com.sun.tools.jdi.EventQueueImpl) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>> > com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 15-ea > >? ? ? >>>>>>> /EventQueueImpl.java:125) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 15-ea > >? ? ? >>>>>>> /InternalEventHandler.java:61) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "JDI Target VM Interface" #16 daemon prio=5 os_prio=0 > >? ? ?cpu=46.88ms > >? ? ? >>>>>>> elapsed=341.39s tid=0x000001e349daa7c0 nid=0x3d04 > runnable > >? ? ? >>>>>>>? ?[0x000000340f0fe000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native > >? ? ? >>>>>>> Method) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > >? ? ? >>>>>>> /SocketDispatcher.java:46) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:261) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:312) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:350) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:803) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.net.Socket$SocketInputStream.read(java.base at 15-ea > >? ? ? >>>>>>> /Socket.java:981) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.net.Socket$SocketInputStream.read(java.base at 15-ea > >? ? ? >>>>>>> /Socket.java:976) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >> com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 15-ea > >? ? ? >>>>>>> /SocketConnection.java:82) > >? ? ? >>>>>>>? ? ? ? ? - locked <0x000000060154b998> (a > java.lang.Object) > >? ? ? >>>>>>>? ? ? ? ? at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 15-ea > >? ? ? >>>>>>> /TargetVM.java:124) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - <0x0000000601577110> (a > >? ? ? >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >? ? ? >>>>>>> > >? ? ? >>>>>>> "event-handler" #18 daemon prio=5 os_prio=0 cpu=0.00ms > >? ? ? >> elapsed=341.38s > >? ? ? >>>>>>> tid=0x000001e349dbb640 nid=0x203c in Object.wait() > >? ? ? >>>>> [0x000000340edfe000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: WAITING (on object monitor) > >? ? ? >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > >? ? ?Method) > >? ? ? >>>>>>>? ? ? ? ? - waiting on > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>> > com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > >? ? ? >>>>>>> /EventQueueImpl.java:190) > >? ? ? >>>>>>>? ? ? ? ? - locked <0x000000060154bc28> (a > >? ? ? >>>>> com.sun.tools.jdi.EventQueueImpl) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > >? ? ? >>>>>>> /EventQueueImpl.java:97) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > >? ? ? >>>>>>> /EventQueueImpl.java:83) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 15-ea > >? ? ? >>>>>>> /JdiEventHandler.java:79) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "output reader" #19 daemon prio=5 os_prio=0 cpu=0.00ms > >? ? ? >> elapsed=341.31s > >? ? ? >>>>>>> tid=0x000001e34a141140 nid=0x49c0 runnable > >? ? ?[0x000000340eeff000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native > >? ? ? >>>>>>> Method) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > >? ? ? >>>>>>> /SocketDispatcher.java:46) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:261) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:312) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:350) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:803) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.net.Socket$SocketInputStream.read(java.base at 15-ea > >? ? ? >>>>>>> /Socket.java:981) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.net.Socket$SocketInputStream.read(java.base at 15-ea > >? ? ? >>>>>>> /Socket.java:976) > >? ? ? >>>>>>>? ? ? ? ? at > java.io.FilterInputStream.read(java.base at 15-ea > >? ? ? >>>>>>> /FilterInputStream.java:82) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >> jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 15-ea > >? ? ? >>>>>>> /DemultiplexInput.java:58) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - <0x0000000601553510> (a > >? ? ? >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >? ? ? >>>>>>> > >? ? ? >>>>>>> "Thread-0" #21 daemon prio=5 os_prio=0 cpu=312.50ms > >? ? ?elapsed=341.22s > >? ? ? >>>>>>> tid=0x000001e349d555c0 nid=0x4d88 waiting on condition > >? ? ? >>>>> [0x000000340f1fe000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: WAITING (parking) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native > >? ? ? >>>>> Method) > >? ? ? >>>>>>>? ? ? ? ? - parking to wait for? <0x0000000601550fc0> (a > >? ? ? >>>>>>> > >? ? ? >> > > > ?java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >> java.util.concurrent.locks.LockSupport.park(java.base at 15-ea > >? ? ? >>>>>>> /LockSupport.java:341) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 15-ea > >? ? ? >>>>>>> /AbstractQueuedSynchronizer.java:505) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>> > java.util.concurrent.ForkJoinPool.managedBlock(java.base at 15-ea > >? ? ? >>>>>>> /ForkJoinPool.java:3137) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > >? ? ? >>>>>>> /AbstractQueuedSynchronizer.java:1614) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>> > java.util.concurrent.LinkedBlockingQueue.take(java.base at 15-ea > >? ? ? >>>>>>> /LinkedBlockingQueue.java:435) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>> > java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > >? ? ? >>>>>>> /ThreadPoolExecutor.java:1056) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ?java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >? ? ? >>>>>>> /ThreadPoolExecutor.java:1116) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > > > ?java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >? ? ? >>>>>>> /ThreadPoolExecutor.java:630) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "Thread-2" #23 daemon prio=5 os_prio=0 cpu=338859.38ms > >? ? ? >> elapsed=340.58s > >? ? ? >>>>>>> tid=0x000001e34b07f030 nid=0xac0 runnable > [0x000000340f3fe000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > >? ? ? >>>>>>> /AbstractQueuedSynchronizer.java:1749) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.utils.NonBlockingPumpReader.read(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /NonBlockingPumpReader.java:77) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /NonBlockingReader.java:57) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /NonBlocking.java:104) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /NonBlockingInputStream.java:36) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 15-ea > >? ? ? >>>>>>> /StopDetectingInputStream.java:66) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$410/0x0000000800d2eb28.run(jdk.jshell at 15-ea > >? ? ? >>>>> /Unknown > >? ? ? >>>>>>> Source) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - <0x00000006028b4318> (a > >? ? ? >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >? ? ? >>>>>>> > >? ? ? >>>>>>> "WindowsStreamPump" #25 daemon prio=5 os_prio=0 > cpu=0.00ms > >? ? ? >>>>>>> elapsed=340.53s tid=0x000001e34a461c90 nid=0x3688 > runnable > >? ? ? >>>>>>>? ?[0x000000340f4fe000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.terminal.impl.jna.win.Kernel32Impl.WaitForSingleObject(jdk.internal.le at 15-ea > >? ? ? >>>>> /Native > >? ? ? >>>>>>> Method) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.readConsoleInput(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /JnaWinSysTerminal.java:185) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.processConsoleInput(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /JnaWinSysTerminal.java:108) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal.pump(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /AbstractWindowsTerminal.java:465) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal$$Lambda$417/0x0000000800d310f8.run(jdk.internal.le at 15-ea > >? ? ? >>>>> /Unknown > >? ? ? >>>>>>> Source) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "null non blocking reader thread" #26 daemon prio=5 > os_prio=0 > >? ? ? >>>>> cpu=0.00ms > >? ? ? >>>>>>> elapsed=340.26s tid=0x000001e34a45fae0 nid=0x488 in > >? ? ?Object.wait() > >? ? ? >>>>>>>? ?[0x000000340f6ff000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: WAITING (on object monitor) > >? ? ? >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > >? ? ?Method) > >? ? ? >>>>>>>? ? ? ? ? - waiting on > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Object.wait(java.base at 15-ea/Object.java:321) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > > > ?jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 15-ea > >? ? ? >>>>>>> /StopDetectingInputStream.java:98) > >? ? ? >>>>>>>? ? ? ? ? - locked <0x0000000601e2b650> (a > >? ? ? >>>>>>> jdk.internal.jshell.tool.StopDetectingInputStream) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 15-ea > >? ? ? >>>>>>> /NonBlockingInputStreamImpl.java:216) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$584/0x0000000800d4f088.run(jdk.internal.le at 15-ea > >? ? ? >>>>> /Unknown > >? ? ? >>>>>>> Source) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "RMI TCP Accept-0" #27 daemon prio=5 os_prio=0 > cpu=0.00ms > >? ? ? >>>>> elapsed=180.89s > >? ? ? >>>>>>> tid=0x000001e34a45ffb0 nid=0x45f0 runnable > >? ? ?[0x000000340d8fe000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>>? ? ? ? ? at sun.nio.ch.Net.accept(java.base at 15-ea/Native > >? ? ?Method) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl.accept(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:755) > >? ? ? >>>>>>>? ? ? ? ? at > java.net.ServerSocket.implAccept(java.base at 15-ea > >? ? ? >>>>>>> /ServerSocket.java:684) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.net.ServerSocket.platformImplAccept(java.base at 15-ea > >? ? ? >>>>>>> /ServerSocket.java:650) > >? ? ? >>>>>>>? ? ? ? ? at > java.net.ServerSocket.implAccept(java.base at 15-ea > >? ? ? >>>>>>> /ServerSocket.java:626) > >? ? ? >>>>>>>? ? ? ? ? at > java.net.ServerSocket.implAccept(java.base at 15-ea > >? ? ? >>>>>>> /ServerSocket.java:583) > >? ? ? >>>>>>>? ? ? ? ? at java.net.ServerSocket.accept(java.base at 15-ea > >? ? ? >>>>>>> /ServerSocket.java:540) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(jdk.management.agent at 15-ea > >? ? ? >>>>>>> /LocalRMIServerSocketFactory.java:52) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi at 15-ea > >? ? ? >>>>>>> /TCPTransport.java:413) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ?sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi at 15-ea > >? ? ? >>>>>>> /TCPTransport.java:377) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - <0x0000000602e53118> (a > >? ? ? >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >? ? ? >>>>>>> > >? ? ? >>>>>>> "RMI TCP Connection(1)-10.0.201.131" #28 daemon prio=5 > >? ? ?os_prio=0 > >? ? ? >>>>>>> cpu=437.50ms elapsed=180.87s tid=0x000001e34a4617c0 > nid=0x4790 > >? ? ? >>>>> runnable > >? ? ? >>>>>>>? ?[0x000000340fbfe000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: RUNNABLE > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.Net.poll(java.base at 15-ea/Native Method) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl.park(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:181) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl.timedRead(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:285) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:309) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:350) > >? ? ? >>>>>>>? ? ? ? ? at > sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > >? ? ? >>>>>>> /NioSocketImpl.java:803) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.net.Socket$SocketInputStream.read(java.base at 15-ea > >? ? ? >>>>>>> /Socket.java:981) > >? ? ? >>>>>>>? ? ? ? ? at > java.io.BufferedInputStream.fill(java.base at 15-ea > >? ? ? >>>>>>> /BufferedInputStream.java:244) > >? ? ? >>>>>>>? ? ? ? ? at > java.io.BufferedInputStream.read(java.base at 15-ea > >? ? ? >>>>>>> /BufferedInputStream.java:263) > >? ? ? >>>>>>>? ? ? ? ? - locked <0x0000000602e19470> (a > >? ? ? >> java.io.BufferedInputStream) > >? ? ? >>>>>>>? ? ? ? ? at > java.io.FilterInputStream.read(java.base at 15-ea > >? ? ? >>>>>>> /FilterInputStream.java:82) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ?sun.rmi.transport.tcp.TCPTransport.handleMessages(java.rmi at 15-ea > >? ? ? >>>>>>> /TCPTransport.java:569) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(java.rmi at 15-ea > >? ? ? >>>>>>> /TCPTransport.java:828) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(java.rmi at 15-ea > >? ? ? >>>>>>> /TCPTransport.java:705) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$686/0x0000000800da3998.run(java.rmi at 15-ea > >? ? ? >>>>> /Unknown > >? ? ? >>>>>>> Source) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ?java.security.AccessController.executePrivileged(java.base at 15-ea > >? ? ? >>>>>>> /AccessController.java:753) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >> java.security.AccessController.doPrivileged(java.base at 15-ea > >? ? ? >>>>>>> /AccessController.java:391) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > > > ?sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(java.rmi at 15-ea > >? ? ? >>>>>>> /TCPTransport.java:704) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ?java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >? ? ? >>>>>>> /ThreadPoolExecutor.java:1130) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > > > ?java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >? ? ? >>>>>>> /ThreadPoolExecutor.java:630) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - <0x0000000602e19708> (a > >? ? ? >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker) > >? ? ? >>>>>>>? ? ? ? ? - <0x0000000602e59038> (a > >? ? ? >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > >? ? ? >>>>>>> > >? ? ? >>>>>>> "RMI Scheduler(0)" #29 daemon prio=5 os_prio=0 > cpu=0.00ms > >? ? ? >>>>> elapsed=180.86s > >? ? ? >>>>>>> tid=0x000001e34a462160 nid=0x1df0 waiting on condition > >? ? ? >>>>> [0x000000340fcfe000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: TIMED_WAITING (parking) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native > >? ? ? >>>>> Method) > >? ? ? >>>>>>>? ? ? ? ? - parking to wait for? <0x0000000602e1af00> (a > >? ? ? >>>>>>> > >? ? ? >> > > > ?java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ?java.util.concurrent.locks.LockSupport.parkNanos(java.base at 15-ea > >? ? ? >>>>>>> /LockSupport.java:252) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 15-ea > >? ? ? >>>>>>> /AbstractQueuedSynchronizer.java:1661) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > >? ? ? >>>>>>> /ScheduledThreadPoolExecutor.java:1182) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > >? ? ? >>>>>>> /ScheduledThreadPoolExecutor.java:899) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>> > java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > >? ? ? >>>>>>> /ThreadPoolExecutor.java:1056) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ?java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > >? ? ? >>>>>>> /ThreadPoolExecutor.java:1116) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > > > ?java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > >? ? ? >>>>>>> /ThreadPoolExecutor.java:630) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "JMX server connection timeout 30" #30 daemon prio=5 > os_prio=0 > >? ? ? >>>>> cpu=0.00ms > >? ? ? >>>>>>> elapsed=180.86s tid=0x000001e34a45f610 nid=0x2fe8 in > >? ? ?Object.wait() > >? ? ? >>>>>>>? ?[0x000000340fdff000] > >? ? ? >>>>>>>? ? ?java.lang.Thread.State: TIMED_WAITING (on object > monitor) > >? ? ? >>>>>>>? ? ? ? ? at java.lang.Object.wait(java.base at 15-ea/Native > >? ? ?Method) > >? ? ? >>>>>>>? ? ? ? ? - waiting on > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >> > > > ?com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(java.management at 15-ea > >? ? ? >>>>>>> /ServerCommunicatorAdmin.java:171) > >? ? ? >>>>>>>? ? ? ? ? - locked <0x0000000602e1ca08> (a [I) > >? ? ? >>>>>>>? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > >? ? ? >>>>>>> > >? ? ? >>>>>>>? ? ?Locked ownable synchronizers: > >? ? ? >>>>>>>? ? ? ? ? - None > >? ? ? >>>>>>> > >? ? ? >>>>>>> "VM Thread" os_prio=2 cpu=515.63ms elapsed=341.79s > >? ? ? >>>>> tid=0x000001e349031eb0 > >? ? ? >>>>>>> nid=0x540 runnable > >? ? ? >>>>>>> > >? ? ? >>>>>>> "GC Thread#0" os_prio=2 cpu=328.13ms elapsed=341.80s > >? ? ? >>>>>>> tid=0x000001e31c218710 nid=0x19e8 runnable > >? ? ? >>>>>>> > >? ? ? >>>>>>> "GC Thread#1" os_prio=2 cpu=265.63ms elapsed=341.53s > >? ? ? >>>>>>> tid=0x000001e349b353d0 nid=0x1cc4 runnable > >? ? ? >>>>>>> > >? ? ? >>>>>>> "GC Thread#2" os_prio=2 cpu=218.75ms elapsed=340.37s > >? ? ? >>>>>>> tid=0x000001e349b350a0 nid=0x1ddc runnable > >? ? ? >>>>>>> > >? ? ? >>>>>>> "GC Thread#3" os_prio=2 cpu=187.50ms elapsed=338.82s > >? ? ? >>>>>>> tid=0x000001e349b35700 nid=0x4a48 runnable > >? ? ? >>>>>>> > >? ? ? >>>>>>> "GC Thread#4" os_prio=2 cpu=140.63ms elapsed=338.82s > >? ? ? >>>>>>> tid=0x000001e349b340b0 nid=0x32e8 runnable > >? ? ? >>>>>>> > >? ? ? >>>>>>> "GC Thread#5" os_prio=2 cpu=156.25ms elapsed=338.82s > >? ? ? >>>>>>> tid=0x000001e349b35a30 nid=0x38cc runnable > >? ? ? >>>>>>> > >? ? ? >>>>>>> "GC Thread#6" os_prio=2 cpu=171.88ms elapsed=338.82s > >? ? ? >>>>>>> tid=0x000001e349b35d60 nid=0x3ed0 runnable > >? ? ? >>>>>>> > >? ? ? >>>>>>> "G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=341.80s > >? ? ? >>>>>>> tid=0x000001e31c229930 nid=0x21c runnable > >? ? ? >>>>>>> > >? ? ? >>>>>>> "G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=341.80s > >? ? ? >>>>> tid=0x000001e31c22a5a0 > >? ? ? >>>>>>> nid=0x3920 runnable > >? ? ? >>>>>>> > >? ? ? >>>>>>> "G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=341.80s > >? ? ? >>>>> tid=0x000001e31c253f10 > >? ? ? >>>>>>> nid=0x1f84 runnable > >? ? ? >>>>>>> > >? ? ? >>>>>>> "G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms > elapsed=341.80s > >? ? ? >>>>>>> tid=0x000001e31c254b90 nid=0x27ac runnable > >? ? ? >>>>>>> > >? ? ? >>>>>>> "VM Periodic Task Thread" os_prio=2 cpu=15.63ms > elapsed=341.76s > >? ? ? >>>>>>> tid=0x000001e349b39710 nid=0x838 waiting on condition > >? ? ? >>>>>>> > >? ? ? >>>>>>> JNI global refs: 33, weak refs: 0 > >? ? ? >>>>>>> > >? ? ? >>>>>>> -- > >? ? ? >>>>>>> Aaron Scott-Boddendijk > >? ? ? >>>>>>> > >? ? ? >>>>>>> On Tue, Jun 16, 2020 at 10:15 AM Robert Field < > >? ? ? >>>>> robert.field at oracle.com > >> > >? ? ? >>>>>>> wrote: > >? ? ? >>>>>>> > >? ? ? >>>>>>>> Make that jps/jstack > >? ? ? >>>>>>>> > >? ? ? >>>>>>>> -R > >? ? ? >>>>>>>> > >? ? ? >>>>>>>> On 2020-06-15 15:12, Robert Field wrote: > >? ? ? >>>>>>>>> Thanks for the report. > >? ? ? >>>>>>>>> > >? ? ? >>>>>>>>> What, if anything, is the Java stack for this > thread (jps)? > >? ? ? >>>>>>>>> > >? ? ? >>>>>>>>> -Robert > >? ? ? >>>>>>>>> > >? ? ? >>>>>>>>> > >? ? ? >>>>>>>>> On 2020-06-15 14:41, Aaron Scott-Boddendijk wrote: > >? ? ? >>>>>>>>>>? ? System: > >? ? ? >>>>>>>>>> * Windows 10 > >? ? ? >>>>>>>>>> * Powershell > >? ? ? >>>>>>>>>> > >? ? ? >>>>>>>>>> When I start JShell, without executing anything, > a CPU > >? ? ?core is > >? ? ? >>>>> always > >? ? ? >>>>>>>> at > >? ? ? >>>>>>>>>> 100% (a single thread though I haven't identified > what it's > >? ? ? >>>>> doing). > >? ? ? >>>>>>>>>> > >? ? ? >>>>>>>>>> The thread stack is as follows (with only the > last two items > >? ? ? >>>>> sometimes > >? ? ? >>>>>>>>>> change - but I don't know the internals of the JVM to > >? ? ?know if > >? ? ? >> this > >? ? ? >>>>>>>>>> useful > >? ? ? >>>>>>>>>> or significant): > >? ? ? >>>>>>>>>> > >? ? ? >>>>>>>>>> ntoskrnl.exe!KeSynchronizeExecution+0x5b46 > >? ? ? >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x1c2d > >? ? ? >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0xab4 > >? ? ? >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x255 > >? ? ? >>>>>>>>>> ntoskrnl.exe!RtlClearBitsEx+0x15a7 > >? ? ? >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x3828 > >? ? ? >>>>>>>>>> ntoskrnl.exe!KeSynchronizeExecution+0x3120 > >? ? ? >>>>>>>>>> jvm.dll!c2v_notifyCompilerInliningEvent+0x201797 > >? ? ? >>>>>>>>>> > >? ? ? >>>>>>>>>> The JDK 14 version of JShell does not have this > issue but > >? ? ? >> several > >? ? ? >>>>> of > >? ? ? >>>>>>>> the > >? ? ? >>>>>>>>>> recent JDK 15 builds have done this. > >? ? ? >>>>>>>>>> > >? ? ? >>>>>>>>>> -- > >? ? ? >>>>>>>>>> Aaron Scott-Boddendijk > >? ? ? >>>>>>>> > >? ? ? >>>>>>> > >? ? ? >>>>> > >? ? ? >>>> > >? ? ? >> > > > From plugins at lingocoder.com Thu Jul 16 09:47:29 2020 From: plugins at lingocoder.com (Lingo Coder) Date: Thu, 16 Jul 2020 02:47:29 -0700 Subject: Records are called =?UTF-8?Q?=E2=80=9Emethods=E2=80=9C=20in=20JShell?= Message-ID: <20200716024729.b6ff8ab09a6c540215cae158a90d7e03.f548552953.wbe@email17.godaddy.com> Thank you Robert, Jorn, and Jan, A couple last things. Please? 1. How is that `mymode` has persisted so long and is configured for every one of my JDKs since JDK9? Even though they are all in their own folders? I set `mymode` way back in 2017 in a JDK 9 install; that was so long ago that I'd forgotten it. Since then, I've used JDKs 10-15. They're all in their own folders. 2. Please, can anybody on the list recommend a thorough resource on advanced use of JShell? I've learned a lot about JShell from Java 9 Revealed ? For Early Adoption and Migration by Kishor Sharan By ?advanced? I mean things like: How to configure the built-in default snippet editor on Windows, to open centered in the screen; instead of opening at an X * Y position that has most of the editor off screen at the bottom-right of the window. TIA. -------- Original Message -------- Subject: Re:_Records_are_called_?methods?_in_JSh ell From: Robert Field Date: Wed, July 15, 2020 9:04 pm To: Lingo Coder , "kulla-dev at openjdk.java.net" , "jorn.vernee at oracle.com" Thanks for persisting with this! I have filed a bug: https://bugs.openjdk.java.net/browse/JDK-8249566 I am able to reproduce it (see bug). You should be able to see it working correctly by doing: jshell> /set feedback normal jshell> public record ConstExpr(Expr e) implements Expr{} See work-around suggestions in bug. I will be looking into fixes. Thanks, Robert On 2020-07-15 13:47, Lingo Coder wrote: Thank you so much, Robert! Hopefully,/set format mymode typeKind "record" recordWill fix your issue. I had high hopes for that [1] but...jshell> /set format mymode typeKind| /set format mymode typeKind "class" class| /set format mymode typeKind "interface" interface| /set format mymode typeKind "enum" enum| /set format mymode typeKind "annotation interface" annotationjshell> public record ConstExpr(Expr e) implements Expr{}| created method ConstExpr(), however, it cannot be referenced untilclass Expr is declaredjshell> /set format mymode typeKind "record" recordjshell> /set format mymode typeKind| /set format mymode typeKind "class" class| /set format mymode typeKind "interface" interface| /set format mymode typeKind "enum" enum| /set format mymode typeKind "annotation interface" annotation| /set format mymode typeKind "record" recordjshell> public record ConstExpr(Expr e) implements Expr{}| modified method ConstExpr(), however, it cannot be referenced untilclass Expr is declared----[1] https://imgur.com/GaIgkOb-------- Original Message --------Subject: Re:_Records_are_called_?methods?_in_JSh ellFrom: Robert Field Date: Wed, July 15, 2020 11:09 amTo: Lingo Coder , "kulla-dev at openjdk.java.net" , "jorn.vernee at oracle.com" OK! There is the root of your issue. You have your own mode, but it probably hasn't been updated for records. You aren't using normal mode so, instead, show the output of: /set format mymode typeKindHopefully,/set format mymode typeKind "record" recordWill fix your issue.-RobertOn 7/15/20 7:33 AM, Lingo Coder wrote: Thank you Robert, ?...And send us what it prints...? You'll see below that right after I did `/set format normal typeKind`it still said, ?created *method*...?. I also recorded it. [1]But then right after `/set feedback verbose`, it said ?created*record*?.However, after an `/exit` and a relaunch of `jshell --enable-preview`,itreverted back to ?created *method*...?/?dropped *method*... ?.I _vaguely_ recall creating `mymode` and doing `/set feedback -retainmymode`way back in 2017 when JShell first came out. I think. I'm not 100% suretho.So I'm guessing I need to do `/set feedback -retain verbose` topermanentlyget ?created *record*...? Correct?TIA.----...jshell> /set feedback| /set feedback -retain mymode|| Retained feedback modes:| mymode| Available feedback modes:| concise| mymode| normal| silent| verbosejshell> /set format normal typeKind| /set format normal typeKind "class" class| /set format normal typeKind "interface" interface| /set format normal typeKind "enum" enum| /set format normal typeKind "annotation interface" annotation| /set format normal typeKind "record" recordjshell> public record ConstExpr(Expr e) implements Expr{}| created method ConstExpr(), however, it cannot be referenced untilclass Expr is declaredjshell> /type| record ConstExpr| which cannot be referenced until class Expr is declaredjshell> /types| record ConstExpr| which cannot be referenced until class Expr is declaredjshell> /method| void print(boolean)| void print(char)| void print(int)| void print(long)| void print(float)| void print(double)| void print(char s[])| void print(String)| void print(Object)| void println()| void println(boolean)| void println(char)| void println(int)| void println(long)| void println(float)| void println(double)| void println(char s[])| void println(String)| void println(Object)| void printf(java.util.Locale,String,Object...)| void printf(String,Object...)jshell> /drop ConstExpr| dropped method ConstExpr()jshell> /set feedback verbose| Feedback mode: verbosejshell> public record ConstExpr(Expr e) implements Expr{}| created record ConstExpr, however, it cannot be referenced untilclass Expr is declaredjshell> /type| record ConstExpr| which cannot be referenced until class Expr is declaredjshell> class Expr{}| created class Exprjshell> /types| record ConstExpr| which cannot be referenced until this error is corrected:| interface expected here| public record ConstExpr(Expr e) implements Expr{}| ^--^| class Exprjshell> /drop Expr| dropped class Exprjshell> interface Expr{}| created interface Expr| update replaced record ConstExprjshell> /types| record ConstExpr| interface Exprjshell> /drop ConstExpr| dropped record ConstExpr...----[1] https://imgur.com/ePyilYo-------- Original Message --------Subject: Re:_Records_are_called_?methods?_in_JSh ellFrom: Robert Field Date: Tue, July 14, 2020 8:07 pmTo: Lingo Coder ,"kulla-dev at openjdk.java.net" ,"jorn.vernee at oracle.com" I have a theory, maybe the following can illuminate...Couple more things to try:/set feedback/set format normal typeKindAnd send us what it prints.Also, after you have entered:public record ConstExpr(Expr e) implements Expr{}Type:/typeand/methodSeparately, what do they print?Oh, and if you want to try one more thing:/set feedback verbosepublic record ConstExpr(Expr e) implements Expr{}Sorry, I don't have Windows, but I believe Jan has access.-RobertOn 2020-07-14 18:35, Lingo Coder wrote: Thanks Robert, ?...Can you do:jshell --full-version...? I did that. It says jshell 15-ea+31-1502 [1]What version of Windows are you other guys trying this in? I'm onWindows 7. ?...I'm guessing you may be using an older JDK...? As I show in [1] and in earlier screen recordings, I completelyclear my $PATH to confirm that there is no other jshell.exe onthe $PATH.I have not installed any JDKs with an installer or anythinglike that. For that reason, I rule out anything registry-related.I do have an early access release of 14-Valhallabuild 14-valhalla+4-55 on my workstation. But, that wasinstalled by simply unzipping the archive into ajdk-14.L.world.Build.14-valhalla+4-55 folder. More importantly,that build doesn't even have the records nor the sealed typesfeatures.I also have GA releases of OpenJDK 12 & 13 in their own folders.But again, not only are they isolated well out of the way ofthe $PATH I run jshell 15 in, they don't even have records andsealed types functionality.If _any_ other JDK were somehow in the $PATH, it would besurprising if records and sealed types even worked _at all_;let alone the misnaming as ?methods? issue Right? Pleasecorrect me if I'm wrong?[1] https://imgur.com/cMsAl5f-------- Original Message --------Subject: Re:_Records_are_called_?methods?_in_JSh ellFrom: Robert Field Date: Tue, July 14, 2020 3:57 pmTo: kulla-dev at openjdk.java.net, jorn.vernee at oracle.com,plugins at lingocoder.comI'm guessing you may be using an older JDK. I get:jshell> public record ConstExpr(Expr e) implements Expr{}| created record ConstExprjshell> /drop ConstExpr| dropped record ConstExprCan you do:jshell --full-versionThanks,Robert From sormuras at gmail.com Thu Jul 16 09:52:51 2020 From: sormuras at gmail.com (Christian Stein) Date: Thu, 16 Jul 2020 11:52:51 +0200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: <40adde2b-0b93-51e1-471d-9ca5cb8ae313@oracle.com> References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> <40adde2b-0b93-51e1-471d-9ca5cb8ae313@oracle.com> Message-ID: Replaced some / with \ ... ;-) It exactly compiled, started, and doesn't eat CPU cycles anymore like you wrote. So +1 for the patch. Will add a comment to the issue as well. Cheers, Christian On Thu, Jul 16, 2020 at 11:44 AM Jan Lahoda wrote: > On 15. 07. 20 19:23, Christian Stein wrote: > > Hi Jan, > > > > I reviewed your CR on the webrev and think it resolves the issue. > > > > I also +1'ed https://github.com/jline/jline3/issues/552 > > > > Two questions: > > > > - Does it only happen on Windows? If yes, why? > > I believe Windows only. The reason is that inputs work differently on > Linux and on Windows. On Linux, reading goes basically from System.in, > with some wrapping, but not through NonBlockingReaderInputStream, as no > Reader->InputStream conversion is needed. > > On Windows, the primary source of data is a Reader, based on reading > characters directly from the console (System.in is basically ignored, to > my knowledge). That gets converted to InputStream using > NonBlockingReaderInputStream. > > > - How can I, without compiling JShell on my own, verify it? > > Patch that class (*) in my JDK installation temporarily? > > It should be easy to compile the class and apply it: > -create a directory called 8249367 somewhere > -download: > > http://hg.openjdk.java.net/jdk/jdk15/raw-file/244298608b49/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java > into: > 8249367/src/jdk/internal/jshell/tool/StopDetectingInputStream.java > -using a recent JDK 15 build, inside the 8249367 directory do: > javac --patch-module jdk.jshell=src -d classes > src/jdk/internal/jshell/tool/StopDetectingInputStream.java > jshell --enable-preview -J--patch-module=jdk.jshell=classes > > That should run JShell with the patch. > > Jan > > > > > Cheers, > > Christian > > > > (*) If you could send the compiled class via mail, that would be great. > > > > On Wed, Jul 15, 2020 at 2:18 PM Jan Lahoda > > wrote: > > > > FWIW, I've sent: > > > https://mail.openjdk.java.net/pipermail/kulla-dev/2020-July/002551.html > > > > I'd be happy if someone else could verify it solves the issue (given > > the > > upcoming RDP2). > > > > Thanks, > > Jan > > > > On 15. 07. 20 9:15, Christian Stein wrote: > > > JShell 16-ea is affected, too. > > > > > > Hoping that the fix is as simple as you think, Jan. > > > Perhaps, it can make its way into JShell 15 before GA. > > > > > > Cheers, > > > Christian > > > > > > > > > On Tue, Jul 14, 2020 at 9:05 PM Jan Lahoda > > > > >> > wrote: > > > > > > Hi, > > > > > > Thanks for the report and analysis. I've filled: > > > https://bugs.openjdk.java.net/browse/JDK-8249367 > > > > > > I think the issue is in: > > > > > > http://hg.openjdk.java.net/jdk/jdk/file/1e249ca8d585/src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlocking.java#l104 > > > > > > If the timeout is zero (which it is when invoked from > > > StopDetectingInputStream, as it calls the read method without > > timeout), > > > the method invocation will exit immediately, and it will be > > immediately > > > called again, etc. > > > > > > Jan > > > > > > On 13. 07. 20 6:00, Aaron Scott-Boddendijk wrote: > > > > I can confirm the CPU behaves as suggested with a sequence > of > > > entering and > > > > leaving `/edit`. > > > > > > > > Thanks Christian. > > > > > > > > -- > > > > Aaron Scott-Boddendijk > > > > > > > > On Mon, Jul 13, 2020 at 3:27 PM Christian Stein > > > > > >> wrote: > > > > > > > >> It's coming from the "while(true)"-loop in > > > StopDetectingInputStream.java > > > >> [0]. > > > >> > > > >> Aaron, try to open an external editor within the JShell > > session via > > > >> > > > >> /edit > > > >> > > > >> The CPU usage should drop immediately to normal levels. > > > >> As soon as you close the editor (it's the internal JShell > > Edit > > > Pad for me) > > > >> the thread is again eating CPU cycles. Can you confirm > this? > > > >> > > > >> While the editor is opened, the thread waits via > > > >> > > > >> > > > > > jdk.internal.jshell.tool.StopDetectingInputStream.waitInputNeeded > > > line: > > > >> 164 > > > >> > > > >> If no editor is open, the "input.read()" method does > > never wait: > > > >> > > > >> > > > >> > > > > > > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > > > >> line: 66 > > > >> > > > >> Cheers, > > > >> Christian > > > >> > > > >> [0]: > > > >> > > > >> > > > > > > https://github.com/openjdk/jdk/blob/faf4d7ccb792b16092c791c0ac77acdd440dbca1/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java#L57-L74 > > > >> > > > >> On Mon, Jul 13, 2020 at 5:05 AM Christian Stein > > > > > >> > > > >> wrote: > > > >> > > > >>> Seems like "read line" from "jline" is underlying reason: > > > >>> > > > >>> Thread-2 [31] (RUNNABLE) > > > >>> > > > >>> > > > >> > > > > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await > > > >>> line: 1749 > > > >>> > jdk.internal.org.jline.utils.NonBlockingPumpReader.read > > > line: 77 > > > >>> jdk.internal.org.jline.utils.NonBlockingReader.read > > line: 57 > > > >>> > > > >>> > > > >> > > > > > > jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read > > > >>> line: 104 > > > >>> > jdk.internal.org.jline.utils.NonBlockingInputStream.read > > > line: 36 > > > >>> > > > >>> > > > >> > > > > > > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0 > > > >>> line: 66 > > > >>> > > > >>> > > > >> > > > > > > jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$347/0x0000000800cff330.run > > > >>> line: not available > > > >>> java.lang.Thread.run line: 832 > > > >>> > > > >>> It produces a constant high CPU usage and allocates a > lot of > > > RAM per > > > >>> second. > > > >>> > > > >>> Thread Name Thread State Blocked Count Total CPU Usage > > Deadlocked > > > >>> Allocated Memory > > > >>> Thread-2 RUNNABLE 1 0.06252084028009336 Not Enabled > > 196198305136 B > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> On Mon, Jul 13, 2020 at 4:52 AM Christian Stein > > > > > >> > > > >>> wrote: > > > >>> > > > >>>> Hi Aaron, > > > >>>> > > > >>>> I observe the same behaviour of JShell 15 build 30. > > > >>>> > > > >>>> Here, the 100% CPU workload is split on to 3-4 logical > > processors. > > > >>>> Grabbed an animated GIF of "jshell.exe -- /exit" > > session at [0]. > > > >>>> To me, it looks like a loop is running wild, w/o a > > > >>>> Thread.yield()/.sleep() call. > > > >>>> > > > >>>> Microsoft Windows [Version 10.0.19041.329] > > > >>>> > > > >>>> openjdk 15-ea 2020-09-15 > > > >>>> OpenJDK Runtime Environment (build 15-ea+30-1476) > > > >>>> OpenJDK 64-Bit Server VM (build 15-ea+30-1476, mixed > mode, > > > sharing) > > > >>>> > > > >>>> Cheers, > > > >>>> Christian > > > >>>> > > > >>>> [0]: > > > >>>> > > > >> > > > > > > https://drive.google.com/file/d/1KOQO5B9WrM4C43K3AB7H9VVPuh9hdCOe/view?usp=sharing > > > >>>> > > > >>>> > > > >>>> On Mon, Jul 13, 2020 at 4:24 AM Aaron Scott-Boddendijk < > > > >> talden at gmail.com > > >> > > > >>>> wrote: > > > >>>> > > > >>>>> This still exists in JDK 15 build 31. > > > >>>>> > > > >>>>> Is any other Windows user able to reproduce this? I > > have two > > > machines, > > > >>>>> one > > > >>>>> laptop and one desktop that show a CPU thread > constantly @ > > > 100% just by > > > >>>>> starting JShell. For the desktop machine that's not a > > major > > > issue but > > > >> for > > > >>>>> the laptop this spins up the fans and eats the battery. > > > >>>>> > > > >>>>> JShell in JDK 14 is fine. > > > >>>>> > > > >>>>> I've yet to hear of any other user confirming this > issue. > > > >>>>> > > > >>>>> -- > > > >>>>> Aaron Scott-Boddendijk > > > >>>>> > > > >>>>> > > > >>>>> On Fri, Jun 26, 2020 at 2:00 PM Aaron Scott-Boddendijk > < > > > >> talden at gmail.com > > > > > > >>>>>> > > > >>>>> wrote: > > > >>>>> > > > >>>>>> Just confirming that: > > > >>>>>> > > > >>>>>> * This still exists in JDK 15 build 29 > > > >>>>>> * Occurs on multiple unrelated Windows 10 machines > with > > > differing > > > >> major > > > >>>>>> versions of the OS. > > > >>>>>> * Does not occur in JDK 14.01 on these machines > > (OpenJDK 64-Bit > > > >> Server > > > >>>>> VM > > > >>>>>> Zulu14.28+21-CA) > > > >>>>>> * Does not appear to occur on Linux > > > >>>>>> > > > >>>>>> -- > > > >>>>>> Aaron Scott-Boddendijk > > > >>>>>> > > > >>>>>> > > > >>>>>> On Tue, Jun 16, 2020 at 11:16 AM Aaron > Scott-Boddendijk < > > > >>>>> talden at gmail.com > > >> > > > >>>>>> wrote: > > > >>>>>> > > > >>>>>>> This is the thread-dump from the JVM that VisualVM > > sees as > > > using a > > > >>>>> core... > > > >>>>>>> > > > >>>>>>> 2020-06-16 11:07:35 > > > >>>>>>> Full thread dump OpenJDK 64-Bit Server VM > (15-ea+27-1372 > > > mixed mode, > > > >>>>>>> sharing): > > > >>>>>>> > > > >>>>>>> Threads class SMR info: > > > >>>>>>> _java_thread_list=0x000001e34a6040f0, length=23, > > elements={ > > > >>>>>>> 0x000001e31c1a1dc0, 0x000001e349035ee0, > > 0x000001e349037250, > > > >>>>>>> 0x000001e349058ae0, > > > >>>>>>> 0x000001e34905c5b0, 0x000001e34905f710, > > 0x000001e3490603f0, > > > >>>>>>> 0x000001e349065140, > > > >>>>>>> 0x000001e34906d620, 0x000001e349b36a20, > > 0x000001e349b8c690, > > > >>>>>>> 0x000001e349da3400, > > > >>>>>>> 0x000001e349daa7c0, 0x000001e349dbb640, > > 0x000001e34a141140, > > > >>>>>>> 0x000001e349d555c0, > > > >>>>>>> 0x000001e34b07f030, 0x000001e34a461c90, > > 0x000001e34a45fae0, > > > >>>>>>> 0x000001e34a45ffb0, > > > >>>>>>> 0x000001e34a4617c0, 0x000001e34a462160, > > 0x000001e34a45f610 > > > >>>>>>> } > > > >>>>>>> > > > >>>>>>> "main" #1 prio=5 os_prio=0 cpu=1078.13ms > elapsed=341.81s > > > >>>>>>> tid=0x000001e31c1a1dc0 nid=0x16b0 in Object.wait() > > > >>>>> [0x000000340d9fe000] > > > >>>>>>> java.lang.Thread.State: TIMED_WAITING (on object > > monitor) > > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea > /Native > > > Method) > > > >>>>>>> - waiting on > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 15-ea > > > >>>>>>> /NonBlockingInputStreamImpl.java:139) > > > >>>>>>> - locked <0x000000060fe87338> (a > > > >>>>>>> jdk.internal.jshell.tool.ConsoleIOContext$1) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > > > >>>>>>> /NonBlockingInputStream.java:62) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 15-ea > > > >>>>>>> /NonBlocking.java:168) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > > > >>>>>>> /NonBlockingReader.java:57) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 15-ea > > > >>>>>>> /BindingReader.java:160) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > > > >>>>>>> /BindingReader.java:110) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 15-ea > > > >>>>>>> /BindingReader.java:61) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 15-ea > > > >>>>>>> /LineReaderImpl.java:913) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 15-ea > > > >>>>>>> /LineReaderImpl.java:946) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 15-ea > > > >>>>>>> /ConsoleIOContext.java:154) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > > > >>>>>>> /LineReaderImpl.java:637) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 15-ea > > > >>>>>>> /LineReaderImpl.java:454) > > > >>>>>>> at > > > >>>>>>> > > > > > jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 15-ea > > > >>>>>>> /ConsoleIOContext.java:229) > > > >>>>>>> at > > > >>>>> > > jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 15-ea > > > >>>>>>> /JShellTool.java:1254) > > > >>>>>>> at > > > jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 15-ea > > > >>>>>>> /JShellTool.java:1190) > > > >>>>>>> at > > > >> jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 15-ea > > > >>>>>>> /JShellTool.java:991) > > > >>>>>>> at > > > >>>>>>> > > > > jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 15-ea > > > >>>>>>> /JShellToolBuilder.java:254) > > > >>>>>>> at > > > >>>>>>> > > > > jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 15-ea > > > >>>>>>> /JShellToolProvider.java:120) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "Reference Handler" #2 daemon prio=10 os_prio=2 > > cpu=0.00ms > > > >>>>>>> elapsed=341.79s tid=0x000001e349035ee0 nid=0x13fc > > waiting on > > > >> condition > > > >>>>>>> [0x000000340e0fe000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> at > > > >>>>>>> > > > > > java.lang.ref.Reference.waitForReferencePendingList(java.base at 15-ea > > > >>>>> /Native > > > >>>>>>> Method) > > > >>>>>>> at > > > >>>>>>> > > > > java.lang.ref.Reference.processPendingReferences(java.base at 15-ea > > > >>>>>>> /Reference.java:241) > > > >>>>>>> at > > > >>>>> > > java.lang.ref.Reference$ReferenceHandler.run(java.base at 15-ea > > > >>>>>>> /Reference.java:213) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms > > > elapsed=341.79s > > > >>>>>>> tid=0x000001e349037250 nid=0x2a60 in Object.wait() > > > >>>>> [0x000000340e1fe000] > > > >>>>>>> java.lang.Thread.State: WAITING (on object > monitor) > > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea > /Native > > > Method) > > > >>>>>>> - waiting on <0x0000000601400bc0> (a > > > >>>>>>> java.lang.ref.ReferenceQueue$Lock) > > > >>>>>>> at > > java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > > > >>>>>>> /ReferenceQueue.java:155) > > > >>>>>>> - locked <0x0000000601400bc0> (a > > > >>>>>>> java.lang.ref.ReferenceQueue$Lock) > > > >>>>>>> at > > java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > > > >>>>>>> /ReferenceQueue.java:176) > > > >>>>>>> at > > > >> > java.lang.ref.Finalizer$FinalizerThread.run(java.base at 15-ea > > > >>>>>>> /Finalizer.java:170) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "Signal Dispatcher" #4 daemon prio=9 os_prio=2 > > cpu=0.00ms > > > >>>>> elapsed=341.78s > > > >>>>>>> tid=0x000001e349058ae0 nid=0x35c8 runnable > > > [0x0000000000000000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "Attach Listener" #5 daemon prio=5 os_prio=2 > > cpu=125.00ms > > > >>>>> elapsed=341.78s > > > >>>>>>> tid=0x000001e34905c5b0 nid=0x3e0c waiting on > condition > > > >>>>> [0x0000000000000000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "Service Thread" #6 daemon prio=9 os_prio=0 > cpu=0.00ms > > > >> elapsed=341.78s > > > >>>>>>> tid=0x000001e34905f710 nid=0x398c runnable > > > [0x0000000000000000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "C2 CompilerThread0" #7 daemon prio=9 os_prio=2 > > cpu=1781.25ms > > > >>>>>>> elapsed=341.78s tid=0x000001e3490603f0 nid=0xcf0 > > waiting on > > > >> condition > > > >>>>>>> [0x0000000000000000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> No compile task > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "C1 CompilerThread0" #10 daemon prio=9 os_prio=2 > > cpu=765.63ms > > > >>>>>>> elapsed=341.78s tid=0x000001e349065140 nid=0x3e54 > > waiting on > > > >> condition > > > >>>>>>> [0x0000000000000000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> No compile task > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "Sweeper thread" #11 daemon prio=9 os_prio=2 > cpu=0.00ms > > > >>>>> elapsed=341.78s > > > >>>>>>> tid=0x000001e34906d620 nid=0x38bc runnable > > > [0x0000000000000000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "Notification Thread" #12 daemon prio=9 os_prio=0 > > cpu=0.00ms > > > >>>>>>> elapsed=341.76s tid=0x000001e349b36a20 nid=0x49b8 > > runnable > > > >>>>>>> [0x0000000000000000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "Common-Cleaner" #13 daemon prio=8 os_prio=1 > cpu=0.00ms > > > >>>>> elapsed=341.75s > > > >>>>>>> tid=0x000001e349b8c690 nid=0x26e4 in Object.wait() > > > >>>>> [0x000000340eaff000] > > > >>>>>>> java.lang.Thread.State: TIMED_WAITING (on object > > monitor) > > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea > /Native > > > Method) > > > >>>>>>> - waiting on > > > >>>>>>> at > > java.lang.ref.ReferenceQueue.remove(java.base at 15-ea > > > >>>>>>> /ReferenceQueue.java:155) > > > >>>>>>> - locked <0x0000000601401a78> (a > > > >>>>>>> java.lang.ref.ReferenceQueue$Lock) > > > >>>>>>> at > > jdk.internal.ref.CleanerImpl.run(java.base at 15-ea > > > >>>>>>> /CleanerImpl.java:148) > > > >>>>>>> at > > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > > >>>>>>> at > > > jdk.internal.misc.InnocuousThread.run(java.base at 15-ea > > > >>>>>>> /InnocuousThread.java:134) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "JDI Internal Event Handler" #17 daemon prio=5 > os_prio=0 > > > cpu=15.63ms > > > >>>>>>> elapsed=341.39s tid=0x000001e349da3400 nid=0x68 in > > > Object.wait() > > > >>>>>>> [0x000000340effe000] > > > >>>>>>> java.lang.Thread.State: WAITING (on object > monitor) > > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea > /Native > > > Method) > > > >>>>>>> - waiting on > > > >>>>>>> at > > > java.lang.Object.wait(java.base at 15-ea/Object.java:321) > > > >>>>>>> at > > > >>>>> > > com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > > > >>>>>>> /EventQueueImpl.java:190) > > > >>>>>>> - locked <0x000000060154b630> (a > > > >>>>> com.sun.tools.jdi.EventQueueImpl) > > > >>>>>>> at > > > >>>>> > > com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 15-ea > > > >>>>>>> /EventQueueImpl.java:125) > > > >>>>>>> at > > > com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 15-ea > > > >>>>>>> /InternalEventHandler.java:61) > > > >>>>>>> at > > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "JDI Target VM Interface" #16 daemon prio=5 os_prio=0 > > > cpu=46.88ms > > > >>>>>>> elapsed=341.39s tid=0x000001e349daa7c0 nid=0x3d04 > > runnable > > > >>>>>>> [0x000000340f0fe000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> at > > > sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native > > > >>>>>>> Method) > > > >>>>>>> at > > sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > > > >>>>>>> /SocketDispatcher.java:46) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:261) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:312) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:350) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:803) > > > >>>>>>> at > > > java.net.Socket$SocketInputStream.read(java.base at 15-ea > > > >>>>>>> /Socket.java:981) > > > >>>>>>> at > > > java.net.Socket$SocketInputStream.read(java.base at 15-ea > > > >>>>>>> /Socket.java:976) > > > >>>>>>> at > > > >> > com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 15-ea > > > >>>>>>> /SocketConnection.java:82) > > > >>>>>>> - locked <0x000000060154b998> (a > > java.lang.Object) > > > >>>>>>> at > com.sun.tools.jdi.TargetVM.run(jdk.jdi at 15-ea > > > >>>>>>> /TargetVM.java:124) > > > >>>>>>> at > > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - <0x0000000601577110> (a > > > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > > > >>>>>>> > > > >>>>>>> "event-handler" #18 daemon prio=5 os_prio=0 > cpu=0.00ms > > > >> elapsed=341.38s > > > >>>>>>> tid=0x000001e349dbb640 nid=0x203c in Object.wait() > > > >>>>> [0x000000340edfe000] > > > >>>>>>> java.lang.Thread.State: WAITING (on object > monitor) > > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea > /Native > > > Method) > > > >>>>>>> - waiting on > > > >>>>>>> at > > > java.lang.Object.wait(java.base at 15-ea/Object.java:321) > > > >>>>>>> at > > > >>>>> > > com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 15-ea > > > >>>>>>> /EventQueueImpl.java:190) > > > >>>>>>> - locked <0x000000060154bc28> (a > > > >>>>> com.sun.tools.jdi.EventQueueImpl) > > > >>>>>>> at > > > com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > > > >>>>>>> /EventQueueImpl.java:97) > > > >>>>>>> at > > > com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 15-ea > > > >>>>>>> /EventQueueImpl.java:83) > > > >>>>>>> at > > > jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 15-ea > > > >>>>>>> /JdiEventHandler.java:79) > > > >>>>>>> at > > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "output reader" #19 daemon prio=5 os_prio=0 > cpu=0.00ms > > > >> elapsed=341.31s > > > >>>>>>> tid=0x000001e34a141140 nid=0x49c0 runnable > > > [0x000000340eeff000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> at > > > sun.nio.ch.SocketDispatcher.read0(java.base at 15-ea/Native > > > >>>>>>> Method) > > > >>>>>>> at > > sun.nio.ch.SocketDispatcher.read(java.base at 15-ea > > > >>>>>>> /SocketDispatcher.java:46) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl.tryRead(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:261) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:312) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:350) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:803) > > > >>>>>>> at > > > java.net.Socket$SocketInputStream.read(java.base at 15-ea > > > >>>>>>> /Socket.java:981) > > > >>>>>>> at > > > java.net.Socket$SocketInputStream.read(java.base at 15-ea > > > >>>>>>> /Socket.java:976) > > > >>>>>>> at > > java.io.FilterInputStream.read(java.base at 15-ea > > > >>>>>>> /FilterInputStream.java:82) > > > >>>>>>> at > > > >> jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 15-ea > > > >>>>>>> /DemultiplexInput.java:58) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - <0x0000000601553510> (a > > > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > > > >>>>>>> > > > >>>>>>> "Thread-0" #21 daemon prio=5 os_prio=0 cpu=312.50ms > > > elapsed=341.22s > > > >>>>>>> tid=0x000001e349d555c0 nid=0x4d88 waiting on > condition > > > >>>>> [0x000000340f1fe000] > > > >>>>>>> java.lang.Thread.State: WAITING (parking) > > > >>>>>>> at > > > jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native > > > >>>>> Method) > > > >>>>>>> - parking to wait for <0x0000000601550fc0> > (a > > > >>>>>>> > > > >> > > > > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > > > >>>>>>> at > > > >> > java.util.concurrent.locks.LockSupport.park(java.base at 15-ea > > > >>>>>>> /LockSupport.java:341) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 15-ea > > > >>>>>>> /AbstractQueuedSynchronizer.java:505) > > > >>>>>>> at > > > >>>>> > > java.util.concurrent.ForkJoinPool.managedBlock(java.base at 15-ea > > > >>>>>>> /ForkJoinPool.java:3137) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > > > >>>>>>> /AbstractQueuedSynchronizer.java:1614) > > > >>>>>>> at > > > >>>>> > > java.util.concurrent.LinkedBlockingQueue.take(java.base at 15-ea > > > >>>>>>> /LinkedBlockingQueue.java:435) > > > >>>>>>> at > > > >>>>> > > java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > > > >>>>>>> /ThreadPoolExecutor.java:1056) > > > >>>>>>> at > > > >>>>>>> > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > > > >>>>>>> /ThreadPoolExecutor.java:1116) > > > >>>>>>> at > > > >>>>>>> > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > > > >>>>>>> /ThreadPoolExecutor.java:630) > > > >>>>>>> at > > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "Thread-2" #23 daemon prio=5 os_prio=0 > cpu=338859.38ms > > > >> elapsed=340.58s > > > >>>>>>> tid=0x000001e34b07f030 nid=0xac0 runnable > > [0x000000340f3fe000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 15-ea > > > >>>>>>> /AbstractQueuedSynchronizer.java:1749) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.utils.NonBlockingPumpReader.read(jdk.internal.le at 15-ea > > > >>>>>>> /NonBlockingPumpReader.java:77) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 15-ea > > > >>>>>>> /NonBlockingReader.java:57) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.utils.NonBlocking$NonBlockingReaderInputStream.read(jdk.internal.le at 15-ea > > > >>>>>>> /NonBlocking.java:104) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 15-ea > > > >>>>>>> /NonBlockingInputStream.java:36) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 15-ea > > > >>>>>>> /StopDetectingInputStream.java:66) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$410/0x0000000800d2eb28.run(jdk.jshell at 15-ea > > > >>>>> /Unknown > > > >>>>>>> Source) > > > >>>>>>> at > > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - <0x00000006028b4318> (a > > > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > > > >>>>>>> > > > >>>>>>> "WindowsStreamPump" #25 daemon prio=5 os_prio=0 > > cpu=0.00ms > > > >>>>>>> elapsed=340.53s tid=0x000001e34a461c90 nid=0x3688 > > runnable > > > >>>>>>> [0x000000340f4fe000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.terminal.impl.jna.win.Kernel32Impl.WaitForSingleObject(jdk.internal.le at 15-ea > > > >>>>> /Native > > > >>>>>>> Method) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.readConsoleInput(jdk.internal.le at 15-ea > > > >>>>>>> /JnaWinSysTerminal.java:185) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.terminal.impl.jna.win.JnaWinSysTerminal.processConsoleInput(jdk.internal.le at 15-ea > > > >>>>>>> /JnaWinSysTerminal.java:108) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal.pump(jdk.internal.le at 15-ea > > > >>>>>>> /AbstractWindowsTerminal.java:465) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.terminal.impl.AbstractWindowsTerminal$$Lambda$417/0x0000000800d310f8.run(jdk.internal.le at 15-ea > > > >>>>> /Unknown > > > >>>>>>> Source) > > > >>>>>>> at > > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "null non blocking reader thread" #26 daemon prio=5 > > os_prio=0 > > > >>>>> cpu=0.00ms > > > >>>>>>> elapsed=340.26s tid=0x000001e34a45fae0 nid=0x488 in > > > Object.wait() > > > >>>>>>> [0x000000340f6ff000] > > > >>>>>>> java.lang.Thread.State: WAITING (on object > monitor) > > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea > /Native > > > Method) > > > >>>>>>> - waiting on > > > >>>>>>> at > > > java.lang.Object.wait(java.base at 15-ea/Object.java:321) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > > > > jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 15-ea > > > >>>>>>> /StopDetectingInputStream.java:98) > > > >>>>>>> - locked <0x0000000601e2b650> (a > > > >>>>>>> jdk.internal.jshell.tool.StopDetectingInputStream) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 15-ea > > > >>>>>>> /NonBlockingInputStreamImpl.java:216) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$584/0x0000000800d4f088.run(jdk.internal.le at 15-ea > > > >>>>> /Unknown > > > >>>>>>> Source) > > > >>>>>>> at > > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "RMI TCP Accept-0" #27 daemon prio=5 os_prio=0 > > cpu=0.00ms > > > >>>>> elapsed=180.89s > > > >>>>>>> tid=0x000001e34a45ffb0 nid=0x45f0 runnable > > > [0x000000340d8fe000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> at sun.nio.ch.Net.accept(java.base at 15-ea > /Native > > > Method) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl.accept(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:755) > > > >>>>>>> at > > java.net.ServerSocket.implAccept(java.base at 15-ea > > > >>>>>>> /ServerSocket.java:684) > > > >>>>>>> at > > > java.net.ServerSocket.platformImplAccept(java.base at 15-ea > > > >>>>>>> /ServerSocket.java:650) > > > >>>>>>> at > > java.net.ServerSocket.implAccept(java.base at 15-ea > > > >>>>>>> /ServerSocket.java:626) > > > >>>>>>> at > > java.net.ServerSocket.implAccept(java.base at 15-ea > > > >>>>>>> /ServerSocket.java:583) > > > >>>>>>> at > java.net.ServerSocket.accept(java.base at 15-ea > > > >>>>>>> /ServerSocket.java:540) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(jdk.management.agent at 15-ea > > > >>>>>>> /LocalRMIServerSocketFactory.java:52) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi at 15-ea > > > >>>>>>> /TCPTransport.java:413) > > > >>>>>>> at > > > >>>>>>> > > > > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi at 15-ea > > > >>>>>>> /TCPTransport.java:377) > > > >>>>>>> at > > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - <0x0000000602e53118> (a > > > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > > > >>>>>>> > > > >>>>>>> "RMI TCP Connection(1)-10.0.201.131" #28 daemon > prio=5 > > > os_prio=0 > > > >>>>>>> cpu=437.50ms elapsed=180.87s tid=0x000001e34a4617c0 > > nid=0x4790 > > > >>>>> runnable > > > >>>>>>> [0x000000340fbfe000] > > > >>>>>>> java.lang.Thread.State: RUNNABLE > > > >>>>>>> at > > sun.nio.ch.Net.poll(java.base at 15-ea/Native Method) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl.park(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:181) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl.timedRead(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:285) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl.implRead(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:309) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl.read(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:350) > > > >>>>>>> at > > sun.nio.ch.NioSocketImpl$1.read(java.base at 15-ea > > > >>>>>>> /NioSocketImpl.java:803) > > > >>>>>>> at > > > java.net.Socket$SocketInputStream.read(java.base at 15-ea > > > >>>>>>> /Socket.java:981) > > > >>>>>>> at > > java.io.BufferedInputStream.fill(java.base at 15-ea > > > >>>>>>> /BufferedInputStream.java:244) > > > >>>>>>> at > > java.io.BufferedInputStream.read(java.base at 15-ea > > > >>>>>>> /BufferedInputStream.java:263) > > > >>>>>>> - locked <0x0000000602e19470> (a > > > >> java.io.BufferedInputStream) > > > >>>>>>> at > > java.io.FilterInputStream.read(java.base at 15-ea > > > >>>>>>> /FilterInputStream.java:82) > > > >>>>>>> at > > > >>>>>>> > > > > sun.rmi.transport.tcp.TCPTransport.handleMessages(java.rmi at 15-ea > > > >>>>>>> /TCPTransport.java:569) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(java.rmi at 15-ea > > > >>>>>>> /TCPTransport.java:828) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(java.rmi at 15-ea > > > >>>>>>> /TCPTransport.java:705) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$686/0x0000000800da3998.run(java.rmi at 15-ea > > > >>>>> /Unknown > > > >>>>>>> Source) > > > >>>>>>> at > > > >>>>>>> > > > > java.security.AccessController.executePrivileged(java.base at 15-ea > > > >>>>>>> /AccessController.java:753) > > > >>>>>>> at > > > >> > java.security.AccessController.doPrivileged(java.base at 15-ea > > > >>>>>>> /AccessController.java:391) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > > > > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(java.rmi at 15-ea > > > >>>>>>> /TCPTransport.java:704) > > > >>>>>>> at > > > >>>>>>> > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > > > >>>>>>> /ThreadPoolExecutor.java:1130) > > > >>>>>>> at > > > >>>>>>> > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > > > >>>>>>> /ThreadPoolExecutor.java:630) > > > >>>>>>> at > > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - <0x0000000602e19708> (a > > > >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker) > > > >>>>>>> - <0x0000000602e59038> (a > > > >>>>>>> java.util.concurrent.locks.ReentrantLock$NonfairSync) > > > >>>>>>> > > > >>>>>>> "RMI Scheduler(0)" #29 daemon prio=5 os_prio=0 > > cpu=0.00ms > > > >>>>> elapsed=180.86s > > > >>>>>>> tid=0x000001e34a462160 nid=0x1df0 waiting on > condition > > > >>>>> [0x000000340fcfe000] > > > >>>>>>> java.lang.Thread.State: TIMED_WAITING (parking) > > > >>>>>>> at > > > jdk.internal.misc.Unsafe.park(java.base at 15-ea/Native > > > >>>>> Method) > > > >>>>>>> - parking to wait for <0x0000000602e1af00> > (a > > > >>>>>>> > > > >> > > > > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > > > >>>>>>> at > > > >>>>>>> > > > > java.util.concurrent.locks.LockSupport.parkNanos(java.base at 15-ea > > > >>>>>>> /LockSupport.java:252) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 15-ea > > > >>>>>>> /AbstractQueuedSynchronizer.java:1661) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > > > >>>>>>> /ScheduledThreadPoolExecutor.java:1182) > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 15-ea > > > >>>>>>> /ScheduledThreadPoolExecutor.java:899) > > > >>>>>>> at > > > >>>>> > > java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 15-ea > > > >>>>>>> /ThreadPoolExecutor.java:1056) > > > >>>>>>> at > > > >>>>>>> > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 15-ea > > > >>>>>>> /ThreadPoolExecutor.java:1116) > > > >>>>>>> at > > > >>>>>>> > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 15-ea > > > >>>>>>> /ThreadPoolExecutor.java:630) > > > >>>>>>> at > > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "JMX server connection timeout 30" #30 daemon prio=5 > > os_prio=0 > > > >>>>> cpu=0.00ms > > > >>>>>>> elapsed=180.86s tid=0x000001e34a45f610 nid=0x2fe8 in > > > Object.wait() > > > >>>>>>> [0x000000340fdff000] > > > >>>>>>> java.lang.Thread.State: TIMED_WAITING (on object > > monitor) > > > >>>>>>> at java.lang.Object.wait(java.base at 15-ea > /Native > > > Method) > > > >>>>>>> - waiting on > > > >>>>>>> at > > > >>>>>>> > > > >>>>> > > > >> > > > > > > com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(java.management at 15-ea > > > >>>>>>> /ServerCommunicatorAdmin.java:171) > > > >>>>>>> - locked <0x0000000602e1ca08> (a [I) > > > >>>>>>> at > > > java.lang.Thread.run(java.base at 15-ea/Thread.java:832) > > > >>>>>>> > > > >>>>>>> Locked ownable synchronizers: > > > >>>>>>> - None > > > >>>>>>> > > > >>>>>>> "VM Thread" os_prio=2 cpu=515.63ms elapsed=341.79s > > > >>>>> tid=0x000001e349031eb0 > > > >>>>>>> nid=0x540 runnable > > > >>>>>>> > > > >>>>>>> "GC Thread#0" os_prio=2 cpu=328.13ms elapsed=341.80s > > > >>>>>>> tid=0x000001e31c218710 nid=0x19e8 runnable > > > >>>>>>> > > > >>>>>>> "GC Thread#1" os_prio=2 cpu=265.63ms elapsed=341.53s > > > >>>>>>> tid=0x000001e349b353d0 nid=0x1cc4 runnable > > > >>>>>>> > > > >>>>>>> "GC Thread#2" os_prio=2 cpu=218.75ms elapsed=340.37s > > > >>>>>>> tid=0x000001e349b350a0 nid=0x1ddc runnable > > > >>>>>>> > > > >>>>>>> "GC Thread#3" os_prio=2 cpu=187.50ms elapsed=338.82s > > > >>>>>>> tid=0x000001e349b35700 nid=0x4a48 runnable > > > >>>>>>> > > > >>>>>>> "GC Thread#4" os_prio=2 cpu=140.63ms elapsed=338.82s > > > >>>>>>> tid=0x000001e349b340b0 nid=0x32e8 runnable > > > >>>>>>> > > > >>>>>>> "GC Thread#5" os_prio=2 cpu=156.25ms elapsed=338.82s > > > >>>>>>> tid=0x000001e349b35a30 nid=0x38cc runnable > > > >>>>>>> > > > >>>>>>> "GC Thread#6" os_prio=2 cpu=171.88ms elapsed=338.82s > > > >>>>>>> tid=0x000001e349b35d60 nid=0x3ed0 runnable > > > >>>>>>> > > > >>>>>>> "G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=341.80s > > > >>>>>>> tid=0x000001e31c229930 nid=0x21c runnable > > > >>>>>>> > > > >>>>>>> "G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=341.80s > > > >>>>> tid=0x000001e31c22a5a0 > > > >>>>>>> nid=0x3920 runnable > > > >>>>>>> > > > >>>>>>> "G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=341.80s > > > >>>>> tid=0x000001e31c253f10 > > > >>>>>>> nid=0x1f84 runnable > > > >>>>>>> > > > >>>>>>> "G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms > > elapsed=341.80s > > > >>>>>>> tid=0x000001e31c254b90 nid=0x27ac runnable > > > >>>>>>> > > > >>>>>>> "VM Periodic Task Thread" os_prio=2 cpu=15.63ms > > elapsed=341.76s > > > >>>>>>> tid=0x000001e349b39710 nid=0x838 waiting on condition > > > >>>>>>> > > > >>>>>>> JNI global refs: 33, weak refs: 0 > > > >>>>>>> > > > >>>>>>> -- > > > >>>>>>> Aaron Scott-Boddendijk > > > >>>>>>> > > > >>>>>>> On Tue, Jun 16, 2020 at 10:15 AM Robert Field < > > > >>>>> robert.field at oracle.com > > > >> > > > >>>>>>> wrote: > > > >>>>>>> > > > >>>>>>>> Make that jps/jstack > > > >>>>>>>> > > > >>>>>>>> -R > > > >>>>>>>> > > > >>>>>>>> On 2020-06-15 15:12, Robert Field wrote: > > > >>>>>>>>> Thanks for the report. > > > >>>>>>>>> > > > >>>>>>>>> What, if anything, is the Java stack for this > > thread (jps)? > > > >>>>>>>>> > > > >>>>>>>>> -Robert > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> On 2020-06-15 14:41, Aaron Scott-Boddendijk wrote: > > > >>>>>>>>>> System: > > > >>>>>>>>>> * Windows 10 > > > >>>>>>>>>> * Powershell > > > >>>>>>>>>> > > > >>>>>>>>>> When I start JShell, without executing anything, > > a CPU > > > core is > > > >>>>> always > > > >>>>>>>> at > > > >>>>>>>>>> 100% (a single thread though I haven't identified > > what it's > > > >>>>> doing). > > > >>>>>>>>>> > > > >>>>>>>>>> The thread stack is as follows (with only the > > last two items > > > >>>>> sometimes > > > >>>>>>>>>> change - but I don't know the internals of the > JVM to > > > know if > > > >> this > > > >>>>>>>>>> useful > > > >>>>>>>>>> or significant): > > > >>>>>>>>>> > > > >>>>>>>>>> ntoskrnl.exe!KeSynchronizeExecution+0x5b46 > > > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x1c2d > > > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0xab4 > > > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x255 > > > >>>>>>>>>> ntoskrnl.exe!RtlClearBitsEx+0x15a7 > > > >>>>>>>>>> ntoskrnl.exe!KeWaitForSingleObject+0x3828 > > > >>>>>>>>>> ntoskrnl.exe!KeSynchronizeExecution+0x3120 > > > >>>>>>>>>> jvm.dll!c2v_notifyCompilerInliningEvent+0x201797 > > > >>>>>>>>>> > > > >>>>>>>>>> The JDK 14 version of JShell does not have this > > issue but > > > >> several > > > >>>>> of > > > >>>>>>>> the > > > >>>>>>>>>> recent JDK 15 builds have done this. > > > >>>>>>>>>> > > > >>>>>>>>>> -- > > > >>>>>>>>>> Aaron Scott-Boddendijk > > > >>>>>>>> > > > >>>>>>> > > > >>>>> > > > >>>> > > > >> > > > > > > From plugins at lingocoder.com Thu Jul 16 10:39:57 2020 From: plugins at lingocoder.com (Lingo Coder) Date: Thu, 16 Jul 2020 03:39:57 -0700 Subject: Records are called =?UTF-8?Q?=E2=80=9Emethods=E2=80=9C=20in=20JShell?= Message-ID: <20200716033957.b6ff8ab09a6c540215cae158a90d7e03.44307d3938.wbe@email17.godaddy.com> > ...Please, can anybody on the list recommend a thorough > resource on advanced use of JShell?... This [1] is very good. Anybody know of any others? ---- [1] https://docs.oracle.com/javase/9/jshell/JSHEL.pdf -------- Original Message -------- Subject: Re: Records are called ?methods? in JShell From: "Lingo Coder" Date: Thu, July 16, 2020 2:47 am To: "Robert Field" , "Lingo Coder" , "kulla-dev at openjdk.java.net" , "jorn.vernee at oracle.com" Thank you Robert, Jorn, and Jan, A couple last things. Please? 1. How is that `mymode` has persisted so long and is configured for every one of my JDKs since JDK9? Even though they are all in their own folders? I set `mymode` way back in 2017 in a JDK 9 install; that was so long ago that I'd forgotten it. Since then, I've used JDKs 10-15. They're all in their own folders. 2. Please, can anybody on the list recommend a thorough resource on advanced use of JShell? I've learned a lot about JShell from Java 9 Revealed ? For Early Adoption and Migration by Kishor Sharan By ?advanced? I mean things like: How to configure the built-in default snippet editor on Windows, to open centered in the screen; instead of opening at an X * Y position that has most of the editor off screen at the bottom-right of the window. TIA. -------- Original Message -------- Subject: Re:_Records_are_called_?methods?_in_JSh ell From: Robert Field Date: Wed, July 15, 2020 9:04 pm To: Lingo Coder , "kulla-dev at openjdk.java.net" , "jorn.vernee at oracle.com" Thanks for persisting with this! I have filed a bug: https://bugs.openjdk.java.net/browse/JDK-8249566 I am able to reproduce it (see bug). You should be able to see it working correctly by doing: jshell> /set feedback normal jshell> public record ConstExpr(Expr e) implements Expr{} See work-around suggestions in bug. I will be looking into fixes. Thanks, Robert On 2020-07-15 13:47, Lingo Coder wrote: Thank you so much, Robert! Hopefully,/set format mymode typeKind "record" recordWill fix your issue. I had high hopes for that [1] but...jshell> /set format mymode typeKind| /set format mymode typeKind "class" class| /set format mymode typeKind "interface" interface| /set format mymode typeKind "enum" enum| /set format mymode typeKind "annotation interface" annotationjshell> public record ConstExpr(Expr e) implements Expr{}| created method ConstExpr(), however, it cannot be referenced untilclass Expr is declaredjshell> /set format mymode typeKind "record" recordjshell> /set format mymode typeKind| /set format mymode typeKind "class" class| /set format mymode typeKind "interface" interface| /set format mymode typeKind "enum" enum| /set format mymode typeKind "annotation interface" annotation| /set format mymode typeKind "record" recordjshell> public record ConstExpr(Expr e) implements Expr{}| modified method ConstExpr(), however, it cannot be referenced untilclass Expr is declared----[1] https://imgur.com/GaIgkOb-------- Original Message --------Subject: Re:_Records_are_called_?methods?_in_JSh ellFrom: Robert Field Date: Wed, July 15, 2020 11:09 amTo: Lingo Coder , "kulla-dev at openjdk.java.net" , "jorn.vernee at oracle.com" OK! There is the root of your issue. You have your own mode, but it probably hasn't been updated for records. You aren't using normal mode so, instead, show the output of: /set format mymode typeKindHopefully,/set format mymode typeKind "record" recordWill fix your issue.-RobertOn 7/15/20 7:33 AM, Lingo Coder wrote: Thank you Robert, ?...And send us what it prints...? You'll see below that right after I did `/set format normal typeKind`it still said, ?created *method*...?. I also recorded it. [1]But then right after `/set feedback verbose`, it said ?created*record*?.However, after an `/exit` and a relaunch of `jshell --enable-preview`,itreverted back to ?created *method*...?/?dropped *method*... ?.I _vaguely_ recall creating `mymode` and doing `/set feedback -retainmymode`way back in 2017 when JShell first came out. I think. I'm not 100% suretho.So I'm guessing I need to do `/set feedback -retain verbose` topermanentlyget ?created *record*...? Correct?TIA.----...jshell> /set feedback| /set feedback -retain mymode|| Retained feedback modes:| mymode| Available feedback modes:| concise| mymode| normal| silent| verbosejshell> /set format normal typeKind| /set format normal typeKind "class" class| /set format normal typeKind "interface" interface| /set format normal typeKind "enum" enum| /set format normal typeKind "annotation interface" annotation| /set format normal typeKind "record" recordjshell> public record ConstExpr(Expr e) implements Expr{}| created method ConstExpr(), however, it cannot be referenced untilclass Expr is declaredjshell> /type| record ConstExpr| which cannot be referenced until class Expr is declaredjshell> /types| record ConstExpr| which cannot be referenced until class Expr is declaredjshell> /method| void print(boolean)| void print(char)| void print(int)| void print(long)| void print(float)| void print(double)| void print(char s[])| void print(String)| void print(Object)| void println()| void println(boolean)| void println(char)| void println(int)| void println(long)| void println(float)| void println(double)| void println(char s[])| void println(String)| void println(Object)| void printf(java.util.Locale,String,Object...)| void printf(String,Object...)jshell> /drop ConstExpr| dropped method ConstExpr()jshell> /set feedback verbose| Feedback mode: verbosejshell> public record ConstExpr(Expr e) implements Expr{}| created record ConstExpr, however, it cannot be referenced untilclass Expr is declaredjshell> /type| record ConstExpr| which cannot be referenced until class Expr is declaredjshell> class Expr{}| created class Exprjshell> /types| record ConstExpr| which cannot be referenced until this error is corrected:| interface expected here| public record ConstExpr(Expr e) implements Expr{}| ^--^| class Exprjshell> /drop Expr| dropped class Exprjshell> interface Expr{}| created interface Expr| update replaced record ConstExprjshell> /types| record ConstExpr| interface Exprjshell> /drop ConstExpr| dropped record ConstExpr...----[1] https://imgur.com/ePyilYo-------- Original Message --------Subject: Re:_Records_are_called_?methods?_in_JSh ellFrom: Robert Field Date: Tue, July 14, 2020 8:07 pmTo: Lingo Coder ,"kulla-dev at openjdk.java.net" ,"jorn.vernee at oracle.com" I have a theory, maybe the following can illuminate...Couple more things to try:/set feedback/set format normal typeKindAnd send us what it prints.Also, after you have entered:public record ConstExpr(Expr e) implements Expr{}Type:/typeand/methodSeparately, what do they print?Oh, and if you want to try one more thing:/set feedback verbosepublic record ConstExpr(Expr e) implements Expr{}Sorry, I don't have Windows, but I believe Jan has access.-RobertOn 2020-07-14 18:35, Lingo Coder wrote: Thanks Robert, ?...Can you do:jshell --full-version...? I did that. It says jshell 15-ea+31-1502 [1]What version of Windows are you other guys trying this in? I'm onWindows 7. ?...I'm guessing you may be using an older JDK...? As I show in [1] and in earlier screen recordings, I completelyclear my $PATH to confirm that there is no other jshell.exe onthe $PATH.I have not installed any JDKs with an installer or anythinglike that. For that reason, I rule out anything registry-related.I do have an early access release of 14-Valhallabuild 14-valhalla+4-55 on my workstation. But, that wasinstalled by simply unzipping the archive into ajdk-14.L.world.Build.14-valhalla+4-55 folder. More importantly,that build doesn't even have the records nor the sealed typesfeatures.I also have GA releases of OpenJDK 12 & 13 in their own folders.But again, not only are they isolated well out of the way ofthe $PATH I run jshell 15 in, they don't even have records andsealed types functionality.If _any_ other JDK were somehow in the $PATH, it would besurprising if records and sealed types even worked _at all_;let alone the misnaming as ?methods? issue Right? Pleasecorrect me if I'm wrong?[1] https://imgur.com/cMsAl5f-------- Original Message --------Subject: Re:_Records_are_called_?methods?_in_JSh ellFrom: Robert Field Date: Tue, July 14, 2020 3:57 pmTo: kulla-dev at openjdk.java.net, jorn.vernee at oracle.com,plugins at lingocoder.comI'm guessing you may be using an older JDK. I get:jshell> public record ConstExpr(Expr e) implements Expr{}| created record ConstExprjshell> /drop ConstExpr| dropped record ConstExprCan you do:jshell --full-versionThanks,Robert From robert.field at oracle.com Thu Jul 16 14:47:41 2020 From: robert.field at oracle.com (Robert Field) Date: Thu, 16 Jul 2020 07:47:41 -0700 Subject: =?UTF-8?B?UmU6IFJlY29yZHMgYXJlIGNhbGxlZCDigJ5tZXRob2Rz4oCcIGluIEpTaGVsbA==?= In-Reply-To: <20200716024729.b6ff8ab09a6c540215cae158a90d7e03.f548552953.wbe@email17.godaddy.com> References: <20200716024729.b6ff8ab09a6c540215cae158a90d7e03.f548552953.wbe@email17.godaddy.com> Message-ID: <173581866c8.27ed.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Retained JShell tool settings are stored globally. They persist across version/installation ... To revert to normal just do this once: /set feedback normal -retain -Robert On July 16, 2020 2:48:06 AM Lingo Coder wrote: > Thank you Robert, Jorn, and Jan, > > A couple last things. Please? > > 1. How is that `mymode` has persisted so long and > is configured for every one of my JDKs since JDK9? > Even though they are all in their own folders? > > I set `mymode` way back in 2017 in a JDK 9 install; > that was so long ago that I'd forgotten it. Since > then, I've used JDKs 10-15. They're all in their > own folders. > > 2. Please, can anybody on the list recommend a thorough > resource on advanced use of JShell? I've learned > a lot about JShell from Java 9 Revealed ? For Early > Adoption and Migration by Kishor Sharan > > By ?advanced? I mean things like: How to configure the > built-in default snippet editor on Windows, to open > centered in the screen; instead of opening at an X * Y > position that has most of the editor off screen at the > bottom-right of the window. > > TIA. > > -------- Original Message -------- > Subject: Re:_Records_are_called_?methods?_in_JSh ell > From: Robert Field > Date: Wed, July 15, 2020 9:04 pm > To: Lingo Coder , > "kulla-dev at openjdk.java.net" , > "jorn.vernee at oracle.com" > > Thanks for persisting with this! > I have filed a bug: > https://bugs.openjdk.java.net/browse/JDK-8249566 > I am able to reproduce it (see bug). > You should be able to see it working correctly by doing: > jshell> /set feedback normal > > jshell> public record ConstExpr(Expr e) implements Expr{} > See work-around suggestions in bug. > I will be looking into fixes. > Thanks, > Robert > > > On 2020-07-15 13:47, Lingo Coder wrote: > > Thank you so much, Robert! Hopefully,/set format mymode typeKind > "record" recordWill fix your issue. I had high hopes for that [1] > but...jshell> /set format mymode typeKind| /set format mymode typeKind > "class" class| /set format mymode typeKind "interface" interface| /set > format mymode typeKind "enum" enum| /set format mymode typeKind > "annotation interface" annotationjshell> public record ConstExpr(Expr e) > implements Expr{}| created method ConstExpr(), however, it cannot be > referenced untilclass Expr is declaredjshell> /set format mymode > typeKind "record" recordjshell> /set format mymode typeKind| /set format > mymode typeKind "class" class| /set format mymode typeKind "interface" > interface| /set format mymode typeKind "enum" enum| /set format mymode > typeKind "annotation interface" annotation| /set format mymode typeKind > "record" recordjshell> public record ConstExpr(Expr e) implements > Expr{}| modified method ConstExpr(), however, it cannot be referenced > untilclass Expr is declared----[1] https://imgur.com/GaIgkOb-------- > Original Message --------Subject: > Re:_Records_are_called_?methods?_in_JSh ellFrom: Robert Field > Date: Wed, July 15, 2020 11:09 amTo: Lingo > Coder , "kulla-dev at openjdk.java.net" > , "jorn.vernee at oracle.com" > OK! There is the root of your issue. You have > your own mode, but it probably hasn't been updated for records. You > aren't using normal mode so, instead, show the output of: /set format > mymode typeKindHopefully,/set format mymode typeKind "record" recordWill > fix your issue.-RobertOn 7/15/20 7:33 AM, Lingo Coder wrote: Thank you > Robert, ?...And send us what it prints...? You'll see below that > right after I did `/set format normal typeKind`it still said, ?created > *method*...?. I also recorded it. [1]But then right after `/set > feedback verbose`, it said ?created*record*?.However, after an > `/exit` and a relaunch of `jshell --enable-preview`,itreverted back to > ?created *method*...?/?dropped *method*... ?.I _vaguely_ recall > creating `mymode` and doing `/set feedback -retainmymode`way back in > 2017 when JShell first came out. I think. I'm not 100% suretho.So I'm > guessing I need to do `/set feedback -retain verbose` topermanentlyget > ?created *record*...? Correct?TIA.----...jshell> /set feedback| /set > feedback -retain mymode|| Retained feedback modes:| mymode| Available > feedback modes:| concise| mymode| normal| silent| verbosejshell> /set > format normal typeKind| /set format normal typeKind "class" class| /set > format normal typeKind "interface" interface| /set format normal > typeKind "enum" enum| /set format normal typeKind "annotation interface" > annotation| /set format normal typeKind "record" recordjshell> public > record ConstExpr(Expr e) implements Expr{}| created method ConstExpr(), > however, it cannot be referenced untilclass Expr is declaredjshell> > /type| record ConstExpr| which cannot be referenced until class Expr is > declaredjshell> /types| record ConstExpr| which cannot be referenced > until class Expr is declaredjshell> /method| void print(boolean)| void > print(char)| void print(int)| void print(long)| void print(float)| void > print(double)| void print(char s[])| void print(String)| void > print(Object)| void println()| void println(boolean)| void > println(char)| void println(int)| void println(long)| void > println(float)| void println(double)| void println(char s[])| void > println(String)| void println(Object)| void > printf(java.util.Locale,String,Object...)| void > printf(String,Object...)jshell> /drop ConstExpr| dropped method > ConstExpr()jshell> /set feedback verbose| Feedback mode: verbosejshell> > public record ConstExpr(Expr e) implements Expr{}| created record > ConstExpr, however, it cannot be referenced untilclass Expr is > declaredjshell> /type| record ConstExpr| which cannot be referenced > until class Expr is declaredjshell> class Expr{}| created class > Exprjshell> /types| record ConstExpr| which cannot be referenced until > this error is corrected:| interface expected here| public record > ConstExpr(Expr e) implements Expr{}| ^--^| class Exprjshell> /drop Expr| > dropped class Exprjshell> interface Expr{}| created interface Expr| > update replaced record ConstExprjshell> /types| record ConstExpr| > interface Exprjshell> /drop ConstExpr| dropped record > ConstExpr...----[1] https://imgur.com/ePyilYo-------- Original Message > --------Subject: Re:_Records_are_called_?methods?_in_JSh ellFrom: > Robert Field Date: Tue, July 14, 2020 8:07 > pmTo: Lingo Coder ,"kulla-dev at openjdk.java.net" > ,"jorn.vernee at oracle.com" > I have a theory, maybe the following can > illuminate...Couple more things to try:/set feedback/set format normal > typeKindAnd send us what it prints.Also, after you have entered:public > record ConstExpr(Expr e) implements > Expr{}Type:/typeand/methodSeparately, what do they print?Oh, and if you > want to try one more thing:/set feedback verbosepublic record > ConstExpr(Expr e) implements Expr{}Sorry, I don't have Windows, but I > believe Jan has access.-RobertOn 2020-07-14 18:35, Lingo Coder wrote: > Thanks Robert, ?...Can you do:jshell --full-version...? I did > that. It says jshell 15-ea+31-1502 [1]What version of Windows are you > other guys trying this in? I'm onWindows 7. ?...I'm guessing you may > be using an older JDK...? As I show in [1] and in earlier screen > recordings, I completelyclear my $PATH to confirm that there is no other > jshell.exe onthe $PATH.I have not installed any JDKs with an installer > or anythinglike that. For that reason, I rule out anything > registry-related.I do have an early access release of 14-Valhallabuild > 14-valhalla+4-55 on my workstation. But, that wasinstalled by simply > unzipping the archive into ajdk-14.L.world.Build.14-valhalla+4-55 > folder. More importantly,that build doesn't even have the records nor > the sealed typesfeatures.I also have GA releases of OpenJDK 12 & 13 in > their own folders.But again, not only are they isolated well out of the > way ofthe $PATH I run jshell 15 in, they don't even have records > andsealed types functionality.If _any_ other JDK were somehow in the > $PATH, it would besurprising if records and sealed types even worked _at > all_;let alone the misnaming as ?methods? issue Right? Pleasecorrect > me if I'm wrong?[1] https://imgur.com/cMsAl5f-------- Original Message > --------Subject: Re:_Records_are_called_?methods?_in_JSh ellFrom: > Robert Field Date: Tue, July 14, 2020 3:57 > pmTo: kulla-dev at openjdk.java.net, > jorn.vernee at oracle.com,plugins at lingocoder.comI'm guessing you may be > using an older JDK. I get:jshell> public record ConstExpr(Expr e) > implements Expr{}| created record ConstExprjshell> /drop ConstExpr| > dropped record ConstExprCan you do:jshell --full-versionThanks,Robert From robert.field at oracle.com Tue Jul 21 18:26:24 2020 From: robert.field at oracle.com (Robert Field) Date: Tue, 21 Jul 2020 11:26:24 -0700 Subject: CFV: Dissolve the Kulla [JShell] Project Message-ID: According to section 6 of the bylaws [1], the Committers of a Project may decide, by Lazy Consensus, to request that a Project should be dissolved. When a Project is dissolved its materials are archived. A dissolved Project may be re-created by being re-proposed. The work that was done in this Project has been integrated into JDK 9. The kulla-dev mailing list has inappropriately transitioned to being used as a general maintenance mailing list. A much less obscurely named mailing list should be used for discussion of JShell maintenance and other topics. I therefore propose that the Kulla Project [2] should be dissolved. Votes are due by 1pm PDT, 4th August 2020 Only current Kulla Project Committers [3] are eligible to vote. Votes must be cast in the open by replying to this mailing list. -- Robert [1]http://openjdk.java.net/bylaws#_6 [2]https://openjdk.java.net/projects/kulla/ [3] https://openjdk.java.net/census#kulla From robert.field at oracle.com Tue Jul 21 23:37:13 2020 From: robert.field at oracle.com (Robert Field) Date: Tue, 21 Jul 2020 16:37:13 -0700 Subject: CFV: Dissolve the Kulla [JShell] Project In-Reply-To: References: Message-ID: Sorry, never mind. Apparently leaving a project around (after it has been integrated into the JDK) and continuing to use its mailing list is completely appropriate. I veto the dissolution. -Robert On 2020-07-21 11:26, Robert Field wrote: > According to section 6 of the bylaws [1], the Committers of a Project may > decide, by Lazy Consensus, to request that a Project should be > dissolved. When a Project is dissolved its materials are archived. A > dissolved Project may be re-created by being re-proposed. > > The work that was done in this Project has been integrated into JDK 9. > The kulla-dev mailing list has inappropriately transitioned to being used > as a general maintenance mailing list.? A much less obscurely named > mailing > list should be used for discussion of JShell maintenance and other > topics. > > I therefore propose that the Kulla Project [2] should be dissolved. > > Votes are due by 1pm PDT, 4th August 2020 > > Only current Kulla Project Committers [3] are eligible to vote. > > Votes must be cast in the open by replying to this mailing list. > > -- Robert > > > [1]http://openjdk.java.net/bylaws#_6 > [2]https://openjdk.java.net/projects/kulla/ > > [3] https://openjdk.java.net/census#kulla > > > > > From jan.lahoda at oracle.com Thu Jul 23 12:48:44 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 23 Jul 2020 14:48:44 +0200 Subject: RFR 8248157: JShell: throws AssertionError when creating a variable with some unicode chars In-Reply-To: <91f89609-5615-d447-5332-119f601369d0@oracle.com> References: <91f89609-5615-d447-5332-119f601369d0@oracle.com> Message-ID: <54b067c2-e7da-008c-2e19-2d8c0b494406@oracle.com> Looks OK to me. Jan On 10. 07. 20 21:36, Robert Field wrote: > Unicode in JShell is a broader issue, as covered in the issues I've just > added as falling out from this: > > ?? 8249197: JShell: variable declaration with unicode type name gets > garbled result > https://bugs.openjdk.java.net/browse/JDK-8249197 > > ?? 8249199: JShell: Consistent representation of unicode > https://bugs.openjdk.java.net/browse/JDK-8249199 > > This fix is for the narrow problem specified in the bug report. > > Webrev: > > http://cr.openjdk.java.net/~rfield/8248157v0.webrev/ > > Thanks, > Robert > > From robert.field at oracle.com Fri Jul 24 01:43:01 2020 From: robert.field at oracle.com (Robert Field) Date: Thu, 23 Jul 2020 18:43:01 -0700 Subject: RFR: 8249566: jshell tool: retained modes from JDK-13 or prior cause confusing messages to be generated for records Message-ID: <3cadf2f7-7b76-e0ed-888f-849651a841ed@oracle.com> Please review.... Fixes the corruption of JDK-13 or earlier user defined modes and switches to a textual format resistant to future corruption.? The issue in the bug title is just one resulting error (the mode is deeply corrupted). Fixing this necessitated a rewrite of all the code related to processing selectors, this was put in a new source file Selector.java.? It is a lot of code, but I've documented thoroughly. I've hand tested by using JDK-13 and JDK-14 retained modes, can't really test the future language thing ;-) and none of that is reasonably testable with the test harness. One of the side-effects of the rewrite is that the user's layout of a selector, is preserved, not rewritten in fixed order, so I needed to update one test case accordingly. Issue: https://bugs.openjdk.java.net/browse/JDK-8249566 Webrev: http://cr.openjdk.java.net/~rfield/8249566v0.webrev/ Thanks, Robert From fw at deneb.enyo.de Sun Jul 26 08:30:11 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 26 Jul 2020 10:30:11 +0200 Subject: CFV: Dissolve the Kulla [JShell] Project In-Reply-To: (Robert Field's message of "Tue, 21 Jul 2020 16:37:13 -0700") References: Message-ID: <87wo2q4r1o.fsf@mid.deneb.enyo.de> * Robert Field: > Sorry, never mind. > > Apparently leaving a project around (after it has been integrated into > the JDK) and continuing to use its mailing list is completely appropriate. > > I veto the dissolution. Maybe you can change this kulla-dev Technical discussion about Project Kulla on kulla-dev Technical discussion about JShell tool development ? From jan.lahoda at oracle.com Thu Jul 30 14:37:18 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 30 Jul 2020 16:37:18 +0200 Subject: RFR: 8249566: jshell tool: retained modes from JDK-13 or prior cause confusing messages to be generated for records In-Reply-To: <3cadf2f7-7b76-e0ed-888f-849651a841ed@oracle.com> References: <3cadf2f7-7b76-e0ed-888f-849651a841ed@oracle.com> Message-ID: Looks OK. The new file: src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Selector.java should have a license header. No need for re-review. Thanks, Jan On 24. 07. 20 3:43, Robert Field wrote: > Please review.... > > Fixes the corruption of JDK-13 or earlier user defined modes and > switches to a textual format resistant to future corruption.? The issue > in the bug title is just one resulting error (the mode is deeply > corrupted). > > Fixing this necessitated a rewrite of all the code related to processing > selectors, this was put in a new source file Selector.java.? It is a lot > of code, but I've documented thoroughly. > > I've hand tested by using JDK-13 and JDK-14 retained modes, can't really > test the future language thing ;-) > and none of that is reasonably testable with the test harness. One of > the side-effects of the rewrite is that the user's layout of a selector, > is preserved, not rewritten in fixed order, so I needed to update one > test case accordingly. > > Issue: > > https://bugs.openjdk.java.net/browse/JDK-8249566 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8249566v0.webrev/ > > Thanks, > Robert > >