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
