RFR: JDK-8202920: jvm.cfg generation incorrect

[David Holmes]

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.

> 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.

>> 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.

David

> /Erik
>> David
>>
>>> /Erik
>>>
>>> On 2018-05-10 15:32, Erik Joelsson wrote:
>>>> On 2018-05-10 15:12, David Holmes wrote:
>>>>> Hi Erik,
>>>>>
>>>>> cc'ing Kumar as he is nominally the owner of the jvm.cfg files.
>>>>>
>>>>> On 11/05/2018 3:38 AM, Erik Joelsson wrote:
>>>>>> I took a further look at the jvm.cfg generation and reworked it 
>>>>>> completely. This change removes all the predefined jvm.cfg files 
>>>>>> and replaces them with a simple generation script. This should 
>>>>>> produce the same files as before JDK-8202683 for any configuration 
>>>>>> Oracle builds officially and zero. For special jvm variant 
>>>>>> combinations, it will stay closer to the official ones. See bug 
>>>>>> comments for details.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202920
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8202920/webrev.01/
>>>>>
>>>>> I'm not sure of the details here. You no longer alias any flags for 
>>>>> VMs not present, but list them as "ignore". IIUC that means the 
>>>>> default VM will be selected - so as long as the default VM is the 
>>>>> one previously aliased to then it is equivalent. I also thought 
>>>>> that the first line in the file defined the default VM and so had 
>>>>> to be a known VM - with these changes a client-only build, for 
>>>>> example, will have a first entry of "-server ignore".
>>>>>
>>>> I wasn't sure about the ordering and default, but if the first one 
>>>> matters, then I need to rework this a bit. In particular the order 
>>>> is now reversed for windows x86 (if that is something we would want 
>>>> to preserve). Inserting the KNOWN should also be moved last as you 
>>>> point out.
>>>>> There is always some debate as to whether a non-present VM should 
>>>>> be ignored or cause an error. For the minimal VM builds we used to 
>>>>> do for SE Embedded it was chosen to ignore them and just use the 
>>>>> Minimal VM. This isn't necessarily what everyone would want.
>>>>>
>>>> For that part, this change is not changing behavior for any 
>>>> configuration that we really care about. (Note that you need to 
>>>> compare to the behavior previous to Shipilev's change which did 
>>>> indeed move things around.) All the static jvm.cfg files should be 
>>>> equivalent as none of them had ALIAS in them anymore (since your 
>>>> change way back in JDK 8). There will only be a difference if you 
>>>> explicitly build a non standard combination, like only client or 
>>>> only minimal. In those cases, the old generation logic would kick in 
>>>> and generate aliases. Do we want to keep aliases in those cases? 
>>>> Does it really matter?
>>>>
>>>> /Erik
>>>>> David
>>>>>
>>>>>> /Erik
>>>>>>
>>>>
>>>
>