[PERF] Cartridge Boot and Program Ownership

discussion/workflow/agendas/AGD-0014-perf-cartridge-boot-and-program-ownership.md

@@ -1,77 +0,0 @@
----
-id: AGD-0014
-ticket: perf-cartridge-boot-and-program-ownership
-title: Agenda - [PERF] Cartridge Boot and Program Ownership
-status: abandoned
-created: 2026-03-27
-resolved: 2026-04-20
-decision:
-tags: []
----
-
-# 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](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/console/prometeu-system/src/virtual_machine_runtime/lifecycle.rs#L125)
-
-## 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
-
-1. Ownership do programa.
-   Decidir se o bytecode:
-   - e movido para a VM;
-   - e compartilhado por `Arc`;
-   - e mantido no cart com view emprestada.
-
-2. Ownership de metadata.
-   Delimitar o que precisa ser copiado para estado corrente do runtime e o que pode ser referenciado.
-
-3. Ciclo de vida.
-   Definir como ownership funciona em:
-   - boot inicial;
-   - troca de cart;
-   - debugger/reload;
-   - run-cart futuro.
-
-4. Meta de boot.
-   Fechar qual custo de inicializacao e aceitavel para o baseline.
-
-## Open Questions de Arquitetura
-
-1. O projeto quer boot otimizado para trocas frequentes ou apenas para cold start?
-   R: o runtime precisa ser otimizado para trocas frequentes. o ciclo pode ser: 1. run prometeu que fica rodando como uma plataforma, podendo trocar carts durante seu funcionamento. 2. run cart direto, ai funciona como um jogo separado. mas o funcionamento do boot do cart deve ser o mesmo em ambos os casos.
-2. Existe risco real de aliasing/perigo de lifetime ao evitar copias aqui?
-   R: nao, o cart deve ser imutavel para o prometeu, de forma que este possa se tornar fonte da verdade. o grande vilao aqui eh remocao do cart no meio do runtime e coisas do tipo.
-3. Vale aceitar copia de metadata pequena e atacar so `program`? 
-   R: se nao me engano isso jah acontece com o asset_table, ele fica na memoria sempre depois do boot. e sim, eh completamente valido, isso o problema eh aceitar copia de tudo indiscriminadamente. 
-
-## 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.