From kbarrett at openjdk.java.net Fri Jan 1 09:44:18 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 1 Jan 2021 09:44:18 GMT Subject: RFR: 8258810: Improve enum traits [v2] In-Reply-To: References: Message-ID: > Please review these miscellaneous improvements to the enum iteration facility. > Thanks to @albertnetymk for discussions. > > (1) Removed some unneeded stuff from EnumIterationTraits. > > (2) Various similar bits of error checking code are unified and shared via > EnumIterationTraits. > > (3) Casts between the enum type and the underlying type are now done using > helper functions in EnumIterationTraits. > > (4) JDK-8257466 added accessors for the EnumRange bounds and the index for > an enumerator, but didn't account for the possibility of an empty subrange. > Add assertions for that case. > > (5) Added some death tests to verify some of the error checking. > > Testing: > mach5 tier1 Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: ayang review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1868/files - new: https://git.openjdk.java.net/jdk/pull/1868/files/cb889e87..a4667b70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1868&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1868&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1868/head:pull/1868 PR: https://git.openjdk.java.net/jdk/pull/1868 From kim.barrett at oracle.com Fri Jan 1 09:46:38 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Jan 2021 04:46:38 -0500 Subject: RFR: 8258810: Improve enum traits In-Reply-To: <5wNonxnCzpbxmF-Eb4DZ7E89L0BeqZXPb66Rw_PZvDo=.5d397ee6-fa8f-4860-add7-dada8f713063@github.com> References: <5wNonxnCzpbxmF-Eb4DZ7E89L0BeqZXPb66Rw_PZvDo=.5d397ee6-fa8f-4860-add7-dada8f713063@github.com> Message-ID: <842DF952-AF4F-487C-A699-D069FEAA3CA5@oracle.com> > On Dec 24, 2020, at 3:46 PM, Albert Mingkun Yang wrote: > > On Tue, 22 Dec 2020 18:45:31 GMT, Kim Barrett wrote: > >> Please review these miscellaneous improvements to the enum iteration facility. >> Thanks to @albertnetymk for discussions. >> [?] > > I think `assert(size() > 0)` is more consistent with preceding documentation than `assert_not_empty()` in `first()` and `last()`. Very subjective though; up to you. I changed assert_not_empty to use `size() > 0`. The old implementation was equivalent in context, but not immediately obviously so. `assert_not_empty` just gives a meaningful name to the condition, and avoids a bit of code repetition. 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 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 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 redestad at openjdk.java.net Mon Jan 4 11:54:38 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 4 Jan 2021 11:54:38 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v12] In-Reply-To: References: Message-ID: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Claes Redestad 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 30 additional commits since the last revision: - PPC updates courtesy of @TheRealMDoerr - Merge branch 'master' into log2_template - Merge branch 'master' into log2_template - Remove use of make_unsigned, use UINT64_FORMAT_X to make sign extension stand out - With JDK-8257985 fixed, use count_trailing_zeros to implement log2i_exact - Merge branch 'master' into log2_template - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template - More review comments adressed - Issue with using count_trailing_zeros with 64-bit values on 32-bit, revert and add TODO - Merge branch 'master' into log2_template - ... and 20 more: https://git.openjdk.java.net/jdk/compare/639d328c...14a903a1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1663/files - new: https://git.openjdk.java.net/jdk/pull/1663/files/e21e1b7a..14a903a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=10-11 Stats: 23505 lines in 980 files changed: 13975 ins; 6182 del; 3348 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 From redestad at openjdk.java.net Mon Jan 4 13:38:58 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 4 Jan 2021 13:38:58 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v11] In-Reply-To: <9D4pRJcX5SOTHeBxQmxM23cQYrggeIyrflF-8bemMZs=.a3458e8c-f5d0-48bb-bbdc-ee2e625d7cf8@github.com> References: <69k8Moh5KhGkjiymiWIupvM_BgMfCE5Vz6sNSMz6Mb0=.b17954a6-0130-4e3e-bccb-ceff35213867@github.com> <9D4pRJcX5SOTHeBxQmxM23cQYrggeIyrflF-8bemMZs=.a3458e8c-f5d0-48bb-bbdc-ee2e625d7cf8@github.com> Message-ID: On Thu, 17 Dec 2020 12:09:50 GMT, Martin Doerr wrote: >>> Hi Claes, >>> I noticed that you're using `log2i_exact` in ppc.ad. That's wrong, we're hitting assertions because it's not used for exact powers of 2. Please change to `log2i`. I'll test with that change. >> >> To have the same semantics as before I guess `log2i_graceful` is the better fit. I picked `log2i_exact` since the variable names suggested they were powers of two. > > You're right, looks like `log2i_exact` should be used and only braces are wrong. I'll try to fix it and get back to you. Thanks for your patience. I've merged in a patch to ppc.ad from @TheRealMDoerr that has passed testing on PPC. I'm running a few tiers of testing now with the intent of pushing this later tonight. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From coleenp at openjdk.java.net Mon Jan 4 17:43:19 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 4 Jan 2021 17:43:19 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock Message-ID: See CR for details. I made the classpath append list lock-free. Calling experts in Atomic operations... Tested with tier1-6. Thanks, Coleen ------------- Commit messages: - 8259067: bootclasspath append takes out object lock Changes: https://git.openjdk.java.net/jdk/pull/1935/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1935&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259067 Stats: 48 lines in 4 files changed: 20 ins; 7 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1935.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1935/head:pull/1935 PR: https://git.openjdk.java.net/jdk/pull/1935 From iklam at openjdk.java.net Mon Jan 4 17:47:25 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 4 Jan 2021 17:47:25 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp [v2] In-Reply-To: References: Message-ID: <1ag_sNd7DDMPNv9uHW0HawBjASZHTRyPxGK-ekO-JXM=.eff714de-c409-4048-84c4-f817344f767a@github.com> > Currently, [globals.hpp](https://github.com/openjdk/jdk/blob/17ace8339dd8235f3811e3975d9ccc77910b0c77/src/hotspot/share/runtime/globals.hpp#L29) is including gc_globals.hpp. This exposes all the GC command-line flags to almost all cpp files. However, only about 1/3 of the cpp files would require gc_globals.hpp. > > This RFE improves modularity and HotSpot build time. > > **Review notes:** > - Please start with globals.hpp, gc_globals.hpp. > - Flags related to TLAB are frequently used by other header files. I moved these flags to a new header tlab_globals.hpp. > - Some tweaking of oop.hpp to avoid including gc_globals.hpp in this popular header file. (Otherwise gc_globals.hpp would be included by everyone). > - The other changes are just files that use GC flags. They should have included gc_globals.hpp but didn't. > > **Testing:** > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam 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 five additional commits since the last revision: - fixed copyright year - Merge branch 'master' into 8258459-decouple-gc-globals-hpp-from-globals-hpp - comments by coleenp - fixed copyright year - 8258459: Decouple gc_globals.hpp from globals.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1797/files - new: https://git.openjdk.java.net/jdk/pull/1797/files/df618db6..ec8a3902 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=00-01 Stats: 17381 lines in 942 files changed: 9715 ins; 4698 del; 2968 mod Patch: https://git.openjdk.java.net/jdk/pull/1797.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1797/head:pull/1797 PR: https://git.openjdk.java.net/jdk/pull/1797 From iklam at openjdk.java.net Mon Jan 4 18:00:59 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 4 Jan 2021 18:00:59 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp [v2] In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 13:08:23 GMT, Coleen Phillimore wrote: >> Ioi Lam 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 five additional commits since the last revision: >> >> - fixed copyright year >> - Merge branch 'master' into 8258459-decouple-gc-globals-hpp-from-globals-hpp >> - comments by coleenp >> - fixed copyright year >> - 8258459: Decouple gc_globals.hpp from globals.hpp > > src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp line 61: > >> 59: } >> 60: >> 61: size_t ThreadLocalAllocBuffer::initial_refill_waste_limit() { return desired_size() / TLABRefillWasteFraction; } > > nit: please line this up. Fixed > src/hotspot/share/oops/oop.inline.hpp line 187: > >> 185: // disjunct below to fail if the two comparands are computed across such >> 186: // a concurrent change. >> 187: assert((s == klass->oop_size(this)) || > > It might be nicer to throw the second half of this assert into the .cpp file, like > assert(s == klass->oop_size(this) || gc_has_forwarded(), "wrong array object size"); > With the special comment above it in the cpp file. Then someone has the potential to add more information if the assert fails, and that gets Universe::hpp out of the inline file (if that helps with future cleanups). I'd like to keep this PR minimal. If I change `(Universe::heap()->is_gc_active() && is_objArray() && is_forwarded() && (get_UseParallelGC() || get_UseG1GC())` to `gc_has_forwarded()`, I would also need to move the comments about `UseParallelGC and UseG1GC can change the length field of an "old copy"...`. I think that should be done in a separate PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1797 From zgu at openjdk.java.net Mon Jan 4 18:48:56 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 4 Jan 2021 18:48:56 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 17:28:30 GMT, Coleen Phillimore wrote: > See CR for details. > I made the classpath append list lock-free. Calling experts in Atomic operations... > Tested with tier1-6. > Thanks, > Coleen src/hotspot/share/classfile/classLoader.cpp line 843: > 841: assert(first_append_entry() == NULL, "boot loader's append class path entry list not empty"); > 842: Atomic::store(&_first_append_entry_list, new_entry); > 843: return; Not sure if it is a problem. There is a chance that an entry is added, e.g. _last_append_entry = new_entry, but _first_append_entry_list == NULL. If contains_append_entry() queries on this new entry, it may return false. ------------- PR: https://git.openjdk.java.net/jdk/pull/1935 From coleenp at openjdk.java.net Mon Jan 4 18:52:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 4 Jan 2021 18:52:57 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 17:28:30 GMT, Coleen Phillimore wrote: > See CR for details. > I made the classpath append list lock-free. Calling experts in Atomic operations... > Tested with tier1-6. > Thanks, > Coleen For the record, these tests exercise this code: vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch007,8,9,10. ------------- PR: https://git.openjdk.java.net/jdk/pull/1935 From coleenp at openjdk.java.net Mon Jan 4 19:01:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 4 Jan 2021 19:01:56 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock In-Reply-To: References: Message-ID: <8lsgDz1LIHir0vFVVZ3qJIQmL8P1F2Yuqy4YLsRDlGc=.fe8910ea-5932-47be-b4bf-025f2d3df9ba@github.com> On Mon, 4 Jan 2021 18:45:54 GMT, Zhengyu Gu wrote: >> See CR for details. >> I made the classpath append list lock-free. Calling experts in Atomic operations... >> Tested with tier1-6. >> Thanks, >> Coleen > > src/hotspot/share/classfile/classLoader.cpp line 843: > >> 841: assert(first_append_entry() == NULL, "boot loader's append class path entry list not empty"); >> 842: Atomic::store(&_first_append_entry_list, new_entry); >> 843: return; > > Not sure if it is a problem. There is a chance that an entry is added, e.g. _last_append_entry = new_entry, but _first_append_entry_list == NULL. If contains_append_entry() queries on this new entry, it may return false. That race also exists in the current code, since contains_append_entry() never acquired the same lock. Even if it did, there's a race when one thread adds an entry and the other reads the list. ------------- PR: https://git.openjdk.java.net/jdk/pull/1935 From lfoltan at openjdk.java.net Mon Jan 4 19:25:53 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Mon, 4 Jan 2021 19:25:53 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 17:28:30 GMT, Coleen Phillimore wrote: > See CR for details. > I made the classpath append list lock-free. Calling experts in Atomic operations... > Tested with tier1-6. > Thanks, > Coleen LGTM. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1935 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 coleenp at openjdk.java.net Mon Jan 4 19:36:54 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 4 Jan 2021 19:36:54 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock In-Reply-To: <8lsgDz1LIHir0vFVVZ3qJIQmL8P1F2Yuqy4YLsRDlGc=.fe8910ea-5932-47be-b4bf-025f2d3df9ba@github.com> References: <8lsgDz1LIHir0vFVVZ3qJIQmL8P1F2Yuqy4YLsRDlGc=.fe8910ea-5932-47be-b4bf-025f2d3df9ba@github.com> Message-ID: <8U4aBGWj-t1OWsobT_py44ELnMTulbiG0XEYCiPrMpo=.798d1bea-67bc-41a6-90e5-43e56043cf0f@github.com> On Mon, 4 Jan 2021 18:59:09 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/classLoader.cpp line 843: >> >>> 841: assert(first_append_entry() == NULL, "boot loader's append class path entry list not empty"); >>> 842: Atomic::store(&_first_append_entry_list, new_entry); >>> 843: return; >> >> Not sure if it is a problem. There is a chance that an entry is added, e.g. _last_append_entry = new_entry, but _first_append_entry_list == NULL. If contains_append_entry() queries on this new entry, it may return false. > > That race also exists in the current code, since contains_append_entry() never acquired the same lock. Even if it did lock, there's a race when one thread adds an entry and the other reads the list. void InstanceKlass::log_to_classlist(const ClassFileStream* stream) const { if (ClassListWriter::is_enabled()) { ... if (class_loader == NULL && ClassLoader::contains_append_entry(stream->source())) { // .. but don't skip the boot classes that are loaded from -Xbootclasspath/a // as they can be loaded from the archive during runtime. in logging loaded classes from the NULL class loader, this is where contains_append_entry() races with a JVMTI thread concurrently adding a class path entry, but this is benign because it's logging a class that's already loaded, so it couldn't have loaded it from the partially added classpath. ------------- PR: https://git.openjdk.java.net/jdk/pull/1935 From redestad at openjdk.java.net Mon Jan 4 21:26:58 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 4 Jan 2021 21:26:58 GMT Subject: Integrated: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 12:00:48 GMT, Claes Redestad wrote: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) This pull request has now been integrated. Changeset: 9d160aa1 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/9d160aa1 Stats: 283 lines in 41 files changed: 75 ins; 101 del; 107 mod 8257815: Replace global log2 functions with efficient implementations Reviewed-by: kbarrett, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From coleenp at openjdk.java.net Mon Jan 4 22:38:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 4 Jan 2021 22:38:08 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 19:23:19 GMT, Lois Foltan wrote: >> See CR for details. >> I made the classpath append list lock-free. Calling experts in Atomic operations... >> Tested with tier1-6. >> Thanks, >> Coleen > > LGTM. > Lois Thanks, Lois! ------------- PR: https://git.openjdk.java.net/jdk/pull/1935 From iklam at openjdk.java.net Tue Jan 5 00:20:15 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 00:20:15 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp [v3] In-Reply-To: References: Message-ID: > Currently, [globals.hpp](https://github.com/openjdk/jdk/blob/17ace8339dd8235f3811e3975d9ccc77910b0c77/src/hotspot/share/runtime/globals.hpp#L29) is including gc_globals.hpp. This exposes all the GC command-line flags to almost all cpp files. However, only about 1/3 of the cpp files would require gc_globals.hpp. > > This RFE improves modularity and HotSpot build time. > > **Review notes:** > - Please start with globals.hpp, gc_globals.hpp. > - Flags related to TLAB are frequently used by other header files. I moved these flags to a new header tlab_globals.hpp. > - Some tweaking of oop.hpp to avoid including gc_globals.hpp in this popular header file. (Otherwise gc_globals.hpp would be included by everyone). > - The other changes are just files that use GC flags. They should have included gc_globals.hpp but didn't. > > **Testing:** > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: added tlab_globals.hpp to all files that use the TLAB globals ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1797/files - new: https://git.openjdk.java.net/jdk/pull/1797/files/ec8a3902..372fd801 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=01-02 Stats: 60 lines in 31 files changed: 32 ins; 7 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1797.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1797/head:pull/1797 PR: https://git.openjdk.java.net/jdk/pull/1797 From sspitsyn at openjdk.java.net Tue Jan 5 02:06:58 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 5 Jan 2021 02:06:58 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 17:28:30 GMT, Coleen Phillimore wrote: > See CR for details. > I made the classpath append list lock-free. Calling experts in Atomic operations... > Tested with tier1-6. > Thanks, > Coleen Hi Coleen, LGTM++ Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1935 From njian at openjdk.java.net Tue Jan 5 02:57:15 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 5 Jan 2021 02:57:15 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v2] In-Reply-To: References: Message-ID: <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com> > After applying [1], some Vector API tests fail with SIGILL on SVE > system. The SIGILL was triggered by verify_ptrue before c2 compiled > function returns, which means that the preserved p7 register (as ptrue) > has been clobbered before returning to c2 compiled code. (p7 is not > preserved cross function calls, and system calls [2]). > > Currently we try to reinitialize ptrue at each entrypoint of returning > from non-c2 compiled code, which indicating possible C or system calls. > However, there's still one entrypoint missing, exception handling, as > we may jump to c2 compiled code for exception handler. See > OptoRuntime::generate_exception_blob(). > > Adding reinitialize_ptrue before jumping back to c2 compiled code in > generate_exception_blob() could solve those Vector API test failures. > Actually I had that in my initial test patch [3], I don't know why I > missed that in final patch... I reran tests with the same approach of > [3] and found that there's still something missing, the > nmethod_entry_barrier() in c2 function prolog. The barrier may call to > runtime code (see generate_method_entry_barrier()). To reduce the risk > of missing such reinitialize_ptrue in newly added code in future, I > think it would be better to do the reinitialize in > pop_call_clobbered_registers(). > > P.S. the SIGILL message is also not clear, it should print detailed > message as indicated by MacroAssembler::stop() call. This is caused by > JDK-8255711 removing the message printing code. This patch also adds it > back, so that it could print detailed message for abort. > > Tested with tier1-3 on SVE hardware. Also verified with the same > approach of patch [3] with jtreg tests hotspot_all_no_apps and > jdk:tier1-3 passed without incorrect ptrue value assertion failure. > > [1] https://github.com/openjdk/jdk/pull/1621 > [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst > [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: Update copyright year to 2021. ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/50/files - new: https://git.openjdk.java.net/jdk16/pull/50/files/a5754c7d..873c2506 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=50&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=50&range=00-01 Stats: 12 lines in 7 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk16/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/50/head:pull/50 PR: https://git.openjdk.java.net/jdk16/pull/50 From dongbo at openjdk.java.net Tue Jan 5 03:43:15 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 5 Jan 2021 03:43:15 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v2] In-Reply-To: References: Message-ID: > This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. > > Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. > Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. > > Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. > Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op > VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op > VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op > VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op > > # Kunpeng 916, with fmaxp/fminp > VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% > VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op > VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% > VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: rebase the .m4 entry ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1925/files - new: https://git.openjdk.java.net/jdk/pull/1925/files/71048b82..876939b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=00-01 Stats: 16 lines in 1 file changed: 2 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1925/head:pull/1925 PR: https://git.openjdk.java.net/jdk/pull/1925 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 coleenp at openjdk.java.net Tue Jan 5 04:22:09 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 5 Jan 2021 04:22:09 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v2] In-Reply-To: References: Message-ID: > See CR for details. > I made the classpath append list lock-free. Calling experts in Atomic operations... > Tested with tier1-6. > Thanks, > Coleen Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Simplify with a Mutex. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1935/files - new: https://git.openjdk.java.net/jdk/pull/1935/files/f132d7bd..fb8e87d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1935&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1935&range=00-01 Stats: 29 lines in 5 files changed: 6 ins; 12 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1935.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1935/head:pull/1935 PR: https://git.openjdk.java.net/jdk/pull/1935 From coleenp at openjdk.java.net Tue Jan 5 04:22:09 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 5 Jan 2021 04:22:09 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 02:03:42 GMT, Serguei Spitsyn wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify with a Mutex. > > Hi Coleen, > > LGTM++ > > Thanks, > Serguei Thanks Serguei. Ioi convinced me offline to simplify and just use a mutex, so I updated the patch to do that. I tested with jdi and jvmti tests and will rerun tier1-3. ------------- PR: https://git.openjdk.java.net/jdk/pull/1935 From njian at openjdk.java.net Tue Jan 5 05:46:59 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 5 Jan 2021 05:46:59 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 07:11:11 GMT, Ningsheng Jian wrote: > After applying [1], some Vector API tests fail with SIGILL on SVE > system. The SIGILL was triggered by verify_ptrue before c2 compiled > function returns, which means that the preserved p7 register (as ptrue) > has been clobbered before returning to c2 compiled code. (p7 is not > preserved cross function calls, and system calls [2]). > > Currently we try to reinitialize ptrue at each entrypoint of returning > from non-c2 compiled code, which indicating possible C or system calls. > However, there's still one entrypoint missing, exception handling, as > we may jump to c2 compiled code for exception handler. See > OptoRuntime::generate_exception_blob(). > > Adding reinitialize_ptrue before jumping back to c2 compiled code in > generate_exception_blob() could solve those Vector API test failures. > Actually I had that in my initial test patch [3], I don't know why I > missed that in final patch... I reran tests with the same approach of > [3] and found that there's still something missing, the > nmethod_entry_barrier() in c2 function prolog. The barrier may call to > runtime code (see generate_method_entry_barrier()). To reduce the risk > of missing such reinitialize_ptrue in newly added code in future, I > think it would be better to do the reinitialize in > pop_call_clobbered_registers(). > > P.S. the SIGILL message is also not clear, it should print detailed > message as indicated by MacroAssembler::stop() call. This is caused by > JDK-8255711 removing the message printing code. This patch also adds it > back, so that it could print detailed message for abort. > > Tested with tier1-3 on SVE hardware. Also verified with the same > approach of patch [3] with jtreg tests hotspot_all_no_apps and > jdk:tier1-3 passed without incorrect ptrue value assertion failure. > > [1] https://github.com/openjdk/jdk/pull/1621 > [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst > [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch Can I get a review for jdk16 please? I think the x86 pre-submit test failure is not related to this patch, which looks like the issue fixed by: https://github.com/openjdk/jdk16/pull/64 ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From iklam at openjdk.java.net Tue Jan 5 06:00:20 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 06:00:20 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp [v4] In-Reply-To: References: Message-ID: > Currently, [globals.hpp](https://github.com/openjdk/jdk/blob/17ace8339dd8235f3811e3975d9ccc77910b0c77/src/hotspot/share/runtime/globals.hpp#L29) is including gc_globals.hpp. This exposes all the GC command-line flags to almost all cpp files. However, only about 1/3 of the cpp files would require gc_globals.hpp. > > This RFE improves modularity and HotSpot build time. > > **Review notes:** > - Please start with globals.hpp, gc_globals.hpp. > - Flags related to TLAB are frequently used by other header files. I moved these flags to a new header tlab_globals.hpp. > - Some tweaking of oop.hpp to avoid including gc_globals.hpp in this popular header file. (Otherwise gc_globals.hpp would be included by everyone). > - The other changes are just files that use GC flags. They should have included gc_globals.hpp but didn't. > > **Testing:** > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam 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 seven additional commits since the last revision: - Merge branch 'master' into 8258459-decouple-gc-globals-hpp-from-globals-hpp - added tlab_globals.hpp to all files that use the TLAB globals - fixed copyright year - Merge branch 'master' into 8258459-decouple-gc-globals-hpp-from-globals-hpp - comments by coleenp - fixed copyright year - 8258459: Decouple gc_globals.hpp from globals.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1797/files - new: https://git.openjdk.java.net/jdk/pull/1797/files/372fd801..f68aa0ee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=02-03 Stats: 491 lines in 60 files changed: 213 ins; 129 del; 149 mod Patch: https://git.openjdk.java.net/jdk/pull/1797.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1797/head:pull/1797 PR: https://git.openjdk.java.net/jdk/pull/1797 From iklam at openjdk.java.net Tue Jan 5 06:00:23 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 06:00:23 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp [v4] In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 13:08:54 GMT, Coleen Phillimore wrote: >> Ioi Lam 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 seven additional commits since the last revision: >> >> - Merge branch 'master' into 8258459-decouple-gc-globals-hpp-from-globals-hpp >> - added tlab_globals.hpp to all files that use the TLAB globals >> - fixed copyright year >> - Merge branch 'master' into 8258459-decouple-gc-globals-hpp-from-globals-hpp >> - comments by coleenp >> - fixed copyright year >> - 8258459: Decouple gc_globals.hpp from globals.hpp > > Looks good! I had a couple of minor change requests. Thanks @coleenp and @lfoltan for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1797 From iklam at openjdk.java.net Tue Jan 5 06:00:25 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 5 Jan 2021 06:00:25 GMT Subject: Integrated: 8258459: Decouple gc_globals.hpp from globals.hpp In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 06:24:59 GMT, Ioi Lam wrote: > Currently, [globals.hpp](https://github.com/openjdk/jdk/blob/17ace8339dd8235f3811e3975d9ccc77910b0c77/src/hotspot/share/runtime/globals.hpp#L29) is including gc_globals.hpp. This exposes all the GC command-line flags to almost all cpp files. However, only about 1/3 of the cpp files would require gc_globals.hpp. > > This RFE improves modularity and HotSpot build time. > > **Review notes:** > - Please start with globals.hpp, gc_globals.hpp. > - Flags related to TLAB are frequently used by other header files. I moved these flags to a new header tlab_globals.hpp. > - Some tweaking of oop.hpp to avoid including gc_globals.hpp in this popular header file. (Otherwise gc_globals.hpp would be included by everyone). > - The other changes are just files that use GC flags. They should have included gc_globals.hpp but didn't. > > **Testing:** > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. This pull request has now been integrated. Changeset: 5ea96072 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/5ea96072 Stats: 445 lines in 127 files changed: 253 ins; 70 del; 122 mod 8258459: Decouple gc_globals.hpp from globals.hpp Reviewed-by: lfoltan, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1797 From adinn at openjdk.java.net Tue Jan 5 10:43:55 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 5 Jan 2021 10:43:55 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 05:44:36 GMT, Ningsheng Jian wrote: >> After applying [1], some Vector API tests fail with SIGILL on SVE >> system. The SIGILL was triggered by verify_ptrue before c2 compiled >> function returns, which means that the preserved p7 register (as ptrue) >> has been clobbered before returning to c2 compiled code. (p7 is not >> preserved cross function calls, and system calls [2]). >> >> Currently we try to reinitialize ptrue at each entrypoint of returning >> from non-c2 compiled code, which indicating possible C or system calls. >> However, there's still one entrypoint missing, exception handling, as >> we may jump to c2 compiled code for exception handler. See >> OptoRuntime::generate_exception_blob(). >> >> Adding reinitialize_ptrue before jumping back to c2 compiled code in >> generate_exception_blob() could solve those Vector API test failures. >> Actually I had that in my initial test patch [3], I don't know why I >> missed that in final patch... I reran tests with the same approach of >> [3] and found that there's still something missing, the >> nmethod_entry_barrier() in c2 function prolog. The barrier may call to >> runtime code (see generate_method_entry_barrier()). To reduce the risk >> of missing such reinitialize_ptrue in newly added code in future, I >> think it would be better to do the reinitialize in >> pop_call_clobbered_registers(). >> >> P.S. the SIGILL message is also not clear, it should print detailed >> message as indicated by MacroAssembler::stop() call. This is caused by >> JDK-8255711 removing the message printing code. This patch also adds it >> back, so that it could print detailed message for abort. >> >> Tested with tier1-3 on SVE hardware. Also verified with the same >> approach of patch [3] with jtreg tests hotspot_all_no_apps and >> jdk:tier1-3 passed without incorrect ptrue value assertion failure. >> >> [1] https://github.com/openjdk/jdk/pull/1621 >> [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst >> [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch > > Can I get a review for jdk16 please? > > I think the x86 pre-submit test failure is not related to this patch, which looks like the issue fixed by: https://github.com/openjdk/jdk16/pull/64 Hi Ningsheng, The SVE changes look ok. I'm just unsure about restoring the exit in the signal handler. ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From adinn at openjdk.java.net Tue Jan 5 10:43:58 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 5 Jan 2021 10:43:58 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v2] In-Reply-To: <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com> References: <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com> Message-ID: <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com> On Tue, 5 Jan 2021 02:57:15 GMT, Ningsheng Jian wrote: >> After applying [1], some Vector API tests fail with SIGILL on SVE >> system. The SIGILL was triggered by verify_ptrue before c2 compiled >> function returns, which means that the preserved p7 register (as ptrue) >> has been clobbered before returning to c2 compiled code. (p7 is not >> preserved cross function calls, and system calls [2]). >> >> Currently we try to reinitialize ptrue at each entrypoint of returning >> from non-c2 compiled code, which indicating possible C or system calls. >> However, there's still one entrypoint missing, exception handling, as >> we may jump to c2 compiled code for exception handler. See >> OptoRuntime::generate_exception_blob(). >> >> Adding reinitialize_ptrue before jumping back to c2 compiled code in >> generate_exception_blob() could solve those Vector API test failures. >> Actually I had that in my initial test patch [3], I don't know why I >> missed that in final patch... I reran tests with the same approach of >> [3] and found that there's still something missing, the >> nmethod_entry_barrier() in c2 function prolog. The barrier may call to >> runtime code (see generate_method_entry_barrier()). To reduce the risk >> of missing such reinitialize_ptrue in newly added code in future, I >> think it would be better to do the reinitialize in >> pop_call_clobbered_registers(). >> >> P.S. the SIGILL message is also not clear, it should print detailed >> message as indicated by MacroAssembler::stop() call. This is caused by >> JDK-8255711 removing the message printing code. This patch also adds it >> back, so that it could print detailed message for abort. >> >> Tested with tier1-3 on SVE hardware. Also verified with the same >> approach of patch [3] with jtreg tests hotspot_all_no_apps and >> jdk:tier1-3 passed without incorrect ptrue value assertion failure. >> >> [1] https://github.com/openjdk/jdk/pull/1621 >> [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst >> [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch > > Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2021. src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 252: > 250: pc, info, NULL, NULL, 0, 0); > 251: va_end(detail_args); > 252: } I'm not sure it is ok to revert this code. The fix this is part of (for JDK-8255711) was provided explicitly to re-organize the flow of control for handling of fatal errors. Reverting this code appears to undermine the goal of that issue. I would like to get Thomas Stuefe's (@tstuefe) opinion on whether it is appropriate to abort the JVM here vs returning false before accepting this specific change. ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From njian at openjdk.java.net Tue Jan 5 10:50:56 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 5 Jan 2021 10:50:56 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests In-Reply-To: References: Message-ID: <8c_83PwGl5YuRXbdHF2x0M9UrZocHav7peSPbQzPwuQ=.e8badd95-09ca-46c4-95e3-6479cab080c8@github.com> On Tue, 5 Jan 2021 10:41:40 GMT, Andrew Dinn wrote: > Hi Ningsheng, > > The SVE changes look ok. I'm just unsure about restoring the exit in the signal handler. Thank you @adinn for the review! @tstuefe would you mind helping to review the lines @adinn mentioned? Thanks! ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From aph at openjdk.java.net Tue Jan 5 11:21:57 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 5 Jan 2021 11:21:57 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 03:43:15 GMT, Dong Bo wrote: >> This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. >> >> Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. >> Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. >> >> Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. >> Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: >> Benchmark (COUNT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op >> VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op >> VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op >> VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op >> >> # Kunpeng 916, with fmaxp/fminp >> VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% >> VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op >> VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% >> VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op > > Dong Bo has updated the pull request incrementally with one additional commit since the last revision: > > rebase the .m4 entry This all looks reasonable. With the assembler change I think we should be good to go. src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2451: > 2449: #undef INSN > 2450: > 2451: #define INSN(NAME, opc) \ This should be in an "AdvSIMD scalar pairwise" instruction group with faddp. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From rpressler at openjdk.java.net Tue Jan 5 11:58:58 2021 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 5 Jan 2021 11:58:58 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 19:38:09 GMT, Coleen Phillimore wrote: > This change allows JRT_LEAF functions to create Handles because it doesn't need them but some code inside the VM needs Handles. There's a NoSafepointVerifier in JRT_LEAF functions. > The JNI_LEAF and JVM_LEAF functions have NoHandleMark (so you can't create handles) but the transition ThreadInVMfromNative will reenable the HandleMarks, so that all this code doesn't have to do it itself. > Tested with tier1-6. src/hotspot/share/code/compiledMethod.cpp line 707: > 705: Thread* thread = Thread::current(); > 706: ResetNoHandleMark rnm; // Might be called from LEAF/QUICK ENTRY > 707: HandleMark hm(thread); Why was the `HandleMark` removed here? Is it not needed? src/hotspot/share/runtime/interfaceSupport.inline.hpp line 353: > 351: #define VM_LEAF_BASE(result_type, header) \ > 352: TRACE_CALL(result_type, header) \ > 353: debug_only(NoHandleMark __hm;) \ Shouldn't `NoSafepointVerifier` be added here and then it can be removed from `JRT_LEAF`? src/hotspot/share/runtime/interfaceSupport.inline.hpp line 484: > 482: result_type JNICALL header { \ > 483: VM_Exit::block_if_vm_exited(); \ > 484: debug_only(NoHandleMark __hm;) \ Why does `JVM_LEAF` need `NoHandleMark`? ------------- PR: https://git.openjdk.java.net/jdk/pull/1846 From dongbo at openjdk.java.net Tue Jan 5 13:42:21 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 5 Jan 2021 13:42:21 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: > This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. > > Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. > Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. > > Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. > Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op > VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op > VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op > VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op > > # Kunpeng 916, with fmaxp/fminp > VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% > VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op > VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% > VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: put faddp/fmaxp/fminp together in a group ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1925/files - new: https://git.openjdk.java.net/jdk/pull/1925/files/876939b9..c0c6f51f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=01-02 Stats: 27 lines in 1 file changed: 6 ins; 14 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1925/head:pull/1925 PR: https://git.openjdk.java.net/jdk/pull/1925 From dongbo at openjdk.java.net Tue Jan 5 13:45:56 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 5 Jan 2021 13:45:56 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 11:10:17 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> rebase the .m4 entry > > src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2451: > >> 2449: #undef INSN >> 2450: >> 2451: #define INSN(NAME, opc) \ > > This should be in an "AdvSIMD scalar pairwise" instruction group with faddp. Done. The instructions `faddp`, `fmax` and `fmin` are put together in one group now. Re-run the `test/jdk/jdk/incubator/vector/` tests and passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From coleenp at openjdk.java.net Tue Jan 5 14:44:04 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 5 Jan 2021 14:44:04 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 11:46:30 GMT, Ron Pressler wrote: >> This change allows JRT_LEAF functions to create Handles because it doesn't need them but some code inside the VM needs Handles. There's a NoSafepointVerifier in JRT_LEAF functions. >> The JNI_LEAF and JVM_LEAF functions have NoHandleMark (so you can't create handles) but the transition ThreadInVMfromNative will reenable the HandleMarks, so that all this code doesn't have to do it itself. >> Tested with tier1-6. > > src/hotspot/share/code/compiledMethod.cpp line 707: > >> 705: Thread* thread = Thread::current(); >> 706: ResetNoHandleMark rnm; // Might be called from LEAF/QUICK ENTRY >> 707: HandleMark hm(thread); > > Why was the `HandleMark` removed here? Is it not needed? There are no Handles in this block. There are a lot of rogue HandleMarks around because of PermGen. They don't do anything harmful, but they don't hold any Handles either. > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 353: > >> 351: #define VM_LEAF_BASE(result_type, header) \ >> 352: TRACE_CALL(result_type, header) \ >> 353: debug_only(NoHandleMark __hm;) \ > > Shouldn't `NoSafepointVerifier` be added here and then it can be removed from `JRT_LEAF`? I don't want a NoSafepointVerifier in JNI_LEAF, and the equivalent fromNative JVM_LEAF, which "calls" this. I only want it in JRT_LEAF. JNI_LEAF isn't really a leaf, it often calls JNI functions that transition to the VM. > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 484: > >> 482: result_type JNICALL header { \ >> 483: VM_Exit::block_if_vm_exited(); \ >> 484: debug_only(NoHandleMark __hm;) \ > > Why does `JVM_LEAF` need `NoHandleMark`? JVM_LEAF comes from _thread_in_native so there shouldn't be oops or Handles. It's really equivalent to JNI_LEAF. I tried to make sense of this in the CR report, mostly so I'd remember what I was thinking. ------------- PR: https://git.openjdk.java.net/jdk/pull/1846 From coleenp at openjdk.java.net Tue Jan 5 14:43:58 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 5 Jan 2021 14:43:58 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 19:38:09 GMT, Coleen Phillimore wrote: > This change allows JRT_LEAF functions to create Handles because it doesn't need them but some code inside the VM needs Handles. There's a NoSafepointVerifier in JRT_LEAF functions. > The JNI_LEAF and JVM_LEAF functions have NoHandleMark (so you can't create handles) but the transition ThreadInVMfromNative will reenable the HandleMarks, so that all this code doesn't have to do it itself. > Tested with tier1-6. Ron, thanks for looking at this and for this request. ------------- PR: https://git.openjdk.java.net/jdk/pull/1846 From coleenp at openjdk.java.net Tue Jan 5 14:48:13 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 5 Jan 2021 14:48:13 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions [v2] In-Reply-To: References: Message-ID: > This change allows JRT_LEAF functions to create Handles because it doesn't need them but some code inside the VM needs Handles. There's a NoSafepointVerifier in JRT_LEAF functions. > The JNI_LEAF and JVM_LEAF functions have NoHandleMark (so you can't create handles) but the transition ThreadInVMfromNative will reenable the HandleMarks, so that all this code doesn't have to do it itself. > Tested with tier1-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix copyrights. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1846/files - new: https://git.openjdk.java.net/jdk/pull/1846/files/3b4a1750..6f65664f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1846&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1846&range=00-01 Stats: 16 lines in 16 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1846.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1846/head:pull/1846 PR: https://git.openjdk.java.net/jdk/pull/1846 From rpressler at openjdk.java.net Tue Jan 5 14:50:59 2021 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 5 Jan 2021 14:50:59 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 14:48:13 GMT, Coleen Phillimore wrote: >> This change allows JRT_LEAF functions to create Handles because it doesn't need them but some code inside the VM needs Handles. There's a NoSafepointVerifier in JRT_LEAF functions. >> The JNI_LEAF and JVM_LEAF functions have NoHandleMark (so you can't create handles) but the transition ThreadInVMfromNative will reenable the HandleMarks, so that all this code doesn't have to do it itself. >> Tested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyrights. Marked as reviewed by rpressler (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/1846 From psandoz at openjdk.java.net Tue Jan 5 15:53:55 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 5 Jan 2021 15:53:55 GMT Subject: [jdk16] RFR: 8259213: Vector conversion with part > 0 is not getting intrinsic implementation In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 01:03:55 GMT, Sandhya Viswanathan wrote: > Vector conversion with part > 0 is implemented using slice(origin, vector) instead of slice(origin). > The slice(origin) has intrinsic implementation whereas slice(origin, vector) doesn?t. > Slice(origin) is written using vector API methods like rearrange and blend which all have intrinsic implementations. > Also, VectorIntrinsics.VECTOR_ACCESS_OOB_CHECK code is missing from rearrange checkIndexes. > > Please review this patch which fixes the above issue. > > Best Regards, > Sandhya Looks good. Can you please update the copyright year before integrating? I notice the issue is not assigned to you, unsure of Skara will make it so once integrated. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/79 From sviswanathan at openjdk.java.net Tue Jan 5 17:17:11 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 5 Jan 2021 17:17:11 GMT Subject: [jdk16] RFR: 8259213: Vector conversion with part > 0 is not getting intrinsic implementation [v2] In-Reply-To: References: Message-ID: <0JtoDeYrCblrZAyD7ODvI1i1TDeOVX9qIsiyN1y0qAk=.2108d536-7648-4c80-98c0-06e5212cd55b@github.com> > Vector conversion with part > 0 is implemented using slice(origin, vector) instead of slice(origin). > The slice(origin) has intrinsic implementation whereas slice(origin, vector) doesn?t. > Slice(origin) is written using vector API methods like rearrange and blend which all have intrinsic implementations. > Also, VectorIntrinsics.VECTOR_ACCESS_OOB_CHECK code is missing from rearrange checkIndexes. > > Please review this patch which fixes the above issue. > > Best Regards, > Sandhya Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/79/files - new: https://git.openjdk.java.net/jdk16/pull/79/files/c283812f..29ed8e43 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=79&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=79&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/79.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/79/head:pull/79 PR: https://git.openjdk.java.net/jdk16/pull/79 From sviswanathan at openjdk.java.net Tue Jan 5 17:20:00 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 5 Jan 2021 17:20:00 GMT Subject: [jdk16] RFR: 8259213: Vector conversion with part > 0 is not getting intrinsic implementation [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 15:51:08 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright year > > Looks good. Can you please update the copyright year before integrating? > > I notice the issue is not assigned to you, unsure of Skara will make it so once integrated. @PaulSandoz Thanks a lot for the review. I have updated the copyright year. Please let me know if I can go ahead and integrate. ------------- PR: https://git.openjdk.java.net/jdk16/pull/79 From psandoz at openjdk.java.net Tue Jan 5 17:33:56 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 5 Jan 2021 17:33:56 GMT Subject: [jdk16] RFR: 8259213: Vector conversion with part > 0 is not getting intrinsic implementation [v2] In-Reply-To: References: Message-ID: <7fz4H7u0nulJP4-2XpQaGTNiwKHAMzDULJCK9hmuRac=.04dee001-5510-4ea1-90eb-d99e50e692d6@github.com> On Tue, 5 Jan 2021 15:51:08 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright year > > Looks good. Can you please update the copyright year before integrating? > > I notice the issue is not assigned to you, unsure of Skara will make it so once integrated. > @PaulSandoz Thanks a lot for the review. I have updated the copyright year. Please let me know if I can go ahead and integrate. All good. ------------- PR: https://git.openjdk.java.net/jdk16/pull/79 From sviswanathan at openjdk.java.net Tue Jan 5 17:44:59 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 5 Jan 2021 17:44:59 GMT Subject: [jdk16] Integrated: 8259213: Vector conversion with part > 0 is not getting intrinsic implementation In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 01:03:55 GMT, Sandhya Viswanathan wrote: > Vector conversion with part > 0 is implemented using slice(origin, vector) instead of slice(origin). > The slice(origin) has intrinsic implementation whereas slice(origin, vector) doesn?t. > Slice(origin) is written using vector API methods like rearrange and blend which all have intrinsic implementations. > Also, VectorIntrinsics.VECTOR_ACCESS_OOB_CHECK code is missing from rearrange checkIndexes. > > Please review this patch which fixes the above issue. > > Best Regards, > Sandhya This pull request has now been integrated. Changeset: 50bf4330 Author: Sandhya Viswanathan URL: https://git.openjdk.java.net/jdk16/commit/50bf4330 Stats: 10 lines in 2 files changed: 6 ins; 0 del; 4 mod 8259213: Vector conversion with part > 0 is not getting intrinsic implementation Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk16/pull/79 From zgu at openjdk.java.net Tue Jan 5 18:03:06 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 5 Jan 2021 18:03:06 GMT Subject: RFR: 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 Message-ID: Please review this trivial change that fixes build failure after JDK-8258459 ------------- Commit messages: - Fix build failure Changes: https://git.openjdk.java.net/jdk/pull/1946/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1946&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259252 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1946.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1946/head:pull/1946 PR: https://git.openjdk.java.net/jdk/pull/1946 From hseigel at openjdk.java.net Tue Jan 5 18:05:05 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 5 Jan 2021 18:05:05 GMT Subject: RFR: 8258937: Remove JVM IgnoreRewrites flag Message-ID: Please review this change to remove the legacy JVM develop flag IgnoreRewrites. The change was tested with Mach5 tiers 1-2 on Linux, Windows, and Mac OS, and tiers 3-5 on Linux x64. Thanks, Harold ------------- Commit messages: - 8258937: Remove JVM IgnoreRewrites flag Changes: https://git.openjdk.java.net/jdk/pull/1947/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1947&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258937 Stats: 29 lines in 2 files changed: 0 ins; 27 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1947.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1947/head:pull/1947 PR: https://git.openjdk.java.net/jdk/pull/1947 From rkennke at openjdk.java.net Tue Jan 5 18:21:55 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 5 Jan 2021 18:21:55 GMT Subject: RFR: 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 17:57:47 GMT, Zhengyu Gu wrote: > Please review this trivial change that fixes build failure after JDK-8258459 Looks good! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1946 From shade at openjdk.java.net Tue Jan 5 18:26:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 18:26:54 GMT Subject: RFR: 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 18:22:09 GMT, Aleksey Shipilev wrote: >> Please review this trivial change that fixes build failure after JDK-8258459 > > Looks good. `shenandoahBarrierSetC1_x86.cpp` already has this include. ...and yes, this is trivial. ------------- PR: https://git.openjdk.java.net/jdk/pull/1946 From shade at openjdk.java.net Tue Jan 5 18:26:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 18:26:54 GMT Subject: RFR: 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 17:57:47 GMT, Zhengyu Gu wrote: > Please review this trivial change that fixes build failure after JDK-8258459 Looks good. `shenandoahBarrierSetC1_x86.cpp` already has this include. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1946 From zgu at openjdk.java.net Tue Jan 5 18:37:05 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 5 Jan 2021 18:37:05 GMT Subject: Integrated: 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 17:57:47 GMT, Zhengyu Gu wrote: > Please review this trivial change that fixes build failure after JDK-8258459 This pull request has now been integrated. Changeset: 1b60acd8 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/1b60acd8 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 Reviewed-by: rkennke, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1946 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 shade at openjdk.java.net Tue Jan 5 19:00:05 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 5 Jan 2021 19:00:05 GMT Subject: [jdk16] RFR: 8258558: Revert changes for JDK-8252505 and related issues Message-ID: As the result of retroactive CSR discussion in JDK-8257827, I have decided to revert the original push and all the follow-up changes from JDK 16, in order to reconsider them for JDK 17. This PR reverts the following changes -- the reversal is clean and done without manual intervention: JDK-8258111: Problemlist compiler/blackhole tests for -Xcomp until JDK-8258101 is fixed JDK-8257848: -XX:CompileCommand=blackhole,* should be diagnostic JDK-8257805: Add compiler/blackhole tests to tier1 JDK-8257803: Add -Xbatch to compiler/blackhole tests JDK-8252505: C1/C2 compiler support for blackholes While line count is great, the overwhelming majority of changes are test removals. Additional testing: - [x] Linux x86_64 `tier1` ------------- Commit messages: - 8258558: Revert changes for JDK-8252505 Changes: https://git.openjdk.java.net/jdk16/pull/86/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=86&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258558 Stats: 1662 lines in 33 files changed: 0 ins; 1660 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/86.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/86/head:pull/86 PR: https://git.openjdk.java.net/jdk16/pull/86 From kvn at openjdk.java.net Tue Jan 5 19:22:59 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 5 Jan 2021 19:22:59 GMT Subject: [jdk16] RFR: 8258558: Revert changes for JDK-8252505 and related issues In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 18:54:45 GMT, Aleksey Shipilev wrote: > As the result of retroactive CSR discussion in JDK-8257827, I have decided to revert the original push and all the follow-up changes from JDK 16, in order to reconsider them for JDK 17. > > This PR reverts the following changes -- the reversal is clean and done without manual intervention: > JDK-8258111: Problemlist compiler/blackhole tests for -Xcomp until JDK-8258101 is fixed > JDK-8257848: -XX:CompileCommand=blackhole,* should be diagnostic > JDK-8257805: Add compiler/blackhole tests to tier1 > JDK-8257803: Add -Xbatch to compiler/blackhole tests > JDK-8252505: C1/C2 compiler support for blackholes > > While line count is great, the overwhelming majority of changes are test removals. > > Additional testing: > - [x] Linux x86_64 `tier1` Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/86 From coleenp at openjdk.java.net Tue Jan 5 21:03:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 5 Jan 2021 21:03:57 GMT Subject: RFR: 8258937: Remove JVM IgnoreRewrites flag In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 18:00:11 GMT, Harold Seigel wrote: > Please review this change to remove the legacy JVM develop flag IgnoreRewrites. > > The change was tested with Mach5 tiers 1-2 on Linux, Windows, and Mac OS, and tiers 3-5 on Linux x64. > > Thanks, Harold Wow, terrifying. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1947 From coleenp at openjdk.java.net Tue Jan 5 21:03:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 5 Jan 2021 21:03:57 GMT Subject: RFR: 8258937: Remove JVM IgnoreRewrites flag In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 21:00:57 GMT, Coleen Phillimore wrote: >> Please review this change to remove the legacy JVM develop flag IgnoreRewrites. >> >> The change was tested with Mach5 tiers 1-2 on Linux, Windows, and Mac OS, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Wow, terrifying. I'd say this is trivial also. ------------- PR: https://git.openjdk.java.net/jdk/pull/1947 From sspitsyn at openjdk.java.net Tue Jan 5 21:14:02 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 5 Jan 2021 21:14:02 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 04:19:29 GMT, Coleen Phillimore wrote: >> Hi Coleen, >> >> LGTM++ >> >> Thanks, >> Serguei > > Thanks Serguei. Ioi convinced me offline to simplify and just use a mutex, so I updated the patch to do that. I tested with jdi and jvmti tests and will rerun tier1-3. Coleen, the function `ClassLoader::add_to_boot_append_entries` is also called from `ClassLoader::update_class_path_entry_list` and `ClassLoaderExt::append_boot_classpath`. It is not clear why the `Bootclasspath_lock` is not used for sync in these contexts. Could you consider to move this `MutexLocker` from `JvmtiEnv::AddToBootstrapClassLoaderSearch` to `ClassLoader::add_to_boot_append_entries`? ------------- PR: https://git.openjdk.java.net/jdk/pull/1935 From hseigel at openjdk.java.net Tue Jan 5 21:17:53 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 5 Jan 2021 21:17:53 GMT Subject: RFR: 8258937: Remove JVM IgnoreRewrites flag In-Reply-To: References: Message-ID: <2ZtiK2gJKodXfs8HN5KrmiUAPGlkZ9pKEMRQDpTrxNo=.98c86e33-788f-4759-90a4-f81780ccdcfe@github.com> On Tue, 5 Jan 2021 21:01:15 GMT, Coleen Phillimore wrote: >> Wow, terrifying. > > I'd say this is trivial also. Thanks Coleen! ------------- PR: https://git.openjdk.java.net/jdk/pull/1947 From hseigel at openjdk.java.net Tue Jan 5 21:17:55 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 5 Jan 2021 21:17:55 GMT Subject: Integrated: 8258937: Remove JVM IgnoreRewrites flag In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 18:00:11 GMT, Harold Seigel wrote: > Please review this change to remove the legacy JVM develop flag IgnoreRewrites. > > The change was tested with Mach5 tiers 1-2 on Linux, Windows, and Mac OS, and tiers 3-5 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: cf9908b4 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/cf9908b4 Stats: 29 lines in 2 files changed: 0 ins; 27 del; 2 mod 8258937: Remove JVM IgnoreRewrites flag Reviewed-by: coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1947 From hseigel at openjdk.java.net Tue Jan 5 22:02:12 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 5 Jan 2021 22:02:12 GMT Subject: RFR: 8258908: Remove JVM option CleanChunkPoolAsync Message-ID: Please review this small change to remove JVM develop option CleanChunkPoolAsync. The option was originally added for embedded builds so they could clean chunk pools synchronouosly. The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. Thanks, Harold ------------- Commit messages: - 8258908: Remove JVM option CleanChunkPoolAsync Changes: https://git.openjdk.java.net/jdk/pull/1949/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1949&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258908 Stats: 25 lines in 6 files changed: 0 ins; 20 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1949.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1949/head:pull/1949 PR: https://git.openjdk.java.net/jdk/pull/1949 From coleenp at openjdk.java.net Tue Jan 5 22:28:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 5 Jan 2021 22:28:55 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 21:10:45 GMT, Serguei Spitsyn wrote: >> Thanks Serguei. Ioi convinced me offline to simplify and just use a mutex, so I updated the patch to do that. I tested with jdi and jvmti tests and will rerun tier1-3. > > Coleen, the function `ClassLoader::add_to_boot_append_entries` is also called from `ClassLoader::update_class_path_entry_list` and `ClassLoaderExt::append_boot_classpath`. It is not clear why the `Bootclasspath_lock` is not used for sync in these contexts. Could you consider to move this `MutexLocker` from `JvmtiEnv::AddToBootstrapClassLoaderSearch` to `ClassLoader::add_to_boot_append_entries`? Thanks Serguei. I was trying to decide whether to move the lock there or add an assert that we are not multi-threaded when the lock isn't held. But it's cleaner to just move the lock there, so I'll do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1935 From sviswanathan at openjdk.java.net Tue Jan 5 23:18:04 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 5 Jan 2021 23:18:04 GMT Subject: RFR: 8259278: Optimize Vector API slice and unslice operations Message-ID: <0Hoxshsrh_L881MMdvplGZIUjkrtXwQcOqnOKtNAQqE=.fe0063e1-3234-44dd-884b-c92bf4d3ed5d@github.com> This pull request optimizes Vector API slice and unslice operations. All the slice and unslice variants that take more than one argument are implemented in terms of already intrinsic methods on similar lines as slice(origin) and unslice(origin). Also, the slice and unslice intrinsics for 256-bit byte/short vectors implemented for x86 platforms supporting AVX2 using a sequence of instructions. For TestSlice.java attached to JBS (https://bugs.openjdk.java.net/browse/JDK-8259278): Before: Benchmark (size) Mode Cnt Score Error Units TestSlice.vectorSliceOrigin 1024 thrpt 5 17.665 ? 0.980 ops/ms TestSlice.vectorSliceOriginVector 1024 thrpt 5 604.179 ? 5.795 ops/ms TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 9.286 ? 0.088 ops/ms TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 435.678 ? 30.171 ops/ms TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 440.492 ? 24.592 ops/ms After: Benchmark (size) Mode Cnt Score Error Units TestSlice.vectorSliceOrigin 1024 thrpt 5 1319.044 ? 67.862 ops/ms TestSlice.vectorSliceOriginVector 1024 thrpt 5 969.514 ? 33.411 ops/ms TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 687.804 ? 31.511 ops/ms TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 560.807 ? 20.600 ops/ms TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 560.202 ? 4.012 ops/ms Please review. Best Regards, Sandhya ------------- Commit messages: - 8259278: Optimize Vector API slice and unslice operations Changes: https://git.openjdk.java.net/jdk/pull/1950/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1950&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259278 Stats: 1475 lines in 45 files changed: 563 ins; 285 del; 627 mod Patch: https://git.openjdk.java.net/jdk/pull/1950.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1950/head:pull/1950 PR: https://git.openjdk.java.net/jdk/pull/1950 From coleenp at openjdk.java.net Wed Jan 6 00:18:20 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Jan 2021 00:18:20 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 22:26:11 GMT, Coleen Phillimore wrote: >> Coleen, the function `ClassLoader::add_to_boot_append_entries` is also called from `ClassLoader::update_class_path_entry_list` and `ClassLoaderExt::append_boot_classpath`. It is not clear why the `Bootclasspath_lock` is not used for sync in these contexts. Could you consider to move this `MutexLocker` from `JvmtiEnv::AddToBootstrapClassLoaderSearch` to `ClassLoader::add_to_boot_append_entries`? > > Thanks Serguei. I was trying to decide whether to move the lock there or add an assert that we are not multi-threaded when the lock isn't held. But it's cleaner to just move the lock there, so I'll do that. I reran tier1 and jvmti and jdi tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/1935 From coleenp at openjdk.java.net Wed Jan 6 00:18:19 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Jan 2021 00:18:19 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v3] In-Reply-To: References: Message-ID: > See CR for details. > I made the classpath append list lock-free. Calling experts in Atomic operations... > Tested with tier1-6. > Thanks, > Coleen Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Move locking into function where exclusive access is needed. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1935/files - new: https://git.openjdk.java.net/jdk/pull/1935/files/fb8e87d7..9b250606 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1935&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1935&range=01-02 Stats: 3 lines in 2 files changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1935.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1935/head:pull/1935 PR: https://git.openjdk.java.net/jdk/pull/1935 From kbarrett at openjdk.java.net Wed Jan 6 01:53:55 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 6 Jan 2021 01:53:55 GMT Subject: RFR: 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 01:05:29 GMT, Kim Barrett wrote: > Please review this change which adds the ENABLE_IF_PARAM macro. This is > used in the definition of a function template when that definition is > separate from the declaration and the declaration uses ENABLE_IF. > > For the separate definition to match the declaration, the non-type template > parameter for SFINAE in the two places must be "equivalent", where that's > defined in terms of tokens. Rather than requiring a separate definition > match the ENABLE_IF expansion directly, the new macro is provided; it is > maintained in parallel with ENABLE_IF to ensure the needed consistency. > > Alternative names for the new macro are possible. > > (1) This gives the following usage: > > template::value)> > void foo(T x) { ... } > > and this for separate declaration and definition. > > template::value)> > void foo(T x); > > // later separate definition > template::value)> > void foo(T x) { ... } > > (2) An alternative that isn't being proposed here, but which could be done > instead, would be to drop the ENABLE_IF macro and use a type alias, with > associated change of syntax. Suppose the name is EnableIfX (should probably > be EnableIf, but need to deal with name conflict). It would be defined as > > template using EnableIfX = std::enable_if_t; > > and used as > > template::value> = 0> > void foo(T x) { ... } > > and this for separate declaration and definition. > > template::value> = 0> > void foo(T x); > > // later separate definition > template::value>> > void foo(T x) { ... } > > (3) Or we could not provide any syntactic help, and just write it all out everywhere: > > template::value, int> = 0> > void foo(T x) { ... } > > and this for separate declaration and definition. > > template::value, int> = 0> > void foo(T x); > > // later separate definition > template::value, int>> > void foo(T x) { ... } > > Testing: > mach5 tier1 > This includes some new gtests for the macros. > There aren't any current non-test uses of ENABLE_IF_PARAM yet. Some offline discussion with jrose has led to some intersting discoveries that require changes, so I'm withdrawing this for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1873 From kbarrett at openjdk.java.net Wed Jan 6 01:53:56 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 6 Jan 2021 01:53:56 GMT Subject: Withdrawn: 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 01:05:29 GMT, Kim Barrett wrote: > Please review this change which adds the ENABLE_IF_PARAM macro. This is > used in the definition of a function template when that definition is > separate from the declaration and the declaration uses ENABLE_IF. > > For the separate definition to match the declaration, the non-type template > parameter for SFINAE in the two places must be "equivalent", where that's > defined in terms of tokens. Rather than requiring a separate definition > match the ENABLE_IF expansion directly, the new macro is provided; it is > maintained in parallel with ENABLE_IF to ensure the needed consistency. > > Alternative names for the new macro are possible. > > (1) This gives the following usage: > > template::value)> > void foo(T x) { ... } > > and this for separate declaration and definition. > > template::value)> > void foo(T x); > > // later separate definition > template::value)> > void foo(T x) { ... } > > (2) An alternative that isn't being proposed here, but which could be done > instead, would be to drop the ENABLE_IF macro and use a type alias, with > associated change of syntax. Suppose the name is EnableIfX (should probably > be EnableIf, but need to deal with name conflict). It would be defined as > > template using EnableIfX = std::enable_if_t; > > and used as > > template::value> = 0> > void foo(T x) { ... } > > and this for separate declaration and definition. > > template::value> = 0> > void foo(T x); > > // later separate definition > template::value>> > void foo(T x) { ... } > > (3) Or we could not provide any syntactic help, and just write it all out everywhere: > > template::value, int> = 0> > void foo(T x) { ... } > > and this for separate declaration and definition. > > template::value, int> = 0> > void foo(T x); > > // later separate definition > template::value, int>> > void foo(T x) { ... } > > Testing: > mach5 tier1 > This includes some new gtests for the macros. > There aren't any current non-test uses of ENABLE_IF_PARAM yet. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1873 From iklam at openjdk.java.net Wed Jan 6 02:46:55 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 6 Jan 2021 02:46:55 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v3] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 00:18:19 GMT, Coleen Phillimore wrote: >> See CR for details. >> I made the classpath append list lock-free. Calling experts in Atomic operations... >> Tested with tier1-6. >> Thanks, >> Coleen > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Move locking into function where exclusive access is needed. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1935 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 sspitsyn at openjdk.java.net Wed Jan 6 06:33:59 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 6 Jan 2021 06:33:59 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v3] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 00:18:19 GMT, Coleen Phillimore wrote: >> See CR for details. >> I made the classpath append list lock-free. Calling experts in Atomic operations... >> Tested with tier1-6. >> Thanks, >> Coleen > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Move locking into function where exclusive access is needed. LGTM++ ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1935 From shade at openjdk.java.net Wed Jan 6 14:28:21 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 6 Jan 2021 14:28:21 GMT Subject: [jdk16] Integrated: 8258558: Revert changes for JDK-8252505 and related issues In-Reply-To: References: Message-ID: <7RwVxUOINX55Iz2lR-FQ6lNckKWYdG4DyhR-Aa0u204=.4fa7790e-1408-4829-a167-e41f23ad642e@github.com> On Tue, 5 Jan 2021 18:54:45 GMT, Aleksey Shipilev wrote: > As the result of retroactive CSR discussion in JDK-8257827, I have decided to revert the original push and all the follow-up changes from JDK 16, in order to reconsider them for JDK 17. > > This PR reverts the following changes -- the reversal is clean and done without manual intervention: > JDK-8258111: Problemlist compiler/blackhole tests for -Xcomp until JDK-8258101 is fixed > JDK-8257848: -XX:CompileCommand=blackhole,* should be diagnostic > JDK-8257805: Add compiler/blackhole tests to tier1 > JDK-8257803: Add -Xbatch to compiler/blackhole tests > JDK-8252505: C1/C2 compiler support for blackholes > > While line count is great, the overwhelming majority of changes are test removals. > > Additional testing: > - [x] Linux x86_64 `tier1` This pull request has now been integrated. Changeset: ad456787 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16/commit/ad456787 Stats: 1662 lines in 33 files changed: 0 ins; 1660 del; 2 mod 8258558: Revert changes for JDK-8252505 and related issues Reviewed-by: kvn ------------- PR: https://git.openjdk.java.net/jdk16/pull/86 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 coleenp at openjdk.java.net Wed Jan 6 15:06:59 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Jan 2021 15:06:59 GMT Subject: RFR: 8258908: Remove JVM option CleanChunkPoolAsync In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 21:53:39 GMT, Harold Seigel wrote: > Please review this small change to remove JVM develop option CleanChunkPoolAsync. The option was originally added for embedded builds so they could clean chunk pools synchronouosly. > > The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Looks good and trivial. Thanks! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1949 From hseigel at openjdk.java.net Wed Jan 6 15:14:52 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 6 Jan 2021 15:14:52 GMT Subject: RFR: 8258908: Remove JVM option CleanChunkPoolAsync In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 15:03:42 GMT, Coleen Phillimore wrote: >> Please review this small change to remove JVM develop option CleanChunkPoolAsync. The option was originally added for embedded builds so they could clean chunk pools synchronouosly. >> >> The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Looks good and trivial. Thanks! Thanks Coleen! ------------- PR: https://git.openjdk.java.net/jdk/pull/1949 From hseigel at openjdk.java.net Wed Jan 6 15:14:53 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 6 Jan 2021 15:14:53 GMT Subject: Integrated: 8258908: Remove JVM option CleanChunkPoolAsync In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 21:53:39 GMT, Harold Seigel wrote: > Please review this small change to remove JVM develop option CleanChunkPoolAsync. The option was originally added for embedded builds so they could clean chunk pools synchronouosly. > > The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: f6cb8c55 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/f6cb8c55 Stats: 25 lines in 6 files changed: 0 ins; 20 del; 5 mod 8258908: Remove JVM option CleanChunkPoolAsync Reviewed-by: coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1949 From lfoltan at openjdk.java.net Wed Jan 6 15:42:56 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 6 Jan 2021 15:42:56 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v3] In-Reply-To: References: Message-ID: <32yPbZk4Jmgb0p3WhVxXqydMpQgynlKllluOu6VpAAk=.76b95147-6835-46c7-8bbb-8160b54138f0@github.com> On Wed, 6 Jan 2021 00:18:19 GMT, Coleen Phillimore wrote: >> See CR for details. >> I made the classpath append list lock-free. Calling experts in Atomic operations... >> Tested with tier1-6. >> Thanks, >> Coleen > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Move locking into function where exclusive access is needed. Changes look good to me. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1935 From dcubed at openjdk.java.net Wed Jan 6 17:19:05 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 6 Jan 2021 17:19:05 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions [v2] In-Reply-To: References: Message-ID: <6J9CKtxCHQwK2ze6tQBZ6jD9QnFP9k_mP1TFuXPRySE=.7afe7ad5-97cd-4410-beab-c5199427c8bc@github.com> On Tue, 5 Jan 2021 14:48:13 GMT, Coleen Phillimore wrote: >> This change allows JRT_LEAF functions to create Handles because it doesn't need them but some code inside the VM needs Handles. There's a NoSafepointVerifier in JRT_LEAF functions. >> The JNI_LEAF and JVM_LEAF functions have NoHandleMark (so you can't create handles) but the transition ThreadInVMfromNative will reenable the HandleMarks, so that all this code doesn't have to do it itself. >> Tested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyrights. So these changes boil down to: - remove ResetNoHandleMark and NoHandleMark helpers in favor of having them in the appropriate interfaceSupport.inline.hpp macros and helpers - ThreadInVMfromNative now has a ResetNoHandleMark helper - VM_LEAF_BASE no longer needs a NoHandleMark helper - VM_ENTRY_BASE_FROM_LEAF no longer needs a ResetNoHandleMark helper - JNI_LEAF now has a NoHandleMark helper - JVM_LEAF now has a NoHandleMark helper - JVM_ENTRY_FROM_LEAF now has a ResetNoHandleMark helper Okay, I think I grok these changes and they look good to me. I would like to see Tier7 and Tier8 testing done since longer stress runs are done in those tiers. src/hotspot/share/c1/c1_Runtime1.cpp line 647: > 645: address pc = thread->exception_pc(); > 646: // Still in Java mode > 647: nmethod* nm = NULL; You are definitely going to want a C1 cognizant person to review the changes in this file. The baseline's use of ResetNoHandleMark and NoHandleMark in this file is an absolute mess. I don't understand the reason for old L647 here and for old L652 below. Double ResetNoHandleMarks, but why? I see no reason for old L647 so glad that it's gone! src/hotspot/share/c1/c1_Runtime1.cpp line 1311: > 1309: patch_code(thread, load_klass_patching_id); > 1310: > 1311: // Back in JAVA, use no oops DON'T safepoint The baseline here is even more confused. debug_only NoHandleMark here on old L1311 and a ResetNoHandleMark on old L1315. I see no reason for old L1311 so glad that it's gone! src/hotspot/share/c1/c1_Runtime1.cpp line 1330: > 1328: } > 1329: > 1330: int Runtime1::move_appendix_patching(JavaThread* thread) { And again a debug_only NoHandleMark on old L1330 and ResetNoHandleMark on old L1334. What the heck? src/hotspot/share/c1/c1_Runtime1.cpp line 1349: > 1347: // helper method which does the normal VM transition and when it > 1348: // completes we can check for deoptimization. This simplifies the > 1349: // assembly code in the cpu directories. And again a debug_only NoHandleMark on old L1349 and ResetNoHandleMark on old L1353. What the heck? src/hotspot/share/c1/c1_Runtime1.cpp line 1376: > 1374: // between the C calling convention and the Java one. > 1375: // e.g., on x86, GCC may clear only %al when returning a bool false, but > 1376: // JVM takes the whole %eax as the return value, which may misinterpret And again a debug_only NoHandleMark on old L1376 and ResetNoHandleMark on old L1380. What the heck? src/hotspot/share/jvmci/jvmciRuntime.cpp line 375: > 373: address pc = thread->exception_pc(); > 374: // Still in Java mode > 375: CompiledMethod* cm = NULL; I don't understand the reason for old L375 here and for old L380 below. Double ResetNoHandleMarks, but why? I see no reason for old L375 so glad that it's gone! src/hotspot/share/opto/runtime.cpp line 1362: > 1360: SharedRuntime::_find_handler_ctr++; // find exception handler > 1361: #endif > 1362: nmethod* nm = NULL; The baseline here is even more confused. debug_only NoHandleMark here on old L1362 and a ResetNoHandleMark on old L1368. I see no reason for old L1362 so glad that it's gone! src/hotspot/share/runtime/deoptimization.cpp line 153: > 151: > 152: // In order to make fetch_unroll_info work properly with escape > 153: // analysis, The method was changed from JRT_LEAF to JRT_BLOCK_ENTRY. nit - typo (not yours): s/, The/, the/ src/hotspot/share/runtime/handles.hpp line 292: > 290: > 291: // ResetNoHandleMark is called in a context where there is an enclosing > 292: // NoHandleMark. Thread in _thread_in_native cannot create handles so Perhaps: // NoHandleMark. A thread in _thread_in_native must not create handles so src/hotspot/share/runtime/handles.hpp line 293: > 291: // ResetNoHandleMark is called in a context where there is an enclosing > 292: // NoHandleMark. Thread in _thread_in_native cannot create handles so > 293: // this is used when transitioning via. ThreadInVMfromNative. nit typo: s/via./via/ ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1846 From dcubed at openjdk.java.net Wed Jan 6 17:19:05 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 6 Jan 2021 17:19:05 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions [v2] In-Reply-To: References: Message-ID: <-LGK3K5olIonhOHBLuLDHnIwJQNItZIZVTwBdkcIDns=.bf412629-73da-478b-b037-eeb5b9ec6a23@github.com> On Tue, 5 Jan 2021 14:37:53 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 353: >> >>> 351: #define VM_LEAF_BASE(result_type, header) \ >>> 352: TRACE_CALL(result_type, header) \ >>> 353: debug_only(NoHandleMark __hm;) \ >> >> Shouldn't `NoSafepointVerifier` be added here and then it can be removed from `JRT_LEAF`? > > I don't want a NoSafepointVerifier in JNI_LEAF, and the equivalent fromNative JVM_LEAF, which "calls" this. I only want it in JRT_LEAF. JNI_LEAF isn't really a leaf, it often calls JNI functions that transition to the VM. Do you want to file a cleanup bug to rename JNI_LEAF to something more appropriate? ------------- PR: https://git.openjdk.java.net/jdk/pull/1846 From psandoz at openjdk.java.net Wed Jan 6 17:20:55 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 6 Jan 2021 17:20:55 GMT Subject: RFR: 8259278: Optimize Vector API slice and unslice operations In-Reply-To: <0Hoxshsrh_L881MMdvplGZIUjkrtXwQcOqnOKtNAQqE=.fe0063e1-3234-44dd-884b-c92bf4d3ed5d@github.com> References: <0Hoxshsrh_L881MMdvplGZIUjkrtXwQcOqnOKtNAQqE=.fe0063e1-3234-44dd-884b-c92bf4d3ed5d@github.com> Message-ID: On Tue, 5 Jan 2021 22:59:29 GMT, Sandhya Viswanathan wrote: > This pull request optimizes Vector API slice and unslice operations. > All the slice and unslice variants that take more than one argument are implemented in terms of already intrinsic methods on similar lines as slice(origin) and unslice(origin). > Also, the slice and unslice intrinsics for 256-bit byte/short vectors implemented for x86 platforms supporting AVX2 using a sequence of instructions. > > For TestSlice.java attached to JBS (https://bugs.openjdk.java.net/browse/JDK-8259278): > Before: > Benchmark (size) Mode Cnt Score Error Units > TestSlice.vectorSliceOrigin 1024 thrpt 5 17.665 ? 0.980 ops/ms > TestSlice.vectorSliceOriginVector 1024 thrpt 5 604.179 ? 5.795 ops/ms > TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 9.286 ? 0.088 ops/ms > TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 435.678 ? 30.171 ops/ms > TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 440.492 ? 24.592 ops/ms > > After: > Benchmark (size) Mode Cnt Score Error Units > TestSlice.vectorSliceOrigin 1024 thrpt 5 1319.044 ? 67.862 ops/ms > TestSlice.vectorSliceOriginVector 1024 thrpt 5 969.514 ? 33.411 ops/ms > TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 687.804 ? 31.511 ops/ms > TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 560.807 ? 20.600 ops/ms > TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 560.202 ? 4.012 ops/ms > > Please review. > > Best Regards, > Sandhya The following bounds check can be replaced with Objects.checkIndex: if ((origin < 0) || (origin >= VLENGTH)) { throw new ArrayIndexOutOfBoundsException("Index " + origin + " out of bounds for vector length " + VLENGTH); } In general, I am wondering why the code for the slice/unslice implementations cannot refer to template code of the abstract super class, thereby avoiding much duplication. ------------- PR: https://git.openjdk.java.net/jdk/pull/1950 From coleenp at openjdk.java.net Wed Jan 6 17:56:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Jan 2021 17:56:10 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions [v2] In-Reply-To: <6J9CKtxCHQwK2ze6tQBZ6jD9QnFP9k_mP1TFuXPRySE=.7afe7ad5-97cd-4410-beab-c5199427c8bc@github.com> References: <6J9CKtxCHQwK2ze6tQBZ6jD9QnFP9k_mP1TFuXPRySE=.7afe7ad5-97cd-4410-beab-c5199427c8bc@github.com> Message-ID: On Wed, 6 Jan 2021 16:53:55 GMT, Daniel D. Daugherty wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyrights. > > src/hotspot/share/runtime/deoptimization.cpp line 153: > >> 151: >> 152: // In order to make fetch_unroll_info work properly with escape >> 153: // analysis, The method was changed from JRT_LEAF to JRT_BLOCK_ENTRY. > > nit - typo (not yours): s/, The/, the/ I fixed this and noticed that just under it is a comment that is now false with this change, so deleted it too. > src/hotspot/share/runtime/handles.hpp line 292: > >> 290: >> 291: // ResetNoHandleMark is called in a context where there is an enclosing >> 292: // NoHandleMark. Thread in _thread_in_native cannot create handles so > > Perhaps: > // NoHandleMark. A thread in _thread_in_native must not create handles so Ok, "must not" is better since it's more strict. > src/hotspot/share/runtime/handles.hpp line 293: > >> 291: // ResetNoHandleMark is called in a context where there is an enclosing >> 292: // NoHandleMark. Thread in _thread_in_native cannot create handles so >> 293: // this is used when transitioning via. ThreadInVMfromNative. > > nit typo: s/via./via/ ok ------------- PR: https://git.openjdk.java.net/jdk/pull/1846 From coleenp at openjdk.java.net Wed Jan 6 18:08:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Jan 2021 18:08:05 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions [v2] In-Reply-To: <6J9CKtxCHQwK2ze6tQBZ6jD9QnFP9k_mP1TFuXPRySE=.7afe7ad5-97cd-4410-beab-c5199427c8bc@github.com> References: <6J9CKtxCHQwK2ze6tQBZ6jD9QnFP9k_mP1TFuXPRySE=.7afe7ad5-97cd-4410-beab-c5199427c8bc@github.com> Message-ID: On Wed, 6 Jan 2021 16:40:17 GMT, Daniel D. Daugherty wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyrights. > > src/hotspot/share/c1/c1_Runtime1.cpp line 647: > >> 645: address pc = thread->exception_pc(); >> 646: // Still in Java mode >> 647: nmethod* nm = NULL; > > You are definitely going to want a C1 cognizant person to > review the changes in this file. The baseline's use of > ResetNoHandleMark and NoHandleMark in this file is an > absolute mess. > > I don't understand the reason for old L647 here and for > old L652 below. Double ResetNoHandleMarks, but why? > I see no reason for old L647 so glad that it's gone! These ResetNoHandleMarks have been there since before mercurial. I don't see any reason for the ResetNoHandleMark here historically either, since there isn't a NoHandleMark outside this call. ------------- PR: https://git.openjdk.java.net/jdk/pull/1846 From coleenp at openjdk.java.net Wed Jan 6 18:39:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Jan 2021 18:39:07 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions [v2] In-Reply-To: <6J9CKtxCHQwK2ze6tQBZ6jD9QnFP9k_mP1TFuXPRySE=.7afe7ad5-97cd-4410-beab-c5199427c8bc@github.com> References: <6J9CKtxCHQwK2ze6tQBZ6jD9QnFP9k_mP1TFuXPRySE=.7afe7ad5-97cd-4410-beab-c5199427c8bc@github.com> Message-ID: On Wed, 6 Jan 2021 16:44:41 GMT, Daniel D. Daugherty wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyrights. > > src/hotspot/share/c1/c1_Runtime1.cpp line 1311: > >> 1309: patch_code(thread, load_klass_patching_id); >> 1310: >> 1311: // Back in JAVA, use no oops DON'T safepoint > > The baseline here is even more confused. > debug_only NoHandleMark here on old L1311 > and a ResetNoHandleMark on old L1315. > I see no reason for old L1311 so glad that it's gone! Same here. It was never a JRT_LEAF, which would have necessitated a ResetNoHandleMark. It was a JRT_ENTRY at one point and then was made a direct call from _thread_in_Java code. That's when the ResetNoHandleMark was added, assuming that even without the NoHandleMark from JRT_LEAF, it was a bad to have Handles when the thread state is in Java. This is the restriction that this patch removes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1846 From hseigel at openjdk.java.net Wed Jan 6 19:15:03 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 6 Jan 2021 19:15:03 GMT Subject: RFR: 8259317: Remove JVM option BreakAtWarning Message-ID: Please review this trivial change to remove the old JVM develop BreakAtWarning flag. The change was tested with Mach5 tiers 1-3 on Linux, Windows, and Mac OS. Thanks, Harold ------------- Commit messages: - 8259317: Remove JVM option BreakAtWarning Changes: https://git.openjdk.java.net/jdk/pull/1966/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1966&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259317 Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1966.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1966/head:pull/1966 PR: https://git.openjdk.java.net/jdk/pull/1966 From coleenp at openjdk.java.net Wed Jan 6 20:03:04 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Jan 2021 20:03:04 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions [v2] In-Reply-To: <6J9CKtxCHQwK2ze6tQBZ6jD9QnFP9k_mP1TFuXPRySE=.7afe7ad5-97cd-4410-beab-c5199427c8bc@github.com> References: <6J9CKtxCHQwK2ze6tQBZ6jD9QnFP9k_mP1TFuXPRySE=.7afe7ad5-97cd-4410-beab-c5199427c8bc@github.com> Message-ID: On Wed, 6 Jan 2021 17:16:39 GMT, Daniel D. Daugherty wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyrights. > > So these changes boil down to: > - remove ResetNoHandleMark and NoHandleMark helpers in favor of having them in the appropriate interfaceSupport.inline.hpp macros and helpers > - ThreadInVMfromNative now has a ResetNoHandleMark helper > - VM_LEAF_BASE no longer needs a NoHandleMark helper > - VM_ENTRY_BASE_FROM_LEAF no longer needs a ResetNoHandleMark helper > - JNI_LEAF now has a NoHandleMark helper > - JVM_LEAF now has a NoHandleMark helper > - JVM_ENTRY_FROM_LEAF now has a ResetNoHandleMark helper > > Okay, I think I grok these changes and they look good to me. > I would like to see Tier7 and Tier8 testing done since longer > stress runs are done in those tiers. Answering Dan's questions made me realize that the compiler runtime changes are incorrect. There were some runtime functions that were made to not have transitions from Java, but then call some function that has a JRT_ENTRY. The JRT_ENTRY has a HandleMarkCleaner which resets the handlers to where the Java code is called (just before call_stub in javaCalls.cpp) so if you create a Handle in these special non-transitioning functions, they?ll get wiped out by the JRT_ENTRY and not collected. So the pattern in the code like this makes sense (except two instances that has a ResetNoHandleMark rather than NoHandleMark). NoHandleMark nhm; // any handles created here and used after the function call to // handle_exception_C_helper will be wiped out by the HandleMarkCleaner in the JRT_ENTRY. { // Enter the VM ResetNoHandleMark rnhm; handler_address = handle_exception_C_helper(thread, nm); } I messed up my git repo trying to revert files, so I'm withdrawing this PR for now. Thanks for your attention, Dan! ------------- PR: https://git.openjdk.java.net/jdk/pull/1846 From coleenp at openjdk.java.net Wed Jan 6 20:03:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Jan 2021 20:03:05 GMT Subject: Withdrawn: 8258032: Reconsider LEAF entry restrictions In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 19:38:09 GMT, Coleen Phillimore wrote: > This change allows JRT_LEAF functions to create Handles because it doesn't need them but some code inside the VM needs Handles. There's a NoSafepointVerifier in JRT_LEAF functions. > The JNI_LEAF and JVM_LEAF functions have NoHandleMark (so you can't create handles) but the transition ThreadInVMfromNative will reenable the HandleMarks, so that all this code doesn't have to do it itself. > Tested with tier1-6. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1846 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 lfoltan at openjdk.java.net Wed Jan 6 20:25:56 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 6 Jan 2021 20:25:56 GMT Subject: RFR: 8259317: Remove JVM option BreakAtWarning In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 19:10:08 GMT, Harold Seigel wrote: > Please review this trivial change to remove the old JVM develop BreakAtWarning flag. > > The change was tested with Mach5 tiers 1-3 on Linux, Windows, and Mac OS. > > Thanks, Harold LGTM. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1966 From coleenp at openjdk.java.net Wed Jan 6 21:00:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Jan 2021 21:00:56 GMT Subject: RFR: 8259317: Remove JVM option BreakAtWarning In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 19:10:08 GMT, Harold Seigel wrote: > Please review this trivial change to remove the old JVM develop BreakAtWarning flag. > > The change was tested with Mach5 tiers 1-3 on Linux, Windows, and Mac OS. > > Thanks, Harold Looks trivial too. Thanks! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1966 From dholmes at openjdk.java.net Wed Jan 6 22:11:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 6 Jan 2021 22:11:56 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v3] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 00:18:19 GMT, Coleen Phillimore wrote: >> See CR for details. >> I made the classpath append list lock-free. Calling experts in Atomic operations... >> Tested with tier1-6. >> Thanks, >> Coleen > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Move locking into function where exclusive access is needed. Hi Coleen, Just a quick skim, but I think you need acquire/release for the lock-free path. Thanks, David src/hotspot/share/classfile/classLoader.cpp line 837: > 835: _last_append_entry = new_entry; > 836: assert(first_append_entry() == NULL, "boot loader's append class path entry list not empty"); > 837: Atomic::store(&_first_append_entry_list, new_entry); This should probably be `OrderAccess::release_store`. src/hotspot/share/classfile/classLoader.hpp line 220: > 218: static ClassPathEntry* volatile _first_append_entry_list; > 219: static ClassPathEntry* first_append_entry() { > 220: return Atomic::load(&_first_append_entry_list); This should probably be a load_acquire. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1935 From coleenp at openjdk.java.net Wed Jan 6 23:21:58 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Jan 2021 23:21:58 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v3] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 22:06:33 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Move locking into function where exclusive access is needed. > > src/hotspot/share/classfile/classLoader.cpp line 837: > >> 835: _last_append_entry = new_entry; >> 836: assert(first_append_entry() == NULL, "boot loader's append class path entry list not empty"); >> 837: Atomic::store(&_first_append_entry_list, new_entry); > > This should probably be `OrderAccess::release_store`. Ok, thanks. > src/hotspot/share/classfile/classLoader.hpp line 220: > >> 218: static ClassPathEntry* volatile _first_append_entry_list; >> 219: static ClassPathEntry* first_append_entry() { >> 220: return Atomic::load(&_first_append_entry_list); > > This should probably be a load_acquire. Okay, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1935 From coleenp at openjdk.java.net Thu Jan 7 00:04:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 00:04:07 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v4] In-Reply-To: References: Message-ID: <35mTJA1WnJtINemvH31Htg3tFdqyDDp-_JRpH5hEsdQ=.5d60ea5c-22e0-49d6-b130-be93125a9c08@github.com> > See CR for details. > I made the classpath append list lock-free. Calling experts in Atomic operations... > Tested with tier1-6. > Thanks, > Coleen Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Use acquire/release for first_append_entry_list ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1935/files - new: https://git.openjdk.java.net/jdk/pull/1935/files/9b250606..1e7251b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1935&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1935&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1935.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1935/head:pull/1935 PR: https://git.openjdk.java.net/jdk/pull/1935 From sviswanathan at openjdk.java.net Thu Jan 7 00:33:13 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 7 Jan 2021 00:33:13 GMT Subject: RFR: 8259278: Optimize Vector API slice and unslice operations [v2] In-Reply-To: <0Hoxshsrh_L881MMdvplGZIUjkrtXwQcOqnOKtNAQqE=.fe0063e1-3234-44dd-884b-c92bf4d3ed5d@github.com> References: <0Hoxshsrh_L881MMdvplGZIUjkrtXwQcOqnOKtNAQqE=.fe0063e1-3234-44dd-884b-c92bf4d3ed5d@github.com> Message-ID: > This pull request optimizes Vector API slice and unslice operations. > All the slice and unslice variants that take more than one argument are implemented in terms of already intrinsic methods on similar lines as slice(origin) and unslice(origin). > Also, the slice and unslice intrinsics for 256-bit byte/short vectors implemented for x86 platforms supporting AVX2 using a sequence of instructions. > > For TestSlice.java attached to JBS (https://bugs.openjdk.java.net/browse/JDK-8259278): > Before: > Benchmark (size) Mode Cnt Score Error Units > TestSlice.vectorSliceOrigin 1024 thrpt 5 17.665 ? 0.980 ops/ms > TestSlice.vectorSliceOriginVector 1024 thrpt 5 604.179 ? 5.795 ops/ms > TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 9.286 ? 0.088 ops/ms > TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 435.678 ? 30.171 ops/ms > TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 440.492 ? 24.592 ops/ms > > After: > Benchmark (size) Mode Cnt Score Error Units > TestSlice.vectorSliceOrigin 1024 thrpt 5 1319.044 ? 67.862 ops/ms > TestSlice.vectorSliceOriginVector 1024 thrpt 5 969.514 ? 33.411 ops/ms > TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 687.804 ? 31.511 ops/ms > TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 560.807 ? 20.600 ops/ms > TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 560.202 ? 4.012 ops/ms > > Please review. > > Best Regards, > Sandhya Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Use Objects.checkIndex and move code to xxxVector.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1950/files - new: https://git.openjdk.java.net/jdk/pull/1950/files/1c2c6a4e..8fd967e1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1950&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1950&range=00-01 Stats: 1401 lines in 38 files changed: 364 ins; 899 del; 138 mod Patch: https://git.openjdk.java.net/jdk/pull/1950.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1950/head:pull/1950 PR: https://git.openjdk.java.net/jdk/pull/1950 From sviswanathan at openjdk.java.net Thu Jan 7 00:33:13 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 7 Jan 2021 00:33:13 GMT Subject: RFR: 8259278: Optimize Vector API slice and unslice operations [v2] In-Reply-To: References: <0Hoxshsrh_L881MMdvplGZIUjkrtXwQcOqnOKtNAQqE=.fe0063e1-3234-44dd-884b-c92bf4d3ed5d@github.com> Message-ID: <1A8_jV6Tq3wi5hALSGVjCjXWIo_em-sIH-kAjNwLg08=.0b3ca33a-5edd-4e65-9315-a483913ba810@github.com> On Wed, 6 Jan 2021 17:18:14 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Objects.checkIndex and move code to xxxVector.java > > The following bounds check can be replaced with Objects.checkIndex: > if ((origin < 0) || (origin >= VLENGTH)) { > throw new ArrayIndexOutOfBoundsException("Index " + origin + " out of bounds for vector length " + VLENGTH); > } > > In general, I am wondering why the code for the slice/unslice implementations cannot refer to template code of the abstract super class, thereby avoiding much duplication. @PaulSandoz Thanks a lot for the review. I have implemented both the changes you suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/1950 From dongbo at openjdk.java.net Thu Jan 7 01:53:59 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Thu, 7 Jan 2021 01:53:59 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v2] In-Reply-To: References: Message-ID: <1uesqHOGE6FbsMN6jcbfiVWT1nYVFpfBqXfrBMTwCIk=.b94cc813-e88f-4cf0-9fe4-474e0911b01d@github.com> On Tue, 5 Jan 2021 11:19:08 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> rebase the .m4 entry > > This all looks reasonable. With the assembler change I think we should be good to go. @theRealAph Hi, is there any further suggestions? :) ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From psandoz at openjdk.java.net Thu Jan 7 02:42:56 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 7 Jan 2021 02:42:56 GMT Subject: RFR: 8259278: Optimize Vector API slice and unslice operations [v2] In-Reply-To: References: <0Hoxshsrh_L881MMdvplGZIUjkrtXwQcOqnOKtNAQqE=.fe0063e1-3234-44dd-884b-c92bf4d3ed5d@github.com> Message-ID: On Thu, 7 Jan 2021 00:33:13 GMT, Sandhya Viswanathan wrote: >> This pull request optimizes Vector API slice and unslice operations. >> All the slice and unslice variants that take more than one argument are implemented in terms of already intrinsic methods on similar lines as slice(origin) and unslice(origin). >> Also, the slice and unslice intrinsics for 256-bit byte/short vectors implemented for x86 platforms supporting AVX2 using a sequence of instructions. >> >> For TestSlice.java attached to JBS (https://bugs.openjdk.java.net/browse/JDK-8259278): >> Before: >> Benchmark (size) Mode Cnt Score Error Units >> TestSlice.vectorSliceOrigin 1024 thrpt 5 17.665 ? 0.980 ops/ms >> TestSlice.vectorSliceOriginVector 1024 thrpt 5 604.179 ? 5.795 ops/ms >> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 9.286 ? 0.088 ops/ms >> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 435.678 ? 30.171 ops/ms >> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 440.492 ? 24.592 ops/ms >> >> After: >> Benchmark (size) Mode Cnt Score Error Units >> TestSlice.vectorSliceOrigin 1024 thrpt 5 1319.044 ? 67.862 ops/ms >> TestSlice.vectorSliceOriginVector 1024 thrpt 5 969.514 ? 33.411 ops/ms >> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 687.804 ? 31.511 ops/ms >> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 560.807 ? 20.600 ops/ms >> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 560.202 ? 4.012 ops/ms >> >> Please review. >> >> Best Regards, >> Sandhya > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Use Objects.checkIndex and move code to xxxVector.java Code changes to Java source looks good. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1950 From dholmes at openjdk.java.net Thu Jan 7 02:48:57 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 7 Jan 2021 02:48:57 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v4] In-Reply-To: <35mTJA1WnJtINemvH31Htg3tFdqyDDp-_JRpH5hEsdQ=.5d60ea5c-22e0-49d6-b130-be93125a9c08@github.com> References: <35mTJA1WnJtINemvH31Htg3tFdqyDDp-_JRpH5hEsdQ=.5d60ea5c-22e0-49d6-b130-be93125a9c08@github.com> Message-ID: <5s85OUZUDAcIYJ6N5-JSTB6Q5ij88JNLwK5QblnfNoM=.819f13c5-2b55-4b83-b977-0945d1dd6e48@github.com> On Thu, 7 Jan 2021 00:04:07 GMT, Coleen Phillimore wrote: >> See CR for details. >> I made the classpath append list lock-free. Calling experts in Atomic operations... >> Tested with tier1-6. >> Thanks, >> Coleen > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use acquire/release for first_append_entry_list Addition of release/acquire looks good. Note that we now update _first_append_entry with the same release semantics as ClassPathEntry::set_next - as we should in general. I'm not 100% clear on which part of these API's can only be called whilst the VM is still single-threaded, but ignoring that, the change to use locked updates with lock-free traversal seems functionally correct. The overall necessity of using locking does depend on the potential for concurrent calls to ClassLoader::add_to_boot_append_entries - something I have not investigated at all. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1935 From pli at openjdk.java.net Thu Jan 7 03:06:57 2021 From: pli at openjdk.java.net (Pengfei Li) Date: Thu, 7 Jan 2021 03:06:57 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 13:42:21 GMT, Dong Bo wrote: >> This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. >> >> Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. >> Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. >> >> Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. >> Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: >> Benchmark (COUNT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op >> VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op >> VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op >> VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op >> >> # Kunpeng 916, with fmaxp/fminp >> VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% >> VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op >> VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% >> VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op > > Dong Bo has updated the pull request incrementally with one additional commit since the last revision: > > put faddp/fmaxp/fminp together in a group test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java line 2: > 1: /* > 2: * Copyright (c) 2021, Huawei Technologies Co., Ltd. All rights reserved. Should each new source file also include Oracle copyright? ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From coleenp at openjdk.java.net Thu Jan 7 03:11:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 03:11:56 GMT Subject: RFR: 8259067: bootclasspath append takes out object lock [v4] In-Reply-To: <5s85OUZUDAcIYJ6N5-JSTB6Q5ij88JNLwK5QblnfNoM=.819f13c5-2b55-4b83-b977-0945d1dd6e48@github.com> References: <35mTJA1WnJtINemvH31Htg3tFdqyDDp-_JRpH5hEsdQ=.5d60ea5c-22e0-49d6-b130-be93125a9c08@github.com> <5s85OUZUDAcIYJ6N5-JSTB6Q5ij88JNLwK5QblnfNoM=.819f13c5-2b55-4b83-b977-0945d1dd6e48@github.com> Message-ID: <60diwQZMHAdKdljiMIWJI9nX0d5iIJVfJ9kpWm64YIM=.5d1ba205-c3df-4e10-9ba6-0de99398a97a@github.com> On Thu, 7 Jan 2021 02:45:48 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Use acquire/release for first_append_entry_list > > Addition of release/acquire looks good. Note that we now update _first_append_entry with the same release semantics as ClassPathEntry::set_next - as we should in general. > > I'm not 100% clear on which part of these API's can only be called whilst the VM is still single-threaded, but ignoring that, the change to use locked updates with lock-free traversal seems functionally correct. The overall necessity of using locking does depend on the potential for concurrent calls to ClassLoader::add_to_boot_append_entries - something I have not investigated at all. > > Thanks, > David Thanks for reviewing this, David. The concurrent calls are from JVMTI where the lock was originally, but as suggested by Serguei, for safety, and to avoid tracing through all the callers, I moved the locking to the function where we write the list. It's not a performance critical operation. ------------- PR: https://git.openjdk.java.net/jdk/pull/1935 From dongbo at openjdk.java.net Thu Jan 7 03:29:12 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Thu, 7 Jan 2021 03:29:12 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v4] In-Reply-To: References: Message-ID: > This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. > > Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. > Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. > > Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. > Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op > VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op > VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op > VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op > > # Kunpeng 916, with fmaxp/fminp > VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% > VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op > VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% > VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: include Oracle copyright in VectorReductionFloatingMinMax.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1925/files - new: https://git.openjdk.java.net/jdk/pull/1925/files/c0c6f51f..96dc92f8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1925/head:pull/1925 PR: https://git.openjdk.java.net/jdk/pull/1925 From dongbo at openjdk.java.net Thu Jan 7 03:31:58 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Thu, 7 Jan 2021 03:31:58 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 03:03:31 GMT, Pengfei Li wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> put faddp/fmaxp/fminp together in a group > > test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java line 2: > >> 1: /* >> 2: * Copyright (c) 2021, Huawei Technologies Co., Ltd. All rights reserved. > > Should each new source file also include Oracle copyright? Fixed, thank you for mentioning this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From jiefu at openjdk.java.net Thu Jan 7 03:55:56 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 7 Jan 2021 03:55:56 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 03:29:34 GMT, Dong Bo wrote: >> test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2021, Huawei Technologies Co., Ltd. All rights reserved. >> >> Should each new source file also include Oracle copyright? > > Fixed, thank you for mentioning this. > Should each new source file also include Oracle copyright? I'm not sure. But there are already some files which don't contain Oracle copyright. @dholmes-ora , what do you think of this question? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From sviswanathan at openjdk.java.net Thu Jan 7 04:49:55 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 7 Jan 2021 04:49:55 GMT Subject: RFR: 8259278: Optimize Vector API slice and unslice operations [v2] In-Reply-To: References: <0Hoxshsrh_L881MMdvplGZIUjkrtXwQcOqnOKtNAQqE=.fe0063e1-3234-44dd-884b-c92bf4d3ed5d@github.com> Message-ID: On Thu, 7 Jan 2021 02:40:37 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Objects.checkIndex and move code to xxxVector.java > > Code changes to Java source looks good. Thanks a lot @PaulSandoz for the review. @iwanowww Looking forward to your review comments on this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/1950 From aph at openjdk.java.net Thu Jan 7 11:21:57 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 7 Jan 2021 11:21:57 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 13:42:21 GMT, Dong Bo wrote: >> This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. >> >> Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. >> Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. >> >> Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. >> Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: >> Benchmark (COUNT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op >> VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op >> VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op >> VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op >> >> # Kunpeng 916, with fmaxp/fminp >> VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% >> VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op >> VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% >> VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op > > Dong Bo has updated the pull request incrementally with one additional commit since the last revision: > > put faddp/fmaxp/fminp together in a group Changes requested by aph (Reviewer). test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java line 67: > 65: for (int i = 0; i < COUNT; i++) { > 66: max = Math.max(max, floatsA[i] - floatsB[i]); > 67: } This test code looks a bit contrived. If you're looking for the smallest delta it'd be Math.max(max, Math.abs(floatsA[i] - floatsB[i])); and if you're looking for the smallest value it'd probably be Math.max(max, floatsA[i]); Do we gain any advantage with these? ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From coleenp at openjdk.java.net Thu Jan 7 12:37:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 12:37:55 GMT Subject: Integrated: 8259067: bootclasspath append takes out object lock In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 17:28:30 GMT, Coleen Phillimore wrote: > See CR for details. > I made the classpath append list lock-free. Calling experts in Atomic operations... > Tested with tier1-6. > Thanks, > Coleen This pull request has now been integrated. Changeset: 1c33847b Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/1c33847b Stats: 39 lines in 6 files changed: 13 ins; 7 del; 19 mod 8259067: bootclasspath append takes out object lock Reviewed-by: lfoltan, sspitsyn, iklam, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1935 From hseigel at openjdk.java.net Thu Jan 7 13:21:53 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 7 Jan 2021 13:21:53 GMT Subject: RFR: 8259317: Remove JVM option BreakAtWarning In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 20:57:41 GMT, Coleen Phillimore wrote: >> Please review this trivial change to remove the old JVM develop BreakAtWarning flag. >> >> The change was tested with Mach5 tiers 1-3 on Linux, Windows, and Mac OS. >> >> Thanks, Harold > > Looks trivial too. Thanks! Thanks Lois and Coleen for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/1966 From hseigel at openjdk.java.net Thu Jan 7 13:21:54 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 7 Jan 2021 13:21:54 GMT Subject: Integrated: 8259317: Remove JVM option BreakAtWarning In-Reply-To: References: Message-ID: <-uQAy_tCV8yzuVg3dcwjU_FbA3bDwl4xEc9kGPEbFoA=.6950a612-89d7-4fb8-abd1-6d95e526972c@github.com> On Wed, 6 Jan 2021 19:10:08 GMT, Harold Seigel wrote: > Please review this trivial change to remove the old JVM develop BreakAtWarning flag. > > The change was tested with Mach5 tiers 1-3 on Linux, Windows, and Mac OS. > > Thanks, Harold This pull request has now been integrated. Changeset: f91f92dc Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/f91f92dc Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod 8259317: Remove JVM option BreakAtWarning Reviewed-by: lfoltan, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1966 From shade at openjdk.java.net Thu Jan 7 14:02:12 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 7 Jan 2021 14:02:12 GMT Subject: RFR: 8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp Message-ID: As noted in the bug report, there are places in `vmError.cpp`, where information on compressed classes is only printed if compressed oops are enabled. After JDK-8241825 both features should be independent. In addition to 2 reported places, we also need to print the setting in JVM modeline. Sample outputs: Command Line: Crash ... # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.shade.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) ... VM Mutex/Monitor currently owned by a thread: None Heap address: 0x0000000082000000, size: 30688 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 CDS archive(s) mapped at: [0x0000000800000000-0x0000000800c5c000-0x0000000800c5c000), size 12959744, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. Compressed class space mapped at: 0x0000000801000000-0x0000000841000000, reserved size: 1073741824 Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 GC Precious Log: Command Line: -XX:-UseCompressedOops Crash ... # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.shade.jdk, mixed mode, sharing, tiered, compressed class ptrs, g1 gc, linux-amd64) ... VM Mutex/Monitor currently owned by a thread: None CDS archive(s) mapped at: [0x0000000800000000-0x0000000800c2f000-0x0000000800c2f000), size 12775424, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. Compressed class space mapped at: 0x0000000801000000-0x0000000841000000, reserved size: 1073741824 Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 GC Precious Log: ... Command Line: -XX:-UseCompressedOops -XX:-UseCompressedClassPointers Crash ... # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.shade.jdk, mixed mode, tiered, g1 gc, linux-amd64) ... VM Mutex/Monitor currently owned by a thread: None GC Precious Log: ... ------------- Commit messages: - 8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp Changes: https://git.openjdk.java.net/jdk/pull/1974/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1974&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253910 Stats: 19 lines in 1 file changed: 8 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1974.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1974/head:pull/1974 PR: https://git.openjdk.java.net/jdk/pull/1974 From rrich at openjdk.java.net Thu Jan 7 14:32:56 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 7 Jan 2021 14:32:56 GMT Subject: RFR: 8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 13:54:25 GMT, Aleksey Shipilev wrote: > As noted in the bug report, there are places in `vmError.cpp`, where information on compressed classes is only printed if compressed oops are enabled. After JDK-8241825 both features should be independent. In addition to 2 reported places, we also need to print the setting in JVM modeline. > > Sample outputs: > > Command Line: Crash > ... > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.shade.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > ... > VM Mutex/Monitor currently owned by a thread: None > > Heap address: 0x0000000082000000, size: 30688 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 > > CDS archive(s) mapped at: [0x0000000800000000-0x0000000800c5c000-0x0000000800c5c000), size 12959744, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. > Compressed class space mapped at: 0x0000000801000000-0x0000000841000000, reserved size: 1073741824 > Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 > > GC Precious Log: > > Command Line: -XX:-UseCompressedOops Crash > ... > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.shade.jdk, mixed mode, sharing, tiered, compressed class ptrs, g1 gc, linux-amd64) > ... > VM Mutex/Monitor currently owned by a thread: None > > CDS archive(s) mapped at: [0x0000000800000000-0x0000000800c2f000-0x0000000800c2f000), size 12775424, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. > Compressed class space mapped at: 0x0000000801000000-0x0000000841000000, reserved size: 1073741824 > Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 > > GC Precious Log: > ... > > Command Line: -XX:-UseCompressedOops -XX:-UseCompressedClassPointers Crash > ... > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.shade.jdk, mixed mode, tiered, g1 gc, linux-amd64) > ... > VM Mutex/Monitor currently owned by a thread: None > > GC Precious Log: > ... The change looks good to me. Thanks for fixing. ------------- Marked as reviewed by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/1974 From coleenp at openjdk.java.net Thu Jan 7 16:10:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 16:10:07 GMT Subject: RFR: 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark Message-ID: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> This is a trivial change to remove the comments and the ResetNoHandleMark from jvmti functions. They're called by JNI_ENTRY so they don't have a NoHandleMark that needs to be reset. It may not have always been the case. Tested with the other patch for https://bugs.openjdk.java.net/browse/JDK-8258032 and retesting with tier1-3. ------------- Commit messages: - 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark Changes: https://git.openjdk.java.net/jdk/pull/1975/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1975&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259375 Stats: 18 lines in 2 files changed: 0 ins; 14 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1975.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1975/head:pull/1975 PR: https://git.openjdk.java.net/jdk/pull/1975 From coleenp at openjdk.java.net Thu Jan 7 16:21:59 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 16:21:59 GMT Subject: RFR: 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark In-Reply-To: References: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> Message-ID: <4wrJvMf3kPtPWgN0hKZXnfroN4k8ahcp10wi36AfUkM=.53915674-f6b6-43b4-b3bb-9b397489dec0@github.com> On Thu, 7 Jan 2021 16:17:31 GMT, Lois Foltan wrote: >> This is a trivial change to remove the comments and the ResetNoHandleMark from jvmti functions. They're called by JNI_ENTRY so they don't have a NoHandleMark that needs to be reset. It may not have always been the case. >> Tested with the other patch for https://bugs.openjdk.java.net/browse/JDK-8258032 and retesting with tier1-3. > > Looks good & trivial. Thanks Lois! ------------- PR: https://git.openjdk.java.net/jdk/pull/1975 From lfoltan at openjdk.java.net Thu Jan 7 16:21:59 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 7 Jan 2021 16:21:59 GMT Subject: RFR: 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark In-Reply-To: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> References: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> Message-ID: On Thu, 7 Jan 2021 16:04:28 GMT, Coleen Phillimore wrote: > This is a trivial change to remove the comments and the ResetNoHandleMark from jvmti functions. They're called by JNI_ENTRY so they don't have a NoHandleMark that needs to be reset. It may not have always been the case. > Tested with the other patch for https://bugs.openjdk.java.net/browse/JDK-8258032 and retesting with tier1-3. Looks good & trivial. ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1975 From mbaesken at openjdk.java.net Thu Jan 7 16:26:13 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 7 Jan 2021 16:26:13 GMT Subject: RFR: JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling Message-ID: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> AIX 5.3 had buggy __thread support (see JDK-8176442). That's why we introduced a macro USE_LIBRARY_BASED_TLS_ONLY and set it only to 1 on AIX (different to the other platforms supported by the OpenJDK). However AIX 5.3 support was removed some time ago (currently we have a minimum requirement of AIX 7.X ) so the whole USE_LIBRARY_BASED_TLS_ONLY related coding could be removed. ------------- Commit messages: - JDK-8259372 Changes: https://git.openjdk.java.net/jdk/pull/1976/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1976&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259372 Stats: 20 lines in 3 files changed: 0 ins; 17 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1976/head:pull/1976 PR: https://git.openjdk.java.net/jdk/pull/1976 From dcubed at openjdk.java.net Thu Jan 7 17:01:55 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 7 Jan 2021 17:01:55 GMT Subject: RFR: 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark In-Reply-To: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> References: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> Message-ID: On Thu, 7 Jan 2021 16:04:28 GMT, Coleen Phillimore wrote: > This is a trivial change to remove the comments and the ResetNoHandleMark from jvmti functions. They're called by JNI_ENTRY so they don't have a NoHandleMark that needs to be reset. It may not have always been the case. > Tested with the other patch for https://bugs.openjdk.java.net/browse/JDK-8258032 and retesting with tier1-3. This appears to match what I reviewed in JDK-8258032 so this extraction from that PR looks good. I agree that this is a trivial change. Thumbs up! ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1975 From coleenp at openjdk.java.net Thu Jan 7 17:16:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 17:16:55 GMT Subject: RFR: 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark In-Reply-To: References: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> Message-ID: On Thu, 7 Jan 2021 16:59:30 GMT, Daniel D. Daugherty wrote: >> This is a trivial change to remove the comments and the ResetNoHandleMark from jvmti functions. They're called by JNI_ENTRY so they don't have a NoHandleMark that needs to be reset. It may not have always been the case. >> Tested with the other patch for https://bugs.openjdk.java.net/browse/JDK-8258032 and retesting with tier1-3. > > This appears to match what I reviewed in JDK-8258032 > so this extraction from that PR looks good. I agree that > this is a trivial change. > > Thumbs up! Yes, it is a piece of that change. Thanks for the review Dan and Lois! ------------- PR: https://git.openjdk.java.net/jdk/pull/1975 From coleenp at openjdk.java.net Thu Jan 7 17:16:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 17:16:57 GMT Subject: Integrated: 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark In-Reply-To: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> References: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> Message-ID: On Thu, 7 Jan 2021 16:04:28 GMT, Coleen Phillimore wrote: > This is a trivial change to remove the comments and the ResetNoHandleMark from jvmti functions. They're called by JNI_ENTRY so they don't have a NoHandleMark that needs to be reset. It may not have always been the case. > Tested with the other patch for https://bugs.openjdk.java.net/browse/JDK-8258032 and retesting with tier1-3. This pull request has now been integrated. Changeset: 8530ef0e Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/8530ef0e Stats: 18 lines in 2 files changed: 0 ins; 14 del; 4 mod 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark Reviewed-by: lfoltan, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/1975 From coleenp at openjdk.java.net Thu Jan 7 18:34:04 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 18:34:04 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark Message-ID: Please review this straightforward change to add a ResetNoHandleMark in the ThreadInVMfromNative transition class so that callers don't have to do this. Tested with tier1-3. This was broken out of a larger change for JDK-8258032 Reconsider LEAF entry restrictions. ------------- Commit messages: - 8259374: Make ThreadInVMfromNative have ResetNoHandleMark Changes: https://git.openjdk.java.net/jdk/pull/1983/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1983&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259374 Stats: 18 lines in 7 files changed: 4 ins; 8 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1983.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1983/head:pull/1983 PR: https://git.openjdk.java.net/jdk/pull/1983 From hseigel at openjdk.java.net Thu Jan 7 20:08:06 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 7 Jan 2021 20:08:06 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging Message-ID: Please review this change to remove the JVM develop flag UseStackBanging and always use stack banging. The change was tested with tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and cross-builds on PPC64, Linux32, and S390x. Thanks, Harold ------------- Commit messages: - 8258838: Remove JVM option UseStackBanging Changes: https://git.openjdk.java.net/jdk/pull/1988/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1988&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258838 Stats: 213 lines in 19 files changed: 0 ins; 55 del; 158 mod Patch: https://git.openjdk.java.net/jdk/pull/1988.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1988/head:pull/1988 PR: https://git.openjdk.java.net/jdk/pull/1988 From iveresov at openjdk.java.net Thu Jan 7 20:36:07 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 7 Jan 2021 20:36:07 GMT Subject: RFR: 8251462: Remove legacy compilation policy Message-ID: This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! ------------- Commit messages: - Fix copyright years - Remove legacy compilation policy. Changes: https://git.openjdk.java.net/jdk/pull/1985/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251462 Stats: 5285 lines in 95 files changed: 1481 ins; 2979 del; 825 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 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 cjplummer at openjdk.java.net Thu Jan 7 20:54:01 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Jan 2021 20:54:01 GMT Subject: RFR: 8251462: Remove legacy compilation policy In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 18:43:51 GMT, Igor Veresov wrote: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java line 35: > 33: * While running the thread, it calls a method (doTask2() ) for number of times (10000). > 34: * That would cause this method to be compiled, which causes a jvmti callback for compiled method load. > 35: * (Hint : to force method compilation -XX:CompileThreshold=900 is used). The test still uses (and the comments state it uses) -XX:CompileThreshold=900 to force compilation, yet it looks like you needed to bump the number of times the method is called from 1000 to 10000 to keep this test working. Why doesn't 1000 still work? ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From coleenp at openjdk.java.net Thu Jan 7 21:01:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 21:01:05 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions Message-ID: Please review the smaller version of this enhancement. JRT_LEAF can allow Handles. Fixed places where a ResetNoHandleMark was added to workaround the restriction and remove some obsolete comments in deoptimization (the function is a JRT_BLOCK_ENTRY that has a HandleMarkCleaner which cleans up the HandleMark to the one before call_stub() in JavaCalls. A HandleMarkCleaner also allows HandleMark and Handles. Tested with tier1-3, 4-6 with the larger change and 7-8 in progress. ------------- Commit messages: - Remove slow_identity_hash ResetNoHandleMark - 8258032: Reconsider LEAF entry restrictions Changes: https://git.openjdk.java.net/jdk/pull/1990/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1990&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258032 Stats: 23 lines in 5 files changed: 3 ins; 16 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1990.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1990/head:pull/1990 PR: https://git.openjdk.java.net/jdk/pull/1990 From dcubed at openjdk.java.net Thu Jan 7 21:12:58 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 7 Jan 2021 21:12:58 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 18:28:54 GMT, Coleen Phillimore wrote: > Please review this straightforward change to add a ResetNoHandleMark in the ThreadInVMfromNative transition class so that callers don't have to do this. Tested with tier1-3. > This was broken out of a larger change for JDK-8258032 Reconsider LEAF entry restrictions. Extracting this from JDK-8258032 makes the changes very clear. Thumbs up! Just for the record, these changes were included in testing done for JDK-8258032 so have gone through Mach5 Tier[1-6] if I remember correctly... src/hotspot/share/runtime/handles.hpp line 292: > 290: > 291: // ResetNoHandleMark is called in a context where there is an enclosing > 292: // NoHandleMark. Thread in _thread_in_native must not create handles so nit grammar: s/Thread in/A thread in/ ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1983 From walt at drummond.us Thu Jan 7 21:18:12 2021 From: walt at drummond.us (Walt Drummond) Date: Thu, 7 Jan 2021 13:18:12 -0800 Subject: Linux signals Message-ID: Hi -- I'm chasing down some information about how the JVM interacts with signals on Linux. Specifically I need to understand if any of the Java runtime attempts to directly inspect the system stack when in a POSIX signal handler. My survey of the code doesn't seem to show any such uses, and in fact it looks like the JVM relies only on the POSIX signals API but I figured I'd ask the experts for confirmation. Thanks. --Walt 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 iveresov at openjdk.java.net Thu Jan 7 21:35:11 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 7 Jan 2021 21:35:11 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 20:50:50 GMT, Chris Plummer wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix s390 build > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java line 35: > >> 33: * While running the thread, it calls a method (doTask2() ) for number of times (10000). >> 34: * That would cause this method to be compiled, which causes a jvmti callback for compiled method load. >> 35: * (Hint : to force method compilation -XX:CompileThreshold=900 is used). > > The test still uses (and the comments state it uses) -XX:CompileThreshold=900 to force compilation, yet it looks like you needed to bump the number of times the method is called from 1000 to 10000 to keep this test working. Why doesn't 1000 still work? Tiered policy (which the -TieredCompilation emulation mode piggybacks on now) functions by doing periodic callbacks into the runtime to make policy decisions. The callback intervals are a power-of-2. So, because of the resulting rounding I cannot guarantee that the compilation will be triggered exactly at the specified threshold. Plus there are various adaptive mechanisms that I kept on even in the emulation mode that may also result in a method being compiled later than expected. To summarize, in the new world, the advisable way of triggering a compilation is to use the WB API. If that's too much effort, make sure that the method that you'd like to compile is invoked more than 2^(log2(CompileThreshold) + 1) times, plus a bit more. Very few tests actually depend on the legacy behavior, this just happens to be one of those. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Thu Jan 7 21:35:10 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 7 Jan 2021 21:35:10 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: Message-ID: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Fix s390 build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1985/files - new: https://git.openjdk.java.net/jdk/pull/1985/files/1a4c6a46..c6983a18 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From dcubed at openjdk.java.net Thu Jan 7 21:46:57 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 7 Jan 2021 21:46:57 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 20:57:00 GMT, Coleen Phillimore wrote: > Please review the smaller version of this enhancement. JRT_LEAF can allow Handles. Fixed places where a ResetNoHandleMark was added to workaround the restriction and remove some obsolete comments in deoptimization (the function is a JRT_BLOCK_ENTRY that has a HandleMarkCleaner which cleans up the HandleMark to the one before call_stub() in JavaCalls. A HandleMarkCleaner also allows HandleMark and Handles. > > Tested with tier1-3, 4-6 with the larger change and 7-8 in progress. Like the original changes, the most interesting stuff is in interfaceSupport.inline.hpp. Just to keep it clear in my head: - remove NoHandleMark helper from VM_LEAF_BASE; it gets added to JNI_LEAF and JVM_LEAF which need it; JRT_LEAF doesn't need it. - remove ResetNoHandleMark helper from VM_ENTRY_BASE_FROM_LEAF since ThreadInVMfromNative will have one with your fix for JDK-8259374. Please see my comment in JVM_ENTRY_FROM_LEAF. src/hotspot/share/gc/z/zVerify.cpp line 376: > 374: // is no safepoint to protect against, and fiddling around with exceptions. > 375: class StackWatermarkProcessingMark { > 376: HandleMark _hm; Since you're removing the ResetNoHandleMark, you should revisit the comment block for the class. The entire sentence to revisit is: // ... It is mostly // due to problems that we might want to eventually clean up inside of the // frame iteration code, such as creating random handles even though there // is no safepoint to protect against, and fiddling around with exceptions. src/hotspot/share/runtime/stackWatermark.cpp line 80: > 78: // is no safepoint to protect against, and fiddling around with exceptions. > 79: class StackWatermarkProcessingMark { > 80: HandleMark _hm; Since you're removing the ResetNoHandleMark, you should revisit the comment block for the class. The entire sentence to revisit is: // ... It is mostly // due to problems that we might want to eventually clean up inside of the // frame processing code, such as creating random handles even though there // is no safepoint to protect against, and fiddling around with exceptions. src/hotspot/share/runtime/interfaceSupport.inline.hpp line 493: > 491: ThreadInVMfromNative __tiv(thread); \ > 492: debug_only(VMNativeEntryWrapper __vew;) \ > 493: debug_only(ResetNoHandleMark __rnhm;) \ Your fix for JDK-8259374 adds a ResetNoHandleMark to ThreadInVMfromNative so new L493 isn't needed. ------------- Changes requested by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1990 From cjplummer at openjdk.java.net Thu Jan 7 21:51:59 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Jan 2021 21:51:59 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: Message-ID: <1-LylT7vEKyn34M0hmOfrMckVgNK02PaHVy19Mgc_3M=.abfaf6e0-4b16-48d7-a51d-acfe4f87c95c@github.com> On Thu, 7 Jan 2021 21:29:32 GMT, Igor Veresov wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java line 35: >> >>> 33: * While running the thread, it calls a method (doTask2() ) for number of times (10000). >>> 34: * That would cause this method to be compiled, which causes a jvmti callback for compiled method load. >>> 35: * (Hint : to force method compilation -XX:CompileThreshold=900 is used). >> >> The test still uses (and the comments state it uses) -XX:CompileThreshold=900 to force compilation, yet it looks like you needed to bump the number of times the method is called from 1000 to 10000 to keep this test working. Why doesn't 1000 still work? > > Tiered policy (which the -TieredCompilation emulation mode piggybacks on now) functions by doing periodic callbacks into the runtime to make policy decisions. The callback intervals are a power-of-2. So, because of the resulting rounding I cannot guarantee that the compilation will be triggered exactly at the specified threshold. Plus there are various adaptive mechanisms that I kept on even in the emulation mode that may also result in a method being compiled later than expected. To summarize, in the new world, the advisable way of triggering a compilation is to use the WB API. If that's too much effort, make sure that the method that you'd like to compile is invoked more than 2^(log2(CompileThreshold) + 1) times, plus a bit more. Very few tests actually depend on the legacy behavior, this just happens to be one of those. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From cjplummer at openjdk.java.net Thu Jan 7 21:51:58 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Jan 2021 21:51:58 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Thu, 7 Jan 2021 21:35:10 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Fix s390 build Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1985 From coleenp at openjdk.java.net Thu Jan 7 22:21:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 22:21:07 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: References: Message-ID: > Please review this straightforward change to add a ResetNoHandleMark in the ThreadInVMfromNative transition class so that callers don't have to do this. Tested with tier1-3. > This was broken out of a larger change for JDK-8258032 Reconsider LEAF entry restrictions. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: fix grammar ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1983/files - new: https://git.openjdk.java.net/jdk/pull/1983/files/d8114d8d..a94143e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1983&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1983&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1983.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1983/head:pull/1983 PR: https://git.openjdk.java.net/jdk/pull/1983 From coleenp at openjdk.java.net Thu Jan 7 22:21:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 22:21:08 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 21:09:46 GMT, Daniel D. Daugherty wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> fix grammar > > Extracting this from JDK-8258032 makes the changes very clear. > Thumbs up! > > Just for the record, these changes were included in testing done for JDK-8258032 > so have gone through Mach5 Tier[1-6] if I remember correctly... Yes, I tested tiers 1-6 on the greater change containing this one, and retested tiers 1-3. > src/hotspot/share/runtime/handles.hpp line 292: > >> 290: >> 291: // ResetNoHandleMark is called in a context where there is an enclosing >> 292: // NoHandleMark. Thread in _thread_in_native must not create handles so > > nit grammar: s/Thread in/A thread in/ fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1983 From pchilanomate at openjdk.java.net Thu Jan 7 22:24:58 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 7 Jan 2021 22:24:58 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 22:21:07 GMT, Coleen Phillimore wrote: >> Please review this straightforward change to add a ResetNoHandleMark in the ThreadInVMfromNative transition class so that callers don't have to do this. Tested with tier1-3. >> This was broken out of a larger change for JDK-8258032 Reconsider LEAF entry restrictions. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > fix grammar Looks good to me! ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/1983 From coleenp at openjdk.java.net Thu Jan 7 22:30:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 22:30:06 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions In-Reply-To: References: Message-ID: <-D7hLGftSqbykxT20N5wKaO6fSUU4ieSbUsCqFSdhUI=.38071c09-6da3-4043-af50-b514b5ab79a5@github.com> On Thu, 7 Jan 2021 21:20:49 GMT, Daniel D. Daugherty wrote: >> Please review the smaller version of this enhancement. JRT_LEAF can allow Handles. Fixed places where a ResetNoHandleMark was added to workaround the restriction and remove some obsolete comments in deoptimization (the function is a JRT_BLOCK_ENTRY that has a HandleMarkCleaner which cleans up the HandleMark to the one before call_stub() in JavaCalls. A HandleMarkCleaner also allows HandleMark and Handles. >> >> Tested with tier1-3, 4-6 with the larger change and 7-8 in progress. > > src/hotspot/share/gc/z/zVerify.cpp line 376: > >> 374: // is no safepoint to protect against, and fiddling around with exceptions. >> 375: class StackWatermarkProcessingMark { >> 376: HandleMark _hm; > > Since you're removing the ResetNoHandleMark, you should revisit > the comment block for the class. The entire sentence to revisit is: > // ... It is mostly > // due to problems that we might want to eventually clean up inside of the > // frame iteration code, such as creating random handles even though there > // is no safepoint to protect against, and fiddling around with exceptions. This statement is still true. PreserveExceptionMark creates a Handle, so we need the HandleMark. We don't need to ResetNoHandleMark with this change. PreserveExceptionMark::PreserveExceptionMark(Thread*& thread) { thread = Thread::current(); _thread = thread; _preserved_exception_oop = Handle(thread, _thread->pending_exception()); (which will create a Handle if there's a pending_exception). > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 493: > >> 491: ThreadInVMfromNative __tiv(thread); \ >> 492: debug_only(VMNativeEntryWrapper __vew;) \ >> 493: debug_only(ResetNoHandleMark __rnhm;) \ > > Your fix for JDK-8259374 adds a ResetNoHandleMark to > ThreadInVMfromNative so new L493 isn't needed. Oh you're right. I'd missed this in the original. I'll remove this after I checkin the first one. ------------- PR: https://git.openjdk.java.net/jdk/pull/1990 From coleenp at openjdk.java.net Thu Jan 7 22:31:53 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Jan 2021 22:31:53 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 22:22:05 GMT, Patricio Chilano Mateo wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> fix grammar > > Looks good to me! Thanks Dan and Patricio! ------------- PR: https://git.openjdk.java.net/jdk/pull/1983 From dholmes at openjdk.java.net Thu Jan 7 22:44:54 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 7 Jan 2021 22:44:54 GMT Subject: RFR: JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling In-Reply-To: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> References: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> Message-ID: On Thu, 7 Jan 2021 16:20:20 GMT, Matthias Baesken wrote: > AIX 5.3 had buggy __thread support (see JDK-8176442). > That's why we introduced a macro USE_LIBRARY_BASED_TLS_ONLY and set it only to 1 on AIX (different to the other platforms supported by the OpenJDK). > However AIX 5.3 support was removed some time ago (currently we have a minimum requirement of AIX 7.X ) so the whole USE_LIBRARY_BASED_TLS_ONLY related coding could be removed. Hi Matthias, We didn't introduce USE_LIBRARY_BASED_TLS_ONLY just for AIX, it was also added to aid the mobile project: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-November/020765.html Before removing it we would need to have a broader discussion. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1976 From iveresov at openjdk.java.net Thu Jan 7 23:06:19 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 7 Jan 2021 23:06:19 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Fix another s390 compilation failure ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1985/files - new: https://git.openjdk.java.net/jdk/pull/1985/files/c6983a18..dfffc35b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 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 iklam at openjdk.java.net Fri Jan 8 00:43:07 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 8 Jan 2021 00:43:07 GMT Subject: RFR: 8259214: MetaspaceClosure support for Arrays of MetaspaceObj Message-ID: Currently, `MetaspaceClosure::push` supports only the following variants: MetaspaceClosure* it = ...; Klass* o = ...; it->push(&o); Array* a1 = ...; it->push(&a1); Array* a2 = ...; it->push(&a2); In Valhalla, support is needed for the following variant (Annotation is a subtype of MetaspaceObj): Array* a3 = ...; it->push(&a3); This change will allow CDS to make a copy of this array, as well as relocating all the pointers embedded in the elements of this array. See a test case in test_metaspaceClosure.cpp. I also cleaned up the code (with help from @kimbarrett) to use SFINAE to dispatch from `MetaspaceClosure::push` to the different subtypes of `MetaspaceClosure::Ref`. ------------- Commit messages: - 8259214: MetaspaceClosure support for Arrays of MetaspaceObj Changes: https://git.openjdk.java.net/jdk/pull/1995/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1995&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259214 Stats: 264 lines in 2 files changed: 209 ins; 31 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/1995.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1995/head:pull/1995 PR: https://git.openjdk.java.net/jdk/pull/1995 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 iklam at openjdk.java.net Fri Jan 8 01:07:54 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 8 Jan 2021 01:07:54 GMT Subject: RFR: 8258810: Improve enum traits [v2] In-Reply-To: References: Message-ID: On Fri, 1 Jan 2021 09:44:18 GMT, Kim Barrett wrote: >> Please review these miscellaneous improvements to the enum iteration facility. >> Thanks to @albertnetymk for discussions. >> >> (1) Removed some unneeded stuff from EnumIterationTraits. >> >> (2) Various similar bits of error checking code are unified and shared via >> EnumIterationTraits. >> >> (3) Casts between the enum type and the underlying type are now done using >> helper functions in EnumIterationTraits. >> >> (4) JDK-8257466 added accessors for the EnumRange bounds and the index for >> an enumerator, but didn't account for the possibility of an empty subrange. >> Add assertions for that case. >> >> (5) Added some death tests to verify some of the error checking. >> >> Testing: >> mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > ayang review Looks good to me ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1868 From dongbo at openjdk.java.net Fri Jan 8 02:53:58 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Fri, 8 Jan 2021 02:53:58 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 10:04:45 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> put faddp/fmaxp/fminp together in a group > > test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java line 67: > >> 65: for (int i = 0; i < COUNT; i++) { >> 66: max = Math.max(max, floatsA[i] - floatsB[i]); >> 67: } > > This test code looks a bit contrived. If you're looking for the smallest delta it'd be > > Math.max(max, Math.abs(floatsA[i] - floatsB[i])); > > and if you're looking for the smallest value it'd probably be > > Math.max(max, floatsA[i]); > > Do we gain any advantage with these? Hi, As the experiment shows, we do not gain improvements with these. For `Math.max(max, Math.abs(floatsA[i] - floatsB[i]))`, the code is not vectorized if `COUNT < 12`. When `COUNT == 12`, the node we have is not `Max2F` but `Max4F`. The `Math.max(max, floatsA[i] - floatsB[i])` suffers same problem that it does not match `Max2F` with small `COUNT`. For `Math.max(max, floatsA[i])`, it is not auto-vectorized even with `COUNT = 512`. I think the auto-vectorized optimization for this is disabled by JDK-8078563 [1]. One of the advantages of `Max2F with fmaxp` can gain for `VectorAPI`, the test code is available in [2]. We witnessed about `12%` improvements for `reduceLanes(VectorOperators.MAX)` of `FloatVector.SPECIES_64`: Benchmark (COUNT) (seed) Mode Cnt Score Error Units # Kunpeng 916, default VectorReduction2FMinMax.maxRed2F 512 0 avgt 10 667.173 ? 0.576 ns/op VectorReduction2FMinMax.minRed2F 512 0 avgt 10 667.172 ? 0.649 ns/op # Kunpeng 916, with fmaxp/fminp VectorReduction2FMinMax.maxRed2F 512 0 avgt 10 592.404 ? 0.885 ns/op VectorReduction2FMinMax.minRed2F 512 0 avgt 10 592.293 ? 0.607 ns/op I agree the testcode for `floats` in `VectorReductionFloatingMinMax.java` is contrived. Do you think we should replace the tests for `MinMaxF` in `VectorReductionFloatingMinMax` with tests in [2]? [1] https://bugs.openjdk.java.net/browse/JDK-8078563 [2] [VectorReduction2FMinMax.java.txt](https://github.com/openjdk/jdk/files/5784948/VectorReduction2FMinMax.java.txt) ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From dholmes at openjdk.java.net Fri Jan 8 03:52:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Jan 2021 03:52:56 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: <7v_VkkEtUrZMV6tBc64b2zNlQNOtrzZ43_WggVw9T_s=.13ce0950-3817-417b-bbf3-a5eaeabc4ffb@github.com> On Thu, 17 Dec 2020 08:10:24 GMT, Mauro Lacy wrote: >>> Besides, I don't think the same is true of the other `Release` methods. This happens only with the `Critical` variant. >> >> Sorry for (contributing to) the confusion. The reported double free error always mentions `ReleasePrimitiveArrayCritical`, but as Dmitry says, this ends up affecting both APIs. > > Hi David, > > Thanks for researching this thoroughly. > What you propose is reasonable, given the circumstances: undocumented or badly documented usage in the specs, and a lot of existing code (even in books, etc) that use `JNI_COMMIT` basically as `0`. We faced the same weeks ago, when looking for examples, documentation, and use cases for this functionality. > > A couple comments: > - Given that `JNI_COMMIT` is then effectively useless, maybe a good idea would be to deprecate it. This will break existing code, true, but a deprecation notice can be used, by example in the form of a compilation warning or so, for code that calls / uses it. Same in the docs, i. e. this is kept for historical reasons but will be deprecated soon, and so on. > - I think in this case the best for us would be to simply drop support for `JNI_COMMIT` in the Rust JNI library. At least, for the ArrayCritical methods. Hi @maurolacy can you please close this PR in favour of https://github.com/openjdk/jdk/pull/1816. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From david.holmes at oracle.com Fri Jan 8 04:30:39 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Jan 2021 14:30:39 +1000 Subject: Linux signals In-Reply-To: References: Message-ID: Hi Walt, On 8/01/2021 7:18 am, Walt Drummond wrote: > Hi -- > > I'm chasing down some information about how the JVM interacts with > signals on Linux. Specifically I need to understand if any of the > Java runtime attempts to directly inspect the system stack when in a > POSIX signal handler. My survey of the code doesn't seem to show any > such uses, and in fact it looks like the JVM relies only on the POSIX > signals API but I figured I'd ask the experts for confirmation. I'm not quite sure what you are asking with regards to the "system stack". The hotspot signal handler does a range of things to try and determine what the signal might mean - e.g. whether it is a true error or an internal use of signals that we can recover from. That may involve examining the thread stack. Cheers, David ----- > Thanks. > --Walt > From david.holmes at oracle.com Fri Jan 8 04:57:45 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Jan 2021 14:57:45 +1000 Subject: RFR: 8251462: Remove legacy compilation policy In-Reply-To: References: Message-ID: <01bf1e4c-cda5-32b8-45e4-5b4100314947@oracle.com> Hi Igor, On 8/01/2021 6:36 am, Igor Veresov wrote: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. Can you clarify, for non-compiler folk, what all the alternative configs actually mean now. I'm a bit confused by this definition: define_pd_global(bool, TieredCompilation, COMPILER1_PRESENT(true) NOT_COMPILER1(false)); as I expected tiered compilation to require COMPILER1 and COMPILER2. Also I see interpreter code that used to be guarded by TieredCompilation now being executed unconditionally, which seems to assume C1 or C2 must be present? Overall it is a big change to digest, but after skimming it looks like a few of the refactorings could have been applied in a layered fashion using multiple commits to make it easier to review. Thanks, David ----- > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > ------------- > > Commit messages: > - Fix copyright years > - Remove legacy compilation policy. > > Changes: https://git.openjdk.java.net/jdk/pull/1985/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8251462 > Stats: 5285 lines in 95 files changed: 1481 ins; 2979 del; 825 mod > Patch: https://git.openjdk.java.net/jdk/pull/1985.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 > > PR: https://git.openjdk.java.net/jdk/pull/1985 > From dholmes at openjdk.java.net Fri Jan 8 05:08:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Jan 2021 05:08:55 GMT Subject: RFR: 8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 13:54:25 GMT, Aleksey Shipilev wrote: > As noted in the bug report, there are places in `vmError.cpp`, where information on compressed classes is only printed if compressed oops are enabled. After JDK-8241825 both features should be independent. In addition to 2 reported places, we also need to print the setting in JVM modeline. > > Sample outputs: > > Command Line: Crash > ... > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.shade.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > ... > VM Mutex/Monitor currently owned by a thread: None > > Heap address: 0x0000000082000000, size: 30688 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 > > CDS archive(s) mapped at: [0x0000000800000000-0x0000000800c5c000-0x0000000800c5c000), size 12959744, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. > Compressed class space mapped at: 0x0000000801000000-0x0000000841000000, reserved size: 1073741824 > Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 > > GC Precious Log: > > Command Line: -XX:-UseCompressedOops Crash > ... > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.shade.jdk, mixed mode, sharing, tiered, compressed class ptrs, g1 gc, linux-amd64) > ... > VM Mutex/Monitor currently owned by a thread: None > > CDS archive(s) mapped at: [0x0000000800000000-0x0000000800c2f000-0x0000000800c2f000), size 12775424, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. > Compressed class space mapped at: 0x0000000801000000-0x0000000841000000, reserved size: 1073741824 > Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 > > GC Precious Log: > ... > > Command Line: -XX:-UseCompressedOops -XX:-UseCompressedClassPointers Crash > ... > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.shade.jdk, mixed mode, tiered, g1 gc, linux-amd64) > ... > VM Mutex/Monitor currently owned by a thread: None > > GC Precious Log: > ... That all seems fine to me. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1974 From david.holmes at oracle.com Fri Jan 8 05:28:45 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Jan 2021 15:28:45 +1000 Subject: RFR: 8258032: Reconsider LEAF entry restrictions In-Reply-To: References: Message-ID: <812b87e7-cad7-b6f5-b175-465aa6792236@oracle.com> On 8/01/2021 7:46 am, Daniel D.Daugherty wrote: > On Thu, 7 Jan 2021 20:57:00 GMT, Coleen Phillimore wrote: > >> Please review the smaller version of this enhancement. JRT_LEAF can allow Handles. Fixed places where a ResetNoHandleMark was added to workaround the restriction and remove some obsolete comments in deoptimization (the function is a JRT_BLOCK_ENTRY that has a HandleMarkCleaner which cleans up the HandleMark to the one before call_stub() in JavaCalls. A HandleMarkCleaner also allows HandleMark and Handles. >> >> Tested with tier1-3, 4-6 with the larger change and 7-8 in progress. > > Like the original changes, the most interesting stuff is in > interfaceSupport.inline.hpp. Just to keep it clear in my head: > - remove NoHandleMark helper from VM_LEAF_BASE; it gets added to JNI_LEAF and JVM_LEAF which need it; JRT_LEAF doesn't need it. If I read the bug comments correctly it is more a case of: "JRT_LEAF should also need it, because this is a leaf routine and we shouldn't be messing with handles, but we have code that wants to mess with Handles even from leaf routines, and that is safe so let's allow them to do that." This strikes me as totally butchering what we mean by a "leaf" routine. :( I also can't quite see if Deoptimization::fetch_unroll_info can actually be reverted back to a JRT_LEAF with these proposed changes? > - remove ResetNoHandleMark helper from VM_ENTRY_BASE_FROM_LEAF since ThreadInVMfromNative will have one with your fix for JDK-8259374. Can we add a comment describing what ResetNoHandleMark actually does please. I'm not really understanding how it is supposed to be used. I suspect it is to allow code that should not create Handles to call code that will create Handles without having to introduce convoluted scoping for the NHM. Thanks, David ----- > Please see my comment in JVM_ENTRY_FROM_LEAF. > > src/hotspot/share/gc/z/zVerify.cpp line 376: > >> 374: // is no safepoint to protect against, and fiddling around with exceptions. >> 375: class StackWatermarkProcessingMark { >> 376: HandleMark _hm; > > Since you're removing the ResetNoHandleMark, you should revisit > the comment block for the class. The entire sentence to revisit is: > // ... It is mostly > // due to problems that we might want to eventually clean up inside of the > // frame iteration code, such as creating random handles even though there > // is no safepoint to protect against, and fiddling around with exceptions. > > src/hotspot/share/runtime/stackWatermark.cpp line 80: > >> 78: // is no safepoint to protect against, and fiddling around with exceptions. >> 79: class StackWatermarkProcessingMark { >> 80: HandleMark _hm; > > Since you're removing the ResetNoHandleMark, you should revisit > the comment block for the class. The entire sentence to revisit is: > // ... It is mostly > // due to problems that we might want to eventually clean up inside of the > // frame processing code, such as creating random handles even though there > // is no safepoint to protect against, and fiddling around with exceptions. > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 493: > >> 491: ThreadInVMfromNative __tiv(thread); \ >> 492: debug_only(VMNativeEntryWrapper __vew;) \ >> 493: debug_only(ResetNoHandleMark __rnhm;) \ > > Your fix for JDK-8259374 adds a ResetNoHandleMark to > ThreadInVMfromNative so new L493 isn't needed. > > ------------- > > Changes requested by dcubed (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1990 > From iveresov at openjdk.java.net Fri Jan 8 06:09:55 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 8 Jan 2021 06:09:55 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix s390 build > > Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. Please find the answers in-line. > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ > > Hi Igor, > > On 8/01/2021 6:36 am, Igor Veresov wrote: > > > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > Can you clarify, for non-compiler folk, what all the alternative configs > actually mean now. I'm a bit confused by this definition: > > define_pd_global(bool, TieredCompilation, > COMPILER1_PRESENT(true) NOT_COMPILER1(false)); That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. > > as I expected tiered compilation to require COMPILER1 and COMPILER2. > Right. That's exactly what's happening. > Also I see interpreter code that used to be guarded by TieredCompilation > now being executed unconditionally, which seems to assume C1 or C2 must > be present? > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. > Overall it is a big change to digest, but after skimming it looks like a > few of the refactorings could have been applied in a layered fashion > using multiple commits to make it easier to review. > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. As far as the runtime part of the change is concerted, it's pretty much only the legacy policy removal. In particular, the parts of the interpreter that dealt with the old policy (basically everything in the interpreter that was under !TieredCompilation has gotten removed). Igor > Thanks, > David > ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From dholmes at openjdk.java.net Fri Jan 8 06:14:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Jan 2021 06:14:04 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 20:03:19 GMT, Harold Seigel wrote: > Please review this change to remove the JVM develop flag UseStackBanging and always use stack banging. > > The change was tested with tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and cross-builds on PPC64, Linux32, and S390x. > > Thanks, Harold Hi Harold, Changes seem fine. I'm enjoying your "war" on legacy flags :) A couple of minor comments below. Thanks, David src/hotspot/cpu/aarch64/aarch64.ad line 3: > 1: // > 2: // Copyright (c) 2003, 2021, Oracle and/or its affiliates. All rights reserved. > 3: // Copyright (c) 2014, 2021, Red Hat, Inc. All rights reserved. Not clear if non-Oracle copyrights need updating when we update Oracle ones. src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 1507: > 1505: // interpreter would need. So this stack banging should never > 1506: // trigger a fault. Verify that it does not on non product builds. > 1507: // See if it is enough stack to push deoptimized frames Now the two comment blocks flow together, please add a period to line 1507. Thanks. src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 252: > 250: X86_ONLY(do_intx_flag(UseSSE)) \ > 251: COMPILER2_PRESENT(do_bool_flag(UseSquareToLenIntrinsic)) \ > 252: do_bool_flag(UseStackBanging) \ Compiler folk will need to verify if this change is okay wrt. upstream Graal code. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1988 From dholmes at openjdk.java.net Fri Jan 8 06:20:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Jan 2021 06:20:56 GMT Subject: RFR: 8258908: Remove JVM option CleanChunkPoolAsync In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 21:53:39 GMT, Harold Seigel wrote: > Please review this small change to remove JVM develop option CleanChunkPoolAsync. The option was originally added for embedded builds so they could clean chunk pools synchronouosly. > > The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Hi Harold, Thanks for cleaning this up, it probably should have been done as part of, or a follow up to, 8140723. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1949 From iveresov at openjdk.java.net Fri Jan 8 06:31:56 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 8 Jan 2021 06:31:56 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Fri, 8 Jan 2021 06:07:23 GMT, Igor Veresov wrote: >> Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. > > Please find the answers in-line. > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >> >> Hi Igor, >> >> On 8/01/2021 6:36 am, Igor Veresov wrote: >> >> > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> Can you clarify, for non-compiler folk, what all the alternative configs >> actually mean now. I'm a bit confused by this definition: >> >> define_pd_global(bool, TieredCompilation, >> COMPILER1_PRESENT(true) NOT_COMPILER1(false)); > > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. >> >> as I expected tiered compilation to require COMPILER1 and COMPILER2. >> > Right. That's exactly what's happening. > >> Also I see interpreter code that used to be guarded by TieredCompilation >> now being executed unconditionally, which seems to assume C1 or C2 must >> be present? >> > > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. > >> Overall it is a big change to digest, but after skimming it looks like a >> few of the refactorings could have been applied in a layered fashion >> using multiple commits to make it easier to review. >> > > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. > > As far as the runtime part of the change is concerted, it's pretty much only the legacy policy removal. In particular, the parts of the interpreter that dealt with the old policy (basically everything in the interpreter that was under !TieredCompilation has gotten removed). > > Igor > >> Thanks, >> David >> ----- To clarify the possible configs. 1. There is only one policy now. Functions with both compilers or a single compiler. 2. The best way to control the operation mode is with the ```-XX:CompilationMode=``` flag. Possible values so far are: normal (aka default), high-only (c2 or graal only), quick-only(c1 only), high-only-quick-internal (a special mode for jar graal where only graal itself is compiled by c1, but the user code is compiled with graal). 3. There is a mode that emulates the behavior when the user specifies -TieredCompilation. That's basically the high-only mode. 4. There is also support for legacy policy flags such as CompileThreshold, which would properly setup the policy parameters to match the old behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From dholmes at openjdk.java.net Fri Jan 8 06:55:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Jan 2021 06:55:56 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 22:21:07 GMT, Coleen Phillimore wrote: >> Please review this straightforward change to add a ResetNoHandleMark in the ThreadInVMfromNative transition class so that callers don't have to do this. Tested with tier1-3. >> This was broken out of a larger change for JDK-8258032 Reconsider LEAF entry restrictions. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > fix grammar src/hotspot/share/runtime/handles.hpp line 293: > 291: // ResetNoHandleMark is called in a context where there is an enclosing > 292: // NoHandleMark. A thread in _thread_in_native must not create handles so > 293: // this is used when transitioning via ThreadInVMfromNative. This comment still doesn't clearly (to me) explain the use of RNHM. Basically it is intended to "disable" a NHM further up the stack but why do we not force the caller up the stack to correctly scope the NMH? This seems to be a way to allow sloppy coding further up the stack, or worse it allows code to be called that might use Handles completely unexpectedly wrt the code up the stack. Should a NHM not mean "this code and all code called from it must not use Handles"? And can't this be used in a range of contexts not just this ThreadInVMFromNative transition? Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1983 From dholmes at openjdk.java.net Fri Jan 8 06:59:02 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Jan 2021 06:59:02 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: References: Message-ID: <2U9_AyzJPQKlEFk3rC94U85uDzE7pl1rUfsshKrwzII=.e6fff35d-7b31-468d-a31d-0b18f212ea49@github.com> On Thu, 7 Jan 2021 22:21:07 GMT, Coleen Phillimore wrote: >> Please review this straightforward change to add a ResetNoHandleMark in the ThreadInVMfromNative transition class so that callers don't have to do this. Tested with tier1-3. >> This was broken out of a larger change for JDK-8258032 Reconsider LEAF entry restrictions. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > fix grammar src/hotspot/share/runtime/interfaceSupport.inline.hpp line 195: > 193: > 194: class ThreadInVMfromNative : public ThreadStateTransition { > 195: ResetNoHandleMark __rnhm; We should add a constructor for RNHM that takes the current thread so that we don't have to call Thread::current() unnecessarily in the existing RNHM constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/1983 From dholmes at openjdk.java.net Fri Jan 8 07:03:01 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Jan 2021 07:03:01 GMT Subject: RFR: 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark In-Reply-To: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> References: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> Message-ID: On Thu, 7 Jan 2021 16:04:28 GMT, Coleen Phillimore wrote: > This is a trivial change to remove the comments and the ResetNoHandleMark from jvmti functions. They're called by JNI_ENTRY so they don't have a NoHandleMark that needs to be reset. It may not have always been the case. > Tested with the other patch for https://bugs.openjdk.java.net/browse/JDK-8258032 and retesting with tier1-3. src/hotspot/share/prims/jvmtiExport.cpp line 1891: > 1889: // At least one field access watch is set so we have more work > 1890: // to do. This wrapper is used by "quick" entry points that don't > 1891: // allow us to create handles in post_field_access_by_jni(). We This part of the comment should have remained - no? It is what distinguishes the _nh version from the regular version. (Though this code seems so confused it may be that we don't even need a _nh version?) Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1975 From dholmes at openjdk.java.net Fri Jan 8 07:05:57 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Jan 2021 07:05:57 GMT Subject: RFR: 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark In-Reply-To: References: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> Message-ID: On Fri, 8 Jan 2021 07:00:45 GMT, David Holmes wrote: >> This is a trivial change to remove the comments and the ResetNoHandleMark from jvmti functions. They're called by JNI_ENTRY so they don't have a NoHandleMark that needs to be reset. It may not have always been the case. >> Tested with the other patch for https://bugs.openjdk.java.net/browse/JDK-8258032 and retesting with tier1-3. > > src/hotspot/share/prims/jvmtiExport.cpp line 1891: > >> 1889: // At least one field access watch is set so we have more work >> 1890: // to do. This wrapper is used by "quick" entry points that don't >> 1891: // allow us to create handles in post_field_access_by_jni(). We > > This part of the comment should have remained - no? It is what distinguishes the _nh version from the regular version. (Though this code seems so confused it may be that we don't even need a _nh version?) > > Cheers, > David Looking closer this code is broken - both the _nh and regular version actually create Handles! The _nh version should be read as being used when "the caller does not allow handles" and hence it needed the RNHM. So either the RHNM remains necessary or else all calls to x_nh() should be changed to x(). David ------------- PR: https://git.openjdk.java.net/jdk/pull/1975 From github.com+11656534+maurolacy at openjdk.java.net Fri Jan 8 07:10:56 2021 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Fri, 8 Jan 2021 07:10:56 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: <7v_VkkEtUrZMV6tBc64b2zNlQNOtrzZ43_WggVw9T_s=.13ce0950-3817-417b-bbf3-a5eaeabc4ffb@github.com> References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> <7v_VkkEtUrZMV6tBc64b2zNlQNOtrzZ43_W ggVw9T_s=.13ce0950-3817-417b-bbf3-a5eaeabc4ffb@github.com> Message-ID: On Fri, 8 Jan 2021 03:50:10 GMT, David Holmes wrote: >> Hi David, >> >> Thanks for researching this thoroughly. >> What you propose is reasonable, given the circumstances: undocumented or badly documented usage in the specs, and a lot of existing code (even in books, etc) that use `JNI_COMMIT` basically as `0`. We faced the same weeks ago, when looking for examples, documentation, and use cases for this functionality. >> >> A couple comments: >> - Given that `JNI_COMMIT` is then effectively useless, maybe a good idea would be to deprecate it. This will break existing code, true, but a deprecation notice can be used, by example in the form of a compilation warning or so, for code that calls / uses it. Same in the docs, i. e. this is kept for historical reasons but will be deprecated soon, and so on. >> - I think in this case the best for us would be to simply drop support for `JNI_COMMIT` in the Rust JNI library. At least, for the ArrayCritical methods. > > Hi @maurolacy can you please close this PR in favour of https://github.com/openjdk/jdk/pull/1816. Thanks. Closing in favour of #1816. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From github.com+11656534+maurolacy at openjdk.java.net Fri Jan 8 07:10:57 2021 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Fri, 8 Jan 2021 07:10:57 GMT Subject: Withdrawn: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> Message-ID: On Tue, 8 Dec 2020 14:01:48 GMT, Mauro Lacy wrote: > Hello, > > I'm a contributor of the [jni-rs](https://github.com/jni-rs/jni-rs/) project. Rust bindings to the JNI. > > When running tests against OpenJDK with the flag "-Xcheck:jni" enabled, we detected the following: the behaviour of the `JNI_COMMIT` mode of `ReleasePrimitiveArrayCritical` seems to be inconsistent, when running with `-Xcheck:jni` enabled, vs. without `-Xcheck:jni`. > > If using "-Xcheck:jni", we're hitting a double free calling `ReleasePrimitiveArrayCritical` with `JNI_COMMIT`, when we attempt to release the buffer at the end. It is our understanding that the behaviour of `ReleasePrimitiveArrayCritical` must be consistent, independently of whether the check JNI mode is enabled or not. > > You can check [https://github.com/jni-rs/jni-rs/issues/283](https://github.com/jni-rs/jni-rs/issues/283) for details / comments on this. > > We've tracked down the issue to this February 2019 commit: [openjdk commit 3e904a4](https://github.com/openjdk/jdk/commit/3e904a4801b2bf2e988ba096e5cb64a17fd5fce7). The related discussion is here: [openjdk bug JDK-8193234](https://bugs.openjdk.java.net/browse/JDK-8193234). > > As there are no associated tests or functionality in the OpenJDK code base, I've simply reverted the commit. Just in case, I've also built and tested the JDK, without issues. > > Not sure what tests are the ones mentioned in the discussions that led to the introduction of this behaviour. It is our understanding that tests of `JNI_COMMIT` functionality must still make a call to `ReleasePrimitiveArrayCritical` with a proper mode (`0` or `JNI_ABORT`) at the end, to release the buffer. And this, independently of `-Xcheck:jni` being enabled or not. > > If there are any issues related to this that we're not aware of, please let us know. > > This reverts commit 3e904a4801b2bf2e988ba096e5cb64a17fd5fce7. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From shade at openjdk.java.net Fri Jan 8 09:48:07 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 8 Jan 2021 09:48:07 GMT Subject: RFR: 8259403: Zero: crash with NULL MethodHandle receiver Message-ID: Happens reliably: $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/jsr292/NullConstantReceiver.java # A fatal error has been detected by the Java Runtime Environment: # SIGSEGV (0xb) at pc=0x0000000000000000, pid=4059994, tid=4060008 Zero's MH handling code does not check if receiver is NULL before accessing its klass. Additional testing: - [x] Linux x86_64 Zero `compiler/jsr292/NullConstantReceiver.java` - [x] Linux x86_64 Zero `tier1` (no new failures) ------------- Commit messages: - 8259403: Zero: crash with NULL MethodHandle receiver Changes: https://git.openjdk.java.net/jdk/pull/1987/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1987&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259403 Stats: 79 lines in 4 files changed: 57 ins; 16 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1987.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1987/head:pull/1987 PR: https://git.openjdk.java.net/jdk/pull/1987 From aph at openjdk.java.net Fri Jan 8 09:54:58 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 8 Jan 2021 09:54:58 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 02:51:19 GMT, Dong Bo wrote: >> test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java line 67: >> >>> 65: for (int i = 0; i < COUNT; i++) { >>> 66: max = Math.max(max, floatsA[i] - floatsB[i]); >>> 67: } >> >> This test code looks a bit contrived. If you're looking for the smallest delta it'd be >> >> Math.max(max, Math.abs(floatsA[i] - floatsB[i])); >> >> and if you're looking for the smallest value it'd probably be >> >> Math.max(max, floatsA[i]); >> >> Do we gain any advantage with these? > > Hi, > > As the experiment shows, we do not gain improvements with these. > > For `Math.max(max, Math.abs(floatsA[i] - floatsB[i]))`, the code is not vectorized if `COUNT < 12`. > When `COUNT == 12`, the node we have is not `Max2F` but `Max4F`. > The `Math.max(max, floatsA[i] - floatsB[i])` suffers same problem that it does not match `Max2F` with small `COUNT`. > > For `Math.max(max, floatsA[i])`, it is not auto-vectorized even with `COUNT = 512`. > I think the auto-vectorized optimization for this is disabled by JDK-8078563 [1]. > > One of the advantages of `Max2F with fmaxp` can gain for `VectorAPI`, the test code is available in [2]. > We witnessed about `12%` improvements for `reduceLanes(VectorOperators.MAX)` of `FloatVector.SPECIES_64`: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction2FMinMax.maxRed2F 512 0 avgt 10 667.173 ? 0.576 ns/op > VectorReduction2FMinMax.minRed2F 512 0 avgt 10 667.172 ? 0.649 ns/op > # Kunpeng 916, with fmaxp/fminp > VectorReduction2FMinMax.maxRed2F 512 0 avgt 10 592.404 ? 0.885 ns/op > VectorReduction2FMinMax.minRed2F 512 0 avgt 10 592.293 ? 0.607 ns/op > > I agree the testcode for `floats` in `VectorReductionFloatingMinMax.java` is contrived. > Do you think we should replace the tests for `MinMaxF` in `VectorReductionFloatingMinMax` with tests in [2]? > > [1] https://bugs.openjdk.java.net/browse/JDK-8078563 > [2] [VectorReduction2FMinMax.java.txt](https://github.com/openjdk/jdk/files/5784948/VectorReduction2FMinMax.java.txt) I don't think the real problem is only the tests, it's that common cases don't get vectorized. Can we fix this code so that it works with ```Math.abs()``` ? Are there any examples of plausible Java code that benefit from this optimization? ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From tschatzl at openjdk.java.net Fri Jan 8 11:08:58 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Jan 2021 11:08:58 GMT Subject: RFR: 8259380: Correct pretouch chunk size to cap with actual page size In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 11:03:55 GMT, Thomas Schatzl wrote: >> This is actually a regression, with regards to JVM startup time extreme slowdown, initially found at an aarch64 platform (Ampere Altra core). >> >> The chunk size of pretouching should cap with the input page size which probably stands for large pages size if UseLargePages was set, otherwise processing chunks with much smaller size inside large size pages would hurt performance. >> >> This issue was introduced during a refactor on chunk calculations [JDK-8254972](https://bugs.openjdk.java.net/browse/JDK-8254972) (https://github.com/openjdk/jdk/commit/2c7fc85be92c60f4262aff3bc80e704792c1e810) but did not cause any problem immediately since the default PreTouchParallelChunkSize for all platforms are 1GB which can cover all popular sizes of large pages in use by most kernel variations. Later on, [JDK-8254699](https://bugs.openjdk.java.net/browse/JDK-8254699) (https://github.com/openjdk/jdk/commit/805d05812c5e831947197419d163f9c83d55634a) set default 4MB for Linux platform, which is helpful to speed up startup time for some platforms. For example, most x64, since the popular default large page size (e.g. CentOS) is 2MB. In contrast, most default large page size with aarch64 platforms/kernels (e.g. CentOS) are 512MB, so using the 4MB chunk size to do page walk through the pages inside 512MB large page hurt performance of startup time. >> >> In addition, there will be a similar problem if we set -XX:PreTouchParallelChunkSize=4k at a x64 Linux platform, the startup slowdown will show as well. >> >> Tests: >> https://bugs.openjdk.java.net/secure/attachment/92623/pretouch_chunk_size_fix_testing.txt >> The 4 before-after comparisons show the JVM startup time go back to normal. >> 1). 33.381s to 0.870s >> 2). 20.333s to 2.740s >> 3). 15.090s to 6.268s >> 4). 38.983s to 6.709s >> (Use the start time of pretouching the first Survivor space as a rough measurement, while \time, or GCTraceTime can generate similar results) > > Thanks for finding and reporting this issue and even providing a patch. > > After having looked at the issue we (in the Oracle GC team) think this problem is serious enough to actually go into JDK16. Since backporting after having this pushed to some (this) repo is some extra effort, would you mind closing this PR here on openjdk/jdk and reopening a new one on openjdk/jdk16? > > It will then be automatically forward ported to this repo. Not only is backporting some additional effort, there is concern that it won't make it into jdk16 otherwise - Jan 14 is cutoff date for bugs of this seriousness, and we'd need to get an exception for this otherwise. > > As one of the persons typically triaging new issues in the bug tracker, I would also like to ask you to not open new issues immediately. We are looking at these issues three times a week, and if you open them yourselves, issues might not be handled correctly (i.e. like in this case immediately put into openjdk/jdk16). You can still create a PR and everything even if an issue is in "New" state. > > I'll start looking at your change immediately. > > Thanks, > Thomas Fwiw, the most appropriate label for this change would probably be "hotspot-gc", but "hotspot" is fine too. ------------- PR: https://git.openjdk.java.net/jdk/pull/1978 From tschatzl at openjdk.java.net Fri Jan 8 11:08:57 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Jan 2021 11:08:57 GMT Subject: RFR: 8259380: Correct pretouch chunk size to cap with actual page size In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 16:56:37 GMT, Patrick Zhang wrote: > This is actually a regression, with regards to JVM startup time extreme slowdown, initially found at an aarch64 platform (Ampere Altra core). > > The chunk size of pretouching should cap with the input page size which probably stands for large pages size if UseLargePages was set, otherwise processing chunks with much smaller size inside large size pages would hurt performance. > > This issue was introduced during a refactor on chunk calculations [JDK-8254972](https://bugs.openjdk.java.net/browse/JDK-8254972) (https://github.com/openjdk/jdk/commit/2c7fc85be92c60f4262aff3bc80e704792c1e810) but did not cause any problem immediately since the default PreTouchParallelChunkSize for all platforms are 1GB which can cover all popular sizes of large pages in use by most kernel variations. Later on, [JDK-8254699](https://bugs.openjdk.java.net/browse/JDK-8254699) (https://github.com/openjdk/jdk/commit/805d05812c5e831947197419d163f9c83d55634a) set default 4MB for Linux platform, which is helpful to speed up startup time for some platforms. For example, most x64, since the popular default large page size (e.g. CentOS) is 2MB. In contrast, most default large page size with aarch64 platforms/kernels (e.g. CentOS) are 512MB, so using the 4MB chunk size to do page walk through the pages inside 512MB large page hurt performance of startup time. > > In addition, there will be a similar problem if we set -XX:PreTouchParallelChunkSize=4k at a x64 Linux platform, the startup slowdown will show as well. > > Tests: > https://bugs.openjdk.java.net/secure/attachment/92623/pretouch_chunk_size_fix_testing.txt > The 4 before-after comparisons show the JVM startup time go back to normal. > 1). 33.381s to 0.870s > 2). 20.333s to 2.740s > 3). 15.090s to 6.268s > 4). 38.983s to 6.709s > (Use the start time of pretouching the first Survivor space as a rough measurement, while \time, or GCTraceTime can generate similar results) Thanks for finding and reporting this issue and even providing a patch. After having looked at the issue we (in the Oracle GC team) think this problem is serious enough to actually go into JDK16. Since backporting after having this pushed to some (this) repo is some extra effort, would you mind closing this PR here on openjdk/jdk and reopening a new one on openjdk/jdk16? It will then be automatically forward ported to this repo. Not only is backporting some additional effort, there is concern that it won't make it into jdk16 otherwise - Jan 14 is cutoff date for bugs of this seriousness, and we'd need to get an exception for this otherwise. As one of the persons typically triaging new issues in the bug tracker, I would also like to ask you to not open new issues immediately. We are looking at these issues three times a week, and if you open them yourselves, issues might not be handled correctly (i.e. like in this case immediately put into openjdk/jdk16). You can still create a PR and everything even if an issue is in "New" state. I'll start looking at your change immediately. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1978 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 kbarrett at openjdk.java.net Fri Jan 8 12:15:57 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 8 Jan 2021 12:15:57 GMT Subject: RFR: 8258810: Improve enum traits [v2] In-Reply-To: <5wNonxnCzpbxmF-Eb4DZ7E89L0BeqZXPb66Rw_PZvDo=.5d397ee6-fa8f-4860-add7-dada8f713063@github.com> References: <5wNonxnCzpbxmF-Eb4DZ7E89L0BeqZXPb66Rw_PZvDo=.5d397ee6-fa8f-4860-add7-dada8f713063@github.com> Message-ID: On Thu, 24 Dec 2020 20:44:37 GMT, Albert Mingkun Yang wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> ayang review > > I think `assert(size() > 0)` is more consistent with preceding documentation than `assert_not_empty()` in `first()` and `last()`. Very subjective though; up to you. Thanks @albertnetymk and @iklam for reviews. Still need another reviewer, since @albertnetymk is not yet a committer. ------------- PR: https://git.openjdk.java.net/jdk/pull/1868 From coleenp at openjdk.java.net Fri Jan 8 13:08:01 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Jan 2021 13:08:01 GMT Subject: RFR: 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark In-Reply-To: References: <58BDl-zfMI1tMZ-7nvYwsUvHS8BX8m_uzO1CQVdO_rE=.ec7c6e4f-eb2a-4965-a761-af92215351d6@github.com> Message-ID: On Fri, 8 Jan 2021 07:03:28 GMT, David Holmes wrote: >> src/hotspot/share/prims/jvmtiExport.cpp line 1891: >> >>> 1889: // At least one field access watch is set so we have more work >>> 1890: // to do. This wrapper is used by "quick" entry points that don't >>> 1891: // allow us to create handles in post_field_access_by_jni(). We >> >> This part of the comment should have remained - no? It is what distinguishes the _nh version from the regular version. (Though this code seems so confused it may be that we don't even need a _nh version?) >> >> Cheers, >> David > > Looking closer this code is broken - both the _nh and regular version actually create Handles! The _nh version should be read as being used when "the caller does not allow handles" and hence it needed the RNHM. So either the RHNM remains necessary or else all calls to x_nh() should be changed to x(). > > David Calls to x_nh() should be changed to x(). QUICK_ENTRY was removed in https://bugs.openjdk.java.net/browse/JDK-8228758 and this was called via JNI_QUICK_ENTRY back then. All this complex machinery makes me want to remove HandleMarks completely in favor of having Handles be RAII objects like methodHandles. I can file a bug to remove the _nh version of this function. ------------- PR: https://git.openjdk.java.net/jdk/pull/1975 From coleenp at openjdk.java.net Fri Jan 8 13:16:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Jan 2021 13:16:57 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: <2U9_AyzJPQKlEFk3rC94U85uDzE7pl1rUfsshKrwzII=.e6fff35d-7b31-468d-a31d-0b18f212ea49@github.com> References: <2U9_AyzJPQKlEFk3rC94U85uDzE7pl1rUfsshKrwzII=.e6fff35d-7b31-468d-a31d-0b18f212ea49@github.com> Message-ID: <_idMfO5Oq1M0_pUK6iVBYbkm_mLjmkcJfexeBjTzad4=.0b3a1f1e-76f2-41a8-9bd3-ca0fe48dd090@github.com> On Fri, 8 Jan 2021 06:56:11 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> fix grammar > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 195: > >> 193: >> 194: class ThreadInVMfromNative : public ThreadStateTransition { >> 195: ResetNoHandleMark __rnhm; > > We should add a constructor for RNHM that takes the current thread so that we don't have to call Thread::current() unnecessarily in the existing RNHM constructor. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/1983 From coleenp at openjdk.java.net Fri Jan 8 13:43:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Jan 2021 13:43:05 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: References: Message-ID: <5u0LgLfOfCoE0wUTAkH0G_43mb41UljWgpNBocm_cLc=.e1b7dd10-8716-47d8-89f3-990aff32d2c4@github.com> On Fri, 8 Jan 2021 06:52:43 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> fix grammar > > src/hotspot/share/runtime/handles.hpp line 293: > >> 291: // ResetNoHandleMark is called in a context where there is an enclosing >> 292: // NoHandleMark. A thread in _thread_in_native must not create handles so >> 293: // this is used when transitioning via ThreadInVMfromNative. > > This comment still doesn't clearly (to me) explain the use of RNHM. Basically it is intended to "disable" a NHM further up the stack but why do we not force the caller up the stack to correctly scope the NMH? This seems to be a way to allow sloppy coding further up the stack, or worse it allows code to be called that might use Handles completely unexpectedly wrt the code up the stack. Should a NHM not mean "this code and all code called from it must not use Handles"? > > And can't this be used in a range of contexts not just this ThreadInVMFromNative transition? > > Thanks, > David Yes so the NHM does mean "this code and all code called from this must not use handles" which is why it appears in the JNI_LEAF and JVM_LEAF. Handles and oops are not safe in VM code whose state is _thread_in_native. So the interesting scenario here is: JNI_LEAF(some function) { do some things that don't allow oops or Handles (the NHM will cause an assertion to help make sure this is the case) // Oh rats, we need to go into the VM maybe conditionally ThreadInVMFromNative tivm; // Now handles are cool. } This change embeds the ResetNoHandleMark in the ThreadInVMFromNative so that all the callers don't require it. The caller up the stack is the JNI_LEAF generally where we generally want NoHandleMark. The transitions from Java to VM don't require this because my n+1 change lifts the no Handle restrictions. This is the only case where this pattern is needed in the callers. My goal with this is to reduce the intellectual noise required to read this and figure out why it's needed that is littered around the source code. I'm not sure what to say in this comment that explains this better, please suggest better wording. ------------- PR: https://git.openjdk.java.net/jdk/pull/1983 From coleenp at openjdk.java.net Fri Jan 8 13:56:59 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Jan 2021 13:56:59 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 21:43:54 GMT, Daniel D. Daugherty wrote: >> Please review the smaller version of this enhancement. JRT_LEAF can allow Handles. Fixed places where a ResetNoHandleMark was added to workaround the restriction and remove some obsolete comments in deoptimization (the function is a JRT_BLOCK_ENTRY that has a HandleMarkCleaner which cleans up the HandleMark to the one before call_stub() in JavaCalls. A HandleMarkCleaner also allows HandleMark and Handles. >> >> Tested with tier1-3, 4-6 with the larger change and 7-8 in progress. > > Like the original changes, the most interesting stuff is in > interfaceSupport.inline.hpp. Just to keep it clear in my head: > - remove NoHandleMark helper from VM_LEAF_BASE; it gets added to JNI_LEAF and JVM_LEAF which need it; JRT_LEAF doesn't need it. > - remove ResetNoHandleMark helper from VM_ENTRY_BASE_FROM_LEAF since ThreadInVMfromNative will have one with your fix for JDK-8259374. > > Please see my comment in JVM_ENTRY_FROM_LEAF. JRT_LEAF still has a NoSafepointVerifier if that helps. There's a comment about the things it's not allowed to do in interfaceSupport.inline.hpp. The things it's not supposed to do are all checked by the NSV. One of the things it can do now (especially if it's not going to safepoint) is to have a Handle with an enclosing HandleMark because GC won't touch the oops anyway. This is one of the things @pron ran into with loom (see issue) and @fisk and I discussed. I originally took the bug because I was going to close it as WNF, because I hate removing restrictions. I do think there is a bug lurking here. If you have a Handle without an enclosing HandleMark in JRT_LEAF, it will not be cleaned up when the leaf function returns. This might need a HandleMarkCleaner. ------------- PR: https://git.openjdk.java.net/jdk/pull/1990 From coleenp at openjdk.java.net Fri Jan 8 13:56:59 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Jan 2021 13:56:59 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 13:53:11 GMT, Coleen Phillimore wrote: >> Like the original changes, the most interesting stuff is in >> interfaceSupport.inline.hpp. Just to keep it clear in my head: >> - remove NoHandleMark helper from VM_LEAF_BASE; it gets added to JNI_LEAF and JVM_LEAF which need it; JRT_LEAF doesn't need it. >> - remove ResetNoHandleMark helper from VM_ENTRY_BASE_FROM_LEAF since ThreadInVMfromNative will have one with your fix for JDK-8259374. >> >> Please see my comment in JVM_ENTRY_FROM_LEAF. > > JRT_LEAF still has a NoSafepointVerifier if that helps. There's a comment about the things it's not allowed to do in interfaceSupport.inline.hpp. The things it's not supposed to do are all checked by the NSV. > One of the things it can do now (especially if it's not going to safepoint) is to have a Handle with an enclosing HandleMark because GC won't touch the oops anyway. This is one of the things @pron ran into with loom (see issue) and @fisk and I discussed. > I originally took the bug because I was going to close it as WNF, because I hate removing restrictions. > I do think there is a bug lurking here. If you have a Handle without an enclosing HandleMark in JRT_LEAF, it will not be cleaned up when the leaf function returns. This might need a HandleMarkCleaner. I do not see fetch_unroll_info_helper reverting back to JRT_LEAF. ------------- PR: https://git.openjdk.java.net/jdk/pull/1990 From hseigel at openjdk.java.net Fri Jan 8 14:41:12 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 8 Jan 2021 14:41:12 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v2] In-Reply-To: References: Message-ID: > Please review this change to remove the JVM develop flag UseStackBanging and always use stack banging. > > The change was tested with tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and cross-builds on PPC64, Linux32, and S390x. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: fix copyrights, other minot changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1988/files - new: https://git.openjdk.java.net/jdk/pull/1988/files/86a537b8..34e80423 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1988&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1988&range=00-01 Stats: 9 lines in 8 files changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1988.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1988/head:pull/1988 PR: https://git.openjdk.java.net/jdk/pull/1988 From hseigel at openjdk.java.net Fri Jan 8 14:41:13 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 8 Jan 2021 14:41:13 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 06:06:43 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> fix copyrights, other minot changes > > src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 1507: > >> 1505: // interpreter would need. So this stack banging should never >> 1506: // trigger a fault. Verify that it does not on non product builds. >> 1507: // See if it is enough stack to push deoptimized frames > > Now the two comment blocks flow together, please add a period to line 1507. Thanks. Done. Thanks for pointing this out. ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From hseigel at openjdk.java.net Fri Jan 8 14:46:14 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 8 Jan 2021 14:46:14 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v3] In-Reply-To: References: Message-ID: <6rQJahQ2wG0MPbf6BQ39B1qhHZc73MLyOK1n0ufY2RE=.b727c7ba-4cc7-411e-91b3-c14e8fa41eed@github.com> > Please review this change to remove the JVM develop flag UseStackBanging and always use stack banging. > > The change was tested with tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and cross-builds on PPC64, Linux32, and S390x. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: minor comment changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1988/files - new: https://git.openjdk.java.net/jdk/pull/1988/files/34e80423..7aabbf2c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1988&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1988&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1988.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1988/head:pull/1988 PR: https://git.openjdk.java.net/jdk/pull/1988 From hseigel at openjdk.java.net Fri Jan 8 14:50:01 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 8 Jan 2021 14:50:01 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 06:11:28 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> minor comment changes > > Hi Harold, > > Changes seem fine. I'm enjoying your "war" on legacy flags :) > > A couple of minor comments below. > > Thanks, > David David, thanks for the review. I fixed up the comments and restored the non-Oracle copyrights to their original values because I noticed other hotspot changes only updated the Oracle copyrights. I'll wait for a Graal person to approve this change before pushing it. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From coleenp at openjdk.java.net Fri Jan 8 15:05:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Jan 2021 15:05:05 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v3] In-Reply-To: <6rQJahQ2wG0MPbf6BQ39B1qhHZc73MLyOK1n0ufY2RE=.b727c7ba-4cc7-411e-91b3-c14e8fa41eed@github.com> References: <6rQJahQ2wG0MPbf6BQ39B1qhHZc73MLyOK1n0ufY2RE=.b727c7ba-4cc7-411e-91b3-c14e8fa41eed@github.com> Message-ID: On Fri, 8 Jan 2021 14:46:14 GMT, Harold Seigel wrote: >> Please review this change to remove the JVM develop flag UseStackBanging and always use stack banging. >> >> The change was tested with tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and cross-builds on PPC64, Linux32, and S390x. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > minor comment changes LGTM ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1988 From walt at drummond.us Fri Jan 8 16:22:16 2021 From: walt at drummond.us (Walt Drummond) Date: Fri, 8 Jan 2021 08:22:16 -0800 Subject: Linux signals In-Reply-To: References: Message-ID: Hi David -- Sorry, I've come to appreciate the confusion this causes; I can't tell if by 'thread' you mean a java thread or a POSIX thread. :) To help punch through some of that, I'm going to be a bit pedantic, apologies in advance. When the kernel delivers a signal to a process/thread (in the Linux sense of the term), it places some data on the process stack. That data includes the parameters to the POSIX signal hander (signal number, a siginfo_t, and a ucontext_t). Above that in the stack, the kernel also places FPU state and, on AMD64, extended state information. My question is does the JVM directly inspect the JVM program stack when running the POSIX signal handler(s). My current understanding is that it does not and only relies on the POSIX signals APIs and data structures from libc. Thanks, and sorry for the confusion. On Thu, Jan 7, 2021 at 8:30 PM David Holmes wrote: > > Hi Walt, > > On 8/01/2021 7:18 am, Walt Drummond wrote: > > Hi -- > > > > I'm chasing down some information about how the JVM interacts with > > signals on Linux. Specifically I need to understand if any of the > > Java runtime attempts to directly inspect the system stack when in a > > POSIX signal handler. My survey of the code doesn't seem to show any > > such uses, and in fact it looks like the JVM relies only on the POSIX > > signals API but I figured I'd ask the experts for confirmation. > > I'm not quite sure what you are asking with regards to the "system > stack". The hotspot signal handler does a range of things to try and > determine what the signal might mean - e.g. whether it is a true error > or an internal use of signals that we can recover from. That may involve > examining the thread stack. > > Cheers, > David > ----- > > > Thanks. > > --Walt > > From mdoerr at openjdk.java.net Fri Jan 8 16:29:56 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 8 Jan 2021 16:29:56 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v3] In-Reply-To: References: <6rQJahQ2wG0MPbf6BQ39B1qhHZc73MLyOK1n0ufY2RE=.b727c7ba-4cc7-411e-91b3-c14e8fa41eed@github.com> Message-ID: On Fri, 8 Jan 2021 15:01:48 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> minor comment changes > > LGTM I'm fine with removing the develop flag even though I'd like to have an alternative for stack banging in the future. It still has problems on some platforms (primordial thread on AIX) and a high complexity. And I could even imagine that using explicit compare instructions yields better performance because we could avoid polluting caches with stack banging. But that's unrelated to this change. I just didn't have time for further investigations so far. ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From coleenp at openjdk.java.net Fri Jan 8 17:03:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Jan 2021 17:03:06 GMT Subject: RFR: 8259486: Remove CautiouslyPreserveExceptionMark Message-ID: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> See CR for details. This is a hopefully simple cleanup. I didn't try to reason about removing any of these except an obvious call (if you look above the patch in thread.cpp). Tested with tier1-3. ------------- Commit messages: - Fix clear_pending_exception in fill_in_stack_trace. - Remove CautiouslyPreserveException mark. Changes: https://git.openjdk.java.net/jdk/pull/2007/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2007&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259486 Stats: 103 lines in 14 files changed: 8 ins; 58 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/2007.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2007/head:pull/2007 PR: https://git.openjdk.java.net/jdk/pull/2007 From iklam at openjdk.java.net Fri Jan 8 19:12:13 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 8 Jan 2021 19:12:13 GMT Subject: RFR: 8259214: MetaspaceClosure support for Arrays of MetaspaceObj [v2] In-Reply-To: References: Message-ID: > Currently, `MetaspaceClosure::push` supports only the following variants: > > MetaspaceClosure* it = ...; > Klass* o = ...; it->push(&o); > Array* a1 = ...; it->push(&a1); > Array* a2 = ...; it->push(&a2); > > In Valhalla, support is needed for the following variant (Annotation is a subtype of MetaspaceObj): > > Array* a3 = ...; it->push(&a3); > > This change will allow CDS to make a copy of this array, as well as relocating all the pointers embedded in the elements of this array. See a test case in test_metaspaceClosure.cpp. > > I also cleaned up the code (with help from @kimbarrett) to use SFINAE to dispatch from `MetaspaceClosure::push` to the different subtypes of `MetaspaceClosure::Ref`. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed typo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1995/files - new: https://git.openjdk.java.net/jdk/pull/1995/files/c432f190..6781e383 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1995&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1995&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1995.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1995/head:pull/1995 PR: https://git.openjdk.java.net/jdk/pull/1995 From coleenp at openjdk.java.net Fri Jan 8 19:37:02 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Jan 2021 19:37:02 GMT Subject: RFR: 8259482: jni_Set/GetField_probe are the same as their _nh versions Message-ID: <-KyDin9aId3_tTdCVPJdIddjJR6AjQReRFJdvOIpYvg=.057bc24e-fee7-4284-a2b5-6e02fa8ecf0f@github.com> Remove the _nh versions. Tested with tier1 and vmTestbase/nsk/jdi,jvmti tests. ------------- Commit messages: - 8259482: jni_Set/GetField_probe are the same as their _nh versions Changes: https://git.openjdk.java.net/jdk/pull/2008/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2008&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259482 Stats: 37 lines in 3 files changed: 0 ins; 33 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2008.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2008/head:pull/2008 PR: https://git.openjdk.java.net/jdk/pull/2008 From hseigel at openjdk.java.net Fri Jan 8 19:58:54 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 8 Jan 2021 19:58:54 GMT Subject: RFR: 8259482: jni_Set/GetField_probe are the same as their _nh versions In-Reply-To: <-KyDin9aId3_tTdCVPJdIddjJR6AjQReRFJdvOIpYvg=.057bc24e-fee7-4284-a2b5-6e02fa8ecf0f@github.com> References: <-KyDin9aId3_tTdCVPJdIddjJR6AjQReRFJdvOIpYvg=.057bc24e-fee7-4284-a2b5-6e02fa8ecf0f@github.com> Message-ID: On Fri, 8 Jan 2021 19:32:36 GMT, Coleen Phillimore wrote: > Remove the _nh versions. Tested with tier1 and vmTestbase/nsk/jdi,jvmti tests. The changes look good! Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2008 From kvn at openjdk.java.net Fri Jan 8 20:35:03 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 8 Jan 2021 20:35:03 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v3] In-Reply-To: <6rQJahQ2wG0MPbf6BQ39B1qhHZc73MLyOK1n0ufY2RE=.b727c7ba-4cc7-411e-91b3-c14e8fa41eed@github.com> References: <6rQJahQ2wG0MPbf6BQ39B1qhHZc73MLyOK1n0ufY2RE=.b727c7ba-4cc7-411e-91b3-c14e8fa41eed@github.com> Message-ID: On Fri, 8 Jan 2021 14:46:14 GMT, Harold Seigel wrote: >> Please review this change to remove the JVM develop flag UseStackBanging and always use stack banging. >> >> The change was tested with tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and cross-builds on PPC64, Linux32, and S390x. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > minor comment changes Changes requested by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From kvn at openjdk.java.net Fri Jan 8 20:35:04 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 8 Jan 2021 20:35:04 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 14:41:12 GMT, Harold Seigel wrote: >> Please review this change to remove the JVM develop flag UseStackBanging and always use stack banging. >> >> The change was tested with tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and cross-builds on PPC64, Linux32, and S390x. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix copyrights, other minot changes src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java line 256: > 254: public final int stackShadowPages = getFlag("StackShadowPages", Integer.class); > 255: public final int stackReservedPages = getFlag("StackReservedPages", Integer.class, 0, JDK >= 9); > 256: public final int stackBias = getConstant("STACK_BIAS", Integer.class, 0, JDK < 15); The line should be modified instead of removal: public final boolean useStackBanging = getFlag("UseStackBanging", Boolean.class, true, JDK < 17); @dougxc please note that it should be upstreamed when GraalVM adopt JDK 17. src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java line 133: > 131: > 132: public void emitStackOverflowCheck(CompilationResultBuilder crb) { > 133: // Each code entry causes one stack bang n pages down the stack where n I think you can leave this file unchanged with my suggested modification in GraalHotSpotVMConfig.java. ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From hseigel at openjdk.java.net Fri Jan 8 20:48:55 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 8 Jan 2021 20:48:55 GMT Subject: RFR: 8258908: Remove JVM option CleanChunkPoolAsync In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 06:18:01 GMT, David Holmes wrote: >> Please review this small change to remove JVM develop option CleanChunkPoolAsync. The option was originally added for embedded builds so they could clean chunk pools synchronouosly. >> >> The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Hi Harold, > Thanks for cleaning this up, it probably should have been done as part of, or a follow up to, 8140723. > > Thanks, > David Thanks David! Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1949 From dnsimon at openjdk.java.net Fri Jan 8 21:49:04 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 8 Jan 2021 21:49:04 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v3] In-Reply-To: References: <6rQJahQ2wG0MPbf6BQ39B1qhHZc73MLyOK1n0ufY2RE=.b727c7ba-4cc7-411e-91b3-c14e8fa41eed@github.com> Message-ID: On Fri, 8 Jan 2021 20:32:32 GMT, Vladimir Kozlov wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> minor comment changes > > Changes requested by kvn (Reviewer). If you follow @vnkozlov 's feedback, the Graal/JVMCI aspects of this change look fine to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From dnsimon at openjdk.java.net Fri Jan 8 21:49:05 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 8 Jan 2021 21:49:05 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v2] In-Reply-To: References: Message-ID: <_uwGpfXfxNS3LRSrqFgBRv0Y6YvzvVXIKlelCMSQYFU=.d5c20e4f-da73-4f97-bb16-b419be12d983@github.com> On Fri, 8 Jan 2021 20:23:53 GMT, Vladimir Kozlov wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> fix copyrights, other minot changes > > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java line 256: > >> 254: public final int stackShadowPages = getFlag("StackShadowPages", Integer.class); >> 255: public final int stackReservedPages = getFlag("StackReservedPages", Integer.class, 0, JDK >= 9); >> 256: public final int stackBias = getConstant("STACK_BIAS", Integer.class, 0, JDK < 15); > > The line should be modified instead of removal: > public final boolean useStackBanging = getFlag("UseStackBanging", Boolean.class, true, JDK < 17); > @dougxc please note that it should be upstreamed when GraalVM adopt JDK 17. The good thing is that the VM will fail fail when initializing Graal if the update is not done so there's no way we can overlook it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From cjplummer at openjdk.java.net Fri Jan 8 21:51:07 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 8 Jan 2021 21:51:07 GMT Subject: RFR: 8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping Message-ID: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> There is an assert in `JvmtiThreadState::cur_stack_depth()` that tends to slow down single stepping a lot when running the debuggee with a debug jvm. See CR for details. The fix is to allow disabling of this assert using the new EnableJVMTIStackDepthAsserts global, which defaults to true. ------------- Commit messages: - Update copyrights - Get rid of asserts that were added to incr() and decre() in previous commit. - Add EnableJVMTIStackDepthAsserts global to control the enabling of the JVMTI stack depth asserts. Changes: https://git.openjdk.java.net/jdk/pull/1835/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1835&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258652 Stats: 13 lines in 2 files changed: 8 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1835.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1835/head:pull/1835 PR: https://git.openjdk.java.net/jdk/pull/1835 From dholmes at openjdk.java.net Fri Jan 8 21:51:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Jan 2021 21:51:07 GMT Subject: RFR: 8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping In-Reply-To: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> References: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> Message-ID: On Fri, 18 Dec 2020 02:01:28 GMT, Chris Plummer wrote: > There is an assert in `JvmtiThreadState::cur_stack_depth()` that tends to slow down single stepping a lot when running the debuggee with a debug jvm. See CR for details. The fix is to allow disabling of this assert using the new EnableJVMTIStackDepthAsserts global, which defaults to true. This works but I'm concerned if this sets a precedent for adding expensive assertions? Do we already have similar flags? ------------- PR: https://git.openjdk.java.net/jdk/pull/1835 From cjplummer at openjdk.java.net Fri Jan 8 21:51:07 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 8 Jan 2021 21:51:07 GMT Subject: RFR: 8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping In-Reply-To: References: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> Message-ID: On Fri, 18 Dec 2020 02:19:28 GMT, David Holmes wrote: > This works but I'm concerned if this sets a precedent for adding expensive assertions? Do we already have similar flags? @dholmes-ora The one expensive assert is already there. I have since removed the two additional expensive asserts for the incr() and decr() APIs. I don't know of any other similar flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/1835 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 dongbo at openjdk.java.net Sat Jan 9 08:16:55 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Sat, 9 Jan 2021 08:16:55 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 09:52:02 GMT, Andrew Haley wrote: >> Hi, >> >> As the experiment shows, we do not gain improvements with these. >> >> For `Math.max(max, Math.abs(floatsA[i] - floatsB[i]))`, the code is not vectorized if `COUNT < 12`. >> When `COUNT == 12`, the node we have is not `Max2F` but `Max4F`. >> The `Math.max(max, floatsA[i] - floatsB[i])` suffers same problem that it does not match `Max2F` with small `COUNT`. >> >> For `Math.max(max, floatsA[i])`, it is not auto-vectorized even with `COUNT = 512`. >> I think the auto-vectorized optimization for this is disabled by JDK-8078563 [1]. >> >> One of the advantages of `Max2F with fmaxp` can gain for `VectorAPI`, the test code is available in [2]. >> We witnessed about `12%` improvements for `reduceLanes(VectorOperators.MAX)` of `FloatVector.SPECIES_64`: >> Benchmark (COUNT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReduction2FMinMax.maxRed2F 512 0 avgt 10 667.173 ? 0.576 ns/op >> VectorReduction2FMinMax.minRed2F 512 0 avgt 10 667.172 ? 0.649 ns/op >> # Kunpeng 916, with fmaxp/fminp >> VectorReduction2FMinMax.maxRed2F 512 0 avgt 10 592.404 ? 0.885 ns/op >> VectorReduction2FMinMax.minRed2F 512 0 avgt 10 592.293 ? 0.607 ns/op >> >> I agree the testcode for `floats` in `VectorReductionFloatingMinMax.java` is contrived. >> Do you think we should replace the tests for `MinMaxF` in `VectorReductionFloatingMinMax` with tests in [2]? >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8078563 >> [2] [VectorReduction2FMinMax.java.txt](https://github.com/openjdk/jdk/files/5784948/VectorReduction2FMinMax.java.txt) > > I don't think the real problem is only the tests, it's that common cases don't get vectorized. > Can we fix this code so that it works with ```Math.abs()``` ? > Are there any examples of plausible Java code that benefit from this optimization? According to the results of `JMH perfasm`, `Math.max(max, Math.abs(floatsA[i] - floatsB[i]))` is vectorized when `COUNT=8` on a X86 platform. While on aarch64, `floatsB[i] = Math.abs(floatsA[i])` is not vectorized when `COUNT = 10` and we can not match `Max2F` for `AbsF` neither. I am going to investigate the failed vectorization and see if we can have `Max2F` matched. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From sspitsyn at openjdk.java.net Sat Jan 9 09:36:56 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sat, 9 Jan 2021 09:36:56 GMT Subject: RFR: 8259482: jni_Set/GetField_probe are the same as their _nh versions In-Reply-To: <-KyDin9aId3_tTdCVPJdIddjJR6AjQReRFJdvOIpYvg=.057bc24e-fee7-4284-a2b5-6e02fa8ecf0f@github.com> References: <-KyDin9aId3_tTdCVPJdIddjJR6AjQReRFJdvOIpYvg=.057bc24e-fee7-4284-a2b5-6e02fa8ecf0f@github.com> Message-ID: On Fri, 8 Jan 2021 19:32:36 GMT, Coleen Phillimore wrote: > Remove the _nh versions. Tested with tier1 and vmTestbase/nsk/jdi,jvmti tests. LGTM++ Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2008 From david.holmes at oracle.com Sat Jan 9 13:10:23 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 9 Jan 2021 23:10:23 +1000 Subject: Linux signals In-Reply-To: References: Message-ID: <877d9b7e-5d36-91c4-6025-04057e0707cf@oracle.com> Hi Walt, On 9/01/2021 2:22 am, Walt Drummond wrote: > Hi David -- > > Sorry, I've come to appreciate the confusion this causes; I can't tell > if by 'thread' you mean a java thread or a POSIX thread. :) To help > punch through some of that, I'm going to be a bit pedantic, apologies > in advance. In hotspot there is a 1:1 correspondence between a Java thread and OS/Posix thread. > When the kernel delivers a signal to a process/thread (in the Linux > sense of the term), it places some data on the process stack. That > data includes the parameters to the POSIX signal hander (signal > number, a siginfo_t, and a ucontext_t). Above that in the stack, the > kernel also places FPU state and, on AMD64, extended state > information. My question is does the JVM directly inspect the JVM > program stack when running the POSIX signal handler(s). My current > understanding is that it does not and only relies on the POSIX signals > APIs and data structures from libc. As I stated before the JVM signal handler may inspect the stack, or it may not, depending on the nature of the signal it is processing - crash reporting can do a lot of things from the signal handler. You can see the main signal handler here: https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/signals_posix.cpp#L525 What is the context for asking the question? Cheers, David ----- > Thanks, and sorry for the confusion. > > On Thu, Jan 7, 2021 at 8:30 PM David Holmes wrote: >> >> Hi Walt, >> >> On 8/01/2021 7:18 am, Walt Drummond wrote: >>> Hi -- >>> >>> I'm chasing down some information about how the JVM interacts with >>> signals on Linux. Specifically I need to understand if any of the >>> Java runtime attempts to directly inspect the system stack when in a >>> POSIX signal handler. My survey of the code doesn't seem to show any >>> such uses, and in fact it looks like the JVM relies only on the POSIX >>> signals API but I figured I'd ask the experts for confirmation. >> >> I'm not quite sure what you are asking with regards to the "system >> stack". The hotspot signal handler does a range of things to try and >> determine what the signal might mean - e.g. whether it is a true error >> or an internal use of signals that we can recover from. That may involve >> examining the thread stack. >> >> Cheers, >> David >> ----- >> >>> Thanks. >>> --Walt >>> From david.holmes at oracle.com Sat Jan 9 13:31:19 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 9 Jan 2021 23:31:19 +1000 Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: <5u0LgLfOfCoE0wUTAkH0G_43mb41UljWgpNBocm_cLc=.e1b7dd10-8716-47d8-89f3-990aff32d2c4@github.com> References: <5u0LgLfOfCoE0wUTAkH0G_43mb41UljWgpNBocm_cLc=.e1b7dd10-8716-47d8-89f3-990aff32d2c4@github.com> Message-ID: <4e46b4c2-3056-1156-3d67-aa61cced8c41@oracle.com> On 8/01/2021 11:43 pm, Coleen Phillimore wrote: > On Fri, 8 Jan 2021 06:52:43 GMT, David Holmes wrote: > >>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >>> >>> fix grammar >> >> src/hotspot/share/runtime/handles.hpp line 293: >> >>> 291: // ResetNoHandleMark is called in a context where there is an enclosing >>> 292: // NoHandleMark. A thread in _thread_in_native must not create handles so >>> 293: // this is used when transitioning via ThreadInVMfromNative. >> >> This comment still doesn't clearly (to me) explain the use of RNHM. Basically it is intended to "disable" a NHM further up the stack but why do we not force the caller up the stack to correctly scope the NMH? This seems to be a way to allow sloppy coding further up the stack, or worse it allows code to be called that might use Handles completely unexpectedly wrt the code up the stack. Should a NHM not mean "this code and all code called from it must not use Handles"? >> >> And can't this be used in a range of contexts not just this ThreadInVMFromNative transition? >> >> Thanks, >> David > > Yes so the NHM does mean "this code and all code called from this must not use handles" which is why it appears in the JNI_LEAF and JVM_LEAF. Handles and oops are not safe in VM code whose state is _thread_in_native. > So the interesting scenario here is: > > JNI_LEAF(some function) { > do some things that don't allow oops or Handles (the NHM will cause an assertion to help make sure this is the case) > // Oh rats, we need to go into the VM maybe conditionally > ThreadInVMFromNative tivm; > // Now handles are cool. Any function that does that should not be a JNI_LEAF! (That is assuming a JNI_LEAF is the JNI equivalent of JRT_LEAF and has similar restrictions.) What JNI_LEAF function does as you describe? Thanks, David ----- > } > This change embeds the ResetNoHandleMark in the ThreadInVMFromNative so that all the callers don't require it. > > The caller up the stack is the JNI_LEAF generally where we generally want NoHandleMark. > > The transitions from Java to VM don't require this because my n+1 change lifts the no Handle restrictions. This is the only case where this pattern is needed in the callers. My goal with this is to reduce the intellectual noise required to read this and figure out why it's needed that is littered around the source code. > > I'm not sure what to say in this comment that explains this better, please suggest better wording. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1983 > From walt at drummond.us Sat Jan 9 21:10:57 2021 From: walt at drummond.us (Walt Drummond) Date: Sat, 9 Jan 2021 13:10:57 -0800 Subject: Linux signals In-Reply-To: <877d9b7e-5d36-91c4-6025-04057e0707cf@oracle.com> References: <877d9b7e-5d36-91c4-6025-04057e0707cf@oracle.com> Message-ID: Context: I'm chasing down concerns that increasing the size of the kernel's definition of sigset_t would break userspace. This only seems plausible if (1) on receipt of a signal user space tries to unwind or directly interpret the program stack frame or (2) the application uses a definition of sigset_t that is not derived from glibc. From what I see here, neither of these are the case. The JVM inspects the state of the stack by looking at the ucontext_t structure passed to it from the kernel and it exclusively uses the POSIX signals APIs and the system libc. On Sat, Jan 9, 2021 at 5:10 AM David Holmes wrote: > > Hi Walt, > > On 9/01/2021 2:22 am, Walt Drummond wrote: > > Hi David -- > > > > Sorry, I've come to appreciate the confusion this causes; I can't tell > > if by 'thread' you mean a java thread or a POSIX thread. :) To help > > punch through some of that, I'm going to be a bit pedantic, apologies > > in advance. > > In hotspot there is a 1:1 correspondence between a Java thread and > OS/Posix thread. > > > When the kernel delivers a signal to a process/thread (in the Linux > > sense of the term), it places some data on the process stack. That > > data includes the parameters to the POSIX signal hander (signal > > number, a siginfo_t, and a ucontext_t). Above that in the stack, the > > kernel also places FPU state and, on AMD64, extended state > > information. My question is does the JVM directly inspect the JVM > > program stack when running the POSIX signal handler(s). My current > > understanding is that it does not and only relies on the POSIX signals > > APIs and data structures from libc. > > As I stated before the JVM signal handler may inspect the stack, or it > may not, depending on the nature of the signal it is processing - crash > reporting can do a lot of things from the signal handler. You can see > the main signal handler here: > > https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/signals_posix.cpp#L525 > > What is the context for asking the question? > > Cheers, > David > ----- > > > > Thanks, and sorry for the confusion. > > > > On Thu, Jan 7, 2021 at 8:30 PM David Holmes wrote: > >> > >> Hi Walt, > >> > >> On 8/01/2021 7:18 am, Walt Drummond wrote: > >>> Hi -- > >>> > >>> I'm chasing down some information about how the JVM interacts with > >>> signals on Linux. Specifically I need to understand if any of the > >>> Java runtime attempts to directly inspect the system stack when in a > >>> POSIX signal handler. My survey of the code doesn't seem to show any > >>> such uses, and in fact it looks like the JVM relies only on the POSIX > >>> signals API but I figured I'd ask the experts for confirmation. > >> > >> I'm not quite sure what you are asking with regards to the "system > >> stack". The hotspot signal handler does a range of things to try and > >> determine what the signal might mean - e.g. whether it is a true error > >> or an internal use of signals that we can recover from. That may involve > >> examining the thread stack. > >> > >> Cheers, > >> David > >> ----- > >> > >>> Thanks. > >>> --Walt > >>> From david.holmes at oracle.com Sat Jan 9 23:42:32 2021 From: david.holmes at oracle.com (David Holmes) Date: Sun, 10 Jan 2021 09:42:32 +1000 Subject: Linux signals In-Reply-To: References: <877d9b7e-5d36-91c4-6025-04057e0707cf@oracle.com> Message-ID: On 10/01/2021 7:10 am, Walt Drummond wrote: > Context: I'm chasing down concerns that increasing the size of the > kernel's definition of sigset_t would break userspace. This only > seems plausible if (1) on receipt of a signal user space tries to > unwind or directly interpret the program stack frame or (2) the > application uses a definition of sigset_t that is not derived from > glibc. From what I see here, neither of these are the case. The JVM > inspects the state of the stack by looking at the ucontext_t structure > passed to it from the kernel and it exclusively uses the POSIX signals > APIs and the system libc. Thanks for the info. I think we should be all good on that front. David > On Sat, Jan 9, 2021 at 5:10 AM David Holmes wrote: >> >> Hi Walt, >> >> On 9/01/2021 2:22 am, Walt Drummond wrote: >>> Hi David -- >>> >>> Sorry, I've come to appreciate the confusion this causes; I can't tell >>> if by 'thread' you mean a java thread or a POSIX thread. :) To help >>> punch through some of that, I'm going to be a bit pedantic, apologies >>> in advance. >> >> In hotspot there is a 1:1 correspondence between a Java thread and >> OS/Posix thread. >> >>> When the kernel delivers a signal to a process/thread (in the Linux >>> sense of the term), it places some data on the process stack. That >>> data includes the parameters to the POSIX signal hander (signal >>> number, a siginfo_t, and a ucontext_t). Above that in the stack, the >>> kernel also places FPU state and, on AMD64, extended state >>> information. My question is does the JVM directly inspect the JVM >>> program stack when running the POSIX signal handler(s). My current >>> understanding is that it does not and only relies on the POSIX signals >>> APIs and data structures from libc. >> >> As I stated before the JVM signal handler may inspect the stack, or it >> may not, depending on the nature of the signal it is processing - crash >> reporting can do a lot of things from the signal handler. You can see >> the main signal handler here: >> >> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/signals_posix.cpp#L525 >> >> What is the context for asking the question? >> >> Cheers, >> David >> ----- >> >> >>> Thanks, and sorry for the confusion. >>> >>> On Thu, Jan 7, 2021 at 8:30 PM David Holmes wrote: >>>> >>>> Hi Walt, >>>> >>>> On 8/01/2021 7:18 am, Walt Drummond wrote: >>>>> Hi -- >>>>> >>>>> I'm chasing down some information about how the JVM interacts with >>>>> signals on Linux. Specifically I need to understand if any of the >>>>> Java runtime attempts to directly inspect the system stack when in a >>>>> POSIX signal handler. My survey of the code doesn't seem to show any >>>>> such uses, and in fact it looks like the JVM relies only on the POSIX >>>>> signals API but I figured I'd ask the experts for confirmation. >>>> >>>> I'm not quite sure what you are asking with regards to the "system >>>> stack". The hotspot signal handler does a range of things to try and >>>> determine what the signal might mean - e.g. whether it is a true error >>>> or an internal use of signals that we can recover from. That may involve >>>> examining the thread stack. >>>> >>>> Cheers, >>>> David >>>> ----- >>>> >>>>> Thanks. >>>>> --Walt >>>>> From walt at drummond.us Sat Jan 9 23:46:19 2021 From: walt at drummond.us (Walt Drummond) Date: Sat, 9 Jan 2021 15:46:19 -0800 Subject: Linux signals In-Reply-To: References: <877d9b7e-5d36-91c4-6025-04057e0707cf@oracle.com> Message-ID: Thank you. Appreciate it. On Sat, Jan 9, 2021 at 3:44 PM David Holmes wrote: > > On 10/01/2021 7:10 am, Walt Drummond wrote: > > Context: I'm chasing down concerns that increasing the size of the > > kernel's definition of sigset_t would break userspace. This only > > seems plausible if (1) on receipt of a signal user space tries to > > unwind or directly interpret the program stack frame or (2) the > > application uses a definition of sigset_t that is not derived from > > glibc. From what I see here, neither of these are the case. The JVM > > inspects the state of the stack by looking at the ucontext_t structure > > passed to it from the kernel and it exclusively uses the POSIX signals > > APIs and the system libc. > > Thanks for the info. I think we should be all good on that front. > > David > > > On Sat, Jan 9, 2021 at 5:10 AM David Holmes wrote: > >> > >> Hi Walt, > >> > >> On 9/01/2021 2:22 am, Walt Drummond wrote: > >>> Hi David -- > >>> > >>> Sorry, I've come to appreciate the confusion this causes; I can't tell > >>> if by 'thread' you mean a java thread or a POSIX thread. :) To help > >>> punch through some of that, I'm going to be a bit pedantic, apologies > >>> in advance. > >> > >> In hotspot there is a 1:1 correspondence between a Java thread and > >> OS/Posix thread. > >> > >>> When the kernel delivers a signal to a process/thread (in the Linux > >>> sense of the term), it places some data on the process stack. That > >>> data includes the parameters to the POSIX signal hander (signal > >>> number, a siginfo_t, and a ucontext_t). Above that in the stack, the > >>> kernel also places FPU state and, on AMD64, extended state > >>> information. My question is does the JVM directly inspect the JVM > >>> program stack when running the POSIX signal handler(s). My current > >>> understanding is that it does not and only relies on the POSIX signals > >>> APIs and data structures from libc. > >> > >> As I stated before the JVM signal handler may inspect the stack, or it > >> may not, depending on the nature of the signal it is processing - crash > >> reporting can do a lot of things from the signal handler. You can see > >> the main signal handler here: > >> > >> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/signals_posix.cpp#L525 > >> > >> What is the context for asking the question? > >> > >> Cheers, > >> David > >> ----- > >> > >> > >>> Thanks, and sorry for the confusion. > >>> > >>> On Thu, Jan 7, 2021 at 8:30 PM David Holmes wrote: > >>>> > >>>> Hi Walt, > >>>> > >>>> On 8/01/2021 7:18 am, Walt Drummond wrote: > >>>>> Hi -- > >>>>> > >>>>> I'm chasing down some information about how the JVM interacts with > >>>>> signals on Linux. Specifically I need to understand if any of the > >>>>> Java runtime attempts to directly inspect the system stack when in a > >>>>> POSIX signal handler. My survey of the code doesn't seem to show any > >>>>> such uses, and in fact it looks like the JVM relies only on the POSIX > >>>>> signals API but I figured I'd ask the experts for confirmation. > >>>> > >>>> I'm not quite sure what you are asking with regards to the "system > >>>> stack". The hotspot signal handler does a range of things to try and > >>>> determine what the signal might mean - e.g. whether it is a true error > >>>> or an internal use of signals that we can recover from. That may involve > >>>> examining the thread stack. > >>>> > >>>> Cheers, > >>>> David > >>>> ----- > >>>> > >>>>> Thanks. > >>>>> --Walt > >>>>> From cvdcamilleri at gmail.com Sun Jan 10 16:33:14 2021 From: cvdcamilleri at gmail.com (Charlie) Date: Sun, 10 Jan 2021 16:33:14 +0000 Subject: JVMTI Class load callback not being called on Windows, but works on Linux Message-ID: <6b650f6d-4f7e-d75a-2cc1-ea96336256e5@gmail.com> Hi, I have a working jvmti agent on Linux (Java(TM) SE Runtime Environment (build 1.8.0_271-b09)) that hooks the class load event. This same agent compiled for windows claims to work (all asserts pass), but my hook never gets called, is anyone able to tell me why? I register my callback like so: jint res = vm->GetEnv(reinterpret_cast(&jvmti), JVMTI_VERSION_1); ??? if (res != JNI_OK || jvmti==nullptr) { ??????? fprintf(stderr,"Unable to get JVMTI!"); ??? } ??? assert(res == JVMTI_ERROR_NONE); ??? jvmtiCapabilities capabilities = {0}; ??? capabilities.can_retransform_classes=1; ??? capabilities.can_generate_all_class_hook_events? = 1; ??? assert(jvmti->AddCapabilities(&capabilities) == JVMTI_ERROR_NONE); ??? jvmtiEventCallbacks callbacks; ??? memset(&callbacks,0,sizeof(callbacks)); ??? callbacks.ClassFileLoadHook = &class_file_load_hook_handler; ??? assert(jvmti->SetEventCallbacks(&callbacks, sizeof(callbacks)) == JVMTI_ERROR_NONE); ??? assert(jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_CLASS_FILE_LOAD_HOOK, nullptr) == JVMTI_ERROR_NONE); The callback itself is as follows: static void JNICALL class_file_load_hook_handler( ??????? jvmtiEnv* jvmti, ??????? JNIEnv* env, ??????? jclass class_being_redefined, ??????? jobject loader, ??????? const char* name, ??????? jobject protection_domain, ??????? jint class_data_len, ??????? const unsigned char* class_data, ??????? jint* new_class_data_len, ??????? unsigned char** new_class_data ) { ??? if (name == nullptr) { ??????? return; ??? } ??? printf("loaded %s\n",name); } (to clarify, all JNI functions in the lib work fine) The Windows machine's java version string is this: java version "1.8.0_271" Java(TM) SE Runtime Environment (build 1.8.0_271-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode) From mikael.vidstedt at oracle.com Sun Jan 10 23:09:24 2021 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Sun, 10 Jan 2021 15:09:24 -0800 Subject: JVMTI Class load callback not being called on Windows, but works on Linux In-Reply-To: <6b650f6d-4f7e-d75a-2cc1-ea96336256e5@gmail.com> References: <6b650f6d-4f7e-d75a-2cc1-ea96336256e5@gmail.com> Message-ID: <01C7DD0F-B495-465A-BF06-31CC28217FF6@oracle.com> Just a control question: Are you *sure* asserts are actually enabled? Having actual application logic in an assert is normally a bad idea because if/when you compile the release/production version with asserts disabled the application behavior will change. Cheers, Mikael > On Jan 10, 2021, at 8:33 AM, Charlie wrote: > > Hi, > > I have a working jvmti agent on Linux (Java(TM) SE Runtime Environment (build 1.8.0_271-b09)) that hooks the class load event. > > This same agent compiled for windows claims to work (all asserts pass), but my hook never gets called, is anyone able to tell me why? > > I register my callback like so: > > jint res = vm->GetEnv(reinterpret_cast(&jvmti), JVMTI_VERSION_1); > if (res != JNI_OK || jvmti==nullptr) { > fprintf(stderr,"Unable to get JVMTI!"); > } > assert(res == JVMTI_ERROR_NONE); > > jvmtiCapabilities capabilities = {0}; > capabilities.can_retransform_classes=1; > capabilities.can_generate_all_class_hook_events = 1; > > assert(jvmti->AddCapabilities(&capabilities) == JVMTI_ERROR_NONE); > > jvmtiEventCallbacks callbacks; > memset(&callbacks,0,sizeof(callbacks)); > callbacks.ClassFileLoadHook = &class_file_load_hook_handler; > assert(jvmti->SetEventCallbacks(&callbacks, sizeof(callbacks)) == JVMTI_ERROR_NONE); > assert(jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_CLASS_FILE_LOAD_HOOK, nullptr) == JVMTI_ERROR_NONE); > > The callback itself is as follows: > > static void JNICALL class_file_load_hook_handler( > jvmtiEnv* jvmti, > JNIEnv* env, > jclass class_being_redefined, > jobject loader, > const char* name, > jobject protection_domain, > jint class_data_len, > const unsigned char* class_data, > jint* new_class_data_len, > unsigned char** new_class_data > ) { > if (name == nullptr) { > return; > } > > printf("loaded %s\n",name); > > } > > (to clarify, all JNI functions in the lib work fine) > > The Windows machine's java version string is this: > > java version "1.8.0_271" > Java(TM) SE Runtime Environment (build 1.8.0_271-b09) > Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode) > From dholmes at openjdk.java.net Mon Jan 11 00:47:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Jan 2021 00:47:55 GMT Subject: RFR: 8259482: jni_Set/GetField_probe are the same as their _nh versions In-Reply-To: <-KyDin9aId3_tTdCVPJdIddjJR6AjQReRFJdvOIpYvg=.057bc24e-fee7-4284-a2b5-6e02fa8ecf0f@github.com> References: <-KyDin9aId3_tTdCVPJdIddjJR6AjQReRFJdvOIpYvg=.057bc24e-fee7-4284-a2b5-6e02fa8ecf0f@github.com> Message-ID: On Fri, 8 Jan 2021 19:32:36 GMT, Coleen Phillimore wrote: > Remove the _nh versions. Tested with tier1 and vmTestbase/nsk/jdi,jvmti tests. Cleanup looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2008 From dholmes at openjdk.java.net Mon Jan 11 01:28:57 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Jan 2021 01:28:57 GMT Subject: RFR: 8259486: Remove CautiouslyPreserveExceptionMark In-Reply-To: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: On Fri, 8 Jan 2021 16:58:15 GMT, Coleen Phillimore wrote: > See CR for details. This is a hopefully simple cleanup. I didn't try to reason about removing any of these except an obvious call (if you look above the patch in thread.cpp). > Tested with tier1-3. Hi Coleen, AFAICS you are not simply removing CautiouslyPreserveExceptionMark but you are changing PreserveExceptionMark to now act as CautiouslyPreserveExceptionMark did. If the PEM now encounters an unexpected exception it is no longer fatal. This relaxation is not unreasonable but I think the bug synopsis and description need to be updated to reflect what you are actually doing. I agree "Cautiously" was not a good word for distinguishing the two responses here. I also think WeakPEM is not great either. :( A couple of minor comments elsewhere. Thanks, David src/hotspot/share/classfile/javaClasses.cpp line 2528: > 2526: if (total_count == 0) { > 2527: // The top frame will be hidden from the stack trace. > 2528: bt.set_has_hidden_top_frame(); To be clear: no exception can become pending due to this call, so no need for CHECK. src/hotspot/share/classfile/javaClasses.cpp line 2556: > 2554: > 2555: JavaThread* thread = JavaThread::active(); > 2556: PreserveExceptionMark pm(thread); The result of JavaThread::active() is not necessarily the current thread. So either the new code is wrong or else we should just be using JavaThread::current() src/hotspot/share/runtime/thread.cpp line 1867: > 1865: // Call method Thread.dispatchUncaughtException(). > 1866: Klass* thread_klass = SystemDictionary::Thread_klass(); > 1867: JavaValue result(T_VOID); I think I agree that this is redundant. Seems to be a leftover from something else. ------------- PR: https://git.openjdk.java.net/jdk/pull/2007 From david.holmes at oracle.com Mon Jan 11 02:01:42 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Jan 2021 12:01:42 +1000 Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: <67dfcdae-be37-f702-71cf-f58079322824@oracle.com> On 8/01/2021 4:09 pm, Igor Veresov wrote: > On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote: > >>> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Fix s390 build >> >> Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. > > Please find the answers in-line. > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >> >> Hi Igor, >> >> On 8/01/2021 6:36 am, Igor Veresov wrote: >> >>> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> Can you clarify, for non-compiler folk, what all the alternative configs >> actually mean now. I'm a bit confused by this definition: >> >> define_pd_global(bool, TieredCompilation, >> COMPILER1_PRESENT(true) NOT_COMPILER1(false)); > > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. Sorry I overlooked the exact placement. >> >> as I expected tiered compilation to require COMPILER1 and COMPILER2. >> > Right. That's exactly what's happening. > >> Also I see interpreter code that used to be guarded by TieredCompilation >> now being executed unconditionally, which seems to assume C1 or C2 must >> be present? >> > > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. That is not at all obvious. For example in templateInterpreterGenerator_aarch64.cpp this code used to guarded by TieredCompilation: 608: __ bind(no_mdo); // Increment counter in MethodCounters const Address invocation_counter(rscratch2, MethodCounters::invocation_counter_offset() + InvocationCounter::counter_offset()); __ get_method_counters(rmethod, rscratch2, done); const Address mask(rscratch2, in_bytes(MethodCounters::invoke_mask_offset())); __ increment_mask_and_jump(invocation_counter, increment, mask, rscratch1, r1, false, Assembler::EQ, overflow); __ bind(done); but now it seems to be executed unconditionally with no reference to either flag you mentioned. > >> Overall it is a big change to digest, but after skimming it looks like a >> few of the refactorings could have been applied in a layered fashion >> using multiple commits to make it easier to review. >> > > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. I was thinking the ifdef related changes as one commit; then the TieredCompilation removals; then the addition of CompilerConfig API ... These aren't separate changes just different commits within the PR so that it can be reviewed in stages. Cheers, David ----- > As far as the runtime part of the change is concerted, it's pretty much only the legacy policy removal. In particular, the parts of the interpreter that dealt with the old policy (basically everything in the interpreter that was under !TieredCompilation has gotten removed). > > Igor > >> Thanks, >> David >> ----- > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1985 > 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 iveresov at openjdk.java.net Mon Jan 11 02:56:57 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Mon, 11 Jan 2021 02:56:57 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Fri, 8 Jan 2021 06:29:10 GMT, Igor Veresov wrote: >> Please find the answers in-line. >> >>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >>> >>> Hi Igor, >>> >>> On 8/01/2021 6:36 am, Igor Veresov wrote: >>> >>> > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >>> >>> Can you clarify, for non-compiler folk, what all the alternative configs >>> actually mean now. I'm a bit confused by this definition: >>> >>> define_pd_global(bool, TieredCompilation, >>> COMPILER1_PRESENT(true) NOT_COMPILER1(false)); >> >> That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. >>> >>> as I expected tiered compilation to require COMPILER1 and COMPILER2. >>> >> Right. That's exactly what's happening. >> >>> Also I see interpreter code that used to be guarded by TieredCompilation >>> now being executed unconditionally, which seems to assume C1 or C2 must >>> be present? >>> >> >> Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. >> >>> Overall it is a big change to digest, but after skimming it looks like a >>> few of the refactorings could have been applied in a layered fashion >>> using multiple commits to make it easier to review. >>> >> >> Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. >> >> As far as the runtime part of the change is concerted, it's pretty much only the legacy policy removal. In particular, the parts of the interpreter that dealt with the old policy (basically everything in the interpreter that was under !TieredCompilation has gotten removed). >> >> Igor >> >>> Thanks, >>> David >>> ----- > > To clarify the possible configs. > 1. There is only one policy now. Functions with both compilers or a single compiler. > 2. The best way to control the operation mode is with the ```-XX:CompilationMode=``` flag. Possible values so far are: normal (aka default), high-only (c2 or graal only), quick-only(c1 only), high-only-quick-internal (a special mode for jar graal where only graal itself is compiled by c1, but the user code is compiled with graal). > 3. There is a mode that emulates the behavior when the user specifies -TieredCompilation. That's basically the high-only mode. > 4. There is also support for legacy policy flags such as CompileThreshold, which would properly setup the policy parameters to match the old behavior. Dave, I'm answering inline. > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ > > On 8/01/2021 4:09 pm, Igor Veresov wrote: > > > On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote: > > > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > > > Fix s390 build > > > > > > > > > Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. > > > > > > Please find the answers in-line. > > > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ > > > Hi Igor, > > > On 8/01/2021 6:36 am, Igor Veresov wrote: > > > > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > > > > > > > > Can you clarify, for non-compiler folk, what all the alternative configs > > > actually mean now. I'm a bit confused by this definition: > > > define_pd_global(bool, TieredCompilation, > > > COMPILER1_PRESENT(true) NOT_COMPILER1(false)); > > > > > > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. > > Sorry I overlooked the exact placement. > > > > as I expected tiered compilation to require COMPILER1 and COMPILER2. > > > > > > Right. That's exactly what's happening. > > > Also I see interpreter code that used to be guarded by TieredCompilation > > > now being executed unconditionally, which seems to assume C1 or C2 must > > > be present? > > > > > > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. > > That is not at all obvious. For example in > templateInterpreterGenerator_aarch64.cpp this code used to guarded by > TieredCompilation: > > 608: __ bind(no_mdo); > // Increment counter in MethodCounters > const Address invocation_counter(rscratch2, > MethodCounters::invocation_counter_offset() + > InvocationCounter::counter_offset()); > __ get_method_counters(rmethod, rscratch2, done); > const Address mask(rscratch2, > in_bytes(MethodCounters::invoke_mask_offset())); > __ increment_mask_and_jump(invocation_counter, increment, mask, > rscratch1, r1, false, Assembler::EQ, overflow); > __ bind(done); This code is in generate_counter_incr() each call to which is guarded by ```if (inc_counter)```, and ```inc_counter``` is defined as ``` bool inc_counter = UseCompiler || CountCompiledCalls || LogTouchedMethods;```. Again, I haven't changed that at all, that how it always worked. We may try to tidy this up but I feel like this change is big enough already. > > but now it seems to be executed unconditionally with no reference to > either flag you mentioned. > > > > Overall it is a big change to digest, but after skimming it looks like a > > > few of the refactorings could have been applied in a layered fashion > > > using multiple commits to make it easier to review. > > > > > > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. > > I was thinking the ifdef related changes as one commit; then the > TieredCompilation removals; then the addition of CompilerConfig API ... > > These aren't separate changes just different commits within the PR so > that it can be reviewed in stages. I could've done that, I guess, but I usually like to make my checkpoints compilable. Sorry. > > Cheers, > David > ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From dongbo at openjdk.java.net Mon Jan 11 05:14:21 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 11 Jan 2021 05:14:21 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v5] In-Reply-To: References: Message-ID: > This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. > > Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. > Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. > > Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. > Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op > VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op > VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op > VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op > > # Kunpeng 916, with fmaxp/fminp > VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% > VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op > VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% > VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: modify test code to match Max2F ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1925/files - new: https://git.openjdk.java.net/jdk/pull/1925/files/96dc92f8..f244ed01 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=03-04 Stats: 20 lines in 1 file changed: 7 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/1925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1925/head:pull/1925 PR: https://git.openjdk.java.net/jdk/pull/1925 From dongbo at openjdk.java.net Mon Jan 11 05:16:53 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 11 Jan 2021 05:16:53 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Sat, 9 Jan 2021 08:13:45 GMT, Dong Bo wrote: >> I don't think the real problem is only the tests, it's that common cases don't get vectorized. >> Can we fix this code so that it works with ```Math.abs()``` ? >> Are there any examples of plausible Java code that benefit from this optimization? > > According to the results of `JMH perfasm`, `Math.max(max, Math.abs(floatsA[i] - floatsB[i]))` is vectorized when `COUNT=8` on a X86 platform. > While on aarch64, `floatsB[i] = Math.abs(floatsA[i])` is not vectorized when `COUNT = 10` and we can not match `VAbs2F` neither. > I am going to investigate the failed vectorization and see if we can have `Max2F` matched. Thanks. Hi, I made a mistake to say that the code is not vectorized with `COUNT < 12`, seems that the percentages of vectorized code is too small to be catched by `JMH perfasm`. To observed if `Min/MaxReductionVNode` are created or not, I added a explicit print in `ReductionNode::make`, like: --- a/src/hotspot/share/opto/vectornode.cpp +++ b/src/hotspot/share/opto/vectornode.cpp @@ -961,7 +961,9 @@ ReductionNode* ReductionNode::make(int opc, Node *ctrl, Node* n1, Node* n2, Basi case Op_MinReductionV: return new MinReductionVNode(ctrl, n1, n2); - case Op_MaxReductionV: return new MaxReductionVNode(ctrl, n1, n2); + case Op_MaxReductionV: + warning("in ReductionNode::make, making a MaxReductionVNode, length %d", n2->bottom_type()->is_vect()->length()); + return new MaxReductionVNode(ctrl, n1, n2); case Op_AndReductionV: return new AndReductionVNode(ctrl, n1, n2); In my observation, we have `Max4F` when `COUNT >= 4`, it is resonable to create `Max4F` other than `Max2F`. The `Max2F` is created with `COUNT == 3` and `-XX:-SuperWordLoopUnrollAnalysis`. But I did not find any noticeable improvements with such a small percentage. The JMH has been updated, the performance results are: Benchmark (COUNT_DOUBLE) (COUNT_FLOAT) (seed) Mode Cnt Score Error Units # Kunpeng 916, default VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 677.778 ? 0.694 ns/op VectorReductionFloatingMinMax.maxRedF 512 3 0 avgt 10 21.016 ? 0.097 ns/op VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 677.633 ? 0.664 ns/op VectorReductionFloatingMinMax.minRedF 512 3 0 avgt 10 21.001 ? 0.019 ns/op # Kunpeng 916, fmaxp/fminp VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 425.776 ? 0.785 ns/op VectorReductionFloatingMinMax.maxRedF 512 3 0 avgt 10 20.883 ? 0.033 ns/op VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 426.177 ? 3.258 ns/op VectorReductionFloatingMinMax.minRedF 512 3 0 avgt 10 20.871 ? 0.044 ns/op ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From stuefe at openjdk.java.net Mon Jan 11 06:42:00 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 11 Jan 2021 06:42:00 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v2] In-Reply-To: <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com> References: <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com> <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com> Message-ID: On Tue, 5 Jan 2021 10:40:11 GMT, Andrew Dinn wrote: >> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year to 2021. > > src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 252: > >> 250: pc, info, NULL, NULL, 0, 0); >> 251: va_end(detail_args); >> 252: } > > I'm not sure it is ok to revert this code. The fix this is part of (for JDK-8255711) was provided explicitly to re-organize the flow of control for handling of fatal errors. Reverting this code appears to undermine the goal of that issue. I would like to get Thomas Stuefe's (@tstuefe) opinion on whether it is appropriate to abort the JVM here vs returning false before accepting this specific change. Sorry for the delay. I'll take a look. ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From stuefe at openjdk.java.net Mon Jan 11 07:00:01 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 11 Jan 2021 07:00:01 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v2] In-Reply-To: References: <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com> <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com> Message-ID: On Mon, 11 Jan 2021 06:39:27 GMT, Thomas Stuefe wrote: >> src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 252: >> >>> 250: pc, info, NULL, NULL, 0, 0); >>> 251: va_end(detail_args); >>> 252: } >> >> I'm not sure it is ok to revert this code. The fix this is part of (for JDK-8255711) was provided explicitly to re-organize the flow of control for handling of fatal errors. Reverting this code appears to undermine the goal of that issue. I would like to get Thomas Stuefe's (@tstuefe) opinion on whether it is appropriate to abort the JVM here vs returning false before accepting this specific change. > > Sorry for the delay. I'll take a look. Thanks for finding that, and for pinging me. Please revert this part of the change, I opened a separate issue for it (also affects ppc64): https://bugs.openjdk.java.net/browse/JDK-8259539. ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From njian at openjdk.java.net Mon Jan 11 07:30:15 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Mon, 11 Jan 2021 07:30:15 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v3] In-Reply-To: References: Message-ID: > After applying [1], some Vector API tests fail with SIGILL on SVE > system. The SIGILL was triggered by verify_ptrue before c2 compiled > function returns, which means that the preserved p7 register (as ptrue) > has been clobbered before returning to c2 compiled code. (p7 is not > preserved cross function calls, and system calls [2]). > > Currently we try to reinitialize ptrue at each entrypoint of returning > from non-c2 compiled code, which indicating possible C or system calls. > However, there's still one entrypoint missing, exception handling, as > we may jump to c2 compiled code for exception handler. See > OptoRuntime::generate_exception_blob(). > > Adding reinitialize_ptrue before jumping back to c2 compiled code in > generate_exception_blob() could solve those Vector API test failures. > Actually I had that in my initial test patch [3], I don't know why I > missed that in final patch... I reran tests with the same approach of > [3] and found that there's still something missing, the > nmethod_entry_barrier() in c2 function prolog. The barrier may call to > runtime code (see generate_method_entry_barrier()). To reduce the risk > of missing such reinitialize_ptrue in newly added code in future, I > think it would be better to do the reinitialize in > pop_call_clobbered_registers(). > > P.S. the SIGILL message is also not clear, it should print detailed > message as indicated by MacroAssembler::stop() call. This is caused by > JDK-8255711 removing the message printing code. This patch also adds it > back, so that it could print detailed message for abort. > > Tested with tier1-3 on SVE hardware. Also verified with the same > approach of patch [3] with jtreg tests hotspot_all_no_apps and > jdk:tier1-3 passed without incorrect ptrue value assertion failure. > > [1] https://github.com/openjdk/jdk/pull/1621 > [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst > [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: Revert signal handler changes, which will be fixed in JDK-8259539. ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/50/files - new: https://git.openjdk.java.net/jdk16/pull/50/files/873c2506..7bd8bcb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=50&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=50&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/50/head:pull/50 PR: https://git.openjdk.java.net/jdk16/pull/50 From njian at openjdk.java.net Mon Jan 11 07:34:05 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Mon, 11 Jan 2021 07:34:05 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v2] In-Reply-To: <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com> References: <9XtCnqp4eKcBDXlXSm18R6tUIH9mCPZUZJE3Htio2Bs=.606bf77d-fec8-434a-b1e9-6cb5484605a1@github.com> <4wsrcJIZMSQcI-bEYswi7vI4MznlHMCuYkxCFjzY6S4=.ec088b95-496c-4ecc-98a7-e239c7247348@github.com> Message-ID: On Tue, 5 Jan 2021 10:40:11 GMT, Andrew Dinn wrote: >> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year to 2021. > > src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 252: > >> 250: pc, info, NULL, NULL, 0, 0); >> 251: va_end(detail_args); >> 252: } > > I'm not sure it is ok to revert this code. The fix this is part of (for JDK-8255711) was provided explicitly to re-organize the flow of control for handling of fatal errors. Reverting this code appears to undermine the goal of that issue. I would like to get Thomas Stuefe's (@tstuefe) opinion on whether it is appropriate to abort the JVM here vs returning false before accepting this specific change. Thank you Thomas. I have removed the change from my patch. Would you mind taking another look and approving this patch @adinn ? ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From bulasevich at openjdk.java.net Mon Jan 11 09:09:05 2021 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Mon, 11 Jan 2021 09:09:05 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: <3FqXOR8NSsGbCExqGxRWPfWOrlb0Rpl0bU3Ug__8I8g=.c74bae33-89af-47b5-b02d-6546a9f538a7@github.com> On Thu, 7 Jan 2021 23:06:19 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Fix another s390 compilation failure src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp line 376: > 374: // Note: In tiered we increment either counters in MethodCounters* or > 375: // in MDO depending if we're profiling or not. > 376: int increment = InvocationCounter::count_increment; The small code below seems not to be equivalent replacement for the above code. I would appreciate some explanation on why we change the things. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From bulasevich at openjdk.java.net Mon Jan 11 09:11:56 2021 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Mon, 11 Jan 2021 09:11:56 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Mon, 11 Jan 2021 02:54:02 GMT, Igor Veresov wrote: >> To clarify the possible configs. >> 1. There is only one policy now. Functions with both compilers or a single compiler. >> 2. The best way to control the operation mode is with the ```-XX:CompilationMode=``` flag. Possible values so far are: normal (aka default), high-only (c2 or graal only), quick-only(c1 only), high-only-quick-internal (a special mode for jar graal where only graal itself is compiled by c1, but the user code is compiled with graal). >> 3. There is a mode that emulates the behavior when the user specifies -TieredCompilation. That's basically the high-only mode. >> 4. There is also support for legacy policy flags such as CompileThreshold, which would properly setup the policy parameters to match the old behavior. > > Dave, I'm answering inline. > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >> >> On 8/01/2021 4:09 pm, Igor Veresov wrote: >> >> > On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote: >> > > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> > > > Fix s390 build >> > > >> > > >> > > Marking as reviewed, but only for the jvmti tests. I don't believe there are any other svc changes in this PR. >> > >> > >> > Please find the answers in-line. >> > > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ >> > > Hi Igor, >> > > On 8/01/2021 6:36 am, Igor Veresov wrote: >> > > > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> > > >> > > >> > > Can you clarify, for non-compiler folk, what all the alternative configs >> > > actually mean now. I'm a bit confused by this definition: >> > > define_pd_global(bool, TieredCompilation, >> > > COMPILER1_PRESENT(true) NOT_COMPILER1(false)); >> > >> > >> > That's in a c2_globals_*.hpp, which is only included if C2 is present. Given that, if C1 is present as well the flag is set to true. >> >> Sorry I overlooked the exact placement. >> >> > > as I expected tiered compilation to require COMPILER1 and COMPILER2. >> > >> > >> > Right. That's exactly what's happening. >> > > Also I see interpreter code that used to be guarded by TieredCompilation >> > > now being executed unconditionally, which seems to assume C1 or C2 must >> > > be present? >> > >> > >> > Counters and compilation policy callbacks are historically guarded by UseCompiler and UseLoopCounter flags, which are set to false if there are no compilers present. I haven't changed the semantics. >> >> That is not at all obvious. For example in >> templateInterpreterGenerator_aarch64.cpp this code used to guarded by >> TieredCompilation: >> >> 608: __ bind(no_mdo); >> // Increment counter in MethodCounters >> const Address invocation_counter(rscratch2, >> MethodCounters::invocation_counter_offset() + >> InvocationCounter::counter_offset()); >> __ get_method_counters(rmethod, rscratch2, done); >> const Address mask(rscratch2, >> in_bytes(MethodCounters::invoke_mask_offset())); >> __ increment_mask_and_jump(invocation_counter, increment, mask, >> rscratch1, r1, false, Assembler::EQ, overflow); >> __ bind(done); > > This code is in generate_counter_incr() each call to which is guarded by ```if (inc_counter)```, and ```inc_counter``` is defined as ``` bool inc_counter = UseCompiler || CountCompiledCalls || LogTouchedMethods;```. Again, I haven't changed that at all, that how it always worked. We may try to tidy this up but I feel like this change is big enough already. > >> >> but now it seems to be executed unconditionally with no reference to >> either flag you mentioned. >> >> > > Overall it is a big change to digest, but after skimming it looks like a >> > > few of the refactorings could have been applied in a layered fashion >> > > using multiple commits to make it easier to review. >> > >> > >> > Frankly, I don't know how to split it into smaller pieces. There are surprisingly lots of interdependencies. However, the best way to think about it is that there are three major parts: 1. CompilerConfig API that is an abstraction over compiler configuration (what's compiled in, what flags are present that restrict compiler usage, etc); 2. The legacy policy removal. 3. Emulation of the old JVM behavior. >> >> I was thinking the ifdef related changes as one commit; then the >> TieredCompilation removals; then the addition of CompilerConfig API ... >> >> These aren't separate changes just different commits within the PR so >> that it can be reviewed in stages. > > I could've done that, I guess, but I usually like to make my checkpoints compilable. Sorry. > >> >> Cheers, >> David >> ----- I see some regression on ARM32 with this change: http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From adinn at openjdk.java.net Mon Jan 11 09:35:01 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Mon, 11 Jan 2021 09:35:01 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v3] In-Reply-To: References: Message-ID: <2vNAJAihgpB4q_wqeuf2Dtjbu9X-NpqfXtNMibnOOUc=.f52ed07a-702f-4d8b-9200-46986181e6a1@github.com> On Mon, 11 Jan 2021 07:30:15 GMT, Ningsheng Jian wrote: >> After applying [1], some Vector API tests fail with SIGILL on SVE >> system. The SIGILL was triggered by verify_ptrue before c2 compiled >> function returns, which means that the preserved p7 register (as ptrue) >> has been clobbered before returning to c2 compiled code. (p7 is not >> preserved cross function calls, and system calls [2]). >> >> Currently we try to reinitialize ptrue at each entrypoint of returning >> from non-c2 compiled code, which indicating possible C or system calls. >> However, there's still one entrypoint missing, exception handling, as >> we may jump to c2 compiled code for exception handler. See >> OptoRuntime::generate_exception_blob(). >> >> Adding reinitialize_ptrue before jumping back to c2 compiled code in >> generate_exception_blob() could solve those Vector API test failures. >> Actually I had that in my initial test patch [3], I don't know why I >> missed that in final patch... I reran tests with the same approach of >> [3] and found that there's still something missing, the >> nmethod_entry_barrier() in c2 function prolog. The barrier may call to >> runtime code (see generate_method_entry_barrier()). To reduce the risk >> of missing such reinitialize_ptrue in newly added code in future, I >> think it would be better to do the reinitialize in >> pop_call_clobbered_registers(). >> >> P.S. the SIGILL message is also not clear, it should print detailed >> message as indicated by MacroAssembler::stop() call. This is caused by >> JDK-8255711 removing the message printing code. This will be fixed by JDK-8259539. >> >> Tested with tier1-3 on SVE hardware. Also verified with the same >> approach of patch [3] with jtreg tests hotspot_all_no_apps and >> jdk:tier1-3 passed without incorrect ptrue value assertion failure. >> >> [1] https://github.com/openjdk/jdk/pull/1621 >> [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst >> [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch > > Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: > > Revert signal handler changes, which will be fixed in JDK-8259539. This looks fine now. ------------- Marked as reviewed by adinn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/50 From shade at openjdk.java.net Mon Jan 11 09:46:07 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 09:46:07 GMT Subject: Integrated: 8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 13:54:25 GMT, Aleksey Shipilev wrote: > As noted in the bug report, there are places in `vmError.cpp`, where information on compressed classes is only printed if compressed oops are enabled. After JDK-8241825 both features should be independent. In addition to 2 reported places, we also need to print the setting in JVM modeline. > > Sample outputs: > > Command Line: Crash > ... > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.shade.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > ... > VM Mutex/Monitor currently owned by a thread: None > > Heap address: 0x0000000082000000, size: 30688 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 > > CDS archive(s) mapped at: [0x0000000800000000-0x0000000800c5c000-0x0000000800c5c000), size 12959744, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. > Compressed class space mapped at: 0x0000000801000000-0x0000000841000000, reserved size: 1073741824 > Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 > > GC Precious Log: > > Command Line: -XX:-UseCompressedOops Crash > ... > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.shade.jdk, mixed mode, sharing, tiered, compressed class ptrs, g1 gc, linux-amd64) > ... > VM Mutex/Monitor currently owned by a thread: None > > CDS archive(s) mapped at: [0x0000000800000000-0x0000000800c2f000-0x0000000800c2f000), size 12775424, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. > Compressed class space mapped at: 0x0000000801000000-0x0000000841000000, reserved size: 1073741824 > Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 > > GC Precious Log: > ... > > Command Line: -XX:-UseCompressedOops -XX:-UseCompressedClassPointers Crash > ... > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.shade.jdk, mixed mode, tiered, g1 gc, linux-amd64) > ... > VM Mutex/Monitor currently owned by a thread: None > > GC Precious Log: > ... This pull request has now been integrated. Changeset: a03e22bb Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/a03e22bb Stats: 19 lines in 1 file changed: 8 ins; 0 del; 11 mod 8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp Reviewed-by: rrich, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1974 From stuefe at openjdk.java.net Mon Jan 11 09:59:58 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 11 Jan 2021 09:59:58 GMT Subject: RFR: JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling In-Reply-To: References: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> Message-ID: <1DuT7x_rffnTozTmD9VzGowaXzasOWQNasDyQfoIjdU=.d14f7967-986a-4483-b0f2-9b355f811015@github.com> On Thu, 7 Jan 2021 22:42:02 GMT, David Holmes wrote: >> AIX 5.3 had buggy __thread support (see JDK-8176442). >> That's why we introduced a macro USE_LIBRARY_BASED_TLS_ONLY and set it only to 1 on AIX (different to the other platforms supported by the OpenJDK). >> However AIX 5.3 support was removed some time ago (currently we have a minimum requirement of AIX 7.X ) so the whole USE_LIBRARY_BASED_TLS_ONLY related coding could be removed. > > Hi Matthias, > We didn't introduce USE_LIBRARY_BASED_TLS_ONLY just for AIX, it was also added to aid the mobile project: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-November/020765.html > Before removing it we would need to have a broader discussion. > Thanks, > David Hi Matthias, Removal looks good. I have a small preference for leaving it in; but OTOS we never really test this coding since all main platforms use __thread. Maybe removal is good then. I'll defer to David for the final decision. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1976 From ngasson at openjdk.java.net Mon Jan 11 10:08:00 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 11 Jan 2021 10:08:00 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 07:30:15 GMT, Ningsheng Jian wrote: >> After applying [1], some Vector API tests fail with SIGILL on SVE >> system. The SIGILL was triggered by verify_ptrue before c2 compiled >> function returns, which means that the preserved p7 register (as ptrue) >> has been clobbered before returning to c2 compiled code. (p7 is not >> preserved cross function calls, and system calls [2]). >> >> Currently we try to reinitialize ptrue at each entrypoint of returning >> from non-c2 compiled code, which indicating possible C or system calls. >> However, there's still one entrypoint missing, exception handling, as >> we may jump to c2 compiled code for exception handler. See >> OptoRuntime::generate_exception_blob(). >> >> Adding reinitialize_ptrue before jumping back to c2 compiled code in >> generate_exception_blob() could solve those Vector API test failures. >> Actually I had that in my initial test patch [3], I don't know why I >> missed that in final patch... I reran tests with the same approach of >> [3] and found that there's still something missing, the >> nmethod_entry_barrier() in c2 function prolog. The barrier may call to >> runtime code (see generate_method_entry_barrier()). To reduce the risk >> of missing such reinitialize_ptrue in newly added code in future, I >> think it would be better to do the reinitialize in >> pop_call_clobbered_registers(). >> >> P.S. the SIGILL message is also not clear, it should print detailed >> message as indicated by MacroAssembler::stop() call. This is caused by >> JDK-8255711 removing the message printing code. This will be fixed by JDK-8259539. >> >> Tested with tier1-3 on SVE hardware. Also verified with the same >> approach of patch [3] with jtreg tests hotspot_all_no_apps and >> jdk:tier1-3 passed without incorrect ptrue value assertion failure. >> >> [1] https://github.com/openjdk/jdk/pull/1621 >> [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst >> [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch > > Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: > > Revert signal handler changes, which will be fixed in JDK-8259539. Marked as reviewed by ngasson (Committer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From aph at openjdk.java.net Mon Jan 11 10:41:58 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 11 Jan 2021 10:41:58 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 05:14:05 GMT, Dong Bo wrote: >> According to the results of `JMH perfasm`, `Math.max(max, Math.abs(floatsA[i] - floatsB[i]))` is vectorized when `COUNT=8` on a X86 platform. >> While on aarch64, `floatsB[i] = Math.abs(floatsA[i])` is not vectorized when `COUNT = 10` and we can not match `VAbs2F` neither. >> I am going to investigate the failed vectorization and see if we can have `Max2F` matched. Thanks. > > Hi, > > I made a mistake to say that the code is not vectorized with `COUNT < 12`, seems that the percentages of vectorized code is too small to be catched by `JMH perfasm`. > To observed if `Min/MaxReductionVNode` are created or not, I added a explicit print in `ReductionNode::make`, like: > --- a/src/hotspot/share/opto/vectornode.cpp > +++ b/src/hotspot/share/opto/vectornode.cpp > @@ -961,7 +961,9 @@ ReductionNode* ReductionNode::make(int opc, Node *ctrl, Node* n1, Node* n2, Basi > case Op_MinReductionV: return new MinReductionVNode(ctrl, n1, n2); > - case Op_MaxReductionV: return new MaxReductionVNode(ctrl, n1, n2); > + case Op_MaxReductionV: > + warning("in ReductionNode::make, making a MaxReductionVNode, length %d", n2->bottom_type()->is_vect()->length()); > + return new MaxReductionVNode(ctrl, n1, n2); > case Op_AndReductionV: return new AndReductionVNode(ctrl, n1, n2); > > In my observation, we have `Max4F` when `COUNT >= 4`, it is resonable to create `Max4F` other than `Max2F`. > The `Max2F` is created with `COUNT == 3` and `-XX:-SuperWordLoopUnrollAnalysis`. > But I did not find any noticeable improvements with such a small percentage. > > The JMH has been updated, the performance results are: > Benchmark (COUNT_DOUBLE) (COUNT_FLOAT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 677.778 ? 0.694 ns/op > VectorReductionFloatingMinMax.maxRedF 512 3 0 avgt 10 21.016 ? 0.097 ns/op > VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 677.633 ? 0.664 ns/op > VectorReductionFloatingMinMax.minRedF 512 3 0 avgt 10 21.001 ? 0.019 ns/op > # Kunpeng 916, fmaxp/fminp > VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 425.776 ? 0.785 ns/op > VectorReductionFloatingMinMax.maxRedF 512 3 0 avgt 10 20.883 ? 0.033 ns/op > VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 426.177 ? 3.258 ns/op > VectorReductionFloatingMinMax.minRedF 512 3 0 avgt 10 20.871 ? 0.044 ns/op Did you try math.abs() for doubles? ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From dongbo at openjdk.java.net Mon Jan 11 11:41:13 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 11 Jan 2021 11:41:13 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v6] In-Reply-To: References: Message-ID: <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com> > This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. > > Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. > Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. > > Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. > Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op > VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op > VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op > VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op > > # Kunpeng 916, with fmaxp/fminp > VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% > VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op > VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% > VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: test improvements for doubles with Math.abs() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1925/files - new: https://git.openjdk.java.net/jdk/pull/1925/files/f244ed01..4d6d32e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1925&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1925/head:pull/1925 PR: https://git.openjdk.java.net/jdk/pull/1925 From dongbo at openjdk.java.net Mon Jan 11 11:41:14 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 11 Jan 2021 11:41:14 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 10:38:41 GMT, Andrew Haley wrote: >> Hi, >> >> I made a mistake to say that the code is not vectorized with `COUNT < 12`, seems that the percentages of vectorized code is too small to be catched by `JMH perfasm`. >> To observed if `Min/MaxReductionVNode` are created or not, I added a explicit print in `ReductionNode::make`, like: >> --- a/src/hotspot/share/opto/vectornode.cpp >> +++ b/src/hotspot/share/opto/vectornode.cpp >> @@ -961,7 +961,9 @@ ReductionNode* ReductionNode::make(int opc, Node *ctrl, Node* n1, Node* n2, Basi >> case Op_MinReductionV: return new MinReductionVNode(ctrl, n1, n2); >> - case Op_MaxReductionV: return new MaxReductionVNode(ctrl, n1, n2); >> + case Op_MaxReductionV: >> + warning("in ReductionNode::make, making a MaxReductionVNode, length %d", n2->bottom_type()->is_vect()->length()); >> + return new MaxReductionVNode(ctrl, n1, n2); >> case Op_AndReductionV: return new AndReductionVNode(ctrl, n1, n2); >> >> In my observation, we have `Max4F` when `COUNT >= 4`, it is resonable to create `Max4F` other than `Max2F`. >> The `Max2F` is created with `COUNT == 3` and `-XX:-SuperWordLoopUnrollAnalysis`. >> But I did not find any noticeable improvements with such a small percentage. >> >> The JMH has been updated, the performance results are: >> Benchmark (COUNT_DOUBLE) (COUNT_FLOAT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 677.778 ? 0.694 ns/op >> VectorReductionFloatingMinMax.maxRedF 512 3 0 avgt 10 21.016 ? 0.097 ns/op >> VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 677.633 ? 0.664 ns/op >> VectorReductionFloatingMinMax.minRedF 512 3 0 avgt 10 21.001 ? 0.019 ns/op >> # Kunpeng 916, fmaxp/fminp >> VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 425.776 ? 0.785 ns/op >> VectorReductionFloatingMinMax.maxRedF 512 3 0 avgt 10 20.883 ? 0.033 ns/op >> VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 426.177 ? 3.258 ns/op >> VectorReductionFloatingMinMax.minRedF 512 3 0 avgt 10 20.871 ? 0.044 ns/op > > Did you try math.abs() for doubles? The `Math.abs(doublesA[i] - doublesB[i])` has `~36%` improvements. I updated the tests for doubles with `Math.abs()`, it looks more consistent. Thanks. The JMH results of doubles with `Math.abs()`: Benchmark (COUNT_DOUBLE) (COUNT_FLOAT) (seed) Mode Cnt Score Error Units # Kunpeng 916, default VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 681.319 ? 0.658 ns/op VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 682.596 ? 4.322 ns/op # Kunpeng 916, fmaxp/fminp VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 439.130 ? 0.450 ns/op => 35.54% VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 439.105 ? 0.435 ns/op => 35.67% ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From aph at redhat.com Mon Jan 11 11:51:57 2021 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 Jan 2021 11:51:57 +0000 Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On 1/11/21 11:41 AM, Dong Bo wrote: > On Mon, 11 Jan 2021 10:38:41 GMT, Andrew Haley wrote: >> Did you try math.abs() for doubles? > > The `Math.abs(doublesA[i] - doublesB[i])` has `~36%` improvements. OK, so we are seeing some improvement in the performance of plausible Java benchmarks, if not real programs. Is it correct that there have been no improvements to anything you have tried using single-precision floating-point operands? If not, is there any possibility that this optimization might do anything useful with single-precision floats? -- 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 dongbo at openjdk.java.net Mon Jan 11 12:31:56 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 11 Jan 2021 12:31:56 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 11:38:01 GMT, Dong Bo wrote: >> Did you try math.abs() for doubles? > > The `Math.abs(doublesA[i] - doublesB[i])` has `~36%` improvements. > I updated the tests for doubles with `Math.abs()`, it looks more consistent. Thanks. > The JMH results of doubles with `Math.abs()`: > Benchmark (COUNT_DOUBLE) (COUNT_FLOAT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 681.319 ? 0.658 ns/op > VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 682.596 ? 4.322 ns/op > # Kunpeng 916, fmaxp/fminp > VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 439.130 ? 0.450 ns/op => 35.54% > VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 439.105 ? 0.435 ns/op => 35.67% For single-precision floating-point operands, as the experiments showed, we can have `Max2F` match only with `COUNT == 3`. With such a small loop under superword framework, it is diffcult to tell how much improvements of `fmaxp/fminp` over `fmaxv+ins`. Although it sounds unreasonable for an application to use `Float64Vector` rather than `Float128Vecotor`, the optimization does being useful for VectorAPI `Float64Vector.reduceLanes(VectorOperators.MAX)` as mentioned previously. Do you think we should remove single-precision floating-point parts in this patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From coleenp at openjdk.java.net Mon Jan 11 12:31:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Jan 2021 12:31:56 GMT Subject: RFR: 8259482: jni_Set/GetField_probe are the same as their _nh versions In-Reply-To: References: <-KyDin9aId3_tTdCVPJdIddjJR6AjQReRFJdvOIpYvg=.057bc24e-fee7-4284-a2b5-6e02fa8ecf0f@github.com> Message-ID: On Mon, 11 Jan 2021 00:45:25 GMT, David Holmes wrote: >> Remove the _nh versions. Tested with tier1 and vmTestbase/nsk/jdi,jvmti tests. > > Cleanup looks good. > > Thanks, > David Thanks Harold, Serguei and David. ------------- PR: https://git.openjdk.java.net/jdk/pull/2008 From coleenp at openjdk.java.net Mon Jan 11 12:31:58 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Jan 2021 12:31:58 GMT Subject: Integrated: 8259482: jni_Set/GetField_probe are the same as their _nh versions In-Reply-To: <-KyDin9aId3_tTdCVPJdIddjJR6AjQReRFJdvOIpYvg=.057bc24e-fee7-4284-a2b5-6e02fa8ecf0f@github.com> References: <-KyDin9aId3_tTdCVPJdIddjJR6AjQReRFJdvOIpYvg=.057bc24e-fee7-4284-a2b5-6e02fa8ecf0f@github.com> Message-ID: On Fri, 8 Jan 2021 19:32:36 GMT, Coleen Phillimore wrote: > Remove the _nh versions. Tested with tier1 and vmTestbase/nsk/jdi,jvmti tests. This pull request has now been integrated. Changeset: 23801da9 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/23801da9 Stats: 37 lines in 3 files changed: 0 ins; 33 del; 4 mod 8259482: jni_Set/GetField_probe are the same as their _nh versions Reviewed-by: hseigel, sspitsyn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/2008 From coleenp at openjdk.java.net Mon Jan 11 12:49:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Jan 2021 12:49:56 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 22:29:10 GMT, Coleen Phillimore wrote: >> Looks good to me! > > Thanks Dan and Patricio! > What JNI_LEAF function does as you describe? 1. JNI_LEAF(void, JVM_RegisterNativeEntryPointMethods(JNIEnv *env, jclass NEP_class)) int status = env->RegisterNatives(NEP_class, NEP_methods, sizeof(NEP_methods)/sizeof(JNINativeMethod)); guarantee(status == JNI_OK && !env->ExceptionOccurred(), "register jdk.internal.invoke.NativeEntryPoint natives"); JNI_END Also: JVM_RegisterProgrammableInvokerMethods, JVM_RegisterProgrammableUpcallHandlerMethods 2. The real reason that I wrote this is patch is so that each of these ThreadInVMfromNative calls (from the compiler and JFR) don't need to also have ResetNoHandleMark. The intention is to hide this detail so one doesn't need to try to figure out what this is when reading through the code. It is debug code, so after the transition, there is no need to have a NoHandleMark. My original intention is to hide this as much as possible since it's a weird artifact of our implementation of Handles. It's noise, that I've always ignored until now. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1983 From coleenp at openjdk.java.net Mon Jan 11 12:58:02 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Jan 2021 12:58:02 GMT Subject: RFR: 8259486: Remove CautiouslyPreserveExceptionMark In-Reply-To: References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: On Mon, 11 Jan 2021 01:13:25 GMT, David Holmes wrote: >> See CR for details. This is a hopefully simple cleanup. I didn't try to reason about removing any of these except an obvious call (if you look above the patch in thread.cpp). >> Tested with tier1-3. > > src/hotspot/share/runtime/thread.cpp line 1867: > >> 1865: // Call method Thread.dispatchUncaughtException(). >> 1866: Klass* thread_klass = SystemDictionary::Thread_klass(); >> 1867: JavaValue result(T_VOID); > > I think I agree that this is redundant. Seems to be a leftover from something else. Yes. Look above it. It clears the exception mark so there's never an exception pending. strange we didn't clean this out sometime between 1.2 and now. > src/hotspot/share/classfile/javaClasses.cpp line 2528: > >> 2526: if (total_count == 0) { >> 2527: // The top frame will be hidden from the stack trace. >> 2528: bt.set_has_hidden_top_frame(); > > To be clear: no exception can become pending due to this call, so no need for CHECK. Correct. I think it used to allocate an object so could throw OOM but that was changed. > src/hotspot/share/classfile/javaClasses.cpp line 2556: > >> 2554: >> 2555: JavaThread* thread = JavaThread::active(); >> 2556: PreserveExceptionMark pm(thread); > > The result of JavaThread::active() is not necessarily the current thread. So either the new code is wrong or else we should just be using JavaThread::current() My first iteration of this change knew there was a difference then I cleaned it up. I'll restore the Thread::current() in the PEM constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/2007 From coleenp at openjdk.java.net Mon Jan 11 13:06:02 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Jan 2021 13:06:02 GMT Subject: RFR: 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark In-Reply-To: References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: <-2Eb7bpIOOv6xrWn944x5rGjRlfDDnQUj1Rnc2o2AX8=.e31fcf85-d76a-4534-81b5-ea32df5acccd@github.com> On Mon, 11 Jan 2021 12:55:22 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 2556: >> >>> 2554: >>> 2555: JavaThread* thread = JavaThread::active(); >>> 2556: PreserveExceptionMark pm(thread); >> >> The result of JavaThread::active() is not necessarily the current thread. So either the new code is wrong or else we should just be using JavaThread::current() > > My first iteration of this change knew there was a difference then I cleaned it up. I'll restore the Thread::current() in the PEM constructor. annoyingly every caller of fill_in_stack_trace has the current thread. ------------- PR: https://git.openjdk.java.net/jdk/pull/2007 From coleenp at openjdk.java.net Mon Jan 11 13:10:16 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Jan 2021 13:10:16 GMT Subject: RFR: 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark [v2] In-Reply-To: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: > See CR for details. This is a hopefully simple cleanup. I didn't try to reason about removing any of these except an obvious call (if you look above the patch in thread.cpp). > Tested with tier1-3. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix clear_pending_exception in fill_in_stack_trace. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2007/files - new: https://git.openjdk.java.net/jdk/pull/2007/files/fa1511d5..3deb86b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2007&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2007&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2007.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2007/head:pull/2007 PR: https://git.openjdk.java.net/jdk/pull/2007 From shade at openjdk.java.net Mon Jan 11 13:13:08 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 13:13:08 GMT Subject: [jdk16] RFR: 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049 Message-ID: Debian folks report that Zero m68k (and seems only that arch) fails the static assert added by JDK-8252049. It affects at least JDK 16, but would affect more releases once JDK-8252049 is backported. /<>/src/hotspot/share/oops/methodData.hpp: In constructor 'MethodData::CompilerCounters::CompilerCounters()': /<>/src/hotspot/share/oops/methodData.hpp:1987:55: error: static assertion failed: align 1987 | static_assert(sizeof(_trap_hist) % HeapWordSize == 0, "align"); | I tried to massage the code so that `oops/methodData.hpp` is not touched when Zero is built (since Zero does not use compilers and related infra), but there are enough transitive dependencies to `oops/methodData.hpp` to make it quite messy. So instead I would just special-case it in place. ------------- Commit messages: - 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049 Changes: https://git.openjdk.java.net/jdk16/pull/102/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=102&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259560 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/102/head:pull/102 PR: https://git.openjdk.java.net/jdk16/pull/102 From coleenp at openjdk.java.net Mon Jan 11 13:28:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Jan 2021 13:28:05 GMT Subject: RFR: 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark [v2] In-Reply-To: References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: On Mon, 11 Jan 2021 13:10:16 GMT, Coleen Phillimore wrote: >> See CR for details. This is a hopefully simple cleanup. I didn't try to reason about removing any of these except an obvious call (if you look above the patch in thread.cpp). >> Tested with tier1-3. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix clear_pending_exception in fill_in_stack_trace. src/hotspot/share/classfile/javaClasses.cpp line 2557: > 2555: PreserveExceptionMark pm(Thread::current()); // not necessarily JavaThread::active(). > 2556: > 2557: JavaThread* thread = JavaThread::active(); This should NOT be JavaThread::active() since it's passed and used as TRAPS, ie, as the current thread for creating ResourceMark and throwing exceptions. This is wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/2007 From hseigel at openjdk.java.net Mon Jan 11 13:49:19 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 11 Jan 2021 13:49:19 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v4] In-Reply-To: References: Message-ID: > Please review this change to remove the JVM develop flag UseStackBanging and always use stack banging. > > The change was tested with tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and cross-builds on PPC64, Linux32, and S390x. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8258838: fix Graal changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1988/files - new: https://git.openjdk.java.net/jdk/pull/1988/files/7aabbf2c..8333d705 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1988&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1988&range=02-03 Stats: 35 lines in 2 files changed: 3 ins; 0 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/1988.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1988/head:pull/1988 PR: https://git.openjdk.java.net/jdk/pull/1988 From hseigel at openjdk.java.net Mon Jan 11 13:53:58 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 11 Jan 2021 13:53:58 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v3] In-Reply-To: References: <6rQJahQ2wG0MPbf6BQ39B1qhHZc73MLyOK1n0ufY2RE=.b727c7ba-4cc7-411e-91b3-c14e8fa41eed@github.com> Message-ID: On Fri, 8 Jan 2021 21:46:37 GMT, Doug Simon wrote: >> Changes requested by kvn (Reviewer). > > If you follow @vnkozlov 's feedback, the Graal/JVMCI aspects of this change look fine to me. Thanks Vladimir and Doug for looking at this change! Please review this latest version that contains the changes requested by Vladimir. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From dnsimon at openjdk.java.net Mon Jan 11 14:07:05 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 11 Jan 2021 14:07:05 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v3] In-Reply-To: References: <6rQJahQ2wG0MPbf6BQ39B1qhHZc73MLyOK1n0ufY2RE=.b727c7ba-4cc7-411e-91b3-c14e8fa41eed@github.com> Message-ID: On Mon, 11 Jan 2021 13:51:00 GMT, Harold Seigel wrote: > Thanks Vladimir and Doug for looking at this change! Please review this latest version that contains the changes requested by Vladimir. > Thanks, Harold Changes look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From shade at openjdk.java.net Mon Jan 11 14:17:11 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 14:17:11 GMT Subject: RFR: 8259565: Zero: runtime/criticalnatives fails because CriticalJNINatives is not supported Message-ID: Zero does not support CriticalJNINatives (and that flag is going away soon), and so the tests are failing with: $ CONF=linux-x86_64-zero-fastdebug make exploded-run-test TEST=compiler/runtime/criticalnatives/ java.lang.Exception: critical native lookup failed at compiler.runtime.criticalnatives.argumentcorruption.CheckLongArgs.check(CheckLongArgs.java:58) at compiler.runtime.criticalnatives.argumentcorruption.CheckLongArgs.test(CheckLongArgs.java:48) at compiler.runtime.criticalnatives.argumentcorruption.CheckLongArgs.main(CheckLongArgs.java:38) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) There are similar issues for AArch64 (JDK-8191129) and ARM32 (JDK-8213794). Zero needs the same. Additional testing: - [x] Linux x86_64 Zero `compiler/runtime/criticalnatives` (now skipped) - [x] Linux x86_64 Server `compiler/runtime/criticalnatives` (still run and pass) ------------- Commit messages: - 8259565: Zero: runtime/criticalnatives fails because CriticalJNINatives is not supported Changes: https://git.openjdk.java.net/jdk/pull/2027/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2027&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259565 Stats: 6 lines in 3 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2027/head:pull/2027 PR: https://git.openjdk.java.net/jdk/pull/2027 From hseigel at openjdk.java.net Mon Jan 11 14:35:01 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 11 Jan 2021 14:35:01 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v2] In-Reply-To: <_uwGpfXfxNS3LRSrqFgBRv0Y6YvzvVXIKlelCMSQYFU=.d5c20e4f-da73-4f97-bb16-b419be12d983@github.com> References: <_uwGpfXfxNS3LRSrqFgBRv0Y6YvzvVXIKlelCMSQYFU=.d5c20e4f-da73-4f97-bb16-b419be12d983@github.com> Message-ID: On Fri, 8 Jan 2021 21:44:51 GMT, Doug Simon wrote: >> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java line 256: >> >>> 254: public final int stackShadowPages = getFlag("StackShadowPages", Integer.class); >>> 255: public final int stackReservedPages = getFlag("StackReservedPages", Integer.class, 0, JDK >= 9); >>> 256: public final int stackBias = getConstant("STACK_BIAS", Integer.class, 0, JDK < 15); >> >> The line should be modified instead of removal: >> public final boolean useStackBanging = getFlag("UseStackBanging", Boolean.class, true, JDK < 17); >> @dougxc please note that it should be upstreamed when GraalVM adopt JDK 17. > > The good thing is that the VM will fail fail when initializing Graal if the update is not done so there's no way we can overlook it. fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From hseigel at openjdk.java.net Mon Jan 11 14:35:03 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 11 Jan 2021 14:35:03 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v2] In-Reply-To: References: Message-ID: <9r6mb04wp0uOOssAxMUaHbQAEFMOrHkNoarDRsxU-lw=.7a9f0a7f-115d-402c-b606-ecb72ed0e282@github.com> On Fri, 8 Jan 2021 20:32:20 GMT, Vladimir Kozlov wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> fix copyrights, other minot changes > > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java line 133: > >> 131: >> 132: public void emitStackOverflowCheck(CompilationResultBuilder crb) { >> 133: // Each code entry causes one stack bang n pages down the stack where n > > I think you can leave this file unchanged with my suggested modification in GraalHotSpotVMConfig.java. done ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From hseigel at openjdk.java.net Mon Jan 11 14:35:05 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 11 Jan 2021 14:35:05 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v4] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 06:09:28 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258838: fix Graal changes > > src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 252: > >> 250: X86_ONLY(do_intx_flag(UseSSE)) \ >> 251: COMPILER2_PRESENT(do_bool_flag(UseSquareToLenIntrinsic)) \ >> 252: do_bool_flag(UseStackBanging) \ > > Compiler folk will need to verify if this change is okay wrt. upstream Graal code. done ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From coleenp at openjdk.java.net Mon Jan 11 14:42:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Jan 2021 14:42:55 GMT Subject: RFR: 8259565: Zero: compiler/runtime/criticalnatives fails because CriticalJNINatives is not supported In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 14:12:33 GMT, Aleksey Shipilev wrote: > Zero does not support CriticalJNINatives (and that flag is going away soon), and so the tests are failing with: > > $ CONF=linux-x86_64-zero-fastdebug make exploded-run-test TEST=compiler/runtime/criticalnatives/ > java.lang.Exception: critical native lookup failed > at compiler.runtime.criticalnatives.argumentcorruption.CheckLongArgs.check(CheckLongArgs.java:58) > at compiler.runtime.criticalnatives.argumentcorruption.CheckLongArgs.test(CheckLongArgs.java:48) > at compiler.runtime.criticalnatives.argumentcorruption.CheckLongArgs.main(CheckLongArgs.java:38) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > > There are similar issues for AArch64 (JDK-8191129) and ARM32 (JDK-8213794). Zero needs the same. > > Additional testing: > - [x] Linux x86_64 Zero `compiler/runtime/criticalnatives` (now skipped) > - [x] Linux x86_64 Server `compiler/runtime/criticalnatives` (still run and pass) Looks good and can be pushed under the trivial rules. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2027 From coleenp at openjdk.java.net Mon Jan 11 14:51:01 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Jan 2021 14:51:01 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v3] In-Reply-To: References: <6rQJahQ2wG0MPbf6BQ39B1qhHZc73MLyOK1n0ufY2RE=.b727c7ba-4cc7-411e-91b3-c14e8fa41eed@github.com> Message-ID: On Mon, 11 Jan 2021 14:04:45 GMT, Doug Simon wrote: >> Thanks Vladimir and Doug for looking at this change! Please review this latest version that contains the changes requested by Vladimir. >> Thanks, Harold > >> Thanks Vladimir and Doug for looking at this change! Please review this latest version that contains the changes requested by Vladimir. >> Thanks, Harold > > Changes look good. The stack banging code still seems like the most efficient way to test for stack overflow in compiled code, but it may be that a pointer comparison in the interpreter entries (that are very inconsistent right now) would be better for them. There are some cleanup RFEs. eg. https://bugs.openjdk.java.net/browse/JDK-8069196 or even https://bugs.openjdk.java.net/browse/JDK-8072070 if you want them @TheRealMDoerr they're all yours. ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From shade at openjdk.java.net Mon Jan 11 15:13:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 15:13:58 GMT Subject: Withdrawn: 8255523: Clean up temporary shared_locs initializations In-Reply-To: <5OHoOpEGZ0j62A09r5hqDzxIu39qDSrxrC-b2tWOAzg=.4555cf67-82ee-4827-9154-1322b3f4fcf8@github.com> References: <5OHoOpEGZ0j62A09r5hqDzxIu39qDSrxrC-b2tWOAzg=.4555cf67-82ee-4827-9154-1322b3f4fcf8@github.com> Message-ID: On Wed, 28 Oct 2020 09:36:55 GMT, Aleksey Shipilev wrote: > See #648. Apparently, LLVM 11 complains that we are computing the number of elements over the array of a different type. Instead of ignoring the warning, it seems better to just clean up that code. We can allocate the whole thing as resource array of the same size. `sizeOf(relocInfo) = 2`, since it carries `unsigned short`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/897 From shade at openjdk.java.net Mon Jan 11 16:00:18 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Jan 2021 16:00:18 GMT Subject: [jdk16] RFR: 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049 [v2] In-Reply-To: References: Message-ID: > Debian folks report that Zero m68k (and seems only that arch) fails the static assert added by JDK-8252049. It affects at least JDK 16, but would affect more releases once JDK-8252049 is backported. > > /<>/src/hotspot/share/oops/methodData.hpp: In constructor 'MethodData::CompilerCounters::CompilerCounters()': > /<>/src/hotspot/share/oops/methodData.hpp:1987:55: error: static assertion failed: align > 1987 | static_assert(sizeof(_trap_hist) % HeapWordSize == 0, "align"); > | > > I tried to massage the code so that `oops/methodData.hpp` is not touched when Zero is built (since Zero does not use compilers and related infra), but there are enough transitive dependencies to `oops/methodData.hpp` to make it quite messy. So instead I would just special-case it in place. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Added another place where the build fails ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/102/files - new: https://git.openjdk.java.net/jdk16/pull/102/files/5df0f200..6690bcb0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=102&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=102&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/102/head:pull/102 PR: https://git.openjdk.java.net/jdk16/pull/102 From coleenp at openjdk.java.net Mon Jan 11 16:33:12 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Jan 2021 16:33:12 GMT Subject: RFR: 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark [v3] In-Reply-To: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: > See CR for details. This is a hopefully simple cleanup. I didn't try to reason about removing any of these except an obvious call (if you look above the patch in thread.cpp). > Tested with tier1-3. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix wrong JavaThread::active in fill_in_stack_trace. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2007/files - new: https://git.openjdk.java.net/jdk/pull/2007/files/3deb86b9..7f4427c4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2007&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2007&range=01-02 Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2007.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2007/head:pull/2007 PR: https://git.openjdk.java.net/jdk/pull/2007 From coleenp at openjdk.java.net Mon Jan 11 16:37:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Jan 2021 16:37:55 GMT Subject: RFR: 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark [v3] In-Reply-To: References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: On Mon, 11 Jan 2021 01:26:00 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix wrong JavaThread::active in fill_in_stack_trace. > > Hi Coleen, > > AFAICS you are not simply removing CautiouslyPreserveExceptionMark but you are changing PreserveExceptionMark to now act as CautiouslyPreserveExceptionMark did. If the PEM now encounters an unexpected exception it is no longer fatal. This relaxation is not unreasonable but I think the bug synopsis and description need to be updated to reflect what you are actually doing. > > I agree "Cautiously" was not a good word for distinguishing the two responses here. I also think WeakPEM is not great either. :( > > A couple of minor comments elsewhere. > > Thanks, > David Reran tier1-3 and jvmti tests separately (thought the JavaThread::active() was added for them but it couldn't have been because it was added in 1998). ------------- PR: https://git.openjdk.java.net/jdk/pull/2007 From zgu at openjdk.java.net Mon Jan 11 17:44:02 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Jan 2021 17:44:02 GMT Subject: RFR: 8259565: Zero: compiler/runtime/criticalnatives fails because CriticalJNINatives is not supported In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 14:12:33 GMT, Aleksey Shipilev wrote: > Zero does not support CriticalJNINatives (and that flag is going away soon), and so the tests are failing with: > > $ CONF=linux-x86_64-zero-fastdebug make exploded-run-test TEST=compiler/runtime/criticalnatives/ > java.lang.Exception: critical native lookup failed > at compiler.runtime.criticalnatives.argumentcorruption.CheckLongArgs.check(CheckLongArgs.java:58) > at compiler.runtime.criticalnatives.argumentcorruption.CheckLongArgs.test(CheckLongArgs.java:48) > at compiler.runtime.criticalnatives.argumentcorruption.CheckLongArgs.main(CheckLongArgs.java:38) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > > There are similar issues for AArch64 (JDK-8191129) and ARM32 (JDK-8213794). Zero needs the same. > > Additional testing: > - [x] Linux x86_64 Zero `compiler/runtime/criticalnatives` (now skipped) > - [x] Linux x86_64 Server `compiler/runtime/criticalnatives` (still run and pass) Looks good. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2027 From iveresov at openjdk.java.net Mon Jan 11 17:52:02 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Mon, 11 Jan 2021 17:52:02 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: <3FqXOR8NSsGbCExqGxRWPfWOrlb0Rpl0bU3Ug__8I8g=.c74bae33-89af-47b5-b02d-6546a9f538a7@github.com> References: <3FqXOR8NSsGbCExqGxRWPfWOrlb0Rpl0bU3Ug__8I8g=.c74bae33-89af-47b5-b02d-6546a9f538a7@github.com> Message-ID: On Mon, 11 Jan 2021 09:06:36 GMT, Boris Ulasevich wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp line 376: > >> 374: // Note: In tiered we increment either counters in MethodCounters* or >> 375: // in MDO depending if we're profiling or not. >> 376: int increment = InvocationCounter::count_increment; > > The small code below seems not to be equivalent replacement for the above code. I would appreciate some explanation on why we change the things. Thanks. It's a just the code that was guarded before by ```if (TieredCompilation)```. It was just the else part that's gotten removed. Since the new policy is base off of tiered we don't need the old style of callbacks. Is there something else that you've noticed? ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Mon Jan 11 17:56:54 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Mon, 11 Jan 2021 17:56:54 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: On Mon, 11 Jan 2021 09:09:12 GMT, Boris Ulasevich wrote: > I see some regression on ARM32 with this change: > http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ I don't think those are related to the changes. Those are probably some preexisting c1 and c2 problems respectively that for some reason weren't triggered before. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Mon Jan 11 18:21:01 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 11 Jan 2021 18:21:01 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v4] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 13:49:19 GMT, Harold Seigel wrote: >> Please review this change to remove the JVM develop flag UseStackBanging and always use stack banging. >> >> The change was tested with tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and cross-builds on PPC64, Linux32, and S390x. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8258838: fix Graal changes Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1988 From hseigel at openjdk.java.net Mon Jan 11 18:21:01 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 11 Jan 2021 18:21:01 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v4] In-Reply-To: References: Message-ID: <8dswWyP69MH374UoFPyHj4iwH7dp5q7YJiGjlQbrWkc=.1db12fcd-c3ff-41b9-8b42-a798a3efbb9e@github.com> On Mon, 11 Jan 2021 18:16:23 GMT, Vladimir Kozlov wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258838: fix Graal changes > > Good. Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From hseigel at openjdk.java.net Mon Jan 11 18:21:02 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 11 Jan 2021 18:21:02 GMT Subject: Integrated: 8258838: Remove JVM option UseStackBanging In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 20:03:19 GMT, Harold Seigel wrote: > Please review this change to remove the JVM develop flag UseStackBanging and always use stack banging. > > The change was tested with tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and cross-builds on PPC64, Linux32, and S390x. > > Thanks, Harold This pull request has now been integrated. Changeset: cf3e4bfd Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/cf3e4bfd Stats: 174 lines in 18 files changed: 0 ins; 50 del; 124 mod 8258838: Remove JVM option UseStackBanging Reviewed-by: dholmes, coleenp, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1988 From lucy at openjdk.java.net Mon Jan 11 18:45:05 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 11 Jan 2021 18:45:05 GMT Subject: RFR: 8259383: AsyncGetCallTrace() crashes sporadically Message-ID: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com> Hi, may I please ask the community to review this small fix? It closes another hole in AsyncGetCallTrace(). Thanks a lot! Lutz ------------- Commit messages: - 8259383: AsyncGetCallTrace() crashes sporadically Changes: https://git.openjdk.java.net/jdk/pull/2032/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2032&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259383 Stats: 27 lines in 1 file changed: 22 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2032.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2032/head:pull/2032 PR: https://git.openjdk.java.net/jdk/pull/2032 From mdoerr at openjdk.java.net Mon Jan 11 19:00:59 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 11 Jan 2021 19:00:59 GMT Subject: RFR: 8258838: Remove JVM option UseStackBanging [v4] In-Reply-To: <8dswWyP69MH374UoFPyHj4iwH7dp5q7YJiGjlQbrWkc=.1db12fcd-c3ff-41b9-8b42-a798a3efbb9e@github.com> References: <8dswWyP69MH374UoFPyHj4iwH7dp5q7YJiGjlQbrWkc=.1db12fcd-c3ff-41b9-8b42-a798a3efbb9e@github.com> Message-ID: On Mon, 11 Jan 2021 18:17:34 GMT, Harold Seigel wrote: >> Good. > > Thanks for the reviews! Hi Coleen, thanks for the pointers. I?d like to investigate, but I don?t have enough time for it at the moment. > The stack banging code still seems like the most efficient way to test for stack overflow in compiled code I think it would be interesting to re-evaluate this with recent hotspot on modern CPUs with out-of-order execution. I?d try something like the following x86_64 code: cmpq(rsp, Address(r15_thread, JavaThread::stack_overflow_limit_offset())); jump_cc(Assembler::belowEqual, ExternalAddress(StubRoutines::throw_StackOverflowError_entry())); The branch can be perfectly predicted (usually never taken) and the CPU can execute the succeeding code speculatively before the checking is completed. In addition, I guess we do more inlining than at the time when stack banging was introduced. More inlining leads to fewer nmethod prologues executed and hence fewer stack overflow checking overhead. I guess the overhead will be below noise. Advantage would be no cache pollution by stack banging. And it?d be great to have no need for protected stack pages anymore! Best regards, Martin From: Coleen Phillimore Sent: Montag, 11. Januar 2021 15:49 To: openjdk/jdk Cc: Doerr, Martin ; Mention Subject: Re: [openjdk/jdk] 8258838: Remove JVM option UseStackBanging (#1988) The stack banging code still seems like the most efficient way to test for stack overflow in compiled code, but it may be that a pointer comparison in the interpreter entries (that are very inconsistent right now) would be better for them. There are some cleanup RFEs. eg. https://bugs.openjdk.java.net/browse/JDK-8069196 or even https://bugs.openjdk.java.net/browse/JDK-8072070 if you want them @TheRealMDoerr they're all yours. ? 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/1988 From lfoltan at openjdk.java.net Mon Jan 11 20:37:56 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Mon, 11 Jan 2021 20:37:56 GMT Subject: RFR: 8258810: Improve enum traits [v2] In-Reply-To: References: Message-ID: On Fri, 1 Jan 2021 09:44:18 GMT, Kim Barrett wrote: >> Please review these miscellaneous improvements to the enum iteration facility. >> Thanks to @albertnetymk for discussions. >> >> (1) Removed some unneeded stuff from EnumIterationTraits. >> >> (2) Various similar bits of error checking code are unified and shared via >> EnumIterationTraits. >> >> (3) Casts between the enum type and the underlying type are now done using >> helper functions in EnumIterationTraits. >> >> (4) JDK-8257466 added accessors for the EnumRange bounds and the index for >> an enumerator, but didn't account for the possibility of an empty subrange. >> Add assertions for that case. >> >> (5) Added some death tests to verify some of the error checking. >> >> Testing: >> mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > ayang review LGTM. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1868 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 njian at openjdk.java.net Tue Jan 12 01:35:06 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 12 Jan 2021 01:35:06 GMT Subject: [jdk16] Integrated: 8258384: AArch64: SVE verify_ptrue fails on some tests In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 07:11:11 GMT, Ningsheng Jian wrote: > After applying [1], some Vector API tests fail with SIGILL on SVE > system. The SIGILL was triggered by verify_ptrue before c2 compiled > function returns, which means that the preserved p7 register (as ptrue) > has been clobbered before returning to c2 compiled code. (p7 is not > preserved cross function calls, and system calls [2]). > > Currently we try to reinitialize ptrue at each entrypoint of returning > from non-c2 compiled code, which indicating possible C or system calls. > However, there's still one entrypoint missing, exception handling, as > we may jump to c2 compiled code for exception handler. See > OptoRuntime::generate_exception_blob(). > > Adding reinitialize_ptrue before jumping back to c2 compiled code in > generate_exception_blob() could solve those Vector API test failures. > Actually I had that in my initial test patch [3], I don't know why I > missed that in final patch... I reran tests with the same approach of > [3] and found that there's still something missing, the > nmethod_entry_barrier() in c2 function prolog. The barrier may call to > runtime code (see generate_method_entry_barrier()). To reduce the risk > of missing such reinitialize_ptrue in newly added code in future, I > think it would be better to do the reinitialize in > pop_call_clobbered_registers(). > > P.S. the SIGILL message is also not clear, it should print detailed > message as indicated by MacroAssembler::stop() call. This is caused by > JDK-8255711 removing the message printing code. This will be fixed by JDK-8259539. > > Tested with tier1-3 on SVE hardware. Also verified with the same > approach of patch [3] with jtreg tests hotspot_all_no_apps and > jdk:tier1-3 passed without incorrect ptrue value assertion failure. > > [1] https://github.com/openjdk/jdk/pull/1621 > [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst > [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch This pull request has now been integrated. Changeset: a7e5da22 Author: Ningsheng Jian URL: https://git.openjdk.java.net/jdk16/commit/a7e5da22 Stats: 61 lines in 6 files changed: 18 ins; 16 del; 27 mod 8258384: AArch64: SVE verify_ptrue fails on some tests Reviewed-by: adinn, ngasson ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From njian at openjdk.java.net Tue Jan 12 01:35:05 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 12 Jan 2021 01:35:05 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests [v3] In-Reply-To: <2vNAJAihgpB4q_wqeuf2Dtjbu9X-NpqfXtNMibnOOUc=.f52ed07a-702f-4d8b-9200-46986181e6a1@github.com> References: <2vNAJAihgpB4q_wqeuf2Dtjbu9X-NpqfXtNMibnOOUc=.f52ed07a-702f-4d8b-9200-46986181e6a1@github.com> Message-ID: On Mon, 11 Jan 2021 09:31:51 GMT, Andrew Dinn wrote: >> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert signal handler changes, which will be fixed in JDK-8259539. > > This looks fine now. Thank you @adinn @nick-arm for the review! ------------- PR: https://git.openjdk.java.net/jdk16/pull/50 From david.holmes at oracle.com Tue Jan 12 02:22:33 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jan 2021 12:22:33 +1000 Subject: RFR: JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling In-Reply-To: <1DuT7x_rffnTozTmD9VzGowaXzasOWQNasDyQfoIjdU=.d14f7967-986a-4483-b0f2-9b355f811015@github.com> References: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> <1DuT7x_rffnTozTmD9VzGowaXzasOWQNasDyQfoIjdU=.d14f7967-986a-4483-b0f2-9b355f811015@github.com> Message-ID: <1f1e5559-7329-0bfa-83f7-8698cd6a68a7@oracle.com> On 11/01/2021 7:59 pm, Thomas Stuefe wrote: > On Thu, 7 Jan 2021 22:42:02 GMT, David Holmes wrote: > >>> AIX 5.3 had buggy __thread support (see JDK-8176442). >>> That's why we introduced a macro USE_LIBRARY_BASED_TLS_ONLY and set it only to 1 on AIX (different to the other platforms supported by the OpenJDK). >>> However AIX 5.3 support was removed some time ago (currently we have a minimum requirement of AIX 7.X ) so the whole USE_LIBRARY_BASED_TLS_ONLY related coding could be removed. >> >> Hi Matthias, >> We didn't introduce USE_LIBRARY_BASED_TLS_ONLY just for AIX, it was also added to aid the mobile project: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-November/020765.html >> Before removing it we would need to have a broader discussion. >> Thanks, >> David > > Hi Matthias, > > Removal looks good. I have a small preference for leaving it in; but OTOS we never really test this coding since all main platforms use __thread. Maybe removal is good then. I'll defer to David for the final decision. Sorry for the delay, I've emailed mobile-dev to see what their usage state is. Cheers, David > Cheers, Thomas > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1976 > From sspitsyn at openjdk.java.net Tue Jan 12 02:46:00 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 12 Jan 2021 02:46:00 GMT Subject: RFR: 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark [v3] In-Reply-To: References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: On Mon, 11 Jan 2021 16:33:12 GMT, Coleen Phillimore wrote: >> See CR for details. This is a hopefully simple cleanup. I didn't try to reason about removing any of these except an obvious call (if you look above the patch in thread.cpp). >> Tested with tier1-3. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix wrong JavaThread::active in fill_in_stack_trace. The fix looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2007 From kim.barrett at oracle.com Tue Jan 12 03:08:50 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 11 Jan 2021 22:08:50 -0500 Subject: RFR: 8258810: Improve enum traits [v2] In-Reply-To: References: Message-ID: <8E29CA1D-A213-4ACA-AAFC-5699890A3DBE@oracle.com> > On Jan 11, 2021, at 3:37 PM, Lois Foltan wrote: > > On Fri, 1 Jan 2021 09:44:18 GMT, Kim Barrett wrote: > >>> Please review these miscellaneous improvements to the enum iteration facility. >>> Thanks to @albertnetymk for discussions. >>> >>> [?] >> >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> ayang review > > LGTM. > Lois > > ------------- > > Marked as reviewed by lfoltan (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1868 Thanks. From kbarrett at openjdk.java.net Tue Jan 12 03:42:23 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 12 Jan 2021 03:42:23 GMT Subject: RFR: 8258810: Improve enum traits [v3] In-Reply-To: References: Message-ID: > Please review these miscellaneous improvements to the enum iteration facility. > Thanks to @albertnetymk for discussions. > > (1) Removed some unneeded stuff from EnumIterationTraits. > > (2) Various similar bits of error checking code are unified and shared via > EnumIterationTraits. > > (3) Casts between the enum type and the underlying type are now done using > helper functions in EnumIterationTraits. > > (4) JDK-8257466 added accessors for the EnumRange bounds and the index for > an enumerator, but didn't account for the possibility of an empty subrange. > Add assertions for that case. > > (5) Added some death tests to verify some of the error checking. > > Testing: > mach5 tier1 Kim Barrett 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 four additional commits since the last revision: - Merge branch 'master' into improve_enum_traits - update copyrights - ayang review - Improve enum traits and tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1868/files - new: https://git.openjdk.java.net/jdk/pull/1868/files/a4667b70..6fdeda47 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1868&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1868&range=01-02 Stats: 33536 lines in 1245 files changed: 10927 ins; 10970 del; 11639 mod Patch: https://git.openjdk.java.net/jdk/pull/1868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1868/head:pull/1868 PR: https://git.openjdk.java.net/jdk/pull/1868 From kbarrett at openjdk.java.net Tue Jan 12 03:42:24 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 12 Jan 2021 03:42:24 GMT Subject: Integrated: 8258810: Improve enum traits In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 18:45:31 GMT, Kim Barrett wrote: > Please review these miscellaneous improvements to the enum iteration facility. > Thanks to @albertnetymk for discussions. > > (1) Removed some unneeded stuff from EnumIterationTraits. > > (2) Various similar bits of error checking code are unified and shared via > EnumIterationTraits. > > (3) Casts between the enum type and the underlying type are now done using > helper functions in EnumIterationTraits. > > (4) JDK-8257466 added accessors for the EnumRange bounds and the index for > an enumerator, but didn't account for the possibility of an empty subrange. > Add assertions for that case. > > (5) Added some death tests to verify some of the error checking. > > Testing: > mach5 tier1 This pull request has now been integrated. Changeset: 2255ab76 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/2255ab76 Stats: 106 lines in 2 files changed: 78 ins; 8 del; 20 mod 8258810: Improve enum traits Reviewed-by: ayang, iklam, lfoltan ------------- PR: https://git.openjdk.java.net/jdk/pull/1868 From coleenp at openjdk.java.net Tue Jan 12 04:00:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 12 Jan 2021 04:00:05 GMT Subject: RFR: 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark [v3] In-Reply-To: References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: On Tue, 12 Jan 2021 02:43:26 GMT, Serguei Spitsyn wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix wrong JavaThread::active in fill_in_stack_trace. > > The fix looks good to me. > Thanks, > Serguei Thanks Serguei! ------------- PR: https://git.openjdk.java.net/jdk/pull/2007 From dholmes at openjdk.java.net Tue Jan 12 04:52:01 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Jan 2021 04:52:01 GMT Subject: [jdk16] RFR: 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049 [v2] In-Reply-To: References: Message-ID: <7lo7BDhAkN7a01RHJGLFcHCPZpziDjq7bMvjDrpGdSY=.70f77c5c-bcc5-4362-8421-20460b05a2d4@github.com> On Mon, 11 Jan 2021 16:00:18 GMT, Aleksey Shipilev wrote: >> Debian folks report that Zero m68k (and seems only that arch) fails the static assert added by JDK-8252049. It affects at least JDK 16, but would affect more releases once JDK-8252049 is backported. >> >> /<>/src/hotspot/share/oops/methodData.hpp: In constructor 'MethodData::CompilerCounters::CompilerCounters()': >> /<>/src/hotspot/share/oops/methodData.hpp:1987:55: error: static assertion failed: align >> 1987 | static_assert(sizeof(_trap_hist) % HeapWordSize == 0, "align"); >> | >> >> I tried to massage the code so that `oops/methodData.hpp` is not touched when Zero is built (since Zero does not use compilers and related infra), but there are enough transitive dependencies to `oops/methodData.hpp` to make it quite messy. So instead I would just special-case it in place. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Added another place where the build fails I prefer NOT_ZERO macro usage over ifdefs, but don't insist. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/102 From iveresov at openjdk.java.net Tue Jan 12 05:04:11 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Tue, 12 Jan 2021 05:04:11 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Check legacy flags validity before deriving flag values for emulation mode. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1985/files - new: https://git.openjdk.java.net/jdk/pull/1985/files/dfffc35b..82dffbe9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=02-03 Stats: 49 lines in 2 files changed: 37 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Tue Jan 12 05:07:01 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Tue, 12 Jan 2021 05:07:01 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> Message-ID: <_kzqYF9JIc1ten32g062993eEyhRKHBGOoKoeemvQ9w=.c98f3d6c-cea1-4a8b-b64e-b4e7108d643d@github.com> On Mon, 11 Jan 2021 17:54:10 GMT, Igor Veresov wrote: >> I see some regression on ARM32 with this change: >> http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ > >> I see some regression on ARM32 with this change: >> http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ > > I don't think those are related to the changes. Those are probably some preexisting c1 and c2 problems respectively that for some reason weren't triggered before. > > The TestOptionsWithRanges is my fault though. I'll fix that. I've added the flag validity pre-checks, which should solve the issues with VM complaining about tiered flags being invalid as a result of CompileThreshold and friends being invalid. We'd have to solve the C1 SIGILL and the C2 loop opts crash separately. Those are not really related to the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From ysuenaga at openjdk.java.net Tue Jan 12 07:01:57 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 12 Jan 2021 07:01:57 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> Message-ID: On Mon, 21 Dec 2020 01:33:58 GMT, Yasumasa Suenaga wrote: >> I think there is a use case for getting an event when an OOM occurs, but the long term plan is to change so that a jdk.JavaErrorThrow is emitted when the exception is thrown, not when the object is allocated. When that is fixed, it will take care of OOME automatically - at all places. I think it is confusing for users to not get an event at every OOME and users/customers will file bugs. > > @egahlin OOME from JVM will not be reported because they are instantiated at JVM init stage and are kept in `Universe`, so they cannot be handled in `ThrowableTracer::traceError`. > We can trace OOMEs which are happened in Java code at `ThrowableTracer::traceError`. However I'm not sure where the event should be handled in. > > For sake of simply, I want to add `jdk.OutOfMemoryError` event to `jdk.jfr` module as a Java class, and I want to emit it from `ThrowableTracer::traceError`, however it duplicates with a definition in JVM. > OTOH we can implement to emit event from `ThrowableTracer::traceError` via `JVM` class, however need to add API to emit events with arbitrary arguments. `Universe` holds some of throwable objects such as `NullPointerException`, `VirtualMachineError`. They could be lost in flight record. This problem is not only for OOME. So I think we need to track all `Throwable` objects in `Exceptions::_throw()` in HotSpot instead of bytecode injection. `ThrowableTracer` has a counter to track num of throwing (`numThrowables`) which is used in `ExceptionStatisticsEvent`, so we also need to track it in HotSpot. I want to hear opinions about it before making changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From stuefe at openjdk.java.net Tue Jan 12 07:31:02 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Jan 2021 07:31:02 GMT Subject: RFR: JDK-8257959: Add gtest run with -XX:+UseLargePages In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 17:26:28 GMT, Thomas Stuefe wrote: >> Looks good. >> Lois > >> Looks good. >> Lois > > Thank you Lois! Gentle ping. May I have another review please? ------------- PR: https://git.openjdk.java.net/jdk/pull/1763 From shade at openjdk.java.net Tue Jan 12 07:51:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Jan 2021 07:51:54 GMT Subject: Integrated: 8259565: Zero: compiler/runtime/criticalnatives fails because CriticalJNINatives is not supported In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 14:12:33 GMT, Aleksey Shipilev wrote: > Zero does not support CriticalJNINatives (and that flag is going away soon), and so the tests are failing with: > > $ CONF=linux-x86_64-zero-fastdebug make exploded-run-test TEST=compiler/runtime/criticalnatives/ > java.lang.Exception: critical native lookup failed > at compiler.runtime.criticalnatives.argumentcorruption.CheckLongArgs.check(CheckLongArgs.java:58) > at compiler.runtime.criticalnatives.argumentcorruption.CheckLongArgs.test(CheckLongArgs.java:48) > at compiler.runtime.criticalnatives.argumentcorruption.CheckLongArgs.main(CheckLongArgs.java:38) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > > There are similar issues for AArch64 (JDK-8191129) and ARM32 (JDK-8213794). Zero needs the same. > > Additional testing: > - [x] Linux x86_64 Zero `compiler/runtime/criticalnatives` (now skipped) > - [x] Linux x86_64 Server `compiler/runtime/criticalnatives` (still run and pass) This pull request has now been integrated. Changeset: 9d4e84fd Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/9d4e84fd Stats: 6 lines in 3 files changed: 4 ins; 0 del; 2 mod 8259565: Zero: compiler/runtime/criticalnatives fails because CriticalJNINatives is not supported Reviewed-by: coleenp, zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/2027 From david.holmes at oracle.com Tue Jan 12 08:09:26 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jan 2021 18:09:26 +1000 Subject: RFR: JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling In-Reply-To: <1f1e5559-7329-0bfa-83f7-8698cd6a68a7@oracle.com> References: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> <1DuT7x_rffnTozTmD9VzGowaXzasOWQNasDyQfoIjdU=.d14f7967-986a-4483-b0f2-9b355f811015@github.com> <1f1e5559-7329-0bfa-83f7-8698cd6a68a7@oracle.com> Message-ID: On 12/01/2021 12:22 pm, David Holmes wrote: > On 11/01/2021 7:59 pm, Thomas Stuefe wrote: >> On Thu, 7 Jan 2021 22:42:02 GMT, David Holmes >> wrote: >> >>>> AIX 5.3 had buggy __thread support (see JDK-8176442). >>>> That's why we introduced a macro USE_LIBRARY_BASED_TLS_ONLY and set >>>> it only to 1 on AIX (different to the other platforms supported by >>>> the OpenJDK). >>>> However AIX 5.3 support was removed some time ago (currently we have >>>> a minimum requirement of AIX 7.X ) so the whole >>>> USE_LIBRARY_BASED_TLS_ONLY related coding could be removed. >>> >>> Hi Matthias, >>> We didn't introduce USE_LIBRARY_BASED_TLS_ONLY just for AIX, it was >>> also added to aid the mobile project: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-November/020765.html >>> >>> Before removing it we would need to have a broader discussion. >>> Thanks, >>> David >> >> Hi Matthias, >> >> Removal looks good. I have a small preference for leaving it in; but >> OTOS we never really test this coding since all main platforms use >> __thread. Maybe removal is good then. I'll defer to David for the >> final decision. > > Sorry for the delay, I've emailed mobile-dev to see what their usage > state is. But that aside I've just looked at the proposed RISC-V 64 port and they declare USE_LIBRARY_BASED_TLS_ONLY for JDK 11 at least (mainline port is not public yet). So perhaps it would be prudent to leave this in place for a while longer and just make the AIX specific change. Cheers, David > Cheers, > David > >> Cheers, Thomas >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/1976 >> From glaubitz at openjdk.java.net Tue Jan 12 08:41:58 2021 From: glaubitz at openjdk.java.net (John Paul Adrian Glaubitz) Date: Tue, 12 Jan 2021 08:41:58 GMT Subject: [jdk16] RFR: 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049 [v2] In-Reply-To: <7lo7BDhAkN7a01RHJGLFcHCPZpziDjq7bMvjDrpGdSY=.70f77c5c-bcc5-4362-8421-20460b05a2d4@github.com> References: <7lo7BDhAkN7a01RHJGLFcHCPZpziDjq7bMvjDrpGdSY=.70f77c5c-bcc5-4362-8421-20460b05a2d4@github.com> Message-ID: <20-5SFGrQn7k1lNWc7TJe8P925nhvdpBxbtZXNrLC6M=.8c1b8021-92e7-40de-8637-1a244b21551f@github.com> On Tue, 12 Jan 2021 04:49:16 GMT, David Holmes wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Added another place where the build fails > > I prefer NOT_ZERO macro usage over ifdefs, but don't insist. > > Thanks, > David I can confirm that the current PR fixes the problem for me. ------------- PR: https://git.openjdk.java.net/jdk16/pull/102 From david.holmes at oracle.com Tue Jan 12 08:57:17 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jan 2021 18:57:17 +1000 Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: References: Message-ID: <50a57c3e-aa5a-d845-c0ab-c83b2ded221e@oracle.com> On 11/01/2021 10:49 pm, Coleen Phillimore wrote: > On Thu, 7 Jan 2021 22:29:10 GMT, Coleen Phillimore wrote: > >>> Looks good to me! >> >> Thanks Dan and Patricio! > >> What JNI_LEAF function does as you describe? > 1. > JNI_LEAF(void, JVM_RegisterNativeEntryPointMethods(JNIEnv *env, jclass NEP_class)) > int status = env->RegisterNatives(NEP_class, NEP_methods, sizeof(NEP_methods)/sizeof(JNINativeMethod)); > guarantee(status == JNI_OK && !env->ExceptionOccurred(), > "register jdk.internal.invoke.NativeEntryPoint natives"); > JNI_END > Also: JVM_RegisterProgrammableInvokerMethods, JVM_RegisterProgrammableUpcallHandlerMethods Okay ... these really should not be "leaf" methods they are full JNI entries because they call a JNI_ENTRY method. I vaguely recall some discussion around this ... issues with a JNI_ENTRY calling a JNI_ENTRY, so JNI_LEAF was used to get a lightweight entry point that simply called the real JNI_ENTRY method. > 2. The real reason that I wrote this is patch is so that each of these ThreadInVMfromNative calls (from the compiler and JFR) don't need to also have ResetNoHandleMark. The intention is to hide this detail so one doesn't need to try to figure out what this is when reading through the code. It is debug code, so after the transition, there is no need to have a NoHandleMark. My original intention is to hide this as much as possible since it's a weird artifact of our implementation of Handles. It's noise, that I've always ignored until now. My concern is that "leaf" methods should not be doing ThreadInVMFromNative so we shouldn't have to make any changes to the definition of JNI_LEAF because of this. :( I think this use of JNI_LEAF needs to be re-examined, but I won't insist on that here or object to the proposed changes. Thanks, David ----- > Thanks. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1983 > From david.holmes at oracle.com Tue Jan 12 09:02:08 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jan 2021 19:02:08 +1000 Subject: RFR: 8259486: Remove CautiouslyPreserveExceptionMark In-Reply-To: References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: <178f06fc-dcfd-359a-3f78-97390cf8c8b9@oracle.com> On 11/01/2021 10:58 pm, Coleen Phillimore wrote: > On Mon, 11 Jan 2021 01:13:25 GMT, David Holmes wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 2556: >> >>> 2554: >>> 2555: JavaThread* thread = JavaThread::active(); >>> 2556: PreserveExceptionMark pm(thread); >> >> The result of JavaThread::active() is not necessarily the current thread. So either the new code is wrong or else we should just be using JavaThread::current() > > My first iteration of this change knew there was a difference then I cleaned it up. I'll restore the Thread::current() in the PEM constructor. I'm not so sure the use of JavaThread::active() is correct. It implies that we will throw an exception via the VMThread, which surely is not allowed! ?? David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2007 > From david.holmes at oracle.com Tue Jan 12 09:03:39 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jan 2021 19:03:39 +1000 Subject: RFR: 8259486: Remove CautiouslyPreserveExceptionMark In-Reply-To: <178f06fc-dcfd-359a-3f78-97390cf8c8b9@oracle.com> References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> <178f06fc-dcfd-359a-3f78-97390cf8c8b9@oracle.com> Message-ID: On 12/01/2021 7:02 pm, David Holmes wrote: > On 11/01/2021 10:58 pm, Coleen Phillimore wrote: >> On Mon, 11 Jan 2021 01:13:25 GMT, David Holmes >> wrote: >>> src/hotspot/share/classfile/javaClasses.cpp line 2556: >>> >>>> 2554: >>>> 2555:?? JavaThread* thread = JavaThread::active(); >>>> 2556:?? PreserveExceptionMark pm(thread); >>> >>> The result of JavaThread::active() is not necessarily the current >>> thread. So either the new code is wrong or else we should just be >>> using JavaThread::current() >> >> My first iteration of this change knew there was a difference then I >> cleaned it up.? I'll restore the Thread::current() in the PEM >> constructor. > > I'm not so sure the use of JavaThread::active() is correct. It implies > that we will throw an exception via the VMThread, which surely is not > allowed! ?? Sorry missed your later email under the new subject :) David ----- > David > ----- > >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/2007 >> From aph at openjdk.java.net Tue Jan 12 10:28:57 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 12 Jan 2021 10:28:57 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 12:28:57 GMT, Dong Bo wrote: >> The `Math.abs(doublesA[i] - doublesB[i])` has `~36%` improvements. >> I updated the tests for doubles with `Math.abs()`, it looks more consistent. Thanks. >> The JMH results of doubles with `Math.abs()`: >> Benchmark (COUNT_DOUBLE) (COUNT_FLOAT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 681.319 ? 0.658 ns/op >> VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 682.596 ? 4.322 ns/op >> # Kunpeng 916, fmaxp/fminp >> VectorReductionFloatingMinMax.maxRedD 512 3 0 avgt 10 439.130 ? 0.450 ns/op => 35.54% >> VectorReductionFloatingMinMax.minRedD 512 3 0 avgt 10 439.105 ? 0.435 ns/op => 35.67% > > For single-precision floating-point operands, as the experiments showed, we can have `Max2F` match only with `COUNT == 3`. > With such a small loop under superword framework, it is diffcult to tell how much improvements of `fmaxp/fminp` over `fmaxv+ins`. > > Although it sounds unreasonable for an application to use `Float64Vector` rather than `Float128Vecotor`, > the optimization does being useful for VectorAPI `Float64Vector.reduceLanes(VectorOperators.MAX)` as mentioned previously. > > Do you think we should remove single-precision floating-point parts in this patch? OK, I guess we'll keep both. Even though the acceleration for single-precision float is disappointing on these cores, it might well be useful for some future processor, and I do care about the Vector API. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From aph at openjdk.java.net Tue Jan 12 10:28:56 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 12 Jan 2021 10:28:56 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v6] In-Reply-To: <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com> References: <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com> Message-ID: On Mon, 11 Jan 2021 11:41:13 GMT, Dong Bo wrote: >> This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. >> >> Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. >> Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. >> >> Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. >> Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: >> Benchmark (COUNT) (seed) Mode Cnt Score Error Units >> # Kunpeng 916, default >> VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op >> VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op >> VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op >> VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op >> >> # Kunpeng 916, with fmaxp/fminp >> VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% >> VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op >> VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% >> VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op > > Dong Bo has updated the pull request incrementally with one additional commit since the last revision: > > test improvements for doubles with Math.abs() Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From ayang at openjdk.java.net Tue Jan 12 11:20:06 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 12 Jan 2021 11:20:06 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing Message-ID: The first commit removes some obsolete enum items, while the second commit adds the verification logic. Commit 2 introduces some "empty" task claims for the verification logic, explicitly marked in the comments. Test: hotspot_gc ------------- Commit messages: - add claim verification - remove unused enum items Changes: https://git.openjdk.java.net/jdk/pull/2046/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2046&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8074101 Stats: 59 lines in 8 files changed: 29 ins; 20 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2046.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2046/head:pull/2046 PR: https://git.openjdk.java.net/jdk/pull/2046 From dongbo at openjdk.java.net Tue Jan 12 12:58:55 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 12 Jan 2021 12:58:55 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v6] In-Reply-To: References: <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com> Message-ID: On Tue, 12 Jan 2021 10:26:39 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> test improvements for doubles with Math.abs() > > Marked as reviewed by aph (Reviewer). @theRealAph Thanks for the review. @pfustc @DamonFool Thank you for looking into this. I see some aarch64 files created recently include Oracle copyright, e.g. `aarch64_sve.ad`. And when I wrote the test code, I did take some files with Oracle copyright as references. I think the Oracle copyright statements in testcode should be kept there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From mbaesken at openjdk.java.net Tue Jan 12 13:00:12 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 12 Jan 2021 13:00:12 GMT Subject: RFR: JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling [v2] In-Reply-To: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> References: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> Message-ID: > AIX 5.3 had buggy __thread support (see JDK-8176442). > That's why we introduced a macro USE_LIBRARY_BASED_TLS_ONLY and set it only to 1 on AIX (different to the other platforms supported by the OpenJDK). > However AIX 5.3 support was removed some time ago (currently we have a minimum requirement of AIX 7.X ) so the whole USE_LIBRARY_BASED_TLS_ONLY related coding could be removed. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1976/files - new: https://git.openjdk.java.net/jdk/pull/1976/files/aa98142c..3944582e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1976&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1976&range=00-01 Stats: 16 lines in 2 files changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1976/head:pull/1976 PR: https://git.openjdk.java.net/jdk/pull/1976 From coleenp at openjdk.java.net Tue Jan 12 13:09:59 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 12 Jan 2021 13:09:59 GMT Subject: Integrated: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 18:28:54 GMT, Coleen Phillimore wrote: > Please review this straightforward change to add a ResetNoHandleMark in the ThreadInVMfromNative transition class so that callers don't have to do this. Tested with tier1-3. > This was broken out of a larger change for JDK-8258032 Reconsider LEAF entry restrictions. This pull request has now been integrated. Changeset: 4c75d14a Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/4c75d14a Stats: 18 lines in 7 files changed: 4 ins; 8 del; 6 mod 8259374: Make ThreadInVMfromNative have ResetNoHandleMark Reviewed-by: dcubed, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/1983 From coleenp at openjdk.java.net Tue Jan 12 13:09:59 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 12 Jan 2021 13:09:59 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 12:47:10 GMT, Coleen Phillimore wrote: >> Thanks Dan and Patricio! > >> What JNI_LEAF function does as you describe? > 1. > JNI_LEAF(void, JVM_RegisterNativeEntryPointMethods(JNIEnv *env, jclass NEP_class)) > int status = env->RegisterNatives(NEP_class, NEP_methods, sizeof(NEP_methods)/sizeof(JNINativeMethod)); > guarantee(status == JNI_OK && !env->ExceptionOccurred(), > "register jdk.internal.invoke.NativeEntryPoint natives"); > JNI_END > Also: JVM_RegisterProgrammableInvokerMethods, JVM_RegisterProgrammableUpcallHandlerMethods > 2. The real reason that I wrote this is patch is so that each of these ThreadInVMfromNative calls (from the compiler and JFR) don't need to also have ResetNoHandleMark. The intention is to hide this detail so one doesn't need to try to figure out what this is when reading through the code. It is debug code, so after the transition, there is no need to have a NoHandleMark. My original intention is to hide this as much as possible since it's a weird artifact of our implementation of Handles. It's noise, that I've always ignored until now. > Thanks. > I think this use of JNI_LEAF needs to be re-examined, but I won't insist > on that here or object to the proposed changes. Ok, thanks. We could file another RFE to reexamine why these are LEAF methods. There might be a bigger change to call the vm code directly instead of env->RegisterNatives that I don't want to get into in this change. Thanks for the code reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/1983 From coleenp at openjdk.java.net Tue Jan 12 13:17:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 12 Jan 2021 13:17:56 GMT Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: <_idMfO5Oq1M0_pUK6iVBYbkm_mLjmkcJfexeBjTzad4=.0b3a1f1e-76f2-41a8-9bd3-ca0fe48dd090@github.com> References: <2U9_AyzJPQKlEFk3rC94U85uDzE7pl1rUfsshKrwzII=.e6fff35d-7b31-468d-a31d-0b18f212ea49@github.com> <_idMfO5Oq1M0_pUK6iVBYbkm_mLjmkcJfexeBjTzad4=.0b3a1f1e-76f2-41a8-9bd3-ca0fe48dd090@github.com> Message-ID: On Fri, 8 Jan 2021 13:14:36 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 195: >> >>> 193: >>> 194: class ThreadInVMfromNative : public ThreadStateTransition { >>> 195: ResetNoHandleMark __rnhm; >> >> We should add a constructor for RNHM that takes the current thread so that we don't have to call Thread::current() unnecessarily in the existing RNHM constructor. > > Ok but the ResetNoHandleMark implementation disappears in product mode, so it doesn't actually call Thread::current() in product mode. I forgot to push the change up to add a ResetNoHandleMark that takes a Thread* parameter. Since it evaporates in product mode, I don't think it's needed or helpful. I could add it back with https://github.com/openjdk/jdk/pull/1990 if you insist. ------------- PR: https://git.openjdk.java.net/jdk/pull/1983 From dongbo at openjdk.java.net Tue Jan 12 13:30:57 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 12 Jan 2021 13:30:57 GMT Subject: Integrated: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 06:23:33 GMT, Dong Bo wrote: > This patch optimizes vectorial Min/Max reduction of two floating-point numbers on aarch64 with NEON instructions `fmaxp` and `fminp`. > > Passed jtreg tier1-3 tests with `linux-aarch64-server-fastdebug` build. > Tests under `test/jdk/jdk/incubator/vector/` runned specially for the correctness and passed. > > Introduced a new JMH micro `test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java` for performance test. > Witnessed abount `37%` performance improvements on Kunpeng916. The JMH Results: > Benchmark (COUNT) (seed) Mode Cnt Score Error Units > # Kunpeng 916, default > VectorReduction.maxRedD 512 0 avgt 10 678.126 ? 0.815 ns/op > VectorReduction.maxRedF 512 0 avgt 10 242.958 ? 0.212 ns/op > VectorReduction.minRedD 512 0 avgt 10 678.554 ? 0.824 ns/op > VectorReduction.minRedF 512 0 avgt 10 243.368 ? 0.205 ns/op > > # Kunpeng 916, with fmaxp/fminp > VectorReduction.maxRedD 512 0 avgt 10 430.201 ? 0.353 ns/op => 36.56% > VectorReduction.maxRedF 512 0 avgt 10 243.404 ? 0.297 ns/op > VectorReduction.minRedD 512 0 avgt 10 427.805 ? 0.528 ns/op => 36.89% > VectorReduction.minRedF 512 0 avgt 10 242.963 ? 0.210 ns/op This pull request has now been integrated. Changeset: ccac7aae Author: Dong Bo Committer: Fei Yang URL: https://git.openjdk.java.net/jdk/commit/ccac7aae Stats: 658 lines in 7 files changed: 226 ins; 93 del; 339 mod 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp Reviewed-by: aph ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From kbarrett at openjdk.java.net Tue Jan 12 14:13:57 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 12 Jan 2021 14:13:57 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v6] In-Reply-To: References: <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com> Message-ID: On Tue, 12 Jan 2021 12:56:03 GMT, Dong Bo wrote: >> Marked as reviewed by aph (Reviewer). > > @theRealAph Thanks for the review. > > @pfustc @DamonFool Thank you for looking into this. > I see some aarch64 files created recently include Oracle copyright, e.g. `aarch64_sve.ad`. > And when I wrote the test code, I did take some files with Oracle copyright as references. > I think the Oracle copyright statements in testcode should be kept there. All linux-aarch64 builds have started failing in Oracle's CI testing after this change was pushed. See https://bugs.openjdk.java.net/browse/JDK-8259629 ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From bulasevich at openjdk.java.net Tue Jan 12 14:44:01 2021 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Tue, 12 Jan 2021 14:44:01 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v2] In-Reply-To: <_kzqYF9JIc1ten32g062993eEyhRKHBGOoKoeemvQ9w=.c98f3d6c-cea1-4a8b-b64e-b4e7108d643d@github.com> References: <4dUsRpBUTXPn9PhqCJx9Y8X-XVGo08IZv1lzDEdsKtI=.92d358a3-1355-4e95-9f37-0e555ce11018@github.com> <_kzqYF9JIc1ten32g062993eEyhRKHBGOoKoeemvQ9w=.c98f3d6c-cea1-4a8b-b64e-b4e7108d643d@github.com> Message-ID: On Tue, 12 Jan 2021 05:03:45 GMT, Igor Veresov wrote: >>> I see some regression on ARM32 with this change: >>> http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/ >> >> I don't think those are related to the changes. Those are probably some preexisting c1 and c2 problems respectively that for some reason weren't triggered before. >> >> The TestOptionsWithRanges is my fault though. I'll fix that. > > I've added the flag validity pre-checks, which should solve the issues with VM complaining about tiered flags being invalid as a result of CompileThreshold and friends being invalid. We'd have to solve the C1 SIGILL and the C2 loop opts crash separately. Those are not really related to the change. Ok. I will see what is wrong there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From mbaesken at openjdk.java.net Tue Jan 12 14:45:56 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 12 Jan 2021 14:45:56 GMT Subject: RFR: JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling In-Reply-To: <1DuT7x_rffnTozTmD9VzGowaXzasOWQNasDyQfoIjdU=.d14f7967-986a-4483-b0f2-9b355f811015@github.com> References: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> <1DuT7x_rffnTozTmD9VzGowaXzasOWQNasDyQfoIjdU=.d14f7967-986a-4483-b0f2-9b355f811015@github.com> Message-ID: On Mon, 11 Jan 2021 09:57:10 GMT, Thomas Stuefe wrote: >> Hi Matthias, >> We didn't introduce USE_LIBRARY_BASED_TLS_ONLY just for AIX, it was also added to aid the mobile project: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-November/020765.html >> Before removing it we would need to have a broader discussion. >> Thanks, >> David > > Hi Matthias, > > Removal looks good. I have a small preference for leaving it in; but OTOS we never really test this coding since all main platforms use __thread. Maybe removal is good then. I'll defer to David for the final decision. > > Cheers, Thomas Hi, considering RISC-V and potential use for mobile , I think I better touch only the AIX specifics and leave the shared code as it is . Please see the latest change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1976 From kbarrett at openjdk.java.net Tue Jan 12 15:05:02 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 12 Jan 2021 15:05:02 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 11:13:29 GMT, Albert Mingkun Yang wrote: > The first commit removes some obsolete enum items, while the second commit adds the verification logic. Commit 2 introduces some "empty" task claims for the verification logic, explicitly marked in the comments. > > Test: hotspot_gc src/hotspot/share/gc/g1/g1RootProcessor.cpp line 66: > 64: // already processed in java roots. > 65: _process_strong_tasks.try_claim_task(G1RP_PS_CodeCache_oops_do); > 66: #endif Rather than these fake claims, consider something like this: template void all_tasks_completed(uint nworkers, Ts... tags) { // Type-check more_skipped are all of the same type as first_skipped. T0 typed_skipped[] = { first_skipped, more_skipped... }; uint skipped[] = { static_cast(tags)... }; all_tasks_completed_impl(nworkers, skipped, ARRAY_SIZE(skipped)); } void all_tasks_completed(uint nworkers) { all_tasks_completed_impl(nworkers, nullptr, 0); } Usage: all_tasks_completed(n_workers(), G1RP_PS_CodeCache_oops_do, G1RP_PS_refProcessor_oops_do) all_tasks_completed_impl can check that all tasks have been claimed except the skipped ones, which have not been claimed. There might be better ways to write the variadic all_tasks_completed. It's been a while since I've done anything with variadic templates. ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From hseigel at openjdk.java.net Tue Jan 12 15:23:11 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 12 Jan 2021 15:23:11 GMT Subject: RFR: 8258912: Remove JVM options CountJNICalls and CountJVMCalls Message-ID: Please review this change to remove the old non-product JVM -XX flags CountRuntimeCalls, CountJNICalls, CountJVMCalls, and CountRemovableExceptions. Additionally, this change removes non-product flag WarnOnStalledSpinLock because, as a result of this change, it is no longer used. The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. Thanks, Harold ------------- Commit messages: - 8258912: Remove JVM options CountJNICalls and CountJVMCalls Changes: https://git.openjdk.java.net/jdk/pull/2050/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2050&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258912 Stats: 708 lines in 11 files changed: 0 ins; 702 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2050.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2050/head:pull/2050 PR: https://git.openjdk.java.net/jdk/pull/2050 From coleenp at openjdk.java.net Tue Jan 12 15:33:59 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 12 Jan 2021 15:33:59 GMT Subject: RFR: 8258912: Remove JVM options CountJNICalls and CountJVMCalls In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 15:17:52 GMT, Harold Seigel wrote: > Please review this change to remove the old non-product JVM -XX flags CountRuntimeCalls, CountJNICalls, CountJVMCalls, and CountRemovableExceptions. Additionally, this change removes non-product flag WarnOnStalledSpinLock because, as a result of this change, it is no longer used. > > The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold LGTM! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2050 From lfoltan at openjdk.java.net Tue Jan 12 15:44:58 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Tue, 12 Jan 2021 15:44:58 GMT Subject: RFR: 8258912: Remove JVM options CountJNICalls and CountJVMCalls In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 15:17:52 GMT, Harold Seigel wrote: > Please review this change to remove the old non-product JVM -XX flags CountRuntimeCalls, CountJNICalls, CountJVMCalls, and CountRemovableExceptions. Additionally, this change removes non-product flag WarnOnStalledSpinLock because, as a result of this change, it is no longer used. > > The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold LGTM. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2050 From dongbo at openjdk.java.net Tue Jan 12 16:28:10 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 12 Jan 2021 16:28:10 GMT Subject: RFR: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp [v6] In-Reply-To: References: <4nnhdRP9gsILzFv5MvE_1usJtLBwmtoThIErfRgcftw=.277fc10e-1bc2-4a99-97e6-ca1562b625c3@github.com> Message-ID: <-ySS8X0WKKilPfASGTraHnIkUErfiVFjOoPcFgponTg=.45a4032e-122e-4cdf-9a91-aa0afdcd90a7@github.com> On Tue, 12 Jan 2021 14:11:07 GMT, Kim Barrett wrote: > All linux-aarch64 builds have started failing in Oracle's CI testing after this change was pushed. > See https://bugs.openjdk.java.net/browse/JDK-8259629 I'm really sorry for producing a serious BUG here. I have raise a PR [1] to fix this. Would you mind having a look? Thanks. [1] https://github.com/openjdk/jdk/pull/2052 ------------- PR: https://git.openjdk.java.net/jdk/pull/1925 From dongbo at openjdk.java.net Tue Jan 12 16:30:07 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 12 Jan 2021 16:30:07 GMT Subject: RFR: 8259629: aarch64 builds fail after JDK-8258932 Message-ID: This fixes aarch64 builds failure after JDK-8258932. It is caused by the mismatched call `fmaxp/fminp` in `AssemblerAArch64` tests to the definitions in `assembler_aarch64.hpp`. Verified with `gtest-1.8.1` and `make test TEST="gtest"`, `linux-aarch64-server-slowdebug`. Both builds and tests are good, the results of `gtest` on my aarch64 server: Finished running test 'gtest:all/server' Test report is stored in build/linux-aarch64-server-slowdebug/test-results/gtest_all_server ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR gtest:all/server 807 807 0 0 ============================== TEST SUCCESS Finished building target 'test' in configuration 'linux-aarch64-server-slowdebug' The `gtest` was not configured during tests in `JDK-8258932`, so it did not execute previously. I'm really sorry for my carelessness and producing a serious BUG. ------------- Commit messages: - 8259629: aarch64 builds fail after JDK-8258932 Changes: https://git.openjdk.java.net/jdk/pull/2052/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2052&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259629 Stats: 8 lines in 2 files changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2052.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2052/head:pull/2052 PR: https://git.openjdk.java.net/jdk/pull/2052 From kbarrett at openjdk.java.net Tue Jan 12 17:16:55 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 12 Jan 2021 17:16:55 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 15:02:27 GMT, Kim Barrett wrote: >> The first commit removes some obsolete enum items, while the second commit adds the verification logic. Commit 2 introduces some "empty" task claims for the verification logic, explicitly marked in the comments. >> >> Test: hotspot_gc > > src/hotspot/share/gc/g1/g1RootProcessor.cpp line 66: > >> 64: // already processed in java roots. >> 65: _process_strong_tasks.try_claim_task(G1RP_PS_CodeCache_oops_do); >> 66: #endif > > Rather than these fake claims, consider something like this: > > template > void all_tasks_completed(uint nworkers, Ts... tags) { > // Type-check more_skipped are all of the same type as first_skipped. > T0 typed_skipped[] = { first_skipped, more_skipped... }; > uint skipped[] = { static_cast(tags)... }; > all_tasks_completed_impl(nworkers, skipped, ARRAY_SIZE(skipped)); > } > > void all_tasks_completed(uint nworkers) { > all_tasks_completed_impl(nworkers, nullptr, 0); > } > > Usage: > > all_tasks_completed(n_workers(), > G1RP_PS_CodeCache_oops_do, > G1RP_PS_refProcessor_oops_do) > > all_tasks_completed_impl can check that all tasks have been claimed except > the skipped ones, which have not been claimed. > > There might be better ways to write the variadic all_tasks_completed. It's > been a while since I've done anything with variadic templates. Here's a better version of the variadic `all_tasks_completed` template...>::value)> void all_tasks_completed(uint n_threads, T0 first_skipped, Ts... more_skipped) { static_assert(std::is_convertible::value, "not convertible"); uint skipped[] = { static_cast(first_skipped), static_cast(more_skipped)... }; all_tasks_completed_impl(n_threads, skipped, ARRAY_SIZE(skipped)); } `Conjunction` is in metaprogramming/logical.hpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From dcubed at openjdk.java.net Tue Jan 12 18:14:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 12 Jan 2021 18:14:56 GMT Subject: RFR: 8259629: aarch64 builds fail after JDK-8258932 In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 16:23:56 GMT, Dong Bo wrote: > This fixes aarch64 builds failure after JDK-8258932. > It is caused by the mismatched call `fmaxp/fminp` in `AssemblerAArch64` tests to the definitions in `assembler_aarch64.hpp`. > > Verified with `gtest-1.8.1` and `make test TEST="gtest"`, `linux-aarch64-server-slowdebug`. > Both builds and tests are good, the results of `gtest` on my aarch64 server: > Finished running test 'gtest:all/server' > Test report is stored in build/linux-aarch64-server-slowdebug/test-results/gtest_all_server > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > gtest:all/server 807 807 0 0 > ============================== > TEST SUCCESS > > Finished building target 'test' in configuration 'linux-aarch64-server-slowdebug' > > The `gtest` was not configured during tests in `JDK-8258932`, so it did not execute previously. > I'm really sorry for my carelessness and producing a serious BUG. I'm testing this patch with linux-aarch64 Mach5 tier1. ------------- PR: https://git.openjdk.java.net/jdk/pull/2052 From dcubed at openjdk.java.net Tue Jan 12 18:34:54 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 12 Jan 2021 18:34:54 GMT Subject: RFR: 8259629: aarch64 builds fail after JDK-8258932 In-Reply-To: References: Message-ID: <5cx4IxYGSTLV0Ecm56D0QxrihJa6-xtbWp4buOYp3I4=.8d5e220b-3a58-45e7-82a1-66b92fc7596f@github.com> On Tue, 12 Jan 2021 18:11:45 GMT, Daniel D. Daugherty wrote: >> This fixes aarch64 builds failure after JDK-8258932. >> It is caused by the mismatched call `fmaxp/fminp` in `AssemblerAArch64` tests to the definitions in `assembler_aarch64.hpp`. >> >> Verified with `gtest-1.8.1` and `make test TEST="gtest"`, `linux-aarch64-server-slowdebug`. >> Both builds and tests are good, the results of `gtest` on my aarch64 server: >> Finished running test 'gtest:all/server' >> Test report is stored in build/linux-aarch64-server-slowdebug/test-results/gtest_all_server >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> gtest:all/server 807 807 0 0 >> ============================== >> TEST SUCCESS >> >> Finished building target 'test' in configuration 'linux-aarch64-server-slowdebug' >> >> The `gtest` was not configured during tests in `JDK-8258932`, so it did not execute previously. >> I'm really sorry for my carelessness and producing a serious BUG. > > I'm testing this patch with linux-aarch64 Mach5 tier1. The three build tasks (linux-aarch64, linux-aarch64-debug and linux-aarch64-open) all passed. Tier1 testing is still running. ------------- PR: https://git.openjdk.java.net/jdk/pull/2052 From dcubed at openjdk.java.net Tue Jan 12 18:38:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 12 Jan 2021 18:38:56 GMT Subject: RFR: 8259629: aarch64 builds fail after JDK-8258932 In-Reply-To: <5cx4IxYGSTLV0Ecm56D0QxrihJa6-xtbWp4buOYp3I4=.8d5e220b-3a58-45e7-82a1-66b92fc7596f@github.com> References: <5cx4IxYGSTLV0Ecm56D0QxrihJa6-xtbWp4buOYp3I4=.8d5e220b-3a58-45e7-82a1-66b92fc7596f@github.com> Message-ID: <_8bnhD-W66IzsPNbpPDDnLpN4er5-Qe8PfMkzsPYCDE=.ce1cbc21-5434-4a66-a189-f8d89e757583@github.com> On Tue, 12 Jan 2021 18:32:14 GMT, Daniel D. Daugherty wrote: >> I'm testing this patch with linux-aarch64 Mach5 tier1. > > The three build tasks (linux-aarch64, linux-aarch64-debug and linux-aarch64-open) > all passed. Tier1 testing is still running. @theRealAph - since you were the one reviewer on https://bugs.openjdk.java.net/browse/JDK-8258932 it would be good if you reviewed this build fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/2052 From ayang at openjdk.java.net Tue Jan 12 18:46:15 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 12 Jan 2021 18:46:15 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 17:14:10 GMT, Kim Barrett wrote: >> src/hotspot/share/gc/g1/g1RootProcessor.cpp line 66: >> >>> 64: // already processed in java roots. >>> 65: _process_strong_tasks.try_claim_task(G1RP_PS_CodeCache_oops_do); >>> 66: #endif >> >> Rather than these fake claims, consider something like this: >> >> template >> void all_tasks_completed(uint nworkers, Ts... tags) { >> // Type-check more_skipped are all of the same type as first_skipped. >> T0 typed_skipped[] = { first_skipped, more_skipped... }; >> uint skipped[] = { static_cast(tags)... }; >> all_tasks_completed_impl(nworkers, skipped, ARRAY_SIZE(skipped)); >> } >> >> void all_tasks_completed(uint nworkers) { >> all_tasks_completed_impl(nworkers, nullptr, 0); >> } >> >> Usage: >> >> all_tasks_completed(n_workers(), >> G1RP_PS_CodeCache_oops_do, >> G1RP_PS_refProcessor_oops_do) >> >> all_tasks_completed_impl can check that all tasks have been claimed except >> the skipped ones, which have not been claimed. >> >> There might be better ways to write the variadic all_tasks_completed. It's >> been a while since I've done anything with variadic templates. > > Here's a better version of the variadic `all_tasks_completed` > > template ENABLE_IF(Conjunction...>::value)> > void all_tasks_completed(uint n_threads, T0 first_skipped, Ts... more_skipped) { > static_assert(std::is_convertible::value, "not convertible"); > uint skipped[] = { static_cast(first_skipped), static_cast(more_skipped)... }; > all_tasks_completed_impl(n_threads, skipped, ARRAY_SIZE(skipped)); > } > `Conjunction` is in metaprogramming/logical.hpp. Thank you; updated as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From ayang at openjdk.java.net Tue Jan 12 18:46:15 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 12 Jan 2021 18:46:15 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v2] In-Reply-To: References: Message-ID: > The first commit removes some obsolete enum items, while the second commit adds the verification logic. Commit 2 introduces some "empty" task claims for the verification logic, explicitly marked in the comments. > > Test: hotspot_gc Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2046/files - new: https://git.openjdk.java.net/jdk/pull/2046/files/4fc22b48..938dce1d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2046&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2046&range=00-01 Stats: 71 lines in 3 files changed: 35 ins; 25 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2046.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2046/head:pull/2046 PR: https://git.openjdk.java.net/jdk/pull/2046 From kvn at openjdk.java.net Tue Jan 12 18:56:05 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 12 Jan 2021 18:56:05 GMT Subject: RFR: 8259629: aarch64 builds fail after JDK-8258932 In-Reply-To: References: Message-ID: <7b3kZetb-LRNPlInkbXO6ujx9Mwsucmkm_i4YfQgq4w=.7cc4d39e-879d-40f5-ad7e-2f1081781ca5@github.com> On Tue, 12 Jan 2021 16:23:56 GMT, Dong Bo wrote: > This fixes aarch64 builds failure after JDK-8258932. > It is caused by the mismatched call `fmaxp/fminp` in `AssemblerAArch64` tests to the definitions in `assembler_aarch64.hpp`. > > Verified with `gtest-1.8.1` and `make test TEST="gtest"`, `linux-aarch64-server-slowdebug`. > Both builds and tests are good, the results of `gtest` on my aarch64 server: > Finished running test 'gtest:all/server' > Test report is stored in build/linux-aarch64-server-slowdebug/test-results/gtest_all_server > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > gtest:all/server 807 807 0 0 > ============================== > TEST SUCCESS > > Finished building target 'test' in configuration 'linux-aarch64-server-slowdebug' > > The `gtest` was not configured during tests in `JDK-8258932`, so it did not execute previously. > I'm really sorry for my carelessness and producing a serious BUG. It passed out whole tier1 testing I ran. So I am fine with it, But I would like to see review from someone familiar with Aaarch64 assembler too. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2052 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 kvn at openjdk.java.net Tue Jan 12 20:14:00 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 12 Jan 2021 20:14:00 GMT Subject: RFR: 8259629: aarch64 builds fail after JDK-8258932 In-Reply-To: <7b3kZetb-LRNPlInkbXO6ujx9Mwsucmkm_i4YfQgq4w=.7cc4d39e-879d-40f5-ad7e-2f1081781ca5@github.com> References: <7b3kZetb-LRNPlInkbXO6ujx9Mwsucmkm_i4YfQgq4w=.7cc4d39e-879d-40f5-ad7e-2f1081781ca5@github.com> Message-ID: On Tue, 12 Jan 2021 18:53:35 GMT, Vladimir Kozlov wrote: >> This fixes aarch64 builds failure after JDK-8258932. >> It is caused by the mismatched call `fmaxp/fminp` in `AssemblerAArch64` tests to the definitions in `assembler_aarch64.hpp`. >> >> Verified with `gtest-1.8.1` and `make test TEST="gtest"`, `linux-aarch64-server-slowdebug`. >> Both builds and tests are good, the results of `gtest` on my aarch64 server: >> Finished running test 'gtest:all/server' >> Test report is stored in build/linux-aarch64-server-slowdebug/test-results/gtest_all_server >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> gtest:all/server 807 807 0 0 >> ============================== >> TEST SUCCESS >> >> Finished building target 'test' in configuration 'linux-aarch64-server-slowdebug' >> >> The `gtest` was not configured during tests in `JDK-8258932`, so it did not execute previously. >> I'm really sorry for my carelessness and producing a serious BUG. > > It passed out whole tier1 testing I ran. So I am fine with it, > > But I would like to see review from someone familiar with Aaarch64 assembler too. After internal discussion and urgency we suggest to push this fix ASAP. @dgbo please integrate it and I will sponsor. ------------- PR: https://git.openjdk.java.net/jdk/pull/2052 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 egahlin at openjdk.java.net Tue Jan 12 21:59:56 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 12 Jan 2021 21:59:56 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> Message-ID: On Tue, 12 Jan 2021 06:59:37 GMT, Yasumasa Suenaga wrote: >> @egahlin OOME from JVM will not be reported because they are instantiated at JVM init stage and are kept in `Universe`, so they cannot be handled in `ThrowableTracer::traceError`. >> We can trace OOMEs which are happened in Java code at `ThrowableTracer::traceError`. However I'm not sure where the event should be handled in. >> >> For sake of simply, I want to add `jdk.OutOfMemoryError` event to `jdk.jfr` module as a Java class, and I want to emit it from `ThrowableTracer::traceError`, however it duplicates with a definition in JVM. >> OTOH we can implement to emit event from `ThrowableTracer::traceError` via `JVM` class, however need to add API to emit events with arbitrary arguments. > > `Universe` holds some of throwable objects such as `NullPointerException`, `VirtualMachineError`. They could be lost in flight record. This problem is not only for OOME. > > So I think we need to track all `Throwable` objects in `Exceptions::_throw()` in HotSpot instead of bytecode injection. > `ThrowableTracer` has a counter to track num of throwing (`numThrowables`) which is used in `ExceptionStatisticsEvent`, so we also need to track it in HotSpot. > > I want to hear opinions about it before making changes. The right way to do this is to emit the event when the exception is thrown and I think it must happen inside the VM. One problem is that the C2 compiler can eliminate the throw if it can prove the it can't be seen. That is the reason, we ended up with the current implementation many years ago. It was complicated to implement in the VM. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From ayang at openjdk.java.net Tue Jan 12 22:19:21 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 12 Jan 2021 22:19:21 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v3] In-Reply-To: References: Message-ID: > The first commit removes some obsolete enum items, while the second commit adds the verification logic. Commit 2 introduces some "empty" task claims for the verification logic, explicitly marked in the comments. > > Test: hotspot_gc Albert Mingkun Yang 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: review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2046/files - new: https://git.openjdk.java.net/jdk/pull/2046/files/938dce1d..aa2d853c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2046&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2046&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2046.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2046/head:pull/2046 PR: https://git.openjdk.java.net/jdk/pull/2046 From dongbo at openjdk.java.net Tue Jan 12 23:54:57 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 12 Jan 2021 23:54:57 GMT Subject: RFR: 8259629: aarch64 builds fail after JDK-8258932 In-Reply-To: References: <7b3kZetb-LRNPlInkbXO6ujx9Mwsucmkm_i4YfQgq4w=.7cc4d39e-879d-40f5-ad7e-2f1081781ca5@github.com> Message-ID: <2JT9WKY7LhupnKPgY_tmMY3yU93NVHPVDPMA_nSXCt0=.94bcc08e-f374-4822-94e5-be3957184705@github.com> On Tue, 12 Jan 2021 20:11:36 GMT, Vladimir Kozlov wrote: >> It passed out whole tier1 testing I ran. So I am fine with it, >> >> But I would like to see review from someone familiar with Aaarch64 assembler too. > > After internal discussion and urgency we suggest to push this fix ASAP. > @dgbo please integrate it and I will sponsor. Thank you all so much. @vnkozlov Integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2052 From dongbo at openjdk.java.net Wed Jan 13 00:33:57 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Wed, 13 Jan 2021 00:33:57 GMT Subject: Integrated: 8259629: aarch64 builds fail after JDK-8258932 In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 16:23:56 GMT, Dong Bo wrote: > This fixes aarch64 builds failure after JDK-8258932. > It is caused by the mismatched call `fmaxp/fminp` in `AssemblerAArch64` tests to the definitions in `assembler_aarch64.hpp`. > > Verified with `gtest-1.8.1` and `make test TEST="gtest"`, `linux-aarch64-server-slowdebug`. > Both builds and tests are good, the results of `gtest` on my aarch64 server: > Finished running test 'gtest:all/server' > Test report is stored in build/linux-aarch64-server-slowdebug/test-results/gtest_all_server > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > gtest:all/server 807 807 0 0 > ============================== > TEST SUCCESS > > Finished building target 'test' in configuration 'linux-aarch64-server-slowdebug' > > The `gtest` was not configured during tests in `JDK-8258932`, so it did not execute previously. > I'm really sorry for my carelessness and producing a serious BUG. This pull request has now been integrated. Changeset: c6d798c2 Author: Dong Bo Committer: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/c6d798c2 Stats: 8 lines in 2 files changed: 3 ins; 0 del; 5 mod 8259629: aarch64 builds fail after JDK-8258932 Reviewed-by: kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/2052 From david.holmes at oracle.com Wed Jan 13 01:27:34 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Jan 2021 11:27:34 +1000 Subject: RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2] In-Reply-To: References: <2U9_AyzJPQKlEFk3rC94U85uDzE7pl1rUfsshKrwzII=.e6fff35d-7b31-468d-a31d-0b18f212ea49@github.com> <_idMfO5Oq1M0_pUK6iVBYbkm_mLjmkcJfexeBjTzad4=.0b3a1f1e-76f2-41a8-9bd3-ca0fe48dd090@github.com> Message-ID: On 12/01/2021 11:17 pm, Coleen Phillimore wrote: > On Fri, 8 Jan 2021 13:14:36 GMT, Coleen Phillimore wrote: > >>> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 195: >>> >>>> 193: >>>> 194: class ThreadInVMfromNative : public ThreadStateTransition { >>>> 195: ResetNoHandleMark __rnhm; >>> >>> We should add a constructor for RNHM that takes the current thread so that we don't have to call Thread::current() unnecessarily in the existing RNHM constructor. >> >> Ok but the ResetNoHandleMark implementation disappears in product mode, so it doesn't actually call Thread::current() in product mode. > > I forgot to push the change up to add a ResetNoHandleMark that takes a Thread* parameter. Since it evaporates in product mode, I don't think it's needed or helpful. I could add it back with https://github.com/openjdk/jdk/pull/1990 if you insist. I'd overlooked this was not-product, so it is fine. Thanks for checking. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1983 > From dholmes at openjdk.java.net Wed Jan 13 02:38:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 13 Jan 2021 02:38:55 GMT Subject: RFR: 8258912: Remove JVM options CountJNICalls and CountJVMCalls In-Reply-To: References: Message-ID: <81gaPPp6WraRTTlCaFX-zpRev1HR0u057ulvdxkwago=.f89f63cd-fbff-460c-b1bc-b6f8f3537d09@github.com> On Tue, 12 Jan 2021 15:17:52 GMT, Harold Seigel wrote: > Please review this change to remove the old non-product JVM -XX flags CountRuntimeCalls, CountJNICalls, CountJVMCalls, and CountRemovableExceptions. Additionally, this change removes non-product flag WarnOnStalledSpinLock because, as a result of this change, it is no longer used. > > The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Hi Harold, The call counters seem like useful statistics to me, though ones that may only be checked during specific types of development work. I think some consultation may be in order here rather than "take it away and see if anyone complains". At a minimum I'd like to know whether our benchmarking/optimisation experts ever utilise these when figuring out code changes - paging @cl4es and @shipilev :) Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/2050 From dholmes at openjdk.java.net Wed Jan 13 03:01:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 13 Jan 2021 03:01:56 GMT Subject: RFR: JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling [v2] In-Reply-To: References: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> Message-ID: On Tue, 12 Jan 2021 13:00:12 GMT, Matthias Baesken wrote: >> AIX 5.3 had buggy __thread support (see JDK-8176442). >> That's why we introduced a macro USE_LIBRARY_BASED_TLS_ONLY and set it only to 1 on AIX (different to the other platforms supported by the OpenJDK). >> However AIX 5.3 support was removed some time ago (currently we have a minimum requirement of AIX 7.X ) so the whole USE_LIBRARY_BASED_TLS_ONLY related coding could be removed. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling LGTM! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1976 From dholmes at openjdk.java.net Wed Jan 13 04:27:57 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 13 Jan 2021 04:27:57 GMT Subject: RFR: 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark [v3] In-Reply-To: References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: On Mon, 11 Jan 2021 16:33:12 GMT, Coleen Phillimore wrote: >> See CR for details. This is a hopefully simple cleanup. I didn't try to reason about removing any of these except an obvious call (if you look above the patch in thread.cpp). >> Tested with tier1-3. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix wrong JavaThread::active in fill_in_stack_trace. Hi Coleen, This all seems fine to me. One minor nit below. Thanks, David src/hotspot/share/utilities/preserveException.cpp line 32: > 30: > 31: PreserveExceptionMark::PreserveExceptionMark(Thread* thread) { > 32: _thread = thread; Nit: extra spaces before = now that lines are not being aligned. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2007 From stuefe at openjdk.java.net Wed Jan 13 07:04:57 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Jan 2021 07:04:57 GMT Subject: RFR: JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling [v2] In-Reply-To: References: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> Message-ID: On Tue, 12 Jan 2021 13:00:12 GMT, Matthias Baesken wrote: >> AIX 5.3 had buggy __thread support (see JDK-8176442). >> That's why we introduced a macro USE_LIBRARY_BASED_TLS_ONLY and set it only to 1 on AIX (different to the other platforms supported by the OpenJDK). >> However AIX 5.3 support was removed some time ago (currently we have a minimum requirement of AIX 7.X ) so the whole USE_LIBRARY_BASED_TLS_ONLY related coding could be removed. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1976 From shade at openjdk.java.net Wed Jan 13 07:38:55 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 07:38:55 GMT Subject: RFR: 8258912: Remove JVM options CountJNICalls and CountJVMCalls In-Reply-To: References: Message-ID: <0XHXXCg4OGqHfBY_C6O-NXUn2Dth0CQJM6FNCgw6osM=.96c19bfb-f832-430f-9121-0dad62723910@github.com> On Tue, 12 Jan 2021 15:17:52 GMT, Harold Seigel wrote: > Please review this change to remove the old non-product JVM -XX flags CountRuntimeCalls, CountJNICalls, CountJVMCalls, and CountRemovableExceptions. Additionally, this change removes non-product flag WarnOnStalledSpinLock because, as a result of this change, it is no longer used. > > The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold I never used these flags, and I don't think they are very useful. I think most of that data is supposed to be delivered by JFR these days, instead of ad-hoc profiling facilities. If there are no relevant JFR events, they could be added later. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2050 From mbaesken at openjdk.java.net Wed Jan 13 07:56:55 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 13 Jan 2021 07:56:55 GMT Subject: Integrated: JDK-8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling In-Reply-To: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> References: <9Gt5jLxmEX1NGjcWjgkk8ceEjoXsyB0JV5Up8t3x9pY=.277df7e0-37c4-4c40-a127-74f2fc04246b@github.com> Message-ID: On Thu, 7 Jan 2021 16:20:20 GMT, Matthias Baesken wrote: > AIX 5.3 had buggy __thread support (see JDK-8176442). > That's why we introduced a macro USE_LIBRARY_BASED_TLS_ONLY and set it only to 1 on AIX (different to the other platforms supported by the OpenJDK). > However AIX 5.3 support was removed some time ago (currently we have a minimum requirement of AIX 7.X ) so the whole USE_LIBRARY_BASED_TLS_ONLY related coding could be removed. This pull request has now been integrated. Changeset: 139b6dae Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/139b6dae Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod 8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1976 From rrich at openjdk.java.net Wed Jan 13 08:11:07 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 13 Jan 2021 08:11:07 GMT Subject: RFR: 8259627: Potential memory leaks in JVMTI after JDK-8227745 Message-ID: This change eliminates memory leaks in the JVMTI implementation reported by SonarCloud. The leaks occur when the Java heap is exhausted. ------------- Commit messages: - 8259627: Potential memory leaks in JVMTI after JDK-8227745 Changes: https://git.openjdk.java.net/jdk/pull/2055/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2055&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259627 Stats: 16 lines in 1 file changed: 8 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2055.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2055/head:pull/2055 PR: https://git.openjdk.java.net/jdk/pull/2055 From shade at openjdk.java.net Wed Jan 13 08:23:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 08:23:00 GMT Subject: RFR: 8259627: Potential memory leaks in JVMTI after JDK-8227745 In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 19:09:43 GMT, Richard Reingruber wrote: > This change eliminates memory leaks in the JVMTI implementation reported by SonarCloud. > > The leaks occur when the Java heap is exhausted. This looks good to me, thanks! ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2055 From shade at openjdk.java.net Wed Jan 13 08:31:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 08:31:59 GMT Subject: RFR: 8259627: Potential memory leaks in JVMTI after JDK-8227745 In-Reply-To: References: Message-ID: <7sK2TyJpFTgpfT5WlHgpovv8YzbO51ZeZWuM-Sdk3Wk=.9434f0fd-c170-47f6-a620-ed3ec10e1829@github.com> On Wed, 13 Jan 2021 08:19:59 GMT, Aleksey Shipilev wrote: >> This change eliminates memory leaks in the JVMTI implementation reported by SonarCloud. >> >> The leaks occur when the Java heap is exhausted. > > This looks good to me, thanks! > @shipilev thanks for doing the analysis and reporting the issues. I found 2 leaks. Do you see more that could be related to JDK-8227745 ([40f847e](https://github.com/openjdk/jdk/commit/40f847e2))? > > I wanted to do a SonarCloud scan myself but was uncertain about the requested permissions, me using the service for work, etc. Would it be possible to publish the SC report? I think those are only two instances. I am only aware of [this one](https://sonarcloud.io/project/issues?fileUuids=AXaE0amt8L9hkQskFrwX&id=jdk&resolved=false&types=BUG). I meant to set up my own some time later. ------------- PR: https://git.openjdk.java.net/jdk/pull/2055 From rrich at openjdk.java.net Wed Jan 13 08:31:58 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 13 Jan 2021 08:31:58 GMT Subject: RFR: 8259627: Potential memory leaks in JVMTI after JDK-8227745 In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 08:19:59 GMT, Aleksey Shipilev wrote: >> This change eliminates memory leaks in the JVMTI implementation reported by SonarCloud. >> >> The leaks occur when the Java heap is exhausted. > > This looks good to me, thanks! @shipilev thanks for doing the analysis and reporting the issues. I found 2 leaks. Do you see more that could be related to JDK-8227745 (https://github.com/openjdk/jdk/commit/40f847e2)? I wanted to do a SonarCloud scan myself but was uncertain about the requested permissions, me using the service for work, etc. Would it be possible to publish the SC report? ------------- PR: https://git.openjdk.java.net/jdk/pull/2055 From kbarrett at openjdk.java.net Wed Jan 13 08:40:59 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 13 Jan 2021 08:40:59 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v3] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 22:19:21 GMT, Albert Mingkun Yang wrote: >> The first commit removes some obsolete enum items, while the second commit adds the verification logic. Commit 2 introduces some "empty" task claims for the verification logic, explicitly marked in the comments. >> >> Test: hotspot_gc > > Albert Mingkun Yang 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. Changes requested by kbarrett (Reviewer). src/hotspot/share/gc/shared/workgroup.cpp line 384: > 382: } > 383: assert(is_skipped, "%d not claimed.", i); > 384: } Can also do a separate loop over `skipped` to verify `_tasks[skipped[i]] == 0` (with appropriate bounds checking). src/hotspot/share/gc/shared/workgroup.hpp line 336: > 334: // > 335: // n_threads - Number of threads executing the sub-tasks. > 336: // followed by vararg skipped tasks The description comment should be augmented to describe the optional skipped values. src/hotspot/share/gc/g1/g1RootProcessor.cpp line 109: > 107: // refProcessor is not needed since we are inside a safe point > 108: _process_strong_tasks.all_tasks_completed(n_workers(), > 109: G1RP_PS_CodeCache_oops_do, G1RP_PS_refProcessor_oops_do); When parameters or arguments are on multiple lines, we usually align all the arguments, and usually one per line. There are some other similar cases elsewhere in this change that I didn't redundantly comment. src/hotspot/share/gc/shared/workgroup.hpp line 29: > 27: > 28: #include "memory/allocation.hpp" > 29: #include "metaprogramming/logical.hpp" Should also add metaprogramming/enableIf.hpp, to avoid implicit include dependency. ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From stuefe at openjdk.java.net Wed Jan 13 08:45:58 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Jan 2021 08:45:58 GMT Subject: RFR: 8259627: Potential memory leaks in JVMTI after JDK-8227745 In-Reply-To: References: Message-ID: <8BAWm_k5dK1IBjWQ5hzJkSHF1sVg6NiOeUFur1xU3Vg=.aeb8728b-c79e-4e2b-8ada-028ee77a6977@github.com> On Tue, 12 Jan 2021 19:09:43 GMT, Richard Reingruber wrote: > This change eliminates memory leaks in the JVMTI implementation reported by SonarCloud. > > The leaks occur when the Java heap is exhausted. Looks good. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2055 From shade at openjdk.java.net Wed Jan 13 08:51:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 08:51:56 GMT Subject: [jdk16] Integrated: 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049 In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 13:07:41 GMT, Aleksey Shipilev wrote: > Debian folks report that Zero m68k (and seems only that arch) fails the static assert added by JDK-8252049. It affects at least JDK 16, but would affect more releases once JDK-8252049 is backported. > > /<>/src/hotspot/share/oops/methodData.hpp: In constructor 'MethodData::CompilerCounters::CompilerCounters()': > /<>/src/hotspot/share/oops/methodData.hpp:1987:55: error: static assertion failed: align > 1987 | static_assert(sizeof(_trap_hist) % HeapWordSize == 0, "align"); > | > > I tried to massage the code so that `oops/methodData.hpp` is not touched when Zero is built (since Zero does not use compilers and related infra), but there are enough transitive dependencies to `oops/methodData.hpp` to make it quite messy. So instead I would just special-case it in place. This pull request has now been integrated. Changeset: a99df45b Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16/commit/a99df45b Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049 Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk16/pull/102 From rrich at openjdk.java.net Wed Jan 13 08:49:55 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 13 Jan 2021 08:49:55 GMT Subject: RFR: 8259627: Potential memory leaks in JVMTI after JDK-8227745 In-Reply-To: <8BAWm_k5dK1IBjWQ5hzJkSHF1sVg6NiOeUFur1xU3Vg=.aeb8728b-c79e-4e2b-8ada-028ee77a6977@github.com> References: <8BAWm_k5dK1IBjWQ5hzJkSHF1sVg6NiOeUFur1xU3Vg=.aeb8728b-c79e-4e2b-8ada-028ee77a6977@github.com> Message-ID: <07VI4FfQhhLRUdHW8pTCzEcOABNrRR6HHsSW-TxohN8=.57d77815-1db0-48fd-9aed-93d411bb7a5d@github.com> On Wed, 13 Jan 2021 08:42:59 GMT, Thomas Stuefe wrote: >> This change eliminates memory leaks in the JVMTI implementation reported by SonarCloud. >> >> The leaks occur when the Java heap is exhausted. > > Looks good. > > > > @shipilev thanks for doing the analysis and reporting the issues. I found 2 leaks. Do you see more that could be related to JDK-8227745 ([40f847e](https://github.com/openjdk/jdk/commit/40f847e2))? > > I wanted to do a SonarCloud scan myself but was uncertain about the requested permissions, me using the service for work, etc. Would it be possible to publish the SC report? > > I think those are only two instances. I am only aware of [this one](https://sonarcloud.io/project/issues?fileUuids=AXaE0amt8L9hkQskFrwX&id=jdk&resolved=false&types=BUG). I meant to set up my own some time later. Excellent! I googled for public scans but failed. Now I see that scans are listed on the "Explore" page of SonarCloud. Cool the tool found the leaks! Thanks for the review also. > > > Looks good. Thanks for looking! ------------- PR: https://git.openjdk.java.net/jdk/pull/2055 From dholmes at openjdk.java.net Wed Jan 13 09:02:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 13 Jan 2021 09:02:56 GMT Subject: RFR: 8259627: Potential memory leaks in JVMTI after JDK-8227745 In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 19:09:43 GMT, Richard Reingruber wrote: > This change eliminates memory leaks in the JVMTI implementation reported by SonarCloud. > > The leaks occur when the Java heap is exhausted. Looks good! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2055 From sspitsyn at openjdk.java.net Wed Jan 13 09:11:58 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 13 Jan 2021 09:11:58 GMT Subject: RFR: 8259627: Potential memory leaks in JVMTI after JDK-8227745 In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 19:09:43 GMT, Richard Reingruber wrote: > This change eliminates memory leaks in the JVMTI implementation reported by SonarCloud. > > The leaks occur when the Java heap is exhausted. Hi Richard, LGTM++ Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2055 From ayang at openjdk.java.net Wed Jan 13 09:11:59 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 13 Jan 2021 09:11:59 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v3] In-Reply-To: References: Message-ID: <705T3CG8S9Wo9-CGBRAKXwjWOzp33r0VRlCsajnm9B8=.b9335e75-7827-4284-bcbb-382b28301604@github.com> On Wed, 13 Jan 2021 08:37:24 GMT, Kim Barrett wrote: >> Albert Mingkun Yang 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. > > src/hotspot/share/gc/shared/workgroup.hpp line 29: > >> 27: >> 28: #include "memory/allocation.hpp" >> 29: #include "metaprogramming/logical.hpp" > > Should also add metaprogramming/enableIf.hpp, to avoid implicit include dependency. Should I include both `enableIf.hpp` and `logical.hpp`, or only `enableIf.hpp` since it includes `logical.hpp` already? ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From rrich at openjdk.java.net Wed Jan 13 09:14:56 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 13 Jan 2021 09:14:56 GMT Subject: RFR: 8259627: Potential memory leaks in JVMTI after JDK-8227745 In-Reply-To: References: Message-ID: <9YjpboRz7_lqQZSzRtG2-KBpSvTbQf8zkDv2e7cPBTc=.cf7810ba-8116-4732-a78e-f92df30c7a37@github.com> On Wed, 13 Jan 2021 09:09:37 GMT, Serguei Spitsyn wrote: >> This change eliminates memory leaks in the JVMTI implementation reported by SonarCloud. >> >> The leaks occur when the Java heap is exhausted. > > Hi Richard, > LGTM++ > Thanks, > Serguei Thanks for the reviews David and Serguei. ------------- PR: https://git.openjdk.java.net/jdk/pull/2055 From kbarrett at openjdk.java.net Wed Jan 13 09:21:57 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 13 Jan 2021 09:21:57 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v3] In-Reply-To: <705T3CG8S9Wo9-CGBRAKXwjWOzp33r0VRlCsajnm9B8=.b9335e75-7827-4284-bcbb-382b28301604@github.com> References: <705T3CG8S9Wo9-CGBRAKXwjWOzp33r0VRlCsajnm9B8=.b9335e75-7827-4284-bcbb-382b28301604@github.com> Message-ID: On Wed, 13 Jan 2021 09:09:25 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/shared/workgroup.hpp line 29: >> >>> 27: >>> 28: #include "memory/allocation.hpp" >>> 29: #include "metaprogramming/logical.hpp" >> >> Should also add metaprogramming/enableIf.hpp, to avoid implicit include dependency. > > Should I include both `enableIf.hpp` and `logical.hpp`, or only `enableIf.hpp` since it includes `logical.hpp` already? We don't have any tooling support, but there has been a trend away from relying on implicit includes, because they lead to breakages far away from refactorings that change includes. ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From ayang at openjdk.java.net Wed Jan 13 10:20:12 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 13 Jan 2021 10:20:12 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v3] In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 08:38:25 GMT, Kim Barrett wrote: >> Albert Mingkun Yang 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. > > Changes requested by kbarrett (Reviewer). Addressed all suggestions in the revision. ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From ayang at openjdk.java.net Wed Jan 13 10:20:12 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 13 Jan 2021 10:20:12 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v4] In-Reply-To: References: Message-ID: > The first commit removes some obsolete enum items, while the second commit adds the verification logic. Commit 2 introduces some "empty" task claims for the verification logic, explicitly marked in the comments. > > Test: hotspot_gc Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2046/files - new: https://git.openjdk.java.net/jdk/pull/2046/files/aa2d853c..4d147817 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2046&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2046&range=02-03 Stats: 21 lines in 3 files changed: 12 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2046.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2046/head:pull/2046 PR: https://git.openjdk.java.net/jdk/pull/2046 From ayang at openjdk.java.net Wed Jan 13 10:20:13 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 13 Jan 2021 10:20:13 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v3] In-Reply-To: References: <705T3CG8S9Wo9-CGBRAKXwjWOzp33r0VRlCsajnm9B8=.b9335e75-7827-4284-bcbb-382b28301604@github.com> Message-ID: On Wed, 13 Jan 2021 09:19:17 GMT, Kim Barrett wrote: >> Should I include both `enableIf.hpp` and `logical.hpp`, or only `enableIf.hpp` since it includes `logical.hpp` already? > > We don't have any tooling support, but there has been a trend away from relying on implicit includes, because they lead to breakages far away from refactorings that change includes. Got it; including both then. ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From kbarrett at openjdk.java.net Wed Jan 13 10:35:00 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 13 Jan 2021 10:35:00 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v4] In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 10:20:12 GMT, Albert Mingkun Yang wrote: >> The first commit removes some obsolete enum items, while the second commit adds the verification logic. Commit 2 introduces some "empty" task claims for the verification logic, explicitly marked in the comments. >> >> Test: hotspot_gc > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by kbarrett (Reviewer). src/hotspot/share/gc/shared/workgroup.hpp line 331: > 329: > 330: // The calling thread asserts that it has attempted to claim all the tasks > 331: // that it will try to claim. Tasks that is meant to be skipped must be s/is meant/are meant/ src/hotspot/share/gc/shared/workgroup.hpp line 332: > 330: // The calling thread asserts that it has attempted to claim all the tasks > 331: // that it will try to claim. Tasks that is meant to be skipped must be > 332: // explicitly passed as extra arguments using the variadic version below. I would drop "using the variadic version below". I think of this as a function that takes some optional "these are expected to be skipped" task designators, and the non-variadic overload is just an implementation detail to handle the base case of there being none of those. ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From ysuenaga at openjdk.java.net Wed Jan 13 11:10:22 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 13 Jan 2021 11:10:22 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError [v2] In-Reply-To: References: Message-ID: > OOM on Metaspace would be reported in `MetaspaceOOM` JFR event, however other OOM (e.g. Java heap) would not be reported. > > It is useful if JFR reports OOMs. 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: - Move JavaErrorThrow and JavaExceptionThrow into HotSpot - Merge remote-tracking branch 'upstream/master' into JDK-8256916 - 8256916: Add JFR event for OutOfMemoryError ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1403/files - new: https://git.openjdk.java.net/jdk/pull/1403/files/8f8799d6..7601b2f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1403&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1403&range=00-01 Stats: 122944 lines in 3018 files changed: 71590 ins; 25940 del; 25414 mod Patch: https://git.openjdk.java.net/jdk/pull/1403.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1403/head:pull/1403 PR: https://git.openjdk.java.net/jdk/pull/1403 From ayang at openjdk.java.net Wed Jan 13 11:19:12 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 13 Jan 2021 11:19:12 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v5] In-Reply-To: References: Message-ID: > The first commit removes some obsolete enum items, while the second commit adds the verification logic. Commit 2 introduces some "empty" task claims for the verification logic, explicitly marked in the comments. > > Test: hotspot_gc Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2046/files - new: https://git.openjdk.java.net/jdk/pull/2046/files/4d147817..15892bd4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2046&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2046&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2046.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2046/head:pull/2046 PR: https://git.openjdk.java.net/jdk/pull/2046 From ayang at openjdk.java.net Wed Jan 13 11:19:12 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 13 Jan 2021 11:19:12 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v4] In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 10:32:12 GMT, Kim Barrett wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > Marked as reviewed by kbarrett (Reviewer). Addressed suggestions on the comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From stefank at openjdk.java.net Wed Jan 13 12:51:07 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 13 Jan 2021 12:51:07 GMT Subject: RFR: 8256955: Move includes of events.hpp out of header files Message-ID: I was making changes to events.hpp and saw that the majority of cpp files were recompiled. There are two header files that include events.hpp. I propose that we remove those usages by: jvmci.hpp: Use a forward declaration collectedHeap.hpp: Move its usage to the cpp file events.hpp also includes thread.hpp, which brings in a large portion of the HotSpot headers. So, this change is also good in that regard. ------------- Commit messages: - 8256955: Move includes of events.hpp out of header files Changes: https://git.openjdk.java.net/jdk/pull/2059/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2059&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256955 Stats: 58 lines in 7 files changed: 31 ins; 27 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2059.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2059/head:pull/2059 PR: https://git.openjdk.java.net/jdk/pull/2059 From kbarrett at openjdk.java.net Wed Jan 13 13:18:02 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 13 Jan 2021 13:18:02 GMT Subject: RFR: 8256955: Move includes of events.hpp out of header files In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 09:51:12 GMT, Stefan Karlsson wrote: > I was making changes to events.hpp and saw that the majority of cpp files were recompiled. There are two header files that include events.hpp. I propose that we remove those usages by: > > jvmci.hpp: Use a forward declaration > collectedHeap.hpp: Move its usage to the cpp file > > events.hpp also includes thread.hpp, which brings in a large portion of the HotSpot headers. So, this change is also good in that regard. Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2059 From ysuenaga at openjdk.java.net Wed Jan 13 14:16:02 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 13 Jan 2021 14:16:02 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> Message-ID: <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> On Tue, 12 Jan 2021 21:45:32 GMT, Erik Gahlin wrote: > The right way to do this is to emit the event when the exception is thrown and I think it must happen inside the VM. I updated PR. Could you review? Windows build on GitHub Actions failed, but it is not caused by this PR (due to configure error). I removed bytecode injection to hook c'tor of `Error` and `Exception`. JavaErrorThrown and JavaExceptionThrown would be thrown from HotSpot. And also number of thrown is counted at HotSpot, so I added new JNI function to get it, it is used for ExceptionStatistics event. > One problem is that the C2 compiler can eliminate the throw if it can prove the it can't be seen. That is the reason, we ended up with the current implementation many years ago. It was complicated to implement in the VM. I added a function call which emits JavaErrorThrown and/or JavaExceptionThrown around `Exceptions::log_exception()` call. It is not completely solution for your concern, but we can hook most of throwable objects like unified logging. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From coleenp at openjdk.java.net Wed Jan 13 14:22:04 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 14:22:04 GMT Subject: RFR: 8256955: Move includes of events.hpp out of header files In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 09:51:12 GMT, Stefan Karlsson wrote: > I was making changes to events.hpp and saw that the majority of cpp files were recompiled. There are two header files that include events.hpp. I propose that we remove those usages by: > > jvmci.hpp: Use a forward declaration > collectedHeap.hpp: Move its usage to the cpp file > > events.hpp also includes thread.hpp, which brings in a large portion of the HotSpot headers. So, this change is also good in that regard. Nice! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2059 From coleenp at openjdk.java.net Wed Jan 13 14:22:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 14:22:05 GMT Subject: RFR: 8256955: Move includes of events.hpp out of header files In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 14:18:57 GMT, Coleen Phillimore wrote: >> I was making changes to events.hpp and saw that the majority of cpp files were recompiled. There are two header files that include events.hpp. I propose that we remove those usages by: >> >> jvmci.hpp: Use a forward declaration >> collectedHeap.hpp: Move its usage to the cpp file >> >> events.hpp also includes thread.hpp, which brings in a large portion of the HotSpot headers. So, this change is also good in that regard. > > Nice! I should have asked if you were able to build shenandoah and zero with this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/2059 From coleenp at openjdk.java.net Wed Jan 13 14:32:21 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 14:32:21 GMT Subject: RFR: 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark [v4] In-Reply-To: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: > See CR for details. This is a hopefully simple cleanup. I didn't try to reason about removing any of these except an obvious call (if you look above the patch in thread.cpp). > Tested with tier1-3. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: fix space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2007/files - new: https://git.openjdk.java.net/jdk/pull/2007/files/7f4427c4..2c008402 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2007&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2007&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2007.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2007/head:pull/2007 PR: https://git.openjdk.java.net/jdk/pull/2007 From ysuenaga at openjdk.java.net Wed Jan 13 14:29:02 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 13 Jan 2021 14:29:02 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> Message-ID: On Wed, 13 Jan 2021 14:13:30 GMT, Yasumasa Suenaga wrote: >> The right way to do this is to emit the event when the exception is thrown and I think it must happen inside the VM. >> >> One problem is that the C2 compiler can eliminate the throw if it can prove the it can't be seen. That is the reason, we ended up with the current implementation many years ago. It was complicated to implement in the VM. > >> The right way to do this is to emit the event when the exception is thrown and I think it must happen inside the VM. > > I updated PR. Could you review? > Windows build on GitHub Actions failed, but it is not caused by this PR (due to configure error). > > I removed bytecode injection to hook c'tor of `Error` and `Exception`. JavaErrorThrown and JavaExceptionThrown would be thrown from HotSpot. And also number of thrown is counted at HotSpot, so I added new JNI function to get it, it is used for ExceptionStatistics event. > >> One problem is that the C2 compiler can eliminate the throw if it can prove the it can't be seen. That is the reason, we ended up with the current implementation many years ago. It was complicated to implement in the VM. > > I added a function call which emits JavaErrorThrown and/or JavaExceptionThrown around `Exceptions::log_exception()` call. It is not completely solution for your concern, but we can hook most of throwable objects like unified logging. This PR passed all tests in jdk/jfr on Linux x64. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From coleenp at openjdk.java.net Wed Jan 13 14:37:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 14:37:07 GMT Subject: RFR: 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark [v3] In-Reply-To: References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: On Wed, 13 Jan 2021 04:25:33 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix wrong JavaThread::active in fill_in_stack_trace. > > Hi Coleen, > > This all seems fine to me. One minor nit below. > > Thanks, > David Thanks David - thank you for asking about JavaThread::active so we could find this bug. > src/hotspot/share/utilities/preserveException.cpp line 32: > >> 30: >> 31: PreserveExceptionMark::PreserveExceptionMark(Thread* thread) { >> 32: _thread = thread; > > Nit: extra spaces before = now that lines are not being aligned. fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2007 From coleenp at openjdk.java.net Wed Jan 13 14:37:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 14:37:07 GMT Subject: Integrated: 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark In-Reply-To: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> References: <5LhyzyRjSeaXYT8K7j5jz5R16nx0-NNxkA6fkUWWnXk=.2a309eec-31f3-4665-84c4-4b6b40c2a628@github.com> Message-ID: On Fri, 8 Jan 2021 16:58:15 GMT, Coleen Phillimore wrote: > See CR for details. This is a hopefully simple cleanup. I didn't try to reason about removing any of these except an obvious call (if you look above the patch in thread.cpp). > Tested with tier1-3. This pull request has now been integrated. Changeset: 535f2da5 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/535f2da5 Stats: 104 lines in 14 files changed: 7 ins; 56 del; 41 mod 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark Reviewed-by: dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/2007 From coleenp at openjdk.java.net Wed Jan 13 14:42:27 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 14:42:27 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions [v2] In-Reply-To: References: Message-ID: > Please review the smaller version of this enhancement. JRT_LEAF can allow Handles. Fixed places where a ResetNoHandleMark was added to workaround the restriction and remove some obsolete comments in deoptimization (the function is a JRT_BLOCK_ENTRY that has a HandleMarkCleaner which cleans up the HandleMark to the one before call_stub() in JavaCalls. A HandleMarkCleaner also allows HandleMark and Handles. > > Tested with tier1-3, 4-6 with the larger change and 7-8 in progress. Coleen Phillimore 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 six additional commits since the last revision: - Revert zVerify and stackWaterMark changes. They need a RNHM. - Remove ResetNoHandleMark after ThreadInVMfromNative. - Merge branch 'master' into leaf2 - Merge branch 'master' into leaf2 - Remove slow_identity_hash ResetNoHandleMark - 8258032: Reconsider LEAF entry restrictions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1990/files - new: https://git.openjdk.java.net/jdk/pull/1990/files/85c89b61..4e66f0ac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1990&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1990&range=00-01 Stats: 21319 lines in 663 files changed: 10586 ins; 7128 del; 3605 mod Patch: https://git.openjdk.java.net/jdk/pull/1990.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1990/head:pull/1990 PR: https://git.openjdk.java.net/jdk/pull/1990 From coleenp at openjdk.java.net Wed Jan 13 15:27:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 15:27:05 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 13:54:11 GMT, Coleen Phillimore wrote: >> JRT_LEAF still has a NoSafepointVerifier if that helps. There's a comment about the things it's not allowed to do in interfaceSupport.inline.hpp. The things it's not supposed to do are all checked by the NSV. >> One of the things it can do now (especially if it's not going to safepoint) is to have a Handle with an enclosing HandleMark because GC won't touch the oops anyway. This is one of the things @pron ran into with loom (see issue) and @fisk and I discussed. >> I originally took the bug because I was going to close it as WNF, because I hate removing restrictions. >> I do think there is a bug lurking here. If you have a Handle without an enclosing HandleMark in JRT_LEAF, it will not be cleaned up when the leaf function returns. This might need a HandleMarkCleaner. > > I do not see fetch_unroll_info_helper reverting back to JRT_LEAF. I am closing this as WNF. There are too many problems that you can get into if you're not careful. I opened a new issue to fix the wrong comments in deoptimization.cpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/1990 From coleenp at openjdk.java.net Wed Jan 13 15:27:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 15:27:06 GMT Subject: Withdrawn: 8258032: Reconsider LEAF entry restrictions In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 20:57:00 GMT, Coleen Phillimore wrote: > Please review the smaller version of this enhancement. JRT_LEAF can allow Handles. Fixed places where a ResetNoHandleMark was added to workaround the restriction and remove some obsolete comments in deoptimization (the function is a JRT_BLOCK_ENTRY that has a HandleMarkCleaner which cleans up the HandleMark to the one before call_stub() in JavaCalls. A HandleMarkCleaner also allows HandleMark and Handles. > > Tested with tier1-3, 4-6 with the larger change and 7-8 in progress. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1990 From coleenp at openjdk.java.net Wed Jan 13 21:17:15 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 21:17:15 GMT Subject: RFR: 8259713: Fix comments and ResetNoHandleMark in deoptimization Message-ID: This is a small part of the withdrawn change for https://github.com/openjdk/jdk/pull/1990 to fix the out-of-date comments in deoptimization.cpp. Tested with tier1-3. ------------- Commit messages: - 8259713: Fix comments and ResetNoHandleMark in deoptimization Changes: https://git.openjdk.java.net/jdk/pull/2069/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2069&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259713 Stats: 11 lines in 1 file changed: 2 ins; 5 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2069.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2069/head:pull/2069 PR: https://git.openjdk.java.net/jdk/pull/2069 From lfoltan at openjdk.java.net Wed Jan 13 21:39:00 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 13 Jan 2021 21:39:00 GMT Subject: RFR: 8259713: Fix comments and ResetNoHandleMark in deoptimization In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:12:34 GMT, Coleen Phillimore wrote: > This is a small part of the withdrawn change for https://github.com/openjdk/jdk/pull/1990 to fix the out-of-date comments in deoptimization.cpp. > Tested with tier1-3. LGTM. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2069 From coleenp at openjdk.java.net Wed Jan 13 21:43:03 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 21:43:03 GMT Subject: RFR: 8259713: Fix comments and ResetNoHandleMark in deoptimization In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:36:24 GMT, Lois Foltan wrote: >> This is a small part of the withdrawn change for https://github.com/openjdk/jdk/pull/1990 to fix the out-of-date comments in deoptimization.cpp. >> Tested with tier1-3. > > LGTM. > Lois Thanks Lois! ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From dcubed at openjdk.java.net Wed Jan 13 21:47:05 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 13 Jan 2021 21:47:05 GMT Subject: RFR: 8259713: Fix comments and ResetNoHandleMark in deoptimization In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:12:34 GMT, Coleen Phillimore wrote: > This is a small part of the withdrawn change for https://github.com/openjdk/jdk/pull/1990 to fix the out-of-date comments in deoptimization.cpp. > Tested with tier1-3. Changes requested by dcubed (Reviewer). src/hotspot/share/runtime/deoptimization.cpp line 692: > 690: // Beware though because allocating Handles must have a HandleMark or else the > 691: // Handles will be leaked. > 692: ResetNoHandleMark rnhm; So I'm confused. The bug description says: > the ResetNoHandleMark is unneeded but it is still here. src/hotspot/share/runtime/deoptimization.cpp line 691: > 689: // do in debug mode to get around the NoHandleMark code in the JRT_LEAF macro > 690: // Beware though because allocating Handles must have a HandleMark or else the > 691: // Handles will be leaked. This comment is confusing because there is HandleMark on L693. ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From coleenp at openjdk.java.net Wed Jan 13 22:24:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 22:24:06 GMT Subject: RFR: 8259713: Fix comments and ResetNoHandleMark in deoptimization In-Reply-To: References: Message-ID: <2xRWn0XjRSG6Asre1GikF8rozSOF_qZZyE-g_XkIsq0=.e3462304-3900-4e64-aba9-299c98ec9afc@github.com> On Wed, 13 Jan 2021 21:43:40 GMT, Daniel D. Daugherty wrote: >> This is a small part of the withdrawn change for https://github.com/openjdk/jdk/pull/1990 to fix the out-of-date comments in deoptimization.cpp. >> Tested with tier1-3. > > src/hotspot/share/runtime/deoptimization.cpp line 691: > >> 689: // do in debug mode to get around the NoHandleMark code in the JRT_LEAF macro >> 690: // Beware though because allocating Handles must have a HandleMark or else the >> 691: // Handles will be leaked. > > This comment is confusing because there is HandleMark on L693. My point of this comment is that you should make sure you have a HandleMark if you've used ResetNoHandleMark in JRT_LEAF. > src/hotspot/share/runtime/deoptimization.cpp line 692: > >> 690: // Beware though because allocating Handles must have a HandleMark or else the >> 691: // Handles will be leaked. >> 692: ResetNoHandleMark rnhm; > > So I'm confused. The bug description says: > >> the ResetNoHandleMark is unneeded > > but it is still here. This one is needed because it's in a JRT_LEAF. The one above in the JRT_BLOCK_ENTRY is unneeded (along with the comment that matched the one in this unpack_frames() function.) ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From cjplummer at openjdk.java.net Wed Jan 13 22:41:05 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 13 Jan 2021 22:41:05 GMT Subject: RFR: 8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping In-Reply-To: References: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> Message-ID: On Thu, 7 Jan 2021 22:32:50 GMT, Chris Plummer wrote: >> This works but I'm concerned if this sets a precedent for adding expensive assertions? Do we already have similar flags? > >> This works but I'm concerned if this sets a precedent for adding expensive assertions? Do we already have similar flags? > > @dholmes-ora The one expensive assert is already there. I have since removed the two additional expensive asserts for the incr() and decr() APIs. I don't know of any other similar flag. Ping! Still need 2 reviews for this one too. ------------- PR: https://git.openjdk.java.net/jdk/pull/1835 From dcubed at openjdk.java.net Wed Jan 13 22:45:01 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 13 Jan 2021 22:45:01 GMT Subject: RFR: 8259713: Fix comments and ResetNoHandleMark in deoptimization In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:44:07 GMT, Daniel D. Daugherty wrote: >> This is a small part of the withdrawn change for https://github.com/openjdk/jdk/pull/1990 to fix the out-of-date comments in deoptimization.cpp. >> Tested with tier1-3. > > Changes requested by dcubed (Reviewer). The comment in the bug says this: > The comments are wrong and the ResetNoHandleMark is unneeded > since Deoptimization::fetch_unroll_info is a JRT_BLOCK_ENTRY (has a HandleMarkCleaner). so I read this as you are changing Deoptimization::fetch_unroll_info to: - fix a comment - remove a ResetNoHandleMark The comment in the bug doesn't mention JRT_LEAF at all, but you're making comment changes there also. No where in this fix do I see a ResetNoHandleMark being removed. Is the reason for my confusion more clear yet? ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From coleenp at openjdk.java.net Wed Jan 13 22:49:04 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 22:49:04 GMT Subject: RFR: 8259713: Fix comments and ResetNoHandleMark in deoptimization In-Reply-To: <2xRWn0XjRSG6Asre1GikF8rozSOF_qZZyE-g_XkIsq0=.e3462304-3900-4e64-aba9-299c98ec9afc@github.com> References: <2xRWn0XjRSG6Asre1GikF8rozSOF_qZZyE-g_XkIsq0=.e3462304-3900-4e64-aba9-299c98ec9afc@github.com> Message-ID: On Wed, 13 Jan 2021 22:21:23 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 692: >> >>> 690: // Beware though because allocating Handles must have a HandleMark or else the >>> 691: // Handles will be leaked. >>> 692: ResetNoHandleMark rnhm; >> >> So I'm confused. The bug description says: >> >>> the ResetNoHandleMark is unneeded >> >> but it is still here. > > This one is needed because it's in a JRT_LEAF. The one above in the JRT_BLOCK_ENTRY is unneeded (along with the comment that matched the one in this unpack_frames() function.) Correction, I didn't remove a ResetNoHandleMark in fetch_unroll_info, because there wasn't one there. It was removed already. I just removed the comment that described the code that isn't there anymore. ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From sspitsyn at openjdk.java.net Wed Jan 13 23:17:02 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 13 Jan 2021 23:17:02 GMT Subject: RFR: 8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping In-Reply-To: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> References: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> Message-ID: On Fri, 18 Dec 2020 02:01:28 GMT, Chris Plummer wrote: > There is an assert in `JvmtiThreadState::cur_stack_depth()` that tends to slow down single stepping a lot when running the debuggee with a debug jvm. See CR for details. The fix is to allow disabling of this assert using the new EnableJVMTIStackDepthAsserts global, which defaults to true. LGTM Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1835 From coleenp at openjdk.java.net Wed Jan 13 23:35:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Jan 2021 23:35:10 GMT Subject: RFR: 8259068: Streamline class loader locking Message-ID: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. Tested with tier1-8. ------------- Commit messages: - Streamline class loader locking. Changes: https://git.openjdk.java.net/jdk/pull/2071/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2071&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259068 Stats: 103 lines in 6 files changed: 10 ins; 55 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/2071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2071/head:pull/2071 PR: https://git.openjdk.java.net/jdk/pull/2071 From david.holmes at oracle.com Wed Jan 13 23:42:20 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Jan 2021 09:42:20 +1000 Subject: RFR: 8258912: Remove JVM options CountJNICalls and CountJVMCalls In-Reply-To: <81gaPPp6WraRTTlCaFX-zpRev1HR0u057ulvdxkwago=.f89f63cd-fbff-460c-b1bc-b6f8f3537d09@github.com> References: <81gaPPp6WraRTTlCaFX-zpRev1HR0u057ulvdxkwago=.f89f63cd-fbff-460c-b1bc-b6f8f3537d09@github.com> Message-ID: On 13/01/2021 12:38 pm, David Holmes wrote: > On Tue, 12 Jan 2021 15:17:52 GMT, Harold Seigel wrote: > >> Please review this change to remove the old non-product JVM -XX flags CountRuntimeCalls, CountJNICalls, CountJVMCalls, and CountRemovableExceptions. Additionally, this change removes non-product flag WarnOnStalledSpinLock because, as a result of this change, it is no longer used. >> >> The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Hi Harold, > > The call counters seem like useful statistics to me, though ones that may only be checked during specific types of development work. I think some consultation may be in order here rather than "take it away and see if anyone complains". > > At a minimum I'd like to know whether our benchmarking/optimisation experts ever utilise these when figuring out code changes - paging @cl4es and @shipilev :) Seems Claes and Alexey are okay with removing these. I don't know who else may use them. If it turns out to be an issue we can revert, but there are probably better means of profiling (though this one is simple and lightweight). Thanks, David > Thanks, > David > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2050 > From dholmes at openjdk.java.net Wed Jan 13 23:43:01 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 13 Jan 2021 23:43:01 GMT Subject: RFR: 8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping In-Reply-To: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> References: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> Message-ID: On Fri, 18 Dec 2020 02:01:28 GMT, Chris Plummer wrote: > There is an assert in `JvmtiThreadState::cur_stack_depth()` that tends to slow down single stepping a lot when running the debuggee with a debug jvm. See CR for details. The fix is to allow disabling of this assert using the new EnableJVMTIStackDepthAsserts global, which defaults to true. LGTM. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1835 From jwilhelm at openjdk.java.net Thu Jan 14 01:25:23 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 14 Jan 2021 01:25:23 GMT Subject: RFR: Merge jdk16 Message-ID: <-aqBh7X3owjZhc7NJ9IadTg_pDoBEcSVULP6D9ZQlwc=.2f9552f6-95ee-4bdd-8591-e2fea0f2ee47@github.com> Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8259719: ProblemList runtime/cds/appcds/jigsaw/modulepath/ModulePathAndCP_JFR.java on Windows - 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows - 8259722: ProblemList two jdk/jfr/startupargs tests on Windows - 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference - 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading - 8259657: typo in generated HELP page prevents localization - 8258272: LoadVectorMaskedNode can't be replaced by zero con - 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049 - 8258985: Parallel WeakProcessor may use too few threads - ... and 11 more: https://git.openjdk.java.net/jdk/compare/c7e2174b...64cae854 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2072&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2072&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2072/files Stats: 991 lines in 48 files changed: 764 ins; 123 del; 104 mod Patch: https://git.openjdk.java.net/jdk/pull/2072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2072/head:pull/2072 PR: https://git.openjdk.java.net/jdk/pull/2072 From jwilhelm at openjdk.java.net Thu Jan 14 01:33:06 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 14 Jan 2021 01:33:06 GMT Subject: Integrated: Merge jdk16 In-Reply-To: <-aqBh7X3owjZhc7NJ9IadTg_pDoBEcSVULP6D9ZQlwc=.2f9552f6-95ee-4bdd-8591-e2fea0f2ee47@github.com> References: <-aqBh7X3owjZhc7NJ9IadTg_pDoBEcSVULP6D9ZQlwc=.2f9552f6-95ee-4bdd-8591-e2fea0f2ee47@github.com> Message-ID: On Thu, 14 Jan 2021 01:20:13 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 51e14f2e Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/51e14f2e Stats: 991 lines in 48 files changed: 764 ins; 123 del; 104 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2072 From dcubed at openjdk.java.net Thu Jan 14 01:34:02 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 14 Jan 2021 01:34:02 GMT Subject: RFR: 8259713: Fix comments and ResetNoHandleMark in deoptimization In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 22:42:07 GMT, Daniel D. Daugherty wrote: >> Changes requested by dcubed (Reviewer). > > The comment in the bug says this: > >> The comments are wrong and the ResetNoHandleMark is unneeded >> since Deoptimization::fetch_unroll_info is a JRT_BLOCK_ENTRY (has a HandleMarkCleaner). > > so I read this as you are changing Deoptimization::fetch_unroll_info to: > > - fix a comment > - remove a ResetNoHandleMark > > The comment in the bug doesn't mention JRT_LEAF at all, but you're > making comment changes there also. > > No where in this fix do I see a ResetNoHandleMark being removed. > > Is the reason for my confusion more clear yet? Please fix the bug synopsis and make the PR description match. Please correct the bug description to describe what you are doing. I also added a proposed comment rewrite for you. ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From dcubed at openjdk.java.net Thu Jan 14 01:34:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 14 Jan 2021 01:34:04 GMT Subject: RFR: 8259713: Fix comments and ResetNoHandleMark in deoptimization In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:12:34 GMT, Coleen Phillimore wrote: > This is a small part of the withdrawn change for https://github.com/openjdk/jdk/pull/1990 to fix the out-of-date comments in deoptimization.cpp. > Tested with tier1-3. src/hotspot/share/runtime/deoptimization.cpp line 693: > 691: // Handles will be leaked. > 692: ResetNoHandleMark rnhm; > 693: HandleMark hm(thread); Here's a simpler rewrite for L687 -> L693: // This code wants to allocate handles which is okay in a leaf method, // but JRT_LEAF contains a NoHandleMark so we have to work around // that with ResetNoHandleMark in order to create a HandleMark here: ResetNoHandleMark rnhm; HandleMark hm(thread); ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From coleenp at openjdk.java.net Thu Jan 14 01:50:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Jan 2021 01:50:05 GMT Subject: RFR: 8259713: Fix comments about ResetNoHandleMark in deoptimization In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 01:30:21 GMT, Daniel D. Daugherty wrote: >> This is a small part of the withdrawn change for https://github.com/openjdk/jdk/pull/1990 to fix the out-of-date comments in deoptimization.cpp. >> Tested with tier1-3. > > src/hotspot/share/runtime/deoptimization.cpp line 693: > >> 691: // Handles will be leaked. >> 692: ResetNoHandleMark rnhm; >> 693: HandleMark hm(thread); > > Here's a simpler rewrite for L687 -> L693: > > // This code wants to allocate handles which is okay in a leaf method, > // but JRT_LEAF contains a NoHandleMark so we have to work around > // that with ResetNoHandleMark in order to create a HandleMark here: > ResetNoHandleMark rnhm; > HandleMark hm(thread); Unfortunately this is not entirely what I want to say. I want to say that you *must* have a HandleMark if you have ResetNoHandleMark in a JRT_LEAF. You need a ResetNoHandleMark to create Handles but there are no asserts to make sure you have a HandleMark. ie: ResetNoHandleMark rnhm; Handle h(THREAD, obj); // OK no problem But the Handle will leak once this function returns (until the next JRT_ENTRY anyway). // This code wants to allocate handles which is okay in a leaf method, // but JRT_LEAF contains a NoHandleMark so we have to work around // that with ResetNoHandleMark in order to create a Handles here. // There must also be a HandleMark here to clean up any handles created in this scope. How about that? ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From ysuenaga at openjdk.java.net Thu Jan 14 03:08:19 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 14 Jan 2021 03:08:19 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed [v3] In-Reply-To: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> Message-ID: > If `Agent_OnAttach()` in JVMTI agent which is attempted to load via JVMTI.agent_load dcmd is failed, it would not be unloaded. > We've [discussed it on serviceability-dev](https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032839.html). This PR is a continuation of that. > > This PR also includes to call `Agent_OnUnload()` when `Agent_OnAttach()` failed. > > How to reproduce: > > 1. Build JVMTI agent for test > $ git clone https://github.com/YaSuenag/jvmti-examples.git > $ cd jvmti-examples/helloworld/out/build > $ cmake ../.. > > 2. Run JShell > > 3. Load JVMTI agent via `jcmd JVMTI.agent_load` with "error" ("error" means `Agent_OnAttach()` returns JNI_ERR) > $ jcmd > 89456 jdk.jshell.execution.RemoteExecutionControl 45651 > 89547 sun.tools.jcmd.JCmd > 89436 jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider > $ jcmd 89436 JVMTI.agent_load `pwd`/libhelloworld.so error > 89436: > return code: -1 > > 4. Check loaded libraries via `jcmd VM.dynlibs` > $ jcmd 89436 VM.dynlibs | grep libhelloworld > 7f2f8b06b000-7f2f8b06c000 r--p 00000000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so > 7f2f8b06c000-7f2f8b06d000 r-xp 00001000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so > 7f2f8b06d000-7f2f8b06e000 r--p 00002000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so > 7f2f8b06e000-7f2f8b06f000 r--p 00002000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so > 7f2f8b06f000-7f2f8b070000 rw-p 00003000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Update jvmti.xml to follow CSR - Merge remote-tracking branch 'upstream/master' into JDK-8252657 - Update patch - Merge remote-tracking branch 'upstream/master' into JDK-8252657 - revert - JVMTI agent is not unloaded when Agent_OnAttach is failed ------------- Changes: https://git.openjdk.java.net/jdk/pull/19/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=19&range=02 Stats: 15 lines in 3 files changed: 10 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/19.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/19/head:pull/19 PR: https://git.openjdk.java.net/jdk/pull/19 From ysuenaga at openjdk.java.net Thu Jan 14 03:08:20 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 14 Jan 2021 03:08:20 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> Message-ID: <2xnw0cfh8F8_WNvB1zEzei7TOigCTcu96wUcDQKZpdg=.bff342d9-5918-461b-992a-e36b20f8064c@github.com> On Fri, 18 Dec 2020 05:09:02 GMT, Yasumasa Suenaga wrote: >>> > * Q3: What has to be done for statically linked agent? >>> >>> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. >> >> I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. > > @dholmes-ora Thank you for explanation! I updated [CSR](https://bugs.openjdk.java.net/browse/JDK-8256918). Could you review it? CSR has been approved. I updated jvmti.xml to follow it (I haven't make any changes in other files in latest commit) Could you review again? ------------- PR: https://git.openjdk.java.net/jdk/pull/19 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 dholmes at openjdk.java.net Thu Jan 14 07:12:59 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 14 Jan 2021 07:12:59 GMT Subject: RFR: 8259713: Fix comments about ResetNoHandleMark in deoptimization In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 01:46:13 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 693: >> >>> 691: // Handles will be leaked. >>> 692: ResetNoHandleMark rnhm; >>> 693: HandleMark hm(thread); >> >> Here's a simpler rewrite for L687 -> L693: >> >> // This code wants to allocate handles which is okay in a leaf method, >> // but JRT_LEAF contains a NoHandleMark so we have to work around >> // that with ResetNoHandleMark in order to create a HandleMark here: >> ResetNoHandleMark rnhm; >> HandleMark hm(thread); > > Unfortunately this is not entirely what I want to say. > I want to say that you *must* have a HandleMark if you have ResetNoHandleMark in a JRT_LEAF. > You need a ResetNoHandleMark to create Handles but there are no asserts to make sure you have a HandleMark. > ie: > > ResetNoHandleMark rnhm; > Handle h(THREAD, obj); // OK no problem > > But the Handle will leak once this function returns (until the next JRT_ENTRY anyway). > > // This code wants to allocate handles which is okay in a leaf method, > // but JRT_LEAF contains a NoHandleMark so we have to work around > // that with ResetNoHandleMark in order to create a Handles here. > // There must also be a HandleMark here to clean up any handles created in this scope. > > How about that? My suggestion: // JRT_LEAF methods don't normally allocate handles and there is a // NoHandleMark to enforce that. It is actually safe to use Handles // in a JRT_LEAF method, and sometimes desirable, but to do so we // must use ResetNoHandleMark to bypass the NoHandleMark, and // then use a HandleMark to ensure any Handles we do create are // cleaned up in this scope. I still question why such a function declares itself a LEAF instead of just being a JRT_ENTRY but that is a different argument. :) Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From dholmes at openjdk.java.net Thu Jan 14 07:22:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 14 Jan 2021 07:22:09 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed [v3] In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> Message-ID: On Thu, 14 Jan 2021 03:08:19 GMT, Yasumasa Suenaga wrote: >> If `Agent_OnAttach()` in JVMTI agent which is attempted to load via JVMTI.agent_load dcmd is failed, it would not be unloaded. >> We've [discussed it on serviceability-dev](https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032839.html). This PR is a continuation of that. >> >> This PR also includes to call `Agent_OnUnload()` when `Agent_OnAttach()` failed. >> >> How to reproduce: >> >> 1. Build JVMTI agent for test >> $ git clone https://github.com/YaSuenag/jvmti-examples.git >> $ cd jvmti-examples/helloworld/out/build >> $ cmake ../.. >> >> 2. Run JShell >> >> 3. Load JVMTI agent via `jcmd JVMTI.agent_load` with "error" ("error" means `Agent_OnAttach()` returns JNI_ERR) >> $ jcmd >> 89456 jdk.jshell.execution.RemoteExecutionControl 45651 >> 89547 sun.tools.jcmd.JCmd >> 89436 jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider >> $ jcmd 89436 JVMTI.agent_load `pwd`/libhelloworld.so error >> 89436: >> return code: -1 >> >> 4. Check loaded libraries via `jcmd VM.dynlibs` >> $ jcmd 89436 VM.dynlibs | grep libhelloworld >> 7f2f8b06b000-7f2f8b06c000 r--p 00000000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so >> 7f2f8b06c000-7f2f8b06d000 r-xp 00001000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so >> 7f2f8b06d000-7f2f8b06e000 r--p 00002000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so >> 7f2f8b06e000-7f2f8b06f000 r--p 00002000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so >> 7f2f8b06f000-7f2f8b070000 rw-p 00003000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Update jvmti.xml to follow CSR > - Merge remote-tracking branch 'upstream/master' into JDK-8252657 > - Update patch > - Merge remote-tracking branch 'upstream/master' into JDK-8252657 > - revert > - JVMTI agent is not unloaded when Agent_OnAttach is failed Hi Yasumasa, Spec update looks good. VM tweak to call dll_unload on failure looks good. I don't understand the test change though. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/19 From ysuenaga at openjdk.java.net Thu Jan 14 08:29:03 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 14 Jan 2021 08:29:03 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed [v3] In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> Message-ID: On Thu, 14 Jan 2021 07:19:06 GMT, David Holmes wrote: > Hi Yasumasa, > > Spec update looks good. > > VM tweak to call dll_unload on failure looks good. Thanks! > I don't understand the test change though. To check the agent is unloaded, call VM.dynlibs dcmd and check whether agent path is not contained. libReturnError.so would be loaded only once in AttachReturnError.java, so it is expected to unload when `Agent_OnAttach()` fails. ------------- PR: https://git.openjdk.java.net/jdk/pull/19 From shade at openjdk.java.net Thu Jan 14 09:04:03 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Jan 2021 09:04:03 GMT Subject: RFR: 8259403: Zero: crash with NULL MethodHandle receiver In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 19:54:22 GMT, Aleksey Shipilev wrote: > Happens reliably: > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/jsr292/NullConstantReceiver.java > # A fatal error has been detected by the Java Runtime Environment: > # SIGSEGV (0xb) at pc=0x0000000000000000, pid=4059994, tid=4060008 > > Zero's MH handling code does not check if receiver is NULL before accessing its klass. > > Additional testing: > - [x] Linux x86_64 Zero `compiler/jsr292/NullConstantReceiver.java` > - [x] Linux x86_64 Zero `tier1` (no new failures) Ping? ------------- PR: https://git.openjdk.java.net/jdk/pull/1987 From stefank at openjdk.java.net Thu Jan 14 10:15:05 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 14 Jan 2021 10:15:05 GMT Subject: RFR: 8256955: Move includes of events.hpp out of header files In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 14:19:58 GMT, Coleen Phillimore wrote: > I should have asked if you were able to build shenandoah and zero with this change? Yes. Built Shenandoah and Zero locally on fastdebug and release. ------------- PR: https://git.openjdk.java.net/jdk/pull/2059 From stefank at openjdk.java.net Thu Jan 14 10:15:05 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 14 Jan 2021 10:15:05 GMT Subject: RFR: 8256955: Move includes of events.hpp out of header files In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 10:11:53 GMT, Stefan Karlsson wrote: >> I should have asked if you were able to build shenandoah and zero with this change? > >> I should have asked if you were able to build shenandoah and zero with this change? > > Yes. Built Shenandoah and Zero locally on fastdebug and release. Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/2059 From stefank at openjdk.java.net Thu Jan 14 11:38:01 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 14 Jan 2021 11:38:01 GMT Subject: Integrated: 8256955: Move includes of events.hpp out of header files In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 09:51:12 GMT, Stefan Karlsson wrote: > I was making changes to events.hpp and saw that the majority of cpp files were recompiled. There are two header files that include events.hpp. I propose that we remove those usages by: > > jvmci.hpp: Use a forward declaration > collectedHeap.hpp: Move its usage to the cpp file > > events.hpp also includes thread.hpp, which brings in a large portion of the HotSpot headers. So, this change is also good in that regard. This pull request has now been integrated. Changeset: 3462f7a9 Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/3462f7a9 Stats: 58 lines in 7 files changed: 31 ins; 27 del; 0 mod 8256955: Move includes of events.hpp out of header files Reviewed-by: kbarrett, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/2059 From coleenp at openjdk.java.net Thu Jan 14 13:23:04 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Jan 2021 13:23:04 GMT Subject: RFR: 8259713: Fix comments about ResetNoHandleMark in deoptimization In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 07:09:58 GMT, David Holmes wrote: >> Unfortunately this is not entirely what I want to say. >> I want to say that you *must* have a HandleMark if you have ResetNoHandleMark in a JRT_LEAF. >> You need a ResetNoHandleMark to create Handles but there are no asserts to make sure you have a HandleMark. >> ie: >> >> ResetNoHandleMark rnhm; >> Handle h(THREAD, obj); // OK no problem >> >> But the Handle will leak once this function returns (until the next JRT_ENTRY anyway). >> >> // This code wants to allocate handles which is okay in a leaf method, >> // but JRT_LEAF contains a NoHandleMark so we have to work around >> // that with ResetNoHandleMark in order to create a Handles here. >> // There must also be a HandleMark here to clean up any handles created in this scope. >> >> How about that? > > My suggestion: > // JRT_LEAF methods don't normally allocate handles and there is a > // NoHandleMark to enforce that. It is actually safe to use Handles > // in a JRT_LEAF method, and sometimes desirable, but to do so we > // must use ResetNoHandleMark to bypass the NoHandleMark, and > // then use a HandleMark to ensure any Handles we do create are > // cleaned up in this scope. > I still question why such a function declares itself a LEAF instead of just being a JRT_ENTRY but that is a different argument. :) > Cheers, > David Ok, your comment says the same thing as mine and includes what I want to say, so I'll use your comment. I'm pretty sure this function wants a NoSafepointVerifier but some of the calls it uses might need handles, because we were pretty aggressive about making arguments into handles. ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From coleenp at openjdk.java.net Thu Jan 14 13:34:02 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Jan 2021 13:34:02 GMT Subject: RFR: 8259713: Fix comments about ResetNoHandleMark in deoptimization In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 13:20:31 GMT, Coleen Phillimore wrote: >> My suggestion: >> // JRT_LEAF methods don't normally allocate handles and there is a >> // NoHandleMark to enforce that. It is actually safe to use Handles >> // in a JRT_LEAF method, and sometimes desirable, but to do so we >> // must use ResetNoHandleMark to bypass the NoHandleMark, and >> // then use a HandleMark to ensure any Handles we do create are >> // cleaned up in this scope. >> I still question why such a function declares itself a LEAF instead of just being a JRT_ENTRY but that is a different argument. :) >> Cheers, >> David > > Ok, your comment says the same thing as mine and includes what I want to say, so I'll use your comment. > I'm pretty sure this function wants a NoSafepointVerifier but some of the calls it uses might need handles, because we were pretty aggressive about making arguments into handles. I actually think the HandleMark is there because of the PreserveExceptionMark call in VerifyStack, which is the thing that Erik ran into also with stack watermarks, and prompted the original request about lifting the restrictions for JRT_LEAF functions. I don't want there to be an unhandleized version of PreserveExceptionMark, and I don't want JRT_LEAF to allow Handles by default, so hopefully this comment is adequate documentation. ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From coleenp at openjdk.java.net Thu Jan 14 13:48:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Jan 2021 13:48:06 GMT Subject: RFR: 8259403: Zero: crash with NULL MethodHandle receiver In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 19:54:22 GMT, Aleksey Shipilev wrote: > Happens reliably: > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/jsr292/NullConstantReceiver.java > # A fatal error has been detected by the Java Runtime Environment: > # SIGSEGV (0xb) at pc=0x0000000000000000, pid=4059994, tid=4060008 > > Zero's MH handling code does not check if receiver is NULL before accessing its klass. > > Additional testing: > - [x] Linux x86_64 Zero `compiler/jsr292/NullConstantReceiver.java` > - [x] Linux x86_64 Zero `tier1` (no new failures) Seems good. I don't know why there's no last_Java_frame where you throw NPE. I was trying to see how bytecodeInterpreter invoke* calls do this and found: // The frame manager handles this #define SET_LAST_JAVA_FRAME() #define RESET_LAST_JAVA_FRAME() Strange. But this change is good. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1987 From coleenp at openjdk.java.net Thu Jan 14 13:51:14 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Jan 2021 13:51:14 GMT Subject: RFR: 8259713: Fix comments about ResetNoHandleMark in deoptimization [v2] In-Reply-To: References: Message-ID: > This is a small part of the withdrawn change for https://github.com/openjdk/jdk/pull/1990 to fix the out-of-date comments in deoptimization.cpp. > Tested with tier1-3. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Use David's comment. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2069/files - new: https://git.openjdk.java.net/jdk/pull/2069/files/024660f7..6b76e6ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2069&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2069&range=00-01 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2069.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2069/head:pull/2069 PR: https://git.openjdk.java.net/jdk/pull/2069 From egahlin at openjdk.java.net Thu Jan 14 14:43:04 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 14 Jan 2021 14:43:04 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> Message-ID: On Wed, 13 Jan 2021 14:26:39 GMT, Yasumasa Suenaga wrote: >>> The right way to do this is to emit the event when the exception is thrown and I think it must happen inside the VM. >> >> I updated PR. Could you review? >> Windows build on GitHub Actions failed, but it is not caused by this PR (due to configure error). >> >> I removed bytecode injection to hook c'tor of `Error` and `Exception`. JavaErrorThrown and JavaExceptionThrown would be thrown from HotSpot. And also number of thrown is counted at HotSpot, so I added new JNI function to get it, it is used for ExceptionStatistics event. >> >>> One problem is that the C2 compiler can eliminate the throw if it can prove the it can't be seen. That is the reason, we ended up with the current implementation many years ago. It was complicated to implement in the VM. >> >> I added a function call which emits JavaErrorThrown and/or JavaExceptionThrown around `Exceptions::log_exception()` call. It is not completely solution for your concern, but we can hook most of throwable objects like unified logging. > > This PR passed all tests in jdk/jfr on Linux x64. I don't have time to look at this now, I need to fix some high priority issues for JDK 16, but the problem is with C2. Several people have looked at this before. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From dcubed at openjdk.java.net Thu Jan 14 14:50:05 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 14 Jan 2021 14:50:05 GMT Subject: RFR: 8259713: Fix comments about ResetNoHandleMark in deoptimization [v2] In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 13:51:14 GMT, Coleen Phillimore wrote: >> This is a small part of the withdrawn change for https://github.com/openjdk/jdk/pull/1990 to fix the out-of-date comments in deoptimization.cpp. >> Tested with tier1-3. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use David's comment. I like David's comment much more than the one I proposed! Thumbs up! For the first time in a long time, I had to use a webrev to review the code since there were so many comments in the Git view that made it hard to see the code... :-) ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2069 From hseigel at openjdk.java.net Thu Jan 14 15:07:01 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 14 Jan 2021 15:07:01 GMT Subject: RFR: 8258912: Remove JVM options CountJNICalls and CountJVMCalls In-Reply-To: <0XHXXCg4OGqHfBY_C6O-NXUn2Dth0CQJM6FNCgw6osM=.96c19bfb-f832-430f-9121-0dad62723910@github.com> References: <0XHXXCg4OGqHfBY_C6O-NXUn2Dth0CQJM6FNCgw6osM=.96c19bfb-f832-430f-9121-0dad62723910@github.com> Message-ID: On Wed, 13 Jan 2021 07:36:10 GMT, Aleksey Shipilev wrote: >> Please review this change to remove the old non-product JVM -XX flags CountRuntimeCalls, CountJNICalls, CountJVMCalls, and CountRemovableExceptions. Additionally, this change removes non-product flag WarnOnStalledSpinLock because, as a result of this change, it is no longer used. >> >> The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > I never used these flags, and I don't think they are very useful. I think most of that data is supposed to be delivered by JFR these days, instead of ad-hoc profiling facilities. If there are no relevant JFR events, they could be added later. Thanks Coleen, Lois, and Aleksey for reviewing this change and David for his comments! ------------- PR: https://git.openjdk.java.net/jdk/pull/2050 From hseigel at openjdk.java.net Thu Jan 14 15:07:02 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 14 Jan 2021 15:07:02 GMT Subject: Integrated: 8258912: Remove JVM options CountJNICalls and CountJVMCalls In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 15:17:52 GMT, Harold Seigel wrote: > Please review this change to remove the old non-product JVM -XX flags CountRuntimeCalls, CountJNICalls, CountJVMCalls, and CountRemovableExceptions. Additionally, this change removes non-product flag WarnOnStalledSpinLock because, as a result of this change, it is no longer used. > > The change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: 38a12017 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/38a12017 Stats: 708 lines in 11 files changed: 0 ins; 702 del; 6 mod 8258912: Remove JVM options CountJNICalls and CountJVMCalls Reviewed-by: coleenp, lfoltan, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/2050 From coleenp at openjdk.java.net Thu Jan 14 15:11:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Jan 2021 15:11:06 GMT Subject: RFR: 8259713: Fix comments about ResetNoHandleMark in deoptimization [v2] In-Reply-To: References: Message-ID: <98jh_jCaTIpuLr6Fsdf2gp7_gI5YZcYaFA6MmFygdpk=.a02af6e5-b2fb-4a2f-8513-ef7cadcc0daa@github.com> On Thu, 14 Jan 2021 14:47:33 GMT, Daniel D. Daugherty wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Use David's comment. > > I like David's comment much more than the one I proposed! > Thumbs up! For the first time in a long time, I had to use a > webrev to review the code since there were so many comments > in the Git view that made it hard to see the code... :-) Thanks Dan! ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From vlivanov at openjdk.java.net Thu Jan 14 17:28:04 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 14 Jan 2021 17:28:04 GMT Subject: RFR: 8259278: Optimize Vector API slice and unslice operations [v2] In-Reply-To: References: <0Hoxshsrh_L881MMdvplGZIUjkrtXwQcOqnOKtNAQqE=.fe0063e1-3234-44dd-884b-c92bf4d3ed5d@github.com> Message-ID: On Thu, 7 Jan 2021 00:33:13 GMT, Sandhya Viswanathan wrote: >> This pull request optimizes Vector API slice and unslice operations. >> All the slice and unslice variants that take more than one argument are implemented in terms of already intrinsic methods on similar lines as slice(origin) and unslice(origin). >> Also, the slice and unslice intrinsics for 256-bit byte/short vectors implemented for x86 platforms supporting AVX2 using a sequence of instructions. >> >> For TestSlice.java attached to JBS (https://bugs.openjdk.java.net/browse/JDK-8259278): >> Before: >> Benchmark (size) Mode Cnt Score Error Units >> TestSlice.vectorSliceOrigin 1024 thrpt 5 17.665 ? 0.980 ops/ms >> TestSlice.vectorSliceOriginVector 1024 thrpt 5 604.179 ? 5.795 ops/ms >> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 9.286 ? 0.088 ops/ms >> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 435.678 ? 30.171 ops/ms >> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 440.492 ? 24.592 ops/ms >> >> After: >> Benchmark (size) Mode Cnt Score Error Units >> TestSlice.vectorSliceOrigin 1024 thrpt 5 1319.044 ? 67.862 ops/ms >> TestSlice.vectorSliceOriginVector 1024 thrpt 5 969.514 ? 33.411 ops/ms >> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 687.804 ? 31.511 ops/ms >> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 560.807 ? 20.600 ops/ms >> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 560.202 ? 4.012 ops/ms >> >> Please review. >> >> Best Regards, >> Sandhya > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Use Objects.checkIndex and move code to xxxVector.java Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1950 From sviswanathan at openjdk.java.net Thu Jan 14 17:52:03 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 14 Jan 2021 17:52:03 GMT Subject: Integrated: 8259278: Optimize Vector API slice and unslice operations In-Reply-To: <0Hoxshsrh_L881MMdvplGZIUjkrtXwQcOqnOKtNAQqE=.fe0063e1-3234-44dd-884b-c92bf4d3ed5d@github.com> References: <0Hoxshsrh_L881MMdvplGZIUjkrtXwQcOqnOKtNAQqE=.fe0063e1-3234-44dd-884b-c92bf4d3ed5d@github.com> Message-ID: On Tue, 5 Jan 2021 22:59:29 GMT, Sandhya Viswanathan wrote: > This pull request optimizes Vector API slice and unslice operations. > All the slice and unslice variants that take more than one argument are implemented in terms of already intrinsic methods on similar lines as slice(origin) and unslice(origin). > Also, the slice and unslice intrinsics for 256-bit byte/short vectors implemented for x86 platforms supporting AVX2 using a sequence of instructions. > > For TestSlice.java attached to JBS (https://bugs.openjdk.java.net/browse/JDK-8259278): > Before: > Benchmark (size) Mode Cnt Score Error Units > TestSlice.vectorSliceOrigin 1024 thrpt 5 17.665 ? 0.980 ops/ms > TestSlice.vectorSliceOriginVector 1024 thrpt 5 604.179 ? 5.795 ops/ms > TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 9.286 ? 0.088 ops/ms > TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 435.678 ? 30.171 ops/ms > TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 440.492 ? 24.592 ops/ms > > After: > Benchmark (size) Mode Cnt Score Error Units > TestSlice.vectorSliceOrigin 1024 thrpt 5 1319.044 ? 67.862 ops/ms > TestSlice.vectorSliceOriginVector 1024 thrpt 5 969.514 ? 33.411 ops/ms > TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 687.804 ? 31.511 ops/ms > TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 560.807 ? 20.600 ops/ms > TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 560.202 ? 4.012 ops/ms > > Please review. > > Best Regards, > Sandhya This pull request has now been integrated. Changeset: a6b2162f Author: Sandhya Viswanathan URL: https://git.openjdk.java.net/jdk/commit/a6b2162f Stats: 983 lines in 45 files changed: 266 ins; 523 del; 194 mod 8259278: Optimize Vector API slice and unslice operations Reviewed-by: psandoz, vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/1950 From amenkov at openjdk.java.net Thu Jan 14 19:59:03 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 14 Jan 2021 19:59:03 GMT Subject: RFR: 8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping In-Reply-To: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> References: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> Message-ID: On Fri, 18 Dec 2020 02:01:28 GMT, Chris Plummer wrote: > There is an assert in `JvmtiThreadState::cur_stack_depth()` that tends to slow down single stepping a lot when running the debuggee with a debug jvm. See CR for details. The fix is to allow disabling of this assert using the new EnableJVMTIStackDepthAsserts global, which defaults to true. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1835 From david.holmes at oracle.com Thu Jan 14 22:52:29 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Jan 2021 08:52:29 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed [v3] In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> Message-ID: <7d1fa4d9-16c0-4ded-7f34-34f5c536a97f@oracle.com> On 14/01/2021 6:29 pm, Yasumasa Suenaga wrote: > On Thu, 14 Jan 2021 07:19:06 GMT, David Holmes wrote: > >> Hi Yasumasa, >> >> Spec update looks good. >> >> VM tweak to call dll_unload on failure looks good. > > Thanks! > >> I don't understand the test change though. > > To check the agent is unloaded, call VM.dynlibs dcmd and check whether agent path is not contained. > libReturnError.so would be loaded only once in AttachReturnError.java, so it is expected to unload when `Agent_OnAttach()` fails. Got it! Thanks. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/19 > From dholmes at openjdk.java.net Thu Jan 14 22:53:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 14 Jan 2021 22:53:06 GMT Subject: RFR: 8259713: Fix comments about ResetNoHandleMark in deoptimization [v2] In-Reply-To: References: Message-ID: <2Dj4MPv1SoK4YmMBLGQ7mEHwOK-DZPNoFrARGqS8hKw=.c14e607d-00bc-4fbf-8338-6ac86dd10b64@github.com> On Thu, 14 Jan 2021 13:51:14 GMT, Coleen Phillimore wrote: >> This is a small part of the withdrawn change for https://github.com/openjdk/jdk/pull/1990 to fix the out-of-date comments in deoptimization.cpp. >> Tested with tier1-3. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use David's comment. LG. Thanks Coleen! David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2069 From dcubed at openjdk.java.net Thu Jan 14 23:04:11 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 14 Jan 2021 23:04:11 GMT Subject: RFR: 8259068: Streamline class loader locking In-Reply-To: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Wed, 13 Jan 2021 23:30:09 GMT, Coleen Phillimore wrote: > The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. > This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. > Tested with tier1-8. Thumbs up. I only have minor nits and wording suggestions. It would be good if @iklam had a chance to review this also. src/hotspot/share/classfile/systemDictionary.cpp line 579: > 577: assert_lock_strong(SystemDictionary_lock); > 578: > 579: assert(lockObject() != NULL, "unexpected double_lock_wait"); Perhaps a different assert string: "lockObject must be non-NULL" src/hotspot/share/classfile/systemDictionary.cpp line 582: > 580: bool calledholdinglock > 581: = ObjectSynchronizer::current_thread_holds_lock(thread->as_Java_thread(), lockObject); > 582: assert(calledholdinglock,"must hold lock for notify"); L582 nit - s/,/, / (not your bug) src/hotspot/share/classfile/systemDictionary.cpp line 583: > 581: = ObjectSynchronizer::current_thread_holds_lock(thread->as_Java_thread(), lockObject); > 582: assert(calledholdinglock,"must hold lock for notify"); > 583: assert(!is_parallelCapable(lockObject), "unexpected double_lock_wait"); Perhaps a different assert string: "lockObject must not be parallelCapable" src/hotspot/share/classfile/systemDictionary.cpp line 752: > 750: } > 751: > 752: assert(placeholders()->compute_hash(name) == name_hash, "they're the same hashcode"); Why delete this assert? src/hotspot/share/classfile/systemDictionary.cpp line 1104: > 1102: TRAPS) { > 1103: > 1104: assert(st != NULL, "invariant"); Thanks for moving this assert here. src/hotspot/share/classfile/systemDictionary.cpp line 1635: > 1633: HandleMark hm(THREAD); > 1634: ClassLoaderData* loader_data = k->class_loader_data(); > 1635: assert(loader_data->class_loader() == class_loader(), "they are the same"); Perhaps: s/they are the same/they must be the same/ src/hotspot/share/classfile/systemDictionaryShared.cpp line 1034: > 1032: Dictionary* dictionary = loader_data->dictionary(); > 1033: > 1034: unsigned int d_hash = dictionary->compute_hash(name); Is there a reason that `d_hash` was previously computed outside the `SystemDictionary_lock`? src/hotspot/share/runtime/synchronizer.hpp line 189: > 187: // reenter reclaims lock with original recursion count > 188: intx complete_exit(TRAPS) { return ObjectSynchronizer::complete_exit(_obj, THREAD); } > 189: void reenter(intx recursions, TRAPS) { ObjectSynchronizer::reenter(_obj, recursions, CHECK); } Nice cleanup. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2071 From dcubed at openjdk.java.net Thu Jan 14 23:04:14 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 14 Jan 2021 23:04:14 GMT Subject: RFR: 8259068: Streamline class loader locking In-Reply-To: References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: <1CnXZRctx-6pM0m-_OUyuFbMBz45hZydiS73HnVkIi4=.f4b04454-9650-41f0-8234-229838ce5881@github.com> On Thu, 14 Jan 2021 22:38:52 GMT, Daniel D. Daugherty wrote: >> The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. >> This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. >> Tested with tier1-8. > > src/hotspot/share/classfile/systemDictionary.cpp line 752: > >> 750: } >> 751: >> 752: assert(placeholders()->compute_hash(name) == name_hash, "they're the same hashcode"); > > Why delete this assert? Ahhh... I see now that you moved it. Okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From cjplummer at openjdk.java.net Thu Jan 14 23:07:03 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 14 Jan 2021 23:07:03 GMT Subject: Integrated: 8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping In-Reply-To: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> References: <3X35Q9Hew8S_EDCkJ-UTA6OyWteyQoAp5IoWf2KZUXI=.b386bb27-1b60-4109-8d5e-dca6647f5c25@github.com> Message-ID: On Fri, 18 Dec 2020 02:01:28 GMT, Chris Plummer wrote: > There is an assert in `JvmtiThreadState::cur_stack_depth()` that tends to slow down single stepping a lot when running the debuggee with a debug jvm. See CR for details. The fix is to allow disabling of this assert using the new EnableJVMTIStackDepthAsserts global, which defaults to true. This pull request has now been integrated. Changeset: 4f881ba5 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/4f881ba5 Stats: 12 lines in 2 files changed: 8 ins; 0 del; 4 mod 8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping Reviewed-by: sspitsyn, dholmes, amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/1835 From iklam at openjdk.java.net Thu Jan 14 23:19:08 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 14 Jan 2021 23:19:08 GMT Subject: RFR: 8259068: Streamline class loader locking In-Reply-To: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Wed, 13 Jan 2021 23:30:09 GMT, Coleen Phillimore wrote: > The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. > This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. > Tested with tier1-8. Changes requested by iklam (Reviewer). src/hotspot/share/classfile/systemDictionary.cpp line 208: > 206: == ObjectSynchronizer::owner_other) { > 207: ClassLoader::sync_nonSystemLoaderLockContentionRate()->inc(); > 208: } Should the systemLoaderLockContentionRate perf counter be removed as well? I don't know what kind of compatibility risk is there. Maybe we can doit in a separate RFE. src/hotspot/share/classfile/systemDictionaryShared.cpp line 1042: > 1040: Handle lockObject = compute_loader_lock_object(THREAD, class_loader); > 1041: check_loader_lock_contention(THREAD, lockObject); > 1042: ObjectLocker ol(lockObject, THREAD); I think we can replace the above 3 lines with something like assert(!is_parallelCapable(class_loader), "ObjectLocker not required"); src/hotspot/share/classfile/systemDictionary.cpp line 1104: > 1102: TRAPS) { > 1103: > 1104: assert(st != NULL, "invariant"); Is this necessary? We normally don't have asserts for non-null-ness. src/hotspot/share/classfile/systemDictionary.cpp line 1635: > 1633: HandleMark hm(THREAD); > 1634: ClassLoaderData* loader_data = k->class_loader_data(); > 1635: assert(loader_data->class_loader() == class_loader(), "they are the same"); What's the reason for adding a class_loader parameter? Is it to avoid creating a new Handle? If there's not much performance difference, I would suggest keeping the old code to avoid code churn. ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From sspitsyn at openjdk.java.net Thu Jan 14 23:27:13 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 14 Jan 2021 23:27:13 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed [v3] In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> Message-ID: On Thu, 14 Jan 2021 03:08:19 GMT, Yasumasa Suenaga wrote: >> If `Agent_OnAttach()` in JVMTI agent which is attempted to load via JVMTI.agent_load dcmd is failed, it would not be unloaded. >> We've [discussed it on serviceability-dev](https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032839.html). This PR is a continuation of that. >> >> This PR also includes to call `Agent_OnUnload()` when `Agent_OnAttach()` failed. >> >> How to reproduce: >> >> 1. Build JVMTI agent for test >> $ git clone https://github.com/YaSuenag/jvmti-examples.git >> $ cd jvmti-examples/helloworld/out/build >> $ cmake ../.. >> >> 2. Run JShell >> >> 3. Load JVMTI agent via `jcmd JVMTI.agent_load` with "error" ("error" means `Agent_OnAttach()` returns JNI_ERR) >> $ jcmd >> 89456 jdk.jshell.execution.RemoteExecutionControl 45651 >> 89547 sun.tools.jcmd.JCmd >> 89436 jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider >> $ jcmd 89436 JVMTI.agent_load `pwd`/libhelloworld.so error >> 89436: >> return code: -1 >> >> 4. Check loaded libraries via `jcmd VM.dynlibs` >> $ jcmd 89436 VM.dynlibs | grep libhelloworld >> 7f2f8b06b000-7f2f8b06c000 r--p 00000000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so >> 7f2f8b06c000-7f2f8b06d000 r-xp 00001000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so >> 7f2f8b06d000-7f2f8b06e000 r--p 00002000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so >> 7f2f8b06e000-7f2f8b06f000 r--p 00002000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so >> 7f2f8b06f000-7f2f8b070000 rw-p 00003000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Update jvmti.xml to follow CSR > - Merge remote-tracking branch 'upstream/master' into JDK-8252657 > - Update patch > - Merge remote-tracking branch 'upstream/master' into JDK-8252657 > - revert > - JVMTI agent is not unloaded when Agent_OnAttach is failed Hi Yasumasa, Both the CSR and the fix look good. Thank you for your patience with the process. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/19 From coleenp at openjdk.java.net Thu Jan 14 23:28:04 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Jan 2021 23:28:04 GMT Subject: RFR: 8259713: Fix comments about ResetNoHandleMark in deoptimization [v2] In-Reply-To: <2Dj4MPv1SoK4YmMBLGQ7mEHwOK-DZPNoFrARGqS8hKw=.c14e607d-00bc-4fbf-8338-6ac86dd10b64@github.com> References: <2Dj4MPv1SoK4YmMBLGQ7mEHwOK-DZPNoFrARGqS8hKw=.c14e607d-00bc-4fbf-8338-6ac86dd10b64@github.com> Message-ID: On Thu, 14 Jan 2021 22:50:00 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Use David's comment. > > LG. > > Thanks Coleen! > > David Thanks, David for the suggestions. ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From coleenp at openjdk.java.net Thu Jan 14 23:30:13 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Jan 2021 23:30:13 GMT Subject: RFR: 8259068: Streamline class loader locking In-Reply-To: References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Thu, 14 Jan 2021 22:30:51 GMT, Daniel D. Daugherty wrote: >> The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. >> This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. >> Tested with tier1-8. > > src/hotspot/share/classfile/systemDictionary.cpp line 579: > >> 577: assert_lock_strong(SystemDictionary_lock); >> 578: >> 579: assert(lockObject() != NULL, "unexpected double_lock_wait"); > > Perhaps a different assert string: > "lockObject must be non-NULL" ok > src/hotspot/share/classfile/systemDictionary.cpp line 583: > >> 581: = ObjectSynchronizer::current_thread_holds_lock(thread->as_Java_thread(), lockObject); >> 582: assert(calledholdinglock,"must hold lock for notify"); >> 583: assert(!is_parallelCapable(lockObject), "unexpected double_lock_wait"); > > Perhaps a different assert string: > "lockObject must not be parallelCapable" Ok, I'll use that wording. Technically it relies on the fact that the lockObject is the class loader, but I'm planning more cleanups here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From coleenp at openjdk.java.net Thu Jan 14 23:30:14 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Jan 2021 23:30:14 GMT Subject: RFR: 8259068: Streamline class loader locking In-Reply-To: <1CnXZRctx-6pM0m-_OUyuFbMBz45hZydiS73HnVkIi4=.f4b04454-9650-41f0-8234-229838ce5881@github.com> References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> <1CnXZRctx-6pM0m-_OUyuFbMBz45hZydiS73HnVkIi4=.f4b04454-9650-41f0-8234-229838ce5881@github.com> Message-ID: On Thu, 14 Jan 2021 22:42:39 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/classfile/systemDictionary.cpp line 752: >> >>> 750: } >>> 751: >>> 752: assert(placeholders()->compute_hash(name) == name_hash, "they're the same hashcode"); >> >> Why delete this assert? > > Ahhh... I see now that you moved it. Okay. yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From coleenp at openjdk.java.net Thu Jan 14 23:28:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Jan 2021 23:28:06 GMT Subject: Integrated: 8259713: Fix comments about ResetNoHandleMark in deoptimization In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:12:34 GMT, Coleen Phillimore wrote: > This is a small part of the withdrawn change for https://github.com/openjdk/jdk/pull/1990 to fix the out-of-date comments in deoptimization.cpp. > Tested with tier1-3. This pull request has now been integrated. Changeset: bf28f925 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/bf28f925 Stats: 15 lines in 1 file changed: 3 ins; 5 del; 7 mod 8259713: Fix comments about ResetNoHandleMark in deoptimization Reviewed-by: lfoltan, dcubed, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/2069 From coleenp at openjdk.java.net Fri Jan 15 00:03:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Jan 2021 00:03:10 GMT Subject: RFR: 8259068: Streamline class loader locking In-Reply-To: References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Thu, 14 Jan 2021 23:04:54 GMT, Ioi Lam wrote: >> The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. >> This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. >> Tested with tier1-8. > > src/hotspot/share/classfile/systemDictionary.cpp line 208: > >> 206: == ObjectSynchronizer::owner_other) { >> 207: ClassLoader::sync_nonSystemLoaderLockContentionRate()->inc(); >> 208: } > > Should the systemLoaderLockContentionRate perf counter be removed as well? I don't know what kind of compatibility risk is there. Maybe we can doit in a separate RFE. So I think it should be done separately. It was always zero or close to zero since nothing really contended on this lock. I was wondering if any of these class loading perf counters are used by anything. Something I wanted to look into afterwards. > src/hotspot/share/classfile/systemDictionary.cpp line 1104: > >> 1102: TRAPS) { >> 1103: >> 1104: assert(st != NULL, "invariant"); > > Is this necessary? We normally don't have asserts for non-null-ness. I moved it from below. Probably not necessary. The callers pass the address of a stack variable and testing this for NULL really doesn't make any sense. > src/hotspot/share/classfile/systemDictionary.cpp line 1635: > >> 1633: HandleMark hm(THREAD); >> 1634: ClassLoaderData* loader_data = k->class_loader_data(); >> 1635: assert(loader_data->class_loader() == class_loader(), "they are the same"); > > What's the reason for adding a class_loader parameter? Is it to avoid creating a new Handle? > If there's not much performance difference, I would suggest keeping the old code to avoid code churn. I added it to prevent a read barrier for GC, since I have the value in all the callers and to prevent creating another handle, which I also have in all the callers. > src/hotspot/share/classfile/systemDictionaryShared.cpp line 1042: > >> 1040: Handle lockObject = compute_loader_lock_object(THREAD, class_loader); >> 1041: check_loader_lock_contention(THREAD, lockObject); >> 1042: ObjectLocker ol(lockObject, THREAD); > > I think we can replace the above 3 lines with something like > assert(!is_parallelCapable(class_loader), "ObjectLocker not required"); Yes, I agree. I updated the comment slightly also. ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From coleenp at openjdk.java.net Fri Jan 15 00:03:12 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Jan 2021 00:03:12 GMT Subject: RFR: 8259068: Streamline class loader locking In-Reply-To: References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Thu, 14 Jan 2021 22:51:51 GMT, Daniel D. Daugherty wrote: >> The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. >> This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. >> Tested with tier1-8. > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 1034: > >> 1032: Dictionary* dictionary = loader_data->dictionary(); >> 1033: >> 1034: unsigned int d_hash = dictionary->compute_hash(name); > > Is there a reason that `d_hash` was previously computed > outside the `SystemDictionary_lock`? I moved it closer to where it's used, but it can go back to outside the lock, to reduce what's computed inside the lock. > src/hotspot/share/runtime/synchronizer.hpp line 189: > >> 187: // reenter reclaims lock with original recursion count >> 188: intx complete_exit(TRAPS) { return ObjectSynchronizer::complete_exit(_obj, THREAD); } >> 189: void reenter(intx recursions, TRAPS) { ObjectSynchronizer::reenter(_obj, recursions, CHECK); } > > Nice cleanup. thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From coleenp at openjdk.java.net Fri Jan 15 00:03:13 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Jan 2021 00:03:13 GMT Subject: RFR: 8259068: Streamline class loader locking In-Reply-To: References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Thu, 14 Jan 2021 23:42:44 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/systemDictionaryShared.cpp line 1042: >> >>> 1040: Handle lockObject = compute_loader_lock_object(THREAD, class_loader); >>> 1041: check_loader_lock_contention(THREAD, lockObject); >>> 1042: ObjectLocker ol(lockObject, THREAD); >> >> I think we can replace the above 3 lines with something like >> assert(!is_parallelCapable(class_loader), "ObjectLocker not required"); > > Yes, I agree. I updated the comment slightly also. It's assert(is_parallelCapable(class_loader)). ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From coleenp at openjdk.java.net Fri Jan 15 00:08:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Jan 2021 00:08:07 GMT Subject: RFR: 8259068: Streamline class loader locking In-Reply-To: References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Thu, 14 Jan 2021 23:37:47 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/systemDictionary.cpp line 1635: >> >>> 1633: HandleMark hm(THREAD); >>> 1634: ClassLoaderData* loader_data = k->class_loader_data(); >>> 1635: assert(loader_data->class_loader() == class_loader(), "they are the same"); >> >> What's the reason for adding a class_loader parameter? Is it to avoid creating a new Handle? >> If there's not much performance difference, I would suggest keeping the old code to avoid code churn. > > I added it to prevent a read barrier for GC, since I have the value in all the callers and to prevent creating another handle, which I also have in all the callers. If I pass class_loader, this function doesn't need a HandleMark either. ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From redestad at openjdk.java.net Fri Jan 15 02:07:06 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 15 Jan 2021 02:07:06 GMT Subject: RFR: 8259068: Streamline class loader locking In-Reply-To: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Wed, 13 Jan 2021 23:30:09 GMT, Coleen Phillimore wrote: > The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. > This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. > Tested with tier1-8. Nice! `ClassLoader::sync_systemLoaderLockContentionRate()` becomes unused with this change, so could trivially be removed. The underlying perf counter lives in the unstable, unsupported SUN_CLS namespace and can probably be nuked without a CSR or anything, but that might be good for a follow-up. ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From jwilhelm at openjdk.java.net Fri Jan 15 02:25:16 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 15 Jan 2021 02:25:16 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8253505: JFR: onFlush invoked out of order with a sorted event stream - 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2087&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2087&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2087/files Stats: 119 lines in 11 files changed: 43 ins; 40 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/2087.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2087/head:pull/2087 PR: https://git.openjdk.java.net/jdk/pull/2087 From coleenp at openjdk.java.net Fri Jan 15 02:41:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Jan 2021 02:41:08 GMT Subject: RFR: 8259068: Streamline class loader locking In-Reply-To: References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Fri, 15 Jan 2021 02:04:25 GMT, Claes Redestad wrote: >> The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. >> This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. >> Tested with tier1-8. > > Nice! > > `ClassLoader::sync_systemLoaderLockContentionRate()` becomes unused with this change, so could trivially be removed. The underlying perf counter lives in the unstable, unsupported SUN_CLS namespace and can probably be nuked without a CSR or anything, but that might be good for a follow-up. Thanks Claes, I'll remove them as a follow up. Do you know what tools use these? ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From ddong at openjdk.java.net Fri Jan 15 02:48:15 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 15 Jan 2021 02:48:15 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall Message-ID: 8259808: Add JFR event to detect GC locker stall ------------- Commit messages: - 8259808: Add JFR event to detect GC locker stall Changes: https://git.openjdk.java.net/jdk/pull/2088/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259808 Stats: 191 lines in 9 files changed: 191 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2088/head:pull/2088 PR: https://git.openjdk.java.net/jdk/pull/2088 From ysuenaga at openjdk.java.net Fri Jan 15 02:51:05 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 15 Jan 2021 02:51:05 GMT Subject: Integrated: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> Message-ID: On Sat, 5 Sep 2020 14:26:17 GMT, Yasumasa Suenaga wrote: > If `Agent_OnAttach()` in JVMTI agent which is attempted to load via JVMTI.agent_load dcmd is failed, it would not be unloaded. > We've [discussed it on serviceability-dev](https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032839.html). This PR is a continuation of that. > > This PR also includes to call `Agent_OnUnload()` when `Agent_OnAttach()` failed. > > How to reproduce: > > 1. Build JVMTI agent for test > $ git clone https://github.com/YaSuenag/jvmti-examples.git > $ cd jvmti-examples/helloworld/out/build > $ cmake ../.. > > 2. Run JShell > > 3. Load JVMTI agent via `jcmd JVMTI.agent_load` with "error" ("error" means `Agent_OnAttach()` returns JNI_ERR) > $ jcmd > 89456 jdk.jshell.execution.RemoteExecutionControl 45651 > 89547 sun.tools.jcmd.JCmd > 89436 jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider > $ jcmd 89436 JVMTI.agent_load `pwd`/libhelloworld.so error > 89436: > return code: -1 > > 4. Check loaded libraries via `jcmd VM.dynlibs` > $ jcmd 89436 VM.dynlibs | grep libhelloworld > 7f2f8b06b000-7f2f8b06c000 r--p 00000000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so > 7f2f8b06c000-7f2f8b06d000 r-xp 00001000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so > 7f2f8b06d000-7f2f8b06e000 r--p 00002000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so > 7f2f8b06e000-7f2f8b06f000 r--p 00002000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so > 7f2f8b06f000-7f2f8b070000 rw-p 00003000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so This pull request has now been integrated. Changeset: 90960c5f Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/90960c5f Stats: 15 lines in 3 files changed: 10 ins; 0 del; 5 mod 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed Reviewed-by: dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/19 From ysuenaga at openjdk.java.net Fri Jan 15 03:08:03 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 15 Jan 2021 03:08:03 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> Message-ID: On Thu, 14 Jan 2021 14:40:34 GMT, Erik Gahlin wrote: > I don't have time to look at this now, I need to fix some high priority issues for JDK 16, but the problem is with C2. Several people have looked at this before. I agree with you the problem is also with C2, however current JFR implementation has also problem in exception events - they hook throwing exceptions lesser than unified logging. It should be fixed. As you can see in this PR, to move throwing events into HotSpot makes big change, so I think it is worth to work now without solving the problem with C2. (We will be able to make lesser change when we want to solve the problem with C2 later.) So I hope other JFR folks review this PR if you are busy. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From jwilhelm at openjdk.java.net Fri Jan 15 03:14:01 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 15 Jan 2021 03:14:01 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 02:19:46 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: d701babb Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/d701babb Stats: 119 lines in 11 files changed: 43 ins; 40 del; 36 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2087 From ddong at openjdk.java.net Fri Jan 15 03:17:03 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 15 Jan 2021 03:17:03 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 02:42:20 GMT, Denghui Dong wrote: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. For the test purpose, I add two Whitebox methods to lock/unlock critical. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From rrich at openjdk.java.net Fri Jan 15 07:43:05 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 15 Jan 2021 07:43:05 GMT Subject: Integrated: 8259627: Potential memory leaks in JVMTI after JDK-8227745 In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 19:09:43 GMT, Richard Reingruber wrote: > This change eliminates memory leaks in the JVMTI implementation reported by SonarCloud. > > The leaks occur when the Java heap is exhausted. This pull request has now been integrated. Changeset: 6d4a593f Author: Richard Reingruber URL: https://git.openjdk.java.net/jdk/commit/6d4a593f Stats: 16 lines in 1 file changed: 8 ins; 8 del; 0 mod 8259627: Potential memory leaks in JVMTI after JDK-8227745 Reviewed-by: shade, stuefe, dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/2055 From mgronlun at openjdk.java.net Fri Jan 15 10:02:07 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Jan 2021 10:02:07 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> Message-ID: On Fri, 15 Jan 2021 03:05:40 GMT, Yasumasa Suenaga wrote: >> I don't have time to look at this now, I need to fix some high priority issues for JDK 16, but the problem is with C2. Several people have looked at this before. > >> I don't have time to look at this now, I need to fix some high priority issues for JDK 16, but the problem is with C2. Several people have looked at this before. > > I agree with you the problem is also with C2, however current JFR implementation has also problem in exception events - they hook throwing exceptions lesser than unified logging. It should be fixed. > > As you can see in this PR, to move throwing events into HotSpot makes big change, so I think it is worth to work now without solving the problem with C2. > (We will be able to make lesser change when we want to solve the problem with C2 later.) > > So I hope other JFR folks review this PR if you are busy. As you say: "move throwing events into HotSpot makes big change" - I agree and Erik has already stated that many have tried already to make this kind of change, but attempts have faltered because the impact / disruptions are unclear. Do you fully understand the consequences of how it will change the way users work with exceptions in JFR? If C2 optimizations now start to remove exception sites that were previously reported? I understand and appreciate the ambition, and I acknowledge the existing mechanisms has drawbacks (known for a long time) but reworking how exceptions are reported is a big project. Such a project should also involve exception throttling - and throttling might pose additional constraints / opportunities that need to be considered. Modifying this subsystem is a sensitive undertaking and should solve the fundamental and already known problems before it is to be endorsed and for the disruption to end user motivated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From sjohanss at openjdk.java.net Fri Jan 15 11:24:09 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 15 Jan 2021 11:24:09 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 18:48:05 GMT, Marcus G K Williams wrote: >> When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using >> Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). >> >> This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). >> >> In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. > > Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Merge branch 'master' into update_hlp > - Merge branch 'master' into update_hlp > - Remove extraneous ' from warning > > Signed-off-by: Marcus G K Williams > - Merge branch 'master' into update_hlp > - Merge branch 'master' into update_hlp > - Merge branch 'master' into update_hlp > - Fix os::large_page_size() in last update > > Signed-off-by: Marcus G K Williams > - Ivan W. Requested Changes > > Removed os::Linux::select_large_page_size and > use os::page_size_for_region instead > > Removed Linux::find_large_page_size and use > register_large_page_sizes. Streamlined > Linux::setup_large_page_size > > Signed-off-by: Marcus G K Williams > - Fix space format, use Linux:: for local func. > > Signed-off-by: Marcus G K Williams > - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp > - ... and 13 more: https://git.openjdk.java.net/jdk/compare/da2415fe...d73e7a4c Back from the holidays and actually looking at our use of large pages from a other perspecive as well. I think the approach here has been simplified a lot from the first suggestion and I like it. Just a few small additional comments. src/hotspot/os/linux/os_linux.cpp line 3750: > 3748: } > 3749: } > 3750: closedir(dir); It would be nice to add some logging here using the `pagesize` tag. The new PageSizes class has a `print_on()` that we could use. I'm thinking something like: LogTarget(Info, pagesize) lt; if (lt.is_enabled()) { LogStream ls(lt); ls.print("Available page sizes: "); _page_sizes.print_on(&ls); } src/hotspot/os/linux/os_linux.cpp line 4013: > 4011: assert(UseLargePages && UseHugeTLBFS, "only for Huge TLBFS large pages"); > 4012: assert(is_aligned(bytes, large_page_size), "Unaligned size"); > 4013: assert(is_aligned(req_addr, large_page_size), "Unaligned address"); Adding an assert here that `large_page_size` is larger than os::vm_page_size (small page size) to ensure we actually get a large page size from `page_size_for_region_aligned()`. Otherwise the passed in a size wasn't correctly aligned. src/hotspot/os/linux/os_linux.cpp line 4047: > 4045: // that is smaller than size_t bytes > 4046: size_t large_page_size = os::page_size_for_region_aligned(bytes, 1); > 4047: Adding the same assert as suggested above here. ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1153 From coleenp at openjdk.java.net Fri Jan 15 13:12:21 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Jan 2021 13:12:21 GMT Subject: RFR: 8259068: Streamline class loader locking [v2] In-Reply-To: References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Fri, 15 Jan 2021 02:38:35 GMT, Coleen Phillimore wrote: >> Nice! >> >> `ClassLoader::sync_systemLoaderLockContentionRate()` becomes unused with this change, so could trivially be removed. The underlying perf counter lives in the unstable, unsupported SUN_CLS namespace and can probably be nuked without a CSR or anything, but that might be good for a follow-up. > > Thanks Claes, I'll remove them as a follow up. Do you know what tools use these? Reran tier1 and running tier2 and 3. ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From coleenp at openjdk.java.net Fri Jan 15 13:12:21 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Jan 2021 13:12:21 GMT Subject: RFR: 8259068: Streamline class loader locking [v2] In-Reply-To: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: > The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. > This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. > Tested with tier1-8. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Changes for code review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2071/files - new: https://git.openjdk.java.net/jdk/pull/2071/files/ccc8281c..bb90fded Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2071&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2071&range=00-01 Stats: 19 lines in 2 files changed: 1 ins; 11 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2071/head:pull/2071 PR: https://git.openjdk.java.net/jdk/pull/2071 From tschatzl at openjdk.java.net Fri Jan 15 14:28:04 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 15 Jan 2021 14:28:04 GMT Subject: RFR: JDK-8257959: Add gtest run with -XX:+UseLargePages In-Reply-To: References: Message-ID: <0I9RgXRSsbppnxzYz3D2kWhnRAGQRta5ynU97-MIU0A=.6f0cdd10-c51e-4c84-b501-34cf05df662c@github.com> On Mon, 14 Dec 2020 09:44:06 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for this addition. > > To better test changes in large page handling, it makes sense to regularly run gtests with large pages enabled. Not the whole gtest suite needs to be run, but at least the os* part. > > Thanks, Thomas Lgtm ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1763 From tschatzl at openjdk.java.net Fri Jan 15 14:42:08 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 15 Jan 2021 14:42:08 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v5] In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 11:19:12 GMT, Albert Mingkun Yang wrote: >> The first commit removes some obsolete enum items, while the second commit adds the verification logic. Commit 2 introduces some "empty" task claims for the verification logic, explicitly marked in the comments. >> >> Test: hotspot_gc > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Lgmt. src/hotspot/share/gc/shared/workgroup.cpp line 377: > 375: // all non-skipped tasks are claimed > 376: for (uint i = 0; i < _n_tasks; ++i) { > 377: if (_tasks[i] == 0) { pre-existing: This could be fixed in a separate CR: _tasks could be an array of bool instead of (u)int. Using an int is a historic artifact of not having a good Atomics library. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2046 From stuefe at openjdk.java.net Fri Jan 15 14:55:08 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 15 Jan 2021 14:55:08 GMT Subject: Integrated: JDK-8257959: Add gtest run with -XX:+UseLargePages In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 09:44:06 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for this addition. > > To better test changes in large page handling, it makes sense to regularly run gtests with large pages enabled. Not the whole gtest suite needs to be run, but at least the os* part. > > Thanks, Thomas This pull request has now been integrated. Changeset: bbac91a4 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/bbac91a4 Stats: 64 lines in 2 files changed: 63 ins; 0 del; 1 mod 8257959: Add gtest run with -XX:+UseLargePages Reviewed-by: lfoltan, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/1763 From stuefe at openjdk.java.net Fri Jan 15 14:55:05 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 15 Jan 2021 14:55:05 GMT Subject: RFR: JDK-8257959: Add gtest run with -XX:+UseLargePages In-Reply-To: <0I9RgXRSsbppnxzYz3D2kWhnRAGQRta5ynU97-MIU0A=.6f0cdd10-c51e-4c84-b501-34cf05df662c@github.com> References: <0I9RgXRSsbppnxzYz3D2kWhnRAGQRta5ynU97-MIU0A=.6f0cdd10-c51e-4c84-b501-34cf05df662c@github.com> Message-ID: On Fri, 15 Jan 2021 14:25:27 GMT, Thomas Schatzl wrote: > Lgtm Thanks, Thomas! ------------- PR: https://git.openjdk.java.net/jdk/pull/1763 From iklam at openjdk.java.net Fri Jan 15 16:39:08 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 15 Jan 2021 16:39:08 GMT Subject: RFR: 8259068: Streamline class loader locking [v2] In-Reply-To: References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Fri, 15 Jan 2021 13:12:21 GMT, Coleen Phillimore wrote: >> The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. >> This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. >> Tested with tier1-8. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Changes for code review comments. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From coleenp at openjdk.java.net Fri Jan 15 16:48:12 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Jan 2021 16:48:12 GMT Subject: RFR: 8259068: Streamline class loader locking [v2] In-Reply-To: References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Fri, 15 Jan 2021 16:35:56 GMT, Ioi Lam wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes for code review comments. > > Marked as reviewed by iklam (Reviewer). Thanks Ioi and Dan! ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From dcubed at openjdk.java.net Fri Jan 15 17:46:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 15 Jan 2021 17:46:09 GMT Subject: RFR: 8259068: Streamline class loader locking [v2] In-Reply-To: References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Fri, 15 Jan 2021 13:12:21 GMT, Coleen Phillimore wrote: >> The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. >> This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. >> Tested with tier1-8. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Changes for code review comments. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2071 From coleenp at openjdk.java.net Fri Jan 15 17:52:09 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Jan 2021 17:52:09 GMT Subject: RFR: 8259068: Streamline class loader locking [v2] In-Reply-To: References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Fri, 15 Jan 2021 17:42:55 GMT, Daniel D. Daugherty wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes for code review comments. > > Thumbs up. Thanks again, Dan! ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From coleenp at openjdk.java.net Fri Jan 15 17:52:11 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Jan 2021 17:52:11 GMT Subject: Integrated: 8259068: Streamline class loader locking In-Reply-To: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> References: <4Spob8szDWYu6X6ILVeSsByl1-QW_x3LyZP5_fRuqmE=.35d269c7-0ba7-49db-b721-934eff0aaf0f@github.com> Message-ID: On Wed, 13 Jan 2021 23:30:09 GMT, Coleen Phillimore wrote: > The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug. > This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call. > Tested with tier1-8. This pull request has now been integrated. Changeset: 9aa5672a Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/9aa5672a Stats: 110 lines in 6 files changed: 8 ins; 63 del; 39 mod 8259068: Streamline class loader locking Reviewed-by: dcubed, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/2071 From rkennke at openjdk.java.net Fri Jan 15 18:25:15 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 15 Jan 2021 18:25:15 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier Message-ID: We named the IU barriers StoreValEnqueueBarrier and various similar variations of this. Instead of naming it after how it's implemented, we should name it after its purpose: support IU-marking. It also looks confusing to have enqueue_barrier() and similar stuff, where no barrier is actually enqueued. The renaming was 100% mechanical. Testing: - [ ] hotspot_gc_shenandoah (x86_64, x86_32, aarch64) ------------- Commit messages: - 8259849: Shenandoah: Rename store-val to IU-barrier Changes: https://git.openjdk.java.net/jdk/pull/2104/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2104&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259849 Stats: 108 lines in 23 files changed: 0 ins; 5 del; 103 mod Patch: https://git.openjdk.java.net/jdk/pull/2104.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2104/head:pull/2104 PR: https://git.openjdk.java.net/jdk/pull/2104 From github.com+168222+mgkwill at openjdk.java.net Fri Jan 15 18:32:07 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Fri, 15 Jan 2021 18:32:07 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 11:21:11 GMT, Stefan Johansson wrote: >> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: >> >> - Merge branch 'master' into update_hlp >> - Merge branch 'master' into update_hlp >> - Remove extraneous ' from warning >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'master' into update_hlp >> - Merge branch 'master' into update_hlp >> - Merge branch 'master' into update_hlp >> - Fix os::large_page_size() in last update >> >> Signed-off-by: Marcus G K Williams >> - Ivan W. Requested Changes >> >> Removed os::Linux::select_large_page_size and >> use os::page_size_for_region instead >> >> Removed Linux::find_large_page_size and use >> register_large_page_sizes. Streamlined >> Linux::setup_large_page_size >> >> Signed-off-by: Marcus G K Williams >> - Fix space format, use Linux:: for local func. >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp >> - ... and 13 more: https://git.openjdk.java.net/jdk/compare/da2415fe...d73e7a4c > > Back from the holidays and actually looking at our use of large pages from a other perspecive as well. I think the approach here has been simplified a lot from the first suggestion and I like it. Just a few small additional comments. Thanks @kstefanj . I'm taking a look at your suggestions and will have an update soon. I'm also working through the testing needs suggested by @tstuefe. It appears he's added gtest runs with largepages option in https://github.com/openjdk/jdk/pull/1763 - Thanks @tstuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From zgu at openjdk.java.net Fri Jan 15 18:54:07 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 15 Jan 2021 18:54:07 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 18:19:09 GMT, Roman Kennke wrote: > We named the IU barriers StoreValEnqueueBarrier and various similar variations of this. Instead of naming it after how it's implemented, we should name it after its purpose: support IU-marking. It also looks confusing to have enqueue_barrier() and similar stuff, where no barrier is actually enqueued. > > The renaming was 100% mechanical. > > Testing: > - [ ] hotspot_gc_shenandoah (x86_64, x86_32, aarch64) Some file's copyright year need to be updated. Otherwise, looks good. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2104 From ayang at openjdk.java.net Fri Jan 15 19:32:06 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 15 Jan 2021 19:32:06 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v5] In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 14:37:45 GMT, Thomas Schatzl wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > src/hotspot/share/gc/shared/workgroup.cpp line 377: > >> 375: // all non-skipped tasks are claimed >> 376: for (uint i = 0; i < _n_tasks; ++i) { >> 377: if (_tasks[i] == 0) { > > pre-existing: This could be fixed in a separate CR: _tasks could be an array of bool instead of (u)int. Using an int is a historic artifact of not having a good Atomics library. Created a ticket (JDK-8259851) for it; will start working on that after this is merged. Thanks for the suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From iklam at openjdk.java.net Fri Jan 15 19:46:22 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 15 Jan 2021 19:46:22 GMT Subject: RFR: 8259214: MetaspaceClosure support for Arrays of MetaspaceObj [v3] In-Reply-To: References: Message-ID: > Currently, `MetaspaceClosure::push` supports only the following variants: > > MetaspaceClosure* it = ...; > Klass* o = ...; it->push(&o); > Array* a1 = ...; it->push(&a1); > Array* a2 = ...; it->push(&a2); > > In Valhalla, support is needed for the following variant (Annotation is a subtype of MetaspaceObj): > > Array* a3 = ...; it->push(&a3); > > This change will allow CDS to make a copy of this array, as well as relocating all the pointers embedded in the elements of this array. See a test case in test_metaspaceClosure.cpp. > > I also cleaned up the code (with help from @kimbarrett) to use SFINAE to dispatch from `MetaspaceClosure::push` to the different subtypes of `MetaspaceClosure::Ref`. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Updated SFINAE per @kimbarrett offline comments; added test case for disallowed types ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1995/files - new: https://git.openjdk.java.net/jdk/pull/1995/files/6781e383..0f7cf37a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1995&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1995&range=01-02 Stats: 38 lines in 1 file changed: 22 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1995.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1995/head:pull/1995 PR: https://git.openjdk.java.net/jdk/pull/1995 From sjohanss at openjdk.java.net Fri Jan 15 20:16:12 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 15 Jan 2021 20:16:12 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: Message-ID: <3BHnoVKWC7hs9ftPYJGiILcSiYDC58nneNLIrwmKYA4=.d5c63333-9b77-4ec5-aab6-719d288e3f2f@github.com> On Tue, 15 Dec 2020 18:48:05 GMT, Marcus G K Williams wrote: >> When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using >> Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). >> >> This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). >> >> In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. > > Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Merge branch 'master' into update_hlp > - Merge branch 'master' into update_hlp > - Remove extraneous ' from warning > > Signed-off-by: Marcus G K Williams > - Merge branch 'master' into update_hlp > - Merge branch 'master' into update_hlp > - Merge branch 'master' into update_hlp > - Fix os::large_page_size() in last update > > Signed-off-by: Marcus G K Williams > - Ivan W. Requested Changes > > Removed os::Linux::select_large_page_size and > use os::page_size_for_region instead > > Removed Linux::find_large_page_size and use > register_large_page_sizes. Streamlined > Linux::setup_large_page_size > > Signed-off-by: Marcus G K Williams > - Fix space format, use Linux:: for local func. > > Signed-off-by: Marcus G K Williams > - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp > - ... and 13 more: https://git.openjdk.java.net/jdk/compare/da2415fe...d73e7a4c Did some more testing with the code. I'm using Parallel for testing becuase G1 does a better job aligning sizes and avoiding some problems. I found that this change has a problem with mapping using both small and large pages (`reserve_memory_special_huge_tlbfs_mixed()`). I'm currently investigating if we can remove these type of mixed-mappings, and instead make sure we only use large pages when properly aligned, so in the future we might be able get rid of some code in this area. For know see my comments below. src/hotspot/os/linux/os_linux.cpp line 4134: > 4132: // Select large_page_size from _page_sizes > 4133: // that is smaller than size_t bytes > 4134: size_t large_page_size = os::page_size_for_region_aligned(bytes, 1); This is partly what I'm looking at from a slightly different direction. And my current thinking is that we should get rid of all mappings that are not properly aligned when using large pages. But that is something for a different PR. I need to look more at this next week, but for this to work as before this call needs to use the unaligned version: `os::page_size_for_region_unaligned(...)` otherwise we will here get a small page size in many cases and that can not be used with the code doing the reservations below. src/hotspot/os/linux/os_linux.cpp line 4046: > 4044: // Select large_page_size from _page_sizes > 4045: // that is smaller than size_t bytes > 4046: size_t large_page_size = os::page_size_for_region_aligned(bytes, 1); This one also needs to use `os::page_size_for_region_unaligned(...)` since we know we have a size that needs both small and large pages. ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1153 From iklam at openjdk.java.net Fri Jan 15 23:08:29 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 15 Jan 2021 23:08:29 GMT Subject: RFR: 8258004: Remove unnecessary inclusion of vm_version.hpp Message-ID: In the x86 build, vm_version.hpp includes vm_version_x86.hpp, which is over 1000 lines due to the complexity of the Intel architecture. vm_version.hpp is unnecessarily included by these popular header files: - assembler.hpp - assembler_x86.hpp - threadLocalAllocBuffer.hpp Before this change, there are 822 .o files that include vm_version.hpp. Refactoring the code reduces the number to 220 .o files. Review note: the main change is in the 3 files mentioned above. All the other files had to be fixed because they were using declarations from vm_version.hpp without including it explicitly. ------------- Commit messages: - 8258004: Remove unnecessary inclusion of vm_version.hpp Changes: https://git.openjdk.java.net/jdk/pull/2105/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2105&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258004 Stats: 157 lines in 30 files changed: 81 ins; 49 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/2105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2105/head:pull/2105 PR: https://git.openjdk.java.net/jdk/pull/2105 From rkennke at openjdk.java.net Fri Jan 15 23:10:26 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 15 Jan 2021 23:10:26 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier [v2] In-Reply-To: References: Message-ID: > We named the IU barriers StoreValEnqueueBarrier and various similar variations of this. Instead of naming it after how it's implemented, we should name it after its purpose: support IU-marking. It also looks confusing to have enqueue_barrier() and similar stuff, where no barrier is actually enqueued. > > The renaming was 100% mechanical. > > Testing: > - [ ] hotspot_gc_shenandoah (x86_64, x86_32, aarch64) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Update copyright years in modified files ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2104/files - new: https://git.openjdk.java.net/jdk/pull/2104/files/2d2b0130..3804e64e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2104&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2104&range=00-01 Stats: 20 lines in 20 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/2104.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2104/head:pull/2104 PR: https://git.openjdk.java.net/jdk/pull/2104 From stuefe at openjdk.java.net Sat Jan 16 06:02:15 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 16 Jan 2021 06:02:15 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: <3BHnoVKWC7hs9ftPYJGiILcSiYDC58nneNLIrwmKYA4=.d5c63333-9b77-4ec5-aab6-719d288e3f2f@github.com> References: <3BHnoVKWC7hs9ftPYJGiILcSiYDC58nneNLIrwmKYA4=.d5c63333-9b77-4ec5-aab6-719d288e3f2f@github.com> Message-ID: On Fri, 15 Jan 2021 20:13:42 GMT, Stefan Johansson wrote: >> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: >> >> - Merge branch 'master' into update_hlp >> - Merge branch 'master' into update_hlp >> - Remove extraneous ' from warning >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'master' into update_hlp >> - Merge branch 'master' into update_hlp >> - Merge branch 'master' into update_hlp >> - Fix os::large_page_size() in last update >> >> Signed-off-by: Marcus G K Williams >> - Ivan W. Requested Changes >> >> Removed os::Linux::select_large_page_size and >> use os::page_size_for_region instead >> >> Removed Linux::find_large_page_size and use >> register_large_page_sizes. Streamlined >> Linux::setup_large_page_size >> >> Signed-off-by: Marcus G K Williams >> - Fix space format, use Linux:: for local func. >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp >> - ... and 13 more: https://git.openjdk.java.net/jdk/compare/da2415fe...d73e7a4c > > Did some more testing with the code. I'm using Parallel for testing becuase G1 does a better job aligning sizes and avoiding some problems. > > I found that this change has a problem with mapping using both small and large pages (`reserve_memory_special_huge_tlbfs_mixed()`). I'm currently investigating if we can remove these type of mixed-mappings, and instead make sure we only use large pages when properly aligned, so in the future we might be able get rid of some code in this area. For know see my comments below. Since we are not shipping this with JDK16, I'm more relaxed now. This will have time to cook before JDK17 is shipped, which takes care of my third point (doing more tests). About the jtreg test. I originally wrote: >> one jtreg test to test that the VM comes up with -XX:+UseLargePages -XX:LargePageSizeInBytes=1G and allocates small-large-pages as expected. This is not only needed as a function proof but to prevent regressions when we reform the code (which will happen) Not sure if that was too vague. An easy way would be to add some tracing to the VM in the allocation path, eg with `log_info(os)(...)`, then in the test start a VM with `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xlog=os`, and scan its output. There are many tests which do this, for an easy example see e.g. runtime/os/TestUseCpuAllocPath.java. I'll take a closer look next week but will wait until Stefan had his go. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From ddong at openjdk.java.net Mon Jan 18 02:53:37 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 18 Jan 2021 02:53:37 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 03:14:10 GMT, Denghui Dong wrote: >> GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. >> >> For the test purpose, I add two Whitebox methods to lock/unlock critical. > > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Greetings, please help review this patch:) Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From iklam at openjdk.java.net Mon Jan 18 05:48:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 18 Jan 2021 05:48:52 GMT Subject: RFR: 8259882: Reduce the inclusion of perfData.hpp Message-ID: perfData.hpp is about 1000 lines long, and is included by 829 out of about 1000 HotSpot .o files. Several popular headers (such as synchronizer.hpp, objectMonitor.hpp, threadLocalAllocBuffer.hpp) include perfData.hpp. However, since these headers just declare pointers like PerfCounter* foo; there's no need to include perfData.hpp. A forward declaration of the PerfCount type would suffice. With forward declaration, we can remove perfData.hpp from these headers. This reduces the number of .o files that include perfData.hpp to 183. Build time of HotSpot is reduced by about 0.4%. **Note:** the forward declaration is in the new file perfDataTypes.hpp. It contains typedefs to make "aliases" of the types. These are probably relics from the past, where new classes like`PerfIntConstant` were to be added but that never happened. typedef PerfLongSampleHelper PerfSampleHelper; typedef PerfLongConstant PerfConstant; typedef PerfLongCounter PerfCounter; typedef PerfLongVariable PerfVariable; The HotSpot code uses both the "real" type and the "alias" type (mostly the latter). I don't want to deal with the alises for now, so I just moved them from perfData.hpp to perfDataTypes.hpp. We should probably just rename `PerfLongConstant` to `PerfConstant` in a future RFE. Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- Commit messages: - 8259882: Reduce the inclusion of perfData.hpp Changes: https://git.openjdk.java.net/jdk/pull/2123/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2123&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259882 Stats: 116 lines in 23 files changed: 73 ins; 20 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/2123.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2123/head:pull/2123 PR: https://git.openjdk.java.net/jdk/pull/2123 From dholmes at openjdk.java.net Mon Jan 18 07:55:47 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 18 Jan 2021 07:55:47 GMT Subject: RFR: 8258004: Remove unnecessary inclusion of vm_version.hpp In-Reply-To: References: Message-ID: <1dbjfT3cRIqIyQCoxi0RJqPkKWUBw7d3zQF_RaE1EUA=.7f1e1919-8395-4126-baf7-39ebe78d74e3@github.com> On Fri, 15 Jan 2021 22:13:50 GMT, Ioi Lam wrote: > In the x86 build, vm_version.hpp includes vm_version_x86.hpp, which is over 1000 lines due to the complexity of the Intel architecture. > > vm_version.hpp is unnecessarily included by these popular header files: > - assembler.hpp > - assembler_x86.hpp > - threadLocalAllocBuffer.hpp > > Before this change, there are 822 .o files that include vm_version.hpp. Refactoring the code reduces the number to 220 .o files. > > Review note: the main change is in the 3 files mentioned above. All the other files had to be fixed because they were using declarations from vm_version.hpp without including it explicitly. Changes appear fine. Thanks, David Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2105 From stefank at openjdk.java.net Mon Jan 18 08:12:47 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 18 Jan 2021 08:12:47 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 02:42:20 GMT, Denghui Dong wrote: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Not a review, but a few comments about what probably needs to be cleaned up before a proper review starts. src/hotspot/share/gc/shared/gcLocker.cpp line 186: > 184: _stall_count = 0; > 185: } > 186: #endif This adds a fair amount of noise and hides the actual GCLocker logic, IMHO. Could you somehow encapsulate this code and the other INCLUDE_JFR above into a class and make single-line calls perform these functions? src/hotspot/share/jfr/metadata/metadata.xml line 1080: > 1078: > 1079: > 1080: You add this between two Shenandoah events. Could you put it somewhere where it's not splitting up a group of events? src/hotspot/share/prims/whitebox.cpp line 44: > 42: #include "gc/shared/genArguments.hpp" > 43: #include "gc/shared/genCollectedHeap.hpp" > 44: #include "gc/shared/gcLocker.inline.hpp" Sort includes. src/hotspot/share/gc/shared/gcLocker.cpp line 112: > 110: #if INCLUDE_JFR > 111: if (EventGCLocker::is_enabled()) { > 112: _needs_gc_start_timestamp = JfrTicks::now(); Do you really need to use JfrTicks instead of Ticks here? If not, could you remove all references and includes of JfrTicks? We usually use pass in Ticks when we send JFR events. src/hotspot/share/utilities/ticks.hpp line 241: > 239: friend class GCTimerTest; > 240: friend class CompilerEvent; > 241: friend class GCLocker; I don't think this should be needed. ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2088 From stefank at openjdk.java.net Mon Jan 18 08:16:38 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 18 Jan 2021 08:16:38 GMT Subject: RFR: 8258004: Remove unnecessary inclusion of vm_version.hpp In-Reply-To: References: Message-ID: <9rc4uAranVYWq-ekWYEUcRGbxPytq4ITgaRkk3mRyCs=.140c39dc-d6b1-4990-9fe8-06862dbd5175@github.com> On Fri, 15 Jan 2021 22:13:50 GMT, Ioi Lam wrote: > In the x86 build, vm_version.hpp includes vm_version_x86.hpp, which is over 1000 lines due to the complexity of the Intel architecture. > > vm_version.hpp is unnecessarily included by these popular header files: > - assembler.hpp > - assembler_x86.hpp > - threadLocalAllocBuffer.hpp > > Before this change, there are 822 .o files that include vm_version.hpp. Refactoring the code reduces the number to 220 .o files. > > Review note: the main change is in the 3 files mentioned above. All the other files had to be fixed because they were using declarations from vm_version.hpp without including it explicitly. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2105 From ayang at openjdk.java.net Mon Jan 18 08:31:47 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 18 Jan 2021 08:31:47 GMT Subject: RFR: 8074101: Add verification that all tasks are actually claimed during roots processing [v5] In-Reply-To: References: Message-ID: <1EvfoP-M7eGHkfH79oSV6DBMGtunMjUNTSoFEYn5ysI=.33cb0699-6647-478d-b34d-c729c9da3e30@github.com> On Fri, 15 Jan 2021 14:39:06 GMT, Thomas Schatzl wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > Lgmt. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From ayang at openjdk.java.net Mon Jan 18 08:36:38 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 18 Jan 2021 08:36:38 GMT Subject: Integrated: 8074101: Add verification that all tasks are actually claimed during roots processing In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 11:13:29 GMT, Albert Mingkun Yang wrote: > The first commit removes some obsolete enum items, while the second commit adds the verification logic. Commit 2 introduces some "empty" task claims for the verification logic, explicitly marked in the comments. > > Test: hotspot_gc This pull request has now been integrated. Changeset: e93f08e2 Author: Albert Mingkun Yang Committer: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/e93f08e2 Stats: 95 lines in 8 files changed: 51 ins; 22 del; 22 mod 8074101: Add verification that all tasks are actually claimed during roots processing Reviewed-by: kbarrett, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/2046 From shade at openjdk.java.net Mon Jan 18 10:09:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Jan 2021 10:09:54 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier [v2] In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 23:10:26 GMT, Roman Kennke wrote: >> We named the IU barriers StoreValEnqueueBarrier and various similar variations of this. Instead of naming it after how it's implemented, we should name it after its purpose: support IU-marking. It also looks confusing to have enqueue_barrier() and similar stuff, where no barrier is actually enqueued. >> >> The renaming was 100% mechanical. >> >> Testing: >> - [ ] hotspot_gc_shenandoah (x86_64, x86_32, aarch64) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years in modified files This makes sense. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2104 From shade at openjdk.java.net Mon Jan 18 10:09:55 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Jan 2021 10:09:55 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 10:05:14 GMT, Aleksey Shipilev wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright years in modified files > > This makes sense. ...except that GHA report these two tests have failed: gc/shenandoah/options/TestWrongBarrierDisable.java gc/shenandoah/options/TestWrongBarrierEnable.java ------------- PR: https://git.openjdk.java.net/jdk/pull/2104 From rkennke at openjdk.java.net Mon Jan 18 10:22:05 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 18 Jan 2021 10:22:05 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier [v3] In-Reply-To: References: Message-ID: <-V_pN8Z-yBefpevDtyLy_A77-YNvlGXJuiXKD3_9f2s=.30835087-e001-4ffe-8467-afa69c1cf347@github.com> > We named the IU barriers StoreValEnqueueBarrier and various similar variations of this. Instead of naming it after how it's implemented, we should name it after its purpose: support IU-marking. It also looks confusing to have enqueue_barrier() and similar stuff, where no barrier is actually enqueued. > > The renaming was 100% mechanical. > > Testing: > - [ ] hotspot_gc_shenandoah (x86_64, x86_32, aarch64) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Change to I-U barrier name in tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2104/files - new: https://git.openjdk.java.net/jdk/pull/2104/files/3804e64e..31810029 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2104&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2104&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2104.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2104/head:pull/2104 PR: https://git.openjdk.java.net/jdk/pull/2104 From shade at openjdk.java.net Mon Jan 18 10:32:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Jan 2021 10:32:47 GMT Subject: Integrated: 8259403: Zero: crash with NULL MethodHandle receiver In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 19:54:22 GMT, Aleksey Shipilev wrote: > Happens reliably: > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/jsr292/NullConstantReceiver.java > # A fatal error has been detected by the Java Runtime Environment: > # SIGSEGV (0xb) at pc=0x0000000000000000, pid=4059994, tid=4060008 > > Zero's MH handling code does not check if receiver is NULL before accessing its klass. > > Additional testing: > - [x] Linux x86_64 Zero `compiler/jsr292/NullConstantReceiver.java` > - [x] Linux x86_64 Zero `tier1` (no new failures) This pull request has now been integrated. Changeset: ff275b37 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/ff275b37 Stats: 79 lines in 4 files changed: 57 ins; 16 del; 6 mod 8259403: Zero: crash with NULL MethodHandle receiver Reviewed-by: coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1987 From sjohanss at openjdk.java.net Mon Jan 18 10:45:48 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 18 Jan 2021 10:45:48 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: <3BHnoVKWC7hs9ftPYJGiILcSiYDC58nneNLIrwmKYA4=.d5c63333-9b77-4ec5-aab6-719d288e3f2f@github.com> Message-ID: On Sat, 16 Jan 2021 05:58:56 GMT, Thomas Stuefe wrote: >> Did some more testing with the code. I'm using Parallel for testing becuase G1 does a better job aligning sizes and avoiding some problems. >> >> I found that this change has a problem with mapping using both small and large pages (`reserve_memory_special_huge_tlbfs_mixed()`). I'm currently investigating if we can remove these type of mixed-mappings, and instead make sure we only use large pages when properly aligned, so in the future we might be able get rid of some code in this area. For know see my comments below. > > Since we are not shipping this with JDK16, I'm more relaxed now. This will have time to cook before JDK17 is shipped, which takes care of my third point (doing more tests). > > About the jtreg test. I originally wrote: > >>> one jtreg test to test that the VM comes up with -XX:+UseLargePages -XX:LargePageSizeInBytes=1G and allocates small-large-pages as expected. This is not only needed as a function proof but to prevent regressions when we reform the code (which will happen) > > Not sure if that was too vague. An easy way would be to add some tracing to the VM in the allocation path, eg with `log_info(os)(...)`, then in the test start a VM with `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xlog=os`, and scan its output. There are many tests which do this, for an easy example see e.g. runtime/os/TestUseCpuAllocPath.java. > > I'll take a closer look next week but will wait until Stefan had his go. Found a couple of additional issues: * The `page_size_for_region_*()` helpers was previously only used in higher level code to help figure out if large pages should/could be used for a given size. Now when using them at the actual site of reservation it will break the cases where someone in a higher level has requested that there should be at least a certain number of pages for the given size. We can take the heap using Parallel as an example: const size_t min_pages = 4; // 1 for eden + 1 for each survivor + 1 for old const size_t page_sz = os::page_size_for_region_aligned(MinHeapSize, min_pages); If both 2M and 1G pages are enabled this will settle for 2M in the code setting up Parallel GC but then end up allocating just one 1G page if we run with `-Xmx1g`. * There is also an issue when there, for example, are too few pages to allocate the heap using 1G pages, then we fall straight back to 4k pages instead of trying 2M pages first. My preferred way of handling this would be that the higher level code sets an upper bound on the page size to be used and the mapping layer satisfies the mapping using the largest possible page size with enough pages free. Such a change might be a bit big for this PR, but we need to make sure this change don't break anything like what I describe above. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From sjohanss at openjdk.java.net Mon Jan 18 11:46:49 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 18 Jan 2021 11:46:49 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 18:48:05 GMT, Marcus G K Williams wrote: >> When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using >> Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). >> >> This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). >> >> In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. > > Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Merge branch 'master' into update_hlp > - Merge branch 'master' into update_hlp > - Remove extraneous ' from warning > > Signed-off-by: Marcus G K Williams > - Merge branch 'master' into update_hlp > - Merge branch 'master' into update_hlp > - Merge branch 'master' into update_hlp > - Fix os::large_page_size() in last update > > Signed-off-by: Marcus G K Williams > - Ivan W. Requested Changes > > Removed os::Linux::select_large_page_size and > use os::page_size_for_region instead > > Removed Linux::find_large_page_size and use > register_large_page_sizes. Streamlined > Linux::setup_large_page_size > > Signed-off-by: Marcus G K Williams > - Fix space format, use Linux:: for local func. > > Signed-off-by: Marcus G K Williams > - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp > - ... and 13 more: https://git.openjdk.java.net/jdk/compare/da2415fe...d73e7a4c src/hotspot/os/linux/os_linux.cpp line 3746: > 3744: if (page_size * K > (size_t)Linux::page_size()) { > 3745: // Add each found Large Page Size to _page_sizes > 3746: _page_sizes.add(page_size * K); Just realized one more thing, with this code we will enable all page sizes configured even if there are no pages "allocated" for the given size. Is that what we want or should we read the file nr_hugepages in the given director and only add it if the size is > 0? ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From iwalulya at openjdk.java.net Mon Jan 18 12:20:52 2021 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Mon, 18 Jan 2021 12:20:52 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 11:44:13 GMT, Stefan Johansson wrote: >> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: >> >> - Merge branch 'master' into update_hlp >> - Merge branch 'master' into update_hlp >> - Remove extraneous ' from warning >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'master' into update_hlp >> - Merge branch 'master' into update_hlp >> - Merge branch 'master' into update_hlp >> - Fix os::large_page_size() in last update >> >> Signed-off-by: Marcus G K Williams >> - Ivan W. Requested Changes >> >> Removed os::Linux::select_large_page_size and >> use os::page_size_for_region instead >> >> Removed Linux::find_large_page_size and use >> register_large_page_sizes. Streamlined >> Linux::setup_large_page_size >> >> Signed-off-by: Marcus G K Williams >> - Fix space format, use Linux:: for local func. >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp >> - ... and 13 more: https://git.openjdk.java.net/jdk/compare/da2415fe...d73e7a4c > > src/hotspot/os/linux/os_linux.cpp line 3746: > >> 3744: if (page_size * K > (size_t)Linux::page_size()) { >> 3745: // Add each found Large Page Size to _page_sizes >> 3746: _page_sizes.add(page_size * K); > > Just realized one more thing, with this code we will enable all page sizes configured even if there are no pages "allocated" for the given size. > > Is that what we want or should we read the file nr_hugepages in the given director and only add it if the size is > 0? I think a more complete solution is to check the nr_hugepages. Additionally, this will be required by the solution you propose above that would consider "largest possible page size with enough pages free". ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From sjohanss at openjdk.java.net Mon Jan 18 13:17:52 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 18 Jan 2021 13:17:52 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 12:17:26 GMT, Ivan Walulya wrote: >> src/hotspot/os/linux/os_linux.cpp line 3746: >> >>> 3744: if (page_size * K > (size_t)Linux::page_size()) { >>> 3745: // Add each found Large Page Size to _page_sizes >>> 3746: _page_sizes.add(page_size * K); >> >> Just realized one more thing, with this code we will enable all page sizes configured even if there are no pages "allocated" for the given size. >> >> Is that what we want or should we read the file nr_hugepages in the given director and only add it if the size is > 0? > > I think a more complete solution is to check the nr_hugepages. Additionally, this will be required by the solution you propose above that would consider "largest possible page size with enough pages free". I think so too. The "largest possible page size..." could be solved anyway, by just retrying all configured pages sizes until we find one that works. But it would be much more efficient to just try the page size that actually could work. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From rkennke at openjdk.java.net Mon Jan 18 13:34:49 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 18 Jan 2021 13:34:49 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 10:06:32 GMT, Aleksey Shipilev wrote: > ...except that GHA report these two tests have failed: > gc/shenandoah/options/TestWrongBarrierDisable.java > gc/shenandoah/options/TestWrongBarrierEnable.java Right. Those should be fixed now. Only remaining GHA failure is Windows: configure: error: Could not find a C compiler. Do you know what's up there? ------------- PR: https://git.openjdk.java.net/jdk/pull/2104 From shade at openjdk.java.net Mon Jan 18 13:38:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Jan 2021 13:38:47 GMT Subject: RFR: 8259849: Shenandoah: Rename store-val to IU-barrier [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:31:58 GMT, Roman Kennke wrote: > Right. Those should be fixed now. Only remaining GHA failure is Windows: > > configure: error: Could not find a C compiler. > Do you know what's up there? Known issue: https://bugs.openjdk.java.net/browse/JDK-8259679 ------------- PR: https://git.openjdk.java.net/jdk/pull/2104 From stuefe at openjdk.java.net Mon Jan 18 13:50:39 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 18 Jan 2021 13:50:39 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:14:28 GMT, Stefan Johansson wrote: >> I think a more complete solution is to check the nr_hugepages. Additionally, this will be required by the solution you propose above that would consider "largest possible page size with enough pages free". > > I think so too. The "largest possible page size..." could be solved anyway, by just retrying all configured pages sizes until we find one that works. But it would be much more efficient to just try the page size that actually could work. One also can set nr_overcommit_hugepages>0 and have a "dynamic" large page pool this way, even with nr_hugepages=0. Moreover, these settings can change during the lifetime of the VM. I would not bother adding too much logic here. Allocating huge pages may or may not fail anyway and the VM has to be prepared to deal with failure. Just my 5c. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From ddong at openjdk.java.net Mon Jan 18 13:55:06 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 18 Jan 2021 13:55:06 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: Refactor based on comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2088/files - new: https://git.openjdk.java.net/jdk/pull/2088/files/b68814f3..c36d4f96 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=00-01 Stats: 94 lines in 6 files changed: 55 ins; 36 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2088/head:pull/2088 PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Mon Jan 18 13:55:07 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 18 Jan 2021 13:55:07 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 08:10:10 GMT, Stefan Karlsson wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor based on comments > > Not a review, but a few comments about what probably needs to be cleaned up before a proper review starts. Refactored. Testing: jdk/jfr all passed. > src/hotspot/share/gc/shared/gcLocker.cpp line 186: > >> 184: _stall_count = 0; >> 185: } >> 186: #endif > > This adds a fair amount of noise and hides the actual GCLocker logic, IMHO. Could you somehow encapsulate this code and the other INCLUDE_JFR above into a class and make single-line calls perform these functions? good idea. updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From sjohanss at openjdk.java.net Mon Jan 18 14:01:41 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 18 Jan 2021 14:01:41 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:48:12 GMT, Thomas Stuefe wrote: >> I think so too. The "largest possible page size..." could be solved anyway, by just retrying all configured pages sizes until we find one that works. But it would be much more efficient to just try the page size that actually could work. > > One also can set nr_overcommit_hugepages>0 and have a "dynamic" large page pool this way, even with nr_hugepages=0. Moreover, these settings can change during the lifetime of the VM. I would not bother adding too much logic here. Allocating huge pages may or may not fail anyway and the VM has to be prepared to deal with failure. Just my 5c. The "dynamic part" might make this actually being "too much logic", otherwise if feels like a pretty reasonable check. The fact that huge pages can be added during the runtime of the JVM doesn't feel like a big problem, since most large reservations are done at startup. But you might be right, since we have to handle the case of a failed mapping, it might not be to big of a problem trying all possible page sizes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From kbarrett at openjdk.java.net Mon Jan 18 14:13:44 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 18 Jan 2021 14:13:44 GMT Subject: RFR: 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE Message-ID: <4sH9-Ili4eHGu7VOvOCYqmZ9ZGzxqH9kyyw6Qlzk-C8=.3424a2d5-80ae-4c98-9a0d-c3a215a29d5b@github.com> [Restarting this PR after some offline discussion with jrose. New name for the macro, and some additional commentary and tests.] Please review this change which adds the ENABLE_IF_SDEFN macro. This is used in the definition of a function template when that definition is separate from a declaration that uses ENABLE_IF. Alternative names for the new macro are possible and even solicited. I know, I'm asking for bikeshedding. The ENABLE_IF macro provides convenient syntax for function template SFINAE using the new default template parameter feature of C++11. However, this macro can only be used in the function declaration (which may also be a definition). The syntax needed in a definition that is separate from the declaration is different, but the type forms for the non-type template parameters in the two places must be "equivalent" (C++14 14.5.6). The precise form for ENABLE_IF is "hidden" behind the macro. It is not desirable to have template definitions making assumptions about that form. This suggests there should be a second macro for use in the separate definition case, with the two macros maintained together to ensure the necessary consistency. (Note that some versions of gcc permit the unused default in some separate definitions. Other tool chains reject it. Because of this, I was only vaguely aware of (and had long forgotten) about this issue when proposing ENABLE_IF, despite having extensively used similar mechanisms in other code bases.) This gives the following usage: template::value)> void foo(T x) { ... } and this for separate declaration and definition. template::value)> void foo(T x); // later separate definition template::value)> void foo(T x) { ... } (An alternative would be to just drop the macro usage entirely, at least in the separate definition case, and just accept the additional syntactic complexity. I'm not proposing that.) (Since I was touching the file anyway, I also improved some of the comments discussing details) Testing: mach5 tier1 This includes some new gtests for the macros. There aren't any current non-test uses of ENABLE_IF_SDEFN yet. ------------- Commit messages: - rename to ENABLE_IF_SDEFN - Add ENABLE_IF_PARAM, unit tests Changes: https://git.openjdk.java.net/jdk/pull/2129/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2129&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258853 Stats: 97 lines in 2 files changed: 85 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/2129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2129/head:pull/2129 PR: https://git.openjdk.java.net/jdk/pull/2129 From ddong at openjdk.java.net Mon Jan 18 14:00:42 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 18 Jan 2021 14:00:42 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: <0GQ4f8N7Ddv0bpiazsnfPydzLYN1gZdhHu42U3ZpMMc=.3dd4d732-c24a-4166-9d00-0b8e7e4b03e0@github.com> On Mon, 18 Jan 2021 08:04:38 GMT, Stefan Karlsson wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor based on comments > > src/hotspot/share/utilities/ticks.hpp line 241: > >> 239: friend class GCTimerTest; >> 240: friend class CompilerEvent; >> 241: friend class GCLocker; > > I don't think this should be needed. Fixed. > src/hotspot/share/gc/shared/gcLocker.cpp line 112: > >> 110: #if INCLUDE_JFR >> 111: if (EventGCLocker::is_enabled()) { >> 112: _needs_gc_start_timestamp = JfrTicks::now(); > > Do you really need to use JfrTicks instead of Ticks here? If not, could you remove all references and includes of JfrTicks? We usually use pass in Ticks when we send JFR events. Fixed. > src/hotspot/share/prims/whitebox.cpp line 44: > >> 42: #include "gc/shared/genArguments.hpp" >> 43: #include "gc/shared/genCollectedHeap.hpp" >> 44: #include "gc/shared/gcLocker.inline.hpp" > > Sort includes. Fixed. > src/hotspot/share/jfr/metadata/metadata.xml line 1080: > >> 1078: >> 1079: >> 1080: > > You add this between two Shenandoah events. Could you put it somewhere where it's not splitting up a group of events? Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From rkennke at openjdk.java.net Mon Jan 18 15:32:54 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 18 Jan 2021 15:32:54 GMT Subject: Integrated: 8259849: Shenandoah: Rename store-val to IU-barrier In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 18:19:09 GMT, Roman Kennke wrote: > We named the IU barriers StoreValEnqueueBarrier and various similar variations of this. Instead of naming it after how it's implemented, we should name it after its purpose: support IU-marking. It also looks confusing to have enqueue_barrier() and similar stuff, where no barrier is actually enqueued. > > The renaming was 100% mechanical. > > Testing: > - [x] hotspot_gc_shenandoah (x86_64, x86_32, aarch64) This pull request has now been integrated. Changeset: e60c9926 Author: Roman Kennke URL: https://git.openjdk.java.net/jdk/commit/e60c9926 Stats: 131 lines in 26 files changed: 0 ins; 5 del; 126 mod 8259849: Shenandoah: Rename store-val to IU-barrier Reviewed-by: zgu, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/2104 From lutz.schmidt at sap.com Mon Jan 18 15:45:34 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 18 Jan 2021 15:45:34 +0000 Subject: [PING] RFR: 8259383: AsyncGetCallTrace() crashes sporadically Message-ID: <85ACAAAA-CA33-40A1-A251-D0672F0764E1@sap.com> Dear All, I would like to bring this RFR back to your attention. Thank you, Lutz ?On 11.01.21, 19:45, "hotspot-dev on behalf of Lutz Schmidt" wrote: Hi, may I please ask the community to review this small fix? It closes another hole in AsyncGetCallTrace(). Thanks a lot! Lutz ------------- Commit messages: - 8259383: AsyncGetCallTrace() crashes sporadically Changes: https://git.openjdk.java.net/jdk/pull/2032/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2032&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259383 Stats: 27 lines in 1 file changed: 22 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2032.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2032/head:pull/2032 PR: https://git.openjdk.java.net/jdk/pull/2032 From ysuenaga at openjdk.java.net Tue Jan 19 01:37:49 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 19 Jan 2021 01:37:49 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> Message-ID: On Fri, 15 Jan 2021 09:59:08 GMT, Markus Gr?nlund wrote: > As you say: "move throwing events into HotSpot makes big change" - I agree and Erik has already stated that many have tried already to make this kind of change, but attempts have faltered because the impact / disruptions are unclear. Do you fully understand the consequences of how it will change the way users work with exceptions in JFR? If C2 optimizations now start to remove exception sites that were previously reported? I believe the user who hooks JavaErrorThrow event wants to know the occurrence of OOME. Let's think about the user who want to restart the system automatically if the fatal error happens. The user defines OOME as an event that should be restarted and monitored by remote recording. If JavaErrorThrow event for OOME cannot be hooked, it is meaningless. I understand all `Throwable` s cannot be hooked due to C2 optimization, but most of them should be hooked. They should be hooked as well as unified logging at least, and we can do it like this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From iklam at openjdk.java.net Tue Jan 19 04:36:12 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 19 Jan 2021 04:36:12 GMT Subject: Integrated: 8258004: Remove unnecessary inclusion of vm_version.hpp In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 22:13:50 GMT, Ioi Lam wrote: > In the x86 build, vm_version.hpp includes vm_version_x86.hpp, which is over 1000 lines due to the complexity of the Intel architecture. > > vm_version.hpp is unnecessarily included by these popular header files: > - assembler.hpp > - assembler_x86.hpp > - threadLocalAllocBuffer.hpp > > Before this change, there are 822 .o files that include vm_version.hpp. Refactoring the code reduces the number to 220 .o files. > > Review note: the main change is in the 3 files mentioned above. All the other files had to be fixed because they were using declarations from vm_version.hpp without including it explicitly. This pull request has now been integrated. Changeset: 492bebc7 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/492bebc7 Stats: 157 lines in 30 files changed: 81 ins; 49 del; 27 mod 8258004: Remove unnecessary inclusion of vm_version.hpp Reviewed-by: dholmes, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/2105 From iklam at openjdk.java.net Tue Jan 19 04:36:09 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 19 Jan 2021 04:36:09 GMT Subject: RFR: 8258004: Remove unnecessary inclusion of vm_version.hpp [v2] In-Reply-To: References: Message-ID: > In the x86 build, vm_version.hpp includes vm_version_x86.hpp, which is over 1000 lines due to the complexity of the Intel architecture. > > vm_version.hpp is unnecessarily included by these popular header files: > - assembler.hpp > - assembler_x86.hpp > - threadLocalAllocBuffer.hpp > > Before this change, there are 822 .o files that include vm_version.hpp. Refactoring the code reduces the number to 220 .o files. > > Review note: the main change is in the 3 files mentioned above. All the other files had to be fixed because they were using declarations from vm_version.hpp without including it explicitly. Ioi Lam 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 8258004-unnecessary-inclusion-vm_version.hpp - 8258004: Remove unnecessary inclusion of vm_version.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2105/files - new: https://git.openjdk.java.net/jdk/pull/2105/files/97710ade..c4924e55 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2105&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2105&range=00-01 Stats: 11983 lines in 108 files changed: 1328 ins; 9224 del; 1431 mod Patch: https://git.openjdk.java.net/jdk/pull/2105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2105/head:pull/2105 PR: https://git.openjdk.java.net/jdk/pull/2105 From iklam at openjdk.java.net Tue Jan 19 04:36:11 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 19 Jan 2021 04:36:11 GMT Subject: RFR: 8258004: Remove unnecessary inclusion of vm_version.hpp [v2] In-Reply-To: <9rc4uAranVYWq-ekWYEUcRGbxPytq4ITgaRkk3mRyCs=.140c39dc-d6b1-4990-9fe8-06862dbd5175@github.com> References: <9rc4uAranVYWq-ekWYEUcRGbxPytq4ITgaRkk3mRyCs=.140c39dc-d6b1-4990-9fe8-06862dbd5175@github.com> Message-ID: On Mon, 18 Jan 2021 08:13:45 GMT, Stefan Karlsson wrote: >> Ioi Lam 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 8258004-unnecessary-inclusion-vm_version.hpp >> - 8258004: Remove unnecessary inclusion of vm_version.hpp > > Marked as reviewed by stefank (Reviewer). Thanks @stefank and @dholmes-ora for the review. Merged with latest repo and retested with build tiers 1-5. ------------- PR: https://git.openjdk.java.net/jdk/pull/2105 From jwilhelm at openjdk.java.net Tue Jan 19 05:03:13 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 19 Jan 2021 05:03:13 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" - 8259574: SIGSEGV in BFSClosure::closure_impl - 8259641: C2: assert(early->dominates(LCA)) failed: early is high enough The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2137&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2137&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2137/files Stats: 99 lines in 5 files changed: 95 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2137.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2137/head:pull/2137 PR: https://git.openjdk.java.net/jdk/pull/2137 From jwilhelm at openjdk.java.net Tue Jan 19 05:46:51 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 19 Jan 2021 05:46:51 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 04:58:45 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: a1a851b6 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/a1a851b6 Stats: 99 lines in 5 files changed: 95 ins; 1 del; 3 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2137 From stuefe at openjdk.java.net Tue Jan 19 07:09:52 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 19 Jan 2021 07:09:52 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:59:02 GMT, Stefan Johansson wrote: >> One also can set nr_overcommit_hugepages>0 and have a "dynamic" large page pool this way, even with nr_hugepages=0. Moreover, these settings can change during the lifetime of the VM. I would not bother adding too much logic here. Allocating huge pages may or may not fail anyway and the VM has to be prepared to deal with failure. Just my 5c. > > The "dynamic part" might make this actually being "too much logic", otherwise if feels like a pretty reasonable check. The fact that huge pages can be added during the runtime of the JVM doesn't feel like a big problem, since most large reservations are done at startup. > > But you might be right, since we have to handle the case of a failed mapping, it might not be to big of a problem trying all possible page sizes. I'm actually using nr_overcommit_hugepages alot (has been a tip by Per Liden) since its so convenient. As for allocation at startup, I plan on making Metaspace large-page-able again at some point in the future; that would mean larger LP allocations may happen later in VM life too. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From sjohanss at openjdk.java.net Tue Jan 19 09:00:45 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 19 Jan 2021 09:00:45 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: Message-ID: <-XDDOuZ587CjzTAMiKepvJ-siKe6kSCUiNJwQ_VZS6I=.19e9fc03-e93d-4ccd-ace1-5b844ad7caa7@github.com> On Tue, 19 Jan 2021 07:06:48 GMT, Thomas Stuefe wrote: >> The "dynamic part" might make this actually being "too much logic", otherwise if feels like a pretty reasonable check. The fact that huge pages can be added during the runtime of the JVM doesn't feel like a big problem, since most large reservations are done at startup. >> >> But you might be right, since we have to handle the case of a failed mapping, it might not be to big of a problem trying all possible page sizes. > > I'm actually using nr_overcommit_hugepages alot (has been a tip by Per Liden) since its so convenient. As for allocation at startup, I plan on making Metaspace large-page-able again at some point in the future; that would mean larger LP allocations may happen later in VM life too. Ok, maybe I should try it out as well :) Regarding allocation at startup vs later, is the plan to make new reservations during the run or supporting uncommit of large pages. Currently if a `ReservedSpace` is special (uses large pages), uncommit is disabled and all pages are committed up front. Is your plan to change this or will it work by adding and removing `ReservedSpace`s. I have not had time to look at the new `Metaspace` implementation in detail yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From stuefe at openjdk.java.net Tue Jan 19 09:27:50 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 19 Jan 2021 09:27:50 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: <-XDDOuZ587CjzTAMiKepvJ-siKe6kSCUiNJwQ_VZS6I=.19e9fc03-e93d-4ccd-ace1-5b844ad7caa7@github.com> References: <-XDDOuZ587CjzTAMiKepvJ-siKe6kSCUiNJwQ_VZS6I=.19e9fc03-e93d-4ccd-ace1-5b844ad7caa7@github.com> Message-ID: On Tue, 19 Jan 2021 08:57:42 GMT, Stefan Johansson wrote: >> I'm actually using nr_overcommit_hugepages alot (has been a tip by Per Liden) since its so convenient. As for allocation at startup, I plan on making Metaspace large-page-able again at some point in the future; that would mean larger LP allocations may happen later in VM life too. > > Ok, maybe I should try it out as well :) > > Regarding allocation at startup vs later, is the plan to make new reservations during the run or supporting uncommit of large pages. Currently if a `ReservedSpace` is special (uses large pages), uncommit is disabled and all pages are committed up front. Is your plan to change this or will it work by adding and removing `ReservedSpace`s. I have not had time to look at the new `Metaspace` implementation in detail yet. As it is now in my head, using LP on Metaspace would disable on-demand uncommitting (there is a second stage release of memory unaffected by this, where ReservedSpace segments get unmapped, but that is rare due to fragmentation. Due to the large page size uncommit on demand would be much less effective anyway than with normal pages. I am vaguely aware however of someones (yours?) experiments with "soft uncommit" - madvise(MADV_FREE) - and was planning on playing around with this too. Depending on how that plays out it may be a way to get uncommit-like behavior for large pages. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From stuefe at openjdk.java.net Tue Jan 19 10:38:55 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 19 Jan 2021 10:38:55 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: <-XDDOuZ587CjzTAMiKepvJ-siKe6kSCUiNJwQ_VZS6I=.19e9fc03-e93d-4ccd-ace1-5b844ad7caa7@github.com> Message-ID: On Tue, 19 Jan 2021 09:31:43 GMT, Stefan Johansson wrote: >> As it is now in my head, using LP on Metaspace would disable on-demand uncommitting (there is a second stage release of memory unaffected by this, where ReservedSpace segments get unmapped, but that is rare due to fragmentation. Due to the large page size uncommit on demand would be much less effective anyway than with normal pages. >> >> I am vaguely aware however of someones (yours?) experiments with "soft uncommit" - madvise(MADV_FREE) - and was planning on playing around with this too. Depending on how that plays out it may be a way to get uncommit-like behavior for large pages. > > Yes, we've done some experiments using `madvise`. Some results looked promising and others a bit surprising, but I didn't actually looked at how it would affect `HUGETLB` large pages. But yes, it might be a way to get better behavior for large pages. Maybe we also could take another look at the "never-remap-hugepages" rule added with JDK-8007074. I understand why stefank did that, but maybe if one added safety measures (eg before remapping making sure that we have enough huge pages in the pool with a large margin) and combined with a switch it would be safe enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From sjohanss at openjdk.java.net Tue Jan 19 10:38:55 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 19 Jan 2021 10:38:55 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: <-XDDOuZ587CjzTAMiKepvJ-siKe6kSCUiNJwQ_VZS6I=.19e9fc03-e93d-4ccd-ace1-5b844ad7caa7@github.com> Message-ID: On Tue, 19 Jan 2021 09:25:19 GMT, Thomas Stuefe wrote: >> Ok, maybe I should try it out as well :) >> >> Regarding allocation at startup vs later, is the plan to make new reservations during the run or supporting uncommit of large pages. Currently if a `ReservedSpace` is special (uses large pages), uncommit is disabled and all pages are committed up front. Is your plan to change this or will it work by adding and removing `ReservedSpace`s. I have not had time to look at the new `Metaspace` implementation in detail yet. > > As it is now in my head, using LP on Metaspace would disable on-demand uncommitting (there is a second stage release of memory unaffected by this, where ReservedSpace segments get unmapped, but that is rare due to fragmentation. Due to the large page size uncommit on demand would be much less effective anyway than with normal pages. > > I am vaguely aware however of someones (yours?) experiments with "soft uncommit" - madvise(MADV_FREE) - and was planning on playing around with this too. Depending on how that plays out it may be a way to get uncommit-like behavior for large pages. Yes, we've done some experiments using `madvise`. Some results looked promising and others a bit surprising, but I didn't actually looked at how it would affect `HUGETLB` large pages. But yes, it might be a way to get better behavior for large pages. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From sjohanss at openjdk.java.net Tue Jan 19 10:38:55 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 19 Jan 2021 10:38:55 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: <-XDDOuZ587CjzTAMiKepvJ-siKe6kSCUiNJwQ_VZS6I=.19e9fc03-e93d-4ccd-ace1-5b844ad7caa7@github.com> Message-ID: On Tue, 19 Jan 2021 09:25:19 GMT, Thomas Stuefe wrote: >> Ok, maybe I should try it out as well :) >> >> Regarding allocation at startup vs later, is the plan to make new reservations during the run or supporting uncommit of large pages. Currently if a `ReservedSpace` is special (uses large pages), uncommit is disabled and all pages are committed up front. Is your plan to change this or will it work by adding and removing `ReservedSpace`s. I have not had time to look at the new `Metaspace` implementation in detail yet. > > As it is now in my head, using LP on Metaspace would disable on-demand uncommitting (there is a second stage release of memory unaffected by this, where ReservedSpace segments get unmapped, but that is rare due to fragmentation. Due to the large page size uncommit on demand would be much less effective anyway than with normal pages. > > I am vaguely aware however of someones (yours?) experiments with "soft uncommit" - madvise(MADV_FREE) - and was planning on playing around with this too. Depending on how that plays out it may be a way to get uncommit-like behavior for large pages. Yes, we've done some experiments using `madvise`. Some results looked promising and others a bit surprising, but I didn't actually looked at how it would affect `HUGETLB` large pages. But yes, it might be a way to get better behavior for large pages. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From sjohanss at openjdk.java.net Tue Jan 19 10:59:52 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 19 Jan 2021 10:59:52 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: <-XDDOuZ587CjzTAMiKepvJ-siKe6kSCUiNJwQ_VZS6I=.19e9fc03-e93d-4ccd-ace1-5b844ad7caa7@github.com> Message-ID: On Tue, 19 Jan 2021 10:35:47 GMT, Thomas Stuefe wrote: >> Yes, we've done some experiments using `madvise`. Some results looked promising and others a bit surprising, but I didn't actually looked at how it would affect `HUGETLB` large pages. But yes, it might be a way to get better behavior for large pages. > > Maybe we also could take another look at the "never-remap-hugepages" rule added with JDK-8007074. I understand why stefank did that, but maybe if one added safety measures (eg before remapping making sure that we have enough huge pages in the pool with a large margin) and combined with a switch it would be safe enough. Yes, and maybe take another look at if +UseLargePages could mean use THP, currently THP is only used if explicitly set and I'm not sure that is true with newer Linux kernels. We even have a comment about this: // Don't try UseTransparentHugePages since there are known // performance issues with it turned on. This might change in the future. UseTransparentHugePages = false; ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From shade at openjdk.java.net Tue Jan 19 12:09:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 19 Jan 2021 12:09:00 GMT Subject: RFR: 8259978: PPC64 builds broken after JDK-8258004 Message-ID: `nativeInst_ppc.hpp` uses `TrapBasedRangeChecks`, so needs the explicit import of `c2_globals.hpp`. `method.cpp` uses `VMVersion`, so needs the appropriate direct include. Additional testing: - [x] Linux ppc64 cross-compile {release, fastdebug, slowdebug} ------------- Commit messages: - 8259978: PPC64 builds broken after JDK-8258004 Changes: https://git.openjdk.java.net/jdk/pull/2143/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2143&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259978 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2143.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2143/head:pull/2143 PR: https://git.openjdk.java.net/jdk/pull/2143 From mbaesken at openjdk.java.net Tue Jan 19 12:15:02 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 19 Jan 2021 12:15:02 GMT Subject: RFR: JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name Message-ID: On some platforms like bsd/mac, we call dll_address_to_library_name with a buffer parameter (e.g. char dli_fname[MAXPATHLEN]; ) that has uninitialized content. This is usually no problem because dll_address_to_library_name fills the array, but on some codepaths it seems not to be the case. See also this related sonar issue : https://sonarcloud.io/project/issues?id=jdk&open=AXaE0drk8L9hkQskGEXZ&resolved=false&types=BUG ------------- Commit messages: - JDK-8259843 Changes: https://git.openjdk.java.net/jdk/pull/2144/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2144&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259843 Stats: 11 lines in 4 files changed: 6 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2144.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2144/head:pull/2144 PR: https://git.openjdk.java.net/jdk/pull/2144 From lucy at openjdk.java.net Tue Jan 19 15:49:47 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 19 Jan 2021 15:49:47 GMT Subject: RFR: JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 12:08:05 GMT, Matthias Baesken wrote: > On some platforms like bsd/mac, we call dll_address_to_library_name with a buffer parameter (e.g. char dli_fname[MAXPATHLEN]; ) that has uninitialized content. > This is usually no problem because dll_address_to_library_name fills the array, but on some codepaths it seems not to be the case. > > See also this related sonar issue : > https://sonarcloud.io/project/issues?id=jdk&open=AXaE0drk8L9hkQskGEXZ&resolved=false&types=BUG The changes look good to me. linuxppcle build error unrelated. Addressed by JDK-8259978. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2144 From lucy at openjdk.java.net Tue Jan 19 15:54:48 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 19 Jan 2021 15:54:48 GMT Subject: RFR: 8259978: PPC64 builds broken after JDK-8258004 In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 12:03:03 GMT, Aleksey Shipilev wrote: > `nativeInst_ppc.hpp` uses `TrapBasedRangeChecks`, so needs the explicit import of `c2_globals.hpp`. > `method.cpp` uses `VMVersion`, so needs the appropriate direct include. > > Additional testing: > - [x] Linux ppc64 cross-compile {release, fastdebug, slowdebug} Changes look good to me. Thanks for fixing. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2143 From iklam at openjdk.java.net Tue Jan 19 16:17:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 19 Jan 2021 16:17:52 GMT Subject: RFR: 8259978: PPC64 builds broken after JDK-8258004 In-Reply-To: References: Message-ID: <640EFJJtaoflJuNfWe578Z3uuccmJpw6SNPQbwkOQT4=.05d26c59-ba78-4e99-b1cf-2928a5e03cd5@github.com> On Tue, 19 Jan 2021 12:03:03 GMT, Aleksey Shipilev wrote: > `nativeInst_ppc.hpp` uses `TrapBasedRangeChecks`, so needs the explicit import of `c2_globals.hpp`. > `method.cpp` uses `VMVersion`, so needs the appropriate direct include. > > Additional testing: > - [x] Linux ppc64 cross-compile {release, fastdebug, slowdebug} Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2143 From shade at openjdk.java.net Tue Jan 19 18:36:44 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 19 Jan 2021 18:36:44 GMT Subject: Integrated: 8259978: PPC64 builds broken after JDK-8258004 In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 12:03:03 GMT, Aleksey Shipilev wrote: > `nativeInst_ppc.hpp` uses `TrapBasedRangeChecks`, so needs the explicit import of `c2_globals.hpp`. > `method.cpp` uses `VMVersion`, so needs the appropriate direct include. > > Additional testing: > - [x] Linux ppc64 cross-compile {release, fastdebug, slowdebug} This pull request has now been integrated. Changeset: 3edf393d Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/3edf393d Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod 8259978: PPC64 builds broken after JDK-8258004 Reviewed-by: lucy, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/2143 From iklam at openjdk.java.net Tue Jan 19 20:13:10 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 19 Jan 2021 20:13:10 GMT Subject: RFR: 8259214: MetaspaceClosure support for Arrays of MetaspaceObj [v4] In-Reply-To: References: Message-ID: > Currently, `MetaspaceClosure::push` supports only the following variants: > > MetaspaceClosure* it = ...; > Klass* o = ...; it->push(&o); > Array* a1 = ...; it->push(&a1); > Array* a2 = ...; it->push(&a2); > > In Valhalla, support is needed for the following variant (Annotation is a subtype of MetaspaceObj): > > Array* a3 = ...; it->push(&a3); > > This change will allow CDS to make a copy of this array, as well as relocating all the pointers embedded in the elements of this array. See a test case in test_metaspaceClosure.cpp. > > I also cleaned up the code (with help from @kimbarrett) to use SFINAE to dispatch from `MetaspaceClosure::push` to the different subtypes of `MetaspaceClosure::Ref`. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Remove RefMatcher and go back to overloaded template functions for push(...) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1995/files - new: https://git.openjdk.java.net/jdk/pull/1995/files/0f7cf37a..84074148 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1995&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1995&range=02-03 Stats: 133 lines in 1 file changed: 62 ins; 68 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1995.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1995/head:pull/1995 PR: https://git.openjdk.java.net/jdk/pull/1995 From MRasmussen at perforce.com Tue Jan 19 20:27:40 2021 From: MRasmussen at perforce.com (Michael Rasmussen) Date: Tue, 19 Jan 2021 20:27:40 +0000 Subject: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 Message-ID: Hi, I noticed a regression in the verification of sealed classes, that I've narrowed down to happening between jdk-16+27 and jdk-16+28. Retransforming or redefining a sealed class can lead to a JVMTI_ERROR_FAILS_VERIFICATION, with Exception (0x00000000feb820a0), even though the class actually does that. I've tried to investigate the reason, and from what I can tell, it boils down to the check in InstanceKlass::has_as_permitted_subclass. In jdk-16+27, this method always seems to take the Symbol branch (_constants->tag_at(cp_index).is_klass() is false). But for jdk-16+28, it takes the Klass branch after the classes are loaded, and from what I can tell the (k2 == k) comparison can then fail during the redefinition since the Klass stored in the _permitted_subclasses is not the same as the one being verified, as a new InstanceKlass is allocated for the stream parser. Unfortunately, I haven't been able to produce a small self-contained test example, but I can reliably reproduce it while developing JRebel (which utilizes class retransformation), but hopefully the above is at least helpful in finding the issue and fixing it. /Michael This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. From harold.seigel at oracle.com Tue Jan 19 20:52:27 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 19 Jan 2021 20:52:27 +0000 Subject: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 In-Reply-To: References: Message-ID: Hi Michael, I entered bug https://bugs.openjdk.java.net/browse/JDK-8260009 for this problem. Thank you for reporting it. Harold ________________________________ From: hotspot-dev on behalf of Michael Rasmussen Sent: Tuesday, January 19, 2021 3:27 PM To: hotspot-dev at openjdk.java.net Subject: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 Hi, I noticed a regression in the verification of sealed classes, that I've narrowed down to happening between jdk-16+27 and jdk-16+28. Retransforming or redefining a sealed class can lead to a JVMTI_ERROR_FAILS_VERIFICATION, with Exception (0x00000000feb820a0), even though the class actually does that. I've tried to investigate the reason, and from what I can tell, it boils down to the check in InstanceKlass::has_as_permitted_subclass. In jdk-16+27, this method always seems to take the Symbol branch (_constants->tag_at(cp_index).is_klass() is false). But for jdk-16+28, it takes the Klass branch after the classes are loaded, and from what I can tell the (k2 == k) comparison can then fail during the redefinition since the Klass stored in the _permitted_subclasses is not the same as the one being verified, as a new InstanceKlass is allocated for the stream parser. Unfortunately, I haven't been able to produce a small self-contained test example, but I can reliably reproduce it while developing JRebel (which utilizes class retransformation), but hopefully the above is at least helpful in finding the issue and fixing it. /Michael This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. From cjplummer at openjdk.java.net Tue Jan 19 22:26:47 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 19 Jan 2021 22:26:47 GMT Subject: RFR: 8259383: AsyncGetCallTrace() crashes sporadically In-Reply-To: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com> References: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com> Message-ID: On Mon, 11 Jan 2021 18:39:41 GMT, Lutz Schmidt wrote: > Hi, > may I please ask the community to review this small fix? It closes another hole in AsyncGetCallTrace(). > Thanks a lot! > Lutz The changes look ok to me. I think it would be good to get someone from the compiler team to verify your reasoning here. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2032 From lutz.schmidt at sap.com Tue Jan 19 22:57:02 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 19 Jan 2021 22:57:02 +0000 Subject: 8259383: AsyncGetCallTrace() crashes sporadically Message-ID: <6007763D-3C05-49C5-AF11-13453EF04101@sap.com> Hi Chris, thank you for your review. Per your request/recommendation, I'll cross-post to hotspot-compiler-dev. On the other hand, I've been working recently in just that corner of CodeHeap/CodeCache. As the access to VM data structures via AsyncGetCallTrace() is asynchronous (the name suggests it), you may see inconsistent states. You have to deal with such inconsistencies. Furthermore, a direct colleague of mine did in-depth research on Async Profiler. I consulted with him. Anyway, thanks again! Lutz ?On 19.01.21, 23:26, "hotspot-dev on behalf of Chris Plummer" wrote: On Mon, 11 Jan 2021 18:39:41 GMT, Lutz Schmidt wrote: > Hi, > may I please ask the community to review this small fix? It closes another hole in AsyncGetCallTrace(). > Thanks a lot! > Lutz The changes look ok to me. I think it would be good to get someone from the compiler team to verify your reasoning here. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2032 From github.com+1749416+apangin at openjdk.java.net Wed Jan 20 03:44:55 2021 From: github.com+1749416+apangin at openjdk.java.net (Andrei Pangin) Date: Wed, 20 Jan 2021 03:44:55 GMT Subject: RFR: 8259383: AsyncGetCallTrace() crashes sporadically In-Reply-To: References: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com> Message-ID: On Tue, 19 Jan 2021 22:23:38 GMT, Chris Plummer wrote: >> Hi, >> may I please ask the community to review this small fix? It closes another hole in AsyncGetCallTrace(). >> Thanks a lot! >> Lutz > > The changes look ok to me. I think it would be good to get someone from the compiler team to verify your reasoning here. Hi Lutz, Thank you for working on this issue. I'm not a formal OpenJDK Reviewer, but as an author of async-profiler project (which heavily relies on AsyncGetCallTrace), I'm more or less familiar with this code. Let me leave a few comments. 1. The statement `if (candidate.pc() != NULL) return false;` looks a bit odd to me. When a profiler calls AsyncGetCallTrace, pc of the initial frame is obtained from a signal context, and it is never NULL. Returning false when pc != NULL basically invalidates the entire `if (fr->cb() == NULL)` branch. If this was intended, the branch could be simplified. 2. At the same time, returning false whenever cb == NULL, discards a fair amount of valid stack traces, e.g. when a runtime function is called from Java without switching to in_vm state. I guess, the original intention of that loop was to handle such cases, but, as you noticed, it does not currently work well because of the assertions. I'd rather prefer revising the logic of that loop then instead of dropping all those valid samples. 3. What I don't really understand from the bug report is why `if (fr->cb() == NULL)` branch is executed at all in this particular example. According to the stack trace from the crash dump, the top frame (before a signal handler) is `ThreadCritical::~ThreadCritical()`. This means, a thread is in_vm state, and its last_Java_frame should have been set. In this case AsyncGetCallTrace prefers to take last_Java_frame, and thus cb should be non-NULL. Another suspicious thing is that a frame below `ThreadCritical::~ThreadCritical()` is not a C frame. This cannot normally happen (the execution is in the middle of `ThreadCritical::~ThreadCritical()`, where the stack frame is consistent). These facts make me think something bad has already happened with the stack earlier, and the failed guarantee is probably just one manifestation of a bigger problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/2032 From iklam at openjdk.java.net Wed Jan 20 04:47:04 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 20 Jan 2021 04:47:04 GMT Subject: RFR: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h Message-ID: jvm.h is over 1000 lines long. It is included by 940 out of 1000 HotSpot .o files. However, most of the HotSpot source files just use a small fraction of jvm.h: - the jio_xxxprintf() functions - the JVM_RECOGNIZED_XXX_MODIFIERS defines We should move these two parts into jvm_io.h and jvm_constants.h. This reduces the files that include jvm.h to about 82 files. Build time of HotSpot is reduced by about 0.4%. Testing: mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- Commit messages: - 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h Changes: https://git.openjdk.java.net/jdk/pull/2154/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2154&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259894 Stats: 248 lines in 16 files changed: 145 ins; 86 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/2154.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2154/head:pull/2154 PR: https://git.openjdk.java.net/jdk/pull/2154 From dholmes at openjdk.java.net Wed Jan 20 06:12:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 20 Jan 2021 06:12:55 GMT Subject: RFR: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 04:33:56 GMT, Ioi Lam wrote: > jvm.h is over 1000 lines long. It is included by 940 out of 1000 HotSpot .o files. However, most of the HotSpot source files just use a small fraction of jvm.h: > > - the jio_xxxprintf() functions > - the JVM_RECOGNIZED_XXX_MODIFIERS defines > > We should move these two parts into jvm_io.h and jvm_constants.h. This reduces the files that include jvm.h to about 82 files. Build time of HotSpot is reduced by about 0.4%. > > Testing: mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Hi Ioi, This was less noisy than I expected but I have a few comments on it. Comments on jvm_constants.h apply to jvm_io.h too. Thanks, David src/hotspot/share/include/jvm_constants.h line 8: > 6: * under the terms of the GNU General Public License version 2 only, as > 7: * published by the Free Software Foundation. Oracle designates this > 8: * particular file as subject to the "Classpath" exception as provided Classpath exception is wrong here - that is only for (mainly Java) sources that applications may link against. It's existing use in jvm.h is incorrect. src/hotspot/share/include/jvm_constants.h line 26: > 24: */ > 25: > 26: #ifndef _JAVASOFT_JVM_CONSTANTS_H_ We don't need to keep the legacy JAVASOFT defines. src/hotspot/share/logging/logSelection.cpp line 25: > 23: */ > 24: #include "precompiled.hpp" > 25: #include "jvm.h" Not jvm_io.h ?? src/hotspot/share/include/jvm.h line 34: > 32: #include "jvm_md.h" > 33: #include "jvm_constants.h" > 34: #include "jvm_io.h" Note that the comment block starting at line 40 needs to be updated now you have refactored things. src/hotspot/share/classfile/javaClasses.cpp line 26: > 24: > 25: #include "precompiled.hpp" > 26: #include "jvm.h" Does this really need jvm.h or just jvm_constants.h and jvm_io.h? src/hotspot/share/classfile/vmIntrinsics.cpp line 26: > 24: > 25: #include "precompiled.hpp" > 26: #include "jvm.h" Does this really need jvm.h or just jvm_constants.h and jvm_io.h? src/hotspot/share/runtime/os.hpp line 28: > 26: #define SHARE_RUNTIME_OS_HPP > 27: > 28: #include "jvm_md.h" jvm_md.h should not be included directly by any file - it is an internal implementation detail. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2154 From dholmes at openjdk.java.net Wed Jan 20 07:21:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 20 Jan 2021 07:21:53 GMT Subject: RFR: JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 12:08:05 GMT, Matthias Baesken wrote: > On some platforms like bsd/mac, we call dll_address_to_library_name with a buffer parameter (e.g. char dli_fname[MAXPATHLEN]; ) that has uninitialized content. > This is usually no problem because dll_address_to_library_name fills the array, but on some codepaths it seems not to be the case. > > See also this related sonar issue : > https://sonarcloud.io/project/issues?id=jdk&open=AXaE0drk8L9hkQskGEXZ&resolved=false&types=BUG Hi Matthias, Seems okay. One query below. Thanks, David src/hotspot/share/runtime/frame.cpp line 543: > 541: bool found; > 542: > 543: if (buf == NULL || buflen < 1) return; Can this not just be an assert: buf != NULL && buflen > 0 ? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2144 From ysuenaga at openjdk.java.net Wed Jan 20 07:57:05 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 20 Jan 2021 07:57:05 GMT Subject: RFR: 8260025: HotSpot cannot identify Zen (family 17h) processor Message-ID: HotSpot cannot identify Zen (family 17h) processor. You can see this problem in flight record as below: java -XX:StartFlightRecording=filename=test.jfr --version `(null)` in `cpu` and `` in `Family` should be `Zen`. $ jfr print --events jdk.CPUInformation test.jfr jdk.CPUInformation { startTime = 15:59:37.207 cpu = "AMD (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A AMD64" description = "Brand: AMD Ryzen 3 3300X 4-Core Processor , Vendor: AuthenticAMD Family: (0x17), Model: (0x71), Stepping: 0x0 Ext. family: 0x8, Ext. model: 0x7, Type: 0x0, Signature: 0x00870f10 Features: ebx: 0x00020800, ecx: 0xfed83203, edx: 0x178bfbff Ext. features: eax: 0x00870f10, ebx: 0x20000000, ecx: 0x004003f3, edx: 0x2fd3fbff Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Hyper Threading, Streaming SIMD Extensions 3, PCLMULQDQ, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, MOVBE, Popcount instruction, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Core multi-processor leagacy mode, Advanced Bit Manipulations: LZCNT, SSE4A: MOVNTSS, MOVNTSD, EXTRQ, INSERTQ, Misaligned SSE mode, SYSCALL/SYSRET, Execute Disab le Bit, RDTSCP, Intel 64 Architecture" sockets = 1 cores = 2 hwThreads = 2 } It is caused by missing comma after `Opteron QC/Phenom`. So I think the fix is trivial. ------------- Commit messages: - 8260025: HotSpot cannot identify Zen (family 17h) processor Changes: https://git.openjdk.java.net/jdk/pull/2158/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2158&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260025 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2158.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2158/head:pull/2158 PR: https://git.openjdk.java.net/jdk/pull/2158 From dholmes at openjdk.java.net Wed Jan 20 08:06:50 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 20 Jan 2021 08:06:50 GMT Subject: RFR: 8260025: HotSpot cannot identify Zen (family 17h) processor In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 07:51:29 GMT, Yasumasa Suenaga wrote: > HotSpot cannot identify Zen (family 17h) processor. You can see this problem in flight record as below: > > java -XX:StartFlightRecording=filename=test.jfr --version > > `(null)` in `cpu` and `` in `Family` should be `Zen`. > > $ jfr print --events jdk.CPUInformation test.jfr > jdk.CPUInformation { > startTime = 15:59:37.207 > cpu = "AMD (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A AMD64" > description = "Brand: AMD Ryzen 3 3300X 4-Core Processor , Vendor: AuthenticAMD > Family: (0x17), Model: (0x71), Stepping: 0x0 > Ext. family: 0x8, Ext. model: 0x7, Type: 0x0, Signature: 0x00870f10 > Features: ebx: 0x00020800, ecx: 0xfed83203, edx: 0x178bfbff > Ext. features: eax: 0x00870f10, ebx: 0x20000000, ecx: 0x004003f3, edx: 0x2fd3fbff > Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Hyper Threading, Streaming SIMD Extensions 3, PCLMULQDQ, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, MOVBE, Popcount instruction, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Core multi-processor leagacy mode, Advanced Bit Manipulations: LZCNT, SSE4A: MOVNTSS, MOVNTSD, EXTRQ, INSERTQ, Misaligned SSE mode, SYSCALL/SYSRET, Execute Dis able Bit, RDTSCP, Intel 64 Architecture" > sockets = 1 > cores = 2 > hwThreads = 2 > } > > It is caused by missing comma after `Opteron QC/Phenom`. So I think the fix is trivial. Hi Yasumasa, You should have led with the fact this is caused by a missing comma! IIUC this will shorten the array by one entry and so Zen will be in the wrong position. Looks good and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2158 From stuefe at openjdk.java.net Wed Jan 20 08:12:54 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 20 Jan 2021 08:12:54 GMT Subject: RFR: 8260025: HotSpot cannot identify Zen (family 17h) processor In-Reply-To: References: Message-ID: <_Ixqn4L7VMikZruoqcpjDf_kB7LoD-b7CnXLstwfy0A=.d3a08aa3-01f0-4c11-b733-b51804c9a653@github.com> On Wed, 20 Jan 2021 07:51:29 GMT, Yasumasa Suenaga wrote: > HotSpot cannot identify Zen (family 17h) processor. You can see this problem in flight record as below: > > java -XX:StartFlightRecording=filename=test.jfr --version > > `(null)` in `cpu` and `` in `Family` should be `Zen`. > > $ jfr print --events jdk.CPUInformation test.jfr > jdk.CPUInformation { > startTime = 15:59:37.207 > cpu = "AMD (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A AMD64" > description = "Brand: AMD Ryzen 3 3300X 4-Core Processor , Vendor: AuthenticAMD > Family: (0x17), Model: (0x71), Stepping: 0x0 > Ext. family: 0x8, Ext. model: 0x7, Type: 0x0, Signature: 0x00870f10 > Features: ebx: 0x00020800, ecx: 0xfed83203, edx: 0x178bfbff > Ext. features: eax: 0x00870f10, ebx: 0x20000000, ecx: 0x004003f3, edx: 0x2fd3fbff > Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Hyper Threading, Streaming SIMD Extensions 3, PCLMULQDQ, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, MOVBE, Popcount instruction, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Core multi-processor leagacy mode, Advanced Bit Manipulations: LZCNT, SSE4A: MOVNTSS, MOVNTSD, EXTRQ, INSERTQ, Misaligned SSE mode, SYSCALL/SYSRET, Execute Dis able Bit, RDTSCP, Intel 64 Architecture" > sockets = 1 > cores = 2 > hwThreads = 2 > } > > It is caused by missing comma after `Opteron QC/Phenom`. So I think the fix is trivial. Marked as reviewed by stuefe (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2158 From stuefe at openjdk.java.net Wed Jan 20 08:12:55 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 20 Jan 2021 08:12:55 GMT Subject: RFR: 8260025: HotSpot cannot identify Zen (family 17h) processor In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 08:03:25 GMT, David Holmes wrote: >> HotSpot cannot identify Zen (family 17h) processor. You can see this problem in flight record as below: >> >> java -XX:StartFlightRecording=filename=test.jfr --version >> >> `(null)` in `cpu` and `` in `Family` should be `Zen`. >> >> $ jfr print --events jdk.CPUInformation test.jfr >> jdk.CPUInformation { >> startTime = 15:59:37.207 >> cpu = "AMD (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A AMD64" >> description = "Brand: AMD Ryzen 3 3300X 4-Core Processor , Vendor: AuthenticAMD >> Family: (0x17), Model: (0x71), Stepping: 0x0 >> Ext. family: 0x8, Ext. model: 0x7, Type: 0x0, Signature: 0x00870f10 >> Features: ebx: 0x00020800, ecx: 0xfed83203, edx: 0x178bfbff >> Ext. features: eax: 0x00870f10, ebx: 0x20000000, ecx: 0x004003f3, edx: 0x2fd3fbff >> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Hyper Threading, Streaming SIMD Extensions 3, PCLMULQDQ, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, MOVBE, Popcount instruction, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Core multi-processor leagacy mode, Advanced Bit Manipulations: LZCNT, SSE4A: MOVNTSS, MOVNTSD, EXTRQ, INSERTQ, Misaligned SSE mode, SYSCALL/SYSRET, Execute Di sable Bit, RDTSCP, Intel 64 Architecture" >> sockets = 1 >> cores = 2 >> hwThreads = 2 >> } >> >> It is caused by missing comma after `Opteron QC/Phenom`. So I think the fix is trivial. > > Hi Yasumasa, > > You should have led with the fact this is caused by a missing comma! IIUC this will shorten the array by one entry and so Zen will be in the wrong position. > > Looks good and trivial. > > Thanks, > David Thanks, Yasumasa, good and trivial. ------------- PR: https://git.openjdk.java.net/jdk/pull/2158 From ysuenaga at openjdk.java.net Wed Jan 20 08:18:37 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 20 Jan 2021 08:18:37 GMT Subject: RFR: 8260025: HotSpot cannot identify Zen (family 17h) processor In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 08:03:25 GMT, David Holmes wrote: >> HotSpot cannot identify Zen (family 17h) processor. You can see this problem in flight record as below: >> >> java -XX:StartFlightRecording=filename=test.jfr --version >> >> `(null)` in `cpu` and `` in `Family` should be `Zen`. >> >> $ jfr print --events jdk.CPUInformation test.jfr >> jdk.CPUInformation { >> startTime = 15:59:37.207 >> cpu = "AMD (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A AMD64" >> description = "Brand: AMD Ryzen 3 3300X 4-Core Processor , Vendor: AuthenticAMD >> Family: (0x17), Model: (0x71), Stepping: 0x0 >> Ext. family: 0x8, Ext. model: 0x7, Type: 0x0, Signature: 0x00870f10 >> Features: ebx: 0x00020800, ecx: 0xfed83203, edx: 0x178bfbff >> Ext. features: eax: 0x00870f10, ebx: 0x20000000, ecx: 0x004003f3, edx: 0x2fd3fbff >> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Hyper Threading, Streaming SIMD Extensions 3, PCLMULQDQ, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, MOVBE, Popcount instruction, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Core multi-processor leagacy mode, Advanced Bit Manipulations: LZCNT, SSE4A: MOVNTSS, MOVNTSD, EXTRQ, INSERTQ, Misaligned SSE mode, SYSCALL/SYSRET, Execute Di sable Bit, RDTSCP, Intel 64 Architecture" >> sockets = 1 >> cores = 2 >> hwThreads = 2 >> } >> >> It is caused by missing comma after `Opteron QC/Phenom`. So I think the fix is trivial. > > Hi Yasumasa, > > You should have led with the fact this is caused by a missing comma! IIUC this will shorten the array by one entry and so Zen will be in the wrong position. > > Looks good and trivial. > > Thanks, > David Thanks @dholmes-ora and @tstuefe for the review! > You should have led with the fact this is caused by a missing comma! Do you mean we should change the subject like "Missing comma in VM_Version_Ext::_family_id_amd"? > IIUC this will shorten the array by one entry and so Zen will be in the wrong position. Yes, "Zen" was located at penultimate position, and NULL was set to the tail when I checked it on GDB. ------------- PR: https://git.openjdk.java.net/jdk/pull/2158 From mbaesken at openjdk.java.net Wed Jan 20 08:24:48 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 20 Jan 2021 08:24:48 GMT Subject: RFR: JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 06:25:50 GMT, David Holmes wrote: >> On some platforms like bsd/mac, we call dll_address_to_library_name with a buffer parameter (e.g. char dli_fname[MAXPATHLEN]; ) that has uninitialized content. >> This is usually no problem because dll_address_to_library_name fills the array, but on some codepaths it seems not to be the case. >> >> See also this related sonar issue : >> https://sonarcloud.io/project/issues?id=jdk&open=AXaE0drk8L9hkQskGEXZ&resolved=false&types=BUG > > src/hotspot/share/runtime/frame.cpp line 543: > >> 541: bool found; >> 542: >> 543: if (buf == NULL || buflen < 1) return; > > Can this not just be an assert: buf != NULL && buflen > 0 ? Hi David, I think a return would be clearer but an assert is "better than nothing" . Best regards, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/2144 From lucy at openjdk.java.net Wed Jan 20 08:32:52 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 20 Jan 2021 08:32:52 GMT Subject: RFR: JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 08:21:36 GMT, Matthias Baesken wrote: >> src/hotspot/share/runtime/frame.cpp line 543: >> >>> 541: bool found; >>> 542: >>> 543: if (buf == NULL || buflen < 1) return; >> >> Can this not just be an assert: buf != NULL && buflen > 0 ? > > Hi David, I think a return would be clearer but an assert is "better than nothing" . > > Best regards, Matthias With an assert, you assume this is a "cannot occur error". You should be pretty sure to have good test coverage to find all "illegal invocations" before letting a release build escape into the wild. ------------- PR: https://git.openjdk.java.net/jdk/pull/2144 From stuefe at openjdk.java.net Wed Jan 20 08:45:46 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 20 Jan 2021 08:45:46 GMT Subject: RFR: JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 08:29:59 GMT, Lutz Schmidt wrote: >> Hi David, I think a return would be clearer but an assert is "better than nothing" . >> >> Best regards, Matthias > > With an assert, you assume this is a "cannot occur error". You should be pretty sure to have good test coverage to find all "illegal invocations" before letting a release build escape into the wild. +1 for the assert. If you are worried about release, combine assert with release check: assert(buf && buflen > 1, "sanity"); if (buf == NULL || buflen < 1) return; Its what I usually do if I want to be super thorough. Sorry for the bikeshedding :) ------------- PR: https://git.openjdk.java.net/jdk/pull/2144 From mbaesken at openjdk.java.net Wed Jan 20 11:09:46 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 20 Jan 2021 11:09:46 GMT Subject: RFR: JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 08:42:23 GMT, Thomas Stuefe wrote: >> With an assert, you assume this is a "cannot occur error". You should be pretty sure to have good test coverage to find all "illegal invocations" before letting a release build escape into the wild. > > +1 for the assert. > If you are worried about release, combine assert with release check: > assert(buf && buflen > 1, "sanity"); > if (buf == NULL || buflen < 1) return; > Its what I usually do if I want to be super thorough. > Sorry for the bikeshedding :) Hi Thomas, I like your suggestion ; David are you fine with it ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2144 From david.holmes at oracle.com Wed Jan 20 12:04:58 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jan 2021 22:04:58 +1000 Subject: RFR: 8260025: HotSpot cannot identify Zen (family 17h) processor In-Reply-To: References: Message-ID: <969283ab-f6e5-27dc-ee3b-efbdf6187458@oracle.com> On 20/01/2021 6:18 pm, Yasumasa Suenaga wrote: > On Wed, 20 Jan 2021 08:03:25 GMT, David Holmes wrote: > >>> HotSpot cannot identify Zen (family 17h) processor. You can see this problem in flight record as below: >>> >>> java -XX:StartFlightRecording=filename=test.jfr --version >>> >>> `(null)` in `cpu` and `` in `Family` should be `Zen`. >>> >>> $ jfr print --events jdk.CPUInformation test.jfr >>> jdk.CPUInformation { >>> startTime = 15:59:37.207 >>> cpu = "AMD (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A AMD64" >>> description = "Brand: AMD Ryzen 3 3300X 4-Core Processor , Vendor: AuthenticAMD >>> Family: (0x17), Model: (0x71), Stepping: 0x0 >>> Ext. family: 0x8, Ext. model: 0x7, Type: 0x0, Signature: 0x00870f10 >>> Features: ebx: 0x00020800, ecx: 0xfed83203, edx: 0x178bfbff >>> Ext. features: eax: 0x00870f10, ebx: 0x20000000, ecx: 0x004003f3, edx: 0x2fd3fbff >>> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Hyper Threading, Streaming SIMD Extensions 3, PCLMULQDQ, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, MOVBE, Popcount instruction, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Core multi-processor leagacy mode, Advanced Bit Manipulations: LZCNT, SSE4A: MOVNTSS, MOVNTSD, EXTRQ, INSERTQ, Misaligned SSE mode, SYSCALL/SYSRET, Execute Di > sable Bit, RDTSCP, Intel 64 Architecture" >>> sockets = 1 >>> cores = 2 >>> hwThreads = 2 >>> } >>> >>> It is caused by missing comma after `Opteron QC/Phenom`. So I think the fix is trivial. >> >> Hi Yasumasa, >> >> You should have led with the fact this is caused by a missing comma! IIUC this will shorten the array by one entry and so Zen will be in the wrong position. >> >> Looks good and trivial. >> >> Thanks, >> David > > Thanks @dholmes-ora and @tstuefe for the review! > >> You should have led with the fact this is caused by a missing comma! > > Do you mean we should change the subject like "Missing comma in VM_Version_Ext::_family_id_amd"? Well yes, the bug report could have been clearer :) I went from the bug report to the PR link and straight to "Files changed" to do the review - after checking that we did in fact have Zen support. So I never saw the "It is caused by missing comma ..." you added for the PR description. Cheers, David ----- >> IIUC this will shorten the array by one entry and so Zen will be in the wrong position. > > Yes, "Zen" was located at penultimate position, and NULL was set to the tail when I checked it on GDB. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2158 > From david.holmes at oracle.com Wed Jan 20 12:20:54 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jan 2021 22:20:54 +1000 Subject: RFR: JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name In-Reply-To: References: Message-ID: On 20/01/2021 6:32 pm, Lutz Schmidt wrote: > On Wed, 20 Jan 2021 08:21:36 GMT, Matthias Baesken wrote: > >>> src/hotspot/share/runtime/frame.cpp line 543: >>> >>>> 541: bool found; >>>> 542: >>>> 543: if (buf == NULL || buflen < 1) return; >>> >>> Can this not just be an assert: buf != NULL && buflen > 0 ? >> >> Hi David, I think a return would be clearer but an assert is "better than nothing" . >> >> Best regards, Matthias > > With an assert, you assume this is a "cannot occur error". You should be pretty sure to have good test coverage to find all "illegal invocations" before letting a release build escape into the wild. The problem with a return is that it implies these conditions are allowable and could reasonably happen, when in fact it would be an internal programming error in the VM. Do we have test coverage for all the code paths involved? Probably not. But the vast majority of assertions in the VM do not have a "release" bail-out path. Keeping one here is unnecessary and overkill IMO but I won't insist it be removed as this is essentially error reporting code anyway. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2144 > From stuefe at openjdk.java.net Wed Jan 20 12:28:01 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 20 Jan 2021 12:28:01 GMT Subject: RFR: JDK-8260030: Improve stringStream buffer handling Message-ID: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> stringStream objects are used as temporary string buffers a lot in hotspot. When investigating JDK-8259710, I found that a large majority of the stringStreams created never use the backing buffer fully; about 70% of all streams write less than 32 characters. stringStream creates an backing buffer, C-heap allocated, with a default size of 256 characters. Some things could be improved: - add a small in-object buffer for the first n characters to be written. This would avoid or at least delay allocation of the backing buffer from C-heap, at the expense of slightly increased object size and one memcpy when switching over to C-heap. Note that if the backing buffer is smaller than what now is the default size, the total footprint will go down despite the increased object size. - Delaying allocation of the backing buffer would be good for the many cases where stringStream objects are created as temporary objects without being actually used, see eg. compile.hpp `class PrintInliningBuffer` - Besides all that, the code could benefit from a little grooming (using modern style syntax etc). ---- This patch: - renames members of stringStream to conform to common syntax (eg leading underscores) and to be clearer - Uses initialization lists - Factors out buffer growth code from stringStream::write() to a new function stringStream::grow() - Introduces a new object-internal mini buffer, `stringStream::_small_buffer`, sized 32 bytes, which is initially used for all writes This patch drastically reduces the number of malloc calls done from this class. The internal buffer size of 32byte seems a good cut-off. Running some unrelated test program (no tracing active), I see a reduction in the number of malloc calls from stringStream from ~211K malloc calls down to 53K (debug VM). In a release VM, it drops from ~85K down to about 1K. The reason is that `stringStream` is used in a ton of places as a temporary stack allocated object, to write very minimal text snippets to. I also tweaked the associated gtest to test more thoroughly. ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/2160/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2160&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260030 Stats: 92 lines in 3 files changed: 33 ins; 9 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/2160.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2160/head:pull/2160 PR: https://git.openjdk.java.net/jdk/pull/2160 From stuefe at openjdk.java.net Wed Jan 20 12:29:54 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 20 Jan 2021 12:29:54 GMT Subject: RFR: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently Message-ID: When function descriptors are fed to os::print_function_and_library_name() to get debug output, it would be very helpful to transparently handle the case where the address is not a code pointer but a function descriptor. Of the official OpenJDK platforms this affects only ppc, but also includes at least ia64 for those who maintain ports to that platform. Fixing this will also fix the display of signal handlers on linux ppc which still show up without function names after JDK-8258606. Before: 695 Signal Handlers: 696 SIGSEGV: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 697 SIGBUS: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 698 SIGFPE: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 699 SIGPIPE: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 700 SIGXFSZ: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 701 SIGILL: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 702 SIGUSR2: 0x00000fff8d0e0098 in libjvm.so+34799768, sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO 703 SIGHUP: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 704 SIGINT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 705 SIGTERM: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 706 SIGQUIT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 707 SIGTRAP: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO Now: 693 Signal Handlers: 694 SIGSEGV: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 695 SIGBUS: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 696 SIGFPE: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 697 SIGPIPE: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 698 SIGXFSZ: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 699 SIGILL: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 700 SIGUSR2: SR_handler in libjvm.so (FD), sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO 701 SIGHUP: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 702 SIGINT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 703 SIGTERM: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 704 SIGQUIT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 705 SIGTRAP: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO The patch also adds a little trailing marker `(FD)` as an indication for the developer that this had been a function descriptor. ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/2157/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2157&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260022 Stats: 46 lines in 6 files changed: 41 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2157.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2157/head:pull/2157 PR: https://git.openjdk.java.net/jdk/pull/2157 From ysuenaga at openjdk.java.net Wed Jan 20 12:56:50 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 20 Jan 2021 12:56:50 GMT Subject: RFR: 8260025: HotSpot cannot identify Zen (family 17h) processor In-Reply-To: References: Message-ID: <9Z27FuLL6fHUtAWs70Ve_fuIAk3oUGLL6CnyIa1xQV0=.cb1d1231-466f-4167-bb22-59b29611d195@github.com> On Wed, 20 Jan 2021 08:15:37 GMT, Yasumasa Suenaga wrote: >> Hi Yasumasa, >> >> You should have led with the fact this is caused by a missing comma! IIUC this will shorten the array by one entry and so Zen will be in the wrong position. >> >> Looks good and trivial. >> >> Thanks, >> David > > Thanks @dholmes-ora and @tstuefe for the review! > >> You should have led with the fact this is caused by a missing comma! > > Do you mean we should change the subject like "Missing comma in VM_Version_Ext::_family_id_amd"? > >> IIUC this will shorten the array by one entry and so Zen will be in the wrong position. > > Yes, "Zen" was located at penultimate position, and NULL was set to the tail when I checked it on GDB. > > Do you mean we should change the subject like "Missing comma in VM_Version_Ext::_family_id_amd"? > > Well yes, the bug report could have been clearer :) I went from the bug > report to the PR link and straight to "Files changed" to do the review - > after checking that we did in fact have Zen support. So I never saw the > "It is caused by missing comma ..." you added for the PR description. Sorry for the confusing subject. Ok, I will change the subject both JBS and this PR before pushing. ------------- PR: https://git.openjdk.java.net/jdk/pull/2158 From lutz.schmidt at sap.com Wed Jan 20 13:40:03 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 20 Jan 2021 13:40:03 +0000 Subject: JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name Message-ID: <7454243A-8D6D-46A9-A7DB-0FF76F910D3F@sap.com> Hi David, my comment was motivated by the "don't fail if you don't have to" principle. You will certainly agree, such principle is very helpful in productive environments. In this particular case, there is no need to fail - just don't print. On the other hand, if these checks describe a "cannot occur situation" - why then checking for it at all? Anyway, life has gone on since I wrote my comment. Everybody else likes the path you (and Thomas) suggested. I will therefore mute myself. My LGTM statement remains valid. Best Regards, Lutz ?On 20.01.21, 13:20, "David Holmes" wrote: On 20/01/2021 6:32 pm, Lutz Schmidt wrote: > On Wed, 20 Jan 2021 08:21:36 GMT, Matthias Baesken wrote: > >>> src/hotspot/share/runtime/frame.cpp line 543: >>> >>>> 541: bool found; >>>> 542: >>>> 543: if (buf == NULL || buflen < 1) return; >>> >>> Can this not just be an assert: buf != NULL && buflen > 0 ? >> >> Hi David, I think a return would be clearer but an assert is "better than nothing" . >> >> Best regards, Matthias > > With an assert, you assume this is a "cannot occur error". You should be pretty sure to have good test coverage to find all "illegal invocations" before letting a release build escape into the wild. The problem with a return is that it implies these conditions are allowable and could reasonably happen, when in fact it would be an internal programming error in the VM. Do we have test coverage for all the code paths involved? Probably not. But the vast majority of assertions in the VM do not have a "release" bail-out path. Keeping one here is unnecessary and overkill IMO but I won't insist it be removed as this is essentially error reporting code anyway. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2144 > From mdoerr at openjdk.java.net Wed Jan 20 14:46:50 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 20 Jan 2021 14:46:50 GMT Subject: RFR: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 06:39:06 GMT, Thomas Stuefe wrote: > When function descriptors are fed to os::print_function_and_library_name() to get debug output, it would be very helpful to transparently handle the case where the address is not a code pointer but a function descriptor. > > Of the official OpenJDK platforms this affects only ppc, but also includes at least ia64 for those who maintain ports to that platform. > > Fixing this will also fix the display of signal handlers on linux ppc which still show up without function names after JDK-8258606. > > Before: > 695 Signal Handlers: > 696 SIGSEGV: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 697 SIGBUS: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 698 SIGFPE: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 699 SIGPIPE: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 700 SIGXFSZ: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 701 SIGILL: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 702 SIGUSR2: 0x00000fff8d0e0098 in libjvm.so+34799768, sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > 703 SIGHUP: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 704 SIGINT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 705 SIGTERM: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 706 SIGQUIT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 707 SIGTRAP: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > Now: > 693 Signal Handlers: > 694 SIGSEGV: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 695 SIGBUS: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 696 SIGFPE: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 697 SIGPIPE: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 698 SIGXFSZ: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 699 SIGILL: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 700 SIGUSR2: SR_handler in libjvm.so (FD), sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > 701 SIGHUP: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 702 SIGINT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 703 SIGTERM: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 704 SIGQUIT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 705 SIGTRAP: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > The patch also adds a little trailing marker `(FD)` as an indication for the developer that this had been a function descriptor. Hi Thomas, thanks for fixing it. Please check PPC64le which doesn't use FunctionDescriptors. They are only used on Big Endian (linux + AIX). Little Endian implements ABI v2 (also see usage of ABI_ELFv2 in hotspot code). ------------- PR: https://git.openjdk.java.net/jdk/pull/2157 From mbaesken at openjdk.java.net Wed Jan 20 15:11:52 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 20 Jan 2021 15:11:52 GMT Subject: Integrated: JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name In-Reply-To: References: Message-ID: <6CgbW2zzA27gNs_ic1vN8MhOsxwqeOFM3oBMpecQ2kM=.34419d66-377b-4413-96c5-3a230ec6c314@github.com> On Tue, 19 Jan 2021 12:08:05 GMT, Matthias Baesken wrote: > On some platforms like bsd/mac, we call dll_address_to_library_name with a buffer parameter (e.g. char dli_fname[MAXPATHLEN]; ) that has uninitialized content. > This is usually no problem because dll_address_to_library_name fills the array, but on some codepaths it seems not to be the case. > > See also this related sonar issue : > https://sonarcloud.io/project/issues?id=jdk&open=AXaE0drk8L9hkQskGEXZ&resolved=false&types=BUG This pull request has now been integrated. Changeset: 69f90b5f Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/69f90b5f Stats: 11 lines in 4 files changed: 6 ins; 0 del; 5 mod 8259843: initialize dli_fname array before calling dll_address_to_library_name Reviewed-by: lucy, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/2144 From fparain at openjdk.java.net Wed Jan 20 21:11:50 2021 From: fparain at openjdk.java.net (Frederic Parain) Date: Wed, 20 Jan 2021 21:11:50 GMT Subject: RFR: 8259214: MetaspaceClosure support for Arrays of MetaspaceObj [v4] In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 20:13:10 GMT, Ioi Lam wrote: >> Currently, `MetaspaceClosure::push` supports only the following variants: >> >> MetaspaceClosure* it = ...; >> Klass* o = ...; it->push(&o); >> Array* a1 = ...; it->push(&a1); >> Array* a2 = ...; it->push(&a2); >> >> In Valhalla, support is needed for the following variant (Annotation is a subtype of MetaspaceObj): >> >> Array* a3 = ...; it->push(&a3); >> >> This change will allow CDS to make a copy of this array, as well as relocating all the pointers embedded in the elements of this array. See a test case in test_metaspaceClosure.cpp. >> >> I also cleaned up the code (with help from @kimbarrett) to use SFINAE to dispatch from `MetaspaceClosure::push` to the different subtypes of `MetaspaceClosure::Ref`. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Remove RefMatcher and go back to overloaded template functions for push(...) Looks good to me. Thank you for adding this feature. Fred ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.java.net/jdk/pull/1995 From jrose at openjdk.java.net Wed Jan 20 22:40:52 2021 From: jrose at openjdk.java.net (John R Rose) Date: Wed, 20 Jan 2021 22:40:52 GMT Subject: RFR: 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE In-Reply-To: <4sH9-Ili4eHGu7VOvOCYqmZ9ZGzxqH9kyyw6Qlzk-C8=.3424a2d5-80ae-4c98-9a0d-c3a215a29d5b@github.com> References: <4sH9-Ili4eHGu7VOvOCYqmZ9ZGzxqH9kyyw6Qlzk-C8=.3424a2d5-80ae-4c98-9a0d-c3a215a29d5b@github.com> Message-ID: On Mon, 18 Jan 2021 14:07:36 GMT, Kim Barrett wrote: > [Restarting this PR after some offline discussion with jrose. New name for > the macro, and some additional commentary and tests.] > > Please review this change which adds the ENABLE_IF_SDEFN macro. This is > used in the definition of a function template when that definition is > separate from a declaration that uses ENABLE_IF. > > Alternative names for the new macro are possible and even solicited. I > know, I'm asking for bikeshedding. > > The ENABLE_IF macro provides convenient syntax for function template SFINAE > using the new default template parameter feature of C++11. However, this > macro can only be used in the function declaration (which may also be a > definition). > > The syntax needed in a definition that is separate from the declaration is > different, but the type forms for the non-type template parameters in the > two places must be "equivalent" (C++14 14.5.6). The precise form for > ENABLE_IF is "hidden" behind the macro. It is not desirable to have > template definitions making assumptions about that form. This suggests > there should be a second macro for use in the separate definition case, with > the two macros maintained together to ensure the necessary consistency. > > (Note that some versions of gcc permit the unused default in some separate > definitions. Other tool chains reject it. Because of this, I was only > vaguely aware of (and had long forgotten) about this issue when proposing > ENABLE_IF, despite having extensively used similar mechanisms in other code > bases.) > > This gives the following usage: > > template::value)> > void foo(T x) { ... } > > and this for separate declaration and definition. > > template::value)> > void foo(T x); > > // later separate definition > template::value)> > void foo(T x) { ... } > > (An alternative would be to just drop the macro usage entirely, at least in > the separate definition case, and just accept the additional syntactic > complexity. I'm not proposing that.) > > (Since I was touching the file anyway, I also improved some of the comments > discussing details) > > Testing: > mach5 tier1 > This includes some new gtests for the macros. > There aren't any current non-test uses of ENABLE_IF_SDEFN yet. Marked as reviewed by jrose (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2129 From iklam at openjdk.java.net Wed Jan 20 22:58:03 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 20 Jan 2021 22:58:03 GMT Subject: RFR: 8260191: Do not include access.hpp in oop.hpp Message-ID: <6u3URNOh5SJ9TuVCA4VSsawfEBWbmbBXwtGvtD1Zv6k=.6b5dfdf6-6110-49e2-a54f-f1803e77e04b@github.com> Please review this trivial change. oop.h is included by 860 out of 1000 HotSpot .o files. It includes access.h for this member function declaration only: template oop obj_field_access(int offset) const; Instead of access.h, oop.h should include accessDecorators.hpp. This avoids including lots of header files from the Access API. HotSpot build time is reduced by about 0.5% for this single-line change. Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- Commit messages: - 8260191: Do not include access.hpp in oop.hpp Changes: https://git.openjdk.java.net/jdk/pull/2172/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2172&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260191 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2172/head:pull/2172 PR: https://git.openjdk.java.net/jdk/pull/2172 From iklam at openjdk.java.net Wed Jan 20 23:09:51 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 20 Jan 2021 23:09:51 GMT Subject: RFR: JDK-8260030: Improve stringStream buffer handling In-Reply-To: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> References: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> Message-ID: <_MIWLgqaujCcTMu48Hs78mn3UF_2sWMKWLIr-Y8MOxE=.c2a43fcf-9d65-413e-b62a-df7b736ffff6@github.com> On Wed, 20 Jan 2021 10:27:11 GMT, Thomas Stuefe wrote: > stringStream objects are used as temporary string buffers a lot in hotspot. When investigating JDK-8259710, I found that a large majority of the stringStreams created never use the backing buffer fully; about 70% of all streams write less than 32 characters. > > stringStream creates an backing buffer, C-heap allocated, with a default size of 256 characters. Some things could be improved: > > - add a small in-object buffer for the first n characters to be written. This would avoid or at least delay allocation of the backing buffer from C-heap, at the expense of slightly increased object size and one memcpy when switching over to C-heap. Note that if the backing buffer is smaller than what now is the default size, the total footprint will go down despite the increased object size. > > - Delaying allocation of the backing buffer would be good for the many cases where stringStream objects are created as temporary objects without being actually used, see eg. compile.hpp `class PrintInliningBuffer` > > - Besides all that, the code could benefit from a little grooming (using modern style syntax etc). > > ---- > > This patch: > > - renames members of stringStream to conform to common syntax (eg leading underscores) and to be clearer > - Uses initialization lists > - Factors out buffer growth code from stringStream::write() to a new function stringStream::grow() > - Introduces a new object-internal mini buffer, `stringStream::_small_buffer`, sized 32 bytes, which is initially used for all writes > > This patch drastically reduces the number of malloc calls done from this class. The internal buffer size of 32byte seems a good cut-off. Running some unrelated test program (no tracing active), I see a reduction in the number of malloc calls from stringStream from ~211K malloc calls down to 53K (debug VM). In a release VM, it drops from ~85K down to about 1K. The reason is that `stringStream` is used in a ton of places as a temporary stack allocated object, to write very minimal text snippets to. > > I also tweaked the associated gtest to test more thoroughly. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2160 From redestad at openjdk.java.net Wed Jan 20 23:21:53 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 20 Jan 2021 23:21:53 GMT Subject: RFR: 8259882: Reduce the inclusion of perfData.hpp In-Reply-To: References: Message-ID: <2HuiruAVj21BM7Ji9IcN4CX4N8mLPJfCjz0lVYMGY98=.23f60a29-55b1-4430-a66c-e9590c70b011@github.com> On Mon, 18 Jan 2021 04:24:27 GMT, Ioi Lam wrote: > perfData.hpp is about 1000 lines long, and is included by 829 out of about 1000 HotSpot .o files. > > Several popular headers (such as synchronizer.hpp, objectMonitor.hpp, threadLocalAllocBuffer.hpp) include perfData.hpp. However, since these headers just declare pointers like > > PerfCounter* foo; > > there's no need to include perfData.hpp. A forward declaration of the PerfCount type would suffice. > > With forward declaration, we can remove perfData.hpp from these headers. This reduces the number of .o files that include perfData.hpp to 183. Build time of HotSpot is reduced by about 0.4%. > > **Note:** the forward declaration is in the new file perfDataTypes.hpp. It contains typedefs to make "aliases" of the types. These are probably relics from the past, where new classes like`PerfIntConstant` were to be added but that never happened. > > typedef PerfLongSampleHelper PerfSampleHelper; > typedef PerfLongConstant PerfConstant; > typedef PerfLongCounter PerfCounter; > typedef PerfLongVariable PerfVariable; > > The HotSpot code uses both the "real" type and the "alias" type (mostly the latter). I don't want to deal with the alises for now, so I just moved them from perfData.hpp to perfDataTypes.hpp. We should probably just rename `PerfLongConstant` to `PerfConstant` in a future RFE. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Looks good to me. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2123 From david.holmes at oracle.com Wed Jan 20 23:40:21 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jan 2021 09:40:21 +1000 Subject: JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name In-Reply-To: <7454243A-8D6D-46A9-A7DB-0FF76F910D3F@sap.com> References: <7454243A-8D6D-46A9-A7DB-0FF76F910D3F@sap.com> Message-ID: <9cfb6fd3-2311-5454-d31c-8f94be2d435d@oracle.com> Hi Lutz, On 20/01/2021 11:40 pm, Schmidt, Lutz wrote: > Hi David, > my comment was motivated by the "don't fail if you don't have to" principle. You will certainly agree, such principle is very helpful in productive environments. In this particular case, there is no need to fail - just don't print. On the other hand, if these checks describe a "cannot occur situation" - why then checking for it at all? The condition indicates a programming error in the caller of this API hence an assertion would be appropriate. We usually introduce release-build checks, after an assert, for cases where we should not get the condition (as it indicates a programming error in the VM which we expect testing to catch) but there is a possibility of it actually happening at runtime due to "external inputs". That is not the case here. > Anyway, life has gone on since I wrote my comment. Everybody else likes the path you (and Thomas) suggested. I will therefore mute myself. My LGTM statement remains valid. The original code with just the return is what was committed. :) Cheers, David > Best Regards, > Lutz > > ?On 20.01.21, 13:20, "David Holmes" wrote: > > On 20/01/2021 6:32 pm, Lutz Schmidt wrote: > > On Wed, 20 Jan 2021 08:21:36 GMT, Matthias Baesken wrote: > > > >>> src/hotspot/share/runtime/frame.cpp line 543: > >>> > >>>> 541: bool found; > >>>> 542: > >>>> 543: if (buf == NULL || buflen < 1) return; > >>> > >>> Can this not just be an assert: buf != NULL && buflen > 0 ? > >> > >> Hi David, I think a return would be clearer but an assert is "better than nothing" . > >> > >> Best regards, Matthias > > > > With an assert, you assume this is a "cannot occur error". You should be pretty sure to have good test coverage to find all "illegal invocations" before letting a release build escape into the wild. > > The problem with a return is that it implies these conditions are > allowable and could reasonably happen, when in fact it would be an > internal programming error in the VM. Do we have test coverage for all > the code paths involved? Probably not. But the vast majority of > assertions in the VM do not have a "release" bail-out path. Keeping one > here is unnecessary and overkill IMO but I won't insist it be removed as > this is essentially error reporting code anyway. > > David > > > ------------- > > > > PR: https://git.openjdk.java.net/jdk/pull/2144 > > > From kbarrett at openjdk.java.net Thu Jan 21 02:07:56 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 21 Jan 2021 02:07:56 GMT Subject: RFR: 8260191: Do not include access.hpp in oop.hpp In-Reply-To: <6u3URNOh5SJ9TuVCA4VSsawfEBWbmbBXwtGvtD1Zv6k=.6b5dfdf6-6110-49e2-a54f-f1803e77e04b@github.com> References: <6u3URNOh5SJ9TuVCA4VSsawfEBWbmbBXwtGvtD1Zv6k=.6b5dfdf6-6110-49e2-a54f-f1803e77e04b@github.com> Message-ID: <0yyqZ4ZLTzZYRRG-tvRLLViiyhK1q9iA_oxb4DaaEC4=.633cf2db-501d-4d39-a58e-dbf8dc66b210@github.com> On Wed, 20 Jan 2021 22:30:44 GMT, Ioi Lam wrote: > Please review this trivial change. > > oop.h is included by 860 out of 1000 HotSpot .o files. It includes access.h for this member function declaration only: > > template oop obj_field_access(int offset) const; > > Instead of access.h, oop.h should include accessDecorators.hpp. This avoids including lots of header files from the Access API. > > HotSpot build time is reduced by about 0.5% for this single-line change. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2172 From kbarrett at openjdk.java.net Thu Jan 21 02:12:57 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 21 Jan 2021 02:12:57 GMT Subject: RFR: 8260191: Do not include access.hpp in oop.hpp In-Reply-To: <6u3URNOh5SJ9TuVCA4VSsawfEBWbmbBXwtGvtD1Zv6k=.6b5dfdf6-6110-49e2-a54f-f1803e77e04b@github.com> References: <6u3URNOh5SJ9TuVCA4VSsawfEBWbmbBXwtGvtD1Zv6k=.6b5dfdf6-6110-49e2-a54f-f1803e77e04b@github.com> Message-ID: On Wed, 20 Jan 2021 22:30:44 GMT, Ioi Lam wrote: > Please review this trivial change. > > oop.h is included by 860 out of 1000 HotSpot .o files. It includes access.h for this member function declaration only: > > template oop obj_field_access(int offset) const; > > Instead of access.h, oop.h should include accessDecorators.hpp. This avoids including lots of header files from the Access API. > > HotSpot build time is reduced by about 0.5% for this single-line change. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Forgot to say earlier, I agree this is trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2172 From iklam at openjdk.java.net Thu Jan 21 03:09:13 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 21 Jan 2021 03:09:13 GMT Subject: RFR: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h [v2] In-Reply-To: References: Message-ID: <-jIDq0RisaLSuXg2Z9PlB-pWs8Aio6GUbEZTr4ozRJY=.2ed90f9c-b543-4ef3-b4e7-deeca5d0694e@github.com> > jvm.h is over 1000 lines long. It is included by 940 out of 1000 HotSpot .o files. However, most of the HotSpot source files just use a small fraction of jvm.h: > > - the jio_xxxprintf() functions > - the JVM_RECOGNIZED_XXX_MODIFIERS defines > > We should move these two parts into jvm_io.h and jvm_constants.h. This reduces the files that include jvm.h to about 82 files. Build time of HotSpot is reduced by about 0.4%. > > Testing: mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: David Holmes comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2154/files - new: https://git.openjdk.java.net/jdk/pull/2154/files/f3cce1ba..00fc5db5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2154&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2154&range=00-01 Stats: 16 lines in 5 files changed: 2 ins; 3 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2154.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2154/head:pull/2154 PR: https://git.openjdk.java.net/jdk/pull/2154 From iklam at openjdk.java.net Thu Jan 21 03:09:17 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 21 Jan 2021 03:09:17 GMT Subject: RFR: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h [v2] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 05:51:11 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> David Holmes comments > > src/hotspot/share/include/jvm_constants.h line 8: > >> 6: * under the terms of the GNU General Public License version 2 only, as >> 7: * published by the Free Software Foundation. Oracle designates this >> 8: * particular file as subject to the "Classpath" exception as provided > > Classpath exception is wrong here - that is only for (mainly Java) sources that applications may link against. It's existing use in jvm.h is incorrect. I think the classpath exception is intended for other JVM implementations that might include jvm.h. I'll leave it as is for now. > src/hotspot/share/include/jvm_constants.h line 26: > >> 24: */ >> 25: >> 26: #ifndef _JAVASOFT_JVM_CONSTANTS_H_ > > We don't need to keep the legacy JAVASOFT defines. Changed to `_JVM_CONSTANTS_H_` and `_JVM_IO_H_`. > src/hotspot/share/logging/logSelection.cpp line 25: > >> 23: */ >> 24: #include "precompiled.hpp" >> 25: #include "jvm.h" > > Not jvm_io.h ?? Changed to jvm_io.h > src/hotspot/share/include/jvm.h line 34: > >> 32: #include "jvm_md.h" >> 33: #include "jvm_constants.h" >> 34: #include "jvm_io.h" > > Note that the comment block starting at line 40 needs to be updated now you have refactored things. I fixed the comments. > src/hotspot/share/classfile/javaClasses.cpp line 26: > >> 24: >> 25: #include "precompiled.hpp" >> 26: #include "jvm.h" > > Does this really need jvm.h or just jvm_constants.h and jvm_io.h? jvm.h is needed because this file uses the JVM_XXX() functions. > src/hotspot/share/classfile/vmIntrinsics.cpp line 26: > >> 24: >> 25: #include "precompiled.hpp" >> 26: #include "jvm.h" > > Does this really need jvm.h or just jvm_constants.h and jvm_io.h? Changed to jvm_constants.h and jvm_io.h. ------------- PR: https://git.openjdk.java.net/jdk/pull/2154 From iklam at openjdk.java.net Thu Jan 21 03:13:41 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 21 Jan 2021 03:13:41 GMT Subject: RFR: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h [v2] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 06:07:19 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> David Holmes comments > > src/hotspot/share/runtime/os.hpp line 28: > >> 26: #define SHARE_RUNTIME_OS_HPP >> 27: >> 28: #include "jvm_md.h" > > jvm_md.h should not be included directly by any file - it is an internal implementation detail. os.hpp is used by almost all HotSpot .o files, so if we keep jvm.h here, that defeats the purpose of this PR. As David and I discussed offline, jvm_md.h is a kludgy legacy porting layer for stuff like DIR, which is used by os.hpp. jvm_md.h contains comments like the following that haven't been touched for decades .... so it's probably a good idea to not disturb it now. /* * This file is currently collecting system-specific dregs for the * JNI conversion, which should be sorted out later. */ ------------- PR: https://git.openjdk.java.net/jdk/pull/2154 From iklam at openjdk.java.net Thu Jan 21 03:56:49 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 21 Jan 2021 03:56:49 GMT Subject: RFR: 8260191: Do not include access.hpp in oop.hpp In-Reply-To: References: <6u3URNOh5SJ9TuVCA4VSsawfEBWbmbBXwtGvtD1Zv6k=.6b5dfdf6-6110-49e2-a54f-f1803e77e04b@github.com> Message-ID: On Thu, 21 Jan 2021 02:09:23 GMT, Kim Barrett wrote: >> Please review this trivial change. >> >> oop.h is included by 860 out of 1000 HotSpot .o files. It includes access.h for this member function declaration only: >> >> template oop obj_field_access(int offset) const; >> >> Instead of access.h, oop.h should include accessDecorators.hpp. This avoids including lots of header files from the Access API. >> >> HotSpot build time is reduced by about 0.5% for this single-line change. >> >> Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > Forgot to say earlier, I agree this is trivial. Thanks @kimbarrett for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/2172 From iklam at openjdk.java.net Thu Jan 21 03:56:49 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 21 Jan 2021 03:56:49 GMT Subject: Integrated: 8260191: Do not include access.hpp in oop.hpp In-Reply-To: <6u3URNOh5SJ9TuVCA4VSsawfEBWbmbBXwtGvtD1Zv6k=.6b5dfdf6-6110-49e2-a54f-f1803e77e04b@github.com> References: <6u3URNOh5SJ9TuVCA4VSsawfEBWbmbBXwtGvtD1Zv6k=.6b5dfdf6-6110-49e2-a54f-f1803e77e04b@github.com> Message-ID: <9fsn1z0ZqwJryZ-xdvsJ0EPQKXQ-r9_B57hp9UOwKso=.2f785f29-955e-4d8b-a248-337b3b7b75ae@github.com> On Wed, 20 Jan 2021 22:30:44 GMT, Ioi Lam wrote: > Please review this trivial change. > > oop.h is included by 860 out of 1000 HotSpot .o files. It includes access.h for this member function declaration only: > > template oop obj_field_access(int offset) const; > > Instead of access.h, oop.h should include accessDecorators.hpp. This avoids including lots of header files from the Access API. > > HotSpot build time is reduced by about 0.5% for this single-line change. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. This pull request has now been integrated. Changeset: 044bae0e Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/044bae0e Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod 8260191: Do not include access.hpp in oop.hpp Reviewed-by: kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/2172 From kbarrett at openjdk.java.net Thu Jan 21 05:37:56 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 21 Jan 2021 05:37:56 GMT Subject: RFR: 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE In-Reply-To: References: <4sH9-Ili4eHGu7VOvOCYqmZ9ZGzxqH9kyyw6Qlzk-C8=.3424a2d5-80ae-4c98-9a0d-c3a215a29d5b@github.com> Message-ID: On Wed, 20 Jan 2021 22:38:05 GMT, John R Rose wrote: >> [Restarting this PR after some offline discussion with jrose. New name for >> the macro, and some additional commentary and tests.] >> >> Please review this change which adds the ENABLE_IF_SDEFN macro. This is >> used in the definition of a function template when that definition is >> separate from a declaration that uses ENABLE_IF. >> >> Alternative names for the new macro are possible and even solicited. I >> know, I'm asking for bikeshedding. >> >> The ENABLE_IF macro provides convenient syntax for function template SFINAE >> using the new default template parameter feature of C++11. However, this >> macro can only be used in the function declaration (which may also be a >> definition). >> >> The syntax needed in a definition that is separate from the declaration is >> different, but the type forms for the non-type template parameters in the >> two places must be "equivalent" (C++14 14.5.6). The precise form for >> ENABLE_IF is "hidden" behind the macro. It is not desirable to have >> template definitions making assumptions about that form. This suggests >> there should be a second macro for use in the separate definition case, with >> the two macros maintained together to ensure the necessary consistency. >> >> (Note that some versions of gcc permit the unused default in some separate >> definitions. Other tool chains reject it. Because of this, I was only >> vaguely aware of (and had long forgotten) about this issue when proposing >> ENABLE_IF, despite having extensively used similar mechanisms in other code >> bases.) >> >> This gives the following usage: >> >> template::value)> >> void foo(T x) { ... } >> >> and this for separate declaration and definition. >> >> template::value)> >> void foo(T x); >> >> // later separate definition >> template::value)> >> void foo(T x) { ... } >> >> (An alternative would be to just drop the macro usage entirely, at least in >> the separate definition case, and just accept the additional syntactic >> complexity. I'm not proposing that.) >> >> (Since I was touching the file anyway, I also improved some of the comments >> discussing details) >> >> Testing: >> mach5 tier1 >> This includes some new gtests for the macros. >> There aren't any current non-test uses of ENABLE_IF_SDEFN yet. > > Marked as reviewed by jrose (Reviewer). Thanks @rose00 for review. ------------- PR: https://git.openjdk.java.net/jdk/pull/2129 From ysuenaga at openjdk.java.net Thu Jan 21 06:11:57 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 21 Jan 2021 06:11:57 GMT Subject: Integrated: 8260025: Missing comma in VM_Version_Ext::_family_id_amd In-Reply-To: References: Message-ID: <4v2lyZmT01ZjTTi0BSjUbcXBFV2sciRdsuJzPoJEDO4=.14f236e8-e005-4ce9-9a53-5ef53a2a4f33@github.com> On Wed, 20 Jan 2021 07:51:29 GMT, Yasumasa Suenaga wrote: > HotSpot cannot identify Zen (family 17h) processor. You can see this problem in flight record as below: > > java -XX:StartFlightRecording=filename=test.jfr --version > > `(null)` in `cpu` and `` in `Family` should be `Zen`. > > $ jfr print --events jdk.CPUInformation test.jfr > jdk.CPUInformation { > startTime = 15:59:37.207 > cpu = "AMD (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A AMD64" > description = "Brand: AMD Ryzen 3 3300X 4-Core Processor , Vendor: AuthenticAMD > Family: (0x17), Model: (0x71), Stepping: 0x0 > Ext. family: 0x8, Ext. model: 0x7, Type: 0x0, Signature: 0x00870f10 > Features: ebx: 0x00020800, ecx: 0xfed83203, edx: 0x178bfbff > Ext. features: eax: 0x00870f10, ebx: 0x20000000, ecx: 0x004003f3, edx: 0x2fd3fbff > Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Hyper Threading, Streaming SIMD Extensions 3, PCLMULQDQ, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, MOVBE, Popcount instruction, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Core multi-processor leagacy mode, Advanced Bit Manipulations: LZCNT, SSE4A: MOVNTSS, MOVNTSD, EXTRQ, INSERTQ, Misaligned SSE mode, SYSCALL/SYSRET, Execute Dis able Bit, RDTSCP, Intel 64 Architecture" > sockets = 1 > cores = 2 > hwThreads = 2 > } > > It is caused by missing comma after `Opteron QC/Phenom`. So I think the fix is trivial. This pull request has now been integrated. Changeset: f8a9602a Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/f8a9602a Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8260025: Missing comma in VM_Version_Ext::_family_id_amd Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/2158 From stuefe at openjdk.java.net Thu Jan 21 09:36:19 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 21 Jan 2021 09:36:19 GMT Subject: RFR: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently [v2] In-Reply-To: References: Message-ID: <57kh3-liBn7oO9l1r4Ad_sfh0WiM69HZCpUevoSz07U=.ba340bfd-3935-47f1-b4ae-5f1296d6c90c@github.com> > When function descriptors are fed to os::print_function_and_library_name() to get debug output, it would be very helpful to transparently handle the case where the address is not a code pointer but a function descriptor. > > Of the official OpenJDK platforms this affects only ppc, but also includes at least ia64 for those who maintain ports to that platform. > > Fixing this will also fix the display of signal handlers on linux ppc which still show up without function names after JDK-8258606. > > Before: > 695 Signal Handlers: > 696 SIGSEGV: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 697 SIGBUS: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 698 SIGFPE: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 699 SIGPIPE: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 700 SIGXFSZ: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 701 SIGILL: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 702 SIGUSR2: 0x00000fff8d0e0098 in libjvm.so+34799768, sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > 703 SIGHUP: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 704 SIGINT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 705 SIGTERM: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 706 SIGQUIT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 707 SIGTRAP: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > Now: > 693 Signal Handlers: > 694 SIGSEGV: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 695 SIGBUS: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 696 SIGFPE: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 697 SIGPIPE: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 698 SIGXFSZ: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 699 SIGILL: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 700 SIGUSR2: SR_handler in libjvm.so (FD), sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > 701 SIGHUP: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 702 SIGINT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 703 SIGTERM: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 704 SIGQUIT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 705 SIGTRAP: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > The patch also adds a little trailing marker `(FD)` as an indication for the developer that this had been a function descriptor. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Fix build errors on ppcle and AIX ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2157/files - new: https://git.openjdk.java.net/jdk/pull/2157/files/c0a07f2b..a0bf1a72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2157&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2157&range=00-01 Stats: 8 lines in 5 files changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2157.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2157/head:pull/2157 PR: https://git.openjdk.java.net/jdk/pull/2157 From stuefe at openjdk.java.net Thu Jan 21 09:40:52 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 21 Jan 2021 09:40:52 GMT Subject: RFR: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 14:44:11 GMT, Martin Doerr wrote: > Hi Thomas, > thanks for fixing it. > Please check PPC64le which doesn't use FunctionDescriptors. They are only used on Big Endian (linux + AIX). > Little Endian implements ABI v2 (also see usage of ABI_ELFv2 in hotspot code). Ouch, you are right. I fixed it. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/2157 From mdoerr at openjdk.java.net Thu Jan 21 09:55:58 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 21 Jan 2021 09:55:58 GMT Subject: RFR: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently [v2] In-Reply-To: <57kh3-liBn7oO9l1r4Ad_sfh0WiM69HZCpUevoSz07U=.ba340bfd-3935-47f1-b4ae-5f1296d6c90c@github.com> References: <57kh3-liBn7oO9l1r4Ad_sfh0WiM69HZCpUevoSz07U=.ba340bfd-3935-47f1-b4ae-5f1296d6c90c@github.com> Message-ID: On Thu, 21 Jan 2021 09:36:19 GMT, Thomas Stuefe wrote: >> When function descriptors are fed to os::print_function_and_library_name() to get debug output, it would be very helpful to transparently handle the case where the address is not a code pointer but a function descriptor. >> >> Of the official OpenJDK platforms this affects only ppc, but also includes at least ia64 for those who maintain ports to that platform. >> >> Fixing this will also fix the display of signal handlers on linux ppc which still show up without function names after JDK-8258606. >> >> Before: >> 695 Signal Handlers: >> 696 SIGSEGV: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 697 SIGBUS: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 698 SIGFPE: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 699 SIGPIPE: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 700 SIGXFSZ: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 701 SIGILL: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 702 SIGUSR2: 0x00000fff8d0e0098 in libjvm.so+34799768, sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >> 703 SIGHUP: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 704 SIGINT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 705 SIGTERM: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 706 SIGQUIT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 707 SIGTRAP: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> >> Now: >> 693 Signal Handlers: >> 694 SIGSEGV: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 695 SIGBUS: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 696 SIGFPE: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 697 SIGPIPE: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 698 SIGXFSZ: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 699 SIGILL: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 700 SIGUSR2: SR_handler in libjvm.so (FD), sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >> 701 SIGHUP: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 702 SIGINT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 703 SIGTERM: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 704 SIGQUIT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 705 SIGTRAP: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> >> The patch also adds a little trailing marker `(FD)` as an indication for the developer that this had been a function descriptor. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Fix build errors on ppcle and AIX Hi Thomas, looks correct. I have only one wish. src/hotspot/os_cpu/linux_ppc/os_linux_ppc.hpp line 35: > 33: static bool register_code_area(char *low, char *high) { return true; } > 34: > 35: #ifndef VM_LITTLE_ENDIAN I'd prefer using #ifndef ABI_ELFv2 because it's directly related to the ABI, not to the endianess. It is used to control function descriptor related code usage in elfFile.cpp. It'd be great if you could use HAVE_FUNCTION_DESCRIPTORS there, too. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2157 From stuefe at openjdk.java.net Thu Jan 21 10:08:14 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 21 Jan 2021 10:08:14 GMT Subject: RFR: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently [v3] In-Reply-To: References: Message-ID: <-U7zmZRMWfYgZatil3T1ksFVqFqWATGKJvrCHHso8hU=.11d26a25-1ce6-4b53-979c-0eee4afe01df@github.com> > When function descriptors are fed to os::print_function_and_library_name() to get debug output, it would be very helpful to transparently handle the case where the address is not a code pointer but a function descriptor. > > Of the official OpenJDK platforms this affects only ppc, but also includes at least ia64 for those who maintain ports to that platform. > > Fixing this will also fix the display of signal handlers on linux ppc which still show up without function names after JDK-8258606. > > Before: > 695 Signal Handlers: > 696 SIGSEGV: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 697 SIGBUS: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 698 SIGFPE: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 699 SIGPIPE: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 700 SIGXFSZ: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 701 SIGILL: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 702 SIGUSR2: 0x00000fff8d0e0098 in libjvm.so+34799768, sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > 703 SIGHUP: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 704 SIGINT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 705 SIGTERM: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 706 SIGQUIT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 707 SIGTRAP: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > Now: > 693 Signal Handlers: > 694 SIGSEGV: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 695 SIGBUS: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 696 SIGFPE: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 697 SIGPIPE: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 698 SIGXFSZ: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 699 SIGILL: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 700 SIGUSR2: SR_handler in libjvm.so (FD), sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > 701 SIGHUP: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 702 SIGINT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 703 SIGTERM: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 704 SIGQUIT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 705 SIGTRAP: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > The patch also adds a little trailing marker `(FD)` as an indication for the developer that this had been a function descriptor. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Use ABI_ELFv2 instead of VM_LITTLE_ENDIAN ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2157/files - new: https://git.openjdk.java.net/jdk/pull/2157/files/a0bf1a72..9cedffac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2157&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2157&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2157.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2157/head:pull/2157 PR: https://git.openjdk.java.net/jdk/pull/2157 From mdoerr at openjdk.java.net Thu Jan 21 10:08:15 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 21 Jan 2021 10:08:15 GMT Subject: RFR: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently [v3] In-Reply-To: <-U7zmZRMWfYgZatil3T1ksFVqFqWATGKJvrCHHso8hU=.11d26a25-1ce6-4b53-979c-0eee4afe01df@github.com> References: <-U7zmZRMWfYgZatil3T1ksFVqFqWATGKJvrCHHso8hU=.11d26a25-1ce6-4b53-979c-0eee4afe01df@github.com> Message-ID: On Thu, 21 Jan 2021 10:05:21 GMT, Thomas Stuefe wrote: >> When function descriptors are fed to os::print_function_and_library_name() to get debug output, it would be very helpful to transparently handle the case where the address is not a code pointer but a function descriptor. >> >> Of the official OpenJDK platforms this affects only ppc, but also includes at least ia64 for those who maintain ports to that platform. >> >> Fixing this will also fix the display of signal handlers on linux ppc which still show up without function names after JDK-8258606. >> >> Before: >> 695 Signal Handlers: >> 696 SIGSEGV: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 697 SIGBUS: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 698 SIGFPE: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 699 SIGPIPE: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 700 SIGXFSZ: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 701 SIGILL: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 702 SIGUSR2: 0x00000fff8d0e0098 in libjvm.so+34799768, sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >> 703 SIGHUP: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 704 SIGINT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 705 SIGTERM: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 706 SIGQUIT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 707 SIGTRAP: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> >> Now: >> 693 Signal Handlers: >> 694 SIGSEGV: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 695 SIGBUS: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 696 SIGFPE: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 697 SIGPIPE: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 698 SIGXFSZ: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 699 SIGILL: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 700 SIGUSR2: SR_handler in libjvm.so (FD), sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >> 701 SIGHUP: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 702 SIGINT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 703 SIGTERM: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 704 SIGQUIT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 705 SIGTRAP: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> >> The patch also adds a little trailing marker `(FD)` as an indication for the developer that this had been a function descriptor. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Use ABI_ELFv2 instead of VM_LITTLE_ENDIAN Thanks! ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2157 From stuefe at openjdk.java.net Thu Jan 21 10:08:16 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 21 Jan 2021 10:08:16 GMT Subject: RFR: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently [v2] In-Reply-To: References: <57kh3-liBn7oO9l1r4Ad_sfh0WiM69HZCpUevoSz07U=.ba340bfd-3935-47f1-b4ae-5f1296d6c90c@github.com> Message-ID: <0WWJZqmat1p2bkysIUWS796LSfQ-qvAOQd_9ihm4qfw=.2a12e4e2-5622-4a33-b206-1441a646468b@github.com> On Thu, 21 Jan 2021 09:52:30 GMT, Martin Doerr wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix build errors on ppcle and AIX > > src/hotspot/os_cpu/linux_ppc/os_linux_ppc.hpp line 35: > >> 33: static bool register_code_area(char *low, char *high) { return true; } >> 34: >> 35: #ifndef VM_LITTLE_ENDIAN > > I'd prefer using #ifndef ABI_ELFv2 because it's directly related to the ABI, not to the endianess. It is used to control function descriptor related code usage in elfFile.cpp. (It'd be great if we could use HAVE_FUNCTION_DESCRIPTORS there, too, but this may not fit well to your change.) Makes sense. I changed it to use ABI_ELFv2. ------------- PR: https://git.openjdk.java.net/jdk/pull/2157 From stuefe at openjdk.java.net Thu Jan 21 10:44:54 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 21 Jan 2021 10:44:54 GMT Subject: RFR: JDK-8260030: Improve stringStream buffer handling In-Reply-To: <_MIWLgqaujCcTMu48Hs78mn3UF_2sWMKWLIr-Y8MOxE=.c2a43fcf-9d65-413e-b62a-df7b736ffff6@github.com> References: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> <_MIWLgqaujCcTMu48Hs78mn3UF_2sWMKWLIr-Y8MOxE=.c2a43fcf-9d65-413e-b62a-df7b736ffff6@github.com> Message-ID: On Wed, 20 Jan 2021 23:06:34 GMT, Ioi Lam wrote: > LGTM Thanks, Ioi! ------------- PR: https://git.openjdk.java.net/jdk/pull/2160 From stuefe at openjdk.java.net Thu Jan 21 12:16:20 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 21 Jan 2021 12:16:20 GMT Subject: RFR: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently [v4] In-Reply-To: References: Message-ID: <83VP-6dw_pvAkaFLm0u56lIjoH85dLz3hOKZBH3FNsM=.1de019f9-6675-4ca0-b0fe-57772696cfb4@github.com> > When function descriptors are fed to os::print_function_and_library_name() to get debug output, it would be very helpful to transparently handle the case where the address is not a code pointer but a function descriptor. > > Of the official OpenJDK platforms this affects only ppc, but also includes at least ia64 for those who maintain ports to that platform. > > Fixing this will also fix the display of signal handlers on linux ppc which still show up without function names after JDK-8258606. > > Before: > 695 Signal Handlers: > 696 SIGSEGV: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 697 SIGBUS: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 698 SIGFPE: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 699 SIGPIPE: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 700 SIGXFSZ: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 701 SIGILL: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 702 SIGUSR2: 0x00000fff8d0e0098 in libjvm.so+34799768, sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > 703 SIGHUP: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 704 SIGINT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 705 SIGTERM: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 706 SIGQUIT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 707 SIGTRAP: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > Now: > 693 Signal Handlers: > 694 SIGSEGV: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 695 SIGBUS: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 696 SIGFPE: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 697 SIGPIPE: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 698 SIGXFSZ: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 699 SIGILL: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 700 SIGUSR2: SR_handler in libjvm.so (FD), sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > 701 SIGHUP: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 702 SIGINT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 703 SIGTERM: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 704 SIGQUIT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 705 SIGTRAP: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > The patch also adds a little trailing marker `(FD)` as an indication for the developer that this had been a function descriptor. Thomas Stuefe 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: Use ABI_ELFv2 instead of VM_LITTLE_ENDIAN ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2157/files - new: https://git.openjdk.java.net/jdk/pull/2157/files/9cedffac..e4f7cac0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2157&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2157&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2157.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2157/head:pull/2157 PR: https://git.openjdk.java.net/jdk/pull/2157 From MRasmussen at perforce.com Thu Jan 21 13:31:43 2021 From: MRasmussen at perforce.com (Michael Rasmussen) Date: Thu, 21 Jan 2021 13:31:43 +0000 Subject: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 In-Reply-To: References: , Message-ID: OK, managed to make a very simple reproduceable test: package com.test; import net.bytebuddy.agent.ByteBuddyAgent; import java.lang.instrument.Instrumentation; public class Main { public static void main(String[] args) throws Exception { final Instrumentation instrumentation = ByteBuddyAgent.install(); Foo.class.isSealed(); instrumentation.retransformClasses(Bar.class); } static sealed interface Foo permits Bar {} static final class Bar implements Foo {} } -- java.exe -showversion --enable-preview -Xlog:class+redefine+load=trace "-Xlog:sealed*=trace" -classpath target\classes;lib\asm-9.0.jar;lib\byte-buddy-agent-1.10.19.jar com.test.Main openjdk version "16-ea" 2021-03-16 OpenJDK Runtime Environment (build 16-ea+32-2190) OpenJDK 64-Bit Server VM (build 16-ea+32-2190, mixed mode, sharing) [0.271s][trace][class,sealed] Checking for permitted subclass of com.test.Main$Bar in com.test.Main$Foo [0.271s][trace][class,sealed] - Found it at permitted_subclasses[0] => cp[11] [0.273s][debug][redefine,class,load] loading name=com.test.Main$Bar kind=101 (avail_mem=22046284K) [0.273s][trace][class,sealed ] Checking for permitted subclass of com.test.Main$Bar in com.test.Main$Foo [0.273s][trace][class,sealed ] - class is NOT a permitted subclass! Exception in thread "main" java.lang.VerifyError at java.instrument/sun.instrument.InstrumentationImpl.retransformClasses0(Native Method) at java.instrument/sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:168) at com.test.Main.main(Main.java:13) /Michael ________________________________ From: Harold Seigel Sent: 19 January 2021 22:52 To: Michael Rasmussen ; hotspot-dev at openjdk.java.net Subject: Re: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 Hi Michael, I entered bug https://bugs.openjdk.java.net/browse/JDK-8260009 for this problem. Thank you for reporting it. Harold ________________________________ From: hotspot-dev on behalf of Michael Rasmussen Sent: Tuesday, January 19, 2021 3:27 PM To: hotspot-dev at openjdk.java.net Subject: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 Hi, I noticed a regression in the verification of sealed classes, that I've narrowed down to happening between jdk-16+27 and jdk-16+28. Retransforming or redefining a sealed class can lead to a JVMTI_ERROR_FAILS_VERIFICATION, with Exception (0x00000000feb820a0), even though the class actually does that. I've tried to investigate the reason, and from what I can tell, it boils down to the check in InstanceKlass::has_as_permitted_subclass. In jdk-16+27, this method always seems to take the Symbol branch (_constants->tag_at(cp_index).is_klass() is false). But for jdk-16+28, it takes the Klass branch after the classes are loaded, and from what I can tell the (k2 == k) comparison can then fail during the redefinition since the Klass stored in the _permitted_subclasses is not the same as the one being verified, as a new InstanceKlass is allocated for the stream parser. Unfortunately, I haven't been able to produce a small self-contained test example, but I can reliably reproduce it while developing JRebel (which utilizes class retransformation), but hopefully the above is at least helpful in finding the issue and fixing it. /Michael This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. CAUTION: This email originated from outside of the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. From hseigel at openjdk.java.net Thu Jan 21 13:48:16 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 21 Jan 2021 13:48:16 GMT Subject: RFR: 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined Message-ID: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> Please review this fix for JDK-8260009. The fix removes the "if (k2 == k)" check for a valid permitted subclass because the check does not work if "k" is being redefined. It fails because 'k' is a temporary InstanceKlass created when loading the redefined class. Instead, the code relies on a name check to determine if 'k' is a permitted subclass. The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and JCK Lang and VM tests. Thanks, Harold ------------- Commit messages: - 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined Changes: https://git.openjdk.java.net/jdk/pull/2184/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2184&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260009 Stats: 145 lines in 2 files changed: 131 ins; 9 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2184.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2184/head:pull/2184 PR: https://git.openjdk.java.net/jdk/pull/2184 From coleenp at openjdk.java.net Thu Jan 21 13:55:28 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 21 Jan 2021 13:55:28 GMT Subject: RFR: 8259882: Reduce the inclusion of perfData.hpp In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 04:24:27 GMT, Ioi Lam wrote: > perfData.hpp is about 1000 lines long, and is included by 829 out of about 1000 HotSpot .o files. > > Several popular headers (such as synchronizer.hpp, objectMonitor.hpp, threadLocalAllocBuffer.hpp) include perfData.hpp. However, since these headers just declare pointers like > > PerfCounter* foo; > > there's no need to include perfData.hpp. A forward declaration of the PerfCount type would suffice. > > With forward declaration, we can remove perfData.hpp from these headers. This reduces the number of .o files that include perfData.hpp to 183. Build time of HotSpot is reduced by about 0.4%. > > **Note:** the forward declaration is in the new file perfDataTypes.hpp. It contains typedefs to make "aliases" of the types. These are probably relics from the past, where new classes like`PerfIntConstant` were to be added but that never happened. > > typedef PerfLongSampleHelper PerfSampleHelper; > typedef PerfLongConstant PerfConstant; > typedef PerfLongCounter PerfCounter; > typedef PerfLongVariable PerfVariable; > > The HotSpot code uses both the "real" type and the "alias" type (mostly the latter). I don't want to deal with the alises for now, so I just moved them from perfData.hpp to perfDataTypes.hpp. We should probably just rename `PerfLongConstant` to `PerfConstant` in a future RFE. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ok. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2123 From kbarrett at openjdk.java.net Thu Jan 21 15:43:32 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 21 Jan 2021 15:43:32 GMT Subject: RFR: JDK-8260030: Improve stringStream buffer handling In-Reply-To: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> References: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> Message-ID: On Wed, 20 Jan 2021 10:27:11 GMT, Thomas Stuefe wrote: > stringStream objects are used as temporary string buffers a lot in hotspot. When investigating JDK-8259710, I found that a large majority of the stringStreams created never use the backing buffer fully; about 70% of all streams write less than 32 characters. > > stringStream creates an backing buffer, C-heap allocated, with a default size of 256 characters. Some things could be improved: > > - add a small in-object buffer for the first n characters to be written. This would avoid or at least delay allocation of the backing buffer from C-heap, at the expense of slightly increased object size and one memcpy when switching over to C-heap. Note that if the backing buffer is smaller than what now is the default size, the total footprint will go down despite the increased object size. > > - Delaying allocation of the backing buffer would be good for the many cases where stringStream objects are created as temporary objects without being actually used, see eg. compile.hpp `class PrintInliningBuffer` > > - Besides all that, the code could benefit from a little grooming (using modern style syntax etc). > > ---- > > This patch: > > - renames members of stringStream to conform to common syntax (eg leading underscores) and to be clearer > - Uses initialization lists > - Factors out buffer growth code from stringStream::write() to a new function stringStream::grow() > - Introduces a new object-internal mini buffer, `stringStream::_small_buffer`, sized 32 bytes, which is initially used for all writes > > This patch drastically reduces the number of malloc calls done from this class. The internal buffer size of 32byte seems a good cut-off. Running some unrelated test program (no tracing active), I see a reduction in the number of malloc calls from stringStream from ~211K malloc calls down to 53K (debug VM). In a release VM, it drops from ~85K down to about 1K. The reason is that `stringStream` is used in a ton of places as a temporary stack allocated object, to write very minimal text snippets to. > > I also tweaked the associated gtest to test more thoroughly. Changes requested by kbarrett (Reviewer). src/hotspot/share/utilities/ostream.cpp line 341: > 339: assert(new_capacity > _capacity, "Sanity"); > 340: assert(new_capacity > sizeof(_small_buffer), "Sanity"); > 341: assert(!_is_fixed, "Don't call for caller provided buffers"); I think the !_is_fixed assert should be first. src/hotspot/share/utilities/ostream.cpp line 357: > 355: void stringStream::write(const char* s, size_t len) { > 356: size_t write_len = len; // number of non-null bytes to write > 357: size_t end = _written + len + 1; // position after write and final '\0' There's a risk of arithmetic overflow here, if len is "bad". Can this be rewritten to be more careful? Though maybe an assert that end <= _written is sufficient, as line 369 already protects against buffer overrun. Also, the comments aren't lined up. src/hotspot/share/utilities/ostream.cpp line 407: > 405: > 406: stringStream::~stringStream() { > 407: if (_is_fixed == false && _buffer != NULL && _buffer != _small_buffer) { `_is_fixed == false` => `!_is_fixed` Is `_buffer == NULL` actually possible now? src/hotspot/share/utilities/ostream.hpp line 196: > 194: class stringStream : public outputStream { > 195: protected: > 196: char* _buffer; Consider changing the protected members to private. There are no derived classes, and probably shouldn't be without more work. src/hotspot/share/utilities/ostream.cpp line 389: > 387: > 388: void stringStream::reset() { > 389: _written = 0; _precount = 0; _position = 0; Is it a pre-existing bug that this doesn't also have `_newlines = 0;` ? src/hotspot/share/utilities/ostream.hpp line 200: > 198: size_t _capacity; > 199: const bool _is_fixed; > 200: char _small_buffer[32]; I'm a little surprised that 32 bytes is that effective. Any idea how much better (in malloc avoidance) a few more words would be? Since 32 bytes isn't really all that much. src/hotspot/share/utilities/ostream.cpp line 396: > 394: char* copy = c_heap ? > 395: NEW_C_HEAP_ARRAY(char, _written + 1, mtInternal) : NEW_RESOURCE_ARRAY(char, _written + 1); > 396: strncpy(copy, _buffer, _written); Pre-existing: Should this really be using strncpy rather than memcpy? strncpy will stop at an embedded NUL. ------------- PR: https://git.openjdk.java.net/jdk/pull/2160 From stuefe at openjdk.java.net Thu Jan 21 17:12:32 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 21 Jan 2021 17:12:32 GMT Subject: RFR: JDK-8260030: Improve stringStream buffer handling In-Reply-To: References: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> Message-ID: On Thu, 21 Jan 2021 13:47:47 GMT, Kim Barrett wrote: >> stringStream objects are used as temporary string buffers a lot in hotspot. When investigating JDK-8259710, I found that a large majority of the stringStreams created never use the backing buffer fully; about 70% of all streams write less than 32 characters. >> >> stringStream creates an backing buffer, C-heap allocated, with a default size of 256 characters. Some things could be improved: >> >> - add a small in-object buffer for the first n characters to be written. This would avoid or at least delay allocation of the backing buffer from C-heap, at the expense of slightly increased object size and one memcpy when switching over to C-heap. Note that if the backing buffer is smaller than what now is the default size, the total footprint will go down despite the increased object size. >> >> - Delaying allocation of the backing buffer would be good for the many cases where stringStream objects are created as temporary objects without being actually used, see eg. compile.hpp `class PrintInliningBuffer` >> >> - Besides all that, the code could benefit from a little grooming (using modern style syntax etc). >> >> ---- >> >> This patch: >> >> - renames members of stringStream to conform to common syntax (eg leading underscores) and to be clearer >> - Uses initialization lists >> - Factors out buffer growth code from stringStream::write() to a new function stringStream::grow() >> - Introduces a new object-internal mini buffer, `stringStream::_small_buffer`, sized 32 bytes, which is initially used for all writes >> >> This patch drastically reduces the number of malloc calls done from this class. The internal buffer size of 32byte seems a good cut-off. Running some unrelated test program (no tracing active), I see a reduction in the number of malloc calls from stringStream from ~211K malloc calls down to 53K (debug VM). In a release VM, it drops from ~85K down to about 1K. The reason is that `stringStream` is used in a ton of places as a temporary stack allocated object, to write very minimal text snippets to. >> >> I also tweaked the associated gtest to test more thoroughly. > > src/hotspot/share/utilities/ostream.cpp line 341: > >> 339: assert(new_capacity > _capacity, "Sanity"); >> 340: assert(new_capacity > sizeof(_small_buffer), "Sanity"); >> 341: assert(!_is_fixed, "Don't call for caller provided buffers"); > > I think the !_is_fixed assert should be first. Will do. > src/hotspot/share/utilities/ostream.cpp line 357: > >> 355: void stringStream::write(const char* s, size_t len) { >> 356: size_t write_len = len; // number of non-null bytes to write >> 357: size_t end = _written + len + 1; // position after write and final '\0' > > There's a risk of arithmetic overflow here, if len is "bad". Can this be > rewritten to be more careful? Though maybe an assert that end <= _written > is sufficient, as line 369 already protects against buffer overrun. > Also, the comments aren't lined up. I'll rewrite this coding to be safer. > src/hotspot/share/utilities/ostream.cpp line 407: > >> 405: >> 406: stringStream::~stringStream() { >> 407: if (_is_fixed == false && _buffer != NULL && _buffer != _small_buffer) { > > `_is_fixed == false` => `!_is_fixed` > Is `_buffer == NULL` actually possible now? No, you are right. I'll remove it. free would accept NULL anyway, so there is not even a risk. > src/hotspot/share/utilities/ostream.hpp line 196: > >> 194: class stringStream : public outputStream { >> 195: protected: >> 196: char* _buffer; > > Consider changing the protected members to private. There are no > derived classes, and probably shouldn't be without more work. Very good, I'll do it. > src/hotspot/share/utilities/ostream.cpp line 389: > >> 387: >> 388: void stringStream::reset() { >> 389: _written = 0; _precount = 0; _position = 0; > > Is it a pre-existing bug that this doesn't also have `_newlines = 0;` ? Strictly speaking yes. But _newlines is really only used as a very circumvent way to trigger a flush in defaultStream::write() if the last write contained a newline. We could probably throw _newlines completely away at the cost of a `strchr(s, '\n')` in defaultStream::write(). I'll remove the outside accessor `newlines()` at least, since its not used, and will correct stringStream::reset(), so it is consistent for now. I leave the cleanup for another day. > src/hotspot/share/utilities/ostream.cpp line 396: > >> 394: char* copy = c_heap ? >> 395: NEW_C_HEAP_ARRAY(char, _written + 1, mtInternal) : NEW_RESOURCE_ARRAY(char, _written + 1); >> 396: strncpy(copy, _buffer, _written); > > Pre-existing: Should this really be using strncpy rather than memcpy? > strncpy will stop at an embedded NUL. Sure, I'll switch it to memcpy. Its probably more efficient. The content should not contain embedded zeros, but since we do not test on write, they can slip in. Using memcpy would be at least consistent with write(). ------------- PR: https://git.openjdk.java.net/jdk/pull/2160 From dcubed at openjdk.java.net Thu Jan 21 18:12:43 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 21 Jan 2021 18:12:43 GMT Subject: RFR: 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined In-Reply-To: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> References: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> Message-ID: On Thu, 21 Jan 2021 13:41:44 GMT, Harold Seigel wrote: > Please review this fix for JDK-8260009. The fix removes the "if (k2 == k)" check for a valid permitted subclass because the check does not work if "k" is being redefined. It fails because 'k' is a temporary InstanceKlass created when loading the redefined class. > > Instead, the code relies on a name check to determine if 'k' is a permitted subclass. > > The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and JCK Lang and VM tests. > > Thanks, Harold @sspitsyn - This issue might interest you. ------------- PR: https://git.openjdk.java.net/jdk/pull/2184 From stuefe at openjdk.java.net Thu Jan 21 18:24:00 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 21 Jan 2021 18:24:00 GMT Subject: RFR: JDK-8260030: Improve stringStream buffer handling In-Reply-To: References: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> Message-ID: On Thu, 21 Jan 2021 14:27:29 GMT, Kim Barrett wrote: >> stringStream objects are used as temporary string buffers a lot in hotspot. When investigating JDK-8259710, I found that a large majority of the stringStreams created never use the backing buffer fully; about 70% of all streams write less than 32 characters. >> >> stringStream creates an backing buffer, C-heap allocated, with a default size of 256 characters. Some things could be improved: >> >> - add a small in-object buffer for the first n characters to be written. This would avoid or at least delay allocation of the backing buffer from C-heap, at the expense of slightly increased object size and one memcpy when switching over to C-heap. Note that if the backing buffer is smaller than what now is the default size, the total footprint will go down despite the increased object size. >> >> - Delaying allocation of the backing buffer would be good for the many cases where stringStream objects are created as temporary objects without being actually used, see eg. compile.hpp `class PrintInliningBuffer` >> >> - Besides all that, the code could benefit from a little grooming (using modern style syntax etc). >> >> ---- >> >> This patch: >> >> - renames members of stringStream to conform to common syntax (eg leading underscores) and to be clearer >> - Uses initialization lists >> - Factors out buffer growth code from stringStream::write() to a new function stringStream::grow() >> - Introduces a new object-internal mini buffer, `stringStream::_small_buffer`, sized 32 bytes, which is initially used for all writes >> >> This patch drastically reduces the number of malloc calls done from this class. The internal buffer size of 32byte seems a good cut-off. Running some unrelated test program (no tracing active), I see a reduction in the number of malloc calls from stringStream from ~211K malloc calls down to 53K (debug VM). In a release VM, it drops from ~85K down to about 1K. The reason is that `stringStream` is used in a ton of places as a temporary stack allocated object, to write very minimal text snippets to. >> >> I also tweaked the associated gtest to test more thoroughly. > > src/hotspot/share/utilities/ostream.hpp line 200: > >> 198: size_t _capacity; >> 199: const bool _is_fixed; >> 200: char _small_buffer[32]; > > I'm a little surprised that 32 bytes is that effective. Any idea how much better > (in malloc avoidance) a few more words would be? Since 32 bytes isn't really > all that much. I was surprised too. I did not want to blow up the stringStream object too much because I was afraid someone may use it on stack in a recursion. I even considered melting the buffer and the buffer pointer into a union to save space, since you only need either one or the other, but the coding got too complex and it felt overengineered. I did some tests: java -version debug: <32:1038 (86%), <48:111 (9%), <64:42 (3%), >=64:4 (0%) release: <32:449 (84%), <48:54 (10%), <64:26 (4%), >=64:4 (0%) Running some unrelated test program, no tracing, doing metaspace stuff debug: <32:151985 (52%), <48:83341 (28%), <64:46916 (16%), >=64:6445 (2%) release: <32:84123 (49%), <48:80332 (47%), <64:871 (0%), >=64:3567 (2%) same test with -XX:+PrintOptoInlining, which creates many temporary stringStream objects with large buffers debug: <32:160311 (52%), <48:83661 (27%), <64:47821 (15%), >=64:15345 (4%) So, depending on the scenario, increasing the buffer size to 48 may give us between 10% and almost 30% more cases. Beyond that the effect strongly diminishes. I will increase it to 48. ------------- PR: https://git.openjdk.java.net/jdk/pull/2160 From stuefe at openjdk.java.net Thu Jan 21 18:45:35 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 21 Jan 2021 18:45:35 GMT Subject: RFR: JDK-8260030: Improve stringStream buffer handling [v2] In-Reply-To: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> References: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> Message-ID: > stringStream objects are used as temporary string buffers a lot in hotspot. When investigating JDK-8259710, I found that a large majority of the stringStreams created never use the backing buffer fully; about 70% of all streams write less than 32 characters. > > stringStream creates an backing buffer, C-heap allocated, with a default size of 256 characters. Some things could be improved: > > - add a small in-object buffer for the first n characters to be written. This would avoid or at least delay allocation of the backing buffer from C-heap, at the expense of slightly increased object size and one memcpy when switching over to C-heap. Note that if the backing buffer is smaller than what now is the default size, the total footprint will go down despite the increased object size. > > - Delaying allocation of the backing buffer would be good for the many cases where stringStream objects are created as temporary objects without being actually used, see eg. compile.hpp `class PrintInliningBuffer` > > - Besides all that, the code could benefit from a little grooming (using modern style syntax etc). > > ---- > > This patch: > > - renames members of stringStream to conform to common syntax (eg leading underscores) and to be clearer > - Uses initialization lists > - Factors out buffer growth code from stringStream::write() to a new function stringStream::grow() > - Introduces a new object-internal mini buffer, `stringStream::_small_buffer`, sized 32 bytes, which is initially used for all writes > > This patch drastically reduces the number of malloc calls done from this class. The internal buffer size of 32byte seems a good cut-off. Running some unrelated test program (no tracing active), I see a reduction in the number of malloc calls from stringStream from ~211K malloc calls down to 53K (debug VM). In a release VM, it drops from ~85K down to about 1K. The reason is that `stringStream` is used in a ton of places as a temporary stack allocated object, to write very minimal text snippets to. > > I also tweaked the associated gtest to test more thoroughly. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Kim Feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2160/files - new: https://git.openjdk.java.net/jdk/pull/2160/files/4a869bba..cced1e79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2160&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2160&range=00-01 Stats: 29 lines in 2 files changed: 9 ins; 4 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/2160.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2160/head:pull/2160 PR: https://git.openjdk.java.net/jdk/pull/2160 From stuefe at openjdk.java.net Thu Jan 21 18:45:38 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 21 Jan 2021 18:45:38 GMT Subject: RFR: JDK-8260030: Improve stringStream buffer handling [v2] In-Reply-To: References: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> Message-ID: On Thu, 21 Jan 2021 14:44:06 GMT, Kim Barrett wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Kim Feedback > > Changes requested by kbarrett (Reviewer). I rewrote stringStream::write somewhat: - I check and ignore len==0 - I check len for unreasonably high values (>1G). I assert, in release I return: stringStream is used for tracing a lot and we never touch all tracing code in debug. I did not add a overflow check, though I could, since overflow would require very high values for _written (> SIZE_MAX - 1G) which is not possible. - I changed the guarantee to an assert, and added a similar assert to the start of the function ------------- PR: https://git.openjdk.java.net/jdk/pull/2160 From lfoltan at openjdk.java.net Thu Jan 21 18:49:43 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 21 Jan 2021 18:49:43 GMT Subject: RFR: 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined In-Reply-To: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> References: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> Message-ID: On Thu, 21 Jan 2021 13:41:44 GMT, Harold Seigel wrote: > Please review this fix for JDK-8260009. The fix removes the "if (k2 == k)" check for a valid permitted subclass because the check does not work if "k" is being redefined. It fails because 'k' is a temporary InstanceKlass created when loading the redefined class. > > Instead, the code relies on a name check to determine if 'k' is a permitted subclass. > > The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and JCK Lang and VM tests. > > Thanks, Harold Looks good Harold! Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2184 From sspitsyn at openjdk.java.net Thu Jan 21 21:02:01 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 21 Jan 2021 21:02:01 GMT Subject: RFR: 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined In-Reply-To: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> References: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> Message-ID: On Thu, 21 Jan 2021 13:41:44 GMT, Harold Seigel wrote: > Please review this fix for JDK-8260009. The fix removes the "if (k2 == k)" check for a valid permitted subclass because the check does not work if "k" is being redefined. It fails because 'k' is a temporary InstanceKlass created when loading the redefined class. > > Instead, the code relies on a name check to determine if 'k' is a permitted subclass. > > The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and JCK Lang and VM tests. > > Thanks, Harold Hi Harold, The fix looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2184 From dholmes at openjdk.java.net Thu Jan 21 22:19:05 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 21 Jan 2021 22:19:05 GMT Subject: RFR: 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined In-Reply-To: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> References: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> Message-ID: <-G0EtW4hP0o5nLsC1jfsQaimAZltIszNemvr3u5uWZc=.a684691e-f1a1-45d9-bcd2-fb27e866efd0@github.com> On Thu, 21 Jan 2021 13:41:44 GMT, Harold Seigel wrote: > Please review this fix for JDK-8260009. The fix removes the "if (k2 == k)" check for a valid permitted subclass because the check does not work if "k" is being redefined. It fails because 'k' is a temporary InstanceKlass created when loading the redefined class. > > Instead, the code relies on a name check to determine if 'k' is a permitted subclass. > > The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and JCK Lang and VM tests. > > Thanks, Harold Hi Harold, This makes me wonder whether we can have a similar issue with nestmate checking? Just curious: is there any way to determine that a Klass k2 is actually a redefinition of Klass k1? I One nit below, otherwise this seems fine. Thanks, David src/hotspot/share/oops/instanceKlass.cpp line 255: > 253: // Do not check for a resolved cp entry, because that check can fail if > 254: // the class is being redefined. Just do a name check. > 255: // We don't want to resolve any class other than the one being checked. You don't resolve any classes at all now so this comment can go. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2184 From david.holmes at oracle.com Thu Jan 21 22:23:05 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Jan 2021 08:23:05 +1000 Subject: RFR: 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined In-Reply-To: <-G0EtW4hP0o5nLsC1jfsQaimAZltIszNemvr3u5uWZc=.a684691e-f1a1-45d9-bcd2-fb27e866efd0@github.com> References: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> <-G0EtW4hP0o5nLsC1jfsQaimAZltIszNemvr3u5uWZc=.a684691e-f1a1-45d9-bcd2-fb27e866efd0@github.com> Message-ID: On 22/01/2021 8:19 am, David Holmes wrote: > On Thu, 21 Jan 2021 13:41:44 GMT, Harold Seigel wrote: > >> Please review this fix for JDK-8260009. The fix removes the "if (k2 == k)" check for a valid permitted subclass because the check does not work if "k" is being redefined. It fails because 'k' is a temporary InstanceKlass created when loading the redefined class. >> >> Instead, the code relies on a name check to determine if 'k' is a permitted subclass. >> >> The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and JCK Lang and VM tests. >> >> Thanks, Harold > > Hi Harold, > > This makes me wonder whether we can have a similar issue with nestmate checking? Thinking more, I think not. IIUC the issue here is that the permitted subclass check happens as part of redefinition - correct? Whereas there is no nestmate access check as part of redefinition. David > Just curious: is there any way to determine that a Klass k2 is actually a redefinition of Klass k1? I > > One nit below, otherwise this seems fine. > > Thanks, > David > > src/hotspot/share/oops/instanceKlass.cpp line 255: > >> 253: // Do not check for a resolved cp entry, because that check can fail if >> 254: // the class is being redefined. Just do a name check. >> 255: // We don't want to resolve any class other than the one being checked. > > You don't resolve any classes at all now so this comment can go. > > ------------- > > Marked as reviewed by dholmes (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/2184 > From kbarrett at openjdk.java.net Thu Jan 21 23:33:11 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 21 Jan 2021 23:33:11 GMT Subject: RFR: JDK-8260030: Improve stringStream buffer handling [v2] In-Reply-To: References: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> Message-ID: On Thu, 21 Jan 2021 18:45:35 GMT, Thomas Stuefe wrote: >> stringStream objects are used as temporary string buffers a lot in hotspot. When investigating JDK-8259710, I found that a large majority of the stringStreams created never use the backing buffer fully; about 70% of all streams write less than 32 characters. >> >> stringStream creates an backing buffer, C-heap allocated, with a default size of 256 characters. Some things could be improved: >> >> - add a small in-object buffer for the first n characters to be written. This would avoid or at least delay allocation of the backing buffer from C-heap, at the expense of slightly increased object size and one memcpy when switching over to C-heap. Note that if the backing buffer is smaller than what now is the default size, the total footprint will go down despite the increased object size. >> >> - Delaying allocation of the backing buffer would be good for the many cases where stringStream objects are created as temporary objects without being actually used, see eg. compile.hpp `class PrintInliningBuffer` >> >> - Besides all that, the code could benefit from a little grooming (using modern style syntax etc). >> >> ---- >> >> This patch: >> >> - renames members of stringStream to conform to common syntax (eg leading underscores) and to be clearer >> - Uses initialization lists >> - Factors out buffer growth code from stringStream::write() to a new function stringStream::grow() >> - Introduces a new object-internal mini buffer, `stringStream::_small_buffer`, sized 32 bytes, which is initially used for all writes >> >> This patch drastically reduces the number of malloc calls done from this class. The internal buffer size of 32byte seems a good cut-off. Running some unrelated test program (no tracing active), I see a reduction in the number of malloc calls from stringStream from ~211K malloc calls down to 53K (debug VM). In a release VM, it drops from ~85K down to about 1K. The reason is that `stringStream` is used in a ton of places as a temporary stack allocated object, to write very minimal text snippets to. >> >> I also tweaked the associated gtest to test more thoroughly. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Kim Feedback Other than the minor nit about use of `_is_fixed` in the destructor, looks good. src/hotspot/share/utilities/ostream.cpp line 414: > 412: > 413: stringStream::~stringStream() { > 414: if (_is_fixed == false && _buffer != _small_buffer) { Still using `_is_fixed == false` rather than `!_is_fixed`. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2160 From kvn at openjdk.java.net Fri Jan 22 01:48:49 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 01:48:49 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 23:06:19 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Fix another s390 compilation failure src/hotspot/share/aot/aotCodeHeap.cpp line 194: > 192: // AOT libs are loaded before heap initialized so shift values are not set. > 193: // It is okay since ObjectAlignmentInBytes flag which defines shifts value is set before AOT libs are loaded. > 194: // Set shifts value based on first AOT library config. Why this code is removed? src/hotspot/share/compiler/compileBroker.cpp line 972: > 970: > 971: // Initialize the compilation queue > 972: if (_c2_count > 0) { Is ZERO treated as `is_interpreter_only()` ? How this change works with ZERO? src/hotspot/share/runtime/vmStructs.cpp line 296: > 294: JVMTI_ONLY(nonstatic_field(MethodCounters, _number_of_breakpoints, u2)) \ > 295: nonstatic_field(MethodCounters, _invocation_counter, InvocationCounter) \ > 296: nonstatic_field(MethodCounters, _backedge_counter, InvocationCounter) \ You need to fix SA agent: https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodCounters.java#L52 src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 229: > 227: JVMTI_ONLY(nonstatic_field(MethodCounters, _number_of_breakpoints, u2)) \ > 228: nonstatic_field(MethodCounters, _invocation_counter, InvocationCounter) \ > 229: nonstatic_field(MethodCounters, _backedge_counter, InvocationCounter) \ I don't see Java JVMCI changes. Do you need them? test/hotspot/jtreg/TEST.quick-groups line 1787: > 1785: vmTestbase/jit/t/t112/t112.java \ > 1786: vmTestbase/jit/t/t113/t113.java \ > 1787: vmTestbase/jit/verifier/VerifyInitLocal/VerifyInitLocal.java \ Why this test removed? ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 01:48:46 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 01:48:46 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 05:04:11 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Check legacy flags validity before deriving flag values for emulation mode. I would also suggest to do performance runs. Ask Eric for help. Changes are significant and may affect performance due to some typo. src/hotspot/share/compiler/compilerDefinitions.hpp line 234: > 232: static bool is_interpreter_only() { > 233: return Arguments::is_interpreter_only() || TieredStopAtLevel == CompLevel_none; > 234: } Can you move these functions after has_*() functions? They are used before. src/hotspot/share/compiler/compilerDefinitions.hpp line 179: > 177: } > 178: // Is the JVM in a configuration that permits only c2-compiled methods? > 179: // JVMCI compiler replaces C2. The comment `JVMCI compiler replaces C2.` should be removed or moved to `is_jvmci_compiler_only()` where it is make more sense. src/hotspot/share/compiler/compilerDefinitions.hpp line 171: > 169: } > 170: > 171: static bool is_c2_available() { For me `_available` suffix sounds similar to `has_`. May be `_enabled` is better. At least it is less confusing where it is called. src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp line 1414: > 1412: // use LD;DMB but stores use STLR. This can happen if C2 compiles > 1413: // the stores in one method and C1 compiles the loads in another. > 1414: if (!CompilerConfig::is_c1_or_interpreter_only_no_aot_or_jvmci()) { It is C1 code which should not be executed in -Xint. Why check `interpreter_only`? src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp line 54: > 52: ShenandoahBarrierSet::assembler()->cmpxchg_oop(masm->masm(), addr, cmpval, newval, /*acquire*/ true, /*release*/ true, /*is_cae*/ false, result); > 53: > 54: if (CompilerConfig::is_c1_or_interpreter_only_no_aot_or_jvmci()) { Again about `interpreter_only` check. src/hotspot/share/compiler/compilerDefinitions.hpp line 243: > 241: static bool is_c1_only_no_aot_or_jvmci() { > 242: return is_c1_only() && !is_aot() && !is_jvmci(); > 243: } These names are a little confusing: what about C2, why only no AOT and JVMCI. I understand that you want to check if JVMCI or AOT can install their compiled code. May be `is_c1_nmethods_only`, `is_c1_nmethods_or_interpreter_only` ? src/hotspot/share/oops/method.cpp line 1013: > 1011: return false; > 1012: if (comp_level == CompLevel_any) > 1013: return is_not_c1_compilable() && is_not_c2_compilable(); Was it bug before? src/hotspot/share/compiler/compilerDefinitions.cpp line 62: > 60: } > 61: } else if (strcmp(CompilationMode, "high-only") == 0) { > 62: if (!CompilerConfig::has_c2() && !CompilerConfig::is_jvmci_compiler()) { Is using `!is_c2_or_jvmci_compiler_available()` better here? All flags should be processed at this point. And we could have some `TieredStopAtLevel` flags. It looks like you have cross dependency between CompilerConfig and CompilationModeFlag which make using `is_c2_or_jvmci_compiler_available()` impossible here. src/hotspot/share/compiler/compilerDefinitions.cpp line 84: > 82: } else if (CompilerConfig::is_c2_or_jvmci_compiler_only()) { > 83: _mode = Mode::HIGH_ONLY; > 84: } else if (CompilerConfig::is_jvmci_compiler() && !TieredCompilation) { Should you check `CompilerConfig::is_tiered()` instead of `TieredCompilation` flag? ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iklam at openjdk.java.net Fri Jan 22 04:03:07 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 22 Jan 2021 04:03:07 GMT Subject: RFR: 8259882: Reduce the inclusion of perfData.hpp [v2] In-Reply-To: References: Message-ID: <2AspoeC-G5MeG97TTA8UW6Tqns2nrN7Qrw5zgRERDhY=.aade698a-b7a9-4b7d-a956-075c117c3e40@github.com> > perfData.hpp is about 1000 lines long, and is included by 829 out of about 1000 HotSpot .o files. > > Several popular headers (such as synchronizer.hpp, objectMonitor.hpp, threadLocalAllocBuffer.hpp) include perfData.hpp. However, since these headers just declare pointers like > > PerfCounter* foo; > > there's no need to include perfData.hpp. A forward declaration of the PerfCount type would suffice. > > With forward declaration, we can remove perfData.hpp from these headers. This reduces the number of .o files that include perfData.hpp to 183. Build time of HotSpot is reduced by about 0.4%. > > **Note:** the forward declaration is in the new file perfDataTypes.hpp. It contains typedefs to make "aliases" of the types. These are probably relics from the past, where new classes like`PerfIntConstant` were to be added but that never happened. > > typedef PerfLongSampleHelper PerfSampleHelper; > typedef PerfLongConstant PerfConstant; > typedef PerfLongCounter PerfCounter; > typedef PerfLongVariable PerfVariable; > > The HotSpot code uses both the "real" type and the "alias" type (mostly the latter). I don't want to deal with the alises for now, so I just moved them from perfData.hpp to perfDataTypes.hpp. We should probably just rename `PerfLongConstant` to `PerfConstant` in a future RFE. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - removed inadvertent edit - Merge branch 'master' into 8259882-reduce-inclusion-of-perfData.hpp - 8259882: Reduce the inclusion of perfData.hpp ------------- Changes: https://git.openjdk.java.net/jdk/pull/2123/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2123&range=01 Stats: 115 lines in 23 files changed: 72 ins; 20 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/2123.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2123/head:pull/2123 PR: https://git.openjdk.java.net/jdk/pull/2123 From iklam at openjdk.java.net Fri Jan 22 04:23:18 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 22 Jan 2021 04:23:18 GMT Subject: RFR: 8259882: Reduce the inclusion of perfData.hpp [v2] In-Reply-To: <2HuiruAVj21BM7Ji9IcN4CX4N8mLPJfCjz0lVYMGY98=.23f60a29-55b1-4430-a66c-e9590c70b011@github.com> References: <2HuiruAVj21BM7Ji9IcN4CX4N8mLPJfCjz0lVYMGY98=.23f60a29-55b1-4430-a66c-e9590c70b011@github.com> Message-ID: On Wed, 20 Jan 2021 23:19:12 GMT, Claes Redestad wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - removed inadvertent edit >> - Merge branch 'master' into 8259882-reduce-inclusion-of-perfData.hpp >> - 8259882: Reduce the inclusion of perfData.hpp > > Looks good to me. Thanks @cl4es and @coleenp for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/2123 From iklam at openjdk.java.net Fri Jan 22 04:28:20 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 22 Jan 2021 04:28:20 GMT Subject: Integrated: 8259882: Reduce the inclusion of perfData.hpp In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 04:24:27 GMT, Ioi Lam wrote: > perfData.hpp is about 1000 lines long, and is included by 829 out of about 1000 HotSpot .o files. > > Several popular headers (such as synchronizer.hpp, objectMonitor.hpp, threadLocalAllocBuffer.hpp) include perfData.hpp. However, since these headers just declare pointers like > > PerfCounter* foo; > > there's no need to include perfData.hpp. A forward declaration of the PerfCount type would suffice. > > With forward declaration, we can remove perfData.hpp from these headers. This reduces the number of .o files that include perfData.hpp to 183. Build time of HotSpot is reduced by about 0.4%. > > **Note:** the forward declaration is in the new file perfDataTypes.hpp. It contains typedefs to make "aliases" of the types. These are probably relics from the past, where new classes like`PerfIntConstant` were to be added but that never happened. > > typedef PerfLongSampleHelper PerfSampleHelper; > typedef PerfLongConstant PerfConstant; > typedef PerfLongCounter PerfCounter; > typedef PerfLongVariable PerfVariable; > > The HotSpot code uses both the "real" type and the "alias" type (mostly the latter). I don't want to deal with the alises for now, so I just moved them from perfData.hpp to perfDataTypes.hpp. We should probably just rename `PerfLongConstant` to `PerfConstant` in a future RFE. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. This pull request has now been integrated. Changeset: ba386615 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/ba386615 Stats: 115 lines in 23 files changed: 72 ins; 20 del; 23 mod 8259882: Reduce the inclusion of perfData.hpp Reviewed-by: redestad, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/2123 From ccheung at openjdk.java.net Fri Jan 22 04:39:37 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 22 Jan 2021 04:39:37 GMT Subject: RFR: 8259214: MetaspaceClosure support for Arrays of MetaspaceObj [v4] In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 20:13:10 GMT, Ioi Lam wrote: >> Currently, `MetaspaceClosure::push` supports only the following variants: >> >> MetaspaceClosure* it = ...; >> Klass* o = ...; it->push(&o); >> Array* a1 = ...; it->push(&a1); >> Array* a2 = ...; it->push(&a2); >> >> In Valhalla, support is needed for the following variant (Annotation is a subtype of MetaspaceObj): >> >> Array* a3 = ...; it->push(&a3); >> >> This change will allow CDS to make a copy of this array, as well as relocating all the pointers embedded in the elements of this array. See a test case in test_metaspaceClosure.cpp. >> >> I also cleaned up the code (with help from @kimbarrett) to use SFINAE to dispatch from `MetaspaceClosure::push` to the different subtypes of `MetaspaceClosure::Ref`. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Remove RefMatcher and go back to overloaded template functions for push(...) Looks good. I spotted some typos in metaspaceClosure.hpp. src/hotspot/share/memory/metaspaceClosure.hpp line 209: > 207: > 208: // OtherArrayRef -- iterate an instance of Array, where T is NOT a subtype of MetaspaceObj. > 209: // T can be a primitive type, since as int, or a structure. However, we do not scan typo: s/since/such src/hotspot/share/memory/metaspaceClosure.hpp line 321: > 319: // Klass* o = ...; it->push(&o); => MSORef > 320: // Array* a1 = ...; it->push(&a1); => OtherArrayRef > 321: // Array* a2 = ...; it->push(&a3); => MSOArrayRef &a3 should be &a2? src/hotspot/share/memory/metaspaceClosure.hpp line 322: > 320: // Array* a1 = ...; it->push(&a1); => OtherArrayRef > 321: // Array* a2 = ...; it->push(&a3); => MSOArrayRef > 322: // Array* a3 = ...; it->push(&a2); => MSOPointerArrayRef &a2 should be &a3? src/hotspot/share/memory/metaspaceClosure.hpp line 323: > 321: // Array* a2 = ...; it->push(&a3); => MSOArrayRef > 322: // Array* a3 = ...; it->push(&a2); => MSOPointerArrayRef > 323: // Array*>* a4 = ...; it->push(&a3); => MSOPointerArrayRef &a3 should be &a4? src/hotspot/share/memory/metaspaceClosure.hpp line 324: > 322: // Array* a3 = ...; it->push(&a2); => MSOPointerArrayRef > 323: // Array*>* a4 = ...; it->push(&a3); => MSOPointerArrayRef > 324: // Array* a5 = ...; it->push(&a3); => MSOPointerArrayRef Array* should be Array* ? &a3 should be &a5? ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1995 From stuefe at openjdk.java.net Fri Jan 22 09:04:15 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 22 Jan 2021 09:04:15 GMT Subject: RFR: JDK-8260030: Improve stringStream buffer handling [v3] In-Reply-To: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> References: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> Message-ID: > stringStream objects are used as temporary string buffers a lot in hotspot. When investigating JDK-8259710, I found that a large majority of the stringStreams created never use the backing buffer fully; about 70% of all streams write less than 32 characters. > > stringStream creates an backing buffer, C-heap allocated, with a default size of 256 characters. Some things could be improved: > > - add a small in-object buffer for the first n characters to be written. This would avoid or at least delay allocation of the backing buffer from C-heap, at the expense of slightly increased object size and one memcpy when switching over to C-heap. Note that if the backing buffer is smaller than what now is the default size, the total footprint will go down despite the increased object size. > > - Delaying allocation of the backing buffer would be good for the many cases where stringStream objects are created as temporary objects without being actually used, see eg. compile.hpp `class PrintInliningBuffer` > > - Besides all that, the code could benefit from a little grooming (using modern style syntax etc). > > ---- > > This patch: > > - renames members of stringStream to conform to common syntax (eg leading underscores) and to be clearer > - Uses initialization lists > - Factors out buffer growth code from stringStream::write() to a new function stringStream::grow() > - Introduces a new object-internal mini buffer, `stringStream::_small_buffer`, sized 32 bytes, which is initially used for all writes > > This patch drastically reduces the number of malloc calls done from this class. The internal buffer size of 32byte seems a good cut-off. Running some unrelated test program (no tracing active), I see a reduction in the number of malloc calls from stringStream from ~211K malloc calls down to 53K (debug VM). In a release VM, it drops from ~85K down to about 1K. The reason is that `stringStream` is used in a ton of places as a temporary stack allocated object, to write very minimal text snippets to. > > I also tweaked the associated gtest to test more thoroughly. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Use ! instead of false for is_fixed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2160/files - new: https://git.openjdk.java.net/jdk/pull/2160/files/cced1e79..caf62f09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2160&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2160&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2160.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2160/head:pull/2160 PR: https://git.openjdk.java.net/jdk/pull/2160 From stuefe at openjdk.java.net Fri Jan 22 09:04:17 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 22 Jan 2021 09:04:17 GMT Subject: RFR: JDK-8260030: Improve stringStream buffer handling [v2] In-Reply-To: References: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> Message-ID: On Thu, 21 Jan 2021 23:30:05 GMT, Kim Barrett wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Kim Feedback > > Other than the minor nit about use of `_is_fixed` in the destructor, looks good. Thanks Kim, Ioi. > src/hotspot/share/utilities/ostream.cpp line 414: > >> 412: >> 413: stringStream::~stringStream() { >> 414: if (_is_fixed == false && _buffer != _small_buffer) { > > Still using `_is_fixed == false` rather than `!_is_fixed`. Oh, I missed that, sorry. Will fix before integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/2160 From stuefe at openjdk.java.net Fri Jan 22 09:04:19 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 22 Jan 2021 09:04:19 GMT Subject: Integrated: JDK-8260030: Improve stringStream buffer handling In-Reply-To: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> References: <-azhWESdnNUc7cDldFVh4cugV9Bxixt0xJsU5tDryPQ=.d524ebc6-da4b-4f89-83fd-86799e5ca1d9@github.com> Message-ID: On Wed, 20 Jan 2021 10:27:11 GMT, Thomas Stuefe wrote: > stringStream objects are used as temporary string buffers a lot in hotspot. When investigating JDK-8259710, I found that a large majority of the stringStreams created never use the backing buffer fully; about 70% of all streams write less than 32 characters. > > stringStream creates an backing buffer, C-heap allocated, with a default size of 256 characters. Some things could be improved: > > - add a small in-object buffer for the first n characters to be written. This would avoid or at least delay allocation of the backing buffer from C-heap, at the expense of slightly increased object size and one memcpy when switching over to C-heap. Note that if the backing buffer is smaller than what now is the default size, the total footprint will go down despite the increased object size. > > - Delaying allocation of the backing buffer would be good for the many cases where stringStream objects are created as temporary objects without being actually used, see eg. compile.hpp `class PrintInliningBuffer` > > - Besides all that, the code could benefit from a little grooming (using modern style syntax etc). > > ---- > > This patch: > > - renames members of stringStream to conform to common syntax (eg leading underscores) and to be clearer > - Uses initialization lists > - Factors out buffer growth code from stringStream::write() to a new function stringStream::grow() > - Introduces a new object-internal mini buffer, `stringStream::_small_buffer`, sized 32 bytes, which is initially used for all writes > > This patch drastically reduces the number of malloc calls done from this class. The internal buffer size of 32byte seems a good cut-off. Running some unrelated test program (no tracing active), I see a reduction in the number of malloc calls from stringStream from ~211K malloc calls down to 53K (debug VM). In a release VM, it drops from ~85K down to about 1K. The reason is that `stringStream` is used in a ton of places as a temporary stack allocated object, to write very minimal text snippets to. > > I also tweaked the associated gtest to test more thoroughly. This pull request has now been integrated. Changeset: d066f2b0 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/d066f2b0 Stats: 102 lines in 3 files changed: 35 ins; 6 del; 61 mod 8260030: Improve stringStream buffer handling Reviewed-by: iklam, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/2160 From sjohanss at openjdk.java.net Fri Jan 22 09:37:53 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 22 Jan 2021 09:37:53 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:55:06 GMT, Denghui Dong wrote: >> GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. >> >> For the test purpose, I add two Whitebox methods to lock/unlock critical. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > Refactor based on comments Some comments. src/hotspot/share/gc/shared/gcTraceSend.cpp line 354: > 352: > 353: void GCLockerTracer::start_gc_locker(const jint jni_lock_count) { > 354: assert(SafepointSynchronize::is_at_safepoint(), "sanity"); Maybe add assertions that `_jni_lock_count` and `_stall_count` is 0 to ensure this is not called multiple times for a single event. src/hotspot/share/gc/shared/gcTraceSend.cpp line 369: > 367: void GCLockerTracer::report_gc_locker() { > 368: Ticks zero; > 369: if (_needs_gc_start_timestamp != zero) { Why is this needed? src/hotspot/share/gc/shared/gcTraceSend.cpp line 372: > 370: EventGCLocker event(UNTIMED); > 371: if (event.should_commit()) { > 372: event.set_starttime(_needs_gc_start_timestamp); Shouldn't you also set the endtime using `event.set_endtime(...)`? src/hotspot/share/gc/shared/gcTraceSend.cpp line 378: > 376: } > 377: _needs_gc_start_timestamp = zero; > 378: _stall_count = 0; Any reason to not clear `_jni_lock_count`? It would be needed for the assert suggested above. ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Fri Jan 22 13:31:11 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 22 Jan 2021 13:31:11 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 09:17:45 GMT, Stefan Johansson wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor based on comments > > src/hotspot/share/gc/shared/gcTraceSend.cpp line 354: > >> 352: >> 353: void GCLockerTracer::start_gc_locker(const jint jni_lock_count) { >> 354: assert(SafepointSynchronize::is_at_safepoint(), "sanity"); > > Maybe add assertions that `_jni_lock_count` and `_stall_count` is 0 to ensure this is not called multiple times for a single event. Makes sense. Added. > src/hotspot/share/gc/shared/gcTraceSend.cpp line 369: > >> 367: void GCLockerTracer::report_gc_locker() { >> 368: Ticks zero; >> 369: if (_needs_gc_start_timestamp != zero) { > > Why is this needed? Because we can't assume that EventGCLocker is enabled when GC locker is started, in another word, at the beginning and end of the GC locker, whether EventGCLocker is enabled may be inconsistent. So check here if _needs_gc_start_timestamp is not zero, if it is not 0, it needs to reset _needs_gc_start_timestamp regardless of whether the event will be sent. > src/hotspot/share/gc/shared/gcTraceSend.cpp line 372: > >> 370: EventGCLocker event(UNTIMED); >> 371: if (event.should_commit()) { >> 372: event.set_starttime(_needs_gc_start_timestamp); > > Shouldn't you also set the endtime using `event.set_endtime(...)`? endtime will be set in event.commit() > src/hotspot/share/gc/shared/gcTraceSend.cpp line 378: > >> 376: } >> 377: _needs_gc_start_timestamp = zero; >> 378: _stall_count = 0; > > Any reason to not clear `_jni_lock_count`? It would be needed for the assert suggested above. There is no special reason, just to save memory access. It's okay for me to reset it. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Fri Jan 22 13:31:09 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 22 Jan 2021 13:31:09 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v3] In-Reply-To: References: Message-ID: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: add assertions and reset _jni_lock_count ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2088/files - new: https://git.openjdk.java.net/jdk/pull/2088/files/c36d4f96..41641d8a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=01-02 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2088/head:pull/2088 PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Fri Jan 22 13:33:53 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 22 Jan 2021 13:33:53 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 09:35:04 GMT, Stefan Johansson wrote: > Some comments. Thanks for the review :) ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From hseigel at openjdk.java.net Fri Jan 22 13:46:17 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 22 Jan 2021 13:46:17 GMT Subject: RFR: 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined [v2] In-Reply-To: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> References: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> Message-ID: > Please review this fix for JDK-8260009. The fix removes the "if (k2 == k)" check for a valid permitted subclass because the check does not work if "k" is being redefined. It fails because 'k' is a temporary InstanceKlass created when loading the redefined class. > > Instead, the code relies on a name check to determine if 'k' is a permitted subclass. > > The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and JCK Lang and VM tests. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8260009: remove comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2184/files - new: https://git.openjdk.java.net/jdk/pull/2184/files/ca70228f..2303ef1d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2184&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2184&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2184.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2184/head:pull/2184 PR: https://git.openjdk.java.net/jdk/pull/2184 From eosterlund at openjdk.java.net Fri Jan 22 13:50:53 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 22 Jan 2021 13:50:53 GMT Subject: RFR: 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE In-Reply-To: <4sH9-Ili4eHGu7VOvOCYqmZ9ZGzxqH9kyyw6Qlzk-C8=.3424a2d5-80ae-4c98-9a0d-c3a215a29d5b@github.com> References: <4sH9-Ili4eHGu7VOvOCYqmZ9ZGzxqH9kyyw6Qlzk-C8=.3424a2d5-80ae-4c98-9a0d-c3a215a29d5b@github.com> Message-ID: <9m1bmXmM1NYcMbOjphUFL0vNH2Rp8ii0a4eLSRnpCvA=.d9cdaf9d-c5f0-43eb-bde9-cf0a6ecbe052@github.com> On Mon, 18 Jan 2021 14:07:36 GMT, Kim Barrett wrote: > [Restarting this PR after some offline discussion with jrose. New name for > the macro, and some additional commentary and tests.] > > Please review this change which adds the ENABLE_IF_SDEFN macro. This is > used in the definition of a function template when that definition is > separate from a declaration that uses ENABLE_IF. > > Alternative names for the new macro are possible and even solicited. I > know, I'm asking for bikeshedding. > > The ENABLE_IF macro provides convenient syntax for function template SFINAE > using the new default template parameter feature of C++11. However, this > macro can only be used in the function declaration (which may also be a > definition). > > The syntax needed in a definition that is separate from the declaration is > different, but the type forms for the non-type template parameters in the > two places must be "equivalent" (C++14 14.5.6). The precise form for > ENABLE_IF is "hidden" behind the macro. It is not desirable to have > template definitions making assumptions about that form. This suggests > there should be a second macro for use in the separate definition case, with > the two macros maintained together to ensure the necessary consistency. > > (Note that some versions of gcc permit the unused default in some separate > definitions. Other tool chains reject it. Because of this, I was only > vaguely aware of (and had long forgotten) about this issue when proposing > ENABLE_IF, despite having extensively used similar mechanisms in other code > bases.) > > This gives the following usage: > > template::value)> > void foo(T x) { ... } > > and this for separate declaration and definition. > > template::value)> > void foo(T x); > > // later separate definition > template::value)> > void foo(T x) { ... } > > (An alternative would be to just drop the macro usage entirely, at least in > the separate definition case, and just accept the additional syntactic > complexity. I'm not proposing that.) > > (Since I was touching the file anyway, I also improved some of the comments > discussing details) > > Testing: > mach5 tier1 > This includes some new gtests for the macros. > There aren't any current non-test uses of ENABLE_IF_SDEFN yet. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2129 From hseigel at openjdk.java.net Fri Jan 22 13:55:53 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 22 Jan 2021 13:55:53 GMT Subject: RFR: 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined [v2] In-Reply-To: <-G0EtW4hP0o5nLsC1jfsQaimAZltIszNemvr3u5uWZc=.a684691e-f1a1-45d9-bcd2-fb27e866efd0@github.com> References: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> <-G0EtW4hP0o5nLsC1jfsQaimAZltIszNemvr3u5uWZc=.a684691e-f1a1-45d9-bcd2-fb27e866efd0@github.com> Message-ID: On Thu, 21 Jan 2021 22:15:36 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8260009: remove comment > > Hi Harold, > > This makes me wonder whether we can have a similar issue with nestmate checking? > > Just curious: is there any way to determine that a Klass k2 is actually a redefinition of Klass k1? I > > One nit below, otherwise this seems fine. > > Thanks, > David Hi David, I agree that this is not an issue for nestmates. Class redefinition loads the redefined class, and class loading calls verify_member_access(), which does a nestmate check for private access. But, class loading only calls verify_member_access() for accessing non-private methods, when doing method override checking in check_final_method_override(). Thanks, Harold ________________________________ From: mlbridge[bot] Sent: Thursday, January 21, 2021 5:25 PM To: openjdk/jdk Cc: Harold Seigel ; Mention Subject: [External] : Re: [openjdk/jdk] 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined (#2184) Mailing list message from David Holmes on hotspot-dev: On 22/01/2021 8:19 am, David Holmes wrote: On Thu, 21 Jan 2021 13:41:44 GMT, Harold Seigel wrote: Please review this fix for JDK-8260009. The fix removes the "if (k2 == k)" check for a valid permitted subclass because the check does not work if "k" is being redefined. It fails because 'k' is a temporary InstanceKlass created when loading the redefined class. Instead, the code relies on a name check to determine if 'k' is a permitted subclass. The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and JCK Lang and VM tests. Thanks, Harold Hi Harold, This makes me wonder whether we can have a similar issue with nestmate checking? Thinking more, I think not. IIUC the issue here is that the permitted subclass check happens as part of redefinition - correct? Whereas there is no nestmate access check as part of redefinition. David ? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. > src/hotspot/share/oops/instanceKlass.cpp line 255: > >> 253: // Do not check for a resolved cp entry, because that check can fail if >> 254: // the class is being redefined. Just do a name check. >> 255: // We don't want to resolve any class other than the one being checked. > > You don't resolve any classes at all now so this comment can go. comment was deleted. ------------- PR: https://git.openjdk.java.net/jdk/pull/2184 From hseigel at openjdk.java.net Fri Jan 22 13:55:54 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 22 Jan 2021 13:55:54 GMT Subject: RFR: 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined [v2] In-Reply-To: References: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> <-G0EtW4hP0o5nLsC1jfsQaimAZltIszNemvr3u5uWZc=.a684691e-f1a1-45d9-bcd2-fb27e866efd0@github.com> Message-ID: On Fri, 22 Jan 2021 13:49:40 GMT, Harold Seigel wrote: >> Hi Harold, >> >> This makes me wonder whether we can have a similar issue with nestmate checking? >> >> Just curious: is there any way to determine that a Klass k2 is actually a redefinition of Klass k1? I >> >> One nit below, otherwise this seems fine. >> >> Thanks, >> David > > Hi David, > > I agree that this is not an issue for nestmates. Class redefinition loads the redefined class, and class loading calls verify_member_access(), which does a nestmate check for private access. But, class loading only calls verify_member_access() for accessing non-private methods, when doing method override checking in check_final_method_override(). > > Thanks, Harold > ________________________________ > From: mlbridge[bot] > Sent: Thursday, January 21, 2021 5:25 PM > To: openjdk/jdk > Cc: Harold Seigel ; Mention > Subject: [External] : Re: [openjdk/jdk] 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined (#2184) > > > Mailing list message from David Holmes on hotspot-dev: > > On 22/01/2021 8:19 am, David Holmes wrote: > > On Thu, 21 Jan 2021 13:41:44 GMT, Harold Seigel wrote: > > Please review this fix for JDK-8260009. The fix removes the "if (k2 == k)" check for a valid permitted subclass because the check does not work if "k" is being redefined. It fails because 'k' is a temporary InstanceKlass created when loading the redefined class. > > Instead, the code relies on a name check to determine if 'k' is a permitted subclass. > > The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and JCK Lang and VM tests. > > Thanks, Harold > > Hi Harold, > > This makes me wonder whether we can have a similar issue with nestmate checking? > > Thinking more, I think not. IIUC the issue here is that the permitted > subclass check happens as part of redefinition - correct? Whereas there > is no nestmate access check as part of redefinition. > > David > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or unsubscribe. Thanks Lois, Serguei, and David for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/2184 From hseigel at openjdk.java.net Fri Jan 22 13:55:56 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 22 Jan 2021 13:55:56 GMT Subject: Integrated: 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined In-Reply-To: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> References: <4DNm9wNdH5LO00ISdx2Soq8BKHmgImaNVMOAoQrDBnk=.e518d3b8-d1fc-47f4-8f55-37bea1cac4fe@github.com> Message-ID: On Thu, 21 Jan 2021 13:41:44 GMT, Harold Seigel wrote: > Please review this fix for JDK-8260009. The fix removes the "if (k2 == k)" check for a valid permitted subclass because the check does not work if "k" is being redefined. It fails because 'k' is a temporary InstanceKlass created when loading the redefined class. > > Instead, the code relies on a name check to determine if 'k' is a permitted subclass. > > The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, tiers 3-5 on Linux x64, and JCK Lang and VM tests. > > Thanks, Harold This pull request has now been integrated. Changeset: f928265e Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/f928265e Stats: 145 lines in 2 files changed: 130 ins; 11 del; 4 mod 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined Reviewed-by: lfoltan, sspitsyn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/2184 From kbarrett at openjdk.java.net Fri Jan 22 14:08:07 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 22 Jan 2021 14:08:07 GMT Subject: RFR: 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE In-Reply-To: <9m1bmXmM1NYcMbOjphUFL0vNH2Rp8ii0a4eLSRnpCvA=.d9cdaf9d-c5f0-43eb-bde9-cf0a6ecbe052@github.com> References: <4sH9-Ili4eHGu7VOvOCYqmZ9ZGzxqH9kyyw6Qlzk-C8=.3424a2d5-80ae-4c98-9a0d-c3a215a29d5b@github.com> <9m1bmXmM1NYcMbOjphUFL0vNH2Rp8ii0a4eLSRnpCvA=.d9cdaf9d-c5f0-43eb-bde9-cf0a6ecbe052@github.com> Message-ID: On Fri, 22 Jan 2021 13:47:49 GMT, Erik ?sterlund wrote: >> [Restarting this PR after some offline discussion with jrose. New name for >> the macro, and some additional commentary and tests.] >> >> Please review this change which adds the ENABLE_IF_SDEFN macro. This is >> used in the definition of a function template when that definition is >> separate from a declaration that uses ENABLE_IF. >> >> Alternative names for the new macro are possible and even solicited. I >> know, I'm asking for bikeshedding. >> >> The ENABLE_IF macro provides convenient syntax for function template SFINAE >> using the new default template parameter feature of C++11. However, this >> macro can only be used in the function declaration (which may also be a >> definition). >> >> The syntax needed in a definition that is separate from the declaration is >> different, but the type forms for the non-type template parameters in the >> two places must be "equivalent" (C++14 14.5.6). The precise form for >> ENABLE_IF is "hidden" behind the macro. It is not desirable to have >> template definitions making assumptions about that form. This suggests >> there should be a second macro for use in the separate definition case, with >> the two macros maintained together to ensure the necessary consistency. >> >> (Note that some versions of gcc permit the unused default in some separate >> definitions. Other tool chains reject it. Because of this, I was only >> vaguely aware of (and had long forgotten) about this issue when proposing >> ENABLE_IF, despite having extensively used similar mechanisms in other code >> bases.) >> >> This gives the following usage: >> >> template::value)> >> void foo(T x) { ... } >> >> and this for separate declaration and definition. >> >> template::value)> >> void foo(T x); >> >> // later separate definition >> template::value)> >> void foo(T x) { ... } >> >> (An alternative would be to just drop the macro usage entirely, at least in >> the separate definition case, and just accept the additional syntactic >> complexity. I'm not proposing that.) >> >> (Since I was touching the file anyway, I also improved some of the comments >> discussing details) >> >> Testing: >> mach5 tier1 >> This includes some new gtests for the macros. >> There aren't any current non-test uses of ENABLE_IF_SDEFN yet. > > Looks good. Thanks @fisk for review. ------------- PR: https://git.openjdk.java.net/jdk/pull/2129 From kbarrett at openjdk.java.net Fri Jan 22 14:48:12 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 22 Jan 2021 14:48:12 GMT Subject: RFR: 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE [v2] In-Reply-To: <4sH9-Ili4eHGu7VOvOCYqmZ9ZGzxqH9kyyw6Qlzk-C8=.3424a2d5-80ae-4c98-9a0d-c3a215a29d5b@github.com> References: <4sH9-Ili4eHGu7VOvOCYqmZ9ZGzxqH9kyyw6Qlzk-C8=.3424a2d5-80ae-4c98-9a0d-c3a215a29d5b@github.com> Message-ID: > [Restarting this PR after some offline discussion with jrose. New name for > the macro, and some additional commentary and tests.] > > Please review this change which adds the ENABLE_IF_SDEFN macro. This is > used in the definition of a function template when that definition is > separate from a declaration that uses ENABLE_IF. > > Alternative names for the new macro are possible and even solicited. I > know, I'm asking for bikeshedding. > > The ENABLE_IF macro provides convenient syntax for function template SFINAE > using the new default template parameter feature of C++11. However, this > macro can only be used in the function declaration (which may also be a > definition). > > The syntax needed in a definition that is separate from the declaration is > different, but the type forms for the non-type template parameters in the > two places must be "equivalent" (C++14 14.5.6). The precise form for > ENABLE_IF is "hidden" behind the macro. It is not desirable to have > template definitions making assumptions about that form. This suggests > there should be a second macro for use in the separate definition case, with > the two macros maintained together to ensure the necessary consistency. > > (Note that some versions of gcc permit the unused default in some separate > definitions. Other tool chains reject it. Because of this, I was only > vaguely aware of (and had long forgotten) about this issue when proposing > ENABLE_IF, despite having extensively used similar mechanisms in other code > bases.) > > This gives the following usage: > > template::value)> > void foo(T x) { ... } > > and this for separate declaration and definition. > > template::value)> > void foo(T x); > > // later separate definition > template::value)> > void foo(T x) { ... } > > (An alternative would be to just drop the macro usage entirely, at least in > the separate definition case, and just accept the additional syntactic > complexity. I'm not proposing that.) > > (Since I was touching the file anyway, I also improved some of the comments > discussing details) > > Testing: > mach5 tier1 > This includes some new gtests for the macros. > There aren't any current non-test uses of ENABLE_IF_SDEFN yet. Kim Barrett 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 enable_if_param - rename to ENABLE_IF_SDEFN - Add ENABLE_IF_PARAM, unit tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2129/files - new: https://git.openjdk.java.net/jdk/pull/2129/files/bbd78dff..5764b7e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2129&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2129&range=00-01 Stats: 79171 lines in 2225 files changed: 28825 ins; 32603 del; 17743 mod Patch: https://git.openjdk.java.net/jdk/pull/2129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2129/head:pull/2129 PR: https://git.openjdk.java.net/jdk/pull/2129 From kbarrett at openjdk.java.net Fri Jan 22 14:48:13 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 22 Jan 2021 14:48:13 GMT Subject: Integrated: 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE In-Reply-To: <4sH9-Ili4eHGu7VOvOCYqmZ9ZGzxqH9kyyw6Qlzk-C8=.3424a2d5-80ae-4c98-9a0d-c3a215a29d5b@github.com> References: <4sH9-Ili4eHGu7VOvOCYqmZ9ZGzxqH9kyyw6Qlzk-C8=.3424a2d5-80ae-4c98-9a0d-c3a215a29d5b@github.com> Message-ID: On Mon, 18 Jan 2021 14:07:36 GMT, Kim Barrett wrote: > [Restarting this PR after some offline discussion with jrose. New name for > the macro, and some additional commentary and tests.] > > Please review this change which adds the ENABLE_IF_SDEFN macro. This is > used in the definition of a function template when that definition is > separate from a declaration that uses ENABLE_IF. > > Alternative names for the new macro are possible and even solicited. I > know, I'm asking for bikeshedding. > > The ENABLE_IF macro provides convenient syntax for function template SFINAE > using the new default template parameter feature of C++11. However, this > macro can only be used in the function declaration (which may also be a > definition). > > The syntax needed in a definition that is separate from the declaration is > different, but the type forms for the non-type template parameters in the > two places must be "equivalent" (C++14 14.5.6). The precise form for > ENABLE_IF is "hidden" behind the macro. It is not desirable to have > template definitions making assumptions about that form. This suggests > there should be a second macro for use in the separate definition case, with > the two macros maintained together to ensure the necessary consistency. > > (Note that some versions of gcc permit the unused default in some separate > definitions. Other tool chains reject it. Because of this, I was only > vaguely aware of (and had long forgotten) about this issue when proposing > ENABLE_IF, despite having extensively used similar mechanisms in other code > bases.) > > This gives the following usage: > > template::value)> > void foo(T x) { ... } > > and this for separate declaration and definition. > > template::value)> > void foo(T x); > > // later separate definition > template::value)> > void foo(T x) { ... } > > (An alternative would be to just drop the macro usage entirely, at least in > the separate definition case, and just accept the additional syntactic > complexity. I'm not proposing that.) > > (Since I was touching the file anyway, I also improved some of the comments > discussing details) > > Testing: > mach5 tier1 > This includes some new gtests for the macros. > There aren't any current non-test uses of ENABLE_IF_SDEFN yet. This pull request has now been integrated. Changeset: a97f3c18 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/a97f3c18 Stats: 97 lines in 2 files changed: 85 ins; 0 del; 12 mod 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE Add ENABLE_IF_SDEFN, unit tests Reviewed-by: jrose, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/2129 From lucy at openjdk.java.net Fri Jan 22 15:00:47 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Fri, 22 Jan 2021 15:00:47 GMT Subject: RFR: 8259383: AsyncGetCallTrace() crashes sporadically In-Reply-To: References: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com> Message-ID: On Wed, 20 Jan 2021 03:36:52 GMT, Andrei Pangin wrote: >> The changes look ok to me. I think it would be good to get someone from the compiler team to verify your reasoning here. > > Hi Lutz, > > Thank you for working on this issue. > I'm not a formal OpenJDK Reviewer, but as an author of async-profiler project (which heavily relies on AsyncGetCallTrace), I'm more or less familiar with this code. Let me leave a few comments. > > 1. The statement `if (candidate.pc() != NULL) return false;` looks a bit odd to me. When a profiler calls AsyncGetCallTrace, pc of the initial frame is obtained from a signal context, and it is never NULL. Returning false when pc != NULL basically invalidates the entire `if (fr->cb() == NULL)` branch. If this was intended, the branch could be simplified. > 2. At the same time, returning false whenever cb == NULL, discards a fair amount of valid stack traces, e.g. when a runtime function is called from Java without switching to in_vm state. I guess, the original intention of that loop was to handle such cases, but, as you noticed, it does not currently work well because of the assertions. I'd rather prefer revising the logic of that loop then instead of dropping all those valid samples. > 3. What I don't really understand from the bug report is why `if (fr->cb() == NULL)` branch is executed at all in this particular example. According to the stack trace from the crash dump, the top frame (before a signal handler) is `ThreadCritical::~ThreadCritical()`. This means, a thread is in_vm state, and its last_Java_frame should have been set. In this case AsyncGetCallTrace prefers to take last_Java_frame, and thus cb should be non-NULL. Another suspicious thing is that a frame below `ThreadCritical::~ThreadCritical()` is not a C frame. This cannot normally happen (the execution is in the middle of `ThreadCritical::~ThreadCritical()`, where the stack frame is consistent). These facts make me think something bad has already happened with the stack earlier, and the failed guarantee is probably just one manifestation of a bigger problem. Spent a lot fo time and many thoughts. Finally, I found out it was all for nothing. The failure doesn't occur at the location I was sure it would. Will invest more time and more thoughts... I'll be back! ------------- PR: https://git.openjdk.java.net/jdk/pull/2032 From iveresov at openjdk.java.net Fri Jan 22 15:22:50 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 15:22:50 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 19:51:11 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.hpp line 234: > >> 232: static bool is_interpreter_only() { >> 233: return Arguments::is_interpreter_only() || TieredStopAtLevel == CompLevel_none; >> 234: } > > Can you move these functions after has_*() functions? They are used before. Right now has_() functions are defined before uses. Do you want them to be after the uses? Please confirm. > src/hotspot/share/compiler/compilerDefinitions.hpp line 179: > >> 177: } >> 178: // Is the JVM in a configuration that permits only c2-compiled methods? >> 179: // JVMCI compiler replaces C2. > > The comment `JVMCI compiler replaces C2.` should be removed or moved to `is_jvmci_compiler_only()` where it is make more sense. I removed the comment, it does seem to be out of context. I'm not sure why I put it there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:02:48 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:02:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 20:17:48 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.hpp line 171: > >> 169: } >> 170: >> 171: static bool is_c2_available() { > > For me `_available` suffix sounds similar to `has_`. May be `_enabled` is better. At least it is less confusing where it is called. Ok, I'll do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:09:52 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:09:52 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: <-XgAzg034eEEPCuR342rrb4r6X-2yLRxGbr2QJgXoLw=.c1926204-ba05-4b70-891d-fd1765cc9778@github.com> On Wed, 20 Jan 2021 20:28:34 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp line 1414: > >> 1412: // use LD;DMB but stores use STLR. This can happen if C2 compiles >> 1413: // the stores in one method and C1 compiles the loads in another. >> 1414: if (!CompilerConfig::is_c1_or_interpreter_only_no_aot_or_jvmci()) { > > It is C1 code which should not be executed in -Xint. Why check `interpreter_only`? Good point, I'll fix that. > src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp line 54: > >> 52: ShenandoahBarrierSet::assembler()->cmpxchg_oop(masm->masm(), addr, cmpval, newval, /*acquire*/ true, /*release*/ true, /*is_cae*/ false, result); >> 53: >> 54: if (CompilerConfig::is_c1_or_interpreter_only_no_aot_or_jvmci()) { > > Again about `interpreter_only` check. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:16:45 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:16:45 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 20:36:35 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/share/aot/aotCodeHeap.cpp line 194: > >> 192: // AOT libs are loaded before heap initialized so shift values are not set. >> 193: // It is okay since ObjectAlignmentInBytes flag which defines shifts value is set before AOT libs are loaded. >> 194: // Set shifts value based on first AOT library config. > > Why this code is removed? It's always running with the tiered policy now. Prior to this change if you attempted to run an AOT library with tiered-style profiling compiled in with the non-tiered policy it wouldn't work correctly. That's why we had this check. Now tiered is the only policy, so it will work correctly whether you have the AOT code with profiling or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:23:47 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:23:47 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 20:52:31 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.hpp line 243: > >> 241: static bool is_c1_only_no_aot_or_jvmci() { >> 242: return is_c1_only() && !is_aot() && !is_jvmci(); >> 243: } > > These names are a little confusing: what about C2, why only no AOT and JVMCI. I understand that you want to check if JVMCI or AOT can install their compiled code. > May be `is_c1_nmethods_only`, `is_c1_nmethods_or_interpreter_only` ? I guess it's a matter of naming convention. What I tried to make the CompilerConfig API about is to check if compilers are present/enabled and in which combination. Of course presence of a compiler implies that we're going to see nmethod produced by it. I'd like to keep the current naming if it's not a huge eyesore for you. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:35:52 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:35:52 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 00:43:29 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/oops/method.cpp line 1013: > >> 1011: return false; >> 1012: if (comp_level == CompLevel_any) >> 1013: return is_not_c1_compilable() && is_not_c2_compilable(); > > Was it bug before? Yup. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:35:48 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:35:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 00:24:34 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/share/compiler/compileBroker.cpp line 972: > >> 970: >> 971: // Initialize the compilation queue >> 972: if (_c2_count > 0) { > > Is ZERO treated as `is_interpreter_only()` ? How this change works with ZERO? I forgot why I removed that. Let me put it back and run it through testing again. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 17:55:47 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 17:55:47 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 00:56:16 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/share/runtime/vmStructs.cpp line 296: > >> 294: JVMTI_ONLY(nonstatic_field(MethodCounters, _number_of_breakpoints, u2)) \ >> 295: nonstatic_field(MethodCounters, _invocation_counter, InvocationCounter) \ >> 296: nonstatic_field(MethodCounters, _backedge_counter, InvocationCounter) \ > > You need to fix SA agent: > https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodCounters.java#L52 Good point. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iklam at openjdk.java.net Fri Jan 22 18:14:45 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 22 Jan 2021 18:14:45 GMT Subject: RFR: 8260306: Do not include osThread.hpp in thread.hpp Message-ID: thread.hpp is a popular header file (included by 856 out of 1000 HotSpot.o file), so we should try to minimize what files are included by thread.hpp. We can replace the inclusion of osThread.hpp with a forward declaration of the OSThread class. This reduces the number of .o files that include osThread.hpp to 42. Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- Commit messages: - 8260306: Do not include osThread.hpp in thread.hpp Changes: https://git.openjdk.java.net/jdk/pull/2198/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2198&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260306 Stats: 31 lines in 19 files changed: 19 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2198.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2198/head:pull/2198 PR: https://git.openjdk.java.net/jdk/pull/2198 From kvn at openjdk.java.net Fri Jan 22 18:22:08 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 18:22:08 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 15:19:39 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compilerDefinitions.hpp line 234: >> >>> 232: static bool is_interpreter_only() { >>> 233: return Arguments::is_interpreter_only() || TieredStopAtLevel == CompLevel_none; >>> 234: } >> >> Can you move these functions after has_*() functions? They are used before. > > Right now has_() functions are defined before uses. Do you want them to be after the uses? Please confirm. Don't touch has_() - they are in correct place. I am asking only to move these 4 is_() functions between has_() and is_c1_only() function. >> src/hotspot/share/compiler/compilerDefinitions.hpp line 243: >> >>> 241: static bool is_c1_only_no_aot_or_jvmci() { >>> 242: return is_c1_only() && !is_aot() && !is_jvmci(); >>> 243: } >> >> These names are a little confusing: what about C2, why only no AOT and JVMCI. I understand that you want to check if JVMCI or AOT can install their compiled code. >> May be `is_c1_nmethods_only`, `is_c1_nmethods_or_interpreter_only` ? > > I guess it's a matter of naming convention. What I tried to make the CompilerConfig API about is to check if compilers are present/enabled and in which combination. Of course presence of a compiler implies that we're going to see nmethod produced by it. I'd like to keep the current naming if it's not a huge eyesore for you. Hmm, may be we don't need these funxctions. Seems is_c1_only() will be true only when JVMCI is off. Right? We can also reinforce it to exclude AOT too. And AOT and JVMCI are disabled with -Xint. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 18:22:09 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 18:22:09 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 01:11:33 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix another s390 compilation failure > > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 229: > >> 227: JVMTI_ONLY(nonstatic_field(MethodCounters, _number_of_breakpoints, u2)) \ >> 228: nonstatic_field(MethodCounters, _invocation_counter, InvocationCounter) \ >> 229: nonstatic_field(MethodCounters, _backedge_counter, InvocationCounter) \ > > I don't see Java JVMCI changes. Do you need them? I haven't found any uses of it. > test/hotspot/jtreg/TEST.quick-groups line 1787: > >> 1785: vmTestbase/jit/t/t112/t112.java \ >> 1786: vmTestbase/jit/t/t113/t113.java \ >> 1787: vmTestbase/jit/verifier/VerifyInitLocal/VerifyInitLocal.java \ > > Why this test removed? It was an odd test that check if the -XX:+PrintTieredEvents flag didn't work with -XX:-TieredCompilation. Since now it always works that test doesn't make much sense anymore. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 18:22:10 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 18:22:10 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: <3tY1BN0Q7o5K4cFcRH_KRk8djNOlMOpzU9yY3XpeaRc=.8128e81c-74b0-43c0-b96b-2eeee24d660d@github.com> On Fri, 22 Jan 2021 17:14:15 GMT, Igor Veresov wrote: >> src/hotspot/share/aot/aotCodeHeap.cpp line 194: >> >>> 192: // AOT libs are loaded before heap initialized so shift values are not set. >>> 193: // It is okay since ObjectAlignmentInBytes flag which defines shifts value is set before AOT libs are loaded. >>> 194: // Set shifts value based on first AOT library config. >> >> Why this code is removed? > > It's always running with the tiered policy now. Prior to this change if you attempted to run an AOT library with tiered-style profiling compiled in with the non-tiered policy it wouldn't work correctly. That's why we had this check. Now tiered is the only policy, so it will work correctly whether you have the AOT code with profiling or not. Okay. Got it ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 18:22:10 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 18:22:10 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 17:51:36 GMT, Vladimir Kozlov wrote: >> Right now has_() functions are defined before uses. Do you want them to be after the uses? Please confirm. > > Don't touch has_() - they are in correct place. I am asking only to move these 4 is_() functions between has_() and is_c1_only() function. I understand what you mean now. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 18:22:11 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 18:22:11 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 01:25:25 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.cpp line 62: > >> 60: } >> 61: } else if (strcmp(CompilationMode, "high-only") == 0) { >> 62: if (!CompilerConfig::has_c2() && !CompilerConfig::is_jvmci_compiler()) { > > Is using `!is_c2_or_jvmci_compiler_available()` better here? All flags should be processed at this point. And we could have some `TieredStopAtLevel` flags. > It looks like you have cross dependency between CompilerConfig and CompilationModeFlag which make using `is_c2_or_jvmci_compiler_available()` impossible here. Yes, there is an unfortunate cross dependency. It would probably work fine since ```_mode``` is initialized to ```NORMAL``` before parsing the flag. But I wanted to not use any function that would depend on the value of the ```_mode``` during parsing. It could create trouble in the future. I'll put more comments about that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 18:29:48 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 18:29:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:04:54 GMT, Vladimir Kozlov wrote: >> I guess it's a matter of naming convention. What I tried to make the CompilerConfig API about is to check if compilers are present/enabled and in which combination. Of course presence of a compiler implies that we're going to see nmethod produced by it. I'd like to keep the current naming if it's not a huge eyesore for you. > > Hmm, may be we don't need these funxctions. > Seems is_c1_only() will be true only when JVMCI is off. Right? We can also reinforce it to exclude AOT too. > And AOT and JVMCI are disabled with -Xint. It's not so easy. You can have AOT or JVMCI enabled with -Xint. JVMCI code installs can be initiated not only as a result of method going through the compiler broker. Remember that you can run Graal in "host" mode, where it is a normal C1/C2 system (or may be just an interpreter); Truffle can work in a mode like that. And you can totally run with AOT and interpreter (without any JIT). ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iklam at openjdk.java.net Fri Jan 22 20:01:51 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 22 Jan 2021 20:01:51 GMT Subject: RFR: 8260307: Do not include method.hpp in frame.hpp Message-ID: frame.hpp is a popular header file (included by 876 out of 1000 HotSpot.o file). It includes method.hpp, which in turn pulls in all the class metadata types such as instanceKlass.hpp, constantPool.hpp, etc. We can replace the inclusion of method.hpp with a forward declaration of the Method class. This reduces the number of .o files that include method.hpp from 882 to 586. HotSpot build time is reduced by more than 2%. Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- Commit messages: - 8260307: Do not include method.hpp in frame.hpp Changes: https://git.openjdk.java.net/jdk/pull/2201/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2201&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260307 Stats: 42 lines in 21 files changed: 25 ins; 1 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/2201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2201/head:pull/2201 PR: https://git.openjdk.java.net/jdk/pull/2201 From iveresov at openjdk.java.net Fri Jan 22 20:02:55 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 20:02:55 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 01:37:53 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Check legacy flags validity before deriving flag values for emulation mode. > > src/hotspot/share/compiler/compilerDefinitions.cpp line 84: > >> 82: } else if (CompilerConfig::is_c2_or_jvmci_compiler_only()) { >> 83: _mode = Mode::HIGH_ONLY; >> 84: } else if (CompilerConfig::is_jvmci_compiler() && !TieredCompilation) { > > Should you check `CompilerConfig::is_tiered()` instead of `TieredCompilation` flag? I wanted to be explicit about what's happening here. I'd like it to be obvious that the we're switching to ```HIGH_ONLY_QUICK_INTERNAL``` mode as a result of the user specifying -XX:-TieredCompilation on the command line. There is a bug on this line however. I should be checking if c1 is present and enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 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 coleenp at openjdk.java.net Fri Jan 22 20:07:47 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 22 Jan 2021 20:07:47 GMT Subject: RFR: 8260306: Do not include osThread.hpp in thread.hpp In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:02:10 GMT, Ioi Lam wrote: > thread.hpp is a popular header file (included by 856 out of 1000 HotSpot.o file), so we should try to minimize what files are included by thread.hpp. > > We can replace the inclusion of osThread.hpp with a forward declaration of the OSThread class. > > This reduces the number of .o files that include osThread.hpp to 42. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2198 From kvn at openjdk.java.net Fri Jan 22 20:07:51 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 20:07:51 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:15:40 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compilerDefinitions.cpp line 62: >> >>> 60: } >>> 61: } else if (strcmp(CompilationMode, "high-only") == 0) { >>> 62: if (!CompilerConfig::has_c2() && !CompilerConfig::is_jvmci_compiler()) { >> >> Is using `!is_c2_or_jvmci_compiler_available()` better here? All flags should be processed at this point. And we could have some `TieredStopAtLevel` flags. >> It looks like you have cross dependency between CompilerConfig and CompilationModeFlag which make using `is_c2_or_jvmci_compiler_available()` impossible here. > > Yes, there is an unfortunate cross dependency. It would probably work fine since ```_mode``` is initialized to ```NORMAL``` before parsing the flag. But I wanted to not use any function that would depend on the value of the ```_mode``` during parsing. It could create trouble in the future. I'll put more comments about that. okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 20:10:53 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 20:10:53 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:26:43 GMT, Igor Veresov wrote: >> Hmm, may be we don't need these funxctions. >> Seems is_c1_only() will be true only when JVMCI is off. Right? We can also reinforce it to exclude AOT too. >> And AOT and JVMCI are disabled with -Xint. > > It's not so easy. You can have AOT or JVMCI enabled with -Xint. JVMCI code installs can be initiated not only as a result of method going through the compiler broker. Remember that you can run Graal in "host" mode, where it is a normal C1/C2 system (or may be just an interpreter); Truffle can work in a mode like that. And you can totally run with AOT and interpreter (without any JIT). I don't think so: > java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -version Java HotSpot(TM) 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. > java -Xint -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -XX:+PrintAOT -version Java HotSpot(TM) 64-Bit Server VM warning: -Xint is not compatible with AOT (switching AOT off) ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Fri Jan 22 20:14:49 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 20:14:49 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 19:50:48 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compilerDefinitions.cpp line 84: >> >>> 82: } else if (CompilerConfig::is_c2_or_jvmci_compiler_only()) { >>> 83: _mode = Mode::HIGH_ONLY; >>> 84: } else if (CompilerConfig::is_jvmci_compiler() && !TieredCompilation) { >> >> Should you check `CompilerConfig::is_tiered()` instead of `TieredCompilation` flag? > > I wanted to be explicit about what's happening here. I'd like it to be obvious that the we're switching to ```HIGH_ONLY_QUICK_INTERNAL``` mode as a result of the user specifying -XX:-TieredCompilation on the command line. > > There is a bug on this line however. I should be checking if c1 is present and enabled. okay ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Fri Jan 22 20:19:49 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 22 Jan 2021 20:19:49 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 20:08:17 GMT, Vladimir Kozlov wrote: >> It's not so easy. You can have AOT or JVMCI enabled with -Xint. JVMCI code installs can be initiated not only as a result of method going through the compiler broker. Remember that you can run Graal in "host" mode, where it is a normal C1/C2 system (or may be just an interpreter); Truffle can work in a mode like that. And you can totally run with AOT and interpreter (without any JIT). > > I don't think so: >> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -version > Java HotSpot(TM) 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. > >> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -XX:+PrintAOT -version > Java HotSpot(TM) 64-Bit Server VM warning: -Xint is not compatible with AOT (switching AOT off) You're right. Perhaps I was overly defensive. It doesn't hurt though, less potential surprises in the future (as you correctly noticed those are used to make sure there are no nmethods produced by any other compiler but C1). Also you still can have a C1 and AOT combination. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From lfoltan at openjdk.java.net Fri Jan 22 20:20:45 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Fri, 22 Jan 2021 20:20:45 GMT Subject: RFR: 8260306: Do not include osThread.hpp in thread.hpp In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:02:10 GMT, Ioi Lam wrote: > thread.hpp is a popular header file (included by 856 out of 1000 HotSpot.o file), so we should try to minimize what files are included by thread.hpp. > > We can replace the inclusion of osThread.hpp with a forward declaration of the OSThread class. > > This reduces the number of .o files that include osThread.hpp to 42. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Looks good. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2198 From lfoltan at openjdk.java.net Fri Jan 22 20:20:45 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Fri, 22 Jan 2021 20:20:45 GMT Subject: RFR: 8260307: Do not include method.hpp in frame.hpp In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:50:48 GMT, Ioi Lam wrote: > frame.hpp is a popular header file (included by 876 out of 1000 HotSpot.o file). It includes method.hpp, which in turn pulls in all the class metadata types such as instanceKlass.hpp, constantPool.hpp, etc. > > We can replace the inclusion of method.hpp with a forward declaration of the Method class. > > This reduces the number of .o files that include method.hpp from 882 to 586. > > HotSpot build time is reduced by more than 2%. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Looks good. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2201 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 kvn at openjdk.java.net Fri Jan 22 20:31:50 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 22 Jan 2021 20:31:50 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 20:17:24 GMT, Igor Veresov wrote: >> I don't think so: >>> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -version >> Java HotSpot(TM) 64-Bit Server VM warning: JVMCI Compiler disabled due to -Xint. >> >>> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -XX:+PrintAOT -version >> Java HotSpot(TM) 64-Bit Server VM warning: -Xint is not compatible with AOT (switching AOT off) > > You're right. Perhaps I was overly defensive. It doesn't hurt though, less potential surprises in the future (as you correctly noticed those are used to make sure there are no nmethods produced by any other compiler but C1). > Also you still can have a C1 and AOT combination. Yes. You can have C1 in combination with AOT and JVMCI (hosted). I looked on use cases for these 4 methods and it seems it will be hard to only use one. Okay. Leave them as it is. May be add comments to explain why you needs these variants. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From coleenp at openjdk.java.net Fri Jan 22 20:33:41 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 22 Jan 2021 20:33:41 GMT Subject: RFR: 8260307: Do not include method.hpp in frame.hpp In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:50:48 GMT, Ioi Lam wrote: > frame.hpp is a popular header file (included by 876 out of 1000 HotSpot.o file). It includes method.hpp, which in turn pulls in all the class metadata types such as instanceKlass.hpp, constantPool.hpp, etc. > > We can replace the inclusion of method.hpp with a forward declaration of the Method class. > > This reduces the number of .o files that include method.hpp from 882 to 586. > > HotSpot build time is reduced by more than 2%. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. This looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2201 From iklam at openjdk.java.net Fri Jan 22 22:51:04 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 22 Jan 2021 22:51:04 GMT Subject: RFR: 8259214: MetaspaceClosure support for Arrays of MetaspaceObj [v5] In-Reply-To: References: Message-ID: > Currently, `MetaspaceClosure::push` supports only the following variants: > > MetaspaceClosure* it = ...; > Klass* o = ...; it->push(&o); > Array* a1 = ...; it->push(&a1); > Array* a2 = ...; it->push(&a2); > > In Valhalla, support is needed for the following variant (Annotation is a subtype of MetaspaceObj): > > Array* a3 = ...; it->push(&a3); > > This change will allow CDS to make a copy of this array, as well as relocating all the pointers embedded in the elements of this array. See a test case in test_metaspaceClosure.cpp. > > I also cleaned up the code (with help from @kimbarrett) to use SFINAE to dispatch from `MetaspaceClosure::push` to the different subtypes of `MetaspaceClosure::Ref`. Ioi Lam 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 six additional commits since the last revision: - Merge branch 'master' into 8259214-MetaspaceClosure-support-for-Arrays-of-MetaspaceObj - Fixed typos per @calvinccheung review comments - Remove RefMatcher and go back to overloaded template functions for push(...) - Updated SFINAE per @kimbarrett offline comments; added test case for disallowed types - fixed typo - 8259214: MetaspaceClosure support for Arrays of MetaspaceObj ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1995/files - new: https://git.openjdk.java.net/jdk/pull/1995/files/84074148..79dd6627 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1995&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1995&range=03-04 Stats: 63721 lines in 1572 files changed: 26967 ins; 27758 del; 8996 mod Patch: https://git.openjdk.java.net/jdk/pull/1995.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1995/head:pull/1995 PR: https://git.openjdk.java.net/jdk/pull/1995 From iklam at openjdk.java.net Fri Jan 22 22:51:05 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 22 Jan 2021 22:51:05 GMT Subject: RFR: 8259214: MetaspaceClosure support for Arrays of MetaspaceObj [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 21:08:24 GMT, Frederic Parain wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove RefMatcher and go back to overloaded template functions for push(...) > > Looks good to me. > Thank you for adding this feature. > > Fred Thanks @fparain and @calvinccheung for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1995 From iklam at openjdk.java.net Fri Jan 22 22:51:07 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 22 Jan 2021 22:51:07 GMT Subject: Integrated: 8259214: MetaspaceClosure support for Arrays of MetaspaceObj In-Reply-To: References: Message-ID: <2VPEkDTdfx6Q2dziexB2yDYE5SKYV4mJ0tNBbnC9pds=.980aa16a-d4f1-420e-9f55-58d46976554f@github.com> On Fri, 8 Jan 2021 00:33:52 GMT, Ioi Lam wrote: > Currently, `MetaspaceClosure::push` supports only the following variants: > > MetaspaceClosure* it = ...; > Klass* o = ...; it->push(&o); > Array* a1 = ...; it->push(&a1); > Array* a2 = ...; it->push(&a2); > > In Valhalla, support is needed for the following variant (Annotation is a subtype of MetaspaceObj): > > Array* a3 = ...; it->push(&a3); > > This change will allow CDS to make a copy of this array, as well as relocating all the pointers embedded in the elements of this array. See a test case in test_metaspaceClosure.cpp. > > I also cleaned up the code (with help from @kimbarrett) to use SFINAE to dispatch from `MetaspaceClosure::push` to the different subtypes of `MetaspaceClosure::Ref`. This pull request has now been integrated. Changeset: aa57d07c Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/aa57d07c Stats: 251 lines in 2 files changed: 203 ins; 9 del; 39 mod 8259214: MetaspaceClosure support for Arrays of MetaspaceObj Reviewed-by: fparain, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/1995 From coleenp at openjdk.java.net Fri Jan 22 23:27:40 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 22 Jan 2021 23:27:40 GMT Subject: RFR: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h [v2] In-Reply-To: <-jIDq0RisaLSuXg2Z9PlB-pWs8Aio6GUbEZTr4ozRJY=.2ed90f9c-b543-4ef3-b4e7-deeca5d0694e@github.com> References: <-jIDq0RisaLSuXg2Z9PlB-pWs8Aio6GUbEZTr4ozRJY=.2ed90f9c-b543-4ef3-b4e7-deeca5d0694e@github.com> Message-ID: On Thu, 21 Jan 2021 03:09:13 GMT, Ioi Lam wrote: >> jvm.h is over 1000 lines long. It is included by 940 out of 1000 HotSpot .o files. However, most of the HotSpot source files just use a small fraction of jvm.h: >> >> - the jio_xxxprintf() functions >> - the JVM_RECOGNIZED_XXX_MODIFIERS defines >> >> We should move these two parts into jvm_io.h and jvm_constants.h. This reduces the files that include jvm.h to about 82 files. Build time of HotSpot is reduced by about 0.4%. >> >> Testing: mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > David Holmes comments Looks good to me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2154 From coleenp at openjdk.java.net Fri Jan 22 23:27:42 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 22 Jan 2021 23:27:42 GMT Subject: RFR: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 03:11:21 GMT, Ioi Lam wrote: >> src/hotspot/share/runtime/os.hpp line 28: >> >>> 26: #define SHARE_RUNTIME_OS_HPP >>> 27: >>> 28: #include "jvm_md.h" >> >> jvm_md.h should not be included directly by any file - it is an internal implementation detail. > > os.hpp is used by almost all HotSpot .o files, so if we keep jvm.h here, that defeats the purpose of this PR. As David and I discussed offline, jvm_md.h is a kludgy legacy porting layer for stuff like DIR, which is used by os.hpp. > > jvm_md.h contains comments like the following that haven't been touched for decades .... so it's probably a good idea to not disturb it now. > > /* > * This file is currently collecting system-specific dregs for the > * JNI conversion, which should be sorted out later. > */ What does os.hpp need from jvm_md.h ? Can that be moved to os.cpp ? I guess I can look at the file and answer my own question. ------------- PR: https://git.openjdk.java.net/jdk/pull/2154 From iklam at openjdk.java.net Fri Jan 22 23:36:40 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 22 Jan 2021 23:36:40 GMT Subject: RFR: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 23:24:26 GMT, Coleen Phillimore wrote: >> os.hpp is used by almost all HotSpot .o files, so if we keep jvm.h here, that defeats the purpose of this PR. As David and I discussed offline, jvm_md.h is a kludgy legacy porting layer for stuff like DIR, which is used by os.hpp. >> >> jvm_md.h contains comments like the following that haven't been touched for decades .... so it's probably a good idea to not disturb it now. >> >> /* >> * This file is currently collecting system-specific dregs for the >> * JNI conversion, which should be sorted out later. >> */ > > What does os.hpp need from jvm_md.h ? Can that be moved to os.cpp ? I guess I can look at the file and answer my own question. One reason is that os.hpp uses `DIR` in function declarations, and `DIR` is declared in jvm_md.h in a platform-dependent way. So we can't forward-declare `DIR` in os.hpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/2154 From jwilhelm at openjdk.java.net Sat Jan 23 02:19:01 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Sat, 23 Jan 2021 02:19:01 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region" - 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation - 8227695: assert(pss->trim_ticks().seconds() == 0.0) failed: Unexpected partial trimming during evacuation - 8255199: Catching a few NumberFormatExceptions in xmldsig - 8247619: Improve Direct Buffering of Characters The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2207&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2207&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2207/files Stats: 131 lines in 11 files changed: 111 ins; 4 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/2207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2207/head:pull/2207 PR: https://git.openjdk.java.net/jdk/pull/2207 From jwilhelm at openjdk.java.net Sat Jan 23 03:19:42 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Sat, 23 Jan 2021 03:19:42 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 02:13:06 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 6f2a3943 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/6f2a3943 Stats: 131 lines in 11 files changed: 111 ins; 4 del; 16 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2207 From iklam at openjdk.java.net Sat Jan 23 06:28:57 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 23 Jan 2021 06:28:57 GMT Subject: RFR: 8260307: Do not include method.hpp in frame.hpp [v2] In-Reply-To: References: Message-ID: > frame.hpp is a popular header file (included by 876 out of 1000 HotSpot.o file). It includes method.hpp, which in turn pulls in all the class metadata types such as instanceKlass.hpp, constantPool.hpp, etc. > > We can replace the inclusion of method.hpp with a forward declaration of the Method class. > > This reduces the number of .o files that include method.hpp from 882 to 586. > > HotSpot build time is reduced by more than 2%. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam 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' of https://github.com/openjdk/jdk into 8260307-do-not-include-method.hpp-in-frame.hpp - 8260307: Do not include method.hpp in frame.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2201/files - new: https://git.openjdk.java.net/jdk/pull/2201/files/fed529d0..2178110f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2201&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2201&range=00-01 Stats: 4615 lines in 83 files changed: 2516 ins; 1660 del; 439 mod Patch: https://git.openjdk.java.net/jdk/pull/2201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2201/head:pull/2201 PR: https://git.openjdk.java.net/jdk/pull/2201 From iklam at openjdk.java.net Sat Jan 23 06:28:59 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 23 Jan 2021 06:28:59 GMT Subject: RFR: 8260307: Do not include method.hpp in frame.hpp [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 20:30:40 GMT, Coleen Phillimore wrote: >> Ioi Lam 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' of https://github.com/openjdk/jdk into 8260307-do-not-include-method.hpp-in-frame.hpp >> - 8260307: Do not include method.hpp in frame.hpp > > This looks good! Thanks @coleenp and @lfoltan for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/2201 From iklam at openjdk.java.net Sat Jan 23 06:29:00 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 23 Jan 2021 06:29:00 GMT Subject: Integrated: 8260307: Do not include method.hpp in frame.hpp In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:50:48 GMT, Ioi Lam wrote: > frame.hpp is a popular header file (included by 876 out of 1000 HotSpot.o file). It includes method.hpp, which in turn pulls in all the class metadata types such as instanceKlass.hpp, constantPool.hpp, etc. > > We can replace the inclusion of method.hpp with a forward declaration of the Method class. > > This reduces the number of .o files that include method.hpp from 882 to 586. > > HotSpot build time is reduced by more than 2%. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. This pull request has now been integrated. Changeset: 5cdcce1c Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/5cdcce1c Stats: 42 lines in 21 files changed: 25 ins; 1 del; 16 mod 8260307: Do not include method.hpp in frame.hpp Reviewed-by: lfoltan, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/2201 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 sjohanss at openjdk.java.net Sat Jan 23 15:19:40 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Sat, 23 Jan 2021 15:19:40 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 13:25:12 GMT, Denghui Dong wrote: >> src/hotspot/share/gc/shared/gcTraceSend.cpp line 369: >> >>> 367: void GCLockerTracer::report_gc_locker() { >>> 368: Ticks zero; >>> 369: if (_needs_gc_start_timestamp != zero) { >> >> Why is this needed? > > Because we can't assume that EventGCLocker is enabled when GC locker is started, in another word, at the beginning and end of the GC locker, whether EventGCLocker is enabled may be inconsistent. > > So check here if _needs_gc_start_timestamp is not zero, if it is not 0, it needs to reset _needs_gc_start_timestamp regardless of whether the event will be sent. Ok, so instead of sending an incomplete event you want to skip it? That might be correct but in that case I would prefer adding a helper `GCLockerTracer::is_started()`, that checks if the timestamp is set. That would make the intention more clear I think. This helper could assert that the event is enabled and it could also be used in `inc_stall_count()` since that one won't have any effect if the event is not "started". What do you think about that? ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From iklam at openjdk.java.net Sun Jan 24 01:45:03 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sun, 24 Jan 2021 01:45:03 GMT Subject: RFR: 8260306: Do not include osThread.hpp in thread.hpp [v2] In-Reply-To: References: Message-ID: <__XP3tNQz1SpM3MP-vZZ3sKMBTFeXtseK8f-KEwf4EY=.2cb0e2f0-192b-4053-9c66-135a93656696@github.com> > thread.hpp is a popular header file (included by 856 out of 1000 HotSpot.o file), so we should try to minimize what files are included by thread.hpp. > > We can replace the inclusion of osThread.hpp with a forward declaration of the OSThread class. > > This reduces the number of .o files that include osThread.hpp to 42. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam 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 four additional commits since the last revision: - Fixed merge - Merge branch 'master' into 8260306-dont-include-osThread.hpp-in-thread.hpp - Merge branch 'master' of https://github.com/openjdk/jdk into 8260306-dont-include-osThread.hpp-in-thread.hpp - 8260306: Do not include osThread.hpp in thread.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2198/files - new: https://git.openjdk.java.net/jdk/pull/2198/files/4da3fecb..d6f22383 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2198&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2198&range=00-01 Stats: 4945 lines in 137 files changed: 2573 ins; 1855 del; 517 mod Patch: https://git.openjdk.java.net/jdk/pull/2198.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2198/head:pull/2198 PR: https://git.openjdk.java.net/jdk/pull/2198 From ddong at openjdk.java.net Sun Jan 24 01:48:57 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Sun, 24 Jan 2021 01:48:57 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v4] In-Reply-To: References: Message-ID: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: add GCLockerTracer::is_started() that makes the logic more clear ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2088/files - new: https://git.openjdk.java.net/jdk/pull/2088/files/41641d8a..85987c58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=02-03 Stats: 13 lines in 2 files changed: 8 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2088/head:pull/2088 PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Sun Jan 24 01:52:42 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Sun, 24 Jan 2021 01:52:42 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 15:16:40 GMT, Stefan Johansson wrote: >> Because we can't assume that EventGCLocker is enabled when GC locker is started, in another word, at the beginning and end of the GC locker, whether EventGCLocker is enabled may be inconsistent. >> >> So check here if _needs_gc_start_timestamp is not zero, if it is not 0, it needs to reset _needs_gc_start_timestamp regardless of whether the event will be sent. > > Ok, so instead of sending an incomplete event you want to skip it? That might be correct but in that case I would prefer adding a helper `GCLockerTracer::is_started()`, that checks if the timestamp is set. That would make the intention more clear I think. This helper could assert that the event is enabled and it could also be used in `inc_stall_count()` since that one won't have any effect if the event is not "started". What do you think about that? Good idea. Updated. But I didn't add the assertion that makes sure the event is enabled, because it may be disabled between GCLockerTracer::start_gc_locker and GCLockerTracer::inc_stall_count(). ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From iklam at openjdk.java.net Sun Jan 24 02:43:45 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sun, 24 Jan 2021 02:43:45 GMT Subject: RFR: 8260306: Do not include osThread.hpp in thread.hpp [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 20:18:19 GMT, Lois Foltan wrote: >> Ioi Lam 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 four additional commits since the last revision: >> >> - Fixed merge >> - Merge branch 'master' into 8260306-dont-include-osThread.hpp-in-thread.hpp >> - Merge branch 'master' of https://github.com/openjdk/jdk into 8260306-dont-include-osThread.hpp-in-thread.hpp >> - 8260306: Do not include osThread.hpp in thread.hpp > > Looks good. > Lois Thanks @lfoltan and @coleenp for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/2198 From iklam at openjdk.java.net Sun Jan 24 02:43:45 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sun, 24 Jan 2021 02:43:45 GMT Subject: Integrated: 8260306: Do not include osThread.hpp in thread.hpp In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:02:10 GMT, Ioi Lam wrote: > thread.hpp is a popular header file (included by 856 out of 1000 HotSpot.o file), so we should try to minimize what files are included by thread.hpp. > > We can replace the inclusion of osThread.hpp with a forward declaration of the OSThread class. > > This reduces the number of .o files that include osThread.hpp to 42. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. This pull request has now been integrated. Changeset: 535c2927 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/535c2927 Stats: 34 lines in 20 files changed: 21 ins; 1 del; 12 mod 8260306: Do not include osThread.hpp in thread.hpp Reviewed-by: coleenp, lfoltan ------------- PR: https://git.openjdk.java.net/jdk/pull/2198 From iveresov at openjdk.java.net Sun Jan 24 03:53:00 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Sun, 24 Jan 2021 03:53:00 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Address Vladimir's review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1985/files - new: https://git.openjdk.java.net/jdk/pull/1985/files/82dffbe9..74ebbcb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=03-04 Stats: 78 lines in 20 files changed: 21 ins; 26 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Sun Jan 24 03:56:48 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Sun, 24 Jan 2021 03:56:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 17:32:09 GMT, Igor Veresov wrote: >> src/hotspot/share/compiler/compileBroker.cpp line 972: >> >>> 970: >>> 971: // Initialize the compilation queue >>> 972: if (_c2_count > 0) { >> >> Is ZERO treated as `is_interpreter_only()` ? How this change works with ZERO? > > I forgot why I removed that. Let me put it back and run it through testing again. So the reason for that was an awkward possibility of ending up with 0 compilers. That was because during the argument check in ```CompilerConfig::check_args_consistency()``` We checked for ```Arguments::is_interpreter_only()``` instead of ```CompilerConfig::is_interpreter_only()```. The former doesn't check if ```TieredStopAtLevel=0``` is present. Anyways, I fixed the check and reverted this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 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 dholmes at openjdk.java.net Sun Jan 24 21:23:44 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 24 Jan 2021 21:23:44 GMT Subject: RFR: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h [v2] In-Reply-To: <-jIDq0RisaLSuXg2Z9PlB-pWs8Aio6GUbEZTr4ozRJY=.2ed90f9c-b543-4ef3-b4e7-deeca5d0694e@github.com> References: <-jIDq0RisaLSuXg2Z9PlB-pWs8Aio6GUbEZTr4ozRJY=.2ed90f9c-b543-4ef3-b4e7-deeca5d0694e@github.com> Message-ID: On Thu, 21 Jan 2021 03:09:13 GMT, Ioi Lam wrote: >> jvm.h is over 1000 lines long. It is included by 940 out of 1000 HotSpot .o files. However, most of the HotSpot source files just use a small fraction of jvm.h: >> >> - the jio_xxxprintf() functions >> - the JVM_RECOGNIZED_XXX_MODIFIERS defines >> >> We should move these two parts into jvm_io.h and jvm_constants.h. This reduces the files that include jvm.h to about 82 files. Build time of HotSpot is reduced by about 0.4%. >> >> Testing: mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > David Holmes comments Updates look good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2154 From david.holmes at oracle.com Sun Jan 24 21:59:40 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Jan 2021 07:59:40 +1000 Subject: RFR: 8260306: Do not include osThread.hpp in thread.hpp In-Reply-To: References: Message-ID: <97e3baa5-b144-30fd-7f23-5cec4ed6ea8f@oracle.com> Hi Ioi, On 23/01/2021 4:14 am, Ioi Lam wrote: > thread.hpp is a popular header file (included by 856 out of 1000 HotSpot.o file), so we should try to minimize what files are included by thread.hpp. > > We can replace the inclusion of osThread.hpp with a forward declaration of the OSThread class. > > This reduces the number of .o files that include osThread.hpp to 42. Seems to me we should provide Thread::native_id() (or something like that) so that calls to thread->osthread()->thread_id() do not leak out everywhere. The osThread really should be an internal detail of thread and the OS-specific code. Cheers, David > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > ------------- > > Commit messages: > - 8260306: Do not include osThread.hpp in thread.hpp > > Changes: https://git.openjdk.java.net/jdk/pull/2198/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2198&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8260306 > Stats: 31 lines in 19 files changed: 19 ins; 1 del; 11 mod > Patch: https://git.openjdk.java.net/jdk/pull/2198.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/2198/head:pull/2198 > > PR: https://git.openjdk.java.net/jdk/pull/2198 From iklam at openjdk.java.net Mon Jan 25 06:33:04 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 25 Jan 2021 06:33:04 GMT Subject: RFR: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h [v3] In-Reply-To: References: Message-ID: > jvm.h is over 1000 lines long. It is included by 940 out of 1000 HotSpot .o files. However, most of the HotSpot source files just use a small fraction of jvm.h: > > - the jio_xxxprintf() functions > - the JVM_RECOGNIZED_XXX_MODIFIERS defines > > We should move these two parts into jvm_io.h and jvm_constants.h. This reduces the files that include jvm.h to about 82 files. Build time of HotSpot is reduced by about 0.4%. > > Testing: mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam 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 four additional commits since the last revision: - fixed windows build failure - Merge branch 'master' into 8259894-refactor-jvm.h - David Holmes comments - 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2154/files - new: https://git.openjdk.java.net/jdk/pull/2154/files/00fc5db5..058c1ec2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2154&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2154&range=01-02 Stats: 11440 lines in 368 files changed: 5471 ins; 4070 del; 1899 mod Patch: https://git.openjdk.java.net/jdk/pull/2154.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2154/head:pull/2154 PR: https://git.openjdk.java.net/jdk/pull/2154 From dholmes at openjdk.java.net Mon Jan 25 07:18:43 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 25 Jan 2021 07:18:43 GMT Subject: RFR: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 06:33:04 GMT, Ioi Lam wrote: >> jvm.h is over 1000 lines long. It is included by 940 out of 1000 HotSpot .o files. However, most of the HotSpot source files just use a small fraction of jvm.h: >> >> - the jio_xxxprintf() functions >> - the JVM_RECOGNIZED_XXX_MODIFIERS defines >> >> We should move these two parts into jvm_io.h and jvm_constants.h. This reduces the files that include jvm.h to about 82 files. Build time of HotSpot is reduced by about 0.4%. >> >> Testing: mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > Ioi Lam 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 four additional commits since the last revision: > > - fixed windows build failure > - Merge branch 'master' into 8259894-refactor-jvm.h > - David Holmes comments > - 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2154 From iklam at openjdk.java.net Mon Jan 25 08:03:42 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 25 Jan 2021 08:03:42 GMT Subject: RFR: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h [v2] In-Reply-To: References: <-jIDq0RisaLSuXg2Z9PlB-pWs8Aio6GUbEZTr4ozRJY=.2ed90f9c-b543-4ef3-b4e7-deeca5d0694e@github.com> Message-ID: On Fri, 22 Jan 2021 23:24:52 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> David Holmes comments > > Looks good to me. Thanks @coleenp and @dholmes-ora for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/2154 From iklam at openjdk.java.net Mon Jan 25 08:03:46 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 25 Jan 2021 08:03:46 GMT Subject: Integrated: 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 04:33:56 GMT, Ioi Lam wrote: > jvm.h is over 1000 lines long. It is included by 940 out of 1000 HotSpot .o files. However, most of the HotSpot source files just use a small fraction of jvm.h: > > - the jio_xxxprintf() functions > - the JVM_RECOGNIZED_XXX_MODIFIERS defines > > We should move these two parts into jvm_io.h and jvm_constants.h. This reduces the files that include jvm.h to about 82 files. Build time of HotSpot is reduced by about 0.4%. > > Testing: mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. This pull request has now been integrated. Changeset: 5898ab65 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/5898ab65 Stats: 252 lines in 17 files changed: 145 ins; 86 del; 21 mod 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/2154 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 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 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 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 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 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 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 kvn at openjdk.java.net Mon Jan 25 18:00:52 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 25 Jan 2021 18:00:52 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: On Sun, 24 Jan 2021 03:53:00 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Address Vladimir's review comments Looks better now. I would like to see result of performance testing before approving. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From hseigel at openjdk.java.net Mon Jan 25 18:01:47 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 25 Jan 2021 18:01:47 GMT Subject: RFR: 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out Message-ID: <_RgVuhYJArTNFxi5AOShZPJkHwgn1FWGfe4uDIomKnQ=.ab70edda-fe2c-412f-baf6-a206a522e3e2@github.com> Please review this change to fix JDK-8252545. The fix uses -Xm128m to reduce the size of the heap, lessening the amount of time needed to get an OutOfMemoryError exception. The fix also simplifies things by including test TestHeapDumpOnOutOfMemoryErrorInMetaspace.java with this test. (Hopefully, this won't increase the likelihood of timeouts.) The fix was tested by running Mach5 tier 3 on Linux, Mac OS, and Windows, and running the test 100 times on Linxu x64 with the same JVM options that were used when the test last timed out: "-XX:MaxRAMPercentage=6 -XX:+UseParallelGC -XX:+UseNUMA". Thanks, Harold ------------- Commit messages: - 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out Changes: https://git.openjdk.java.net/jdk/pull/2226/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2226&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252545 Stats: 36 lines in 3 files changed: 3 ins; 30 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2226.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2226/head:pull/2226 PR: https://git.openjdk.java.net/jdk/pull/2226 From sjohanss at openjdk.java.net Mon Jan 25 18:13:45 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 25 Jan 2021 18:13:45 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v4] In-Reply-To: References: Message-ID: <_sVYAZQIiJSDJlj5QO29F6uF0k2V0ApDtlFuMwVLkwA=.d34f9b7e-a6f5-4131-9299-2e570cf3cf04@github.com> On Sun, 24 Jan 2021 01:48:57 GMT, Denghui Dong wrote: >> GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. >> >> For the test purpose, I add two Whitebox methods to lock/unlock critical. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > add GCLockerTracer::is_started() that makes the logic more clear I think this looks good now but please await a second reviewer. I took if for a spin in out internal testing and tier1-2 looks ok as well as the JFR tests. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2088 From iveresov at openjdk.java.net Mon Jan 25 18:15:49 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Mon, 25 Jan 2021 18:15:49 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 17:57:29 GMT, Vladimir Kozlov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Address Vladimir's review comments > > Looks better now. I would like to see result of performance testing before approving. I asked Eric to run the benchmarks. The results should be ready on Wednesday. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 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 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 anleonar at redhat.com Mon Jan 25 21:19:23 2021 From: anleonar at redhat.com (Andrew Leonard) Date: Mon, 25 Jan 2021 21:19:23 +0000 Subject: Does "strictfp" affect called/intrinsified Math functions? Message-ID: Hi, Can I just check my understanding is correct, in that the following example will not actually return a "strictfp" value, because the Math.exp() is not strictfp and by default is a non-strictfp Intrinsic inline implementation? Thanks Andrew private strictfp double strictfpMathExp(double input) { return Math.exp(input); } 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 coleenp at openjdk.java.net Mon Jan 25 22:28:48 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Jan 2021 22:28:48 GMT Subject: RFR: 8259809: Remove PerfEvent class loading locking counters Message-ID: See CR for details. Tested with tier1-3. ------------- Commit messages: - 8259809: Remove PerfEvent class loading locking counters Changes: https://git.openjdk.java.net/jdk/pull/2227/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2227&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259809 Stats: 163 lines in 8 files changed: 0 ins; 162 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2227.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2227/head:pull/2227 PR: https://git.openjdk.java.net/jdk/pull/2227 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 redestad at openjdk.java.net Mon Jan 25 22:36:39 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 25 Jan 2021 22:36:39 GMT Subject: RFR: 8259809: Remove PerfEvent class loading locking counters In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 22:23:57 GMT, Coleen Phillimore wrote: > See CR for details. > Tested with tier1-3. LGTM! ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2227 From iklam at openjdk.java.net Mon Jan 25 22:42:39 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 25 Jan 2021 22:42:39 GMT Subject: RFR: 8259809: Remove PerfEvent class loading locking counters In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 22:23:57 GMT, Coleen Phillimore wrote: > See CR for details. > Tested with tier1-3. Seems reasonable to remove code that isn't useful/used anymore. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2227 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 coleenp at openjdk.java.net Mon Jan 25 23:35:44 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Jan 2021 23:35:44 GMT Subject: RFR: 8254246: SymbolHashMapEntry wastes space Message-ID: <8wbyUcwQLDjGe1pJ_ziOE4iwOQOKvfccjM9j2N9nN2I=.ec93062b-e90f-442e-873d-f0fce57fbcf2@github.com> The ConstantPool SymbolHashMapEntry is used by class file reconstitution, so the little wasted space doesn't make a difference, but it's fixed here. Tested with tier1 and vmTestbase/nsk/{jdi,jvmti} tests. Should be trivial. ------------- Commit messages: - 8254246: SymbolHashMapEntry wastes space Changes: https://git.openjdk.java.net/jdk/pull/2228/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2228&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254246 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2228/head:pull/2228 PR: https://git.openjdk.java.net/jdk/pull/2228 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 redestad at openjdk.java.net Mon Jan 25 23:56:42 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 25 Jan 2021 23:56:42 GMT Subject: RFR: 8254246: SymbolHashMapEntry wastes space In-Reply-To: <8wbyUcwQLDjGe1pJ_ziOE4iwOQOKvfccjM9j2N9nN2I=.ec93062b-e90f-442e-873d-f0fce57fbcf2@github.com> References: <8wbyUcwQLDjGe1pJ_ziOE4iwOQOKvfccjM9j2N9nN2I=.ec93062b-e90f-442e-873d-f0fce57fbcf2@github.com> Message-ID: On Mon, 25 Jan 2021 23:30:52 GMT, Coleen Phillimore wrote: > The ConstantPool SymbolHashMapEntry is used by class file reconstitution, so the little wasted space doesn't make a difference, but it's fixed here. Tested with tier1 and vmTestbase/nsk/{jdi,jvmti} tests. Should be trivial. Looks good and trivial. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2228 From coleenp at openjdk.java.net Tue Jan 26 00:02:42 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 26 Jan 2021 00:02:42 GMT Subject: RFR: 8254246: SymbolHashMapEntry wastes space In-Reply-To: References: <8wbyUcwQLDjGe1pJ_ziOE4iwOQOKvfccjM9j2N9nN2I=.ec93062b-e90f-442e-873d-f0fce57fbcf2@github.com> Message-ID: On Mon, 25 Jan 2021 23:53:36 GMT, Claes Redestad wrote: >> The ConstantPool SymbolHashMapEntry is used by class file reconstitution, so the little wasted space doesn't make a difference, but it's fixed here. Tested with tier1 and vmTestbase/nsk/{jdi,jvmti} tests. Should be trivial. > > Looks good and trivial. Thanks Claes! ------------- PR: https://git.openjdk.java.net/jdk/pull/2228 From coleenp at openjdk.java.net Tue Jan 26 00:02:43 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 26 Jan 2021 00:02:43 GMT Subject: Integrated: 8254246: SymbolHashMapEntry wastes space In-Reply-To: <8wbyUcwQLDjGe1pJ_ziOE4iwOQOKvfccjM9j2N9nN2I=.ec93062b-e90f-442e-873d-f0fce57fbcf2@github.com> References: <8wbyUcwQLDjGe1pJ_ziOE4iwOQOKvfccjM9j2N9nN2I=.ec93062b-e90f-442e-873d-f0fce57fbcf2@github.com> Message-ID: On Mon, 25 Jan 2021 23:30:52 GMT, Coleen Phillimore wrote: > The ConstantPool SymbolHashMapEntry is used by class file reconstitution, so the little wasted space doesn't make a difference, but it's fixed here. Tested with tier1 and vmTestbase/nsk/{jdi,jvmti} tests. Should be trivial. This pull request has now been integrated. Changeset: 9ea93238 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/9ea93238 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod 8254246: SymbolHashMapEntry wastes space Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/2228 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 whuang at openjdk.java.net Tue Jan 26 08:03:56 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 26 Jan 2021 08:03:56 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v3] In-Reply-To: References: Message-ID: > The reason is : > > BasicType t = store->as_Mem()->memory_type(); > const char* fill_name; > if (msg == NULL && > StubRoutines::select_fill_function(t, false, fill_name) == NULL) { > msg = "unsupported store"; > msg_node = store; > } > > If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't intrinsify a `StoreVectorNode` filling here. > > I add a new case here to avoid mistake: > case T_NARROWOOP: > case T_NARROWKLASS: > case T_ADDRESS: > + case T_VOID: > // Currently unsupported > return NULL; Wang Huang 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: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/132/files - new: https://git.openjdk.java.net/jdk16/pull/132/files/4a503063..ee3797d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=01-02 Stats: 8 lines in 4 files changed: 1 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk16/pull/132.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132 PR: https://git.openjdk.java.net/jdk16/pull/132 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 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 neliasso at openjdk.java.net Tue Jan 26 09:30:48 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Tue, 26 Jan 2021 09:30:48 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 08:03:56 GMT, Wang Huang wrote: >> The reason is : >> >> BasicType t = store->as_Mem()->memory_type(); >> const char* fill_name; >> if (msg == NULL && >> StubRoutines::select_fill_function(t, false, fill_name) == NULL) { >> msg = "unsupported store"; >> msg_node = store; >> } >> >> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. >> >> I add a new case here to avoid mistake: >> case T_NARROWOOP: >> case T_NARROWKLASS: >> case T_ADDRESS: >> + case T_VOID: >> // Currently unsupported >> return NULL; > > Wang Huang 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 fix looks good. Since JDK 16 is in rampdown phase 2 (http://openjdk.java.net/jeps/3) - this fix will need additional approval before it can be pushed. I will help out with that. ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 From whuang at openjdk.java.net Tue Jan 26 09:41:40 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 26 Jan 2021 09:41:40 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 09:28:13 GMT, Nils Eliasson wrote: > The fix looks good. > > Since JDK 16 is in rampdown phase 2 (http://openjdk.java.net/jeps/3) - this fix will need additional approval before it can be pushed. I will help out with that. Thank you for your review and help. ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 From tschatzl at openjdk.java.net Tue Jan 26 09:52:43 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 26 Jan 2021 09:52:43 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v4] In-Reply-To: References: Message-ID: On Sun, 24 Jan 2021 01:48:57 GMT, Denghui Dong wrote: >> GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. >> >> For the test purpose, I add two Whitebox methods to lock/unlock critical. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > add GCLockerTracer::is_started() that makes the logic more clear Changes requested by tschatzl (Reviewer). test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 34: > 32: import sun.hotspot.WhiteBox; > 33: > 34: /** This block should be the first thing in the test after the copyright notice. test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 116: > 114: ts[i] = new Thread(() -> { > 115: STALL_COUNT_SIGNAL.countDown(); > 116: for (int j = 0; j < LOOP; j++) { Since the test already uses WhiteBox, please use whitebox to trigger a gc instead of this dodgy method. src/hotspot/share/gc/shared/gcLocker.cpp line 101: > 99: verify_critical_count(); > 100: _needs_gc = true; > 101: GCLockerTracer::start_gc_locker(_jni_lock_count); Not really convinced that passing `_jni_lock_count` here gives a lot of information: this is the number of threads in a critical section at the point of the first thread needing a gc. It's probably better than nothing. At least this information should be added to the description of the event (if that is possible). test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 2: > 1: /* > 2: * Copyright (c) 2021 Alibaba Group Holding Limited. All Rights Reserved. Would it be possible to keep with the general format of copyright messages in other code, i.e. "Copyright (c) , . ..."? I.e. if possible please add a comma after the year. src/hotspot/share/jfr/metadata/metadata.xml line 1095: > 1093: > 1094: > 1095: Please add descriptions to the fields as mentioned above. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From aph at redhat.com Tue Jan 26 10:35:24 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jan 2021 10:35:24 +0000 Subject: Does "strictfp" affect called/intrinsified Math functions? In-Reply-To: References: Message-ID: <09f08ba7-6871-36e9-adf1-0182554be668@redhat.com> On 1/25/21 9:19 PM, Andrew Leonard wrote: > Can I just check my understanding is correct, in that the following example > will not actually return a "strictfp" value, because the Math.exp() is not > strictfp and by default is a non-strictfp Intrinsic inline implementation? strictfp affects the code in this method, not other methods called from it. If you need StrictMath.exp, which I very much doubt, you'll have to call it. There's no real connection between StrictMath and strictfp. -- 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 ddong at openjdk.java.net Tue Jan 26 11:06:57 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 26 Jan 2021 11:06:57 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v5] In-Reply-To: References: Message-ID: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: Add descriptions and fix the format problem ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2088/files - new: https://git.openjdk.java.net/jdk/pull/2088/files/85987c58..a5d0e0a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=03-04 Stats: 23 lines in 2 files changed: 11 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2088/head:pull/2088 PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Tue Jan 26 11:07:00 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 26 Jan 2021 11:07:00 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v4] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 09:42:59 GMT, Thomas Schatzl wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> add GCLockerTracer::is_started() that makes the logic more clear > > src/hotspot/share/gc/shared/gcLocker.cpp line 101: > >> 99: verify_critical_count(); >> 100: _needs_gc = true; >> 101: GCLockerTracer::start_gc_locker(_jni_lock_count); > > Not really convinced that passing `_jni_lock_count` here gives a lot of information: this is the number of threads in a critical section at the point of the first thread needing a gc. It's probably better than nothing. At least this information should be added to the description of the event (if that is possible). I think this field can be used to judge whether there are many threads that are often in a critical section, but I am not sure if it really helps to analyze the problem., and just as you said, it's better than nothing. An appropriate description of this field has been added. > test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 116: > >> 114: ts[i] = new Thread(() -> { >> 115: STALL_COUNT_SIGNAL.countDown(); >> 116: for (int j = 0; j < LOOP; j++) { > > Since the test already uses WhiteBox, please use whitebox to trigger a gc instead of this dodgy method. Triggering a GC is not enough, I hope these threads could be stall by the GC locker(call GCLocker::stall_until_clear) so that a correct assertion of the number of stall count could be added. I think it could not be done by WhiteBox::youngGC/fullGC, please correct me if I'm wrong. > src/hotspot/share/jfr/metadata/metadata.xml line 1095: > >> 1093: >> 1094: >> 1095: > > Please add descriptions to the fields as mentioned above. added > test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 2: > >> 1: /* >> 2: * Copyright (c) 2021 Alibaba Group Holding Limited. All Rights Reserved. > > Would it be possible to keep with the general format of copyright messages in other code, i.e. "Copyright (c) , . ..."? I.e. if possible please add a comma after the year. Fixed. > test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 34: > >> 32: import sun.hotspot.WhiteBox; >> 33: >> 34: /** > > This block should be the first thing in the test after the copyright notice. Fixed. But I notice that there are many other tests that didn't comply with this rule. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 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 coleenp at openjdk.java.net Tue Jan 26 11:53:44 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 26 Jan 2021 11:53:44 GMT Subject: RFR: 8259809: Remove PerfEvent class loading locking counters In-Reply-To: References: Message-ID: <2Qa6sTknvm0cS0gbYAMfYx--k38mKqFRRLP_qr_FNhY=.a7ccbf82-41c4-4353-bae8-fd1c622e28c2@github.com> On Mon, 25 Jan 2021 22:39:44 GMT, Ioi Lam wrote: >> See CR for details. >> Tested with tier1-3. > > Seems reasonable to remove code that isn't useful/used anymore. Thanks Claes and Ioi! ------------- PR: https://git.openjdk.java.net/jdk/pull/2227 From coleenp at openjdk.java.net Tue Jan 26 11:53:45 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 26 Jan 2021 11:53:45 GMT Subject: Integrated: 8259809: Remove PerfEvent class loading locking counters In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 22:23:57 GMT, Coleen Phillimore wrote: > See CR for details. > Tested with tier1-3. This pull request has now been integrated. Changeset: 81a66dfa Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/81a66dfa Stats: 163 lines in 8 files changed: 0 ins; 162 del; 1 mod 8259809: Remove PerfEvent class loading locking counters Reviewed-by: redestad, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/2227 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 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 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 jiefu at openjdk.java.net Tue Jan 26 12:10:46 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 26 Jan 2021 12:10:46 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 09:38:28 GMT, Wang Huang wrote: >> The fix looks good. >> >> Since JDK 16 is in rampdown phase 2 (http://openjdk.java.net/jeps/3) - this fix will need additional approval before it can be pushed. I will help out with that. > >> The fix looks good. >> >> Since JDK 16 is in rampdown phase 2 (http://openjdk.java.net/jeps/3) - this fix will need additional approval before it can be pushed. I will help out with that. > > Thank you for your review and help. Hi @Wanghuang-Huawei , I'm still not clear how to reproduce the bug. Is it possible to add a jtreg test for this fix? Thanks. ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 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 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 stuefe at openjdk.java.net Tue Jan 26 12:47:44 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 26 Jan 2021 12:47:44 GMT Subject: RFR: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently [v3] In-Reply-To: References: <-U7zmZRMWfYgZatil3T1ksFVqFqWATGKJvrCHHso8hU=.11d26a25-1ce6-4b53-979c-0eee4afe01df@github.com> Message-ID: On Thu, 21 Jan 2021 10:04:32 GMT, Martin Doerr wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Use ABI_ELFv2 instead of VM_LITTLE_ENDIAN > > Thanks! Gentle ping. ------------- PR: https://git.openjdk.java.net/jdk/pull/2157 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 stuefe at openjdk.java.net Tue Jan 26 13:03:42 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 26 Jan 2021 13:03:42 GMT Subject: RFR: 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out In-Reply-To: <_RgVuhYJArTNFxi5AOShZPJkHwgn1FWGfe4uDIomKnQ=.ab70edda-fe2c-412f-baf6-a206a522e3e2@github.com> References: <_RgVuhYJArTNFxi5AOShZPJkHwgn1FWGfe4uDIomKnQ=.ab70edda-fe2c-412f-baf6-a206a522e3e2@github.com> Message-ID: <_9Gk6M0sKGYMBK2wP8HgM1sS9hv8laLzj35qZ7u4tFk=.822bb221-69d8-403c-834a-01730cea5488@github.com> On Mon, 25 Jan 2021 17:57:33 GMT, Harold Seigel wrote: > Please review this change to fix JDK-8252545. The fix uses -Xm128m to reduce the size of the heap, lessening the amount of time needed to get an OutOfMemoryError exception. The fix also simplifies things by including test TestHeapDumpOnOutOfMemoryErrorInMetaspace.java with this test. (Hopefully, this won't increase the likelihood of timeouts.) > > The fix was tested by running Mach5 tier 3 on Linux, Mac OS, and Windows, and running the test 100 times on Linxu x64 with the same JVM options that were used when the test last timed out: "-XX:MaxRAMPercentage=6 -XX:+UseParallelGC -XX:+UseNUMA". > > Thanks, Harold Hi Harold, looks good and makes sense. I even believe we could drop the Metaspace test to the default timeout; the longest runtimes I found since JDK-8212218 are about 12-15 seconds on our slow platforms (leave that up to you though). ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2226 From coleenp at openjdk.java.net Tue Jan 26 13:08:41 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 26 Jan 2021 13:08:41 GMT Subject: RFR: 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out In-Reply-To: <_RgVuhYJArTNFxi5AOShZPJkHwgn1FWGfe4uDIomKnQ=.ab70edda-fe2c-412f-baf6-a206a522e3e2@github.com> References: <_RgVuhYJArTNFxi5AOShZPJkHwgn1FWGfe4uDIomKnQ=.ab70edda-fe2c-412f-baf6-a206a522e3e2@github.com> Message-ID: On Mon, 25 Jan 2021 17:57:33 GMT, Harold Seigel wrote: > Please review this change to fix JDK-8252545. The fix uses -Xm128m to reduce the size of the heap, lessening the amount of time needed to get an OutOfMemoryError exception. The fix also simplifies things by including test TestHeapDumpOnOutOfMemoryErrorInMetaspace.java with this test. (Hopefully, this won't increase the likelihood of timeouts.) > > The fix was tested by running Mach5 tier 3 on Linux, Mac OS, and Windows, and running the test 100 times on Linxu x64 with the same JVM options that were used when the test last timed out: "-XX:MaxRAMPercentage=6 -XX:+UseParallelGC -XX:+UseNUMA". > > Thanks, Harold LGTM! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2226 From hseigel at openjdk.java.net Tue Jan 26 13:19:39 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 26 Jan 2021 13:19:39 GMT Subject: RFR: 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out In-Reply-To: References: <_RgVuhYJArTNFxi5AOShZPJkHwgn1FWGfe4uDIomKnQ=.ab70edda-fe2c-412f-baf6-a206a522e3e2@github.com> Message-ID: <8Fqe8u3bve_98l4YLiWUaAZ03lnH9a0cNVuHUozhrMg=.915af64e-8f64-48ee-83f2-3586bbe1a30a@github.com> On Tue, 26 Jan 2021 13:06:14 GMT, Coleen Phillimore wrote: >> Please review this change to fix JDK-8252545. The fix uses -Xm128m to reduce the size of the heap, lessening the amount of time needed to get an OutOfMemoryError exception. The fix also simplifies things by including test TestHeapDumpOnOutOfMemoryErrorInMetaspace.java with this test. (Hopefully, this won't increase the likelihood of timeouts.) >> >> The fix was tested by running Mach5 tier 3 on Linux, Mac OS, and Windows, and running the test 100 times on Linxu x64 with the same JVM options that were used when the test last timed out: "-XX:MaxRAMPercentage=6 -XX:+UseParallelGC -XX:+UseNUMA". >> >> Thanks, Harold > > LGTM! Thanks Thomas and Coleen for the reviews! I'll keep the Metaspace timeout as is for now to reduce the chances of that test timing out. ------------- PR: https://git.openjdk.java.net/jdk/pull/2226 From hseigel at openjdk.java.net Tue Jan 26 13:19:41 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 26 Jan 2021 13:19:41 GMT Subject: Integrated: 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out In-Reply-To: <_RgVuhYJArTNFxi5AOShZPJkHwgn1FWGfe4uDIomKnQ=.ab70edda-fe2c-412f-baf6-a206a522e3e2@github.com> References: <_RgVuhYJArTNFxi5AOShZPJkHwgn1FWGfe4uDIomKnQ=.ab70edda-fe2c-412f-baf6-a206a522e3e2@github.com> Message-ID: On Mon, 25 Jan 2021 17:57:33 GMT, Harold Seigel wrote: > Please review this change to fix JDK-8252545. The fix uses -Xm128m to reduce the size of the heap, lessening the amount of time needed to get an OutOfMemoryError exception. The fix also simplifies things by including test TestHeapDumpOnOutOfMemoryErrorInMetaspace.java with this test. (Hopefully, this won't increase the likelihood of timeouts.) > > The fix was tested by running Mach5 tier 3 on Linux, Mac OS, and Windows, and running the test 100 times on Linxu x64 with the same JVM options that were used when the test last timed out: "-XX:MaxRAMPercentage=6 -XX:+UseParallelGC -XX:+UseNUMA". > > Thanks, Harold This pull request has now been integrated. Changeset: e080ce92 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/e080ce92 Stats: 36 lines in 3 files changed: 3 ins; 30 del; 3 mod 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out Reviewed-by: stuefe, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/2226 From jbachorik at openjdk.java.net Tue Jan 26 13:42:50 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 26 Jan 2021 13:42:50 GMT Subject: RFR: 8247471: Enhance CPU load events with the actual elapsed CPU time Message-ID: A continuation of an RFR thread started last year - https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2020-June/001533.html This change adds the raw CPU time value to CPU load events (per-thread and per-process as well). The CPU time value is already known and used to calculate the load so adding it to the events does not incur any extra overhead while making it much easier for the end users to eg. aggregate and compare the active execution time per time period without the detailed knowledge how JFR computes and normalizes the CPU load. ------------- Commit messages: - Fix wording and remove unnecessary debug output - Fix jcheck - Merge branch 'master' into 8247471_cpuload_with_time - 8247471: Enhance CPU load events with the actual elapsed CPU time Changes: https://git.openjdk.java.net/jdk/pull/2186/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2186&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247471 Stats: 543 lines in 11 files changed: 238 ins; 205 del; 100 mod Patch: https://git.openjdk.java.net/jdk/pull/2186.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2186/head:pull/2186 PR: https://git.openjdk.java.net/jdk/pull/2186 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 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 harold.seigel at oracle.com Tue Jan 26 15:16:40 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 26 Jan 2021 15:16:40 +0000 Subject: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 In-Reply-To: References: , , Message-ID: Hi Michael, This bug has been fixed. The fix should be available in a JDK-16 update release and in JDK-17. See https://bugs.openjdk.java.net/browse/JDK-8260009 for details. Thanks again for reporting it. Harold ________________________________ From: Michael Rasmussen Sent: Thursday, January 21, 2021 8:31 AM To: Harold Seigel ; hotspot-dev at openjdk.java.net Subject: [External] : Re: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 OK, managed to make a very simple reproduceable test: package com.test; import net.bytebuddy.agent.ByteBuddyAgent; import java.lang.instrument.Instrumentation; public class Main { public static void main(String[] args) throws Exception { final Instrumentation instrumentation = ByteBuddyAgent.install(); Foo.class.isSealed(); instrumentation.retransformClasses(Bar.class); } static sealed interface Foo permits Bar {} static final class Bar implements Foo {} } -- java.exe -showversion --enable-preview -Xlog:class+redefine+load=trace "-Xlog:sealed*=trace" -classpath target\classes;lib\asm-9.0.jar;lib\byte-buddy-agent-1.10.19.jar com.test.Main openjdk version "16-ea" 2021-03-16 OpenJDK Runtime Environment (build 16-ea+32-2190) OpenJDK 64-Bit Server VM (build 16-ea+32-2190, mixed mode, sharing) [0.271s][trace][class,sealed] Checking for permitted subclass of com.test.Main$Bar in com.test.Main$Foo [0.271s][trace][class,sealed] - Found it at permitted_subclasses[0] => cp[11] [0.273s][debug][redefine,class,load] loading name=com.test.Main$Bar kind=101 (avail_mem=22046284K) [0.273s][trace][class,sealed ] Checking for permitted subclass of com.test.Main$Bar in com.test.Main$Foo [0.273s][trace][class,sealed ] - class is NOT a permitted subclass! Exception in thread "main" java.lang.VerifyError at java.instrument/sun.instrument.InstrumentationImpl.retransformClasses0(Native Method) at java.instrument/sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:168) at com.test.Main.main(Main.java:13) /Michael ________________________________ From: Harold Seigel Sent: 19 January 2021 22:52 To: Michael Rasmussen ; hotspot-dev at openjdk.java.net Subject: Re: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 Hi Michael, I entered bug https://bugs.openjdk.java.net/browse/JDK-8260009 for this problem. Thank you for reporting it. Harold ________________________________ From: hotspot-dev on behalf of Michael Rasmussen Sent: Tuesday, January 19, 2021 3:27 PM To: hotspot-dev at openjdk.java.net Subject: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 Hi, I noticed a regression in the verification of sealed classes, that I've narrowed down to happening between jdk-16+27 and jdk-16+28. Retransforming or redefining a sealed class can lead to a JVMTI_ERROR_FAILS_VERIFICATION, with Exception (0x00000000feb820a0), even though the class actually does that. I've tried to investigate the reason, and from what I can tell, it boils down to the check in InstanceKlass::has_as_permitted_subclass. In jdk-16+27, this method always seems to take the Symbol branch (_constants->tag_at(cp_index).is_klass() is false). But for jdk-16+28, it takes the Klass branch after the classes are loaded, and from what I can tell the (k2 == k) comparison can then fail during the redefinition since the Klass stored in the _permitted_subclasses is not the same as the one being verified, as a new InstanceKlass is allocated for the stream parser. Unfortunately, I haven't been able to produce a small self-contained test example, but I can reliably reproduce it while developing JRebel (which utilizes class retransformation), but hopefully the above is at least helpful in finding the issue and fixing it. /Michael This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. CAUTION: This email originated from outside of the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. 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 egahlin at openjdk.java.net Tue Jan 26 16:56:43 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 26 Jan 2021 16:56:43 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v5] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 11:06:57 GMT, Denghui Dong wrote: >> GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. >> >> For the test purpose, I add two Whitebox methods to lock/unlock critical. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > Add descriptions and fix the format problem Marked as reviewed by egahlin (Reviewer). src/hotspot/share/jfr/metadata/metadata.xml line 1094: > 1092: > 1093: > 1094: I would suggest changing this to: "The number of Java threads in a critical section when the GC locker is started" "The number of Java threads stalled by the GC locker" src/hotspot/share/jfr/metadata/metadata.xml line 1093: > 1091: > 1092: > 1093: "GC Locker Information" is not very useful. Remove the description completely or provide more information. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From stuefe at openjdk.java.net Tue Jan 26 17:02:54 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 26 Jan 2021 17:02:54 GMT Subject: RFR: JDK-8260404: jvm_io.h include missing in a number of files Message-ID: One of the last include corrections caused a build error on our AIX machines because compile.cpp uses jio_snprintf() without including jvm_io.h. I did not deeply follow up on the why, but "8260307: Do not include method.hpp in frame.hpp" is a possible candidate. AIX builds without JFR and hence miss a number of include chains other platforms have. I scanned hotspot sources for files using jio_snprintf but not including jvm_io.h. There are some hits, which should be fixed. All this is trivial, right? ------------- Commit messages: - JDK-8260404-add-missing-jvm_io.h Changes: https://git.openjdk.java.net/jdk/pull/2232/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2232&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260404 Stats: 26 lines in 16 files changed: 16 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2232.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2232/head:pull/2232 PR: https://git.openjdk.java.net/jdk/pull/2232 From shade at openjdk.java.net Tue Jan 26 17:02:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 17:02:54 GMT Subject: RFR: JDK-8260404: jvm_io.h include missing in a number of files In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 10:22:09 GMT, Thomas Stuefe wrote: > One of the last include corrections caused a build error on our AIX machines because compile.cpp uses jio_snprintf() without including jvm_io.h. > > I did not deeply follow up on the why, but "8260307: Do not include method.hpp in frame.hpp" is a possible candidate. AIX builds without JFR and hence miss a number of include chains other platforms have. > > I scanned hotspot sources for files using jio_snprintf but not including jvm_io.h. There are some hits, which should be fixed. > > All this is trivial, right? Ah. I saw x86_32 build failures as well, so I PR'ed #2237. I think you linked this issue incorrectly to JDK-8260404, not JDK-8259894, and that is why I missed it. If you are about to propose this PR, I can close mine as duplicate. ------------- PR: https://git.openjdk.java.net/jdk/pull/2232 From stuefe at openjdk.java.net Tue Jan 26 17:02:54 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 26 Jan 2021 17:02:54 GMT Subject: RFR: JDK-8260404: jvm_io.h include missing in a number of files In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 13:50:37 GMT, Aleksey Shipilev wrote: > Ah. I saw x86_32 build failures as well, so I PR'ed #2237. I think you linked this issue incorrectly to JDK-8260404, not JDK-8259894, and that is why I missed it. If you are about to propose this PR, I can close mine as duplicate. Sorry, I saw this too late. I am fine with either PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/2232 From kvn at openjdk.java.net Tue Jan 26 17:19:44 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 26 Jan 2021 17:19:44 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 08:03:56 GMT, Wang Huang wrote: >> The reason is : >> >> BasicType t = store->as_Mem()->memory_type(); >> const char* fill_name; >> if (msg == NULL && >> StubRoutines::select_fill_function(t, false, fill_name) == NULL) { >> msg = "unsupported store"; >> msg_node = store; >> } >> >> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. >> >> I add a new case here to avoid mistake: >> case T_NARROWOOP: >> case T_NARROWKLASS: >> case T_ADDRESS: >> + case T_VOID: >> // Currently unsupported >> return NULL; > > Wang Huang 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: > > 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop Need regression test since change is in common code. ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/132 From shade at openjdk.java.net Tue Jan 26 17:44:44 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 26 Jan 2021 17:44:44 GMT Subject: RFR: JDK-8260404: jvm_io.h include missing in a number of files In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 10:22:09 GMT, Thomas Stuefe wrote: > One of the last include corrections caused a build error on our AIX machines because compile.cpp uses jio_snprintf() without including jvm_io.h. > > I did not deeply follow up on the why, but "8260307: Do not include method.hpp in frame.hpp" is a possible candidate. AIX builds without JFR and hence miss a number of include chains other platforms have. > > I scanned hotspot sources for files using jio_snprintf but not including jvm_io.h. There are some hits, which should be fixed. > > All this is trivial, right? Looks fine to me. (And your fix is more comprehensive, I'll close mine as duplicate) ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2232 From joe.darcy at oracle.com Tue Jan 26 17:45:16 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 26 Jan 2021 09:45:16 -0800 Subject: Does "strictfp" affect called/intrinsified Math functions? In-Reply-To: <09f08ba7-6871-36e9-adf1-0182554be668@redhat.com> References: <09f08ba7-6871-36e9-adf1-0182554be668@redhat.com> Message-ID: On 1/26/2021 2:35 AM, Andrew Haley wrote: > On 1/25/21 9:19 PM, Andrew Leonard wrote: > >> Can I just check my understanding is correct, in that the following example >> will not actually return a "strictfp" value, because the Math.exp() is not >> strictfp and by default is a non-strictfp Intrinsic inline implementation? > strictfp affects the code in this method, not other methods called from it. > If you need StrictMath.exp, which I very much doubt, you'll have to call it. > There's no real connection between StrictMath and strictfp. Right -- no direct connection between StrictMath and strictfp. It is not always necessary for StrictMath method to be declared strictfp to get reproducible results. If the expression in the method cannot overflow or underflow, strictfp won't change the result even when the variations allowed by non-strictfp could be used. Conversely, it would be fine for a Math.foo method to be declared strictfp as that would require Math.foo to have reproducible behavior across platforms, even if it differed from the StrictMath.foo behavior. The code generation options allowed by non-strictfp are only available (in practice) on the x87 stack. If SSE instructions are being used, all the code is strict in practice. -Joe From iignatyev at openjdk.java.net Tue Jan 26 18:26:46 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 26 Jan 2021 18:26:46 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop In-Reply-To: References: Message-ID: <3OCcv9-ZHzZmMPI_lxrozJuLq_M7a6FlbHTinkjguwo=.b9c777a0-53d1-4d6f-9f7e-f46e37947c92@github.com> On Tue, 26 Jan 2021 02:01:00 GMT, Wang Huang wrote: > The reason is : > > BasicType t = store->as_Mem()->memory_type(); > const char* fill_name; > if (msg == NULL && > StubRoutines::select_fill_function(t, false, fill_name) == NULL) { > msg = "unsupported store"; > msg_node = store; > } > > If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. > > I add a new case here to avoid mistake: > case T_NARROWOOP: > case T_NARROWKLASS: > case T_ADDRESS: > + case T_VOID: > // Currently unsupported > return NULL; Hi @Wanghuang-Huawei, given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken `TestLoopStoreVector.java` from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test in my [pull/132](https://github.com/iignatev/jdk16/tree/pull/132) branch (you will need to replace `$copyright-header` w/ the appropriate line), feel free to use it as-is or modify. Thanks, -- Igor ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 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 cjplummer at openjdk.java.net Tue Jan 26 19:21:40 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 26 Jan 2021 19:21:40 GMT Subject: RFR: 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out In-Reply-To: <8Fqe8u3bve_98l4YLiWUaAZ03lnH9a0cNVuHUozhrMg=.915af64e-8f64-48ee-83f2-3586bbe1a30a@github.com> References: <_RgVuhYJArTNFxi5AOShZPJkHwgn1FWGfe4uDIomKnQ=.ab70edda-fe2c-412f-baf6-a206a522e3e2@github.com> <8Fqe8u3bve_98l4YLiWUaAZ03lnH9a0cNVuHUozhrMg=.915af64e-8f64-48ee-83f2-3586bbe1a30a@github.com> Message-ID: On Tue, 26 Jan 2021 13:16:27 GMT, Harold Seigel wrote: >> LGTM! > > Thanks Thomas and Coleen for the reviews! I'll keep the Metaspace timeout as is for now to reduce the chances of that test timing out. I think SQE prefers multiple @test sections rather than multiple @run commands. You might want to check with @lmesnik or @iignatev on this. ------------- PR: https://git.openjdk.java.net/jdk/pull/2226 From iignatyev at openjdk.java.net Tue Jan 26 19:29:39 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 26 Jan 2021 19:29:39 GMT Subject: RFR: 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out In-Reply-To: References: <_RgVuhYJArTNFxi5AOShZPJkHwgn1FWGfe4uDIomKnQ=.ab70edda-fe2c-412f-baf6-a206a522e3e2@github.com> <8Fqe8u3bve_98l4YLiWUaAZ03lnH9a0cNVuHUozhrMg=.915af64e-8f64-48ee-83f2-3586bbe1a30a@github.com> Message-ID: On Tue, 26 Jan 2021 19:18:48 GMT, Chris Plummer wrote: > I think SQE prefers multiple @test sections rather than multiple @run commands. You might want to check with @lmesnik or @iignatev on this. That?s correct, if `@run` are independent, it?s preferable to split them into multiple test description sections, ie multiple blocks with `@test` as this allows greater control over their execution and test results are easier to interpret. Cheers, ? Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/2226 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 MRasmussen at perforce.com Tue Jan 26 19:38:46 2021 From: MRasmussen at perforce.com (Michael Rasmussen) Date: Tue, 26 Jan 2021 19:38:46 +0000 Subject: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 In-Reply-To: References: , , , Message-ID: I have been following the ticket a bit -- and noticed that you pushed the PR half an hour after I posted the simple test case in this thread. Many thanks for the speedy fix! /Michael ________________________________ From: Harold Seigel Sent: 26 January 2021 17:16 To: Michael Rasmussen ; hotspot-dev at openjdk.java.net Subject: Re: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 Hi Michael, This bug has been fixed. The fix should be available in a JDK-16 update release and in JDK-17. See https://bugs.openjdk.java.net/browse/JDK-8260009 for details. Thanks again for reporting it. Harold ________________________________ From: Michael Rasmussen Sent: Thursday, January 21, 2021 8:31 AM To: Harold Seigel ; hotspot-dev at openjdk.java.net Subject: [External] : Re: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 OK, managed to make a very simple reproduceable test: package com.test; import net.bytebuddy.agent.ByteBuddyAgent; import java.lang.instrument.Instrumentation; public class Main { public static void main(String[] args) throws Exception { final Instrumentation instrumentation = ByteBuddyAgent.install(); Foo.class.isSealed(); instrumentation.retransformClasses(Bar.class); } static sealed interface Foo permits Bar {} static final class Bar implements Foo {} } -- java.exe -showversion --enable-preview -Xlog:class+redefine+load=trace "-Xlog:sealed*=trace" -classpath target\classes;lib\asm-9.0.jar;lib\byte-buddy-agent-1.10.19.jar com.test.Main openjdk version "16-ea" 2021-03-16 OpenJDK Runtime Environment (build 16-ea+32-2190) OpenJDK 64-Bit Server VM (build 16-ea+32-2190, mixed mode, sharing) [0.271s][trace][class,sealed] Checking for permitted subclass of com.test.Main$Bar in com.test.Main$Foo [0.271s][trace][class,sealed] - Found it at permitted_subclasses[0] => cp[11] [0.273s][debug][redefine,class,load] loading name=com.test.Main$Bar kind=101 (avail_mem=22046284K) [0.273s][trace][class,sealed ] Checking for permitted subclass of com.test.Main$Bar in com.test.Main$Foo [0.273s][trace][class,sealed ] - class is NOT a permitted subclass! Exception in thread "main" java.lang.VerifyError at java.instrument/sun.instrument.InstrumentationImpl.retransformClasses0(Native Method) at java.instrument/sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:168) at com.test.Main.main(Main.java:13) /Michael ________________________________ From: Harold Seigel Sent: 19 January 2021 22:52 To: Michael Rasmussen ; hotspot-dev at openjdk.java.net Subject: Re: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 Hi Michael, I entered bug https://bugs.openjdk.java.net/browse/JDK-8260009 for this problem. Thank you for reporting it. Harold ________________________________ From: hotspot-dev on behalf of Michael Rasmussen Sent: Tuesday, January 19, 2021 3:27 PM To: hotspot-dev at openjdk.java.net Subject: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28 Hi, I noticed a regression in the verification of sealed classes, that I've narrowed down to happening between jdk-16+27 and jdk-16+28. Retransforming or redefining a sealed class can lead to a JVMTI_ERROR_FAILS_VERIFICATION, with Exception (0x00000000feb820a0), even though the class actually does that. I've tried to investigate the reason, and from what I can tell, it boils down to the check in InstanceKlass::has_as_permitted_subclass. In jdk-16+27, this method always seems to take the Symbol branch (_constants->tag_at(cp_index).is_klass() is false). But for jdk-16+28, it takes the Klass branch after the classes are loaded, and from what I can tell the (k2 == k) comparison can then fail during the redefinition since the Klass stored in the _permitted_subclasses is not the same as the one being verified, as a new InstanceKlass is allocated for the stream parser. Unfortunately, I haven't been able to produce a small self-contained test example, but I can reliably reproduce it while developing JRebel (which utilizes class retransformation), but hopefully the above is at least helpful in finding the issue and fixing it. /Michael This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. CAUTION: This email originated from outside of the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. CAUTION: This email originated from outside of the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. From iklam at openjdk.java.net Tue Jan 26 19:39:43 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 26 Jan 2021 19:39:43 GMT Subject: RFR: JDK-8260404: jvm_io.h include missing in a number of files In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 10:22:09 GMT, Thomas Stuefe wrote: > One of the last include corrections caused a build error on our AIX machines because compile.cpp uses jio_snprintf() without including jvm_io.h. > > I did not deeply follow up on the why, but "8260307: Do not include method.hpp in frame.hpp" is a possible candidate. AIX builds without JFR and hence miss a number of include chains other platforms have. > > I scanned hotspot sources for files using jio_snprintf but not including jvm_io.h. There are some hits, which should be fixed. > > All this is trivial, right? Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2232 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 hseigel at openjdk.java.net Tue Jan 26 21:23:40 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 26 Jan 2021 21:23:40 GMT Subject: RFR: 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out In-Reply-To: References: <_RgVuhYJArTNFxi5AOShZPJkHwgn1FWGfe4uDIomKnQ=.ab70edda-fe2c-412f-baf6-a206a522e3e2@github.com> <8Fqe8u3bve_98l4YLiWUaAZ03lnH9a0cNVuHUozhrMg=.915af64e-8f64-48ee-83f2-3586bbe1a30a@github.com> Message-ID: On Tue, 26 Jan 2021 19:26:35 GMT, Igor Ignatyev wrote: >> I think SQE prefers multiple @test sections rather than multiple @run commands. You might want to check with @lmesnik or @iignatev on this. > >> I think SQE prefers multiple @test sections rather than multiple @run commands. You might want to check with @lmesnik or @iignatev on this. > > That?s correct, if `@run` are independent, it?s preferable to split them into multiple test description sections, ie multiple blocks with `@test` as this allows greater control over their execution and test results are easier to interpret. > > Cheers, > ? Igor Thanks Igor and Chris. I create https://bugs.openjdk.java.net/browse/JDK-8260466 for the @run -> @test issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/2226 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 jiefu at openjdk.java.net Tue Jan 26 23:47:44 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 26 Jan 2021 23:47:44 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 02:01:00 GMT, Wang Huang wrote: > The reason is : > > BasicType t = store->as_Mem()->memory_type(); > const char* fill_name; > if (msg == NULL && > StubRoutines::select_fill_function(t, false, fill_name) == NULL) { > msg = "unsupported store"; > msg_node = store; > } > > If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. > > I add a new case here to avoid mistake: > case T_NARROWOOP: > case T_NARROWKLASS: > case T_ADDRESS: > + case T_VOID: > // Currently unsupported > return NULL; > Hi @Wanghuang-Huawei , I'm still not clear how to reproduce the bug. > Ah, I missed the attachment in the JBS. Thumbs-up @Wanghuang-Huawei . ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 From iklam at openjdk.java.net Tue Jan 26 23:51:49 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 26 Jan 2021 23:51:49 GMT Subject: RFR: 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp Message-ID: The "well-known classes" API in [systemDictionary.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/systemDictionary.hpp#L103) is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other. The proposed API follows the existing pattern of accessing known symbols/intrinsics in [vmSymbols.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmSymbols.hpp#L53) and [vmIntrinsics.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmIntrinsics.hpp#L108): #include "classfile/vmClasses.hpp" #include "classfile/vmIntrinsics.hpp" #include "classfile/vmSymbols.hpp" // NEW Symbol* s = vmSymbols::java_lang_Object(); vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial; Klass* k = vmClasses::Object_klass(); // NEW Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like `SystemDictionary::Object_klass()` to `vmClasses::Object_klass()`. That will be done in a subtask ([JDK-8260471](https://bugs.openjdk.java.net/browse/JDK-8260471) -- [preliminary webrev](http://cr.openjdk.java.net/~iklam/jdk17/8260471-decouple-vmClasses-and-SystemDictionary/)). Within this RFE, we temporarily subclass `SystemDictionary` from `vmClasses`, so `SystemDictionary::Object_klass()` will continue to work. Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- Commit messages: - Merge branch 'master' into 8260467-move-well-known-klasses-out-of-system-dictionary - added missing vmClasses.hpp - Renamed VMClasses to vmClasses to be consistent with vmSymbols - Move well_known_classes out of SystemDictionary Changes: https://git.openjdk.java.net/jdk/pull/2246/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2246&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260467 Stats: 1208 lines in 35 files changed: 634 ins; 455 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/2246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2246/head:pull/2246 PR: https://git.openjdk.java.net/jdk/pull/2246 From iklam at openjdk.java.net Wed Jan 27 00:04:44 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 27 Jan 2021 00:04:44 GMT Subject: RFR: 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 23:13:33 GMT, Ioi Lam wrote: > The "well-known classes" API in [systemDictionary.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/systemDictionary.hpp#L103) is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other. > > The proposed API follows the existing pattern of accessing known symbols/intrinsics in [vmSymbols.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmSymbols.hpp#L53) and [vmIntrinsics.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmIntrinsics.hpp#L108): > > #include "classfile/vmClasses.hpp" > #include "classfile/vmIntrinsics.hpp" > #include "classfile/vmSymbols.hpp" // NEW > > Symbol* s = vmSymbols::java_lang_Object(); > vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial; > Klass* k = vmClasses::Object_klass(); // NEW > > Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like `SystemDictionary::Object_klass()` to `vmClasses::Object_klass()`. That will be done in a subtask ([JDK-8260471](https://bugs.openjdk.java.net/browse/JDK-8260471) -- [preliminary webrev](http://cr.openjdk.java.net/~iklam/jdk17/8260471-decouple-vmClasses-and-SystemDictionary/)). > > Within this RFE, we temporarily subclass `SystemDictionary` from `vmClasses`, so `SystemDictionary::Object_klass()` will continue to work. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. The name `vmClasses` is in `lowerCamelCase`, which is a deviation from the rest of the HotSpot code, where most classes have `UpperCamelCase` names. However, `vmClasses` and `vmSymbols` are often used together, like the following, so a consistent look would be nice: JavaCalls::call_static(&result, vmClasses::MethodHandleNatives_klass(), vmSymbols::linkMethodHandleConstant_name(), vmSymbols::linkMethodHandleConstant_signature(), &args, CHECK_(empty)); ------------- PR: https://git.openjdk.java.net/jdk/pull/2246 From coleen.phillimore at oracle.com Wed Jan 27 00:55:56 2021 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Jan 2021 19:55:56 -0500 Subject: RFR: 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp In-Reply-To: References: Message-ID: On 1/26/21 7:04 PM, Ioi Lam wrote: > On Tue, 26 Jan 2021 23:13:33 GMT, Ioi Lam wrote: > >> The "well-known classes" API in [systemDictionary.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/systemDictionary.hpp#L103) is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other. >> >> The proposed API follows the existing pattern of accessing known symbols/intrinsics in [vmSymbols.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmSymbols.hpp#L53) and [vmIntrinsics.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmIntrinsics.hpp#L108): >> >> #include "classfile/vmClasses.hpp" >> #include "classfile/vmIntrinsics.hpp" >> #include "classfile/vmSymbols.hpp" // NEW >> >> Symbol* s = vmSymbols::java_lang_Object(); >> vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial; >> Klass* k = vmClasses::Object_klass(); // NEW >> >> Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like `SystemDictionary::Object_klass()` to `vmClasses::Object_klass()`. That will be done in a subtask ([JDK-8260471](https://bugs.openjdk.java.net/browse/JDK-8260471) -- [preliminary webrev](http://cr.openjdk.java.net/~iklam/jdk17/8260471-decouple-vmClasses-and-SystemDictionary/)). >> >> Within this RFE, we temporarily subclass `SystemDictionary` from `vmClasses`, so `SystemDictionary::Object_klass()` will continue to work. >> >> Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > The name `vmClasses` is in `lowerCamelCase`, which is a deviation from the rest of the HotSpot code, where most classes have `UpperCamelCase` names. However, `vmClasses` and `vmSymbols` are often used together, like the following, so a consistent look would be nice: > > JavaCalls::call_static(&result, > vmClasses::MethodHandleNatives_klass(), > vmSymbols::linkMethodHandleConstant_name(), > vmSymbols::linkMethodHandleConstant_signature(), > &args, CHECK_(empty)); I agree! > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2246 From ddong at openjdk.java.net Wed Jan 27 02:25:01 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 27 Jan 2021 02:25:01 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v5] In-Reply-To: References: Message-ID: <1a-o8CEtmWfhrp2K9gzs8pqgt_ISmH8BEivGEqS4Rlo=.d16eda2f-b559-4083-a16e-25a1dd0d325a@github.com> On Tue, 26 Jan 2021 16:49:37 GMT, Erik Gahlin wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> Add descriptions and fix the format problem > > src/hotspot/share/jfr/metadata/metadata.xml line 1094: > >> 1092: >> 1093: >> 1094: > > I would suggest changing this to: > > "The number of Java threads in a critical section when the GC locker is started" > "The number of Java threads stalled by the GC locker" changed. > src/hotspot/share/jfr/metadata/metadata.xml line 1093: > >> 1091: >> 1092: >> 1093: > > "GC Locker Information" is not very useful. Remove the description completely or provide more information. removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Wed Jan 27 02:25:00 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 27 Jan 2021 02:25:00 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v6] In-Reply-To: References: Message-ID: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: improve descriptions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2088/files - new: https://git.openjdk.java.net/jdk/pull/2088/files/a5d0e0a3..7efac60f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2088/head:pull/2088 PR: https://git.openjdk.java.net/jdk/pull/2088 From dholmes at openjdk.java.net Wed Jan 27 06:37:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 27 Jan 2021 06:37:41 GMT Subject: RFR: JDK-8260404: jvm_io.h include missing in a number of files In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 10:22:09 GMT, Thomas Stuefe wrote: > One of the last include corrections caused a build error on our AIX machines because compile.cpp uses jio_snprintf() without including jvm_io.h. > > I did not deeply follow up on the why, but "8260307: Do not include method.hpp in frame.hpp" is a possible candidate. AIX builds without JFR and hence miss a number of include chains other platforms have. > > I scanned hotspot sources for files using jio_snprintf but not including jvm_io.h. There are some hits, which should be fixed. > > All this is trivial, right? Hi Thomas, This all seems okay. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2232 From dholmes at openjdk.java.net Wed Jan 27 06:33:45 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 27 Jan 2021 06:33:45 GMT Subject: RFR: 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 23:13:33 GMT, Ioi Lam wrote: > The "well-known classes" API in [systemDictionary.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/systemDictionary.hpp#L103) is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other. > > The proposed API follows the existing pattern of accessing known symbols/intrinsics in [vmSymbols.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmSymbols.hpp#L53) and [vmIntrinsics.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmIntrinsics.hpp#L108): > > #include "classfile/vmClasses.hpp" > #include "classfile/vmIntrinsics.hpp" > #include "classfile/vmSymbols.hpp" // NEW > > Symbol* s = vmSymbols::java_lang_Object(); > vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial; > Klass* k = vmClasses::Object_klass(); // NEW > > Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like `SystemDictionary::Object_klass()` to `vmClasses::Object_klass()`. That will be done in a subtask ([JDK-8260471](https://bugs.openjdk.java.net/browse/JDK-8260471) -- [preliminary webrev](http://cr.openjdk.java.net/~iklam/jdk17/8260471-decouple-vmClasses-and-SystemDictionary/)). > > Within this RFE, we temporarily subclass `SystemDictionary` from `vmClasses`, so `SystemDictionary::Object_klass()` will continue to work. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Hi Ioi, This first step at refactoring and renaming looks good. Only one comment below. Thanks, David src/hotspot/share/classfile/vmClasses.cpp line 219: > 217: #if INCLUDE_CDS > 218: > 219: void vmClasses::resolve_shared_class(InstanceKlass* klass, ClassLoaderData* loader_data, Handle domain, TRAPS) { It isn't at all obvious to me why this functionality was relocated. I don't see anything vmClasses related in here. ?? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2246 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 stuefe at openjdk.java.net Wed Jan 27 07:37:41 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 27 Jan 2021 07:37:41 GMT Subject: Integrated: JDK-8260404: jvm_io.h include missing in a number of files In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 10:22:09 GMT, Thomas Stuefe wrote: > One of the last include corrections caused a build error on our AIX machines because compile.cpp uses jio_snprintf() without including jvm_io.h. > > I did not deeply follow up on the why, but "8260307: Do not include method.hpp in frame.hpp" is a possible candidate. AIX builds without JFR and hence miss a number of include chains other platforms have. > > I scanned hotspot sources for files using jio_snprintf but not including jvm_io.h. There are some hits, which should be fixed. > > All this is trivial, right? This pull request has now been integrated. Changeset: 1c770468 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/1c770468 Stats: 26 lines in 16 files changed: 16 ins; 0 del; 10 mod 8260404: jvm_io.h include missing in a number of files Reviewed-by: shade, iklam, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/2232 From stuefe at openjdk.java.net Wed Jan 27 07:37:40 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 27 Jan 2021 07:37:40 GMT Subject: RFR: JDK-8260404: jvm_io.h include missing in a number of files In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 06:35:10 GMT, David Holmes wrote: >> One of the last include corrections caused a build error on our AIX machines because compile.cpp uses jio_snprintf() without including jvm_io.h. >> >> I did not deeply follow up on the why, but "8260307: Do not include method.hpp in frame.hpp" is a possible candidate. AIX builds without JFR and hence miss a number of include chains other platforms have. >> >> I scanned hotspot sources for files using jio_snprintf but not including jvm_io.h. There are some hits, which should be fixed. >> >> All this is trivial, right? > > Hi Thomas, > > This all seems okay. > > Thanks, > David Thanks Alexey, Ioi and David! ------------- PR: https://git.openjdk.java.net/jdk/pull/2232 From iklam at openjdk.java.net Wed Jan 27 07:52:41 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 27 Jan 2021 07:52:41 GMT Subject: RFR: 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 06:27:51 GMT, David Holmes wrote: >> The "well-known classes" API in [systemDictionary.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/systemDictionary.hpp#L103) is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other. >> >> The proposed API follows the existing pattern of accessing known symbols/intrinsics in [vmSymbols.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmSymbols.hpp#L53) and [vmIntrinsics.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmIntrinsics.hpp#L108): >> >> #include "classfile/vmClasses.hpp" >> #include "classfile/vmIntrinsics.hpp" >> #include "classfile/vmSymbols.hpp" // NEW >> >> Symbol* s = vmSymbols::java_lang_Object(); >> vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial; >> Klass* k = vmClasses::Object_klass(); // NEW >> >> Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like `SystemDictionary::Object_klass()` to `vmClasses::Object_klass()`. That will be done in a subtask ([JDK-8260471](https://bugs.openjdk.java.net/browse/JDK-8260471) -- [preliminary webrev](http://cr.openjdk.java.net/~iklam/jdk17/8260471-decouple-vmClasses-and-SystemDictionary/)). >> >> Within this RFE, we temporarily subclass `SystemDictionary` from `vmClasses`, so `SystemDictionary::Object_klass()` will continue to work. >> >> Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > src/hotspot/share/classfile/vmClasses.cpp line 219: > >> 217: #if INCLUDE_CDS >> 218: >> 219: void vmClasses::resolve_shared_class(InstanceKlass* klass, ClassLoaderData* loader_data, Handle domain, TRAPS) { > > It isn't at all obvious to me why this functionality was relocated. I don't see anything vmClasses related in here. ?? `vmClasses::resolve_shared_class()` is a private method and is called from here: bool vmClasses::resolve(VMClassID id, TRAPS) { InstanceKlass** klassp = &_klasses[as_int(id)]; ... InstanceKlass* k = *klassp; resolve_shared_class(k, ....); <---- HERE } Maybe the function name is not clear enough. It's meant to "resolve a vmClass from the CDS archive". It used to be the (even more confusingly named) `SystemDictionary::quick_resolve()` method. ------------- PR: https://git.openjdk.java.net/jdk/pull/2246 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:41:03 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jan 2021 18:41:03 +1000 Subject: RFR: 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp In-Reply-To: References: Message-ID: <3dc2f75a-3193-d7e8-6a28-3fae46b176ad@oracle.com> On 27/01/2021 5:52 pm, Ioi Lam wrote: > On Wed, 27 Jan 2021 06:27:51 GMT, David Holmes wrote: > >>> The "well-known classes" API in [systemDictionary.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/systemDictionary.hpp#L103) is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other. >>> >>> The proposed API follows the existing pattern of accessing known symbols/intrinsics in [vmSymbols.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmSymbols.hpp#L53) and [vmIntrinsics.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmIntrinsics.hpp#L108): >>> >>> #include "classfile/vmClasses.hpp" >>> #include "classfile/vmIntrinsics.hpp" >>> #include "classfile/vmSymbols.hpp" // NEW >>> >>> Symbol* s = vmSymbols::java_lang_Object(); >>> vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial; >>> Klass* k = vmClasses::Object_klass(); // NEW >>> >>> Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like `SystemDictionary::Object_klass()` to `vmClasses::Object_klass()`. That will be done in a subtask ([JDK-8260471](https://bugs.openjdk.java.net/browse/JDK-8260471) -- [preliminary webrev](http://cr.openjdk.java.net/~iklam/jdk17/8260471-decouple-vmClasses-and-SystemDictionary/)). >>> >>> Within this RFE, we temporarily subclass `SystemDictionary` from `vmClasses`, so `SystemDictionary::Object_klass()` will continue to work. >>> >>> Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. >> >> src/hotspot/share/classfile/vmClasses.cpp line 219: >> >>> 217: #if INCLUDE_CDS >>> 218: >>> 219: void vmClasses::resolve_shared_class(InstanceKlass* klass, ClassLoaderData* loader_data, Handle domain, TRAPS) { >> >> It isn't at all obvious to me why this functionality was relocated. I don't see anything vmClasses related in here. ?? > > `vmClasses::resolve_shared_class()` is a private method and is called from here: > > bool vmClasses::resolve(VMClassID id, TRAPS) { > InstanceKlass** klassp = &_klasses[as_int(id)]; > ... > InstanceKlass* k = *klassp; > resolve_shared_class(k, ....); <---- HERE > } > > Maybe the function name is not clear enough. It's meant to "resolve a vmClass from the CDS archive". It used to be the (even more confusingly named) `SystemDictionary::quick_resolve()` method. Thanks for clarifying - the fact it has a single caller was not clear. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2246 > 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 whuang at openjdk.java.net Wed Jan 27 09:05:46 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 27 Jan 2021 09:05:46 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 02:01:00 GMT, Wang Huang wrote: > The reason is : > > BasicType t = store->as_Mem()->memory_type(); > const char* fill_name; > if (msg == NULL && > StubRoutines::select_fill_function(t, false, fill_name) == NULL) { > msg = "unsupported store"; > msg_node = store; > } > > If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. > > I add a new case here to avoid mistake: > case T_NARROWOOP: > case T_NARROWKLASS: > case T_ADDRESS: > + case T_VOID: > // Currently unsupported > return NULL; > Hi @Wanghuang-Huawei, > > given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken `TestLoopStoreVector.java` from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test from my [pull/132](https://github.com/iignatev/jdk16/tree/pull/132) branch (you will need to replace `$copyright-header` w/ the appropriate line), feel free to use it as-is or modify. > > Thanks, > -- Igor Thank you very much. I will push a new commit which contains jtreg test. ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 From whuang at openjdk.java.net Wed Jan 27 09:27:04 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 27 Jan 2021 09:27:04 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v4] In-Reply-To: References: Message-ID: > The reason is : > > BasicType t = store->as_Mem()->memory_type(); > const char* fill_name; > if (msg == NULL && > StubRoutines::select_fill_function(t, false, fill_name) == NULL) { > msg = "unsupported store"; > msg_node = store; > } > > If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. > > I add a new case here to avoid mistake: > case T_NARROWOOP: > case T_NARROWKLASS: > case T_ADDRESS: > + case T_VOID: > // Currently unsupported > return NULL; Wang Huang has updated the pull request incrementally with one additional commit since the last revision: add jtreg test case ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/132/files - new: https://git.openjdk.java.net/jdk16/pull/132/files/ee3797d9..7ec5e23b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=02-03 Stats: 80 lines in 1 file changed: 80 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/132.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132 PR: https://git.openjdk.java.net/jdk16/pull/132 From whuang at openjdk.java.net Wed Jan 27 09:34:03 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 27 Jan 2021 09:34:03 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v5] In-Reply-To: References: Message-ID: > The reason is : > > BasicType t = store->as_Mem()->memory_type(); > const char* fill_name; > if (msg == NULL && > StubRoutines::select_fill_function(t, false, fill_name) == NULL) { > msg = "unsupported store"; > msg_node = store; > } > > If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. > > I add a new case here to avoid mistake: > case T_NARROWOOP: > case T_NARROWKLASS: > case T_ADDRESS: > + case T_VOID: > // Currently unsupported > return NULL; Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix code style ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/132/files - new: https://git.openjdk.java.net/jdk16/pull/132/files/7ec5e23b..6efc7cee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=03-04 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk16/pull/132.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132 PR: https://git.openjdk.java.net/jdk16/pull/132 From whuang at openjdk.java.net Wed Jan 27 09:37:08 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 27 Jan 2021 09:37:08 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v6] In-Reply-To: References: Message-ID: > The reason is : > > BasicType t = store->as_Mem()->memory_type(); > const char* fill_name; > if (msg == NULL && > StubRoutines::select_fill_function(t, false, fill_name) == NULL) { > msg = "unsupported store"; > msg_node = store; > } > > If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. > > I add a new case here to avoid mistake: > case T_NARROWOOP: > case T_NARROWKLASS: > case T_ADDRESS: > + case T_VOID: > // Currently unsupported > return NULL; Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix trailing whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/132/files - new: https://git.openjdk.java.net/jdk16/pull/132/files/6efc7cee..b9f1a249 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/132.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132 PR: https://git.openjdk.java.net/jdk16/pull/132 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 neliasso at openjdk.java.net Wed Jan 27 10:25:45 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Wed, 27 Jan 2021 10:25:45 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 09:02:26 GMT, Wang Huang wrote: >> The reason is : >> >> BasicType t = store->as_Mem()->memory_type(); >> const char* fill_name; >> if (msg == NULL && >> StubRoutines::select_fill_function(t, false, fill_name) == NULL) { >> msg = "unsupported store"; >> msg_node = store; >> } >> >> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. >> >> I add a new case here to avoid mistake: >> case T_NARROWOOP: >> case T_NARROWKLASS: >> case T_ADDRESS: >> + case T_VOID: >> // Currently unsupported >> return NULL; > >> Hi @Wanghuang-Huawei, >> >> given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken `TestLoopStoreVector.java` from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test from my [pull/132](https://github.com/iignatev/jdk16/tree/pull/132) branch (you will need to replace `$copyright-header` w/ the appropriate line), feel free to use it as-is or modify. >> >> Thanks, >> -- Igor > > Thank you very much. I will push a new commit which contains jtreg test. @Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64. ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 From jiefu at openjdk.java.net Wed Jan 27 10:41:41 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 27 Jan 2021 10:41:41 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 09:02:26 GMT, Wang Huang wrote: >> The reason is : >> >> BasicType t = store->as_Mem()->memory_type(); >> const char* fill_name; >> if (msg == NULL && >> StubRoutines::select_fill_function(t, false, fill_name) == NULL) { >> msg = "unsupported store"; >> msg_node = store; >> } >> >> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. >> >> I add a new case here to avoid mistake: >> case T_NARROWOOP: >> case T_NARROWKLASS: >> case T_ADDRESS: >> + case T_VOID: >> // Currently unsupported >> return NULL; > >> Hi @Wanghuang-Huawei, >> >> given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken `TestLoopStoreVector.java` from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test from my [pull/132](https://github.com/iignatev/jdk16/tree/pull/132) branch (you will need to replace `$copyright-header` w/ the appropriate line), feel free to use it as-is or modify. >> >> Thanks, >> -- Igor > > Thank you very much. I will push a new commit which contains jtreg test. > @Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64. I tried the reproducer on the JBS just now and couldn't reproduce it on x64 either. ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 From njian at openjdk.java.net Wed Jan 27 10:41:42 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 27 Jan 2021 10:41:42 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 09:02:26 GMT, Wang Huang wrote: >> The reason is : >> >> BasicType t = store->as_Mem()->memory_type(); >> const char* fill_name; >> if (msg == NULL && >> StubRoutines::select_fill_function(t, false, fill_name) == NULL) { >> msg = "unsupported store"; >> msg_node = store; >> } >> >> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. >> >> I add a new case here to avoid mistake: >> case T_NARROWOOP: >> case T_NARROWKLASS: >> case T_ADDRESS: >> + case T_VOID: >> // Currently unsupported >> return NULL; > >> Hi @Wanghuang-Huawei, >> >> given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken `TestLoopStoreVector.java` from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test from my [pull/132](https://github.com/iignatev/jdk16/tree/pull/132) branch (you will need to replace `$copyright-header` w/ the appropriate line), feel free to use it as-is or modify. >> >> Thanks, >> -- Igor > > Thank you very much. I will push a new commit which contains jtreg test. > @Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64. I think x64 has disabled OptimizeFill by default. I can reproduce this with -XX:+OptimizeFill. ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 From stuefe at openjdk.java.net Wed Jan 27 10:43:55 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 27 Jan 2021 10:43:55 GMT Subject: RFR: JDK-8260485: Simplify and unify handler vectors in Posix signal code Message-ID: In signal handling code, we have code sections which save signal handler state into vectors of sigaction structures, or of integers (if only flags are saved). All these code sections can be unified, disentangled and the using code simplified. There are three places where we do this: 1) When installing hotspot signal handlers, should we find a handler in place and signal chaining is enabled, we save the original handler inside a sigaction array and a corresponding sigset: https://github.com/openjdk/jdk/blob/e0d748d56f817b4fb5158aae86aee12d90b36356/src/hotspot/os/posix/signals_posix.cpp#L85 https://github.com/openjdk/jdk/blob/e0d748d56f817b4fb5158aae86aee12d90b36356/src/hotspot/os/posix/signals_posix.cpp#L338 2) if diagnostics are enabled with -Xcheck:jni, we periodically check if our hotspot signal handlers had been replaced (`static void check_signal_handler(int sig)`): https://github.com/openjdk/jdk/blob/e0d748d56f817b4fb5158aae86aee12d90b36356/src/hotspot/os/posix/signals_posix.cpp#L766 To do that, we store information about the handlers we installed and we expect to be intact; in this case we only store the sigaction flags (`int sigflags[NSIG];`) and deduce the handler address from context. 3) There is a complicated dance between VMError and the posix signal handler code: If a fatal error happens, we enter error reporting and install the secondary handler (`VMError::install_secondary_signal_handler()`). Before doing that, we store the handler we replace in yet another array, in this case one array for the handler address, one for the flag: https://github.com/openjdk/jdk/blob/e0d748d56f817b4fb5158aae86aee12d90b36356/src/hotspot/os/posix/vmError_posix.cpp#L77 I believe the purpose of this is to - when printing signal handlers as part of error reporting - print the original signal handler instead of the secondary crash handler (see `PosixSignals::print_signal_handler()`): https://github.com/openjdk/jdk/blob/e0d748d56f817b4fb5158aae86aee12d90b36356/src/hotspot/os/posix/signals_posix.cpp#L1372 and additionally to not trip this warning here: https://github.com/openjdk/jdk/blob/e0d748d56f817b4fb5158aae86aee12d90b36356/src/hotspot/os/posix/signals_posix.cpp#L1391 ------ Changes in this patch: - I added some convenience macros to check if a handler matches a given function (HANDLER_IS), check if a handler is set to ignore or default or both (HANDLER_IS_IGN, HANDLER_IS_DFL, HANDLER_IS_IGN_OR_DFL). Makes code more readable. - I added convenience class `SavedSignalHandlers` to keep a vector of handler information by signal number. - I used that class to cover cases (1)..(3): - `chained_handlers` contains all information of chained handlers - `expected_handlers` contains a copy of the handlers the hotspot installed - `replaced_handlers` contains information about replaced handlers - about (1): I store the chained signal handler information in `chained_handlers` when installing a hotspot handler, UseSignalChaining is 1, and a non-default handler was encountered. - about (2): I simplified the signal checking mechanism quite a bit: it compares the handler (address and flags) it finds present with expectations. Before this patch, the expected handler address was deduced in a hard-wired way, now, we just compare the active sigaction structure with the one we installed on VM start. - about (3): when installing any handler (hotspot as well as user defined via java), I store the handler it replaced in `replaced_handlers`. I use that to print which handler had been replaced in `PosixSignals::print_signal_handler`. I simplified `PosixSignals::print_signal_handler` such that it does not retain any knowledge about hotspot signal handlers. Now, it just prints out the currently established handlers. In addition to that, it prints out chaining information and which handlers had been replaced. I removed the associated coding from VMError. Output Before: 663 Signal Handlers: 664 SIGSEGV: javaSignalHandler in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 665 SIGBUS: javaSignalHandler in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 666 SIGFPE: javaSignalHandler in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 667 SIGPIPE: javaSignalHandler in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 668 SIGXFSZ: javaSignalHandler in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 669 SIGILL: javaSignalHandler in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 670 SIGUSR2: SR_handler in libjvm.so, sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO 671 SIGHUP: UserHandler in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 672 SIGINT: UserHandler in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 673 SIGTERM: UserHandler in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 674 SIGQUIT: UserHandler in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 675 SIGTRAP: javaSignalHandler in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO Now: Signal Handlers: SIGSEGV: crash_handler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO replaced: SIGSEGV: javaSignalHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGBUS: crash_handler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO replaced: SIGBUS: javaSignalHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGFPE: crash_handler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO replaced: SIGFPE: javaSignalHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGPIPE: javaSignalHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGXFSZ: javaSignalHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGILL: crash_handler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO replaced: SIGILL: javaSignalHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGUSR2: SR_handler in libjvm.so, mask=00000000000000000000000000000000, flags=SA_RESTART|SA_SIGINFO SIGHUP: UserHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGINT: UserHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGTERM: UserHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGQUIT: UserHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGTRAP: crash_handler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO ----- Tests: GA, and the patch has been tested in our nighlies for over a month now. I manually executed the runtime/jni/checked tests too. ------------- Commit messages: - JDK-8260485-signal-handler-improvements Changes: https://git.openjdk.java.net/jdk/pull/2251/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2251&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260485 Stats: 328 lines in 4 files changed: 126 ins; 132 del; 70 mod Patch: https://git.openjdk.java.net/jdk/pull/2251.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2251/head:pull/2251 PR: https://git.openjdk.java.net/jdk/pull/2251 From lucy at openjdk.java.net Wed Jan 27 10:45:41 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 27 Jan 2021 10:45:41 GMT Subject: RFR: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently [v4] In-Reply-To: <83VP-6dw_pvAkaFLm0u56lIjoH85dLz3hOKZBH3FNsM=.1de019f9-6675-4ca0-b0fe-57772696cfb4@github.com> References: <83VP-6dw_pvAkaFLm0u56lIjoH85dLz3hOKZBH3FNsM=.1de019f9-6675-4ca0-b0fe-57772696cfb4@github.com> Message-ID: <4SCO8rjpxY8QjxivyHhAzoSFRtq1HyV2fXFtyBrTIWU=.f22c536b-f58a-46bd-9d92-d05b2b5f7ded@github.com> On Thu, 21 Jan 2021 12:16:20 GMT, Thomas Stuefe wrote: >> When function descriptors are fed to os::print_function_and_library_name() to get debug output, it would be very helpful to transparently handle the case where the address is not a code pointer but a function descriptor. >> >> Of the official OpenJDK platforms this affects only ppc, but also includes at least ia64 for those who maintain ports to that platform. >> >> Fixing this will also fix the display of signal handlers on linux ppc which still show up without function names after JDK-8258606. >> >> Before: >> 695 Signal Handlers: >> 696 SIGSEGV: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 697 SIGBUS: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 698 SIGFPE: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 699 SIGPIPE: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 700 SIGXFSZ: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 701 SIGILL: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 702 SIGUSR2: 0x00000fff8d0e0098 in libjvm.so+34799768, sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >> 703 SIGHUP: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 704 SIGINT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 705 SIGTERM: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 706 SIGQUIT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 707 SIGTRAP: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> >> Now: >> 693 Signal Handlers: >> 694 SIGSEGV: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 695 SIGBUS: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 696 SIGFPE: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 697 SIGPIPE: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 698 SIGXFSZ: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 699 SIGILL: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 700 SIGUSR2: SR_handler in libjvm.so (FD), sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >> 701 SIGHUP: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 702 SIGINT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 703 SIGTERM: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 704 SIGQUIT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> 705 SIGTRAP: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> >> The patch also adds a little trailing marker `(FD)` as an indication for the developer that this had been a function descriptor. > > Thomas Stuefe 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 changes look good to me. Thanks for enhancing the output. Looks much nicer now! I don't like that you had to include additional asm headers. But that's not your fault. As in other places, the include hierarchy is messed up. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2157 From stuefe at openjdk.java.net Wed Jan 27 10:45:41 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 27 Jan 2021 10:45:41 GMT Subject: RFR: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently [v4] In-Reply-To: <4SCO8rjpxY8QjxivyHhAzoSFRtq1HyV2fXFtyBrTIWU=.f22c536b-f58a-46bd-9d92-d05b2b5f7ded@github.com> References: <83VP-6dw_pvAkaFLm0u56lIjoH85dLz3hOKZBH3FNsM=.1de019f9-6675-4ca0-b0fe-57772696cfb4@github.com> <4SCO8rjpxY8QjxivyHhAzoSFRtq1HyV2fXFtyBrTIWU=.f22c536b-f58a-46bd-9d92-d05b2b5f7ded@github.com> Message-ID: On Wed, 27 Jan 2021 10:39:27 GMT, Lutz Schmidt wrote: > The changes look good to me. > Thanks for enhancing the output. Looks much nicer now! > I don't like that you had to include additional asm headers. But that's not your fault. As in other places, the include hierarchy is messed up. Thank you Lutz! About the header, I got a build error without that include. ------------- PR: https://git.openjdk.java.net/jdk/pull/2157 From stuefe at openjdk.java.net Wed Jan 27 10:45:42 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 27 Jan 2021 10:45:42 GMT Subject: Integrated: JDK-8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 06:39:06 GMT, Thomas Stuefe wrote: > When function descriptors are fed to os::print_function_and_library_name() to get debug output, it would be very helpful to transparently handle the case where the address is not a code pointer but a function descriptor. > > Of the official OpenJDK platforms this affects only ppc, but also includes at least ia64 for those who maintain ports to that platform. > > Fixing this will also fix the display of signal handlers on linux ppc which still show up without function names after JDK-8258606. > > Before: > 695 Signal Handlers: > 696 SIGSEGV: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 697 SIGBUS: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 698 SIGFPE: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 699 SIGPIPE: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 700 SIGXFSZ: 0x00000fff8d0e0158 in libjvm.so+34799960, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 701 SIGILL: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 702 SIGUSR2: 0x00000fff8d0e0098 in libjvm.so+34799768, sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > 703 SIGHUP: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 704 SIGINT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 705 SIGTERM: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 706 SIGQUIT: 0x00000fff8d0e0080 in libjvm.so+34799744, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 707 SIGTRAP: 0x00000fff8d0f4348 in libjvm.so+34882376, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > Now: > 693 Signal Handlers: > 694 SIGSEGV: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 695 SIGBUS: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 696 SIGFPE: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 697 SIGPIPE: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 698 SIGXFSZ: javaSignalHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 699 SIGILL: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 700 SIGUSR2: SR_handler in libjvm.so (FD), sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > 701 SIGHUP: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 702 SIGINT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 703 SIGTERM: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 704 SIGQUIT: UserHandler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > 705 SIGTRAP: crash_handler in libjvm.so (FD), sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > The patch also adds a little trailing marker `(FD)` as an indication for the developer that this had been a function descriptor. This pull request has now been integrated. Changeset: 3e4194c4 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/3e4194c4 Stats: 50 lines in 6 files changed: 45 ins; 0 del; 5 mod 8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently Reviewed-by: mdoerr, lucy ------------- PR: https://git.openjdk.java.net/jdk/pull/2157 From neliasso at openjdk.java.net Wed Jan 27 11:13:42 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Wed, 27 Jan 2021 11:13:42 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 10:39:24 GMT, Ningsheng Jian wrote: >>> Hi @Wanghuang-Huawei, >>> >>> given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken `TestLoopStoreVector.java` from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test from my [pull/132](https://github.com/iignatev/jdk16/tree/pull/132) branch (you will need to replace `$copyright-header` w/ the appropriate line), feel free to use it as-is or modify. >>> >>> Thanks, >>> -- Igor >> >> Thank you very much. I will push a new commit which contains jtreg test. > >> @Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64. > > I think x64 has disabled OptimizeFill by default. I can reproduce this with -XX:+OptimizeFill. Please add -XX:+OptimizeFill to the regression test ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 From rkennke at openjdk.java.net Wed Jan 27 12:54:46 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 12:54:46 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 19:00:52 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 > # Error: assert(VM_Version::supports_sse2()) failed > > V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 > V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d > V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f > > This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. > > Additional testing: > - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` Nice change! See comment. Do we need to handle no-SSE case too? src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 127: > 125: __ get_thread(thread); > 126: #endif > 127: assert_different_registers(src, dst, count, thread); Take a look at methodHandles_x86.cpp, there is pushing/popping code like this: #ifdef _LP64 __ movdbl(Address(rsp, 0), xmm0); #else if (UseSSE >= 2) { __ movdbl(Address(rsp, 0), xmm0); } else if (UseSSE == 1) { __ movflt(Address(rsp, 0), xmm0); } else { __ fst_d(Address(rsp, 0)); } #endif // LP64 IOW, it also has a branch for no SSE at all. :-) BTW, I am almost certain that we only ever need to save/restore xmm0. The relevant code is (afaict) only ever called by the interpreter (which only uses xmm0) and methodHandles (which also only seems to care about xmm0 - see the various code sequences there 'save FP result'). Grep for load_heap_oop(), that gives all relevant entries. But that is outside the scope of this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From shade at openjdk.java.net Wed Jan 27 12:54:46 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 12:54:46 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code Message-ID: $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 # Error: assert(VM_Version::supports_sse2()) failed V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. Additional testing: - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` ------------- Commit messages: - Merge branch 'master' into JDK-8256215-shenandoah-no-sse2-fail - Simplify - Merge branch 'master' into JDK-8256215-shenandoah-no-sse2-fail - Merge branch 'master' into JDK-8256215-shenandoah-no-sse2-fail - Merge branch 'master' into JDK-8256215-shenandoah-no-sse2-fail - 8256215: Some x86_32 Shenandoah tests fail due to using unsupported SSE2 instructions Changes: https://git.openjdk.java.net/jdk/pull/1172/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1172&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256215 Stats: 118 lines in 2 files changed: 69 ins; 13 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/1172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1172/head:pull/1172 PR: https://git.openjdk.java.net/jdk/pull/1172 From rkennke at openjdk.java.net Wed Jan 27 12:54:47 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 12:54:47 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 21:42:52 GMT, Roman Kennke wrote: >> $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 >> # Error: assert(VM_Version::supports_sse2()) failed >> >> V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 >> V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d >> V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f >> >> This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. >> >> Additional testing: >> - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` > > src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 127: > >> 125: __ get_thread(thread); >> 126: #endif >> 127: assert_different_registers(src, dst, count, thread); > > Take a look at methodHandles_x86.cpp, there is pushing/popping code like this: > #ifdef _LP64 > __ movdbl(Address(rsp, 0), xmm0); > #else > if (UseSSE >= 2) { > __ movdbl(Address(rsp, 0), xmm0); > } else if (UseSSE == 1) { > __ movflt(Address(rsp, 0), xmm0); > } else { > __ fst_d(Address(rsp, 0)); > } > #endif // LP64 > > IOW, it also has a branch for no SSE at all. :-) > > BTW, I am almost certain that we only ever need to save/restore xmm0. The relevant code is (afaict) only ever called by the interpreter (which only uses xmm0) and methodHandles (which also only seems to care about xmm0 - see the various code sequences there 'save FP result'). Grep for load_heap_oop(), that gives all relevant entries. But that is outside the scope of this patch. To extend a little bit on that last comment: we introduced that xmm save/restore code when we still had RBs and WBs, and we needed a WB in front of C1's CAS-obj. That would mess with C1 keeping FP values in xmm registers across the then-WB. With the move to LRB, this was no longer necessary, and all remaining calls into the asm LRB routines are from the interpreter and thus only need to save/restore xmm0 (which could reasonably be folded into save/restore of other registers and save one add/sub each). The C1 LRB stub calls C1_MacroAssembler::save_live_registers_no_oop_map() which is already smart about which registers to save in context of C1. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From zgu at openjdk.java.net Wed Jan 27 13:08:40 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 27 Jan 2021 13:08:40 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 19:00:52 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 > # Error: assert(VM_Version::supports_sse2()) failed > > V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 > V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d > V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f > > This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. > > Additional testing: > - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` Probably, no processor that does not support sse2, but should we always use VM_version::supports_sse(x)? instead of UseSSE(x) ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From shade at openjdk.java.net Wed Jan 27 13:11:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 13:11:40 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: <-SCzTLsHYdhLesTYEry9DQ5-kqQhbymWMzUlFhzD_1A=.c1858ed0-1373-41b7-8bd5-a9ec94a4a38f@github.com> On Wed, 27 Jan 2021 13:06:04 GMT, Zhengyu Gu wrote: > Probably, no processor that does not support sse2, but should we always use VM_version::supports_sse(x)? instead of UseSSE(x) "Hotspot way" seems to be "check for VM_version::supports_sse* in assemblers" + "check for appropriate UseSSE level in machine-specific code before asking assemblers". This is what the patch does. ...or I misunderstand the question. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From coleenp at openjdk.java.net Wed Jan 27 14:10:39 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 27 Jan 2021 14:10:39 GMT Subject: RFR: 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 23:13:33 GMT, Ioi Lam wrote: > The "well-known classes" API in [systemDictionary.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/systemDictionary.hpp#L103) is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other. > > The proposed API follows the existing pattern of accessing known symbols/intrinsics in [vmSymbols.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmSymbols.hpp#L53) and [vmIntrinsics.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmIntrinsics.hpp#L108): > > #include "classfile/vmClasses.hpp" > #include "classfile/vmIntrinsics.hpp" > #include "classfile/vmSymbols.hpp" // NEW > > Symbol* s = vmSymbols::java_lang_Object(); > vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial; > Klass* k = vmClasses::Object_klass(); // NEW > > Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like `SystemDictionary::Object_klass()` to `vmClasses::Object_klass()`. That will be done in a subtask ([JDK-8260471](https://bugs.openjdk.java.net/browse/JDK-8260471) -- [preliminary webrev](http://cr.openjdk.java.net/~iklam/jdk17/8260471-decouple-vmClasses-and-SystemDictionary/)). > > Within this RFE, we temporarily subclass `SystemDictionary` from `vmClasses`, so `SystemDictionary::Object_klass()` will continue to work. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Why not consolidate vmClassMacros.hpp into vmClassID.hpp ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2246 From sjohanss at openjdk.java.net Wed Jan 27 14:34:40 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 27 Jan 2021 14:34:40 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v4] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 09:50:02 GMT, Thomas Schatzl wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> add GCLockerTracer::is_started() that makes the logic more clear > > Changes requested by tschatzl (Reviewer). Since @tschatzl requested changes yesterday I will wait for him to sponsor this. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 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 rkennke at openjdk.java.net Wed Jan 27 14:59:43 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 14:59:43 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 19:00:52 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 > # Error: assert(VM_Version::supports_sse2()) failed > > V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 > V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d > V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f > > This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. > > Additional testing: > - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` Looks good, but I have questions. src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 159: > 157: __ jcc(Assembler::zero, done); > 158: > 159: save_machine_state(masm, /* handle_gpr = */ true, /* handle_fp = */ true); IIRC, it is ensured in arraycopy prologue and epilogue that no FPU state is active (I can probably research why), and it may affect performance of tiny arraycopies (which are more frequent than I'd like). src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 3683: > 3681: __ movflt(Address(rsp, xmm_size * 1), xmm1); > 3682: __ movflt(Address(rsp, xmm_size * 0), xmm0); > 3683: } I am not sure that we should sneak in this shared-code change with what is otherwise a Shenandoah-change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 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 shade at openjdk.java.net Wed Jan 27 15:04:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 15:04:42 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> On Wed, 27 Jan 2021 14:54:24 GMT, Roman Kennke wrote: >> $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 >> # Error: assert(VM_Version::supports_sse2()) failed >> >> V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 >> V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d >> V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f >> >> This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. >> >> Additional testing: >> - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` > > src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 159: > >> 157: __ jcc(Assembler::zero, done); >> 158: >> 159: save_machine_state(masm, /* handle_gpr = */ true, /* handle_fp = */ true); > > IIRC, it is ensured in arraycopy prologue and epilogue that no FPU state is active (I can probably research why), and it may affect performance of tiny arraycopies (which are more frequent than I'd like). OK, I was going for the overkill of over-saving registers for interpreter code. But you are right, this might be problematic. We could do `/* handle_fp = */ false` here, so it would save only the generic registers? > src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 3683: > >> 3681: __ movflt(Address(rsp, xmm_size * 1), xmm1); >> 3682: __ movflt(Address(rsp, xmm_size * 0), xmm0); >> 3683: } > > I am not sure that we should sneak in this shared-code change with what is otherwise a Shenandoah-change. This is nmethod barrier handling part, and on x86_32, Shenandoah is the only user of this code. I can split it out, but it would still be Shenandoah-specific. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From rkennke at openjdk.java.net Wed Jan 27 15:04:43 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 15:04:43 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> References: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> Message-ID: On Wed, 27 Jan 2021 14:59:59 GMT, Aleksey Shipilev wrote: >> src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 159: >> >>> 157: __ jcc(Assembler::zero, done); >>> 158: >>> 159: save_machine_state(masm, /* handle_gpr = */ true, /* handle_fp = */ true); >> >> IIRC, it is ensured in arraycopy prologue and epilogue that no FPU state is active (I can probably research why), and it may affect performance of tiny arraycopies (which are more frequent than I'd like). > > OK, I was going for the overkill of over-saving registers for interpreter code. But you are right, this might be problematic. We could do `/* handle_fp = */ false` here, so it would save only the generic registers? Ah yes, Look in stubGenerator_x86_64, copy_bytes_forward() and copy_bytes_backward(), those generate fast copy routines that use FP registers. If those registers were live in the arraycopy code paths, those routines would trash it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From shade at openjdk.java.net Wed Jan 27 15:12:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 15:12:43 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> Message-ID: On Wed, 27 Jan 2021 15:02:12 GMT, Roman Kennke wrote: >> OK, I was going for the overkill of over-saving registers for interpreter code. But you are right, this might be problematic. We could do `/* handle_fp = */ false` here, so it would save only the generic registers? > > Ah yes, Look in stubGenerator_x86_64, copy_bytes_forward() and copy_bytes_backward(), those generate fast copy routines that use FP registers. If those registers were live in the arraycopy code paths, those routines would trash it. Yes, so that basically confirms the current behavior (that is, not saving FP) is already OK. I'll drop `handle_fp` to `false` then. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From shade at openjdk.java.net Wed Jan 27 15:17:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 15:17:45 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> References: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> Message-ID: On Wed, 27 Jan 2021 15:00:29 GMT, Aleksey Shipilev wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 3683: >> >>> 3681: __ movflt(Address(rsp, xmm_size * 1), xmm1); >>> 3682: __ movflt(Address(rsp, xmm_size * 0), xmm0); >>> 3683: } >> >> I am not sure that we should sneak in this shared-code change with what is otherwise a Shenandoah-change. > > This is nmethod barrier handling part, and on x86_32, Shenandoah is the only user of this code. I can split it out, but it would still be Shenandoah-specific. (...and I don't like to split it, because both hunks are needed to pass testing) ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From shade at openjdk.java.net Wed Jan 27 15:26:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 15:26:57 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: References: Message-ID: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 > # Error: assert(VM_Version::supports_sse2()) failed > > V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 > V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d > V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f > > This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. > > Additional testing: > - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Drop FP reg saves for arraycopy (current behavior) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1172/files - new: https://git.openjdk.java.net/jdk/pull/1172/files/b4db69e5..489c0db7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1172&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1172&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1172/head:pull/1172 PR: https://git.openjdk.java.net/jdk/pull/1172 From tschatzl at openjdk.java.net Wed Jan 27 15:31:43 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Jan 2021 15:31:43 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v4] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 11:03:15 GMT, Denghui Dong wrote: >> test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 116: >> >>> 114: ts[i] = new Thread(() -> { >>> 115: STALL_COUNT_SIGNAL.countDown(); >>> 116: for (int j = 0; j < LOOP; j++) { >> >> Since the test already uses WhiteBox, please use whitebox to trigger a gc instead of this dodgy method. > > Triggering a GC is not enough, I hope these threads could be stalled by the GC locker(call GCLocker::stall_until_clear) so that a correct assertion of the number of stall count could be added. > I think it could not be done by WhiteBox::youngGC/fullGC, please correct me if I'm wrong. I agree, although this is more a theoretical concern since it's not checked. Let's keep this for now as is though. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From tschatzl at openjdk.java.net Wed Jan 27 15:31:42 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Jan 2021 15:31:42 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v6] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 02:25:00 GMT, Denghui Dong wrote: >> GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. >> >> For the test purpose, I add two Whitebox methods to lock/unlock critical. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > improve descriptions Looks good. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Wed Jan 27 15:31:46 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 27 Jan 2021 15:31:46 GMT Subject: Integrated: 8259808: Add JFR event to detect GC locker stall In-Reply-To: References: Message-ID: <0jX_KfLI5gBLg8Ew1dRZnDcMpwWMB-xysSIoARaCE_w=.144f412d-4b8f-4dc6-bc64-b2d23607ec90@github.com> On Fri, 15 Jan 2021 02:42:20 GMT, Denghui Dong wrote: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. This pull request has now been integrated. Changeset: 311a0a91 Author: Denghui Dong Committer: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/311a0a91 Stats: 224 lines in 10 files changed: 224 ins; 0 del; 0 mod 8259808: Add JFR event to detect GC locker stall Reviewed-by: sjohanss, tschatzl, egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From rkennke at openjdk.java.net Wed Jan 27 15:38:50 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 15:38:50 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: References: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> Message-ID: On Wed, 27 Jan 2021 15:02:12 GMT, Roman Kennke wrote: >> OK, I was going for the overkill of over-saving registers for interpreter code. But you are right, this might be problematic. We could do `/* handle_fp = */ false` here, so it would save only the generic registers? > > Ah yes, Look in stubGenerator_x86_64, copy_bytes_forward() and copy_bytes_backward(), those generate fast copy routines that use FP registers. If those registers were live in the arraycopy code paths, those routines would trash it. Yes, save only generic regs there should be good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From rkennke at openjdk.java.net Wed Jan 27 15:38:49 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 15:38:49 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 15:26:57 GMT, Aleksey Shipilev wrote: >> $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 >> # Error: assert(VM_Version::supports_sse2()) failed >> >> V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 >> V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d >> V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f >> >> This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. >> >> Additional testing: >> - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Drop FP reg saves for arraycopy (current behavior) Looks good to me! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1172 From rkennke at openjdk.java.net Wed Jan 27 15:38:52 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 27 Jan 2021 15:38:52 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> References: <2L7t0PoVLBOxTLjkA5By5XbMkiEY1L2jaEDuEeZMWPQ=.cf32eda1-4163-4d64-abad-b8fc5ab37374@github.com> Message-ID: On Wed, 27 Jan 2021 15:00:29 GMT, Aleksey Shipilev wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 3683: >> >>> 3681: __ movflt(Address(rsp, xmm_size * 1), xmm1); >>> 3682: __ movflt(Address(rsp, xmm_size * 0), xmm0); >>> 3683: } >> >> I am not sure that we should sneak in this shared-code change with what is otherwise a Shenandoah-change. > > This is nmethod barrier handling part, and on x86_32, Shenandoah is the only user of this code. I can split it out, but it would still be Shenandoah-specific. Ah ok then. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From zgu at openjdk.java.net Wed Jan 27 16:02:43 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 27 Jan 2021 16:02:43 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 15:36:09 GMT, Roman Kennke wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop FP reg saves for arraycopy (current behavior) > > Looks good to me! Thanks! > > Probably, no processor that does not support sse2, but should we always use VM_version::supports_sse(x)? instead of UseSSE(x) > > "Hotspot way" seems to be "check for VM_version::supports_sse* in assemblers" + "check for appropriate UseSSE level in machine-specific code before asking assemblers". This is what the patch does. ...or I misunderstand the question. Okay, then. ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From zgu at openjdk.java.net Wed Jan 27 16:02:41 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 27 Jan 2021 16:02:41 GMT Subject: RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 15:26:57 GMT, Aleksey Shipilev wrote: >> $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 >> # Error: assert(VM_Version::supports_sse2()) failed >> >> V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 >> V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d >> V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f >> >> This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. >> >> Additional testing: >> - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` >> - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Drop FP reg saves for arraycopy (current behavior) Marked as reviewed by zgu (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From iveresov at openjdk.java.net Wed Jan 27 16:46:47 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Wed, 27 Jan 2021 16:46:47 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 18:13:20 GMT, Igor Veresov wrote: >> Looks better now. I would like to see result of performance testing before approving. > > I asked Eric to run the benchmarks. The results should be ready on Wednesday. The benchmarking is done. No regressions. There are mild improvements in startup benchmarks on the order of 1-5% (I suspect because of the compilation policy devirtualization). @dholmes-ora, do still plan to look at this? It's been a few weeks, I'd like to push this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From shade at openjdk.java.net Wed Jan 27 17:02:50 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 27 Jan 2021 17:02:50 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 16:43:28 GMT, Igor Veresov wrote: >> I asked Eric to run the benchmarks. The results should be ready on Wednesday. > > The benchmarking is done. No regressions. There are mild improvements in startup benchmarks on the order of 1-5% (I suspect because of the compilation policy devirtualization). > > @dholmes-ora, do still plan to look at this? It's been a few weeks, I'd like to push this. Please update from current master to get x86_32 built and tested in GH Actions. ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Wed Jan 27 17:09:48 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 27 Jan 2021 17:09:48 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: On Sun, 24 Jan 2021 03:53:00 GMT, Igor Veresov wrote: >> This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. >> >> I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. >> >> Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Address Vladimir's review comments I approve it based on performance results. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1985 From iveresov at openjdk.java.net Wed Jan 27 17:25:58 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Wed, 27 Jan 2021 17:25:58 GMT Subject: RFR: 8251462: Remove legacy compilation policy [v6] In-Reply-To: References: Message-ID: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Address Vladimir's review comments - Check legacy flags validity before deriving flag values for emulation mode. - Fix another s390 compilation failure - Fix s390 build - Fix copyright years - Remove legacy compilation policy. ------------- Changes: https://git.openjdk.java.net/jdk/pull/1985/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1985&range=05 Stats: 5318 lines in 98 files changed: 1519 ins; 2994 del; 805 mod Patch: https://git.openjdk.java.net/jdk/pull/1985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1985/head:pull/1985 PR: https://git.openjdk.java.net/jdk/pull/1985 From kvn at openjdk.java.net Wed Jan 27 17:26:50 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 27 Jan 2021 17:26:50 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 11:10:59 GMT, Nils Eliasson wrote: >>> @Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64. >> >> I think x64 has disabled OptimizeFill by default. I can reproduce this with -XX:+OptimizeFill. > > Please add -XX:+OptimizeFill to the regression test Yes, OptimizeFill is off after 8247307 changes in JDK 16. Add it to @run command (it is C2 flag so you need `Ignore*` flag): * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:+OptimizeFill ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 From iklam at openjdk.java.net Wed Jan 27 18:08:40 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 27 Jan 2021 18:08:40 GMT Subject: RFR: 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp In-Reply-To: References: Message-ID: <_vJMFtbvIXqUbLxIAy8aXHuqzOyWYErKPdnLzpTu01E=.54482bbd-76dc-442a-a95e-d8d72a2d04aa@github.com> On Wed, 27 Jan 2021 14:08:22 GMT, Coleen Phillimore wrote: > Why not consolidate vmClassMacros.hpp into vmClassID.hpp ? ciEnv.hpp uses the VM_CLASSES_DO macro, but does not use anything inside vmClassID.hpp. As a result, vmClassMacros.hpp is included by 468 .o files, but vmClassID.hpp is included only by 318 files. ------------- PR: https://git.openjdk.java.net/jdk/pull/2246 From coleenp at openjdk.java.net Wed Jan 27 19:03:44 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 27 Jan 2021 19:03:44 GMT Subject: RFR: 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 23:13:33 GMT, Ioi Lam wrote: > The "well-known classes" API in [systemDictionary.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/systemDictionary.hpp#L103) is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other. > > The proposed API follows the existing pattern of accessing known symbols/intrinsics in [vmSymbols.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmSymbols.hpp#L53) and [vmIntrinsics.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmIntrinsics.hpp#L108): > > #include "classfile/vmClasses.hpp" > #include "classfile/vmIntrinsics.hpp" > #include "classfile/vmSymbols.hpp" // NEW > > Symbol* s = vmSymbols::java_lang_Object(); > vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial; > Klass* k = vmClasses::Object_klass(); // NEW > > Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like `SystemDictionary::Object_klass()` to `vmClasses::Object_klass()`. That will be done in a subtask ([JDK-8260471](https://bugs.openjdk.java.net/browse/JDK-8260471) -- [preliminary webrev](http://cr.openjdk.java.net/~iklam/jdk17/8260471-decouple-vmClasses-and-SystemDictionary/)). > > Within this RFE, we temporarily subclass `SystemDictionary` from `vmClasses`, so `SystemDictionary::Object_klass()` will continue to work. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ok! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2246 From honguye at microsoft.com Thu Jan 28 00:51:48 2021 From: honguye at microsoft.com (Nhat Nguyen) Date: Thu, 28 Jan 2021 00:51:48 +0000 Subject: Follow up on [JDK-7018422] - JavaAgent code always interpreted during initialization phase In-Reply-To: References: Message-ID: Hi, I'm writing this email to follow up on JDK-7018422 [1] on jdk8u, where the JavaAgent code is always interpreted during the initialization phase on jdk8. For background, one of our tools is currently making use of a JavaAgent whose performance is important. As part of a performance investigation, I discovered that the CompilerBroker is not initialized by the time the premain method runs, therefore all compilation requests for the JavaAgent are discarded. Fortunately, I found JDK-7018422 which describes the exact issue that we are experiencing. However, the ticket was closed as "Not an issue" because the initialization order is changed with the introduction of the module system. So I would like to ask the mailing list for opinions on whether a fix for this issue can be considered for jdk8u. I have also attached a prototype fix [2] and would appreciate any suggestions and comments as well. [1]: https://bugs.openjdk.java.net/browse/JDK-7018422 [2]: --- hotspot/src/share/vm/runtime/thread.cpp | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/hotspot/src/share/vm/runtime/thread.cpp b/hotspot/src/share/vm/runtime/thread.cpp index 330593acb3..3918f989cc 100644 --- a/hotspot/src/share/vm/runtime/thread.cpp +++ b/hotspot/src/share/vm/runtime/thread.cpp @@ -3634,11 +3634,6 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { create_vm_init_libraries(); } - // Notify JVMTI agents that VM initialization is complete - nop if no agents. - JvmtiExport::post_vm_initialized(); - - JFR_ONLY(Jfr::on_vm_start();) - if (CleanChunkPoolAsync) { Chunk::start_chunk_pool_cleaner_task(); } @@ -3648,6 +3643,11 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { CompileBroker::compilation_init(); #endif + // Notify JVMTI agents that VM initialization is complete - nop if no agents. + JvmtiExport::post_vm_initialized(); + + JFR_ONLY(Jfr::on_vm_start();) + if (EnableInvokeDynamic) { // Pre-initialize some JSR292 core classes to avoid deadlock during class loading. // It is done after compilers are initialized, because otherwise compilations of -- From whuang at openjdk.java.net Thu Jan 28 01:34:12 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 28 Jan 2021 01:34:12 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v7] In-Reply-To: References: Message-ID: <9vpuiDLlNDANMFx3E5bOfyjPsKMQD4yRmV7WcE6JVTI=.acf2c8e9-45a5-4096-a83c-92d7ff856aa5@github.com> > The reason is : > > BasicType t = store->as_Mem()->memory_type(); > const char* fill_name; > if (msg == NULL && > StubRoutines::select_fill_function(t, false, fill_name) == NULL) { > msg = "unsupported store"; > msg_node = store; > } > > If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. > > I add a new case here to avoid mistake: > case T_NARROWOOP: > case T_NARROWKLASS: > case T_ADDRESS: > + case T_VOID: > // Currently unsupported > return NULL; Wang Huang has updated the pull request incrementally with one additional commit since the last revision: add -XX:+OptimizeFill ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/132/files - new: https://git.openjdk.java.net/jdk16/pull/132/files/b9f1a249..cf54002d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/132.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132 PR: https://git.openjdk.java.net/jdk16/pull/132 From iklam at openjdk.java.net Thu Jan 28 01:40:04 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 28 Jan 2021 01:40:04 GMT Subject: RFR: 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp [v2] In-Reply-To: References: Message-ID: <9HW1nwx7o8IvP7alO0PT3o_Z1Ae2YhtPfUQwrWCIY9E=.794d26df-5f64-4029-814b-0e4256338738@github.com> > The "well-known classes" API in [systemDictionary.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/systemDictionary.hpp#L103) is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other. > > The proposed API follows the existing pattern of accessing known symbols/intrinsics in [vmSymbols.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmSymbols.hpp#L53) and [vmIntrinsics.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmIntrinsics.hpp#L108): > > #include "classfile/vmClasses.hpp" > #include "classfile/vmIntrinsics.hpp" > #include "classfile/vmSymbols.hpp" // NEW > > Symbol* s = vmSymbols::java_lang_Object(); > vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial; > Klass* k = vmClasses::Object_klass(); // NEW > > Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like `SystemDictionary::Object_klass()` to `vmClasses::Object_klass()`. That will be done in a subtask ([JDK-8260471](https://bugs.openjdk.java.net/browse/JDK-8260471) -- [preliminary webrev](http://cr.openjdk.java.net/~iklam/jdk17/8260471-decouple-vmClasses-and-SystemDictionary/)). > > Within this RFE, we temporarily subclass `SystemDictionary` from `vmClasses`, so `SystemDictionary::Object_klass()` will continue to work. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam 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 five additional commits since the last revision: - Merge branch 'master' into 8260467-move-well-known-klasses-out-of-system-dictionary - Merge branch 'master' into 8260467-move-well-known-klasses-out-of-system-dictionary - added missing vmClasses.hpp - Renamed VMClasses to vmClasses to be consistent with vmSymbols - Move well_known_classes out of SystemDictionary ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2246/files - new: https://git.openjdk.java.net/jdk/pull/2246/files/3d380398..e585ddca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2246&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2246&range=00-01 Stats: 4742 lines in 109 files changed: 3821 ins; 516 del; 405 mod Patch: https://git.openjdk.java.net/jdk/pull/2246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2246/head:pull/2246 PR: https://git.openjdk.java.net/jdk/pull/2246 From dongbo at openjdk.java.net Thu Jan 28 01:41:48 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Thu, 28 Jan 2021 01:41:48 GMT Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad Message-ID: As discussed in [1], all NEON instructions should be moved from `aarch64.ad` to `aarch64_neon.ad`. In the first commit [2] of this PR, the NEON instructions are deleted from `aarch64.ad` and appended to `aarch64_neon.ad`. I compared the generated code in `aarch64_neon.ad` with original code in `aarch64.ad`, no suspicious differences found. The last two commits just simply move code around in `aarch64_neon.ad` to put related instructions together, i.e. `LoadStore` [3], `Reduction` [4]. This also supports vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`, fixes few typos, e.g. `vor8B`, `vsrla4S_imm`. [1] https://github.com/openjdk/jdk/pull/1215#issuecomment-728186803 [2] https://github.com/dgbo/jdk/commit/40cbe99e647cdf93712edf8f77ab3b5b30ea0a95 [3] https://github.com/dgbo/jdk/commit/695fb8f8ef009b733a8f804e791347f4bfe2572e [4] https://github.com/dgbo/jdk/commit/e0c38aa9aaa6af9925a3821328384b1e2b2c2070 ------------- Commit messages: - put all VReduction together - put all VLoadStore together - 8258953: AArch64: move NEON instructions to aarch64_neon.ad Changes: https://git.openjdk.java.net/jdk/pull/2273/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2273&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258953 Stats: 5703 lines in 3 files changed: 3241 ins; 2442 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/2273.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2273/head:pull/2273 PR: https://git.openjdk.java.net/jdk/pull/2273 From kvn at openjdk.java.net Thu Jan 28 01:59:47 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 28 Jan 2021 01:59:47 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v7] In-Reply-To: <9vpuiDLlNDANMFx3E5bOfyjPsKMQD4yRmV7WcE6JVTI=.acf2c8e9-45a5-4096-a83c-92d7ff856aa5@github.com> References: <9vpuiDLlNDANMFx3E5bOfyjPsKMQD4yRmV7WcE6JVTI=.acf2c8e9-45a5-4096-a83c-92d7ff856aa5@github.com> Message-ID: On Thu, 28 Jan 2021 01:34:12 GMT, Wang Huang wrote: >> The reason is : >> >> BasicType t = store->as_Mem()->memory_type(); >> const char* fill_name; >> if (msg == NULL && >> StubRoutines::select_fill_function(t, false, fill_name) == NULL) { >> msg = "unsupported store"; >> msg_node = store; >> } >> >> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. >> >> I add a new case here to avoid mistake: >> case T_NARROWOOP: >> case T_NARROWKLASS: >> case T_ADDRESS: >> + case T_VOID: >> // Currently unsupported >> return NULL; > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > add -XX:+OptimizeFill test/hotspot/jtreg/compiler/vectorapi/TestLoopStoreVector.java line 35: > 33: * @modules jdk.incubator.vector > 34: * > 35: * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:+OptimizeFill You forgot test name ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 From serguei.spitsyn at oracle.com Thu Jan 28 02:01:09 2021 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Thu, 28 Jan 2021 02:01:09 +0000 Subject: Follow up on [JDK-7018422] - JavaAgent code always interpreted during initialization phase In-Reply-To: References: Message-ID: <5E4E7B96-1B85-47E0-A4A1-C51E149BA5FB@oracle.com> Hi Nhat, What kind of work besides simple initialization does your Java agent's premain method? Is it possible to postpone some part of it until the VM is fully initialized? Also, why do you think the premain method is going to be compiled after the Jit Compiler initialization order is changed? Thanks, Serguei ?On 1/27/21, 16:52, "hotspot-dev on behalf of Nhat Nguyen" wrote: Hi, I'm writing this email to follow up on JDK-7018422 [1] on jdk8u, where the JavaAgent code is always interpreted during the initialization phase on jdk8. For background, one of our tools is currently making use of a JavaAgent whose performance is important. As part of a performance investigation, I discovered that the CompilerBroker is not initialized by the time the premain method runs, therefore all compilation requests for the JavaAgent are discarded. Fortunately, I found JDK-7018422 which describes the exact issue that we are experiencing. However, the ticket was closed as "Not an issue" because the initialization order is changed with the introduction of the module system. So I would like to ask the mailing list for opinions on whether a fix for this issue can be considered for jdk8u. I have also attached a prototype fix [2] and would appreciate any suggestions and comments as well. [1]: https://bugs.openjdk.java.net/browse/JDK-7018422 [2]: --- hotspot/src/share/vm/runtime/thread.cpp | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/hotspot/src/share/vm/runtime/thread.cpp b/hotspot/src/share/vm/runtime/thread.cpp index 330593acb3..3918f989cc 100644 --- a/hotspot/src/share/vm/runtime/thread.cpp +++ b/hotspot/src/share/vm/runtime/thread.cpp @@ -3634,11 +3634,6 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { create_vm_init_libraries(); } - // Notify JVMTI agents that VM initialization is complete - nop if no agents. - JvmtiExport::post_vm_initialized(); - - JFR_ONLY(Jfr::on_vm_start();) - if (CleanChunkPoolAsync) { Chunk::start_chunk_pool_cleaner_task(); } @@ -3648,6 +3643,11 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { CompileBroker::compilation_init(); #endif + // Notify JVMTI agents that VM initialization is complete - nop if no agents. + JvmtiExport::post_vm_initialized(); + + JFR_ONLY(Jfr::on_vm_start();) + if (EnableInvokeDynamic) { // Pre-initialize some JSR292 core classes to avoid deadlock during class loading. // It is done after compilers are initialized, because otherwise compilations of -- From whuang at openjdk.java.net Thu Jan 28 02:24:06 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 28 Jan 2021 02:24:06 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v8] In-Reply-To: References: Message-ID: > The reason is : > > BasicType t = store->as_Mem()->memory_type(); > const char* fill_name; > if (msg == NULL && > StubRoutines::select_fill_function(t, false, fill_name) == NULL) { > msg = "unsupported store"; > msg_node = store; > } > > If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. > > I add a new case here to avoid mistake: > case T_NARROWOOP: > case T_NARROWKLASS: > case T_ADDRESS: > + case T_VOID: > // Currently unsupported > return NULL; Wang Huang has updated the pull request incrementally with one additional commit since the last revision: add missing summary and test name ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/132/files - new: https://git.openjdk.java.net/jdk16/pull/132/files/cf54002d..8e1c90d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=132&range=06-07 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/132.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132 PR: https://git.openjdk.java.net/jdk16/pull/132 From kvn at openjdk.java.net Thu Jan 28 02:41:42 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 28 Jan 2021 02:41:42 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v8] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 02:24:06 GMT, Wang Huang wrote: >> The reason is : >> >> BasicType t = store->as_Mem()->memory_type(); >> const char* fill_name; >> if (msg == NULL && >> StubRoutines::select_fill_function(t, false, fill_name) == NULL) { >> msg = "unsupported store"; >> msg_node = store; >> } >> >> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. >> >> I add a new case here to avoid mistake: >> case T_NARROWOOP: >> case T_NARROWKLASS: >> case T_ADDRESS: >> + case T_VOID: >> // Currently unsupported >> return NULL; > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > add missing summary and test name Good. Wait an other day for other people to look. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/132 From iignatyev at openjdk.java.net Thu Jan 28 02:48:46 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 28 Jan 2021 02:48:46 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v8] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 02:24:06 GMT, Wang Huang wrote: >> The reason is : >> >> BasicType t = store->as_Mem()->memory_type(); >> const char* fill_name; >> if (msg == NULL && >> StubRoutines::select_fill_function(t, false, fill_name) == NULL) { >> msg = "unsupported store"; >> msg_node = store; >> } >> >> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. >> >> I add a new case here to avoid mistake: >> case T_NARROWOOP: >> case T_NARROWKLASS: >> case T_ADDRESS: >> + case T_VOID: >> // Currently unsupported >> return NULL; > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > add missing summary and test name LGTM ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/132 From iklam at openjdk.java.net Thu Jan 28 04:26:43 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 28 Jan 2021 04:26:43 GMT Subject: RFR: 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp [v2] In-Reply-To: References: Message-ID: <0UkTJp4YuLa7ltOwpfnouo8Y4iaymmRjAvx2wK8xDR8=.6d66f69a-556f-419d-91f8-917bc56af97e@github.com> On Wed, 27 Jan 2021 19:01:18 GMT, Coleen Phillimore wrote: >> Ioi Lam 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 five additional commits since the last revision: >> >> - Merge branch 'master' into 8260467-move-well-known-klasses-out-of-system-dictionary >> - Merge branch 'master' into 8260467-move-well-known-klasses-out-of-system-dictionary >> - added missing vmClasses.hpp >> - Renamed VMClasses to vmClasses to be consistent with vmSymbols >> - Move well_known_classes out of SystemDictionary > > Ok! Thanks @coleenp and @dholmes-ora for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/2246 From iklam at openjdk.java.net Thu Jan 28 04:26:44 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 28 Jan 2021 04:26:44 GMT Subject: Integrated: 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 23:13:33 GMT, Ioi Lam wrote: > The "well-known classes" API in [systemDictionary.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/systemDictionary.hpp#L103) is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other. > > The proposed API follows the existing pattern of accessing known symbols/intrinsics in [vmSymbols.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmSymbols.hpp#L53) and [vmIntrinsics.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmIntrinsics.hpp#L108): > > #include "classfile/vmClasses.hpp" > #include "classfile/vmIntrinsics.hpp" > #include "classfile/vmSymbols.hpp" // NEW > > Symbol* s = vmSymbols::java_lang_Object(); > vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial; > Klass* k = vmClasses::Object_klass(); // NEW > > Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like `SystemDictionary::Object_klass()` to `vmClasses::Object_klass()`. That will be done in a subtask ([JDK-8260471](https://bugs.openjdk.java.net/browse/JDK-8260471) -- [preliminary webrev](http://cr.openjdk.java.net/~iklam/jdk17/8260471-decouple-vmClasses-and-SystemDictionary/)). > > Within this RFE, we temporarily subclass `SystemDictionary` from `vmClasses`, so `SystemDictionary::Object_klass()` will continue to work. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. This pull request has now been integrated. Changeset: 396a496f Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/396a496f Stats: 1206 lines in 35 files changed: 634 ins; 455 del; 117 mod 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/2246 From david.holmes at oracle.com Thu Jan 28 04:37:13 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Jan 2021 14:37:13 +1000 Subject: Follow up on [JDK-7018422] - JavaAgent code always interpreted during initialization phase In-Reply-To: References: Message-ID: <26ea45a4-bf19-6a5e-c885-5b628e6aebfd@oracle.com> Hi, On 28/01/2021 10:51 am, Nhat Nguyen wrote: > Hi, > > I'm writing this email to follow up on JDK-7018422 [1] on jdk8u, where the JavaAgent code > is always interpreted during the initialization phase on jdk8. Just FYI for changes to 8u you need to raise the issue on jdk8u-dev at openjdk.java.net. > For background, one of our tools is currently making use of a JavaAgent whose performance > is important. As part of a performance investigation, I discovered that the CompilerBroker is > not initialized by the time the premain method runs, therefore all compilation requests for > the JavaAgent are discarded. > > Fortunately, I found JDK-7018422 which describes the exact issue that we are experiencing. > However, the ticket was closed as "Not an issue" because the initialization order is changed > with the introduction of the module system. > > So I would like to ask the mailing list for opinions on whether a fix for this issue can be > considered for jdk8u. I have also attached a prototype fix [2] and would appreciate any > suggestions and comments as well. You have to be extremely careful changing the initialization order as there are many hidden inter-dependencies. And as Serguei stated, that change may potentially allow JIT'ing to be possible, but that doesn't mean it will actually occur. Cheers, David ----- > > [1]: https://bugs.openjdk.java.net/browse/JDK-7018422 > [2]: > > --- > hotspot/src/share/vm/runtime/thread.cpp | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/hotspot/src/share/vm/runtime/thread.cpp b/hotspot/src/share/vm/runtime/thread.cpp > index 330593acb3..3918f989cc 100644 > --- a/hotspot/src/share/vm/runtime/thread.cpp > +++ b/hotspot/src/share/vm/runtime/thread.cpp > @@ -3634,11 +3634,6 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { > create_vm_init_libraries(); > } > > - // Notify JVMTI agents that VM initialization is complete - nop if no agents. > - JvmtiExport::post_vm_initialized(); > - > - JFR_ONLY(Jfr::on_vm_start();) > - > if (CleanChunkPoolAsync) { > Chunk::start_chunk_pool_cleaner_task(); > } > @@ -3648,6 +3643,11 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { > CompileBroker::compilation_init(); > #endif > > + // Notify JVMTI agents that VM initialization is complete - nop if no agents. > + JvmtiExport::post_vm_initialized(); > + > + JFR_ONLY(Jfr::on_vm_start();) > + > if (EnableInvokeDynamic) { > // Pre-initialize some JSR292 core classes to avoid deadlock during class loading. > // It is done after compilers are initialized, because otherwise compilations of > -- > From david.holmes at oracle.com Thu Jan 28 04:44:13 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Jan 2021 14:44:13 +1000 Subject: RFR: 8251462: Remove legacy compilation policy [v5] In-Reply-To: References: Message-ID: <7a846651-9ffe-eacd-af93-91f2e545b059@oracle.com> Hi Igor, On 28/01/2021 2:46 am, Igor Veresov wrote: > On Mon, 25 Jan 2021 18:13:20 GMT, Igor Veresov wrote: > >>> Looks better now. I would like to see result of performance testing before approving. >> >> I asked Eric to run the benchmarks. The results should be ready on Wednesday. > > The benchmarking is done. No regressions. There are mild improvements in startup benchmarks on the order of 1-5% (I suspect because of the compilation policy devirtualization). > > @dholmes-ora, do still plan to look at this? It's been a few weeks, I'd like to push this. No I only perused this and made a couple of comments, now addressed. I'll leave a full review to others. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1985 > From ngasson at openjdk.java.net Thu Jan 28 08:31:46 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 28 Jan 2021 08:31:46 GMT Subject: RFR: 8260355: AArch64: deoptimization stub should save vector registers Message-ID: <5PbujtOhWB7uqNXu5vRMwYGNMNU78aLAkGpDLWUnQKM=.9d2206fe-9c15-424c-b08e-80eab468df2a@github.com> This is an AArch64 port of the fix for JDK-8256056 "Deoptimization stub doesn't save vector registers on x86". The problem is that a vector produced by the Vector API may be stored in a register when the deopt blob is called. Because the deopt blob only stores the lower half of vector registers, the full vector object cannot be rematerialized during deoptimization. So the following will crash on AArch64 with current JDK: make test TEST="jdk/incubator/vector" \ JTREG="VM_OPTIONS=-XX:+DeoptimizeALot -XX:DeoptimizeALotInterval=0" The fix is to store the full vector registers by passing save_vectors=true to save_live_registers() in the deopt blob. Because save_live_registers() places the integer registers above the floating registers in the stack frame, RegisterSaver::r0_offset_in_bytes() needs to calculate the SP offset based on whether full vectors were saved, and whether those vectors were NEON or SVE, rather than using a static offset as it does currently. The change to VectorSupport::allocate_vector_payload_helper() is required because we only store the lowest VMReg slot in the oop map. However unlike x86 the vector registers are always saved in a contiguous region of memory, so we can calculate the address of each vector element as an offset from the address of the first slot. X86 handles this in RegisterMap::pd_location() but that won't work on AArch64 because with SVE there isn't a unique VMReg corresponding to each four-byte physical slot in the vector (there are always exactly eight logical VMRegs regardless of the actual vector length). Tested hotspot_all_no_apps and jdk_core. ------------- Commit messages: - 8260355: AArch64: deoptimization stub should save vector registers Changes: https://git.openjdk.java.net/jdk/pull/2279/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2279&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260355 Stats: 88 lines in 2 files changed: 42 ins; 23 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/2279.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2279/head:pull/2279 PR: https://git.openjdk.java.net/jdk/pull/2279 From aph at redhat.com Thu Jan 28 09:48:32 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Jan 2021 09:48:32 +0000 Subject: RFR: 8260355: AArch64: deoptimization stub should save vector registers In-Reply-To: <5PbujtOhWB7uqNXu5vRMwYGNMNU78aLAkGpDLWUnQKM=.9d2206fe-9c15-424c-b08e-80eab468df2a@github.com> References: <5PbujtOhWB7uqNXu5vRMwYGNMNU78aLAkGpDLWUnQKM=.9d2206fe-9c15-424c-b08e-80eab468df2a@github.com> Message-ID: <817f592f-7933-241d-3e7b-50874879005b@redhat.com> On 1/28/21 8:31 AM, Nick Gasson wrote: > The fix is to store the full vector registers by passing > save_vectors=true to save_live_registers() in the deopt blob. Because > save_live_registers() places the integer registers above the floating > registers in the stack frame, RegisterSaver::r0_offset_in_bytes() needs > to calculate the SP offset based on whether full vectors were saved, and > whether those vectors were NEON or SVE, rather than using a static > offset as it does currently. It seems to me that save_vectors is only set here: bool save_vectors = COMPILER2_OR_JVMCI != 0; which means that save_vectors is a static property of a build, not something that can vary. Therefore, there is nothing to be gained by passing save_vectors around. Could we simply have a save_vectors_on_deopt() function? Also, I'm wondering how much all of this complexity gains us for the sake of configurations without C2. I'd be very tempted to just leave a hole in the stack for these systems. How much stack would that cost? -- 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 sgehwolf at redhat.com Thu Jan 28 10:05:06 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 28 Jan 2021 11:05:06 +0100 Subject: Follow up on [JDK-7018422] - JavaAgent code always interpreted during initialization phase In-Reply-To: <26ea45a4-bf19-6a5e-c885-5b628e6aebfd@oracle.com> References: <26ea45a4-bf19-6a5e-c885-5b628e6aebfd@oracle.com> Message-ID: <4e6a3167c955d66ef732e46c7fcda51566d19359.camel@redhat.com> Hi, On Thu, 2021-01-28 at 14:37 +1000, David Holmes wrote: > Hi, > > On 28/01/2021 10:51 am, Nhat Nguyen wrote: > > Hi, > > > > I'm writing this email to follow up on JDK-7018422 [1] on jdk8u, where the JavaAgent code > > is always interpreted during the initialization phase on jdk8. > > Just FYI for changes to 8u you need to raise the issue on > jdk8u-dev at openjdk.java.net. Adding jdk8u-dev to cc. > > > For background, one of our tools is currently making use of a JavaAgent whose performance > > is important. As part of a performance investigation, I discovered that the CompilerBroker is > > not initialized by the time the premain method runs, therefore all compilation requests for > > the JavaAgent are discarded. > > > > Fortunately, I found JDK-7018422 which describes the exact issue that we are experiencing. > > However, the ticket was closed as "Not an issue" because the initialization order is changed > > with the introduction of the module system. > > > > So I would like to ask the mailing list for opinions on whether a fix for this issue can be > > considered for jdk8u. I have also attached a prototype fix [2] and would appreciate any > > suggestions and comments as well. > > You have to be extremely careful changing the initialization order as > there are many hidden inter-dependencies. Yes, and we've been bitten by this before[i]. There is a significant risk involved changing initialization order in stable jdk8u. The reasons given here don't strike me as a good enough reason to accept such a patch. YMMV. Andrew Haley, thoughts? Thanks, Severin [i] https://bugs.openjdk.java.net/browse/JDK-8249158 and https://bugs.openjdk.java.net/browse/JDK-8233197 > And as Serguei stated, that change may potentially allow JIT'ing to be > possible, but that doesn't mean it will actually occur. > > Cheers, > David > ----- > > > > > [1]: https://bugs.openjdk.java.net/browse/JDK-7018422 > > [2]: > > > > --- > > ? hotspot/src/share/vm/runtime/thread.cpp | 10 +++++----- > > ? 1 file changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/hotspot/src/share/vm/runtime/thread.cpp > > b/hotspot/src/share/vm/runtime/thread.cpp > > index 330593acb3..3918f989cc 100644 > > --- a/hotspot/src/share/vm/runtime/thread.cpp > > +++ b/hotspot/src/share/vm/runtime/thread.cpp > > @@ -3634,11 +3634,6 @@ jint Threads::create_vm(JavaVMInitArgs* > > args, bool* canTryAgain) { > > ????? create_vm_init_libraries(); > > ??? } > > ? > > -? // Notify JVMTI agents that VM initialization is complete - nop > > if no agents. > > -? JvmtiExport::post_vm_initialized(); > > - > > -? JFR_ONLY(Jfr::on_vm_start();) > > - > > ??? if (CleanChunkPoolAsync) { > > ????? Chunk::start_chunk_pool_cleaner_task(); > > ??? } > > @@ -3648,6 +3643,11 @@ jint Threads::create_vm(JavaVMInitArgs* > > args, bool* canTryAgain) { > > ??? CompileBroker::compilation_init(); > > ? #endif > > ? > > +? // Notify JVMTI agents that VM initialization is complete - nop > > if no agents. > > +? JvmtiExport::post_vm_initialized(); > > + > > +? JFR_ONLY(Jfr::on_vm_start();) > > + > > ??? if (EnableInvokeDynamic) { > > ????? // Pre-initialize some JSR292 core classes to avoid deadlock > > during class loading. > > ????? // It is done after compilers are initialized, because > > otherwise compilations of > > -- > > > From shade at openjdk.java.net Thu Jan 28 10:27:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Jan 2021 10:27:40 GMT Subject: Integrated: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 19:00:52 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC" > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311 > # Error: assert(VM_Version::supports_sse2()) failed > > V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168 > V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d > V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f > > This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times. > > Additional testing: > - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0` > - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1` This pull request has now been integrated. Changeset: a97aedff Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/a97aedff Stats: 118 lines in 2 files changed: 69 ins; 13 del; 36 mod 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code Reviewed-by: rkennke, zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/1172 From vlivanov at openjdk.java.net Thu Jan 28 10:29:41 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 28 Jan 2021 10:29:41 GMT Subject: RFR: 8260355: AArch64: deoptimization stub should save vector registers In-Reply-To: <5PbujtOhWB7uqNXu5vRMwYGNMNU78aLAkGpDLWUnQKM=.9d2206fe-9c15-424c-b08e-80eab468df2a@github.com> References: <5PbujtOhWB7uqNXu5vRMwYGNMNU78aLAkGpDLWUnQKM=.9d2206fe-9c15-424c-b08e-80eab468df2a@github.com> Message-ID: On Thu, 28 Jan 2021 08:27:22 GMT, Nick Gasson wrote: > This is an AArch64 port of the fix for JDK-8256056 "Deoptimization stub > doesn't save vector registers on x86". The problem is that a vector > produced by the Vector API may be stored in a register when the deopt > blob is called. Because the deopt blob only stores the lower half of > vector registers, the full vector object cannot be rematerialized during > deoptimization. So the following will crash on AArch64 with current JDK: > > make test TEST="jdk/incubator/vector" \ > JTREG="VM_OPTIONS=-XX:+DeoptimizeALot -XX:DeoptimizeALotInterval=0" > > The fix is to store the full vector registers by passing > save_vectors=true to save_live_registers() in the deopt blob. Because > save_live_registers() places the integer registers above the floating > registers in the stack frame, RegisterSaver::r0_offset_in_bytes() needs > to calculate the SP offset based on whether full vectors were saved, and > whether those vectors were NEON or SVE, rather than using a static > offset as it does currently. > > The change to VectorSupport::allocate_vector_payload_helper() is > required because we only store the lowest VMReg slot in the oop map. > However unlike x86 the vector registers are always saved in a contiguous > region of memory, so we can calculate the address of each vector element > as an offset from the address of the first slot. X86 handles this in > RegisterMap::pd_location() but that won't work on AArch64 because with > SVE there isn't a unique VMReg corresponding to each four-byte physical > slot in the vector (there are always exactly eight logical VMRegs > regardless of the actual vector length). > > Tested hotspot_all_no_apps and jdk_core. src/hotspot/share/prims/vectorSupport.cpp line 138: > 136: > 137: for (int i = 0; i < num_elem; i++) { > 138: bool contiguous = X86_ONLY(false) NOT_X86(true); I don't like this change. It's not x86-specific, but SVE-specific code. What is broken here is `VMReg::next()` doesn't work properly for `VecA` registers. And, as a result, it makes `RegisterMap::location(VMReg)` unusable as well. So, a proper fix should address that instead. If there's no way to save `VMReg::next()` and `RegisterMap::location(VMReg)`, then new cross-platform API should be introduced and `VectorSupport::allocate_vector_payload_helper()` migrated to it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2279 From njian at openjdk.java.net Thu Jan 28 10:40:46 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Thu, 28 Jan 2021 10:40:46 GMT Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 01:37:33 GMT, Dong Bo wrote: > As discussed in [1], all NEON instructions should be moved from `aarch64.ad` to `aarch64_neon.ad`. > > In the first commit [2] of this PR, the NEON instructions are deleted from `aarch64.ad` and appended to `aarch64_neon.ad`. > I compared the generated code in `aarch64_neon.ad` with original code in `aarch64.ad`, no suspicious differences found. > The last two commits just simply move code around in `aarch64_neon.ad` to put related instructions together, i.e. `LoadStore` [3], `Reduction` [4]. > > This also supports vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`, fixes few typos, e.g. `vor8B`, `vsrla4S_imm`. > > [1] https://github.com/openjdk/jdk/pull/1215#issuecomment-728186803 > [2] https://github.com/dgbo/jdk/commit/40cbe99e647cdf93712edf8f77ab3b5b30ea0a95 > [3] https://github.com/dgbo/jdk/commit/695fb8f8ef009b733a8f804e791347f4bfe2572e > [4] https://github.com/dgbo/jdk/commit/e0c38aa9aaa6af9925a3821328384b1e2b2c2070 I managed to sort all the instructs and compare them with and without the patch. They are general the same except for some trailing whitespaces and typos you mentioned. src/hotspot/cpu/aarch64/aarch64_neon.ad line 776: > 774: as_FloatRegister($vsrc$$reg), 0, 1); > 775: __ fadds(as_FloatRegister($dst$$reg), > 776: as_FloatRegister($dst$$reg), as_FloatRegister($tmp$$reg)); Remove trailing whitespace. src/hotspot/cpu/aarch64/aarch64_neon.ad line 880: > 878: as_FloatRegister($vsrc$$reg), 0, 1); > 879: __ faddd(as_FloatRegister($dst$$reg), > 880: as_FloatRegister($dst$$reg), as_FloatRegister($tmp$$reg)); Trailing whitespace. src/hotspot/cpu/aarch64/aarch64_neon.ad line 800: > 798: as_FloatRegister($vsrc$$reg), 0, 1); > 799: __ fadds(as_FloatRegister($dst$$reg), > 800: as_FloatRegister($dst$$reg), as_FloatRegister($tmp$$reg)); trailing whitespace src/hotspot/cpu/aarch64/aarch64_neon.ad line 4936: > 4934: format %{ "fsqrt $dst, $src\t# vector (2D)" %} > 4935: ins_encode %{ > 4936: __ fsqrt(as_FloatRegister($dst$$reg), __ T2D, trailing whitespace src/hotspot/cpu/aarch64/aarch64_neon.ad line 900: > 898: as_FloatRegister($vsrc$$reg), 0, 1); > 899: __ fmuld(as_FloatRegister($dst$$reg), > 900: as_FloatRegister($dst$$reg), as_FloatRegister($tmp$$reg)); trailing whitespace? src/hotspot/cpu/aarch64/aarch64_neon.ad line 5022: > 5020: match(Set dst (OrV src1 src2)); > 5021: ins_cost(INSN_COST); > 5022: format %{ "orr $dst,$src1,$src2\t# vector (8B)" %} Good catch for this typo! src/hotspot/cpu/aarch64/aarch64_neon.ad line 5937: > 5935: as_FloatRegister($src$$reg)); > 5936: } else { > 5937: __ usra(as_FloatRegister($dst$$reg), __ T4H, I see you have fixed this typo, from ushr to usra. I presume original version generates wrong code and produces wrong results for specific case? If so, do you think it deserves a separate fix, e.g. for jdk16? ------------- PR: https://git.openjdk.java.net/jdk/pull/2273 From aph at redhat.com Thu Jan 28 11:14:53 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Jan 2021 11:14:53 +0000 Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad In-Reply-To: References: Message-ID: <6f38f44f-4a37-6ead-2093-1072a8b349a8@redhat.com> On 1/28/21 10:40 AM, Ningsheng Jian wrote: > I see you have fixed this typo, from ushr to usra. I presume original version generates wrong code and produces wrong results for specific case? If so, do you think it deserves a separate fix, e.g. for jdk16? It does. This patch should change nothing at all, except moving text from A to B. -- 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 njian at openjdk.java.net Thu Jan 28 11:19:47 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Thu, 28 Jan 2021 11:19:47 GMT Subject: RFR: 8260355: AArch64: deoptimization stub should save vector registers In-Reply-To: References: <5PbujtOhWB7uqNXu5vRMwYGNMNU78aLAkGpDLWUnQKM=.9d2206fe-9c15-424c-b08e-80eab468df2a@github.com> Message-ID: <_4sNUEnp1D8ufU2DBKfAVKa0AzBXOdKT9-ya8RwFIKo=.37bbf7b0-d3eb-47a9-9057-cc0569577207@github.com> On Thu, 28 Jan 2021 10:27:04 GMT, Vladimir Ivanov wrote: >> This is an AArch64 port of the fix for JDK-8256056 "Deoptimization stub >> doesn't save vector registers on x86". The problem is that a vector >> produced by the Vector API may be stored in a register when the deopt >> blob is called. Because the deopt blob only stores the lower half of >> vector registers, the full vector object cannot be rematerialized during >> deoptimization. So the following will crash on AArch64 with current JDK: >> >> make test TEST="jdk/incubator/vector" \ >> JTREG="VM_OPTIONS=-XX:+DeoptimizeALot -XX:DeoptimizeALotInterval=0" >> >> The fix is to store the full vector registers by passing >> save_vectors=true to save_live_registers() in the deopt blob. Because >> save_live_registers() places the integer registers above the floating >> registers in the stack frame, RegisterSaver::r0_offset_in_bytes() needs >> to calculate the SP offset based on whether full vectors were saved, and >> whether those vectors were NEON or SVE, rather than using a static >> offset as it does currently. >> >> The change to VectorSupport::allocate_vector_payload_helper() is >> required because we only store the lowest VMReg slot in the oop map. >> However unlike x86 the vector registers are always saved in a contiguous >> region of memory, so we can calculate the address of each vector element >> as an offset from the address of the first slot. X86 handles this in >> RegisterMap::pd_location() but that won't work on AArch64 because with >> SVE there isn't a unique VMReg corresponding to each four-byte physical >> slot in the vector (there are always exactly eight logical VMRegs >> regardless of the actual vector length). >> >> Tested hotspot_all_no_apps and jdk_core. > > src/hotspot/share/prims/vectorSupport.cpp line 138: > >> 136: >> 137: for (int i = 0; i < num_elem; i++) { >> 138: bool contiguous = X86_ONLY(false) NOT_X86(true); > > I don't like this change. It's not x86-specific, but SVE-specific code. What is broken here is `VMReg::next()` doesn't work properly for `VecA` registers. And, as a result, it makes `RegisterMap::location(VMReg)` unusable as well. > > So, a proper fix should address that instead. If there's no way to save `VMReg::next()` and `RegisterMap::location(VMReg)`, then new cross-platform API should be introduced and `VectorSupport::allocate_vector_payload_helper()` migrated to it. For Arm NEON (and PPC) we don't set VMReg::next() in oopmap either, and their vector slots are contiguous, so that's x86-specific? But yes, NEON can also generate correct full oopmap as for fixed vector size. For SVE, I have no idea to have proper VMReg::next() support, so Nick's solution looks good to me. Regarding to introducing new cross-platform API, which API do you mean? If we could have some better api, that would be perfect. Currently, allocate_vector_payload_helper() is the only one I can see that is vector related for RegisterMap::location() call. ------------- PR: https://git.openjdk.java.net/jdk/pull/2279 From neliasso at openjdk.java.net Thu Jan 28 11:38:47 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Thu, 28 Jan 2021 11:38:47 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v8] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 02:24:06 GMT, Wang Huang wrote: >> The reason is : >> >> BasicType t = store->as_Mem()->memory_type(); >> const char* fill_name; >> if (msg == NULL && >> StubRoutines::select_fill_function(t, false, fill_name) == NULL) { >> msg = "unsupported store"; >> msg_node = store; >> } >> >> If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. >> >> I add a new case here to avoid mistake: >> case T_NARROWOOP: >> case T_NARROWKLASS: >> case T_ADDRESS: >> + case T_VOID: >> // Currently unsupported >> return NULL; > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > add missing summary and test name Looks good. ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/132 From neliasso at openjdk.java.net Thu Jan 28 11:38:48 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Thu, 28 Jan 2021 11:38:48 GMT Subject: [jdk16] RFR: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop [v8] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 11:33:36 GMT, Nils Eliasson wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> add missing summary and test name > > Looks good. I will sponsor this change when 24 hours have passed since the last update. ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 From dongbo at openjdk.java.net Thu Jan 28 12:12:45 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Thu, 28 Jan 2021 12:12:45 GMT Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 10:37:47 GMT, Ningsheng Jian wrote: >> As discussed in [1], all NEON instructions should be moved from `aarch64.ad` to `aarch64_neon.ad`. >> >> In the first commit [2] of this PR, the NEON instructions are deleted from `aarch64.ad` and appended to `aarch64_neon.ad`. >> I compared the generated code in `aarch64_neon.ad` with original code in `aarch64.ad`, no suspicious differences found. >> The last two commits just simply move code around in `aarch64_neon.ad` to put related instructions together, i.e. `LoadStore` [3], `Reduction` [4]. >> >> This also supports vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`, fixes few typos, e.g. `vor8B`, `vsrla4S_imm`. >> >> [1] https://github.com/openjdk/jdk/pull/1215#issuecomment-728186803 >> [2] https://github.com/dgbo/jdk/commit/40cbe99e647cdf93712edf8f77ab3b5b30ea0a95 >> [3] https://github.com/dgbo/jdk/commit/695fb8f8ef009b733a8f804e791347f4bfe2572e >> [4] https://github.com/dgbo/jdk/commit/e0c38aa9aaa6af9925a3821328384b1e2b2c2070 > > I managed to sort all the instructs and compare them with and without the patch. They are general the same except for some trailing whitespaces and typos you mentioned. > _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_ > > On 1/28/21 10:40 AM, Ningsheng Jian wrote: > > > I see you have fixed this typo, from ushr to usra. I presume original version generates wrong code and produces wrong results for specific case? If so, do you think it deserves a separate fix, e.g. for jdk16? > > It does. This patch should change nothing at all, except moving > text from A to B. > > -- > 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 @nsjian @theRealAph Thank you for the comments. I'll raise a seperate PR to fix this right now. BTW, since Andrew says we should change nothing at all in this move, do you think we should also do the things below in separtate PRs? 1. fix the typo of `vor8B`. 2. supporting vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2273 From vlivanov at openjdk.java.net Thu Jan 28 12:15:41 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 28 Jan 2021 12:15:41 GMT Subject: RFR: 8260355: AArch64: deoptimization stub should save vector registers In-Reply-To: <_4sNUEnp1D8ufU2DBKfAVKa0AzBXOdKT9-ya8RwFIKo=.37bbf7b0-d3eb-47a9-9057-cc0569577207@github.com> References: <5PbujtOhWB7uqNXu5vRMwYGNMNU78aLAkGpDLWUnQKM=.9d2206fe-9c15-424c-b08e-80eab468df2a@github.com> <_4sNUEnp1D8ufU2DBKfAVKa0AzBXOdKT9-ya8RwFIKo=.37bbf7b0-d3eb-47a9-9057-cc0569577207@github.com> Message-ID: On Thu, 28 Jan 2021 11:17:16 GMT, Ningsheng Jian wrote: >> src/hotspot/share/prims/vectorSupport.cpp line 138: >> >>> 136: >>> 137: for (int i = 0; i < num_elem; i++) { >>> 138: bool contiguous = X86_ONLY(false) NOT_X86(true); >> >> I don't like this change. It's not x86-specific, but SVE-specific code. What is broken here is `VMReg::next()` doesn't work properly for `VecA` registers. And, as a result, it makes `RegisterMap::location(VMReg)` unusable as well. >> >> So, a proper fix should address that instead. If there's no way to save `VMReg::next()` and `RegisterMap::location(VMReg)`, then new cross-platform API should be introduced and `VectorSupport::allocate_vector_payload_helper()` migrated to it. > > For Arm NEON (and PPC) we don't set VMReg::next() in oopmap either, and their vector slots are contiguous, so that's x86-specific? But yes, NEON can also generate correct full oopmap as for fixed vector size. For SVE, I have no idea to have proper VMReg::next() support, so Nick's solution looks good to me. Regarding to introducing new cross-platform API, which API do you mean? If we could have some better api, that would be perfect. Currently, allocate_vector_payload_helper() is the only one I can see that is vector related for RegisterMap::location() call. Probably, x86 unique in using non-contiguous representation for vector values, but it doesn't make the code in question x86-specific. AArch64 is the only user of`VecA` and `VecA` is the only register type which has a mismatch in size between in-memory and RegMask representation. So, I conclude it is AArch64/SVE-specific. On x86 RegisterMap isn't fully populated for vector registers as well, but there's`RegisterMap::pd_location()` to cover that. Regarding new API, I mean the alternative to `VMReg::next()`/`RegisterMap::location(VMReg)` which is able to handle `VecA` case well. As Nick pointed out earlier, the problem with `VecA` is that there's no `VMReg` representation for all the slots which comprise the register value. Either enhancing `VMReg::next(int)` to produce special values for `VecA` case or introducing `RegisterMap::location(VMReg base_reg, int slot)` is a better way to handle the problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/2279 From eosterlund at openjdk.java.net Thu Jan 28 13:03:09 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 28 Jan 2021 13:03:09 GMT Subject: RFR: 8259643: ZGC can return metaspace OOM prematurely Message-ID: There exists a race condition for ZGC metaspace allocations, where an allocation can throw OOM due to unbounded starvation from other threads. Towards the end of the allocation dance, we conceptually do this: 1. full_gc() 2. final_allocation_attempt() And if we still fail at 2 after doing a full GC, we conclude that there isn't enough metaspace memory. However, if the thread gets preempted between 1 and 2, then an unbounded number of metaspace allocations from other threads can fill up the entire metaspace, making the final allocation attempt fail and hence throw. This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM. I managed to reproduce this with the right sleeps. The way we deal with this particular issue for heap allocations, is to have an allocation request queue, and satisfy those allocations before others, preventing starvation. My solution to this metaspace OOM problem will be to basically do exactly that - have a queue of "critical" allocations, that get precedence over normal metaspace allocations. The solution should work for other concurrent GCs (who likely have the same issue), but I only tried this with ZGC, so I am only hooking in ZGC to the new API (for concurrently unloading GCs to manage critical metaspace allocations) at this point. Passes ZGC tests from tier 1-5, and the particular test that failed (with the JVM sleeps that make it fail deterministically). ------------- Commit messages: - 8259643: ZGC can return metaspace OOM prematurely Changes: https://git.openjdk.java.net/jdk/pull/2289/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2289&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259643 Stats: 296 lines in 6 files changed: 275 ins; 17 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2289/head:pull/2289 PR: https://git.openjdk.java.net/jdk/pull/2289 From dongbo at openjdk.java.net Thu Jan 28 13:06:56 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Thu, 28 Jan 2021 13:06:56 GMT Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers Message-ID: This is a typo introduced by JDK-8255949. Compiler will generate `ushr` for shifting right and accumulating four short integers. It produces wrong results for specific case. The instruction should be `usra`. ------------- Commit messages: - 8260585: AArch64: Wrong code generated by shifting right and accumulating four unsigned short integers Changes: https://git.openjdk.java.net/jdk16/pull/136/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260585 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/136.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/136/head:pull/136 PR: https://git.openjdk.java.net/jdk16/pull/136 From eosterlund at openjdk.java.net Thu Jan 28 13:24:10 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 28 Jan 2021 13:24:10 GMT Subject: RFR: 8259643: ZGC can return metaspace OOM prematurely [v2] In-Reply-To: References: Message-ID: > There exists a race condition for ZGC metaspace allocations, where an allocation can throw OOM due to unbounded starvation from other threads. Towards the end of the allocation dance, we conceptually do this: > > 1. full_gc() > 2. final_allocation_attempt() > > And if we still fail at 2 after doing a full GC, we conclude that there isn't enough metaspace memory. However, if the thread gets preempted between 1 and 2, then an unbounded number of metaspace allocations from other threads can fill up the entire metaspace, making the final allocation attempt fail and hence throw. This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM. I managed to reproduce this with the right sleeps. > > The way we deal with this particular issue for heap allocations, is to have an allocation request queue, and satisfy those allocations before others, preventing starvation. My solution to this metaspace OOM problem will be to basically do exactly that - have a queue of "critical" allocations, that get precedence over normal metaspace allocations. > > The solution should work for other concurrent GCs (who likely have the same issue), but I only tried this with ZGC, so I am only hooking in ZGC to the new API (for concurrently unloading GCs to manage critical metaspace allocations) at this point. > > Passes ZGC tests from tier 1-5, and the particular test that failed (with the JVM sleeps that make it fail deterministically). Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: polish code alignment and rename register/unregister to add/remove ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2289/files - new: https://git.openjdk.java.net/jdk/pull/2289/files/9d49103f..e5a0d080 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2289&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2289&range=00-01 Stats: 12 lines in 2 files changed: 0 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2289/head:pull/2289 PR: https://git.openjdk.java.net/jdk/pull/2289 From stefank at openjdk.java.net Thu Jan 28 13:35:42 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 28 Jan 2021 13:35:42 GMT Subject: RFR: 8259643: ZGC can return metaspace OOM prematurely [v2] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 13:24:10 GMT, Erik ?sterlund wrote: >> There exists a race condition for ZGC metaspace allocations, where an allocation can throw OOM due to unbounded starvation from other threads. Towards the end of the allocation dance, we conceptually do this: >> >> 1. full_gc() >> 2. final_allocation_attempt() >> >> And if we still fail at 2 after doing a full GC, we conclude that there isn't enough metaspace memory. However, if the thread gets preempted between 1 and 2, then an unbounded number of metaspace allocations from other threads can fill up the entire metaspace, making the final allocation attempt fail and hence throw. This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM. I managed to reproduce this with the right sleeps. >> >> The way we deal with this particular issue for heap allocations, is to have an allocation request queue, and satisfy those allocations before others, preventing starvation. My solution to this metaspace OOM problem will be to basically do exactly that - have a queue of "critical" allocations, that get precedence over normal metaspace allocations. >> >> The solution should work for other concurrent GCs (who likely have the same issue), but I only tried this with ZGC, so I am only hooking in ZGC to the new API (for concurrently unloading GCs to manage critical metaspace allocations) at this point. >> >> Passes ZGC tests from tier 1-5, and the particular test that failed (with the JVM sleeps that make it fail deterministically). > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > polish code alignment and rename register/unregister to add/remove Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2289 From eosterlund at openjdk.java.net Thu Jan 28 13:39:43 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 28 Jan 2021 13:39:43 GMT Subject: RFR: 8259643: ZGC can return metaspace OOM prematurely [v2] In-Reply-To: <7ZKX9hzE8xoqiDrvVu6iPiqf9y3U5mRDrl_QVhKaWDo=.58c6cbea-eec4-48ef-9a41-e8cdb5356c20@github.com> References: <7ZKX9hzE8xoqiDrvVu6iPiqf9y3U5mRDrl_QVhKaWDo=.58c6cbea-eec4-48ef-9a41-e8cdb5356c20@github.com> Message-ID: On Thu, 28 Jan 2021 13:36:20 GMT, Per Liden wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> polish code alignment and rename register/unregister to add/remove > > Marked as reviewed by pliden (Reviewer). Thanks for the reviews @pliden and @stefank. ------------- PR: https://git.openjdk.java.net/jdk/pull/2289 From pliden at openjdk.java.net Thu Jan 28 13:39:42 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 28 Jan 2021 13:39:42 GMT Subject: RFR: 8259643: ZGC can return metaspace OOM prematurely [v2] In-Reply-To: References: Message-ID: <7ZKX9hzE8xoqiDrvVu6iPiqf9y3U5mRDrl_QVhKaWDo=.58c6cbea-eec4-48ef-9a41-e8cdb5356c20@github.com> On Thu, 28 Jan 2021 13:24:10 GMT, Erik ?sterlund wrote: >> There exists a race condition for ZGC metaspace allocations, where an allocation can throw OOM due to unbounded starvation from other threads. Towards the end of the allocation dance, we conceptually do this: >> >> 1. full_gc() >> 2. final_allocation_attempt() >> >> And if we still fail at 2 after doing a full GC, we conclude that there isn't enough metaspace memory. However, if the thread gets preempted between 1 and 2, then an unbounded number of metaspace allocations from other threads can fill up the entire metaspace, making the final allocation attempt fail and hence throw. This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM. I managed to reproduce this with the right sleeps. >> >> The way we deal with this particular issue for heap allocations, is to have an allocation request queue, and satisfy those allocations before others, preventing starvation. My solution to this metaspace OOM problem will be to basically do exactly that - have a queue of "critical" allocations, that get precedence over normal metaspace allocations. >> >> The solution should work for other concurrent GCs (who likely have the same issue), but I only tried this with ZGC, so I am only hooking in ZGC to the new API (for concurrently unloading GCs to manage critical metaspace allocations) at this point. >> >> Passes ZGC tests from tier 1-5, and the particular test that failed (with the JVM sleeps that make it fail deterministically). > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > polish code alignment and rename register/unregister to add/remove Marked as reviewed by pliden (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2289 From stuefe at openjdk.java.net Thu Jan 28 16:26:40 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 28 Jan 2021 16:26:40 GMT Subject: RFR: 8259643: ZGC can return metaspace OOM prematurely [v2] In-Reply-To: References: <7ZKX9hzE8xoqiDrvVu6iPiqf9y3U5mRDrl_QVhKaWDo=.58c6cbea-eec4-48ef-9a41-e8cdb5356c20@github.com> Message-ID: <3UDe0d-AIFxOb5CWce7yStNyzXpAC4A5yq8FxQr-s8w=.f5ea6d6f-168e-43fe-8c85-1ff353e98008@github.com> On Thu, 28 Jan 2021 13:37:16 GMT, Erik ?sterlund wrote: >> Marked as reviewed by pliden (Reviewer). > > Thanks for the reviews @pliden and @stefank. Hi Erik, lets see if I understand the problem: 1 n threads allocate metaspace 2 thread A gets an allocation error (not HWM but a hard limit) 3 .. returns, (eventually) schedules a synchronous GC. 4 .. gc runs, the CLDG is at some point purged, releases metaspace pressure 5 other threads load classes, allocating metaspace concurrently, benefitting from the released pressure 6 thread A reattempts allocation, fails again. This is normally not a problem, no? Which thread exactly gets the OOM if the VM hovers that close to the limit does not really matter. But you write "This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM." - so we could get OOMs even if most of the Metaspace were vacant? This only can happen if, between (4) and (6), other threads not only allocate metaspace, but also then loose the loaders used for those allocations, to late for the GC at (4) to collect them but before (5). Collecting them would require another GC. In other words, the contract is that we only throw an OOM if we really tried everything, but since the effects of the first GC are "stale" it does not count as try? Do you think this is a realistic problem? Do I understand your patch right in that you divide allocations in two priority classes, add another lock, MetaspaceCritical_lock, which blocks normal allocations as long as critical allocations are queued? Sorry if I am slow :) --- One problem I see is that Metaspace::purge is not the full purge. Reclaiming metaspace happens in two stages: 1) in CLDG::purge, we delete all `ClassLoaderMetaspace` objects belonging to dead loaders. This releases all their metaspace to the freelists, optionally uncommitting portions of it (since JEP387). 2) in Metaspace::purge, we go through Metaspace and munmap any mappings which are now completely vacant. The metaspace pressure release already happens in (1), so any concurrent thread allocating will benefit already. --- Why do we even need a queue? Why could we not just let the first thread attempting a synchronous gc block metaspace allocation path for all threads, including others running into a limit, until the gc is finished and it had its first-allocation-right served? Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/2289 From ddong at openjdk.java.net Thu Jan 28 17:01:52 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 28 Jan 2021 17:01:52 GMT Subject: RFR: 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) Message-ID: <7Jps9Sq1KlTAc3TUYWGzD23tkuzO_DR0Jah1JMHE_JI=.20407a00-1795-46c8-a7e3-c3225636ccd6@github.com> hi, Could I have a review of this fix? If we run the following code snippet, will get a crash class JFRDemo { public static void main(String[] args) { Recording r = new Recording(); r.enable("MyEvent"); r.start(); MyEvent event = new MyEvent(); event.begin(); event.clazz = long.class; event.commit(); } } @Enabled(true) @StackTrace(true) @Registered(true) @Name("MyEvent") class MyEvent extends Event { @Label("Class") public Class clazz; } ------------- Commit messages: - 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) Changes: https://git.openjdk.java.net/jdk/pull/2295/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2295&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260589 Stats: 138 lines in 3 files changed: 138 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2295.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2295/head:pull/2295 PR: https://git.openjdk.java.net/jdk/pull/2295 From eosterlund at openjdk.java.net Thu Jan 28 17:57:42 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 28 Jan 2021 17:57:42 GMT Subject: RFR: 8259643: ZGC can return metaspace OOM prematurely [v2] In-Reply-To: <3UDe0d-AIFxOb5CWce7yStNyzXpAC4A5yq8FxQr-s8w=.f5ea6d6f-168e-43fe-8c85-1ff353e98008@github.com> References: <7ZKX9hzE8xoqiDrvVu6iPiqf9y3U5mRDrl_QVhKaWDo=.58c6cbea-eec4-48ef-9a41-e8cdb5356c20@github.com> <3UDe0d-AIFxOb5CWce7yStNyzXpAC4A5yq8FxQr-s8w=.f5ea6d6f-168e-43fe-8c85-1ff353e98008@github.com> Message-ID: On Thu, 28 Jan 2021 16:23:12 GMT, Thomas Stuefe wrote: >> Thanks for the reviews @pliden and @stefank. > > Hi Erik, > > lets see if I understand the problem: > > 1 n threads allocate metaspace > 2 thread A gets an allocation error (not HWM but a hard limit) > 3 .. returns, (eventually) schedules a synchronous GC. > 4 .. gc runs, the CLDG is at some point purged, releases metaspace pressure > 5 other threads load classes, allocating metaspace concurrently, benefitting from the released pressure > 6 thread A reattempts allocation, fails again. > > This is normally not a problem, no? Which thread exactly gets the OOM if the VM hovers that close to the limit does not really matter. But you write "This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM." - so we could get OOMs even if most of the Metaspace were vacant? This only can happen if, between (4) and (6), other threads not only allocate metaspace, but also then loose the loaders used for those allocations, to late for the GC at (4) to collect them but before (5). Collecting them would require another GC. > > In other words, the contract is that we only throw an OOM if we really tried everything, but since the effects of the first GC are "stale" it does not count as try? > > Do you think this is a realistic problem? > > Do I understand your patch right in that you divide allocations in two priority classes, add another lock, MetaspaceCritical_lock, which blocks normal allocations as long as critical allocations are queued? > > Sorry if I am slow :) > > --- > > One problem I see is that Metaspace::purge is not the full purge. Reclaiming metaspace happens in two stages: > 1) in CLDG::purge, we delete all `ClassLoaderMetaspace` objects belonging to dead loaders. This releases all their metaspace to the freelists, optionally uncommitting portions of it (since JEP387). > 2) in Metaspace::purge, we go through Metaspace and munmap any mappings which are now completely vacant. > > The metaspace pressure release already happens in (1), so any concurrent thread allocating will benefit already. > > --- > > Why do we even need a queue? Why could we not just let the first thread attempting a synchronous gc block metaspace allocation path for all threads, including others running into a limit, until the gc is finished and it had its first-allocation-right served? > > Thanks, Thomas Hi Thomas, Thanks for chiming in! I will reply inline. > Hi Erik, > > lets see if I understand the problem: > > 1 n threads allocate metaspace > 2 thread A gets an allocation error (not HWM but a hard limit) > 3 .. returns, (eventually) schedules a synchronous GC. > 4 .. gc runs, the CLDG is at some point purged, releases metaspace pressure > 5 other threads load classes, allocating metaspace concurrently, benefitting from the released pressure > 6 thread A reattempts allocation, fails again. That's the one. > This is normally not a problem, no? Indeed, and that was my gut feeling when the current handling was written. I wouldn't expect an actual application to ever hit this problem. Nevertheless, I think it's a soundness problem with completely unbounded starvation, even though it doesn't happen in real life. So I think I would still like to fix the issue. It is definitely a bit arbitrary though where we decide to draw the line of what we guarantee, and what the balance between exactness and maintainability should be. My aim is to try hard enough so we don't rely on luck (random sleeps) if a program that shouldn't be even close to OOM will fail or not, even though you have to be *very* unlucky for it to fail. But I am not interested in prefect guarantees either, down to the last allocation. My balance is that I allow throwing OOM prematurely if we are "really close" to being down to the last allocation OOM, but if you are not "really close", then no sleep in the world should cause a failure. > Which thread exactly gets the OOM if the VM hovers that close to the limit does not really matter. But you write "This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM." - so we could get OOMs even if most of the Metaspace were vacant? This only can happen if, between (4) and (6), other threads not only allocate metaspace, but also then loose the loaders used for those allocations, to late for the GC at (4) to collect them but before (5). Collecting them would require another GC. Right, and that is indeed what the test does. It loads chunks of 1000 classes and releases them, assuming that surely after releasing them, I can allocate more classes. Unless of course starvation ruins the day. > In other words, the contract is that we only throw an OOM if we really tried everything, but since the effects of the first GC are "stale" it does not count as try? The previous contract was that we try to allocate again after a full GC, and if that fails we give up. The issue is that this guarantee allows the GC to free up 99% of metaspace, yet still fail the allocation due to races with other threads doing the same thing. So at any given point, it might be that only 1% of metadata is reachable, yet an OOM can be produced if you are "unlucky". > Do you think this is a realistic problem? It is realistic enough that one stress test has failed in the real world. Yet I don't think any application out there will run into any issue. But I prefer having a sound solution where we can know that and not rely on probability. > Do I understand your patch right in that you divide allocations in two priority classes, add another lock, MetaspaceCritical_lock, which blocks normal allocations as long as critical allocations are queued? Yes, that's exactly right. > Sorry if I am slow :) Not at all! > One problem I see is that Metaspace::purge is not the full purge. Reclaiming metaspace happens in two stages: > > 1. in CLDG::purge, we delete all `ClassLoaderMetaspace` objects belonging to dead loaders. This releases all their metaspace to the freelists, optionally uncommitting portions of it (since JEP387). > > 2. in Metaspace::purge, we go through Metaspace and munmap any mappings which are now completely vacant. > > > The metaspace pressure release already happens in (1), so any concurrent thread allocating will benefit already. Ah. I thought it was all done in 2. I can move the Big Fat Lock to cover all of CLDG::purge instead. What do you think? It just needs to cover the entire thing basically. > Why do we even need a queue? Why could we not just let the first thread attempting a synchronous gc block metaspace allocation path for all threads, including others running into a limit, until the gc is finished and it had its first-allocation-right served? Each "critical" allocation rides on one particular GC cycle, that denotes the make-or-break point of the allocation. In order to prevent starvation, we have to satisfy all critical allocations who have their make-or-break GC cycle associated with the current purge() operation, before we release the lock in purge(), letting new allocations in, or we will rely on luck again. However, among the pending critical allocations, they will all possibly have different make-or-break GC cycles associated with them. So in purge() some of them need to be satisfied, and others do not, yet can happily get their allocations satisfied opportunistically if possible. So we need to make sure they are ordered somehow, such that the earliest arriving pending critical allocations are satisfied first, before subsequent critical allocations (possibly waiting for a later GC), or we can get premature OOM situations again, where a thread releases a bunch of memory, expecting to be able to allocate, yet fails due to races with various threads. The queue basically ensures the ordering of critical allocation satisfaction is sound, so that the pending critical allocations with the associated make-or-break GC being the one running purge(), are satisfied first, before satisfying (opportunistically) other critical allocations, that are really waiting for the next GC to happen. Thanks, > Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/2289 From iveresov at openjdk.java.net Thu Jan 28 20:53:49 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 28 Jan 2021 20:53:49 GMT Subject: Integrated: 8251462: Simplify compilation policy In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 18:43:51 GMT, Igor Veresov wrote: > This change removes the legacy compilation policy and an emulation mode to the tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code, devirtualizes the compilation policy API, adds a consistent way to query compiler configuration with the new ```CompilerConfig``` API. > > I've tested this with hs-tier{1,2,3,4,5}. And also made sure it builds and works with C1/C2-Graal/AOT being enabled/disabled. > > Since there are platform-specific changes I would greatly appreciate some help from the maintainers of the specific ports to verify the build and run basic smoke tests. I've already tested x64 and aarch64. Thanks! This pull request has now been integrated. Changeset: 15196325 Author: Igor Veresov URL: https://git.openjdk.java.net/jdk/commit/15196325 Stats: 5314 lines in 98 files changed: 1519 ins; 2994 del; 801 mod 8251462: Simplify compilation policy Reviewed-by: cjplummer, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1985 From iklam at openjdk.java.net Thu Jan 28 21:07:57 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 28 Jan 2021 21:07:57 GMT Subject: RFR: 8260471: Change SystemDictionary::X_klass calls to vmClasses::X_klass In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 21:00:04 GMT, Ioi Lam wrote: > This is the second step of https://github.com/openjdk/jdk/pull/2246 (8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp). These are mostly boiler-plate changes done by scripts. > > [1] Change calls like > > SystemDictionary::Object_klass() > SystemDictionary::Throwable_klass_is_loaded() > SystemDictionary::box_klass_type() > > to > > vmClasses::Object_klass() > vmClasses::Throwable_klass_is_loaded() > vmClasses::box_klass_type() > > [2] Remove unnecessary inclusion of systemDictionary.hpp (replace with vmClasses.hpp if necessary). In some cases, I have to add signature.hpp to some files, which only indirectly included signature.hpp through systemDictionary.hpp. > > [3] In the previous PR, I incorrectly used the enum name `VMClassID`. This PR changes it to `vmClassID` to match the existing use of `vmSymbolID` and `vmIntrinsicID`. > > Due to the refactoring of these two PRs, the number of HotSpot .o files that include systemDictionary.hpp decreases from 491 to 91. HotSpot build time is reduced by about 2% > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. To make reviewing the 185 files a little easier, I haven't changed the copyright dates yet. I'll do that before the final integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/2301 From iklam at openjdk.java.net Thu Jan 28 21:07:57 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 28 Jan 2021 21:07:57 GMT Subject: RFR: 8260471: Change SystemDictionary::X_klass calls to vmClasses::X_klass Message-ID: This is the second step of https://github.com/openjdk/jdk/pull/2246 (8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp). These are mostly boiler-plate changes done by scripts. [1] Change calls like SystemDictionary::Object_klass() SystemDictionary::Throwable_klass_is_loaded() SystemDictionary::box_klass_type() to vmClasses::Object_klass() vmClasses::Throwable_klass_is_loaded() vmClasses::box_klass_type() [2] Remove unnecessary inclusion of systemDictionary.hpp (replace with vmClasses.hpp if necessary). In some cases, I have to add signature.hpp to some files, which only indirectly included signature.hpp through systemDictionary.hpp. [3] In the previous PR, I incorrectly used the enum name `VMClassID`. This PR changes it to `vmClassID` to match the existing use of `vmSymbolID` and `vmIntrinsicID`. Due to the refactoring of these two PRs, the number of HotSpot .o files that include systemDictionary.hpp decreases from 491 to 91. HotSpot build time is reduced by about 2% Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- Commit messages: - 8260471: Change SystemDictionary::xxx_klass() calls to vmClasses::xxx_klass() Changes: https://git.openjdk.java.net/jdk/pull/2301/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2301&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260471 Stats: 691 lines in 185 files changed: 85 ins; 64 del; 542 mod Patch: https://git.openjdk.java.net/jdk/pull/2301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2301/head:pull/2301 PR: https://git.openjdk.java.net/jdk/pull/2301 From ddong at openjdk.java.net Fri Jan 29 01:49:57 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 29 Jan 2021 01:49:57 GMT Subject: RFR: 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) [v2] In-Reply-To: <7Jps9Sq1KlTAc3TUYWGzD23tkuzO_DR0Jah1JMHE_JI=.20407a00-1795-46c8-a7e3-c3225636ccd6@github.com> References: <7Jps9Sq1KlTAc3TUYWGzD23tkuzO_DR0Jah1JMHE_JI=.20407a00-1795-46c8-a7e3-c3225636ccd6@github.com> Message-ID: > hi, > > Could I have a review of this fix? > > If we run the following code snippet, will get a crash > class JFRDemo { > public static void main(String[] args) { > Recording r = new Recording(); > r.enable("MyEvent"); > r.start(); > > MyEvent event = new MyEvent(); > event.begin(); > event.clazz = long.class; > event.commit(); > } > } > > @Enabled(true) > @StackTrace(true) > @Registered(true) > @Name("MyEvent") > class MyEvent extends Event { > > @Label("Class") > public Class clazz; > } Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: clean doc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2295/files - new: https://git.openjdk.java.net/jdk/pull/2295/files/d2d7477a..0ba1623c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2295&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2295&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2295.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2295/head:pull/2295 PR: https://git.openjdk.java.net/jdk/pull/2295 From aph at openjdk.java.net Fri Jan 29 02:37:42 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 29 Jan 2021 02:37:42 GMT Subject: Integrated: JDK-8255544: Create a checked cast In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 15:50:52 GMT, Andrew Haley wrote: > In many places we've added C-style casts to silence compiler warnings, for example when truncating a size_t to an int when we know the size_t is a small struct. Such casts are inherently risky, because they effectively disable useful compiler warnings. We should add a form of cast that checks at runtime that a truncation does not overflow. This pull request has now been integrated. Changeset: 3302d3ad Author: Andrew Haley URL: https://git.openjdk.java.net/jdk/commit/3302d3ad Stats: 17 lines in 2 files changed: 16 ins; 0 del; 1 mod 8255544: Create a checked cast Reviewed-by: adinn, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/904 From nick.gasson at arm.com Fri Jan 29 07:53:19 2021 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 29 Jan 2021 15:53:19 +0800 Subject: RFR: 8260355: AArch64: deoptimization stub should save vector registers In-Reply-To: <817f592f-7933-241d-3e7b-50874879005b@redhat.com> References: <5PbujtOhWB7uqNXu5vRMwYGNMNU78aLAkGpDLWUnQKM=.9d2206fe-9c15-424c-b08e-80eab468df2a@github.com> <817f592f-7933-241d-3e7b-50874879005b@redhat.com> Message-ID: <85ft2kqivk.fsf@nicgas01-pc.shanghai.arm.com> On 01/28/21 17:48 pm, Andrew Haley wrote: > > It seems to me that save_vectors is only set here: > > bool save_vectors = COMPILER2_OR_JVMCI != 0; > > which means that save_vectors is a static property of a build, not something > that can vary. Therefore, there is nothing to be gained by passing save_vectors > around. Could we simply have a save_vectors_on_deopt() function? > RegisterSaver is also used by generate_resolve_blob (which never saves vectors) and generate_handler_blob (which saves vectors when poll_type == POLL_AT_VECTOR_LOOP). How about we make RegisterSaver a class you can instantiate, and pass whether to save vectors or not to the constructor? That would look like: RegisterSaver reg_save(COMPILER2_OR_JVMCI != 0 /* save_vectors */); map = reg_save.save_live_registers(masm, 0, &frame_size_in_words); ... reg_save.restore_live_registers(masm); Which avoids passing save_vectors around everywhere. > Also, I'm wondering how much all of this complexity gains us for the sake > of configurations without C2. I'd be very tempted to just leave a hole in > the stack for these systems. How much stack would that cost? For NEON the difference is 768 bytes vs 512, but SVE could be a lot more. 83 // FIXME -- this is used by C1 84 class RegisterSaver { Do you remember what this is referring to? That it's duplicating save_live_registers() in c1_Runtime_aarch64.cpp? -- Thanks, Nick From qingfeng.yy at alibaba-inc.com Fri Jan 29 08:03:14 2021 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Fri, 29 Jan 2021 16:03:14 +0800 Subject: =?UTF-8?B?QnVpbGQgZmFpbHMgd2hlbiBleGNsdWRpbmcgU2VyaWFsIEdD?= Message-ID: <7e2adbed-1b0b-4693-92c0-5c03963b3c55.qingfeng.yy@alibaba-inc.com> Hi, It's quite easy to reproduce this problem: ./configure --with-jvm-features=-serialgc ... ; make images I got the following output ``` ... === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_objs_genCollectedHeap.o: /home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/gc/shared/genCollectedHeap.cpp: In member function 'virtual void GenCollectedHeap::post_initialize()': /home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/gc/shared/genCollectedHeap.cpp:206:3: error: 'MarkSweep' has not been declared 206 | MarkSweep::initialize(); | ^~~~~~~~~ * All command lines available in /home/qingfeng.yy/openjdk16_so_warning/jdk/build/linux-x86_64-server-release/make-support/failure-logs. === End of repeated output === ``` I found current JVM features contain the serial gc, but actually I can not build an image that does not contain serial gc. This problem has existed from jdk 11 to jdk head. I am somewhat surprised, so I haven't filed an issue on JBS. Is this really a bug? Or actually we should revise the building document and remove all INCLUDE_SERIALGC macros? Cheers,Yang Yi From whuang at openjdk.java.net Fri Jan 29 08:10:51 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 29 Jan 2021 08:10:51 GMT Subject: [jdk16] Integrated: 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 02:01:00 GMT, Wang Huang wrote: > The reason is : > > BasicType t = store->as_Mem()->memory_type(); > const char* fill_name; > if (msg == NULL && > StubRoutines::select_fill_function(t, false, fill_name) == NULL) { > msg = "unsupported store"; > msg_node = store; > } > > If the `store` is a `StoreVectorNode` ,the `BasicType` is `T_VOID`. It seems that we don't need to intrinsify a `StoreVectorNode` filling here. > > I add a new case here to avoid mistake: > case T_NARROWOOP: > case T_NARROWKLASS: > case T_ADDRESS: > + case T_VOID: > // Currently unsupported > return NULL; This pull request has now been integrated. Changeset: a117e115 Author: Wang Huang Committer: Nils Eliasson URL: https://git.openjdk.java.net/jdk16/commit/a117e115 Stats: 82 lines in 2 files changed: 82 ins; 0 del; 0 mod 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop Co-authored-by: He Xuejin Reviewed-by: neliasso, kvn, iignatyev ------------- PR: https://git.openjdk.java.net/jdk16/pull/132 From kbarrett at openjdk.java.net Fri Jan 29 08:50:48 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 29 Jan 2021 08:50:48 GMT Subject: RFR: 8260630: Templatize literal_size Message-ID: <5sPGLrCapTTPbCklqP93lId2uqrOw343_WFDlMaQv-I=.193b309c-13c7-41c1-9a1d-fae471d5c6c4@github.com> Please review a couple of small cleanups in Hashtable support. (1) Replace some "default" overloads for literal_size with a template. This makes it easier to add new Hashtable value types whose sizes aren't interesting for statistics printout. (2) Trivial change to remove no longer used instantiation of Hashtable support for oop values. Testing: mach5 tier1 ------------- Commit messages: - remove instantiations for oop - templatize literal_size Changes: https://git.openjdk.java.net/jdk/pull/2310/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2310&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260630 Stats: 14 lines in 1 file changed: 1 ins; 11 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2310.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2310/head:pull/2310 PR: https://git.openjdk.java.net/jdk/pull/2310 From pliden at openjdk.java.net Fri Jan 29 09:12:42 2021 From: pliden at openjdk.java.net (Per Liden) Date: Fri, 29 Jan 2021 09:12:42 GMT Subject: RFR: 8260630: Templatize literal_size In-Reply-To: <5sPGLrCapTTPbCklqP93lId2uqrOw343_WFDlMaQv-I=.193b309c-13c7-41c1-9a1d-fae471d5c6c4@github.com> References: <5sPGLrCapTTPbCklqP93lId2uqrOw343_WFDlMaQv-I=.193b309c-13c7-41c1-9a1d-fae471d5c6c4@github.com> Message-ID: <1yn7PxkacDG7AsiY2bWKOxkADdmDlBnVb4LK9cMxcAQ=.b5a85c88-761b-4971-88c2-1993690c94ba@github.com> On Fri, 29 Jan 2021 08:44:51 GMT, Kim Barrett wrote: > Please review a couple of small cleanups in Hashtable support. > > (1) Replace some "default" overloads for literal_size with a template. This > makes it easier to add new Hashtable value types whose sizes aren't > interesting for statistics printout. > > (2) Trivial change to remove no longer used instantiation of Hashtable > support for oop values. > > Testing: > mach5 tier1 Looks good to me! ------------- Marked as reviewed by pliden (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2310 From magnus.ihse.bursie at oracle.com Fri Jan 29 09:49:55 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 29 Jan 2021 10:49:55 +0100 Subject: Build fails when excluding Serial GC In-Reply-To: <7e2adbed-1b0b-4693-92c0-5c03963b3c55.qingfeng.yy@alibaba-inc.com> References: <7e2adbed-1b0b-4693-92c0-5c03963b3c55.qingfeng.yy@alibaba-inc.com> Message-ID: <88f8f4b4-941a-5df3-6a89-28741d2f6c7b@oracle.com> On 2021-01-29 09:03, Yang Yi wrote: > Hi, > > It's quite easy to reproduce this problem: > ./configure --with-jvm-features=-serialgc ... ; make images > > I got the following output > ``` > ... > === Output from failing command(s) repeated here === > * For target hotspot_variant-server_libjvm_objs_genCollectedHeap.o: > /home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/gc/shared/genCollectedHeap.cpp: In member function 'virtual void GenCollectedHeap::post_initialize()': > /home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/gc/shared/genCollectedHeap.cpp:206:3: error: 'MarkSweep' has not been declared > 206 | MarkSweep::initialize(); > | ^~~~~~~~~ > * All command lines available in /home/qingfeng.yy/openjdk16_so_warning/jdk/build/linux-x86_64-server-release/make-support/failure-logs. > === End of repeated output === > ``` > I found current JVM features contain the serial gc, but actually I can not > build an image that does not contain serial gc. This problem has existed > from jdk 11 to jdk head. I am somewhat surprised, so I haven't filed an > issue on JBS. Is this really a bug? Or actually we should revise the building > document and remove all INCLUDE_SERIALGC macros? About a year ago I opened https://bugs.openjdk.java.net/browse/JDK-8240224, to fix this (and other things). This caused quite a heated debate [1], and the result was that I closed the bug again. In summary, my understanding is that hotspot developers view the serialgc as essential, and that there exists no reason beyond toy applications to remove it from compilation. But furthermore the INCLUDE_SERIALGC macros should remain, even though they do not really work, since they function as markers of intent for the code. I don't? agree 100% with this stance, but it's not my code to complain about. :-) Possibly, the configure script should be changed so it does not look like it's possible to exclude the serialgc... /Magnus [1] https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-March/028779.html > > Cheers,Yang Yi > From stefan.karlsson at oracle.com Fri Jan 29 10:07:48 2021 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 29 Jan 2021 11:07:48 +0100 Subject: Build fails when excluding Serial GC In-Reply-To: <7e2adbed-1b0b-4693-92c0-5c03963b3c55.qingfeng.yy@alibaba-inc.com> References: <7e2adbed-1b0b-4693-92c0-5c03963b3c55.qingfeng.yy@alibaba-inc.com> Message-ID: On 2021-01-29 09:03, Yang Yi wrote: > Hi, > > It's quite easy to reproduce this problem: > ./configure --with-jvm-features=-serialgc ... ; make images > > I got the following output > ``` > ... > === Output from failing command(s) repeated here === > * For target hotspot_variant-server_libjvm_objs_genCollectedHeap.o: > /home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/gc/shared/genCollectedHeap.cpp: In member function 'virtual void GenCollectedHeap::post_initialize()': > /home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/gc/shared/genCollectedHeap.cpp:206:3: error: 'MarkSweep' has not been declared > 206 | MarkSweep::initialize(); > | ^~~~~~~~~ > * All command lines available in /home/qingfeng.yy/openjdk16_so_warning/jdk/build/linux-x86_64-server-release/make-support/failure-logs. > === End of repeated output === > ``` > I found current JVM features contain the serial gc, but actually I can not > build an image that does not contain serial gc. This problem has existed > from jdk 11 to jdk head. I am somewhat surprised, so I haven't filed an > issue on JBS. Is this really a bug? Or actually we should revise the building > document and remove all INCLUDE_SERIALGC macros? It's sort-of a known issue, but since we (Oracle) don't build without the Serial GC it has been left to be fixed later. Maybe by us, or maybe by someone who want's to be able to exclude the Serial GC. I won't mind if you want to fix this. However, note that there are some legacy code here because GenCollectedHeap used to be shared code between the Serial GC and CMS. Now that CMS has been removed, GenCollectedHeap is actually only used by the Serial GC. If you look at the code you'll see that Serial code calls back and forth between the GenCollectedHeap (and associated classes). Cleaning that up is on our backlog, but is not a high-priority task. When/if that gets done, some of the code in the shared/ directory, will be moved into the serial/ directory. With that, I think most of the INCLUDE_SERIALGC problems will go away. StefanK > > Cheers,Yang Yi > From stefan.karlsson at oracle.com Fri Jan 29 10:19:04 2021 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 29 Jan 2021 11:19:04 +0100 Subject: Build fails when excluding Serial GC In-Reply-To: <88f8f4b4-941a-5df3-6a89-28741d2f6c7b@oracle.com> References: <7e2adbed-1b0b-4693-92c0-5c03963b3c55.qingfeng.yy@alibaba-inc.com> <88f8f4b4-941a-5df3-6a89-28741d2f6c7b@oracle.com> Message-ID: <2514512e-68d5-868a-5f05-c9d765ae3486@oracle.com> On 2021-01-29 10:49, Magnus Ihse Bursie wrote: > > > On 2021-01-29 09:03, Yang Yi wrote: >> Hi, >> >> It's quite easy to reproduce this problem: >> ./configure --with-jvm-features=-serialgc ... ; make images >> >> I got the following output >> ``` >> ... >> === Output from failing command(s) repeated here === >> * For target hotspot_variant-server_libjvm_objs_genCollectedHeap.o: >> /home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/gc/shared/genCollectedHeap.cpp: >> In member function 'virtual void GenCollectedHeap::post_initialize()': >> /home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/gc/shared/genCollectedHeap.cpp:206:3: >> error: 'MarkSweep' has not been declared >> ?? 206 |?? MarkSweep::initialize(); >> ?????? |?? ^~~~~~~~~ >> * All command lines available in >> /home/qingfeng.yy/openjdk16_so_warning/jdk/build/linux-x86_64-server-release/make-support/failure-logs. >> === End of repeated output === >> ``` >> I found current JVM features contain the serial gc, but actually I >> can not >> build an image that does not contain serial gc. This problem has existed >> from jdk 11 to jdk head. I am somewhat surprised, so I haven't filed an >> issue on JBS. Is this really a bug? Or actually we should revise the >> building >> document and remove all INCLUDE_SERIALGC macros? > > About a year ago I opened > https://bugs.openjdk.java.net/browse/JDK-8240224, to fix this (and > other things). This caused quite a heated debate [1], and the result > was that I closed the bug again. > > In summary, my understanding is that hotspot developers view the > serialgc as essential, and that there exists no reason beyond toy > applications to remove it from compilation. But furthermore the > INCLUDE_SERIALGC macros should remain, even though they do not really > work, since they function as markers of intent for the code. I don't? > agree 100% with this stance, but it's not my code to complain about. :-) I think you got push back on some of the changes. To me and many others the gcConfig.* changes were really controversial. It doesn't mean that fixes to clean this up won't be accepted. In that mail thread, there was a reference to this bug '8234502: Merge GenCollectedHeap and SerialHeap'. Chipping away at that would be good. Fixing that would not only make it possible to build without Serial GC, but also help with the maintainability of our code. StefanK > > Possibly, the configure script should be changed so it does not look > like it's possible to exclude the serialgc... > > /Magnus > > > [1] > https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-March/028779.html > >> >> Cheers,Yang Yi >> > From aph at redhat.com Fri Jan 29 10:21:17 2021 From: aph at redhat.com (Andrew Haley) Date: Fri, 29 Jan 2021 10:21:17 +0000 Subject: RFR: 8260355: AArch64: deoptimization stub should save vector registers In-Reply-To: <85ft2kqivk.fsf@nicgas01-pc.shanghai.arm.com> References: <5PbujtOhWB7uqNXu5vRMwYGNMNU78aLAkGpDLWUnQKM=.9d2206fe-9c15-424c-b08e-80eab468df2a@github.com> <817f592f-7933-241d-3e7b-50874879005b@redhat.com> <85ft2kqivk.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: On 1/29/21 7:53 AM, Nick Gasson wrote: > On 01/28/21 17:48 pm, Andrew Haley wrote: >> >> It seems to me that save_vectors is only set here: >> >> bool save_vectors = COMPILER2_OR_JVMCI != 0; >> >> which means that save_vectors is a static property of a build, not something >> that can vary. Therefore, there is nothing to be gained by passing save_vectors >> around. Could we simply have a save_vectors_on_deopt() function? >> > > RegisterSaver is also used by generate_resolve_blob (which never saves > vectors) and generate_handler_blob (which saves vectors when poll_type > == POLL_AT_VECTOR_LOOP). How about we make RegisterSaver a class you can > instantiate, and pass whether to save vectors or not to the constructor? > That would look like: > > RegisterSaver reg_save(COMPILER2_OR_JVMCI != 0 /* save_vectors */); > map = reg_save.save_live_registers(masm, 0, &frame_size_in_words); > ... > reg_save.restore_live_registers(masm); > > Which avoids passing save_vectors around everywhere. That sounds like a great improvement. >> Also, I'm wondering how much all of this complexity gains us for the sake >> of configurations without C2. I'd be very tempted to just leave a hole in >> the stack for these systems. How much stack would that cost? > > For NEON the difference is 768 bytes vs 512, but SVE could be a lot > more. OK, so it probably wouldn't be worth doing on NEON. But A64FX vectors are 64 bytes each, right? So 2kbytes to save, in which case we need this variable-size register-save area. > 83 // FIXME -- this is used by C1 > 84 class RegisterSaver { > > Do you remember what this is referring to? That it's duplicating > save_live_registers() in c1_Runtime_aarch64.cpp? Probably, yes. -- 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 tschatzl at openjdk.java.net Fri Jan 29 10:24:39 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 29 Jan 2021 10:24:39 GMT Subject: RFR: 8260630: Templatize literal_size In-Reply-To: <5sPGLrCapTTPbCklqP93lId2uqrOw343_WFDlMaQv-I=.193b309c-13c7-41c1-9a1d-fae471d5c6c4@github.com> References: <5sPGLrCapTTPbCklqP93lId2uqrOw343_WFDlMaQv-I=.193b309c-13c7-41c1-9a1d-fae471d5c6c4@github.com> Message-ID: On Fri, 29 Jan 2021 08:44:51 GMT, Kim Barrett wrote: > Please review a couple of small cleanups in Hashtable support. > > (1) Replace some "default" overloads for literal_size with a template. This > makes it easier to add new Hashtable value types whose sizes aren't > interesting for statistics printout. > > (2) Trivial change to remove no longer used instantiation of Hashtable > support for oop values. > > Testing: > mach5 tier1 Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2310 From stuefe at openjdk.java.net Fri Jan 29 11:26:40 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 29 Jan 2021 11:26:40 GMT Subject: RFR: 8259643: ZGC can return metaspace OOM prematurely [v2] In-Reply-To: References: <7ZKX9hzE8xoqiDrvVu6iPiqf9y3U5mRDrl_QVhKaWDo=.58c6cbea-eec4-48ef-9a41-e8cdb5356c20@github.com> <3UDe0d-AIFxOb5CWce7yStNyzXpAC4A5yq8FxQr-s8w=.f5ea6d6f-168e-43fe-8c85-1ff353e98008@github.com> Message-ID: On Thu, 28 Jan 2021 17:54:25 GMT, Erik ?sterlund wrote: >> Hi Erik, >> >> lets see if I understand the problem: >> >> 1 n threads allocate metaspace >> 2 thread A gets an allocation error (not HWM but a hard limit) >> 3 .. returns, (eventually) schedules a synchronous GC. >> 4 .. gc runs, the CLDG is at some point purged, releases metaspace pressure >> 5 other threads load classes, allocating metaspace concurrently, benefitting from the released pressure >> 6 thread A reattempts allocation, fails again. >> >> This is normally not a problem, no? Which thread exactly gets the OOM if the VM hovers that close to the limit does not really matter. But you write "This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM." - so we could get OOMs even if most of the Metaspace were vacant? This only can happen if, between (4) and (6), other threads not only allocate metaspace, but also then loose the loaders used for those allocations, to late for the GC at (4) to collect them but before (5). Collecting them would require another GC. >> >> In other words, the contract is that we only throw an OOM if we really tried everything, but since the effects of the first GC are "stale" it does not count as try? >> >> Do you think this is a realistic problem? >> >> Do I understand your patch right in that you divide allocations in two priority classes, add another lock, MetaspaceCritical_lock, which blocks normal allocations as long as critical allocations are queued? >> >> Sorry if I am slow :) >> >> --- >> >> One problem I see is that Metaspace::purge is not the full purge. Reclaiming metaspace happens in two stages: >> 1) in CLDG::purge, we delete all `ClassLoaderMetaspace` objects belonging to dead loaders. This releases all their metaspace to the freelists, optionally uncommitting portions of it (since JEP387). >> 2) in Metaspace::purge, we go through Metaspace and munmap any mappings which are now completely vacant. >> >> The metaspace pressure release already happens in (1), so any concurrent thread allocating will benefit already. >> >> --- >> >> Why do we even need a queue? Why could we not just let the first thread attempting a synchronous gc block metaspace allocation path for all threads, including others running into a limit, until the gc is finished and it had its first-allocation-right served? >> >> Thanks, Thomas > > Hi Thomas, > > Thanks for chiming in! I will reply inline. > >> Hi Erik, >> >> lets see if I understand the problem: >> >> 1 n threads allocate metaspace >> 2 thread A gets an allocation error (not HWM but a hard limit) >> 3 .. returns, (eventually) schedules a synchronous GC. >> 4 .. gc runs, the CLDG is at some point purged, releases metaspace pressure >> 5 other threads load classes, allocating metaspace concurrently, benefitting from the released pressure >> 6 thread A reattempts allocation, fails again. > > That's the one. > >> This is normally not a problem, no? > > Indeed, and that was my gut feeling when the current handling was written. I wouldn't expect an actual application to ever hit this problem. Nevertheless, I think it's a soundness problem with completely unbounded starvation, even though it doesn't happen in real life. So I think I would still like to fix the issue. > > It is definitely a bit arbitrary though where we decide to draw the line of what we guarantee, and what the balance between exactness and maintainability should be. My aim is to try hard enough so we don't rely on luck (random sleeps) if a program that shouldn't be even close to OOM will fail or not, even though you have to be *very* unlucky for it to fail. But I am not interested in prefect guarantees either, down to the last allocation. My balance is that I allow throwing OOM prematurely if we are "really close" to being down to the last allocation OOM, but if you are not "really close", then no sleep in the world should cause a failure. > >> Which thread exactly gets the OOM if the VM hovers that close to the limit does not really matter. But you write "This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM." - so we could get OOMs even if most of the Metaspace were vacant? This only can happen if, between (4) and (6), other threads not only allocate metaspace, but also then loose the loaders used for those allocations, to late for the GC at (4) to collect them but before (5). Collecting them would require another GC. > > Right, and that is indeed what the test does. It loads chunks of 1000 classes and releases them, assuming that surely after releasing them, I can allocate more classes. Unless of course starvation ruins the day. > >> In other words, the contract is that we only throw an OOM if we really tried everything, but since the effects of the first GC are "stale" it does not count as try? > > The previous contract was that we try to allocate again after a full GC, and if that fails we give up. The issue is that this guarantee allows the GC to free up 99% of metaspace, yet still fail the allocation due to races with other threads doing the same thing. So at any given point, it might be that only 1% of metadata is reachable, yet an OOM can be produced if you are "unlucky". > >> Do you think this is a realistic problem? > > It is realistic enough that one stress test has failed in the real world. Yet I don't think any application out there will run into any issue. But I prefer having a sound solution where we can know that and not rely on probability. > >> Do I understand your patch right in that you divide allocations in two priority classes, add another lock, MetaspaceCritical_lock, which blocks normal allocations as long as critical allocations are queued? > > Yes, that's exactly right. > >> Sorry if I am slow :) > > Not at all! > >> One problem I see is that Metaspace::purge is not the full purge. Reclaiming metaspace happens in two stages: >> >> 1. in CLDG::purge, we delete all `ClassLoaderMetaspace` objects belonging to dead loaders. This releases all their metaspace to the freelists, optionally uncommitting portions of it (since JEP387). >> >> 2. in Metaspace::purge, we go through Metaspace and munmap any mappings which are now completely vacant. >> >> >> The metaspace pressure release already happens in (1), so any concurrent thread allocating will benefit already. > > Ah. I thought it was all done in 2. I can move the Big Fat Lock to cover all of CLDG::purge instead. What do you think? It just needs to cover the entire thing basically. > >> Why do we even need a queue? Why could we not just let the first thread attempting a synchronous gc block metaspace allocation path for all threads, including others running into a limit, until the gc is finished and it had its first-allocation-right served? > > Each "critical" allocation rides on one particular GC cycle, that denotes the make-or-break point of the allocation. > In order to prevent starvation, we have to satisfy all critical allocations who have their make-or-break GC cycle associated with the current purge() operation, before we release the lock in purge(), letting new allocations in, or we will rely on luck again. However, among the pending critical allocations, they will all possibly have different make-or-break GC cycles associated with them. So in purge() some of them need to be satisfied, and others do not, yet can happily get their allocations satisfied opportunistically if possible. So we need to make sure they are ordered somehow, such that the earliest arriving pending critical allocations are satisfied first, before subsequent critical allocations (possibly waiting for a later GC), or we can get premature OOM situations again, where a thread releases a bunch of memory, expecting to be able to allocate, yet fails due to races with various threads. > The queue basically ensures the ordering of critical allocation satisfaction is sound, so that the pending critical allocations with the associated make-or-break GC being the one running purge(), are satisfied first, before satisfying (opportunistically) other critical allocations, that are really waiting for the next GC to happen. > > Thanks, > > >> Thanks, Thomas Hi Erik, thanks for the extensive explanations! One issue with your patch just came to me: the block-on-allocate may be too early. `Metaspace::allocate()` is a bit hot. I wonder about the performance impact of pulling and releasing a lock on each atomar allocation, even if its uncontended. Ideally I'd like to keep this path as close to a simple pointer bump allocation as possible (which it isn't unfortunately). It is also not necessary: the majority of callers satisfy their allocation from already-committed arena local memory. So they are good and no thieves. We would block them unnecessary. I estimate only about 1:60 to 1:1000 calls would need that lock. Allocation happens (roughly) in these steps: 1 try allocate from arena local free block list 2 try allocate from arena local current chunk without newly committing memory 3 try enlarge the chunk in place and/or commit more chunk memory and allocate from current chunk 4 get a new chunk from the freelist (1) and (2) don't bother anyone. Hot path is typically (2). From (3) onward concurrently released memory could be used. So (1) and (2) can still happen before your block. All that happens inside `MetaspaceArena::allocate`: https://github.com/openjdk/jdk/blob/0675473486bc0ee321654d308b600874cf5ce41e/src/hotspot/share/memory/metaspace/metaspaceArena.cpp#L225 But code-wise (2) and (3) are a bit entangled, so the code would have to be massaged a bit to clearly express (2) from (3). Please find more remarks inline. > Hi Thomas, > > Thanks for chiming in! I will reply inline. > > > Hi Erik, > > lets see if I understand the problem: > > 1 n threads allocate metaspace > > 2 thread A gets an allocation error (not HWM but a hard limit) > > 3 .. returns, (eventually) schedules a synchronous GC. > > 4 .. gc runs, the CLDG is at some point purged, releases metaspace pressure > > 5 other threads load classes, allocating metaspace concurrently, benefitting from the released pressure > > 6 thread A reattempts allocation, fails again. > > That's the one. > > > This is normally not a problem, no? > > Indeed, and that was my gut feeling when the current handling was written. I wouldn't expect an actual application to ever hit this problem. Nevertheless, I think it's a soundness problem with completely unbounded starvation, even though it doesn't happen in real life. So I think I would still like to fix the issue. > > It is definitely a bit arbitrary though where we decide to draw the line of what we guarantee, and what the balance between exactness and maintainability should be. My aim is to try hard enough so we don't rely on luck (random sleeps) if a program that shouldn't be even close to OOM will fail or not, even though you have to be _very_ unlucky for it to fail. But I am not interested in prefect guarantees either, down to the last allocation. My balance is that I allow throwing OOM prematurely if we are "really close" to being down to the last allocation OOM, but if you are not "really close", then no sleep in the world should cause a failure. I think I get this now. IIUC we have the problem that memory release happens delayed, and we carry around a baggage of "potentially free" memory which needs a collector run to materialize. So many threads jumping up and down and doing class loading and unloading drive up metaspace use rate and increase the "potentially free" overhead, right? So the thing is to time collector runs right. One concern I have is that if the customer runs with too tight a limit, we may bounce from full GC to full GC. Always scraping the barrel enough to just keep going - maybe collecting some short lived loaders - but not enough to get the VM into clear waters. I think this may be an issue today already. What is unclear to me is when it would be just better to give up and throw an OOM. To motivate the customer to increase the limits. > > > Which thread exactly gets the OOM if the VM hovers that close to the limit does not really matter. But you write "This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM." - so we could get OOMs even if most of the Metaspace were vacant? This only can happen if, between (4) and (6), other threads not only allocate metaspace, but also then loose the loaders used for those allocations, to late for the GC at (4) to collect them but before (5). Collecting them would require another GC. > > Right, and that is indeed what the test does. It loads chunks of 1000 classes and releases them, assuming that surely after releasing them, I can allocate more classes. Unless of course starvation ruins the day. > > > In other words, the contract is that we only throw an OOM if we really tried everything, but since the effects of the first GC are "stale" it does not count as try? > > The previous contract was that we try to allocate again after a full GC, and if that fails we give up. The issue is that this guarantee allows the GC to free up 99% of metaspace, yet still fail the allocation due to races with other threads doing the same thing. So at any given point, it might be that only 1% of metadata is reachable, yet an OOM can be produced if you are "unlucky". > > > Do you think this is a realistic problem? > > It is realistic enough that one stress test has failed in the real world. Yet I don't think any application out there will run into any issue. But I prefer having a sound solution where we can know that and not rely on probability. > > > Do I understand your patch right in that you divide allocations in two priority classes, add another lock, MetaspaceCritical_lock, which blocks normal allocations as long as critical allocations are queued? > > Yes, that's exactly right. > > > Sorry if I am slow :) > > Not at all! > > > One problem I see is that Metaspace::purge is not the full purge. Reclaiming metaspace happens in two stages: > > ``` > > 1. in CLDG::purge, we delete all `ClassLoaderMetaspace` objects belonging to dead loaders. This releases all their metaspace to the freelists, optionally uncommitting portions of it (since JEP387). > > > > 2. in Metaspace::purge, we go through Metaspace and munmap any mappings which are now completely vacant. > > ``` > > > > > > The metaspace pressure release already happens in (1), so any concurrent thread allocating will benefit already. > > Ah. I thought it was all done in 2. I can move the Big Fat Lock to cover all of CLDG::purge instead. What do you think? It just needs to cover the entire thing basically. Why not just cover the whole synchronous GC collect call? I'd put that barrier up as early as possible, to prevent as many threads as possible from entering the more expensive fail path. At that point we know we are near exhaustion. Any thread allocating could just as well wait inside MetaspaceArena::allocate. If the GC succeeds in releasing lots of memory, they will not have been disturbed much. > > > Why do we even need a queue? Why could we not just let the first thread attempting a synchronous gc block metaspace allocation path for all threads, including others running into a limit, until the gc is finished and it had its first-allocation-right served? > > Each "critical" allocation rides on one particular GC cycle, that denotes the make-or-break point of the allocation. I feel like I should know this, but if multiple threads enter satisfy_failed_metadata_allocation around the same time and call a synchronous collect(), they would wait on the same GC, right? They won't start individual GCs for each thread? > In order to prevent starvation, we have to satisfy all critical allocations who have their make-or-break GC cycle associated with the current purge() operation, before we release the lock in purge(), letting new allocations in, or we will rely on luck again. However, among the pending critical allocations, they will all possibly have different make-or-break GC cycles associated with them. So in purge() some of them need to be satisfied, and others do not, yet can happily get their allocations satisfied opportunistically if possible. So we need to make sure they are ordered somehow, such that the earliest arriving pending critical allocations are satisfied first, before subsequent critical allocations (possibly waiting for a later GC), or we can get premature OOM situations again, where a thread releases a bunch of memory, expecting to be able to allocate, yet fails due to races with various threads. > The queue basically ensures the ordering of critical allocation satisfaction is sound, so that the pending critical allocations with the associated make-or-break GC being the one running purge(), are satisfied first, before satisfying (opportunistically) other critical allocations, that are really waiting for the next GC to happen. I still don't get why the order of the critical allocations matter. I understand that even with your barrier, multiple threads can fail the initial allocation, enter the "satisfy_failed_metadata_allocation()" path, and now their allocation count as critical since if they fail again they will throw an OOM. But why does the order of the critical allocations among themselves matter? Why not just let the critical allocations trickle out unordered? Is the relation to the GC cycle not arbitrary? > > Thanks, > /Erik > We need an "erik" pr command :) Just FYI, I have very vague plans to extend usage of the metaspace allocator to other areas. To get back the cost of implementation. Eg one candidate may be replacement of the current resource areas, which are just more primitive arena based allocators. This is very vague and not a high priority, but I am a bit interested in keeping the coding generic if its not too much effort. But I don't see your patch causing any problems there. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/2289 From coleenp at openjdk.java.net Fri Jan 29 14:05:43 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 29 Jan 2021 14:05:43 GMT Subject: RFR: 8260630: Templatize literal_size In-Reply-To: <5sPGLrCapTTPbCklqP93lId2uqrOw343_WFDlMaQv-I=.193b309c-13c7-41c1-9a1d-fae471d5c6c4@github.com> References: <5sPGLrCapTTPbCklqP93lId2uqrOw343_WFDlMaQv-I=.193b309c-13c7-41c1-9a1d-fae471d5c6c4@github.com> Message-ID: <5-7udNz2v9LPTq9lgVLv3XoLozt_qr9JtCJZMccg8dM=.ea9456a3-9fe2-4e44-8951-fd83e7aa516d@github.com> On Fri, 29 Jan 2021 08:44:51 GMT, Kim Barrett wrote: > Please review a couple of small cleanups in Hashtable support. > > (1) Replace some "default" overloads for literal_size with a template. This > makes it easier to add new Hashtable value types whose sizes aren't > interesting for statistics printout. > > (2) Trivial change to remove no longer used instantiation of Hashtable > support for oop values. > > Testing: > mach5 tier1 Looks good! src/hotspot/share/utilities/hashtable.cpp line 241: > 239: } > 240: > 241: #ifndef PRODUCT I wrote that. Thanks for fixing this! src/hotspot/share/utilities/hashtable.cpp line 120: > 118: } > 119: > 120: static int literal_size(oop obj) { Is literal_size(oop) still needed? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2310 From iklam at openjdk.java.net Fri Jan 29 14:26:03 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 29 Jan 2021 14:26:03 GMT Subject: RFR: 8260471: Change SystemDictionary::X_klass calls to vmClasses::X_klass [v2] In-Reply-To: References: Message-ID: > This is the second step of https://github.com/openjdk/jdk/pull/2246 (8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp). These are mostly boiler-plate changes done by scripts. > > [1] Change calls like > > SystemDictionary::Object_klass() > SystemDictionary::Throwable_klass_is_loaded() > SystemDictionary::box_klass_type() > > to > > vmClasses::Object_klass() > vmClasses::Throwable_klass_is_loaded() > vmClasses::box_klass_type() > > [2] Remove unnecessary inclusion of systemDictionary.hpp (replace with vmClasses.hpp if necessary). In some cases, I have to add signature.hpp to some files, which only indirectly included signature.hpp through systemDictionary.hpp. > > [3] In the previous PR, I incorrectly used the enum name `VMClassID`. This PR changes it to `vmClassID` to match the existing use of `vmSymbolID` and `vmIntrinsicID`. > > Due to the refactoring of these two PRs, the number of HotSpot .o files that include systemDictionary.hpp decreases from 491 to 91. HotSpot build time is reduced by about 2% > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > Review Notes: if you don't want to scroll through 185 files, you may want to try: > > curl https://github.com/openjdk/jdk/compare/1de3c554477497d1ceee573180940e8d38c364ee...e2f77252c8b3edd4d0071cfc014290568a16de9d.diff | \ > grep -v '^[+-][+-][+-]' | grep '^[+-]' Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: added missing #include systemDictionary.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2301/files - new: https://git.openjdk.java.net/jdk/pull/2301/files/e2f77252..e1a09411 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2301&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2301&range=00-01 Stats: 8 lines in 8 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2301/head:pull/2301 PR: https://git.openjdk.java.net/jdk/pull/2301 From kbarrett at openjdk.java.net Fri Jan 29 14:34:46 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 29 Jan 2021 14:34:46 GMT Subject: RFR: 8260630: Templatize literal_size In-Reply-To: <5-7udNz2v9LPTq9lgVLv3XoLozt_qr9JtCJZMccg8dM=.ea9456a3-9fe2-4e44-8951-fd83e7aa516d@github.com> References: <5sPGLrCapTTPbCklqP93lId2uqrOw343_WFDlMaQv-I=.193b309c-13c7-41c1-9a1d-fae471d5c6c4@github.com> <5-7udNz2v9LPTq9lgVLv3XoLozt_qr9JtCJZMccg8dM=.ea9456a3-9fe2-4e44-8951-fd83e7aa516d@github.com> Message-ID: On Fri, 29 Jan 2021 14:02:12 GMT, Coleen Phillimore wrote: >> Please review a couple of small cleanups in Hashtable support. >> >> (1) Replace some "default" overloads for literal_size with a template. This >> makes it easier to add new Hashtable value types whose sizes aren't >> interesting for statistics printout. >> >> (2) Trivial change to remove no longer used instantiation of Hashtable >> support for oop values. >> >> Testing: >> mach5 tier1 > > src/hotspot/share/utilities/hashtable.cpp line 120: > >> 118: } >> 119: >> 120: static int literal_size(oop obj) { > > Is literal_size(oop) still needed? It's used by literal_size(WeakHandle). ------------- PR: https://git.openjdk.java.net/jdk/pull/2310 From eosterlund at openjdk.java.net Fri Jan 29 16:56:44 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 29 Jan 2021 16:56:44 GMT Subject: RFR: 8259643: ZGC can return metaspace OOM prematurely [v2] In-Reply-To: References: <7ZKX9hzE8xoqiDrvVu6iPiqf9y3U5mRDrl_QVhKaWDo=.58c6cbea-eec4-48ef-9a41-e8cdb5356c20@github.com> <3UDe0d-AIFxOb5CWce7yStNyzXpAC4A5yq8FxQr-s8w=.f5ea6d6f-168e-43fe-8c85-1ff353e98008@github.com> Message-ID: On Fri, 29 Jan 2021 11:23:30 GMT, Thomas Stuefe wrote: >> Hi Thomas, >> >> Thanks for chiming in! I will reply inline. >> >>> Hi Erik, >>> >>> lets see if I understand the problem: >>> >>> 1 n threads allocate metaspace >>> 2 thread A gets an allocation error (not HWM but a hard limit) >>> 3 .. returns, (eventually) schedules a synchronous GC. >>> 4 .. gc runs, the CLDG is at some point purged, releases metaspace pressure >>> 5 other threads load classes, allocating metaspace concurrently, benefitting from the released pressure >>> 6 thread A reattempts allocation, fails again. >> >> That's the one. >> >>> This is normally not a problem, no? >> >> Indeed, and that was my gut feeling when the current handling was written. I wouldn't expect an actual application to ever hit this problem. Nevertheless, I think it's a soundness problem with completely unbounded starvation, even though it doesn't happen in real life. So I think I would still like to fix the issue. >> >> It is definitely a bit arbitrary though where we decide to draw the line of what we guarantee, and what the balance between exactness and maintainability should be. My aim is to try hard enough so we don't rely on luck (random sleeps) if a program that shouldn't be even close to OOM will fail or not, even though you have to be *very* unlucky for it to fail. But I am not interested in prefect guarantees either, down to the last allocation. My balance is that I allow throwing OOM prematurely if we are "really close" to being down to the last allocation OOM, but if you are not "really close", then no sleep in the world should cause a failure. >> >>> Which thread exactly gets the OOM if the VM hovers that close to the limit does not really matter. But you write "This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM." - so we could get OOMs even if most of the Metaspace were vacant? This only can happen if, between (4) and (6), other threads not only allocate metaspace, but also then loose the loaders used for those allocations, to late for the GC at (4) to collect them but before (5). Collecting them would require another GC. >> >> Right, and that is indeed what the test does. It loads chunks of 1000 classes and releases them, assuming that surely after releasing them, I can allocate more classes. Unless of course starvation ruins the day. >> >>> In other words, the contract is that we only throw an OOM if we really tried everything, but since the effects of the first GC are "stale" it does not count as try? >> >> The previous contract was that we try to allocate again after a full GC, and if that fails we give up. The issue is that this guarantee allows the GC to free up 99% of metaspace, yet still fail the allocation due to races with other threads doing the same thing. So at any given point, it might be that only 1% of metadata is reachable, yet an OOM can be produced if you are "unlucky". >> >>> Do you think this is a realistic problem? >> >> It is realistic enough that one stress test has failed in the real world. Yet I don't think any application out there will run into any issue. But I prefer having a sound solution where we can know that and not rely on probability. >> >>> Do I understand your patch right in that you divide allocations in two priority classes, add another lock, MetaspaceCritical_lock, which blocks normal allocations as long as critical allocations are queued? >> >> Yes, that's exactly right. >> >>> Sorry if I am slow :) >> >> Not at all! >> >>> One problem I see is that Metaspace::purge is not the full purge. Reclaiming metaspace happens in two stages: >>> >>> 1. in CLDG::purge, we delete all `ClassLoaderMetaspace` objects belonging to dead loaders. This releases all their metaspace to the freelists, optionally uncommitting portions of it (since JEP387). >>> >>> 2. in Metaspace::purge, we go through Metaspace and munmap any mappings which are now completely vacant. >>> >>> >>> The metaspace pressure release already happens in (1), so any concurrent thread allocating will benefit already. >> >> Ah. I thought it was all done in 2. I can move the Big Fat Lock to cover all of CLDG::purge instead. What do you think? It just needs to cover the entire thing basically. >> >>> Why do we even need a queue? Why could we not just let the first thread attempting a synchronous gc block metaspace allocation path for all threads, including others running into a limit, until the gc is finished and it had its first-allocation-right served? >> >> Each "critical" allocation rides on one particular GC cycle, that denotes the make-or-break point of the allocation. >> In order to prevent starvation, we have to satisfy all critical allocations who have their make-or-break GC cycle associated with the current purge() operation, before we release the lock in purge(), letting new allocations in, or we will rely on luck again. However, among the pending critical allocations, they will all possibly have different make-or-break GC cycles associated with them. So in purge() some of them need to be satisfied, and others do not, yet can happily get their allocations satisfied opportunistically if possible. So we need to make sure they are ordered somehow, such that the earliest arriving pending critical allocations are satisfied first, before subsequent critical allocations (possibly waiting for a later GC), or we can get premature OOM situations again, where a thread releases a bunch of memory, expecting to be able to allocate, yet fails due to races with various threads. >> The queue basically ensures the ordering of critical allocation satisfaction is sound, so that the pending critical allocations with the associated make-or-break GC being the one running purge(), are satisfied first, before satisfying (opportunistically) other critical allocations, that are really waiting for the next GC to happen. >> >> Thanks, >> >> >>> Thanks, Thomas > > Hi Erik, > > thanks for the extensive explanations! > > One issue with your patch just came to me: the block-on-allocate may be too early. `Metaspace::allocate()` is a bit hot. I wonder about the performance impact of pulling and releasing a lock on each atomar allocation, even if its uncontended. Ideally I'd like to keep this path as close to a simple pointer bump allocation as possible (which it isn't unfortunately). > > It is also not necessary: the majority of callers satisfy their allocation from already-committed arena local memory. So they are good and no thieves. We would block them unnecessary. I estimate only about 1:60 to 1:1000 calls would need that lock. > > Allocation happens (roughly) in these steps: > 1 try allocate from arena local free block list > 2 try allocate from arena local current chunk without newly committing memory > 3 try enlarge the chunk in place and/or commit more chunk memory and allocate from current chunk > 4 get a new chunk from the freelist > > (1) and (2) don't bother anyone. Hot path is typically (2). From (3) onward concurrently released memory could be used. So (1) and (2) can still happen before your block. > > All that happens inside `MetaspaceArena::allocate`: > > https://github.com/openjdk/jdk/blob/0675473486bc0ee321654d308b600874cf5ce41e/src/hotspot/share/memory/metaspace/metaspaceArena.cpp#L225 > > But code-wise (2) and (3) are a bit entangled, so the code would have to be massaged a bit to clearly express (2) from (3). > > Please find more remarks inline. > >> Hi Thomas, >> >> Thanks for chiming in! I will reply inline. >> >> > Hi Erik, >> > lets see if I understand the problem: >> > 1 n threads allocate metaspace >> > 2 thread A gets an allocation error (not HWM but a hard limit) >> > 3 .. returns, (eventually) schedules a synchronous GC. >> > 4 .. gc runs, the CLDG is at some point purged, releases metaspace pressure >> > 5 other threads load classes, allocating metaspace concurrently, benefitting from the released pressure >> > 6 thread A reattempts allocation, fails again. >> >> That's the one. >> >> > This is normally not a problem, no? >> >> Indeed, and that was my gut feeling when the current handling was written. I wouldn't expect an actual application to ever hit this problem. Nevertheless, I think it's a soundness problem with completely unbounded starvation, even though it doesn't happen in real life. So I think I would still like to fix the issue. >> >> It is definitely a bit arbitrary though where we decide to draw the line of what we guarantee, and what the balance between exactness and maintainability should be. My aim is to try hard enough so we don't rely on luck (random sleeps) if a program that shouldn't be even close to OOM will fail or not, even though you have to be _very_ unlucky for it to fail. But I am not interested in prefect guarantees either, down to the last allocation. My balance is that I allow throwing OOM prematurely if we are "really close" to being down to the last allocation OOM, but if you are not "really close", then no sleep in the world should cause a failure. > > I think I get this now. IIUC we have the problem that memory release happens delayed, and we carry around a baggage of "potentially free" memory which needs a collector run to materialize. So many threads jumping up and down and doing class loading and unloading drive up metaspace use rate and increase the "potentially free" overhead, right? So the thing is to time collector runs right. > > One concern I have is that if the customer runs with too tight a limit, we may bounce from full GC to full GC. Always scraping the barrel enough to just keep going - maybe collecting some short lived loaders - but not enough to get the VM into clear waters. I think this may be an issue today already. What is unclear to me is when it would be just better to give up and throw an OOM. To motivate the customer to increase the limits. > >> >> > Which thread exactly gets the OOM if the VM hovers that close to the limit does not really matter. But you write "This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM." - so we could get OOMs even if most of the Metaspace were vacant? This only can happen if, between (4) and (6), other threads not only allocate metaspace, but also then loose the loaders used for those allocations, to late for the GC at (4) to collect them but before (5). Collecting them would require another GC. >> >> Right, and that is indeed what the test does. It loads chunks of 1000 classes and releases them, assuming that surely after releasing them, I can allocate more classes. Unless of course starvation ruins the day. >> >> > In other words, the contract is that we only throw an OOM if we really tried everything, but since the effects of the first GC are "stale" it does not count as try? >> >> The previous contract was that we try to allocate again after a full GC, and if that fails we give up. The issue is that this guarantee allows the GC to free up 99% of metaspace, yet still fail the allocation due to races with other threads doing the same thing. So at any given point, it might be that only 1% of metadata is reachable, yet an OOM can be produced if you are "unlucky". >> >> > Do you think this is a realistic problem? >> >> It is realistic enough that one stress test has failed in the real world. Yet I don't think any application out there will run into any issue. But I prefer having a sound solution where we can know that and not rely on probability. >> >> > Do I understand your patch right in that you divide allocations in two priority classes, add another lock, MetaspaceCritical_lock, which blocks normal allocations as long as critical allocations are queued? >> >> Yes, that's exactly right. >> >> > Sorry if I am slow :) >> >> Not at all! >> >> > One problem I see is that Metaspace::purge is not the full purge. Reclaiming metaspace happens in two stages: >> > ``` >> > 1. in CLDG::purge, we delete all `ClassLoaderMetaspace` objects belonging to dead loaders. This releases all their metaspace to the freelists, optionally uncommitting portions of it (since JEP387). >> > >> > 2. in Metaspace::purge, we go through Metaspace and munmap any mappings which are now completely vacant. >> > ``` >> > >> > >> > The metaspace pressure release already happens in (1), so any concurrent thread allocating will benefit already. >> >> Ah. I thought it was all done in 2. I can move the Big Fat Lock to cover all of CLDG::purge instead. What do you think? It just needs to cover the entire thing basically. > > Why not just cover the whole synchronous GC collect call? I'd put that barrier up as early as possible, to prevent as many threads as possible from entering the more expensive fail path. At that point we know we are near exhaustion. Any thread allocating could just as well wait inside MetaspaceArena::allocate. If the GC succeeds in releasing lots of memory, they will not have been disturbed much. > >> >> > Why do we even need a queue? Why could we not just let the first thread attempting a synchronous gc block metaspace allocation path for all threads, including others running into a limit, until the gc is finished and it had its first-allocation-right served? >> >> Each "critical" allocation rides on one particular GC cycle, that denotes the make-or-break point of the allocation. > > I feel like I should know this, but if multiple threads enter satisfy_failed_metadata_allocation around the same time and call a synchronous collect(), they would wait on the same GC, right? They won't start individual GCs for each thread? > >> In order to prevent starvation, we have to satisfy all critical allocations who have their make-or-break GC cycle associated with the current purge() operation, before we release the lock in purge(), letting new allocations in, or we will rely on luck again. However, among the pending critical allocations, they will all possibly have different make-or-break GC cycles associated with them. So in purge() some of them need to be satisfied, and others do not, yet can happily get their allocations satisfied opportunistically if possible. So we need to make sure they are ordered somehow, such that the earliest arriving pending critical allocations are satisfied first, before subsequent critical allocations (possibly waiting for a later GC), or we can get premature OOM situations again, where a thread releases a bunch of memory, expecting to be able to allocate, yet fails due to races with various threads. >> The queue basically ensures the ordering of critical allocation satisfaction is sound, so that the pending critical allocations with the associated make-or-break GC being the one running purge(), are satisfied first, before satisfying (opportunistically) other critical allocations, that are really waiting for the next GC to happen. > > I still don't get why the order of the critical allocations matter. I understand that even with your barrier, multiple threads can fail the initial allocation, enter the "satisfy_failed_metadata_allocation()" path, and now their allocation count as critical since if they fail again they will throw an OOM. But why does the order of the critical allocations among themselves matter? Why not just let the critical allocations trickle out unordered? Is the relation to the GC cycle not arbitrary? > >> >> Thanks, >> /Erik >> > > We need an "erik" pr command :) > > Just FYI, I have very vague plans to extend usage of the metaspace allocator to other areas. To get back the cost of implementation. Eg one candidate may be replacement of the current resource areas, which are just more primitive arena based allocators. This is very vague and not a high priority, but I am a bit interested in keeping the coding generic if its not too much effort. But I don't see your patch causing any problems there. > > Cheers, Thomas Hi Thomas, Thanks for having a look at this. > Hi Erik, > > thanks for the extensive explanations! > > One issue with your patch just came to me: the block-on-allocate may be too early. `Metaspace::allocate()` is a bit hot. I wonder about the performance impact of pulling and releasing a lock on each atomar allocation, even if its uncontended. Ideally I'd like to keep this path as close to a simple pointer bump allocation as possible (which it isn't unfortunately). I have a global flag that denotes there being at least 1 critical allocation in the system. It is set by the first critical allocation, and cleared by the GC if all critical allocations could be satisfied. The global lock is only taken in Metaspace::allocate() if said flag is on. Normal apps should never see this flag being on. So the only overhead in the common case is to check the flag and see that no locking is required. I think that should be fast enough, right? And when you are in the critical mode, you obviously have more to worry about than lock contention, in terms of how the system is performing. > It is also not necessary: the majority of callers satisfy their allocation from already-committed arena local memory. So they are good and no thieves. We would block them unnecessary. I estimate only about 1:60 to 1:1000 calls would need that lock. > > Allocation happens (roughly) in these steps: > 1 try allocate from arena local free block list > 2 try allocate from arena local current chunk without newly committing memory > 3 try enlarge the chunk in place and/or commit more chunk memory and allocate from current chunk > 4 get a new chunk from the freelist > > (1) and (2) don't bother anyone. Hot path is typically (2). From (3) onward concurrently released memory could be used. So (1) and (2) can still happen before your block. > > All that happens inside `MetaspaceArena::allocate`: > > https://github.com/openjdk/jdk/blob/0675473486bc0ee321654d308b600874cf5ce41e/src/hotspot/share/memory/metaspace/metaspaceArena.cpp#L225 > > But code-wise (2) and (3) are a bit entangled, so the code would have to be massaged a bit to clearly express (2) from (3). It might be possible to move it to a less hot path as you propose, but given that the fast path doesn't take said lock unless anyone really has critical allocations in the system, I don't think we need to worry about that. But if you still have performance concerns, I am open to suggestions of course. > Please find more remarks inline. > > > Hi Thomas, > > Thanks for chiming in! I will reply inline. > > > Hi Erik, > > > lets see if I understand the problem: > > > 1 n threads allocate metaspace > > > 2 thread A gets an allocation error (not HWM but a hard limit) > > > 3 .. returns, (eventually) schedules a synchronous GC. > > > 4 .. gc runs, the CLDG is at some point purged, releases metaspace pressure > > > 5 other threads load classes, allocating metaspace concurrently, benefitting from the released pressure > > > 6 thread A reattempts allocation, fails again. > > > > > > That's the one. > > > This is normally not a problem, no? > > > > > > Indeed, and that was my gut feeling when the current handling was written. I wouldn't expect an actual application to ever hit this problem. Nevertheless, I think it's a soundness problem with completely unbounded starvation, even though it doesn't happen in real life. So I think I would still like to fix the issue. > > It is definitely a bit arbitrary though where we decide to draw the line of what we guarantee, and what the balance between exactness and maintainability should be. My aim is to try hard enough so we don't rely on luck (random sleeps) if a program that shouldn't be even close to OOM will fail or not, even though you have to be _very_ unlucky for it to fail. But I am not interested in prefect guarantees either, down to the last allocation. My balance is that I allow throwing OOM prematurely if we are "really close" to being down to the last allocation OOM, but if you are not "really close", then no sleep in the world should cause a failure. > > I think I get this now. IIUC we have the problem that memory release happens delayed, and we carry around a baggage of "potentially free" memory which needs a collector run to materialize. So many threads jumping up and down and doing class loading and unloading drive up metaspace use rate and increase the "potentially free" overhead, right? So the thing is to time collector runs right. Exactly. > One concern I have is that if the customer runs with too tight a limit, we may bounce from full GC to full GC. Always scraping the barrel enough to just keep going - maybe collecting some short lived loaders - but not enough to get the VM into clear waters. I think this may be an issue today already. What is unclear to me is when it would be just better to give up and throw an OOM. To motivate the customer to increase the limits. Right - this is a bit of a philosophical one. There is always a balance there between precision, code complexity, and when to put the VM out of its misery when it is performing poorly. We deal with the same trade-off really with heap allocations, which is why I am also solving the starvation problem in pretty much the same way: with a queue satisfied by the GC, and locking out starvation. Then we throw OOM in fairly similar conditions. What they have in common is that when they throw, we will have a live portion of metaspace that is "pretty much" full, and there is no point in continuing, while allowing unfortunate timings on a less full (in terms of temporal liveness) metaspace to always succeed. One might argue that the trade-off should be moved in some direction, and that it is okay for it to be more or less exact, but I was hoping that by doing the same dance that heap OOM situations do, we can at least follow a trade-off that is pretty well established and has worked pretty well for heap OOM situations for many years. And I think heap OOM situations in the wild are far more common than metaspace OOM, so I don't think that the metaspace OOM mechanism needs to do better than what the heap OOM mechanism does. If that makes sense. > > > Which thread exactly gets the OOM if the VM hovers that close to the limit does not really matter. But you write "This can cause a situation where almost the entire metaspace is unreachable from roots, yet we throw OOM." - so we could get OOMs even if most of the Metaspace were vacant? This only can happen if, between (4) and (6), other threads not only allocate metaspace, but also then loose the loaders used for those allocations, to late for the GC at (4) to collect them but before (5). Collecting them would require another GC. > > > > > > Right, and that is indeed what the test does. It loads chunks of 1000 classes and releases them, assuming that surely after releasing them, I can allocate more classes. Unless of course starvation ruins the day. > > > In other words, the contract is that we only throw an OOM if we really tried everything, but since the effects of the first GC are "stale" it does not count as try? > > > > > > The previous contract was that we try to allocate again after a full GC, and if that fails we give up. The issue is that this guarantee allows the GC to free up 99% of metaspace, yet still fail the allocation due to races with other threads doing the same thing. So at any given point, it might be that only 1% of metadata is reachable, yet an OOM can be produced if you are "unlucky". > > > Do you think this is a realistic problem? > > > > > > It is realistic enough that one stress test has failed in the real world. Yet I don't think any application out there will run into any issue. But I prefer having a sound solution where we can know that and not rely on probability. > > > Do I understand your patch right in that you divide allocations in two priority classes, add another lock, MetaspaceCritical_lock, which blocks normal allocations as long as critical allocations are queued? > > > > > > Yes, that's exactly right. > > > Sorry if I am slow :) > > > > > > Not at all! > > > One problem I see is that Metaspace::purge is not the full purge. Reclaiming metaspace happens in two stages: > > > ``` > > > 1. in CLDG::purge, we delete all `ClassLoaderMetaspace` objects belonging to dead loaders. This releases all their metaspace to the freelists, optionally uncommitting portions of it (since JEP387). > > > > > > 2. in Metaspace::purge, we go through Metaspace and munmap any mappings which are now completely vacant. > > > ``` > > > > > > > > > The metaspace pressure release already happens in (1), so any concurrent thread allocating will benefit already. > > > > > > Ah. I thought it was all done in 2. I can move the Big Fat Lock to cover all of CLDG::purge instead. What do you think? It just needs to cover the entire thing basically. > > Why not just cover the whole synchronous GC collect call? I'd put that barrier up as early as possible, to prevent as many threads as possible from entering the more expensive fail path. At that point we know we are near exhaustion. Any thread allocating could just as well wait inside MetaspaceArena::allocate. If the GC succeeds in releasing lots of memory, they will not have been disturbed much. Do you mean 1) why I don't hold the MetaspaceCritical_lock across the collect() call at the mutator side of the code, or 2) why I don't hold the MetaspaceCritical_lock across the entire GC cycle instead of purge? I think you meant 2), so will answer that: a) Keeping the lock across the entire GC cycle is rather problematic when it comes to constraining lock ranks. It would have to be above any lock ever needed in an entire GC cycle, yet we take a bunch of other locks that mutators hold at different point, interacting with class unloading. It would be very hard to find the right rank for this. b) The GC goes in and out of safepoints, and needs to sometimes block out safepoints. Holding locks in and out of safepoints while blocking in and out safepoints, is in my experience rather deadlock prone. c) There is no need to keep the lock across more than the operation that frees metaspace memory, which in a concurrent GC always happens when safepoints are blocked out. If a mutator succeeds during a concurrent GC due to finding memory in a local free list or something, while another allocation failed and needs a critical allocation, then that is absolutely fine, as the successful allocation is never what causes the failing allocation to fail. > > > Why do we even need a queue? Why could we not just let the first thread attempting a synchronous gc block metaspace allocation path for all threads, including others running into a limit, until the gc is finished and it had its first-allocation-right served? > > > > > > Each "critical" allocation rides on one particular GC cycle, that denotes the make-or-break point of the allocation. > > I feel like I should know this, but if multiple threads enter satisfy_failed_metadata_allocation around the same time and call a synchronous collect(), they would wait on the same GC, right? They won't start individual GCs for each thread? The rule we have in ZGC to ensure what we want in terms of OOM situations, is that GCs that are *requested* before an equivalent GC *starts*, can be satisfied with the same GC cycle. Let's go through what will likely happen in practice with my solution when you have, let's say 1000 concurrent calls to satisfy a failing metaspace allocation. 1. Thread 1 registers its allocation, sees it is the first one, and starts a metaspace GC. 2. GC starts running 3. Threads 2-999 register their allocations, and see that there was already a critical allocation before them. This causes them to wait for the GC to purge, opportunistically, riding on that first GC. 4. The GC satisfies allocations. For the sake of example, let's say that allocations 1-500 could be satisfied, but not the rest. 5. Threads 2-500 who were waiting for purge to finish, wake up, and run off happily with their satisfied allocations. 6. Threads 501-1000 wake up seeing that their allocations didn't get satisfied. They now stop being opportunistic, and request a gc each before finally giving up. 7. The first GC cycle finishes. 8. Thread 1 wakes up after the entire first GC cycle is done and sees its satisfied allocation, happily running off with it. 9. The next GC cycle starts 10. The next GC cycle successfully satisfies metadata allocations for threads 501-750, but not the rest. 11. The entire next GC cycle finishes, satisfying the GC requested by threads 2-1000, as they all *requested* a metaspace GC, *before* it started running. Therefore, no further GC will run. 12. Threads 501-750 wake up, happily running off with their satisfied allocations. 13. Threads 751-1000 wake up, grumpy about the lack of memory after their GC. They are all gonna throw. So basically, if they can all get satisfied with 1 GC, then 1 GC will be enough. But we won't throw until a thread has had a full GC run *after* it was requested, but multiple threads can ride on the same GC there. In this example, threads 2-1000 all ride on the same GC. Note though, that we would never allow a GC that is already running to satisfy a GC request that comes in while the GC is already running, as we then wouldn't catch situations when a thread releases a lot of memory, and then expects it to be available just after. > > In order to prevent starvation, we have to satisfy all critical allocations who have their make-or-break GC cycle associated with the current purge() operation, before we release the lock in purge(), letting new allocations in, or we will rely on luck again. However, among the pending critical allocations, they will all possibly have different make-or-break GC cycles associated with them. So in purge() some of them need to be satisfied, and others do not, yet can happily get their allocations satisfied opportunistically if possible. So we need to make sure they are ordered somehow, such that the earliest arriving pending critical allocations are satisfied first, before subsequent critical allocations (possibly waiting for a later GC), or we can get premature OOM situations again, where a thread releases a bunch of memory, expecting to be able to allocate, yet fails due to races with various threads. > > The queue basically ensures the ordering of critical allocation satisfaction is sound, so that the pending critical allocations with the associated make-or-break GC being the one running purge(), are satisfied first, before satisfying (opportunistically) other critical allocations, that are really waiting for the next GC to happen. > > I still don't get why the order of the critical allocations matter. I understand that even with your barrier, multiple threads can fail the initial allocation, enter the "satisfy_failed_metadata_allocation()" path, and now their allocation count as critical since if they fail again they will throw an OOM. But why does the order of the critical allocations among themselves matter? Why not just let the critical allocations trickle out unordered? Is the relation to the GC cycle not arbitrary? If we don't preserve the order, we would miss situations when a thread releases a large chunk of metaspace (e.g. by releasing a class loader reference), and then expects that memory to be available. An allocation from a critical allocation that is associated with a subsequent GC, could starve a thread that is associated with the current GC cycle, hence causing a premature OOM for that thread, while not really needing that allocation until next GC cycle, while doing it in the right order would satisfy both allocations. One might argue it might be okay to throw in such a scenario with an unordered solution. We are pretty close to running out of memory anyway I guess. But I'm not really sure what such a solution would look like in more detail, and thought writing this little list was easy enough, and for me easier to reason about, partially because we do the same dance in the GC to deal with heap OOM, which has been a success. Thanks, ^--- I know this will be treated as a PR bot command, but I can't give up on my slash! > > Thanks, > > /Erik > > We need an "erik" pr command :) Indeed. > Just FYI, I have very vague plans to extend usage of the metaspace allocator to other areas. To get back the cost of implementation. Eg one candidate may be replacement of the current resource areas, which are just more primitive arena based allocators. This is very vague and not a high priority, but I am a bit interested in keeping the coding generic if its not too much effort. But I don't see your patch causing any problems there. That sounds very interesting. We had internal discussions about riding on the MetaspaceExpand lock which I believe would also work, but thought this really ought to be a separate thing so that we don't tie ourselves too tight to the internal implementation of the allocator. Given that you might want to use the allocator for other stuff, it sounds like that is indeed the right choice. > Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/2289 From kvn at openjdk.java.net Fri Jan 29 17:28:44 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 29 Jan 2021 17:28:44 GMT Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 13:01:07 GMT, Dong Bo wrote: > This is a typo introduced by JDK-8255949. > Compiler will generate `ushr` for shifting right and accumulating four short integers. > It produces wrong results for specific case. The instruction should be `usra`. Someone familiar with Aarch64 assembler have to review this before it is approved for JDK 16. ------------- PR: https://git.openjdk.java.net/jdk16/pull/136 From iveresov at openjdk.java.net Fri Jan 29 18:24:42 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 29 Jan 2021 18:24:42 GMT Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 13:01:07 GMT, Dong Bo wrote: > This is a typo introduced by JDK-8255949. > Compiler will generate `ushr` for shifting right and accumulating four short integers. > It produces wrong results for specific case. The instruction should be `usra`. Marked as reviewed by iveresov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/136 From dlong at openjdk.java.net Fri Jan 29 20:11:42 2021 From: dlong at openjdk.java.net (Dean Long) Date: Fri, 29 Jan 2021 20:11:42 GMT Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 13:01:07 GMT, Dong Bo wrote: > This is a typo introduced by JDK-8255949. > Compiler will generate `ushr` for shifting right and accumulating four short integers. > It produces wrong results for specific case. The instruction should be `usra`. Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/136 From dlong at openjdk.java.net Fri Jan 29 20:26:48 2021 From: dlong at openjdk.java.net (Dean Long) Date: Fri, 29 Jan 2021 20:26:48 GMT Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 20:08:36 GMT, Dean Long wrote: >> This is a typo introduced by JDK-8255949. >> Compiler will generate `ushr` for shifting right and accumulating four short integers. >> It produces wrong results for specific case. The instruction should be `usra`. > > Marked as reviewed by dlong (Reviewer). Why didn't the testing for JDK-8255949 catch this? Do you need to fix the regression test too? ------------- PR: https://git.openjdk.java.net/jdk16/pull/136 From kvn at openjdk.java.net Fri Jan 29 20:33:46 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 29 Jan 2021 20:33:46 GMT Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 20:24:05 GMT, Dean Long wrote: >> Marked as reviewed by dlong (Reviewer). > > Why didn't the testing for JDK-8255949 catch this? Do you need to fix the regression test too? Yes, we need regression test for this fix. Or modify existing one to catch it. ------------- PR: https://git.openjdk.java.net/jdk16/pull/136 From dongbo at openjdk.java.net Sat Jan 30 05:07:08 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Sat, 30 Jan 2021 05:07:08 GMT Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers [v2] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 20:31:16 GMT, Vladimir Kozlov wrote: >> Why didn't the testing for JDK-8255949 catch this? Do you need to fix the regression test too? > > Yes, we need regression test for this fix. Or modify existing one to catch it. Did not run local tests for small loops in JDK-8255949. Updated a test for all shift and accumulating operations which can catch this. ------------- PR: https://git.openjdk.java.net/jdk16/pull/136 From dongbo at openjdk.java.net Sat Jan 30 05:07:08 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Sat, 30 Jan 2021 05:07:08 GMT Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers [v2] In-Reply-To: References: Message-ID: > This is a typo introduced by JDK-8255949. > Compiler will generate `ushr` for shifting right and accumulating four short integers. > It produces wrong results for specific case. The instruction should be `usra`. Dong Bo has updated the pull request incrementally with two additional commits since the last revision: - fix trailing whitespace - add tests for shift right and accumulate ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/136/files - new: https://git.openjdk.java.net/jdk16/pull/136/files/d97281ab..f212c5e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=00-01 Stats: 196 lines in 1 file changed: 196 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/136.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/136/head:pull/136 PR: https://git.openjdk.java.net/jdk16/pull/136 From kbarrett at openjdk.java.net Sat Jan 30 09:59:40 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 30 Jan 2021 09:59:40 GMT Subject: RFR: 8260630: Templatize literal_size In-Reply-To: <1yn7PxkacDG7AsiY2bWKOxkADdmDlBnVb4LK9cMxcAQ=.b5a85c88-761b-4971-88c2-1993690c94ba@github.com> References: <5sPGLrCapTTPbCklqP93lId2uqrOw343_WFDlMaQv-I=.193b309c-13c7-41c1-9a1d-fae471d5c6c4@github.com> <1yn7PxkacDG7AsiY2bWKOxkADdmDlBnVb4LK9cMxcAQ=.b5a85c88-761b-4971-88c2-1993690c94ba@github.com> Message-ID: On Fri, 29 Jan 2021 09:09:46 GMT, Per Liden wrote: >> Please review a couple of small cleanups in Hashtable support. >> >> (1) Replace some "default" overloads for literal_size with a template. This >> makes it easier to add new Hashtable value types whose sizes aren't >> interesting for statistics printout. >> >> (2) Trivial change to remove no longer used instantiation of Hashtable >> support for oop values. >> >> Testing: >> mach5 tier1 > > Looks good to me! Thanks @pliden , @coleenp , @tschatzl for reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/2310 From kbarrett at openjdk.java.net Sat Jan 30 09:59:42 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 30 Jan 2021 09:59:42 GMT Subject: Integrated: 8260630: Templatize literal_size In-Reply-To: <5sPGLrCapTTPbCklqP93lId2uqrOw343_WFDlMaQv-I=.193b309c-13c7-41c1-9a1d-fae471d5c6c4@github.com> References: <5sPGLrCapTTPbCklqP93lId2uqrOw343_WFDlMaQv-I=.193b309c-13c7-41c1-9a1d-fae471d5c6c4@github.com> Message-ID: On Fri, 29 Jan 2021 08:44:51 GMT, Kim Barrett wrote: > Please review a couple of small cleanups in Hashtable support. > > (1) Replace some "default" overloads for literal_size with a template. This > makes it easier to add new Hashtable value types whose sizes aren't > interesting for statistics printout. > > (2) Trivial change to remove no longer used instantiation of Hashtable > support for oop values. > > Testing: > mach5 tier1 This pull request has now been integrated. Changeset: 67a34daf Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/67a34daf Stats: 14 lines in 1 file changed: 1 ins; 11 del; 2 mod 8260630: Templatize literal_size 8260629: Remove explicit instantiation of Hashtable with oop value Reviewed-by: pliden, tschatzl, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/2310 From aph at redhat.com Sat Jan 30 10:45:13 2021 From: aph at redhat.com (Andrew Haley) Date: Sat, 30 Jan 2021 10:45:13 +0000 Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers [v2] In-Reply-To: References: Message-ID: <4b6eff2a-6a74-24fb-84d3-84d0b53dc710@redhat.com> On 1/30/21 5:07 AM, Dong Bo wrote: > On Fri, 29 Jan 2021 20:31:16 GMT, Vladimir Kozlov wrote: > >>> Why didn't the testing for JDK-8255949 catch this? Do you need to fix the regression test too? >> >> Yes, we need regression test for this fix. Or modify existing one to catch it. > > Did not run local tests for small loops in JDK-8255949. > Updated a test for all shift and accumulating operations which can catch this. > > ------------- > > PR: https://git.openjdk.java.net/jdk16/pull/136 I don't understand. Looking at this: instruct vsrla4S_imm(vecD dst, vecD src, immI shift) %{ predicate(n->as_Vector()->length() == 4); match(Set dst (AddVS dst (URShiftVS src (RShiftCntV shift)))); ins_cost(INSN_COST); format %{ "usra $dst, $src, $shift\t# vector (4H)" %} ins_encode %{ int sh = (int)$shift$$constant; if (sh >= 16) { __ eor(as_FloatRegister($src$$reg), __ T8B, as_FloatRegister($src$$reg), as_FloatRegister($src$$reg)); } else { __ usra(as_FloatRegister($dst$$reg), __ T4H, as_FloatRegister($src$$reg), sh); } %} ins_pipe(vshift64_imm); %} What happens when the shift is >= 16? What happens to src and dst? -- 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 dongbo at openjdk.java.net Sun Jan 31 10:30:06 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Sun, 31 Jan 2021 10:30:06 GMT Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers [v3] In-Reply-To: References: Message-ID: > This is a typo introduced by JDK-8255949. > Compiler will generate `ushr` for shifting right and accumulating four short integers. > It produces wrong results for specific case. The instruction should be `usra`. Dong Bo has updated the pull request incrementally with one additional commit since the last revision: make empty ins_encode when shift >= 16 (chars) ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/136/files - new: https://git.openjdk.java.net/jdk16/pull/136/files/f212c5e6..b7ef8fb8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=01-02 Stats: 20 lines in 1 file changed: 0 ins; 16 del; 4 mod Patch: https://git.openjdk.java.net/jdk16/pull/136.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/136/head:pull/136 PR: https://git.openjdk.java.net/jdk16/pull/136 From dongbo at openjdk.java.net Sun Jan 31 10:34:40 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Sun, 31 Jan 2021 10:34:40 GMT Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers [v3] In-Reply-To: References: Message-ID: On Sat, 30 Jan 2021 05:01:09 GMT, Dong Bo wrote: >> Yes, we need regression test for this fix. Or modify existing one to catch it. > > Did not run local tests for small loops in JDK-8255949. > Updated a test for all shift and accumulating operations which can catch this. > _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_ > > On 1/30/21 5:07 AM, Dong Bo wrote: > > I don't understand. Looking at this: > > instruct vsrla4S_imm(vecD dst, vecD src, immI shift) %{ > predicate(n->as_Vector()->length() == 4); > match(Set dst (AddVS dst (URShiftVS src (RShiftCntV shift)))); > ins_cost(INSN_COST); > format %{ "usra $dst, $src, $shift\t# vector (4H)" %} > ins_encode %{ > int sh = (int)$shift$$constant; > if (sh >= 16) { > __ eor(as_FloatRegister($src$$reg), __ T8B, > as_FloatRegister($src$$reg), > as_FloatRegister($src$$reg)); > } else { > __ usra(as_FloatRegister($dst$$reg), __ T4H, > as_FloatRegister($src$$reg), sh); > } > %} > ins_pipe(vshift64_imm); > %} > > What happens when the shift is >= 16? What happens to src and dst? > > -- > 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 This was wrong, both src and dst should have the same value as before. Actually, when the shift is `>= 16`, the URShift is optimized to zero by the compiler. So we don't have a `vsrla4S_imm` match if `shift >= 16`, the wrong `eor` is not generated. Check the assembly code of the following test: # test public void shiftURightAccumulateChar() { for (int i = 0; i < count; i++) { charsD[i] = (char) (charsA[i] + (charsB[i] >>> 16)); } } # assembly code, the `shift` is gone, only `move` left 1.17% ? 0x0000ffff88075348: ldr q16, [x14,#16] ? 0x0000ffff8807534c: add x12, x19, x12 ? 0x0000ffff88075350: str q16, [x12,#16] 1.66% ? 0x0000ffff88075354: ldr q16, [x14,#32] ? 0x0000ffff88075358: str q16, [x12,#32] 2.03% ? 0x0000ffff8807535c: ldr q16, [x14,#48] ? 0x0000ffff88075360: str q16, [x12,#48] 1.39% ? 0x0000ffff88075364: ldr q16, [x14,#64] ? 0x0000ffff88075368: str q16, [x12,#64] ------------- PR: https://git.openjdk.java.net/jdk16/pull/136 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 From daniel.daugherty at oracle.com Mon Jan 11 13:59:51 2021 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 11 Jan 2021 13:59:51 -0000 Subject: JVMTI Class load callback not being called on Windows, but works on Linux In-Reply-To: <01C7DD0F-B495-465A-BF06-31CC28217FF6@oracle.com> References: <6b650f6d-4f7e-d75a-2cc1-ea96336256e5@gmail.com> <01C7DD0F-B495-465A-BF06-31CC28217FF6@oracle.com> Message-ID: <7d107085-b6cb-e36e-c977-5422884a2240@oracle.com> Redirecting to the serviceability-dev at ... alias since JVM/TI is maintained by the Serviceability team... Dan On 1/10/21 6:09 PM, Mikael Vidstedt wrote: > Just a control question: Are you *sure* asserts are actually enabled? Having actual application logic in an assert is normally a bad idea because if/when you compile the release/production version with asserts disabled the application behavior will change. > > Cheers, > Mikael > >> On Jan 10, 2021, at 8:33 AM, Charlie wrote: >> >> Hi, >> >> I have a working jvmti agent on Linux (Java(TM) SE Runtime Environment (build 1.8.0_271-b09)) that hooks the class load event. >> >> This same agent compiled for windows claims to work (all asserts pass), but my hook never gets called, is anyone able to tell me why? >> >> I register my callback like so: >> >> jint res = vm->GetEnv(reinterpret_cast(&jvmti), JVMTI_VERSION_1); >> if (res != JNI_OK || jvmti==nullptr) { >> fprintf(stderr,"Unable to get JVMTI!"); >> } >> assert(res == JVMTI_ERROR_NONE); >> >> jvmtiCapabilities capabilities = {0}; >> capabilities.can_retransform_classes=1; >> capabilities.can_generate_all_class_hook_events = 1; >> >> assert(jvmti->AddCapabilities(&capabilities) == JVMTI_ERROR_NONE); >> >> jvmtiEventCallbacks callbacks; >> memset(&callbacks,0,sizeof(callbacks)); >> callbacks.ClassFileLoadHook = &class_file_load_hook_handler; >> assert(jvmti->SetEventCallbacks(&callbacks, sizeof(callbacks)) == JVMTI_ERROR_NONE); >> assert(jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_CLASS_FILE_LOAD_HOOK, nullptr) == JVMTI_ERROR_NONE); >> >> The callback itself is as follows: >> >> static void JNICALL class_file_load_hook_handler( >> jvmtiEnv* jvmti, >> JNIEnv* env, >> jclass class_being_redefined, >> jobject loader, >> const char* name, >> jobject protection_domain, >> jint class_data_len, >> const unsigned char* class_data, >> jint* new_class_data_len, >> unsigned char** new_class_data >> ) { >> if (name == nullptr) { >> return; >> } >> >> printf("loaded %s\n",name); >> >> } >> >> (to clarify, all JNI functions in the lib work fine) >> >> The Windows machine's java version string is this: >> >> java version "1.8.0_271" >> Java(TM) SE Runtime Environment (build 1.8.0_271-b09) >> Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode) >>