RFR 8010280: jvm.cfg needs updating for non-server builds

[David Holmes]

On 15/04/2013 7:03 PM, Erik Joelsson wrote:
> Hello,
>
> It looks to me like you are covering the case of both server and client
> being true twice. How could line 319 ever evaluate to true? Otherwise it
> looks ok.

You are right - that was a leftover from an initial approach that only 
looked for client+server but excluded client+server+minimal. Back to the 
drawing board.

Thanks,
David

> /Erik
>
> On 2013-04-15 02:18, David Holmes wrote:
>> Some background.
>>
>> The jvm.cfg file, for which there is a per-architecture committed file
>> in the repository, controls which VM's (client, server, minimal) are
>> known, which is the default, whether there are other aliases and
>> whether ergonomic selection is used.
>>
>> Historically things were simple:
>> - 64-bit platforms had server only
>> - 32-bit platforms had client and server
>>
>> then we acknowledged that some platforms may be client only and we
>> added some support (originally in the old build then converted to the
>> new build) for dynamically creating a jvm.cfg for the case of building
>> client only.
>>
>> Then the minimal VM was introduced and we potentially have three VMs
>> to handle. To address this we initially added "-minimal KNOWN" to all
>> the jvm.cfg files for platforms known to support the minimal VM - this
>> was done under JDK-7198815 (and those changes are now reversed by this
>> changeset.)
>>
>> The problem after minimal was introduced was that the logic for
>> "building client only" didn't account for building minimal (only or
>> combined with client) and we need support for not-building-server. And
>> that is what this changeset does.
>>
>> This only affects 32-bit builds as there is no client nor minimal VM
>> on 64-bit. The basic operation is as follows:
>>
>> - If building client+server then we use the committed jvm.cfg (which
>> handles ergonomics if applicable), adding a "-minimal KNOWN" line if
>> minimal is also selected;
>> - Otherwise we dynamically generate a jvm.cfg for the set of VMs being
>> built, using these simple rules:
>>   - if client or server are present they are default
>>   - if client and/or server is absent then the absent VM is aliased to
>> the default VM in that config
>>   - if minimal is not selected then it is absent from the jvm.cfg (we
>> do not add any aliases for minimal**).
>>
>> ** The alias mechanism is useful for deprecating legacy VM names, and
>> has also made testing more convenient. However I think it is a flawed
>> mechanism for testing and our internal test infrastructure is moving
>> away from arbitrarily using -client/-server when actually running
>> server/client. If you ask for the minimal VM and it is not available I
>> think you should get an error not silent use of a different VM. (Note:
>> this selection doesn't affect SE Embedded as it defines jvm.cfg files
>> using it's own rules/preferences.)
>>
>> webrev:
>>
>> http://cr.openjdk.java.net/~dholmes/8010280/webrev/
>>
>> Thanks,
>> David