[FrancMauer]

Mireczki mam # java OutOfMemory i nie wiem gdzie siedzi

for (int i = 1000; i < 10001; i += 1000) {
 MatrixGraph mgr = new MatrixGraph(i, 0.5);
 ListGraph lgr = mgr.toListGraph();
 DFS.dfs(lgr, start);
 System.out.print(DFS.res + " ");
 }

przy 8 kroku wywala się Out Of memory. klasy:
MatrixGraph
DFS
ListGraph
#programowanie

[villager]

@FrancMauer: problemem jest wirus HIV. mam nadzieję że pomogłem

[uuid]

@FrancMauer: ten kod alokuje tablice o wielkościach 1MB, 2MB ... 64MB, to daje sumę ~160MB. Dodatkowo tworzysz adjacencyList które zajmują około połowę tego co adjacencyMatrix, czyli ~80MB. Mamy już 240MB a standardowa ilość pamięci w javie to 256MB. Doliczmy do tego jakiś narzut i mamy koniec pamięci.

[uuid]

@FrancMauer: możesz spróbować wrzucić System.gc() na początku pętli, wtedy jest szansa, że garbage collector usunie poprzednio stworzone obiekty i zrobi miejsce na nowe.

[frax]

@FrancMauer: Wydaje mi się, że @uuid trochę źle liczy, bo te stare grafy powinny się odśmiecać (ale może nie, nie znam Javy), ale za to nie dolicza wielkości adjacencyList, które trzyma inty zamiast booli - czyli 4 lub 8 razy więcej miejsca, o ile Java nie trzyma tego w ogóle jako referencji (wtedy jeszcze więcej). Dodatkowo musisz policzyć, że DFS może się zagłębiać na te parę tys. wywołań, co też swoje

[FrancMauer]

Dodatkowo musisz policzyć, że DFS może się zagłębiać na te parę tys. wywołań, co też swoje zajmuje. Ogólnie - w cholerę miejsca na to potrzebujesz.

@frax: wiem, myślałem, ze coś źle zrobiłem, miałem nadzieje że ktoś znajdzie błąd :)

[frax]

@FrancMauer: Nie powiem, żebym to dokładnie czytał, ale nic się w oczy nie rzuca, a jeśli wywala się przy ósmym obrocie, no to raczej generalnie działa. Możesz spróbować z tym System.gc(), może pomoże. Możesz też zwiększyć dopuszczalną wielkość sterty opcją -Xmx jvm-a, np. -Xmx2048m ustawi maksymalną pamięć na 2048 MB (nie wiem, ile jest domyślnie, i to chyba może zależeć od ilości RAMu w twojej maszynie).

[FrancMauer]

@frax: próbowałem z System.gc() ale nie rozwiązuje problemu.

[xwlk]

@FrancMauer: ustaw -Xmx2048m (2GB pamięci dla javy) lub więcej jeśli masz dużo wolnego RAMu - spróbuj z różnymi wariantami

[FrancMauer]

@xwlk: @frax: Metoda "Daj większy mlotek?"

[rancosster]

@FrancMauer: Zawsze mozesz zamiast Boolean uzyc tablicy z typem byte. Jeszcze jedno mi sie rzucilo w oczy liczba mnoga od Vertex to Vertices, a nie Vertexes, tak samo jak Matrix i Matrices ( ͡° ͜ʖ ͡°)

[Szab]

@FrancMauer: Wydaje mi się, że @uuid trochę źle liczy, bo te stare grafy powinny się odśmiecać (ale może nie, nie znam Javy)

@frax: Odśmiecanie działa raz na jakiś czas i ciężko przewidzieć kiedy zostanie wywołane :P

[frax]

@Szab: No tak, ale spodziewałbym się wywołania go, kiedy zaczyna brakować pamięci, zanim się rzuci wyjątkiem... Chociaż może samo odśmiecanie wymaga jej już za dużo :P

[FrancMauer]

@frax: Właśnie algorytmy gc nie są takie intuicyjne do końca, dlatego pytam czy może przesadziłem z danymi

[NikczemnyPan]

@FrancMauer: nulluj na koniec pętli:

MatrixGraph mgr = null;
ListGraph lgr = null;

Podpowiesz zbieraczowi smieci, że może to zabrać zamiast sam do tego dochodzić.

Kiedyś miałem taki kawałek:

for(Obiekt o : kolekcja ){
 String s = new String();
 wynik = operacjaNaObiekcie( o );
 operacjcjaNaStringu( s, wynik );

 // s = null;
}

I też mi leciało out of memory, gc nie nadążał odśmiecać. Problem zniknął gdy nullowałem stringa przed zakończeniem

[NikczemnyPan]

@FrancMauer: przejrzałem pobieżnie te klasy. z metod toString wyciągnoł bym tego stringbulidera do konstruktora i nie tworzył go za każdym razem tylko w metodzie toString pierwsza linika to stringbuilder.setLenght( 0 )

dynamiczne listy, też jak dasz radę to przenieś do konstruktora i czyść przed każdym użyciem