{"id":160720,"date":"2026-02-12T17:11:59","date_gmt":"2026-02-12T15:11:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-yazyke-nim-predstavlen-yrc-potokobezopasnyj-sborshhik-cziklicheskih-ssylok"},"modified":"2026-02-12T17:11:59","modified_gmt":"2026-02-12T15:11:59","slug":"v-yazyke-nim-predstavlen-yrc-potokobezopasnyj-sborshhik-cziklicheskih-ssylok","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/v-yazyke-nim-predstavlen-yrc-potokobezopasnyj-sborshhik-cziklicheskih-ssylok","title":{"rendered":"Nel linguaggio Nim \u00e8 stato introdotto YRC \u2014 un raccoglitore di riferimenti ciclici thread-safe","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Andreas Rumpf (Araq), autore del linguaggio di programmazione Nim, ha annunciato un nuovo algoritmo di gestione della memoria chiamato YRC (pronunciato \"Urc\"), che risolve uno dei problemi chiave dei meccanismi esistenti in Nim: l'incapacit\u00e0 di gestire correttamente i riferimenti ciclici che attraversano i confini dei thread. <\/p>\n
Prima dell'introduzione di YRC, gli algoritmi di gestione della memoria proposti in Nim presentavano i seguenti limiti: ARC \u2014 non supportava la multithreading e la gestione dei cicli; Atomic ARC \u2014 era sicuro per i thread, ma non gestiva i riferimenti ciclici; ORC \u2014 gestiva i riferimenti ciclici, ma poteva farlo correttamente solo all'interno di un singolo thread (le perdite di memoria si verificavano quando si utilizzavano riferimenti condivisi tra thread). <\/p>\n
Il YRC proposto combina la sicurezza dei thread e la gestione dei cicli tra thread, utilizzando un approccio combinato: per i dati aciclici si applica il conteggio atomico dei riferimenti, mentre per i ciclici si utilizza una barriera di scrittura, che si attiva soltanto durante l'assegnazione dei puntatori. Nella sua implementazione: il raccoglitore viene avviato secondo necessit\u00e0 (senza pause stop-the-world); gli oggetti radice RC sono definiti esplicitamente e uniti una sola volta (non \u00e8 necessaria la scansione degli stack dei thread); si evita la rimozione multithread durante l'iterazione (non \u00e8 presente una fase globale di sweep); i mutatori possono leggere liberamente i dati; qualsiasi thread pu\u00f2 avviare il garbage collector se necessario (senza un thread GC dedicato). <\/p>\n
Il YRC utilizza informazioni complete sugli eventi incRef\/decRef, che i tradizionali garbage collector a tracing scartano e devono poi recuperare attraverso la scansione degli stack e l'attraversamento del grafo. L'implementazione richiede solo 550 righe di codice e ha una verifica formale di sicurezza e assenza di deadlock tramite specifiche in TLA+ e prove nel toolkit Lean. Il YRC \u00e8 posizionato come \"quasi l'ultimo garbage collector basato sul conteggio dei riferimenti\" (la lettera Y precede la Z nell'alfabeto), oltre a essere il garbage collector pi\u00f9 semplice e sicuro per i thread \u2014 secondo l'autore, non richiede molti dei complessi meccanismi tipici dei tradizionali garbage collector a tracing. <\/p>\n
YRC offre la stessa API di ORC, con l'esecuzione dei distruttori durante la raccolta dei rifiuti. Il raccoglitore gestisce solo i sottografi di oggetti con cui lavorano i thread, senza toccare le strutture dati non correlate (cache, oggetti a lungo termine) \u2014 un approccio simile a quello di un \u00abideale\u00bb raccoglitore generazionale senza l'uso delle generazioni. L'interruzione principale riguarda le prestazioni: YRC mostra un rallentamento di 1.5-2.0 volte rispetto a ORC nel test di prestazioni orcbench. L'autore considera questo un prezzo accettabile per il trattamento completamente thread-safe dei riferimenti circolari. <\/p>\n
YRC \u00e8 gi\u00e0 disponibile nella versione di sviluppo di Nim e si attiva con il flag \u00ab--mm:yrc\u00bb. Tuttavia, nei messaggi successivi, l'autore ha riconosciuto che l'implementazione iniziale conteneva gravi errori e non gestiva correttamente i cicli. Al momento della pubblicazione \u00e8 stato preparato un insieme di correzioni che risolvono i principali errori. L'autore continua a ottimizzare le euristiche di raccolta e a correggere gli errori rimanenti, mantenendo comunque l'algoritmo di base e la sua verifica formale corretti. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"