Source   Edit  

The compiler's .bif loader: bif.load, except that a file's names stay in the mapping until they are read.

bif.load borrows the token block from the mapping but copies every string, symbol and filename out of it into the buffer's pools. A backend process opens ~800 .bif files and reads names from a fraction of them: on nimbus-eth2 that was 2.9M strings, 222MB, 41% of the process's heap (--mm:refc -d:nimTypeNames). load here gives each pool its ids — an empty entry per name, so the ids line up with the token stream — and keeps per pool where each name's bytes sit in the mapping (LazyNames). A name is copied into the pool the first time it is read, and a lookup BY VALUE hashes and compares the mapped bytes, so nothing is copied to be found.

The pools are nifcore's, and nifcore's own symName(c), strVal(c), poolSym, poolStr and lineInfoFile(c) read a pool's entry directly: they answer "" for a name that has not been read yet. So a module that reads a loaded buffer imports nifcore except those five and uses the accessors here, which spell the same; importing both makes every call ambiguous, so the two cannot be mixed by accident. Nothing interns INTO a loaded pool — a loaded buffer is read-only — and nothing may: nifcore's getOrIncl would build its reverse index over the empty entries.

The symbol pool is the one that cannot be filled entry-for-entry: nifcore stores a symbol TAKEN APART (NifSymbol, three StrIds into p.strings), and re-interning those components would hash a pool that is still all placeholders. fillSym puts the spelling back whole instead — see there.

-d:icEagerPools makes load the plain bif.load, for an A/B; the accessors work on an eager pool as they do on any other.