MSVC EH: Partial x64 support #4
Conversation
…g std::terminate remove vcruntime hacks when converting to exception to error, do not rethrow if the catch handles errors, too
kinke
force-pushed
the
msvc_x64
branch
3 times, most recently
from
f28d365 to
3493e19
Compare
|
I've fixed a few bugs and added some comments... |
|
Realized just now, that this PR is against my branch ;-) |
There was a problem hiding this comment.
This function already exists as rt.util.container.xmalloc.
|
Oh right - that's too bad. The GC won't help here either, right? So the only 2 solutions are either building these structs at compile time or pre-allocating a reasonable chunk of memory and dying with an OutOfMemoryError (or just terminating) in case it doesn't suffice, correct? :/ And all of this because of these crappy 32-bit offsets for x64, dammit... |
|
I think the GC could work, but the base pointer needs to be saved in the exception stack, too. That would prevent premature collection. |
D exceptions are not created while being thrown, so it needs the dynamic type to generate the _ThrowInfo. It would have to be added to the ClassInfo or similar where it's accessible via virtual dispatch. In C++, it is just created with the throw statement. |
That's what I meant - a TypeDescriptor, CatchableType, CatchableTypeArray and _ThrowInfo for each |
I only just now realized what you meant - not freeing the previous block when growing. That sounds like the most straight-forward approach to me, and the total memory consumption should be manageable, especially in times where even smartphones have Gigabytes of memory. ;) |
rainers
force-pushed
the
catch_cleanup_exceptions
branch
from
f0d795f to
7484da5
Compare
2 participants
Everything starting from
struct FrameInfo, especially the inline assembly parts, still needs to be done.Not tested at all, except for basic compilability. :]