RFR: JDK-8202920: jvm.cfg generation incorrect

[Erik Joelsson]

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