[refactoring] investigate memory usage when converting projects

[martinlippert]

I've seen a couple of "out of memory" issues showing up on the language server log output when running project conversions via open-rewrite, but haven't investigated the details yet.

We should take a look to see what is going on and I will try to find out which project(s) trigger this behavior.

[BoykoAlex]

@martinlippert seems like this is resolved for now with a919463 ?

[martinlippert]

Agree, part of this is already solved via the commit that you mentioned, but I would like to continue to investigate this a bit further. It still seems like running the reconciling based on OpenRewrite causes quite some amount of heap and CPU usage, even for small workspaces with small projects, so something we need to investigate further. I am moving this to 4.17.1 for additional work.

[martinlippert]

I ran some analysis on this, not in every depth, but still some early insights here. I captured a memory dump of the language server process after forcing a GC and after opening a larger workspace in the workspace.

• org.springframework.ide.vscode.boot.java.rewrite.RewriteCompilationUnitCache seems to be the one object that sticks out the most in size.
• there are many many objects lurking around of type java.util.zip.ZipFile$Source - looks like pointing to JAR files from the classpath of the projects in my workspace
• there is another set of objects of type jdk.nio.zipfs.ZipFileSystem around. They seem to be referenced by the compilation unit cache a relatively deep reference chain

[BoykoAlex]

Likely ZipFile$Source and ZipFileSystem are referenced from cached project java parsers... There would be one parser per project kept around. If parser isn't re-used then it takes longer to parse a java source. The Rewrite CU cache might become empty if we switch to JDT for marking problems in the code...

[martinlippert]

Latest tests show that the overall memory consumption is still an issue that we need to investigate further, but it has improved quite a bit since I filed this issue, so we should mark this one here as fixed for now.

Additional memory optimizations will be worked on in separate, new and probably more specific issues.