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

[Staffan Larsen]

On 18 dec 2012, at 22:11, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:

> 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\" \
> 

Isn't it this line that makes it work? Arguments::created_by_gamma_launcher() essentially checks that -Dsun.java.launcher=gamma is set. And the LAUNCHER_TYPE=gamma is what sets -Dsun.java.launcher=gamma. I think, but I may be missing something?

Thanks,
/Staffan

> 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.
>