daniellansun opened a new pull request, #3230:
URL: https://github.com/apache/groovy/pull/3230

   https://issues.apache.org/jira/browse/GROOVY-12332
   
   Since 6.0.0-beta-3, compiling one very large class needed more heap than 
Gradle's default forked compiler (512m). The same sources spread across 
ordinary-sized classes still compiled. Bisect lands on GROOVY-12318 
(`1b0ebf6102`), which moved the parser prediction cache onto a private ATN and 
stopped clearing it in place.
   
   Two strong references then survived parsing:
   
   - Each parameter kept its parse context so a record header could be lowered. 
That context's parent chain is the whole concrete syntax tree, so one parameter 
pinned every token of the file.
   - The recognizer kept its interpreter. After the cache was replaced, a 
finished parser still pointed at the retired ATN, so the prediction graph 
stayed live through class generation.
   
   Both are dropped once the AST is built. The shared cache remains softly 
reachable for later files, which is what keeps an idle compiler copy 
collectable.
   
   Checked against the groovy-verify sources from the report (VerifyChecker at 
15,580 lines, plus the rest of `src/main`) on JDK 21:
   
   | compiler | 512m |
   | --- | --- |
   | 6.0.0-beta-3 | compiles |
   | master before this change | `OutOfMemoryError: Java heap space` during 
class generation |
   | this change | compiles (peak during parse, then the graph is released; 
about 135m retained afterwards) |
   
   `./gradlew :lintGate` and `:test --tests bugs.Groovy12332 --tests 
bugs.Groovy12142 --tests org.codehaus.groovy.classgen.RecordTest` passed. 
`bugs.Groovy12332` fails if the release is removed: parameters still hold 
parser contexts, and the prediction cache stays reachable from the finished 
class.
   
   ### Testing
   - `bugs.Groovy12332`
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to