The chunk pool assets reside in.
The number of resident assets.
The underlying chunk pool.
The asset to check.
True if the asset is resident.
The asset to query.
The asset's physical (chunk-rounded) resident bytes (0 if absent).
The asset to query.
The asset's current reference count (0 if absent).
Drop a reference on an asset. On the last reference (1→0) the asset's chunks return to the pool and the caller should discard the payload.
The asset to release.
True if this was the last reference (asset freed).
Take a reference on an asset, acquiring chunks for it if it is not yet
resident. All-or-nothing: returns false (and changes nothing) only when
the asset is absent and the pool can't fit it — the caller's cue to evict
and retry. A wasAbsent result of true tells the caller to materialise
the payload into the asset's chunks (the 0→1 transition).
The asset to reference.
Its payload size (used only on first residency).
Whether the reference was taken, and whether this was the residency-creating reference.
Refcounted assets resident in a ChunkedPool — the sharing layer of the memory system (see
src/core/mem/).The general relationship this models: many instances reference shared assets (the definition/occurrence split that recurs across CAD — STEP AP214 literally names it occurrence). Concretely for geometry: products are instances, representation geometry is the asset, and mapped items make many products share one representation. But nothing here is geometry-specific — an asset is any refcounted, chunk-resident payload (a parsed property block, a decoded sidecar, a texture).
Storage is keyed and refcounted on the asset, so the correctness rule for shared data falls out structurally: releasing one instance's reference never frees an asset another instance still holds; chunks return to the pool only on the last release. (Evicting product A must not free the representation product B still renders — the mapped-item bug a per-instance store invites.)
Instance-level bookkeeping (which assets an instance holds, demand priorities, eviction order) belongs to the layer above — see
GeometryTilePoolfor the geometry narrowing andDemandGeometryQueuefor the scheduling policy.