ANTLR plugin high CPU utilization during idle

[gravityfox]

Windows 10 x64
IntelliJ IDEA 2024.1.1
IDEA plugin version 1.23.1

When starting the IDE with the plugin enabled, CPU utilization is normal.

After opening a .g4 file, CPU usage spikes and stays high.

CPU utilization continues staying high if the file is closed. It also stays high if parsing is stopped by the "stop" button in the preview pane. The preview pane does not ever need to have opened for the high utilization to start.

When setting idea64.exe affinity to just cores 0 and 2 (to avoid hyper-threading), both cores are at 100% utilization. Giving IDEA additional cores distributes the load, which suggests 2 no-sleep looping threads.

Closing the project does not cause this utilization to come back down. Only terminating the IDE and restarting causes idle utilization to be normal again.

This anomalous utilization does not occur if the plugin is disabled.

After some testing, I discovered that this does not happen to all grammars. I have created an offending grammar that causes this issue:

grammar Bad;

start: list EOF;

list: x list;

x: 'test';

[bjansen]

Hi, and thanks for the detailed description.

It seems your problem is related to a bad grammar. To fix #399 I implemented a "watchdog" that prevents the grammar interpreter from being stuck in an infinite loop when it parses such grammars. It's working correctly, but in your case the error recovery strategy is somehow trying to recover again and again from the exception thrown by the watchdog.

You can 'fix' your grammar by removing the infinite recursion:

list: x list?;

And on my side I'll fix the plugin to avoid the infinite recovery and try to provide a useful error message.

BTW antlr itself (not the IJ plugin) also crashes on your grammar:

Exception in thread "main" java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.antlr.v4.gui.TestRig.process(TestRig.java:207)
	at org.antlr.v4.gui.TestRig.process(TestRig.java:158)
	at org.antlr.v4.gui.TestRig.main(TestRig.java:119)
Caused by: java.lang.StackOverflowError
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)
	at org.antlr.v4.runtime.atn.PredictionContext.fromRuleContext(PredictionContext.java:72)

[gravityfox]

For context, this happened while I was doing a direct 1-to-1 conversion of a grammar from another project. Under the direction of my professor, I was attempting to keep the grammar structure as close as possible to the original.

Although I cannot pull up the original grammar (I did not keep it, even though maybe I should have), I know that it did not have a forced infinite loop (Running ANTLR itself worked fine, and would produce a meaningful parse tree), but still caused this performance issue. I eventually switched to alternate notation of list: listitem*, which worked flawlessly.

At some point in the near future, when I have some extra time, I'll revisit this to try and recreate that behavior so you have a more concrete example to work with.