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