JDK 13 EA: 100% CPU use with no Java threads runnable
david.holmes at oracle.com
Sun Sep 15 02:12:04 UTC 2019
On 15/09/2019 7:49 am, Stefan Reich wrote:
> thanks for your answer. Unfortunately, I still don't know what triggers the
> "bad" state, so no test case... It happens randomly, but as I said, once it
> does, it doesn't go away anymore. (Still happening right now.)
> Would the result from Thread.getAllStackTraces() help? I attached that to
> this email.
Possible - though ideally we would want to see all threads not just Java
threads. But looking at the list you gave I see one suspicious thread:
Thread[JNativeHook Hook Thread,10,main]
You might want to check what the code for that thread does.
Also try to identify the thread involved via top:
> Many greetings,
> On Sat, 14 Sep 2019 at 23:43, Ioi Lam <ioi.lam at oracle.com> wrote:
>> Hi Stefan,
>> Is it possible for you to create a test case that reproduce this problem?
>> If not, try running the program inside a Linux terminal, and when the
>> CPU goes at 100%, type "Ctrl-\" (Control + Backslash). It lists the
>> states of all the threads that the JVM knows about. It might give you
>> some idea what's happening.
>> An alternative is to run your program inside gdb,
>> $ gdb jdk13/bin/java
>> (gdb) handle SIGSEGV noprint
>> (gdb) handle SIGSEGV nostop
>> (gdb) set print thread-events off
>> (gdb) set height 0
>> (gdb) run -cp myapp.jar App
>> (When the program enters the 100% CPU state, type Ctrl-C)
>> Thread 1 "java" received signal SIGINT, Interrupt.
>> 0x00007ffff779798d in pthread_join (threadid=140737353910016,
>> thread_return=0x7fffffff8508) at pthread_join.c:90
>> 90 pthread_join.c: No such file or directory.
>> (gdb) thread apply all where
>> This will list all stacks of all the threads, including ones that the
>> JVM may not be aware of. This should tell you who is spinning the CPU.
>> - Ioi
>> On 9/14/19 1:57 PM, Stefan Reich wrote:
>>> I was advised by Oracle's Fairoz Matte to contact this list.
>>> I am seeing a Java process use 100% of one CPU core continuously, but no
>>> Java threads are runnable (as evidenced by internal thread sampling as
>>> as VisualVM).
>>> Whenever it occurs, the problem does not seem to go away until the Java
>>> I think I am using a single native library (OSHI), the rest is pure Java.
>>> Older versions of the JDK have exhibited the same problem, but most
>>> interestingly, the bug is happening right now on a Linux machine
>>> (Peppermint 7 I think) with OpenJDK 13 EA Build 31.
>>> I can perform any test on this machine that you instruct me to.
>>> Please advise,
More information about the hotspot-dev