124 lines
6.9 KiB
Markdown
124 lines
6.9 KiB
Markdown
---
|
|
id: AGD-0013
|
|
ticket: perf-vm-allocation-and-copy-pressure
|
|
title: Agenda - [PERF] VM Allocation and Copy Pressure
|
|
status: accepted
|
|
created: 2026-03-27
|
|
resolved: 2026-04-20
|
|
decision: DEC-0018
|
|
tags: []
|
|
---
|
|
|
|
# Agenda - [PERF] VM Allocation and Copy Pressure
|
|
|
|
## Problema
|
|
|
|
O core da VM ainda aloca e clona demais em alguns caminhos relevantes, especialmente quando strings entram no fluxo.
|
|
|
|
Hoje `ADD` com string usa `format!`/`to_string()`, `GET_GLOBAL` clona valores e varios caminhos de erro montam strings dinamicas.
|
|
|
|
## Dor
|
|
|
|
- churn de heap reduz o teto de throughput da VM.
|
|
- carts que abusam de string e estado global pagam custo cedo demais.
|
|
- hardware barato sente alocacao repetitiva de forma desproporcional.
|
|
|
|
## Hotspots Atuais
|
|
|
|
- [virtual_machine.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/console/prometeu-vm/src/virtual_machine.rs#L635)
|
|
- [virtual_machine.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/console/prometeu-vm/src/virtual_machine.rs#L870)
|
|
- [tick.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/console/prometeu-system/src/virtual_machine_runtime/tick.rs#L111)
|
|
|
|
## Alvo da Discussao
|
|
|
|
Definir o nivel de disciplina de alocacao/copia exigido do core da VM no baseline do console.
|
|
|
|
## O Que Precisa Ser Definido
|
|
|
|
1. Prioridade dos casos.
|
|
Fechar quais caminhos sao realmente hot:
|
|
- opcodes de string;
|
|
- acesso a globals;
|
|
- faults;
|
|
- logs.
|
|
|
|
2. Estrategia de ownership.
|
|
Decidir onde vale introduzir:
|
|
- borrow temporario;
|
|
- small-string strategy;
|
|
- copy-on-write;
|
|
- intern/cache de strings.
|
|
|
|
3. Meta de alocacao.
|
|
Definir se o projeto quer:
|
|
- zero alloc no frame loop feliz;
|
|
- alloc rara e explicita;
|
|
- apenas reducao oportunista.
|
|
|
|
4. Instrumentacao.
|
|
Decidir como medir alocacao sem transformar a VM em microbenchmark artificial.
|
|
|
|
## Open Questions de Arquitetura
|
|
|
|
1. Strings sao citizen de primeira classe no fantasy console ou recurso conveniente mas caro?
|
|
2. Vale endurecer a linguagem/ABI para reduzir alocacao implicitamente?
|
|
3. Caminhos de fault precisam ser maximizados para desempenho ou apenas os caminhos felizes?
|
|
|
|
## Sugestoes para Fechar as Open Questions
|
|
|
|
1. Strings devem ser tratadas como recurso suportado, mas caro por definicao no baseline.
|
|
A VM hoje modela `Value::String(String)` como valor inline clonavel e o opcode `ADD` concatena via `format!`, entao o custo de copia ja faz parte do comportamento real do runtime. A sugestao nao e prometer "string cheap" na semantica base, e sim preservar string como capacidade legitima da linguagem enquanto o baseline otimiza os caminhos quentes que nao dependem de formatacao dinamica. Strings hardcoded podem ser materializadas uma vez na constant pool durante build/load; strings dinamicas podem ser materializadas em storage dinamico durante runtime. Em ambos os casos, a primeira materializacao e aceitavel. O que esta fora da meta e recopiar payload de string repetidamente no caminho quente depois dessa primeira materializacao.
|
|
|
|
2. Vale endurecer o contrato operacional, mas nao a expressividade publica da linguagem neste primeiro passo.
|
|
A recomendacao e evitar uma mudanca ampla de ABI agora. Em vez disso:
|
|
- o caminho feliz do frame loop deve evitar alocacao implicita quando opera sobre numeros, handles e valores ja materializados;
|
|
- strings dinamicas devem continuar permitidas, mas tratadas como custo explicito de runtime;
|
|
- globals devem privilegiar handles e valores baratos no caminho quente, sem introduzir nova semantica publica para `GET_GLOBAL`;
|
|
- qualquer estrategia mais invasiva, como intern global, copy-on-write ou heap-string canonica, deve nascer como decisao posterior se a telemetria provar necessidade.
|
|
|
|
3. Fault paths nao precisam ser maximizados como se fossem caminho quente.
|
|
A recomendacao e exigir que traps e faults permanencam corretos, deterministas e legiveis para tooling host-owned, mas sem contaminar o caminho feliz com formatacao defensiva ou montagem rica de strings em toda instrucao. O investimento principal deve ir para opcode dispatch, acesso a globals e operacoes repetidas por frame; faults podem aceitar custo maior desde que esse custo seja pago so na excecao.
|
|
|
|
## Sugestao / Recomendacao
|
|
|
|
Fechar esta agenda com a seguinte linha:
|
|
|
|
- baseline alvo: "happy path com alloc rara e explicita", nao "zero alloc absoluto";
|
|
- prioridade imediata: reduzir copia/alocacao em `GET_GLOBAL` e nas operacoes de string mais frequentes do loop;
|
|
- strings constantes: custo de materializacao pago uma vez no carregamento/constant pool e depois preferencialmente referenciadas;
|
|
- strings dinamicas: custo inicial de criacao aceito em runtime, mas sem clones implicitos repetidos apos a primeira materializacao;
|
|
- `GET_GLOBAL`: nenhuma nova semantica publica; a reducao de copia deve vir de representacao interna e ownership dos tipos caros;
|
|
- ownership baseline: manter valores triviais por copia e mover payloads caros para representacoes por handle quando houver prova de pressao suficiente para justificar a complexidade;
|
|
- faults/logs: preservar clareza e determinismo, aceitando custo fora do caminho feliz;
|
|
- meta interna de engenharia: perseguir `zero alloc` no caminho feliz numerico e nos acessos quentes ja materializados, sem publicar isso como metrica de certificacao;
|
|
- instrumentacao canonica: medir `heap_used_bytes`, frequencia de GC e contagem de logs/faults no fim do frame, mantendo contadores de alocacao como metrica interna de engenharia, sem transformar o dispatch em microbenchmark intrusivo.
|
|
|
|
## Perguntas em Aberto
|
|
|
|
- Nenhuma no nivel arquitetural atual. A agenda pode ser encerrada quando esta direcao for promovida para decisao normativa.
|
|
|
|
## Dependencias
|
|
|
|
- `docs/specs/runtime/02a-vm-values-and-calling-convention.md`
|
|
- `docs/specs/runtime/03-memory-stack-heap-and-allocation.md`
|
|
- `docs/specs/runtime/10-debug-inspection-and-profiling.md`
|
|
|
|
## Criterio de Saida Desta Agenda
|
|
|
|
Pode virar PR quando houver decisao escrita sobre:
|
|
|
|
- caminho quente prioritario para desengordurar;
|
|
- meta minima de alocacao/copia da VM;
|
|
- estrategia de ownership para strings/values;
|
|
- instrumentacao canonica para medir regressao.
|
|
|
|
## Resolucao Proposta
|
|
|
|
- Strings continuam parte legitima da linguagem, mas sao tratadas como recurso potencialmente caro no baseline.
|
|
- Strings hardcoded podem pagar custo de materializacao uma vez no carregamento/constant pool.
|
|
- Strings dinamicas podem pagar custo inicial de criacao em runtime.
|
|
- A arquitetura deve evitar recopia de payload apos a primeira materializacao sempre que o caminho quente puder operar por referencia, handle ou ownership interno mais barato.
|
|
- `GET_GLOBAL` nao ganha nova semantica publica; qualquer reducao de copia deve vir de mudancas internas de representacao e processo.
|
|
- `Zero alloc no caminho feliz` e meta interna de engenharia do runtime, nao criterio publicado de certificacao.
|
|
- Faults e logs permanecem corretos e legiveis, mas nao dirigem a otimizacao principal.
|