🚀 go-pugleaf

W dniu poniedziałek, 12 stycznia 2015 20:46:28 UTC+1 użytkownik Arivald napisał:
> On 2015-01-12 19:23, obi wan firthe kenobi wrote:
> > jesli pisze sie aplikacje ktore dzialają
> > w 'systemie ramkowym' (by tak to nazwac)
> > np 50 fps, to przydaloby sie zeby te
> > kosztowniejsze operacje garbage collectora
> > nie wykonywaly sie jakos losowo tylko by np mozna wywolywac je pod koniec bloku kodu dla danej
> > ramki (i by zablokowac je wczesniej tj dla czasu
> >   ramki)
> >
> > czy da sie cos takiego zrobic w javie? (tj kontrolowac recznie kiedy to ma sie wykonac)?
> >
> 
> System.gc(), ale nie ma gwarancji że to coś robi w danej implementacji 
> JVM. Ani gwarancji ile czasu zajmie.
> 
> Po za tym niektóre JVM mogą mieć więcej metod do kontroli GC. W 
> szczególności nowoczesne JVM mogą robić GC w osobnym wątku, mogą robić 
> przyrostowo (określoną ilość do limitu w danym cyklu), mogą robić coś 
> jeszcze bardziej wymyślnego.
> 
> 
> Po drugie tak koduj żeby ograniczyć alokacje pamięci. Czyli np. ponowne 
> wykorzystanie obiektów, unikanie ich tworzenia, etc. Temat rzeka.
> Wyrzucenie części operacji do wątków też czasem pomaga.
> 
> -- 
> Arivald

znalazlem taki cytat 

"If you use direct memory buffers, the JVM doesn't run the GC for you even if you are running low on direct memory." 

czy to zanaczy ze przy uzywaniu tych direct memory buffers gc jest wylaczany? (chodzi o mi ogolnie o unikniecie tych wiadomych niedeterministycznych 'zaciec', rozumiem ze 
java tego nie umozliwia? a moglaby zaiste,
potrzebny bylby po prostu sposob oznaczenia bloku kodu - w tym bloku nie wywoluj zadnego
spowalniajacego kolekcjonowania