You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
KSP 1.9.21-1.0.15 has started leaking memory and causing OOM issues & GC thrash when being used in a daemon environment. Our Buck builds use a long-lived buckd daemon process:
For subsequent commands, Buck checks for the running daemon process and if found, uses the daemon to execute the command. Using the Buck daemon can save significant time as it avoids the overhead of starting a Java virtual machine (JVM) and loading the Buck class files
I performed the same build of a smaller app (larger apps fail to compile after 2x their normal time due to OOM or stuck in GC thrash):
1.0.14: 1.5 GB used
1.0.16: 5 GB used
1.0.16 is on the left, 1.0.14 on the right. At the end of compilation, there were 116 mockproject instances in memory on the new version as opposed to 0 on the older version.
MockProject was identified as a potential leak by Memory Analyzer Tool & the path to GC roots looks like:
The text was updated successfully, but these errors were encountered:
KSP
1.9.21-1.0.15
has started leaking memory and causing OOM issues & GC thrash when being used in a daemon environment. Our Buck builds use a long-lived buckd daemon process:I performed the same build of a smaller app (larger apps fail to compile after 2x their normal time due to OOM or stuck in GC thrash):
1.0.16 is on the left, 1.0.14 on the right. At the end of compilation, there were 116 mockproject instances in memory on the new version as opposed to 0 on the older version.
MockProject was identified as a potential leak by Memory Analyzer Tool & the path to GC roots looks like:
The text was updated successfully, but these errors were encountered: