From harold.seigel at oracle.com Fri Jun 1 12:07:52 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Fri, 1 Jun 2018 08:07:52 -0400 Subject: RFR: add verifier checks for when a reference can and cannot be a value type In-Reply-To: <8B4AD927-1ED9-4EB1-A07B-7F7784CAFE57@oracle.com> References: <996c6da3-0875-6f86-296d-ee7b64770658@oracle.com> <8B4AD927-1ED9-4EB1-A07B-7F7784CAFE57@oracle.com> Message-ID: <10b9c69f-14cd-ced0-f813-9fa02dd88a2f@oracle.com> Thanks Karen! Harold On 5/31/2018 5:35 PM, Karen Kinnear wrote: > Harold, > > Many thanks. The changes look great. > > I was wrong about expecting changes to putstatic. > From JVMS 2.4 *http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4d.pdf) > A value class type defines a class for which all instances are identity-less and immutable. > The class itself is not immutable. > > thank you very much, > Karen > >> On May 31, 2018, at 10:30 AM, Harold David Seigel wrote: >> >> Hi, >> >> Please review this change to add checks to the verifier for the following: >> >> 1. Not allow the operand for a NEW or MONITOR* opcode be a value type. >> 2. Require that the reference operand for a WITHFIELD or DEFAULTVALUE >> opcode be a value type. >> 3. Not allow the field for a PUTFIELD opcode to be in a value type >> unless the current method is named "". >> >> Also, some of the existing test cases in verfierTests.jcod were modified to add the ValueTypes attribute. >> >> Webrev: http://cr.openjdk.java.net/~hseigel/vt_verifier_checks/webrev/index.html >> >> The fix was tested with JCK Lang and VM tests, Hotspot JTReg tests, and with many JDK JTReg tests. >> >> Thanks, Harold From harold.seigel at oracle.com Fri Jun 1 12:32:27 2018 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Fri, 01 Jun 2018 12:32:27 +0000 Subject: hg: valhalla/valhalla: Summary: Add verifier checks for when a reference can and cannot be a value type Message-ID: <201806011232.w51CWSPD028403@aojmv0008.oracle.com> Changeset: 1fbbc0ba4434 Author: hseigel Date: 2018-06-01 08:32 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/1fbbc0ba4434 Summary: Add verifier checks for when a reference can and cannot be a value type Reviewed-by: acorn ! src/hotspot/share/classfile/verifier.cpp ! test/hotspot/jtreg/runtime/valhalla/valuetypes/verifier/VerifierValueTypes.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/verifier/verifierTests.jcod From rwestrel at redhat.com Fri Jun 1 15:13:35 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 01 Jun 2018 17:13:35 +0200 Subject: RFR(M): arraycopy/clone/copyOf intrinsics fixes for Lworld In-Reply-To: References: <82899173-9ad7-96fb-b2ac-06afa05e5a7f@oracle.com> <34fbc612-33e0-827c-5e07-472dcab509e7@oracle.com> Message-ID: Here is a new webrev. It implements your suggestion: http://cr.openjdk.java.net/~roland/valhalla/arraycopy-lworld/webrev.01/ test63() is commented out for now because a bug in the type system causes an incorrect execution with non flattened arrays. Roland. From sergey.kuksenko at oracle.com Sat Jun 2 00:52:50 2018 From: sergey.kuksenko at oracle.com (sergey.kuksenko at oracle.com) Date: Sat, 02 Jun 2018 00:52:50 +0000 Subject: hg: valhalla/valhalla: [lword] Add initial set of valhalla lword benchmarks Message-ID: <201806020052.w520qpSh013030@aojmv0008.oracle.com> Changeset: f27b0212d82c Author: Sergey Kuksenko Date: 2018-06-01 17:51 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f27b0212d82c [lword] Add initial set of valhalla lword benchmarks + test/benchmarks/pom.xml + test/benchmarks/src/main/java/oracle/micro/valhalla/AckermannBase.java + test/benchmarks/src/main/java/oracle/micro/valhalla/ArraycopyBase.java + test/benchmarks/src/main/java/oracle/micro/valhalla/ArrayfillBase.java + test/benchmarks/src/main/java/oracle/micro/valhalla/ArraysumBase.java + test/benchmarks/src/main/java/oracle/micro/valhalla/BigDataSize.java + test/benchmarks/src/main/java/oracle/micro/valhalla/InvokeBase.java + test/benchmarks/src/main/java/oracle/micro/valhalla/ListsumBase.java + test/benchmarks/src/main/java/oracle/micro/valhalla/MapBase.java + test/benchmarks/src/main/java/oracle/micro/valhalla/MatrixBase.java + test/benchmarks/src/main/java/oracle/micro/valhalla/SearchBase.java + test/benchmarks/src/main/java/oracle/micro/valhalla/SmallDataSize.java + test/benchmarks/src/main/java/oracle/micro/valhalla/SortBase.java + test/benchmarks/src/main/java/oracle/micro/valhalla/TraversalBase.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/ackermann/Ackermann1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/ackermann/Ackermann2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/ackermann/Ackermann8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/ackermann/AckermannMix.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/arraycopy/Arraycopy1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/arraycopy/Arraycopy2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/arraycopy/Arraycopy8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/arrayfill/Arrayfill1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/arrayfill/Arrayfill2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/arrayfill/Arrayfill8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/arraysum/Arraysum1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/arraysum/Arraysum2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/arraysum/Arraysum8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/convcopy/Convcopy1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/convcopy/Convcopy2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/convcopy/Convcopy8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/invoke/Invoke.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/listsum/Listsum1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/listsum/Listsum2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/listsum/Listsum8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/map/Get.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/map/Put.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/map/Walk.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/matrix/Boxed.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/matrix/Primitive.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/search/Search1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/search/Search2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/search/Search8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/sort/Primitive1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/sort/Sort1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/sort/Sort2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/sort/Sort8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/traversal/Boxed.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/traversal/Primitive.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/types/Box1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/types/Box2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/types/Box8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/baseline/util/HashMap.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/ackermann/Ackermann1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/ackermann/Ackermann2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/ackermann/Ackermann8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/ackermann/AckermannMix.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arraycopy/Arraycopy1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arraycopy/Arraycopy2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arraycopy/Arraycopy8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arrayfill/Arrayfill1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arrayfill/Arrayfill2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arrayfill/Arrayfill8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arraysum/Arraysum1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arraysum/Arraysum2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arraysum/Arraysum8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/convcopy/Convcopy1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/convcopy/Convcopy2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/convcopy/Convcopy8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/invoke/Invoke.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/listsum/Listsum1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/listsum/Listsum2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/listsum/Listsum8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/map/GetValue.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/map/PutValue.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/map/WalkIteratorCursor.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/map/WalkValueCursor.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/map/WalkValueEntry.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/map/WalkValueTotal.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/matrix/Value.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/search/Search1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/search/Search2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/search/Search8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/sort/Sort1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/sort/Sort2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/sort/Sort8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/traversal/Value.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/types/Value1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/types/Value2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/types/Value8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/types/Wrapper1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/types/Wrapper2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/types/Wrapper8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/util/HashMapIteratorCursor.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/util/HashMapValueCursor.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/util/HashMapValueEntry.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lword/util/HashMapValueTotal.java + test/benchmarks/src/main/java/oracle/micro/valhalla/types/PNumber.java + test/benchmarks/src/main/java/oracle/micro/valhalla/types/Total.java + test/benchmarks/src/main/java/oracle/micro/valhalla/util/AbstractMap.java + test/benchmarks/src/main/java/oracle/micro/valhalla/util/Cursor.java From david.holmes at oracle.com Mon Jun 4 04:44:55 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 04 Jun 2018 04:44:55 +0000 Subject: hg: valhalla/valhalla: Merge Message-ID: <201806040444.w544itFw003492@aojmv0008.oracle.com> Changeset: 856c2c87fdf2 Author: dholmes Date: 2018-06-04 00:44 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/856c2c87fdf2 Merge - make/BuildNashorn.gmk - make/UnpackSecurity.gmk ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp - src/hotspot/os/aix/jvm_aix.cpp - src/hotspot/os/bsd/jvm_bsd.cpp - src/hotspot/os/linux/jvm_linux.cpp - src/hotspot/os/solaris/jvm_solaris.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/logging/logTag.hpp - src/hotspot/share/memory/metachunk.cpp - src/hotspot/share/memory/metachunk.hpp ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/reflection.cpp - src/hotspot/share/runtime/vmStructs_trace.hpp - src/hotspot/share/trace/noTraceBackend.hpp - src/hotspot/share/trace/trace.dtd - src/hotspot/share/trace/trace.xml - src/hotspot/share/trace/traceBackend.cpp - src/hotspot/share/trace/traceBackend.hpp - src/hotspot/share/trace/traceDataTypes.hpp - src/hotspot/share/trace/traceEvent.hpp - src/hotspot/share/trace/traceEventClasses.xsl - src/hotspot/share/trace/traceEventIds.xsl - src/hotspot/share/trace/traceMacros.hpp - src/hotspot/share/trace/traceStream.cpp - src/hotspot/share/trace/traceStream.hpp - src/hotspot/share/trace/traceTime.hpp - src/hotspot/share/trace/traceTypes.xsl - src/hotspot/share/trace/traceevents.xml - src/hotspot/share/trace/tracerelationdecls.xml - src/hotspot/share/trace/tracetypes.xml - src/hotspot/share/trace/tracing.hpp - src/hotspot/share/trace/tracingExport.cpp - src/hotspot/share/trace/tracingExport.hpp - src/hotspot/share/trace/xinclude.mod - src/hotspot/share/trace/xsl_util.xsl - src/hotspot/share/utilities/ticks.inline.hpp - src/java.base/macosx/conf/x86_64/jvm.cfg ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Method.java - src/java.base/unix/conf/aarch64/jvm.cfg - src/java.base/unix/conf/amd64/jvm.cfg - src/java.base/unix/conf/arm/jvm.cfg - src/java.base/unix/conf/i586/jvm.cfg - src/java.base/unix/conf/ia64/jvm.cfg - src/java.base/unix/conf/ppc64/jvm.cfg - src/java.base/unix/conf/ppc64le/jvm.cfg - src/java.base/unix/conf/s390x/jvm.cfg - src/java.base/unix/conf/sparc/jvm.cfg - src/java.base/unix/conf/sparcv9/jvm.cfg - src/java.base/unix/conf/zero/jvm.cfg - src/java.base/windows/conf/amd64/jvm.cfg - src/java.base/windows/conf/i586/jvm.cfg - src/java.base/windows/conf/ia64/jvm.cfg ! 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.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/BaseExecutableMemberTaglet.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/BaseInlineTaglet.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/HiddenTaglet.java ! test/hotspot/jtreg/ProblemList.txt + test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/BasicTest.java + test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/PrivateMethodsTest.java ! test/jdk/ProblemList.txt - test/jdk/java/lang/Character/Blocks.txt - test/jdk/java/lang/Character/CheckBlocks.java - test/jdk/java/lang/Character/TestISOControls.java From david.holmes at oracle.com Mon Jun 4 04:50:38 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 04 Jun 2018 04:50:38 +0000 Subject: hg: valhalla/valhalla: 8203046: [Testbug] vmTestbase/nsk/stress/except/except004.java fails with nestmates Message-ID: <201806040450.w544odjD005071@aojmv0008.oracle.com> Changeset: bd873f6d9bf1 Author: dholmes Date: 2018-06-04 00:50 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/bd873f6d9bf1 8203046: [Testbug] vmTestbase/nsk/stress/except/except004.java fails with nestmates Reviewed-by: mainline RFR as part of 8010139 ! test/hotspot/jtreg/vmTestbase/nsk/stress/except/except004.java From tobias.hartmann at oracle.com Mon Jun 4 07:04:19 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 4 Jun 2018 09:04:19 +0200 Subject: RFR(M): arraycopy/clone/copyOf intrinsics fixes for Lworld In-Reply-To: References: <82899173-9ad7-96fb-b2ac-06afa05e5a7f@oracle.com> <34fbc612-33e0-827c-5e07-472dcab509e7@oracle.com> Message-ID: <26259c6c-623a-c2de-cb37-4a9555c4a6a8@oracle.com> Hi Roland, thanks for making that change! In graphKit.cpp:3954 and macro.cpp:1443 shouldn't you use can_be_value_type() (you are not handling the interface element type in macro.cpp)? Also, in macro.cpp you don't need to load elem_klass if it's statically known. Best regards, Tobias On 01.06.2018 17:13, Roland Westrelin wrote: > > Here is a new webrev. It implements your suggestion: > > http://cr.openjdk.java.net/~roland/valhalla/arraycopy-lworld/webrev.01/ > > test63() is commented out for now because a bug in the type system > causes an incorrect execution with non flattened arrays. > > Roland. > From david.holmes at oracle.com Mon Jun 4 07:09:56 2018 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 04 Jun 2018 07:09:56 +0000 Subject: hg: valhalla/valhalla: 8199450: [Nestmates] several runtime/RedefineTests/* failed with the nestmates build Message-ID: <201806040709.w5479vns014729@aojmv0008.oracle.com> Changeset: cf8d878e8aa7 Author: dholmes Date: 2018-06-04 02:53 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/cf8d878e8aa7 8199450: [Nestmates] several runtime/RedefineTests/* failed with the nestmates build Reviewed-by: mainline RFR for 8010319 ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/RedefineTests/RedefineDoubleDelete.java ! test/hotspot/jtreg/runtime/RedefineTests/RedefineFinalizer.java ! test/hotspot/jtreg/runtime/RedefineTests/RedefineInterfaceCall.java ! test/hotspot/jtreg/runtime/RedefineTests/RedefineInterfaceMethods.java ! test/hotspot/jtreg/runtime/RedefineTests/RedefinePreviousVersions.java ! test/hotspot/jtreg/runtime/RedefineTests/RedefineRunningMethods.java ! test/hotspot/jtreg/runtime/RedefineTests/RedefineRunningMethodsWithBacktrace.java ! test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasic.java ! test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java ! test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java From rwestrel at redhat.com Mon Jun 4 14:56:14 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 04 Jun 2018 16:56:14 +0200 Subject: RFR(M): arraycopy/clone/copyOf intrinsics fixes for Lworld In-Reply-To: <26259c6c-623a-c2de-cb37-4a9555c4a6a8@oracle.com> References: <82899173-9ad7-96fb-b2ac-06afa05e5a7f@oracle.com> <34fbc612-33e0-827c-5e07-472dcab509e7@oracle.com> <26259c6c-623a-c2de-cb37-4a9555c4a6a8@oracle.com> Message-ID: Hi Tobias, > In graphKit.cpp:3954 and macro.cpp:1443 shouldn't you use can_be_value_type() (you are not handling > the interface element type in macro.cpp)? Also, in macro.cpp you don't need to load elem_klass if > it's statically known. If the allocation is: new I[]; for some interface I then we know we're not allocating a value type array that needs special initialization. If the allocation is through reflection for some Class c then the type system will report Object as array element. In that case, the array could be a value type array. But for new Object[]; the element type is also Object but it doesn't need special initialization. So my patch should actually test whether the element type is exact or not. New webrev: http://cr.openjdk.java.net/~roland/valhalla/arraycopy-lworld/webrev.02/ Change from previous one is: diff --git a/src/hotspot/share/opto/graphKit.cpp b/src/hotspot/share/opto/graphKit.cpp --- a/src/hotspot/share/opto/graphKit.cpp +++ b/src/hotspot/share/opto/graphKit.cpp @@ -3951,7 +3951,7 @@ // InitializeNode* init = alloc->initialization(); //init->set_complete_with_arraycopy(); } - } else if (EnableValhalla && (!layout_con || (elem_klass != NULL && elem_klass->is_java_lang_Object()))) { + } else if (EnableValhalla && (!layout_con || (elem_klass != NULL && elem_klass->is_java_lang_Object() && !ary_type->klass_is_exact()))) { InitializeNode* init = alloc->initialization(); init->set_unknown_value(); } diff --git a/src/hotspot/share/opto/macro.cpp b/src/hotspot/share/opto/macro.cpp --- a/src/hotspot/share/opto/macro.cpp +++ b/src/hotspot/share/opto/macro.cpp @@ -1440,7 +1440,7 @@ elem_klass = ary_ptr->klass()->as_array_klass()->element_klass(); } - if (elem_klass == NULL || elem_klass->is_java_lang_Object() || elem_klass->is_valuetype()) { + if (elem_klass == NULL || (elem_klass->is_java_lang_Object() && !ary_ptr->klass_is_exact()) || elem_klass->is_valuetype()) { // If it's an array of values we must go to the slow path so it is // correctly initialized with default values. Node* fast_region = new RegionNode(3); Wrt, to the load of elem_klass that's not needed. That will be optimize away, right? I would rather keep the logic simple. Roland. From tobias.hartmann at oracle.com Mon Jun 4 15:03:41 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 4 Jun 2018 17:03:41 +0200 Subject: RFR(M): arraycopy/clone/copyOf intrinsics fixes for Lworld In-Reply-To: References: <82899173-9ad7-96fb-b2ac-06afa05e5a7f@oracle.com> <34fbc612-33e0-827c-5e07-472dcab509e7@oracle.com> <26259c6c-623a-c2de-cb37-4a9555c4a6a8@oracle.com> Message-ID: <893aabea-8807-b497-2832-d5a8aae8649f@oracle.com> Hi Roland, On 04.06.2018 16:56, Roland Westrelin wrote: > If the allocation is: > > new I[]; > > for some interface I then we know we're not allocating a value type > array that needs special initialization. > > If the allocation is through reflection for some Class c then the type > system will report Object as array element. In that case, the array > could be a value type array. But for > > new Object[]; > > the element type is also Object but it doesn't need special > initialization. So my patch should actually test whether the element > type is exact or not. > > New webrev: > > http://cr.openjdk.java.net/~roland/valhalla/arraycopy-lworld/webrev.02/ Got it. The new webrev looks good to me! > Wrt, to the load of elem_klass that's not needed. That will be optimize > away, right? I would rather keep the logic simple. Yes, sure. Thanks, Tobias From rwestrel at redhat.com Tue Jun 5 07:41:54 2018 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Tue, 05 Jun 2018 07:41:54 +0000 Subject: hg: valhalla/valhalla: arraycopy/copyOf/clone intrinsics fixes for Lworld Message-ID: <201806050741.w557fsjD001699@aojmv0008.oracle.com> Changeset: c83ac02bdb4f Author: roland Date: 2018-06-04 16:49 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c83ac02bdb4f arraycopy/copyOf/clone intrinsics fixes for Lworld ! src/hotspot/share/classfile/vmSymbols.cpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macro.hpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/type.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/MyInterface.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/MyValue1.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/MyValue3.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/MyValue4.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestLWorld.java From rwestrel at redhat.com Tue Jun 5 07:53:43 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 05 Jun 2018 09:53:43 +0200 Subject: RFR(S): type system fix Message-ID: http://cr.openjdk.java.net/~roland/valhalla/lworld-typesystem-fix/webrev.00/ This allows a test that I added for copyOf to run correctly. The change attempts to mirror the logic for instances. I tried to run our tests without the workaround in Type::meet_helper() and I hit no failure. Roland. From tobias.hartmann at oracle.com Tue Jun 5 08:38:30 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 5 Jun 2018 10:38:30 +0200 Subject: RFR(S): type system fix In-Reply-To: References: Message-ID: Hi Roland, On 05.06.2018 09:53, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/valhalla/lworld-typesystem-fix/webrev.00/ This looks good to me! Please fix the indentation/whitespacing in type.cpp:4176. > This allows a test that I added for copyOf to run correctly. The change > attempts to mirror the logic for instances. I tried to run our tests > without the workaround in Type::meet_helper() and I hit no failure. I've just tried to execute our tests but even without your changes I get this failure: # Internal Error (/oracle/valhallaL/open/src/hotspot/share/opto/graphKit.cpp:1802), pid=13876, tid=13890 # assert(arg->bottom_type()->remove_speculative() == TypePtr::NULL_PTR) failed: Anything other than null? Current CompileTask: C2: 1749 115 b compiler.valhalla.valuetypes.TestArrays::verify (46 bytes) Stack: [0x00007fdc1817b000,0x00007fdc1827c000], sp=0x00007fdc182785d0, free space=1013k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1a35d6c] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x18c V [libjvm.so+0x1a36c9f] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f V [libjvm.so+0xbb8faa] report_vm_error(char const*, int, char const*, char const*, ...)+0x12a V [libjvm.so+0xec6f8d] GraphKit::set_arguments_for_java_call(CallJavaNode*)+0x3bd V [libjvm.so+0x8e9c45] DirectCallGenerator::generate(JVMState*)+0x475 V [libjvm.so+0xcbb69e] Parse::do_call()+0x49e V [libjvm.so+0x16bb022] Parse::do_one_bytecode()+0x1c52 V [libjvm.so+0x16a9cba] Parse::do_one_block()+0x39a V [libjvm.so+0x16aa8d1] Parse::do_all_blocks()+0x1d1 V [libjvm.so+0x16ae347] Parse::Parse(JVMState*, ciMethod*, float)+0xd17 V [libjvm.so+0x8e560c] ParseGenerator::generate(JVMState*)+0x1fc V [libjvm.so+0xb12f67] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xfe7 V [libjvm.so+0x8e36f2] C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x302 The assert triggers because arg is a CheckCastPP: 146 CastPP === 145 137 [[ 168 155 155 164 ]] #java/lang/Object:NotNull * Oop:java/lang/Object:NotNull * !jvms: TestArrays::verify @ bci:11 162 IfTrue === 161 [[ 139 164 ]] #1 !jvms: TestArrays::verify @ bci:11 164 CheckCastPP === 162 146 [[ 140 90 ]] #compiler/valhalla/valuetypes/MyValue2:NotNull:exact * Oop:compiler/valhalla/valuetypes/MyValue2:NotNull:exact * !jvms: TestArrays::verify @ bci:11 I think it's too strong, here's the fix: --- a/src/hotspot/share/opto/graphKit.cpp Mon Jun 04 16:49:10 2018 +0200 +++ b/src/hotspot/share/opto/graphKit.cpp Tue Jun 05 10:25:52 2018 +0200 @@ -1797,9 +1797,8 @@ // Pass value type argument via oop to callee arg = vt->allocate(this)->get_oop(); } - } else if (t->is_valuetypeptr()) { + } else if (t->is_valuetypeptr() && arg->bottom_type()->remove_speculative() == TypePtr::NULL_PTR) { // Constant null passed for a value type argument - assert(arg->bottom_type()->remove_speculative() == TypePtr::NULL_PTR, "Anything other than null?"); With that and your fix, all tests pass on my machine as well. Thanks, Tobias From srikanth.adayapalam at oracle.com Tue Jun 5 09:29:14 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Tue, 05 Jun 2018 09:29:14 +0000 Subject: hg: valhalla/valhalla: [lworld] Fix tests that are failing post merge. Message-ID: <201806050929.w559TFuG007112@aojmv0008.oracle.com> Changeset: 7aa96b2ecab0 Author: sadayapalam Date: 2018-06-05 14:58 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7aa96b2ecab0 [lworld] Fix tests that are failing post merge. ! test/langtools/tools/javac/valhalla/lworld-values/DemoteToValueBasedTest.java ! test/langtools/tools/javac/valhalla/lworld-values/FinalFieldTest.java From srikanth.adayapalam at oracle.com Tue Jun 5 10:58:47 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Tue, 05 Jun 2018 10:58:47 +0000 Subject: hg: valhalla/valhalla: [lworld] Enhance the bytecode library with an API for easy emission of ValueTypes attribute. Message-ID: <201806051058.w55AwmqJ006226@aojmv0008.oracle.com> Changeset: 0cc219b07dcc Author: sadayapalam Date: 2018-06-05 16:28 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0cc219b07dcc [lworld] Enhance the bytecode library with an API for easy emission of ValueTypes attribute. ! src/java.base/share/classes/jdk/experimental/bytecode/ClassBuilder.java From rwestrel at redhat.com Tue Jun 5 12:20:44 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 05 Jun 2018 14:20:44 +0200 Subject: RFR(S): type system fix In-Reply-To: References: Message-ID: Hi Tobias, > I think it's too strong, here's the fix: > > --- a/src/hotspot/share/opto/graphKit.cpp Mon Jun 04 16:49:10 2018 +0200 > +++ b/src/hotspot/share/opto/graphKit.cpp Tue Jun 05 10:25:52 2018 +0200 > @@ -1797,9 +1797,8 @@ > // Pass value type argument via oop to callee > arg = vt->allocate(this)->get_oop(); > } > - } else if (t->is_valuetypeptr()) { > + } else if (t->is_valuetypeptr() && arg->bottom_type()->remove_speculative() == TypePtr::NULL_PTR) { > // Constant null passed for a value type argument > - assert(arg->bottom_type()->remove_speculative() == TypePtr::NULL_PTR, "Anything other than > null?"); > > With that and your fix, all tests pass on my machine as well. We have a nice invariant that values are either constant null or a value type node. I think we should try to keep it that way. What about this: http://cr.openjdk.java.net/~roland/valhalla/lworld-typesystem-fix/webrev.01/ The interface call resolution code needed some adjustment too. Roland. From tobias.hartmann at oracle.com Tue Jun 5 12:26:48 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 5 Jun 2018 14:26:48 +0200 Subject: RFR(S): type system fix In-Reply-To: References: Message-ID: <1f7c401a-f797-d944-fb61-7c7b908c06f9@oracle.com> Hi Roland, On 05.06.2018 14:20, Roland Westrelin wrote: > We have a nice invariant that values are either constant null or a value > type node. I think we should try to keep it that way. What about this: > > http://cr.openjdk.java.net/~roland/valhalla/lworld-typesystem-fix/webrev.01/ > > The interface call resolution code needed some adjustment too. That's much better. Thanks for fixing! Best regards, Tobias From rwestrel at redhat.com Tue Jun 5 13:42:08 2018 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Tue, 05 Jun 2018 13:42:08 +0000 Subject: hg: valhalla/valhalla: type system fix + fix to cast from profiling + fix to interface call on known value Message-ID: <201806051342.w55Dg9bS001853@aojmv0008.oracle.com> Changeset: 17e0d6032435 Author: roland Date: 2018-06-05 15:29 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/17e0d6032435 type system fix + fix to cast from profiling + fix to interface call on known value ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/opto/doCall.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/type.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java From mandy.chung at oracle.com Thu Jun 7 22:08:14 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 7 Jun 2018 15:08:14 -0700 Subject: Library support for generating BSM for value type's hashCode/equals/toString Message-ID: This is an initial library support to generate BSM for hashCode/equals /toString for value types. It implements the idea John laid out [1]. Srikanth will be adding javac support. Once hook up, we can do more interesting experiment and improvement and tease out issues. http://cr.openjdk.java.net/~mchung/valhalla/webrevs/value-hashcode-bsm.00/ Mandy [1] http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-April/004111.html From paul.sandoz at oracle.com Fri Jun 8 00:00:24 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 7 Jun 2018 17:00:24 -0700 Subject: Library support for generating BSM for value type's hashCode/equals/toString In-Reply-To: References: Message-ID: Hi Mandy, This looks like a great start. You mind is now suitably warped to think in terms of MH combinators :-) For further consideration? I think you can represent the value class, the receiver type, explicitly in the method type passed to the BSM, rather than use Object. Then you don?t need the extra static arg, and you can pick c from type.parameterType(0). Perhaps what you had in mind in the aptNote? Paul. > On Jun 7, 2018, at 3:08 PM, mandy chung wrote: > > This is an initial library support to generate BSM for hashCode/equals > /toString for value types. It implements the idea John laid out [1]. > Srikanth will be adding javac support. Once hook up, we can do more > interesting experiment and improvement and tease out issues. > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/value-hashcode-bsm.00/ > > Mandy > [1] http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-April/004111.html From mandy.chung at oracle.com Fri Jun 8 00:27:22 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 7 Jun 2018 17:27:22 -0700 Subject: Library support for generating BSM for value type's hashCode/equals/toString In-Reply-To: References: Message-ID: On 6/7/18 5:00 PM, Paul Sandoz wrote: > Hi Mandy, > > This looks like a great start. You mind is now suitably warped to > think in terms of MH combinators :-) :-) I haven't managed MethodHandles::loop - more vigorous twisting needed. > For further consideration? > > I think you can represent the value class, the receiver type, > explicitly in the method type passed to the BSM, rather than use > Object. Then you don?t need the extra static arg, and you can pick c > from type.parameterType(0). > > Perhaps what you had in mind in the aptNote? Yes, we can drop the static arg once we have the javac support. It will get the value type from the Lookup object passed to BSM. Mandy > Paul. > >> On Jun 7, 2018, at 3:08 PM, mandy chung >> wrote: >> >> This is an initial library support to generate BSM for >> hashCode/equals /toString for value types. It implements the idea >> John laid out [1]. Srikanth will be adding javac support. Once >> hook up, we can do more interesting experiment and improvement and >> tease out issues. >> >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/value-hashcode-bsm.00/ >> >> >> Mandy >> [1] >> http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-April/004111.html > From paul.sandoz at oracle.com Fri Jun 8 00:50:06 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 7 Jun 2018 17:50:06 -0700 Subject: Library support for generating BSM for value type's hashCode/equals/toString In-Reply-To: References: Message-ID: <887CE919-D683-4CCD-8497-EB27BB7885CA@oracle.com> > On Jun 7, 2018, at 5:27 PM, mandy chung wrote: > > > > On 6/7/18 5:00 PM, Paul Sandoz wrote: >> Hi Mandy, >> This looks like a great start. You mind is now suitably warped to >> think in terms of MH combinators :-) > > :-) > > I haven't managed MethodHandles::loop - more vigorous twisting needed. > >> For further consideration? >> I think you can represent the value class, the receiver type, >> explicitly in the method type passed to the BSM, rather than use >> Object. Then you don?t need the extra static arg, and you can pick c >> from type.parameterType(0). >> >> Perhaps what you had in mind in the aptNote? > > Yes, we can drop the static arg once we have the javac support. > It will get the value type from the Lookup object passed to BSM. > Doh! yes of course, although it might be advantageous to leverage method type now to reduce further changes to javac. In any case one future refinement later is for the BSM to verify the method type parameter is the same as or a super type of the lookup class. Paul. From mandy.chung at oracle.com Fri Jun 8 01:04:14 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 7 Jun 2018 18:04:14 -0700 Subject: Library support for generating BSM for value type's hashCode/equals/toString In-Reply-To: <887CE919-D683-4CCD-8497-EB27BB7885CA@oracle.com> References: <887CE919-D683-4CCD-8497-EB27BB7885CA@oracle.com> Message-ID: On 6/7/18 5:50 PM, Paul Sandoz wrote:> > In any case one future refinement later is for the BSM to verify the > method type parameter is the same as or a super type of the lookup > class. Good point but only need to check the same type. Value class is final, right? I will add that when I remove the static arg in the next patch. thanks Mandy From paul.sandoz at oracle.com Fri Jun 8 04:37:57 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 7 Jun 2018 21:37:57 -0700 Subject: Library support for generating BSM for value type's hashCode/equals/toString In-Reply-To: References: <887CE919-D683-4CCD-8497-EB27BB7885CA@oracle.com> Message-ID: > On Jun 7, 2018, at 6:04 PM, mandy chung wrote: > > > > On 6/7/18 5:50 PM, Paul Sandoz wrote:> >> In any case one future refinement later is for the BSM to verify the >> method type parameter is the same as or a super type of the lookup >> class. > > Good point but only need to check the same type. Value class is final, right? > Yes,. I was thinking the target MH could accept Object or an implemented interface and possibly producing a CCE on invocation, but that seems pointless. > I will add that when I remove the static arg in the next patch. > Ok. Paul. From tobias.hartmann at oracle.com Fri Jun 8 10:20:57 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 8 Jun 2018 12:20:57 +0200 Subject: [lworld] RFR: C2 arraycopy intrinsic fixes Message-ID: <7701790a-f19e-33db-f8cd-8f542cd578d0@oracle.com> Hi, http://cr.openjdk.java.net/~thartmann/valhalla/lworld/arraycopy_fixes/ This patch fixes two problems with the arraycopy intrinsic that Harold found when running JCK tests: (1) We crash in macroArrayCopy.cpp:1408 because top_src is NULL. This is because we already validated the src/dst types in LibraryCallKit::inline_arraycopy() and added a check cast of src to the dst type. Since dst is of static type java.lang.Object (i.e., not an array type), top_src is NULL. We should not check for flattened value type arrays if ac->is_arraycopy_validated(). (2) We hit the following assert in macroArrayCopy.cpp:549: "assert(basic_elem_type != T_ARRAY) failed: caller must fix this". We should pass T_OBJECT as basic type if dest_elem=T_ARRAY. All failing tests now pass. Thanks, Tobias From mandy.chung at oracle.com Fri Jun 8 15:33:20 2018 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 08 Jun 2018 15:33:20 +0000 Subject: hg: valhalla/valhalla: Initial library support for generating BSM for value type's hashCode/equals/toString Message-ID: <201806081533.w58FXKWO000230@aojmv0008.oracle.com> Changeset: 1de5c795f448 Author: mchung Date: 2018-06-08 08:32 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/1de5c795f448 Initial library support for generating BSM for value type's hashCode/equals/toString Reviewed-by: psandoz + src/java.base/share/classes/java/lang/invoke/ValueBootstrapMethods.java + test/jdk/valhalla/valuetypes/ValueBootstrapMethods.java From srikanth.adayapalam at oracle.com Mon Jun 11 12:07:36 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Mon, 11 Jun 2018 12:07:36 +0000 Subject: hg: valhalla/valhalla: [lworld] Additional enhancement to the bytecode library with an API for easy emission of ValueTypes attribute. Message-ID: <201806111207.w5BC7a8B003201@aojmv0008.oracle.com> Changeset: 4e781a86c9ec Author: sadayapalam Date: 2018-06-11 17:37 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/4e781a86c9ec [lworld] Additional enhancement to the bytecode library with an API for easy emission of ValueTypes attribute. ! src/java.base/share/classes/jdk/experimental/bytecode/ClassBuilder.java ! src/java.base/share/classes/jdk/experimental/value/MethodHandleBuilder.java From tobias.hartmann at oracle.com Mon Jun 11 13:35:50 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 11 Jun 2018 15:35:50 +0200 Subject: Ongoing merge: Please do NOT push to lworld Message-ID: <1a7aa66c-2de7-ce68-56d2-7c065ae90f2f@oracle.com> I'm currently working on the merge of lworld with the default branch. Please do not push any changes. Thanks, Tobias From tobias.hartmann at oracle.com Mon Jun 11 14:22:16 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 11 Jun 2018 14:22:16 +0000 Subject: hg: valhalla/valhalla: Merge Message-ID: <201806111422.w5BEMHij020267@aojmv0008.oracle.com> Changeset: b506159453c0 Author: thartmann Date: 2018-06-11 16:19 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b506159453c0 Merge - make/BuildNashorn.gmk ! make/CompileJavaModules.gmk + make/CompileJavaModulesNashorn.gmk ! make/Docs.gmk - make/UnpackSecurity.gmk ! make/common/Modules.gmk ! make/conf/jib-profiles.js ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/cpu/x86/x86_64.ad - src/hotspot/os/aix/jvm_aix.cpp - src/hotspot/os/bsd/jvm_bsd.cpp - src/hotspot/os/linux/jvm_linux.cpp - src/hotspot/os/solaris/jvm_solaris.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/classfile/classLoaderData.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/vmSymbols.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psPromotionManager.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.cpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.hpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/memory/iterator.hpp - src/hotspot/share/memory/metachunk.cpp - src/hotspot/share/memory/metachunk.hpp ! src/hotspot/share/memory/vtBuffer.cpp ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/objArrayKlass.cpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/oops/typeArrayKlass.cpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macro.hpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/parse.hpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/parse3.cpp ! src/hotspot/share/opto/parseHelper.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/opto/valuetypenode.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/biasedLocking.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/javaCalls.cpp ! src/hotspot/share/runtime/jniHandles.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/reflection.cpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmStructs.cpp - src/hotspot/share/runtime/vmStructs_trace.hpp ! src/hotspot/share/runtime/vm_operations.cpp - src/hotspot/share/trace/noTraceBackend.hpp - src/hotspot/share/trace/trace.dtd - src/hotspot/share/trace/trace.xml - src/hotspot/share/trace/traceBackend.cpp - src/hotspot/share/trace/traceBackend.hpp - src/hotspot/share/trace/traceDataTypes.hpp - src/hotspot/share/trace/traceEvent.hpp - src/hotspot/share/trace/traceEventClasses.xsl - src/hotspot/share/trace/traceEventIds.xsl - src/hotspot/share/trace/traceMacros.hpp - src/hotspot/share/trace/traceStream.cpp - src/hotspot/share/trace/traceStream.hpp - src/hotspot/share/trace/traceTime.hpp - src/hotspot/share/trace/traceTypes.xsl - src/hotspot/share/trace/traceevents.xml - src/hotspot/share/trace/tracerelationdecls.xml - src/hotspot/share/trace/tracetypes.xml - src/hotspot/share/trace/tracing.hpp - src/hotspot/share/trace/tracingExport.cpp - src/hotspot/share/trace/tracingExport.hpp - src/hotspot/share/trace/xinclude.mod - src/hotspot/share/trace/xsl_util.xsl ! src/hotspot/share/utilities/globalDefinitions.hpp - src/hotspot/share/utilities/ticks.inline.hpp - src/java.base/macosx/conf/x86_64/jvm.cfg ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Field.java ! src/java.base/share/classes/module-info.java - src/java.base/unix/conf/aarch64/jvm.cfg - src/java.base/unix/conf/amd64/jvm.cfg - src/java.base/unix/conf/arm/jvm.cfg - src/java.base/unix/conf/i586/jvm.cfg - src/java.base/unix/conf/ia64/jvm.cfg - src/java.base/unix/conf/ppc64/jvm.cfg - src/java.base/unix/conf/ppc64le/jvm.cfg - src/java.base/unix/conf/s390x/jvm.cfg - src/java.base/unix/conf/sparc/jvm.cfg - src/java.base/unix/conf/sparcv9/jvm.cfg - src/java.base/unix/conf/zero/jvm.cfg - src/java.base/windows/conf/amd64/jvm.cfg - src/java.base/windows/conf/i586/jvm.cfg - src/java.base/windows/conf/ia64/jvm.cfg ! 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/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.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 ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/BaseExecutableMemberTaglet.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/BaseInlineTaglet.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/HiddenTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups ! test/jdk/TEST.groups - test/jdk/java/lang/Character/Blocks.txt - test/jdk/java/lang/Character/CheckBlocks.java - test/jdk/java/lang/Character/TestISOControls.java ! test/langtools/tools/javac/diags/examples.not-yet.txt From tobias.hartmann at oracle.com Mon Jun 11 14:22:28 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 11 Jun 2018 16:22:28 +0200 Subject: Ongoing merge: Please do NOT push to lworld In-Reply-To: <1a7aa66c-2de7-ce68-56d2-7c065ae90f2f@oracle.com> References: <1a7aa66c-2de7-ce68-56d2-7c065ae90f2f@oracle.com> Message-ID: <23641bb3-dfbe-f593-909f-550921e511c5@oracle.com> The merge is done (very painful due to JDK-8202377). Thanks, Tobias On 11.06.2018 15:35, Tobias Hartmann wrote: > I'm currently working on the merge of lworld with the default branch. Please do not push any changes. > > Thanks, > Tobias > From tobias.hartmann at oracle.com Mon Jun 11 15:45:30 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 11 Jun 2018 15:45:30 +0000 Subject: hg: valhalla/valhalla: [lworld] Handle casted value type receiver in GraphKit::gen_instanceof Message-ID: <201806111545.w5BFjU9W018102@aojmv0008.oracle.com> Changeset: 091757214784 Author: thartmann Date: 2018-06-11 17:45 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/091757214784 [lworld] Handle casted value type receiver in GraphKit::gen_instanceof ! src/hotspot/share/opto/graphKit.cpp From tobias.hartmann at oracle.com Mon Jun 11 15:47:10 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 11 Jun 2018 17:47:10 +0200 Subject: hg: valhalla/valhalla: [lworld] Handle casted value type receiver in GraphKit::gen_instanceof In-Reply-To: <201806111545.w5BFjU9W018102@aojmv0008.oracle.com> References: <201806111545.w5BFjU9W018102@aojmv0008.oracle.com> Message-ID: <8de172bf-02dd-e94f-7882-06fc81458949@oracle.com> Summary: Since [1], "maybe_cast_profiled_receiver" can return a ValueTypeNode. We need to handle this properly in GraphKit::gen_instanceof to avoid failures like this: # SIGSEGV (0xb) at pc=0x00007f94eef9a7de, pid=4974, tid=4988 # # JRE version: Java(TM) SE Runtime Environment (11.0) (fastdebug build 11-internal+0-adhoc.tobias.open) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 11-internal+0-adhoc.tobias.open, mixed mode, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x6907de] AddPNode::Value(PhaseGVN*) const+0x12e Current CompileTask: C2: 67098 556 b compiler.valhalla.valuetypes.TestLWorld::test62 (5 bytes) Stack: [0x00007f94d06b3000,0x00007f94d07b4000], sp=0x00007f94d07b0950, free space=1014k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x6907de] AddPNode::Value(PhaseGVN*) const+0x12e V [libjvm.so+0x16f48cc] PhaseGVN::transform_no_reclaim(Node*)+0x13c V [libjvm.so+0xeee130] GraphKit::load_object_klass(Node*)+0xe0 V [libjvm.so+0xef49ca] GraphKit::gen_instanceof(Node*, Node*, bool)+0x6fa V [libjvm.so+0x16c549b] Parse::do_instanceof()+0x60b V [libjvm.so+0x16b8725] Parse::do_one_bytecode()+0x1075 V [libjvm.so+0x16a7dba] Parse::do_one_block()+0x39a V [libjvm.so+0x16a89d1] Parse::do_all_blocks()+0x1d1 V [libjvm.so+0x16ac47a] Parse::Parse(JVMState*, ciMethod*, float)+0xd3a V [libjvm.so+0x90161c] ParseGenerator::generate(JVMState*)+0x1fc V [libjvm.so+0xb37087] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x1027 V [libjvm.so+0x8ff702] C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x302 V [libjvm.so+0xb44d80] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x3c0 V [libjvm.so+0xb45a69] CompileBroker::compiler_thread_loop()+0x269 V [libjvm.so+0x195c8c7] JavaThread::thread_main_inner()+0x287 V [libjvm.so+0x195cb21] JavaThread::run()+0x191 V [libjvm.so+0x16408da] thread_native_entry(Thread*)+0xfa Thanks, Tobias [1] http://hg.openjdk.java.net/valhalla/valhalla/rev/17e0d6032435 On 11.06.2018 17:45, tobias.hartmann at oracle.com wrote: > Changeset: 091757214784 > Author: thartmann > Date: 2018-06-11 17:45 +0200 > URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/091757214784 > > [lworld] Handle casted value type receiver in GraphKit::gen_instanceof > > ! src/hotspot/share/opto/graphKit.cpp > From david.simms at oracle.com Tue Jun 12 09:57:19 2018 From: david.simms at oracle.com (david.simms at oracle.com) Date: Tue, 12 Jun 2018 09:57:19 +0000 Subject: hg: valhalla/valhalla: 8203293: [lworld] Test does bypass on javac null checks Message-ID: <201806120957.w5C9vKgW020483@aojmv0008.oracle.com> Changeset: 471374bf359a Author: dsimms Date: 2018-06-12 11:56 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/471374bf359a 8203293: [lworld] Test does bypass on javac null checks ! test/hotspot/jtreg/runtime/valhalla/valuetypes/FlattenableSemanticTest.java From david.simms at oracle.com Tue Jun 12 12:46:31 2018 From: david.simms at oracle.com (David Simms) Date: Tue, 12 Jun 2018 14:46:31 +0200 Subject: [lworld] RFR (XS): 8203291 - ValueTypeArray.java fails with "RuntimeException: Expected NPE" Message-ID: <914c6dd3-a9a2-ff90-6024-76ed6ad27d93@oracle.com> RFR: http://cr.openjdk.java.net/~dsimms/valhalla/8203291/ Re-enabled test of array copy for objArray to objArray of Value Type element klass (i.e. non-flat value array) Minor fix adds null and type checks...test passes, tier 1 hs and jdk tests run. There is some further clean up, reunification work to be done in this area. Obviously needs more thoughtful work with the Access API, but we can afford to defer for now. Hence comments in the ValueArrayKlass, get all the required use cases in code first, clean up later. Cheers /David Simms From rwestrel at redhat.com Tue Jun 12 13:43:43 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 12 Jun 2018 15:43:43 +0200 Subject: [lworld] RFR: C2 arraycopy intrinsic fixes In-Reply-To: <7701790a-f19e-33db-f8cd-8f542cd578d0@oracle.com> References: <7701790a-f19e-33db-f8cd-8f542cd578d0@oracle.com> Message-ID: > http://cr.openjdk.java.net/~thartmann/valhalla/lworld/arraycopy_fixes/ That looks good to me. Thanks for fixing. Roland. From tobias.hartmann at oracle.com Tue Jun 12 13:44:36 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 12 Jun 2018 15:44:36 +0200 Subject: [lworld] RFR: C2 arraycopy intrinsic fixes In-Reply-To: References: <7701790a-f19e-33db-f8cd-8f542cd578d0@oracle.com> Message-ID: <6aa983c2-835e-ba19-2fdf-a0dc4b575aed@oracle.com> Thanks, Roland! Best regards, Tobias On 12.06.2018 15:43, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/valhalla/lworld/arraycopy_fixes/ > > That looks good to me. Thanks for fixing. > > Roland. > From tobias.hartmann at oracle.com Wed Jun 13 07:44:26 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 13 Jun 2018 07:44:26 +0000 Subject: hg: valhalla/valhalla: [lworld] C2 arraycopy intrinsic fixes Message-ID: <201806130744.w5D7iQvg008603@aojmv0008.oracle.com> Changeset: fdcb3780188d Author: thartmann Date: 2018-06-13 09:44 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fdcb3780188d [lworld] C2 arraycopy intrinsic fixes Reviewed-by: roland ! src/hotspot/share/opto/macroArrayCopy.cpp From tobias.hartmann at oracle.com Wed Jun 13 09:43:38 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 13 Jun 2018 09:43:38 +0000 Subject: hg: valhalla/valhalla: [lworld] C2 fixes for crashes with TestMethodHandles.java Message-ID: <201806130943.w5D9hdjN018195@aojmv0008.oracle.com> Changeset: b21f643daee5 Author: thartmann Date: 2018-06-13 11:43 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b21f643daee5 [lworld] C2 fixes for crashes with TestMethodHandles.java ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/type.hpp From tobias.hartmann at oracle.com Wed Jun 13 09:45:06 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 13 Jun 2018 11:45:06 +0200 Subject: hg: valhalla/valhalla: [lworld] C2 fixes for crashes with TestMethodHandles.java In-Reply-To: <201806130943.w5D9hdjN018195@aojmv0008.oracle.com> References: <201806130943.w5D9hdjN018195@aojmv0008.oracle.com> Message-ID: <8b835bcb-a896-bc69-1464-520050293ba9@oracle.com> Hi, when testing with "-ea -esa -XX:CompileThreshold=100", I found some bugs: (1) GraphKit::record_profile_for_speculation() tries to improve the type of a ValueTypeNode by joining with a speculative type. As a result, we get a type system assert because TypeValueType should not be mixed with TypeOopPtr [1]. I've fixed this by implementing would_improve_type() and would_improve_ptr() for TypeValueType to return false. (2) We crash with "assert(arg->is_ValueType()) failed: inconsistent argument" in cast_argument() when inlining a method handle intrinsic because the argument type is java.lang.Object and the sig_type is a value type [2]. I've fixed and refactored the code. http://cr.openjdk.java.net/~thartmann/valhalla/lworld/mh_fixes/ Best regards, Tobias [1] Error mixing types: oopptr:TopPTR+top,iid=top (inline_depth=InlineDepthTop) (speculative=compiler/valhalla/valuetypes/MyValue1:AnyNull:exact *,iid=top (inline_depth=-1)) [narrow] and valuetype[8]:{long, int, int, short, java/lang/Integer, [I, compiler/valhalla/valuetypes/MyValue2, compiler/valhalla/valuetypes/MyValue2} [2] arg is 238: 465 ValueTypePtr === _ 414 419 422 425 428 432 436 437 451 [[ 368 ]] #compiler/valhalla/valuetypes/MyValue1:NotNull:exact * Oop:compiler/valhalla/valuetypes/MyValue1:NotNull:exact * !jvms: 0x00000008000b5840::invokeStatic @ bci:-1 0x00000008000b6c40::invoke @ bci:14 0x00000008000e2c40::invokeExact_MT @ bci:18 TestMethodHandles::test4 @ bci:3 3 Start === 3 0 [[ 3 5 6 7 8 9 ]] #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:compiler/valhalla/valuetypes/TestMethodHandles:NotNull *} 368 CheckCastPP === 5 465 [[ 238 ]] #java/lang/Object:NotNull * (speculative=compiler/valhalla/valuetypes/MyValue1:NotNull:exact * (inline_depth=4)) Oop:java/lang/Object:NotNull * (speculative=compiler/valhalla/valuetypes/MyValue1:NotNull:exact * (inline_depth=4)) !jvms: 0x00000008000b5840::invokeStatic @ bci:9 0x00000008000b6c40::invoke @ bci:14 0x00000008000e2c40::invokeExact_MT @ bci:18 TestMethodHandles::test4 @ bci:3 5 Parm === 3 [[ 551 238 368 596 ]] Control !orig=[148] !jvms: TestMethodHandles::test4 @ bci:-1 238 CheckCastPP === 5 368 [[ 551 596 ]] #java/lang/Object:NotNull * (speculative=compiler/valhalla/valuetypes/MyValue1:NotNull:exact * (inline_depth=3)) Oop:java/lang/Object:NotNull * (speculative=compiler/valhalla/valuetypes/MyValue1:NotNull:exact * (inline_depth=3)) !jvms: 0x00000008000b6c40::invoke @ bci:14 0x00000008000e2c40::invokeExact_MT @ bci:18 TestMethodHandles::test4 @ bci:3 From tobias.hartmann at oracle.com Wed Jun 13 11:08:02 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 13 Jun 2018 11:08:02 +0000 Subject: hg: valhalla/valhalla: [lworld] [Testbug] Avoid early compilation in TestArrays.java Message-ID: <201806131108.w5DB82IU014387@aojmv0008.oracle.com> Changeset: 8dd93a0470a3 Author: thartmann Date: 2018-06-13 13:07 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8dd93a0470a3 [lworld] [Testbug] Avoid early compilation in TestArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java From tobias.hartmann at oracle.com Wed Jun 13 11:10:38 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 13 Jun 2018 13:10:38 +0200 Subject: hg: valhalla/valhalla: [lworld] [Testbug] Avoid early compilation in TestArrays.java In-Reply-To: <201806131108.w5DB82IU014387@aojmv0008.oracle.com> References: <201806131108.w5DB82IU014387@aojmv0008.oracle.com> Message-ID: <3e3dd023-1f42-b554-7c05-80fba9a27d0f@oracle.com> Hi, this patch fixes a RuntimeException "Type check should have caused it to deoptimize" when running the test with -XX:CompileThreshold=100 because the method is compiled early, deoptimized and compiled again. Best regards, Tobias On 13.06.2018 13:08, tobias.hartmann at oracle.com wrote: > Changeset: 8dd93a0470a3 > Author: thartmann > Date: 2018-06-13 13:07 +0200 > URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8dd93a0470a3 > > [lworld] [Testbug] Avoid early compilation in TestArrays.java > > ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java > From karen.kinnear at oracle.com Wed Jun 13 18:29:28 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 13 Jun 2018 14:29:28 -0400 Subject: Valhalla VM notes Wed Jun 6 In-Reply-To: <3ADED9F5-D1C0-4DE4-94A4-7D960DDF5E16@oracle.com> References: <3ADED9F5-D1C0-4DE4-94A4-7D960DDF5E16@oracle.com> Message-ID: <2073DCD2-3ACF-45E1-94D8-17DAACCD7A1B@oracle.com> Accidentally sent this internally, incorporated Tobias? corrections from last week: > On Jun 12, 2018, at 6:01 PM, Karen Kinnear wrote: > > Attendees: Mandy, Frederic, Tobias, Harold, Karen, Roland joined (corrections welcome) > > 1. Frederic - VTs attribute consistency > - throws ICCE at mismatch: fields: load time, local methods: preparation time > - also check against real - at constant pool resolution time - this will cover array creation, checkcast, etc. > > was waiting for Srikanth?s updated bytecode APIs - so way to specify VTs attribute in the test > (Srikanth sent an update after that) > > - also need consistency checks between caller/callee for method invocation and remote field reference > > goal 1 correctness > goal 2 avoid mismatches > longterm picture: VBC migration - will not throw ICCE > > 2. static fields: > John wants value classes without circularity error > Karen discussed at EG meeting - AI to do an improved writeup - Dan Smith pointed out some issues if the VTs attribute is incorrect, > I need to walk-through the logic again. My AI. > Note: will never actually flatten, but need semantics of can not be null > key: creating default value before class initialization - ensuring never exposed > (Karen investigating bug found when searching here - JVMTI returns jfieldID/jmethodID without class initialization, and passed > to JNI which assumes class has already been initialized before returning jfieldID/jmethodID - Dan D also thinks this is a bug - > trying to catch holes so instance of default value does not escape > > (note: LW1: John agreed we could disallow this if we need to - i.e. keep current circularity checks if you try) > > 3. verifier for container model: done - checks bytecodes, no nullability checks > (if we need to change to non-nullable types: 3-4 lines and some additional tests) > > 4. interpreter: all set for LW1 > > 5. Classfileparser: all set for LW1 > (if we need to remove ACC_FLATTENABLE from classfile - fallback - let classfileparser add the information so internal > vm implementation unchanged after that) > > 6. JIT: > > Tobias: implementation is good for LW1 > calling convention not needed in 1st EA - we agreed - ok as optimization followup LW 1.1 or whatever > > Roland: checked in intrinsics (bugs fixed since meeting) > 1-2 intrinsics left: > hashcode/identityhashcode, (1 other maybe?) > > 7. Library work: > Discussion with Mandy: > prototyping hashcode using indy - waiting on Srikanth to generate compiler support > initial implementation is using reflection, working with Paul for MH combinators > model is to allow changing the algorithm in the library > algorithm: get all values from all fields > > Ed Note: one possibility is to have C2 support hashcode intrinsic with default algorithm and use library if user overrides > > Proposal from Mandy (correct me if this is inaccurate:) > LW1: use library only, no C2 fallback hashcode intrinsic - expect this to be slow for LW1 > improve with LW 1.1 or whatever (e.g. with caching) > > No other library work outstanding for prototype - Mandy wants to do another pass at Reflection, j.l.invoke for EA - but > code and tests are there > > 7. Work left for LW1: > 1. enable JIT intrinsics for hashcode/equals for non-value types for performance - Roland And other Object methods/bytecodes on value types - e.g. monitor enter: JDK-8204615 - Tobias working on > 2. acmp from experimental tree - Mr Simms > 3. JIT: aastore/aaload > - potential future optimizations (replace de-opts by runtime calls) - not required for LW1 > 4. Mandy/Srikanth - hashcode/identityhash/equals > 5. Frederic - update on VT consistency > > 8. Testing and stability: > Harold ran jck, jtreg without EnableValhalla - occasional small issues > Harold offered to run with EnableValhalla (he sent email update > Test with enableValhalla vs. not > > 9. Longer-term: > LW1: ship sooner - no value types as type parameters, no value-based-class migration > > LW10: 1st preview > - support for erased generics > ?working? means - e.g. pass in an array of Point and not get NPE when storing null, and not NPE when returning null and expecting Point > - language support - e.g. constructors > - preview quality: e.g. JNI, JVMTI, ? - fully featured > - open question: are atomics required? > > we would like to target JDK12 for LW10 - this may be a stretch goal - but we need to figure out what it will take > > LW100: VBC migration (also requires handling nulls) > generic specialization for optimizations > primitives as value types > > Between LW1 and LW10: may have performance optimization incremental EAs (periodically) > > 10. JIT performance today relative to null handling: > null for value type dynamic argument: catch in i2c adaptor and jump to interpreter > null for value type return: deopt (do not throw away compiled code) > check null at checklists to a value type for scalarization within a method > array store: throws ASE/NPE > > 11. Longer term proposals: > Frederic is writing up a Container Model proposal - will send in email > > thanks, > Karen > > > > > > From david.simms at oracle.com Thu Jun 14 08:40:12 2018 From: david.simms at oracle.com (David Simms) Date: Thu, 14 Jun 2018 10:40:12 +0200 Subject: [lworld] LW1 - "Minimal LWorld" Message-ID: <25d6546a-d366-03b0-0657-e3634f598356@oracle.com> Since we are approaching something "usable" in terms of "minimal L World" (LW1), we will be moving of prototyping to milestone stabilization, there issues need to be track with the following attributes: ??? label = "lw1" ??? affected-version = "repo-valhalla" ??? fixed-version = "repo-vahalla" Cheers /David Simms From david.simms at oracle.com Thu Jun 14 08:54:25 2018 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 14 Jun 2018 08:54:25 +0000 Subject: hg: valhalla/valhalla: Fixed copy_array use case objArray to objArray where dest element klass is specifically a value type Message-ID: <201806140854.w5E8sQGS026116@aojmv0008.oracle.com> Changeset: 7cd294006ef4 Author: dsimms Date: 2018-06-14 10:54 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7cd294006ef4 Fixed copy_array use case objArray to objArray where dest element klass is specifically a value type ! src/hotspot/share/oops/objArrayKlass.cpp ! src/hotspot/share/oops/valueArrayKlass.cpp ! test/hotspot/jtreg/runtime/valhalla/valuetypes/ValueTypeArray.java From tobias.hartmann at oracle.com Thu Jun 14 10:48:04 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Thu, 14 Jun 2018 10:48:04 +0000 Subject: hg: valhalla/valhalla: 8204954: [lworld] FlattenableSemanticTest crashes with assert(false) failed: DEBUG MESSAGE: null oop passed to encode_heap_oop_not_null2 Message-ID: <201806141048.w5EAm5YD003224@aojmv0008.oracle.com> Changeset: f113c7a0f6b3 Author: thartmann Date: 2018-06-14 12:47 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f113c7a0f6b3 8204954: [lworld] FlattenableSemanticTest crashes with assert(false) failed: DEBUG MESSAGE: null oop passed to encode_heap_oop_not_null2 ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/type.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestLWorld.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/FlattenableSemanticTest.java From rwestrel at redhat.com Thu Jun 14 15:58:44 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 14 Jun 2018 17:58:44 +0200 Subject: RFR(S): 8204953: [lworld] TestArrays.java crashes with "assert(is_in_g1_reserved((const void*) addr)) failed: Address 0x00000005d56dd5f0 is outside of the heap" Message-ID: http://cr.openjdk.java.net/~roland/8204953/webrev.00/ A couple fixes to clone/copyOf intrinsics: clone of an java.lang.Object array of unknown exact type can't be converted to a series or loads/stores, copyOf of an array of values to an array of unknown type can't be intrinsify. Roland. From karen.kinnear at oracle.com Thu Jun 14 17:35:30 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 14 Jun 2018 13:35:30 -0400 Subject: Value Types Optimization Dependencies Message-ID: <6828F05E-ED24-4835-BF13-EE24131ABE63@oracle.com> Value Types Optimization Dependencies Optimizations in the JVM runtime for Value Types depend on three different kinds of characteristics: Type Information: - Value Type vs. Identity Type All the optimizations below depend on the static type information, specifically the key type properties of being identity-less and immutable. It is important to ensure Value Type Consistency to enable these optimizations. This relies on disallowing value types to ever migrate to become identity types. Value-Based-Classes migrating to value types are a corner case which will require special handling. Non-nullability/flattenability Some optimizations additionally require non-nullability which enables flattenability. This could be thought of as container properties. Runtime dynamic information Some optimizations additionally require dynamic information such as: is_flattened (is flattened in heap containers) (requires flattenable, implementation-dependent) non-null (either non-nullable or dynamically non-null) Optimization Dependencies Value Types value type: identity-less & immutable non-nullable flattenable dynamic non-null is_flattened flattening in containers required required N/A Implementation-specific scalarization invocation: input arguments required not required i2c adapter null filter *1 not required scalarization invocation: return required not required caller check: if null, deopt not required scalarization field access required required type check with null filter required scalarization inside method required not required type check with null filter not required *1: Calling convention optimizations will require additional exploration. JIT optimizations have been destabilized with the introduction of the null reference for value types. Current implementation switches back to interpreted mode when a null reference to a value type is detected, it is important to have value types optimization re-enabled whenever possible; although not necessary to optimize for the null case. Considered explorations include: null profiling to scalarize only value types that are non-null most of the time support for multiple nmethods use of a new non-null emotional type/carrier type to provide non-nullability guarantees New JIT optimizations might also be required to fully optimize the different kind of value arrays. thanks, Karen From karen.kinnear at oracle.com Thu Jun 14 17:47:20 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 14 Jun 2018 13:47:20 -0400 Subject: Value Types Optimization Dependencies In-Reply-To: <6828F05E-ED24-4835-BF13-EE24131ABE63@oracle.com> References: <6828F05E-ED24-4835-BF13-EE24131ABE63@oracle.com> Message-ID: <081D5C98-A87E-4E51-86ED-1502410170A0@oracle.com> Resending - the matrix got flattened - must have thought it was a value type :-) Goal of the exercise is to clarify which optimizations depend on which characteristics, in part to understand the impact of null on optimizations. Value Types Optimization Dependencies Optimizations in the JVM runtime for Value Types depend on three different kinds of characteristics: 1. Type Information: - Value Type vs. Identity Type All the optimizations below depend on the static type information, specifically the key type properties of being identity-less and immutable. It is important to ensure Value Type Consistency to enable these optimizations. This relies on disallowing value types to ever migrate to become identity types. Value-Based-Classes migrating to value types are a corner case which will require special handling. 2. Non-nullability/flattenability Some optimizations additionally require non-nullability which enables flattenability. This could be thought of as container properties. 3. Runtime dynamic information Some optimizations additionally require dynamic information such as: is_flattened (is flattened in heap containers) (requires flattenable, implementation-dependent) non-null (either non-nullable or dynamically non-null) Optimization Dependencies Value Types value type: identity-less & immutable non-nullable flattenable dynamic non-null is_flattened flattening in containers required required N/A Implementation- specific scalarization invocation: input arguments required not required i2c adapter null filter *1 not required scalarization invocation: return required not required caller check: if null, deopt not required scalarization field access required required type check with null filter required scalarization inside method required not required type check with null filter not required *1: Calling convention optimizations will require additional exploration. The Container Model proposal outlines some possibilities. JIT optimizations have been destabilized with the introduction of the null reference for value types. Current implementation switches back to interpreted mode when a null reference to a value type is detected, it is primordial to have value types optimization re-enabled whenever possible. Considered explorations include: ? null profiling to scalarize only value types that are non-null most of the time ? support for multiple nmethods ? use of a new non-null emotional type/carrier type to provide non-nullability guarantees New JIT optimizations might also be required to fully optimize the different kind of value arrays. From tobias.hartmann at oracle.com Fri Jun 15 06:32:51 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 15 Jun 2018 08:32:51 +0200 Subject: RFR(S): 8204953: [lworld] TestArrays.java crashes with "assert(is_in_g1_reserved((const void*) addr)) failed: Address 0x00000005d56dd5f0 is outside of the heap" In-Reply-To: References: Message-ID: <58a948f8-f931-fdff-c35a-9643d9e06a74@oracle.com> Hi Roland, this looks good to me. Thanks, Tobias On 14.06.2018 17:58, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8204953/webrev.00/ > > A couple fixes to clone/copyOf intrinsics: clone of an java.lang.Object > array of unknown exact type can't be converted to a series or > loads/stores, copyOf of an array of values to an array of unknown type > can't be intrinsify. > > Roland. > From rwestrel at redhat.com Fri Jun 15 06:58:02 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 15 Jun 2018 08:58:02 +0200 Subject: RFR(S): 8204953: [lworld] TestArrays.java crashes with "assert(is_in_g1_reserved((const void*) addr)) failed: Address 0x00000005d56dd5f0 is outside of the heap" In-Reply-To: <58a948f8-f931-fdff-c35a-9643d9e06a74@oracle.com> References: <58a948f8-f931-fdff-c35a-9643d9e06a74@oracle.com> Message-ID: Thanks for looking at this, Tobias. Roland. From rwestrel at redhat.com Fri Jun 15 07:09:37 2018 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Fri, 15 Jun 2018 07:09:37 +0000 Subject: hg: valhalla/valhalla: 8204953: [lworld] TestArrays.java crashes with "assert(is_in_g1_reserved((const void*) addr)) failed: Address 0x00000005d56dd5f0 is outside of the heap" Message-ID: <201806150709.w5F79bAG028669@aojmv0008.oracle.com> Changeset: 6cf09d7aa961 Author: roland Date: 2018-06-15 09:08 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/6cf09d7aa961 8204953: [lworld] TestArrays.java crashes with "assert(is_in_g1_reserved((const void*) addr)) failed: Address 0x00000005d56dd5f0 is outside of the heap" Reviewed-by: thartmann ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/type.hpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java From karen.kinnear at oracle.com Fri Jun 15 14:00:08 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 15 Jun 2018 10:00:08 -0400 Subject: Value Types Optimization Dependencies In-Reply-To: <081D5C98-A87E-4E51-86ED-1502410170A0@oracle.com> References: <6828F05E-ED24-4835-BF13-EE24131ABE63@oracle.com> <081D5C98-A87E-4E51-86ED-1502410170A0@oracle.com> Message-ID: <73DBCC80-C093-4DBF-8DFF-3EB4E2B09858@oracle.com> resend again - Attaching the .pdf - I had cut-and-pasted from preview - sorry that didn?t translate. Feedback contents requested. thanks, Karen > > Goal of the exercise is to clarify which optimizations depend on which characteristics, in part to > understand the impact of null on optimizations. -------------- next part -------------- From forax at univ-mlv.fr Fri Jun 15 14:06:21 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 15 Jun 2018 16:06:21 +0200 (CEST) Subject: Value Types Optimization Dependencies In-Reply-To: <73DBCC80-C093-4DBF-8DFF-3EB4E2B09858@oracle.com> References: <6828F05E-ED24-4835-BF13-EE24131ABE63@oracle.com> <081D5C98-A87E-4E51-86ED-1502410170A0@oracle.com> <73DBCC80-C093-4DBF-8DFF-3EB4E2B09858@oracle.com> Message-ID: <874284786.2038458.1529071581590.JavaMail.zimbra@u-pem.fr> Hi Karen, the pdf was scrubbed. R?mi ----- Mail original ----- > De: "Karen Kinnear" > ?: "valhalla-dev" > Envoy?: Vendredi 15 Juin 2018 16:00:08 > Objet: Re: Value Types Optimization Dependencies > resend again - Attaching the .pdf - I had cut-and-pasted from preview - sorry > that didn?t translate. > Feedback contents requested. > > thanks, > Karen > >> >> Goal of the exercise is to clarify which optimizations depend on which >> characteristics, in part to > > understand the impact of null on optimizations. From karen.kinnear at oracle.com Fri Jun 15 14:33:40 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 15 Jun 2018 07:33:40 -0700 (PDT) Subject: Value Types Optimization Dependencies In-Reply-To: <874284786.2038458.1529071581590.JavaMail.zimbra@u-pem.fr> References: <6828F05E-ED24-4835-BF13-EE24131ABE63@oracle.com> <081D5C98-A87E-4E51-86ED-1502410170A0@oracle.com> <73DBCC80-C093-4DBF-8DFF-3EB4E2B09858@oracle.com> <874284786.2038458.1529071581590.JavaMail.zimbra@u-pem.fr> Message-ID: <6A04283E-7BCB-441B-B55E-E051C1D8A496@oracle.com> Value Types Optimization Dependencies Optimizations in the JVM runtime for Value Types depend on three different kinds of characteristics: Type Information: - Value Type vs. Identity Type All the optimizations below depend on the static type information, specifically the key type properties of being identity-less and immutable. It is important to ensure Value Type Consistency to enable these optimizations. This relies on disallowing value types to ever migrate to become identity types. Value-Based-Classes migrating to value types are a corner case which will require special handling. Non-nullability/flattenability Some optimizations additionally require non-nullability which enables flattenability. This could be thought of as container properties. Runtime dynamic information Some optimizations additionally require dynamic information such as: is_flattened (is flattened in heap containers) (requires flattenable, implementation-dependent) non-null (either non-nullable or dynamically non-null) *1: Calling convention optimizations will require additional exploration. Here are some possibilities. JIT optimizations have been destabilized with the introduction of the null reference for value types. Current implementation switches back to interpreted mode when a null reference to a value type is detected, it is primordial to have value types optimization re-enabled whenever possible. Considered explorations include: null profiling to scalarize only value types that are non-null most of the time support for multiple nmethods use of a new non-null emotional type/carrier type to provide non-nullability guarantees New JIT optimizations might also be required to fully optimize the different kind of value arrays. Optimization Dependencies Value Types value type: identity-less & immutable non-nullable flattenable dynamic non-null is_flattened flattening in containers required required N/A Implementation-specific scalarization invocation: input arguments required not required i2c adapter null filter *1 not required scalarization invocation: return required not required caller check: if null, deopt not required scalarization field access required required type check with null filter required scalarization inside method required not required type check with null filter not required > On Jun 15, 2018, at 10:06 AM, Remi Forax wrote: > > Hi Karen, > the pdf was scrubbed. > > R?mi > > ----- Mail original ----- >> De: "Karen Kinnear" >> ?: "valhalla-dev" >> Envoy?: Vendredi 15 Juin 2018 16:00:08 >> Objet: Re: Value Types Optimization Dependencies > >> resend again - Attaching the .pdf - I had cut-and-pasted from preview - sorry >> that didn?t translate. >> Feedback contents requested. >> >> thanks, >> Karen >> >>> >>> Goal of the exercise is to clarify which optimizations depend on which >>> characteristics, in part to >>> understand the impact of null on optimizations. From karen.kinnear at oracle.com Fri Jun 15 14:43:37 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 15 Jun 2018 10:43:37 -0400 Subject: Value Types Optimization Dependencies In-Reply-To: <6A04283E-7BCB-441B-B55E-E051C1D8A496@oracle.com> References: <6828F05E-ED24-4835-BF13-EE24131ABE63@oracle.com> <081D5C98-A87E-4E51-86ED-1502410170A0@oracle.com> <73DBCC80-C093-4DBF-8DFF-3EB4E2B09858@oracle.com> <874284786.2038458.1529071581590.JavaMail.zimbra@u-pem.fr> <6A04283E-7BCB-441B-B55E-E051C1D8A496@oracle.com> Message-ID: Trying a photo of the matrix below: > On Jun 15, 2018, at 10:33 AM, Karen Kinnear wrote: > > > Value Types Optimization Dependencies > > Optimizations in the JVM runtime for Value Types depend on three different kinds of characteristics: > > Type Information: > - Value Type vs. Identity Type > All the optimizations below depend on the static type information, specifically > the key type properties of being identity-less and immutable. > > It is important to ensure Value Type Consistency to enable these optimizations. > This relies on disallowing value types to ever migrate to become identity types. > Value-Based-Classes migrating to value types are a corner case which will require > special handling. > > Non-nullability/flattenability > Some optimizations additionally require non-nullability which enables flattenability. > This could be thought of as container properties. > > Runtime dynamic information > Some optimizations additionally require dynamic information such as: > is_flattened (is flattened in heap containers) > (requires flattenable, implementation-dependent) > non-null (either non-nullable or dynamically non-null) > > *1: Calling convention optimizations will require additional exploration. > Here are some possibilities. > > JIT optimizations have been destabilized with the introduction of the null reference for value types. Current implementation switches back to interpreted mode when a null reference to a value type is detected, it is primordial to have value types optimization re-enabled whenever possible. Considered explorations include: > null profiling to scalarize only value types that are non-null most of the time > support for multiple nmethods > use of a new non-null emotional type/carrier type to provide non-nullability guarantees > New JIT optimizations might also be required to fully optimize the different kind of value arrays. > > > > > > >> On Jun 15, 2018, at 10:06 AM, Remi Forax wrote: >> >> Hi Karen, >> the pdf was scrubbed. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Karen Kinnear" >>> ?: "valhalla-dev" >>> Envoy?: Vendredi 15 Juin 2018 16:00:08 >>> Objet: Re: Value Types Optimization Dependencies >> >>> resend again - Attaching the .pdf - I had cut-and-pasted from preview - sorry >>> that didn?t translate. >>> Feedback contents requested. >>> >>> thanks, >>> Karen >>> >>>> >>>> Goal of the exercise is to clarify which optimizations depend on which >>>> characteristics, in part to >>>> understand the impact of null on optimizations. > From karen.kinnear at oracle.com Fri Jun 15 14:52:25 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 15 Jun 2018 10:52:25 -0400 Subject: Value Types Optimization Dependencies In-Reply-To: References: <6828F05E-ED24-4835-BF13-EE24131ABE63@oracle.com> <081D5C98-A87E-4E51-86ED-1502410170A0@oracle.com> <73DBCC80-C093-4DBF-8DFF-3EB4E2B09858@oracle.com> <874284786.2038458.1529071581590.JavaMail.zimbra@u-pem.fr> <6A04283E-7BCB-441B-B55E-E051C1D8A496@oracle.com> Message-ID: Goal of this exercise is to examine what characteristics different optimizations depend on. Feedback welcome and thanks for your patience. http://cr.openjdk.java.net/~acorn/value-types-optimization-dependencies.pdf thanks, Karen From mandy.chung at oracle.com Fri Jun 15 16:01:11 2018 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 15 Jun 2018 16:01:11 +0000 Subject: hg: valhalla/valhalla: Re-enable VarHandles test to run with -XX:+EnableValhalla and JIT Message-ID: <201806151601.w5FG1Cro014926@aojmv0008.oracle.com> Changeset: f8fa4cb4e4a1 Author: mchung Date: 2018-06-15 09:00 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f8fa4cb4e4a1 Re-enable VarHandles test to run with -XX:+EnableValhalla and JIT Reviewed-by: thartmann ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template From srikanth.adayapalam at oracle.com Tue Jun 19 09:07:17 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Tue, 19 Jun 2018 09:07:17 +0000 Subject: hg: valhalla/valhalla: [lworld] Javac support for generating hashCode/equals/toString for value classes that hook into value bootstrap methods in the runtime via indy. Message-ID: <201806190907.w5J97I5h020789@aojmv0008.oracle.com> Changeset: 8c788bb6b39b Author: sadayapalam Date: 2018-06-19 14:37 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8c788bb6b39b [lworld] Javac support for generating hashCode/equals/toString for value classes that hook into value bootstrap methods in the runtime via indy. ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.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 + test/langtools/tools/javac/valhalla/lworld-values/ValueBootstrapMethodsTest.java ! test/langtools/tools/javac/valhalla/lworld-values/ValueTypesAttributeTest.java From tobias.hartmann at oracle.com Tue Jun 19 11:05:48 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 19 Jun 2018 13:05:48 +0200 Subject: [lworld] RFR(M): Multiple compiler fixes and refactoring Message-ID: Hi, please review the following change that fixes multiple problems: http://cr.openjdk.java.net/~thartmann/valhalla/lworld/field_access_fix/ 1) We hit an assert in StateVector::do_defaultvalue with "should be value type": The assert should only be executed if the klass is loaded. 2) We get a wrong result when deoptimizing at static getfield: The problem is that we always increment the stack in GraphKit::make_load for the uncommon trap but the getfield for a static field does not have a receiver on the stack. 3) We hit different asserts when inlining a method handle call because a value type argument is not passed as ValueTypeNode. The problem is in callGenerator.cpp 'cast_argument' where we should create a ValueTypeNode even if arg_type->higher_equal(sig_type). 4) To support load barriers, we should not directly emit LoadNodes in ValueTypeBaseNode::load but use GraphKit::access_load_at. I've refactored all code to use a GraphKit instance. Also, we need to support value types with non-flattened value type fields (i.e. we need to emit a null check + deopt in that case). Due to the null check when loading a non-flattened value type field, we can now deopt at all the places where we load a value type from an oop (for example, when loading from a flattened value type array, we might encounter a non-flattened value type field and need to deopt when we see null). As a result, we have to make sure that for re-execution of the current bytecode, the arguments are still on the stack (otherwise we'll hit the "must have enough JVMS stack to execute ..." assert). I've fixed some of these places but would like to defer fixing the remaining issues (and adding the corresponding tests) to another change because this one is getting quite large. All compiler and runtime value type tests pass. Thanks, Tobias From tobias.hartmann at oracle.com Tue Jun 19 14:43:10 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 19 Jun 2018 16:43:10 +0200 Subject: [lworld] RFR(M): Multiple compiler fixes and refactoring In-Reply-To: References: Message-ID: On 19.06.2018 13:05, Tobias Hartmann wrote: > 3) We hit different asserts when inlining a method handle call because a value type argument is not > passed as ValueTypeNode. The problem is in callGenerator.cpp 'cast_argument' where we should create > a ValueTypeNode even if arg_type->higher_equal(sig_type). We actually need a null check here when loading a value type from a casted oop because the lambda form can be the root of compilation (the bug only showed up with -XX:CompileThreshold=100 and my newly added test13). I've updated the webrev in place: http://cr.openjdk.java.net/~thartmann/valhalla/lworld/field_access_fix/ Thanks, Tobias From mandy.chung at oracle.com Tue Jun 19 22:59:12 2018 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 19 Jun 2018 22:59:12 +0000 Subject: hg: valhalla/valhalla: Remove static arg from hashCode BSM Message-ID: <201806192259.w5JMxD58011064@aojmv0008.oracle.com> Changeset: 283462bc0999 Author: mchung Date: 2018-06-19 15:59 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/283462bc0999 Remove static arg from hashCode BSM ! src/java.base/share/classes/java/lang/invoke/ValueBootstrapMethods.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! test/jdk/valhalla/valuetypes/ValueBootstrapMethods.java From srikanth.adayapalam at oracle.com Wed Jun 20 11:09:13 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Wed, 20 Jun 2018 11:09:13 +0000 Subject: hg: valhalla/valhalla: [lworld] Javac should emit a synthetic longHashCode() method only if the programmer hasn't supplied one. Message-ID: <201806201109.w5KB9EMO024578@aojmv0008.oracle.com> Changeset: 344695a9ca7a Author: sadayapalam Date: 2018-06-20 16:38 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/344695a9ca7a [lworld] Javac should emit a synthetic longHashCode() method only if the programmer hasn't supplied one. ! src/java.base/share/classes/java/lang/invoke/ValueBootstrapMethods.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/jdk/valhalla/valuetypes/ValueBootstrapMethods.java From sergey.kuksenko at oracle.com Wed Jun 20 18:31:05 2018 From: sergey.kuksenko at oracle.com (sergey.kuksenko at oracle.com) Date: Wed, 20 Jun 2018 18:31:05 +0000 Subject: hg: valhalla/valhalla: typo fixed Message-ID: <201806201831.w5KIV6ru021485@aojmv0008.oracle.com> Changeset: 3d7341bd8e7f Author: Sergey Kuksenko Date: 2018-06-20 11:29 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/3d7341bd8e7f typo fixed - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/ackermann/Ackermann1.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/ackermann/Ackermann2.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/ackermann/Ackermann8.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/ackermann/AckermannMix.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arraycopy/Arraycopy1.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arraycopy/Arraycopy2.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arraycopy/Arraycopy8.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arrayfill/Arrayfill1.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arrayfill/Arrayfill2.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arrayfill/Arrayfill8.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arraysum/Arraysum1.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arraysum/Arraysum2.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/arraysum/Arraysum8.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/convcopy/Convcopy1.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/convcopy/Convcopy2.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/convcopy/Convcopy8.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/invoke/Invoke.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/listsum/Listsum1.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/listsum/Listsum2.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/listsum/Listsum8.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/map/GetValue.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/map/PutValue.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/map/WalkIteratorCursor.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/map/WalkValueCursor.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/map/WalkValueEntry.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/map/WalkValueTotal.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/matrix/Value.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/search/Search1.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/search/Search2.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/search/Search8.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/sort/Sort1.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/sort/Sort2.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/sort/Sort8.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/traversal/Value.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/types/Value1.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/types/Value2.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/types/Value8.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/types/Wrapper1.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/types/Wrapper2.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/types/Wrapper8.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/util/HashMapIteratorCursor.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/util/HashMapValueCursor.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/util/HashMapValueEntry.java - test/benchmarks/src/main/java/oracle/micro/valhalla/lword/util/HashMapValueTotal.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/ackermann/Ackermann1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/ackermann/Ackermann2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/ackermann/Ackermann8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/ackermann/AckermannMix.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/arraycopy/Arraycopy1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/arraycopy/Arraycopy2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/arraycopy/Arraycopy8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/arrayfill/Arrayfill1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/arrayfill/Arrayfill2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/arrayfill/Arrayfill8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/arraysum/Arraysum1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/arraysum/Arraysum2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/arraysum/Arraysum8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/convcopy/Convcopy1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/convcopy/Convcopy2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/convcopy/Convcopy8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/invoke/Invoke.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/listsum/Listsum1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/listsum/Listsum2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/listsum/Listsum8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/map/GetValue.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/map/PutValue.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/map/WalkIteratorCursor.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/map/WalkValueCursor.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/map/WalkValueEntry.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/map/WalkValueTotal.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/matrix/Value.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/search/Search1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/search/Search2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/search/Search8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/sort/Sort1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/sort/Sort2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/sort/Sort8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/traversal/Value.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/types/Value1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/types/Value2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/types/Value8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/types/Wrapper1.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/types/Wrapper2.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/types/Wrapper8.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/util/HashMapIteratorCursor.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/util/HashMapValueCursor.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/util/HashMapValueEntry.java + test/benchmarks/src/main/java/oracle/micro/valhalla/lworld/util/HashMapValueTotal.java From sergey.kuksenko at oracle.com Wed Jun 20 18:59:59 2018 From: sergey.kuksenko at oracle.com (sergey.kuksenko at oracle.com) Date: Wed, 20 Jun 2018 18:59:59 +0000 Subject: hg: valhalla/valhalla: README.html - short benchmarks description is added Message-ID: <201806201900.w5KJ00vD012180@aojmv0008.oracle.com> Changeset: c479a5d42f52 Author: Sergey Kuksenko Date: 2018-06-20 11:59 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c479a5d42f52 README.html - short benchmarks description is added + test/benchmarks/README.html From sergey.kuksenko at oracle.com Wed Jun 20 19:02:48 2018 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Wed, 20 Jun 2018 12:02:48 -0700 Subject: Valhalla LWorld microbencmarks Message-ID: <9bcf4de8-1df0-29a8-5b21-33810bfe4268@oracle.com> Hi All, You can find initial set of Valhalla LWorld microbenchmarks in the valhalla repository under? test/benchmarks directory. A sort benchmarks overview in README.html file. to build it use maven in test/benchmarks directory. From sergey.kuksenko at oracle.com Wed Jun 20 19:10:07 2018 From: sergey.kuksenko at oracle.com (sergey.kuksenko at oracle.com) Date: Wed, 20 Jun 2018 19:10:07 +0000 Subject: hg: valhalla/valhalla: typo fix Message-ID: <201806201910.w5KJA88G019603@aojmv0008.oracle.com> Changeset: 8b02b50a24d6 Author: Sergey Kuksenko Date: 2018-06-20 12:09 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8b02b50a24d6 typo fix ! test/benchmarks/pom.xml From rwestrel at redhat.com Fri Jun 22 08:17:09 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 22 Jun 2018 10:17:09 +0200 Subject: [lworld] RFR(M): Multiple compiler fixes and refactoring In-Reply-To: References: Message-ID: Hi Tobias, > http://cr.openjdk.java.net/~thartmann/valhalla/lworld/field_access_fix/ callGenerator.cpp line 921. Shouldn't we know statically if arg is null (a null litteral) because we filter nulls early? Same question for parse1.cpp line 617. Roland. From rwestrel at redhat.com Fri Jun 22 10:05:20 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 22 Jun 2018 12:05:20 +0200 Subject: bug in hashCode() for values? Message-ID: With this patch applied: http://cr.openjdk.java.net/~roland/8205340/webrev.00/ compiler/valhalla/valuetypes/TestIntrinsics.java fails with: # SIGSEGV (0xb) at pc=0x00007f6505fd8462, pid=16347, tid=16348 # # JRE version: OpenJDK Runtime Environment (11.0) (slowdebug build 11-internal+0-adhoc.roland.valhalla) # Java VM: OpenJDK 64-Bit Server VM (slowdebug 11-internal+0-adhoc.roland.valhalla, mixed mode, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x31f462] oopDesc::klass() const+0x1e and that crash triggers with -Xint. The crash occurs in Unsafe_GetObject with stack trace: 1 - frame( sp=0x00007f8cf9946530, unextended_sp=0x00007f8cf9946530, fp=0x00007f8cf99465a0, pc=0x00007f8ce4c4685e) jdk.internal.misc.Unsafe.getObject(Native Method) 2 - frame( sp=0x00007f8cf99465b0, unextended_sp=0x00007f8cf99465c0, fp=0x00007f8cf9946630, pc=0x00007f8ce4c38300) java.lang.invoke.LambdaForm$MH/0x00000008000b0840.invoke 3 - frame( sp=0x00007f8cf9946640, unextended_sp=0x00007f8cf9946668, fp=0x00007f8cf99466c8, pc=0x00007f8ce4c38300) java.lang.invoke.LambdaForm$MH/0x00000008000cdc40.invoke 4 - frame( sp=0x00007f8cf99466d8, unextended_sp=0x00007f8cf99466f0, fp=0x00007f8cf9946750, pc=0x00007f8ce4c38300) java.lang.invoke.LambdaForm$MH/0x00000008000cb440.invoke_MT 5 - frame( sp=0x00007f8cf9946760, unextended_sp=0x00007f8cf9946768, fp=0x00007f8cf99467e0, pc=0x00007f8ce4c38300) java.lang.invoke.ValueBootstrapMethods$ValueBsmFactory.getFieldValue(ValueBootstrapMethods.java:186) 6 - frame( sp=0x00007f8cf99467f0, unextended_sp=0x00007f8cf99467e8, fp=0x00007f8cf9946860, pc=0x00007f8ce4c38300) java.lang.invoke.LambdaForm$DMH/0x00000008000a4840.invokeStatic 7 - frame( sp=0x00007f8cf9946870, unextended_sp=0x00007f8cf9946878, fp=0x00007f8cf99468f0, pc=0x00007f8ce4c38300) java.lang.invoke.LambdaForm$MH/0x00000008000b3440.invoke 8 - frame( sp=0x00007f8cf9946900, unextended_sp=0x00007f8cf9946910, fp=0x00007f8cf9946988, pc=0x00007f8ce4c38300) java.lang.invoke.LambdaForm$MH/0x00000008000c9c40.invoke 9 - frame( sp=0x00007f8cf9946998, unextended_sp=0x00007f8cf99469e8, fp=0x00007f8cf9946a48, pc=0x00007f8ce4c38300) java.lang.invoke.LambdaForm$MH/0x00000008000cb440.invoke_MT 10 - frame( sp=0x00007f8cf9946a58, unextended_sp=0x00007f8cf9946a60, fp=0x00007f8cf9946ac8, pc=0x00007f8ce4c38300) java.lang.invoke.ValueBootstrapMethods.invoke(ValueBootstrapMethods.java:262) 11 - frame( sp=0x00007f8cf9946ad8, unextended_sp=0x00007f8cf9946ae0, fp=0x00007f8cf9946b40, pc=0x00007f8ce4c38300) java.lang.invoke.ValueBootstrapMethods.valueHashCode(ValueBootstrapMethods.java:224) 12 - frame( sp=0x00007f8cf9946b50, unextended_sp=0x00007f8cf9946b58, fp=0x00007f8cf9946bb8, pc=0x00007f8ce4c37fc0) java.lang.invoke.ValueBootstrapMethods.hashCode(ValueBootstrapMethods.java:204) 13 - frame( sp=0x00007f8cf9946bc8, unextended_sp=0x00007f8cf9946bc0, fp=0x00007f8cf9946c28, pc=0x00007f8ce4c37fc0) java.lang.invoke.LambdaForm$DMH/0x00000008000c1840.invokeStatic 14 - frame( sp=0x00007f8cf9946c38, unextended_sp=0x00007f8cf9946c40, fp=0x00007f8cf9946ca8, pc=0x00007f8ce4c37fc0) java.lang.invoke.LambdaForm$MH/0x00000008000ca840.invoke 15 - frame( sp=0x00007f8cf9946cb8, unextended_sp=0x00007f8cf9946cc8, fp=0x00007f8cf9946d28, pc=0x00007f8ce4c37fc0) java.lang.invoke.LambdaForm$MH/0x00000008000cb040.linkToTargetMethod 16 - frame( sp=0x00007f8cf9946d38, unextended_sp=0x00007f8cf9946d38, fp=0x00007f8cf9946d98, pc=0x00007f8ce4c3804a) compiler.valhalla.valuetypes.MyValue1.hashCode(MyValue1.java:26) 17 - frame( sp=0x00007f8cf9946da8, unextended_sp=0x00007f8cf9946da8, fp=0x00007f8cf9946e00, pc=0x00007f8ce4c37fc0) compiler.valhalla.valuetypes.TestIntrinsics.test6(TestIntrinsics.java:142) Roland. From mandy.chung at oracle.com Fri Jun 22 18:29:03 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 22 Jun 2018 11:29:03 -0700 Subject: bug in hashCode() for values? In-Reply-To: References: Message-ID: Frederic, Attached is a simple test reproducing it. It fails when Unsafe::getObject on a field of value type. Mandy On 6/22/18 3:05 AM, Roland Westrelin wrote: > > With this patch applied: > > http://cr.openjdk.java.net/~roland/8205340/webrev.00/ > > compiler/valhalla/valuetypes/TestIntrinsics.java fails with: > > # SIGSEGV (0xb) at pc=0x00007f6505fd8462, pid=16347, tid=16348 > # > # JRE version: OpenJDK Runtime Environment (11.0) (slowdebug build 11-internal+0-adhoc.roland.valhalla) > # Java VM: OpenJDK 64-Bit Server VM (slowdebug 11-internal+0-adhoc.roland.valhalla, mixed mode, compressed oops, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x31f462] oopDesc::klass() const+0x1e > > and that crash triggers with -Xint. The crash occurs in Unsafe_GetObject > with stack trace: > > 1 - frame( sp=0x00007f8cf9946530, unextended_sp=0x00007f8cf9946530, fp=0x00007f8cf99465a0, pc=0x00007f8ce4c4685e) > jdk.internal.misc.Unsafe.getObject(Native Method) > 2 - frame( sp=0x00007f8cf99465b0, unextended_sp=0x00007f8cf99465c0, fp=0x00007f8cf9946630, pc=0x00007f8ce4c38300) > java.lang.invoke.LambdaForm$MH/0x00000008000b0840.invoke > 3 - frame( sp=0x00007f8cf9946640, unextended_sp=0x00007f8cf9946668, fp=0x00007f8cf99466c8, pc=0x00007f8ce4c38300) > java.lang.invoke.LambdaForm$MH/0x00000008000cdc40.invoke > 4 - frame( sp=0x00007f8cf99466d8, unextended_sp=0x00007f8cf99466f0, fp=0x00007f8cf9946750, pc=0x00007f8ce4c38300) > java.lang.invoke.LambdaForm$MH/0x00000008000cb440.invoke_MT > 5 - frame( sp=0x00007f8cf9946760, unextended_sp=0x00007f8cf9946768, fp=0x00007f8cf99467e0, pc=0x00007f8ce4c38300) > java.lang.invoke.ValueBootstrapMethods$ValueBsmFactory.getFieldValue(ValueBootstrapMethods.java:186) > 6 - frame( sp=0x00007f8cf99467f0, unextended_sp=0x00007f8cf99467e8, fp=0x00007f8cf9946860, pc=0x00007f8ce4c38300) > java.lang.invoke.LambdaForm$DMH/0x00000008000a4840.invokeStatic > 7 - frame( sp=0x00007f8cf9946870, unextended_sp=0x00007f8cf9946878, fp=0x00007f8cf99468f0, pc=0x00007f8ce4c38300) > java.lang.invoke.LambdaForm$MH/0x00000008000b3440.invoke > 8 - frame( sp=0x00007f8cf9946900, unextended_sp=0x00007f8cf9946910, fp=0x00007f8cf9946988, pc=0x00007f8ce4c38300) > java.lang.invoke.LambdaForm$MH/0x00000008000c9c40.invoke > 9 - frame( sp=0x00007f8cf9946998, unextended_sp=0x00007f8cf99469e8, fp=0x00007f8cf9946a48, pc=0x00007f8ce4c38300) > java.lang.invoke.LambdaForm$MH/0x00000008000cb440.invoke_MT > 10 - frame( sp=0x00007f8cf9946a58, unextended_sp=0x00007f8cf9946a60, fp=0x00007f8cf9946ac8, pc=0x00007f8ce4c38300) > java.lang.invoke.ValueBootstrapMethods.invoke(ValueBootstrapMethods.java:262) > 11 - frame( sp=0x00007f8cf9946ad8, unextended_sp=0x00007f8cf9946ae0, fp=0x00007f8cf9946b40, pc=0x00007f8ce4c38300) > java.lang.invoke.ValueBootstrapMethods.valueHashCode(ValueBootstrapMethods.java:224) > 12 - frame( sp=0x00007f8cf9946b50, unextended_sp=0x00007f8cf9946b58, fp=0x00007f8cf9946bb8, pc=0x00007f8ce4c37fc0) > java.lang.invoke.ValueBootstrapMethods.hashCode(ValueBootstrapMethods.java:204) > 13 - frame( sp=0x00007f8cf9946bc8, unextended_sp=0x00007f8cf9946bc0, fp=0x00007f8cf9946c28, pc=0x00007f8ce4c37fc0) > java.lang.invoke.LambdaForm$DMH/0x00000008000c1840.invokeStatic > 14 - frame( sp=0x00007f8cf9946c38, unextended_sp=0x00007f8cf9946c40, fp=0x00007f8cf9946ca8, pc=0x00007f8ce4c37fc0) > java.lang.invoke.LambdaForm$MH/0x00000008000ca840.invoke > 15 - frame( sp=0x00007f8cf9946cb8, unextended_sp=0x00007f8cf9946cc8, fp=0x00007f8cf9946d28, pc=0x00007f8ce4c37fc0) > java.lang.invoke.LambdaForm$MH/0x00000008000cb040.linkToTargetMethod > 16 - frame( sp=0x00007f8cf9946d38, unextended_sp=0x00007f8cf9946d38, fp=0x00007f8cf9946d98, pc=0x00007f8ce4c3804a) > compiler.valhalla.valuetypes.MyValue1.hashCode(MyValue1.java:26) > 17 - frame( sp=0x00007f8cf9946da8, unextended_sp=0x00007f8cf9946da8, fp=0x00007f8cf9946e00, pc=0x00007f8ce4c37fc0) > compiler.valhalla.valuetypes.TestIntrinsics.test6(TestIntrinsics.java:142) > > Roland. > -------------- next part -------------- public class ValueHashCode { static final __ByValue class Point { public final int x; public final int y; Point() { x = 10; y = 20; } public static Point makePoint(int x, int y) { Point p = __MakeDefault Point(); p = __WithField(p.x, x); p = __WithField(p.y, y); return p; } } static final __ByValue class Point2 { final Point p; final int i; Point2 () { p = Point.makePoint(0,0); i = 0; } public static Point2 make(int x, int y, int i) { Point2 p = __MakeDefault Point2(); p = __WithField(p.p, Point.makePoint(x,y)); p = __WithField(p.i, i); return p; } } public static void main(String... args) { Point2 p = Point2.make(10, 20, 30); p.hashCode(); } } From mandy.chung at oracle.com Fri Jun 22 23:49:34 2018 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 22 Jun 2018 23:49:34 +0000 Subject: hg: valhalla/valhalla: Add test to verify hashCode/equals/toString Message-ID: <201806222349.w5MNnZIs023152@aojmv0008.oracle.com> Changeset: e5cec7364448 Author: mchung Date: 2018-06-22 16:48 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e5cec7364448 Add test to verify hashCode/equals/toString + test/jdk/valhalla/valuetypes/Line.java + test/jdk/valhalla/valuetypes/ObjectMethods.java From forax at univ-mlv.fr Sat Jun 23 22:28:41 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 24 Jun 2018 00:28:41 +0200 (CEST) Subject: c1 crashes ? Message-ID: <939492355.2043225.1529792921911.JavaMail.zimbra@u-pem.fr> I've started to do some tests of the lword implementation, i think i've seen a mail saying that c1 was not ready but i'm not able to find it now, can someone confirm that ? Otherwise, i will be happy to send some crash reports :) cheers, R?mi From srikanth.adayapalam at oracle.com Mon Jun 25 08:03:20 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Mon, 25 Jun 2018 08:03:20 +0000 Subject: hg: valhalla/valhalla: [lworld] Relax the requirement that value classes and their instance fields must be explicitlymarked final; Make them implicitly final automatically. Message-ID: <201806250803.w5P83KRe010538@aojmv0008.oracle.com> Changeset: 3d51c1a5997d Author: sadayapalam Date: 2018-06-25 13:33 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/3d51c1a5997d [lworld] Relax the requirement that value classes and their instance fields must be explicitlymarked final; Make them implicitly final automatically. ! 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/TypeEnter.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 ! test/langtools/tools/javac/diags/examples.not-yet.txt ! test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.java ! test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.out From rwestrel at redhat.com Mon Jun 25 08:40:36 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 25 Jun 2018 10:40:36 +0200 Subject: c1 crashes ? In-Reply-To: <939492355.2043225.1529792921911.JavaMail.zimbra@u-pem.fr> References: <939492355.2043225.1529792921911.JavaMail.zimbra@u-pem.fr> Message-ID: > I've started to do some tests of the lword implementation, > i think i've seen a mail saying that c1 was not ready but i'm not able to find it now, > can someone confirm that ? > > Otherwise, i will be happy to send some crash reports :) c1 is not supported and tiered compilation should be forced off when valhalla is enabled so you shouldn't see any crash. Roland. From forax at univ-mlv.fr Mon Jun 25 09:07:07 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 25 Jun 2018 11:07:07 +0200 (CEST) Subject: c1 crashes ? In-Reply-To: References: <939492355.2043225.1529792921911.JavaMail.zimbra@u-pem.fr> Message-ID: <1460712418.141251.1529917627415.JavaMail.zimbra@u-pem.fr> I've not enabled valhalla :) it seems to work without (apart c1 crash). R?mi ----- Mail original ----- > De: "Roland Westrelin" > ?: "Remi Forax" , "valhalla-dev" > Envoy?: Lundi 25 Juin 2018 10:40:36 > Objet: Re: c1 crashes ? >> I've started to do some tests of the lword implementation, >> i think i've seen a mail saying that c1 was not ready but i'm not able to find >> it now, >> can someone confirm that ? >> >> Otherwise, i will be happy to send some crash reports :) > > c1 is not supported and tiered compilation should be forced off when > valhalla is enabled so you shouldn't see any crash. > > Roland. From rwestrel at redhat.com Mon Jun 25 09:13:06 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 25 Jun 2018 11:13:06 +0200 Subject: c1 crashes ? In-Reply-To: <1460712418.141251.1529917627415.JavaMail.zimbra@u-pem.fr> References: <939492355.2043225.1529792921911.JavaMail.zimbra@u-pem.fr> <1460712418.141251.1529917627415.JavaMail.zimbra@u-pem.fr> Message-ID: > it seems to work without (apart c1 crash). Do you have a test case for the c1 crash? Roland. From forax at univ-mlv.fr Mon Jun 25 09:29:17 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 25 Jun 2018 11:29:17 +0200 (CEST) Subject: c1 crashes ? In-Reply-To: References: <939492355.2043225.1529792921911.JavaMail.zimbra@u-pem.fr> <1460712418.141251.1529917627415.JavaMail.zimbra@u-pem.fr> Message-ID: <281714394.156878.1529918957955.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Roland Westrelin" > ?: "Remi Forax" > Cc: "valhalla-dev" > Envoy?: Lundi 25 Juin 2018 11:13:06 > Objet: Re: c1 crashes ? >> it seems to work without (apart c1 crash). > > Do you have a test case for the c1 crash? yes, sure, see below. > > Roland. R?mi --- public final __ByValue class IntBox { private final int value; private IntBox() { this.value = 0; } @Override public String toString() { return "" + value; } public int compareTo(IntBox box) { return Integer.compare(value, box.value); } public IntBox add(IntBox box) { return IntBox.valueOf(value + box.value); } public static IntBox valueOf(int value) { IntBox box = __MakeDefault IntBox(); box = __WithField(box.value, value); return box; } private static IntBox sum(IntBox n) { IntBox sum = IntBox.valueOf(0); for(IntBox i = IntBox.valueOf(0); i.compareTo(n) < 0; i = i.add(IntBox.valueOf(1))) { sum = sum.add(i); } return sum; } public static void main(String[] args) { for(int i = 0; i < 100_000; i++) { sum(IntBox.valueOf(i)); } } } From srikanth.adayapalam at oracle.com Mon Jun 25 09:32:23 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Mon, 25 Jun 2018 09:32:23 +0000 Subject: hg: valhalla/valhalla: [lworld] Additional test for value finality in class files. Message-ID: <201806250932.w5P9WNvZ009020@aojmv0008.oracle.com> Changeset: 3b5dcc4e9eab Author: sadayapalam Date: 2018-06-25 15:02 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/3b5dcc4e9eab [lworld] Additional test for value finality in class files. ! test/langtools/tools/javac/valhalla/lworld-values/CheckFlags.java ! test/langtools/tools/javac/valhalla/lworld-values/Point.java From srikanth.adayapalam at oracle.com Mon Jun 25 10:56:06 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Mon, 25 Jun 2018 10:56:06 +0000 Subject: hg: valhalla/valhalla: [lworld] Forbid value types from being type arguments in generic parameterizations / bounds / witnesses (allowed for experiments under -XDallowGenericsOverValues) Message-ID: <201806251056.w5PAu6mJ005633@aojmv0008.oracle.com> Changeset: e57fd40276e4 Author: sadayapalam Date: 2018-06-25 16:25 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/e57fd40276e4 [lworld] Forbid value types from being type arguments in generic parameterizations / bounds / witnesses (allowed for experiments under -XDallowGenericsOverValues) ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java + test/langtools/tools/javac/valhalla/lworld-values/ValueOverGenericsTest.java + test/langtools/tools/javac/valhalla/lworld-values/ValueOverGenericsTest.out + test/langtools/tools/javac/valhalla/lworld-values/ValueOverGenericsTest2.out ! test/langtools/tools/javac/valhalla/lworld-values/ValuesAsRefs.java From srikanth.adayapalam at oracle.com Mon Jun 25 12:25:53 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Mon, 25 Jun 2018 12:25:53 +0000 Subject: hg: valhalla/valhalla: [lworld] Javac should not recognize or specially handle value based classes (unless invoked with the experimental mode -XDallowValueBasedClasses) Message-ID: <201806251225.w5PCPsRC005261@aojmv0008.oracle.com> Changeset: a46d0912cbe9 Author: sadayapalam Date: 2018-06-25 17:55 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/a46d0912cbe9 [lworld] Javac should not recognize or specially handle value based classes (unless invoked with the experimental mode -XDallowValueBasedClasses) ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! test/langtools/tools/javac/valhalla/lworld-values/CastNullCheckTest.java ! test/langtools/tools/javac/valhalla/lworld-values/CheckDefaultFlattenable.java ! test/langtools/tools/javac/valhalla/lworld-values/DemoteToValueBasedTest.java ! test/langtools/tools/javac/valhalla/lworld-values/DemoteToValueBasedTest.out ! test/langtools/tools/javac/valhalla/lworld-values/DemoteToValueBasedTest10.out + test/langtools/tools/javac/valhalla/lworld-values/DemoteToValueBasedTest3.out ! test/langtools/tools/javac/valhalla/lworld-values/NullPollutionTest.java ! test/langtools/tools/javac/valhalla/lworld-values/NullPollutionTest.out ! test/langtools/tools/javac/valhalla/lworld-values/ValueBasedWarningsTest.java ! test/langtools/tools/javac/valhalla/lworld-values/ValueBasedWarningsTest.out + test/langtools/tools/javac/valhalla/lworld-values/ValueBasedWarningsTest2.out From srikanth.adayapalam at oracle.com Mon Jun 25 13:10:51 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Mon, 25 Jun 2018 13:10:51 +0000 Subject: hg: valhalla/valhalla: [lworld] Fix test failure due to missing option Message-ID: <201806251310.w5PDAqlV019194@aojmv0008.oracle.com> Changeset: 41ab91b9d169 Author: sadayapalam Date: 2018-06-25 18:40 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/41ab91b9d169 [lworld] Fix test failure due to missing option ! test/langtools/tools/javac/diags/examples/SuspiciousNullMix.java From paul.sandoz at oracle.com Mon Jun 25 16:28:41 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 25 Jun 2018 09:28:41 -0700 Subject: JDK-8161256 In-Reply-To: <5B2DA78C.2090100@zeus.net.au> References: <5B2DA78C.2090100@zeus.net.au> Message-ID: Hi Peter, Moving to the Valhalla list, which is probably the closest matching list. We have given some thought about these additional constant pool tags but nothing concrete has arisen from that with regards to a JEP (and thus targeting the current non-existent JEP to a release would be even further out). As of now there has not been a strong requirement/priority for such tags but there might be in the future if other features can benefit from them. I will likely talk about these and other possible enhancements at JVMLS this year. Paul. > On Jun 22, 2018, at 6:51 PM, Peter wrote: > > Will a JEP be created for general data in constant pools? > > CONSTANT_Bytes - tag byte 2 > CONSTANT_Group - tag byte 13 > > The attraction of allowing general data in constant pools, is that it may stabilise the constant pool, there have been a number of additions to the constant pool since Java 8 and this feature, while adding two more constants, reduces future need or motivation for growing the constant pool. > > It's my understanding that Java 11 will be a long term support release, like Java 8. Will this be added in Java 12? > > Thanks, > > Peter. From forax at univ-mlv.fr Mon Jun 25 16:37:49 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 25 Jun 2018 18:37:49 +0200 (CEST) Subject: JDK-8161256 In-Reply-To: References: <5B2DA78C.2090100@zeus.net.au> Message-ID: <1875188614.358504.1529944669807.JavaMail.zimbra@u-pem.fr> Hi Peter, you can simulate the equivalent of a Constant_Bytes by base64 encoding your bytes and pass the resulting string to a Constant Dynamic which at runtime will load it, decode it and return it as a byte array. R?mi ----- Mail original ----- > De: "Paul Sandoz" > ?: "Peter" > Cc: "valhalla-dev" > Envoy?: Lundi 25 Juin 2018 18:28:41 > Objet: Re: JDK-8161256 > Hi Peter, > > Moving to the Valhalla list, which is probably the closest matching list. > > We have given some thought about these additional constant pool tags but nothing > concrete has arisen from that with regards to a JEP (and thus targeting the > current non-existent JEP to a release would be even further out). As of now > there has not been a strong requirement/priority for such tags but there might > be in the future if other features can benefit from them. > > I will likely talk about these and other possible enhancements at JVMLS this > year. > > Paul. > > >> On Jun 22, 2018, at 6:51 PM, Peter wrote: >> >> Will a JEP be created for general data in constant pools? >> >> CONSTANT_Bytes - tag byte 2 >> CONSTANT_Group - tag byte 13 >> >> The attraction of allowing general data in constant pools, is that it may >> stabilise the constant pool, there have been a number of additions to the >> constant pool since Java 8 and this feature, while adding two more constants, >> reduces future need or motivation for growing the constant pool. >> >> It's my understanding that Java 11 will be a long term support release, like >> Java 8. Will this be added in Java 12? >> >> Thanks, >> > > Peter. From john.r.rose at oracle.com Mon Jun 25 17:57:19 2018 From: john.r.rose at oracle.com (John Rose) Date: Mon, 25 Jun 2018 10:57:19 -0700 Subject: constant pool futures In-Reply-To: <1875188614.358504.1529944669807.JavaMail.zimbra@u-pem.fr> References: <5B2DA78C.2090100@zeus.net.au> <1875188614.358504.1529944669807.JavaMail.zimbra@u-pem.fr> Message-ID: On Jun 25, 2018, at 9:37 AM, Remi Forax wrote: > > Hi Peter, > you can simulate the equivalent of a Constant_Bytes by base64 encoding your bytes > and pass the resulting string to a Constant Dynamic which at runtime will load it, > decode it and return it as a byte array. You can also simulate a CONSTANT_Group by using a long array of arguments to the bootstrap method. As of 10, the limit of 255 arguments has been lifted; the class file format can handle up to 2^16-1 extra arguments. The BSM has to be a varargs method of course, since no method can get more than 255 positional arguments on the stack, including receiver and (if present) method handle. As of 11, the CONSTANT_Dynamic constant allows direct "ldc" of a constant computed directly by a BSM (without an intermediate indy or CallSite). The constant can be of any type expressible by the JVM. Crucially, such a constant can be an input to a BSM for a larger constant or call site; this introduces something like expression trees into the constant pool. For example, if you combine List.of with ConstantBootstraps.invoke plus a list of constants, you get a constant List of anything expressible in the constant pool (including other Lists). That's the present. The future of Java is shaped by the people who work hard to create it, but even they can't predict it accurately, although they try to write roadmaps and discuss their aspirations with the community. (We are not hiding secret plans or schedules!) I can say a few things about the how constant pool features fit into the big picture, but I can't predict which releases they will land in. The future Bytes and Group constants are envisioned as helpers for scaling complex class files toward lower overheads and higher limits. The existing workarounds have certain overheads and limits that we would probably like to remove in the longer term. For example, a base64 encoding string has a maximum payload length of about 0.75 * 2^16 octets. *Also*, using base64 requires one or more throwaway intermediate copies of the envelope and payload; this is the overhead of using a simulation instead of direct expression of a sequence of octets. Personally, I'd like to see more *zero copy* data structures in classfiles, just like Linux object files support zero copy read-only data, using file mapping. But zero copy data requires every layer of the system to support either immutability or (at worst) lazy copy on write, and also support "views" on the original data. This means we have to tune certain Java APIs to avoid statefulness and avoid certain data types. Java arrays can't do zero copy views for the same reasons they can't do slices. Value types will eventually help reduce the overheads of views, reducing zero copy API overheads. The Bytes constant is envisioned as scaling to at least 2^31-1 and perhaps beyond, and will not require decoding or copying. As such it is a potential replacement for resource files, as well as a carrier for short "binary string" data. Before we can do this in a copy-free manner, we need either an interface like CharSequence for bytes, or else a kind of ByteBuffer which has no state and is read-only. IMO the ByteBuffer improvements should play out a little longer before we decide what is the type of an "ldc" of a CONSTANT_Bytes constant. The requirements on this structure are close to (but not identical with) a ByteBuffer. My money is on a simple ByteSequence interface which ByteBuffer (and other types) will implement for interoperability, but the "ldc" of a Bytes constant should load a flyweight object (perhaps a value type) which does little more than hold the virtual address of a slice of a classfile (perhaps mapped from disk); this is probably lighter than any ByteBuffer. Likewise, the simulation of groups using BSM arguments has a maximum payload length of 2^16-1, and burns a constant pool index for each (distinct) BSM argument. Since there are only 2^16-1 possible CP entries, this is a serious cost. The Group format is envisioned as expressing a range of CP entries which do *not* consume global CP entry indexes. Uses of Group constants which don't have large number of resolved constants might be better coded as serialized bundles of bits, wrapped in a CONSTANT_Bytes envelope and deserialized from an ad hoc encoding. You can see how the simulation overheads and limits stack up if you then require such a bundle in a base64 string. It's not obvious on first glance, but if you think about it a long group of constants has a likely scalability requirement that the constants not be resolved eagerly for their bootstrap method. I.e,. the BSM should somehow be able to control the sequencing of constant resolution, including even deferring some constants to be resolved *after* the BSM returns (at some future point when the BSM logic needs the resolved constant). This requires another bit of VM functionality, the BootstrapCallInfo API, which allows a BSM to fully control resolution. This is will a WIP although it is (non-public) in the sources. In order for the BootstrapCallInfo API to properly express unresolved constants, we first need to land the JVM Constants API (JEP 334). Given the number of people available to work on various projects, we are working on these features as quickly as we can. There's a mix of sizes: Small things like ByteBuffer upgrades, medium like CONSTANT_Dynamic, and large like value types. Because such features tend to be interrelated, there's also a natural order in which we are approaching them. Also, the speed of development depends not only on the number of hands working on the technology but also on the surprising complexity of properly developing core JVM features, even supposedly simple one like CONSTANT_Dynamic. Coding is a fraction of the required work; there is also test development, integration, spec. development, several kinds of review, and iterative polishing; are are necessary to get a result our users will enjoy, and we'll be proud of, even a decade later. So even the simplest JVM feature requires a total of years of labor. We'll talk more about this at the JVM Language Summit and Oracle Committers' Workshop. I hope we can continue to spread the work around more to current partners like Intel and Red Hat. I will be delighted to talk to conference attenders in great detail about this stuff. HTH ? John From forax at univ-mlv.fr Tue Jun 26 07:03:35 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 26 Jun 2018 09:03:35 +0200 (CEST) Subject: constant pool futures In-Reply-To: References: <5B2DA78C.2090100@zeus.net.au> <1875188614.358504.1529944669807.JavaMail.zimbra@u-pem.fr> Message-ID: <1827422181.444870.1529996614993.JavaMail.zimbra@u-pem.fr> Hi John, ----- Mail original ----- > De: "John Rose" > ?: "Remi Forax" , "Peter" > Cc: "valhalla-dev" > Envoy?: Lundi 25 Juin 2018 19:57:19 > Objet: constant pool futures > On Jun 25, 2018, at 9:37 AM, Remi Forax wrote: >> >> Hi Peter, >> you can simulate the equivalent of a Constant_Bytes by base64 encoding your >> bytes >> and pass the resulting string to a Constant Dynamic which at runtime will load >> it, >> decode it and return it as a byte array. > > > You can also simulate a CONSTANT_Group by using a long array of arguments > to the bootstrap method. > > As of 10, the limit of 255 arguments has been lifted; the class file format can > handle > up to 2^16-1 extra arguments. The BSM has to be a varargs method of course, > since no method can get more than 255 positional arguments on the stack, > including receiver and (if present) method handle. > > As of 11, the CONSTANT_Dynamic constant allows direct "ldc" of a constant > computed directly by a BSM (without an intermediate indy or CallSite). The > constant can be of any type expressible by the JVM. Crucially, such a constant > can be an input to a BSM for a larger constant or call site; this introduces > something > like expression trees into the constant pool. For example, if you combine > List.of > with ConstantBootstraps.invoke plus a list of constants, you get a constant List > of anything expressible in the constant pool (including other Lists). > > That's the present. The future of Java is shaped by the people who work hard > to create it, but even they can't predict it accurately, although they try to > write roadmaps and discuss their aspirations with the community. (We are not hiding > secret plans or schedules!) I can say a few things about the how constant pool > features fit into the big picture, but I can't predict which releases they will > land in. > > The future Bytes and Group constants are envisioned as helpers for scaling > complex class files toward lower overheads and higher limits. The existing workarounds > have certain overheads and limits that we would probably like to remove in the > longer term. For example, a base64 encoding string has a maximum payload > length of about 0.75 * 2^16 octets. *Also*, using base64 requires one or more > throwaway intermediate copies of the envelope and payload; this is the overhead > of using a simulation instead of direct expression of a sequence of octets. > > Personally, I'd like to see more *zero copy* data structures in classfiles, just > like Linux object files support zero copy read-only data, using file mapping. > But zero copy data requires every layer of the system to support either > immutability or (at worst) lazy copy on write, and also support "views" on > the original data. This means we have to tune certain Java APIs to avoid > statefulness and avoid certain data types. Java arrays can't do zero copy > views for the same reasons they can't do slices. Value types will eventually > help reduce the overheads of views, reducing zero copy API overheads. > > The Bytes constant is envisioned as scaling to at least 2^31-1 and perhaps > beyond, and will not require decoding or copying. As such it is a potential replacement > for resource files, as well as a carrier for short "binary string" data. Before we > can do this in a copy-free manner, we need either an interface like CharSequence for > bytes, or else a kind of ByteBuffer which has no state and is read-only. IMO the > ByteBuffer improvements should play out a little longer before we decide what is the type > of an "ldc" of a CONSTANT_Bytes constant. The requirements on this structure are > close to (but not identical with) a ByteBuffer. My money is on a simple > ByteSequence interface which ByteBuffer (and other types) will implement for > interoperability, but the "ldc" of a Bytes constant should load a flyweight object (perhaps a > value type) which does little more than hold the virtual address of a slice of a > classfile (perhaps mapped from disk); this is probably lighter than any ByteBuffer. Refactoring ByteBuffer (subclasses or at least the readonly impl) to be a value types is impossible with the value type current design (a value type can not inherit from an abstract class), so an interface like ByteSequence makes sense but it means re-implementing a lot of methods (slice, bulk copy, etc) on ByteSequence. > > Likewise, the simulation of groups using BSM arguments has a maximum payload > length of 2^16-1, and burns a constant pool index for each (distinct) BSM > argument. > Since there are only 2^16-1 possible CP entries, this is a serious cost. The Group > format is envisioned as expressing a range of CP entries which do *not* consume > global CP entry indexes. Uses of Group constants which don't have large number > of resolved constants might be better coded as serialized bundles of bits, wrapped > in a CONSTANT_Bytes envelope and deserialized from an ad hoc encoding. > You can see how the simulation overheads and limits stack up if you then require > such a bundle in a base64 string. > > It's not obvious on first glance, but if you think about it a long group of > constants has a likely scalability requirement that the constants not be resolved eagerly > for their bootstrap method. I.e,. the BSM should somehow be able to control > the sequencing of constant resolution, including even deferring some constants > to be resolved *after* the BSM returns (at some future point when the BSM > logic needs the resolved constant). This requires another bit of VM > functionality, the BootstrapCallInfo API, which allows a BSM to fully control resolution. > This is will a WIP although it is (non-public) in the sources. > > In order for the BootstrapCallInfo API to properly express unresolved constants, > we first need to land the JVM Constants API (JEP 334). I'm not sure to see the link here. Anyway, the BootstrapCallInfo API from a language runtime implementor because currently i use some strings instead of the proper constants because of the early initialization. > > Given the number of people available to work on various projects, we are working > on these features as quickly as we can. There's a mix of sizes: Small things like > ByteBuffer upgrades, medium like CONSTANT_Dynamic, and large like value > types. Because such features tend to be interrelated, there's also a natural > order in which we are approaching them. Also, the speed of development depends not > only on the number of hands working on the technology but also on the surprising > complexity of properly developing core JVM features, even supposedly simple > one like CONSTANT_Dynamic. Coding is a fraction of the required work; there > is also test development, integration, spec. development, several kinds of > review, and iterative polishing; are are necessary to get a result our users will enjoy, > and we'll be proud of, even a decade later. So even the simplest JVM feature > requires a total of years of labor. > > We'll talk more about this at the JVM Language Summit and Oracle Committers' > Workshop. I hope we can continue to spread the work around more to current > partners like Intel and Red Hat. I will be delighted to talk to conference > attenders in great detail about this stuff. s/Oracle Committers' Workshop/OpenJDK Committers' Workshop ? > > HTH > ? John R?mi From john.r.rose at oracle.com Tue Jun 26 07:28:15 2018 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Jun 2018 00:28:15 -0700 Subject: constant pool futures In-Reply-To: <1827422181.444870.1529996614993.JavaMail.zimbra@u-pem.fr> References: <5B2DA78C.2090100@zeus.net.au> <1875188614.358504.1529944669807.JavaMail.zimbra@u-pem.fr> <1827422181.444870.1529996614993.JavaMail.zimbra@u-pem.fr> Message-ID: On Jun 26, 2018, at 12:03 AM, forax at univ-mlv.fr wrote: > > Hi John, > > ----- Mail original ----- >> De: "John Rose" >> ?: "Remi Forax" , "Peter" >> Cc: "valhalla-dev" >> Envoy?: Lundi 25 Juin 2018 19:57:19 >> Objet: constant pool futures > >>> On Jun 25, 2018, at 9:37 AM, Remi Forax wrote: >>> >>> Hi Peter, >>> you can simulate the equivalent of a Constant_Bytes by base64 encoding your >>> bytes >>> and pass the resulting string to a Constant Dynamic which at runtime will load >>> it, >>> decode it and return it as a byte array. >> >> >> You can also simulate a CONSTANT_Group by using a long array of arguments >> to the bootstrap method. >> >> As of 10, the limit of 255 arguments has been lifted; the class file format can >> handle >> up to 2^16-1 extra arguments. The BSM has to be a varargs method of course, >> since no method can get more than 255 positional arguments on the stack, >> including receiver and (if present) method handle. >> >> As of 11, the CONSTANT_Dynamic constant allows direct "ldc" of a constant >> computed directly by a BSM (without an intermediate indy or CallSite). The >> constant can be of any type expressible by the JVM. Crucially, such a constant >> can be an input to a BSM for a larger constant or call site; this introduces >> something >> like expression trees into the constant pool. For example, if you combine >> List.of >> with ConstantBootstraps.invoke plus a list of constants, you get a constant List >> of anything expressible in the constant pool (including other Lists). >> >> That's the present. The future of Java is shaped by the people who work hard >> to create it, but even they can't predict it accurately, although they try to >> write roadmaps and discuss their aspirations with the community. (We are not hiding >> secret plans or schedules!) I can say a few things about the how constant pool >> features fit into the big picture, but I can't predict which releases they will >> land in. >> >> The future Bytes and Group constants are envisioned as helpers for scaling >> complex class files toward lower overheads and higher limits. The existing workarounds >> have certain overheads and limits that we would probably like to remove in the >> longer term. For example, a base64 encoding string has a maximum payload >> length of about 0.75 * 2^16 octets. *Also*, using base64 requires one or more >> throwaway intermediate copies of the envelope and payload; this is the overhead >> of using a simulation instead of direct expression of a sequence of octets. >> >> Personally, I'd like to see more *zero copy* data structures in classfiles, just >> like Linux object files support zero copy read-only data, using file mapping. >> But zero copy data requires every layer of the system to support either >> immutability or (at worst) lazy copy on write, and also support "views" on >> the original data. This means we have to tune certain Java APIs to avoid >> statefulness and avoid certain data types. Java arrays can't do zero copy >> views for the same reasons they can't do slices. Value types will eventually >> help reduce the overheads of views, reducing zero copy API overheads. >> >> The Bytes constant is envisioned as scaling to at least 2^31-1 and perhaps >> beyond, and will not require decoding or copying. As such it is a potential replacement >> for resource files, as well as a carrier for short "binary string" data. Before we >> can do this in a copy-free manner, we need either an interface like CharSequence for >> bytes, or else a kind of ByteBuffer which has no state and is read-only. IMO the >> ByteBuffer improvements should play out a little longer before we decide what is the type >> of an "ldc" of a CONSTANT_Bytes constant. The requirements on this structure are >> close to (but not identical with) a ByteBuffer. My money is on a simple >> ByteSequence interface which ByteBuffer (and other types) will implement for >> interoperability, but the "ldc" of a Bytes constant should load a flyweight object (perhaps a >> value type) which does little more than hold the virtual address of a slice of a >> classfile (perhaps mapped from disk); this is probably lighter than any ByteBuffer. > > Refactoring ByteBuffer (subclasses or at least the readonly impl) to be a value types is impossible with the value type current design (a value type can not inherit from an abstract class), so an interface like ByteSequence makes sense but it means re-implementing a lot of methods (slice, bulk copy, etc) on ByteSequence. Yes, it will be harder to put BSeq over B.B. than it was to put CSeq over String but I think we must. > >> >> Likewise, the simulation of groups using BSM arguments has a maximum payload >> length of 2^16-1, and burns a constant pool index for each (distinct) BSM >> argument. >> Since there are only 2^16-1 possible CP entries, this is a serious cost. The Group >> format is envisioned as expressing a range of CP entries which do *not* consume >> global CP entry indexes. Uses of Group constants which don't have large number >> of resolved constants might be better coded as serialized bundles of bits, wrapped >> in a CONSTANT_Bytes envelope and deserialized from an ad hoc encoding. >> You can see how the simulation overheads and limits stack up if you then require >> such a bundle in a base64 string. >> >> It's not obvious on first glance, but if you think about it a long group of >> constants has a likely scalability requirement that the constants not be resolved eagerly >> for their bootstrap method. I.e,. the BSM should somehow be able to control >> the sequencing of constant resolution, including even deferring some constants >> to be resolved *after* the BSM returns (at some future point when the BSM >> logic needs the resolved constant). This requires another bit of VM >> functionality, the BootstrapCallInfo API, which allows a BSM to fully control resolution. >> This is will a WIP although it is (non-public) in the sources. >> >> In order for the BootstrapCallInfo API to properly express unresolved constants, >> we first need to land the JVM Constants API (JEP 334). > > I'm not sure to see the link here. With natural representation of unresolved CP items we can have a getUnresolved/getSymbolic access method on BCI that avoids resolving. > > Anyway, the BootstrapCallInfo API from a language runtime implementor because currently i use some strings instead of the proper constants because of the early initialization. It would be better to access the full structure of the CP instead of just the strings in it. > >> >> Given the number of people available to work on various projects, we are working >> on these features as quickly as we can. There's a mix of sizes: Small things like >> ByteBuffer upgrades, medium like CONSTANT_Dynamic, and large like value >> types. Because such features tend to be interrelated, there's also a natural >> order in which we are approaching them. Also, the speed of development depends not >> only on the number of hands working on the technology but also on the surprising >> complexity of properly developing core JVM features, even supposedly simple >> one like CONSTANT_Dynamic. Coding is a fraction of the required work; there >> is also test development, integration, spec. development, several kinds of >> review, and iterative polishing; are are necessary to get a result our users will enjoy, >> and we'll be proud of, even a decade later. So even the simplest JVM feature >> requires a total of years of labor. >> >> We'll talk more about this at the JVM Language Summit and Oracle Committers' >> Workshop. I hope we can continue to spread the work around more to current >> partners like Intel and Red Hat. I will be delighted to talk to conference >> attenders in great detail about this stuff. > > s/Oracle Committers' Workshop/OpenJDK Committers' Workshop ? Wow, just wow. Can I blame this one on autocomplete?? Of course I am referring to OpenJDK committers, not just the Oracle ones. > >> >> HTH >> ? John > > R?mi From srikanth.adayapalam at oracle.com Tue Jun 26 07:33:15 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Tue, 26 Jun 2018 07:33:15 +0000 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. Message-ID: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> Changeset: 8b2ca4fdb101 Author: sadayapalam Date: 2018-06-26 13:02 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8b2ca4fdb101 [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! test/langtools/tools/javac/valhalla/lworld-values/CheckDefaultFlattenable.java ! test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.java ! test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.out ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableFlagFromClass.java ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableFlagTest.java ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableNegativeTest.java ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableNegativeTest.out ! test/langtools/tools/javac/valhalla/lworld-values/Point.java From srikanth.adayapalam at oracle.com Tue Jun 26 07:41:21 2018 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 26 Jun 2018 13:11:21 +0530 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> Message-ID: <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> On Tuesday 26 June 2018 01:03 PM, srikanth.adayapalam at oracle.com wrote: > Changeset: 8b2ca4fdb101 > Author: sadayapalam > Date: 2018-06-26 13:02 +0530 > URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8b2ca4fdb101 > > [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. Hi Karen, This change set removes source level support for the field modifiers __Flattenable and __NotFlattened. Per your suggestion/request, I have still left in ACC_FLATTENABLE. All instance fields declared as value types are marked as ACC_FLATTENABLE at the class file for LW1 and the static fields are not so marked. However, in the course of implementing this, it occurred to me that we may as well have gone the whole way and the flag ACC_FLATTENABLE may also have been completely withdrawn - It is not clear to me that the "All instance fields declared as value types are marked as ACC_FLATTENABLE at the class file for LW1 and the static fields are not so marked." strategy offers much for the VM - this could have been "derived" by the VM without their being a flag such as ACC_FLATTENABLE. But I will wait for a go from you before getting rid of all traces of ACC_FLATTENABLE. Thanks! Srikanth > > ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java > ! test/langtools/tools/javac/valhalla/lworld-values/CheckDefaultFlattenable.java > ! test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.java > ! test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.out > ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableFlagFromClass.java > ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableFlagTest.java > ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableNegativeTest.java > ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableNegativeTest.out > ! test/langtools/tools/javac/valhalla/lworld-values/Point.java > From forax at univ-mlv.fr Tue Jun 26 08:41:22 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 26 Jun 2018 10:41:22 +0200 (CEST) Subject: constant pool futures In-Reply-To: References: <5B2DA78C.2090100@zeus.net.au> <1875188614.358504.1529944669807.JavaMail.zimbra@u-pem.fr> <1827422181.444870.1529996614993.JavaMail.zimbra@u-pem.fr> Message-ID: <1461505254.522079.1530002482804.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "John Rose" > ?: "Remi Forax" > Cc: "Peter" , "valhalla-dev" > Envoy?: Mardi 26 Juin 2018 09:28:15 > Objet: Re: constant pool futures > On Jun 26, 2018, at 12:03 AM, forax at univ-mlv.fr wrote: >> >> Hi John, >> >> ----- Mail original ----- >>> De: "John Rose" >>> ?: "Remi Forax" , "Peter" >>> Cc: "valhalla-dev" >>> Envoy?: Lundi 25 Juin 2018 19:57:19 >>> Objet: constant pool futures >> >>>> On Jun 25, 2018, at 9:37 AM, Remi Forax wrote: >>>> >>>> Hi Peter, >>>> you can simulate the equivalent of a Constant_Bytes by base64 encoding your >>>> bytes >>>> and pass the resulting string to a Constant Dynamic which at runtime will load >>>> it, >>>> decode it and return it as a byte array. >>> >>> >>> You can also simulate a CONSTANT_Group by using a long array of arguments >>> to the bootstrap method. >>> >>> As of 10, the limit of 255 arguments has been lifted; the class file format can >>> handle >>> up to 2^16-1 extra arguments. The BSM has to be a varargs method of course, >>> since no method can get more than 255 positional arguments on the stack, >>> including receiver and (if present) method handle. >>> >>> As of 11, the CONSTANT_Dynamic constant allows direct "ldc" of a constant >>> computed directly by a BSM (without an intermediate indy or CallSite). The >>> constant can be of any type expressible by the JVM. Crucially, such a constant >>> can be an input to a BSM for a larger constant or call site; this introduces >>> something >>> like expression trees into the constant pool. For example, if you combine >>> List.of >>> with ConstantBootstraps.invoke plus a list of constants, you get a constant List >>> of anything expressible in the constant pool (including other Lists). >>> >>> That's the present. The future of Java is shaped by the people who work hard >>> to create it, but even they can't predict it accurately, although they try to >>> write roadmaps and discuss their aspirations with the community. (We are not >>> hiding >>> secret plans or schedules!) I can say a few things about the how constant pool >>> features fit into the big picture, but I can't predict which releases they will >>> land in. >>> >>> The future Bytes and Group constants are envisioned as helpers for scaling >>> complex class files toward lower overheads and higher limits. The existing >>> workarounds >>> have certain overheads and limits that we would probably like to remove in the >>> longer term. For example, a base64 encoding string has a maximum payload >>> length of about 0.75 * 2^16 octets. *Also*, using base64 requires one or more >>> throwaway intermediate copies of the envelope and payload; this is the overhead >>> of using a simulation instead of direct expression of a sequence of octets. >>> >>> Personally, I'd like to see more *zero copy* data structures in classfiles, just >>> like Linux object files support zero copy read-only data, using file mapping. >>> But zero copy data requires every layer of the system to support either >>> immutability or (at worst) lazy copy on write, and also support "views" on >>> the original data. This means we have to tune certain Java APIs to avoid >>> statefulness and avoid certain data types. Java arrays can't do zero copy >>> views for the same reasons they can't do slices. Value types will eventually >>> help reduce the overheads of views, reducing zero copy API overheads. >>> >>> The Bytes constant is envisioned as scaling to at least 2^31-1 and perhaps >>> beyond, and will not require decoding or copying. As such it is a potential >>> replacement >>> for resource files, as well as a carrier for short "binary string" data. Before >>> we >>> can do this in a copy-free manner, we need either an interface like CharSequence >>> for >>> bytes, or else a kind of ByteBuffer which has no state and is read-only. IMO >>> the >>> ByteBuffer improvements should play out a little longer before we decide what is >>> the type >>> of an "ldc" of a CONSTANT_Bytes constant. The requirements on this structure >>> are >>> close to (but not identical with) a ByteBuffer. My money is on a simple >>> ByteSequence interface which ByteBuffer (and other types) will implement for >>> interoperability, but the "ldc" of a Bytes constant should load a flyweight >>> object (perhaps a >>> value type) which does little more than hold the virtual address of a slice of a >>> classfile (perhaps mapped from disk); this is probably lighter than any >>> ByteBuffer. >> >> Refactoring ByteBuffer (subclasses or at least the readonly impl) to be a value >> types is impossible with the value type current design (a value type can not >> inherit from an abstract class), so an interface like ByteSequence makes sense >> but it means re-implementing a lot of methods (slice, bulk copy, etc) on >> ByteSequence. > > > Yes, it will be harder to put BSeq over B.B. than it was to put CSeq over String > but I think we must. >> >>> >>> Likewise, the simulation of groups using BSM arguments has a maximum payload >>> length of 2^16-1, and burns a constant pool index for each (distinct) BSM >>> argument. >>> Since there are only 2^16-1 possible CP entries, this is a serious cost. The >>> Group >>> format is envisioned as expressing a range of CP entries which do *not* consume >>> global CP entry indexes. Uses of Group constants which don't have large number >>> of resolved constants might be better coded as serialized bundles of bits, >>> wrapped >>> in a CONSTANT_Bytes envelope and deserialized from an ad hoc encoding. >>> You can see how the simulation overheads and limits stack up if you then require >>> such a bundle in a base64 string. >>> >>> It's not obvious on first glance, but if you think about it a long group of >>> constants has a likely scalability requirement that the constants not be >>> resolved eagerly >>> for their bootstrap method. I.e,. the BSM should somehow be able to control >>> the sequencing of constant resolution, including even deferring some constants >>> to be resolved *after* the BSM returns (at some future point when the BSM >>> logic needs the resolved constant). This requires another bit of VM >>> functionality, the BootstrapCallInfo API, which allows a BSM to fully control >>> resolution. >>> This is will a WIP although it is (non-public) in the sources. >>> >>> In order for the BootstrapCallInfo API to properly express unresolved constants, >>> we first need to land the JVM Constants API (JEP 334). >> >> I'm not sure to see the link here. > > With natural representation of unresolved CP items we can have a > getUnresolved/getSymbolic access method on BCI that avoids resolving. ok, got it, you want BootstrapCallInfo not only to provide lazy/deferred evaluation but be able to provide an unresolved version of each CP item, hence the link. >> >> Anyway, the BootstrapCallInfo API from a language runtime implementor because >> currently i use some strings instead of the proper constants because of the >> early initialization. > > It would be better to access the full structure of the CP instead of just the > strings in it. yes, i fully agree, (my sentence above would be far easier to understood with the words 'is a great addition' after implementor). >> >>> >>> Given the number of people available to work on various projects, we are working >>> on these features as quickly as we can. There's a mix of sizes: Small things >>> like >>> ByteBuffer upgrades, medium like CONSTANT_Dynamic, and large like value >>> types. Because such features tend to be interrelated, there's also a natural >>> order in which we are approaching them. Also, the speed of development depends >>> not >>> only on the number of hands working on the technology but also on the surprising >>> complexity of properly developing core JVM features, even supposedly simple >>> one like CONSTANT_Dynamic. Coding is a fraction of the required work; there >>> is also test development, integration, spec. development, several kinds of >>> review, and iterative polishing; are are necessary to get a result our users >>> will enjoy, >>> and we'll be proud of, even a decade later. So even the simplest JVM feature >>> requires a total of years of labor. >>> >>> We'll talk more about this at the JVM Language Summit and Oracle Committers' >>> Workshop. I hope we can continue to spread the work around more to current >>> partners like Intel and Red Hat. I will be delighted to talk to conference >>> attenders in great detail about this stuff. >> >> s/Oracle Committers' Workshop/OpenJDK Committers' Workshop ? > > Wow, just wow. Can I blame this one on autocomplete?? Of course I am referring > to OpenJDK committers, not just the Oracle ones. > :) R?mi From tobias.hartmann at oracle.com Tue Jun 26 08:52:50 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 26 Jun 2018 10:52:50 +0200 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> Message-ID: <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> Hi, this change breaks all our value types tests because we are extensively using the __Flattenable and __NotFlattened modifiers (see last Mach5 results email). I understand that we don't want to support __NotFlattened for lw1 but shouldn't we leave the functionality in and guard it by an (experimental) javac flag or something? Thanks, Tobias On 26.06.2018 09:41, Srikanth wrote: > > > On Tuesday 26 June 2018 01:03 PM, srikanth.adayapalam at oracle.com wrote: >> Changeset: 8b2ca4fdb101 >> Author:??? sadayapalam >> Date:????? 2018-06-26 13:02 +0530 >> URL:?????? http://hg.openjdk.java.net/valhalla/valhalla/rev/8b2ca4fdb101 >> >> [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. > > Hi Karen, > > This change set removes source level support for the field modifiers __Flattenable and __NotFlattened. > Per your suggestion/request, I have still left in ACC_FLATTENABLE. All instance fields declared as > value types are marked as ACC_FLATTENABLE at the class file for LW1 and the static fields are not so > marked. > > However, in the course of implementing this, it occurred to me that we may as well have gone the > whole way and the flag ACC_FLATTENABLE may also have been completely withdrawn - It is not clear to > me that the "All instance fields declared as value types are marked as ACC_FLATTENABLE at the class > file for LW1 and the static fields are not so marked." strategy offers much for the VM - this could > have been "derived" by the VM without their being a flag such as ACC_FLATTENABLE. > > But I will wait for a go from you before getting rid of all traces of ACC_FLATTENABLE. > > Thanks! > Srikanth > > >> >> ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java >> ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java >> ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java >> ! test/langtools/tools/javac/valhalla/lworld-values/CheckDefaultFlattenable.java >> ! test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.java >> ! test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.out >> ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableFlagFromClass.java >> ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableFlagTest.java >> ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableNegativeTest.java >> ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableNegativeTest.out >> ! test/langtools/tools/javac/valhalla/lworld-values/Point.java >> > From srikanth.adayapalam at oracle.com Tue Jun 26 09:21:56 2018 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 26 Jun 2018 14:51:56 +0530 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> Message-ID: <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> On Tuesday 26 June 2018 02:22 PM, Tobias Hartmann wrote: > Hi, > > this change breaks all our value types tests because we are extensively using the __Flattenable and > __NotFlattened modifiers (see last Mach5 results email). I understand that we don't want to support > __NotFlattened for lw1 but shouldn't we leave the functionality in and guard it by an (experimental) > javac flag or something? > > Thanks, > Tobias Hi Tobias, I am sorry that there is some pain caused by this change, but I believe it is a hit that is preferably taken sooner. Brian and John are of the opinion that the __Flattenable and __NotFlattened modifiers as well as ACC_FLATTENABLE should go as soon as possible. The fix for these broken tests should be simple - to simply delete the __Flattenable keyword from the tests. An instance field whose type is a value class is automatically marked ACC_FLATTENABLE and so the __Flattenable modifier is redundant. Srikanth. > > On 26.06.2018 09:41, Srikanth wrote: >> >> On Tuesday 26 June 2018 01:03 PM, srikanth.adayapalam at oracle.com wrote: >>> Changeset: 8b2ca4fdb101 >>> Author:??? sadayapalam >>> Date:????? 2018-06-26 13:02 +0530 >>> URL:?????? http://hg.openjdk.java.net/valhalla/valhalla/rev/8b2ca4fdb101 >>> >>> [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. >> Hi Karen, >> >> This change set removes source level support for the field modifiers __Flattenable and __NotFlattened. >> Per your suggestion/request, I have still left in ACC_FLATTENABLE. All instance fields declared as >> value types are marked as ACC_FLATTENABLE at the class file for LW1 and the static fields are not so >> marked. >> >> However, in the course of implementing this, it occurred to me that we may as well have gone the >> whole way and the flag ACC_FLATTENABLE may also have been completely withdrawn - It is not clear to >> me that the "All instance fields declared as value types are marked as ACC_FLATTENABLE at the class >> file for LW1 and the static fields are not so marked." strategy offers much for the VM - this could >> have been "derived" by the VM without their being a flag such as ACC_FLATTENABLE. >> >> But I will wait for a go from you before getting rid of all traces of ACC_FLATTENABLE. >> >> Thanks! >> Srikanth >> >> >>> ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java >>> ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java >>> ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java >>> ! test/langtools/tools/javac/valhalla/lworld-values/CheckDefaultFlattenable.java >>> ! test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.java >>> ! test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.out >>> ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableFlagFromClass.java >>> ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableFlagTest.java >>> ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableNegativeTest.java >>> ! test/langtools/tools/javac/valhalla/lworld-values/FlattenableNegativeTest.out >>> ! test/langtools/tools/javac/valhalla/lworld-values/Point.java >>> From tobias.hartmann at oracle.com Tue Jun 26 09:30:19 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 26 Jun 2018 11:30:19 +0200 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> Message-ID: Hi Srikanth, On 26.06.2018 11:21, Srikanth wrote: > I am sorry that there is some pain caused by this change, but I believe it is a hit that is > preferably taken sooner. Brian and John are of the opinion that the __Flattenable and __NotFlattened > modifiers as well as ACC_FLATTENABLE should go as soon as possible. > > The fix for these broken tests should be simple - to simply delete the __Flattenable keyword from > the tests. An instance field whose type is a value class is automatically marked ACC_FLATTENABLE and > so the __Flattenable modifier is redundant. Yes, I agree with that but my understanding was that we do want to support non-flattened value type fields after LW1 (and in fact we already fully support them). How do we continue to test this now without a way to declare such fields in the tests? Thanks, Tobias From srikanth.adayapalam at oracle.com Tue Jun 26 09:37:32 2018 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 26 Jun 2018 15:07:32 +0530 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> Message-ID: <53abe74c-2b1c-79bf-eeb8-c4774f17fd4a@oracle.com> On Tuesday 26 June 2018 03:00 PM, Tobias Hartmann wrote: > Hi Srikanth, > > On 26.06.2018 11:21, Srikanth wrote: >> I am sorry that there is some pain caused by this change, but I believe it is a hit that is >> preferably taken sooner. Brian and John are of the opinion that the __Flattenable and __NotFlattened >> modifiers as well as ACC_FLATTENABLE should go as soon as possible. >> >> The fix for these broken tests should be simple - to simply delete the __Flattenable keyword from >> the tests. An instance field whose type is a value class is automatically marked ACC_FLATTENABLE and >> so the __Flattenable modifier is redundant. > Yes, I agree with that but my understanding was that we do want to support non-flattened value type > fields after LW1 (and in fact we already fully support them). How do we continue to test this now > without a way to declare such fields in the tests? Hi Tobias, I did have an express go from Karen to "nuke" these source level modifiers before proceeding. But in light of what you say, I'll take a look and see what is involved in pushing these under an option instead. Even with that many of the tests would need "massaging" but I guess it won't shut you out from retaining the support for non-flattened value type fields. Srikanth > > Thanks, > Tobias From tobias.hartmann at oracle.com Tue Jun 26 10:02:44 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 26 Jun 2018 12:02:44 +0200 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <53abe74c-2b1c-79bf-eeb8-c4774f17fd4a@oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> <53abe74c-2b1c-79bf-eeb8-c4774f17fd4a@oracle.com> Message-ID: Hi Srikanth, On 26.06.2018 11:37, Srikanth wrote: > I did have an express go from Karen to "nuke" these source level modifiers before proceeding. But in > light of what you say, I'll take a look and see what is involved in pushing these under an option > instead. Thanks for looking into it but we should probably wait for Karen to comment on that. I guess I missed the discussion/decision of fully removing these modifiers (I thought we just don't want to support them for LW1). > Even with that many of the tests would need "massaging" but I guess it won't shut you out from > retaining the support for non-flattened value type fields. Yes, I'm fine with modifying the tests, I'm just concerned that without testing the implementation of non-flattenable fields in the JVM, the code will start to rot very soon. Thanks, Tobias From srikanth.adayapalam at oracle.com Tue Jun 26 10:08:18 2018 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 26 Jun 2018 15:38:18 +0530 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> <53abe74c-2b1c-79bf-eeb8-c4774f17fd4a@oracle.com> Message-ID: <70fbad77-2b90-9e0b-4acc-6e6af25835d9@oracle.com> On Tuesday 26 June 2018 03:32 PM, Tobias Hartmann wrote: > Hi Srikanth, > > On 26.06.2018 11:37, Srikanth wrote: >> I did have an express go from Karen to "nuke" these source level modifiers before proceeding. But in >> light of what you say, I'll take a look and see what is involved in pushing these under an option >> instead. > Thanks for looking into it but we should probably wait for Karen to comment on that. I guess I > missed the discussion/decision of fully removing these modifiers (I thought we just don't want to > support them for LW1). Sounds good to me. I'll keep a patch ready in any case and after hearing from Karen decide to push or discard. I believe the consensus in the VM is to move away fromACC_FLATTENABLE on fields to using the ValueTypes attribute. Your concern below about the code rot is valid. Srikanth > >> Even with that many of the tests would need "massaging" but I guess it won't shut you out from >> retaining the support for non-flattened value type fields. > Yes, I'm fine with modifying the tests, I'm just concerned that without testing the implementation > of non-flattenable fields in the JVM, the code will start to rot very soon. > > Thanks, > Tobias From srikanth.adayapalam at oracle.com Tue Jun 26 11:23:19 2018 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 26 Jun 2018 16:53:19 +0530 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <70fbad77-2b90-9e0b-4acc-6e6af25835d9@oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> <53abe74c-2b1c-79bf-eeb8-c4774f17fd4a@oracle.com> <70fbad77-2b90-9e0b-4acc-6e6af25835d9@oracle.com> Message-ID: <47608021-f50c-dcfa-5d22-28f0f3e32219@oracle.com> The attached patch would cause the flattenability modifiers to be accepted with their erstwhile syntax and semantics when javac is invoked with -XDallowFlattenabilityModifiers I'll wait to hear from Karen and push/discard accordingly. (I am likely away Thursday/Friday, I will be available on Wednesday. Posting a patch here, so if it is required in my absence it can be availed. It passes all langtools tests) Thanks! Srikanth On Tuesday 26 June 2018 03:38 PM, Srikanth wrote: > > > On Tuesday 26 June 2018 03:32 PM, Tobias Hartmann wrote: >> Hi Srikanth, >> >> On 26.06.2018 11:37, Srikanth wrote: >>> I did have an express go from Karen to "nuke" these source level >>> modifiers before proceeding. But in >>> light of what you say, I'll take a look and see what is involved in >>> pushing these under an option >>> instead. >> Thanks for looking into it but we should probably wait for Karen to >> comment on that. I guess I >> missed the discussion/decision of fully removing these modifiers (I >> thought we just don't want to >> support them for LW1). > > Sounds good to me. I'll keep a patch ready in any case and after > hearing from Karen decide to push or discard. > > I believe the consensus in the VM is to move away fromACC_FLATTENABLE > on fields to using the ValueTypes attribute. > > Your concern below about the code rot is valid. > > Srikanth >> >>> Even with that many of the tests would need "massaging" but I guess >>> it won't shut you out from >>> retaining the support for non-flattened value type fields. >> Yes, I'm fine with modifying the tests, I'm just concerned that >> without testing the implementation >> of non-flattenable fields in the JVM, the code will start to rot very >> soon. >> >> Thanks, >> Tobias > -------------- next part -------------- diff -r 8b2ca4fdb101 src/java.compiler/share/classes/javax/lang/model/element/Modifier.java --- a/src/java.compiler/share/classes/javax/lang/model/element/Modifier.java Tue Jun 26 13:02:54 2018 +0530 +++ b/src/java.compiler/share/classes/javax/lang/model/element/Modifier.java Tue Jun 26 16:49:37 2018 +0530 @@ -63,6 +63,17 @@ * @since 1.11 */ VALUE, + /** + * The modifier {@code __Flattenable} + * @since 1.11 + */ + FLATTENABLE, + + /** + * The modifier {@code __NotFlattened} + * @since 1.11 + */ + NOT_FLATTENED, /** The modifier {@code static} */ STATIC, /** The modifier {@code final} */ FINAL, diff -r 8b2ca4fdb101 src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java Tue Jun 26 13:02:54 2018 +0530 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java Tue Jun 26 16:49:37 2018 +0530 @@ -230,6 +230,11 @@ public static final long UNION = 1L<<39; /** + * Flag that marks field that is a value instance that can be inlined in the layout. + */ + public static final long FLATTENABLE = 1L<<40; + + /** * Flag that marks an 'effectively final' local variable. */ public static final long EFFECTIVELY_FINAL = 1L<<41; @@ -321,6 +326,11 @@ public static final long ANONCONSTR_BASED = 1L<<57; /** + * Flag that marks field that is a value instance that SHOULD NOT be inlined in the layout. + */ + public static final long NOT_FLATTENED = 1L<<58; + + /** * Flag that marks finalize block as body-only, should not be copied into catch clauses. * Used to implement try-with-resources. */ @@ -339,13 +349,13 @@ MethodFlags = AccessFlags | ABSTRACT | STATIC | NATIVE | SYNCHRONIZED | FINAL | STRICTFP; public static final long - ExtendedStandardFlags = (long)StandardFlags | DEFAULT | VALUE, - ModifierFlags = ((long)StandardFlags & ~INTERFACE) | DEFAULT, + ExtendedStandardFlags = (long)StandardFlags | DEFAULT | VALUE | FLATTENABLE | NOT_FLATTENED, + ModifierFlags = ((long)StandardFlags & ~INTERFACE) | DEFAULT | FLATTENABLE | NOT_FLATTENED, InterfaceMethodMask = ABSTRACT | PRIVATE | STATIC | PUBLIC | STRICTFP | DEFAULT, AnnotationTypeElementMask = ABSTRACT | PUBLIC, LocalVarFlags = FINAL | PARAMETER, VarFlags = AccessFlags | FINAL | STATIC | - VOLATILE | TRANSIENT | ENUM, + VOLATILE | TRANSIENT | FLATTENABLE | NOT_FLATTENED | ENUM, ReceiverParamFlags = PARAMETER; @@ -360,6 +370,8 @@ if (0 != (flags & STATIC)) modifiers.add(Modifier.STATIC); if (0 != (flags & FINAL)) modifiers.add(Modifier.FINAL); if (0 != (flags & TRANSIENT)) modifiers.add(Modifier.TRANSIENT); + if (0 != (flags & FLATTENABLE)) modifiers.add(Modifier.FLATTENABLE); + if (0 != (flags & NOT_FLATTENED)) modifiers.add(Modifier.NOT_FLATTENED); if (0 != (flags & VOLATILE)) modifiers.add(Modifier.VOLATILE); if (0 != (flags & SYNCHRONIZED)) modifiers.add(Modifier.SYNCHRONIZED); @@ -428,6 +440,8 @@ HYPOTHETICAL(Flags.HYPOTHETICAL), PROPRIETARY(Flags.PROPRIETARY), UNION(Flags.UNION), + FLATTENABLE(Flags.FLATTENABLE), + NOT_FLATTENED(Flags.NOT_FLATTENED), EFFECTIVELY_FINAL(Flags.EFFECTIVELY_FINAL), CLASH(Flags.CLASH), AUXILIARY(Flags.AUXILIARY), diff -r 8b2ca4fdb101 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Tue Jun 26 13:02:54 2018 +0530 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Tue Jun 26 16:49:37 2018 +0530 @@ -1201,6 +1201,10 @@ setSyntheticVariableType(tree, v.type); } } + if (v.owner.kind == TYP && types.isValue(v.type) && !types.isValueBased(v.type)) { + if ((v.flags() & (STATIC | NOT_FLATTENED)) == 0) + v.flags_field |= FLATTENABLE; + } result = tree.type = v.type; } finally { diff -r 8b2ca4fdb101 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java Tue Jun 26 13:02:54 2018 +0530 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java Tue Jun 26 16:49:37 2018 +0530 @@ -93,6 +93,7 @@ private final Target target; private final Profile profile; private final boolean warnOnAnyAccessToMembers; + private final boolean rejectValueMembershipCycles; private final boolean allowGenericsOverValues; private final boolean allowValueBasedClasses; @@ -135,6 +136,7 @@ source = Source.instance(context); target = Target.instance(context); warnOnAnyAccessToMembers = options.isSet("warnOnAccessToMembers"); + rejectValueMembershipCycles = options.isSet("rejectValueMembershipCycles"); allowGenericsOverValues = options.isSet("allowGenericsOverValues"); allowValueBasedClasses = options.isSet("allowValueBasedClasses"); Target target = Target.instance(context); @@ -2226,7 +2228,11 @@ } // where private boolean cyclePossible(VarSymbol symbol) { - return !symbol.isStatic() && types.isValue(symbol.type); + if (symbol.isStatic()) + return false; + if (rejectValueMembershipCycles && types.isValue(symbol.type)) + return true; + return (symbol.flags() & FLATTENABLE) != 0 && types.isValue(symbol.type); } void checkNonCyclicDecl(JCClassDecl tree) { diff -r 8b2ca4fdb101 src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java Tue Jun 26 13:02:54 2018 +0530 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java Tue Jun 26 16:49:37 2018 +0530 @@ -2932,6 +2932,11 @@ ***********************************************************************/ long adjustFieldFlags(long flags) { + if ((flags & ACC_FLATTENABLE) != 0) { + flags &= ~ACC_FLATTENABLE; + if (allowValueTypes) + flags |= FLATTENABLE; + } return flags; } diff -r 8b2ca4fdb101 src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Tue Jun 26 13:02:54 2018 +0530 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Tue Jun 26 16:49:37 2018 +0530 @@ -1179,8 +1179,6 @@ */ void writeField(VarSymbol v) { int flags = adjustFlags(v.flags()); - if ((v.flags() & STATIC) == 0 && types.isValue(v.type)) - flags |= ACC_FLATTENABLE; databuf.appendChar(flags); if (dumpFieldModifiers) { PrintWriter pw = log.getWriter(Log.WriterKind.ERROR); @@ -1931,6 +1929,8 @@ result &= ~ABSTRACT; if ((flags & VALUE) != 0) result |= ACC_VALUE; + if ((flags & FLATTENABLE) != 0) + result |= ACC_FLATTENABLE; return result; } diff -r 8b2ca4fdb101 src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java Tue Jun 26 13:02:54 2018 +0530 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java Tue Jun 26 16:49:37 2018 +0530 @@ -181,6 +181,7 @@ this.keepLineMap = keepLineMap; this.errorTree = F.Erroneous(); endPosTable = newEndPosTable(keepEndPositions); + this.allowFlattenabilityModifiers = fac.options.isSet("allowFlattenabilityModifiers"); } protected AbstractEndPosTable newEndPosTable(boolean keepEndPositions) { @@ -197,6 +198,10 @@ */ boolean allowStringFolding; + /** Switch: should we allow value type field flattenability modifiers? + */ + boolean allowFlattenabilityModifiers; + /** Switch: should we keep docComments? */ boolean keepDocComments; @@ -320,6 +325,8 @@ case PROTECTED: case STATIC: case TRANSIENT: + case FLATTENABLE: + case NOTFLATTENED: case NATIVE: case VOLATILE: case SYNCHRONIZED: @@ -2882,6 +2889,8 @@ case PUBLIC : flag = Flags.PUBLIC; break; case STATIC : flag = Flags.STATIC; break; case TRANSIENT : flag = Flags.TRANSIENT; break; + case FLATTENABLE : checkSourceLevel(Feature.VALUE_TYPES); checkFlattenabilitySpecOk(token.pos); flag = Flags.FLATTENABLE; break; + case NOTFLATTENED: checkSourceLevel(Feature.VALUE_TYPES); checkFlattenabilitySpecOk(token.pos); flag = Flags.NOT_FLATTENED; break; case FINAL : flag = Flags.FINAL; break; case ABSTRACT : flag = Flags.ABSTRACT; break; case NATIVE : flag = Flags.NATIVE; break; @@ -2930,6 +2939,12 @@ storeEnd(mods, S.prevToken().endPos); return mods; } + // where + private void checkFlattenabilitySpecOk(int pos) { + if (!allowFlattenabilityModifiers) { + log.error(pos, Errors.FlattenabilityModifiersDisallowed); + } + } /** Annotation = "@" Qualident [ "(" AnnotationFieldValues ")" ] * diff -r 8b2ca4fdb101 src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java Tue Jun 26 13:02:54 2018 +0530 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java Tue Jun 26 16:49:37 2018 +0530 @@ -162,6 +162,8 @@ THROW("throw"), THROWS("throws"), TRANSIENT("transient"), + FLATTENABLE("__Flattenable"), + NOTFLATTENED("__NotFlattened"), TRY("try"), VALUE("__ByValue"), VDEFAULT("__MakeDefault"), diff -r 8b2ca4fdb101 src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties Tue Jun 26 13:02:54 2018 +0530 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties Tue Jun 26 16:49:37 2018 +0530 @@ -3435,3 +3435,6 @@ # 0: type compiler.warn.potential.null.pollution=\ Potential null pollution from nullable type {0} + +compiler.err.flattenability.modifiers.disallowed=\ + This modifier is allowed only with -XDallowFlattenabilityModifiers diff -r 8b2ca4fdb101 src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java --- a/src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java Tue Jun 26 13:02:54 2018 +0530 +++ b/src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java Tue Jun 26 16:49:37 2018 +0530 @@ -223,6 +223,8 @@ PROTECTED(TokenKind.PROTECTED, XDECL1), // protected PUBLIC(TokenKind.PUBLIC, XDECL1), // public TRANSIENT(TokenKind.TRANSIENT, XDECL1), // transient + FLATTENABLE(TokenKind.FLATTENABLE, XDECL1), // __Flattenable + NOTFLATTENED(TokenKind.NOTFLATTENED, XDECL1), // __NotFlattened VOLATILE(TokenKind.VOLATILE, XDECL1), // volatile // Declarations and type parameters (thus expressions) diff -r 8b2ca4fdb101 test/langtools/tools/javac/diags/examples.not-yet.txt --- a/test/langtools/tools/javac/diags/examples.not-yet.txt Tue Jun 26 13:02:54 2018 +0530 +++ b/test/langtools/tools/javac/diags/examples.not-yet.txt Tue Jun 26 16:49:37 2018 +0530 @@ -200,3 +200,4 @@ compiler.err.make.default.with.nonvalue compiler.err.value.may.not.extend compiler.warn.potential.null.pollution +compiler.err.flattenability.modifiers.disallowed diff -r 8b2ca4fdb101 test/langtools/tools/javac/valhalla/lworld-values/CheckDefaultFlattenable.java --- a/test/langtools/tools/javac/valhalla/lworld-values/CheckDefaultFlattenable.java Tue Jun 26 13:02:54 2018 +0530 +++ b/test/langtools/tools/javac/valhalla/lworld-values/CheckDefaultFlattenable.java Tue Jun 26 16:49:37 2018 +0530 @@ -27,7 +27,7 @@ * @test * @summary Check default setting of ACC_FLATTENABLE * @modules jdk.jdeps/com.sun.tools.classfile - * @compile -XDallowValueBasedClasses CheckDefaultFlattenable.java + * @compile -XDallowValueBasedClasses -XDallowFlattenabilityModifiers CheckDefaultFlattenable.java * @run main CheckDefaultFlattenable */ @@ -44,12 +44,12 @@ } X x1; - static X x2; - X x3; + __NotFlattened X x2; + __Flattenable X x3; Y y1; - static Y y2; - Y y3; + __NotFlattened Y y2; + __Flattenable Y y3; public static void main(String[] args) throws Exception { ClassFile cls = ClassFile.read(CheckDefaultFlattenable.class.getResourceAsStream("CheckDefaultFlattenable.class")); @@ -73,8 +73,8 @@ } if (field.getName(cls.constant_pool).equals("y1")) { checks ++; - if ((field.access_flags.flags & AccessFlags.ACC_FLATTENABLE) == 0) - throw new AssertionError("Expected flattenable flag missing"); + if ((field.access_flags.flags & AccessFlags.ACC_FLATTENABLE) != 0) + throw new AssertionError("Unexpected flattenable flag found"); } if (field.getName(cls.constant_pool).equals("y2")) { checks ++; diff -r 8b2ca4fdb101 test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.java --- a/test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.java Tue Jun 26 13:02:54 2018 +0530 +++ b/test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.java Tue Jun 26 16:49:37 2018 +0530 @@ -2,7 +2,7 @@ * @test /nodynamiccopyright/ * @summary Check for cycles through fields declared flattenable. * - * @compile/fail/ref=CheckFlattenableCycles.out -XDrawDiagnostics CheckFlattenableCycles.java + * @compile/fail/ref=CheckFlattenableCycles.out -XDrawDiagnostics -XDallowFlattenabilityModifiers CheckFlattenableCycles.java */ final __ByValue class CheckFlattenableCycles { @@ -10,11 +10,11 @@ CheckFlattenableCycles cfc; } __ByValue final class InnerValue { - final CheckFlattenableCycles cfc = __MakeDefault CheckFlattenableCycles(); // Error. + final __Flattenable CheckFlattenableCycles cfc = __MakeDefault CheckFlattenableCycles(); // Error. } - final CheckFlattenableCycles cfc = __MakeDefault CheckFlattenableCycles(); // Error. + final __Flattenable CheckFlattenableCycles cfc = __MakeDefault CheckFlattenableCycles(); // Error. final int i = 10; final String s = "blah"; final InnerRef ir = new InnerRef(); // OK. - final InnerValue iv = __MakeDefault InnerValue(); -} + final __Flattenable InnerValue iv = __MakeDefault InnerValue(); +} \ No newline at end of file diff -r 8b2ca4fdb101 test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.out --- a/test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.out Tue Jun 26 13:02:54 2018 +0530 +++ b/test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.out Tue Jun 26 16:49:37 2018 +0530 @@ -1,3 +1,3 @@ -CheckFlattenableCycles.java:15:34: compiler.err.cyclic.value.type.membership: CheckFlattenableCycles -CheckFlattenableCycles.java:13:38: compiler.err.cyclic.value.type.membership: CheckFlattenableCycles.InnerValue -2 errors +CheckFlattenableCycles.java:15:48: compiler.err.cyclic.value.type.membership: CheckFlattenableCycles +CheckFlattenableCycles.java:13:52: compiler.err.cyclic.value.type.membership: CheckFlattenableCycles.InnerValue +2 errors \ No newline at end of file From tobias.hartmann at oracle.com Tue Jun 26 12:16:56 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 26 Jun 2018 14:16:56 +0200 Subject: [lworld] RFR(M): Multiple compiler fixes and refactoring In-Reply-To: References: Message-ID: <390731d8-7996-8fe7-4baa-43390c323e6e@oracle.com> Hi Roland, Thanks for looking at this. On 22.06.2018 10:17, Roland Westrelin wrote: > callGenerator.cpp line 921. Shouldn't we know statically if arg is null > (a null litteral) because we filter nulls early? What do you mean by "filter nulls early"? The check at method entry? In this case we don't have a null check at method entry because we are compiling a lambda form and the arg type is java.lang.Object. We then need to emit a null check when inlining the linkTo call and casting the arg to a value type. > Same question for > parse1.cpp line 617. This is the null check for value type arguments at method entry. Thanks, Tobias From tobias.hartmann at oracle.com Tue Jun 26 12:42:51 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 26 Jun 2018 14:42:51 +0200 Subject: c1 crashes ? In-Reply-To: <281714394.156878.1529918957955.JavaMail.zimbra@u-pem.fr> References: <939492355.2043225.1529792921911.JavaMail.zimbra@u-pem.fr> <1460712418.141251.1529917627415.JavaMail.zimbra@u-pem.fr> <281714394.156878.1529918957955.JavaMail.zimbra@u-pem.fr> Message-ID: <5ed82987-e1e3-5c01-f639-92ddda64d278@oracle.com> Hi Remi, so this is a C1 crash with an application that uses value types and is executed without -XX:+EnableValhalla, right? A crash is expected in this case because C1 does not support value types (and Tiered Compilation is enabled by default). Maybe we should reject value types during verification if EnableValhalla is off. Thanks, Tobias On 25.06.2018 11:29, forax at univ-mlv.fr wrote: > > > ----- Mail original ----- >> De: "Roland Westrelin" >> ?: "Remi Forax" >> Cc: "valhalla-dev" >> Envoy?: Lundi 25 Juin 2018 11:13:06 >> Objet: Re: c1 crashes ? > >>> it seems to work without (apart c1 crash). >> >> Do you have a test case for the c1 crash? > > yes, sure, see below. > >> >> Roland. > > R?mi > > --- > public final __ByValue class IntBox { > private final int value; > > private IntBox() { > this.value = 0; > } > > @Override > public String toString() { > return "" + value; > } > > public int compareTo(IntBox box) { > return Integer.compare(value, box.value); > } > > public IntBox add(IntBox box) { > return IntBox.valueOf(value + box.value); > } > > public static IntBox valueOf(int value) { > IntBox box = __MakeDefault IntBox(); > box = __WithField(box.value, value); > return box; > } > > private static IntBox sum(IntBox n) { > IntBox sum = IntBox.valueOf(0); > for(IntBox i = IntBox.valueOf(0); i.compareTo(n) < 0; i = i.add(IntBox.valueOf(1))) { > sum = sum.add(i); > } > return sum; > } > > public static void main(String[] args) { > for(int i = 0; i < 100_000; i++) { > sum(IntBox.valueOf(i)); > } > } > } > From forax at univ-mlv.fr Tue Jun 26 13:19:30 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 26 Jun 2018 15:19:30 +0200 (CEST) Subject: Empty value type ? Message-ID: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> Is empty value type targeted for LW1 ? Error: LinkageError occurred while loading main class GenBug java.lang.ClassFormatError: class: GenBug - Value Types do not support zero instance size yet R?mi From forax at univ-mlv.fr Tue Jun 26 13:21:17 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 26 Jun 2018 15:21:17 +0200 (CEST) Subject: c1 crashes ? In-Reply-To: <5ed82987-e1e3-5c01-f639-92ddda64d278@oracle.com> References: <939492355.2043225.1529792921911.JavaMail.zimbra@u-pem.fr> <1460712418.141251.1529917627415.JavaMail.zimbra@u-pem.fr> <281714394.156878.1529918957955.JavaMail.zimbra@u-pem.fr> <5ed82987-e1e3-5c01-f639-92ddda64d278@oracle.com> Message-ID: <1406186202.663797.1530019277148.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Tobias Hartmann" > ?: "Remi Forax" , "Roland Westrelin" > Cc: "valhalla-dev" > Envoy?: Mardi 26 Juin 2018 14:42:51 > Objet: Re: c1 crashes ? > Hi Remi, > > so this is a C1 crash with an application that uses value types and is executed > without > -XX:+EnableValhalla, right? A crash is expected in this case because C1 does not > support value types > (and Tiered Compilation is enabled by default). Maybe we should reject value > types during > verification if EnableValhalla is off. yes and explain that value type can be enable using -XX:+EnableValhalla ? > > Thanks, > Tobias R?mi > > > On 25.06.2018 11:29, forax at univ-mlv.fr wrote: >> >> >> ----- Mail original ----- >>> De: "Roland Westrelin" >>> ?: "Remi Forax" >>> Cc: "valhalla-dev" >>> Envoy?: Lundi 25 Juin 2018 11:13:06 >>> Objet: Re: c1 crashes ? >> >>>> it seems to work without (apart c1 crash). >>> >>> Do you have a test case for the c1 crash? >> >> yes, sure, see below. >> >>> >>> Roland. >> >> R?mi >> >> --- >> public final __ByValue class IntBox { >> private final int value; >> >> private IntBox() { >> this.value = 0; >> } >> >> @Override >> public String toString() { >> return "" + value; >> } >> >> public int compareTo(IntBox box) { >> return Integer.compare(value, box.value); >> } >> >> public IntBox add(IntBox box) { >> return IntBox.valueOf(value + box.value); >> } >> >> public static IntBox valueOf(int value) { >> IntBox box = __MakeDefault IntBox(); >> box = __WithField(box.value, value); >> return box; >> } >> >> private static IntBox sum(IntBox n) { >> IntBox sum = IntBox.valueOf(0); >> for(IntBox i = IntBox.valueOf(0); i.compareTo(n) < 0; i = >> i.add(IntBox.valueOf(1))) { >> sum = sum.add(i); >> } >> return sum; >> } >> >> public static void main(String[] args) { >> for(int i = 0; i < 100_000; i++) { >> sum(IntBox.valueOf(i)); >> } >> } >> } From tobias.hartmann at oracle.com Tue Jun 26 13:22:25 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 26 Jun 2018 15:22:25 +0200 Subject: c1 crashes ? In-Reply-To: <1406186202.663797.1530019277148.JavaMail.zimbra@u-pem.fr> References: <939492355.2043225.1529792921911.JavaMail.zimbra@u-pem.fr> <1460712418.141251.1529917627415.JavaMail.zimbra@u-pem.fr> <281714394.156878.1529918957955.JavaMail.zimbra@u-pem.fr> <5ed82987-e1e3-5c01-f639-92ddda64d278@oracle.com> <1406186202.663797.1530019277148.JavaMail.zimbra@u-pem.fr> Message-ID: On 26.06.2018 15:21, forax at univ-mlv.fr wrote: > yes and explain that value type can be enable using -XX:+EnableValhalla ? Yes, that would make sense to me. Thanks, Tobias From tobias.hartmann at oracle.com Tue Jun 26 13:23:46 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 26 Jun 2018 15:23:46 +0200 Subject: Empty value type ? In-Reply-To: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> References: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, no, empty value types are not planned to be supported for LW1. Best regards, Tobias On 26.06.2018 15:19, Remi Forax wrote: > Is empty value type targeted for LW1 ? > > Error: LinkageError occurred while loading main class GenBug > java.lang.ClassFormatError: class: GenBug - Value Types do not support zero instance size yet > > R?mi > From forax at univ-mlv.fr Tue Jun 26 13:25:44 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 26 Jun 2018 15:25:44 +0200 (CEST) Subject: Generics Value Type ? Message-ID: <546834616.667958.1530019544075.JavaMail.zimbra@u-pem.fr> Hi Srikanth, __WithField seems to have trouble if the value type is generics. R?mi public final __ByValue class GenBug { private final boolean value; private GenBug() { value = false; throw new AssertionError(); } public static GenBug create() { GenBug bug = __MakeDefault GenBug(); bug = __WithField(bug.value, true); return bug; } } From forax at univ-mlv.fr Tue Jun 26 13:28:00 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 26 Jun 2018 15:28:00 +0200 (CEST) Subject: Empty value type ? In-Reply-To: References: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> Message-ID: <783083966.669860.1530019680824.JavaMail.zimbra@u-pem.fr> ok, in that case, i think zero field value types should be rejected by the compiler. R?mi ----- Mail original ----- > De: "Tobias Hartmann" > ?: "Remi Forax" , "valhalla-dev" > Envoy?: Mardi 26 Juin 2018 15:23:46 > Objet: Re: Empty value type ? > Hi Remi, > > no, empty value types are not planned to be supported for LW1. > > Best regards, > Tobias > > On 26.06.2018 15:19, Remi Forax wrote: >> Is empty value type targeted for LW1 ? >> >> Error: LinkageError occurred while loading main class GenBug >> java.lang.ClassFormatError: class: GenBug - Value Types do not support zero >> instance size yet >> >> R?mi From srikanth.adayapalam at oracle.com Tue Jun 26 14:29:35 2018 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 26 Jun 2018 19:59:35 +0530 Subject: Generics Value Type ? In-Reply-To: <546834616.667958.1530019544075.JavaMail.zimbra@u-pem.fr> References: <546834616.667958.1530019544075.JavaMail.zimbra@u-pem.fr> Message-ID: <8ab9b1a6-049a-7caf-c4b5-fc4a7637ed9d@oracle.com> Hi Remi, Thanks for the test case. I'll follow up. Srikanth On Tuesday 26 June 2018 06:55 PM, Remi Forax wrote: > public final __ByValue class GenBug { > private final boolean value; > > private GenBug() { > value = false; > throw new AssertionError(); > } > > public static GenBug create() { > GenBug bug = __MakeDefault GenBug(); > bug = __WithField(bug.value, true); > return bug; > } > } From kirk.pepperdine at gmail.com Tue Jun 26 15:36:09 2018 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 26 Jun 2018 17:36:09 +0200 Subject: Empty value type ? In-Reply-To: <783083966.669860.1530019680824.JavaMail.zimbra@u-pem.fr> References: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> <783083966.669860.1530019680824.JavaMail.zimbra@u-pem.fr> Message-ID: <548A46F3-5DF7-4674-A374-5E9DDF0C4C09@gmail.com> How can a value type be empty.. what is an empty integer? An empty string? Just curious. Kind regards, Kirk > On Jun 26, 2018, at 3:28 PM, forax at univ-mlv.fr wrote: > > ok, > in that case, i think zero field value types should be rejected by the compiler. > > R?mi > > ----- Mail original ----- >> De: "Tobias Hartmann" >> ?: "Remi Forax" , "valhalla-dev" >> Envoy?: Mardi 26 Juin 2018 15:23:46 >> Objet: Re: Empty value type ? > >> Hi Remi, >> >> no, empty value types are not planned to be supported for LW1. >> >> Best regards, >> Tobias >> >> On 26.06.2018 15:19, Remi Forax wrote: >>> Is empty value type targeted for LW1 ? >>> >>> Error: LinkageError occurred while loading main class GenBug >>> java.lang.ClassFormatError: class: GenBug - Value Types do not support zero >>> instance size yet >>> >>> R?mi From karen.kinnear at oracle.com Tue Jun 26 15:47:12 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 26 Jun 2018 11:47:12 -0400 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <47608021-f50c-dcfa-5d22-28f0f3e32219@oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> <53abe74c-2b1c-79bf-eeb8-c4774f17fd4a@oracle.com> <70fbad77-2b90-9e0b-4acc-6e6af25835d9@oracle.com> <47608021-f50c-dcfa-5d22-28f0f3e32219@oracle.com> Message-ID: <872616D9-4CA6-4D9B-9B9B-860EEF947A79@oracle.com> Srikanth, Tobias, Yes please to push this patch to move these modifiers under the experimental flag. this is a much better approach. LW1 is a really tight deadline right now and we don?t want to cause extra work. My apologies for missing the implications. thank you both, Karen > On Jun 26, 2018, at 7:23 AM, Srikanth wrote: > > > The attached patch would cause the flattenability modifiers to be accepted with their erstwhile syntax and semantics when javac is invoked with -XDallowFlattenabilityModifiers > > I'll wait to hear from Karen and push/discard accordingly. > > (I am likely away Thursday/Friday, I will be available on Wednesday. Posting a patch here, so if it is required in my absence it can be availed. It passes all langtools tests) > > Thanks! > Srikanth > > On Tuesday 26 June 2018 03:38 PM, Srikanth wrote: >> >> >> On Tuesday 26 June 2018 03:32 PM, Tobias Hartmann wrote: >>> Hi Srikanth, >>> >>> On 26.06.2018 11:37, Srikanth wrote: >>>> I did have an express go from Karen to "nuke" these source level modifiers before proceeding. But in >>>> light of what you say, I'll take a look and see what is involved in pushing these under an option >>>> instead. >>> Thanks for looking into it but we should probably wait for Karen to comment on that. I guess I >>> missed the discussion/decision of fully removing these modifiers (I thought we just don't want to >>> support them for LW1). >> >> Sounds good to me. I'll keep a patch ready in any case and after hearing from Karen decide to push or discard. >> >> I believe the consensus in the VM is to move away fromACC_FLATTENABLE on fields to using the ValueTypes attribute. >> >> Your concern below about the code rot is valid. >> >> Srikanth >>> >>>> Even with that many of the tests would need "massaging" but I guess it won't shut you out from >>>> retaining the support for non-flattened value type fields. >>> Yes, I'm fine with modifying the tests, I'm just concerned that without testing the implementation >>> of non-flattenable fields in the JVM, the code will start to rot very soon. >>> >>> Thanks, >>> Tobias >> > > From forax at univ-mlv.fr Tue Jun 26 15:49:31 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 26 Jun 2018 17:49:31 +0200 (CEST) Subject: Empty value type ? In-Reply-To: <548A46F3-5DF7-4674-A374-5E9DDF0C4C09@gmail.com> References: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> <783083966.669860.1530019680824.JavaMail.zimbra@u-pem.fr> <548A46F3-5DF7-4674-A374-5E9DDF0C4C09@gmail.com> Message-ID: <2105873426.741454.1530028171824.JavaMail.zimbra@u-pem.fr> Hi Kirk, there are lot of examples in the history, on top of my head, a type represent the absence of value like unit, void or bottom, a type that represent the result of a throw, a type that allows HashSet to be defined as HashMap, a transformative type like a marker type that separate arguments, like in foo("a", "b", "c", marker, "d", "e") with the semantics that the values that follow the marker will be boxed/gathered into something, etc. R?mi ----- Mail original ----- > De: "Kirk Pepperdine" > ?: "Remi Forax" > Cc: "Tobias Hartmann" , "valhalla-dev" > Envoy?: Mardi 26 Juin 2018 17:36:09 > Objet: Re: Empty value type ? > How can a value type be empty.. what is an empty integer? An empty string? Just > curious. > > Kind regards, > Kirk > > > >> On Jun 26, 2018, at 3:28 PM, forax at univ-mlv.fr wrote: >> >> ok, >> in that case, i think zero field value types should be rejected by the compiler. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Tobias Hartmann" >>> ?: "Remi Forax" , "valhalla-dev" >>> >>> Envoy?: Mardi 26 Juin 2018 15:23:46 >>> Objet: Re: Empty value type ? >> >>> Hi Remi, >>> >>> no, empty value types are not planned to be supported for LW1. >>> >>> Best regards, >>> Tobias >>> >>> On 26.06.2018 15:19, Remi Forax wrote: >>>> Is empty value type targeted for LW1 ? >>>> >>>> Error: LinkageError occurred while loading main class GenBug >>>> java.lang.ClassFormatError: class: GenBug - Value Types do not support zero >>>> instance size yet >>>> > >>> R?mi From john.r.rose at oracle.com Tue Jun 26 17:02:20 2018 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Jun 2018 10:02:20 -0700 Subject: Empty value type ? In-Reply-To: <2105873426.741454.1530028171824.JavaMail.zimbra@u-pem.fr> References: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> <783083966.669860.1530019680824.JavaMail.zimbra@u-pem.fr> <548A46F3-5DF7-4674-A374-5E9DDF0C4C09@gmail.com> <2105873426.741454.1530028171824.JavaMail.zimbra@u-pem.fr> Message-ID: https://en.m.wikipedia.org/wiki/Unit_type From brian.goetz at oracle.com Tue Jun 26 19:43:24 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 26 Jun 2018 15:43:24 -0400 Subject: Empty value type ? In-Reply-To: <548A46F3-5DF7-4674-A374-5E9DDF0C4C09@gmail.com> References: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> <783083966.669860.1530019680824.JavaMail.zimbra@u-pem.fr> <548A46F3-5DF7-4674-A374-5E9DDF0C4C09@gmail.com> Message-ID: Zero-length values can be quite useful, just not directly. Look at the current implementations of Set that delegate to HashMap; all that wasted space. When we have specialized generics, they can specialize to HashMap, and that space gets squeezed away to zero. > On Jun 26, 2018, at 11:36 AM, Kirk Pepperdine wrote: > > How can a value type be empty.. what is an empty integer? An empty string? Just curious. > > Kind regards, > Kirk > > > >> On Jun 26, 2018, at 3:28 PM, forax at univ-mlv.fr wrote: >> >> ok, >> in that case, i think zero field value types should be rejected by the compiler. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Tobias Hartmann" >>> ?: "Remi Forax" , "valhalla-dev" >>> Envoy?: Mardi 26 Juin 2018 15:23:46 >>> Objet: Re: Empty value type ? >> >>> Hi Remi, >>> >>> no, empty value types are not planned to be supported for LW1. >>> >>> Best regards, >>> Tobias >>> >>> On 26.06.2018 15:19, Remi Forax wrote: >>>> Is empty value type targeted for LW1 ? >>>> >>>> Error: LinkageError occurred while loading main class GenBug >>>> java.lang.ClassFormatError: class: GenBug - Value Types do not support zero >>>> instance size yet >>>> >>>> R?mi > From kirk.pepperdine at gmail.com Tue Jun 26 21:37:00 2018 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 26 Jun 2018 23:37:00 +0200 Subject: Empty value type ? In-Reply-To: References: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> <783083966.669860.1530019680824.JavaMail.zimbra@u-pem.fr> <548A46F3-5DF7-4674-A374-5E9DDF0C4C09@gmail.com> Message-ID: <22689FC5-209A-40ED-BD39-6DC7420BBF6C@gmail.com> Feels like a value type version of null. Kind regards, Kirk > On Jun 26, 2018, at 9:43 PM, Brian Goetz wrote: > > Zero-length values can be quite useful, just not directly. Look at the current implementations of Set that delegate to HashMap; all that wasted space. When we have specialized generics, they can specialize to HashMap, and that space gets squeezed away to zero. > >> On Jun 26, 2018, at 11:36 AM, Kirk Pepperdine wrote: >> >> How can a value type be empty.. what is an empty integer? An empty string? Just curious. >> >> Kind regards, >> Kirk >> >> >> >>> On Jun 26, 2018, at 3:28 PM, forax at univ-mlv.fr wrote: >>> >>> ok, >>> in that case, i think zero field value types should be rejected by the compiler. >>> >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Tobias Hartmann" >>>> ?: "Remi Forax" , "valhalla-dev" >>>> Envoy?: Mardi 26 Juin 2018 15:23:46 >>>> Objet: Re: Empty value type ? >>> >>>> Hi Remi, >>>> >>>> no, empty value types are not planned to be supported for LW1. >>>> >>>> Best regards, >>>> Tobias >>>> >>>> On 26.06.2018 15:19, Remi Forax wrote: >>>>> Is empty value type targeted for LW1 ? >>>>> >>>>> Error: LinkageError occurred while loading main class GenBug >>>>> java.lang.ClassFormatError: class: GenBug - Value Types do not support zero >>>>> instance size yet >>>>> >>>>> R?mi >> > From forax at univ-mlv.fr Tue Jun 26 22:46:31 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 27 Jun 2018 00:46:31 +0200 (CEST) Subject: Integer vs IntBox benchmark Message-ID: <2042157901.796776.1530053191748.JavaMail.zimbra@u-pem.fr> I've just written a small perf benchmark [1] that compare int, Integer and IntBox (a value type that stores an int) and results are very good. On my laptop: Benchmark Mode Cnt Score Error Units IntBoxBenchMark.sum_IntBox avgt 15 0.029 ? 0.001 ms/op IntBoxBenchMark.sum_Integer avgt 15 0.523 ? 0.011 ms/op IntBoxBenchMark.sum_int avgt 15 0.029 ? 0.001 ms/op On travisCI (amazon ec2 i think): Benchmark Mode Cnt Score Error Units IntBoxBenchMark.sum_IntBox avgt 15 0.035 ? 0.001 ms/op IntBoxBenchMark.sum_Integer avgt 15 0.724 ? 0.039 ms/op IntBoxBenchMark.sum_int avgt 15 0.035 ? 0.001 ms/op R?mi [1] https://github.com/forax/valuetype-lworld/blob/master/src/test/java/fr.umlv.valuetype/fr/umlv/valuetype/perf/IntBoxBenchMark.java From john.r.rose at oracle.com Wed Jun 27 02:11:37 2018 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Jun 2018 19:11:37 -0700 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <872616D9-4CA6-4D9B-9B9B-860EEF947A79@oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> <53abe74c-2b1c-79bf-eeb8-c4774f17fd4a@oracle.com> <70fbad77-2b90-9e0b-4acc-6e6af25835d9@oracle.com> <47608021-f50c-dcfa-5d22-28f0f3e32219@oracle.com> <872616D9-4CA6-4D9B-9B9B-860EEF947A79@oracle.com> Message-ID: <3622C412-F6C0-4C87-A42D-480CC0924C22@oracle.com> FTR, I'm fine with this too for LW1. I think the highest priority for LW1 is to guide some users into a smooth and simple user experience, and see whether it really works. For this to work gaps in functionality are tolerable (statics, constructors?). Excess (half-baked) functionality should be factored under a flag so users won't "bump into it" without knowing they are moving out of the central experience we want to test. That includes integration with generics and nullability control, also those extra modifiers. If we can get constructors working we can put __WithField and __DefaultValue under experimental flags also. ? John On Jun 26, 2018, at 8:47 AM, Karen Kinnear wrote: > > Srikanth, Tobias, > > Yes please to push this patch to move these modifiers under the experimental flag. this is a much better approach. > > LW1 is a really tight deadline right now and we don?t want to cause extra work. > My apologies for missing the implications. > > thank you both, > Karen > >> On Jun 26, 2018, at 7:23 AM, Srikanth wrote: >> >> >> The attached patch would cause the flattenability modifiers to be accepted with their erstwhile syntax and semantics when javac is invoked with -XDallowFlattenabilityModifiers >> >> I'll wait to hear from Karen and push/discard accordingly. >> >> (I am likely away Thursday/Friday, I will be available on Wednesday. Posting a patch here, so if it is required in my absence it can be availed. It passes all langtools tests) >> >> Thanks! >> Srikanth >> >> On Tuesday 26 June 2018 03:38 PM, Srikanth wrote: >>> >>> >>> On Tuesday 26 June 2018 03:32 PM, Tobias Hartmann wrote: >>>> Hi Srikanth, >>>> >>>> On 26.06.2018 11:37, Srikanth wrote: >>>>> I did have an express go from Karen to "nuke" these source level modifiers before proceeding. But in >>>>> light of what you say, I'll take a look and see what is involved in pushing these under an option >>>>> instead. >>>> Thanks for looking into it but we should probably wait for Karen to comment on that. I guess I >>>> missed the discussion/decision of fully removing these modifiers (I thought we just don't want to >>>> support them for LW1). >>> >>> Sounds good to me. I'll keep a patch ready in any case and after hearing from Karen decide to push or discard. >>> >>> I believe the consensus in the VM is to move away fromACC_FLATTENABLE on fields to using the ValueTypes attribute. >>> >>> Your concern below about the code rot is valid. >>> >>> Srikanth >>>> >>>>> Even with that many of the tests would need "massaging" but I guess it won't shut you out from >>>>> retaining the support for non-flattened value type fields. >>>> Yes, I'm fine with modifying the tests, I'm just concerned that without testing the implementation >>>> of non-flattenable fields in the JVM, the code will start to rot very soon. >>>> >>>> Thanks, >>>> Tobias >>> >> >> > From srikanth.adayapalam at oracle.com Wed Jun 27 03:40:37 2018 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Wed, 27 Jun 2018 09:10:37 +0530 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <872616D9-4CA6-4D9B-9B9B-860EEF947A79@oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> <53abe74c-2b1c-79bf-eeb8-c4774f17fd4a@oracle.com> <70fbad77-2b90-9e0b-4acc-6e6af25835d9@oracle.com> <47608021-f50c-dcfa-5d22-28f0f3e32219@oracle.com> <872616D9-4CA6-4D9B-9B9B-860EEF947A79@oracle.com> Message-ID: <9b10e572-048c-3c3e-2a79-70c6998187d8@oracle.com> I am working on it, will push soon. Srikanth On Tuesday 26 June 2018 09:17 PM, Karen Kinnear wrote: > Srikanth, Tobias, > > Yes please to push this patch to move these modifiers under the experimental flag. this is a much better approach. > > LW1 is a really tight deadline right now and we don?t want to cause extra work. > My apologies for missing the implications. > > thank you both, > Karen > >> On Jun 26, 2018, at 7:23 AM, Srikanth wrote: >> >> >> The attached patch would cause the flattenability modifiers to be accepted with their erstwhile syntax and semantics when javac is invoked with -XDallowFlattenabilityModifiers >> >> I'll wait to hear from Karen and push/discard accordingly. >> >> (I am likely away Thursday/Friday, I will be available on Wednesday. Posting a patch here, so if it is required in my absence it can be availed. It passes all langtools tests) >> >> Thanks! >> Srikanth >> >> On Tuesday 26 June 2018 03:38 PM, Srikanth wrote: >>> >>> On Tuesday 26 June 2018 03:32 PM, Tobias Hartmann wrote: >>>> Hi Srikanth, >>>> >>>> On 26.06.2018 11:37, Srikanth wrote: >>>>> I did have an express go from Karen to "nuke" these source level modifiers before proceeding. But in >>>>> light of what you say, I'll take a look and see what is involved in pushing these under an option >>>>> instead. >>>> Thanks for looking into it but we should probably wait for Karen to comment on that. I guess I >>>> missed the discussion/decision of fully removing these modifiers (I thought we just don't want to >>>> support them for LW1). >>> Sounds good to me. I'll keep a patch ready in any case and after hearing from Karen decide to push or discard. >>> >>> I believe the consensus in the VM is to move away fromACC_FLATTENABLE on fields to using the ValueTypes attribute. >>> >>> Your concern below about the code rot is valid. >>> >>> Srikanth >>>>> Even with that many of the tests would need "massaging" but I guess it won't shut you out from >>>>> retaining the support for non-flattened value type fields. >>>> Yes, I'm fine with modifying the tests, I'm just concerned that without testing the implementation >>>> of non-flattenable fields in the JVM, the code will start to rot very soon. >>>> >>>> Thanks, >>>> Tobias >> From srikanth.adayapalam at oracle.com Wed Jun 27 05:11:43 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Wed, 27 Jun 2018 05:11:43 +0000 Subject: hg: valhalla/valhalla: [lworld] Restore support for the __Flattenable and __NotFlattened field modifiers under the internal experimental mode -XDallowFlattenabilityModifiers Message-ID: <201806270511.w5R5BiRb021145@aojmv0008.oracle.com> Changeset: 578a9489b058 Author: sadayapalam Date: 2018-06-27 10:41 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/578a9489b058 [lworld] Restore support for the __Flattenable and __NotFlattened field modifiers under the internal experimental mode -XDallowFlattenabilityModifiers ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! test/langtools/tools/javac/diags/examples.not-yet.txt ! test/langtools/tools/javac/valhalla/lworld-values/CheckCyclicMembership.java ! test/langtools/tools/javac/valhalla/lworld-values/CheckCyclicMembership.out ! test/langtools/tools/javac/valhalla/lworld-values/CheckDefaultFlattenable.java ! test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.java ! test/langtools/tools/javac/valhalla/lworld-values/CheckFlattenableCycles.out + test/langtools/tools/javac/valhalla/lworld-values/FlattenabilityModifiersDisallowed.java + test/langtools/tools/javac/valhalla/lworld-values/FlattenabilityModifiersDisallowed.out From srikanth.adayapalam at oracle.com Wed Jun 27 05:59:23 2018 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Wed, 27 Jun 2018 05:59:23 +0000 Subject: hg: valhalla/valhalla: [lworld] Adjust failing runtime tests by adding suitable options Message-ID: <201806270559.w5R5xOn9003962@aojmv0008.oracle.com> Changeset: b01641abdcbb Author: sadayapalam Date: 2018-06-27 11:29 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b01641abdcbb [lworld] Adjust failing runtime tests by adding suitable options ! test/hotspot/jtreg/runtime/valhalla/valuetypes/FlattenableSemanticTest.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/QuickeningTest.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/TestInheritedValueTypeFields.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/UninitializedValueFieldsTest.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/VDefaultTest.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/ValueOops.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/ValueTypeArray.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/ValueTypeCreation.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/ValueTypesTest.java From forax at univ-mlv.fr Wed Jun 27 06:47:19 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 27 Jun 2018 08:47:19 +0200 (CEST) Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <3622C412-F6C0-4C87-A42D-480CC0924C22@oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <53abe74c-2b1c-79bf-eeb8-c4774f17fd4a@oracle.com> <70fbad77-2b90-9e0b-4acc-6e6af25835d9@oracle.com> <47608021-f50c-dcfa-5d22-28f0f3e32219@oracle.com> <872616D9-4CA6-4D9B-9B9B-860EEF947A79@oracle.com> <3622C412-F6C0-4C87-A42D-480CC0924C22@oracle.com> Message-ID: <1389085945.828453.1530082039949.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "John Rose" > ?: "Karen Kinnear" > Cc: "valhalla-dev" > Envoy?: Mercredi 27 Juin 2018 04:11:37 > Objet: Re: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. > FTR, I'm fine with this too for LW1. > > I think the highest priority for LW1 is to guide some users into > a smooth and simple user experience, and see whether it > really works. > > For this to work gaps in functionality are tolerable (statics, > constructors?). > > Excess (half-baked) functionality should be factored > under a flag so users won't "bump into it" without knowing > they are moving out of the central experience we want > to test. That includes integration with generics and > nullability control, also those extra modifiers. Playing with the prototype, i've found that disabling value types as type argument make a lot of codes to not compile, hard to do something fun when a simple ArrayList, Comparable, Stream or Optional doesn't work. I wonder if it's not better to let people to use generics even if the behavior of LW10 will be different ? > > If we can get constructors working we can put __WithField > and __DefaultValue under experimental flags also. > > ? John R?mi > > On Jun 26, 2018, at 8:47 AM, Karen Kinnear wrote: >> >> Srikanth, Tobias, >> >> Yes please to push this patch to move these modifiers under the experimental >> flag. this is a much better approach. >> >> LW1 is a really tight deadline right now and we don?t want to cause extra work. >> My apologies for missing the implications. >> >> thank you both, >> Karen >> >>> On Jun 26, 2018, at 7:23 AM, Srikanth wrote: >>> >>> >>> The attached patch would cause the flattenability modifiers to be accepted with >>> their erstwhile syntax and semantics when javac is invoked with >>> -XDallowFlattenabilityModifiers >>> >>> I'll wait to hear from Karen and push/discard accordingly. >>> >>> (I am likely away Thursday/Friday, I will be available on Wednesday. Posting a >>> patch here, so if it is required in my absence it can be availed. It passes all >>> langtools tests) >>> >>> Thanks! >>> Srikanth >>> >>> On Tuesday 26 June 2018 03:38 PM, Srikanth wrote: >>>> >>>> >>>> On Tuesday 26 June 2018 03:32 PM, Tobias Hartmann wrote: >>>>> Hi Srikanth, >>>>> >>>>> On 26.06.2018 11:37, Srikanth wrote: >>>>>> I did have an express go from Karen to "nuke" these source level modifiers >>>>>> before proceeding. But in >>>>>> light of what you say, I'll take a look and see what is involved in pushing >>>>>> these under an option >>>>>> instead. >>>>> Thanks for looking into it but we should probably wait for Karen to comment on >>>>> that. I guess I >>>>> missed the discussion/decision of fully removing these modifiers (I thought we >>>>> just don't want to >>>>> support them for LW1). >>>> >>>> Sounds good to me. I'll keep a patch ready in any case and after hearing from >>>> Karen decide to push or discard. >>>> >>>> I believe the consensus in the VM is to move away fromACC_FLATTENABLE on fields >>>> to using the ValueTypes attribute. >>>> >>>> Your concern below about the code rot is valid. >>>> >>>> Srikanth >>>>> >>>>>> Even with that many of the tests would need "massaging" but I guess it won't >>>>>> shut you out from >>>>>> retaining the support for non-flattened value type fields. >>>>> Yes, I'm fine with modifying the tests, I'm just concerned that without testing >>>>> the implementation >>>>> of non-flattenable fields in the JVM, the code will start to rot very soon. >>>>> >>>>> Thanks, >>>>> Tobias >>>> >>> >>> From tobias.hartmann at oracle.com Wed Jun 27 07:47:04 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 27 Jun 2018 07:47:04 +0000 Subject: hg: valhalla/valhalla: [lworld] Fixed compiler tests by adding -XDallowFlattenabilityModifiers Message-ID: <201806270747.w5R7l56T003522@aojmv0008.oracle.com> Changeset: 8b22e5024f2b Author: thartmann Date: 2018-06-27 09:46 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8b22e5024f2b [lworld] Fixed compiler tests by adding -XDallowFlattenabilityModifiers ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestBasicFunctionality.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestCallingConvention.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestLWorld.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestMethodHandles.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestOnStackReplacement.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestUnloadedValueTypeArray.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestUnresolvedValueClass.java From tobias.hartmann at oracle.com Wed Jun 27 07:53:20 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 27 Jun 2018 09:53:20 +0200 Subject: Integer vs IntBox benchmark In-Reply-To: <2042157901.796776.1530053191748.JavaMail.zimbra@u-pem.fr> References: <2042157901.796776.1530053191748.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, thanks for reporting these results! You've probably seen that Serguey pushed a whole bunch of JMH tests recently: http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-June/004380.html Just in case you are interested in running / looking at some of these. Thanks, Tobias On 27.06.2018 00:46, Remi Forax wrote: > I've just written a small perf benchmark [1] that compare int, Integer and IntBox (a value type that stores an int) and results are very good. > > On my laptop: > Benchmark Mode Cnt Score Error Units > IntBoxBenchMark.sum_IntBox avgt 15 0.029 ? 0.001 ms/op > IntBoxBenchMark.sum_Integer avgt 15 0.523 ? 0.011 ms/op > IntBoxBenchMark.sum_int avgt 15 0.029 ? 0.001 ms/op > > > On travisCI (amazon ec2 i think): > Benchmark Mode Cnt Score Error Units > IntBoxBenchMark.sum_IntBox avgt 15 0.035 ? 0.001 ms/op > IntBoxBenchMark.sum_Integer avgt 15 0.724 ? 0.039 ms/op > IntBoxBenchMark.sum_int avgt 15 0.035 ? 0.001 ms/op > > R?mi > > [1] https://github.com/forax/valuetype-lworld/blob/master/src/test/java/fr.umlv.valuetype/fr/umlv/valuetype/perf/IntBoxBenchMark.java > From rwestrel at redhat.com Wed Jun 27 10:32:16 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 27 Jun 2018 12:32:16 +0200 Subject: [lworld] RFR(M): Multiple compiler fixes and refactoring In-Reply-To: <390731d8-7996-8fe7-4baa-43390c323e6e@oracle.com> References: <390731d8-7996-8fe7-4baa-43390c323e6e@oracle.com> Message-ID: >> callGenerator.cpp line 921. Shouldn't we know statically if arg is null >> (a null litteral) because we filter nulls early? > > What do you mean by "filter nulls early"? The check at method entry? In this case we don't have a > null check at method entry because we are compiling a lambda form and the arg type is > java.lang.Object. We then need to emit a null check when inlining the linkTo call and casting the > arg to a value type. Right. >> Same question for >> parse1.cpp line 617. > > This is the null check for value type arguments at method entry. That one can (and should) be restricted to the root of the compilation (depth() == 1). Except for that, looks good. Roland. From tobias.hartmann at oracle.com Wed Jun 27 10:57:32 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 27 Jun 2018 12:57:32 +0200 Subject: [lworld] RFR(M): Multiple compiler fixes and refactoring In-Reply-To: References: <390731d8-7996-8fe7-4baa-43390c323e6e@oracle.com> Message-ID: Hi Roland, On 27.06.2018 12:32, Roland Westrelin wrote: > That one can (and should) be restricted to the root of the compilation > (depth() == 1). Yes, I'll do that with a follow up change that I already have in my queue. > Except for that, looks good. Thank you! Best regards, Tobias From tobias.hartmann at oracle.com Wed Jun 27 11:01:51 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 27 Jun 2018 11:01:51 +0000 Subject: hg: valhalla/valhalla: [lworld] Multiple compiler fixes and refactoring Message-ID: <201806271101.w5RB1qmW003127@aojmv0008.oracle.com> Changeset: ad6949f382f4 Author: thartmann Date: 2018-06-27 13:01 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ad6949f382f4 [lworld] Multiple compiler fixes and refactoring Reviewed-by: roland ! src/hotspot/share/ci/ciTypeFlow.cpp ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/castnode.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/parse3.cpp ! src/hotspot/share/opto/valuetypenode.cpp ! src/hotspot/share/opto/valuetypenode.hpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/MyValue1.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestLWorld.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestMethodHandles.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java From rwestrel at redhat.com Wed Jun 27 13:01:57 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 27 Jun 2018 15:01:57 +0200 Subject: RFR: 8205340: [lworld] Re-enable _hashCode, _identityHashCode and _newArray intrinsics Message-ID: http://cr.openjdk.java.net/~roland/8205340/webrev.00/ I expect this change to fix all remaining intrinsics. I found that flattened array allocation through reflection would never go through the fast path. Once that was fixed then I hit some failure in arraycopy/copyOf tests that this patch fixes. hashCode() tests are currently commented out because they trigger the bug I reported on this list earlier: http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-June/004383.html The tests did pass when I developped this patch on an older revision of the repo. Roland. From karen.kinnear at oracle.com Wed Jun 27 13:33:19 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 27 Jun 2018 09:33:19 -0400 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <9b10e572-048c-3c3e-2a79-70c6998187d8@oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> <53abe74c-2b1c-79bf-eeb8-c4774f17fd4a@oracle.com> <70fbad77-2b90-9e0b-4acc-6e6af25835d9@oracle.com> <47608021-f50c-dcfa-5d22-28f0f3e32219@oracle.com> <872616D9-4CA6-4D9B-9B9B-860EEF947A79@oracle.com> <9b10e572-048c-3c3e-2a79-70c6998187d8@oracle.com> Message-ID: <26841429-014F-44FA-B13E-68EA56F71E18@oracle.com> To be really really clear what we are asking for for LW1: 1. Modifiers: __Flattenable, __NotFlattened would be accepted only under -XDAllowFlattenabilityModifiers flag Many of the existing tests will need to be modified to add this flag. 2. ACC_FLATTENABLE For LW1, by default all instance fields containing value types would be marked as ACC_FLATTENABLE in the classfile. Static fields would not. This continues to work even without the -XDAllowFlattenabilityModifiers flag. Please make sure this is true - the patch you sent e.g. ClassWriter looks like that might now be true. We won?t make LW1 if we change the classfile at this point. So for the LW1 timeframe, the consensus is NOT to move away from ACC_FLATTENABLE. Apologies for the confusion, Karen > On Jun 26, 2018, at 11:40 PM, Srikanth wrote: > > I am working on it, will push soon. > > Srikanth > > On Tuesday 26 June 2018 09:17 PM, Karen Kinnear wrote: >> Srikanth, Tobias, >> >> Yes please to push this patch to move these modifiers under the experimental flag. this is a much better approach. >> >> LW1 is a really tight deadline right now and we don?t want to cause extra work. >> My apologies for missing the implications. >> >> thank you both, >> Karen >> >>> On Jun 26, 2018, at 7:23 AM, Srikanth wrote: >>> >>> >>> The attached patch would cause the flattenability modifiers to be accepted with their erstwhile syntax and semantics when javac is invoked with -XDallowFlattenabilityModifiers >>> >>> I'll wait to hear from Karen and push/discard accordingly. >>> >>> (I am likely away Thursday/Friday, I will be available on Wednesday. Posting a patch here, so if it is required in my absence it can be availed. It passes all langtools tests) >>> >>> Thanks! >>> Srikanth >>> >>> On Tuesday 26 June 2018 03:38 PM, Srikanth wrote: >>>> >>>> On Tuesday 26 June 2018 03:32 PM, Tobias Hartmann wrote: >>>>> Hi Srikanth, >>>>> >>>>> On 26.06.2018 11:37, Srikanth wrote: >>>>>> I did have an express go from Karen to "nuke" these source level modifiers before proceeding. But in >>>>>> light of what you say, I'll take a look and see what is involved in pushing these under an option >>>>>> instead. >>>>> Thanks for looking into it but we should probably wait for Karen to comment on that. I guess I >>>>> missed the discussion/decision of fully removing these modifiers (I thought we just don't want to >>>>> support them for LW1). >>>> Sounds good to me. I'll keep a patch ready in any case and after hearing from Karen decide to push or discard. >>>> >>>> I believe the consensus in the VM is to move away fromACC_FLATTENABLE on fields to using the ValueTypes attribute. >>>> >>>> Your concern below about the code rot is valid. >>>> >>>> Srikanth >>>>>> Even with that many of the tests would need "massaging" but I guess it won't shut you out from >>>>>> retaining the support for non-flattened value type fields. >>>>> Yes, I'm fine with modifying the tests, I'm just concerned that without testing the implementation >>>>> of non-flattenable fields in the JVM, the code will start to rot very soon. >>>>> >>>>> Thanks, >>>>> Tobias >>> > From tobias.hartmann at oracle.com Wed Jun 27 13:42:23 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 27 Jun 2018 15:42:23 +0200 Subject: RFR: 8205340: [lworld] Re-enable _hashCode, _identityHashCode and _newArray intrinsics In-Reply-To: References: Message-ID: <48f9a94b-018b-a08e-9389-3d6d9d5bbc5a@oracle.com> Hi Roland, this looks good but shouldn't we just go the slow path in inline_native_hashcode() instead of deoptimizing? Thanks, Tobias On 27.06.2018 15:01, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8205340/webrev.00/ > > I expect this change to fix all remaining intrinsics. I found that > flattened array allocation through reflection would never go through the > fast path. Once that was fixed then I hit some failure in > arraycopy/copyOf tests that this patch fixes. hashCode() tests are > currently commented out because they trigger the bug I reported on this > list earlier: > > http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-June/004383.html > > The tests did pass when I developped this patch on an older revision of > the repo. > > Roland. > From rwestrel at redhat.com Wed Jun 27 14:28:20 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 27 Jun 2018 16:28:20 +0200 Subject: RFR: 8205340: [lworld] Re-enable _hashCode, _identityHashCode and _newArray intrinsics In-Reply-To: <48f9a94b-018b-a08e-9389-3d6d9d5bbc5a@oracle.com> References: <48f9a94b-018b-a08e-9389-3d6d9d5bbc5a@oracle.com> Message-ID: Hi Tobias, Thanks for looking at this. > this looks good but shouldn't we just go the slow path in inline_native_hashcode() instead of > deoptimizing? Right. Not sure why I thought it was a problem. http://cr.openjdk.java.net/~roland/8205340/webrev.01/ Roland. From karen.kinnear at oracle.com Wed Jun 27 15:54:37 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 27 Jun 2018 11:54:37 -0400 Subject: Empty value type ? In-Reply-To: <783083966.669860.1530019680824.JavaMail.zimbra@u-pem.fr> References: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> <783083966.669860.1530019680824.JavaMail.zimbra@u-pem.fr> Message-ID: Filed an LW1 bug: 8205933 as you suggested. We will revisit after LW1 and set behavior expectations then. Thank you so much for all the experimentation and feedback. thanks, Karen > On Jun 26, 2018, at 9:28 AM, forax at univ-mlv.fr wrote: > > ok, > in that case, i think zero field value types should be rejected by the compiler. > > R?mi > > ----- Mail original ----- >> De: "Tobias Hartmann" >> ?: "Remi Forax" , "valhalla-dev" >> Envoy?: Mardi 26 Juin 2018 15:23:46 >> Objet: Re: Empty value type ? > >> Hi Remi, >> >> no, empty value types are not planned to be supported for LW1. >> >> Best regards, >> Tobias >> >> On 26.06.2018 15:19, Remi Forax wrote: >>> Is empty value type targeted for LW1 ? >>> >>> Error: LinkageError occurred while loading main class GenBug >>> java.lang.ClassFormatError: class: GenBug - Value Types do not support zero >>> instance size yet >>> >>> R?mi From srikanth.adayapalam at oracle.com Wed Jun 27 15:58:50 2018 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Wed, 27 Jun 2018 21:28:50 +0530 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <26841429-014F-44FA-B13E-68EA56F71E18@oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> <53abe74c-2b1c-79bf-eeb8-c4774f17fd4a@oracle.com> <70fbad77-2b90-9e0b-4acc-6e6af25835d9@oracle.com> <47608021-f50c-dcfa-5d22-28f0f3e32219@oracle.com> <872616D9-4CA6-4D9B-9B9B-860EEF947A79@oracle.com> <9b10e572-048c-3c3e-2a79-70c6998187d8@oracle.com> <26841429-014F-44FA-B13E-68EA56F71E18@oracle.com> Message-ID: <1c56eca8-3a1a-881d-4841-ad6efeb2d1dd@oracle.com> Hello Karen, Yes, I believe both 1 and 2 below are taken care of and any behavior contrary to that would be a bug. There is no known bug ATM in this space. Srikanth On Wednesday 27 June 2018 07:03 PM, Karen Kinnear wrote: > To be really really clear what we are asking for for LW1: > > 1. Modifiers: __Flattenable, __NotFlattened would be accepted only under -XDAllowFlattenabilityModifiers flag > Many of the existing tests will need to be modified to add this flag. > > 2. ACC_FLATTENABLE > For LW1, by default all instance fields containing value types would be marked as ACC_FLATTENABLE in the classfile. > Static fields would not. This continues to work even without the -XDAllowFlattenabilityModifiers flag. > Please make sure this is true - the patch you sent e.g. ClassWriter looks like that might now be true. > > We won?t make LW1 if we change the classfile at this point. > > So for the LW1 timeframe, the consensus is NOT to move away from ACC_FLATTENABLE. > > Apologies for the confusion, > Karen > > > >> On Jun 26, 2018, at 11:40 PM, Srikanth wrote: >> >> I am working on it, will push soon. >> >> Srikanth >> >> On Tuesday 26 June 2018 09:17 PM, Karen Kinnear wrote: >>> Srikanth, Tobias, >>> >>> Yes please to push this patch to move these modifiers under the experimental flag. this is a much better approach. >>> >>> LW1 is a really tight deadline right now and we don?t want to cause extra work. >>> My apologies for missing the implications. >>> >>> thank you both, >>> Karen >>> >>>> On Jun 26, 2018, at 7:23 AM, Srikanth wrote: >>>> >>>> >>>> The attached patch would cause the flattenability modifiers to be accepted with their erstwhile syntax and semantics when javac is invoked with -XDallowFlattenabilityModifiers >>>> >>>> I'll wait to hear from Karen and push/discard accordingly. >>>> >>>> (I am likely away Thursday/Friday, I will be available on Wednesday. Posting a patch here, so if it is required in my absence it can be availed. It passes all langtools tests) >>>> >>>> Thanks! >>>> Srikanth >>>> >>>> On Tuesday 26 June 2018 03:38 PM, Srikanth wrote: >>>>> On Tuesday 26 June 2018 03:32 PM, Tobias Hartmann wrote: >>>>>> Hi Srikanth, >>>>>> >>>>>> On 26.06.2018 11:37, Srikanth wrote: >>>>>>> I did have an express go from Karen to "nuke" these source level modifiers before proceeding. But in >>>>>>> light of what you say, I'll take a look and see what is involved in pushing these under an option >>>>>>> instead. >>>>>> Thanks for looking into it but we should probably wait for Karen to comment on that. I guess I >>>>>> missed the discussion/decision of fully removing these modifiers (I thought we just don't want to >>>>>> support them for LW1). >>>>> Sounds good to me. I'll keep a patch ready in any case and after hearing from Karen decide to push or discard. >>>>> >>>>> I believe the consensus in the VM is to move away fromACC_FLATTENABLE on fields to using the ValueTypes attribute. >>>>> >>>>> Your concern below about the code rot is valid. >>>>> >>>>> Srikanth >>>>>>> Even with that many of the tests would need "massaging" but I guess it won't shut you out from >>>>>>> retaining the support for non-flattened value type fields. >>>>>> Yes, I'm fine with modifying the tests, I'm just concerned that without testing the implementation >>>>>> of non-flattenable fields in the JVM, the code will start to rot very soon. >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>> From karen.kinnear at oracle.com Wed Jun 27 16:03:22 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 27 Jun 2018 12:03:22 -0400 Subject: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers. In-Reply-To: <1c56eca8-3a1a-881d-4841-ad6efeb2d1dd@oracle.com> References: <201806260733.w5Q7XFDa023713@aojmv0008.oracle.com> <6c76c111-92fa-0fbe-1047-67605b93bdae@oracle.com> <0bee271a-6d1a-4970-0bf8-5774cc1e4cfe@oracle.com> <37ba0c2d-659a-3b1c-8fbc-f7f1eb9cfb28@oracle.com> <53abe74c-2b1c-79bf-eeb8-c4774f17fd4a@oracle.com> <70fbad77-2b90-9e0b-4acc-6e6af25835d9@oracle.com> <47608021-f50c-dcfa-5d22-28f0f3e32219@oracle.com> <872616D9-4CA6-4D9B-9B9B-860EEF947A79@oracle.com> <9b10e572-048c-3c3e-2a79-70c6998187d8@oracle.com> <26841429-014F-44FA-B13E-68EA56F71E18@oracle.com> <1c56eca8-3a1a-881d-4841-ad6efeb2d1dd@oracle.com> Message-ID: Many thanks Srikanth - I had missed that you already pushed this. Very much appreciated. thanks, Karen > On Jun 27, 2018, at 11:58 AM, Srikanth wrote: > > Hello Karen, > > Yes, I believe both 1 and 2 below are taken care of and any behavior contrary to that would be a bug. There is no known bug ATM in this space. > > Srikanth > > On Wednesday 27 June 2018 07:03 PM, Karen Kinnear wrote: >> To be really really clear what we are asking for for LW1: >> >> 1. Modifiers: __Flattenable, __NotFlattened would be accepted only under -XDAllowFlattenabilityModifiers flag >> Many of the existing tests will need to be modified to add this flag. >> >> 2. ACC_FLATTENABLE >> For LW1, by default all instance fields containing value types would be marked as ACC_FLATTENABLE in the classfile. >> Static fields would not. This continues to work even without the -XDAllowFlattenabilityModifiers flag. >> Please make sure this is true - the patch you sent e.g. ClassWriter looks like that might now be true. >> >> We won?t make LW1 if we change the classfile at this point. >> >> So for the LW1 timeframe, the consensus is NOT to move away from ACC_FLATTENABLE. >> >> Apologies for the confusion, >> Karen >> >> >> >>> On Jun 26, 2018, at 11:40 PM, Srikanth wrote: >>> >>> I am working on it, will push soon. >>> >>> Srikanth >>> >>> On Tuesday 26 June 2018 09:17 PM, Karen Kinnear wrote: >>>> Srikanth, Tobias, >>>> >>>> Yes please to push this patch to move these modifiers under the experimental flag. this is a much better approach. >>>> >>>> LW1 is a really tight deadline right now and we don?t want to cause extra work. >>>> My apologies for missing the implications. >>>> >>>> thank you both, >>>> Karen >>>> >>>>> On Jun 26, 2018, at 7:23 AM, Srikanth wrote: >>>>> >>>>> >>>>> The attached patch would cause the flattenability modifiers to be accepted with their erstwhile syntax and semantics when javac is invoked with -XDallowFlattenabilityModifiers >>>>> >>>>> I'll wait to hear from Karen and push/discard accordingly. >>>>> >>>>> (I am likely away Thursday/Friday, I will be available on Wednesday. Posting a patch here, so if it is required in my absence it can be availed. It passes all langtools tests) >>>>> >>>>> Thanks! >>>>> Srikanth >>>>> >>>>> On Tuesday 26 June 2018 03:38 PM, Srikanth wrote: >>>>>> On Tuesday 26 June 2018 03:32 PM, Tobias Hartmann wrote: >>>>>>> Hi Srikanth, >>>>>>> >>>>>>> On 26.06.2018 11:37, Srikanth wrote: >>>>>>>> I did have an express go from Karen to "nuke" these source level modifiers before proceeding. But in >>>>>>>> light of what you say, I'll take a look and see what is involved in pushing these under an option >>>>>>>> instead. >>>>>>> Thanks for looking into it but we should probably wait for Karen to comment on that. I guess I >>>>>>> missed the discussion/decision of fully removing these modifiers (I thought we just don't want to >>>>>>> support them for LW1). >>>>>> Sounds good to me. I'll keep a patch ready in any case and after hearing from Karen decide to push or discard. >>>>>> >>>>>> I believe the consensus in the VM is to move away fromACC_FLATTENABLE on fields to using the ValueTypes attribute. >>>>>> >>>>>> Your concern below about the code rot is valid. >>>>>> >>>>>> Srikanth >>>>>>>> Even with that many of the tests would need "massaging" but I guess it won't shut you out from >>>>>>>> retaining the support for non-flattened value type fields. >>>>>>> Yes, I'm fine with modifying the tests, I'm just concerned that without testing the implementation >>>>>>> of non-flattenable fields in the JVM, the code will start to rot very soon. >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>> > From forax at univ-mlv.fr Wed Jun 27 18:56:39 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 27 Jun 2018 20:56:39 +0200 (CEST) Subject: Traversing an array of value types seen as an array of Object is slow Message-ID: <1826106725.1109413.1530125799135.JavaMail.zimbra@u-pem.fr> I maybe wrong with the conclusion but this benchmark [1] show that there is something fishy. Benchmark Mode Cnt Score Error Units ReifiedListBenchMark.arraylist_integer_get avgt 9 0.068 ? 0.001 ms/op ReifiedListBenchMark.arraylist_integer_iterator avgt 9 0.069 ? 0.001 ms/op ReifiedListBenchMark.reifiedlist_intbox_cursor avgt 9 516.526 ? 11.903 ms/op ReifiedListBenchMark.reifiedlist_intbox_get avgt 9 523.149 ? 9.194 ms/op ReifiedListBenchMark.reifiedlist_intbox_iterator avgt 9 514.091 ? 18.357 ms/op A reified list uses an array created by reflection and seen as an Object[]. The creation and the population of the array is done out-of-the-band and not benchmarked, the benchmark only test several ways to access to the array in a loop. It seems that the JIT never try to optimize the loop for whatever reason so the loop is done by the interpreter and only the access to the array cell is JITed. R?mi [1] https://github.com/forax/valuetype-lworld/blob/master/src/test/java/fr.umlv.valuetype/fr/umlv/valuetype/perf/ReifiedListBenchMark.java From frederic.parain at oracle.com Wed Jun 27 21:17:08 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 27 Jun 2018 17:17:08 -0400 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe Message-ID: Please review this changeset which adds support for flattened values to the Unsafe API. http://cr.openjdk.java.net/~fparain/Unsafe/webrev.02/index.html This changeset addresses the following issues: - reading from /writing to a flattenable/flattened field with Unsafe - null-check when writing to a flattenable field - initialization barrier when reading an uninitialized static value field with Unsafe - enforcing values immutability even when using Unsafe - reading from /writing to a value array with Unsafe - null-check when writing to a value array with Unsafe Thanks, Fred From karen.kinnear at oracle.com Wed Jun 27 21:36:44 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 27 Jun 2018 17:36:44 -0400 Subject: JDK-8205549: unsafe and LW1: needed for MethodHandles, VarHandles and Reflection Message-ID: <78B3AFFB-FCFF-47C3-BBA4-4D4E34E094A6@oracle.com> I?ve appended a summary of Unsafe object accessors used in MethodHandles, VarHandles and Reflection. Thanks to Remi?s hashCode that Mandy was trying, we identified a hole in our current implementation. Turns out our tests for MethodHandles, VarHandles and Reflection did not include testing for field accessors to flattened value type fields, which all use unsafe. Model of usage (see e.g. test/hotspot/jtreg/runtime/Unsafe/GetPutObject.java) 1. use reflection to return a j.l.reflect.Field: Test.class.getField("fieldname") 2. unsafe.objectFieldOffset(j.l.reflect.Field) 3. unsafe.getObject(jobject t, offset) sample array usage: Object arrayObject[] 1. int scale = unsafe.arrayIndexScale(arrayObject.getClass()) 2. long offset = unsafe.arrayBaseOffset(arrayObject.getClass()) 3. iterate, starting with offset, += scale and pass to unsafe.getObject(arrayObject, offset) Issues: 1. getObject on a flattened value field today will return the first 64 bits of the flattened contents 2. putObject on a flattened value field today will overwrite the first 64 bits with an object address 3. put$Type$ to a field in a value class will NOT prevent writing note: I recognize this is unsafe. I highly recommend we prevent writing when given a clazz and offset so we can identify a value type field. 4. getObject/putObject not only accept a clazz + offset, they also accept a null base pointer + arbitrary address - there is no way to determine the start of the object 5. performance - basic unsafe calls are going to be very slow when applied to flattened fields 6. C2 intrinsics - today we count on intrinsics to make these fast. If C2 scalarizes fields from a value type, there may not be any value type to return Status: 1. Frederic has been working rapidly on an initial prototype for changing unsafe, and sent a webrev for unsafe changes. http://cr.openjdk.java.net/~fparain/Unsafe/webrev.02/index.html Note - this will not handle passing a null base pointer to a value type 2. Paul has started prototyping one possible form of optimization - - add some internal APIs to determine if you have a flattened field or array - call a different unsafe API to access a flattened field or array element - use this for VarHandles 3. Mandy is prototyping optimizations for MethodHandles and Reflection to use these new APIs Next Steps: Roland: Please do look at C2 intrinsics for the unsafe Object accessors and see what it would take to make these intrinsics work for value types If you think there is significant benefit in adding new APIs, please help us understand what APIs might be most helpful. Mandy, Paul - could you possibly send your webrevs when you are ready? Then we can have a better conversation of alternatives with our C2 folks. We will need a more complete set of tests specifically for MethodHandles, VarHandles and Reflection as well as for unsafe. thanks, Karen p.s. Here is the usage of unsafe for MethodHandles, VarHandles, Reflection and java.util.Concurrent. I did not include explicit internal uses on JDK existing classes or on ByteBuffers. I did not do a complete search of the JDK. MethodHandles: DirectMethodHandles create LambdaForms with NamedFunctions in unsafe to access fields. Underneath they use unsafe: getObject, getObjectVolatile, putObject, putObjectVolatile as well as equivalents for primitive types. sources in DirectMethodHandles.java: see makePreparedFieldLambdaForm, getFieldKind: Kind is an enum in LambdaForm.java note: uses MethodHandleNatives.objectFieldOffset, staticFieldBase, staticFieldOffset to set up base & offset, base is always either the mirror for statics or the class for instances. offset is obtained from fieldDescriptor returned by LinkResolver::resolve_field, i.e. instanceKlass.find_field(). MemberName stores offset in vmindex, is_static, is_setter are stored in flags. I do not see any array element accessors via MethodHandles VarHandles: Creates Forms which use unsafe.get$Type$ use: getObject, putObject and decorations such as Volatile, Opaque,Acquire, ? as well as equivalents for primitive types VarHandles ALSO access array elements using unsafe. arrayBaseOffset, arrayIndexScale (returns ascale) shift = 31 - Integer.numberOfLeadingZeros(ascale) and then e.g. UNSAFE.get$Type$Volatile, etc. (sources in VarHandle.s.java, X-VarHandle.java.template). Acquire base and offset from MethodHandleNatives calls. For the non-volatile case, appears to directly get/set from the array[index] Reflection: Reflection creates UnsafeFieldAccessorImpl (or Qualified for Volatile, same 2 for static) and they use unsafe: getObject, putObject, getObjectVolatile, putObjectVolatile sources in jdk/internal/reflect/UnsafeFieldAccessorImpl.java uses unsafe.staticFieldOffset or unsafe.objectFieldOffset I do not see any array element accessors in Reflection. java.util.Concurrent: Atomics - uses various decorated versions of Get/putObjectVolatile/Release/compareAndSet etc. I think clarifying that LW1 does not support java.util.Concurrent atomics is the way to handle this one. From karen.kinnear at oracle.com Wed Jun 27 21:49:10 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 27 Jun 2018 17:49:10 -0400 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: References: Message-ID: Frederic, Many thanks for doing this so quickly! The code looks good. I only had one minor question - 1. allocate_buffered_or_heap_instance - I assume that for unsafe you always want a heap instance? - I recognize that today this will always return a heap instance thanks, Karen > On Jun 27, 2018, at 5:17 PM, Frederic Parain wrote: > > Please review this changeset which adds support for flattened values to the Unsafe API. > > http://cr.openjdk.java.net/~fparain/Unsafe/webrev.02/index.html > > This changeset addresses the following issues: > - reading from /writing to a flattenable/flattened field with Unsafe > - null-check when writing to a flattenable field > - initialization barrier when reading an uninitialized static value field with Unsafe > - enforcing values immutability even when using Unsafe > - reading from /writing to a value array with Unsafe > - null-check when writing to a value array with Unsafe > > Thanks, > > Fred > From frederic.parain at oracle.com Wed Jun 27 22:10:14 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 27 Jun 2018 18:10:14 -0400 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: References: Message-ID: > On Jun 27, 2018, at 17:49, Karen Kinnear wrote: > > Frederic, > > Many thanks for doing this so quickly! > The code looks good. > > I only had one minor question - > > 1. allocate_buffered_or_heap_instance > - I assume that for unsafe you always want a heap instance? Why would you force a heap allocation? The reference being returned is local the the thread. > - I recognize that today this will always return a heap instance Correct. Thanks, Fred > > thanks, > Karen > >> On Jun 27, 2018, at 5:17 PM, Frederic Parain wrote: >> >> Please review this changeset which adds support for flattened values to the Unsafe API. >> >> http://cr.openjdk.java.net/~fparain/Unsafe/webrev.02/index.html >> >> This changeset addresses the following issues: >> - reading from /writing to a flattenable/flattened field with Unsafe >> - null-check when writing to a flattenable field >> - initialization barrier when reading an uninitialized static value field with Unsafe >> - enforcing values immutability even when using Unsafe >> - reading from /writing to a value array with Unsafe >> - null-check when writing to a value array with Unsafe >> >> Thanks, >> >> Fred >> > From paul.sandoz at oracle.com Wed Jun 27 22:11:40 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Jun 2018 15:11:40 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: References: Message-ID: <91E09FA6-B765-4C37-8510-75DEFB3D026A@oracle.com> Hi Frederic, Code looks good, but I have some concerns that modifying the existing non-intrinsic native implementations is the best direction to take. It may be better progress-wise for now to create new Unsafe methods for plain flat access: - we don?t peturb existing behavior and usages of unsafe accessors and deviate from C1/C2 behavior. - we can provide flat atomic accessors in Java by leveraging the plain accessors with locks thereby crudely supporting VarHandles until we can do something better. - its not clear to me that the existing Unsafe plain access signatures are the right approach for flat access, nor is it clear to me the degree of checks that should be performed, after all this is Unsafe where checks are commonly performed before making unsafe calls with appropriately vetted arguments allowing for efficient code to be generated. Input from C2 experts will i think help with regards to the signature and required checks if any. ? I was hacking around with an alternative based on your code that creates separate methods (with lighter checks pushed to asserts, but i almost removed ?em): http://cr.openjdk.java.net/~psandoz/valhalla/unsafe-flat-value-access/webrev/ The general idea being one could write or read a value to or from an area of memory, it's up to the caller to pass in the correct arguments. So that in principle works for flat fields, flat arrays, or off-heap. However, i don?t understand the the value type code in detail so perhaps such an approach is misguided? Paul. > On Jun 27, 2018, at 2:17 PM, Frederic Parain wrote: > > Please review this changeset which adds support for flattened values to the Unsafe API. > > http://cr.openjdk.java.net/~fparain/Unsafe/webrev.02/index.html > > This changeset addresses the following issues: > - reading from /writing to a flattenable/flattened field with Unsafe > - null-check when writing to a flattenable field > - initialization barrier when reading an uninitialized static value field with Unsafe > - enforcing values immutability even when using Unsafe > - reading from /writing to a value array with Unsafe > - null-check when writing to a value array with Unsafe > > Thanks, > > Fred > From john.r.rose at oracle.com Wed Jun 27 22:22:23 2018 From: john.r.rose at oracle.com (John Rose) Date: Wed, 27 Jun 2018 15:22:23 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: References: Message-ID: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> On Jun 27, 2018, at 2:17 PM, Frederic Parain wrote: > > Please review this changeset which adds support for flattened values to the Unsafe API. > > http://cr.openjdk.java.net/~fparain/Unsafe/webrev.02/index.html > > This changeset addresses the following issues: > - reading from /writing to a flattenable/flattened field with Unsafe > - null-check when writing to a flattenable field > - initialization barrier when reading an uninitialized static value field with Unsafe > - enforcing values immutability even when using Unsafe > - reading from /writing to a value array with Unsafe > - null-check when writing to a value array with Unsafe > > Thanks, > > Fred Impressive work Fred; you have a nice way to doing the impossible. The existing version of U.putObject doesn't look at metadata, but clearly the new version has to depend on metadata to see how the container is shaped. I see how this can work the way you did it, and why it's useful to unblock prototyping. But it's not a design that I want to see made permanent. Container analysis is a delicate and potentially buggy operation which I am surprised can be hidden safely under U.putObject. The basic contract of Unsafe is to force the user to take responsibility for querying the container, and issue the U.putX that matches the container. The benefit of this contract is not only avoiding delicate and buggy operations inside Unsafe, but also a simpler optimization model. So, I view this as a work-in-progress, which can unblock existing code that uses Unsafe without requiring that code to be revamped. Later, the get/putObject APIs need to be split into versions which explicitly manage references vs. flat values. Unsafe-using code that wants full optimization will want to avoid get/putObject if it has this complicated stuff going on under the hood. New API points are needed to let the user work explicitly with the container shape: public Object getValue(Object o, long offset, Class valueType); public void putValue(Object o, long offset, Class valueType, Object value); public Object getReference(Object o, long offset); public void putReference(Object o, long offset, Object reference); The get/putValue API points would load and store values of the given type in their native format (flattened). If you knew a container wasn't flattened although the type could be, you'd call putReference. We could also deprecate get/putObject so that users will be forced to do the container analysis. An non-deprecated version of your container analysis should have a more complex-sounding name, such as getReferenceOrValue. Or we should just force users to write their own; it's simple if the hooks are provided (see below). The valueType operand is there even when the value is also present, for robustness. If we derive valueType from value automatically, the user loses a channel for asserting the container analysis. You could get heap-scribbling bugs when the value is of the wrong type. Oddly enough, the Unsafe API has a concern with safety: You have to give the user a reasonable chance to write safe code using Unsafe. I think we also want queries which can execute the logic you have written, directly, and not in the course of reading or writing the heap. Something like this would give unsafe users control over factoring the metadata queries from the access itself: public Class objectFieldContainerType(Field f); public Field findObjectField(Class objClass, long offset); public Object getReferenceOrValue(Object o, long offset) { Class ctype = objectFieldContainerType(findObjectField(o.getClass(), offset)); if (ctype.isValue()) return getValue(o, offset, ctype); else return getReference(o, offset); } All that said, for the present review, it looks good as a work in progress. (If the benefit of overloading get/putObject is small, consider naming this new logic with a new name like getReferenceOrValue. But I'm guessing the overloading trick is a short-term requirement, to avoid cracking open lots of platform code.) If we don't have another bug to track Unsafe support for container analysis of flat fields, let's file one as a followup to this. ? John From mandy.chung at oracle.com Wed Jun 27 22:23:31 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 27 Jun 2018 15:23:31 -0700 Subject: JDK-8205549: unsafe and LW1: needed for MethodHandles, VarHandles and Reflection In-Reply-To: <78B3AFFB-FCFF-47C3-BBA4-4D4E34E094A6@oracle.com> References: <78B3AFFB-FCFF-47C3-BBA4-4D4E34E094A6@oracle.com> Message-ID: <306292d9-5723-f826-0f42-976da78ccdbc@oracle.com> On 6/27/18 2:36 PM, Karen Kinnear wrote: > I?ve appended a summary of Unsafe object accessors used in > MethodHandles, VarHandles and Reflection. > > Thanks to Remi?s hashCode that Mandy was trying, we identified a hole > in our current implementation. Turns out our tests for MethodHandles, > VarHandles and Reflection did not include testing for field > accessors to flattened value type fields, which all use unsafe. In fact Roland reported the crash [1] (thanks). > Next Steps: > > Roland: Please do look at C2 intrinsics for the unsafe Object > accessors and see what it would take to make these intrinsics work > for value types If you think there is significant benefit in adding > new APIs, please help us understand what APIs might be most helpful. > > Mandy, Paul - could you possibly send your webrevs when you are > ready? http://cr.openjdk.java.net/~mchung/valhalla/webrevs/unsafe-flat-fields-webrev/index.html This approach adds Unsafe::getFlatObject and Unsafe::putFlatObject for flattened field access. This allows Unsafe::getObjectXXX and putObjectXXX to work for non-flattened fields without suffering the performance hit. Paul suggests to add Unsafe::isFlatField method. For now, I piggyback on Field's modifiers and MemberName's flags to indicate if it's flattened or not. This is still work in progress but this should give you a good idea what the new APIs we are thinking about. This way it allows the system to move forward to minimize the performance impact on non-value types and give time to implement the proper optimization for flattened field access. > Then we can have a better conversation of alternatives with our C2 > folks. > > We will need a more complete set of tests specifically for > MethodHandles, VarHandles and Reflection as well as for unsafe. Agree. I'm adding more tests for java.lang.invoke and java.lang.reflect w.r.t. flattened/flattenable fields. Mandy [1] http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-June/004383.html From forax at univ-mlv.fr Wed Jun 27 22:28:47 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 28 Jun 2018 00:28:47 +0200 (CEST) Subject: JDK-8205549: unsafe and LW1: needed for MethodHandles, VarHandles and Reflection In-Reply-To: <78B3AFFB-FCFF-47C3-BBA4-4D4E34E094A6@oracle.com> References: <78B3AFFB-FCFF-47C3-BBA4-4D4E34E094A6@oracle.com> Message-ID: <1326849285.1130691.1530138526996.JavaMail.zimbra@u-pem.fr> Hi Karen, at least MethodHandles.zero also doesn't work with a value type. and there are method handles to access arrays, see below. R?mi ----- Mail original ----- > De: "Karen Kinnear" > ?: "valhalla-dev" > Envoy?: Mercredi 27 Juin 2018 23:36:44 > Objet: JDK-8205549: unsafe and LW1: needed for MethodHandles, VarHandles and Reflection > I?ve appended a summary of Unsafe object accessors used in MethodHandles, > VarHandles and Reflection. > > Thanks to Remi?s hashCode that Mandy was trying, we identified a hole in our > current implementation. > Turns out our tests for MethodHandles, VarHandles and Reflection did not include > testing for field accessors > to flattened value type fields, which all use unsafe. > > Model of usage (see e.g. test/hotspot/jtreg/runtime/Unsafe/GetPutObject.java) > 1. use reflection to return a j.l.reflect.Field: > Test.class.getField("fieldname") > 2. unsafe.objectFieldOffset(j.l.reflect.Field) > 3. unsafe.getObject(jobject t, offset) > > sample array usage: > Object arrayObject[] > 1. int scale = unsafe.arrayIndexScale(arrayObject.getClass()) > 2. long offset = unsafe.arrayBaseOffset(arrayObject.getClass()) > 3. iterate, starting with offset, += scale and pass to > unsafe.getObject(arrayObject, offset) > > Issues: > 1. getObject on a flattened value field today will return the first 64 bits of > the flattened contents > 2. putObject on a flattened value field today will overwrite the first 64 bits > with an object address > 3. put$Type$ to a field in a value class will NOT prevent writing > note: I recognize this is unsafe. I highly recommend we prevent writing when > given a clazz and offset so > we can identify a value type field. > 4. getObject/putObject not only accept a clazz + offset, they also accept a null > base pointer + arbitrary address > - there is no way to determine the start of the object > 5. performance > - basic unsafe calls are going to be very slow when applied to flattened fields > 6. C2 intrinsics > - today we count on intrinsics to make these fast. If C2 scalarizes fields from > a value type, there may not be any value type to return > > Status: > 1. Frederic has been working rapidly on an initial prototype for changing > unsafe, and sent a webrev > for unsafe changes. > http://cr.openjdk.java.net/~fparain/Unsafe/webrev.02/index.html > > Note - this will not handle passing a null base pointer to a value type > > 2. Paul has started prototyping one possible form of optimization - > - add some internal APIs to determine if you have a flattened field or array > - call a different unsafe API to access a flattened field or array element > - use this for VarHandles > > 3. Mandy is prototyping optimizations for MethodHandles and Reflection to use > these new APIs > > Next Steps: > > Roland: > Please do look at C2 intrinsics for the unsafe Object accessors and see what it > would take to make these intrinsics work > for value types > If you think there is significant benefit in adding new APIs, please help us > understand what APIs might be most helpful. > > Mandy, Paul - could you possibly send your webrevs when you are ready? > > Then we can have a better conversation of alternatives with our C2 folks. > > We will need a more complete set of tests specifically for MethodHandles, > VarHandles and Reflection as well as for > unsafe. > > > thanks, > Karen > > p.s. Here is the usage of unsafe for MethodHandles, VarHandles, Reflection and > java.util.Concurrent. > I did not include explicit internal uses on JDK existing classes or on > ByteBuffers. > I did not do a complete search of the JDK. > > MethodHandles: > > DirectMethodHandles create LambdaForms with NamedFunctions in unsafe to access > fields. Underneath they use unsafe: > getObject, getObjectVolatile, putObject, putObjectVolatile as well as > equivalents for primitive types. > > sources in DirectMethodHandles.java: see makePreparedFieldLambdaForm, > getFieldKind: Kind is an enum in LambdaForm.java > note: uses MethodHandleNatives.objectFieldOffset, staticFieldBase, > staticFieldOffset to set up base & offset, base is always > either the mirror for statics or the class for instances. offset is obtained > from fieldDescriptor returned by LinkResolver::resolve_field, > i.e. instanceKlass.find_field(). MemberName stores offset in vmindex, is_static, > is_setter are stored in flags. > > I do not see any array element accessors via MethodHandles MethodHandles.arrayElementGetter() and MethodHandles.arrayElementSetter. > > VarHandles: > Creates Forms which use unsafe.get$Type$ use: > getObject, putObject and decorations such as Volatile, Opaque,Acquire, ? as well > as equivalents for primitive types > > VarHandles ALSO access array elements using unsafe. > arrayBaseOffset, arrayIndexScale (returns ascale) > shift = 31 - Integer.numberOfLeadingZeros(ascale) and then e.g. > UNSAFE.get$Type$Volatile, etc. > > (sources in VarHandle.s.java, X-VarHandle.java.template). Acquire base and > offset from MethodHandleNatives calls. > For the non-volatile case, appears to directly get/set from the array[index] > > Reflection: > Reflection creates UnsafeFieldAccessorImpl (or Qualified for Volatile, same 2 > for static) and they use unsafe: > getObject, putObject, getObjectVolatile, putObjectVolatile > > sources in jdk/internal/reflect/UnsafeFieldAccessorImpl.java uses > unsafe.staticFieldOffset or unsafe.objectFieldOffset > > I do not see any array element accessors in Reflection. > > java.util.Concurrent: Atomics - uses various decorated versions of > Get/putObjectVolatile/Release/compareAndSet etc. > I think clarifying that LW1 does not support java.util.Concurrent atomics is the > way to handle this one. From john.r.rose at oracle.com Wed Jun 27 22:31:36 2018 From: john.r.rose at oracle.com (John Rose) Date: Wed, 27 Jun 2018 15:31:36 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <91E09FA6-B765-4C37-8510-75DEFB3D026A@oracle.com> References: <91E09FA6-B765-4C37-8510-75DEFB3D026A@oracle.com> Message-ID: <9C46AE76-37B2-4444-AF41-D92731FE56CD@oracle.com> On Jun 27, 2018, at 3:11 PM, Paul Sandoz wrote: > > I was hacking around with an alternative based on your code that creates separate methods (with lighter checks pushed to asserts, but i almost removed ?em): > > http://cr.openjdk.java.net/~psandoz/valhalla/unsafe-flat-value-access/webrev/ > > > The general idea being one could write or read a value to or from an area of memory, it's up to the caller to pass in the correct arguments. So that in principle works for flat fields, flat arrays, or off-heap. However, i don?t understand the the value type code in detail so perhaps such an approach is misguided? Yep; container types should be explicit and required from the user of Unsafe. (That's what you call "layout" and I call "valueType".) One hallmark of the Unsafe API design is that assertions like you mention can be coded which will help catch user errors, but the assertions can safely be disabled without changing semantics. After assertions are dropped, what's left can be optimized readily by the JIT, often to an instruction or two. The JVM is clever about hiding the internal formats of its objects, but those formats ("layout" is a good term) need to be available to Unsafe users. We can assume that Class is a reasonably future-proof way to reify those decisions to Usafe users. The layout of a reference field can be Object.class regardless of any narrower type of the field (and even if the field is typed as a non-flat value). ? John From paul.sandoz at oracle.com Wed Jun 27 23:54:13 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Jun 2018 16:54:13 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> Message-ID: <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> Hi John, Those new API points you propose match closely with what i had in mind, and i also agree that a set of query methods are important (I was just scratching the surface of that). IMHO i think we can make a tentative split now and that would also increase prototyping velocity without potentially destabilizing existing unsafe usages. Mandy?s patch indicates the amount of Java platform code changes are manageable for such a split and it can allow for quicker experimentation with VarHandles. Paul. > On Jun 27, 2018, at 3:22 PM, John Rose wrote: > > On Jun 27, 2018, at 2:17 PM, Frederic Parain wrote: >> >> Please review this changeset which adds support for flattened values to the Unsafe API. >> >> http://cr.openjdk.java.net/~fparain/Unsafe/webrev.02/index.html >> >> This changeset addresses the following issues: >> - reading from /writing to a flattenable/flattened field with Unsafe >> - null-check when writing to a flattenable field >> - initialization barrier when reading an uninitialized static value field with Unsafe >> - enforcing values immutability even when using Unsafe >> - reading from /writing to a value array with Unsafe >> - null-check when writing to a value array with Unsafe >> >> Thanks, >> >> Fred > > Impressive work Fred; you have a nice way to doing the impossible. > > The existing version of U.putObject doesn't look at metadata, but clearly > the new version has to depend on metadata to see how the container is shaped. > > I see how this can work the way you did it, and why it's useful to unblock > prototyping. But it's not a design that I want to see made permanent. > > Container analysis is a delicate and potentially buggy operation which I am > surprised can be hidden safely under U.putObject. The basic contract of > Unsafe is to force the user to take responsibility for querying the container, > and issue the U.putX that matches the container. The benefit of this contract > is not only avoiding delicate and buggy operations inside Unsafe, but also > a simpler optimization model. > > So, I view this as a work-in-progress, which can unblock existing > code that uses Unsafe without requiring that code to be revamped. > > Later, the get/putObject APIs need to be split into versions which explicitly > manage references vs. flat values. Unsafe-using code that wants full > optimization will want to avoid get/putObject if it has this complicated > stuff going on under the hood. > > New API points are needed to let the user work explicitly with the > container shape: > > public Object getValue(Object o, long offset, Class valueType); > public void putValue(Object o, long offset, Class valueType, Object value); > public Object getReference(Object o, long offset); > public void putReference(Object o, long offset, Object reference); > > The get/putValue API points would load and store values of the given type > in their native format (flattened). If you knew a container wasn't flattened > although the type could be, you'd call putReference. > > We could also deprecate get/putObject so that users will be forced to > do the container analysis. An non-deprecated version of your container > analysis should have a more complex-sounding name, such as > getReferenceOrValue. Or we should just force users to write their > own; it's simple if the hooks are provided (see below). > > The valueType operand is there even when the value is also present, > for robustness. If we derive valueType from value automatically, the > user loses a channel for asserting the container analysis. You could > get heap-scribbling bugs when the value is of the wrong type. Oddly > enough, the Unsafe API has a concern with safety: You have to give > the user a reasonable chance to write safe code using Unsafe. > > I think we also want queries which can execute the logic you have written, > directly, and not in the course of reading or writing the heap. Something > like this would give unsafe users control over factoring the metadata > queries from the access itself: > > public Class objectFieldContainerType(Field f); > public Field findObjectField(Class objClass, long offset); > public Object getReferenceOrValue(Object o, long offset) { > Class ctype = objectFieldContainerType(findObjectField(o.getClass(), offset)); > if (ctype.isValue()) return getValue(o, offset, ctype); > else return getReference(o, offset); > } > > All that said, for the present review, it looks good as a work in progress. > > (If the benefit of overloading get/putObject is small, consider naming > this new logic with a new name like getReferenceOrValue. But I'm guessing > the overloading trick is a short-term requirement, to avoid cracking open > lots of platform code.) > > If we don't have another bug to track Unsafe support for container analysis > of flat fields, let's file one as a followup to this. > > ? John From rwestrel at redhat.com Thu Jun 28 07:31:24 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 28 Jun 2018 09:31:24 +0200 Subject: Traversing an array of value types seen as an array of Object is slow In-Reply-To: <1826106725.1109413.1530125799135.JavaMail.zimbra@u-pem.fr> References: <1826106725.1109413.1530125799135.JavaMail.zimbra@u-pem.fr> Message-ID: Hi R?mi, > I maybe wrong with the conclusion but this benchmark [1] show that there is something fishy. > > Benchmark Mode Cnt Score Error Units > ReifiedListBenchMark.arraylist_integer_get avgt 9 0.068 ? 0.001 ms/op > ReifiedListBenchMark.arraylist_integer_iterator avgt 9 0.069 ? 0.001 ms/op > ReifiedListBenchMark.reifiedlist_intbox_cursor avgt 9 516.526 ? 11.903 ms/op > ReifiedListBenchMark.reifiedlist_intbox_get avgt 9 523.149 ? 9.194 ms/op > ReifiedListBenchMark.reifiedlist_intbox_iterator avgt 9 514.091 ? 18.357 ms/op > > A reified list uses an array created by reflection and seen as an Object[]. > The creation and the population of the array is done out-of-the-band and not benchmarked, > the benchmark only test several ways to access to the array in a loop. > > It seems that the JIT never try to optimize the loop for whatever > reason so the loop is done by the interpreter and only the access to > the array cell is JITed. Thanks for reporting the issue. I'm taking a look. Roland. From rwestrel at redhat.com Thu Jun 28 08:15:34 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 28 Jun 2018 10:15:34 +0200 Subject: Traversing an array of value types seen as an array of Object is slow In-Reply-To: <1826106725.1109413.1530125799135.JavaMail.zimbra@u-pem.fr> References: <1826106725.1109413.1530125799135.JavaMail.zimbra@u-pem.fr> Message-ID: > It seems that the JIT never try to optimize the loop for whatever > reason so the loop is done by the interpreter and only the access to > the array cell is JITed. We currently don't support loading from an Object[] array that's actually a flattened value type array because we can't tell at compile time what value type is being loaded. That forces compiled code to deoptimize. Roland. From forax at univ-mlv.fr Thu Jun 28 09:22:07 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 28 Jun 2018 11:22:07 +0200 (CEST) Subject: Traversing an array of value types seen as an array of Object is slow In-Reply-To: References: <1826106725.1109413.1530125799135.JavaMail.zimbra@u-pem.fr> Message-ID: <314850162.1281145.1530177727856.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Roland Westrelin" > ?: "Remi Forax" , "valhalla-dev" > Envoy?: Jeudi 28 Juin 2018 10:15:34 > Objet: Re: Traversing an array of value types seen as an array of Object is slow >> It seems that the JIT never try to optimize the loop for whatever >> reason so the loop is done by the interpreter and only the access to >> the array cell is JITed. > > We currently don't support loading from an Object[] array that's > actually a flattened value type array because we can't tell at compile > time what value type is being loaded. That forces compiled code to > deoptimize. You can have a generic assembly code that loads the flattened value type as a reference (you need this kind of code for java.lang.reflect.Array.get() too) or/and you can consider that accessing the array is like a method call and profile the value type array and deoptimize only once. In that case, the profile should be the size of the layout of the value type. > > Roland. R?mi From tobias.hartmann at oracle.com Thu Jun 28 10:15:31 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 28 Jun 2018 12:15:31 +0200 Subject: RFR: 8205340: [lworld] Re-enable _hashCode, _identityHashCode and _newArray intrinsics In-Reply-To: References: <48f9a94b-018b-a08e-9389-3d6d9d5bbc5a@oracle.com> Message-ID: <62c43ba0-200d-edef-5848-8f6ad42cb87b@oracle.com> Hi Roland, looks good to me! Best regards, Tobias On 27.06.2018 16:28, Roland Westrelin wrote: > > Hi Tobias, > > Thanks for looking at this. > >> this looks good but shouldn't we just go the slow path in inline_native_hashcode() instead of >> deoptimizing? > > Right. Not sure why I thought it was a problem. > > http://cr.openjdk.java.net/~roland/8205340/webrev.01/ > > Roland. > From tobias.hartmann at oracle.com Thu Jun 28 10:16:39 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 28 Jun 2018 12:16:39 +0200 Subject: RFR: 8205340: [lworld] Re-enable _hashCode, _identityHashCode and _newArray intrinsics In-Reply-To: <62c43ba0-200d-edef-5848-8f6ad42cb87b@oracle.com> References: <48f9a94b-018b-a08e-9389-3d6d9d5bbc5a@oracle.com> <62c43ba0-200d-edef-5848-8f6ad42cb87b@oracle.com> Message-ID: <17f8caf6-7f7b-ba0b-b464-91ceca76842c@oracle.com> Just noticed that you can remove "Node* value_ctrl =" in library_call.cpp:3924 Tobias On 28.06.2018 12:15, Tobias Hartmann wrote: > Hi Roland, > > looks good to me! > > Best regards, > Tobias > > On 27.06.2018 16:28, Roland Westrelin wrote: >> >> Hi Tobias, >> >> Thanks for looking at this. >> >>> this looks good but shouldn't we just go the slow path in inline_native_hashcode() instead of >>> deoptimizing? >> >> Right. Not sure why I thought it was a problem. >> >> http://cr.openjdk.java.net/~roland/8205340/webrev.01/ >> >> Roland. >> From rwestrel at redhat.com Thu Jun 28 10:18:26 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 28 Jun 2018 12:18:26 +0200 Subject: Traversing an array of value types seen as an array of Object is slow In-Reply-To: <314850162.1281145.1530177727856.JavaMail.zimbra@u-pem.fr> References: <1826106725.1109413.1530125799135.JavaMail.zimbra@u-pem.fr> <314850162.1281145.1530177727856.JavaMail.zimbra@u-pem.fr> Message-ID: > You can have a generic assembly code that loads the flattened value > type as a reference (you need this kind of code for > java.lang.reflect.Array.get() too) or/and you can consider that > accessing the array is like a method call and profile the value type > array and deoptimize only once. In that case, the profile should be > the size of the layout of the value type. Right, we realize that. So a small matter of implementation... Roland. From rwestrel at redhat.com Thu Jun 28 10:19:01 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 28 Jun 2018 12:19:01 +0200 Subject: RFR: 8205340: [lworld] Re-enable _hashCode, _identityHashCode and _newArray intrinsics In-Reply-To: <62c43ba0-200d-edef-5848-8f6ad42cb87b@oracle.com> References: <48f9a94b-018b-a08e-9389-3d6d9d5bbc5a@oracle.com> <62c43ba0-200d-edef-5848-8f6ad42cb87b@oracle.com> Message-ID: Thanks for reviewing this. Roland. From tobias.hartmann at oracle.com Thu Jun 28 10:37:37 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 28 Jun 2018 12:37:37 +0200 Subject: c1 crashes ? In-Reply-To: References: <939492355.2043225.1529792921911.JavaMail.zimbra@u-pem.fr> <1460712418.141251.1529917627415.JavaMail.zimbra@u-pem.fr> <281714394.156878.1529918957955.JavaMail.zimbra@u-pem.fr> <5ed82987-e1e3-5c01-f639-92ddda64d278@oracle.com> <1406186202.663797.1530019277148.JavaMail.zimbra@u-pem.fr> Message-ID: <09c8423c-4a9c-c924-b063-3e17a6905a73@oracle.com> I've filed: https://bugs.openjdk.java.net/browse/JDK-8205998 Thanks, Tobias On 26.06.2018 15:22, Tobias Hartmann wrote: > > On 26.06.2018 15:21, forax at univ-mlv.fr wrote: >> yes and explain that value type can be enable using -XX:+EnableValhalla ? > > Yes, that would make sense to me. > > Thanks, > Tobias > From harold.seigel at oracle.com Thu Jun 28 13:54:01 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Thu, 28 Jun 2018 09:54:01 -0400 Subject: RFR: 8205998: [lworld] Verifier should reject value type classes if -XX:+EnableValhalla is not set Message-ID: <4ad03616-189a-0493-17c9-c1992cb113ec@oracle.com> Hi, Please review this LWorld fix that throws a ClassFormatError exception if a class is a value type class and -XX:+EnableValhalla is not set. Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8205998/webrev/index.html JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8205998 The fix was tested with tier1 and tier2 tests on Linux x64 and Macosx. Thanks, Harold From rwestrel at redhat.com Thu Jun 28 14:50:05 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 28 Jun 2018 16:50:05 +0200 Subject: RFR: 8205340: [lworld] Re-enable _hashCode, _identityHashCode and _newArray intrinsics In-Reply-To: <17f8caf6-7f7b-ba0b-b464-91ceca76842c@oracle.com> References: <48f9a94b-018b-a08e-9389-3d6d9d5bbc5a@oracle.com> <62c43ba0-200d-edef-5848-8f6ad42cb87b@oracle.com> <17f8caf6-7f7b-ba0b-b464-91ceca76842c@oracle.com> Message-ID: > Just noticed that you can remove "Node* value_ctrl =" in library_call.cpp:3924 Thanks. Will do that before I push it. Roland. From tobias.hartmann at oracle.com Thu Jun 28 14:56:27 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 28 Jun 2018 16:56:27 +0200 Subject: [lworld] RFR(M): Cleanup of null checks Message-ID: <4275c4dc-1b97-1330-db47-c1ad0b8d298a@oracle.com> Hi, please review the following patch: http://cr.openjdk.java.net/~thartmann/valhalla/lworld/null_check_cleanup/ Changes: - Moved all null checks into ValueTypeNode::make_from_oop(). We are now emitting null checks if the oop can be null - Added asserts at the call sites to verify that we never emit null checks where it's not required - Fixed a problem with OSR where a null value type is accessed without a null check (see new test in TestOnStackReplacement.java) - Some refactoring and comment cleanups All compiler and runtime tests pass. Thanks, Tobias From rwestrel at redhat.com Thu Jun 28 15:16:19 2018 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Thu, 28 Jun 2018 15:16:19 +0000 Subject: hg: valhalla/valhalla: 8205340: [lworld] Re-enable _hashCode, _identityHashCode and _newArray intrinsics Message-ID: <201806281516.w5SFGKBK015544@aojmv0008.oracle.com> Changeset: 7feb5ae0f3dc Author: roland Date: 2018-06-28 16:50 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7feb5ae0f3dc 8205340: [lworld] Re-enable _hashCode, _identityHashCode and _newArray intrinsics Reviewed-by: thartmann ! src/hotspot/share/classfile/vmSymbols.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macro.hpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/opto/parse2.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java From karen.kinnear at oracle.com Thu Jun 28 15:17:52 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 28 Jun 2018 11:17:52 -0400 Subject: RFR: 8205998: [lworld] Verifier should reject value type classes if -XX:+EnableValhalla is not set In-Reply-To: <4ad03616-189a-0493-17c9-c1992cb113ec@oracle.com> References: <4ad03616-189a-0493-17c9-c1992cb113ec@oracle.com> Message-ID: <186BE9D8-C17E-4223-807E-5C8E3A7C549F@oracle.com> Harold, Looks good. Thank you for fixing the existing tests as well. thanks, Karen > On Jun 28, 2018, at 9:54 AM, Harold David Seigel wrote: > > Hi, > > Please review this LWorld fix that throws a ClassFormatError exception if a class is a value type class and -XX:+EnableValhalla is not set. > > Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8205998/webrev/index.html > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8205998 > > The fix was tested with tier1 and tier2 tests on Linux x64 and Macosx. > > Thanks, Harold > From harold.seigel at oracle.com Thu Jun 28 15:18:14 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Thu, 28 Jun 2018 11:18:14 -0400 Subject: RFR: 8205998: [lworld] Verifier should reject value type classes if -XX:+EnableValhalla is not set In-Reply-To: <186BE9D8-C17E-4223-807E-5C8E3A7C549F@oracle.com> References: <4ad03616-189a-0493-17c9-c1992cb113ec@oracle.com> <186BE9D8-C17E-4223-807E-5C8E3A7C549F@oracle.com> Message-ID: <96d2d4f4-0936-0e38-2c6b-970ea1fab2d9@oracle.com> Thanks Karen! Harold On 6/28/2018 11:17 AM, Karen Kinnear wrote: > Harold, > > Looks good. Thank you for fixing the existing tests as well. > > thanks, > Karen > >> On Jun 28, 2018, at 9:54 AM, Harold David Seigel wrote: >> >> Hi, >> >> Please review this LWorld fix that throws a ClassFormatError exception if a class is a value type class and -XX:+EnableValhalla is not set. >> >> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8205998/webrev/index.html >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8205998 >> >> The fix was tested with tier1 and tier2 tests on Linux x64 and Macosx. >> >> Thanks, Harold >> From harold.seigel at oracle.com Thu Jun 28 15:31:15 2018 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Thu, 28 Jun 2018 15:31:15 +0000 Subject: hg: valhalla/valhalla: 8205998: [lworld] Verifier should reject value type classes if -XX:+EnableValhalla is not set Message-ID: <201806281531.w5SFVGXH020043@aojmv0008.oracle.com> Changeset: 7f4697fd100d Author: hseigel Date: 2018-06-28 11:30 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7f4697fd100d 8205998: [lworld] Verifier should reject value type classes if -XX:+EnableValhalla is not set Summary: Add check for this to classFileParser and throw ClassFormatError if need be. Reviewed-by: acorn ! src/hotspot/share/classfile/classFileParser.cpp + test/hotspot/jtreg/runtime/valhalla/valuetypes/classfileparser/BadACCValue.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/classfileparser/BadValueTypes.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/verifier/VerifierValueTypes.java ! test/jdk/valhalla/valuetypes/Reflection.java ! test/jdk/valhalla/valuetypes/ValueBootstrapMethods.java ! test/langtools/tools/javac/valhalla/lworld-values/CastNullCheckTest.java ! test/langtools/tools/javac/valhalla/lworld-values/CheckDefaultFlattenable.java ! test/langtools/tools/javac/valhalla/lworld-values/ValueBootstrapMethodsTest.java ! test/langtools/tools/javac/valhalla/lworld-values/ValuesAsRefs.java ! test/langtools/tools/javac/valhalla/lworld-values/WithFieldRuntimeTest.java From forax at univ-mlv.fr Thu Jun 28 20:03:55 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 28 Jun 2018 22:03:55 +0200 (CEST) Subject: RFR: 8205998: [lworld] Verifier should reject value type classes if -XX:+EnableValhalla is not set In-Reply-To: <96d2d4f4-0936-0e38-2c6b-970ea1fab2d9@oracle.com> References: <4ad03616-189a-0493-17c9-c1992cb113ec@oracle.com> <186BE9D8-C17E-4223-807E-5C8E3A7C549F@oracle.com> <96d2d4f4-0936-0e38-2c6b-970ea1fab2d9@oracle.com> Message-ID: <1741673184.1526637.1530216235385.JavaMail.zimbra@u-pem.fr> Works great :) /usr/jdk/jdk-11-lworld/bin/java --module-path target/test/artifact:deps -m fr.umlv.valuetype/fr.umlv.valuetype.ReifiedList Error: Unable to load main class fr.umlv.valuetype.ReifiedList in module fr.umlv.valuetype java.lang.ClassFormatError: Class modifier ACC_VALUE in class fr/umlv/valuetype/ReifiedList requires option -XX:+EnableValhalla thanks, R?mi ----- Mail original ----- > De: "Harold David Seigel" > ?: "Karen Kinnear" > Cc: "valhalla-dev" > Envoy?: Jeudi 28 Juin 2018 17:18:14 > Objet: Re: RFR: 8205998: [lworld] Verifier should reject value type classes if -XX:+EnableValhalla is not set > Thanks Karen! > > Harold > > > On 6/28/2018 11:17 AM, Karen Kinnear wrote: >> Harold, >> >> Looks good. Thank you for fixing the existing tests as well. >> >> thanks, >> Karen >> >>> On Jun 28, 2018, at 9:54 AM, Harold David Seigel >>> wrote: >>> >>> Hi, >>> >>> Please review this LWorld fix that throws a ClassFormatError exception if a >>> class is a value type class and -XX:+EnableValhalla is not set. >>> >>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8205998/webrev/index.html >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8205998 >>> >>> The fix was tested with tier1 and tier2 tests on Linux x64 and Macosx. >>> >>> Thanks, Harold From frederic.parain at oracle.com Thu Jun 28 20:24:39 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 28 Jun 2018 16:24:39 -0400 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> Message-ID: John, This is an emergency fix (Unsafe was not part of the plan for LW1, until we discovered VarHandles needed it), it focuses on robustness, not on performance. Looking longer term: 1 - retrieving all information for flattenable/flattened fields or value containers is expensive. I think there?s a clear consensus that new methods are required to efficiently support access to flattened/flattenable fields. But the LW1 date is fast approaching, so I?m not convinced that rushing these new APIs for LW1 is a good choice. 2 - deprecating U.getObject() and U.putObject(), for more precise methods makes sense, however deprecating is often a slow process in the Java world. An alternate solution would be to keep getObject() and putObject() while proposing the new alternative. It seems possible to restore almost all performance of getObject()/putObject() for the non value types cases (not part of the current patch, I wanted to push the fix ASAP to fix the current regressions). The trick is that objectFieldOffset() is not guaranteed to return a true offset, it could be some kind of a handle. It is possible to use three bits out of the 64bits of the offset to encode the information the JVM needs (flattened field/flattenable field/value container). Internally, Hotspot is already using 3 bits of the field offset metadata to encode some information. With a simple mask and test against zero, it would be very simple to detect that no value type is involved and the code could directly perform the legacy behavior. This would preserve the performance of GetObject()/putObject() for legacy code, the time for the code base to migrate to the new APIs, and make the support of value almost transparent for this code (except for performance). Once all codes have been migrated, getObject()/putObject() would be removed. This trick could also be applied to arrayBaseOffset() for the support of arrays. Fred > On Jun 27, 2018, at 18:22, John Rose wrote: > > On Jun 27, 2018, at 2:17 PM, Frederic Parain wrote: >> >> Please review this changeset which adds support for flattened values to the Unsafe API. >> >> http://cr.openjdk.java.net/~fparain/Unsafe/webrev.02/index.html >> >> This changeset addresses the following issues: >> - reading from /writing to a flattenable/flattened field with Unsafe >> - null-check when writing to a flattenable field >> - initialization barrier when reading an uninitialized static value field with Unsafe >> - enforcing values immutability even when using Unsafe >> - reading from /writing to a value array with Unsafe >> - null-check when writing to a value array with Unsafe >> >> Thanks, >> >> Fred > > Impressive work Fred; you have a nice way to doing the impossible. > > The existing version of U.putObject doesn't look at metadata, but clearly > the new version has to depend on metadata to see how the container is shaped. > > I see how this can work the way you did it, and why it's useful to unblock > prototyping. But it's not a design that I want to see made permanent. > > Container analysis is a delicate and potentially buggy operation which I am > surprised can be hidden safely under U.putObject. The basic contract of > Unsafe is to force the user to take responsibility for querying the container, > and issue the U.putX that matches the container. The benefit of this contract > is not only avoiding delicate and buggy operations inside Unsafe, but also > a simpler optimization model. > > So, I view this as a work-in-progress, which can unblock existing > code that uses Unsafe without requiring that code to be revamped. > > Later, the get/putObject APIs need to be split into versions which explicitly > manage references vs. flat values. Unsafe-using code that wants full > optimization will want to avoid get/putObject if it has this complicated > stuff going on under the hood. > > New API points are needed to let the user work explicitly with the > container shape: > > public Object getValue(Object o, long offset, Class valueType); > public void putValue(Object o, long offset, Class valueType, Object value); > public Object getReference(Object o, long offset); > public void putReference(Object o, long offset, Object reference); > > The get/putValue API points would load and store values of the given type > in their native format (flattened). If you knew a container wasn't flattened > although the type could be, you'd call putReference. > > We could also deprecate get/putObject so that users will be forced to > do the container analysis. An non-deprecated version of your container > analysis should have a more complex-sounding name, such as > getReferenceOrValue. Or we should just force users to write their > own; it's simple if the hooks are provided (see below). > > The valueType operand is there even when the value is also present, > for robustness. If we derive valueType from value automatically, the > user loses a channel for asserting the container analysis. You could > get heap-scribbling bugs when the value is of the wrong type. Oddly > enough, the Unsafe API has a concern with safety: You have to give > the user a reasonable chance to write safe code using Unsafe. > > I think we also want queries which can execute the logic you have written, > directly, and not in the course of reading or writing the heap. Something > like this would give unsafe users control over factoring the metadata > queries from the access itself: > > public Class objectFieldContainerType(Field f); > public Field findObjectField(Class objClass, long offset); > public Object getReferenceOrValue(Object o, long offset) { > Class ctype = objectFieldContainerType(findObjectField(o.getClass(), offset)); > if (ctype.isValue()) return getValue(o, offset, ctype); > else return getReference(o, offset); > } > > All that said, for the present review, it looks good as a work in progress. > > (If the benefit of overloading get/putObject is small, consider naming > this new logic with a new name like getReferenceOrValue. But I'm guessing > the overloading trick is a short-term requirement, to avoid cracking open > lots of platform code.) > > If we don't have another bug to track Unsafe support for container analysis > of flat fields, let's file one as a followup to this. > > ? John From frederic.parain at oracle.com Thu Jun 28 20:38:56 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 28 Jun 2018 16:38:56 -0400 Subject: RFR: Value types consistency checks Message-ID: <71EB54F5-FAA9-4A9F-AEF7-DC1E756DF7E0@oracle.com> Please review this changeset implementing consistency checks based on the ValueTypes attribute. These checks ensure that the assumptions a class has about value types, as encoded in its ValueTypes attribute, match the reality, or the assumptions of another class it links to. The details of the consistency checks have been summarized by Karen in this document: http://cr.openjdk.java.net/~acorn/value-types-consistency-checking-details.pdf If the implementation doesn?t match the document, this is likely to be bug, so please, report it. Some tests using the Bytecodes API have been updated to include a ValueTypes attribute in the class files they generate (thanks to Srikanth for adding this feature to the Bytecodes API). Webrev: http://cr.openjdk.java.net/~fparain/VTAttributeChecks/webrev.01/ Thank you, Fred From harold.seigel at oracle.com Thu Jun 28 20:50:28 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Thu, 28 Jun 2018 16:50:28 -0400 Subject: RFR: 8205998: [lworld] Verifier should reject value type classes if -XX:+EnableValhalla is not set In-Reply-To: <1741673184.1526637.1530216235385.JavaMail.zimbra@u-pem.fr> References: <4ad03616-189a-0493-17c9-c1992cb113ec@oracle.com> <186BE9D8-C17E-4223-807E-5C8E3A7C549F@oracle.com> <96d2d4f4-0936-0e38-2c6b-970ea1fab2d9@oracle.com> <1741673184.1526637.1530216235385.JavaMail.zimbra@u-pem.fr> Message-ID: <1a9e4e41-e1b1-0759-b22a-dc27fdbcaced@oracle.com> Thanks!? I'm glad it works. Harold On 6/28/2018 4:03 PM, Remi Forax wrote: > Works great :) > > /usr/jdk/jdk-11-lworld/bin/java --module-path target/test/artifact:deps -m fr.umlv.valuetype/fr.umlv.valuetype.ReifiedList > Error: Unable to load main class fr.umlv.valuetype.ReifiedList in module fr.umlv.valuetype > java.lang.ClassFormatError: Class modifier ACC_VALUE in class fr/umlv/valuetype/ReifiedList requires option -XX:+EnableValhalla > > thanks, > R?mi > > ----- Mail original ----- >> De: "Harold David Seigel" >> ?: "Karen Kinnear" >> Cc: "valhalla-dev" >> Envoy?: Jeudi 28 Juin 2018 17:18:14 >> Objet: Re: RFR: 8205998: [lworld] Verifier should reject value type classes if -XX:+EnableValhalla is not set >> Thanks Karen! >> >> Harold >> >> >> On 6/28/2018 11:17 AM, Karen Kinnear wrote: >>> Harold, >>> >>> Looks good. Thank you for fixing the existing tests as well. >>> >>> thanks, >>> Karen >>> >>>> On Jun 28, 2018, at 9:54 AM, Harold David Seigel >>>> wrote: >>>> >>>> Hi, >>>> >>>> Please review this LWorld fix that throws a ClassFormatError exception if a >>>> class is a value type class and -XX:+EnableValhalla is not set. >>>> >>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8205998/webrev/index.html >>>> >>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8205998 >>>> >>>> The fix was tested with tier1 and tier2 tests on Linux x64 and Macosx. >>>> >>>> Thanks, Harold From mandy.chung at oracle.com Thu Jun 28 21:03:42 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 28 Jun 2018 14:03:42 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> Message-ID: <808e8ffa-f283-6493-04e2-2229b3d1f858@oracle.com> On 6/27/18 4:54 PM, Paul Sandoz wrote: > Hi John, > > Those new API points you propose match closely with what i had in > mind, and i also agree that a set of query methods are important (I > was just scratching the surface of that). > > IMHO i think we can make a tentative split now and that would also > increase prototyping velocity without potentially destabilizing > existing unsafe usages. Mandy?s patch indicates the amount of Java > platform code changes are manageable for such a split and it can > allow for quicker experimentation with VarHandles. I am making further progress on the patch [1] to split the access to flattened fields with the new Unsafe API. It's still work in progress and I should be able to post something next week (if not this week). Mandy [1] http://cr.openjdk.java.net/~mchung/valhalla/webrevs/unsafe-flat-fields-webrev/ From john.r.rose at oracle.com Fri Jun 29 00:54:16 2018 From: john.r.rose at oracle.com (John Rose) Date: Thu, 28 Jun 2018 17:54:16 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <808e8ffa-f283-6493-04e2-2229b3d1f858@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> <808e8ffa-f283-6493-04e2-2229b3d1f858@oracle.com> Message-ID: On Jun 28, 2018, at 2:03 PM, mandy chung wrote: > > On 6/27/18 4:54 PM, Paul Sandoz wrote: >> Hi John, >> Those new API points you propose match closely with what i had in >> mind, and i also agree that a set of query methods are important (I >> was just scratching the surface of that). >> IMHO i think we can make a tentative split now and that would also >> increase prototyping velocity without potentially destabilizing >> existing unsafe usages. Mandy?s patch indicates the amount of Java >> platform code changes are manageable for such a split and it can >> allow for quicker experimentation with VarHandles. > > I am making further progress on the patch [1] to split the access to flattened fields with the new Unsafe API. It's still work in progress and I should be able to post something next week (if not this week). > > Mandy > [1] http://cr.openjdk.java.net/~mchung/valhalla/webrevs/unsafe-flat-fields-webrev/ I read this patch and I like what you are doing; thanks for pushing on this problem. I guess the underlying theory is that any object field whose type is a value type can be flattened, but the decision to flatten must be queried for the metadata *for that field*. The query returns a boolean: If false, the field is formatted as a regular oop pointer (though there might be a restriction against nulls on it). If true, then the field is formatted in a layout which is permanently assigned to the value type. Two flattened fields of the same value type *always* have the same layout; thus, flattened fields have no variance or polymorphism. This allows you to statically query whether a given field is flattened, and thereafter just use the value type (Class mirror) to control how the field is correctly accessed. This all makes sense to me, and we want to be clear that this is how we are going to do things. For example, we won't pack two value type fields in one container by mixing their fields together according to alignment restrictions, even though that would pack the containing object tighter in memory. I have ideas how to do this in the long run, but it would complicate the logic for U.getValue. Once a field (with its base offset) has been determined to be a flat value, then loading or storing it is a fixed procedure to copy into TLVB or out of TLVB/HB, which the JIT can easily "see through" and optimize down to individual memory operations. There will be one such procedure for each U.get/put operation. Maybe {get,put} x {normal,volatile,acquire, release,opaque}. In addition to teaching the JIT how to optimize those, I wonder if we will want to make them into quasi-virtual methods on java.lang.Class or ValueKlass, and call them out-of-line from codes which cannot determine the value type Class as a JIT-time constant. Probably not, but it's interesting to imagine this protocol, a sort of type-dependent access API for flattened fields. In your code, the extra check in unsafe.cpp (check_putfield_access) seems to promise that the unsafe access is taking responsibility for preventing certain mismatched accesses. The more "unsafe-y" way to handle this is to require the caller of the access to perform the check. In this way the primitive can do the simplest possible thing, even if that would crash the VM if the access is mismatched. This reasoning applies to almost every path you might find in unsafe.cpp which throws an exception. It doesn't apply to "large scale" ops like loadClass or allocateMemory, but it does apply to every op we hope the JIT will optimize as an intrinsic. As a service to the user we can sometimes make simple checks in unsafe.cpp, but if we put complicated ones in, then we are putting the optimizations at risk, since the JIT will then have the burden to reproduce the complicated checks. Making the unsafe.cpp code using the 'guarantee' macro is less friendly to the user, but more honest than throwing an exception that the JIT won't be able to produce. Dealing with the layers of required checking will be easier, I think, if we put most or all of the checks (for flattening, for value type mismatches, etc.) in Java code. So if we *do* decide that getObject should have a special value-type check (as a service to the user, even though the user should drive more carefully) then that check would be better reified as a subroutine method call inside a Java-coded version of U.getObject, rather than hardwired C++ code in unsafe.cpp. In that case, the logic of the Java-coded check can itself be made into an intrinsic, so the JIT can separately optimize it. ? John From john.r.rose at oracle.com Fri Jun 29 01:12:45 2018 From: john.r.rose at oracle.com (John Rose) Date: Thu, 28 Jun 2018 18:12:45 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> Message-ID: <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> On Jun 28, 2018, at 1:24 PM, Frederic Parain wrote: > > John, > > This is an emergency fix (Unsafe was not part of the plan for LW1, until > we discovered VarHandles needed it), it focuses on robustness, not on > performance. Yes, I guessed that! > Looking longer term: > > 1 - retrieving all information for flattenable/flattened fields or value > containers is expensive. I think there?s a clear consensus that > new methods are required to efficiently support access to > flattened/flattenable fields. But the LW1 date is fast approaching, > so I?m not convinced that rushing these new APIs for LW1 is a good > choice. No, probably not, unless your technique causes a serious problem with performance. But I think the JIT folks are avoiding the unsafe.cpp code successfully, so we're good. > > 2 - deprecating U.getObject() and U.putObject(), for more precise > methods makes sense, however deprecating is often a slow process > in the Java world. An alternate solution would be to keep getObject() > and putObject() while proposing the new alternative. It seems possible > to restore almost all performance of getObject()/putObject() for the > non value types cases (not part of the current patch, I wanted to > push the fix ASAP to fix the current regressions). The trick is that > objectFieldOffset() is not guaranteed to return a true offset, it could > be some kind of a handle. It is possible to use three bits out of the > 64bits of the offset to encode the information the JVM needs > (flattened field/flattenable field/value container). Internally, Hotspot > is already using 3 bits of the field offset metadata to encode some > information. With a simple mask and test against zero, it would be > very simple to detect that no value type is involved and the code > could directly perform the legacy behavior. Yes, the oFO could be given tag bits. Some clients of Unsafe may do arithmetic on these offsets, so the tagged offsets might have to be made resistant to arithmetic mistakes. Probably this means the tags would want to be placed high in the oFO word. Of course clients who perform arithmetic on those are taking risks, and should check for tags anyway. As I said to Mandy, I think any such test should be reified in Java code, rather than burned into unsafe.cpp and the JIT. If it is burned in, it becomes invisible and harder (for both clients and JVM) to optimize. If we decide to go the route you are saying, the legacy getObject should become a Java-coded method which clearly decomposes into the steps you are describing. Then it will be a simpler matter for clients and for the JIT to refactor their usages to avoid the branches. Today's getObject calls usually compile down to single memory references; adding even a simple tag check and branch to the base semantics risks adding a proportionately large overhead. Reifying the extra check at the Java level gives control back to the programmer. > This would preserve the performance of GetObject()/putObject() > for legacy code, the time for the code base to migrate to the > new APIs, and make the support of value almost transparent > for this code (except for performance). > Once all codes have been migrated, getObject()/putObject() would > be removed. Or it could be left as-is. Given a Java-coded body, it would be clear to users what are the pros and cons of using it or refactoring to use its parts. I guess I buy this trajectory. The stripped-down version of getObject (the thing that getObject calls after making a safety check) should be called getReference (or getOop or getPointer, but reference is the proper JVM-level term). The semantics of getReference would be more "hard line unsafe-y" in that if you accidentally passed it the offset of a flattened field, it would just crash rather than detect the error and try to make it nicer for you. I think we could do all of this migration without tag bits. Instead of tag bits, the transitional getObject would do the expensive metadata lookup you are adding into unsafe.cpp (using a Java API, not hardwired C++ code). It would be slow, but everybody would know what to do about it. Adding the tag bits would make that slow path a little faster, but at the cost of making offsets (oFO results) less scrutable. > This trick could also be applied to arrayBaseOffset() for the support > of arrays. Yep. There's even a documented sentinel value (-1) which is a sort of prototype for an offset-that-is-not-a-real-offset. But we've never been able (so far) to make really good use of that option. Thanks! ? John From john.r.rose at oracle.com Fri Jun 29 01:25:38 2018 From: john.r.rose at oracle.com (John Rose) Date: Thu, 28 Jun 2018 18:25:38 -0700 Subject: [lworld] RFR(M): Cleanup of null checks In-Reply-To: <4275c4dc-1b97-1330-db47-c1ad0b8d298a@oracle.com> References: <4275c4dc-1b97-1330-db47-c1ad0b8d298a@oracle.com> Message-ID: <5CD10DE7-0FDE-484A-A1C0-82C0EEDA9DF5@oracle.com> Reviewed. This is really good; all those deleted lines are the sign of a successful refactoring. I have one suggestion: After the refactoring make_from_oop now has full responsibility for null checks. The boolean parameter 'flattened' now means "map null to default"; if it is false, then a null triggers deopt which (I assume) eventually gets to an NPE. My suggestion is to rename flattened to null2default or map_null_to_default or default_on_null. This will make the division of responsibility clearer between make_from_oop and its users. The general meaning of and policy concerning "flattened" values is in flux, and a more specific name for this argument will make sure it won't become incomprehensible in the future. ? John On Jun 28, 2018, at 7:56 AM, Tobias Hartmann wrote: > > Hi, > > please review the following patch: > http://cr.openjdk.java.net/~thartmann/valhalla/lworld/null_check_cleanup/ > > Changes: > - Moved all null checks into ValueTypeNode::make_from_oop(). We are now emitting null checks if the > oop can be null > - Added asserts at the call sites to verify that we never emit null checks where it's not required > - Fixed a problem with OSR where a null value type is accessed without a null check (see new test in > TestOnStackReplacement.java) > - Some refactoring and comment cleanups > > All compiler and runtime tests pass. > > Thanks, > Tobias From mandy.chung at oracle.com Fri Jun 29 03:26:40 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 28 Jun 2018 20:26:40 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> <808e8ffa-f283-6493-04e2-2229b3d1f858@oracle.com> Message-ID: On 6/28/18 5:54 PM, John Rose wrote: > I read this patch and I like what you are doing; thanks for pushing on this problem. > > I guess the underlying theory is that any object field whose type is > a value type can be flattened, but the decision to flatten must be > queried for the metadata *for that field*. The query returns a > boolean: If false, the field is formatted as a regular oop pointer > (though there might be a restriction against nulls on it). If true, > then the field is formatted in a layout which is permanently > assigned to the value type. Two flattened fields of the same value > type *always* have the same layout; thus, flattened fields have no > variance or polymorphism. Yes that's the underlying theory from my understanding of the current implementation. Frederic and Karen can double confirm. > This allows you to statically query whether a given field is > flattened, and thereafter just use the value type (Class mirror) to > control how the field is correctly accessed. This all makes sense to > me, and we want to be clear that this is how we are going to do > things. For example, we won't pack two value type fields in one > container by mixing their fields together according to alignment > restrictions, even though that would pack the containing object > tighter in memory. I have ideas how to do this in the long run, but > it would complicate the logic for U.getValue. Frederic - does that align with what you are thinking? > Once a field (with its base offset) has been determined to be a flat > value, then loading or storing it is a fixed procedure to copy into > TLVB or out of TLVB/HB, which the JIT can easily "see through" and > optimize down to individual memory operations. There will be one > such procedure for each U.get/put operation. Maybe {get,put} x > {normal,volatile,acquire, release,opaque}. In addition to teaching > the JIT how to optimize those, I wonder if we will want to make them > into quasi-virtual methods on java.lang.Class or ValueKlass, and call > them out-of-line from codes which cannot determine the value type > Class as a JIT-time constant. Probably not, but it's interesting to > imagine this protocol, a sort of type-dependent access API for > flattened fields. > > In your code, the extra check in unsafe.cpp (check_putfield_access) > seems to promise that the unsafe access is taking responsibility for > preventing certain mismatched accesses. The more "unsafe-y" way to > handle this is to require the caller of the access to perform the > check. In this way the primitive can do the simplest possible thing, > even if that would crash the VM if the access is mismatched. Thanks. Paul also pointed that out. > This reasoning applies to almost every path you might find in > unsafe.cpp which throws an exception. It doesn't apply to "large > scale" ops like loadClass or allocateMemory, but it does apply to > every op we hope the JIT will optimize as an intrinsic. > > As a service to the user we can sometimes make simple checks in > unsafe.cpp, but if we put complicated ones in, then we are putting > the optimizations at risk, since the JIT will then have the burden to > reproduce the complicated checks. > > Making the unsafe.cpp code using the 'guarantee' macro is less > friendly to the user, but more honest than throwing an exception that > the JIT won't be able to produce. > > Dealing with the layers of required checking will be easier, I think, > if we put most or all of the checks (for flattening, for value type > mismatches, etc.) in Java code. So if we *do* decide that getObject > should have a special value-type check (as a service to the user, > even though the user should drive more carefully) then that check > would be better reified as a subroutine method call inside a > Java-coded version of U.getObject, rather than hardwired C++ code in > unsafe.cpp. In that case, the logic of the Java-coded check can > itself be made into an intrinsic, so the JIT can separately optimize > it. Thanks for this. I'll move the extra check in unsafe to Java code where appropriate. Status update: I have got the MethodHandle, VarHandle, core reflection working with flattened fields (webrev [1] updated in place). Array access via VarHandles would need more investigation. Mandy [1] http://cr.openjdk.java.net/~mchung/valhalla/webrevs/unsafe-flat-fields-webrev/ From mandy.chung at oracle.com Fri Jun 29 04:47:20 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 28 Jun 2018 21:47:20 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> <808e8ffa-f283-6493-04e2-2229b3d1f858@oracle.com> Message-ID: <644d5e62-372b-afef-9426-65c2ce8d4cc5@oracle.com> This patch introduces Unsafe::getValue and Unsafe::putValue API. http://cr.openjdk.java.net/~mchung/valhalla/webrevs/unsafe-flat-fields-webrev/ A flattenable object field can be flattened. The decision to flatten an object field is made at class loading time in this implementation When an object field is accessed, we will query if the field is flattened or not. java.lang.reflect.Field and java.lang.invoke.MemberName are extended to indicate if it's flattened. A new MethodHandleTest and existing tests are updated to test value type and non-value type containing flat fields via MethodHandle, VarHandle, and core reflection. It also tests direct method handle of array element getter and setters. VarHandle support for value arrays depend on JDK-8205698. I will look into this next. - ValueFieldInstanceReadWrite and ValueFieldInstanceReadOnly are added specially for flat field. The implementation does not flatten static fields and hence I decide not to add unused ValueFieldStaticXXX class. I left the other VarHandle operations such as compareAndSet as is and look at them again. - I removed check_putfield_access in unsafe.cpp and move the check of non-null value to put on a flat field to java. We will go through over places that does not allow setting value field to null, as a separate task. - I keep the assert and logging in Unsafe_GetValue and Unsafe_PutValue for diagnosis. I will remove it when we add the VarHandle support for value arrays. I quite like this patch coming along. Thanks Mandy From tobias.hartmann at oracle.com Fri Jun 29 09:36:41 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Jun 2018 11:36:41 +0200 Subject: [lworld] RFR(M): Cleanup of null checks In-Reply-To: <5CD10DE7-0FDE-484A-A1C0-82C0EEDA9DF5@oracle.com> References: <4275c4dc-1b97-1330-db47-c1ad0b8d298a@oracle.com> <5CD10DE7-0FDE-484A-A1C0-82C0EEDA9DF5@oracle.com> Message-ID: Hi John, On 29.06.2018 03:25, John Rose wrote: > Reviewed. This is really good; all those deleted lines are the > sign of a successful refactoring. Thanks for looking at this! > I have one suggestion: After the refactoring make_from_oop now has > full responsibility for null checks. The boolean parameter 'flattened' > now means "map null to default"; if it is false, then a null triggers deopt > which (I assume) eventually gets to an NPE.> My suggestion is to rename flattened to null2default or map_null_to_default > or default_on_null. This will make the division of responsibility clearer between > make_from_oop and its users. The general meaning of and policy concerning > "flattened" values is in flux, and a more specific name for this argument will make > sure it won't become incomprehensible in the future. That's a good suggestion, I will change the name before pushing. Thanks, Tobias From tobias.hartmann at oracle.com Fri Jun 29 09:42:17 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Fri, 29 Jun 2018 09:42:17 +0000 Subject: hg: valhalla/valhalla: [lworld] Cleanup of null checks Message-ID: <201806290942.w5T9gHWk011907@aojmv0008.oracle.com> Changeset: 52a1a2a4ddb6 Author: thartmann Date: 2018-06-29 11:41 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/52a1a2a4ddb6 [lworld] Cleanup of null checks Reviewed-by: jrose ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/doCall.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/parse3.cpp ! src/hotspot/share/opto/valuetypenode.cpp ! src/hotspot/share/opto/valuetypenode.hpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestOnStackReplacement.java From tobias.hartmann at oracle.com Fri Jun 29 09:51:04 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Fri, 29 Jun 2018 09:51:04 +0000 Subject: hg: valhalla/valhalla: [lworld] Fixed SIGILL caused by incorrect patch for 8205340 and renamed 'flattenable' parameter. Message-ID: <201806290951.w5T9p4Wf014392@aojmv0008.oracle.com> Changeset: 000bb8a4bb16 Author: thartmann Date: 2018-06-29 11:50 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/000bb8a4bb16 [lworld] Fixed SIGILL caused by incorrect patch for 8205340 and renamed 'flattenable' parameter. ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/doCall.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/parse3.cpp ! src/hotspot/share/opto/valuetypenode.cpp ! src/hotspot/share/opto/valuetypenode.hpp From tobias.hartmann at oracle.com Fri Jun 29 11:46:26 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Fri, 29 Jun 2018 11:46:26 +0000 Subject: hg: valhalla/valhalla: 8205944: [lworld] hotspot TestArrays.java test fails when -XX:CompileThreshold=100 is specified Message-ID: <201806291146.w5TBkRUi018170@aojmv0008.oracle.com> Changeset: 0faf027984f3 Author: thartmann Date: 2018-06-29 13:45 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0faf027984f3 8205944: [lworld] hotspot TestArrays.java test fails when -XX:CompileThreshold=100 is specified ! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java From tobias.hartmann at oracle.com Fri Jun 29 12:25:37 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Fri, 29 Jun 2018 12:25:37 +0000 Subject: hg: valhalla/valhalla: 8206110: [lworld] TestIntrinsics fails with 'Not a Java pointer' with -Xcomp Message-ID: <201806291225.w5TCPcLT029854@aojmv0008.oracle.com> Changeset: b9d1c33c2a0f Author: thartmann Date: 2018-06-29 14:25 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b9d1c33c2a0f 8206110: [lworld] TestIntrinsics fails with 'Not a Java pointer' with -Xcomp ! src/hotspot/share/opto/library_call.cpp From tobias.hartmann at oracle.com Fri Jun 29 12:27:36 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Jun 2018 14:27:36 +0200 Subject: hg: valhalla/valhalla: 8206110: [lworld] TestIntrinsics fails with 'Not a Java pointer' with -Xcomp In-Reply-To: <201806291225.w5TCPcLT029854@aojmv0008.oracle.com> References: <201806291225.w5TCPcLT029854@aojmv0008.oracle.com> Message-ID: The problem was that 'obj' can be constant NULL, we should only check the type with is_oopptr() after null checking. Best regards, Tobias On 29.06.2018 14:25, tobias.hartmann at oracle.com wrote: > Changeset: b9d1c33c2a0f > Author: thartmann > Date: 2018-06-29 14:25 +0200 > URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/b9d1c33c2a0f > > 8206110: [lworld] TestIntrinsics fails with 'Not a Java pointer' with -Xcomp > > ! src/hotspot/share/opto/library_call.cpp > From tobias.hartmann at oracle.com Fri Jun 29 14:03:43 2018 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Fri, 29 Jun 2018 14:03:43 +0000 Subject: hg: valhalla/valhalla: 8206109: [lworld] TestLWorld crashes in ciInstanceKlass::get_field_by_offset() with -Xcomp Message-ID: <201806291403.w5TE3igh000516@aojmv0008.oracle.com> Changeset: 186c0c79f03f Author: thartmann Date: 2018-06-29 15:59 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/186c0c79f03f 8206109: [lworld] TestLWorld crashes in ciInstanceKlass::get_field_by_offset() with -Xcomp ! src/hotspot/share/opto/valuetypenode.cpp From tobias.hartmann at oracle.com Fri Jun 29 14:09:26 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Jun 2018 16:09:26 +0200 Subject: hg: valhalla/valhalla: 8206109: [lworld] TestLWorld crashes in ciInstanceKlass::get_field_by_offset() with -Xcomp In-Reply-To: <201806291403.w5TE3igh000516@aojmv0008.oracle.com> References: <201806291403.w5TE3igh000516@aojmv0008.oracle.com> Message-ID: <8f6850fe-fe63-2a1c-f539-dfed13fa0781@oracle.com> The problem is that we read a value type element from a constant array oop and assume that the value type is constant as well (we crash because "holder" is NULL). We should filter out array oops. Best regards, Tobias On 29.06.2018 16:03, tobias.hartmann at oracle.com wrote: > Changeset: 186c0c79f03f > Author: thartmann > Date: 2018-06-29 15:59 +0200 > URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/186c0c79f03f > > 8206109: [lworld] TestLWorld crashes in ciInstanceKlass::get_field_by_offset() with -Xcomp > > ! src/hotspot/share/opto/valuetypenode.cpp > From frederic.parain at oracle.com Fri Jun 29 14:14:26 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 29 Jun 2018 10:14:26 -0400 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> Message-ID: <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> > On Jun 28, 2018, at 21:12, John Rose wrote: > > On Jun 28, 2018, at 1:24 PM, Frederic Parain wrote: >> >> John, >> >> This is an emergency fix (Unsafe was not part of the plan for LW1, until >> we discovered VarHandles needed it), it focuses on robustness, not on >> performance. > > Yes, I guessed that! > >> Looking longer term: >> >> 1 - retrieving all information for flattenable/flattened fields or value >> containers is expensive. I think there?s a clear consensus that >> new methods are required to efficiently support access to >> flattened/flattenable fields. But the LW1 date is fast approaching, >> so I?m not convinced that rushing these new APIs for LW1 is a good >> choice. > > No, probably not, unless your technique causes a serious problem with > performance. But I think the JIT folks are avoiding the unsafe.cpp code > successfully, so we're good. > >> >> 2 - deprecating U.getObject() and U.putObject(), for more precise >> methods makes sense, however deprecating is often a slow process >> in the Java world. An alternate solution would be to keep getObject() >> and putObject() while proposing the new alternative. It seems possible >> to restore almost all performance of getObject()/putObject() for the >> non value types cases (not part of the current patch, I wanted to >> push the fix ASAP to fix the current regressions). The trick is that >> objectFieldOffset() is not guaranteed to return a true offset, it could >> be some kind of a handle. It is possible to use three bits out of the >> 64bits of the offset to encode the information the JVM needs >> (flattened field/flattenable field/value container). Internally, Hotspot >> is already using 3 bits of the field offset metadata to encode some >> information. With a simple mask and test against zero, it would be >> very simple to detect that no value type is involved and the code >> could directly perform the legacy behavior. > > Yes, the oFO could be given tag bits. Some clients of Unsafe may do > arithmetic on these offsets, so the tagged offsets might have to be > made resistant to arithmetic mistakes. Probably this means the > tags would want to be placed high in the oFO word. Of course clients > who perform arithmetic on those are taking risks, and should check > for tags anyway. > > As I said to Mandy, I think any such test should be reified in Java > code, rather than burned into unsafe.cpp and the JIT. If it is burned > in, it becomes invisible and harder (for both clients and JVM) to optimize. > > If we decide to go the route you are saying, the legacy getObject should > become a Java-coded method which clearly decomposes into the steps > you are describing. Then it will be a simpler matter for clients and for > the JIT to refactor their usages to avoid the branches. Today's getObject > calls usually compile down to single memory references; adding even > a simple tag check and branch to the base semantics risks adding > a proportionately large overhead. Reifying the extra check at the > Java level gives control back to the programmer. It seems my plan was not explicit enough. I was suggesting considering getObject()/putObject() as doomed, because they are not aware that flattened fields and values exist, so the JVM has to do all the hard work under the hood. Mandy is making good progress on getValue()/putValue() to provide efficient access to values. We should also have methods getRefObject()/putRefObject(), working as getObject()/putObject() work today, assuming that the caller has checked that no values were involved. These methods are the ones that will optimized to a single memory reference by the JIT. The legacy getObject()/putObject() would be maintained with value types support just the time to allow a smooth transition. Fred > >> This would preserve the performance of GetObject()/putObject() >> for legacy code, the time for the code base to migrate to the >> new APIs, and make the support of value almost transparent >> for this code (except for performance). >> Once all codes have been migrated, getObject()/putObject() would >> be removed. > > Or it could be left as-is. Given a Java-coded body, it would be clear > to users what are the pros and cons of using it or refactoring to use > its parts. > > I guess I buy this trajectory. The stripped-down version of getObject > (the thing that getObject calls after making a safety check) should be > called getReference (or getOop or getPointer, but reference is the > proper JVM-level term). The semantics of getReference would be > more "hard line unsafe-y" in that if you accidentally passed it the > offset of a flattened field, it would just crash rather than detect the > error and try to make it nicer for you. > > I think we could do all of this migration without tag bits. Instead > of tag bits, the transitional getObject would do the expensive metadata > lookup you are adding into unsafe.cpp (using a Java API, not hardwired > C++ code). It would be slow, but everybody would know what to do > about it. Adding the tag bits would make that slow path a little faster, > but at the cost of making offsets (oFO results) less scrutable. > >> This trick could also be applied to arrayBaseOffset() for the support >> of arrays. > > Yep. There's even a documented sentinel value (-1) which is a sort > of prototype for an offset-that-is-not-a-real-offset. But we've never > been able (so far) to make really good use of that option. > > Thanks! > > ? John From paul.sandoz at oracle.com Fri Jun 29 16:23:12 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 29 Jun 2018 09:23:12 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <644d5e62-372b-afef-9426-65c2ce8d4cc5@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> <808e8ffa-f283-6493-04e2-2229b3d1f858@oracle.com> <644d5e62-372b-afef-9426-65c2ce8d4cc5@oracle.com> Message-ID: <80808535-AB5D-44A4-AC5A-54E237BE564F@oracle.com> View nice! Comments for further iteration perhaps after committing: - You may want to follow the same pattern for getType as for fieldOffset i.e. use a static method rather than a virtual method. - We can remove the atomic add and bitwise ops from ValueFieldInstanceReadWrite. - The Unsafe atomic accessors ValueVolatile/Acquire/Release/Opaque can use a global lock for the moment to ensure atomicity and ordering, the acquire/release can defer to the volatile accessors. Adding the others is also straightforward (weaker CAS and CAE can defer to the volatile CAS/CAE methods). Happy to help with any of this with following patches. Paul. > On Jun 28, 2018, at 9:47 PM, mandy chung wrote: > > This patch introduces Unsafe::getValue and Unsafe::putValue API. > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/unsafe-flat-fields-webrev/ > > A flattenable object field can be flattened. The decision to flatten > an object field is made at class loading time in this implementation > When an object field is accessed, we will query if the field is > flattened or not. java.lang.reflect.Field and java.lang.invoke.MemberName > are extended to indicate if it's flattened. > > A new MethodHandleTest and existing tests are updated to test value > type and non-value type containing flat fields via MethodHandle, > VarHandle, and core reflection. It also tests direct method handle > of array element getter and setters. VarHandle support for value > arrays depend on JDK-8205698. I will look into this next. > > - ValueFieldInstanceReadWrite and ValueFieldInstanceReadOnly are added > specially for flat field. The implementation does not flatten static > fields and hence I decide not to add unused ValueFieldStaticXXX class. > I left the other VarHandle operations such as compareAndSet as is and > look at them again. > > - I removed check_putfield_access in unsafe.cpp and move the check of > non-null value to put on a flat field to java. We will go through > over places that does not allow setting value field to null, as a > separate task. > > - I keep the assert and logging in Unsafe_GetValue and Unsafe_PutValue > for diagnosis. I will remove it when we add the VarHandle support for > value arrays. > > I quite like this patch coming along. > > Thanks > Mandy From paul.sandoz at oracle.com Fri Jun 29 16:35:09 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 29 Jun 2018 09:35:09 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> Message-ID: <9B7BB622-42EB-473D-849D-93F9AECB36AC@oracle.com> > On Jun 29, 2018, at 7:14 AM, Frederic Parain wrote: > > The legacy getObject()/putObject() would be maintained with value > types support just the time to allow a smooth transition. > IMHO i think these should be left as is. Various external (and of course unsupported!) usages of Unsafe do all sorts of crazy things and there is a risk those usages could be perturbed, either due to performance or because the new code infers something incorrectly. I would like to suggest an alternative if this is a major concern. Modify the sun.misc.Unsafe implementation in the unsupported module and add asserts to the Java implementations to fail if it is detected value types are used. Then document the restrictions. Paul. From forax at univ-mlv.fr Fri Jun 29 16:36:09 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 29 Jun 2018 18:36:09 +0200 (CEST) Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> Message-ID: <920952507.1865460.1530290169628.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Frederic Parain" > ?: "John Rose" > Cc: "valhalla-dev" > Envoy?: Vendredi 29 Juin 2018 16:14:26 > Objet: Re: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe >> On Jun 28, 2018, at 21:12, John Rose wrote: >> >> On Jun 28, 2018, at 1:24 PM, Frederic Parain wrote: >>> >>> John, >>> >>> This is an emergency fix (Unsafe was not part of the plan for LW1, until >>> we discovered VarHandles needed it), it focuses on robustness, not on >>> performance. >> >> Yes, I guessed that! >> >>> Looking longer term: >>> >>> 1 - retrieving all information for flattenable/flattened fields or value >>> containers is expensive. I think there?s a clear consensus that >>> new methods are required to efficiently support access to >>> flattened/flattenable fields. But the LW1 date is fast approaching, >>> so I?m not convinced that rushing these new APIs for LW1 is a good >>> choice. >> >> No, probably not, unless your technique causes a serious problem with >> performance. But I think the JIT folks are avoiding the unsafe.cpp code >> successfully, so we're good. >> >>> >>> 2 - deprecating U.getObject() and U.putObject(), for more precise >>> methods makes sense, however deprecating is often a slow process >>> in the Java world. An alternate solution would be to keep getObject() >>> and putObject() while proposing the new alternative. It seems possible >>> to restore almost all performance of getObject()/putObject() for the >>> non value types cases (not part of the current patch, I wanted to >>> push the fix ASAP to fix the current regressions). The trick is that >>> objectFieldOffset() is not guaranteed to return a true offset, it could >>> be some kind of a handle. It is possible to use three bits out of the >>> 64bits of the offset to encode the information the JVM needs >>> (flattened field/flattenable field/value container). Internally, Hotspot >>> is already using 3 bits of the field offset metadata to encode some >>> information. With a simple mask and test against zero, it would be >>> very simple to detect that no value type is involved and the code >>> could directly perform the legacy behavior. >> >> Yes, the oFO could be given tag bits. Some clients of Unsafe may do >> arithmetic on these offsets, so the tagged offsets might have to be >> made resistant to arithmetic mistakes. Probably this means the >> tags would want to be placed high in the oFO word. Of course clients >> who perform arithmetic on those are taking risks, and should check >> for tags anyway. >> >> As I said to Mandy, I think any such test should be reified in Java >> code, rather than burned into unsafe.cpp and the JIT. If it is burned >> in, it becomes invisible and harder (for both clients and JVM) to optimize. >> >> If we decide to go the route you are saying, the legacy getObject should >> become a Java-coded method which clearly decomposes into the steps >> you are describing. Then it will be a simpler matter for clients and for >> the JIT to refactor their usages to avoid the branches. Today's getObject >> calls usually compile down to single memory references; adding even >> a simple tag check and branch to the base semantics risks adding >> a proportionately large overhead. Reifying the extra check at the >> Java level gives control back to the programmer. > > It seems my plan was not explicit enough. > I was suggesting considering getObject()/putObject() as doomed, > because they are not aware that flattened fields and values exist, > so the JVM has to do all the hard work under the hood. > > Mandy is making good progress on getValue()/putValue() to provide > efficient access to values. > > We should also have methods getRefObject()/putRefObject(), > working as getObject()/putObject() work today, assuming that the > caller has checked that no values were involved. These methods > are the ones that will optimized to a single memory reference by the JIT. > > The legacy getObject()/putObject() would be maintained with value > types support just the time to allow a smooth transition. > > Fred Hi Fred, given that there are now two Unsafes, we can offer a getObject (resp putObject) that delegates to getRefObject or getValue only in sun.misc.Unsafe to maintain backward compatibility while removing getObject/putObject from jdk.internal.misc.Unsafe. R?mi > > >> >>> This would preserve the performance of GetObject()/putObject() >>> for legacy code, the time for the code base to migrate to the >>> new APIs, and make the support of value almost transparent >>> for this code (except for performance). >>> Once all codes have been migrated, getObject()/putObject() would >>> be removed. >> >> Or it could be left as-is. Given a Java-coded body, it would be clear >> to users what are the pros and cons of using it or refactoring to use >> its parts. >> >> I guess I buy this trajectory. The stripped-down version of getObject >> (the thing that getObject calls after making a safety check) should be >> called getReference (or getOop or getPointer, but reference is the >> proper JVM-level term). The semantics of getReference would be >> more "hard line unsafe-y" in that if you accidentally passed it the >> offset of a flattened field, it would just crash rather than detect the >> error and try to make it nicer for you. >> >> I think we could do all of this migration without tag bits. Instead >> of tag bits, the transitional getObject would do the expensive metadata >> lookup you are adding into unsafe.cpp (using a Java API, not hardwired >> C++ code). It would be slow, but everybody would know what to do >> about it. Adding the tag bits would make that slow path a little faster, >> but at the cost of making offsets (oFO results) less scrutable. >> >>> This trick could also be applied to arrayBaseOffset() for the support >>> of arrays. >> >> Yep. There's even a documented sentinel value (-1) which is a sort >> of prototype for an offset-that-is-not-a-real-offset. But we've never >> been able (so far) to make really good use of that option. >> >> Thanks! >> > > ? John From mandy.chung at oracle.com Fri Jun 29 18:58:51 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 29 Jun 2018 11:58:51 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <80808535-AB5D-44A4-AC5A-54E237BE564F@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> <808e8ffa-f283-6493-04e2-2229b3d1f858@oracle.com> <644d5e62-372b-afef-9426-65c2ce8d4cc5@oracle.com> <80808535-AB5D-44A4-AC5A-54E237BE564F@oracle.com> Message-ID: On 6/29/18 9:23 AM, Paul Sandoz wrote: > View nice! > > Comments for further iteration perhaps after committing: > > - You may want to follow the same pattern for getType as for > fieldOffset i.e. use a static method rather than a virtual method. I added static fieldValueType for Accessor and staticFieldValueType for StaticAccessor that might help the performance (no data). I am in two mind if I should prepare the static field case as hotspot does not flatten static field. For now, I keep it there and should revisit it at some point. > - We can remove the atomic add and bitwise ops from > ValueFieldInstanceReadWrite. Good catch. I took that out. > - The Unsafe atomic accessors ValueVolatile/Acquire/Release/Opaque > can use a global lock for the moment to ensure atomicity and > ordering, the acquire/release can defer to the volatile accessors. > Adding the others is also straightforward (weaker CAS and CAE can > defer to the volatile CAS/CAE methods). > > Happy to help with any of this with following patches. Thanks. I wanted to look at volatile/acquire/release/opaque and other ops separately and will definitely ask your help. So no lock at the moment and hope it's okay. Revised webrev: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/unsafe-flat-fields-webrev.01/ Mandy From mandy.chung at oracle.com Fri Jun 29 19:19:20 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 29 Jun 2018 12:19:20 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> <808e8ffa-f283-6493-04e2-2229b3d1f858@oracle.com> <644d5e62-372b-afef-9426-65c2ce8d4cc5@oracle.com> <80808535-AB5D-44A4-AC5A-54E237BE564F@oracle.com> Message-ID: <8d71b69e-7212-c12d-5f3d-eff6f099e7f4@oracle.com> On 6/29/18 11:58 AM, mandy chung wrote: > Revised webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/unsafe-flat-fields-webrev.01/ Thinking it again, I went with the global lock suggestion. ValueAcquire/Release/Opaque accessor method calls the ValueVolatile method which acquire the lock. I also changed the static fieldValueType/staticFieldValueType to access the final `fieldType` field directly. Webrev updated in place. Mandy From paul.sandoz at oracle.com Fri Jun 29 19:23:14 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 29 Jun 2018 12:23:14 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <8d71b69e-7212-c12d-5f3d-eff6f099e7f4@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> <808e8ffa-f283-6493-04e2-2229b3d1f858@oracle.com> <644d5e62-372b-afef-9426-65c2ce8d4cc5@oracle.com> <80808535-AB5D-44A4-AC5A-54E237BE564F@oracle.com> <8d71b69e-7212-c12d-5f3d-eff6f099e7f4@oracle.com> Message-ID: +1 this looks very good to me. Assuming others are ok too i think this is good to push. You can probably remove the DirectMethodHandle getType methods if you wish. Paul. > On Jun 29, 2018, at 12:19 PM, mandy chung wrote: > > On 6/29/18 11:58 AM, mandy chung wrote: >> Revised webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/unsafe-flat-fields-webrev.01/ > > Thinking it again, I went with the global lock suggestion. > > ValueAcquire/Release/Opaque accessor method calls the ValueVolatile > method which acquire the lock. > > I also changed the static fieldValueType/staticFieldValueType to > access the final `fieldType` field directly. > > Webrev updated in place. > > Mandy From frederic.parain at oracle.com Fri Jun 29 19:31:21 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 29 Jun 2018 15:31:21 -0400 Subject: Empty value type ? In-Reply-To: References: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> <783083966.669860.1530019680824.JavaMail.zimbra@u-pem.fr> <548A46F3-5DF7-4674-A374-5E9DDF0C4C09@gmail.com> Message-ID: <2F97DE9B-80EA-4E10-BE1C-E2924F57DC19@oracle.com> I?d be cautious about ?zero-length? values, especially if the assumption is that they will be flattened and their memory cost would be strictly equal to zero. Several components or API implementations in the JVM are using the field offset as a unique ID for fields, which works fine because today there?s a 1:1 mapping between offsets and fields. It?s also convenient because the offset uniquely identify a field in the declaring class and also in all its sub-classes. One example of this is the jFieldID used by JNI and JVMTI. Other usages are in MethodHandles code (MethodHandles::expand_MemberName()) and reflection code (jvm_get_field_common()). Zero-length flattened fields would break this property (if they really have zero-length, several fields could have the same offset). Flattened empty value types might look appealing, but we have to look carefully about the impact they will have on our code base. Fred > On Jun 26, 2018, at 15:43, Brian Goetz wrote: > > Zero-length values can be quite useful, just not directly. Look at the current implementations of Set that delegate to HashMap; all that wasted space. When we have specialized generics, they can specialize to HashMap, and that space gets squeezed away to zero. > >> On Jun 26, 2018, at 11:36 AM, Kirk Pepperdine wrote: >> >> How can a value type be empty.. what is an empty integer? An empty string? Just curious. >> >> Kind regards, >> Kirk >> >> >> >>> On Jun 26, 2018, at 3:28 PM, forax at univ-mlv.fr wrote: >>> >>> ok, >>> in that case, i think zero field value types should be rejected by the compiler. >>> >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Tobias Hartmann" >>>> ?: "Remi Forax" , "valhalla-dev" >>>> Envoy?: Mardi 26 Juin 2018 15:23:46 >>>> Objet: Re: Empty value type ? >>> >>>> Hi Remi, >>>> >>>> no, empty value types are not planned to be supported for LW1. >>>> >>>> Best regards, >>>> Tobias >>>> >>>> On 26.06.2018 15:19, Remi Forax wrote: >>>>> Is empty value type targeted for LW1 ? >>>>> >>>>> Error: LinkageError occurred while loading main class GenBug >>>>> java.lang.ClassFormatError: class: GenBug - Value Types do not support zero >>>>> instance size yet >>>>> >>>>> R?mi >> > From forax at univ-mlv.fr Fri Jun 29 19:49:29 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 29 Jun 2018 21:49:29 +0200 (CEST) Subject: Empty value type ? In-Reply-To: <2F97DE9B-80EA-4E10-BE1C-E2924F57DC19@oracle.com> References: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> <783083966.669860.1530019680824.JavaMail.zimbra@u-pem.fr> <548A46F3-5DF7-4674-A374-5E9DDF0C4C09@gmail.com> <2F97DE9B-80EA-4E10-BE1C-E2924F57DC19@oracle.com> Message-ID: <1113860819.1885793.1530301769005.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Frederic Parain" > ?: "Brian Goetz" > Cc: "valhalla-dev" > Envoy?: Vendredi 29 Juin 2018 21:31:21 > Objet: Re: Empty value type ? > I?d be cautious about ?zero-length? values, especially if the assumption is that > they will be flattened and their memory cost would be strictly equal to zero. > > Several components or API implementations in the JVM are using the field > offset as a unique ID for fields, which works fine because today there?s a 1:1 > mapping between offsets and fields. It?s also convenient because the offset > uniquely identify a field in the declaring class and also in all its > sub-classes. > One example of this is the jFieldID used by JNI and JVMTI. Other usages > are in MethodHandles code (MethodHandles::expand_MemberName()) and > reflection code (jvm_get_field_common()). > > Zero-length flattened fields would break this property (if they really have > zero-length, several fields could have the same offset). > > Flattened empty value types might look appealing, but we have to look > carefully about the impact they will have on our code base. I agree, First, you can export a fake id has a negative value or use another high bit, having a flag bit is useful because you can test easily if you can extract the value or not. Also, most of these empty types are mostly used on stack but not as field, at least until we can use them to specialize a generics class, so perhaps they can be allowed only on stack first ? > > Fred R?mi > > >> On Jun 26, 2018, at 15:43, Brian Goetz wrote: >> >> Zero-length values can be quite useful, just not directly. Look at the current >> implementations of Set that delegate to HashMap; all that wasted space. When >> we have specialized generics, they can specialize to HashMap, and >> that space gets squeezed away to zero. >> >>> On Jun 26, 2018, at 11:36 AM, Kirk Pepperdine wrote: >>> >>> How can a value type be empty.. what is an empty integer? An empty string? Just >>> curious. >>> >>> Kind regards, >>> Kirk >>> >>> >>> >>>> On Jun 26, 2018, at 3:28 PM, forax at univ-mlv.fr wrote: >>>> >>>> ok, >>>> in that case, i think zero field value types should be rejected by the compiler. >>>> >>>> R?mi >>>> >>>> ----- Mail original ----- >>>>> De: "Tobias Hartmann" >>>>> ?: "Remi Forax" , "valhalla-dev" >>>>> >>>>> Envoy?: Mardi 26 Juin 2018 15:23:46 >>>>> Objet: Re: Empty value type ? >>>> >>>>> Hi Remi, >>>>> >>>>> no, empty value types are not planned to be supported for LW1. >>>>> >>>>> Best regards, >>>>> Tobias >>>>> >>>>> On 26.06.2018 15:19, Remi Forax wrote: >>>>>> Is empty value type targeted for LW1 ? >>>>>> >>>>>> Error: LinkageError occurred while loading main class GenBug >>>>>> java.lang.ClassFormatError: class: GenBug - Value Types do not support zero >>>>>> instance size yet >>>>>> >>>>>> R?mi >>> From john.r.rose at oracle.com Fri Jun 29 20:06:46 2018 From: john.r.rose at oracle.com (John Rose) Date: Fri, 29 Jun 2018 13:06:46 -0700 Subject: Empty value type ? In-Reply-To: <2F97DE9B-80EA-4E10-BE1C-E2924F57DC19@oracle.com> References: <562018221.662106.1530019170659.JavaMail.zimbra@u-pem.fr> <783083966.669860.1530019680824.JavaMail.zimbra@u-pem.fr> <548A46F3-5DF7-4674-A374-5E9DDF0C4C09@gmail.com> <2F97DE9B-80EA-4E10-BE1C-E2924F57DC19@oracle.com> Message-ID: <20424203-0E1C-418E-BAD8-4A09603FCD59@oracle.com> On Jun 29, 2018, at 12:31 PM, Frederic Parain wrote: > > I?d be cautious about ?zero-length? values, especially if the assumption is that > they will be flattened and their memory cost would be strictly equal to zero. They are not trivial to implement, but they are very useful with specialized generic data structures, so they need to be on the table. I'm reminded that C++ supports empty classes, but in some versions it sticks in a synthetic char field, to avoid paradoxes like you describe. We could do that trick also. But Remi's fix is better. Basically, every zero-length value of a given type T is identical to T.default. This means that, although there might need to be an objectFieldOffset for such a value inside a container, that offset doesn't need to actually point at a byte inside the object. It can be whatever value we need it to be, given that it won't ever be used to load payload from the container. In effect, instance fields of type T (where T is empty) translate automatically to static fields of the same type. ? John From frederic.parain at oracle.com Fri Jun 29 20:36:13 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 29 Jun 2018 16:36:13 -0400 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <9B7BB622-42EB-473D-849D-93F9AECB36AC@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> <9B7BB622-42EB-473D-849D-93F9AECB36AC@oracle.com> Message-ID: <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> I?d prefer asserts then just let the VM crash unpredictably. But we?re speaking about Unsafe, do whatever you want for getObject()/putObject(). However, put*() methods should (must?) enforce value types immutability (this includes primitive fields too). I haven?t seen this in Mandy?s changeset (but I might I missed it). Fred > On Jun 29, 2018, at 12:35, Paul Sandoz wrote: > > > >> On Jun 29, 2018, at 7:14 AM, Frederic Parain wrote: >> >> The legacy getObject()/putObject() would be maintained with value >> types support just the time to allow a smooth transition. >> > > IMHO i think these should be left as is. Various external (and of course unsupported!) usages of Unsafe do all sorts of crazy things and there is a risk those usages could be perturbed, either due to performance or because the new code infers something incorrectly. > > I would like to suggest an alternative if this is a major concern. Modify the sun.misc.Unsafe implementation in the unsupported module and add asserts to the Java implementations to fail if it is detected value types are used. Then document the restrictions. > > Paul. From karen.kinnear at oracle.com Fri Jun 29 20:51:07 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 29 Jun 2018 16:51:07 -0400 Subject: RFR: Value types consistency checks In-Reply-To: <71EB54F5-FAA9-4A9F-AEF7-DC1E756DF7E0@oracle.com> References: <71EB54F5-FAA9-4A9F-AEF7-DC1E756DF7E0@oracle.com> Message-ID: <4E9AA19D-1954-4838-896E-3E2D8D1A8A81@oracle.com> Frederic, Many thanks for doing this and doing this so cleanly. Couple of questions: 1. instanceKlass.cpp: if (has_value_types_attribute) line 632 ? does this want to also be if EnableValhalla? my understanding is that extra attributes are ignored so classFileParser should just allow them 2. instanceKlass.cpp check_symbol/signature_for_value_types_consistency In the array part, did you want to check for ?L? or is that just me being over cautious? 3. klassVtable.cpp In update_inherited_vtable when you override a method (this is the vtable part), there is a if (check constraints & !targer_method()->is_overpass() - which needs a declarer/overridder match check. Also in initialize_itable_for_interface under if (check constraints) 4. Thank you for adding the ValueTypes attributes in the class files for the tests. Did you add any tests that fail consistency? many thanks, Karen > On Jun 28, 2018, at 4:38 PM, Frederic Parain wrote: > > Please review this changeset implementing consistency checks based on the > ValueTypes attribute. These checks ensure that the assumptions a class has > about value types, as encoded in its ValueTypes attribute, match the > reality, or the assumptions of another class it links to. > > The details of the consistency checks have been summarized by Karen in > this document: > http://cr.openjdk.java.net/~acorn/value-types-consistency-checking-details.pdf > > If the implementation doesn?t match the document, this is likely to be bug, > so please, report it. > > Some tests using the Bytecodes API have been updated to include a > ValueTypes attribute in the class files they generate (thanks to Srikanth > for adding this feature to the Bytecodes API). > > Webrev: > http://cr.openjdk.java.net/~fparain/VTAttributeChecks/webrev.01/ > > Thank you, > > Fred > From paul.sandoz at oracle.com Fri Jun 29 20:51:52 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 29 Jun 2018 13:51:52 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> <9B7BB622-42EB-473D-849D-93F9AECB36AC@oracle.com> <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> Message-ID: <020A1732-E1B9-478F-820A-CDB1788825C0@oracle.com> > On Jun 29, 2018, at 1:36 PM, Frederic Parain wrote: > > I?d prefer asserts then just let the VM crash unpredictably. > But we?re speaking about Unsafe, do whatever you want > for getObject()/putObject(). > > However, put*() methods should (must?) enforce value types immutability > (this includes primitive fields too). It?s a similar problem to the writing of final fields. Since it's possible peek and poke at any memory location with Unsafe with byte to longs and now to compound values in a single call i am unsure how we can, in general, enforce immutability or stop word tearing. Unsafe accesses can break the integrity of the VM in many ways. Such enforcement is easier if performed by the caller. Perhaps there are ways to define a set of ranges over which an offset+length is valid for writes to a base Object but that requires bounds checking and this is the kind of checking that is currently performed by the caller (and it will not be enforced for off-heap access to the same memory addresses as the base Object). Paul. > I haven?t seen this in Mandy?s changeset > (but I might I missed it). > > Fred > > >> On Jun 29, 2018, at 12:35, Paul Sandoz wrote: >> >> >> >>> On Jun 29, 2018, at 7:14 AM, Frederic Parain wrote: >>> >>> The legacy getObject()/putObject() would be maintained with value >>> types support just the time to allow a smooth transition. >>> >> >> IMHO i think these should be left as is. Various external (and of course unsupported!) usages of Unsafe do all sorts of crazy things and there is a risk those usages could be perturbed, either due to performance or because the new code infers something incorrectly. >> >> I would like to suggest an alternative if this is a major concern. Modify the sun.misc.Unsafe implementation in the unsupported module and add asserts to the Java implementations to fail if it is detected value types are used. Then document the restrictions. >> >> Paul. > From john.r.rose at oracle.com Fri Jun 29 21:12:33 2018 From: john.r.rose at oracle.com (John Rose) Date: Fri, 29 Jun 2018 14:12:33 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> <9B7BB622-42EB-473D-849D-93F9AECB36AC@oracle.com> <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> Message-ID: On Jun 29, 2018, at 1:36 PM, Frederic Parain wrote: > > I?d prefer asserts then just let the VM crash unpredictably. > But we?re speaking about Unsafe, do whatever you want > for getObject()/putObject(). Right, it's Unsafe. C++ asserts or even InternalError throws are friendly and helpful, but we ruthlessly chop them out in optimized code; that's how random crashes can happen if you get your Unsafe stuff wrong. But it is likely you will run your buggy code in the interpreter first, and from there you will get a reasonably diagnosed failure. At least, that's the theory of how to balance raw performance against a semblance of debuggability. > However, put*() methods should (must?) enforce value types immutability > (this includes primitive fields too). I haven?t seen this in Mandy?s changeset > (but I might I missed it). That's a good point, although it is an optional target of opportunity, under the theory that Unsafe requires the user to enforce all relevant constraints. Storing a new value to an ACC_FINAL object instance field is about as disastrous as storing a new value to a buffered value instance field. Is it a user error? Probably. Must the Unsafe API prevent the error? Probably not, unless it's simple to do. This also reminds me that we need a way to use Unsafe to patch value instance fields. Here's how I would like to do this, as a first cut: public Object withFloat(Object value, long offset, float x); Here's a throwaway implementation: public Object withFloat(Object value, long offset, float x) { Object[] buf = (Object[]) java.lang.reflect.Array.newInstance(value.getClass(), 1); long bufBase = arrayBaseOffset(buf.getClass()); assert(isFlattenedArray(buf.getClass())); buf[0] = value; putFloat(buf, bufBase + (offset - VALUE_BUFFER_HEADER_SIZE), x); value = buf[0]; return value; } I fear we *will* want all of the various withFoo to go with their getFoo and putFoo brethren. But I hope we *can* implement them using lower level peek/poke operations on buffered values. Doing this with one-element arrays seems relatively workable, but it requires that the arrays be flattened. Now we get to exactly what Fred is warning as a bug, but I think it's a necessary feature, which is patching value instances in place. To do this we need an Unsafe API point for creating a privately buffered value of a value type, which we can *then* safely patch using putFoo. There should also be an API point for freezing the private buffer, in case the optimizer cares, and for potential error checks. It would be good (though not required) if the interpreter entry points for putField would verify that, if the Object in question is a value instance, then the object is a private buffer, not an arbitrary shared buffer that found its way into a dangerous neighborhood. See below. To prevent putFoo on random values robustly we would want a "larval bit" inside the temporary private buffer header. Larval objects are something we are likely to do anyway, at some point, but we can't now. ? John public Object withFloat(Class valueType, Object value, long offset, float x) { Object buf = makePrivateBuffer(value); putFloat(buf, offset, x); return finishPrivateBuffer(buf); } // prototype version; must be intrinsified for real use public Object makePrivateBuffer(Object value) { assert(value.getClass().isValue()); Object[] a = (Object[]) java.lang.reflect.Array.newInstance(value.getClass(), 1); assert(isFlattenedArray(bh.a.getClass())); int i = 0; a[i] = value; { class BlackHole { volatile Object[] a; volatile int i; } var bh = new BlackHole(); bh.a = a; bh.i = i; a = bh.a; i = bh.i; } value = a[i]; //value = enterLarvalState(value); return value; } // prototype version; must be intrinsified for real use public Object finishPrivateBuffer(Object value) { //assert(isPrivateBufferInLarvalState(value)); //value = exitLarvalState(value); return value; } From john.r.rose at oracle.com Fri Jun 29 21:13:08 2018 From: john.r.rose at oracle.com (John Rose) Date: Fri, 29 Jun 2018 14:13:08 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <020A1732-E1B9-478F-820A-CDB1788825C0@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> <9B7BB622-42EB-473D-849D-93F9AECB36AC@oracle.com> <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> <020A1732-E1B9-478F-820A-CDB1788825C0@oracle.com> Message-ID: On Jun 29, 2018, at 1:51 PM, Paul Sandoz wrote: > > It?s a similar problem to the writing of final fields. Since it's possible peek and poke at any memory location with Unsafe with byte to longs and now to compound values in a single call i am unsure how we can, in general, enforce immutability or stop word tearing. Unsafe accesses can break the integrity of the VM in many ways. > > Such enforcement is easier if performed by the caller. Perhaps there are ways to define a set of ranges over which an offset+length is valid for writes to a base Object but that requires bounds checking and this is the kind of checking that is currently performed by the caller (and it will not be enforced for off-heap access to the same memory addresses as the base Object). +1 BYOSB (bring your own seat belts) From mandy.chung at oracle.com Fri Jun 29 21:15:49 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 29 Jun 2018 14:15:49 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> <9B7BB622-42EB-473D-849D-93F9AECB36AC@oracle.com> <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> Message-ID: On 6/29/18 1:36 PM, Frederic Parain wrote: > I?d prefer asserts then just let the VM crash unpredictably. > But we?re speaking about Unsafe, do whatever you want > for getObject()/putObject(). > > However, put*() methods should (must?) enforce value types immutability > (this includes primitive fields too). I haven?t seen this in Mandy?s changeset > (but I might I missed it). This is not enforced (as John explains) in Unsafe::putXXX methods as they are unsafe access. VarHandle and core reflection have an explicit guard to disallow writing to fields of a value type [1][2]. Final is final for value types. The caller to putValueXXX does require the new value to be non-null (see X-VarHandle.java.template). The check you put in in your patch is to throw NPE if it's writing null to a flat field of value type. That is not done in the library and I will create a JBS issue and fix that separately. Mandy [1] http://hg.openjdk.java.net/valhalla/valhalla/file/tip/src/java.base/share/classes/java/lang/invoke/MethodHandles.java#l2419 [2] http://hg.openjdk.java.net/valhalla/valhalla/file/tip/src/java.base/share/classes/java/lang/reflect/Field.java#l168 From paul.sandoz at oracle.com Fri Jun 29 21:36:22 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 29 Jun 2018 14:36:22 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> <9B7BB622-42EB-473D-849D-93F9AECB36AC@oracle.com> <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> Message-ID: <8AA6C9ED-536F-4DFB-9DA1-34682BA81D7D@oracle.com> > This also reminds me that we need a way to use Unsafe > to patch value instance fields. Here's how I would like to > do this, as a first cut: > That?s a good observation. The lack of enforcement on Unsafe allow us to internally break the rules (as long as the intermediate breaking effects are contained and cannot be observed externally). I can see interesting usages for object + fused tail and writing values to that tail, or even perhaps scribbling values that contain no oops to a byte buffer. Paul. From karen.kinnear at oracle.com Fri Jun 29 21:40:59 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 29 Jun 2018 17:40:59 -0400 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> <808e8ffa-f283-6493-04e2-2229b3d1f858@oracle.com> <644d5e62-372b-afef-9426-65c2ce8d4cc5@oracle.com> <80808535-AB5D-44A4-AC5A-54E237BE564F@oracle.com> Message-ID: <278B279F-837F-4B74-A7A7-8DB7EC0B752E@oracle.com> Thank you all for the rapid responses and prototyping. Based on John/Paul/Remi?s suggestions - this is what I propose we do for LW1: (Roland, Tobias - intrinsics questions embedded please) I. New APIs: Add new unsafe APIs for getValue/putValue and getReference/putReference (your choice of names) and get to them as Remi suggested via jdk.internal.misc.unsafe. - Use the new APIs from MethodHandles/VarHandles/Reflection (as Mandy is prototyping) II. getObject/putObject handling I like the combined suggestions of: - jdk.internal.misc.unsafe - remove getObject/putObject and friends - as you have time, migrating all the callers to use the new APIs. - sun.misc.unsafe - this currently redirects you to jdk.internal.misc.unsafe - your call how you do this - this would be the place to have the value-aware version Step 1: Have Frederic check in his native changes including getObject/putObject native changes. Remove @HotspotIntrinsic for getObject/putObject. Step 2: Move the conditional logic to jdk.internal.misc.unsafe which will call getValue/getReference as appropriate. Please move ALL the logic in the native version to java - making sure to cover all the cases the native version is covering today. Step 3: If you have time - Remove jdk.internal.misc.unsafe.getObject/putObject - and replace all jdk uses with the new calls, possibly moving the logic out to sun.misc.unsafe. IV. Intrinsics Roland, Tobias My expectation of intrinsics is: 1. The new getReference/putReference will use exactly the same code as today?s getObject/putObject, so it could use the same intrinsics 2. The new getValue/putValue will need new intrinsics - which have additional challenges for example due to scalarization 3. getObject/putObject will no longer be intensified IV. Immutability Immutability is not just a good idea, ? Immutability is not the same as final - sorry - we actually count on it. I highly recommend that even through unsafe - value types are immutable. V. Nullability In LW1, all instance fields of value types are flattenable and non-nullable. We have the option in putValue of not allowing writing null to an value type instance field. Let?s start with that assumption. We intend to add flattenable static fields shortly after LW1, so we should disallow writing null to flattenable value type static fields. Open Questions: 1. atomic/volatile/etc. What can you do at the java level? We don?t currently support atomic flattenable value types. thanks, Karen p.s. I will be out on vacation next week, back the week after - don?t let me slow you down > On Jun 29, 2018, at 2:58 PM, mandy chung wrote: > > > > On 6/29/18 9:23 AM, Paul Sandoz wrote: >> View nice! >> Comments for further iteration perhaps after committing: >> - You may want to follow the same pattern for getType as for >> fieldOffset i.e. use a static method rather than a virtual method. > > I added static fieldValueType for Accessor and staticFieldValueType > for StaticAccessor that might help the performance (no data). > > I am in two mind if I should prepare the static field case as > hotspot does not flatten static field. For now, I keep it there > and should revisit it at some point. > >> - We can remove the atomic add and bitwise ops from >> ValueFieldInstanceReadWrite. > > Good catch. I took that out. > >> - The Unsafe atomic accessors ValueVolatile/Acquire/Release/Opaque >> can use a global lock for the moment to ensure atomicity and >> ordering, the acquire/release can defer to the volatile accessors. >> Adding the others is also straightforward (weaker CAS and CAE can >> defer to the volatile CAS/CAE methods). >> Happy to help with any of this with following patches. > > Thanks. I wanted to look at volatile/acquire/release/opaque and > other ops separately and will definitely ask your help. So no lock > at the moment and hope it's okay. > > Revised webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/unsafe-flat-fields-webrev.01/ > > Mandy > From frederic.parain at oracle.com Fri Jun 29 21:50:01 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 29 Jun 2018 17:50:01 -0400 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <8AA6C9ED-536F-4DFB-9DA1-34682BA81D7D@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> <9B7BB622-42EB-473D-849D-93F9AECB36AC@oracle.com> <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> <8AA6C9ED-536F-4DFB-9DA1-34682BA81D7D@oracle.com> Message-ID: <3B8FA895-6690-41F4-A7CB-266BA4F6AC7B@oracle.com> Breaking the rules even internally is dangerous. There?s currently no guarantee at the Java level that the value being operated on is not shared with other threads. __MakeDefault is not new, you don?t have the guarantee that you?ll get a fresh unshared value.In fact, it currently returns a shared instance, and modifying it would corrupt all future new values. Many other optimizations are already in place in the JVM strongly relying on the immutability of values, adding sharing and aliasing in many places (arrays, LVT in the interpreter). Situation is even worse in JIT compiled code, where object_base + offset has no direct meaning because of values scalarization. I like the caveat "as long as the intermediate breaking effects are contained and cannot be observed externally?, but I?m curious to know how it will be checked or enforced. Fred > On Jun 29, 2018, at 17:36, Paul Sandoz wrote: > > >> This also reminds me that we need a way to use Unsafe >> to patch value instance fields. Here's how I would like to >> do this, as a first cut: >> > > That?s a good observation. The lack of enforcement on Unsafe allow us to internally break the rules (as long as the intermediate breaking effects are contained and cannot be observed externally). I can see interesting usages for object + fused tail and writing values to that tail, or even perhaps scribbling values that contain no oops to a byte buffer. > > Paul. From paul.sandoz at oracle.com Fri Jun 29 21:52:22 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 29 Jun 2018 14:52:22 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <278B279F-837F-4B74-A7A7-8DB7EC0B752E@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> <808e8ffa-f283-6493-04e2-2229b3d1f858@oracle.com> <644d5e62-372b-afef-9426-65c2ce8d4cc5@oracle.com> <80808535-AB5D-44A4-AC5A-54E237BE564F@oracle.com> <278B279F-837F-4B74-A7A7-8DB7EC0B752E@oracle.com> Message-ID: <239099C6-E682-4F76-B107-9392B5D6A1B3@oracle.com> > On Jun 29, 2018, at 2:40 PM, Karen Kinnear wrote: > > IV. Immutability > Immutability is not just a good idea, ? > Immutability is not the same as final - sorry - we actually count on it. But i would argue it is similar to how final fields are treated in j.l.invoke and fields annotated with @Stable within java.base. Writing to such a field using Unsafe can break the VM integrity. > I highly recommend that even through unsafe - value types are immutable. > Yes, from the byte code and public accessor methods the immutable property should be enforced, and the JIT should assume that integrity is enforced and optimize just like it does for @Stable fields. IMO all bets are off if you use unsafe generally to scribble on presumed read-only areas of memory :-) Paul. From frederic.parain at oracle.com Fri Jun 29 21:54:23 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 29 Jun 2018 17:54:23 -0400 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> <9B7BB622-42EB-473D-849D-93F9AECB36AC@oracle.com> <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> Message-ID: <02D20B31-8EFC-443F-8579-5DAC2A1761C9@oracle.com> > On Jun 29, 2018, at 17:15, mandy chung wrote: > > > > On 6/29/18 1:36 PM, Frederic Parain wrote: >> I?d prefer asserts then just let the VM crash unpredictably. >> But we?re speaking about Unsafe, do whatever you want >> for getObject()/putObject(). >> However, put*() methods should (must?) enforce value types immutability >> (this includes primitive fields too). I haven?t seen this in Mandy?s changeset >> (but I might I missed it). > > This is not enforced (as John explains) in Unsafe::putXXX methods as they are unsafe access. VarHandle and core reflection have an explicit guard to disallow writing to fields of a value type [1][2]. Final is final for value types. The caller to putValueXXX does require the > new value to be non-null (see X-VarHandle.java.template). Thank you for the explanation. I just want to clarify the consequences of unrestricted Unsafe::putXXX on values: a single call can corrupt many values and have persistent effects on future values. Fred > > The check you put in in your patch is to throw NPE if it's writing > null to a flat field of value type. That is not done in the library > and I will create a JBS issue and fix that separately. > > Mandy > [1] http://hg.openjdk.java.net/valhalla/valhalla/file/tip/src/java.base/share/classes/java/lang/invoke/MethodHandles.java#l2419 > [2] http://hg.openjdk.java.net/valhalla/valhalla/file/tip/src/java.base/share/classes/java/lang/reflect/Field.java#l168 From john.r.rose at oracle.com Fri Jun 29 22:08:13 2018 From: john.r.rose at oracle.com (John Rose) Date: Fri, 29 Jun 2018 15:08:13 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <278B279F-837F-4B74-A7A7-8DB7EC0B752E@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <8B69B0DE-3A03-472B-86B4-0FD7A8740D3A@oracle.com> <808e8ffa-f283-6493-04e2-2229b3d1f858@oracle.com> <644d5e62-372b-afef-9426-65c2ce8d4cc5@oracle.com> <80808535-AB5D-44A4-AC5A-54E237BE564F@oracle.com> <278B279F-837F-4B74-A7A7-8DB7EC0B752E@oracle.com> Message-ID: On Jun 29, 2018, at 2:40 PM, Karen Kinnear wrote: > > Thank you all for the rapid responses and prototyping. > > Based on John/Paul/Remi?s suggestions - this is what I propose we do for LW1: > (Roland, Tobias - intrinsics questions embedded please) > > I. ? III. Yes, that's a good breakdown into steps. > IV. Immutability > Immutability is not just a good idea, ? > Immutability is not the same as final - sorry - we actually count on it. > I highly recommend that even through unsafe - value types are immutable. I have to disagree on this one. Immutability is a stronger invariant than final, but Unsafe is stronger than both. Unsafe has to be able to bend all those rules. The design constraint for Unsafe is that there has to be a safe way to use it. Other than that, there are no constraints on what Unsafe is allowed to touch. It is the Java way to scribble on memory like C++ can do. I claim adding the makePrivateBuffer/finishPrivateBuffer API points will enable us to preserve immutability invariants around the private buffer, while accurately collecting the required side effects. I *think* there is an efficient way to implement those API points; if I'm wrong we'll have to come up with an alternative API point for Unsafe. > V. Nullability > In LW1, all instance fields of value types are flattenable and non-nullable. > We have the option in putValue of not allowing writing null to an value type instance field. > Let?s start with that assumption. I agree. As with Tobias' latest JIT work on nullability, the detection of nulls is a caller responsibility. We don't have any future work on the books to fold nullability into flattened fields, only non-flattened fields. This could change, but then we'd need to make adjustments throughout the system, not just Unsafe. > We intend to add flattenable static fields shortly after LW1, so we should disallow writing > null to flattenable value type static fields. Yes, where "disallow" has the usual meaning for Unsafe: It is a caller responsibility to check for this, and if the caller makes a mistake, then you might get a good diagnosis of this, but if the code was optimized, you'll get unpredictable results. NPE or InternalError if you are lucky. So, nulls are never correctly written (via Unsafe) to flattened variables, and if they are incorrectly written, we get the usual unpredictable behavior from Unsafe. Loading a null *from* a non-flattened variable is open to interpretation (as in Tobias' JIT work), but I would lean towards requiring the user to call getReference and explicitly test for null and replace with T.default if that is what was intended. Having getValue automatically replace null with T.default (for an invisible non-flattened variable) is a little too indirect for Unsafe, although it might be the right call in this case, if the value type is *never* flattened. > Open Questions: > 1. atomic/volatile/etc. What can you do at the java level? > We don?t currently support atomic flattenable value types. I think this is the plan of record: Translate volatile value fields to non-flattened non-nullable fields; do this transparently in the class loader. Later on: Experiment with SeqLock-based protocols. Overlay the SeqLock in the containing object header if possible. Perhaps use split locks with flattened arrays. The interaction with Unsafe would be as follows: If a value field is translated to a non-flattened field, we can detect this with a metadata query, and use get/putReference instead of get/putValue. (Or we can make it automagic inside of get/putValue, as long as the operands to get/putValue distinguish correctly between flattened and non-flattened fields.) My assumption here is that every field can be fully described as either flattened or not, with nullability as an extra bit if it is not flattened. If we get fancier with field representations, then the Unsafe API points might need to take more arguments to reflect the new fancy degrees of freedom, along with the rest of the JVM internals. Unsafe is part of the JVM internals. ? John From paul.sandoz at oracle.com Fri Jun 29 22:14:47 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 29 Jun 2018 15:14:47 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <3B8FA895-6690-41F4-A7CB-266BA4F6AC7B@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> <9B7BB622-42EB-473D-849D-93F9AECB36AC@oracle.com> <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> <8AA6C9ED-536F-4DFB-9DA1-34682BA81D7D@oracle.com> <3B8FA895-6690-41F4-A7CB-266BA4F6AC7B@oracle.com> Message-ID: <943538B1-785A-437E-9A50-49829F26A5FC@oracle.com> > On Jun 29, 2018, at 2:50 PM, Frederic Parain wrote: > > Breaking the rules even internally is dangerous. Yes, very :-) > There?s currently no guarantee at the Java level that the > value being operated on is not shared with other threads. > __MakeDefault is not new, you don?t have the guarantee that > you?ll get a fresh unshared value.In fact, it currently returns > a shared instance, and modifying it would corrupt all future > new values. Many other optimizations are already in place in > the JVM strongly relying on the immutability of values, adding > sharing and aliasing in many places (arrays, LVT in the > interpreter). Situation is even worse in JIT compiled code, > where object_base + offset has no direct meaning because > of values scalarization. > Yes. Fun fact: did you know that one can subvert the values of boxed ints by changing the contents of the cache used in j.l.Integer? (see Intenger.IntegerCache.cache) > I like the caveat "as long as the intermediate breaking effects > are contained and cannot be observed externally?, but I?m > curious to know how it will be checked or enforced. > With great care and good testing. Some of the code in j.l.invoke plays this dangerous game. I wish there could be a way of more formally marking a block of such internal code beyond clear use of the Unsafe class. ? I view Unsafe as a far far less formal equivalent of Rust?s unsafe block [1] for us Java Runtime engineers to build a safe and performant platform. I guess the closest formal notion with have currently is JNI :-) soon we will have Panama and that will up-level some unsafe properties of JNI and native wrappers into Java code. Paul. [1] https://doc.rust-lang.org/book/second-edition/ch19-01-unsafe-rust.html https://doc.rust-lang.org/nightly/nomicon/ "Instead of the programs I had hoped for, there came only a shuddering blackness and ineffable loneliness; and I saw at last a fearful truth which no one had ever dared to breathe before ? the unwhisperable secret of secrets ? The fact that this language of stone and stridor is not a sentient perpetuation of Rust as London is of Old London and Paris of Old Paris, but that it is in fact quite unsafe, its sprawling body imperfectly embalmed and infested with queer animate things which have nothing to do with it as it was in compilation." From john.r.rose at oracle.com Fri Jun 29 22:37:50 2018 From: john.r.rose at oracle.com (John Rose) Date: Fri, 29 Jun 2018 15:37:50 -0700 Subject: RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe In-Reply-To: <943538B1-785A-437E-9A50-49829F26A5FC@oracle.com> References: <93F26824-C920-4747-AE9D-C2A44E43C2C7@oracle.com> <9074913C-997B-43BB-802C-DAC93FA8EA64@oracle.com> <75EC382D-85CC-402B-85B2-23FC72F60EDB@oracle.com> <9B7BB622-42EB-473D-849D-93F9AECB36AC@oracle.com> <34BC4E23-56C3-4476-93BB-140B98662EC7@oracle.com> <8AA6C9ED-536F-4DFB-9DA1-34682BA81D7D@oracle.com> <3B8FA895-6690-41F4-A7CB-266BA4F6AC7B@oracle.com> <943538B1-785A-437E-9A50-49829F26A5FC@oracle.com> Message-ID: <9AA03F6B-5D8D-4C0E-96D5-646913F027E2@oracle.com> On Jun 29, 2018, at 3:14 PM, Paul Sandoz wrote: > > >> I like the caveat "as long as the intermediate breaking effects >> are contained and cannot be observed externally?, but I?m >> curious to know how it will be checked or enforced. Yes, that's exactly what I meant by the design constraint that an Unsafe API must be usable in a safe manner; you could call the the Unsafe Prime Directive. See my previous message for how to implement this directive for value patching: You need a pair of intrinsics for privately buffering a value, and for committing such a buffer to be shareable. In the JIT, they would be implemented using some sort of fencing, perhaps with an internal mode change (from ValueNode to ValuePtrNode or the like). > With great care and good testing. Some of the code in j.l.invoke plays this dangerous game. (If you like, think of Unsafe as the C++ Access API hiding in Java. The same mind set is required for using either.) > I wish there could be a way of more formally marking a block of such internal code beyond clear use of the Unsafe class. A bit of history: Over various objections similar to the present ones, I created the sun.misc.Unsafe API (first commit 2000/04/01, not a prank). The goal was (and is) to allow Java code to play on C++'s territory. Even back then we were getting tired of writing new bespoke natives and C++ code for every incrementally edgy new idea for a Java API. (That was also when I began to dream of an all-Java implementation of HotSpot a la Graal/Metropolis/Maxine/Jikes, and wonder when that researchy idea would be mature enough to emerge from somebody's labs.) At the time I was aware of the unsafe-block feature in some research languages, and, with fear and trembling, instead designed a dynamic capability-based permission check, to properly delimit and check code which uses this super-user API. At the time piggy-backing a capability check on the JVM null check was an unproven technique. It seems to have worked. You can find unsafe blocks fairly easily in Java simply by looking for uses (import, CP entries) of Unsafe. In the end, and combined with Java 9 modules, I think it's not terribly worse than an unsafe block with an unsafe marker attribute on code. When you see Unsafe, it means "Don't fiddle with this if you don't know what it does, but if you do know what you are about, you are in super-user mode; bring your own seat belt." > ? > > I view Unsafe as a far far less formal equivalent of Rust?s unsafe block [1] for us Java Runtime engineers to build a safe and performant platform. I guess the closest formal notion with have currently is JNI :-) soon we will have Panama and that will up-level some unsafe properties of JNI and native wrappers into Java code. Yep. Actually Panama re-raises the question of clearly marking Java code which needs extra analysis to verify safety (null, bounds, lifetime, type, etc.). One way to secure Panama code would be to require an Unsafe instance to do anything with a Panama binding. ? John