Che cosa si intende per managed language?
Che cosa si intende per linguaggio managed?
Un linguaggio managed è un linguaggio che, a differenza dei linguaggi unmanaged – ovvero quelli che vengono eseguiti senza discostarsi significativamente dalla logica implementata dal programmatore – solleva l'utente dalla necessità di gestire operazioni a basso livello rischiose, delegando al runtime l'esecuzione di attività quali GC, ottimizzazione del runtime, green threads e gestione della concorrenza.
Tali linguaggi offrono il vantaggio di permettere allo sviluppatore di concentrarsi esclusivamente sulla business logic; tuttavia, poiché il comportamento effettivo del programma potrebbe divergere dall'intuizione del programmatore, talvolta si rende necessaria una raffinata messa a punto del runtime.
In primo luogo, prenderemo in esame il linguaggio Go, che tra i linguaggi managed è il più fedele a una filosofia minimalista e presenta un assembly trasparente.
Struttura del binario nel linguaggio Go
| .text | .data | .gopclntab, .typelink ecc. |
|---|---|---|
| Codice macchina da eseguire | Dati da memorizzare | Sezioni del runtime del linguaggio |
Poiché il linguaggio Go non traduce il codice in linguaggio macchina con un rapporto 1:1 rispetto all'input dell'utente, la logica nella sezione .text è strettamente correlata alle sezioni del runtime del linguaggio.
Inoltre, funzioni come runtime.printnl(), non esplicitamente scritte dall'utente, vengono aggiunte all'assembly della sezione .text.
Attraverso questa inserzione automatica di codice, il linguaggio Go assiste lo sviluppatore nel distaccarsi dalla gestione manuale.
Analisi della sola funzione main in Go
Per iniziare, scriviamo un semplice esempio di codice sorgente main.go ed esaminiamolo a partire dal main su una macchina AMD64.
1package main
2
3func sayHello(msg string) {
4 println(msg)
5}
6
7func main() {
8 sayHello("Hello World")
9}
Successivamente, si procede alla compilazione come segue:
1go build main.go
Go supporta go tool per facilitare il debugging a basso livello.
Per visualizzare solo l'assembly relativo alla funzione main all'interno del pacchetto main tramite go tool, si esegue il seguente comando:
1go tool objdump -s "main\.main" ./main
Assembly
1TEXT main.main(SB) /home/yjlee/compare-assembly/go/main.go
2 main.go:7 0x468f60 493b6610 CMPQ SP, 0x10(R14)
3 main.go:7 0x468f64 762f JBE 0x468f95
4 main.go:7 0x468f66 55 PUSHQ BP
5 main.go:7 0x468f67 4889e5 MOVQ SP, BP
6 main.go:7 0x468f6a 4883ec10 SUBQ $0x10, SP
7 main.go:8 0x468f6e 90 NOPL
8 main.go:4 0x468f6f e8cca3fcff CALL runtime.printlock(SB)
9 main.go:4 0x468f74 488d05da290100 LEAQ 0x129da(IP), AX
10 main.go:4 0x468f7b bb0b000000 MOVL $0xb, BX
11 main.go:4 0x468f80 e83bacfcff CALL runtime.printstring(SB)
12 main.go:4 0x468f85 e8f6a5fcff CALL runtime.printnl(SB)
13 main.go:4 0x468f8a e811a4fcff CALL runtime.printunlock(SB)
14 main.go:9 0x468f8f 4883c410 ADDQ $0x10, SP
15 main.go:9 0x468f93 5d POPQ BP
16 main.go:9 0x468f94 c3 RET
17 main.go:7 0x468f95 e8e6afffff CALL runtime.morestack_noctxt.abi0(SB)
18 main.go:7 0x468f9a ebc4 JMP main.main(SB)
- Dopo aver verificato tramite CMPQ se il thread corrente è stato inserito, in caso affermativo si esegue un salto all'Entrypoint 0x468f95.
- Il punto di ingresso viene inserito nello stack tramite
PUSHQ BP. - All'inizio della funzione, viene specificato il punto di partenza dello stack nel registro SP, dove sono stati caricati i dati più recenti, fissando così il punto di ingresso per il riferimento alle variabili locali.
- Successivamente, viene riservato uno stack di 16 byte per le variabili locali (
SUBQ $0x10, SP) e viene utilizzato NOPL per riempire diversi byte e allineare la cache della CPU. - Il runtime di Go richiama
runtime.printlock(SB)per bloccare l'output del buffer della stringa. - Tramite l'istruzione LEAQ, l'indirizzo iniziale della stringa allocata viene salvato in AX, l'accumulatore utilizzato tra i registri generici per l'archiviazione dei dati.
- In seguito, viene salvata la lunghezza della stringa, pari a 11, nel registro BX, utilizzato per il supporto alle operazioni e l'archiviazione temporanea dei dati. (
MOVL $0xb, BX) - Con
runtime.printstring(SB), le informazioni dell'accumulatore vengono inviate verso SB. - Anche lo spazio vuoto di una riga viene scritto verso SB tramite
runtime.printnl(SB). - Il buffer della stringa viene rilasciato tramite
runtime.printunlock(SB). - Con
ADDQ $0x10, SPviene restituita la memoria dello stack di 16 byte precedentemente richiesta. Avendo inserito inizialmente il punto di ingresso nello stack, ora lo si rimuove tramitePOPQ BPe si invia il segnale di ritorno. - Successivamente, tramite
runtime.morestack_noctxt.abi0(SB), coerentemente con la natura di un linguaggio managed, viene allocato uno stack sufficiente e viene configurato il runtime, inclusi il GC e altri componenti. - Si passa all'indirizzo gestito
main.main(SB).
Come si può osservare, l'assembly della business logic è piuttosto chiaro, con l'aggiunta di una gestione del runtime di modeste dimensioni.
In assenza di ottimizzazione
La forma precedente è il risultato dell'ottimizzazione ottenuta tramite l'inlining automatico di due funzioni separate da parte del compilatore Go. Tuttavia, a scopo didattico, in questo caso non eseguiremo l'inlining di sayHello.
Per ottenere ciò, compiliamo il sorgente con il seguente flag:
1 go build -gcflags="-l" main.go
Analizzando i risultati nella shell, si riscontra la presenza di assembly duplicato.
1yjlee@elegant:~/compare-assembly/go$ go build -gcflags="-l" main.go
2
3go tool objdump -s "main\.sayHello" ./main
4TEXT main.sayHello(SB) /home/yjlee/compare-assembly/go/main.go
5 main.go:3 0x468f60 493b6610 CMPQ SP, 0x10(R14)
6 main.go:3 0x468f64 7636 JBE 0x468f9c
7 main.go:3 0x468f66 55 PUSHQ BP
8 main.go:3 0x468f67 4889e5 MOVQ SP, BP
9 main.go:3 0x468f6a 4883ec10 SUBQ $0x10, SP
10 main.go:5 0x468f6e 4889442420 MOVQ AX, 0x20(SP)
11 main.go:5 0x468f73 48895c2428 MOVQ BX, 0x28(SP)
12 main.go:4 0x468f78 e8c3a3fcff CALL runtime.printlock(SB)
13 main.go:4 0x468f7d 488b442420 MOVQ 0x20(SP), AX
14 main.go:4 0x468f82 488b5c2428 MOVQ 0x28(SP), BX
15 main.go:4 0x468f87 e834acfcff CALL runtime.printstring(SB)
16 main.go:4 0x468f8c e8efa5fcff CALL runtime.printnl(SB)
17 main.go:4 0x468f91 e80aa4fcff CALL runtime.printunlock(SB)
18 main.go:5 0x468f96 4883c410 ADDQ $0x10, SP
19 main.go:5 0x468f9a 5d POPQ BP
20 main.go:5 0x468f9b c3 RET
21 main.go:3 0x468f9c 4889442408 MOVQ AX, 0x8(SP)
22 main.go:3 0x468fa1 48895c2410 MOVQ BX, 0x10(SP)
23 main.go:3 0x468fa6 e8d5afffff CALL runtime.morestack_noctxt.abi0(SB)
24 main.go:3 0x468fab 488b442408 MOVQ 0x8(SP), AX
25 main.go:3 0x468fb0 488b5c2410 MOVQ 0x10(SP), BX
26 main.go:3 0x468fb5 eba9 JMP main.sayHello(SB)
27yjlee@elegant:~/compare-assembly/go$ go tool objdump -s "main\.sayHello" ./main
28TEXT main.sayHello(SB) /home/yjlee/compare-assembly/go/main.go
29 main.go:3 0x468f60 493b6610 CMPQ SP, 0x10(R14)
30 main.go:3 0x468f64 7636 JBE 0x468f9c
31 main.go:3 0x468f66 55 PUSHQ BP
32 main.go:3 0x468f67 4889e5 MOVQ SP, BP
33 main.go:3 0x468f6a 4883ec10 SUBQ $0x10, SP
34 main.go:5 0x468f6e 4889442420 MOVQ AX, 0x20(SP)
35 main.go:5 0x468f73 48895c2428 MOVQ BX, 0x28(SP)
36 main.go:4 0x468f78 e8c3a3fcff CALL runtime.printlock(SB)
37 main.go:4 0x468f7d 488b442420 MOVQ 0x20(SP), AX
38 main.go:4 0x468f82 488b5c2428 MOVQ 0x28(SP), BX
39OVQ 0x20(SP), AX
40 main.go:4 0x468f82 488b5c2428 MOVQ 0x28(SP), BX
41 main.go:4 0x468f87 e834acfcff CALL runtime.printstring(SB)
42 main.go:4 0x468f8c e8efa5fcff CALL runtime.printnl(SB)
43 main.go:4 0x468f91 e80aa4fcff CALL runtime.printunlock(SB)
44 main.go:5 0x468f96 4883c410 ADDQ $0x10, SP
45 main.go:5 0x468f9a 5d POPQ BP
46 main.go:5 0x468f9b c3 RET
47 main.go:3 0x468f9c 4889442408 MOVQ AX, 0x8(SP)
48 main.go:3 0x468fa1 48895c2410 MOVQ BX, 0x10(SP)
49 main.go:3 0x468fa6 e8d5afffff CALL runtime.morestack_noctxt.abi0(SB)
50 main.go:3 0x468fab 488b442408 MOVQ 0x8(SP), AX
51 main.go:3 0x468fb0 488b5c2410 MOVQ 0x10(SP), BX
52 main.go:3 0x468fb5 eba9 JMP main.sayHello(SB)
53yjlee@elegant:~/compare-assembly/go$
In sintesi, è stato confermato che l'ottimizzazione operata dal compilatore riguarda proprio tali operazioni duplicate, l'inefficiente loop unrolling e simili.
Prossimo incontro
Nel prossimo incontro tratteremo le istruzioni if e switch nel linguaggio Go. Qualora vi fosse tempo in futuro, analizzeremo anche le sezioni del runtime di Go.