From kim.barrett at oracle.com Sat Jan 2 18:30:29 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 2 Jan 2021 13:30:29 -0500 Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion In-Reply-To: References: Message-ID: <4D06C0A2-98B7-45B7-80E1-9D43DB056AC4@oracle.com> > On Dec 24, 2020, at 3:44 PM, Xin Liu wrote: > > On Thu, 24 Dec 2020 17:27:39 GMT, Kim Barrett wrote: >> [?] >> Since DUIterator_Last is just delegating both the copy constructor and >> assignment operator to the base class, their copy constructor and >> assignment operator would be better as the default (either implicit or >> explicit using `=default`) rather than explicit code. > > Agree. c2 actually never uses the assignment operator of DUIterator_Last. It needs the copy constructor in this line. > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1499 > > you can delete the following code or leave it =default. > - void operator=(const DUIterator_Last& that) > - { DUIterator_Fast::operator=(that); } DUIterator_Last::operator= *is* used, for example: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1473 That doesn't change whether defaulting DUIIterator_Last's copy constructor and copy assign works though (whether implicit or explicit). So making it implicit does work. I think making it explicitly defaulted might be better though, to make it clear the default behavior is intentional and it wasn't accidentally left as the implicit default. This is because the default isn't right for the other related classes. From kim.barrett at oracle.com Sun Jan 3 04:17:11 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 2 Jan 2021 23:17:11 -0500 Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: References: <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com> Message-ID: <24624BC7-B710-4DCA-8616-D78990363B57@oracle.com> > On Dec 29, 2020, at 10:33 PM, Hao Sun wrote: > >> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >> >> >> C++17 "guaranteed copy elision" is implemented in gcc7. >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html >> > > Thanks for your comment. > Initially we only suspected it might be copy elision that made gcc and clang to behave differently on this warning, and we were not aware of this flag '-fno-elide-constructors'. > Thank you for pointing it out. > >> Using -fno-elide-constructors makes it obvious that the deprecated >> implicit copy constructors are indeed being elided, so no deprecation >> warning. >> > > I suppose you want to express 'Using -**felide-constructors**' here. > gcc with '-fno-elide-constructos' would produce derepcated warnings for this issue as clang-10 does. I really did mean "-fno-elide-constructors". The idea is that having the normally working build fail with "-fno-elide-constructors" provides evidence for the "working because of copy elision" conjecture. clang has supported -f[no-]elide-constructors for a while. It appears that either clang is different from gcc for -felide-constructors (which seems unlikely), or clang (clang-10) is doing the deprecation warning at a different point from gcc (quite plausible). That is, clang could be checking for the deprecated case before eliding the call, while gcc is checking for the deprecated case after copy elision has been applied. >> Why doesn't this patch similarly define DUIterator copy constructor? >> It seems to have the same issue, and I'm surprised clang-10 didn't >> complain about it too. Certainly gcc with -fno-elide-constructors >> complains about the defaulted implicit constructor. >> > > I'm afraid we have noticed the same issue for 'DUIterator' before. > Yes. It's weird that clang-10 didn't raise warning here. ( verified it on my local machine.) Yes, that?s weird. >> But I discovered something alarming while experimenting. Building >> with gcc10.2 with -fno-elide-constructors doesn't seem to be possible. >> I get different kinds of failures depending on how DUIterator is >> defined: >> >> - implict: deprecation warning (as expected) >> - =delete: error, deleted function used >> - =default: assert in os::free >> - _idx and reset from that: assert in reset >> >> Without -fno-elide-constructors, all of the variants seem to work >> except =delete, which still fails because the deleted function is >> used. (I didn't test the "working" cases extensively though.) >> >> So there's something problematic, though I don't understand the code >> well enough to understand what. > > Thanks for your tests. > But I have no idea how to fix it right now either. > Do you know anyone who is familiar with these code and maybe we can invite him/her to help take a look at this issue? > Thanks. I have a suspicion that the assert failure when building with -fno-elide-constructors has nothing to do with DUIterator stuff, and is instead a problem elsewhere. But it certainly makes it hard to feel confident that the additional constructors being added are correct. I'm going to try to do some investigating of that assert failure, and see if I can figure out what's going on. Anyone else should feel free to join in. The failure is # Internal Error (../../src/hotspot/share/runtime/thread.hpp:850), pid=29939, tid=29939 # assert(current != __null) failed: Thread::current() called on detached thread From kim.barrett at oracle.com Sun Jan 3 08:51:17 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 3 Jan 2021 03:51:17 -0500 Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: <24624BC7-B710-4DCA-8616-D78990363B57@oracle.com> References: <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com> <24624BC7-B710-4DCA-8616-D78990363B57@oracle.com> Message-ID: <72204700-69A0-4870-9A6B-100F120D2BB0@oracle.com> > On Jan 2, 2021, at 11:17 PM, Kim Barrett wrote: > >> On Dec 29, 2020, at 10:33 PM, Hao Sun wrote: >> >>> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >>> But I discovered something alarming while experimenting. Building >>> with gcc10.2 with -fno-elide-constructors doesn't seem to be possible. >>> I get different kinds of failures depending on how DUIterator is >>> defined: >>> >>> - implict: deprecation warning (as expected) >>> - =delete: error, deleted function used >>> - =default: assert in os::free >>> - _idx and reset from that: assert in reset >>> >>> Without -fno-elide-constructors, all of the variants seem to work >>> except =delete, which still fails because the deleted function is >>> used. (I didn't test the "working" cases extensively though.) >>> >>> So there's something problematic, though I don't understand the code >>> well enough to understand what. >> >> Thanks for your tests. >> But I have no idea how to fix it right now either. >> Do you know anyone who is familiar with these code and maybe we can invite him/her to help take a look at this issue? >> Thanks. > > I have a suspicion that the assert failure when building with > -fno-elide-constructors has nothing to do with DUIterator stuff, and is > instead a problem elsewhere. But it certainly makes it hard to feel > confident that the additional constructors being added are correct. > > I'm going to try to do some investigating of that assert failure, and see if > I can figure out what's going on. Anyone else should feel free to join in. > The failure is > > # Internal Error (../../src/hotspot/share/runtime/thread.hpp:850), pid=29939, tid=29939 > # assert(current != __null) failed: Thread::current() called on detached thread The assert failure when building with -fno-elide-constructors is a known issue: https://bugs.openjdk.java.net/browse/JDK-8234773 I thought it looked vaguely familiar, but it took a while to track down. I think I'm going to deal with it so nobody runs into it again. From github.com+16932759+shqking at openjdk.java.net Mon Jan 4 01:21:58 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Mon, 4 Jan 2021 01:21:58 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: References: <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com> Message-ID: On Wed, 30 Dec 2020 03:31:38 GMT, Hao Sun wrote: >> LGTM. It still needs other's approval. > >> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >> >> > On Dec 22, 2020, at 8:52 PM, Hao Sun wrote: >> > 1. '-Wdeprecated-copy' >> > As specified in C++11 [1], "the generation of the implicitly-defined >> > copy constructor is deprecated if T has a user-defined destructor or >> > user-defined copy assignment operator". The rationale behind is the >> > well-known Rule of Three [2]. >> > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' >> > warns about the C++11 deprecation of implicitly declared copy >> > constructor and assignment operator if one of them is user-provided. >> > Defining an explicit copy constructor would suppress this warning. >> > The main reason why debug build with gcc-9 or higher succeeds lies in >> > the inconsistent warning behaviors between gcc and clang. See the >> > reduced code example [5]. We suspect it might be return value >> > optimization/copy elision [6] that drives gcc not to declare implicit >> > copy constructor for this case. >> >> C++17 "guaranteed copy elision" is implemented in gcc7. >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html >> > > Thanks for your comment. > Initially we only suspected it might be copy elision that made gcc and clang to behave differently on this warning, and we were not aware of this flag '-fno-elide-constructors'. > Thank you for pointing it out. > >> Using -fno-elide-constructors makes it obvious that the deprecated >> implicit copy constructors are indeed being elided, so no deprecation >> warning. >> > > I suppose you want to express 'Using -**felide-constructors**' here. > gcc with '-fno-elide-constructos' would produce derepcated warnings for this issue as clang-10 does. > >> Why doesn't this patch similarly define DUIterator copy constructor? >> It seems to have the same issue, and I'm surprised clang-10 didn't >> complain about it too. Certainly gcc with -fno-elide-constructors >> complains about the defaulted implicit constructor. >> > > I'm afraid we have noticed the same issue for 'DUIterator' before. > Yes. It's weird that clang-10 didn't raise warning here. ( verified it on my local machine.) > >> But I discovered something alarming while experimenting. Building >> with gcc10.2 with -fno-elide-constructors doesn't seem to be possible. >> I get different kinds of failures depending on how DUIterator is >> defined: >> >> - implict: deprecation warning (as expected) >> - =delete: error, deleted function used >> - =default: assert in os::free >> - _idx and reset from that: assert in reset >> >> Without -fno-elide-constructors, all of the variants seem to work >> except =delete, which still fails because the deleted function is >> used. (I didn't test the "working" cases extensively though.) >> >> So there's something problematic, though I don't understand the code >> well enough to understand what. > > Thanks for your tests. > But I have no idea how to fix it right now either. > Do you know anyone who is familiar with these code and maybe we can invite him/her to help take a look at this issue? > Thanks. > >> >> Interestingly, some of the complexity and weirdness around copy/assign >> for these classes may be an attempt at providing something like move >> semantics in a C++98 code base. I've noticed a number of places in >> HotSpot that are doing that. >> >> Defining DUIterator_Fast and DUIterator_Last as movable but not >> copyable (explicitly delete the copy constructor and copy assign >> operator, and define the move constructor and move assign operator >> with the reset) works, even with -fno-elide-constructors. > _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ > > > On Dec 24, 2020, at 3:44 PM, Xin Liu wrote: > > On Thu, 24 Dec 2020 17:27:39 GMT, Kim Barrett wrote: > > > [?] > > > Since DUIterator_Last is just delegating both the copy constructor and > > > assignment operator to the base class, their copy constructor and > > > assignment operator would be better as the default (either implicit or > > > explicit using `=default`) rather than explicit code. > > > > > > Agree. c2 actually never uses the assignment operator of DUIterator_Last. It needs the copy constructor in this line. > > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1499 > > you can delete the following code or leave it =default. > > - void operator=(const DUIterator_Last& that) > > - { DUIterator_Fast::operator=(that); } > > DUIterator_Last::operator= *is* used, for example: > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1473 > > That doesn't change whether defaulting DUIIterator_Last's copy constructor > and copy assign works though (whether implicit or explicit). So making it > implicit does work. > > I think making it explicitly defaulted might be better though, to make it > clear the default behavior is intentional and it wasn't accidentally left as > the implicit default. This is because the default isn't right for the other > related classes. Yes. You're right. It's much better to make it explicitly defaulted. May I have your opinion @navyxliu ? ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From github.com+16932759+shqking at openjdk.java.net Mon Jan 4 04:33:55 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Mon, 4 Jan 2021 04:33:55 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: References: <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com> Message-ID: On Mon, 4 Jan 2021 01:18:47 GMT, Hao Sun wrote: >>> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >>> >>> > On Dec 22, 2020, at 8:52 PM, Hao Sun wrote: >>> > 1. '-Wdeprecated-copy' >>> > As specified in C++11 [1], "the generation of the implicitly-defined >>> > copy constructor is deprecated if T has a user-defined destructor or >>> > user-defined copy assignment operator". The rationale behind is the >>> > well-known Rule of Three [2]. >>> > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' >>> > warns about the C++11 deprecation of implicitly declared copy >>> > constructor and assignment operator if one of them is user-provided. >>> > Defining an explicit copy constructor would suppress this warning. >>> > The main reason why debug build with gcc-9 or higher succeeds lies in >>> > the inconsistent warning behaviors between gcc and clang. See the >>> > reduced code example [5]. We suspect it might be return value >>> > optimization/copy elision [6] that drives gcc not to declare implicit >>> > copy constructor for this case. >>> >>> C++17 "guaranteed copy elision" is implemented in gcc7. >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html >>> >> >> Thanks for your comment. >> Initially we only suspected it might be copy elision that made gcc and clang to behave differently on this warning, and we were not aware of this flag '-fno-elide-constructors'. >> Thank you for pointing it out. >> >>> Using -fno-elide-constructors makes it obvious that the deprecated >>> implicit copy constructors are indeed being elided, so no deprecation >>> warning. >>> >> >> I suppose you want to express 'Using -**felide-constructors**' here. >> gcc with '-fno-elide-constructos' would produce derepcated warnings for this issue as clang-10 does. >> >>> Why doesn't this patch similarly define DUIterator copy constructor? >>> It seems to have the same issue, and I'm surprised clang-10 didn't >>> complain about it too. Certainly gcc with -fno-elide-constructors >>> complains about the defaulted implicit constructor. >>> >> >> I'm afraid we have noticed the same issue for 'DUIterator' before. >> Yes. It's weird that clang-10 didn't raise warning here. ( verified it on my local machine.) >> >>> But I discovered something alarming while experimenting. Building >>> with gcc10.2 with -fno-elide-constructors doesn't seem to be possible. >>> I get different kinds of failures depending on how DUIterator is >>> defined: >>> >>> - implict: deprecation warning (as expected) >>> - =delete: error, deleted function used >>> - =default: assert in os::free >>> - _idx and reset from that: assert in reset >>> >>> Without -fno-elide-constructors, all of the variants seem to work >>> except =delete, which still fails because the deleted function is >>> used. (I didn't test the "working" cases extensively though.) >>> >>> So there's something problematic, though I don't understand the code >>> well enough to understand what. >> >> Thanks for your tests. >> But I have no idea how to fix it right now either. >> Do you know anyone who is familiar with these code and maybe we can invite him/her to help take a look at this issue? >> Thanks. >> >>> >>> Interestingly, some of the complexity and weirdness around copy/assign >>> for these classes may be an attempt at providing something like move >>> semantics in a C++98 code base. I've noticed a number of places in >>> HotSpot that are doing that. >>> >>> Defining DUIterator_Fast and DUIterator_Last as movable but not >>> copyable (explicitly delete the copy constructor and copy assign >>> operator, and define the move constructor and move assign operator >>> with the reset) works, even with -fno-elide-constructors. > >> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >> >> > On Dec 24, 2020, at 3:44 PM, Xin Liu wrote: >> > On Thu, 24 Dec 2020 17:27:39 GMT, Kim Barrett wrote: >> > > [?] >> > > Since DUIterator_Last is just delegating both the copy constructor and >> > > assignment operator to the base class, their copy constructor and >> > > assignment operator would be better as the default (either implicit or >> > > explicit using `=default`) rather than explicit code. >> > >> > >> > Agree. c2 actually never uses the assignment operator of DUIterator_Last. It needs the copy constructor in this line. >> > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1499 >> > you can delete the following code or leave it =default. >> > - void operator=(const DUIterator_Last& that) >> > - { DUIterator_Fast::operator=(that); } >> >> DUIterator_Last::operator= *is* used, for example: >> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1473 >> >> That doesn't change whether defaulting DUIIterator_Last's copy constructor >> and copy assign works though (whether implicit or explicit). So making it >> implicit does work. >> >> I think making it explicitly defaulted might be better though, to make it >> clear the default behavior is intentional and it wasn't accidentally left as >> the implicit default. This is because the default isn't right for the other >> related classes. > > Yes. You're right. It's much better to make it explicitly defaulted. > May I have your opinion @navyxliu ? > _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ > > > On Dec 29, 2020, at 10:33 PM, Hao Sun wrote: > > > _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ > > > C++17 "guaranteed copy elision" is implemented in gcc7. > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html > > > > > > Thanks for your comment. > > Initially we only suspected it might be copy elision that made gcc and clang to behave differently on this warning, and we were not aware of this flag '-fno-elide-constructors'. > > Thank you for pointing it out. > > > Using -fno-elide-constructors makes it obvious that the deprecated > > > implicit copy constructors are indeed being elided, so no deprecation > > > warning. > > > > > > I suppose you want to express 'Using -**felide-constructors**' here. > > gcc with '-fno-elide-constructos' would produce derepcated warnings for this issue as clang-10 does. > > I really did mean "-fno-elide-constructors". The idea is that having the > normally working build fail with "-fno-elide-constructors" provides evidence > for the "working because of copy elision" conjecture. > > clang has supported -f[no-]elide-constructors for a while. > > It appears that either clang is different from gcc for -felide-constructors > (which seems unlikely), or clang (clang-10) is doing the deprecation warning > at a different point from gcc (quite plausible). That is, clang could be > checking for the deprecated case before eliding the call, while gcc is > checking for the deprecated case after copy elision has been applied. Thanks for your reply. I checked the source code of clang-10 and gcc-9 and found that: 1) for clang-10, 'Wdeprecated-copy' is implemented at the 'Sema' module of clang. See https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/Sema/SemaDeclCXX.cpp#L13585 Flag 'felide-constructors' would enable 'felide_constructors' and flag 'fno-elide-constructors' would enables 'fno_elide_constructors'. (See https://github.com/llvm/llvm-project/blob/release/10.x/clang/include/clang/Driver/Options.td). Then 'ElideConstructors' will be set (See https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/Frontend/CompilerInvocation.cpp#L2863) Finally, constructors might be elided in several spots in 'CodeGen' module. See: https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/CodeGen/CGStmt.cpp#L1094 https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/CodeGen/CGExprCXX.cpp#L611 https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/CodeGen/CGDecl.cpp#L1405 As far as I know, 'Sema' module is conducted to check semantics errors before 'CodeGen' module. That verified your conjecture, i.e. 'clang could be checking for the derepcated case before eliding the call'. 2) for gcc-9, 'felide-constructors' and 'Wdeprecated-copy' are implemented in a number of spots in gcc. I currently didn't figure out their execution order clearly. But in one of the use points at function build_over_call(), 'flag_elide_constructors' (See https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/cp/call.c#L8538) is handled **before** 'warn_deprecated_copy' (See https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/cp/call.c#L8608 and https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/cp/call.c#L8679) Hope that my finding is helpful. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From kbarrett at openjdk.java.net Mon Jan 4 06:25:57 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 4 Jan 2021 06:25:57 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: References: Message-ID: On Mon, 28 Dec 2020 10:28:09 GMT, Hao Sun wrote: >> 1. '-Wdeprecated-copy' >> As specified in C++11 [1], "the generation of the implicitly-defined >> copy constructor is deprecated if T has a user-defined destructor or >> user-defined copy assignment operator". The rationale behind is the >> well-known Rule of Three [2]. >> >> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' >> warns about the C++11 deprecation of implicitly declared copy >> constructor and assignment operator if one of them is user-provided. >> Defining an explicit copy constructor would suppress this warning. >> >> The main reason why debug build with gcc-9 or higher succeeds lies in >> the inconsistent warning behaviors between gcc and clang. See the >> reduced code example [5]. We suspect it might be return value >> optimization/copy elision [6] that drives gcc not to declare implicit >> copy constructor for this case. >> >> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise >> warnings for deprecated defintions of copy constructors. However, >> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 >> and clang-9 are not affected. >> >> 2. '-Wimplicit-int-float-conversion' >> Making the conversion explicit would fix it. >> >> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. >> Therefore clang-8 and clang-9 are not affected. The flag with similar >> functionality in gcc is '-Wfloat-conversion', but it is not enabled by >> '-Wall' or '-Wextra'. That's why this warning does not apprear when >> building with gcc. >> >> [1] https://en.cppreference.com/w/cpp/language/copy_constructor >> [2] https://en.cppreference.com/w/cpp/language/rule_of_three >> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html >> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html >> [5] https://godbolt.org/z/err4jM >> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization >> >> >> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines. > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Remove the unused assignment operator for DUIterator_Last > > Instead of adding the copy constructor, remove the assignment operator > of DUIterator_Last since it's never used. > > Change-Id: Idf5658e38861eb2b0e724b064d17e9ab4e93905f > CustomizedGitHooks: yes src/hotspot/share/opto/node.hpp line 1396: > 1394: > 1395: DUIterator_Fast(const DUIterator_Fast& that) > 1396: { _outp = that._outp; debug_only(reset(that)); } `reset` tests `_vdui`, but nothing here has set it, so it's uninitialized and that test wil be UB. I'm also not sure why it's okay for `operator=` to use whatever the current value of `_vdui` might be; that could leave `_last` as the old value rather than refreshing from `that`, which seems wrong. This is aabout pre-existing code that looks questionable to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From kim.barrett at oracle.com Mon Jan 4 06:27:13 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 4 Jan 2021 01:27:13 -0500 Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: References: <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com> Message-ID: <7AECF807-540E-4FD7-9C18-FBF67003F49B@oracle.com> > On Jan 3, 2021, at 11:33 PM, Hao Sun wrote: > > On Mon, 4 Jan 2021 01:18:47 GMT, Hao Sun wrote: > >>>> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >> >> It appears that either clang is different from gcc for -felide-constructors >> (which seems unlikely), or clang (clang-10) is doing the deprecation warning >> at a different point from gcc (quite plausible). That is, clang could be >> checking for the deprecated case before eliding the call, while gcc is >> checking for the deprecated case after copy elision has been applied. > > Thanks for your reply. > I checked the source code of clang-10 and gcc-9 and found that: > > 1) for clang-10, > 'Wdeprecated-copy' is implemented at the 'Sema' module of clang. See https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/Sema/SemaDeclCXX.cpp#L13585 > > Flag 'felide-constructors' would enable 'felide_constructors' and flag 'fno-elide-constructors' would enables 'fno_elide_constructors'. (See https://github.com/llvm/llvm-project/blob/release/10.x/clang/include/clang/Driver/Options.td). > Then 'ElideConstructors' will be set (See https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/Frontend/CompilerInvocation.cpp#L2863) > Finally, constructors might be elided in several spots in 'CodeGen' module. > See: > https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/CodeGen/CGStmt.cpp#L1094 > https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/CodeGen/CGExprCXX.cpp#L611 > https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/CodeGen/CGDecl.cpp#L1405 > > As far as I know, 'Sema' module is conducted to check semantics errors before 'CodeGen' module. > That verified your conjecture, i.e. 'clang could be checking for the derepcated case before eliding the call'. > > 2) for gcc-9, > 'felide-constructors' and 'Wdeprecated-copy' are implemented in a number of spots in gcc. I currently didn't figure out their execution order clearly. > > But in one of the use points at function build_over_call(), 'flag_elide_constructors' (See https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/cp/call.c#L8538) is handled **before** 'warn_deprecated_copy' (See https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/cp/call.c#L8608 and https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/cp/call.c#L8679) > > Hope that my finding is helpful. Thanks. Yes, that would explain the different warning behaviors. Thanks for digging through that. From github.com+16932759+shqking at openjdk.java.net Mon Jan 4 07:02:55 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Mon, 4 Jan 2021 07:02:55 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 06:22:46 GMT, Kim Barrett wrote: >> Hao Sun has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the unused assignment operator for DUIterator_Last >> >> Instead of adding the copy constructor, remove the assignment operator >> of DUIterator_Last since it's never used. >> >> Change-Id: Idf5658e38861eb2b0e724b064d17e9ab4e93905f >> CustomizedGitHooks: yes > > src/hotspot/share/opto/node.hpp line 1396: > >> 1394: >> 1395: DUIterator_Fast(const DUIterator_Fast& that) >> 1396: { _outp = that._outp; debug_only(reset(that)); } > > `reset` tests `_vdui`, but nothing here has set it, so it's uninitialized and that test wil be UB. > > I'm also not sure why it's okay for `operator=` to use whatever the current value of `_vdui` might be; that could leave `_last` as the old value rather than refreshing from `that`, which seems wrong. This is aabout pre-existing code that looks questionable to me. I suppose the constructor would be invoked before the copy assignment operator. That is `_vdui` gets initialized already in the ctor `DUIterator_Fast()` for `operator=` case. Right? Yes. For our newly-added copy constructor for `DUIterator_Fast`, we should initialize `_vdui` as `false`. It may be defined as below. DUIterator_Fast(const DUIterator_Fast& that) { _outp = that._outp; debug_only(_vdui = false; reset(that)); } ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From shade at redhat.com Mon Jan 4 08:35:22 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Jan 2021 09:35:22 +0100 Subject: [patch] link libjvm with -latomic In-Reply-To: <845e9d8c-d25c-b1d2-df62-e5130481d297@oracle.com> References: <90671a28-0464-37e7-fc3d-1372a1bf8a77@ubuntu.com> <845e9d8c-d25c-b1d2-df62-e5130481d297@oracle.com> Message-ID: Hi, Thanks for the testing and the report, Matthias! On 12/11/20 11:29 AM, Magnus Ihse Bursie wrote: > If we need -latomic on certain platforms we should add it on those > platforms, but I would prefer not to add it unconditionally. But then > again, if you want to add it for a bunch of system which are only > supported on zero, I will not argue hard against it. This whole shebang is Zero-specific problem, so I see no reason to link libatomic unconditionally. AFAICS, Matthias' patch adds libatomic to platforms that are nominally supported by Server (i.e. ARM). It used to handle only MIPS that is only supported by Zero. So the patch would be a bit reworked to accept only Zero. I did it here: https://bugs.openjdk.java.net/browse/JDK-8259043 https://github.com/openjdk/jdk16/pull/76 Matthias, please give it a spin, if you can. -- Thanks, -Aleksey From shade at openjdk.java.net Mon Jan 4 08:40:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 4 Jan 2021 08:40:09 GMT Subject: [jdk16] RFR: 8259043: More Zero architectures need linkage with libatomic Message-ID: JDK-8256831 added the Zero linkage with libatomic for MIPS, but there are other 32-bit Zero platforms that need the same kind of treatment. Additional testing: - [x] linux-mipsel-zero-fastdebug build ------------- Commit messages: - 8259043: More Zero architectures need linkage with libatomic Changes: https://git.openjdk.java.net/jdk16/pull/76/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=76&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259043 Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk16/pull/76.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/76/head:pull/76 PR: https://git.openjdk.java.net/jdk16/pull/76 From kbarrett at openjdk.java.net Mon Jan 4 09:43:56 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 4 Jan 2021 09:43:56 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 06:59:54 GMT, Hao Sun wrote: >> src/hotspot/share/opto/node.hpp line 1396: >> >>> 1394: >>> 1395: DUIterator_Fast(const DUIterator_Fast& that) >>> 1396: { _outp = that._outp; debug_only(reset(that)); } >> >> `reset` tests `_vdui`, but nothing here has set it, so it's uninitialized and that test wil be UB. >> >> I'm also not sure why it's okay for `operator=` to use whatever the current value of `_vdui` might be; that could leave `_last` as the old value rather than refreshing from `that`, which seems wrong. This is aabout pre-existing code that looks questionable to me. > > I suppose the constructor would be invoked before the copy assignment operator. That is `_vdui` gets initialized already in the ctor `DUIterator_Fast()` for `operator=` case. Right? > Take the following code snippet as an example. > DUIterator_Fast t1, t2; > t2 = t1; // assignment operator > DUIterator_Fast t3 = t1; // copy constructor. same as "t3(t1)" > My point is that, the ctor for `t2` has already invoked, i.e. initializing `_vdui` as false. That's why `operator=` works well. > > > Yes. For our newly-added copy constructor for `DUIterator_Fast`, we should initialize `_vdui` as `false`. It may be defined as below. > DUIterator_Fast(const DUIterator_Fast& that) > { _outp = that._outp; debug_only(_vdui = false; reset(that)); } That's true on the first assignment of `t2`. But what if `t2` is reassigned to some other iterator. That assignment sees `_vdui` true, and keeps the old value of `_last` rather than updating the value from that other iterator. Is that really correct? It certainly seems strange. I'm trying to find someone who understands this code to get involved, but holidays. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From shade at openjdk.java.net Mon Jan 4 10:11:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 4 Jan 2021 10:11:57 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun wrote: > From the error log we can see the root cause is that, develop_pd flag > 'pd_CICompileOSR' is undeclared in zero build. > > Where this flag is used? > Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 > of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. > > Where this flag can be declared? > Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if > VM is built with compiler1 or compiler2. See lines 30 to 38 of > 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get > declared in the header files for specific arch, e.g., > 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. > However, regarding zero build (without compiler1 and compiler2 and > jvmci) , this flag is undelcared. Hence, this patch gets header file > 'compiler/compiler_globals_pd.hpp' included where this flag is declared > for the case when neither COMPILER1 nor COMPILER2 are defined and > INCLUDE_JVMCI is inactive. > > Note that 'compiler/compiler_globals_pd.hpp' already includes > 'runtime/globals_shared.hpp'. > > Note that zero build with PCH succeeds because 'runtime/globals.hpp' is > included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is > included in 'runtime/globals.hpp'. It is unclear to me why the original change in JDK-8258074 included `compiler_globals_pd.hpp` in `globals.hpp` at all, @iklam? It seems what @shqking proposes is sound. I believe we should additionally change the `#include compiler/compiler_globals_pd.hpp` to `#include compiler/compiler_globals.hpp` in `globals.hpp`? @shqking, please go to https://github.com/shqking/jdk/actions -- and enable GH Actions, then trigger the workflow manually on your branch to get this tested. ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1894 From github.com+16932759+shqking at openjdk.java.net Mon Jan 4 10:17:57 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Mon, 4 Jan 2021 10:17:57 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 09:41:01 GMT, Kim Barrett wrote: >> I suppose the constructor would be invoked before the copy assignment operator. That is `_vdui` gets initialized already in the ctor `DUIterator_Fast()` for `operator=` case. Right? >> Take the following code snippet as an example. >> DUIterator_Fast t1, t2; >> t2 = t1; // assignment operator >> DUIterator_Fast t3 = t1; // copy constructor. same as "t3(t1)" >> My point is that, the ctor for `t2` has already invoked, i.e. initializing `_vdui` as false. That's why `operator=` works well. >> >> >> Yes. For our newly-added copy constructor for `DUIterator_Fast`, we should initialize `_vdui` as `false`. It may be defined as below. >> DUIterator_Fast(const DUIterator_Fast& that) >> { _outp = that._outp; debug_only(_vdui = false; reset(that)); } > > That's true on the first assignment of `t2`. But what if `t2` is reassigned > to some other iterator. That assignment sees `_vdui` true, and keeps the old > value of `_last` rather than updating the value from that other iterator. Is > that really correct? It certainly seems strange. I'm trying to find someone > who understands this code to get involved, but holidays. Thanks for your explanation. Yes, you're right. I didn't realize the re-assignment scenario. However, I noticed that there does NOT exist such re-assignment cases. Simply grep `= DUIterator_Last(` and `= DUIterator_Fast(`. Is there anything I missed? ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From ysuenaga at openjdk.java.net Mon Jan 4 11:50:04 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 4 Jan 2021 11:50:04 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale Message-ID: I got garbled exception message as following when I run `livenmethods` CLHSDB command: sun.jvm.hotspot.debugger.DebuggerException : ?w???????W My Windows laptop is set Japanese Locale, garbled message was written in Japanese. saproc.dll would throw exception via [ThrowNew()](https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#thrownew) JNI function, but it accepts UTF-8 encoded message. However [FormatMessage()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage) Windows API might not return UTF-8 encoded string on Japanese locale. java.dll (libjava,so) provides good functions to resolve this issue. We can convert localized (non ascii) chars to UTF-8 string. I use them in this PR and remove `FormatMessage()` call from sadis.c. And also I remove `-D_MBCS` from compiler option because [MBCS has been already deprecated](https://docs.microsoft.com/ja-jp/cpp/text/support-for-multibyte-character-sets-mbcss) - it does not seem to add to any other executables. ------------- Commit messages: - 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale Changes: https://git.openjdk.java.net/jdk/pull/1928/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1928&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259045 Stats: 50 lines in 2 files changed: 4 ins; 37 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1928/head:pull/1928 PR: https://git.openjdk.java.net/jdk/pull/1928 From erikj at openjdk.java.net Mon Jan 4 15:18:55 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 4 Jan 2021 15:18:55 GMT Subject: RFR: 8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk [v3] In-Reply-To: <9xkNifNu1u9_edtzKO1GsygtwNwAM91k1o6iaw0KvS4=.c0c96c97-c13f-4f1b-97fe-a79abace039c@github.com> References: <9xkNifNu1u9_edtzKO1GsygtwNwAM91k1o6iaw0KvS4=.c0c96c97-c13f-4f1b-97fe-a79abace039c@github.com> Message-ID: <_PStifoVHZV-wGaQBGatxmFA2EwEA0HQcrVHO8eL9F8=.46ed09a4-0dcf-4eb1-9411-f36d6835ed6f@github.com> On Tue, 15 Dec 2020 14:40:34 GMT, Magnus Ihse Bursie wrote: >> Right now `CompileJavaModules.gmk` contains two different part: one part with the functionality needed to compile a java module, and one part were all special requirements for all modules are listed. >> >> The second part should be removed from `CompileJavaModules.gmk`, and instead listed directly for each individual module in `make/modules/$M/Java.gmk`. >> >> I used a special-written shell script to automatically extract the module-specific part from CompileJavaModules.gmk into the respective Java.gmk files, to avoid risking any hard-to-detect copy/paste errors. After this I did a `sed -i` to remove the module-specific prefix. All this makes me confident that I have correctly moved the variables (I realize this is hard to verify from the patch). > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Final bug fixes... Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1779 From erikj at openjdk.java.net Mon Jan 4 15:18:57 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 4 Jan 2021 15:18:57 GMT Subject: RFR: 8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 13:11:30 GMT, Magnus Ihse Bursie wrote: > Right now `CompileJavaModules.gmk` contains two different part: one part with the functionality needed to compile a java module, and one part were all special requirements for all modules are listed. > > The second part should be removed from `CompileJavaModules.gmk`, and instead listed directly for each individual module in `make/modules/$M/Java.gmk`. > > I used a special-written shell script to automatically extract the module-specific part from CompileJavaModules.gmk into the respective Java.gmk files, to avoid risking any hard-to-detect copy/paste errors. After this I did a `sed -i` to remove the module-specific prefix. All this makes me confident that I have correctly moved the variables (I realize this is hard to verify from the patch). Looks good to me. I assume you have run compare builds on all platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/1779 From erikj at openjdk.java.net Mon Jan 4 15:21:58 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 4 Jan 2021 15:21:58 GMT Subject: RFR: 8258426: Split up autoconf/version-numbers and move it to conf dir [v2] In-Reply-To: <9O1KoB8zL6iGMcMbjmo_wM0bhV1AqNH4tHavRAt3FOQ=.d13a9d3d-e16c-4c2c-a51a-928b0070f064@github.com> References: <9O1KoB8zL6iGMcMbjmo_wM0bhV1AqNH4tHavRAt3FOQ=.d13a9d3d-e16c-4c2c-a51a-928b0070f064@github.com> Message-ID: On Tue, 15 Dec 2020 21:17:14 GMT, Magnus Ihse Bursie wrote: >> The file `make/autoconf/version-numbers` is plagued by a two-fold problem: first of all, it's a configuration file, not a part of autoconf, so it should reside in `make/conf` instead of `make/autoconf`. >> >> Secondly, contrary to the name, it does not only contain version numbers, but also the branding properties (company name, product name, etc). This should be split out into a separate branding configuration file. >> >> This is the last patch in the series of moving configuration into `make/conf`. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update submit.yml Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1786 From erikj at openjdk.java.net Mon Jan 4 15:22:57 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 4 Jan 2021 15:22:57 GMT Subject: RFR: 8258449: Move make/hotspot/symbols to make/data In-Reply-To: <5xNHtr0piHsmCR5c17c1zzwfeAdUK1YxzrrulIXcy5w=.88bfdc68-de83-41c7-9fc6-2e69ded5bfa2@github.com> References: <5xNHtr0piHsmCR5c17c1zzwfeAdUK1YxzrrulIXcy5w=.88bfdc68-de83-41c7-9fc6-2e69ded5bfa2@github.com> Message-ID: On Tue, 15 Dec 2020 23:38:02 GMT, Magnus Ihse Bursie wrote: > The "symbol" files in make/hotspot/symbols are a list of exported symbols from libjvm. As such, they are an essential data source for the build system, and they should reside in make/data, not mixed with the hotspot make source code. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1793 From erikj at openjdk.java.net Mon Jan 4 15:22:58 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 4 Jan 2021 15:22:58 GMT Subject: RFR: 8258445: Move make/templates to make/data In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:15:23 GMT, Magnus Ihse Bursie wrote: > The `templates` directory in `make` is an odd bird. It actually contains data files that the license checker needs, so it should move to `make/data`. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1790 From erikj at openjdk.java.net Mon Jan 4 15:32:11 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 4 Jan 2021 15:32:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [ ] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - Step 2: Update references > - First stage, move actual data files Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From iklam at openjdk.java.net Mon Jan 4 17:43:01 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 4 Jan 2021 17:43:01 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun wrote: > From the error log we can see the root cause is that, develop_pd flag > 'pd_CICompileOSR' is undeclared in zero build. > > Where this flag is used? > Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 > of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. > > Where this flag can be declared? > Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if > VM is built with compiler1 or compiler2. See lines 30 to 38 of > 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get > declared in the header files for specific arch, e.g., > 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. > However, regarding zero build (without compiler1 and compiler2 and > jvmci) , this flag is undelcared. Hence, this patch gets header file > 'compiler/compiler_globals_pd.hpp' included where this flag is declared > for the case when neither COMPILER1 nor COMPILER2 are defined and > INCLUDE_JVMCI is inactive. > > Note that 'compiler/compiler_globals_pd.hpp' already includes > 'runtime/globals_shared.hpp'. > > Note that zero build with PCH succeeds because 'runtime/globals.hpp' is > included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is > included in 'runtime/globals.hpp'. Changes requested by iklam (Reviewer). src/hotspot/share/compiler/compiler_globals.hpp line 29: > 27: > 28: #include "compiler/compiler_globals_pd.hpp" > 29: #ifdef COMPILER1 `#include "runtime/globals_shared.hpp"` should not be removed. compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by globals_shared.hpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From iklam at openjdk.java.net Mon Jan 4 17:43:08 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 4 Jan 2021 17:43:08 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 10:09:23 GMT, Aleksey Shipilev wrote: > It is unclear to me why the original change in JDK-8258074 included `compiler_globals_pd.hpp` in `globals.hpp` at all, @iklam? The reason is, for historical reasons, some PD flags related to the compiler, such as `BackgroundCompilation`, are declared in `globals.hpp`. As a result, `globals.hpp` must include `compiler_globals_pd.hpp`, which provides the platform-specific default value for `BackgroundCompilation`. This should eventually be fixed by moving the declaration of these flags to compiler_globals.hpp instead. > I believe we should additionally change the `#include compiler/compiler_globals_pd.hpp` to `#include compiler/compiler_globals.hpp` in `globals.hpp`? This is not necessary. `globals.hpp` does not use anything declared in `compiler_globals.hpp` ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From kravikumar at openjdk.java.net Mon Jan 4 18:16:07 2021 From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar) Date: Mon, 4 Jan 2021 18:16:07 GMT Subject: RFR: 8258878: (tz) Upgrade time-zone data to tzdata2020e Message-ID: <9Vhqq8tJSSFttfpVHRl2YMj8DHXs8IhYajW61wQbMhs=.a9a11b2e-9b08-474c-a1cb-cbfa34b4c0d2@github.com> Hi Guys, Please review the integration of tzdata2020e to JDK. Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-December/000063.html Bug: https://bugs.openjdk.java.net/browse/JDK-8258878 Most of the changes are about correcting past timestamps and Australia/Currie timezone is removed. Regression Tests pass along with JCK. Please let me know if the changes are good to push. Thanks, Kiran ------------- Commit messages: - 8258878: (tz) Upgrade time-zone data to tzdata2020e Changes: https://git.openjdk.java.net/jdk/pull/1937/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1937&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258878 Stats: 729 lines in 10 files changed: 578 ins; 19 del; 132 mod Patch: https://git.openjdk.java.net/jdk/pull/1937.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1937/head:pull/1937 PR: https://git.openjdk.java.net/jdk/pull/1937 From erik.joelsson at oracle.com Mon Jan 4 18:33:15 2021 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Jan 2021 10:33:15 -0800 Subject: Cross-compilation of OpenJDK Zero with clang In-Reply-To: References: Message-ID: <98c4bf24-7ffb-6071-5b0c-ce8e0045ce56@oracle.com> Hello Andy, Sorry for the late reply, but a lot of us have been on holiday. I recommend starting with the main documentation in the source tree at doc/building.md. I have no personal experience using Clang for cross compilation, but I would imagine it would function similar enough to GCC. To instruct configure to look for Clang instead of GCC, use --with-toolchain-type=clang (also documented in said file). You will also need to use the --with-sysroot option to point to your target sysroot. By default when cross compiling, a "build" jdk will also be built. This is a partial JDK native to the build system, which is used during the build. In many cases it makes more sense to explicitly build this once before trying to cross compile instead of having it weaved into your cross compile build. You can do that by simply building normally for your build platform first, and then point configure for your cross compile configuration to your newly produced native JDK using --with-build-jdk. If you run into specific issues, you can followup with questions here. /Erik On 2020-12-17 08:13, Andy Nisbet wrote: > Hi, > I am in the process of porting OpenJDK to a new architecture, at the > current moment in time we only have clang/LLVM cross compilation tools, and > GCC/binutils is still a year or so away. Could anyone offer any pointers to > documentation/hints, and/or outline what is necessary to get cross > compilation with clang working? I have a sysroot and a bootable diskimage > for the virtual emulated platform. > > Thanks, > Andy From erikj at openjdk.java.net Mon Jan 4 18:45:02 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 4 Jan 2021 18:45:02 GMT Subject: [jdk16] RFR: 8259043: More Zero architectures need linkage with libatomic In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 08:34:02 GMT, Aleksey Shipilev wrote: > JDK-8256831 added the Zero linkage with libatomic for MIPS, but there are other 32-bit Zero platforms that need the same kind of treatment. > > Additional testing: > - [x] linux-mipsel-zero-fastdebug build Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/76 From erikj at openjdk.java.net Mon Jan 4 18:52:58 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 4 Jan 2021 18:52:58 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 09:25:55 GMT, Yasumasa Suenaga wrote: > I got garbled exception message as following when I run `livenmethods` CLHSDB command: > > sun.jvm.hotspot.debugger.DebuggerException : ?w???????W > > My Windows laptop is set Japanese Locale, garbled message was written in Japanese. > saproc.dll would throw exception via [ThrowNew()](https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#thrownew) JNI function, but it accepts UTF-8 encoded message. However [FormatMessage()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage) Windows API might not return UTF-8 encoded string on Japanese locale. > > java.dll (libjava,so) provides good functions to resolve this issue. We can convert localized (non ascii) chars to UTF-8 string. I use them in this PR and remove `FormatMessage()` call from sadis.c. > And also I remove `-D_MBCS` from compiler option because [MBCS has been already deprecated](https://docs.microsoft.com/ja-jp/cpp/text/support-for-multibyte-character-sets-mbcss) - it does not seem to add to any other executables. Build changes look ok to me, but someone from serviceability needs to comment on the actual change. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1928 From erik.joelsson at oracle.com Mon Jan 4 19:03:36 2021 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Jan 2021 11:03:36 -0800 Subject: Build and test problems on Windows with gtest In-Reply-To: References: Message-ID: Hello Matthias, The path configure found to vcruntime140_1.dll certainly looks strange. This is likely a bug in the build system. Normally we would expect to find this file in the redist dir of the Visual Studio installation. Does your community edition not include that file? /Erik On 2020-12-21 02:01, Matthias Perktold - ASA wrote: > I wanted to create a pull request in OpenJDK, but I struggle to make the tests of tier 1 pass before making any changes. > > At some point, I was able to run the tests of tier1, but got some failures (roughly about 60). > > Then I noticed that the document says "Building of Hotspot Gtest suite requires the source code of Google Test framework". > So, I downloaded the source code and reconfigured the Toolchain, adding -with-gtest to the previously used config command, resulting in: > bash configure --with-boot-jdk=/cygdrive/c/jDev/java-x64/jdk-15.0.1+9/ > --with-jtreg=/cygdrive/c/jDev/jtreg/ > --with-gtest=/cygdrive/c/jDev/googletest-release-1.8.1/ > > But now I cannot run the tests anymore. > The test build exits with the message "ERROR: Build failed for target 'run-test-tier1' in configuration 'windows-x86_64-server-release' (exit code 2)". > Further up the logs, I found the following messages: > > Creating support/test/lib-test/jtreg/native/bin/jvm-test-launcher.exe from 1 file(s) > make[3]: *** No rule to make target '/cygdrive/c/jdev/java-x64/jdk-15~2.1_9/bin//cygdrive/c/windows/system32/vcruntime140_1.dll', needed by '/cygdrive/c/users/matthiasp/git/jdk/build/windows-x86_64-server-release/images/test/hotspot/gtest/server/vcruntime140_1.dll'. Stop. > make[3]: *** Waiting for unfinished jobs.... > make[2]: *** [make/Main.gmk:675: test-image-hotspot-gtest] Error 2 > > Notice the double slash in the target path. > Also, it starts with the path to the boot JDK, but then it has "jdk-15~2.19" instead of "jdk-15.0.1+9". > Apparently, the paths got messed up here. > > Do you have any idea what that could be, or what steps can help to solve this? > As you can see, I am on Windows with Cygwin. > Also, I installed Visual Studio 2019 Community Edition, adding "MSVC v142 - VS 2019 C++-ARM-Buildtools (v14.28)" to the core installation. > > Thanks, > Matthias Perktold > From xliu at openjdk.java.net Mon Jan 4 19:36:55 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 4 Jan 2021 19:36:55 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: References: <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com> Message-ID: On Mon, 4 Jan 2021 04:31:02 GMT, Hao Sun wrote: >>> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >>> >>> > On Dec 24, 2020, at 3:44 PM, Xin Liu wrote: >>> > On Thu, 24 Dec 2020 17:27:39 GMT, Kim Barrett wrote: >>> > > [?] >>> > > Since DUIterator_Last is just delegating both the copy constructor and >>> > > assignment operator to the base class, their copy constructor and >>> > > assignment operator would be better as the default (either implicit or >>> > > explicit using `=default`) rather than explicit code. >>> > >>> > >>> > Agree. c2 actually never uses the assignment operator of DUIterator_Last. It needs the copy constructor in this line. >>> > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1499 >>> > you can delete the following code or leave it =default. >>> > - void operator=(const DUIterator_Last& that) >>> > - { DUIterator_Fast::operator=(that); } >>> >>> DUIterator_Last::operator= *is* used, for example: >>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1473 >>> >>> That doesn't change whether defaulting DUIIterator_Last's copy constructor >>> and copy assign works though (whether implicit or explicit). So making it >>> implicit does work. >>> >>> I think making it explicitly defaulted might be better though, to make it >>> clear the default behavior is intentional and it wasn't accidentally left as >>> the implicit default. This is because the default isn't right for the other >>> related classes. >> >> Yes. You're right. It's much better to make it explicitly defaulted. >> May I have your opinion @navyxliu ? > >> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >> >> > On Dec 29, 2020, at 10:33 PM, Hao Sun wrote: >> > > _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >> > > C++17 "guaranteed copy elision" is implemented in gcc7. >> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html >> > >> > >> > Thanks for your comment. >> > Initially we only suspected it might be copy elision that made gcc and clang to behave differently on this warning, and we were not aware of this flag '-fno-elide-constructors'. >> > Thank you for pointing it out. >> > > Using -fno-elide-constructors makes it obvious that the deprecated >> > > implicit copy constructors are indeed being elided, so no deprecation >> > > warning. >> > >> > >> > I suppose you want to express 'Using -**felide-constructors**' here. >> > gcc with '-fno-elide-constructos' would produce derepcated warnings for this issue as clang-10 does. >> >> I really did mean "-fno-elide-constructors". The idea is that having the >> normally working build fail with "-fno-elide-constructors" provides evidence >> for the "working because of copy elision" conjecture. >> >> clang has supported -f[no-]elide-constructors for a while. >> >> It appears that either clang is different from gcc for -felide-constructors >> (which seems unlikely), or clang (clang-10) is doing the deprecation warning >> at a different point from gcc (quite plausible). That is, clang could be >> checking for the deprecated case before eliding the call, while gcc is >> checking for the deprecated case after copy elision has been applied. > > Thanks for your reply. > I checked the source code of clang-10 and gcc-9 and found that: > > 1) for clang-10, > 'Wdeprecated-copy' is implemented at the 'Sema' module of clang. See https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/Sema/SemaDeclCXX.cpp#L13585 > > Flag 'felide-constructors' would enable 'felide_constructors' and flag 'fno-elide-constructors' would enables 'fno_elide_constructors'. (See https://github.com/llvm/llvm-project/blob/release/10.x/clang/include/clang/Driver/Options.td). > Then 'ElideConstructors' will be set (See https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/Frontend/CompilerInvocation.cpp#L2863) > Finally, constructors might be elided in several spots in 'CodeGen' module. > See: > https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/CodeGen/CGStmt.cpp#L1094 > https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/CodeGen/CGExprCXX.cpp#L611 > https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/CodeGen/CGDecl.cpp#L1405 > > As far as I know, 'Sema' module is conducted to check semantics errors before 'CodeGen' module. > That verified your conjecture, i.e. 'clang could be checking for the derepcated case before eliding the call'. > > 2) for gcc-9, > 'felide-constructors' and 'Wdeprecated-copy' are implemented in a number of spots in gcc. I currently didn't figure out their execution order clearly. > > But in one of the use points at function build_over_call(), 'flag_elide_constructors' (See https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/cp/call.c#L8538) is handled **before** 'warn_deprecated_copy' (See https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/cp/call.c#L8608 and https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/cp/call.c#L8679) > > Hope that my finding is helpful. Thanks. > > _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ > > > On Dec 24, 2020, at 3:44 PM, Xin Liu wrote: > > > On Thu, 24 Dec 2020 17:27:39 GMT, Kim Barrett wrote: > > > > [?] > > > > Since DUIterator_Last is just delegating both the copy constructor and > > > > assignment operator to the base class, their copy constructor and > > > > assignment operator would be better as the default (either implicit or > > > > explicit using `=default`) rather than explicit code. > > > > > > > > > Agree. c2 actually never uses the assignment operator of DUIterator_Last. It needs the copy constructor in this line. > > > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1499 > > > you can delete the following code or leave it =default. > > > > > > * void operator=(const DUIterator_Last& that) > > > * { DUIterator_Fast::operator=(that); } > > > > > > DUIterator_Last::operator= _is_ used, for example: > > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1473 > > That doesn't change whether defaulting DUIIterator_Last's copy constructor > > and copy assign works though (whether implicit or explicit). So making it > > implicit does work. > > I think making it explicitly defaulted might be better though, to make it > > clear the default behavior is intentional and it wasn't accidentally left as > > the implicit default. This is because the default isn't right for the other > > related classes. > > Yes. You're right. It's much better to make it explicitly defaulted. > May I have your opinion @navyxliu ? Sorry, I overlooked that copy assignment case. Making it explicitly default is better to me too. no objection! ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From cjplummer at openjdk.java.net Mon Jan 4 21:09:04 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 4 Jan 2021 21:09:04 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 09:25:55 GMT, Yasumasa Suenaga wrote: > I got garbled exception message as following when I run `livenmethods` CLHSDB command: > > sun.jvm.hotspot.debugger.DebuggerException : ?w???????W > > My Windows laptop is set Japanese Locale, garbled message was written in Japanese. > saproc.dll would throw exception via [ThrowNew()](https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#thrownew) JNI function, but it accepts UTF-8 encoded message. However [FormatMessage()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage) Windows API might not return UTF-8 encoded string on Japanese locale. > > java.dll (libjava,so) provides good functions to resolve this issue. We can convert localized (non ascii) chars to UTF-8 string. I use them in this PR and remove `FormatMessage()` call from sadis.c. > And also I remove `-D_MBCS` from compiler option because [MBCS has been already deprecated](https://docs.microsoft.com/ja-jp/cpp/text/support-for-multibyte-character-sets-mbcss) - it does not seem to add to any other executables. There are probably 25 or so places in our code where we use FormatMessage to get the error message. Are these all going to run into the same FormateMessage bug? Also, it's not clear to me why you are getting garbled text in the first place. You said "Windows API might not return UTF-8 encoded string on Japanese locale." Why is that the case? src/jdk.hotspot.agent/share/native/libsaproc/sadis.c line 75: > 73: > 74: #ifdef _WINDOWS > 75: static int getLastErrorString(char *buf, size_t len) Is this being removed because a copy already exists in jni_util_md.c, and you now have access to this copy because you are linking against java.dll? ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From prr at openjdk.java.net Mon Jan 4 21:24:14 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 4 Jan 2021 21:24:14 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [ ] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - Step 2: Update references > - First stage, move actual data files Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From jiefu at openjdk.java.net Mon Jan 4 23:41:54 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 4 Jan 2021 23:41:54 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 17:19:44 GMT, Ioi Lam wrote: > `#include "runtime/globals_shared.hpp"` should not be removed. compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by globals_shared.hpp. Since globals_shared.hpp is included in compiler_globals_pd.hpp, I think it's fine to remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From iklam at openjdk.java.net Tue Jan 5 00:15:57 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 00:15:57 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 23:39:18 GMT, Jie Fu wrote: >> src/hotspot/share/compiler/compiler_globals.hpp line 29: >> >>> 27: >>> 28: #include "compiler/compiler_globals_pd.hpp" >>> 29: #ifdef COMPILER1 >> >> `#include "runtime/globals_shared.hpp"` should not be removed. compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by globals_shared.hpp. > >> `#include "runtime/globals_shared.hpp"` should not be removed. compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by globals_shared.hpp. > > Since globals_shared.hpp is included in compiler_globals_pd.hpp, I think it's fine to remove it. We should not rely on indirect inclusion. Otherwise, compiler_globals.hpp will break if compiler_globals_pd.hpp is changed to not include globals_shared.hpp. In fact, I have been fixing a lot of such problems when restructuring the header files. See https://github.com/openjdk/jdk/pull/1610 -- the vast majority of the 59 files changed in that PR were caused by relying on indirect inclusion of stubRoutines.hpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From ysuenaga at openjdk.java.net Tue Jan 5 00:32:02 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 5 Jan 2021 00:32:02 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 20:58:59 GMT, Chris Plummer wrote: >> I got garbled exception message as following when I run `livenmethods` CLHSDB command: >> >> sun.jvm.hotspot.debugger.DebuggerException : ?w???????W >> >> My Windows laptop is set Japanese Locale, garbled message was written in Japanese. >> saproc.dll would throw exception via [ThrowNew()](https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#thrownew) JNI function, but it accepts UTF-8 encoded message. However [FormatMessage()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage) Windows API might not return UTF-8 encoded string on Japanese locale. >> >> java.dll (libjava,so) provides good functions to resolve this issue. We can convert localized (non ascii) chars to UTF-8 string. I use them in this PR and remove `FormatMessage()` call from sadis.c. >> And also I remove `-D_MBCS` from compiler option because [MBCS has been already deprecated](https://docs.microsoft.com/ja-jp/cpp/text/support-for-multibyte-character-sets-mbcss) - it does not seem to add to any other executables. > > src/jdk.hotspot.agent/share/native/libsaproc/sadis.c line 75: > >> 73: >> 74: #ifdef _WINDOWS >> 75: static int getLastErrorString(char *buf, size_t len) > > Is this being removed because a copy already exists in jni_util_md.c, and you now have access to this copy because you are linking against java.dll? Exactly. ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From ysuenaga at openjdk.java.net Tue Jan 5 00:43:56 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 5 Jan 2021 00:43:56 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: Message-ID: <68bajRcB_ufJ_pJevEYP46te1ZaRtGpfPLXCgv2b3gU=.e21270a1-6500-4e0a-90a5-aac232ca1930@github.com> On Mon, 4 Jan 2021 21:06:46 GMT, Chris Plummer wrote: > There are probably 25 or so places in our code where we use FormatMessage to get the error message. Are these all going to run into the same FormateMessage bug? jdk.hotspot.agent do not have `FormatMessage()` call in other place. Did you say about whole JDK code? I haven't checked all of them, but some code (e.g. net_util_md.c) uses `JNU_ThrowByName()` which is provided by java.dll. > Also, it's not clear to me why you are getting garbled text in the first place. You said "Windows API might not return UTF-8 encoded string on Japanese locale." Why is that the case? Japanese locale on Windows uses CP932., so `FormatMessage()` would return error message with Japanese chars which are encoded by CP932. It is not UTF-8. ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From cjplummer at openjdk.java.net Tue Jan 5 01:33:56 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 5 Jan 2021 01:33:56 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: <68bajRcB_ufJ_pJevEYP46te1ZaRtGpfPLXCgv2b3gU=.e21270a1-6500-4e0a-90a5-aac232ca1930@github.com> References: <68bajRcB_ufJ_pJevEYP46te1ZaRtGpfPLXCgv2b3gU=.e21270a1-6500-4e0a-90a5-aac232ca1930@github.com> Message-ID: On Tue, 5 Jan 2021 00:41:11 GMT, Yasumasa Suenaga wrote: > jdk.hotspot.agent do not have `FormatMessage()` call in other place. > Did you say about whole JDK code? I haven't checked all of them, but some code (e.g. net_util_md.c) uses `JNU_ThrowByName()` which is provided by java.dll. Yes, I was referring to all JDK code. Given how many references there are to FormatMessage(), I'm surprised this issue has not turned up before. I was wondering if there is something unique about the SA reference that makes the issue only turn up there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From iklam at openjdk.java.net Tue Jan 5 01:33:55 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 01:33:55 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: <68bajRcB_ufJ_pJevEYP46te1ZaRtGpfPLXCgv2b3gU=.e21270a1-6500-4e0a-90a5-aac232ca1930@github.com> References: <68bajRcB_ufJ_pJevEYP46te1ZaRtGpfPLXCgv2b3gU=.e21270a1-6500-4e0a-90a5-aac232ca1930@github.com> Message-ID: On Tue, 5 Jan 2021 00:41:11 GMT, Yasumasa Suenaga wrote: >> There are probably 25 or so places in our code where we use FormatMessage to get the error message. Are these all going to run into the same FormateMessage bug? >> >> Also, it's not clear to me why you are getting garbled text in the first place. You said "Windows API might not return UTF-8 encoded string on Japanese locale." Why is that the case? > >> There are probably 25 or so places in our code where we use FormatMessage to get the error message. Are these all going to run into the same FormateMessage bug? > > jdk.hotspot.agent do not have `FormatMessage()` call in other place. > Did you say about whole JDK code? I haven't checked all of them, but some code (e.g. net_util_md.c) uses `JNU_ThrowByName()` which is provided by java.dll. > >> Also, it's not clear to me why you are getting garbled text in the first place. You said "Windows API might not return UTF-8 encoded string on Japanese locale." Why is that the case? > > Japanese locale on Windows uses CP932., so `FormatMessage()` would return error message with Japanese chars which are encoded by CP932. It is not UTF-8. Now the saproc DLL has an external reference to getLastErrorString, JNU_NewStringPlatform and JNU_NewObjectByName on all platforms. Do we need to modify the makefiles for platforms other than Windows? ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From ysuenaga at openjdk.java.net Tue Jan 5 01:41:58 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 5 Jan 2021 01:41:58 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: <68bajRcB_ufJ_pJevEYP46te1ZaRtGpfPLXCgv2b3gU=.e21270a1-6500-4e0a-90a5-aac232ca1930@github.com> Message-ID: <7zXZeRMg4Wa5_RynsE9VcFKR8Nv4D7tUjFXbsE7hr3I=.b77992e0-46c4-4f4d-8a55-5d6e8ec1b84e@github.com> On Tue, 5 Jan 2021 01:30:07 GMT, Ioi Lam wrote: > Now the saproc DLL has an external reference to getLastErrorString, JNU_NewStringPlatform and JNU_NewObjectByName on all platforms. Do we need to modify the makefiles for platforms other than Windows? @iklam Agree, so I added `LIBS_unix := -ljava` to make/modules/jdk.hotspot.agent/Lib.gmk in this change. It works fine on Windows x64 and Linux x64. ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From iklam at openjdk.java.net Tue Jan 5 02:21:55 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 02:21:55 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 09:25:55 GMT, Yasumasa Suenaga wrote: > I got garbled exception message as following when I run `livenmethods` CLHSDB command: > > sun.jvm.hotspot.debugger.DebuggerException : ?w???????W > > My Windows laptop is set Japanese Locale, garbled message was written in Japanese. > saproc.dll would throw exception via [ThrowNew()](https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#thrownew) JNI function, but it accepts UTF-8 encoded message. However [FormatMessage()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage) Windows API might not return UTF-8 encoded string on Japanese locale. > > java.dll (libjava,so) provides good functions to resolve this issue. We can convert localized (non ascii) chars to UTF-8 string. I use them in this PR and remove `FormatMessage()` call from sadis.c. > And also I remove `-D_MBCS` from compiler option because [MBCS has been already deprecated](https://docs.microsoft.com/ja-jp/cpp/text/support-for-multibyte-character-sets-mbcss) - it does not seem to add to any other executables. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From iklam at openjdk.java.net Tue Jan 5 02:21:56 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 02:21:56 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: <68bajRcB_ufJ_pJevEYP46te1ZaRtGpfPLXCgv2b3gU=.e21270a1-6500-4e0a-90a5-aac232ca1930@github.com> Message-ID: <_Za4TlASBBlsXCpIhOdBHiySzVma7ncBk9BcPFWvFmo=.c74f27fd-ff78-42b7-a796-edb75c9711de@github.com> On Tue, 5 Jan 2021 01:31:28 GMT, Chris Plummer wrote: > > jdk.hotspot.agent do not have `FormatMessage()` call in other place. > > Did you say about whole JDK code? I haven't checked all of them, but some code (e.g. net_util_md.c) uses `JNU_ThrowByName()` which is provided by java.dll. > > Yes, I was referring to all JDK code. Given how many references there are to FormatMessage(), I'm surprised this issue has not turned up before. I was wondering if there is something unique about the SA reference that makes the issue only turn up there. I looked at a cases in the JDK code where `Java_sun_security_pkcs11_wrapper_PKCS11_connect()` calls `FormatMessage()`. It eventually passes the `char*` to `jni_ThrowNew`, which eventually gets to `Exceptions::new_exception` with `to_utf8_safe==safe_to_utf8`. This means the message will be converted with `java_lang_String::create_from_str()`, which does NOT call `JNU_NewStringPlatform`. So I think in this case, the error message will also be garbled. java.base/windows/native/libnet/Inet4AddressImpl.c seems to have a similar problem in the `ping4` function. But, I don't know how to write a simple test case for the above. ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From ysuenaga at openjdk.java.net Tue Jan 5 02:42:58 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 5 Jan 2021 02:42:58 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 02:19:37 GMT, Ioi Lam wrote: >> I got garbled exception message as following when I run `livenmethods` CLHSDB command: >> >> sun.jvm.hotspot.debugger.DebuggerException : ?w???????W >> >> My Windows laptop is set Japanese Locale, garbled message was written in Japanese. >> saproc.dll would throw exception via [ThrowNew()](https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#thrownew) JNI function, but it accepts UTF-8 encoded message. However [FormatMessage()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage) Windows API might not return UTF-8 encoded string on Japanese locale. >> >> java.dll (libjava,so) provides good functions to resolve this issue. We can convert localized (non ascii) chars to UTF-8 string. I use them in this PR and remove `FormatMessage()` call from sadis.c. >> And also I remove `-D_MBCS` from compiler option because [MBCS has been already deprecated](https://docs.microsoft.com/ja-jp/cpp/text/support-for-multibyte-character-sets-mbcss) - it does not seem to add to any other executables. > > Marked as reviewed by iklam (Reviewer). @iklam Thanks for your review! > I looked at a cases in the JDK code where `Java_sun_security_pkcs11_wrapper_PKCS11_connect()` calls `FormatMessage()`. It eventually passes the `char*` to `jni_ThrowNew`, which eventually gets to `Exceptions::new_exception` with `to_utf8_safe==safe_to_utf8`. This means the message will be converted with `java_lang_String::create_from_str()`, which does NOT call `JNU_NewStringPlatform`. So I think in this case, the error message will also be garbled. > > java.base/windows/native/libnet/Inet4AddressImpl.c seems to have a similar problem in the `ping4` function. Agree. `ping4()` calls `NET_ThrowNew()` which passes `ThrowNew()` JNI function without modifying arguments. I looked at other cases in JDK code, following places has possible to garble: * `throwByName()` @ jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c * `Java_sun_security_pkcs11_Secmod_nssLoadLibrary()` @ j2secmod_md.c * jdk.jdi/share/native/libdt_shmem/SharedMemoryTransport.c * `throwShmemException()` @ SharedMemoryTransport.c > But, I don't know how to write a simple test case for the above. Agree, we might need to fix garbled messages one by one when we find out issues. IMHO we need to establish rule that we have to use `JNU_NewStringPlatform()` if we want to throw exception with message from platform (`FormatMessage()`, `strerror()`) from JNI. ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From cjplummer at openjdk.java.net Tue Jan 5 03:11:00 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 5 Jan 2021 03:11:00 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 02:40:29 GMT, Yasumasa Suenaga wrote: >> Marked as reviewed by iklam (Reviewer). > > @iklam Thanks for your review! > >> I looked at a cases in the JDK code where `Java_sun_security_pkcs11_wrapper_PKCS11_connect()` calls `FormatMessage()`. It eventually passes the `char*` to `jni_ThrowNew`, which eventually gets to `Exceptions::new_exception` with `to_utf8_safe==safe_to_utf8`. This means the message will be converted with `java_lang_String::create_from_str()`, which does NOT call `JNU_NewStringPlatform`. So I think in this case, the error message will also be garbled. >> >> java.base/windows/native/libnet/Inet4AddressImpl.c seems to have a similar problem in the `ping4` function. > > Agree. `ping4()` calls `NET_ThrowNew()` which passes `ThrowNew()` JNI function without modifying arguments. > I looked at other cases in JDK code, following places has possible to garble: > > * `throwByName()` @ jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c > * `Java_sun_security_pkcs11_Secmod_nssLoadLibrary()` @ j2secmod_md.c > * jdk.jdi/share/native/libdt_shmem/SharedMemoryTransport.c > * `throwShmemException()` @ SharedMemoryTransport.c > >> But, I don't know how to write a simple test case for the above. > > Agree, we might need to fix garbled messages one by one when we find out issues. > IMHO we need to establish rule that we have to use `JNU_NewStringPlatform()` if we want to throw exception with message from platform (`FormatMessage()`, `strerror()`) from JNI. Given that this seems to be a common problem in our code, and likely a very very old problem at that, why has it never been reported before? I'm not questioning the fix except to the extent that I'm questioning our understanding of the problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From iklam at openjdk.java.net Tue Jan 5 03:22:56 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 03:22:56 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 03:07:49 GMT, Chris Plummer wrote: > Given that this seems to be a common problem in our code, and likely a very very old problem at that, why has it never been reported before? I'm not questioning the fix except to the extent that I'm questioning our understanding of the problem. I think it's probably because the errors only happen in very rare cases. For example, when a DLL is missing from the JAVA_HOME. For more common cases, such as Process_impl.c, the code has been rewritten to use FormatMessageW, which is unicode. ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 03:44:10 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 03:44:10 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v3] In-Reply-To: References: Message-ID: > 1. '-Wdeprecated-copy' > As specified in C++11 [1], "the generation of the implicitly-defined > copy constructor is deprecated if T has a user-defined destructor or > user-defined copy assignment operator". The rationale behind is the > well-known Rule of Three [2]. > > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' > warns about the C++11 deprecation of implicitly declared copy > constructor and assignment operator if one of them is user-provided. > Defining an explicit copy constructor would suppress this warning. > > The main reason why debug build with gcc-9 or higher succeeds lies in > the inconsistent warning behaviors between gcc and clang. See the > reduced code example [5]. We suspect it might be return value > optimization/copy elision [6] that drives gcc not to declare implicit > copy constructor for this case. > > Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise > warnings for deprecated defintions of copy constructors. However, > '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 > and clang-9 are not affected. > > 2. '-Wimplicit-int-float-conversion' > Making the conversion explicit would fix it. > > Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. > Therefore clang-8 and clang-9 are not affected. The flag with similar > functionality in gcc is '-Wfloat-conversion', but it is not enabled by > '-Wall' or '-Wextra'. That's why this warning does not apprear when > building with gcc. > > [1] https://en.cppreference.com/w/cpp/language/copy_constructor > [2] https://en.cppreference.com/w/cpp/language/rule_of_three > [3] https://www.gnu.org/software/gcc/gcc-9/changes.html > [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html > [5] https://godbolt.org/z/err4jM > [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization > > > Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines. Hao Sun has updated the pull request incrementally with one additional commit since the last revision: Update the copy constructors for class DUIterator, DUIterator_Fast and DUIterator_Last 1. Update copyright year to 2021. 2. Add the definition of copy constructor for class DUIterator. Otherwise, gcc with '-fno-elide-constructors' would raise a warning. 3. For the copy constructor of class DUIterator_Fast, we initialize '_vdui' as false, otherwise UB is introduced. 4. It's better to define the copy constructor of class DUIterator_Last as explicitly-defaulted, instead of leaving it for compilers to implicitly define. Change-Id: I3d2f5b396aa116d1832f52da361ff3172459a87e CustomizedGitHooks: yes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1874/files - new: https://git.openjdk.java.net/jdk/pull/1874/files/68679966..d0f5d7d5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1874&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1874&range=01-02 Stats: 11 lines in 2 files changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1874/head:pull/1874 PR: https://git.openjdk.java.net/jdk/pull/1874 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 03:51:55 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 03:51:55 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: References: <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com> Message-ID: On Mon, 4 Jan 2021 19:33:45 GMT, Xin Liu wrote: >>> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >>> >>> > On Dec 29, 2020, at 10:33 PM, Hao Sun wrote: >>> > > _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >>> > > C++17 "guaranteed copy elision" is implemented in gcc7. >>> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html >>> > >>> > >>> > Thanks for your comment. >>> > Initially we only suspected it might be copy elision that made gcc and clang to behave differently on this warning, and we were not aware of this flag '-fno-elide-constructors'. >>> > Thank you for pointing it out. >>> > > Using -fno-elide-constructors makes it obvious that the deprecated >>> > > implicit copy constructors are indeed being elided, so no deprecation >>> > > warning. >>> > >>> > >>> > I suppose you want to express 'Using -**felide-constructors**' here. >>> > gcc with '-fno-elide-constructos' would produce derepcated warnings for this issue as clang-10 does. >>> >>> I really did mean "-fno-elide-constructors". The idea is that having the >>> normally working build fail with "-fno-elide-constructors" provides evidence >>> for the "working because of copy elision" conjecture. >>> >>> clang has supported -f[no-]elide-constructors for a while. >>> >>> It appears that either clang is different from gcc for -felide-constructors >>> (which seems unlikely), or clang (clang-10) is doing the deprecation warning >>> at a different point from gcc (quite plausible). That is, clang could be >>> checking for the deprecated case before eliding the call, while gcc is >>> checking for the deprecated case after copy elision has been applied. >> >> Thanks for your reply. >> I checked the source code of clang-10 and gcc-9 and found that: >> >> 1) for clang-10, >> 'Wdeprecated-copy' is implemented at the 'Sema' module of clang. See https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/Sema/SemaDeclCXX.cpp#L13585 >> >> Flag 'felide-constructors' would enable 'felide_constructors' and flag 'fno-elide-constructors' would enables 'fno_elide_constructors'. (See https://github.com/llvm/llvm-project/blob/release/10.x/clang/include/clang/Driver/Options.td). >> Then 'ElideConstructors' will be set (See https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/Frontend/CompilerInvocation.cpp#L2863) >> Finally, constructors might be elided in several spots in 'CodeGen' module. >> See: >> https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/CodeGen/CGStmt.cpp#L1094 >> https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/CodeGen/CGExprCXX.cpp#L611 >> https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/CodeGen/CGDecl.cpp#L1405 >> >> As far as I know, 'Sema' module is conducted to check semantics errors before 'CodeGen' module. >> That verified your conjecture, i.e. 'clang could be checking for the derepcated case before eliding the call'. >> >> 2) for gcc-9, >> 'felide-constructors' and 'Wdeprecated-copy' are implemented in a number of spots in gcc. I currently didn't figure out their execution order clearly. >> >> But in one of the use points at function build_over_call(), 'flag_elide_constructors' (See https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/cp/call.c#L8538) is handled **before** 'warn_deprecated_copy' (See https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/cp/call.c#L8608 and https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/cp/call.c#L8679) >> >> Hope that my finding is helpful. Thanks. > >> > _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >> > > On Dec 24, 2020, at 3:44 PM, Xin Liu wrote: >> > > On Thu, 24 Dec 2020 17:27:39 GMT, Kim Barrett wrote: >> > > > [?] >> > > > Since DUIterator_Last is just delegating both the copy constructor and >> > > > assignment operator to the base class, their copy constructor and >> > > > assignment operator would be better as the default (either implicit or >> > > > explicit using `=default`) rather than explicit code. >> > > >> > > >> > > Agree. c2 actually never uses the assignment operator of DUIterator_Last. It needs the copy constructor in this line. >> > > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1499 >> > > you can delete the following code or leave it =default. >> > > >> > > * void operator=(const DUIterator_Last& that) >> > > * { DUIterator_Fast::operator=(that); } >> > >> > >> > DUIterator_Last::operator= _is_ used, for example: >> > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1473 >> > That doesn't change whether defaulting DUIIterator_Last's copy constructor >> > and copy assign works though (whether implicit or explicit). So making it >> > implicit does work. >> > I think making it explicitly defaulted might be better though, to make it >> > clear the default behavior is intentional and it wasn't accidentally left as >> > the implicit default. This is because the default isn't right for the other >> > related classes. >> >> Yes. You're right. It's much better to make it explicitly defaulted. >> May I have your opinion @navyxliu ? > Sorry, I overlooked that copy assignment case. > Making it explicitly default is better to me too. no objection! Thanks for your comments. @kimbarrett and @navyxliu I updated the patch based on my understanding. Please check the latest commit. As @kimbarrett mentioned, I suppose there still exist the following problems to be address. 1) why clang-10 with '-Wdeprecated-copy' does NOT raise warning for class DUIterator. It's weird. 2) the assert failure when building with gcc '-fno-elide-constructors'. Might not be related to our patch. 3) the implementation of 'operator=' for class DUIterator_Fast might be problematic. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From ysuenaga at openjdk.java.net Tue Jan 5 04:20:57 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 5 Jan 2021 04:20:57 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 03:19:51 GMT, Ioi Lam wrote: > > Given that this seems to be a common problem in our code, and likely a very very old problem at that, why has it never been reported before? I'm not questioning the fix except to the extent that I'm questioning our understanding of the problem. > > I think it's probably because the errors only happen in very rare cases. For example, when a DLL is missing from the JAVA_HOME. For more common cases, such as Process_impl.c, the code has been rewritten to use FormatMessageW, which is unicode. In addition, this problem can be seen on non-ASCII locales such as CJK, so I guess many people overlooked it. And also I think it is not just a problem on Windows because some older Linux machines on Japan set locale to EUC JP. In case of ProcessImpl_md.c which @iklam pointed, result of `FormatMessageW()` which is encoded WideString (UTF-16) will be converted to UTF-8 with `WideCharToMultiByte()` at `win32Error()`, so it should work fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 04:56:56 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 04:56:56 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: <7HjOk0EQl7wbAMcB-YPrZL_MzPxuexKLtWm9uxi6JFg=.cb37f275-30d7-4b82-8bcb-ea772202d967@github.com> On Mon, 4 Jan 2021 17:19:48 GMT, Ioi Lam wrote: >> From the error log we can see the root cause is that, develop_pd flag >> 'pd_CICompileOSR' is undeclared in zero build. >> >> Where this flag is used? >> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 >> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. >> >> Where this flag can be declared? >> Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if >> VM is built with compiler1 or compiler2. See lines 30 to 38 of >> 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get >> declared in the header files for specific arch, e.g., >> 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. >> However, regarding zero build (without compiler1 and compiler2 and >> jvmci) , this flag is undelcared. Hence, this patch gets header file >> 'compiler/compiler_globals_pd.hpp' included where this flag is declared >> for the case when neither COMPILER1 nor COMPILER2 are defined and >> INCLUDE_JVMCI is inactive. >> >> Note that 'compiler/compiler_globals_pd.hpp' already includes >> 'runtime/globals_shared.hpp'. >> >> Note that zero build with PCH succeeds because 'runtime/globals.hpp' is >> included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is >> included in 'runtime/globals.hpp'. > > Changes requested by iklam (Reviewer). > It is unclear to me why the original change in JDK-8258074 included `compiler_globals_pd.hpp` in `globals.hpp` at all, @iklam? It seems what @shqking proposes is sound. > > I believe we should additionally change the `#include compiler/compiler_globals_pd.hpp` to `#include compiler/compiler_globals.hpp` in `globals.hpp`? > > @shqking, please go to https://github.com/shqking/jdk/actions -- and enable GH Actions, then trigger the workflow manually on your branch to get this tested. Thanks for your comment. @shipilev The tests were finished but one of them failed. I found that this failure existed for several days and I suppose it's not related to our patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From shade at openjdk.java.net Tue Jan 5 08:29:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 08:29:00 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: <07IGEyNdiB87CZXchlzhoXiv0m36gM8yc7cehVHW2t0=.41b95205-bbba-4e6f-979b-eb07fb8dfdec@github.com> On Tue, 5 Jan 2021 00:12:58 GMT, Ioi Lam wrote: >>> `#include "runtime/globals_shared.hpp"` should not be removed. compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by globals_shared.hpp. >> >> Since globals_shared.hpp is included in compiler_globals_pd.hpp, I think it's fine to remove it. > > We should not rely on indirect inclusion. Otherwise, compiler_globals.hpp will break if compiler_globals_pd.hpp is changed to not include globals_shared.hpp. > > In fact, I have been fixing a lot of such problems when restructuring the header files. See https://github.com/openjdk/jdk/pull/1610 -- the vast majority of the 59 files changed in that PR were caused by relying on indirect inclusion of stubRoutines.hpp. Yes, if something is using the definitions from the header, that header should be included directly. So, the patch is just adding the `#include "compiler/compiler_globals_pd.hpp"` then, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From shade at openjdk.java.net Tue Jan 5 08:28:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 08:28:58 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: <7HjOk0EQl7wbAMcB-YPrZL_MzPxuexKLtWm9uxi6JFg=.cb37f275-30d7-4b82-8bcb-ea772202d967@github.com> References: <7HjOk0EQl7wbAMcB-YPrZL_MzPxuexKLtWm9uxi6JFg=.cb37f275-30d7-4b82-8bcb-ea772202d967@github.com> Message-ID: <1wQ-ufsSql4wIrUZSBnIwKQfyFYtoo3cKc8zHDEy7eo=.962cab85-5a7b-40ce-8e47-e730a679e2c9@github.com> On Tue, 5 Jan 2021 04:54:32 GMT, Hao Sun wrote: > The tests were finished but one of them failed. I found that this failure existed for several days (in other PRs) and I suppose it's not related to our patch. Yes, the failure you caught does not look related to this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From jiefu at openjdk.java.net Tue Jan 5 12:06:19 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 5 Jan 2021 12:06:19 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 12:03:39 GMT, Hao Sun wrote: >> From the error log we can see the root cause is that, develop_pd flag >> 'pd_CICompileOSR' is undeclared in zero build. >> >> Where this flag is used? >> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 >> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. >> >> Where this flag can be declared? >> Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if >> VM is built with compiler1 or compiler2. See lines 30 to 38 of >> 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get >> declared in the header files for specific arch, e.g., >> 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. >> However, regarding zero build (without compiler1 and compiler2 and >> jvmci) , this flag is undelcared. Hence, this patch gets header file >> 'compiler/compiler_globals_pd.hpp' included where this flag is declared >> for the case when neither COMPILER1 nor COMPILER2 are defined and >> INCLUDE_JVMCI is inactive. >> >> Note that 'compiler/compiler_globals_pd.hpp' already includes >> 'runtime/globals_shared.hpp'. >> >> Note that zero build with PCH succeeds because 'runtime/globals.hpp' is >> included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is >> included in 'runtime/globals.hpp'. > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Header 'runtime/globals_shared.hpp' should be kept > > Header 'runtime/globals_shared.hpp' is kept even though > 'compiler/compiler_globals_pd.hpp' already includes it, because > 'compiler_globals.hpp' uses the DECLARE_FLAGS macro, which is defined by > 'runtime/globals_shared.hpp', and it should be included directly. > > Besides, update the copyright year to 2021. > > Change-Id: Ia355f3b6e98b495dc265093e71b2d1fec1ca45ca > CustomizedGitHooks: yes Marked as reviewed by jiefu (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 12:06:18 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 12:06:18 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: > From the error log we can see the root cause is that, develop_pd flag > 'pd_CICompileOSR' is undeclared in zero build. > > Where this flag is used? > Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 > of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. > > Where this flag can be declared? > Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if > VM is built with compiler1 or compiler2. See lines 30 to 38 of > 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get > declared in the header files for specific arch, e.g., > 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. > However, regarding zero build (without compiler1 and compiler2 and > jvmci) , this flag is undelcared. Hence, this patch gets header file > 'compiler/compiler_globals_pd.hpp' included where this flag is declared > for the case when neither COMPILER1 nor COMPILER2 are defined and > INCLUDE_JVMCI is inactive. > > Note that 'compiler/compiler_globals_pd.hpp' already includes > 'runtime/globals_shared.hpp'. > > Note that zero build with PCH succeeds because 'runtime/globals.hpp' is > included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is > included in 'runtime/globals.hpp'. Hao Sun has updated the pull request incrementally with one additional commit since the last revision: Header 'runtime/globals_shared.hpp' should be kept Header 'runtime/globals_shared.hpp' is kept even though 'compiler/compiler_globals_pd.hpp' already includes it, because 'compiler_globals.hpp' uses the DECLARE_FLAGS macro, which is defined by 'runtime/globals_shared.hpp', and it should be included directly. Besides, update the copyright year to 2021. Change-Id: Ia355f3b6e98b495dc265093e71b2d1fec1ca45ca CustomizedGitHooks: yes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1894/files - new: https://git.openjdk.java.net/jdk/pull/1894/files/0cc564bd..f3cd5181 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1894&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1894&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1894.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1894/head:pull/1894 PR: https://git.openjdk.java.net/jdk/pull/1894 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 12:09:56 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 12:09:56 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 00:12:58 GMT, Ioi Lam wrote: >>> `#include "runtime/globals_shared.hpp"` should not be removed. compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by globals_shared.hpp. >> >> Since globals_shared.hpp is included in compiler_globals_pd.hpp, I think it's fine to remove it. > > We should not rely on indirect inclusion. Otherwise, compiler_globals.hpp will break if compiler_globals_pd.hpp is changed to not include globals_shared.hpp. > > In fact, I have been fixing a lot of such problems when restructuring the header files. See https://github.com/openjdk/jdk/pull/1610 -- the vast majority of the 59 files changed in that PR were caused by relying on indirect inclusion of stubRoutines.hpp. Patch is updated: 1) keeping `runtime/globals_shared.hpp' included directly and 2) updating the copyright year to 2021. Could you please help to review it? @iklam @shipilev Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From iklam at openjdk.java.net Tue Jan 5 12:17:02 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 12:17:02 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun wrote: >> From the error log we can see the root cause is that, develop_pd flag >> 'pd_CICompileOSR' is undeclared in zero build. >> >> Where this flag is used? >> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 >> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. >> >> Where this flag can be declared? >> Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if >> VM is built with compiler1 or compiler2. See lines 30 to 38 of >> 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get >> declared in the header files for specific arch, e.g., >> 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. >> However, regarding zero build (without compiler1 and compiler2 and >> jvmci) , this flag is undelcared. Hence, this patch gets header file >> 'compiler/compiler_globals_pd.hpp' included where this flag is declared >> for the case when neither COMPILER1 nor COMPILER2 are defined and >> INCLUDE_JVMCI is inactive. >> >> Note that 'compiler/compiler_globals_pd.hpp' already includes >> 'runtime/globals_shared.hpp'. >> >> Note that zero build with PCH succeeds because 'runtime/globals.hpp' is >> included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is >> included in 'runtime/globals.hpp'. > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Header 'runtime/globals_shared.hpp' should be kept > > Header 'runtime/globals_shared.hpp' is kept even though > 'compiler/compiler_globals_pd.hpp' already includes it, because > 'compiler_globals.hpp' uses the DECLARE_FLAGS macro, which is defined by > 'runtime/globals_shared.hpp', and it should be included directly. > > Besides, update the copyright year to 2021. > > Change-Id: Ia355f3b6e98b495dc265093e71b2d1fec1ca45ca > CustomizedGitHooks: yes LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1894 From shade at openjdk.java.net Tue Jan 5 12:17:01 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 12:17:01 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun wrote: >> From the error log we can see the root cause is that, develop_pd flag >> 'pd_CICompileOSR' is undeclared in zero build. >> >> Where this flag is used? >> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 >> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. >> >> Where this flag can be declared? >> Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if >> VM is built with compiler1 or compiler2. See lines 30 to 38 of >> 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get >> declared in the header files for specific arch, e.g., >> 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. >> However, regarding zero build (without compiler1 and compiler2 and >> jvmci) , this flag is undelcared. Hence, this patch gets header file >> 'compiler/compiler_globals_pd.hpp' included where this flag is declared >> for the case when neither COMPILER1 nor COMPILER2 are defined and >> INCLUDE_JVMCI is inactive. >> >> Note that 'compiler/compiler_globals_pd.hpp' already includes >> 'runtime/globals_shared.hpp'. >> >> Note that zero build with PCH succeeds because 'runtime/globals.hpp' is >> included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is >> included in 'runtime/globals.hpp'. > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Header 'runtime/globals_shared.hpp' should be kept > > Header 'runtime/globals_shared.hpp' is kept even though > 'compiler/compiler_globals_pd.hpp' already includes it, because > 'compiler_globals.hpp' uses the DECLARE_FLAGS macro, which is defined by > 'runtime/globals_shared.hpp', and it should be included directly. > > Besides, update the copyright year to 2021. > > Change-Id: Ia355f3b6e98b495dc265093e71b2d1fec1ca45ca > CustomizedGitHooks: yes This looks fine to me, but @iklam should approve. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From shade at openjdk.java.net Tue Jan 5 12:19:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 12:19:57 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: <4rHg312dxhxqEjOcUre5nFomMw6LKC_5IzXJCa6rTYM=.6f73c059-dc04-4b31-98f7-6e2b102db4bf@github.com> On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun wrote: >> From the error log we can see the root cause is that, develop_pd flag >> 'pd_CICompileOSR' is undeclared in zero build. >> >> Where this flag is used? >> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 >> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. >> >> Where this flag can be declared? >> Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if >> VM is built with compiler1 or compiler2. See lines 30 to 38 of >> 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get >> declared in the header files for specific arch, e.g., >> 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. >> However, regarding zero build (without compiler1 and compiler2 and >> jvmci) , this flag is undelcared. Hence, this patch gets header file >> 'compiler/compiler_globals_pd.hpp' included where this flag is declared >> for the case when neither COMPILER1 nor COMPILER2 are defined and >> INCLUDE_JVMCI is inactive. >> >> Note that 'compiler/compiler_globals_pd.hpp' already includes >> 'runtime/globals_shared.hpp'. >> >> Note that zero build with PCH succeeds because 'runtime/globals.hpp' is >> included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is >> included in 'runtime/globals.hpp'. > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Header 'runtime/globals_shared.hpp' should be kept > > Header 'runtime/globals_shared.hpp' is kept even though > 'compiler/compiler_globals_pd.hpp' already includes it, because > 'compiler_globals.hpp' uses the DECLARE_FLAGS macro, which is defined by > 'runtime/globals_shared.hpp', and it should be included directly. > > Besides, update the copyright year to 2021. > > Change-Id: Ia355f3b6e98b495dc265093e71b2d1fec1ca45ca > CustomizedGitHooks: yes Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 14:30:55 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 14:30:55 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 12:03:05 GMT, Jie Fu wrote: >> Hao Sun has updated the pull request incrementally with one additional commit since the last revision: >> >> Header 'runtime/globals_shared.hpp' should be kept >> >> Header 'runtime/globals_shared.hpp' is kept even though >> 'compiler/compiler_globals_pd.hpp' already includes it, because >> 'compiler_globals.hpp' uses the DECLARE_FLAGS macro, which is defined by >> 'runtime/globals_shared.hpp', and it should be included directly. >> >> Besides, update the copyright year to 2021. >> >> Change-Id: Ia355f3b6e98b495dc265093e71b2d1fec1ca45ca >> CustomizedGitHooks: yes > > Marked as reviewed by jiefu (Committer). Thanks for your reviews! @DamonFool @iklam @shipilev The pre-submit tests were passed except the GC one which is not related to this patch. I suppose this patch is ready to be merged now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From shade at openjdk.java.net Tue Jan 5 16:30:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 16:30:56 GMT Subject: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 14:28:14 GMT, Hao Sun wrote: >> Marked as reviewed by jiefu (Committer). > > Thanks for your reviews! @DamonFool @iklam @shipilev > > The pre-submit tests were passed except the GC one which is not related to this patch. I suppose this patch is ready to be merged now. Sponsoring to unbreak current jdk/jdk CI for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From github.com+16932759+shqking at openjdk.java.net Tue Jan 5 16:30:58 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 5 Jan 2021 16:30:58 GMT Subject: Integrated: 8258857: Zero: non-PCH release build fails after JDK-8258074 In-Reply-To: References: Message-ID: On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun wrote: > From the error log we can see the root cause is that, develop_pd flag > 'pd_CICompileOSR' is undeclared in zero build. > > Where this flag is used? > Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 > of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'. > > Where this flag can be declared? > Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if > VM is built with compiler1 or compiler2. See lines 30 to 38 of > 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get > declared in the header files for specific arch, e.g., > 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'. > However, regarding zero build (without compiler1 and compiler2 and > jvmci) , this flag is undelcared. Hence, this patch gets header file > 'compiler/compiler_globals_pd.hpp' included where this flag is declared > for the case when neither COMPILER1 nor COMPILER2 are defined and > INCLUDE_JVMCI is inactive. > > Note that 'compiler/compiler_globals_pd.hpp' already includes > 'runtime/globals_shared.hpp'. > > Note that zero build with PCH succeeds because 'runtime/globals.hpp' is > included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is > included in 'runtime/globals.hpp'. This pull request has now been integrated. Changeset: 82bdbfd7 Author: Hao Sun Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/82bdbfd7 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8258857: Zero: non-PCH release build fails after JDK-8258074 Reviewed-by: jiefu, shade, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1894 From kvn at openjdk.java.net Tue Jan 5 18:37:55 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 5 Jan 2021 18:37:55 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 03:44:10 GMT, Hao Sun wrote: >> 1. '-Wdeprecated-copy' >> As specified in C++11 [1], "the generation of the implicitly-defined >> copy constructor is deprecated if T has a user-defined destructor or >> user-defined copy assignment operator". The rationale behind is the >> well-known Rule of Three [2]. >> >> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' >> warns about the C++11 deprecation of implicitly declared copy >> constructor and assignment operator if one of them is user-provided. >> Defining an explicit copy constructor would suppress this warning. >> >> The main reason why debug build with gcc-9 or higher succeeds lies in >> the inconsistent warning behaviors between gcc and clang. See the >> reduced code example [5]. We suspect it might be return value >> optimization/copy elision [6] that drives gcc not to declare implicit >> copy constructor for this case. >> >> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise >> warnings for deprecated defintions of copy constructors. However, >> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 >> and clang-9 are not affected. >> >> 2. '-Wimplicit-int-float-conversion' >> Making the conversion explicit would fix it. >> >> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. >> Therefore clang-8 and clang-9 are not affected. The flag with similar >> functionality in gcc is '-Wfloat-conversion', but it is not enabled by >> '-Wall' or '-Wextra'. That's why this warning does not apprear when >> building with gcc. >> >> [1] https://en.cppreference.com/w/cpp/language/copy_constructor >> [2] https://en.cppreference.com/w/cpp/language/rule_of_three >> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html >> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html >> [5] https://godbolt.org/z/err4jM >> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization >> >> >> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines. > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Update the copy constructors for class DUIterator, DUIterator_Fast and DUIterator_Last > > 1. Update copyright year to 2021. > 2. Add the definition of copy constructor for class DUIterator. > Otherwise, gcc with '-fno-elide-constructors' would raise a warning. > 3. For the copy constructor of class DUIterator_Fast, we initialize > '_vdui' as false, otherwise UB is introduced. > 4. It's better to define the copy constructor of class DUIterator_Last > as explicitly-defaulted, instead of leaving it for compilers to > implicitly define. > > Change-Id: I3d2f5b396aa116d1832f52da361ff3172459a87e > CustomizedGitHooks: yes node.hpp changes seems fine. Passed tier1 builds and testing. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1874 From erikj at openjdk.java.net Tue Jan 5 22:56:07 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 5 Jan 2021 22:56:07 GMT Subject: [jdk16] RFR: JDK-8258657: Doc build is broken by use of new language features Message-ID: This patch changes how the docs-reference make target behaves to better support the requirements for it. This target is used to generate javadocs in a more stable way between releases, so that they those docs are better suited for generating diffs between releases. Currently we use the boot JDK to run javadoc for these, but this has shown to be problematic. This patch introduced a specific configure parameter for the JDK to use just for generating these docs. If not set, it will revert to the default interim javadoc, just like the main docs are built (but still with a separate set of parameters). This fix needs to go into JDK 16 so that the docs-reference target there can be used to generate diffs for JDK 17. ------------- Commit messages: - Added configure output - Removed unneeded macosx workarounds - New configure parameter --with-docs-reference-jdk Changes: https://git.openjdk.java.net/jdk16/pull/88/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=88&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258657 Stats: 34 lines in 5 files changed: 31 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk16/pull/88.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/88/head:pull/88 PR: https://git.openjdk.java.net/jdk16/pull/88 From darcy at openjdk.java.net Wed Jan 6 02:25:03 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 6 Jan 2021 02:25:03 GMT Subject: RFR: 8258143: Update --release 16 symbol information for JDK 16 build 30 or later Message-ID: Updating to the symbol files for JDK 16 b30; change generated with the script make/scripts/generate-symbol-data.sh The change to the java.desktop module looks to be for JDK-8258373. ------------- Commit messages: - 8258143: Update --release 16 symbol information for JDK 16 build 30 or later Changes: https://git.openjdk.java.net/jdk/pull/1954/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1954&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258143 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1954.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1954/head:pull/1954 PR: https://git.openjdk.java.net/jdk/pull/1954 From iris at openjdk.java.net Wed Jan 6 02:52:56 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 6 Jan 2021 02:52:56 GMT Subject: RFR: 8258143: Update --release 16 symbol information for JDK 16 build 30 or later In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 02:19:51 GMT, Joe Darcy wrote: > Updating to the symbol files for JDK 16 b30; change generated with the script > > make/scripts/generate-symbol-data.sh > > The change to the java.desktop module looks to be for JDK-8258373. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1954 From github.com+16932759+shqking at openjdk.java.net Wed Jan 6 03:17:55 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Wed, 6 Jan 2021 03:17:55 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 18:35:07 GMT, Vladimir Kozlov wrote: >> Hao Sun has updated the pull request incrementally with one additional commit since the last revision: >> >> Update the copy constructors for class DUIterator, DUIterator_Fast and DUIterator_Last >> >> 1. Update copyright year to 2021. >> 2. Add the definition of copy constructor for class DUIterator. >> Otherwise, gcc with '-fno-elide-constructors' would raise a warning. >> 3. For the copy constructor of class DUIterator_Fast, we initialize >> '_vdui' as false, otherwise UB is introduced. >> 4. It's better to define the copy constructor of class DUIterator_Last >> as explicitly-defaulted, instead of leaving it for compilers to >> implicitly define. >> >> Change-Id: I3d2f5b396aa116d1832f52da361ff3172459a87e >> CustomizedGitHooks: yes > > node.hpp changes seems fine. > Passed tier1 builds and testing. > > I think the two issues described here are distinct and should be dealt > > with in separate bugs and PRs. Their only relation is that both arise > > with using clang-10. But they are very different problems, in very > > different parts of the code, and probably ought to be reviewed by > > folks from different teams. > > Thanks for your comment. > > Warning message of '-Wimplicit-int-float-conversion' was further encountered after we fixed the build failure caused by '-Wdeprecated-copy' first. That's why we put them in one PR initially. > > Yes. Your way is much better. But we suppose the issue of '-Wimplicit-int-float-conversion' is trivial and putting them in separate PRs might raise another internal review process (for our side) by which extra time is needed. I was wondering could we continue in one single PR. :) Will split this PR. In this PR, we focus on the warnings caused by -Wdeprecated-copy. Will update the code soon. Will create a new PR to address JDK-8259288. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From github.com+16932759+shqking at openjdk.java.net Wed Jan 6 04:31:01 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Wed, 6 Jan 2021 04:31:01 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v3] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 03:14:48 GMT, Hao Sun wrote: >> node.hpp changes seems fine. >> Passed tier1 builds and testing. > >> > I think the two issues described here are distinct and should be dealt >> > with in separate bugs and PRs. Their only relation is that both arise >> > with using clang-10. But they are very different problems, in very >> > different parts of the code, and probably ought to be reviewed by >> > folks from different teams. >> >> Thanks for your comment. >> >> Warning message of '-Wimplicit-int-float-conversion' was further encountered after we fixed the build failure caused by '-Wdeprecated-copy' first. That's why we put them in one PR initially. >> >> Yes. Your way is much better. But we suppose the issue of '-Wimplicit-int-float-conversion' is trivial and putting them in separate PRs might raise another internal review process (for our side) by which extra time is needed. I was wondering could we continue in one single PR. :) > > Will split this PR. > In this PR, we focus on the warnings caused by -Wdeprecated-copy. > Will update the code soon. Will create a new PR to address JDK-8259288. > Thanks for your comments. @kimbarrett and @navyxliu > I updated the patch based on my understanding. Please check the latest commit. > > As @kimbarrett mentioned, I suppose there still exist the following problems to be addressed. > > 1. why clang-10 with '-Wdeprecated-copy' does NOT raise warning for class DUIterator. It's weird. > 2. the assert failure when building with gcc '-fno-elide-constructors'. Might not be related to our patch. (JDK-8259036) > 3. the implementation of 'operator=' for class DUIterator_Fast might be problematic. @kimbarrett Regarding problem 1, I believe this is because there exists use-defined dtor for class DUIterator and the deprecated copy ctor warning message ought to be emitted by '-Wdeprecated-copy-dtor' (which is not enabled by '-Wall' or '-Wextra'). Please refer to https://github.com/llvm/llvm-project/blob/release/10.x/clang/lib/Sema/SemaDeclCXX.cpp#L13585 The main logic is user-defined dtor/copy constructor/assignment operator is checked in order when diagnosing implicit-defined copy constructor, and warning message will be emitted (lines 13619 to 13625). In this case of class DUIterator, user-defined dtor is provided but '-Wdeprecated-copy-dtor' is not enabled, clang-10 does not further check whether '-Wdeprecated-copy' is on or not. I further checked 1) I built openjdk with "--with-extra-cxxflags='-Wdeprecated-copy-dtor'", but the building failed earlier before class DUIterator. 2) I removed the dtor of class DUIterator manually and built openjdk with clang-10. Then clang-10 would produce the warning as we expected, which I think verified my conjecture. === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_gtest_objs_test_mathexact.o: In file included from /home/haosun01/jdk/jdk_src/test/hotspot/gtest/opto/test_mathexact.cpp:26: In file included from /home/haosun01/jdk/jdk_src/src/hotspot/share/opto/mulnode.hpp:28: void operator=(const DUIterator& that) ^ { return DUIterator(this, 0); } ^ void operator=(const DUIterator_Fast& that) ^ return DUIterator_Fast(this, 0); ^ ... (rest of output omitted) * For target support_gensrc_jdk.localedata__cldr-gensrc.marker: * All command lines available in /home/haosun01/tmp/deprecated-copy/clang10-fast-build/make-support/failure-logs. === End of repeated output === ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From github.com+16932759+shqking at openjdk.java.net Wed Jan 6 04:37:08 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Wed, 6 Jan 2021 04:37:08 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 10:15:27 GMT, Hao Sun wrote: >> That's true on the first assignment of `t2`. But what if `t2` is reassigned >> to some other iterator. That assignment sees `_vdui` true, and keeps the old >> value of `_last` rather than updating the value from that other iterator. Is >> that really correct? It certainly seems strange. I'm trying to find someone >> who understands this code to get involved, but holidays. > > Thanks for your explanation. Yes, you're right. I didn't realize the re-assignment scenario. @vnkozlov I was wondering if you could take a look at this? We're not sure whether 'operator=' is problematic or not. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From github.com+16932759+shqking at openjdk.java.net Wed Jan 6 06:14:11 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Wed, 6 Jan 2021 06:14:11 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v4] In-Reply-To: References: Message-ID: > 1. '-Wdeprecated-copy' > As specified in C++11 [1], "the generation of the implicitly-defined > copy constructor is deprecated if T has a user-defined destructor or > user-defined copy assignment operator". The rationale behind is the > well-known Rule of Three [2]. > > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' > warns about the C++11 deprecation of implicitly declared copy > constructor and assignment operator if one of them is user-provided. > Defining an explicit copy constructor would suppress this warning. > > The main reason why debug build with gcc-9 or higher succeeds lies in > the inconsistent warning behaviors between gcc and clang. See the > reduced code example [5]. We suspect it might be return value > optimization/copy elision [6] that drives gcc not to declare implicit > copy constructor for this case. > > Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise > warnings for deprecated defintions of copy constructors. However, > '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 > and clang-9 are not affected. > > ~~2. '-Wimplicit-int-float-conversion'~~ > ~~Making the conversion explicit would fix it.~~ > > ~~Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.~~ > ~~Therefore clang-8 and clang-9 are not affected. The flag with similar~~ > ~~functionality in gcc is '-Wfloat-conversion', but it is not enabled by~~ > ~~'-Wall' or '-Wextra'. That's why this warning does not apprear when~~ > ~~building with gcc.~~ > > [1] https://en.cppreference.com/w/cpp/language/copy_constructor > [2] https://en.cppreference.com/w/cpp/language/rule_of_three > [3] https://www.gnu.org/software/gcc/gcc-9/changes.html > [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html > [5] https://godbolt.org/z/err4jM > [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization > > > Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. > Note that '--with-extra-cxxflags=-Wno-implicit-int-float-conversion' should be added when configuration. It's another issue (See JDK-8259288) Hao Sun has updated the pull request incrementally with one additional commit since the last revision: Split the PR, addressing -Wdeprecated-copy only As suggested by kimbarrett, we should focus on warnings produced by '-Wdeprecated-copy' in this PR. Because JDK-8259288 is a very different problem and might be reviewed by folks from different teams. Will create a new PR to address JDK-8259288. Change-Id: I1b9f434ab6fcdf2763a46870eaed91641984fd76 CustomizedGitHooks: yes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1874/files - new: https://git.openjdk.java.net/jdk/pull/1874/files/d0f5d7d5..4cc18217 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1874&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1874&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1874/head:pull/1874 PR: https://git.openjdk.java.net/jdk/pull/1874 From github.com+16932759+shqking at openjdk.java.net Wed Jan 6 06:23:04 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Wed, 6 Jan 2021 06:23:04 GMT Subject: RFR: 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion Message-ID: Making the conversion explicit would fix it. Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. Therefore clang-8 and clang-9 are not affected. The flag with similar functionality in gcc is '-Wfloat-conversion', but it is not enabled by '-Wall' or '-Wextra'. That's why this warning does not appear when building with gcc. Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. Note that '--with-extra-cxxflags=-Wno-deprecated-copy' should be added when configuration. It's another issue (See JDK-8258010) ------------- Commit messages: - 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion Changes: https://git.openjdk.java.net/jdk/pull/1956/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1956&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259288 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1956.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1956/head:pull/1956 PR: https://git.openjdk.java.net/jdk/pull/1956 From erikj at openjdk.java.net Wed Jan 6 13:22:52 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 6 Jan 2021 13:22:52 GMT Subject: RFR: 8258143: Update --release 16 symbol information for JDK 16 build 30 or later In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 02:19:51 GMT, Joe Darcy wrote: > Updating to the symbol files for JDK 16 b30; change generated with the script > > make/scripts/generate-symbol-data.sh > > The change to the java.desktop module looks to be for JDK-8258373. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1954 From github.com+16932759+shqking at openjdk.java.net Wed Jan 6 14:29:00 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Wed, 6 Jan 2021 14:29:00 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v2] In-Reply-To: References: Message-ID: <8DhP6C1QayAGQEJusv1GAJ-dFg9WyE59TR9ZY9geDGU=.6d81f545-ff86-4502-b8bf-442e1dc76d91@github.com> On Wed, 6 Jan 2021 04:34:36 GMT, Hao Sun wrote: >> Thanks for your explanation. Yes, you're right. I didn't realize the re-assignment scenario. > > @vnkozlov I was wondering if you could take a look at this? We're not sure whether 'operator=' is problematic or not. Thanks. I manually checked the usages of assignment operators for class DUIterator, DUIterator_Fast and DUIterator_Last. (Simply grep the class names in the source code and check the context). ~~I found there exist only a couple of re-assignment usages. However, I guess kind of reset operations are conducted in these sites, and I suspect the implementation of `operator=` might be good.~~ As I examined, only the following 3 sites are found where re-assignment happens https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/cfgnode.cpp#L565 https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/phaseX.cpp#L1878 https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/split_if.cpp#L452 Please take `cfgnode.cpp` as an example. `j` is first assigned at line 568 and it would be assigned again if flag `progress` is true. ~~However, I suppose `j` gets reset at line 578 in such case.~~ Note that `j` might be re-assigned at line 578. However, it's self assignment and nothing is conducted. ~~It might be incorrect if I missed something.~~ Hope that this finding would be helpful to analyze this problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From darcy at openjdk.java.net Wed Jan 6 16:29:59 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 6 Jan 2021 16:29:59 GMT Subject: Integrated: 8258143: Update --release 16 symbol information for JDK 16 build 30 or later In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 02:19:51 GMT, Joe Darcy wrote: > Updating to the symbol files for JDK 16 b30; change generated with the script > > make/scripts/generate-symbol-data.sh > > The change to the java.desktop module looks to be for JDK-8258373. This pull request has now been integrated. Changeset: d20d2fa9 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/d20d2fa9 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8258143: Update --release 16 symbol information for JDK 16 build 30 or later Reviewed-by: iris, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/1954 From cjplummer at openjdk.java.net Wed Jan 6 17:38:56 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 6 Jan 2021 17:38:56 GMT Subject: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 09:25:55 GMT, Yasumasa Suenaga wrote: > I got garbled exception message as following when I run `livenmethods` CLHSDB command: > > sun.jvm.hotspot.debugger.DebuggerException : ?w???????W > > My Windows laptop is set Japanese Locale, garbled message was written in Japanese. > saproc.dll would throw exception via [ThrowNew()](https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#thrownew) JNI function, but it accepts UTF-8 encoded message. However [FormatMessage()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage) Windows API might not return UTF-8 encoded string on Japanese locale. > > java.dll (libjava,so) provides good functions to resolve this issue. We can convert localized (non ascii) chars to UTF-8 string. I use them in this PR and remove `FormatMessage()` call from sadis.c. > And also I remove `-D_MBCS` from compiler option because [MBCS has been already deprecated](https://docs.microsoft.com/ja-jp/cpp/text/support-for-multibyte-character-sets-mbcss) - it does not seem to add to any other executables. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From kvn at openjdk.java.net Wed Jan 6 20:07:53 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 6 Jan 2021 20:07:53 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v2] In-Reply-To: <8DhP6C1QayAGQEJusv1GAJ-dFg9WyE59TR9ZY9geDGU=.6d81f545-ff86-4502-b8bf-442e1dc76d91@github.com> References: <8DhP6C1QayAGQEJusv1GAJ-dFg9WyE59TR9ZY9geDGU=.6d81f545-ff86-4502-b8bf-442e1dc76d91@github.com> Message-ID: On Wed, 6 Jan 2021 13:24:22 GMT, Hao Sun wrote: >> @vnkozlov I was wondering if you could take a look at this? We're not sure whether 'operator=' is problematic or not. Thanks. > > I manually checked the usages of assignment operators for class DUIterator, DUIterator_Fast and DUIterator_Last. (Simply grep the class names in the source code and check the context). > > ~~I found there exist only a couple of re-assignment usages. However, I guess kind of reset operations are conducted in these sites, and I suspect the implementation of `operator=` might be good.~~ > > As I examined, only the following 3 sites are found where re-assignment happens > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/cfgnode.cpp#L565 > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/phaseX.cpp#L1878 > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/split_if.cpp#L452 > > Please take `cfgnode.cpp` as an example. `j` is first assigned at line 568 and it would be assigned again if flag `progress` is true. ~~However, I suppose `j` gets reset at line 578 in such case.~~ Note that `j` might be re-assigned at line 578. However, it's self assignment and nothing is conducted. > > ~~It might be incorrect if I missed something.~~ > Hope that this finding would be helpful to analyze this problem. Code is correct. _last should not be updated with additional assignments which updates only node's information. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From ysatowse at openjdk.java.net Wed Jan 6 22:51:02 2021 From: ysatowse at openjdk.java.net (Yoshiki Sato) Date: Wed, 6 Jan 2021 22:51:02 GMT Subject: Integrated: 8247957: remove doclint support for HTML 4 In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 03:26:16 GMT, Yoshiki Sato wrote: > HTML4 is no longer supported in javadoc. > > doclint needs to drop HTML4 support as well. > The changes consist of: > * Removing -Xhtmlversion option from doclint and --doclint-format from javac. > * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references. > * Updating makefile not to use removed option. > * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY) > * Fixing incorrect value checks for the id attribute. > * Modifying test code and expected outputs to be checked in HTML5 This pull request has now been integrated. Changeset: 28e1f4d9 Author: Yoshiki Sato Committer: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/28e1f4d9 Stats: 1499 lines in 60 files changed: 411 ins; 808 del; 280 mod 8247957: remove doclint support for HTML 4 8257204: Remove usage of -Xhtmlversion option from javac 8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option 8258460: Remove --doclint-format option from javac 8256312: Valid anchor 'id' value not allowed Reviewed-by: jjg, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/893 From tbell at openjdk.java.net Wed Jan 6 23:17:01 2021 From: tbell at openjdk.java.net (Tim Bell) Date: Wed, 6 Jan 2021 23:17:01 GMT Subject: [jdk16] RFR: JDK-8258657: Doc build is broken by use of new language features In-Reply-To: References: Message-ID: <5GZoPKWh1B6bQ8me8yBsY4mUtnA7Q6TbNRQVYjvlMU4=.c13cb6b8-8b86-4a7e-9c44-8a6736366006@github.com> On Tue, 5 Jan 2021 22:51:29 GMT, Erik Joelsson wrote: > This patch changes how the docs-reference make target behaves to better support the requirements for it. This target is used to generate javadocs in a more stable way between releases, so that they those docs are better suited for generating diffs between releases. Currently we use the boot JDK to run javadoc for these, but this has shown to be problematic. This patch introduced a specific configure parameter for the JDK to use just for generating these docs. If not set, it will revert to the default interim javadoc, just like the main docs are built (but still with a separate set of parameters). > > This fix needs to go into JDK 16 so that the docs-reference target there can be used to generate diffs for JDK 17. Marked as reviewed by tbell (Reviewer). Marked as reviewed by tbell (Reviewer). Marked as reviewed by tbell (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/88 From iris at openjdk.java.net Wed Jan 6 23:46:56 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 6 Jan 2021 23:46:56 GMT Subject: [jdk16] RFR: JDK-8258657: Doc build is broken by use of new language features In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 22:51:29 GMT, Erik Joelsson wrote: > This patch changes how the docs-reference make target behaves to better support the requirements for it. This target is used to generate javadocs in a more stable way between releases, so that they those docs are better suited for generating diffs between releases. Currently we use the boot JDK to run javadoc for these, but this has shown to be problematic. This patch introduced a specific configure parameter for the JDK to use just for generating these docs. If not set, it will revert to the default interim javadoc, just like the main docs are built (but still with a separate set of parameters). > > This fix needs to go into JDK 16 so that the docs-reference target there can be used to generate diffs for JDK 17. Do you need to update the copyright year? Other than that, your changes appear to implement the described behaviour. Thanks! Iris ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/88 From ysuenaga at openjdk.java.net Thu Jan 7 00:03:56 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 7 Jan 2021 00:03:56 GMT Subject: Integrated: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 09:25:55 GMT, Yasumasa Suenaga wrote: > I got garbled exception message as following when I run `livenmethods` CLHSDB command: > > sun.jvm.hotspot.debugger.DebuggerException : ?w???????W > > My Windows laptop is set Japanese Locale, garbled message was written in Japanese. > saproc.dll would throw exception via [ThrowNew()](https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#thrownew) JNI function, but it accepts UTF-8 encoded message. However [FormatMessage()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage) Windows API might not return UTF-8 encoded string on Japanese locale. > > java.dll (libjava,so) provides good functions to resolve this issue. We can convert localized (non ascii) chars to UTF-8 string. I use them in this PR and remove `FormatMessage()` call from sadis.c. > And also I remove `-D_MBCS` from compiler option because [MBCS has been already deprecated](https://docs.microsoft.com/ja-jp/cpp/text/support-for-multibyte-character-sets-mbcss) - it does not seem to add to any other executables. This pull request has now been integrated. Changeset: 67c22114 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/67c22114 Stats: 49 lines in 2 files changed: 4 ins; 37 del; 8 mod 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale Reviewed-by: erikj, cjplummer, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1928 From mbaesken at openjdk.java.net Thu Jan 7 08:57:04 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 7 Jan 2021 08:57:04 GMT Subject: RFR: JDK-8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 Message-ID: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com> Hello, for a while the AIX build fails with the following error in the harfbuzz build 1500-004: (U) INTERNAL COMPILER ERROR while compiling OT::MarkBasePosFormat1::collect_variation_indices(hb_collect_variation_indices_context_t *) const. Compilation ended. Contact your Service Representative and provide the following information: GRARNN: gr29643 is used before it is defined. This xlc 16 version is used for compiling bash-4.4$ xlc -qversion IBM XL C/C++ for AIX, V16.1.0 (5725-C72, 5765-J12) Version: 16.01.0000.0006 Solution by IBM compiler support is to use "-qdebug=necan", this effectively turns off an optimisation called "Early Re-canonizing" on the harfbuzz lib. ------------- Commit messages: - JDK-8258484 Changes: https://git.openjdk.java.net/jdk/pull/1972/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1972&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258484 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1972.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1972/head:pull/1972 PR: https://git.openjdk.java.net/jdk/pull/1972 From clanger at openjdk.java.net Thu Jan 7 09:34:10 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 7 Jan 2021 09:34:10 GMT Subject: RFR: JDK-8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 [v2] In-Reply-To: References: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com> Message-ID: On Thu, 7 Jan 2021 09:19:27 GMT, Matthias Baesken wrote: >> Hello, for a while the AIX build fails with the following error in the harfbuzz build >> 1500-004: (U) INTERNAL COMPILER ERROR while compiling OT::MarkBasePosFormat1::collect_variation_indices(hb_collect_variation_indices_context_t *) const. >> Compilation ended. Contact your Service Representative and provide the following information: GRARNN: gr29643 is used before it is defined. >> >> This xlc 16 version is used for compiling >> bash-4.4$ xlc -qversion >> IBM XL C/C++ for AIX, V16.1.0 (5725-C72, 5765-J12) >> Version: 16.01.0000.0006 >> >> Solution by IBM compiler support is to use "-qdebug=necan", this effectively turns off an optimisation called "Early Re-canonizing" on the harfbuzz lib. > > Matthias Baesken 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 two new commits since the last revision: > > - Adjust comment > - JDK-8258484 Hi Matthias, looks good to me in principal. I would spell out the abbreviation ICE, though, otherwise somebody reading this later could have difficulties to grok it ;-) Thanks Christoph Maybe better: Early re-canonizing has to be disabled to workaround an internal XlC compiler error when building libharfbuzz ? LGTM now :) ------------- Changes requested by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1972Marked as reviewed by clanger (Reviewer). From mbaesken at openjdk.java.net Thu Jan 7 09:34:09 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 7 Jan 2021 09:34:09 GMT Subject: RFR: JDK-8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 [v2] In-Reply-To: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com> References: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com> Message-ID: > Hello, for a while the AIX build fails with the following error in the harfbuzz build > 1500-004: (U) INTERNAL COMPILER ERROR while compiling OT::MarkBasePosFormat1::collect_variation_indices(hb_collect_variation_indices_context_t *) const. > Compilation ended. Contact your Service Representative and provide the following information: GRARNN: gr29643 is used before it is defined. > > This xlc 16 version is used for compiling > bash-4.4$ xlc -qversion > IBM XL C/C++ for AIX, V16.1.0 (5725-C72, 5765-J12) > Version: 16.01.0000.0006 > > Solution by IBM compiler support is to use "-qdebug=necan", this effectively turns off an optimisation called "Early Re-canonizing" on the harfbuzz lib. Matthias Baesken 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 two new commits since the last revision: - Adjust comment - JDK-8258484 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1972/files - new: https://git.openjdk.java.net/jdk/pull/1972/files/ecd93d06..27205b26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1972&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1972&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1972.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1972/head:pull/1972 PR: https://git.openjdk.java.net/jdk/pull/1972 From mdoerr at openjdk.java.net Thu Jan 7 10:14:59 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 7 Jan 2021 10:14:59 GMT Subject: RFR: JDK-8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 [v2] In-Reply-To: References: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com> Message-ID: On Thu, 7 Jan 2021 09:34:09 GMT, Matthias Baesken wrote: >> Hello, for a while the AIX build fails with the following error in the harfbuzz build >> 1500-004: (U) INTERNAL COMPILER ERROR while compiling OT::MarkBasePosFormat1::collect_variation_indices(hb_collect_variation_indices_context_t *) const. >> Compilation ended. Contact your Service Representative and provide the following information: GRARNN: gr29643 is used before it is defined. >> >> This xlc 16 version is used for compiling >> bash-4.4$ xlc -qversion >> IBM XL C/C++ for AIX, V16.1.0 (5725-C72, 5765-J12) >> Version: 16.01.0000.0006 >> >> Solution by IBM compiler support is to use "-qdebug=necan", this effectively turns off an optimisation called "Early Re-canonizing" on the harfbuzz lib. > > Matthias Baesken 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. Marked as reviewed by mdoerr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1972 From mbaesken at openjdk.java.net Thu Jan 7 12:43:00 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 7 Jan 2021 12:43:00 GMT Subject: Integrated: JDK-8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 In-Reply-To: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com> References: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com> Message-ID: On Thu, 7 Jan 2021 08:51:25 GMT, Matthias Baesken wrote: > Hello, for a while the AIX build fails with the following error in the harfbuzz build > 1500-004: (U) INTERNAL COMPILER ERROR while compiling OT::MarkBasePosFormat1::collect_variation_indices(hb_collect_variation_indices_context_t *) const. > Compilation ended. Contact your Service Representative and provide the following information: GRARNN: gr29643 is used before it is defined. > > This xlc 16 version is used for compiling > bash-4.4$ xlc -qversion > IBM XL C/C++ for AIX, V16.1.0 (5725-C72, 5765-J12) > Version: 16.01.0000.0006 > > Solution by IBM compiler support is to use "-qdebug=necan", this effectively turns off an optimisation called "Early Re-canonizing" on the harfbuzz lib. This pull request has now been integrated. Changeset: 3f9f86f0 Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/3f9f86f0 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 Reviewed-by: clanger, mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/1972 From erikj at openjdk.java.net Thu Jan 7 14:54:11 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 7 Jan 2021 14:54:11 GMT Subject: [jdk16] RFR: JDK-8258657: Doc build is broken by use of new language features [v2] In-Reply-To: References: Message-ID: > This patch changes how the docs-reference make target behaves to better support the requirements for it. This target is used to generate javadocs in a more stable way between releases, so that they those docs are better suited for generating diffs between releases. Currently we use the boot JDK to run javadoc for these, but this has shown to be problematic. This patch introduced a specific configure parameter for the JDK to use just for generating these docs. If not set, it will revert to the default interim javadoc, just like the main docs are built (but still with a separate set of parameters). > > This fix needs to go into JDK 16 so that the docs-reference target there can be used to generate diffs for JDK 17. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Update copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/88/files - new: https://git.openjdk.java.net/jdk16/pull/88/files/521c460c..5e5e7f78 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=88&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=88&range=00-01 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk16/pull/88.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/88/head:pull/88 PR: https://git.openjdk.java.net/jdk16/pull/88 From erikj at openjdk.java.net Thu Jan 7 15:00:02 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 7 Jan 2021 15:00:02 GMT Subject: [jdk16] Integrated: JDK-8258657: Doc build is broken by use of new language features In-Reply-To: References: Message-ID: <3jY3KNKMr2FcMeF2kRra2ekB2zGANz6bYOxFYTx1WFc=.73e83ae8-a786-4025-9caa-4eb29072e668@github.com> On Tue, 5 Jan 2021 22:51:29 GMT, Erik Joelsson wrote: > This patch changes how the docs-reference make target behaves to better support the requirements for it. This target is used to generate javadocs in a more stable way between releases, so that they those docs are better suited for generating diffs between releases. Currently we use the boot JDK to run javadoc for these, but this has shown to be problematic. This patch introduced a specific configure parameter for the JDK to use just for generating these docs. If not set, it will revert to the default interim javadoc, just like the main docs are built (but still with a separate set of parameters). > > This fix needs to go into JDK 16 so that the docs-reference target there can be used to generate diffs for JDK 17. This pull request has now been integrated. Changeset: 484e23b9 Author: Erik Joelsson URL: https://git.openjdk.java.net/jdk16/commit/484e23b9 Stats: 39 lines in 5 files changed: 31 ins; 0 del; 8 mod 8258657: Doc build is broken by use of new language features Reviewed-by: tbell, iris ------------- PR: https://git.openjdk.java.net/jdk16/pull/88 From powers.anirvan at gmail.com Thu Jan 7 15:20:08 2021 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Fri, 8 Jan 2021 00:20:08 +0900 Subject: Cannot build new jdk on Windows after commit d29c78d In-Reply-To: References: Message-ID: ++ build-dev On Thu, 7 Jan 2021 at 8:19 AM, - wrote: > Hello, > > I am a Windows 10 user trying to build OpenJDK HEAD > so that I can try to fix a bug in > javadoc. > > However, when I run make configure, my configure fails because it cannot > detect a regular microsoft visual studio installation, which contains > spaces in its directory name. > > I have tried to reinstall microsoft visual studio to a directory without > spaces in name and pointed VSCOMMTOOLS system var to that directory. It > succeeded but failed subsequently for other dependencies that have spaces > in directory names. > > I have determined that the problem arises after this commit: > d29c78da19ba78214efe9e7856cde30fdd9ba8ab > < > https://github.com/openjdk/jdk/commit/d29c78da19ba78214efe9e7856cde30fdd9ba8ab > > > > When I checkout the commit before, 74be819 > < > https://github.com/openjdk/jdk/commit/74be819088e13e244131cfb32d7d498ab213d075 > >, > when the "fixpath.c" was used rather than "fixpath.sh", I can run "make > configure" successfully, without failing for subsequent space problems. > > I think this problem lies within the "fixpath.sh" bash script. > Unfortunately, I am no good at shell. I hope Magnus Ihse Bursie, who did > the c to bash migration, can find a solution to this space in windows > directory name failing fixpath problem. > > Best, > liangchenblue at gmail.com > -- Anirvan From jlahoda at openjdk.java.net Thu Jan 7 20:23:16 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 7 Jan 2021 20:23:16 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v13] In-Reply-To: References: Message-ID: <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com> > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: - Fixing tests after a merge. - Merging master into JDK-8250768 - Merging recent master changes into JDK-8250768 - Fixing navigator for the PREVIEW page. - Fixing typo. - Removing obsolette @PreviewFeature. - Merging master into JDK-8250768 - Removing unnecessary property keys. - Cleanup - removing unnecessary code. - Merging master into JDK-8250768-dev4 - ... and 47 more: https://git.openjdk.java.net/jdk/compare/81c06242...a8046dde ------------- Changes: https://git.openjdk.java.net/jdk/pull/703/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=12 Stats: 3719 lines in 134 files changed: 2724 ins; 695 del; 300 mod Patch: https://git.openjdk.java.net/jdk/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Thu Jan 7 20:23:17 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 7 Jan 2021 20:23:17 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v12] In-Reply-To: References: Message-ID: <8Op-CSXTHItDGmtN_VyoyOdZe1WR9g4JkRe852pe274=.367211a5-5f71-473b-be53-ee3706e50786@github.com> On Wed, 9 Dec 2020 13:30:14 GMT, Magnus Ihse Bursie wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits: >> >> - Merging recent master changes into JDK-8250768 >> - Fixing navigator for the PREVIEW page. >> - Fixing typo. >> - Removing obsolette @PreviewFeature. >> - Merging master into JDK-8250768 >> - Removing unnecessary property keys. >> - Cleanup - removing unnecessary code. >> - Merging master into JDK-8250768-dev4 >> - Reflecting review comments. >> - Removing trailing whitespace. >> - ... and 45 more: https://git.openjdk.java.net/jdk/compare/044616bd...0c1c4d57 > > Build changes still good. I've merged the PR with the recent mainline, and I'd like to integrate sometime soon. Please let me know if there's any issue with that. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jwilhelm at openjdk.java.net Thu Jan 7 20:45:15 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 20:45:15 GMT Subject: RFR: Merge jdk16 Message-ID: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8249633: doclint reports missing javadoc for JavaFX property methods that have a property description - 8251200: False positive messages about missing comments for serialization - 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days - 8259075: Update the copyright notice in the files generated by CLDR Converter tool - 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes - 8258558: Revert changes for JDK-8252505 and related issues - 8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition - 8259007: This test printed a blank page - 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert - ... and 8 more: https://git.openjdk.java.net/jdk/compare/0e6de4eb...bbd6426f The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1989/files Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/1989.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1989/head:pull/1989 PR: https://git.openjdk.java.net/jdk/pull/1989 From jwilhelm at openjdk.java.net Thu Jan 7 21:21:57 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 21:21:57 GMT Subject: Integrated: Merge jdk16 In-Reply-To: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> References: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> Message-ID: On Thu, 7 Jan 2021 20:40:49 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 555641ed Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/555641ed Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1989 From erikj at openjdk.java.net Thu Jan 7 22:06:08 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 7 Jan 2021 22:06:08 GMT Subject: [jdk16] RFR: JDK-8259429: Update reference to README.md Message-ID: <-n4IDxJBbFemgzGim-vH0zA0WiHUdhMWXSWre-jOax8=.d61d3992-7b35-41e9-bffd-284a539963c1@github.com> In JDK-8251551, the top level README file changed names to README.md. In jib-profiles.js we have a reference to this file to identify if the current source tree is likely to be complete. This reference needs to be updated. ------------- Commit messages: - Change reference in jib-profiles.js Changes: https://git.openjdk.java.net/jdk16/pull/94/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=94&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259429 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/94.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/94/head:pull/94 PR: https://git.openjdk.java.net/jdk16/pull/94 From iris at openjdk.java.net Thu Jan 7 22:09:59 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 7 Jan 2021 22:09:59 GMT Subject: [jdk16] RFR: JDK-8259429: Update reference to README.md In-Reply-To: <-n4IDxJBbFemgzGim-vH0zA0WiHUdhMWXSWre-jOax8=.d61d3992-7b35-41e9-bffd-284a539963c1@github.com> References: <-n4IDxJBbFemgzGim-vH0zA0WiHUdhMWXSWre-jOax8=.d61d3992-7b35-41e9-bffd-284a539963c1@github.com> Message-ID: On Thu, 7 Jan 2021 22:01:51 GMT, Erik Joelsson wrote: > In JDK-8251551, the top level README file changed names to README.md. In jib-profiles.js we have a reference to this file to identify if the current source tree is likely to be complete. This reference needs to be updated. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/94 From clanger at openjdk.java.net Thu Jan 7 22:55:08 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 7 Jan 2021 22:55:08 GMT Subject: [jdk16] Integrated: 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 Message-ID: 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 ------------- Commit messages: - Backport 3f9f86f0d3f918b9955ba6ba73c9c58ae8fcf7cb Changes: https://git.openjdk.java.net/jdk16/pull/95/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=95&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258484 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/95.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/95/head:pull/95 PR: https://git.openjdk.java.net/jdk16/pull/95 From clanger at openjdk.java.net Thu Jan 7 22:55:08 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 7 Jan 2021 22:55:08 GMT Subject: [jdk16] Integrated: 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 22:47:35 GMT, Christoph Langer wrote: > 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 This pull request has now been integrated. Changeset: 677802d2 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk16/commit/677802d2 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 Backport-of: 3f9f86f0d3f918b9955ba6ba73c9c58ae8fcf7cb ------------- PR: https://git.openjdk.java.net/jdk16/pull/95 From suenaga at oss.nttdata.com Thu Jan 7 23:39:12 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 8 Jan 2021 08:39:12 +0900 Subject: Cannot build new jdk on Windows after commit d29c78d In-Reply-To: References: Message-ID: <61ee9023-5b9c-5ff0-7b6d-e9566af7ffc5@oss.nttdata.com> Hi, I use WSL 1 to build OpenJDK on Windows 10. However, it has a problem in fixpath.sh, so I've posted PR for it. https://github.com/openjdk/jdk/pull/1889 You can build OpenJDK if you apply it. Thanks, Yasumasa On 2021/01/08 0:20, Anirvan Sarkar wrote: > ++ build-dev > > On Thu, 7 Jan 2021 at 8:19 AM, - wrote: > >> Hello, >> >> I am a Windows 10 user trying to build OpenJDK HEAD >> so that I can try to fix a bug in >> javadoc. >> >> However, when I run make configure, my configure fails because it cannot >> detect a regular microsoft visual studio installation, which contains >> spaces in its directory name. >> >> I have tried to reinstall microsoft visual studio to a directory without >> spaces in name and pointed VSCOMMTOOLS system var to that directory. It >> succeeded but failed subsequently for other dependencies that have spaces >> in directory names. >> >> I have determined that the problem arises after this commit: >> d29c78da19ba78214efe9e7856cde30fdd9ba8ab >> < >> https://github.com/openjdk/jdk/commit/d29c78da19ba78214efe9e7856cde30fdd9ba8ab >>> >> >> When I checkout the commit before, 74be819 >> < >> https://github.com/openjdk/jdk/commit/74be819088e13e244131cfb32d7d498ab213d075 >>> , >> when the "fixpath.c" was used rather than "fixpath.sh", I can run "make >> configure" successfully, without failing for subsequent space problems. >> >> I think this problem lies within the "fixpath.sh" bash script. >> Unfortunately, I am no good at shell. I hope Magnus Ihse Bursie, who did >> the c to bash migration, can find a solution to this space in windows >> directory name failing fixpath problem. >> >> Best, >> liangchenblue at gmail.com >> From github.com+16932759+shqking at openjdk.java.net Thu Jan 7 23:43:55 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Thu, 7 Jan 2021 23:43:55 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v2] In-Reply-To: References: <8DhP6C1QayAGQEJusv1GAJ-dFg9WyE59TR9ZY9geDGU=.6d81f545-ff86-4502-b8bf-442e1dc76d91@github.com> Message-ID: On Wed, 6 Jan 2021 20:05:07 GMT, Vladimir Kozlov wrote: >> I manually checked the usages of assignment operators for class DUIterator, DUIterator_Fast and DUIterator_Last. (Simply grep the class names in the source code and check the context). >> >> ~~I found there exist only a couple of re-assignment usages. However, I guess kind of reset operations are conducted in these sites, and I suspect the implementation of `operator=` might be good.~~ >> >> As I examined, only the following 3 sites are found where re-assignment happens >> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/cfgnode.cpp#L565 >> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/phaseX.cpp#L1878 >> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/split_if.cpp#L452 >> >> Please take `cfgnode.cpp` as an example. `j` is first assigned at line 568 and it would be assigned again if flag `progress` is true. ~~However, I suppose `j` gets reset at line 578 in such case.~~ Note that `j` might be re-assigned at line 578. However, it's self assignment and nothing is conducted. >> >> ~~It might be incorrect if I missed something.~~ >> Hope that this finding would be helpful to analyze this problem. > > Code is correct. _last should not be updated with additional assignments which updates only node's information. Thanks a lot for your explanation @vnkozlov . ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From github.com+16932759+shqking at openjdk.java.net Thu Jan 7 23:53:55 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Thu, 7 Jan 2021 23:53:55 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v3] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 04:27:44 GMT, Hao Sun wrote: > Thanks for your comments. @kimbarrett and @navyxliu > I updated the patch based on my understanding. Please check the latest commit. > > As @kimbarrett mentioned, I suppose there still exist the following problems to be addressed. > > 1. why clang-10 with '-Wdeprecated-copy' does NOT raise warning for class DUIterator. It's weird. > 2. the assert failure when building with gcc '-fno-elide-constructors'. Might not be related to our patch. (JDK-8259036) > 3. the implementation of 'operator=' for class DUIterator_Fast might be problematic. For problem 1, it's due to '-Wdeprecated-copy-dtor'. Please refer to my previous comment for details. For problem 2, I suppose it's not related to our patch and it would be issued in JDK-8259036. For problem 3, as clarified by @vnkozlov , the code is correct. Besides, the pre-submit tests failed due to one GC problem, which seems not related to this patch. See JDK-8258481. Hence, I wonder if this patch is ready to merge. Could you please take another round of review as new commits have been made? @kimbarrett @navyxliu @vnkozlov Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From jwilhelm at openjdk.java.net Thu Jan 7 23:56:15 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 23:56:15 GMT Subject: Integrated: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 - 8039278: console.sh failed Automatically with exit code 1 - 8258972: unexpected compilation error with generic sealed interface - 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check - 8258657: Doc build is broken by use of new language features - 8250903: jdk/jfr/javaagent/TestLoadedAgent.java fails with Mismatch in TestEvent count The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1994&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1994&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1994/files Stats: 198 lines in 15 files changed: 147 ins; 31 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/1994.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1994/head:pull/1994 PR: https://git.openjdk.java.net/jdk/pull/1994 From jwilhelm at openjdk.java.net Thu Jan 7 23:56:17 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 23:56:17 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: <6YfMfrA9n62l9LpgHgzPt2twp3wBWzcnD9ZliipfNoE=.153e6add-6f3e-4fe5-948c-d20b4534412f@github.com> On Thu, 7 Jan 2021 23:46:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 56a354eb Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/56a354eb Stats: 198 lines in 15 files changed: 147 ins; 31 del; 20 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1994 From kvn at openjdk.java.net Fri Jan 8 00:51:56 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 8 Jan 2021 00:51:56 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v4] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 06:14:11 GMT, Hao Sun wrote: >> 1. '-Wdeprecated-copy' >> As specified in C++11 [1], "the generation of the implicitly-defined >> copy constructor is deprecated if T has a user-defined destructor or >> user-defined copy assignment operator". The rationale behind is the >> well-known Rule of Three [2]. >> >> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' >> warns about the C++11 deprecation of implicitly declared copy >> constructor and assignment operator if one of them is user-provided. >> Defining an explicit copy constructor would suppress this warning. >> >> The main reason why debug build with gcc-9 or higher succeeds lies in >> the inconsistent warning behaviors between gcc and clang. See the >> reduced code example [5]. We suspect it might be return value >> optimization/copy elision [6] that drives gcc not to declare implicit >> copy constructor for this case. >> >> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise >> warnings for deprecated defintions of copy constructors. However, >> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 >> and clang-9 are not affected. >> >> ~~2. '-Wimplicit-int-float-conversion'~~ >> ~~Making the conversion explicit would fix it.~~ >> >> ~~Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.~~ >> ~~Therefore clang-8 and clang-9 are not affected. The flag with similar~~ >> ~~functionality in gcc is '-Wfloat-conversion', but it is not enabled by~~ >> ~~'-Wall' or '-Wextra'. That's why this warning does not apprear when~~ >> ~~building with gcc.~~ >> >> [1] https://en.cppreference.com/w/cpp/language/copy_constructor >> [2] https://en.cppreference.com/w/cpp/language/rule_of_three >> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html >> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html >> [5] https://godbolt.org/z/err4jM >> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization >> >> >> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. >> Note that '--with-extra-cxxflags=-Wno-implicit-int-float-conversion' should be added when configuration. It's another issue (See JDK-8259288) > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Split the PR, addressing -Wdeprecated-copy only > > As suggested by kimbarrett, we should focus on warnings produced by > '-Wdeprecated-copy' in this PR. Because JDK-8259288 is a very different > problem and might be reviewed by folks from different teams. > > Will create a new PR to address JDK-8259288. > > Change-Id: I1b9f434ab6fcdf2763a46870eaed91641984fd76 > CustomizedGitHooks: yes Still good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1874 From jjg at openjdk.java.net Fri Jan 8 02:01:06 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 8 Jan 2021 02:01:06 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v13] In-Reply-To: <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com> References: <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com> Message-ID: On Thu, 7 Jan 2021 20:23:16 GMT, Jan Lahoda wrote: >> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. >> >> The notable changes are: >> >> * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: >> * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. >> * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings >> * improving error/warning messages. Please see [1] for a list of cases/examples. >> * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. >> * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). >> * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. >> * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. >> >> Please also see the CSR [6] for more information. >> >> [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html >> [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html >> [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html >> [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html >> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ >> [6] https://bugs.openjdk.java.net/browse/JDK-8250769 > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: > > - Fixing tests after a merge. > - Merging master into JDK-8250768 > - Merging recent master changes into JDK-8250768 > - Fixing navigator for the PREVIEW page. > - Fixing typo. > - Removing obsolette @PreviewFeature. > - Merging master into JDK-8250768 > - Removing unnecessary property keys. > - Cleanup - removing unnecessary code. > - Merging master into JDK-8250768-dev4 > - ... and 47 more: https://git.openjdk.java.net/jdk/compare/81c06242...a8046dde I've looked at all the files that were marked as changed since I last looked at them. There's one suggested enhancement to reduce string bashing between `Utils` and `ClassWriterImpl` that could be done now or later. There's a pending conflict with a PR of mine to change to use a new type `HtmlId` for HTML ids. This JEP12 work has been in progress for a while, and so it would be good to get it in before the `HtmlId` work, and I'll deal with the merge conflict in due course. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 194: > 192: > 193: @Override @SuppressWarnings("preview") > 194: public void addClassSignature(String modifiers, Content classInfoTree) { It seems less than ideal for this method to take a `String` and to then have to take it apart and reassemble it. It looks like it should be possible (and conceptually better) to change the signature to `List` and to make the corresponding change to `utils.modifiersToString`, probably renaming it as `utils.modifiersToStrings` or something like that, and dropping the always-`true` argument for `trailingSpace`. But, the code is OK as is, and the suggestion is just for an enhancement, so is OK to defer it, if you would prefer. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 2: > 1: /* > 2: * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved. (minor) now 2021 src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 61: > 59: public abstract class SummaryListWriter extends SubWriterHolderWriter { > 60: > 61: private String getAnchorName(SummaryElementKind kind) { Heads-up: at some point this will conflict with another change in progress/review, to introduce a new type `HtmlId` to use instead of `String` for ids. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 227: > 225: * @param contentTree the content tree to which the summary table will be added > 226: */ > 227: protected void addSummaryAPI(SortedSet apiList, String id, Heads-up, here's another occurrence of where there will be a conflict for ids. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 154: > 152: doclet.Errors=Errors > 153: doclet.Classes=Classes > 154: doclet.Records=Records I guess I'm mildly surprised to see all these items being removed... src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java line 2: > 1: /* > 2: * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved. Year test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java line 2: > 1: /* > 2: * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved. 2021. I assume you will do a bulk update for affected files. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/703 From jjg at openjdk.java.net Fri Jan 8 04:14:04 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 8 Jan 2021 04:14:04 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v13] In-Reply-To: References: <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com> Message-ID: On Fri, 8 Jan 2021 01:58:07 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: >> >> - Fixing tests after a merge. >> - Merging master into JDK-8250768 >> - Merging recent master changes into JDK-8250768 >> - Fixing navigator for the PREVIEW page. >> - Fixing typo. >> - Removing obsolette @PreviewFeature. >> - Merging master into JDK-8250768 >> - Removing unnecessary property keys. >> - Cleanup - removing unnecessary code. >> - Merging master into JDK-8250768-dev4 >> - ... and 47 more: https://git.openjdk.java.net/jdk/compare/81c06242...a8046dde > > I've looked at all the files that were marked as changed since I last looked at them. > > There's one suggested enhancement to reduce string bashing between `Utils` and `ClassWriterImpl` that could be done now or later. > > There's a pending conflict with a PR of mine to change to use a new type `HtmlId` for HTML ids. This JEP12 work has been in progress for a while, and so it would be good to get it in before the `HtmlId` work, and I'll deal with the merge conflict in due course. +1 -- Jon On 1/7/21 12:19 PM, Jan Lahoda wrote: > > I've merged the PR with the recent mainline, and I'd like to integrate > sometime soon. Please let me know if there's any issue with that. Thanks! > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From dholmes at openjdk.java.net Fri Jan 8 04:30:01 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Jan 2021 04:30:01 GMT Subject: RFR: 8258925: configure script failed on WSL In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 08:04:34 GMT, Yasumasa Suenaga wrote: > I ran configure script on WSL 1, but it failed as below: > > $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 > > : > > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java > configure exiting with result code 1 > > `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists. make/scripts/fixpath.sh line 152: > 150: # If it fails, try again with an added .exe (needed on WSL) > 151: if [[ $? -ne 0 ]]; then > 152: path="$path.exe" This seems to conflict with the logic starting at line #173 below. ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From ysuenaga at openjdk.java.net Fri Jan 8 06:07:14 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 8 Jan 2021 06:07:14 GMT Subject: RFR: 8258925: configure script failed on WSL [v2] In-Reply-To: References: Message-ID: > I ran configure script on WSL 1, but it failed as below: > > $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 > > : > > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java > configure exiting with result code 1 > > `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists. Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Save original path - Merge remote-tracking branch 'upstream/master' into JDK-8258925 - 8258925: configure script failed on WSL ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1889/files - new: https://git.openjdk.java.net/jdk/pull/1889/files/284b3a2a..286a1f64 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1889&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1889&range=00-01 Stats: 19697 lines in 830 files changed: 3395 ins; 7379 del; 8923 mod Patch: https://git.openjdk.java.net/jdk/pull/1889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1889/head:pull/1889 PR: https://git.openjdk.java.net/jdk/pull/1889 From ysuenaga at openjdk.java.net Fri Jan 8 06:07:17 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 8 Jan 2021 06:07:17 GMT Subject: RFR: 8258925: configure script failed on WSL [v2] In-Reply-To: References: Message-ID: <7Z72jwwowNK07aV_gy1MFmFbOpuE9kayf8lv1og9rGE=.99d0890b-96be-494d-a4de-b4cf8fc31211@github.com> On Fri, 8 Jan 2021 04:27:16 GMT, David Holmes wrote: >> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Save original path >> - Merge remote-tracking branch 'upstream/master' into JDK-8258925 >> - 8258925: configure script failed on WSL > > make/scripts/fixpath.sh line 152: > >> 150: # If it fails, try again with an added .exe (needed on WSL) >> 151: if [[ $? -ne 0 ]]; then >> 152: path="$path.exe" > > This seems to conflict with the logic starting at line #173 below. I pushed to new commit to save original `$path` and restore it later if the path not found. Could you review again? ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From dholmes at openjdk.java.net Fri Jan 8 06:25:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Jan 2021 06:25:56 GMT Subject: RFR: 8258925: configure script failed on WSL [v2] In-Reply-To: <7Z72jwwowNK07aV_gy1MFmFbOpuE9kayf8lv1og9rGE=.99d0890b-96be-494d-a4de-b4cf8fc31211@github.com> References: <7Z72jwwowNK07aV_gy1MFmFbOpuE9kayf8lv1og9rGE=.99d0890b-96be-494d-a4de-b4cf8fc31211@github.com> Message-ID: On Fri, 8 Jan 2021 06:03:46 GMT, Yasumasa Suenaga wrote: >> make/scripts/fixpath.sh line 152: >> >>> 150: # If it fails, try again with an added .exe (needed on WSL) >>> 151: if [[ $? -ne 0 ]]; then >>> 152: path="$path.exe" >> >> This seems to conflict with the logic starting at line #173 below. > > I pushed to new commit to save original `$path` and restore it later if the path not found. > Could you review again? Sorry but I'm really not following exactly what the problem is and thus the solution. How does setting path affect the running of PATHTOOL? Does the problem indicate we should be using winpath rather than path somewhere? ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From ysuenaga at openjdk.java.net Fri Jan 8 06:45:53 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 8 Jan 2021 06:45:53 GMT Subject: RFR: 8258925: configure script failed on WSL [v2] In-Reply-To: References: <7Z72jwwowNK07aV_gy1MFmFbOpuE9kayf8lv1og9rGE=.99d0890b-96be-494d-a4de-b4cf8fc31211@github.com> Message-ID: On Fri, 8 Jan 2021 06:23:35 GMT, David Holmes wrote: >> I pushed to new commit to save original `$path` and restore it later if the path not found. >> Could you review again? > > Sorry but I'm really not following exactly what the problem is and thus the solution. How does setting path affect the running of PATHTOOL? Does the problem indicate we should be using winpath rather than path somewhere? In this case `$PATHTOOL` points `wslpath`, and it tries to convert `$JAVA_HOME/bin/java` to Windows path. However `java` on Windows is `java.exe`, so we need to convert it. Currently `fixpath.sh` adds `.exe` if `wslpath` fails, then attempt to do it again, but `$path` still lost extension ( `.exe`). So `configure` will fail on WSL because `java.exe` cannot be find. ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From liangchenblue at gmail.com Fri Jan 8 05:35:45 2021 From: liangchenblue at gmail.com (-) Date: Thu, 7 Jan 2021 23:35:45 -0600 Subject: Adding to building info on space in windows directories Message-ID: Hello, This is a followup of https://mail.openjdk.java.net/pipermail/build-dev/2021-January/029905.html. In that thread, my build on Windows 10 (not WSL) failed because Windows did not short path some directories with space in it, such as "Microsoft Visual Studio" or "Microsoft SDKs", while fixpath.sh expects Windows to do so. This can be resolved by using fsutil to create short paths for them. A direct consequence is that configure emits an uninformative message of "Cannot find a valid Visual Studio installation" because all the paths it received from fixpath.sh is "". I believe it would be helpful if we add information on this problem in the building instructions. Would anyone support this idea and possibly create a ticket on openjdk bug tracker? Best, liangchenblue at gmail.com From david.holmes at oracle.com Fri Jan 8 07:24:46 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Jan 2021 17:24:46 +1000 Subject: RFR: 8258925: configure script failed on WSL [v2] In-Reply-To: References: <7Z72jwwowNK07aV_gy1MFmFbOpuE9kayf8lv1og9rGE=.99d0890b-96be-494d-a4de-b4cf8fc31211@github.com> Message-ID: <006532e5-6906-83c2-2cb5-de0c6b1f5da6@oracle.com> On 8/01/2021 4:45 pm, Yasumasa Suenaga wrote: > On Fri, 8 Jan 2021 06:23:35 GMT, David Holmes wrote: > >>> I pushed to new commit to save original `$path` and restore it later if the path not found. >>> Could you review again? >> >> Sorry but I'm really not following exactly what the problem is and thus the solution. How does setting path affect the running of PATHTOOL? Does the problem indicate we should be using winpath rather than path somewhere? > > In this case `$PATHTOOL` points `wslpath`, and it tries to convert `$JAVA_HOME/bin/java` to Windows path. However `java` on Windows is `java.exe`, so we need to convert it. > > Currently `fixpath.sh` adds `.exe` if `wslpath` fails, then attempt to do it again, but `$path` still lost extension ( `.exe`). So `configure` will fail on WSL because `java.exe` cannot be find. Sorry but how does this: winpath="$($PATHTOOL -w "$path.exe" 2>/dev/null)" not add the .exe extension? David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1889 > From ysuenaga at openjdk.java.net Fri Jan 8 07:36:54 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 8 Jan 2021 07:36:54 GMT Subject: RFR: 8258925: configure script failed on WSL In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 08:04:34 GMT, Yasumasa Suenaga wrote: > I ran configure script on WSL 1, but it failed as below: > > $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 > > : > > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java > configure exiting with result code 1 > > `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists. > Sorry but how does this: > > winpath="$($PATHTOOL -w "$path.exe" 2>/dev/null)" > > not add the .exe extension? Yes, but `$path` is finally to use, not `$winpath`. https://github.com/openjdk/jdk/blob/712014c5956cf74982531d212b03460843e4e5b6/make/scripts/fixpath.sh#L165-L166 ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From david.holmes at oracle.com Fri Jan 8 10:38:01 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Jan 2021 20:38:01 +1000 Subject: RFR: 8258925: configure script failed on WSL In-Reply-To: References: Message-ID: <68b6ece0-21b1-5eb9-70cb-213f9bc553f0@oracle.com> On 8/01/2021 5:36 pm, Yasumasa Suenaga wrote: > On Thu, 24 Dec 2020 08:04:34 GMT, Yasumasa Suenaga wrote: > >> I ran configure script on WSL 1, but it failed as below: >> >> $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 >> >> : >> >> configure: Found potential Boot JDK using configure arguments >> configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. >> configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java >> configure exiting with result code 1 >> >> `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists. > >> Sorry but how does this: >> >> winpath="$($PATHTOOL -w "$path.exe" 2>/dev/null)" >> >> not add the .exe extension? > > Yes, but `$path` is finally to use, not `$winpath`. > https://github.com/openjdk/jdk/blob/712014c5956cf74982531d212b03460843e4e5b6/make/scripts/fixpath.sh#L165-L166 Exactly my point. Shouldn't this: # Make it lower case path="$(echo "$path" | tr [:upper:] [:lower:])" be: # Make it lower case path="$(echo "$winpath" | tr [:upper:] [:lower:])" ? David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1889 > From kbarrett at openjdk.java.net Fri Jan 8 11:57:55 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 8 Jan 2021 11:57:55 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v4] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 06:14:11 GMT, Hao Sun wrote: >> 1. '-Wdeprecated-copy' >> As specified in C++11 [1], "the generation of the implicitly-defined >> copy constructor is deprecated if T has a user-defined destructor or >> user-defined copy assignment operator". The rationale behind is the >> well-known Rule of Three [2]. >> >> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' >> warns about the C++11 deprecation of implicitly declared copy >> constructor and assignment operator if one of them is user-provided. >> Defining an explicit copy constructor would suppress this warning. >> >> The main reason why debug build with gcc-9 or higher succeeds lies in >> the inconsistent warning behaviors between gcc and clang. See the >> reduced code example [5]. We suspect it might be return value >> optimization/copy elision [6] that drives gcc not to declare implicit >> copy constructor for this case. >> >> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise >> warnings for deprecated defintions of copy constructors. However, >> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 >> and clang-9 are not affected. >> >> ~~2. '-Wimplicit-int-float-conversion'~~ >> ~~Making the conversion explicit would fix it.~~ >> >> ~~Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.~~ >> ~~Therefore clang-8 and clang-9 are not affected. The flag with similar~~ >> ~~functionality in gcc is '-Wfloat-conversion', but it is not enabled by~~ >> ~~'-Wall' or '-Wextra'. That's why this warning does not apprear when~~ >> ~~building with gcc.~~ >> >> [1] https://en.cppreference.com/w/cpp/language/copy_constructor >> [2] https://en.cppreference.com/w/cpp/language/rule_of_three >> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html >> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html >> [5] https://godbolt.org/z/err4jM >> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization >> >> >> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. >> Note that '--with-extra-cxxflags=-Wno-implicit-int-float-conversion' should be added when configuration. It's another issue (See JDK-8259288) > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Split the PR, addressing -Wdeprecated-copy only > > As suggested by kimbarrett, we should focus on warnings produced by > '-Wdeprecated-copy' in this PR. Because JDK-8259288 is a very different > problem and might be reviewed by folks from different teams. > > Will create a new PR to address JDK-8259288. > > Change-Id: I1b9f434ab6fcdf2763a46870eaed91641984fd76 > CustomizedGitHooks: yes [Can't comment on this inline.] I'd prefer DUIterator_Last::operator= be changed to =default, for consistency with the copy constructor. That would require fixing the return type too. src/hotspot/share/opto/node.hpp line 1461: > 1459: // initialize to garbage > 1460: > 1461: DUIterator_Last (const DUIterator_Last& that) = default; Nit - remove space before parameter list. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1874 From ysuenaga at openjdk.java.net Fri Jan 8 12:29:17 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 8 Jan 2021 12:29:17 GMT Subject: RFR: 8258925: configure script failed on WSL [v3] In-Reply-To: References: Message-ID: > I ran configure script on WSL 1, but it failed as below: > > $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 > > : > > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java > configure exiting with result code 1 > > `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Refactoring ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1889/files - new: https://git.openjdk.java.net/jdk/pull/1889/files/286a1f64..37498adf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1889&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1889&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1889/head:pull/1889 PR: https://git.openjdk.java.net/jdk/pull/1889 From ysuenaga at openjdk.java.net Fri Jan 8 12:33:56 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 8 Jan 2021 12:33:56 GMT Subject: RFR: 8258925: configure script failed on WSL In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 07:34:03 GMT, Yasumasa Suenaga wrote: >> I ran configure script on WSL 1, but it failed as below: >> >> $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 >> >> : >> >> configure: Found potential Boot JDK using configure arguments >> configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. >> configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java >> configure exiting with result code 1 >> >> `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists. > >> Sorry but how does this: >> >> winpath="$($PATHTOOL -w "$path.exe" 2>/dev/null)" >> >> not add the .exe extension? > > Yes, but `$path` is finally to use, not `$winpath`. > https://github.com/openjdk/jdk/blob/712014c5956cf74982531d212b03460843e4e5b6/make/scripts/fixpath.sh#L165-L166 > > > Sorry but how does this: > > > winpath="$($PATHTOOL -w "$path.exe" 2>/dev/null)" > > > not add the .exe extension? > > > > > > Yes, but `$path` is finally to use, not `$winpath`. > > https://github.com/openjdk/jdk/blob/712014c5956cf74982531d212b03460843e4e5b6/make/scripts/fixpath.sh#L165-L166 > > Exactly my point. Shouldn't this: > > # Make it lower case > path="$(echo "$path" | tr [:upper:] [:lower:])" > > be: > > # Make it lower case > path="$(echo "$winpath" | tr [:upper:] [:lower:])" > > ? No, `path` points unix path, on the other hand, `winpath` points windows path. For example: * path * /mnt/c/java/jdk-15.0.1/bin/java.exe * winpath * C:\Java\jdk-15.0.1\bin\java.exe However I think we can simplify this change based on `winpath`. How about new change? ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From dholmes at openjdk.java.net Fri Jan 8 13:09:57 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Jan 2021 13:09:57 GMT Subject: RFR: 8258925: configure script failed on WSL [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 12:29:17 GMT, Yasumasa Suenaga wrote: >> I ran configure script on WSL 1, but it failed as below: >> >> $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 >> >> : >> >> configure: Found potential Boot JDK using configure arguments >> configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. >> configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java >> configure exiting with result code 1 >> >> `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring Hi Yasumasa, Okay I see the problem case now, and the latest fix seems to fix things in a way that makes sense to me now. We still need to wait to see what Magnus or Erik think though. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1889 From erik.joelsson at oracle.com Fri Jan 8 13:41:27 2021 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Jan 2021 05:41:27 -0800 Subject: Adding to building info on space in windows directories In-Reply-To: References: Message-ID: <63d093ca-fe7a-3f51-d7e7-3ea12a313a27@oracle.com> I agree this would be useful and filed https://bugs.openjdk.java.net/browse/JDK-8259485 /Erik On 2021-01-07 21:35, - wrote: > Hello, > This is a followup of > https://mail.openjdk.java.net/pipermail/build-dev/2021-January/029905.html. > > In that thread, my build on Windows 10 (not WSL) failed because Windows did > not short path some directories with space in it, such as "Microsoft Visual > Studio" or "Microsoft SDKs", while fixpath.sh expects Windows to do so. > This can be resolved by using fsutil to create short paths for them. > > A direct consequence is that configure emits an uninformative message of > "Cannot find a valid Visual Studio installation" because all the paths it > received from fixpath.sh is "". > > I believe it would be helpful if we add information on this problem in the > building instructions. Would anyone support this idea and possibly create a > ticket on openjdk bug tracker? > > Best, > liangchenblue at gmail.com From erikj at openjdk.java.net Fri Jan 8 14:17:57 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 8 Jan 2021 14:17:57 GMT Subject: RFR: 8258925: configure script failed on WSL [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 13:07:02 GMT, David Holmes wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactoring > > Hi Yasumasa, > > Okay I see the problem case now, and the latest fix seems to fix things in a way that makes sense to me now. We still need to wait to see what Magnus or Erik think though. > > Thanks, > David I initially wanted to leave this for Magnus to look at since he wrote all of this, and I know he put a lot of effort into fixpath.sh. It's not a simple script. Now I have stared at it for a while, I think I understand the problem. One very important aspect of fixpath.sh is to not do heavy work unnecessarily. The latest solution unfortunately adds a call to $PATHTOOL when winpath does not contain forbidden characters. This is a pretty common case and will have performance impact. The problem is that on line 152, if we find the executable by adding .exe, we need to remember this and use it on line 166, but we cannot modify the variable "path" as it's also used in the else block starting on 168. I would propose introducing a new variable "unixpath" before line 151. Add .exe to it before line 152. Then overwrite it on line 162, and finally use it as the source on line 166. ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From ysuenaga at openjdk.java.net Fri Jan 8 14:51:54 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 8 Jan 2021 14:51:54 GMT Subject: RFR: 8258925: configure script failed on WSL [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 14:15:08 GMT, Erik Joelsson wrote: >> Hi Yasumasa, >> >> Okay I see the problem case now, and the latest fix seems to fix things in a way that makes sense to me now. We still need to wait to see what Magnus or Erik think though. >> >> Thanks, >> David > > I initially wanted to leave this for Magnus to look at since he wrote all of this, and I know he put a lot of effort into fixpath.sh. It's not a simple script. Now I have stared at it for a while, I think I understand the problem. > > One very important aspect of fixpath.sh is to not do heavy work unnecessarily. The latest solution unfortunately adds a call to $PATHTOOL when winpath does not contain forbidden characters. This is a pretty common case and will have performance impact. > > The problem is that on line 152, if we find the executable by adding .exe, we need to remember this and use it on line 166, but we cannot modify the variable "path" as it's also used in the else block starting on 168. I would propose introducing a new variable "unixpath" before line 151. Add .exe to it before line 152. Then overwrite it on line 162, and finally use it as the source on line 166. Thanks @erikj79 for proposing the fix! but I think we should not add variable(s) as possible. We use `$path` as a result, and we use `$path`, `$winpath` (and `$shortpath` generated by `$winpath`) as input for it if fixpath.sh runs on WSL. The cause of this problem is fixpath.sh modifies `$winpath` only. If we add new variable, similar issue(s) may happen in future. Fortunately we can convert to unix path from windows path. So it is easy to maintenance if we converge the path to modify to `$winpath`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From erikj at openjdk.java.net Fri Jan 8 14:59:54 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 8 Jan 2021 14:59:54 GMT Subject: RFR: 8258925: configure script failed on WSL [v3] In-Reply-To: References: Message-ID: <-6nKkp0jFQgv1fsM97Xvqspo85onsg7eHq0Copnm6tA=.b6b25e2e-99c6-4d5b-9c28-b2b1ef30f214@github.com> On Fri, 8 Jan 2021 14:49:12 GMT, Yasumasa Suenaga wrote: >> I initially wanted to leave this for Magnus to look at since he wrote all of this, and I know he put a lot of effort into fixpath.sh. It's not a simple script. Now I have stared at it for a while, I think I understand the problem. >> >> One very important aspect of fixpath.sh is to not do heavy work unnecessarily. The latest solution unfortunately adds a call to $PATHTOOL when winpath does not contain forbidden characters. This is a pretty common case and will have performance impact. >> >> The problem is that on line 152, if we find the executable by adding .exe, we need to remember this and use it on line 166, but we cannot modify the variable "path" as it's also used in the else block starting on 168. I would propose introducing a new variable "unixpath" before line 151. Add .exe to it before line 152. Then overwrite it on line 162, and finally use it as the source on line 166. > > Thanks @erikj79 for proposing the fix! but I think we should not add variable(s) as possible. > > We use `$path` as a result, and we use `$path`, `$winpath` (and `$shortpath` generated by `$winpath`) as input for it if fixpath.sh runs on WSL. > The cause of this problem is fixpath.sh modifies `$winpath` only. If we add new variable, similar issue(s) may happen in future. Fortunately we can convert to unix path from windows path. So it is easy to maintenance if we converge the path to modify to `$winpath`. In this case, I think introducing a variable is well worth it as it means we can eliminate a very common and unnecessary call to $PATHTOOL. ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From jlahoda at openjdk.java.net Fri Jan 8 15:26:04 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 8 Jan 2021 15:26:04 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v13] In-Reply-To: References: <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com> Message-ID: On Fri, 8 Jan 2021 01:51:52 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: >> >> - Fixing tests after a merge. >> - Merging master into JDK-8250768 >> - Merging recent master changes into JDK-8250768 >> - Fixing navigator for the PREVIEW page. >> - Fixing typo. >> - Removing obsolette @PreviewFeature. >> - Merging master into JDK-8250768 >> - Removing unnecessary property keys. >> - Cleanup - removing unnecessary code. >> - Merging master into JDK-8250768-dev4 >> - ... and 47 more: https://git.openjdk.java.net/jdk/compare/81c06242...a8046dde > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 154: > >> 152: doclet.Errors=Errors >> 153: doclet.Classes=Classes >> 154: doclet.Records=Records > > I guess I'm mildly surprised to see all these items being removed... These were used from DeprecatedListWriter.getSummaryKey which is removed by this patch (and is unused in the current mainline, as far as I know). ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Fri Jan 8 15:29:22 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 8 Jan 2021 15:29:22 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v14] In-Reply-To: References: Message-ID: <5yqRThkGhxW8tDtwfkBzOB8k6-CoWkengMWAgeGogr0=.fa0c0a28-abe8-47bb-86f8-cd18b1ed3aa0@github.com> > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Updating copyright years. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/703/files - new: https://git.openjdk.java.net/jdk/pull/703/files/a8046dde..56371c47 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=12-13 Stats: 103 lines in 103 files changed: 0 ins; 0 del; 103 mod Patch: https://git.openjdk.java.net/jdk/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Fri Jan 8 17:22:19 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 8 Jan 2021 17:22:19 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v15] In-Reply-To: References: Message-ID: <1l2ZGdCLlmLZ_hbqsEG0AnTrX7pob7FJ_kJ73_qLLu8=.a116a4b4-229e-41dc-ba22-d72f139ce2dd@github.com> > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits: - Merging master into JDK-8250768 - Updating copyright years. - Fixing tests after a merge. - Merging master into JDK-8250768 - Merging recent master changes into JDK-8250768 - Fixing navigator for the PREVIEW page. - Fixing typo. - Removing obsolette @PreviewFeature. - Merging master into JDK-8250768 - Removing unnecessary property keys. - ... and 49 more: https://git.openjdk.java.net/jdk/compare/090bd3af...4f654955 ------------- Changes: https://git.openjdk.java.net/jdk/pull/703/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=14 Stats: 3802 lines in 133 files changed: 2724 ins; 695 del; 383 mod Patch: https://git.openjdk.java.net/jdk/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 PR: https://git.openjdk.java.net/jdk/pull/703 From erikj at openjdk.java.net Fri Jan 8 18:33:00 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 8 Jan 2021 18:33:00 GMT Subject: [jdk16] Integrated: JDK-8259429: Update reference to README.md In-Reply-To: <-n4IDxJBbFemgzGim-vH0zA0WiHUdhMWXSWre-jOax8=.d61d3992-7b35-41e9-bffd-284a539963c1@github.com> References: <-n4IDxJBbFemgzGim-vH0zA0WiHUdhMWXSWre-jOax8=.d61d3992-7b35-41e9-bffd-284a539963c1@github.com> Message-ID: On Thu, 7 Jan 2021 22:01:51 GMT, Erik Joelsson wrote: > In JDK-8251551, the top level README file changed names to README.md. In jib-profiles.js we have a reference to this file to identify if the current source tree is likely to be complete. This reference needs to be updated. This pull request has now been integrated. Changeset: 020ec848 Author: Erik Joelsson URL: https://git.openjdk.java.net/jdk16/commit/020ec848 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8259429: Update reference to README.md Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk16/pull/94 From darcy at openjdk.java.net Fri Jan 8 22:40:03 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 8 Jan 2021 22:40:03 GMT Subject: RFR: 8259512: Update --release 16 symbol information for JDK 16 build 31 Message-ID: Using the symbol updating script, update the symbol files for API changes in JDK 16 build 31. ------------- Commit messages: - 8259512: Update --release 16 symbol information for JDK 16 build 31 Changes: https://git.openjdk.java.net/jdk/pull/2010/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2010&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259512 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2010.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2010/head:pull/2010 PR: https://git.openjdk.java.net/jdk/pull/2010 From jjg at openjdk.java.net Fri Jan 8 23:56:55 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 8 Jan 2021 23:56:55 GMT Subject: RFR: 8259512: Update --release 16 symbol information for JDK 16 build 31 In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 22:36:01 GMT, Joe Darcy wrote: > Using the symbol updating script, update the symbol files for API changes in JDK 16 build 31. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2010 From darcy at openjdk.java.net Sat Jan 9 00:06:55 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 9 Jan 2021 00:06:55 GMT Subject: Integrated: 8259512: Update --release 16 symbol information for JDK 16 build 31 In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 22:36:01 GMT, Joe Darcy wrote: > Using the symbol updating script, update the symbol files for API changes in JDK 16 build 31. This pull request has now been integrated. Changeset: a6539282 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/a6539282 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod 8259512: Update --release 16 symbol information for JDK 16 build 31 Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/2010 From github.com+16932759+shqking at openjdk.java.net Sat Jan 9 00:29:57 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Sat, 9 Jan 2021 00:29:57 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v4] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 11:55:21 GMT, Kim Barrett wrote: > [Can't comment on this inline.] I'd prefer DUIterator_Last::operator= be changed to =default, for consistency with the copy constructor. That would require fixing the return type too. Thanks for your comment. Agree. Will update the code. > src/hotspot/share/opto/node.hpp line 1461: > >> 1459: // initialize to garbage >> 1460: >> 1461: DUIterator_Last (const DUIterator_Last& that) = default; > > Nit - remove space before parameter list. Thanks for point it out. Will remove. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From serb at openjdk.java.net Sat Jan 9 01:33:03 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 9 Jan 2021 01:33:03 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race wrote: > Proposed updates to JNI error handling. src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 180: > 178: * nature of the problem that has been detected and how survivable it is. > 179: */ > 180: #define CHECK_EXCEPTION() \ Since this macro does not try to return from the outer code we can change it to the method? src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 182: > 180: #define CHECK_EXCEPTION() \ > 181: if ((*env)->ExceptionOccurred(env) != NULL) { \ > 182: if ([NSThread isMainThread] == YES) { \ Isn't it is a similar code to the https://github.com/openjdk/jdk/blob/67c221148159d94142a3a6d9ddadce2dff8c858b/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L334 Where we just catch an exception log it, and continue to run our infinite loop? Why do we need to do something specific here? I mean we cannot drop any try/catch blocks anyway since an nsexception may be generated by some external system code. src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41: > 39: NSLog(@"%@",[NSThread callStackSymbols]); \ > 40: if ([NSThread isMainThread] == NO) { \ > 41: JNU_ThrowInternalError(env, "Bad JNI Lookup"); \ It will be possible that(most of the time) the JNU_ThrowInternalError will be called while we already have a raised java exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Sat Jan 9 01:33:02 2021 From: prr at openjdk.java.net (Phil Race) Date: Sat, 9 Jan 2021 01:33:02 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. Message-ID: Proposed updates to JNI error handling. ------------- Commit messages: - 8259343: [macOS] Update JNI error handling in Cocoa code. - 8259343: [macOS] Update JNI error handling in Cocoa code. Changes: https://git.openjdk.java.net/jdk/pull/1967/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1967&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259343 Stats: 73 lines in 8 files changed: 58 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1967.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1967/head:pull/1967 PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Sat Jan 9 01:33:05 2021 From: prr at openjdk.java.net (Phil Race) Date: Sat, 9 Jan 2021 01:33:05 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 00:35:27 GMT, Sergey Bylokhov wrote: >> Proposed updates to JNI error handling. > > src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 180: > >> 178: * nature of the problem that has been detected and how survivable it is. >> 179: */ >> 180: #define CHECK_EXCEPTION() \ > > Since this macro does not try to return from the outer code we can change it to the method? But then "env" would need to be passed explicitly. I don't think the churn is worth it. And a method would then need a .m or .c file ... > src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41: > >> 39: NSLog(@"%@",[NSThread callStackSymbols]); \ >> 40: if ([NSThread isMainThread] == NO) { \ >> 41: JNU_ThrowInternalError(env, "Bad JNI Lookup"); \ > > It will be possible that(most of the time) the JNU_ThrowInternalError will be called while we already have a raised java exception. I don't think "most" of the time is very likely. JNI lookup failures don't cause exceptions to be thrown. Is that what you are tihinking ? And separately, with either the current code of clearing exceptions or the change here to the practice of throwing NSException on seeing a Java Exception I think it very unlikely. > src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 182: > >> 180: #define CHECK_EXCEPTION() \ >> 181: if ((*env)->ExceptionOccurred(env) != NULL) { \ >> 182: if ([NSThread isMainThread] == YES) { \ > > Isn't it is a similar code to the > https://github.com/openjdk/jdk/blob/67c221148159d94142a3a6d9ddadce2dff8c858b/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L334 > Where we just catch an exception log it, and continue to run our infinite loop? Why do we need to do something specific here? I mean we cannot drop any try/catch blocks anyway since an nsexception may be generated by some external system code. In my testing that code does not get called. The new code does. So the old code could probably be deleted as useless but it is also harmless and just maybe it'll catch something else, even if it isn't doing anything that I can see. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Sat Jan 9 01:33:06 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 9 Jan 2021 01:33:06 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 02:40:58 GMT, Phil Race wrote: >> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41: >> >>> 39: NSLog(@"%@",[NSThread callStackSymbols]); \ >>> 40: if ([NSThread isMainThread] == NO) { \ >>> 41: JNU_ThrowInternalError(env, "Bad JNI Lookup"); \ >> >> It will be possible that(most of the time) the JNU_ThrowInternalError will be called while we already have a raised java exception. > > I don't think "most" of the time is very likely. JNI lookup failures don't cause exceptions to be thrown. > Is that what you are tihinking ? > > And separately, with either the current code of clearing exceptions or the change here to the practice of throwing NSException on seeing a Java Exception I think it very unlikely. Then how we get NoSuchMethodError here? https://bugs.openjdk.java.net/browse/JDK-8259232? https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetMethodID Calling Instance Methods: GetMethodID RETURNS: Returns a method ID, or NULL if the specified method cannot be found. THROWS: NoSuchMethodError: if the specified method cannot be found. ExceptionInInitializerError: if the class initializer fails due to an exception. OutOfMemoryError: if the system runs out of memory. Same for fields: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetFieldID >> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 180: >> >>> 178: * nature of the problem that has been detected and how survivable it is. >>> 179: */ >>> 180: #define CHECK_EXCEPTION() \ >> >> Since this macro does not try to return from the outer code we can change it to the method? > > But then "env" would need to be passed explicitly. I don't think the churn is worth it. > And a method would then need a .m or .c file ... But that could be merged to the CallXXXMethod and placed somewhere in the libosxapp >> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 182: >> >>> 180: #define CHECK_EXCEPTION() \ >>> 181: if ((*env)->ExceptionOccurred(env) != NULL) { \ >>> 182: if ([NSThread isMainThread] == YES) { \ >> >> Isn't it is a similar code to the >> https://github.com/openjdk/jdk/blob/67c221148159d94142a3a6d9ddadce2dff8c858b/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L334 >> Where we just catch an exception log it, and continue to run our infinite loop? Why do we need to do something specific here? I mean we cannot drop any try/catch blocks anyway since an nsexception may be generated by some external system code. > > In my testing that code does not get called. The new code does. So the old code could probably be deleted as useless but it is also harmless and just maybe it'll catch something else, even if it isn't doing anything that I can see. That code for sure should be called, it is even improved recently by JDK-8255681 I'll check how it was intended to work. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Sat Jan 9 01:33:06 2021 From: prr at openjdk.java.net (Phil Race) Date: Sat, 9 Jan 2021 01:33:06 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: <2MhWS44-i0zX8lt6BUh_dpOxsEQdYnifCB8dcqO_25E=.319e2c92-6bf1-40fa-86a6-5d9df8c6c27e@github.com> On Fri, 8 Jan 2021 04:40:36 GMT, Sergey Bylokhov wrote: >> But then "env" would need to be passed explicitly. I don't think the churn is worth it. >> And a method would then need a .m or .c file ... > > But that could be merged to the CallXXXMethod and placed somewhere in the libosxapp You mean those methods or macros that we already discussed and I explained why I do not want to do that ? This is a small update for error checking not revisiting everything done before. >> I don't think "most" of the time is very likely. JNI lookup failures don't cause exceptions to be thrown. >> Is that what you are tihinking ? >> >> And separately, with either the current code of clearing exceptions or the change here to the practice of throwing NSException on seeing a Java Exception I think it very unlikely. > > Then how we get NoSuchMethodError here? https://bugs.openjdk.java.net/browse/JDK-8259232? > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetMethodID > Calling Instance Methods: GetMethodID > RETURNS: > Returns a method ID, or NULL if the specified method cannot be found. > THROWS: > NoSuchMethodError: if the specified method cannot be found. > ExceptionInInitializerError: if the class initializer fails due to an exception. > OutOfMemoryError: if the system runs out of memory. > > Same for fields: > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetFieldID Ok. I will only create my own if none is pending. >> In my testing that code does not get called. The new code does. So the old code could probably be deleted as useless but it is also harmless and just maybe it'll catch something else, even if it isn't doing anything that I can see. > > That code for sure should be called, it is even improved recently by JDK-8255681 > I'll check how it was intended to work. I hadn't noticed that line - and definintely not realised it was recent. I suppose he must have had a way to trigger it. But I don't think it hurts to have both. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Sat Jan 9 01:33:07 2021 From: prr at openjdk.java.net (Phil Race) Date: Sat, 9 Jan 2021 01:33:07 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race wrote: > Proposed updates to JNI error handling. src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 46: > 44: if ((*env)->ExceptionOccurred(env) != NULL) { \ > 45: (*env)->ExceptionDescribe(env); \ > 46: } \ So the update here is that if we are not on the appkit thread, make sure a java exception is thrown. If we are on the appkit thread, clear any java exception since it isn't going anywhere but do it using describe which prints it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From ysuenaga at openjdk.java.net Sat Jan 9 02:02:12 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 9 Jan 2021 02:02:12 GMT Subject: RFR: 8258925: configure script failed on WSL [v4] In-Reply-To: References: Message-ID: > I ran configure script on WSL 1, but it failed as below: > > $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 > > : > > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java > configure exiting with result code 1 > > `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Refactoring ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1889/files - new: https://git.openjdk.java.net/jdk/pull/1889/files/37498adf..1294adde Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1889&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1889&range=02-03 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1889/head:pull/1889 PR: https://git.openjdk.java.net/jdk/pull/1889 From ysuenaga at openjdk.java.net Sat Jan 9 02:04:53 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 9 Jan 2021 02:04:53 GMT Subject: RFR: 8258925: configure script failed on WSL [v3] In-Reply-To: <-6nKkp0jFQgv1fsM97Xvqspo85onsg7eHq0Copnm6tA=.b6b25e2e-99c6-4d5b-9c28-b2b1ef30f214@github.com> References: <-6nKkp0jFQgv1fsM97Xvqspo85onsg7eHq0Copnm6tA=.b6b25e2e-99c6-4d5b-9c28-b2b1ef30f214@github.com> Message-ID: <1BiqezvzkGeCuP8TG0wYS0rhmdGkoerI-xI6Vg4YWM4=.4867ef1e-4500-4fde-a12f-b115c465d66d@github.com> On Fri, 8 Jan 2021 14:57:16 GMT, Erik Joelsson wrote: > In this case, I think introducing a variable is well worth it as it means we can eliminate a very common and unnecessary call to $PATHTOOL. Ok, I pushed new commit to use `$unixpath` instead of calling `$PATHTOOL`. Could you review again? @dholmes-ora Are you still ok this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From dholmes at openjdk.java.net Sat Jan 9 09:24:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 9 Jan 2021 09:24:56 GMT Subject: RFR: 8258925: configure script failed on WSL [v4] In-Reply-To: References: Message-ID: <6qRSullcqWemuD4QImhNtm3lbBKUy9UKN8eLDJq5ruk=.59d6d05c-fd67-4377-a22c-92d4639cdc8a@github.com> On Sat, 9 Jan 2021 02:02:12 GMT, Yasumasa Suenaga wrote: >> I ran configure script on WSL 1, but it failed as below: >> >> $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 >> >> : >> >> configure: Found potential Boot JDK using configure arguments >> configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. >> configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java >> configure exiting with result code 1 >> >> `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring I _think_ this is right but to be honest the multitude of variables adds to the confusion for me. David make/scripts/fixpath.sh line 155: > 153: if [[ $? -ne 0 ]]; then > 154: unixpath="$unixpath.exe" > 155: winpath="$($PATHTOOL -w "$path.exe" 2>/dev/null)" I think it would be a little cleaner/clearer to use unixpath on line 155. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1889 From ysuenaga at openjdk.java.net Sat Jan 9 13:33:57 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 9 Jan 2021 13:33:57 GMT Subject: RFR: 8258925: configure script failed on WSL [v4] In-Reply-To: <6qRSullcqWemuD4QImhNtm3lbBKUy9UKN8eLDJq5ruk=.59d6d05c-fd67-4377-a22c-92d4639cdc8a@github.com> References: <6qRSullcqWemuD4QImhNtm3lbBKUy9UKN8eLDJq5ruk=.59d6d05c-fd67-4377-a22c-92d4639cdc8a@github.com> Message-ID: <7LgEE7i7wUg1zCsIXkYn_aVu-vh38ejNYkDFQp-MCP8=.c1d7168d-622e-41e1-8687-e0ffd14db22e@github.com> On Sat, 9 Jan 2021 09:21:20 GMT, David Holmes wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactoring > > make/scripts/fixpath.sh line 155: > >> 153: if [[ $? -ne 0 ]]; then >> 154: unixpath="$unixpath.exe" >> 155: winpath="$($PATHTOOL -w "$path.exe" 2>/dev/null)" > > I think it would be a little cleaner/clearer to use unixpath on line 155. We will check the result from `$PATHTOOL` at L154, so I think current location is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From david.holmes at oracle.com Sat Jan 9 13:37:46 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 9 Jan 2021 23:37:46 +1000 Subject: RFR: 8258925: configure script failed on WSL [v4] In-Reply-To: <7LgEE7i7wUg1zCsIXkYn_aVu-vh38ejNYkDFQp-MCP8=.c1d7168d-622e-41e1-8687-e0ffd14db22e@github.com> References: <6qRSullcqWemuD4QImhNtm3lbBKUy9UKN8eLDJq5ruk=.59d6d05c-fd67-4377-a22c-92d4639cdc8a@github.com> <7LgEE7i7wUg1zCsIXkYn_aVu-vh38ejNYkDFQp-MCP8=.c1d7168d-622e-41e1-8687-e0ffd14db22e@github.com> Message-ID: On 9/01/2021 11:33 pm, Yasumasa Suenaga wrote: > On Sat, 9 Jan 2021 09:21:20 GMT, David Holmes wrote: > >>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Refactoring >> >> make/scripts/fixpath.sh line 155: >> >>> 153: if [[ $? -ne 0 ]]; then >>> 154: unixpath="$unixpath.exe" >>> 155: winpath="$($PATHTOOL -w "$path.exe" 2>/dev/null)" >> >> I think it would be a little cleaner/clearer to use unixpath on line 155. > > We will check the result from `$PATHTOOL` at L154, so I think current location is fine. I'm not at all sure what you mean by the reference to PATHTOOL here, so to be clear I was suggesting writing line 155 as: winpath="$($PATHTOOL -w "$unixpath" 2>/dev/null)" David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1889 > From ysuenaga at openjdk.java.net Sat Jan 9 14:05:10 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 9 Jan 2021 14:05:10 GMT Subject: RFR: 8258925: configure script failed on WSL [v5] In-Reply-To: References: Message-ID: > I ran configure script on WSL 1, but it failed as below: > > $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 > > : > > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java > configure exiting with result code 1 > > `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Use "unixpath" instead of "path" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1889/files - new: https://git.openjdk.java.net/jdk/pull/1889/files/1294adde..01dcf16f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1889&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1889&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1889/head:pull/1889 PR: https://git.openjdk.java.net/jdk/pull/1889 From ysuenaga at openjdk.java.net Sat Jan 9 14:05:11 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 9 Jan 2021 14:05:11 GMT Subject: RFR: 8258925: configure script failed on WSL [v4] In-Reply-To: <6qRSullcqWemuD4QImhNtm3lbBKUy9UKN8eLDJq5ruk=.59d6d05c-fd67-4377-a22c-92d4639cdc8a@github.com> References: <6qRSullcqWemuD4QImhNtm3lbBKUy9UKN8eLDJq5ruk=.59d6d05c-fd67-4377-a22c-92d4639cdc8a@github.com> Message-ID: On Sat, 9 Jan 2021 09:22:40 GMT, David Holmes wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactoring > > I _think_ this is right but to be honest the multitude of variables adds to the confusion for me. > > David > > > I think it would be a little cleaner/clearer to use unixpath on line 155. > > > > > > We will check the result from `$PATHTOOL` at L154, so I think current location is fine. > > I'm not at all sure what you mean by the reference to PATHTOOL here, so > to be clear I was suggesting writing line 155 as: > > winpath="$($PATHTOOL -w "$unixpath" 2>/dev/null)" Ah, I misunderstood. I fixed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From github.com+16932759+shqking at openjdk.java.net Mon Jan 11 02:14:17 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Mon, 11 Jan 2021 02:14:17 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v5] In-Reply-To: References: Message-ID: > 1. '-Wdeprecated-copy' > As specified in C++11 [1], "the generation of the implicitly-defined > copy constructor is deprecated if T has a user-defined destructor or > user-defined copy assignment operator". The rationale behind is the > well-known Rule of Three [2]. > > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' > warns about the C++11 deprecation of implicitly declared copy > constructor and assignment operator if one of them is user-provided. > Defining an explicit copy constructor would suppress this warning. > > The main reason why debug build with gcc-9 or higher succeeds lies in > the inconsistent warning behaviors between gcc and clang. See the > reduced code example [5]. We suspect it might be return value > optimization/copy elision [6] that drives gcc not to declare implicit > copy constructor for this case. > > Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise > warnings for deprecated defintions of copy constructors. However, > '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 > and clang-9 are not affected. > > ~~2. '-Wimplicit-int-float-conversion'~~ > ~~Making the conversion explicit would fix it.~~ > > ~~Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.~~ > ~~Therefore clang-8 and clang-9 are not affected. The flag with similar~~ > ~~functionality in gcc is '-Wfloat-conversion', but it is not enabled by~~ > ~~'-Wall' or '-Wextra'. That's why this warning does not apprear when~~ > ~~building with gcc.~~ > > [1] https://en.cppreference.com/w/cpp/language/copy_constructor > [2] https://en.cppreference.com/w/cpp/language/rule_of_three > [3] https://www.gnu.org/software/gcc/gcc-9/changes.html > [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html > [5] https://godbolt.org/z/err4jM > [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization > > > Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. > Note that '--with-extra-cxxflags=-Wno-implicit-int-float-conversion' should be added when configuration. It's another issue (See JDK-8259288) Hao Sun has updated the pull request incrementally with one additional commit since the last revision: Define the copy assign operator of class DUIterator_Last as defaulted The copy assignment operator of class DUIterator_Last should also be defined as defaulted, i.e. =default, keeping consistent with the copy constructor. Besides, fix the NIT for the copy ctor definition of class DUIterator_Last. Change-Id: I2f9502f023443163910eea9469b72df5bf1e25e0 CustomizedGitHooks: yes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1874/files - new: https://git.openjdk.java.net/jdk/pull/1874/files/4cc18217..5c8195b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1874&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1874&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1874/head:pull/1874 PR: https://git.openjdk.java.net/jdk/pull/1874 From kbarrett at openjdk.java.net Mon Jan 11 02:44:58 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 11 Jan 2021 02:44:58 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v5] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 02:14:17 GMT, Hao Sun wrote: >> 1. '-Wdeprecated-copy' >> As specified in C++11 [1], "the generation of the implicitly-defined >> copy constructor is deprecated if T has a user-defined destructor or >> user-defined copy assignment operator". The rationale behind is the >> well-known Rule of Three [2]. >> >> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' >> warns about the C++11 deprecation of implicitly declared copy >> constructor and assignment operator if one of them is user-provided. >> Defining an explicit copy constructor would suppress this warning. >> >> The main reason why debug build with gcc-9 or higher succeeds lies in >> the inconsistent warning behaviors between gcc and clang. See the >> reduced code example [5]. We suspect it might be return value >> optimization/copy elision [6] that drives gcc not to declare implicit >> copy constructor for this case. >> >> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise >> warnings for deprecated defintions of copy constructors. However, >> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 >> and clang-9 are not affected. >> >> ~~2. '-Wimplicit-int-float-conversion'~~ >> ~~Making the conversion explicit would fix it.~~ >> >> ~~Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.~~ >> ~~Therefore clang-8 and clang-9 are not affected. The flag with similar~~ >> ~~functionality in gcc is '-Wfloat-conversion', but it is not enabled by~~ >> ~~'-Wall' or '-Wextra'. That's why this warning does not apprear when~~ >> ~~building with gcc.~~ >> >> [1] https://en.cppreference.com/w/cpp/language/copy_constructor >> [2] https://en.cppreference.com/w/cpp/language/rule_of_three >> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html >> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html >> [5] https://godbolt.org/z/err4jM >> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization >> >> >> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. >> Note that '--with-extra-cxxflags=-Wno-implicit-int-float-conversion' should be added when configuration. It's another issue (See JDK-8259288) > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Define the copy assign operator of class DUIterator_Last as defaulted > > The copy assignment operator of class DUIterator_Last should also be > defined as defaulted, i.e. =default, keeping consistent with the copy > constructor. > > Besides, fix the NIT for the copy ctor definition of class > DUIterator_Last. > > Change-Id: I2f9502f023443163910eea9469b72df5bf1e25e0 > CustomizedGitHooks: yes Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From jai.forums2013 at gmail.com Mon Jan 11 04:43:53 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 11 Jan 2021 10:13:53 +0530 Subject: JDK building from source - Prevent user name leaking into the generated binary? Message-ID: <965fa00f-7dc5-7611-2b36-6bde4a29680e@gmail.com> I build the JDK from source using "make images". When I use that JDK binary, the user name of the user who built the binary "leaks" into some of the runtime system properties and (of course as a result) into the output of java -version. Here's the output of java -version of such a built JDK: openjdk version "16-internal" 2021-03-16 OpenJDK Runtime Environment (build 16-internal+0-adhoc.jaikiran.jdk16) OpenJDK 64-Bit Server VM (build 16-internal+0-adhoc.jaikiran.jdk16, mixed mode, sharing) Notice the "jaikiran" in that output - that's the user name who built the JDK. Furthermore, this also ends up in runtime properties like: java.runtime.version = 16-internal+0-adhoc.jaikiran.jdk16 ... java.vm.version = 16-internal+0-adhoc.jaikiran.jdk16 Is there a way/option that I can use while building the JDK that will prevent this user name leaking into the built binary? Better still can that option be the default? -Jaikiran From serb at openjdk.java.net Mon Jan 11 06:07:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 11 Jan 2021 06:07:57 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race wrote: > Proposed updates to JNI error handling. src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41: > 39: NSLog(@"%@",[NSThread callStackSymbols]); \ > 40: if ([NSThread isMainThread] == NO) { \ > 41: if ((*env)->ExceptionOccurred(env) == NULL) { \ Not sure that the check for ExceptionOccurred is needed, in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example : https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357 Note that the exception in the static initializer is fatal for the application. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Mon Jan 11 06:07:59 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 11 Jan 2021 06:07:59 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: <7RahvO2lHhxOAhcIdk2_pqtsbqdelLHRSXeAin2ZnQY=.0aaa2356-c382-46e7-83be-99ec143ee8ff@github.com> On Fri, 8 Jan 2021 19:05:09 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 46: > >> 44: if ((*env)->ExceptionOccurred(env) != NULL) { \ >> 45: (*env)->ExceptionDescribe(env); \ >> 46: } \ > > So the update here is that if we are not on the appkit thread, make sure a java exception is thrown. > If we are on the appkit thread, clear any java exception since it isn't going anywhere but do it using > describe which prints it. I read the logic of the method differently, probably the wrong indents? - If we are not on the toolkit thread then - Check ExceptionOccurred -> throw JNU_ThrowInternalError if needed or check exception again ->call ExceptionDescribe - NSException raise at the end. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Mon Jan 11 06:08:00 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 11 Jan 2021 06:08:00 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: <2MhWS44-i0zX8lt6BUh_dpOxsEQdYnifCB8dcqO_25E=.319e2c92-6bf1-40fa-86a6-5d9df8c6c27e@github.com> References: <2MhWS44-i0zX8lt6BUh_dpOxsEQdYnifCB8dcqO_25E=.319e2c92-6bf1-40fa-86a6-5d9df8c6c27e@github.com> Message-ID: On Fri, 8 Jan 2021 19:17:17 GMT, Phil Race wrote: >> That code for sure should be called, it is even improved recently by JDK-8255681 >> I'll check how it was intended to work. > > I hadn't noticed that line - and definintely not realised it was recent. > I suppose he must have had a way to trigger it. > But I don't think it hurts to have both. I just tried to understand why we need to complicate this, to me, it is unclear why handling the same errors in the NSApplicationAWT.m does not work. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From david.holmes at oracle.com Mon Jan 11 06:32:57 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Jan 2021 16:32:57 +1000 Subject: JDK building from source - Prevent user name leaking into the generated binary? In-Reply-To: <965fa00f-7dc5-7611-2b36-6bde4a29680e@gmail.com> References: <965fa00f-7dc5-7611-2b36-6bde4a29680e@gmail.com> Message-ID: <61e2506d-b984-a9ce-e546-27f708eaa1cf@oracle.com> Hi Jaikiran, On 11/01/2021 2:43 pm, Jaikiran Pai wrote: > I build the JDK from source using "make images". When I use that JDK > binary, the user name of the user who built the binary "leaks" into some > of the runtime system properties and (of course as a result) into the > output of java -version. Here's the output of java -version of such a > built JDK: > > > openjdk version "16-internal" 2021-03-16 > OpenJDK Runtime Environment (build 16-internal+0-adhoc.jaikiran.jdk16) > OpenJDK 64-Bit Server VM (build 16-internal+0-adhoc.jaikiran.jdk16, > mixed mode, sharing) > > > Notice the "jaikiran" in that output - that's the user name who built > the JDK. Furthermore, this also ends up in runtime properties like: > > > java.runtime.version = 16-internal+0-adhoc.jaikiran.jdk16 > ... > java.vm.version = 16-internal+0-adhoc.jaikiran.jdk16 > > > Is there a way/option that I can use while building the JDK that will > prevent this user name leaking into the built binary? Yes. You have full control over the version string at configure time. See: make/autoconf/jdk-version.m4 As the format of the version string is controlled by a JEP and has a lot of rules there are actually quite a number of configure flags that can affect the version string. Your simplest option may just be to use --with-version-string="your version string". If you like most of the defaults but not the user name you may be able to override that simply by changing USER in your environment when running configure. > Better still can that option be the default? Not in my opinion. :) We find it useful to see what binary was used in detail. Cheers, David > > -Jaikiran > > From ihse at openjdk.java.net Mon Jan 11 07:40:55 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 07:40:55 GMT Subject: Integrated: 8258449: Move make/hotspot/symbols to make/data In-Reply-To: <5xNHtr0piHsmCR5c17c1zzwfeAdUK1YxzrrulIXcy5w=.88bfdc68-de83-41c7-9fc6-2e69ded5bfa2@github.com> References: <5xNHtr0piHsmCR5c17c1zzwfeAdUK1YxzrrulIXcy5w=.88bfdc68-de83-41c7-9fc6-2e69ded5bfa2@github.com> Message-ID: On Tue, 15 Dec 2020 23:38:02 GMT, Magnus Ihse Bursie wrote: > The "symbol" files in make/hotspot/symbols are a list of exported symbols from libjvm. As such, they are an essential data source for the build system, and they should reside in make/data, not mixed with the hotspot make source code. This pull request has now been integrated. Changeset: d21a0ea1 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/d21a0ea1 Stats: 6 lines in 7 files changed: 0 ins; 0 del; 6 mod 8258449: Move make/hotspot/symbols to make/data Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/1793 From ihse at openjdk.java.net Mon Jan 11 07:47:06 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 07:47:06 GMT Subject: Integrated: 8258445: Move make/templates to make/data In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:15:23 GMT, Magnus Ihse Bursie wrote: > The `templates` directory in `make` is an odd bird. It actually contains data files that the license checker needs, so it should move to `make/data`. This pull request has now been integrated. Changeset: bd344184 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/bd344184 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod 8258445: Move make/templates to make/data Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/1790 From jai.forums2013 at gmail.com Mon Jan 11 07:58:39 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 11 Jan 2021 13:28:39 +0530 Subject: JDK building from source - Prevent user name leaking into the generated binary? In-Reply-To: <61e2506d-b984-a9ce-e546-27f708eaa1cf@oracle.com> References: <965fa00f-7dc5-7611-2b36-6bde4a29680e@gmail.com> <61e2506d-b984-a9ce-e546-27f708eaa1cf@oracle.com> Message-ID: Hello David, On 11/01/21 12:02 pm, David Holmes wrote: > Hi Jaikiran, > > On 11/01/2021 2:43 pm, Jaikiran Pai wrote: >> I build the JDK from source using "make images". When I use that JDK >> binary, the user name of the user who built the binary "leaks" into >> some of the runtime system properties and (of course as a result) >> into the output of java -version. Here's the output of java -version >> of such a built JDK: >> >> >> openjdk version "16-internal" 2021-03-16 >> OpenJDK Runtime Environment (build 16-internal+0-adhoc.jaikiran.jdk16) >> OpenJDK 64-Bit Server VM (build 16-internal+0-adhoc.jaikiran.jdk16, >> mixed mode, sharing) >> >> >> Notice the "jaikiran" in that output - that's the user name who built >> the JDK. Furthermore, this also ends up in runtime properties like: >> >> >> java.runtime.version = 16-internal+0-adhoc.jaikiran.jdk16 >> ... >> java.vm.version = 16-internal+0-adhoc.jaikiran.jdk16 >> >> >> Is there a way/option that I can use while building the JDK that will >> prevent this user name leaking into the built binary? > > Yes. You have full control over the version string at configure time. > See: > > make/autoconf/jdk-version.m4 > > As the format of the version string is controlled by a JEP and has a > lot of rules there are actually quite a number of configure flags that > can affect the version string. Your simplest option may just be to use > --with-version-string="your version string". Thank you for pointing to me that file. Yes, this option is good enough for me to override the default one. > >> Better still can that option be the default? > > Not in my opinion. :) We find it useful to see what binary was used in > detail. Fair enough :) -Jaikiran From ihse at openjdk.java.net Mon Jan 11 09:23:11 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 09:23:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: Message-ID: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> On Mon, 4 Jan 2021 21:20:53 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Update comment refering to "make" dir >> - Move new symbols to jdk.compiler >> - Merge branch 'master' into shuffle-data >> - Move macosxicons from share to macosx >> - Move to share/data, and move jdwp.spec to java.se >> - Update references in test >> - Step 2: Update references >> - First stage, move actual data files > > Marked as reviewed by prr (Reviewer). This PR is not stale; it's just still waiting for input from @AlanBateman. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From jlahoda at openjdk.java.net Mon Jan 11 10:15:06 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 11 Jan 2021 10:15:06 GMT Subject: Integrated: JDK-8250768: javac should be adapted to changes in JEP 12 In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda wrote: > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 This pull request has now been integrated. Changeset: 23548821 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/23548821 Stats: 3802 lines in 133 files changed: 2724 ins; 695 del; 383 mod 8250768: javac should be adapted to changes in JEP 12 Reviewed-by: mcimadamore, erikj, jjg, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From ihse at openjdk.java.net Mon Jan 11 11:16:05 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 11:16:05 GMT Subject: RFR: 8259559: COMPARE_BUILD can't compare patch files Message-ID: COMPARE_BUILD will fail to run the compare stage, since re-applying an applied patch does not work. ------------- Commit messages: - 8259559: COMPARE_BUILD can't compare patch files Changes: https://git.openjdk.java.net/jdk/pull/2025/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2025&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259559 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2025.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2025/head:pull/2025 PR: https://git.openjdk.java.net/jdk/pull/2025 From ihse at openjdk.java.net Mon Jan 11 11:18:03 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 11:18:03 GMT Subject: RFR: 8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk [v3] In-Reply-To: <_PStifoVHZV-wGaQBGatxmFA2EwEA0HQcrVHO8eL9F8=.46ed09a4-0dcf-4eb1-9411-f36d6835ed6f@github.com> References: <9xkNifNu1u9_edtzKO1GsygtwNwAM91k1o6iaw0KvS4=.c0c96c97-c13f-4f1b-97fe-a79abace039c@github.com> <_PStifoVHZV-wGaQBGatxmFA2EwEA0HQcrVHO8eL9F8=.46ed09a4-0dcf-4eb1-9411-f36d6835ed6f@github.com> Message-ID: On Mon, 4 Jan 2021 15:16:35 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Final bug fixes... > > Marked as reviewed by erikj (Reviewer). @erikj79 Actually, I had not done that. But it was a great idea. Now I have, and it looks good. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/1779 From ihse at openjdk.java.net Mon Jan 11 11:33:19 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 11:33:19 GMT Subject: Integrated: 8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 13:11:30 GMT, Magnus Ihse Bursie wrote: > Right now `CompileJavaModules.gmk` contains two different part: one part with the functionality needed to compile a java module, and one part were all special requirements for all modules are listed. > > The second part should be removed from `CompileJavaModules.gmk`, and instead listed directly for each individual module in `make/modules/$M/Java.gmk`. > > I used a special-written shell script to automatically extract the module-specific part from CompileJavaModules.gmk into the respective Java.gmk files, to avoid risking any hard-to-detect copy/paste errors. After this I did a `sed -i` to remove the module-specific prefix. All this makes me confident that I have correctly moved the variables (I realize this is hard to verify from the patch). This pull request has now been integrated. Changeset: 1bd015fb Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/1bd015fb Stats: 2118 lines in 47 files changed: 1556 ins; 548 del; 14 mod 8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/1779 From ihse at openjdk.java.net Mon Jan 11 11:33:17 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 11:33:17 GMT Subject: RFR: 8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk [v4] In-Reply-To: References: Message-ID: > Right now `CompileJavaModules.gmk` contains two different part: one part with the functionality needed to compile a java module, and one part were all special requirements for all modules are listed. > > The second part should be removed from `CompileJavaModules.gmk`, and instead listed directly for each individual module in `make/modules/$M/Java.gmk`. > > I used a special-written shell script to automatically extract the module-specific part from CompileJavaModules.gmk into the respective Java.gmk files, to avoid risking any hard-to-detect copy/paste errors. After this I did a `sed -i` to remove the module-specific prefix. All this makes me confident that I have correctly moved the variables (I realize this is hard to verify from the patch). Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' of https://git.openjdk.java.net/jdk into modularize-java-part - Final bug fixes... - Rename DISABLED_WARNINGS to DISABLED_WARNINGS_java to avoid overwriting the global variable - $($(MODULE)_COPY_EXTRA) target is not used anymore - Remove module prefix from java variables - Remove debug code mistakenly pushed - Move some more module-specific stuff to Java.gmk files - Only include the module Java.gmk file we need - First step: break out Java settings to separate files ------------- Changes: https://git.openjdk.java.net/jdk/pull/1779/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1779&range=03 Stats: 2118 lines in 47 files changed: 1556 ins; 548 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1779.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1779/head:pull/1779 PR: https://git.openjdk.java.net/jdk/pull/1779 From shade at openjdk.java.net Mon Jan 11 13:48:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 13:48:59 GMT Subject: [jdk16] RFR: 8259043: More Zero architectures need linkage with libatomic In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 18:42:05 GMT, Erik Joelsson wrote: >> JDK-8256831 added the Zero linkage with libatomic for MIPS, but there are other 32-bit Zero platforms that need the same kind of treatment. >> >> Additional testing: >> - [x] linux-mipsel-zero-fastdebug build > > Marked as reviewed by erikj (Reviewer). Matthias reports (privately) that Zero arches still build in Debian with this patch. Integrating. ------------- PR: https://git.openjdk.java.net/jdk16/pull/76 From shade at openjdk.java.net Mon Jan 11 13:49:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 13:49:00 GMT Subject: [jdk16] Integrated: 8259043: More Zero architectures need linkage with libatomic In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 08:34:02 GMT, Aleksey Shipilev wrote: > JDK-8256831 added the Zero linkage with libatomic for MIPS, but there are other 32-bit Zero platforms that need the same kind of treatment. > > Additional testing: > - [x] linux-mipsel-zero-fastdebug build This pull request has now been integrated. Changeset: e05f36f4 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16/commit/e05f36f4 Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod 8259043: More Zero architectures need linkage with libatomic Co-authored-by: Matthias Klose Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk16/pull/76 From erikj at openjdk.java.net Mon Jan 11 14:02:56 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Jan 2021 14:02:56 GMT Subject: RFR: 8258925: configure script failed on WSL [v5] In-Reply-To: References: Message-ID: On Sat, 9 Jan 2021 14:05:10 GMT, Yasumasa Suenaga wrote: >> I ran configure script on WSL 1, but it failed as below: >> >> $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 >> >> : >> >> configure: Found potential Boot JDK using configure arguments >> configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. >> configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java >> configure exiting with result code 1 >> >> `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Use "unixpath" instead of "path" This looks good to me. Thanks! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1889 From erikj at openjdk.java.net Mon Jan 11 14:26:00 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Jan 2021 14:26:00 GMT Subject: RFR: 8259559: COMPARE_BUILD can't compare patch files In-Reply-To: References: Message-ID: <641rjOIQH7HCL_Fy1oiI0m60uNz0y9NKxeytQqI5KRU=.a05299bc-d4c7-4f15-ac4a-24d28dc16613@github.com> On Mon, 11 Jan 2021 11:11:01 GMT, Magnus Ihse Bursie wrote: > COMPARE_BUILD will fail to run the compare stage, since re-applying an applied patch does not work. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2025 From martin.doerr at sap.com Mon Jan 11 16:08:24 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 11 Jan 2021 16:08:24 +0000 Subject: [11u] RFR: 8256810: Incremental rebuild broken on Macosx Message-ID: Hi, JDK-8256810 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly because of an unlrelated context change (Solaris removal). Bug: https://bugs.openjdk.java.net/browse/JDK-8256810 Original change: https://github.com/openjdk/jdk/commit/4c86e46d 11u backport: http://cr.openjdk.java.net/~mdoerr/8256810_build_11u/webrev.00/ Please review. Best regards, Martin From rwestrel at redhat.com Mon Jan 11 16:16:03 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 11 Jan 2021 17:16:03 +0100 Subject: [11u] RFR: 8256810: Incremental rebuild broken on Macosx In-Reply-To: References: Message-ID: <877dojbgak.fsf@redhat.com> Hi Martin, > JDK-8256810 is backported to 11.0.11-oracle. I'd like to backport it for parity. > Change doesn't apply cleanly because of an unlrelated context change (Solaris removal). See my RFR for the backport of 8257547. It basically replaces all of that code. Roland. From martin.doerr at sap.com Mon Jan 11 16:34:34 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 11 Jan 2021 16:34:34 +0000 Subject: [11u] RFR: 8256810: Incremental rebuild broken on Macosx In-Reply-To: <877dojbgak.fsf@redhat.com> References: <877dojbgak.fsf@redhat.com> Message-ID: Hi Roland, thanks for letting me know. My plan was to backport both changes in the original order, but I'm fine if you do change to the new version at once. May I ask you to flag both issues as backported once you're done? Best regards, Martin > -----Original Message----- > From: Roland Westrelin > Sent: Montag, 11. Januar 2021 17:16 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net; build-dev at openjdk.java.net > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: Re: [11u] RFR: 8256810: Incremental rebuild broken on Macosx > > > Hi Martin, > > > JDK-8256810 is backported to 11.0.11-oracle. I'd like to backport it for parity. > > Change doesn't apply cleanly because of an unlrelated context change > (Solaris removal). > > See my RFR for the backport of 8257547. It basically replaces all of > that code. > > Roland. From rwestrel at redhat.com Mon Jan 11 16:40:07 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 11 Jan 2021 17:40:07 +0100 Subject: [11u] RFR: 8256810: Incremental rebuild broken on Macosx In-Reply-To: References: <877dojbgak.fsf@redhat.com> Message-ID: <871rerbf6g.fsf@redhat.com> > thanks for letting me know. My plan was to backport both changes in the original order, but I'm fine if you do change to the new version at once. > May I ask you to flag both issues as backported once you're done? Sure. Is a comment stating that this was backported what you have in mind? Would you mind reviewing my RFR given you've already taken a look at this area? Roland. From martin.doerr at sap.com Mon Jan 11 17:21:54 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 11 Jan 2021 17:21:54 +0000 Subject: [11u] RFR: 8256810: Incremental rebuild broken on Macosx In-Reply-To: <871rerbf6g.fsf@redhat.com> References: <877dojbgak.fsf@redhat.com> <871rerbf6g.fsf@redhat.com> Message-ID: Hi Roland, > Sure. Is a comment stating that this was backported what you have in mind? Preferrably comment + link "backportet by" to your backport issue. > Would you mind reviewing my RFR given you've already taken a look at > this area? I'll take a look. Best regards, Martin > -----Original Message----- > From: Roland Westrelin > Sent: Montag, 11. Januar 2021 17:40 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net; build-dev at openjdk.java.net > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: RE: [11u] RFR: 8256810: Incremental rebuild broken on Macosx > > > > thanks for letting me know. My plan was to backport both changes in the > original order, but I'm fine if you do change to the new version at once. > > May I ask you to flag both issues as backported once you're done? > > Sure. Is a comment stating that this was backported what you have in mind? > > Would you mind reviewing my RFR given you've already taken a look at > this area? > > Roland. From prr at openjdk.java.net Mon Jan 11 17:52:19 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 11 Jan 2021 17:52:19 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2] In-Reply-To: References: Message-ID: <5fPXj8SlcJcjfD9bwylmTZ7bR7Gia8CIDUFADlpcPAU=.6c25ea7c-89b8-4e70-8269-1cdb1bedb8d3@github.com> > Proposed updates to JNI error handling. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8259343: [macOS] Update JNI error handling in Cocoa code. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1967/files - new: https://git.openjdk.java.net/jdk/pull/1967/files/0e745aa6..08a41150 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1967&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1967&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1967.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1967/head:pull/1967 PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Mon Jan 11 17:52:19 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 11 Jan 2021 17:52:19 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2] In-Reply-To: References: Message-ID: <1-5L0YWqNPmuzpu1O1Q1chv5l1dGr55oEdQj4r9wyRg=.1addab94-3655-417d-8e03-1a621164502a@github.com> On Mon, 11 Jan 2021 05:52:02 GMT, Sergey Bylokhov wrote: > Not sure that the check for ExceptionOccurred is needed, It may not be needed in practice but if the code path is never taken no harm ... in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example : > > https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357 > > Note that the exception in the static initializer is fatal for the application. Nothing new here. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Mon Jan 11 17:52:20 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 11 Jan 2021 17:52:20 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2] In-Reply-To: <7RahvO2lHhxOAhcIdk2_pqtsbqdelLHRSXeAin2ZnQY=.0aaa2356-c382-46e7-83be-99ec143ee8ff@github.com> References: <7RahvO2lHhxOAhcIdk2_pqtsbqdelLHRSXeAin2ZnQY=.0aaa2356-c382-46e7-83be-99ec143ee8ff@github.com> Message-ID: On Mon, 11 Jan 2021 05:58:28 GMT, Sergey Bylokhov wrote: >> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 46: >> >>> 44: if ((*env)->ExceptionOccurred(env) != NULL) { \ >>> 45: (*env)->ExceptionDescribe(env); \ >>> 46: } \ >> >> So the update here is that if we are not on the appkit thread, make sure a java exception is thrown. >> If we are on the appkit thread, clear any java exception since it isn't going anywhere but do it using >> describe which prints it. > > I read the logic of the method differently, probably the wrong indents? > - If we are not on the toolkit thread then > - Check ExceptionOccurred -> throw JNU_ThrowInternalError if needed or check exception again ->call ExceptionDescribe > - NSException raise at the end. I have a paren in the wrong place ! I've pushed an update. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Mon Jan 11 17:52:20 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 11 Jan 2021 17:52:20 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2] In-Reply-To: References: <2MhWS44-i0zX8lt6BUh_dpOxsEQdYnifCB8dcqO_25E=.319e2c92-6bf1-40fa-86a6-5d9df8c6c27e@github.com> Message-ID: <3jqvTyJ_wKIDMURTmYQSbTCwUMcVRRvzvVekjS9Eem0=.866999d7-3542-4f3f-9e93-d6955b05a657@github.com> On Mon, 11 Jan 2021 06:01:36 GMT, Sergey Bylokhov wrote: >> I hadn't noticed that line - and definintely not realised it was recent. >> I suppose he must have had a way to trigger it. >> But I don't think it hurts to have both. > > I just tried to understand why we need to complicate this, to me, it is unclear why handling the same errors in the NSApplicationAWT.m does not work. Because of the reason I've said before. That logging in NSApplication AWT is not being seen. Something is swallowing it. So I'd say if anything remove that logging and keep the new one but as I also said it isn't harmful to have provision in case it also logs some case we aren't catching. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From ihse at openjdk.java.net Mon Jan 11 18:22:57 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 18:22:57 GMT Subject: Integrated: 8259559: COMPARE_BUILD can't compare patch files In-Reply-To: References: Message-ID: <9JriK4XXQXp3w5_PrJDogNslGRIj36vAHIq_SKWtN5w=.d3381922-39d5-457e-b29a-b16bb476fbce@github.com> On Mon, 11 Jan 2021 11:11:01 GMT, Magnus Ihse Bursie wrote: > COMPARE_BUILD will fail to run the compare stage, since re-applying an applied patch does not work. This pull request has now been integrated. Changeset: dab17875 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/dab17875 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8259559: COMPARE_BUILD can't compare patch files Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/2025 From ihse at openjdk.java.net Mon Jan 11 18:26:35 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 18:26:35 GMT Subject: RFR: 8258426: Split up autoconf/version-numbers and move it to conf dir [v3] In-Reply-To: References: Message-ID: > The file `make/autoconf/version-numbers` is plagued by a two-fold problem: first of all, it's a configuration file, not a part of autoconf, so it should reside in `make/conf` instead of `make/autoconf`. > > Secondly, contrary to the name, it does not only contain version numbers, but also the branding properties (company name, product name, etc). This should be split out into a separate branding configuration file. > > This is the last patch in the series of moving configuration into `make/conf`. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into version-numbers-to-conf - Also update submit.yml - 8258426: Split up autoconf/version-numbers and move it to conf dir ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1786/files - new: https://git.openjdk.java.net/jdk/pull/1786/files/bcd3b338..63162969 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1786&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1786&range=01-02 Stats: 51838 lines in 1653 files changed: 23670 ins; 14499 del; 13669 mod Patch: https://git.openjdk.java.net/jdk/pull/1786.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1786/head:pull/1786 PR: https://git.openjdk.java.net/jdk/pull/1786 From ihse at openjdk.java.net Mon Jan 11 18:26:37 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 18:26:37 GMT Subject: Integrated: 8258426: Split up autoconf/version-numbers and move it to conf dir In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 19:07:55 GMT, Magnus Ihse Bursie wrote: > The file `make/autoconf/version-numbers` is plagued by a two-fold problem: first of all, it's a configuration file, not a part of autoconf, so it should reside in `make/conf` instead of `make/autoconf`. > > Secondly, contrary to the name, it does not only contain version numbers, but also the branding properties (company name, product name, etc). This should be split out into a separate branding configuration file. > > This is the last patch in the series of moving configuration into `make/conf`. This pull request has now been integrated. Changeset: 38619602 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/38619602 Stats: 152 lines in 8 files changed: 81 ins; 55 del; 16 mod 8258426: Split up autoconf/version-numbers and move it to conf dir Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/1786 From erikj at openjdk.java.net Mon Jan 11 18:59:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Jan 2021 18:59:03 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2] In-Reply-To: <5fPXj8SlcJcjfD9bwylmTZ7bR7Gia8CIDUFADlpcPAU=.6c25ea7c-89b8-4e70-8269-1cdb1bedb8d3@github.com> References: <5fPXj8SlcJcjfD9bwylmTZ7bR7Gia8CIDUFADlpcPAU=.6c25ea7c-89b8-4e70-8269-1cdb1bedb8d3@github.com> Message-ID: On Mon, 11 Jan 2021 17:52:19 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8259343: [macOS] Update JNI error handling in Cocoa code. make/modules/java.desktop/Lib.gmk line 96: > 94: $(call SET_SHARED_LIBRARY_ORIGIN), \ > 95: LIBS := \ > 96: -ljava \ There should be a dependency declaration added too. Something like this right after the SetupJdkLibrary macro call: $(BUILD_LIBOSXAPP): $(call FindLib, java.base, java) ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Mon Jan 11 19:27:12 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 11 Jan 2021 19:27:12 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: Message-ID: > Proposed updates to JNI error handling. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8259343: [macOS] Update JNI error handling in Cocoa code. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1967/files - new: https://git.openjdk.java.net/jdk/pull/1967/files/08a41150..913b37c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1967&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1967&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1967.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1967/head:pull/1967 PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Mon Jan 11 19:27:12 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 11 Jan 2021 19:27:12 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2] In-Reply-To: References: <5fPXj8SlcJcjfD9bwylmTZ7bR7Gia8CIDUFADlpcPAU=.6c25ea7c-89b8-4e70-8269-1cdb1bedb8d3@github.com> Message-ID: On Mon, 11 Jan 2021 18:56:38 GMT, Erik Joelsson wrote: > There should be a dependency declaration added too. Something like this right after the SetupJdkLibrary macro call: > > $(BUILD_LIBOSXAPP): $(call FindLib, java.base, java) Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From erikj at openjdk.java.net Mon Jan 11 20:22:58 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Jan 2021 20:22:58 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: Message-ID: <9q6B-ZySWhc8qPfcn728cCehk_SSer-qtIhCJdI3sXg=.dce6e806-9858-481b-96a7-f27ed7d2bdb3@github.com> On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8259343: [macOS] Update JNI error handling in Cocoa code. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1967 From jwilhelm at openjdk.java.net Mon Jan 11 22:10:14 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 11 Jan 2021 22:10:14 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing - 8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl - 8259043: More Zero architectures need linkage with libatomic - 8259429: Update reference to README.md - 8259014: (so) ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress) will have unknown user and group owner (win) The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2040/files Stats: 140 lines in 12 files changed: 117 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2040.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2040/head:pull/2040 PR: https://git.openjdk.java.net/jdk/pull/2040 From ysuenaga at openjdk.java.net Mon Jan 11 23:17:58 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 11 Jan 2021 23:17:58 GMT Subject: Integrated: 8258925: configure script failed on WSL In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 08:04:34 GMT, Yasumasa Suenaga wrote: > I ran configure script on WSL 1, but it failed as below: > > $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1 > > : > > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java > configure exiting with result code 1 > > `fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists. This pull request has now been integrated. Changeset: 712ea250 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/712ea250 Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod 8258925: configure script failed on WSL Reviewed-by: dholmes, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/1889 From jwilhelm at openjdk.java.net Tue Jan 12 00:59:20 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 12 Jan 2021 00:59:20 GMT Subject: RFR: Merge jdk16 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 16 -> JDK 17 Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Merge ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2040/files - new: https://git.openjdk.java.net/jdk/pull/2040/files/e55da33b..69dad8ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2040.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2040/head:pull/2040 PR: https://git.openjdk.java.net/jdk/pull/2040 From jwilhelm at openjdk.java.net Tue Jan 12 01:10:59 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 12 Jan 2021 01:10:59 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 22:04:16 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: b378f54d Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/b378f54d Stats: 139 lines in 12 files changed: 116 ins; 2 del; 21 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2040 From github.com+16932759+shqking at openjdk.java.net Tue Jan 12 01:23:57 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 12 Jan 2021 01:23:57 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v4] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 00:49:36 GMT, Vladimir Kozlov wrote: >> Hao Sun has updated the pull request incrementally with one additional commit since the last revision: >> >> Split the PR, addressing -Wdeprecated-copy only >> >> As suggested by kimbarrett, we should focus on warnings produced by >> '-Wdeprecated-copy' in this PR. Because JDK-8259288 is a very different >> problem and might be reviewed by folks from different teams. >> >> Will create a new PR to address JDK-8259288. >> >> Change-Id: I1b9f434ab6fcdf2763a46870eaed91641984fd76 >> CustomizedGitHooks: yes > > Still good. @vnkozlov would you mind helping to review the latest commit (again)? Really appreciate it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From serb at openjdk.java.net Tue Jan 12 02:34:58 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Jan 2021 02:34:58 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8259343: [macOS] Update JNI error handling in Cocoa code. src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 197: > 195: } \ > 196: if (getenv("JNU_NO_COCOA_EXCEPTION") == NULL) { \ > 197: [NSException raise:NSGenericException format:@"Java Exception"]; \ How did you check that the logging in the NSApplication was swallowing? Both macro will throw the NSException on the toolkit thread now, does it mean that in both cases the logging in the NSApplication will be ignored/no output? ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Tue Jan 12 02:41:00 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Jan 2021 02:41:00 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: <1-5L0YWqNPmuzpu1O1Q1chv5l1dGr55oEdQj4r9wyRg=.1addab94-3655-417d-8e03-1a621164502a@github.com> References: <1-5L0YWqNPmuzpu1O1Q1chv5l1dGr55oEdQj4r9wyRg=.1addab94-3655-417d-8e03-1a621164502a@github.com> Message-ID: On Mon, 11 Jan 2021 17:09:14 GMT, Phil Race wrote: >> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41: >> >>> 39: NSLog(@"%@",[NSThread callStackSymbols]); \ >>> 40: if ([NSThread isMainThread] == NO) { \ >>> 41: if ((*env)->ExceptionOccurred(env) == NULL) { \ >> >> Not sure that the check for ExceptionOccurred is needed, in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example : >> https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357 >> >> Note that the exception in the static initializer is fatal for the application. > >> Not sure that the check for ExceptionOccurred is needed, > It may not be needed in practice but if the code path is never taken no harm ... > > in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example : >> >> https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357 >> >> Note that the exception in the static initializer is fatal for the application. > > Nothing new here. The new thing here is that you check the result of the ExceptionOccurred if NULL is returned from the GetMethodID/etc, we usually never do it. If such checks are necessary then I'll create a separate bug to update other similar use cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From github.com+7806504+liach at openjdk.java.net Tue Jan 12 06:52:03 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Tue, 12 Jan 2021 06:52:03 GMT Subject: RFR: 8259485: Document need for short paths when building on Windows Message-ID: Though this content seems simple, it would be extremely frustrating to newcomers, especially when the build stalls at "cannot find valid visual studio installation" for no clear reason in logs at all. ------------- Commit messages: - 8259485: Document need for short paths when building on Windows Changes: https://git.openjdk.java.net/jdk/pull/2043/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2043&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259485 Stats: 15 lines in 2 files changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2043.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2043/head:pull/2043 PR: https://git.openjdk.java.net/jdk/pull/2043 From rwestrel at redhat.com Tue Jan 12 08:18:11 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 12 Jan 2021 09:18:11 +0100 Subject: [11u] RFR: 8256810: Incremental rebuild broken on Macosx In-Reply-To: References: <877dojbgak.fsf@redhat.com> <871rerbf6g.fsf@redhat.com> Message-ID: <87v9c2a7r0.fsf@redhat.com> >> Sure. Is a comment stating that this was backported what you have in mind? > Preferrably comment + link "backportet by" to your backport issue. I'll do that once it's in. Roland. From erikj at openjdk.java.net Tue Jan 12 13:49:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 12 Jan 2021 13:49:53 GMT Subject: RFR: 8259485: Document need for short paths when building on Windows In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 06:46:33 GMT, liach wrote: > Though this content seems simple, it would be extremely frustrating to newcomers, especially when the build stalls at "cannot find valid visual studio installation" for no clear reason in logs at all. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2043 From ewhelan at openjdk.java.net Tue Jan 12 16:31:09 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 12 Jan 2021 16:31:09 GMT Subject: RFR: 8226810: Failed to launch JVM because of NullPointerException occurred on System.props Message-ID: Hi, Please review this small change which enables the GB18030 charset to be built into java.base Thanks ------------- Commit messages: - 8226810: Failed to launch JVM because of NullPointerException occurred on System.props Changes: https://git.openjdk.java.net/jdk/pull/2053/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2053&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8226810 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2053.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2053/head:pull/2053 PR: https://git.openjdk.java.net/jdk/pull/2053 From prr at openjdk.java.net Tue Jan 12 17:28:58 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 12 Jan 2021 17:28:58 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: <1-5L0YWqNPmuzpu1O1Q1chv5l1dGr55oEdQj4r9wyRg=.1addab94-3655-417d-8e03-1a621164502a@github.com> Message-ID: On Tue, 12 Jan 2021 02:38:11 GMT, Sergey Bylokhov wrote: >>> Not sure that the check for ExceptionOccurred is needed, >> It may not be needed in practice but if the code path is never taken no harm ... >> >> in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example : >>> >>> https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357 >>> >>> Note that the exception in the static initializer is fatal for the application. >> >> Nothing new here. > > The new thing here is that you check the result of the ExceptionOccurred if NULL is returned from the GetMethodID/etc, we usually never do it. If such checks are necessary then I'll create a separate bug to update other similar use cases. Here I don't have immediate control over why this is being called. So we could have null but no pending exception depending on what the caller did. It won't be executed except in the rare case there's a problem so it certainly isn't causing overhead so what is the problem ? I don't see a need to change other code unless there's a really good reason. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Tue Jan 12 17:24:57 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 12 Jan 2021 17:24:57 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 02:31:56 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8259343: [macOS] Update JNI error handling in Cocoa code. > > src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 197: > >> 195: } \ >> 196: if (getenv("JNU_NO_COCOA_EXCEPTION") == NULL) { \ >> 197: [NSException raise:NSGenericException format:@"Java Exception"]; \ > > How did you check that the logging in the NSApplication was swallowing? Both macro will throw the NSException on the toolkit thread now, does it mean that in both cases the logging in the NSApplication will be ignored/no output? See the bug assigned to you that I filed last month : https://bugs.openjdk.java.net/browse/JDK-8258797 This error should have been logged by that NSApplicationAWT code but was not (and I mean in JDK 16 as well before I started on this) and in JDK 17 it was seen only when adding the new logging. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From kvn at openjdk.java.net Tue Jan 12 18:58:00 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 12 Jan 2021 18:58:00 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v5] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 02:14:17 GMT, Hao Sun wrote: >> 1. '-Wdeprecated-copy' >> As specified in C++11 [1], "the generation of the implicitly-defined >> copy constructor is deprecated if T has a user-defined destructor or >> user-defined copy assignment operator". The rationale behind is the >> well-known Rule of Three [2]. >> >> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' >> warns about the C++11 deprecation of implicitly declared copy >> constructor and assignment operator if one of them is user-provided. >> Defining an explicit copy constructor would suppress this warning. >> >> The main reason why debug build with gcc-9 or higher succeeds lies in >> the inconsistent warning behaviors between gcc and clang. See the >> reduced code example [5]. We suspect it might be return value >> optimization/copy elision [6] that drives gcc not to declare implicit >> copy constructor for this case. >> >> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise >> warnings for deprecated defintions of copy constructors. However, >> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 >> and clang-9 are not affected. >> >> ~~2. '-Wimplicit-int-float-conversion'~~ >> ~~Making the conversion explicit would fix it.~~ >> >> ~~Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.~~ >> ~~Therefore clang-8 and clang-9 are not affected. The flag with similar~~ >> ~~functionality in gcc is '-Wfloat-conversion', but it is not enabled by~~ >> ~~'-Wall' or '-Wextra'. That's why this warning does not apprear when~~ >> ~~building with gcc.~~ >> >> [1] https://en.cppreference.com/w/cpp/language/copy_constructor >> [2] https://en.cppreference.com/w/cpp/language/rule_of_three >> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html >> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html >> [5] https://godbolt.org/z/err4jM >> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization >> >> >> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. >> Note that '--with-extra-cxxflags=-Wno-implicit-int-float-conversion' should be added when configuration. It's another issue (See JDK-8259288) > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Define the copy assign operator of class DUIterator_Last as defaulted > > The copy assignment operator of class DUIterator_Last should also be > defined as defaulted, i.e. =default, keeping consistent with the copy > constructor. > > Besides, fix the NIT for the copy ctor definition of class > DUIterator_Last. > > Change-Id: I2f9502f023443163910eea9469b72df5bf1e25e0 > CustomizedGitHooks: yes Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1874 From serb at openjdk.java.net Tue Jan 12 20:06:59 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Jan 2021 20:06:59 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 17:21:53 GMT, Phil Race wrote: >> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 197: >> >>> 195: } \ >>> 196: if (getenv("JNU_NO_COCOA_EXCEPTION") == NULL) { \ >>> 197: [NSException raise:NSGenericException format:@"Java Exception"]; \ >> >> How did you check that the logging in the NSApplication was swallowing? Both macro will throw the NSException on the toolkit thread now, does it mean that in both cases the logging in the NSApplication will be ignored/no output? > > See the bug assigned to you that I filed last month : https://bugs.openjdk.java.net/browse/JDK-8258797 > This error should have been logged by that NSApplicationAWT code but was not (and I mean in JDK 16 as well before I started on this) and in JDK 17 it was seen only when adding the new logging. I have found it down to the absence of NSApplication#reportException() method and logging in it. Ok will update that code later in the separate update. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Tue Jan 12 20:06:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Jan 2021 20:06:57 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: Message-ID: <9L-Z-lva8-afVWdri9YjO0wIM0nQ6H7IUOcruvNUToY=.33f942e9-23cb-43e7-a07d-b1fe64df4974@github.com> On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8259343: [macOS] Update JNI error handling in Cocoa code. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Tue Jan 12 20:22:57 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 12 Jan 2021 20:22:57 GMT Subject: Integrated: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race wrote: > Proposed updates to JNI error handling. This pull request has now been integrated. Changeset: d6a2105b Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/d6a2105b Stats: 75 lines in 8 files changed: 60 ins; 1 del; 14 mod 8259343: [macOS] Update JNI error handling in Cocoa code. Reviewed-by: erikj, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From github.com+16932759+shqking at openjdk.java.net Tue Jan 12 21:58:24 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Tue, 12 Jan 2021 21:58:24 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v5] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 02:42:09 GMT, Kim Barrett wrote: >> Hao Sun has updated the pull request incrementally with one additional commit since the last revision: >> >> Define the copy assign operator of class DUIterator_Last as defaulted >> >> The copy assignment operator of class DUIterator_Last should also be >> defined as defaulted, i.e. =default, keeping consistent with the copy >> constructor. >> >> Besides, fix the NIT for the copy ctor definition of class >> DUIterator_Last. >> >> Change-Id: I2f9502f023443163910eea9469b72df5bf1e25e0 >> CustomizedGitHooks: yes > > Marked as reviewed by kbarrett (Reviewer). Thanks a lot for your review @kimbarrett @vnkozlov . ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From shade at openjdk.java.net Wed Jan 13 08:05:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 08:05:56 GMT Subject: RFR: 8259485: Document need for short paths when building on Windows In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 06:46:33 GMT, liach wrote: > Though this content seems simple, it would be extremely frustrating to newcomers, especially when the build stalls at "cannot find valid visual studio installation" for no clear reason in logs at all. Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2043 From github.com+7806504+liach at openjdk.java.net Wed Jan 13 08:05:56 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 13 Jan 2021 08:05:56 GMT Subject: Integrated: 8259485: Document need for short paths when building on Windows In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 06:46:33 GMT, liach wrote: > Though this content seems simple, it would be extremely frustrating to newcomers, especially when the build stalls at "cannot find valid visual studio installation" for no clear reason in logs at all. This pull request has now been integrated. Changeset: 2243a170 Author: liach Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/2243a170 Stats: 15 lines in 2 files changed: 15 ins; 0 del; 0 mod 8259485: Document need for short paths when building on Windows Reviewed-by: erikj, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/2043 From github.com+16932759+shqking at openjdk.java.net Thu Jan 14 04:14:03 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Thu, 14 Jan 2021 04:14:03 GMT Subject: Integrated: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 01:45:58 GMT, Hao Sun wrote: > 1. '-Wdeprecated-copy' > As specified in C++11 [1], "the generation of the implicitly-defined > copy constructor is deprecated if T has a user-defined destructor or > user-defined copy assignment operator". The rationale behind is the > well-known Rule of Three [2]. > > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' > warns about the C++11 deprecation of implicitly declared copy > constructor and assignment operator if one of them is user-provided. > Defining an explicit copy constructor would suppress this warning. > > The main reason why debug build with gcc-9 or higher succeeds lies in > the inconsistent warning behaviors between gcc and clang. See the > reduced code example [5]. We suspect it might be return value > optimization/copy elision [6] that drives gcc not to declare implicit > copy constructor for this case. > > Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise > warnings for deprecated defintions of copy constructors. However, > '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 > and clang-9 are not affected. > > ~~2. '-Wimplicit-int-float-conversion'~~ > ~~Making the conversion explicit would fix it.~~ > > ~~Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.~~ > ~~Therefore clang-8 and clang-9 are not affected. The flag with similar~~ > ~~functionality in gcc is '-Wfloat-conversion', but it is not enabled by~~ > ~~'-Wall' or '-Wextra'. That's why this warning does not apprear when~~ > ~~building with gcc.~~ > > [1] https://en.cppreference.com/w/cpp/language/copy_constructor > [2] https://en.cppreference.com/w/cpp/language/rule_of_three > [3] https://www.gnu.org/software/gcc/gcc-9/changes.html > [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html > [5] https://godbolt.org/z/err4jM > [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization > > > Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. > Note that '--with-extra-cxxflags=-Wno-implicit-int-float-conversion' should be added when configuration. It's another issue (See JDK-8259288) This pull request has now been integrated. Changeset: 5513f989 Author: Hao Sun Committer: Ningsheng Jian URL: https://git.openjdk.java.net/jdk/commit/5513f989 Stats: 11 lines in 1 file changed: 8 ins; 1 del; 2 mod 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy Reviewed-by: xliu, kvn, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From github.com+16932759+shqking at openjdk.java.net Thu Jan 14 06:03:03 2021 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Thu, 14 Jan 2021 06:03:03 GMT Subject: RFR: 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 06:16:43 GMT, Hao Sun wrote: > Making the conversion explicit would fix it. > > Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. > Therefore clang-8 and clang-9 are not affected. The flag with similar > functionality in gcc is '-Wfloat-conversion', but it is not enabled by > '-Wall' or '-Wextra'. That's why this warning does not appear when > building with gcc. > > > Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. > Note that '--with-extra-cxxflags=-Wno-deprecated-copy' should be added when configuration. It's another issue (See JDK-8258010) Can anyone help to review this trivial patch? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1956 From jnimeh at openjdk.java.net Thu Jan 14 06:38:15 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 14 Jan 2021 06:38:15 GMT Subject: RFR: 8253866: Security Libs Terminology Refresh Message-ID: This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). Here are the changes covering core libraries code and tests. Terms were changed as follows: - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) - master/slave in KRB5 -> primary/replica - blacklist in other files -> deny list - whitelist -> allow list Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. ------------- Commit messages: - Merge main branch - 8253866: Security Libs Terminology Refresh Changes: https://git.openjdk.java.net/jdk/pull/2074/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2074&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253866 Stats: 351 lines in 17 files changed: 152 ins; 150 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/2074.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2074/head:pull/2074 PR: https://git.openjdk.java.net/jdk/pull/2074 From erikj at openjdk.java.net Thu Jan 14 13:48:04 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 14 Jan 2021 13:48:04 GMT Subject: RFR: 8253866: Security Libs Terminology Refresh In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > > - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2074 From weijun at openjdk.java.net Thu Jan 14 15:30:02 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 14 Jan 2021 15:30:02 GMT Subject: RFR: 8253866: Security Libs Terminology Refresh In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > > - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Code change looks fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2074 From mullan at openjdk.java.net Thu Jan 14 15:51:04 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 14 Jan 2021 15:51:04 GMT Subject: RFR: 8253866: Security Libs Terminology Refresh In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > > - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Marked as reviewed by mullan (Reviewer). src/java.base/share/conf/security/java.security line 454: > 452: # configuration, but with smaller max_retries and timeout values. > 453: # max_retries and timeout are optional numerical parameters (default 1 and > 454: # 5000, which means once and 5 seconds). Please notes that if any of the Typo: s/notes/note/ src/java.base/share/conf/security/java.security line 455: > 453: # max_retries and timeout are optional numerical parameters (default 1 and > 454: # 5000, which means once and 5 seconds). Please notes that if any of the > 455: # values defined here is more than what is defined in krb5.conf, it will be Typo: s/is more/are more/ ------------- PR: https://git.openjdk.java.net/jdk/pull/2074 From jnimeh at openjdk.java.net Thu Jan 14 16:40:15 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 14 Jan 2021 16:40:15 GMT Subject: RFR: 8253866: Security Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: > This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > > - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Minor grammatical fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2074/files - new: https://git.openjdk.java.net/jdk/pull/2074/files/9d44a9e1..45492f55 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2074&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2074&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2074.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2074/head:pull/2074 PR: https://git.openjdk.java.net/jdk/pull/2074 From jnimeh at openjdk.java.net Thu Jan 14 16:40:18 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 14 Jan 2021 16:40:18 GMT Subject: Integrated: 8253866: Security Libs Terminology Refresh In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were changed as follows: > > - blacklisted.certs -> blocked.certs (along with supporting make infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. This pull request has now been integrated. Changeset: 8554fe6e Author: Jamil Nimeh URL: https://git.openjdk.java.net/jdk/commit/8554fe6e Stats: 351 lines in 17 files changed: 152 ins; 150 del; 49 mod 8253866: Security Libs Terminology Refresh Reviewed-by: erikj, weijun, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2074 From jnimeh at openjdk.java.net Thu Jan 14 16:40:17 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 14 Jan 2021 16:40:17 GMT Subject: RFR: 8253866: Security Libs Terminology Refresh [v2] In-Reply-To: References: Message-ID: <0T5q-e3tXNFq1QKgKV3YvjgFIhNZG6QpmhnG2_Y3JrA=.2a06de53-02db-4b9b-b58c-5f8220c83a71@github.com> On Thu, 14 Jan 2021 15:45:43 GMT, Sean Mullan wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor grammatical fixes > > src/java.base/share/conf/security/java.security line 455: > >> 453: # max_retries and timeout are optional numerical parameters (default 1 and >> 454: # 5000, which means once and 5 seconds). Please notes that if any of the >> 455: # values defined here is more than what is defined in krb5.conf, it will be > > Typo: s/is more/are more/ Done. Good catch. > src/java.base/share/conf/security/java.security line 454: > >> 452: # configuration, but with smaller max_retries and timeout values. >> 453: # max_retries and timeout are optional numerical parameters (default 1 and >> 454: # 5000, which means once and 5 seconds). Please notes that if any of the > > Typo: s/notes/note/ fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/2074 From martin.doerr at sap.com Thu Jan 14 16:49:36 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 14 Jan 2021 16:49:36 +0000 Subject: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm Message-ID: Hi, JDK-8257633 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly because of an unrelated context change in the neighboring code. Bug: https://bugs.openjdk.java.net/browse/JDK-8257633 Original change: https://git.openjdk.java.net/jdk/commit/51d325e6 11u backport: http://cr.openjdk.java.net/~mdoerr/8257633_build_11u/webrev.00/ Please review. Best regards, Martin From goetz.lindenmaier at sap.com Fri Jan 15 10:29:01 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 15 Jan 2021 10:29:01 +0000 Subject: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm In-Reply-To: References: Message-ID: Hi Martin, Trivial adaptions. Looks good. Best regards Goetz. From: Doerr, Martin Sent: Thursday, January 14, 2021 5:50 PM To: jdk-updates-dev at openjdk.java.net; build-dev at openjdk.java.net Cc: Lindenmaier, Goetz ; Langer, Christoph Subject: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm Hi, JDK-8257633 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly because of an unrelated context change in the neighboring code. Bug: https://bugs.openjdk.java.net/browse/JDK-8257633 Original change: https://git.openjdk.java.net/jdk/commit/51d325e6 11u backport: http://cr.openjdk.java.net/~mdoerr/8257633_build_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Fri Jan 15 11:42:02 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 15 Jan 2021 11:42:02 +0000 Subject: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review. Best regards, Martin From: Lindenmaier, Goetz Sent: Freitag, 15. Januar 2021 11:29 To: Doerr, Martin ; jdk-updates-dev at openjdk.java.net; build-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm Hi Martin, Trivial adaptions. Looks good. Best regards Goetz. From: Doerr, Martin > Sent: Thursday, January 14, 2021 5:50 PM To: jdk-updates-dev at openjdk.java.net; build-dev at openjdk.java.net Cc: Lindenmaier, Goetz >; Langer, Christoph > Subject: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm Hi, JDK-8257633 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly because of an unrelated context change in the neighboring code. Bug: https://bugs.openjdk.java.net/browse/JDK-8257633 Original change: https://git.openjdk.java.net/jdk/commit/51d325e6 11u backport: http://cr.openjdk.java.net/~mdoerr/8257633_build_11u/webrev.00/ Please review. Best regards, Martin From alanb at openjdk.java.net Fri Jan 15 15:01:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 15 Jan 2021 15:01:09 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Mon, 11 Jan 2021 09:20:07 GMT, Magnus Ihse Bursie wrote: >> Marked as reviewed by prr (Reviewer). > > This PR is not stale; it's just still waiting for input from @AlanBateman. @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From mark.reinhold at oracle.com Fri Jan 15 18:27:09 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 15 Jan 2021 10:27:09 -0800 Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: <20210115102709.538599954@eggemoggin.niobe.net> 2020/12/4 6:08:13 -0800, erikj at openjdk.java.net: > On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote: >>> And I can certainly move jdwp.spec to java.base instead. That's the >>> reason I need input on this: All I know is that is definitely not >>> the responsibility of the Build Group to maintain that document, and >>> I made my best guess at where to place it. >> >>> And I can certainly move jdwp.spec to java.base instead. >> >> If jdwp.spec has to move to the src tree then src/java.se is probably >> the most suitable home because Java SE specifies JDWP as an optional >> interface. So nothing to do with java.base and the build will need to >> continue to generate the sources for the front-end (jdk.jdi) and >> back-end (jdk.jdwp.agent) as they implement the protocol. > > My understanding of JEPs is that they should be viewed as living > documents. In this case, I think it's perfectly valid to update JEP > 201 with additional source code layout. Both for this and for the > other missing dirs. Feature JEPs are living documents until such time as they are delivered. In this case it would not be appropriate to update JEP 201, which is as much about the transition from the old source-code layout as it is about the new layout as of 2014. At this point, and given that we?d already gone beyond JEP 201 prior to this change (with `man` and `lib` subdirectories), what?d make the most sense is a new informational JEP that documents the source-code layout. Informational JEPs can, within reason, be updated over time. - Mark From ihse at openjdk.java.net Fri Jan 15 18:30:07 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 15 Jan 2021 18:30:07 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote: >> This PR is not stale; it's just still waiting for input from @AlanBateman. > > @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? @AlanBateman That sounds like an excellent idea. I'll update the PR first thing next week. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From christoph.langer at sap.com Sat Jan 16 11:03:15 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 16 Jan 2021 11:03:15 +0000 Subject: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm In-Reply-To: References: Message-ID: Hi Martin, looks good. I also verified that it removes the warning messages in the build. Approved. Best regards Christoph From: Doerr, Martin Sent: Donnerstag, 14. Januar 2021 17:50 To: jdk-updates-dev at openjdk.java.net; build-dev at openjdk.java.net Cc: Lindenmaier, Goetz ; Langer, Christoph Subject: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm Hi, JDK-8257633 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly because of an unrelated context change in the neighboring code. Bug: https://bugs.openjdk.java.net/browse/JDK-8257633 Original change: https://git.openjdk.java.net/jdk/commit/51d325e6 11u backport: http://cr.openjdk.java.net/~mdoerr/8257633_build_11u/webrev.00/ Please review. Best regards, Martin From dholmes at openjdk.java.net Mon Jan 18 07:52:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 18 Jan 2021 07:52:55 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC Message-ID: We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. The changes are in layered commits: Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. Step 2: make supports_monotonic_clock always true and so remove checking in OS code Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) Step 4: Move shared time functions to os_posix.cpp Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 Testing: tiers 1-3 for functional testing built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 ------------- Commit messages: - Merge branch 'master' into 8246112-mono - Alway link librt on Linux so we don't rely on glibc > 2.12 - Step 4: Move shared time functions to os_posix.cpp - Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) - Step 2: make supports_monotonic_clock always true and so remove checking it (in OS code) - 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC Changes: https://git.openjdk.java.net/jdk/pull/2090/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2090&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246112 Stats: 380 lines in 11 files changed: 54 ins; 299 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/2090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2090/head:pull/2090 PR: https://git.openjdk.java.net/jdk/pull/2090 From martin.doerr at sap.com Mon Jan 18 09:40:53 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 18 Jan 2021 09:40:53 +0000 Subject: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm In-Reply-To: References: Message-ID: Hi Christoph, thanks for reviewing, testing and for the approval. Pushed. Best regards, Martin From: Langer, Christoph Sent: Samstag, 16. Januar 2021 12:03 To: Doerr, Martin ; jdk-updates-dev at openjdk.java.net; build-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: RE: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm Hi Martin, looks good. I also verified that it removes the warning messages in the build. Approved. Best regards Christoph From: Doerr, Martin > Sent: Donnerstag, 14. Januar 2021 17:50 To: jdk-updates-dev at openjdk.java.net; build-dev at openjdk.java.net Cc: Lindenmaier, Goetz >; Langer, Christoph > Subject: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm Hi, JDK-8257633 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly because of an unrelated context change in the neighboring code. Bug: https://bugs.openjdk.java.net/browse/JDK-8257633 Original change: https://git.openjdk.java.net/jdk/commit/51d325e6 11u backport: http://cr.openjdk.java.net/~mdoerr/8257633_build_11u/webrev.00/ Please review. Best regards, Martin From shade at openjdk.java.net Mon Jan 18 13:07:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Jan 2021 13:07:52 GMT Subject: RFR: 8259679: GitHub actions should use MSVC 14.28 Message-ID: Current Windows GH Actions fails with: configure: using /cygdrive/c/progra~2/micros~1/2019/Enterprise/vc/auxiliary/build/vcvarsx86_amd64.bat configure: Setting extracted environment variables for x86_64 checking that Visual Studio variables have been correctly extracted... ok checking for cl... [not found] configure: error: Could not find a C compiler. configure exiting with result code 1 I managed to figure out that MSVC build 14.27 is not really available. 14.28 is available instead. Note that Windows AArch64 build block already uses 14.28 in the same manner, so this change not only fixes the GH actions, it also keeps both blocks consistent. ------------- Commit messages: - 8259679: GitHub actions should use MSVC 14.28 Changes: https://git.openjdk.java.net/jdk/pull/2126/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2126&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259679 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2126.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2126/head:pull/2126 PR: https://git.openjdk.java.net/jdk/pull/2126 From magnus.ihse.bursie at oracle.com Mon Jan 18 13:21:07 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 14:21:07 +0100 Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: <20210115102709.538599954@eggemoggin.niobe.net> References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> <20210115102709.538599954@eggemoggin.niobe.net> Message-ID: <0219364d-3926-2b7b-4cb5-90f698eeb706@oracle.com> On 2021-01-15 19:27, mark.reinhold at oracle.com wrote: > Feature JEPs are living documents until such time as they are delivered. > In this case it would not be appropriate to update JEP 201, which is as > much about the transition from the old source-code layout as it is about > the new layout as of 2014. > > At this point, and given that we?d already gone beyond JEP 201 prior to > this change (with `man` and `lib` subdirectories), what?d make the most > sense is a new informational JEP that documents the source-code layout. > Informational JEPs can, within reason, be updated over time. So I take it I need to create a new informational JEP. :-) Fine, I can do that. I assume I mostly need to extract the parts of JEP 201 that describes the (then "new") layout, update wording to show that this is a description of the current layout, and add the new additions. It'll be a very short JEP, but in this case, that's probably a virtue. /Magnus From ihse at openjdk.java.net Mon Jan 18 13:47:20 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 13:47:20 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v5] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Move characterdata templates to share/classes/java/lang. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/68b252b5..c4894348 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=03-04 Stats: 4 lines in 9 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Mon Jan 18 13:52:44 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 13:52:44 GMT Subject: RFR: 8259679: GitHub actions should use MSVC 14.28 In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:02:59 GMT, Aleksey Shipilev wrote: > Current Windows GH Actions fails with: > > configure: using /cygdrive/c/progra~2/micros~1/2019/Enterprise/vc/auxiliary/build/vcvarsx86_amd64.bat > configure: Setting extracted environment variables for x86_64 > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... [not found] > configure: error: Could not find a C compiler. > configure exiting with result code 1 > > I managed to figure out that MSVC build 14.27 is not really available. 14.28 is available instead. Note that Windows AArch64 build block already uses 14.28 in the same manner, so this change not only fixes the GH actions, it also keeps both blocks consistent. LGTM. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2126 From ihse at openjdk.java.net Mon Jan 18 13:49:49 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 13:49:49 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote: >> This PR is not stale; it's just still waiting for input from @AlanBateman. > > @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? @AlanBateman When I moved the charset templates, I found this gold nugget: # Copy two Java files that need no preprocessing. $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template $(call LogInfo, Generating $(@F)) $(call install-file) GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \ $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) That definitely needs cleaning up, but this PR is large enough as it is, so I will not do it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Mon Jan 18 13:59:44 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 13:59:44 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 04:57:24 GMT, David Holmes wrote: > We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. > > As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. > > The changes are in layered commits: > > Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. > Step 2: make supports_monotonic_clock always true and so remove checking in OS code > Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) > Step 4: Move shared time functions to os_posix.cpp > Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 > > Testing: tiers 1-3 for functional testing > built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 Looks like a good cleanup. But please minimize the use of -lrt to hotspot only as per the comment above. make/autoconf/flags-ldflags.m4 line 116: > 114: # has glibc 2.17, this can be removed as the functions are > 115: # in libc. > 116: OS_LDFLAGS="-lrt" I believe this should be `OS_LDFLAGS_JVM_ONLY`, right? ------------- Changes requested by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2090 From shade at openjdk.java.net Mon Jan 18 14:03:01 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Jan 2021 14:03:01 GMT Subject: RFR: 8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386" Message-ID: When `libc6*:i386` packages are installed as the dependency of other packages, they seem to run into configure problems. It helps to install them ahead of the bulk of the packages to resolve this. ------------- Commit messages: - 8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386" Changes: https://git.openjdk.java.net/jdk/pull/2128/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2128&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259924 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2128.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2128/head:pull/2128 PR: https://git.openjdk.java.net/jdk/pull/2128 From redestad at openjdk.java.net Mon Jan 18 14:04:43 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 18 Jan 2021 14:04:43 GMT Subject: RFR: 8259679: GitHub actions should use MSVC 14.28 In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:02:59 GMT, Aleksey Shipilev wrote: > Current Windows GH Actions fails with: > > configure: using /cygdrive/c/progra~2/micros~1/2019/Enterprise/vc/auxiliary/build/vcvarsx86_amd64.bat > configure: Setting extracted environment variables for x86_64 > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... [not found] > configure: error: Could not find a C compiler. > configure exiting with result code 1 > > I managed to figure out that MSVC build 14.27 is not really available. 14.28 is available instead. Note that Windows AArch64 build block already uses 14.28 in the same manner, so this change not only fixes the GH actions, it also keeps both blocks consistent. Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2126 From afarley at openjdk.java.net Mon Jan 18 18:32:56 2021 From: afarley at openjdk.java.net (Adam Farley) Date: Mon, 18 Jan 2021 18:32:56 GMT Subject: RFR: 8259942: Enable customizations in CompileJavaModules.gmk and Main.gmk Message-ID: Ensure make files look on the include path or in PHASE_MAKEDIRS for customizations. Change also adds a tidy-up that improves readability. ------------- Commit messages: - 8259942: Enable customizations in CompileJavaModules.gmk and Main.gmk Changes: https://git.openjdk.java.net/jdk/pull/2134/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2134&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259942 Stats: 5 lines in 3 files changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2134.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2134/head:pull/2134 PR: https://git.openjdk.java.net/jdk/pull/2134 From shade at openjdk.java.net Mon Jan 18 18:45:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Jan 2021 18:45:45 GMT Subject: Integrated: 8259679: GitHub actions should use MSVC 14.28 In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:02:59 GMT, Aleksey Shipilev wrote: > Current Windows GH Actions fails with: > > configure: using /cygdrive/c/progra~2/micros~1/2019/Enterprise/vc/auxiliary/build/vcvarsx86_amd64.bat > configure: Setting extracted environment variables for x86_64 > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... [not found] > configure: error: Could not find a C compiler. > configure exiting with result code 1 > > I managed to figure out that MSVC build 14.27 is not really available. 14.28 is available instead. Note that Windows AArch64 build block already uses 14.28 in the same manner, so this change not only fixes the GH actions, it also keeps both blocks consistent. This pull request has now been integrated. Changeset: 6b4732fe Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/6b4732fe Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8259679: GitHub actions should use MSVC 14.28 Reviewed-by: ihse, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/2126 From shade at openjdk.java.net Mon Jan 18 18:47:04 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Jan 2021 18:47:04 GMT Subject: RFR: 8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386" [v2] In-Reply-To: References: Message-ID: > When `libc6*:i386` packages are installed as the dependency of other packages, they seem to run into configure problems. It helps to install them ahead of the bulk of the packages to resolve this. > > Current Linux x86 jobs fail like this: > > E: Could not configure 'libc6:i386'. > E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8259924 - 8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2128/files - new: https://git.openjdk.java.net/jdk/pull/2128/files/e64adb4e..af23d952 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2128&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2128&range=00-01 Stats: 135 lines in 28 files changed: 0 ins; 5 del; 130 mod Patch: https://git.openjdk.java.net/jdk/pull/2128.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2128/head:pull/2128 PR: https://git.openjdk.java.net/jdk/pull/2128 From adfarley at redhat.com Mon Jan 18 18:41:17 2021 From: adfarley at redhat.com (Adam Farley) Date: Mon, 18 Jan 2021 18:41:17 +0000 Subject: RFR: JDK-8259942: Enable customizations in CompileJavaModules.gmk and Main.gmk Message-ID: Hi All, Reviews and sponsor requested for a simple fix. This change restores the ability of these makefiles to include customizations. No sign this ability was removed deliberately, so I think it was just a mistake. Also includes a small readability improvement. Bug: https://bugs.openjdk.java.net/browse/JDK-8259942 PR: https://github.com/openjdk/jdk/pull/2134 Best Regards Adam Farley Software Developer Red Hat From david.holmes at oracle.com Mon Jan 18 22:59:08 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Jan 2021 08:59:08 +1000 Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC In-Reply-To: References: Message-ID: On 18/01/2021 11:59 pm, Magnus Ihse Bursie wrote: > On Fri, 15 Jan 2021 04:57:24 GMT, David Holmes wrote: > >> We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. >> >> As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. >> >> The changes are in layered commits: >> >> Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. >> Step 2: make supports_monotonic_clock always true and so remove checking in OS code >> Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) >> Step 4: Move shared time functions to os_posix.cpp >> Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 >> >> Testing: tiers 1-3 for functional testing >> built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 > > Looks like a good cleanup. But please minimize the use of -lrt to hotspot only as per the comment above. > > make/autoconf/flags-ldflags.m4 line 116: > >> 114: # has glibc 2.17, this can be removed as the functions are >> 115: # in libc. >> 116: OS_LDFLAGS="-lrt" > > I believe this should be `OS_LDFLAGS_JVM_ONLY`, right? Right - sorry, don't know how I missed that. Thanks, David > ------------- > > Changes requested by ihse (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/2090 > From david.holmes at oracle.com Mon Jan 18 23:13:02 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Jan 2021 09:13:02 +1000 Subject: RFR: 8259679: GitHub actions should use MSVC 14.28 In-Reply-To: References: Message-ID: Hi Aleksey, On 18/01/2021 11:07 pm, Aleksey Shipilev wrote: > Current Windows GH Actions fails with: > > configure: using /cygdrive/c/progra~2/micros~1/2019/Enterprise/vc/auxiliary/build/vcvarsx86_amd64.bat > configure: Setting extracted environment variables for x86_64 > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... [not found] > configure: error: Could not find a C compiler. > configure exiting with result code 1 > > I managed to figure out that MSVC build 14.27 is not really available. 14.28 is available instead. Note that Windows AArch64 build block already uses 14.28 in the same manner, so this change not only fixes the GH actions, it also keeps both blocks consistent. Hard-wiring build numbers seems a maintenance PITA. :( Is there not a way to do this that is independent of the actual build installed? Would it not also be good to add a check for the existence of the build that we do hard-wire? That way the problem will be very clear next time. Cheers, David > ------------- > > Commit messages: > - 8259679: GitHub actions should use MSVC 14.28 > > Changes: https://git.openjdk.java.net/jdk/pull/2126/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2126&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8259679 > Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jdk/pull/2126.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/2126/head:pull/2126 > > PR: https://git.openjdk.java.net/jdk/pull/2126 > From dholmes at openjdk.java.net Mon Jan 18 23:20:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 18 Jan 2021 23:20:52 GMT Subject: RFR: 8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386" [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 18:47:04 GMT, Aleksey Shipilev wrote: >> When `libc6*:i386` packages are installed as the dependency of other packages, they seem to run into configure problems. It helps to install them ahead of the bulk of the packages to resolve this. >> >> Current Linux x86 jobs fail like this: >> >> E: Could not configure 'libc6:i386'. >> E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8259924 > - 8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386" Seems reasonable - albeit annoying that we need to track some dependencies explicitly. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2128 From dholmes at openjdk.java.net Mon Jan 18 23:30:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 18 Jan 2021 23:30:07 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v2] In-Reply-To: References: Message-ID: <2NHLdeM9Lz4XSFsjzb66kjLtHCECzhfm5vlxK1686pQ=.6ac14cac-7a7c-46b2-bc8d-faae45e3f478@github.com> > We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. > > As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. > > The changes are in layered commits: > > Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. > Step 2: make supports_monotonic_clock always true and so remove checking in OS code > Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) > Step 4: Move shared time functions to os_posix.cpp > Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 > > Testing: tiers 1-3 for functional testing > built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 David Holmes has updated the pull request incrementally with one additional commit since the last revision: Restrict librt linking to JVM - per Magnus's request ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2090/files - new: https://git.openjdk.java.net/jdk/pull/2090/files/cfb59800..b857faf6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2090&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2090&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2090/head:pull/2090 PR: https://git.openjdk.java.net/jdk/pull/2090 From dholmes at openjdk.java.net Tue Jan 19 01:53:03 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 19 Jan 2021 01:53:03 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v3] In-Reply-To: References: Message-ID: > We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. > > As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. > > The changes are in layered commits: > > Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. > Step 2: make supports_monotonic_clock always true and so remove checking in OS code > Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) > Step 4: Move shared time functions to os_posix.cpp > Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 > > Testing: tiers 1-3 for functional testing > built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into 8246112-mono - Restrict librt linking to JVM - per Magnus's request - Merge branch 'master' into 8246112-mono - Alway link librt on Linux so we don't rely on glibc > 2.12 - Step 4: Move shared time functions to os_posix.cpp - Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) - Step 2: make supports_monotonic_clock always true and so remove checking it (in OS code) - 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2090/files - new: https://git.openjdk.java.net/jdk/pull/2090/files/b857faf6..e59676fd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2090&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2090&range=01-02 Stats: 14984 lines in 239 files changed: 2936 ins; 9648 del; 2400 mod Patch: https://git.openjdk.java.net/jdk/pull/2090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2090/head:pull/2090 PR: https://git.openjdk.java.net/jdk/pull/2090 From stuefe at openjdk.java.net Tue Jan 19 06:06:18 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 19 Jan 2021 06:06:18 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory [v2] In-Reply-To: References: Message-ID: <4ONcTjZt6YQKyWyuZ87LPSe2GYVAr70qPSWq8cXoxsI=.e9b59bb5-2fbe-4710-980b-86fe142392a1@github.com> On Mon, 18 Jan 2021 11:25:32 GMT, Tobias Hartmann wrote: > Otherwise, looks good to me. Thanks Tobias. I added your suggestion. Cheers, Thoams ------------- PR: https://git.openjdk.java.net/jdk/pull/2063 From stuefe at openjdk.java.net Tue Jan 19 06:06:17 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 19 Jan 2021 06:06:17 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory [v2] In-Reply-To: References: Message-ID: > We see C-heap leaking, originating in C2: > > 1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55 > 1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c > 1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator >::grow(int)+0x163 > 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator >::insert_before(int, Compile::PrintInliningBuffer const&)+0x82 > 1434781 [0x00007f5820c6aaf2] Compile::print_inlining_push()+0x70 > > accumulating over the course of days to some hundred MB at a customer site where inline tracing was active. > > > Analysis: > > > To build up a comprehensive inlining trace, c2 keeps trace snippets in an internal list and assembles them at print time. These are stringStream's, contained in PrintInliningBuffer: > > GrowableArray* _print_inlining_list; > ... > class PrintInliningBuffer : public ResourceObj { > private: > CallGenerator* _cg; > stringStream* _ss; > > public: > PrintInliningBuffer() > : _cg(NULL) { > _ss = new stringStream(); > } > > void freeStream() { > _ss->~stringStream(); _ss = NULL; } > ... > }; > > With [JDK-8224193](https://bugs.openjdk.java.net/browse/JDK-8224193), stringStream was changed to use C-heap instead of ResourceArea for its internal buffer. This means one cannot just omit stringStream destruction anymore - even where stringStream objects themselves live in RA, their internal buffers don't, they live in C-Heap. To clean up properly, ~stringStream() must be called. > > Those `PrintInliningBuffer` objects are kept _by value_ in a GrowableArray `Compile::_print_inlining_list`. Normally, if an object is kept by value, it needs to implement correct copy- and destruction-semantics. PrintInliningBuffer does not do that and instead relies on manual cleanup (`PrintInliningBuffer::freeStream()`) - I assume the authors did not want to deal with reference counting the contained stringStream on copying. > > That however is a problem because GrowableArray creates internally temporary objects of the item type to pre-populate its array - its whole capacity - when it grows: > > > template > void GrowableArrayWithAllocator::grow(int j) { > > ... > for ( ; i < this->_len; i++) ::new ((void*)&newData[i]) E(this->_data[i]); > for ( ; i < this->_max; i++) ::new ((void*)&newData[i]) E(); <<<<<<< > for (i = 0; i < old_max; i++) this->_data[i].~E(); > ... > } > > this it does for the whole new capacity, which means more objects get created than have been added; if the caller does not fill the GrowableArray up to its capacity, it never knows about the excess objects created. This is normally not a problem since all these objects are destructed by GrowableArray in `void GrowableArrayWithAllocator::clear_and_deallocate()`. But since PrintInliningBuffer does not implement a destructor, this has no effect. > > PrintInliningBuffer instead relies on manual cleanup of the stringStreams: at the end of the compile phase, it calls `PrintInliningBuffer::freeStream()` on all buffers it thinks are contained in the array: > > assert(_print_inlining_list != NULL, "process_print_inlining should be called only once."); > for (int i = 0; i < _print_inlining_list->length(); i++) { > ss.print("%s", _print_inlining_list->adr_at(i)->ss()->as_string()); > _print_inlining_list->at(i).freeStream(); > } > > but this of course leaves the excess objects untouched (objects whose index is array length >= index >= array capacity). > > ----------- > > There are several ways to fix this: > > 1) implement correct destructor- and copy semantics for PrintInliningBuffer. This would work but is not optimal since we would still pay for creation of unnecessary PrintInliningBuffer objects when the array is prepopulated on grow() > > 2) delay construction of `PrintInliningBuffer::_ss` until the stream is actually used for writing into. This would would mean we have to check the stringStream for NULL before using it. > > 3) Just let the PrintInliningBuffer live in C-heap instead of the RA. Its only a small shell anywhere now that the stringStream buffer lives in C-heap. Instead, let PrintInliningBuffer contain the stringStream as a member, allocate PrintInliningBuffer from C-heap, and change the list to contain pointers to PrintInliningBuffer, not the object itself. This removes all that unnecessary copying, removes creation of temporary objects, and simplifies the code. Having to free those objects is no big deal since we free the stringStream objects manually anyway. > > I went with (3). I also decreased the default stringStream buffer size for this scenario since when testing I found out that many trace snippets are below 128 bytes. > > Note that (3) is not only simpler, but also more efficient: many of the PrintInliningBuffer objects are inserted into the middle of the _print_inlining_list; GrowableArray does shift all higher items up to provide space for the new item. If those items are simple pointers instead of whole objects, less memory is moved around. > > Tests: > - github actions > - Nightlies at SAP > - I manually tested the patch and compared the NMT output of a tracing scenario to verify that the leak went away and no other numbers changed > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: change return parameter of Compile::print_inlining_current() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2063/files - new: https://git.openjdk.java.net/jdk/pull/2063/files/4045f2f8..b52b140b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2063&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2063&range=00-01 Stats: 2375 lines in 4 files changed: 2365 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2063/head:pull/2063 PR: https://git.openjdk.java.net/jdk/pull/2063 From thartmann at openjdk.java.net Tue Jan 19 08:50:54 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 19 Jan 2021 08:50:54 GMT Subject: RFR: JDK-8259710: Inlining trace leaks memory [v2] In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 06:06:17 GMT, Thomas Stuefe wrote: >> We see C-heap leaking, originating in C2: >> >> 1434777 [0x00007f58214af461] stringStream::stringStream(unsigned long)+0x55 >> 1434778 [0x00007f5820c6db3e] Compile::PrintInliningBuffer::PrintInliningBuffer()+0x6c >> 1434779 [0x00007f5820c724f1] GrowableArrayWithAllocator >::grow(int)+0x163 >> 1434780 [0x00007f5820c7160e] GrowableArrayWithAllocator >::insert_before(int, Compile::PrintInliningBuffer const&)+0x82 >> 1434781 [0x00007f5820c6aaf2] Compile::print_inlining_push()+0x70 >> >> accumulating over the course of days to some hundred MB at a customer site where inline tracing was active. >> >> >> Analysis: >> >> >> To build up a comprehensive inlining trace, c2 keeps trace snippets in an internal list and assembles them at print time. These are stringStream's, contained in PrintInliningBuffer: >> >> GrowableArray* _print_inlining_list; >> ... >> class PrintInliningBuffer : public ResourceObj { >> private: >> CallGenerator* _cg; >> stringStream* _ss; >> >> public: >> PrintInliningBuffer() >> : _cg(NULL) { >> _ss = new stringStream(); >> } >> >> void freeStream() { >> _ss->~stringStream(); _ss = NULL; } >> ... >> }; >> >> With [JDK-8224193](https://bugs.openjdk.java.net/browse/JDK-8224193), stringStream was changed to use C-heap instead of ResourceArea for its internal buffer. This means one cannot just omit stringStream destruction anymore - even where stringStream objects themselves live in RA, their internal buffers don't, they live in C-Heap. To clean up properly, ~stringStream() must be called. >> >> Those `PrintInliningBuffer` objects are kept _by value_ in a GrowableArray `Compile::_print_inlining_list`. Normally, if an object is kept by value, it needs to implement correct copy- and destruction-semantics. PrintInliningBuffer does not do that and instead relies on manual cleanup (`PrintInliningBuffer::freeStream()`) - I assume the authors did not want to deal with reference counting the contained stringStream on copying. >> >> That however is a problem because GrowableArray creates internally temporary objects of the item type to pre-populate its array - its whole capacity - when it grows: >> >> >> template >> void GrowableArrayWithAllocator::grow(int j) { >> >> ... >> for ( ; i < this->_len; i++) ::new ((void*)&newData[i]) E(this->_data[i]); >> for ( ; i < this->_max; i++) ::new ((void*)&newData[i]) E(); <<<<<<< >> for (i = 0; i < old_max; i++) this->_data[i].~E(); >> ... >> } >> >> this it does for the whole new capacity, which means more objects get created than have been added; if the caller does not fill the GrowableArray up to its capacity, it never knows about the excess objects created. This is normally not a problem since all these objects are destructed by GrowableArray in `void GrowableArrayWithAllocator::clear_and_deallocate()`. But since PrintInliningBuffer does not implement a destructor, this has no effect. >> >> PrintInliningBuffer instead relies on manual cleanup of the stringStreams: at the end of the compile phase, it calls `PrintInliningBuffer::freeStream()` on all buffers it thinks are contained in the array: >> >> assert(_print_inlining_list != NULL, "process_print_inlining should be called only once."); >> for (int i = 0; i < _print_inlining_list->length(); i++) { >> ss.print("%s", _print_inlining_list->adr_at(i)->ss()->as_string()); >> _print_inlining_list->at(i).freeStream(); >> } >> >> but this of course leaves the excess objects untouched (objects whose index is array length >= index >= array capacity). >> >> ----------- >> >> There are several ways to fix this: >> >> 1) implement correct destructor- and copy semantics for PrintInliningBuffer. This would work but is not optimal since we would still pay for creation of unnecessary PrintInliningBuffer objects when the array is prepopulated on grow() >> >> 2) delay construction of `PrintInliningBuffer::_ss` until the stream is actually used for writing into. This would would mean we have to check the stringStream for NULL before using it. >> >> 3) Just let the PrintInliningBuffer live in C-heap instead of the RA. Its only a small shell anywhere now that the stringStream buffer lives in C-heap. Instead, let PrintInliningBuffer contain the stringStream as a member, allocate PrintInliningBuffer from C-heap, and change the list to contain pointers to PrintInliningBuffer, not the object itself. This removes all that unnecessary copying, removes creation of temporary objects, and simplifies the code. Having to free those objects is no big deal since we free the stringStream objects manually anyway. >> >> I went with (3). I also decreased the default stringStream buffer size for this scenario since when testing I found out that many trace snippets are below 128 bytes. >> >> Note that (3) is not only simpler, but also more efficient: many of the PrintInliningBuffer objects are inserted into the middle of the _print_inlining_list; GrowableArray does shift all higher items up to provide space for the new item. If those items are simple pointers instead of whole objects, less memory is moved around. >> >> Tests: >> - github actions >> - Nightlies at SAP >> - I manually tested the patch and compared the NMT output of a tracing scenario to verify that the leak went away and no other numbers changed >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > change return parameter of Compile::print_inlining_current() Thanks for updating. Looks good but you accidentally pushed `make/hs_err_pid10680.log`, `make/replay_pid10680.log` :) Best regards, Tobias ------------- Changes requested by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2063 From shade at openjdk.java.net Tue Jan 19 09:41:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 19 Jan 2021 09:41:47 GMT Subject: Integrated: 8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386" In-Reply-To: References: Message-ID: <6cL-WDwm8IkaM85YW2c-NsZ6hsf1gKLYx_o_YrYSPDQ=.187b3f8b-3eb8-4d09-862d-d2d69773c4f5@github.com> On Mon, 18 Jan 2021 13:57:18 GMT, Aleksey Shipilev wrote: > When `libc6*:i386` packages are installed as the dependency of other packages, they seem to run into configure problems. It helps to install them ahead of the bulk of the packages to resolve this. > > Current Linux x86 jobs fail like this: > > E: Could not configure 'libc6:i386'. > E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) This pull request has now been integrated. Changeset: a9519c83 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/a9519c83 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386" Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/2128 From magnus.ihse.bursie at oracle.com Tue Jan 19 13:48:59 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 19 Jan 2021 14:48:59 +0100 Subject: RFR: 8259679: GitHub actions should use MSVC 14.28 In-Reply-To: References: Message-ID: <97ec9a82-2a6a-344f-223e-cff246c4b873@oracle.com> On 2021-01-19 00:13, David Holmes wrote: > Hard-wiring build numbers seems a maintenance PITA. :( Is there not a > way to do this that is independent of the actual build installed? I agree that hard-wiring numbers in the code is bad. However, having explicit version numbers for our dependencies is good. That is the philosophy behind jib, and it has served us well. We should look at finding a way to store the actual versioon numbers outside the submit.yml file, though. But what do you mean by "independent of the actual build installed"? > Would it not also be good to add a check for the existence of the > build that we do hard-wire? That way the problem will be very clear > next time. It would be fantastic! Please tell me how to to that in the limited, brain-dead Github Actions environment. :-( /Magnus > > Cheers, > David > >> ------------- >> >> Commit messages: >> ? - 8259679: GitHub actions should use MSVC 14.28 >> >> Changes: https://git.openjdk.java.net/jdk/pull/2126/files >> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2126&range=00 >> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8259679 >> ?? Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >> ?? Patch: https://git.openjdk.java.net/jdk/pull/2126.diff >> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >> pull/2126/head:pull/2126 >> >> PR: https://git.openjdk.java.net/jdk/pull/2126 >> From erikj at openjdk.java.net Tue Jan 19 14:26:05 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 19 Jan 2021 14:26:05 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v3] In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 01:53:03 GMT, David Holmes wrote: >> We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. >> >> As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. >> >> The changes are in layered commits: >> >> Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. >> Step 2: make supports_monotonic_clock always true and so remove checking in OS code >> Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) >> Step 4: Move shared time functions to os_posix.cpp >> Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 >> >> Testing: tiers 1-3 for functional testing >> built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'master' into 8246112-mono > - Restrict librt linking to JVM - per Magnus's request > - Merge branch 'master' into 8246112-mono > - Alway link librt on Linux so we don't rely on glibc > 2.12 > - Step 4: Move shared time functions to os_posix.cpp > - Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) > - Step 2: make supports_monotonic_clock always true and so remove checking it (in OS code) > - 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC > > Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. Build changes look good to me. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2090 From erikj at openjdk.java.net Tue Jan 19 14:30:52 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 19 Jan 2021 14:30:52 GMT Subject: RFR: 8259942: Enable customizations in CompileJavaModules.gmk and Main.gmk In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 18:27:14 GMT, Adam Farley wrote: > Ensure make files look on the include path or in PHASE_MAKEDIRS for > customizations. > > Change also adds a tidy-up that improves readability. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2134 From ihse at openjdk.java.net Tue Jan 19 18:24:55 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Jan 2021 18:24:55 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v3] In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 01:53:03 GMT, David Holmes wrote: >> We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. >> >> As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. >> >> The changes are in layered commits: >> >> Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. >> Step 2: make supports_monotonic_clock always true and so remove checking in OS code >> Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) >> Step 4: Move shared time functions to os_posix.cpp >> Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 >> >> Testing: tiers 1-3 for functional testing >> built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'master' into 8246112-mono > - Restrict librt linking to JVM - per Magnus's request > - Merge branch 'master' into 8246112-mono > - Alway link librt on Linux so we don't rely on glibc > 2.12 > - Step 4: Move shared time functions to os_posix.cpp > - Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) > - Step 2: make supports_monotonic_clock always true and so remove checking it (in OS code) > - 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC > > Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2090 From andrew at openjdk.java.net Wed Jan 20 04:36:05 2021 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Wed, 20 Jan 2021 04:36:05 GMT Subject: RFR: JDK-8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags Message-ID: The latest GCC fails if -fcf-protection is used with an x86 (32-bit) target that doesn't support CMOV: https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/config/i386/i386-options.c;h=a70f6edf7b0bfa6994db372c2507dbacb5526646;hp=6819a04238965f0ad63b10323823caa2fb8b147c;hb=77d372abec0fbf2cfe922e3140ee3410248f979e;hpb=5ebdd53534db25401473db5f6a0ad30f41410241 At least back to OpenJDK 11, the JDK build forces -march=i586 and the build fails with '-fcf-protection is not compatible with this target' This patch uses -march=i686 instead if -fcf-protection is detected in the compiler flags. It also makes it clear which is being set in the configure output, rather than silently setting the flag. ------------- Commit messages: - JDK-8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags Changes: https://git.openjdk.java.net/jdk/pull/2153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2153&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259949 Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2153/head:pull/2153 PR: https://git.openjdk.java.net/jdk/pull/2153 From david.holmes at oracle.com Wed Jan 20 05:14:30 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jan 2021 15:14:30 +1000 Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v3] In-Reply-To: References: Message-ID: <22d5a604-1285-d26c-31ae-b743c8bdc009@oracle.com> Thanks for the reviews Erik and Magnus! David On 20/01/2021 12:26 am, Erik Joelsson wrote: > On Tue, 19 Jan 2021 01:53:03 GMT, David Holmes wrote: > >>> We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. >>> >>> As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. >>> >>> The changes are in layered commits: >>> >>> Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. >>> Step 2: make supports_monotonic_clock always true and so remove checking in OS code >>> Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) >>> Step 4: Move shared time functions to os_posix.cpp >>> Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 >>> >>> Testing: tiers 1-3 for functional testing >>> built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 >> >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Merge branch 'master' into 8246112-mono >> - Restrict librt linking to JVM - per Magnus's request >> - Merge branch 'master' into 8246112-mono >> - Alway link librt on Linux so we don't rely on glibc > 2.12 >> - Step 4: Move shared time functions to os_posix.cpp >> - Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) >> - Step 2: make supports_monotonic_clock always true and so remove checking it (in OS code) >> - 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC >> >> Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. > > Build changes look good to me. > > ------------- > > Marked as reviewed by erikj (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/2090 > From david.holmes at oracle.com Wed Jan 20 05:48:29 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jan 2021 15:48:29 +1000 Subject: RFR: 8259679: GitHub actions should use MSVC 14.28 In-Reply-To: <97ec9a82-2a6a-344f-223e-cff246c4b873@oracle.com> References: <97ec9a82-2a6a-344f-223e-cff246c4b873@oracle.com> Message-ID: On 19/01/2021 11:48 pm, Magnus Ihse Bursie wrote: > > On 2021-01-19 00:13, David Holmes wrote: >> Hard-wiring build numbers seems a maintenance PITA. :( Is there not a >> way to do this that is independent of the actual build installed? > I agree that hard-wiring numbers in the code is bad. However, having > explicit version numbers for our dependencies is good. That is the > philosophy behind jib, and it has served us well. We should look at > finding a way to store the actual versioon numbers outside the > submit.yml file, though. I think this is a bit different to the way we use jib to manage our own build environment. > But what do you mean by "independent of the actual build installed"? We have AFAIK no control over what toolkit versions are installed for Github actions, so they could change at any time. We update today to request 14.28 and tomorrow they replace 14.28 with 14.29 and our builds fail again even though they would likely be perfectly fine on 14.29. To me if we just were able to say "Use latest VS 14.x" then that would suffice most of the time. Occasionally we could hit an issue where our sources are not yet compatible with the latest VS but hopefully that is less frequent than the frequency these VS builds change. >> Would it not also be good to add a check for the existence of the >> build that we do hard-wire? That way the problem will be very clear >> next time. > It would be fantastic! Please tell me how to to that in the limited, > brain-dead Github Actions environment. :-( If we put those hard-wired version/build numbers into a file readable by configure, then couldn't configure check it? Cheers, David > /Magnus >> >> Cheers, >> David >> >>> ------------- >>> >>> Commit messages: >>> ? - 8259679: GitHub actions should use MSVC 14.28 >>> >>> Changes: https://git.openjdk.java.net/jdk/pull/2126/files >>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2126&range=00 >>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8259679 >>> ?? Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>> ?? Patch: https://git.openjdk.java.net/jdk/pull/2126.diff >>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >>> pull/2126/head:pull/2126 >>> >>> PR: https://git.openjdk.java.net/jdk/pull/2126 >>> > From erikj at openjdk.java.net Wed Jan 20 14:07:48 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 20 Jan 2021 14:07:48 GMT Subject: RFR: JDK-8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 04:29:52 GMT, Andrew John Hughes wrote: > The latest GCC fails if -fcf-protection is used with an x86 (32-bit) target that doesn't support CMOV: > > https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/config/i386/i386-options.c;h=a70f6edf7b0bfa6994db372c2507dbacb5526646;hp=6819a04238965f0ad63b10323823caa2fb8b147c;hb=77d372abec0fbf2cfe922e3140ee3410248f979e;hpb=5ebdd53534db25401473db5f6a0ad30f41410241 > > At least back to OpenJDK 11, the JDK build forces -march=i586 and the build fails with '-fcf-protection is not compatible with this target' > > This patch uses -march=i686 instead if -fcf-protection is detected in the compiler flags. It also makes it clear which is being set in the configure output, rather than silently setting the flag. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2153 From andrew at openjdk.java.net Wed Jan 20 16:16:58 2021 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Wed, 20 Jan 2021 16:16:58 GMT Subject: Integrated: JDK-8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 04:29:52 GMT, Andrew John Hughes wrote: > The latest GCC fails if -fcf-protection is used with an x86 (32-bit) target that doesn't support CMOV: > > https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/config/i386/i386-options.c;h=a70f6edf7b0bfa6994db372c2507dbacb5526646;hp=6819a04238965f0ad63b10323823caa2fb8b147c;hb=77d372abec0fbf2cfe922e3140ee3410248f979e;hpb=5ebdd53534db25401473db5f6a0ad30f41410241 > > At least back to OpenJDK 11, the JDK build forces -march=i586 and the build fails with '-fcf-protection is not compatible with this target' > > This patch uses -march=i686 instead if -fcf-protection is detected in the compiler flags. It also makes it clear which is being set in the configure output, rather than silently setting the flag. This pull request has now been integrated. Changeset: 07851474 Author: Andrew John Hughes URL: https://git.openjdk.java.net/jdk/commit/07851474 Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags Use -march=i686 instead of -march=i586 if -fcf-protection is passed to the build as CMOV is required Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/2153 From gziemski at openjdk.java.net Wed Jan 20 21:34:06 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 20 Jan 2021 21:34:06 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v3] In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 01:53:03 GMT, David Holmes wrote: >> We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. >> >> As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. >> >> The changes are in layered commits: >> >> Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. >> Step 2: make supports_monotonic_clock always true and so remove checking in OS code >> Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) >> Step 4: Move shared time functions to os_posix.cpp >> Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 >> >> Testing: tiers 1-3 for functional testing >> built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'master' into 8246112-mono > - Restrict librt linking to JVM - per Magnus's request > - Merge branch 'master' into 8246112-mono > - Alway link librt on Linux so we don't rely on glibc > 2.12 > - Step 4: Move shared time functions to os_posix.cpp > - Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) > - Step 2: make supports_monotonic_clock always true and so remove checking it (in OS code) > - 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC > > Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. Changes requested by gziemski (Committer). src/hotspot/os/bsd/os_bsd.inline.hpp line 2: > 1: /* > 2: * Copyright (c) 1999, 2030, Oracle and/or its affiliates. All rights reserved. Year 2030 ? src/hotspot/os/bsd/os_bsd.cpp line 828: > 826: } > 827: > 828: void os::javaTimeNanos_info(jvmtiTimerInfo *info_ptr) { How come we need `os::javaTimeNanos_info` here if there is already one in `os_posix.cpp`? src/hotspot/os/posix/os_posix.hpp line 95: > 93: static void ucontext_set_pc(ucontext_t* ctx, address pc); > 94: > 95: static bool supports_monotonic_clock(); Why do we need this API at all now? thread.cpp uses it here: assert(!os::supports_monotonic_clock(), "unexpected time moving backwards detected in JavaThread::sleep()"); so we can just remove this usage? src/hotspot/os/posix/os_posix.cpp line 1161: > 1159: > 1160: void os::Posix::init_2(void) { > 1161: log_info(os)("Use of CLOCK_MONOTONIC is supported"); We are keeping this output to avoid breaking whomever might be looking for this text? ------------- PR: https://git.openjdk.java.net/jdk/pull/2090 From dholmes at openjdk.java.net Thu Jan 21 02:12:08 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 21 Jan 2021 02:12:08 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v4] In-Reply-To: References: Message-ID: > We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. > > As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. > > The changes are in layered commits: > > Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. > Step 2: make supports_monotonic_clock always true and so remove checking in OS code > Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) > Step 4: Move shared time functions to os_posix.cpp > Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 > > Testing: tiers 1-3 for functional testing > built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge - Merge branch 'master' into 8246112-mono - Restrict librt linking to JVM - per Magnus's request - Merge branch 'master' into 8246112-mono - Alway link librt on Linux so we don't rely on glibc > 2.12 - Step 4: Move shared time functions to os_posix.cpp - Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) - Step 2: make supports_monotonic_clock always true and so remove checking it (in OS code) - 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. ------------- Changes: https://git.openjdk.java.net/jdk/pull/2090/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2090&range=03 Stats: 379 lines in 11 files changed: 54 ins; 299 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/2090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2090/head:pull/2090 PR: https://git.openjdk.java.net/jdk/pull/2090 From david.holmes at oracle.com Thu Jan 21 03:02:21 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jan 2021 13:02:21 +1000 Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v3] In-Reply-To: References: Message-ID: <806b175b-b135-b16d-e3c0-eb5d057ecc0b@oracle.com> Hi Gerard, Thanks for looking at this! On 21/01/2021 7:34 am, Gerard Ziemski wrote: > On Tue, 19 Jan 2021 01:53:03 GMT, David Holmes wrote: > >>> We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. >>> >>> As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. >>> >>> The changes are in layered commits: >>> >>> Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. >>> Step 2: make supports_monotonic_clock always true and so remove checking in OS code >>> Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) >>> Step 4: Move shared time functions to os_posix.cpp >>> Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 > > src/hotspot/os/bsd/os_bsd.inline.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 1999, 2030, Oracle and/or its affiliates. All rights reserved. > > Year 2030 ? No idea how that happened :) Fixed via merge with mainline. > src/hotspot/os/bsd/os_bsd.cpp line 828: > >> 826: } >> 827: >> 828: void os::javaTimeNanos_info(jvmtiTimerInfo *info_ptr) { > > How come we need `os::javaTimeNanos_info` here if there is already one in `os_posix.cpp`? javaTimeNanos_info describes the properties of the implementation of javaTimeNanos. As we have a custom implementation of javaTimeNanos_info for macOS (and AIX) it seemed appropriate to also define javaTimeNanos_info, even if it happens to be the same as the Posix version. Alternatively I could put a comment block in there warning anyone who might change the implementation to check if the Posix version is still correct (and I'd change the ifdefs in the os_posix.cpp code). > src/hotspot/os/posix/os_posix.hpp line 95: > >> 93: static void ucontext_set_pc(ucontext_t* ctx, address pc); >> 94: >> 95: static bool supports_monotonic_clock(); > > Why do we need this API at all now? > > thread.cpp uses it here: > > assert(!os::supports_monotonic_clock(), > "unexpected time moving backwards detected in JavaThread::sleep()"); > > so we can just remove this usage? Good catch! Yes we can do this. I had intended to do it but got distracted by the linking issues and forgot about it. > src/hotspot/os/posix/os_posix.cpp line 1161: > >> 1159: >> 1160: void os::Posix::init_2(void) { >> 1161: log_info(os)("Use of CLOCK_MONOTONIC is supported"); > > We are keeping this output to avoid breaking whomever might be looking for this text? I find it useful information, especially in conjunction with the lines that follow, and allows comparing different JDK versions. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2090 > From dholmes at openjdk.java.net Thu Jan 21 05:24:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 21 Jan 2021 05:24:09 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v5] In-Reply-To: References: Message-ID: > We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. > > As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. > > The changes are in layered commits: > > Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. > Step 2: make supports_monotonic_clock always true and so remove checking in OS code > Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) > Step 4: Move shared time functions to os_posix.cpp > Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 > > Testing: tiers 1-3 for functional testing > built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 David Holmes has updated the pull request incrementally with one additional commit since the last revision: Remove the always true os::supports_monotonic_clock() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2090/files - new: https://git.openjdk.java.net/jdk/pull/2090/files/049bc73c..99ba6528 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2090&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2090&range=03-04 Stats: 29 lines in 8 files changed: 0 ins; 27 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2090/head:pull/2090 PR: https://git.openjdk.java.net/jdk/pull/2090 From rwestberg at openjdk.java.net Thu Jan 21 09:06:50 2021 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Thu, 21 Jan 2021 09:06:50 GMT Subject: RFR: 8258477: Pre-submit testing using GitHub Actions should merge changes from target branch In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 10:47:50 GMT, Robin Westberg wrote: > Normally when running GitHub Actions on a pull request, what is checked out is the merge of the pull request with the latest changes on the target branch. This ensure that what is tested is as close as possible to what will actually be the result of integrating said pull request. > > In our use of GitHub Actions, we don't run directly on pull requests but instead allow contributors to run them in their own personal forks. In that context, there is no notion of a target branch. However, we can infer the target project and branch by encoding this in the workflow file. This allows us to perform the same merge manually, and achieve the same behaviour. > > The change also adds an option to disable this automated merge when launching the workflow manually, which could be useful when investigating unexpected test failures. > > Note that downstream projects picking up this change will have to adapt the workflow file to keep using these actions for pre-submit testing. This has been a common request from downstream projects, but could also be done in a separate change (or not at all). So, is there anyone who would like to review this? I still think it will improve the effectiveness of the GitHub Actions-based testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1801 From gziemski at openjdk.java.net Thu Jan 21 15:40:59 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 21 Jan 2021 15:40:59 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v5] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 05:24:09 GMT, David Holmes wrote: >> We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. >> >> As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. >> >> The changes are in layered commits: >> >> Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. >> Step 2: make supports_monotonic_clock always true and so remove checking in OS code >> Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) >> Step 4: Move shared time functions to os_posix.cpp >> Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 >> >> Testing: tiers 1-3 for functional testing >> built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Remove the always true os::supports_monotonic_clock() Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2090 From dongbohe at openjdk.java.net Fri Jan 22 01:41:56 2021 From: dongbohe at openjdk.java.net (Dongbo He) Date: Fri, 22 Jan 2021 01:41:56 GMT Subject: RFR: 8260272: bash configure --prefix does not work after JDK-8257679 Message-ID: 8260272: bash configure --prefix does not work after JDK-8257679 ------------- Commit messages: - 8260272: bash configure --prefix does not work after JDK-8257679 Changes: https://git.openjdk.java.net/jdk/pull/2189/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2189&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260272 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2189.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2189/head:pull/2189 PR: https://git.openjdk.java.net/jdk/pull/2189 From dongbohe at openjdk.java.net Fri Jan 22 04:49:07 2021 From: dongbohe at openjdk.java.net (Dongbo He) Date: Fri, 22 Jan 2021 04:49:07 GMT Subject: RFR: 8260272: bash configure --prefix does not work after JDK-8257679 [v2] In-Reply-To: References: Message-ID: > $ bash configure --prefix=/home/hedongbo/jdk-release > $ make install > ... > Creating CDS archive for jdk image > Creating CDS-NOCOOPS archive for jdk image > Installing jdk image into /jvm/openjdk-17-internal > and creating 60 links from /bin into the jdk. > > make[3]: *** [install] Error 1 > Install.gmk:36: recipe for target 'install' failed > make/Main.gmk:786: recipe for target 'install' failed > make[2]: *** [install] Error 2 > > ERROR: Build failed for target 'install' in configuration 'linux-x86_64-server-release' (exit code 2) > Stopping sjavac server > > === Make failed targets repeated here === > Install.gmk:36: recipe for target 'install' failed > make/Main.gmk:786: recipe for target 'install' failed > === End of repeated output === > > Hint: Try searching the build log for the name of the first failed target. > Hint: See doc/building.html#troubleshooting for assistance. > > make[1]: *** [main] Error 2 > > make: *** [install] Error 2 > > > > > The reason is that the prefix variable used in `make/autoconf/util_paths.m4` conflicts with the prefix used in `make/autoconf/spec.gmk.in:780`. Dongbo He 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 one new commit since the last revision: 8260272: bash configure --prefix does not work after JDK-8257679 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2189/files - new: https://git.openjdk.java.net/jdk/pull/2189/files/7627b597..987837ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2189&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2189&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2189.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2189/head:pull/2189 PR: https://git.openjdk.java.net/jdk/pull/2189 From stuefe at openjdk.java.net Fri Jan 22 10:13:57 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 22 Jan 2021 10:13:57 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v5] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 15:26:43 GMT, Gerard Ziemski wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the always true os::supports_monotonic_clock() > > Marked as reviewed by gziemski (Committer). Builds fine on AIX. I scheduled tests for the coming nights. About os::javaTimeNanos, not sure if we still need that for AIX, but monotonic clocks gave us a lot of grief in the past on that .. platform and I prefer it to leave that way for now. Investigating if we can use clock_gettime for os::javaTimeNanos like Linux does can be done in a separate RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/2090 From erikj at openjdk.java.net Fri Jan 22 14:41:06 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 22 Jan 2021 14:41:06 GMT Subject: RFR: 8260272: bash configure --prefix does not work after JDK-8257679 [v2] In-Reply-To: References: Message-ID: <41ddIlGYBjpChtAETrRtsnS4kyhQBrlM27PWrc_AGYs=.da46cb18-342d-443d-a096-f9cbf98b8589@github.com> On Fri, 22 Jan 2021 04:49:07 GMT, Dongbo He wrote: >> $ bash configure --prefix=/home/hedongbo/jdk-release >> $ make install >> ... >> Creating CDS archive for jdk image >> Creating CDS-NOCOOPS archive for jdk image >> Installing jdk image into /jvm/openjdk-17-internal >> and creating 60 links from /bin into the jdk. >> >> make[3]: *** [install] Error 1 >> Install.gmk:36: recipe for target 'install' failed >> make/Main.gmk:786: recipe for target 'install' failed >> make[2]: *** [install] Error 2 >> >> ERROR: Build failed for target 'install' in configuration 'linux-x86_64-server-release' (exit code 2) >> Stopping sjavac server >> >> === Make failed targets repeated here === >> Install.gmk:36: recipe for target 'install' failed >> make/Main.gmk:786: recipe for target 'install' failed >> === End of repeated output === >> >> Hint: Try searching the build log for the name of the first failed target. >> Hint: See doc/building.html#troubleshooting for assistance. >> >> make[1]: *** [main] Error 2 >> >> make: *** [install] Error 2 >> >> >> >> >> The reason is that the prefix variable used in `make/autoconf/util_paths.m4` conflicts with the prefix used in `make/autoconf/spec.gmk.in:780`. > > Dongbo He 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. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2189 From ihse at openjdk.java.net Fri Jan 22 15:11:45 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 22 Jan 2021 15:11:45 GMT Subject: RFR: 8260272: bash configure --prefix does not work after JDK-8257679 [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 04:49:07 GMT, Dongbo He wrote: >> $ bash configure --prefix=/home/hedongbo/jdk-release >> $ make install >> ... >> Creating CDS archive for jdk image >> Creating CDS-NOCOOPS archive for jdk image >> Installing jdk image into /jvm/openjdk-17-internal >> and creating 60 links from /bin into the jdk. >> >> make[3]: *** [install] Error 1 >> Install.gmk:36: recipe for target 'install' failed >> make/Main.gmk:786: recipe for target 'install' failed >> make[2]: *** [install] Error 2 >> >> ERROR: Build failed for target 'install' in configuration 'linux-x86_64-server-release' (exit code 2) >> Stopping sjavac server >> >> === Make failed targets repeated here === >> Install.gmk:36: recipe for target 'install' failed >> make/Main.gmk:786: recipe for target 'install' failed >> === End of repeated output === >> >> Hint: Try searching the build log for the name of the first failed target. >> Hint: See doc/building.html#troubleshooting for assistance. >> >> make[1]: *** [main] Error 2 >> >> make: *** [install] Error 2 >> >> >> >> >> The reason is that the prefix variable used in `make/autoconf/util_paths.m4` conflicts with the prefix used in `make/autoconf/spec.gmk.in:780`. > > Dongbo He 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. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2189 From ihse at openjdk.java.net Fri Jan 22 15:16:52 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 22 Jan 2021 15:16:52 GMT Subject: RFR: 8259942: Enable customizations in CompileJavaModules.gmk and Main.gmk In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 18:27:14 GMT, Adam Farley wrote: > Ensure make files look on the include path or in PHASE_MAKEDIRS for > customizations. > > Change also adds a tidy-up that improves readability. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2134 From hseigel at openjdk.java.net Fri Jan 22 16:20:40 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 22 Jan 2021 16:20:40 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v5] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 05:24:09 GMT, David Holmes wrote: >> We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. >> >> As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. >> >> The changes are in layered commits: >> >> Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. >> Step 2: make supports_monotonic_clock always true and so remove checking in OS code >> Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) >> Step 4: Move shared time functions to os_posix.cpp >> Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 >> >> Testing: tiers 1-3 for functional testing >> built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Remove the always true os::supports_monotonic_clock() Hi David, The changes look good. Just a couple of nits. 1. Could you add a comment explaining why AIX and BSD have their own version of javaTimeNanos_info(). 2. A few copyrights need to be updated to 2021. Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2090 From akozlov at openjdk.java.net Fri Jan 22 20:02:56 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 22 Jan 2021 20:02:56 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port Message-ID: Please review the implementation of JEP 391: macOS/AArch64 Port. It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. Major changes are in: * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) ------------- Commit messages: - Fix build - JDK-8253816: Update after recent changes - Rework gtests to always have wx_write - Revert gtest changes - Fix gtests in debug - Merge remote-tracking branch 'upstream/master' into jdk-macos - Fix windows_aarch64 - Use r18_tls instead of r18_reserved - JDK-8253742: bsd_aarch64 part - JDK-8257882: bsd_aarch64 part - ... and 40 more: https://git.openjdk.java.net/jdk/compare/82adfb32...3d4f4c23 Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253795 Stats: 3335 lines in 117 files changed: 3230 ins; 41 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From erikj at openjdk.java.net Fri Jan 22 20:27:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 22 Jan 2021 20:27:42 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port In-Reply-To: References: Message-ID: <_l6v7_5ODWCmW5x90hA_Vv0TegGm00YW98ELrJvi65o=.1b2d4f0f-0791-4d4f-bf00-d829738611b5@github.com> On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov wrote: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Build changes in general look good. make/autoconf/flags-cflags.m4 line 169: > 167: WARNINGS_ENABLE_ALL="-Wall -Wextra -Wformat=2 $WARNINGS_ENABLE_ADDITIONAL" > 168: > 169: DISABLED_WARNINGS="unknown-warning-option unused-parameter unused format-nonliteral" Globally disabling a warning needs some motivation. Why is this needed? Does it really need to be applied everywhere or is there a specific binary or source file where this is triggered? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From alanb at openjdk.java.net Sat Jan 23 07:57:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 23 Jan 2021 07:57:43 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote: >> This PR is not stale; it's just still waiting for input from @AlanBateman. > > @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? > @AlanBateman When I moved the charset templates, I found this gold nugget: > > ``` > # Copy two Java files that need no preprocessing. > $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template > $(call LogInfo, Generating $(@F)) > $(call install-file) > > GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \ > $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java > ``` > > What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) That definitely needs cleaning up, but this PR is large enough as it is, so I will not do it now. Good find, surprised this wasn't spotted before now. We should create a separate issue to rename them and get rid of the copying in the make file. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From aph at openjdk.java.net Sat Jan 23 11:46:45 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Sat, 23 Jan 2021 11:46:45 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov wrote: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86: > 84: > 85: switch (_num_int_args) { > 86: case 0: I don't think you need such a large switch statement. I think this can be expressed as if (num_int_args <= 6) { ldr(as_Register(num_int_args + 1), src); ... etc. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 43: > 41: //describe amount of space in bytes occupied by type on native stack > 42: #ifdef __APPLE__ > 43: const int nativeByteSpace = sizeof(jbyte); I'm not sure these names should be in the global name space, and they're not very descriptive. Something like NativeStack::byteSpace would be better. Then you can use them with a `using namespace NativeStack` declaration. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 433: > 431: store_and_inc(_to, from_obj, nativeShortSpace); > 432: > 433: _num_int_args++; Please lift this increment out of the conditional. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394: > 392: > 393: class SlowSignatureHandler > 394: : public NativeSignatureIterator { SlowSignatureHandler is turning into a maintenance nightmare. This isn't the fault of this commit so much as some nasty cut-and=paste programming in the code you're editing. It might well be better to rewrite this whole thing to use a table-driven approach, with a table that contains the increment and the size of each native type: then we'd have only a single routine which could pass data of any type, and each OS needs only supply a table of constants. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272: > 5270: void MacroAssembler::get_thread(Register dst) { > 5271: RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst; > 5272: push(saved_regs, sp); This isn't very nice. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Sun Jan 24 15:32:59 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Sun, 24 Jan 2021 15:32:59 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Address feedback for signature generators - Enable -Wformat-nonliteral back ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/3d4f4c23..50b55f66 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=00-01 Stats: 204 lines in 2 files changed: 20 ins; 138 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Sun Jan 24 15:37:43 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Sun, 24 Jan 2021 15:37:43 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <_l6v7_5ODWCmW5x90hA_Vv0TegGm00YW98ELrJvi65o=.1b2d4f0f-0791-4d4f-bf00-d829738611b5@github.com> References: <_l6v7_5ODWCmW5x90hA_Vv0TegGm00YW98ELrJvi65o=.1b2d4f0f-0791-4d4f-bf00-d829738611b5@github.com> Message-ID: On Fri, 22 Jan 2021 20:18:51 GMT, Erik Joelsson wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > make/autoconf/flags-cflags.m4 line 169: > >> 167: WARNINGS_ENABLE_ALL="-Wall -Wextra -Wformat=2 $WARNINGS_ENABLE_ADDITIONAL" >> 168: >> 169: DISABLED_WARNINGS="unknown-warning-option unused-parameter unused format-nonliteral" > > Globally disabling a warning needs some motivation. Why is this needed? Does it really need to be applied everywhere or is there a specific binary or source file where this is triggered? It seems to be a leftover from the past. I tried to revert the line and the build went fine. Thanks for noticing! ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Sun Jan 24 15:52:44 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Sun, 24 Jan 2021 15:52:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 11:10:17 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86: > >> 84: >> 85: switch (_num_int_args) { >> 86: case 0: > > I don't think you need such a large switch statement. I think this can be expressed as > if (num_int_args <= 6) { > ldr(as_Register(num_int_args + r1.encoding()), src); > ... etc. I like the suggestion. For the defense, new functions were made this way intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment as a blessing to fix all of them. But I feel that refactoring of existing code should go in a separate commit. Especially after `pass_int` used `ldr/str` instead of `ldrw/strw`, which looks wrong. https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Sun Jan 24 16:13:42 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Sun, 24 Jan 2021 16:13:42 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 11:42:48 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394: > >> 392: >> 393: class SlowSignatureHandler >> 394: : public NativeSignatureIterator { > > SlowSignatureHandler is turning into a maintenance nightmare. This isn't the fault of this commit so much as some nasty cut-and-paste programming in the code you're editing. It might well be better to rewrite this whole thing to use a table-driven approach, with a table that contains the increment and the size of each native type: then we'd have only a single routine which could pass data of any type, and each OS needs only supply a table of constants. Would you like me to do something about it now? The problem is that the functions of SlowSignatureHandler are subtly different, so it will be multiple tables, not sure how many. Such change is another candidate for a separate code enhancement, which I would like not to mix into the JEP implementation (it's already not a small change :)). But if you think it would be a good thing, please let me know. In another case, I'll add this to a queue of follow-up enhancements. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Sun Jan 24 16:32:41 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Sun, 24 Jan 2021 16:32:41 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 11:43:31 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272: > >> 5270: void MacroAssembler::get_thread(Register dst) { >> 5271: RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst; >> 5272: push(saved_regs, sp); > > This isn't very nice. Hello Why is it not nice ? linux_aarch64 uses some linux specific tls function _ZN10JavaThread25aarch64_get_thread_helperEv from hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s which clobbers only r0 and r1 macos_aarch64 has no such tls code and uses generic C-call to Thread::current(); Hence we are saving possibly clobbered regs here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From dongbohe at openjdk.java.net Mon Jan 25 01:11:40 2021 From: dongbohe at openjdk.java.net (Dongbo He) Date: Mon, 25 Jan 2021 01:11:40 GMT Subject: Integrated: 8260272: bash configure --prefix does not work after JDK-8257679 In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 01:29:10 GMT, Dongbo He wrote: > $ bash configure --prefix=/home/hedongbo/jdk-release > $ make install > ... > Creating CDS archive for jdk image > Creating CDS-NOCOOPS archive for jdk image > Installing jdk image into /jvm/openjdk-17-internal > and creating 60 links from /bin into the jdk. > > make[3]: *** [install] Error 1 > Install.gmk:36: recipe for target 'install' failed > make/Main.gmk:786: recipe for target 'install' failed > make[2]: *** [install] Error 2 > > ERROR: Build failed for target 'install' in configuration 'linux-x86_64-server-release' (exit code 2) > Stopping sjavac server > > === Make failed targets repeated here === > Install.gmk:36: recipe for target 'install' failed > make/Main.gmk:786: recipe for target 'install' failed > === End of repeated output === > > Hint: Try searching the build log for the name of the first failed target. > Hint: See doc/building.html#troubleshooting for assistance. > > make[1]: *** [main] Error 2 > > make: *** [install] Error 2 > > > > > The reason is that the prefix variable used in `make/autoconf/util_paths.m4` conflicts with the prefix used in `make/autoconf/spec.gmk.in:780`. This pull request has now been integrated. Changeset: 764111ff Author: Dongbo He Committer: Fei Yang URL: https://git.openjdk.java.net/jdk/commit/764111ff Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod 8260272: bash configure --prefix does not work after JDK-8257679 Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/2189 From dholmes at openjdk.java.net Mon Jan 25 04:46:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 25 Jan 2021 04:46:52 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v6] In-Reply-To: References: Message-ID: > We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. > > As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. > > The changes are in layered commits: > > Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. > Step 2: make supports_monotonic_clock always true and so remove checking in OS code > Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) > Step 4: Move shared time functions to os_posix.cpp > Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 > > Testing: tiers 1-3 for functional testing > built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - 'Merge branch 'master' into 8246112-mono - Update copyrights - Remove the always true os::supports_monotonic_clock() - Merge - Merge branch 'master' into 8246112-mono - Restrict librt linking to JVM - per Magnus's request - Merge branch 'master' into 8246112-mono - Alway link librt on Linux so we don't rely on glibc > 2.12 - Step 4: Move shared time functions to os_posix.cpp - Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) - ... and 2 more: https://git.openjdk.java.net/jdk/compare/764111ff...f4bf2b8a ------------- Changes: https://git.openjdk.java.net/jdk/pull/2090/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2090&range=05 Stats: 412 lines in 16 files changed: 54 ins; 326 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/2090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2090/head:pull/2090 PR: https://git.openjdk.java.net/jdk/pull/2090 From stuefe at openjdk.java.net Mon Jan 25 07:19:43 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 25 Jan 2021 07:19:43 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v5] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 16:17:57 GMT, Harold Seigel wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the always true os::supports_monotonic_clock() > > Hi David, > The changes look good. Just a couple of nits. > 1. Could you add a comment explaining why AIX and BSD have their own version of javaTimeNanos_info(). > 2. A few copyrights need to be updated to 2021. > Thanks, Harold I don't see any new issues on AIX in our tests with this patch. Thanks for waiting! ------------- PR: https://git.openjdk.java.net/jdk/pull/2090 From david.holmes at oracle.com Mon Jan 25 07:57:15 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Jan 2021 17:57:15 +1000 Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v5] In-Reply-To: References: Message-ID: <41d3e114-8e1f-6298-ce94-7ae426b1856f@oracle.com> On 25/01/2021 5:19 pm, Thomas Stuefe wrote: > On Fri, 22 Jan 2021 16:17:57 GMT, Harold Seigel wrote: > >>> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Remove the always true os::supports_monotonic_clock() >> >> Hi David, >> The changes look good. Just a couple of nits. >> 1. Could you add a comment explaining why AIX and BSD have their own version of javaTimeNanos_info(). >> 2. A few copyrights need to be updated to 2021. >> Thanks, Harold > > I don't see any new issues on AIX in our tests with this patch. Thanks for waiting! Thanks Thomas! David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2090 > From aph at openjdk.java.net Mon Jan 25 10:00:41 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 25 Jan 2021 10:00:41 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On Sun, 24 Jan 2021 16:10:44 GMT, Anton Kozlov wrote: >> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394: >> >>> 392: >>> 393: class SlowSignatureHandler >>> 394: : public NativeSignatureIterator { >> >> SlowSignatureHandler is turning into a maintenance nightmare. This isn't the fault of this commit so much as some nasty cut-and-paste programming in the code you're editing. It might well be better to rewrite this whole thing to use a table-driven approach, with a table that contains the increment and the size of each native type: then we'd have only a single routine which could pass data of any type, and each OS needs only supply a table of constants. > > Would you like me to do something about it now? The problem is that the functions of SlowSignatureHandler are subtly different, so it will be multiple tables, not sure how many. Such change is another candidate for a separate code enhancement, which I would like not to mix into the JEP implementation (it's already not a small change :)). But if you think it would be a good thing, please let me know. In another case, I'll add this to a queue of follow-up enhancements. I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aph at openjdk.java.net Mon Jan 25 10:00:43 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 25 Jan 2021 10:00:43 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On Sun, 24 Jan 2021 16:29:31 GMT, Vladimir Kempik wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272: >> >>> 5270: void MacroAssembler::get_thread(Register dst) { >>> 5271: RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst; >>> 5272: push(saved_regs, sp); >> >> This isn't very nice. > > Hello > Why is it not nice ? > linux_aarch64 uses some linux specific tls function _ZN10JavaThread25aarch64_get_thread_helperEv from hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s > which clobbers only r0 and r1 > macos_aarch64 has no such tls code and uses generic C-call to Thread::current(); > Hence we are saving possibly clobbered regs here. Surely if you did as Linux does you wouldn't need to clobber all those registers. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aleonard at openjdk.java.net Mon Jan 25 13:01:55 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Mon, 25 Jan 2021 13:01:55 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 Message-ID: A problem was found downstream with Eclipse OpenJ9 builds whereby since JDK-8258411 they were unable to extend the module lists. This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to enable the module list extension again. Signed-off-by: Andrew Leonard ------------- Commit messages: - 8260289: Unable to customize module lists after change JDK-8258411 Changes: https://git.openjdk.java.net/jdk/pull/2219/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2219&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260289 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2219.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2219/head:pull/2219 PR: https://git.openjdk.java.net/jdk/pull/2219 From ihse at openjdk.java.net Mon Jan 25 13:11:41 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 25 Jan 2021 13:11:41 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 12:57:29 GMT, Andrew Leonard wrote: > A problem was found downstream with Eclipse OpenJ9 builds whereby since JDK-8258411 they were unable to extend the module lists. > This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to enable the module list extension again. > > Signed-off-by: Andrew Leonard Changes requested by ihse (Reviewer). make/conf/module-loader-map.conf line 100: > 98: # Hook to include the corresponding custom file, if present. > 99: $(eval $(call IncludeCustomExtension, conf/module-loader-map.conf)) > 100: Using IncludeCustomExtension is a good idea, but you should to this where module-loader-map.conf is included in common/Modules.gmk, not here. The `*.conf` files are supposed to be formatted as simple configuration files, and not include special make commands. ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From aleonard at openjdk.java.net Mon Jan 25 13:16:41 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Mon, 25 Jan 2021 13:16:41 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 13:08:53 GMT, Magnus Ihse Bursie wrote: >> A problem was found downstream with Eclipse OpenJ9 builds whereby since JDK-8258411 they were unable to extend the module lists. >> This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to enable the module list extension again. >> >> Signed-off-by: Andrew Leonard > > make/conf/module-loader-map.conf line 100: > >> 98: # Hook to include the corresponding custom file, if present. >> 99: $(eval $(call IncludeCustomExtension, conf/module-loader-map.conf)) >> 100: > > Using IncludeCustomExtension is a good idea, but you should to this where module-loader-map.conf is included in common/Modules.gmk, not here. The `*.conf` files are supposed to be formatted as simple configuration files, and not include special make commands. Ah ok thanks Magnus, didn't realize that, I will update ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From alanb at openjdk.java.net Mon Jan 25 13:22:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 25 Jan 2021 13:22:41 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 13:08:53 GMT, Magnus Ihse Bursie wrote: >> A problem was found downstream with Eclipse OpenJ9 builds whereby since JDK-8258411 they were unable to extend the module lists. >> This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to enable the module list extension again. >> >> Signed-off-by: Andrew Leonard > > make/conf/module-loader-map.conf line 100: > >> 98: # Hook to include the corresponding custom file, if present. >> 99: $(eval $(call IncludeCustomExtension, conf/module-loader-map.conf)) >> 100: > > Using IncludeCustomExtension is a good idea, but you should to this where module-loader-map.conf is included in common/Modules.gmk, not here. The `*.conf` files are supposed to be formatted as simple configuration files, and not include special make commands. @magicus Is there an ordering issue in common/Modules.gmk? It also invokes IncludeCustomExtension but this is done before it includes the conf file. ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From aleonard at openjdk.java.net Mon Jan 25 13:25:50 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Mon, 25 Jan 2021 13:25:50 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 13:19:31 GMT, Alan Bateman wrote: >> make/conf/module-loader-map.conf line 100: >> >>> 98: # Hook to include the corresponding custom file, if present. >>> 99: $(eval $(call IncludeCustomExtension, conf/module-loader-map.conf)) >>> 100: >> >> Using IncludeCustomExtension is a good idea, but you should to this where module-loader-map.conf is included in common/Modules.gmk, not here. The `*.conf` files are supposed to be formatted as simple configuration files, and not include special make commands. > > @magicus Is there an ordering issue in common/Modules.gmk? It also invokes IncludeCustomExtension but this is done before it includes the conf file. @AlanBateman Yes, that's what JDK-8258411 inadvertently changed and I am fixing. I am going to now move the common/Modules.gmk IncludeCustomExtension after the module-loader-map.conf include. ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From ihse at openjdk.java.net Mon Jan 25 13:25:53 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 25 Jan 2021 13:25:53 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Address feedback for signature generators > - Enable -Wformat-nonliteral back Changes requested by ihse (Reviewer). make/autoconf/jvm-features.m4 line 269: > 267: if test "x$OPENJDK_TARGET_OS" != xaix && \ > 268: !( test "x$OPENJDK_TARGET_OS" = "xmacosx" && \ > 269: test "x$OPENJDK_TARGET_CPU" = "xaarch64" ) ; then This test is making my head spin. Can't you just invert it to this structure: if OS=aix || OS+CPU = mac+aarch64; then no else yes fi make/autoconf/platform.m4 line 75: > 73: ;; > 74: esac > 75: ;; This is solved in the wrong place. This code should just use the result from `config.guess/config.sub`. These files are imported from the autoconf project. Unfortunately, they have changed the license to one incompatible with OpenJDK, so we are stuck with an old version. Instead, we have created a "bugfix wrapper" that calls the original `autoconf-config.guess/sub` and fixes up the result, with stuff like this. make/autoconf/platform.m4 line 273: > 271: # Convert the autoconf OS/CPU value to our own data, into the VAR_OS/CPU/LIBC variables. > 272: PLATFORM_EXTRACT_VARS_FROM_OS($build_os) > 273: PLATFORM_EXTRACT_VARS_FROM_CPU($build_cpu, $build_os) Fixing the comment above means this change, and the one below, can be reverted. make/common/NativeCompilation.gmk line 1180: > 1178: # silently fail otherwise. > 1179: ifneq ($(CODESIGN), ) > 1180: $(CODESIGN) -f -s "$(MACOSX_CODESIGN_IDENTITY)" --timestamp --options runtime \ What does -f do, and is it needed for macos-x64 as well? make/modules/jdk.hotspot.agent/Lib.gmk line 34: > 32: > 33: else ifeq ($(call isTargetOs, macosx), true) > 34: SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \ Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons). ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From hseigel at openjdk.java.net Mon Jan 25 13:26:46 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 25 Jan 2021 13:26:46 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v5] In-Reply-To: References: Message-ID: <-G9GGkWyMRc9ZecE9Xh_BVGmG120NkJeeJL86mXihgQ=.0debcd59-b00f-4d59-8ea8-a1aec12fe170@github.com> On Mon, 25 Jan 2021 07:17:13 GMT, Thomas Stuefe wrote: >> Hi David, >> The changes look good. Just a couple of nits. >> 1. Could you add a comment explaining why AIX and BSD have their own version of javaTimeNanos_info(). >> 2. A few copyrights need to be updated to 2021. >> Thanks, Harold > > I don't see any new issues on AIX in our tests with this patch. Thanks for waiting! Hi David, I think that os_posix.cpp is a good place to put a comment explaining why AIX and BSD have their own javaTimeNanos_info(). Stating something like "AIX and BSD have their own versions because their implementations of monotonic time have worked on those platforms." seems fine. Thanks for doing this! Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/2090 From ihse at openjdk.java.net Mon Jan 25 13:30:41 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 25 Jan 2021 13:30:41 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 13:19:31 GMT, Alan Bateman wrote: >> make/conf/module-loader-map.conf line 100: >> >>> 98: # Hook to include the corresponding custom file, if present. >>> 99: $(eval $(call IncludeCustomExtension, conf/module-loader-map.conf)) >>> 100: >> >> Using IncludeCustomExtension is a good idea, but you should to this where module-loader-map.conf is included in common/Modules.gmk, not here. The `*.conf` files are supposed to be formatted as simple configuration files, and not include special make commands. > > @magicus Is there an ordering issue in common/Modules.gmk? It also invokes IncludeCustomExtension but this is done before it includes the conf file. @AlanBateman I'm not sure. Frankly, most of the IncludeCustomExtension hooks are no longer used by Oracle since we've moved most of our code out in the open, so they kind of bit rot... I should probably do a sweep and ask the community which one to still keep, and remove the rest. > @AlanBateman Yes, that's what JDK-8258411 inadvertently changed and I am fixing. I am going to now move the common/Modules.gmk IncludeCustomExtension after the module-loader-map.conf include. Andrew, why can't you just use the existing IncludeCustomExtension then to load your own module-loader-map.conf? Or maybe that's just what you are going to do? ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From vkempik at openjdk.java.net Mon Jan 25 13:33:47 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 25 Jan 2021 13:33:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 13:18:34 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > make/common/NativeCompilation.gmk line 1180: > >> 1178: # silently fail otherwise. >> 1179: ifneq ($(CODESIGN), ) >> 1180: $(CODESIGN) -f -s "$(MACOSX_CODESIGN_IDENTITY)" --timestamp --options runtime \ > > What does -f do, and is it needed for macos-x64 as well? -f - replace signature if it's present, if not - just sign as usual macos-aarch64 binaries always have adhoc signature, so need to replace it. > make/modules/jdk.hotspot.agent/Lib.gmk line 34: > >> 32: >> 33: else ifeq ($(call isTargetOs, macosx), true) >> 34: SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \ > > Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons). @luhenry , could you please check this comment, I think SA-agent was MS's job here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aleonard at openjdk.java.net Mon Jan 25 13:43:41 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Mon, 25 Jan 2021 13:43:41 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 13:27:29 GMT, Magnus Ihse Bursie wrote: >> @magicus Is there an ordering issue in common/Modules.gmk? It also invokes IncludeCustomExtension but this is done before it includes the conf file. > >> @AlanBateman Yes, that's what JDK-8258411 inadvertently changed and I am fixing. I am going to now move the common/Modules.gmk IncludeCustomExtension after the module-loader-map.conf include. > > Andrew, why can't you just use the existing IncludeCustomExtension then to load your own module-loader-map.conf? Or maybe that's just what you are going to do? The previous behavior provided the ability to "extend" the upstream MODULE lists, ie.just add OpenJ9 modules to the base module lists, see: https://github.com/ibmruntimes/openj9-openjdk-jdk/blob/01e13c398721628540babac94ac8663be716c0a8/closed/custom/common/Modules.gmk#L21 The present https://github.com/openjdk/jdk/blob/master/make/conf/module-loader-map.conf will simply over-write whatever is set in the BOOT_MODULES list. What I am now going to do is move the IncludeCustomExtension after the module-loader-map.conf inclusion. The other alternative would be to change module-loader-map.conf so it appended to any existing BOOT_MODULES variable, but I think you suggested that file is a straight conf file? @magicus thoughts? ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From aleonard at openjdk.java.net Mon Jan 25 13:47:58 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Mon, 25 Jan 2021 13:47:58 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 13:41:06 GMT, Andrew Leonard wrote: >>> @AlanBateman Yes, that's what JDK-8258411 inadvertently changed and I am fixing. I am going to now move the common/Modules.gmk IncludeCustomExtension after the module-loader-map.conf include. >> >> Andrew, why can't you just use the existing IncludeCustomExtension then to load your own module-loader-map.conf? Or maybe that's just what you are going to do? > > The previous behavior provided the ability to "extend" the upstream MODULE lists, ie.just add OpenJ9 modules to the base module lists, see: https://github.com/ibmruntimes/openj9-openjdk-jdk/blob/01e13c398721628540babac94ac8663be716c0a8/closed/custom/common/Modules.gmk#L21 > > The present https://github.com/openjdk/jdk/blob/master/make/conf/module-loader-map.conf will simply over-write whatever is set in the BOOT_MODULES list. > > What I am now going to do is move the IncludeCustomExtension after the module-loader-map.conf inclusion. > The other alternative would be to change module-loader-map.conf so it appended to any existing BOOT_MODULES variable, but I think you suggested that file is a straight conf file? > > @magicus thoughts? Note, it was the change from "appending" to BOOT_MODULES to just "assigning" that broke the existing behaviour with the JDK-8258411 change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From vkempik at openjdk.java.net Mon Jan 25 14:09:44 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 25 Jan 2021 14:09:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 14:03:40 GMT, Per Liden wrote: > In `make/autoconf/jvm-features.m4` I notice that you haven't enabled ZGC for macos/aarch64. Is that just an oversight, or is there a reason for that? because it does not work processor_id has no "official docs"-friendly implementation, only a hacky one from ios world. Also ZGC needs additional W^X work. I believe zgc supports needs to be done in a separate commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From pliden at openjdk.java.net Mon Jan 25 14:06:46 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 25 Jan 2021 14:06:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 13:23:27 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > Changes requested by ihse (Reviewer). In `make/autoconf/jvm-features.m4` I notice that you haven't enabled ZGC for macos/aarch64. Is that just an oversight, or is there a reason for that? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aleonard at openjdk.java.net Mon Jan 25 14:20:01 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Mon, 25 Jan 2021 14:20:01 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2] In-Reply-To: References: Message-ID: <3n3i-nntO7sFuxwQ8bVNfLqONpEuNS5IG1Z96uoi3Tc=.1f8a1269-ba62-40f4-96d4-aaed02d6ba2c@github.com> > A problem was found downstream with Eclipse OpenJ9 builds whereby since JDK-8258411 they were unable to extend the module lists. > This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to enable the module list extension again. > > Signed-off-by: Andrew Leonard Andrew Leonard 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 one new commit since the last revision: 8260289: Unable to customize module lists after change JDK-8258411 Signed-off-by: Andrew Leonard ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2219/files - new: https://git.openjdk.java.net/jdk/pull/2219/files/0250fdcc..ffd53bff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2219&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2219&range=00-01 Stats: 14 lines in 2 files changed: 5 ins; 7 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2219.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2219/head:pull/2219 PR: https://git.openjdk.java.net/jdk/pull/2219 From aleonard at openjdk.java.net Mon Jan 25 14:20:02 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Mon, 25 Jan 2021 14:20:02 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 13:08:58 GMT, Magnus Ihse Bursie wrote: >> Andrew Leonard 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 one new commit since the last revision: >> >> 8260289: Unable to customize module lists after change JDK-8258411 >> >> Signed-off-by: Andrew Leonard > > Changes requested by ihse (Reviewer). @magicus do you know what the magic pull request command is to re-generate the webrev having updated the commit? ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From ihse at openjdk.java.net Mon Jan 25 14:20:02 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 25 Jan 2021 14:20:02 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 13:45:23 GMT, Andrew Leonard wrote: >> The previous behavior provided the ability to "extend" the upstream MODULE lists, ie.just add OpenJ9 modules to the base module lists, see: https://github.com/ibmruntimes/openj9-openjdk-jdk/blob/01e13c398721628540babac94ac8663be716c0a8/closed/custom/common/Modules.gmk#L21 >> >> The present https://github.com/openjdk/jdk/blob/master/make/conf/module-loader-map.conf will simply over-write whatever is set in the BOOT_MODULES list. >> >> What I am now going to do is move the IncludeCustomExtension after the module-loader-map.conf inclusion. >> The other alternative would be to change module-loader-map.conf so it appended to any existing BOOT_MODULES variable, but I think you suggested that file is a straight conf file? >> >> @magicus thoughts? > > Note, it was the change from "appending" to BOOT_MODULES to just "assigning" that broke the existing behaviour with the JDK-8258411 change. @andrew-m-leonard (Seems I can't get github to tag you???) That sounds good. I think you could move the IncludeCustomExtension to after all *.conf files, to future-proof it and to make it a bit more consistent -- "first include conf files, then adjust them in custom extensions". ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From aleonard at openjdk.java.net Mon Jan 25 14:20:02 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Mon, 25 Jan 2021 14:20:02 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 13:57:26 GMT, Magnus Ihse Bursie wrote: >> Note, it was the change from "appending" to BOOT_MODULES to just "assigning" that broke the existing behaviour with the JDK-8258411 change. > > @andrew-m-leonard (Seems I can't get github to tag you???) > > That sounds good. I think you could move the IncludeCustomExtension to after all *.conf files, to future-proof it and to make it a bit more consistent -- "first include conf files, then adjust them in custom extensions". @magicus yes, that's exactly the new commit i've just pushed. @(lookups) have been a bit wobbly recently with github.com I have noticed, I can find some people but not others! ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From coleenp at openjdk.java.net Mon Jan 25 14:39:49 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Jan 2021 14:39:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Address feedback for signature generators > - Enable -Wformat-nonliteral back src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87: > 85: JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env); > 86: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));; > 87: Thread::WXWriteFromExecSetter wx_write; Is this on every transition to VM from Native? Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From coleenp at openjdk.java.net Mon Jan 25 14:43:44 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Jan 2021 14:43:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com> On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Address feedback for signature generators > - Enable -Wformat-nonliteral back src/hotspot/share/runtime/thread.hpp line 915: > 913: verify_wx_state(WXExec); > 914: } > 915: }; Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and just add the class instance as a field in thread.hpp? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From coleenp at openjdk.java.net Mon Jan 25 14:43:46 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Jan 2021 14:43:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com> Message-ID: <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com> On Mon, 25 Jan 2021 14:40:09 GMT, Coleen Phillimore wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/hotspot/share/runtime/thread.hpp line 915: > >> 913: verify_wx_state(WXExec); >> 914: } >> 915: }; > > Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and just add the class instance as a field in thread.hpp? This could be a follow-up RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From martin at openjdk.java.net Mon Jan 25 14:49:41 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Mon, 25 Jan 2021 14:49:41 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2] In-Reply-To: References: Message-ID: <0wOgJTp1AEssSLbqCzD0SS3peoDYChpvyvMRq-GXUuM=.f8e41946-2163-4242-a7f8-0a15bf5715e4@github.com> On Mon, 25 Jan 2021 14:00:42 GMT, Andrew Leonard wrote: >> @andrew-m-leonard (Seems I can't get github to tag you???) >> >> That sounds good. I think you could move the IncludeCustomExtension to after all *.conf files, to future-proof it and to make it a bit more consistent -- "first include conf files, then adjust them in custom extensions". > > @magicus yes, that's exactly the new commit i've just pushed. > > @(lookups) have been a bit wobbly recently with github.com I have noticed, I can find some people but not others! @andrew-m-leonard try searching at https://github.com/orgs/openjdk/people ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From aleonard at openjdk.java.net Mon Jan 25 15:00:43 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Mon, 25 Jan 2021 15:00:43 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 13:57:26 GMT, Magnus Ihse Bursie wrote: >> Note, it was the change from "appending" to BOOT_MODULES to just "assigning" that broke the existing behaviour with the JDK-8258411 change. > > @andrew-m-leonard (Seems I can't get github to tag you???) > > That sounds good. I think you could move the IncludeCustomExtension to after all *.conf files, to future-proof it and to make it a bit more consistent -- "first include conf files, then adjust them in custom extensions". @magicus @AlanBateman please see new commit (webrev https://webrevs.openjdk.java.net/?repo=jdk&pr=2219&range=01) ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From akozlov at openjdk.java.net Mon Jan 25 15:03:44 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 25 Jan 2021 15:03:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 14:36:35 GMT, Coleen Phillimore wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87: > >> 85: JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env); >> 86: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));; >> 87: Thread::WXWriteFromExecSetter wx_write; > > Is this on every transition to VM from Native? Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is? I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aleonard at openjdk.java.net Mon Jan 25 15:14:42 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Mon, 25 Jan 2021 15:14:42 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 13:08:58 GMT, Magnus Ihse Bursie wrote: >> Andrew Leonard 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 one new commit since the last revision: >> >> 8260289: Unable to customize module lists after change JDK-8258411 >> >> Signed-off-by: Andrew Leonard > > Changes requested by ihse (Reviewer). > @magicus do you know what the magic pull request command is to re-generate the webrev having updated the commit? Ah looks like it automatically picked it up :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From ihse at openjdk.java.net Mon Jan 25 15:33:48 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 25 Jan 2021 15:33:48 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2] In-Reply-To: <3n3i-nntO7sFuxwQ8bVNfLqONpEuNS5IG1Z96uoi3Tc=.1f8a1269-ba62-40f4-96d4-aaed02d6ba2c@github.com> References: <3n3i-nntO7sFuxwQ8bVNfLqONpEuNS5IG1Z96uoi3Tc=.1f8a1269-ba62-40f4-96d4-aaed02d6ba2c@github.com> Message-ID: On Mon, 25 Jan 2021 14:20:01 GMT, Andrew Leonard wrote: >> A problem was found downstream with Eclipse OpenJ9 builds whereby since JDK-8258411 they were unable to extend the module lists. >> This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to enable the module list extension again. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard 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. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From alanb at openjdk.java.net Mon Jan 25 15:50:42 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 25 Jan 2021 15:50:42 GMT Subject: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2] In-Reply-To: <3n3i-nntO7sFuxwQ8bVNfLqONpEuNS5IG1Z96uoi3Tc=.1f8a1269-ba62-40f4-96d4-aaed02d6ba2c@github.com> References: <3n3i-nntO7sFuxwQ8bVNfLqONpEuNS5IG1Z96uoi3Tc=.1f8a1269-ba62-40f4-96d4-aaed02d6ba2c@github.com> Message-ID: <0UrM8vAQbpW9CyU2z6cjqmcmqOSWvBWKtjmc-b8gsco=.b013fe69-9756-4af1-9549-307199197cf8@github.com> On Mon, 25 Jan 2021 14:20:01 GMT, Andrew Leonard wrote: >> A problem was found downstream with Eclipse OpenJ9 builds whereby since JDK-8258411 they were unable to extend the module lists. >> This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to enable the module list extension again. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard 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 one new commit since the last revision: > > 8260289: Unable to customize module lists after change JDK-8258411 > > Signed-off-by: Andrew Leonard Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From burban at openjdk.java.net Mon Jan 25 16:02:45 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 25 Jan 2021 16:02:45 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 13:30:55 GMT, Vladimir Kempik wrote: >> make/modules/jdk.hotspot.agent/Lib.gmk line 34: >> >>> 32: >>> 33: else ifeq ($(call isTargetOs, macosx), true) >>> 34: SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \ >> >> Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons). > > @luhenry , could you please check this comment, I think SA-agent was MS's job here. The target is identified by the header file now: https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083f666367e25fba2b527a9a5bc8743a6R35-R41 Do you think there is any problem with this approach? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aph at openjdk.java.net Mon Jan 25 17:21:46 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 25 Jan 2021 17:21:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: <0WPkx3i-N0HHqCqrxE_B0Rf2akunbQaWQb7M7Z88BQY=.c582d11a-ba8d-4789-a55b-279e1286ad8d@github.com> On Sun, 24 Jan 2021 15:50:01 GMT, Anton Kozlov wrote: >> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86: >> >>> 84: >>> 85: switch (_num_int_args) { >>> 86: case 0: >> >> I don't think you need such a large switch statement. I think this can be expressed as >> if (num_int_args <= 6) { >> ldr(as_Register(num_int_args + r1.encoding()), src); >> ... etc. > > I like the suggestion. For the defense, new functions were made this way intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment as a blessing to fix all of them. But I feel that refactoring of existing code should go in a separate commit. Especially after `pass_int` used `ldr/str` instead of `ldrw/strw`, which looks wrong. https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122 This is new code, and it should not repeat the mistakes of the past. There's no need to refactor the similar existing code as part of this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From prr at openjdk.java.net Mon Jan 25 17:45:47 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 25 Jan 2021 17:45:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Address feedback for signature generators > - Enable -Wformat-nonliteral back Changes requested by prr (Reviewer). src/java.desktop/share/native/libharfbuzz/hb-common.h line 113: > 111: > 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF))) > 113: #define HB_UNTAG(tag) (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF) I need a robust explanation of these changes. They are not mentioned, nor are they in upstream harfbuzz. Likely these should be pushed to upstream first if there is a reason for them. src/java.desktop/share/native/libharfbuzz/hb-coretext.cc line 193: > 191: * crbug.com/549610 */ > 192: // 0x00070000 stands for "kCTVersionNumber10_10", see CoreText.h > 193: #if TARGET_OS_OSX && MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_10_10 I need a robust explanation of these changes. They are not mentioned, nor are they in upstream harfbuzz. Likely these should be pushed to upstream first if there is a reason for them. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Jan 25 17:45:47 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 25 Jan 2021 17:45:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 09:52:00 GMT, Andrew Haley wrote: >> Hello >> Why is it not nice ? >> linux_aarch64 uses some linux specific tls function _ZN10JavaThread25aarch64_get_thread_helperEv from hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s >> which clobbers only r0 and r1 >> macos_aarch64 has no such tls code and uses generic C-call to Thread::current(); >> Hence we are saving possibly clobbered regs here. > > Surely if you did as Linux does you wouldn't need to clobber all those registers. I see how this can be done, from looking at C example with `__thread`, which involves poorly documented relocations and private libc interface invocation. But now I also wonder how much benefit would we have from this optimization. `get_thread` is called from few places and all of them are guarded by `#ifdef ASSERT`. The release build is still fine after I removed MacroAssembler::get_thread definition (as a verification). Callers of get_thread: * StubAssembler::call_RT * Runtime1::generate_patching * StubGenerator::generate_call_stub * StubGenerator::generate_catch_exception All of them are heavy-weight functions, nonoptimal get_thread is unlikely to slow them down even in fastdebug. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From coleenp at openjdk.java.net Mon Jan 25 19:14:48 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Jan 2021 19:14:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 15:01:25 GMT, Anton Kozlov wrote: >> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87: >> >>> 85: JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env); >>> 86: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));; >>> 87: Thread::WXWriteFromExecSetter wx_write; >> >> Is this on every transition to VM from Native? Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is? > > I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here. Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like: class ThreadInVMfromNative : public ThreadStateTransition { ResetNoHandleMark __rnhm; We can look at it with cleaning up the thread transitions RFE or as a follow-on. If every line of ThreadInVMfromNative has to have one of these Thread::WXWriteVerifier __wx_write; people are going to miss them when adding the former. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aleonard at openjdk.java.net Mon Jan 25 19:29:43 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Mon, 25 Jan 2021 19:29:43 GMT Subject: Integrated: 8260289: Unable to customize module lists after change JDK-8258411 In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 12:57:29 GMT, Andrew Leonard wrote: > A problem was found downstream with Eclipse OpenJ9 builds whereby since JDK-8258411 they were unable to extend the module lists. > This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to enable the module list extension again. > > Signed-off-by: Andrew Leonard This pull request has now been integrated. Changeset: 12ccd211 Author: Andrew Leonard URL: https://git.openjdk.java.net/jdk/commit/12ccd211 Stats: 9 lines in 1 file changed: 5 ins; 3 del; 1 mod 8260289: Unable to customize module lists after change JDK-8258411 Reviewed-by: ihse, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2219 From akozlov at openjdk.java.net Mon Jan 25 19:38:16 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 25 Jan 2021 19:38:16 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Refactor CDS disabling - Redo builsys support for aarch64-darwin ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/50b55f66..0c2cb0a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=01-02 Stats: 36 lines in 3 files changed: 12 ins; 15 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From prr at openjdk.java.net Mon Jan 25 20:50:57 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 25 Jan 2021 20:50:57 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor CDS disabling > - Redo builsys support for aarch64-darwin make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573: > 571: EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \ > 572: WARNINGS_AS_ERRORS_xlc := false, \ > 573: DISABLED_WARNINGS_clang := deprecated-declarations, \ I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things. I've built JDK using Xcode 12.3 and not had any need for this. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Mon Jan 25 21:21:49 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 25 Jan 2021 21:21:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 19:42:41 GMT, Phil Race wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor CDS disabling >> - Redo builsys support for aarch64-darwin > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573: > >> 571: EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \ >> 572: WARNINGS_AS_ERRORS_xlc := false, \ >> 573: DISABLED_WARNINGS_clang := deprecated-declarations, \ > > I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things. > I've built JDK using Xcode 12.3 and not had any need for this. Hello I believe it was a workaround for issues with xcode 12.2 in early beta days. Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Mon Jan 25 21:21:49 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 25 Jan 2021 21:21:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 20:54:38 GMT, Vladimir Kempik wrote: >> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573: >> >>> 571: EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \ >>> 572: WARNINGS_AS_ERRORS_xlc := false, \ >>> 573: DISABLED_WARNINGS_clang := deprecated-declarations, \ >> >> I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things. >> I've built JDK using Xcode 12.3 and not had any need for this. > > Hello > I believe it was a workaround for issues with xcode 12.2 in early beta days. > Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds. It seems these workarounds are still needed: jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations] bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat ^~~~~~~~~~~~~~~~~~~~~~~~ NSBitmapFormatAlphaFirst jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations] styleMask: NSBorderlessWindowMask ^~~~~~~~~~~~~~~~~~~~~~ NSWindowStyleMaskBorderless ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From prr at openjdk.java.net Mon Jan 25 22:24:47 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 25 Jan 2021 22:24:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> On Mon, 25 Jan 2021 21:18:59 GMT, Vladimir Kempik wrote: >> Hello >> I believe it was a workaround for issues with xcode 12.2 in early beta days. >> Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds. > > It seems these workarounds are still needed: > > jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations] > bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat > ^~~~~~~~~~~~~~~~~~~~~~~~ > NSBitmapFormatAlphaFirst > > jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations] > styleMask: NSBorderlessWindowMask > ^~~~~~~~~~~~~~~~~~~~~~ > NSWindowStyleMaskBorderless Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem. I think we currently target a macOS 10.9 and if you are changing that it would need discussion. If you are changing it only for Mac ARM that may make more sense .. And these appear to be just API churn by Apple NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc NSBorderlessWindowMask is replaced by NSWindowStyleMask https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Mon Jan 25 22:28:46 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 25 Jan 2021 22:28:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> References: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> Message-ID: On Mon, 25 Jan 2021 22:22:06 GMT, Phil Race wrote: >> It seems these workarounds are still needed: >> >> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations] >> bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat >> ^~~~~~~~~~~~~~~~~~~~~~~~ >> NSBitmapFormatAlphaFirst >> >> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations] >> styleMask: NSBorderlessWindowMask >> ^~~~~~~~~~~~~~~~~~~~~~ >> NSWindowStyleMaskBorderless > > Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem. > I think we currently target a macOS 10.9 and if you are changing that it would need discussion. > If you are changing it only for Mac ARM that may make more sense .. > > And these appear to be just API churn by Apple > NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst > > https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc > > NSBorderlessWindowMask is replaced by NSWindowStyleMask > > https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ Min_macos version is changed to 11.0 for macos_aarch64 https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From prr at openjdk.java.net Mon Jan 25 22:45:42 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 25 Jan 2021 22:45:42 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> Message-ID: On Mon, 25 Jan 2021 22:25:48 GMT, Vladimir Kempik wrote: >> Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem. >> I think we currently target a macOS 10.9 and if you are changing that it would need discussion. >> If you are changing it only for Mac ARM that may make more sense .. >> >> And these appear to be just API churn by Apple >> NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst >> >> https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc >> >> NSBorderlessWindowMask is replaced by NSWindowStyleMask >> >> https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ > > Min_macos version is changed to 11.0 for macos_aarch64 > > https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask 2) So maybe rather than the deprecation suppression you could change both constants to the new ones. Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ... ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Mon Jan 25 22:50:44 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 25 Jan 2021 22:50:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> Message-ID: On Mon, 25 Jan 2021 22:42:40 GMT, Phil Race wrote: >> Min_macos version is changed to 11.0 for macos_aarch64 >> >> https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136 > > 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask > 2) So maybe rather than the deprecation suppression you could change both constants to the new ones. > Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ... that sounds good to me, I am just afraid to break intel mac on older macos versions with this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From cjplummer at openjdk.java.net Mon Jan 25 23:01:47 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 25 Jan 2021 23:01:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor CDS disabling > - Redo builsys support for aarch64-darwin I looked through the SA changes. Overall looks good except for a couple of minor issues noted. For the most part it seems to have been boilerplate copy-n-paste from existing ports. If there is anything you want me to take a closer look at, let me know. src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 702: > 700: primitiveArray = (*env)->GetLongArrayElements(env, registerArray, NULL); > 701: > 702: #undef REG_INDEX I'm not so sure why the #undef and subsequent #define of REG_INDEX is needed since it seems to just get #define'd back to the same value. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64ThreadContext.java line 2: > 1: /* > 2: * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved. Update copyright. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From cjplummer at openjdk.java.net Mon Jan 25 23:08:48 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 25 Jan 2021 23:08:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: <0a4qdfSXm3tmLgOW3MJoTc8VSL4XGnaKXrSEbaeL3h0=.d7c6ce7f-183f-429c-8b3e-7f6bc3379f23@github.com> On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor CDS disabling > - Redo builsys support for aarch64-darwin JDI changes also look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From prr at openjdk.java.net Mon Jan 25 23:38:44 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 25 Jan 2021 23:38:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> Message-ID: On Mon, 25 Jan 2021 23:34:04 GMT, Phil Race wrote: >> that sounds good to me, I am just afraid to break intel mac on older macos versions with this change. > > That may actually be a valid concern. Both say macOS 10.12+ ... which might conflict with the 10.9 target. Maybe you should just file a bug after all for this to be dealt with separately. Certainly if it is NOT fixed now such a bug needs to be filed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From prr at openjdk.java.net Mon Jan 25 23:38:43 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 25 Jan 2021 23:38:43 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> Message-ID: On Mon, 25 Jan 2021 22:47:33 GMT, Vladimir Kempik wrote: >> 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask >> 2) So maybe rather than the deprecation suppression you could change both constants to the new ones. >> Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ... > > that sounds good to me, I am just afraid to break intel mac on older macos versions with this change. That may actually be a valid concern. Both say macOS 10.12+ ... which might conflict with the 10.9 target. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Tue Jan 26 07:26:43 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 26 Jan 2021 07:26:43 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com> Message-ID: On Mon, 25 Jan 2021 23:35:52 GMT, Phil Race wrote: >> That may actually be a valid concern. Both say macOS 10.12+ ... which might conflict with the 10.9 target. > > Maybe you should just file a bug after all for this to be dealt with separately. > Certainly if it is NOT fixed now such a bug needs to be filed. I have created https://bugs.openjdk.java.net/browse/JDK-8260402 which is blocked by jep-391 currently ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From stefank at openjdk.java.net Tue Jan 26 08:57:54 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 26 Jan 2021 08:57:54 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor CDS disabling > - Redo builsys support for aarch64-darwin > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. I wonder if this is the right choice. I think it would have been good if this could have been completely hidden in the transition classes. However, that doesn't seem to have been enough and now there are explicit Thread::WXWriteFromExecSetter instances where it's not at all obvious why they are needed. For example, why was it added here?: OopStorageParIterPerf::~OopStorageParIterPerf() { // missing transition to vm state Thread::WXWriteFromExecSetter wx_write; _storage.release(_entries, ARRAY_SIZE(_entries)); } You need to dig down in the OopStorage implementation to find that it's because it uses SafeFetch, which has the opposite transition: inline int SafeFetch32(int* adr, int errValue) { assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated"); Thread::WXExecFromWriteSetter wx_exec; return StubRoutines::SafeFetch32_stub()(adr, errValue); } I think this adds complexity to code that shouldn't have to deal with this. I'm fine with having to force devs / code that writes to exec memory to have to deal with a bit more complexity, but it seems wrong to let this leak out to code that is staying far away from that. For my understanding, was this choice made because the nmethods instances (and maybe other types as well) are placed in the code cache memory segment, which is executable? If the code cache only contained the JIT:ed code, and not object instances, I think this could more easily have been contained a bit more. If the proposed solution is going to stay, maybe this could be made a little bit nicer by changing the SafeFetch implementation to use a new scoped object that doesn't enforce the "from" state to be "write"? Instead it could check if the state is "write" and only then flip the state back and forth. I think, this would remove the change needed OopStorageParIterPerf, and probably other places as well. src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp line 38: > 36: #include "runtime/os.hpp" > 37: #include "runtime/stubRoutines.hpp" > 38: #include "runtime/stubRoutines.inline.hpp" Remove stubRutines.hpp line src/hotspot/share/runtime/stubRoutines.inline.hpp line 29: > 27: > 28: #include > 29: #include Replace < > with " " src/hotspot/os/aix/os_aix.cpp line 70: > 68: #include "runtime/statSampler.hpp" > 69: #include "runtime/stubRoutines.hpp" > 70: #include "runtime/stubRoutines.inline.hpp" Remove stubRutines.hpp line ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From aph at redhat.com Tue Jan 26 09:14:10 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jan 2021 09:14:10 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: Message-ID: On 1/25/21 5:45 PM, Anton Kozlov wrote: > I see how this can be done, from looking at C example with `__thread`, which involves > poorly documented relocations and private libc interface invocation. > > But now I also wonder how much benefit would we have from this optimization. OK, so perhaps it's not worth doing. Withdrawn. -- 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 From ihse at openjdk.java.net Tue Jan 26 09:25:50 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 09:25:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor CDS disabling > - Redo builsys support for aarch64-darwin Changes requested by ihse (Reviewer). make/autoconf/build-aux/autoconf-config.guess line 1275: > 1273: UNAME_PROCESSOR="aarch64" > 1274: fi > 1275: fi ;; Almost, but not quite, correct. We cannot change the autoconf-config.guess file due to license restrictions (the license allows redistribution, not modifications). Instead we have the config.guess file which "wraps" autoconf-config.guess and makes pre-/post-call modifications to work around limitations in the autoconf original file. So you need to check there if you are getting incorrect results back and adjust it in that case. See the already existing clauses in that file. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+5426460+mkraljt at openjdk.java.net Tue Jan 26 09:26:44 2021 From: github.com+5426460+mkraljt at openjdk.java.net (mkraljt) Date: Tue, 26 Jan 2021 09:26:44 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v6] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 04:46:52 GMT, David Holmes wrote: >> We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. >> >> As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. >> >> The changes are in layered commits: >> >> Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. >> Step 2: make supports_monotonic_clock always true and so remove checking in OS code >> Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) >> Step 4: Move shared time functions to os_posix.cpp >> Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 >> >> Testing: tiers 1-3 for functional testing >> built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - 'Merge branch 'master' into 8246112-mono > - Update copyrights > - Remove the always true os::supports_monotonic_clock() > - Merge > - Merge branch 'master' into 8246112-mono > - Restrict librt linking to JVM - per Magnus's request > - Merge branch 'master' into 8246112-mono > - Alway link librt on Linux so we don't rely on glibc > 2.12 > - Step 4: Move shared time functions to os_posix.cpp > - Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/764111ff...f4bf2b8a src/hotspot/os/posix/os_posix.cpp line 1292: > 1290: return jlong(ts.tv_sec) * MILLIUNITS + > 1291: jlong(ts.tv_nsec) / NANOUNITS_PER_MILLIUNIT; > 1292: } David, Great to see simplifications like this happening in OpenJdk code. - Posix letting you delete platform specific code. - Always nice to see 'if' branching eliminated to simplify test coverage and runtime. ------------- PR: https://git.openjdk.java.net/jdk/pull/2090 From ihse at openjdk.java.net Tue Jan 26 09:39:41 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 09:39:41 GMT Subject: RFR: 8258477: Pre-submit testing using GitHub Actions should merge changes from target branch In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 09:03:57 GMT, Robin Westberg wrote: >> Normally when running GitHub Actions on a pull request, what is checked out is the merge of the pull request with the latest changes on the target branch. This ensure that what is tested is as close as possible to what will actually be the result of integrating said pull request. >> >> In our use of GitHub Actions, we don't run directly on pull requests but instead allow contributors to run them in their own personal forks. In that context, there is no notion of a target branch. However, we can infer the target project and branch by encoding this in the workflow file. This allows us to perform the same merge manually, and achieve the same behaviour. >> >> The change also adds an option to disable this automated merge when launching the workflow manually, which could be useful when investigating unexpected test failures. >> >> Note that downstream projects picking up this change will have to adapt the workflow file to keep using these actions for pre-submit testing. This has been a common request from downstream projects, but could also be done in a separate change (or not at all). > > So, is there anyone who would like to review this? I still think it will improve the effectiveness of the GitHub Actions-based testing. I might be missing something here, but it sounds like it muddies the water on exactly what is tested: if an automatic merge is possible, this will be done and tested. If the automatic merge fails, the original, un-merged, branch is tested. For instance, it will have the ironic effect of a small non-compatible change that passes the automatic merge will fail the test, but an even larger non-compatible change that do not pass the automatic merge will succeed! I understand the intention, but I'm just worried it decreases the transparency of what GHA tests even more. How can you know what was tested? ------------- PR: https://git.openjdk.java.net/jdk/pull/1801 From magnus.ihse.bursie at oracle.com Tue Jan 26 10:08:24 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 11:08:24 +0100 Subject: RFR: 8259679: GitHub actions should use MSVC 14.28 In-Reply-To: References: <97ec9a82-2a6a-344f-223e-cff246c4b873@oracle.com> Message-ID: <1971efe0-87e0-c084-b055-d562801567d0@oracle.com> On 2021-01-20 06:48, David Holmes wrote: > On 19/01/2021 11:48 pm, Magnus Ihse Bursie wrote: >> >> On 2021-01-19 00:13, David Holmes wrote: >>> Hard-wiring build numbers seems a maintenance PITA. :( Is there not >>> a way to do this that is independent of the actual build installed? >> I agree that hard-wiring numbers in the code is bad. However, having >> explicit version numbers for our dependencies is good. That is the >> philosophy behind jib, and it has served us well. We should look at >> finding a way to store the actual versioon numbers outside the >> submit.yml file, though. > > I think this is a bit different to the way we use jib to manage our > own build environment. > >> But what do you mean by "independent of the actual build installed"? > > We have AFAIK no control over what toolkit versions are installed for > Github actions, so they could change at any time. We update today to > request 14.28 and tomorrow they replace 14.28 with 14.29 and our > builds fail again even though they would likely be perfectly fine on > 14.29. To me if we just were able to say "Use latest VS 14.x" then > that would suffice most of the time. Occasionally we could hit an > issue where our sources are not yet compatible with the latest VS but > hopefully that is less frequent than the frequency these VS builds > change. I think that depends on how we view the GHA testing, which still is not clear. Or rather, each OpenJDK developer seem to have their own opinion on this, and no official guidelines to help us. I think we need to make the most effort we can to control the GHA environment. That means requesting a specific version of VS, and having a fail-fast if that is not available. That way, we get to know when GHA environment changes. Which is how things work today. > >>> Would it not also be good to add a check for the existence of the >>> build that we do hard-wire? That way the problem will be very clear >>> next time. >> It would be fantastic! Please tell me how to to that in the limited, >> brain-dead Github Actions environment. :-( > > If we put those hard-wired version/build numbers into a file readable > by configure, then couldn't configure check it? So just to be clear: configure *did* check for the existence of VS, and it did not find it, and thus it aborted and complained. So we did have this fail-fast functionality. But since the GHA environment contained a half-broken, half-working installation of the VS version in question, the error message from configure was not really clear. This PR was about updating the version of VS required by the GHA build script. Unfortunately, I think it's not possible to either: 1) move the version number to a separate configuration file, instead of hard-coding it in the yaml source 2) have the submit.yml GHA script check for the availability of the specific version of VS before launching configure. but it might be just my limited knowledge about the system. If it were possible, I think we should do both. /Magnus > > Cheers, > David > >> /Magnus >>> >>> Cheers, >>> David >>> >>>> ------------- >>>> >>>> Commit messages: >>>> ? - 8259679: GitHub actions should use MSVC 14.28 >>>> >>>> Changes: https://git.openjdk.java.net/jdk/pull/2126/files >>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2126&range=00 >>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8259679 >>>> ?? Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/2126.diff >>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >>>> pull/2126/head:pull/2126 >>>> >>>> PR: https://git.openjdk.java.net/jdk/pull/2126 >>>> >> From ihse at openjdk.java.net Tue Jan 26 10:14:41 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 10:14:41 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Sat, 23 Jan 2021 07:55:09 GMT, Alan Bateman wrote: > We should create a separate issue to rename them and get rid of the copying in the make file. I opened https://bugs.openjdk.java.net/browse/JDK-8260406. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Tue Jan 26 10:39:50 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 10:39:50 GMT Subject: RFR: 8260406: Do not copy pure java source code to gensrc Message-ID: For java.base gensrc we do the following: # Copy two Java files that need no preprocessing. $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template $(call LogInfo, Generating $(@F)) $(call install-file) GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \ $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) We should just rename these files to java and move them to the normal source directory. ------------- Commit messages: - 8260406: Do not copy pure java source code to gensrc Changes: https://git.openjdk.java.net/jdk/pull/2233/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2233&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260406 Stats: 9 lines in 3 files changed: 0 ins; 8 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2233.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2233/head:pull/2233 PR: https://git.openjdk.java.net/jdk/pull/2233 From akozlov at openjdk.java.net Tue Jan 26 11:33:45 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 11:33:45 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com> <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com> Message-ID: On Mon, 25 Jan 2021 14:40:42 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/thread.hpp line 915: >> >>> 913: verify_wx_state(WXExec); >>> 914: } >>> 915: }; >> >> Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and just add the class instance as a field in thread.hpp? > > This could be a follow-up RFE. I assume a WXVerifier class that tracks W^X mode in debug mode and does nothing in release mode. I've considered to do this, it's relates to small inefficiencies, while this patch brings zero overhead (in release) for a platform that does not need W^X. * We don't need thread instance in release to call `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will require calling `Thread::current()` first and we could only hope for compiler to optimize this out, not sure if it will happen at all. In some contexts the Thread instance is available, in some it's not. * An instance of the empty class (as WXVerifier will be in the release) will occupy non-zero space in the Thread instance. If such costs are negligible, I can do as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From alanb at openjdk.java.net Tue Jan 26 11:48:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 26 Jan 2021 11:48:40 GMT Subject: RFR: 8260406: Do not copy pure java source code to gensrc In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 10:35:03 GMT, Magnus Ihse Bursie wrote: > For java.base gensrc we do the following: > > # Copy two Java files that need no preprocessing. > $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template > $(call LogInfo, Generating $(@F)) > $(call install-file) > > GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \ > $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java > > What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) > > We should just rename these files to java and move them to the normal source directory. Good. I notice the comment in both source files says "Java.lang.Character" rather than "java.lang.Character", probably should fix that at some point. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2233 From shade at openjdk.java.net Tue Jan 26 12:01:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 12:01:48 GMT Subject: RFR: 8260408: Shenandoah: adjust inline hints after JDK-8255019 Message-ID: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> I was following up on performance testing results for some ongoing work, and realized that there are `ShenandoahMarkContext::mark_strong` calls from `mark_work_loop`. Those callees were supposed to be inlined. I believe it is a simple omission after JDK-8255019 moved `mark_work_loop` code to `shenandoahMark.cpp`. On a typical workload: # Before [44.500s][info][gc,stats] Concurrent Marking = 0.395 s (a = 11278 us) (n = 35) (lvls, us = 6426, 9473, 11133, 12891, 16476) # After [44.405s][info][gc,stats] Concurrent Marking = 0.337 s (a = 9636 us) (n = 35) (lvls, us = 3770, 7383, 9785, 11328, 16776) Additional testing: - [x] Eyeballing GC hot paths - [x] Ad-hoc performance tests ------------- Commit messages: - 8260408: Shenandoah: adjust inline hints after JDK-8255019 Changes: https://git.openjdk.java.net/jdk/pull/2235/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2235&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260408 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2235.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2235/head:pull/2235 PR: https://git.openjdk.java.net/jdk/pull/2235 From coleenp at openjdk.java.net Tue Jan 26 12:04:48 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 26 Jan 2021 12:04:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com> <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com> Message-ID: On Tue, 26 Jan 2021 11:31:18 GMT, Anton Kozlov wrote: >> This could be a follow-up RFE. > > I assume a WXVerifier class that tracks W^X mode in debug mode and does nothing in release mode. I've considered to do this, it's relates to small inefficiencies, while this patch brings zero overhead (in release) for a platform that does not need W^X. > * We don't need thread instance in release to call `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will require calling `Thread::current()` first and we could only hope for compiler to optimize this out, not sure if it will happen at all. In some contexts the Thread instance is available, in some it's not. > * An instance of the empty class (as WXVerifier will be in the release) will occupy non-zero space in the Thread instance. > > If such costs are negligible, I can do as suggested. I really just want the minimal number of lines of code and hooks in thread.hpp. You can still access it through the thread, just like these lines currently. Look at HandshakeState as an example. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From rkennke at openjdk.java.net Tue Jan 26 12:05:41 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 26 Jan 2021 12:05:41 GMT Subject: RFR: 8260408: Shenandoah: adjust inline hints after JDK-8255019 In-Reply-To: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> References: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> Message-ID: On Tue, 26 Jan 2021 11:41:52 GMT, Aleksey Shipilev wrote: > I was following up on performance testing results for some ongoing work, and realized that there are `ShenandoahMarkContext::mark_strong` calls from `mark_work_loop`. Those callees were supposed to be inlined. I believe it is a simple omission after JDK-8255019 moved `mark_work_loop` code to `shenandoahMark.cpp`. > > On a typical workload: > > # Before > [44.500s][info][gc,stats] Concurrent Marking = 0.395 s (a = 11278 us) > (n = 35) (lvls, us = 6426, 9473, 11133, 12891, 16476) > > # After > [44.405s][info][gc,stats] Concurrent Marking = 0.337 s (a = 9636 us) > (n = 35) (lvls, us = 3770, 7383, 9785, 11328, 16776) > > Additional testing: > - [x] Eyeballing GC hot paths > - [x] Ad-hoc performance tests Looks good! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2235 From vkempik at openjdk.java.net Tue Jan 26 12:09:42 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 26 Jan 2021 12:09:42 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward wrote: > AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework > ie: > `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` > > Otherwise there will be missing _JNFNative* functions. > > Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? There is ongoing work by P. Race to eliminate dependence on JNF at all ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+4146708+a74nh at openjdk.java.net Tue Jan 26 12:04:47 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Tue, 26 Jan 2021 12:04:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 09:23:23 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor CDS disabling >> - Redo builsys support for aarch64-darwin > > Changes requested by ihse (Reviewer). AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework ie: ` --with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/' ` Otherwise there will be missing _JNFNative* functions. Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+4146708+a74nh at openjdk.java.net Tue Jan 26 12:36:44 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Tue, 26 Jan 2021 12:36:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com> On Tue, 26 Jan 2021 12:06:28 GMT, Vladimir Kempik wrote: > > AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework > > ie: > > `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` > > Otherwise there will be missing _JNFNative* functions. > > Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? > > There is ongoing work by P. Race to eliminate dependence on JNF at all Ok, that's great. In the meantime is it worth adding something to the MacOS section of doc/building.* ? (I pieced together the required line from multiple posts in a mailing list) ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Tue Jan 26 12:44:40 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 12:44:40 GMT Subject: RFR: 8260408: Shenandoah: adjust inline hints after JDK-8255019 In-Reply-To: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> References: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> Message-ID: On Tue, 26 Jan 2021 11:41:52 GMT, Aleksey Shipilev wrote: > I was following up on performance testing results for some ongoing work, and realized that there are `ShenandoahMarkContext::mark_strong` calls from `mark_work_loop`. Those callees were supposed to be inlined. I believe it is a simple omission after JDK-8255019 moved `mark_work_loop` code to `shenandoahMark.cpp`. > > On a typical workload: > > # Before > [44.500s][info][gc,stats] Concurrent Marking = 0.395 s (a = 11278 us) > (n = 35) (lvls, us = 6426, 9473, 11133, 12891, 16476) > > # After > [44.405s][info][gc,stats] Concurrent Marking = 0.337 s (a = 9636 us) > (n = 35) (lvls, us = 3770, 7383, 9785, 11328, 16776) > > Additional testing: > - [x] Eyeballing GC hot paths > - [x] Ad-hoc performance tests Looks good from the build PoV. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2235 From magnus.ihse.bursie at oracle.com Tue Jan 26 12:44:34 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 13:44:34 +0100 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: <0ce3d16d-76e1-dd38-1b13-d693bc490915@oracle.com> On 2021-01-26 13:09, Vladimir Kempik wrote: > On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward wrote: > >> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework >> ie: >> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` >> >> Otherwise there will be missing _JNFNative* functions. >> >> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? > There is ongoing work by P. Race to eliminate dependence on JNF at all How far has that work come? Otherwise the logic should be added to configure to look for this framework automatically, and provide a way to override it/set it if not found. I don't think it's OK to publish a new port that cannot build out-of-the-box without hacks like this. /Magnus > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Tue Jan 26 12:52:44 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 12:52:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 19:12:17 GMT, Coleen Phillimore wrote: >> I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here. > > Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like: > class ThreadInVMfromNative : public ThreadStateTransition { > ResetNoHandleMark __rnhm; > > We can look at it with cleaning up the thread transitions RFE or as a follow-on. If every line of ThreadInVMfromNative has to have one of these Thread::WXWriteVerifier __wx_write; people are going to miss them when adding the former. Not every ThreadInVMfromNative needs this, for example JIT goes to Native state without changing of W^X state. But from some experience of maintaining this patch, I actually had a duty to add missing W^X transitions after assert failures. A possible solution is actually to make W^X transition a part of ThreadInVMfromNative (and similar), but controlled by an optional constructor parameter with possible values "do exec->write", "verify write"...;. So in a common case ThreadInVMfromNative would implicitly do the transition and still would allow something uncommon like verification of the state for the JIT. I have to think about this. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From shade at openjdk.java.net Tue Jan 26 13:08:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 13:08:42 GMT Subject: RFR: 8260408: Shenandoah: adjust inline hints after JDK-8255019 In-Reply-To: References: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> Message-ID: On Tue, 26 Jan 2021 12:42:10 GMT, Magnus Ihse Bursie wrote: >> I was following up on performance testing results for some ongoing work, and realized that there are `ShenandoahMarkContext::mark_strong` calls from `mark_work_loop`. Those callees were supposed to be inlined. I believe it is a simple omission after JDK-8255019 moved `mark_work_loop` code to `shenandoahMark.cpp`. >> >> On a typical workload: >> >> # Before >> [44.500s][info][gc,stats] Concurrent Marking = 0.395 s (a = 11278 us) >> (n = 35) (lvls, us = 6426, 9473, 11133, 12891, 16476) >> >> # After >> [44.405s][info][gc,stats] Concurrent Marking = 0.337 s (a = 9636 us) >> (n = 35) (lvls, us = 3770, 7383, 9785, 11328, 16776) >> >> Additional testing: >> - [x] Eyeballing GC hot paths >> - [x] Ad-hoc performance tests > > Looks good from the build PoV. Thanks, GHA reports all builds are green. I would not wait for tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/2235 From shade at openjdk.java.net Tue Jan 26 13:08:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 13:08:43 GMT Subject: Integrated: 8260408: Shenandoah: adjust inline hints after JDK-8255019 In-Reply-To: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> References: <6Jelo9PB6s60HIt-Xsb27tRVJi9G627AAfIzPcSUBzk=.65599cbe-6507-4b5b-848e-404e19889853@github.com> Message-ID: On Tue, 26 Jan 2021 11:41:52 GMT, Aleksey Shipilev wrote: > I was following up on performance testing results for some ongoing work, and realized that there are `ShenandoahMarkContext::mark_strong` calls from `mark_work_loop`. Those callees were supposed to be inlined. I believe it is a simple omission after JDK-8255019 moved `mark_work_loop` code to `shenandoahMark.cpp`. > > On a typical workload: > > # Before > [44.500s][info][gc,stats] Concurrent Marking = 0.395 s (a = 11278 us) > (n = 35) (lvls, us = 6426, 9473, 11133, 12891, 16476) > > # After > [44.405s][info][gc,stats] Concurrent Marking = 0.337 s (a = 9636 us) > (n = 35) (lvls, us = 3770, 7383, 9785, 11328, 16776) > > Additional testing: > - [x] Eyeballing GC hot paths > - [x] Ad-hoc performance tests This pull request has now been integrated. Changeset: edd27074 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/edd27074 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8260408: Shenandoah: adjust inline hints after JDK-8255019 Reviewed-by: rkennke, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/2235 From erikj at openjdk.java.net Tue Jan 26 13:52:40 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 26 Jan 2021 13:52:40 GMT Subject: RFR: 8260406: Do not copy pure java source code to gensrc In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 10:35:03 GMT, Magnus Ihse Bursie wrote: > For java.base gensrc we do the following: > > # Copy two Java files that need no preprocessing. > $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template > $(call LogInfo, Generating $(@F)) > $(call install-file) > > GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \ > $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java > > What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) > > We should just rename these files to java and move them to the normal source directory. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2233 From ihse at openjdk.java.net Tue Jan 26 14:11:41 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 14:11:41 GMT Subject: Integrated: 8260406: Do not copy pure java source code to gensrc In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 10:35:03 GMT, Magnus Ihse Bursie wrote: > For java.base gensrc we do the following: > > # Copy two Java files that need no preprocessing. > $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template > $(call LogInfo, Generating $(@F)) > $(call install-file) > > GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \ > $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java > > What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) > > We should just rename these files to java and move them to the normal source directory. This pull request has now been integrated. Changeset: 8d2f77fd Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/8d2f77fd Stats: 9 lines in 3 files changed: 0 ins; 8 del; 1 mod 8260406: Do not copy pure java source code to gensrc Reviewed-by: alanb, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/2233 From akozlov at openjdk.java.net Tue Jan 26 15:06:14 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 15:06:14 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v4] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision: - Little adjustement of SlowSignatureHandler - Partially bring previous commit - Revert "Address feedback for signature generators" This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/0c2cb0a3..fef36580 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=02-03 Stats: 98 lines in 1 file changed: 74 ins; 13 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Tue Jan 26 15:06:14 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 15:06:14 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v4] In-Reply-To: <0WPkx3i-N0HHqCqrxE_B0Rf2akunbQaWQb7M7Z88BQY=.c582d11a-ba8d-4789-a55b-279e1286ad8d@github.com> References: <0WPkx3i-N0HHqCqrxE_B0Rf2akunbQaWQb7M7Z88BQY=.c582d11a-ba8d-4789-a55b-279e1286ad8d@github.com> Message-ID: On Mon, 25 Jan 2021 10:00:20 GMT, Andrew Haley wrote: >> I like the suggestion. For the defense, new functions were made this way intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment as a blessing to fix all of them. But I feel that refactoring of existing code should go in a separate commit. Especially after `pass_int` used `ldr/str` instead of `ldrw/strw`, which looks wrong. https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122 > > This is new code, and it should not repeat the mistakes of the past. There's no need to refactor the similar existing code as part of this patch. Makes sense, I've reverted changes in the old code but will propose them in the separate PR shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From doko at ubuntu.com Tue Jan 26 16:08:56 2021 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 26 Jan 2021 17:08:56 +0100 Subject: building OpenJDK 11 with link time optimizations? Message-ID: <5e8c9458-4e66-7b93-c14b-c5e6d4f3cbc8@ubuntu.com> Several Linux distros now build with link time optimizations (-flto=auto) by default. It looks like 15 and newer versions can be built with -flto. I haven't yet checked test results for LTO/non-LTO builds. I also only tried building with GCC 10. 11 still fails with /usr/bin/ld: /tmp/libjvm.so.xGmnnW.ltrans45.ltrans.o: in function `G1CMOopClosure::do_oop(oopDesc**)': /<>/openjdk-lts-11.0.9.1+1/make/hotspot/./src/hotspot/share/gc/g1/g1OopClosures.hpp:176: undefined reference to `void G1CMOopClosure::do_oop_work(oopDesc**)' [...] However this might be just the first build failure. Matthias From vkempik at openjdk.java.net Tue Jan 26 16:09:50 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 26 Jan 2021 16:09:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> Message-ID: On Mon, 25 Jan 2021 17:43:22 GMT, Phil Race wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/java.desktop/share/native/libharfbuzz/hb-common.h line 113: > >> 111: >> 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF))) >> 113: #define HB_UNTAG(tag) (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF) > > I need a robust explanation of these changes. > They are not mentioned, nor are they in upstream harfbuzz. > Likely these should be pushed to upstream first if there is a reason for them. @lewurm This and other harfbuzz changes came from MS, could you please comment here ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From burban at openjdk.java.net Tue Jan 26 16:38:47 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Tue, 26 Jan 2021 16:38:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> Message-ID: On Tue, 26 Jan 2021 16:07:19 GMT, Vladimir Kempik wrote: >> src/java.desktop/share/native/libharfbuzz/hb-common.h line 113: >> >>> 111: >>> 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF))) >>> 113: #define HB_UNTAG(tag) (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF) >> >> I need a robust explanation of these changes. >> They are not mentioned, nor are they in upstream harfbuzz. >> Likely these should be pushed to upstream first if there is a reason for them. > > @lewurm This and other harfbuzz changes came from MS, could you please comment here ? This looks like a merge fix mistake: https://github.com/openjdk/jdk/commit/051357ef977ecab77fa9b2b1e61f94f288e716f9#diff-e3815f37244d076e27feef0c778fb78a4e5691b47db9c92abcb28bb2a9c2865e ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Tue Jan 26 18:42:02 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 18:42:02 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v5] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Revert harfbuzz changes, disable warnings for it ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/fef36580..b2b396fc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=03-04 Stats: 5 lines in 3 files changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From erik.joelsson at oracle.com Tue Jan 26 18:42:49 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 26 Jan 2021 10:42:49 -0800 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: <0ce3d16d-76e1-dd38-1b13-d693bc490915@oracle.com> References: <0ce3d16d-76e1-dd38-1b13-d693bc490915@oracle.com> Message-ID: <58df0666-2c69-a4dd-3bb8-fd00c859b490@oracle.com> On 2021-01-26 04:44, Magnus Ihse Bursie wrote: > On 2021-01-26 13:09, Vladimir Kempik wrote: >> On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward >> wrote: >> >>> AIUI, the configure line needs passing a prebuilt >>> JavaNativeFoundation framework >>> ie: >>> `--with-extra-ldflags='-F >>> /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` >>> >>> Otherwise there will be missing _JNFNative* functions. >>> >>> Is this the long term plan? Or will eventually the required code be >>> moved into JDK and/or the xcode one automatically get picked up by >>> the configure scripts? >> There is ongoing work by P. Race to eliminate dependence on JNF at all > How far has that work come? Otherwise the logic should be added to > configure to look for this framework automatically, and provide a way > to override it/set it if not found. > > I don't think it's OK to publish a new port that cannot build > out-of-the-box without hacks like this. > My understanding is that Apple chose to not provide JNF for aarch64, so if you want to build OpenJDK, you first need to build JNF yourself (it's available in github). Phil is working on removing this dependency completely, which will solve this issue [1]. In the meantime, I don't think we should rely on finding JNF in unsupported locations inside Xcode. Could we wait with integrating this port until it can be built without such hacks? If not, then adding something in the documentation on how to get a working JNF would at least be needed. /Erik [1] https://bugs.openjdk.java.net/browse/JDK-8257852 From akozlov at openjdk.java.net Tue Jan 26 18:54:46 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 18:54:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> Message-ID: On Tue, 26 Jan 2021 16:35:54 GMT, Bernhard Urban-Forster wrote: >> @lewurm This and other harfbuzz changes came from MS, could you please comment here ? > > This looks like a merge fix mistake: https://github.com/openjdk/jdk/commit/051357ef977ecab77fa9b2b1e61f94f288e716f9#diff-e3815f37244d076e27feef0c778fb78a4e5691b47db9c92abcb28bb2a9c2865e I've reverted this change and disabled some warnings for libharfbuzz instead. I should be blamed, yes. Now this is consistent with other changes covered by JDK-8260402 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From shade at openjdk.java.net Tue Jan 26 19:13:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 19:13:48 GMT Subject: RFR: 8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386" Message-ID: See for example: https://github.com/shipilev/jdk/runs/1771453139?check_suite_focus=true E: Could not configure 'libc6:i386'. E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) It seems JDK-8259924 helped only for a while. There is a [bugfix](https://salsa.debian.org/apt-team/apt/-/commit/998a17d7e6f834c341f198ca5b6df2f27e18df38) in Apt 2.0.4 that prints these warnings and then allows the whole thing to continue. It was [released](https://bugs.launchpad.net/ubuntu-cdimage/+bug/1871268) in Ubuntu a week ago, but it is not in base image yet. So, if we upgrade apt before installing other packages, apt updates from 2.0.2 to 2.0.4 and the whole thing starts to work. This also reverts changes added by previous attempt in [JDK-8259924](https://github.com/openjdk/jdk/commit/a9519c83). ------------- Commit messages: - 8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386" Changes: https://git.openjdk.java.net/jdk/pull/2243/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2243&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260460 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2243.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2243/head:pull/2243 PR: https://git.openjdk.java.net/jdk/pull/2243 From weijun at openjdk.java.net Tue Jan 26 19:36:50 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Jan 2021 19:36:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v5] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 18:42:02 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Revert harfbuzz changes, disable warnings for it src/java.security.jgss/share/native/libj2gss/gssapi.h line 48: > 46: // Condition was copied from > 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h > 48: #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__)) So for macOS/AArch64, this `if` is no longer true? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From burban at openjdk.java.net Tue Jan 26 19:41:50 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Tue, 26 Jan 2021 19:41:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com> Message-ID: On Mon, 25 Jan 2021 17:43:35 GMT, Phil Race wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > src/java.desktop/share/native/libharfbuzz/hb-coretext.cc line 193: > >> 191: * crbug.com/549610 */ >> 192: // 0x00070000 stands for "kCTVersionNumber10_10", see CoreText.h >> 193: #if TARGET_OS_OSX && MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_10_10 > > I need a robust explanation of these changes. > They are not mentioned, nor are they in upstream harfbuzz. > Likely these should be pushed to upstream first if there is a reason for them. I'm afraid it's one of those dirty changes that we did to make progress, but forgot to revisit later. Without the guard you would get: * For target support_native_java.desktop_libharfbuzz_hb-coretext.o: if (&CTGetCoreTextVersion != nullptr && CTGetCoreTextVersion() < 0x00070000) { ^ uint32_t CTGetCoreTextVersion( void ) CT_DEPRECATED("Use -[NSProcessInfo operatingSystemVersion]", macos(10.5, 11.0), ios(3.2, 14.0), watchos(2.0, 7.0), tvos(9.0, 14.0)); ^ if (&CTGetCoreTextVersion != nullptr && CTGetCoreTextVersion() < 0x00070000) { ^ uint32_t CTGetCoreTextVersion( void ) CT_DEPRECATED("Use -[NSProcessInfo operatingSystemVersion]", macos(10.5, 11.0), ios(3.2, 14.0), watchos(2.0, 7.0), tvos(9.0, 14.0)); ^ 2 errors generated. For now, it's probably better to go with what Anton did in the latest commit https://github.com/openjdk/jdk/pull/2200/commits/b2b396fca679fbc7ee78fb5bc80191bc79e1c490 Eventually upstream will do something about it I assume? How often does it get synced with upstream? Maybe worth to file an issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Tue Jan 26 20:02:50 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 26 Jan 2021 20:02:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v5] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 19:33:28 GMT, Weijun Wang wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert harfbuzz changes, disable warnings for it > > src/java.security.jgss/share/native/libj2gss/gssapi.h line 48: > >> 46: // Condition was copied from >> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h >> 48: #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__)) > > So for macOS/AArch64, this `if` is no longer true? That is according to Xcode sdk. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Tue Jan 26 21:59:03 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 26 Jan 2021 21:59:03 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Redo buildsys fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/b2b396fc..f1ef6240 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=04-05 Stats: 18 lines in 2 files changed: 8 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Tue Jan 26 22:07:48 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 26 Jan 2021 22:07:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 09:23:18 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor CDS disabling >> - Redo builsys support for aarch64-darwin > > make/autoconf/build-aux/autoconf-config.guess line 1275: > >> 1273: UNAME_PROCESSOR="aarch64" >> 1274: fi >> 1275: fi ;; > > Almost, but not quite, correct. We cannot change the autoconf-config.guess file due to license restrictions (the license allows redistribution, not modifications). Instead we have the config.guess file which "wraps" autoconf-config.guess and makes pre-/post-call modifications to work around limitations in the autoconf original file. So you need to check there if you are getting incorrect results back and adjust it in that case. See the already existing clauses in that file. Hello I have updated PR and moved this logic to make/autoconf/build-aux/config.guess It's pretty similar to i386 -> x86_64 fix-up on macos_intel ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From dholmes at openjdk.java.net Wed Jan 27 01:15:59 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 27 Jan 2021 01:15:59 GMT Subject: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v7] In-Reply-To: References: Message-ID: > We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. > > As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. > > The changes are in layered commits: > > Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. > Step 2: make supports_monotonic_clock always true and so remove checking in OS code > Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) > Step 4: Move shared time functions to os_posix.cpp > Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 > > Testing: tiers 1-3 for functional testing > built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 David Holmes has updated the pull request incrementally with one additional commit since the last revision: Expand comment on macOS and AIX custom implementations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2090/files - new: https://git.openjdk.java.net/jdk/pull/2090/files/f4bf2b8a..baf1abb3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2090&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2090&range=05-06 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2090/head:pull/2090 PR: https://git.openjdk.java.net/jdk/pull/2090 From dholmes at openjdk.java.net Wed Jan 27 01:22:40 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 27 Jan 2021 01:22:40 GMT Subject: Integrated: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 04:57:24 GMT, David Holmes wrote: > We are now confident that we have build-time and runtime support for clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX platforms - see bug report for some more details on different OS. Consequently we can simplify a lot of the code in this area and move common code to os_posix. > > As of glibc 2.17 the necessary functions are in glibc rather than librt, but we (Oracle at least) aren't yet in position to set our minimum Linux version to support that. We still have supported platforms at glibc 2.12. So to address that we link librt at build time on Linux. This seems to work find for older and more modern Linuxes and also works for the Apline Linux with Musl variant. > > The changes are in layered commits: > > Step 1: Remove build time checks. SUPPORTS_CLOCK_MONOTONIC is assumed true and removed. > Step 2: make supports_monotonic_clock always true and so remove checking in OS code > Step 3: Replace gettimeofday by clock_gettime(CLOCK_REALTIME) > Step 4: Move shared time functions to os_posix.cpp > Step 5: Alway link librt on Linux so we don't rely on glibc > 2.17 > > Testing: tiers 1-3 for functional testing > built and checked (-Xlog:os) on Linux with glibc 2.12 and 2.17, macOS 10.13.6 and 10.15.7 This pull request has now been integrated. Changeset: 6f2be9c6 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/6f2be9c6 Stats: 414 lines in 16 files changed: 57 ins; 326 del; 31 mod 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC Reviewed-by: ihse, erikj, gziemski, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/2090 From dholmes at openjdk.java.net Wed Jan 27 06:50:45 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 27 Jan 2021 06:50:45 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com> References: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com> Message-ID: On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward wrote: >>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework >>> ie: >>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` >>> >>> Otherwise there will be missing _JNFNative* functions. >>> >>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? >> >> There is ongoing work by P. Race to eliminate dependence on JNF at all > >> > AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework >> > ie: >> > `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` >> > Otherwise there will be missing _JNFNative* functions. >> > Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? >> >> There is ongoing work by P. Race to eliminate dependence on JNF at all > > Ok, that's great. > In the meantime is it worth adding something to the MacOS section of doc/building.* ? > (I pieced together the required line from multiple posts in a mailing list) Hi Anton, Just to add weight to comments already made by @coleenp and @stefank , I also find the W^X coding support to be too intrusive and polluting of the shared code. I would much rather see this support pushed down as far as possible, to minimise the impact and to use ifdef'd code for macos/Aarch64 (via MACOS_AARCH64_ONLY macro) rather than providing empty methods. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Wed Jan 27 08:21:41 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 27 Jan 2021 08:21:41 GMT Subject: RFR: 8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386" In-Reply-To: References: Message-ID: <6qKzSVX4HET7HlmR9Qr-QQ9VhWbMKblcZua52yL69SQ=.762210e5-88da-4642-8442-dfba75aea015@github.com> On Tue, 26 Jan 2021 19:08:41 GMT, Aleksey Shipilev wrote: > See for example: > https://github.com/shipilev/jdk/runs/1771453139?check_suite_focus=true > > E: Could not configure 'libc6:i386'. > E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) > > It seems JDK-8259924 helped only for a while. > > There is a [bugfix](https://salsa.debian.org/apt-team/apt/-/commit/998a17d7e6f834c341f198ca5b6df2f27e18df38) in Apt 2.0.4 that prints these warnings and then allows the whole thing to continue. It was [released](https://bugs.launchpad.net/ubuntu-cdimage/+bug/1871268) in Ubuntu a week ago, but it is not in base image yet. So, if we upgrade apt before installing other packages, apt updates from 2.0.2 to 2.0.4 and the whole thing starts to work. > > This also reverts changes added by previous attempt in [JDK-8259924](https://github.com/openjdk/jdk/commit/a9519c83). Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2243 From ihse at openjdk.java.net Wed Jan 27 08:29:45 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 27 Jan 2021 08:29:45 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Mon, 25 Jan 2021 16:00:23 GMT, Bernhard Urban-Forster wrote: >> @luhenry , could you please check this comment, I think SA-agent was MS's job here. > > The target is identified by the header file now: > https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083f666367e25fba2b527a9a5bc8743a6R35-R41 > > Do you think there is any problem with this approach? @lewurm No, that's okay. I just wanted to know that this had not been lost. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Wed Jan 27 08:32:46 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 27 Jan 2021 08:32:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 22:04:48 GMT, Vladimir Kempik wrote: >> make/autoconf/build-aux/autoconf-config.guess line 1275: >> >>> 1273: UNAME_PROCESSOR="aarch64" >>> 1274: fi >>> 1275: fi ;; >> >> Almost, but not quite, correct. We cannot change the autoconf-config.guess file due to license restrictions (the license allows redistribution, not modifications). Instead we have the config.guess file which "wraps" autoconf-config.guess and makes pre-/post-call modifications to work around limitations in the autoconf original file. So you need to check there if you are getting incorrect results back and adjust it in that case. See the already existing clauses in that file. > > Hello > I have updated PR and moved this logic to make/autoconf/build-aux/config.guess > It's pretty similar to i386 -> x86_64 fix-up on macos_intel Thanks. That looks better. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Wed Jan 27 08:38:46 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 27 Jan 2021 08:38:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 21:59:03 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Redo buildsys fix Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From david.holmes at oracle.com Wed Jan 27 08:42:53 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jan 2021 18:42:53 +1000 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com> Message-ID: <2f9e8ea2-a3a9-53d0-f735-894272a3717e@oracle.com> I don't know why the Skara tools decided to associate my comment with Alan Hayward's comment as they are not at all related. :( David On 27/01/2021 4:50 pm, David Holmes wrote: > On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward wrote: > >>>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework >>>> ie: >>>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` >>>> >>>> Otherwise there will be missing _JNFNative* functions. >>>> >>>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? >>> >>> There is ongoing work by P. Race to eliminate dependence on JNF at all >> >>>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework >>>> ie: >>>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` >>>> Otherwise there will be missing _JNFNative* functions. >>>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts? >>> >>> There is ongoing work by P. Race to eliminate dependence on JNF at all >> >> Ok, that's great. >> In the meantime is it worth adding something to the MacOS section of doc/building.* ? >> (I pieced together the required line from multiple posts in a mailing list) > > Hi Anton, > > Just to add weight to comments already made by @coleenp and @stefank , I also find the W^X coding support to be too intrusive and polluting of the shared code. I would much rather see this support pushed down as far as possible, to minimise the impact and to use ifdef'd code for macos/Aarch64 (via MACOS_AARCH64_ONLY macro) rather than providing empty methods. > > Thanks, > David > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2200 > From magnus.ihse.bursie at oracle.com Wed Jan 27 09:35:47 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Jan 2021 10:35:47 +0100 Subject: building OpenJDK 11 with link time optimizations? In-Reply-To: <5e8c9458-4e66-7b93-c14b-c5e6d4f3cbc8@ubuntu.com> References: <5e8c9458-4e66-7b93-c14b-c5e6d4f3cbc8@ubuntu.com> Message-ID: On 2021-01-26 17:08, Matthias Klose wrote: > Several Linux distros now build with link time optimizations (-flto=auto) by > default. It looks like 15 and newer versions can be built with -flto. I haven't > yet checked test results for LTO/non-LTO builds. I also only tried building with > GCC 10. > > 11 still fails with > /usr/bin/ld: /tmp/libjvm.so.xGmnnW.ltrans45.ltrans.o: in function > `G1CMOopClosure::do_oop(oopDesc**)': > /<>/openjdk-lts-11.0.9.1+1/make/hotspot/./src/hotspot/share/gc/g1/g1OopClosures.hpp:176: > undefined reference to `void G1CMOopClosure::do_oop_work(oopDesc**)' > [...] > > However this might be just the first build failure. Is this when building with --enable-jvm-feature-link-time-opt on linux-x64? When I try that (with gcc-10 on Ubuntu) on the mainline, I get: In function 'strncpy', ??? inlined from 'description' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp:86:10, ??? inlined from 'description' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp:107:34, ??? inlined from '__write_sample_info__' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp:212:16, ??? inlined from 'operator()' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/writers/jfrTypeWriterHost.hpp:87:14, ??? inlined from 'operator()' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/writers/jfrTypeWriterHost.hpp:69:18, ??? inlined from 'iterate' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp:118:16, ??? inlined from 'write_sample_infos' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp:223:26: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:34: warning: '__builtin_strncpy' specified bound depends on the length of the source argument [-Wstringop-overflow=] ? 106 |?? return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); ????? |????????????????????????????????? ^ /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp: In function 'write_sample_infos': /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp:83:28: note: length computed here ?? 83 |?? const size_t len = strlen(_buffer); ????? |??????????????????????????? ^ In function 'strncpy', ??? inlined from 'description' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp:86:10, ??? inlined from 'description' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp:340:33, ??? inlined from '__write_root_description_info__' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp:348:16, ??? inlined from 'operator()' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/writers/jfrTypeWriterHost.hpp:87:14, ??? inlined from 'operator()' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/writers/jfrTypeWriterHost.hpp:69:18, ??? inlined from 'iterate' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp:118:16, ??? inlined from 'write_root_descriptors' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp:514:24, ??? inlined from '__dt_base ' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp:627:25, ??? inlined from '_ZN22ObjectSampleCheckpoint5writeEPK13ObjectSamplerP9EdgeStorebP6Thread.part.0' at /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp:381:46: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:34: warning: '__builtin_strncpy' specified bound depends on the length of the source argument [-Wstringop-overflow=] ? 106 |?? return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); ????? |????????????????????????????????? ^ /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp: In function '_ZN22ObjectSampleCheckpoint5writeEPK13ObjectSamplerP9EdgeStorebP6Thread.part.0': /localhome/git/jdk-BAR/open/src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp:83:28: note: length computed here ?? 83 |?? const size_t len = strlen(_buffer); ????? |??????????????????????????? ^ I don't think anyone used LTO seriously since the old Oracle arm-32 port. The major blocker is the added linking time spent for hotspot, I think. Patches to fix this is more than welcome, though! /Magnus > > Matthias From aph at redhat.com Wed Jan 27 09:43:36 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jan 2021 09:43:36 +0000 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: <2f9e8ea2-a3a9-53d0-f735-894272a3717e@oracle.com> References: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com> <2f9e8ea2-a3a9-53d0-f735-894272a3717e@oracle.com> Message-ID: <90fd9651-f954-42da-1282-bf9a7de63e13@redhat.com> On 1/26/21 6:42 PM, erik.joelsson at oracle.com wrote: > My understanding is that Apple chose to not provide JNF for aarch64, so > if you want to build OpenJDK, you first need to build JNF yourself (it's > available in github). Phil is working on removing this dependency > completely, which will solve this issue [1]. > > In the meantime, I don't think we should rely on finding JNF in > unsupported locations inside Xcode. Could we wait with integrating this > port until it can be built without such hacks? That sounds right to me. In the meantime, there is some cleanup work to be done in mainline on slow_signature_handler, which will potentially make the AArch64 back end merge much simpler. -- 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 From shade at openjdk.java.net Wed Jan 27 09:52:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 09:52:40 GMT Subject: RFR: 8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386" In-Reply-To: <6qKzSVX4HET7HlmR9Qr-QQ9VhWbMKblcZua52yL69SQ=.762210e5-88da-4642-8442-dfba75aea015@github.com> References: <6qKzSVX4HET7HlmR9Qr-QQ9VhWbMKblcZua52yL69SQ=.762210e5-88da-4642-8442-dfba75aea015@github.com> Message-ID: On Wed, 27 Jan 2021 08:18:56 GMT, Magnus Ihse Bursie wrote: >> See for example: >> https://github.com/shipilev/jdk/runs/1771453139?check_suite_focus=true >> >> E: Could not configure 'libc6:i386'. >> E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) >> >> It seems JDK-8259924 helped only for a while. >> >> There is a [bugfix](https://salsa.debian.org/apt-team/apt/-/commit/998a17d7e6f834c341f198ca5b6df2f27e18df38) in Apt 2.0.4 that prints these warnings and then allows the whole thing to continue. It was [released](https://bugs.launchpad.net/ubuntu-cdimage/+bug/1871268) in Ubuntu a week ago, but it is not in base image yet. So, if we upgrade apt before installing other packages, apt updates from 2.0.2 to 2.0.4 and the whole thing starts to work. >> >> This also reverts changes added by previous attempt in [JDK-8259924](https://github.com/openjdk/jdk/commit/a9519c83). > > Marked as reviewed by ihse (Reviewer). Okay to push now, as to unbreak the GHA? ------------- PR: https://git.openjdk.java.net/jdk/pull/2243 From doko at ubuntu.com Wed Jan 27 10:42:04 2021 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 27 Jan 2021 11:42:04 +0100 Subject: building OpenJDK 11 with link time optimizations? In-Reply-To: References: <5e8c9458-4e66-7b93-c14b-c5e6d4f3cbc8@ubuntu.com> Message-ID: On 1/27/21 10:35 AM, Magnus Ihse Bursie wrote: > On 2021-01-26 17:08, Matthias Klose wrote: >> Several Linux distros now build with link time optimizations (-flto=auto) by >> default.? It looks like 15 and newer versions can be built with -flto. I haven't >> yet checked test results for LTO/non-LTO builds. I also only tried building with >> GCC 10. >> >> 11 still fails with >> /usr/bin/ld: /tmp/libjvm.so.xGmnnW.ltrans45.ltrans.o: in function >> `G1CMOopClosure::do_oop(oopDesc**)': >> /<>/openjdk-lts-11.0.9.1+1/make/hotspot/./src/hotspot/share/gc/g1/g1OopClosures.hpp:176: >> >> undefined reference to `void G1CMOopClosure::do_oop_work(oopDesc**)' >> [...] >> >> However this might be just the first build failure. > > Is this when building with --enable-jvm-feature-link-time-opt on linux-x64? No, just passing -flto=auto in CFLAGS, CXXFLAGS, and LDFLAGS, and configuring with --with-extra-*flags here's a build log for such kind of build: https://launchpad.net/ubuntu/+archive/test-rebuild-20201216-hirsute-lto/+build/20573901 > When I try that (with gcc-10 on Ubuntu) on the mainline, I get: [...] these seem to be warnings "only". A 16+33 build configured with --enable-jvm-feature-link-time-opt also succeeds for me. at least for GCC, the LTO streaming format doesn't collect warning options, so maybe these should be passed to the linker explicitly when configuring with the lto option. > I don't think anyone used LTO seriously since the old Oracle arm-32 port. The > major blocker is the added linking time spent for hotspot, I think. Patches to > fix this is more than welcome, though! currently --enable-jvm-feature-link-time-opt only builds with -flto, and therefore sequentially. An obvious thing to do is either to build with -flto=auto or -flto=jobserver to use all available cores for the link. I also saw in the link: /usr/bin/nm: bytecodeHistogram.o: no symbols /usr/bin/nm: c1_Defs.o: no symbols /usr/bin/nm: instanceOop.o: no symbols /usr/bin/nm: oopsHierarchy.o: no symbols /usr/bin/nm: operator_new.o: no symbols /usr/bin/nm: register.o: no symbols /usr/bin/nm: vm_version_linux_x86.o: no symbols /usr/bin/nm: weakProcessorPhases.o: no symbols Creating mapfile Linking libjvm.so if something relies on the object code, then maybe use -ffat-lto-objects, although this will slow down the build of the object files. Matthias From ihse at openjdk.java.net Wed Jan 27 10:51:40 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 27 Jan 2021 10:51:40 GMT Subject: RFR: 8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386" In-Reply-To: References: <6qKzSVX4HET7HlmR9Qr-QQ9VhWbMKblcZua52yL69SQ=.762210e5-88da-4642-8442-dfba75aea015@github.com> Message-ID: On Wed, 27 Jan 2021 09:50:13 GMT, Aleksey Shipilev wrote: >> Marked as reviewed by ihse (Reviewer). > > Okay to push now, as to unbreak the GHA? Yeah..? What are you waiting for otherwise? The 24 hour rule only apply to Hotspot coce. ------------- PR: https://git.openjdk.java.net/jdk/pull/2243 From shade at openjdk.java.net Wed Jan 27 10:51:41 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 10:51:41 GMT Subject: RFR: 8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386" In-Reply-To: References: <6qKzSVX4HET7HlmR9Qr-QQ9VhWbMKblcZua52yL69SQ=.762210e5-88da-4642-8442-dfba75aea015@github.com> Message-ID: On Wed, 27 Jan 2021 10:46:04 GMT, Magnus Ihse Bursie wrote: >> Okay to push now, as to unbreak the GHA? > > Yeah..? What are you waiting for otherwise? The 24 hour rule only apply to Hotspot coce. I believe 24 hour rule is the generic courtesy rule for everything. So I was asking explicitly if we are good with ignoring that courtesy for this instance. ------------- PR: https://git.openjdk.java.net/jdk/pull/2243 From shade at openjdk.java.net Wed Jan 27 10:51:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 10:51:42 GMT Subject: Integrated: 8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386" In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 19:08:41 GMT, Aleksey Shipilev wrote: > See for example: > https://github.com/shipilev/jdk/runs/1771453139?check_suite_focus=true > > E: Could not configure 'libc6:i386'. > E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) > > It seems JDK-8259924 helped only for a while. > > There is a [bugfix](https://salsa.debian.org/apt-team/apt/-/commit/998a17d7e6f834c341f198ca5b6df2f27e18df38) in Apt 2.0.4 that prints these warnings and then allows the whole thing to continue. It was [released](https://bugs.launchpad.net/ubuntu-cdimage/+bug/1871268) in Ubuntu a week ago, but it is not in base image yet. So, if we upgrade apt before installing other packages, apt updates from 2.0.2 to 2.0.4 and the whole thing starts to work. > > This also reverts changes added by previous attempt in [JDK-8259924](https://github.com/openjdk/jdk/commit/a9519c83). This pull request has now been integrated. Changeset: bf15c709 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/bf15c709 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386" Reviewed-by: ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/2243 From magnus.ihse.bursie at oracle.com Wed Jan 27 11:39:54 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Jan 2021 12:39:54 +0100 Subject: building OpenJDK 11 with link time optimizations? In-Reply-To: References: <5e8c9458-4e66-7b93-c14b-c5e6d4f3cbc8@ubuntu.com> Message-ID: On 2021-01-27 11:42, Matthias Klose wrote: > On 1/27/21 10:35 AM, Magnus Ihse Bursie wrote: >> On 2021-01-26 17:08, Matthias Klose wrote: >>> Several Linux distros now build with link time optimizations (-flto=auto) by >>> default.? It looks like 15 and newer versions can be built with -flto. I haven't >>> yet checked test results for LTO/non-LTO builds. I also only tried building with >>> GCC 10. >>> >>> 11 still fails with >>> /usr/bin/ld: /tmp/libjvm.so.xGmnnW.ltrans45.ltrans.o: in function >>> `G1CMOopClosure::do_oop(oopDesc**)': >>> /<>/openjdk-lts-11.0.9.1+1/make/hotspot/./src/hotspot/share/gc/g1/g1OopClosures.hpp:176: >>> >>> undefined reference to `void G1CMOopClosure::do_oop_work(oopDesc**)' >>> [...] >>> >>> However this might be just the first build failure. >> Is this when building with --enable-jvm-feature-link-time-opt on linux-x64? > No, just passing -flto=auto in CFLAGS, CXXFLAGS, and LDFLAGS, and configuring > with --with-extra-*flags > here's a build log for such kind of build: > https://launchpad.net/ubuntu/+archive/test-rebuild-20201216-hirsute-lto/+build/20573901 > >> When I try that (with gcc-10 on Ubuntu) on the mainline, I get: > [...] > > these seem to be warnings "only". A 16+33 build configured with > --enable-jvm-feature-link-time-opt also succeeds for me. > > at least for GCC, the LTO streaming format doesn't collect warning options, so > maybe these should be passed to the linker explicitly when configuring with the > lto option. So these are warnings that we disable to the compiler, but when running with lto, it is triggered first when linking, instead of when compiling? I see. > >> I don't think anyone used LTO seriously since the old Oracle arm-32 port. The >> major blocker is the added linking time spent for hotspot, I think. Patches to >> fix this is more than welcome, though! > currently --enable-jvm-feature-link-time-opt only builds with -flto, and > therefore sequentially. An obvious thing to do is either to build with > -flto=auto or -flto=jobserver to use all available cores for the link. Well, that did drastically improve the link speed. On my machine it went from ~12 minutes with the "old" LTO, to 3 min 20 s with -flto=jobserver. This is still quite a lot more than without LTO (which is < 2 minutes on the same machine), but very much bearable. We should definitely add =jobserver to the -flto option. We should probably also clean up some of the other dumb stuff that link-time-opt does, since that's just backwards compatibility with the old (and now removed) behavior for Oracle arm-32. However, the resulting libjvm.so was several times larger, which suprised me quite a bit. I assumed (perhaps naively) that using LTO would result in a more compact end binary. (With LTO: 59 MB, without: 22 MB). > > I also saw in the link: > /usr/bin/nm: bytecodeHistogram.o: no symbols > /usr/bin/nm: c1_Defs.o: no symbols > /usr/bin/nm: instanceOop.o: no symbols > /usr/bin/nm: oopsHierarchy.o: no symbols > /usr/bin/nm: operator_new.o: no symbols > /usr/bin/nm: register.o: no symbols > /usr/bin/nm: vm_version_linux_x86.o: no symbols > /usr/bin/nm: weakProcessorPhases.o: no symbols > Creating mapfile > Linking libjvm.so > > if something relies on the object code, then maybe use -ffat-lto-objects, > although this will slow down the build of the object files. My initial guess would be that you are building without certain components, which make these files end up empty. But the names sound very much general, so that is a bit suspicious... /Magnus > > Matthias From akozlov at openjdk.java.net Wed Jan 27 14:50:01 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 27 Jan 2021 14:50:01 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v7] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year for BsdAARCH64ThreadContext.java - Fix inclusing of StubRoutines header ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/f1ef6240..9d8b07c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=05-06 Stats: 5 lines in 4 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Wed Jan 27 15:01:47 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Wed, 27 Jan 2021 15:01:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 08:36:19 GMT, Magnus Ihse Bursie wrote: > Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR. I believe it's better be done under separate PR/bugfix, so it can be completely reverted once JNF removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From erikj at openjdk.java.net Wed Jan 27 19:28:50 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 27 Jan 2021 19:28:50 GMT Subject: RFR: JDK-8260518: Change default -mmacosx-version-min to 10.12 Message-ID: To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019). The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap. Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402. ------------- Commit messages: - Bump macosx version min/max to 10.12 Changes: https://git.openjdk.java.net/jdk/pull/2268/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2268&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260518 Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2268/head:pull/2268 PR: https://git.openjdk.java.net/jdk/pull/2268 From tbell at openjdk.java.net Wed Jan 27 20:21:40 2021 From: tbell at openjdk.java.net (Tim Bell) Date: Wed, 27 Jan 2021 20:21:40 GMT Subject: RFR: JDK-8260518: Change default -mmacosx-version-min to 10.12 In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 19:23:48 GMT, Erik Joelsson wrote: > To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019). > > The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap. > > Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402. Looks good. ------------- Marked as reviewed by tbell (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2268 From prr at openjdk.java.net Wed Jan 27 20:46:40 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 27 Jan 2021 20:46:40 GMT Subject: RFR: JDK-8260518: Change default -mmacosx-version-min to 10.12 In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 19:23:48 GMT, Erik Joelsson wrote: > To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019). > > The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap. > > Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2268 From rhalade at openjdk.java.net Thu Jan 28 01:28:57 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 28 Jan 2021 01:28:57 GMT Subject: RFR: 8256421: Add 2 HARICA roots to Oracle Root CA Program Message-ID: Following two roots are added to cacerts store - CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR ------------- Commit messages: - 8256421: Add 2 HARICA roots to Oracle Root CA Program Changes: https://git.openjdk.java.net/jdk/pull/2272/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2272&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256421 Stats: 393 lines in 4 files changed: 390 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2272/head:pull/2272 PR: https://git.openjdk.java.net/jdk/pull/2272 From serb at openjdk.java.net Thu Jan 28 03:57:38 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 28 Jan 2021 03:57:38 GMT Subject: RFR: JDK-8260518: Change default -mmacosx-version-min to 10.12 In-Reply-To: References: Message-ID: <6gX0RaStGEsJCApMJtyVU3ytAfU7psYuvyVqUGldpp8=.441eeb48-e558-4e16-b68d-7a4b6fe707f6@github.com> On Wed, 27 Jan 2021 20:43:44 GMT, Phil Race wrote: >> To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019). >> >> The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap. >> >> Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402. > > Marked as reviewed by prr (Reviewer). Will this affect the minimum version of macOS which will be able to run on? don't we need a CSR(not sure)? ------------- PR: https://git.openjdk.java.net/jdk/pull/2268 From ihse at openjdk.java.net Thu Jan 28 12:12:45 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 28 Jan 2021 12:12:45 GMT Subject: RFR: JDK-8260518: Change default -mmacosx-version-min to 10.12 In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 19:23:48 GMT, Erik Joelsson wrote: > To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019). > > The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap. > > Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402. Looks good to me. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2268 From erik.joelsson at oracle.com Thu Jan 28 14:10:49 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 28 Jan 2021 06:10:49 -0800 Subject: RFR: JDK-8260518: Change default -mmacosx-version-min to 10.12 In-Reply-To: <6gX0RaStGEsJCApMJtyVU3ytAfU7psYuvyVqUGldpp8=.441eeb48-e558-4e16-b68d-7a4b6fe707f6@github.com> References: <6gX0RaStGEsJCApMJtyVU3ytAfU7psYuvyVqUGldpp8=.441eeb48-e558-4e16-b68d-7a4b6fe707f6@github.com> Message-ID: On 2021-01-27 19:57, Sergey Bylokhov wrote: > On Wed, 27 Jan 2021 20:43:44 GMT, Phil Race wrote: > >>> To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019). >>> >>> The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap. >>> >>> Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402. >> Marked as reviewed by prr (Reviewer). > Will this affect the minimum version of macOS which will be able to run on? don't we need a CSR(not sure)? Yes it will and no, as far as I'm aware, we don't need anything like that. For Oracle, the support matrix for JDK 16 was 10.13+. The problem would be if some other OpenJDK distributor wanted to keep supporting something older. /Erik From erikj at openjdk.java.net Thu Jan 28 16:08:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 28 Jan 2021 16:08:53 GMT Subject: RFR: JDK-8260518: Change default -mmacosx-version-min to 10.12 [v2] In-Reply-To: References: Message-ID: > To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019). > > The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap. > > Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2268/files - new: https://git.openjdk.java.net/jdk/pull/2268/files/41d60207..4eb09479 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2268&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2268&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2268/head:pull/2268 PR: https://git.openjdk.java.net/jdk/pull/2268 From serb at openjdk.java.net Thu Jan 28 17:17:43 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 28 Jan 2021 17:17:43 GMT Subject: RFR: JDK-8260518: Change default -mmacosx-version-min to 10.12 [v2] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 16:08:53 GMT, Erik Joelsson wrote: >> To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019). >> >> The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap. >> >> Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Copyright year Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2268 From prr at openjdk.java.net Fri Jan 29 00:11:54 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Jan 2021 00:11:54 GMT Subject: RFR: 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m Message-ID: This removes the JNF dependency from the jdk.hotspot.agent module. The macro expansions are the same as already used in the Java desktop module - which actually uses a macro still but there there are hundreds of uses. The function of this macro code is to prevent NSExceptions escaping to Java and also to drain the auto-release pool. What test group would be good for verifying this change ? ------------- Commit messages: - 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m - 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m Changes: https://git.openjdk.java.net/jdk/pull/2304/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2304&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257988 Stats: 42 lines in 2 files changed: 32 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2304.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2304/head:pull/2304 PR: https://git.openjdk.java.net/jdk/pull/2304 From cjplummer at openjdk.java.net Fri Jan 29 00:18:41 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 29 Jan 2021 00:18:41 GMT Subject: RFR: 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 22:40:57 GMT, Phil Race wrote: > This removes the JNF dependency from the jdk.hotspot.agent module. > The macro expansions are the same as already used in the Java desktop module - which actually uses a macro > still but there there are hundreds of uses. > The function of this macro code is to prevent NSExceptions escaping to Java and also to drain the auto-release pool. > What test group would be good for verifying this change ? For testing you want `test/jdk/sun/tools/jhsdb/` and `test/hotspot/jtreg/serviceability/sa` ------------- PR: https://git.openjdk.java.net/jdk/pull/2304 From prr at openjdk.java.net Fri Jan 29 00:34:55 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Jan 2021 00:34:55 GMT Subject: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module Message-ID: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com> This completes the desktop module JNF removal * remove -framework JavaNativeFoundation from make files * remove #import from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S * replace JNFNSToJavaString with NSStringToJavaString and JNFJavaToNSString with JavaStringToNSString * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this) * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods. * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed. * Remove the single usage of JNFPerformEnvBlock * replace JNFJavaToNSNumber in single A11Y file with local replacement * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION) ------------- Commit messages: - 8260616: Removing remaining JNF dependencies in the java.desktop module Changes: https://git.openjdk.java.net/jdk/pull/2305/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260616 Stats: 431 lines in 71 files changed: 196 ins; 96 del; 139 mod Patch: https://git.openjdk.java.net/jdk/pull/2305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2305/head:pull/2305 PR: https://git.openjdk.java.net/jdk/pull/2305 From cjplummer at openjdk.java.net Fri Jan 29 00:35:41 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 29 Jan 2021 00:35:41 GMT Subject: RFR: 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 00:15:56 GMT, Chris Plummer wrote: >> This removes the JNF dependency from the jdk.hotspot.agent module. >> The macro expansions are the same as already used in the Java desktop module - which actually uses a macro >> still but there there are hundreds of uses. >> The function of this macro code is to prevent NSExceptions escaping to Java and also to drain the auto-release pool. >> What test group would be good for verifying this change ? > > For testing you want `test/jdk/sun/tools/jhsdb/` and `test/hotspot/jtreg/serviceability/sa` I'm doubtful you'll find anyone on serviceability-dev that understands JNF and the implications it has on MacosxDebuggerLocal.m. Although I've done a lot of work in this file myself recently, it's all bee sans any knowledge of JNF, Cocoa, or Objective C. You might be better off asking reviewers that looked at other recent PRs to remove JNF usage. However, having looked through [JDK-8257852](https://bugs.openjdk.java.net/browse/JDK-8257852) and from there finding [JDK-8259651](https://bugs.openjdk.java.net/browse/JDK-8259651), I'm wondering why you didn't just replace JNF_COCOA_ENTER/EXIT with the new JNI_COCOA_ENTER/EXIT in this PR also? Is it because they are not in a place that can be accessed from this file? ------------- PR: https://git.openjdk.java.net/jdk/pull/2304 From ihse at openjdk.java.net Fri Jan 29 10:04:42 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 29 Jan 2021 10:04:42 GMT Subject: RFR: 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 22:40:57 GMT, Phil Race wrote: > This removes the JNF dependency from the jdk.hotspot.agent module. > The macro expansions are the same as already used in the Java desktop module - which actually uses a macro > still but there there are hundreds of uses. > The function of this macro code is to prevent NSExceptions escaping to Java and also to drain the auto-release pool. > What test group would be good for verifying this change ? Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2304 From ihse at openjdk.java.net Fri Jan 29 10:56:42 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 29 Jan 2021 10:56:42 GMT Subject: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module In-Reply-To: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com> References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com> Message-ID: On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race wrote: > This completes the desktop module JNF removal > > * remove -framework JavaNativeFoundation from make files > > * remove #import from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S > > * replace JNFNSToJavaString with NSStringToJavaString and JNFJavaToNSString with JavaStringToNSString > > * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString > > * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI > > * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this) > > * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods. > > * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed. > > * Remove the single usage of JNFPerformEnvBlock > > * replace JNFJavaToNSNumber in single A11Y file with local replacement > > * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement > > * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m > > * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION) I mostly have questions about what is missing from this PR. :-) (If this is supposed to remove the final remnants of JNF) - There is a disabled warning in `make/autoconf/flags-cflags.m4`, line 173, referring to JavaNativeFoundation. It can presumably be removed. If it triggers individually instead, the warning should be disabled on a per-library basis. - In `make/modules/java.base/Lib.gmk`, line 99 & 113, are references to JavaNativeFoundation. It seems that `libosxsecurity` needs to be cleaned from JNF as well. Also, the comments indicate that the exception for STATIC_BUILD can be removed. (You can verify this with `configure --enable-static-build`) - In `make/modules/java.desktop/Lib.gmk`, line 129, and `make/modules/java.desktop/lib/Awt2dLibraries.gmk`, line 866 & 094, it seems like `libosx`, `libawt_lwawt`, and `liboxui` also has JNF that needs to be removed. If these are fixed in any of the other issues for the umbrella JDK-8257852, I apologize. I could not figure that out. - There is also a test dependency that I have seen being addressed, in `make/test/JtregNativeJdk.gmk` line 82, for `libTestMainKeyWindow`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2305 From erik.joelsson at oracle.com Fri Jan 29 13:45:16 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 29 Jan 2021 05:45:16 -0800 Subject: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module In-Reply-To: References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com> Message-ID: <99d3d648-803e-a014-92c0-50c862e5c328@oracle.com> On 2021-01-29 02:56, Magnus Ihse Bursie wrote: > On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race wrote: > >> This completes the desktop module JNF removal >> >> * remove -framework JavaNativeFoundation from make files >> >> * remove #import from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S >> >> * replace JNFNSToJavaString with NSStringToJavaString and JNFJavaToNSString with JavaStringToNSString >> >> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString >> >> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI >> >> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this) >> >> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods. >> >> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed. >> >> * Remove the single usage of JNFPerformEnvBlock >> >> * replace JNFJavaToNSNumber in single A11Y file with local replacement >> >> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement >> >> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m >> >> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION) > I mostly have questions about what is missing from this PR. :-) (If this is supposed to remove the final remnants of JNF) > > - There is a disabled warning in `make/autoconf/flags-cflags.m4`, line 173, referring to JavaNativeFoundation. It can presumably be removed. If it triggers individually instead, the warning should be disabled on a per-library basis. > > - In `make/modules/java.base/Lib.gmk`, line 99 & 113, are references to JavaNativeFoundation. It seems that `libosxsecurity` needs to be cleaned from JNF as well. Also, the comments indicate that the exception for STATIC_BUILD can be removed. (You can verify this with `configure --enable-static-build`) libosxsecurity is being worked on separately, see https://github.com/openjdk/jdk/pull/1845 That said, we may need a separate bug for build to remove the any lingering global stuff after each component has been fixed. /Erik > - In `make/modules/java.desktop/Lib.gmk`, line 129, and `make/modules/java.desktop/lib/Awt2dLibraries.gmk`, line 866 & 094, it seems like `libosx`, `libawt_lwawt`, and `liboxui` also has JNF that needs to be removed. If these are fixed in any of the other issues for the umbrella JDK-8257852, I apologize. I could not figure that out. > > - There is also a test dependency that I have seen being addressed, in `make/test/JtregNativeJdk.gmk` line 82, for `libTestMainKeyWindow`. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2305 From erikj at openjdk.java.net Fri Jan 29 14:24:41 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 29 Jan 2021 14:24:41 GMT Subject: Integrated: JDK-8260518: Change default -mmacosx-version-min to 10.12 In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 19:23:48 GMT, Erik Joelsson wrote: > To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019). > > The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap. > > Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402. This pull request has now been integrated. Changeset: 53f1b938 Author: Erik Joelsson URL: https://git.openjdk.java.net/jdk/commit/53f1b938 Stats: 5 lines in 3 files changed: 1 ins; 0 del; 4 mod 8260518: Change default -mmacosx-version-min to 10.12 Reviewed-by: tbell, prr, ihse, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/2268 From weijun at openjdk.java.net Fri Jan 29 14:35:50 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 14:35:50 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 19:20:47 GMT, Weijun Wang wrote: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) New commit pushed. There is completely no dependency on JavaNativeFramework anymore. Major change this time: Update the format of `SCDynamicStoreConfig::getKerberosConfig`. ToDo: clean up `JNIUtilities.h`, take back `JNFPerformEnvBlock`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Fri Jan 29 14:35:50 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 14:35:50 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m Message-ID: This fix covers both - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) ------------- Commit messages: - error check, new JavaStringToNSString - do not find class and method in loop - no more header file - better macro, no more JNI_COCOA_ENTER - Merge branch 'master' into 8257858 - callback libosxsecurity/KeystoreImpl.m - new SCDynamicStoreConfig return value format - add framework so link succeeds - 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m Changes: https://git.openjdk.java.net/jdk/pull/1845/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257858 Stats: 484 lines in 6 files changed: 153 ins; 212 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From erikj at openjdk.java.net Fri Jan 29 14:48:41 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 29 Jan 2021 14:48:41 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 19:20:47 GMT, Weijun Wang wrote: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Fri Jan 29 14:57:56 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 14:57:56 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v2] In-Reply-To: References: Message-ID: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com> > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: same behavior as before -- empty realm map ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1845/files - new: https://git.openjdk.java.net/jdk/pull/1845/files/cb02503f..b0ee18a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From prr at openjdk.java.net Fri Jan 29 16:41:44 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Jan 2021 16:41:44 GMT Subject: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module In-Reply-To: References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com> Message-ID: On Fri, 29 Jan 2021 10:53:42 GMT, Magnus Ihse Bursie wrote: >> This completes the desktop module JNF removal >> >> * remove -framework JavaNativeFoundation from make files >> >> * remove #import from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S >> >> * replace JNFNSToJavaString with NSStringToJavaString and JNFJavaToNSString with JavaStringToNSString >> >> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString >> >> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI >> >> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this) >> >> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods. >> >> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed. >> >> * Remove the single usage of JNFPerformEnvBlock >> >> * replace JNFJavaToNSNumber in single A11Y file with local replacement >> >> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement >> >> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m >> >> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION) > > I mostly have questions about what is missing from this PR. :-) (If this is supposed to remove the final remnants of JNF) > > - There is a disabled warning in `make/autoconf/flags-cflags.m4`, line 173, referring to JavaNativeFoundation. It can presumably be removed. If it triggers individually instead, the warning should be disabled on a per-library basis. > > - In `make/modules/java.base/Lib.gmk`, line 99 & 113, are references to JavaNativeFoundation. It seems that `libosxsecurity` needs to be cleaned from JNF as well. Also, the comments indicate that the exception for STATIC_BUILD can be removed. (You can verify this with `configure --enable-static-build`) > > - In `make/modules/java.desktop/Lib.gmk`, line 129, and `make/modules/java.desktop/lib/Awt2dLibraries.gmk`, line 866 & 094, it seems like `libosx`, `libawt_lwawt`, and `liboxui` also has JNF that needs to be removed. If these are fixed in any of the other issues for the umbrella JDK-8257852, I apologize. I could not figure that out. > > - There is also a test dependency that I have seen being addressed, in `make/test/JtregNativeJdk.gmk` line 82, for `libTestMainKeyWindow`. Right, this is the desktop module as per the first line of the comment. java.base needs to be removed by the other PR as Erik said. I had not spotted it, but I don't see why the make/test /JtregNativeJdk.gmk case needs to link this framework. I don't see it being used by the test in question. But we can just remove it and prove it - but probably a separate PR since it is nothing to do with the desktop module and the autoconf code needs to be updated once everything else is in. ------------- PR: https://git.openjdk.java.net/jdk/pull/2305 From gziemski at openjdk.java.net Fri Jan 29 17:01:51 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 29 Jan 2021 17:01:51 GMT Subject: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module In-Reply-To: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com> References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com> Message-ID: On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race wrote: > This completes the desktop module JNF removal > > * remove -framework JavaNativeFoundation from make files > > * remove #import from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S > > * replace JNFNSToJavaString with NSStringToJavaString and JNFJavaToNSString with JavaStringToNSString > > * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString > > * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI > > * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this) > > * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods. > > * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed. > > * Remove the single usage of JNFPerformEnvBlock > > * replace JNFJavaToNSNumber in single A11Y file with local replacement > > * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement > > * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m > > * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION) Changes requested by gziemski (Committer). src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 608: > 606: { > 607: // Get string to draw and the length > 608: const jchar *unichars = JNFGetStringUTF16UniChars(env, str); According to `JNFString.h`, the `JNFGetStringUTF16UniChars()` API: /* * Gets UTF16 unichars from a Java string, and checks for errors and raises a JNFException if * the unichars cannot be obtained from Java. */ raises a (JNFException) if it can't get the chars, but now we simply return if `GetStringChars()` can not return the chars. Seems like we handle this case differently in the new code now - is this change desired and correct? src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 601: > 599: jchar unichars[len]; > 600: (*env)->GetStringRegion(env, str, 0, len, unichars); > 601: CHECK_EXCEPTION(); Are `JNF_CHECK_AND_RETHROW_EXCEPTION` and `CHECK_EXCEPTION` equivalent? `JNF_CHECK_AND_RETHROW_EXCEPTION` seems to throw exception, but `CHECK_EXCEPTION` does not? src/java.desktop/macosx/native/libosxui/ScreenMenu.m line 165: > 163: */ > 164: static jlong NSTimeIntervalToJavaMilliseconds(NSTimeInterval interval) { > 165: NSTimeInterval interval1970 = interval + NSTimeIntervalSince1970; Is it required for the APIs using the value from this function to expect the time calculated since Jan 1st 1970? src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 83: > 81: stringWithFileSystemRepresentation:chs length:len]; > 82: return result; > 83: } Why are we doing: `java_string -> chars -> NSString -> chars -> [NSFileManager stringWithFileSystemRepresentation]` ? Why not just get the raw characters form JNI and feed them directly into `[NSFileManager stringWithFileSystemRepresentation]`, ie: `java_string -> chars -> [NSFileManager stringWithFileSystemRepresentation]` and skip the `JavaStringToNSString` step altogether? ------------- PR: https://git.openjdk.java.net/jdk/pull/2305 From gziemski at openjdk.java.net Fri Jan 29 17:05:42 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 29 Jan 2021 17:05:42 GMT Subject: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module In-Reply-To: References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com> Message-ID: On Fri, 29 Jan 2021 16:57:09 GMT, Gerard Ziemski wrote: >> This completes the desktop module JNF removal >> >> * remove -framework JavaNativeFoundation from make files >> >> * remove #import from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S >> >> * replace JNFNSToJavaString with NSStringToJavaString and JNFJavaToNSString with JavaStringToNSString >> >> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString >> >> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI >> >> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this) >> >> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods. >> >> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed. >> >> * Remove the single usage of JNFPerformEnvBlock >> >> * replace JNFJavaToNSNumber in single A11Y file with local replacement >> >> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement >> >> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m >> >> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION) > > Changes requested by gziemski (Committer). Lots of small changes you had to handle here. Thank you for doing it! ------------- PR: https://git.openjdk.java.net/jdk/pull/2305 From prr at openjdk.java.net Fri Jan 29 17:24:05 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Jan 2021 17:24:05 GMT Subject: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module [v2] In-Reply-To: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com> References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com> Message-ID: > This completes the desktop module JNF removal > > * remove -framework JavaNativeFoundation from make files > > * remove #import from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S > > * replace JNFNSToJavaString with NSStringToJavaString and JNFJavaToNSString with JavaStringToNSString > > * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString > > * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI > > * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this) > > * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods. > > * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed. > > * Remove the single usage of JNFPerformEnvBlock > > * replace JNFJavaToNSNumber in single A11Y file with local replacement > > * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement > > * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m > > * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION) Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8260616: Removing remaining JNF dependencies in the java.desktop modul ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2305/files - new: https://git.openjdk.java.net/jdk/pull/2305/files/1951d6d8..efab1de5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2305/head:pull/2305 PR: https://git.openjdk.java.net/jdk/pull/2305 From prr at openjdk.java.net Fri Jan 29 17:24:06 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Jan 2021 17:24:06 GMT Subject: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module [v2] In-Reply-To: References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com> Message-ID: On Fri, 29 Jan 2021 17:02:30 GMT, Gerard Ziemski wrote: >> Changes requested by gziemski (Committer). > > Lots of small changes you had to handle here. Thank you for doing it! I pushed a commit with the remaining -lframework ... removals in the desktop makefiles that I had somehow missed ... ------------- PR: https://git.openjdk.java.net/jdk/pull/2305 From prr at openjdk.java.net Fri Jan 29 17:25:40 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Jan 2021 17:25:40 GMT Subject: RFR: 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 10:01:42 GMT, Magnus Ihse Bursie wrote: >> This removes the JNF dependency from the jdk.hotspot.agent module. >> The macro expansions are the same as already used in the Java desktop module - which actually uses a macro >> still but there there are hundreds of uses. >> The function of this macro code is to prevent NSExceptions escaping to Java and also to drain the auto-release pool. >> What test group would be good for verifying this change ? > > Build changes look good. > Is it because they are not in a place that can be accessed from this file? Right 99% of JNF usage was the desktop module many, many files, 1300 references .. the entire rest of the JDK had just 3 files each in a different module ! It did not seem worth creating a JDK-wide platform-specific library to support this. ------------- PR: https://git.openjdk.java.net/jdk/pull/2304 From prr at openjdk.java.net Fri Jan 29 19:56:45 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Jan 2021 19:56:45 GMT Subject: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module [v2] In-Reply-To: References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com> Message-ID: On Fri, 29 Jan 2021 16:23:20 GMT, Gerard Ziemski wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8260616: Removing remaining JNF dependencies in the java.desktop modul > > src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 601: > >> 599: jchar unichars[len]; >> 600: (*env)->GetStringRegion(env, str, 0, len, unichars); >> 601: CHECK_EXCEPTION(); > > Are `JNF_CHECK_AND_RETHROW_EXCEPTION` and `CHECK_EXCEPTION` equivalent? > > `JNF_CHECK_AND_RETHROW_EXCEPTION` seems to throw exception, but `CHECK_EXCEPTION` does not? JNF_CHECK_AND_RETHROW_EXCEPTION is this // JNF_CHECK_AND_RETHROW_EXCEPTION - rethrows exceptions from Java // // Takes an exception thrown from Java, and transforms it into an // NSException. The NSException should bubble up to the upper-most // JNF_COCOA_ENTER/JNF_COCOA_EXIT pair, and then be re-thrown as // a Java exception when returning from JNI. This check should be // done after raw JNI operations which could cause a Java exception // to be be thrown. The JNF{Get/Set/Call} macros below do this // check automatically. #define JNF_CHECK_AND_RETHROW_EXCEPTION(env) \ { \ jthrowable _exception = (*env)->ExceptionOccurred(env); \ if (_exception) [JNFException raise:env throwable:_exception]; \ } So what it actually does is clear the exception, raise an NSException and when the code reaches JNF_COCOA_EXIT - which then has to be there - it clears the NSException and re-throws the Java exception. So the name of the macro is misleading since this does NOT itself rethrow the exception, it relies on other code to do that. CHECK_EXCEPTION will amount to the same - it throws an NSException if there is a Java exception pending. And it will clear the NSException before exiting back to Java. The difference is that it doesn't clear the Java Exception and later rethrow it since there is no need There is one exception to this in CHECK_EXCEPTION - if this is the main (ie appkit) thread the java exception is cleared since there's no one to return it to ... > src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 608: > >> 606: { >> 607: // Get string to draw and the length >> 608: const jchar *unichars = JNFGetStringUTF16UniChars(env, str); > > According to `JNFString.h`, the `JNFGetStringUTF16UniChars()` API: > > /* > * Gets UTF16 unichars from a Java string, and checks for errors and raises a JNFException if > * the unichars cannot be obtained from Java. > */ > > raises a (JNFException) if it can't get the chars, but now we simply return if `GetStringChars()` can not return the chars. > > Seems like we handle this case differently in the new code now - is this change desired and correct? You are correct, but I decided that here it is fine. If GetStringChars fails it will return NULL (it does not raise any excptions itself). I added a check for NULL if NULL we then return from the JNI method to Java. In the old case it also would return but would additionally propagate that raised exception to Java which JNF decided to throw into the mix when there's already a standard way of testing failure. And since we already know str != NULL we are in the realms of something went badly wrong inside the VM for this to fail. So I decided this was all fine. > src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 83: > >> 81: stringWithFileSystemRepresentation:chs length:len]; >> 82: return result; >> 83: } > > Why are we doing: > > `java_string -> chars -> NSString -> chars -> [NSFileManager stringWithFileSystemRepresentation]` > > ? > > Why not just get the raw characters form JNI and feed them directly into `[NSFileManager stringWithFileSystemRepresentation]`, ie: > > `java_string -> chars -> [NSFileManager stringWithFileSystemRepresentation]` > > and skip the `JavaStringToNSString` step altogether? I tried to explain the odd-ness of this in the comments preceding the function definition. Near as I could figure out that intermediate call is needed to do the decomposition since the NSFileManager won't do that. But this is not exactly my area of expertise and there may be a better way. Who is an expert on the intricacies of the macOS file system naming ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2305 From erikj at openjdk.java.net Fri Jan 29 19:58:51 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 29 Jan 2021 19:58:51 GMT Subject: RFR: JDK-8260669: Missing quotes in fixpath.sh Message-ID: <4-cyXPxFDHjxp5CY-uXviREsB-ArfHkhvy5CBVUoxL0=.5a670b2c-633e-4af3-9411-747e6c09334f@github.com> The build on Windows can fail if certain directory names are present in root directory of the workspace. In particular I've observed that the single letter 'p' is triggering this problem. This is caused by missing quotes around [:upper:] in a 'tr' call in fixpath.sh. ------------- Commit messages: - Fix quoting of tr args Changes: https://git.openjdk.java.net/jdk/pull/2318/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2318&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260669 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2318.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2318/head:pull/2318 PR: https://git.openjdk.java.net/jdk/pull/2318 From prr at openjdk.java.net Fri Jan 29 21:19:48 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Jan 2021 21:19:48 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v2] In-Reply-To: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com> References: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com> Message-ID: <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com> On Fri, 29 Jan 2021 14:57:56 GMT, Weijun Wang wrote: >> This fix covers both >> >> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) >> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > same behavior as before -- empty realm map make/modules/java.security.jgss/Lib.gmk line 84: > 82: $(call SET_SHARED_LIBRARY_ORIGIN), \ > 83: LIBS := -framework Cocoa -framework SystemConfiguration \ > 84: -framework Kerberos -ljava, \ The need to add -ljava is interesting. It implies we were getting something from the platform that usually we'd expect to come from the JDK itself ?? src/java.base/macosx/classes/apple/security/KeychainStore.java line 820: > 818: private void createKeyEntry(String alias, long creationDate, long secKeyRef, > 819: long[] secCertificateRefs, byte[][] rawCertData) { > 820: KeyEntry ke = new KeyEntry(); removing these exceptions is presumably just clean up - not directly related ?? src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 28: > 26: #import "apple_security_KeychainStore.h" > 27: #include "jni.h" > 28: #include "jni_util.h" jni_util.h includes jni.h so I don't understand the need for this change. Also why did you change import to include ? import is the Obj-C norm ... src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 619: > 617: (*env)->ReleaseCharArrayElements(env, passwordObj, passwordChars, > 618: JNI_ABORT); > 619: } Although you have it in the later code, here you are missing @catch (NSException *e) { NSLog(@"%@", [e callStackSymbols]); } src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 41: > 39: if ([keys count] == 0) return; > 40: if (![keys containsObject:KERBEROS_DEFAULT_REALMS] && ![keys containsObject:KERBEROS_DEFAULT_REALM_MAPPINGS]) return; > 41: // JNFPerformEnvBlock(JNFThreadDetachOnThreadDeath | JNFThreadSetSystemClassLoaderOnAttach | JNFThreadAttachAsDaemon, ^(JNIEnv *env) { remove commented out code src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 57: > 55: } > 56: } > 57: (*localVM)->DetachCurrentThread(localVM); I think you only want to detach if you actually attached ! you don't want to be detaching VM threads. ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From asemenyuk at openjdk.java.net Fri Jan 29 21:51:17 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 29 Jan 2021 21:51:17 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS Message-ID: Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. Layout of jpackage's native code changed: - `common`: code shared between all jpackage binaries. - `applauncher`: launcher only code. - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. ------------- Commit messages: - 8254702: jpackage app launcher crashes on CentOS - 8254702: jpackage app launcher crashes on CentOS - 8254702: jpackage app launcher crashes on CentOS - 8254702: jpackage app launcher crashes on CentOS - 8254702: jpackage app launcher crashes on CentOS - 8254702: jpackage app launcher crashes on CentOS - It works! - 8254702: jpackage app launcher crashes on CentOS - strerror bugfix - Add helper makefile to build jpackage native code only - ... and 1 more: https://git.openjdk.java.net/jdk/compare/20e7df50...14d277a2 Changes: https://git.openjdk.java.net/jdk/pull/2320/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254702 Stats: 1823 lines in 24 files changed: 1376 ins; 420 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/2320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2320/head:pull/2320 PR: https://git.openjdk.java.net/jdk/pull/2320 From asemenyuk at openjdk.java.net Fri Jan 29 21:51:17 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 29 Jan 2021 21:51:17 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 21:33:40 GMT, Alexey Semenyuk wrote: > Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 > > The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. > At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). > App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. > > Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. > > Layout of jpackage's native code changed: > - `common`: code shared between all jpackage binaries. > - `applauncher`: launcher only code. > - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. > - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. make/modules/jdk.jpackage/applauncherlib.ld-version-script line 1: > 1: { Linker script is "just in case" to guarantee that only controlled set of functions is exported from launcher lib. Current set of g++ OpenJDK command line options disables export of functions with external linkage by default. However in my local builds this was not the case and the whole C++ runtime statically linked in launcher lib got exported. This prevented it from unloading from launcher's process memory when it was `dlclose()`-ed. This linker script used in linkage of launcher lib will guarantee this will not happen. src/jdk.jpackage/share/native/common/tstrings.cpp line 55: > 53: ret = _vsntprintf_s(&*fmtout.begin(), fmtout.size(), _TRUNCATE, format, args); > 54: #else > 55: #if defined(__GNUC__) && __GNUC__ >= 5 Local build with older g++compiler bugfix. ------------- PR: https://git.openjdk.java.net/jdk/pull/2320 From weijun at openjdk.java.net Fri Jan 29 21:54:45 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 21:54:45 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v2] In-Reply-To: <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com> References: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com> <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com> Message-ID: On Fri, 29 Jan 2021 20:51:04 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> same behavior as before -- empty realm map > > make/modules/java.security.jgss/Lib.gmk line 84: > >> 82: $(call SET_SHARED_LIBRARY_ORIGIN), \ >> 83: LIBS := -framework Cocoa -framework SystemConfiguration \ >> 84: -framework Kerberos -ljava, \ > > The need to add -ljava is interesting. It implies we were getting something from the platform that usually we'd expect to come from the JDK itself ?? I tried removing it and the build runs fine. But I remember I have seen some error before. > src/java.base/macosx/classes/apple/security/KeychainStore.java line 820: > >> 818: private void createKeyEntry(String alias, long creationDate, long secKeyRef, >> 819: long[] secCertificateRefs, byte[][] rawCertData) { >> 820: KeyEntry ke = new KeyEntry(); > > removing these exceptions is presumably just clean up - not directly related ?? Yes. > src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 28: > >> 26: #import "apple_security_KeychainStore.h" >> 27: #include "jni.h" >> 28: #include "jni_util.h" > > jni_util.h includes jni.h so I don't understand the need for this change. > Also why did you change import to include ? import is the Obj-C norm ... Will fix. > src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 619: > >> 617: (*env)->ReleaseCharArrayElements(env, passwordObj, passwordChars, >> 618: JNI_ABORT); >> 619: } > > Although you have it in the later code, here you are missing > @catch (NSException *e) { > NSLog(@"%@", [e callStackSymbols]); > } Will add. BTW, will these be shown on stdout or stderr? If so, is this a good idea? > src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 57: > >> 55: } >> 56: } >> 57: (*localVM)->DetachCurrentThread(localVM); > > I think you only want to detach if you actually attached ! you don't want to be detaching VM threads. So I should remember how env was retrieved and only detach when it's from `AttachCurrentThreadAsDaemon`? In fact, in my test the plain `GetEnv` has never succeeded and it was always attached. ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From prr at openjdk.java.net Fri Jan 29 22:03:42 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Jan 2021 22:03:42 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 21:33:40 GMT, Alexey Semenyuk wrote: > Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 > > The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. > At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). > App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. > > Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. > > Layout of jpackage's native code changed: > - `common`: code shared between all jpackage binaries. > - `applauncher`: launcher only code. > - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. > - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. So after this change if you bundle and run an app on Linux and then do "ps" .. what is shown to be running ? Java or the app-name you expected ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2320 From prr at openjdk.java.net Fri Jan 29 22:08:40 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 29 Jan 2021 22:08:40 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v2] In-Reply-To: References: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com> <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com> Message-ID: On Fri, 29 Jan 2021 21:47:32 GMT, Weijun Wang wrote: >> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 619: >> >>> 617: (*env)->ReleaseCharArrayElements(env, passwordObj, passwordChars, >>> 618: JNI_ABORT); >>> 619: } >> >> Although you have it in the later code, here you are missing >> @catch (NSException *e) { >> NSLog(@"%@", [e callStackSymbols]); >> } > > Will add. > > BTW, will these be shown on stdout or stderr? If so, is this a good idea? should be stderr. Whether to log is up to you. You could wrap it in something that checks for a debug build. The idea is that if this ever happens there is a serious problem. NSException is only thrown (by the OS frameworks) in supposedly fatal scenarios. >> src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m line 57: >> >>> 55: } >>> 56: } >>> 57: (*localVM)->DetachCurrentThread(localVM); >> >> I think you only want to detach if you actually attached ! you don't want to be detaching VM threads. > > So I should remember how env was retrieved and only detach when it's from `AttachCurrentThreadAsDaemon`? In fact, in my test the plain `GetEnv` has never succeeded and it was always attached. Yes that is the idea. BTW which thread was it attached to in what you saw ? ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From asemenyuk at openjdk.java.net Fri Jan 29 22:20:41 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 29 Jan 2021 22:20:41 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 22:00:32 GMT, Phil Race wrote: >> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 >> >> The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. >> At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). >> App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. >> >> Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. >> >> Layout of jpackage's native code changed: >> - `common`: code shared between all jpackage binaries. >> - `applauncher`: launcher only code. >> - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. >> - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. > > So after this change if you bundle and run an app on Linux and then do "ps" .. what is shown to be running ? Java or the app-name you expected ? "ps" will show app-name. It was never Java for jpackage apps before this patch and this patch doesn't change it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2320 From tbell at openjdk.java.net Fri Jan 29 22:34:41 2021 From: tbell at openjdk.java.net (Tim Bell) Date: Fri, 29 Jan 2021 22:34:41 GMT Subject: RFR: JDK-8260669: Missing quotes in fixpath.sh In-Reply-To: <4-cyXPxFDHjxp5CY-uXviREsB-ArfHkhvy5CBVUoxL0=.5a670b2c-633e-4af3-9411-747e6c09334f@github.com> References: <4-cyXPxFDHjxp5CY-uXviREsB-ArfHkhvy5CBVUoxL0=.5a670b2c-633e-4af3-9411-747e6c09334f@github.com> Message-ID: <9m9CKunTQl53L36ispNfpZK560s3HWLb4WU3Wzxs_cY=.9be673f4-bd03-47ca-9bb9-2ab8ecad93b2@github.com> On Fri, 29 Jan 2021 19:54:12 GMT, Erik Joelsson wrote: > The build on Windows can fail if certain directory names are present in root directory of the workspace. In particular I've observed that the single letter 'p' is triggering this problem. This is caused by missing quotes around [:upper:] in a 'tr' call in fixpath.sh. Looks good. ------------- Marked as reviewed by tbell (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2318 From weijun at openjdk.java.net Fri Jan 29 22:38:39 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 22:38:39 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v2] In-Reply-To: References: <-F0tHX1FDgcp-8kRi-EkcpfLHdDnEGtGxtPckeBkU4A=.7228511d-529c-4b52-8733-0e4bdaf0c789@github.com> <06TlDaeAfh41fK0rXHZkVqHJFccZuhTH6WX-VGihKH8=.67aa28d4-9576-4b68-a128-2015fb262c55@github.com> Message-ID: On Fri, 29 Jan 2021 22:05:21 GMT, Phil Race wrote: >> So I should remember how env was retrieved and only detach when it's from `AttachCurrentThreadAsDaemon`? In fact, in my test the plain `GetEnv` has never succeeded and it was always attached. > > Yes that is the idea. BTW which thread was it attached to in what you saw ? It's a new thread in the main group. After the method finishes, the thread exits (`Thread::exit`). ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From iris at openjdk.java.net Fri Jan 29 22:45:46 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 29 Jan 2021 22:45:46 GMT Subject: RFR: JDK-8260669: Missing quotes in fixpath.sh In-Reply-To: <4-cyXPxFDHjxp5CY-uXviREsB-ArfHkhvy5CBVUoxL0=.5a670b2c-633e-4af3-9411-747e6c09334f@github.com> References: <4-cyXPxFDHjxp5CY-uXviREsB-ArfHkhvy5CBVUoxL0=.5a670b2c-633e-4af3-9411-747e6c09334f@github.com> Message-ID: On Fri, 29 Jan 2021 19:54:12 GMT, Erik Joelsson wrote: > The build on Windows can fail if certain directory names are present in root directory of the workspace. In particular I've observed that the single letter 'p' is triggering this problem. This is caused by missing quotes around [:upper:] in a 'tr' call in fixpath.sh. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2318 From weijun at openjdk.java.net Fri Jan 29 22:47:52 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Jan 2021 22:47:52 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v3] In-Reply-To: References: Message-ID: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: phil comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1845/files - new: https://git.openjdk.java.net/jdk/pull/1845/files/b0ee18a8..ba3d1a1f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=01-02 Stats: 14 lines in 3 files changed: 7 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From asemenyuk at openjdk.java.net Fri Jan 29 23:06:20 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 29 Jan 2021 23:06:20 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v2] In-Reply-To: References: Message-ID: > Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 > > The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. > At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). > App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. > > Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. > > Layout of jpackage's native code changed: > - `common`: code shared between all jpackage binaries. > - `applauncher`: launcher only code. > - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. > - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. Alexey Semenyuk 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 one new commit since the last revision: 8254702: jpackage app launcher crashes on CentOS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2320/files - new: https://git.openjdk.java.net/jdk/pull/2320/files/14d277a2..b493bcfd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2320/head:pull/2320 PR: https://git.openjdk.java.net/jdk/pull/2320 From mikael at openjdk.java.net Sat Jan 30 00:02:40 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Sat, 30 Jan 2021 00:02:40 GMT Subject: RFR: JDK-8260669: Missing quotes in fixpath.sh In-Reply-To: <4-cyXPxFDHjxp5CY-uXviREsB-ArfHkhvy5CBVUoxL0=.5a670b2c-633e-4af3-9411-747e6c09334f@github.com> References: <4-cyXPxFDHjxp5CY-uXviREsB-ArfHkhvy5CBVUoxL0=.5a670b2c-633e-4af3-9411-747e6c09334f@github.com> Message-ID: On Fri, 29 Jan 2021 19:54:12 GMT, Erik Joelsson wrote: > The build on Windows can fail if certain directory names are present in root directory of the workspace. In particular I've observed that the single letter 'p' is triggering this problem. This is caused by missing quotes around [:upper:] in a 'tr' call in fixpath.sh. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2318 From prr at openjdk.java.net Sat Jan 30 00:09:44 2021 From: prr at openjdk.java.net (Phil Race) Date: Sat, 30 Jan 2021 00:09:44 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v3] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 22:47:52 GMT, Weijun Wang wrote: >> This fix covers both >> >> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) >> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > phil comment Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From almatvee at openjdk.java.net Sat Jan 30 02:36:44 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 30 Jan 2021 02:36:44 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v2] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 23:06:20 GMT, Alexey Semenyuk wrote: >> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 >> >> The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. >> At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). >> App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. >> >> Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. >> >> Layout of jpackage's native code changed: >> - `common`: code shared between all jpackage binaries. >> - `applauncher`: launcher only code. >> - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. >> - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. > > Alexey Semenyuk 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. Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2320 From weijun at openjdk.java.net Sat Jan 30 15:23:09 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 30 Jan 2021 15:23:09 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v4] In-Reply-To: References: Message-ID: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: end values should be vectors ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1845/files - new: https://git.openjdk.java.net/jdk/pull/1845/files/ba3d1a1f..a0cad8fd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=02-03 Stats: 12 lines in 1 file changed: 8 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Sat Jan 30 18:07:22 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 30 Jan 2021 18:07:22 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v5] In-Reply-To: References: Message-ID: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: a test only in patch2: unchanged: ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1845/files - new: https://git.openjdk.java.net/jdk/pull/1845/files/a0cad8fd..38616b32 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=03-04 Stats: 200 lines in 3 files changed: 199 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Sat Jan 30 18:07:23 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 30 Jan 2021 18:07:23 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v3] In-Reply-To: References: Message-ID: On Sat, 30 Jan 2021 00:06:51 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> phil comment > > Marked as reviewed by prr (Reviewer). Added a test. Unfortunately it has to be `manual` because updating the dynamic store needs `sudo` privilege. ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From prr at openjdk.java.net Sat Jan 30 18:11:41 2021 From: prr at openjdk.java.net (Phil Race) Date: Sat, 30 Jan 2021 18:11:41 GMT Subject: RFR: 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 17:22:49 GMT, Phil Race wrote: >> Build changes look good. > >> Is it because they are not in a place that can be accessed from this file? > Right 99% of JNF usage was the desktop module many, many files, 1300 references .. the entire rest of the JDK had just 3 files each in a different module ! It did not seem worth creating a JDK-wide platform-specific library to support this. > For testing you want test/jdk/sun/tools/jhsdb/ and test/hotspot/jtreg/serviceability/sa These tests passed with my changes ------------- PR: https://git.openjdk.java.net/jdk/pull/2304 From weijun at openjdk.java.net Sun Jan 31 18:45:19 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 31 Jan 2021 18:45:19 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v6] In-Reply-To: References: Message-ID: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: - move test - Merge branch 'master' into 8257858 - a test only in patch2: unchanged: - end values should be vectors - phil comment - same behavior as before -- empty realm map - error check, new JavaStringToNSString - do not find class and method in loop - no more header file reverted: - better macro, no more JNI_COCOA_ENTER - ... and 5 more: https://git.openjdk.java.net/jdk/compare/bb728c47...ef337f12 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1845/files - new: https://git.openjdk.java.net/jdk/pull/1845/files/38616b32..ef337f12 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=04-05 Stats: 33763 lines in 708 files changed: 13479 ins; 10043 del; 10241 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From akozlov at openjdk.java.net Sun Jan 31 20:14:01 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Sun, 31 Jan 2021 20:14:01 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits: - Merge branch 'master' into jdk-macos - Update copyright year for BsdAARCH64ThreadContext.java - Fix inclusing of StubRoutines header - Redo buildsys fix - Revert harfbuzz changes, disable warnings for it - Little adjustement of SlowSignatureHandler - Partially bring previous commit - Revert "Address feedback for signature generators" This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d. - Refactor CDS disabling - Redo builsys support for aarch64-darwin - ... and 52 more: https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=07 Stats: 3266 lines in 114 files changed: 3164 ins; 41 del; 61 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Sun Jan 31 20:14:02 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Sun, 31 Jan 2021 20:14:02 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com> On Mon, 25 Jan 2021 09:48:46 GMT, Andrew Haley wrote: >> Would you like me to do something about it now? The problem is that the functions of SlowSignatureHandler are subtly different, so it will be multiple tables, not sure how many. Such change is another candidate for a separate code enhancement, which I would like not to mix into the JEP implementation (it's already not a small change :)). But if you think it would be a good thing, please let me know. In another case, I'll add this to a queue of follow-up enhancements. > > I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline. Hello Does this look like something in the right direction ? https://github.com/VladimirKempik/jdk/commit/c2820734f4b10148154085a70d380b8c5775fa49 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200