[jira] [Closed] (GROOVY-11955) Provide a size guard for flattening of chained method calls

["Paul King (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-11955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul King closed GROOVY-11955.
------------------------------

> Provide a size guard for flattening of chained method calls
> -----------------------------------------------------------
>
>                 Key: GROOVY-11955
>                 URL: https://issues.apache.org/jira/browse/GROOVY-11955
>             Project: Groovy
>          Issue Type: Bug
>            Reporter: Daniel Kuppitz
>            Assignee: Paul King
>            Priority: Major
>             Fix For: 6.0.0-alpha-1, 5.0.6
>
>
> The chained call method flattening we added in GROOVY-7785 generates slightly slower bytecode and slightly larger bytecode. This isn't necessarily a problem for most code but for frameworks like Spock which inject quite a bit of code when converting assertions to their value-recording form, it can reduce the number of assertions that can appear in a method before hitting JVM limits.
> Credit to Juho Naalisvaara on Slack for providing the example (made up example to show an issue they were having in their real tests):
> {code}
> static def generateSpec(def count) {
>     def assertions = (1..count).collect { i ->
>         "assert obj.field${i % 10} == 'value${i % 10}'"
>     }.join("\n\t\t\t\t")
>     def spec = """\
> @Grab('org.spockframework:spock-core:2.4-groovy-5.0')
> import spock.lang.Specification
> class MethodTooLargeReproducerSpec extends Specification {
>     def "verifyAll with ${count} assertions"() {
>         given:
>             def obj = [field0: 'value0', field1: 'value1', field2: 'value2',
>                        field3: 'value3', field4: 'value4', field5: 'value5',
>                        field6: 'value6', field7: 'value7', field8: 'value8',
>                        field9: 'value9']
>         expect:
>             verifyAll {
>             \t${assertions}
>             }
>     }
> }
> """
> }
> def gcl = new GroovyClassLoader()
> (589..597).step(1).each { count ->
>     def src = generateSpec(count)
>     try {
>         gcl.parseClass(src)
>         println "OK:     ${count}"
>     } catch (Exception e) {
>         println "FAILED: ${count} — ${e.message}"
>         System.exit(1)
>     }
> }
> {code}
> This code bombs out with an error like this:
> {noformat}
> FAILED: 589 — startup failed:
> General error during instruction selection: Method too large: MethodTooLargeReproducerSpec$__spock_feature_0_0_closure1.doCall (Ljava/lang/Object;)Ljava/lang/Object;
> groovyjarjarasm.asm.MethodTooLargeException: Method too large: MethodTooLargeReproducerSpec$__spock_feature_0_0_closure1.doCall (Ljava/lang/Object;)Ljava/lang/Object;
> 	at groovyjarjarasm.asm.MethodWriter.computeMethodInfoSize(MethodWriter.java:2088)
> ...
> {noformat}
> For Groovy 5.0.4 you could have 595 assertions (with similar complexity to above) in a method before hitting this limit. In Groovy 5.0.5 you could only have 585. A small decrease, and yes workarounds like splitting the method come to mind, but I propose to add a guard so we do the flattening only when chaining depth gets above a threshold.
> In addition, the flattened bytecode is very slightly less performant, so this will be a win for code not needing the unrolling. We know the stackoverflow territory covered by GROOVY-7785 is 500-1000 calls deep, so I was going to propose a threshold of 64. We can adjust if we don't find that gives us best performance.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)