Problem polega na tym iż pamięć zajęta nie chce się usunąć normalnie (referencja = null)
Usuwa się jedynie wtedy gdy zminimalizuje okno -,-.
Czy ktoś mógłby mi powiedzieć ocb?
0
1
Runtime.gc() to tylko sugestia, JVM odśmieci sobie i tak wtedy kiedy chce.
0
Wibowit napisał(a):
Runtime.gc() to tylko sugestia, JVM odśmieci sobie i tak wtedy kiedy chce.
To dlaczego usuwa kiedy minimalizuje okno?
1
Dorzuć kolejną pojedynczą alokację po tej pętli, wtedy JVM wymusi uruchomienie GC by skutecznie przeprowadzić tę alokację.
...
bytes = null;//-.-
byte[] temp = new byte[megs * 1024 * 1024];
...
powinno pomóc.
1
Może system operacyjny podrzuca JVMowi jakąś głębszą sugestię? Albo to zwyczajnie szczegół implementacyjny JVM.
0
http://objectmix.com/java/73030-minimizing-jframe-releases-memory-why.html
Tu jest podobny problem ale nie czaje zbytnio odpowiedzi.
0
Odpowiadający napisał, że to może mieć związek z systemem operacyjnym, który zrzuca nieużywane strony pamięci na dysk twardy. Spróbuj czy bez minimalizowania aplikacji zajętość pamięci też będzie spadać.
0
Po pierwsze to co jest w Javie nazywane pamięcią free, nie ma odpowiednika w żadnym innym środowisku - w szczególności na środowisku C/C++ na którym bazuje kod wykonywalny JVM. Javowe free oznacza pamięć jakby "super wolną" - gotową do natychmiastowego przydziału pamięci na obiekt i natychmiastowego zwrotu referencji. Dzięki temu operacje na stercie w Javie są szybsze niż w C++, który nierzadko musi wołać do systemu o przydział nowego bloku.
Co do minimalizowania okna JFrame, to Java przydziela ze sterty bufory na podwójne buforowanie grafiki związanej z takim oknem. Wtedy nie ma potrzeby blokowania tej pamięci, więc jest ona zwracana. Stąd nagły wzrost ilości tej pamięci super-free.
0
Olamagato napisał(a):
Po pierwsze to co jest w Javie nazywane pamięcią free, nie ma odpowiednika w żadnym innym środowisku - w szczególności na środowisku C/C++ na którym bazuje kod wykonywalny JVM. Javowe free oznacza pamięć jakby "super wolną" - gotową do natychmiastowego przydziału pamięci na obiekt i natychmiastowego zwrotu referencji. Dzięki temu operacje na stercie w Javie są szybsze niż w C++, który nierzadko musi wołać do systemu o przydział nowego bloku.
Co do minimalizowania okna JFrame, to Java przydziela ze sterty bufory na podwójne buforowanie grafiki związanej z takim oknem. Wtedy nie ma potrzeby blokowania tej pamięci, więc jest ona zwracana. Stąd nagły wzrost ilości tej pamięci super-free.
Więc nic z tym nie zrobię?
0
A jak duża jest ta różnica? Jak zminimalizuję Operę to zajętość pamięci zmniejsza się o około 8 MB natychmiast, podobnie jak przywrócę to się o tyle zwiększa.
0
Polish napisał(a):
Więc nic z tym nie zrobię?
Tak. Nic z tym nie zrobisz, bo to brutalnie mówiąc powinieneś się odpimpkać od monitorowania pamięci. :)
Jeżeli Twój własny kod nie powoduje lawinowego przydziału pamięci, której nie chce zwrócić, to tym bardziej nie zrobi nic brzydkiego kod standardowych bibliotek javy.
A jeżeli cudzy kod powoduje zwrotkę pamięci, to nie jest to zmartwienie, i tym bardziej nie Twoje.
W C/C++ też nie masz de facto żadnej kontroli nad pamięcią bo różne programy mogą pamięć żądać/dostawać i zwalniać.
Jeżeli potrzebujesz naprawdę obrabiać wielkie porcje danych takich jak obrazy lub filmy, to wtedy i tak dostaniesz od Javy łącznie na pewno tyle ile jest w opcji -Xms (tyle Java sobie weźmie na starcie od systemu), a możesz mieć co najwyżej nadzieję na tyle ile jest w opcji -Xmx i ani bajta więcej. A wcale nie jest pewne, czy w danym momencie system będzie mógł tyle dać.
0
Wibowit napisał(a):
A jak duża jest ta różnica? Jak zminimalizuję Operę to zajętość pamięci zmniejsza się o około 8 MB natychmiast, podobnie jak przywrócę to się o tyle zwiększa.
Mi sie zwalnia na raz jakieś 100M a poźniej wraca ale np co sekunde dodaje 3 mb i tak do 100.
Dodam jeszcze:
If I open multiple "large"(~100mb)image stacks and then close them, the
memory monitor will show a decrease in memory (after a variable lag) but the
Windows Task Manager does not show any decrease in Mem Usage for the Java
VM, even after an overnight wait. The Virtual Memory size stays at the
largest memory ever used during a single session. The "Java VM" Memory
Usage will decline if other programs are loaded. But when new images are
loaded, there can be a big lag in ImageJ while "empty" memory is paged back in.
0
Task manager nigdy nie pokaże zwrotki pamięci ponieważ JVM nigdy nie oddaje raz otrzymanej pamięci. Oddaje hurtem dopiero wtedy gdy sama robi won z systemu, albo zostanie skillowana.
To co dostają aplikacje Javy, to pamięć którą ona sama dostała od systemu. Jeżeli aplikacja tę pamięć zwróci, to nadal dysponuje nią JVM, a dla systemu nic się nie zmienia. Dla odmiany manager sterty z C lub C++ oddaje zwolnioną pamięć z powrotem do systemu, więc TM zawsze będzie odzwierciedlał aktualny stan. JVM też jest z punktu widzenia systemu programem w C/C++, ale u niego funkcja free() jest po prostu bezrobotna. Od czasu do czasu odpalana jest tylko malloc(), a i to tylko wtedy kiedy ilość pamięci w -Xmx jest większa od -Xms, a aplikacje Javy dojdą do granicy aktualnego przydziału.
1
JVM serwerowa raz zajmuje pamięć, a potem jej nie oddaje, taką ma zasadę. JVM kliencka oddaje po jakimś czasie, zależnie od ustawień "min/max heap free ratio".
64-bitowe JRE na Windowsa ma wersję tylko serwerową.
32-bitowy JRE na Windowsa ma tylko kliencką. Ale JDK ma również serwerową - więc jeśli odpalasz z JDK (np przez Ecipse) to odpalisz na serwerowej.
0
Hmm czyli powinienem się skupić na memory use pobieranego z Runtime?
Co do tworzenia nowych obiektów to staram się jak najmniej ich tworzyć :)
Jestem pewnien że problemem są buffered image.
0
Moim zdaniem tak. Podejrzenie o kiepską pracę z pamięcią BufferedImage jest trochę uzasadnione. Ta klasa, to taka hybryda, która próbuje robić wszystko. Pokombinuj trochę z poziomem żądanej akceleracji (od 0 - brak do 1 - ile się da), czyli i korzystaniem z buforów w pamięci GPU (a to się wiąże z ich synchronizacją z głównej pamięci = sterty). Obrabiając grafikę staram się ją wyłączać, a włączać głównie przed pacnięcięm na ekran. Czy jest to najlepsze rozwiązanie - nie jestem pewien, ale nic lepszego nie wymyśliłem - full HD ładuje mi w 30 FPS na ekran, a taki poziom jak na razie mnie zadowala.
0
@PolishCivil Miełem podobny problem, do tego przy kompilacji włączałem Java VisualVM i sprawdzałem co mi powoduje Przepełnienie bufora.