You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2007/03/12 17:05:13 UTC
[drlvm][threading] H3010 (Stack Overflow Exception) -- when does this bug really have to be fixed?
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
Re: [drlvm][threading] H3010 (Stack Overflow Exception) -- when does this bug really have to be fixed?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Mar 12, 2007, at 4:35 PM, Weldon Washburn wrote:
>>
>> that has some relevence to the -Xss option. If we implement it,
>> almost
>> any "popular workload" would crash in SEGV instead of throwing SOE
>> properly when run on a small stack size.
>>
>> One might argue that running a "popular workload" with a small stack
>> size makes the workload "not so popular". I dunno.
>
>
> I understand your argument. It makes perfect sense. But the question
> remains. Is this a bug that has to be fixed in Q2 or in 2008? Is it
> acceptable to simply bump up the stack size to get Q2 workloads
> running?
What's a "Q2 workload"?
I do think that this is important if people are going to start
trusting harmony as being predictable and stable. Yes, we can
predict that it will SEGV, but there is no "java.lang.SEGV" to catch
and handle :)
geir
Re: [drlvm][threading] H3010 (Stack Overflow Exception) -- when does this bug really have to be fixed?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x297 day of Apache Harmony Weldon Washburn wrote:
> On 12 Mar 2007 21:52:45 +0300, Egor Pasko <eg...@gmail.com> wrote:
> >
> > On the 0x297 day of Apache Harmony Weldon Washburn wrote:
> > > On 12 Mar 2007 19:46:06 +0300, Egor Pasko <eg...@gmail.com> wrote:
> > > >
> > > > On the 0x297 day of Apache Harmony Weldon Washburn 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.
> > > >
> > > > to be honest..
> > > >
> > > > SOE can happen from a 'push' onto stack (such pushes are not
> > > > safepoints in JIT currently). Thus, you cannot unwind properly (no M2N
> > > > necessary for releasing the lock).
> > > >
> > > > Do you think it is a low probability?
> > >
> > >
> > > Good point. Yes, SOE can happen from jitted code doing stuff like "push
> > > ebp". And we have to handle this case properly. And it will require a
> > > design discussion between JIT and VM developers. This is really
> > interesting
> > > topic. But the question remains. Do we have to solve this issue in Q1?
> > > Q4? 2008?? To answer this question, we have to ask what workloads we
> > want
> > > to run in Q1/Q2/Q3... And then find out if the workloads hit the SOE
> > > problem we are discussing. My guess is that if useful workloads we want
> > to
> > > run actually hit SOE, we will be able to workaround it by simply making
> > the
> > > stack a little bigger. Also my guess is that Java compatibility tests
> > > (tck?) will specifically test this case. In other words, its probably
> > > needed for compliance but not really needed for getting important
> > workloads
> > > running.
> >
> > that has some relevence to the -Xss option. If we implement it, almost
> > any "popular workload" would crash in SEGV instead of throwing SOE
> > properly when run on a small stack size.
> >
> > One might argue that running a "popular workload" with a small stack
> > size makes the workload "not so popular". I dunno.
>
>
> I understand your argument. It makes perfect sense. But the question
> remains. Is this a bug that has to be fixed in Q2 or in 2008? Is it
> acceptable to simply bump up the stack size to get Q2 workloads running?
Weldon, I should agree with you, this is not Q2/07 according to our
Q2_milestone draft. But I would address this issue not later than
Q4/2007 because it affects important design decisions that should be
implemented _before_ any attempt to pass serious conformance tests.
Now I tend to think that milestoning is not a perfect thing. There is
a pretty cool agile approach that might be more effective for us (and
what Geir probably talks about):
1. regularly update the TODO list
2. prioritize it, agree on priorities in the project-wide
3. assign highest priority tasks to people (keep the list of task-to-person on Wiki)
4. set requirements for the next release (according to the list of assignments)
5. when these tasks are finished and integrated we fire up the release
6. goto 1.
maybe, new thread for this?
> > > 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?
> > > >
> > > > --
> > > > Egor Pasko
> > > >
> > > >
> > >
> > >
> > > --
> > > Weldon Washburn
> > > Intel Enterprise Solutions Software Division
> >
> > --
> > Egor Pasko
> >
> >
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
--
Egor Pasko
Re: [drlvm][threading] H3010 (Stack Overflow Exception) -- when does this bug really have to be fixed?
Posted by Weldon Washburn <we...@gmail.com>.
On 12 Mar 2007 21:52:45 +0300, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x297 day of Apache Harmony Weldon Washburn wrote:
> > On 12 Mar 2007 19:46:06 +0300, Egor Pasko <eg...@gmail.com> wrote:
> > >
> > > On the 0x297 day of Apache Harmony Weldon Washburn 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.
> > >
> > > to be honest..
> > >
> > > SOE can happen from a 'push' onto stack (such pushes are not
> > > safepoints in JIT currently). Thus, you cannot unwind properly (no M2N
> > > necessary for releasing the lock).
> > >
> > > Do you think it is a low probability?
> >
> >
> > Good point. Yes, SOE can happen from jitted code doing stuff like "push
> > ebp". And we have to handle this case properly. And it will require a
> > design discussion between JIT and VM developers. This is really
> interesting
> > topic. But the question remains. Do we have to solve this issue in Q1?
> > Q4? 2008?? To answer this question, we have to ask what workloads we
> want
> > to run in Q1/Q2/Q3... And then find out if the workloads hit the SOE
> > problem we are discussing. My guess is that if useful workloads we want
> to
> > run actually hit SOE, we will be able to workaround it by simply making
> the
> > stack a little bigger. Also my guess is that Java compatibility tests
> > (tck?) will specifically test this case. In other words, its probably
> > needed for compliance but not really needed for getting important
> workloads
> > running.
>
> that has some relevence to the -Xss option. If we implement it, almost
> any "popular workload" would crash in SEGV instead of throwing SOE
> properly when run on a small stack size.
>
> One might argue that running a "popular workload" with a small stack
> size makes the workload "not so popular". I dunno.
I understand your argument. It makes perfect sense. But the question
remains. Is this a bug that has to be fixed in Q2 or in 2008? Is it
acceptable to simply bump up the stack size to get Q2 workloads running?
> > 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?
> > >
> > > --
> > > Egor Pasko
> > >
> > >
> >
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
>
> --
> Egor Pasko
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm][threading] H3010 (Stack Overflow Exception) -- when does this bug really have to be fixed?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x297 day of Apache Harmony Weldon Washburn wrote:
> On 12 Mar 2007 19:46:06 +0300, Egor Pasko <eg...@gmail.com> wrote:
> >
> > On the 0x297 day of Apache Harmony Weldon Washburn 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.
> >
> > to be honest..
> >
> > SOE can happen from a 'push' onto stack (such pushes are not
> > safepoints in JIT currently). Thus, you cannot unwind properly (no M2N
> > necessary for releasing the lock).
> >
> > Do you think it is a low probability?
>
>
> Good point. Yes, SOE can happen from jitted code doing stuff like "push
> ebp". And we have to handle this case properly. And it will require a
> design discussion between JIT and VM developers. This is really interesting
> topic. But the question remains. Do we have to solve this issue in Q1?
> Q4? 2008?? To answer this question, we have to ask what workloads we want
> to run in Q1/Q2/Q3... And then find out if the workloads hit the SOE
> problem we are discussing. My guess is that if useful workloads we want to
> run actually hit SOE, we will be able to workaround it by simply making the
> stack a little bigger. Also my guess is that Java compatibility tests
> (tck?) will specifically test this case. In other words, its probably
> needed for compliance but not really needed for getting important workloads
> running.
that has some relevence to the -Xss option. If we implement it, almost
any "popular workload" would crash in SEGV instead of throwing SOE
properly when run on a small stack size.
One might argue that running a "popular workload" with a small stack
size makes the workload "not so popular". I dunno.
> > 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?
> >
> > --
> > Egor Pasko
> >
> >
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
--
Egor Pasko
Re: [drlvm][threading] H3010 (Stack Overflow Exception) -- when does this bug really have to be fixed?
Posted by Weldon Washburn <we...@gmail.com>.
On 12 Mar 2007 19:46:06 +0300, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x297 day of Apache Harmony Weldon Washburn 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.
>
> to be honest..
>
> SOE can happen from a 'push' onto stack (such pushes are not
> safepoints in JIT currently). Thus, you cannot unwind properly (no M2N
> necessary for releasing the lock).
>
> Do you think it is a low probability?
Good point. Yes, SOE can happen from jitted code doing stuff like "push
ebp". And we have to handle this case properly. And it will require a
design discussion between JIT and VM developers. This is really interesting
topic. But the question remains. Do we have to solve this issue in Q1?
Q4? 2008?? To answer this question, we have to ask what workloads we want
to run in Q1/Q2/Q3... And then find out if the workloads hit the SOE
problem we are discussing. My guess is that if useful workloads we want to
run actually hit SOE, we will be able to workaround it by simply making the
stack a little bigger. Also my guess is that Java compatibility tests
(tck?) will specifically test this case. In other words, its probably
needed for compliance but not really needed for getting important workloads
running.
> 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?
>
> --
> Egor Pasko
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm][threading] H3010 (Stack Overflow Exception) -- when does this bug really have to be fixed?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x298 day of Apache Harmony Gregory Shimansky wrote:
> Egor Pasko wrote:
> > On the 0x297 day of Apache Harmony Weldon Washburn 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.
> > to be honest..
> > SOE can happen from a 'push' onto stack (such pushes are not
> > safepoints in JIT currently). Thus, you cannot unwind properly (no M2N
> > necessary for releasing the lock).
> > Do you think it is a low probability?
>
> If SOE happens in managed code it is handled similar to hardware NPEs,
> that is the stack is unwound to the exception handler if it exists or
> to the nearest native frame. AFAIK hardware NPE places are not
> safepoints too, so there is a small possibility for enumeration bugs
> in such places.
yes, you are right. Still hardware NPEs are disabled for
a) try..catch regions
b) synchronized methods (VM needs jit_get_address_of_this)
Okay, I should agree that both (a) and (b) are not likely to hit SOE
on "popular workloads". And, AFAIR, we have both bugs in JIRA, so, all
is going fine. Let's think of them as having low probability.
> >> 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?
> >
>
>
> --
> Gregory
>
>
--
Egor Pasko
Re: [drlvm][threading] H3010 (Stack Overflow Exception) -- when does
this bug really have to be fixed?
Posted by Gregory Shimansky <gs...@gmail.com>.
Egor Pasko wrote:
> On the 0x297 day of Apache Harmony Weldon Washburn 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.
>
> to be honest..
>
> SOE can happen from a 'push' onto stack (such pushes are not
> safepoints in JIT currently). Thus, you cannot unwind properly (no M2N
> necessary for releasing the lock).
>
> Do you think it is a low probability?
If SOE happens in managed code it is handled similar to hardware NPEs,
that is the stack is unwound to the exception handler if it exists or to
the nearest native frame. AFAIK hardware NPE places are not safepoints
too, so there is a small possibility for enumeration bugs in such places.
>> 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?
>
--
Gregory
Re: [drlvm][threading] H3010 (Stack Overflow Exception) -- when does this bug really have to be fixed?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x297 day of Apache Harmony Weldon Washburn 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.
to be honest..
SOE can happen from a 'push' onto stack (such pushes are not
safepoints in JIT currently). Thus, you cannot unwind properly (no M2N
necessary for releasing the lock).
Do you think it is a low probability?
> 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?
--
Egor Pasko
Re: [drlvm][threading] H3010 (Stack Overflow Exception) -- when does this bug really have to be fixed?
Posted by Weldon Washburn <we...@gmail.com>.
On 3/12/07, Rana Dasgupta <rd...@gmail.com> 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 <we...@gmail.com> 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
Re: [drlvm][threading] H3010 (Stack Overflow Exception) -- when does this bug really have to be fixed?
Posted by Rana Dasgupta <rd...@gmail.com>.
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 <we...@gmail.com> 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
>