90 lines
2.6 KiB
Markdown
90 lines
2.6 KiB
Markdown
# Agenda - VM-Owned Stateful Core
|
|
|
|
## Problema
|
|
|
|
O runtime ja tem VM-owned intrinsics read-only (input), mas ainda nao tem contrato canonico para recursos VM-owned stateful.
|
|
|
|
Sem esse core, cada novo servico tende a inventar:
|
|
|
|
- modelo proprio de handle/referencia;
|
|
- semantica propria de lifecycle;
|
|
- shape proprio de ABI/intrinsic;
|
|
- regras ad hoc de validacao/verifier.
|
|
|
|
## Alvo da Discussao
|
|
|
|
Fechar o contrato base de recursos VM-owned stateful que sera reutilizado por dominios como random, colecoes runtime-owned e futuros recursos de app model.
|
|
|
|
## O Que Precisa Ser Definido
|
|
|
|
1. Modelo de referencia stateful.
|
|
Definir:
|
|
- `HeapRef<TBuiltin>` como padrao ou alternativa canonica;
|
|
- regra anti-stale (generation/version);
|
|
- ownership e validade de referencia.
|
|
|
|
2. Lifecycle minimo.
|
|
Definir contrato de:
|
|
- `create`;
|
|
- `read/query`;
|
|
- `update`;
|
|
- `destroy`.
|
|
|
|
3. Execucao de intrinsic stateful.
|
|
Definir:
|
|
- como o executor recebe contexto VM/runtime;
|
|
- como manter compatibilidade com intrinsics atuais read-only.
|
|
|
|
4. ABI/meta por operacao.
|
|
Definir metadados obrigatorios:
|
|
- `arg_slots`;
|
|
- `ret_slots`;
|
|
- efeito;
|
|
- custo;
|
|
- determinismo.
|
|
|
|
5. Verifier/toolchain/disasm.
|
|
Definir:
|
|
- validacoes estaticas obrigatorias;
|
|
- regras de diagnostico para mismatch de assinatura/layout;
|
|
- compatibilidade binaria por versao.
|
|
|
|
6. Politica de fault/status.
|
|
Definir fronteira entre:
|
|
- `status` operacional de dominio;
|
|
- `Trap` estrutural;
|
|
- `Panic` por inconsistencia interna.
|
|
|
|
## Open Questions de Arquitetura
|
|
|
|
1. `HeapRef<TBuiltin>` sera obrigatorio para todos os recursos stateful?
|
|
2. Como evitar aliasing perigoso com multiplas referencias para o mesmo recurso?
|
|
3. Como roots/GC/lifetime se comportam para recursos vivos entre frames?
|
|
4. Quais gatilhos justificariam mecanismo simbolico adicional no futuro (alem de IDs finais)?
|
|
5. Qual contrato minimo de metadata precisamos versionar para garantir 1:1 FE/backend/runtime?
|
|
|
|
## Dependencias
|
|
|
|
- `../virtual-machine/ISA_CORE.md`
|
|
- `../specs/16-host-abi-and-syscalls.md`
|
|
- `../specs/16a-syscall-policies.md`
|
|
- `../specs/06-input-peripheral.md`
|
|
- `../decisions/003-vm-owned-byte-transfer-protocol.md`
|
|
|
|
## Fora de Escopo
|
|
|
|
- surface especifica de random (fica na agenda `012`);
|
|
- window/app model detalhado;
|
|
- redesign de `HOSTCALL`/`SYSCALL`;
|
|
- UX de linguagens de frontend.
|
|
|
|
## Criterio de Saida Desta Agenda
|
|
|
|
Pode virar PR quando houver decisao escrita sobre:
|
|
|
|
- contrato stateful VM-owned reutilizavel;
|
|
- forma definitiva de referencia/validade/lifecycle;
|
|
- metadados canonicos de ABI para intrinsic stateful;
|
|
- regras de verifier/disasm/compatibilidade binaria.
|
|
|