Problem with CHECK_NULL macro in return statements
Volker Simonis
volker.simonis at gmail.com
Mon Nov 5 09:44:19 PST 2012
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!
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
>
>
More information about the hotspot-compiler-dev
mailing list