RFR: JDK-8202920: jvm.cfg generation incorrect

[Magnus Ihse Bursie]

On 2018-05-14 17:50, Erik Joelsson wrote:
> On 2018-05-13 00:37, Magnus Ihse Bursie wrote:
>> Just to mess a bit more with you all, maybe this code does not really 
>> belong in "copy" "java.base", but rather more Hotspot and gensrc? The 
>> jvm.cfg is, after all, describing the hotspot build configuration.
> Maybe, but I believe historically it's been considered part of the 
> launcher logic rather than hotspot. I wouldn't agree with gensrc 
> either, as the file is not being compiled or processed further after 
> this. It could be argued to be gendata rather than copy, but the 
> difference between those two is really not well defined. In reality, 
> the difference bweteen gendata and copy is that copy does not depend 
> on the buildtools targets to be run first, while gendata does.
>
> I prefer just keeping it where it is for now.
Hm.

Oh well. I'm happy enough that you're cleaning it up, so I'll leave it 
to you. :)

/Magnus

>
> /Erik
>> /Magnus
>>
>>> 11 maj 2018 kl. 19:46 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>>
>>> 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/
>>>
>>> /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
>