Warum schlägt das nichtflüchtige „Huckepack“ in dieser speziellen, auf Unsafe basierenden Ringpufferimplementierung fehl ⇐ Java

[Anonymous]

Ich arbeite an einer Messaging-Bibliothek mit geringer Latenz und versuche, einen „wartefreien“ Ringpuffer zu implementieren. Ich versuche, das "Piggybacking"-Prinzip (passiert vor der Konsistenz) zu nutzen, um den Overhead von flüchtigen Schreibvorgängen für jedes Element zu vermeiden.
Gemäß JSR-133 (Java Memory Model) stellt ein Schreibvorgang in eine flüchtige-Variable eine passiert-bevor-Beziehung mit nachfolgenden Lesevorgängen derselben Variablen her. Wenn ich theoretisch in ein nichtflüchtiges Array-Element schreibe und dann eine flüchtige Sequenzbarriere aktualisiere, sollte der Verbraucher, der die Barriere liest, das aktualisierte Array-Element sehen.
Das Setup: Ich verwende sun.misc.Unsafe, um putOrderedLong (Store-Store-Barriere) für die Datenelemente und einen flüchtigen Long für den Sequenzcursor auszuführen. Das Problem: Bei starker Konkurrenz auf einer x86_64-Architektur (wo die meisten Ladungen/Speicher bereits bestellt sind) funktioniert dies in 99,9 % der Fälle. Beim Testen auf ARM64 (Graviton3) sehe ich jedoch gelegentlich Lesevorgänge für „veraltete Daten“, bei denen der Verbraucher den aktualisierten tailCursor, aber den vorherigen Wert im Puffer sieht. Meine Fragen:

• Da storeFence() explizit aufgerufen wird, sollte das nichtflüchtige putLong nicht für jeden Thread sichtbar sein, der den aktualisierten tailCursor über eine flüchtige Last beobachtet?
• Garantiert das JMM die Sichtbarkeit für nichtflüchtige Speicher, wenn das „Huckepack“ über erfolgt setOrdered (lazySet) anstelle eines standardmäßigen flüchtigen-Schreibvorgangs?
• Gibt es eine spezifische Interaktion zwischen dem schwachen Speichermodell von ARM und den LoadLoad-Barrieren der JVM, die dazu führen könnte, dass der Verbraucher die gelesenen Daten bevor den Cursor liest?