GoSuda

O que é uma managed language?

By Lee Yunjin
views ...

O que é uma linguagem gerenciada?

Uma linguagem gerenciada é, ao contrário de uma linguagem não gerenciada — ou seja, uma linguagem que apenas executa a lógica estruturada pelo programador sem grandes desvios —, uma linguagem que executa GC (Garbage Collection), otimização de runtime, green threads, processamento de concorrência, entre outros, em tempo de execução, permitindo que o usuário não precise realizar o gerenciamento de baixo nível, o qual é inerentemente arriscado. No caso dessas linguagens, existe a vantagem de poder focar exclusivamente na lógica de negócios para o desenvolvimento; por outro lado, como o comportamento real do programa pode diferir da intuição do programador, pode ser necessário realizar um ajuste fino (tuning) sofisticado do runtime. Primeiramente, examinaremos a linguagem Go, que é a mais fiel à filosofia minimalista entre as linguagens gerenciadas e possui uma assembly transparente.

Estrutura binária da linguagem Go

.text.data.gopclntab, .typelink, etc.
Código de máquina a ser executadoDados a serem armazenadosSeções de runtime da linguagem
Como a linguagem Go não traduz para código de máquina em uma relação de 1:1 conforme a entrada do usuário, a lógica na seção .text está intimamente ligada às seções de runtime da linguagem.
Além disso, funções como runtime.printnl(), que não foram escritas pelo usuário, são adicionadas à assembly da seção .text.
Por meio dessa inserção automática de código, a linguagem Go auxilia o desenvolvedor a se libertar do gerenciamento manual.

Observando apenas a função main em Go

Inicialmente, vamos criar um exemplo de código-fonte simples, main.go, e observar a partir da função main em uma máquina AMD64.

 1package main
 2
 3func sayHello(msg string) {
 4    println(msg)
 5}
 6
 7func main() {
 8    sayHello("Hello World")
 9}
10

Em seguida, compile da seguinte forma.

1go build main.go
2

Go oferece suporte ao go tool para facilitar a depuração de baixo nível. No go tool, para visualizar apenas a assembly correspondente à função main no pacote main, insira este 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
  • Após comparar o valor do stack guard dentro do registrador de bloco de controle da goroutine (R14) com o stack pointer (SP) atual usando CMPQ para verificar se o espaço do frame da pilha da goroutine é suficiente, caso seja insuficiente, realiza um salto (JBE) para o endereço 0x468f95, que é o Entrypoint para a expansão da pilha.
  • Insere o base pointer anterior na pilha usando PUSHQ BP para salvá-lo.
  • Copia o stack pointer (SP) atual para o registrador base pointer (BP) para fixar o ponto de referência da pilha no início da função.
  • Em seguida, aloca 16 bytes de espaço de pilha para variáveis locais (SUBQ $0x10, SP) e utiliza NOPL para preencher com instruções virtuais, realizando o alinhamento de cache da CPU.
  • Chama runtime.printlock(SB) para bloquear a sincronização da saída padrão de strings internas no runtime do Go.
  • Utiliza a instrução LEAQ para armazenar o endereço inicial da string alocada como constante ("Hello World") no registrador AX, que é usado como o primeiro parâmetro de acordo com a especificação ABI do Go entre os registradores de propósito geral.
  • Em seguida, armazena o valor que representa o comprimento da string no segundo registrador de parâmetro, BX. (MOVL $0xb, BX, ou seja, 11 em decimal).
  • Chama runtime.printstring(SB) para imprimir no console com base nas informações de AX (endereço dos dados) e BX (comprimento) fornecidas.
  • Chama runtime.printnl(SB) para processar a quebra de linha.
  • Uma vez concluída a impressão, libera o bloqueio através de runtime.printunlock(SB).
  • Recupera a memória de pilha de 16 bytes que foi alocada com ADDQ $0x10, SP.
  • Restaura o base pointer anterior com POPQ BP.
  • Retorna o controle para o ponto onde a função foi chamada via RET.
  • Se o espaço for insuficiente na verificação inicial da pilha, chama runtime.morestack_noctxt.abi0(SB) no endereço 0x468f95 para expandir dinamicamente o runtime da pilha, conforme esperado de uma linguagem gerenciada.
  • Quando a expansão da pilha é concluída, retorna (JMP) para o ponto de entrada de main.main(SB). Como se pode observar, a assembly da lógica de negócios é bastante clara, com apenas uma fina camada de gerenciamento de runtime adicionada.

Sem otimização

A forma acima é o resultado da otimização realizada pelo compilador Go, que automaticamente realizou o inlining de duas funções separadas. No entanto, para fins de aprendizado, neste caso, não realizaremos o inlining de sayHello. Para fazer isso, compilamos o código-fonte com a seguinte flag.

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

Ao verificar o resultado no shell, observa-se a presença de assembly redundante.

 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

Ao desativar o inlining, operações MOVQ são inseridas para recarregar valores no offset do stack pointer, como 0x20(SP), a fim de preservar os parâmetros (AX, BX) de acordo com a especificação de chamada de função. Em suma, foi confirmado que o que o compilador otimiza são justamente essas operações desnecessárias de movimentação de memória e o overhead de chamadas.

Próxima etapa

Na próxima sessão, abordaremos as instruções if e switch na linguagem Go. Caso haja oportunidade futura, também analisaremos as seções de runtime do Go.