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

[harold seigel]

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 "libjvm.so"
2541 len = strlen(buf);
2542 *snprintf(buf + len, buflen-len, "/hotspot/libjvm.so");*
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:
> Greetings,
>
> I'm sponsoring this code review request from Ron Durbin. This change
> is targeted at JDK8/HSX-25 in the RT_Baseline repo.
>
> Dan
>
> Sending again with correct subject line, bug URLs and webrev URL.
>
>
> Intro:
>
> This set of changes removes the runtimesupport for generation of debug 
> versions that follow _g semantics.
>
> Defect:
> JDK-8005044 remove crufty '_g' support from HS runtime code
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044
> https://jbs.oracle.com/bugs/browse/JDK-8005044
>
>
> Webrev
> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0
>
>
> Details:
> Files have been modified to remove all reference and support for 
>  debug versions that follow _g semantics.
>
> Testing:
>
> Passed JPRT last night:
>
> Additional Testing In process: (suggested by Dan):
>
> src/share/vm/runtime/arguments.cpp
>     - test with shared archive creation and use; see the e-mail
>       from Coleen
>
> src/share/tools/ProjectCreator/ProjectCreator.java
>     - just a usage message; visual inspection of the code
>
> src/os/windows/vm/os_windows.cpp
>     - comments only; no testing needed
>
> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp
>     - 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...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/d9406680/attachment.html