[
https://issues.apache.org/jira/browse/GROOVY-12465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18128884#comment-18128884
]
ASF GitHub Bot commented on GROOVY-12465:
-----------------------------------------
paulk-asert merged PR #2990:
URL: https://github.com/apache/groovy/pull/2990
> Bump asm to 9.11.1
> ------------------
>
> Key: GROOVY-12465
> URL: https://issues.apache.org/jira/browse/GROOVY-12465
> Project: Groovy
> Issue Type: Dependency upgrade
> Reporter: Daniel Sun
> Assignee: Paul King
> Priority: Major
> Fix For: 7.0.0-alpha-1, 6.0.1
>
>
> h3. Frame computation limits and additional tests
> ASM 9.11 adds per-method resource limits to {{ClassWriter}} frame computation
> ({{setComputeLimits}}). They are on by default: 10 MB and 100M operations,
> set at about ten times what the largest {{java.*}} method in the JDK needs. A
> method that goes over fails with {{LimitExceededException}}.
> Groovy computes frames for all generated code ({{COMPUTE_MAXS |
> COMPUTE_FRAMES}}), and its methods are far more expensive to compute than JDK
> methods. With ASM's defaults, ordinary code that compiled under ASM 9.10.1
> fails, even though the methods involved are only 10-20 KB of bytecode:
> * about 424 {{def}} or {{int}} locals with branches, in dynamic or
> {{@CompileStatic}} code
> * about 300 closures in one method
> * about 425 locals in a script body
> * just 108 {{try/catch/finally}} blocks in a {{@CompileStatic}} method
> Methods right at the 64 KB limit need 5-53 times the default operation budget
> and up to about 290 MB. They still compile in under a second, so the 64 KB
> method limit already bounds the worst case.
> h4. Changes
> * {{CompilationUnit}}'s class writer now applies configurable limits, and by
> default they impose no practical limit, restoring the ASM 9.10.1 behaviour.
> * New {{CompilerConfiguration}} settings {{frameComputationMaxBytes}} and
> {{frameComputationMaxOperations}}, with the system/configuration properties
> {{groovy.frame.computation.max.bytes}} and
> {{groovy.frame.computation.max.operations}}. They let sandboxed or embedded
> uses bound what one method of untrusted source can consume.
> * When a configured limit is exceeded, the compile error now names these
> properties.
> h4. Tests
> * New {{gls.sizelimits.MethodSizeTest}}: generated methods about two thirds
> of the way to the 64 KB code limit, covering dynamic and static locals with
> branches, static locals of mixed types, closures, try/catch/finally, dynamic
> and static switch, a large static initializer and a large script body. Each
> case is compiled and run. Against ASM 9.11.1 with its default limits, 7 of
> the 9 cases fail. All pass with this change.
> * {{MethodSizeTest.testConfiguredFrameComputationLimit}}: a low configured
> operation limit fails compilation with {{LimitExceededException}} as the root
> cause, and the error message names the property.
> * {{CompilerConfigurationTest}}: defaults, system properties and
> {{Properties}}, copy constructor, the immutable {{DEFAULT}}, and rejection of
> non-positive values.
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
