Convert free_at_safepoint from a vector to a linked list and eliminate its associated mutex

[nwc10]

• move our atomic operations macros to a new header src/atomics.h
• convert free_at_safepoint from a vector to a linked list
• eliminate the mutex mutex_free_at_safepoint by using MVM_casptr
• If we have C11 atomics use atomic_exchange_explicit instead of MVM_casptr

The commit that converts free_at_safepoint to a linked list is code @MasterDuke17 was working on as part of investigating eliminating the FSA

My subsequent changes assume that the pointer generated by the expression STABLE(type) can't change (outside of the GC) - is it correct that st is never reassigned?

[niner]

My subsequent changes assume that the pointer generated by the expression `STABLE(type)` can't change (outside of the GC) - is it correct that `st` is never reassigned? You can view, comment on, or merge this pull

Unfortunately it isn't. Rebless changes the STABLE: https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/P6opaque.c#L1358

[nwc10]

My subsequent changes assume that the pointer generated by the expression STABLE(type) can't change (outside of the GC) - is it correct that st is never reassigned? You can view, comment on, or merge this pull
Unfortunately it isn't. Rebless changes the STABLE: https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/P6opaque.c#L1358

Hmm, interesting.

I think (stress think) that actually that means that the existing code in MVM_6model_set_debug_name is buggy, because it does this:

/* Set the debug name on a type. */
void MVM_6model_set_debug_name(MVMThreadContext *tc, MVMObject *type, MVMString *name) {
    char *orig_debug_name;
    uv_mutex_lock(&(tc->instance->mutex_free_at_safepoint));
    orig_debug_name = STABLE(type)->debug_name;
    if (orig_debug_name)
        MVM_free_at_safepoint(tc, orig_debug_name);
    STABLE(type)->debug_name = name && MVM_string_graphs(tc, name)
        ? MVM_string_utf8_encode_C_string(tc, name)
        : NULL;
    uv_mutex_unlock(&(tc->instance->mutex_free_at_safepoint));
}

and sure, it is holding the mutex mutex_free_at_safepoint while it does this, but that code in P6opaque is not, meaning that if both are executing in different threads, then the LVALUE expression STABLE(type)->debug_name might change.

Whereas my final version with this:

    void *old_debug_name
        = (void *) atomic_exchange_explicit(&STABLE(type)->debug_name, new_debug_name, memory_order_relaxed);

I think can't. Sure, it can't know which STABLE is is altering (the one before P6opaque's rebless or the one after it) but whichever it changes will remain self consistent (and no memory will leak or get double freed)

@jnthn - have we uncovered a race condition here?

[niner]

At least, whatever stable we read at this point, it will still point at allocated memory and writing to debug_name is safe. Considering how rebless and setdebugtypename are used, I'd be highly surprised if we ever ran into an issue there. setdebugtypename is usually done right after allocating a type object, i.e. no other thread will have seen it at this point.