[RFC]: use `POOL_ALLOC` and `POOL_FREE` for objects with known lifetime in future.c
albertnetymk opened this issue · comments
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.
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.
@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.
I am in favour of this change. Good thinking @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.