On Mon, May 11, 2026 at 11:11:04AM +0800, Qian Yun wrote:
> On 5/10/26 10:50 PM, Qian Yun wrote:
> >
> > But we can have the best of both worlds: when the array cache
> > needs to expand (or hitting some threshold, or triggered manually),
> > use sb-ext:make-weak-pointer on the kernels, do a GC,
> > create the smaller cache again. I'll report back.
> >
> > - Qian
> >
>
> Naively using weak pointer will get trouble, this might also
> explain the errors met by the previous hashtable approach:
> say you are doing integrals, the program may just construct
> a useful kernel, and enter it to cache, but it is not referenced
> by any expression, then it can get recycled by GC, causing
> failures later.
I do not think this is a problem. Either kernel is reachable
from some variable (possibly local variable in a function) or
is useless. GC should not collect things reachable from
variables. Of course, weak pointer should be used for
reference from kernel cache to actual kernel. All other
places should just work with kernels.
A different problem needs to be handled: GC can happen
essentially at any time and cause kernel to "vanish".
But binary search uses comparisons so needs something
to work correctly (linear search could just skip
dangling weak pointers).
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/agFQUwtmLmDF1s2X%40fricas.org.
