Both Azul and Mill were from-scratch hardware designs, unconstrained by prior literature. It’s interesting that we independently came up with similar solutions for GC barriers. Of course GC was critical for Azul as a Java machine, while it’s a minor feature for the more generalist Mill.
You are right that I answered about our read/write barrier. Those barriers are the only GC-specific part of the Mill. There is no specific support for a stack barrier, and none needed; the return sequence is controlled by the spiller, and suitably privileged software can alter that sequence, including altering the return point to a trap, using the API that is intended for debuggers. We are not GC experts, but be thought that was sufficient; we may learn better when we port a GC language 🙂