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

[Mike Duigou]

Hi David;

I remember reviewing the jvm.cfg config patch for JDK 7. I had hoped to see the "classic" and "green" flags go away and some of the other legacy flags like "-hotspot" reduced to WARN. What's the difference between removing an entry completely and retaining it with "ERROR"?

Additionally I don't like that aliases have differing definitions and some confusing ones like "-server ALIASED_TO -client". Is this necessary or just historically convenient?

Mike

On Apr 14 2013, at 17: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