From tobias.hartmann at oracle.com Mon Mar 6 08:26:55 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Mar 2017 09:26:55 +0100 Subject: OSR with value type arrays Message-ID: <589db343-ca9b-7e1f-3cdf-fca0f6a68598@oracle.com> Hi, please review this patch that fixes OSR with value type arrays and disables ValueTypePassFieldsAsArgs on non-x86_64 platforms: http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.09/ I also added the value type tests to the hotspot_compiler_3 test group. Thanks, Tobias From rwestrel at redhat.com Mon Mar 6 08:40:45 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 06 Mar 2017 09:40:45 +0100 Subject: OSR with value type arrays In-Reply-To: <589db343-ca9b-7e1f-3cdf-fca0f6a68598@oracle.com> References: <589db343-ca9b-7e1f-3cdf-fca0f6a68598@oracle.com> Message-ID: > http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.09/ Looks good to me. Why do we need this: 29 * @requires os.simpleArch == "x64" now that ValueTypePassFieldsAsArgsis false on 32 bit? Roland. From tobias.hartmann at oracle.com Mon Mar 6 08:50:18 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Mar 2017 09:50:18 +0100 Subject: OSR with value type arrays In-Reply-To: References: <589db343-ca9b-7e1f-3cdf-fca0f6a68598@oracle.com> Message-ID: <9200f64a-fb0a-aabc-60fd-8d7e689c57d2@oracle.com> Hi Roland, On 06.03.2017 09:40, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.09/ > > Looks good to me. Thanks for looking at this. > Why do we need this: > 29 * @requires os.simpleArch == "x64" > > now that ValueTypePassFieldsAsArgsis false on 32 bit? Forgot to mention this, the test still triggers crashes on 32-bit so I "quarantined" it until we fixed those problems. Thanks, Tobias > > Roland. > From rwestrel at redhat.com Mon Mar 6 08:55:38 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 06 Mar 2017 09:55:38 +0100 Subject: OSR with value type arrays In-Reply-To: <9200f64a-fb0a-aabc-60fd-8d7e689c57d2@oracle.com> References: <589db343-ca9b-7e1f-3cdf-fca0f6a68598@oracle.com> <9200f64a-fb0a-aabc-60fd-8d7e689c57d2@oracle.com> Message-ID: >> Why do we need this: >> 29 * @requires os.simpleArch == "x64" >> >> now that ValueTypePassFieldsAsArgsis false on 32 bit? > > Forgot to mention this, the test still triggers crashes on 32-bit so I > "quarantined" it until we fixed those problems. Ok. What kind of crashes: in the compiler, in compiled code or elsewhere? Roland. From tobias.hartmann at oracle.com Mon Mar 6 09:46:20 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Mar 2017 10:46:20 +0100 Subject: OSR with value type arrays In-Reply-To: References: <589db343-ca9b-7e1f-3cdf-fca0f6a68598@oracle.com> <9200f64a-fb0a-aabc-60fd-8d7e689c57d2@oracle.com> Message-ID: <05fbb0b6-c37f-67ac-b555-6bca4a8d14c3@oracle.com> On 06.03.2017 09:55, Roland Westrelin wrote: > Ok. What kind of crashes: in the compiler, in compiled code or > elsewhere? There are two problems (see attached hs_err files). Best regards, Tobias From tobias.hartmann at oracle.com Mon Mar 6 09:49:03 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Mar 2017 10:49:03 +0100 Subject: OSR with value type arrays In-Reply-To: <05fbb0b6-c37f-67ac-b555-6bca4a8d14c3@oracle.com> References: <589db343-ca9b-7e1f-3cdf-fca0f6a68598@oracle.com> <9200f64a-fb0a-aabc-60fd-8d7e689c57d2@oracle.com> <05fbb0b6-c37f-67ac-b555-6bca4a8d14c3@oracle.com> Message-ID: [Forgot attachments] On 06.03.2017 10:46, Tobias Hartmann wrote: > > > On 06.03.2017 09:55, Roland Westrelin wrote: >> Ok. What kind of crashes: in the compiler, in compiled code or >> elsewhere? > > There are two problems (see attached hs_err files). > > Best regards, > Tobias > From tobias.hartmann at oracle.com Mon Mar 6 09:50:10 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Mar 2017 10:50:10 +0100 Subject: OSR with value type arrays In-Reply-To: References: <589db343-ca9b-7e1f-3cdf-fca0f6a68598@oracle.com> <9200f64a-fb0a-aabc-60fd-8d7e689c57d2@oracle.com> <05fbb0b6-c37f-67ac-b555-6bca4a8d14c3@oracle.com> Message-ID: <279c775b-ac7d-48e9-793c-727b427c52a8@oracle.com> Seems like the hs_err files are removed from my email. Trying zip. On 06.03.2017 10:49, Tobias Hartmann wrote: > [Forgot attachments] > > On 06.03.2017 10:46, Tobias Hartmann wrote: >> >> >> On 06.03.2017 09:55, Roland Westrelin wrote: >>> Ok. What kind of crashes: in the compiler, in compiled code or >>> elsewhere? >> >> There are two problems (see attached hs_err files). >> >> Best regards, >> Tobias >> From tobias.hartmann at oracle.com Mon Mar 6 09:52:24 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Mar 2017 10:52:24 +0100 Subject: OSR with value type arrays In-Reply-To: <279c775b-ac7d-48e9-793c-727b427c52a8@oracle.com> References: <589db343-ca9b-7e1f-3cdf-fca0f6a68598@oracle.com> <9200f64a-fb0a-aabc-60fd-8d7e689c57d2@oracle.com> <05fbb0b6-c37f-67ac-b555-6bca4a8d14c3@oracle.com> <279c775b-ac7d-48e9-793c-727b427c52a8@oracle.com> Message-ID: Seems like all attachments are removed for some reason. I uploaded the files: http://cr.openjdk.java.net/~thartmann/tmp/ Sorry for the noise. On 06.03.2017 10:50, Tobias Hartmann wrote: > Seems like the hs_err files are removed from my email. Trying zip. > > On 06.03.2017 10:49, Tobias Hartmann wrote: >> [Forgot attachments] >> >> On 06.03.2017 10:46, Tobias Hartmann wrote: >>> >>> >>> On 06.03.2017 09:55, Roland Westrelin wrote: >>>> Ok. What kind of crashes: in the compiler, in compiled code or >>>> elsewhere? >>> >>> There are two problems (see attached hs_err files). >>> >>> Best regards, >>> Tobias >>> From f.giacherio at gmail.com Mon Mar 6 11:18:00 2017 From: f.giacherio at gmail.com (GIACHERIO Fabien) Date: Mon, 6 Mar 2017 12:18:00 +0100 Subject: Value Types - static fields are not assgined in value's constructors Message-ID: Hi everyone, I'm trying to execute some tests of the ValueTypeTestBench.java and i've noticed that the static field 's' of MyValue1 is never affected to the value of the integer x. The static method called in order to create the value is createDontInline(int, long). It seems that we can set a static field using a VALUE_FACTORY method, but we can not assign it in a constructor. Is it a normal behavior ? ____________________________________________ __ByValue final class MyValue1 { static int s; static final long sf = ValueTypeTestBench.rL; final int x; final long y; final MyValue2 v1; final MyValue2 v2; static final MyValue2 v3 = MyValue2.createInline(ValueTypeTestBench.rI, true); final int c; private MyValue1(int x, long y, MyValue2 v1, MyValue2 v2, int c) { s = x; this.x = x; this.y = y; this.v1 = v1; this.v2 = v2; this.c = c; } public static MyValue1 createDontInline(int x, long y) { return __Make MyValue1(x, y, MyValue2.createInline(x, true), MyValue2.createInline(x, false), ValueTypeTestBench.rI); } Best regards, Fabien GIACHERIO From tobias.hartmann at oracle.com Mon Mar 6 11:46:04 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Mar 2017 12:46:04 +0100 Subject: Value Types - static fields are not assgined in value's constructors In-Reply-To: References: Message-ID: <9aea9732-c45c-e227-c0d3-0c3b7a677a16@oracle.com> Hi Fabien, On 06.03.2017 12:18, GIACHERIO Fabien wrote: > Hi everyone, > > I'm trying to execute some tests of the ValueTypeTestBench.java and i've > noticed that the static field 's' of MyValue1 is never affected to the > value of the integer x. > > The static method called in order to create the value is > createDontInline(int, long). > > It seems that we can set a static field using a VALUE_FACTORY method, but > we can not assign it in a constructor. > > Is it a normal behavior ? Yes, that's normal. The constructor is not executed but the value type is directly created by vnew like this: public static compiler.valhalla.valuetypes.MyValue1 createDontInline(int, long); Code: 0: iload_0 1: lload_1 2: iload_0 3: iconst_1 4: invokestatic #39 // Method compiler/valhalla/valuetypes/MyValue2.createInline:(IZ)Qcompiler/valhalla/valuetypes/MyValue2; 7: iload_0 8: iconst_0 9: invokestatic #39 // Method compiler/valhalla/valuetypes/MyValue2.createInline:(IZ)Qcompiler/valhalla/valuetypes/MyValue2; 12: getstatic #44 // Field compiler/valhalla/valuetypes/ValueTypeTestBench.rI:I 15: vnew #48 // Method "":(IJQcompiler/valhalla/valuetypes/MyValue2;Qcompiler/valhalla/valuetypes/MyValue2;I)Qcompiler/valhalla/valuetypes/MyValue1; 18: vreturn Best regards, Tobias > > ____________________________________________ > > __ByValue final class MyValue1 { > static int s; > static final long sf = ValueTypeTestBench.rL; > final int x; > final long y; > final MyValue2 v1; > final MyValue2 v2; > static final MyValue2 v3 = > MyValue2.createInline(ValueTypeTestBench.rI, true); > final int c; > > private MyValue1(int x, long y, MyValue2 v1, MyValue2 v2, int c) { > s = x; > this.x = x; > this.y = y; > this.v1 = v1; > this.v2 = v2; > this.c = c; > } > > public static MyValue1 createDontInline(int x, long y) { > return __Make MyValue1(x, y, MyValue2.createInline(x, true), > MyValue2.createInline(x, false), ValueTypeTestBench.rI); > } > > > Best regards, > Fabien GIACHERIO > From tobias.hartmann at oracle.com Mon Mar 6 14:45:29 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 06 Mar 2017 14:45:29 +0000 Subject: hg: valhalla/valhalla/hotspot: Fixes OSR with value type arrays and disables ValueTypePassFieldsAsArgs on non-x86_64 platforms. Added VT tests to hotspot_compiler_3. Message-ID: <201703061445.v26EjTWa008821@aojmv0008.oracle.com> Changeset: 5dadede55f1c Author: thartmann Date: 2017-03-06 15:44 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/5dadede55f1c Fixes OSR with value type arrays and disables ValueTypePassFieldsAsArgs on non-x86_64 platforms. Added VT tests to hotspot_compiler_3. Reviewed-by: roland ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/cpu/ppc/vm/globals_ppc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/ci/ciArrayKlass.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! test/TEST.groups ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From karen.kinnear at oracle.com Wed Mar 8 19:34:29 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 8 Mar 2017 14:34:29 -0500 Subject: CFV: New Valhalla Committer: Lois Foltan Message-ID: I hereby nominate Lois Foltan (OpenJDK user name: lfoltan) to Committer role in Project Valhalla. Lois is actively working on * ClassDynamic support * MethodHandle tests for MVT 1.0 and has contributed support for generic specialization of boot loader classes Also, she is a jdk9 and jdk10 Committer. Votes are due by March 22, 2017 Only current Valhalla Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. thanks, Karen [1] http://openjdk.java.net/census# valhalla [2] http://openjdk.java.net/projects#committer-vote From brian.goetz at oracle.com Wed Mar 8 19:59:40 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 8 Mar 2017 19:59:40 +0000 Subject: CFV: New Valhalla Committer: Lois Foltan In-Reply-To: References: Message-ID: <40A5C69E-6FBD-4F6A-A7E9-228873C152AC@oracle.com> Vote: Yes > On Mar 8, 2017, at 7:34 PM, Karen Kinnear wrote: > > I hereby nominate Lois Foltan (OpenJDK user name: lfoltan) to Committer role in Project Valhalla. > > Lois is actively working on > * ClassDynamic support > * MethodHandle tests for MVT 1.0 > and has contributed support for generic specialization of boot loader classes > > Also, she is a jdk9 and jdk10 Committer. > > Votes are due by March 22, 2017 > > Only current Valhalla Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > thanks, > Karen > > [1] http://openjdk.java.net/census# valhalla > [2] http://openjdk.java.net/projects#committer-vote From john.r.rose at oracle.com Wed Mar 8 20:15:16 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 8 Mar 2017 20:15:16 +0000 Subject: CFV: New Valhalla Committer: Lois Foltan In-Reply-To: References: Message-ID: Vote: yes From frederic.parain at oracle.com Wed Mar 8 20:55:21 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 8 Mar 2017 15:55:21 -0500 Subject: CFV: New Valhalla Committer: Lois Foltan In-Reply-To: References: Message-ID: <0A4987F4-0E97-4E5F-B7FF-46A6118C5DF7@oracle.com> Vote: Yes Fred > On Mar 8, 2017, at 14:34, Karen Kinnear wrote: > > I hereby nominate Lois Foltan (OpenJDK user name: lfoltan) to Committer role in Project Valhalla. > > Lois is actively working on > * ClassDynamic support > * MethodHandle tests for MVT 1.0 > and has contributed support for generic specialization of boot loader classes > > Also, she is a jdk9 and jdk10 Committer. > > Votes are due by March 22, 2017 > > Only current Valhalla Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > thanks, > Karen > > [1] http://openjdk.java.net/census# valhalla > [2] http://openjdk.java.net/projects#committer-vote From maurizio.cimadamore at oracle.com Wed Mar 8 22:00:22 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 8 Mar 2017 22:00:22 +0000 Subject: CFV: New Valhalla Committer: Lois Foltan In-Reply-To: References: Message-ID: <866a111b-5049-d839-9109-3b38042f9530@oracle.com> Vote: yes! Maurizio On 08/03/17 19:34, Karen Kinnear wrote: > I hereby nominate Lois Foltan (OpenJDK user name: lfoltan) to Committer role in Project Valhalla. > > Lois is actively working on > * ClassDynamic support > * MethodHandle tests for MVT 1.0 > and has contributed support for generic specialization of boot loader classes > > Also, she is a jdk9 and jdk10 Committer. > > Votes are due by March 22, 2017 > > Only current Valhalla Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > thanks, > Karen > > [1] http://openjdk.java.net/census# valhalla > [2] http://openjdk.java.net/projects#committer-vote From karen.kinnear at oracle.com Wed Mar 8 22:24:40 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 8 Mar 2017 17:24:40 -0500 Subject: CFV: New Valhalla Committer: Lois Foltan In-Reply-To: References: Message-ID: <793EC331-F22B-4E94-800C-6836D3A55192@oracle.com> Vote: yes Karen > On Mar 8, 2017, at 2:34 PM, Karen Kinnear wrote: > > I hereby nominate Lois Foltan (OpenJDK user name: lfoltan) to Committer role in Project Valhalla. > > Lois is actively working on > * ClassDynamic support > * MethodHandle tests for MVT 1.0 > and has contributed support for generic specialization of boot loader classes > > Also, she is a jdk9 and jdk10 Committer. > > Votes are due by March 22, 2017 > > Only current Valhalla Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > thanks, > Karen > > [1] http://openjdk.java.net/census# valhalla > [2] http://openjdk.java.net/projects#committer-vote From tobias.hartmann at oracle.com Thu Mar 9 07:07:54 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 9 Mar 2017 08:07:54 +0100 Subject: CFV: New Valhalla Committer: Lois Foltan In-Reply-To: References: Message-ID: <27170e13-0ec5-917f-3e24-4d92c0f58493@oracle.com> Vote: yes Best regards, Tobias On 08.03.2017 20:34, Karen Kinnear wrote: > I hereby nominate Lois Foltan (OpenJDK user name: lfoltan) to Committer role in Project Valhalla. > > Lois is actively working on > * ClassDynamic support > * MethodHandle tests for MVT 1.0 > and has contributed support for generic specialization of boot loader classes > > Also, she is a jdk9 and jdk10 Committer. > > Votes are due by March 22, 2017 > > Only current Valhalla Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > thanks, > Karen > > [1] http://openjdk.java.net/census# valhalla > [2] http://openjdk.java.net/projects#committer-vote > From david.simms at oracle.com Thu Mar 9 08:29:32 2017 From: david.simms at oracle.com (David Simms) Date: Thu, 9 Mar 2017 09:29:32 +0100 Subject: CFV: New Valhalla Committer: Lois Foltan In-Reply-To: References: Message-ID: <275e22c6-fe36-913e-443b-d70e702dade0@oracle.com> Vote: yes ! /David Simms On 08/03/17 20:34, Karen Kinnear wrote: > I hereby nominate Lois Foltan (OpenJDK user name: lfoltan) to Committer role in Project Valhalla. > > Lois is actively working on > * ClassDynamic support > * MethodHandle tests for MVT 1.0 > and has contributed support for generic specialization of boot loader classes > > Also, she is a jdk9 and jdk10 Committer. > > Votes are due by March 22, 2017 > > Only current Valhalla Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > thanks, > Karen > > [1] http://openjdk.java.net/census# valhalla > [2] http://openjdk.java.net/projects#committer-vote From rwestrel at redhat.com Thu Mar 9 08:58:57 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 09 Mar 2017 09:58:57 +0100 Subject: Some incremental inlining fixes Message-ID: http://cr.openjdk.java.net/~roland/valhalla/incrementalinlining2/webrev.00/ With incremental inlining, an inlined call that returns a value type can be first compiled as a call. The compiler then expects a ptr to the result to be returned. When the method is inlined incrementally, it thus has to return a ptr and so allocates an object for the value type. We then rely on escape analysis + scalarization to eliminate the allocation and obtain the same result we would get with parse time inlining. EA + scalarization doesn't support value type ptrs. This change tweaks the code so it is now enabled for them. Sometimes, a value type allocation is not eliminated because it is referenced by a value type node itself referenced by a safepoint. The change in SafePointNode::Ideal fixes that. The change also includes some fixes to replay inlining to record static fields that are value types and replay them. Roland. From tobias.hartmann at oracle.com Thu Mar 9 09:57:32 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 9 Mar 2017 10:57:32 +0100 Subject: Some incremental inlining fixes In-Reply-To: References: Message-ID: <3343408a-62ad-0f67-c5be-69decbf9b764@oracle.com> Hi Roland, On 09.03.2017 09:58, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/valhalla/incrementalinlining2/webrev.00/ > > With incremental inlining, an inlined call that returns a value type can > be first compiled as a call. The compiler then expects a ptr to the > result to be returned. When the method is inlined incrementally, it thus > has to return a ptr and so allocates an object for the value type. We > then rely on escape analysis + scalarization to eliminate the allocation > and obtain the same result we would get with parse time inlining. EA + > scalarization doesn't support value type ptrs. This change tweaks the > code so it is now enabled for them. Looks good to me. > Sometimes, a value type allocation > is not eliminated because it is referenced by a value type node itself > referenced by a safepoint. The change in SafePointNode::Ideal fixes > that. The comment in SafePointNode::Ideal is a bit misleading because "a valid object input" could also mean that the ValueTypeNode has an object *field* input. Maybe change it to: 1147 // An allocated ValueTypeNode in the debug info? 1148 // Reference the oop directly. Helps removal of useless value 1149 // type allocations with incremental inlining. You don't need to send an updated webrev. > The change also includes some fixes to replay inlining to record > static fields that are value types and replay them. Very nice! Thanks, Tobias From vladimir.x.ivanov at oracle.com Thu Mar 9 11:57:44 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 9 Mar 2017 14:57:44 +0300 Subject: CFV: New Valhalla Committer: Lois Foltan In-Reply-To: References: Message-ID: Vote: yes Best regards, Vladimir Ivanov On 3/8/17 10:34 PM, Karen Kinnear wrote: > I hereby nominate Lois Foltan (OpenJDK user name: lfoltan) to Committer role in Project Valhalla. > From vladimir.x.ivanov at oracle.com Thu Mar 9 11:57:59 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 9 Mar 2017 14:57:59 +0300 Subject: CFV: New Valhalla Committer: Stanislav Smirnov In-Reply-To: References: Message-ID: <5352e4f1-ffc7-78c0-8dab-c96427f181e1@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/23/17 7:07 PM, Karen Kinnear wrote: > I hereby nominate Stanislav Smirnov (email: stanislav.smirnov at oracle.com ) to Committer role in Project Valhalla. From zoltan.majo at oracle.com Thu Mar 9 14:34:08 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 9 Mar 2017 15:34:08 +0100 Subject: CFV: New Valhalla Committer: Lois Foltan In-Reply-To: References: Message-ID: Vote: yes. Best regards, Zoltan On 03/08/2017 08:34 PM, Karen Kinnear wrote: > I hereby nominate Lois Foltan (OpenJDK user name: lfoltan) to Committer role in Project Valhalla. > > Lois is actively working on > * ClassDynamic support > * MethodHandle tests for MVT 1.0 > and has contributed support for generic specialization of boot loader classes > > Also, she is a jdk9 and jdk10 Committer. > > Votes are due by March 22, 2017 > > Only current Valhalla Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > thanks, > Karen > > [1] http://openjdk.java.net/census# valhalla > [2] http://openjdk.java.net/projects#committer-vote From karen.kinnear at oracle.com Thu Mar 9 15:47:15 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 9 Mar 2017 10:47:15 -0500 Subject: Result: CFV: New Valhalla Committer: Stanislav Smirnov In-Reply-To: <5352e4f1-ffc7-78c0-8dab-c96427f181e1@oracle.com> References: <5352e4f1-ffc7-78c0-8dab-c96427f181e1@oracle.com> Message-ID: <7A297B44-2FF5-4C2D-9491-B346F3614183@oracle.com> Voting for Stanislav Smirnov [1] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. thanks, Karen [1] http://mail.openjdk.java.net/pipermail/valhalla-dev/2017-February/002211.html From david.simms at oracle.com Fri Mar 10 12:16:26 2017 From: david.simms at oracle.com (David Simms) Date: Fri, 10 Mar 2017 13:16:26 +0100 Subject: RFR: Value Array element size / value store fixes... Message-ID: Hi, Whilst in the middle of making sure value reference fields were working I discovered number some bugs which can be fixed separately: * valueArrayKlass incorrectly using the heapOopSize aligned size (i.e. nonstatic_field_size()). o This meant small values, like a single byte would use up to 8 bytes per element. This was not the intention, it should behave more like typeArrayKlass. * ValueKlass::value_store() used "Copy::conjoint_jlongs_atomic()" with an incorrect length. o Caused overwrite on small values (e.g. single narrowOop) * ValueKlass::value_store() use of memcpy is implementation dependent o Risk tearing individual primitive and reference fields Here's a patch to address the problems: http://cr.openjdk.java.net/~dsimms/valhalla/elemsize/webrev0/ Summary of changes: * valueKlass.hpp: o Reworked "raw_value_byte_size()" to return the correct pow2 aligned size for small values, otherwise heapOopSize aligned. + This enables the correct element size + Is a little expensive to call given it needs to field iterate o value_store() + Added the ability to specify copy size (for array elements) + Added "raw_field_copy()" to copy the correct size for small values or units of long (much like "JVM_Clone()" does) o Some clean up: + Removed static "valueOopDescBase()", replace usage with "first_field_offset()" + Removed value_store_ helpers * valueArrayKlass.hpp o Added "element_value_store_size()" to store "ValueKlass::raw_value_byte_size()" since it is costly + Also helps limit the amount bytes copy due to wasted space with pow2 element addressing o Add typeArray style memory copy to "copy_array()" when primitive only. Cheers /David SImms From rwestrel at redhat.com Fri Mar 10 13:05:43 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 10 Mar 2017 14:05:43 +0100 Subject: Some incremental inlining fixes In-Reply-To: <3343408a-62ad-0f67-c5be-69decbf9b764@oracle.com> References: <3343408a-62ad-0f67-c5be-69decbf9b764@oracle.com> Message-ID: Hi Tobias, Thanks for looking at this. > The comment in SafePointNode::Ideal is a bit misleading because "a > valid object input" could also mean that the ValueTypeNode has an > object *field* input. > > Maybe change it to: > 1147 // An allocated ValueTypeNode in the debug info? > 1148 // Reference the oop directly. Helps removal of useless value > 1149 // type allocations with incremental inlining. Right. But allocated ValueTypeNode sounds a bit strange. "A ValueTypeNode that was already heap allocated"? Roland. From tobias.hartmann at oracle.com Fri Mar 10 13:07:02 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 10 Mar 2017 14:07:02 +0100 Subject: Some incremental inlining fixes In-Reply-To: References: <3343408a-62ad-0f67-c5be-69decbf9b764@oracle.com> Message-ID: <3dd11f5c-4198-0ec9-04c8-79393e67fef8@oracle.com> On 10.03.2017 14:05, Roland Westrelin wrote: > Right. But allocated ValueTypeNode sounds a bit strange. "A > ValueTypeNode that was already heap allocated"? Sounds good! Thanks, Tobias From rwestrel at redhat.com Fri Mar 10 13:09:28 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Fri, 10 Mar 2017 13:09:28 +0000 Subject: hg: valhalla/valhalla/hotspot: incremental inlining fixes Message-ID: <201703101309.v2AD9Sku014432@aojmv0008.oracle.com> Changeset: 1c7a80f1947d Author: roland Date: 2017-03-10 14:08 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1c7a80f1947d incremental inlining fixes ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/valuetypenode.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From frederic.parain at oracle.com Fri Mar 10 16:19:40 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 10 Mar 2017 11:19:40 -0500 Subject: RFR: Value Array element size / value store fixes... In-Reply-To: References: Message-ID: Mr Simms, Thank you cleaning up the code related to value type payload handling. General comment about coding style: HotSpot coding style recommends to put the ?else? keyword on same line as the closing bracket of the ?then? block, not on the line below. src/share/vm/oops/valueKlass.hpp: line 82: I?d like to have some asserts here to check that the return value is a valid oop src/share/vm/oops/valueKlass.cpp: line 59 int ValueKlass::raw_value_byte_size() I assume support for object references will be added as part of your next push, right? Otherwise, looks good. Fred > On Mar 10, 2017, at 07:16, David Simms wrote: > > Hi, > > Whilst in the middle of making sure value reference fields were working I discovered number some bugs which can be fixed separately: > > * valueArrayKlass incorrectly using the heapOopSize aligned size (i.e. > nonstatic_field_size()). > o This meant small values, like a single byte would use up to 8 > bytes per element. This was not the intention, it should behave > more like typeArrayKlass. > * ValueKlass::value_store() used "Copy::conjoint_jlongs_atomic()" with > an incorrect length. > o Caused overwrite on small values (e.g. single narrowOop) > * ValueKlass::value_store() use of memcpy is implementation dependent > o Risk tearing individual primitive and reference fields > > Here's a patch to address the problems: > > http://cr.openjdk.java.net/~dsimms/valhalla/elemsize/webrev0/ > > > Summary of changes: > > * valueKlass.hpp: > o Reworked "raw_value_byte_size()" to return the correct pow2 > aligned size for small values, otherwise heapOopSize aligned. > + This enables the correct element size > + Is a little expensive to call given it needs to field iterate > o value_store() > + Added the ability to specify copy size (for array elements) > + Added "raw_field_copy()" to copy the correct size for small > values or units of long (much like "JVM_Clone()" does) > o Some clean up: > + Removed static "valueOopDescBase()", replace usage with > "first_field_offset()" > + Removed value_store_ helpers > * valueArrayKlass.hpp > o Added "element_value_store_size()" to store > "ValueKlass::raw_value_byte_size()" since it is costly > + Also helps limit the amount bytes copy due to wasted space > with pow2 element addressing > o Add typeArray style memory copy to "copy_array()" when primitive > only. > > Cheers > > /David SImms > > From rwestrel at redhat.com Fri Mar 10 17:14:29 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 10 Mar 2017 18:14:29 +0100 Subject: assert in interpreter code on 32 bit Message-ID: Hi, Running compiler/valhalla/valuetypes/ValueTypeTestBench.java with a 32 bit debug build, I get the following assert: # Internal Error (/home/rwestrel/valhalla/hotspot/src/share/vm/utilities/globalDefinitions.cpp:53), pid=643, tid=644 # fatal error: not aligned with stack: V [libjvm.so+0xa36cb9] basic_fatal(char const*)+0x39 V [libjvm.so+0x116e0b4] ValueKlass::raw_field_copy(void*, void*, unsigned int)+0xc4 V [libjvm.so+0x116e2f5] ValueKlass::value_store(void*, void*, unsigned int, bool, bool)+0x1e5 V [libjvm.so+0xaed393] InterpreterRuntime::value_array_store(JavaThread*, arrayOopDesc*, int, void*)+0x373 j compiler.valhalla.valuetypes.ValueTypeTestBench.test36_verifier(Z)V+25 Is it a known issue? Roland. From frederic.parain at oracle.com Fri Mar 10 17:28:29 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 10 Mar 2017 12:28:29 -0500 Subject: assert in interpreter code on 32 bit In-Reply-To: References: Message-ID: Hi Roland, Could this be related to the issue Mr Simms is fixing with his latest patch (still in RFR) "RFR: Value Array element size / value store fixes??? Have you tried to apply his patch? Regards, Fred > On Mar 10, 2017, at 12:14, Roland Westrelin wrote: > > > Hi, > > Running compiler/valhalla/valuetypes/ValueTypeTestBench.java with a 32 > bit debug build, I get the following assert: > > # Internal Error (/home/rwestrel/valhalla/hotspot/src/share/vm/utilities/globalDefinitions.cpp:53), pid=643, tid=644 > # fatal error: not aligned > > with stack: > > V [libjvm.so+0xa36cb9] basic_fatal(char const*)+0x39 > V [libjvm.so+0x116e0b4] ValueKlass::raw_field_copy(void*, void*, unsigned int)+0xc4 > V [libjvm.so+0x116e2f5] ValueKlass::value_store(void*, void*, unsigned int, bool, bool)+0x1e5 > V [libjvm.so+0xaed393] InterpreterRuntime::value_array_store(JavaThread*, arrayOopDesc*, int, void*)+0x373 > j compiler.valhalla.valuetypes.ValueTypeTestBench.test36_verifier(Z)V+25 > > Is it a known issue? > > Roland. From rwestrel at redhat.com Fri Mar 10 17:32:57 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 10 Mar 2017 18:32:57 +0100 Subject: assert in interpreter code on 32 bit In-Reply-To: References: Message-ID: Hi Fred, > Have you tried to apply his patch? I tried it and it doesn't seem to help. Roland. From stanislav.smirnov at oracle.com Sat Mar 11 07:39:08 2017 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Sat, 11 Mar 2017 10:39:08 +0300 Subject: CFV: New Valhalla Committer: Lois Foltan In-Reply-To: References: Message-ID: <299E82DF-FC46-4F68-9865-6416A562E7F4@oracle.com> Vote: yes. Best regards, Stanislav Smirnov > On 08 Mar 2017, at 22:34, Karen Kinnear wrote: > > I hereby nominate Lois Foltan (OpenJDK user name: lfoltan) to Committer role in Project Valhalla. > > Lois is actively working on > * ClassDynamic support > * MethodHandle tests for MVT 1.0 > and has contributed support for generic specialization of boot loader classes > > Also, she is a jdk9 and jdk10 Committer. > > Votes are due by March 22, 2017 > > Only current Valhalla Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > thanks, > Karen > > [1] http://openjdk.java.net/census# valhalla > [2] http://openjdk.java.net/projects#committer-vote From david.simms at oracle.com Mon Mar 13 06:36:22 2017 From: david.simms at oracle.com (David Simms) Date: Mon, 13 Mar 2017 07:36:22 +0100 Subject: assert in interpreter code on 32 bit In-Reply-To: References: Message-ID: Oops, no, I haven't seen this one...I'll take a look today. "ValueKlass::raw_field_copy()" - this code hasn't been pushed yet btw :-) But yeah, it looks like I need to re-run 32 bit testing Cheers /David Simms On 10/03/2017 6:14 p.m., Roland Westrelin wrote: > Hi, > > Running compiler/valhalla/valuetypes/ValueTypeTestBench.java with a 32 > bit debug build, I get the following assert: > > # Internal Error (/home/rwestrel/valhalla/hotspot/src/share/vm/utilities/globalDefinitions.cpp:53), pid=643, tid=644 > # fatal error: not aligned > > with stack: > > V [libjvm.so+0xa36cb9] basic_fatal(char const*)+0x39 > V [libjvm.so+0x116e0b4] ValueKlass::raw_field_copy(void*, void*, unsigned int)+0xc4 > V [libjvm.so+0x116e2f5] ValueKlass::value_store(void*, void*, unsigned int, bool, bool)+0x1e5 > V [libjvm.so+0xaed393] InterpreterRuntime::value_array_store(JavaThread*, arrayOopDesc*, int, void*)+0x373 > j compiler.valhalla.valuetypes.ValueTypeTestBench.test36_verifier(Z)V+25 > > Is it a known issue? > > Roland. From david.simms at oracle.com Mon Mar 13 07:39:14 2017 From: david.simms at oracle.com (David Simms) Date: Mon, 13 Mar 2017 08:39:14 +0100 Subject: RFR: Value Array element size / value store fixes... In-Reply-To: References: Message-ID: <015b5e44-cce6-13b1-8e49-2cd5ed1ddb09@oracle.com> On 10/03/2017 5:19 p.m., Frederic Parain wrote: > Mr Simms, > > Thank you cleaning up the code related to value type payload handling. > > General comment about coding style: HotSpot coding style recommends > to put the ?else? keyword on same line as the closing bracket of the ?then? > block, not on the line below. > > src/share/vm/oops/valueKlass.hpp: > line 82: I?d like to have some asserts here to check that the return value > is a valid oop Can do > > src/share/vm/oops/valueKlass.cpp: > line 59 int ValueKlass::raw_value_byte_size() > I assume support for object references will be added as part of > your next push, right? Yes > > Otherwise, looks good. Cheers, will adjust. Thanks for pointing out the HS style. I will run some 32 bit testing before pushing, seeing Roland found some issues with it. /David From david.simms at oracle.com Mon Mar 13 08:01:36 2017 From: david.simms at oracle.com (David Simms) Date: Mon, 13 Mar 2017 09:01:36 +0100 Subject: 32-bit support in general (was Re: assert in interpreter code on 32 bit) In-Reply-To: References: Message-ID: Hey all, We don't actually have 32 bit support in place for the Valhalla repo just yet... I forgot that we still had a number of "TODO later" for 32-bit support. For example testing "hotspot_valhalla" with 32 bits results in "ShouldNotReachHere()" in "SharedRuntime::java_calling_convention()" (at hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:490) is still missing case for T_VALUETYPE. This might be trivial, but... Frederic: Am I right in thinking there were still a number of non-trivial 32 bit changes outstanding ? Is it worth addressing these in the aging jdk9 - one year old sandbox, or wait until we move to jdk10 ? /David On 13/03/2017 7:36 a.m., David Simms wrote: > > Oops, no, I haven't seen this one...I'll take a look today. > > "ValueKlass::raw_field_copy()" - this code hasn't been pushed yet btw :-) > > > But yeah, it looks like I need to re-run 32 bit testing > > > Cheers > > /David Simms > > > On 10/03/2017 6:14 p.m., Roland Westrelin wrote: >> Hi, >> >> Running compiler/valhalla/valuetypes/ValueTypeTestBench.java with a 32 >> bit debug build, I get the following assert: >> >> # Internal Error >> (/home/rwestrel/valhalla/hotspot/src/share/vm/utilities/globalDefinitions.cpp:53), >> pid=643, tid=644 >> # fatal error: not aligned >> >> with stack: >> >> V [libjvm.so+0xa36cb9] basic_fatal(char const*)+0x39 >> V [libjvm.so+0x116e0b4] ValueKlass::raw_field_copy(void*, void*, >> unsigned int)+0xc4 >> V [libjvm.so+0x116e2f5] ValueKlass::value_store(void*, void*, >> unsigned int, bool, bool)+0x1e5 >> V [libjvm.so+0xaed393] >> InterpreterRuntime::value_array_store(JavaThread*, arrayOopDesc*, >> int, void*)+0x373 >> j compiler.valhalla.valuetypes.ValueTypeTestBench.test36_verifier(Z)V+25 >> >> Is it a known issue? >> >> Roland. > From david.simms at oracle.com Mon Mar 13 08:57:35 2017 From: david.simms at oracle.com (David Simms) Date: Mon, 13 Mar 2017 09:57:35 +0100 Subject: assert in interpreter code on 32 bit In-Reply-To: References: Message-ID: <96c33da1-db0b-1c32-df98-65a828e1728d@oracle.com> Thank you for running the elemsize patch Roland ! Yeah I reproduced the issue with 32-bit array layout. Looks like the header size was never correctly aligned for valueArrayOop on 32 bits. Will adjust the patch after some more testing. There remain some further 32 bit issues, as I brought up in another mail forked from this thread. Cheers /David Simms On 13/03/2017 7:36 a.m., David Simms wrote: > > Oops, no, I haven't seen this one...I'll take a look today. > > "ValueKlass::raw_field_copy()" - this code hasn't been pushed yet btw :-) > > > But yeah, it looks like I need to re-run 32 bit testing > > > Cheers > > /David Simms > > > On 10/03/2017 6:14 p.m., Roland Westrelin wrote: >> Hi, >> >> Running compiler/valhalla/valuetypes/ValueTypeTestBench.java with a 32 >> bit debug build, I get the following assert: >> >> # Internal Error >> (/home/rwestrel/valhalla/hotspot/src/share/vm/utilities/globalDefinitions.cpp:53), >> pid=643, tid=644 >> # fatal error: not aligned >> >> with stack: >> >> V [libjvm.so+0xa36cb9] basic_fatal(char const*)+0x39 >> V [libjvm.so+0x116e0b4] ValueKlass::raw_field_copy(void*, void*, >> unsigned int)+0xc4 >> V [libjvm.so+0x116e2f5] ValueKlass::value_store(void*, void*, >> unsigned int, bool, bool)+0x1e5 >> V [libjvm.so+0xaed393] >> InterpreterRuntime::value_array_store(JavaThread*, arrayOopDesc*, >> int, void*)+0x373 >> j compiler.valhalla.valuetypes.ValueTypeTestBench.test36_verifier(Z)V+25 >> >> Is it a known issue? >> >> Roland. > From megbeckim at gmail.com Thu Mar 2 15:10:13 2017 From: megbeckim at gmail.com (Timothy Fagan) Date: Thu, 2 Mar 2017 10:10:13 -0500 Subject: Proposal for a simplified syntax for invoking @FunctionalInterface methods Message-ID: I'm not sure if this is the appropriate forum, or if this idea has been proposed elsewhere, but I'd like to suggest a simplified syntax for invoking @FunctionalInterface methods. The idea is that if: * foo is a object reference (field, local variable or parameter) whose type is a @FunctionalInterface * there is a statement or expression where foo is used as if it were a method name * the formal parameters of the statement or expression match the formal parameters of the abstract method on the @FunctionalInterface * the formal parameters of the statement or expression do NOT match the formal parameters of any other method in scope named foo Then: * the statement or expression is compiled as an invocation of the @FunctionalInterface abstract method on foo's type. E.g. Function doubleString = s -> s + s; // prints "hellohello" System.out.println(*doubleString*("hello")); -Timothy From paul.sandoz at oracle.com Mon Mar 13 20:06:44 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 13 Mar 2017 13:06:44 -0700 Subject: CFV: New Valhalla Committer: Lois Foltan In-Reply-To: References: Message-ID: Vote: yes Paul. From john.r.rose at oracle.com Mon Mar 13 22:17:08 2017 From: john.r.rose at oracle.com (John Rose) Date: Mon, 13 Mar 2017 15:17:08 -0700 Subject: 32-bit support in general (was Re: assert in interpreter code on 32 bit) In-Reply-To: References: Message-ID: <2DB30599-3505-4084-8C6F-791D40DC525F@oracle.com> On Mar 13, 2017, at 1:01 AM, David Simms wrote: > > We don't actually have 32 bit support in place for the Valhalla repo just yet... I would be inclined to treat 32-bit as a future porting target (alongside SPARC and ARM and PPC), not a present requirement. By that I mean don't knowingly cut off the option, but also don't expend much effort on it, unless it helps us understand some other problem more deeply. (Maybe porting to small platforms sooner rather than later will help us understand how well our designs can be shrunk?) ? John From david.simms at oracle.com Tue Mar 14 09:50:18 2017 From: david.simms at oracle.com (david.simms at oracle.com) Date: Tue, 14 Mar 2017 09:50:18 +0000 Subject: hg: valhalla/valhalla/hotspot: value_store/ValueArray header & element size fixes Message-ID: <201703140950.v2E9oIF2019300@aojmv0008.oracle.com> Changeset: 659925d66604 Author: dsimms Date: 2017-03-14 10:49 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/659925d66604 value_store/ValueArray header & element size fixes ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/universe.inline.hpp ! src/share/vm/oops/valueArrayKlass.cpp ! src/share/vm/oops/valueArrayKlass.hpp ! src/share/vm/oops/valueKlass.cpp ! src/share/vm/oops/valueKlass.hpp ! src/share/vm/oops/valueKlass.inline.hpp From david.simms at oracle.com Tue Mar 14 13:39:15 2017 From: david.simms at oracle.com (David Simms) Date: Tue, 14 Mar 2017 14:39:15 +0100 Subject: hg: valhalla/valhalla/hotspot: value_store/ValueArray header & element size fixes In-Reply-To: <201703140950.v2E9oIF2019300@aojmv0008.oracle.com> References: <201703140950.v2E9oIF2019300@aojmv0008.oracle.com> Message-ID: <548b5f90-319b-70ec-de38-056236840b08@oracle.com> Grrr, there remains a bug... value_store is using "nonstatic_field_size() << LogBytesPerHeapOop" which is not always jlong size aligned. So whilst JVM_Clone for whole object (i.e.: from oop header through all fields) is guaranteed to be align size to jlong for copying, just the field payload is not. Value store operations for array load/store and derive value type copying, do not want to copy mark and klass ptrs. We align up the start of the fields to BytesPerLong, I guess the nonstatic_fields_size also needs jlong alignment when greater than BytesPerLong (i.e. small values remain small, copy via jbyte, jshort and jint pointers). Will push a quick fix soon, unless I hear any objection. /David Simms On 14/03/17 10:50, david.simms at oracle.com wrote: > Changeset: 659925d66604 > Author: dsimms > Date: 2017-03-14 10:49 +0100 > URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/659925d66604 > > value_store/ValueArray header & element size fixes > > ! src/share/vm/interpreter/interpreterRuntime.cpp > ! src/share/vm/memory/universe.inline.hpp > ! src/share/vm/oops/valueArrayKlass.cpp > ! src/share/vm/oops/valueArrayKlass.hpp > ! src/share/vm/oops/valueKlass.cpp > ! src/share/vm/oops/valueKlass.hpp > ! src/share/vm/oops/valueKlass.inline.hpp > From david.simms at oracle.com Tue Mar 14 14:45:56 2017 From: david.simms at oracle.com (david.simms at oracle.com) Date: Tue, 14 Mar 2017 14:45:56 +0000 Subject: hg: valhalla/valhalla/hotspot: Values and VCC larger than heapOopSize have jlong size aligned fields Message-ID: <201703141445.v2EEjuvf018287@aojmv0008.oracle.com> Changeset: f49fe2f4fadc Author: dsimms Date: 2017-03-14 15:45 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f49fe2f4fadc Values and VCC larger than heapOopSize have jlong size aligned fields ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/valueKlass.cpp From karen.kinnear at oracle.com Tue Mar 14 14:47:18 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 14 Mar 2017 10:47:18 -0400 Subject: hg: valhalla/valhalla/hotspot: Values and VCC larger than heapOopSize have jlong size aligned fields In-Reply-To: <201703141445.v2EEjuvf018287@aojmv0008.oracle.com> References: <201703141445.v2EEjuvf018287@aojmv0008.oracle.com> Message-ID: <017461CA-2530-4550-BAEE-DDFA85DFD7B5@oracle.com> Thank you for the fix! Karen > On Mar 14, 2017, at 10:45 AM, david.simms at oracle.com wrote: > > Changeset: f49fe2f4fadc > Author: dsimms > Date: 2017-03-14 15:45 +0100 > URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f49fe2f4fadc > > Values and VCC larger than heapOopSize have jlong size aligned fields > > ! src/share/vm/classfile/classFileParser.cpp > ! src/share/vm/oops/valueKlass.cpp > From rwestrel at redhat.com Tue Mar 14 16:16:34 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 14 Mar 2017 17:16:34 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp Message-ID: http://cr.openjdk.java.net/~roland/valhalla/xcompfixes/webrev.00/ Because of method handles, in SharedRuntime::allocate_value_types() using the static target is not good enough because its signature of the static target might differ from the signature of the actual callee. So instead, the runtime call is now passed the actual target which is good because we also probably need to do something to keep it alive. The bcEscapeAnalyzer.cpp fix is obvious. We can't use the value factory parameter mapping until the value class is initialized: added an assert and an uncommon trap so the assert doesn't fire. Sometimes a lambda form compiled as the root of a compilation has a signature with object parameters but is passed a value type: so it's passed fields but has no way to know. This could be fixed by always passing value types as references when the target is a lambda form. But then, method handles intrinsics could get reference inputs and call a method that expects value types to be passed as fields. So the code in MethodHandles::generate_method_handle_dispatch() would need to be adjusted to shuffle arguments. That all sounds too complicated so instead I disallowed lambda form as root of compilations. Roland. From tobias.hartmann at oracle.com Wed Mar 15 08:00:54 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Mar 2017 09:00:54 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: References: Message-ID: <9f25d88f-aeb3-6c72-9549-0f69aa2a34fe@oracle.com> Hi Roland, On 14.03.2017 17:16, Roland Westrelin wrote: > Because of method handles, in SharedRuntime::allocate_value_types() > using the static target is not good enough because its signature of the > static target might differ from the signature of the actual callee. So > instead, the runtime call is now passed the actual target which is good > because we also probably need to do something to keep it alive. Please add a TODO to the "required to keep callee live?" comments so we can easily find those locations later. > The bcEscapeAnalyzer.cpp fix is obvious. > > We can't use the value factory parameter mapping until the value class > is initialized: added an assert and an uncommon trap so the assert > doesn't fire. Looks good! > Sometimes a lambda form compiled as the root of a compilation has a > signature with object parameters but is passed a value type: so it's > passed fields but has no way to know. This could be fixed by always > passing value types as references when the target is a lambda form. But > then, method handles intrinsics could get reference inputs and call a > method that expects value types to be passed as fields. So the code in > MethodHandles::generate_method_handle_dispatch() would need to be > adjusted to shuffle arguments. That all sounds too complicated so > instead I disallowed lambda form as root of compilations. I wonder if it's okay to treat value types as objects in such cases. Zoltan, you found some related problems right? I think it would make sense to add "-Xcomp -XX:-TieredCompilation" to the runtime tests (I did that before, see patch below). Thanks, Tobias --- old/test/runtime/valhalla/valuetypes/DeriveValueTypeCreation.java 2017-03-15 08:54:48.004842144 +0100 +++ new/test/runtime/valhalla/valuetypes/DeriveValueTypeCreation.java 2017-03-15 08:54:47.936842147 +0100 @@ -43,6 +43,7 @@ * @library /testlibrary / * @build runtime.valhalla.valuetypes.ValueCapableClass * @run main/othervm -Xint -noverify runtime.valhalla.valuetypes.DeriveValueTypeCreation + * @run main/othervm -Xcomp -XX:-TieredCompilation -noverify runtime.valhalla.valuetypes.DeriveValueTypeCreation */ public class DeriveValueTypeCreation { --- old/test/runtime/valhalla/valuetypes/InvokeDirect.java 2017-03-15 08:54:48.256842132 +0100 +++ new/test/runtime/valhalla/valuetypes/InvokeDirect.java 2017-03-15 08:54:48.188842136 +0100 @@ -7,6 +7,7 @@ * @summary Value Type invokedirect bytecode test (incomplete until type system defn done) * @library /testlibrary / * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.InvokeDirect + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.InvokeDirect */ public class InvokeDirect { public static void main(String[] args) { --- old/test/runtime/valhalla/valuetypes/VDefaultTest.java 2017-03-15 08:54:48.512842121 +0100 +++ new/test/runtime/valhalla/valuetypes/VDefaultTest.java 2017-03-15 08:54:48.444842124 +0100 @@ -30,6 +30,7 @@ * @summary vdefault bytecode test * @library /testlibrary / * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.VDefaultTest + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.VDefaultTest */ public class VDefaultTest { --- old/test/runtime/valhalla/valuetypes/VWithFieldTest.java 2017-03-15 08:54:48.756842109 +0100 +++ new/test/runtime/valhalla/valuetypes/VWithFieldTest.java 2017-03-15 08:54:48.692842112 +0100 @@ -30,6 +30,7 @@ * @summary vwithfield bytecode test * @library /testlibrary / * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.VWithFieldTest + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.VWithFieldTest */ public class VWithFieldTest { --- old/test/runtime/valhalla/valuetypes/ValueTypeArray.java 2017-03-15 08:54:49.000842098 +0100 +++ new/test/runtime/valhalla/valuetypes/ValueTypeArray.java 2017-03-15 08:54:48.936842101 +0100 @@ -33,6 +33,8 @@ * @library /testlibrary / * @run main/othervm -noverify -Xint -XX:+ValueArrayFlatten runtime.valhalla.valuetypes.ValueTypeArray * @run main/othervm -noverify -Xint -XX:-ValueArrayFlatten runtime.valhalla.valuetypes.ValueTypeArray + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation -XX:+ValueArrayFlatten runtime.valhalla.valuetypes.ValueTypeArray + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation -XX:-ValueArrayFlatten runtime.valhalla.valuetypes.ValueTypeArray */ public class ValueTypeArray { public static void main(String[] args) { --- old/test/runtime/valhalla/valuetypes/ValueTypeCreation.java 2017-03-15 08:54:49.248842086 +0100 +++ new/test/runtime/valhalla/valuetypes/ValueTypeCreation.java 2017-03-15 08:54:49.180842089 +0100 @@ -7,6 +7,7 @@ * @summary Value Type creation test * @library /testlibrary / * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.ValueTypeCreation + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.ValueTypeCreation */ public class ValueTypeCreation { public static void main(String[] args) { --- old/test/runtime/valhalla/valuetypes/ValueTypeDensity.java 2017-03-15 08:54:49.496842075 +0100 +++ new/test/runtime/valhalla/valuetypes/ValueTypeDensity.java 2017-03-15 08:54:49.428842078 +0100 @@ -36,6 +36,7 @@ * @run driver ClassFileInstaller sun.hotspot.WhiteBox * sun.hotspot.WhiteBox$WhiteBoxPermission * @run main/othervm -noverify -Xint -XX:+ValueArrayFlatten -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI ValueTypeDensity + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation -XX:+ValueArrayFlatten -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI ValueTypeDensity */ public class ValueTypeDensity { --- old/test/runtime/valhalla/valuetypes/ValueTypeGetField.java 2017-03-15 08:54:49.752842063 +0100 +++ new/test/runtime/valhalla/valuetypes/ValueTypeGetField.java 2017-03-15 08:54:49.684842066 +0100 @@ -7,6 +7,7 @@ * @summary Value Type get field test * @library /testlibrary / * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.ValueTypeGetField + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.ValueTypeGetField */ public class ValueTypeGetField { --- old/test/runtime/valhalla/valuetypes/VboxUnbox.java 2017-03-15 08:54:50.008842051 +0100 +++ new/test/runtime/valhalla/valuetypes/VboxUnbox.java 2017-03-15 08:54:49.940842054 +0100 @@ -33,6 +33,7 @@ * @library /testlibrary / * @build runtime.valhalla.valuetypes.ValueCapableClass * @run main/othervm -Xint -noverify runtime.valhalla.valuetypes.VboxUnbox + * @run main/othervm -Xcomp -XX:-TieredCompilation -noverify runtime.valhalla.valuetypes.VboxUnbox * * To dump generated byte-code, add "-Dvalhalla.dumpIsolatedMethodClasses=/tmp/foo" */ From rwestrel at redhat.com Wed Mar 15 08:08:06 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 15 Mar 2017 09:08:06 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: <9f25d88f-aeb3-6c72-9549-0f69aa2a34fe@oracle.com> References: <9f25d88f-aeb3-6c72-9549-0f69aa2a34fe@oracle.com> Message-ID: Hi Tobias, Thanks for looking at this. > Please add a TODO to the "required to keep callee live?" comments so > we can easily find those locations later. Ok. >> Sometimes a lambda form compiled as the root of a compilation has a >> signature with object parameters but is passed a value type: so it's >> passed fields but has no way to know. This could be fixed by always >> passing value types as references when the target is a lambda form. But >> then, method handles intrinsics could get reference inputs and call a >> method that expects value types to be passed as fields. So the code in >> MethodHandles::generate_method_handle_dispatch() would need to be >> adjusted to shuffle arguments. That all sounds too complicated so >> instead I disallowed lambda form as root of compilations. > > I wonder if it's okay to treat value types as objects in such cases. That would be a problem in the method handles runtime then, right? > I think it would make sense to add "-Xcomp -XX:-TieredCompilation" to > the runtime tests (I did that before, see patch below). But then, if we break something in the compiler, the runtime foks will start to see failures in their tests. Wouldn't it be better to remove the -Xint from the runtime tests, force TieredCompilation off so we can run the VM with no option. Then we can run their tests by passing -Xcomp to jtreg? Roland. From tobias.hartmann at oracle.com Wed Mar 15 08:12:25 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Mar 2017 09:12:25 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: References: <9f25d88f-aeb3-6c72-9549-0f69aa2a34fe@oracle.com> Message-ID: <95c10b99-bfd2-2f31-6f89-dbb67399d799@oracle.com> On 15.03.2017 09:08, Roland Westrelin wrote: >>> Sometimes a lambda form compiled as the root of a compilation has a >>> signature with object parameters but is passed a value type: so it's >>> passed fields but has no way to know. This could be fixed by always >>> passing value types as references when the target is a lambda form. But >>> then, method handles intrinsics could get reference inputs and call a >>> method that expects value types to be passed as fields. So the code in >>> MethodHandles::generate_method_handle_dispatch() would need to be >>> adjusted to shuffle arguments. That all sounds too complicated so >>> instead I disallowed lambda form as root of compilations. >> >> I wonder if it's okay to treat value types as objects in such cases. > > That would be a problem in the method handles runtime then, right? Yes, I think so but unfortunately I'm not too familiar with the method handle runtime. >> I think it would make sense to add "-Xcomp -XX:-TieredCompilation" to >> the runtime tests (I did that before, see patch below). > > But then, if we break something in the compiler, the runtime foks will > start to see failures in their tests. Wouldn't it be better to remove > the -Xint from the runtime tests, force TieredCompilation off so we can > run the VM with no option. Then we can run their tests by passing -Xcomp > to jtreg? Yes, you are right. Removing -Xint and adding -XX:-TieredCompilation is better. Thanks, Tobias From rwestrel at redhat.com Wed Mar 15 08:21:29 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 15 Mar 2017 09:21:29 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: <95c10b99-bfd2-2f31-6f89-dbb67399d799@oracle.com> References: <9f25d88f-aeb3-6c72-9549-0f69aa2a34fe@oracle.com> <95c10b99-bfd2-2f31-6f89-dbb67399d799@oracle.com> Message-ID: >>>> Sometimes a lambda form compiled as the root of a compilation has a >>>> signature with object parameters but is passed a value type: so it's >>>> passed fields but has no way to know. This could be fixed by always >>>> passing value types as references when the target is a lambda form. But >>>> then, method handles intrinsics could get reference inputs and call a >>>> method that expects value types to be passed as fields. So the code in >>>> MethodHandles::generate_method_handle_dispatch() would need to be >>>> adjusted to shuffle arguments. That all sounds too complicated so >>>> instead I disallowed lambda form as root of compilations. >>> >>> I wonder if it's okay to treat value types as objects in such cases. >> >> That would be a problem in the method handles runtime then, right? > > Yes, I think so but unfortunately I'm not too familiar with the method > handle runtime. Me neither. Vladimir I, what do you think? Anyway, we at least need a workaround for this. Are you ok with the one I used? > Yes, you are right. Removing -Xint and adding -XX:-TieredCompilation > is better. Why not set TieredCompilation to false in arguments.cpp once for all? Roland. From tobias.hartmann at oracle.com Wed Mar 15 08:29:39 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Mar 2017 09:29:39 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: References: <9f25d88f-aeb3-6c72-9549-0f69aa2a34fe@oracle.com> <95c10b99-bfd2-2f31-6f89-dbb67399d799@oracle.com> Message-ID: <62b114ad-ea06-b0eb-2e9b-b7ad0a37a2ec@oracle.com> On 15.03.2017 09:21, Roland Westrelin wrote: > Anyway, we at least need a workaround for this. Are you ok with the one > I used? Sure, fine with me. > Why not set TieredCompilation to false in arguments.cpp once for all? Right, that's even better. Thanks, Tobias From rwestrel at redhat.com Wed Mar 15 08:35:07 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 15 Mar 2017 09:35:07 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: <62b114ad-ea06-b0eb-2e9b-b7ad0a37a2ec@oracle.com> References: <9f25d88f-aeb3-6c72-9549-0f69aa2a34fe@oracle.com> <95c10b99-bfd2-2f31-6f89-dbb67399d799@oracle.com> <62b114ad-ea06-b0eb-2e9b-b7ad0a37a2ec@oracle.com> Message-ID: >> Why not set TieredCompilation to false in arguments.cpp once for all? > > Right, that's even better. Ok. Let me push that change and I'll propose the tweak to the runtime tests as another change. Roland. From rwestrel at redhat.com Wed Mar 15 08:39:16 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Wed, 15 Mar 2017 08:39:16 +0000 Subject: hg: valhalla/valhalla/hotspot: collection of fixes from runtime tests with -Xcomp Message-ID: <201703150839.v2F8dGRn018364@aojmv0008.oracle.com> Changeset: 84f7e1e3ef47 Author: roland Date: 2017-03-14 16:49 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/84f7e1e3ef47 collection of fixes from runtime tests with -Xcomp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciValueKlass.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp From rwestrel at redhat.com Wed Mar 15 09:03:52 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 15 Mar 2017 10:03:52 +0100 Subject: remove -Xint from runtime tests Message-ID: http://cr.openjdk.java.net/~roland/valhalla/runtimetests/webrev.00/ We'd like to be able to run runtime tests with -Xcomp to stress test the compiler. Runtime tests currently run fine without -Xint. This change also forces TieredCompilation to off because c1 is unsupported. Roland. From tobias.hartmann at oracle.com Wed Mar 15 09:22:18 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Mar 2017 10:22:18 +0100 Subject: remove -Xint from runtime tests In-Reply-To: References: Message-ID: <9c99d1c1-c582-7462-0273-940e6c390112@oracle.com> Hi Roland, looks good to me but the runtime team should decide if they are fine with this. Thanks, Tobias On 15.03.2017 10:03, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/valhalla/runtimetests/webrev.00/ > > We'd like to be able to run runtime tests with -Xcomp to stress test the > compiler. Runtime tests currently run fine without -Xint. > > This change also forces TieredCompilation to off because c1 is > unsupported. > > Roland. > From zoltan.majo at oracle.com Wed Mar 15 10:29:55 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Mar 2017 11:29:55 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: <9f25d88f-aeb3-6c72-9549-0f69aa2a34fe@oracle.com> References: <9f25d88f-aeb3-6c72-9549-0f69aa2a34fe@oracle.com> Message-ID: <08a8189c-c2b8-70e4-7fcf-fa088c9c5063@oracle.com> Hi, On 03/15/2017 09:00 AM, Tobias Hartmann wrote: > Hi Roland, > > On 14.03.2017 17:16, Roland Westrelin wrote: >> [...] >> >> Sometimes a lambda form compiled as the root of a compilation has a >> signature with object parameters but is passed a value type: so it's >> passed fields but has no way to know. This could be fixed by always >> passing value types as references when the target is a lambda form. But >> then, method handles intrinsics could get reference inputs and call a >> method that expects value types to be passed as fields. So the code in >> MethodHandles::generate_method_handle_dispatch() would need to be >> adjusted to shuffle arguments. That all sounds too complicated so >> instead I disallowed lambda form as root of compilations. > I wonder if it's okay to treat value types as objects in such cases. > > Zoltan, you found some related problems right? Yes. A version of Maurizio's PointValues program triggered an error in C2's type system. The test attempted to pass a Q-type to an MethodHandle.invoke(Object o). That results in a type system error at the moment, as C2 considers a Q-type and and L-type to be "unrelated". (The test would, of course work, if the Q-type was first boxed to the matching L-type before calling the invoke method.) So maybe the question is: Is a value type a subclass of a java.lang.Object? If yes, we should make C2 aware of that. If not, then I think it's a good idea to bail out compilation if the compiler detects that a Q-type is used in place of an L-type. Currently, an L-type and the matching Q-type have the same memory layout, so we could treat them as being the same. But by starting to doing so we'll most likely encounter some difficult-to-trace errors. So I'm more for bailing out compilations (or updating the type system to consider Q-types as subclasses of java.lang.Object). Best regards, Zoltan > > I think it would make sense to add "-Xcomp -XX:-TieredCompilation" to the runtime tests (I did that before, see patch below). > > Thanks, > Tobias > > > --- old/test/runtime/valhalla/valuetypes/DeriveValueTypeCreation.java 2017-03-15 08:54:48.004842144 +0100 > +++ new/test/runtime/valhalla/valuetypes/DeriveValueTypeCreation.java 2017-03-15 08:54:47.936842147 +0100 > @@ -43,6 +43,7 @@ > * @library /testlibrary / > * @build runtime.valhalla.valuetypes.ValueCapableClass > * @run main/othervm -Xint -noverify runtime.valhalla.valuetypes.DeriveValueTypeCreation > + * @run main/othervm -Xcomp -XX:-TieredCompilation -noverify runtime.valhalla.valuetypes.DeriveValueTypeCreation > */ > public class DeriveValueTypeCreation { > > --- old/test/runtime/valhalla/valuetypes/InvokeDirect.java 2017-03-15 08:54:48.256842132 +0100 > +++ new/test/runtime/valhalla/valuetypes/InvokeDirect.java 2017-03-15 08:54:48.188842136 +0100 > @@ -7,6 +7,7 @@ > * @summary Value Type invokedirect bytecode test (incomplete until type system defn done) > * @library /testlibrary / > * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.InvokeDirect > + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.InvokeDirect > */ > public class InvokeDirect { > public static void main(String[] args) { > --- old/test/runtime/valhalla/valuetypes/VDefaultTest.java 2017-03-15 08:54:48.512842121 +0100 > +++ new/test/runtime/valhalla/valuetypes/VDefaultTest.java 2017-03-15 08:54:48.444842124 +0100 > @@ -30,6 +30,7 @@ > * @summary vdefault bytecode test > * @library /testlibrary / > * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.VDefaultTest > + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.VDefaultTest > */ > > public class VDefaultTest { > --- old/test/runtime/valhalla/valuetypes/VWithFieldTest.java 2017-03-15 08:54:48.756842109 +0100 > +++ new/test/runtime/valhalla/valuetypes/VWithFieldTest.java 2017-03-15 08:54:48.692842112 +0100 > @@ -30,6 +30,7 @@ > * @summary vwithfield bytecode test > * @library /testlibrary / > * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.VWithFieldTest > + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.VWithFieldTest > */ > > public class VWithFieldTest { > --- old/test/runtime/valhalla/valuetypes/ValueTypeArray.java 2017-03-15 08:54:49.000842098 +0100 > +++ new/test/runtime/valhalla/valuetypes/ValueTypeArray.java 2017-03-15 08:54:48.936842101 +0100 > @@ -33,6 +33,8 @@ > * @library /testlibrary / > * @run main/othervm -noverify -Xint -XX:+ValueArrayFlatten runtime.valhalla.valuetypes.ValueTypeArray > * @run main/othervm -noverify -Xint -XX:-ValueArrayFlatten runtime.valhalla.valuetypes.ValueTypeArray > + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation -XX:+ValueArrayFlatten runtime.valhalla.valuetypes.ValueTypeArray > + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation -XX:-ValueArrayFlatten runtime.valhalla.valuetypes.ValueTypeArray > */ > public class ValueTypeArray { > public static void main(String[] args) { > --- old/test/runtime/valhalla/valuetypes/ValueTypeCreation.java 2017-03-15 08:54:49.248842086 +0100 > +++ new/test/runtime/valhalla/valuetypes/ValueTypeCreation.java 2017-03-15 08:54:49.180842089 +0100 > @@ -7,6 +7,7 @@ > * @summary Value Type creation test > * @library /testlibrary / > * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.ValueTypeCreation > + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.ValueTypeCreation > */ > public class ValueTypeCreation { > public static void main(String[] args) { > --- old/test/runtime/valhalla/valuetypes/ValueTypeDensity.java 2017-03-15 08:54:49.496842075 +0100 > +++ new/test/runtime/valhalla/valuetypes/ValueTypeDensity.java 2017-03-15 08:54:49.428842078 +0100 > @@ -36,6 +36,7 @@ > * @run driver ClassFileInstaller sun.hotspot.WhiteBox > * sun.hotspot.WhiteBox$WhiteBoxPermission > * @run main/othervm -noverify -Xint -XX:+ValueArrayFlatten -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI ValueTypeDensity > + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation -XX:+ValueArrayFlatten -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI ValueTypeDensity > */ > > public class ValueTypeDensity { > --- old/test/runtime/valhalla/valuetypes/ValueTypeGetField.java 2017-03-15 08:54:49.752842063 +0100 > +++ new/test/runtime/valhalla/valuetypes/ValueTypeGetField.java 2017-03-15 08:54:49.684842066 +0100 > @@ -7,6 +7,7 @@ > * @summary Value Type get field test > * @library /testlibrary / > * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.ValueTypeGetField > + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.ValueTypeGetField > */ > public class ValueTypeGetField { > > --- old/test/runtime/valhalla/valuetypes/VboxUnbox.java 2017-03-15 08:54:50.008842051 +0100 > +++ new/test/runtime/valhalla/valuetypes/VboxUnbox.java 2017-03-15 08:54:49.940842054 +0100 > @@ -33,6 +33,7 @@ > * @library /testlibrary / > * @build runtime.valhalla.valuetypes.ValueCapableClass > * @run main/othervm -Xint -noverify runtime.valhalla.valuetypes.VboxUnbox > + * @run main/othervm -Xcomp -XX:-TieredCompilation -noverify runtime.valhalla.valuetypes.VboxUnbox > * > * To dump generated byte-code, add "-Dvalhalla.dumpIsolatedMethodClasses=/tmp/foo" > */ > From tobias.hartmann at oracle.com Wed Mar 15 11:58:42 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Mar 2017 12:58:42 +0100 Subject: Loop cloning with value types and some small fixes Message-ID: <20582b63-a145-f156-92ee-d69a1d416063@oracle.com> Hi, please review the following patch that fixes multiple problem (see below): http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.10/ - Loop cloning creates phi nodes to merge loop exit values from the old and new loop bodies. ValueTypeNodes should not be merged through phi nodes but through their input values. I tried different approaches but Roland suggested to go with a PhiNode::Ideal transformation. - Added safepoint re-wiring code to ValueTypeNode::Ideal because it can happen that the oop input is replaced by a non-NULL value without re-processing by Safepoint::Ideal() - Changed oop null check to 'higher_equal' for consistency (for example, with LibraryCallKit::inline_unsafe_access) - Added an assert to split if in case we ever try to split a value type through a phi - Added -XX:+IgnoreUnrecognizedVMOptions to tests to ignore debug flag settings in product builds - Only disable ValueTypePassFieldsAsArgs on non-x86_64 (was disabled on all non-Linux platforms by accident) - Disable IR verification if ValueTypePassFieldsAsArgs is not supported because we would need to add additional matching rules for those flag combinations Thanks to Mr. Simms and Frederic for reporting some of the problems. Thanks to Roland for helping to fix clone_loop. Best regards, Tobias From rwestrel at redhat.com Wed Mar 15 12:16:47 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 15 Mar 2017 13:16:47 +0100 Subject: Loop cloning with value types and some small fixes In-Reply-To: <20582b63-a145-f156-92ee-d69a1d416063@oracle.com> References: <20582b63-a145-f156-92ee-d69a1d416063@oracle.com> Message-ID: > http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.10/ Looks good to me. Roland. From tobias.hartmann at oracle.com Wed Mar 15 12:17:44 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Mar 2017 13:17:44 +0100 Subject: Loop cloning with value types and some small fixes In-Reply-To: References: <20582b63-a145-f156-92ee-d69a1d416063@oracle.com> Message-ID: <053eb00e-b6c0-e009-b7ab-83d9791a19e3@oracle.com> Thanks, Roland! Best regards, Tobias On 15.03.2017 13:16, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.10/ > > Looks good to me. > > Roland. > From david.simms at oracle.com Wed Mar 15 12:51:01 2017 From: david.simms at oracle.com (David Simms) Date: Wed, 15 Mar 2017 13:51:01 +0100 Subject: remove -Xint from runtime tests In-Reply-To: <9c99d1c1-c582-7462-0273-940e6c390112@oracle.com> References: <9c99d1c1-c582-7462-0273-940e6c390112@oracle.com> Message-ID: Most of the runtime valhalla tests take only a seconds, FWIW I'd like to see both "-Xint" and "-Xcomp" (i.e. multiple jtreg run tags). On 15/03/2017 10:22 a.m., Tobias Hartmann wrote: > Hi Roland, > > looks good to me but the runtime team should decide if they are fine with this. > > Thanks, > Tobias > > On 15.03.2017 10:03, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/valhalla/runtimetests/webrev.00/ >> >> We'd like to be able to run runtime tests with -Xcomp to stress test the >> compiler. Runtime tests currently run fine without -Xint. >> >> This change also forces TieredCompilation to off because c1 is >> unsupported. >> >> Roland. >> From tobias.hartmann at oracle.com Wed Mar 15 12:59:41 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Mar 2017 13:59:41 +0100 Subject: hg: valhalla/valhalla/hotspot: value_store/ValueArray header & element size fixes In-Reply-To: <201703140950.v2E9oIF2019300@aojmv0008.oracle.com> References: <201703140950.v2E9oIF2019300@aojmv0008.oracle.com> Message-ID: <6e0a48c0-4674-ef56-4dae-15ce52f24c9f@oracle.com> Hi, there's an #include "oops/oop.inline.hpp" missing in valueKlass.hpp because of the new assert(o->is_oop(false)) causing JPRT build failures. I'll fix this with my next changeset. Thanks, Tobias On 14.03.2017 10:50, david.simms at oracle.com wrote: > Changeset: 659925d66604 > Author: dsimms > Date: 2017-03-14 10:49 +0100 > URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/659925d66604 > > value_store/ValueArray header & element size fixes > > ! src/share/vm/interpreter/interpreterRuntime.cpp > ! src/share/vm/memory/universe.inline.hpp > ! src/share/vm/oops/valueArrayKlass.cpp > ! src/share/vm/oops/valueArrayKlass.hpp > ! src/share/vm/oops/valueKlass.cpp > ! src/share/vm/oops/valueKlass.hpp > ! src/share/vm/oops/valueKlass.inline.hpp > From frederic.parain at oracle.com Wed Mar 15 13:02:53 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 15 Mar 2017 09:02:53 -0400 Subject: remove -Xint from runtime tests In-Reply-To: References: <9c99d1c1-c582-7462-0273-940e6c390112@oracle.com> Message-ID: <0BC69CAC-B98C-48C1-9054-675164B410F2@oracle.com> +1 Fred > On Mar 15, 2017, at 08:51, David Simms wrote: > > > Most of the runtime valhalla tests take only a seconds, FWIW I'd like to see both "-Xint" and "-Xcomp" (i.e. multiple jtreg run tags). > > > On 15/03/2017 10:22 a.m., Tobias Hartmann wrote: >> Hi Roland, >> >> looks good to me but the runtime team should decide if they are fine with this. >> >> Thanks, >> Tobias >> >> On 15.03.2017 10:03, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/valhalla/runtimetests/webrev.00/ >>> >>> We'd like to be able to run runtime tests with -Xcomp to stress test the >>> compiler. Runtime tests currently run fine without -Xint. >>> >>> This change also forces TieredCompilation to off because c1 is >>> unsupported. >>> >>> Roland. >>> > From tobias.hartmann at oracle.com Wed Mar 15 13:06:24 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 15 Mar 2017 13:06:24 +0000 Subject: hg: valhalla/valhalla/hotspot: Loop cloning with value types and some small fixes Message-ID: <201703151306.v2FD6Ok8004898@aojmv0008.oracle.com> Changeset: 214cedfb6051 Author: thartmann Date: 2017-03-15 14:05 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/214cedfb6051 Loop cloning with value types and some small fixes Reviewed-by: roland ! src/share/vm/oops/valueKlass.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/valuetypenode.cpp ! src/share/vm/opto/valuetypenode.hpp ! src/share/vm/runtime/arguments.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From david.simms at oracle.com Wed Mar 15 13:10:01 2017 From: david.simms at oracle.com (David Simms) Date: Wed, 15 Mar 2017 14:10:01 +0100 Subject: hg: valhalla/valhalla/hotspot: value_store/ValueArray header & element size fixes In-Reply-To: <6e0a48c0-4674-ef56-4dae-15ce52f24c9f@oracle.com> References: <201703140950.v2E9oIF2019300@aojmv0008.oracle.com> <6e0a48c0-4674-ef56-4dae-15ce52f24c9f@oracle.com> Message-ID: <8bc8ebf0-e0ec-adca-ed08-72a7b179ccb7@oracle.com> Thanks Tobias ! Sorry about that /David Simms On 15/03/2017 1:59 p.m., Tobias Hartmann wrote: > Hi, > > there's an #include "oops/oop.inline.hpp" missing in valueKlass.hpp because of the new assert(o->is_oop(false)) causing JPRT build failures. I'll fix this with my next changeset. > > Thanks, > Tobias > > On 14.03.2017 10:50, david.simms at oracle.com wrote: >> Changeset: 659925d66604 >> Author: dsimms >> Date: 2017-03-14 10:49 +0100 >> URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/659925d66604 >> >> value_store/ValueArray header & element size fixes >> >> ! src/share/vm/interpreter/interpreterRuntime.cpp >> ! src/share/vm/memory/universe.inline.hpp >> ! src/share/vm/oops/valueArrayKlass.cpp >> ! src/share/vm/oops/valueArrayKlass.hpp >> ! src/share/vm/oops/valueKlass.cpp >> ! src/share/vm/oops/valueKlass.hpp >> ! src/share/vm/oops/valueKlass.inline.hpp >> From tobias.hartmann at oracle.com Wed Mar 15 14:51:31 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Mar 2017 15:51:31 +0100 Subject: Arrays.copyOf does not work with value type arrays Message-ID: <5903439c-6ac8-dc27-adab-0ee0ff3bda1e@oracle.com> Hi, I'm looking into C2 intrinsic support for value types and noticed that below code fails with: Exception in thread "main" java.lang.BootstrapMethodError: call site initialization exception at java.lang.invoke.CallSite.makeSite(CallSite.java:347) at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:247) at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:237) at Test.main(Test.java:23) Caused by: java.lang.ClassNotFoundException: java/util/Arrays$copyOf$433071630$${QPoint;} at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:372) at java.lang.invoke.GenericStaticDispatch.metafactory(GenericStaticDispatch.java:14) at java.lang.invoke.CallSite.makeSite(CallSite.java:308) ... 3 more Is this supposed to work with MVT1.0? Thanks, Tobias import java.util.Arrays; __ByValue final class Point { final int x; final int y; private Point(int x, int y) { this.x = x; this.y = y; } public static Point createPoint(int x, int y) { return __Make Point(x, y); } } public class Test { public static void main(String[] args) { Point[] src = new Point[10]; Point[] dst = Arrays.copyOf(src, 10); } } From david.simms at oracle.com Wed Mar 15 15:29:16 2017 From: david.simms at oracle.com (David Simms) Date: Wed, 15 Mar 2017 16:29:16 +0100 Subject: Arrays.copyOf does not work with value type arrays In-Reply-To: <5903439c-6ac8-dc27-adab-0ee0ff3bda1e@oracle.com> References: <5903439c-6ac8-dc27-adab-0ee0ff3bda1e@oracle.com> Message-ID: <917ae23f-283b-86b7-ac6d-f01305dbc1c6@oracle.com> Hi Tobias, So this is a method handle issue, i.e. javac generates: invokedynamic #29, 0 // InvokeDynamic #0:copyOf:([Ljava/lang/Object;I)[Ljava/lang/Object; For call to "public static T[] copyOf(T[] original, int newLength)". This is something of a problem here. MVT array method handles return Object as the array. So I'm not sure you can call Arrays.copyOf with "[QPoint" as you are doing here. Furthermore, method handle JDK runtime support for Q types is incomplete. /David Simms On 15/03/2017 3:51 p.m., Tobias Hartmann wrote: > import java.util.Arrays; > > __ByValue final class Point { > final int x; > final int y; > > private Point(int x, int y) { > this.x = x; > this.y = y; > } > > public static Point createPoint(int x, int y) { > return __Make Point(x, y); > } > } > > public class Test { > > public static void main(String[] args) { > Point[] src = new Point[10]; > Point[] dst = Arrays.copyOf(src, 10); > } > > } From rwestrel at redhat.com Wed Mar 15 15:37:37 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 15 Mar 2017 16:37:37 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: <08a8189c-c2b8-70e4-7fcf-fa088c9c5063@oracle.com> References: <9f25d88f-aeb3-6c72-9549-0f69aa2a34fe@oracle.com> <08a8189c-c2b8-70e4-7fcf-fa088c9c5063@oracle.com> Message-ID: > Currently, an L-type and the matching Q-type have the same memory > layout, so we could treat them as being the same. But by starting to > doing so we'll most likely encounter some difficult-to-trace errors. So > I'm more for bailing out compilations (or updating the type system to > consider Q-types as subclasses of java.lang.Object). The problem in my case was that the root of the compilation is a lambda form which takes and object argument but is passed a value type. There's no way in that case to know at compile time that what is passed is a value type so no way to bail out. Roland. From zoltan.majo at oracle.com Wed Mar 15 15:57:53 2017 From: zoltan.majo at oracle.com (=?utf-8?Q?Zolt=C3=A1n_Maj=C3=B3?=) Date: Wed, 15 Mar 2017 16:57:53 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: References: <9f25d88f-aeb3-6c72-9549-0f69aa2a34fe@oracle.com> <08a8189c-c2b8-70e4-7fcf-fa088c9c5063@oracle.com> Message-ID: Hi Roland, > On 2017. Mar 15., at 16:37, Roland Westrelin wrote: > > >> Currently, an L-type and the matching Q-type have the same memory >> layout, so we could treat them as being the same. But by starting to >> doing so we'll most likely encounter some difficult-to-trace errors. So >> I'm more for bailing out compilations (or updating the type system to >> consider Q-types as subclasses of java.lang.Object). > > The problem in my case was that the root of the compilation is a lambda > form which takes and object argument but is passed a value type. There's > no way in that case to know at compile time that what is passed is a > value type so no way to bail out. > thank you for explaining. I meant "bail out" in a more general way -- I thought of something along the lines of refuse compilation in cases where mixing types happens or can potentially happen. Best regards, Zoltan > Roland. From frederic.parain at oracle.com Wed Mar 15 16:59:14 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 15 Mar 2017 12:59:14 -0400 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: References: Message-ID: > On Mar 14, 2017, at 12:16, Roland Westrelin wrote: > > > http://cr.openjdk.java.net/~roland/valhalla/xcompfixes/webrev.00/ > > Because of method handles, in SharedRuntime::allocate_value_types() > using the static target is not good enough because its signature of the > static target might differ from the signature of the actual callee. So > instead, the runtime call is now passed the actual target which is good > because we also probably need to do something to keep it alive. > > The bcEscapeAnalyzer.cpp fix is obvious. > > We can't use the value factory parameter mapping until the value class > is initialized: added an assert and an uncommon trap so the assert > doesn't fire. Roland,, Is C2 code relying on the ValueFactory_attribute used by vnew? Vnew and this attribute are supposed to be removed in favor of the vdefault/vwithfield solution to create values. If this is likely to cause issues to C2, it?s time to speak up. Regards, Fred > Sometimes a lambda form compiled as the root of a compilation has a > signature with object parameters but is passed a value type: so it's > passed fields but has no way to know. This could be fixed by always > passing value types as references when the target is a lambda form. But > then, method handles intrinsics could get reference inputs and call a > method that expects value types to be passed as fields. So the code in > MethodHandles::generate_method_handle_dispatch() would need to be > adjusted to shuffle arguments. That all sounds too complicated so > instead I disallowed lambda form as root of compilations. > > Roland. From frederic.parain at oracle.com Wed Mar 15 17:09:20 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 15 Mar 2017 13:09:20 -0400 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: <08a8189c-c2b8-70e4-7fcf-fa088c9c5063@oracle.com> References: <9f25d88f-aeb3-6c72-9549-0f69aa2a34fe@oracle.com> <08a8189c-c2b8-70e4-7fcf-fa088c9c5063@oracle.com> Message-ID: <15D98BF5-4260-48F5-89A3-4A9DE53FCD27@oracle.com> > On Mar 15, 2017, at 06:29, Zolt?n Maj? wrote: > > Hi, > > > On 03/15/2017 09:00 AM, Tobias Hartmann wrote: >> Hi Roland, >> >> On 14.03.2017 17:16, Roland Westrelin wrote: >>> [...] >>> >>> Sometimes a lambda form compiled as the root of a compilation has a >>> signature with object parameters but is passed a value type: so it's >>> passed fields but has no way to know. This could be fixed by always >>> passing value types as references when the target is a lambda form. But >>> then, method handles intrinsics could get reference inputs and call a >>> method that expects value types to be passed as fields. So the code in >>> MethodHandles::generate_method_handle_dispatch() would need to be >>> adjusted to shuffle arguments. That all sounds too complicated so >>> instead I disallowed lambda form as root of compilations. >> I wonder if it's okay to treat value types as objects in such cases. >> >> Zoltan, you found some related problems right? > > Yes. A version of Maurizio's PointValues program triggered an error in C2's type system. > > The test attempted to pass a Q-type to an MethodHandle.invoke(Object o). That results in a type system error at the moment, as C2 considers a Q-type and and L-type to be "unrelated". (The test would, of course work, if the Q-type was first boxed to the matching L-type before calling the invoke method.) > > So maybe the question is: Is a value type a subclass of a java.lang.Object? If yes, we should make C2 aware of that. If not, then I think it's a good idea to bail out compilation if the compiler detects that a Q-type is used in place of an L-type. A value type is *not* a subclass of java.lang.Object. The box of a value type is a subclass of java.lang.Object, and has a L-type signature. > Currently, an L-type and the matching Q-type have the same memory layout, so we could treat them as being the same. But by starting to doing so we'll most likely encounter some difficult-to-trace errors. So I'm more for bailing out compilations (or updating the type system to consider Q-types as subclasses of java.lang.Object). > They have a similar layout, but they don?t have the same behavior nor the same methods: all L-types inherit a set of methods from java.lang.Object. Q-type don?t have any of them. So, trying to handle a Q-type pretending is a L-type is a slippery slope to disaster. Fred > Best regards, > > > Zoltan > >> >> I think it would make sense to add "-Xcomp -XX:-TieredCompilation" to the runtime tests (I did that before, see patch below). >> >> Thanks, >> Tobias >> >> >> --- old/test/runtime/valhalla/valuetypes/DeriveValueTypeCreation.java 2017-03-15 08:54:48.004842144 +0100 >> +++ new/test/runtime/valhalla/valuetypes/DeriveValueTypeCreation.java 2017-03-15 08:54:47.936842147 +0100 >> @@ -43,6 +43,7 @@ >> * @library /testlibrary / >> * @build runtime.valhalla.valuetypes.ValueCapableClass >> * @run main/othervm -Xint -noverify runtime.valhalla.valuetypes.DeriveValueTypeCreation >> + * @run main/othervm -Xcomp -XX:-TieredCompilation -noverify runtime.valhalla.valuetypes.DeriveValueTypeCreation >> */ >> public class DeriveValueTypeCreation { >> --- old/test/runtime/valhalla/valuetypes/InvokeDirect.java 2017-03-15 08:54:48.256842132 +0100 >> +++ new/test/runtime/valhalla/valuetypes/InvokeDirect.java 2017-03-15 08:54:48.188842136 +0100 >> @@ -7,6 +7,7 @@ >> * @summary Value Type invokedirect bytecode test (incomplete until type system defn done) >> * @library /testlibrary / >> * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.InvokeDirect >> + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.InvokeDirect >> */ >> public class InvokeDirect { >> public static void main(String[] args) { >> --- old/test/runtime/valhalla/valuetypes/VDefaultTest.java 2017-03-15 08:54:48.512842121 +0100 >> +++ new/test/runtime/valhalla/valuetypes/VDefaultTest.java 2017-03-15 08:54:48.444842124 +0100 >> @@ -30,6 +30,7 @@ >> * @summary vdefault bytecode test >> * @library /testlibrary / >> * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.VDefaultTest >> + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.VDefaultTest >> */ >> public class VDefaultTest { >> --- old/test/runtime/valhalla/valuetypes/VWithFieldTest.java 2017-03-15 08:54:48.756842109 +0100 >> +++ new/test/runtime/valhalla/valuetypes/VWithFieldTest.java 2017-03-15 08:54:48.692842112 +0100 >> @@ -30,6 +30,7 @@ >> * @summary vwithfield bytecode test >> * @library /testlibrary / >> * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.VWithFieldTest >> + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.VWithFieldTest >> */ >> public class VWithFieldTest { >> --- old/test/runtime/valhalla/valuetypes/ValueTypeArray.java 2017-03-15 08:54:49.000842098 +0100 >> +++ new/test/runtime/valhalla/valuetypes/ValueTypeArray.java 2017-03-15 08:54:48.936842101 +0100 >> @@ -33,6 +33,8 @@ >> * @library /testlibrary / >> * @run main/othervm -noverify -Xint -XX:+ValueArrayFlatten runtime.valhalla.valuetypes.ValueTypeArray >> * @run main/othervm -noverify -Xint -XX:-ValueArrayFlatten runtime.valhalla.valuetypes.ValueTypeArray >> + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation -XX:+ValueArrayFlatten runtime.valhalla.valuetypes.ValueTypeArray >> + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation -XX:-ValueArrayFlatten runtime.valhalla.valuetypes.ValueTypeArray >> */ >> public class ValueTypeArray { >> public static void main(String[] args) { >> --- old/test/runtime/valhalla/valuetypes/ValueTypeCreation.java 2017-03-15 08:54:49.248842086 +0100 >> +++ new/test/runtime/valhalla/valuetypes/ValueTypeCreation.java 2017-03-15 08:54:49.180842089 +0100 >> @@ -7,6 +7,7 @@ >> * @summary Value Type creation test >> * @library /testlibrary / >> * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.ValueTypeCreation >> + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.ValueTypeCreation >> */ >> public class ValueTypeCreation { >> public static void main(String[] args) { >> --- old/test/runtime/valhalla/valuetypes/ValueTypeDensity.java 2017-03-15 08:54:49.496842075 +0100 >> +++ new/test/runtime/valhalla/valuetypes/ValueTypeDensity.java 2017-03-15 08:54:49.428842078 +0100 >> @@ -36,6 +36,7 @@ >> * @run driver ClassFileInstaller sun.hotspot.WhiteBox >> * sun.hotspot.WhiteBox$WhiteBoxPermission >> * @run main/othervm -noverify -Xint -XX:+ValueArrayFlatten -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI ValueTypeDensity >> + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation -XX:+ValueArrayFlatten -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI ValueTypeDensity >> */ >> public class ValueTypeDensity { >> --- old/test/runtime/valhalla/valuetypes/ValueTypeGetField.java 2017-03-15 08:54:49.752842063 +0100 >> +++ new/test/runtime/valhalla/valuetypes/ValueTypeGetField.java 2017-03-15 08:54:49.684842066 +0100 >> @@ -7,6 +7,7 @@ >> * @summary Value Type get field test >> * @library /testlibrary / >> * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.ValueTypeGetField >> + * @run main/othervm -noverify -Xcomp -XX:-TieredCompilation runtime.valhalla.valuetypes.ValueTypeGetField >> */ >> public class ValueTypeGetField { >> --- old/test/runtime/valhalla/valuetypes/VboxUnbox.java 2017-03-15 08:54:50.008842051 +0100 >> +++ new/test/runtime/valhalla/valuetypes/VboxUnbox.java 2017-03-15 08:54:49.940842054 +0100 >> @@ -33,6 +33,7 @@ >> * @library /testlibrary / >> * @build runtime.valhalla.valuetypes.ValueCapableClass >> * @run main/othervm -Xint -noverify runtime.valhalla.valuetypes.VboxUnbox >> + * @run main/othervm -Xcomp -XX:-TieredCompilation -noverify runtime.valhalla.valuetypes.VboxUnbox >> * >> * To dump generated byte-code, add "-Dvalhalla.dumpIsolatedMethodClasses=/tmp/foo" >> */ From john.r.rose at oracle.com Wed Mar 15 17:48:12 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 15 Mar 2017 10:48:12 -0700 Subject: Arrays.copyOf does not work with value type arrays In-Reply-To: <5903439c-6ac8-dc27-adab-0ee0ff3bda1e@oracle.com> References: <5903439c-6ac8-dc27-adab-0ee0ff3bda1e@oracle.com> Message-ID: On Mar 15, 2017, at 7:51 AM, Tobias Hartmann wrote: > > Hi, > > I'm looking into C2 intrinsic support for value types and noticed that below code fails with: > > Exception in thread "main" java.lang.BootstrapMethodError: call site initialization exception > at java.lang.invoke.CallSite.makeSite(CallSite.java:347) > at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:247) > at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:237) > at Test.main(Test.java:23) > Caused by: java.lang.ClassNotFoundException: java/util/Arrays$copyOf$433071630$${QPoint;} > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:372) > at java.lang.invoke.GenericStaticDispatch.metafactory(GenericStaticDispatch.java:14) > at java.lang.invoke.CallSite.makeSite(CallSite.java:308) > ... 3 more > > Is this supposed to work with MVT1.0? This is not supposed to work in MVT1.0 because __ByValue and __Make keywords introduce source-level types not present in MVT1.0. The type "array-of-Q-Point" is going to be confusing to existing library code, until it is properly generified. (The type "array-of-L-Point" would not be problematic, but it is undesirable since each Point is boxed as an L-Point. Such are the tradeoffs of MVT1.0.) MVT1.0 allows the user to work with "flat" arrays of values ("array-of-Q-Foo") but *only* through method handles, not directly in source code. To get the source code story straightened out, we need to formulate the rules for distinguishing "array-of-Q-Foo" from "array-of-L-Foo". The latter type, is relatively useless and perhaps can be omitted totally, but I think that legacy code might have an occasional need to work with it. In any case it's an open issue, and MVT1.0 avoids it. ? John From rwestrel at redhat.com Thu Mar 16 08:19:30 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 16 Mar 2017 09:19:30 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: References: Message-ID: > Is C2 code relying on the ValueFactory_attribute used by vnew? > Vnew and this attribute are supposed to be removed in favor of the > vdefault/vwithfield solution to create values. If this is likely to cause > issues to C2, it?s time to speak up. I don't think we have a problem with vnew and the ValueFactory_attribute going away. We'll just have to adjust the code. Roland. From tobias.hartmann at oracle.com Thu Mar 16 08:27:07 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 Mar 2017 09:27:07 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: References: Message-ID: <9f92ab3a-5f80-7048-6a2e-0e31ebe34b7c@oracle.com> On 16.03.2017 09:19, Roland Westrelin wrote: >> Is C2 code relying on the ValueFactory_attribute used by vnew? >> Vnew and this attribute are supposed to be removed in favor of the >> vdefault/vwithfield solution to create values. If this is likely to cause >> issues to C2, it?s time to speak up. > > I don't think we have a problem with vnew and the ValueFactory_attribute > going away. We'll just have to adjust the code. Yes, I agree. Please let us now upfront, so we can adjust our code. Thanks, Tobias From david.simms at oracle.com Thu Mar 16 08:56:00 2017 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 16 Mar 2017 08:56:00 +0000 Subject: hg: valhalla/valhalla: Value Types with ref fields, GC: Serial and G1 Message-ID: <201703160856.v2G8u0ch020614@aojmv0008.oracle.com> Changeset: 657545a3f810 Author: dsimms Date: 2017-03-16 08:32 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/657545a3f810 Value Types with ref fields, GC: Serial and G1 ! test/lib/sun/hotspot/WhiteBox.java From david.simms at oracle.com Thu Mar 16 08:56:10 2017 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 16 Mar 2017 08:56:10 +0000 Subject: hg: valhalla/valhalla/hotspot: Value Types with ref fields, GC: Serial and G1 Message-ID: <201703160856.v2G8uAom020702@aojmv0008.oracle.com> Changeset: 61e63d55c274 Author: dsimms Date: 2017-03-16 08:32 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/61e63d55c274 Value Types with ref fields, GC: Serial and G1 ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/valueArrayKlass.cpp ! src/share/vm/oops/valueArrayKlass.hpp ! src/share/vm/oops/valueArrayKlass.inline.hpp ! src/share/vm/oops/valueArrayOop.hpp ! src/share/vm/oops/valueKlass.cpp ! src/share/vm/oops/valueKlass.hpp ! src/share/vm/oops/valueKlass.inline.hpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! test/runtime/valhalla/valuetypes/DeriveValueTypeCreation.java ! test/runtime/valhalla/valuetypes/Person.java + test/runtime/valhalla/valuetypes/PersonVcc.java + test/runtime/valhalla/valuetypes/ValueOops.java From tobias.hartmann at oracle.com Thu Mar 16 09:58:55 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 Mar 2017 10:58:55 +0100 Subject: Arrays.copyOf does not work with value type arrays In-Reply-To: References: <5903439c-6ac8-dc27-adab-0ee0ff3bda1e@oracle.com> Message-ID: Thanks John and Mr. Simms for the detailed answer! I'll leave this for now. Best regards, Tobias On 15.03.2017 18:48, John Rose wrote: > On Mar 15, 2017, at 7:51 AM, Tobias Hartmann wrote: >> >> Hi, >> >> I'm looking into C2 intrinsic support for value types and noticed that below code fails with: >> >> Exception in thread "main" java.lang.BootstrapMethodError: call site initialization exception >> at java.lang.invoke.CallSite.makeSite(CallSite.java:347) >> at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:247) >> at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:237) >> at Test.main(Test.java:23) >> Caused by: java.lang.ClassNotFoundException: java/util/Arrays$copyOf$433071630$${QPoint;} >> at java.lang.Class.forName0(Native Method) >> at java.lang.Class.forName(Class.java:372) >> at java.lang.invoke.GenericStaticDispatch.metafactory(GenericStaticDispatch.java:14) >> at java.lang.invoke.CallSite.makeSite(CallSite.java:308) >> ... 3 more >> >> Is this supposed to work with MVT1.0? > > This is not supposed to work in MVT1.0 because __ByValue and __Make keywords > introduce source-level types not present in MVT1.0. The type "array-of-Q-Point" is > going to be confusing to existing library code, until it is properly generified. > > (The type "array-of-L-Point" would not be problematic, but it is undesirable since > each Point is boxed as an L-Point. Such are the tradeoffs of MVT1.0.) > > MVT1.0 allows the user to work with "flat" arrays of values ("array-of-Q-Foo") > but *only* through method handles, not directly in source code. > > To get the source code story straightened out, we need to formulate the rules > for distinguishing "array-of-Q-Foo" from "array-of-L-Foo". The latter type, is > relatively useless and perhaps can be omitted totally, but I think that legacy > code might have an occasional need to work with it. In any case it's an open > issue, and MVT1.0 avoids it. > > ? John > From david.simms at oracle.com Thu Mar 16 12:46:46 2017 From: david.simms at oracle.com (David Simms) Date: Thu, 16 Mar 2017 13:46:46 +0100 Subject: RFR: Klass is_Array() fix, and support for value type ref fields with Parallel GC Message-ID: <30a548e8-3bfd-dc48-3094-57a436af67aa@oracle.com> Hi all, http://cr.openjdk.java.net/~dsimms/valhalla/valueoops/webrev1/ As follow-up to "Value Types with ref fields, GC: Serial and G1" change earlier today, I realized only a few simple changes were required for basic Parallel GC support. Main outage: ValueArrayKlass::oop_pc_follow_contents() is not parallel as is the case for ObjArrayKlass. The main change is actually a bug fix, whereby Klass layout helper was always set "is_typeArray()" to true for valueArrayKlass. Previous to adding reference fields to value type this wasn't much of a problem. There is a fair amount of GC code which checks "is_typeArray()" then "nothing to do here". One could argue that value arrays, could use the obj array bit for rather than testing "valueKlass::contains_oops()", but for clarity, I simply added another discrete array tag bit. Arrays are one of three things, but not two of three as was the case (value and type array). Cheers /David Simms From rwestrel at redhat.com Thu Mar 16 13:11:19 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 16 Mar 2017 14:11:19 +0100 Subject: call to __Value methods can't pass fields as arguments Message-ID: http://cr.openjdk.java.net/~roland/valhalla/__valuemethods/webrev.00/ When calling a method that's defined only by __Value (toString etc.), we can't pass fields, we have to pass a reference (the callee is generic so has no way to know what fields to expect). There's a little tweak to some runtime code so someone from runtime should probably take a look. Roland. From rwestrel at redhat.com Thu Mar 16 13:33:12 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 16 Mar 2017 14:33:12 +0100 Subject: remove -Xint from runtime tests In-Reply-To: References: <9c99d1c1-c582-7462-0273-940e6c390112@oracle.com> Message-ID: > Most of the runtime valhalla tests take only a seconds, FWIW I'd like to > see both "-Xint" and "-Xcomp" (i.e. multiple jtreg run tags). This? http://cr.openjdk.java.net/~roland/valhalla/runtimetests/webrev.01/ Roland. From zoltan.majo at oracle.com Thu Mar 16 13:49:17 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 16 Mar 2017 14:49:17 +0100 Subject: collection of small fixes from running runtime tests with -Xcomp In-Reply-To: <9f92ab3a-5f80-7048-6a2e-0e31ebe34b7c@oracle.com> References: <9f92ab3a-5f80-7048-6a2e-0e31ebe34b7c@oracle.com> Message-ID: <72d2e75b-cd4c-489a-6454-235ab908d5f5@oracle.com> Hi, On 03/16/2017 09:27 AM, Tobias Hartmann wrote: > On 16.03.2017 09:19, Roland Westrelin wrote: >>> Is C2 code relying on the ValueFactory_attribute used by vnew? >>> Vnew and this attribute are supposed to be removed in favor of the >>> vdefault/vwithfield solution to create values. If this is likely to cause >>> issues to C2, it?s time to speak up. >> I don't think we have a problem with vnew and the ValueFactory_attribute >> going away. We'll just have to adjust the code. > Yes, I agree. Please let us now upfront, so we can adjust our code. I also agree. I actually hoped to have removed the dependence on the ValueFactory_attribute with the changeset: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4be6e6ebc443 I'm not sure if more remains to be done. Best regards, Zoltan > > Thanks, > Tobias From david.simms at oracle.com Fri Mar 17 08:17:33 2017 From: david.simms at oracle.com (David Simms) Date: Fri, 17 Mar 2017 09:17:33 +0100 Subject: remove -Xint from runtime tests In-Reply-To: References: <9c99d1c1-c582-7462-0273-940e6c390112@oracle.com> Message-ID: <7a1d71f5-513b-a771-bec1-4d23fc4bf43b@oracle.com> This looks good. Yet, when I add -Xcomp to "runtime/valhalla/valuetypes/ValueOops.java", I got a ShouldReachHere() in "/localhome/davids/hotspot/valhalla/hotspot/src/share/vm/c1/c1_ValueType.cpp:140". I thought C1 was disabled ? (Trouble grokking tiered option) /Mr. Simms On 16/03/17 14:33, Roland Westrelin wrote: >> Most of the runtime valhalla tests take only a seconds, FWIW I'd like to >> see both "-Xint" and "-Xcomp" (i.e. multiple jtreg run tags). > This? > > http://cr.openjdk.java.net/~roland/valhalla/runtimetests/webrev.01/ > > Roland. From rwestrel at redhat.com Fri Mar 17 08:31:12 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 17 Mar 2017 09:31:12 +0100 Subject: remove -Xint from runtime tests In-Reply-To: <7a1d71f5-513b-a771-bec1-4d23fc4bf43b@oracle.com> References: <9c99d1c1-c582-7462-0273-940e6c390112@oracle.com> <7a1d71f5-513b-a771-bec1-4d23fc4bf43b@oracle.com> Message-ID: > I thought C1 was disabled ? (Trouble grokking tiered option) Have you applied that part of the patch? http://cr.openjdk.java.net/~roland/valhalla/runtimetests/webrev.01/src/share/vm/runtime/arguments.cpp.patch Roland. From stanislav.smirnov at oracle.com Fri Mar 17 08:31:37 2017 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Fri, 17 Mar 2017 11:31:37 +0300 Subject: remove -Xint from runtime tests In-Reply-To: <7a1d71f5-513b-a771-bec1-4d23fc4bf43b@oracle.com> References: <9c99d1c1-c582-7462-0273-940e6c390112@oracle.com> <7a1d71f5-513b-a771-bec1-4d23fc4bf43b@oracle.com> Message-ID: Well, you can leave both * @run main/othervm -noverify -Xint runtime.valhalla.valuetypes.VWithFieldTest * @run main/othervm -noverify -Xcomp runtime.valhalla.valuetypes.VWithFieldTest it will be just two executions. Best regards, Stanislav Smirnov > On 17 Mar 2017, at 11:17, David Simms wrote: > > This looks good. > > Yet, when I add -Xcomp to "runtime/valhalla/valuetypes/ValueOops.java", I got a ShouldReachHere() in "/localhome/davids/hotspot/valhalla/hotspot/src/share/vm/c1/c1_ValueType.cpp:140". > > I thought C1 was disabled ? (Trouble grokking tiered option) > > /Mr. Simms > > On 16/03/17 14:33, Roland Westrelin wrote: >>> Most of the runtime valhalla tests take only a seconds, FWIW I'd like to >>> see both "-Xint" and "-Xcomp" (i.e. multiple jtreg run tags). >> This? >> >> http://cr.openjdk.java.net/~roland/valhalla/runtimetests/webrev.01/ >> >> Roland. > > From david.simms at oracle.com Fri Mar 17 09:04:43 2017 From: david.simms at oracle.com (David Simms) Date: Fri, 17 Mar 2017 10:04:43 +0100 Subject: remove -Xint from runtime tests In-Reply-To: References: <9c99d1c1-c582-7462-0273-940e6c390112@oracle.com> <7a1d71f5-513b-a771-bec1-4d23fc4bf43b@oracle.com> Message-ID: <2c143129-94a4-445f-9d97-9c7f160f714a@oracle.com> Oops, cheers, good to go. On 17/03/17 09:31, Roland Westrelin wrote: >> I thought C1 was disabled ? (Trouble grokking tiered option) > Have you applied that part of the patch? > > http://cr.openjdk.java.net/~roland/valhalla/runtimetests/webrev.01/src/share/vm/runtime/arguments.cpp.patch > > Roland. From rwestrel at redhat.com Fri Mar 17 09:35:27 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 17 Mar 2017 10:35:27 +0100 Subject: remove -Xint from runtime tests In-Reply-To: <2c143129-94a4-445f-9d97-9c7f160f714a@oracle.com> References: <9c99d1c1-c582-7462-0273-940e6c390112@oracle.com> <7a1d71f5-513b-a771-bec1-4d23fc4bf43b@oracle.com> <2c143129-94a4-445f-9d97-9c7f160f714a@oracle.com> Message-ID: > Oops, cheers, good to go. Thanks. Roland. From rwestrel at redhat.com Fri Mar 17 09:41:00 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Fri, 17 Mar 2017 09:41:00 +0000 Subject: hg: valhalla/valhalla/hotspot: 2 new changesets Message-ID: <201703170941.v2H9f0kE007355@aojmv0008.oracle.com> Changeset: 4c4c8e58c2b3 Author: roland Date: 2017-03-16 14:20 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4c4c8e58c2b3 tiered off ! src/share/vm/runtime/arguments.cpp Changeset: a7755fcbf968 Author: roland Date: 2017-03-16 14:27 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a7755fcbf968 runtime tests with -Xcomp ! test/runtime/valhalla/valuetypes/DeriveValueTypeCreation.java ! test/runtime/valhalla/valuetypes/InvokeDirect.java ! test/runtime/valhalla/valuetypes/VDefaultTest.java ! test/runtime/valhalla/valuetypes/VWithFieldTest.java ! test/runtime/valhalla/valuetypes/ValueTypeArray.java ! test/runtime/valhalla/valuetypes/ValueTypeCreation.java ! test/runtime/valhalla/valuetypes/ValueTypeDensity.java ! test/runtime/valhalla/valuetypes/ValueTypeGetField.java ! test/runtime/valhalla/valuetypes/VboxUnbox.java From tobias.hartmann at oracle.com Tue Mar 21 09:55:57 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 21 Mar 2017 10:55:57 +0100 Subject: call to __Value methods can't pass fields as arguments In-Reply-To: References: Message-ID: Hi Roland, On 16.03.2017 14:11, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/valhalla/__valuemethods/webrev.00/ This looks good to me! Best regards, Tobias > When calling a method that's defined only by __Value (toString etc.), > we can't pass fields, we have to pass a reference (the callee is generic > so has no way to know what fields to expect). > > There's a little tweak to some runtime code so someone from runtime > should probably take a look. > > Roland. > From frederic.parain at oracle.com Tue Mar 21 21:04:58 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 21 Mar 2017 17:04:58 -0400 Subject: RFR: Klass is_Array() fix, and support for value type ref fields with Parallel GC In-Reply-To: <30a548e8-3bfd-dc48-3094-57a436af67aa@oracle.com> References: <30a548e8-3bfd-dc48-3094-57a436af67aa@oracle.com> Message-ID: <86C57284-2217-43AD-83DE-2CE9F7ABAA87@oracle.com> Looks good to me. Fred > On Mar 16, 2017, at 08:46, David Simms wrote: > > Hi all, > > http://cr.openjdk.java.net/~dsimms/valhalla/valueoops/webrev1/ > > As follow-up to "Value Types with ref fields, GC: Serial and G1" change earlier today, I realized only a few simple changes were required for basic Parallel GC support. Main outage: ValueArrayKlass::oop_pc_follow_contents() is not parallel as is the case for ObjArrayKlass. > > The main change is actually a bug fix, whereby Klass layout helper was always set "is_typeArray()" to true for valueArrayKlass. Previous to adding reference fields to value type this wasn't much of a problem. There is a fair amount of GC code which checks "is_typeArray()" then "nothing to do here". > > One could argue that value arrays, could use the obj array bit for rather than testing "valueKlass::contains_oops()", but for clarity, I simply added another discrete array tag bit. Arrays are one of three things, but not two of three as was the case (value and type array). > > > Cheers > > /David Simms > > > > From david.simms at oracle.com Wed Mar 22 09:13:12 2017 From: david.simms at oracle.com (david.simms at oracle.com) Date: Wed, 22 Mar 2017 09:13:12 +0000 Subject: hg: valhalla/valhalla/hotspot: 2 new changesets Message-ID: <201703220913.v2M9DCg1022759@aojmv0008.oracle.com> Changeset: 395af99e676c Author: dsimms Date: 2017-03-16 14:43 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/395af99e676c Klass is_Array() fix, and support for value type ref fields with Parallel GC ! src/share/vm/gc/parallel/psCompactionManager.cpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/valueArrayKlass.cpp ! src/share/vm/oops/valueArrayKlass.hpp ! test/runtime/valhalla/valuetypes/ValueOops.java Changeset: 7817efa85fda Author: dsimms Date: 2017-03-22 08:59 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7817efa85fda Merge From karen.kinnear at oracle.com Wed Mar 22 17:06:46 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 22 Mar 2017 13:06:46 -0400 Subject: CFV: New Valhalla Committer: Lois Foltan In-Reply-To: References: Message-ID: Voting for Lois Foltan [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. thanks, Karen [1] http://mail.openjdk.java.net/pipermail/valhalla-dev/2017-March/002230.html From david.simms at oracle.com Thu Mar 23 09:31:18 2017 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 23 Mar 2017 09:31:18 +0000 Subject: hg: valhalla/valhalla/jdk: substitutabilityTest fixes Message-ID: <201703230931.v2N9VInr007608@aojmv0008.oracle.com> Changeset: 94d536aaf185 Author: dsimms Date: 2017-03-23 10:30 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/94d536aaf185 substitutabilityTest fixes ! src/java.base/share/classes/jdk/experimental/value/ValueType.java From david.simms at oracle.com Thu Mar 23 12:27:37 2017 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 23 Mar 2017 12:27:37 +0000 Subject: hg: valhalla/valhalla/hotspot: raw_value_byte_size fixes Message-ID: <201703231227.v2NCRbLc002184@aojmv0008.oracle.com> Changeset: b8e9e6847067 Author: dsimms Date: 2017-03-23 13:26 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/b8e9e6847067 raw_value_byte_size fixes ! src/share/vm/oops/valueKlass.cpp From maurizio.cimadamore at oracle.com Thu Mar 23 13:54:53 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 23 Mar 2017 13:54:53 +0000 Subject: Proposal for a simplified syntax for invoking @FunctionalInterface methods In-Reply-To: References: Message-ID: <45c4ab8a-9571-c428-2439-a172ec7ebeed@oracle.com> This is a question for lambda-dev. Something like this was present in the very first draft of the lambda language support [1] - syntax aside, the main issue with this avenue, is that Java has separate namespaces for methods and fields. That is, you are able to declare a field AND a method whose type is 'doubleString'. So, if you start treating fields in a more method-y way, the namespace issue might pop up, and ambiguities might ensue. [1] - http://cr.openjdk.java.net/~mr/lambda/straw-man/ Maurizio On 02/03/17 15:10, Timothy Fagan wrote: > I'm not sure if this is the appropriate forum, or if this idea has been > proposed elsewhere, but I'd like to suggest a simplified syntax for > invoking @FunctionalInterface methods. > > The idea is that if: > * foo is a object reference (field, local variable or parameter) whose > type is a @FunctionalInterface > * there is a statement or expression where foo is used as if it were a > method name > * the formal parameters of the statement or expression match the formal > parameters of the abstract method on the @FunctionalInterface > * the formal parameters of the statement or expression do NOT match the > formal parameters of any other method in scope named foo > Then: > * the statement or expression is compiled as an invocation of the > @FunctionalInterface abstract method on foo's type. > > E.g. > > Function doubleString = s -> s + s; > > // prints "hellohello" > System.out.println(*doubleString*("hello")); > > -Timothy From me at noctarius.com Thu Mar 23 14:01:49 2017 From: me at noctarius.com (Christoph Engelbert) Date: Thu, 23 Mar 2017 07:01:49 -0700 Subject: Proposal for a simplified syntax for invoking @FunctionalInterface methods In-Reply-To: <45c4ab8a-9571-c428-2439-a172ec7ebeed@oracle.com> References: <45c4ab8a-9571-c428-2439-a172ec7ebeed@oracle.com> Message-ID: <55DDB3B2-EE40-4B92-AB2E-72BBACE204E8@noctarius.com> Hey guys, Comments inline: > On 23. Mar 2017, at 06:54, Maurizio Cimadamore wrote: > > This is a question for lambda-dev. > > Something like this was present in the very first draft of the lambda language support [1] - syntax aside, the main issue with this avenue, is that Java has separate namespaces for methods and fields. That is, you are able to declare a field AND a method whose type is 'doubleString'. So, if you start treating fields in a more method-y way, the namespace issue might pop up, and ambiguities might ensue. But wouldn?t that just be another layer of name shadowing like we already have on fields? I think it?s all about precedence of field over method or method over field. Do I miss something here (I probably do :-))? > > [1] - http://cr.openjdk.java.net/~mr/lambda/straw-man/ > > Maurizio > > > On 02/03/17 15:10, Timothy Fagan wrote: >> I'm not sure if this is the appropriate forum, or if this idea has been >> proposed elsewhere, but I'd like to suggest a simplified syntax for >> invoking @FunctionalInterface methods. >> >> The idea is that if: >> * foo is a object reference (field, local variable or parameter) whose >> type is a @FunctionalInterface >> * there is a statement or expression where foo is used as if it were a >> method name >> * the formal parameters of the statement or expression match the formal >> parameters of the abstract method on the @FunctionalInterface >> * the formal parameters of the statement or expression do NOT match the >> formal parameters of any other method in scope named foo >> Then: >> * the statement or expression is compiled as an invocation of the >> @FunctionalInterface abstract method on foo's type. >> >> E.g. >> >> Function doubleString = s -> s + s; >> >> // prints "hellohello" >> System.out.println(*doubleString*("hello")); >> >> -Timothy > From maurizio.cimadamore at oracle.com Thu Mar 23 14:10:18 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 23 Mar 2017 14:10:18 +0000 Subject: Proposal for a simplified syntax for invoking @FunctionalInterface methods In-Reply-To: <55DDB3B2-EE40-4B92-AB2E-72BBACE204E8@noctarius.com> References: <45c4ab8a-9571-c428-2439-a172ec7ebeed@oracle.com> <55DDB3B2-EE40-4B92-AB2E-72BBACE204E8@noctarius.com> Message-ID: <26c91565-1df5-76ed-208e-713b9336afb6@oracle.com> Please move this discussion where it belongs, as suggested. I note that lambda-dev is no longer active, but compiler-dev is. Maurizio On 23/03/17 14:01, Christoph Engelbert wrote: > Hey guys, > > Comments inline: > >> On 23. Mar 2017, at 06:54, Maurizio Cimadamore wrote: >> >> This is a question for lambda-dev. >> >> Something like this was present in the very first draft of the lambda language support [1] - syntax aside, the main issue with this avenue, is that Java has separate namespaces for methods and fields. That is, you are able to declare a field AND a method whose type is 'doubleString'. So, if you start treating fields in a more method-y way, the namespace issue might pop up, and ambiguities might ensue. > But wouldn?t that just be another layer of name shadowing like we already have on fields? I think it?s all about precedence of field over method or method over field. Do I miss something here (I probably do :-))? > >> [1] - http://cr.openjdk.java.net/~mr/lambda/straw-man/ >> >> Maurizio >> >> >> On 02/03/17 15:10, Timothy Fagan wrote: >>> I'm not sure if this is the appropriate forum, or if this idea has been >>> proposed elsewhere, but I'd like to suggest a simplified syntax for >>> invoking @FunctionalInterface methods. >>> >>> The idea is that if: >>> * foo is a object reference (field, local variable or parameter) whose >>> type is a @FunctionalInterface >>> * there is a statement or expression where foo is used as if it were a >>> method name >>> * the formal parameters of the statement or expression match the formal >>> parameters of the abstract method on the @FunctionalInterface >>> * the formal parameters of the statement or expression do NOT match the >>> formal parameters of any other method in scope named foo >>> Then: >>> * the statement or expression is compiled as an invocation of the >>> @FunctionalInterface abstract method on foo's type. >>> >>> E.g. >>> >>> Function doubleString = s -> s + s; >>> >>> // prints "hellohello" >>> System.out.println(*doubleString*("hello")); >>> >>> -Timothy From tobias.hartmann at oracle.com Thu Mar 23 14:50:56 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Mar 2017 15:50:56 +0100 Subject: RFR: -XX:+ValueTypePassFieldsAsArgs is broken with value type fields < 4 byte Message-ID: Hi, please review the following fix: http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.11/ When passing value type fields as arguments, the IC2 and C2I adapters need to read/write the value type fields from/to the (heap) buffer. Right now, we always read/write >= 4 bytes. I fixed this by reading/writing the appropriate field size and also refactored the code. Thanks, Tobias From david.simms at oracle.com Thu Mar 23 16:55:30 2017 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 23 Mar 2017 16:55:30 +0000 Subject: hg: valhalla/valhalla/jdk: Further correction of ifcmp use with type desc string Message-ID: <201703231655.v2NGtUK9011218@aojmv0008.oracle.com> Changeset: 6e086f285e3a Author: dsimms Date: 2017-03-23 17:51 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6e086f285e3a Further correction of ifcmp use with type desc string ! src/java.base/share/classes/jdk/experimental/value/MethodHandleBuilder.java ! src/java.base/share/classes/jdk/experimental/value/ValueType.java From rwestrel at redhat.com Fri Mar 24 14:56:07 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 24 Mar 2017 15:56:07 +0100 Subject: RFR: -XX:+ValueTypePassFieldsAsArgs is broken with value type fields < 4 byte In-Reply-To: References: Message-ID: > please review the following fix: > http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.11/ Looks good to me. Thanks for fixing this. Roland. From tobias.hartmann at oracle.com Fri Mar 24 14:56:55 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 24 Mar 2017 15:56:55 +0100 Subject: RFR: -XX:+ValueTypePassFieldsAsArgs is broken with value type fields < 4 byte In-Reply-To: References: Message-ID: <8cd65c3a-596d-92ed-8620-13edb4ae03c4@oracle.com> Hi Roland, thanks for the review! Best regards, Tobias On 24.03.2017 15:56, Roland Westrelin wrote: > >> please review the following fix: >> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.11/ > > Looks good to me. Thanks for fixing this. > > Roland. > From frederic.parain at oracle.com Fri Mar 24 15:01:36 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 24 Mar 2017 11:01:36 -0400 Subject: call to __Value methods can't pass fields as arguments In-Reply-To: References: Message-ID: <8C9E2B06-1C19-4B8F-AB65-00861880B356@oracle.com> Hi Roland, Thank you for finding this issue with the __Value methods, I?m concerned with changes in sharedRuntime.cpp:2607: 2605 ValueKlass* vk = ValueKlass::cast(holder); 2606 if (vk == SystemDictionary::___Value_klass()) { 2607 sig_extended.push(SigEntry(T_OBJECT)); 2608 } else { 2609 const GrowableArray& sig_vk = collect_fields(vk); 2610 sig_extended.appendAll(&sig_vk); 2611 } Is it trying passing a reference to a standalone value by pretending that it is an Object? Fred > On Mar 21, 2017, at 05:55, Tobias Hartmann wrote: > > Hi Roland, > > On 16.03.2017 14:11, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/valhalla/__valuemethods/webrev.00/ > > This looks good to me! > > Best regards, > Tobias > >> When calling a method that's defined only by __Value (toString etc.), >> we can't pass fields, we have to pass a reference (the callee is generic >> so has no way to know what fields to expect). >> >> There's a little tweak to some runtime code so someone from runtime >> should probably take a look. >> >> Roland. >> From tobias.hartmann at oracle.com Fri Mar 24 15:02:30 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Fri, 24 Mar 2017 15:02:30 +0000 Subject: hg: valhalla/valhalla/hotspot: -XX:+ValueTypePassFieldsAsArgs is broken with value type fields < 4 byte Message-ID: <201703241502.v2OF2Uam024222@aojmv0008.oracle.com> Changeset: aadec3f94870 Author: thartmann Date: 2017-03-24 16:01 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/aadec3f94870 -XX:+ValueTypePassFieldsAsArgs is broken with value type fields < 4 byte Reviewed-by: roland ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java ! test/runtime/valhalla/valuetypes/ValueOops.java From rwestrel at redhat.com Fri Mar 24 15:08:28 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 24 Mar 2017 16:08:28 +0100 Subject: call to __Value methods can't pass fields as arguments In-Reply-To: <8C9E2B06-1C19-4B8F-AB65-00861880B356@oracle.com> References: <8C9E2B06-1C19-4B8F-AB65-00861880B356@oracle.com> Message-ID: Hi Fred, Thanks for looking at this. > Thank you for finding this issue with the __Value methods, > > I?m concerned with changes in sharedRuntime.cpp:2607: > > 2605 ValueKlass* vk = ValueKlass::cast(holder); > > 2606 if (vk == SystemDictionary::___Value_klass()) { > 2607 sig_extended.push(SigEntry(T_OBJECT)); > 2608 } else { > > 2609 const GrowableArray& sig_vk = collect_fields(vk); > 2610 sig_extended.appendAll(&sig_vk); > > 2611 } > > Is it trying passing a reference to a standalone value by pretending that it is > an Object? It is not. It's recording that a _Value should be passed as a reference so the logic that performs the allocation of arguments to registers picks up a register that can hold a reference. Using T_OBJECT here is ugly. It should probably be revisited. I'll add a comment. Roland. From tobias.hartmann at oracle.com Fri Mar 24 15:13:49 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Fri, 24 Mar 2017 15:13:49 +0000 Subject: hg: valhalla/valhalla/hotspot: Reverted accidental changes in ValueOops.java Message-ID: <201703241513.v2OFDoRh026835@aojmv0008.oracle.com> Changeset: 57f9b6cfb802 Author: thartmann Date: 2017-03-24 16:12 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/57f9b6cfb802 Reverted accidental changes in ValueOops.java ! test/runtime/valhalla/valuetypes/ValueOops.java From frederic.parain at oracle.com Fri Mar 24 15:21:07 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 24 Mar 2017 11:21:07 -0400 Subject: call to __Value methods can't pass fields as arguments In-Reply-To: References: <8C9E2B06-1C19-4B8F-AB65-00861880B356@oracle.com> Message-ID: Roland, Cannot we use T_VALUETYPE instead of T_OBJECT? Fred > On Mar 24, 2017, at 11:08, Roland Westrelin wrote: > > > Hi Fred, > > Thanks for looking at this. > >> Thank you for finding this issue with the __Value methods, >> >> I?m concerned with changes in sharedRuntime.cpp:2607: >> >> 2605 ValueKlass* vk = ValueKlass::cast(holder); >> >> 2606 if (vk == SystemDictionary::___Value_klass()) { >> 2607 sig_extended.push(SigEntry(T_OBJECT)); >> 2608 } else { >> >> 2609 const GrowableArray& sig_vk = collect_fields(vk); >> 2610 sig_extended.appendAll(&sig_vk); >> >> 2611 } >> >> Is it trying passing a reference to a standalone value by pretending that it is >> an Object? > > It is not. It's recording that a _Value should be passed as a reference > so the logic that performs the allocation of arguments to registers > picks up a register that can hold a reference. Using T_OBJECT here is > ugly. It should probably be revisited. I'll add a comment. > > Roland. From rwestrel at redhat.com Fri Mar 24 15:28:59 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 24 Mar 2017 16:28:59 +0100 Subject: call to __Value methods can't pass fields as arguments In-Reply-To: References: <8C9E2B06-1C19-4B8F-AB65-00861880B356@oracle.com> Message-ID: > Cannot we use T_VALUETYPE instead of T_OBJECT? That list already includes T_VALUETYPE elements for another purpose. collect_fields() has a comment that explains why. // Value type arguments are not passed by reference, instead each // field of the value type is passed as an argument. This helper // function collects the fields of the value types (including embedded // value type's fields) in a list. Included with the field's type is // the offset of each field in the value type: i2c and c2i adapters // need that to load or store fields. Finally, the list of fields is // sorted in order of increasing offsets: the adapters and the // compiled code need and agreed upon order of fields. // // The list of basic types that is returned starts with a T_VALUETYPE // and ends with an extra T_VOID. T_VALUETYPE/T_VOID are used as // delimiters. Every entry between the two is a field of the value // type. If there's an embedded value type in the list, it also starts // with a T_VALUETYPE and ends with a T_VOID. This is so we can // generate a unique fingerprint for the method's adapters and we can // generate the list of basic types from the interpreter point of view // (value types passed as reference: iterate on the list until a // T_VALUETYPE, drop everything until and including the closing // T_VOID) or the compiler point of view (each field of the value // types is an argument: drop all T_VALUETYPE/T_VOID from the list). Roland. From frederic.parain at oracle.com Fri Mar 24 15:37:53 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 24 Mar 2017 11:37:53 -0400 Subject: call to __Value methods can't pass fields as arguments In-Reply-To: References: <8C9E2B06-1C19-4B8F-AB65-00861880B356@oracle.com> Message-ID: <87A46302-60C8-4CE3-9DD7-B0DF883556CB@oracle.com> OK. Let?s go with T_OBJECT right now (with a comment please). Could the calling convention be revisited later? 1 - to have T_VALUETYPE being a real reference to a standalone value (and then could be used in the case we are discussing) 2 - to add a special delimiter type instead of overloading T_VALUETYPE I?m concerned that the overloaded meaning T_VALUETYPE could strike us back later. Fred > On Mar 24, 2017, at 11:28, Roland Westrelin wrote: > > >> Cannot we use T_VALUETYPE instead of T_OBJECT? > > That list already includes T_VALUETYPE elements for another > purpose. collect_fields() has a comment that explains why. > > // Value type arguments are not passed by reference, instead each > // field of the value type is passed as an argument. This helper > // function collects the fields of the value types (including embedded > // value type's fields) in a list. Included with the field's type is > // the offset of each field in the value type: i2c and c2i adapters > // need that to load or store fields. Finally, the list of fields is > // sorted in order of increasing offsets: the adapters and the > // compiled code need and agreed upon order of fields. > // > // The list of basic types that is returned starts with a T_VALUETYPE > // and ends with an extra T_VOID. T_VALUETYPE/T_VOID are used as > // delimiters. Every entry between the two is a field of the value > // type. If there's an embedded value type in the list, it also starts > // with a T_VALUETYPE and ends with a T_VOID. This is so we can > // generate a unique fingerprint for the method's adapters and we can > // generate the list of basic types from the interpreter point of view > // (value types passed as reference: iterate on the list until a > // T_VALUETYPE, drop everything until and including the closing > // T_VOID) or the compiler point of view (each field of the value > // types is an argument: drop all T_VALUETYPE/T_VOID from the list). > > Roland. From tobias.hartmann at oracle.com Mon Mar 27 13:31:24 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Mar 2017 15:31:24 +0200 Subject: Adapter sharing is broken with -XX:+ValueTypePassFieldsAsArgs Message-ID: <2bb21a8a-65df-7e7e-cd6b-a0aee051d646@oracle.com> Hi, please review the following fix: http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.12/ The C2I and I2C adapters of different methods are shared if the methods have a matching signature. Arguments of type T_BOOLEAN, T_BYTE, T_SHORT and T_CHAR are widened to type T_INT. This does not work with -XX:+ValueTypePassFieldsAsArgs because value types are passed field-by-field and to be able to load/store the correct values from/to the buffer, we need an adapter that matches with the exact field type in the signature. Thanks to Fred for catching and reporting this issue! Best regards, Tobias From rwestrel at redhat.com Mon Mar 27 13:43:22 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 27 Mar 2017 15:43:22 +0200 Subject: Adapter sharing is broken with -XX:+ValueTypePassFieldsAsArgs In-Reply-To: <2bb21a8a-65df-7e7e-cd6b-a0aee051d646@oracle.com> References: <2bb21a8a-65df-7e7e-cd6b-a0aee051d646@oracle.com> Message-ID: Hi Tobias, > http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.12/ Why the change lines 2254-2281? You skip over the T_VALUETYPE/T_VOID markers, right? I don't think that's correct. With your change: class MyValue1 { int f1; long f2; } class MyValue3 { int f1; } class MyValue4 { long f2; } class MyValue2 { MyValue3 f1; MyValue4 f2; } MyValue1 and MyValue2 would share the same adapters but that would only be correct if they have the same layout (because now adapters embed hard coded offsets for fields). Is it true? Is it guaranteed that it doesn't change in the future? Roland. From rwestrel at redhat.com Mon Mar 27 13:50:40 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 27 Mar 2017 15:50:40 +0200 Subject: call to __Value methods can't pass fields as arguments In-Reply-To: <87A46302-60C8-4CE3-9DD7-B0DF883556CB@oracle.com> References: <8C9E2B06-1C19-4B8F-AB65-00861880B356@oracle.com> <87A46302-60C8-4CE3-9DD7-B0DF883556CB@oracle.com> Message-ID: > Let?s go with T_OBJECT right now (with a comment please). > > Could the calling convention be revisited later? > 1 - to have T_VALUETYPE being a real reference to a standalone > value (and then could be used in the case we are discussing) > 2 - to add a special delimiter type instead of overloading T_VALUETYPE Yes. I'll think about it. Roland. From tobias.hartmann at oracle.com Mon Mar 27 14:10:16 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Mar 2017 16:10:16 +0200 Subject: Adapter sharing is broken with -XX:+ValueTypePassFieldsAsArgs In-Reply-To: References: <2bb21a8a-65df-7e7e-cd6b-a0aee051d646@oracle.com> Message-ID: <3fb2b17e-a2bd-da71-267c-5b5e45c6283c@oracle.com> Hi Roland, thanks for looking at this! On 27.03.2017 15:43, Roland Westrelin wrote: > Why the change lines 2254-2281? > You skip over the T_VALUETYPE/T_VOID markers, right? Yes, I check for the T_VALUETYPE/T_VOID scope to avoid widening when we are passing the fields of a value type (see 'is_valuetype' argument of adapter_encoding). > I don't think that's correct. With your change: > > class MyValue1 { > int f1; > long f2; > } > > class MyValue3 { > int f1; > } > > class MyValue4 { > long f2; > } > > class MyValue2 { > MyValue3 f1; > MyValue4 f2; > } > > MyValue1 and MyValue2 would share the same adapters but that would only > be correct if they have the same layout (because now adapters embed hard > coded offsets for fields). Is it true? Is it guaranteed that it doesn't > change in the future? Right, that's not intended and probably not guaranteed in the future. I tried to remove the 'continue' statements but that triggers the "failed: code must match" assert again. Investigating. Thanks, Tobias From frederic.parain at oracle.com Mon Mar 27 14:35:23 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 27 Mar 2017 10:35:23 -0400 Subject: call to __Value methods can't pass fields as arguments In-Reply-To: References: <8C9E2B06-1C19-4B8F-AB65-00861880B356@oracle.com> <87A46302-60C8-4CE3-9DD7-B0DF883556CB@oracle.com> Message-ID: Thank you Roland! Fred On 03/27/2017 09:50 AM, Roland Westrelin wrote: > >> Let?s go with T_OBJECT right now (with a comment please). >> >> Could the calling convention be revisited later? >> 1 - to have T_VALUETYPE being a real reference to a standalone >> value (and then could be used in the case we are discussing) >> 2 - to add a special delimiter type instead of overloading T_VALUETYPE > > Yes. I'll think about it. > > Roland. > From tobias.hartmann at oracle.com Mon Mar 27 14:48:02 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Mar 2017 16:48:02 +0200 Subject: Adapter sharing is broken with -XX:+ValueTypePassFieldsAsArgs In-Reply-To: <3fb2b17e-a2bd-da71-267c-5b5e45c6283c@oracle.com> References: <2bb21a8a-65df-7e7e-cd6b-a0aee051d646@oracle.com> <3fb2b17e-a2bd-da71-267c-5b5e45c6283c@oracle.com> Message-ID: <0d23f296-e283-9ed1-d6f8-6b13c1c5ac0c@oracle.com> Hi Roland, the problem was handling the empty value type receiver when processing java.lang.__Value.hashCode()I. We need to differentiate between a "T_VALUETYPE, T_VOID" signature and a "T_OBJECT, T_OBJECT" signature (T_OBJECT, T_VOID and T_VALUETYPE were widened to T_LONG). Here's the new webrev: http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.13/ Thanks, Tobias On 27.03.2017 16:10, Tobias Hartmann wrote: > Hi Roland, > > thanks for looking at this! > > On 27.03.2017 15:43, Roland Westrelin wrote: >> Why the change lines 2254-2281? >> You skip over the T_VALUETYPE/T_VOID markers, right? > > Yes, I check for the T_VALUETYPE/T_VOID scope to avoid widening when we are passing the fields of a value type (see 'is_valuetype' argument of adapter_encoding). > >> I don't think that's correct. With your change: >> >> class MyValue1 { >> int f1; >> long f2; >> } >> >> class MyValue3 { >> int f1; >> } >> >> class MyValue4 { >> long f2; >> } >> >> class MyValue2 { >> MyValue3 f1; >> MyValue4 f2; >> } >> >> MyValue1 and MyValue2 would share the same adapters but that would only >> be correct if they have the same layout (because now adapters embed hard >> coded offsets for fields). Is it true? Is it guaranteed that it doesn't >> change in the future? > > Right, that's not intended and probably not guaranteed in the future. > > I tried to remove the 'continue' statements but that triggers the "failed: code must match" assert again. Investigating. > > Thanks, > Tobias > From tobias.hartmann at oracle.com Tue Mar 28 08:25:41 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Tue, 28 Mar 2017 08:25:41 +0000 Subject: hg: valhalla/valhalla/hotspot: Removed excess comma causing build failures Message-ID: <201703280825.v2S8PfTI024723@aojmv0008.oracle.com> Changeset: 98f3f77faf5a Author: thartmann Date: 2017-03-28 10:24 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/98f3f77faf5a Removed excess comma causing build failures ! src/share/vm/oops/klass.hpp From rwestrel at redhat.com Tue Mar 28 08:44:50 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Tue, 28 Mar 2017 08:44:50 +0000 Subject: hg: valhalla/valhalla/hotspot: call to __Value methods can't pass fields as arguments Message-ID: <201703280844.v2S8ioWq029161@aojmv0008.oracle.com> Changeset: 453b599a04b4 Author: roland Date: 2017-03-28 10:37 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/453b599a04b4 call to __Value methods can't pass fields as arguments ! src/share/vm/ci/ciValueKlass.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From rwestrel at redhat.com Tue Mar 28 09:20:19 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 28 Mar 2017 11:20:19 +0200 Subject: Adapter sharing is broken with -XX:+ValueTypePassFieldsAsArgs In-Reply-To: <0d23f296-e283-9ed1-d6f8-6b13c1c5ac0c@oracle.com> References: <2bb21a8a-65df-7e7e-cd6b-a0aee051d646@oracle.com> <3fb2b17e-a2bd-da71-267c-5b5e45c6283c@oracle.com> <0d23f296-e283-9ed1-d6f8-6b13c1c5ac0c@oracle.com> Message-ID: Hi Tobias, > the problem was handling the empty value type receiver when processing > java.lang.__Value.hashCode()I. We need to differentiate between a > "T_VALUETYPE, T_VOID" signature and a "T_OBJECT, T_OBJECT" signature > (T_OBJECT, T_VOID and T_VALUETYPE were widened to T_LONG). Why isn't this: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/453b599a04b4 sufficient? Roland. From tobias.hartmann at oracle.com Tue Mar 28 10:32:27 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Mar 2017 12:32:27 +0200 Subject: Adapter sharing is broken with -XX:+ValueTypePassFieldsAsArgs In-Reply-To: References: <2bb21a8a-65df-7e7e-cd6b-a0aee051d646@oracle.com> <3fb2b17e-a2bd-da71-267c-5b5e45c6283c@oracle.com> <0d23f296-e283-9ed1-d6f8-6b13c1c5ac0c@oracle.com> Message-ID: Hi Roland On 28.03.2017 11:20, Roland Westrelin wrote: > Why isn't this: > > http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/453b599a04b4 > > sufficient? Because we would still treat these signatures as equal (MyValue has an int field): m1(MyValue v) -> (T_VALUETYPE, T_INT, T_VOID) m2(Object o1, int i, Object o2) -> (T_OBJECT, T_INT, T_OBJECT) Which is not correct because we cannot use the adapter for m2 to pass a value type to m1. Right? Best regards, Tobias From rwestrel at redhat.com Tue Mar 28 11:07:58 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 28 Mar 2017 13:07:58 +0200 Subject: Adapter sharing is broken with -XX:+ValueTypePassFieldsAsArgs In-Reply-To: References: <2bb21a8a-65df-7e7e-cd6b-a0aee051d646@oracle.com> <3fb2b17e-a2bd-da71-267c-5b5e45c6283c@oracle.com> <0d23f296-e283-9ed1-d6f8-6b13c1c5ac0c@oracle.com> Message-ID: > Because we would still treat these signatures as equal (MyValue has an int field): > > m1(MyValue v) -> (T_VALUETYPE, T_INT, T_VOID) > m2(Object o1, int i, Object o2) -> (T_OBJECT, T_INT, T_OBJECT) > > Which is not correct because we cannot use the adapter for m2 to pass a value type to m1. I see. But T_VOID doesn't become T_OBJECT, right? Anyway, your change looks good. Roland. From tobias.hartmann at oracle.com Tue Mar 28 11:18:00 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Mar 2017 13:18:00 +0200 Subject: Adapter sharing is broken with -XX:+ValueTypePassFieldsAsArgs In-Reply-To: References: <2bb21a8a-65df-7e7e-cd6b-a0aee051d646@oracle.com> <3fb2b17e-a2bd-da71-267c-5b5e45c6283c@oracle.com> <0d23f296-e283-9ed1-d6f8-6b13c1c5ac0c@oracle.com> Message-ID: <56f0b645-95e0-d005-649d-06df38d7d18e@oracle.com> On 28.03.2017 13:07, Roland Westrelin wrote: >> Because we would still treat these signatures as equal (MyValue has an int field): >> >> m1(MyValue v) -> (T_VALUETYPE, T_INT, T_VOID) >> m2(Object o1, int i, Object o2) -> (T_OBJECT, T_INT, T_OBJECT) >> >> Which is not correct because we cannot use the adapter for m2 to pass a value type to m1. > > I see. But T_VOID doesn't become T_OBJECT, right? Yes, you are right. T_VOID stays T_VOID. But if MyValue has an Object field, it's still a problem: m1(MyValue v) -> (T_VALUETYPE, T_OBJECT, T_VOID) -> (T_LONG, T_LONG, T_VOID) m2(Object o1, long i) -> (T_OBJECT, T_LONG, T_VOID) > (T_LONG, T_LONG, T_VOID) > Anyway, your change looks good. Thanks for reviewing this. Best regards, Tobias From zoltan.majo at oracle.com Tue Mar 28 11:20:42 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 28 Mar 2017 13:20:42 +0200 Subject: RFR (M): Generate checks for vbox/vunbox; extend CI to include VCC-DVT mapping Message-ID: Hi, please review the following change: http://cr.openjdk.java.net/~zmajo/valhalla/03.vbox-vunbox-checks/webrev.00/ The patch adds checks to vbox/vunbox that are missing in the current implementation. The patch enables C2 to generate code that includes null checks and type checks (where required). Other checks (e.g., checking if the source/target class of the bytecode instruction is loaded and if it is a value-capable-class/derived value type) are performed at compile-time. The patch also extends the CI to mirror the VCC-DVT mapping to the compiler. Tested with all valhalla tests, JPRT (linux_x64 only), Octane. Thank you! Best regards, Zoltan From rwestrel at redhat.com Tue Mar 28 12:25:54 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 28 Mar 2017 14:25:54 +0200 Subject: Return value type fields in registers Message-ID: http://cr.openjdk.java.net/~roland/valhalla/returnconvention/webrev.00/ Instead of returning a reference to a value type (which forces the compiler to allocate a value type instance and initialize it), with this change, the compiler returns the value type in registers: one field per register. Similarly to the calling convention, SharedRuntime::java_return_convention() defines what registers are used to return value types. That call can fail if there are not enough registers for a particular value type (too many fields in the value type), in which case, the compiler is forced to allocate a value type instance. Because the compiled code now returns multiple values, the interpreter needs to be able to handle multiple return values. Because the interpreter works with value type references, on method return, it has to allocate a new value type and initialize it with the field's values from the registers of the calling convention. Because the interpreter now expects multiple return values from a call, returning from an interpreted method also needs to follow the calling convention and return a value type instance in registers. Both loading the fields into registers from a value type instance on return and allocating a new value type instance initialized from the field values in registers is performed through runtime calls that read/write register values using a RegisterMap. On the compiler side, supporting multiple return values consists mostly in adding as many edges as there are fields to the ReturnNode and adding as many projections as there are fields following a call. The change also includes This is not turned on by default for 2 reasons: 1) The interpreter reallocates value types in the heap. It would make more sense for the interpreter to do it using the new buffer scheme that's being developed. 2) If lambda form are involved, exact types for return values are lost and this return scheme breaks. It needs lambda form to be specialized to each value type types. This is mostly unrelated but I noticed that calling a method that returns a value type through reflection is currently broken (assert failure somewhere in the reflection code). I suppose that when reflection is fixed, it will box the returned value type so it's not affected by that change to the calling convention. I suppose a similar problem exists with passing value type arguments through reflection though I haven't tried it. Roland. From tobias.hartmann at oracle.com Tue Mar 28 12:52:57 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Tue, 28 Mar 2017 12:52:57 +0000 Subject: hg: valhalla/valhalla/hotspot: Adapter sharing is broken with -XX:+ValueTypePassFieldsAsArgs Message-ID: <201703281252.v2SCqvil023084@aojmv0008.oracle.com> Changeset: 7275b173a83f Author: thartmann Date: 2017-03-28 14:41 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/7275b173a83f Adapter sharing is broken with -XX:+ValueTypePassFieldsAsArgs Reviewed-by: roland ! src/share/vm/runtime/sharedRuntime.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From zoltan.majo at oracle.com Tue Mar 28 14:24:00 2017 From: zoltan.majo at oracle.com (zoltan.majo at oracle.com) Date: Tue, 28 Mar 2017 14:24:00 +0000 Subject: hg: valhalla/valhalla/hotspot: Printing attributes for vwithfield and vdefault bytecodes breaks the Ideal Graph Visualizer Message-ID: <201703281424.v2SEO1lD018664@aojmv0008.oracle.com> Changeset: 6a646203cf6c Author: zmajo Date: 2017-03-28 16:23 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6a646203cf6c Printing attributes for vwithfield and vdefault bytecodes breaks the Ideal Graph Visualizer ! src/share/vm/interpreter/bytecodeTracer.cpp From tobias.hartmann at oracle.com Thu Mar 30 08:26:56 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 30 Mar 2017 10:26:56 +0200 Subject: RFR (M): Generate checks for vbox/vunbox; extend CI to include VCC-DVT mapping In-Reply-To: References: Message-ID: <79c73089-912f-fd6d-66b1-e1b0671c7bfa@oracle.com> Hi Zoltan, On 28.03.2017 13:20, Zolt?n Maj? wrote: > http://cr.openjdk.java.net/~zmajo/valhalla/03.vbox-vunbox-checks/webrev.00/ > > The patch adds checks to vbox/vunbox that are missing in the current implementation. The patch enables C2 to generate code that includes null checks and type checks (where required). Other checks (e.g., checking if the source/target class of the bytecode instruction is loaded and if it is a value-capable-class/derived value type) are performed at compile-time. The patch also extends the CI to mirror the VCC-DVT mapping to the compiler. Here are some comments/questions: - I think it's sufficient to have the "// TODO: Check if updating flag works properly" in one place - In graphKit.cpp, why do you set 'treat_throw_as_hot' to always true? Shouldn't the checks in line 549 be sufficient to set it (also for the vbox/vunbox bytecodes)? - Since we don't support subtyping for value types, shouldn't we check for type equality instead of a subtype relation? - In vbox(), you can get the exact type of the ValueTypeNode via ValueTypeNode::value_klass() and you can check that for equality with the target_dvt_klass - In vunbox(), I would check for equality of the source_type and the target_vcc_klass Thanks, Tobias From tobias.hartmann at oracle.com Thu Mar 30 12:40:13 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 30 Mar 2017 14:40:13 +0200 Subject: Return value type fields in registers In-Reply-To: References: Message-ID: Hi Roland, On 28.03.2017 14:25, Roland Westrelin wrote: > Because the compiled code now returns multiple values, the interpreter > needs to be able to handle multiple return values. Because the > interpreter works with value type references, on method return, it has > to allocate a new value type and initialize it with the field's values > from the registers of the calling convention. Because the interpreter > now expects multiple return values from a call, returning from an > interpreted method also needs to follow the calling convention and > return a value type instance in registers. Both loading the fields into > registers from a value type instance on return and allocating a new > value type instance initialized from the field values in registers is > performed through runtime calls that read/write register values using a > RegisterMap. Very nice! Here are some minor comments/questions: templateInterpreterGenerator_x86.cpp - What is 'skip' used for? deoptimization.cpp - you can merge the check in line 232 with the check in line 252 - 'return_values' is a bit misleading because it contains Handles for oop fields or the oop return and not all returned values. Maybe rename to 'return_oops' or 'return_handles'. sharedRuntime.cpp - line 3176, missing whitespace I'm currently working on reference field support and it requires some significant changes. How did you check the save_oop_results() code without oop field support? > This is not turned on by default for 2 reasons: 1) The interpreter > reallocates value types in the heap. It would make more sense for the > interpreter to do it using the new buffer scheme that's being > developed. 2) If lambda form are involved, exact types for return values > are lost and this return scheme breaks. It needs lambda form to be > specialized to each value type types. I wonder if it would make sense to also pass/return the oop of a value type? In C2I we would then only need to allocate if the oop is NULL and in IC2 we can pass on the oop of the interpreter-allocated value type. We could do the same when returning from the interpreter or compiled code. > This is mostly unrelated but I noticed that calling a method that > returns a value type through reflection is currently broken (assert > failure somewhere in the reflection code). I suppose that when > reflection is fixed, it will box the returned value type so it's not > affected by that change to the calling convention. I suppose a similar > problem exists with passing value type arguments through reflection > though I haven't tried it. Right, I also recently hit some problems with reflection. Thanks, Tobias