languages such as Ada that have dynamically-sized values, including values returned as unconstrained array types, run a second stack in parallel, putting the dynamically-sized things on that. i suppose it's similar to Weinstein and Wulf's QuickFit (one very fast malloc strategy) but with stacked lifetimes.
On Sat, 19 Jul 2025 at 17:05, ron minnich <[email protected]> wrote: > Sorry, I got that confused, but I still believe that, clever or no, they > should just find a way to not use alloca. > > > > On Sat, Jul 19, 2025 at 8:53 AM Bakul Shah via 9fans <[email protected]> > wrote: > >> On Jul 19, 2025, at 8:02 AM, ron minnich <[email protected]> wrote: >> >> >> I'd argue that fixing Chez not to need alloca is a better approach. >> >> >> I believe it is *Chicken Scheme* that requires alloca() as it uses >> "Cheney on the MTA" garbage collection method that essentially allocates >> all *heap* objects on the *stack.* It is a very clever scheme (no pun >> intended) that handles tail recursion extremely well. From >> >> >> https://web.archive.org/web/20160630144131/http://home.pipeline.com/~hbaker1/CheneyMTA.html >> >> >> Since the C "stack" never contracts, we can allocate all of our closures >> and user data structures on this stack as automatic/dynamic/local data. All >> closures and user data structures whose sizes are known at compile time are >> statically allocated in the C "stack" frame; dynamic arrays and other data >> structures whose size is unknown at compile time can be allocated by C's >> alloca primitive (or equivalent), which also obtains space from the >> "stack".[3] >> <https://web.archive.org/web/20160630144131/http://home.pipeline.com/~hbaker1/CheneyMTA.html#fn3>Since >> our C "stack" is also the "heap", there is no distinction between stack and >> heap allocation. >> >> Since none of our C functions ever returns, the only *live* frame on >> this "stack" is the top one. However, within many of the dead frames will >> be found live closures and live user data objects. Eventually, the C >> "stack" will overflow the space assigned to it, and we must perform garbage >> collection. Garbage collection (GC) by copying is a relatively >> straight-forward process. There are a number of static roots, as well as >> the latest continuation closure, which is passed to the GC as an argument. >> (Forming an explicit continuation closure for the GC avoids the necessity >> of scanning C stack frames.) The live objects and live closures are all >> copied (and thereby condensed) into another area, so that execution can be >> restarted with a "stack" frame at the beginning of the C "stack" allocation >> area. >> >> >> So emulating alloca() with malloc() [I think Dough Gwyn did this a long >> time ago] kind of defeats the purpose. >> Most Scheme implementations don't rely on this trick. >> > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/Tcd29ad8a4559a4cf-Me761cd298a65132674bf0900> > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcd29ad8a4559a4cf-M27be034324bae613dfbef0fa Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
