JVM garbage collection i architektura pamięci stronicowania

Będę twierdzić, że to nie jest tak duży problem, jak myślisz.

Aby upewnić się, że opisujemy to samo: kompletny zbiór wymaga, aby JVM poruszał się po wykresie obiektów w celu zidentyfikowania każdego osiągalnego obiektu; te, które pozostały, są śmieciami. W ten sposób dotknie każdej strony w stosie aplikacji, co spowoduje, że każda strona zostanie uszkodzona w pamięci, jeśli została zamieniona.

Myślę, że to nie jest problem z kilku powodów: Po pierwsze, ponieważ nowoczesne JVM używają kolektorów pokoleniowych, a większość obiektów nigdy nie wychodzi z młodych pokoleń, które są prawie zagwarantowane w zestawie rezydenta.

Po drugie, ponieważ obiekty, które poruszają się z młodego pokolenia, nadal są często dostępne, co ponownie oznacza, że powinny być w zestawie rezydenta. Jest to bardziej delikatny argument, a w rzeczywistości jest wiele przypadków, w których długotrwałe przedmioty nie zostaną dotknięte, z wyjątkiem GC (jeden z powodów, dla których nie wierzę w pamięci podręcznej).

Trzecim powodem (i może być więcej) jest to, że JVM (przynajmniej Słońce JVM) używa kolektora mark-sweep-compact. Tak więc po GC aktywne obiekty w stercie zajmują mniejszą liczbę stron, ponownie zwiększając RSS. Nawiasem mówiąc, jest to główny sterownik dla aplikacji Swing do jawnego wywołania systemu.gc () gdy są zminimalizowane: przez zagęszczenie sterty, jest mniej do zamiany, gdy zostaną ponownie zmaksymalizowane.

Również rozpoznaj tę stertę fragmentacja obiektów C / C++ może być ekstremalna, a Młode obiekty będą rozrzucane pomiędzy starsze, więc RSS musi być większy.

Nie jestem ekspertem, ale każdy rodzaj pokoleniowego odśmiecania powinien w pewnym stopniu pomóc. Strony, które są agresywnie wymieniane, prawdopodobnie zawierają starsze obiekty, a nie nowsze, więc gc naturalnie dotknie ich rzadziej.

Zadałbym też pytanie przeciwne: czy są jakieś uniksowe algorytmy stronicowania, które są świadome zbierania śmieci? Jeśli dana strona jest zapisywana w pamięci regularnie (jeśli nie często), to może nie jest to taka świetna kandydat przecież do wyrzucenia na rzecz większej ilości pamięci podręcznej dysku; -)

Systemy uniksowe (a zwłaszcza Linux) agresywnie odciągają pamięć, która nie była dotykana przez jakiś czas, i chociaż jest to dobre dla przeciętnej wyciekającej aplikacji c, zabija wydajność Java w sytuacjach napiętych z pamięcią.

Należy pamiętać, że zazwyczaj jest to ustawienie przestrajalne -- vm.na przykład Zamiana jądra Linuksa. Możesz przeczytać artykuł na blogu, który napisałem na ten temat jeśli chcesz uzyskać więcej szczegółowych informacji na temat swap-tuning NA Linux.

Czy są jakieś przywoławcze (świadome) algorytmy zbierania śmieci?

Algorytmy Garbage collection są zazwyczaj zaprojektowane dla bardzo szerokiej gamy możliwych programów jako wejścia i do pracy w wielu możliwych środowiskach; ich projekt musi to wziąć pod uwagę. Myślę, że byłoby to naprawdę trudne, aby" stronicowanie świadomy " algorytm gc, który był ogólnie użyteczny. Jeśli piszesz taki dla bardzo wyspecjalizowanego środowiska, w którym możesz zamknijcie sprawy, wtedy myślę, że macie duże szanse na dobry wynik.

W dzisiejszych czasach programy przywoławcze to naprawdę zły pomysł. Pamięć jest bardzo tania.

FWIW, jeśli jesteś uruchomiony na komputerze od producenta, który lubi ładować kilka razy ponad szanse na pamięć, Windows Vista ma predykcyjny algorytm stronicowania, który działa dość dobrze(być może jedyną rzeczą, że OS robi dobrze).