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

[Daniel D. Daugherty]

Just for the record: I have reviewed all of Ron's changes
and I approve them.

One thing I noticed of interest to launcher folks that
is not due to any changes that Ron made:

src/os/windows/vm/os_windows.cpp:

1718 // Find the full path to the current module, jvm.dll
1719 void os::jvm_path(char *buf, jint buflen) {
1720   // Error checking.
1721   if (buflen < MAX_PATH) {
1722     assert(false, "must use a large-enough buffer");
1723     buf[0] = '\0';
1724     return;
1725   }
1726   // Lazy resolve the path to current module.
1727   if (saved_jvm_path[0] != 0) {
1728     strcpy(buf, saved_jvm_path);
1729     return;
1730   }
1731
1732   buf[0] = '\0';
1733   if (Arguments::created_by_gamma_launcher()) {
1734      // Support for the gamma launcher. Check for an
1735      // JAVA_HOME environment variable
1736      // and fix up the path so it looks like
1737      // libjvm.so is installed there (append a fake suffix
1738      // hotspot/libjvm.so).
1739      char* java_home_var = ::getenv("JAVA_HOME");
1740      if (java_home_var != NULL && java_home_var[0] != 0) {
1741
1742         strncpy(buf, java_home_var, buflen);
1743
1744         // determine if this is a legacy image or modules image
1745         // modules image doesn't have "jre" subdirectory
1746         size_t len = strlen(buf);
1747         char* jrebin_p = buf + len;
1748         jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\");
1749         if (0 != _access(buf, 0)) {
1750           jio_snprintf(jrebin_p, buflen-len, "\\bin\\");
1751         }
1752         len = strlen(buf);
1753         jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll");
1754      }
1755   }
1756
1757   if(buf[0] == '\0') {
1758   GetModuleFileName(vm_lib_handle, buf, buflen);
1759   }
1760   strcpy(saved_jvm_path, buf);
1761 }

the block from line 1733 -> 1755 is dead code on Windows.
The launcher on Windows is now called "hotspot" and is not
called "gamma" so Arguments::created_by_gamma_launcher()
will not return true on Windows.

And one more launcher nit:

$ grep gamma make/windows/makefiles/launcher.make
     /D LAUNCHER_TYPE=\"gamma\" \

Dan


On 12/18/12 1: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/5bb2eb24/attachment-0001.html