RFR: JDK-8202920: jvm.cfg generation incorrect

[David Holmes]

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
>