Async deinit: Optimization Goals

[Nickolas_Pohilets (Nickolas Pokhylets)]

It's await Task.yield() which creates back-pressure, not Task.sleep(). Sleep is there is to make deallocation even slower. It models some async shutdown activity in the deinit body.

Back-pressure is applied towards allocation of the new objects. Bounding memory usage is achieved by pausing new allocations until already scheduled deallocations are not processed. If used correctly, executors already provide this functionality. And "used correctly" means two things:

• Producing code eventually yields execution
• Deallocating tasks have equal or greater priority than allocating tasks.

Current implementation of the isolated deinit copies priority of the task that executed last deinit. If objects are allocated in high-priority task, but last release happens in low-priority task, this might be a problem. Maybe solution for both isolated and async deinit would be to remember inside the object priority of the task that allocated it, WDYT?

@kavon

For example, suppose the synchronous deinit thunk wrapping the async deinit could recognize when its immediate caller is an async function. The thunk maybe could do a little dance to pop its own frame and push an async frame on top of the task's stack to execute the body of the async deinit, so we can avoid creating a detached task by effectively awaiting the deinit. But if the caller is synchronous, we cannot await, so we're forced to create a detached task and we're back at the same problem.

I was considering this in detail in separate post. Basically this makes code very hard to reason about. There are lots of sync frames inside the async function, often generated by the compiler. Which may be inlined or not.