On 2018-05-14 17:50, Erik Joelsson wrote:
On 2018-05-13 00:37, Magnus Ihse Bursie wrote:
Just to mess a bit more with you all, maybe this code does not really
belong in "copy" "java.base", but rather more Hotspot and gensrc? The
jvm.cfg is, after all, describing the hotspot build configuration.
Maybe, but I believe historically it's been considered part of the
launcher logic rather than hotspot. I wouldn't agree with gensrc
either, as the file is not being compiled or processed further after
this. It could be argued to be gendata rather than copy, but the
difference between those two is really not well defined. In reality,
the difference bweteen gendata and copy is that copy does not depend
on the buildtools targets to be run first, while gendata does.
I prefer just keeping it where it is for now.
Hm.
Oh well. I'm happy enough that you're cleaning it up, so I'll leave it
to you. :)
/Magnus
/Erik
/Magnus
11 maj 2018 kl. 19:46 skrev Erik Joelsson <erik.joels...@oracle.com>:
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
