Improper usage of CHECK macros generates unreachable code

[Volker Simonis]

Ok, from this discussion I've learned that an automatic solution (i.e.
a script which changes every CHECK macro in a return statement into
either THREAD or introduces a temporary variable) is not the optimal
way to go.

Instead we should have a look at every single method which uses the
check macro in a return statement:
- if it only has callers which check for pending exceptions themselves
we can safely replace CHECK with THREAD. This would eliminate the
unreachable code and allow the compiler to emit tail calls.
- if it has callers which don't check for pending exception, we should
introduce a temporary variable.

Is this ok?

I'll start a changeset and post a webrev once I'm done.

Regards,
Volker

On 10/8/09, John Rose <John.Rose at sun.com> wrote:
> On Oct 7, 2009, at 9:31 PM, David Holmes - Sun Microsystems wrote:
>
>
> > The assumption was that the functionality performed by CHECK was actually
> necessary, hence the variables would not be useless nor the test duplicated.
> >
>
>  OK, I missed that. I was working from Volker's initial example, of
> create_string_variable, where the CHECK is not necessary, since it has the
> same TRAPS contract with its caller that its caller has with it.  (That is,
> all callers of create_string_variable also use the CHECK macro, which
> contains a duplicable test.)  Your example of
> ObjectSynchronizer::complete_exit is similar.  In those
> cases, if the middle function uses CHECK, as well as the outer function,
> there is a duplicated test (for an exception posted to the thread object by
> the inner function).
>
>  -- John
>