🚀 go-pugleaf

Na prosbe Karola wyprodukuje sie troche na temat JIT, interpreterow i
prekompilatorow. Tak wiec nie musicie tego czytac, bo jest troche dlugie:)

Na poczatku trzeba skumac jak dokladnie wygladaja bytecody javy.
Sa to instrukcje psudoprocesora, dosyc wysokiego poziomu (w stosunku do
normalnego assemblera). Zeby uniezaleznic sie of platformy wszystkie
operacje odbywaja sie na stosie. Tak wiec mamy push 0, add (dodaje dwie
liczby ze stosu i umieszcza na nim wynik) itp.
W interperterze wszystko odbywa sie dokladnie w ten sposob. Mamy petelke

while( costam)
{
	switch ( getu8() )
	{
		case OPCODE_PUSH:
			...
		case OPCODE_ADD:
			...
		...
	}
}

Tak wiec jezeli chcesz dodac do siebie 2 i 2 to robisz

push 2
push 2
add

co w przelozeniu na assmbler jakiegos procesora (a'la Intela :) tlumaczy
sie na

r1 - program counter
r2 - stos javowski
(rejestry lub miejsca w pamieci, jezeli pamiec to jeszcze jeden poziom
indirection)

petla:	
	jmp [r1]
	...

opcode_push:
	inc r1
	movl [r2],r1 
	add r1, 4
	add r2, 4
	jmp petla

znowu
	jmp [r1]
	
i cala operacja z opcode_push

potem znow jmp i

opcode_add:
	mov r3, [r2]
	sub r2,4
	mov r4, [r2]
	add r3, r4
	mov [r2-4], r3
	jmp petla

Dluga zabawa tylko po to aby dodac 2 liczby (oczywiscie ten przyklad
bedzie zoptymalizowany przez javac, ale nie o to chodzi).
Duzo dostepow do pamieci. A wystarczy przeciez

mov r1, 2
mov r2, 2
add r1,r2
i wynik mamy w r2.
I tu wlasnie wchodza JIT. Biora one opcody javy i zamieniaja na rownowazne
im instrukcje konkretnego procesora. To pozwala uniknac skakania w switch.
Robia tez istotniejsza sztuczke - czesc java-stosu implementuja na
rejestrach. Dzieki temu zamiast ciaglych odwolan do pamieci, mamy operacje
na rejestarch dla najczesiej uzywanych zmiennych.
Pozwala to na przyspieszenie kodu ok 3-10 razy na Intelu i wiecej na RISC.
Jakie sa problemy ?
Niektorych instrukcji nie optymalizuje sie na rejestry - wymagaja dostepu
do pamieci (albo wlasnie na sie rejestry skonczyly). Wtedy zamiast
8-bitowej instrukcji javy add, mamy 5 mnemonikow co np na Alfie daje 5*32
bajty. Oczywiscie nie wszystko jest tak brutalne, ale trzbea sie liczyc z
co najmniej 8-krotnym wzrostem miejsca zajmowanego przez klase, przy
okazji trzeba ja tez trzymac w pamieci, bo jest potrzebna wersja zrodlowa
do debuggingu itp)
W JIT nie mozna robic tez prawdziwej optymalizacji run-time ( w javie
optymalizacja w czasie kompilacji nie jest mozliwa na wieksza skale -
wszelkie klasy poza kompilowana moga sie zmienic i nie mozna robic
nic inline) 
JIT jest takze trudniejszy do implementacji - na kazdy procesor trzeba go
robic inny, a port interpretera nie jest skomplikowany)
Tu wchodza prekompilatory. Biora one wszystkie potrzebne klasy i kompiluja
do jednego pliku wykonywalnego. Moga robic wszelkie optymalizacje, bo
klasy ktore wykorzystuja nie zmienia sie - zostana zamrozone w execu.
Jest mozliwe dolaczanie potem innych klas w run-time, ale one z
oczywistych wzgledow nie beda juz az tak optymalizowane.
Wydaje sie ze lamie to przenosnosc javy - nie zupelnie. Po pierwsze kazdy
moze zrobic to u siebie na komputerze (dostaje wersje w java bytecode i
linkuje do zoptymalizowanego execa na potrzey danej maszyny; jak zmieni
sprzet to zlinkuje jeszcze raz). Po drugie java nie zostala napisana (tu
cytuje) z mysla
Compile Once, Run Anywhere
ale
Write Once, Run Anywhere
Prekompilatory takie moga tez rozwiazac problem dekompilacji bytecodow -
firma bedzie rozpowszechniala wersje juz czesciowo zlinkowane.
Prekompilatory sa zapewne przyszloscia - obok powaznych JIT. Interpretery
pozostana jako zaplecze gdy pamiec bedzie ograniczona.

Jezeli chodzi o prekompilatory to jest juz jeden na Intel/Windows :( -
SuperCede. Nie wiem o nim duzo - sprawdz http://www.supercede.com
Kaffe tez ma byc wzbogacona o prekompilator, a wlasciwie to prekompilator
o kaffe. Cygnus robi interface kompilujacy bytecody javy, wpleciony w gcc.
Dzieki temu zaoszczedzaja duzo roboty - maja gigantyczna baze.
Bedzie tez mozliwe bezposrednie laczenie .o z C,C++,javy i co tylko tam
jest w gcc. Wymagac to bedzie oczywiscie zmiany linkera itp, ale wyglada
ciekawie.

Artur