Problem with CHECK_NULL macro in return statements

[Christian Thalinger]

On Nov 5, 2012, at 9:44 AM, Volker Simonis <volker.simonis at gmail.com> wrote:

> Hi,
> 
> we indeed discussed this topic three years ago:
> 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-October/thread.html#2175
> 
> The general outcome of the discussion was to:
> 
> 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.
> 
> I promised to prepare a Webrev that time which I haven't done until
> now so I'm a little bit reluctant to promise it again:)
> But I'll try my best to fix it this time!

I knew the ball was in your court :-D

-- Chris

> 
> Regards,
> Volker
> 
> 
> 
> On Mon, Nov 5, 2012 at 5:44 PM, Christian Thalinger
> <christian.thalinger at oracle.com> wrote:
>> 
>> On Nov 2, 2012, at 9:38 AM, "Doerr, Martin" <martin.doerr at sap.com> wrote:
>> 
>> Hello everybody,
>> 
>> 
>> 
>> I found many places at which the CHECK_NULL macro gets used in a return
>> statement like the following one:
>> 
>> return the_table()->basic_add(index, (u1*)buffer, len, hashValue, true,
>> CHECK_NULL);
>> 
>> 
>> 
>> However, this does not work as one would usually expect. The macro gets
>> expanded to:
>> 
>> __the_thread__); if
>> ((((ThreadShadow*)__the_thread__)->has_pending_exception())) return NULL; (0
>> 
>> 
>> 
>> The return statement above prevents the code after “__the_thread__);” from
>> ever getting evaluated.
>> 
>> 
>> There was a discussion with Volker about this issue some time ago.  I can't
>> remember what the outcome was.  Do you guys have a fix to propose?
>> 
>> -- Chris
>> 
>> 
>> 
>> Kind regards,
>> 
>> Martin
>> 
>>