nije bas tako, nema veze sa primerom iz paskala, ti kada pokrenes
virtualnu masinu ti toj masini alociras neku kolicinu rama i ona ne moze
da "kasnije" uzme vise od toga, tako da ti kad startas jvm ti mu sa -Xms
setujes inicijalni heap, -Xmx maximalni heap (dakle on ce da uzima od
os-a izmedju Xms i Xmx po potrebi) -Xss max thread stack ..
startuj
java -XshowSettings:all
i on ce ti pokaze koje sve propertie vm ima, i sa
java -X
ces da dobijes sve te X parametre (za stek, heap i slicno)
takodje pogledaj -XX* opcije
to je normalno ponasanje, imas virtualnu masinu - podesavas kako hoces
ta masina da se ponasa, zasto max heap nije == max ram hosta, zato sto
garbage collection radi razlicito u odnosu na to koliko heap-a imas
prazno ... ako ti je 50+% heap-a prazno, sto bi uopste trosio vreme na gc :)
sto se "nikada nije imao potrebe da petlja išta eksplicitno sa GC-om" ..
znam ja mnogo "seniora" koji nisu, ali to samo zavisi sta prave i kako
.. ako naguras sve one ogromne frameworke oni u sebi imaju explicitno
drndanje sa gc-om, takodje serverske aplikacije uglavnom ne
startuju/testiraju/podesavaju ti developeri nego sysadmini koji vrlo
dobro znaju da to ne moze tako kako mali perica zamislja inace imas
uzasne pikove svaki put kad se okine gc, tako da imas fore tipa da kazes
da ti GC radi NONSTOP 2% vremena ili 5% vremena ili ako su developeri
losiji i nemaju ideju kako radi java pa kreiraju i unistavaju objekte
non stop 10% vremena ... tako nemas pikove gc radi non stop i app
performanse su vrlo "predictable" ... imas odlican tekst recimo ovde:
http://blog.sokolenko.me/2014/11/javavm-options-production.html takodje
procitaj i komentare ispod posta
sto se c++ dela tice, naravno, tako radi i C i bilo koji drugi nativni
jezik koji ima malloc/new/free/delete .. ideja GC-a u "modernim"
jezicima je da je sve vise "programera pajsera" koji ne umeju da urade
free/delete pa to umesto njih radi GC ... u tom slucaju moras da imas
zauzeto "vise rama" nego sto ti treba zato sto gc-u treba neko vreme da
oslobodi visak .. sa min/max heap ti podesavas virtualnoj masini granice
u kojima hoces da radi .. nista drugacije se ne ponasaju ni "nativni
jezici sa gc-om"
> Nema tu malloc ko u C-u da napraviš niz čija se veličina određuje u
fazi izvršavanja,
> nego se u fazi prevođenja određuje veličinu niza koja piše u sorsu
kao konstanta.
> Dakle, ako stavim mali niz, onda neće moći da radi sa veliim
podacima, a ako stavim
> veliki, zauzimaće mnogo RAM-a čak i ako korisnik radi nešto što
zahteva mali deo tog
> niza. Znam da je savremeni Pascal dobio zamenu za malloc/free.
jok, omasio si skroz, napravis dinamicki niz u javi i on zauzima tacno
toliko mesta koliko treba, cak stavise, napravis, vektor, mapu ili
stagod, i automatski alocira onoliko rama koliko treba kada dodas
objekat u mapu, vektor... i on taj ram alocira sa nekim svojim
"jvm_malloc na primer" sa svog heap-a od jvm-a, pa ako nema dovoljno
rama na heap-u da to odradi on sistemskim malloc poveca heap do max heapa...
fora je u tome sto kada obrises objekat iz vektora, ili kada obrises ceo
vektor ta memorije se ne vrati automatski na heap dok je garbage
collector ne vrati.. nemas mogucnost da ti kazes delete() ili free() i
vratis to nego mora dereferenciras i cekas da gc to vrati "sam". ...
tako da u poredjenju sa C++, sve radi prilicno isto, jedino sto imas
samo malloc() i new, nemas free() i delete, free i delete se pozivaju
"automagicno" :D