From tobias.hartmann at oracle.com Tue Jan 3 08:35:16 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 3 Jan 2017 09:35:16 +0100 Subject: RFR/RFC: C2: limited support for vbox/vunbox In-Reply-To: <9100403a-e0bd-fba1-dc52-310a983d8a9a@oracle.com> References: <9100403a-e0bd-fba1-dc52-310a983d8a9a@oracle.com> Message-ID: <586B6244.9030802@oracle.com> Hi Zoltan, your changes look good to me! Here are some minor suggestions (you don't need to send another webrev): - in line 150 of ValueTypeTestBench.java you could use rI and rL to randomize the argument values - ValueCapableClass1::hash() is not used - ValueCapableClass1.java is missing the copyright header Best regards, Tobias On 20.12.2016 15:33, Zolt?n Maj? wrote: > 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 rwestrel at redhat.com Tue Jan 3 10:29:17 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 3 Jan 2017 11:29:17 +0100 Subject: C2: fix zeroing elimination with heap allocated value types Message-ID: <76052ff7-4399-9996-7876-24e1c8033265@redhat.com> Tobias noticed zeroing elimination doesn't trigger when value types are heap allocated. http://cr.openjdk.java.net/~roland/valhalla/zeroingelim/webrev.00/ With this change initialization stores are captured by the allocation and some of them show up as raw memory stores: that's why test9 had to be tweaked. Roland. From tobias.hartmann at oracle.com Tue Jan 3 11:43:03 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 3 Jan 2017 12:43:03 +0100 Subject: C2: fix zeroing elimination with heap allocated value types In-Reply-To: <76052ff7-4399-9996-7876-24e1c8033265@redhat.com> References: <76052ff7-4399-9996-7876-24e1c8033265@redhat.com> Message-ID: <586B8E47.2090703@oracle.com> Hi Roland, On 03.01.2017 11:29, Roland Westrelin wrote: > Tobias noticed zeroing elimination doesn't trigger when value types are > heap allocated. > > http://cr.openjdk.java.net/~roland/valhalla/zeroingelim/webrev.00/ > > With this change initialization stores are captured by the allocation > and some of them show up as raw memory stores: that's why test9 had to > be tweaked. This looks good to me! Do we still need the call to set_complete_with_arraycopy() in ValueTypeNode::store_to_memory() that I tried to add in my value type array prototype [1]? Thanks, Tobias [1] http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.05/src/share/vm/opto/valuetypenode.cpp.sdiff.html > > Roland. > From rwestrel at redhat.com Tue Jan 3 13:03:33 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 03 Jan 2017 14:03:33 +0100 Subject: C2: fix zeroing elimination with heap allocated value types In-Reply-To: <586B8E47.2090703@oracle.com> References: <76052ff7-4399-9996-7876-24e1c8033265@redhat.com> <586B8E47.2090703@oracle.com> Message-ID: Hi Tobias, Thanks for looking at this. > This looks good to me! Do we still need the call to > set_complete_with_arraycopy() in ValueTypeNode::store_to_memory() that > I tried to add in my value type array prototype [1]? I don't know. I haven't checked yet. Roland. From rwestrel at redhat.com Tue Jan 3 13:18:05 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Tue, 03 Jan 2017 13:18:05 +0000 Subject: hg: valhalla/valhalla/hotspot: zeroing elimination fix Message-ID: <201701031318.v03DI53x012862@aojmv0008.oracle.com> Changeset: da509a6c140c Author: roland Date: 2017-01-03 11:19 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/da509a6c140c zeroing elimination fix ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/type.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From zoltan.majo at oracle.com Tue Jan 3 13:36:58 2017 From: zoltan.majo at oracle.com (zoltan.majo at oracle.com) Date: Tue, 03 Jan 2017 13:36:58 +0000 Subject: hg: valhalla/valhalla/hotspot: Summary: Basic C2 support for the vbox/vunbox bytecodes. No type checks, assumes memory layout of VCC and DVT to be the same. Message-ID: <201701031336.v03Daw94022507@aojmv0008.oracle.com> Changeset: a6700e1bf14f Author: zmajo Date: 2017-01-03 14:36 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/a6700e1bf14f Summary: Basic C2 support for the vbox/vunbox bytecodes. No type checks, assumes memory layout of VCC and DVT to be the same. Reviewed-by: thartmann ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/valuetypenode.cpp ! src/share/vm/opto/valuetypenode.hpp + test/compiler/valhalla/valuetypes/ValueCapableClass1.java ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From zoltan.majo at oracle.com Tue Jan 3 13:38:20 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 3 Jan 2017 14:38:20 +0100 Subject: RFR/RFC: C2: limited support for vbox/vunbox In-Reply-To: <586B6244.9030802@oracle.com> References: <9100403a-e0bd-fba1-dc52-310a983d8a9a@oracle.com> <586B6244.9030802@oracle.com> Message-ID: Hi Tobias, On 01/03/2017 09:35 AM, Tobias Hartmann wrote: > Hi Zoltan, > > your changes look good to me! > > Here are some minor suggestions (you don't need to send another webrev): > - in line 150 of ValueTypeTestBench.java you could use rI and rL to randomize the argument values > - ValueCapableClass1::hash() is not used > - ValueCapableClass1.java is missing the copyright header thank you for the review! I fixed the problems you pointed out and pushed the changeset. Best regards, Zoltan > > Best regards, > Tobias > > On 20.12.2016 15:33, Zolt?n Maj? wrote: >> 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 brian.goetz at oracle.com Wed Jan 4 22:17:51 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 4 Jan 2017 17:17:51 -0500 Subject: Proposal: Add a type token class for representing generic types In-Reply-To: References: Message-ID: One of the known defects of this approach, as implemented in various places, is that while it increases the range of Java language types that can be expressed via reflective tokens, it still falls short of describing all the types that occur in real programs. For example, it does not support variance. Suppose I want to do this, in your type-safe hetergeneous container example: container.put(aListOfInts, (type literal for List)); List numList = container.get( (type literal for List) ); Now, you could claim that this is too esoteric an example, but if the goal is patching the inadequacies of an existing facility... And one could pull on this thread further -- such as intersection types. Pulling on this thread means building in subtyping too, not just "do I describe the same type." Which isn't trivial. Now, this isn't a slam-dunk indictment, but its a concern. That said, Valhalla will need something to describe at least the portion of parameterized types that are reified, such as ArrayList. And type tokens for value types too. Whether this is lumped in with Class, or whether it is a new thing, is still under exploration. Some revamp of reflection will certainly be in order after Valhalla -- so probably best to wait and see how that settles out. On 12/23/2016 3:08 AM, Gunnar Morling wrote: > 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 rwestrel at redhat.com Fri Jan 6 13:38:31 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 06 Jan 2017 14:38:31 +0100 Subject: RFR: : vdefault / vwithfield In-Reply-To: References: Message-ID: Hi Fred, > 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 That change doesn't seem to include support for value type fields (a field of a value type that is itself a value type). # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/rwestrel/valhalla/hotspot/src/share/vm/interpreter/interpreterRuntime.cpp:203), pid=23476, tid=23477 # fatal error: Should not be handled with this method Is this a known limitation or an oversight? Roland. From frederic.parain at oracle.com Fri Jan 6 14:21:34 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 6 Jan 2017 09:21:34 -0500 Subject: RFR: : vdefault / vwithfield In-Reply-To: References: Message-ID: <0278a7c4-a43b-9b84-9434-00beaffc19b1@oracle.com> Hi Roland, Indeed, I forgot this case, I'll fix ASAP. Thanks, Fred On 01/06/2017 08:38 AM, Roland Westrelin wrote: > > Hi Fred, > >> 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 > > That change doesn't seem to include support for value type fields (a > field of a value type that is itself a value type). > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/rwestrel/valhalla/hotspot/src/share/vm/interpreter/interpreterRuntime.cpp:203), pid=23476, tid=23477 > # fatal error: Should not be handled with this method > > Is this a known limitation or an oversight? > > Roland. > From tobias.hartmann at oracle.com Mon Jan 9 14:17:07 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 9 Jan 2017 15:17:07 +0100 Subject: C2 support for value type arrays Message-ID: <58739B63.9000202@oracle.com> Hi, please review the following change which adds C2 support for value type arrays: http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.05/ This is a prototype implementation that still lacks some functionality and contains known problems (see below). I would still like to push this to allow others (e.g., Roland) to continue for as long as I'm busy with JDK 9 bugs. Here's the TODO list: - Re-enable "hsize is pre-rounded" assert in graphKit.cpp (currently fails) - Re-enable "no mismatched stores" assert in memnode.cpp (currently fails) - Enable and fix VT array part of deopt test (test20) with flattening - Enable and fix VT array part of OSR test (test23) with flattening - Add match rules to test45 - Enable set_complete_with_arraycopy() in ValueTypeNode::store_to_memory(), this currently breaks test21 - Add range checks to value type array accesses - Improve escape analysis with value type arrays. For example, there should be no allocation for test46 - I had to change the match rules of test9 because only 3 stores were found with my changes. We need to fix this. - Add support for multi-dimensional value type arrays (multivnewarray) The implementation includes the alias analysis quick-fix that Roland found when looking at an earlier prototype (thanks again!). The ValueTypeTestBench passes. I've also run some non-VT tests for sanity. Thanks, Tobias From rwestrel at redhat.com Mon Jan 9 14:22:42 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 9 Jan 2017 15:22:42 +0100 Subject: C2 support for value type arrays In-Reply-To: <58739B63.9000202@oracle.com> References: <58739B63.9000202@oracle.com> Message-ID: <1e7d7718-c265-27ca-33b5-3e2fe7b0ffc3@redhat.com> > please review the following change which adds C2 support for value type arrays: > http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.05/ It looks good to me. Thanks! Roland. From tobias.hartmann at oracle.com Mon Jan 9 14:37:29 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 09 Jan 2017 14:37:29 +0000 Subject: hg: valhalla/valhalla/hotspot: C2 support for value type arrays Message-ID: <201701091437.v09EbTOo005648@aojmv0008.oracle.com> Changeset: dd87a3e342a7 Author: thartmann Date: 2017-01-09 15:36 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/dd87a3e342a7 C2 support for value type arrays ! src/share/vm/ci/ciArrayKlass.cpp ! src/share/vm/ci/ciArrayKlass.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMetadata.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp + src/share/vm/ci/ciValueArrayKlass.cpp + src/share/vm/ci/ciValueArrayKlass.hpp ! src/share/vm/ci/ciValueKlass.cpp ! src/share/vm/ci/ciValueKlass.hpp ! src/share/vm/ci/compilerInterface.hpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/valuetypenode.cpp ! src/share/vm/opto/valuetypenode.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/runtime/deoptimization.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From tobias.hartmann at oracle.com Mon Jan 9 14:38:24 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 9 Jan 2017 15:38:24 +0100 Subject: C2 support for value type arrays In-Reply-To: <1e7d7718-c265-27ca-33b5-3e2fe7b0ffc3@redhat.com> References: <58739B63.9000202@oracle.com> <1e7d7718-c265-27ca-33b5-3e2fe7b0ffc3@redhat.com> Message-ID: <5873A060.6040306@oracle.com> Thanks, Roland! I pushed it: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/dd87a3e342a7 Best regards, Tobias On 09.01.2017 15:22, Roland Westrelin wrote: >> please review the following change which adds C2 support for value type arrays: >> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.05/ > > It looks good to me. Thanks! > > Roland. > From rwestrel at redhat.com Tue Jan 10 14:23:29 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 10 Jan 2017 15:23:29 +0100 Subject: C2: multiple slices for flattened value type arrays Message-ID: This patch has a couple small improvements on top of Tobias' change to support flattened value type arrays: 1) it changes the type of flattened value type arrays from array of pointers to value types to array of value types 2) it tweaks alias analysis so each field of the value type element has its own slice. To achieve 2), TypeAryPtr now keeps track of a field_offset, the offset within the value type for the field being accessed. The change is big because I decided to introduce an Offset class to manipulates the 2 cases where we have an offset in the types (offset from a pointer: TypePtr::_offset and field offset in arrays: TypeAryPtr::_field_offset). This avoids some code duplication but mainly, this helps getting calls to type factory methods and constructors right: type factory methods and constructors have so many arguments, many of the same types or types that the c++ compiler can implicit cast between that it's very easy to call a factory method and pass a boolean where an int is expected and have no compiled time error. Roland. From rwestrel at redhat.com Tue Jan 10 14:39:22 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 10 Jan 2017 15:39:22 +0100 Subject: C2: vdefault + vwithfield support Message-ID: http://cr.openjdk.java.net/~roland/valhalla/vdefault%2bvwithfield/webrev.00/ This adds basic support for vdefault and vwithfield. Some checks are missing (unloaded class etc.). Roland. From tobias.hartmann at oracle.com Tue Jan 10 14:49:38 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 10 Jan 2017 15:49:38 +0100 Subject: C2: multiple slices for flattened value type arrays In-Reply-To: References: Message-ID: <5874F482.2010907@oracle.com> Hi Roland, the webrev is missing. Best regards, Tobias On 10.01.2017 15:23, Roland Westrelin wrote: > > This patch has a couple small improvements on top of Tobias' change to > support flattened value type arrays: 1) it changes the type of flattened > value type arrays from array of pointers to value types to array of > value types 2) it tweaks alias analysis so each field of the value type > element has its own slice. > > To achieve 2), TypeAryPtr now keeps track of a field_offset, the offset > within the value type for the field being accessed. > > The change is big because I decided to introduce an Offset class to > manipulates the 2 cases where we have an offset in the types (offset > from a pointer: TypePtr::_offset and field offset in arrays: > TypeAryPtr::_field_offset). This avoids some code duplication but > mainly, this helps getting calls to type factory methods and > constructors right: type factory methods and constructors have so many > arguments, many of the same types or types that the c++ compiler can > implicit cast between that it's very easy to call a factory method and > pass a boolean where an int is expected and have no compiled time error. > > Roland. > From rwestrel at redhat.com Tue Jan 10 14:50:48 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 10 Jan 2017 15:50:48 +0100 Subject: C2: multiple slices for flattened value type arrays In-Reply-To: <5874F482.2010907@oracle.com> References: <5874F482.2010907@oracle.com> Message-ID: <7d8dcbc1-2aca-03c0-6341-162cc99b412c@redhat.com> > the webrev is missing. Sorry. Here it is: http://cr.openjdk.java.net/~roland/valhalla/flattenvtarray/webrev.00/ Roland. From frederic.parain at oracle.com Tue Jan 10 18:42:23 2017 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Tue, 10 Jan 2017 18:42:23 +0000 Subject: hg: valhalla/valhalla/hotspot: Adding embedded value type support to vwithfield Message-ID: <201701101842.v0AIgOru010733@aojmv0008.oracle.com> Changeset: ad1bc672ab0e Author: fparain Date: 2017-01-10 13:43 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ad1bc672ab0e Adding embedded value type support to vwithfield ! src/share/vm/interpreter/interpreterRuntime.cpp From frederic.parain at oracle.com Wed Jan 11 14:07:17 2017 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 11 Jan 2017 14:07:17 +0000 Subject: hg: valhalla/valhalla/hotspot: Fix incomplete cast in vwithfield Message-ID: <201701111407.v0BE7Hhn007547@aojmv0008.oracle.com> Changeset: 1f932c2189aa Author: fparain Date: 2017-01-11 09:09 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/1f932c2189aa Fix incomplete cast in vwithfield ! src/share/vm/interpreter/interpreterRuntime.cpp From tobias.hartmann at oracle.com Wed Jan 11 14:31:42 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 11 Jan 2017 15:31:42 +0100 Subject: C2: vdefault + vwithfield support In-Reply-To: References: Message-ID: <587641CE.4010105@oracle.com> Hi Roland, On 10.01.2017 15:39, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/valhalla/vdefault%2bvwithfield/webrev.00/ > > This adds basic support for vdefault and vwithfield. Some checks are > missing (unloaded class etc.). Looks good to me! Thanks, Tobias > > Roland. > From tobias.hartmann at oracle.com Thu Jan 12 10:57:56 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Thu, 12 Jan 2017 10:57:56 +0000 Subject: hg: valhalla/valhalla: Updated jib-profiles file to submit RBT jobs Message-ID: <201701121057.v0CAvu7b024908@aojmv0008.oracle.com> Changeset: 5820f2afe811 Author: thartmann Date: 2017-01-12 11:57 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/5820f2afe811 Updated jib-profiles file to submit RBT jobs ! common/conf/jib-profiles.js From tobias.hartmann at oracle.com Thu Jan 12 14:54:58 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 12 Jan 2017 15:54:58 +0100 Subject: C2: multiple slices for flattened value type arrays In-Reply-To: <7d8dcbc1-2aca-03c0-6341-162cc99b412c@redhat.com> References: <5874F482.2010907@oracle.com> <7d8dcbc1-2aca-03c0-6341-162cc99b412c@redhat.com> Message-ID: <587798C2.1080009@oracle.com> Hi Roland, On 10.01.2017 15:50, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/valhalla/flattenvtarray/webrev.00/ Very nice! I noticed some style issues you may want to correct since you changed those lines anyway: - Excess newlines that can be removed. For example, type.hpp:1208, type.cpp:4486, type.cpp:4594 - Wrong indentations. For example, type.cpp:3071 - Excess/missing whitespace around parentheses. For example: - TypeRawPtr( PTR ptr, address bits ) -> TypeRawPtr(PTR ptr, address bits) - assert( offset() >= 0, "" ) -> assert(offset() >= 0, "") - _bits(bits){} -> _bits(bits) { } - Pointer asterisk position. For example: - static const TypePtr *make(..) -> static const TypePtr* make(..) You don't need to send a new webrev for that or we can also do that cleanup later. Thanks, Tobias > > Roland. > From rwestrel at redhat.com Fri Jan 13 14:08:55 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 13 Jan 2017 15:08:55 +0100 Subject: C2: vdefault + vwithfield support In-Reply-To: <587641CE.4010105@oracle.com> References: <587641CE.4010105@oracle.com> Message-ID: Hi Tobias, >> http://cr.openjdk.java.net/~roland/valhalla/vdefault%2bvwithfield/webrev.00/ >> >> This adds basic support for vdefault and vwithfield. Some checks are >> missing (unloaded class etc.). > > Looks good to me! Thanks for looking at this. Roland. From rwestrel at redhat.com Fri Jan 13 14:34:30 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 13 Jan 2017 15:34:30 +0100 Subject: C2: multiple slices for flattened value type arrays In-Reply-To: <587798C2.1080009@oracle.com> References: <5874F482.2010907@oracle.com> <7d8dcbc1-2aca-03c0-6341-162cc99b412c@redhat.com> <587798C2.1080009@oracle.com> Message-ID: Hi Tobias, > I noticed some style issues you may want to correct since you changed those lines anyway: > - Excess newlines that can be removed. For example, type.hpp:1208, type.cpp:4486, type.cpp:4594 > - Wrong indentations. For example, type.cpp:3071 > - Excess/missing whitespace around parentheses. For example: > - TypeRawPtr( PTR ptr, address bits ) -> TypeRawPtr(PTR ptr, address bits) > - assert( offset() >= 0, "" ) -> assert(offset() >= 0, "") > - _bits(bits){} -> _bits(bits) { } > - Pointer asterisk position. For example: > - static const TypePtr *make(..) -> static const TypePtr* make(..) > > You don't need to send a new webrev for that or we can also do that cleanup later. Thanks for looking at this. I will do a quick pass of clean up and push it. Roland. From rwestrel at redhat.com Fri Jan 13 20:13:31 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Fri, 13 Jan 2017 20:13:31 +0000 Subject: hg: valhalla/valhalla/hotspot: C2: multiple slices for flattened value type arrays Message-ID: <201701132013.v0DKDV9c012955@aojmv0008.oracle.com> Changeset: abefceb95a0b Author: roland Date: 2017-01-13 15:54 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/abefceb95a0b C2: multiple slices for flattened value type arrays ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/opto/valuetypenode.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From rwestrel at redhat.com Fri Jan 13 20:13:57 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Fri, 13 Jan 2017 20:13:57 +0000 Subject: hg: valhalla/valhalla/hotspot: C2: vdefault + vwithfield support Message-ID: <201701132013.v0DKDvJ9013177@aojmv0008.oracle.com> Changeset: e6a7071a58aa Author: roland Date: 2017-01-10 15:25 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/e6a7071a58aa C2: vdefault + vwithfield support ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parseHelper.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From rwestrel at redhat.com Wed Jan 18 15:44:26 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 18 Jan 2017 16:44:26 +0100 Subject: Some multidimensional array tests + small tweaks to run them Message-ID: http://cr.openjdk.java.net/~roland/valhalla/multiarray/webrev.00/ A couple simple tests that only required some small tweaks to the compiler code. Roland. From tobias.hartmann at oracle.com Wed Jan 18 15:55:13 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 18 Jan 2017 15:55:13 +0000 Subject: hg: valhalla/valhalla: Reverted jib-profiles file update Message-ID: <201701181555.v0IFtDPs019395@aojmv0008.oracle.com> Changeset: 27d374a0ad48 Author: thartmann Date: 2017-01-18 16:54 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/27d374a0ad48 Reverted jib-profiles file update ! common/conf/jib-profiles.js From tobias.hartmann at oracle.com Wed Jan 18 17:07:26 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 18 Jan 2017 18:07:26 +0100 Subject: Some multidimensional array tests + small tweaks to run them In-Reply-To: References: Message-ID: <587FA0CE.7040606@oracle.com> Hi Roland, On 18.01.2017 16:44, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/valhalla/multiarray/webrev.00/ > > A couple simple tests that only required some small tweaks to the > compiler code. Looks good to me! Thanks, Tobias > > Roland. > From rwestrel at redhat.com Wed Jan 18 17:09:07 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Wed, 18 Jan 2017 17:09:07 +0000 Subject: hg: valhalla/valhalla/hotspot: multidimensional array tests Message-ID: <201701181709.v0IH97oW006484@aojmv0008.oracle.com> Changeset: c4b4ab053e6b Author: roland Date: 2017-01-18 16:30 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/c4b4ab053e6b multidimensional array tests ! src/share/vm/ci/ciObjArrayKlass.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From rwestrel at redhat.com Wed Jan 18 17:09:39 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 18 Jan 2017 18:09:39 +0100 Subject: Some multidimensional array tests + small tweaks to run them In-Reply-To: <587FA0CE.7040606@oracle.com> References: <587FA0CE.7040606@oracle.com> Message-ID: <1e414f37-65e7-1da6-fc1c-d3015fd2b100@redhat.com> Thanks for looking at that change. Roland. From tobias.hartmann at oracle.com Thu Jan 19 10:32:29 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Thu, 19 Jan 2017 10:32:29 +0000 Subject: hg: valhalla/valhalla/hotspot: Fixed build on Linux/MacOSX x86_64 Message-ID: <201701191032.v0JAWTpZ001276@aojmv0008.oracle.com> Changeset: 04dc71b403dc Author: thartmann Date: 2017-01-19 11:32 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/04dc71b403dc Fixed build on Linux/MacOSX x86_64 ! src/share/vm/ci/ciArrayKlass.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciValueArrayKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/valueArrayKlass.cpp ! src/share/vm/oops/valueArrayKlass.hpp ! src/share/vm/oops/valueKlass.hpp ! src/share/vm/runtime/sharedRuntime.cpp From tobias.hartmann at oracle.com Thu Jan 19 10:32:42 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 19 Jan 2017 11:32:42 +0100 Subject: Build broken on Windows x64 Message-ID: <588095CA.6050006@oracle.com> Hi Fred, the Windows x64 build is currently broken due to: C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(283) : error C2065: '_num_int_args' : undeclared identifier C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(283) : error C2050: switch expression not integral C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(287) : error C2065: '_num_int_args' : undeclared identifier C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(294) : error C2065: '_num_int_args' : undeclared identifier C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(301) : error C2065: '_num_int_args' : undeclared identifier C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(305) : error C2065: 'c_rarg4' : undeclared identifier C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(307) : error C2065: 'c_rarg4' : undeclared identifier C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(308) : error C2065: '_num_int_args' : undeclared identifier C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(312) : error C2065: 'c_rarg5' : undeclared identifier C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(314) : error C2065: 'c_rarg5' : undeclared identifier C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(315) : error C2065: '_num_int_args' : undeclared identifier C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(554) : error C2259: 'SlowSignatureHandler' : cannot instantiate abstract class due to following members: 'void NativeSignatureIterator::pass_valuetype(void)' : is abstract C:\jprt\T\P1\093341.tohartma\s\hotspot\src\share\vm\runtime/signature.hpp(326) : see declaration of 'NativeSignatureIterator::pass_valuetype' C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(554) : error C2228: left of '.iterate' must have class/struct/union The problem is that there are some #ifdef _WIN64 in the code and the WIN64 specific code is not implemented. Is this intended? Thanks, Tobias From tobias.hartmann at oracle.com Thu Jan 19 10:32:52 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 19 Jan 2017 11:32:52 +0100 Subject: 32 bit build broken on Linux x86 Message-ID: <588095D4.8060307@oracle.com> Hi Roland, I just noticed that your value type calling convention change broke the 32 bit build (see below). http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6b6d84008c49 Could you please have a look? Thanks, Tobias /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:703:6: error: prototype for 'void SharedRuntime::gen_i2c_adapter(MacroAssembler*, int, int, const BasicType*, const VMRegPair*)' does not match any in class 'SharedRuntime' void SharedRuntime::gen_i2c_adapter(MacroAssembler *masm, ^ In file included from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/gc/shared/collectedHeap.inline.hpp:35:0, from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/oops/oop.inline.hpp:31, from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/oops/markOop.inline.hpp:30, from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/precompiled/precompiled.hpp:150: /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/runtime/sharedRuntime.hpp:482:15: error: candidate is: static void SharedRuntime::gen_i2c_adapter(MacroAssembler*, int, const GrowableArray&, const VMRegPair*) static void gen_i2c_adapter(MacroAssembler *_masm, ^ /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:915:22: error: prototype for 'AdapterHandlerEntry* SharedRuntime::generate_i2c2i_adapters(MacroAssembler*, int, int, const BasicType*, const VMRegPair*, AdapterFingerPrint*)' does not match any in class 'SharedRuntime' AdapterHandlerEntry* SharedRuntime::generate_i2c2i_adapters(MacroAssembler *masm, ^ In file included from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/gc/shared/collectedHeap.inline.hpp:35:0, from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/oops/oop.inline.hpp:31, from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/oops/markOop.inline.hpp:30, from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/precompiled/precompiled.hpp:150: /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/runtime/sharedRuntime.hpp:475:31: error: candidate is: static AdapterHandlerEntry* SharedRuntime::generate_i2c2i_adapters(MacroAssembler*, int, const GrowableArray&, const VMRegPair*, AdapterFingerPrint*, AdapterBlob*&) static AdapterHandlerEntry* generate_i2c2i_adapters(MacroAssembler *_masm, ^ /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:559:13: error: 'void gen_c2i_adapter(MacroAssembler*, int, int, const BasicType*, const VMRegPair*, Label&)' defined but not used [-Werror=unused-function] static void gen_c2i_adapter(MacroAssembler *masm, ^ /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:685:13: error: 'void move_i2c_double(MacroAssembler*, XMMRegister, Register, int)' defined but not used [-Werror=unused-function] static void move_i2c_double(MacroAssembler *masm, XMMRegister r, Register saved_sp, int ld_off) { ^ /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:690:13: error: 'void range_check(MacroAssembler*, Register, Register, address, address, Label&)' defined but not used [-Werror=unused-function] static void range_check(MacroAssembler* masm, Register pc_reg, Register temp_reg, ^ cc1plus: all warnings being treated as errors From karen.kinnear at oracle.com Mon Jan 23 21:41:39 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 23 Jan 2017 16:41:39 -0500 Subject: Initial feedback on Minimal Value Types 0.2 for discussion Message-ID: <18357DE1-A914-483D-92A3-D11F2FCD061D@oracle.com> Review of Minimal Value Types August 2016 Shady Edition (v 0.2) http://cr.openjdk.java.net/~jrose/values/shady-values.html Questions/Comments: abbreviations used: VCC: value-capable class, DVT: derived value type 1. Goals -- might be worth adding to the bullets: Allow use of existing toolchain where possible including IDEs and debuggers 2. Features: "Three" bytecode instructions ->"A small set of" 3. Typically, value-capable classes will not be exported. Is the reason for this to limit exposure since the expectation is that the initial APIs and mechanisms will change? 4. Value-capable classes: supporting methods p.3 "This design endows both boxes and pure values with a common set of methods; it "lifts" box methods onto the derived values." p.5 "The synthetic class has the given fields (unchanged) and has no methods" p.5 "Meanwhile, all methods (and other class features) stay on the value-capable class. The value type proper is just a "dumb struct" containing the extracted fields" - given that in the MVT model we are starting with a POJO box, and instance methods that clearly take an Object as a receiver, one proposal for the initial MVT approach would be to have all methods only supported by the box, and require boxing to invoke any methods - so I think the first quote would need either removal or modification 5. Value bytecodes p.11 "Method handles and invokedynamic will always allow bytecode to invoke methods on Q-types". - is this still accurate in the context above? I know the comment says that internally the MH might box the Qtype, but do we still want to support MH and indy to appear to invoke methods on Q-types? 6. Restrictions on the POJO: A. It would help to have a bulleted list of restrictions B. Clarify error/exception to throw - perhaps ClassFormatError for all of these? C. Request to not support VCC on interfaces at all for MVT 1.0 I know the restrictions are intermixed in the text today. This is what I extracted: (p.3-4, 6) VCC (and probably going forward) 1. VCC superclass must be Object (and should be omitted) 2. the class must be final 3. all fields must be final - please clarify - all instance fields must be final 4. all constructors private 5. must replace equals, hashcode, toString (with current Object syntax) 6. may not use any methods provided on Object specifically: may not use clone, finalize, wait, notify, notifyAll (directly) 7. may use getClass MVT 1.0 additional limitations 9. may contain primitive instance fields, but no reference instance fields - please update document to clarify this restriction is for instance fields only 10. may not contain generic instance fields - please update document to clarify this restriction is for instance fields only - it is my understanding that you can?t have generic static fields at all 11. "interfaces (especially with default methods)" - please change p.6 to clarify that there are no value type interfaces period. 12. 0.2 version states: may not contain a value class as an instance field - see below for further discussion 7. potential extensions: 12. 0.2 version states: value class may not contain a value class as an instance field - we would like to propose supporting this - perhaps as an optional extension? - we would need to add an exception for handling circularity - note: no way to express this in java, but you could express in a classfile 8. Splitting the value type from the object type Propose not using the nested class approach, to not tie us into this relationship longer term - so remove example and the "looks like an inner class" - note: a key point here is how the user generating bytecodes would know the generated name of the DVT This will need further discussion. In the constant pool, references can use Qpackage.Class; rather than Lpackage.Class; Are there requirements for java sources to be able to refer to the derived value type by name? e.g. Class.forName()? If not, then perhaps the temporary naming convention could be kept internal? 9. Splitting the value type from the object type p.5 "The original class is given a new synthetic field of the new value type, to hold the state for the original class". - to simplify implementation, and allow experiments which go beyond the initial MVT plans, we propose * that the VCC is left untouched * the DVT has a copy of the immutable instance fields - We think this qualifies as "any equivalent technique" on p.5 - the quote above would need modifying or removing 10. Scoping of these features - exploring adding class file capability bits for experimental features, as a versioning approach - we will want to pin this down later in the cycle 11. JVM changes to support Q-types - "So when the class loader loads an object whose fields are Q_types, it must resolve (and perhaps load) the classes of those Q_types, ..." - for instance fields that are Q-types, I believe we need to explicitly specify temporary JVMS load/link/init rules (I will propose an early draft in a later email). - e.g. Specifically, for instance fields that are Q-types, we would propose requiring eager loading of the Q-types, modifying JVMS 5.3.5 Deriving a Class from a class File Representation. Bullets 3 and 4 described eager resolution of the direct superclass and direct superinterfaces. The expectation is that an additional bullet would be added for direct instance fields that are Q-types. - note that this change would make it the JVM's responsibility, not the class loaders' responsibility, to resolve the classes of those Q-types. Note: in the JVMS load/link/init rules I will also propose VCC/DVT load/link/init requirements. 12. value bytecodes - the following are useful in the MethodHandle implementation, and likely to be useful for direct bytecode access - we would like to propose the following as the minimal bytecode set: in addition to vload, vstore, vreturn (and slot-specific variants) - vdefault/vwithfield - vbox/vunbox - vaload/vastore - vgetfield (fetch a field from a value type) - NOT vcmp_eq/ne (equality can be implemented as component-wise comparison) clarify that for MVT 1.0, statics are only available through the box. (TODO: where does this go in shady?) 13. value bytecodes - open issue - typed prefix vs. vbytecodes for initial prototype 14. Value bytecodes use of Qtype as class component: "Initially the only valid use of a Q-type [is] as the class component of a CONSTANT_Methodref or CONSTANT_Fieldref is as a CONSTANT_MethodHandle constant." - if we extend the bytecodes as above, and we disallow anyone (MethodHandles, bytecodes) from invoking methods on Qtypes, we could modify this to disallow Q-types for CONSTANT_Methodref or CONSTANT_InterfaceMethodRef completely. - but perhaps you want the MethodHandles to be able to invoke methods on DVTs by dynamically boxing them. This works as long as the methods don't assume identity. 15. Q-types and bytecodes We propose modifying anewarray and multianewarray to allow operands that are Q-types. 16. Value Type Reflection With the proposed modifications in #8 above: i.e. leaving the VCC untouched and copying the instance fields to the DVT, the VCC now matches the source file. So Class.forName() would return the VCC which is the original POJO which fits the backward compatibility model. So we don't need a separate SourceClass, but leaving it in the proposal provides implementation flexibility. 17. Q-type method handles & behaviors "possible bytecode" might want to change vnew to vdefault these are samples and evolving, so maybe not worth changing I did not do this level of detailed review for the Future Work yet. thanks, Karen From stanislav.smirnov at oracle.com Wed Jan 25 15:06:26 2017 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Wed, 25 Jan 2017 18:06:26 +0300 Subject: 32 bit build broken on Linux x86 In-Reply-To: <588095D4.8060307@oracle.com> References: <588095D4.8060307@oracle.com> Message-ID: Hi Roland, any update? Best regards, Stanislav Smirnov > On 19 Jan 2017, at 13:32, Tobias Hartmann wrote: > > Hi Roland, > > I just noticed that your value type calling convention change broke the 32 bit build (see below). > http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6b6d84008c49 > > Could you please have a look? > > Thanks, > Tobias > > /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:703:6: error: prototype for 'void SharedRuntime::gen_i2c_adapter(MacroAssembler*, int, int, const BasicType*, const VMRegPair*)' does not match any in class 'SharedRuntime' > void SharedRuntime::gen_i2c_adapter(MacroAssembler *masm, > ^ > In file included from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/gc/shared/collectedHeap.inline.hpp:35:0, > from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/oops/oop.inline.hpp:31, > from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/oops/markOop.inline.hpp:30, > from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/precompiled/precompiled.hpp:150: > /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/runtime/sharedRuntime.hpp:482:15: error: candidate is: static void SharedRuntime::gen_i2c_adapter(MacroAssembler*, int, const GrowableArray&, const VMRegPair*) > static void gen_i2c_adapter(MacroAssembler *_masm, > ^ > /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:915:22: error: prototype for 'AdapterHandlerEntry* SharedRuntime::generate_i2c2i_adapters(MacroAssembler*, int, int, const BasicType*, const VMRegPair*, AdapterFingerPrint*)' does not match any in class 'SharedRuntime' > AdapterHandlerEntry* SharedRuntime::generate_i2c2i_adapters(MacroAssembler *masm, > ^ > In file included from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/gc/shared/collectedHeap.inline.hpp:35:0, > from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/oops/oop.inline.hpp:31, > from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/oops/markOop.inline.hpp:30, > from /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/precompiled/precompiled.hpp:150: > /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/share/vm/runtime/sharedRuntime.hpp:475:31: error: candidate is: static AdapterHandlerEntry* SharedRuntime::generate_i2c2i_adapters(MacroAssembler*, int, const GrowableArray&, const VMRegPair*, AdapterFingerPrint*, AdapterBlob*&) > static AdapterHandlerEntry* generate_i2c2i_adapters(MacroAssembler *_masm, > ^ > /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:559:13: error: 'void gen_c2i_adapter(MacroAssembler*, int, int, const BasicType*, const VMRegPair*, Label&)' defined but not used [-Werror=unused-function] > static void gen_c2i_adapter(MacroAssembler *masm, > ^ > /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:685:13: error: 'void move_i2c_double(MacroAssembler*, XMMRegister, Register, int)' defined but not used [-Werror=unused-function] > static void move_i2c_double(MacroAssembler *masm, XMMRegister r, Register saved_sp, int ld_off) { > ^ > /scratch/opt/jprt/T/P1/080644.tohartma/s/hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:690:13: error: 'void range_check(MacroAssembler*, Register, Register, address, address, Label&)' defined but not used [-Werror=unused-function] > static void range_check(MacroAssembler* masm, Register pc_reg, Register temp_reg, > ^ > cc1plus: all warnings being treated as errors