Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros

Krystal Mo krystal.mo at oracle.com
Thu Mar 28 16:22:42 PDT 2013


Hi Mikael,

I'd say it has to do with the way ResourceMark works.

Dummy example:

void foo(Symbol* sym) {
   RC_TRACE(("%s", sym->as_C_string())); // as_C_string allocates resource
}

ideally this should get expanded into:

void foo(Symbol* sym) {
   if (RC_TRACE_ENABLED(some_level)) {
     ResourceMark rm; // note here
     tty->print("RedefineClasses-0x%x: ", level);
     tty->print("%s", sym->as_C_string()); // resource allocation in the 
same scope as the ResourceMark
   }
}

If RC_TRACE were made into a (inline) function, then the ResourceMark 
will have to be taken care of by the caller, like so:

void foo(Symbol* sym) {
   ResourceMark rm;
   RC_TRACE(("%s", sym->as_C_string())); // as_C_string allocates resource
}

Otherwise we'd leak resource-allocated memory. This is the only reason I 
can think of for keeping it as a macro instead of turning it into a real 
function.

- Kris

On 03/28/2013 04:12 PM, Mikael Vidstedt wrote:
>
> I'm curious: Are there any fundamental reasons for not turning these 
> into real functions instead of using macros to avoid the problem all 
> together? The only downside I can see is that the functions would to 
> do a va_start/va_end and use the va_list version of print instead, but 
> that doesn't seem all to bad?
>
> Cheers,
> Mikael
>
> On 2013-03-28 15:11, Krystal Mo wrote:
>> Hi all,
>>
>> Could I have a review for this small patch, please?
>>
>> Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00
>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009
>>
>> This patch improves the EC_TRACE and RC_TRACE* family of macros to be 
>> less error prone.
>> They used to end with while(0) to make the macros statement-like, but 
>> a better way to do this is do {...} while(0).
>>
>> Testing with JPRT, will send an update email when it's done.
>>
>> P.S. I'm not sure where I should send this email for review, should 
>> it be hotspot-runtime or serviceability?
>>
>> Thanks,
>> Kris
>



More information about the hotspot-dev mailing list