[
https://issues.apache.org/jira/browse/GROOVY-12465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-12465:
-------------------------------
Description:
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.
```
> 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)
