PON-BEAM: um paradigma orientado a notificações dentro da máquina virtual do Erlang
1.
A pergunta que move este projeto Todo programador Elixir ou Erlang já ouviu o mantra: "a BEAM é uma máquina virtual altamente concorrente, com milhões de processos leves, trocas de contexto em microsegundos e escalabilidade quase linear".
E isso é verdade — para o modelo de programação.
Mas quando você abre o código em C da ERTS (Erlang Run-Time System) e olha como a máquina funciona por dentro, encontra uma surpresa: a BEAM é um motor híbrido.
Ela tem notificações para algumas coisas, mas ainda puxa (polling) e faz scans lineares em vários dos subsistemas mais críticos: Subsistema Mecanismo no BEAM stock (OTP 30) Custo seletivo Scan linear da mailbox (cada cláusula contra cada mensagem) $O(N \times M)$ Timers Timer wheel com ticks periódicos de polling O(1) por tick, mas a CPU nunca dorme Scheduler SMP Run-queue pollada / busy-spin quando ocioso 5–30% de um core desperdiçado Coletor de lixo Varredura de heap por raízes $O(\text{heap total})$ ETS Lookups com lock + busca contention na chave quente Esse é exatamente o tipo de problema que o Paradigma Orientado a Notificações (PON / NOP), criado pelo professor Dr.
Jean Marcelo Simão (UTFPR, 2005–2009), se propõe a eliminar: redundância temporal (reavaliações desnecessárias) e redundância estrutural (código de busca repetido).
O PON-BEAM (repositório: matheuscamarques/pon_beam) é uma re-arquitetura completa da BEAM onde todo subsistema interno vira uma entidade reativa PON: mensagens empurram notificações, em vez de a máquina puxar estados.
A tese central: Nenhum trabalho anterior aplicou o PON como princípio fundacional do motor da VM.
A literatura NOP implementa o paradigma em cima de plataformas existentes (C++, Java, FPGA, Erlang).
O PON-BEAM propõe o PON como o próprio design da máquina.
Este artigo explica, um a um, cada componente PON que foi integrado à VMBEAM — o que ele substitui, como foi implementado em C na ERTS, e quais ganhos empíricos o harness de benchmarks mediu.
2.
O paradigma PON em 5 minutos Antes de falar de cada componente, os conceitos básicos do PON: Entidade: qualquer elemento da aplicação (um processo Erlang, um scheduler, um objeto de heap) tratado como reativo e desacoplado.
Uma entidade contém dois tipos de elementos: FAD (Facts / dados): o estado da entidade.
FBE (Fundamental Behavior Element / procedimentos): o comportamento.
Premise: uma condição mínima sobre os fatos de uma entidade.
Ela só é avaliada quando notificada — e não periodicamente.
Ex.: "uma mensagem chegou na mailbox".
Condition: uma conjunção de Premises.
Quando todas as Premises de uma Condition estão satisfeitas, a Condition notifica uma Instigação.
Instigation: dispara a execução de um método (FBE) quando sua condição causal/temporal se torna verdadeira.
No PON-BEAM, os timers são Instigações temporais.
Notificação: o único mecanismo de colaboração entre entidades. É ponto-a-ponto (quem muda sabe quem deve ser avisado), reativa (só dispara quando o fato muda) e sem polling.
A inversão de controle é radical: no modelo imperativo clássico a entidade pergunta "o estado mudou?".
No PON, o estado muda e avisa quem o observa.
3.
A fundação: um overlay compilável sobre o OTP Antes de qualquer subsistema, a Fase 0 estabeleceu como o PON-BEAM existe junto do OTP stock.
As regras de ouro do projeto: Nunca tocar no baseline.
O OTP original vive imutável na branch .
Toda modificação C fica dentro de .
O código original permanece intacto — o PON-BEAM é um overlay compilável, não um fork divergente.
Um artefato por fase: um , um benchmark diferencial e uma telemetria.
Isso garante 100% de compatibilidade retroativa: o formato , a ABI de NIFs e o protocolo de distribuição não mudam.
Um mesmo pool de código compila (stock) ou (PON) dependendo do flag .
A telemetria da prova: Para medir que o comportamento reativo realmente aconteceu (e não só intuir), cada componente PON escreve contadores thread-local por sche