Code Review fix for 8005044 remove crufty '_g' support from HS runtime code
Staffan Larsen
staffan.larsen at oracle.com
Wed Dec 19 00:27:25 PST 2012
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.
>
More information about the serviceability-dev
mailing list