W chwili wykonania lcmp na stosie są czasy (long) z obu dat. Jedyna szansa na zaistnienie nierówności do wskoczenie GC na drugim new. Czyli odpowiedź brzmi: zależy :-)).
Odpowiedź generalnie poprawna, tylko wytłumaczenie nie bardzo zrozumiałe (przynajmniej dla mnie). Wg mnie nierówność zależy m.in. od tego, jak szybko tyka nam procesor. Jeśli między wywołaniami "new" nic nie zabierze nam procesora na dłużej niż jedną milisekundę, to nierówność zwróci false. Wytłumacz dokładniej co masz na myśli z tym GC?
No chodzi o to, że GC zabierze nam ten czas procesora pomiędzy wywołaniami new. Równie dobrze może to być inny wątek Javowy, lub przełączenie z systemu operacyjnego całej maszyny wirtualnej.
getTime zwraca pole fastTime z klasy Date. new Date bez parametrów wywołuje new Date() z parametrem typu long, a pobiera go z System.currentTimeMillis. Parametr ten jest przypisywany do fastTime.
z dokumentacji System.currentTimeMillis
"Note that while the unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger."
W dodatku zapewne testowałeś na procesorze wielordzeniowym gdzie wywłaszczenie procesu JVM jest znacznie rzadsze niż na jednordzeniowym.
Podsumowując Zwraca true wtedy gdy: - pomiędzy wywołaniami konstruktora trafi się wywłaszczenie procesu JVM z procesora. - pomiędzy wywołaniami new trafi się proces GC i to też niekoniecznie, bo jeżeli GC nie ma nic do czyszczenia to nie zawiesi działania programu. - system ma wysoką granulację czasu (poniżej jednej milisekundy), ale to rzadkie przypadki.
false?
OdpowiedzUsuńWróćmy do źródeł:
OdpowiedzUsuńnew #3; //class java/util/Date
dup
invokespecial #4; //Method java/util/Date."<init>":()V
invokevirtual #5; //Method java/util/Date.getTime:()J
new #3; //class java/util/Date
dup
invokespecial #4; //Method java/util/Date."<init>":()V
invokevirtual #5; //Method java/util/Date.getTime:()J
lcmp
W chwili wykonania lcmp na stosie są czasy (long) z obu dat. Jedyna szansa na zaistnienie nierówności do wskoczenie GC na drugim new. Czyli odpowiedź brzmi: zależy :-)).
Odpowiedź generalnie poprawna, tylko wytłumaczenie nie bardzo zrozumiałe (przynajmniej dla mnie). Wg mnie nierówność zależy m.in. od tego, jak szybko tyka nam procesor. Jeśli między wywołaniami "new" nic nie zabierze nam procesora na dłużej niż jedną milisekundę, to nierówność zwróci false. Wytłumacz dokładniej co masz na myśli z tym GC?
OdpowiedzUsuńNo chodzi o to, że GC zabierze nam ten czas procesora pomiędzy wywołaniami new. Równie dobrze może to być inny wątek Javowy, lub przełączenie z systemu operacyjnego całej maszyny wirtualnej.
OdpowiedzUsuńW takim kontekście GC ma sens.
OdpowiedzUsuńgetTime zwraca pole fastTime z klasy Date.
OdpowiedzUsuńnew Date bez parametrów wywołuje new Date() z parametrem typu long, a pobiera go z System.currentTimeMillis. Parametr ten jest przypisywany do fastTime.
z dokumentacji System.currentTimeMillis
"Note that while the unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger."
W dodatku zapewne testowałeś na procesorze wielordzeniowym gdzie wywłaszczenie procesu JVM jest znacznie rzadsze niż na jednordzeniowym.
Podsumowując
Zwraca true wtedy gdy:
- pomiędzy wywołaniami konstruktora trafi się wywłaszczenie procesu JVM z procesora.
- pomiędzy wywołaniami new trafi się proces GC i to też niekoniecznie, bo jeżeli GC nie ma nic do czyszczenia to nie zawiesi działania programu.
- system ma wysoką granulację czasu (poniżej jednej milisekundy), ale to rzadkie przypadki.