Happens inside spock expect, verifyAll

I can work around it by splitting the spock Specification.verifyAll-call

I will try to create a reproducer

I have reproducer. With 5.0.4 we can have 601 “complex” asserts inside verifyAll, with 5.0.5 590. Note that my actual production code has less than 350. With trivial 1==1 asserts i could not reproduce the diff

Is this kind of observable change in code compilation considered a bug? The limits are quite arbitrary

Reproducer https://github.com/jnaalisv/groovy-505-method-too-large

I can find i acceptable if u dont consider this a bug but clearly something changed in the compilation so that we hit this limit now earlier

Claude still pondering ... Confirmed — threshold dropped from 596 → 586 asserts between 5.0.4 and 5.0.5. Let me get the bytecode diff.

Closure class is ~1114 bytes larger in 5.0.5 (at 500 asserts) I see a constant-pool difference. 5.0.4 has a direct Methodref ValueRecorder.record; 5.0.5 has an InvokeDynamic invoke:(ValueRecorder,I,Object)Object taking its place.

Found it. 5.0.4 emits invokevirtual ValueRecorder.record (3 bytes); 5.0.5 emits invokedynamic invoke:(ValueRecorder,I,Object)Object (5 bytes) — +2 bytes per record call.

Empirical confirmation: patching just InvokeDynamicWriter.class in the 5.0.5 jar back to the pre-GROOVY-7785 version produced closure bytecode byte-identical to 5.0.4 (84106 bytes exactly). So the regression is isolated to that one commit. Summary Cause: f1d6e5f025 GROOVY-7785 "StackoverflowException when using too many chained method calls" (Daniel Sun, Feb 8). The fix added an iterative receiver-chain walker to InvokeDynamicWriter.prepareIndyCall: // old: receiver.visit(controller.getAcg()); // new: visitReceiverOfMethodCall(receiver); // flattens chain, emits each intermediate call via finishIndyCallForChain → invokedynamic Why Spock's verifyAll is affected. Each assert obj.fieldN == 'valueN' rewrites into roughly: verifyCondition(ec, vr, "…", line, col, null, vr.record(vr.startRecordingValue(3), compareEqual( vr.record(vr.startRecordingValue(1), vr.record(vr.startRecordingValue(0), obj.get()) // ← this record() .getProperty("fieldN")), // ← is the receiver of getProperty vr.record(vr.startRecordingValue(2), "valueN")))) The inner record(...) call has another method call — getProperty(...) — as its parent, i.e. it is a receiver that is itself a MethodCallExpression. In 5.0.4 visiting that receiver recursed through AsmClassGenerator.visitMethodCallExpression, where the resolved method target let it emit invokevirtual ValueRecorder.record (3 bytes). In 5.0.5 the new visitReceiverOfMethodCall pushes it onto a chain and emits it via finishIndyCallForChain as invokedynamic invoke:(ValueRecorder,I,Object)Object (5 bytes). Arithmetic: +2 bytes per assert × 500 asserts = +1000 bytes, matching the observed 1114-byte growth. That shrinks the 64 KB headroom by ~10 asserts, matching the 596 → 586 threshold drop. Suggested fix direction: the intent of GROOVY-7785 is only to prevent real recursion blowups for long a.b().c().d()… chains. A minimal tweak in visitReceiverOfMethodCall would preserve the original non-regressive behavior for short chains, e.g. keep receiver.visit(acg) when chain.size() <= N (pick N around ~32–64, well under the JVM recursion limit), and only switch to the iterative/indy path when the chain is genuinely deep. That restores direct invokevirtual for common cases while still fixing the deep-chain StackOverflow. Alternatively, finishIndyCallForChain could honor a resolved MethodNode target (set by AST transforms such as Spock's) and emit a direct invokevirtual for those.

So, it was a fix we applied to make performance better for a different situation that is causing what you see.

That does look like something we can action.

But, you are right that we should have a test that would put bounds on a potential fix.

I think I will place all that info in a jira including your test if that is okay, or happy if you want to create it.

There is a fix in place for 5.0.6 maybe a week or two at most away that fixes your problem. Note that you are approaching the JVM limit for Spock annotations even after the fix - as your were on 5.0.4.