[
https://issues.apache.org/jira/browse/GROOVY-12288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-12288.
--------------------------------
Fix Version/s: 6.0.0-beta-3
Assignee: Daniel Sun
Resolution: Fixed
> Cache ClassWriter getCommonSuperClass lookups per class
> -------------------------------------------------------
>
> Key: GROOVY-12288
> URL: https://issues.apache.org/jira/browse/GROOVY-12288
> Project: Groovy
> Issue Type: Improvement
> Reporter: Daniel Sun
> Assignee: Daniel Sun
> Priority: Major
> Fix For: 6.0.0-beta-3
>
>
> Bytecode generation uses an ASM {{ClassWriter}} with {{{}COMPUTE_FRAMES{}}}.
> Frame computation calls {{getCommonSuperClass}} at every control-flow merge.
> Groovy overrides that method so types still being compiled are resolved
> through {{ClassNode}} ({{{}CompileUnit{}}}, generated inner classes,
> {{{}ClassNodeResolver{}}}) rather than {{{}Class.forName{}}}.
> {{COMPUTE_FRAMES}} asks for the same binary-name pairs many times inside one
> class. Each call converts slashes to dots, resolves two \{{ClassNode}}s, and
> walks superclasses with isDerivedFrom. Class generation is about half of
> compile wall time.
> h3. Approach
> Memoize both steps on the {{ClassWriter}} created by
> {{{}CompilationUnit.createClassVisitor{}}}. One writer is allocated per
> generated class and discarded afterwards, so the maps cannot go stale across
> classes.
> ||Cache||Key||Value||
> |{{classNodeByName}}|binary name (dot form)|{{ClassNode}} (successful lookups
> only)|
> |{{commonSuperByPair}}|canonical pair of internal names|internal name of the
> common superclass|
> The key is order-independent: {{(A,B)}} and {{(B,A)}} share one entry. The
> common-superclass algorithm is unchanged.
> h3. Impact
> Compile-time only. {{getCommonSuperClass}} results and generated bytecode
> stay the same.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
