From tobias.hartmann at oracle.com Mon Jul 1 11:26:07 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 01 Jul 2019 11:26:07 +0000 Subject: hg: valhalla/valhalla: 8227012: [lworld] Compiler tests fail with -Xmixed Message-ID: <201907011126.x61BQ7Kt010386@aojmv0008.oracle.com> Changeset: c8c7d759f9c0 Author: thartmann Date: 2019-07-01 13:25 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c8c7d759f9c0 8227012: [lworld] Compiler tests fail with -Xmixed ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestCallingConventionC1.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestJNICalls.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestOnStackReplacement.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java From forax at univ-mlv.fr Mon Jul 1 13:05:50 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 1 Jul 2019 15:05:50 +0200 (CEST) Subject: inline class should not compile with --source 13 Message-ID: <701907809.373339.1561986350096.JavaMail.zimbra@u-pem.fr> Hi all, currently if you try to compile with the version 13, you get a fun error message (because ValueBootstrapMethods is not a class which is a part of the version 13). bash-4.4$ /usr/jdk/jdk-13-lworld/bin/javac --release 13 Simple.java Simple.java:1: error: cannot access ValueBootstrapMethods inline class Simple { ^ class file for java.lang.invoke.ValueBootstrapMethods not found 1 error Fatal Error: Unable to find method makeBootstrapMethod I believe it's better to not allow "inline" classes if the source version is not 14. R?mi From harold.seigel at oracle.com Mon Jul 1 13:10:46 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 1 Jul 2019 09:10:46 -0400 Subject: inline class should not compile with --source 13 In-Reply-To: <701907809.373339.1561986350096.JavaMail.zimbra@u-pem.fr> References: <701907809.373339.1561986350096.JavaMail.zimbra@u-pem.fr> Message-ID: <553f55b0-0e77-c7cb-73d5-1daa5958e10d@oracle.com> Hi Remi, Thanks for reporting this issue. It looks similar to open bug https://bugs.openjdk.java.net/browse/JDK-8208204 Harold On 7/1/2019 9:05 AM, Remi Forax wrote: > Hi all, > currently if you try to compile with the version 13, you get a fun error message > (because ValueBootstrapMethods is not a class which is a part of the version 13). > > bash-4.4$ /usr/jdk/jdk-13-lworld/bin/javac --release 13 Simple.java > Simple.java:1: error: cannot access ValueBootstrapMethods > inline class Simple { > ^ > class file for java.lang.invoke.ValueBootstrapMethods not found > 1 error > Fatal Error: Unable to find method makeBootstrapMethod > > > I believe it's better to not allow "inline" classes if the source version is not 14. > > R?mi From tobias.hartmann at oracle.com Mon Jul 1 13:17:14 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 1 Jul 2019 15:17:14 +0200 Subject: RFR(M): 8222221: [lworld] Valhalla causes performance slowdown for reflective invocations Message-ID: <9e6f6e2e-9d6b-4731-7513-301b55822d50@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8222221 http://cr.openjdk.java.net/~thartmann/8222221/webrev.00/ The performance regression observed with reflective invocations is due to Object array accesses in the GeneratedMethodAccessor because arguments are passed as varags (see bug comments). To mitigate this, I've added code to speculate on varag arrays not being null-free value type arrays. The type system now allows to mark TypeAry as _not_flat and _not_null_free (which implies _not_flat). The speculative type is added on method entry (see parse1.cpp) and only used on array access in Parse::array_addressing by adding a corresponding guard. We could also do this when accessing arrays in intrinsics but I leave this for future work. I've also noticed that we were sometimes emitting value array guards even if flattening is not possible. I've added the corresponding checks and asserts. The patch also contains some unrelated refactoring of code I've spotted when debugging. As a follow-up enhancement, I plan to optimize object array loads followed by a cast of the element. If the element is successfully castes to a non-value type, we know that the source array can never be a value type array (and we can mark the type as _not_flat and _not_null_free). Thanks, Tobias From forax at univ-mlv.fr Mon Jul 1 13:43:59 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 1 Jul 2019 15:43:59 +0200 (CEST) Subject: inline class should not compile with --source 13 In-Reply-To: <553f55b0-0e77-c7cb-73d5-1daa5958e10d@oracle.com> References: <701907809.373339.1561986350096.JavaMail.zimbra@u-pem.fr> <553f55b0-0e77-c7cb-73d5-1daa5958e10d@oracle.com> Message-ID: <1935421202.393594.1561988639401.JavaMail.zimbra@u-pem.fr> Hi Harold, it's not exactly the same issue, your issue is about the VM mine is about the javac. There are more both side of the same coin, e.g. the compiler (javac) and the VM should only support inline classes with the latest version of the classfile. R?mi ----- Mail original ----- > De: "Harold David Seigel" > ?: "valhalla-dev" > Envoy?: Lundi 1 Juillet 2019 15:10:46 > Objet: Re: inline class should not compile with --source 13 > Hi Remi, > > Thanks for reporting this issue. > > It looks similar to open bug > https://bugs.openjdk.java.net/browse/JDK-8208204 > > Harold > > On 7/1/2019 9:05 AM, Remi Forax wrote: >> Hi all, >> currently if you try to compile with the version 13, you get a fun error message >> (because ValueBootstrapMethods is not a class which is a part of the version >> 13). >> >> bash-4.4$ /usr/jdk/jdk-13-lworld/bin/javac --release 13 Simple.java >> Simple.java:1: error: cannot access ValueBootstrapMethods >> inline class Simple { >> ^ >> class file for java.lang.invoke.ValueBootstrapMethods not found >> 1 error >> Fatal Error: Unable to find method makeBootstrapMethod >> >> >> I believe it's better to not allow "inline" classes if the source version is not >> 14. >> > > R?mi From srikanth.adayapalam at oracle.com Mon Jul 1 13:48:57 2019 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Mon, 1 Jul 2019 19:18:57 +0530 Subject: inline class should not compile with --source 13 In-Reply-To: <1935421202.393594.1561988639401.JavaMail.zimbra@u-pem.fr> References: <701907809.373339.1561986350096.JavaMail.zimbra@u-pem.fr> <553f55b0-0e77-c7cb-73d5-1daa5958e10d@oracle.com> <1935421202.393594.1561988639401.JavaMail.zimbra@u-pem.fr> Message-ID: <8384daa9-4f73-45e4-5b16-d2606bc7cdd8@oracle.com> Hi Remi, Thanks for reporting this, I will follow up. Srikanth On 01/07/19 7:13 PM, Remi Forax wrote: > Hi Harold, > > it's not exactly the same issue, > your issue is about the VM mine is about the javac. > > There are more both side of the same coin, e.g. the compiler (javac) and the VM should only support inline classes with the latest version of the classfile. > > R?mi > > ----- Mail original ----- >> De: "Harold David Seigel" >> ?: "valhalla-dev" >> Envoy?: Lundi 1 Juillet 2019 15:10:46 >> Objet: Re: inline class should not compile with --source 13 >> Hi Remi, >> >> Thanks for reporting this issue. >> >> It looks similar to open bug >> https://bugs.openjdk.java.net/browse/JDK-8208204 >> >> Harold >> >> On 7/1/2019 9:05 AM, Remi Forax wrote: >>> Hi all, >>> currently if you try to compile with the version 13, you get a fun error message >>> (because ValueBootstrapMethods is not a class which is a part of the version >>> 13). >>> >>> bash-4.4$ /usr/jdk/jdk-13-lworld/bin/javac --release 13 Simple.java >>> Simple.java:1: error: cannot access ValueBootstrapMethods >>> inline class Simple { >>> ^ >>> class file for java.lang.invoke.ValueBootstrapMethods not found >>> 1 error >>> Fatal Error: Unable to find method makeBootstrapMethod >>> >>> >>> I believe it's better to not allow "inline" classes if the source version is not >>> 14. >>> >>> R?mi From rwestrel at redhat.com Mon Jul 1 14:33:23 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 01 Jul 2019 16:33:23 +0200 Subject: RFR: 8224211:[lworld] Reflective method invocation fails with assert(sender_sp != sp()) failed: must have changed Message-ID: <87zhlxakp8.fsf@redhat.com> http://cr.openjdk.java.net/~roland/8224211/webrev.00/ I couldn't reproduce the exact same failure. What I see is a SIGSEGV in a checkcast in the interpreter. I found that when StubGenerator::generate_call_stub() is called, CompressedKlassPointers::base() and CompressedKlassPointers::shift() are not yet set so code generated in case of a flattened return value is incorrect. I propose the runtime pre-allocates a result buffer before the call to java in case of a value type return and the call stub fills it with the flattened return value (or discard it if we get a buffered value from the call). With the current scheme a safepoint/exception could happen on a value return and we were not sure how the call stub would handle it. We don't have to worry about that with this change. Roland. From ioi.lam at oracle.com Tue Jul 2 03:40:35 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 1 Jul 2019 20:40:35 -0700 Subject: RFR 8227065 [lworld][c1] runtime.valhalla.valuetypes.ValueTypeArray fails with C1 Message-ID: https://bugs.openjdk.java.net/browse/JDK-8227065 http://cr.openjdk.java.net/~iklam/valhalla/8227065-ValueTypeArray-fails-with-c1.v01/ The bug is in Runtime1::new_value_array(). It should initialize the value class as necessary (similar to how the interpreter handles it). I added two new test cases in compiler/valhalla/valuetypes/TestUnloadedValueTypeArray.java Thanks - Ioi From rwestrel at redhat.com Tue Jul 2 07:30:29 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 02 Jul 2019 09:30:29 +0200 Subject: RFR: 8224211:[lworld] Reflective method invocation fails with assert(sender_sp != sp()) failed: must have changed In-Reply-To: <87zhlxakp8.fsf@redhat.com> References: <87zhlxakp8.fsf@redhat.com> Message-ID: <87v9wkao6i.fsf@redhat.com> I updated the webrev with a small tweak: http://cr.openjdk.java.net/~roland/8224211/webrev.01/ (no need to allocate the buffer if ValueTypeReturnedAsFields is not on) Roland. From tobias.hartmann at oracle.com Tue Jul 2 07:42:01 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 2 Jul 2019 09:42:01 +0200 Subject: RFR(S): 8227033: [lworld] Remove ACmpOnValues command line option Message-ID: <77c73b5b-3f77-99ea-19c9-a596fe75958c@oracle.com> Hi, please review the following patch that removes the ACmpOnValues command line option. The substitutability check is now the default default with -XX+EnableValhalla. https://bugs.openjdk.java.net/browse/JDK-8227033 http://cr.openjdk.java.net/~thartmann/8227033/webrev.00/ Thanks, Tobias From rwestrel at redhat.com Tue Jul 2 13:13:47 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 02 Jul 2019 15:13:47 +0200 Subject: RFR(S): 8227033: [lworld] Remove ACmpOnValues command line option In-Reply-To: <77c73b5b-3f77-99ea-19c9-a596fe75958c@oracle.com> References: <77c73b5b-3f77-99ea-19c9-a596fe75958c@oracle.com> Message-ID: <87pnmsa8ac.fsf@redhat.com> > http://cr.openjdk.java.net/~thartmann/8227033/webrev.00/ Is this: 1421 if (compiled) { still required? If I remember correctly I added it when the substitutability test was only implemented by c2. Roland. From tobias.hartmann at oracle.com Tue Jul 2 13:27:14 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 2 Jul 2019 15:27:14 +0200 Subject: RFR 8227065 [lworld][c1] runtime.valhalla.valuetypes.ValueTypeArray fails with C1 In-Reply-To: References: Message-ID: Hi Ioi, looks good to me. Thanks, Tobias On 02.07.19 05:40, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8227065 > http://cr.openjdk.java.net/~iklam/valhalla/8227065-ValueTypeArray-fails-with-c1.v01/ > > The bug is in Runtime1::new_value_array(). It should initialize the value class > as necessary (similar to how the interpreter handles it). > > I added two new test cases in compiler/valhalla/valuetypes/TestUnloadedValueTypeArray.java > > Thanks > - Ioi From rwestrel at redhat.com Tue Jul 2 13:51:23 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 02 Jul 2019 15:51:23 +0200 Subject: RFR(M): 8222221: [lworld] Valhalla causes performance slowdown for reflective invocations In-Reply-To: <9e6f6e2e-9d6b-4731-7513-301b55822d50@oracle.com> References: <9e6f6e2e-9d6b-4731-7513-301b55822d50@oracle.com> Message-ID: <87muhwa6jo.fsf@redhat.com> > http://cr.openjdk.java.net/~thartmann/8222221/webrev.00/ Why drop stuff related to Compile::_type_hwm? Why no check for is_not_flat() for the first generate_valueArray_guard below? Shouldn't the is_not_flat() test be in generate_valueArray_guard()? 4042 Node* is_flat = generate_valueArray_guard(klass_node, NULL); 4043 if (!original_t->is_not_flat()) { 4044 generate_valueArray_guard(original_kls, bailout); 4045 } In Parse::array_store(), why remove: || elemptr->is_valuetypeptr() ? 253 Node *kls = load_object_klass(ary); 254 Node *layout_val = load_lh_array_tag(kls); Isn't the usual coding convention Node* kls? Roland. From rwestrel at redhat.com Tue Jul 2 14:22:08 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 02 Jul 2019 16:22:08 +0200 Subject: RFR: 8224211:[lworld] Reflective method invocation fails with assert(sender_sp != sp()) failed: must have changed In-Reply-To: <87v9wkao6i.fsf@redhat.com> References: <87zhlxakp8.fsf@redhat.com> <87v9wkao6i.fsf@redhat.com> Message-ID: <87k1d0a54f.fsf@redhat.com> One more tweak: http://cr.openjdk.java.net/~roland/8224211/webrev.02/ Call result->set_jobject() right before the call itself. There could be a gc between the allocation and the call that would not update the result JavaValue. Roland. From ioi.lam at oracle.com Tue Jul 2 16:36:00 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Tue, 02 Jul 2019 16:36:00 +0000 Subject: hg: valhalla/valhalla: 8227065: [lworld][c1] runtime.valhalla.valuetypes.ValueTypeArray fails with C1 Message-ID: <201907021636.x62Ga2jD001831@aojmv0008.oracle.com> Changeset: 78ac902a15bf Author: iklam Date: 2019-07-02 09:35 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/78ac902a15bf 8227065: [lworld][c1] runtime.valhalla.valuetypes.ValueTypeArray fails with C1 Reviewed-by: thartmann ! src/hotspot/share/c1/c1_Runtime1.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestUnloadedValueTypeArray.java From ioi.lam at oracle.com Wed Jul 3 05:13:23 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 2 Jul 2019 22:13:23 -0700 Subject: RFR 8227040 [lworld][c1] Must repair stack frame before calling buffer_value_args Message-ID: https://bugs.openjdk.java.net/browse/JDK-8227040 http://cr.openjdk.java.net/~iklam/valhalla/8227040-repair-frame-before-buffer_value_args.v01/ When a C1-compiled method is called by C2, it needs to pack all the fields of its value arguments back to buffered objects. In some cases, usually when the value arguments have floating point fields, the C1 callee may require more stack than what has been provided by the C2 caller. On x64, this is handled by the following "stack repair" instructions in the "Verified Entry Point" of the callee ??? pop %r13 ??? sub ,%rsp ??? push %r13 ??? movq ,(%rsp) The stack must be repaired before it can be walked (for GC, etc). This bug happens because we call Runtime1::buffer_value_args, which may GC, before the stack is repaired. The fix is to move the stack repair code before calling buffer_value_args. I also added one test case that would reliably catch this type of error. Thanks - Ioi From tobias.hartmann at oracle.com Wed Jul 3 08:10:18 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 3 Jul 2019 10:10:18 +0200 Subject: RFR(S): 8227033: [lworld] Remove ACmpOnValues command line option In-Reply-To: <87pnmsa8ac.fsf@redhat.com> References: <77c73b5b-3f77-99ea-19c9-a596fe75958c@oracle.com> <87pnmsa8ac.fsf@redhat.com> Message-ID: <204ffe08-afaa-b6a8-6212-6a6f8a9e28ff@oracle.com> Hi Roland, On 02.07.19 15:13, Roland Westrelin wrote: > Is this: > > 1421 if (compiled) { > > still required? If I remember correctly I added it when the > substitutability test was only implemented by c2. Good catch, here's a new webrev: http://cr.openjdk.java.net/~thartmann/8227033/webrev.01/ Thanks, Tobias From rwestrel at redhat.com Wed Jul 3 08:13:09 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 03 Jul 2019 10:13:09 +0200 Subject: RFR(S): 8227033: [lworld] Remove ACmpOnValues command line option In-Reply-To: <204ffe08-afaa-b6a8-6212-6a6f8a9e28ff@oracle.com> References: <77c73b5b-3f77-99ea-19c9-a596fe75958c@oracle.com> <87pnmsa8ac.fsf@redhat.com> <204ffe08-afaa-b6a8-6212-6a6f8a9e28ff@oracle.com> Message-ID: <871rz7a63u.fsf@redhat.com> > Good catch, here's a new webrev: > http://cr.openjdk.java.net/~thartmann/8227033/webrev.01/ Good. Roland. From tobias.hartmann at oracle.com Wed Jul 3 08:20:24 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 3 Jul 2019 10:20:24 +0200 Subject: RFR(S): 8227033: [lworld] Remove ACmpOnValues command line option In-Reply-To: <871rz7a63u.fsf@redhat.com> References: <77c73b5b-3f77-99ea-19c9-a596fe75958c@oracle.com> <87pnmsa8ac.fsf@redhat.com> <204ffe08-afaa-b6a8-6212-6a6f8a9e28ff@oracle.com> <871rz7a63u.fsf@redhat.com> Message-ID: <9ad8ec2e-8110-ab79-ff56-76e68c527129@oracle.com> Thanks again! Best regards, Tobias On 03.07.19 10:13, Roland Westrelin wrote: > >> Good catch, here's a new webrev: >> http://cr.openjdk.java.net/~thartmann/8227033/webrev.01/ > > Good. > > Roland. > From tobias.hartmann at oracle.com Wed Jul 3 08:40:57 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 03 Jul 2019 08:40:57 +0000 Subject: hg: valhalla/valhalla: 8227033: [lworld] Remove ACmpOnValues command line option Message-ID: <201907030840.x638ewD2016415@aojmv0008.oracle.com> Changeset: 789a8a219886 Author: thartmann Date: 2019-07-03 10:40 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/789a8a219886 8227033: [lworld] Remove ACmpOnValues command line option Reviewed-by: roland ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/mulnode.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/subnode.cpp ! src/hotspot/share/opto/subnode.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNewAcmp.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/Ifacmp.java From tobias.hartmann at oracle.com Wed Jul 3 11:25:15 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 3 Jul 2019 13:25:15 +0200 Subject: RFR(M): 8222221: [lworld] Valhalla causes performance slowdown for reflective invocations In-Reply-To: <87muhwa6jo.fsf@redhat.com> References: <9e6f6e2e-9d6b-4731-7513-301b55822d50@oracle.com> <87muhwa6jo.fsf@redhat.com> Message-ID: <5a0512fd-14c4-7bc3-1f0c-a56e3391a74a@oracle.com> Hi Roland, thanks for the review! On 02.07.19 15:51, Roland Westrelin wrote: > Why drop stuff related to Compile::_type_hwm? Because it's unused code. > Why no check for is_not_flat() for the first generate_valueArray_guard > below? Because we only have a TypeKlassPtr from the array type mirror but no TypeAryPtr for the destination type. > Shouldn't the is_not_flat() test be in > generate_valueArray_guard()? > > 4042 Node* is_flat = generate_valueArray_guard(klass_node, NULL); > 4043 if (!original_t->is_not_flat()) { > 4044 generate_valueArray_guard(original_kls, bailout); > 4045 } generate_valueArray_guard takes a klass but the is_not_flat() check needs to be done on TypeAryPtr. > In Parse::array_store(), why remove: > > || elemptr->is_valuetypeptr() > > ? I don't think it's necessary, right? Either it is a null-free array and then !ary_t->klass_is_exact() holds or it is a null-ok array and then we don't need to go this path. > 253 Node *kls = load_object_klass(ary); > 254 Node *layout_val = load_lh_array_tag(kls); > > Isn't the usual coding convention Node* kls? It surely is, not sure why this got changed. Fixed. Added a missing call to remove_speculative() in parse1.cpp that caused a typesystem assert because 't' could already contain a speculative type. New webrev: http://cr.openjdk.java.net/~thartmann/8222221/webrev.01 Thanks, Tobias From tobias.hartmann at oracle.com Wed Jul 3 11:33:58 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 3 Jul 2019 13:33:58 +0200 Subject: RFR: 8224211:[lworld] Reflective method invocation fails with assert(sender_sp != sp()) failed: must have changed In-Reply-To: <87k1d0a54f.fsf@redhat.com> References: <87zhlxakp8.fsf@redhat.com> <87v9wkao6i.fsf@redhat.com> <87k1d0a54f.fsf@redhat.com> Message-ID: Hi Roland, looks good to me! Thanks, Tobias On 02.07.19 16:22, Roland Westrelin wrote: > > One more tweak: > > http://cr.openjdk.java.net/~roland/8224211/webrev.02/ > > Call result->set_jobject() right before the call itself. There could be > a gc between the allocation and the call that would not update the > result JavaValue. > > Roland. > From tobias.hartmann at oracle.com Wed Jul 3 11:56:13 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 3 Jul 2019 13:56:13 +0200 Subject: RFR 8227040 [lworld][c1] Must repair stack frame before calling buffer_value_args In-Reply-To: References: Message-ID: <12d6fca1-bca8-da1c-f824-2c80ee1049a0@oracle.com> Hi Ioi, looks good to me. Please re-align the comment in c1_MacroAssembler_x86.cpp:346 and 436. Thanks, Tobias On 03.07.19 07:13, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8227040 > http://cr.openjdk.java.net/~iklam/valhalla/8227040-repair-frame-before-buffer_value_args.v01/ > > When a C1-compiled method is called by C2, it needs to pack all the fields > of its value arguments back to buffered objects. In some cases, usually when the > value arguments have floating point fields, the C1 callee may require more > stack than what has been provided by the C2 caller. On x64, this is handled > by the following "stack repair" instructions in the "Verified Entry Point" > of the callee > > ??? pop %r13 > ??? sub ,%rsp > ??? push %r13 > ??? movq ,(%rsp) > > The stack must be repaired before it can be walked (for GC, etc). This bug > happens because we call Runtime1::buffer_value_args, which may GC, before > the stack is repaired. > > The fix is to move the stack repair code before calling buffer_value_args. > I also added one test case that would reliably catch this type of error. > > Thanks > - Ioi From rwestrel at redhat.com Wed Jul 3 12:08:22 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 03 Jul 2019 14:08:22 +0200 Subject: RFR(M): 8222221: [lworld] Valhalla causes performance slowdown for reflective invocations In-Reply-To: <5a0512fd-14c4-7bc3-1f0c-a56e3391a74a@oracle.com> References: <9e6f6e2e-9d6b-4731-7513-301b55822d50@oracle.com> <87muhwa6jo.fsf@redhat.com> <5a0512fd-14c4-7bc3-1f0c-a56e3391a74a@oracle.com> Message-ID: <87v9wj8gnd.fsf@redhat.com> > On 02.07.19 15:51, Roland Westrelin wrote: >> Why drop stuff related to Compile::_type_hwm? > > Because it's unused code. Would be nice to do that clean up upstream as well. >> Why no check for is_not_flat() for the first generate_valueArray_guard >> below? > Because we only have a TypeKlassPtr from the array type mirror but no TypeAryPtr for the destination > type. Ok. >> Shouldn't the is_not_flat() test be in >> generate_valueArray_guard()? >> >> 4042 Node* is_flat = generate_valueArray_guard(klass_node, NULL); >> 4043 if (!original_t->is_not_flat()) { >> 4044 generate_valueArray_guard(original_kls, bailout); >> 4045 } > > generate_valueArray_guard takes a klass but the is_not_flat() check needs to be done on TypeAryPtr. Maybe it would make sense to change the signature of generate_valueArray_guard() then so all is_not_flat() checks are in one location rather than duplicated in many places? Roland. From tobias.hartmann at oracle.com Wed Jul 3 12:18:38 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 3 Jul 2019 14:18:38 +0200 Subject: RFR(M): 8222221: [lworld] Valhalla causes performance slowdown for reflective invocations In-Reply-To: <87v9wj8gnd.fsf@redhat.com> References: <9e6f6e2e-9d6b-4731-7513-301b55822d50@oracle.com> <87muhwa6jo.fsf@redhat.com> <5a0512fd-14c4-7bc3-1f0c-a56e3391a74a@oracle.com> <87v9wj8gnd.fsf@redhat.com> Message-ID: <726dec4f-98ad-8164-b1d0-9b2646a9a12a@oracle.com> Thanks again for the review. On 03.07.19 14:08, Roland Westrelin wrote: > Would be nice to do that clean up upstream as well. Okay, I'll push that part upstream and remove it from the patch. > Maybe it would make sense to change the signature of > generate_valueArray_guard() then so all is_not_flat() checks are in one > location rather than duplicated in many places? As we've discussed off-thread, I'll leave it as is for now. Thanks, Tobias From tobias.hartmann at oracle.com Wed Jul 3 12:28:02 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 03 Jul 2019 12:28:02 +0000 Subject: hg: valhalla/valhalla: 8222221: [lworld] Valhalla causes performance slowdown for reflective invocations Message-ID: <201907031228.x63CS3wH022300@aojmv0008.oracle.com> Changeset: 598fb53656f9 Author: thartmann Date: 2019-07-03 14:27 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/598fb53656f9 8222221: [lworld] Valhalla causes performance slowdown for reflective invocations Reviewed-by: roland ! src/hotspot/share/ci/ciFlags.hpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/ci/ciSignature.cpp ! src/hotspot/share/opto/compile.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/macroArrayCopy.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNullableArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java From ioi.lam at oracle.com Wed Jul 3 16:29:44 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Wed, 03 Jul 2019 16:29:44 +0000 Subject: hg: valhalla/valhalla: 8227040: [lworld][c1] Must repair stack frame before calling buffer_value_args Message-ID: <201907031629.x63GTj0u015037@aojmv0008.oracle.com> Changeset: 3de42b2ccd6c Author: iklam Date: 2019-07-03 08:33 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/3de42b2ccd6c 8227040: [lworld][c1] Must repair stack frame before calling buffer_value_args Reviewed-by: thartmann ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestCallingConventionC1.java From ioi.lam at oracle.com Wed Jul 3 17:32:07 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 3 Jul 2019 10:32:07 -0700 Subject: RFR 8227040 [lworld][c1] Must repair stack frame before calling buffer_value_args In-Reply-To: <12d6fca1-bca8-da1c-f824-2c80ee1049a0@oracle.com> References: <12d6fca1-bca8-da1c-f824-2c80ee1049a0@oracle.com> Message-ID: <03440e5c-5a11-28e8-33e9-47f975608892@oracle.com> Hi Tobias Thanks for the review. I've fixed the comments and pushed. - Ioi On 7/3/19 4:56 AM, Tobias Hartmann wrote: > Hi Ioi, > > looks good to me. > > Please re-align the comment in c1_MacroAssembler_x86.cpp:346 and 436. > > Thanks, > Tobias > > On 03.07.19 07:13, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8227040 >> http://cr.openjdk.java.net/~iklam/valhalla/8227040-repair-frame-before-buffer_value_args.v01/ >> >> When a C1-compiled method is called by C2, it needs to pack all the fields >> of its value arguments back to buffered objects. In some cases, usually when the >> value arguments have floating point fields, the C1 callee may require more >> stack than what has been provided by the C2 caller. On x64, this is handled >> by the following "stack repair" instructions in the "Verified Entry Point" >> of the callee >> >> ??? pop %r13 >> ??? sub ,%rsp >> ??? push %r13 >> ??? movq ,(%rsp) >> >> The stack must be repaired before it can be walked (for GC, etc). This bug >> happens because we call Runtime1::buffer_value_args, which may GC, before >> the stack is repaired. >> >> The fix is to move the stack repair code before calling buffer_value_args. >> I also added one test case that would reliably catch this type of error. >> >> Thanks >> - Ioi From ioi.lam at oracle.com Thu Jul 4 04:10:56 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Thu, 04 Jul 2019 04:10:56 +0000 Subject: hg: valhalla/valhalla: 8227244: [lworld][c1] enqueueMethodForCompilation uses wrong level when testing with C1 only Message-ID: <201907040410.x644Au3c017794@aojmv0008.oracle.com> Changeset: 8def7598960f Author: iklam Date: 2019-07-03 21:09 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8def7598960f 8227244: [lworld][c1] enqueueMethodForCompilation uses wrong level when testing with C1 only ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestCallingConvention.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestMethodHandles.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNewAcmp.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNullableArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java From tobias.hartmann at oracle.com Thu Jul 4 08:02:24 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Thu, 04 Jul 2019 08:02:24 +0000 Subject: hg: valhalla/valhalla: 8227180: [lworld] C2 compilation fails with assert(f->is_flattened()) failed: should be flattened Message-ID: <201907040802.x6482P9K007883@aojmv0008.oracle.com> Changeset: 8f3d47dc49f6 Author: thartmann Date: 2019-07-04 10:02 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/8f3d47dc49f6 8227180: [lworld] C2 compilation fails with assert(f->is_flattened()) failed: should be flattened ! src/hotspot/share/opto/valuetypenode.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java From rwestrel at redhat.com Thu Jul 4 09:58:55 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 04 Jul 2019 11:58:55 +0200 Subject: RFR: 8222148: [lworld] Value type check(guard) causes not working lock coarsening optimization. Message-ID: <87muhu86jk.fsf@redhat.com> http://cr.openjdk.java.net/~roland/8222148/webrev.00/ This moves the test for a monitorenter on a value right before we enter the slow path call so it's mostly free. The change to runtime/init.cpp fixes printing of stubs generated by generate_return_value_stub() so it's possible to run benchmarks with -prof perfasm. Roland. From rwestrel at redhat.com Thu Jul 4 10:21:41 2019 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Thu, 04 Jul 2019 10:21:41 +0000 Subject: hg: valhalla/valhalla: 8224211: [lworld] Reflective method invocation fails with assert(sender_sp != sp()) failed: must have changed Message-ID: <201907041021.x64ALg4f022619@aojmv0008.oracle.com> Changeset: f33dcd923881 Author: roland Date: 2019-07-02 16:24 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/f33dcd923881 8224211: [lworld] Reflective method invocation fails with assert(sender_sp != sp()) failed: must have changed Reviewed-by: thartmann ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/runtime/javaCalls.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestCallingConvention.java From tobias.hartmann at oracle.com Thu Jul 4 11:35:11 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 4 Jul 2019 13:35:11 +0200 Subject: RFR: 8222148: [lworld] Value type check(guard) causes not working lock coarsening optimization. In-Reply-To: <87muhu86jk.fsf@redhat.com> References: <87muhu86jk.fsf@redhat.com> Message-ID: Hi Roland, looks good to me. Why did you remove the "inline" in macroArrayCopy.cpp? Best regards, Tobias On 04.07.19 11:58, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8222148/webrev.00/ > > This moves the test for a monitorenter on a value right before we enter > the slow path call so it's mostly free. The change to runtime/init.cpp > fixes printing of stubs generated by generate_return_value_stub() so > it's possible to run benchmarks with -prof perfasm. > > Roland. > From rwestrel at redhat.com Thu Jul 4 11:45:43 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 04 Jul 2019 13:45:43 +0200 Subject: RFR: 8222148: [lworld] Value type check(guard) causes not working lock coarsening optimization. In-Reply-To: References: <87muhu86jk.fsf@redhat.com> Message-ID: <87ef3681lk.fsf@redhat.com> Hi Tobias, > looks good to me. Why did you remove the "inline" in macroArrayCopy.cpp? Thanks for the review. Compilation fails because the symbol doesn't exist. Roland. From tobias.hartmann at oracle.com Thu Jul 4 12:14:30 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 4 Jul 2019 14:14:30 +0200 Subject: RFR: 8222148: [lworld] Value type check(guard) causes not working lock coarsening optimization. In-Reply-To: <87ef3681lk.fsf@redhat.com> References: <87muhu86jk.fsf@redhat.com> <87ef3681lk.fsf@redhat.com> Message-ID: On 04.07.19 13:45, Roland Westrelin wrote: > Thanks for the review. Compilation fails because the symbol doesn't exist. Okay, thanks for the explanation. Looks good. Best regards, Tobias From tobias.hartmann at oracle.com Thu Jul 4 13:06:55 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Thu, 04 Jul 2019 13:06:55 +0000 Subject: hg: valhalla/valhalla: 8227271: [lworld] C2 compilation fails when loading final value type field that is always null Message-ID: <201907041306.x64D6tkv027356@aojmv0008.oracle.com> Changeset: 287ec97efc90 Author: thartmann Date: 2019-07-04 15:06 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/287ec97efc90 8227271: [lworld] C2 compilation fails when loading final value type field that is always null ! src/hotspot/share/opto/graphKit.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNullableValueTypes.java From rwestrel at redhat.com Thu Jul 4 13:09:28 2019 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Thu, 04 Jul 2019 13:09:28 +0000 Subject: hg: valhalla/valhalla: 8222148: [lworld] Value type check(guard) causes not working lock coarsening optimization. Message-ID: <201907041309.x64D9TG4000267@aojmv0008.oracle.com> Changeset: 0f2e4c96b8a4 Author: roland Date: 2019-07-04 11:31 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/0f2e4c96b8a4 8222148: [lworld] Value type check(guard) causes not working lock coarsening optimization. Reviewed-by: thartmann ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/runtime/init.cpp From tobias.hartmann at oracle.com Thu Jul 4 14:36:24 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Thu, 04 Jul 2019 14:36:24 +0000 Subject: hg: valhalla/valhalla: 8227276: [lworld] C2 compilation fails with assert(i < field_count()) failed: field not found Message-ID: <201907041436.x64EaPxv016463@aojmv0008.oracle.com> Changeset: c090df0e6767 Author: thartmann Date: 2019-07-04 16:36 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/c090df0e6767 8227276: [lworld] C2 compilation fails with assert(i < field_count()) failed: field not found ! src/hotspot/share/opto/valuetypenode.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestBasicFunctionality.java From dms at samersoff.net Thu Jul 4 17:41:59 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Thu, 4 Jul 2019 20:41:59 +0300 Subject: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> Message-ID: <354e6f5e-bce5-1423-0f20-18e016e2ec3d@samersoff.net> Hello Everybody, I rebased the fix one more time, to lworld_stable tag. -Dmitry On 27.06.2019 10:43, Dmitry Samersoff wrote: > Hello Everybody, > > > Please review v.05 of adding AArch64 support to lworld branch > > http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.05/ > > What was done: > > Implemented Valhalla support for aarch64. > > Support for ValueTypePassFieldsAsArgs and ValueTypeReturnedAsFields > is not completed and is not included into this webrev > to reduce review and rebasing efforts. > > Testing: > > All tests in runtime/valhalla/valuetypes and in > compiler/valhalla/valuetypes/ are passed > > compiler/valhalla/valuetypes/TestMethodHandles.java > compiler/valhalla/valuetypes/TestBasicFunctionality.java > > are passed after manually tweaking of output patterns, I have not > found a way to support both x86 and aarch64, so these tests remain > unchanged and run on x64 only. > > > -Dmitry > From dms at samersoff.net Thu Jul 4 18:01:27 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Thu, 4 Jul 2019 21:01:27 +0300 Subject: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> Message-ID: <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> Ioi, After last rebase the test TestFlatArrayThreshold start failing: java.lang.RuntimeException: NullPointerException expected at TestFlatArrayThreshold.main(TestFlatArrayThreshold.java:128) i.e. when we pass null to: public static MyValue1? test2(MyValue1?[] va, MyValue1? vt) { va[0] = vt; return va[1]; } It fails if ValueKlass::flatten_array() returns false, but passes if it returns true. It also passes wit -Xint Do you know where I should look for the problem? I didn't find any obvious platfrom-specific changes. -Dmitry On 27.06.2019 19:09, Ioi Lam wrote: > Hi Dmitry, > > During the port, have you found anything that should be refactored and > put into shared code? > > One thing that I am thinking of doing is to refactor the code in > macroAssembler_x86.cpp that deals with ValueTypePassFieldsAsArgs. > Hopefully that will make the port to other architectures easier. > > Thanks > - Ioi > > > On 6/27/19 12:43 AM, Dmitry Samersoff wrote: >> Hello Everybody, >> >> >> Please review v.05 of adding AArch64 support to lworld branch >> >> http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.05/ >> >> What was done: >> >> ?? Implemented Valhalla support for aarch64. >> >> ?? Support for ValueTypePassFieldsAsArgs and ValueTypeReturnedAsFields >> ?? is not completed and is not included into this webrev >> ?? to reduce review and rebasing efforts. >> >> Testing: >> >> ??? All tests in runtime/valhalla/valuetypes and in >> compiler/valhalla/valuetypes/ are passed >> >> ??? compiler/valhalla/valuetypes/TestMethodHandles.java >> ??? compiler/valhalla/valuetypes/TestBasicFunctionality.java >> >> ??? are passed after manually tweaking of output patterns, I have not >> found a way to support both x86 and aarch64, so these tests remain >> unchanged and run on x64 only. >> >> >> -Dmitry > From ioi.lam at oracle.com Fri Jul 5 05:14:30 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 4 Jul 2019 22:14:30 -0700 Subject: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> Message-ID: <0a672201-788c-02b1-a27d-21556f5b6455@oracle.com> So the AArch64 port fails but the x64 port passes? I just tested on x64 and the test passed for me. I would suggest running both ports side-by-side with gdb, and see when the behavior starts to diverge. To help debugging, you can try to strip down TestFlatArrayThreshold.java to the minimum and also pass -XX:CompileCommand=compileonly,*::test2 -XX:CompileCommand=print,*::test2 to the @run line. Thanks - Ioi On 7/4/19 11:01 AM, Dmitry Samersoff wrote: > Ioi, > > After last rebase the test TestFlatArrayThreshold start failing: > > java.lang.RuntimeException: NullPointerException expected > at TestFlatArrayThreshold.main(TestFlatArrayThreshold.java:128) > > i.e. when we pass null to: > > public static MyValue1? test2(MyValue1?[] va, MyValue1? vt) { > va[0] = vt; > return va[1]; > } > > It fails if ValueKlass::flatten_array() returns false, > but passes if it returns true. It also passes wit -Xint > > Do you know where I should look for the problem? I didn't find any > obvious platfrom-specific changes. > > -Dmitry > > On 27.06.2019 19:09, Ioi Lam wrote: >> Hi Dmitry, >> >> During the port, have you found anything that should be refactored and >> put into shared code? >> >> One thing that I am thinking of doing is to refactor the code in >> macroAssembler_x86.cpp that deals with ValueTypePassFieldsAsArgs. >> Hopefully that will make the port to other architectures easier. >> >> Thanks >> - Ioi >> >> >> On 6/27/19 12:43 AM, Dmitry Samersoff wrote: >>> Hello Everybody, >>> >>> >>> Please review v.05 of adding AArch64 support to lworld branch >>> >>> http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.05/ >>> >>> What was done: >>> >>> ?? Implemented Valhalla support for aarch64. >>> >>> ?? Support for ValueTypePassFieldsAsArgs and ValueTypeReturnedAsFields >>> ?? is not completed and is not included into this webrev >>> ?? to reduce review and rebasing efforts. >>> >>> Testing: >>> >>> ??? All tests in runtime/valhalla/valuetypes and in >>> compiler/valhalla/valuetypes/ are passed >>> >>> ??? compiler/valhalla/valuetypes/TestMethodHandles.java >>> ??? compiler/valhalla/valuetypes/TestBasicFunctionality.java >>> >>> ??? are passed after manually tweaking of output patterns, I have not >>> found a way to support both x86 and aarch64, so these tests remain >>> unchanged and run on x64 only. >>> >>> >>> -Dmitry From david.simms at oracle.com Fri Jul 5 09:53:51 2019 From: david.simms at oracle.com (david.simms at oracle.com) Date: Fri, 05 Jul 2019 09:53:51 +0000 Subject: hg: valhalla/valhalla: [lworld] LW2 EA branch Message-ID: <201907050953.x659rqFN017592@aojmv0008.oracle.com> Changeset: d5bf185cc738 Author: dsimms Date: 2019-07-05 11:53 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d5bf185cc738 [lworld] LW2 EA branch From david.simms at oracle.com Fri Jul 5 10:08:37 2019 From: david.simms at oracle.com (David Simms) Date: Fri, 5 Jul 2019 12:08:37 +0200 Subject: L-World LW2 EA binaries now available Message-ID: <0e483ea5-2aa2-e415-68c3-defde4ae4530@oracle.com> The next step in the L-World [1] series of Valhalla prototypes, "LW2" [2] is now available from: http://jdk.java.net/valhalla/ * Initially we are looking for feedback on the user model. * There are a number limitations listed on download page and OpenJDK wiki [2]. * We are looking to periodically refresh the binaries with bug fixes and performance updates (a new build should be available later today in fact) Thanks to all involved /Valhalla Project Team [1] https://wiki.openjdk.java.net/display/valhalla/L-World [2] https://wiki.openjdk.java.net/display/valhalla/LW2 From david.simms at oracle.com Fri Jul 5 10:16:21 2019 From: david.simms at oracle.com (David Simms) Date: Fri, 5 Jul 2019 12:16:21 +0200 Subject: Valhalla project repository status: Branched off "LW2" Message-ID: <5781c0a6-bc00-f3d0-16c0-3d6e95578085@oracle.com> Some recent changes to the Valhalla Project repository: http://hg.openjdk.java.net/valhalla/valhalla/ Named branch "lw2" has been created to allow further changes in "lworld" without affecting the stability of LW2 EA Current branches (hg branches)... * default: periodically updated copy of jdk/jdk (i.e. JDK mainline, http://hg.openjdk.java.net/jdk, contains no project changes) * exp: ad-hoc experimental branch for various collaboration efforts (not currently used) * lworld: LWorld series of prototype, receives updates (merges) from "default" (Current prototyping work) * lw1: LW1 minimal LWorld prototype, (Dead release branch) * lw2: LW2 L-World inline-types prototype * mvt: Minimal Value Types prototype, (Dead release branch) * nestmates: Nest-Based access control work(JEP 181) Cheers /David Simms From tobias.hartmann at oracle.com Fri Jul 5 12:34:37 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 5 Jul 2019 14:34:37 +0200 Subject: RFR(S): 8227310: [lworld] Fix diagnostic flag -XX:ScalarizeValueTypes Message-ID: Hi, please review the following patch that fixes the diagnostic flag -XX:ScalarizeValueTypes: https://bugs.openjdk.java.net/browse/JDK-8227310 http://cr.openjdk.java.net/~thartmann/8227310/webrev.00/ The patch also includes some refactoring of related code. Thanks, Tobias From brian.goetz at oracle.com Fri Jul 5 16:24:18 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 5 Jul 2019 12:24:18 -0400 Subject: Bug report with lworld / jshell Message-ID: In JShell, I did the following: jshell -C-XDallowGenericsOverValues |? Welcome to JShell -- Version 14-internal |? For an introduction type: /help intro jshell> inline class V { int x; int y; V(int x, int y) { this.x = x; this.y = y; } } |? Warning: |? Modifier 'final' not permitted in top-level declarations, ignored |? inline class V { int x; int y; V(int x, int y) { this.x = x; this.y = y; } } | ^--------------------------------------------------------------------------^ |? created class V // The warning is confusing, but not terrible. jshell> V v = new V(1,2) v ==> [V x=1 y=2] jshell> V? vv = v vv ==> [V x=1 y=2] jshell> v v ==> [V x=1 y=2] jshell> vv |? Exception java.lang.NoSuchFieldError: vv |??????? at (#5:1) The last seems a JShell bug. From graphhopper at gmx.de Sat Jul 6 23:40:51 2019 From: graphhopper at gmx.de (Peter) Date: Sun, 7 Jul 2019 01:40:51 +0200 Subject: Error Message: value -> inline Message-ID: <00447e87-ba88-417c-d4bf-3f60adab7648@gmx.de> Hi, I'm currently playing with the prototype of Project Valhalla - thanks for your huge work! I've studied the tests but is more documentation or better examples what is currently possible? E.g. I think that primitive lists like List is not yet possible - is this right? Now I caught an error message that needs a small change. With: inline class Point { double lat; double lon; } inline class Point3d { double ele; inline Point point; } I get: Point3d.java:[5,25] modifier value not allowed here instead of: Point3d.java:[5,25] modifier inline not allowed here Regards Peter From forax at univ-mlv.fr Sun Jul 7 09:38:20 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 7 Jul 2019 11:38:20 +0200 (CEST) Subject: Error Message: value -> inline In-Reply-To: <00447e87-ba88-417c-d4bf-3f60adab7648@gmx.de> References: <00447e87-ba88-417c-d4bf-3f60adab7648@gmx.de> Message-ID: <1964708750.3531534.1562492300957.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Peter" > ?: "valhalla-dev" > Envoy?: Dimanche 7 Juillet 2019 01:40:51 > Objet: Error Message: value -> inline > Hi, Hi > > I'm currently playing with the prototype of Project Valhalla - thanks > for your huge work! > > I've studied the tests but is more documentation or better examples what > is currently possible? E.g. I think that primitive lists like List > is not yet possible - is this right? yes, no specialized generics yet ! you have more examples here: https://github.com/forax/valuetype-lworld > > Now I caught an error message that needs a small change. With: > > inline class Point { double lat; double lon; } > inline class Point3d { double ele; inline Point point; } > > I get: > > Point3d.java:[5,25] modifier value not allowed here > > instead of: > > Point3d.java:[5,25] modifier inline not allowed here > > Regards > Peter cheers, R?mi From ioi.lam at oracle.com Mon Jul 8 04:00:38 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 7 Jul 2019 21:00:38 -0700 Subject: RFR 8226921 [lworld] Refactor argument shuffling code for ValueTypePassFieldsAsArgs In-Reply-To: References: Message-ID: Hi Dmitry, Did you get a chance to use the code? If you don't see any big issues, I am thinking of pushing it to avoid code rot. We can do further refactoring if necessary when you implement the Aarch64 port. Thanks - Ioi On 6/28/19 12:31 AM, Dmitry Samersoff wrote: > Hi Ioi, > > Flicked through your patch - Very Cool! > > I'll apply it and check what is happening on aarch64 early next week. > > -Dmitry > > On 28.06.19 08:16, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8226921 >> http://cr.openjdk.java.net/~iklam/valhalla/8226921-refactor-ValueTypePassFieldsAsArgs-args-shuffling.v01/ >> >> >> Hi Dmitry, >> >> Could you try this patch and see if it works for the aarch64 port? >> >> To make it compile, you have to add these declaration into >> macroAssembler_aarch64.hpp: >> >> ? bool move_helper(VMReg from, VMReg to, BasicType bt, RegState >> reg_state[], int ret_off, int extra_stack_offset); >> ? bool unpack_value_helper(const GrowableArray* sig, int& >> sig_index, VMReg from, VMRegPair* regs_to, int& to_index, >> ?????????????????????????? RegState reg_state[], int ret_off, int >> extra_stack_offset); >> ? bool pack_value_helper(const GrowableArray* sig, int& >> sig_index, int vtarg_index, >> ???????????????????????? VMReg to, VMRegPair* regs_from, int >> regs_from_count, int& from_index, RegState reg_state[], >> ???????????????????????? int ret_off, int extra_stack_offset); >> ? int shuffle_value_args(bool is_packing, bool receiver_only, int >> extra_stack_offset, >> ???????????????????????? BasicType* sig_bt, const >> GrowableArray* sig_cc, >> ???????????????????????? int args_passed, int args_on_stack, VMRegPair* >> regs, >> ???????????????????????? int args_passed_to, int args_on_stack_to, >> VMRegPair* regs_to); >> ? VMReg spill_reg_for(VMReg reg); >> >> I think I have removed all x64-ism from macroAssembler_common.cpp, but >> I have no way of verifying that :-( >> >> I ran all the Valhalla tests on my linux/x64 boxes and saw no regression. >> >> Thanks >> - Ioi >> From srikanth.adayapalam at oracle.com Mon Jul 8 05:28:19 2019 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Mon, 8 Jul 2019 10:58:19 +0530 Subject: Bug report with lworld / jshell In-Reply-To: References: Message-ID: <46d234fc-99db-8113-c2c4-f8de2b957e46@oracle.com> Thanks Brian, I will follow up. Srikanth On 05/07/19 9:54 PM, Brian Goetz wrote: > In JShell, I did the following: > > jshell -C-XDallowGenericsOverValues > |? Welcome to JShell -- Version 14-internal > |? For an introduction type: /help intro > > jshell> inline class V { int x; int y; V(int x, int y) { this.x = x; > this.y = y; } } > |? Warning: > |? Modifier 'final' not permitted in top-level declarations, ignored > |? inline class V { int x; int y; V(int x, int y) { this.x = x; this.y > = y; } } > | > ^--------------------------------------------------------------------------^ > |? created class V > > // The warning is confusing, but not terrible. > > jshell> V v = new V(1,2) > v ==> [V x=1 y=2] > > jshell> V? vv = v > vv ==> [V x=1 y=2] > > jshell> v > v ==> [V x=1 y=2] > > jshell> vv > |? Exception java.lang.NoSuchFieldError: vv > |??????? at (#5:1) > > The last seems a JShell bug. > > From srikanth.adayapalam at oracle.com Mon Jul 8 05:31:01 2019 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Mon, 8 Jul 2019 11:01:01 +0530 Subject: Error Message: value -> inline In-Reply-To: <00447e87-ba88-417c-d4bf-3f60adab7648@gmx.de> References: <00447e87-ba88-417c-d4bf-3f60adab7648@gmx.de> Message-ID: <6e94885a-9c2a-30c2-ffcc-affbd560e0b7@oracle.com> Thanks for the report, I will follow up. Thanks! Srikanth On 07/07/19 5:10 AM, Peter wrote: > Hi, > > I'm currently playing with the prototype of Project Valhalla - thanks > for your huge work! > > I've studied the tests but is more documentation or better examples what > is currently possible? E.g. I think that primitive lists like List > is not yet possible - is this right? > > Now I caught an error message that needs a small change. With: > > inline class Point { double lat; double lon; } > inline class Point3d { double ele; inline Point point; } > > I get: > > Point3d.java:[5,25] modifier value not allowed here > > instead of: > > Point3d.java:[5,25] modifier inline not allowed here > > Regards > Peter > From ioi.lam at oracle.com Mon Jul 8 06:09:45 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 7 Jul 2019 23:09:45 -0700 Subject: RFR 8224944 [lworld] TestCallingConventionC1::test63 fails with -Xcomp Message-ID: https://bugs.openjdk.java.net/browse/JDK-8224944 http://cr.openjdk.java.net/~iklam/valhalla/8224944-c1-incorrect-vvep-ro-sharing.v01/ C1 tries to save space by avoiding the generation of the VVEP(RO) entry. However, in some cases we cannot re-use the VEP for VVEP(RO) -- when some parameters are passed on the stack, VEP has reserved entries, but VVEP(RO) doesn't. I also fixed the printing of the nmethod entry point names after merging with JDK-8213084 (Rework and enhance Print[Opto]Assembly output). Thanks - Ioi From tobias.hartmann at oracle.com Mon Jul 8 07:01:55 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 8 Jul 2019 09:01:55 +0200 Subject: RFR 8224944 [lworld] TestCallingConventionC1::test63 fails with -Xcomp In-Reply-To: References: Message-ID: <764449d5-3cc7-b2ad-5408-51c8e1d1ced2@oracle.com> Hi Ioi, Looks good! Some small things: - I think you've missed some debug code in c1_LIRAssembler.cpp:661. - sharedRuntime.cpp:2841 Excess whitespace after "!=" - sharedRuntime.cpp:2844 inset -> insert Best regards, Tobias On 08.07.19 08:09, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8224944 > http://cr.openjdk.java.net/~iklam/valhalla/8224944-c1-incorrect-vvep-ro-sharing.v01/ > > C1 tries to save space by avoiding the generation of the VVEP(RO) entry. However, > in some cases we cannot re-use the VEP for VVEP(RO) -- when some parameters are > passed on the stack, VEP has reserved entries, but VVEP(RO) doesn't. > > I also fixed the printing of the nmethod entry point names after merging with > JDK-8213084 (Rework and enhance Print[Opto]Assembly output). > > Thanks > - Ioi > > > > From rwestrel at redhat.com Mon Jul 8 07:35:01 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 08 Jul 2019 09:35:01 +0200 Subject: RFR(S): 8227310: [lworld] Fix diagnostic flag -XX:ScalarizeValueTypes In-Reply-To: References: Message-ID: <87lfx96kt6.fsf@redhat.com> > http://cr.openjdk.java.net/~thartmann/8227310/webrev.00/ Good. Roland. From tobias.hartmann at oracle.com Mon Jul 8 07:36:10 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 8 Jul 2019 09:36:10 +0200 Subject: RFR(S): 8227310: [lworld] Fix diagnostic flag -XX:ScalarizeValueTypes In-Reply-To: <87lfx96kt6.fsf@redhat.com> References: <87lfx96kt6.fsf@redhat.com> Message-ID: <9ddf9a42-c9f2-3420-90c2-5fd00390ea64@oracle.com> Thanks Roland! Best regards, Tobias On 08.07.19 09:35, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8227310/webrev.00/ > > Good. > > Roland. > From tobias.hartmann at oracle.com Mon Jul 8 07:37:11 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 08 Jul 2019 07:37:11 +0000 Subject: hg: valhalla/valhalla: 8227310: [lworld] Fix diagnostic flag -XX:ScalarizeValueTypes Message-ID: <201907080737.x687bCek016266@aojmv0008.oracle.com> Changeset: 72ea1440e86f Author: thartmann Date: 2019-07-08 09:36 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/72ea1440e86f 8227310: [lworld] Fix diagnostic flag -XX:ScalarizeValueTypes Reviewed-by: roland ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/ci/ciValueKlass.cpp ! src/hotspot/share/oops/valueKlass.cpp ! src/hotspot/share/oops/valueKlass.hpp ! src/hotspot/share/opto/parseHelper.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/runtime/fieldDescriptor.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/signature.hpp From graphhopper at gmx.de Mon Jul 8 08:49:45 2019 From: graphhopper at gmx.de (Peter) Date: Mon, 8 Jul 2019 10:49:45 +0200 Subject: Error Message: value -> inline In-Reply-To: <1964708750.3531534.1562492300957.JavaMail.zimbra@u-pem.fr> References: <00447e87-ba88-417c-d4bf-3f60adab7648@gmx.de> <1964708750.3531534.1562492300957.JavaMail.zimbra@u-pem.fr> Message-ID: <2bf4ebfe-d408-52a8-571c-4cfc61d76830@gmx.de> Hello Remi, Thanks, also for the link! The code for your ArrayList looks very crazy :) ... what is the reason for that? And Java's ArrayList is not as good because it has Object[] instead of E[]? Or would be more changes necessary to make it memory efficient for inline types? Regards Peter On 07.07.19 11:38, Remi Forax wrote: > ----- Mail original ----- >> De: "Peter" >> ?: "valhalla-dev" >> Envoy?: Dimanche 7 Juillet 2019 01:40:51 >> Objet: Error Message: value -> inline >> Hi, > Hi > >> I'm currently playing with the prototype of Project Valhalla - thanks >> for your huge work! >> >> I've studied the tests but is more documentation or better examples what >> is currently possible? E.g. I think that primitive lists like List >> is not yet possible - is this right? > yes, > no specialized generics yet ! > > you have more examples here: > https://github.com/forax/valuetype-lworld > >> Now I caught an error message that needs a small change. With: >> >> inline class Point { double lat; double lon; } >> inline class Point3d { double ele; inline Point point; } >> >> I get: >> >> Point3d.java:[5,25] modifier value not allowed here >> >> instead of: >> >> Point3d.java:[5,25] modifier inline not allowed here >> >> Regards >> Peter > cheers, > R?mi -- GraphHopper.com - fast and flexible route planning From dms at samersoff.net Mon Jul 8 08:56:08 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Mon, 8 Jul 2019 11:56:08 +0300 Subject: RFR 8226921 [lworld] Refactor argument shuffling code for ValueTypePassFieldsAsArgs In-Reply-To: References: Message-ID: Ioi, Sorry for delay. The code works on aarch64, so please push it. -Dmitry On 08.07.19 07:00, Ioi Lam wrote: > Hi Dmitry, > > Did you get a chance to use the code? If you don't see any big issues, I > am thinking of pushing it to avoid code rot. We can do further > refactoring if necessary when you implement the Aarch64 port. > > Thanks > - Ioi > > On 6/28/19 12:31 AM, Dmitry Samersoff wrote: >> Hi Ioi, >> >> Flicked through your patch - Very Cool! >> >> I'll apply it and check what is happening on aarch64 early next week. >> >> -Dmitry >> >> On 28.06.19 08:16, Ioi Lam wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8226921 >>> http://cr.openjdk.java.net/~iklam/valhalla/8226921-refactor-ValueTypePassFieldsAsArgs-args-shuffling.v01/ >>> >>> >>> >>> Hi Dmitry, >>> >>> Could you try this patch and see if it works for the aarch64 port? >>> >>> To make it compile, you have to add these declaration into >>> macroAssembler_aarch64.hpp: >>> >>> ?? bool move_helper(VMReg from, VMReg to, BasicType bt, RegState >>> reg_state[], int ret_off, int extra_stack_offset); >>> ?? bool unpack_value_helper(const GrowableArray* sig, int& >>> sig_index, VMReg from, VMRegPair* regs_to, int& to_index, >>> ??????????????????????????? RegState reg_state[], int ret_off, int >>> extra_stack_offset); >>> ?? bool pack_value_helper(const GrowableArray* sig, int& >>> sig_index, int vtarg_index, >>> ????????????????????????? VMReg to, VMRegPair* regs_from, int >>> regs_from_count, int& from_index, RegState reg_state[], >>> ????????????????????????? int ret_off, int extra_stack_offset); >>> ?? int shuffle_value_args(bool is_packing, bool receiver_only, int >>> extra_stack_offset, >>> ????????????????????????? BasicType* sig_bt, const >>> GrowableArray* sig_cc, >>> ????????????????????????? int args_passed, int args_on_stack, VMRegPair* >>> regs, >>> ????????????????????????? int args_passed_to, int args_on_stack_to, >>> VMRegPair* regs_to); >>> ?? VMReg spill_reg_for(VMReg reg); >>> >>> I think I have removed all x64-ism from macroAssembler_common.cpp, but >>> I have no way of verifying that :-( >>> >>> I ran all the Valhalla tests on my linux/x64 boxes and saw no >>> regression. >>> >>> Thanks >>> - Ioi >>> > From srikanth.adayapalam at oracle.com Mon Jul 8 09:35:11 2019 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Mon, 08 Jul 2019 09:35:11 +0000 Subject: hg: valhalla/valhalla: 8227385: [lworld] Confusing error message when using inline types with --release 13 Message-ID: <201907080935.x689ZCTT011071@aojmv0008.oracle.com> Changeset: 38785edfce2d Author: sadayapalam Date: 2019-07-08 15:03 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/38785edfce2d 8227385: [lworld] Confusing error message when using inline types with --release 13 ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.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/ValuesNotSupported.java From srikanth.adayapalam at oracle.com Mon Jul 8 10:16:01 2019 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Mon, 08 Jul 2019 10:16:01 +0000 Subject: hg: valhalla/valhalla: 8227388: [lworld] Javac still emits error messages that refer to value modifier Message-ID: <201907081016.x68AG2ee002219@aojmv0008.oracle.com> Changeset: 26565ccbd719 Author: sadayapalam Date: 2019-07-08 15:45 +0530 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/26565ccbd719 8227388: [lworld] Javac still emits error messages that refer to value modifier ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! test/langtools/tools/javac/valhalla/lworld-values/CheckMakeDefault.out ! test/langtools/tools/javac/valhalla/lworld-values/CheckValueModifier.out ! test/langtools/tools/javac/valhalla/lworld-values/IllegalByValueTest.out ! test/langtools/tools/javac/valhalla/lworld-values/InlineAnnotationOnAnonymousClass.out ! test/langtools/tools/javac/valhalla/lworld-values/InlineAnnotationTest.out ! test/langtools/tools/javac/valhalla/lworld-values/ValueAnnotationOnAnonymousClass.out ! test/langtools/tools/javac/valhalla/lworld-values/ValueAnnotationTest.out From dms at samersoff.net Mon Jul 8 14:46:44 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Mon, 8 Jul 2019 17:46:44 +0300 Subject: Flat Array null check issue - Re: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <0a672201-788c-02b1-a27d-21556f5b6455@oracle.com> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> <0a672201-788c-02b1-a27d-21556f5b6455@oracle.com> Message-ID: <6b286a81-6be4-09fe-9313-03274d2ba06e@samersoff.net> Hello Rolland, Ioi I narrowed the problem (below) to: GraphKit::gen_value_array_null_guard and following replacement of GetNullFreeProperty in compile.cpp Interpreter in a similar place uses the code (below): ldrw(dst, Address(src, oopDesc::klass_offset_in_bytes())); asrw(dst, dst, oopDesc::narrow_storage_props_shift); andr(dst, dst, ArrayStorageProperties::null_free_value); cbnz(dst, is_null_free_array); but C2 does: # LoadNKlass node ldrw $dst, $mem andr $dst, $dst, oopDesc::compressed_klass_mask() #AndINode andr $dst, 1 << (oopDesc::narrow_storage_props_shift + ArrayStorageProperties::null_free_bit); # cmpI cbz(temp_reg, is_null_free_array); Is it correct? Do you have any ideas how to go forward with it? -Dmitry On 05.07.19 08:14, Ioi Lam wrote: > So the AArch64 port fails but the x64 port passes? I just tested on x64 > and the test passed for me. > > I would suggest running both ports side-by-side with gdb, and see when > the behavior starts to diverge. > > To help debugging, you can try to strip down TestFlatArrayThreshold.java > to the minimum and also pass -XX:CompileCommand=compileonly,*::test2 > -XX:CompileCommand=print,*::test2 to the @run line. > > Thanks > - Ioi > > On 7/4/19 11:01 AM, Dmitry Samersoff wrote: >> Ioi, >> >> After last rebase the test TestFlatArrayThreshold start failing: >> >> java.lang.RuntimeException: NullPointerException expected >> ???????? at TestFlatArrayThreshold.main(TestFlatArrayThreshold.java:128) >> >> i.e. when we pass null to: >> >> ? public static MyValue1? test2(MyValue1?[] va, MyValue1? vt) { >> ???????? va[0] = vt; >> ???????? return va[1]; >> ???? } >> >> It fails if ValueKlass::flatten_array() returns false, >> but passes if it returns true. It also passes wit -Xint >> >> Do you know where I should look for the problem? I didn't find any >> obvious platfrom-specific changes. >> >> -Dmitry >> >> On 27.06.2019 19:09, Ioi Lam wrote: >>> Hi Dmitry, >>> >>> During the port, have you found anything that should be refactored and >>> put into shared code? >>> >>> One thing that I am thinking of doing is to refactor the code in >>> macroAssembler_x86.cpp that deals with ValueTypePassFieldsAsArgs. >>> Hopefully that will make the port to other architectures easier. >>> >>> Thanks >>> - Ioi >>> >>> >>> On 6/27/19 12:43 AM, Dmitry Samersoff wrote: >>>> Hello Everybody, >>>> >>>> >>>> Please review v.05 of adding AArch64 support to lworld branch >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.05/ >>>> >>>> >>>> What was done: >>>> >>>> ??? Implemented Valhalla support for aarch64. >>>> >>>> ??? Support for ValueTypePassFieldsAsArgs and ValueTypeReturnedAsFields >>>> ??? is not completed and is not included into this webrev >>>> ??? to reduce review and rebasing efforts. >>>> >>>> Testing: >>>> >>>> ???? All tests in runtime/valhalla/valuetypes and in >>>> compiler/valhalla/valuetypes/ are passed >>>> >>>> ???? compiler/valhalla/valuetypes/TestMethodHandles.java >>>> ???? compiler/valhalla/valuetypes/TestBasicFunctionality.java >>>> >>>> ???? are passed after manually tweaking of output patterns, I have not >>>> found a way to support both x86 and aarch64, so these tests remain >>>> unchanged and run on x64 only. >>>> >>>> >>>> -Dmitry > From tobias.hartmann at oracle.com Mon Jul 8 15:21:59 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 08 Jul 2019 15:21:59 +0000 Subject: hg: valhalla/valhalla: 8227396: [lworld] C2 compilation fails with assert(is_ValueType()) failed: invalid node class Message-ID: <201907081522.x68FM0X8020927@aojmv0008.oracle.com> Changeset: 05a6bd4d7e5e Author: thartmann Date: 2019-07-08 17:21 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/05a6bd4d7e5e 8227396: [lworld] C2 compilation fails with assert(is_ValueType()) failed: invalid node class ! src/hotspot/share/opto/graphKit.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNullableValueTypes.java From forax at univ-mlv.fr Mon Jul 8 17:48:43 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 8 Jul 2019 19:48:43 +0200 (CEST) Subject: Error Message: value -> inline In-Reply-To: <2bf4ebfe-d408-52a8-571c-4cfc61d76830@gmx.de> References: <00447e87-ba88-417c-d4bf-3f60adab7648@gmx.de> <1964708750.3531534.1562492300957.JavaMail.zimbra@u-pem.fr> <2bf4ebfe-d408-52a8-571c-4cfc61d76830@gmx.de> Message-ID: <2020450143.355039.1562608123775.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Peter" > ?: "Remi Forax" > Cc: "valhalla-dev" > Envoy?: Lundi 8 Juillet 2019 10:49:45 > Objet: Re: Error Message: value -> inline > Hello Remi, > > Thanks, also for the link! > > The code for your ArrayList looks very crazy :) ... what is the reason > for that? yes, it's a research code not a use case code :) There are several layers to introduce reified generics, roughly 3 levels level 1: we need to have reified type accessible from the VM opcodes level 2: at runtime, we need different constant pools (or parts of the constant pool) for the same class (species) level 3: we need a way to have several specialized methods and activate/deactivate them This code test the level 1, the code is weird because it emulates the VM opcodes in Java (we have used a similar technique in the past when introducing invokedynamic). In term of expressiveness, you have parameterized classes/methods done at compile time only using the stack, so no runtime support for wildcards/raw types/dynamic cast from Object. > > And Java's ArrayList is not as good because it has Object[] instead of > E[]? Or would be more changes necessary to make it memory efficient for > inline types? ArrayList is special because the VM already allows E[] (Object[] at runtime) to be an array of indirect types or an array of inline types, so a quick hack is to have a constructor that take a class as argument and use it to create the array. see https://github.com/forax/valuetype-lworld/blob/master/src/main/java/fr.umlv.valuetype/fr/umlv/valuetype/ReifiedList.java But this trick doesn't work when your data structure need an internal class with one of its field being either an indirect type or an inline type, in that case, you have to modify the VM to teach it what i've called the level 2. > > Regards > Peter regards, R?mi > > On 07.07.19 11:38, Remi Forax wrote: >> ----- Mail original ----- >>> De: "Peter" >>> ?: "valhalla-dev" >>> Envoy?: Dimanche 7 Juillet 2019 01:40:51 >>> Objet: Error Message: value -> inline >>> Hi, >> Hi >> >>> I'm currently playing with the prototype of Project Valhalla - thanks >>> for your huge work! >>> >>> I've studied the tests but is more documentation or better examples what >>> is currently possible? E.g. I think that primitive lists like List >>> is not yet possible - is this right? >> yes, >> no specialized generics yet ! >> >> you have more examples here: >> https://github.com/forax/valuetype-lworld >> >>> Now I caught an error message that needs a small change. With: >>> >>> inline class Point { double lat; double lon; } >>> inline class Point3d { double ele; inline Point point; } >>> >>> I get: >>> >>> Point3d.java:[5,25] modifier value not allowed here >>> >>> instead of: >>> >>> Point3d.java:[5,25] modifier inline not allowed here >>> >>> Regards >>> Peter >> cheers, >> R?mi > > > -- > GraphHopper.com - fast and flexible route planning From ioi.lam at oracle.com Mon Jul 8 19:53:53 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 8 Jul 2019 12:53:53 -0700 Subject: RFR 8224944 [lworld] TestCallingConventionC1::test63 fails with -Xcomp In-Reply-To: <764449d5-3cc7-b2ad-5408-51c8e1d1ced2@oracle.com> References: <764449d5-3cc7-b2ad-5408-51c8e1d1ced2@oracle.com> Message-ID: <8f8bc455-41a5-71b1-cdcd-68faa3c596da@oracle.com> Hi Tobias, Thanks for the review. I will fix the following and push. - Ioi On 7/8/19 12:01 AM, Tobias Hartmann wrote: > Hi Ioi, > > Looks good! > > Some small things: > - I think you've missed some debug code in c1_LIRAssembler.cpp:661. > - sharedRuntime.cpp:2841 Excess whitespace after "!=" > - sharedRuntime.cpp:2844 inset -> insert > > Best regards, > Tobias > > On 08.07.19 08:09, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8224944 >> http://cr.openjdk.java.net/~iklam/valhalla/8224944-c1-incorrect-vvep-ro-sharing.v01/ >> >> C1 tries to save space by avoiding the generation of the VVEP(RO) entry. However, >> in some cases we cannot re-use the VEP for VVEP(RO) -- when some parameters are >> passed on the stack, VEP has reserved entries, but VVEP(RO) doesn't. >> >> I also fixed the printing of the nmethod entry point names after merging with >> JDK-8213084 (Rework and enhance Print[Opto]Assembly output). >> >> Thanks >> - Ioi >> >> >> >> From harold.seigel at oracle.com Mon Jul 8 20:03:35 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 8 Jul 2019 16:03:35 -0400 Subject: RFR 8227373: [lworld] Monitorenter fails with VerifyError: Bad type on operand stack Message-ID: <24576b3e-f1ef-6f31-be56-8f3944ff697e@oracle.com> Hi, Please review this small fix to prevent the verifier from throwing a VerifyError exception when an inline type is the operand for a monitorenter or monitorexit opcode. Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8227373_lworld/webrev/index.html JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8227373 The fix was regression tested with tiers 1-3. Thanks, Harold From ioi.lam at oracle.com Mon Jul 8 20:42:15 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 8 Jul 2019 13:42:15 -0700 Subject: RFR 8227373: [lworld] Monitorenter fails with VerifyError: Bad type on operand stack In-Reply-To: <24576b3e-f1ef-6f31-be56-8f3944ff697e@oracle.com> References: <24576b3e-f1ef-6f31-be56-8f3944ff697e@oracle.com> Message-ID: <3dfdfd9b-090a-3f31-9551-ab66f01f1e43@oracle.com> Hi Harold, The changes look good to me. Thanks - Ioi On 7/8/19 1:03 PM, Harold Seigel wrote: > Hi, > > Please review this small fix to prevent the verifier from throwing a > VerifyError exception when an inline type is the operand for a > monitorenter or monitorexit opcode. > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8227373_lworld/webrev/index.html > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8227373 > > The fix was regression tested with tiers 1-3. > > Thanks, Harold > From harold.seigel at oracle.com Mon Jul 8 20:49:52 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 8 Jul 2019 16:49:52 -0400 Subject: RFR 8227373: [lworld] Monitorenter fails with VerifyError: Bad type on operand stack In-Reply-To: <3dfdfd9b-090a-3f31-9551-ab66f01f1e43@oracle.com> References: <24576b3e-f1ef-6f31-be56-8f3944ff697e@oracle.com> <3dfdfd9b-090a-3f31-9551-ab66f01f1e43@oracle.com> Message-ID: Thanks Ioi! Harold On 7/8/2019 4:42 PM, Ioi Lam wrote: > Hi Harold, > > The changes look good to me. > Thanks > - Ioi > > On 7/8/19 1:03 PM, Harold Seigel wrote: >> Hi, >> >> Please review this small fix to prevent the verifier from throwing a >> VerifyError exception when an inline type is the operand for a >> monitorenter or monitorexit opcode. >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8227373_lworld/webrev/index.html >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8227373 >> >> The fix was regression tested with tiers 1-3. >> >> Thanks, Harold >> > From ioi.lam at oracle.com Tue Jul 9 00:01:30 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Tue, 09 Jul 2019 00:01:30 +0000 Subject: hg: valhalla/valhalla: 2 new changesets Message-ID: <201907090001.x6901V8f021211@aojmv0008.oracle.com> Changeset: fd84386a3ff6 Author: iklam Date: 2019-07-08 12:59 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fd84386a3ff6 8226921: [lworld] Refactor argument shuffling code for ValueTypePassFieldsAsArgs Reviewed-by: dsamersoff ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/share/asm/macroAssembler.hpp + src/hotspot/share/asm/macroAssembler_common.cpp + src/hotspot/share/asm/macroAssembler_common.hpp + src/hotspot/share/runtime/signature_cc.hpp Changeset: fc0e33f800da Author: iklam Date: 2019-07-08 12:57 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/fc0e33f800da 8224944: [lworld] TestCallingConventionC1::test63 fails with -Xcomp Reviewed-by: thartmann ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestCallingConventionC1.java From rwestrel at redhat.com Tue Jul 9 08:46:47 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 09 Jul 2019 10:46:47 +0200 Subject: Flat Array null check issue - Re: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <6b286a81-6be4-09fe-9313-03274d2ba06e@samersoff.net> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> <0a672201-788c-02b1-a27d-21556f5b6455@oracle.com> <6b286a81-6be4-09fe-9313-03274d2ba06e@samersoff.net> Message-ID: <87imsb7fyg.fsf@redhat.com> > GetNullFreeProperty in compile.cpp > > > Interpreter in a similar place uses the code (below): > > ldrw(dst, Address(src, oopDesc::klass_offset_in_bytes())); > asrw(dst, dst, oopDesc::narrow_storage_props_shift); > > andr(dst, dst, ArrayStorageProperties::null_free_value); > cbnz(dst, is_null_free_array); > > > but C2 does: > > # LoadNKlass node > ldrw $dst, $mem > andr $dst, $dst, oopDesc::compressed_klass_mask() > > #AndINode > andr $dst, 1 << (oopDesc::narrow_storage_props_shift + > ArrayStorageProperties::null_free_bit); > > # cmpI > cbz(temp_reg, is_null_free_array); > > > Is it correct? > Do you have any ideas how to go forward with it? The klass pointer of a null free array is tagged with property bits (there are 2 property bits: null free and flattened). So before we use the klass pointer as an actual pointer we need to mask out the property bits. That's what: andr $dst, $dst, oopDesc::compressed_klass_mask() does. To check for a null free array, we need to test for the null free property bit on the unmasked klass pointer. Is the sequence above the actual code generated by c2? It would then seem that we test for the property bit on the already masked klass pointer. Roland. From dms at samersoff.net Tue Jul 9 09:33:41 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Tue, 9 Jul 2019 12:33:41 +0300 Subject: Flat Array null check issue - Re: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <87imsb7fyg.fsf@redhat.com> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> <0a672201-788c-02b1-a27d-21556f5b6455@oracle.com> <6b286a81-6be4-09fe-9313-03274d2ba06e@samersoff.net> <87imsb7fyg.fsf@redhat.com> Message-ID: Roland, > Is the sequence above the actual code generated by c2? It would then > seem that we test for the property bit on the already masked klass > pointer. Yes. It's the code generated by C2 and I agree with you finding. What is the correct way to fix it? Is it possible to move this logic to *.ad file and re-use the code from macroAssembler_*.cpp or it's better to replace LoadKlassNode with LoadPNode inside GraphKit::gen_value_array_null_guard and update dependent code? -Dmitry On 09.07.19 11:46, Roland Westrelin wrote: > >> GetNullFreeProperty in compile.cpp >> >> >> Interpreter in a similar place uses the code (below): >> >> ldrw(dst, Address(src, oopDesc::klass_offset_in_bytes())); >> asrw(dst, dst, oopDesc::narrow_storage_props_shift); >> >> andr(dst, dst, ArrayStorageProperties::null_free_value); >> cbnz(dst, is_null_free_array); >> >> >> but C2 does: >> >> # LoadNKlass node >> ldrw $dst, $mem >> andr $dst, $dst, oopDesc::compressed_klass_mask() >> >> #AndINode >> andr $dst, 1 << (oopDesc::narrow_storage_props_shift + >> ArrayStorageProperties::null_free_bit); >> >> # cmpI >> cbz(temp_reg, is_null_free_array); >> >> >> Is it correct? >> Do you have any ideas how to go forward with it? > > The klass pointer of a null free array is tagged with property bits > (there are 2 property bits: null free and flattened). So before we use > the klass pointer as an actual pointer we need to mask out the property > bits. That's what: > andr $dst, $dst, oopDesc::compressed_klass_mask() > does. > > To check for a null free array, we need to test for the null free > property bit on the unmasked klass pointer. > > Is the sequence above the actual code generated by c2? It would then > seem that we test for the property bit on the already masked klass > pointer. > > Roland. > From rwestrel at redhat.com Tue Jul 9 11:26:04 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 09 Jul 2019 13:26:04 +0200 Subject: Flat Array null check issue - Re: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> <0a672201-788c-02b1-a27d-21556f5b6455@oracle.com> <6b286a81-6be4-09fe-9313-03274d2ba06e@samersoff.net> <87imsb7fyg.fsf@redhat.com> Message-ID: <87d0ij78kz.fsf@redhat.com> Hi Dmitry, >> Is the sequence above the actual code generated by c2? It would then >> seem that we test for the property bit on the already masked klass >> pointer. > > Yes. It's the code generated by C2 and I agree with you finding. Can you send the output of PrintIdeal for that method? Thanks, Roland. From graphhopper at gmx.de Tue Jul 9 12:22:26 2019 From: graphhopper at gmx.de (Peter) Date: Tue, 9 Jul 2019 14:22:26 +0200 Subject: Error Message: value -> inline In-Reply-To: <2020450143.355039.1562608123775.JavaMail.zimbra@u-pem.fr> References: <00447e87-ba88-417c-d4bf-3f60adab7648@gmx.de> <1964708750.3531534.1562492300957.JavaMail.zimbra@u-pem.fr> <2bf4ebfe-d408-52a8-571c-4cfc61d76830@gmx.de> <2020450143.355039.1562608123775.JavaMail.zimbra@u-pem.fr> Message-ID: <0b1484a4-8b47-9e82-43a7-c44c2aa995e7@gmx.de> Hi R?mi, Thanks a lot for taking the time for an "ordinary" Java developer who is interested to try this feature :) ! (have no experience with hacking the JVM) > so no runtime support for wildcards/raw types/dynamic cast from Object. What do you mean here? I also do not understand the ArrayList part. On the one hand it seems that inline types should already work, as you say: /> ArrayList is special because the VM already allows E[] (Object[] at runtime) to be an array of indirect types or an array of inline types/ but on the other hand you say: /> //in that case, you have to modify the VM to teach it what i've called the level 2. / (When I say "the inline type works" I mean that a list of it uses the same memory like an array of structs in C) And allow me one last (the main) question: What is the best way at the moment to force my application to use the ArrayList where the inline type works? You can assume I have a very simple class like: inline class Point { double latitude; double longitude; } Or would I have to implement my own "XArrayList" class and replace all code occurrences of ArrayList? Regards Peter On 08.07.19 19:48, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "Peter" >> ?: "Remi Forax" >> Cc: "valhalla-dev" >> Envoy?: Lundi 8 Juillet 2019 10:49:45 >> Objet: Re: Error Message: value -> inline >> Hello Remi, >> >> Thanks, also for the link! >> >> The code for your ArrayList looks very crazy :) ... what is the reason >> for that? > yes, > it's a research code not a use case code :) > > There are several layers to introduce reified generics, roughly 3 levels > level 1: we need to have reified type accessible from the VM opcodes > level 2: at runtime, we need different constant pools (or parts of the constant pool) for the same class (species) > level 3: we need a way to have several specialized methods and activate/deactivate them > > This code test the level 1, the code is weird because it emulates the VM opcodes in Java (we have used a similar technique in the past when introducing invokedynamic). > In term of expressiveness, you have parameterized classes/methods done at compile time only using the stack, so no runtime support for wildcards/raw types/dynamic cast from Object. > >> And Java's ArrayList is not as good because it has Object[] instead of >> E[]? Or would be more changes necessary to make it memory efficient for >> inline types? > ArrayList is special because the VM already allows E[] (Object[] at runtime) to be an array of indirect types or an array of inline types, > so a quick hack is to have a constructor that take a class as argument and use it to create the array. > see https://github.com/forax/valuetype-lworld/blob/master/src/main/java/fr.umlv.valuetype/fr/umlv/valuetype/ReifiedList.java > > But this trick doesn't work when your data structure need an internal class with one of its field being either an indirect type or an inline type, > in that case, you have to modify the VM to teach it what i've called the level 2. > >> Regards >> Peter > regards, > R?mi > >> On 07.07.19 11:38, Remi Forax wrote: >>> ----- Mail original ----- >>>> De: "Peter" >>>> ?: "valhalla-dev" >>>> Envoy?: Dimanche 7 Juillet 2019 01:40:51 >>>> Objet: Error Message: value -> inline >>>> Hi, >>> Hi >>> >>>> I'm currently playing with the prototype of Project Valhalla - thanks >>>> for your huge work! >>>> >>>> I've studied the tests but is more documentation or better examples what >>>> is currently possible? E.g. I think that primitive lists like List >>>> is not yet possible - is this right? >>> yes, >>> no specialized generics yet ! >>> >>> you have more examples here: >>> https://github.com/forax/valuetype-lworld >>> >>>> Now I caught an error message that needs a small change. With: >>>> >>>> inline class Point { double lat; double lon; } >>>> inline class Point3d { double ele; inline Point point; } >>>> >>>> I get: >>>> >>>> Point3d.java:[5,25] modifier value not allowed here >>>> >>>> instead of: >>>> >>>> Point3d.java:[5,25] modifier inline not allowed here >>>> >>>> Regards >>>> Peter >>> cheers, >>> R?mi From harold.seigel at oracle.com Tue Jul 9 12:57:08 2019 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 09 Jul 2019 12:57:08 +0000 Subject: hg: valhalla/valhalla: 8227373: [lworld] Monitorenter fails with VerifyError: Bad type on operand stack Message-ID: <201907091257.x69Cv91i015436@aojmv0008.oracle.com> Changeset: 7b3697565ab1 Author: hseigel Date: 2019-07-09 08:55 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7b3697565ab1 8227373: [lworld] Monitorenter fails with VerifyError: Bad type on operand stack Summary: Change verifier to check for a non-scalar type instead of a reference Reviewed-by: iklam ! src/hotspot/share/classfile/verifier.cpp + test/hotspot/jtreg/runtime/valhalla/valuetypes/verifier/VTMonitor.java ! test/hotspot/jtreg/runtime/valhalla/valuetypes/verifier/VerifierValueTypes.java From tobias.hartmann at oracle.com Tue Jul 9 13:31:54 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 9 Jul 2019 15:31:54 +0200 Subject: RFR(S): 8227436: [lworld] C2 compilation fails with "bad dominance" Message-ID: <65cd6205-7c76-b422-3381-17aab4bb512a@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8227436 http://cr.openjdk.java.net/~thartmann/8227436/webrev.00/ ValueTypeNode::remove_redundant_allocations replaces a inline type allocation by a non-dominant one because we are only checking if the AllocateNode is dominant but that does not imply that the result_cast() is also dominant. Thanks, Tobias From dms at samersoff.net Tue Jul 9 13:36:08 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Tue, 9 Jul 2019 16:36:08 +0300 Subject: Flat Array null check issue - Re: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <87d0ij78kz.fsf@redhat.com> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> <0a672201-788c-02b1-a27d-21556f5b6455@oracle.com> <6b286a81-6be4-09fe-9313-03274d2ba06e@samersoff.net> <87imsb7fyg.fsf@redhat.com> <87d0ij78kz.fsf@redhat.com> Message-ID: <1426312d-8753-9435-cfe2-6b3a7d5d4039@samersoff.net> Hi Roland, Alias tends to strip attachments, so sending it directly. I checked x86 code. On x86 we don't mask loaded class in x86_64.ad file, on AArch64 I do it right in aarch64.ad I can follow x86 convention but it means that we need carefully insert masking to all place where it necessary. Should we consider to put masking inside LoadNKlass and LoadKlass and use LoadN/LoadP when we need unmasked value? Thank you, -Dmitry On 09.07.19 14:26, Roland Westrelin wrote: > > Hi Dmitry, > >>> Is the sequence above the actual code generated by c2? It would then >>> seem that we test for the property bit on the already masked klass >>> pointer. >> >> Yes. It's the code generated by C2 and I agree with you finding. > > Can you send the output of PrintIdeal for that method? > > Thanks, > Roland. > From tobias.hartmann at oracle.com Wed Jul 10 08:16:33 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 10 Jul 2019 10:16:33 +0200 Subject: RFR(S): 8227463: [lworld] Non-optimal code generation for array properties check Message-ID: <9fcf471a-4581-48ea-6bc9-298b0fd012b5@oracle.com> Hi, please review the following patch that optimizes code generation for the array properties check: https://bugs.openjdk.java.net/browse/JDK-8227463 http://cr.openjdk.java.net/~thartmann/8227463/webrev.00/ Before: Compressed oops: 0x00007f1eb9177c92: mov 0x8(%r12,%r10,8),%r11d 0x00007f1eb9177c97: mov %r11d,%r8d 0x00007f1eb9177c9a: test $0x40000000,%r8d No compressed oops: 0x00007f893d1662dd: mov 0x8(%r10),%r11 0x00007f893d1662e1: movabs $0x4000000000000000,%r8 0x00007f893d1662eb: and %r8,%r11 0x00007f893d1662ee: test %r11,%r11 After: Compressed oops: 0x00007fef69177a92: testl $0x40000000,0x8(%r12,%r10,8) No compressed oops: 0x00007fcd7d1660dd: movabs $0x4000000000000000,%r11 0x00007fcd7d1660e7: test %r11,0x8(%r10) Thanks, Tobias From rwestrel at redhat.com Wed Jul 10 08:26:49 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 10 Jul 2019 10:26:49 +0200 Subject: Flat Array null check issue - Re: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <1426312d-8753-9435-cfe2-6b3a7d5d4039@samersoff.net> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> <0a672201-788c-02b1-a27d-21556f5b6455@oracle.com> <6b286a81-6be4-09fe-9313-03274d2ba06e@samersoff.net> <87imsb7fyg.fsf@redhat.com> <87d0ij78kz.fsf@redhat.com> <1426312d-8753-9435-cfe2-6b3a7d5d4039@samersoff.net> Message-ID: <878st670s6.fsf@redhat.com> Hi Dmitry, I will take a closer look at that issue. Do you reproduce it with: http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.05/ ? Roland. From rwestrel at redhat.com Wed Jul 10 08:56:44 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 10 Jul 2019 10:56:44 +0200 Subject: RFR(S): 8227436: [lworld] C2 compilation fails with "bad dominance" In-Reply-To: <65cd6205-7c76-b422-3381-17aab4bb512a@oracle.com> References: <65cd6205-7c76-b422-3381-17aab4bb512a@oracle.com> Message-ID: <8736je6zeb.fsf@redhat.com> > http://cr.openjdk.java.net/~thartmann/8227436/webrev.00/ Good. Roland. From rwestrel at redhat.com Wed Jul 10 09:00:02 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 10 Jul 2019 11:00:02 +0200 Subject: RFR(S): 8227463: [lworld] Non-optimal code generation for array properties check In-Reply-To: <9fcf471a-4581-48ea-6bc9-298b0fd012b5@oracle.com> References: <9fcf471a-4581-48ea-6bc9-298b0fd012b5@oracle.com> Message-ID: <87zhlm5kod.fsf@redhat.com> > http://cr.openjdk.java.net/~thartmann/8227463/webrev.00/ Great! Thanks. Roland. From tobias.hartmann at oracle.com Wed Jul 10 09:01:31 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 10 Jul 2019 11:01:31 +0200 Subject: RFR(S): 8227463: [lworld] Non-optimal code generation for array properties check In-Reply-To: <87zhlm5kod.fsf@redhat.com> References: <9fcf471a-4581-48ea-6bc9-298b0fd012b5@oracle.com> <87zhlm5kod.fsf@redhat.com> Message-ID: <6a8047fa-6323-ed06-f7b3-f02d6388e474@oracle.com> Hi Roland, thanks for the review! Best regards, Tobias On 10.07.19 11:00, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8227463/webrev.00/ > > Great! Thanks. > > Roland. > From tobias.hartmann at oracle.com Wed Jul 10 09:03:11 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 10 Jul 2019 09:03:11 +0000 Subject: hg: valhalla/valhalla: 8227436: [lworld] C2 compilation fails with "bad dominance" Message-ID: <201907100903.x6A93CZb011513@aojmv0008.oracle.com> Changeset: 7c050415b6ef Author: thartmann Date: 2019-07-10 11:02 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/7c050415b6ef 8227436: [lworld] C2 compilation fails with "bad dominance" Reviewed-by: roland ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/valuetypenode.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNullableArrays.java From tobias.hartmann at oracle.com Wed Jul 10 09:01:20 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 10 Jul 2019 11:01:20 +0200 Subject: RFR(S): 8227436: [lworld] C2 compilation fails with "bad dominance" In-Reply-To: <8736je6zeb.fsf@redhat.com> References: <65cd6205-7c76-b422-3381-17aab4bb512a@oracle.com> <8736je6zeb.fsf@redhat.com> Message-ID: Hi Roland, thanks for the review! Best regards, Tobias On 10.07.19 10:56, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8227436/webrev.00/ > > Good. > > Roland. > From tobias.hartmann at oracle.com Wed Jul 10 09:06:12 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 10 Jul 2019 09:06:12 +0000 Subject: hg: valhalla/valhalla: 8227463: [lworld] Non-optimal code generation for array properties check Message-ID: <201907100906.x6A96DYI012376@aojmv0008.oracle.com> Changeset: 99244051701f Author: thartmann Date: 2019-07-10 11:05 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/99244051701f 8227463: [lworld] Non-optimal code generation for array properties check Reviewed-by: roland ! src/hotspot/cpu/x86/x86_64.ad From dms at samersoff.net Wed Jul 10 09:20:58 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Wed, 10 Jul 2019 12:20:58 +0300 Subject: Flat Array null check issue - Re: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <878st670s6.fsf@redhat.com> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> <0a672201-788c-02b1-a27d-21556f5b6455@oracle.com> <6b286a81-6be4-09fe-9313-03274d2ba06e@samersoff.net> <87imsb7fyg.fsf@redhat.com> <87d0ij78kz.fsf@redhat.com> <1426312d-8753-9435-cfe2-6b3a7d5d4039@samersoff.net> <878st670s6.fsf@redhat.com> Message-ID: <24dc35ef-69ab-9793-fd00-e5c1f3149e2f@samersoff.net> Hi Roland, On 10.07.19 11:26, Roland Westrelin wrote: > I will take a closer look at that issue. Do you reproduce it with: > > http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.05/ Thank you! Yes, you can reproduce it with this webrev. Also, I think you can reproduce the issue on x86 by adding andl($dst$$Register, oopDesc::compressed_klass_mask()); to instruct loadNKlass(rRegN dst, memory mem) inside x86_64.ad -Dmitry From rwestrel at redhat.com Wed Jul 10 09:26:59 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 10 Jul 2019 11:26:59 +0200 Subject: Flat Array null check issue - Re: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <24dc35ef-69ab-9793-fd00-e5c1f3149e2f@samersoff.net> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> <0a672201-788c-02b1-a27d-21556f5b6455@oracle.com> <6b286a81-6be4-09fe-9313-03274d2ba06e@samersoff.net> <87imsb7fyg.fsf@redhat.com> <87d0ij78kz.fsf@redhat.com> <1426312d-8753-9435-cfe2-6b3a7d5d4039@samersoff.net> <878st670s6.fsf@redhat.com> <24dc35ef-69ab-9793-fd00-e5c1f3149e2f@samersoff.net> Message-ID: <87tvbu5jfg.fsf@redhat.com> Hi Dmitry, >> I will take a closer look at that issue. Do you reproduce it with: >> >> http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.05/ > > Thank you! > > Yes, you can reproduce it with this webrev. > > Also, I think you can reproduce the issue on x86 by adding > > andl($dst$$Register, oopDesc::compressed_klass_mask()); > > to instruct loadNKlass(rRegN dst, memory mem) > inside x86_64.ad Masking is handled by platform independent code in C2. x86 used to take care of the masking in the ad file but it no longer does. Why doesn't aarch64 follow the x86 implementation? Roland. From dms at samersoff.net Wed Jul 10 10:16:19 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Wed, 10 Jul 2019 13:16:19 +0300 Subject: Flat Array null check issue - Re: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <87tvbu5jfg.fsf@redhat.com> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> <0a672201-788c-02b1-a27d-21556f5b6455@oracle.com> <6b286a81-6be4-09fe-9313-03274d2ba06e@samersoff.net> <87imsb7fyg.fsf@redhat.com> <87d0ij78kz.fsf@redhat.com> <1426312d-8753-9435-cfe2-6b3a7d5d4039@samersoff.net> <878st670s6.fsf@redhat.com> <24dc35ef-69ab-9793-fd00-e5c1f3149e2f@samersoff.net> <87tvbu5jfg.fsf@redhat.com> Message-ID: <89628f67-6edd-45a6-e787-ed8cb08d60a3@samersoff.net> Roland, > Masking is handled by platform independent code in C2. x86 used to > take care of the masking in the ad file but it no longer does. > Why doesn't aarch64 follow the x86 implementation? I updated aarch64 code to follow x86 implementation (I'll publish updated webrev shortly) so the immediate problem of falling test is solved. But I have more general question: Masking and storage property check is implemented three times - in interpreter, in C1 and in C2. Therefore, if we can re-use the code from macroAssembler_xxx.cpp in C1 and C2 it will simplify further maintenance. -Dmitry On 10.07.19 12:26, Roland Westrelin wrote: > > Hi Dmitry, > >>> I will take a closer look at that issue. Do you reproduce it with: >>> >>> http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.05/ >> >> Thank you! >> >> Yes, you can reproduce it with this webrev. >> >> Also, I think you can reproduce the issue on x86 by adding >> >> andl($dst$$Register, oopDesc::compressed_klass_mask()); >> >> to instruct loadNKlass(rRegN dst, memory mem) >> inside x86_64.ad > > Masking is handled by platform independent code in C2. x86 used to take > care of the masking in the ad file but it no longer does. Why doesn't > aarch64 follow the x86 implementation? > > Roland. > From tobias.hartmann at oracle.com Wed Jul 10 10:32:58 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 10 Jul 2019 10:32:58 +0000 Subject: hg: valhalla/valhalla: 8227509: [lworld] nmethod::print_nmethod_labels fails with Error: ShouldNotReachHere() Message-ID: <201907101032.x6AAWxIx027376@aojmv0008.oracle.com> Changeset: efd1b6baf25a Author: thartmann Date: 2019-07-10 12:32 +0200 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/efd1b6baf25a 8227509: [lworld] nmethod::print_nmethod_labels fails with Error: ShouldNotReachHere() ! src/hotspot/share/code/nmethod.cpp From rwestrel at redhat.com Wed Jul 10 11:49:59 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 10 Jul 2019 13:49:59 +0200 Subject: Flat Array null check issue - Re: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <89628f67-6edd-45a6-e787-ed8cb08d60a3@samersoff.net> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <850e5e34-bc84-320d-8e04-c019458a3f9b@samersoff.net> <0a672201-788c-02b1-a27d-21556f5b6455@oracle.com> <6b286a81-6be4-09fe-9313-03274d2ba06e@samersoff.net> <87imsb7fyg.fsf@redhat.com> <87d0ij78kz.fsf@redhat.com> <1426312d-8753-9435-cfe2-6b3a7d5d4039@samersoff.net> <878st670s6.fsf@redhat.com> <24dc35ef-69ab-9793-fd00-e5c1f3149e2f@samersoff.net> <87tvbu5jfg.fsf@redhat.com> <89628f67-6edd-45a6-e787-ed8cb08d60a3@samersoff.net> Message-ID: <87r26y5ct4.fsf@redhat.com> > I updated aarch64 code to follow x86 implementation (I'll publish > updated webrev shortly) so the immediate problem of falling test is solved. Great! > But I have more general question: > > Masking and storage property check is implemented three times - in > interpreter, in C1 and in C2. Therefore, if we can re-use the code from > macroAssembler_xxx.cpp in C1 and C2 it will simplify further maintenance. Sharing code between c1 and the interpreter definitely makes sense if possible. I think we would rather implement the check as platform independent IR in C2 which should lead to better generated code. That makes sharing with C2 impossible. Anyway, I'm sure we would welcome a patch that implements shared storage property checks for c1 and the interpreter on x86 if you feel like tackling it. Roland. From ioi.lam at oracle.com Wed Jul 10 15:33:38 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Wed, 10 Jul 2019 15:33:38 +0000 Subject: hg: valhalla/valhalla: 8227209: [lworld][c1] TestOnStackReplacement.java scenario #4 times out with -DVerifyVM=true Message-ID: <201907101533.x6AFXclN021581@aojmv0008.oracle.com> Changeset: ab44170a424b Author: iklam Date: 2019-07-09 23:47 -0700 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/ab44170a424b 8227209: [lworld][c1] TestOnStackReplacement.java scenario #4 times out with -DVerifyVM=true ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestOnStackReplacement.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java From ioi.lam at oracle.com Thu Jul 11 02:24:10 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Thu, 11 Jul 2019 02:24:10 +0000 Subject: hg: valhalla/valhalla: 8227453: [lworld][c1] compiler/valhalla/valuetypes/TestArrays fails with -Xcomp Message-ID: <201907110224.x6B2OBp5018067@aojmv0008.oracle.com> Changeset: 64afd6af7383 Author: iklam Date: 2019-07-10 19:12 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/64afd6af7383 8227453: [lworld][c1] compiler/valhalla/valuetypes/TestArrays fails with -Xcomp ! src/hotspot/share/c1/c1_Instruction.cpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java From ioi.lam at oracle.com Fri Jul 12 15:18:17 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 12 Jul 2019 08:18:17 -0700 Subject: RFR 8227451 [lworld][c1] withfield and defaultvalue handling for unloaded classes Message-ID: https://bugs.openjdk.java.net/browse/JDK-8227451 http://cr.openjdk.java.net/~iklam/valhalla/8227451-withfield-unloaded-class.v01/ When C1 sees a withfield or defaultvalue bytecode that operates on a class that's not yet loaded, it generates a deoptimization stub to fall back to the interpreter. This kind of code is uncommon (not possible with regular Java code??), so there's no point of optimizing for it. Thanks - Ioi From dms at samersoff.net Sat Jul 13 18:10:34 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Sat, 13 Jul 2019 21:10:34 +0300 Subject: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> Message-ID: <66117c8f-df12-4f93-21e2-9d0de0a3c3c7@samersoff.net> Hello David, I updated the webrev below to lworld_stable. All tests are passed. Is there any chance to have the changes reviewed and pushed? -Dmitry On 27.06.2019 10:43, Dmitry Samersoff wrote: > Hello Everybody, > > > Please review v.05 of adding AArch64 support to lworld branch > > http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.05/ > > What was done: > > Implemented Valhalla support for aarch64. > > Support for ValueTypePassFieldsAsArgs and ValueTypeReturnedAsFields > is not completed and is not included into this webrev > to reduce review and rebasing efforts. > > Testing: > > All tests in runtime/valhalla/valuetypes and in > compiler/valhalla/valuetypes/ are passed > > compiler/valhalla/valuetypes/TestMethodHandles.java > compiler/valhalla/valuetypes/TestBasicFunctionality.java > > are passed after manually tweaking of output patterns, I have not > found a way to support both x86 and aarch64, so these tests remain > unchanged and run on x64 only. > > > -Dmitry > From dms at samersoff.net Mon Jul 15 08:01:26 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Mon, 15 Jul 2019 11:01:26 +0300 Subject: Recommended Valhalla benchmarks? Message-ID: <481cfa23-0501-0555-f1af-a466140d104c@samersoff.net> Hello Everybody, Are there any benchmarks that is recommended to demonstrate Valhalla purpose/value? -Dmitry From mandy.chung at oracle.com Mon Jul 15 17:43:42 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 15 Jul 2019 10:43:42 -0700 Subject: Recommended Valhalla benchmarks? In-Reply-To: <481cfa23-0501-0555-f1af-a466140d104c@samersoff.net> References: <481cfa23-0501-0555-f1af-a466140d104c@samersoff.net> Message-ID: The micro benchmarks are under test/micro/org/openjdk/bench/valhalla.? README.txt under that directory describes the micro benchmarks.? Sergey can give details on his work. Mandy On 7/15/19 1:01 AM, Dmitry Samersoff wrote: > Hello Everybody, > > Are there any benchmarks that is recommended to demonstrate Valhalla > purpose/value? > > -Dmitry From tobias.hartmann at oracle.com Tue Jul 16 13:29:49 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 16 Jul 2019 15:29:49 +0200 Subject: RFR(M): 8227634: [lworld] Better optimize object array accesses Message-ID: <762ca59c-0a04-7b0a-6352-d7eaf84bbc33@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8227634 http://cr.openjdk.java.net/~thartmann/8227634/webrev.00/ This patch implements the following optimizations: - When checkcasting an array element to a type that can not be flattened in arrays, the array should be marked as not-flat (see TestArrays::test79-test80). - When storing an object with a non-inline, non-null type into an array, that array should be marked as not-null-free and therefore also as not-flat (see TestArrays::test81). - When storing an inline type with a type that can not be flattened in arrays into an array, that array should be marked as not-flat (see TestArrays::test82). - When checkcasting an array element to a non-inline type, the array should be marked as not-null-free and therefore also as not-flat (see TestArrays::test83). - When storing a constant null into an array, the array should be marked as not-null-free and therefore also as not-flat (see TestArrays::test84-test87). Now these are parse time optimizations that could potentially be converted to IGVN optimizations (to handle cases where exact type information is only available after parsing, for example with incremental inlining). I'll investigate this as a follow-up. Other changes: - Strengthened the asserts to make sure we emit optimal code at parse time - Fixed a bug where no NPE is thrown when we store NULL to a null-free value type array (happens if we always store null, see test88 and test89) - Moved is_flattened_array_check from loopUnswitch.cpp to IfNode - Strengthened IR matching rules for some tests - There are several tests with accesses to (nullable) non-flattened inline type arrays that have their matching rules disabled but can probably be optimized further. I've filed JDK-8227588 and marked these tests with a TODO. - Enabled IR verification for test scenario 2 for most tests (also enabled field flattening) - Set ValueArrayElemMaxFlatOops to 5 for test scenarios to create non-flattened inline type arrays while array flattening is still enabled Thanks, Tobias From tobias.hartmann at oracle.com Tue Jul 16 13:34:48 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 16 Jul 2019 15:34:48 +0200 Subject: RFR 8227451 [lworld][c1] withfield and defaultvalue handling for unloaded classes In-Reply-To: References: Message-ID: <3109c20f-857a-fd6d-53ea-e92a5268a152@oracle.com> Hi Ioi, looks good to me! Best regards, Tobias On 12.07.19 17:18, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8227451 > http://cr.openjdk.java.net/~iklam/valhalla/8227451-withfield-unloaded-class.v01/ > > When C1 sees a withfield or defaultvalue bytecode that operates on a > class that's not yet loaded, it generates a deoptimization stub to fall > back to the interpreter. > > This kind of code is uncommon (not possible with regular Java code??), so > there's no point of optimizing for it. > > Thanks > - Ioi From ioi.lam at oracle.com Wed Jul 17 02:50:20 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Wed, 17 Jul 2019 02:50:20 +0000 Subject: hg: valhalla/valhalla: 8227451: [lworld][c1] withfield and defaultvalue handling for unloaded classes Message-ID: <201907170250.x6H2oLjE006921@aojmv0008.oracle.com> Changeset: 3364303696f7 Author: iklam Date: 2019-07-16 19:47 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3364303696f7 8227451: [lworld][c1] withfield and defaultvalue handling for unloaded classes Reviewed-by: thartmann ! src/hotspot/share/c1/c1_Canonicalizer.cpp ! src/hotspot/share/c1/c1_Canonicalizer.hpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_InstructionPrinter.cpp ! src/hotspot/share/c1/c1_InstructionPrinter.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/c1/c1_Optimizer.cpp ! src/hotspot/share/c1/c1_RangeCheckElimination.hpp ! src/hotspot/share/c1/c1_ValueMap.hpp From ioi.lam at oracle.com Wed Jul 17 03:34:43 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 16 Jul 2019 20:34:43 -0700 Subject: RFR 8227568 [lworld][c1] oopmap missing for calls to store_value_type_fields_to_buf Message-ID: https://bugs.openjdk.java.net/browse/JDK-8227568 http://cr.openjdk.java.net/~iklam/valhalla/8227568-oompap-for-returned-fields.v01/ The main change is here in c1_LIRAssembler.cpp: ? if (op->maybe_return_as_fields(&vk)) { ??? int offset = store_value_type_fields_to_buf(vk); ??? add_call_info(offset, op->info(), true); ? } With the oopmap, a GC can happen inside SharedRuntime::store_value_type_fields_to_buf when called by C1. I also reverted the changes in JDK-8226284 (which disabled VerifyStack checks for store_value_type_fields_to_buf), because now we can walk the stack due to the addition of the oopmaps. (codeBlob.cpp/hpp, interfaceSupport.cpp, stubGenerator_x86_64.cpp). Thanks - Ioi From rwestrel at redhat.com Wed Jul 17 12:30:16 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 17 Jul 2019 14:30:16 +0200 Subject: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <66117c8f-df12-4f93-21e2-9d0de0a3c3c7@samersoff.net> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <66117c8f-df12-4f93-21e2-9d0de0a3c3c7@samersoff.net> Message-ID: <87ims04zdz.fsf@redhat.com> Hi Dmitry, > I updated the webrev below to lworld_stable. All tests are passed. > > Is there any chance to have the changes reviewed and pushed? I went over the changes quickly and while I can't say I reviewed them I see no reason not to push them. I also propose we nominate you as valhalla committer so you can proceed with subsequent pushes yourself. We can either wait until the CFV is over or I can push them for you. What do you think? Roland. From rwestrel at redhat.com Wed Jul 17 12:44:38 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 17 Jul 2019 14:44:38 +0200 Subject: CFV: New Valhalla Committer: Dmitry Samersoff Message-ID: <87ftn44yq1.fsf@redhat.com> I hereby nominate Dmitry Samersoff (dsamersoff) to Valhalla Committer. Dmitry is a jdk 10 and up reviewer and has been working on an aarch64 port of the value type prototype. For a full list of Dmitry's commits, see [3]. Votes are due by July 31, 2019. Only current Valhalla Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. Thank you, Roland Westrelin. [1] - http://openjdk.java.net/census [2] - http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=%28keyword%28%22dms%40samersoff.net%22%29+or+keyword%28%22dmitry.samersoff%40oracle.com%22%29+or+%28author%28dsamersoff%29+and+not+desc%28%22Contributed-by%3A%22%29%29%29+and+not+desc%28%22Merge%22%29 [4] http://openjdk.java.net/jeps/197 [5] http://openjdk.java.net/jeps/254 From rwestrel at redhat.com Wed Jul 17 12:45:49 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 17 Jul 2019 14:45:49 +0200 Subject: CFV: New Valhalla Committer: Dmitry Samersoff In-Reply-To: <87ftn44yq1.fsf@redhat.com> References: <87ftn44yq1.fsf@redhat.com> Message-ID: <87d0i84yo2.fsf@redhat.com> Vote: yes. Roland. From harold.seigel at oracle.com Wed Jul 17 12:46:47 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 17 Jul 2019 08:46:47 -0400 Subject: CFV: New Valhalla Committer: Dmitry Samersoff In-Reply-To: <87ftn44yq1.fsf@redhat.com> References: <87ftn44yq1.fsf@redhat.com> Message-ID: Vote: Yes Harold On 7/17/2019 8:44 AM, Roland Westrelin wrote: > I hereby nominate Dmitry Samersoff (dsamersoff) to Valhalla Committer. > > Dmitry is a jdk 10 and up reviewer and has been working on an aarch64 > port of the value type prototype. For a full list of Dmitry's commits, > see [3]. > > Votes are due by July 31, 2019. > > Only current Valhalla Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > Roland Westrelin. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=%28keyword%28%22dms%40samersoff.net%22%29+or+keyword%28%22dmitry.samersoff%40oracle.com%22%29+or+%28author%28dsamersoff%29+and+not+desc%28%22Contributed-by%3A%22%29%29%29+and+not+desc%28%22Merge%22%29 > [4] http://openjdk.java.net/jeps/197 > [5] http://openjdk.java.net/jeps/254 From frederic.parain at oracle.com Wed Jul 17 12:47:32 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 17 Jul 2019 08:47:32 -0400 Subject: CFV: New Valhalla Committer: Dmitry Samersoff In-Reply-To: <87ftn44yq1.fsf@redhat.com> References: <87ftn44yq1.fsf@redhat.com> Message-ID: <0D49AEF1-447E-486A-856D-747D43D9021D@oracle.com> Vote: yes Fred > On Jul 17, 2019, at 08:44, Roland Westrelin wrote: > > > I hereby nominate Dmitry Samersoff (dsamersoff) to Valhalla Committer. > > Dmitry is a jdk 10 and up reviewer and has been working on an aarch64 > port of the value type prototype. For a full list of Dmitry's commits, > see [3]. > > Votes are due by July 31, 2019. > > Only current Valhalla Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > Roland Westrelin. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=%28keyword%28%22dms%40samersoff.net%22%29+or+keyword%28%22dmitry.samersoff%40oracle.com%22%29+or+%28author%28dsamersoff%29+and+not+desc%28%22Contributed-by%3A%22%29%29%29+and+not+desc%28%22Merge%22%29 > [4] http://openjdk.java.net/jeps/197 > [5] http://openjdk.java.net/jeps/254 From tobias.hartmann at oracle.com Wed Jul 17 12:48:17 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 17 Jul 2019 14:48:17 +0200 Subject: CFV: New Valhalla Committer: Dmitry Samersoff In-Reply-To: <87ftn44yq1.fsf@redhat.com> References: <87ftn44yq1.fsf@redhat.com> Message-ID: <17908ad7-b7ff-dde4-8b30-745ca4249b6e@oracle.com> Vote: yes Best regards, Tobias On 17.07.19 14:44, Roland Westrelin wrote: > > I hereby nominate Dmitry Samersoff (dsamersoff) to Valhalla Committer. > > Dmitry is a jdk 10 and up reviewer and has been working on an aarch64 > port of the value type prototype. For a full list of Dmitry's commits, > see [3]. > > Votes are due by July 31, 2019. > > Only current Valhalla Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > Roland Westrelin. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=%28keyword%28%22dms%40samersoff.net%22%29+or+keyword%28%22dmitry.samersoff%40oracle.com%22%29+or+%28author%28dsamersoff%29+and+not+desc%28%22Contributed-by%3A%22%29%29%29+and+not+desc%28%22Merge%22%29 > [4] http://openjdk.java.net/jeps/197 > [5] http://openjdk.java.net/jeps/254 > From vladimir.x.ivanov at oracle.com Wed Jul 17 13:02:32 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 17 Jul 2019 16:02:32 +0300 Subject: CFV: New Valhalla Committer: Dmitry Samersoff In-Reply-To: <87ftn44yq1.fsf@redhat.com> References: <87ftn44yq1.fsf@redhat.com> Message-ID: <1fc9d910-0bc1-cbb0-176c-0be04c8ab6b7@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 17/07/2019 15:44, Roland Westrelin wrote: > I hereby nominate Dmitry Samersoff (dsamersoff) to Valhalla Committer. From lois.foltan at oracle.com Wed Jul 17 13:34:51 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 17 Jul 2019 09:34:51 -0400 Subject: CFV: New Valhalla Committer: Dmitry Samersoff In-Reply-To: <87ftn44yq1.fsf@redhat.com> References: <87ftn44yq1.fsf@redhat.com> Message-ID: <5b308d52-800d-237d-b404-c3549ea1febd@oracle.com> Vote: yes Lois On 7/17/2019 8:44 AM, Roland Westrelin wrote: > I hereby nominate Dmitry Samersoff (dsamersoff) to Valhalla Committer. > > Dmitry is a jdk 10 and up reviewer and has been working on an aarch64 > port of the value type prototype. For a full list of Dmitry's commits, > see [3]. > > Votes are due by July 31, 2019. > > Only current Valhalla Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > Roland Westrelin. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=%28keyword%28%22dms%40samersoff.net%22%29+or+keyword%28%22dmitry.samersoff%40oracle.com%22%29+or+%28author%28dsamersoff%29+and+not+desc%28%22Contributed-by%3A%22%29%29%29+and+not+desc%28%22Merge%22%29 > [4] http://openjdk.java.net/jeps/197 > [5] http://openjdk.java.net/jeps/254 From chris.hegarty at oracle.com Wed Jul 17 13:44:13 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 17 Jul 2019 14:44:13 +0100 Subject: CFV: New Valhalla Committer: Dmitry Samersoff In-Reply-To: <87ftn44yq1.fsf@redhat.com> References: <87ftn44yq1.fsf@redhat.com> Message-ID: <7a8dbd11-6015-e365-a145-ad31cf0c9255@oracle.com> On 17/07/2019 13:44, Roland Westrelin wrote: > > I hereby nominate Dmitry Samersoff (dsamersoff) to Valhalla Committer. Vote: YES. -Chris. From mandy.chung at oracle.com Wed Jul 17 15:26:49 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 17 Jul 2019 08:26:49 -0700 Subject: CFV: New Valhalla Committer: Dmitry Samersoff In-Reply-To: <87ftn44yq1.fsf@redhat.com> References: <87ftn44yq1.fsf@redhat.com> Message-ID: <6e9d915d-8ea0-53f5-4dd6-26c6943e8b09@oracle.com> Vote: yes Mandy From IOI.LAM at ORACLE.COM Wed Jul 17 15:30:08 2019 From: IOI.LAM at ORACLE.COM (Ioi Lam) Date: Wed, 17 Jul 2019 08:30:08 -0700 Subject: CFV: New Valhalla Committer: Dmitry Samersoff In-Reply-To: <87ftn44yq1.fsf@redhat.com> References: <87ftn44yq1.fsf@redhat.com> Message-ID: <274E2FFF-9A07-4FBD-A835-770DEE7A64D8@ORACLE.COM> Vote: yes Ioi Sent from my iPad > On Jul 17, 2019, at 5:44 AM, Roland Westrelin wrote: > > > I hereby nominate Dmitry Samersoff (dsamersoff) to Valhalla Committer. > > Dmitry is a jdk 10 and up reviewer and has been working on an aarch64 > port of the value type prototype. For a full list of Dmitry's commits, > see [3]. > > Votes are due by July 31, 2019. > > Only current Valhalla Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > Roland Westrelin. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=%28keyword%28%22dms%40samersoff.net%22%29+or+keyword%28%22dmitry.samersoff%40oracle.com%22%29+or+%28author%28dsamersoff%29+and+not+desc%28%22Contributed-by%3A%22%29%29%29+and+not+desc%28%22Merge%22%29 > [4] http://openjdk.java.net/jeps/197 > [5] http://openjdk.java.net/jeps/254 From tobias.hartmann at oracle.com Thu Jul 18 05:10:48 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 18 Jul 2019 07:10:48 +0200 Subject: RFR 8227568 [lworld][c1] oopmap missing for calls to store_value_type_fields_to_buf In-Reply-To: References: Message-ID: <8c8d486a-c65f-0f15-b324-e8770ccbb74e@oracle.com> Hi Ioi, looks good to me. Just wondering, why do you need the changes in c1_LIR.cpp:1088? Thanks, Tobias On 17.07.19 05:34, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8227568 > http://cr.openjdk.java.net/~iklam/valhalla/8227568-oompap-for-returned-fields.v01/ > > The main change is here in c1_LIRAssembler.cpp: > > ? if (op->maybe_return_as_fields(&vk)) { > ??? int offset = store_value_type_fields_to_buf(vk); > ??? add_call_info(offset, op->info(), true); > ? } > > With the oopmap, a GC can happen inside SharedRuntime::store_value_type_fields_to_buf > when called by C1. > > I also reverted the changes in JDK-8226284 (which disabled VerifyStack checks for > store_value_type_fields_to_buf), because now we can walk the stack due to the addition > of the oopmaps. (codeBlob.cpp/hpp, interfaceSupport.cpp, stubGenerator_x86_64.cpp). > > Thanks > - Ioi > > > From ioi.lam at oracle.com Thu Jul 18 06:35:01 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 17 Jul 2019 23:35:01 -0700 Subject: RFR 8227568 [lworld][c1] oopmap missing for calls to store_value_type_fields_to_buf In-Reply-To: <8c8d486a-c65f-0f15-b324-e8770ccbb74e@oracle.com> References: <8c8d486a-c65f-0f15-b324-e8770ccbb74e@oracle.com> Message-ID: <8fcd527a-a63a-2a99-5ea0-bc476c26c466@oracle.com> Hi Tobias, Thanks foe the review. On 7/17/19 10:10 PM, Tobias Hartmann wrote: > Hi Ioi, > > looks good to me. Just wondering, why do you need the changes in c1_LIR.cpp:1088? The reason is there was almost identical code in the old version of c1_LIRAssembler.cpp around line 488, so I just consolidated the code into a single place. Thanks - Ioi > Thanks, > Tobias > > On 17.07.19 05:34, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8227568 >> http://cr.openjdk.java.net/~iklam/valhalla/8227568-oompap-for-returned-fields.v01/ >> >> The main change is here in c1_LIRAssembler.cpp: >> >> ? if (op->maybe_return_as_fields(&vk)) { >> ??? int offset = store_value_type_fields_to_buf(vk); >> ??? add_call_info(offset, op->info(), true); >> ? } >> >> With the oopmap, a GC can happen inside SharedRuntime::store_value_type_fields_to_buf >> when called by C1. >> >> I also reverted the changes in JDK-8226284 (which disabled VerifyStack checks for >> store_value_type_fields_to_buf), because now we can walk the stack due to the addition >> of the oopmaps. (codeBlob.cpp/hpp, interfaceSupport.cpp, stubGenerator_x86_64.cpp). >> >> Thanks >> - Ioi >> >> >> From tobias.hartmann at oracle.com Thu Jul 18 06:47:15 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 18 Jul 2019 08:47:15 +0200 Subject: RFR 8227568 [lworld][c1] oopmap missing for calls to store_value_type_fields_to_buf In-Reply-To: <8fcd527a-a63a-2a99-5ea0-bc476c26c466@oracle.com> References: <8c8d486a-c65f-0f15-b324-e8770ccbb74e@oracle.com> <8fcd527a-a63a-2a99-5ea0-bc476c26c466@oracle.com> Message-ID: <290fb48b-638d-1262-a0e5-09cb841b0e9d@oracle.com> On 18.07.19 08:35, Ioi Lam wrote: > The reason is there was almost identical code in the old version of c1_LIRAssembler.cpp around line > 488, so I just consolidated the code into a single place. Okay, thanks for the explanation! Best regards, Tobias From tobias.hartmann at oracle.com Thu Jul 18 12:26:11 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 18 Jul 2019 14:26:11 +0200 Subject: RFR(XS): 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable Message-ID: <43a02a7c-c08c-271d-6ea2-78022dbe8380@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8228367 http://cr.openjdk.java.net/~thartmann/8228367/webrev.00/ When loading a constant, null-free inline type field from an inline type, we should treat that field as flattenable (even if it is not declared as flattenable) to trigger scalarization. I also had to remove the assert in ValueTypeNode::pass_fields because it is too strong. Thanks, Tobias From tobias.hartmann at oracle.com Thu Jul 18 12:44:11 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Thu, 18 Jul 2019 12:44:11 +0000 Subject: hg: valhalla/valhalla: [lworld] Some refactoring and removal of unnecessary TODOs Message-ID: <201907181244.x6ICiCVE023160@aojmv0008.oracle.com> Changeset: 6525422aa7e5 Author: thartmann Date: 2019-07-18 14:43 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/6525422aa7e5 [lworld] Some refactoring and removal of unnecessary TODOs ! src/hotspot/share/ci/ciInstance.cpp ! src/hotspot/share/ci/ciInstance.hpp ! src/hotspot/share/ci/ciValueArrayKlass.cpp ! src/hotspot/share/ci/ciValueArrayKlass.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp From ioi.lam at oracle.com Thu Jul 18 20:01:01 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Thu, 18 Jul 2019 20:01:01 +0000 Subject: hg: valhalla/valhalla: 8227568: [lworld][c1] oopmap missing for calls to store_value_type_fields_to_buf Message-ID: <201907182001.x6IK12qL016866@aojmv0008.oracle.com> Changeset: 45f2f8d86692 Author: iklam Date: 2019-07-18 13:00 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/45f2f8d86692 8227568: [lworld][c1] oopmap missing for calls to store_value_type_fields_to_buf Reviewed-by: thartmann ! src/hotspot/cpu/x86/c1_LIRAssembler_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/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_LIRAssembler.hpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/runtime/interfaceSupport.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestCallingConventionC1.java From ioi.lam at oracle.com Fri Jul 19 06:13:03 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Fri, 19 Jul 2019 06:13:03 +0000 Subject: hg: valhalla/valhalla: 8227452: [lworld][c1] jdk/valhalla/valuetypes/ValueArray.java fails with -Xcomp Message-ID: <201907190613.x6J6D4im009044@aojmv0008.oracle.com> Changeset: 397e474bdb8d Author: iklam Date: 2019-07-18 23:12 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/397e474bdb8d 8227452: [lworld][c1] jdk/valhalla/valuetypes/ValueArray.java fails with -Xcomp ! src/hotspot/share/c1/c1_Instruction.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java From tobias.hartmann at oracle.com Fri Jul 19 10:48:43 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 19 Jul 2019 12:48:43 +0200 Subject: RFR(S): 8228416: [lworld] C2 compilation fails with assert(raw_val == __null) failed: val may not be null Message-ID: <7acd4eae-1878-16c9-ce05-56f45ee74c17@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8228416 http://cr.openjdk.java.net/~thartmann/8228416/webrev.00/ When allocating an array without a statically known type (for example, through reflection), we only set raw_default_value but not default_value which triggers an assert during macro expansion of the AllocateArrayNode. Both values should be initialized. This only happens with -XX:-UseCompressedClassPointers because the code paths in PhaseMacroExpand::generate_clear_array are different due to different alignment restrictions. Thanks, Tobias From forax at univ-mlv.fr Fri Jul 19 15:02:49 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 19 Jul 2019 17:02:49 +0200 (CEST) Subject: RFR(XS): 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable In-Reply-To: <43a02a7c-c08c-271d-6ea2-78022dbe8380@oracle.com> References: <43a02a7c-c08c-271d-6ea2-78022dbe8380@oracle.com> Message-ID: <1298549412.3670769.1563548569358.JavaMail.zimbra@u-pem.fr> Hi Tobias, this seems wrong to me, it's the tail wagging the dog. The scalarization has nothing to do with the fact of being flattenable or not, the flattenability is a storage property so for value in fields or array elements, not for value on the stack. Being a null-free inline type is enough, you do not have to check if the fields are flattenable or not. R?mi ----- Mail original ----- > De: "Tobias Hartmann" > ?: "valhalla-dev" > Envoy?: Jeudi 18 Juillet 2019 14:26:11 > Objet: RFR(XS): 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8228367 > http://cr.openjdk.java.net/~thartmann/8228367/webrev.00/ > > When loading a constant, null-free inline type field from an inline type, we > should treat that field > as flattenable (even if it is not declared as flattenable) to trigger > scalarization. > > I also had to remove the assert in ValueTypeNode::pass_fields because it is too > strong. > > Thanks, > Tobias From frederic.parain at oracle.com Fri Jul 19 15:26:45 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 19 Jul 2019 11:26:45 -0400 Subject: RFR(XL): JDK-8228441 Field layout requires complete overhaul to efficiently support inline classes Message-ID: <9F44BBA3-1415-40F6-BB32-0F67C6DEB4FB@oracle.com> Greetings, This is the initial request for review for a new code to layout fields. The current code to compute field layouts is especially ugly and not fitted to efficiently flatten inline classes. This changeset is an almost complete overhaul of the field layout code, with a new framework to compute layouts and two different allocation strategies (one for identity classes and one for inline classes). CR: https://bugs.openjdk.java.net/browse/JDK-8228441 Webrev: http://cr.openjdk.java.net/~fparain/layout/webrev.00/ This changeset also includes some options and DCMD to ease inspection of layouts, especially when flattenable fields are involved. The changeset doesn?t remove the old layout code, meaning that either the old code or the new code can be used (controlled by VM flag). This code passed tiers 1 to 3 on Valhalla supported platforms. Some failures have been identified in higher tiers with some @Contended tests, but they are due to test bugs (tests making relying on wrong assumptions about field layouts). The code contains a lot of comments about the new framework and the different allocation strategies. Feel free to complain if comments are not clear enough or if some code need more comments. Regarding the huge size of this changeset, and people being in summer vacation, I?m not planning to push this code in the short term. Thank you, Fred From brian.goetz at oracle.com Fri Jul 19 15:32:58 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 19 Jul 2019 11:32:58 -0400 Subject: RFR(XL): JDK-8228441 Field layout requires complete overhaul to efficiently support inline classes In-Reply-To: <9F44BBA3-1415-40F6-BB32-0F67C6DEB4FB@oracle.com> References: <9F44BBA3-1415-40F6-BB32-0F67C6DEB4FB@oracle.com> Message-ID: <41E17BB7-8567-4270-BDC2-B11DA91A41DF@oracle.com> Great to see support for making it easier to inspect what decisions the VM is actually making here. Rather than a DCMD, did you consider using JFR events to log these decisions, now that JFR is universally available? > On Jul 19, 2019, at 11:26 AM, Frederic Parain wrote: > > This changeset also includes some options and DCMD to ease inspection > of layouts, especially when flattenable fields are involved. From frederic.parain at oracle.com Fri Jul 19 15:44:28 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 19 Jul 2019 11:44:28 -0400 Subject: RFR(XL): JDK-8228441 Field layout requires complete overhaul to efficiently support inline classes In-Reply-To: <41E17BB7-8567-4270-BDC2-B11DA91A41DF@oracle.com> References: <9F44BBA3-1415-40F6-BB32-0F67C6DEB4FB@oracle.com> <41E17BB7-8567-4270-BDC2-B11DA91A41DF@oracle.com> Message-ID: I love DCMD, because it?s text based :-) But I?ll look at the generation of JFR events. Fred > On Jul 19, 2019, at 11:32, Brian Goetz wrote: > > Great to see support for making it easier to inspect what decisions the VM is actually making here. Rather than a DCMD, did you consider using JFR events to log these decisions, now that JFR is universally available? > >> On Jul 19, 2019, at 11:26 AM, Frederic Parain wrote: >> >> This changeset also includes some options and DCMD to ease inspection >> of layouts, especially when flattenable fields are involved. > From tobias.hartmann at oracle.com Mon Jul 22 06:01:37 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 22 Jul 2019 08:01:37 +0200 Subject: RFR(XS): 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable In-Reply-To: <1298549412.3670769.1563548569358.JavaMail.zimbra@u-pem.fr> References: <43a02a7c-c08c-271d-6ea2-78022dbe8380@oracle.com> <1298549412.3670769.1563548569358.JavaMail.zimbra@u-pem.fr> Message-ID: <306e68c1-d34b-46ab-cd4e-722396286fb1@oracle.com> Hi R?mi, On 19.07.19 17:02, Remi Forax wrote: > The scalarization has nothing to do with the fact of being flattenable or not, > the flattenability is a storage property so for value in fields or array elements, not for value on the stack. > > Being a null-free inline type is enough, you do not have to check if the fields are flattenable or not. Yes, sure. But this change is about VM/JIT internal code that attempts scalarization when creating the C2 IR for loading a constant inline type field with an inline type holder. And here the term "flattenable" is currently used interchangeably with "null-free". That's actually not specific to the JIT, but just how the VM propagates inline type field specific information internally. Basically, we have three relevant field states: (1) !flattenable && !flattened => !null-free, !flat, !inline type field (2) flattenable && !flattened => null-free, !flat, inline type field (3) flattenable && flattened => null-free, flat, inline type field The JIT will attempt scalarization for (2) and (3). This simplification will change as soon as there is a possibility to declare inline type fields that are null-free and !flattenable (or !null-free and flattenable, once we have support for null-default inline classes). Best regards, Tobias From forax at univ-mlv.fr Mon Jul 22 07:07:12 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 22 Jul 2019 09:07:12 +0200 (CEST) Subject: RFR(XS): 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable In-Reply-To: <306e68c1-d34b-46ab-cd4e-722396286fb1@oracle.com> References: <43a02a7c-c08c-271d-6ea2-78022dbe8380@oracle.com> <1298549412.3670769.1563548569358.JavaMail.zimbra@u-pem.fr> <306e68c1-d34b-46ab-cd4e-722396286fb1@oracle.com> Message-ID: <31772979.56896.1563779232841.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Tobias Hartmann" > ?: "Remi Forax" > Cc: "valhalla-dev" > Envoy?: Lundi 22 Juillet 2019 08:01:37 > Objet: Re: RFR(XS): 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable > Hi R?mi, > > On 19.07.19 17:02, Remi Forax wrote: >> The scalarization has nothing to do with the fact of being flattenable or not, >> the flattenability is a storage property so for value in fields or array >> elements, not for value on the stack. >> >> Being a null-free inline type is enough, you do not have to check if the fields >> are flattenable or not. > > Yes, sure. But this change is about VM/JIT internal code that attempts > scalarization when creating > the C2 IR for loading a constant inline type field with an inline type holder. > And here the term > "flattenable" is currently used interchangeably with "null-free". That's > actually not specific to > the JIT, but just how the VM propagates inline type field specific information > internally. > > Basically, we have three relevant field states: > (1) !flattenable && !flattened => !null-free, !flat, !inline type field > (2) flattenable && !flattened => null-free, !flat, inline type field > (3) flattenable && flattened => null-free, flat, inline type field > > The JIT will attempt scalarization for (2) and (3). > > This simplification will change as soon as there is a possibility to declare > inline type fields that > are null-free and !flattenable (or !null-free and flattenable, once we have > support for null-default > inline classes). for the former, null-free && !flattenable, by definition you don't want to scalarize it, but for the later, null-default, i don't see why it should not be scalarized. IMO, a null-default inline class acts at runtime as a null-free inline class but with an additional special nullcheck when accessing a field, doing a method call, etc. > > Best regards, > Tobias regards, R?mi From tobias.hartmann at oracle.com Mon Jul 22 10:38:59 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 22 Jul 2019 12:38:59 +0200 Subject: RFR(XS): 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable In-Reply-To: <31772979.56896.1563779232841.JavaMail.zimbra@u-pem.fr> References: <43a02a7c-c08c-271d-6ea2-78022dbe8380@oracle.com> <1298549412.3670769.1563548569358.JavaMail.zimbra@u-pem.fr> <306e68c1-d34b-46ab-cd4e-722396286fb1@oracle.com> <31772979.56896.1563779232841.JavaMail.zimbra@u-pem.fr> Message-ID: <5c481949-8217-caee-2acc-c52fb739af51@oracle.com> On 22.07.19 09:07, forax at univ-mlv.fr wrote: > for the former, null-free && !flattenable, by definition you don't want to scalarize it, As you've said "flattenability is a storage property so for value in fields or array elements, not for value on the stack". The JIT might therefore decide to scalarize these as well. > but for the later, null-default, i don't see why it should not be scalarized. > IMO, a null-default inline class acts at runtime as a null-free inline class but with an additional special nullcheck when accessing a field, doing a method call, etc. Yes, sure but we still need to prototype and thoroughly evaluate this. Best regards, Tobias From rwestrel at redhat.com Mon Jul 22 12:42:12 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 22 Jul 2019 14:42:12 +0200 Subject: RFR(M): 8227634: [lworld] Better optimize object array accesses In-Reply-To: <762ca59c-0a04-7b0a-6352-d7eaf84bbc33@oracle.com> References: <762ca59c-0a04-7b0a-6352-d7eaf84bbc33@oracle.com> Message-ID: <87r26i2qcb.fsf@redhat.com> > http://cr.openjdk.java.net/~thartmann/8227634/webrev.00/ Looks good to me. Roland. From rwestrel at redhat.com Mon Jul 22 12:43:16 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 22 Jul 2019 14:43:16 +0200 Subject: RFR(XS): 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable In-Reply-To: <43a02a7c-c08c-271d-6ea2-78022dbe8380@oracle.com> References: <43a02a7c-c08c-271d-6ea2-78022dbe8380@oracle.com> Message-ID: <87o91m2qaj.fsf@redhat.com> > http://cr.openjdk.java.net/~thartmann/8228367/webrev.00/ Looks good to me. Roland. From rwestrel at redhat.com Mon Jul 22 12:44:20 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 22 Jul 2019 14:44:20 +0200 Subject: RFR(S): 8228416: [lworld] C2 compilation fails with assert(raw_val == __null) failed: val may not be null In-Reply-To: <7acd4eae-1878-16c9-ce05-56f45ee74c17@oracle.com> References: <7acd4eae-1878-16c9-ce05-56f45ee74c17@oracle.com> Message-ID: <87lfwq2q8r.fsf@redhat.com> > http://cr.openjdk.java.net/~thartmann/8228416/webrev.00/ Looks good to me. Roland. From tobias.hartmann at oracle.com Mon Jul 22 12:56:20 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 22 Jul 2019 14:56:20 +0200 Subject: RFR(M): 8227634: [lworld] Better optimize object array accesses In-Reply-To: <87r26i2qcb.fsf@redhat.com> References: <762ca59c-0a04-7b0a-6352-d7eaf84bbc33@oracle.com> <87r26i2qcb.fsf@redhat.com> Message-ID: Thanks Roland! Best regards, Tobias On 22.07.19 14:42, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8227634/webrev.00/ > > Looks good to me. > > Roland. > From tobias.hartmann at oracle.com Mon Jul 22 12:56:39 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 22 Jul 2019 14:56:39 +0200 Subject: RFR(S): 8228416: [lworld] C2 compilation fails with assert(raw_val == __null) failed: val may not be null In-Reply-To: <87lfwq2q8r.fsf@redhat.com> References: <7acd4eae-1878-16c9-ce05-56f45ee74c17@oracle.com> <87lfwq2q8r.fsf@redhat.com> Message-ID: <21b58aaa-362d-0b2b-ca4f-43e9d33af35a@oracle.com> Thanks Roland! Best regards, Tobias On 22.07.19 14:44, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8228416/webrev.00/ > > Looks good to me. > > Roland. > From tobias.hartmann at oracle.com Mon Jul 22 12:58:19 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 22 Jul 2019 12:58:19 +0000 Subject: hg: valhalla/valhalla: 8227634: [lworld] Better optimize object array accesses Message-ID: <201907221258.x6MCwJH3003459@aojmv0008.oracle.com> Changeset: 383439861abd Author: thartmann Date: 2019-07-22 14:58 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/383439861abd 8227634: [lworld] Better optimize object array accesses Reviewed-by: roland ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopUnswitch.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/valuetypenode.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestBasicFunctionality.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestLWorld.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestMethodHandles.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNullableArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java From tobias.hartmann at oracle.com Mon Jul 22 12:56:30 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 22 Jul 2019 14:56:30 +0200 Subject: RFR(XS): 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable In-Reply-To: <87o91m2qaj.fsf@redhat.com> References: <43a02a7c-c08c-271d-6ea2-78022dbe8380@oracle.com> <87o91m2qaj.fsf@redhat.com> Message-ID: <3b7baaa2-73ea-3f5d-9912-6bb59b331d39@oracle.com> Thanks Roland! Best regards, Tobias On 22.07.19 14:43, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8228367/webrev.00/ > > Looks good to me. > > Roland. > From tobias.hartmann at oracle.com Mon Jul 22 12:59:55 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 22 Jul 2019 12:59:55 +0000 Subject: hg: valhalla/valhalla: 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable Message-ID: <201907221259.x6MCxu5l004070@aojmv0008.oracle.com> Changeset: dc499c78becd Author: thartmann Date: 2019-07-22 14:59 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/dc499c78becd 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable Reviewed-by: roland ! src/hotspot/share/opto/valuetypenode.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNullableValueTypes.java From tobias.hartmann at oracle.com Mon Jul 22 13:01:13 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 22 Jul 2019 13:01:13 +0000 Subject: hg: valhalla/valhalla: 8228416: [lworld] C2 compilation fails with assert(raw_val == __null) failed: val may not be null Message-ID: <201907221301.x6MD1E4j004346@aojmv0008.oracle.com> Changeset: f3cd28d18c08 Author: thartmann Date: 2019-07-22 15:01 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f3cd28d18c08 8228416: [lworld] C2 compilation fails with assert(raw_val == __null) failed: val may not be null Reviewed-by: roland ! src/hotspot/share/opto/graphKit.cpp From tobias.hartmann at oracle.com Mon Jul 22 14:17:14 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 22 Jul 2019 14:17:14 +0000 Subject: hg: valhalla/valhalla: [lworld] Fixed duplicate test name in TestArrays.java Message-ID: <201907221417.x6MEHFEh021552@aojmv0008.oracle.com> Changeset: f1a3e0175d05 Author: thartmann Date: 2019-07-22 16:17 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f1a3e0175d05 [lworld] Fixed duplicate test name in TestArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java From ioi.lam at oracle.com Wed Jul 24 05:30:20 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 23 Jul 2019 22:30:20 -0700 Subject: RFR 8227494 [lworld][c1] Optimize withfield bytecode into putfield Message-ID: <75a71698-cfd9-485f-6875-db6b4efccce5@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8227494 http://cr.openjdk.java.net/~iklam/valhalla/8227494-withfield-optimization.v01/ This optimization significantly reduces the amount of code generated by C1 for withfield bytecodes. In the methods of value classes, it's quite common to have a sequence like this, where we load a value object from a local slot, and overwrite the same local slot with a modified copy of the value object. ???? defaultvalue #1 // class compiler/valhalla/valuetypes/MyValue1 ???? astore 9 ???? ... ???? iload_0 ???? aload 9 ???? swap ???? withfield #7 // Field x:I ???? astore 9 If this object was created by defaultvalue, and has not escaped, and is not stored in any other local slots, we can effectively treat the withfield/astore sequence as a single putfield bytecode. I implemented a very rudimentary escape analysis in c1_GraphBuilder.cpp. It seems like there's no need to follow back branches like this: ??????? static FooValue test4() { ??????????? FooValue v = FooValue.default; ??????????? for (int i=1; i<=2; i++) { ??????????????? v = __WithField(v.x, i); ??????????????? v = __WithField(v.y, i); ??????????????? set_foo_static_if_null(v); ??????????? } ??????????? return v; ??????? } The local slot for "v" in the loop body is a Phi node (not a NewValueTypeInstance node), so it will fail the "obj->is_optimizable_for_withfield()" check (which will only return true from NewValueTypeInstance) in GraphBuilder::withfield(). Thanks - Ioi From tobias.hartmann at oracle.com Thu Jul 25 08:59:45 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 25 Jul 2019 10:59:45 +0200 Subject: RFR 8227494 [lworld][c1] Optimize withfield bytecode into putfield In-Reply-To: <75a71698-cfd9-485f-6875-db6b4efccce5@oracle.com> References: <75a71698-cfd9-485f-6875-db6b4efccce5@oracle.com> Message-ID: Hi Ioi, this looks good to me! Why is the change in c1_GraphBuilder.cpp:1879 necessary? Best regards, Tobias On 24.07.19 07:30, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8227494 > http://cr.openjdk.java.net/~iklam/valhalla/8227494-withfield-optimization.v01/ > > > This optimization significantly reduces the amount of code generated by C1 for > withfield bytecodes. > > In the methods of value classes, it's quite common to have a sequence like > this, where we load a value object from a local slot, and overwrite the same local > slot with a modified copy of the value object. > > ???? defaultvalue #1 // class compiler/valhalla/valuetypes/MyValue1 > ???? astore 9 > ???? ... > ???? iload_0 > ???? aload 9 > ???? swap > ???? withfield #7 // Field x:I > ???? astore 9 > > If this object was created by defaultvalue, and has not escaped, and is not stored > in any other local slots, we can effectively treat the withfield/astore > sequence as a single putfield bytecode. > > I implemented a very rudimentary escape analysis in c1_GraphBuilder.cpp. It seems like > there's no need to follow back branches like this: > > ??????? static FooValue test4() { > ??????????? FooValue v = FooValue.default; > ??????????? for (int i=1; i<=2; i++) { > ??????????????? v = __WithField(v.x, i); > ??????????????? v = __WithField(v.y, i); > ??????????????? set_foo_static_if_null(v); > ??????????? } > > ??????????? return v; > ??????? } > > The local slot for "v" in the loop body is a Phi node (not a NewValueTypeInstance node), > so it will fail the "obj->is_optimizable_for_withfield()" check (which will only return true > from NewValueTypeInstance) in GraphBuilder::withfield(). > > Thanks > - Ioi > From ioi.lam at oracle.com Thu Jul 25 20:32:06 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 25 Jul 2019 13:32:06 -0700 Subject: RFR 8227494 [lworld][c1] Optimize withfield bytecode into putfield In-Reply-To: References: <75a71698-cfd9-485f-6875-db6b4efccce5@oracle.com> Message-ID: <924f5958-ddde-3a07-4b5f-c447d528e075@oracle.com> Hi Tobias, thanks for the review. On 7/25/2019 1:59 AM, Tobias Hartmann wrote: > Hi Ioi, > > this looks good to me! > > Why is the change in c1_GraphBuilder.cpp:1879 necessary? I have modified the line to the following: ? if (!holder->is_loaded() ????? || needs_patching /* FIXME: 8228634 - field_modify->will_link() may incorrectly return false */ ????? ) { I'll add more descriptions into the bug, but so far it seems to affect only with __Withfield() macros that operates on the final fields of other classes. It doesn't affect "normal" Java code that initializes the fields of an inline class in its own method. Thanks - Ioi > Best regards, > Tobias > > On 24.07.19 07:30, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8227494 >> http://cr.openjdk.java.net/~iklam/valhalla/8227494-withfield-optimization.v01/ >> >> >> This optimization significantly reduces the amount of code generated by C1 for >> withfield bytecodes. >> >> In the methods of value classes, it's quite common to have a sequence like >> this, where we load a value object from a local slot, and overwrite the same local >> slot with a modified copy of the value object. >> >> ???? defaultvalue #1 // class compiler/valhalla/valuetypes/MyValue1 >> ???? astore 9 >> ???? ... >> ???? iload_0 >> ???? aload 9 >> ???? swap >> ???? withfield #7 // Field x:I >> ???? astore 9 >> >> If this object was created by defaultvalue, and has not escaped, and is not stored >> in any other local slots, we can effectively treat the withfield/astore >> sequence as a single putfield bytecode. >> >> I implemented a very rudimentary escape analysis in c1_GraphBuilder.cpp. It seems like >> there's no need to follow back branches like this: >> >> ??????? static FooValue test4() { >> ??????????? FooValue v = FooValue.default; >> ??????????? for (int i=1; i<=2; i++) { >> ??????????????? v = __WithField(v.x, i); >> ??????????????? v = __WithField(v.y, i); >> ??????????????? set_foo_static_if_null(v); >> ??????????? } >> >> ??????????? return v; >> ??????? } >> >> The local slot for "v" in the loop body is a Phi node (not a NewValueTypeInstance node), >> so it will fail the "obj->is_optimizable_for_withfield()" check (which will only return true >> from NewValueTypeInstance) in GraphBuilder::withfield(). >> >> Thanks >> - Ioi >> From ioi.lam at oracle.com Thu Jul 25 21:13:26 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Thu, 25 Jul 2019 21:13:26 +0000 Subject: hg: valhalla/valhalla: 8227494: [lworld][c1] Optimize withfield bytecode into putfield Message-ID: <201907252113.x6PLDRoX008598@aojmv0008.oracle.com> Changeset: ab1e0ac6b32f Author: iklam Date: 2019-07-25 13:34 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ab1e0ac6b32f 8227494: [lworld][c1] Optimize withfield bytecode into putfield Reviewed-by: thartmann ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_GraphBuilder.hpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_InstructionPrinter.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestOnStackReplacement.java + test/hotspot/jtreg/compiler/valhalla/valuetypes/TestWithfieldC1.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java From ioi.lam at oracle.com Thu Jul 25 22:35:36 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 25 Jul 2019 15:35:36 -0700 Subject: RFR 8228633 [lworld][c1] method invocation fails if the return type is an unloaded Q type Message-ID: <03cbf633-a4db-48f5-1dba-98ee75f49940@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8228633 http://cr.openjdk.java.net/~iklam/valhalla/8228633-unloaded-return-q-type.v01/ Bug: When a C1-compiled method A calls a method B with a return type "QT;", but T has not be loaded at the time of compilation, the caller will not check if the returned value is passed as unpacked fields. Fix: I added a new function ciSignature::maybe_returns_never_null(), so we would always generate the "test $rax, 0x1" check in this situation. The check may not be necessary if it turns out that type T is too large to be returned as fields, but such a check is harmless. Thanks - Ioi From tobias.hartmann at oracle.com Fri Jul 26 05:27:34 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 26 Jul 2019 07:27:34 +0200 Subject: RFR 8227494 [lworld][c1] Optimize withfield bytecode into putfield In-Reply-To: <924f5958-ddde-3a07-4b5f-c447d528e075@oracle.com> References: <75a71698-cfd9-485f-6875-db6b4efccce5@oracle.com> <924f5958-ddde-3a07-4b5f-c447d528e075@oracle.com> Message-ID: <8b2ebc8c-0910-cb26-7704-8d52e53a1e6f@oracle.com> Hi Ioi, okay, thanks for the explanation. Best regards, Tobias On 25.07.19 22:32, Ioi Lam wrote: > Hi Tobias, thanks for the review. > > > On 7/25/2019 1:59 AM, Tobias Hartmann wrote: >> Hi Ioi, >> >> this looks good to me! >> >> Why is the change in c1_GraphBuilder.cpp:1879 necessary? > > I have modified the line to the following: > > ? if (!holder->is_loaded() > ????? || needs_patching /* FIXME: 8228634 - field_modify->will_link() may incorrectly return false */ > ????? ) { > > I'll add more descriptions into the bug, but so far it seems to affect only with __Withfield() > macros that operates on the final fields of other classes. It doesn't affect "normal" Java code that > initializes the fields of an inline class in its own method. > > Thanks > - Ioi > >> Best regards, >> Tobias >> >> On 24.07.19 07:30, Ioi Lam wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8227494 >>> http://cr.openjdk.java.net/~iklam/valhalla/8227494-withfield-optimization.v01/ >>> >>> >>> This optimization significantly reduces the amount of code generated by C1 for >>> withfield bytecodes. >>> >>> In the methods of value classes, it's quite common to have a sequence like >>> this, where we load a value object from a local slot, and overwrite the same local >>> slot with a modified copy of the value object. >>> >>> ????? defaultvalue #1 // class compiler/valhalla/valuetypes/MyValue1 >>> ????? astore 9 >>> ????? ... >>> ????? iload_0 >>> ????? aload 9 >>> ????? swap >>> ????? withfield #7 // Field x:I >>> ????? astore 9 >>> >>> If this object was created by defaultvalue, and has not escaped, and is not stored >>> in any other local slots, we can effectively treat the withfield/astore >>> sequence as a single putfield bytecode. >>> >>> I implemented a very rudimentary escape analysis in c1_GraphBuilder.cpp. It seems like >>> there's no need to follow back branches like this: >>> >>> ???????? static FooValue test4() { >>> ???????????? FooValue v = FooValue.default; >>> ???????????? for (int i=1; i<=2; i++) { >>> ???????????????? v = __WithField(v.x, i); >>> ???????????????? v = __WithField(v.y, i); >>> ???????????????? set_foo_static_if_null(v); >>> ???????????? } >>> >>> ???????????? return v; >>> ???????? } >>> >>> The local slot for "v" in the loop body is a Phi node (not a NewValueTypeInstance node), >>> so it will fail the "obj->is_optimizable_for_withfield()" check (which will only return true >>> from NewValueTypeInstance) in GraphBuilder::withfield(). >>> >>> Thanks >>> - Ioi >>> > From info at michaelhoffer.de Fri Jul 26 10:36:48 2019 From: info at michaelhoffer.de (Michael Hoffer) Date: Fri, 26 Jul 2019 12:36:48 +0200 Subject: ArrayStoreException: bug or expected behavior? Message-ID: <387826C0-4AAA-4F5C-9248-820C38B6EE47@michaelhoffer.de> Hi all, I finally found the time to play with the newest Valhalla build. We have a lot of use cases for this in the scientific community. Thanks for working on it. I prepared a small test program that throws an ArrayStoreException during the assignment of an "inline value" to an array. I wanted to test the behavior of casting between "inline" and the nullable "?" type and interfaces. My expectations are that such errors should be prevented by the type system and should be discovered at compile-time. Either Point2D shouldn?t be allowed to implement the Point2DI interface (hopefully, that?s not the case) or the assignment of the points-array with an array of "inline values? should be prevented (which is better). Is this a bug or the expected behavior of the preview build? Regards, Michael -- Dr. Michael Hoffer Web: mihosoft.eu Twitter: @mihosoft Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) Goethe-Universit?t Kettenhofweg 139 60325 Frankfurt am Main phone: +49 69 798 25254 info at michaelhoffer.de /** *

* How to reproduce the behavior/potential bug: * * Compile this code with jdk-14-valhalla+1-8 (2019/7/4): * * 

 * javac Main.java && java Main
 *
* *

*

* Actual behavior: a java.lang.ArrayStoreException is thrown * unexpectedly in line 33. *

*

* Expected behavior: compile-time error that prevents the problematic * assignment in line 30. *

* * @author Michael Hoffer <info at michaelhoffer.de> */ public class Main { public static void main(String[] args) { int n = 100_000_000; System.out.println("> creating " + n + " points"); Point2DI[] points = new Point2D[n]; for(int i = 0; i < points.length;i++) { points[i] = new Point2DCls(i, i); } } static interface Point2DI { double getX(); double getY(); } static inline class Point2D implements Point2DI { public double x; public double y; Point2D(double x, double y) { this.x = x; this.y = y; } @Override public double getX() { return x; } @Override public double getY() { return y; } } static class Point2DCls implements Point2DI { public double x; public double y; Point2DCls(double x, double y) { this.x = x; this.y = y; } @Override public double getX() { return x; } @Override public double getY() { return y; } } } // end class Main From tobias.hartmann at oracle.com Fri Jul 26 11:06:27 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 26 Jul 2019 13:06:27 +0200 Subject: ArrayStoreException: bug or expected behavior? In-Reply-To: <387826C0-4AAA-4F5C-9248-820C38B6EE47@michaelhoffer.de> References: <387826C0-4AAA-4F5C-9248-820C38B6EE47@michaelhoffer.de> Message-ID: <0b816ae7-7899-20c5-78fb-bf383a5e7689@oracle.com> Hi Michael, thanks for trying out inline types! I just had a quick look at this but when removing the "inline" from Point2D and executing with latest Java, you get an ArrayStoreException exception as well (and no compile-time warning/error). So if I don't miss anything, this isn't specific to inline types and therefore expected behavior. Best regards, Tobias On 26.07.19 12:36, Michael Hoffer wrote: > Hi all, > > I finally found the time to play with the newest Valhalla build. We have a lot of use cases for this in the scientific community. Thanks for working on it. > > I prepared a small test program that throws an ArrayStoreException during the assignment of an "inline value" to an array. I wanted to test the behavior of casting between "inline" and the nullable "?" type and interfaces. > > My expectations are that such errors should be prevented by the type system and should be discovered at compile-time. Either Point2D shouldn?t be allowed to implement the Point2DI interface (hopefully, that?s not the case) or the assignment of the points-array with an array of "inline values? should be prevented (which is better). > > Is this a bug or the expected behavior of the preview build? > > Regards, > Michael > > -- > Dr. Michael Hoffer > > Web: mihosoft.eu > Twitter: @mihosoft > > Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) > Goethe-Universit?t > Kettenhofweg 139 > 60325 Frankfurt am Main > phone: +49 69 798 25254 > info at michaelhoffer.de > > > /** > *

> * How to reproduce the behavior/potential bug: > * > * Compile this code with jdk-14-valhalla+1-8 (2019/7/4): > * > * 

>  * javac Main.java && java Main
>  *
> * > *

> *

> * Actual behavior: a java.lang.ArrayStoreException is thrown > * unexpectedly in line 33. > *

> *

> * Expected behavior: compile-time error that prevents the problematic > * assignment in line 30. > *

> * > * @author Michael Hoffer <info at michaelhoffer.de> > */ > public class Main { > public static void main(String[] args) { > > int n = 100_000_000; > > System.out.println("> creating " + n + " points"); > > Point2DI[] points = new Point2D[n]; > > for(int i = 0; i < points.length;i++) { > points[i] = new Point2DCls(i, i); > } > } > > static interface Point2DI { > double getX(); > double getY(); > } > > static inline class Point2D implements Point2DI { > public double x; > public double y; > > Point2D(double x, double y) { > this.x = x; > this.y = y; > } > > @Override > public double getX() { > return x; > } > > @Override > public double getY() { > return y; > } > } > > static class Point2DCls implements Point2DI { > public double x; > public double y; > > Point2DCls(double x, double y) { > this.x = x; > this.y = y; > } > > @Override > public double getX() { > return x; > } > > @Override > public double getY() { > return y; > } > } > } // end class Main > > > > > > > From info at michaelhoffer.de Fri Jul 26 11:19:51 2019 From: info at michaelhoffer.de (Michael Hoffer) Date: Fri, 26 Jul 2019 13:19:51 +0200 Subject: ArrayStoreException: bug or expected behavior? In-Reply-To: <0b816ae7-7899-20c5-78fb-bf383a5e7689@oracle.com> References: <387826C0-4AAA-4F5C-9248-820C38B6EE47@michaelhoffer.de> <0b816ae7-7899-20c5-78fb-bf383a5e7689@oracle.com> Message-ID: <8C545798-2153-4581-BB2F-2F138C34F49F@michaelhoffer.de> Hi Tobias, thanks for your quick response. You are right. I was too focused on inline types and didn?t see what actually caused the issue. So the root of the problem is that Java treats a Point2D[] array as a subtype of Point2DI[]. But that?s just wrong. This is indeed known and therefore expected behavior. Still feels broken though. Regards, Michael -- Dr. Michael Hoffer Web: mihosoft.eu Twitter: @mihosoft Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) Goethe-Universit?t Kettenhofweg 139 60325 Frankfurt am Main phone: +49 69 798 25254 info at michaelhoffer.de > Am 26.07.2019 um 13:06 schrieb Tobias Hartmann : > > Hi Michael, > > thanks for trying out inline types! > > I just had a quick look at this but when removing the "inline" from Point2D and executing with > latest Java, you get an ArrayStoreException exception as well (and no compile-time warning/error). > > So if I don't miss anything, this isn't specific to inline types and therefore expected behavior. > > Best regards, > Tobias > > On 26.07.19 12:36, Michael Hoffer wrote: >> Hi all, >> >> I finally found the time to play with the newest Valhalla build. We have a lot of use cases for this in the scientific community. Thanks for working on it. >> >> I prepared a small test program that throws an ArrayStoreException during the assignment of an "inline value" to an array. I wanted to test the behavior of casting between "inline" and the nullable "?" type and interfaces. >> >> My expectations are that such errors should be prevented by the type system and should be discovered at compile-time. Either Point2D shouldn?t be allowed to implement the Point2DI interface (hopefully, that?s not the case) or the assignment of the points-array with an array of "inline values? should be prevented (which is better). >> >> Is this a bug or the expected behavior of the preview build? >> >> Regards, >> Michael >> >> -- >> Dr. Michael Hoffer >> >> Web: mihosoft.eu >> Twitter: @mihosoft >> >> Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) >> Goethe-Universit?t >> Kettenhofweg 139 >> 60325 Frankfurt am Main >> phone: +49 69 798 25254 >> info at michaelhoffer.de >> >> >> /** >> *

>> * How to reproduce the behavior/potential bug: >> * >> * Compile this code with jdk-14-valhalla+1-8 (2019/7/4): >> * >> * 

>> * javac Main.java && java Main
>> *
>> * >> *

>> *

>> * Actual behavior: a java.lang.ArrayStoreException is thrown >> * unexpectedly in line 33. >> *

>> *

>> * Expected behavior: compile-time error that prevents the problematic >> * assignment in line 30. >> *

>> * >> * @author Michael Hoffer <info at michaelhoffer.de> >> */ >> public class Main { >> public static void main(String[] args) { >> >> int n = 100_000_000; >> >> System.out.println("> creating " + n + " points"); >> >> Point2DI[] points = new Point2D[n]; >> >> for(int i = 0; i < points.length;i++) { >> points[i] = new Point2DCls(i, i); >> } >> } >> >> static interface Point2DI { >> double getX(); >> double getY(); >> } >> >> static inline class Point2D implements Point2DI { >> public double x; >> public double y; >> >> Point2D(double x, double y) { >> this.x = x; >> this.y = y; >> } >> >> @Override >> public double getX() { >> return x; >> } >> >> @Override >> public double getY() { >> return y; >> } >> } >> >> static class Point2DCls implements Point2DI { >> public double x; >> public double y; >> >> Point2DCls(double x, double y) { >> this.x = x; >> this.y = y; >> } >> >> @Override >> public double getX() { >> return x; >> } >> >> @Override >> public double getY() { >> return y; >> } >> } >> } // end class Main >> >> >> >> >> >> >> From info at michaelhoffer.de Fri Jul 26 11:32:53 2019 From: info at michaelhoffer.de (Michael Hoffer) Date: Fri, 26 Jul 2019 13:32:53 +0200 Subject: ArrayStoreException: bug or expected behavior? In-Reply-To: <8C545798-2153-4581-BB2F-2F138C34F49F@michaelhoffer.de> References: <387826C0-4AAA-4F5C-9248-820C38B6EE47@michaelhoffer.de> <0b816ae7-7899-20c5-78fb-bf383a5e7689@oracle.com> <8C545798-2153-4581-BB2F-2F138C34F49F@michaelhoffer.de> Message-ID: <9E499050-9669-45E0-ADFA-1C0D986C0CF1@michaelhoffer.de> A follow-up question: the following code automatically translates Point2D into Point2D?. Is this assumption correct? Does this mean that the reduction in required memory and the cache optimal layout are lost in this case? Point2DI[] points = new Point2DI[n]; for(int i = 0; i < points.length;i++) { points[i] = new Point2D(i, i); } Regards, Michael -- Dr. Michael Hoffer Web: mihosoft.eu Twitter: @mihosoft Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) Goethe-Universit?t Kettenhofweg 139 60325 Frankfurt am Main phone: +49 69 798 25254 info at michaelhoffer.de > Am 26.07.2019 um 13:19 schrieb Michael Hoffer : > > Hi Tobias, > > thanks for your quick response. You are right. I was too focused on inline types and didn?t see what actually caused the issue. So the root of the problem is that Java treats a Point2D[] array as a subtype of Point2DI[]. But that?s just wrong. This is indeed known and therefore expected behavior. Still feels broken though. > > Regards, > Michael > > -- > Dr. Michael Hoffer > > Web: mihosoft.eu > Twitter: @mihosoft > > Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) > Goethe-Universit?t > Kettenhofweg 139 > 60325 Frankfurt am Main > phone: +49 69 798 25254 > info at michaelhoffer.de > >> Am 26.07.2019 um 13:06 schrieb Tobias Hartmann : >> >> Hi Michael, >> >> thanks for trying out inline types! >> >> I just had a quick look at this but when removing the "inline" from Point2D and executing with >> latest Java, you get an ArrayStoreException exception as well (and no compile-time warning/error). >> >> So if I don't miss anything, this isn't specific to inline types and therefore expected behavior. >> >> Best regards, >> Tobias >> >> On 26.07.19 12:36, Michael Hoffer wrote: >>> Hi all, >>> >>> I finally found the time to play with the newest Valhalla build. We have a lot of use cases for this in the scientific community. Thanks for working on it. >>> >>> I prepared a small test program that throws an ArrayStoreException during the assignment of an "inline value" to an array. I wanted to test the behavior of casting between "inline" and the nullable "?" type and interfaces. >>> >>> My expectations are that such errors should be prevented by the type system and should be discovered at compile-time. Either Point2D shouldn?t be allowed to implement the Point2DI interface (hopefully, that?s not the case) or the assignment of the points-array with an array of "inline values? should be prevented (which is better). >>> >>> Is this a bug or the expected behavior of the preview build? >>> >>> Regards, >>> Michael >>> >>> -- >>> Dr. Michael Hoffer >>> >>> Web: mihosoft.eu >>> Twitter: @mihosoft >>> >>> Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) >>> Goethe-Universit?t >>> Kettenhofweg 139 >>> 60325 Frankfurt am Main >>> phone: +49 69 798 25254 >>> info at michaelhoffer.de >>> >>> >>> /** >>> *

>>> * How to reproduce the behavior/potential bug: >>> * >>> * Compile this code with jdk-14-valhalla+1-8 (2019/7/4): >>> * >>> * 

>>> * javac Main.java && java Main
>>> *
>>> * >>> *

>>> *

>>> * Actual behavior: a java.lang.ArrayStoreException is thrown >>> * unexpectedly in line 33. >>> *

>>> *

>>> * Expected behavior: compile-time error that prevents the problematic >>> * assignment in line 30. >>> *

>>> * >>> * @author Michael Hoffer <info at michaelhoffer.de> >>> */ >>> public class Main { >>> public static void main(String[] args) { >>> >>> int n = 100_000_000; >>> >>> System.out.println("> creating " + n + " points"); >>> >>> Point2DI[] points = new Point2D[n]; >>> >>> for(int i = 0; i < points.length;i++) { >>> points[i] = new Point2DCls(i, i); >>> } >>> } >>> >>> static interface Point2DI { >>> double getX(); >>> double getY(); >>> } >>> >>> static inline class Point2D implements Point2DI { >>> public double x; >>> public double y; >>> >>> Point2D(double x, double y) { >>> this.x = x; >>> this.y = y; >>> } >>> >>> @Override >>> public double getX() { >>> return x; >>> } >>> >>> @Override >>> public double getY() { >>> return y; >>> } >>> } >>> >>> static class Point2DCls implements Point2DI { >>> public double x; >>> public double y; >>> >>> Point2DCls(double x, double y) { >>> this.x = x; >>> this.y = y; >>> } >>> >>> @Override >>> public double getX() { >>> return x; >>> } >>> >>> @Override >>> public double getY() { >>> return y; >>> } >>> } >>> } // end class Main >>> >>> >>> >>> >>> >>> >>> > From tobias.hartmann at oracle.com Fri Jul 26 11:18:47 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 26 Jul 2019 13:18:47 +0200 Subject: RFR 8228633 [lworld][c1] method invocation fails if the return type is an unloaded Q type In-Reply-To: <03cbf633-a4db-48f5-1dba-98ee75f49940@oracle.com> References: <03cbf633-a4db-48f5-1dba-98ee75f49940@oracle.com> Message-ID: <503b0244-bcfa-e735-0734-d020bd594a4d@oracle.com> Hi Ioi, this looks good to me. Just a small suggestion: The ValueTypeTest class defines random values rI and rL that you can use to initialize fields like Test104Value::x0 and then verify the value. Also, the comment in ciSignature.cpp:137 should be "maybe_returns_never_null". Thanks, Tobias On 26.07.19 00:35, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8228633 > http://cr.openjdk.java.net/~iklam/valhalla/8228633-unloaded-return-q-type.v01/ > > Bug: > > When a C1-compiled method A calls a method B with a return type "QT;", > but T has not be loaded at the time of compilation, the caller will > not check if the returned value is passed as unpacked fields. > > Fix: > > I added a new function ciSignature::maybe_returns_never_null(), so we would > always generate the "test $rax, 0x1" check in this situation. The check may not > be necessary if it turns out that type T is too large to be returned as fields, > but such a check is harmless. > > Thanks > - Ioi > From tobias.hartmann at oracle.com Fri Jul 26 11:54:45 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 26 Jul 2019 13:54:45 +0200 Subject: ArrayStoreException: bug or expected behavior? In-Reply-To: <9E499050-9669-45E0-ADFA-1C0D986C0CF1@michaelhoffer.de> References: <387826C0-4AAA-4F5C-9248-820C38B6EE47@michaelhoffer.de> <0b816ae7-7899-20c5-78fb-bf383a5e7689@oracle.com> <8C545798-2153-4581-BB2F-2F138C34F49F@michaelhoffer.de> <9E499050-9669-45E0-ADFA-1C0D986C0CF1@michaelhoffer.de> Message-ID: On 26.07.19 13:32, Michael Hoffer wrote: > A follow-up question: the following code automatically translates Point2D into Point2D?. Is this > assumption correct? It does not translate Point2D to Point2D? but simply allocates the inline type on the Java heap and stores a reference to it in the interface array. > Does this mean that the reduction in required memory and the cache optimal > layout are lost in this case? If you are referring to the memory layout of a flattened array Point2D[] then yes, these are not available with your interface array. In memory terms, this creates an array of pointers: > ? ? ? ? Point2DI[] points = new Point2DI[n]; And the following loop stores pointers to Point2D into that array: > ? ? ? ? for(int i = 0; i < points.length;i++) { > ? ? ? ? ? ? points[i] = new Point2D(i, i); > ? ? ? ? } Other than memory layout, one of the biggest optimization opportunities for inline types is that they can always be scalarized by the just in time compiler (i.e. passed in registers or on the stack). Hope that helps. Best regards, Tobias From info at michaelhoffer.de Fri Jul 26 12:09:34 2019 From: info at michaelhoffer.de (Michael Hoffer) Date: Fri, 26 Jul 2019 14:09:34 +0200 Subject: ArrayStoreException: bug or expected behavior? In-Reply-To: References: <387826C0-4AAA-4F5C-9248-820C38B6EE47@michaelhoffer.de> <0b816ae7-7899-20c5-78fb-bf383a5e7689@oracle.com> <8C545798-2153-4581-BB2F-2F138C34F49F@michaelhoffer.de> <9E499050-9669-45E0-ADFA-1C0D986C0CF1@michaelhoffer.de> Message-ID: <7BF25564-70FB-47B5-8808-FF6EEB060072@michaelhoffer.de> > It does not translate Point2D to Point2D? but simply allocates the inline type on the Java heap and > stores a reference to it in the interface array. That?s good news. So there are no conversion costs involved. > If you are referring to the memory layout of a flattened array Point2D[] then yes, these are not > available with your interface array. Makes sense. > Other than memory layout, one of the biggest optimization opportunities for inline types is that > they can always be scalarized by the just in time compiler (i.e. passed in registers or on the stack). Thanks. That helps a lot! Regards, Michael -- Dr. Michael Hoffer Web: mihosoft.eu Twitter: @mihosoft Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) Goethe-Universit?t Kettenhofweg 139 60325 Frankfurt am Main phone: +49 69 798 25254 info at michaelhoffer.de > Am 26.07.2019 um 13:54 schrieb Tobias Hartmann : > > On 26.07.19 13:32, Michael Hoffer wrote: >> A follow-up question: the following code automatically translates Point2D into Point2D?. Is this >> assumption correct? > > It does not translate Point2D to Point2D? but simply allocates the inline type on the Java heap and > stores a reference to it in the interface array. > >> Does this mean that the reduction in required memory and the cache optimal >> layout are lost in this case? > > If you are referring to the memory layout of a flattened array Point2D[] then yes, these are not > available with your interface array. > > In memory terms, this creates an array of pointers: > >> Point2DI[] points = new Point2DI[n]; > > And the following loop stores pointers to Point2D into that array: > >> for(int i = 0; i < points.length;i++) { >> points[i] = new Point2D(i, i); >> } > > Other than memory layout, one of the biggest optimization opportunities for inline types is that > they can always be scalarized by the just in time compiler (i.e. passed in registers or on the stack). > > Hope that helps. > > Best regards, > Tobias From tobias.hartmann at oracle.com Fri Jul 26 12:50:31 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 26 Jul 2019 14:50:31 +0200 Subject: RFR(XL): JDK-8228441 Field layout requires complete overhaul to efficiently support inline classes In-Reply-To: <9F44BBA3-1415-40F6-BB32-0F67C6DEB4FB@oracle.com> References: <9F44BBA3-1415-40F6-BB32-0F67C6DEB4FB@oracle.com> Message-ID: Hi Fred, just wondering, did you intentionally include the change in compile.cpp? If so, it should be guarded by #ifdef ASSERT but I would suggest to just remove it. Best regards, Tobias On 19.07.19 17:26, Frederic Parain wrote: > Greetings, > > This is the initial request for review for a new code to layout fields. > The current code to compute field layouts is especially ugly and > not fitted to efficiently flatten inline classes. > > This changeset is an almost complete overhaul of the field layout code, > with a new framework to compute layouts and two different allocation > strategies (one for identity classes and one for inline classes). > > CR: https://bugs.openjdk.java.net/browse/JDK-8228441 > Webrev: http://cr.openjdk.java.net/~fparain/layout/webrev.00/ > > This changeset also includes some options and DCMD to ease inspection > of layouts, especially when flattenable fields are involved. > > The changeset doesn?t remove the old layout code, meaning that either > the old code or the new code can be used (controlled by VM flag). > > This code passed tiers 1 to 3 on Valhalla supported platforms. > Some failures have been identified in higher tiers with some @Contended > tests, but they are due to test bugs (tests making relying on wrong > assumptions about field layouts). > > The code contains a lot of comments about the new framework and the > different allocation strategies. Feel free to complain if comments > are not clear enough or if some code need more comments. > > Regarding the huge size of this changeset, and people being in summer > vacation, I?m not planning to push this code in the short term. > > Thank you, > > Fred > From frederic.parain at oracle.com Fri Jul 26 13:36:13 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 26 Jul 2019 09:36:13 -0400 Subject: RFR(XL): JDK-8228441 Field layout requires complete overhaul to efficiently support inline classes In-Reply-To: References: <9F44BBA3-1415-40F6-BB32-0F67C6DEB4FB@oracle.com> Message-ID: Oops, debug code that definitively must be removed. Thank you for spotting it. FYI, Coleen and Mary asked me to port this code to the main line. I?ve prepared a version of it without dependencies to the Valhalla code, and added some missing features (notably, handling of classes with hard coded field offsets, using the hard coded offsets directly instead of tricking the layout algorithm to produce the same offsets). I?ll update the Valhalla webrev to include these changes, so both versions will be mostly in sync. Regards, Fred > On Jul 26, 2019, at 08:50, Tobias Hartmann wrote: > > Hi Fred, > > just wondering, did you intentionally include the change in compile.cpp? If so, it should be guarded > by #ifdef ASSERT but I would suggest to just remove it. > > Best regards, > Tobias > > On 19.07.19 17:26, Frederic Parain wrote: >> Greetings, >> >> This is the initial request for review for a new code to layout fields. >> The current code to compute field layouts is especially ugly and >> not fitted to efficiently flatten inline classes. >> >> This changeset is an almost complete overhaul of the field layout code, >> with a new framework to compute layouts and two different allocation >> strategies (one for identity classes and one for inline classes). >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8228441 >> Webrev: http://cr.openjdk.java.net/~fparain/layout/webrev.00/ >> >> This changeset also includes some options and DCMD to ease inspection >> of layouts, especially when flattenable fields are involved. >> >> The changeset doesn?t remove the old layout code, meaning that either >> the old code or the new code can be used (controlled by VM flag). >> >> This code passed tiers 1 to 3 on Valhalla supported platforms. >> Some failures have been identified in higher tiers with some @Contended >> tests, but they are due to test bugs (tests making relying on wrong >> assumptions about field layouts). >> >> The code contains a lot of comments about the new framework and the >> different allocation strategies. Feel free to complain if comments >> are not clear enough or if some code need more comments. >> >> Regarding the huge size of this changeset, and people being in summer >> vacation, I?m not planning to push this code in the short term. >> >> Thank you, >> >> Fred >> From benjamin.john.evans at gmail.com Sun Jul 28 13:14:47 2019 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Sun, 28 Jul 2019 13:14:47 +0000 Subject: Can't make simple Streams over indirect projects work Message-ID: Hi, I'm probably missing something really obvious, but I've been playing with this code for several days and can't find my bug. Given an inline class defined like this: public inline class OptionalInt { private static final OptionalInt EMPTY = OptionalInt.default; private boolean isPresent = false; private int v = 0; public static OptionalInt empty() { return EMPTY; } public static OptionalInt of(int val) { OptionalInt self = OptionalInt.default; self = __WithField(self.v, val); self = __WithField(self.isPresent, true); return self; } public int getAsInt() { if (!isPresent) throw new NoSuchElementException("No value present"); return v; } public boolean isPresent() { return isPresent; } public void ifPresent(IntConsumer consumer) { if (isPresent) consumer.accept(v); } public int orElse(int other) { return isPresent ? v : other; } } and some code that attempts to use it like this: public final class Main4 { public static void main(String[] args) { List opts = new ArrayList<>(); for (int i=0; i < 5; i++) { opts.add(OptionalInt.of(i)); opts.add(OptionalInt.empty()); opts.add(null); } Integer total = opts.stream() .map((OptionalInt? o) -> { if (o == null) return 0; OptionalInt op = (OptionalInt)o; return op.orElse(0); }) .reduce(0, (x, y) -> x + y); System.out.println("Total: "+ total); } } Then javac barfs like this: bevans$ javac -XDallowWithFieldOperator -XDallowGenericsOverValues javamag/Main4.java javamag/Main4.java:15: error: ')' expected .map((OptionalInt? o) -> { ^ javamag/Main4.java:15: error: : expected .map((OptionalInt? o) -> { ^ javamag/Main4.java:15: error: ';' expected .map((OptionalInt? o) -> { ^ javamag/Main4.java:20: error: illegal start of expression\ }) ^ 4 errors Could some kind person put me out of my misery and tell me what I'm doing wrong here, and what the proper way to express this should be? Thanks, Ben From brian.goetz at oracle.com Sun Jul 28 13:22:48 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 28 Jul 2019 09:22:48 -0400 Subject: Can't make simple Streams over indirect projects work In-Reply-To: References: Message-ID: This is not related to your streams issue, but don?t use __WithField, write a regular ctor. WF is there for testing and will go away. Try rewriting your stream with all explicit types, including generic withesses, To rule out type inference issues. Sent from my MacBook Wheel > On Jul 28, 2019, at 9:14 AM, Ben Evans wrote: > > Hi, > > I'm probably missing something really obvious, but I've been playing > with this code for several days and can't find my bug. > > Given an inline class defined like this: > > public inline class OptionalInt { > private static final OptionalInt EMPTY = OptionalInt.default; > > private boolean isPresent = false; > private int v = 0; > > public static OptionalInt empty() { > return EMPTY; > } > > public static OptionalInt of(int val) { > OptionalInt self = OptionalInt.default; > self = __WithField(self.v, val); > self = __WithField(self.isPresent, true); > return self; > } > > public int getAsInt() { > if (!isPresent) > throw new NoSuchElementException("No value present"); > > return v; > } > > public boolean isPresent() { > return isPresent; > } > > public void ifPresent(IntConsumer consumer) { > if (isPresent) > consumer.accept(v); > } > > public int orElse(int other) { > return isPresent ? v : other; > } > } > > and some code that attempts to use it like this: > > public final class Main4 { > public static void main(String[] args) { > List opts = new ArrayList<>(); > for (int i=0; i < 5; i++) { > opts.add(OptionalInt.of(i)); > opts.add(OptionalInt.empty()); > opts.add(null); > } > > Integer total = opts.stream() > .map((OptionalInt? o) -> { > if (o == null) > return 0; > > OptionalInt op = (OptionalInt)o; > return op.orElse(0); > }) > .reduce(0, (x, y) -> x + y); > > System.out.println("Total: "+ total); > } > } > > Then javac barfs like this: > > bevans$ javac -XDallowWithFieldOperator -XDallowGenericsOverValues > javamag/Main4.java > > javamag/Main4.java:15: error: ')' expected > .map((OptionalInt? o) -> { > ^ > javamag/Main4.java:15: error: : expected > .map((OptionalInt? o) -> { > ^ > javamag/Main4.java:15: error: ';' expected > .map((OptionalInt? o) -> { > ^ > javamag/Main4.java:20: error: illegal start of expression\ > }) > ^ > 4 errors > > Could some kind person put me out of my misery and tell me what I'm > doing wrong here, and what the proper way to express this should be? > > Thanks, > > Ben From benjamin.john.evans at gmail.com Sun Jul 28 14:32:46 2019 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Sun, 28 Jul 2019 14:32:46 +0000 Subject: Can't make simple Streams over indirect projects work In-Reply-To: References: Message-ID: On Sun, 28 Jul 2019 at 13:22, Brian Goetz wrote: > > This is not related to your streams issue, but don?t use __WithField, write a regular ctor. WF is there for testing and will go away. OK! > Try rewriting your stream with all explicit types, including generic withesses, > To rule out type inference issues. This code: Stream soi = opts.stream(); ToIntFunction f = (OptionalInt? o) -> { if (o == null) return 0; OptionalInt op = (OptionalInt)o; return op.orElse(0); }; IntStream sint = soi.mapToInt(f); int total = sint.reduce(0, (x, y) -> x + y); fails with: bevans$ javac -XDallowWithFieldOperator -XDallowGenericsOverValues javamag/Main4.java javamag/Main4.java:18: error: ')' expected ToIntFunction f = (OptionalInt? o) -> { ^ javamag/Main4.java:18: error: : expected ToIntFunction f = (OptionalInt? o) -> { ^ 2 errors whereas the type-inferred form: Stream soi = opts.stream(); ToIntFunction f = o -> { if (o == null) return 0; OptionalInt op = (OptionalInt)o; return op.orElse(0); }; IntStream sint = soi.mapToInt(f); int total = sint.reduce(0, (x, y) -> x + y); fails with this: bevans$ javac -XDallowWithFieldOperator -XDallowGenericsOverValues javamag/Main4.java javamag/Main4.java:19: error: incomparable types: OptionalInt and if (o == null) return 0; ^ javamag/Main4.java:18: error: incompatible types: incompatible parameter types in lambda expression ToIntFunction f = o -> { ^ 2 errors Thanks, Ben From ioi.lam at oracle.com Sun Jul 28 17:25:11 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Sun, 28 Jul 2019 17:25:11 +0000 Subject: hg: valhalla/valhalla: 8228633: [lworld][c1] method invocation fails if the return type is an unloaded Q type Message-ID: <201907281725.x6SHPCNa016538@aojmv0008.oracle.com> Changeset: 2718fd83971d Author: iklam Date: 2019-07-28 10:05 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/2718fd83971d 8228633: [lworld][c1] method invocation fails if the return type is an unloaded Q type Reviewed-by: thartmann ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/ci/ciSignature.cpp ! src/hotspot/share/ci/ciSignature.hpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/signature.hpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestCallingConventionC1.java From ioi.lam at oracle.com Sun Jul 28 21:42:16 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Sun, 28 Jul 2019 21:42:16 +0000 Subject: hg: valhalla/valhalla: 2 new changesets Message-ID: <201907282142.x6SLgHpg027155@aojmv0008.oracle.com> Changeset: f7ad2b61ccfe Author: iklam Date: 2019-07-28 14:08 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f7ad2b61ccfe 8228694: [lworld] Ignore tests scenarios in TestWithfieldC1.java due to JDK-8228693 ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestWithfieldC1.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java Changeset: a6fea066f20f Author: iklam Date: 2019-07-28 14:09 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a6fea066f20f 8228695: [lworld] EnableValhallaC1 and TieredStopAtLevel options should obey TieredCompilation ! src/hotspot/share/runtime/arguments.cpp From dms at samersoff.net Tue Jul 30 11:13:55 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Tue, 30 Jul 2019 14:13:55 +0300 Subject: RFR(L) Valhalla support for AArch64 v.05 In-Reply-To: <87ims04zdz.fsf@redhat.com> References: <885b89a3-3711-6b34-74f6-3bc9199a0292@samersoff.net> <66117c8f-df12-4f93-21e2-9d0de0a3c3c7@samersoff.net> <87ims04zdz.fsf@redhat.com> Message-ID: Roland, If you can push these changes for me, I'll appreciate it. -Dmitry On 17.07.2019 15:30, Roland Westrelin wrote: > > Hi Dmitry, > >> I updated the webrev below to lworld_stable. All tests are passed. >> >> Is there any chance to have the changes reviewed and pushed? > > I went over the changes quickly and while I can't say I reviewed them I > see no reason not to push them. I also propose we nominate you as > valhalla committer so you can proceed with subsequent pushes > yourself. We can either wait until the CFV is over or I can push them > for you. What do you think? > > Roland. > From rwestrel at redhat.com Tue Jul 30 13:34:27 2019 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Tue, 30 Jul 2019 13:34:27 +0000 Subject: hg: valhalla/valhalla: valhalla support for AArch64 Message-ID: <201907301334.x6UDYSqm002098@aojmv0008.oracle.com> Changeset: 8cd372dc26ca Author: dsamersoff Date: 2019-07-30 15:04 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8cd372dc26ca valhalla support for AArch64 ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/abstractInterpreter_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_FrameMap_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/shared/modRefBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shared/modRefBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp ! src/hotspot/cpu/aarch64/interpreterRT_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.hpp ! src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestCallingConvention.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestCallingConventionC1.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestJNICalls.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestLWorld.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNullableArrays.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNullableValueTypes.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestOnStackReplacement.java From forax at univ-mlv.fr Tue Jul 30 16:19:03 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 30 Jul 2019 18:19:03 +0200 (CEST) Subject: Can't make simple Streams over indirect projects work In-Reply-To: References: Message-ID: <764152486.393680.1564503543323.JavaMail.zimbra@u-pem.fr> You have hit 2 different bugs :) first, there is a type inference bug, ToIntFunction mapper = o -> 0; o is inferred as OptionalInt instead of OptionalInt? then there is a grammar bug ToIntFunction mapper = (OptionalInt? o) -> 0; the parser choke on the '?' when declaring the type of the lambda parameter. cheers, R?mi ----- Mail original ----- > De: "Ben Evans" > ?: "Brian Goetz" > Cc: "valhalla-dev" > Envoy?: Dimanche 28 Juillet 2019 16:32:46 > Objet: Re: Can't make simple Streams over indirect projects work > On Sun, 28 Jul 2019 at 13:22, Brian Goetz wrote: >> >> This is not related to your streams issue, but don?t use __WithField, write a >> regular ctor. WF is there for testing and will go away. > > OK! > >> Try rewriting your stream with all explicit types, including generic withesses, >> To rule out type inference issues. > > This code: > > Stream soi = opts.stream(); > ToIntFunction f = (OptionalInt? o) -> { > if (o == null) return 0; > OptionalInt op = (OptionalInt)o; > return op.orElse(0); > }; > IntStream sint = soi.mapToInt(f); > int total = sint.reduce(0, (x, y) -> x + y); > > fails with: > > bevans$ javac -XDallowWithFieldOperator -XDallowGenericsOverValues > javamag/Main4.java > javamag/Main4.java:18: error: ')' expected > ToIntFunction f = (OptionalInt? o) -> { > ^ > javamag/Main4.java:18: error: : expected > ToIntFunction f = (OptionalInt? o) -> { > ^ > 2 errors > > whereas the type-inferred form: > > Stream soi = opts.stream(); > ToIntFunction f = o -> { > if (o == null) return 0; > OptionalInt op = (OptionalInt)o; > return op.orElse(0); > }; > IntStream sint = soi.mapToInt(f); > int total = sint.reduce(0, (x, y) -> x + y); > > fails with this: > > bevans$ javac -XDallowWithFieldOperator -XDallowGenericsOverValues > javamag/Main4.java > javamag/Main4.java:19: error: incomparable types: OptionalInt and > if (o == null) return 0; > ^ > javamag/Main4.java:18: error: incompatible types: incompatible > parameter types in lambda expression > ToIntFunction f = o -> { > ^ > 2 errors > > Thanks, > > Ben From uberto.gama at gmail.com Wed Jul 31 22:04:09 2019 From: uberto.gama at gmail.com (Uberto Barbini) Date: Wed, 31 Jul 2019 23:04:09 +0100 Subject: flattening a String? Message-ID: Hi, I've converted my examples from LW1 to LW2 and I've played a bit. Thanks for all the good work! One thing that bothered me is that all examples were just using numbers, so I've done some experiments to save a String of a fixed length (a reasonable compromise for high performance) in an inline type. This would allow to use them in more use cases including FIX records etc. So far the best I managed is just having a bunch of char fields and mapping them to and from a String. The code is not nice but it works and it should be fast (I've not measured anything yet). Of course, there are many limitations (Unicode and strings longer than 16 chars :)) but the main issue now is that looking at the memory footprint, it seems that it takes 4 bytes for each char, is that correct? I can imagine using int instead to store 4 chars in a more compact way but I wonder if it is possible to do better than this, either now or in the future (flattened arrays of fixed size)? Thank you very much Uberto inline public class User { public final int yearOfBirth; private final SixteenCharString name; public User(String name, int yearOfBirth) { this.yearOfBirth = yearOfBirth; this.name = new SixteenCharString(name); } public String getName(){ return name.getValue(); } } inline public class SixteenCharString { private final char c0; private final char c1; private final char c2; private final char c3; private final char c4; private final char c5; private final char c6; private final char c7; private final char c8; private final char c9; private final char cA; private final char cB; private final char cC; private final char cD; private final char cE; private final char cF; public SixteenCharString(String value){ char[] padded = (value + " ").toCharArray(); int index =0; c0 = padded[index++]; c1 = padded[index++]; c2 = padded[index++]; c3 = padded[index++]; c4 = padded[index++]; c5 = padded[index++]; c6 = padded[index++]; c7 = padded[index++]; c8 = padded[index++]; c9 = padded[index++]; cA = padded[index++]; cB = padded[index++]; cC = padded[index++]; cD = padded[index++]; cE = padded[index++]; cF = padded[index++]; } public String getValue(){ char[] padded = new char[16]; int index =0; padded[index++] = c0; padded[index++] = c1; padded[index++] = c2; padded[index++] = c3; padded[index++] = c4; padded[index++] = c5; padded[index++] = c6; padded[index++] = c7; padded[index++] = c8; padded[index++] = c9; padded[index++] = cA; padded[index++] = cB; padded[index++] = cC; padded[index++] = cD; padded[index++] = cE; padded[index++] = cF; return new String(padded).trim(); } }