Instruction-cache invalidation for AArch64 self-modifying code after DC CVAC

Instruction-cache invalidation for AArch64 self-modifying code after DC CVAC

The goal is to determine whether an AArch64 JIT or runtime that writes executable memory can rely on DC CVAC to the Point of Coherency plus a Data Synchronization Barrier alone, or whether an explicit instruction-cache invalidation and Instruction Synchronization Barrier are required before fetching the new instructions.

The architecture describes clean-to-PoC, DSB, instruction-cache invalidate, then ISB, but marks whether a fetch can observe a stale line after only the data-cache clean as implementation-defined. Some cores snoop instruction fetches against recent data writes; others do not. Behavior can differ between Cortex-A implementations and custom AArch64 cores, so identical generated code may run correctly on one silicon revision and silently execute stale instructions on another.

Assumptions: AArch64 execution state, coherent system cache, and runtime-generated code rather than a static image. The unresolved boundary is whether invalidation is mandatory for a given core or optional because of implementation-specific snooping.

Which AArch64 cores require explicit instruction-cache invalidation after DC CVAC and DSB before executing newly written code? Is the ISB alone sufficient after a complete data-cache clean, or must software always invalidate by address or all? What mechanism should portable runtime code use to declare this dependency without targeting a specific microarchitecture?