Jestem ciekawy, dlaczego firma Sun zdecydowała się na wykorzystanie stosu JVM, a Google zdecydował się na utworzenie rejestru DalvikVM?
Przypuszczam, że JVM nie może tak naprawdę zakładać, że pewna liczba rejestrów jest dostępna na platformie docelowej, ponieważ ma być niezależna od platformy. Dlatego po prostu odkłada alokację rejestru itp. Do kompilatora JIT. (Popraw mnie, jeśli się mylę.)
Więc faceci z Androidem pomyśleli: „hej, to nieefektywne, przejdźmy od razu do maszyny wirtualnej opartej na rejestrze…”? Ale czekaj, istnieje wiele różnych urządzeń z Androidem, jaką liczbę rejestrów wybrał Dalvik? Czy opkody Dalvik są zakodowane na stałe dla określonej liczby rejestrów?
Czy wszystkie obecne na rynku urządzenia z Androidem mają mniej więcej taką samą liczbę rejestrów? A może jest przeprowadzana ponowna alokacja rejestru podczas ładowania dex? Jak to wszystko do siebie pasuje?
Odpowiedzi:
Istnieje kilka atrybutów maszyny wirtualnej opartej na stosie, które dobrze pasują do celów projektowych Javy:
Projekt oparty na stosie zakłada bardzo niewiele założeń dotyczących sprzętu docelowego (rejestry, funkcje procesora), więc łatwo jest zaimplementować maszynę wirtualną na szerokiej gamie sprzętu.
Ponieważ operandy instrukcji są w dużej mierze niejawne, kod wynikowy będzie zwykle mniejszy. Jest to ważne, jeśli zamierzasz pobierać kod przez wolne łącze sieciowe.
Korzystanie ze schematu opartego na rejestrach prawdopodobnie oznacza, że generator kodu Dalvik nie musi pracować tak ciężko, aby wygenerować wydajny kod. Uruchomienie na architekturze wyjątkowo bogatej w rejestry lub ubogiej w rejestry prawdopodobnie utrudniłoby Dalvik, ale to nie jest zwykły cel - ARM jest architekturą pośrodku drogi.
Zapomniałem również, że pierwotna wersja Dalvik w ogóle nie zawierała JIT. Jeśli masz zamiar zinterpretować instrukcje bezpośrednio, schemat oparty na rejestrze jest prawdopodobnie zwycięzcą w zakresie interpretacji.
źródło
Nie mogę znaleźć odniesienia, ale myślę, że Sun zdecydował się na podejście oparte na kodzie bajtowym stosu, ponieważ ułatwia to uruchomienie maszyny JVM na architekturze z kilkoma rejestrami (np. IA32).
W Dalvik VM Internals z Google I / O 2008 twórca z Dalvik, Dan Bornstein, podaje następujące argumenty przemawiające za wyborem maszyny wirtualnej opartej na rejestrze na slajdzie 35 ze slajdów prezentacji :
a na slajdzie 36:
Według Bornsteina jest to „ogólne oczekiwanie, jakie można znaleźć, konwertując zestaw plików klas na pliki dex”.
Odpowiednia część prezentacji wideo zaczyna się o 25:00 .
Istnieje również wnikliwy artykuł zatytułowany „Virtual Machine Showdown: Stack Versus Registers” autorstwa Shi et al. (2005) , który bada różnice między maszynami wirtualnymi opartymi na stosie i rejestrach.
źródło
Nie wiem, dlaczego Sun zdecydował się oprzeć na stosie JVM. Maszyna wirtualna Erlangs BEAM jest oparta na rejestrach ze względu na wydajność. Dalvik również wydaje się być oparty na rejestrach ze względu na wydajność.
Z Pro Android 2 :
A jeśli chodzi o rozmiar kodu:
I jak dobrze pamiętam Architektura komputera: podejście ilościowe pozwala również stwierdzić, że maszyna rejestrująca działa lepiej niż maszyna ze stosem.
źródło