GoSuda

Che cosa si intende per managed language?

By Lee Yunjin
views ...

Che cosa è un linguaggio managed?

Un linguaggio managed è un linguaggio che, a differenza di un linguaggio unmanaged — ovvero un linguaggio che viene eseguito senza discostarsi significativamente dalla logica scritta dal programmatore — esegue in runtime operazioni come GC, ottimizzazione del runtime, green threads e gestione della concorrenza, sollevando così l'utente dalla necessità di gestire pericolose operazioni di basso livello. Nel caso di tali linguaggi, il vantaggio risiede nella possibilità di concentrarsi esclusivamente sulla business logic, favorendo un maggiore coinvolgimento nello sviluppo; tuttavia, poiché il comportamento effettivo del programma può differire dall'intuizione del programmatore, talvolta si rende necessaria una sofisticata messa a punto del runtime. In primo luogo, esamineremo il linguaggio Go, tra i linguaggi managed quello più fedele alla filosofia minimalista e con un assembly trasparente.

Struttura del binario del linguaggio Go

.text.data.gopclntab, .typelink ecc.
Codice macchina da eseguireDati da memorizzareSezioni del runtime del linguaggio
Poiché il linguaggio Go non traduce il codice macchina in modo 1:1 rispetto a quanto inserito dall'utente, la logica nella sezione .text è strettamente correlata alle sezioni del runtime del linguaggio.
Inoltre, funzioni come runtime.printnl(), non scritte esplicitamente dall'utente, vengono aggiunte all'assembly della sezione .text.
Attraverso tale inserimento automatico di codice, il linguaggio Go aiuta lo sviluppatore a liberarsi 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}
10

Successivamente, eseguiamo la build come segue.

1go build main.go
2

Go supporta il comando go tool per facilitare il debugging di basso livello. Per visualizzare nel go tool solo l'assembly corrispondente alla funzione main all'interno del pacchetto main, si inserisce il seguente comando.

1go tool objdump -s "main\.main" ./main
2

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)
19
  • Dopo aver confrontato con CMPQ il valore della stack guard all'interno del registro del blocco di controllo della goroutine (R14) con l'attuale stack pointer (SP) per verificare se lo spazio nello stack frame della goroutine sia sufficiente, si effettua un salto (JBE) all'indirizzo 0x468f95, ovvero l'entrypoint per l'espansione dello stack, in caso di spazio insufficiente.
  • Si inserisce il base pointer precedente nello stack tramite PUSHQ BP.
  • Si copia l'attuale stack pointer (SP) nel registro base pointer (BP) per fissare il punto di riferimento dello stack all'inizio della funzione.
  • Successivamente, si alloca lo spazio nello stack per le variabili locali pari a 16 byte (SUBQ $0x10, SP) e si esegue l'allineamento della cache della CPU riempiendo con istruzioni fittizie tramite NOPL.
  • Per la sincronizzazione dell'output standard delle stringhe interne nel runtime di Go, si invoca runtime.printlock(SB) per attivare il lock.
  • Tramite l'istruzione LEAQ, l'indirizzo di inizio della stringa assegnata come costante ("Hello World") viene salvato nel registro AX, utilizzato come primo parametro secondo le specifiche ABI di Go.
  • Successivamente, il valore che indica la lunghezza della stringa viene salvato nel secondo registro dei parametri, BX. (MOVL $0xb, BX, ovvero 11 in decimale)
  • Si invoca runtime.printstring(SB) per stampare sulla console basandosi sulle informazioni di AX (indirizzo dei dati) e BX (lunghezza) trasmesse.
  • Si invoca runtime.printnl(SB) per gestire l'a capo.
  • Poiché l'output è completato, si rilascia il lock tramite runtime.printunlock(SB).
  • Si ripristina la memoria dello stack di 16 byte precedentemente allocata con ADDQ $0x10, SP.
  • Si ripristina il base pointer originale tramite POPQ BP.
  • Si restituisce il controllo al punto in cui è stata chiamata la funzione tramite RET.
  • Se durante il controllo iniziale dello stack lo spazio risultava insufficiente, si invoca runtime.morestack_noctxt.abi0(SB) all'indirizzo 0x468f95 per espandere dinamicamente il runtime dello stack, coerentemente con la natura di un linguaggio managed.
  • Una volta completata l'espansione dello stack, si ritorna (JMP) all'entrypoint di main.main(SB). Come si può osservare, l'assembly della business logic è piuttosto chiaro ed è integrato solo da una sottile gestione del runtime.

In assenza di ottimizzazione

La forma sopra riportata è il risultato dell'ottimizzazione automatica effettuata dal compilatore Go, che ha eseguito l'inlining delle due funzioni separate. Tuttavia, a scopo didattico, in questo caso non eseguiremo l'inlining di sayHello. Per farlo, compiliamo il sorgente con il seguente flag.

1go build -gcflags="-l" main.go
2

Visualizzando il risultato nella shell, si riscontra un assembly ridondante.

 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)
27

Disabilitando l'inlining, vengono inserite operazioni MOVQ che ricaricano i valori in offset dello stack pointer come 0x20(SP), al fine di preservare i parametri (AX, BX) in conformità con le specifiche di chiamata delle funzioni. In sintesi, è stato confermato che l'ottimizzazione del compilatore ha come oggetto proprio tali inutili operazioni di spostamento in memoria e l'overhead di chiamata.

Prossimo incontro

Nel prossimo incontro tratteremo le istruzioni if e switch nel linguaggio Go. Se in futuro avremo tempo, analizzeremo anche le sezioni del runtime di Go.