On 5/11/26 11:43 AM, Waldek Hebisch wrote: > 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). >
OK, maybe you are right. The failure I saw happens in "insertInCache". Maybe during "insertInCache", GC happens and "compactCache" is called and modifies cache array, causing "insertInCache" to fail. I'll try your "allow dangling weak pointers" idea. - Qian -- 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/c8d28b8d-c6a6-4cfd-b340-7a47bebe4e15%40gmail.com.
