Agenda - [PERF] Cartridge Boot and Program Ownership

Problema

O bootstrap do cart ainda faz copia desnecessaria de dados grandes e de metadados que poderiam ter ownership mais claro.

Hoje initialize_vm() clona program, title, app_version e entrypoint ao carregar o cart. Isso nao e o maior gargalo em steady-state, mas sinaliza que ownership de boot ainda esta frouxo.

Dor

reload, troca de cart e cenarios de tooling pagam custo desnecessario.
ownership frouxo no boot tende a reaparecer em hot-reload, debugger e loader.
em hardware pequeno, boot "barato" tambem importa.

Hotspots Atuais

lifecycle.rs

Alvo da Discussao

Fechar um modelo de ownership de cart/programa que reduza copias sem comprometer simplicidade ou seguranca do runtime.

O Que Precisa Ser Definido

Ownership do programa. Decidir se o bytecode:
- e movido para a VM;
- e compartilhado por Arc;
- e mantido no cart com view emprestada.
Ownership de metadata. Delimitar o que precisa ser copiado para estado corrente do runtime e o que pode ser referenciado.
Ciclo de vida. Definir como ownership funciona em:
- boot inicial;
- troca de cart;
- debugger/reload;
- run-cart futuro.
Meta de boot. Fechar qual custo de inicializacao e aceitavel para o baseline.

Open Questions de Arquitetura

O projeto quer boot otimizado para trocas frequentes ou apenas para cold start?
Existe risco real de aliasing/perigo de lifetime ao evitar copias aqui?
Vale aceitar copia de metadata pequena e atacar so program?

Dependencias

../specs/13-cartridge.md
../specs/14-boot-profiles.md
009-system-run-cart.md

Criterio de Saida Desta Agenda

Pode virar PR quando houver decisao escrita sobre:

ownership canonico de program;
politica de copia/referencia para metadata de cart;
comportamento em reload/troca de cart;
meta de custo para boot e reinicializacao.

2.1 KiB Raw Blame History