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

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.

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 vastart/vaend and use the valist 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/viewbug.do?bugid=8011009 This patch improves the ECTRACE and RCTRACE* 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