Questa pagina è tradotta dalla documentazione inglese. Comandi, identificatori ed esempi restano invariati. Runtime 7.24.4 · SDK 2.6.7. Testo inglese

Uso della memoria

Stato: attuale

Ambito: stato attuale

Ultima revisione: 2026-09-13

Responsabile: runtime di ax-code

AX Code condivide la macchina con i language server, le build del repository, i browser e qualsiasi runtime di modello locale. Un server TypeScript o un analizzatore Rust può usare più memoria del backend di AX Code stesso. Quei processi forniscono analisi del codice; non sono servizi vocali. Sommare l’RSS dei processi può contare più di una volta le pagine condivise.

Profili

AX_CODE_MEMORY_PROFILE accetta auto (predefinito), low o normal. In auto, un host che riporta al massimo 8 GiB di RAM fisica seleziona low; gli altri host selezionano normal. I valori non validi usano il rilevamento automatico. Il rilevamento usa la RAM fisica dell’host, non la RAM libera né un limite di memoria del container; seleziona low in modo esplicito in una VM o in un container vincolato, quando serve. Imposta la variabile prima di avviare AX Code; non riconfigura un backend già in esecuzione.

AX_CODE_MEMORY_PROFILE=low ax-code

PowerShell:

$env:AX_CODE_MEMORY_PROFILE = "low"
ax-code

I language server partono su richiesta per impostazione predefinita in entrambi i profili. L’avvio e le letture ordinarie dei file non innescano il preriscaldamento semantico speculativo. La navigazione semantica esplicita, la diagnostica e l’indicizzazione avviano comunque l’analisi necessaria, quindi la prima richiesta semantica può richiedere più tempo. Per ripristinare il preriscaldamento speculativo di avvio e lettura su un host con margine adeguato, imposta entrambe le variabili prima dell’avvio:

AX_CODE_MEMORY_PROFILE=normal AX_CODE_LSP_PREWARM=1 ax-code

Solo il valore esatto 1 abilita il preriscaldamento speculativo; low lo sopprime sempre. I server esistenti non vengono terminati da questa impostazione, e non è un divieto globale di avvio LSP: le modifiche che richiedono diagnostica e le operazioni semantiche o di indicizzazione esplicite usano ancora i language server. Il recupero dell’inattività in modalità bassa resta separato.

La cache del sorgente ha anche un limite di 1,000 voci. La sua contabilità include un margine conservativo per stringhe e chiavi; non è un limite di heap V8 né di RSS. Un file che non entra sincronizza comunque l’intero contenuto corrente con il language server. Lo sfratto dalla cache non chiude un documento finché una richiesta può averne bisogno.

La modalità bassa mette il lavoro in coda invece di saltare l’analisi. Il primo uso, o l’uso dopo uno spegnimento per inattività, può richiedere più tempo. I client selezionati o in coda, le RPC sottostanti in attesa e le attese diagnostiche sono protetti dallo spegnimento per inattività. Una richiesta scaduta può lasciare in esecuzione lavoro lato server: due operazioni attese non garantiscono solo due calcoli dentro i language server. L’inventario diagnostico viene segnato come degradato dopo il recupero per inattività, perché riavviare un file non può provare la copertura completa del workspace precedente.

Questi limiti valgono dentro ogni processo di AX Code. Non limitano la RAM totale, non coordinano istanze separate di AX Code, non pongono un tetto agli heap dei language server e non controllano un compilatore, un browser o un modello locale. La selezione del modello, il contesto di prompt richiesto e i comandi di verifica restano invariati.

Conservazione di sessione e prove

La TUI conserva gli eventi pesanti della trascrizione per la sessione visualizzata. Le sessioni inattive conservano riepiloghi, stato e approvazioni o domande in attesa; aprendole si ricarica la cronologia salvata da SQLite. La finestra di visualizzazione normale è di 100 messaggi con un budget di payload serializzato di 16 MiB. I messaggi completi vecchi vengono rilasciati per primi. Il messaggio indivisibile più recente e la cronologia Undo/Restore recuperata possono superare il budget morbido; la TUI mostra un indicatore. Sono limiti di proiezione, non limiti sulla cronologia durevole della sessione o sul contesto del modello.

Quando l’heap V8 si avvicina al proprio limite rigido, il budget della trascrizione si restringe automaticamente (fino a un minimo di 2 MiB al 90% di uso dell’heap) così l’insieme trattenuto si alleggerisce prima che il processo raggiunga FatalProcessOutOfMemory; oltre l’80% la TUI mostra anche un avviso che suggerisce /compact o un riavvio. La pressione si recupera dopo un GC completo, ma la cronologia già sfrattata resta assente finché non viene ricaricata.

Le parti che arrivano prima del messaggio genitore usano un’area in attesa limitata (128 ID di messaggio / 1 MiB). Se il contenuto in attesa deve essere rilasciato, la TUI offre un ricaricamento dalla cronologia salvata. Gli eventi tardivi per messaggi sfrattati non possono ricreare in modo permanente parti orfane.

La cache delle prove usa per impostazione predefinita memoria limitata (128 voci / 4 MiB di valori serializzati per istanza). RocksDB resta facoltativo; cambiare solo il backend della cache non riduce le chiamate di strumenti del modello. Vedi Cache delle prove.

Output dei comandi in background

L’output in background non letto usa file transitori privati invece di trattenere stringhe JavaScript di molti megabyte per ogni shell terminata. Ogni file è un anello UTF-8 di 2 MiB; l’output non letto più vecchio oltre quel limite viene scartato ed etichettato. Fino a 32 file ad anello riservano al massimo 64 MiB per processo. Quando gli slot su disco sono pieni, lo spool terminato più vecchio può scadere; la proprietà delle shell attive non viene sfrattata. Le letture restituiscono in modo incrementale l’output non letto trattenuto e rilasciano il suo slot su disco.

Il registro consente 16 shell attive per sessione e 32 per processo, e conserva al massimo 16 record terminati per sessione / 64 per processo. L’output terminato scade dopo 30 minuti (controllato all’accesso e circa una volta al minuto). Gli elenchi di comando e descrizione sono anteprime limitate a 8 KiB / 1 KiB; il comando eseguito resta invariato. Il replay dell’osservatore ha limiti separati di 64 KiB e 128 record per shell, con un budget di byte di 2 MiB per l’intero processo; il replay incompleto è etichettato.

bash_output segnala l’integrità dell’output separatamente dallo stato di uscita reale del processo. L’output scartato, scaduto o illeggibile è una prova di verifica incompleta anche quando il comando è uscito con codice zero. Questi avvisi restano visibili quando si usa un filtro sull’output. Un record mancante può significare che è già stato consumato o sfrattato; l’output non disponibile non è la prova che un controllo sia passato.

I file usano una directory temporanea privata posseduta dal processo (0700) e file 0600 su POSIX. Letture, rimozione della sessione, pulizia della conservazione e uscita normale del processo rilasciano i file posseduti. Lo spool non è un archivio di sessione resistente ai crash. Una terminazione forzata o un crash può lasciare una directory temporanea privata; la pulizia automatica tra processi non è implementata, quindi il limite di 64 MiB descrive il processo corrente, non i residui accumulati dai crash. Gli errori di pulizia del filesystem vengono segnalati e non liberano la riserva di quota del file fallito. L’I/O su file sincrono e limitato evita code di scrittura illimitate, ma può aggiungere latenza su un filesystem temporaneo lento.

Scegliere un carico di lavoro

Per gli host vincolati, usa prima un provider cloud, una sola sessione di programmazione attiva e un repository piccolo. Esegui build grandi e sessioni di agente aggiuntive solo quando la macchina ha margine. L’inferenza locale richiede un budget separato per pesi, cache KV e contesto e overhead del runtime; la guida hardware dei provider cloud non si applica a essa.

Usa la CLI pacchettizzata per l’uso ordinario; pnpm run dev è un flusso di lavoro sul sorgente per chi contribuisce, con un costo diverso di avvio e caricamento dei moduli. Ispeziona AX Code insieme ai figli language server e di build in Activity Monitor o nel monitor dei processi della piattaforma. Un limite di cache ridotto non stabilisce una riduzione fissa della memoria fisica.

Le modifiche alla memoria hanno test deterministici di conservazione e di equivalenza semantica. Non sono state qualificate da un test di carico su un Mac fisico da 8 GB. La modalità bassa non garantisce che un progetto arbitrario entri in una macchina da 8 GB.