From zoltan.majo at oracle.com Fri Nov 4 15:06:08 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 4 Nov 2016 16:06:08 +0100 Subject: C2 support for method invocations on value types Message-ID: Hi, here is a changeset to add (preliminary) C2 support for method invocations on value types. http://cr.openjdk.java.net/~zmajo/valhalla/00.invokedirect.webrev.00/ The changeset also adds some verification code to the invokedirect implementation in the interpreter. With the modification, the interpreter fails if it encounters the invocation of a non-final method on a value type. If you disagree with that change, I can remove it from the planned changeset. I also made some comments more verbose. Maybe future first-readers will benefit from that as well. I plan to push the change on Monday the earliest, unless, of course, there are any objections. Thank you! Best regards, Zoltan From rwestrel at redhat.com Fri Nov 4 15:13:23 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 4 Nov 2016 16:13:23 +0100 Subject: C2 support for method invocations on value types In-Reply-To: References: Message-ID: <70158c50-7203-ddb3-1668-5627d0dc20de@redhat.com> Hi Zoltan, > http://cr.openjdk.java.net/~zmajo/valhalla/00.invokedirect.webrev.00/ Why is the change in Parse::create_entry_map() needed? Roland. From zoltan.majo at oracle.com Fri Nov 4 15:38:39 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 4 Nov 2016 16:38:39 +0100 Subject: C2 support for method invocations on value types In-Reply-To: <70158c50-7203-ddb3-1668-5627d0dc20de@redhat.com> References: <70158c50-7203-ddb3-1668-5627d0dc20de@redhat.com> Message-ID: <460a04be-2b8b-deea-f5e8-e66c87ffe5d5@oracle.com> Hi Roland, thank you for looking at the suggested change. On 11/04/2016 04:13 PM, Roland Westrelin wrote: > Hi Zoltan, > >> http://cr.openjdk.java.net/~zmajo/valhalla/00.invokedirect.webrev.00/ > Why is the change in Parse::create_entry_map() needed? That change needed to avoid checking if the receiver is null with null_check_receiver_before_call()(we don't need to "fake" the null check if the callee method is inlined, I think; as value type fields are anyway used "directly"). But what I suggest is a bit too much: Theallocation of the oop for the valutype (as below) is not required, because only its fields are used anyway: 1117 if (kit.argument(0)->is_ValueType()) { 1118 ValueTypeNode* vt = kit.argument(0)->as_ValueType(); 1119 vt->store_to_memory(&kit); 1120 } else { 1121 kit.null_check_receiver_before_call(method()); 1122 } So it's probably best to just skip it. Here is what I suggest to do in the updated webrev [1]: 1117 if (!kit.argument(0)->is_ValueType()) { 1118 kit.null_check_receiver_before_call(method()); 1119 } 1120 _caller = kit.transfer_exceptions_into_jvms(); Does that make more sense to you? Thank you and best regards, Zoltan [1] http://cr.openjdk.java.net/~zmajo/valhalla/00.invokedirect.webrev.01/ > > Roland. From rwestrel at redhat.com Fri Nov 4 15:39:38 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 4 Nov 2016 16:39:38 +0100 Subject: C2 support for method invocations on value types In-Reply-To: <460a04be-2b8b-deea-f5e8-e66c87ffe5d5@oracle.com> References: <70158c50-7203-ddb3-1668-5627d0dc20de@redhat.com> <460a04be-2b8b-deea-f5e8-e66c87ffe5d5@oracle.com> Message-ID: > 1117 if (!kit.argument(0)->is_ValueType()) { > 1118 kit.null_check_receiver_before_call(method()); > 1119 } > 1120 _caller = kit.transfer_exceptions_into_jvms(); > > Does that make more sense to you? It does. Thanks. Roland. From zoltan.majo at oracle.com Mon Nov 7 08:55:19 2016 From: zoltan.majo at oracle.com (zoltan.majo at oracle.com) Date: Mon, 07 Nov 2016 08:55:19 +0000 Subject: hg: valhalla/valhalla/hotspot: Summary: C2 support for invokedirect (incl. tests) Message-ID: <201611070855.uA78tJ8H016042@aojmv0008.oracle.com> Changeset: ad353fd10e42 Author: zmajo Date: 2016-11-07 09:53 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ad353fd10e42 Summary: C2 support for invokedirect (incl. tests) ! src/cpu/x86/vm/templateTable_x86.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/valuetypenode.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From frederic.parain at oracle.com Mon Nov 7 15:32:04 2016 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Mon, 07 Nov 2016 15:32:04 +0000 Subject: hg: valhalla/valhalla/hotspot: Fix offset bug in qputfield Message-ID: <201611071532.uA7FW4s5002268@aojmv0008.oracle.com> Changeset: 9d5bcd96ea40 Author: fparain Date: 2016-11-07 10:31 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9d5bcd96ea40 Fix offset bug in qputfield ! src/share/vm/interpreter/interpreterRuntime.cpp From rwestrel at redhat.com Mon Nov 7 16:54:03 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 07 Nov 2016 17:54:03 +0100 Subject: C2: add SafePointScalarObjectNodes from ValueTypeNodes to SafePointNodes without an allocation + propagate materialized value type in the graph Message-ID: http://cr.openjdk.java.net/~roland/valhalla/scalar_at_safepoints/webrev.00/ In general we shouldn't need a temporary allocation to eliminate value type nodes at SafePoint nodes. Also, the temporary allocation currently happens at uncommon traps but there are other safepoints that are not currently handled. For instance, the first call to sumValue() in test14() has a reference to v that is not currently handled. This change creates SafePointScalarObjectNodes from ValueTypeNodes without a temporary allocation. This doesn't take care of a safepoint that references a value type that references another value type. I'll fix that once flattened value type support is integrated. I'll also remove the graphKit.cpp code that adds temporary allocations at uncommon traps later. I also noticed that test14() currently causes 2 allocations to be emitted. Same with test15(). The change to ValueTypeNode::store_to_memory() fixes that by creating a new ValueTypeNode that has a reference to the allocation and replacing the old one with the new one in the JVM state. Finally, I noticed WhiteBox.deoptimize() doesn't work properly. That will need to be fixed in jdk9 as well apparently (I can take care of it). Roland. From rwestrel at redhat.com Mon Nov 7 17:15:06 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 07 Nov 2016 18:15:06 +0100 Subject: C2: add SafePointScalarObjectNodes from ValueTypeNodes to SafePointNodes without an allocation + propagate materialized value type in the graph In-Reply-To: References: Message-ID: > Finally, I noticed WhiteBox.deoptimize() doesn't work properly. That > will need to be fixed in jdk9 as well apparently (I can take care of > it). Actually it was removed from jdk9 so I'll use: diff --git a/test/compiler/valhalla/valuetypes/ValueTypeTestBench.java b/test/compiler/valhalla/valuetypes/ValueTypeTestBench.java --- a/test/compiler/valhalla/valuetypes/ValueTypeTestBench.java +++ b/test/compiler/valhalla/valuetypes/ValueTypeTestBench.java @@ -356,7 +356,7 @@ MyValue v = MyValue.createInline(rI, rL, rD); if (flag) { // uncommon trap - WHITE_BOX.deoptimize(); + WHITE_BOX.deoptimizeMethod(tests.get("ValueTypeTestBench::test16")); } return sumValue(v); } Roland. From maurizio.cimadamore at oracle.com Mon Nov 7 18:40:50 2016 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 07 Nov 2016 18:40:50 +0000 Subject: hg: valhalla/valhalla/langtools: Fix: do not generate 'typed' opcodes if -XDenableMinimalValueTypes is set Message-ID: <201611071840.uA7IeoxY021231@aojmv0008.oracle.com> Changeset: ef0142d1ab9a Author: mcimadamore Date: 2016-11-07 18:38 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ef0142d1ab9a Fix: do not generate 'typed' opcodes if -XDenableMinimalValueTypes is set Fix translation of value capable class by omitting any extraneous opcode (such as 'typed') as well as by setting minor/major version accordingly. ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java ! test/tools/javac/valhalla/minimalvalues/TypedBytecodeTest.java From tobias.hartmann at oracle.com Tue Nov 8 08:00:20 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 8 Nov 2016 09:00:20 +0100 Subject: C2: add SafePointScalarObjectNodes from ValueTypeNodes to SafePointNodes without an allocation + propagate materialized value type in the graph In-Reply-To: References: Message-ID: <58218614.40809@oracle.com> Hi Roland, On 07.11.2016 17:54, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/valhalla/scalar_at_safepoints/webrev.00/ > > In general we shouldn't need a temporary allocation to eliminate value > type nodes at SafePoint nodes. Yes, I completely agree that we shouldn't emit a temporary allocation that is then removed anyway. Just used this as a straight forward implementation. > Also, the temporary allocation currently > happens at uncommon traps but there are other safepoints that are not > currently handled. For instance, the first call to sumValue() in > test14() has a reference to v that is not currently handled. This change > creates SafePointScalarObjectNodes from ValueTypeNodes without a > temporary allocation. This doesn't take care of a safepoint that > references a value type that references another value type. I'll fix > that once flattened value type support is integrated. I'll also remove > the graphKit.cpp code that adds temporary allocations at uncommon traps > later. Right, I hit this problem with the tests for my flattened VT prototype as well. Good that you were able to fix this! > I also noticed that test14() currently causes 2 allocations to be > emitted. Same with test15(). The change to > ValueTypeNode::store_to_memory() fixes that by creating a new > ValueTypeNode that has a reference to the allocation and replacing the > old one with the new one in the JVM state. Your fix looks good to me, please go ahead and push. I'll then merge my flattened VT changes in. Thanks, Tobias > Finally, I noticed WhiteBox.deoptimize() doesn't work properly. That > will need to be fixed in jdk9 as well apparently (I can take care of > it). > > Roland. > From rwestrel at redhat.com Wed Nov 9 08:43:21 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 09 Nov 2016 09:43:21 +0100 Subject: C2: add SafePointScalarObjectNodes from ValueTypeNodes to SafePointNodes without an allocation + propagate materialized value type in the graph In-Reply-To: <58218614.40809@oracle.com> References: <58218614.40809@oracle.com> Message-ID: > Your fix looks good to me, please go ahead and push. I'll then merge > my flattened VT changes in. Thanks for looking at this, Tobias. I will push it. Roland. From rwestrel at redhat.com Wed Nov 9 09:12:29 2016 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Wed, 09 Nov 2016 09:12:29 +0000 Subject: hg: valhalla/valhalla/hotspot: C2: add SafePointScalarObjectNodes from ValueTypeNodes to SafePointNodes without an allocation + propagate materialized value type in the graph Message-ID: <201611090912.uA99CTFE000837@aojmv0008.oracle.com> Changeset: 825cd25116ec Author: roland Date: 2016-11-09 09:48 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/825cd25116ec C2: add SafePointScalarObjectNodes from ValueTypeNodes to SafePointNodes without an allocation + propagate materialized value type in the graph ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/valuetypenode.cpp ! src/share/vm/opto/valuetypenode.hpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From rwestrel at redhat.com Wed Nov 9 09:13:44 2016 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Wed, 09 Nov 2016 09:13:44 +0000 Subject: hg: valhalla/valhalla/hotspot: ValueTypeTestBench test fix Message-ID: <201611090913.uA99DiKQ001083@aojmv0008.oracle.com> Changeset: 95c915eac3e0 Author: roland Date: 2016-11-09 10:13 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/95c915eac3e0 ValueTypeTestBench test fix ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From tobias.hartmann at oracle.com Fri Nov 11 11:00:40 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 11 Nov 2016 12:00:40 +0100 Subject: Flattened value type field support for C2 Message-ID: <5825A4D8.8090405@oracle.com> Hi, here's my implementation of (flattened) value type field support for C2: http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.03/ The patch contains the following changes: - Support for flattened value type fields in regular objects and value types - field list in ciInstanceKlass now contains flattened value type fields (recursively) - fixed instanceOopDesc::contains_field_offset() to account for different alignment of value type fields - fixed alias analysis to support value type fields - fixed deoptimization to correctly reassign flattened value type fields - Improved ValueKlass::first_field_offset() to not iterate over all fields but compute the offset - Improved ValueTypeNode::make_scalar_in_safepoints() and added support for value type fields - Added new tests, increased coverage of existing tests and fixed test bench to support product builds - Lots of refactoring, added more comments and more asserts I also tried to make it more clear/explicit in the code that ciValueKlass translates between the following field indexes: 1) Value type factory parameter index: The index of the value type factory parameter that corresponds to a field index 2) in the valueKlass. The value of that field can be obtained by the value input edge of the ValueTypeNode in C2 IR with the same index. 2) Field index in the valueKlass. I'll write up a more detailed documentation in the next days. Please have a look at the code and let me know if you spot any problems. Thanks, Tobias From rwestrel at redhat.com Mon Nov 14 13:54:10 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 14 Nov 2016 14:54:10 +0100 Subject: Flattened value type field support for C2 In-Reply-To: <5825A4D8.8090405@oracle.com> References: <5825A4D8.8090405@oracle.com> Message-ID: Hi Tobias, > - fixed deoptimization to correctly reassign flattened value type fields So reassigning a field can now fail and we then return to interpreted code with a pending exception and the field not properly initialized? I took a quick look to the change and it looks good to me. Roland. From rwestrel at redhat.com Mon Nov 14 14:10:53 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 14 Nov 2016 15:10:53 +0100 Subject: Flattened value type field support for C2 In-Reply-To: <5825A4D8.8090405@oracle.com> References: <5825A4D8.8090405@oracle.com> Message-ID: Another question: is a value type field always flattened? Are recursive declarations forbidden? Roland. From tobias.hartmann at oracle.com Mon Nov 14 14:19:06 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 14 Nov 2016 15:19:06 +0100 Subject: Flattened value type field support for C2 In-Reply-To: References: <5825A4D8.8090405@oracle.com> Message-ID: <5829C7DA.8060404@oracle.com> Hi Roland, On 14.11.2016 14:54, Roland Westrelin wrote: > > Hi Tobias, > >> - fixed deoptimization to correctly reassign flattened value type fields > > So reassigning a field can now fail and we then return to interpreted > code with a pending exception and the field not properly initialized? Yes, this may happen due to the SymbolTable lookup that is necessary to get the Klass of the flattened value type field. One of the items on my todo list is to get rid of those lookups. We also need them in ciInstanceKlass::get_field_type_by_offset() and some places in the interpreter: // It would be better to have another way to retrieve the field klass // than doing a lookup in the SystemDictionary In this case, the question is if it wouldn't be okay to throw an exception if the lookup fails? > I took a quick look to the change and it looks good to me. Thanks for taking a look! Best regards, Tobias > > Roland. > From tobias.hartmann at oracle.com Mon Nov 14 14:21:32 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 14 Nov 2016 15:21:32 +0100 Subject: Flattened value type field support for C2 In-Reply-To: References: <5825A4D8.8090405@oracle.com> Message-ID: <5829C86C.508@oracle.com> Hi Roland, On 14.11.2016 15:10, Roland Westrelin wrote: > > Another question: is a value type field always flattened? Are recursive > declarations forbidden? Both yes. The current prototype always flattens value type fields and recursive declarations are forbidden by javac: /oracle/valhalla/hotspot/test/compiler/valhalla/valuetypes/ValueTypeTestBench.java:61: error: cyclic value type membership involving MyValue1 final MyValue1 v3; Best regards, Tobias > > Roland. > From zoltan.majo at oracle.com Tue Nov 15 16:36:38 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 15 Nov 2016 17:36:38 +0100 Subject: Flattened value type field support for C2 In-Reply-To: <5825A4D8.8090405@oracle.com> References: <5825A4D8.8090405@oracle.com> Message-ID: <97b8e1ff-0c96-a146-5d1f-95ad8ab03f0b@oracle.com> Hi Tobias, On 11/11/2016 12:00 PM, Tobias Hartmann wrote: > Hi, > > here's my implementation of (flattened) value type field support for C2: > http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.03/ > > The patch contains the following changes: > - Support for flattened value type fields in regular objects and value types > - field list in ciInstanceKlass now contains flattened value type fields (recursively) > - fixed instanceOopDesc::contains_field_offset() to account for different alignment of value type fields > - fixed alias analysis to support value type fields > - fixed deoptimization to correctly reassign flattened value type fields > - Improved ValueKlass::first_field_offset() to not iterate over all fields but compute the offset > - Improved ValueTypeNode::make_scalar_in_safepoints() and added support for value type fields > - Added new tests, increased coverage of existing tests and fixed test bench to support product builds > - Lots of refactoring, added more comments and more asserts > > I also tried to make it more clear/explicit in the code that ciValueKlass translates between the following field indexes: > 1) Value type factory parameter index: The index of the value type factory parameter that corresponds to a field index 2) in the valueKlass. The value of that field can be obtained by the value input edge of the ValueTypeNode in C2 IR with the same index. > 2) Field index in the valueKlass. your change looks good to me -- thank you for the clarifications off-line! I've spotted a small issue with ValueTypeTestBench.java at line 547: 547 "-XX:CompileCommand=inline,java.lang.Object::", You might have left that in by accident. Thank you! Best regards, Zoltan > I'll write up a more detailed documentation in the next days. > > Please have a look at the code and let me know if you spot any problems. > > Thanks, > Tobias From tobias.hartmann at oracle.com Wed Nov 16 07:57:56 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 16 Nov 2016 08:57:56 +0100 Subject: Flattened value type field support for C2 In-Reply-To: <97b8e1ff-0c96-a146-5d1f-95ad8ab03f0b@oracle.com> References: <5825A4D8.8090405@oracle.com> <97b8e1ff-0c96-a146-5d1f-95ad8ab03f0b@oracle.com> Message-ID: <582C1184.8040201@oracle.com> Hi Zoltan, On 15.11.2016 17:36, Zolt?n Maj? wrote: > Hi Tobias, > > > On 11/11/2016 12:00 PM, Tobias Hartmann wrote: >> Hi, >> >> here's my implementation of (flattened) value type field support for C2: >> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.03/ >> >> The patch contains the following changes: >> - Support for flattened value type fields in regular objects and value types >> - field list in ciInstanceKlass now contains flattened value type fields (recursively) >> - fixed instanceOopDesc::contains_field_offset() to account for different alignment of value type fields >> - fixed alias analysis to support value type fields >> - fixed deoptimization to correctly reassign flattened value type fields >> - Improved ValueKlass::first_field_offset() to not iterate over all fields but compute the offset >> - Improved ValueTypeNode::make_scalar_in_safepoints() and added support for value type fields >> - Added new tests, increased coverage of existing tests and fixed test bench to support product builds >> - Lots of refactoring, added more comments and more asserts >> >> I also tried to make it more clear/explicit in the code that ciValueKlass translates between the following field indexes: >> 1) Value type factory parameter index: The index of the value type factory parameter that corresponds to a field index 2) in the valueKlass. The value of that field can be obtained by the value input edge of the ValueTypeNode in C2 IR with the same index. >> 2) Field index in the valueKlass. > > your change looks good to me -- thank you for the clarifications off-line! Thanks for having a look! > I've spotted a small issue with ValueTypeTestBench.java at line 547: > > 547 "-XX:CompileCommand=inline,java.lang.Object::", > > You might have left that in by accident. Yes, that's a leftover from some testing I did. I will remove the line before pushing. Thanks, Tobias > Thank you! > > Best regards, > > > Zoltan > > >> I'll write up a more detailed documentation in the next days. >> >> Please have a look at the code and let me know if you spot any problems. >> >> Thanks, >> Tobias > From tobias.hartmann at oracle.com Wed Nov 16 08:23:22 2016 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 16 Nov 2016 08:23:22 +0000 Subject: hg: valhalla/valhalla/hotspot: Summary: Support for flattened value type fields in regular objects and value types Message-ID: <201611160823.uAG8NMmE005292@aojmv0008.oracle.com> Changeset: f2b95228b845 Author: thartmann Date: 2016-11-16 09:23 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/f2b95228b845 Summary: Support for flattened value type fields in regular objects and value types Reviewed-by: roland, zmajo ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciValueKlass.cpp ! src/share/vm/ci/ciValueKlass.hpp ! src/share/vm/jvmci/jvmciCompilerToVM.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/valueKlass.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/valuetypenode.cpp ! src/share/vm/opto/valuetypenode.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From rwestrel at redhat.com Wed Nov 16 08:53:20 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 16 Nov 2016 09:53:20 +0100 Subject: Flattened value type field support for C2 In-Reply-To: <5829C7DA.8060404@oracle.com> References: <5825A4D8.8090405@oracle.com> <5829C7DA.8060404@oracle.com> Message-ID: > In this case, the question is if it wouldn't be okay to throw an exception if the lookup fails? Resuming code execution with a half initialize object doesn't seem like a good idea. Maybe it would good enough for now to have a guarantee() that test for no pending exception? Roland. From tobias.hartmann at oracle.com Wed Nov 16 09:09:11 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 16 Nov 2016 10:09:11 +0100 Subject: Flattened value type field support for C2 In-Reply-To: References: <5825A4D8.8090405@oracle.com> <5829C7DA.8060404@oracle.com> Message-ID: <582C2237.4050700@oracle.com> Hi Roland, On 16.11.2016 09:53, Roland Westrelin wrote: > >> In this case, the question is if it wouldn't be okay to throw an exception if the lookup fails? > > Resuming code execution with a half initialize object doesn't seem like > a good idea. Maybe it would good enough for now to have a guarantee() > that test for no pending exception? Yes, that seems reasonable. I'll add a guarantee with my next push. Best regards, Tobias > > Roland. > From martijnverburg at gmail.com Thu Nov 17 13:25:19 2016 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 17 Nov 2016 14:25:19 +0100 Subject: Updates to wiki Message-ID: Hi all, I've been given access to edit the Wiki (dangerous I know) and I've added a chunk of information there including Brian's text on the goals of the project (not just performance!) The wiki is here: https://wiki.openjdk.java.net/display/valhalla/Main Any and all feedback welcome! CCing in Adoption group as this is the sort of service we could provide for other groups / projects of that is helpful. Cheers, Martijn From forax at univ-mlv.fr Thu Nov 17 13:32:54 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 17 Nov 2016 14:32:54 +0100 (CET) Subject: Updates to wiki In-Reply-To: References: Message-ID: <927945933.2493205.1479389574711.JavaMail.zimbra@u-pem.fr> Hi Martijn, you can add a link to the last JVM Summit https://www.youtube.com/playlist?list=PLX8CzqL3ArzUY6rQAQTwI_jKvqJxrRrP_ cheers, R?mi ----- Mail original ----- > De: "Martijn Verburg" > ?: valhalla-dev at openjdk.java.net > Cc: adoption-discuss at openjdk.java.net > Envoy?: Jeudi 17 Novembre 2016 14:25:19 > Objet: Updates to wiki > Hi all, > > I've been given access to edit the Wiki (dangerous I know) and I've added a > chunk of information there including Brian's text on the goals of the > project (not just performance!) > > The wiki is here: https://wiki.openjdk.java.net/display/valhalla/Main > > Any and all feedback welcome! > > CCing in Adoption group as this is the sort of service we could provide for > other groups / projects of that is helpful. > > Cheers, > Martijn From martijnverburg at gmail.com Thu Nov 17 15:03:40 2016 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 17 Nov 2016 16:03:40 +0100 Subject: Updates to wiki In-Reply-To: <927945933.2493205.1479389574711.JavaMail.zimbra@u-pem.fr> References: <927945933.2493205.1479389574711.JavaMail.zimbra@u-pem.fr> Message-ID: On 17 November 2016 at 14:32, Remi Forax wrote: > https://www.youtube.com/playlist?list=PLX8CzqL3ArzUY6rQAQTwI_jKvqJxrRrP_ Added thank you! Cheers, Martijn From forax at univ-mlv.fr Thu Nov 17 15:49:26 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 17 Nov 2016 16:49:26 +0100 (CET) Subject: Updates to wiki In-Reply-To: References: <927945933.2493205.1479389574711.JavaMail.zimbra@u-pem.fr> Message-ID: <978804893.2639282.1479397766724.JavaMail.zimbra@u-pem.fr> No, thank you :) R?mi > De: "Martijn Verburg" > ?: "Remi Forax" > Cc: valhalla-dev at openjdk.java.net, adoption-discuss at openjdk.java.net > Envoy?: Jeudi 17 Novembre 2016 16:03:40 > Objet: Re: Updates to wiki > On 17 November 2016 at 14:32, Remi Forax < forax at univ-mlv.fr > wrote: >> https://www.youtube.com/playlist?list=PLX8CzqL3ArzUY6rQAQTwI_jKvqJxrRrP_ > Added thank you! > Cheers, > Martijn From rwestrel at redhat.com Thu Nov 24 10:25:20 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 24 Nov 2016 11:25:20 +0100 Subject: RFR/RFC calling convention change for value types in compiled code Message-ID: http://cr.openjdk.java.net/~roland/valhalla/callingconvention/webrev.00/ This patch implements a new compiled code calling convention for methods that take value type arguments: instead of passing a reference to the value type as an argument, the method is passed each field of the value type in registers/stack slots. The interpreter continues to use references at calls so when going to compiled from the interpreter (i2c adapter), value type fields are loaded from the value type object and the value type object is discarded. When going from compiled code to the interpreter (c2i adapter), value type objects for every arguments need to be allocated and initialized with the field values passed by the compiler. Roland. From stanislav.smirnov at oracle.com Thu Nov 24 11:56:49 2016 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Thu, 24 Nov 2016 14:56:49 +0300 Subject: Nestmates MH tests update to use javac flag Message-ID: Hi, please take a look on this changes to nestmates MH tests. Tests start using -XDdisableAccessors javac flag to stop generating access bridges and so verify the vm changes. Without vm support tests will fail on setUp phase because without access bridges there is no way to refer to ?super? fields/methods from inner classes. Also in MethodHandleSubTop class lookup and mt access modifiers have been changed to package private to give access from inner classes without bridges. Rest of the changes verify that there are no access bridges available and some tests are now positive, expecting accessibility, plus added comments to the test cases. webrev: http://cr.openjdk.java.net/~stsmirno/mhtests/webrev.00 And I will need a sponsor for this change. Best regards, Stanislav Smirnov From david.simms at oracle.com Thu Nov 24 13:42:28 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 24 Nov 2016 13:42:28 +0000 Subject: hg: valhalla/valhalla/hotspot: 2 new changesets Message-ID: <201611241342.uAODgSJY006019@aojmv0008.oracle.com> Changeset: 9d6cd81511b9 Author: dsimms Date: 2016-11-24 11:25 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9d6cd81511b9 Fix for Class.forName([Qtype;) ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvm.h ! test/runtime/valhalla/valuetypes/ValueTypeArray.java Changeset: 65b3a5587970 Author: dsimms Date: 2016-11-24 14:40 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/65b3a5587970 Half broken test library ! test/runtime/valhalla/valuetypes/ValueTypeArray.java From david.simms at oracle.com Thu Nov 24 13:42:43 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 24 Nov 2016 13:42:43 +0000 Subject: hg: valhalla/valhalla/jdk: Fix for Class.forName([Qtype;) Message-ID: <201611241342.uAODghK0006218@aojmv0008.oracle.com> Changeset: 1915d0702dbf Author: dsimms Date: 2016-11-24 11:25 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/1915d0702dbf Fix for Class.forName([Qtype;) ! src/java.base/share/native/include/classfile_constants.h ! src/java.base/share/native/libverify/check_code.c ! src/java.base/share/native/libverify/check_format.c From zoltan.majo at oracle.com Thu Nov 24 14:16:30 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 24 Nov 2016 15:16:30 +0100 Subject: RFR/RFC calling convention change for value types in compiled code In-Reply-To: References: Message-ID: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> Hi Roland, On 11/24/2016 11:25 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/valhalla/callingconvention/webrev.00/ > > This patch implements a new compiled code calling convention for methods > that take value type arguments: instead of passing a reference to the > value type as an argument, the method is passed each field of the value > type in registers/stack slots. > > The interpreter continues to use references at calls so when going to > compiled from the interpreter (i2c adapter), value type fields are > loaded from the value type object and the value type object is > discarded. When going from compiled code to the interpreter (c2i > adapter), value type objects for every arguments need to be allocated > and initialized with the field values passed by the compiler. the change looks good to me in general. Please find some minor comments below: = src/cpu/x86/vm/sharedRuntime_x86_64.cpp Don't we have one T_VOID too much here? 561 // flattened so, for instance: T_VALUETYPE T_INT T_VALUETYPE 562 // T_INT T_LONG T_VOID T_VOID T_VOID is a value type with a 2 minor typos. 563 // int field an a value type field that itself has 2 fields, a 564 // int and a long => 563 // int field and a value type field that itself has 2 fields, an 564 // int and a long Maybe it's better to have a more precise condition here: 692 if (i != sig.length()) { => 692 if (i < sig.length()) { Can you maybe find more suggestive names for j and k (and maybe i) in gen_c2i_adapter_helper()? 766 for (int i = 0, ignored = 0, j = 0, k = 0; i < sig.length(); i++) { Maybe next_vt_arg_comp for j, next_arg_int for k and next_arg_comp for k? These are long variable names, I agree, but it would be helpful if the code indicated which variable represents the interpreter's and which the compiler's point of view. The same could be applied to gen_i2c_adapter() 1029 for (int i = 0, ignored = 0, k = 0; i < sig.length(); i++) { Can we maybe change the method name to reflect that the number of arguments computed is from the point of view of the interpreter? 552 static int compute_total_args_passed_int(const GrowableArray& sig) { Maybe it would be also good to change the argument name to sig_extended or sig_cc so that it's more obvious that this is the signature used by the calling convention (and not the declared signature). So in SharedRuntime::gen_i2c_adapter, you could change 1018 int total_args_passed = compute_total_args_passed(sig); to 1018 int total_args_passed_int = compute_total_args_passed_int(sig_extended); = src/share/vm/opto/type.hpp 1536 const TypeTuple* const _domain_sig; // Domain of inputs 1537 const TypeTuple* const _domain_cc; // Domain of inputs Could you please add a comment to explain what the difference between _domain_sig and _domain_cc is? I see that 'cc' refers to calling convention, but that was not obvious on the first sight. Or maybe you can use _domain_sig_extended instead. (Whatever you may pick, it would be great if it stayed consistent with the terms you use at other places, e.g., in the adapter generation). The comment in src/share/vm/opto/type.cpp describes very well what is happening, maybe you can reuse part of that text. 1558 static const TypeFunc *make(const TypeTuple* domain, const TypeTuple* domain_cc, const TypeTuple* range); You could add a version of the make method that takes only one domain argument for the case domain_sig and domain_sig_extended are the same. (There are more than 30 places where the two are equal and only one place where they are not.) 652 static const TypeTuple *make_domain(ciInstanceKlass* recv, ciSignature *sig, bool is_cc = false); Could you please give a more suggestive name to the 'is_cc'? You don't actually check that we have a calling convention but rather if the special calling convention for VT fields is enabled. Maybe vt_fields_as_args_enabled could work. = src/share/vm/opto/type.cpp Could you please move the extra_value_fields() and collect_value_fields() functions to ciValueKlass? Both functions operate on a ciValueKlass instance and maybe we want to use them later in some other context. Maybe add a short comment summarizing what those functions do. = src/share/vm/opto/callGenerator.cpp 375 // FIXME: late inlining of methods that take value type arguments is 376 // broken: arguments at the call are set up so fields of value type 377 // arguments are passed but code here expects a single argument per 378 // value type (a ValueTypeNode) instead. How difficult do you think it will be to fix late inlining later on? It's fine to do the fix later -- I'm just wondering if there is anything here that would cause a large difficulty for us later on (most likely not, but better to ask). = src/share/vm/runtime/globals.hpp 4183 experimental(bool, ValueTypePassFieldsAsArgs, true, \ 4184 "Pass each field as an argument at calls") \ Can you please correct the indentation in the second line? Thank you! Best regards, Zoltan > > Roland. From maurizio.cimadamore at oracle.com Thu Nov 24 14:38:52 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 24 Nov 2016 14:38:52 +0000 Subject: Nestmates MH tests update to use javac flag In-Reply-To: References: Message-ID: <80e78830-10e1-b736-4973-1257773bf528@oracle.com> Looks good to me - note that I think that hotspot changes by themselves might not be sufficient for having these test to pass - some upgrade to the 292 machinery to take nestmates into account might also be in order. Maurizio On 24/11/16 11:56, Stanislav Smirnov wrote: > Hi, > > please take a look on this changes to nestmates MH tests. > Tests start using -XDdisableAccessors javac flag to stop generating access bridges and so verify the vm changes. > Without vm support tests will fail on setUp phase because without access bridges there is no way to refer to ?super? fields/methods from inner classes. > Also in MethodHandleSubTop class lookup and mt access modifiers have been changed to package private to give access from inner classes without bridges. > Rest of the changes verify that there are no access bridges available and some tests are now positive, expecting accessibility, plus added comments to the test cases. > > webrev: http://cr.openjdk.java.net/~stsmirno/mhtests/webrev.00 > > And I will need a sponsor for this change. > > Best regards, > Stanislav Smirnov > > > > > From stanislav.smirnov at oracle.com Thu Nov 24 14:43:19 2016 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Thu, 24 Nov 2016 17:43:19 +0300 Subject: Nestmates MH tests update to use javac flag In-Reply-To: <80e78830-10e1-b736-4973-1257773bf528@oracle.com> References: <80e78830-10e1-b736-4973-1257773bf528@oracle.com> Message-ID: Maurizio, thank you for a review. Yes, 292 machinery requires upgrade, we have discussed it with Karen, not yet sure, who will be doing it, but thanks for pointing it out. Best regards, Stanislav Smirnov > On 24 Nov 2016, at 17:38, Maurizio Cimadamore wrote: > > Looks good to me - note that I think that hotspot changes by themselves might not be sufficient for having these test to pass - some upgrade to the 292 machinery to take nestmates into account might also be in order. > > Maurizio > > > On 24/11/16 11:56, Stanislav Smirnov wrote: >> Hi, >> >> please take a look on this changes to nestmates MH tests. >> Tests start using -XDdisableAccessors javac flag to stop generating access bridges and so verify the vm changes. >> Without vm support tests will fail on setUp phase because without access bridges there is no way to refer to ?super? fields/methods from inner classes. >> Also in MethodHandleSubTop class lookup and mt access modifiers have been changed to package private to give access from inner classes without bridges. >> Rest of the changes verify that there are no access bridges available and some tests are now positive, expecting accessibility, plus added comments to the test cases. >> >> webrev: http://cr.openjdk.java.net/~stsmirno/mhtests/webrev.00 >> >> And I will need a sponsor for this change. >> >> Best regards, >> Stanislav Smirnov >> >> >> >> >> > From srikanth.adayapalam at oracle.com Fri Nov 25 07:40:52 2016 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Fri, 25 Nov 2016 07:40:52 +0000 Subject: hg: valhalla/valhalla/langtools: Enhancement: Add support for alternate mode of value creation using __MakeDefault Message-ID: <201611250740.uAP7eq0r011888@aojmv0008.oracle.com> Changeset: a82751a8e69b Author: sadayapalam Date: 2016-11-25 13:10 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/a82751a8e69b Enhancement: Add support for alternate mode of value creation using __MakeDefault ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java ! src/jdk.compiler/share/classes/com/sun/source/tree/NewClassTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ByteCodes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Opcode.java ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/valhalla/values/CheckMakeDefault.java + test/tools/javac/valhalla/values/CheckMakeDefault.out + test/tools/javac/valhalla/values/CheckStaticValueFactory.java + test/tools/javac/valhalla/values/CheckStaticValueFactory.out + test/tools/javac/valhalla/values/ValueCreationTest.java From david.simms at oracle.com Fri Nov 25 12:32:23 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Fri, 25 Nov 2016 12:32:23 +0000 Subject: hg: valhalla/valhalla/hotspot: Summary: Nestmates MH tests update to use javac flag Message-ID: <201611251232.uAPCWN6K005869@aojmv0008.oracle.com> Changeset: 05e526e60802 Author: stsmirno Date: 2016-11-25 13:25 +0300 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/05e526e60802 Summary: Nestmates MH tests update to use javac flag Reviewed-by: mcimadamore Contributed-by: stanislav.smirnov at oracle.com ! test/runtime/valhalla/nestmates/MethodHandleInheritTest.java ! test/runtime/valhalla/nestmates/p2/MethodHandleSubTop.java From david.simms at oracle.com Fri Nov 25 12:49:51 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Fri, 25 Nov 2016 12:49:51 +0000 Subject: hg: valhalla/valhalla/hotspot: Disable failing test Message-ID: <201611251249.uAPCnpHP011727@aojmv0008.oracle.com> Changeset: 45ea489c4a47 Author: dsimms Date: 2016-11-25 13:49 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/45ea489c4a47 Disable failing test ! test/TEST.groups From tobias.hartmann at oracle.com Fri Nov 25 15:30:14 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 25 Nov 2016 16:30:14 +0100 Subject: RFR/RFC calling convention change for value types in compiled code In-Reply-To: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> References: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> Message-ID: <58385906.1050103@oracle.com> Hi Roland, very nice work! Apart from the points that Zoltan already mentioned, I noticed the following: - sharedRuntime_x86_64.cpp: - both branches of the if in line 635 contain the same statement. The comment in the first branch refers to the removed st_off/next_off. - line 656: shouldn't this be "movq" and can then be merged with the first branch? - callGenerator.cpp: - I would move the !ValueTypePassFieldsAsArgs condition in line 157 to the outer if - There are lots of "domain() -> domain_sig()" changes. Maybe it would make sense to not rename domain() but only add domain_cc(). - Please add messages to asserts like "assert(type->is_valuetype(), "")" or remove the "" - I saw that you also fixed the invokedirect problem you've mentioned. Was this problem triggered by one of the tests you added? - The test changes look good, great that you were able to handle both flag settings with the same tests. [The following thoughts are out of the scope of this but should be considered for future work] Below code allocates the value type 'v' three times although only one allocation is required: 1: MyValue v = createInline(); 2: pass_to_interpreter(v); 3: pass_to_interpreter(v); 4: v = compiled_return(v); // this compiled callee method does "vreturn v;" Allocation in line 2 is required because we call interpreted code. In line 3, we allocate again because allocation in line 2 happened in the c2i adapter and the oop is not passed back to the caller. In line 4, we have to load the field values from memory, pass them to the compiled callee and re-allocate the value type on vreturn. My idea is to solve this problem by having read/write oop arguments. Like this, we could pass an additional oop argument for each VT parameter that can be NULL and set the oop in the c2i adapter or the compiled callee after allocation happened the first time. In line 2, we would then pass NULL as oop argument and the adapter would set the oop after allocating the VT. In line 3, we would re-use that oop and the c2i adapter would not allocate again. In line 4, we would not allocate in the callee because we receive a non-null oop. This would also solve the problem of how to avoid allocations when returning to compiled code. For example: MyValue get() { return createInline(); } would always allocate the VT even if we return to compiled code. We could now pass an additional oop to an uninitialized VT as argument to get() to hold the to be returned VT. The buffered VT is then initialized in the callee if the oop argument is non-NULL instead of allocating and returning a new VT (this would of course require interpreter support). The advantage is that we can defer allocation to the caller (recursively), potentially increasing optimization opportunities and avoiding allocations in long call/return chains. We should also consider passing VTs "by value" only if the field values are available as constants or have to be loaded in the callee anyway. Otherwise, we may load field values from memory just to pass them to the callee when it may be more beneficial to just pass an oop and avoid field loads (especially for large value types). Thanks, Tobias On 24.11.2016 15:16, Zolt?n Maj? wrote: > Hi Roland, > > > On 11/24/2016 11:25 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/valhalla/callingconvention/webrev.00/ >> >> This patch implements a new compiled code calling convention for methods >> that take value type arguments: instead of passing a reference to the >> value type as an argument, the method is passed each field of the value >> type in registers/stack slots. >> >> The interpreter continues to use references at calls so when going to >> compiled from the interpreter (i2c adapter), value type fields are >> loaded from the value type object and the value type object is >> discarded. When going from compiled code to the interpreter (c2i >> adapter), value type objects for every arguments need to be allocated >> and initialized with the field values passed by the compiler. > > the change looks good to me in general. Please find some minor comments below: > > = src/cpu/x86/vm/sharedRuntime_x86_64.cpp > > Don't we have one T_VOID too much here? > > 561 // flattened so, for instance: T_VALUETYPE T_INT T_VALUETYPE > 562 // T_INT T_LONG T_VOID T_VOID T_VOID is a value type with a > > > 2 minor typos. > > 563 // int field an a value type field that itself has 2 fields, a > 564 // int and a long > > => > > 563 // int field and a value type field that itself has 2 fields, an > 564 // int and a long > > > Maybe it's better to have a more precise condition here: > > 692 if (i != sig.length()) { > > => > > 692 if (i < sig.length()) { > > > Can you maybe find more suggestive names for j and k (and maybe i) in gen_c2i_adapter_helper()? > > 766 for (int i = 0, ignored = 0, j = 0, k = 0; i < sig.length(); i++) { > > Maybe next_vt_arg_comp for j, next_arg_int for k and next_arg_comp for k? These are long variable names, I agree, but it would be helpful if the code indicated which variable represents the interpreter's and which the compiler's point of view. > > The same could be applied to gen_i2c_adapter() > > 1029 for (int i = 0, ignored = 0, k = 0; i < sig.length(); i++) { > > > Can we maybe change the method name to reflect that the number of arguments computed is from the point of view of the interpreter? > > 552 static int compute_total_args_passed_int(const GrowableArray& sig) { > > Maybe it would be also good to change the argument name to sig_extended or sig_cc so that it's more obvious that this is the signature used by the calling convention (and not the declared signature). > > So in SharedRuntime::gen_i2c_adapter, you could change > > 1018 int total_args_passed = compute_total_args_passed(sig); > > to > > 1018 int total_args_passed_int = compute_total_args_passed_int(sig_extended); > > > = src/share/vm/opto/type.hpp > > 1536 const TypeTuple* const _domain_sig; // Domain of inputs > 1537 const TypeTuple* const _domain_cc; // Domain of inputs > > Could you please add a comment to explain what the difference between _domain_sig and _domain_cc is? I see that 'cc' refers to calling convention, but that was not obvious on the first sight. Or maybe you can use _domain_sig_extended instead. (Whatever you may pick, it would be great if it stayed consistent with the terms you use at other places, e.g., in the adapter generation). > > The comment in src/share/vm/opto/type.cpp describes very well what is happening, maybe you can reuse part of that text. > > > 1558 static const TypeFunc *make(const TypeTuple* domain, const TypeTuple* domain_cc, const TypeTuple* range); > > You could add a version of the make method that takes only one domain argument for the case domain_sig and domain_sig_extended are the same. (There are more than 30 places where the two are equal and only one place where they are not.) > > > 652 static const TypeTuple *make_domain(ciInstanceKlass* recv, ciSignature *sig, bool is_cc = false); > > Could you please give a more suggestive name to the 'is_cc'? You don't actually check that we have a calling convention but rather if the special calling convention for VT fields is enabled. Maybe vt_fields_as_args_enabled could work. > > > = src/share/vm/opto/type.cpp > > Could you please move the extra_value_fields() and collect_value_fields() functions to ciValueKlass? Both functions operate on a ciValueKlass instance and maybe we want to use them later in some other context. Maybe add a short comment summarizing what those functions do. > > > = src/share/vm/opto/callGenerator.cpp > > 375 // FIXME: late inlining of methods that take value type arguments is > 376 // broken: arguments at the call are set up so fields of value type > 377 // arguments are passed but code here expects a single argument per > 378 // value type (a ValueTypeNode) instead. > > How difficult do you think it will be to fix late inlining later on? It's fine to do the fix later -- I'm just wondering if there is anything here that would cause a large difficulty for us later on (most likely not, but better to ask). > > > = src/share/vm/runtime/globals.hpp > > 4183 experimental(bool, ValueTypePassFieldsAsArgs, true, \ > 4184 "Pass each field as an argument at calls") \ > > Can you please correct the indentation in the second line? > > Thank you! > > Best regards, > > > Zoltan > >> >> Roland. > From zoltan.majo at oracle.com Mon Nov 28 08:20:41 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 28 Nov 2016 09:20:41 +0100 Subject: RFR/RFC calling convention change for value types in compiled code In-Reply-To: <58385906.1050103@oracle.com> References: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> <58385906.1050103@oracle.com> Message-ID: Hi, On 11/25/2016 04:30 PM, Tobias Hartmann wrote: > [...] > > [The following thoughts are out of the scope of this but should be considered for future work] > > Below code allocates the value type 'v' three times although only one allocation is required: > > 1: MyValue v = createInline(); > 2: pass_to_interpreter(v); > 3: pass_to_interpreter(v); > 4: v = compiled_return(v); // this compiled callee method does "vreturn v;" > > Allocation in line 2 is required because we call interpreted code. In line 3, we allocate again because allocation in line 2 happened in the c2i adapter and the oop is not passed back to the caller. In line 4, we have to load the field values from memory, pass them to the compiled callee and re-allocate the value type on vreturn. > > My idea is to solve this problem by having read/write oop arguments. Like this, we could pass an additional oop argument for each VT parameter that can be NULL and set the oop in the c2i adapter or the compiled callee after allocation happened the first time. > In line 2, we would then pass NULL as oop argument and the adapter would set the oop after allocating the VT. In line 3, we would re-use that oop and the c2i adapter would not allocate again. In line 4, we would not allocate in the callee because we receive a non-null oop. Passing an oop to compiled code for each VT argument could help us avoid some allocations (even if oops are "read-only", i.e., the way the system currently works). I have the following scenario in mind: interpreted method m1(VT v1) -> compiled method m2(VT v1) -> call interpreted method m3(VT v1) All three methods are passed the same VT v1 instance. In method m1(), VT v1 "has" an oop because m1() is interpreted. With Roland's suggested changes, the oop for VT v1 is not available in method m2(), as m2 is compiled (only v1's fields are available there). When the interpreted method m3() is called, the oop for VT v1 is created again. If we would pass both the VT oops and fields to compiled methods, we could avoid (re-)allocation of VT v1 when m3() is called. Best regards, Zoltan > > This would also solve the problem of how to avoid allocations when returning to compiled code. For example: > > MyValue get() { > return createInline(); > } > > would always allocate the VT even if we return to compiled code. We could now pass an additional oop to an uninitialized VT as argument to get() to hold the to be returned VT. The buffered VT is then initialized in the callee if the oop argument is non-NULL instead of allocating and returning a new VT (this would of course require interpreter support). The advantage is that we can defer allocation to the caller (recursively), potentially increasing optimization opportunities and avoiding allocations in long call/return chains. > > We should also consider passing VTs "by value" only if the field values are available as constants or have to be loaded in the callee anyway. Otherwise, we may load field values from memory just to pass them to the callee when it may be more beneficial to just pass an oop and avoid field loads (especially for large value types). > > Thanks, > Tobias > > On 24.11.2016 15:16, Zolt?n Maj? wrote: >> Hi Roland, >> >> >> On 11/24/2016 11:25 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/valhalla/callingconvention/webrev.00/ >>> >>> This patch implements a new compiled code calling convention for methods >>> that take value type arguments: instead of passing a reference to the >>> value type as an argument, the method is passed each field of the value >>> type in registers/stack slots. >>> >>> The interpreter continues to use references at calls so when going to >>> compiled from the interpreter (i2c adapter), value type fields are >>> loaded from the value type object and the value type object is >>> discarded. When going from compiled code to the interpreter (c2i >>> adapter), value type objects for every arguments need to be allocated >>> and initialized with the field values passed by the compiler. >> the change looks good to me in general. Please find some minor comments below: >> >> = src/cpu/x86/vm/sharedRuntime_x86_64.cpp >> >> Don't we have one T_VOID too much here? >> >> 561 // flattened so, for instance: T_VALUETYPE T_INT T_VALUETYPE >> 562 // T_INT T_LONG T_VOID T_VOID T_VOID is a value type with a >> >> >> 2 minor typos. >> >> 563 // int field an a value type field that itself has 2 fields, a >> 564 // int and a long >> >> => >> >> 563 // int field and a value type field that itself has 2 fields, an >> 564 // int and a long >> >> >> Maybe it's better to have a more precise condition here: >> >> 692 if (i != sig.length()) { >> >> => >> >> 692 if (i < sig.length()) { >> >> >> Can you maybe find more suggestive names for j and k (and maybe i) in gen_c2i_adapter_helper()? >> >> 766 for (int i = 0, ignored = 0, j = 0, k = 0; i < sig.length(); i++) { >> >> Maybe next_vt_arg_comp for j, next_arg_int for k and next_arg_comp for k? These are long variable names, I agree, but it would be helpful if the code indicated which variable represents the interpreter's and which the compiler's point of view. >> >> The same could be applied to gen_i2c_adapter() >> >> 1029 for (int i = 0, ignored = 0, k = 0; i < sig.length(); i++) { >> >> >> Can we maybe change the method name to reflect that the number of arguments computed is from the point of view of the interpreter? >> >> 552 static int compute_total_args_passed_int(const GrowableArray& sig) { >> >> Maybe it would be also good to change the argument name to sig_extended or sig_cc so that it's more obvious that this is the signature used by the calling convention (and not the declared signature). >> >> So in SharedRuntime::gen_i2c_adapter, you could change >> >> 1018 int total_args_passed = compute_total_args_passed(sig); >> >> to >> >> 1018 int total_args_passed_int = compute_total_args_passed_int(sig_extended); >> >> >> = src/share/vm/opto/type.hpp >> >> 1536 const TypeTuple* const _domain_sig; // Domain of inputs >> 1537 const TypeTuple* const _domain_cc; // Domain of inputs >> >> Could you please add a comment to explain what the difference between _domain_sig and _domain_cc is? I see that 'cc' refers to calling convention, but that was not obvious on the first sight. Or maybe you can use _domain_sig_extended instead. (Whatever you may pick, it would be great if it stayed consistent with the terms you use at other places, e.g., in the adapter generation). >> >> The comment in src/share/vm/opto/type.cpp describes very well what is happening, maybe you can reuse part of that text. >> >> >> 1558 static const TypeFunc *make(const TypeTuple* domain, const TypeTuple* domain_cc, const TypeTuple* range); >> >> You could add a version of the make method that takes only one domain argument for the case domain_sig and domain_sig_extended are the same. (There are more than 30 places where the two are equal and only one place where they are not.) >> >> >> 652 static const TypeTuple *make_domain(ciInstanceKlass* recv, ciSignature *sig, bool is_cc = false); >> >> Could you please give a more suggestive name to the 'is_cc'? You don't actually check that we have a calling convention but rather if the special calling convention for VT fields is enabled. Maybe vt_fields_as_args_enabled could work. >> >> >> = src/share/vm/opto/type.cpp >> >> Could you please move the extra_value_fields() and collect_value_fields() functions to ciValueKlass? Both functions operate on a ciValueKlass instance and maybe we want to use them later in some other context. Maybe add a short comment summarizing what those functions do. >> >> >> = src/share/vm/opto/callGenerator.cpp >> >> 375 // FIXME: late inlining of methods that take value type arguments is >> 376 // broken: arguments at the call are set up so fields of value type >> 377 // arguments are passed but code here expects a single argument per >> 378 // value type (a ValueTypeNode) instead. >> >> How difficult do you think it will be to fix late inlining later on? It's fine to do the fix later -- I'm just wondering if there is anything here that would cause a large difficulty for us later on (most likely not, but better to ask). >> >> >> = src/share/vm/runtime/globals.hpp >> >> 4183 experimental(bool, ValueTypePassFieldsAsArgs, true, \ >> 4184 "Pass each field as an argument at calls") \ >> >> Can you please correct the indentation in the second line? >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> Roland.