ProcessWire runtime page cache: safe boundary for $pages->uncache() when other loaded pages reference the target

Runtime page cache in batch scripts

In a long-running ProcessWire CLI script (an import that iterates thousands of pages via $pages->get() and $pages->find()), memory grows steadily because every loaded Page object is retained in the runtime page cache for the lifetime of the request. The documented mitigation is $pages->uncache($page) or periodic $pages->uncacheAll() calls, but I cannot find a documented constraint for one specific situation.

The missing constraint

Many of the pages I load are referenced by other still-loaded pages: as parents, as page-reference field targets, or as children already iterated. The documentation does not state whether uncaching such a page is safe — whether dependent code silently triggers a fresh database reload, or whether remaining references keep the instance alive anyway, negating the memory saving. There also appears to be no documented cache size limit or eviction policy to rely on instead.

Assume ProcessWire 3.x; I will confirm method signatures against wire/core/Pages.php in my installed copy.

Questions

• Is it safe to call $pages->uncache() on a page that other loaded pages still reference, and what actually happens on next access — silent reload or stale instance?
• Does uncacheAll() mid-loop meaningfully reduce memory when live references remain, or is selector pagination with limit= the only reliable bound?
• Is there a documented way to inspect or cap the page cache size?