Re: RFR: JDK-8239019: testmake fails with FATAL: VCS_TYPE is empty
Hi Erik, Agree it should run outside of any source code system. Idea supports that with the empty string. So even the warning can be removed. Thanks, Roger On 2/13/20 7:41 PM, Erik Joelsson wrote: Hello, The fix to make idea.sh support both git and mercurial had the unfortunate side effect of bailing out completely if neither was found. This happens to be the case when we run our build system tests (which includes running idea.sh) in our distributed test environment. I think idea.sh should still work even if run on a source tree outside of any source control system. This patch just changes the lack of a detected VCS_TYPE to a warning instead of being fatal. The vcs.xml is still generated, but from what I can tell, Intellij doesn't seem to care much. Webrev: http://cr.openjdk.java.net/~erikj/8239019/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8239019 /Erik
Re: RFR: 8237566: FindTests.gmk should only include existing TEST.ROOT files
On 2/13/20 6:21 PM, Erik Joelsson wrote:
Hello Erik,
Looks good.
Thanks for reviewing!
On 2/13/20 6:21 PM, Erik Joelsson wrote:
Style wise I try to put closing braces for logical blocks on
a new line, aligned with the opening brace. I think that helps making
the already quite convoluted makefile logic a tad more readable.
Ok, sure, no problem. I moved the closing brace onto a new line (aligned
with the opening brace). Please see new webrevs below:
Webrevs:
- full: http://cr.openjdk.java.net/~ehelin/8237566/01/
- inc: http://cr.openjdk.java.net/~ehelin/8237566/00-01/
Thanks,
Erik
/Erik
On 2020-02-13 04:44, Erik Helin wrote:
Hi all,
this small patch changes FindTest.gmk to only include TEST.ROOT files
that actually are present. The motivation for this change is that both
Git and Mercurial supports so called "sparse" checkouts [0][1] (still
somewhat experimental for both, but actively worked on). While
experimenting with these features I noticed that FindTests.gmk demands
that test/{jtreg,jdk,langtools,nashorn,jaxp}/TEST.ROOT are present
even if you are only trying to run e.g. `make hotspot`. This small
patch ensures that we only include TEST.ROOT files that actually exist
on disk.
Webrev:
https://cr.openjdk.java.net/~ehelin/8237566/00/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8237566
Testing:
- Tier 1,2,3 on Linux, macOS, Windows (all x64)
Thanks,
Erik
[0]: https://www.mercurial-scm.org/repo/hg/file/tip/hgext/sparse.py
[1]:
https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/
PS. For the curious, I did manage to create a minimal working
directory for hotspot using git version 2.25 (with this patch applied):
$ git clone https://github.com/openjdk/jdk --no-checkout
$ cd jdk
$ git sparse-checkout init --cone
$ git sparse-checkout set make src/java.base src/hotspot
$ curl
https://cr.openjdk.java.net/~ehelin/8237566/00/JDK-8237566.patch | git
apply
$ bash configure
$ make hotspot
RE: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images
Hi Alan, > On 12/02/2020 22:16, Erik Joelsson wrote: > > Hello Christoph, > > > > This patch certainly looks better to me, though I agree it's a bit > > hackish to have to filter and rename the stripped.pdb files twice, > > once for jmods and again for bundles. I think I'm ok with it for now > > though. The future improvement I would like to make would be to create > > two sets of jdk images, one that contains debug symbols and demos, > > which we continue to use for testing, and another which only contains > > exactly what we bundle up, including the correctly named top dir. The > > latter would be created first and used as input for the former. I > > think lots of things would be cleaner then, especially Bundles.gmk. > There may be a role for a jlink plugin here. On Linux, jlink > --strip-native-debug-symbols runs the objdump tool and sub-options can > be used to configure the debuginfo files to keep or exclude. In time I'm > sure there will be other plugins like this. Yes, something similar should be doable (and desirable) for Windows. In fact, that makes me think whether we should generalize this option to something like --with-external-debug-symbols-in-product-bundles=. So, that way one could decide which PDBs to ship and it could eventually also be made available for other platforms and external debug symbols. And jlink plugins could then handle this and remove/strip this information. Best regards Christoph
RE: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to remove unused code
> > Hello , please review the downport of "8234525: enable link-time section- > gc for linux s390x to remove unused code" to jdk11 . > > > > My change from jdk/jdk did not apply directly and I had to adjust it > > slightly . > > > > > > > > > > Bug and jdk/jdk change : > > > > https://bugs.openjdk.java.net/browse/JDK-8234525 > > https://hg.openjdk.java.net/jdk/jdk/rev/c04fa10636fd > > > > > > Adjusted change for jdk11u-dev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.0_jdk11/ > > > > > > Original review thread : > > > > https://mail.openjdk.java.net/pipermail/build-dev/2019- > November/026326.html > > > > > > Thanks, Matthias > > > > In the original patch, the lines are added after > TOOLCHAIN_CFLAGS_JDK_CONLY. In the 11u version, they seem to have > needlessly moved above it. > > Otherwise, looks good. > > Regarding the patch itself, are these flags only useful when the s390x > port is present or would they be advantageous on older versions where > s390x is still using the Zero assembler port? > Hello Andrew, thanks for the review . I did not check the zero based ports . However as long as gcc and ld support the flags used , it should work with zero too . Best regards, Matthias
