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.
/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
