You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is not permitted to be either a safepoint or equivalently a
safepoint region transition while a lock is being held that might be
needed by GC as that forms a cycle. We must ensure that this thread is
permitted to keep running, so that it becomes possible for it to reach
the condition wait call and release the lock to keep in synchronized
with the notify_all in the sweep. Alternatively we could use a
timed_wait and continuous poll the GC (to ensure we actually run GC
periodically), but I would rather that be an internal GC policy than an
external forcing factor here. This prevents the GC from recruiting this
thread (via a signal) to help GC even though it is observably sleeping,
but we might consider later integrating a way for the GC to notify a set
of condition variables upon starting to wake them and recruit them
temporarily via a subsequent safepoint such as (in julia-syntax psuedocode):
gc_safe_enter()
lock(condvar) do
while !condmet
wait(condvar)
while gc_running
unlock(lock)
unsafe_enter()
gc_safepoint()
unsafe_leave()
lock(lock)
end
end
end
gc_safe_leave()
voidjl_gc_safe_leave(jl_ptls_tptls, int8_tstate) JL_NOTSAFEPOINT_LEAVE; // this might not be a safepoint, but we have to assume it could be (statically)
355
+
// these might not be a safepoint (if they are no-op safe=>safe transitions), but we have to assume it could be (statically)
356
+
// however mark a delineated region in which safepoints would be not permissible
0 commit comments