jak w Netbeans zwiększyć rozmiar stosu lub zwalniać pamięć po wywołanej rekurencyjnie funkcji

0

testuje algorytm sortujący z dużą ilością wywołań rekurencyjnych używam Netbeans pod linuxem

mam błąd Exception in thread "main" java.lang.StackOverflowError

w pliku netbeans.conff ustawiłem zgodnie z sugestią http://stackoverflow.com/questions/15460779/how-to-increase-the-java-heap-size-in-netbeans

netbeans_default_options="-J-client -J-Xss2m -J-Xms512m -J-Xmx1024m -J-XX:PermSize=256m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Dsun.java2d.dpiaware=true -J-Dsun.zip.disableMemoryMapping=true"

nie pomaga

jednak jest sytuacja że rekurencyjna funkcja raz się wykonuje poprawnie sortuje wyświetla wynik
program podaje czas jej wykonania

jednak kolejne wywołania jej w tej samej funkcji main powodują ten błąd

wywołuję ją kilka razy w tej samej main by uzyskać uśredniony czas wykonania algorytmu ( robię to bo czas może być różny w zależności od zajęcia prcesora itp )dla tych samych danych w losowo uzupełnionej tablicy posiadającej 100000 elementów, dla 10000 elementów działał bez zarzutu

może w javie w funkcji main po każdym wykonaniu funkcji sortującej ( z dużą ilością rekurencyjnych wywołań) trzeba zwolnić jakoś pamięć ???

2
  1. Do kontrolowania rozmiaru stosu służy -Xss. -Xms i -Xmx służą do kontrolowania rozmiaru sterty.
  2. Zmieniasz ustawienia JVMki na której odpalany jest NetBeans zamiast zmieniać ustawienia projektu, by twój projekt był odpalany z konkretnymi ustawieniami. Ustawienia projektu są Properties (klikasz PPM na projekcie) -> Run -> VM Options.
  3. Algorytm rozsadzający stos jest bez sensu. Pamiętaj, że każdy wątek ma taki sam rozmiar stosu. Jeżeli ustawisz np stos 1 giga to nie odpalisz programu na maszynie 32-bitowej, bo JVMka odpala wiele wątków dla siebie i zabraknie przestrzeni adresowej.
  4. Miejsce na stosie jest zwalniane po wyjściu z funkcji.
  5. Upewnij się, że wiesz co to stos, a co to sterta.
0

tak wstawiałem opcje do propertis>run>vm options

to testowe sprawdzenie pesymistycznego zbioru danych dla których algorytm praktycznie idzie w dół z rekurencją do n poziomu takie wymogi testu

to też mój błąd bo tablice ma uporządkowaną po pierwszym przejściu funkcji i wtedy jest przypadek pesymistyczny dla reszty wywołań to przeoczyłem przez roztargniennie i to tłumaczy
pierwsze wywołanie patrz szybkie sortowanie z wyborem lewego skrajnego elementu :)

2

Zrobiłem prostą aplikację do badania głębokości stosu:

package main;

public class Main {

    public static void main(String[] args) {
        new Main().recursion(0);
    }
    
    void recursion(int i) {
        try {
            recursion(i + 1);
        } catch (StackOverflowError soe) {
            System.out.println(i);
        }
    }
    
}

Z domyślnymi ustawieniami wynik jest np taki:

run:
16593
BUILD SUCCESSFUL (total time: 0 seconds)

Gdy dam -Xss10m w Properties -> Run -> VM Options to wynik jest np taki:

run:
389099
BUILD SUCCESSFUL (total time: 0 seconds)
0

dzięki :) za podpowiedź poskutkowało wykonał dla 1000000 elementów wariant pesymistyczny trochę to trwało

1 użytkowników online, w tym zalogowanych: 0, gości: 1