Dopasowanie projektu maszyny wirtualnej do jej podstawowego języka programowania

Question

Jako tło dla projektu pobocznego czytałem o różnych projektach maszyn wirtualnych, przy czym JVM oczywiście uzyskała największą prasę. Spojrzałem również na BEAM (Erlang), GTS RTS (rodzaj ale nie całkiem VM) i niektóre implementacje JavaScript. Python ma również interpreter kodu bajtowego, o którym wiem, że istnieje, ale nie czytał o nim zbyt wiele.

To, czego nie znalazłem, jest dobrym wytłumaczeniem dla , dla której dokonano wyboru konkretnej maszyny wirtualnej dla określonego języka. Szczególnie interesują mnie wybory projektowe pasujące do współbieżnych i/lub bardzo dynamicznych języków (Ruby, JavaScript, Lisp).

---

Edit: W odpowiedzi na komentarz z prośbą o swoistości tutaj jest przykładem. JVM używa maszyny stosu, a nie maszyny rejestrującej, co było bardzo kontrowersyjne po pierwszym wprowadzeniu Javy. Okazało się, że inżynierowie, którzy zaprojektowali maszynę JVM, dokonali tak zamierzonej przenośności platformy, a przekształcenie maszyny stosowej z powrotem w maszynę rejestrującą było łatwiejsze i bardziej wydajne niż pokonanie niedopasowania impedancji, w którym było zbyt wiele lub zbyt mało rejestrów wirtualnych.

Oto kolejny przykład: dla Haskella papier, który warto obejrzeć, to: Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine. To bardzo różni się od każdego innego VM, o którym wiem. I faktycznie GHC (premierowa implementacja Haskella) nie działa na żywo, ale służy jako pośredni krok w kompilacji. Peyton-Jones wymienia nie mniej niż 8 innych maszyn wirtualnych, które nie działały. Chciałbym zrozumieć, dlaczego niektóre maszyny wirtualne odnoszą sukces tam, gdzie inne zawodzą.

Answer 1

Odpowiem na twoje pytanie z innej strony: czym jest VM? VM jest jedynie specyfikacją dla "tłumacza" niższego poziomu języka niż język źródłowy. Tutaj używam czarnego pola znaczenia słowa "tłumacz". Nie obchodzi mnie, jak VM zostanie zaimplementowana (jako intepereter kodu bajtowego, kompilator JIT, cokolwiek). Kiedy tak sformułowane, z punktu widzenia projektu VM nie jest interesującą rzeczą, że jest to język niskiego poziomu.

Idealny język VM zrobi dwie rzeczy. Po pierwsze, ułatwi to skompilowanie do niego języka źródłowego. Dwa ułatwią również interpretację na platformach docelowych (gdzie ponownie interpreter może zostać zaimplementowany bardzo naiwnie lub może być naprawdę zaawansowanym JIT takim jak Hotspot lub V8).

Oczywiście istnieje napięcie między tymi dwoma pożądanymi właściwościami, ale w mniejszym lub większym stopniu tworzą one dwa punkty końcowe na linii w przestrzeni projektowej wszystkich możliwych maszyn wirtualnych. (Lub może jakiś bardziej skomplikowany kształt niż linia, ponieważ nie jest to płaska przestrzeń euklidesowa, ale masz pomysł). Jeśli zbudujesz swój język VM daleko poza tą linią, nie będzie to zbyt użyteczne. To właśnie ogranicza konstrukcję VM: umieszczając ją gdzieś w tej idealnej linii.

Linia ta jest również przyczyną tego, że maszyny wirtualne o wysokim poziomie są zwykle bardzo specyficzne dla języka, podczas gdy maszyny wirtualne o niskim poziomie są bardziej agnostyczne, ale nie zapewniają wielu usług. Maszyna wirtualna wysokiego poziomu jest ze swej natury blisko języka źródłowego, co czyni go dalekim od innych, różnych języków źródłowych. Niskopoziomowa maszyna wirtualna jest ze swojej natury blisko platformy docelowej, tak blisko do końca idealnych linii dla wielu języków, ale ta maszyna wirtualna o niskim poziomie będzie również dość daleko od "łatwego do skompilowania" końca idealnej linii większość języków źródłowych.

Teraz, szerzej, koncepcyjnie każdy kompilator może być postrzegany jako seria przekształceń od języka źródłowego do pośrednich, które same mogą być postrzegane jako języki dla maszyn wirtualnych. Maszyny wirtualne dla języków pośrednich mogą nigdy nie zostać zbudowane, ale mogą być. Kompilator ostatecznie emituje ostateczną formę. I ta ostateczna forma sama będzie językiem dla VM. Możemy nazwać to VM "JVM", "V8" ... lub możemy nazwać to VM "x86", "ARM", itp.

Nadzieję, że pomaga.

Answer 2

Znalazłem tę książkę jako pomocną. Omawia wiele punktów, o które pytasz. (zauważ, że nie jestem w żaden sposób związany z Amazon, ani nie promuję Amazon, tylko było to najłatwiejsze miejsce do połączenia z).

http://www.amazon.com/dp/1852339691/

Answer 3

Jedną z technik uzyskiwania VM jest po prostu iść w dół łańcucha kompilacji, przekształcając swój język źródłowy do coraz bardziej niskopoziomowych języków pośrednich. Po znalezieniu niskiego poziomu wystarczającego języka odpowiedniego dla płaskiej reprezentacji (tj. Tej, która może być serializowana do sekwencji "instrukcji"), jest to prawie Twoja maszyna wirtualna. A twój interpreter VM lub kompilator JIT kontynuowałby twój łańcuch transformacji od punktu wybranego do serializacji.

Niektóre techniki serializacji są bardzo powszechne - np. Przy użyciu reprezentacji pseudo-sterty dla drzewek wyrażeń (jak w .NET CLR, która w ogóle nie jest "prawdziwą" maszyną stosu). W przeciwnym razie możesz użyć formularza SSA do serializacji, jak w LLVM, lub po prostu 3-adresowej maszyny wirtualnej z nieskończoną liczbą rejestrów (jak w Dalvik). To naprawdę nie ma znaczenia, w jaki sposób podejmiesz, ponieważ jest to tylko serializacja i później zostanie zdekrealizowana, aby kontynuować normalny sposób kompilacji.

To trochę inna historia, jeśli zamierzasz zinterpretować kod VM natychmiast, zamiast go skompilować. Obecnie nie ma zgody co do tego, które maszyny wirtualne lepiej nadają się do interpretacji. Obydwie oparte na stosie (lub ośmielałem się powiedzieć, oparte na Forth-) maszyny wirtualne i oparte na rejestrach okazały się wydajne.