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

[Tim Bell]

Hi David

Looks good to me.

Tim

On 04/26/13 12:27 AM, David Holmes wrote:
> Here is the final form of this after CCC approval.
>
> http://cr.openjdk.java.net/~dholmes/8010280/webrev.v3/
>
> For the "traditional" build of client+server we continue to use the 
> platform specific jvm.cfg files committed into the source repository. 
> Consequently no product builds (SE or Embedded) are altered by this 
> proposal. (Those files already contain "-minimal KNOWN" if applicable 
> to that platform.)
>
> Otherwise we define a jvm.cfg file where:
> - the default VM is the "dominant" VM (server > client > minimal)
> - a missing client/server is aliased to the default VM
> - the minimal VM is only present in the jvm.cfg file if it is built
>
> Further, as a target of opportunity we stop generating, and delete 
> from the existing jvm.cfg files the legacy entries for "hotspot", 
> "classic", "native" and "green"
>
> Thanks,
> David
>
> Generated jvm.cfg contents based on selected JVM variants:
>
> ::::::::::::::
> client
> ::::::::::::::
> -client KNOWN
> -server ALIASED_TO -client
>
> ::::::::::::::
> minimal+client
> ::::::::::::::
> -client KNOWN
> -server ALIASED_TO -client
> -minimal KNOWN
>
> ::::::::::::::
> minimal
> ::::::::::::::
> -minimal KNOWN
> -server ALIASED_TO -minimal
> -client ALIASED_TO -minimal
>
> ::::::::::::::
> minimal+server
> ::::::::::::::
> -server KNOWN
> -client ALIASED_TO -server
> -minimal KNOWN
>
> ::::::::::::::
> server
> ::::::::::::::
> -server KNOWN
> -client ALIASED_TO -server
>
>
> On 15/04/2013 10:18 AM, 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