RFR: JDK-8202920: jvm.cfg generation incorrect

[Kumar Srinivasan]

+1

Kumar

> Hi Erik,
>
> As long as the end result is a jvm.cfg that matches the current ones 
> in the repo then this looks fine.
>
> Thanks,
> David
>
> On 12/05/2018 3:46 AM, Erik Joelsson wrote:
>> Here is a new attempt. This time I'm pretty sure it produces the same 
>> jvm.cfg as all the predefined ones. It's easy to define a new default 
>> variant for specific configurations (as is done for windows-x86). It 
>> also handles the jvm variants that aren't server, client or minimal 
>> correctly (by treating them as server).
>>
>> The only real difference compared to before all this is that we no 
>> longer generate ALIASED_TO, but that only happened on very specific 
>> manual configurations that anyway.
>>
>> http://cr.openjdk.java.net/~erikj/8202920/webrev.03/
>>
>> /Erik
>>
>>
>> On 2018-05-11 08:56, Erik Joelsson wrote:
>>> On 2018-05-10 21:56, David Holmes wrote:
>>>> On 11/05/2018 10:03 AM, Erik Joelsson wrote:
>>>>> On 2018-05-10 15:52, David Holmes wrote:
>>>>>> On 11/05/2018 8:41 AM, Erik Joelsson wrote:
>>>>>>> Here is a new webrev where the IGNORED are added last.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/
>>>>>>>
>>>>>>> It will still change the default on windows-x86 however. If we 
>>>>>>> really care about this, then perhaps we need to add a configure 
>>>>>>> flag that allows the builder to pick the default variant.
>>>>>>
>>>>>> For 32-bit, client was always the default. That should be easy 
>>>>>> enough to maintain.
>>>>>>
>>>>> No, if you look at:
>>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/unix/conf/i586/jvm.cfg-.html 
>>>>>
>>>>>
>>>>> It has server as default, whereas:
>>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/windows/conf/i586/jvm.cfg-.html 
>>>>>
>>>>>
>>>>> has client, so it varies on OS (and cpu type for legacy oracle closed 
>>>>
>>>> Sorry I meant with respect to windows-x86, that being the subject 
>>>> of your comment.
>>>>
>>> Right, then we are on the same page there.
>>>>> platforms). This can certainly be maintained, but the question is 
>>>>> if anyone cares. There is a cost to maintaining exceptions. I 
>>>>> think the best cause of action right now is to go with my current 
>>>>> patch and if anyone thinks they need to control the default (i.e. 
>>>>> set client default for certain configurations) we can add a 
>>>>> configure flag later.
>>>>
>>>> I strongly disagree. For anyone who is producing a 32-bit Windows 
>>>> bundle for use by others, the behaviour will change from running 
>>>> client by default to running server! At best that will impact 
>>>> startup and performance; at worst startup scripts will fail if 
>>>> client specific flags are used.
>>>>
>>> You are right, I will rework this to make sure we can generate 
>>> different defaults for different configurations so that the current 
>>> behavior is preserved for any of the current predefined jvm.cfg files.
>>>>>> Given these jvm.cfg files have been slated for removal for a very 
>>>>>> long time, I don't think you want to add new configure options 
>>>>>> related to them. Even this current work is rather a waste of 
>>>>>> everyone's time in the circumstance.
>>>>>>
>>>>> You mean the launcher will be reworked? Perhaps it will. However, 
>>>>> right now, the combination of JDK-8202919 and JDK-8202683 has 
>>>>> quite drastically changed the contents of jvm.cfg, so I'm trying 
>>>>> to restore some kind of order short term.
>>>>
>>>> Personally when the problem with Aleksey's original change was 
>>>> detected I would have rolled it back. If you want to restore order 
>>>> by other means, then do so, but that means restoring the previous 
>>>> contents of the jvm.cfg files to me.
>>>>
>>> The problematic change has now been backed out but I will make 
>>> another attempt at this change.
>>>
>>> /Erik
>>