-
Notifications
You must be signed in to change notification settings - Fork 4
Description
I appreciate the ABI decisions of GCC, but with coroutines, I expect that we will get A LOT of exceptions stored per thread than previous expected. If we have 15 coroutines tasks in a thread and 10 of them throw, we need the storage to handle all of that.
With the policy to over allocate to hold the exception header, we end up sending a LOT of memory per exception to their own dedicated header. But why not just statically allocate the header and allocate separately? There should only be ONE unhandled exception per thread so why not have a single header for each thread. It does use up memory if you never throw, but the benefit is that the allocations will be the size of your object plus the std::exception_ptr wrapper. It would be desirable to have the resource already be wrapped so copying them around does the correct ref counting.
So rather than spend 64 + sizeof(ThrowObject)
we spend 64 bytes for the header once and we only need an allocator for the thrown objects.
I'm certain this will worm because the header information is only really useful to get out of the sad path. Once out, the information here can be scrapped if another throw is performed. So anytime we re-enter the exception flow, we can scrap what exists and simply get the latest state of the CPU.
We make this thread local because each thread will need its own exception header object. A potentially nasty alternative would be to have the app devs provide memory for headers separate from the exceptions themselves. If you only had 3 slots of exception header and those are full, then you'd block until one of the slots frees up. This may be useful in some constrained situations. We shall see what seems to work and work accordingly. 64 bytes per thread might not be too bad.
Finally, we need to figure out how to plug into the TLS support in GCC.