RFR: JDK-8180202: -XXaltjvm is not working anymore on MacOSX

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR: JDK-8180202: -XXaltjvm is not working anymore on MacOSX

Kumar Srinivasan
Hi David,

Please review simple fix for JDK-8180202, recall we hard coded "server",
this is incorrect because the function CheckJvmType will determin
the correct jvmtype based on jvm.cfg *or* path/jvmtype specified by
-XXaltjvm.  IMO all this needs to be cleaned up when jvm.cfg is removed.

Thanks
Kumar

PS: please also approve the removal of the test from the internal
ProblemList.txt
diff in the JBS issue.

diff --git a/src/java.base/macosx/native/libjli/java_md_macosx.c
b/src/java.base/macosx/native/libjli/java_md_macosx.c
--- a/src/java.base/macosx/native/libjli/java_md_macosx.c
+++ b/src/java.base/macosx/native/libjli/java_md_macosx.c
@@ -424,7 +424,7 @@
           * macosx client library is built thin, i386 only.
           * 64 bit client requests must load server library
           */
-        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/server/" JVM_DLL,
jrepath);
+        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL,
jrepath, jvmtype);
      }

      JLI_TraceLauncher("Does `%s' exist ... ", jvmpath);






Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8180202: -XXaltjvm is not working anymore on MacOSX

David Holmes
Hi Kumar,

On 15/05/2017 9:54 AM, Kumar Srinivasan wrote:
> Hi David,
>
> Please review simple fix for JDK-8180202, recall we hard coded "server",
> this is incorrect because the function CheckJvmType will determin
> the correct jvmtype based on jvm.cfg *or* path/jvmtype specified by
> -XXaltjvm.  IMO all this needs to be cleaned up when jvm.cfg is removed.

So this original change was wrong:

!         const char *jvmtypeUsed = ((bitsWanted == 64) &&
(strcmp(jvmtype, "client") == 0)) ? "server" : jvmtype;
!         const char *jvmtypeUsed = "server";

because jvmType might still be something other than "server"? Not sure
how but okay.

However I don't see the connection to -XXaltjvm as that should be
setting a full path itself and not relying on jvmType within the
well-known path ??

> Thanks
> Kumar
>
> PS: please also approve the removal of the test from the internal
> ProblemList.txt

Ok.

Thanks,
David

> diff in the JBS issue.
>
> diff --git a/src/java.base/macosx/native/libjli/java_md_macosx.c
> b/src/java.base/macosx/native/libjli/java_md_macosx.c
> --- a/src/java.base/macosx/native/libjli/java_md_macosx.c
> +++ b/src/java.base/macosx/native/libjli/java_md_macosx.c
> @@ -424,7 +424,7 @@
>           * macosx client library is built thin, i386 only.
>           * 64 bit client requests must load server library
>           */
> -        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/server/" JVM_DLL,
> jrepath);
> +        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL,
> jrepath, jvmtype);
>      }
>
>      JLI_TraceLauncher("Does `%s' exist ... ", jvmpath);
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8180202: -XXaltjvm is not working anymore on MacOSX

Kumar Srinivasan
Hi David,

>>
>> Please review simple fix for JDK-8180202, recall we hard coded "server",
>> this is incorrect because the function CheckJvmType will determin
>> the correct jvmtype based on jvm.cfg *or* path/jvmtype specified by
>> -XXaltjvm.  IMO all this needs to be cleaned up when jvm.cfg is removed.
>
> So this original change was wrong:
>
> !         const char *jvmtypeUsed = ((bitsWanted == 64) &&
> (strcmp(jvmtype, "client") == 0)) ? "server" : jvmtype;
> !         const char *jvmtypeUsed = "server";
>
> because jvmType might still be something other than "server"? Not sure
> how but okay.
>
> However I don't see the connection to -XXaltjvm as that should be
> setting a full path itself and not relying on jvmType within the
> well-known path ??

Ah, please see
http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/51214dadd48f/src/java.base/macosx/native/libjli/java_md_macosx.c#l420

What is happening is if XXaltjvm contains a slash then it treats it as a
path,
ex: -XXaltjvm /tmp/myvm

if not then jvmtype, and uses it choose the VM variant, the latter seems to
be an override for jvm.cfg, ex: -XXaltjvm minimal

Not sure of the historical background,  all this needs some cleanup, and
removing jvm.cfg will help clean some of this mess up.

Hope that clarifies.

Kumar



>
>> Thanks
>> Kumar
>>
>> PS: please also approve the removal of the test from the internal
>> ProblemList.txt
>
> Ok.
>
> Thanks,
> David
>
>> diff in the JBS issue.
>>
>> diff --git a/src/java.base/macosx/native/libjli/java_md_macosx.c
>> b/src/java.base/macosx/native/libjli/java_md_macosx.c
>> --- a/src/java.base/macosx/native/libjli/java_md_macosx.c
>> +++ b/src/java.base/macosx/native/libjli/java_md_macosx.c
>> @@ -424,7 +424,7 @@
>>           * macosx client library is built thin, i386 only.
>>           * 64 bit client requests must load server library
>>           */
>> -        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/server/" JVM_DLL,
>> jrepath);
>> +        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL,
>> jrepath, jvmtype);
>>      }
>>
>>      JLI_TraceLauncher("Does `%s' exist ... ", jvmpath);
>>
>>
>>
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8180202: -XXaltjvm is not working anymore on MacOSX

David Holmes
Hi Kumar,

On 16/05/2017 12:21 AM, Kumar Srinivasan wrote:

> Hi David,
>
>>>
>>> Please review simple fix for JDK-8180202, recall we hard coded "server",
>>> this is incorrect because the function CheckJvmType will determin
>>> the correct jvmtype based on jvm.cfg *or* path/jvmtype specified by
>>> -XXaltjvm.  IMO all this needs to be cleaned up when jvm.cfg is removed.
>>
>> So this original change was wrong:
>>
>> !         const char *jvmtypeUsed = ((bitsWanted == 64) &&
>> (strcmp(jvmtype, "client") == 0)) ? "server" : jvmtype;
>> !         const char *jvmtypeUsed = "server";
>>
>> because jvmType might still be something other than "server"? Not sure
>> how but okay.
>>
>> However I don't see the connection to -XXaltjvm as that should be
>> setting a full path itself and not relying on jvmType within the
>> well-known path ??
>
> Ah, please see
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/51214dadd48f/src/java.base/macosx/native/libjli/java_md_macosx.c#l420
>
>
> What is happening is if XXaltjvm contains a slash then it treats it as a
> path,
> ex: -XXaltjvm /tmp/myvm
>
> if not then jvmtype, and uses it choose the VM variant, the latter seems to
> be an override for jvm.cfg, ex: -XXaltjvm minimal

Ah! I did not realize that - how quirky - I guess it avoids the need to
modify jvm.cfg to add a known VM.

> Not sure of the historical background,  all this needs some cleanup, and
> removing jvm.cfg will help clean some of this mess up.
>
> Hope that clarifies.

Thanks!

David

>
> Kumar
>
>
>
>>
>>> Thanks
>>> Kumar
>>>
>>> PS: please also approve the removal of the test from the internal
>>> ProblemList.txt
>>
>> Ok.
>>
>> Thanks,
>> David
>>
>>> diff in the JBS issue.
>>>
>>> diff --git a/src/java.base/macosx/native/libjli/java_md_macosx.c
>>> b/src/java.base/macosx/native/libjli/java_md_macosx.c
>>> --- a/src/java.base/macosx/native/libjli/java_md_macosx.c
>>> +++ b/src/java.base/macosx/native/libjli/java_md_macosx.c
>>> @@ -424,7 +424,7 @@
>>>           * macosx client library is built thin, i386 only.
>>>           * 64 bit client requests must load server library
>>>           */
>>> -        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/server/" JVM_DLL,
>>> jrepath);
>>> +        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL,
>>> jrepath, jvmtype);
>>>      }
>>>
>>>      JLI_TraceLauncher("Does `%s' exist ... ", jvmpath);
>>>
>>>
>>>
>>>
>>>
>>>
>