From jan.lahoda at oracle.com Wed Jun 3 10:16:48 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 3 Jun 2020 12:16:48 +0200 Subject: RFR: JDK-8246353: Sealed types not supported by jshell Message-ID: <725a51bd-1e23-a604-1ceb-b6f05a295a51@oracle.com> Hi, JShell does not support sealed types yet, this patch attempts to solve it. This patch: -adds "permits" clauses to header dependencies of the class that defines it (so that JShell correctly detects the permitted classes must be added before the class is defined) -JShell will not clear the final modifier, on any element (class, method, variable) before compiling the snippet -javac will not report the "no sealed superclass" error for cases like: non-sealed class I extends Undefined {} (this makes support for non-sealed in JShell much easier, and is the right thing to do, I believe.) Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8246353/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8246353 How does this look? Thanks, Jan From vicente.romero at oracle.com Wed Jun 3 16:33:24 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 3 Jun 2020 12:33:24 -0400 Subject: RFR: JDK-8246353: Sealed types not supported by jshell In-Reply-To: <725a51bd-1e23-a604-1ceb-b6f05a295a51@oracle.com> References: <725a51bd-1e23-a604-1ceb-b6f05a295a51@oracle.com> Message-ID: looks good to me, Thanks, Vicente On 6/3/20 6:16 AM, Jan Lahoda wrote: > Hi, > > JShell does not support sealed types yet, this patch attempts to solve > it. This patch: > -adds "permits" clauses to header dependencies of the class that > defines it (so that JShell correctly detects the permitted classes > must be added before the class is defined) > -JShell will not clear the final modifier, on any element (class, > method, variable) before compiling the snippet > -javac will not report the "no sealed superclass" error for cases like: > non-sealed class I extends Undefined {} > (this makes support for non-sealed in JShell much easier, and is the > right thing to do, I believe.) > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8246353/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8246353 > > How does this look? > > Thanks, > ?? Jan From robert.field at oracle.com Thu Jun 4 23:14:22 2020 From: robert.field at oracle.com (Robert Field) Date: Thu, 4 Jun 2020 16:14:22 -0700 Subject: RFR: JDK-8246353: Sealed types not supported by jshell In-Reply-To: <725a51bd-1e23-a604-1ceb-b6f05a295a51@oracle.com> References: <725a51bd-1e23-a604-1ceb-b6f05a295a51@oracle.com> Message-ID: <596fd8e7-f346-23fe-dfc2-4a62c9bec20f@oracle.com> In MaskCommentsAndModifiers, it is the right thing to remove "final" from IGNORED_MODIFIERS, however it is important that "final" is then added to OTHER_MODIFIERS. Otherwise, "final" will prevent subsequent ignored modifiers from being ignored. "final" could, I believe, be added to the before array in to ModifiersTest to catch this. Otherwise looks good.? If those are addressed, I give my thumbs up, without a re-review. Thanks, Robert This review covers the JShell portion of the RFR. On 2020-06-03 03:16, Jan Lahoda wrote: > Hi, > > JShell does not support sealed types yet, this patch attempts to solve > it. This patch: > -adds "permits" clauses to header dependencies of the class that > defines it (so that JShell correctly detects the permitted classes > must be added before the class is defined) > -JShell will not clear the final modifier, on any element (class, > method, variable) before compiling the snippet > -javac will not report the "no sealed superclass" error for cases like: > non-sealed class I extends Undefined {} > (this makes support for non-sealed in JShell much easier, and is the > right thing to do, I believe.) > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8246353/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8246353 > > How does this look? > > Thanks, > ?? Jan From talden at gmail.com Thu Jun 11 23:13:36 2020 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Fri, 12 Jun 2020 11:13:36 +1200 Subject: Jshell IllegalArgumentException on trying to start a text-block (JDK 15 Build 26) Message-ID: System: * Windows 10 * Powershell In JDK 14 this works > jshell --enable-preview ... jshell> var s = """ ...> In JDK 15 build 26 this happens (it has been happening for several builds) > jshell ... jshell> var s = """ Exception in thread "main" java.lang.IllegalArgumentException at jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.(JCDiagnostic.java:600) at jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.create(JCDiagnostic.java:283) at jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.error(JCDiagnostic.java:111) at jdk.compiler/com.sun.tools.javac.util.AbstractLog.error(AbstractLog.java:145) at jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.lexError(JavaTokenizer.java:163) at jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.scanString(JavaTokenizer.java:449) at jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.readToken(JavaTokenizer.java:936) at jdk.compiler/com.sun.tools.javac.parser.Scanner.nextToken(Scanner.java:115) at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.countPendingOpenBraces(ConsoleIOContext.java:988) at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.lambda$new$3(ConsoleIOContext.java:182) at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.acceptLine(LineReaderImpl.java:2983) at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl$1.apply(LineReaderImpl.java:3797) at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:665) at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454) at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:229) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1254) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1190) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:254) at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) I couldn't find a bug mentioning it. -- Aaron Scott-Boddendijk From robert.field at oracle.com Fri Jun 12 23:59:50 2020 From: robert.field at oracle.com (Robert Field) Date: Fri, 12 Jun 2020 16:59:50 -0700 Subject: RFR: JShell fail over test failure not given fail over support and message confusing Message-ID: <428d5e54-e605-357b-35f4-29964cef5ac6@oracle.com> All runs of JShell including all tests have fail over protection against launch failure -- except fail over tests, which only get one chance. The exception thrown is only for the first failure, so for a fail over test with an intended first failure that is particularly confusing. Harden the tests and provide comprehensive diagnostics. Bugs: ? 8247438: JShell: When FailOverExecutionControlProvider fails the proximal cause is not shown https://bugs.openjdk.java.net/browse/JDK-8247438 ? 8237743: test/langtools/jdk/jshell/FailOverExecutionControlTest.java fails No ExecutionControlProvider with name 'nonExistent' and parameter keys: [] https://bugs.openjdk.java.net/browse/JDK-8237743 ? 8199646: JShell tests: jdk/jshell/FailOverDirectExecutionControlTest.java failed with java.lang.UnsupportedOperationException https://bugs.openjdk.java.net/browse/JDK-8199646 Webrev: http://cr.openjdk.java.net/~rfield/8247438v0/ Thanks, Robert From talden at gmail.com Mon Jun 15 21:41:42 2020 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Tue, 16 Jun 2020 09:41:42 +1200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) Message-ID: 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 Mon Jun 15 22:12:32 2020 From: robert.field at oracle.com (Robert Field) Date: Mon, 15 Jun 2020 15:12:32 -0700 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: References: Message-ID: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> 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 Mon Jun 15 22:13:42 2020 From: robert.field at oracle.com (Robert Field) Date: Mon, 15 Jun 2020 15:13:42 -0700 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> Message-ID: <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> 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 Jun 15 23:16:06 2020 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Tue, 16 Jun 2020 11:16:06 +1200 Subject: JShell uses 100% of one core all the time (JDK 15 Build 27) In-Reply-To: <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> References: <6f077147-6bcd-7db1-dc2a-30fcbafdfaa7@oracle.com> <703077d3-2538-ae3d-f2c9-e04500c68ba6@oracle.com> Message-ID: 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 jan.lahoda at oracle.com Fri Jun 19 11:52:35 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 19 Jun 2020 13:52:35 +0200 Subject: Jshell IllegalArgumentException on trying to start a text-block (JDK 15 Build 26) In-Reply-To: References: Message-ID: Hi Aaron, Thanks for the report, I've filled: https://bugs.openjdk.java.net/browse/JDK-8247932 Jan On 12. 06. 20 1:13, Aaron Scott-Boddendijk wrote: > System: > * Windows 10 > * Powershell > > In JDK 14 this works > >> jshell --enable-preview > ... > jshell> var s = """ > ...> > > > In JDK 15 build 26 this happens (it has been happening for several builds) > >> jshell > ... > jshell> var s = """ > Exception in thread "main" java.lang.IllegalArgumentException > at > jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.(JCDiagnostic.java:600) > at > jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.create(JCDiagnostic.java:283) > at > jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.error(JCDiagnostic.java:111) > at > jdk.compiler/com.sun.tools.javac.util.AbstractLog.error(AbstractLog.java:145) > at > jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.lexError(JavaTokenizer.java:163) > at > jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.scanString(JavaTokenizer.java:449) > at > jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.readToken(JavaTokenizer.java:936) > at > jdk.compiler/com.sun.tools.javac.parser.Scanner.nextToken(Scanner.java:115) > at > jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.countPendingOpenBraces(ConsoleIOContext.java:988) > at > jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.lambda$new$3(ConsoleIOContext.java:182) > at > jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.acceptLine(LineReaderImpl.java:2983) > at > jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl$1.apply(LineReaderImpl.java:3797) > at > jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:665) > at > jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454) > at > jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:229) > at > jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1254) > at > jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1190) > at > jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) > at > jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:254) > at > jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) > > I couldn't find a bug mentioning it. > > -- > Aaron Scott-Boddendijk > From jan.lahoda at oracle.com Fri Jun 19 17:28:02 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 19 Jun 2020 19:28:02 +0200 Subject: RFR: JDK-8247932: JShell crashes when typing text block Message-ID: <1d4d091c-6848-f5cb-e891-46e7f20f4eb5@oracle.com> Hi, In JDK 15, we've improved JShell to automatically indent multi-line snippets while typing them. To detect the proper indent, it is necessary to detect '{' and '}'. The javac's lexer has been used for this detection. But there is a bug in that - the javac's Log is not properly configured for that: a) the Log's source is not configured (which leads to the exception from the bug) b) the Log will print any errors detected while detecting the indent to the System.err These are obviously undesirable, so the proposed patch sets a Log's source, and and configures Log to ignore all diagnostics reported. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8247932/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8247932 Does this look sensible? Thanks, Jan From robert.field at oracle.com Fri Jun 19 18:00:13 2020 From: robert.field at oracle.com (Robert Field) Date: Fri, 19 Jun 2020 11:00:13 -0700 Subject: RFR: JDK-8247932: JShell crashes when typing text block In-Reply-To: <1d4d091c-6848-f5cb-e891-46e7f20f4eb5@oracle.com> References: <1d4d091c-6848-f5cb-e891-46e7f20f4eb5@oracle.com> Message-ID: Looks good. Nit: copyright on ConsoleIOContext needs update (no need for re-review). -Robert On 2020-06-19 10:28, Jan Lahoda wrote: > Hi, > > In JDK 15, we've improved JShell to automatically indent multi-line > snippets while typing them. To detect the proper indent, it is > necessary to detect '{' and '}'. The javac's lexer has been used for > this detection. But there is a bug in that - the javac's Log is not > properly configured for that: > a) the Log's source is not configured (which leads to the exception > from the bug) > b) the Log will print any errors detected while detecting the indent > to the System.err > > These are obviously undesirable, so the proposed patch sets a Log's > source, and and configures Log to ignore all diagnostics reported. > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8247932/webrev.00/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8247932 > > Does this look sensible? > > Thanks, > ??? Jan From talden at gmail.com Fri Jun 26 02:00:04 2020 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Fri, 26 Jun 2020 14:00:04 +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: 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 jan.lahoda at oracle.com Fri Jun 26 10:02:21 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 26 Jun 2020 12:02:21 +0200 Subject: RFR: JShell fail over test failure not given fail over support and message confusing In-Reply-To: <428d5e54-e605-357b-35f4-29964cef5ac6@oracle.com> References: <428d5e54-e605-357b-35f4-29964cef5ac6@oracle.com> Message-ID: Looks good to me. Jan On 13. 06. 20 1:59, Robert Field wrote: > All runs of JShell including all tests have fail over protection against > launch failure -- except fail over tests, which only get one chance. > > The exception thrown is only for the first failure, so for a fail over > test with an intended first failure that is particularly confusing. > > Harden the tests and provide comprehensive diagnostics. > > Bugs: > > ? 8247438: JShell: When FailOverExecutionControlProvider fails the > proximal cause is not shown > https://bugs.openjdk.java.net/browse/JDK-8247438 > > ? 8237743: test/langtools/jdk/jshell/FailOverExecutionControlTest.java > fails No ExecutionControlProvider with name 'nonExistent' and parameter > keys: [] > https://bugs.openjdk.java.net/browse/JDK-8237743 > > ? 8199646: JShell tests: > jdk/jshell/FailOverDirectExecutionControlTest.java failed with > java.lang.UnsupportedOperationException > https://bugs.openjdk.java.net/browse/JDK-8199646 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8247438v0/ > > > Thanks, > Robert > >