History view consume CPU

[basilevs]

Version

7.6.0

Operating System

MacOS

Eclipse version

Eclipse SDK Version: 2026-06 (4.40)
Build id: I20260318-1800

Bug description

Test steps

I'm not really sure how to reproduce this, but here is what I've done:

• Follow https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md
• View a history of ui/org.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/editor/PDEFormEditor.java
• Leave the Eclipse PDE untouched for a few days.

Workaround

Change selected file filter. This temporarily reduces consumption to 5%.

Actual behavior

Eclipse consumes 20-50% of a CPU core when History view is shown even when the Workbench window is minimized.

Expected behavior

Less than 1% of CPU should be consumed when Eclipse PDE is inactive.

Relevant log output

"main" #3 [259] prio=6 os_prio=31 cpu=27150433.15ms elapsed=110229.61s tid=0x0000000923020000 nid=259 runnable  [0x000000016aff0000]
   java.lang.Thread.State: RUNNABLE
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:260)
	at org.eclipse.swt.widgets.Widget.drawInteriorWithFrame_inView(Widget.java:772)
	at org.eclipse.swt.widgets.Text.drawInteriorWithFrame_inView(Text.java:700)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:6681)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Widget.drawRect(Widget.java:813)
	at org.eclipse.swt.widgets.Text.drawRect(Text.java:759)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:6266)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
	at org.eclipse.swt.widgets.Display.applicationNextEventMatchingMask(Display.java:5589)
	at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5990)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
	at org.eclipse.swt.internal.cocoa.NSApplication.nextEventMatchingMask(NSApplication.java:92)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4008)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1160)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1051)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:684)
	at org.eclipse.ui.internal.Workbench$$Lambda/0x000007c00132e770.run(Unknown Source)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:583)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:173)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:185)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:219)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:149)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:115)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:467)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:298)
	at java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.base@25/DirectMethodHandle$Holder)
	at java.lang.invoke.LambdaForm$MH/0x000007c001051800.invoke(java.base@25/LambdaForm$MH)
	at java.lang.invoke.LambdaForm$MH/0x000007c001051c00.invokeExact_MT(java.base@25/LambdaForm$MH)
	at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base@25/DirectMethodHandleAccessor.java:156)
	at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base@25/DirectMethodHandleAccessor.java:104)
	at java.lang.reflect.Method.invoke(java.base@25/Method.java:565)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:615)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:563)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1415)

Other information

Eclipse SDK Version: 2026-06 (4.40)
Build id: I20260318-1800
OS: Mac OS X, v.26.3.1, aarch64 / cocoa
Java vendor: Oracle Corporation
Java runtime version: 25+36-3489
Java version: 25

*** Features:
org.eclipse.egit (7.6.0.202603022253-r) "Git integration for Eclipse"

*** Plug-in Registry:
org.eclipse.egit (7.6.0.202603022253-r) "Git integration for Eclipse" [Starting]
org.eclipse.egit.core (7.6.0.202603022253-r) "Git integration for Eclipse - Core" [Active]
org.eclipse.egit.doc (7.6.0.202603022253-r) "Git integration for Eclipse - Documentation" [Starting]
org.eclipse.egit.ui (7.6.0.202603022253-r) "Git integration for Eclipse - UI" [Active]

[fedejeanne]

Did you by any chance make a VisualVM sample to see where the CPU cycles are going? We use EGit pretty often and with a large codebase with 20+ years of history and filters like "All changes of resource" but I never experience a CPU spike (or maybe it was so small/short-lived that I never noticed?)

I am using Windows though. Maybe that changes things.

[msohn]

Did you check if your git repository needs a git garbage collection run ?
Select the repository in the repositories view and click Properties > Statistics or run git count-objects -vH to
check the number of loose objects (should be < few thousand for good performance) and pack files (<50, better only few).

Also increasing the window cache and delta base cache limits under Settings > Version Control > Git > WindowCache can improve performance with large repositories. Too small caches can cause frequent reloading and parsing of git objects from packfiles.

[basilevs]

Did you by any chance make a VisualVM sample

Will collect next time.

Did you check if your git repository needs a git garbage collection run ?

I assumed that is could not be related because there was no IO in jstack.

run git count-objects -vH

% git count-objects -vH 
count: 48
size: 204.00 KiB
in-pack: 372620
packs: 13
size-pack: 145.57 MiB
prune-packable: 10
garbage: 0
size-garbage: 0 bytes

But the issue is not reproduced ATM. Will collect if reproduced again.