RFR: JDK-8202920: jvm.cfg generation incorrect

[Erik Joelsson]

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.

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