Improper usage of CHECK macros generates unreachable code

[Tom Rodriguez]

On Oct 8, 2009, at 1:11 AM, Volker Simonis wrote:

> 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?

This sounds good to me as well.

tom

>
> 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
>>