From david.simms at oracle.com Thu Dec 1 14:08:14 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 01 Dec 2016 14:08:14 +0000 Subject: hg: valhalla/valhalla/hotspot: MVT 1.0 prototype Message-ID: <201612011408.uB1E8ELC010420@aojmv0008.oracle.com> Changeset: eb843f5ed7e3 Author: dsimms Date: 2016-12-01 15:06 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/eb843f5ed7e3 MVT 1.0 prototype ! src/cpu/x86/vm/templateTable_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlass.inline.hpp ! src/share/vm/oops/valueKlass.cpp ! src/share/vm/oops/valueKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/exceptions.hpp + test/runtime/valhalla/valuetypes/DeriveValueTypeCreation.java + test/runtime/valhalla/valuetypes/ValueCapableClass.java + test/runtime/valhalla/valuetypes/VboxUnbox.java From david.simms at oracle.com Thu Dec 1 14:08:29 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 01 Dec 2016 14:08:29 +0000 Subject: hg: valhalla/valhalla/jdk: MVT 1.0 prototype Message-ID: <201612011408.uB1E8UcA010579@aojmv0008.oracle.com> Changeset: c7c97756db18 Author: mcimadamore Date: 2016-12-01 15:06 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/c7c97756db18 MVT 1.0 prototype ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + src/java.base/share/classes/jdk/experimental/bytecode/AbstractBuilder.java + src/java.base/share/classes/jdk/experimental/bytecode/AnnotationsBuilder.java + src/java.base/share/classes/jdk/experimental/bytecode/AttributeBuilder.java + src/java.base/share/classes/jdk/experimental/bytecode/BasicClassBuilder.java + src/java.base/share/classes/jdk/experimental/bytecode/ClassBuilder.java + src/java.base/share/classes/jdk/experimental/bytecode/CodeBuilder.java + src/java.base/share/classes/jdk/experimental/bytecode/DeclBuilder.java + src/java.base/share/classes/jdk/experimental/bytecode/FieldBuilder.java + src/java.base/share/classes/jdk/experimental/bytecode/Flag.java + src/java.base/share/classes/jdk/experimental/bytecode/GrowableByteBuffer.java + src/java.base/share/classes/jdk/experimental/bytecode/MacroCodeBuilder.java + src/java.base/share/classes/jdk/experimental/bytecode/MemberBuilder.java + src/java.base/share/classes/jdk/experimental/bytecode/MethodBuilder.java + src/java.base/share/classes/jdk/experimental/bytecode/Opcode.java + src/java.base/share/classes/jdk/experimental/bytecode/PoolHelper.java + src/java.base/share/classes/jdk/experimental/bytecode/PoolTag.java + src/java.base/share/classes/jdk/experimental/bytecode/Type.java + src/java.base/share/classes/jdk/experimental/bytecode/TypeHelper.java + src/java.base/share/classes/jdk/experimental/bytecode/TypeTag.java + src/java.base/share/classes/jdk/experimental/bytecode/TypedCodeBuilder.java + src/java.base/share/classes/jdk/experimental/value/MethodHandleBuilder.java + src/java.base/share/classes/jdk/experimental/value/ValueType.java + src/java.base/share/classes/jvm/internal/value/DeriveValueType.java ! src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java ! src/java.base/share/classes/valhalla/model3/classfile/ClassReader.java ! src/java.base/share/classes/valhalla/model3/classfile/Code_attribute.java ! src/java.base/share/classes/valhalla/model3/classfile/Method.java + src/java.base/share/classes/valhalla/shady/MinimalValueTypes_1_0.java + src/java.base/share/classes/valhalla/shady/ValueTypeDesc.java + test/valhalla/mvt/MVTTest.java + test/valhalla/mvt/Point.java From david.simms at oracle.com Thu Dec 1 14:08:36 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 01 Dec 2016 14:08:36 +0000 Subject: hg: valhalla/valhalla/langtools: MVT 1.0 prototype Message-ID: <201612011408.uB1E8aQh010692@aojmv0008.oracle.com> Changeset: ce7460995ffc Author: dsimms Date: 2016-12-01 15:06 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ce7460995ffc MVT 1.0 prototype ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Opcode.java From david.simms at oracle.com Thu Dec 1 14:11:17 2016 From: david.simms at oracle.com (David Simms) Date: Thu, 1 Dec 2016 15:11:17 +0100 Subject: Prototype of "Minimal Value Types" (MVT) Message-ID: <937dd1cc-b07a-642a-9d7d-6fda733c852c@oracle.com> Recently pushed into the Valhalla repository with the comment "MVT 1.0 prototype": This is an initial prototype of "Minimal Value Types" document [1] (MVT), proposed by Brian Goetz and John Rose back in August. The document describes a possible means of delivering an experimental test vehicle for "Value Type" [2] features, without committing to language or VM specification changes. There are a number of differences in implementation compared to the "Minimal Value Types" document: Annotating a "Value Capable Class" (VCC) with "jvm.internal.value.DeriveValueType": The VM does not modify the VCC in anyway The value type derived from the VCC is not a an inner class of VCC, but merely provides the same instance fields "jdk.experimental.value.ValueType" API is by no means final, or even complete with regards to the MVT document Caveats, use of "DeriveValueType" annotation and the "ValueType" method handle API: Limited to x86_64 platform JIT support is missing, must use "-Xint" Verifier support is missing, must use "-noverify" MethodHandles dealing with value types are implemented using bytecodes that are libel to change. Much of the underlying implementation is nowhere near production quality. Quite the opposite, we are still prototyping new ideas and wish to maintain some flexibility. Performance improvements will be in most cases using Value Types, completely out of the question at this point. Example usage: test/valhalla/mvt/MVTTest.java [1] http://cr.openjdk.java.net/~jrose/values/shady-values.html [2] http://cr.openjdk.java.net/~jrose/values/values.html From frederic.parain at oracle.com Thu Dec 1 18:38:42 2016 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Thu, 01 Dec 2016 18:38:42 +0000 Subject: hg: valhalla/valhalla/hotspot: Fixing missing ResourceMark in vnew Message-ID: <201612011838.uB1IcgXX025997@aojmv0008.oracle.com> Changeset: 916b58a7a12d Author: fparain Date: 2016-12-01 13:37 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/916b58a7a12d Fixing missing ResourceMark in vnew ! src/share/vm/interpreter/interpreterRuntime.cpp ! test/TEST.groups From tobias.hartmann at oracle.com Fri Dec 2 09:54:17 2016 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Fri, 02 Dec 2016 09:54:17 +0000 Subject: hg: valhalla/valhalla/hotspot: Summary: Support for OSR, fixed a VT merging problem with -Xcomp, support for static/final value type fields, new tests Message-ID: <201612020954.uB29sHi8012641@aojmv0008.oracle.com> Changeset: 2d08d043fa74 Author: thartmann Date: 2016-12-02 10:54 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2d08d043fa74 Summary: Support for OSR, fixed a VT merging problem with -Xcomp, support for static/final value type fields, new tests ! src/share/vm/ci/ciConstant.cpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciValueKlass.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/opto/valuetypenode.cpp ! src/share/vm/opto/valuetypenode.hpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From tobias.hartmann at oracle.com Fri Dec 2 09:59:16 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 2 Dec 2016 10:59:16 +0100 Subject: hg: valhalla/valhalla/hotspot: Summary: Support for OSR, fixed a VT merging problem with -Xcomp, support for static/final value type fields, new tests In-Reply-To: <201612020954.uB29sHi8012641@aojmv0008.oracle.com> References: <201612020954.uB29sHi8012641@aojmv0008.oracle.com> Message-ID: <584145F4.7080505@oracle.com> Hi, I just pushed a fix for the following compiler related value type issues: 1) On Stack Replacement does not work if the OSR compiled code references a live value type in the interpreter state 2) There is a bug in the code that merges value types coming from multiple branches 3) C2 does not yet support static/final value type fields in objects Static final value type field loads are now constant folded. I added tests for all these issues. Best regards, Tobias On 02.12.2016 10:54, tobias.hartmann at oracle.com wrote: > Changeset: 2d08d043fa74 > Author: thartmann > Date: 2016-12-02 10:54 +0100 > URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/2d08d043fa74 > > Summary: Support for OSR, fixed a VT merging problem with -Xcomp, support for static/final value type fields, new tests > > ! src/share/vm/ci/ciConstant.cpp > ! src/share/vm/ci/ciConstant.hpp > ! src/share/vm/ci/ciField.cpp > ! src/share/vm/ci/ciInstance.cpp > ! src/share/vm/ci/ciInstanceKlass.cpp > ! src/share/vm/ci/ciValueKlass.cpp > ! src/share/vm/opto/graphKit.cpp > ! src/share/vm/opto/memnode.cpp > ! src/share/vm/opto/parse.hpp > ! src/share/vm/opto/parse1.cpp > ! src/share/vm/opto/parse3.cpp > ! src/share/vm/opto/type.cpp > ! src/share/vm/opto/type.hpp > ! src/share/vm/opto/valuetypenode.cpp > ! src/share/vm/opto/valuetypenode.hpp > ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java > From rahman.usta.88 at gmail.com Fri Dec 2 19:58:32 2016 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Fri, 2 Dec 2016 22:58:32 +0300 Subject: Building Valhalla Message-ID: Hello, I'm getting following errors when I try to build Valhalla. Java HotSpot(TM) 64-Bit Server VM (build 9-ea+146, mixed mode) Building target 'images' in configuration 'linux-x86_64-normal-server-release' Compiling 1043 files for BUILD_INTERIM_LANGTOOLS ERROR: Build failed for target 'images' in configuration 'linux-x86_64-normal-server-release' (exit code 2) === Output from failing command(s) repeated here === * For target buildtools_langtools_interim_classes__the.BUILD_INTERIM_LANGTOOLS_batch: /opt/valhalla/langtools/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java:26: error: package exists in another module: java.compiler package javax.annotation.processing; ^ /opt/valhalla/langtools/src/java.compiler/share/classes/javax/annotation/processing/Completion.java:26: error: package exists in another module: java.compiler package javax.annotation.processing; ^ /opt/valhalla/langtools/src/java.compiler/share/classes/javax/annotation/processing/Completions.java:26: error: package exists in another module: java.compiler package javax.annotation.processing; ^ /opt/valhalla/langtools/src/java.compiler/share/classes/javax/annotation/processing/Filer.java:26: error: package exists in another module: java.compiler package javax.annotation.processing; ^ ... (rest of output omitted) === End of repeated output === No indication of failed target found. Hint: Try searching the build log for '] Error'. Hint: If caused by a warning, try configure --disable-warnings-as-errors. How can I solve this issue ? Thanks -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From maurizio.cimadamore at oracle.com Fri Dec 2 21:40:11 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 2 Dec 2016 21:40:11 +0000 Subject: Building Valhalla In-Reply-To: References: Message-ID: <280fc508-9feb-cdf6-d6cb-cb60353c437e@oracle.com> I think you are using a bootstrap JDK that is too recent (looks like JDK 9 b146?). Try using JDK 8 as bootstrap. Maurizio On 02/12/16 19:58, Rahman USTA wrote: > Hello, > > I'm getting following errors when I try to build Valhalla. > > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+146, mixed mode) > > Building target 'images' in configuration > 'linux-x86_64-normal-server-release' > Compiling 1043 files for BUILD_INTERIM_LANGTOOLS > > ERROR: Build failed for target 'images' in configuration > 'linux-x86_64-normal-server-release' (exit code 2) > === Output from failing command(s) repeated here === > * For target > buildtools_langtools_interim_classes__the.BUILD_INTERIM_LANGTOOLS_batch: > /opt/valhalla/langtools/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java:26: > error: package exists in another module: java.compiler > package javax.annotation.processing; > ^ > /opt/valhalla/langtools/src/java.compiler/share/classes/javax/annotation/processing/Completion.java:26: > error: package exists in another module: java.compiler > package javax.annotation.processing; > ^ > /opt/valhalla/langtools/src/java.compiler/share/classes/javax/annotation/processing/Completions.java:26: > error: package exists in another module: java.compiler > package javax.annotation.processing; > ^ > /opt/valhalla/langtools/src/java.compiler/share/classes/javax/annotation/processing/Filer.java:26: > error: package exists in another module: java.compiler > package javax.annotation.processing; > ^ > ... (rest of output omitted) > === End of repeated output === > No indication of failed target found. > Hint: Try searching the build log for '] Error'. > Hint: If caused by a warning, try configure --disable-warnings-as-errors. > > How can I solve this issue ? > > Thanks > From rahman.usta.88 at gmail.com Sat Dec 3 15:29:41 2016 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Sat, 3 Dec 2016 18:29:41 +0300 Subject: Building Valhalla In-Reply-To: <280fc508-9feb-cdf6-d6cb-cb60353c437e@oracle.com> References: <280fc508-9feb-cdf6-d6cb-cb60353c437e@oracle.com> Message-ID: Hi Maurizo, It is compiled with JDK 8, but produced JDK doesn't compile for example List list; What I'm missing here? Which features are implemented? Thanks 2 Ara 2016 23:40 tarihinde "Maurizio Cimadamore" < maurizio.cimadamore at oracle.com> yazd?: > I think you are using a bootstrap JDK that is too recent (looks like JDK 9 > b146?). > > Try using JDK 8 as bootstrap. > > Maurizio > > On 02/12/16 19:58, Rahman USTA wrote: > >> Hello, >> >> I'm getting following errors when I try to build Valhalla. >> >> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+146, mixed mode) >> >> Building target 'images' in configuration >> 'linux-x86_64-normal-server-release' >> Compiling 1043 files for BUILD_INTERIM_LANGTOOLS >> >> ERROR: Build failed for target 'images' in configuration >> 'linux-x86_64-normal-server-release' (exit code 2) >> === Output from failing command(s) repeated here === >> * For target >> buildtools_langtools_interim_classes__the.BUILD_INTERIM_LANGTOOLS_batch: >> /opt/valhalla/langtools/src/java.compiler/share/classes/java >> x/annotation/processing/AbstractProcessor.java:26: >> error: package exists in another module: java.compiler >> package javax.annotation.processing; >> ^ >> /opt/valhalla/langtools/src/java.compiler/share/classes/java >> x/annotation/processing/Completion.java:26: >> error: package exists in another module: java.compiler >> package javax.annotation.processing; >> ^ >> /opt/valhalla/langtools/src/java.compiler/share/classes/java >> x/annotation/processing/Completions.java:26: >> error: package exists in another module: java.compiler >> package javax.annotation.processing; >> ^ >> /opt/valhalla/langtools/src/java.compiler/share/classes/java >> x/annotation/processing/Filer.java:26: >> error: package exists in another module: java.compiler >> package javax.annotation.processing; >> ^ >> ... (rest of output omitted) >> === End of repeated output === >> No indication of failed target found. >> Hint: Try searching the build log for '] Error'. >> Hint: If caused by a warning, try configure --disable-warnings-as-errors. >> >> How can I solve this issue ? >> >> Thanks >> >> > From maurizio.cimadamore at oracle.com Mon Dec 5 10:41:54 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 5 Dec 2016 10:41:54 +0000 Subject: Building Valhalla In-Reply-To: References: <280fc508-9feb-cdf6-d6cb-cb60353c437e@oracle.com> Message-ID: <6d74f0ca-7de9-b7f8-c58c-4e86fbd24ef2@oracle.com> The "anyfied" Collections are under the java.anyutil package - and not under java.util. Could it be that? Maurizio On 03/12/16 15:29, Rahman USTA wrote: > > Hi Maurizo, > > It is compiled with JDK 8, but produced JDK doesn't compile for > example List list; > > What I'm missing here? Which features are implemented? > > Thanks > > > 2 Ara 2016 23:40 tarihinde "Maurizio Cimadamore" > > yazd?: > > I think you are using a bootstrap JDK that is too recent (looks > like JDK 9 b146?). > > Try using JDK 8 as bootstrap. > > Maurizio > > On 02/12/16 19:58, Rahman USTA wrote: > > Hello, > > I'm getting following errors when I try to build Valhalla. > > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+146, mixed mode) > > Building target 'images' in configuration > 'linux-x86_64-normal-server-release' > Compiling 1043 files for BUILD_INTERIM_LANGTOOLS > > ERROR: Build failed for target 'images' in configuration > 'linux-x86_64-normal-server-release' (exit code 2) > === Output from failing command(s) repeated here === > * For target > buildtools_langtools_interim_classes__the.BUILD_INTERIM_LANGTOOLS_batch: > /opt/valhalla/langtools/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java:26: > error: package exists in another module: java.compiler > package javax.annotation.processing; > ^ > /opt/valhalla/langtools/src/java.compiler/share/classes/javax/annotation/processing/Completion.java:26: > error: package exists in another module: java.compiler > package javax.annotation.processing; > ^ > /opt/valhalla/langtools/src/java.compiler/share/classes/javax/annotation/processing/Completions.java:26: > error: package exists in another module: java.compiler > package javax.annotation.processing; > ^ > /opt/valhalla/langtools/src/java.compiler/share/classes/javax/annotation/processing/Filer.java:26: > error: package exists in another module: java.compiler > package javax.annotation.processing; > ^ > ... (rest of output omitted) > === End of repeated output === > No indication of failed target found. > Hint: Try searching the build log for '] Error'. > Hint: If caused by a warning, try configure > --disable-warnings-as-errors. > > How can I solve this issue ? > > Thanks > > From rwestrel at redhat.com Mon Dec 5 13:28:25 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 05 Dec 2016 14:28:25 +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: Hi Zoltan, Thanks for the careful review. See the 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 I think it's good: one T_VOID for the T_LONG and then 2 for each T_VALUETYPE. > 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); So you would change sig to sig_extended everywhere it's used? > = 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. I copied the comment. Not sure there's more to say? sig in sharedRuntime, domain_cc and domain_sig are not the same. sig attempts to sum up both domain_cc and domain_sig so I'm not sure what to do about your comment about naming consistency. > = 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. I can't do that for collect_value_fields() because it fills a Type* array which is c2 only. > = 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). I'll take care of it in a later change. I don't think it's too difficult but it's not straightforward either. Roland. From rwestrel at redhat.com Mon Dec 5 13:54:48 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 05 Dec 2016 14:54:48 +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 Tobias, Thanks for the review. > - callGenerator.cpp: > - I would move the !ValueTypePassFieldsAsArgs condition in line 157 > to the outer if It doesn't seem possible to move it to either: if (!is_static) { because it would skip: // Mark the call node as virtual, sort of: call->set_optimized_virtual(true); ... or: if (kit.argument(0)->is_ValueType()) { because it would then null check an non-existing receiver. > - There are lots of "domain() -> domain_sig()" changes. Maybe it would make sense to not rename domain() but only add domain_cc(). Isn't it better to differentiate the two clearly? > - I saw that you also fixed the invokedirect problem you've mentioned. Was this problem triggered by one of the tests you added? Not by one of my tests but I think any test that uses invokedirect. So one of Zoltan's tests should trigger the problem. Roland. From tobias.hartmann at oracle.com Mon Dec 5 14:03:21 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 5 Dec 2016 15:03:21 +0100 Subject: RFR/RFC calling convention change for value types in compiled code In-Reply-To: References: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> <58385906.1050103@oracle.com> Message-ID: <584573A9.5050606@oracle.com> Hi Roland, On 05.12.2016 14:54, Roland Westrelin wrote: > > Hi Tobias, > > Thanks for the review. > >> - callGenerator.cpp: >> - I would move the !ValueTypePassFieldsAsArgs condition in line 157 >> to the outer if > > It doesn't seem possible to move it to either: > > if (!is_static) { > > because it would skip: > > // Mark the call node as virtual, sort of: > call->set_optimized_virtual(true); > ... > > or: > > if (kit.argument(0)->is_ValueType()) { > > because it would then null check an non-existing receiver. Right, I missed that. >> - There are lots of "domain() -> domain_sig()" changes. Maybe it would make sense to not rename domain() but only add domain_cc(). > > Isn't it better to differentiate the two clearly? Yes, probably it's better to clearly differentiate. I'm fine with that. >> - I saw that you also fixed the invokedirect problem you've mentioned. Was this problem triggered by one of the tests you added? > > Not by one of my tests but I think any test that uses invokedirect. So > one of Zoltan's tests should trigger the problem. Okay, sounds good. Thanks, Tobias > > Roland. > From zoltan.majo at oracle.com Wed Dec 7 09:52:58 2016 From: zoltan.majo at oracle.com (zoltan.majo at oracle.com) Date: Wed, 07 Dec 2016 09:52:58 +0000 Subject: hg: valhalla/valhalla/hotspot: Summary: Remove dependences on value factory method; refactor ciValueKlass. Message-ID: <201612070952.uB79qwEc011396@aojmv0008.oracle.com> Changeset: 4be6e6ebc443 Author: zmajo Date: 2016-12-07 10:50 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4be6e6ebc443 Summary: Remove dependences on value factory method; refactor ciValueKlass. Reviewed-by: thartmann ! src/share/vm/ci/ciClassList.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/oops/constMethod.hpp ! src/share/vm/opto/graphKit.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 From zoltan.majo at oracle.com Thu Dec 8 08:36:59 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 8 Dec 2016 09:36:59 +0100 Subject: RFR/RFC calling convention change for value types in compiled code In-Reply-To: References: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> Message-ID: <0298aa32-299b-02da-e1e4-a09b34ecf57a@oracle.com> Hi Roland, sorry for the delay, I was caught up with other work. On 12/05/2016 02:28 PM, Roland Westrelin wrote: > Hi Zoltan, > > Thanks for the careful review. See the 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 > I think it's good: one T_VOID for the T_LONG and then 2 for each > T_VALUETYPE. Oh, I missed that on the first read (but it's obvious on a second read). Maybe you could just add a small note to the comment saying that we need two elements for the long. >> 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); > So you would change sig to sig_extended everywhere it's used? Maybe that's too much, as you would have to change all the way up to AdapterHandlerLibrary::get_adapter() So it's up to you if you want to change that. >> = 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. > I copied the comment. Thank you. > Not sure there's more to say? > sig in sharedRuntime, domain_cc and domain_sig are not the same. sig > attempts to sum up both domain_cc and domain_sig so I'm not sure what to > do about your comment about naming consistency. I see. Then sig_extended is probably a good name for sig (if you decide to change it). > >> = 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. > I can't do that for collect_value_fields() because it fills a Type* > array which is c2 only. OK, thank you for explaining. > >> = 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). > I'll take care of it in a later change. I don't think it's too > difficult but it's not straightforward either. That sounds good to me. Best regards, Zoltan > > Roland. From rwestrel at redhat.com Thu Dec 8 13:01:30 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 08 Dec 2016 14:01:30 +0100 Subject: RFR/RFC calling convention change for value types in compiled code In-Reply-To: <0298aa32-299b-02da-e1e4-a09b34ecf57a@oracle.com> References: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> <0298aa32-299b-02da-e1e4-a09b34ecf57a@oracle.com> Message-ID: Here is a new webrev that should implement all comments that I didn't respond to: http://cr.openjdk.java.net/~roland/valhalla/callingconvention/webrev.01/ (ignore arraycopynode.hpp with no change) Roland. From tobias.hartmann at oracle.com Thu Dec 8 13:08:31 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 8 Dec 2016 14:08:31 +0100 Subject: RFR/RFC calling convention change for value types in compiled code In-Reply-To: References: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> <0298aa32-299b-02da-e1e4-a09b34ecf57a@oracle.com> Message-ID: <58495B4F.7040402@oracle.com> Hi Roland, On 08.12.2016 14:01, Roland Westrelin wrote: > > Here is a new webrev that should implement all comments that I didn't > respond to: > > http://cr.openjdk.java.net/~roland/valhalla/callingconvention/webrev.01/ > > (ignore arraycopynode.hpp with no change) Zoltan recently pushed a change that removed the dependencies on the value factory method (which is not there for a DVT): http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4be6e6ebc443 I think you need to rebase your changes accordingly. Thanks, Tobias > > Roland. > From zoltan.majo at oracle.com Thu Dec 8 13:22:13 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 8 Dec 2016 14:22:13 +0100 Subject: RFR/RFC calling convention change for value types in compiled code In-Reply-To: References: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> <0298aa32-299b-02da-e1e4-a09b34ecf57a@oracle.com> Message-ID: <7cb296cb-e168-b38f-49f4-69a9d2ab7164@oracle.com> Hi Roland, On 12/08/2016 02:01 PM, Roland Westrelin wrote: > Here is a new webrev that should implement all comments that I didn't > respond to: > > http://cr.openjdk.java.net/~roland/valhalla/callingconvention/webrev.01/ > > (ignore arraycopynode.hpp with no change) that change looks good to me! Thank you! Best regards, Zoltan > > Roland. From frederic.parain at oracle.com Mon Dec 12 16:02:03 2016 From: frederic.parain at oracle.com (frederic parain) Date: Mon, 12 Dec 2016 11:02:03 -0500 Subject: RFR: : vdefault / vwithfield Message-ID: Summary: - add vdefault and vwithfield to runtime ad interpreter - some cleanup / simplification in vnew and vgetfield - some naming cleanup - fix cpCache for vgetfield and vwithfield http://jurassic.us.oracle.com/~fparain/Webrevs/mvt-bytecodes/webrev.01/ Thanks, Fred From frederic.parain at oracle.com Mon Dec 12 17:43:47 2016 From: frederic.parain at oracle.com (frederic parain) Date: Mon, 12 Dec 2016 12:43:47 -0500 Subject: RFR: : vdefault / vwithfield In-Reply-To: References: Message-ID: <8fbc5161-d11f-37ce-b1ff-10c8d4d12b2b@oracle.com> With the correct URL for the webrev: http://cr.openjdk.java.net/~fparain/mvt-bytecodes/webrev.00/ Fred On 12/12/2016 11:02, frederic parain wrote: > Summary: > - add vdefault and vwithfield to runtime ad interpreter > - some cleanup / simplification in vnew and vgetfield > - some naming cleanup > - fix cpCache for vgetfield and vwithfield > > http://jurassic.us.oracle.com/~fparain/Webrevs/mvt-bytecodes/webrev.01/ > > Thanks, > > Fred From maurizio.cimadamore at oracle.com Mon Dec 12 17:55:12 2016 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 12 Dec 2016 17:55:12 +0000 Subject: hg: valhalla/valhalla/jdk: Enhancement: add support for 'typed' bytecode prefix to bytecode API Message-ID: <201612121755.uBCHtCOL026808@aojmv0008.oracle.com> Changeset: 6d7136544168 Author: mcimadamore Date: 2016-12-12 17:47 +0000 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6d7136544168 Enhancement: add support for 'typed' bytecode prefix to bytecode API ! src/java.base/share/classes/jdk/experimental/bytecode/AttributeBuilder.java ! src/java.base/share/classes/jdk/experimental/bytecode/BasicClassBuilder.java ! src/java.base/share/classes/jdk/experimental/bytecode/ClassBuilder.java ! src/java.base/share/classes/jdk/experimental/bytecode/CodeBuilder.java ! src/java.base/share/classes/jdk/experimental/bytecode/FieldBuilder.java ! src/java.base/share/classes/jdk/experimental/bytecode/GrowableByteBuffer.java ! src/java.base/share/classes/jdk/experimental/bytecode/MacroCodeBuilder.java ! src/java.base/share/classes/jdk/experimental/bytecode/MemberBuilder.java ! src/java.base/share/classes/jdk/experimental/bytecode/MethodBuilder.java ! src/java.base/share/classes/jdk/experimental/bytecode/Opcode.java ! src/java.base/share/classes/jdk/experimental/bytecode/PoolHelper.java ! src/java.base/share/classes/jdk/experimental/bytecode/TypedCodeBuilder.java ! src/java.base/share/classes/jdk/experimental/value/MethodHandleBuilder.java From frederic.parain at oracle.com Mon Dec 12 17:58:29 2016 From: frederic.parain at oracle.com (frederic parain) Date: Mon, 12 Dec 2016 12:58:29 -0500 Subject: RFR: typed bytecodes - first push Message-ID: <1b29f028-38f1-7813-90ea-7532f8411128@oracle.com> Here's what the typed bytecodes look like today: http://cr.openjdk.java.net/~fparain/typed-bytecodes/webrev.00/ Summary: - the framework to declare and implement typed bytecodes is in place - typed bytecodes can be implemented either by aliasing an existing bytecode or by providing a template to generate the interpreter Codelet (re-using existing templates is possible) - the 'typed' opcode currently takes an UTF8 argument (will be changed in the future) - the two arguments currently recognized by the 'typed' opcode are 'I' and 'F', respectively for int and float - the list of bytecodes supporting the 'typed' prefix is: aload, aload_0, aload_1, aload_2, aload_3, astore, astore_0, astore_1, astore_2, astore_3, aaload, aastore, areturn, anewarray, aconst_null - the unit tests are using the bytecodes API Limitations: - no JIT support The last missing part is the comparison opcodes, if_acmp. The problem is the non-orthogonality of comparisons opcodes between references, integers values and floating point values. Maurizio has a patch ready to generate typed if_acmp sequences, the support in the JVM should be added soon. Thanks, Fred From karen.kinnear at oracle.com Mon Dec 12 22:06:08 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 12 Dec 2016 17:06:08 -0500 Subject: RFR: : vdefault / vwithfield In-Reply-To: <8fbc5161-d11f-37ce-b1ff-10c8d4d12b2b@oracle.com> References: <8fbc5161-d11f-37ce-b1ff-10c8d4d12b2b@oracle.com> Message-ID: Frederic, Code looks good. Thank you for the tests. Go ahead and push. We should clarify that, like all the other ?v? byte codes, these are temporary for experimental purposes, with no assumptions as the byte codes that will ultimately be used for value types. Still works with -Xint, -Xverify:none, linux-x64 only. Initial prototype, no performance work yet. thanks, Karen > On Dec 12, 2016, at 12:43 PM, frederic parain wrote: > > With the correct URL for the webrev: > > http://cr.openjdk.java.net/~fparain/mvt-bytecodes/webrev.00/ > > Fred > > On 12/12/2016 11:02, frederic parain wrote: >> Summary: >> - add vdefault and vwithfield to runtime ad interpreter >> - some cleanup / simplification in vnew and vgetfield >> - some naming cleanup >> - fix cpCache for vgetfield and vwithfield >> >> http://jurassic.us.oracle.com/~fparain/Webrevs/mvt-bytecodes/webrev.01/ >> >> Thanks, >> >> Fred From rwestrel at redhat.com Tue Dec 13 08:44:49 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 13 Dec 2016 09:44:49 +0100 Subject: RFR/RFC calling convention change for value types in compiled code In-Reply-To: <58495B4F.7040402@oracle.com> References: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> <0298aa32-299b-02da-e1e4-a09b34ecf57a@oracle.com> <58495B4F.7040402@oracle.com> Message-ID: Hi Tobias, > Zoltan recently pushed a change that removed the dependencies on the value factory method (which is not there for a DVT): > http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4be6e6ebc443 > > I think you need to rebase your changes accordingly. Here it is rebased: http://cr.openjdk.java.net/~roland/valhalla/callingconvention/webrev.02/ I also had to make the fix below to collect all value type fields at a safepoint. Roland. diff --git a/src/share/vm/opto/valuetypenode.cpp b/src/share/vm/opto/valuetypenode.cpp --- a/src/share/vm/opto/valuetypenode.cpp +++ b/src/share/vm/opto/valuetypenode.cpp @@ -298,7 +298,7 @@ void ValueTypeNode::make_scalar_in_safepoints(Compile* C) { const TypeValueTypePtr* res_type = TypeValueTypePtr::make(bottom_type()->isa_valuetype(), TypePtr::NotNull); ciValueKlass* vk = value_klass(); - uint nfields = vk->field_count(); + uint nfields = vk->flattened_field_count(); for (DUIterator_Fast imax, i = fast_outs(imax); i < imax; i++) { Node* u = fast_out(i); if (u->is_SafePoint() && (!u->is_Call() || u->as_Call()->has_debug_use(this))) { From rwestrel at redhat.com Tue Dec 13 08:45:30 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 13 Dec 2016 09:45:30 +0100 Subject: RFR/RFC calling convention change for value types in compiled code In-Reply-To: <7cb296cb-e168-b38f-49f4-69a9d2ab7164@oracle.com> References: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> <0298aa32-299b-02da-e1e4-a09b34ecf57a@oracle.com> <7cb296cb-e168-b38f-49f4-69a9d2ab7164@oracle.com> Message-ID: > that change looks good to me! Thank you! Thanks! Roland. From tobias.hartmann at oracle.com Tue Dec 13 08:54:48 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 13 Dec 2016 09:54:48 +0100 Subject: RFR/RFC calling convention change for value types in compiled code In-Reply-To: References: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> <0298aa32-299b-02da-e1e4-a09b34ecf57a@oracle.com> <58495B4F.7040402@oracle.com> Message-ID: <584FB758.3070709@oracle.com> Hi Roland, On 13.12.2016 09:44, Roland Westrelin wrote: > Here it is rebased: > > http://cr.openjdk.java.net/~roland/valhalla/callingconvention/webrev.02/ Looks good to me! > I also had to make the fix below to collect all value type fields at > a safepoint. Good catch, I think I screwed that up when removing the double-loop. Thanks, Tobias > Roland. > > diff --git a/src/share/vm/opto/valuetypenode.cpp b/src/share/vm/opto/valuetypenode.cpp > --- a/src/share/vm/opto/valuetypenode.cpp > +++ b/src/share/vm/opto/valuetypenode.cpp > @@ -298,7 +298,7 @@ > void ValueTypeNode::make_scalar_in_safepoints(Compile* C) { > const TypeValueTypePtr* res_type = TypeValueTypePtr::make(bottom_type()->isa_valuetype(), TypePtr::NotNull); > ciValueKlass* vk = value_klass(); > - uint nfields = vk->field_count(); > + uint nfields = vk->flattened_field_count(); > for (DUIterator_Fast imax, i = fast_outs(imax); i < imax; i++) { > Node* u = fast_out(i); > if (u->is_SafePoint() && (!u->is_Call() || u->as_Call()->has_debug_use(this))) { > From rwestrel at redhat.com Tue Dec 13 09:13:44 2016 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Tue, 13 Dec 2016 09:13:44 +0000 Subject: hg: valhalla/valhalla/hotspot: value type calling convention Message-ID: <201612130913.uBD9Di5C005715@aojmv0008.oracle.com> Changeset: 6b6d84008c49 Author: roland Date: 2016-12-13 09:35 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6b6d84008c49 value type calling convention ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/ci/ciValueKlass.cpp ! src/share/vm/ci/ciValueKlass.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macroArrayCopy.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/opto/valuetypenode.cpp ! src/share/vm/opto/valuetypenode.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From rwestrel at redhat.com Tue Dec 13 09:38:22 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 13 Dec 2016 10:38:22 +0100 Subject: RFR/RFC calling convention change for value types in compiled code In-Reply-To: <584FB758.3070709@oracle.com> References: <3591f66c-733e-5922-59e7-01135c92ad08@oracle.com> <0298aa32-299b-02da-e1e4-a09b34ecf57a@oracle.com> <58495B4F.7040402@oracle.com> <584FB758.3070709@oracle.com> Message-ID: Thanks for looking at this again. I pushed it. Roland. From rwestrel at redhat.com Tue Dec 13 15:59:23 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 13 Dec 2016 16:59:23 +0100 Subject: C2: fixes for incremental inlining Message-ID: <44b2f33d-95b5-b9be-02f6-93c3e63e0faa@redhat.com> http://cr.openjdk.java.net/~roland/valhalla/incrementalinlining/webrev.00/ This fixes incremental inlining (which is currently broken with both ValueTypePassFieldsAsArgs on and off). Roland. From rwestrel at redhat.com Tue Dec 13 16:35:49 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 13 Dec 2016 17:35:49 +0100 Subject: C2: No need to allocate value types for uncommon trap's debug info Message-ID: A straightforward clean up: http://cr.openjdk.java.net/~roland/valhalla/noallocatunc/webrev.00/ Roland. From frederic.parain at oracle.com Tue Dec 13 16:41:58 2016 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Tue, 13 Dec 2016 16:41:58 +0000 Subject: hg: valhalla/valhalla/hotspot: Add vdefault and vwithfield to the interpreter Message-ID: <201612131641.uBDGfwW6013175@aojmv0008.oracle.com> Changeset: 195fc7694ff7 Author: fparain Date: 2016-12-13 11:42 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/195fc7694ff7 Add vdefault and vwithfield to the interpreter some cleanup / simplification in vnew and vgetfield some naming cleanup fix cpCache for vgetfield and vwithfield ! src/cpu/x86/vm/templateTable_x86.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/cpCache.hpp + test/runtime/valhalla/valuetypes/VDefaultTest.java + test/runtime/valhalla/valuetypes/VWithFieldTest.java From tobias.hartmann at oracle.com Tue Dec 13 18:04:38 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 13 Dec 2016 19:04:38 +0100 Subject: C2: No need to allocate value types for uncommon trap's debug info In-Reply-To: References: Message-ID: <58503836.3090009@oracle.com> Hi Roland, On 13.12.2016 17:35, Roland Westrelin wrote: > > A straightforward clean up: > > http://cr.openjdk.java.net/~roland/valhalla/noallocatunc/webrev.00/ Why is that code not needed anymore? Best regards, Tobias From rwestrel at redhat.com Wed Dec 14 08:13:27 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 14 Dec 2016 09:13:27 +0100 Subject: C2: No need to allocate value types for uncommon trap's debug info In-Reply-To: <58503836.3090009@oracle.com> References: <58503836.3090009@oracle.com> Message-ID: Hi Tobias, >> http://cr.openjdk.java.net/~roland/valhalla/noallocatunc/webrev.00/ > > Why is that code not needed anymore? case Op_ValueType: { ValueTypeNode* vt = n->as_ValueType(); vt->make_scalar_in_safepoints(this); if (vt->outcnt() == 0) { vt->disconnect_inputs(NULL, this); } break; } in Compile::final_graph_reshaping() should change the debug info of the uncommon traps so it doesn't include any value types or am I missing something? Roland. From tobias.hartmann at oracle.com Wed Dec 14 08:37:48 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 14 Dec 2016 09:37:48 +0100 Subject: C2: No need to allocate value types for uncommon trap's debug info In-Reply-To: References: <58503836.3090009@oracle.com> Message-ID: <585104DC.7020700@oracle.com> Hi Roland, On 14.12.2016 09:13, Roland Westrelin wrote: > > Hi Tobias, > >>> http://cr.openjdk.java.net/~roland/valhalla/noallocatunc/webrev.00/ >> >> Why is that code not needed anymore? > > case Op_ValueType: { > ValueTypeNode* vt = n->as_ValueType(); > vt->make_scalar_in_safepoints(this); > if (vt->outcnt() == 0) { > vt->disconnect_inputs(NULL, this); > } > break; > } > > in Compile::final_graph_reshaping() should change the debug info of the > uncommon traps so it doesn't include any value types or am I missing > something? Right, I thought this was still required because you mentioned this in the RFR for your SafePointNodes change [1]. But with flattened value type support, this is not longer needed. Looks good! Thanks, Tobias [1] http://mail.openjdk.java.net/pipermail/valhalla-dev/2016-November/002063.html From tobias.hartmann at oracle.com Wed Dec 14 08:46:05 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 14 Dec 2016 09:46:05 +0100 Subject: C2: fixes for incremental inlining In-Reply-To: <44b2f33d-95b5-b9be-02f6-93c3e63e0faa@redhat.com> References: <44b2f33d-95b5-b9be-02f6-93c3e63e0faa@redhat.com> Message-ID: <585106CD.4000207@oracle.com> Hi Roland, On 13.12.2016 16:59, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/valhalla/incrementalinlining/webrev.00/ > > This fixes incremental inlining (which is currently broken with both > ValueTypePassFieldsAsArgs on and off). Looks good to me! Please add a comment in line 1323 of compile.hpp before pushing. Best regards, Tobias From rwestrel at redhat.com Wed Dec 14 09:04:04 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 14 Dec 2016 10:04:04 +0100 Subject: C2: No need to allocate value types for uncommon trap's debug info In-Reply-To: <585104DC.7020700@oracle.com> References: <58503836.3090009@oracle.com> <585104DC.7020700@oracle.com> Message-ID: > Looks good! Thanks. Roland. From rwestrel at redhat.com Wed Dec 14 09:04:16 2016 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Wed, 14 Dec 2016 09:04:16 +0000 Subject: hg: valhalla/valhalla/hotspot: No need to allocate value types for uncommon trap's debug info Message-ID: <201612140904.uBE94G37020767@aojmv0008.oracle.com> Changeset: 9ec58fe4fdc0 Author: roland Date: 2016-12-13 17:32 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9ec58fe4fdc0 No need to allocate value types for uncommon trap's debug info ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse1.cpp From rwestrel at redhat.com Wed Dec 14 09:08:17 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 14 Dec 2016 10:08:17 +0100 Subject: C2: fixes for incremental inlining In-Reply-To: <585106CD.4000207@oracle.com> References: <44b2f33d-95b5-b9be-02f6-93c3e63e0faa@redhat.com> <585106CD.4000207@oracle.com> Message-ID: > Looks good to me! Please add a comment in line 1323 of compile.hpp > before pushing. Ok. Thanks. Roland. From rwestrel at redhat.com Wed Dec 14 09:19:03 2016 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Wed, 14 Dec 2016 09:19:03 +0000 Subject: hg: valhalla/valhalla/hotspot: fix incremental inlining with value types Message-ID: <201612140919.uBE9J3TR024700@aojmv0008.oracle.com> Changeset: 43edc51d06e7 Author: roland Date: 2016-12-14 10:06 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/43edc51d06e7 fix incremental inlining with value types ! src/share/vm/ci/ciValueKlass.cpp ! src/share/vm/ci/ciValueKlass.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/type.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From david.simms at oracle.com Wed Dec 14 12:41:08 2016 From: david.simms at oracle.com (David Simms) Date: Wed, 14 Dec 2016 13:41:08 +0100 Subject: RFR: remove vnewarray & multivnewarray Message-ID: <384c71c6-4d57-79c5-4c82-582a1050f5c4@oracle.com> Webrev: http://cr.openjdk.java.net/~dsimms/valhalla/remove_vnewarray/ Summary: * remove "vnewarray" and "multivnewarray" bytecodes, just use anewarray and multianewarray for now * Improved tests and minor fixes for array and multi-dimensional arrays of values Cheers /David Simms From maurizio.cimadamore at oracle.com Wed Dec 14 13:36:07 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 14 Dec 2016 13:36:07 +0000 Subject: RFR: remove vnewarray & multivnewarray In-Reply-To: <384c71c6-4d57-79c5-4c82-582a1050f5c4@oracle.com> References: <384c71c6-4d57-79c5-4c82-582a1050f5c4@oracle.com> Message-ID: <12d9500a-8c08-f5e9-2e0f-a59b23e61c53@oracle.com> The langtools/JDK part of it look good. It is likely that some langtools test will start to fail, but Srikanth and I can follow up on that on a separate patch. Maurizio On 14/12/16 12:41, David Simms wrote: > > Webrev: http://cr.openjdk.java.net/~dsimms/valhalla/remove_vnewarray/ > > > Summary: > > * remove "vnewarray" and "multivnewarray" bytecodes, just use > anewarray and multianewarray for now > * Improved tests and minor fixes for array and multi-dimensional > arrays of values > > Cheers > > /David Simms > > > From david.simms at oracle.com Thu Dec 15 11:24:38 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 15 Dec 2016 11:24:38 +0000 Subject: hg: valhalla/valhalla/hotspot: Remove vnewarray + multivnewarray, add more tests and fixes Message-ID: <201612151124.uBFBOccR022942@aojmv0008.oracle.com> Changeset: 334e4da33a0f Author: dsimms Date: 2016-12-15 12:23 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/334e4da33a0f Remove vnewarray + multivnewarray, add more tests and fixes ! src/cpu/x86/vm/templateTable_x86.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/runtime/reflection.cpp ! test/runtime/valhalla/valuetypes/ValueTypeArray.java ! test/runtime/valhalla/valuetypes/VboxUnbox.java From david.simms at oracle.com Thu Dec 15 11:24:53 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 15 Dec 2016 11:24:53 +0000 Subject: hg: valhalla/valhalla/jdk: Remove vnewarray + multivnewarray, add more tests and fixes Message-ID: <201612151124.uBFBOrEO023077@aojmv0008.oracle.com> Changeset: 88a6e49ec676 Author: dsimms Date: 2016-12-15 12:23 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/88a6e49ec676 Remove vnewarray + multivnewarray, add more tests and fixes ! src/java.base/share/classes/jdk/experimental/bytecode/CodeBuilder.java ! src/java.base/share/classes/jdk/experimental/bytecode/Opcode.java ! src/java.base/share/classes/jdk/experimental/bytecode/TypedCodeBuilder.java ! src/java.base/share/classes/jdk/experimental/value/ValueType.java ! src/java.base/share/classes/valhalla/model3/classfile/Opcode.java ! test/TEST.groups ! test/valhalla/mvt/MVTTest.java From david.simms at oracle.com Thu Dec 15 11:24:59 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 15 Dec 2016 11:24:59 +0000 Subject: hg: valhalla/valhalla/langtools: Remove vnewarray + multivnewarray, add more tests and fixes Message-ID: <201612151124.uBFBOxTv023118@aojmv0008.oracle.com> Changeset: 85cc92a65da8 Author: dsimms Date: 2016-12-15 12:23 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/85cc92a65da8 Remove vnewarray + multivnewarray, add more tests and fixes ! 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.jdeps/share/classes/com/sun/tools/classfile/Opcode.java From zoltan.majo at oracle.com Tue Dec 20 14:33:21 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 20 Dec 2016 15:33:21 +0100 Subject: RFR/RFC: C2: limited support for vbox/vunbox Message-ID: <9100403a-e0bd-fba1-dc52-310a983d8a9a@oracle.com> Hi, this patch adds basic C2 support for the vbox/vunbox bytecodes. http://cr.openjdk.java.net/~zmajo/valhalla/02.vbox-vunbox.webrev.00/ The suggested change is in a prototype phase, thus it works for only a limited set of use cases (covered by tests 37--40). In more detail, the patch - does not enable C2 to generate checks currently performed by the interpreter to verify that the bytecodes handle a value-capable class and it's corresponding derived value type; - relies on the assumption that the memory layout of the derived value type is the same as the memory layout of the value-capable class. The patch also contains a minor refactoring of method names in ValueTypeNode so that the names better match with the HotSpot Style Guide. I tested with ValueTypeTestBench.java and with the Octane+Nashorn benchmarks. Thank you! Best regards, Zoltan From gunnar at hibernate.org Fri Dec 23 08:08:20 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 23 Dec 2016 09:08:20 +0100 Subject: Proposal: Add a type token class for representing generic types Message-ID: Hi, I've sent this proposal to core-libs-dev recently and it has been suggested that it may fall into the scope of project Valhalla, hence I'm proposing it here, too. Any feedback would be very welcome. Thanks, --Gunnar ===== I'd like to suggest the addition of a type token class to the Java class library, to be used for representing generic types such as List. Actual class literals can only represent raw types. But often libraries have the need to apply some sort of configuration to specific generic types, link specific behaviour to them or expose (meta) data related to them. The suggested type token class would allow to implement such cases in a type-safe fashion. # Example use cases * The "type-safe heterogenous container" pattern from Joshua Bloch's book "Effective Java" introduces a container which allows to safely store and retrieve objects of different types. They are keyed by Class, which means that one cannot have a value for a List and another value for a List in such container. Also one cannot obtain a List without casting from such container. Type literals would allow this: void put(TypeLiteral type, T value); T get(TypeLiteral type); TypeLiteral> stringListType = ...; List stringList = container.get( stringListType ); * JAX-RS allows to read response message entities into parameterized types using its GenericType class: List customers = response.readEntity( new GenericType>() {} ); * CDI allows to dynamically obtain beans of specific parameterized types using its TypeLiteral class: @Inject @Any Instance anyPaymentProcessor; public PaymentProcessor getChequePaymentProcessor() { PaymentProcessor pp = anyPaymentProcessor .select( new TypeLiteral>() {} ).get(); } # Proposed solution Type literals would be represented by a new type java.lang.reflect.TypeLiteral. Instances would be created via sub-classing, capturing the parameter and baking it into the sub-class: TypeLiteral> stringListType = new TypeLiteral>(){}; That'd allow to provide type-safe APIs around generic types as shown in the examples above. The following methods should be defined on TypeLiteral in order to make it useful for implementers of such APIs: Type getType(); Class getRawType(); boolean equals(Object obj); int hashCode(); String toString(); # Prior art The idea of type tokens based on capturing a generic type in a sub-class has been around for a long time. The first reference I've found is Neal Gafter's blog post on "Super Type Tokens" from 2006 [1]. Examples in real-world APIs and libraries are TypeLiteral in CDI [2], GenericType in JAX-RS [3], TypeLiteral in commons-lang [4] and TypeToken in Guava [5]. # Alternatives and shortcomings The obvious alternative would be reified generics, but I think it's commonly agreed upon that these will not come to the Java language any time soon. Without native support in the language itself the proposed type literal class is the best way to support the mentioned use cases as far as I can say. Shortcomings are the creation of a sub-class per literal instantiation (probably more an aesthetic problem, though) and failure of the pattern when type variables are included anywhere in the represented type [6]. Unfortunately, this can only be detected at runtime when instantiating a literal but not by the compiler (although, I reckon it technically could, by handling this case specifically). # Conclusion Lacking reified generics, the Java platform would benefit from the addition of new type token class java.lang.reflect.TypeLiteral. The pattern's presence in common APIs and libraries shows that there is a wide-spread need for such mechanism and the community would benefit very much from a standardized solution in the JDK itself. This will allow for more unified API designs as well as foster integration of different libraries. I'm eager to learn about your feedback and the OpenJDK team's assessment of this proposal. --Gunnar [1] http://gafter.blogspot.de/2006/12/super-type-tokens.html [2] https://docs.oracle.com/javaee/7/api/index.html?javax/enterprise/util/TypeLiteral.html [3] https://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/core/GenericType.html [4] https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/reflect/TypeLiteral.html [5] https://google.github.io/guava/releases/20.0/api/docs/index.html?com/google/common/reflect/TypeToken.html [6] http://gafter.blogspot.de/2007/05/limitation-of-super-type-tokens.html From gunnar at hibernate.org Thu Dec 22 14:05:31 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 22 Dec 2016 14:05:31 -0000 Subject: Proposal: Add a type token class for representing generic types Message-ID: Hi, I've sent this proposal to core-libs-dev recently and it has been suggested that it may fall into the scope of project Valhalla, hence I'm proposing it here, too. Any feedback would be very welcome. Thanks, --Gunnar ===== I'd like to suggest the addition of a type token class to the Java class library, to be used for representing generic types such as List. Actual class literals can only represent raw types. But often libraries have the need to apply some sort of configuration to specific generic types, link specific behaviour to them or expose (meta) data related to them. The suggested type token class would allow to implement such cases in a type-safe fashion. # Example use cases * The "type-safe heterogenous container" pattern from Joshua Bloch's book "Effective Java" introduces a container which allows to safely store and retrieve objects of different types. They are keyed by Class, which means that one cannot have a value for a List and another value for a List in such container. Also one cannot obtain a List without casting from such container. Type literals would allow this: void put(TypeLiteral type, T value); T get(TypeLiteral type); TypeLiteral> stringListType = ...; List stringList = container.get( stringListType ); * JAX-RS allows to read response message entities into parameterized types using its GenericType class: List customers = response.readEntity( new GenericType>() {} ); * CDI allows to dynamically obtain beans of specific parameterized types using its TypeLiteral class: @Inject @Any Instance anyPaymentProcessor; public PaymentProcessor getChequePaymentProcessor() { PaymentProcessor pp = anyPaymentProcessor .select( new TypeLiteral>() {} ).get(); } # Proposed solution Type literals would be represented by a new type java.lang.reflect.TypeLiteral. Instances would be created via sub-classing, capturing the parameter and baking it into the sub-class: TypeLiteral> stringListType = new TypeLiteral>(){}; That'd allow to provide type-safe APIs around generic types as shown in the examples above. The following methods should be defined on TypeLiteral in order to make it useful for implementers of such APIs: Type getType(); Class getRawType(); boolean equals(Object obj); int hashCode(); String toString(); # Prior art The idea of type tokens based on capturing a generic type in a sub-class has been around for a long time. The first reference I've found is Neal Gafter's blog post on "Super Type Tokens" from 2006 [1]. Examples in real-world APIs and libraries are TypeLiteral in CDI [2], GenericType in JAX-RS [3], TypeLiteral in commons-lang [4] and TypeToken in Guava [5]. # Alternatives and shortcomings The obvious alternative would be reified generics, but I think it's commonly agreed upon that these will not come to the Java language any time soon. Without native support in the language itself the proposed type literal class is the best way to support the mentioned use cases as far as I can say. Shortcomings are the creation of a sub-class per literal instantiation (probably more an aesthetic problem, though) and failure of the pattern when type variables are included anywhere in the represented type [6]. Unfortunately, this can only be detected at runtime when instantiating a literal but not by the compiler (although, I reckon it technically could, by handling this case specifically). # Conclusion Lacking reified generics, the Java platform would benefit from the addition of new type token class java.lang.reflect.TypeLiteral. The pattern's presence in common APIs and libraries shows that there is a wide-spread need for such mechanism and the community would benefit very much from a standardized solution in the JDK itself. This will allow for more unified API designs as well as foster integration of different libraries. I'm eager to learn about your feedback and the OpenJDK team's assessment of this proposal. --Gunnar [1] http://gafter.blogspot.de/2006/12/super-type-tokens.html [2] https://docs.oracle.com/javaee/7/api/index.html?javax/enterprise/util/TypeLiteral.html [3] https://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/core/GenericType.html [4] https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/reflect/TypeLiteral.html [5] https://google.github.io/guava/releases/20.0/api/docs/index.html?com/google/common/reflect/TypeToken.html [6] http://gafter.blogspot.de/2007/05/limitation-of-super-type-tokens.html