From maurizio.cimadamore at oracle.com Wed Jul 1 15:33:51 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 01 Jul 2015 15:33:51 +0000 Subject: hg: valhalla/valhalla/jdk: Enhancement: add capability to specialize boot classes Message-ID: <201507011533.t61FXpd1012067@aojmv0008.oracle.com> Changeset: 002b0dbf6999 Author: mcimadamore Date: 2015-07-01 16:33 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/002b0dbf6999 Enhancement: add capability to specialize boot classes Contributed-by: lois.foltan at oracle.com * add support for specializing classes in bcp * convert prespecializer into test ! src/java.base/share/classes/java/net/URLClassLoader.java + src/java.base/share/classes/valhalla/classdyn/ClassDynHelper.java - src/java.base/share/classes/valhalla/specializer/Prespecialize.java ! src/java.base/share/classes/valhalla/specializer/SignatureSpecializer.java ! src/java.base/share/classes/valhalla/specializer/Specializer.java + test/valhalla/boottest/valhalla/specializer/PrespecializerTest.java ! test/valhalla/test/valhalla/specializer/ObjectMethodsTest.java From maurizio.cimadamore at oracle.com Wed Jul 1 15:35:48 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 01 Jul 2015 15:35:48 +0000 Subject: hg: valhalla/valhalla/hotspot: Enhancement: add upcall for specializing bootclasses Message-ID: <201507011535.t61FZmfa012838@aojmv0008.oracle.com> Changeset: 419818b23594 Author: mcimadamore Date: 2015-07-01 16:35 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/419818b23594 Enhancement: add upcall for specializing bootclasses Contributed-by: lois.foltan at oracle.com ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp From maurizio.cimadamore at oracle.com Wed Jul 1 15:47:26 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 01 Jul 2015 15:47:26 +0000 Subject: hg: valhalla/valhalla: Remove prespecialization step from 'images' target Message-ID: <201507011547.t61FlQTM017912@aojmv0008.oracle.com> Changeset: 805822c0c42e Author: mcimadamore Date: 2015-07-01 16:36 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/805822c0c42e Remove prespecialization step from 'images' target ! make/Images.gmk From maurizio.cimadamore at oracle.com Thu Jul 2 10:35:06 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 02 Jul 2015 10:35:06 +0000 Subject: hg: valhalla/valhalla/jdk: Turn prespecializer test into a regular jtreg Message-ID: <201507021035.t62AZ6nh014162@aojmv0008.oracle.com> Changeset: deea2507739f Author: mcimadamore Date: 2015-07-02 11:34 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/deea2507739f Turn prespecializer test into a regular jtreg * verify all eagerly specialized classes -Xverify:all * add problem list ! src/java.base/share/classes/java/anyutil/Spliterators.java ! src/java.base/share/classes/valhalla/specializer/Specializer.java ! src/java.base/share/classes/valhalla/specializer/TypeVariablesMapAttribute.java ! test/TEST.groups + test/valhalla/PrespecializerTest.java - test/valhalla/boottest/valhalla/specializer/PrespecializerTest.java From maurizio.cimadamore at oracle.com Thu Jul 2 11:16:33 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 02 Jul 2015 11:16:33 +0000 Subject: hg: valhalla/valhalla/langtools: Enhancement: add support for ref-only var with bounds mentioning any-vars Message-ID: <201507021116.t62BGXhr021304@aojmv0008.oracle.com> Changeset: e8231081c2a6 Author: mcimadamore Date: 2015-07-02 12:16 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/e8231081c2a6 Enhancement: add support for ref-only var with bounds mentioning any-vars * tweaked TypeVariableMapping attribute to include full bound (non-erased) info * revised Types.needsMangling routine to take into account tvar bounds * added smoke test ! src/jdk.compiler/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/classfile/TypeVariablesMap_attribute.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java ! src/jdk.compiler/share/classes/com/sun/tools/javap/AttributeWriter.java + test/tools/javac/valhalla/typespec/Specialization01.java From maurizio.cimadamore at oracle.com Thu Jul 2 11:19:11 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 02 Jul 2015 11:19:11 +0000 Subject: hg: valhalla/valhalla/jdk: Enhancement: add support for ref-only var with bounds mentioning any-vars Message-ID: <201507021119.t62BJBJT021748@aojmv0008.oracle.com> Changeset: 2856d82afcf4 Author: mcimadamore Date: 2015-07-02 12:18 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/2856d82afcf4 Enhancement: add support for ref-only var with bounds mentioning any-vars * specializer now performs specialization of var bounds ! src/java.base/share/classes/valhalla/specializer/SignatureSpecializer.java ! src/java.base/share/classes/valhalla/specializer/Specializer.java ! src/java.base/share/classes/valhalla/specializer/TypeVariablesMapAttribute.java From maurizio.cimadamore at oracle.com Fri Jul 3 18:09:44 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 03 Jul 2015 18:09:44 +0000 Subject: hg: valhalla/valhalla/langtools: Enhancement: emit warnings for unsupported Valhalla features Message-ID: <201507031809.t63I9igE028987@aojmv0008.oracle.com> Changeset: 00906d972818 Author: mcimadamore Date: 2015-07-03 19:09 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/00906d972818 Enhancement: emit warnings for unsupported Valhalla features * compiler should bark when encountering stuff that's not supported by the runtime specializer; for now two: - shadowing of any vars - classes that get any vars from the enclosing context (i.e. member, local, anonymous inner) * Fix: loop detection logic for Types.ContainsAny does not work properly * Fix: ClassWriter should skip BMA generation on non-specializable synthetics ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt From maurizio.cimadamore at oracle.com Fri Jul 3 18:11:06 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 03 Jul 2015 18:11:06 +0000 Subject: hg: valhalla/valhalla/jdk: * Rewrite classes in anyutil to workaround specializer limitations Message-ID: <201507031811.t63IB79G029199@aojmv0008.oracle.com> Changeset: 27cfb6eb0397 Author: mcimadamore Date: 2015-07-03 19:10 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/27cfb6eb0397 * Rewrite classes in anyutil to workaround specializer limitations * enhanced detection logic in PrespecializerTest * dropped some classes from problem list in PrespecializerTest ! src/java.base/share/classes/java/anyutil/Comparator.java ! src/java.base/share/classes/java/anyutil/function/BinaryOperator.java ! src/java.base/share/classes/java/anyutil/function/Function.java ! src/java.base/share/classes/java/anyutil/function/Predicate.java ! src/java.base/share/classes/java/anyutil/function/UnaryOperator.java ! src/java.base/share/classes/java/anyutil/stream/ForEachOps.java ! src/java.base/share/classes/java/anyutil/stream/Pipeline.java ! src/java.base/share/classes/java/anyutil/stream/ReduceOps.java ! src/java.base/share/classes/java/anyutil/stream/SpinedBuffer.java ! test/valhalla/PrespecializerTest.java From maurizio.cimadamore at oracle.com Mon Jul 6 10:44:17 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 06 Jul 2015 10:44:17 +0000 Subject: hg: valhalla/valhalla/langtools: Fix: missing BMA on cast on anyfied arrays Message-ID: <201507061044.t66AiHeK010935@aojmv0008.oracle.com> Changeset: f85bdf089185 Author: mcimadamore Date: 2015-07-06 11:44 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/f85bdf089185 Fix: missing BMA on cast on anyfied arrays ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/valhalla/typespec/Cast03.java ! test/tools/javac/valhalla/typespec/items/tests/TestCast.java From maurizio.cimadamore at oracle.com Mon Jul 6 10:45:54 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 06 Jul 2015 10:45:54 +0000 Subject: hg: valhalla/valhalla/jdk: * Missing erasure on ANEWARRAY specialization Message-ID: <201507061045.t66AjsDB011672@aojmv0008.oracle.com> Changeset: 7e0b93983daa Author: mcimadamore Date: 2015-07-06 11:45 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/7e0b93983daa * Missing erasure on ANEWARRAY specialization ! src/java.base/share/classes/valhalla/specializer/Specializer.java From maurizio.cimadamore at oracle.com Tue Jul 7 10:22:52 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 07 Jul 2015 10:22:52 +0000 Subject: hg: valhalla/valhalla/langtools: Fix: add support for adaptation of signatures with fbounds Message-ID: <201507071022.t67AMqLH027046@aojmv0008.oracle.com> Changeset: 747ff4d57669 Author: mcimadamore Date: 2015-07-07 11:22 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/747ff4d57669 Fix: add support for adaptation of signatures with fbounds * added new routine (Types.decorateDescriptor) which augments a given descriptor with extra type info preserving its erasure * both bridge generation and BMA generation now use the new adaptation logic * add logic for generating BMAs in synthetic bridge cast * updated BMA tests * added several descriptor adaptation tests ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java + test/tools/javac/valhalla/typespec/Augment01.java + test/tools/javac/valhalla/typespec/Augment02.java + test/tools/javac/valhalla/typespec/Augment03.java + test/tools/javac/valhalla/typespec/Augment04.java + test/tools/javac/valhalla/typespec/Augment05.java + test/tools/javac/valhalla/typespec/Augment06.java ! test/tools/javac/valhalla/typespec/items/BytecodeMappingHarness.java ! test/tools/javac/valhalla/typespec/items/TemplateMethod.java ! test/tools/javac/valhalla/typespec/items/tests/TestDefault.java ! test/tools/javac/valhalla/typespec/items/tests/TestLambda.java ! test/tools/javac/valhalla/typespec/items/tests/TestRespecialization.java ! test/tools/javac/valhalla/typespec/items/tests/TestSyntheticCast.java ! test/tools/javac/valhalla/typespec/items/tests/TestValOnly.java From maurizio.cimadamore at oracle.com Tue Jul 7 10:23:20 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 07 Jul 2015 10:23:20 +0000 Subject: hg: valhalla/valhalla/jdk: Fixes: Message-ID: <201507071023.t67ANKq9027203@aojmv0008.oracle.com> Changeset: 79956b73d247 Author: mcimadamore Date: 2015-07-07 11:19 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/79956b73d247 Fixes: * Insert (temporarily) raw cast to avoid use of wildcards in Pipeline * Add logic to detect specialization changes involving fbounds * Fix bug with parsing of indy BMA entry * removed several classes from problem list in PrespecializerTest ! src/java.base/share/classes/java/anyutil/stream/Pipeline.java ! src/java.base/share/classes/valhalla/specializer/SignatureSpecializer.java ! src/java.base/share/classes/valhalla/specializer/Specializer.java ! test/valhalla/PrespecializerTest.java + test/valhalla/test/valhalla/specializer/MultiBoxTest.java From maurizio.cimadamore at oracle.com Tue Jul 7 17:26:14 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 07 Jul 2015 17:26:14 +0000 Subject: hg: valhalla/valhalla/langtools: Fix: missing BMA in synthetic cast Message-ID: <201507071726.t67HQEEH006757@aojmv0008.oracle.com> Changeset: 9d4cb1396926 Author: mcimadamore Date: 2015-07-07 18:25 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/9d4cb1396926 Fix: missing BMA in synthetic cast * proto-type used by TransTypes when translating cast expression does not contain unerased info for BMA generation ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java ! test/tools/javac/valhalla/typespec/items/tests/TestSyntheticCast.java From maurizio.cimadamore at oracle.com Wed Jul 8 14:15:18 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 08 Jul 2015 14:15:18 +0000 Subject: hg: valhalla/valhalla/langtools: Fix: wrong normalization of toplevel captured types leads to 'loose' wildcards Message-ID: <201507081415.t68EFIFO023287@aojmv0008.oracle.com> Changeset: ffc0d863bbf9 Author: mcimadamore Date: 2015-07-08 15:14 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ffc0d863bbf9 Fix: wrong normalization of toplevel captured types leads to 'loose' wildcards ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/valhalla/typespec/Inference08.java ! test/tools/javac/valhalla/typespec/items/tests/TestAnyMembers.java ! test/tools/javac/valhalla/typespec/items/tests/TestCapture.java From maurizio.cimadamore at oracle.com Wed Jul 8 14:16:59 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 08 Jul 2015 14:16:59 +0000 Subject: hg: valhalla/valhalla/jdk: Fix: wrong class name generation during marshalling of additional static metafactory indy args Message-ID: <201507081416.t68EGx4q023955@aojmv0008.oracle.com> Changeset: ae474c1feac1 Author: mcimadamore Date: 2015-07-08 15:16 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/ae474c1feac1 Fix: wrong class name generation during marshalling of additional static metafactory indy args ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java From brian.goetz at oracle.com Thu Jul 9 14:33:41 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 9 Jul 2015 10:33:41 -0400 Subject: Next rounds of prototype Message-ID: <559E8645.4070104@oracle.com> In the next week or two, we'll be pushing parts of our next round of prototype for anyfied generics. The central complaint about the existing prototype has been the lack of a common supertype between Foo and Foo, other than Object. (Much existing code relies on wildcards, for better or worse.) Of course, we didn't pursue the original path because we loved the resulting type system; we pursued this path because it was *what was possible with the JVM architecture we have*. That's not to say that changing the JVM is off the table (as it was in Java 5), but doing so is even more costly than changing the language (which is already quite expensive), and it would have been irresponsible to pursue VM-centric options without first exploring what could be done without VM changes. Of course, even once "change the VM" is under consideration, there is a broad spectrum of cost, ranging from "merely extremely expensive" to "obscenely expensive." So a responsible investigation involves extensive exploration to identify sensible and cost-effective improvements. To that end, we've spent the past several months identifying what we could do in the VM to enable a useful common supertype for all instantiations (whether that is spelled "Foo" is a separate question), and, after several rounds, have pared this down to something that is conceivably implementable with a tractibly-small set of VM changes. In the next week or two, we'll be pushing a prototype implementation of the compiler. We'll follow that up with some new new documents describing what we've done, and prototypes of some of the VM features that are needed to plug the holes. I'm sure there are lots of questions; hopefully they will be answered when we can write it all up. As always, the most important feedback we can get is from people *using* the prototype. We'll post a short summary of the language changes so folks can play with the prototype more effectively. From forax at univ-mlv.fr Thu Jul 9 14:55:33 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 9 Jul 2015 16:55:33 +0200 Subject: Next rounds of prototype In-Reply-To: <559E8645.4070104@oracle.com> References: <559E8645.4070104@oracle.com> Message-ID: <559E8B65.60505@univ-mlv.fr> Am i wrong saying that if it is not spelled List but List, then there is no backward compatibility issue so you don't need a VM change because all methods can be called using invokedynamic. R?mi On 07/09/2015 04:33 PM, Brian Goetz wrote: > In the next week or two, we'll be pushing parts of our next round of > prototype for anyfied generics. > > > The central complaint about the existing prototype has been the lack of > a common supertype between Foo and Foo, other than > Object. (Much existing code relies on wildcards, for better or worse.) > > Of course, we didn't pursue the original path because we loved the > resulting type system; we pursued this path because it was *what was > possible with the JVM architecture we have*. That's not to say that > changing the JVM is off the table (as it was in Java 5), but doing so is > even more costly than changing the language (which is already quite > expensive), and it would have been irresponsible to pursue VM-centric > options without first exploring what could be done without VM changes. > > Of course, even once "change the VM" is under consideration, there is a > broad spectrum of cost, ranging from "merely extremely expensive" to > "obscenely expensive." So a responsible investigation involves > extensive exploration to identify sensible and cost-effective > improvements. > > To that end, we've spent the past several months identifying what we > could do in the VM to enable a useful common supertype for all > instantiations (whether that is spelled "Foo" is a separate > question), and, after several rounds, have pared this down to something > that is conceivably implementable with a tractibly-small set of VM > changes. In the next week or two, we'll be pushing a prototype > implementation of the compiler. We'll follow that up with some new > new documents describing what we've done, and prototypes of some of > the VM features that are needed to plug the holes. I'm sure there are > lots of questions; hopefully they will be answered when we can write > it all up. > > As always, the most important feedback we can get is from people *using* > the prototype. We'll post a short summary of the language changes so > folks can play with the prototype more effectively. > > From maurizio.cimadamore at oracle.com Thu Jul 9 15:15:36 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 09 Jul 2015 15:15:36 +0000 Subject: hg: valhalla/valhalla/langtools: Enhancement: add support for anyfied wildcards in javac Message-ID: <201507091515.t69FFal0002410@aojmv0008.oracle.com> Changeset: 329f5ec6e169 Author: mcimadamore Date: 2015-07-09 16:14 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/329f5ec6e169 Enhancement: add support for anyfied wildcards in javac * parser changes to support new Foo syntax for anyfied wildcards * type system changes to match semantics of new wildcard types * code generation changes, erasure also applies a 'virtualization' pass * virtualized accessors fo through indy to hide boxing adapations * added several tests Todo: * separate compilation doesn't work properly w.r.t. anyfied wildcards (as there's no way to represent them inside Signature attributes, yet) * semantics of unchecked calls might need further refinements ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/diags/examples/CantSelectNonVirtual.java ! test/tools/javac/generics/bridges/BridgeHarness.java ! test/tools/javac/treeannotests/TestProcessor.java ! test/tools/javac/valhalla/typespec/Cast01.java ! test/tools/javac/valhalla/typespec/Cast01.out + test/tools/javac/valhalla/typespec/Wildcards05.java + test/tools/javac/valhalla/typespec/Wildcards06.java + test/tools/javac/valhalla/typespec/Wildcards07.java + test/tools/javac/valhalla/typespec/Wildcards07.out + test/tools/javac/valhalla/typespec/Wildcards08.java + test/tools/javac/valhalla/typespec/Wildcards08.out + test/tools/javac/valhalla/typespec/Wildcards09.java + test/tools/javac/valhalla/typespec/Wildcards09.out ! test/tools/javac/valhalla/typespec/items/BytecodeMappingHarness.java From maurizio.cimadamore at oracle.com Thu Jul 9 15:16:04 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 09 Jul 2015 15:16:04 +0000 Subject: hg: valhalla/valhalla/jdk: Enhancement: add support for anyfied wildcards in specializer Message-ID: <201507091516.t69FG5h9002830@aojmv0008.oracle.com> Changeset: 62c1ff2e7c3a Author: mcimadamore Date: 2015-07-09 16:10 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/62c1ff2e7c3a Enhancement: add support for anyfied wildcards in specializer * all specialization share common (virtual interface) supertype * add support for dynamic boxing/bridge generation * add boostrap for virtual access on anyfied wildcards parameterized types * Pipeline refactoring to take into account anyfied wildcards (contributed by: bgoetz at oracle.com) * add simple anyfied pipeline test * add several tests for anyfied wildcards accessors ! src/java.base/share/classes/java/anyutil/Optional.java ! src/java.base/share/classes/java/anyutil/PrimitiveIterator.java ! src/java.base/share/classes/java/anyutil/Spliterator.java ! src/java.base/share/classes/java/anyutil/stream/AbstractShortCircuitTask.java ! src/java.base/share/classes/java/anyutil/stream/AbstractTask.java ! src/java.base/share/classes/java/anyutil/stream/FindOps.java ! src/java.base/share/classes/java/anyutil/stream/ForEachOps.java ! src/java.base/share/classes/java/anyutil/stream/MatchOps.java ! src/java.base/share/classes/java/anyutil/stream/Nodes.java ! src/java.base/share/classes/java/anyutil/stream/Pipeline.java ! src/java.base/share/classes/java/anyutil/stream/PipelineHelper.java ! src/java.base/share/classes/java/anyutil/stream/ReduceOps.java ! src/java.base/share/classes/java/anyutil/stream/StreamSpliterators.java ! src/java.base/share/classes/java/anyutil/stream/TerminalOp.java + src/java.base/share/classes/java/lang/invoke/VirtualAccess.java ! src/java.base/share/classes/valhalla/specializer/SignatureSpecializer.java ! src/java.base/share/classes/valhalla/specializer/Specializer.java ! test/valhalla/PrespecializerTest.java + test/valhalla/test/valhalla/anyutil/SimplePipelineTest.java + test/valhalla/test/valhalla/specializer/GenericMethodRawAndWildcardTest.java + test/valhalla/test/valhalla/specializer/RawAccessTest.java + test/valhalla/test/valhalla/specializer/RawAndWildcardAccessTest.java + test/valhalla/test/valhalla/specializer/RawCastInstanceOfTest.java ! test/valhalla/test/valhalla/specializer/WhereTest.java From brian.goetz at oracle.com Thu Jul 9 15:54:56 2015 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 09 Jul 2015 15:54:56 +0000 Subject: hg: valhalla/valhalla/jdk: Restructure Pipeline to move head-only state to head class; add back implementations for reduce/collect/count/min/max; more tests Message-ID: <201507091554.t69Fsvw9008336@aojmv0008.oracle.com> Changeset: 551be4cf8bf5 Author: briangoetz Date: 2015-07-09 11:51 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/551be4cf8bf5 Restructure Pipeline to move head-only state to head class; add back implementations for reduce/collect/count/min/max; more tests ! src/java.base/share/classes/java/anyutil/function/BinaryOperator.java ! src/java.base/share/classes/java/anyutil/stream/Pipeline.java ! src/java.base/share/classes/java/anyutil/stream/Stream.java ! src/java.base/share/classes/java/anyutil/stream/StreamSpliterators.java ! test/valhalla/test/valhalla/anyutil/SimplePipelineTest.java From martijnverburg at gmail.com Thu Jul 9 15:57:10 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 9 Jul 2015 16:57:10 +0100 Subject: Next rounds of prototype In-Reply-To: <559E8645.4070104@oracle.com> References: <559E8645.4070104@oracle.com> Message-ID: Hi Brian, Count us in for a hack day when you're happy with the prototype - perhaps we can get an Valhalla commiter along on the day if schedules work out. Cheers, Martijn On Thursday, 9 July 2015, Brian Goetz wrote: > In the next week or two, we'll be pushing parts of our next round of > prototype for anyfied generics. > > > The central complaint about the existing prototype has been the lack of > a common supertype between Foo and Foo, other than Object. > (Much existing code relies on wildcards, for better or worse.) > > Of course, we didn't pursue the original path because we loved the > resulting type system; we pursued this path because it was *what was > possible with the JVM architecture we have*. That's not to say that > changing the JVM is off the table (as it was in Java 5), but doing so is > even more costly than changing the language (which is already quite > expensive), and it would have been irresponsible to pursue VM-centric > options without first exploring what could be done without VM changes. > > Of course, even once "change the VM" is under consideration, there is a > broad spectrum of cost, ranging from "merely extremely expensive" to > "obscenely expensive." So a responsible investigation involves > extensive exploration to identify sensible and cost-effective improvements. > > To that end, we've spent the past several months identifying what we > could do in the VM to enable a useful common supertype for all > instantiations (whether that is spelled "Foo" is a separate > question), and, after several rounds, have pared this down to something > that is conceivably implementable with a tractibly-small set of VM > changes. In the next week or two, we'll be pushing a prototype > implementation of the compiler. We'll follow that up with some new new > documents describing what we've done, and prototypes of some of the VM > features that are needed to plug the holes. I'm sure there are lots of > questions; hopefully they will be answered when we can write it all up. > > As always, the most important feedback we can get is from people *using* > the prototype. We'll post a short summary of the language changes so > folks can play with the prototype more effectively. > > > -- Cheers, Martijn (Sent from Gmail Mobile) From brian.goetz at oracle.com Thu Jul 9 16:05:55 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 9 Jul 2015 12:05:55 -0400 Subject: Next rounds of prototype In-Reply-To: <559E8B65.60505@univ-mlv.fr> References: <559E8645.4070104@oracle.com> <559E8B65.60505@univ-mlv.fr> Message-ID: <559E9BE3.3070209@oracle.com> Yes, that's an important part of the story. I have a long-ish writeup in progress on the subject, please be patient... On 7/9/2015 10:55 AM, Remi Forax wrote: > Am i wrong saying that if it is not spelled List but List, then > there is no backward compatibility issue From pbenedict at apache.org Thu Jul 9 16:13:45 2015 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 9 Jul 2015 11:13:45 -0500 Subject: Rejecting "any" as bounded type name? Message-ID: I know "any" is going to be a context-sensitive keyword, but I wonder if there is merit in restricting "any" as a name of a bounded type name? I don't see much comprehension value in seeing (1) List or (2) List without specialization. I truly dislike syntax puzzlers, and I think my idea would help readability and eliminate gotchas. Thoughts? Cheers, Paul From brian.goetz at oracle.com Thu Jul 9 16:58:32 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 9 Jul 2015 12:58:32 -0400 Subject: Next rounds of prototype In-Reply-To: References: <559E8645.4070104@oracle.com> Message-ID: <559EA838.1060902@oracle.com> Yes -- we're still a bit aways, but when we're ready, we'll take you up on that! On 7/9/2015 11:57 AM, Martijn Verburg wrote: > Hi Brian, > > Count us in for a hack day when you're happy with the prototype - > perhaps we can get an Valhalla commiter along on the day if schedules > work out. > > Cheers, > Martijn > > On Thursday, 9 July 2015, Brian Goetz > wrote: > > In the next week or two, we'll be pushing parts of our next round of > prototype for anyfied generics. > > > The central complaint about the existing prototype has been the lack of > a common supertype between Foo and Foo, other than > Object. (Much existing code relies on wildcards, for better or worse.) > > Of course, we didn't pursue the original path because we loved the > resulting type system; we pursued this path because it was *what was > possible with the JVM architecture we have*. That's not to say that > changing the JVM is off the table (as it was in Java 5), but doing so is > even more costly than changing the language (which is already quite > expensive), and it would have been irresponsible to pursue VM-centric > options without first exploring what could be done without VM changes. > > Of course, even once "change the VM" is under consideration, there is a > broad spectrum of cost, ranging from "merely extremely expensive" to > "obscenely expensive." So a responsible investigation involves > extensive exploration to identify sensible and cost-effective > improvements. > > To that end, we've spent the past several months identifying what we > could do in the VM to enable a useful common supertype for all > instantiations (whether that is spelled "Foo" is a separate > question), and, after several rounds, have pared this down to something > that is conceivably implementable with a tractibly-small set of VM > changes. In the next week or two, we'll be pushing a prototype > implementation of the compiler. We'll follow that up with some new > new documents describing what we've done, and prototypes of some of > the VM features that are needed to plug the holes. I'm sure there > are lots of questions; hopefully they will be answered when we can > write it all up. > > As always, the most important feedback we can get is from people *using* > the prototype. We'll post a short summary of the language changes > so folks can play with the prototype more effectively. > > > > > -- > Cheers, Martijn (Sent from Gmail Mobile) From brian.goetz at oracle.com Thu Jul 9 16:58:06 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 9 Jul 2015 12:58:06 -0400 Subject: Rejecting "any" as bounded type name? In-Reply-To: References: Message-ID: <559EA81E.9060706@oracle.com> It's a fine idea. (Except that its syntax, and we're at least a year away from being ready to talk syntax. Once we clear the several hundred much harder problems between here and there, we can rotate back to syntax.) On 7/9/2015 12:13 PM, Paul Benedict wrote: > I know "any" is going to be a context-sensitive keyword, but I wonder if > there is merit in restricting "any" as a name of a bounded type name? > > I don't see much comprehension value in seeing (1) List or (2) > List without specialization. I truly dislike syntax puzzlers, and I > think my idea would help readability and eliminate gotchas. Thoughts? > > Cheers, > Paul > From brian.goetz at oracle.com Thu Jul 9 18:34:27 2015 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 09 Jul 2015 18:34:27 +0000 Subject: hg: valhalla/valhalla/jdk: Initial strawman for Array supertypes Message-ID: <201507091834.t69IYSN9007487@aojmv0008.oracle.com> Changeset: 73ae1e2cbb20 Author: briangoetz Date: 2015-07-09 14:34 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/73ae1e2cbb20 Initial strawman for Array supertypes + src/java.base/share/classes/java/lang/Arrayish.java + src/java.base/share/classes/java/lang/CrazyArrayish.java ! src/java.base/share/classes/valhalla/specializer/Specialize.java From brian.goetz at oracle.com Thu Jul 9 21:48:47 2015 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 09 Jul 2015 21:48:47 +0000 Subject: hg: valhalla/valhalla/jdk: Add support for distinct() pipeline op (ref only for now) Message-ID: <201507092148.t69Lmmwi011947@aojmv0008.oracle.com> Changeset: 50c0b91568ed Author: briangoetz Date: 2015-07-09 17:48 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/50c0b91568ed Add support for distinct() pipeline op (ref only for now) ! src/java.base/share/classes/java/anyutil/stream/Pipeline.java ! test/valhalla/test/valhalla/anyutil/SimplePipelineTest.java From vlad.ureche at gmail.com Fri Jul 10 04:41:00 2015 From: vlad.ureche at gmail.com (Vlad Ureche) Date: Fri, 10 Jul 2015 06:41:00 +0200 Subject: Next rounds of prototype In-Reply-To: <559E8645.4070104@oracle.com> References: <559E8645.4070104@oracle.com> Message-ID: On Thu, Jul 9, 2015 at 4:33 PM, Brian Goetz wrote: > > The central complaint about the existing prototype has been the lack of > a common supertype between Foo and Foo, other than Object. > (Much existing code relies on wildcards, for better or worse.) > Thanks for letting us know, that's a very exciting turn of events! Erased views for specialized classes (or a different solution that achieves this) will make translating Scala to Valhalla bytecode much easier. Looking forward to playing around with the prototype! Cheers, Vlad From brian.goetz at oracle.com Fri Jul 10 14:15:27 2015 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 10 Jul 2015 14:15:27 +0000 Subject: hg: valhalla/valhalla/jdk: Add missing file DistinctOps Message-ID: <201507101415.t6AEFRdh019832@aojmv0008.oracle.com> Changeset: 2643db397d47 Author: briangoetz Date: 2015-07-10 10:15 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/2643db397d47 Add missing file DistinctOps + src/java.base/share/classes/java/anyutil/stream/DistinctOps.java From maurizio.cimadamore at oracle.com Fri Jul 10 15:12:19 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 10 Jul 2015 15:12:19 +0000 Subject: hg: valhalla/valhalla/jdk: Fix issues with anyutil.DistinctOps: Message-ID: <201507101512.t6AFCJNA029524@aojmv0008.oracle.com> Changeset: 024fbe7d3cfd Author: mcimadamore Date: 2015-07-10 16:12 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/024fbe7d3cfd Fix issues with anyutil.DistinctOps: * fix parameterization of Pipeline * comment @Override on DistinctOps.reparent() * temporarily desugar bound method reference as lambda ! src/java.base/share/classes/java/anyutil/stream/DistinctOps.java From maurizio.cimadamore at oracle.com Fri Jul 10 15:20:09 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 10 Jul 2015 15:20:09 +0000 Subject: hg: valhalla/valhalla/langtools: Enhancement: add support for private constructors in anyfied classes Message-ID: <201507101520.t6AFKA6Z001298@aojmv0008.oracle.com> Changeset: 79986bf4ea64 Author: mcimadamore Date: 2015-07-10 16:19 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/79986bf4ea64 Enhancement: add support for private constructors in anyfied classes * non-generic private constructors of anyfied classes now are translated correctly * added smoke test ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/valhalla/typespec/SpecializedAccessors06.java From maurizio.cimadamore at oracle.com Fri Jul 10 15:22:19 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 10 Jul 2015 15:22:19 +0000 Subject: hg: valhalla/valhalla/jdk: Misc changes: Message-ID: <201507101522.t6AFMJOA001670@aojmv0008.oracle.com> Changeset: f5707f103a09 Author: mcimadamore Date: 2015-07-10 16:22 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f5707f103a09 Misc changes: * remove obsolete test RawAccessTes * revert visibility of Optional constructor to private ! src/java.base/share/classes/java/anyutil/Optional.java - test/valhalla/test/valhalla/specializer/RawAccessTest.java From maurizio.cimadamore at oracle.com Fri Jul 10 17:53:38 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 10 Jul 2015 17:53:38 +0000 Subject: hg: valhalla/valhalla/jdk: Fix: GenericMethodSpecializer picks wrong hostclass when implementation class and receiver class differ Message-ID: <201507101753.t6AHrcgN024222@aojmv0008.oracle.com> Changeset: 0524fbf60cb6 Author: mcimadamore Date: 2015-07-10 18:53 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/0524fbf60cb6 Fix: GenericMethodSpecializer picks wrong hostclass when implementation class and receiver class differ * fixup other cases where MethodHandle checks are not transparent w.r.t. hostclasses * reverted visibility in Pipeline.sourceSpliterator ! src/java.base/share/classes/java/anyutil/stream/Pipeline.java ! src/java.base/share/classes/java/lang/invoke/GenericMethodSpecializer.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/valhalla/test/valhalla/specializer/TestSuperAccess.java From maurizio.cimadamore at oracle.com Mon Jul 13 15:54:31 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 13 Jul 2015 15:54:31 +0000 Subject: hg: valhalla/valhalla/langtools: Enhancement: emit correct value creation sequence Message-ID: <201507131554.t6DFsVAw029963@aojmv0008.oracle.com> Changeset: 0c695d0fee5b Author: mcimadamore Date: 2015-07-13 16:54 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/0c695d0fee5b Enhancement: emit correct value creation sequence contributed-by: michael.haupt at oracle.com ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java From maurizio.cimadamore at oracle.com Mon Jul 13 17:50:39 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 13 Jul 2015 17:50:39 +0000 Subject: hg: valhalla/valhalla/langtools: Enhancement: add support anyfied method references Message-ID: <201507131750.t6DHodWJ021304@aojmv0008.oracle.com> Changeset: d543eb04cb34 Author: mcimadamore Date: 2015-07-13 18:50 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/d543eb04cb34 Enhancement: add support anyfied method references * anyfied method references are desugared into anyfied lambdas * patch LambdaToMethod.MethodReferenceToLambda to generate correct unerased type info during desugaring * added routine in Types to drop non-denotable types from signatures * misc cleanups * added test covering various kinds of method/constructor references ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/valhalla/typespec/Lambda02.java From maurizio.cimadamore at oracle.com Mon Jul 13 17:52:50 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 13 Jul 2015 17:52:50 +0000 Subject: hg: valhalla/valhalla/jdk: Cleanup: revert code to use bound method references instead of lambdas Message-ID: <201507131752.t6DHqpDT021812@aojmv0008.oracle.com> Changeset: 87f1fef5298d Author: mcimadamore Date: 2015-07-13 18:52 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/87f1fef5298d Cleanup: revert code to use bound method references instead of lambdas ! src/java.base/share/classes/java/anyutil/stream/DistinctOps.java ! src/java.base/share/classes/java/anyutil/stream/StreamSpliterators.java From maurizio.cimadamore at oracle.com Tue Jul 14 15:27:09 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 14 Jul 2015 16:27:09 +0100 Subject: updated document on type specialization attributes Message-ID: <55A52A4D.1030709@oracle.com> Hi all, following the recent evolution of the compiler/specializer prototype, I decided to refresh the document covering additional specialization-related bytecode attributes to capture the current state of the translation strategy. While there's nothing radically new, this new document captures all the small changes and adjustments that have been made to the specializer/javac in the last year or so. http://cr.openjdk.java.net/~mcimadamore/specializationAttrs-v0.3.html Cheers Maurizio From scolebourne at joda.org Tue Jul 14 15:30:11 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 14 Jul 2015 16:30:11 +0100 Subject: updated document on type specialization attributes In-Reply-To: <55A52A4D.1030709@oracle.com> References: <55A52A4D.1030709@oracle.com> Message-ID: Thanks for the update. Great to see some additional docs. Stephen On 14 July 2015 at 16:27, Maurizio Cimadamore wrote: > Hi all, > following the recent evolution of the compiler/specializer prototype, I > decided to refresh the document covering additional specialization-related > bytecode attributes to capture the current state of the translation > strategy. While there's nothing radically new, this new document captures > all the small changes and adjustments that have been made to the > specializer/javac in the last year or so. > > http://cr.openjdk.java.net/~mcimadamore/specializationAttrs-v0.3.html > > Cheers > Maurizio From ritterbach at web.de Fri Jul 17 16:06:17 2015 From: ritterbach at web.de (B. Ritterbach) Date: Fri, 17 Jul 2015 18:06:17 +0200 Subject: Value Types in Object-Oriented Programming Languages Message-ID: <55A927F9.6040006@web.de> Hello, Valhalla-dev, I am part of a working group at the University of Hamburg/ Department of Informatics. We are working on "Value Types in Object-Oriented Programming Languages" since many years, actually, decades. Recently I finished my Ph.D. thesis on this subject. Probably some of the ideas from our working group might contribute to value types in Java/ Valhalla? As a comprehensive summary of our value type concept, here the thesis can be downloaded: http://ediss.sub.uni-hamburg.de/frontdoor.php?source_opus=7387 (sorry for the German language). If anybody is interested in this work, or if you have an questions, please feel free to contact me. As an appetizer and a first impression, here is a sample of some of the thesis' essential ideas: 1.) objects and values as fundamentally different concepts: The thesis approaches objects and values from a conceptual perspective. It distinguishes them based on their behavior, independent of a technical implementation: objects are stateful, values are stateless. Therefore values differ from objects by restrictions, by the things they CANNOT do. E. g. values cannot be changed, and (from a conceptual point of view) they can neither be created nor destroyed, value operations cannot produce side effect, etc. (Especially the second restriction - uncreatability - is often neglected by many other papers.) 2.) separation of object types and value types on the language level: Based on the conceptual differences between objects and values, the thesis proposes to support object types and value types on the language level by distinct type constructors (objectClass and valueClass). It focuses on the design of valueClasses and it describes language rules that ensure their value-like behaviour. With this language design, arbitrary value classes can be defined by the programmer. ValueClasses are coded with the same flexibility as an (object)class, and they behave like int in Java. 3.) identity for objects, equality for values: Equality is an essential operation for valueClasses, just as identity is essential for objectClasses. The thesis argues that value equality and object identity can be interpreted as the very same logical concept (though they are implemented differently) and that a programming language should support a single comparison only. 4.) no inheritance for value types: Based on the conceptual properties of values, it can be shown that for valueClasses inheritance does not imply a subtype relation between superclass and subclass. This renders inheritance for valueClasses less useful and more error-prone. For valueClasses a different mechanism (similar to a user-definable widening conversion) can induce a subtype relationship. Additionally, this setting eliminates some problems of object-oriented programming, such as the circle-ellipse-dilemma or the handling of binary methods. 5.) values as a closed subsystem: Object types can use value types, but not vice versa. The value types of a system constitute a closed subsystem. Greetings Beate From simon at ochsenreither.de Fri Jul 17 20:14:49 2015 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Fri, 17 Jul 2015 22:14:49 +0200 (CEST) Subject: Value Types in Object-Oriented Programming Languages In-Reply-To: <55A927F9.6040006@web.de> References: <55A927F9.6040006@web.de> Message-ID: <256465817.26828.1437164089217.JavaMail.open-xchange@srv005.service.ps-server.net> Hi Beate, the thesis looks pretty interesting! I think some of the definitions in the beginning are debatable, but I guess regardless of how you define things, someone will complain one way or another. :-) (E .g. OOP and FP are incompatible, OOP requires mutable state, ...) By the way, there is the return type missing in the code example on p. 139. Value types in your model have bigger restrictions, like referential transparency, no reference types inside value types (which makes them practically pointer-free), no passing or accessing references in value type methods, ... which feels like a larger split introduced into the language, with a mutable, reference-passing model on the one side and an immutable value-passing model on the other side. The automatic validation with isValid is something everyone would love to do I think, but the biggest issue is the difficulty of providing a sane behavior when you create values out of thin air, e.g . with new Array[SomeValueType](100) // substitute with equivalent Java syntax As far as I see, nullability is only mentioned in the "open questions" part, but I feel that differences in handling null can lead to quite different value type designs down the road. Reducing identity/equality to one operation looks like a great simplification, if it can be made to work ... something which I have trouble believing. I guess it really depends on how you define the requirements for equality in your model, and whether you provide a predefined (and maybe not user-overridable implementation) for such operations. With such a large distinction, it's always a question how cumbersome bridging this divide becomes in practice. Achieving compatibility with different value types with inclusion functions restricted to VT -> VT operations looks like a very constrained notion of implicit conversions (which you mention in the paper). From experience, I'm not sure that this subset is actually quite useful. In Scala this subset of implicits is the least useful one and mainly kept for Java compatibility ("implicit widening conversions"). The issue is that these conversions don't scale. Even if Foo -> Bar can be made to work, it's always the question of what happens with Box[Foo] -> Box[Bar]. Either it doesn't work, then it's confusing and inconsistent, and if it was supposed to work, the whole variance complexity enters the debate. Overall, I think there more commonalities than differences between the VTs described in your thesis and what's being implemented, which I guess is a good thing! Nice thesis! Bye, Simon From brian.goetz at oracle.com Fri Jul 17 20:50:33 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 17 Jul 2015 16:50:33 -0400 Subject: Value Types in Object-Oriented Programming Languages In-Reply-To: <256465817.26828.1437164089217.JavaMail.open-xchange@srv005.service.ps-server.net> References: <55A927F9.6040006@web.de> <256465817.26828.1437164089217.JavaMail.open-xchange@srv005.service.ps-server.net> Message-ID: <15552284-5F0C-4B8B-9B6A-3DA4B5022874@oracle.com> > the thesis looks pretty interesting! Indeed, I look forward to stumbling through it with my limited mastery of German. (But not this week, I?m on vacation.) > Value types in your model have bigger restrictions, like referential > transparency, no reference types inside value types (which makes them > practically pointer-free), no passing or accessing references in value type > methods, ... which feels like a larger split introduced into the language, with > a mutable, reference-passing model on the one side and an immutable > value-passing model on the other side. This purity-vs-practicaly crossroads is one that we spent some time staring at as well. Languages like LiMe (designed for GPU computation) take a pure values-all-the-way-down approach, which is appropriate given the target they are aiming at. But such a strict interpretation would be of too limited use for Java ? imagine value types that cannot represent even something as simple as a tuple of (String, String). This compromise does undermine their value-ness, in part, since references are only values relative to the heap they were born with ? and this becomes a visible seam when you serialize + deserialize a value containing a reference. But, it is a compromise we need to live with, just as the primitive-vs-ref divide is a compromise we live with ? because the alternative is impractical. Cheers, -Brian From ritterbach at web.de Sat Jul 18 09:56:17 2015 From: ritterbach at web.de (B. Ritterbach) Date: Sat, 18 Jul 2015 11:56:17 +0200 Subject: Value Types in Object-Oriented Programming Languages In-Reply-To: <256465817.26828.1437164089217.JavaMail.open-xchange@srv005.service.ps-server.net> References: <55A927F9.6040006@web.de> <256465817.26828.1437164089217.JavaMail.open-xchange@srv005.service.ps-server.net> Message-ID: <55AA22C1.6050101@web.de> Hi Simon, thanks for taking a look at my thesis so fast and in so much detail. I try some answers, point by point. >I think some of the definitions in the beginning are debatable, > but I guess regardless of how you define things, someone will complain one way or another. :-) Yes, that's right, it seems virtually impossible to find a common base that everybody would be happy with. The use even of (seemingly) basis concepts it too heterogeneous within the literature. That's why I needed these definitions. They are merely meant to make clear clear what I mean by these words _within the thesis_. > By the way, there is the return type missing in the code example on p. 139. oops, you're right, had not noticed until now. > Value types in your model have bigger restrictions, > like referential transparency, that's true > no reference types inside value types (which makes them practically pointer-free), not exactly. forbidding references within value types is a sufficient, yet not necessary condition to ensure "value-likeness". There are ways to allow object types within the implementation of value types and still find language rules that guarantee the characteristic behavior of values. They would make the language more complex, but some practical use cases may require less tight restrictions. > ... which feels like a larger split introduced into the language, yes, that is the core idea: a two-fold type system, which strictly separates stateful abstractions (objects) and stateless abstractions (values), and as well stateful operations (methods) versus stateless operations (functions). >The automatic validation with isValid is something everyone would love to do I think, > but the biggest issue is the difficulty of providing a sane behavior when you create values out of thin air, > e.g . with new Array[SomeValueType](100) If you "create" a value - or rather, select a value from the value universe - you need to know which one. In the case of an Array with 100 elements, this means you would have to specify each element. However, you can always use a "mutable companion", a kind of builder object that builds the "value" (or rather, its object equivalent) step by step, and when finished, turns it into the "real" value. > As far as I see, nullability is only mentioned in the "open questions" part, > but I feel that differences in handling null can lead to quite different value type designs down the road. yes, I agree, nullability is a big issue. I wonder whether nullability must necessarily be handled by the type system (as many languages do, e .g. MayBe-types in Haskell, etc.). Probably nullability could be designed as a property of a variable (similar to mutability): some variable are defined as nullable, others as non-nullable. I also wonder, whether variables of object types should always be nullable and variables of value types always non-nullabe (as is the case with obects types vs. primitive types in Java). There are some use cases for variables of a value type which are nullable, and also for variables of an object type which are non-nullable. > Reducing identity/equality to one operation looks like a great simplification, > if it can be made to work ... something which I have trouble believing. I tried to argue that it is possible (chapter 8 of the thesis) - based on the assumption that values types and object types are strictly separated, and currently, it looks quite ok. Objections welcome! > I guess it really depends on how you define the requirements for equality in your model The requirements for value equality are stated by the (modified) equality contract (and it also covers object identity). The (modified) equality contract is close to the Java/ Scala equality contract, with slightly more restrictive conditions, and it serves as a unique (and implementation independent) specification for equality (and identity, respectively). I'll circle a paper about the modified contract in the next mail. > and whether you provide a predefined (and maybe not user-overridable implementation) for such operations. Object identity can be predefined by the language (actually, today nearly every OO language does support object identity). For value equality, a standard behavior (that works for many value types) can be predefined by the language. If additionally the language provides a mechanism for "overriding" value equality for cases where the predefined value equality is not appropriate, this would enable sticking to a single comparison operation. (However, for a language that already has 2 or more comparisons, like == and equals in Java), for reasons of upward compatibility it would be cumbersome to switch to that kind of equality/ identity model.) Achieving compatibility with different value types with inclusion functions restricted to VT -> VT operations looks like a very constrained notion of implicit conversions (which you mention in the paper). > an inclusion function is meant as a means for establishing a subtype relation between two value types, and it should be applied only if value type B actually IS a subtype of value type A. That does not necessarily mean that other (less restrictive) implicit conversions do not exist in the language - only that they are not suitable, and not meant for, establishing a subtype relation, and thus be treated differently. >Overall, I think there more commonalities than differences between the VTs described in your thesis >and what's being implemented, which I guess is a good thing! Yes, that's something am really happy about. When we started working on values types (roughly 10 years ago) it looked like something outlandish, very few people were interested in that subject. Now value types (see project Valhalla), and more generally, adding slightly more "functional" elements to OO languages, seems very up to date. I recently had a look at Swift, With classes versus structures Swift has a two-fold type systems, which comes close to the object-value-separation we advocate. I'll dig into Swift closer as soon as i can. There are some details I really want to understand. Bye, Beate On 17.07.2015 22:14, Simon Ochsenreither wrote: > Hi Beate, > > the thesis looks pretty interesting! > > I think some of the definitions in the beginning are debatable, but I > guess regardless of how you define things, someone will complain one > way or another. :-) > (E .g. OOP and FP are incompatible, OOP requires mutable state, ...) > > By the way, there is the return type missing in the code example on p. > 139. > > Value types in your model have bigger restrictions, like referential > transparency, no reference types inside value types (which makes them > practically pointer-free), no passing or accessing references in value > type methods, ... which feels like a larger split introduced into the > language, with a mutable, reference-passing model on the one side and > an immutable value-passing model on the other side. > > The automatic validation with isValid is something everyone would love > to do I think, but the biggest issue is the difficulty of providing a > sane behavior when you create values out of thin air, e.g . with new > Array[SomeValueType](100) // substitute with equivalent Java syntax > As far as I see, nullability is only mentioned in the "open questions" > part, but I feel that differences in handling null can lead to quite > different value type designs down the road. > > Reducing identity/equality to one operation looks like a great > simplification, if it can be made to work ... something which I have > trouble believing. > I guess it really depends on how you define the requirements for > equality in your model, and whether you provide a predefined (and > maybe not user-overridable implementation) for such operations. > > With such a large distinction, it's always a question how cumbersome > bridging this divide becomes in practice. > > Achieving compatibility with different value types with inclusion > functions restricted to VT -> VT operations looks like a very > constrained notion of implicit conversions (which you mention in the > paper). From experience, I'm not sure that this subset is actually > quite useful. In Scala this subset of implicits is the least useful > one and mainly kept for Java compatibility ("implicit widening > conversions"). The issue is that these conversions don't scale. Even > if Foo -> Bar can be made to work, it's always the question of what > happens with Box[Foo] -> Box[Bar]. Either it doesn't work, then it's > confusing and inconsistent, and if it was supposed to work, the whole > variance complexity enters the debate. > > Overall, I think there more commonalities than differences between the > VTs described in your thesis and what's being implemented, which I > guess is a good thing! > > Nice thesis! > > Bye, > > Simon From ritterbach at web.de Sat Jul 18 10:01:01 2015 From: ritterbach at web.de (B. Ritterbach) Date: Sat, 18 Jul 2015 12:01:01 +0200 Subject: Value Types in Object-Oriented Programming Languages In-Reply-To: <15552284-5F0C-4B8B-9B6A-3DA4B5022874@oracle.com> References: <55A927F9.6040006@web.de> <256465817.26828.1437164089217.JavaMail.open-xchange@srv005.service.ps-server.net> <15552284-5F0C-4B8B-9B6A-3DA4B5022874@oracle.com> Message-ID: <55AA23DD.2090206@web.de> Hi Brian, >But such a strict interpretation would be of too limited use for Java I admit, not being bound to restrictions of an existing language made things a bit easier when we were working on the subject. > imagine value types that cannot represent even something as simple as a tuple of (String, String). acually, within our language model, a tuple of (String, String) would be a value type. Also a String type would be a value type within this setting, because of its logical properties (immutable, no creation, operation that are referentially transparent and free of side effect.) As Simon has pointed out, there are many commonalities between value types in Valhalla and value types in the thesis. Probably the only difference: in our model, value types need not necessarily be supported "by value" when they are implemented. Very often this is possible, which makes the implementation fast and efficient, a great collateral benefit. But even if support "by value" is not possible (e. g. for strings or for infinite precision integers) they remain values and are used in a value-like way. Cheers, Beate On 17.07.2015 22:50, Brian Goetz wrote: >> the thesis looks pretty interesting! > Indeed, I look forward to stumbling through it with my limited mastery of German. (But not this week, I?m on vacation.) > >> Value types in your model have bigger restrictions, like referential >> transparency, no reference types inside value types (which makes them >> practically pointer-free), no passing or accessing references in value type >> methods, ... which feels like a larger split introduced into the language, with >> a mutable, reference-passing model on the one side and an immutable >> value-passing model on the other side. > This purity-vs-practicaly crossroads is one that we spent some time staring at as well. Languages like LiMe (designed for GPU computation) take a pure values-all-the-way-down approach, which is appropriate given the target they are aiming at. But such a strict interpretation would be of too limited use for Java ? imagine value types that cannot represent even something as simple as a tuple of (String, String). This compromise does undermine their value-ness, in part, since references are only values relative to the heap they were born with ? and this becomes a visible seam when you serialize + deserialize a value containing a reference. But, it is a compromise we need to live with, just as the primitive-vs-ref divide is a compromise we live with ? because the alternative is impractical. > > Cheers, > -Brian > > > From ritterbach at web.de Sat Jul 18 10:19:58 2015 From: ritterbach at web.de (B. Ritterbach) Date: Sat, 18 Jul 2015 12:19:58 +0200 Subject: Value Types in Object-Oriented Programming Languages In-Reply-To: References: <55A927F9.6040006@web.de> Message-ID: <55AA284E.5060006@web.de> Hi, Vlad, again, I must apologize for not writing the thesis in English. (It would have taken me one year longer at least. No joke, my English writing abilities is horrible and slow. Probably I could try to run the thesis through an automatic translator?) I shall be happy to answer questions or explain the essential parts in English, by writing or talking. A few month ago, we (my supervisor and me) have published a conference article about the separation of value types and object types and its implications on equality and identity. (A so-called "modified equality contract" plays an important role in it.) The article is merely a small part of our work (it roughly corresponds to chapter 8 of the thesis), yet it gives an impression of the way a programming model changes if values and objects are consequently separated. And most important of all - the article is written in English. :-) Here is the link: http://ceur-ws.org/Vol-1337/paper24.pdf Cheers, Beate On 18.07.2015 01:18, Vlad Ureche wrote: > > On Fri, Jul 17, 2015 at 6:06 PM, B. Ritterbach > wrote: > > > As an appetizer and a first impression, here is a sample of some > of the thesis' essential ideas: > > > I wish I understood German... Simon, I envy you so much right now :) > Are there any plans to prepare an English version as well? > > Cheers, > Vlad From maurizio.cimadamore at oracle.com Fri Jul 24 14:46:27 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 24 Jul 2015 14:46:27 +0000 Subject: hg: valhalla/valhalla/langtools: Remove javax.lang.Value class and move it in java.lang Message-ID: <201507241446.t6OEkSko017132@aojmv0008.oracle.com> Changeset: 453597255fd1 Author: mcimadamore Date: 2015-07-24 15:46 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/453597255fd1 Remove javax.lang.Value class and move it in java.lang - src/java.compiler/share/classes/javax/lang/Value.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransValues.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java From maurizio.cimadamore at oracle.com Fri Jul 24 14:47:14 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 24 Jul 2015 14:47:14 +0000 Subject: hg: valhalla/valhalla/jdk: Remove javax.lang.Value class and move it in java.lang Message-ID: <201507241447.t6OElEAM017530@aojmv0008.oracle.com> Changeset: f1ab4b101dc0 Author: mcimadamore Date: 2015-07-24 15:46 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f1ab4b101dc0 Remove javax.lang.Value class and move it in java.lang + src/java.base/share/classes/java/lang/__Value.java From pbenedict at apache.org Fri Jul 24 15:40:08 2015 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 24 Jul 2015 10:40:08 -0500 Subject: hg: valhalla/valhalla/langtools: Remove javax.lang.Value class and move it in java.lang In-Reply-To: <201507241446.t6OEkSko017132@aojmv0008.oracle.com> References: <201507241446.t6OEkSko017132@aojmv0008.oracle.com> Message-ID: I am curious why hashCode(), equals(), and toString() throw UOE as default. If they must be implemented by a subclass, why not mark them as abstract (making Value abstract as well)? Cheers, Paul On Fri, Jul 24, 2015 at 9:46 AM, wrote: > Changeset: 453597255fd1 > Author: mcimadamore > Date: 2015-07-24 15:46 +0100 > URL: > http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/453597255fd1 > > Remove javax.lang.Value class and move it in java.lang > > - src/java.compiler/share/classes/javax/lang/Value.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransValues.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > > From maurizio.cimadamore at oracle.com Fri Jul 24 16:27:43 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 24 Jul 2015 17:27:43 +0100 Subject: hg: valhalla/valhalla/langtools: Remove javax.lang.Value class and move it in java.lang In-Reply-To: References: <201507241446.t6OEkSko017132@aojmv0008.oracle.com> Message-ID: <55B2677F.6080009@oracle.com> All the stuff in __Value is absolutely provisional; I just moved this to the jdk package so that we can keep experimenting with the hotspot changes required for supporting values; we will refine what this class is/means as we go along. For now, the main thing was to mark this class as a value class (that wasn't the case before). Maurizio On 24/07/15 16:40, Paul Benedict wrote: > I am curious why hashCode(), equals(), and toString() throw UOE as > default. If they must be implemented by a subclass, why not mark them > as abstract (making Value abstract as well)? > > > Cheers, > Paul > > On Fri, Jul 24, 2015 at 9:46 AM, > wrote: > > Changeset: 453597255fd1 > Author: mcimadamore > Date: 2015-07-24 15:46 +0100 > URL: > http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/453597255fd1 > > Remove javax.lang.Value class and move it in java.lang > > - src/java.compiler/share/classes/javax/lang/Value.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > ! > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransValues.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > > From mikeb01 at gmail.com Sat Jul 25 02:29:40 2015 From: mikeb01 at gmail.com (Michael Barker) Date: Sat, 25 Jul 2015 14:29:40 +1200 Subject: VarHandles & LMAX Disruptor Message-ID: Hi, I've just ported the Disruptor across from Unsafe to VarHandles[0]. Initially I ran into a whole bunch of issues, but after some time digging realised that they were all of my own making. All of my unit tests pass and the performance tests I've run show very similar results. I think there is a small slowdown (maybe a few %) with VarHandles, but my laptop has a high run to run variance so I can't really be sure until I do some testing on a more stable platform. Even if that is the case, that level is tolerable and I'll most likely release and use internally the VarHandles implementation when JDK9 is available. Excellent work, thanks to Paul Sandoz (and anyone else who worked on the implementation) and Alesky Shiplev for the sandbox instructions. Couple of notes: - The Disruptor is not a heavy (ab)user of the Unsafe - there's no off heap stuff there. The use cases were primarily avoiding the additional costs of AtomicIntArray and AtomicLongFieldUpdater. - I'm a big fan of the style of the API where the use of a concurrent operation is visible at the call site. I think this improves readability and makes it easier to reason about concurrent code. Having to jump to the type declaration to figure out if an assignment operation can affect the visibility/ordering of the code around it increases cognitive load. - I think VarHandle.set/get should be called setRelaxed/getRelaxed as it would make it more obvious to a user and a reader what those methods are going to do. My initial assumption was that they were no different from a normal write/read of a field. Mike. [0] https://github.com/LMAX-Exchange/disruptor/tree/jdk9/ From ali.ebrahimi1781 at gmail.com Sat Jul 25 05:32:39 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Sat, 25 Jul 2015 10:02:39 +0430 Subject: hg: valhalla/valhalla/langtools: Remove javax.lang.Value class and move it in java.lang In-Reply-To: <201507241446.t6OEkSko017132@aojmv0008.oracle.com> References: <201507241446.t6OEkSko017132@aojmv0008.oracle.com> Message-ID: Hi Maurizio, Should not + public final Name javax_lang_Value; to be + public final Name java_lang_Value; On Fri, Jul 24, 2015 at 7:16 PM, wrote: > Changeset: 453597255fd1 > Author: mcimadamore > Date: 2015-07-24 15:46 +0100 > URL: > http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/453597255fd1 > > Remove javax.lang.Value class and move it in java.lang > > - src/java.compiler/share/classes/javax/lang/Value.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransValues.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > > -- Best Regards, Ali Ebrahimi From maurizio.cimadamore at oracle.com Sat Jul 25 14:16:58 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 25 Jul 2015 15:16:58 +0100 Subject: hg: valhalla/valhalla/langtools: Remove javax.lang.Value class and move it in java.lang In-Reply-To: References: <201507241446.t6OEkSko017132@aojmv0008.oracle.com> Message-ID: <55B39A5A.6080609@oracle.com> Whoops - yes. Luckily the important bits are in the string value ;-) Maurizio On 25/07/15 06:32, Ali Ebrahimi wrote: > Hi Maurizio, > > Should not > + public final Name javax_lang_Value; > to be > + public final Name java_lang_Value; > > On Fri, Jul 24, 2015 at 7:16 PM, > wrote: > > Changeset: 453597255fd1 > Author: mcimadamore > Date: 2015-07-24 15:46 +0100 > URL: > http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/453597255fd1 > > Remove javax.lang.Value class and move it in java.lang > > - src/java.compiler/share/classes/javax/lang/Value.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > ! > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransValues.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > > > > > -- > > Best Regards, > Ali Ebrahimi From brian.goetz at oracle.com Sat Jul 25 18:34:56 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 25 Jul 2015 14:34:56 -0400 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: Message-ID: <55B3D6D0.5090709@oracle.com> Thanks for this valuable data point! We are very interested in whatever performance data you have. Obviously the theory is that VarHandles should be highly optimizable by the JIT -- ideally as fast as Unsafe -- but we are very interested in tracking the differences between theory and practice. (We've already found some JIT performance bugs as a result of this effort, and there may be more -- and the earlier we can get the results, the more we can do with it.) Also, it would be great if you could summarize the pitfalls you ran into -- others might be able to benefit from that as well. > - I think VarHandle.set/get should be called setRelaxed/getRelaxed as > it> would make it more obvious to a user and a reader what those > methods are> going to do. My initial assumption was that they were > no different from a> normal write/read of a field. An alternative here is that get/set does whatever the default is for that field (so a volatile field would get ordered access) and {get,set}Relaxed would force a relaxed access (even for volatile fields.) On 7/24/2015 10:29 PM, Michael Barker wrote: > Hi, > > I've just ported the Disruptor across from Unsafe to VarHandles[0]. > Initially I ran into a whole bunch of issues, but after some time > digging realised that they were all of my own making. All of my unit > tests pass and the performance tests I've run show very similar > results. I think there is a small slowdown (maybe a few %) with > VarHandles, but my laptop has a high run to run variance so I can't > really be sure until I do some testing on a more stable platform. > Even if that is the case, that level is tolerable and I'll most > likely release and use internally the VarHandles implementation when > JDK9 is available. > > Excellent work, thanks to Paul Sandoz (and anyone else who worked on > the implementation) and Alesky Shiplev for the sandbox instructions. > > Couple of notes: > > - The Disruptor is not a heavy (ab)user of the Unsafe - there's no > off heap stuff there. The use cases were primarily avoiding the > additional costs of AtomicIntArray and AtomicLongFieldUpdater. - I'm > a big fan of the style of the API where the use of a concurrent > operation is visible at the call site. I think this improves > readability and makes it easier to reason about concurrent code. > Having to jump to the type declaration to figure out if an assignment > operation can affect the visibility/ordering of the code around it > increases cognitive load. - I think VarHandle.set/get should be > called setRelaxed/getRelaxed as it would make it more obvious to a > user and a reader what those methods are going to do. My initial > assumption was that they were no different from a normal write/read > of a field. > > Mike. > > [0] https://github.com/LMAX-Exchange/disruptor/tree/jdk9/ > From mikeb01 at gmail.com Mon Jul 27 08:30:00 2015 From: mikeb01 at gmail.com (Michael Barker) Date: Mon, 27 Jul 2015 20:30:00 +1200 Subject: VarHandles & LMAX Disruptor In-Reply-To: <55B3D6D0.5090709@oracle.com> References: <55B3D6D0.5090709@oracle.com> Message-ID: Hi, We are very interested in whatever performance data you have. Obviously > the theory is that VarHandles should be highly optimizable by the JIT -- > ideally as fast as Unsafe -- but we are very interested in tracking the > differences between theory and practice. (We've already found some JIT > performance bugs as a result of this effort, and there may be more -- > and the earlier we can get the results, the more we can do with it.) > No problem, I'll dig into some of the assembly on the hot paths too. Also, it would be great if you could summarize the pitfalls you ran into > -- others might be able to benefit from that as well. The main difficulty was figuring out which classes to use in the MethodHandles.lookup. The main concurrent class (Sequence [0]) has some slightly funky inheritance in order to support cache line padding, so the actual field that gets modified is not in the Sequence class, but in the superclass. Just using the class that passed as the first argument seemed to work fine. [0] https://github.com/LMAX-Exchange/disruptor/blob/jdk9/src/main/java/com/lmax/disruptor/Sequence.java - I think VarHandle.set/get should be called setRelaxed/getRelaxed as >> it> would make it more obvious to a user and a reader what those >> methods are> going to do. My initial assumption was that they were >> no different from a> normal write/read of a field. >> > > An alternative here is that get/set does whatever the default is for that > field (so a volatile field would get ordered access) and {get,set}Relaxed > would force a relaxed access (even for volatile fields.) That would make sense, however it would preclude the ability to apply a normal load/store to volatile field. Given that a load/stores to volatile fields can have weaker ordering semantics of relaxed or acquire/release via a VarHandle, why not support normal load/stores? It would bring a level of completeness to the API. Or the API could support a setNormal/getNormal. A small comment on the naming. I'm wondering why the name VarHandle? It feels like FieldHandle would be a better name. VarHandle suggests that it would be able to apply it to stack variable, parameters etc? Mike. From brian.goetz at oracle.com Mon Jul 27 14:30:03 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 27 Jul 2015 10:30:03 -0400 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: <55B3D6D0.5090709@oracle.com> Message-ID: <55B6406B.7070109@oracle.com> > A small comment on the naming. I'm wondering why the name VarHandle? > It feels like FieldHandle would be a better name. VarHandle suggests > that it would be able to apply it to stack variable, parameters etc? VarHandle supports access to array elements and off-heap variables as well. Fields are too specific. From brian.goetz at oracle.com Mon Jul 27 14:32:00 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 27 Jul 2015 10:32:00 -0400 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: <55B3D6D0.5090709@oracle.com> Message-ID: <55B640E0.50409@oracle.com> > - I think VarHandle.set/get should be called > setRelaxed/getRelaxed as > it> would make it more obvious to a user and a reader what those > methods are> going to do. My initial assumption was that they were > no different from a> normal write/read of a field. > > An alternative here is that get/set does whatever the default is for > that field (so a volatile field would get ordered access) and > {get,set}Relaxed would force a relaxed access (even for volatile > fields.) > > That would make sense, however it would preclude the ability to apply a > normal load/store to volatile field. Sorry, I wasn't clear. "Alternative" applied to "get rid of get/set" within the context of having an explicit {set,get}Relaxed. In other words, have getters/setters for all the modes, and then define "naked" get/set to mean "whatever is default for this variable. From paul.sandoz at oracle.com Mon Jul 27 15:58:04 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 27 Jul 2015 17:58:04 +0200 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: Message-ID: <5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com> Hi Mike, Thanks for doing this! LMAX was on my radar to try out as i suspected it would likely be very sensitive to any changes, perhaps especially so for array bounds checks. I believe code in RingBuffer was using Unsafe to avoid bounds checks, correct? if so I wonder if the patch in https://bugs.openjdk.java.net/browse/JDK-8003585 would help with strength reducing such checks? I don?t know if that patch also works with a constant offset as used in RingBufferFields, but it should work for MultiProducerSequencer. The patch should apply cleanly to the VarHandles branch in the sandbox if you want to try it out. Ideally what you also need is a public equivalent of @Contended that also supports arrays, that would make the code a little cleaner, but would be a separate project :-) On 25 Jul 2015, at 04:29, Michael Barker wrote: > Hi, > > I've just ported the Disruptor across from Unsafe to VarHandles[0]. > Initially I ran into a whole bunch of issues, but after some time digging > realised that they were all of my own making. All of my unit tests pass > and the performance tests I've run show very similar results. I think > there is a small slowdown (maybe a few %) with VarHandles, but my laptop > has a high run to run variance so I can't really be sure until I do some > testing on a more stable platform. Even if that is the case, that level is > tolerable and I'll most likely release and use internally the VarHandles > implementation when JDK9 is available. > > Excellent work, thanks to Paul Sandoz (and anyone else who worked on the > implementation) and Alesky Shiplev for the sandbox instructions. > Also a big thanks to Aleksey who is also working on the implementation and performance measurements. Paul. > Couple of notes: > > - The Disruptor is not a heavy (ab)user of the Unsafe - there's no off heap > stuff there. The use cases were primarily avoiding the additional costs of > AtomicIntArray and AtomicLongFieldUpdater. > - I'm a big fan of the style of the API where the use of a concurrent > operation is visible at the call site. I think this improves readability > and makes it easier to reason about concurrent code. Having to jump to the > type declaration to figure out if an assignment operation can affect the > visibility/ordering of the code around it increases cognitive load. > - I think VarHandle.set/get should be called setRelaxed/getRelaxed as it > would make it more obvious to a user and a reader what those methods are > going to do. My initial assumption was that they were no different from a > normal write/read of a field. > > Mike. > > [0] https://github.com/LMAX-Exchange/disruptor/tree/jdk9/ From mikeb01 at gmail.com Mon Jul 27 21:04:37 2015 From: mikeb01 at gmail.com (Michael Barker) Date: Tue, 28 Jul 2015 09:04:37 +1200 Subject: VarHandles & LMAX Disruptor In-Reply-To: <55B640E0.50409@oracle.com> References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> Message-ID: On 28 July 2015 at 02:32, Brian Goetz wrote: > - I think VarHandle.set/get should be called >> setRelaxed/getRelaxed as >> it> would make it more obvious to a user and a reader what those >> methods are> going to do. My initial assumption was that they >> were >> no different from a> normal write/read of a field. >> >> An alternative here is that get/set does whatever the default is for >> that field (so a volatile field would get ordered access) and >> {get,set}Relaxed would force a relaxed access (even for volatile >> fields.) >> >> That would make sense, however it would preclude the ability to apply a >> normal load/store to volatile field. >> > > Sorry, I wasn't clear. "Alternative" applied to "get rid of get/set" > within the context of having an explicit {set,get}Relaxed. In other words, > have getters/setters for all the modes, and then define "naked" get/set to > mean "whatever is default for this variable. > If VarHandles supported all access modes (Volatile, Acq/Rel, Relaxed and Normal) with explicit calls and provided "naked" get/set as a default based on the absence/presence of the volatile modifier then that would make for a nice, complete API. Mike. From mikeb01 at gmail.com Mon Jul 27 21:04:54 2015 From: mikeb01 at gmail.com (Michael Barker) Date: Tue, 28 Jul 2015 09:04:54 +1200 Subject: VarHandles & LMAX Disruptor In-Reply-To: <55B6406B.7070109@oracle.com> References: <55B3D6D0.5090709@oracle.com> <55B6406B.7070109@oracle.com> Message-ID: On 28 July 2015 at 02:30, Brian Goetz wrote: > A small comment on the naming. I'm wondering why the name VarHandle? >> It feels like FieldHandle would be a better name. VarHandle suggests >> that it would be able to apply it to stack variable, parameters etc? >> > > VarHandle supports access to array elements and off-heap variables as > well. Fields are too specific. > Good point. From mikeb01 at gmail.com Mon Jul 27 21:35:11 2015 From: mikeb01 at gmail.com (Michael Barker) Date: Tue, 28 Jul 2015 09:35:11 +1200 Subject: VarHandles & LMAX Disruptor In-Reply-To: <5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com> References: <5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com> Message-ID: > > I believe code in RingBuffer was using Unsafe to avoid bounds checks, > correct? if so I wonder if the patch in > https://bugs.openjdk.java.net/browse/JDK-8003585 would help with strength > reducing such checks? I don?t know if that patch also works with a constant > offset as used in RingBufferFields, but it should work for > MultiProducerSequencer. The patch should apply cleanly to the VarHandles > branch in the sandbox if you want to try it out. > Sounds interesting, I'll have a look. Bounds checks weren't at the top of the list for using the Unsafe. We had already started using it for other reasons and made use of that particular optimisation because we could. A little bit of history around the Disruptor and Unsafe, the main reason I started using Unsafe wasn't to do with performance, but "observed" stability. I found on some JVMs APIs like AtomicIntFieldUpdater were less stable on some JVMs than Unsafe. For example on one JVM the JIT didn't treat accesses through a field updater as volatile and would apply optimisations like hoisting from loops which would broke the code. The 10% to 20% performance boost was a nice side benefit. My personal speculation is that most Java licensees reuse the java.util.concurrent library code and provide a decent implementation of Unsafe to make it work, rather than port to their own set of JVM intrinsics. Because of this Unsafe seems to work pretty well on most JVMs. I'm hopeful that java.util.concurrent will be ported across to VarHandles too as it will encourage JVM vendors to have an efficient and stable implementation of VarHandles. > Ideally what you also need is a public equivalent of @Contended that also > supports arrays, that would make the code a little cleaner, but would be a > separate project :-) > That would be nice. One of the other things that is lost with removing the Unsafe is getting the array padding at the ends of array correct. The stuff that I removed used the Unsafe to determine the size of the object reference, which was used to calculate the number of entries required to pad the real data. Now I just pick a value and hope. Mike. From brian.goetz at oracle.com Mon Jul 27 22:57:13 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 27 Jul 2015 18:57:13 -0400 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: <5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com> Message-ID: <55B6B749.7050402@oracle.com> > I'm hopeful that java.util.concurrent will be ported across to > VarHandles too as it will encourage JVM vendors to have an efficient and > stable implementation of VarHandles. That's the plan. Eat our own dog food / lead by example / etc. From mikeb01 at gmail.com Mon Jul 27 23:17:08 2015 From: mikeb01 at gmail.com (Michael Barker) Date: Tue, 28 Jul 2015 11:17:08 +1200 Subject: VarHandles & LMAX Disruptor In-Reply-To: <55B6B749.7050402@oracle.com> References: <5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com> <55B6B749.7050402@oracle.com> Message-ID: > > I'm hopeful that java.util.concurrent will be ported across to >> VarHandles too as it will encourage JVM vendors to have an efficient and >> stable implementation of VarHandles. >> > > That's the plan. Eat our own dog food / lead by example / etc. > Would that work happen in the OpenJDK or would it be built in Doug Lea's repo and copied across? From brian.goetz at oracle.com Mon Jul 27 23:23:09 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 27 Jul 2015 19:23:09 -0400 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: <5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com> <55B6B749.7050402@oracle.com> Message-ID: <55B6BD5D.8050700@oracle.com> > Would that work happen in the OpenJDK or would it be built in Doug Lea's > repo and copied across? Details TBD.... Since Doug's code is used by more than just OpenJDK, there'd have to be two versions somewhere, so we'd have to work out where the fork happens. From paul.sandoz at oracle.com Tue Jul 28 10:26:53 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 28 Jul 2015 12:26:53 +0200 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: <5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com> Message-ID: <6EDDAEEE-6BCF-4C35-B37D-344353AE7C3F@oracle.com> On 27 Jul 2015, at 23:35, Michael Barker wrote: > I believe code in RingBuffer was using Unsafe to avoid bounds checks, correct? if so I wonder if the patch in https://bugs.openjdk.java.net/browse/JDK-8003585 would help with strength reducing such checks? I don?t know if that patch also works with a constant offset as used in RingBufferFields, but it should work for MultiProducerSequencer. The patch should apply cleanly to the VarHandles branch in the sandbox if you want to try it out. > > Sounds interesting, I'll have a look. Bounds checks weren't at the top of the list for using the Unsafe. We had already started using it for other reasons and made use of that particular optimisation because we could. > > A little bit of history around the Disruptor and Unsafe, the main reason I started using Unsafe wasn't to do with performance, but "observed" stability. I found on some JVMs APIs like AtomicIntFieldUpdater were less stable on some JVMs than Unsafe. For example on one JVM the JIT didn't treat accesses through a field updater as volatile and would apply optimisations like hoisting from loops which would broke the code. The 10% to 20% performance boost was a nice side benefit. > Thanks, that is interesting, and somewhat ironic :-) > My personal speculation is that most Java licensees reuse the java.util.concurrent library code and provide a decent implementation of Unsafe to make it work, rather than port to their own set of JVM intrinsics. Because of this Unsafe seems to work pretty well on most JVMs. I'm hopeful that java.util.concurrent will be ported across to VarHandles too as it will encourage JVM vendors to have an efficient and stable implementation of VarHandles. > > Ideally what you also need is a public equivalent of @Contended that also supports arrays, that would make the code a little cleaner, but would be a separate project :-) > > That would be nice. One of the other things that is lost with removing the Unsafe is getting the array padding at the ends of array correct. The stuff that I removed used the Unsafe to determine the size of the object reference, which was used to calculate the number of entries required to pad the real data. Now I just pick a value and hope. > There are stuff like Unsafe.addressSize/pageSize/unalignedAccess/isBigEndian that could be exposed in a public API (the later already is in ByteOrder but that can be somewhat obscure, there might be some other ways in JMX, i have not checked but IMO that is too heavy for getting such constant information). java.lang.Runtime seems a reasonable dumping ground. Paul. From paul.sandoz at oracle.com Tue Jul 28 14:24:32 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 28 Jul 2015 16:24:32 +0200 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> Message-ID: <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> On 27 Jul 2015, at 23:04, Michael Barker wrote: > On 28 July 2015 at 02:32, Brian Goetz wrote: > >> - I think VarHandle.set/get should be called >>> setRelaxed/getRelaxed as >>> it> would make it more obvious to a user and a reader what those >>> methods are> going to do. My initial assumption was that they >>> were >>> no different from a> normal write/read of a field. >>> >>> An alternative here is that get/set does whatever the default is for >>> that field (so a volatile field would get ordered access) and >>> {get,set}Relaxed would force a relaxed access (even for volatile >>> fields.) >>> >>> That would make sense, however it would preclude the ability to apply a >>> normal load/store to volatile field. >>> >> >> Sorry, I wasn't clear. "Alternative" applied to "get rid of get/set" >> within the context of having an explicit {set,get}Relaxed. In other words, >> have getters/setters for all the modes, and then define "naked" get/set to >> mean "whatever is default for this variable. >> > > If VarHandles supported all access modes (Volatile, Acq/Rel, Relaxed and > Normal) with explicit calls and provided "naked" get/set as a default based > on the absence/presence of the volatile modifier then that would make for a > nice, complete API. > I think that?s a good suggestion, worth adding. Stay tuned. Paul. From vitalyd at gmail.com Tue Jul 28 14:56:09 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 28 Jul 2015 10:56:09 -0400 Subject: VarHandles & LMAX Disruptor In-Reply-To: <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> Message-ID: I'll second Mike's suggestion of having VarHandle method names reflect their memory ordering effects, although I don't know if I'd want get/set to use the default based on the presence/absence of volatile modifier. If the API were to expose all supported flavors of ordering, it'd be nice if *all* read/write ops had the effect in the method name. On Tue, Jul 28, 2015 at 10:24 AM, Paul Sandoz wrote: > > On 27 Jul 2015, at 23:04, Michael Barker wrote: > > > On 28 July 2015 at 02:32, Brian Goetz wrote: > > > >> - I think VarHandle.set/get should be called > >>> setRelaxed/getRelaxed as > >>> it> would make it more obvious to a user and a reader what those > >>> methods are> going to do. My initial assumption was that they > >>> were > >>> no different from a> normal write/read of a field. > >>> > >>> An alternative here is that get/set does whatever the default is for > >>> that field (so a volatile field would get ordered access) and > >>> {get,set}Relaxed would force a relaxed access (even for volatile > >>> fields.) > >>> > >>> That would make sense, however it would preclude the ability to apply a > >>> normal load/store to volatile field. > >>> > >> > >> Sorry, I wasn't clear. "Alternative" applied to "get rid of get/set" > >> within the context of having an explicit {set,get}Relaxed. In other > words, > >> have getters/setters for all the modes, and then define "naked" get/set > to > >> mean "whatever is default for this variable. > >> > > > > If VarHandles supported all access modes (Volatile, Acq/Rel, Relaxed and > > Normal) with explicit calls and provided "naked" get/set as a default > based > > on the absence/presence of the volatile modifier then that would make > for a > > nice, complete API. > > > > I think that?s a good suggestion, worth adding. Stay tuned. > > Paul. > > From kirk.pepperdine at gmail.com Tue Jul 28 15:28:33 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 28 Jul 2015 17:28:33 +0200 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> Message-ID: On Jul 28, 2015, at 4:56 PM, Vitaly Davidovich wrote: > I'll second Mike's suggestion of having VarHandle method names reflect > their memory ordering effects, although I don't know if I'd want get/set to > use the default based on the presence/absence of volatile modifier. If the > API were to expose all supported flavors of ordering, it'd be nice if *all* > read/write ops had the effect in the method name. Absolutely, it will have a tremendous positive impact on the readability of the code. Regards, Kirk > > On Tue, Jul 28, 2015 at 10:24 AM, Paul Sandoz > wrote: > >> >> On 27 Jul 2015, at 23:04, Michael Barker wrote: >> >>> On 28 July 2015 at 02:32, Brian Goetz wrote: >>> >>>> - I think VarHandle.set/get should be called >>>>> setRelaxed/getRelaxed as >>>>> it> would make it more obvious to a user and a reader what those >>>>> methods are> going to do. My initial assumption was that they >>>>> were >>>>> no different from a> normal write/read of a field. >>>>> >>>>> An alternative here is that get/set does whatever the default is for >>>>> that field (so a volatile field would get ordered access) and >>>>> {get,set}Relaxed would force a relaxed access (even for volatile >>>>> fields.) >>>>> >>>>> That would make sense, however it would preclude the ability to apply a >>>>> normal load/store to volatile field. >>>>> >>>> >>>> Sorry, I wasn't clear. "Alternative" applied to "get rid of get/set" >>>> within the context of having an explicit {set,get}Relaxed. In other >> words, >>>> have getters/setters for all the modes, and then define "naked" get/set >> to >>>> mean "whatever is default for this variable. >>>> >>> >>> If VarHandles supported all access modes (Volatile, Acq/Rel, Relaxed and >>> Normal) with explicit calls and provided "naked" get/set as a default >> based >>> on the absence/presence of the volatile modifier then that would make >> for a >>> nice, complete API. >>> >> >> I think that?s a good suggestion, worth adding. Stay tuned. >> >> Paul. >> >> From david.lloyd at redhat.com Tue Jul 28 15:35:04 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 28 Jul 2015 10:35:04 -0500 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> Message-ID: <55B7A128.8070005@redhat.com> On 07/28/2015 10:28 AM, Kirk Pepperdine wrote: > > On Jul 28, 2015, at 4:56 PM, Vitaly Davidovich wrote: > >> I'll second Mike's suggestion of having VarHandle method names reflect >> their memory ordering effects, although I don't know if I'd want get/set to >> use the default based on the presence/absence of volatile modifier. If the >> API were to expose all supported flavors of ordering, it'd be nice if *all* >> read/write ops had the effect in the method name. > > Absolutely, it will have a tremendous positive impact on the readability of the code. I agree - VarHandles by nature represent a move away from having "kinds" of variables towards instead having "kinds" of access. No need to muddy those waters with a needless default (under what circumstances would that be useful I wonder?). > > Regards, > Kirk > >> >> On Tue, Jul 28, 2015 at 10:24 AM, Paul Sandoz >> wrote: >> >>> >>> On 27 Jul 2015, at 23:04, Michael Barker wrote: >>> >>>> On 28 July 2015 at 02:32, Brian Goetz wrote: >>>> >>>>> - I think VarHandle.set/get should be called >>>>>> setRelaxed/getRelaxed as >>>>>> it> would make it more obvious to a user and a reader what those >>>>>> methods are> going to do. My initial assumption was that they >>>>>> were >>>>>> no different from a> normal write/read of a field. >>>>>> >>>>>> An alternative here is that get/set does whatever the default is for >>>>>> that field (so a volatile field would get ordered access) and >>>>>> {get,set}Relaxed would force a relaxed access (even for volatile >>>>>> fields.) >>>>>> >>>>>> That would make sense, however it would preclude the ability to apply a >>>>>> normal load/store to volatile field. >>>>>> >>>>> >>>>> Sorry, I wasn't clear. "Alternative" applied to "get rid of get/set" >>>>> within the context of having an explicit {set,get}Relaxed. In other >>> words, >>>>> have getters/setters for all the modes, and then define "naked" get/set >>> to >>>>> mean "whatever is default for this variable. >>>>> >>>> >>>> If VarHandles supported all access modes (Volatile, Acq/Rel, Relaxed and >>>> Normal) with explicit calls and provided "naked" get/set as a default >>> based >>>> on the absence/presence of the volatile modifier then that would make >>> for a >>>> nice, complete API. >>>> >>> >>> I think that?s a good suggestion, worth adding. Stay tuned. >>> >>> Paul. >>> >>> > -- - DML From Mohammad.Rezaei at gs.com Tue Jul 28 16:03:29 2015 From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.) Date: Tue, 28 Jul 2015 12:03:29 -0400 Subject: VarHandles & LMAX Disruptor In-Reply-To: <55B7A128.8070005@redhat.com> References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> <55B7A128.8070005@redhat.com> Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com> I had the same reaction when I first read this, especially because if I wanted to read/assign using the declared default, I'd just use the plain variable. However, there may be use cases outside of concurrency that warrant the "naked" methods, namely as a replacement for reflective Field access in frameworks that need to do that sort of thing. Just my $0.02. Thanks Moh >-----Original Message----- >From: valhalla-dev [mailto:valhalla-dev-bounces at openjdk.java.net] On Behalf Of >David M. Lloyd >Sent: Tuesday, July 28, 2015 11:35 AM >To: valhalla-dev at openjdk.java.net >Subject: Re: VarHandles & LMAX Disruptor > >On 07/28/2015 10:28 AM, Kirk Pepperdine wrote: >> >> On Jul 28, 2015, at 4:56 PM, Vitaly Davidovich wrote: >> >>> I'll second Mike's suggestion of having VarHandle method names reflect >>> their memory ordering effects, although I don't know if I'd want get/set to >>> use the default based on the presence/absence of volatile modifier. If the >>> API were to expose all supported flavors of ordering, it'd be nice if *all* >>> read/write ops had the effect in the method name. >> >> Absolutely, it will have a tremendous positive impact on the readability of >the code. > >I agree - VarHandles by nature represent a move away from having "kinds" >of variables towards instead having "kinds" of access. No need to muddy >those waters with a needless default (under what circumstances would >that be useful I wonder?). > >> >> Regards, >> Kirk >> >>> >>> On Tue, Jul 28, 2015 at 10:24 AM, Paul Sandoz >>> wrote: >>> >>>> >>>> On 27 Jul 2015, at 23:04, Michael Barker wrote: >>>> >>>>> On 28 July 2015 at 02:32, Brian Goetz wrote: >>>>> >>>>>> - I think VarHandle.set/get should be called >>>>>>> setRelaxed/getRelaxed as >>>>>>> it> would make it more obvious to a user and a reader what those >>>>>>> methods are> going to do. My initial assumption was that they >>>>>>> were >>>>>>> no different from a> normal write/read of a field. >>>>>>> >>>>>>> An alternative here is that get/set does whatever the default is for >>>>>>> that field (so a volatile field would get ordered access) and >>>>>>> {get,set}Relaxed would force a relaxed access (even for volatile >>>>>>> fields.) >>>>>>> >>>>>>> That would make sense, however it would preclude the ability to apply a >>>>>>> normal load/store to volatile field. >>>>>>> >>>>>> >>>>>> Sorry, I wasn't clear. "Alternative" applied to "get rid of get/set" >>>>>> within the context of having an explicit {set,get}Relaxed. In other >>>> words, >>>>>> have getters/setters for all the modes, and then define "naked" get/set >>>> to >>>>>> mean "whatever is default for this variable. >>>>>> >>>>> >>>>> If VarHandles supported all access modes (Volatile, Acq/Rel, Relaxed and >>>>> Normal) with explicit calls and provided "naked" get/set as a default >>>> based >>>>> on the absence/presence of the volatile modifier then that would make >>>> for a >>>>> nice, complete API. >>>>> >>>> >>>> I think that?s a good suggestion, worth adding. Stay tuned. >>>> >>>> Paul. >>>> >>>> >> > >-- >- DML From mikeb01 at gmail.com Tue Jul 28 21:53:47 2015 From: mikeb01 at gmail.com (Michael Barker) Date: Wed, 29 Jul 2015 09:53:47 +1200 Subject: VarHandles & LMAX Disruptor In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com> References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> <55B7A128.8070005@redhat.com> <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com> Message-ID: I definitely want all of the explicitly named accessor methods, as the the "naked" get/set with the defaulting behaviour I'm indifferent. Mike. On 29 July 2015 at 04:03, Rezaei, Mohammad A. wrote: > I had the same reaction when I first read this, especially because if I > wanted to read/assign using the declared default, I'd just use the plain > variable. However, there may be use cases outside of concurrency that > warrant the "naked" methods, namely as a replacement for reflective Field > access in frameworks that need to do that sort of thing. > > Just my $0.02. > > Thanks > Moh > > >-----Original Message----- > >From: valhalla-dev [mailto:valhalla-dev-bounces at openjdk.java.net] On > Behalf Of > >David M. Lloyd > >Sent: Tuesday, July 28, 2015 11:35 AM > >To: valhalla-dev at openjdk.java.net > >Subject: Re: VarHandles & LMAX Disruptor > > > >On 07/28/2015 10:28 AM, Kirk Pepperdine wrote: > >> > >> On Jul 28, 2015, at 4:56 PM, Vitaly Davidovich > wrote: > >> > >>> I'll second Mike's suggestion of having VarHandle method names reflect > >>> their memory ordering effects, although I don't know if I'd want > get/set to > >>> use the default based on the presence/absence of volatile modifier. > If the > >>> API were to expose all supported flavors of ordering, it'd be nice if > *all* > >>> read/write ops had the effect in the method name. > >> > >> Absolutely, it will have a tremendous positive impact on the > readability of > >the code. > > > >I agree - VarHandles by nature represent a move away from having "kinds" > >of variables towards instead having "kinds" of access. No need to muddy > >those waters with a needless default (under what circumstances would > >that be useful I wonder?). > > > >> > >> Regards, > >> Kirk > >> > >>> > >>> On Tue, Jul 28, 2015 at 10:24 AM, Paul Sandoz > >>> wrote: > >>> > >>>> > >>>> On 27 Jul 2015, at 23:04, Michael Barker wrote: > >>>> > >>>>> On 28 July 2015 at 02:32, Brian Goetz > wrote: > >>>>> > >>>>>> - I think VarHandle.set/get should be called > >>>>>>> setRelaxed/getRelaxed as > >>>>>>> it> would make it more obvious to a user and a reader what > those > >>>>>>> methods are> going to do. My initial assumption was that > they > >>>>>>> were > >>>>>>> no different from a> normal write/read of a field. > >>>>>>> > >>>>>>> An alternative here is that get/set does whatever the default > is for > >>>>>>> that field (so a volatile field would get ordered access) and > >>>>>>> {get,set}Relaxed would force a relaxed access (even for volatile > >>>>>>> fields.) > >>>>>>> > >>>>>>> That would make sense, however it would preclude the ability to > apply a > >>>>>>> normal load/store to volatile field. > >>>>>>> > >>>>>> > >>>>>> Sorry, I wasn't clear. "Alternative" applied to "get rid of > get/set" > >>>>>> within the context of having an explicit {set,get}Relaxed. In other > >>>> words, > >>>>>> have getters/setters for all the modes, and then define "naked" > get/set > >>>> to > >>>>>> mean "whatever is default for this variable. > >>>>>> > >>>>> > >>>>> If VarHandles supported all access modes (Volatile, Acq/Rel, Relaxed > and > >>>>> Normal) with explicit calls and provided "naked" get/set as a default > >>>> based > >>>>> on the absence/presence of the volatile modifier then that would make > >>>> for a > >>>>> nice, complete API. > >>>>> > >>>> > >>>> I think that?s a good suggestion, worth adding. Stay tuned. > >>>> > >>>> Paul. > >>>> > >>>> > >> > > > >-- > >- DML > From Mohammad.Rezaei at gs.com Tue Jul 28 21:59:45 2015 From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.) Date: Tue, 28 Jul 2015 17:59:45 -0400 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> <55B7A128.8070005@redhat.com> <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com> Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3C36@GSCMAMP06EX.firmwide.corp.gs.com> Sorry if I wasn?t clear: I definitely agree on the explicit naming ; as for the naked ones, I?m slightly biased to keeping them. Thanks Moh From: Michael Barker [mailto:mikeb01 at gmail.com] Sent: Tuesday, July 28, 2015 5:54 PM To: Rezaei, Mohammad A. [Tech] Cc: valhalla-dev at openjdk.java.net Subject: Re: VarHandles & LMAX Disruptor I definitely want all of the explicitly named accessor methods, as the the "naked" get/set with the defaulting behaviour I'm indifferent. Mike. On 29 July 2015 at 04:03, Rezaei, Mohammad A. > wrote: I had the same reaction when I first read this, especially because if I wanted to read/assign using the declared default, I'd just use the plain variable. However, there may be use cases outside of concurrency that warrant the "naked" methods, namely as a replacement for reflective Field access in frameworks that need to do that sort of thing. Just my $0.02. Thanks Moh >-----Original Message----- >From: valhalla-dev [mailto:valhalla-dev-bounces at openjdk.java.net] On Behalf Of >David M. Lloyd >Sent: Tuesday, July 28, 2015 11:35 AM >To: valhalla-dev at openjdk.java.net >Subject: Re: VarHandles & LMAX Disruptor > >On 07/28/2015 10:28 AM, Kirk Pepperdine wrote: >> >> On Jul 28, 2015, at 4:56 PM, Vitaly Davidovich > wrote: >> >>> I'll second Mike's suggestion of having VarHandle method names reflect >>> their memory ordering effects, although I don't know if I'd want get/set to >>> use the default based on the presence/absence of volatile modifier. If the >>> API were to expose all supported flavors of ordering, it'd be nice if *all* >>> read/write ops had the effect in the method name. >> >> Absolutely, it will have a tremendous positive impact on the readability of >the code. > >I agree - VarHandles by nature represent a move away from having "kinds" >of variables towards instead having "kinds" of access. No need to muddy >those waters with a needless default (under what circumstances would >that be useful I wonder?). > >> >> Regards, >> Kirk >> >>> >>> On Tue, Jul 28, 2015 at 10:24 AM, Paul Sandoz > >>> wrote: >>> >>>> >>>> On 27 Jul 2015, at 23:04, Michael Barker > wrote: >>>> >>>>> On 28 July 2015 at 02:32, Brian Goetz > wrote: >>>>> >>>>>> - I think VarHandle.set/get should be called >>>>>>> setRelaxed/getRelaxed as >>>>>>> it> would make it more obvious to a user and a reader what those >>>>>>> methods are> going to do. My initial assumption was that they >>>>>>> were >>>>>>> no different from a> normal write/read of a field. >>>>>>> >>>>>>> An alternative here is that get/set does whatever the default is for >>>>>>> that field (so a volatile field would get ordered access) and >>>>>>> {get,set}Relaxed would force a relaxed access (even for volatile >>>>>>> fields.) >>>>>>> >>>>>>> That would make sense, however it would preclude the ability to apply a >>>>>>> normal load/store to volatile field. >>>>>>> >>>>>> >>>>>> Sorry, I wasn't clear. "Alternative" applied to "get rid of get/set" >>>>>> within the context of having an explicit {set,get}Relaxed. In other >>>> words, >>>>>> have getters/setters for all the modes, and then define "naked" get/set >>>> to >>>>>> mean "whatever is default for this variable. >>>>>> >>>>> >>>>> If VarHandles supported all access modes (Volatile, Acq/Rel, Relaxed and >>>>> Normal) with explicit calls and provided "naked" get/set as a default >>>> based >>>>> on the absence/presence of the volatile modifier then that would make >>>> for a >>>>> nice, complete API. >>>>> >>>> >>>> I think that?s a good suggestion, worth adding. Stay tuned. >>>> >>>> Paul. >>>> >>>> >> > >-- >- DML From vitalyd at gmail.com Tue Jul 28 22:01:33 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 28 Jul 2015 18:01:33 -0400 Subject: VarHandles & LMAX Disruptor In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3C36@GSCMAMP06EX.firmwide.corp.gs.com> References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> <55B7A128.8070005@redhat.com> <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com> <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3C36@GSCMAMP06EX.firmwide.corp.gs.com> Message-ID: Is that in scope though given that VarHandles are really meant to replace Unsafe usage, and I don't see how Unsafe supports that "naked"/default aspect today. On Tue, Jul 28, 2015 at 5:59 PM, Rezaei, Mohammad A. wrote: > Sorry if I wasn?t clear: I definitely agree on the explicit naming ; as > for the naked ones, I?m slightly biased to keeping them. > > Thanks > Moh > > From: Michael Barker [mailto:mikeb01 at gmail.com] > Sent: Tuesday, July 28, 2015 5:54 PM > To: Rezaei, Mohammad A. [Tech] > Cc: valhalla-dev at openjdk.java.net > Subject: Re: VarHandles & LMAX Disruptor > > I definitely want all of the explicitly named accessor methods, as the the > "naked" get/set with the defaulting behaviour I'm indifferent. > > Mike. > > On 29 July 2015 at 04:03, Rezaei, Mohammad A. > wrote: > I had the same reaction when I first read this, especially because if I > wanted to read/assign using the declared default, I'd just use the plain > variable. However, there may be use cases outside of concurrency that > warrant the "naked" methods, namely as a replacement for reflective Field > access in frameworks that need to do that sort of thing. > > Just my $0.02. > > Thanks > Moh > > >-----Original Message----- > >From: valhalla-dev [mailto:valhalla-dev-bounces at openjdk.java.net valhalla-dev-bounces at openjdk.java.net>] On Behalf Of > >David M. Lloyd > >Sent: Tuesday, July 28, 2015 11:35 AM > >To: valhalla-dev at openjdk.java.net > >Subject: Re: VarHandles & LMAX Disruptor > > > >On 07/28/2015 10:28 AM, Kirk Pepperdine wrote: > >> > >> On Jul 28, 2015, at 4:56 PM, Vitaly Davidovich > wrote: > >> > >>> I'll second Mike's suggestion of having VarHandle method names reflect > >>> their memory ordering effects, although I don't know if I'd want > get/set to > >>> use the default based on the presence/absence of volatile modifier. > If the > >>> API were to expose all supported flavors of ordering, it'd be nice if > *all* > >>> read/write ops had the effect in the method name. > >> > >> Absolutely, it will have a tremendous positive impact on the > readability of > >the code. > > > >I agree - VarHandles by nature represent a move away from having "kinds" > >of variables towards instead having "kinds" of access. No need to muddy > >those waters with a needless default (under what circumstances would > >that be useful I wonder?). > > > >> > >> Regards, > >> Kirk > >> > >>> > >>> On Tue, Jul 28, 2015 at 10:24 AM, Paul Sandoz > > >>> wrote: > >>> > >>>> > >>>> On 27 Jul 2015, at 23:04, Michael Barker mikeb01 at gmail.com>> wrote: > >>>> > >>>>> On 28 July 2015 at 02:32, Brian Goetz > wrote: > >>>>> > >>>>>> - I think VarHandle.set/get should be called > >>>>>>> setRelaxed/getRelaxed as > >>>>>>> it> would make it more obvious to a user and a reader what > those > >>>>>>> methods are> going to do. My initial assumption was that > they > >>>>>>> were > >>>>>>> no different from a> normal write/read of a field. > >>>>>>> > >>>>>>> An alternative here is that get/set does whatever the default > is for > >>>>>>> that field (so a volatile field would get ordered access) and > >>>>>>> {get,set}Relaxed would force a relaxed access (even for volatile > >>>>>>> fields.) > >>>>>>> > >>>>>>> That would make sense, however it would preclude the ability to > apply a > >>>>>>> normal load/store to volatile field. > >>>>>>> > >>>>>> > >>>>>> Sorry, I wasn't clear. "Alternative" applied to "get rid of > get/set" > >>>>>> within the context of having an explicit {set,get}Relaxed. In other > >>>> words, > >>>>>> have getters/setters for all the modes, and then define "naked" > get/set > >>>> to > >>>>>> mean "whatever is default for this variable. > >>>>>> > >>>>> > >>>>> If VarHandles supported all access modes (Volatile, Acq/Rel, Relaxed > and > >>>>> Normal) with explicit calls and provided "naked" get/set as a default > >>>> based > >>>>> on the absence/presence of the volatile modifier then that would make > >>>> for a > >>>>> nice, complete API. > >>>>> > >>>> > >>>> I think that?s a good suggestion, worth adding. Stay tuned. > >>>> > >>>> Paul. > >>>> > >>>> > >> > > > >-- > >- DML > > From aleksey.shipilev at oracle.com Tue Jul 28 22:03:01 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 29 Jul 2015 01:03:01 +0300 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> <55B7A128.8070005@redhat.com> <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com> Message-ID: <55B7FC15.1090601@oracle.com> On 07/29/2015 12:53 AM, Michael Barker wrote: > I definitely want all of the explicitly named accessor methods, as the the > "naked" get/set with the defaulting behaviour I'm indifferent. Almost there: https://bugs.openjdk.java.net/browse/JDK-8132471 -Aleksey From paul.sandoz at oracle.com Wed Jul 29 08:53:19 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 Jul 2015 10:53:19 +0200 Subject: VarHandles & LMAX Disruptor In-Reply-To: <55B7FC15.1090601@oracle.com> References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> <55B7A128.8070005@redhat.com> <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com> <55B7FC15.1090601@oracle.com> Message-ID: <25453D48-85A9-4940-B0DE-7DB4FB7A08C4@oracle.com> On 29 Jul 2015, at 00:03, Aleksey Shipilev wrote: > On 07/29/2015 12:53 AM, Michael Barker wrote: >> I definitely want all of the explicitly named accessor methods, as the the >> "naked" get/set with the defaulting behaviour I'm indifferent. > > Almost there: > https://bugs.openjdk.java.net/browse/JDK-8132471 > Thanks!, pushed. I am marginally in favour of the keeping the default accessors. FWIW they have parity with method handle field setters/getters (and of course get/putfield). Vitaly, i think it?s ok to experiment. We can easily remove the default accessors if we eventually conclude these are more of a nuisance. Paul. From chris at hazelcast.com Wed Jul 29 08:57:55 2015 From: chris at hazelcast.com (Christoph Engelbert) Date: Wed, 29 Jul 2015 11:57:55 +0300 Subject: VarHandles & LMAX Disruptor In-Reply-To: <25453D48-85A9-4940-B0DE-7DB4FB7A08C4@oracle.com> References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> <55B7A128.8070005@redhat.com> <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com> <55B7FC15.1090601@oracle.com> <25453D48-85A9-4940-B0DE-7DB4FB7A08C4@oracle.com> Message-ID: <1ECC03A9-9DFA-462E-B171-AC5120CA8393@hazelcast.com> > Am 29.07.2015 um 11:53 schrieb Paul Sandoz : > > > On 29 Jul 2015, at 00:03, Aleksey Shipilev wrote: > >> On 07/29/2015 12:53 AM, Michael Barker wrote: >>> I definitely want all of the explicitly named accessor methods, as the the >>> "naked" get/set with the defaulting behaviour I'm indifferent. >> >> Almost there: >> https://bugs.openjdk.java.net/browse/JDK-8132471 >> > > Thanks!, pushed. > > I am marginally in favour of the keeping the default accessors. FWIW they have parity with method handle field setters/getters (and of course get/putfield). > > Vitaly, i think it?s ok to experiment. We can easily remove the default accessors if we eventually conclude these are more of a nuisance. Not sure I agree, it feels a bit like API smell to have both versions. but yeah they can be removed at any point in time. Chris > Paul. From kirk.pepperdine at gmail.com Wed Jul 29 10:19:51 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Wed, 29 Jul 2015 12:19:51 +0200 Subject: VarHandles & LMAX Disruptor In-Reply-To: <1ECC03A9-9DFA-462E-B171-AC5120CA8393@hazelcast.com> References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> <55B7A128.8070005@redhat.com> <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com> <55B7FC15.1090601@oracle.com> <25453D48-85A9-4940-B0DE-7DB4FB7A08C4@oracle.com> <1ECC03A9-9DFA-462E-B171-AC5120CA8393@hazelcast.com> Message-ID: <6FC29E8F-1AC3-4EDE-885B-FDD08407AA70@gmail.com> On Jul 29, 2015, at 10:57 AM, Christoph Engelbert wrote: >> Am 29.07.2015 um 11:53 schrieb Paul Sandoz : >> >> >> On 29 Jul 2015, at 00:03, Aleksey Shipilev wrote: >> >>> On 07/29/2015 12:53 AM, Michael Barker wrote: >>>> I definitely want all of the explicitly named accessor methods, as the the >>>> "naked" get/set with the defaulting behaviour I'm indifferent. >>> >>> Almost there: >>> https://bugs.openjdk.java.net/browse/JDK-8132471 >>> >> >> Thanks!, pushed. >> >> I am marginally in favour of the keeping the default accessors. FWIW they have parity with method handle field setters/getters (and of course get/putfield). >> >> Vitaly, i think it?s ok to experiment. We can easily remove the default accessors if we eventually conclude these are more of a nuisance. > > Not sure I agree, it feels a bit like API smell to have both versions. but yeah they can be removed at any point in time. Without a backward compatibility issues? At any rate, I always vote for readability so this is a welcome change. FWIW, there is quite a bit of JDK code that would not pass our internal code reviews based on this point. Regards, Kirk From vitalyd at gmail.com Wed Jul 29 10:34:06 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 29 Jul 2015 06:34:06 -0400 Subject: VarHandles & LMAX Disruptor In-Reply-To: <25453D48-85A9-4940-B0DE-7DB4FB7A08C4@oracle.com> References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> <55B7A128.8070005@redhat.com> <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com> <55B7FC15.1090601@oracle.com> <25453D48-85A9-4940-B0DE-7DB4FB7A08C4@oracle.com> Message-ID: Paul, I'd go the other way - leave it out until there's a compelling use case for it. sent from my phone On Jul 29, 2015 4:52 AM, "Paul Sandoz" wrote: > > On 29 Jul 2015, at 00:03, Aleksey Shipilev > wrote: > > > On 07/29/2015 12:53 AM, Michael Barker wrote: > >> I definitely want all of the explicitly named accessor methods, as the > the > >> "naked" get/set with the defaulting behaviour I'm indifferent. > > > > Almost there: > > https://bugs.openjdk.java.net/browse/JDK-8132471 > > > > Thanks!, pushed. > > I am marginally in favour of the keeping the default accessors. FWIW they > have parity with method handle field setters/getters (and of course > get/putfield). > > Vitaly, i think it?s ok to experiment. We can easily remove the default > accessors if we eventually conclude these are more of a nuisance. > > Paul. > From paul.sandoz at oracle.com Wed Jul 29 10:56:17 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 Jul 2015 12:56:17 +0200 Subject: VarHandles & LMAX Disruptor In-Reply-To: <6FC29E8F-1AC3-4EDE-885B-FDD08407AA70@gmail.com> References: <55B3D6D0.5090709@oracle.com> <55B640E0.50409@oracle.com> <314891B5-60D7-4619-89F3-B1BBBE536414@oracle.com> <55B7A128.8070005@redhat.com> <6882C9A35DFB9B4FA2779F7BF5B9757D207EAE3BEE@GSCMAMP06EX.firmwide.corp.gs.com> <55B7FC15.1090601@oracle.com> <25453D48-85A9-4940-B0DE-7DB4FB7A08C4@oracle.com> <1ECC03A9-9DFA-462E-B171-AC5120CA8393@hazelcast.com> <6FC29E8F-1AC3-4EDE-885B-FDD08407AA70@gmail.com> Message-ID: <64D596DA-3ABA-458D-BB6E-5F6FFA1930E4@oracle.com> On 29 Jul 2015, at 12:19, Kirk Pepperdine wrote: >>> >>> I am marginally in favour of the keeping the default accessors. FWIW they have parity with method handle field setters/getters (and of course get/putfield). >>> >>> Vitaly, i think it?s ok to experiment. We can easily remove the default accessors if we eventually conclude these are more of a nuisance. >> >> Not sure I agree, it feels a bit like API smell to have both versions. but yeah they can be removed at any point in time. > > Without a backward compatibility issues? We are talking in the context of pre-Java 9 integration. The API should be locked down once we integrate. Paul. > > At any rate, I always vote for readability so this is a welcome change. FWIW, there is quite a bit of JDK code that would not pass our internal code reviews based on this point. > > Regards, > Kirk > From maurizio.cimadamore at oracle.com Wed Jul 29 13:52:39 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 29 Jul 2015 13:52:39 +0000 Subject: hg: valhalla/valhalla/langtools: Enhancement: generate ValueFactory annotation and method infos for value creation Message-ID: <201507291352.t6TDqduA026923@aojmv0008.oracle.com> Changeset: ee336329195d Author: mcimadamore Date: 2015-07-29 14:52 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ee336329195d Enhancement: generate ValueFactory annotation and method infos for value creation contributed-by: michael.haupt at oracle.com ! src/jdk.compiler/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/jdk.compiler/share/classes/com/sun/tools/classfile/Attribute.java ! src/jdk.compiler/share/classes/com/sun/tools/classfile/ClassWriter.java + src/jdk.compiler/share/classes/com/sun/tools/classfile/ValueFactory_attribute.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Scope.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java ! src/jdk.compiler/share/classes/com/sun/tools/javap/AttributeWriter.java ! test/lib/annotations/annotations/classfile/ClassfileInspector.java ! test/tools/javac/MethodParameters/AttributeVisitor.java ! test/tools/javac/diags/CheckResourceKeys.java From mikeb01 at gmail.com Fri Jul 31 05:43:09 2015 From: mikeb01 at gmail.com (Michael Barker) Date: Fri, 31 Jul 2015 17:43:09 +1200 Subject: VarHandles & LMAX Disruptor In-Reply-To: <5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com> References: <5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com> Message-ID: Hi Paul, I've had a look at the patch that you mentioned and AFAICT it doesn't seem to be able to eliminate the bounds check, even if I remove the array padding. Just to confirm my analysis the assembler around the aaload instruction looks like: 0x00007f627d6b3aea: cmp %ebx,%edx 0x00007f627d6b3aec: jae 0x00007f627d6b3e0c 0x00007f627d6b3af2: mov %r8,%r13 0x00007f627d6b3af5: mov %r11d,%r8d 0x00007f627d6b3af8: mov 0x10(%rax,%rdx,4),%r11d ;*aaload I'm guessing that the cmp/jae pair is the bounds check? A quick note on the patch, it merged, but didn't compile. There seemed to be a signature change on the signature of ConINode::make, so I changed line 1311 in subnode.cpp from 'return ConINode::make(phase->C, 1);' to 'return ConINode::make(1);'. That let it compile, but I don't really understand the code so I'm not sure if it is semantically correct. Mike. On 28 July 2015 at 03:58, Paul Sandoz wrote: > Hi Mike, > > Thanks for doing this! LMAX was on my radar to try out as i suspected it > would likely be very sensitive to any changes, perhaps especially so for > array bounds checks. > > I believe code in RingBuffer was using Unsafe to avoid bounds checks, > correct? if so I wonder if the patch in > https://bugs.openjdk.java.net/browse/JDK-8003585 would help with strength > reducing such checks? I don?t know if that patch also works with a constant > offset as used in RingBufferFields, but it should work for > MultiProducerSequencer. The patch should apply cleanly to the VarHandles > branch in the sandbox if you want to try it out. > > Ideally what you also need is a public equivalent of @Contended that also > supports arrays, that would make the code a little cleaner, but would be a > separate project :-) > > > On 25 Jul 2015, at 04:29, Michael Barker wrote: > > > Hi, > > > > I've just ported the Disruptor across from Unsafe to VarHandles[0]. > > Initially I ran into a whole bunch of issues, but after some time digging > > realised that they were all of my own making. All of my unit tests pass > > and the performance tests I've run show very similar results. I think > > there is a small slowdown (maybe a few %) with VarHandles, but my laptop > > has a high run to run variance so I can't really be sure until I do some > > testing on a more stable platform. Even if that is the case, that level > is > > tolerable and I'll most likely release and use internally the VarHandles > > implementation when JDK9 is available. > > > > Excellent work, thanks to Paul Sandoz (and anyone else who worked on the > > implementation) and Alesky Shiplev for the sandbox instructions. > > > > Also a big thanks to Aleksey who is also working on the implementation and > performance measurements. > > Paul. > > > Couple of notes: > > > > - The Disruptor is not a heavy (ab)user of the Unsafe - there's no off > heap > > stuff there. The use cases were primarily avoiding the additional costs > of > > AtomicIntArray and AtomicLongFieldUpdater. > > - I'm a big fan of the style of the API where the use of a concurrent > > operation is visible at the call site. I think this improves readability > > and makes it easier to reason about concurrent code. Having to jump to > the > > type declaration to figure out if an assignment operation can affect the > > visibility/ordering of the code around it increases cognitive load. > > - I think VarHandle.set/get should be called setRelaxed/getRelaxed as it > > would make it more obvious to a user and a reader what those methods are > > going to do. My initial assumption was that they were no different from > a > > normal write/read of a field. > > > > Mike. > > > > [0] https://github.com/LMAX-Exchange/disruptor/tree/jdk9/ > > From maurizio.cimadamore at oracle.com Fri Jul 31 11:19:39 2015 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 31 Jul 2015 11:19:39 +0000 Subject: hg: valhalla/valhalla/langtools: Misc fix/cleanup: Message-ID: <201507311119.t6VBJdgV004525@aojmv0008.oracle.com> Changeset: 9cd2379d22f2 Author: mcimadamore Date: 2015-07-31 12:19 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/9cd2379d22f2 Misc fix/cleanup: * spurious cyclic inheritance error involving virtual interfaces upon separate compilation * remove unused bytecode mapping cases (getstatic/putstatic) ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java + test/tools/javac/valhalla/typespec/separate05/AnyList.java + test/tools/javac/valhalla/typespec/separate05/Separate05.java From vitalyd at gmail.com Fri Jul 31 11:22:01 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 31 Jul 2015 07:22:01 -0400 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: <5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com> Message-ID: Yes, that looks like range check - can you show the assembly above these lines? What does the java code look like for this test? I think your adjustment to make it compile is fine; http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ae45df3285c9 removed Compile* parameter noting it's unused. sent from my phone On Jul 31, 2015 1:43 AM, "Michael Barker" wrote: > Hi Paul, > > I've had a look at the patch that you mentioned and AFAICT it doesn't seem > to be able to eliminate the bounds check, even if I remove the array > padding. Just to confirm my analysis the assembler around the aaload > instruction looks like: > > 0x00007f627d6b3aea: cmp %ebx,%edx > 0x00007f627d6b3aec: jae 0x00007f627d6b3e0c > 0x00007f627d6b3af2: mov %r8,%r13 > 0x00007f627d6b3af5: mov %r11d,%r8d > 0x00007f627d6b3af8: mov 0x10(%rax,%rdx,4),%r11d ;*aaload > > I'm guessing that the cmp/jae pair is the bounds check? > > A quick note on the patch, it merged, but didn't compile. There seemed to > be a signature change on the signature of ConINode::make, so I changed line > 1311 in subnode.cpp from 'return ConINode::make(phase->C, 1);' to 'return > ConINode::make(1);'. That let it compile, but I don't really understand > the code so I'm not sure if it is semantically correct. > > Mike. > > > > > > > > On 28 July 2015 at 03:58, Paul Sandoz wrote: > > > Hi Mike, > > > > Thanks for doing this! LMAX was on my radar to try out as i suspected it > > would likely be very sensitive to any changes, perhaps especially so for > > array bounds checks. > > > > I believe code in RingBuffer was using Unsafe to avoid bounds checks, > > correct? if so I wonder if the patch in > > https://bugs.openjdk.java.net/browse/JDK-8003585 would help with > strength > > reducing such checks? I don?t know if that patch also works with a > constant > > offset as used in RingBufferFields, but it should work for > > MultiProducerSequencer. The patch should apply cleanly to the VarHandles > > branch in the sandbox if you want to try it out. > > > > Ideally what you also need is a public equivalent of @Contended that also > > supports arrays, that would make the code a little cleaner, but would be > a > > separate project :-) > > > > > > On 25 Jul 2015, at 04:29, Michael Barker wrote: > > > > > Hi, > > > > > > I've just ported the Disruptor across from Unsafe to VarHandles[0]. > > > Initially I ran into a whole bunch of issues, but after some time > digging > > > realised that they were all of my own making. All of my unit tests > pass > > > and the performance tests I've run show very similar results. I think > > > there is a small slowdown (maybe a few %) with VarHandles, but my > laptop > > > has a high run to run variance so I can't really be sure until I do > some > > > testing on a more stable platform. Even if that is the case, that > level > > is > > > tolerable and I'll most likely release and use internally the > VarHandles > > > implementation when JDK9 is available. > > > > > > Excellent work, thanks to Paul Sandoz (and anyone else who worked on > the > > > implementation) and Alesky Shiplev for the sandbox instructions. > > > > > > > Also a big thanks to Aleksey who is also working on the implementation > and > > performance measurements. > > > > Paul. > > > > > Couple of notes: > > > > > > - The Disruptor is not a heavy (ab)user of the Unsafe - there's no off > > heap > > > stuff there. The use cases were primarily avoiding the additional > costs > > of > > > AtomicIntArray and AtomicLongFieldUpdater. > > > - I'm a big fan of the style of the API where the use of a concurrent > > > operation is visible at the call site. I think this improves > readability > > > and makes it easier to reason about concurrent code. Having to jump to > > the > > > type declaration to figure out if an assignment operation can affect > the > > > visibility/ordering of the code around it increases cognitive load. > > > - I think VarHandle.set/get should be called setRelaxed/getRelaxed as > it > > > would make it more obvious to a user and a reader what those methods > are > > > going to do. My initial assumption was that they were no different > from > > a > > > normal write/read of a field. > > > > > > Mike. > > > > > > [0] https://github.com/LMAX-Exchange/disruptor/tree/jdk9/ > > > > > From paul.sandoz at oracle.com Fri Jul 31 12:18:56 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 Jul 2015 14:18:56 +0200 Subject: VarHandles & LMAX Disruptor In-Reply-To: References: <5CF828D3-43E3-4BC9-AE85-9228A073A587@oracle.com> Message-ID: <4D12C838-DB56-4D8C-9EFD-3FB4D1910677@oracle.com> On 31 Jul 2015, at 07:43, Michael Barker wrote: > Hi Paul, > > I've had a look at the patch that you mentioned and AFAICT it doesn't seem to be able to eliminate the bounds check, even if I remove the array padding. Just to confirm my analysis the assembler around the aaload instruction looks like: > > 0x00007f627d6b3aea: cmp %ebx,%edx > 0x00007f627d6b3aec: jae 0x00007f627d6b3e0c > 0x00007f627d6b3af2: mov %r8,%r13 > 0x00007f627d6b3af5: mov %r11d,%r8d > 0x00007f627d6b3af8: mov 0x10(%rax,%rdx,4),%r11d ;*aaload > > I'm guessing that the cmp/jae pair is the bounds check? > Yes, i am assuming that is generated code of RingBuffer.elementAt (aaload) and not MultiProducerSequencer. I suspect the padding is throwing the compiler off the scent (it does not know that indexMask is less than entries.length - BUFFER_INDEX). For an array access such as: int j = i & (a.length - 1); X x = a[j]; I would expect to observe something like: test %edi,%edi jbe ? The bound check should get strength reduced to checking if the array length is zero, and i would expect such a test to be hoisted out of any loop (and get folded into another dominating array length check, if any). Here is an example, given this benchmark method: @Benchmark public int relaxed_r_aa() { Value[] _receiver = receiver; int sum = 0; for (int i = start; i < end; i++) { int j = i & (_receiver.length - 1); sum += _receiver[j].i; } return sum; } Without the patch the following code is generated (when loop unrolling is switched off): : mov 0xc(%r12,%rbx,8),%r9d ;*arraylength : mov %r9d,%r11d : dec %r11d : lea (%r12,%rbx,8),%rcx : xor %eax,%eax ;*iload_3 : mov %r11d,%ebp : and %r10d,%ebp ;*iand : cmp %r9d,%ebp : jae : mov 0x10(%rcx,%rbp,4),%edi ;*aaload : add 0xc(%r12,%rdi,8),%eax ;*iadd : inc %r10d ;*iinc : cmp %r8d,%r10d : jl ;*if_icmpge When the patch is applied the following code is generated: : mov 0xc(%r12,%rbp,8),%r9d ;*arraylength : test %r9d,%r9d : jbe : dec %r9d : lea (%r12,%rbp,8),%r8 : data32 nopw 0x0(%rax,%rax,1) : data32 data32 xchg %ax,%ax ;*iload_3 : mov %r9d,%ebx : and %r11d,%ebx : mov 0x10(%r8,%rbx,4),%ebx ;*aaload : add 0xc(%r12,%rbx,8),%eax ;*iadd : inc %r11d ;*iinc : cmp %r10d,%r11d : jl ;*if_icmpge > A quick note on the patch, it merged, but didn't compile. There seemed to be a signature change on the signature of ConINode::make, so I changed line 1311 in subnode.cpp from 'return ConINode::make(phase->C, 1);' to 'return ConINode::make(1);'. That let it compile, but I don't really understand the code so I'm not sure if it is semantically correct. > Oops sorry about that, i uploaded a new revision of the patch the same fix that you applied. Paul. From brian.goetz at oracle.com Fri Jul 31 19:39:02 2015 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 31 Jul 2015 19:39:02 +0000 Subject: hg: valhalla/valhalla/jdk: Further work on Pipeline and stream factory methods Message-ID: <201507311939.t6VJd2D4021336@aojmv0008.oracle.com> Changeset: a4da1de5481e Author: briangoetz Date: 2015-07-31 15:38 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a4da1de5481e Further work on Pipeline and stream factory methods ! src/java.base/share/classes/java/anyutil/Arrays.java ! src/java.base/share/classes/java/anyutil/stream/DistinctOps.java ! src/java.base/share/classes/java/anyutil/stream/FindOps.java ! src/java.base/share/classes/java/anyutil/stream/ForEachOps.java ! src/java.base/share/classes/java/anyutil/stream/IntStream.java ! src/java.base/share/classes/java/anyutil/stream/MatchOps.java ! src/java.base/share/classes/java/anyutil/stream/Nodes.java ! src/java.base/share/classes/java/anyutil/stream/Pipeline.java ! src/java.base/share/classes/java/anyutil/stream/PipelineHelper.java ! src/java.base/share/classes/java/anyutil/stream/ReduceOps.java ! src/java.base/share/classes/java/anyutil/stream/SpinedBuffer.java ! src/java.base/share/classes/java/anyutil/stream/Stream.java ! src/java.base/share/classes/java/anyutil/stream/StreamOpFlag.java ! src/java.base/share/classes/java/anyutil/stream/StreamSupport.java ! src/java.base/share/classes/java/anyutil/stream/Streams.java ! src/java.base/share/classes/java/anyutil/stream/TerminalOp.java ! src/java.base/share/classes/java/lang/invoke/GenericMethodSpecializer.java ! test/valhalla/test/valhalla/anyutil/SimplePipelineTest.java From brian.goetz at oracle.com Fri Jul 31 19:50:32 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 31 Jul 2015 15:50:32 -0400 Subject: "Model 2" prototype status Message-ID: <55BBD188.8020406@oracle.com> Over the past few months, we've been building what we call our "Model 2" prototype, and incrementally checking it in. It now seems stable enough for brave early adopters to check out. (You'll need to build the JDK from source.) The previous version ("Model 1") was focused on exploring the practicality of specialization on the JVM architecture we have today. The compiler augmented classes with type metadata that otherwise would be erased away, which could be ignored by the JVM but consumed by the specializer. Specialized classes were identified using a name mangling scheme (strictly an expedience for prototyping, not a long-term plan.) The class loader recognizes the name mangling scheme and, if not found in the class path, the class loader invokes the specializer to generate the specialized class on the fly. With these many hacks (name mangling, abuse of class loaders), the result was mixed. On the good side, it worked! It was possible to write specializable generic classes and run them on an only-lightly-hacked JVM. On the bad, the resulting language had a significant usability issue -- the lack of a nontrivial common supertype between Foo and Foo. Of course, we didn't pursue this approach because we thought half-killing wildcards was a great idea; we pursued it because it was what worked on the JVM we had. So with the Model 1 prototype in hand, we set out to see what could be done about providing a reasonable common supertype for all instantiations of an any-generic type. (We explored a number of possible mechanisms and approaches, including several that are more radical than where we landed. Hopefully we will find time to write up some of these roads-not-taken.) Type variables. Type variables are divided into two categories; "ref" (ordinary) and "any". Any tvars ("avars") are identified by the keyword "any" at their declaration site (for both generic classes and generic methods). If a type variable is not modified by "any", it is implicitly an ordinary tvar, and treated just as in Java 8. class Foo { ... } // T is an ordinary tvar class Bar { ... } // T is an avar Class hierarchies can be any-fied from the top down. So it's OK to do: class A { ... } class B extends A { ... } // T is an ordinary tvar here but not OK to do: class A { ... } class B extends A { ... } The rationale for this should be clear enough; specializing a class entails specializing its superclasses, and if the superclass is not specializable, this won't work. (Alternately, you can interpret "any T" as a union bound ("T extends Object | value"), and its OK to use a narrower bound than your supertype, but not a wider one.) Restrictions on avars. Some operations that are allowed on ordinary tvars are not allowed on avars, such as assigning a T to an Object, assigning null to a T, etc. These have not changed from Model 1. Wildcards. The big change in Model 2 is the addition of support for wildcards over avars. The problem with wildcards has two facets; translational (how do we represent a wildcard type over avars in bytecode?) and interpretation (Foo has always been a shorthand for Foo; on the other hand, the "intuitive" intepretation of Foo is "any instantiation of Foo.") The translational issues require some help from the JVM to solve (not yet implemented in the prototype.) The interpretive issues are subtle. While we explored trying to automatically interpret Foo according to the common user intuition, this ran afoul of numerous compatibility issues. So, where we landed is: just as one must specify any-ness at the declaration site for a type variable, one must do the same for a wildcard (which is essentially declaring an anonymous type variable.) So there are two forms of wildcard: Foo -- describes any reference instantiation Foo -- describes any instantiation and Foo will be retconned to mean Foo. Raw types. Raw types have not changed at all from Java 8. As such, they are limited to reference instantiations. The upshot of this is we can achieve perfect source compatibility; the raw type Foo and the wildcard type Foo continues to mean exactly what they always did. As a proof of concept, I've checked in a limited version of Streams (java.anyutil.Stream) that has been ported to the new model. (Some things are still not hooked up yet, but the basic functionality for Stream works.) The Model 2 approach needs some (targeted) help from the VM, which is not yet in place. (Specifically, protected/package methods in interfaces, and some help for access to private members across specializations of the same class.) Until we have this, protected/package methods in anyfied classes will be problematic. There are also some compiler limitations, the most significant of which is that inner classes don't yet work as instantiations of anyfied classes; you have to refactor the inner class to a static named class. (There's no fundamental issue here, its just not done yet.) Most helpfully, the latest IntelliJ has some early support for anyfied generics! (It's not perfect, but its been really helpful -- thanks guys.) Select language level "X" (for experimental) and it will mostly deal with any-tvars and any-wildcards, instead of painting your whole program red. We'd like to get feedback from people *using the prototype* to anyfy their own code. (I'm sure people have a zillion "why did you / why didn't you" questions; we'll try to get to those in a writeup.) I'll also be putting together a writeup on the translation strategy (though brave explorers can and surely will reverse engineer this with javap before this happens.) From ritterbach at informatik.uni-hamburg.de Sat Jul 18 09:43:15 2015 From: ritterbach at informatik.uni-hamburg.de (Beate Ritterbach) Date: Sat, 18 Jul 2015 09:43:15 -0000 Subject: Value Types in Object-Oriented Programming Languages In-Reply-To: References: <55A903A7.7080401@informatik.uni-hamburg.de> <408C0AFD-187D-4D09-9D49-D7B5FB60260B@oracle.com> <55A92024.8080301@informatik.uni-hamburg.de> Message-ID: <55AA1FAC.2030409@informatik.uni-hamburg.de> Hi, John, thanks for your answer. Here some thoughts about your objections: > If this reasoning were applied to the JVM, it would seem that PairValue or OptionalValue could not be instantiated with reference types T or U. The issue of types like PairValue or OptionalValue is indeed a tricky one, because it involves generics. When using a type like PairValue , T and U can be be instantiated both with an object type or a value type. In the definition of type PairValue you cannot access any methods of T and U (except identity/ equality), so the value-like behavior of PairValue cannot be destroyed. Thus from a conceptual point of view everything looks fine. I admit, that this set-up - T sometimes instantiated with an object type (technically: a reference), some other times with a value type (technically: potentially a bit pattern representing the value itself) may be hard to implement. > Maybe in your framework, for cases like that, you need to distinguish an object per se from a reference to the object, and treat T and U as references which require "conversion" to objects via a cast. Within our framework, there is not distinction between an instance and a reference to the instance at all (be the instance a value or an object). To be more precise: no distinction visible to the application programmer. In the underlying implementation, the language environment needs to decide whether a value is implemented directly or via reference, and the decision has to consider the value types definition, especially the size of its representation. Values with "big" representations, or values with unknown representation size - such as strings or infinite precision integers - will need to get implemented with references. Values with "small" representations - like points, dates, complex numbers, rational numbers, monetary amounts - may be implemented directly. Cheers, Beate