Add write barriers when setting Tasks' scope field.

[NHDaly]

This is needed because the field is a jl_value_t* being set in native code.
Presumably this will fix #59483

[vtjnash]

Assigning to the fields of current task does not use a write barrier (the gc knows this would be too costly)

[Keno]

fields of current task

all, tasks right?

julia/src/gc-stock.c

Lines 2362 to 2363 in e8bf6c4

	// assume tasks always reference young objects: set lowest bit
	uintptr_t nptr = (npointers << 2) | 1 | bits;

[vtjnash]

Are they always trapped in the remset? I thought I was told it was only the current task, since the task itself isn't colored (just the metadata update here) when being stored back

[Keno]

You're right, only the current task on all threads gets queued to the remset: https://github.com/JuliaLang/julia/blob/master/src/gc-stock.c#L2770-L2774

So what does that imply for the semantics of the write barrier? Do we need to wb on context switch if we're switching out the task (plus the one assignment in task creation where the task we're assigning is not the current task).

[vtjnash]

Yes, it is supposed to have one on context switch too

julia/src/task.c

Lines 201 to 204 in e57442f

	// this task's stack could have been modified after
	// it was marked by an incremental collection
	// move the barrier back instead of walking it again here
	jl_gc_wb_back(lastt);

The one in creation is usually either jl_gc_wb_knownold or jl_gc_wb_fresh (a no-op in either case), since the only value we have constructed during bootstrapping by the time we need to allocate a task is nothing

[Keno]

Given discussion then - I think this is the only one that is required.

[Keno]

Except, the task is fresh and jl_malloc_stack is JL_NOTSAFEPOINT, so I think we're back to mystery.

[NHDaly]

Okay, well, this PR didn't help with our crash anyway, so indeed maybe none of these write barriers are needed.

I can close the PR -- but reading the thread above, i'm not left with confidence in whether any of these are needed. Are you guys sure that none of them are needed? If you are sure, please close this PR. Or feel free to take it over however you see fit - i relinquish unto you :)

[Keno]

Are you guys sure that none of them are needed? I

Yeah, we're pretty sure. The one that assigns to the newly allocated task could possibly use a jl_gc_wb_fresh to annotate the no-op, but that's neither here nor there.