[
https://issues.apache.org/jira/browse/GROOVY-11792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18098594#comment-18098594
]
ASF GitHub Bot commented on GROOVY-11792:
-----------------------------------------
github-actions[bot] commented on PR #2732:
URL: https://github.com/apache/groovy/pull/2732#issuecomment-5063136116
### JMH summary — classic (commit `7f571e7`)
Speedup vs trailing 90-day baseline on gh-pages. Higher = faster.
`1.00` = in line with history. Per-benchmark ratio, geomean within group.
Time-per-op units inverted so direction is consistent. The *calibrated*
column divides out this runner's speed vs the baseline hardware, as
measured by Groovy-independent pure-Java ruler benchmarks.
| Group | Speedup | Calibrated | n |
|--------|---------|------------|---|
| bench | 0.984 × | 1.018 × | 84 |
| core | 1.014 × | 0.909 × | 77 |
| grails | 0.995 × | 0.936 × | 80 |
<sub>Runner calibration (this run vs baseline hardware): bench 0.97× (26
rulers) · core-ag 1.12× (3 rulers) · core-hz 1.11× (3 rulers) · grails-ad 0.97×
(3 rulers) · grails-ez 1.15× (3 rulers)</sub>
<sub>Baseline: <code>dev/bench/jmh/<part>/classic/data.js</code> on
gh-pages, trailing 90 days. <a
href="https://apache.github.io/groovy/dev/bench/jmh/summary.html";>Daily
dashboard</a> · <a
href="https://apache.github.io/groovy/dev/bench/jmh/";>Per-suite raw
data</a></sub>
<!
> for-in loop variable captured by closure/AIC sees final value, not
> per-iteration value
> --------------------------------------------------------------------------------------
>
> Key: GROOVY-11792
> URL: https://issues.apache.org/jira/browse/GROOVY-11792
> Project: Groovy
> Issue Type: Bug
> Reporter: Daniel Sun
> Priority: Major
>
> h2. Problem
> When a *for-in* (enhanced for-each) loop variable is shared with a deferred
> closure or anonymous inner class (AIC), all captures observe the *final* loop
> value after the loop finishes, instead of the value from the iteration that
> created the capture.
> Classic {{for}} / {{while}} loops are a separate construct and are not the
> subject of this report.
> This is the same class of surprise as Java’s historical “effectively final
> loop variable” / deferred-lambda story, but Groovy’s shared variables use a
> single {{groovy.lang.Reference}} updated in place across for-in iterations,
> so deferred use always sees the last assignment.
> h2. Expected behaviour
> Each deferred capture should observe the for-in value (and index, when
> present) from the {*}iteration in which it was created{*}.
> h2. Actual behaviour
> Every deferred capture sees the *last* iteration’s value.
> h2. Reproducer
> {code:groovy}
> import java.util.function.Supplier
> def numbers = [1, 2, 3]
> List suppliers = []
> for (n in numbers) {
> Supplier s = { n * n }
> suppliers << s
> }
> // Expected: [1, 4, 9]
> // Actual: [9, 9, 9]
> assert suppliers.collect { it.get() } == [1, 4, 9]
> {code}
> Colon syntax ({{{}for (Integer n : numbers){}}}), {{{}@CompileStatic{}}},
> indexed for-in ({{{}for (i, v in …){}}}), array/enumeration SC paths, and AIC
> capture (see GROOVY-11818) show the same pattern.
> h2. Workaround
> Introduce a fresh local per iteration so the closure captures a non-shared
> (or newly shared) binding:
> {code:groovy}
> for (n in numbers) {
> def local = n
> suppliers << { local * local }
> }
> {code}
> h2. Root cause (classgen)
> For-in loop heads store into a *single* shared {{Reference}} for
> closure-shared loop variables ({{{}OperandStack.storeVar{}}} →
> {{{}Reference#set{}}}). Closures/AICs created in the body capture that one
> holder; later iterations overwrite it.
> Relevant area: {{org.codehaus.groovy.classgen.asm}} ({{{}StatementWriter{}}},
> {{{}StaticTypesStatementWriter{}}}, {{{}CompileStack{}}},
> {{{}WriterController{}}}).
> h2. Resolution approach
> * When per-iteration capture is enabled (default), each for-in iteration
> that stores a *holder* loop variable allocates a *fresh*
> {{groovy.lang.Reference}} (value and shared index).
> * Within the *same* iteration, assignment to the loop variable remains
> visible to captures created there (still one {{Reference}} per iteration).
> * Non-shared loop variables and non-loop shared variables are unchanged.
> * Dynamic and static compilation for-in paths (iterator, SC array, SC
> enumeration) share the same store/increment helpers.
> h3. Language-compatibility opt-out
> This changes observable capture semantics (default-on). Historical “single
> shared {{Reference}} / final value” behaviour can be restored with either:
> * system property: {{groovy.for.loop.capture=false}}
> * {{{}CompilerConfiguration{}}}: put {{Boolean.FALSE}} for key
> {{CompilerConfiguration.FOR_LOOP_CAPTURE}} ({{{}"forLoopCapture"{}}}) in the
> optimization-options map
> Notes:
> * This is a *language-compatibility* switch, not a performance optimization.
> * Setting optimization option {{"all"}} to {{false}} does *not* disable
> for-in recapture.
> h2. Related issues
> * GROOVY-11818 — for-in variable captured by anonymous inner class (same
> root cause)
> * GROOVY-11751 — indexed for-in with shared index (holder index
> store/increment)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
