Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds
On 12/16/2015 5:40 PM, David Holmes wrote: On 17/12/2015 7:35 AM, Erik Joelsson wrote: One more thing, where should this fix be pushed? Do you need it urgently in hs-rt? It is urgently needed in both the hs-rt and hs-comp repos as it affects nightly testing and JPRT. If Alejandro agrees I suggest pushing to jdk9/hs and it can then be pulled down to the team repos. Fine with me. It will go through PIT this weekend Alejandro With regard to the fix ... previously DEBUG_BINARIES was never set in spec.gmk and so was never externally introduced into the hotspot build this way. So why not simply change the name of the variable so that it has no affect on the hotspot part of the build? Thanks, David /Erik On 2015-12-16 22:34, Erik Joelsson wrote: Hello, Please review this quick fix for the build issue introduced in Hotspot by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when building Hotspot fastdebug, you essentially get a slowdebug build. For an explanation of why, see comment in bug. This behavior is of course also a bug, but not something I will address in this quick fix. What happened in JDK-8036003 was that a new configure API for controlling debug symbols was introduced. The two main settings of this new parameter, --with-native-debug-symbols, that we use internally at Oracle are "external" and "zipped". It was important to us that the behavior of these did not change with JDK-8036003, but exactly that did happen, because both of these settings now cause DEBUG_BINARIES=true to be set. This variable has never been set by configure before and because of the above weird behavior in the Hotspot makefiles, we are having problems. My proposed quick fix is to not set DEBUG_BINARIES=true for "external" or "zipped". It can remain true for "internal" since Oracle never builds it that way, and I understand those that requested this new configure parameter were setting DEBUG_BINARIES=true as a workaround before this anyway, so they should be fine with the broken fastdebug behavior for a while more. I will file a follow up bug to properly clean up this mess, but it will take some more time. Bug: https://bugs.openjdk.java.net/browse/JDK-8145564 Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/ /Erik -- Alejandro
Fwd: [verona.stage] RFR 8139986: Store debug level in java.vm.debug and conditionally print in "java -version"
There are building changes in this RFR and I meant to include this alias but didn't. So here you go Thanks Alejandro Forwarded Message Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug and conditionally print in "java -version" Date: Tue, 03 Nov 2015 10:45:31 -0700 From: Alejandro E Murillo <alejandro.muri...@oracle.com> Organization: Oracle Corporation To: hotspot-dev <hotspot-...@openjdk.java.net>, core-libs-dev Libs <core-libs-...@openjdk.java.net> CC: verona-...@openjdk.java.net Please review these changes: bug: https://bugs.openjdk.java.net/browse/JDK-8139986 Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/ Background: These changes introduce a new system property named "jdk.debug" intended to identify the type of the build. The build system has already been modified (see [1]) to provide the build type through the "--with-debug-level" configure option, and to remove that info from the (new) version string and consequently from the "java.version" and "java.vm.version" system properties. Here, the configure debug level is used to initialize the value of the "jdk.debug" system property. There are also changes to adapt any code that relied on the value of those version properties to determine the build type. They were changed to use this new property. The Launcher output was also modified to look as follows: jdk.debug = (“*foo*” != “release”) $java -version java version "9-ea" Java(TM) SE Runtime Environment (*foo *build 9-ea+88) Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, mixed mode) jdk.debug = “release”: (no change) $java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+88) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode) All this will be described and updated in the JEP-223 doc [2] shortly. [1] https://bugs.openjdk.java.net/browse/JDK-8139951 [2] http://openjdk.java.net/jeps/223 Thanks -- Alejandro
[9] RFR 8132947: Add tier2, tier2 and tier1_2 testsets to jprt.properties
Please review the webrev below for this enhancement: 8132947: Add tier2, tier2 and tier1_2 testsets to jprt.properties webrev: http://cr.openjdk.java.net/~amurillo/9/8132947/ bug: https://bugs.openjdk.java.net/browse/JDK-8132947 Thanks -- Alejandro
Re: [9] RFR 8132947: Add tier2, tier2 and tier1_2 testsets to jprt.properties
On 8/4/2015 1:11 AM, David Holmes wrote: Hi Alejandro, On 4/08/2015 4:56 PM, Alejandro E Murillo wrote: Please review the webrev below for this enhancement: 8132947: Add tier2, tier2 and tier1_2 testsets to jprt.properties webrev: http://cr.openjdk.java.net/~amurillo/9/8132947/ bug: https://bugs.openjdk.java.net/browse/JDK-8132947 This seems to be duplicating the information in TEST.groups. I thought this was set up so jprt.properties could just name the group from TEST.groups ? Thanks, David I was mimicking what is done for the other testsets, as JPRT seems to provide the list of tests to run. Let me double check that Thanks! -- Alejandro
Re: [9] RFR 8132947: Add tier2, tier2 and tier1_2 testsets to jprt.properties
I see, So we might need this in before invoking just with just tier[1,2] I'll add a dependency on this Thanks! Alejandro On 8/4/2015 11:38 AM, joe darcy wrote: Also note that I have a fix for 8075571: Support tiered testing make targets in-progress. -Joe On 8/4/2015 12:11 AM, David Holmes wrote: Hi Alejandro, On 4/08/2015 4:56 PM, Alejandro E Murillo wrote: Please review the webrev below for this enhancement: 8132947: Add tier2, tier2 and tier1_2 testsets to jprt.properties webrev: http://cr.openjdk.java.net/~amurillo/9/8132947/ bug: https://bugs.openjdk.java.net/browse/JDK-8132947 This seems to be duplicating the information in TEST.groups. I thought this was set up so jprt.properties could just name the group from TEST.groups ? Thanks, David Thanks -- Alejandro
Re: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK
Thanks Dan. Will check why the patch is empty. Alejandro On 7/21/2015 12:57 PM, Daniel D. Daugherty wrote: On 7/20/15 6:45 PM, Alejandro E Murillo wrote: Please review the following change that allows setting the Hotspot minor version and build number to that of the --with-update-version and --with-build-number configure parameters when provided. 8u builds only. webrev: http://cr.openjdk.java.net/~amurillo/8u66/8079410/ hotspot/make/defs.make No comments. hotspot/make/hotspot_version No comments. Thumbs up. Just FYI: the patch link in that webrev goes to an empty page. Dan Background (since bug was originally filed as internal): Currently, for 8u builds and earlier, the hotspot version looks like this (remnant from the hotspot express days): Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) By convention, minor version (66 above) always matches the JDK update version and hotspot build number is managed independently of the JDK build number. Both values are defined by default in hotspot/make/hotspot_version. With this change they can now be setup using the corresponding JDK configure parameters. Consequences: (1) For promoted and other milestone builds, the hotspot minor version will corresponds to the JDK update version and the hotspot build number will match the JDK build number. (2) Hotspot snapshots will no longer need to change the hotspot build number as that will be set at promotion time (matching the JDK build number). Since this is stored in the file mentioned above, a repo push (and the corresponding bug) was required to change it. That will no longer be necessary. (3) Since JPRT configures both the update and build numbers, when building via JPRT, the hotspot build number for those builds will always be 'b00' (matching the JDK build number). The Hotspot minor version will match the update version defined in make/jprt.prtoperties: java version 1.8.0_66-internal # Java(TM) SE Runtime Environment (build 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) (4) Since the version string is not actually changing, I do not expect this to have any impact on external tools or apps, but let me know if so. Thanks -- Alejandro
Re: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK
On 7/20/2015 7:01 PM, David Holmes wrote: Hi Alejandro, On 21/07/2015 10:45 AM, Alejandro E Murillo wrote: Please review the following change that allows setting the Hotspot minor version and build number to that of the --with-update-version and --with-build-number configure parameters when provided. 8u builds only. webrev: cut from the wrong tab, here you go: http://cr.openjdk.java.net/~amurillo/8u66/8079410/ Alejandro That location is not available externally. David Background (since bug was originally filed as internal): Currently, for 8u builds and earlier, the hotspot version looks like this (remnant from the hotspot express days): Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) By convention, minor version (66 above) always matches the JDK update version and hotspot build number is managed independently of the JDK build number. Both values are defined by default in hotspot/make/hotspot_version. With this change they can now be setup using the corresponding JDK configure parameters. Consequences: (1) For promoted and other milestone builds, the hotspot minor version will corresponds to the JDK update version and the hotspot build number will match the JDK build number. (2) Hotspot snapshots will no longer need to change the hotspot build number as that will be set at promotion time (matching the JDK build number). Since this is stored in the file mentioned above, a repo push (and the corresponding bug) was required to change it. That will no longer be necessary. (3) Since JPRT configures both the update and build numbers, when building via JPRT, the hotspot build number for those builds will always be 'b00' (matching the JDK build number). The Hotspot minor version will match the update version defined in make/jprt.prtoperties: java version 1.8.0_66-internal # Java(TM) SE Runtime Environment (build 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) (4) Since the version string is not actually changing, I do not expect this to have any impact on external tools or apps, but let me know if so. Thanks -- Alejandro
Re: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK
On 7/20/2015 7:10 PM, David Holmes wrote: Hi Alejandro, On 21/07/2015 10:45 AM, Alejandro E Murillo wrote: Please review the following change that allows setting the Hotspot minor version and build number to that of the --with-update-version and --with-build-number configure parameters when provided. 8u builds only. webrev: http://cr.openjdk.java.net/~amurillo/8u66/8079410/ The logic seems fine. I would have put it in the hotspot_version file directly I think, but it's okay as is. right, I could have put it there as well. I presume we will still update the default update version at the start of each new release cycle. Yes, but only necessary for non milestone or jprt builds Thanks Alejandro Thanks, David Background (since bug was originally filed as internal): Currently, for 8u builds and earlier, the hotspot version looks like this (remnant from the hotspot express days): Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) By convention, minor version (66 above) always matches the JDK update version and hotspot build number is managed independently of the JDK build number. Both values are defined by default in hotspot/make/hotspot_version. With this change they can now be setup using the corresponding JDK configure parameters. Consequences: (1) For promoted and other milestone builds, the hotspot minor version will corresponds to the JDK update version and the hotspot build number will match the JDK build number. (2) Hotspot snapshots will no longer need to change the hotspot build number as that will be set at promotion time (matching the JDK build number). Since this is stored in the file mentioned above, a repo push (and the corresponding bug) was required to change it. That will no longer be necessary. (3) Since JPRT configures both the update and build numbers, when building via JPRT, the hotspot build number for those builds will always be 'b00' (matching the JDK build number). The Hotspot minor version will match the update version defined in make/jprt.prtoperties: java version 1.8.0_66-internal # Java(TM) SE Runtime Environment (build 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) (4) Since the version string is not actually changing, I do not expect this to have any impact on external tools or apps, but let me know if so. Thanks -- Alejandro
[8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK
Please review the following change that allows setting the Hotspot minor version and build number to that of the --with-update-version and --with-build-number configure parameters when provided. 8u builds only. webrev: http://javaweb.us.oracle.com/~amurillo/webrevs/8079410/ Background (since bug was originally filed as internal): Currently, for 8u builds and earlier, the hotspot version looks like this (remnant from the hotspot express days): Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) By convention, minor version (66 above) always matches the JDK update version and hotspot build number is managed independently of the JDK build number. Both values are defined by default in hotspot/make/hotspot_version. With this change they can now be setup using the corresponding JDK configure parameters. Consequences: (1) For promoted and other milestone builds, the hotspot minor version will corresponds to the JDK update version and the hotspot build number will match the JDK build number. (2) Hotspot snapshots will no longer need to change the hotspot build number as that will be set at promotion time (matching the JDK build number). Since this is stored in the file mentioned above, a repo push (and the corresponding bug) was required to change it. That will no longer be necessary. (3) Since JPRT configures both the update and build numbers, when building via JPRT, the hotspot build number for those builds will always be 'b00' (matching the JDK build number). The Hotspot minor version will match the update version defined in make/jprt.prtoperties: java version 1.8.0_66-internal # Java(TM) SE Runtime Environment (build 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) (4) Since the version string is not actually changing, I do not expect this to have any impact on external tools or apps, but let me know if so. Thanks -- Alejandro
RFR JDK-8130092: Backout Update jprt.properties with property listing tests subtrees
We need to backout this change JDK-8098834: https://bugs.openjdk.java.net/browse/JDK-8098834 as it is impeding the execution of some jprt tests for control jobs and hence the integration of jdk9/hs into jdk9/dev Webrev: http://cr.openjdk.java.net/~amurillo/9/8130092/ CR: https://bugs.openjdk.java.net/browse/JDK-8130092 Thanks -- Alejandro
Re: RFR JDK-8130092: Backout Update jprt.properties with property listing tests subtrees
sounds good David Thanks Alejandro On 6/29/2015 6:34 PM, David Holmes wrote: Looks good Alejandro! We'll work with Dmitry to figure out the problem. Thanks, David On 30/06/2015 10:31 AM, Alejandro E Murillo wrote: We need to backout this change JDK-8098834: https://bugs.openjdk.java.net/browse/JDK-8098834 as it is impeding the execution of some jprt tests for control jobs and hence the integration of jdk9/hs into jdk9/dev Webrev: http://cr.openjdk.java.net/~amurillo/9/8130092/ CR: https://bugs.openjdk.java.net/browse/JDK-8130092 Thanks -- Alejandro
Re: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)
On 6/10/2015 6:13 AM, Magnus Ihse Bursie wrote: On 2015-06-10 11:58, David Holmes wrote: Hi Magnus, Generally looks good - a few comments/queries below. In general, I believe most issues you found are valid. :-) However, as I said before in this thread, I'd like to see them resolved in the needed follow-up patches. The source code changes in Hotspot and JDK are inadequate to fully implement JEP-223, so these areas will need to be rewritten anyhow. Are you okay with resolving these issues later? On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: Here's an updated webrev, which fixes the typos that were pointed out by reviewers: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ common/autoconf/version-numbers Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of the version info? (Even if all zeroes presently.) So that's a tricky one. :- The question here is, I think, does it make sense to update version-numbers when we do a security (9.0.1) or minor (9.1.0) release? Looking historically, the version-numbers file have not been changed for the 8u family. The only change was going from 8 to 9 when creating the new jdk9 forest. That was what I based my decition to only have the major number in the file. (The rest of the version string is set by configure flags when building, in Oracle case by the RE team.) If it makes sense to put the minor/security/patch numbers here, I won't oppose it, but I guess we have until the first such release to figure out what's best, and that likely includes discussion with RE and possibly other consumers in the community (RedHat etc). --- Looking at hotspot changes I can't convince myself that the new streamlined version variables will capture things like fastdebug. Will that filter through via configure variables? The fastdebug label has been handled as a less valued token in the JEP-223 process. Right now there's no mention of it at all in the version string proposal in the JEP. As I understand it, Iris is about to propose an amendment which will just make fastdebug be a part of the OPT string. I'm not entirely happy with that myself, but that's the way it's decided. So wherever you can see the OPT string, you'll see the debug level tag. Currently, however, that's not how it is implemented in this patch. Since no decision was made on this (and it's still not formally decided), I had to pick a route to go forward. The current patch will instead put the fastdebug label as part of the PRE string (that's the reason for the pre-base and pre-debuglevel arguments to configure). If the planned changes goes into the JEP, this'll change to make the debuglevel tag a part of the OPT string instead. --- make/*/makefiles/vm.make Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a stand-alone hotspot build?) The hotspot JEP-223 work initially made by Alejandro kept support for stand-alone hotspot builds. I made additional changes on top of that, which still tried to cater for stand-alone builds. At this very moment I'm not sure if stand-alone hotspot builds are supposed to work or not, but I've tried to not change the situation with this patch. There are two future changes coming down the pipe: One is the additional JEP-223 work needed for Hotspot. I know Alejandro had plans for redesigning the API between Hotspot and the JDK, so no JDK version strings should be compiled into the JVM, but all of it extracted during an API in runtime. That would make most (all?) of the makefile changes in hotspot irrelevant. However, that implementation is not even started, so it's needed for the time being. There's already an API used by Hotspot to get JDK version values. I'm investigating using that and extend it if required. yes, there is a lot stuff in the hotspot code that should be removed (mostly in the makefiles) and I'm not against making those changes now, I just think they are somewhat out of the scope of this project. And should be done as individual RFEs or as part of the upcoming hotspot makefile refactoring. Alejandro The second change is the build-infra hotspot makefile rewrite. When that happens, stand-alone builds will definitely disappear, and if Hotspot still needs make support for version strings, then the logical choice is to use VERSION_CFLAGS. Ok? --- hotspot/src/share/vm/prims/jvm.h jdk/src/java.base/share/native/include/jvm.h I think this comment is way out of date: /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER is set to bNN) * It will be zero for internal builds. */ and can be completely removed. Even if still true, mention of an RE build has no place in OpenJDK sources. Yep, agree. Follow-up patch, right? --- hotspot/src/share/vm/runtime/java.cpp I think a lot of the modified code is obsolete post Hotspot Express - which makes it
Re: RFR: JDK-8073166: Unable to successfully build the merge of jdk9/hs with jdk9/dev
Thanks for quickly fixing this Erik, reran the snapshot and everything built fine Alejandro On 2/16/2015 4:08 AM, Alan Bateman wrote: On 16/02/2015 10:57, Erik Joelsson wrote: Hello, When merging jdk9/dev and jdk9/hs, the following message appears and the build fails: gmake[2]: *** No rule to make target 'jdk.runtime-java', needed by 'jdk.runtime-libs'. Stop. gmake[2]: *** Waiting for unfinished jobs : # Declare dependencies from module-lib to module-java - # Skip jdk.jdwp.agent as it contains no java code. - $(foreach m, $(filter-out jdk.jdwp.agent, $(LIBS_MODULES)), $(eval $m-libs: $m-java)) + # Skip modules that do not have java source. + $(foreach m, $(filter $(JAVA_MODULES), $(LIBS_MODULES)), $(eval $m-libs: $m-java)) This looks okay to me and avoids a few other issues that we could potentially have going forward (as there are a few other adjustments needed to the module graph in JEP 200, also some naming and content issues to resolve too). -Alan. -- Alejandro
Re: build failure in perfMemory_solaris.cpp?
by the timing when this started to happen, I believe
this was caused by the CPU changes integrated into jdk9/dev
on Wednesday (they didn't come through jdk9/hs).
I went to check those changesets and this looks like the prime suspect:
Changeset: c656c7540cb1
Author:gthornbr
Date: 2014-11-17 15:51 -0500
URL:http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c656c7540cb1
8050807: Better performing performance data handling
Reviewed-by: dcubed, pnauman, ctornqvi, dholmes, mschoene
Contributed-by:gerald.thornbr...@oracle.com
! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/share/vm/utilities/vmError.cpp
Jerry, I'm assigning the bug to you. Check it out and reassign if needed
Alejandro
On 1/23/2015 11:26 AM, Anthony Scarpino wrote:
I created one:
https://bugs.openjdk.java.net/browse/JDK-8071501
Tony
On 01/23/2015 10:07 AM, Bradford Wetmore wrote:
Is there a bug id yet? I haven't seen one showing up in a quick search
for dd_fd or perfMemory_solaris.cpp.
For the record, I'm on what I think is the required platform/compilers:
% uname -a
SunOS sca00bkv 5.11 11.1 sun4v sparc sun4v
% more /etc/release
Oracle Solaris 11.1 SPARC
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights
reserved.
Assembled 06 November 2013
% grep BUILD_CC out.txt
BUILD_CC:= /java/devtools/sparc/SUNWspro/SS12u3/bin/cc
Brad
On 1/23/2015 8:32 AM, Volker Simonis wrote:
Hi,
we can see the same in our nightly OpenJDK 8/9 builds
(http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be
interested in a solution as well.
Thanks,
Volker
On Fri, Jan 23, 2015 at 5:19 AM, David Holmes
david.hol...@oracle.com wrote:
Hi Anthony,
On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
Hi,
I just pulled the jdk9/dev gate today and hit a build failure on
SPARC
Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot. I'm
using SS12u3 compilers. Anyone else see a similar error or know what
might be going wrong?
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 337:
Error:
dd_fd is not a member of DIR.
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 369:
Error:
dd_fd is not a member of DIR.
gmake[8]: *** [perfMemory_solaris.o] Error 2
This code was brought in via the recent CPU integration of bug
8050807. (Hi
Jerry! - cc'd)
It looks like Solaris has two potential definitions of DIR:
#if defined(__USE_LEGACY_PROTOTYPES__)
/* traditional SVR4 definition */
typedef struct {
int dd_fd; /* file descriptor */
int dd_loc; /* offset in block */
int dd_size;/* amount of valid data */
char*dd_buf;/* directory block */
} DIR; /* stream data from opendir() */
#else
/* default definition (POSIX conformant) */
typedef struct {
int d_fd; /* file descriptor */
int d_loc; /* offset in block */
int d_size; /* amount of valid data */
char*d_buf; /* directory block */
} DIR; /* stream data from opendir() */
#endif /* __USE_LEGACY_PROTOTYPES__ */
I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably
either
something in Solaris 11.1, or something in SS12u3 is causing this
difference.
David
thanks
Tony
--
Alejandro
Re: RFR: JDK-8062521: 9-dev glinux/elinux configure: error: Could not find all X11 headers since 2014-10-28
On 10/30/2014 7:32 AM, Erik Joelsson wrote: On 2014-10-30 13:52, David Holmes wrote: On 30/10/2014 10:42 PM, Erik Joelsson wrote: I think it would fail in JPRT too, I never ran JPRT with JDK-8062159 unfortunately. I assume very few people run jdk9-dev in JPRT with embedded platforms. All hotspot integrations are doing it. You need -testset hotspot on the jprt submit. It just occurred to me that you wouldn't likely have been aware of that. But all configure related changes must be tested against all builds. Yes, I figured that out and tested this fix with it, so now I know. That's also what I meant by very few jdk9/dev jobs are running with -testset hotspot. The hotspot repos do it all the time, but JDK-8062159 hasn't gotten that far yet. Hi Erik, you are right, the hotspot snapshot job would have caught that, as it merges jdk9/hs with jdk9/dev. BTW, I'm planning to start the snapshot of jdk9/hs for jdk9/dev tonight or early tomorrow morning. Doesn't look like you have pushed the fix, Can you push the fix by the end of the day today? thanks Alejandro /Erik David /Erik On 2014-10-30 13:31, David Holmes wrote: Hi Erik, Seems reasonable. Did this not fail when run through JPRT? Is it something shell specific? David On 30/10/2014 9:40 PM, Erik Joelsson wrote: Hello, In my fix for JDK-8062159 Fix Xrender check to work with sysroot, I added $SYSROOT_CFLAGS to the CFLAGS used when looking for X11 headers. Unfortunately, this didn't work with at least one of the cross compile kits we use. The reason for the failure is in the definition of SYSROOT_CFLAGS: SYSROOT_CFLAGS=--sysroot=\$SYSROOT\ It adds explicit extra quotes around the value. These quotes seem to not be a problem when the variable is used in a recipe in make, but when the variable is used directly in the shell from configure, the extra quotes become part of the argument to gcc. Gcc will fail resolving the path and the test for X11 headers fails. I see no reason for having these quotes other than if we expected spaces in the path to the sysroot, which I sure hope we aren't, as we do not employ any such protection for any other paths that I know of. The fix is then simply to remove the extra quotes when using gcc. I chose not to change the other defintions of the variable as they seem to be working. Bug: https://bugs.openjdk.java.net/browse/JDK-8062521#comment-13570672 Patch: diff -r ce3b04a39f79 common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 +++ b/common/autoconf/flags.m4 @@ -136,8 +136,8 @@ SYSROOT_CFLAGS=-isysroot \$SYSROOT\ -iframework\$SYSROOT/System/Library/Frameworks\ SYSROOT_LDFLAGS=$SYSROOT_CFLAGS elif test x$TOOLCHAIN_TYPE = xgcc; then - SYSROOT_CFLAGS=--sysroot=\$SYSROOT\ - SYSROOT_LDFLAGS=--sysroot=\$SYSROOT\ + SYSROOT_CFLAGS=--sysroot=$SYSROOT + SYSROOT_LDFLAGS=--sysroot=$SYSROOT elif test x$TOOLCHAIN_TYPE = xclang; then SYSROOT_CFLAGS=-isysroot \$SYSROOT\ SYSROOT_LDFLAGS=-isysroot \$SYSROOT\ /Erik -- Alejandro
Re: RFR 8030011: Update Hotspot version string output
Thanks Vladimir
Alejandro
On 4/23/2014 11:53 AM, Vladimir Kozlov wrote:
Looks good.
Thanks,
Vladimir
On 4/22/14 7:32 PM, Alejandro E Murillo wrote:
On 4/22/2014 6:12 PM, Vladimir Kozlov wrote:
On 4/22/14 4:42 PM, Alejandro E Murillo wrote:
On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
Hi Alejandro,
I don't think we need to rename make/hotspot_version file. It is
still
used to set JVM's version string and not JDK's version.
Next assert message is not consistent with previous messages which
use
vm, I think it should be vm here too:
DEBUG_ONLY(assert_digits(vm_build_num, offset, wrong JDK build
number));
we do not have hotspot build number anymore, so I think we should not
mention hotspot build numberls
Can we simple say wrong build number?
sounds good!
So you don't want update build number in make/*_version files? ;)
Yes, I see in your example of JPRT build VM does not have build number
anymore.
it's gone!
Abstract_VM_Version::jvm_version() should include micro version. See
JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
jdk/src/share/javavm/export/jvm.h.
I added that here, is that what you are referring?
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html
No, I mean next code should encode micro version too:
unsigned int Abstract_VM_Version::jvm_version() {
return ((Abstract_VM_Version::vm_major_version() 0xFF) 24) |
((Abstract_VM_Version::vm_minor_version() 0xFF) 16) |
+ ((Abstract_VM_Version::vm_micro_version() 0xFF) 8) |
(Abstract_VM_Version::vm_build_number() 0xFF);
}
you are right. I recall having added that earlier :(
it's back int the webrev
Use corresponding test in jdk for testing of these changes:
jdk/test/sun/misc/Version/Version.java
yeah, I run that test as part of jprt full builds,
That test handles both JDK and Hotspot express versions
Good.
jvm.h: Next comment is not accurate:
+/* VM version string: JDK version string */
If we build VM separately (for example, in JPRT) VM version will not
be JDK version in which VM is installed. It will take numbers either
from passed make parameters or from make/hotspot_version. I think it
should say:
+/* VM version string follows the JDK release version naming
convention
+ * major.minor.micro-bxx[-identifier][-debug_flavor]
Based on your examples [-identifier][-debug_flavor] is still used
so it should be reflected in the comment.
Let me make that explicit.
Don't remove next comments from vm_version.cpp but fix it (follow
the
JDK release):
-// HOTSPOT_RELEASE_VERSION must follow the release version naming
convention
-// major_ver.minor_ver-bnn[-identifier][-debug_target]
ok
You did not show default VM version example when VM is built locally
by engineer.
It will be similar to the hotspot only jprt build. There will be a
mismatch,
I tested by dropping the resulting libjvm into a promoted build,
so it
looks like this:
java version 1.9.0-ea
Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed
mode)
okay
Please test that correct version string is constructed when you build
VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'
Haven't tested that, thanks for pointing that out.
thank you
Next comment change in buildtree.make is not correct because
HOTSPOT_RELEASE_VERSION make parameter does not include
HOTSPOT_BUILD_VERSION:
-# HOTSPOT_RELEASE_VERSION - major.minor-bnn (11.0-b07)
+# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus
HOTSPOT_BUILD_VERSION
see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
let me check that again
I think next change in make/defs.make is not safe (removing make
parameter) due to complexity of our builds:
-MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
I checked the code, and HOTSPOT_RELEASE_VERSION is only used in
vm_version.cpp,
so I think is fine to remove it. Note that if we keep it there, since
the JDK version string
sometimes might have time stamps, it may affect ccache, that's why at
some point they
separated the options for vm_version.cpp from the options for other
components. See this
comment on vm,make:
# This is VERY important! The version define must only be supplied to
vm_version.o
# If not, ccache will not re-use the cache at all, since the version
string might contain
# a time and date.
I was concern that it will not be passed into nested make so that, for
example, buildtree.make will not get it.
I see. I don't think it's needed
I think I incorporated all the changes David, John and you suggested and
started some sanity testing;
Here's is the latest webrev:
http://cr.openjdk.java.net/~amurillo/9/8030011/
Please review (don't forget to refresh each file on your browser) and
let me know if I missed anything
Re: RFR 8030011: Update Hotspot version string output
On 4/24/2014 2:52 PM, John Coomes wrote: Alejandro E Murillo (alejandro.muri...@oracle.com) wrote: ... I think I incorporated all the changes David, John and you suggested and started some sanity testing; Here's is the latest webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Please review (don't forget to refresh each file on your browser) and let me know if I missed anything. thanks guys! Looks good. Might be nice to shorten the rest of the assert messages in vm_version.cpp to match the one for the build number, e.g., bad major version). -John Will do, thanks John -- Alejandro
Re: RFR 8030011: Update Hotspot version string output
On 4/21/2014 1:18 PM, Vladimir Kozlov wrote: Hi Alejandro, I don't think we need to rename make/hotspot_version file. It is still used to set JVM's version string and not JDK's version. Next should be 2014 (I think David pointed it too but there is no new webrev): HOTSPOT_VM_COPYRIGHT=Copyright 2013 correct. I haven't changed that yet If you pass major, micro etc numbers to avoid parsing you need to verify that constructed from them string is equal to passed HOTSPOT_RELEASE_VERSION. yes, there's a test for that, which is run when I submit a full jprt job. Next assert message is not consistent with previous messages which use vm, I think it should be vm here too: DEBUG_ONLY(assert_digits(vm_build_num, offset, wrong JDK build number)); we do not have hotspot build number anymore, so I think we should not mention hotspot build numberls Abstract_VM_Version::jvm_version() should include micro version. See JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in jdk/src/share/javavm/export/jvm.h. I added that here, is that what you are referring? http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html Use corresponding test in jdk for testing of these changes: jdk/test/sun/misc/Version/Version.java yeah, I run that test as part of jprt full builds, That test handles both JDK and Hotspot express versions jvm.h: Next comment is not accurate: +/* VM version string: JDK version string */ If we build VM separately (for example, in JPRT) VM version will not be JDK version in which VM is installed. It will take numbers either from passed make parameters or from make/hotspot_version. I think it should say: +/* VM version string follows the JDK release version naming convention + * major.minor.micro-bxx[-identifier][-debug_flavor] Based on your examples [-identifier][-debug_flavor] is still used so it should be reflected in the comment. Let me make that explicit. Don't remove next comments from vm_version.cpp but fix it (follow the JDK release): -// HOTSPOT_RELEASE_VERSION must follow the release version naming convention -// major_ver.minor_ver-bnn[-identifier][-debug_target] ok You did not show default VM version example when VM is built locally by engineer. It will be similar to the hotspot only jprt build. There will be a mismatch, I tested by dropping the resulting libjvm into a promoted build, so it looks like this: java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b01) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed mode) Please test that correct version string is constructed when you build VM using make/build.sh, for example 'sh make/build.sh debug LP64=1' Haven't tested that, thanks for pointing that out. Next comment change in buildtree.make is not correct because HOTSPOT_RELEASE_VERSION make parameter does not include HOTSPOT_BUILD_VERSION: -# HOTSPOT_RELEASE_VERSION - major.minor-bnn (11.0-b07) +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus HOTSPOT_BUILD_VERSION see JPRT logs where HOTSPOT_BUILD_VERSION is set separately. let me check that again I think next change in make/defs.make is not safe (removing make parameter) due to complexity of our builds: -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION) I checked the code, and HOTSPOT_RELEASE_VERSION is only used in vm_version.cpp, so I think is fine to remove it. Note that if we keep it there, since the JDK version string sometimes might have time stamps, it may affect ccache, that's why at some point they separated the options for vm_version.cpp from the options for other components. See this comment on vm,make: # This is VERY important! The version define must only be supplied to vm_version.o # If not, ccache will not re-use the cache at all, since the version string might contain # a time and date. I know that windows build is mess. Please verify it carefully. For example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but build.make uses them: JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER) That was a typo. Note that I changed the left handside, so they were incorrectly reassigning those. The places were JDK_MINOR_VER is used, the value is read from jdk_version (formerly hotspot_version) Thanks a lot for the feedback! Alejandro Regards, Vladimir On 4/21/14 10:13 AM, Alejandro E Murillo wrote: On 4/18/2014 6:50 PM, John Coomes wrote: Alejandro E Murillo (alejandro.muri...@oracle.com) wrote: Please review this change to make the hotspot related output produced by java -version match the corresponding JDK output: webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 Note that we initially wanted to obtain more information from the repo
Re: RFR 8030011: Update Hotspot version string output
On 4/22/2014 6:12 PM, Vladimir Kozlov wrote:
On 4/22/14 4:42 PM, Alejandro E Murillo wrote:
On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
Hi Alejandro,
I don't think we need to rename make/hotspot_version file. It is still
used to set JVM's version string and not JDK's version.
Next assert message is not consistent with previous messages which use
vm, I think it should be vm here too:
DEBUG_ONLY(assert_digits(vm_build_num, offset, wrong JDK build
number));
we do not have hotspot build number anymore, so I think we should not
mention hotspot build numberls
Can we simple say wrong build number?
sounds good!
So you don't want update build number in make/*_version files? ;)
Yes, I see in your example of JPRT build VM does not have build number
anymore.
it's gone!
Abstract_VM_Version::jvm_version() should include micro version. See
JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
jdk/src/share/javavm/export/jvm.h.
I added that here, is that what you are referring?
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html
No, I mean next code should encode micro version too:
unsigned int Abstract_VM_Version::jvm_version() {
return ((Abstract_VM_Version::vm_major_version() 0xFF) 24) |
((Abstract_VM_Version::vm_minor_version() 0xFF) 16) |
+ ((Abstract_VM_Version::vm_micro_version() 0xFF) 8) |
(Abstract_VM_Version::vm_build_number() 0xFF);
}
you are right. I recall having added that earlier :(
it's back int the webrev
Use corresponding test in jdk for testing of these changes:
jdk/test/sun/misc/Version/Version.java
yeah, I run that test as part of jprt full builds,
That test handles both JDK and Hotspot express versions
Good.
jvm.h: Next comment is not accurate:
+/* VM version string: JDK version string */
If we build VM separately (for example, in JPRT) VM version will not
be JDK version in which VM is installed. It will take numbers either
from passed make parameters or from make/hotspot_version. I think it
should say:
+/* VM version string follows the JDK release version naming
convention
+ * major.minor.micro-bxx[-identifier][-debug_flavor]
Based on your examples [-identifier][-debug_flavor] is still used
so it should be reflected in the comment.
Let me make that explicit.
Don't remove next comments from vm_version.cpp but fix it (follow the
JDK release):
-// HOTSPOT_RELEASE_VERSION must follow the release version naming
convention
-// major_ver.minor_ver-bnn[-identifier][-debug_target]
ok
You did not show default VM version example when VM is built locally
by engineer.
It will be similar to the hotspot only jprt build. There will be a
mismatch,
I tested by dropping the resulting libjvm into a promoted build, so it
looks like this:
java version 1.9.0-ea
Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed
mode)
okay
Please test that correct version string is constructed when you build
VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'
Haven't tested that, thanks for pointing that out.
thank you
Next comment change in buildtree.make is not correct because
HOTSPOT_RELEASE_VERSION make parameter does not include
HOTSPOT_BUILD_VERSION:
-# HOTSPOT_RELEASE_VERSION - major.minor-bnn (11.0-b07)
+# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus
HOTSPOT_BUILD_VERSION
see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
let me check that again
I think next change in make/defs.make is not safe (removing make
parameter) due to complexity of our builds:
-MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
I checked the code, and HOTSPOT_RELEASE_VERSION is only used in
vm_version.cpp,
so I think is fine to remove it. Note that if we keep it there, since
the JDK version string
sometimes might have time stamps, it may affect ccache, that's why at
some point they
separated the options for vm_version.cpp from the options for other
components. See this
comment on vm,make:
# This is VERY important! The version define must only be supplied to
vm_version.o
# If not, ccache will not re-use the cache at all, since the version
string might contain
# a time and date.
I was concern that it will not be passed into nested make so that, for
example, buildtree.make will not get it.
I see. I don't think it's needed
I think I incorporated all the changes David, John and you suggested and
started some sanity testing;
Here's is the latest webrev:
http://cr.openjdk.java.net/~amurillo/9/8030011/
Please review (don't forget to refresh each file on your browser) and
let me know if I missed anything.
thanks guys!
--
Alejandro
Re: RFR 8030011: Update Hotspot version string output
On 4/18/2014 6:50 PM, John Coomes wrote:
Alejandro E Murillo (alejandro.muri...@oracle.com) wrote:
Please review this change to make the hotspot related output produced by
java -version
match the corresponding JDK output:
webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
Note that we initially wanted to obtain more information from the repo
being built and add
it to the hotspot version output, but that will require changes in the
JPRT, so
we have decided to split the change in 2 bugs. One to make the version match
(above webrev) and another one, an RFE, to add additional information
extracted from the repo.
Generally looks good, but I agree with David that the long lines
should be wrapped, and it might even be clearer to separate them into
two variables, e.g.,
JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION=\$(JDK_MAJOR_VERSION)\ \
-DJDK_MINOR_VERSION=\$(JDK_MINOR_VERSION)\ \
... other defs ...
VERSION_DEFS = -DHOTSPOT_RELEASE_VERSION=\$(HS_BUILD_VER)\ \
-DJRE_RELEASE_VERSION=\$(JRE_RELEASE_VER)\ \
$(JDK_VERSION_DEFS)
Also the change to this part of vm.make differs between at least the
solaris version and the linux version (didn't check bsd or windows).
Please make them all consistent.
Note that in the current version of vm_version.cpp, there is no error
checking in product mode,
I was suggested to make that explicit.
I like the additional error checking. I think you could eliminate the
4 copies of similar code with a function that does the checks and sets
the field, e.g.,
void set_version_field(int * version_field, const char * version_str,
const char * const assert_msg) {
if (version_str != NULL ...) {
DEBUG_ONLY(assert_digits(version_str, assert_msg));
*version_field = atoi(version_str);
}
}
-John
Thanks John,
working on adding these changes and sanity testing
Thanks
--
Alejandro
Re: RFR 8030011: Update Hotspot version string output
Hi David, thanks for the feedback, see below On 4/9/2014 8:38 PM, David Holmes wrote: Hi Alejandro, Given we have to maintain the JDK version information in two places (top level repo and hotspot repo) wouldn't it have been simpler to keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set the major/minor/build values to match those of the JDK version? The file is still used, just renamed as only jdk info is in there. HOTSPOT_RELEASE_VERSION was also kept, we just don't get the major,minor,micro and build number from it anymore, mainly it is now set very similar to the JDK_RELEASE_VERSION (plus other values), and that format it's not fixed as it used to be for hotspot express. Those values (major,minor,micro and build number) are already defined in the makefiles, so we just pass them to vm_version.cpp, so no more parsing in it. That aside, in jdk_version file hotspot copyright should now be 2014 will fix that */vm.make: This line is way too long. ! VM_VER_DEFS = -DHOTSPOT_RELEASE_VERSION=\$(HS_BUILD_VER)\ -DJRE_RELEASE_VERSION=\$(JRE_RELEASE_VER)\ -DJDK_MAJOR_VERSION=\$(JDK_MAJOR_VERSION)\ -DJDK_MINOR_VERSION=\$(JDK_MINOR_VERSION)\ -DJDK_MICRO_VERSION=\$(JDK_MICRO_VERSION)\ -DJDK_BUILD_NUMBER=\$(JDK_BUILD_NUMBER)\ ok Not clear why we suddenly need defines for all the component pieces either. You could have kept the HS_XXX variables, just adding the micro part. as mentioned above, the micro part was actually added to HOTSPOT_RELEASE_VERSION, we just don't get those values by parsing it, so we just pass those values to the vm_version.cpp, since they are already defined in the makefiles. The format of the JDK version is not that fixed. Thanks Alejandro David On 10/04/2014 10:15 AM, Alejandro E Murillo wrote: Please review this change to make the hotspot related output produced by java -version match the corresponding JDK output: webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 Note that we initially wanted to obtain more information from the repo being built and add it to the hotspot version output, but that will require changes in the JPRT, so we have decided to split the change in 2 bugs. One to make the version match (above webrev) and another one, an RFE, to add additional information extracted from the repo. Note that in the current version of vm_version.cpp, there is no error checking in product mode, I was suggested to make that explicit. Release Engineering did some testing and I also ran several cases with full and just hotspot JPRT builds. Here is a summary of how the new output compares to the old one: (1) Release Engineering builds (9-dev): from jdk9-dev build: java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode) compared with what we currently have java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (2) Release Engineering builds (jdk9): java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode) compared with what we currently have java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (3) JPRT Full builds: java version 1.9.0-internal # Java(TM) SE Runtime Environment (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00) # Java HotSpot(TM) Server VM (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode) (4) JPRT hotspot only builds: java version 1.9.0-ea-fastdebug # Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06) # Java HotSpot(TM) Server VM (build 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed mode) in this one the built VM is inserted into a promoted build bundle, since we do not have the JDK build number info in the hotspot repo, we can't match the build number in the JDK portion. With the RFE mentioned above, we can extract the build info from the repo and add it to the hotspot portion. I want to mention, that this may change once the new JDK version change is implemented but we don't know when that will be implemented yet, so we need to go ahead with this to get rid of the old hotspot express output. And most of these changes will still have to be done anyways BTW, john Coomes and Dan Daugherty provided feedback in some pieces of this webrev, but I need full reviews now. Thanks -- Alejandro
RFR 8030011: Update Hotspot version string output
Please review this change to make the hotspot related output produced by java -version match the corresponding JDK output: webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 Note that we initially wanted to obtain more information from the repo being built and add it to the hotspot version output, but that will require changes in the JPRT, so we have decided to split the change in 2 bugs. One to make the version match (above webrev) and another one, an RFE, to add additional information extracted from the repo. Note that in the current version of vm_version.cpp, there is no error checking in product mode, I was suggested to make that explicit. Release Engineering did some testing and I also ran several cases with full and just hotspot JPRT builds. Here is a summary of how the new output compares to the old one: (1) Release Engineering builds (9-dev): from jdk9-dev build: java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode) compared with what we currently have java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (2) Release Engineering builds (jdk9): java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode) compared with what we currently have java version 1.9.0-ea Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (3) JPRT Full builds: java version 1.9.0-internal # Java(TM) SE Runtime Environment (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00) # Java HotSpot(TM) Server VM (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode) (4) JPRT hotspot only builds: java version 1.9.0-ea-fastdebug # Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06) # Java HotSpot(TM) Server VM (build 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed mode) in this one the built VM is inserted into a promoted build bundle, since we do not have the JDK build number info in the hotspot repo, we can't match the build number in the JDK portion. With the RFE mentioned above, we can extract the build info from the repo and add it to the hotspot portion. I want to mention, that this may change once the new JDK version change is implemented but we don't know when that will be implemented yet, so we need to go ahead with this to get rid of the old hotspot express output. And most of these changes will still have to be done anyways BTW, john Coomes and Dan Daugherty provided feedback in some pieces of this webrev, but I need full reviews now. Thanks -- Alejandro
Re: How to increment JDK_MINOR_VERSION for JDK 9? -- request for review
Hi David, since the hoptspot version should match the jdk version, I actually plan to remove this file as part of the fix for: https://bugs.openjdk.java.net/browse/JDK-8030011 and set those values appropriately thanks Alejandro On 12/19/2013 12:14 AM, David Holmes wrote: Joe, hotspot/make/hotspot_version also defines: JDK_MAJOR_VER=1 JDK_MINOR_VER=8 JDK_MICRO_VER=0 David H. - On 19/12/2013 4:19 AM, Joe Darcy wrote: On 12/16/2013 02:14 PM, Joe Darcy wrote: On 12/15/2013 09:50 PM, Joe Darcy wrote: On 12/10/2013 03:51 PM, David Katleman wrote: On 12/10/2013 3:33 PM, Joseph Darcy wrote: Hello, Looking ahead to JDK 9, a build 01 change that is needed is updating the JDK_MINOR_VERSION setting in the build from 8 to 9: JDK-8000962 Update JDK_MINOR_VERSION for JDK 9 https://bugs.openjdk.java.net/browse/JDK-8000962 I poked around a bit, but didn't see where this needs to be set. The value of this variable gets used in numerous places throughout the JDK, including in system properties. How can this be updating in the new build? That would be in common/autoconf/version-numbers Dave An update, I've done a build after bumping up that value, but I ran into testing issue. It seems that the jtreg needs a minor update to allow for the successful running of TestNG tests after the minor version is incremented; I've contacted the jtreg team and a fix is in progress. Thanks, -Joe An update on the update: a new jtreg build resolves the TestNG issue. After a new build of jtreg is promoted, I'll go ahead with the JDK_MINOR_VERSIO update. Cheers, -Joe Please review this increment in common/autoconf/version-numbers along with test updates to work around a HotSpot bug: http://cr.openjdk.java.net/~darcy/8000962.0/ Patch below. Thanks, -Joe --- old/common/autoconf/version-numbers2013-12-18 09:12:06.0 -0800 +++ new/common/autoconf/version-numbers2013-12-18 09:12:06.0 -0800 @@ -24,7 +24,7 @@ # JDK_MAJOR_VERSION=1 -JDK_MINOR_VERSION=8 +JDK_MINOR_VERSION=9 JDK_MICRO_VERSION=0 JDK_UPDATE_VERSION= LAUNCHER_NAME=openjdk --- old/langtools/test/tools/javac/MethodParameters/AnnotationTest.java 2013-12-18 09:12:07.0 -0800 +++ new/langtools/test/tools/javac/MethodParameters/AnnotationTest.java 2013-12-18 09:12:07.0 -0800 @@ -24,6 +24,7 @@ /* * @test * @bug 8006582 + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp * @summary javac should generate method parameters correctly. * @build Tester * @compile -parameters AnnotationTest.java --- old/langtools/test/tools/javac/MethodParameters/AnonymousClass.java 2013-12-18 09:12:07.0 -0800 +++ new/langtools/test/tools/javac/MethodParameters/AnonymousClass.java 2013-12-18 09:12:07.0 -0800 @@ -24,6 +24,7 @@ /* * @test * @bug 8006582 + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp * @summary javac should generate method parameters correctly. * @build Tester * @compile -parameters AnonymousClass.java --- old/langtools/test/tools/javac/MethodParameters/CaptureTest.java 2013-12-18 09:12:07.0 -0800 +++ new/langtools/test/tools/javac/MethodParameters/CaptureTest.java 2013-12-18 09:12:07.0 -0800 @@ -24,6 +24,7 @@ /* * @test * @bug 8015701 + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp * @summary Test method parameter attribute generation with captured locals. * @compile -parameters CaptureTest.java * @run main CaptureTest --- old/langtools/test/tools/javac/MethodParameters/Constructors.java 2013-12-18 09:12:08.0 -0800 +++ new/langtools/test/tools/javac/MethodParameters/Constructors.java 2013-12-18 09:12:08.0 -0800 @@ -24,6 +24,7 @@ /* * @test * @bug 8006582 + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp * @summary javac should generate method parameters correctly. * @build Tester * @compile -parameters Constructors.java --- old/langtools/test/tools/javac/MethodParameters/EnumTest.java 2013-12-18 09:12:08.0 -0800 +++ new/langtools/test/tools/javac/MethodParameters/EnumTest.java 2013-12-18 09:12:08.0 -0800 @@ -24,6 +24,7 @@ /* * @test * @bug 8006582 8008658 + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp * @summary javac should generate method parameters correctly. * @build Tester * @compile -parameters EnumTest.java --- old/langtools/test/tools/javac/MethodParameters/InstanceMethods.java 2013-12-18 09:12:09.0 -0800 +++ new/langtools/test/tools/javac/MethodParameters/InstanceMethods.java 2013-12-18 09:12:09.0 -0800 @@ -24,6 +24,7 @@ /* * @test * @bug 8006582 + * @ignore 8030656 Bad version check for parameter information in
Re: How to increment JDK_MINOR_VERSION for JDK 9? -- request for review
On 12/19/2013 6:15 PM, David Holmes wrote: On 20/12/2013 2:22 AM, Alejandro E Murillo wrote: Hi David, since the hoptspot version should match the jdk version, I actually plan to remove this file as part of the fix for: https://bugs.openjdk.java.net/browse/JDK-8030011 and set those values appropriately Okay but wherever they are set needs to modified appropriately. In a full configure based build these should come in via spec.gmk (they don't at present IIRC) but we still need them somewhere in hotspot repo for hotspot only builds. Exactly, they are only used for hotspot only builds. Rectifying what I said, I plan to remove the hotspot_version file, but I'll save those JDK_* defs somewhere else (with minor ver set to 9) Alejandro David thanks Alejandro On 12/19/2013 12:14 AM, David Holmes wrote: Joe, hotspot/make/hotspot_version also defines: JDK_MAJOR_VER=1 JDK_MINOR_VER=8 JDK_MICRO_VER=0 David H. - On 19/12/2013 4:19 AM, Joe Darcy wrote: On 12/16/2013 02:14 PM, Joe Darcy wrote: On 12/15/2013 09:50 PM, Joe Darcy wrote: On 12/10/2013 03:51 PM, David Katleman wrote: On 12/10/2013 3:33 PM, Joseph Darcy wrote: Hello, Looking ahead to JDK 9, a build 01 change that is needed is updating the JDK_MINOR_VERSION setting in the build from 8 to 9: JDK-8000962 Update JDK_MINOR_VERSION for JDK 9 https://bugs.openjdk.java.net/browse/JDK-8000962 I poked around a bit, but didn't see where this needs to be set. The value of this variable gets used in numerous places throughout the JDK, including in system properties. How can this be updating in the new build? That would be in common/autoconf/version-numbers Dave An update, I've done a build after bumping up that value, but I ran into testing issue. It seems that the jtreg needs a minor update to allow for the successful running of TestNG tests after the minor version is incremented; I've contacted the jtreg team and a fix is in progress. Thanks, -Joe An update on the update: a new jtreg build resolves the TestNG issue. After a new build of jtreg is promoted, I'll go ahead with the JDK_MINOR_VERSIO update. Cheers, -Joe Please review this increment in common/autoconf/version-numbers along with test updates to work around a HotSpot bug: http://cr.openjdk.java.net/~darcy/8000962.0/ Patch below. Thanks, -Joe --- old/common/autoconf/version-numbers2013-12-18 09:12:06.0 -0800 +++ new/common/autoconf/version-numbers2013-12-18 09:12:06.0 -0800 @@ -24,7 +24,7 @@ # JDK_MAJOR_VERSION=1 -JDK_MINOR_VERSION=8 +JDK_MINOR_VERSION=9 JDK_MICRO_VERSION=0 JDK_UPDATE_VERSION= LAUNCHER_NAME=openjdk --- old/langtools/test/tools/javac/MethodParameters/AnnotationTest.java 2013-12-18 09:12:07.0 -0800 +++ new/langtools/test/tools/javac/MethodParameters/AnnotationTest.java 2013-12-18 09:12:07.0 -0800 @@ -24,6 +24,7 @@ /* * @test * @bug 8006582 + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp * @summary javac should generate method parameters correctly. * @build Tester * @compile -parameters AnnotationTest.java --- old/langtools/test/tools/javac/MethodParameters/AnonymousClass.java 2013-12-18 09:12:07.0 -0800 +++ new/langtools/test/tools/javac/MethodParameters/AnonymousClass.java 2013-12-18 09:12:07.0 -0800 @@ -24,6 +24,7 @@ /* * @test * @bug 8006582 + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp * @summary javac should generate method parameters correctly. * @build Tester * @compile -parameters AnonymousClass.java --- old/langtools/test/tools/javac/MethodParameters/CaptureTest.java 2013-12-18 09:12:07.0 -0800 +++ new/langtools/test/tools/javac/MethodParameters/CaptureTest.java 2013-12-18 09:12:07.0 -0800 @@ -24,6 +24,7 @@ /* * @test * @bug 8015701 + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp * @summary Test method parameter attribute generation with captured locals. * @compile -parameters CaptureTest.java * @run main CaptureTest --- old/langtools/test/tools/javac/MethodParameters/Constructors.java 2013-12-18 09:12:08.0 -0800 +++ new/langtools/test/tools/javac/MethodParameters/Constructors.java 2013-12-18 09:12:08.0 -0800 @@ -24,6 +24,7 @@ /* * @test * @bug 8006582 + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp * @summary javac should generate method parameters correctly. * @build Tester * @compile -parameters Constructors.java --- old/langtools/test/tools/javac/MethodParameters/EnumTest.java 2013-12-18 09:12:08.0 -0800 +++ new/langtools/test/tools/javac/MethodParameters/EnumTest.java 2013-12-18 09:12:08.0 -0800 @@ -24,6 +24,7 @@ /* * @test * @bug 8006582 8008658 + * @ignore 8030656 Bad
Re: RFR: 8016780: (xs) README-builds.html misses crucial requirement on bootstrap JDK
On 6/17/2013 6:22 PM, Jonathan Gibbons wrote: On 06/17/2013 05:21 PM, Stuart Marks wrote: On 6/17/13 4:02 PM, Kelly O'Hair wrote: Rule #1 Nobody reads the README Rule #2 When things go wrong, blame the README I of course have no objection to the change, however, I'm not convinced it will help much the next time someone runs into this. :^( Hi Kelly! You still read this stuff here? :-) Yeah, I have no illusions that changing the README will prevent many, if any, future occurrences of this problem. However, we had an internal discussion on this incident where the N-1 rule was asserted. There was no dispute about the rule, but I went off to find where it was documented, and found only the fairly weak statement in the README. So, at the very least, that ought to be fixed. A stronger step would be to modify configure to check the version of the boot JDK and to complain if it doesn't match N-1. Or perhaps even N-1 and update = 7. What do you think? I was considering filing an RFE. A restriction in configure would probably be more effective at preventing these kinds of errors. s'marks Stuart, At least make sure you don't break make bootcycle-images which deliberately uses the newly built JDK to build itself again. Very important. Eventually N will become the N -1, so passing that boot-cycle test is a major requirement for safely pushing any hotspot update into jdkN -- Alejandro
