CHECK at the end of a void function

Ioi Lam ioi.lam at oracle.com
Wed Feb 17 22:16:35 UTC 2021


Converting this from a PR discussion 
(https://git.openjdk.java.net/jdk/pull/2494) to a regular mail.

What are people's opinion of:

     void bar(TRAPS);

     void foo(TRAPS) {
        bar(CHECK);
     }

vs

     void foo(TRAPS) {
        bar(THREAD);
     }

There's no mention of this in 
https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md

Advantage of CHECK:

- More readable -- you don't need to ask yourself:
   does the callee need a THREAD, or is the callee a TRAPS function?

- More maintainable. You don't accidentally miss a check if you add new
   code below

     void foo(TRAPS) {
        bar(THREAD);
        baz();       // adding a new call ....
     }

Note that we MUST use THREAD when returning a value (see 
https://bugs.openjdk.java.net/browse/JDK-6889002)

     int x(TRAPS);

     int y(TRAPS) {
        return x(THREAD);
     }

so there's inconsistency. However, the compiler will given an error if 
you add code below the THREAD. So we don't have the maintenance issue as 
void functions:

     int Y(TRAPS) {
        return X(THREAD);
        baz();
     }

Disadvantage of CHECK:

- It's not guaranteed that the C compiler will elide it. The code gets 
pre-processed to

     inlined bool ThreadShadow::has_pending_exception() const {
         return _pending_exception != NULL;
     }

     void foo(Thread*  __the_thread__) {
         bar(__the_thread__);
         if (((ThreadShadow*)__the_thread__)->has_pending_exception()) 
return;
     }

Is it safe to assume that any C compiler that can efficiently compile 
HotSpot will always elide the "if" line?

I am a little worried about the maintenance issue. If we really want to 
avoid the CHECK, I would prefer to have a new macro like:

     void foo(TRAPS) {
        bar(CHECK_AT_RETURN);
     }

which will be preprocessed to

     void foo(....) {
        bar(_thread__); return;
     }

So you can't accidentally add code below it.

Thanks
  -Ioi



More information about the hotspot-dev mailing list