Weldon, It would be nice if exceptions in the fast native helper code paths could be treated as exceptions in unwindable ( jitted ) code. Though the test case is artificial, I think that this is a valid bug and could show up under stress. We could fail fast for now ( assert zero ) as you suggest and defer it till the fast path is written in java.
Thanks, Rana On 3/12/07, Weldon Washburn <[EMAIL PROTECTED]> wrote:
All, I assigned H3010 to myself. This test definitely demonstrates a bug that needs fixing. But its not clear when this bug must be fixed. This really brings forward a higher-level. What to code this bug right now and when would this bug be moved to "blocker" status? I provide some observations to start the discussion: 1) The bug is a Stack Overflow Exception happens from inside fast native helper functions. Fast native helpers do not setup the M2N stack frame which is required to throw exceptions such as SOE. Adding M2N setup to fast native helper will unacceptably slow down the system. 2) When running useful workload, a Stack Overflow that hits precisely on a fast native has a very low probability. Note the test in H3010 specifically forces this event to happen with a very high probability. In other words, while the test is a good, it reflects a very rare event in nature. Given the above, how about we address fixing the problem in two stages: 1) First stage: add an "assert(zero);" to the exception handler when it is determined an SOE has happened inside a fast native. This way, we will find out quickly when an important workload hits this bug. Once the assert(zero) is added, we code H3010 as "later" 2) Second stage: When an application we care about hits the assert(zero), we recode H3010 as "major/blocker". 3) While waiting for #2 above to happen, we discuss on harmony-dev ways of designing the right fix. For starts, I think we should investigate a design where the exception handler rewrites the entire register context so that returning from exception handler revectors the instruction pointer to recovery code that will somehow push the M2N frame on the stack and call proper SOE throwing code. I have not looked closely at how to do this. I am not convinced this approach will work. However, I do think its worth a try. Thoughts? -- Weldon Washburn Intel Enterprise Solutions Software Division
