Was ist eine Managed Language?
Was ist eine Managed Language?
Eine Managed Language ist eine Sprache, die sich von unmanaged Sprachen – also solchen, die lediglich die vom Programmierer geschriebene Logik ausführen, ohne davon maßgeblich abzuweichen – dadurch unterscheidet, dass sie GC, Runtime-Optimierung, Green Threads, Concurrency-Verarbeitung und Ähnliches zur Laufzeit ausführt. Dies entbindet den Anwender von der Notwendigkeit, riskante Low-Level-Verwaltungen selbst durchzuführen.
Bei derartigen Sprachen besteht der Vorteil darin, dass sich der Entwickler voll und ganz auf die Business Logic konzentrieren kann. Andererseits kann es vorkommen, dass das tatsächliche Verhalten des Programms von der Intuition des Programmierers abweicht, was mitunter eine präzise Runtime-Tuning erforderlich macht.
Zunächst werden wir uns die Go-Sprache ansehen, da sie unter den Managed Languages am konsequentesten eine minimalistische Philosophie verfolgt und eine transparente Assembly aufweist.
Binärstruktur der Go-Sprache
| .text | .data | .gopclntab, .typelink etc. |
|---|---|---|
| Auszuführender Maschinencode | Zu speichernde Daten | Language Runtime Sections |
Da Go den vom Benutzer eingegebenen Code nicht 1:1 in Maschinencode übersetzt, ist die Logik im .text-Abschnitt eng mit den Language Runtime Sections verknüpft.
Darüber hinaus werden Funktionen wie runtime.printnl(), die vom Benutzer nicht explizit geschrieben wurden, in die Assembly des .text-Abschnitts eingefügt. Durch diese automatische Code-Injektion unterstützt Go den Entwickler dabei, sich von der manuellen Verwaltung zu lösen.
Betrachtung nur des main-Funktionsbereichs in Go
Zunächst erstellen wir eine einfache Beispiel-Quelldatei main.go, um uns die main-Funktion auf einer AMD64-Maschine anzusehen.
1package main
2
3func sayHello(msg string) {
4 println(msg)
5}
6
7func main() {
8 sayHello("Hello World")
9}
Anschließend wird der Build-Vorgang wie folgt durchgeführt:
1go build main.go
Go unterstützt go tool für eine einfache Low-Level-Fehlersuche.
Um innerhalb des go tool im Main-Paket nur die Assembly für die Main-Funktion anzuzeigen, wird folgender Befehl eingegeben:
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)
- Nach dem Vergleich des Eintritts in den aktuellen Thread mittels CMPQ wird bei Übereinstimmung zum Entrypoint 0x468f95 gesprungen.
- Der Einstiegspunkt wird mittels
PUSHQ BPauf den Stack gelegt. - Am Register SP, in dem zuletzt Daten geladen wurden, wird zu Beginn der Funktion der Startpunkt des Stacks festgelegt, um den Einstiegspunkt für den Zugriff auf lokale Variablen zu fixieren.
- Danach werden 16 Byte für den Stack lokaler Variablen reserviert (
SUBQ $0x10, SP) und mittels NOPL werden mehrere Bytes aufgefüllt, um das CPU-Cache-Alignment zu gewährleisten. - Die Go-Runtime sperrt die Ausgabe des String-Puffers durch den Aufruf von
runtime.printlock(SB). - Mittels des LEAQ-Befehls wird die Startadresse des zugewiesenen Strings in AX gespeichert, dem Akkumulator-Register, das unter den Universalregistern für die Datenspeicherung verwendet wird.
- Anschließend wird die String-Länge 11 im BX-Register gespeichert, welches für Rechenhilfen und temporäre Datenspeicherung genutzt wird (
MOVL $0xb, BX). - Mit runtime.printstring(SB) werden die Informationen des Akkumulators in Richtung SB ausgegeben.
- Ein Zeilenumbruch wird ebenfalls mit runtime.printnl(SB) an SB gesendet.
- Der String-Puffer wird mit runtime.printunlock(SB) wieder freigegeben.
- Mit ADDQ $0x10, SP wird der geliehene 16-Byte-Stack-Speicher zurückgegeben. Da der Einstiegspunkt zu Beginn auf den Stack gelegt wurde, wird er nun mit POPQ BP vom Stack entfernt, bevor das Rückgabesignal erfolgt.
- Danach wird, wie es für eine Managed Language üblich ist, mit runtime.morestack_noctxt.abi0(SB) ausreichend Stack zugewiesen und die Runtime einschließlich GC eingerichtet.
- Es erfolgt der Sprung zur verwalteten Adresse main.main(SB).
Wie zu sehen ist, ist die Assembly der Business Logic recht übersichtlich und nur um eine schlanke Runtime-Verwaltung ergänzt.
Ohne Optimierung
Die obige Form ist das Ergebnis des Go-Compilers, der zwei getrennte Funktionen automatisch durch Inlining optimiert hat. Zu Lernzwecken werden wir jedoch in diesem Fall das Inlining von sayHello unterbinden.
Dies erreichen wir durch die Kompilierung mit folgendem Flag:
1 go build -gcflags="-l" main.go
Wenn wir die Ergebnisse in der Shell betrachten, werden redundante Assembly-Abschnitte sichtbar.
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$
Es wurde bestätigt, dass der Compiler solche redundanten Operationen sowie ineffizientes Loop-Unrolling als Ziele für Optimierungen betrachtet.
Nächstes Mal
Beim nächsten Mal werden wir uns mit if-Statements und switch-Statements in Go beschäftigen. Sollte die Zeit es erlauben, werden wir auch die Go-Runtime-Abschnitte analysieren.