Wat is een managed language?
Wat is een managed language?
Een managed language is, in tegenstelling tot een unmanaged language — waarbij de uitvoering nauw aansluit bij de door de programmeur geschreven logica — een taal die tijdens runtime aspecten zoals GC, runtime-optimalisatie, green threads en concurrency-afhandeling uitvoert, waardoor de gebruiker geen risicovol beheer op laag niveau hoeft uit te voeren.
Dergelijke talen bieden het voordeel dat men zich volledig kan concentreren op de business logic, wat de ontwikkeling ten goede komt. Anderzijds kan het voorkomen dat het programma in de praktijk anders werkt dan de intuïtie van de programmeur suggereert, waardoor verfijnde runtime-tuning soms noodzakelijk is.
We zullen eerst de Go-taal bekijken, die van alle managed languages het meest trouw is aan een minimalistische filosofie en een transparante assembly kent.
De binaire structuur van de Go-taal
| .text | .data | .gopclntab, .typelink etc. |
|---|---|---|
| Uit te voeren machinecode | Op te slaan data | Language runtime-secties |
Omdat Go de door de gebruiker ingevoerde code niet 1-op-1 vertaalt naar machinecode, is de logica in de .text-sectie nauw verbonden met de language runtime-secties.
Bovendien worden functies die de gebruiker niet zelf heeft geschreven, zoals runtime.printnl(), toegevoegd aan de .text-sectie assembly. Door deze automatische code-injectie helpt de Go-taal de ontwikkelaar om handmatig beheer te vermijden.
De main-functie in Go bekijken
Laten we eerst een eenvoudig voorbeeld main.go schrijven en vanaf main kijken op een AMD64-machine.
1package main
2
3func sayHello(msg string) {
4 println(msg)
5}
6
7func main() {
8 sayHello("Hello World")
9}
Vervolgens bouwen we dit als volgt.
1go build main.go
Go ondersteunt go tool voor eenvoudige low-level debugging.
Om in go tool alleen de assembly van de main-functie in het main-pakket te zien, voeren we de volgende opdracht in.
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)
- Na het vergelijken of de huidige thread is binnengekomen met CMPQ, wordt bij een positieve uitkomst naar het entrypoint 0x468f95 gesprongen.
- Het entrypoint wordt met
PUSHQ BPop de stack geplaatst. - Het startpunt van de stack bij het begin van de functie wordt toegewezen aan het register SP (waar de data het meest recent is geladen), waardoor het entrypoint voor lokale variabele-referenties wordt vastgezet.
- Vervolgens wordt 16 bytes aan stackruimte voor lokale variabelen gereserveerd (
SUBQ $0x10, SP) en wordt NOPL gebruikt om verschillende bytes op te vullen voor CPU-cache alignment. - De Go runtime roept
runtime.printlock(SB)aan om de output-lock van de string-buffer te activeren. - Het LEAQ-commando wordt gebruikt om het startadres van de toegewezen string op te slaan in AX, de accumulator die onder de algemene registers wordt gebruikt voor dataopslag.
- Daarna wordt de stringlengte van 11 opgeslagen in het BX-register, dat wordt gebruikt voor berekeningsondersteuning en tijdelijke dataopslag (
MOVL $0xb, BX). - Met
runtime.printstring(SB)wordt de accumulator-informatie naar SB uitgevoerd. - Een lege regel wordt ook naar SB geschreven met
runtime.printnl(SB). - De string-buffer wordt vrijgegeven met
runtime.printunlock(SB). - Met
ADDQ $0x10, SPwordt het geleende 16-byte stackgeheugen teruggegeven. Omdat het entrypoint aanvankelijk op de stack was geplaatst, wordt het nu metPOPQ BPvan de stack gehaald en wordt een retoursignaal gegeven. - Vervolgens wordt met
runtime.morestack_noctxt.abi0(SB), zoals past bij een managed language, voldoende stack toegewezen en de runtime (inclusief GC) ingesteld. - Er wordt gesprongen naar het beheerde main.main(SB)-adres.
Zoals te zien is, is de assembly van de business logic vrij helder en is er slechts een dunne laag runtime-beheer aan toegevoegd.
Zonder optimalisatie
De bovenstaande vorm is het resultaat van de Go-compiler die automatisch twee afzonderlijke functies heeft ge-inline voor optimalisatie. Echter, voor leerdoeleinden zullen we in dit geval sayHello niet laten inlinen.
Om dit te bewerkstelligen, compileren we de broncode met de volgende vlag.
1 go build -gcflags="-l" main.go
Wanneer we de resultaten in de shell bekijken, zien we dubbele assembly-code.
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$
Dit bevestigt dat de compiler optimalisaties uitvoert op zaken als redundante operaties en inefficiënte loop-unrolling.
Volgende keer
De volgende keer zullen we de if- en switch-statements in Go behandelen. Mocht de tijd het toelaten, dan zullen we in de toekomst ook de Go runtime-secties analyseren.