WIP: Refactor barrier implementation

[wks]

We recently added another write barrier, the SATBBarrier. Being another barrier based on the per-object unlog bit, it shares much code with the ObjectBarrier. We refactor the write barriers to improve code sharing and clean up unused code.

We introduce abstract base classes MMTkUnlogBitBarrierSetRuntime, MMTkUnlogBitBarrierSetAssembler, MMTkUnlogBitBarrierSetC1 and MMTkUnlogBitBarrierSetC2, which both ObjectBarrier and SATBBarrier derive from. Those base classes include common parts related to unlog bit handling, including the fast paths for checking if the unlog bit is set, and also the generic implementation for both the pre and the post barriers if applicable.

Runtime:

• Extracted a method for testing if the unlog bit is set for a given object.

Assembler:

• Extracted a method for emitting the unlog bit checking fast path.
• Extracted a method for generating both the pre and the post write barriers.
• Simplified the fast path to use fewer instructions and fewer scratch registers.
• Worked around an issue where the tmp1 and tmp2 temporary registers passed in from BarrierSetAssembler::store_at may overlap with dst.base() and dst_index(), respectively.
  • See https://bugs.openjdk.org/browse/JDK-8301371

C1:

• Make one "runtime stub" per runtime function, not one per pre/post/refload barrier. Those "runtime stubs" are now assembled by MMTkBarrierSetAssembler instead of by MMTkObjectBarrierSetAssembler or MMTkSATBBarrierSetAssembler. The intention is that all barriers can call those functions.
• Extracted a method for emitting the unlog bit checking fast path.
• Extracted a method for emitting both the pre and the post write barriers and their slow-path code stub.
• We no longer pass the slot and new_val to the runtime function in the slow path. Object-logging barriers only needs the obj argument for scanning its fields.
  • For this reason, we moved the C1 CodeStub for the pre/post barrier slow paths down from mmtkBarrierSetC1.hpp to mmtkUnlogBitBarrier.hpp (and unified the pre/post stub implementation) because it no longer needs the slot or new_val args, and is now specific to unlog bit barriers. If we introduce field-logging barriers, we will implement a different stub.
  • We also simplified the function signature of MMTkBarrierSetC1::object_reference_write_{pre,post} so that they only hvae the LIRAccess& access parameter. The slot and the new value can be obtained form the access argument, too, but we don't need them in object-logging barriers.
• The C1 SATBBarrier no longer needs code patching. The code patching was intended for barriers that loads the field in the fast path using LIR instructions, such as G1's SATB barrier. Our object-logging barrier scans the fields in runtime functions (mmtk_object_reference_write_pre), not using LIR instructions.

C2:

• Extracted a method for emitting the unlog bit checking fast path.
• Extracted a method for emitting both the pre and the post write barriers.

Misc:

• Removed the #define private public hack as we no longer need it.
• Removed unused macros, dead code and irrelevant comments.
• Changed the macro SOFT_REFERENCE_LOAD_BARRIER to a run-time flag mmtk_enable_reference_load_barrier settable by environment variable.

[k-sareen]

I think we should specify in the type that this is an object remembering barrier. LXR's field remembering barrier would also be an "unlog-bit" barrier but it's a different implementation.

[wks]

I think we should specify in the type that this is an object remembering barrier. LXR's field remembering barrier would also be an "unlog-bit" barrier but it's a different implementation.

I chose the name MMTkUnlogBitBarrierSet because the mmtk-core simply calls the metadata "unlog bit" or just "log bit". But I think it is worth emphasizing that it is "object unlog bit" or "object remembering barrier" rather than "field unlog bit" or "field remembering barrier".

But I hesitate to change the name now because "MMTkObjectUnlogBitBarrier" and "MMTkObjectRememberingBarrier" are both similar to the current "MMTkObjectBarrier", and the longer name feels like it should be a subclass rather than superclass. It is also a bit confusing because both "ObjectBarrier" and "SATBBarrier" are object-logging. I think we should rename "ObjectBarrier" to a more meaningful name, such as "object modification barrier". We can discuss this in a group.

[wks]

https://github.com/mmtk/mmtk-openjdk/actions/runs/17941785053/job/51021271068?pr=332
One test failed due to "free(): corrupted unsorted chunks". One possibility is that it was because malloc happened to mmap its memory within MMTk's memory range, and MMTk somehow corrupted their memory. We should quarantine the entire MMTk memory range to prevent this from happening. It is also possible if a heap object contains a pointer to a malloc object, and the heap object was collected prematurely. We'll need more evidence.

[wks]

Another failure https://github.com/mmtk/mmtk-openjdk/actions/runs/17941785053/job/51021285329?pr=332 was a "duplicated edges" error in SemiSpace. It was already reported. See #331