RFR: JDK-8202920: jvm.cfg generation incorrect

[Magnus Ihse Bursie]

On 2018-05-11 19:46, 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/
This looks good to me.

I missed that you had sent this out earlier.

/Magnus
>
> /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
>