RFR: JDK-8202920: jvm.cfg generation incorrect

[Erik Joelsson]

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