Java Heap Hard Drive

Question

Pracuję nad programem Java, który generuje fraktalne orbity od dłuższego czasu. Podobnie jak zdjęcia, im większy obraz, tym lepszy będzie on po zmniejszeniu. Program wykorzystuje tablicę obiektów 2D (punkt), do której zapisywane jest obliczenie wartości punktu. Oznacza to, że punkt jest zapisywany w to odpowiednia wartość, tj .:

Point p = new Point(25,30); 
histogram[25][30] = p; 

Oczywiście, jest to edycja dla prostoty. Mógłbym po prostu zapisać wartości punktowe w pliku CSV i później zastosować je do rastra, ale użycie podobnych metod przyniosło niepożądane rezultaty. Próbowałem przez jakiś czas, ponieważ cieszyłem się z możliwości tworzenia większych obrazów z przestrzenią uwolnioną przez brak tej tablicy. To po prostu nie zadziała. Dla jasności chciałbym dodać, że obiekt Point przechowuje również dane kolorów.

Kolejnym problemem jest WriteableRaster, który będzie miał te same wymiary co tablica. W połączeniu te dwie zajmują dużo pamięci. Przyjąłem to, próbując zmienić sposób, w jaki zostało to zrobione kilka razy, z których każda miała niższą jakość.

Po próbie optymalizacji pamięci i czasu, doszedłem do wniosku, że jestem naprawdę ograniczony przez pamięć RAM. To jest to, co chciałbym zmienić. Jestem świadomy przełącznika -Xmx (ustawiony na 10 GB). Czy istnieje sposób użycia pamięci wirtualnej systemu Windows do przechowywania rastra i/lub tablicy? Doskonale zdaję sobie sprawę ze znaczącego wyniku, jaki spowoduje ten efekt, ale zamiast obniżać jakość, tak naprawdę nie wydaje się, by był duży wybór.

Answer 1

OS ma już miejsca na dysku do pamięci RAM dla Ciebie i każdego procesu oczywiście - nie potrzebne magii. Będzie to bardziej katastrofa wydajności niż myślisz; będzie tak wolno, że skutecznie nie działa.

Szukasz plików mapowanych w pamięci? http://docs.oracle.com/javase/6/docs/api/java/nio/MappedByteBuffer.html

Jeśli tak naprawdę należy zrobić w pamięci, założę się, że można znacznie obniżyć zużycie pamięci przy odrobinie optymalizacji. Na przykład twój obiekt Point jest głównie narzutem, a nie danymi. Zliczaj bajty potrzebne do odniesienia, a następnie do nakładu Object w porównaniu z dwoma ints.

Można zmniejszyć obciążenie do minimum za pomocą dwóch dużych równoległych macierzy int dla współrzędnych X i Y. Oczywiście musisz to enkapsulować, aby uzyskać dostęp w swoim kodzie. Ale może zmniejszyć o połowę zużycie pamięci dla tej struktury danych. Miliony mniej obiektów również przyspiesza przebiegi GC.

Zamiast umieszczać WritableRaster w pamięci, należy rozważyć zapisanie pliku obrazu w prostym formacie obrazu bezpośrednio, ty sam. BMP może być bardzo prosty. A może przy użyciu zewnętrznego narzędzia, aby skutecznie go przekonwertować.

Wypróbuj -XX:+UseCompressedOops, aby zmniejszyć również obciążenie obiektu. Wypróbuj także -XX:NewRatio=20 lub nowszą wersję, aby JVM zarezerwował prawie całą swoją stertę dla długożyciowych obiektów. Dzięki temu możesz użyć więcej sterty.

Answer 2

Nie zaleca się konfigurowania parametrów pamięci maszyny JVM (Xmx) w celu przydzielenia systemu operacyjnego z pamięci wymiany. najwyraźniej mechanizm zbierania śmieci musi mieć losowy dostęp do pamięci sterty, a jeśli nie, program będzie trashował przez długi czas i prawdopodobnie zablokuje się. sprawdź odpowiedzi udzielonej już do mojego zapytania (ostatni akapit):

does large value for -Xmx postpone Garbage Collection