Hi Erik,
As long as the end result is a jvm.cfg that matches the current ones in
the repo then this looks fine.
Thanks,
David
On 12/05/2018 3:46 AM, Erik Joelsson wrote:
Here is a new attempt. This time I'm pretty sure it produces the same
jvm.cfg as all the predefined ones. It's easy to define a new default
variant for specific configurations (as is done for windows-x86). It
also handles the jvm variants that aren't server, client or minimal
correctly (by treating them as server).
The only real difference compared to before all this is that we no
longer generate ALIASED_TO, but that only happened on very specific
manual configurations that anyway.
http://cr.openjdk.java.net/~erikj/8202920/webrev.03/
/Erik
On 2018-05-11 08:56, Erik Joelsson wrote:
On 2018-05-10 21:56, David Holmes wrote:
On 11/05/2018 10:03 AM, Erik Joelsson wrote:
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
Sorry I meant with respect to windows-x86, that being the subject of
your comment.
Right, then we are on the same page there.
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.
I strongly disagree. For anyone who is producing a 32-bit Windows
bundle for use by others, the behaviour will change from running
client by default to running server! At best that will impact startup
and performance; at worst startup scripts will fail if client
specific flags are used.
You are right, I will rework this to make sure we can generate
different defaults for different configurations so that the current
behavior is preserved for any of the current predefined jvm.cfg files.
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.
Personally when the problem with Aleksey's original change was
detected I would have rolled it back. If you want to restore order by
other means, then do so, but that means restoring the previous
contents of the jvm.cfg files to me.
The problematic change has now been backed out but I will make another
attempt at this change.
/Erik
