Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v3]

2020-09-21 Thread Philippe Marschall 
> Hello, newbie here
> 
> I picked JDK-8138732 to work on because it has a "starter" label and I 
> believe I understand what to do.
> 
> - I tried to update the copyright year to 2020 in every file.
> - I decided to change `@since` from 9 to 16 since it is a new annotation name 
> in a new package.
> - I tried to keep code changes to a minimum, eg not change to imports if 
> fully qualified class names are used instead of
>   imports. In some cases I did minor reordering of imports to keep them 
> sorted alphabetically.
> - All tier1 tests pass.
> - One jpackage/jlink tier2 test fails but I don't believe it is related.
> - Some tier3 Swing tests fail but I don't think they are related.

Philippe Marschall has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now
contains one commit:

  8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate

-

Changes: https://git.openjdk.java.net/jdk/pull/45/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=45=02
  Stats: 748 lines in 64 files changed: 149 ins; 149 del; 450 mod
  Patch: https://git.openjdk.java.net/jdk/pull/45.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45

PR: https://git.openjdk.java.net/jdk/pull/45

Re: RFR: 8235710: Remove the legacy elliptic curves [v2]

2020-09-21 Thread Xue-Lei Andrew Fan 
On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino  
wrote:

>> This change removes the native elliptic curves library code; as well as, and 
>> calls to that code, tests, and files
>> associated with those libraries.  The makefiles have been changed to remove 
>> from all source builds of the ec code.  The
>> SunEC system property is removed and java.security configurations changed to 
>> reflect the removed curves.  This will
>> remove the following elliptic curves from SunEC:   secp112r1, secp112r2, 
>> secp128r1, secp128r2, secp160k1, secp160r1,
>> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, 
>> sect113r2, sect131r1, sect131r2,
>> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, 
>> sect239k1, sect283k1, sect283r1,
>> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 
>> c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1,
>> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, 
>> X9.62 prime192v2, X9.62 prime192v3, X9.62
>> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 
>> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
>
> Anthony Scarpino has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   remove JDKOPT_DETECT_INTREE_EC from configure.ac

Looks good to me.

-

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/289

Re: RFR: 8235710: Remove the legacy elliptic curves [v2]

2020-09-21 Thread Anthony Scarpino 
> This change removes the native elliptic curves library code; as well as, and 
> calls to that code, tests, and files
> associated with those libraries.  The makefiles have been changed to remove 
> from all source builds of the ec code.  The
> SunEC system property is removed and java.security configurations changed to 
> reflect the removed curves.  This will
> remove the following elliptic curves from SunEC:   secp112r1, secp112r2, 
> secp128r1, secp128r2, secp160k1, secp160r1,
> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, 
> sect113r2, sect131r1, sect131r2,
> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, 
> sect239k1, sect283k1, sect283r1,
> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 
> c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1,
> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 
> prime192v2, X9.62 prime192v3, X9.62
> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 
> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1

Anthony Scarpino has updated the pull request incrementally with one additional 
commit since the last revision:

  remove JDKOPT_DETECT_INTREE_EC from configure.ac

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/289/files
  - new: https://git.openjdk.java.net/jdk/pull/289/files/47eee3f4..8a04ce7a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=289=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=289=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/289.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/289/head:pull/289

PR: https://git.openjdk.java.net/jdk/pull/289

Re: RFR: 8235710: Remove the legacy elliptic curves [v2]

2020-09-21 Thread Anthony Scarpino 
On Mon, 21 Sep 2020 23:50:07 GMT, Erik Joelsson  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   remove JDKOPT_DETECT_INTREE_EC from configure.ac
>
> make/autoconf/jdk-options.m4 line 234:
> 
>> 232: # Enable or disable the elliptic curve crypto implementation
>> 233: #
>> 234: AC_DEFUN_ONCE([JDKOPT_DETECT_INTREE_EC],
> 
> There should be a call to this macro from either configure.ac or this file 
> that also needs to be removed.

found it in configure.ac and removed

-

PR: https://git.openjdk.java.net/jdk/pull/289

Re: RFR: 8235710: Remove the legacy elliptic curves

2020-09-21 Thread Erik Joelsson 
On Mon, 21 Sep 2020 21:10:58 GMT, Anthony Scarpino  
wrote:

> This change removes the native elliptic curves library code; as well as, and 
> calls to that code, tests, and files
> associated with those libraries.  The makefiles have been changed to remove 
> from all source builds of the ec code.  The
> SunEC system property is removed and java.security configurations changed to 
> reflect the removed curves.  This will
> remove the following elliptic curves from SunEC:   secp112r1, secp112r2, 
> secp128r1, secp128r2, secp160k1, secp160r1,
> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, 
> sect113r2, sect131r1, sect131r2,
> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, 
> sect239k1, sect283k1, sect283r1,
> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 
> c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1,
> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 
> prime192v2, X9.62 prime192v3, X9.62
> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 
> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1

make/autoconf/jdk-options.m4 line 234:

> 232: # Enable or disable the elliptic curve crypto implementation
> 233: #
> 234: AC_DEFUN_ONCE([JDKOPT_DETECT_INTREE_EC],

There should be a call to this macro from either configure.ac or this file that 
also needs to be removed.

-

PR: https://git.openjdk.java.net/jdk/pull/289

RFR: 8235710: Remove the legacy elliptic curves

2020-09-21 Thread Anthony Scarpino 
This change removes the native elliptic curves library code; as well as, and 
calls to that code, tests, and files
associated with those libraries.  The makefiles have been changed to remove 
from all source builds of the ec code.  The
SunEC system property is removed and java.security configurations changed to 
reflect the removed curves.

This will remove the following elliptic curves from SunEC:   secp112r1, 
secp112r2, secp128r1, secp128r2, secp160k1,
secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, 
sect113r1, sect113r2, sect131r1,
sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, 
sect233r1, sect239k1, sect283k1,
sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 
c2tnb191v2, X9.62 c2tnb191v3, X9.62
c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 
c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3,
X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 
brainpoolP320r1, brainpoolP384r1, brainpoolP512r1

-

Commit messages:
 - 8235710: Remove the legacy elliptic curves

Changes: https://git.openjdk.java.net/jdk/pull/289/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=289=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8235710
  Stats: 20143 lines in 75 files changed: 25 ins; 20038 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/289.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/289/head:pull/289

PR: https://git.openjdk.java.net/jdk/pull/289

Re: RFR: 8253208: Move CDS related code to a separate class [v3]

2020-09-21 Thread Yumin Qi 
> With more CDS related code added to VM, it is time to move CDS code to a 
> separate class. CDS is the new class which is
> specific to CDS.
> Tests: tier1-4

Yumin Qi has updated the pull request incrementally with one additional commit 
since the last revision:

  8253208: Move CDS related code to a separate class

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/261/files
  - new: https://git.openjdk.java.net/jdk/pull/261/files/c01deec7..953b6bac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=261=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=261=01-02

  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/261/head:pull/261

PR: https://git.openjdk.java.net/jdk/pull/261

Re: RFR: 8253208: Move CDS related code to a separate class [v2]

2020-09-21 Thread Ioi Lam 
On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi  wrote:

>> With more CDS related code added to VM, it is time to move CDS code to a 
>> separate class. CDS is the new class which is
>> specific to CDS.
>> Tests: tier1-4
>
> Yumin Qi has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8253208: Move CDS related code to a separate class

Marked as reviewed by iklam (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/261

Re: RFR: 8253208: Move CDS related code to a separate class [v2]

2020-09-21 Thread Erik Joelsson 
On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi  wrote:

>> With more CDS related code added to VM, it is time to move CDS code to a 
>> separate class. CDS is the new class which is
>> specific to CDS.
>> Tests: tier1-4
>
> Yumin Qi has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8253208: Move CDS related code to a separate class

Build changes look good.

-

PR: https://git.openjdk.java.net/jdk/pull/261

Re: RFR: 8253208: Move CDS related code to a separate class [v2]

2020-09-21 Thread Mandy Chung 
On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi  wrote:

>> With more CDS related code added to VM, it is time to move CDS code to a 
>> separate class. CDS is the new class which is
>> specific to CDS.
>> Tests: tier1-4
>
> Yumin Qi has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8253208: Move CDS related code to a separate class

This patch looks okay.   Please add the javadoc for 
`CDS::getRandomSeedForDumping` and `CDS::defineArchiveModules` for
completeness.

-

PR: https://git.openjdk.java.net/jdk/pull/261

Re: RFR: 8253208: Move CDS related code to a separate class [v2]

2020-09-21 Thread Yumin Qi 
On Sun, 20 Sep 2020 06:10:53 GMT, Ioi Lam  wrote:

>> Yumin Qi has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   8253208: Move CDS related code to a separate class
>
> src/java.base/share/native/libjava/CDS.c line 49:
> 
>> 47: JNIEXPORT jboolean JNICALL
>> 48: Java_jdk_internal_misc_CDS_isCDSDumpingEnabled(JNIEnv *env, jclass jcls) 
>> {
>> 49: return JVM_IsCDSDumpingEnabled(env);
> 
> Maybe: return JVM_IsCDSDynamicDumpingEnabled(env)

updated with comments.

-

PR: https://git.openjdk.java.net/jdk/pull/261

Re: RFR: 8253208: Move CDS related code to a separate class [v2]

2020-09-21 Thread Yumin Qi 
> With more CDS related code added to VM, it is time to move CDS code to a 
> separate class. CDS is the new class which is
> specific to CDS.
> Tests: tier1-4

Yumin Qi has updated the pull request incrementally with one additional commit 
since the last revision:

  8253208: Move CDS related code to a separate class

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/261/files
  - new: https://git.openjdk.java.net/jdk/pull/261/files/b9789c8b..c01deec7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=261=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=261=00-01

  Stats: 27 lines in 7 files changed: 0 ins; 0 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/261/head:pull/261

PR: https://git.openjdk.java.net/jdk/pull/261

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions

2020-09-21 Thread Erik Joelsson 
On Mon, 21 Sep 2020 15:30:41 GMT, Robin Westberg  wrote:

>> Is there any way to derive the version strings for dependencies from a 
>> different source? Once pushed, this file will
>> require updating whenever the bootjdk, jtreg version or gtest version is 
>> updated.
>
> Certainly, the prerequisites step can checkout additional repositories and 
> run shell commands to extract variables to
> be used for later steps. Do we have any suitable source for these versions? 
> We'll also need download links for the
> different flavors of the bootjdk (and ideally the sha256 hash, although the 
> verification step could perhaps be skipped).

We don't have a good source currently no, but something to keep in mind. 
Ideally we would want to create a common
source for both jib-profiles.js and the gitactions to read from. I would prefer 
something that can be read both as a
properties file and sourced as a shell script, much like the version-numbers 
file currently is. That could be done as a
separate change though.

-

PR: https://git.openjdk.java.net/jdk/pull/284

Re: RFR: 8252998: ModuleWrapper.gmk doesn't consult include path

2020-09-21 Thread Severin Gehwolf 
On Fri, 18 Sep 2020 12:44:13 GMT, Erik Joelsson  wrote:

>> A change made to ModuleWrapper.gmk as part of JDK-8244044 means that an 
>> included makefile is found in the current
>> directory, so Make doesn't check the include dirs for overriding gmk files.
>> Recommend a minor, partial reversion of this changeset to ensure any 
>> override files are included instead.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8252998
>
> Looks good.

@adamfarley Please see 
https://github.com/openjdk/jdk/pull/250#issuecomment-694845694 for getting this 
integrated. For
non-committers it's `/integrate` and then `/sponsor` by somebody with commit 
rights.

-

PR: https://git.openjdk.java.net/jdk/pull/250

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions

2020-09-21 Thread Robin Westberg 
On Mon, 21 Sep 2020 13:59:06 GMT, Erik Joelsson  wrote:

>> A few days ago I posted an initial version of the necessary configuration 
>> required to run pre-submit build and tests
>> for JDK main-line contributions using GitHub Actions [2] and the free tier 
>> [3] available to everyone working with open
>> source repositories. I've incorporated the feedback into an updated version 
>> that I believe is ready to be integrated.
>> If this is integrated into the `master` branch, future branches created and 
>> updated in personal forks will build and
>> run the basic tier 1 tests as described in this configuration, on Linux, 
>> Windows and macOS (all on x64). It's of course
>> possible for any contributor to opt out fully or partially of these 
>> automatic runs in a few different ways.  To opt out
>> completely, a contributor can simply disable GitHub Actions on their 
>> personal fork, and no further jobs will be
>> executed. Another option is to add a repository secret [4] with the name 
>> `JDK_SUBMIT_FILTER` set to any value. If this
>> is set, only branches prefixed with `submit/` will be subject to automatic 
>> build and test. This can also be further
>> refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a 
>> value such as `Linux x64, Windows x64` to
>> limit automatic build and test to these two platforms. It will still be 
>> possible to run the tests on any branch and/or
>> platform by manually triggering the workflow.  To see what this looks like 
>> in practice, an example run can be found
>> here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that 
>> there is currently a failing test on Windows
>> which is tracked by JDK-8249095, which should probably be resolved before 
>> this change is integrated).  Best regards,
>> Robin  [1] 
>> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html 
>> [2]
>> https://github.com/features/actions [3]
>> https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits
>>  [4]
>> https://docs.github.com/en/actions/reference/encrypted-secrets
>
> Is there any way to derive the version strings for dependencies from a 
> different source? Once pushed, this file will
> require updating whenever the bootjdk, jtreg version or gtest version is 
> updated.

Certainly, the prerequisites step can checkout additional repositories and run 
shell commands to extract variables to
be used for later steps. Do we have any suitable source for these versions? 
We'll also need download links for the
different flavors of the bootjdk (and ideally the sha256 hash, although the 
verification step could perhaps be skipped).

-

PR: https://git.openjdk.java.net/jdk/pull/284

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3]

2020-09-21 Thread Bernhard Urban-Forster 
On Mon, 21 Sep 2020 08:15:20 GMT, Bernhard Urban-Forster  
wrote:

>> Hey @erikj79, thank you so much for giving it a try!
>> 
>>> Our linux-aarch64 build fails with this:
>>> cc: error: unrecognized command line option '-std=c++14'
>>> when compiling 
>>> build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch
>> 
>> Hmm, that's interesting. What environment is that exactly? What `configure` 
>> line are you using there? We have tested on
>> such a system: $ cat /etc/issue
>> Ubuntu 19.10 \n \l
>> $ bash configure --with-boot-jdk=/home/beurba/work/jdk-16+13 --with-jtreg
>> $ make clean CONF=linux-aarch64-server-release
>> $ make images JOBS=255 LOG=info CONF=linux-aarch64-server-release
>> $ ./build/linux-aarch64-server-release/images/jdk/bin/java 
>> -XshowSettings:properties -version 2>&1 | grep aarch64
>> java.home = 
>> /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk
>> os.arch = aarch64
>> sun.boot.library.path = 
>> /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk/lib
>> 
>>> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. 
>>> Is this something you are also experiencing,
>>> and if so, how are you addressing it?
>> 
>> Yes. As far as I understand, the problem is that `fixpath.exe` isn't built 
>> properly when doing cross-compiling on
>> Windows targets (as it hasn't been a thing so far). We use a workaround 
>> internally
>> https://gist.github.com/lewurm/c099a4b5fcd8a182510cbdeebcb41f77 , but a 
>> proper solution is under discussion on
>> build-dev: 
>> https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027872.html
>
>> _Mailing list message from [Andrew Haley](mailto:a...@redhat.com) on 
>> [build-dev](mailto:build-dev@openjdk.java.net):_
>> 
>> On 18/09/2020 11:14, Monica Beckwith wrote:
>> 
>> > This is a continuation of 
>> > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>> 
>> The diffs in assembler_aarch64.cpp are mostly spurious. Please try this.
> 
> 
> Thank you Andrew. Is the goal to reduce the patch diff in 
> `assembler_aarch64.cpp`? If so, we need to get rid of the
> retry in your patch to avoid additional calls to `random`, e.g. something 
> like this (the diff for the generated part
> would look indeed nicer with that:  
> https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ):
> --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py
> +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py
> @@ -13,6 +13,8 @@ class Register(Operand):
> 
>  def generate(self):
>  self.number = random.randint(0, 30)
> +if self.number == 18:
> +self.number = 17
>  return self
> 
>  def astr(self, prefix):
> @@ -37,6 +39,8 @@ class GeneralRegisterOrZr(Register):
> 
>  def generate(self):
>  self.number = random.randint(0, 31)
> +if self.number == 18:
> +self.number = 16
>  return self
> 
>  def astr(self, prefix = ""):
> @@ -54,6 +58,8 @@ class GeneralRegisterOrZr(Register):
>  class GeneralRegisterOrSp(Register):
>  def generate(self):
>  self.number = random.randint(0, 31)
> +if self.number == 18:
> +self.number = 15
>  return self
> 
>  def astr(self, prefix = ""):
> @@ -1331,7 +1337,7 @@ generate(SpecialCases, [["ccmn",   "__ ccmn(zr, zr, 3u, 
> Assembler::LE);",
>  ["st1w",   "__ sve_st1w(z0, __ S, p1, Address(r0, 
> 7));", "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"],
>  ["st1b",   "__ sve_st1b(z0, __ B, p2, Address(sp, 
> r1));","st1b\t{z0.b}, p2, [sp, x1]"],
>  ["st1h",   "__ sve_st1h(z0, __ H, p3, Address(sp, 
> r8));","st1h\t{z0.h}, p3, [sp, x8, LSL #1]"],
> -["st1d",   "__ sve_st1d(z0, __ D, p4, Address(r0, 
> r18));",   "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"],
> +["st1d",   "__ sve_st1d(z0, __ D, p4, Address(r0, 
> r17));",   "st1d\t{z0.d}, p4, [x0, x17,
> LSL #3]"],
>  ["ldr","__ sve_ldr(z0, Address(sp));",   
> "ldr\tz0, [sp]"],
>  ["ldr","__ sve_ldr(z31, Address(sp, -256));",
> "ldr\tz31, [sp, #-256, MUL VL]"],
>  ["str","__ sve_str(z8, Address(r8, 255));",  
> "str\tz8, [x8, #255, MUL VL]"],

> _Mailing list message from [Andrew Haley](mailto:a...@redhat.com) on 
> [build-dev](mailto:build-dev@openjdk.java.net):_
> 
> On 21/09/2020 09:18, Bernhard Urban-Forster wrote:
> 
> > Thank you Andrew. Is the goal to reduce the patch diff in 
> > `assembler_aarch64.cpp`? If so, we need to get rid of the
> > retry in your patch to avoid additional calls to `random`, e.g. something 
> > like this (the diff for the generated part
> > would look indeed nicer with that:  
> >

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3]

2020-09-21 Thread Monica Beckwith 
> This is a continuation of 
> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will 
> be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov 
> in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] 
> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has refreshed the contents of this pull request, and previous 
commits have been removed. The
incremental views will show differences compared to the previous content of the 
PR. The pull request contains 11 new
commits since the last revision:

 - 8248787: G1: Workaround MSVC bug
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248670: Windows: Exception handling support on AArch64
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248660: AArch64: Make _clear_cache and _nop portable
   Summary: __builtin___clear_cache, etc.
   Contributed-by: mbeckwit, luhenry, burban
 - 8248659: AArch64: Extend CPU Feature detection
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248656: Add Windows AArch64 platform support code
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248498: Add build system support for Windows AArch64
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248663: AArch64: Avoid existing macros/keywords of MSVC
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248676: AArch64: Add workaround for LITable constructor
   Reviewed-by: aph
   Contributed-by: mbeckwit, luhenry, burban
 - 8248500: AArch64: Remove the r18 dependency on Windows AArch64 (regenerate 
tests)
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/5f9b0d35...3881b12d

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/212/files
  - new: https://git.openjdk.java.net/jdk/pull/212/files/5f9b0d35..3881b12d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=212=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=01-02

  Stats: 1366 lines in 2 files changed: 6 ins; 4 del; 1356 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions

2020-09-21 Thread Erik Joelsson 
On Mon, 21 Sep 2020 13:32:09 GMT, Robin Westberg  wrote:

> A few days ago I posted an initial version of the necessary configuration 
> required to run pre-submit build and tests
> for JDK main-line contributions using GitHub Actions [2] and the free tier 
> [3] available to everyone working with open
> source repositories. I've incorporated the feedback into an updated version 
> that I believe is ready to be integrated.
> If this is integrated into the `master` branch, future branches created and 
> updated in personal forks will build and
> run the basic tier 1 tests as described in this configuration, on Linux, 
> Windows and macOS (all on x64). It's of course
> possible for any contributor to opt out fully or partially of these automatic 
> runs in a few different ways.  To opt out
> completely, a contributor can simply disable GitHub Actions on their personal 
> fork, and no further jobs will be
> executed. Another option is to add a repository secret [4] with the name 
> `JDK_SUBMIT_FILTER` set to any value. If this
> is set, only branches prefixed with `submit/` will be subject to automatic 
> build and test. This can also be further
> refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a 
> value such as `Linux x64, Windows x64` to
> limit automatic build and test to these two platforms. It will still be 
> possible to run the tests on any branch and/or
> platform by manually triggering the workflow.  To see what this looks like in 
> practice, an example run can be found
> here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that 
> there is currently a failing test on Windows
> which is tracked by JDK-8249095, which should probably be resolved before 
> this change is integrated).  Best regards,
> Robin  [1] 
> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2]
> https://github.com/features/actions [3]
> https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits
>  [4]
> https://docs.github.com/en/actions/reference/encrypted-secrets

Is there any way to derive the version strings for dependencies from a 
different source? Once pushed, this file will
require updating whenever the bootjdk, jtreg version or gtest version is 
updated.

-

PR: https://git.openjdk.java.net/jdk/pull/284

RFR: 8253424: Add support for running pre-submit testing using GitHub Actions

2020-09-21 Thread Robin Westberg 
A few days ago I posted an initial version of the necessary configuration 
required to run pre-submit build and tests
for JDK main-line contributions using GitHub Actions [2] and the free tier [3] 
available to everyone working with open
source repositories. I've incorporated the feedback into an updated version 
that I believe is ready to be integrated.

If this is integrated into the `master` branch, future branches created and 
updated in personal forks will build and
run the basic tier 1 tests as described in this configuration, on Linux, 
Windows and macOS (all on x64). It's of course
possible for any contributor to opt out fully or partially of these automatic 
runs in a few different ways.

To opt out completely, a contributor can simply disable GitHub Actions on their 
personal fork, and no further jobs will
be executed. Another option is to add a repository secret [4] with the name 
`JDK_SUBMIT_FILTER` set to any value. If
this is set, only branches prefixed with `submit/` will be subject to automatic 
build and test. This can also be
further refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with 
a value such as `Linux x64, Windows
x64` to limit automatic build and test to these two platforms. It will still be 
possible to run the tests on any branch
and/or platform by manually triggering the workflow.

To see what this looks like in practice, an example run can be found here:
https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is 
currently a failing test on Windows which
is tracked by JDK-8249095, which should probably be resolved before this change 
is integrated).

Best regards,
Robin

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html
[2] https://github.com/features/actions
[3] 
https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits
[4] https://docs.github.com/en/actions/reference/encrypted-secrets

-

Commit messages:
 - Updates after initial preview
 - Initial version

Changes: https://git.openjdk.java.net/jdk/pull/284/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=284=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253424
  Stats: 739 lines in 1 file changed: 739 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/284.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/284/head:pull/284

PR: https://git.openjdk.java.net/jdk/pull/284

Re: RFR: 8216497: javadoc should auto-link to platform classes [v2]

2020-09-21 Thread Hannes Wallnöfer 
> This pull request is identical with the RFR previously sent for the Mercurial 
> repository:
> 
> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html
> 
> I'm copy-pasting the comments from the original RFR below.
> 
> Most of the new code is added to the Extern class where it fits in quite 
> nicely and can use the existing supporting
> code for setting up external links.
> The default behaviour is to generate links to docs.oracle.com for released 
> versions and download.java.net for
> prereleases. Platform documentation URLs can be configured using the new 
> --link-platform-properties  option to
> provide a properties file with URLs pointing to to alternative locations. See 
> the CSR linked above for more details on
> the new options.  The feature can be disabled using the --no-platform-link 
> option, generating the same output as
> previously.   One problem I had to solve was how to handle the transition 
> from prerelease versions to final releases,
> since the location of the documentation changes in this transition. For 
> obvious reasons we don’t want to make that
> switch via code change at a time shortly before release.  The way it is done 
> is that we determine if the current
> javadoc instance is a prerelease version as indicated by the Version returned 
> by BaseConfiguration#getDocletVersion(),
> and then check whether the release/source version of the current javadoc 
> execution uses the same (latest) version. This
> means that that only the latest version will ever generate prerelease links 
> (e.g. running current javadoc 16 with
> source version 15 will generate links to the final release documentation) but 
> I think this is acceptable.  Another
> issue I spent some time getting right was tests. New releases require a new 
> element-list resource*), so tests have to
> pick up new releases. On the other hand, we don’t want hundreds of tests to 
> fail when a new release is added, ideally
> there should be one test  with a clear message. Because of this, when a 
> release is encountered for which no
> element-list is available a warning is generated instead of an error, and the 
> documentation is generated without
> platform links as if running with --no-platform-link option. This allows most 
> existing tests to pass and just the new
> test to fail with a relatively clear message of what is wrong.
> *) I also thought about generating the element-list for the current release 
> at build time. It’s quite involved, and we
>  still need to maintain element-lists for older versions, so I’m not sure 
> it’s worth it.
> 
> For existing tests that check output affected by the new option I added  the 
> --no-platform-link option to disable the
> feature. Otherwise we’d have to update those tests with each new release (or 
> else freeze the tests to use some static
> release or source version, which we don’t want either).  I updated the CSR to 
> the new code. It also needs to be
> reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181
> 
> Thanks,
> Hannes

Hannes Wallnöfer has updated the pull request incrementally with three 
additional commits since the last revision:

 - Merge pull request #1 from lahodaj/JDK-8216497
   
   Automatically generate the elements-list data from the ct.sym for releases 
11+, including the current release under
   development
 - Generating current release list for javadoc; using hardcoded lists for 
versions < 11
 - Attempting to (mostly) generate the javadoc release manifests from ct.sym 
historical data.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/171/files
  - new: https://git.openjdk.java.net/jdk/pull/171/files/2aed84f8..6d659ae3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=171=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=171=00-01

  Stats: 2007 lines in 9 files changed: 308 ins; 1698 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/171.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/171/head:pull/171

PR: https://git.openjdk.java.net/jdk/pull/171

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2]

2020-09-21 Thread Andrew Haley 
On 21/09/2020 09:18, Bernhard Urban-Forster wrote:
> Thank you Andrew. Is the goal to reduce the patch diff in 
> `assembler_aarch64.cpp`? If so, we need to get rid of the
> retry in your patch to avoid additional calls to `random`, e.g. something 
> like this (the diff for the generated part
> would look indeed nicer with that:  
> https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ):
> 
> --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py
> +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py
> @@ -13,6 +13,8 @@ class Register(Operand):
> 
>  def generate(self):
>  self.number = random.randint(0, 30)
> +if self.number == 18:
> +self.number = 17

Yes, better. Thanks.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2]

2020-09-21 Thread Bernhard Urban-Forster 
On Fri, 18 Sep 2020 18:38:34 GMT, Bernhard Urban-Forster  
wrote:

>> Our linux-aarch64 build fails with this:
>> cc: error: unrecognized command line option '-std=c++14'
>> when compiling 
>> build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch
>> 
>> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is 
>> this something you are also experiencing,
>> and if so, how are you addressing it?
>
> Hey @erikj79, thank you so much for giving it a try!
> 
>> Our linux-aarch64 build fails with this:
>> cc: error: unrecognized command line option '-std=c++14'
>> when compiling 
>> build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch
> 
> Hmm, that's interesting. What environment is that exactly? What `configure` 
> line are you using there? We have tested on
> such a system: $ cat /etc/issue
> Ubuntu 19.10 \n \l
> $ bash configure --with-boot-jdk=/home/beurba/work/jdk-16+13 --with-jtreg
> $ make clean CONF=linux-aarch64-server-release
> $ make images JOBS=255 LOG=info CONF=linux-aarch64-server-release
> $ ./build/linux-aarch64-server-release/images/jdk/bin/java 
> -XshowSettings:properties -version 2>&1 | grep aarch64
> java.home = 
> /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk
> os.arch = aarch64
> sun.boot.library.path = 
> /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk/lib
> 
>> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is 
>> this something you are also experiencing,
>> and if so, how are you addressing it?
> 
> Yes. As far as I understand, the problem is that `fixpath.exe` isn't built 
> properly when doing cross-compiling on
> Windows targets (as it hasn't been a thing so far). We use a workaround 
> internally
> https://gist.github.com/lewurm/c099a4b5fcd8a182510cbdeebcb41f77 , but a 
> proper solution is under discussion on
> build-dev: 
> https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027872.html

> _Mailing list message from [Andrew Haley](mailto:a...@redhat.com) on 
> [build-dev](mailto:build-dev@openjdk.java.net):_
> 
> On 18/09/2020 11:14, Monica Beckwith wrote:
> 
> > This is a continuation of 
> > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
> 
> The diffs in assembler_aarch64.cpp are mostly spurious. Please try this.


Thank you Andrew. Is the goal to reduce the patch diff in 
`assembler_aarch64.cpp`? If so, we need to get rid of the
retry in your patch to avoid additional calls to `random`, e.g. something like 
this (the diff for the generated part
would look indeed nicer with that:  
https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ):

--- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py
+++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py
@@ -13,6 +13,8 @@ class Register(Operand):

 def generate(self):
 self.number = random.randint(0, 30)
+if self.number == 18:
+self.number = 17
 return self

 def astr(self, prefix):
@@ -37,6 +39,8 @@ class GeneralRegisterOrZr(Register):

 def generate(self):
 self.number = random.randint(0, 31)
+if self.number == 18:
+self.number = 16
 return self

 def astr(self, prefix = ""):
@@ -54,6 +58,8 @@ class GeneralRegisterOrZr(Register):
 class GeneralRegisterOrSp(Register):
 def generate(self):
 self.number = random.randint(0, 31)
+if self.number == 18:
+self.number = 15
 return self

 def astr(self, prefix = ""):
@@ -1331,7 +1337,7 @@ generate(SpecialCases, [["ccmn",   "__ ccmn(zr, zr, 3u, 
Assembler::LE);",
 ["st1w",   "__ sve_st1w(z0, __ S, p1, Address(r0, 
7));", "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"],
 ["st1b",   "__ sve_st1b(z0, __ B, p2, Address(sp, 
r1));","st1b\t{z0.b}, p2, [sp, x1]"],
 ["st1h",   "__ sve_st1h(z0, __ H, p3, Address(sp, 
r8));","st1h\t{z0.h}, p3, [sp, x8, LSL #1]"],
-["st1d",   "__ sve_st1d(z0, __ D, p4, Address(r0, 
r18));",   "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"],
+["st1d",   "__ sve_st1d(z0, __ D, p4, Address(r0, 
r17));",   "st1d\t{z0.d}, p4, [x0, x17,
LSL #3]"],
 ["ldr","__ sve_ldr(z0, Address(sp));", 
  "ldr\tz0, [sp]"],
 ["ldr","__ sve_ldr(z31, Address(sp, -256));",  
  "ldr\tz31, [sp, #-256, MUL VL]"],
 ["str","__ sve_str(z8, Address(r8, 255));",
  "str\tz8, [x8, #255, MUL VL]"],

-

PR: https://git.openjdk.java.net/jdk/pull/212

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2]

2020-09-21 Thread Monica Beckwith 
> This is a continuation of 
> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will 
> be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov 
> in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] 
> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has refreshed the contents of this pull request, and previous 
commits have been removed. The
incremental views will show differences compared to the previous content of the 
PR. The pull request contains six new
commits since the last revision:

 - 8248787: G1: Workaround MSVC bug
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248670: Windows: Exception handling support on AArch64
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248660: AArch64: Make _clear_cache and _nop portable
   Summary: __builtin___clear_cache, etc.
   Contributed-by: mbeckwit, luhenry, burban
 - 8248659: AArch64: Extend CPU Feature detection
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248656: Add Windows AArch64 platform support code
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248498: Add build system support for Windows AArch64
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/212/files
  - new: https://git.openjdk.java.net/jdk/pull/212/files/26e4af3a..5f9b0d35

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=212=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2]

2020-09-21 Thread Bernhard Urban-Forster 
On Fri, 18 Sep 2020 20:34:55 GMT, Erik Joelsson  wrote:

> I assume you need the rest of the PATH on Windows.

Doesn't look like it actually. I've reverted it, thanks for catching it.

-

PR: https://git.openjdk.java.net/jdk/pull/212

Integrated: 8253253: Binutils tar ball extension update to gz

2020-09-21 Thread Junyuan Zheng 
On Tue, 15 Sep 2020 04:54:04 GMT, Junyuan Zheng 
 wrote:

> Our infra team found this error when building DevKit with GCC 4.9.2. The 
> binutils version is 2.25, and an *.xz doesn't
> exist on https://ftp.gnu.org/pub/gnu/binutils.  Hence, we would like to 
> submit a PR to update *.xz to *.gz.
> We have confirmed that *.gz exists for all binutil version.

This pull request has now been integrated.

Changeset: fdce055a
Author:Junyuan Zheng <53073448+junyzh...@users.noreply.github.com>
Committer: Aleksey Shipilev 
URL:   https://git.openjdk.java.net/jdk/commit/fdce055a
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod

8253253: Binutils tar ball extension update to gz

Reviewed-by: erikj

-

PR: https://git.openjdk.java.net/jdk/pull/162