[RFC]: use POOL_ALLOC and POOL_FREE for objects with known lifetime in future.c

[albertnetymk]

The use of encore_alloc in actor_list *entry = encore_alloc(cctx, sizeof *entry); will ask for some memory from the current actor heap, and this memory will be managed by the GC protocol. However, the instant when this memory become collectable is statically know, the loop of iterating awaited_actors, in this case.

In other places of the runtime, POOL_ALLOC and POOL_FREE are used for objects with known lifetime, messageq and mpmcq are two examples. Therefore, I propose to replace all occurrences of encore_alloc in future.c with POOL_ALLOC & POOL_FREE in future.c.

The proposed change will simply the code, and reduce the floating garbage, for we don't need to wait for a GC cycle to reclaim the memory.

[supercooldave]

Your proposal says that you will replace all occurrences of encore_alloc by this pool allocation, but this assumes that you statically know when the future becomes garbage. In 90% of the cases, this may indeed be known. But what about the other cases?

Surely a better approach would be to have two allocation strategies, static and dynamic, one as suggested above for the cases when you statically know, and one for cases where you don't.

[kikofernandez]

@supercooldave @albertnetymk is proposing a change that does NOT affect all occurrences of encore_alloc, but the ones that are located in future.c. More concretely, only the ones that refer to the actor_list field in the future structure in the loop that picks up awaiting actors (they were chained). As far as I can see, we always know when this memory can be collected.

[TobiasWrigstad]

I am in favour of this change. Good thinking @albertnetymk.

[albertnetymk]

I had a quick discussion with Noa on his working on futures, and in his optimized future implementation, all changes I proposed above have been addressed. I will keep this one open until the merging of his work.