🚀 go-pugleaf

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

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

+ inna komenda tu wywolaj sprzatanie (to tez by sie przydalo)

inna sprawa jest w javie sposob na wylczenie bound checking dla pewnych blokow kodu?

On 2015-01-12 21:39, obi wan firthe kenobi wrote:
> + inna komenda tu wywolaj sprzatanie (to tez by sie przydalo)

A przeczytałeś w ogóle co robi System.gc()?

Tu masz linka, jeśli używanie Google sprawia Ci kłopot:
http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#gc%28%29

RTM

-- 
Arivald

W dniu wtorek, 13 stycznia 2015 00:41:00 UTC+1 użytkownik Arivald napisał:
> On 2015-01-12 21:39, obi wan firthe kenobi wrote:
> > + inna komenda tu wywolaj sprzatanie (to tez by sie przydalo)
> 
> A przeczytałeś w ogóle co robi System.gc()?
> 
> Tu masz linka, jeśli używanie Google sprawia Ci kłopot:
> http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#gc%28%29
> 
> RTM
> 
to nie jest odpowiedz na pytanie, wroc do tekstu posta 
jesli masz trudnosci z rozumieniem pytan,
posiadasz widoczne
 

W dniu 12.01.2015 o 19:23, obi wan firthe kenobi pisze:
> 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)?
>

Nie da się tego tak zrobić że oznaczysz (Tutaj nie wykonujemy GC)

Da się natomiast tym odpowiednio sterować tylko temat jest bardzo 
głęboki a ty podałeś bardzo mało danych

Pozdrawiam

W dniu piątek, 16 stycznia 2015 01:32:19 UTC+1 użytkownik J-23 napisał:
> W dniu 12.01.2015 o 19:23, obi wan firthe kenobi pisze:
> > 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)?
> >
> 
> Nie da się tego tak zrobić że oznaczysz (Tutaj nie wykonujemy GC)
> 
> Da się natomiast tym odpowiednio sterować tylko temat jest bardzo 
> głęboki a ty podałeś bardzo mało danych
> 
to jest w sumie odpowiedz + tez mi sie tak zdawalo, wnikac w temat nie mam czasu

W dniu 16.01.2015 o 19:18, obi wan firthe kenobi pisze:
> W dniu piątek, 16 stycznia 2015 01:32:19 UTC+1 użytkownik J-23 napisał:
>> W dniu 12.01.2015 o 19:23, obi wan firthe kenobi pisze:
>>> 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)?
>>>
>>
>> Nie da się tego tak zrobić że oznaczysz (Tutaj nie wykonujemy GC)
>>
>> Da się natomiast tym odpowiednio sterować tylko temat jest bardzo
>> głęboki a ty podałeś bardzo mało danych
>>
> to jest w sumie odpowiedz + tez mi sie tak zdawalo, wnikac w temat nie mam czasu
>


Ale zauważ że jak podczas przetwarzania grafiki ci się włacza GC a ty 
tego nie chcesz :) to jest coś źle zaprojektowane

Pozdrawiam

On 2015-01-12 19:23, obi wan firthe kenobi wrote:
> czy da sie cos takiego zrobic w javie?

Niekoniecznie w czystej javie, ale blisko:

http://en.wikipedia.org/wiki/Real_time_Java

W dniu sobota, 17 stycznia 2015 10:33:33 UTC+1 użytkownik Sebastian Biały napisał:
> On 2015-01-12 19:23, obi wan firthe kenobi wrote:
> > czy da sie cos takiego zrobic w javie?
> 
> Niekoniecznie w czystej javie, ale blisko:
> 
> http://en.wikipedia.org/wiki/Real_time_Java

a kojarzysz moze dokladniej jak tam sie to robi? (nie mam czasu sie wglebiac, nie pisze w javie, ale
byuloby to ciekawe) - jak nie nie ma sprawy

W dniu sobota, 17 stycznia 2015 00:43:56 UTC+1 użytkownik J-23 napisał:
> W dniu 16.01.2015 o 19:18, obi wan firthe kenobi pisze:
> > W dniu piątek, 16 stycznia 2015 01:32:19 UTC+1 użytkownik J-23 napisał:
> >> W dniu 12.01.2015 o 19:23, obi wan firthe kenobi pisze:
> >>> 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)?
> >>>
> >>
> >> Nie da się tego tak zrobić że oznaczysz (Tutaj nie wykonujemy GC)
> >>
> >> Da się natomiast tym odpowiednio sterować tylko temat jest bardzo
> >> głęboki a ty podałeś bardzo mało danych
> >>
> > to jest w sumie odpowiedz + tez mi sie tak zdawalo, wnikac w temat nie mam czasu
> >
> 
> 
> Ale zauważ że jak podczas przetwarzania grafiki ci się włacza GC a ty 
> tego nie chcesz :) to jest coś źle zaprojektowane
> 
normalnie w takiej aplikacji jaka mam na mysli generuje sie sie ramke (i wtedy gc nie powinien sie wlaczac bo bylaby kaszana) po czym wywoluje sie sleep() - ten sleep nie trwa dlugo i nie wiem czy cos takiego jest w javie - ale na przyklad wtwdy gc moglby robic sobie kawalki tej roboty

W dniu 20.01.2015 o 15:23, obi wan firthe kenobi pisze:
> W dniu sobota, 17 stycznia 2015 00:43:56 UTC+1 użytkownik J-23 napisał:
>> W dniu 16.01.2015 o 19:18, obi wan firthe kenobi pisze:
>>> W dniu piątek, 16 stycznia 2015 01:32:19 UTC+1 użytkownik J-23 napisał:
>>>> W dniu 12.01.2015 o 19:23, obi wan firthe kenobi pisze:
>>>>> 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)?
>>>>>
>>>>
>>>> Nie da się tego tak zrobić że oznaczysz (Tutaj nie wykonujemy GC)
>>>>
>>>> Da się natomiast tym odpowiednio sterować tylko temat jest bardzo
>>>> głęboki a ty podałeś bardzo mało danych
>>>>
>>> to jest w sumie odpowiedz + tez mi sie tak zdawalo, wnikac w temat nie mam czasu
>>>
>>
>>
>> Ale zauważ że jak podczas przetwarzania grafiki ci się włacza GC a ty
>> tego nie chcesz :) to jest coś źle zaprojektowane
>>
> normalnie w takiej aplikacji jaka mam na mysli generuje sie sie ramke (i wtedy gc nie powinien sie wlaczac bo bylaby kaszana) po czym wywoluje sie sleep() - ten sleep nie trwa dlugo i nie wiem czy cos takiego jest w javie - ale na przyklad wtwdy gc moglby robic sobie kawalki tej roboty
>

A o wątkach słyszałeś :)??

Pozdrawiam

On 2015-01-20 15:19, obi wan firthe kenobi wrote:
>> Niekoniecznie w czystej javie, ale blisko:
>> http://en.wikipedia.org/wiki/Real_time_Java
> a kojarzysz moze dokladniej jak tam sie to robi? (nie mam czasu sie wglebiac, nie pisze w javie, ale
> byuloby to ciekawe) - jak nie nie ma sprawy

Z grubsza mozna zabronić pracy gc dla określonych bloków pamięci oraz 
określonych wątków o ile pamiętam. W szczególe kolega używał do jakegoś 
projektu z robotymi i mówił że działa zaskakująco dobrze ale ja bliżej 
się tym nie bawiłem. Na youtubie jest troche video jak java robi w 
czasie rzeczywistym obliczenia które przy działającym gc były by 
upiedliwe, np tutaj:

https://www.youtube.com/watch?v=lXct7Bzdhzw

On 2015-01-20 15:23, obi wan firthe kenobi wrote:
> W dniu sobota, 17 stycznia 2015 00:43:56 UTC+1 użytkownik J-23 napisał:
>> W dniu 16.01.2015 o 19:18, obi wan firthe kenobi pisze:
>>> W dniu piątek, 16 stycznia 2015 01:32:19 UTC+1 użytkownik J-23 napisał:
>>>> W dniu 12.01.2015 o 19:23, obi wan firthe kenobi pisze:
>>>>> 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)?
>>>>>
>>>>
>>>> Nie da się tego tak zrobić że oznaczysz (Tutaj nie wykonujemy GC)
>>>>
>>>> Da się natomiast tym odpowiednio sterować tylko temat jest bardzo
>>>> głęboki a ty podałeś bardzo mało danych
>>>>
>>> to jest w sumie odpowiedz + tez mi sie tak zdawalo, wnikac w temat nie mam czasu
>>>
>>
>>
>> Ale zauważ że jak podczas przetwarzania grafiki ci się włacza GC a ty
>> tego nie chcesz :) to jest coś źle zaprojektowane
>>
> normalnie w takiej aplikacji jaka mam na mysli generuje sie sie ramke (i wtedy gc nie powinien sie wlaczac bo bylaby kaszana) po czym wywoluje sie sleep() - ten sleep nie trwa dlugo i nie wiem czy cos takiego jest w javie - ale na przyklad wtwdy gc moglby robic sobie kawalki tej roboty
>

K@%@a kombinujesz aż mnie zęby bolą...

Po prostu na końcu ramki, jak już masz wszystko policzone, to wywołaj GC 
przy pomocy "System.gc()". Dzięki temu GC co może to wyczyści w czasie 
kiedy Twój program i tak czeka do początku następnej ramki. Nie 
gwarantuje Ci to że GC się nie odpali w trakcie ramki, ale znaczni 
obniża prawdopodobieństwo.

Usiłuję Ci to od początku przekazać, a ty jak muł opierasz się, i w 
zamian kombinujesz jakieś niestworzone rzeczy...


Kolejny czynnik to dostępność ramu - jeśli jest go więcej niż potrzeba 
na obliczenia w jednej ramce, to (zakładając wołanie GC na koniec ramki) 
GC się nie odpali w trakcie ramki, bo nie ma po co.


-- 
Arivald