¿Qué es un Managed Language?

¿Qué es un lenguaje gestionado (managed language)?

A diferencia de los lenguajes no gestionados —aquellos que se limitan a ejecutar la lógica establecida por el programador sin mayores añadidos—, un lenguaje gestionado es aquel que delega al entorno de ejecución (runtime) tareas como la recolección de basura (GC), la optimización del runtime, los green threads y la gestión de la concurrencia, evitando así que el usuario deba realizar una gestión de bajo nivel potencialmente peligrosa. Aunque estos lenguajes ofrecen la ventaja de permitir al desarrollador centrarse exclusivamente en la lógica de negocio, pueden presentar el inconveniente de que el comportamiento real del programa difiera de la intuición del programador, lo que a veces requiere una sintonización (tuning) precisa del runtime. En primer lugar, examinaremos el lenguaje Go, el cual es el más fiel a la filosofía minimalista y posee un ensamblador transparente entre los lenguajes gestionados.

Estructura binaria del lenguaje Go

.text	.data	.gopclntab, .typelink, etc.
Código de máquina a ejecutar	Datos a almacenar	Secciones del runtime del lenguaje
Dado que el lenguaje Go no traduce el código a lenguaje máquina de forma 1:1 según lo introducido por el usuario, la lógica de la sección .text está estrechamente relacionada con las secciones del runtime del lenguaje.
Asimismo, funciones como runtime.printnl(), que el usuario no ha escrito explícitamente, se añaden al ensamblador de la sección .text.
Mediante esta inserción automática de código, el lenguaje Go ayuda a liberar al desarrollador de la gestión manual.

Observación de la función main en Go

Primero, escribamos un código de ejemplo sencillo, main.go, y examinémoslo desde main en una máquina AMD64.

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

Posteriormente, se compila de la siguiente manera:

1go build main.go
2

Go proporciona go tool para facilitar la depuración de bajo nivel. Para visualizar únicamente el ensamblador correspondiente a la función main dentro del paquete principal en go tool, se introduce la siguiente sentencia:

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

Ensamblador

 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

Se compara mediante CMPQ si el espacio actual del stack frame de la goroutine es suficiente, verificando el valor del stack guard dentro del registro del bloque de control de la goroutine (R14) frente al puntero de pila actual (SP); si es insuficiente, se realiza un salto (JBE) a la dirección 0x468f95, que es el punto de entrada para la expansión de la pila.
Se inserta el puntero base anterior en la pila mediante PUSHQ BP para guardarlo.
Se copia el puntero de pila actual (SP) al registro del puntero base (BP) para fijar el punto de referencia de la pila al inicio de la función.
A continuación, se asignan 16 bytes de espacio de pila para variables locales (SUBQ $0x10, SP) y se realiza una alineación de caché de CPU utilizando NOPL para rellenar con instrucciones virtuales.
Se invoca runtime.printlock(SB) para bloquear la sincronización de la salida estándar de cadenas interna en el runtime de Go.
Utilizando la instrucción LEAQ, se almacena la dirección de inicio de la cadena asignada como constante ("Hello World") en AX, que se utiliza como primer parámetro según la especificación ABI de Go entre los registros de propósito general.
Posteriormente, se almacena el valor que indica la longitud de la cadena en BX, el registro del segundo parámetro (MOVL $0xb, BX, es decir, 11 en decimal).
Se invoca runtime.printstring(SB) para imprimir en la consola basándose en la información de AX (dirección de datos) y BX (longitud) transmitida.
Se invoca runtime.printnl(SB) para gestionar el salto de línea.
Una vez finalizada la impresión, se libera el bloqueo mediante runtime.printunlock(SB).
Se recuperan los 16 bytes de memoria de pila asignados con ADDQ $0x10, SP.
Se restaura el puntero base original mediante POPQ BP.
Se devuelve el control al punto desde donde se llamó a la función mediante RET.
Si en la comprobación inicial de la pila el espacio era insuficiente, se invoca a runtime.morestack_noctxt.abi0(SB) en la dirección 0x468f95 para expandir dinámicamente el runtime de la pila, conforme a un lenguaje gestionado.
Una vez completada la expansión de la pila, se regresa (JMP) al punto de entrada de main.main(SB). Como se observa, el ensamblador de la lógica de negocio es bastante claro y solo tiene añadida una gestión ligera del runtime.

En ausencia de optimización

La forma anterior es el resultado de que el compilador de Go haya optimizado automáticamente las dos funciones separadas mediante inlining. Sin embargo, con fines didácticos, en este caso no permitiremos que sayHello sea objeto de inlining. Para lograr esto, compilamos el código fuente con la siguiente bandera:

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

Al imprimir los resultados en la shell, se detecta un ensamblador 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

Al deshabilitar el inlining, se insertan operaciones MOVQ que vuelven a cargar valores en el desplazamiento del puntero de pila 0x20(SP), entre otros, para preservar los parámetros (AX, BX) de acuerdo con la especificación de llamada a funciones. En resumen, se ha confirmado que lo que el compilador optimiza es precisamente este tipo de operaciones innecesarias de movimiento de memoria y el overhead de las llamadas.

Próxima sesión

En la próxima sesión trataremos las sentencias if y switch en el lenguaje Go. Si el tiempo lo permite, también analizaremos las secciones del runtime de Go en el futuro.