Re: JDK-8025705
Yes, I did consider using some ifeq tricks like that -- but they are rather ugly and unreadable and have the same problem that you want to avoid: adding distribution-specific code into the open-source makefiles. My goal here is to have the public OpenJDK makefiles be in a state such that custom distribution code can be added (in make/closed, src/closed, or some such alternative location) without having to perform surgery on the Makefiles and maintain the private changes. The mechanism is already in place,it's just some leftover OracleJDK that hasn't made it out of the open makefiles yet. If we could just cordon that off somehow, then anyone could make a custom distribution by augmenting OpenJDK with 'closed' style repositories -- without having to maintain private, unrelated edits to jdk Makefiles. On Wed, Apr 23, 2014 at 12:10 AM, David Holmes david.hol...@oracle.comwrote: Hi Keith, Okay ... so you don't set OPENJDK and thus from the make logic perspective you are implicitly ORACLE_JDK. So first question: why don't you set OPENJDK and then add blocks guarded by MY_JDK (or whatever) for your custom stuff? Second, the way to get a disjunction is to use the text functions eg (untested but you should get the gist): // OR ifeq (true, findstring( $(OPENJDK) $(MYJDK), true) // not-OR ifneq (true, findstring( $(OPENJDK) $(MYJDK), true) It's not as trivial as || etc but not too horrendously ugly :) Does this help? David On 22/04/2014 11:10 PM, Keith McGuigan wrote: Hi David, Most of the problem resides in jdk/make, in the following files: make/CompileDemos.gmk make/CompileJavaClasses.gmk make/CopyFiles.gmk make/CopyIntoClasses.gmk make/CreateSecurityJars.gmk make/gensrc/GensrcIcons.gmk make/Images.gmk make/lib/Awt2dLibraries.gmk Biggest offender is problem CopyFiles.gmk (but CreateSecurityJars.gmk has a bit too). Basically in each situation where there's a ifndef OPENJDK, it encloses a block of code that access something in src/closed or make/closed. I did initially try to set a new variable in our build in an attempt to replace these areas with something like: ifndef OPENJDK ifndef PRIVATEJDK ... but there's apparently no convenient way of doing that in makefiles (conjunctions and disjunctions at the preprocessing level aren't available -- and the workarounds are rather goofy). Duplicating the OPENJDK only code quickly became unreasonable too -- a few of the code blocks are one-liners, but there's a bunch that are much more involved clauses. On Tue, Apr 22, 2014 at 8:23 AM, David Holmes david.hol...@oracle.com mailto:david.hol...@oracle.com wrote: Hi Keith, Sorry I have very limited cycles right now, and just had a 4 day Easter break with anther long weekend ahead :) You are right that the src/closed - CUSTOM_SRC_DIR is somewhat tangential to your issue. The existence checks I suggested would be a check for whatever file/directory is enough to indicate the feature is present. Most uses of OPENJDK are really used to indicate !ORACLE_JDK, so introducing a third variation doesn't really fit. Can you give a concrete example of something that highlights this problem for you and how your proposal addresses it? I may get a better sense of things with specifics rather than trying to generalize - because I don't see a general solution without a lot of refactoring. Thanks, David On 22/04/2014 2:42 PM, Keith McGuigan wrote: Hi Mark, et al., The sad reality of the situation is that there is indeed Oracle-specific code in the OpenJDK makefiles, and this code interferes with our customization of the JDK. Adding temporary signposts to allow us (and others) to avoid this code will not make things worse. It doesn't have to be a distribution name -- we call it whatever you like: TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just something to latch onto to deactivate that code when it is not needed. This would provide immediate relief to customizing distributors and give Oracle engineers time to phase that code into closed makefiles (at which time the signposts can be removed completely). Taking all this code out wholesale instead would be great, and this is something I am totally willing to tackle and put the effort in on if I was in a position to do so. Unfortunately, since this is not fully open-source, I can't do the refactoring needed to move this code into the closed directories. And I though I could easily strip the code from OpenJDK, this would totally muck with Oracle distribution so any patch I would submit would surely be immediately rejected. Considering that the code is question has been in
RFR: JDK-8041593: Update README-builds.html to refer to jdk9
Here is a minor patch to README-builds.html to update references to jdk8 to jdk9 and fix the part about boot jdk since we now require jdk8. I realize there is probably a lot more that needs to be fixed in this file, but would like to leave that for another time. Bug: https://bugs.openjdk.java.net/browse/JDK-8041593 Webrev: http://cr.openjdk.java.net/~erikj/8041593/webrev.root.01/ /Erik
Request for review of make changes for JDK-8041507, Java Access Bridge version strings need to be fixed
Please review the open part of the change for this fix: JDK-8041507 Java Access Bridge version strings need to be fixed https://bugs.openjdk.java.net/browse/JDK-8041507 Change: Some variables needed to be set for use by the RC phase of the build of jabswitch.exe. The closed part of the fix is a straight backport of the 9 fix and includes use of variables set in the make file. The open part of the fix for the make changes could not be backported due to build changes between 7 and 8/9 so a similar change was made to the 7 build file and can be found in the patch. Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8041507/webrev.00/ Thanks, Pete
Re: RFR: JDK-8041593: Update README-builds.html to refer to jdk9
Hi Erik: Here is a minor patch to README-builds.html to update references to jdk8 to jdk9 and fix the part about boot jdk since we now require jdk8. I realize there is probably a lot more that needs to be fixed in this file, but would like to leave that for another time. Bug: https://bugs.openjdk.java.net/browse/JDK-8041593 Webrev: http://cr.openjdk.java.net/~erikj/8041593/webrev.root.01 Looks good to me. Tim
Re: JDK-8036003: Add variable not to separate debug information.
Hi, * Yasumasa Suenaga yasue...@gmail.com [2014-04-04 10:56]: I've succeeded to make binaries which are contained debuginfo as following: http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012037.html $ make images STRIP_POLICY=no_strip POST_STRIP_CMD= I guess that we should run make above options to avoid this issue in currently. Thanks. I have verified that this works. Sorry about the delay in getting it pushed; I haven't had the time due to the security update and now rawhide being broken due to a GCC 4.9 bump. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
Re: Request for review of make changes for JDK-8041507, Java Access Bridge version strings need to be fixed
Hi Pete: Please review the open part of the change for this fix: JDK-8041507 Java Access Bridge version strings need to be fixed https://bugs.openjdk.java.net/browse/JDK-8041507 Change: Some variables needed to be set for use by the RC phase of the build of jabswitch.exe. The closed part of the fix is a straight backport of the 9 fix and includes use of variables set in the make file. The open part of the fix for the make changes could not be backported due to build changes between 7 and 8/9 so a similar change was made to the 7 build file and can be found in the patch. Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8041507/webrev.00/ Looks good to me, as long as test builds on Windows worked as expected. Tim
Re: RFR 8030011: Update Hotspot version string output
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.
thanks guys!
Re: JDK-8025705
On 23/04/2014 9:23 PM, Keith McGuigan wrote: Yes, I did consider using some ifeq tricks like that -- but they are rather ugly and unreadable and have the same problem that you want to avoid: adding distribution-specific code into the open-source makefiles. I see no short-term fix for this beyond what I suggested, as an alternate to putting in the ORACLEJDK variable. But you would have to maintain that change in your private repo - I see no way around that. Given that: ifndef OPENJDK actually, implicitly means ifdef ORACLEJDK then all non-Oracle builds must presently declare themselves to be OPENJDK implementations. To which they can add specific customizations. My goal here is to have the public OpenJDK makefiles be in a state such that custom distribution code can be added (in make/closed, src/closed, or some such alternative location) without having to perform surgery on the Makefiles and maintain the private changes. The mechanism is already in place,it's just some leftover OracleJDK that hasn't made it out of the open makefiles yet. If we could just cordon that off somehow, then anyone could make a custom distribution by augmenting OpenJDK with 'closed' style repositories -- without having to maintain private, unrelated edits to jdk Makefiles. You simply need to leave OPENJDK set to true to achieve that cordoning off. Even if we move all OracleJDK specific stuff out of the open makefiles a completely clean separation may not be possible: - the customization hooks can not be everywhere and different customizations may have different requirements - if there are chunks of OpenJDK code (ie code currently part of both OpenJDK and Oracle JDK) that are not wanted in your custom build then you will still need to maintain private makefile changes to exclude them. To fix this will need additional modularization of the build with feature-selection (though not in a way that would violate the platform specifications). David - On Wed, Apr 23, 2014 at 12:10 AM, David Holmes david.hol...@oracle.com mailto:david.hol...@oracle.com wrote: Hi Keith, Okay ... so you don't set OPENJDK and thus from the make logic perspective you are implicitly ORACLE_JDK. So first question: why don't you set OPENJDK and then add blocks guarded by MY_JDK (or whatever) for your custom stuff? Second, the way to get a disjunction is to use the text functions eg (untested but you should get the gist): // OR ifeq (true, findstring( $(OPENJDK) $(MYJDK), true) // not-OR ifneq (true, findstring( $(OPENJDK) $(MYJDK), true) It's not as trivial as || etc but not too horrendously ugly :) Does this help? David On 22/04/2014 11:10 PM, Keith McGuigan wrote: Hi David, Most of the problem resides in jdk/make, in the following files: make/CompileDemos.gmk make/CompileJavaClasses.gmk make/CopyFiles.gmk make/CopyIntoClasses.gmk make/CreateSecurityJars.gmk make/gensrc/GensrcIcons.gmk make/Images.gmk make/lib/Awt2dLibraries.gmk Biggest offender is problem CopyFiles.gmk (but CreateSecurityJars.gmk has a bit too). Basically in each situation where there's a ifndef OPENJDK, it encloses a block of code that access something in src/closed or make/closed. I did initially try to set a new variable in our build in an attempt to replace these areas with something like: ifndef OPENJDK ifndef PRIVATEJDK ... but there's apparently no convenient way of doing that in makefiles (conjunctions and disjunctions at the preprocessing level aren't available -- and the workarounds are rather goofy). Duplicating the OPENJDK only code quickly became unreasonable too -- a few of the code blocks are one-liners, but there's a bunch that are much more involved clauses. On Tue, Apr 22, 2014 at 8:23 AM, David Holmes david.hol...@oracle.com mailto:david.hol...@oracle.com mailto:david.holmes@oracle.__com mailto:david.hol...@oracle.com wrote: Hi Keith, Sorry I have very limited cycles right now, and just had a 4 day Easter break with anther long weekend ahead :) You are right that the src/closed - CUSTOM_SRC_DIR is somewhat tangential to your issue. The existence checks I suggested would be a check for whatever file/directory is enough to indicate the feature is present. Most uses of OPENJDK are really used to indicate !ORACLE_JDK, so introducing a third variation doesn't really fit. Can you give a concrete example of something that highlights this problem for you and how your proposal addresses it? I may get a better sense of things with
