RFR: JDK-8202920: jvm.cfg generation incorrect

Erik Joelsson erik.joelsson at oracle.com
Thu May 10 22:32:35 UTC 2018


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




More information about the build-dev mailing list