Qu'est-ce qu'un Managed Language ?
Qu'est-ce qu'un langage managé ?
Un langage managé est un langage qui, contrairement aux langages non managés — c'est-à-dire ceux qui se contentent d'exécuter la logique telle qu'elle a été conçue par le programmeur — prend en charge au niveau du runtime le GC, l'optimisation du runtime, les green threads, le traitement de la concurrence, etc., permettant ainsi à l'utilisateur de s'affranchir d'une gestion de bas niveau risquée. Dans le cas de ces langages, bien qu'il soit avantageux de pouvoir se concentrer exclusivement sur la logique métier, il arrive que le comportement réel du programme diffère de l'intuition du programmeur, nécessitant parfois un réglage fin du runtime. Tout d'abord, nous allons examiner le langage Go, qui est parmi les langages managés celui qui reste le plus fidèle à une philosophie minimaliste et dont l'assembleur est le plus transparent.
Structure binaire du langage Go
| .text | .data | .gopclntab, .typelink, etc. |
|---|---|---|
| Code machine à exécuter | Données à stocker | Section du runtime du langage |
| Comme le langage Go ne traduit pas le code machine de manière strictement identique (1:1) à ce que l'utilisateur a saisi, la logique de la section .text est étroitement liée à la section du runtime du langage. | ||
| De plus, des fonctions que l'utilisateur n'a pas écrites explicitement, telles que runtime.printnl(), sont ajoutées à l'assembleur de la section .text. | ||
| Grâce à cette insertion automatique de code, le langage Go aide le développeur à se libérer d'une gestion manuelle. |
Observation de la fonction main dans Go
Commençons par écrire un exemple simple, main.go, et examinons-le à partir de main sur une machine AMD64.
1package main
2
3func sayHello(msg string) {
4 println(msg)
5}
6
7func main() {
8 sayHello("Hello World")
9}
10
Ensuite, nous effectuons la compilation comme suit :
1go build main.go
2
Go propose l'outil go tool pour faciliter le débogage de bas niveau. Pour visualiser uniquement l'assembleur de la fonction main au sein du package main via go tool, nous saisissons la commande suivante :
1go tool objdump -s "main\.main" ./main
2
Assembleur
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
- On compare la valeur de garde de la pile contenue dans le registre du bloc de contrôle de goroutine (R14) avec le pointeur de pile actuel (SP) à l'aide de l'instruction CMPQ pour vérifier si l'espace du frame de pile de la goroutine est suffisant ; si tel n'est pas le cas, on effectue un saut (JBE) vers l'adresse 0x468f95, qui est le point d'entrée pour l'extension de la pile.
- On insère le précédent pointeur de base dans la pile via PUSHQ BP afin de le sauvegarder.
- On copie le pointeur de pile actuel (SP) dans le registre du pointeur de base (BP) pour fixer la référence de la pile au début de la fonction.
- Ensuite, on alloue 16 octets d'espace de pile pour les variables locales (SUBQ $0x10, SP) et on utilise NOPL pour insérer des instructions virtuelles afin d'aligner le cache du processeur.
- Le runtime Go appelle runtime.printlock(SB) pour verrouiller la synchronisation de la sortie standard des chaînes de caractères internes.
- On utilise l'instruction LEAQ pour stocker l'adresse de début de la chaîne allouée en tant que constante ("Hello World") dans AX, qui est utilisé comme premier paramètre conformément à la spécification ABI de Go parmi les registres généraux.
- Ensuite, la valeur représentant la longueur de la chaîne est stockée dans le deuxième registre de paramètres, BX. (MOVL $0xb, BX, soit 11 en décimal).
- On appelle runtime.printstring(SB) pour effectuer l'affichage sur la console en se basant sur les informations AX (adresse des données) et BX (longueur) transmises.
- On appelle runtime.printnl(SB) pour gérer le saut de ligne.
- Une fois l'affichage terminé, le verrou est libéré via runtime.printunlock(SB).
- On restaure la mémoire de pile de 16 octets allouée précédemment avec ADDQ $0x10, SP.
- On restaure l'ancien pointeur de base via POPQ BP.
- On renvoie le contrôle au point d'appel de la fonction via RET.
- Si l'espace était insuffisant lors de la vérification initiale de la pile, on appelle runtime.morestack_noctxt.abi0(SB) à l'adresse 0x468f95 pour étendre dynamiquement la pile du runtime, conformément à la nature d'un langage managé.
- Une fois l'extension de la pile terminée, on revient (JMP) au point d'entrée de main.main(SB). Comme on peut le constater, l'assembleur de la logique métier est relativement clair et n'est agrémenté que d'une légère gestion par le runtime.
En l'absence d'optimisation
La forme ci-dessus est le résultat de l'optimisation automatique par le compilateur Go, qui a intégré (inlining) les deux fonctions distinctes. Cependant, pour les besoins de notre étude, nous allons faire en sorte que sayHello ne soit pas intégré dans ce cas précis. Pour ce faire, nous compilons le code source avec le flag suivant :
1go build -gcflags="-l" main.go
2
En examinant le résultat dans le shell, on découvre un assembleur redondant.
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
Lorsque l'inlining est désactivé, des opérations MOVQ sont insérées pour recharger les valeurs dans les offsets du pointeur de pile, tels que 0x20(SP), afin de préserver les paramètres (AX, BX) conformément à la convention d'appel de fonction. En somme, il est confirmé que ce que le compilateur optimise, ce sont précisément ces opérations de transfert mémoire inutiles et les surcoûts liés aux appels.
Prochaine étape
La prochaine fois, nous aborderons les instructions if et switch dans le langage Go. Si le temps le permet, nous analyserons également les sections du runtime de Go.