Looks good. It's nice to see the legacy entries finally get removed. Mike
On Apr 26 2013, at 00:27 , 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
