Phase3: Add write barrier to Cell and some bytecodes

[xFrednet]

The first commit is a copy pasta from #34 and will be removed once it's merged

This PR covers all Py_CHECKWRITE in bytecodes.c and cellobject.c. The bytecode instructions probably still need more work for local references, but that can easily be done in a followup PR

[xFrednet]

I mentioned in earlier this week that we're only allowed to run the WB if the referenced object actually changes. I tried to document the reason here.

While writing, I also noticed that this case isn't handled in the "Pseudo code for write-barrier" in the paper we submitted to PLDI25. It will simply require a new if statement in writeBarrier(src, oldtgt, tgt) like this:

if oldtgt is tgt:
  return

or probably better

if not oldtgt is tgt:
  addReference(src, tgt)
  removeReference(src, oldtgt)

cc: @TobiasWrigstad @mjp41

---

_{EDIT: I also created a reminder PR in the paper repo fxpl/pyrona#12}

[TobiasWrigstad]

Excellent @xFrednet!

If I understand correctly, the problem is due to double capturing of a borrowed ref to a bridge object, which is always an error except in the very special case when the double capturing happens by the same field. This program produces the error:

r1 = Region() # borrowed ref to region
r2 = Region() # borrowed ref to region
class Obj: pass
r1.obj = Obj()
r1.obj.f = r2 # o captures r2, but r2 remains a borrowed ref because no move
r1.obj.f = r2 # 2nd attempt at storing r2 in o.f fails (but does not trigger invariant) because r2 is already captured

If we ran REMOVEREFERENCE before ADDREFERENCE this would work, but we don't do that (nor should we).

If my understanding is correct, I am on the fence if we should actually fix it because it is almost certainly an error in the program (although I am sure Python people would like it to work).

If we do want to fix it, I suggest the fix happens as an extra check after add_to_region detects a failure due to r2 not being free. Otherwise, we have one more branch in the barrier for a case that is super rare. This penalises this very unlikely case instead of adding an extra check in the barrier top-level.

[xFrednet]

This should be ready for review. The first commit includes some changes from #34 to hopefully prevent merge conflicts later

[xFrednet]

I just rebased to get the Py_TPFLAGS_REGION_AWARE flag

[mjp41]

LGTM, my main concern is if trigger remove reference before removing the edge from the heap could be a problem. Could we end up with remove reference triggering a desctructor, and then the invariant not holding? Are there worse things that could happen.

[mjp41]

Could there be any issues here that the edge still exists when the region remove reference occurs?

[xFrednet]

I don't think so. The invariant will only run when the bytecode is done executing. If a different thread has access to the Cell and gains access to the object between the Py_REGIONCHANGEREFERENCE and PyCell_SET we have a different problem on our hands.

I believe this should be safe, as long as region remove reference only decreases the LRC and doesn't try to verify anything

[mjp41]

LGTM. One very minor thing.

[mjp41]

Suggested change

	Py_REGIONREMOVEREFERENCE(op, op->ob_ref);
	Py_CLEAR(op->ob_ref);
	Py_CLEAR_OBJECT_FIELD(op, op->ob_ref);

[xFrednet]

I only rebased previously, now your comment should be addressed, and I also fixed a small issue with the macro and where it got it's type from.

[mjp41]

LGTM