On 3/12/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
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.
hmm... interesting concept. It might actually be easier/better for the JIT to solve this problem. Simply as the JIT to treat this code as it would any other JIT emitted code. We need to have a Harmony discussion with the JIT developers on this one. I will add a comment to the JIRA. 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 >
-- Weldon Washburn Intel Enterprise Solutions Software Division
