Leopold Toetsch <[EMAIL PROTECTED]> writes:
So during a DOD run the trails of an IO PMC are found on the system
stack during trace_mem_block. The main problem seems to be, that gcc
uses 16-byte aligned stack frames by default.
*Ouch* I spend the whole Friday searching this unbound PMCs, but failed to find them, they seemed to be nowhere in the stack-frames. Now you found out that they aren't in a stack-frame.
Mainly the "solution"
-mpreferred-stack-boundary=2
indicates, that these PMCs are not alive in the current stack frame(s), which is good, but they shine through holes in uninitialized area out from previous frames into the current. So physically they are in the frame.
We should really rethink the statement "We will always walking the stack". The timely destruction needs to know for sure if an object is alive or not. The conservative stack-walking will not give you this information.
Thanks for this statement. My words :-)
The stackwalking was introduced to solve the infant mortality
problem.
Conclusion: Timely destruction and solving infant mortatility don't play together or are mutually exclusive - in the current approach.
Ok, then we need another solution for the infant mortality problem. The requirments for this are: - PMC should be traced exact (timely destruction requieres this) - allows recursive calls of run_core - should not be fooled by longjmp Furthermore the system should be simple and fast. For bonus points it should be portable.
Yep. Good summary. With one addition (that covers Benjamin's approach: PMC, that need timely destruction, should be traced exactly, which implies of course, that aggregates or such where these go in have the same requirements ...)
* Use C++ for the PMCs * mark all PMC values on the stack * use a liked list of frames
Mine still are:
* anchor early, anchor often (Larry Loffer)
meaning place e.g. new PMCs first in register, then initialize it
* if that's to cumbersome, disable DOD
* if that's suboptimal, use active anchoring to some root set linked list for temp PMCs (this is probably your second point above)
* hide this hacks for external/XS code inside some macros
Comments?
Always;-)
boe
leo
