Editing WebDSL (large) modules with latest Spoofax/WebDSL editor combination is tedious as the editor is very slow to respond. It takes a long time for characters to even appear.

Submitted by Eelco Visser on 13 March 2010 at 13:49

Is this a new problem? AFAIK the Editor doesn’t do any semantic analysis atm, so that can’t be it. Do you have an example file where the editor is slow so we can reproduce this problem?

This is likely a duplicate of Spoofax/45, where I also asked for tips to reproduce this – I have only ever seen small <1 second delays myself, and haven’t been able to find out what caused them…

Have you tried editing files in the researchr project? (I have three Eclipse windows open with multiple files open in multiple projects)

A re-start of Eclipse appears to help.

I think this is a memory consumption issue. For a large file, the footprint of the parse tree, AST, and token stream together is quite big and consists of a big number of small objects.

There doesn’t seem to be a good way to reproduce this problem, but when it does occur, JVisualVM shows a garbage collection event (sometimes collecting 800 out of 1000 Mb of memory assigned to the VM). Recording a heap dump seems suffer from the Heisenberg principle and triggers a garbage collect, but of all object instances the top three is: aterm.SharedObjectFactory$Entry (12.5%), char, int. With a quarter million aterm.SharedObjectFactory$Entry instances, each subclassing WeakReference and thus potentially interacting with the garbage collector, I think the ATerm library is (at least partially) to blame here. The garbage collector shouldn’t lead to delays like this (even if they are at most 1~2 seconds in my tests).

Possible solutions that may avoid GC delays:

• Avoid ATerms by implementing Spoofax/9

• Implement incremental parsing

• Maintain only weak references to the AST and token stream of background editors

• Optimize the ASTNode classes and their generous use of ArrayLists (finally breaking free from the IAst interface)

Possible workarounds:

• Assign a larger heap space (e.g. -Xmx1500m) and/or open fewer editors in order to trigger fewer GC events

• Try a different garbage collector. E.g., XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSClassUnloadingEnabled. Or maybe -XX:+UseCompressedOops to enable 32-bits pointers and a compatible GC implementation

I’d like to reemphasize that proper heap size setting is important here: Eclipse tends to do garbage collection very frequently if you set the heap size to 512 MB or less.

Also, fixing Spoofax/88 may also help here.

There have been some memory leak fixes in recent versions that should (hopefully) address this issue: Spoofax/112, Spoofax/120, and others. Spoofax/88 should address needless parse tree allocations. I’m closing this issue. If this is still a problem, please reopen it.