Why is eclipse eating almost all of CPU for no apparent reason

Question

I tried to follow this question High CPU usage in Eclipse when idle and find out why Eclipse is being such a CPU hog

Here are the threads consuming a double digit processor share, can somebody make sense of them? One thread eating ~80% seems to be related to workbench, but the rest are a mystery.

I do have a decent proc and SSD drive, and most of the time eclipse is running smoothly.

BTW. There was a short lag between executing ps and kill, which might explain it, but I don't understand how a waiting thread could use over 50% of cpu.

"Worker-6" prio=10 tid=0x00007fe9e0036000 nid=0x1caf in Object.wait() [0x00007fe9c2269000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor) 16.8%
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00007fea3fa6d1a0> (a org.eclipse.core.internal.jobs.WorkerPool)
        at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:188)
        - locked <0x00007fea3fa6d1a0> (a org.eclipse.core.internal.jobs.WorkerPool)
        at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:220)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:50)


"org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=10 tid=0x00007fea94e3d800 nid=0x1ca1 in Object.wait() [0x00007fe9d65e4000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor) 57.4%
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00007fea39123a28> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue)
        at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:179)
        - locked <0x00007fea39123a28> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue)

"Java indexing" daemon prio=10 tid=0x00007fea9510f000 nid=0x1c9d in Object.wait() [0x00007fe9fc7bf000]
   java.lang.Thread.State: WAITING (on object monitor) 31.9%
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00007fea3adbe2f8> (a org.eclipse.jdt.internal.core.search.indexing.IndexManager)
        at java.lang.Object.wait(Object.java:485)
        at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:382)
        - locked <0x00007fea3adbe2f8> (a org.eclipse.jdt.internal.core.search.indexing.IndexManager)
        at java.lang.Thread.run(Thread.java:662)

"C2 CompilerThread1" daemon prio=10 tid=0x00007fea942fd800 nid=0x1c85 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE 85.6%

"C2 CompilerThread0" daemon prio=10 tid=0x00007fea942fb000 nid=0x1c84 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE 85.6%

"main" prio=10 tid=0x00007fea94009800 nid=0x1c73 runnable [0x00007fea9b93a000]
   java.lang.Thread.State: RUNNABLE 72.7%
        at org.eclipse.swt.internal.gtk.OS.Call(Native Method)
        at org.eclipse.swt.widgets.Display.sleep(Display.java:4233)
        at org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle(WorkbenchAdvisor.java:364)
        at org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor.eventLoopIdle(IDEWorkbenchAdvisor.java:917)
        at org.eclipse.ui.internal.Workbench$3.eventLoopIdle(Workbench.java:487)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1117)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
        at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
        at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
        at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
        at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
        at org.eclipse.equinox.launcher.Main.main(Main.java:1426)

Eclipse has some timing issues which occasionally crop up. The developers are still trying to fix them. Meanwhile, the workaround is to shut down Eclipse and restart it. — keshlam, Mar 20 '14 at 14:42
@keshlam how about an older version of eclipse, such as indigo? — Leo, Apr 07 '14 at 10:54
I don't remember when I first saw it... but I wouldn't be surprised. Next time it happens I'll take a few javacore dumps and see if I can figure out what it has tripped over. — keshlam, Apr 08 '14 at 00:46

score -2 · Answer 1 · answered Apr 07 '14 at 10:48

-2

When you use the term "Waiting Thread" the computer assumes that the thread is waiting for something. Thus, the computer keeps checking whether those threads are to be started or ended.

And so, it uses 50% of the CPU memory.

answered Apr 07 '14 at 10:48

Shantanu Chandra

87
1
1
6

Why is eclipse eating almost all of CPU for no apparent reason

1 Answers1