Skip to content

Conversation

@vtjnash
Copy link
Member

@vtjnash vtjnash commented Sep 15, 2025

This is as an alternative to changing all allocation functions to mutating all memory and returning an aliasing pointer. This operates usually late in the pipeline, so either should not make much difference, but I think it should suffice to mark this volatile to prevent any de-duplication of this load, and this should also be most conservative for GC but more liberal for other optimizations.

Fixes #59547

Produced with dubious help by Claude.

@vtjnash vtjnash added GC Garbage collector backport 1.11 Change should be backported to release-1.11 backport 1.12 Change should be backported to release-1.12 labels Sep 15, 2025
@vtjnash vtjnash requested review from Keno and gbaraldi September 15, 2025 17:34
@gbaraldi
Copy link
Member

This LGTM, there's very little optimizations that are legal around these GC stores at that point

This is as an alternative to changing all allocation functions to
mutating all memory and returning an aliasing pointer. This operates
usually late in the pipeline, so either should not make much difference,
but I think it should suffice to mark this volatile to prevent any
de-duplication of this load, and this should also be most conservative.

Fixes #59547

Written by Claude.
@oscardssmith
Copy link
Member

why volitile rather than sequentially consistent?

@gbaraldi
Copy link
Member

There aren't any atomic requirements there. It just can't assume the value that was there cannot change.

@vtjnash vtjnash merged commit 218f691 into master Sep 16, 2025
5 of 7 checks passed
@vtjnash vtjnash deleted the jn/59547 branch September 16, 2025 00:33
KristofferC pushed a commit that referenced this pull request Sep 17, 2025
This is as an alternative to changing all allocation functions to
mutating all memory and returning an aliasing pointer. This operates
usually late in the pipeline, so either should not make much difference,
but I think it should suffice to mark this volatile to prevent any
de-duplication of this load, and this should also be most conservative
for GC but more liberal for other optimizations.

Fixes #59547

Produced with dubious help by Claude.

(cherry picked from commit 218f691)
KristofferC pushed a commit that referenced this pull request Sep 17, 2025
This is as an alternative to changing all allocation functions to
mutating all memory and returning an aliasing pointer. This operates
usually late in the pipeline, so either should not make much difference,
but I think it should suffice to mark this volatile to prevent any
de-duplication of this load, and this should also be most conservative
for GC but more liberal for other optimizations.

Fixes #59547

Produced with dubious help by Claude.

(cherry picked from commit 218f691)
@DilumAluthge DilumAluthge mentioned this pull request Sep 20, 2025
59 tasks
@KristofferC KristofferC mentioned this pull request Sep 24, 2025
24 tasks
@KristofferC KristofferC removed the backport 1.12 Change should be backported to release-1.12 label Sep 24, 2025
xal-0 pushed a commit to xal-0/julia that referenced this pull request Sep 30, 2025
This is as an alternative to changing all allocation functions to
mutating all memory and returning an aliasing pointer. This operates
usually late in the pipeline, so either should not make much difference,
but I think it should suffice to mark this volatile to prevent any
de-duplication of this load, and this should also be most conservative
for GC but more liberal for other optimizations.

Fixes JuliaLang#59547

Produced with dubious help by Claude.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport 1.11 Change should be backported to release-1.11 GC Garbage collector

Projects

None yet

Development

Successfully merging this pull request may close these issues.

failure to emit mandatory write barriers for memoryref store in v1.12 (regression)

4 participants