Preserve the scope across the exception handler#60647
Conversation
|
LGTM on the root change, but NAK on the unnecessary write barriers as inline commented (and similar for the ones in the runtime). |
|
@Keno I added comments for the wbs. Does that look okay, or do you want to use something like |
If you're gonna add a comment anyway, might as well make it executable, so that it's standardized. |
Fixes JuliaLang#60620 (comment) previously we were preserving the new scope across the exception handler, instead of the scope that was actually stored in the eh context. The additionaly write_barriers are probably not necessary (the task should always be young. Alternative to JuliaLang#60620
I was looking for a previous example of using marker functions for this, but didn't find one. Do you have an example? |
|
Why doesn't this one need to be backported to 1.11 and 1.13 as well? |
|
Technically this needs to be back ported to v1.11 but I don't expect a new release there.
Because I was looking at the wrong PR when I added the labels ;) |
|
I wanted to add a LLVM code generation test, but looking at a slightly simplified version: On 1.11: So It is only in #55907 when the scope is moved into the _eh_frame that we are preserving the "wrong one", and indeed So we don't need to backport this to 1.11 |
Fixes #60620 (comment) previously we were preserving the new scope across the exception handler, instead of the scope that was actually stored in the eh context. The additionaly write_barriers are probably not necessary (the task should always be young. Alternative to #60620
37d2b0d to
1b67f8f
Compare
Co-authored-by: Keno Fischer <keno@juliacomputing.com>
|
Thanks again Valentin! 🎉 |
1 similar comment
|
Thanks again Valentin! 🎉 |
We store the previous scope in the eh_state and thus hide it from GC. This means we need to manually preserve that scope across the `try ... catch`, instead fo the new scope that we switch to. --------- Co-authored-by: Nathan Daly <nathan.daly@relational.ai> Co-authored-by: Keno Fischer <keno@juliacomputing.com>
* Preserve the scope across the exception handler (JuliaLang#60647) We store the previous scope in the eh_state and thus hide it from GC. This means we need to manually preserve that scope across the `try ... catch`, instead fo the new scope that we switch to. --------- Co-authored-by: Nathan Daly <nathan.daly@relational.ai> Co-authored-by: Keno Fischer <keno@juliacomputing.com> * add wb_back on all task switch paths (JuliaLang#60617) Since this task's stack or scope field could have been modified after it was marked by an incremental collection (and not just for copy stacks), move the barrier back unconditionally here. --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com> --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Keno Fischer <keno@juliacomputing.com> Co-authored-by: Jameson Nash <vtjnash@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com>
* Preserve the scope across the exception handler (JuliaLang#60647) We store the previous scope in the eh_state and thus hide it from GC. This means we need to manually preserve that scope across the `try ... catch`, instead fo the new scope that we switch to. --------- Co-authored-by: Nathan Daly <nathan.daly@relational.ai> Co-authored-by: Keno Fischer <keno@juliacomputing.com> * add wb_back on all task switch paths (JuliaLang#60617) Since this task's stack or scope field could have been modified after it was marked by an incremental collection (and not just for copy stacks), move the barrier back unconditionally here. --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com> --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Keno Fischer <keno@juliacomputing.com> Co-authored-by: Jameson Nash <vtjnash@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com>
* Preserve the scope across the exception handler (JuliaLang#60647) We store the previous scope in the eh_state and thus hide it from GC. This means we need to manually preserve that scope across the `try ... catch`, instead fo the new scope that we switch to. --------- Co-authored-by: Nathan Daly <nathan.daly@relational.ai> Co-authored-by: Keno Fischer <keno@juliacomputing.com> * add wb_back on all task switch paths (JuliaLang#60617) Since this task's stack or scope field could have been modified after it was marked by an incremental collection (and not just for copy stacks), move the barrier back unconditionally here. --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com> --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Keno Fischer <keno@juliacomputing.com> Co-authored-by: Jameson Nash <vtjnash@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com>
We store the previous scope in the eh_state and thus hide it from GC. This means we need to manually preserve that scope across the `try ... catch`, instead fo the new scope that we switch to. --------- Co-authored-by: Nathan Daly <nathan.daly@relational.ai> Co-authored-by: Keno Fischer <keno@juliacomputing.com> (cherry picked from commit f22ae77)
|
[This doesn't backport cleanly to 1.12. I've asked Valentin if he can put together a manual backport to |
We store the previous scope in the eh_state and thus hide it from GC. This means we need to manually preserve that scope across the `try ... catch`, instead fo the new scope that we switch to. --------- Co-authored-by: Nathan Daly <nathan.daly@relational.ai> Co-authored-by: Keno Fischer <keno@juliacomputing.com> (cherry picked from commit f22ae77)
* Preserve the scope across the exception handler (JuliaLang#60647) We store the previous scope in the eh_state and thus hide it from GC. This means we need to manually preserve that scope across the `try ... catch`, instead fo the new scope that we switch to. --------- Co-authored-by: Nathan Daly <nathan.daly@relational.ai> Co-authored-by: Keno Fischer <keno@juliacomputing.com> * add wb_back on all task switch paths (JuliaLang#60617) Since this task's stack or scope field could have been modified after it was marked by an incremental collection (and not just for copy stacks), move the barrier back unconditionally here. --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com> --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Keno Fischer <keno@juliacomputing.com> Co-authored-by: Jameson Nash <vtjnash@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com>
* Preserve the scope across the exception handler (JuliaLang#60647) We store the previous scope in the eh_state and thus hide it from GC. This means we need to manually preserve that scope across the `try ... catch`, instead fo the new scope that we switch to. --------- Co-authored-by: Nathan Daly <nathan.daly@relational.ai> Co-authored-by: Keno Fischer <keno@juliacomputing.com> * add wb_back on all task switch paths (JuliaLang#60617) Since this task's stack or scope field could have been modified after it was marked by an incremental collection (and not just for copy stacks), move the barrier back unconditionally here. --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com> --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Keno Fischer <keno@juliacomputing.com> Co-authored-by: Jameson Nash <vtjnash@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com>
* Preserve the scope across the exception handler (JuliaLang#60647) We store the previous scope in the eh_state and thus hide it from GC. This means we need to manually preserve that scope across the `try ... catch`, instead fo the new scope that we switch to. --------- Co-authored-by: Nathan Daly <nathan.daly@relational.ai> Co-authored-by: Keno Fischer <keno@juliacomputing.com> * add wb_back on all task switch paths (JuliaLang#60617) Since this task's stack or scope field could have been modified after it was marked by an incremental collection (and not just for copy stacks), move the barrier back unconditionally here. --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com> --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Keno Fischer <keno@juliacomputing.com> Co-authored-by: Jameson Nash <vtjnash@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com>
We store the previous scope in the eh_state and thus hide it from GC. This means we need to manually preserve that scope across the `try ... catch`, instead fo the new scope that we switch to. --------- Co-authored-by: Nathan Daly <nathan.daly@relational.ai> Co-authored-by: Keno Fischer <keno@juliacomputing.com> (cherry picked from commit f22ae77)
* Preserve the scope across the exception handler (JuliaLang#60647) We store the previous scope in the eh_state and thus hide it from GC. This means we need to manually preserve that scope across the `try ... catch`, instead fo the new scope that we switch to. --------- Co-authored-by: Nathan Daly <nathan.daly@relational.ai> Co-authored-by: Keno Fischer <keno@juliacomputing.com> * add wb_back on all task switch paths (JuliaLang#60617) Since this task's stack or scope field could have been modified after it was marked by an incremental collection (and not just for copy stacks), move the barrier back unconditionally here. --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com> --------- Co-authored-by: Valentin Churavy <v.churavy@gmail.com> Co-authored-by: Keno Fischer <keno@juliacomputing.com> Co-authored-by: Jameson Nash <vtjnash@gmail.com> Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com>
Fixes
#60620 (comment)
previously we were preserving the new scope across the exception
handler, instead of the scope that was actually stored in the eh
context.
The additionaly write_barriers are probably not necessary (the task
should always be young.
Alternative to #60620