Co to jest parametr Javy -XX: + UseMembar

Question

Widzę ten parametr we wszystkich rodzajach miejsc (forach itp.) I na wspólną odpowiedź, która pomaga bardzo współbieżnym serwerom. Mimo to nie mogę znaleźć oficjalnej dokumentacji ze słońca wyjaśniającej, co robi. Czy został dodany w Javie 6 lub czy istnieje w Javie 5?

(BTW, to dobre miejsce dla wielu parametrów hotspot VM jest this page)

Aktualizacja: Java 5 nie uruchamia się za pomocą tego parametru.

Answer 1

Aby zoptymalizować wydajność, JVM używa "pseudo-pamięciowej bariery" w kodzie, aby działać jako instrukcja fencing przy synchronizacji w wielu procesorach. Można powrócić do "prawdziwej" instrukcji zapory pamięciowej, ale może to mieć zauważalny (i zły) wpływ na wydajność.

Użycie numeru -XX:+UseMembar powoduje, że maszyna wirtualna powraca do instrukcji dotyczących prawdziwej bariery pamięci. Ten parametr pierwotnie miał istnieć tymczasowo jako mechanizm weryfikacji nowej logiki pseudobariery, ale okazało się, że nowy kod pseudo-paskowej bariery wprowadził pewne problemy z synchronizacją. Sądzę, że zostały one teraz naprawione, ale dopóki nie zostały, akceptowalnym sposobem obejścia tych problemów było użycie przywróconej flagi.

Błąd został wprowadzony w wersji 1.5 i sądzę, że flaga istnieje w wersjach 1.5 i 1.6.

Mam google-fu'ed to z różnych list dyskusyjnych i błędów JVM:

• http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6546278
• The obligatory Wikipedia link to memory barriers (fencing instructions)
• A classic post from Raymond Chen
• SO question on fencing

Answer 2

I don Zgadzam się z odpowiedzią od smaku masła. Ta strona http://www.md.pp.ru/~eu/jdk6options.html mówi, że ta flaga powoduje wyświetlanie barier pamięci, a następnie wątek zmienia swój stan (z RUNNABLE na WAITING lub na BLOCKED, na przykład).

Answer 3

Masłokwas wyjaśnia tylko połowę historii, chciałbym dodać więcej szczegółów do odpowiedzi kmatveev. Tak, opcja dotyczy zmian stanu wątków i (pseudo) barier pamięci używanych do zapewnienia, że ​​zmiana jest widoczna z innych wątków, w szczególności wątku VM. stany wątku stosowane w OpenJDK6 są następujące:

// _thread_new   : Just started, but not executed init. code yet (most likely still in OS init code) 
// _thread_in_native : In native code. This is a safepoint region, since all oops will be in jobject handles 
// _thread_in_vm  : Executing in the vm 
// _thread_in_Java  : Executing either interpreted or compiled Java code (or could be in a stub) 
... 
_thread_blocked   = 10, // blocked in vm 

bez opcji UseMembar w Linuksie, Hotspot wykorzystuje pamięć stronę serialize zamiast instrukcji bariera pamięci. Ilekroć dojdzie do przejścia stanu wątku, wątek zapisuje się w adresie pamięci na stronie serializacji pamięci za pomocą wskaźnika zmiennego. Gdy wątek VM musi sprawdzać aktualny stan wszystkich wątków, VM zmienia bity ochrony dla strony serializacji pamięci tylko do odczytu, a następnie odzyskuje ją do odczytu/zapisu, aby szeregować zmiany stanu. Bardziej szczegółowy mechanizm został wprowadzony w poniższej strony:

http://home.comcast.net/~pjbishop/Dave/Asymmetric-Dekker-Synchronization.txt

Answer 4

UseMembar określa, czy używać membar instrukcjami w ścisły sposób, zmuszając wszystkie działania pamięci, aby zakończyć przed kontynuowaniem.

Zasadniczo zatrzymuje opóźnione procesorowe optymalizacje obsługi pamięci od manipulowania z kodem.

Powoduje to spowolnienie działania i nie jest konieczne na nowoczesnych maszynach wirtualnych w przypadku większości kodów.

Od czasu do czasu pojawiają się problemy, w których kod powinien być bezpieczny dla wątków, ale nie jest z powodu braku instrukcji użycia memba. W takich przypadkach można włączyć tę opcję, aby taki kod działał bez przełączania się na pojedyncze wątki lub zakłócanie porządku kodu, aby zapobiec problemowi.

JVM jest na ogół dobra w wykrywaniu kodu, który może powodować problemy i albo wstawić blok membranżowy, albo zmienić kod JIT w celu zapewnienia czasu na zakończenie operacji pamięciowych. W rzeczywistości, w moim wyszukiwaniu w sieci na ten temat, znalazłem tylko jeden przykład błędu i został on naprawiony w najnowszych wersjach zarówno wersji Oracle, jak i OpenJRE hotspotu JVM.

Uwaga: w przypadku architektur ARM opcja ta jest domyślnie włączona, ponieważ alternatywne optymalizacje (znane jako optymalizacje psuedo-membar) nie zostały jeszcze zastosowane, a zatem mogą być bardzo błędne bez instrukcji dotyczących memów.