concurrency: alloc an async-let task with the parent's allocator. #36993
Conversation
eeckstein
force-pushed
the
task-allocation
branch
from
2cdcb4a to
f61e959
Compare
eeckstein
changed the title
eeckstein
requested review from
rjmccall and
ktoso
and removed request for
ktoso
|
@swift-ci test |
| class alignas(2 * alignof(void*)) Job : | ||
| // For async-let tasks, the refcount bits are initialized as "immortal" | ||
| // because such a task is allocated with the parent's stack allocator. | ||
| public HeapObject { |
There was a problem hiding this comment.
nice, thanks for the comment!
| @@ -165,7 +164,13 @@ static void swift_asyncLet_endImpl(AsyncLet *alet) { | |||
| // TODO: we need to implicitly await either before the end or here somehow. | |||
|
|
|||
| // and finally, release the task and free the async-let | |||
There was a problem hiding this comment.
| // and finally, release the task and free the async-let | |
| // and finally deallocate the async-let |
no releasing anymore (yay!)
| static void destroyTask(SWIFT_CONTEXT HeapObject *obj) { | ||
| auto task = static_cast<AsyncTask*>(obj); | ||
|
|
||
| task->~AsyncTask(); |
There was a problem hiding this comment.
no idea if doing a destructor is nicer... am I missing something?
so far we've mostly had all destroyX things explicitly (but I'm by no means C++ or this codebase guru...)
There was a problem hiding this comment.
I think it's a matter of taste
| static AsyncTaskAndContext swift_task_create_group_future_commonImpl( | ||
| JobFlags flags, TaskGroup *group, | ||
| const Metadata *futureResultType, | ||
| FutureAsyncSignature::FunctionType *function, | ||
| void *closureContext, bool owningClosureContext, | ||
| void *closureContext, bool isAsyncLetTask, | ||
| size_t initialContextSize) { |
There was a problem hiding this comment.
ABI wise my impression was we wanted something like [TaskCreateRecords] to be passed in and e.g. check their .kind == .isAsyncLet or similar to be future proof about adding more smarts to creating tasks.
But maybe we want to do that in a separate PR? (totally find by me to do later on!)
There was a problem hiding this comment.
yeah, let's do that in a separate PR
| &completeTask); | ||
| assert(parent); | ||
| void *initialSlab = (char*)allocation + amountToAllocate; | ||
| _swift_task_alloc_initialize_with_slab(task, initialSlab, initialSlabSize); |
There was a problem hiding this comment.
cool! so even a bunch of tiny task-local allocs inside the child have a chance to stay in the initial slab... <3
|
Build failed |
|
This PR needs #37010 to land first |
…ator. Also, do this for the initial slab for the task's allocator itself. This avoids memory allocations for async-lets. In case the async-task's memory demand does not exceed the initial slab size, it is now completely malloc-free. The refcount bits of an async-let task are initialized to "immortal" so that ARC operations don't have an effect on the task.
eeckstein
force-pushed
the
task-allocation
branch
from
f61e959 to
075ad87
Compare
|
@swift-ci test |
|
Build failed |
|
@swift-ci smoke test macOS |
1 similar comment
|
@swift-ci smoke test macOS |
Also, do this for the initial slab for the task's allocator itself.
This avoids memory allocations for async-lets.
In case the async-task's memory demand does not exceed the initial slab size, it is now completely malloc-free.
The refcount bits of an async-let task are initialized to "immortal" so that ARC operations don't have an effect on the task.