From maurizio.cimadamore at oracle.com Mon Apr 11 14:08:47 2016 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 11 Apr 2016 14:08:47 +0000 Subject: hg: valhalla/valhalla/langtools: Initial push for nestmate support Message-ID: <201604111408.u3BE8lMH009272@aojmv0008.oracle.com> Changeset: 3197e9b4d80a Author: mcimadamore Date: 2016-04-11 15:08 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/3197e9b4d80a Initial push for nestmate support * Add support for nestmate classfile attributes: NestMembers, MemberOfNest * Internal flag -XDdisableAccessors can be used to inhibit static accessor generation ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/MemberOfNest_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/NestMembers_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! test/lib/annotations/annotations/classfile/ClassfileInspector.java ! test/tools/javac/MethodParameters/AttributeVisitor.java + test/tools/javac/valhalla/nestmate/CheckNestmateAttrs.java From maurizio.cimadamore at oracle.com Fri Apr 15 16:24:44 2016 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 15 Apr 2016 16:24:44 +0000 Subject: hg: valhalla/valhalla/langtools: Enhancement: add M3 generic pool entries harness Message-ID: <201604151624.u3FGOiZV026921@aojmv0008.oracle.com> Changeset: f18dc3fd0496 Author: mcimadamore Date: 2016-04-15 17:24 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/f18dc3fd0496 Enhancement: add M3 generic pool entries harness Fix: build script is not building jshell correctly Fix: alt generic method translation fails to rewrite all typevars Fix: limit generation of redundant generic pool entries in M3 translation ! make/build.properties ! make/build.xml ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java + test/tools/javac/valhalla/typespec/items/m3/Opcodes.java + test/tools/javac/valhalla/typespec/items/m3/PoolMapping.java + test/tools/javac/valhalla/typespec/items/m3/PoolMappingHarness.java + test/tools/javac/valhalla/typespec/items/m3/TemplateMethod.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestAnyMembers.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestArrayLoadAndStore.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestBinary.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestCapture.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestCast.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestClassLit.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestCmp.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestDefault.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestDup.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestForeach.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestGeneric2GenericCall.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestGenericSpecializedConstructor.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestIndy.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestIndyErasure.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestIndyFactory.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestInheritedAnyMembers.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestInner.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestInstanceof.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestLambda.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestLoadAndStore.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestNestedGenerics.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestNew.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestNewArray.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestNonSpecializedGenericCall.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestNonSpecializedMethod.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestPop.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestRefOnly.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestRespecialization.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestSuper.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestSyntheticCast.java + test/tools/javac/valhalla/typespec/items/m3/tests/TestValOnly.java From maurizio.cimadamore at oracle.com Mon Apr 18 16:33:24 2016 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 18 Apr 2016 16:33:24 +0000 Subject: hg: valhalla/valhalla/langtools: Enable M3 translation by default Message-ID: <201604181633.u3IGXOhu022215@aojmv0008.oracle.com> Changeset: 961eb443422f Author: mcimadamore Date: 2016-04-18 17:33 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/961eb443422f Enable M3 translation by default Cleanup code associated with BytecodeMapping-based specialization. ! 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/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/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! test/tools/javac/diags/examples/CantSelectNonVirtual.java ! test/tools/javac/valhalla/typespec/GenericClassFile01.java ! test/tools/javac/valhalla/typespec/GenericClassFile02.java ! test/tools/javac/valhalla/typespec/GenericClassFile03.java ! test/tools/javac/valhalla/typespec/GenericClassFile04.java ! test/tools/javac/valhalla/typespec/GenericClassFile05.java ! test/tools/javac/valhalla/typespec/GenericClassFile06.java ! test/tools/javac/valhalla/typespec/GenericMethod01.java ! test/tools/javac/valhalla/typespec/GenericMethod02.java ! test/tools/javac/valhalla/typespec/GenericMethod03.java ! test/tools/javac/valhalla/typespec/GenericPool01.java ! test/tools/javac/valhalla/typespec/Lambda01.java ! test/tools/javac/valhalla/typespec/Lambda03.java ! test/tools/javac/valhalla/typespec/SpecializedAccessors3.java ! test/tools/javac/valhalla/typespec/SpecializedAccessors5.java - test/tools/javac/valhalla/typespec/TestSuperBridges.java ! test/tools/javac/valhalla/typespec/Wildcards08.java ! test/tools/javac/valhalla/typespec/Wildcards08.out ! test/tools/javac/valhalla/typespec/Wildcards11.java - test/tools/javac/valhalla/typespec/items/BytecodeMapping.java - test/tools/javac/valhalla/typespec/items/BytecodeMappingHarness.java - test/tools/javac/valhalla/typespec/items/Opcodes.java - test/tools/javac/valhalla/typespec/items/TemplateMethod.java ! test/tools/javac/valhalla/typespec/items/m3/PoolMappingHarness.java - test/tools/javac/valhalla/typespec/items/tests/TestAnyMembers.java - test/tools/javac/valhalla/typespec/items/tests/TestArrayLoadAndStore.java - test/tools/javac/valhalla/typespec/items/tests/TestBinary.java - test/tools/javac/valhalla/typespec/items/tests/TestCapture.java - test/tools/javac/valhalla/typespec/items/tests/TestCast.java - test/tools/javac/valhalla/typespec/items/tests/TestClassLit.java - test/tools/javac/valhalla/typespec/items/tests/TestCmp.java - test/tools/javac/valhalla/typespec/items/tests/TestDefault.java - test/tools/javac/valhalla/typespec/items/tests/TestDup.java - test/tools/javac/valhalla/typespec/items/tests/TestForeach.java - test/tools/javac/valhalla/typespec/items/tests/TestGeneric2GenericCall.java - test/tools/javac/valhalla/typespec/items/tests/TestGenericSpecializedConstructor.java - test/tools/javac/valhalla/typespec/items/tests/TestIndy.java - test/tools/javac/valhalla/typespec/items/tests/TestIndyErasure.java - test/tools/javac/valhalla/typespec/items/tests/TestIndyFactory.java - test/tools/javac/valhalla/typespec/items/tests/TestInheritedAnyMembers.java - test/tools/javac/valhalla/typespec/items/tests/TestInner.java - test/tools/javac/valhalla/typespec/items/tests/TestInstanceof.java - test/tools/javac/valhalla/typespec/items/tests/TestLambda.java - test/tools/javac/valhalla/typespec/items/tests/TestLoadAndStore.java - test/tools/javac/valhalla/typespec/items/tests/TestNestedGenerics.java - test/tools/javac/valhalla/typespec/items/tests/TestNew.java - test/tools/javac/valhalla/typespec/items/tests/TestNewArray.java - test/tools/javac/valhalla/typespec/items/tests/TestNonSpecializedGenericCall.java - test/tools/javac/valhalla/typespec/items/tests/TestNonSpecializedMethod.java - test/tools/javac/valhalla/typespec/items/tests/TestPop.java - test/tools/javac/valhalla/typespec/items/tests/TestRefOnly.java - test/tools/javac/valhalla/typespec/items/tests/TestRespecialization.java - test/tools/javac/valhalla/typespec/items/tests/TestSuper.java - test/tools/javac/valhalla/typespec/items/tests/TestSyntheticCast.java - test/tools/javac/valhalla/typespec/items/tests/TestValOnly.java ! test/tools/javac/valhalla/typespec/separate06/Separate06.java ! test/tools/javac/valhalla/typespec/separate07/Separate07.java ! test/tools/javac/valhalla/values/CheckNoDups.java ! test/tools/javac/valhalla/values/CheckValueBuffersAny.java From maurizio.cimadamore at oracle.com Mon Apr 18 16:33:58 2016 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 18 Apr 2016 16:33:58 +0000 Subject: hg: valhalla/valhalla/jdk: Enable M3 translation by default Message-ID: <201604181633.u3IGXxso022375@aojmv0008.oracle.com> Changeset: f0f28425e3e8 Author: mcimadamore Date: 2016-04-18 17:33 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f0f28425e3e8 Enable M3 translation by default Cleanup code associated with BytecodeMapping-based specialization. ! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/DispatchContext.java ! src/java.base/share/classes/java/lang/invoke/GenericInstanceDispatch.java - src/java.base/share/classes/java/lang/invoke/GenericMethodSpecializer.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/valhalla/classdyn/ClassDynHelper.java - src/java.base/share/classes/valhalla/classdyn/Mangler.java - src/java.base/share/classes/valhalla/specializer/BridgeAttribute.java - src/java.base/share/classes/valhalla/specializer/BytecodeMappingAttribute.java - src/java.base/share/classes/valhalla/specializer/DebuggingSignatureVisitor.java - src/java.base/share/classes/valhalla/specializer/SignatureSpecializer.java - src/java.base/share/classes/valhalla/specializer/Specialize.java - src/java.base/share/classes/valhalla/specializer/Specializer.java - src/java.base/share/classes/valhalla/specializer/SpecializerSignature.java - src/java.base/share/classes/valhalla/specializer/TypeVariablesMapAttribute.java - src/java.base/share/classes/valhalla/specializer/WhereAttribute.java ! test/valhalla/PrespecializerTest.java - test/valhalla/boottest/valhalla/specializer/SignatureSpecializerTest.java ! test/valhalla/test/valhalla/anyutil/CollectionsTest.java ! test/valhalla/test/valhalla/anyutil/SimplePipelineTest.java - test/valhalla/test/valhalla/classdyn/ManglerTest.java ! test/valhalla/test/valhalla/specializer/BoxTest.java ! test/valhalla/test/valhalla/specializer/DefaultValueTest.java ! test/valhalla/test/valhalla/specializer/GenericMethodsTest.java ! test/valhalla/test/valhalla/specializer/MiscManglingsTest.java ! test/valhalla/test/valhalla/specializer/MixedTypesTest.java ! test/valhalla/test/valhalla/specializer/MultiBoxTest.java ! test/valhalla/test/valhalla/specializer/ObjectMethodsTest.java - test/valhalla/test/valhalla/specializer/SignatureVisitorTest.java ! test/valhalla/test/valhalla/specializer/SpecializationMetadataTest.java ! test/valhalla/test/valhalla/specializer/TwoBoxTest.java ! test/valhalla/test/valhalla/specializer/WhereTest.java From maurizio.cimadamore at oracle.com Mon Apr 18 16:42:29 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 18 Apr 2016 17:42:29 +0100 Subject: generic classfile enabled by default Message-ID: <57150E75.9020000@oracle.com> Hi all, I've just pushed few patches to enable the new generic classfile format by default (previously the new classfile format was only generated when using the hidden -XDgenericClassFile flag). This is a biggie change, and many adaptations (pushed over the last month) were required for the JDK to function and specialize classes correctly. Most test frameworks have been rewritten in order to work in this new world, and such tests are currently all green - meaning that the new translation scheme should work reasonably well; one notable case where you can notice missing functionality is related to double-slot specialization (i.e. create an instance of Box) which is currently unsupported - this will require VM support and will come at a later stage. Should you find any issue in making your existing examples work in this new world, please do not hesitate to let me know on this very list. Cheers Maurizio From david.simms at oracle.com Thu Apr 21 09:04:25 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 21 Apr 2016 09:04:25 +0000 Subject: hg: valhalla/valhalla/jdk: Array load/store bytecodes mangling Message-ID: <201604210904.u3L94PsZ021756@aojmv0008.oracle.com> Changeset: 10e2de50a300 Author: dsimms Date: 2016-04-21 10:47 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/10e2de50a300 Array load/store bytecodes mangling ! src/java.base/share/classes/valhalla/model3/Model3Converter.java From maurizio.cimadamore at oracle.com Thu Apr 21 16:52:03 2016 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 21 Apr 2016 16:52:03 +0000 Subject: hg: valhalla/valhalla/langtools: Fix: abstract conditional methods are missing ACC_ABSTRACT Message-ID: <201604211652.u3LGq36G022138@aojmv0008.oracle.com> Changeset: 9bec39f205ed Author: mcimadamore Date: 2016-04-21 17:51 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/9bec39f205ed Fix: abstract conditional methods are missing ACC_ABSTRACT Fix: Methodref emitted instead of InterfaceMethodref when receiver is type-var with interface bound Fix: String concatenation doesn't work on any type-variables ! 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/SpecializeTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java From maurizio.cimadamore at oracle.com Thu Apr 21 16:57:58 2016 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 21 Apr 2016 16:57:58 +0000 Subject: hg: valhalla/valhalla/jdk: Fix: inner classes should not get M3 mangling if no type parameter is present anywhere Message-ID: <201604211657.u3LGvxMB024713@aojmv0008.oracle.com> Changeset: 64db0365ed01 Author: mcimadamore Date: 2016-04-21 17:57 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/64db0365ed01 Fix: inner classes should not get M3 mangling if no type parameter is present anywhere Enhancement: add -Xverify:all to PrespecializerTest ! src/java.base/share/classes/valhalla/model3/Model3Converter.java ! test/valhalla/PrespecializerTest.java From maurizio.cimadamore at oracle.com Tue Apr 26 14:48:34 2016 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 26 Apr 2016 14:48:34 +0000 Subject: hg: valhalla/valhalla/langtools: Fix: signatures of polysig methods are erased prematurely Message-ID: <201604261448.u3QEmYVH009010@aojmv0008.oracle.com> Changeset: 162ea1f3dfd9 Author: mcimadamore Date: 2016-04-26 15:48 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/162ea1f3dfd9 Fix: signatures of polysig methods are erased prematurely ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/valhalla/typespec/MethodHandle01.java From david.simms at oracle.com Wed Apr 27 12:50:30 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Wed, 27 Apr 2016 12:50:30 +0000 Subject: hg: valhalla/valhalla: Arrays implement the Arrayish interface Message-ID: <201604271250.u3RCoUdB021949@aojmv0008.oracle.com> Changeset: 52bd1d878467 Author: dsimms Date: 2016-04-27 14:49 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/52bd1d878467 Arrays implement the Arrayish interface ! make/CompileJavaModules.gmk ! make/Images.gmk From david.simms at oracle.com Wed Apr 27 12:50:39 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Wed, 27 Apr 2016 12:50:39 +0000 Subject: hg: valhalla/valhalla/hotspot: Arrays implement the Arrayish interface Message-ID: <201604271250.u3RCodH9022023@aojmv0008.oracle.com> Changeset: 4067612e9978 Author: dsimms Date: 2016-04-27 14:49 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4067612e9978 Arrays implement the Arrayish interface ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! test/TEST.groups + test/runtime/valhalla/arrays/ArrayTypes.java From david.simms at oracle.com Wed Apr 27 12:50:53 2016 From: david.simms at oracle.com (david.simms at oracle.com) Date: Wed, 27 Apr 2016 12:50:53 +0000 Subject: hg: valhalla/valhalla/jdk: Arrays implement the Arrayish interface Message-ID: <201604271250.u3RCor32022143@aojmv0008.oracle.com> Changeset: c82dff06b0d6 Author: dsimms Date: 2016-04-27 14:49 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/c82dff06b0d6 Arrays implement the Arrayish interface ! src/java.base/share/classes/java/lang/Arrayish.java ! src/java.base/share/classes/valhalla/model3/Model3Converter.java From david.simms at oracle.com Wed Apr 27 12:52:41 2016 From: david.simms at oracle.com (David Simms) Date: Wed, 27 Apr 2016 14:52:41 +0200 Subject: Arrays now implement "Arrayish" Message-ID: <5720B619.3030002@oracle.com> Greetings, I've just pushed a set of changes to enable all arrays to implement the "java.lang.Arrayish" interface: public interface Arrayish extends Cloneable, java.io.Serializable { int arraySize(); T arrayGet(int index); void arraySet(int index, T element); } Thanks to John Rose for the original patch, which I have adapted somewhat. How does it work ? * "Klass->extra_super()" contains an optional "InstanceKlass*" pointer, which all array klasses have set to their appropriate Arrayish, i.e.: o int[] extra_super() = "Arrayish" o Object[] extra_super() = "Arrayish" * Classes used as "extra_super" must currently be interfaces, and have their own "self itable" generated at load time. * The extra_super mechanism allows the "Arrayish" interface to be injected during JVM start-up, but after the basic array types need to be initialized * "extra_super()" is used when, checkcast/instanceof and looking up interface methods * See jtreg test: "hotspot/runtime/valhalla/arrays/ArrayTypes.java" This is a prototype, there are caveats (and dragons): * The current "Model 3" implementation uses a specializer written in Java, for bootstrapping the Arrayish specializations, these are currently built at JDK compile time (placed "$JAVA_HOME/valhalla-prespecialized") o There is no support yet for double slot types (double and long, and hence their arrays) o These classes are specific to the JVM runtime, and must not be seen by "javac" ( "VALHALLA_PRESPECIALIZED_DIR" is known to the classloader implementation, but not the classpath). * x86 32 & 64 bit architectures only at this point o arrays on other architectures will simply not implement "Arrayish" * Nothing about this implementation is set in stone, prototype code and quality (piggy-backing on these changes, then ymmv) * The type hierarchy for arrays will no doubt continue to be in flux Cheers /David Simms From pbenedict at apache.org Wed Apr 27 14:18:11 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 27 Apr 2016 09:18:11 -0500 Subject: Why Arrayish implements Cloneable? Message-ID: I only ask because Cloneable is typically looked at as a poor mechanism for duplicating objects. That's the sentiment, anyway, widely popularized by the Effective Java book. Cheers, Paul From brian.goetz at oracle.com Wed Apr 27 14:25:21 2016 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 27 Apr 2016 10:25:21 -0400 Subject: Why Arrayish implements Cloneable? In-Reply-To: References: Message-ID: <5720CBD1.9080700@oracle.com> Because array types (int[], String[]) *already* implement Cloneable and Serializable. On 4/27/2016 10:18 AM, Paul Benedict wrote: > I only ask because Cloneable is typically looked at as a poor mechanism for > duplicating objects. That's the sentiment, anyway, widely popularized by > the Effective Java book. > > Cheers, > Paul From pbenedict at apache.org Wed Apr 27 14:32:10 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 27 Apr 2016 09:32:10 -0500 Subject: Why Arrayish implements Cloneable? In-Reply-To: <5720CBD1.9080700@oracle.com> References: <5720CBD1.9080700@oracle.com> Message-ID: Oh, okay ... so basically when you let the native "any" type be boxed, you're exposing the same functionality through an interface. Cheers, Paul On Wed, Apr 27, 2016 at 9:25 AM, Brian Goetz wrote: > Because array types (int[], String[]) *already* implement Cloneable and > Serializable. > > > > > > On 4/27/2016 10:18 AM, Paul Benedict wrote: > >> I only ask because Cloneable is typically looked at as a poor mechanism >> for >> duplicating objects. That's the sentiment, anyway, widely popularized by >> the Effective Java book. >> >> Cheers, >> Paul >> > > From brian.goetz at oracle.com Wed Apr 27 14:45:56 2016 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 27 Apr 2016 10:45:56 -0400 Subject: Why Arrayish implements Cloneable? In-Reply-To: References: <5720CBD1.9080700@oracle.com> Message-ID: <5720D0A4.9070607@oracle.com> Currently, the array classes (int[].class, String[].class) are totally magical and spring into existence when referenced. They all happen to have some common supertypes (Cloneable, Serializable). This patch moves things forward incrementally (see John's talk on Arrays 2.0, http://medianetwork.oracle.com/video/player/1785452137001) by providing all arrays with a real supertype, Arrayish, which exposes element accessors. This allows, for example, abstraction over array types (), as well as being a precursor to some other cool stuff. On 4/27/2016 10:32 AM, Paul Benedict wrote: > Oh, okay ... so basically when you let the native "any" type be boxed, > you're exposing the same functionality through an interface. > > Cheers, > Paul > > On Wed, Apr 27, 2016 at 9:25 AM, Brian Goetz > wrote: > > Because array types (int[], String[]) *already* implement > Cloneable and Serializable. > > > > > > On 4/27/2016 10:18 AM, Paul Benedict wrote: > > I only ask because Cloneable is typically looked at as a poor > mechanism for > duplicating objects. That's the sentiment, anyway, widely > popularized by > the Effective Java book. > > Cheers, > Paul > > > From john.r.rose at oracle.com Wed Apr 27 20:06:17 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 27 Apr 2016 13:06:17 -0700 Subject: Why Arrayish implements Cloneable? In-Reply-To: <5720D0A4.9070607@oracle.com> References: <5720CBD1.9080700@oracle.com> <5720D0A4.9070607@oracle.com> Message-ID: A2.0 entails splitting current types of the form T[] in into interfaces and implementations. That is, in a future VM we will have polymorphic, generic interfaces (Arrayish, etc.) and built-in linearly stored implementations of the same, what we are familiar with as "classic arrays". We *could* deem that either or both of the marker interfaces Serializable and Cloneable on all T[] are, in fact, implementation artifacts, limited to classic arrays, and not pushed into the generic APIs. In fact, on second thought, we *should* do this for Cloneable, since it is not an API. The generic method clone()T[] is part of the array API, but it is not at all dependent on Cloneable. What about Serializable? Perhaps we can mandate (another way) that all Arrayish's will be serializable, without putting in the marker interface. But I think that's a losing battle. It might in fact be the case that many (or even all?) array implementations would chose to include both Cloneable and Serializable, but that's not necessarily true in all possible worlds. ? John P.S. I was reading Smullyan on modal logic last night, hence the modal connective in that last statement. On Apr 27, 2016, at 7:45 AM, Brian Goetz wrote: > > Currently, the array classes (int[].class, String[].class) are totally magical and spring into existence when referenced. They all happen to have some common supertypes (Cloneable, Serializable). > > This patch moves things forward incrementally (see John's talk on Arrays 2.0, http://medianetwork.oracle.com/video/player/1785452137001) by providing all arrays with a real supertype, Arrayish, which exposes element accessors. This allows, for example, abstraction over array types (), as well as being a precursor to some other cool stuff. > > On 4/27/2016 10:32 AM, Paul Benedict wrote: >> Oh, okay ... so basically when you let the native "any" type be boxed, you're exposing the same functionality through an interface. >> >> Cheers, >> Paul >> >> On Wed, Apr 27, 2016 at 9:25 AM, Brian Goetz > wrote: >> >> Because array types (int[], String[]) *already* implement >> Cloneable and Serializable. >> >> >> >> >> >> On 4/27/2016 10:18 AM, Paul Benedict wrote: >> >> I only ask because Cloneable is typically looked at as a poor >> mechanism for >> duplicating objects. That's the sentiment, anyway, widely >> popularized by >> the Effective Java book. >> >> Cheers, >> Paul >> >> >> > From glen at organicdesign.org Wed Apr 27 20:36:27 2016 From: glen at organicdesign.org (Glen Peterson) Date: Wed, 27 Apr 2016 16:36:27 -0400 Subject: Why Arrayish implements Cloneable? In-Reply-To: References: <5720CBD1.9080700@oracle.com> <5720D0A4.9070607@oracle.com> Message-ID: Adding Serializable (and/or Cloneable) to Arrayish makes it harder to extend. Not every implementation of Arrayish necessarily wants to allow serialization or cloning. Can you have an Arrayish interface and some sub-interface like SerializableArrayish extend it for your purposes? Then people can easily extend Arrayish without the added overhead. What about making the type of your new primitive array Arrayish & Serializable? I haven't used intersection types in Java so that may be more trouble than it's worth, but I thought I'd throw it out there. On Wed, Apr 27, 2016 at 4:06 PM, John Rose wrote: > A2.0 entails splitting current types of the form T[] in into interfaces and implementations. > That is, in a future VM we will have polymorphic, generic interfaces (Arrayish, etc.) and built-in > linearly stored implementations of the same, what we are familiar with as "classic arrays". > > We *could* deem that either or both of the marker interfaces Serializable and Cloneable on all T[] > are, in fact, implementation artifacts, limited to classic arrays, and not pushed into the generic APIs. > > In fact, on second thought, we *should* do this for Cloneable, since it is not an API. The generic > method clone()T[] is part of the array API, but it is not at all dependent on Cloneable. > > What about Serializable? Perhaps we can mandate (another way) that all Arrayish's will be > serializable, without putting in the marker interface. But I think that's a losing battle. > > It might in fact be the case that many (or even all?) array implementations would chose to > include both Cloneable and Serializable, but that's not necessarily true in all possible worlds. > > ? John > > P.S. I was reading Smullyan on modal logic last night, hence the modal connective in that > last statement. > > On Apr 27, 2016, at 7:45 AM, Brian Goetz wrote: >> >> Currently, the array classes (int[].class, String[].class) are totally magical and spring into existence when referenced. They all happen to have some common supertypes (Cloneable, Serializable). >> >> This patch moves things forward incrementally (see John's talk on Arrays 2.0, http://medianetwork.oracle.com/video/player/1785452137001) by providing all arrays with a real supertype, Arrayish, which exposes element accessors. This allows, for example, abstraction over array types (), as well as being a precursor to some other cool stuff. >> >> On 4/27/2016 10:32 AM, Paul Benedict wrote: >>> Oh, okay ... so basically when you let the native "any" type be boxed, you're exposing the same functionality through an interface. >>> >>> Cheers, >>> Paul >>> >>> On Wed, Apr 27, 2016 at 9:25 AM, Brian Goetz > wrote: >>> >>> Because array types (int[], String[]) *already* implement >>> Cloneable and Serializable. >>> >>> >>> >>> >>> >>> On 4/27/2016 10:18 AM, Paul Benedict wrote: >>> >>> I only ask because Cloneable is typically looked at as a poor >>> mechanism for >>> duplicating objects. That's the sentiment, anyway, widely >>> popularized by >>> the Effective Java book. >>> >>> Cheers, >>> Paul >>> >>> >>> >> > -- Glen K. Peterson (828) 393-0081 11110 000 10 011111 10 011001 10 000010 From pbenedict at apache.org Wed Apr 27 21:14:27 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 27 Apr 2016 16:14:27 -0500 Subject: Why Arrayish implements Cloneable? In-Reply-To: References: <5720CBD1.9080700@oracle.com> <5720D0A4.9070607@oracle.com> Message-ID: I had the same thought as Glen. If the JDK has a contract itself must meet with primitive types, then introducing something like a PrimitiveArrayish (implements Serializable & Cloneable) makes sense to me. Then Arrayish itself can be "pure" and a nice building block for other use cases. Cheers, Paul On Wed, Apr 27, 2016 at 3:36 PM, Glen Peterson wrote: > Adding Serializable (and/or Cloneable) to Arrayish makes it harder to > extend. Not every implementation of Arrayish necessarily wants to > allow serialization or cloning. Can you have an Arrayish interface > and some sub-interface like SerializableArrayish extend it for your > purposes? Then people can easily extend Arrayish without the added > overhead. > > What about making the type of your new primitive array Arrayish & > Serializable? I haven't used intersection types in Java so that may > be more trouble than it's worth, but I thought I'd throw it out there. > > On Wed, Apr 27, 2016 at 4:06 PM, John Rose wrote: > > A2.0 entails splitting current types of the form T[] in into > interfaces and implementations. > > That is, in a future VM we will have polymorphic, generic interfaces > (Arrayish, etc.) and built-in > > linearly stored implementations of the same, what we are familiar with > as "classic arrays". > > > > We *could* deem that either or both of the marker interfaces > Serializable and Cloneable on all T[] > > are, in fact, implementation artifacts, limited to classic arrays, and > not pushed into the generic APIs. > > > > In fact, on second thought, we *should* do this for Cloneable, since it > is not an API. The generic > > method clone()T[] is part of the array API, but it is not at all > dependent on Cloneable. > > > > What about Serializable? Perhaps we can mandate (another way) that all > Arrayish's will be > > serializable, without putting in the marker interface. But I think > that's a losing battle. > > > > It might in fact be the case that many (or even all?) array > implementations would chose to > > include both Cloneable and Serializable, but that's not necessarily true > in all possible worlds. > > > > ? John > > > > P.S. I was reading Smullyan on modal logic last night, hence the modal > connective in that > > last statement. > > > > On Apr 27, 2016, at 7:45 AM, Brian Goetz wrote: > >> > >> Currently, the array classes (int[].class, String[].class) are totally > magical and spring into existence when referenced. They all happen to have > some common supertypes (Cloneable, Serializable). > >> > >> This patch moves things forward incrementally (see John's talk on > Arrays 2.0, http://medianetwork.oracle.com/video/player/1785452137001) by > providing all arrays with a real supertype, Arrayish, which exposes element > accessors. This allows, for example, abstraction over array types ( extends Arrayish>), as well as being a precursor to some other cool stuff. > >> > >> On 4/27/2016 10:32 AM, Paul Benedict wrote: > >>> Oh, okay ... so basically when you let the native "any" type be boxed, > you're exposing the same functionality through an interface. > >>> > >>> Cheers, > >>> Paul > >>> > >>> On Wed, Apr 27, 2016 at 9:25 AM, Brian Goetz > wrote: > >>> > >>> Because array types (int[], String[]) *already* implement > >>> Cloneable and Serializable. > >>> > >>> > >>> > >>> > >>> > >>> On 4/27/2016 10:18 AM, Paul Benedict wrote: > >>> > >>> I only ask because Cloneable is typically looked at as a poor > >>> mechanism for > >>> duplicating objects. That's the sentiment, anyway, widely > >>> popularized by > >>> the Effective Java book. > >>> > >>> Cheers, > >>> Paul > >>> > >>> > >>> > >> > > > > > > -- > Glen K. Peterson > (828) 393-0081 > > 11110 000 > 10 011111 > 10 011001 > 10 000010 > From forax at univ-mlv.fr Thu Apr 28 13:02:52 2016 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 28 Apr 2016 13:02:52 +0000 Subject: Arrays now implement "Arrayish" In-Reply-To: <5720B619.3030002@oracle.com> References: <5720B619.3030002@oracle.com> Message-ID: <089BDFEC-7A41-40B3-8F06-6A4180E49E68@univ-mlv.fr> Hi David, did you check that Arrayish can contain default methods ? regards, R?mi Le 27 avril 2016 14:52:41 CEST, David Simms a ?crit : >Greetings, > >I've just pushed a set of changes to enable all arrays to implement the > >"java.lang.Arrayish" interface: > > public interface Arrayish extends Cloneable, > java.io.Serializable { > int arraySize(); > T arrayGet(int index); > void arraySet(int index, T element); > } > >Thanks to John Rose for the original patch, which I have adapted >somewhat. > >How does it work ? > > * "Klass->extra_super()" contains an optional "InstanceKlass*" > pointer, which all array klasses have set to their appropriate > Arrayish, i.e.: > o int[] extra_super() = "Arrayish" > o Object[] extra_super() = "Arrayish" > * Classes used as "extra_super" must currently be interfaces, and have > their own "self itable" generated at load time. > * The extra_super mechanism allows the "Arrayish" interface to be > injected during JVM start-up, but after the basic array types need > to be initialized > * "extra_super()" is used when, checkcast/instanceof and looking up > interface methods > * See jtreg test: "hotspot/runtime/valhalla/arrays/ArrayTypes.java" > > >This is a prototype, there are caveats (and dragons): > > * The current "Model 3" implementation uses a specializer written in > Java, for bootstrapping the Arrayish specializations, these are > currently built at JDK compile time (placed > "$JAVA_HOME/valhalla-prespecialized") > o There is no support yet for double slot types (double and long, > and hence their arrays) > o These classes are specific to the JVM runtime, and must not be > seen by "javac" ( "VALHALLA_PRESPECIALIZED_DIR" is known to the > classloader implementation, but not the classpath). > * x86 32 & 64 bit architectures only at this point > o arrays on other architectures will simply not implement "Arrayish" > * Nothing about this implementation is set in stone, prototype code > and quality (piggy-backing on these changes, then ymmv) > * The type hierarchy for arrays will no doubt continue to be in flux > > >Cheers >/David Simms From forax at univ-mlv.fr Thu Apr 28 13:14:31 2016 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 28 Apr 2016 13:14:31 +0000 Subject: Arrays now implement "Arrayish" In-Reply-To: <089BDFEC-7A41-40B3-8F06-6A4180E49E68@univ-mlv.fr> References: <5720B619.3030002@oracle.com> <089BDFEC-7A41-40B3-8F06-6A4180E49E68@univ-mlv.fr> Message-ID: Answering to myself, yes, the prototype support default methods this is currently how arraySize, arrayGet and arraySet are implemented. This means by the way that a class can implements Arrayish without providing any implementations so a ClassCastException will be raised. Perhaps you should have two interfaces, Arrayish with only abstract methods and ArrayIshImpl (for a lack of better name) which extends Arrayish contains the default methods and is the one which is injected as interface for each array class. R?mi Le 28 avril 2016 15:02:52 CEST, "R?mi Forax" a ?crit : >Hi David, >did you check that Arrayish can contain default methods ? > >regards, >R?mi > > >Le 27 avril 2016 14:52:41 CEST, David Simms a >?crit : >>Greetings, >> >>I've just pushed a set of changes to enable all arrays to implement >the >> >>"java.lang.Arrayish" interface: >> >> public interface Arrayish extends Cloneable, >> java.io.Serializable { >> int arraySize(); >> T arrayGet(int index); >> void arraySet(int index, T element); >> } >> >>Thanks to John Rose for the original patch, which I have adapted >>somewhat. >> >>How does it work ? >> >> * "Klass->extra_super()" contains an optional "InstanceKlass*" >> pointer, which all array klasses have set to their appropriate >> Arrayish, i.e.: >> o int[] extra_super() = "Arrayish" >> o Object[] extra_super() = "Arrayish" >> * Classes used as "extra_super" must currently be interfaces, and >have >> their own "self itable" generated at load time. >> * The extra_super mechanism allows the "Arrayish" interface to be >> injected during JVM start-up, but after the basic array types need >> to be initialized >> * "extra_super()" is used when, checkcast/instanceof and looking up >> interface methods >> * See jtreg test: "hotspot/runtime/valhalla/arrays/ArrayTypes.java" >> >> >>This is a prototype, there are caveats (and dragons): >> >> * The current "Model 3" implementation uses a specializer written in >> Java, for bootstrapping the Arrayish specializations, these are >> currently built at JDK compile time (placed >> "$JAVA_HOME/valhalla-prespecialized") >> o There is no support yet for double slot types (double and >long, >> and hence their arrays) >> o These classes are specific to the JVM runtime, and must not be >> seen by "javac" ( "VALHALLA_PRESPECIALIZED_DIR" is known to >the >> classloader implementation, but not the classpath). >> * x86 32 & 64 bit architectures only at this point >> o arrays on other architectures will simply not implement >"Arrayish" >> * Nothing about this implementation is set in stone, prototype code >> and quality (piggy-backing on these changes, then ymmv) >> * The type hierarchy for arrays will no doubt continue to be in flux >> >> >>Cheers >>/David Simms From peter.levart at gmail.com Thu Apr 28 13:57:35 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 28 Apr 2016 15:57:35 +0200 Subject: Arrays now implement "Arrayish" In-Reply-To: References: <5720B619.3030002@oracle.com> <089BDFEC-7A41-40B3-8F06-6A4180E49E68@univ-mlv.fr> Message-ID: <05035079-3a47-0210-5bcb-fa8469895225@gmail.com> On 04/28/2016 03:14 PM, R?mi Forax wrote: > Answering to myself, > yes, the prototype support default methods this is currently how arraySize, arrayGet and arraySet are implemented. > > This means by the way that a class can implements Arrayish without providing any implementations so a ClassCastException will be raised. > > Perhaps you should have two interfaces, > Arrayish with only abstract methods and ArrayIshImpl (for a lack of better name) which extends Arrayish contains the default methods and is the one which is injected as interface for each array class. ... and is hidden from public view (package-private?) Peter > > R?mi > > > Le 28 avril 2016 15:02:52 CEST, "R?mi Forax" a ?crit : >> Hi David, >> did you check that Arrayish can contain default methods ? >> >> regards, >> R?mi >> >> >> Le 27 avril 2016 14:52:41 CEST, David Simms a >> ?crit : >>> Greetings, >>> >>> I've just pushed a set of changes to enable all arrays to implement >> the >>> "java.lang.Arrayish" interface: >>> >>> public interface Arrayish extends Cloneable, >>> java.io.Serializable { >>> int arraySize(); >>> T arrayGet(int index); >>> void arraySet(int index, T element); >>> } >>> >>> Thanks to John Rose for the original patch, which I have adapted >>> somewhat. >>> >>> How does it work ? >>> >>> * "Klass->extra_super()" contains an optional "InstanceKlass*" >>> pointer, which all array klasses have set to their appropriate >>> Arrayish, i.e.: >>> o int[] extra_super() = "Arrayish" >>> o Object[] extra_super() = "Arrayish" >>> * Classes used as "extra_super" must currently be interfaces, and >> have >>> their own "self itable" generated at load time. >>> * The extra_super mechanism allows the "Arrayish" interface to be >>> injected during JVM start-up, but after the basic array types need >>> to be initialized >>> * "extra_super()" is used when, checkcast/instanceof and looking up >>> interface methods >>> * See jtreg test: "hotspot/runtime/valhalla/arrays/ArrayTypes.java" >>> >>> >>> This is a prototype, there are caveats (and dragons): >>> >>> * The current "Model 3" implementation uses a specializer written in >>> Java, for bootstrapping the Arrayish specializations, these are >>> currently built at JDK compile time (placed >>> "$JAVA_HOME/valhalla-prespecialized") >>> o There is no support yet for double slot types (double and >> long, >>> and hence their arrays) >>> o These classes are specific to the JVM runtime, and must not be >>> seen by "javac" ( "VALHALLA_PRESPECIALIZED_DIR" is known to >> the >>> classloader implementation, but not the classpath). >>> * x86 32 & 64 bit architectures only at this point >>> o arrays on other architectures will simply not implement >> "Arrayish" >>> * Nothing about this implementation is set in stone, prototype code >>> and quality (piggy-backing on these changes, then ymmv) >>> * The type hierarchy for arrays will no doubt continue to be in flux >>> >>> >>> Cheers >>> /David Simms From scolebourne at joda.org Thu Apr 28 14:22:08 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 28 Apr 2016 15:22:08 +0100 Subject: Arrays now implement "Arrayish" In-Reply-To: <5720B619.3030002@oracle.com> References: <5720B619.3030002@oracle.com> Message-ID: Why arraySize() and not size(). We already have the mess betwen length() and size(), so why a third method name? Stephen On 27 April 2016 at 13:52, David Simms wrote: > Greetings, > > I've just pushed a set of changes to enable all arrays to implement the > "java.lang.Arrayish" interface: > > public interface Arrayish extends Cloneable, > java.io.Serializable { > int arraySize(); > T arrayGet(int index); > void arraySet(int index, T element); > } > > Thanks to John Rose for the original patch, which I have adapted somewhat. > > How does it work ? > > * "Klass->extra_super()" contains an optional "InstanceKlass*" > pointer, which all array klasses have set to their appropriate > Arrayish, i.e.: > o int[] extra_super() = "Arrayish" > o Object[] extra_super() = "Arrayish" > * Classes used as "extra_super" must currently be interfaces, and have > their own "self itable" generated at load time. > * The extra_super mechanism allows the "Arrayish" interface to be > injected during JVM start-up, but after the basic array types need > to be initialized > * "extra_super()" is used when, checkcast/instanceof and looking up > interface methods > * See jtreg test: "hotspot/runtime/valhalla/arrays/ArrayTypes.java" > > > This is a prototype, there are caveats (and dragons): > > * The current "Model 3" implementation uses a specializer written in > Java, for bootstrapping the Arrayish specializations, these are > currently built at JDK compile time (placed > "$JAVA_HOME/valhalla-prespecialized") > o There is no support yet for double slot types (double and long, > and hence their arrays) > o These classes are specific to the JVM runtime, and must not be > seen by "javac" ( "VALHALLA_PRESPECIALIZED_DIR" is known to the > classloader implementation, but not the classpath). > * x86 32 & 64 bit architectures only at this point > o arrays on other architectures will simply not implement "Arrayish" > * Nothing about this implementation is set in stone, prototype code > and quality (piggy-backing on these changes, then ymmv) > * The type hierarchy for arrays will no doubt continue to be in flux > > > Cheers > /David Simms > From brian.goetz at oracle.com Thu Apr 28 14:58:20 2016 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 28 Apr 2016 10:58:20 -0400 Subject: Arrays now implement "Arrayish" In-Reply-To: References: <5720B619.3030002@oracle.com> Message-ID: <73B745BE-7DCB-4C86-986E-D4DF32E04A50@oracle.com> Guys -- this is a first cut prototype so we can play with it. We are not even sure how, or if, it will be exposed. It is radically premature to bikeshed on names or syntax at this point..... Sent from my iPad > On Apr 28, 2016, at 10:22, Stephen Colebourne wrote: > > Why arraySize() and not size(). We already have the mess betwen > length() and size(), so why a third method name? > Stephen > > >> On 27 April 2016 at 13:52, David Simms wrote: >> Greetings, >> >> I've just pushed a set of changes to enable all arrays to implement the >> "java.lang.Arrayish" interface: >> >> public interface Arrayish extends Cloneable, >> java.io.Serializable { >> int arraySize(); >> T arrayGet(int index); >> void arraySet(int index, T element); >> } >> >> Thanks to John Rose for the original patch, which I have adapted somewhat. >> >> How does it work ? >> >> * "Klass->extra_super()" contains an optional "InstanceKlass*" >> pointer, which all array klasses have set to their appropriate >> Arrayish, i.e.: >> o int[] extra_super() = "Arrayish" >> o Object[] extra_super() = "Arrayish" >> * Classes used as "extra_super" must currently be interfaces, and have >> their own "self itable" generated at load time. >> * The extra_super mechanism allows the "Arrayish" interface to be >> injected during JVM start-up, but after the basic array types need >> to be initialized >> * "extra_super()" is used when, checkcast/instanceof and looking up >> interface methods >> * See jtreg test: "hotspot/runtime/valhalla/arrays/ArrayTypes.java" >> >> >> This is a prototype, there are caveats (and dragons): >> >> * The current "Model 3" implementation uses a specializer written in >> Java, for bootstrapping the Arrayish specializations, these are >> currently built at JDK compile time (placed >> "$JAVA_HOME/valhalla-prespecialized") >> o There is no support yet for double slot types (double and long, >> and hence their arrays) >> o These classes are specific to the JVM runtime, and must not be >> seen by "javac" ( "VALHALLA_PRESPECIALIZED_DIR" is known to the >> classloader implementation, but not the classpath). >> * x86 32 & 64 bit architectures only at this point >> o arrays on other architectures will simply not implement "Arrayish" >> * Nothing about this implementation is set in stone, prototype code >> and quality (piggy-backing on these changes, then ymmv) >> * The type hierarchy for arrays will no doubt continue to be in flux >> >> >> Cheers >> /David Simms >> From john.r.rose at oracle.com Thu Apr 28 17:38:38 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 28 Apr 2016 10:38:38 -0700 Subject: Arrays now implement "Arrayish" In-Reply-To: References: <5720B619.3030002@oracle.com> <089BDFEC-7A41-40B3-8F06-6A4180E49E68@univ-mlv.fr> Message-ID: Yes, this is a good reading to hide the adapter interfaces. As Brian said, it's all in flux One missing bit is the interface which generalizes the int index to long (and other types). In one possible world, that would be the only public super of arrays. ? John > On Apr 28, 2016, at 6:14 AM, R?mi Forax wrote: > > This means by the way that a class can implements Arrayish without providing any implementations so a ClassCastException will be raised. From john.r.rose at oracle.com Thu Apr 28 17:39:08 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 28 Apr 2016 10:39:08 -0700 Subject: Arrays now implement "Arrayish" In-Reply-To: <5720B619.3030002@oracle.com> References: <5720B619.3030002@oracle.com> Message-ID: <7F0B69D6-29D3-495E-82EF-740A1C5BEB6D@oracle.com> This is great work. Thanks for making it happen. ? John > On Apr 27, 2016, at 5:52 AM, David Simms wrote: > > Greetings, > > I've just pushed a set of changes to enable all arrays to implement the "java.lang.Arrayish" interface: > > public interface Arrayish extends Cloneable, > java.io.Serializable { > int arraySize(); > T arrayGet(int index); > void arraySet(int index, T element); > } > > Thanks to John Rose for the original patch, which I have adapted somewhat. > > How does it work ? > > * "Klass->extra_super()" contains an optional "InstanceKlass*" > pointer, which all array klasses have set to their appropriate > Arrayish, i.e.: > o int[] extra_super() = "Arrayish" > o Object[] extra_super() = "Arrayish" > * Classes used as "extra_super" must currently be interfaces, and have > their own "self itable" generated at load time. > * The extra_super mechanism allows the "Arrayish" interface to be > injected during JVM start-up, but after the basic array types need > to be initialized > * "extra_super()" is used when, checkcast/instanceof and looking up > interface methods > * See jtreg test: "hotspot/runtime/valhalla/arrays/ArrayTypes.java" > > > This is a prototype, there are caveats (and dragons): > > * The current "Model 3" implementation uses a specializer written in > Java, for bootstrapping the Arrayish specializations, these are > currently built at JDK compile time (placed > "$JAVA_HOME/valhalla-prespecialized") > o There is no support yet for double slot types (double and long, > and hence their arrays) > o These classes are specific to the JVM runtime, and must not be > seen by "javac" ( "VALHALLA_PRESPECIALIZED_DIR" is known to the > classloader implementation, but not the classpath). > * x86 32 & 64 bit architectures only at this point > o arrays on other architectures will simply not implement "Arrayish" > * Nothing about this implementation is set in stone, prototype code > and quality (piggy-backing on these changes, then ymmv) > * The type hierarchy for arrays will no doubt continue to be in flux > > > Cheers > /David Simms >