RFR: JDK-8202920: jvm.cfg generation incorrect

[David Holmes]

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.

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.

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