Am Do., 4. Aug. 2022 um 19:37 Uhr schrieb Marc Nieper-Wißkirchen <xxxxxx@gmail.com>:

Bradley Lucier <xxxxxx@math.purdue.edu> schrieb am Do., 4. Aug. 2022, 19:09:
On 8/4/22 9:19 AM, Marc Feeley wrote:
> It has the nice features of not adding pressure on the GC (no heap garbage generated) and being call/cc and thread “safe”.

Does Gambit not copy stack frames to the heap during a GC?

I agree that the default management of data on the stack is easier and
faster than managing data on the heap, but if enough stack frames are
pushed that a GC is triggered, then that data has to be managed somehow.

True, but even then using the stack still ensures locality.

PS For very large arrays, one can also always use a different algorithm. But which would be the best in each case is really dependent on the implementation. Some Schemes may even have a primitive to pre-allocate a large stack.

As for a (slightly) different algorithm:  If the vector to be mapped over is so large that the stack would overflow in Marc's/Gambit's implementation of `vector-map` (causing pressure on the GC), one could preallocate the result vector as in the naive algorithm and copy data chunk-wise from the stack into the vector.  After each chunk, the written part of the result vector is write-protected (using, e.g., `mprotect`).  When a protection violation is signaled, the algorithm enters a more complicated/possibly slower code path.  This would give the best of both worlds and would also address John's concerns.

Marc