On 2018-05-10 15:52, David Holmes wrote:
On 11/05/2018 8:41 AM, Erik Joelsson wrote:
Here is a new webrev where the IGNORED are added last.
http://cr.openjdk.java.net/~erikj/8202920/webrev.02/
It will still change the default on windows-x86 however. If we really
care about this, then perhaps we need to add a configure flag that
allows the builder to pick the default variant.
For 32-bit, client was always the default. That should be easy enough
to maintain.
No, if you look at:
http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/unix/conf/i586/jvm.cfg-.html
It has server as default, whereas:
http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/windows/conf/i586/jvm.cfg-.html
has client, so it varies on OS (and cpu type for legacy oracle closed
platforms). This can certainly be maintained, but the question is if
anyone cares. There is a cost to maintaining exceptions. I think the
best cause of action right now is to go with my current patch and if
anyone thinks they need to control the default (i.e. set client default
for certain configurations) we can add a configure flag later.
Given these jvm.cfg files have been slated for removal for a very long
time, I don't think you want to add new configure options related to
them. Even this current work is rather a waste of everyone's time in
the circumstance.
You mean the launcher will be reworked? Perhaps it will. However, right
now, the combination of JDK-8202919 and JDK-8202683 has quite
drastically changed the contents of jvm.cfg, so I'm trying to restore
some kind of order short term.
/Erik
David
/Erik
On 2018-05-10 15:32, Erik Joelsson wrote:
On 2018-05-10 15:12, David Holmes wrote:
Hi Erik,
cc'ing Kumar as he is nominally the owner of the jvm.cfg files.
On 11/05/2018 3:38 AM, Erik Joelsson wrote:
I took a further look at the jvm.cfg generation and reworked it
completely. This change removes all the predefined jvm.cfg files
and replaces them with a simple generation script. This should
produce the same files as before JDK-8202683 for any configuration
Oracle builds officially and zero. For special jvm variant
combinations, it will stay closer to the official ones. See bug
comments for details.
Bug: https://bugs.openjdk.java.net/browse/JDK-8202920
Webrev: http://cr.openjdk.java.net/~erikj/8202920/webrev.01/
I'm not sure of the details here. You no longer alias any flags for
VMs not present, but list them as "ignore". IIUC that means the
default VM will be selected - so as long as the default VM is the
one previously aliased to then it is equivalent. I also thought
that the first line in the file defined the default VM and so had
to be a known VM - with these changes a client-only build, for
example, will have a first entry of "-server ignore".
I wasn't sure about the ordering and default, but if the first one
matters, then I need to rework this a bit. In particular the order
is now reversed for windows x86 (if that is something we would want
to preserve). Inserting the KNOWN should also be moved last as you
point out.
There is always some debate as to whether a non-present VM should
be ignored or cause an error. For the minimal VM builds we used to
do for SE Embedded it was chosen to ignore them and just use the
Minimal VM. This isn't necessarily what everyone would want.
For that part, this change is not changing behavior for any
configuration that we really care about. (Note that you need to
compare to the behavior previous to Shipilev's change which did
indeed move things around.) All the static jvm.cfg files should be
equivalent as none of them had ALIAS in them anymore (since your
change way back in JDK 8). There will only be a difference if you
explicitly build a non standard combination, like only client or
only minimal. In those cases, the old generation logic would kick in
and generate aliases. Do we want to keep aliases in those cases?
Does it really matter?
/Erik
David
/Erik
