Re: RFR: JDK-8241463 Move build tools to respective modules
Hi Magnus, I looked at i18n related changes: make/CopyInterimTZDB.gmk make/ToolsJdk.gmk make/gendata/Gendata-java.base.gmk make/gendata/GendataBreakIterator.gmk make/gendata/GendataTZDB.gmk make/gensrc/GensrcCharacterData.gmk make/gensrc/GensrcEmojiData.gmk They look ok to me. The *.java changes should have copyright year update. As to charsetmapping and cldrconverter, I believe they can reside in java.base, as jdk.charsets and jdk.localedata modules depend on it. Naoto On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote: The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so anymore. Instead, the build tools source code should move the the module that needs them. For instance, compilefontconfig should move to java.desktop, etc. There are multiple reasons for this: * Currently we build *all* build tools at once, which mean that we cannot compile java.base until e.g. the compilefontconfig tool is compiled, even though it is not needed. * If a build tool, e.g. compilefontconfig is modified, all build tools are recompiled, which triggers a rebuild of more or less the entire JDK. This makes development of the build tools unnecessary tedious. * When the build tools are modified, the group owning the corresponding module is the proper review instance, not the build team. But since they reside under "make", the review mails often include build-dev, but this is mostly noise for us. With this move, the ownership is made clear. In this patch, I have not modified how and when the build tools are compiled, but this shuffle is the prerequisite for continuing with that in a follow-up patch. I have also moved the build tools to the org.openjdk.buildtools.* package name space (inspired by Skara), instead of the strangely named build.tools.* name space. A few build tools are not moved in this patch. Two of them, charsetmapping and cldrconverter, are shared between two modules. (I think they should move to modules nevertheless, but they need some more thought to make sure I do this right.) The rest are tools that are needed for the build in general, like linking or javadoc support. I'll move this to a better location too, but in a separate patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 /Magnus
Re: RFR: JDK-8241463 Move build tools to respective modules
On 23/03/2020 19:03, Magnus Ihse Bursie wrote: The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so anymore. Instead, the build tools source code should move the the module that needs them. For instance, compilefontconfig should move to java.desktop, etc. There are multiple reasons for this: * Currently we build *all* build tools at once, which mean that we cannot compile java.base until e.g. the compilefontconfig tool is compiled, even though it is not needed. * If a build tool, e.g. compilefontconfig is modified, all build tools are recompiled, which triggers a rebuild of more or less the entire JDK. This makes development of the build tools unnecessary tedious. * When the build tools are modified, the group owning the corresponding module is the proper review instance, not the build team. But since they reside under "make", the review mails often include build-dev, but this is mostly noise for us. With this move, the ownership is made clear. In this patch, I have not modified how and when the build tools are compiled, but this shuffle is the prerequisite for continuing with that in a follow-up patch. I have also moved the build tools to the org.openjdk.buildtools.* package name space (inspired by Skara), instead of the strangely named build.tools.* name space. A few build tools are not moved in this patch. Two of them, charsetmapping and cldrconverter, are shared between two modules. (I think they should move to modules nevertheless, but they need some more thought to make sure I do this right.) The rest are tools that are needed for the build in general, like linking or javadoc support. I'll move this to a better location too, but in a separate patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 I think this will require further discussion, maybe even an update to JEP 201. I think it would be useful to see what other options were exploring, in particular options that organize the tools by module in the make tree (as it will confuse people to put them in the src tree). -Alan
Re: RFR: JDK-8241421 Cleanup handling of jtreg
On 3/23/20 1:15 PM, Magnus Ihse Bursie wrote: On 2020-03-23 18:20, Jonathan Gibbons wrote: On 3/23/20 7:32 AM, Erik Joelsson wrote: On 2020-03-23 07:21, Jonathan Gibbons wrote: On 3/23/20 6:06 AM, Erik Joelsson wrote: The environment variable name JT_HOME is defined by Jtreg itself so I think it makes sense to use that. Configure is still honoring it, but run-test-prebuilt is not. We can of course use a different variable name internally, but I don't really see the reason as JT_HOME is the generally accepted one. Would it help to migrate jtreg towards using JTREG_HOME, as a preferred alternative to JT_HOME? Yes, I think that would help. Didn't even consider that possibility. /Erik I'll put that change into jtreg, so that it is available in the next update for jtreg. Nice, thank you very much! When is that due? That is, should I hold this patch and wait for the next jtreg, or should I find a temporary solution until then? /Magnus -- Jon Temporary workaround for now would be better. -- Jon
Re: RFR: JDK-8241463 Move build tools to respective modules
Hi Magnus,
Modularizing the build tools is a good move. This patch suggests to
place the build tools under
src/$MODULE/share/tools/$PACKAGE/*.java
I think the modular source location of the build tools needs more
discussion, including jigsaw-dev for this discussion.
The JDK source as specified in JEP 201 is under:
src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
Compiling the source files from the `src` directory are the intermediate
input to build the resulting image. Build tools are used to generate
additional intermediate input (that is not part of the `src` directory)
to build the image. So I wonder if make/$MODULE/share/tools or
make/tools/$MODULE may be better location for the build tools.
Mandy
On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote:
The build tools (small java tools that are run during the build to
generate source code, or data, needed in the JDK) have historically
been placed in the "make" directory. This maybe made sense long time
ago, but does not do so anymore.
Instead, the build tools source code should move the the module that
needs them. For instance, compilefontconfig should move to
java.desktop, etc.
There are multiple reasons for this:
* Currently we build *all* build tools at once, which mean that we
cannot compile java.base until e.g. the compilefontconfig tool is
compiled, even though it is not needed.
* If a build tool, e.g. compilefontconfig is modified, all build tools
are recompiled, which triggers a rebuild of more or less the entire
JDK. This makes development of the build tools unnecessary tedious.
* When the build tools are modified, the group owning the
corresponding module is the proper review instance, not the build
team. But since they reside under "make", the review mails often
include build-dev, but this is mostly noise for us. With this move,
the ownership is made clear.
In this patch, I have not modified how and when the build tools are
compiled, but this shuffle is the prerequisite for continuing with
that in a follow-up patch.
I have also moved the build tools to the org.openjdk.buildtools.*
package name space (inspired by Skara), instead of the strangely named
build.tools.* name space.
A few build tools are not moved in this patch. Two of them,
charsetmapping and cldrconverter, are shared between two modules. (I
think they should move to modules nevertheless, but they need some
more thought to make sure I do this right.) The rest are tools that
are needed for the build in general, like linking or javadoc support.
I'll move this to a better location too, but in a separate patch.
Bug: https://bugs.openjdk.java.net/browse/JDK-8241463
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01
/Magnus
Re: RFR: JDK-8241421 Cleanup handling of jtreg
On 2020-03-23 18:20, Jonathan Gibbons wrote: On 3/23/20 7:32 AM, Erik Joelsson wrote: On 2020-03-23 07:21, Jonathan Gibbons wrote: On 3/23/20 6:06 AM, Erik Joelsson wrote: The environment variable name JT_HOME is defined by Jtreg itself so I think it makes sense to use that. Configure is still honoring it, but run-test-prebuilt is not. We can of course use a different variable name internally, but I don't really see the reason as JT_HOME is the generally accepted one. Would it help to migrate jtreg towards using JTREG_HOME, as a preferred alternative to JT_HOME? Yes, I think that would help. Didn't even consider that possibility. /Erik I'll put that change into jtreg, so that it is available in the next update for jtreg. Nice, thank you very much! When is that due? That is, should I hold this patch and wait for the next jtreg, or should I find a temporary solution until then? /Magnus -- Jon
Re: RFR: JDK-8241463 Move build tools to respective modules
Looks good. /Erik On 2020-03-23 12:03, Magnus Ihse Bursie wrote: The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so anymore. Instead, the build tools source code should move the the module that needs them. For instance, compilefontconfig should move to java.desktop, etc. There are multiple reasons for this: * Currently we build *all* build tools at once, which mean that we cannot compile java.base until e.g. the compilefontconfig tool is compiled, even though it is not needed. * If a build tool, e.g. compilefontconfig is modified, all build tools are recompiled, which triggers a rebuild of more or less the entire JDK. This makes development of the build tools unnecessary tedious. * When the build tools are modified, the group owning the corresponding module is the proper review instance, not the build team. But since they reside under "make", the review mails often include build-dev, but this is mostly noise for us. With this move, the ownership is made clear. In this patch, I have not modified how and when the build tools are compiled, but this shuffle is the prerequisite for continuing with that in a follow-up patch. I have also moved the build tools to the org.openjdk.buildtools.* package name space (inspired by Skara), instead of the strangely named build.tools.* name space. A few build tools are not moved in this patch. Two of them, charsetmapping and cldrconverter, are shared between two modules. (I think they should move to modules nevertheless, but they need some more thought to make sure I do this right.) The rest are tools that are needed for the build in general, like linking or javadoc support. I'll move this to a better location too, but in a separate patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 /Magnus
RFR: JDK-8241463 Move build tools to respective modules
The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so anymore. Instead, the build tools source code should move the the module that needs them. For instance, compilefontconfig should move to java.desktop, etc. There are multiple reasons for this: * Currently we build *all* build tools at once, which mean that we cannot compile java.base until e.g. the compilefontconfig tool is compiled, even though it is not needed. * If a build tool, e.g. compilefontconfig is modified, all build tools are recompiled, which triggers a rebuild of more or less the entire JDK. This makes development of the build tools unnecessary tedious. * When the build tools are modified, the group owning the corresponding module is the proper review instance, not the build team. But since they reside under "make", the review mails often include build-dev, but this is mostly noise for us. With this move, the ownership is made clear. In this patch, I have not modified how and when the build tools are compiled, but this shuffle is the prerequisite for continuing with that in a follow-up patch. I have also moved the build tools to the org.openjdk.buildtools.* package name space (inspired by Skara), instead of the strangely named build.tools.* name space. A few build tools are not moved in this patch. Two of them, charsetmapping and cldrconverter, are shared between two modules. (I think they should move to modules nevertheless, but they need some more thought to make sure I do this right.) The rest are tools that are needed for the build in general, like linking or javadoc support. I'll move this to a better location too, but in a separate patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 /Magnus
Re: RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode
Looks good.
/Erik
On 2020-03-23 10:56, Andrew Dinn wrote:
Could I please have a review for this trivial fix to the module make
file which ensures that javadoc is generated for new module
jdk.nio.mapmode created as part of the implementation of JEP 352. The
original patch added the module to the BOOT_MODULES list but was not to
the DOCS_MODULES list.
JIRA: https://bugs.openjdk.java.net/browse/JDK-8241144
webrev: http://cr.openjdk.java.net/~adinn/8241144/webrev
Testing:
Built image and compiled + ran Hello World.
Built make target docs-jdk-api-javadoc and checked module
jdk.nio.mapmode was included in output
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode
Could I please have a review for this trivial fix to the module make
file which ensures that javadoc is generated for new module
jdk.nio.mapmode created as part of the implementation of JEP 352. The
original patch added the module to the BOOT_MODULES list but was not to
the DOCS_MODULES list.
JIRA: https://bugs.openjdk.java.net/browse/JDK-8241144
webrev: http://cr.openjdk.java.net/~adinn/8241144/webrev
Testing:
Built image and compiled + ran Hello World.
Built make target docs-jdk-api-javadoc and checked module
jdk.nio.mapmode was included in output
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
Re: RFR: JDK-8241421 Cleanup handling of jtreg
On 3/23/20 7:32 AM, Erik Joelsson wrote: On 2020-03-23 07:21, Jonathan Gibbons wrote: On 3/23/20 6:06 AM, Erik Joelsson wrote: The environment variable name JT_HOME is defined by Jtreg itself so I think it makes sense to use that. Configure is still honoring it, but run-test-prebuilt is not. We can of course use a different variable name internally, but I don't really see the reason as JT_HOME is the generally accepted one. Would it help to migrate jtreg towards using JTREG_HOME, as a preferred alternative to JT_HOME? Yes, I think that would help. Didn't even consider that possibility. /Erik I'll put that change into jtreg, so that it is available in the next update for jtreg. -- Jon
Re: RFR: JDK-8241421 Cleanup handling of jtreg
On 2020-03-23 07:21, Jonathan Gibbons wrote: On 3/23/20 6:06 AM, Erik Joelsson wrote: The environment variable name JT_HOME is defined by Jtreg itself so I think it makes sense to use that. Configure is still honoring it, but run-test-prebuilt is not. We can of course use a different variable name internally, but I don't really see the reason as JT_HOME is the generally accepted one. Would it help to migrate jtreg towards using JTREG_HOME, as a preferred alternative to JT_HOME? Yes, I think that would help. Didn't even consider that possibility. /Erik
Re: RFR: JDK-8241421 Cleanup handling of jtreg
On 3/23/20 6:06 AM, Erik Joelsson wrote: The environment variable name JT_HOME is defined by Jtreg itself so I think it makes sense to use that. Configure is still honoring it, but run-test-prebuilt is not. We can of course use a different variable name internally, but I don't really see the reason as JT_HOME is the generally accepted one. Would it help to migrate jtreg towards using JTREG_HOME, as a preferred alternative to JT_HOME? -- Jon
Re: Build and Test with Docker
Hello Philipp, On 2020-03-21 12:37, Philipp Kunz wrote: Hi everyone, When I started contributing I went through all the building and testing instructions [1] and after I had bought a new computer recently, it occurred to me that this could as well be simplified with docker. What I found was not a lot, surprisingly. A simple test called DockerBasicTest inside the Open Jdk that does nothing with building or testing the jdk but only runs the built jdk image as I understood after a quick glance. To mention is also AdoptOpenJDK [2] which says it does not work at the moment, which I haven't even tried myself so far. I haven't found anything related in the mailing list archives nor in the bugs. What I searched and if that really does not yet exist I want to propose is kind of an additional section to the building and testing instructions at [1] that basically says which docker image to use as an alternative to prepare a computer accordingly. The usage should be as simple as possible: 1. checkout jdk, 2. docker build ..., 3. docker run Unlike [2] I would suggest multi-arch images [3]. Again, did I just not find the relevant thing? If so, I will be grateful for a hint where to look, apologize for this spam, and vote for anything to make also others find it easier. In my opinion, the Open Jdk itself would be the right place to maintain a few dockerfiles so that these can be changed and maintained together with the Open Jdk as it evolves along with its build and testing instructions. It would probably require quite limited effort only, basically extracting the build and testing instructions into a few architecture depending scripts and reference them from one or a few new dockerfiles. This might also help to save a lot of time to existing contributors and help others to start contributing with a lower threshold to get started. I have heard similar requests a couple of times before, but I'm not quite sure what problem this is supposed to solve. There are 3 main reasons to build OpenJDK. 1. An OpenJDK developer builds while developing and testing changes. 2. A user builds OpenJDK to run on their own machine. 3. A distributor builds OpenJDK to distribute the binaries to multiple different users. If I understand you correctly, you are trying to solve problem 1, to lower the threshold for new OpenJDK developers. To use Docker meaningfully, you would be developing on Linux. In my experience, getting a working build environment for local development on Linux is by far the easiest platform. The reason for this is that we have so many contributors already building on a vast variation of different distributions and versions of Linux, so most problems are getting solved rather quickly. Still, a dockerfile would be even easier at first, but would also be clunkier to work with. Having to go through docker for every incremental build command gets annoying, ctrl-c doesn't work as reliably and debugging through docker is messy. I just don't think many developers would be interested in such a workflow. For 2, if you want to compile OpenJDK for your own specific machine and Linux installation, then you most likely want to use your local toolchain and system libraries. Otherwise you wouldn't be compiling yourself, but could just as well download prebuilt binaries from an existing distributor. Finally for 3, it could make sense to build in docker, but that would be something each distributor would have to setup themselves to suit their specific build needs, which are in turn based on their OS support matrix (and a slew of other external factors, which can be both technical and legal), something each distributor defines for themselves. Common to all of these scenarios is the problem of who defines the "official" build platforms for OpenJDK. We currently don't have any. We maintain (sort of) a wiki page [1] with build configurations used by some distributors (such as Oracle and SAP), but no distributor is currently defining their build environments as the official for OpenJDK. Because of all this, I don't think anyone in OpenJDK is currently interested in spending resources on maintaining such dockerfiles. But, if someone wants to contribute and maintain dockerfiles that are known to work to produce a reasonably compatible build of OpenJDK, then I don't see a problem with accepting them into the source tree. /Erik [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms Does that sound reasonable? Any opinions? Regards, Philipp [1] https://hg.openjdk.java.net/jdk/jdk/file/12eb1e2087d2/doc [2] https://github.com/AdoptOpenJDK/openjdk-build/tree/master/docker [3] https://docs.docker.com/registry/spec/manifest-v2-2/
Re: RFR: JDK-8241421 Cleanup handling of jtreg
Hello, On 2020-03-23 02:21, Magnus Ihse Bursie wrote: We're doing some odd things in the build system for jtreg, most of it left-overs from the older build systems. We have no need for JTREGEXE and it should be removed. We should also use the standard naming pattern of JTREG_HOME. The environment variable name JT_HOME is defined by Jtreg itself so I think it makes sense to use that. Configure is still honoring it, but run-test-prebuilt is not. We can of course use a different variable name internally, but I don't really see the reason as JT_HOME is the generally accepted one. In jib-profiles.js, the configure_args for jtreg were not specified as they were generated by default (a feature you requested way back when jib was initially designed). I don't mind it being explicitly set though. You can use "home_path" to have jib automatically find the single "jtreg" subdir inside the archive. Adding $JT_HOME/bin to the path is done to support (the rarely used) "jib run" command. It enables you to have jib provide an environment for running a command directly, such as jtreg. I don't want that removed. For the same reason, I want JT_HOME to remain globally set as the jtreg launcher script could otherwise pick up a different JT_HOME from the users environment. /Erik The test in BuildFailureHandler.gmk is a bit different -- it is supposed to fail. I have run it both with and without the patch, and verified that the test result and test log are basically the same, except for normal runtime variance like time stamps and certain randomness. I have also verified that testing through the Oracle CI system still works as expected. Bug: https://bugs.openjdk.java.net/browse/JDK-8241421 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241421-cleanup-jtreg/webrev.01 /Magnus
Re: Build and Test with Docker
Hi Philipp, On 2020-03-21 20:37, Philipp Kunz wrote: Hi everyone, When I started contributing I went through all the building and testing instructions [1] and after I had bought a new computer recently, it occurred to me that this could as well be simplified with docker. What I found was not a lot, surprisingly. A simple test called DockerBasicTest inside the Open Jdk that does nothing with building or testing the jdk but only runs the built jdk image as I understood after a quick glance. To mention is also AdoptOpenJDK [2] which says it does not work at the moment, which I haven't even tried myself so far. I haven't found anything related in the mailing list archives nor in the bugs. What I searched and if that really does not yet exist I want to propose is kind of an additional section to the building and testing instructions at [1] that basically says which docker image to use as an alternative to prepare a computer accordingly. The usage should be as simple as possible: 1. checkout jdk, 2. docker build ..., 3. docker run Unlike [2] I would suggest multi-arch images [3]. Again, did I just not find the relevant thing? If so, I will be grateful for a hint where to look, apologize for this spam, and vote for anything to make also others find it easier. I don't think there exists any such documentation. In my opinion, the Open Jdk itself would be the right place to maintain a few dockerfiles so that these can be changed and maintained together with the Open Jdk as it evolves along with its build and testing instructions. It would probably require quite limited effort only, basically extracting the build and testing instructions into a few architecture depending scripts and reference them from one or a few new dockerfiles. This might also help to save a lot of time to existing contributors and help others to start contributing with a lower threshold to get started. Does that sound reasonable? Any opinions? Well, it does not sound unreasonable. I think no-one has really found the need for this. But this is an open source community, you are more than welcome to help us improve on this! You are free to create suitable docker images for building and testing the JDK. And a patch with updated documentation on how to use this. (If you do, please see https://openjdk.java.net/contribute/, especially the part about OCA.) /Magnus Regards, Philipp [1] https://hg.openjdk.java.net/jdk/jdk/file/12eb1e2087d2/doc [2] https://github.com/AdoptOpenJDK/openjdk-build/tree/master/docker [3] https://docs.docker.com/registry/spec/manifest-v2-2/
RFR: JDK-8241421 Cleanup handling of jtreg
We're doing some odd things in the build system for jtreg, most of it left-overs from the older build systems. We have no need for JTREGEXE and it should be removed. We should also use the standard naming pattern of JTREG_HOME. The test in BuildFailureHandler.gmk is a bit different -- it is supposed to fail. I have run it both with and without the patch, and verified that the test result and test log are basically the same, except for normal runtime variance like time stamps and certain randomness. I have also verified that testing through the Oracle CI system still works as expected. Bug: https://bugs.openjdk.java.net/browse/JDK-8241421 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241421-cleanup-jtreg/webrev.01 /Magnus
Re: RFR: JDK-8241271 Make hotspot build reproducible
Hotspot change looks good, and trivial. /Jesper > On 23 Mar 2020, at 09:45, Magnus Ihse Bursie > wrote: > > On 2020-03-20 14:19, Stefan Karlsson wrote: >> HotSpot changes look good. > > Can I have a second hotspot reviewer on this, or a confirmation that it's > considered trivial? > > /Magnus >> >> StefanK >> >> On 2020-03-20 14:15, Magnus Ihse Bursie wrote: >>> Can I get some hotspot reviewers on this as well? And is this trivial, from >>> the Hotspot PoV? >>> >>> /Magnus >>> >>> On 2020-03-20 14:05, Erik Joelsson wrote: Looks good! /Erik On 2020-03-20 03:58, Magnus Ihse Bursie wrote: > On 2020-03-19 19:01, Erik Joelsson wrote: >> On 2020-03-19 10:20, Magnus Ihse Bursie wrote: >>> Currently, it is not possible two make hotspot builds reproducible, >>> since the current date and time is always inserted using the special >>> macros __DATE__ and __TIME__. This patch makes it possible to override >>> these values from the build system, paving the way for making re-builds >>> of hotspot bit-by-bit identical. >>> >> I like the ability to achieve this. >>> On linux/gcc, we can now actually get bit-by-bit identical builds of >>> libjvm.so (if not using precompiled headers), so I've updated the >>> baseline-cmp profiles and compare script to reflect this. >>> >> I'm not sure this is a good idea though. It means I can't reasonably >> compare to validate build changes that affect the precompiled header. >> Similarly, the COMPARE_BUILD make variable argument will not work unless >> you use both of these configure arguments. >> >> Since compare.sh is generated through configure, perhaps these >> exceptions can be made conditional on if these configure arguments are >> setup correctly for a reproducible libjvm.so? > > Good thinking! I did not think of this possibility. And yes, I too did > not like the current solution, but could think of no way around it. > Here's an improved webrev. > > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241271-make-hotspot-reproducible/webrev.02 > > Technically, you can make this fail by setting HOTSPOT_BUILD_TIME but to > different values, but hey, there's no need to make this idiot-proof. > > /Magnus >> >> /Erik >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241271 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8241271-make-hotspot-reproducible/webrev.01 >>> >>> /Magnus > >>> >> >
Re: RFR: JDK-8241271 Make hotspot build reproducible
On 2020-03-20 14:19, Stefan Karlsson wrote: HotSpot changes look good. Can I have a second hotspot reviewer on this, or a confirmation that it's considered trivial? /Magnus StefanK On 2020-03-20 14:15, Magnus Ihse Bursie wrote: Can I get some hotspot reviewers on this as well? And is this trivial, from the Hotspot PoV? /Magnus On 2020-03-20 14:05, Erik Joelsson wrote: Looks good! /Erik On 2020-03-20 03:58, Magnus Ihse Bursie wrote: On 2020-03-19 19:01, Erik Joelsson wrote: On 2020-03-19 10:20, Magnus Ihse Bursie wrote: Currently, it is not possible two make hotspot builds reproducible, since the current date and time is always inserted using the special macros __DATE__ and __TIME__. This patch makes it possible to override these values from the build system, paving the way for making re-builds of hotspot bit-by-bit identical. I like the ability to achieve this. On linux/gcc, we can now actually get bit-by-bit identical builds of libjvm.so (if not using precompiled headers), so I've updated the baseline-cmp profiles and compare script to reflect this. I'm not sure this is a good idea though. It means I can't reasonably compare to validate build changes that affect the precompiled header. Similarly, the COMPARE_BUILD make variable argument will not work unless you use both of these configure arguments. Since compare.sh is generated through configure, perhaps these exceptions can be made conditional on if these configure arguments are setup correctly for a reproducible libjvm.so? Good thinking! I did not think of this possibility. And yes, I too did not like the current solution, but could think of no way around it. Here's an improved webrev. WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241271-make-hotspot-reproducible/webrev.02 Technically, you can make this fail by setting HOTSPOT_BUILD_TIME but to different values, but hey, there's no need to make this idiot-proof. /Magnus /Erik Bug: https://bugs.openjdk.java.net/browse/JDK-8241271 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241271-make-hotspot-reproducible/webrev.01 /Magnus
