Code Review fix for 8005044 remove crufty '_g' support from HS runtime code

Ron Durbin ron.durbin at
Tue Dec 18 15:50:19 PST 2012

Thanks for the quick reviews by all.


I will agree with Dan on this one, sprint will stay.




From: Daniel D. Daugherty 
Sent: Tuesday, December 18, 2012 4:03 PM
To: hotspot-runtime-dev at; build-dev; serviceability-dev at
Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code


Sorry, I lost my manners somewhere... :-(

Thanks for the fast review!


On 12/18/12 3:57 PM, Daniel D. Daugherty wrote:

Adding back in the other aliases...


The equivalent of:

    snprintf(buf, n, str);


    strncpy(buf, str, n - 1);
    buf[n - 1] = '\0';

because snprintf() will only write out (n - 1) bytes from
'str' to 'buf' and then write a NUL in the last slot.
strncpy() copies up to 'n' bytes from 'str' to 'buf'.
strncpy() will not copy past a NUL character in 'str', but
it will also not NUL terminate 'buf' if a NUL is not found
in 'str' before the limit 'n' is reached.


On 12/18/12 2:48 PM, harold seigel wrote:

Hi Ron,

I think these calls to snprintf() in os_solaris.cpp and the other os_....cpp files could be replaced with calls to strncpy().  It might be a little simpler.

Otherwise, it looks good.

Thanks, Harold

2539 if (0 == access(buf, F_OK)) { 
2540 // Use current module name "" 
2541 len = strlen(buf); 
2542 snprintf(buf + len, buflen-len, "/hotspot/"); 
2543 } else { 
2544 // Go back to path of .so 
2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } 

On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: 


I'm sponsoring this code review request from Ron Durbin. This change
is targeted at JDK8/HSX-25 in the RT_Baseline repo.


Sending again with correct subject line, bug URLs and webrev URL.

This set of changes removes the runtime support for generation of debug versions that follow _g semantics.
JDK-8005044 remove crufty '_g' support from HS runtime code


Files have been modified to remove all reference and support for  debug versions that follow _g semantics.
Passed JPRT last night:
Additional Testing In process: (suggested by Dan):

    - test with shared archive creation and use; see the e-mail
      from Coleen

    - just a usage message; visual inspection of the code

    - comments only; no testing needed

    - the only code changes come into play when the "gamma"
      launcher is used
    - and when JAVA_HOME refers to a valid JDK, the function
      fakes up a JVM path so that callers using the JVM path
      to find other things in the JDK will work.
    - I can't find any way that the actual JVM path value
      that is returned is exposed
    - I don't see a way to test this other than have a debug
      printf() or manual code inspection.


-------------- next part --------------
An HTML attachment was scrubbed...

More information about the hotspot-runtime-dev mailing list