From github.com+5010047+kelthuzadx at openjdk.java.net Mon Mar 1 11:49:26 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Mon, 1 Mar 2021 11:49:26 GMT Subject: [lworld] RFR: [lworld] jcmd VM.class_print_layout crash due to NULL cld name Message-ID: Hi, can I have a review of this one-line fix? jcmd VM.class_print_layout crashes when printing classes which loaded by bootstrap loader since these classes has NULL class_loder_data()->name(). But actually, I wonder to know why we don't print the layout by modifications of existing functions in FieldLayoutBuilder::build_layout directly? It seems FieldLayoutBuilder can gather more complete layout information. Thanks, Yang ------------- Commit messages: - jcmd VM.class_print_layout crash due to NULL cld name Changes: https://git.openjdk.java.net/valhalla/pull/354/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=354&range=00 Stats: 74 lines in 2 files changed: 73 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/354.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/354/head:pull/354 PR: https://git.openjdk.java.net/valhalla/pull/354 From github.com+5010047+kelthuzadx at openjdk.java.net Mon Mar 1 11:49:27 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Mon, 1 Mar 2021 11:49:27 GMT Subject: [lworld] RFR: [lworld] jcmd VM.class_print_layout crash due to NULL cld name In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 11:42:07 GMT, Yi Yang wrote: > Hi, can I have a review of this one-line fix? > > jcmd VM.class_print_layout crashes when printing classes which loaded by bootstrap loader since these classes has NULL class_loder_data()->name(). > > But actually, I wonder to know why we don't print the layout by modifications of existing functions in FieldLayoutBuilder::build_layout directly? It seems FieldLayoutBuilder can gather more complete layout information. > > Thanks, > Yang Since I don't have a JBS account, I can not file an issue on that, can anyone help to create an issue, much appreciated.:-) Thanks, Yang ------------- PR: https://git.openjdk.java.net/valhalla/pull/354 From github.com+5010047+kelthuzadx at openjdk.java.net Mon Mar 1 11:55:15 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Mon, 1 Mar 2021 11:55:15 GMT Subject: [lworld] RFR: [lworld] C1 compilation fails when PinAllInstructions is turned on Message-ID: When turning on the -XX:+PinAllInstructions, C1 hits the following assertion: ` # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/qingfeng.yy/valhalla/src/hotspot/share/c1/c1_LIRGenerator.cpp:1524), pid=81974, tid=81994 # assert(!x->is_pinned()) failed: only for unpinned constants ... Stack: [0x00007fc0771fa000,0x00007fc0772fb000], sp=0x00007fc0772f89f0, free space=1018k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x65de6c] LIRGenerator::load_constant(Constant*)+0x2a V [libjvm.so+0x65ee4b] LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_OprDesc*&, ciField*, int)+0x319 V [libjvm.so+0x66209c] LIRGenerator::do_LoadIndexed(LoadIndexed*)+0x846 V [libjvm.so+0x6277c4] LoadIndexed::visit(InstructionVisitor*)+0x2e V [libjvm.so+0x6586ae] LIRGenerator::do_root(Instruction*)+0xfc V [libjvm.so+0x65856e] LIRGenerator::block_do(BlockBegin*)+0x7c V [libjvm.so+0x62696d] BlockList::iterate_forward(BlockClosure*)+0x5d V [libjvm.so+0x61ee24] IR::iterate_linear_scan_order(BlockClosure*)+0x2e V [libjvm.so+0x5ee90b] Compilation::emit_lir()+0x95 V [libjvm.so+0x5ef140] Compilation::compile_java_method()+0x21e V [libjvm.so+0x5ef4af] Compilation::compile_method()+0x107 V [libjvm.so+0x5efd05] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x3bb V [libjvm.so+0x5f3baf] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xd9 V [libjvm.so+0x81a938] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x88a V [libjvm.so+0x81956b] CompileBroker::compiler_thread_loop()+0x3df V [libjvm.so+0x83bef1] CompilerThread::thread_entry(JavaThread*, Thread*)+0x69 V [libjvm.so+0x12fd598] JavaThread::thread_main_inner()+0x14c V [libjvm.so+0x12fd444] JavaThread::run()+0x11e V [libjvm.so+0x12fa630] Thread::call_run()+0x180 V [libjvm.so+0x1028936] thread_native_entry(Thread*)+0x1e4 ` The root cause of this crash is because LIRGenerator::access_sub_element() uses LIRGenerator::load_constant() to load the default value of a primitive class type(constant) into a register, load_constant requires unpinned constant instr, so it unquestionably crashes when PinAllInstructions is enabled. This problem also occurred in many places under `test/hotspot/jtreg/compiler/valhalla`. After applying this patch, they all passed with slowdebug build. Thanks, Yang ------------- Commit messages: - PinAllInstructions hits some assertions Changes: https://git.openjdk.java.net/valhalla/pull/355/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=355&range=00 Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/valhalla/pull/355.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/355/head:pull/355 PR: https://git.openjdk.java.net/valhalla/pull/355 From github.com+5010047+kelthuzadx at openjdk.java.net Mon Mar 1 11:55:15 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Mon, 1 Mar 2021 11:55:15 GMT Subject: [lworld] RFR: [lworld] C1 compilation fails when PinAllInstructions is turned on In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 11:50:07 GMT, Yi Yang wrote: > When turning on the -XX:+PinAllInstructions, C1 hits the following assertion: > > ` > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/qingfeng.yy/valhalla/src/hotspot/share/c1/c1_LIRGenerator.cpp:1524), pid=81974, tid=81994 > # assert(!x->is_pinned()) failed: only for unpinned constants > ... > Stack: [0x00007fc0771fa000,0x00007fc0772fb000], sp=0x00007fc0772f89f0, free space=1018k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x65de6c] LIRGenerator::load_constant(Constant*)+0x2a > V [libjvm.so+0x65ee4b] LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_OprDesc*&, ciField*, int)+0x319 > V [libjvm.so+0x66209c] LIRGenerator::do_LoadIndexed(LoadIndexed*)+0x846 > V [libjvm.so+0x6277c4] LoadIndexed::visit(InstructionVisitor*)+0x2e > V [libjvm.so+0x6586ae] LIRGenerator::do_root(Instruction*)+0xfc > V [libjvm.so+0x65856e] LIRGenerator::block_do(BlockBegin*)+0x7c > V [libjvm.so+0x62696d] BlockList::iterate_forward(BlockClosure*)+0x5d > V [libjvm.so+0x61ee24] IR::iterate_linear_scan_order(BlockClosure*)+0x2e > V [libjvm.so+0x5ee90b] Compilation::emit_lir()+0x95 > V [libjvm.so+0x5ef140] Compilation::compile_java_method()+0x21e > V [libjvm.so+0x5ef4af] Compilation::compile_method()+0x107 > V [libjvm.so+0x5efd05] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x3bb > V [libjvm.so+0x5f3baf] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xd9 > V [libjvm.so+0x81a938] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x88a > V [libjvm.so+0x81956b] CompileBroker::compiler_thread_loop()+0x3df > V [libjvm.so+0x83bef1] CompilerThread::thread_entry(JavaThread*, Thread*)+0x69 > V [libjvm.so+0x12fd598] JavaThread::thread_main_inner()+0x14c > V [libjvm.so+0x12fd444] JavaThread::run()+0x11e > V [libjvm.so+0x12fa630] Thread::call_run()+0x180 > V [libjvm.so+0x1028936] thread_native_entry(Thread*)+0x1e4 > ` > > The root cause of this crash is because LIRGenerator::access_sub_element() uses LIRGenerator::load_constant() to load the default value of a primitive class type(constant) into a register, load_constant requires unpinned constant instr, so it unquestionably crashes when PinAllInstructions is enabled. > > This problem also occurred in many places under `test/hotspot/jtreg/compiler/valhalla`. After applying this patch, they all passed with slowdebug build. > > Thanks, > Yang Again, since I don't have a JBS account, I can not file an issue on that, can anyone help to create an issue, much appreciated.:-) ------------- PR: https://git.openjdk.java.net/valhalla/pull/355 From github.com+5010047+kelthuzadx at openjdk.java.net Mon Mar 1 12:02:05 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Mon, 1 Mar 2021 12:02:05 GMT Subject: [lworld] RFR: [lworld] print out reason information for Deoptimize instruction Message-ID: The instruction printer only tells that there is a deoptimization instruction, but not indicates they are deoptimized due to which class is not loaded. Java ---- static void test1(Object[] arr) { TestValue v = TestValue.default; arr[0] = v; } HIR(OLD) --- . 0 2 a2 deoptimize . 5 1 i3 0 . 7 0 a4 a1[i3] := a2 (L) [rc] What's the type of a2? . 8 0 v5 return HIR(NEW) --- . 0 2 a2 deoptimize [unloaded=Test$TestValue] . 5 1 i3 0 . 7 0 a4 a1[i3] := a2 (L) [rc] . 8 0 v5 return In addition, I restore some comments on LIRGenerator::do_Deoptimize, I'm not sure whether these comments were removed deliberately or accidentally, so please let me know if I did wrong. Thanks! Yang ------------- Commit messages: - print out reason information for deopt instr Changes: https://git.openjdk.java.net/valhalla/pull/356/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=356&range=00 Stats: 16 lines in 4 files changed: 11 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/valhalla/pull/356.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/356/head:pull/356 PR: https://git.openjdk.java.net/valhalla/pull/356 From github.com+5010047+kelthuzadx at openjdk.java.net Mon Mar 1 12:02:06 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Mon, 1 Mar 2021 12:02:06 GMT Subject: [lworld] RFR: [lworld] print out reason information for Deoptimize instruction In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 11:57:08 GMT, Yi Yang wrote: > The instruction printer only tells that there is a deoptimization instruction, but not indicates they are deoptimized due to which class is not loaded. > > Java > ---- > static void test1(Object[] arr) { > TestValue v = TestValue.default; > arr[0] = v; > } > HIR(OLD) > --- > . 0 2 a2 deoptimize > . 5 1 i3 0 > . 7 0 a4 a1[i3] := a2 (L) [rc] What's the type of a2? > . 8 0 v5 return > HIR(NEW) > --- > . 0 2 a2 deoptimize [unloaded=Test$TestValue] > . 5 1 i3 0 > . 7 0 a4 a1[i3] := a2 (L) [rc] > . 8 0 v5 return > > In addition, I restore some comments on LIRGenerator::do_Deoptimize, I'm not sure whether these comments were removed deliberately or accidentally, so please let me know if I did wrong. > > Thanks! > Yang Once again, since I don't have a JBS account, I can not file an issue on that, can anyone help to create an issue, much appreciated.:-) ------------- PR: https://git.openjdk.java.net/valhalla/pull/356 From thartmann at openjdk.java.net Mon Mar 1 12:50:01 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 1 Mar 2021 12:50:01 GMT Subject: [lworld] RFR: [lworld] jcmd VM.class_print_layout crash due to NULL cld name In-Reply-To: References: Message-ID: <6YBVMStoQUiXnmFHkTs5DQFZvFxiD0Tjd9zVnoM6bBY=.da355776-b5db-4ae5-adab-faa9db0f3a6d@github.com> On Mon, 1 Mar 2021 11:46:07 GMT, Yi Yang wrote: >> Hi, can I have a review of this one-line fix? >> >> jcmd VM.class_print_layout crashes when printing classes which loaded by bootstrap loader since these classes has NULL class_loder_data()->name(). >> >> But actually, I wonder to know why we don't print the layout by modifications of existing functions in FieldLayoutBuilder::build_layout directly? It seems FieldLayoutBuilder can gather more complete layout information. >> >> Thanks, >> Yang > > Since I don't have a JBS account, I can not file an issue on that, can anyone help to create an issue, much appreciated.:-) > > Thanks, > Yang Hi Yang, thanks for the report! I've filed https://bugs.openjdk.java.net/browse/JDK-8262746 ------------- PR: https://git.openjdk.java.net/valhalla/pull/354 From thartmann at openjdk.java.net Mon Mar 1 12:51:03 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 1 Mar 2021 12:51:03 GMT Subject: [lworld] RFR: [lworld] C1 compilation fails when PinAllInstructions is turned on In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 11:51:53 GMT, Yi Yang wrote: >> When turning on the -XX:+PinAllInstructions, C1 hits the following assertion: >> >> ` >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/qingfeng.yy/valhalla/src/hotspot/share/c1/c1_LIRGenerator.cpp:1524), pid=81974, tid=81994 >> # assert(!x->is_pinned()) failed: only for unpinned constants >> ... >> Stack: [0x00007fc0771fa000,0x00007fc0772fb000], sp=0x00007fc0772f89f0, free space=1018k >> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x65de6c] LIRGenerator::load_constant(Constant*)+0x2a >> V [libjvm.so+0x65ee4b] LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_OprDesc*&, ciField*, int)+0x319 >> V [libjvm.so+0x66209c] LIRGenerator::do_LoadIndexed(LoadIndexed*)+0x846 >> V [libjvm.so+0x6277c4] LoadIndexed::visit(InstructionVisitor*)+0x2e >> V [libjvm.so+0x6586ae] LIRGenerator::do_root(Instruction*)+0xfc >> V [libjvm.so+0x65856e] LIRGenerator::block_do(BlockBegin*)+0x7c >> V [libjvm.so+0x62696d] BlockList::iterate_forward(BlockClosure*)+0x5d >> V [libjvm.so+0x61ee24] IR::iterate_linear_scan_order(BlockClosure*)+0x2e >> V [libjvm.so+0x5ee90b] Compilation::emit_lir()+0x95 >> V [libjvm.so+0x5ef140] Compilation::compile_java_method()+0x21e >> V [libjvm.so+0x5ef4af] Compilation::compile_method()+0x107 >> V [libjvm.so+0x5efd05] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x3bb >> V [libjvm.so+0x5f3baf] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xd9 >> V [libjvm.so+0x81a938] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x88a >> V [libjvm.so+0x81956b] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x83bef1] CompilerThread::thread_entry(JavaThread*, Thread*)+0x69 >> V [libjvm.so+0x12fd598] JavaThread::thread_main_inner()+0x14c >> V [libjvm.so+0x12fd444] JavaThread::run()+0x11e >> V [libjvm.so+0x12fa630] Thread::call_run()+0x180 >> V [libjvm.so+0x1028936] thread_native_entry(Thread*)+0x1e4 >> ` >> >> The root cause of this crash is because LIRGenerator::access_sub_element() uses LIRGenerator::load_constant() to load the default value of a primitive class type(constant) into a register, load_constant requires unpinned constant instr, so it unquestionably crashes when PinAllInstructions is enabled. >> >> This problem also occurred in many places under `test/hotspot/jtreg/compiler/valhalla`. After applying this patch, they all passed with slowdebug build. >> >> Thanks, >> Yang > > Again, since I don't have a JBS account, I can not file an issue on that, can anyone help to create an issue, much appreciated.:-) Thanks for the report! I've filed https://bugs.openjdk.java.net/browse/JDK-8262747 ------------- PR: https://git.openjdk.java.net/valhalla/pull/355 From thartmann at openjdk.java.net Mon Mar 1 12:51:48 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 1 Mar 2021 12:51:48 GMT Subject: [lworld] RFR: [lworld] print out reason information for Deoptimize instruction In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 11:59:57 GMT, Yi Yang wrote: >> The instruction printer only tells that there is a deoptimization instruction, but not indicates they are deoptimized due to which class is not loaded. >> >> Java >> ---- >> static void test1(Object[] arr) { >> TestValue v = TestValue.default; >> arr[0] = v; >> } >> HIR(OLD) >> --- >> . 0 2 a2 deoptimize >> . 5 1 i3 0 >> . 7 0 a4 a1[i3] := a2 (L) [rc] What's the type of a2? >> . 8 0 v5 return >> HIR(NEW) >> --- >> . 0 2 a2 deoptimize [unloaded=Test$TestValue] >> . 5 1 i3 0 >> . 7 0 a4 a1[i3] := a2 (L) [rc] >> . 8 0 v5 return >> >> In addition, I restore some comments on LIRGenerator::do_Deoptimize, I'm not sure whether these comments were removed deliberately or accidentally, so please let me know if I did wrong. >> >> Thanks! >> Yang > > Once again, since I don't have a JBS account, I can not file an issue on that, can anyone help to create an issue, much appreciated.:-) Thanks for the report! I've filed https://bugs.openjdk.java.net/browse/JDK-8262748 ------------- PR: https://git.openjdk.java.net/valhalla/pull/356 From github.com+5010047+kelthuzadx at openjdk.java.net Mon Mar 1 12:57:59 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Mon, 1 Mar 2021 12:57:59 GMT Subject: [lworld] RFR: 8262747: [lworld] C1 compilation fails when PinAllInstructions is turned on In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 12:48:03 GMT, Tobias Hartmann wrote: >> Again, since I don't have a JBS account, I can not file an issue on that, can anyone help to create an issue, much appreciated.:-) > > Thanks for the report! I've filed https://bugs.openjdk.java.net/browse/JDK-8262747 Hi Tobias, new Thanks[3] array for you to take time filing these issues! I've adjusted the title to link the corresponding issue. ------------- PR: https://git.openjdk.java.net/valhalla/pull/355 From thartmann at openjdk.java.net Mon Mar 1 13:46:05 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 1 Mar 2021 13:46:05 GMT Subject: [lworld] RFR: 8262748: [lworld] print out reason information for Deoptimize instruction In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 11:57:08 GMT, Yi Yang wrote: > The instruction printer only tells that there is a deoptimization instruction, but not indicates they are deoptimized due to which class is not loaded. > > Java > ---- > static void test1(Object[] arr) { > TestValue v = TestValue.default; > arr[0] = v; > } > HIR(OLD) > --- > . 0 2 a2 deoptimize > . 5 1 i3 0 > . 7 0 a4 a1[i3] := a2 (L) [rc] What's the type of a2? > . 8 0 v5 return > HIR(NEW) > --- > . 0 2 a2 deoptimize [unloaded=Test$TestValue] > . 5 1 i3 0 > . 7 0 a4 a1[i3] := a2 (L) [rc] > . 8 0 v5 return > > In addition, I restore some comments on LIRGenerator::do_Deoptimize, I'm not sure whether these comments were removed deliberately or accidentally, so please let me know if I did wrong. > > Thanks! > Yang Looks good to me. ------------- Marked as reviewed by thartmann (Committer). PR: https://git.openjdk.java.net/valhalla/pull/356 From thartmann at openjdk.java.net Mon Mar 1 13:59:50 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 1 Mar 2021 13:59:50 GMT Subject: [lworld] RFR: 8262747: [lworld] C1 compilation fails when PinAllInstructions is turned on In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 11:50:07 GMT, Yi Yang wrote: > When turning on the -XX:+PinAllInstructions, C1 hits the following assertion: > > ` > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/qingfeng.yy/valhalla/src/hotspot/share/c1/c1_LIRGenerator.cpp:1524), pid=81974, tid=81994 > # assert(!x->is_pinned()) failed: only for unpinned constants > ... > Stack: [0x00007fc0771fa000,0x00007fc0772fb000], sp=0x00007fc0772f89f0, free space=1018k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x65de6c] LIRGenerator::load_constant(Constant*)+0x2a > V [libjvm.so+0x65ee4b] LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_OprDesc*&, ciField*, int)+0x319 > V [libjvm.so+0x66209c] LIRGenerator::do_LoadIndexed(LoadIndexed*)+0x846 > V [libjvm.so+0x6277c4] LoadIndexed::visit(InstructionVisitor*)+0x2e > V [libjvm.so+0x6586ae] LIRGenerator::do_root(Instruction*)+0xfc > V [libjvm.so+0x65856e] LIRGenerator::block_do(BlockBegin*)+0x7c > V [libjvm.so+0x62696d] BlockList::iterate_forward(BlockClosure*)+0x5d > V [libjvm.so+0x61ee24] IR::iterate_linear_scan_order(BlockClosure*)+0x2e > V [libjvm.so+0x5ee90b] Compilation::emit_lir()+0x95 > V [libjvm.so+0x5ef140] Compilation::compile_java_method()+0x21e > V [libjvm.so+0x5ef4af] Compilation::compile_method()+0x107 > V [libjvm.so+0x5efd05] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x3bb > V [libjvm.so+0x5f3baf] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xd9 > V [libjvm.so+0x81a938] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x88a > V [libjvm.so+0x81956b] CompileBroker::compiler_thread_loop()+0x3df > V [libjvm.so+0x83bef1] CompilerThread::thread_entry(JavaThread*, Thread*)+0x69 > V [libjvm.so+0x12fd598] JavaThread::thread_main_inner()+0x14c > V [libjvm.so+0x12fd444] JavaThread::run()+0x11e > V [libjvm.so+0x12fa630] Thread::call_run()+0x180 > V [libjvm.so+0x1028936] thread_native_entry(Thread*)+0x1e4 > ` > > The root cause of this crash is because LIRGenerator::access_sub_element() uses LIRGenerator::load_constant() to load the default value of a primitive class type(constant) into a register, load_constant requires unpinned constant instr, so it unquestionably crashes when PinAllInstructions is enabled. > > This problem also occurred in many places under `test/hotspot/jtreg/compiler/valhalla`. After applying this patch, they all passed with slowdebug build. > > Thanks, > Yang Looks good to me. ------------- Marked as reviewed by thartmann (Committer). PR: https://git.openjdk.java.net/valhalla/pull/355 From github.com+5010047+kelthuzadx at openjdk.java.net Tue Mar 2 13:23:56 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Tue, 2 Mar 2021 13:23:56 GMT Subject: [lworld] RFR: 8262748: [lworld] print out reason information for Deoptimize instruction In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 13:42:48 GMT, Tobias Hartmann wrote: >> The instruction printer only tells that there is a deoptimization instruction, but not indicates they are deoptimized due to which class is not loaded. >> >> Java >> ---- >> static void test1(Object[] arr) { >> TestValue v = TestValue.default; >> arr[0] = v; >> } >> HIR(OLD) >> --- >> . 0 2 a2 deoptimize >> . 5 1 i3 0 >> . 7 0 a4 a1[i3] := a2 (L) [rc] What's the type of a2? >> . 8 0 v5 return >> HIR(NEW) >> --- >> . 0 2 a2 deoptimize [unloaded=Test$TestValue] >> . 5 1 i3 0 >> . 7 0 a4 a1[i3] := a2 (L) [rc] >> . 8 0 v5 return >> >> In addition, I restore some comments on LIRGenerator::do_Deoptimize, I'm not sure whether these comments were removed deliberately or accidentally, so please let me know if I did wrong. >> >> Thanks! >> Yang > > Looks good to me. Thanks Tobias for the reivew! ------------- PR: https://git.openjdk.java.net/valhalla/pull/356 From github.com+5010047+kelthuzadx at openjdk.java.net Tue Mar 2 13:26:05 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Tue, 2 Mar 2021 13:26:05 GMT Subject: [lworld] RFR: 8262747: [lworld] C1 compilation fails when PinAllInstructions is turned on In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 13:56:50 GMT, Tobias Hartmann wrote: >> When turning on the -XX:+PinAllInstructions, C1 hits the following assertion: >> >> ` >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/qingfeng.yy/valhalla/src/hotspot/share/c1/c1_LIRGenerator.cpp:1524), pid=81974, tid=81994 >> # assert(!x->is_pinned()) failed: only for unpinned constants >> ... >> Stack: [0x00007fc0771fa000,0x00007fc0772fb000], sp=0x00007fc0772f89f0, free space=1018k >> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x65de6c] LIRGenerator::load_constant(Constant*)+0x2a >> V [libjvm.so+0x65ee4b] LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_OprDesc*&, ciField*, int)+0x319 >> V [libjvm.so+0x66209c] LIRGenerator::do_LoadIndexed(LoadIndexed*)+0x846 >> V [libjvm.so+0x6277c4] LoadIndexed::visit(InstructionVisitor*)+0x2e >> V [libjvm.so+0x6586ae] LIRGenerator::do_root(Instruction*)+0xfc >> V [libjvm.so+0x65856e] LIRGenerator::block_do(BlockBegin*)+0x7c >> V [libjvm.so+0x62696d] BlockList::iterate_forward(BlockClosure*)+0x5d >> V [libjvm.so+0x61ee24] IR::iterate_linear_scan_order(BlockClosure*)+0x2e >> V [libjvm.so+0x5ee90b] Compilation::emit_lir()+0x95 >> V [libjvm.so+0x5ef140] Compilation::compile_java_method()+0x21e >> V [libjvm.so+0x5ef4af] Compilation::compile_method()+0x107 >> V [libjvm.so+0x5efd05] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x3bb >> V [libjvm.so+0x5f3baf] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xd9 >> V [libjvm.so+0x81a938] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x88a >> V [libjvm.so+0x81956b] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x83bef1] CompilerThread::thread_entry(JavaThread*, Thread*)+0x69 >> V [libjvm.so+0x12fd598] JavaThread::thread_main_inner()+0x14c >> V [libjvm.so+0x12fd444] JavaThread::run()+0x11e >> V [libjvm.so+0x12fa630] Thread::call_run()+0x180 >> V [libjvm.so+0x1028936] thread_native_entry(Thread*)+0x1e4 >> ` >> >> The root cause of this crash is because LIRGenerator::access_sub_element() uses LIRGenerator::load_constant() to load the default value of a primitive class type(constant) into a register, load_constant requires unpinned constant instr, so it unquestionably crashes when PinAllInstructions is enabled. >> >> This problem also occurred in many places under `test/hotspot/jtreg/compiler/valhalla`. After applying this patch, they all passed with slowdebug build. >> >> Thanks, >> Yang > > Looks good to me. Thanks Tobias for the reivew! ------------- PR: https://git.openjdk.java.net/valhalla/pull/355 From thartmann at openjdk.java.net Tue Mar 2 13:31:39 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 2 Mar 2021 13:31:39 GMT Subject: git: openjdk/valhalla: lworld: 8262748: [lworld] print out reason information for Deoptimize instruction Message-ID: Changeset: 6924d180 Author: Yi Yang Committer: Tobias Hartmann Date: 2021-03-02 13:31:14 +0000 URL: https://git.openjdk.java.net/valhalla/commit/6924d180 8262748: [lworld] print out reason information for Deoptimize instruction Reviewed-by: thartmann ! 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_LIRGenerator.cpp From github.com+5010047+kelthuzadx at openjdk.java.net Tue Mar 2 13:33:58 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Tue, 2 Mar 2021 13:33:58 GMT Subject: [lworld] Integrated: 8262747: [lworld] C1 compilation fails when PinAllInstructions is turned on In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 11:50:07 GMT, Yi Yang wrote: > When turning on the -XX:+PinAllInstructions, C1 hits the following assertion: > > ` > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/qingfeng.yy/valhalla/src/hotspot/share/c1/c1_LIRGenerator.cpp:1524), pid=81974, tid=81994 > # assert(!x->is_pinned()) failed: only for unpinned constants > ... > Stack: [0x00007fc0771fa000,0x00007fc0772fb000], sp=0x00007fc0772f89f0, free space=1018k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x65de6c] LIRGenerator::load_constant(Constant*)+0x2a > V [libjvm.so+0x65ee4b] LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_OprDesc*&, ciField*, int)+0x319 > V [libjvm.so+0x66209c] LIRGenerator::do_LoadIndexed(LoadIndexed*)+0x846 > V [libjvm.so+0x6277c4] LoadIndexed::visit(InstructionVisitor*)+0x2e > V [libjvm.so+0x6586ae] LIRGenerator::do_root(Instruction*)+0xfc > V [libjvm.so+0x65856e] LIRGenerator::block_do(BlockBegin*)+0x7c > V [libjvm.so+0x62696d] BlockList::iterate_forward(BlockClosure*)+0x5d > V [libjvm.so+0x61ee24] IR::iterate_linear_scan_order(BlockClosure*)+0x2e > V [libjvm.so+0x5ee90b] Compilation::emit_lir()+0x95 > V [libjvm.so+0x5ef140] Compilation::compile_java_method()+0x21e > V [libjvm.so+0x5ef4af] Compilation::compile_method()+0x107 > V [libjvm.so+0x5efd05] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x3bb > V [libjvm.so+0x5f3baf] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xd9 > V [libjvm.so+0x81a938] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x88a > V [libjvm.so+0x81956b] CompileBroker::compiler_thread_loop()+0x3df > V [libjvm.so+0x83bef1] CompilerThread::thread_entry(JavaThread*, Thread*)+0x69 > V [libjvm.so+0x12fd598] JavaThread::thread_main_inner()+0x14c > V [libjvm.so+0x12fd444] JavaThread::run()+0x11e > V [libjvm.so+0x12fa630] Thread::call_run()+0x180 > V [libjvm.so+0x1028936] thread_native_entry(Thread*)+0x1e4 > ` > > The root cause of this crash is because LIRGenerator::access_sub_element() uses LIRGenerator::load_constant() to load the default value of a primitive class type(constant) into a register, load_constant requires unpinned constant instr, so it unquestionably crashes when PinAllInstructions is enabled. > > This problem also occurred in many places under `test/hotspot/jtreg/compiler/valhalla`. After applying this patch, they all passed with slowdebug build. > > Thanks, > Yang This pull request has now been integrated. Changeset: 436cfe61 Author: Yi Yang Committer: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/436cfe61 Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod 8262747: [lworld] C1 compilation fails when PinAllInstructions is turned on Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/valhalla/pull/355 From github.com+5010047+kelthuzadx at openjdk.java.net Tue Mar 2 13:33:59 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Tue, 2 Mar 2021 13:33:59 GMT Subject: [lworld] Integrated: 8262748: [lworld] print out reason information for Deoptimize instruction In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 11:57:08 GMT, Yi Yang wrote: > The instruction printer only tells that there is a deoptimization instruction, but not indicates they are deoptimized due to which class is not loaded. > > Java > ---- > static void test1(Object[] arr) { > TestValue v = TestValue.default; > arr[0] = v; > } > HIR(OLD) > --- > . 0 2 a2 deoptimize > . 5 1 i3 0 > . 7 0 a4 a1[i3] := a2 (L) [rc] What's the type of a2? > . 8 0 v5 return > HIR(NEW) > --- > . 0 2 a2 deoptimize [unloaded=Test$TestValue] > . 5 1 i3 0 > . 7 0 a4 a1[i3] := a2 (L) [rc] > . 8 0 v5 return > > In addition, I restore some comments on LIRGenerator::do_Deoptimize, I'm not sure whether these comments were removed deliberately or accidentally, so please let me know if I did wrong. > > Thanks! > Yang This pull request has now been integrated. Changeset: 6924d180 Author: Yi Yang Committer: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/6924d180 Stats: 16 lines in 4 files changed: 11 ins; 0 del; 5 mod 8262748: [lworld] print out reason information for Deoptimize instruction Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/valhalla/pull/356 From fparain at openjdk.java.net Tue Mar 2 14:08:57 2021 From: fparain at openjdk.java.net (Frederic Parain) Date: Tue, 2 Mar 2021 14:08:57 GMT Subject: [lworld] RFR: 8262746: [lworld] jcmd VM.class_print_layout crash due to NULL cld name In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 11:42:07 GMT, Yi Yang wrote: > Hi, can I have a review of this one-line fix? > > jcmd VM.class_print_layout crashes when printing classes which loaded by bootstrap loader since these classes has NULL class_loder_data()->name(). > > But actually, I wonder to know why we don't print the layout by modifications of existing functions in FieldLayoutBuilder::build_layout directly? It seems FieldLayoutBuilder can gather more complete layout information. > > Thanks, > Yang Looks good to me. Thank you for fixing it. Fred ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.java.net/valhalla/pull/354 From github.com+5010047+kelthuzadx at openjdk.java.net Tue Mar 2 14:17:06 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Tue, 2 Mar 2021 14:17:06 GMT Subject: [lworld] RFR: 8262746: [lworld] jcmd VM.class_print_layout crash due to NULL cld name In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 14:06:14 GMT, Frederic Parain wrote: >> Hi, can I have a review of this one-line fix? >> >> jcmd VM.class_print_layout crashes when printing classes which loaded by bootstrap loader since these classes has NULL class_loder_data()->name(). >> >> But actually, I wonder to know why we don't print the layout by modifications of existing functions in FieldLayoutBuilder::build_layout directly? It seems FieldLayoutBuilder can gather more complete layout information. >> >> Thanks, >> Yang > > Looks good to me. > > Thank you for fixing it. > > Fred Thanks Frederic for the reviews. And thanks Tobias for creating a related JBS issue! ------------- PR: https://git.openjdk.java.net/valhalla/pull/354 From github.com+5010047+kelthuzadx at openjdk.java.net Tue Mar 2 15:18:58 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Tue, 2 Mar 2021 15:18:58 GMT Subject: [lworld] Integrated: 8262746: [lworld] jcmd VM.class_print_layout crash due to NULL cld name In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 11:42:07 GMT, Yi Yang wrote: > Hi, can I have a review of this one-line fix? > > jcmd VM.class_print_layout crashes when printing classes which loaded by bootstrap loader since these classes has NULL class_loder_data()->name(). > > But actually, I wonder to know why we don't print the layout by modifications of existing functions in FieldLayoutBuilder::build_layout directly? It seems FieldLayoutBuilder can gather more complete layout information. > > Thanks, > Yang This pull request has now been integrated. Changeset: 6131196e Author: Yi Yang Committer: Frederic Parain URL: https://git.openjdk.java.net/valhalla/commit/6131196e Stats: 74 lines in 2 files changed: 73 ins; 0 del; 1 mod 8262746: [lworld] jcmd VM.class_print_layout crash due to NULL cld name Reviewed-by: fparain ------------- PR: https://git.openjdk.java.net/valhalla/pull/354 From thartmann at openjdk.java.net Tue Mar 2 15:37:14 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 2 Mar 2021 15:37:14 GMT Subject: [lworld] RFR: 8262863: [lworld] C2 should keep track of the oop even if an inline type is returned as fields Message-ID: If an inline type is returned, its fields are passed in registers if possible. The first register (rax) either contains a pointer to the InlineKlass to allow buffering in interpreted or C1 compiled callers or an oop if the inline type has already been buffered. Currently, a C2 compiled caller completely ignores the first register and just uses the field values returned in the other registers. With this patch, C2 checks if an oop is returned and keeps track of it to avoid unnecessary re-buffering. This significantly boosts performance of cases were inlining fails and the callee is interpreted, C1 compiled or had to buffer the inline type for another reason (for example, due a store to a non-flattened field/array). Thanks, Tobias ------------- Commit messages: - 8262863: [lworld] C2 should keep track of the oop even if an inline type is returned as fields Changes: https://git.openjdk.java.net/valhalla/pull/357/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=357&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262863 Stats: 21 lines in 5 files changed: 17 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/357.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/357/head:pull/357 PR: https://git.openjdk.java.net/valhalla/pull/357 From thartmann at openjdk.java.net Tue Mar 2 16:29:23 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 2 Mar 2021 16:29:23 GMT Subject: [lworld] RFR: 8262863: [lworld] C2 should keep track of the oop even if an inline type is returned as fields [v2] In-Reply-To: References: Message-ID: > If an inline type is returned, its fields are passed in registers if possible. The first register (rax) either contains a pointer to the InlineKlass to allow buffering in interpreted or C1 compiled callers or an oop if the inline type has already been buffered. Currently, a C2 compiled caller completely ignores the first register and just uses the field values returned in the other registers. > > With this patch, C2 checks if an oop is returned and keeps track of it to avoid unnecessary re-buffering. This significantly boosts performance of cases were inlining fails and the callee is interpreted, C1 compiled or had to buffer the inline type for another reason (for example, due a store to a non-flattened field/array). > > Thanks, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: Handle incremental inlining ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/357/files - new: https://git.openjdk.java.net/valhalla/pull/357/files/64a82a25..ed85fab9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=357&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=357&range=00-01 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/357.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/357/head:pull/357 PR: https://git.openjdk.java.net/valhalla/pull/357 From thartmann at openjdk.java.net Tue Mar 2 16:45:14 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 2 Mar 2021 16:45:14 GMT Subject: [lworld] RFR: 8262863: [lworld] C2 should keep track of the oop even if an inline type is returned as fields [v3] In-Reply-To: References: Message-ID: > If an inline type is returned, its fields are passed in registers if possible. The first register (rax) either contains a pointer to the InlineKlass to allow buffering in interpreted or C1 compiled callers or an oop if the inline type has already been buffered. Currently, a C2 compiled caller completely ignores the first register and just uses the field values returned in the other registers. > > With this patch, C2 checks if an oop is returned and keeps track of it to avoid unnecessary re-buffering. This significantly boosts performance of cases were inlining fails and the callee is interpreted, C1 compiled or had to buffer the inline type for another reason (for example, due a store to a non-flattened field/array). > > Thanks, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: Method handles ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/357/files - new: https://git.openjdk.java.net/valhalla/pull/357/files/ed85fab9..4a9925d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=357&range=02 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=357&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/357.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/357/head:pull/357 PR: https://git.openjdk.java.net/valhalla/pull/357 From thartmann at openjdk.java.net Wed Mar 3 15:03:19 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 3 Mar 2021 15:03:19 GMT Subject: [lworld] RFR: 8262863: [lworld] C2 should keep track of the oop even if an inline type is returned as fields [v4] In-Reply-To: References: Message-ID: > If an inline type is returned, its fields are passed in registers if possible. The first register (rax) either contains a pointer to the InlineKlass to allow buffering in interpreted or C1 compiled callers or an oop if the inline type has already been buffered. Currently, a C2 compiled caller completely ignores the first register and just uses the field values returned in the other registers. > > With this patch, C2 checks if an oop is returned and keeps track of it to avoid unnecessary re-buffering. This significantly boosts performance of cases were inlining fails and the callee is interpreted, C1 compiled or had to buffer the inline type for another reason (for example, due a store to a non-flattened field/array). > > Thanks, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: More fixes ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/357/files - new: https://git.openjdk.java.net/valhalla/pull/357/files/4a9925d3..d49d3f24 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=357&range=03 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=357&range=02-03 Stats: 8 lines in 3 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/357.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/357/head:pull/357 PR: https://git.openjdk.java.net/valhalla/pull/357 From dsimms at openjdk.java.net Thu Mar 4 06:42:28 2021 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 4 Mar 2021 06:42:28 GMT Subject: [lworld] RFR: Merge jdk Message-ID: <98sUPvEGeB3JCw028qWxkYUEl9tVlFj8vvDg2A7VLAc=.aad675b8-bb22-4dfe-9b59-34c162cf4169@github.com> Merge tag 'jdk-17+12' ------------- Commit messages: - Post merge compilation fixes - Merge tag 'jdk-17+12' into lworld_merge_jdk_17_12 - 8260966: (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView - 8253100: Fix "no comment" warnings in java.base/java.net - 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" - 8261606: Surprising behavior of step over in String switch - 8262726: AArch64: C1 StubAssembler::call_RT can corrupt stack - 8262819: gc/shenandoah/compiler/TestLinkToNativeRBP.java fails with release VMs - 8262461: handle wcstombsdmp return value correctly in unix awt_InputMethod.c - 8261710: SA DSO objects have sizes that are too large - ... and 58 more: https://git.openjdk.java.net/valhalla/compare/6131196e...d1e02862 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=358&range=00.0 - jdk: https://webrevs.openjdk.java.net/?repo=valhalla&pr=358&range=00.1 Changes: https://git.openjdk.java.net/valhalla/pull/358/files Stats: 10617 lines in 542 files changed: 5584 ins; 3029 del; 2004 mod Patch: https://git.openjdk.java.net/valhalla/pull/358.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/358/head:pull/358 PR: https://git.openjdk.java.net/valhalla/pull/358 From thartmann at openjdk.java.net Thu Mar 4 06:51:47 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 4 Mar 2021 06:51:47 GMT Subject: [lworld] Integrated: 8262863: [lworld] C2 should keep track of the oop even if an inline type is returned as fields In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 15:32:24 GMT, Tobias Hartmann wrote: > If an inline type is returned, its fields are passed in registers if possible. The first register (rax) either contains a pointer to the InlineKlass to allow buffering in interpreted or C1 compiled callers or an oop if the inline type has already been buffered. Currently, a C2 compiled caller completely ignores the first register and just uses the field values returned in the other registers. > > With this patch, C2 checks if an oop is returned and keeps track of it to avoid unnecessary re-buffering. This significantly boosts performance of cases were inlining fails and the callee is interpreted, C1 compiled or had to buffer the inline type for another reason (for example, due a store to a non-flattened field/array). > > Thanks, > Tobias This pull request has now been integrated. Changeset: 7f07f60c Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/7f07f60c Stats: 36 lines in 7 files changed: 28 ins; 2 del; 6 mod 8262863: [lworld] C2 should keep track of the oop even if an inline type is returned as fields ------------- PR: https://git.openjdk.java.net/valhalla/pull/357 From dsimms at openjdk.java.net Thu Mar 4 07:06:10 2021 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 4 Mar 2021 07:06:10 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: <98sUPvEGeB3JCw028qWxkYUEl9tVlFj8vvDg2A7VLAc=.aad675b8-bb22-4dfe-9b59-34c162cf4169@github.com> References: <98sUPvEGeB3JCw028qWxkYUEl9tVlFj8vvDg2A7VLAc=.aad675b8-bb22-4dfe-9b59-34c162cf4169@github.com> Message-ID: <5Pr40RB7Jbo7AkewKGL9m1c8qvgzm_kupn1wexK7luA=.2c709fc7-3a80-4c0f-be29-a545f9fd8775@github.com> On Thu, 4 Mar 2021 06:37:50 GMT, David Simms wrote: > Merge tag 'jdk-17+12' This pull request has now been integrated. Changeset: a061ea0a Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/a061ea0a Stats: 10617 lines in 542 files changed: 5584 ins; 3029 del; 2004 mod Merge jdk Merge tag 'jdk-17+12' ------------- PR: https://git.openjdk.java.net/valhalla/pull/358 From dsimms at openjdk.java.net Thu Mar 4 07:29:19 2021 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 4 Mar 2021 07:29:19 GMT Subject: RFR: Merge lworld Message-ID: <4LGalO7P_zRoHM5AtALfJlP-SrL-nfYetOmpNYHHEug=.f5e1fadc-2a96-47bd-9a77-f357a9dce896@github.com> Merge tag 'jdk-17+12' ------------- Commit messages: - Post merge compilation fixes - Merge branch 'lworld' into type-restrictions_merge_lworld_17_12 - Merge jdk - 8260966: (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView - 8253100: Fix "no comment" warnings in java.base/java.net - 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" - 8261606: Surprising behavior of step over in String switch - 8262726: AArch64: C1 StubAssembler::call_RT can corrupt stack - 8262819: gc/shenandoah/compiler/TestLinkToNativeRBP.java fails with release VMs - 8262461: handle wcstombsdmp return value correctly in unix awt_InputMethod.c - ... and 64 more: https://git.openjdk.java.net/valhalla/compare/0a26489c...96378bcd The webrevs contain the adjustments done while merging with regards to each parent branch: - type-restrictions: https://webrevs.openjdk.java.net/?repo=valhalla&pr=359&range=00.0 - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=359&range=00.1 Changes: https://git.openjdk.java.net/valhalla/pull/359/files Stats: 10780 lines in 555 files changed: 5719 ins; 3038 del; 2023 mod Patch: https://git.openjdk.java.net/valhalla/pull/359.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/359/head:pull/359 PR: https://git.openjdk.java.net/valhalla/pull/359 From dsimms at openjdk.java.net Thu Mar 4 07:40:53 2021 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 4 Mar 2021 07:40:53 GMT Subject: Integrated: Merge lworld Message-ID: <2mdhXCSZv9GeYrrl7lCzwYy5A1Rba4D589IbvIBsDoo=.4af024d4-3658-4ee2-94af-37eccd21a53b@github.com> Merge tag 'jdk-17+12' ------------- Commit messages: The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/valhalla/pull/360/files Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/360.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/360/head:pull/360 PR: https://git.openjdk.java.net/valhalla/pull/360 From dsimms at openjdk.java.net Thu Mar 4 07:40:55 2021 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 4 Mar 2021 07:40:55 GMT Subject: Integrated: Merge lworld In-Reply-To: <2mdhXCSZv9GeYrrl7lCzwYy5A1Rba4D589IbvIBsDoo=.4af024d4-3658-4ee2-94af-37eccd21a53b@github.com> References: <2mdhXCSZv9GeYrrl7lCzwYy5A1Rba4D589IbvIBsDoo=.4af024d4-3658-4ee2-94af-37eccd21a53b@github.com> Message-ID: On Thu, 4 Mar 2021 07:35:31 GMT, David Simms wrote: > Merge tag 'jdk-17+12' This pull request has now been integrated. Changeset: 8a508904 Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/8a508904 Stats: 10653 lines in 547 files changed: 5612 ins; 3031 del; 2010 mod Merge lworld Merge tag 'jdk-17+12' ------------- PR: https://git.openjdk.java.net/valhalla/pull/360 From dsimms at openjdk.java.net Thu Mar 4 08:34:19 2021 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 4 Mar 2021 08:34:19 GMT Subject: RFR: Merge lworld [v2] In-Reply-To: <4LGalO7P_zRoHM5AtALfJlP-SrL-nfYetOmpNYHHEug=.f5e1fadc-2a96-47bd-9a77-f357a9dce896@github.com> References: <4LGalO7P_zRoHM5AtALfJlP-SrL-nfYetOmpNYHHEug=.f5e1fadc-2a96-47bd-9a77-f357a9dce896@github.com> Message-ID: > Merge tag 'jdk-17+12' David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Post merge compilation fixes - Merge branch 'lworld' into type-restrictions_merge_lworld_17_12 - Merge lworld Merge tag 'jdk-17+11' - 8262202: [type-restrictions] RestrictedMethodTest failed to compile - 8261956: [type-restrictions] Support RestrictedMethod in the interpreter Reviewed-by: dsimms, hseigel - Merge lworld Merge 'jdk-17+10' - Merge lworld Merge lworld at jdk-17+8 - 8260870: [type-restrictions] Generate RestrictedMethod attributes - 8257600: [type-restrictions] Implement RestrictedField in C1 Reviewed-by: lfoltan, thartmann - Merge lworld Merge tag 'jdk-16+26' - ... and 13 more: https://git.openjdk.java.net/valhalla/compare/a061ea0a...96378bcd ------------- Changes: https://git.openjdk.java.net/valhalla/pull/359/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=359&range=01 Stats: 2395 lines in 62 files changed: 2306 ins; 12 del; 77 mod Patch: https://git.openjdk.java.net/valhalla/pull/359.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/359/head:pull/359 PR: https://git.openjdk.java.net/valhalla/pull/359 From dsimms at openjdk.java.net Thu Mar 4 08:34:20 2021 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 4 Mar 2021 08:34:20 GMT Subject: Integrated: Merge lworld In-Reply-To: <4LGalO7P_zRoHM5AtALfJlP-SrL-nfYetOmpNYHHEug=.f5e1fadc-2a96-47bd-9a77-f357a9dce896@github.com> References: <4LGalO7P_zRoHM5AtALfJlP-SrL-nfYetOmpNYHHEug=.f5e1fadc-2a96-47bd-9a77-f357a9dce896@github.com> Message-ID: <4pw5t6R-7I89A2NdotfJlozOhUkKLH48Ckl__LXq1F0=.2ee0ba70-6383-4cc0-9eff-0dec64d35ac9@github.com> On Thu, 4 Mar 2021 07:24:24 GMT, David Simms wrote: > Merge tag 'jdk-17+12' This pull request has now been integrated. Changeset: 7ce2c11b Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/7ce2c11b Stats: 10780 lines in 555 files changed: 5719 ins; 3038 del; 2023 mod Merge lworld Merge tag 'jdk-17+12' ------------- PR: https://git.openjdk.java.net/valhalla/pull/359 From roland at openjdk.java.net Thu Mar 4 16:36:20 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Thu, 4 Mar 2021 16:36:20 GMT Subject: [lworld] RFR: 8262287: [lworld] C2 compilation fails with assert "should have been removed from the graph" Message-ID: hook_memory_on_init() sets up memory edges so stores can be captured at an allocation. To do that, it adds extra edges for each field after and before the InitializeNode. This also happens for flat arrays eventhough until Compile::adjust_flattened_array_access_aliases() runs there's a single slice for all fields of a flat array element. The extra edges added after the InitalizeNode can cause PhiNodes to be created for each fields of the array element which confuses Compile::adjust_flattened_array_access_aliases() (because it expects no Phi for individual fields until it runs). I don't think the memory edges out of the InitializeNode are needed as Compile::adjust_flattened_array_access_aliases() should create them. So I propose not adding them. ------------- Commit messages: - fix Changes: https://git.openjdk.java.net/valhalla/pull/361/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=361&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262287 Stats: 9 lines in 3 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/361.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/361/head:pull/361 PR: https://git.openjdk.java.net/valhalla/pull/361 From github.com+5010047+kelthuzadx at openjdk.java.net Fri Mar 5 07:29:05 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Fri, 5 Mar 2021 07:29:05 GMT Subject: [lworld] RFR: 8263067: [lworld] Use tlab_allocate in MacroAssembler::store_inline_type_fields_to_buf Message-ID: TLAB allocation in MacroAssembler::store_inline_type_fields_to_buf looks duplicated with MacroAssembler::tlab_allocate, we might use existing MacroAssembler::tlab_allocate instead of duplicated ones. It will generate safer and faster code. (See details on JBS). All jtreg tests are passed with slowdebug mode. Thanks! Yang ------------- Commit messages: - reuse tlab_allocate in store_inline_type_fields_to_buf Changes: https://git.openjdk.java.net/valhalla/pull/362/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=362&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263067 Stats: 10 lines in 1 file changed: 1 ins; 6 del; 3 mod Patch: https://git.openjdk.java.net/valhalla/pull/362.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/362/head:pull/362 PR: https://git.openjdk.java.net/valhalla/pull/362 From thartmann at openjdk.java.net Fri Mar 5 07:41:00 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 5 Mar 2021 07:41:00 GMT Subject: [lworld] RFR: 8263067: [lworld] Use tlab_allocate in MacroAssembler::store_inline_type_fields_to_buf In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 07:24:34 GMT, Yi Yang wrote: > TLAB allocation in MacroAssembler::store_inline_type_fields_to_buf looks duplicated with MacroAssembler::tlab_allocate, we might use existing MacroAssembler::tlab_allocate instead of duplicated ones. It will generate safer and faster code. (See details on JBS). All jtreg tests are passed with slowdebug mode. > > Thanks! > Yang Hi Yang, I had this on my To-Do list as well, thanks for fixing! I'm just wondering if we shouldn't also attempt an allocation in eden if `UseTLAB` is disabled? Similar to what code in `MacroAssembler::allocate_instance` does. Thanks, Tobias ------------- PR: https://git.openjdk.java.net/valhalla/pull/362 From thartmann at openjdk.java.net Fri Mar 5 07:49:00 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 5 Mar 2021 07:49:00 GMT Subject: [lworld] RFR: 8262287: [lworld] C2 compilation fails with assert "should have been removed from the graph" In-Reply-To: References: Message-ID: On Thu, 4 Mar 2021 16:31:42 GMT, Roland Westrelin wrote: > hook_memory_on_init() sets up memory edges so stores can be captured > at an allocation. To do that, it adds extra edges for each field after > and before the InitializeNode. This also happens for flat arrays > eventhough until Compile::adjust_flattened_array_access_aliases() runs > there's a single slice for all fields of a flat array element. The > extra edges added after the InitalizeNode can cause PhiNodes to be > created for each fields of the array element which confuses > Compile::adjust_flattened_array_access_aliases() (because it expects > no Phi for individual fields until it runs). I don't think the memory > edges out of the InitializeNode are needed as > Compile::adjust_flattened_array_access_aliases() should create > them. So I propose not adding them. Looks good to me. Some comments wouldn't hurt though :) and but could you please add the regression test? You can simply add it to `jtreg/compiler/valhalla/inlinetypes/TestGenerated.java` where the generated tests live. ------------- PR: https://git.openjdk.java.net/valhalla/pull/361 From github.com+5010047+kelthuzadx at openjdk.java.net Fri Mar 5 07:58:46 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Fri, 5 Mar 2021 07:58:46 GMT Subject: [lworld] RFR: 8263067: [lworld] Use tlab_allocate in MacroAssembler::store_inline_type_fields_to_buf In-Reply-To: References: Message-ID: <6mf42vuffMOMnOYtqMVGYQ-jJx4l_b0byTVDOkh3ILU=.bc9dbfa9-f361-4fdd-a1b0-85683531a11e@github.com> On Fri, 5 Mar 2021 07:38:22 GMT, Tobias Hartmann wrote: >> TLAB allocation in MacroAssembler::store_inline_type_fields_to_buf looks duplicated with MacroAssembler::tlab_allocate, we might use existing MacroAssembler::tlab_allocate instead of duplicated ones. It will generate safer and faster code. (See details on JBS). All jtreg tests are passed with slowdebug mode. >> >> Thanks! >> Yang > > Hi Yang, > > I had this on my To-Do list as well, thanks for fixing! I'm just wondering if we shouldn't also attempt an allocation in eden if `UseTLAB` is disabled? Similar to what code in `MacroAssembler::allocate_instance` does. > > Thanks, > Tobias Hi Tobias, I think it's reasonable. We can create such a buffered instance similar to `MacroAssembler::allocate_instance` or just using it. What do you think? If you think it's a feasible way, I can also try to tweak the implementation, keeping using the same buffer allocation mechanism on aarch64. Thanks! Yang ------------- PR: https://git.openjdk.java.net/valhalla/pull/362 From thartmann at openjdk.java.net Fri Mar 5 08:09:47 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 5 Mar 2021 08:09:47 GMT Subject: [lworld] RFR: 8263067: [lworld] Use tlab_allocate in MacroAssembler::store_inline_type_fields_to_buf In-Reply-To: <6mf42vuffMOMnOYtqMVGYQ-jJx4l_b0byTVDOkh3ILU=.bc9dbfa9-f361-4fdd-a1b0-85683531a11e@github.com> References: <6mf42vuffMOMnOYtqMVGYQ-jJx4l_b0byTVDOkh3ILU=.bc9dbfa9-f361-4fdd-a1b0-85683531a11e@github.com> Message-ID: On Fri, 5 Mar 2021 07:53:40 GMT, Yi Yang wrote: >> Hi Yang, >> >> I had this on my To-Do list as well, thanks for fixing! I'm just wondering if we shouldn't also attempt an allocation in eden if `UseTLAB` is disabled? Similar to what code in `MacroAssembler::allocate_instance` does. >> >> Thanks, >> Tobias > > Hi Tobias, > > I think it's reasonable. We can create such a buffered instance similar to `MacroAssembler::allocate_instance` or just using it. What do you think? If you think it's a feasible way, I can also try to tweak the implementation, keeping using the same buffer allocation mechanism on aarch64. > > Thanks! > Yang Yes, I think it would be nice to factor the common code out of `MacroAssembler::allocate_instance` (we don't need the zeroing and some of the checks) and use it for buffer allocation. ------------- PR: https://git.openjdk.java.net/valhalla/pull/362 From vromero at openjdk.java.net Sun Mar 7 00:35:31 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 7 Mar 2021 00:35:31 GMT Subject: [lworld] RFR: Javac support for Parametric VM Message-ID: This patch is the initial support for Parametric VM in javac. This is the first iteration of the prototype, so still a work in progress. In order to test the new code users need to pass the hidden option: `-XDsupportParametricVM` to javac. See the examples below for an illustration of the bytecode the compiler can generate now. Lets assume we have the following class annotated with the `@Parametric` annotation: import java.lang.annotation.*; @Parametric(id="PAIR") class Pair { @Parametric(id="PAIR") X fst; @Parametric(id="PAIR") Y snd; Pair(X fst, Y snd) { this.fst = fst; this.snd = snd; } Pair swap() { return new Pair<>(snd, fst); } @Parametric(id="make", kind=ParamKind.METHOD_ONLY) static Pair make(U fst, W snd) { return new Pair<>(fst, snd); } @Parametric(id="setFst", kind=ParamKind.METHOD_AND_CLASS) Pair setFst(Z newFst) { return null; } } After compilation this class will contain the following new entries in the constant pool: #22 = Parameter CLASS:0 // CLASS:0 #37 = Parameter METHOD_ONLY:0 // METHOD_ONLY:0 #44 = Parameter METHOD_AND_CLASS:0 // METHOD_AND_CLASS:0 also there will be several elements with the new attribute `Parametric` which will appear in both fields, the `Pair` class per-se and methods: `make` and `setFst`. Let's now assume we define a Client willing to use class `Pair`, it will need to define values to bound to the "holes" defined in class `Pair` using the `Parametric` annotation. For this class Client should use annotations `@LinkageClass` and or `@LinkageMethod` depending on the kind of hole in class `Pair` it is intending to bound to. Let's define class `Client` as: import java.lang.annotation.*; class Client { @LinkageClass("linkageClass") void linkClassParams() { Pair psi = new Pair<>("first", 2); } @LinkageClass("linkageClass") void linkClassParamsFieldAccess(Pair psi) { psi.fst = "field"; } @LinkageMethod("linkageMethod1") void linkMethodParams(Pair psi) { Pair pair = Pair.make("hello", 1); } @LinkageClass("linkageClass") @LinkageMethod("linkageMethod2") void linkClassAndMethodParams(Pair psi) { Pair pss = psi.setFst("b"); } } again compiling this class with the hidden option `-XDsupportParametricVM` we can find these new entries in the CP: #7 = Linkage #8:#9 // linkageClass:Pair #8 = String #10 // linkageClass #9 = Class #11 // Pair this Linkage CP entry is referred from method: `linkClassParams` as: void linkClassParams(); descriptor: ()V flags: (0x0000) Code: stack=4, locals=2, args_size=1 0: new #7 // Linkage linkageClass:Pair also: #25 = Linkage #8:#26 // linkageClass:Pair.fst:Ljava/lang/Object; #26 = Fieldref #7.#27 // Pair.fst:Ljava/lang/Object; #27 = NameAndType #28:#29 // fst:Ljava/lang/Object; referred from method: `linkClassParamsFieldAccess` the bytecode looks like: void linkClassParamsFieldAccess(Pair); descriptor: (LPair;)V flags: (0x0000) Code: stack=2, locals=2, args_size=2 0: aload_1 1: ldc #23 // String field 3: putfield #25 // Linkage linkageClass:Pair.fst:Ljava/lang/Object; 6: return also: #32 = Linkage #33:#34 // linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; #33 = String #35 // linkageMethod1 #34 = Methodref #9.#36 // Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; this time referred by method: `linkMethodParams` with bytecode: void linkMethodParams(Pair); descriptor: (LPair;)V flags: (0x0000) Code: stack=2, locals=3, args_size=2 0: ldc #30 // String hello 2: iconst_1 3: invokestatic #14 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; 6: invokestatic #32 // Linkage linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; 9: astore_2 10: return and finally: #41 = Linkage #42:#43 // linkageMethod2:Pair.setFst:(Ljava/lang/Object;)LPair; #42 = String #44 // linkageMethod2 #43 = Methodref #7.#45 // Pair.setFst:(Ljava/lang/Object;)LPair; in this last example it can be seen that Methodref at #43 is also pointing to #7 which, as commented above, is another Linkage_info entry in the CP. TIA, for the feedback and comments, Vicente ------------- Commit messages: - javac support for Experimental Parametric VM, first stab - Merge lworld Changes: https://git.openjdk.java.net/valhalla/pull/364/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=364&range=00 Stats: 778 lines in 24 files changed: 772 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/valhalla/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/364/head:pull/364 PR: https://git.openjdk.java.net/valhalla/pull/364 From github.com+5010047+kelthuzadx at openjdk.java.net Mon Mar 8 03:49:30 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Mon, 8 Mar 2021 03:49:30 GMT Subject: [lworld] RFR: 8263067: [lworld] Use tlab_allocate in MacroAssembler::store_inline_type_fields_to_buf [v2] In-Reply-To: References: Message-ID: > TLAB allocation in MacroAssembler::store_inline_type_fields_to_buf looks duplicated with MacroAssembler::tlab_allocate, we might use existing MacroAssembler::tlab_allocate instead of duplicated ones. It will generate safer and faster code. (See details on JBS). All jtreg tests are passed with slowdebug mode. > > Thanks! > Yang Yi Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: improve buffer instance allocation in MacroAssembler::store_inline_type_fields_to_buf ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/362/files - new: https://git.openjdk.java.net/valhalla/pull/362/files/e4b62d19..90e3b7c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=362&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=362&range=00-01 Stats: 46 lines in 2 files changed: 17 ins; 9 del; 20 mod Patch: https://git.openjdk.java.net/valhalla/pull/362.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/362/head:pull/362 PR: https://git.openjdk.java.net/valhalla/pull/362 From github.com+5010047+kelthuzadx at openjdk.java.net Mon Mar 8 04:44:18 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yi Yang) Date: Mon, 8 Mar 2021 04:44:18 GMT Subject: [lworld] RFR: 8263067: [lworld] Improve buffer instance allocation in MacroAssembler::store_inline_type_fields_to_buf In-Reply-To: References: <6mf42vuffMOMnOYtqMVGYQ-jJx4l_b0byTVDOkh3ILU=.bc9dbfa9-f361-4fdd-a1b0-85683531a11e@github.com> Message-ID: On Fri, 5 Mar 2021 08:06:52 GMT, Tobias Hartmann wrote: >> Hi Tobias, >> >> I think it's reasonable. We can create such a buffered instance similar to `MacroAssembler::allocate_instance` or just using it. What do you think? If you think it's a feasible way, I can also try to tweak the implementation, keeping using the same buffer allocation mechanism on aarch64. >> >> Thanks! >> Yang > > Yes, I think it would be nice to factor the common code out of `MacroAssembler::allocate_instance` (we don't need the zeroing and some of the checks) and use it for buffer allocation. Now it will try to allocate a new buffered inline instance either from TLAB or eden space. I tried to build and change its counterpart on aarch64 but failed. Fixing these errors may conflict with #353, so I keep it unchanged until #353 merged. I've noticed a [FIXME comment](https://github.com/openjdk/valhalla/pull/362/files#diff-5d34d63ceb6d72dd9124399b7628bf498b4dec22ea5c5edc0426e80ee6e3bae4R5456) that hope to inline buffer packing in place, it would reduce a call instruction and do all stuff(buffer allocation+packing) in fastpath, but on the other hand, it increases the compiled code size and the final code may be duplicated with pack handler in SharedRuntime::generate_buffered_inline_type_adapter. I'm not sure which is more attractive to us, or keep it unchanged? Looking forward to your inputs. Thanks! Yang ------------- PR: https://git.openjdk.java.net/valhalla/pull/362 From thartmann at openjdk.java.net Mon Mar 8 11:54:23 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 8 Mar 2021 11:54:23 GMT Subject: [lworld] RFR: 8263067: [lworld] Improve buffer instance allocation in MacroAssembler::store_inline_type_fields_to_buf [v2] In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 03:49:30 GMT, Yi Yang wrote: >> TLAB allocation in MacroAssembler::store_inline_type_fields_to_buf looks duplicated with MacroAssembler::tlab_allocate, we might use existing MacroAssembler::tlab_allocate instead of duplicated ones. It will generate safer and faster code. (See details on JBS). All jtreg tests are passed with slowdebug mode. When UseTLAB is disabled, we can also try to allocate the buffer object in eden space. >> >> Thanks! >> Yang > > Yi Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Found some little typos in the comments, otherwise the changes look good to me. I think the `FIXME` you've mentioned can be removed. Best regards, Tobias src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5415: > 5413: > 5414: #ifdef _LP64 > 5415: // The following code is similar to allocate_instance but has some slightly differences, `slightly differences` -> `slight differences` src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5417: > 5415: // The following code is similar to allocate_instance but has some slightly differences, > 5416: // e.g. object size is always not zero, sometimes it's constant; storing klass ptr after > 5417: // allocating is not necessary if vk != NULL, etc. allocate_instance can not aware of these. `allocate_instance can not aware of these` -> `allocate_instance is not aware of these` src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5456: > 5454: // 3. Initialize its fields with an inline class specific handler > 5455: if (vk != NULL) { > 5456: // FIXME -- do the packing in-line to avoid the runtime call This can be removed. I don't think it pays off. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5420: > 5418: Label slow_case; > 5419: // 1. Try to allocate a new buffered inline instance either from TLAB or eden space > 5420: mov(rscratch1, rax); // save rax for slow_case since *_allocate may corrupts it when allocation failed `corrupts it` -> `corrupt it` ------------- Marked as reviewed by thartmann (Committer). PR: https://git.openjdk.java.net/valhalla/pull/362 From yyang at openjdk.java.net Mon Mar 8 14:14:26 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 8 Mar 2021 14:14:26 GMT Subject: [lworld] RFR: 8263067: [lworld] Improve buffer instance allocation in MacroAssembler::store_inline_type_fields_to_buf [v3] In-Reply-To: References: Message-ID: > TLAB allocation in MacroAssembler::store_inline_type_fields_to_buf looks duplicated with MacroAssembler::tlab_allocate, we might use existing MacroAssembler::tlab_allocate instead of duplicated ones. It will generate safer and faster code. (See details on JBS). All jtreg tests are passed with slowdebug mode. When UseTLAB is disabled, we can also try to allocate the buffer object in eden space. > > Thanks! > Yang Yi Yang has updated the pull request incrementally with one additional commit since the last revision: fix comment typos ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/362/files - new: https://git.openjdk.java.net/valhalla/pull/362/files/90e3b7c9..a16daf38 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=362&range=02 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=362&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/valhalla/pull/362.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/362/head:pull/362 PR: https://git.openjdk.java.net/valhalla/pull/362 From yyang at openjdk.java.net Mon Mar 8 14:14:27 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 8 Mar 2021 14:14:27 GMT Subject: [lworld] RFR: 8263067: [lworld] Improve buffer instance allocation in MacroAssembler::store_inline_type_fields_to_buf [v2] In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 11:51:55 GMT, Tobias Hartmann wrote: >> Yi Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > Found some little typos in the comments, otherwise the changes look good to me. I think the `FIXME` you've mentioned can be removed. > > Best regards, > Tobias Thank you @TobiHartmann ! ------------- PR: https://git.openjdk.java.net/valhalla/pull/362 From yyang at openjdk.java.net Mon Mar 8 14:24:17 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 8 Mar 2021 14:24:17 GMT Subject: [lworld] Integrated: 8263067: [lworld] Improve buffer instance allocation in MacroAssembler::store_inline_type_fields_to_buf In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 07:24:34 GMT, Yi Yang wrote: > TLAB allocation in MacroAssembler::store_inline_type_fields_to_buf looks duplicated with MacroAssembler::tlab_allocate, we might use existing MacroAssembler::tlab_allocate instead of duplicated ones. It will generate safer and faster code. (See details on JBS). All jtreg tests are passed with slowdebug mode. When UseTLAB is disabled, we can also try to allocate the buffer object in eden space. > > Thanks! > Yang This pull request has now been integrated. Changeset: d3001a61 Author: Yi Yang Committer: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/d3001a61 Stats: 46 lines in 2 files changed: 11 ins; 9 del; 26 mod 8263067: [lworld] Improve buffer instance allocation in MacroAssembler::store_inline_type_fields_to_buf Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/valhalla/pull/362 From mcimadamore at openjdk.java.net Tue Mar 9 11:55:24 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 9 Mar 2021 11:55:24 GMT Subject: [lworld] RFR: javac support for Parametric VM, first stab In-Reply-To: References: Message-ID: On Sun, 7 Mar 2021 00:30:42 GMT, Vicente Romero wrote: > This patch is the initial support for Parametric VM in javac. This is the first iteration of the prototype, so still a work in progress. In order to test the new code users need to pass the hidden option: `-XDsupportParametricVM` to javac. See the examples below for an illustration of the bytecode the compiler can generate now. Lets assume we have the following class annotated with the `@Parametric` annotation: > > import java.lang.annotation.*; > > @Parametric(id="PAIR") > class Pair { > @Parametric(id="PAIR") > X fst; > @Parametric(id="PAIR") > Y snd; > > Pair(X fst, Y snd) { > this.fst = fst; > this.snd = snd; > } > > Pair swap() { > return new Pair<>(snd, fst); > } > > @Parametric(id="make", kind=ParamKind.METHOD_ONLY) > static Pair make(U fst, W snd) { > return new Pair<>(fst, snd); > } > > @Parametric(id="setFst", kind=ParamKind.METHOD_AND_CLASS) > Pair setFst(Z newFst) { > return null; > } > } > > After compilation this class will contain the following new entries in the constant pool: > > #22 = Parameter CLASS:0 // CLASS:0 > #37 = Parameter METHOD_ONLY:0 // METHOD_ONLY:0 > #44 = Parameter METHOD_AND_CLASS:0 // METHOD_AND_CLASS:0 > also there will be several elements with the new attribute `Parametric` which will appear in both fields, the `Pair` class per-se and methods: `make` and `setFst`. > > Let's now assume we define a Client willing to use class `Pair`, it will need to define values to bound to the "holes" defined in class `Pair` using the `Parametric` annotation. For this class Client should use annotations `@LinkageClass` and or `@LinkageMethod` depending on the kind of hole in class `Pair` it is intending to bound to. Let's define class `Client` as: > > import java.lang.annotation.*; > > class Client { > @LinkageClass("linkageClass") > void linkClassParams() { > Pair psi = new Pair<>("first", 2); > } > > @LinkageClass("linkageClass") > void linkClassParamsFieldAccess(Pair psi) { > psi.fst = "field"; > } > > > @LinkageMethod("linkageMethod1") > void linkMethodParams(Pair psi) { > Pair pair = Pair.make("hello", 1); > } > > @LinkageClass("linkageClass") > @LinkageMethod("linkageMethod2") > void linkClassAndMethodParams(Pair psi) { > Pair pss = psi.setFst("b"); > } > } > > again compiling this class with the hidden option `-XDsupportParametricVM` we can find these new entries in the CP: > > #7 = Linkage #8:#9 // linkageClass:Pair > #8 = String #10 // linkageClass > #9 = Class #11 // Pair > > this Linkage CP entry is referred from method: `linkClassParams` as: > > void linkClassParams(); > descriptor: ()V > flags: (0x0000) > Code: > stack=4, locals=2, args_size=1 > 0: new #7 // Linkage linkageClass:Pair > > also: > > #25 = Linkage #8:#26 // linkageClass:Pair.fst:Ljava/lang/Object; > #26 = Fieldref #7.#27 // Pair.fst:Ljava/lang/Object; > #27 = NameAndType #28:#29 // fst:Ljava/lang/Object; > > referred from method: `linkClassParamsFieldAccess` the bytecode looks like: > > void linkClassParamsFieldAccess(Pair); > descriptor: (LPair;)V > flags: (0x0000) > Code: > stack=2, locals=2, args_size=2 > 0: aload_1 > 1: ldc #23 // String field > 3: putfield #25 // Linkage linkageClass:Pair.fst:Ljava/lang/Object; > 6: return > > also: > > #32 = Linkage #33:#34 // linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; > #33 = String #35 // linkageMethod1 > #34 = Methodref #9.#36 // Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; > > this time referred by method: `linkMethodParams` with bytecode: > > void linkMethodParams(Pair); > descriptor: (LPair;)V > flags: (0x0000) > Code: > stack=2, locals=3, args_size=2 > 0: ldc #30 // String hello > 2: iconst_1 > 3: invokestatic #14 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; > 6: invokestatic #32 // Linkage linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; > 9: astore_2 > 10: return > > and finally: > > #41 = Linkage #42:#43 // linkageMethod2:Pair.setFst:(Ljava/lang/Object;)LPair; > #42 = String #44 // linkageMethod2 > #43 = Methodref #7.#45 // Pair.setFst:(Ljava/lang/Object;)LPair; > > in this last example it can be seen that Methodref at #43 is also pointing to #7 which, as commented above, is another Linkage_info entry in the CP. > > TIA, for the feedback and comments, > Vicente Overall looks solid - I see that that there's no ClassReader support, which is probably ok given that we rely on (declaration) annotations to do the job. src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java line 201: > 199: * Linkage_info constant in the constant pool > 200: */ > 201: int generateLinkage(Object s, Attribute.Compound parametricAnno) { This can probably be simplified, by having this method return the constant to be added - e.g. Pool.Constant wrapWithLinkageIfNeeded(...) And then let clients call `writeIfNeeded`, so that if flow is also more consistent with other pool methods. src/java.base/share/classes/java/lang/annotation/Parametric.java line 31: > 29: */ > 30: @Target({ElementType.TYPE, ElementType.FIELD, ElementType.METHOD, ElementType.CONSTRUCTOR}) > 31: public @interface Parametric { Since we depend on this during code generation, should this has runtime retention? Otherwise, with separate compilation, I don't think we're able to see that a class is parameteric (if we're using it from a different client) ? ------------- PR: https://git.openjdk.java.net/valhalla/pull/364 From mcimadamore at openjdk.java.net Tue Mar 9 12:00:27 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 9 Mar 2021 12:00:27 GMT Subject: [lworld] RFR: javac support for Parametric VM, first stab In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 11:52:17 GMT, Maurizio Cimadamore wrote: >> This patch is the initial support for Parametric VM in javac. This is the first iteration of the prototype, so still a work in progress. In order to test the new code users need to pass the hidden option: `-XDsupportParametricVM` to javac. See the examples below for an illustration of the bytecode the compiler can generate now. Lets assume we have the following class annotated with the `@Parametric` annotation: >> >> import java.lang.annotation.*; >> >> @Parametric(id="PAIR") >> class Pair { >> @Parametric(id="PAIR") >> X fst; >> @Parametric(id="PAIR") >> Y snd; >> >> Pair(X fst, Y snd) { >> this.fst = fst; >> this.snd = snd; >> } >> >> Pair swap() { >> return new Pair<>(snd, fst); >> } >> >> @Parametric(id="make", kind=ParamKind.METHOD_ONLY) >> static Pair make(U fst, W snd) { >> return new Pair<>(fst, snd); >> } >> >> @Parametric(id="setFst", kind=ParamKind.METHOD_AND_CLASS) >> Pair setFst(Z newFst) { >> return null; >> } >> } >> >> After compilation this class will contain the following new entries in the constant pool: >> >> #22 = Parameter CLASS:0 // CLASS:0 >> #37 = Parameter METHOD_ONLY:0 // METHOD_ONLY:0 >> #44 = Parameter METHOD_AND_CLASS:0 // METHOD_AND_CLASS:0 >> also there will be several elements with the new attribute `Parametric` which will appear in both fields, the `Pair` class per-se and methods: `make` and `setFst`. >> >> Let's now assume we define a Client willing to use class `Pair`, it will need to define values to bound to the "holes" defined in class `Pair` using the `Parametric` annotation. For this class Client should use annotations `@LinkageClass` and or `@LinkageMethod` depending on the kind of hole in class `Pair` it is intending to bound to. Let's define class `Client` as: >> >> import java.lang.annotation.*; >> >> class Client { >> @LinkageClass("linkageClass") >> void linkClassParams() { >> Pair psi = new Pair<>("first", 2); >> } >> >> @LinkageClass("linkageClass") >> void linkClassParamsFieldAccess(Pair psi) { >> psi.fst = "field"; >> } >> >> >> @LinkageMethod("linkageMethod1") >> void linkMethodParams(Pair psi) { >> Pair pair = Pair.make("hello", 1); >> } >> >> @LinkageClass("linkageClass") >> @LinkageMethod("linkageMethod2") >> void linkClassAndMethodParams(Pair psi) { >> Pair pss = psi.setFst("b"); >> } >> } >> >> again compiling this class with the hidden option `-XDsupportParametricVM` we can find these new entries in the CP: >> >> #7 = Linkage #8:#9 // linkageClass:Pair >> #8 = String #10 // linkageClass >> #9 = Class #11 // Pair >> >> this Linkage CP entry is referred from method: `linkClassParams` as: >> >> void linkClassParams(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=4, locals=2, args_size=1 >> 0: new #7 // Linkage linkageClass:Pair >> >> also: >> >> #25 = Linkage #8:#26 // linkageClass:Pair.fst:Ljava/lang/Object; >> #26 = Fieldref #7.#27 // Pair.fst:Ljava/lang/Object; >> #27 = NameAndType #28:#29 // fst:Ljava/lang/Object; >> >> referred from method: `linkClassParamsFieldAccess` the bytecode looks like: >> >> void linkClassParamsFieldAccess(Pair); >> descriptor: (LPair;)V >> flags: (0x0000) >> Code: >> stack=2, locals=2, args_size=2 >> 0: aload_1 >> 1: ldc #23 // String field >> 3: putfield #25 // Linkage linkageClass:Pair.fst:Ljava/lang/Object; >> 6: return >> >> also: >> >> #32 = Linkage #33:#34 // linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> #33 = String #35 // linkageMethod1 >> #34 = Methodref #9.#36 // Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> >> this time referred by method: `linkMethodParams` with bytecode: >> >> void linkMethodParams(Pair); >> descriptor: (LPair;)V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=2 >> 0: ldc #30 // String hello >> 2: iconst_1 >> 3: invokestatic #14 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; >> 6: invokestatic #32 // Linkage linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> 9: astore_2 >> 10: return >> >> and finally: >> >> #41 = Linkage #42:#43 // linkageMethod2:Pair.setFst:(Ljava/lang/Object;)LPair; >> #42 = String #44 // linkageMethod2 >> #43 = Methodref #7.#45 // Pair.setFst:(Ljava/lang/Object;)LPair; >> >> in this last example it can be seen that Methodref at #43 is also pointing to #7 which, as commented above, is another Linkage_info entry in the CP. >> >> TIA, for the feedback and comments, >> Vicente > > src/java.base/share/classes/java/lang/annotation/Parametric.java line 31: > >> 29: */ >> 30: @Target({ElementType.TYPE, ElementType.FIELD, ElementType.METHOD, ElementType.CONSTRUCTOR}) >> 31: public @interface Parametric { > > Since we depend on this during code generation, should this has runtime retention? Otherwise, with separate compilation, I don't think we're able to see that a class is parameteric (if we're using it from a different client) ? Nevermind - default retention is CLASS - which is good enough (no reflection, but compiler support). ------------- PR: https://git.openjdk.java.net/valhalla/pull/364 From mcimadamore at openjdk.java.net Tue Mar 9 12:06:25 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 9 Mar 2021 12:06:25 GMT Subject: [lworld] RFR: javac support for Parametric VM, first stab In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 11:51:15 GMT, Maurizio Cimadamore wrote: >> This patch is the initial support for Parametric VM in javac. This is the first iteration of the prototype, so still a work in progress. In order to test the new code users need to pass the hidden option: `-XDsupportParametricVM` to javac. See the examples below for an illustration of the bytecode the compiler can generate now. Lets assume we have the following class annotated with the `@Parametric` annotation: >> >> import java.lang.annotation.*; >> >> @Parametric(id="PAIR") >> class Pair { >> @Parametric(id="PAIR") >> X fst; >> @Parametric(id="PAIR") >> Y snd; >> >> Pair(X fst, Y snd) { >> this.fst = fst; >> this.snd = snd; >> } >> >> Pair swap() { >> return new Pair<>(snd, fst); >> } >> >> @Parametric(id="make", kind=ParamKind.METHOD_ONLY) >> static Pair make(U fst, W snd) { >> return new Pair<>(fst, snd); >> } >> >> @Parametric(id="setFst", kind=ParamKind.METHOD_AND_CLASS) >> Pair setFst(Z newFst) { >> return null; >> } >> } >> >> After compilation this class will contain the following new entries in the constant pool: >> >> #22 = Parameter CLASS:0 // CLASS:0 >> #37 = Parameter METHOD_ONLY:0 // METHOD_ONLY:0 >> #44 = Parameter METHOD_AND_CLASS:0 // METHOD_AND_CLASS:0 >> also there will be several elements with the new attribute `Parametric` which will appear in both fields, the `Pair` class per-se and methods: `make` and `setFst`. >> >> Let's now assume we define a Client willing to use class `Pair`, it will need to define values to bound to the "holes" defined in class `Pair` using the `Parametric` annotation. For this class Client should use annotations `@LinkageClass` and or `@LinkageMethod` depending on the kind of hole in class `Pair` it is intending to bound to. Let's define class `Client` as: >> >> import java.lang.annotation.*; >> >> class Client { >> @LinkageClass("linkageClass") >> void linkClassParams() { >> Pair psi = new Pair<>("first", 2); >> } >> >> @LinkageClass("linkageClass") >> void linkClassParamsFieldAccess(Pair psi) { >> psi.fst = "field"; >> } >> >> >> @LinkageMethod("linkageMethod1") >> void linkMethodParams(Pair psi) { >> Pair pair = Pair.make("hello", 1); >> } >> >> @LinkageClass("linkageClass") >> @LinkageMethod("linkageMethod2") >> void linkClassAndMethodParams(Pair psi) { >> Pair pss = psi.setFst("b"); >> } >> } >> >> again compiling this class with the hidden option `-XDsupportParametricVM` we can find these new entries in the CP: >> >> #7 = Linkage #8:#9 // linkageClass:Pair >> #8 = String #10 // linkageClass >> #9 = Class #11 // Pair >> >> this Linkage CP entry is referred from method: `linkClassParams` as: >> >> void linkClassParams(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=4, locals=2, args_size=1 >> 0: new #7 // Linkage linkageClass:Pair >> >> also: >> >> #25 = Linkage #8:#26 // linkageClass:Pair.fst:Ljava/lang/Object; >> #26 = Fieldref #7.#27 // Pair.fst:Ljava/lang/Object; >> #27 = NameAndType #28:#29 // fst:Ljava/lang/Object; >> >> referred from method: `linkClassParamsFieldAccess` the bytecode looks like: >> >> void linkClassParamsFieldAccess(Pair); >> descriptor: (LPair;)V >> flags: (0x0000) >> Code: >> stack=2, locals=2, args_size=2 >> 0: aload_1 >> 1: ldc #23 // String field >> 3: putfield #25 // Linkage linkageClass:Pair.fst:Ljava/lang/Object; >> 6: return >> >> also: >> >> #32 = Linkage #33:#34 // linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> #33 = String #35 // linkageMethod1 >> #34 = Methodref #9.#36 // Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> >> this time referred by method: `linkMethodParams` with bytecode: >> >> void linkMethodParams(Pair); >> descriptor: (LPair;)V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=2 >> 0: ldc #30 // String hello >> 2: iconst_1 >> 3: invokestatic #14 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; >> 6: invokestatic #32 // Linkage linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> 9: astore_2 >> 10: return >> >> and finally: >> >> #41 = Linkage #42:#43 // linkageMethod2:Pair.setFst:(Ljava/lang/Object;)LPair; >> #42 = String #44 // linkageMethod2 >> #43 = Methodref #7.#45 // Pair.setFst:(Ljava/lang/Object;)LPair; >> >> in this last example it can be seen that Methodref at #43 is also pointing to #7 which, as commented above, is another Linkage_info entry in the CP. >> >> TIA, for the feedback and comments, >> Vicente > > Overall looks solid - I see that that there's no ClassReader support, which is probably ok given that we rely on (declaration) annotations to do the job. Tried out on few examples, and it seems to work as expected - javap support working too. Well done! ------------- PR: https://git.openjdk.java.net/valhalla/pull/364 From dsimms at openjdk.java.net Thu Mar 11 10:22:46 2021 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 11 Mar 2021 10:22:46 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge tag 'jdk-17+13' ------------- Commit messages: - Whitespace - Merge tag 'jdk-17+13' into lworld_merge_jdk_17_13 - 8238812: assert(false) failed: bad AD file - 8262438: sun/security/ssl/SSLLogger/LoggingFormatConsistency.java failed with "SocketException: Socket is closed" - 8262471: Fix coding style in src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java - 8262913: KlassFactory::create_from_stream should never return NULL - 8247869: Change NONCOPYABLE to delete the operations - 6251901: BasicTextUI: installDefaults method are contrary to the documentation - 8263233: Update java.net and java.nio to use instanceof pattern variable - 8263170: ComboBoxModel documentation refers to a nonexistent type - ... and 102 more: https://git.openjdk.java.net/valhalla/compare/d3001a61...5b5d6805 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=365&range=00.0 - jdk: https://webrevs.openjdk.java.net/?repo=valhalla&pr=365&range=00.1 Changes: https://git.openjdk.java.net/valhalla/pull/365/files Stats: 10349 lines in 364 files changed: 5594 ins; 3026 del; 1729 mod Patch: https://git.openjdk.java.net/valhalla/pull/365.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/365/head:pull/365 PR: https://git.openjdk.java.net/valhalla/pull/365 From dsimms at openjdk.java.net Thu Mar 11 11:58:54 2021 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 11 Mar 2021 11:58:54 GMT Subject: [lworld] RFR: Merge jdk [v2] In-Reply-To: References: Message-ID: > Merge tag 'jdk-17+13' David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 1118 commits: - Whitespace - Merge tag 'jdk-17+13' into lworld_merge_jdk_17_13 Added tag jdk-17+13 for changeset 4b5be40ab # Conflicts: # src/hotspot/share/memory/archiveBuilder.cpp # src/hotspot/share/oops/method.cpp # src/hotspot/share/opto/library_call.cpp # src/hotspot/share/prims/unsafe.cpp # src/hotspot/share/runtime/sharedRuntime.cpp - 8263067: [lworld] Improve buffer instance allocation in MacroAssembler::store_inline_type_fields_to_buf Reviewed-by: thartmann - Merge jdk Merge tag 'jdk-17+12' - 8262863: [lworld] C2 should keep track of the oop even if an inline type is returned as fields - 8262746: [lworld] jcmd VM.class_print_layout crash due to NULL cld name Reviewed-by: fparain - 8262748: [lworld] print out reason information for Deoptimize instruction Reviewed-by: thartmann - 8262747: [lworld] C1 compilation fails when PinAllInstructions is turned on Reviewed-by: thartmann - 8262308: [lworld] Various small C2 fixes for bugs found by stress testing - Merge jdk Merge tag 'jdk-17+11' - ... and 1108 more: https://git.openjdk.java.net/valhalla/compare/4b5be40a...5b5d6805 ------------- Changes: https://git.openjdk.java.net/valhalla/pull/365/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=365&range=01 Stats: 145027 lines in 1320 files changed: 138416 ins; 2038 del; 4573 mod Patch: https://git.openjdk.java.net/valhalla/pull/365.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/365/head:pull/365 PR: https://git.openjdk.java.net/valhalla/pull/365 From dsimms at openjdk.java.net Thu Mar 11 11:58:57 2021 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 11 Mar 2021 11:58:57 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 10:18:18 GMT, David Simms wrote: > Merge tag 'jdk-17+13' This pull request has now been integrated. Changeset: c04dc73c Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/c04dc73c Stats: 10349 lines in 364 files changed: 5594 ins; 3026 del; 1729 mod Merge jdk Merge tag 'jdk-17+13' ------------- PR: https://git.openjdk.java.net/valhalla/pull/365 From vromero at openjdk.java.net Thu Mar 11 19:16:44 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 11 Mar 2021 19:16:44 GMT Subject: [lworld] RFR: javac support for Parametric VM, first stab [v2] In-Reply-To: References: Message-ID: > This patch is the initial support for Parametric VM in javac. This is the first iteration of the prototype, so still a work in progress. In order to test the new code users need to pass the hidden option: `-XDsupportParametricVM` to javac. See the examples below for an illustration of the bytecode the compiler can generate now. Lets assume we have the following class annotated with the `@Parametric` annotation: > > import java.lang.annotation.*; > > @Parametric(id="PAIR") > class Pair { > @Parametric(id="PAIR") > X fst; > @Parametric(id="PAIR") > Y snd; > > Pair(X fst, Y snd) { > this.fst = fst; > this.snd = snd; > } > > Pair swap() { > return new Pair<>(snd, fst); > } > > @Parametric(id="make", kind=ParamKind.METHOD_ONLY) > static Pair make(U fst, W snd) { > return new Pair<>(fst, snd); > } > > @Parametric(id="setFst", kind=ParamKind.METHOD_AND_CLASS) > Pair setFst(Z newFst) { > return null; > } > } > > After compilation this class will contain the following new entries in the constant pool: > > #22 = Parameter CLASS:0 // CLASS:0 > #37 = Parameter METHOD_ONLY:0 // METHOD_ONLY:0 > #44 = Parameter METHOD_AND_CLASS:0 // METHOD_AND_CLASS:0 > also there will be several elements with the new attribute `Parametric` which will appear in both fields, the `Pair` class per-se and methods: `make` and `setFst`. > > Let's now assume we define a Client willing to use class `Pair`, it will need to define values to bound to the "holes" defined in class `Pair` using the `Parametric` annotation. For this class Client should use annotations `@LinkageClass` and or `@LinkageMethod` depending on the kind of hole in class `Pair` it is intending to bound to. Let's define class `Client` as: > > import java.lang.annotation.*; > > class Client { > @LinkageClass("linkageClass") > void linkClassParams() { > Pair psi = new Pair<>("first", 2); > } > > @LinkageClass("linkageClass") > void linkClassParamsFieldAccess(Pair psi) { > psi.fst = "field"; > } > > > @LinkageMethod("linkageMethod1") > void linkMethodParams(Pair psi) { > Pair pair = Pair.make("hello", 1); > } > > @LinkageClass("linkageClass") > @LinkageMethod("linkageMethod2") > void linkClassAndMethodParams(Pair psi) { > Pair pss = psi.setFst("b"); > } > } > > again compiling this class with the hidden option `-XDsupportParametricVM` we can find these new entries in the CP: > > #7 = Linkage #8:#9 // linkageClass:Pair > #8 = String #10 // linkageClass > #9 = Class #11 // Pair > > this Linkage CP entry is referred from method: `linkClassParams` as: > > void linkClassParams(); > descriptor: ()V > flags: (0x0000) > Code: > stack=4, locals=2, args_size=1 > 0: new #7 // Linkage linkageClass:Pair > > also: > > #25 = Linkage #8:#26 // linkageClass:Pair.fst:Ljava/lang/Object; > #26 = Fieldref #7.#27 // Pair.fst:Ljava/lang/Object; > #27 = NameAndType #28:#29 // fst:Ljava/lang/Object; > > referred from method: `linkClassParamsFieldAccess` the bytecode looks like: > > void linkClassParamsFieldAccess(Pair); > descriptor: (LPair;)V > flags: (0x0000) > Code: > stack=2, locals=2, args_size=2 > 0: aload_1 > 1: ldc #23 // String field > 3: putfield #25 // Linkage linkageClass:Pair.fst:Ljava/lang/Object; > 6: return > > also: > > #32 = Linkage #33:#34 // linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; > #33 = String #35 // linkageMethod1 > #34 = Methodref #9.#36 // Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; > > this time referred by method: `linkMethodParams` with bytecode: > > void linkMethodParams(Pair); > descriptor: (LPair;)V > flags: (0x0000) > Code: > stack=2, locals=3, args_size=2 > 0: ldc #30 // String hello > 2: iconst_1 > 3: invokestatic #14 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; > 6: invokestatic #32 // Linkage linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; > 9: astore_2 > 10: return > > and finally: > > #41 = Linkage #42:#43 // linkageMethod2:Pair.setFst:(Ljava/lang/Object;)LPair; > #42 = String #44 // linkageMethod2 > #43 = Methodref #7.#45 // Pair.setFst:(Ljava/lang/Object;)LPair; > > in this last example it can be seen that Methodref at #43 is also pointing to #7 which, as commented above, is another Linkage_info entry in the CP. > > TIA, for the feedback and comments, > Vicente Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/364/files - new: https://git.openjdk.java.net/valhalla/pull/364/files/443a0cab..20a7f16e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=364&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=364&range=00-01 Stats: 52 lines in 1 file changed: 5 ins; 30 del; 17 mod Patch: https://git.openjdk.java.net/valhalla/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/364/head:pull/364 PR: https://git.openjdk.java.net/valhalla/pull/364 From vromero at openjdk.java.net Thu Mar 11 19:16:45 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 11 Mar 2021 19:16:45 GMT Subject: [lworld] RFR: javac support for Parametric VM, first stab [v2] In-Reply-To: References: Message-ID: <-bh9mZ7YraqZPx2IxR8epMWa_fEbkbNFausldz42QNs=.3567fb43-c17e-4f25-bbab-133b16e1d724@github.com> On Tue, 9 Mar 2021 12:03:17 GMT, Maurizio Cimadamore wrote: > Tried out on few examples, and it seems to work as expected - javap support working too. Well done! thanks for the review! ------------- PR: https://git.openjdk.java.net/valhalla/pull/364 From mcimadamore at openjdk.java.net Fri Mar 12 12:40:25 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 12 Mar 2021 12:40:25 GMT Subject: [lworld] RFR: javac support for Parametric VM, first stab [v2] In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 19:16:44 GMT, Vicente Romero wrote: >> This patch is the initial support for Parametric VM in javac. This is the first iteration of the prototype, so still a work in progress. In order to test the new code users need to pass the hidden option: `-XDsupportParametricVM` to javac. See the examples below for an illustration of the bytecode the compiler can generate now. Lets assume we have the following class annotated with the `@Parametric` annotation: >> >> import java.lang.annotation.*; >> >> @Parametric(id="PAIR") >> class Pair { >> @Parametric(id="PAIR") >> X fst; >> @Parametric(id="PAIR") >> Y snd; >> >> Pair(X fst, Y snd) { >> this.fst = fst; >> this.snd = snd; >> } >> >> Pair swap() { >> return new Pair<>(snd, fst); >> } >> >> @Parametric(id="make", kind=ParamKind.METHOD_ONLY) >> static Pair make(U fst, W snd) { >> return new Pair<>(fst, snd); >> } >> >> @Parametric(id="setFst", kind=ParamKind.METHOD_AND_CLASS) >> Pair setFst(Z newFst) { >> return null; >> } >> } >> >> After compilation this class will contain the following new entries in the constant pool: >> >> #22 = Parameter CLASS:0 // CLASS:0 >> #37 = Parameter METHOD_ONLY:0 // METHOD_ONLY:0 >> #44 = Parameter METHOD_AND_CLASS:0 // METHOD_AND_CLASS:0 >> also there will be several elements with the new attribute `Parametric` which will appear in both fields, the `Pair` class per-se and methods: `make` and `setFst`. >> >> Let's now assume we define a Client willing to use class `Pair`, it will need to define values to bound to the "holes" defined in class `Pair` using the `Parametric` annotation. For this class Client should use annotations `@LinkageClass` and or `@LinkageMethod` depending on the kind of hole in class `Pair` it is intending to bound to. Let's define class `Client` as: >> >> import java.lang.annotation.*; >> >> class Client { >> @LinkageClass("linkageClass") >> void linkClassParams() { >> Pair psi = new Pair<>("first", 2); >> } >> >> @LinkageClass("linkageClass") >> void linkClassParamsFieldAccess(Pair psi) { >> psi.fst = "field"; >> } >> >> >> @LinkageMethod("linkageMethod1") >> void linkMethodParams(Pair psi) { >> Pair pair = Pair.make("hello", 1); >> } >> >> @LinkageClass("linkageClass") >> @LinkageMethod("linkageMethod2") >> void linkClassAndMethodParams(Pair psi) { >> Pair pss = psi.setFst("b"); >> } >> } >> >> again compiling this class with the hidden option `-XDsupportParametricVM` we can find these new entries in the CP: >> >> #7 = Linkage #8:#9 // linkageClass:Pair >> #8 = String #10 // linkageClass >> #9 = Class #11 // Pair >> >> this Linkage CP entry is referred from method: `linkClassParams` as: >> >> void linkClassParams(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=4, locals=2, args_size=1 >> 0: new #7 // Linkage linkageClass:Pair >> >> also: >> >> #25 = Linkage #8:#26 // linkageClass:Pair.fst:Ljava/lang/Object; >> #26 = Fieldref #7.#27 // Pair.fst:Ljava/lang/Object; >> #27 = NameAndType #28:#29 // fst:Ljava/lang/Object; >> >> referred from method: `linkClassParamsFieldAccess` the bytecode looks like: >> >> void linkClassParamsFieldAccess(Pair); >> descriptor: (LPair;)V >> flags: (0x0000) >> Code: >> stack=2, locals=2, args_size=2 >> 0: aload_1 >> 1: ldc #23 // String field >> 3: putfield #25 // Linkage linkageClass:Pair.fst:Ljava/lang/Object; >> 6: return >> >> also: >> >> #32 = Linkage #33:#34 // linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> #33 = String #35 // linkageMethod1 >> #34 = Methodref #9.#36 // Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> >> this time referred by method: `linkMethodParams` with bytecode: >> >> void linkMethodParams(Pair); >> descriptor: (LPair;)V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=2 >> 0: ldc #30 // String hello >> 2: iconst_1 >> 3: invokestatic #14 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; >> 6: invokestatic #32 // Linkage linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> 9: astore_2 >> 10: return >> >> and finally: >> >> #41 = Linkage #42:#43 // linkageMethod2:Pair.setFst:(Ljava/lang/Object;)LPair; >> #42 = String #44 // linkageMethod2 >> #43 = Methodref #7.#45 // Pair.setFst:(Ljava/lang/Object;)LPair; >> >> in this last example it can be seen that Methodref at #43 is also pointing to #7 which, as commented above, is another Linkage_info entry in the CP. >> >> TIA, for the feedback and comments, >> Vicente > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments I realized that the logic for adding parameter entries is not 100% correct - added some comments. src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 887: > 885: }; > 886: } > 887: databuf.appendChar(poolWriter.putParameter(kind)); There is something fishy here: note that parameter have an "id" - which can be reused by other entries. That is, you can have 5 different @Parameteric annotations, referring to the same parameter ID. Wouldn't this create duplicate parameters in the constant pool? As a quick hack - we could pretend that the parameter CP entry had a "name" so that, instead of doing `putParameter`, you do `putParameter(name)` and poolWriter will use existing uniqueness logic to determine if a new parameter has to be emitted. src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolConstant.java line 244: > 242: @Override > 243: public Object poolKey(Types types) { > 244: return Integer.valueOf(kind); This is not good enough - as it means that you can have only one parameter of each kind. See also my other related comment on this topic. I think this Parameter entry should have a "fake" String id, so that we can give them a name, and distinguish between them; then you can just use the String id as a pool key. ------------- PR: https://git.openjdk.java.net/valhalla/pull/364 From roland at openjdk.java.net Fri Mar 12 13:15:27 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Fri, 12 Mar 2021 13:15:27 GMT Subject: [lworld] RFR: 8262287: [lworld] C2 compilation fails with assert "should have been removed from the graph" [v2] In-Reply-To: References: Message-ID: > hook_memory_on_init() sets up memory edges so stores can be captured > at an allocation. To do that, it adds extra edges for each field after > and before the InitializeNode. This also happens for flat arrays > eventhough until Compile::adjust_flattened_array_access_aliases() runs > there's a single slice for all fields of a flat array element. The > extra edges added after the InitalizeNode can cause PhiNodes to be > created for each fields of the array element which confuses > Compile::adjust_flattened_array_access_aliases() (because it expects > no Phi for individual fields until it runs). I don't think the memory > edges out of the InitializeNode are needed as > Compile::adjust_flattened_array_access_aliases() should create > them. So I propose not adding them. Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - comments & test - fix ------------- Changes: https://git.openjdk.java.net/valhalla/pull/361/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=361&range=01 Stats: 42 lines in 4 files changed: 40 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/361.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/361/head:pull/361 PR: https://git.openjdk.java.net/valhalla/pull/361 From roland at openjdk.java.net Fri Mar 12 13:19:22 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Fri, 12 Mar 2021 13:19:22 GMT Subject: [lworld] RFR: 8262287: [lworld] C2 compilation fails with assert "should have been removed from the graph" [v2] In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 07:46:14 GMT, Tobias Hartmann wrote: > Looks good to me. Some comments wouldn't hurt though :) and could you please add the regression test? You can simply add it to `jtreg/compiler/valhalla/inlinetypes/TestGenerated.java` where the generated tests live. Thanks for the review. I updated the change accordingly. Sorry the force push but after merging github included extra changed and rebasing was the quickest way I found to fix this. ------------- PR: https://git.openjdk.java.net/valhalla/pull/361 From thartmann at openjdk.java.net Fri Mar 12 13:43:33 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 12 Mar 2021 13:43:33 GMT Subject: [lworld] RFR: 8263440: [lworld] C2 compilation fails with "Error mixing types: byte and inlinetype[1]:{byte}" Message-ID: Added missing handling of inline types to ideal node categorization `TypeInt::xmeet`. Thanks, Tobias ------------- Commit messages: - 8263440: [lworld] C2 compilation fails with "Error mixing types: byte and inlinetype[1]:{byte}" Changes: https://git.openjdk.java.net/valhalla/pull/366/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=366&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263440 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/366.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/366/head:pull/366 PR: https://git.openjdk.java.net/valhalla/pull/366 From roland at openjdk.java.net Fri Mar 12 14:54:17 2021 From: roland at openjdk.java.net (Roland Westrelin) Date: Fri, 12 Mar 2021 14:54:17 GMT Subject: [lworld] Integrated: 8262287: [lworld] C2 compilation fails with assert "should have been removed from the graph" In-Reply-To: References: Message-ID: On Thu, 4 Mar 2021 16:31:42 GMT, Roland Westrelin wrote: > hook_memory_on_init() sets up memory edges so stores can be captured > at an allocation. To do that, it adds extra edges for each field after > and before the InitializeNode. This also happens for flat arrays > eventhough until Compile::adjust_flattened_array_access_aliases() runs > there's a single slice for all fields of a flat array element. The > extra edges added after the InitalizeNode can cause PhiNodes to be > created for each fields of the array element which confuses > Compile::adjust_flattened_array_access_aliases() (because it expects > no Phi for individual fields until it runs). I don't think the memory > edges out of the InitializeNode are needed as > Compile::adjust_flattened_array_access_aliases() should create > them. So I propose not adding them. This pull request has now been integrated. Changeset: c2c4b2f7 Author: Roland Westrelin URL: https://git.openjdk.java.net/valhalla/commit/c2c4b2f7 Stats: 42 lines in 4 files changed: 40 ins; 0 del; 2 mod 8262287: [lworld] C2 compilation fails with assert "should have been removed from the graph" Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/valhalla/pull/361 From thartmann at openjdk.java.net Fri Mar 12 13:36:22 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 12 Mar 2021 13:36:22 GMT Subject: [lworld] RFR: 8262287: [lworld] C2 compilation fails with assert "should have been removed from the graph" [v2] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 13:15:27 GMT, Roland Westrelin wrote: >> hook_memory_on_init() sets up memory edges so stores can be captured >> at an allocation. To do that, it adds extra edges for each field after >> and before the InitializeNode. This also happens for flat arrays >> eventhough until Compile::adjust_flattened_array_access_aliases() runs >> there's a single slice for all fields of a flat array element. The >> extra edges added after the InitalizeNode can cause PhiNodes to be >> created for each fields of the array element which confuses >> Compile::adjust_flattened_array_access_aliases() (because it expects >> no Phi for individual fields until it runs). I don't think the memory >> edges out of the InitializeNode are needed as >> Compile::adjust_flattened_array_access_aliases() should create >> them. So I propose not adding them. > > Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - comments & test > - fix Looks good, thanks for making these changes. ------------- Marked as reviewed by thartmann (Committer). PR: https://git.openjdk.java.net/valhalla/pull/361 From thartmann at openjdk.java.net Fri Mar 12 16:13:35 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 12 Mar 2021 16:13:35 GMT Subject: [lworld] Integrated: 8263440: [lworld] C2 compilation fails with "Error mixing types: byte and inlinetype[1]:{byte}" In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 13:38:59 GMT, Tobias Hartmann wrote: > Added missing handling of inline types to ideal node categorization `TypeInt::xmeet`. > > Thanks, > Tobias This pull request has now been integrated. Changeset: d23b6440 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/d23b6440 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8263440: [lworld] C2 compilation fails with "Error mixing types: byte and inlinetype[1]:{byte}" ------------- PR: https://git.openjdk.java.net/valhalla/pull/366 From vromero at openjdk.java.net Fri Mar 12 17:33:57 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 12 Mar 2021 17:33:57 GMT Subject: RFR: javac support for Parametric VM, first stab [v3] In-Reply-To: References: Message-ID: > This patch is the initial support for Parametric VM in javac. This is the first iteration of the prototype, so still a work in progress. In order to test the new code users need to pass the hidden option: `-XDsupportParametricVM` to javac. See the examples below for an illustration of the bytecode the compiler can generate now. Lets assume we have the following class annotated with the `@Parametric` annotation: > > import java.lang.annotation.*; > > @Parametric(id="PAIR") > class Pair { > @Parametric(id="PAIR") > X fst; > @Parametric(id="PAIR") > Y snd; > > Pair(X fst, Y snd) { > this.fst = fst; > this.snd = snd; > } > > Pair swap() { > return new Pair<>(snd, fst); > } > > @Parametric(id="make", kind=ParamKind.METHOD_ONLY) > static Pair make(U fst, W snd) { > return new Pair<>(fst, snd); > } > > @Parametric(id="setFst", kind=ParamKind.METHOD_AND_CLASS) > Pair setFst(Z newFst) { > return null; > } > } > > After compilation this class will contain the following new entries in the constant pool: > > #22 = Parameter CLASS:0 // CLASS:0 > #37 = Parameter METHOD_ONLY:0 // METHOD_ONLY:0 > #44 = Parameter METHOD_AND_CLASS:0 // METHOD_AND_CLASS:0 > also there will be several elements with the new attribute `Parametric` which will appear in both fields, the `Pair` class per-se and methods: `make` and `setFst`. > > Let's now assume we define a Client willing to use class `Pair`, it will need to define values to bound to the "holes" defined in class `Pair` using the `Parametric` annotation. For this class Client should use annotations `@LinkageClass` and or `@LinkageMethod` depending on the kind of hole in class `Pair` it is intending to bound to. Let's define class `Client` as: > > import java.lang.annotation.*; > > class Client { > @LinkageClass("linkageClass") > void linkClassParams() { > Pair psi = new Pair<>("first", 2); > } > > @LinkageClass("linkageClass") > void linkClassParamsFieldAccess(Pair psi) { > psi.fst = "field"; > } > > > @LinkageMethod("linkageMethod1") > void linkMethodParams(Pair psi) { > Pair pair = Pair.make("hello", 1); > } > > @LinkageClass("linkageClass") > @LinkageMethod("linkageMethod2") > void linkClassAndMethodParams(Pair psi) { > Pair pss = psi.setFst("b"); > } > } > > again compiling this class with the hidden option `-XDsupportParametricVM` we can find these new entries in the CP: > > #7 = Linkage #8:#9 // linkageClass:Pair > #8 = String #10 // linkageClass > #9 = Class #11 // Pair > > this Linkage CP entry is referred from method: `linkClassParams` as: > > void linkClassParams(); > descriptor: ()V > flags: (0x0000) > Code: > stack=4, locals=2, args_size=1 > 0: new #7 // Linkage linkageClass:Pair > > also: > > #25 = Linkage #8:#26 // linkageClass:Pair.fst:Ljava/lang/Object; > #26 = Fieldref #7.#27 // Pair.fst:Ljava/lang/Object; > #27 = NameAndType #28:#29 // fst:Ljava/lang/Object; > > referred from method: `linkClassParamsFieldAccess` the bytecode looks like: > > void linkClassParamsFieldAccess(Pair); > descriptor: (LPair;)V > flags: (0x0000) > Code: > stack=2, locals=2, args_size=2 > 0: aload_1 > 1: ldc #23 // String field > 3: putfield #25 // Linkage linkageClass:Pair.fst:Ljava/lang/Object; > 6: return > > also: > > #32 = Linkage #33:#34 // linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; > #33 = String #35 // linkageMethod1 > #34 = Methodref #9.#36 // Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; > > this time referred by method: `linkMethodParams` with bytecode: > > void linkMethodParams(Pair); > descriptor: (LPair;)V > flags: (0x0000) > Code: > stack=2, locals=3, args_size=2 > 0: ldc #30 // String hello > 2: iconst_1 > 3: invokestatic #14 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; > 6: invokestatic #32 // Linkage linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; > 9: astore_2 > 10: return > > and finally: > > #41 = Linkage #42:#43 // linkageMethod2:Pair.setFst:(Ljava/lang/Object;)LPair; > #42 = String #44 // linkageMethod2 > #43 = Methodref #7.#45 // Pair.setFst:(Ljava/lang/Object;)LPair; > > in this last example it can be seen that Methodref at #43 is also pointing to #7 which, as commented above, is another Linkage_info entry in the CP. > > TIA, for the feedback and comments, > Vicente Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: associate an id to the Parameter CP ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/364/files - new: https://git.openjdk.java.net/valhalla/pull/364/files/20a7f16e..5b6afe9f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=364&range=02 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=364&range=01-02 Stats: 16 lines in 4 files changed: 12 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/valhalla/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/364/head:pull/364 PR: https://git.openjdk.java.net/valhalla/pull/364 From vromero at openjdk.java.net Fri Mar 12 17:33:58 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 12 Mar 2021 17:33:58 GMT Subject: RFR: javac support for Parametric VM, first stab In-Reply-To: <-bh9mZ7YraqZPx2IxR8epMWa_fEbkbNFausldz42QNs=.3567fb43-c17e-4f25-bbab-133b16e1d724@github.com> References: <-bh9mZ7YraqZPx2IxR8epMWa_fEbkbNFausldz42QNs=.3567fb43-c17e-4f25-bbab-133b16e1d724@github.com> Message-ID: On Thu, 11 Mar 2021 19:13:14 GMT, Vicente Romero wrote: >> Tried out on few examples, and it seems to work as expected - javap support working too. Well done! > >> Tried out on few examples, and it seems to work as expected - javap support working too. Well done! > > thanks for the review! Hi Maurizio, I have added another commit [5b6afe9](https://github.com/openjdk/valhalla/pull/364/commits/5b6afe9f90d1a90867a925ad3e443a20462f8524) that, I hope, fixes the issue with the Parameter CP you found, thanks for your comments ------------- PR: https://git.openjdk.java.net/valhalla/pull/364 From github.com+828220+forax at openjdk.java.net Fri Mar 12 19:31:18 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 12 Mar 2021 19:31:18 GMT Subject: RFR: javac support for Parametric VM, first stab [v3] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 17:33:57 GMT, Vicente Romero wrote: >> This patch is the initial support for Parametric VM in javac. This is the first iteration of the prototype, so still a work in progress. In order to test the new code users need to pass the hidden option: `-XDsupportParametricVM` to javac. See the examples below for an illustration of the bytecode the compiler can generate now. Lets assume we have the following class annotated with the `@Parametric` annotation: >> >> import java.lang.annotation.*; >> >> @Parametric(id="PAIR") >> class Pair { >> @Parametric(id="PAIR") >> X fst; >> @Parametric(id="PAIR") >> Y snd; >> >> Pair(X fst, Y snd) { >> this.fst = fst; >> this.snd = snd; >> } >> >> Pair swap() { >> return new Pair<>(snd, fst); >> } >> >> @Parametric(id="make", kind=ParamKind.METHOD_ONLY) >> static Pair make(U fst, W snd) { >> return new Pair<>(fst, snd); >> } >> >> @Parametric(id="setFst", kind=ParamKind.METHOD_AND_CLASS) >> Pair setFst(Z newFst) { >> return null; >> } >> } >> >> After compilation this class will contain the following new entries in the constant pool: >> >> #22 = Parameter CLASS:0 // CLASS:0 >> #37 = Parameter METHOD_ONLY:0 // METHOD_ONLY:0 >> #44 = Parameter METHOD_AND_CLASS:0 // METHOD_AND_CLASS:0 >> also there will be several elements with the new attribute `Parametric` which will appear in both fields, the `Pair` class per-se and methods: `make` and `setFst`. >> >> Let's now assume we define a Client willing to use class `Pair`, it will need to define values to bound to the "holes" defined in class `Pair` using the `Parametric` annotation. For this class Client should use annotations `@LinkageClass` and or `@LinkageMethod` depending on the kind of hole in class `Pair` it is intending to bound to. Let's define class `Client` as: >> >> import java.lang.annotation.*; >> >> class Client { >> @LinkageClass("linkageClass") >> void linkClassParams() { >> Pair psi = new Pair<>("first", 2); >> } >> >> @LinkageClass("linkageClass") >> void linkClassParamsFieldAccess(Pair psi) { >> psi.fst = "field"; >> } >> >> >> @LinkageMethod("linkageMethod1") >> void linkMethodParams(Pair psi) { >> Pair pair = Pair.make("hello", 1); >> } >> >> @LinkageClass("linkageClass") >> @LinkageMethod("linkageMethod2") >> void linkClassAndMethodParams(Pair psi) { >> Pair pss = psi.setFst("b"); >> } >> } >> >> again compiling this class with the hidden option `-XDsupportParametricVM` we can find these new entries in the CP: >> >> #7 = Linkage #8:#9 // linkageClass:Pair >> #8 = String #10 // linkageClass >> #9 = Class #11 // Pair >> >> this Linkage CP entry is referred from method: `linkClassParams` as: >> >> void linkClassParams(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=4, locals=2, args_size=1 >> 0: new #7 // Linkage linkageClass:Pair >> >> also: >> >> #25 = Linkage #8:#26 // linkageClass:Pair.fst:Ljava/lang/Object; >> #26 = Fieldref #7.#27 // Pair.fst:Ljava/lang/Object; >> #27 = NameAndType #28:#29 // fst:Ljava/lang/Object; >> >> referred from method: `linkClassParamsFieldAccess` the bytecode looks like: >> >> void linkClassParamsFieldAccess(Pair); >> descriptor: (LPair;)V >> flags: (0x0000) >> Code: >> stack=2, locals=2, args_size=2 >> 0: aload_1 >> 1: ldc #23 // String field >> 3: putfield #25 // Linkage linkageClass:Pair.fst:Ljava/lang/Object; >> 6: return >> >> also: >> >> #32 = Linkage #33:#34 // linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> #33 = String #35 // linkageMethod1 >> #34 = Methodref #9.#36 // Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> >> this time referred by method: `linkMethodParams` with bytecode: >> >> void linkMethodParams(Pair); >> descriptor: (LPair;)V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=2 >> 0: ldc #30 // String hello >> 2: iconst_1 >> 3: invokestatic #14 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; >> 6: invokestatic #32 // Linkage linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> 9: astore_2 >> 10: return >> >> and finally: >> >> #41 = Linkage #42:#43 // linkageMethod2:Pair.setFst:(Ljava/lang/Object;)LPair; >> #42 = String #44 // linkageMethod2 >> #43 = Methodref #7.#45 // Pair.setFst:(Ljava/lang/Object;)LPair; >> >> in this last example it can be seen that Methodref at #43 is also pointing to #7 which, as commented above, is another Linkage_info entry in the CP. >> >> TIA, for the feedback and comments, >> Vicente > > Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: > > associate an id to the Parameter CP src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolConstant.java line 234: > 232: final int kind; > 233: > 234: Parameter(int kind) { Why do you create a Parameter without an id ? ------------- PR: https://git.openjdk.java.net/valhalla/pull/364 From mcimadamore at openjdk.java.net Fri Mar 12 22:26:22 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 12 Mar 2021 22:26:22 GMT Subject: RFR: javac support for Parametric VM, first stab [v3] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 19:28:48 GMT, R?mi Forax wrote: >> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: >> >> associate an id to the Parameter CP > > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolConstant.java line 234: > >> 232: final int kind; >> 233: >> 234: Parameter(int kind) { > > Why do you create a Parameter without an id ? That is during class reading - where we don't care about the "id" anymore. The "id" is just a "fiction" when writing, to help us generating multiple CP holes (possibly with the same kind). ------------- PR: https://git.openjdk.java.net/valhalla/pull/364 From mcimadamore at openjdk.java.net Fri Mar 12 22:26:20 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 12 Mar 2021 22:26:20 GMT Subject: RFR: javac support for Parametric VM, first stab [v3] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 17:33:57 GMT, Vicente Romero wrote: >> This patch is the initial support for Parametric VM in javac. This is the first iteration of the prototype, so still a work in progress. In order to test the new code users need to pass the hidden option: `-XDsupportParametricVM` to javac. See the examples below for an illustration of the bytecode the compiler can generate now. Lets assume we have the following class annotated with the `@Parametric` annotation: >> >> import java.lang.annotation.*; >> >> @Parametric(id="PAIR") >> class Pair { >> @Parametric(id="PAIR") >> X fst; >> @Parametric(id="PAIR") >> Y snd; >> >> Pair(X fst, Y snd) { >> this.fst = fst; >> this.snd = snd; >> } >> >> Pair swap() { >> return new Pair<>(snd, fst); >> } >> >> @Parametric(id="make", kind=ParamKind.METHOD_ONLY) >> static Pair make(U fst, W snd) { >> return new Pair<>(fst, snd); >> } >> >> @Parametric(id="setFst", kind=ParamKind.METHOD_AND_CLASS) >> Pair setFst(Z newFst) { >> return null; >> } >> } >> >> After compilation this class will contain the following new entries in the constant pool: >> >> #22 = Parameter CLASS:0 // CLASS:0 >> #37 = Parameter METHOD_ONLY:0 // METHOD_ONLY:0 >> #44 = Parameter METHOD_AND_CLASS:0 // METHOD_AND_CLASS:0 >> also there will be several elements with the new attribute `Parametric` which will appear in both fields, the `Pair` class per-se and methods: `make` and `setFst`. >> >> Let's now assume we define a Client willing to use class `Pair`, it will need to define values to bound to the "holes" defined in class `Pair` using the `Parametric` annotation. For this class Client should use annotations `@LinkageClass` and or `@LinkageMethod` depending on the kind of hole in class `Pair` it is intending to bound to. Let's define class `Client` as: >> >> import java.lang.annotation.*; >> >> class Client { >> @LinkageClass("linkageClass") >> void linkClassParams() { >> Pair psi = new Pair<>("first", 2); >> } >> >> @LinkageClass("linkageClass") >> void linkClassParamsFieldAccess(Pair psi) { >> psi.fst = "field"; >> } >> >> >> @LinkageMethod("linkageMethod1") >> void linkMethodParams(Pair psi) { >> Pair pair = Pair.make("hello", 1); >> } >> >> @LinkageClass("linkageClass") >> @LinkageMethod("linkageMethod2") >> void linkClassAndMethodParams(Pair psi) { >> Pair pss = psi.setFst("b"); >> } >> } >> >> again compiling this class with the hidden option `-XDsupportParametricVM` we can find these new entries in the CP: >> >> #7 = Linkage #8:#9 // linkageClass:Pair >> #8 = String #10 // linkageClass >> #9 = Class #11 // Pair >> >> this Linkage CP entry is referred from method: `linkClassParams` as: >> >> void linkClassParams(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=4, locals=2, args_size=1 >> 0: new #7 // Linkage linkageClass:Pair >> >> also: >> >> #25 = Linkage #8:#26 // linkageClass:Pair.fst:Ljava/lang/Object; >> #26 = Fieldref #7.#27 // Pair.fst:Ljava/lang/Object; >> #27 = NameAndType #28:#29 // fst:Ljava/lang/Object; >> >> referred from method: `linkClassParamsFieldAccess` the bytecode looks like: >> >> void linkClassParamsFieldAccess(Pair); >> descriptor: (LPair;)V >> flags: (0x0000) >> Code: >> stack=2, locals=2, args_size=2 >> 0: aload_1 >> 1: ldc #23 // String field >> 3: putfield #25 // Linkage linkageClass:Pair.fst:Ljava/lang/Object; >> 6: return >> >> also: >> >> #32 = Linkage #33:#34 // linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> #33 = String #35 // linkageMethod1 >> #34 = Methodref #9.#36 // Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> >> this time referred by method: `linkMethodParams` with bytecode: >> >> void linkMethodParams(Pair); >> descriptor: (LPair;)V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=2 >> 0: ldc #30 // String hello >> 2: iconst_1 >> 3: invokestatic #14 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; >> 6: invokestatic #32 // Linkage linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; >> 9: astore_2 >> 10: return >> >> and finally: >> >> #41 = Linkage #42:#43 // linkageMethod2:Pair.setFst:(Ljava/lang/Object;)LPair; >> #42 = String #44 // linkageMethod2 >> #43 = Methodref #7.#45 // Pair.setFst:(Ljava/lang/Object;)LPair; >> >> in this last example it can be seen that Methodref at #43 is also pointing to #7 which, as commented above, is another Linkage_info entry in the CP. >> >> TIA, for the feedback and comments, >> Vicente > > Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: > > associate an id to the Parameter CP Looks good to me! ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/valhalla/pull/364 From github.com+828220+forax at openjdk.java.net Fri Mar 12 22:31:15 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 12 Mar 2021 22:31:15 GMT Subject: RFR: javac support for Parametric VM, first stab [v3] In-Reply-To: References: Message-ID: <05Nk46BWJa45r0-Y2O6mPE1S8FoDPpRgF86ybXPSbIc=.a4772dd7-681c-4b26-baaa-1c60a01b7f2a@github.com> On Fri, 12 Mar 2021 22:23:11 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolConstant.java line 234: >> >>> 232: final int kind; >>> 233: >>> 234: Parameter(int kind) { >> >> Why do you create a Parameter without an id ? > > That is during class reading - where we don't care about the "id" anymore. The "id" is just a "fiction" when writing, to help us generating multiple CP holes (possibly with the same kind). Ok, i did not think about that part of the process, and you do not do any roundtrip, reader - > javac -> gen, thanks ------------- PR: https://git.openjdk.java.net/valhalla/pull/364 From yyang at openjdk.java.net Mon Mar 15 02:29:41 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 15 Mar 2021 02:29:41 GMT Subject: [lworld] RFR: 8263566: [lworld] Skip generate_return_value_stubs when InlineTypeReturnedAsFields is disabled Message-ID: This is a trivial change. When InlineTypeReturnedAsFields is turned off, we can skip generating related stub routines, which would reduce C heap occupancy and start VM faster through slightly. Testing: x86: all valhalla related tests with release mode aarch64: none Best regards, Yang ------------- Commit messages: - skip generate_return_value_stubs when InlineTypeReturnedAsFields is Changes: https://git.openjdk.java.net/valhalla/pull/367/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=367&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263566 Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/valhalla/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/367/head:pull/367 PR: https://git.openjdk.java.net/valhalla/pull/367 From yyang at openjdk.java.net Mon Mar 15 02:34:29 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 15 Mar 2021 02:34:29 GMT Subject: [lworld] RFR: 8263568: [lworld] Fix residual reference to 'value' Message-ID: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> javap tool is still outputting primitive type class modifiers as `value` class, it looks like we should tweak this. (Actually, I'm wondering what's the meaning of 'native' for fields that annotated with ACC_PRIMITIVE in flagToModifier? Should we remove it and change the `case 0x100` to `case ACC_PRIMITIVE` so that IDE will help us find all references if we want to do some code refactor in the future?) Thanks, Yang ------------- Commit messages: - fix residual reference to 'value' Changes: https://git.openjdk.java.net/valhalla/pull/368/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=368&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263568 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/368.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/368/head:pull/368 PR: https://git.openjdk.java.net/valhalla/pull/368 From thartmann at openjdk.java.net Mon Mar 15 09:11:19 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 15 Mar 2021 09:11:19 GMT Subject: [lworld] RFR: 8263566: [lworld] Skip generate_return_value_stubs when InlineTypeReturnedAsFields is disabled In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 02:25:48 GMT, Yi Yang wrote: > This is a trivial change. When InlineTypeReturnedAsFields is turned off, we can skip generating related stub routines, which would reduce C heap occupancy and start VM faster through slightly. > > Testing: > x86: all valhalla related tests with release mode > aarch64: none > > Best regards, > Yang Hi Yang, looks good to me, thanks for fixing. Best regards, Tobias ------------- Marked as reviewed by thartmann (Committer). PR: https://git.openjdk.java.net/valhalla/pull/367 From yyang at openjdk.java.net Mon Mar 15 09:28:19 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 15 Mar 2021 09:28:19 GMT Subject: [lworld] RFR: 8263566: [lworld] Skip generate_return_value_stubs when InlineTypeReturnedAsFields is disabled In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 09:08:39 GMT, Tobias Hartmann wrote: >> This is a trivial change. When InlineTypeReturnedAsFields is turned off, we can skip generating related stub routines, which would reduce C heap occupancy and start VM faster through slightly. >> >> Testing: >> x86: all valhalla related tests with release mode >> aarch64: none >> >> Best regards, >> Yang > > Hi Yang, > > looks good to me, thanks for fixing. > > Best regards, > Tobias Thank you Tobias for the review. ------------- PR: https://git.openjdk.java.net/valhalla/pull/367 From ngasson at openjdk.java.net Mon Mar 15 09:35:34 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 15 Mar 2021 09:35:34 GMT Subject: [lworld] RFR: 8258038: [AARCH64] [lworld] Fix inline type implementation Message-ID: This patch updates the original AArch64 lworld port from December 2019 to match the x86 C1/C2/interpreter changes since then. It doesn't support InlineTypePassFieldsAsArgs or InlineTypeReturnedAsFields: this can be added later. Known issues: * compiler/valhalla/inlinetypes/TestLWorld test9 fails with an internal C2 error: # Internal Error (/home/nicgas01/valhalla/src/hotspot/share/opto/buildOopMap.cpp:360), pid=2011, tid=2025 # assert(false) failed: there should be a oop in OopMap instead of a live raw oop at safepoint I haven't investigated this but it doesn't seem to be related to any of the platform specific code. I'll make a separate JBS issue for it. * compiler/valhalla/inlinetypes/TestArrays.java and TestNullableArrays.java fail some sub-tests with: stderr: [OpenJDK 64-Bit Server VM warning: InlineTypePassFieldsAsArgs is not supported on this platform OpenJDK 64-Bit Server VM warning: InlineTypeReturnedAsFields is not supported on this platform Exception in thread "main" java.lang.RuntimeException: Graph for 'TestNullableArrays::test1' contains different number of match nodes (expected 1 but got 0): : expected 1 to equal 0 at jdk.test.lib.Asserts.fail(Asserts.java:594) at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) at jdk.test.lib.Asserts.assertEQ(Asserts.java:178) at compiler.valhalla.inlinetypes.InlineTypeTest.parseOutput(InlineTypeTest.java:600) at compiler.valhalla.inlinetypes.InlineTypeTest.execute_vm(InlineTypeTest.java:482) at compiler.valhalla.inlinetypes.InlineTypeTest.run(InlineTypeTest.java:436) at compiler.valhalla.inlinetypes.TestNullableArrays.main(TestNullableArrays.java:58) ] I think this is related to not implementing passing/returning fields. * compiler/valhalla/inlinetypes/TestBufferTearing.java fails intermittently. I haven't investigated this and will make a separate JBS issue for it. This patch includes two changes that I also submitted to openjdk/jdk: * https://github.com/openjdk/jdk/commit/f7e0a09802f74 * https://github.com/openjdk/jdk/commit/be67aaabe63a ------------- Commit messages: - Updates and cleanup - [WIP] 8258038: [AARCH64] [lworld] Fix inline type implementation Changes: https://git.openjdk.java.net/valhalla/pull/353/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=353&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258038 Stats: 1418 lines in 21 files changed: 820 ins; 270 del; 328 mod Patch: https://git.openjdk.java.net/valhalla/pull/353.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/353/head:pull/353 PR: https://git.openjdk.java.net/valhalla/pull/353 From yyang at openjdk.java.net Mon Mar 15 09:40:18 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 15 Mar 2021 09:40:18 GMT Subject: [lworld] Integrated: 8263566: [lworld] Skip generate_return_value_stubs when InlineTypeReturnedAsFields is disabled In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 02:25:48 GMT, Yi Yang wrote: > This is a trivial change. When InlineTypeReturnedAsFields is turned off, we can skip generating related stub routines, which would reduce C heap occupancy and start VM faster through slightly. > > Testing: > x86: all valhalla related tests with release mode > aarch64: none > > Best regards, > Yang This pull request has now been integrated. Changeset: 683bd428 Author: Yi Yang Committer: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/683bd428 Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod 8263566: [lworld] Skip generate_return_value_stubs when InlineTypeReturnedAsFields is disabled Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/valhalla/pull/367 From vromero at openjdk.java.net Mon Mar 15 13:43:22 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 15 Mar 2021 13:43:22 GMT Subject: RFR: javac support for Parametric VM, first stab [v3] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 22:23:25 GMT, Maurizio Cimadamore wrote: > Looks good to me! thanks! ------------- PR: https://git.openjdk.java.net/valhalla/pull/364 From vromero at openjdk.java.net Mon Mar 15 13:43:23 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 15 Mar 2021 13:43:23 GMT Subject: RFR: javac support for Parametric VM, first stab [v3] In-Reply-To: <05Nk46BWJa45r0-Y2O6mPE1S8FoDPpRgF86ybXPSbIc=.a4772dd7-681c-4b26-baaa-1c60a01b7f2a@github.com> References: <05Nk46BWJa45r0-Y2O6mPE1S8FoDPpRgF86ybXPSbIc=.a4772dd7-681c-4b26-baaa-1c60a01b7f2a@github.com> Message-ID: <6Kkvxem7mkOg3BCgHNWj7SELTXJYmFnMxKsrahoW4EM=.279b6964-481a-4388-926b-dd478a9a143a@github.com> On Fri, 12 Mar 2021 22:28:12 GMT, R?mi Forax wrote: >> That is during class reading - where we don't care about the "id" anymore. The "id" is just a "fiction" when writing, to help us generating multiple CP holes (possibly with the same kind). > > Ok, i did not think about that part of the process, and you do not do any roundtrip, reader - > javac -> gen, > thanks right roundtrips shouldn't happen, this is why we have this duality on the constructors ------------- PR: https://git.openjdk.java.net/valhalla/pull/364 From vromero at openjdk.java.net Mon Mar 15 18:15:33 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 15 Mar 2021 18:15:33 GMT Subject: Integrated: javac support for Parametric VM, first stab In-Reply-To: References: Message-ID: On Sun, 7 Mar 2021 00:30:42 GMT, Vicente Romero wrote: > This patch is the initial support for Parametric VM in javac. This is the first iteration of the prototype, so still a work in progress. In order to test the new code users need to pass the hidden option: `-XDsupportParametricVM` to javac. See the examples below for an illustration of the bytecode the compiler can generate now. Lets assume we have the following class annotated with the `@Parametric` annotation: > > import java.lang.annotation.*; > > @Parametric(id="PAIR") > class Pair { > @Parametric(id="PAIR") > X fst; > @Parametric(id="PAIR") > Y snd; > > Pair(X fst, Y snd) { > this.fst = fst; > this.snd = snd; > } > > Pair swap() { > return new Pair<>(snd, fst); > } > > @Parametric(id="make", kind=ParamKind.METHOD_ONLY) > static Pair make(U fst, W snd) { > return new Pair<>(fst, snd); > } > > @Parametric(id="setFst", kind=ParamKind.METHOD_AND_CLASS) > Pair setFst(Z newFst) { > return null; > } > } > > After compilation this class will contain the following new entries in the constant pool: > > #22 = Parameter CLASS:0 // CLASS:0 > #37 = Parameter METHOD_ONLY:0 // METHOD_ONLY:0 > #44 = Parameter METHOD_AND_CLASS:0 // METHOD_AND_CLASS:0 > also there will be several elements with the new attribute `Parametric` which will appear in both fields, the `Pair` class per-se and methods: `make` and `setFst`. > > Let's now assume we define a Client willing to use class `Pair`, it will need to define values to bound to the "holes" defined in class `Pair` using the `Parametric` annotation. For this class Client should use annotations `@LinkageClass` and or `@LinkageMethod` depending on the kind of hole in class `Pair` it is intending to bound to. Let's define class `Client` as: > > import java.lang.annotation.*; > > class Client { > @LinkageClass("linkageClass") > void linkClassParams() { > Pair psi = new Pair<>("first", 2); > } > > @LinkageClass("linkageClass") > void linkClassParamsFieldAccess(Pair psi) { > psi.fst = "field"; > } > > > @LinkageMethod("linkageMethod1") > void linkMethodParams(Pair psi) { > Pair pair = Pair.make("hello", 1); > } > > @LinkageClass("linkageClass") > @LinkageMethod("linkageMethod2") > void linkClassAndMethodParams(Pair psi) { > Pair pss = psi.setFst("b"); > } > } > > again compiling this class with the hidden option `-XDsupportParametricVM` we can find these new entries in the CP: > > #7 = Linkage #8:#9 // linkageClass:Pair > #8 = String #10 // linkageClass > #9 = Class #11 // Pair > > this Linkage CP entry is referred from method: `linkClassParams` as: > > void linkClassParams(); > descriptor: ()V > flags: (0x0000) > Code: > stack=4, locals=2, args_size=1 > 0: new #7 // Linkage linkageClass:Pair > > also: > > #25 = Linkage #8:#26 // linkageClass:Pair.fst:Ljava/lang/Object; > #26 = Fieldref #7.#27 // Pair.fst:Ljava/lang/Object; > #27 = NameAndType #28:#29 // fst:Ljava/lang/Object; > > referred from method: `linkClassParamsFieldAccess` the bytecode looks like: > > void linkClassParamsFieldAccess(Pair); > descriptor: (LPair;)V > flags: (0x0000) > Code: > stack=2, locals=2, args_size=2 > 0: aload_1 > 1: ldc #23 // String field > 3: putfield #25 // Linkage linkageClass:Pair.fst:Ljava/lang/Object; > 6: return > > also: > > #32 = Linkage #33:#34 // linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; > #33 = String #35 // linkageMethod1 > #34 = Methodref #9.#36 // Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; > > this time referred by method: `linkMethodParams` with bytecode: > > void linkMethodParams(Pair); > descriptor: (LPair;)V > flags: (0x0000) > Code: > stack=2, locals=3, args_size=2 > 0: ldc #30 // String hello > 2: iconst_1 > 3: invokestatic #14 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; > 6: invokestatic #32 // Linkage linkageMethod1:Pair.make:(Ljava/lang/Object;Ljava/lang/Object;)LPair; > 9: astore_2 > 10: return > > and finally: > > #41 = Linkage #42:#43 // linkageMethod2:Pair.setFst:(Ljava/lang/Object;)LPair; > #42 = String #44 // linkageMethod2 > #43 = Methodref #7.#45 // Pair.setFst:(Ljava/lang/Object;)LPair; > > in this last example it can be seen that Methodref at #43 is also pointing to #7 which, as commented above, is another Linkage_info entry in the CP. > > TIA, for the feedback and comments, > Vicente This pull request has now been integrated. Changeset: 0e836e2e Author: Vicente Romero Committer: Maurizio Cimadamore URL: https://git.openjdk.java.net/valhalla/commit/0e836e2e Stats: 767 lines in 24 files changed: 759 ins; 2 del; 6 mod javac support for Parametric VM, first stab Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/valhalla/pull/364 From david.simms at oracle.com Mon Mar 15 18:33:02 2021 From: david.simms at oracle.com (David Simms) Date: Mon, 15 Mar 2021 19:33:02 +0100 Subject: CFV: New Valhalla Committer: Vicente Romero Message-ID: I hereby nominate? Vicente Romero to Valhalla Committer. Vicente is a member of the compiler group and actively working on javac, as well as reviewer for the JDK and Amber projects. Votes are due by 2021-03-29 18:30Z. Only current Valhalla Committers [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. David Simms [1] https://openjdk.java.net/census [2] https://openjdk.java.net/projects/#committer-vote From harold.seigel at oracle.com Mon Mar 15 18:33:44 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 15 Mar 2021 14:33:44 -0400 Subject: CFV: New Valhalla Committer: Vicente Romero In-Reply-To: References: Message-ID: Vote: YES Harold On 3/15/2021 2:33 PM, David Simms wrote: > I hereby nominate? Vicente Romero to Valhalla Committer. > > Vicente is a member of the compiler group and actively working on > javac, as well as reviewer for the JDK and Amber projects. > > Votes are due by 2021-03-29 18:30Z. > > Only current Valhalla Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > David Simms > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > From lois.foltan at oracle.com Mon Mar 15 18:35:01 2021 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 15 Mar 2021 14:35:01 -0400 Subject: CFV: New Valhalla Committer: Vicente Romero In-Reply-To: References: Message-ID: <4abbae47-bb64-ff0d-c5ce-00f3502a54b9@oracle.com> Vote: yes Lois On 3/15/2021 2:33 PM, David Simms wrote: > I hereby nominate? Vicente Romero to Valhalla Committer. > > Vicente is a member of the compiler group and actively working on > javac, as well as reviewer for the JDK and Amber projects. > > Votes are due by 2021-03-29 18:30Z. > > Only current Valhalla Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > David Simms > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > From frederic.parain at oracle.com Mon Mar 15 18:35:40 2021 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 15 Mar 2021 14:35:40 -0400 Subject: CFV: New Valhalla Committer: Vicente Romero In-Reply-To: References: Message-ID: <83418A2A-9F1F-4E0B-88D3-3EF3F38E613A@oracle.com> Vote: yes Fred > On Mar 15, 2021, at 2:33 PM, David Simms wrote: > > I hereby nominate Vicente Romero to Valhalla Committer. > > Vicente is a member of the compiler group and actively working on javac, as well as reviewer for the JDK and Amber projects. > > Votes are due by 2021-03-29 18:30Z. > > Only current Valhalla Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > David Simms > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > From mandy.chung at oracle.com Mon Mar 15 18:40:26 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 15 Mar 2021 11:40:26 -0700 Subject: CFV: New Valhalla Committer: Vicente Romero In-Reply-To: References: Message-ID: Vote: yes Mandy On 3/15/21 11:33 AM, David Simms wrote: > I hereby nominate? Vicente Romero to Valhalla Committer. > > Vicente is a member of the compiler group and actively working on > javac, as well as reviewer for the JDK and Amber projects. > > Votes are due by 2021-03-29 18:30Z. > > Only current Valhalla Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > David Simms > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > From roger.riggs at oracle.com Mon Mar 15 18:51:05 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 15 Mar 2021 14:51:05 -0400 Subject: CFV: New Valhalla Committer: Vicente Romero In-Reply-To: References: Message-ID: Vote: Yes On 3/15/21 2:33 PM, David Simms wrote: > I hereby nominate? Vicente Romero to Valhalla Committer. From maurizio.cimadamore at oracle.com Mon Mar 15 22:06:29 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 15 Mar 2021 22:06:29 +0000 Subject: CFV: New Valhalla Committer: Vicente Romero In-Reply-To: References: Message-ID: <77dc6be9-dc98-092a-a833-d4c6a55a5365@oracle.com> Vote: yes! Maurizio On 15/03/2021 18:33, David Simms wrote: > I hereby nominate? Vicente Romero to Valhalla Committer. > > Vicente is a member of the compiler group and actively working on > javac, as well as reviewer for the JDK and Amber projects. > > Votes are due by 2021-03-29 18:30Z. > > Only current Valhalla Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > David Simms > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > From tobias.hartmann at oracle.com Tue Mar 16 06:59:30 2021 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 16 Mar 2021 07:59:30 +0100 Subject: CFV: New Valhalla Committer: Vicente Romero In-Reply-To: References: Message-ID: Vote: yes Best regards, Tobias On 15.03.21 19:33, David Simms wrote: > I hereby nominate? Vicente Romero to Valhalla Committer. > > Vicente is a member of the compiler group and actively working on javac, as well as reviewer for the > JDK and Amber projects. > > Votes are due by 2021-03-29 18:30Z. > > Only current Valhalla Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > David Simms > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > From chris.hegarty at oracle.com Tue Mar 16 09:23:59 2021 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 16 Mar 2021 09:23:59 +0000 Subject: CFV: New Valhalla Committer: Vicente Romero In-Reply-To: References: Message-ID: <88F763C1-3EAD-4455-92F8-DFCB4C085F29@oracle.com> Vote: Yes -Chris. > On 15 Mar 2021, at 18:33, David Simms wrote: > > I hereby nominate Vicente Romero to Valhalla Committer. From thartmann at openjdk.java.net Wed Mar 17 10:18:02 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 17 Mar 2021 10:18:02 GMT Subject: [lworld] RFR: 8258038: [AARCH64] [lworld] Fix inline type implementation In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 09:53:44 GMT, Nick Gasson wrote: > This patch updates the original AArch64 lworld port from December 2019 to match the x86 C1/C2/interpreter changes since then. It doesn't support InlineTypePassFieldsAsArgs or InlineTypeReturnedAsFields: this can be added later. > > Known issues: > > * compiler/valhalla/inlinetypes/TestLWorld test9 fails with an internal C2 error: > > # Internal Error (/home/nicgas01/valhalla/src/hotspot/share/opto/buildOopMap.cpp:360), pid=2011, tid=2025 > # assert(false) failed: there should be a oop in OopMap instead of a live raw oop at safepoint > > I haven't investigated this but it doesn't seem to be related to any of the platform specific code. I'll make a separate JBS issue for it. > > * compiler/valhalla/inlinetypes/TestArrays.java and TestNullableArrays.java fail some sub-tests with: > > stderr: [OpenJDK 64-Bit Server VM warning: InlineTypePassFieldsAsArgs is not supported on this platform > OpenJDK 64-Bit Server VM warning: InlineTypeReturnedAsFields is not supported on this platform > Exception in thread "main" java.lang.RuntimeException: Graph for 'TestNullableArrays::test1' contains different number of match nodes (expected 1 but got 0): > : expected 1 to equal 0 > at jdk.test.lib.Asserts.fail(Asserts.java:594) > at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) > at jdk.test.lib.Asserts.assertEQ(Asserts.java:178) > at compiler.valhalla.inlinetypes.InlineTypeTest.parseOutput(InlineTypeTest.java:600) > at compiler.valhalla.inlinetypes.InlineTypeTest.execute_vm(InlineTypeTest.java:482) > at compiler.valhalla.inlinetypes.InlineTypeTest.run(InlineTypeTest.java:436) > at compiler.valhalla.inlinetypes.TestNullableArrays.main(TestNullableArrays.java:58) > ] > > I think this is related to not implementing passing/returning fields. > > * compiler/valhalla/inlinetypes/TestBufferTearing.java fails intermittently. I haven't investigated this and will make a separate JBS issue for it. > > This patch includes two changes that I also submitted to openjdk/jdk: > * https://github.com/openjdk/jdk/commit/f7e0a09802f74 > * https://github.com/openjdk/jdk/commit/be67aaabe63a Great work! This looks good to me. ------------- Marked as reviewed by thartmann (Committer). PR: https://git.openjdk.java.net/valhalla/pull/353 From mark.reinhold at oracle.com Wed Mar 17 21:49:43 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 17 Mar 2021 14:49:43 -0700 (PDT) Subject: New candidate JEP: 401: Primitive Objects (Preview) Message-ID: <20210317214943.085423DBBFE@eggemoggin.niobe.net> https://openjdk.java.net/jeps/401 Summary: Enhance the Java object model with user-declared primitive objects, which are class instances that lack object identity and can be stored and passed directly, without object headers or indirections. This is a preview language and VM feature. - Mark From mark.reinhold at oracle.com Wed Mar 17 21:49:45 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 17 Mar 2021 14:49:45 -0700 (PDT) Subject: New candidate JEP: 402: Unify the Basic Primitives with Objects (Preview) Message-ID: <20210317214945.A99CD3DBC00@eggemoggin.niobe.net> https://openjdk.java.net/jeps/402 Summary: Unify the basic primitives (int, double, etc.) with objects by modeling the basic primitive values as instances of primitive classes (introduced by JEP 401) and repurposing the wrapper class declarations to act as the basic primitives' class declarations. As a result of this change, all Java values will be objects. This is a preview language and VM feature. - Mark From scolebourne at joda.org Wed Mar 17 23:48:55 2021 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 17 Mar 2021 23:48:55 +0000 Subject: Questions on default values In-Reply-To: <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> References: <3D227EB1-4D86-4F97-BFCB-A5949C63A717@oracle.com> <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> Message-ID: On Wed, 17 Mar 2021 at 15:15, Brian Goetz wrote: > Let me propose another strategy for Bucket 3. It could be implemented > at either the VM or language level, but the latter probably needs some > help from the VM anyway. The idea is that the default value is > _indistinguishable from null_. Strawman: > > - Classes can be marked as default-hostile (e.g., `primitive class X > implements NoGoodDefault`); > - Prior to dereferencing a default-hostile class, a check is made > against the default value, and an NPE is thrown if it is the default value; > - When widening to a reference type, a check is made if it is the > default value, and if so, is converted to null; > - When narrowing from a reference type, a check is made for null, and > if so, converted to the default value; > - It is allowable to compare `x == null`, which is intepreted as > "widen x to X.ref, and compare"; > - (optional) the interface NoGoodDefault could have a method that > optimizes the check, such as by using a pivot field, or the language/VM > could try to automatically pick a pivot field. Three linked questions: My reading of the above is that a brand new NoGoodDefault (nullable) primitive type `YearWeek(int,int)` would work as follows: YearWeek yw = new YearWeek(2021, 6); YearWeek ywn = null; YearWeek ywd = YearWeek.default; - this code compiles - all three variables are of the same primitive type - `YearWeek` - all three variables are primitives, not references - `ywn` and `ywd` are == and indistinguishable - if these are instance variables then all three are flattened - any method call on `ywn` or `ywd` throws NPE - there is no such thing as `YearWeek.val` (so a developer cannot refer to a non-null YearWeek) Object obj = yw; YearWeek[] arr = new YearWeek[5]; - variable 'obj' is a reference of type `YearWeek.ref` - variable 'arr' is an array of the primitive type `YearWeek` - `arr[0] == YearWeek.default` is true - `arr[0] == null` is true - the elements of the array are flattened into a contiguous piece of memory Is this analysis correct? (If so, then I'm pleased. I wrote some "requirements" in July 2020 exactly along these lines but never sent them to the list) Is the performance of method calls on NoGoodDefault primitives likely to be of the same order of magnitude as calls on references? ie. does the extra null/default checks on a NoGoodDefault primitive type effectively equate to those already done on reference types today? If the analysis is correct is it now the case that there is no need for the "reference-favoring primitive classes" concept. ie. that `java.time.LocalDate` can be migrated to a normal NoGoodDefault fully flattened primitive type? (I sincerely hope so...) thanks Stephen From sirinath1978m at gmail.com Thu Mar 18 01:50:34 2021 From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena) Date: Thu, 18 Mar 2021 07:20:34 +0530 Subject: JEP 401: Primitive Objects (Preview) Message-ID: Hello, Few things to note: - Instead of a class being a primitive or a reference object *at the point of declaration* can it be made such that the object instance is a primitive or a reference object *at the point of instantiation*. So at declaration an object can be used either as a primitive or reference. At instantiation if it is primitive it loses identity. Also it has the ability to have different functionality based on what it is. // Class has different templates class A {} // Common parts class A.val extends A {} // val specific parts class A.ref extends A {} // ref specific parts class B {} // can be used as a ref or val // Method/Constructor has different templates class C { C(...) {} // can be used as a ref or val C.val() {} C.ref() {} void f() {} // can be used as a ref or val void m.val() {} void m.ref() {} void g.ref() {} // Only in refs void h.val() {} // Only in vals } If there reference to the self type it will become ref automatically. - With *arrays *there should be a *choice to make them primitive or reference objects* at *the point of instantiation*. Otherwise accessing an array will always need an indirection. Also cannot be flattened into the object containing the arrays when it makes sense to do so. This provides better - performance and - control over memory layout Better control over memory layout would give dividends for better serialisation, communication and foreign memory access when there are *multiple levels of nested* intertwined objects and arrays with one containing the other. Suminda From asviraspossible at gmail.com Thu Mar 18 11:07:38 2021 From: asviraspossible at gmail.com (Victor Nazarov) Date: Thu, 18 Mar 2021 12:07:38 +0100 Subject: New candidate JEP: 401: Primitive Objects (Preview) In-Reply-To: <20210317214943.085423DBBFE@eggemoggin.niobe.net> References: <20210317214943.085423DBBFE@eggemoggin.niobe.net> Message-ID: Hello, I'd like to comment a little on one aspect that I think hasn't been explored enough for valhalla. There is a proposal to introduce reference-favoring primitive classes. For me it seems that this proposal prefers the state of migration over long-term vision. When reading the proposal I see that in the feature we will get code like: Optional.val findUser(...) with lot's of Optional.val scattered all over the file. It seems to me that there is no way to fix this code in future and the result is that we will get two flavours of the code that uses Optional: * one flavour that is inefficient and uses references * one flavour that is efficient but ugly because of the .val noise I think that the feature should be optimized for new code to be both readable and efficient *without forcing old code to migrate*. There is a quote in a JEP: > Other than the interpretation of the class's name when used as a type, a reference-favoring primitive class is just like any other primitive class. I can propose a solution following the spirit of this comment. If reference-preference is just a namespace problem then we can probably solve it with the namespace management tools. Java uses import statements to manage namespaces (including static-imports). I can propose to introduce value-favoring import, like ```` import java.util.Optional.val; ```` which means that *current compilation unit* treats `Optional` as a name of a value-projection and Optional.ref as a name of a reference-projection. Old code will continue to use ```` import java.util.Optional; ```` which means that it treats `Optional` as a name of a reference-projection and Optional.val as a name of a value-projection. Gradual migration will look like more and more code start to use `import java.util.Optional.val` instead of `import java.util.Optional`, but this is better the scattering `.val` all over the place (the motivation is the same as a motivation for introducing static-imports or importing inner-classes instead of referencing them through the top-level reference). This special import feature can be *explained* referencing existing Java-concepts: Optional.val is like an inner-class of the Optional-class and so we can import it, almost... but not quite. -- Victor Nazarov On Wed, Mar 17, 2021 at 10:50 PM wrote: > https://openjdk.java.net/jeps/401 > > Summary: Enhance the Java object model with user-declared primitive > objects, which are class instances that lack object identity > and can be stored and passed directly, without object headers or > indirections. This is a preview language and VM feature. > > - Mark > From david.lloyd at redhat.com Thu Mar 18 13:32:28 2021 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 18 Mar 2021 08:32:28 -0500 Subject: New candidate JEP: 401: Primitive Objects (Preview) In-Reply-To: <20210317214943.085423DBBFE@eggemoggin.niobe.net> References: <20210317214943.085423DBBFE@eggemoggin.niobe.net> Message-ID: Are we completely sure that having every existing class suddenly implement IdentityObject isn't going to break all kinds of reflection-based frameworks? I'd be very nervous about making a change like that. Reinterpreting calls to `new Object()` seems like trouble to me as well; it'd be downright bizarre to have `new Object().getClass() != Object.class`. Making `Object` be special is just going to make the language that much more awkward overall; I honestly can't imagine the tradeoffs that made this seem like a good idea in comparison. I'm surprised that adding these special cases would be preferable to having primitive types be isolated to their own space (i.e. not extending Object) or other options. For example, by having an isolated root primitive class analog to Object (with a box type extending Object directly), and requiring any base abstract types to extend that class, the existing language behaviors would not have to change AFAICT. Primitive classes would be much easier to recognize. Primitive base classes could even have state. What critical use case did such a design inhibit? Where were such decisions documented? Historically, I personally have failed to understand how these kinds of language-level enhancements balance preserving consistent and simple behavior with enabling specific use cases in certain ways; from the outside it seems very ad-hoc (retroactively updating requirements to adhere to new design ideas). I wish there were some better way to have this be communicated through the life of a project. In the case of valhalla, it seems that new requirements have arisen (and some old requirements have been invalidated) over time/iterations, but unless one follows the project discussion from the absolute beginning and keeps careful notes throughout (and is privy to what appear to be possibly non-public design discussions), apart from occasional big-document drops and actually building prototypes, there really seems to be no way to understand what the total set of requirements of the final iteration actually are, or what design considerations went into it. Is this something that can be improved somehow? It would be nice to see, for exampe, a living document with use cases (including use cases that are later rejected) which map to goals and requirements, that could be updated after each design decision. Even if many of the use cases are along the lines of "we want this user experience" in the form of "here is some syntax we'd like users to be able to use, with justifications", this would be really nice to maintain publicly in a simple living document. It would, for example, provide a nice and simple way for news media to inform users about the project progress. All the better if changes for the document could be managed publicly somehow (GitHub pull requests for example). If nothing else, something like this might help mitigate the inevitably repetitive user-level questions that are associated with substantial changes. At best, it avoids the major change "bomb drop" - which IMO leaves the user base with the impression that they have no choice but to accept these kinds of changes - and gives users more of a reason to look forward to a change, with *more* of a possibility of accurate expectations. I'm not saying *nothing* was done on this effort but the end impression for me is that the process resulting in this design has been substantially more obscure than, say, the process of designing pattern-matching switch statements, which seems much more accessible to users. For such important changes, wouldn't it be good to have a more consistent and public process for communication? On Wed, Mar 17, 2021 at 4:50 PM wrote: > https://openjdk.java.net/jeps/401 > > Summary: Enhance the Java object model with user-declared primitive > objects, which are class instances that lack object identity > and can be stored and passed directly, without object headers or > indirections. This is a preview language and VM feature. > > - Mark > > -- - DML ? he/him From jespersm at openjdk.java.net Fri Mar 19 07:39:30 2021 From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=) Date: Fri, 19 Mar 2021 07:39:30 GMT Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly expression. Message-ID: Make .default a separate node type in the parser. ## Issue [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes. ------------- Commit messages: - Hmm, spaces - Make "PrimitiveParameterizedClass.default" a poly expression. Changes: https://git.openjdk.java.net/valhalla/pull/369/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=369&range=00 Stats: 317 lines in 20 files changed: 274 ins; 31 del; 12 mod Patch: https://git.openjdk.java.net/valhalla/pull/369.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/369/head:pull/369 PR: https://git.openjdk.java.net/valhalla/pull/369 From mcimadamore at openjdk.java.net Fri Mar 19 11:00:02 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 19 Mar 2021 11:00:02 GMT Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly expression. In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 00:01:50 GMT, Jesper Steen M?ller wrote: > Make .default a separate node type in the parser. > > ## Issue > [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation > > Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes. Nice work - it's a very nice cleanup of the code base! I like how the code that was previously scattered in several places now can just move where it belongs. Functionality-wise, I'm not sure this supports poly expressions yet - e.g. I see that you set the polyKind tag correctly, but I'm afraid that this along is not sufficient to support stuff like: List ls = List.default; or: void m(List ls) { ... } m(List.default) I think you might be led to believe that the current impl is doing the right thing - but my feeling is that javac might be tricking you: if the expected type is e.g. `List` but the qualifier of the default expression is `List`, the compiler will check (as per checkId) that List <: List - which is true by subtyping conversion. I don't think there is any inference going on, in other words. You might try debugging and looking at the type of the expression that comes out of checkId. Anyway, even if this works and I did miss something, I don't see how this approach can scale to default expression passed as method arguments - given that in that case there is no `pt()`. To add support for that you need to add another case/node in `ArgumentAttr` (see what's been done for anonymous inner classes - this should be simpler as there's no constructor call). In other words, you want Attr.visitApply to treat your default expression method argument in a special way - by creating what we call a "deferred type" - that is a type that is not fully inferred until _after_ overload resolution (when you DO know the pt()). One possibility would be to push this change as is - as the refactoring part is really good - and maybe issue raw type warning when generic types are involved, or when default expressions are used in method context. And then in another, separate PR we can refine what happens in truly poly cases. ------------- PR: https://git.openjdk.java.net/valhalla/pull/369 From mcimadamore at openjdk.java.net Fri Mar 19 12:28:58 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 19 Mar 2021 12:28:58 GMT Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly expression. In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 10:57:22 GMT, Maurizio Cimadamore wrote: >> Make .default a separate node type in the parser. >> >> ## Issue >> [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation >> >> Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes. > > Nice work - it's a very nice cleanup of the code base! I like how the code that was previously scattered in several places now can just move where it belongs. > > Functionality-wise, I'm not sure this supports poly expressions yet - e.g. I see that you set the polyKind tag correctly, but I'm afraid that this along is not sufficient to support stuff like: > > List ls = List.default; > > or: > > void m(List ls) { ... } > > m(List.default) > > I think you might be led to believe that the current impl is doing the right thing - but my feeling is that javac might be tricking you: if the expected type is e.g. `List` but the qualifier of the default expression is `List`, the compiler will check (as per checkId) that List <: List - which is true by subtyping conversion. I don't think there is any inference going on, in other words. You might try debugging and looking at the type of the expression that comes out of checkId. > > Anyway, even if this works and I did miss something, I don't see how this approach can scale to default expression passed as method arguments - given that in that case there is no `pt()`. To add support for that you need to add another case/node in `ArgumentAttr` (see what's been done for anonymous inner classes - this should be simpler as there's no constructor call). > > In other words, you want Attr.visitApply to treat your default expression method argument in a special way - by creating what we call a "deferred type" - that is a type that is not fully inferred until _after_ overload resolution (when you DO know the pt()). > > One possibility would be to push this change as is - as the refactoring part is really good - and maybe issue raw type warning when generic types are involved, or when default expressions are used in method context. And then in another, separate PR we can refine what happens in truly poly cases. So, I debugged what happens in case where we have `List ls = List.default` What I missed is that we create a variable symbol for `default` which has the right type (from the expected type) - so the expression is correctly typed as `List`. But this seems to happen "just because" the compiler detects that the expected type has same base class as the default expression type. Then, the check performed by `checkId` is always vacuously satisfied, given that we're passing in a synthetic variable whose type is the same as the expected one. Counter example: interface Foo extends List { } ... List ls = Foo.default; // still ok, type is `Foo` This example is more complex, for two reasons: * in this case, Foo is a sub-interface, so the trick of saying "if base class is the same just use the expected type" doesn't work. In fact the compiler types this with `Foo` - which is a raw type * in this particular instance, the code should not even be allowed - because the constraint on the `Foo` type parameter are incompatible with those of the expected type List (X must extend Number). All this stuff needs to work correctly if we want to claim that default expressions are true poly expressions. ------------- PR: https://git.openjdk.java.net/valhalla/pull/369 From brian.goetz at oracle.com Fri Mar 19 14:43:14 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 19 Mar 2021 10:43:14 -0400 Subject: Questions on default values In-Reply-To: References: <3D227EB1-4D86-4F97-BFCB-A5949C63A717@oracle.com> <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> Message-ID: <3f14381c-1df6-9a15-a466-b8d311923af5@oracle.com> Your reading of this sketch of one of the options for a feature we might or might not is mostly correct, but still is missing some subtleties.? Clarifications inline. > Three linked questions: > > My reading of the above is that a brand new NoGoodDefault (nullable) > primitive type `YearWeek(int,int)` would work as follows: > > YearWeek yw = new YearWeek(2021, 6); > YearWeek ywn = null; > YearWeek ywd = YearWeek.default; In some of these there is an implicit conversion; `null` is of type YW.ref (null is always a reference), while YW.default is of type YW.val.? In the second line, there's an implicit conversion from the ref to val type.? Similarly, if you were to compare (null == YW.default), one side would be widened/narrowed to that of the other.? Doesn't matter in which direction, since it interconverts in both directions. Note that this is introducing new complexity into JLS Ch5 (Conversions and Contexts.)? This is not free. > - this code compiles > - all three variables are of the same primitive type - `YearWeek` > - all three variables are primitives, not references > - `ywn` and `ywd` are == and indistinguishable > - if these are instance variables then all three are flattened > - any method call on `ywn` or `ywd` throws NPE These are a correct interpretation of the sketch. > - there is no such thing as `YearWeek.val` (so a developer cannot > refer to a non-null YearWeek) This last one is incorrect.? YW.val is a real type, and all of the above are YW.val.? The only difference here is the interpretation of the zero-bits flat value ("vull").? Vulls would be interpreted as null when converting to YW.ref, rather than an element of the domain, and vice versa. > Object obj = yw; > YearWeek[] arr = new YearWeek[5]; > > - variable 'obj' is a reference of type `YearWeek.ref` Not quite.? (This has nothing to do with NGD.)?? For any primitive class P, there is a universe of instances of P (primitive objects) which have no identity.? The type `P.val` (for which P is usually an alias) is this universe of P instances.? The type `P.ref` is the universe of _references to_ those instances of P, plus null.? But there are *no* instances of P.ref; it's more like an interface. ??? P p = ... ??? Object obj = p what happens here is that we do a primitive widening conversion from P to P.ref (take a reference to the instance), and then do a reference widening from P.ref to Object (subtyping).? If you then ask for `obj.getClass()`, it will say P.? With NGD this doesn't change; it just affects what happens when p is vull. > - variable 'arr' is an array of the primitive type `YearWeek` > - `arr[0] == YearWeek.default` is true > - `arr[0] == null` is true > - the elements of the array are flattened into a contiguous piece of memory Correct. > Is this analysis correct? > (If so, then I'm pleased. I wrote some "requirements" in July 2020 > exactly along these lines but never sent them to the list) The fact that you're pleased is not necessarily encouraging, sad to say; it's evidence for our biggest concern about this approach, which is that it will be an attractive nuisance ("Finally, my nullable value types"), developers will be unaware of the performance tradeoffs they are making, and then conclude "value types suck." The feature here is *not* "nullable value types", as much as some would like that to be the feature!? The feature here is "detection of uninitialized primitives."? It is convenient that the latter travels through null, but null is a means to the end, not the end. > Is the performance of method calls on NoGoodDefault primitives likely > to be of the same order of magnitude as calls on references? ie. does > the extra null/default checks on a NoGoodDefault primitive type > effectively equate to those already done on reference types today? No, and that's the problem.? Every dereference must compare to vull first, and throw on vull.? Comparison to vull is significantly more expensive than comparison to null.? (Further, the VM has many tricks for optimizing null checks that are unlikely to scale to vulls.) You pick up the flattening/density/calling convention/inlining benefits, but you pay a cost every time you access one of its fields or call its methods. There are tricks we can use to reduce the cost of the vull check (e.g., pivot fields, hoisting, vull-tracking), but these come out of the same implementation and complexity budgets that other features come out of, so it's not obvious that this is where we should spend it, especially if people want it to be something it never will be. > If the analysis is correct is it now the case that there is no need > for the "reference-favoring primitive classes" concept. ie. that > `java.time.LocalDate` can be migrated to a normal NoGoodDefault fully > flattened primitive type? Nope, sorry!? The ref-favoring model exists to support _compatible migration_ for classes like Optional (and to a different degree, Integer), which this doesn't give us (and which is far^2 more important.)? If we were going to ditch one in favor of the other, it would be a slam-dunk to say "just use ref-favoring primitives if you want nullability."? Migration compatibility is far more important than filing down this rough edge. From jesper at selskabet.org Fri Mar 19 15:35:27 2021 From: jesper at selskabet.org (=?utf-8?Q?Jesper_Steen_M=C3=B8ller?=) Date: Fri, 19 Mar 2021 16:35:27 +0100 Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly expression. In-Reply-To: References: Message-ID: <0CD15D5B-3B2D-49F2-AA52-1A05F12D7E35@selskabet.org> On 19 Mar 2021, at 13.28, Maurizio Cimadamore wrote: > > On Fri, 19 Mar 2021 10:57:22 GMT, Maurizio Cimadamore > wrote: > >> One possibility would be to push this change as is - as the refactoring part is really good - and maybe issue raw type warning when generic types are involved, or when default expressions are used in method context. And then in another, separate PR we can refine what happens in truly poly cases. > Yes, that might make sense. I?ll split the PR up into the two cases. > So, I debugged what happens in case where we have > > `List ls = List.default` > > What I missed is that we create a variable symbol for `default` which has the right type (from the expected type) - so the expression is correctly typed as `List`. But this seems to happen "just because" the compiler detects that the expected type has same base class as the default expression type. Then, the check performed by `checkId` is always vacuously satisfied, given that we're passing in a synthetic variable whose type is the same as the expected one. > > Counter example: > > interface Foo extends List { } > ... > List ls = Foo.default; // still ok, type is `Foo` > > This example is more complex, for two reasons: > > * in this case, Foo is a sub-interface, so the trick of saying "if base class is the same just use the expected type" doesn't work. In fact the compiler types this with `Foo` - which is a raw type > * in this particular instance, the code should not even be allowed - because the constraint on the `Foo` type parameter are incompatible with those of the expected type List (X must extend Number). > > All this stuff needs to work correctly if we want to claim that default expressions are true poly expressions. > I get it; this needs to be checked before blindly promoting to the expected type. Thank you for the good counter example. As for method overload, I?ve come up with this example, which seems to demonstrate the need for the "full poly treatment" using deferred types. class Whatever { static int foo(Consumer c) { return 1; } static String foo(BiConsumer c) { return "x"; } static primitive class Quux implements Consumer, BiConsumer { public void accept(T t, T u) { } public void accept(Integer t) { } } public static void ambiguous() { var result = foo(Quux.default); // foo here is ambiguous, just like non-primitive new Quux<>() is } } -Jesper From john.r.rose at oracle.com Fri Mar 19 18:57:46 2021 From: john.r.rose at oracle.com (John Rose) Date: Fri, 19 Mar 2021 18:57:46 +0000 Subject: Questions on default values In-Reply-To: <3f14381c-1df6-9a15-a466-b8d311923af5@oracle.com> References: <3D227EB1-4D86-4F97-BFCB-A5949C63A717@oracle.com> <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> <3f14381c-1df6-9a15-a466-b8d311923af5@oracle.com> Message-ID: <67B8DCE1-A166-493D-9934-C9E79BCDF9E8@oracle.com> On Mar 19, 2021, at 7:43 AM, Brian Goetz > wrote: Is this analysis correct? (If so, then I'm pleased. I wrote some "requirements" in July 2020 exactly along these lines but never sent them to the list) The fact that you're pleased is not necessarily encouraging, sad to say; it's evidence for our biggest concern about this approach, which is that it will be an attractive nuisance ("Finally, my nullable value types"), developers will be unaware of the performance tradeoffs they are making, and then conclude "value types suck." The feature here is *not* "nullable value types", as much as some would like that to be the feature! The feature here is "detection of uninitialized primitives." It is convenient that the latter travels through null, but null is a means to the end, not the end. Piling on: The idea of vull/null transcoding is about two years old, and has been discussed at length in Valhalla design meetings, with non-Oracle people present, though (sadly) not minuted externally. I find it a most charming idea. The reason it has not seen more wide distribution is that it has hard-to-control performance implications, as Brian points out. That is true even if you allow a ?pivot field? to improve vull detection. (Both ?vull? and ?pivot field? are terms from the old discussions.) BTW, the problem of inferring pivot fields is all by itself an absorbing one. It requires an analysis akin to safe publication analyses for references. Our plate is very very full just doing the basic features that Valhalla requires to survive at all. Like Stephen, I personally would hope to see the vull/null transcoding idea get some more oxygen in several years, when the basic Valhalla infrastructure is well understood and running nicely. It could very well fail even then as a general purpose feature, due to the overheads Brian mentions, but maybe it will have some viability due to as-yet engineered optimizations. It is *not* a requirement for Valhalla?s viability in the same way that generic support is, and generics surely pose a much more compelling demand for our time and effort. ? John From scolebourne at joda.org Fri Mar 19 23:03:18 2021 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 19 Mar 2021 23:03:18 +0000 Subject: Questions on default values In-Reply-To: <67B8DCE1-A166-493D-9934-C9E79BCDF9E8@oracle.com> References: <3D227EB1-4D86-4F97-BFCB-A5949C63A717@oracle.com> <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> <3f14381c-1df6-9a15-a466-b8d311923af5@oracle.com> <67B8DCE1-A166-493D-9934-C9E79BCDF9E8@oracle.com> Message-ID: On Fri, 19 Mar 2021 at 18:57, John Rose wrote: > On Mar 19, 2021, at 7:43 AM, Brian Goetz wrote: > Is this analysis correct? > (If so, then I'm pleased. I wrote some "requirements" in July 2020 > exactly along these lines but never sent them to the list) > > The fact that you're pleased is not necessarily encouraging, sad to say; it's evidence for our biggest concern about this approach, which is that it will be an attractive nuisance ("Finally, my nullable value types"), developers will be unaware of the performance tradeoffs they are making, and then conclude "value types suck." > > The feature here is *not* "nullable value types", as much as some would like that to be the feature! The feature here is "detection of uninitialized primitives." It is convenient that the latter travels through null, but null is a means to the end, not the end. > > Piling on: The idea of vull/null transcoding is about two years old, > and has been discussed at length in Valhalla design meetings, > with non-Oracle people present, though (sadly) not minuted > externally. I find it a most charming idea. > > The reason it has not seen more wide distribution is that it has > hard-to-control performance implications, as Brian points out. I find the performance issue odd. The comparison I see is a flattened YearWeek with a check on method access vs a cache miss memory hop. My understanding was that the cost of the memory-hop dwarfs the branch. Numeric classes are the ones where absolute performance matters most, and those will usually have a zero default, so again the fear seems over-done. > That is true even if you allow a ?pivot field? to improve vull > detection. I'm no expert, but it would seem even if you chose a simple memory-inefficient approach such as an extra up-front byte to determine nullness it still wouldn't be as wasteful as a reference which wastes 4 or 8 bytes and a memory hop. > It is *not* a requirement I definitely differ here. For me, it is a requirement that classes like YearWeek with no good default are flattened. Otherwise, what is the point of valhalla? And the only good representation of the uninitialized value is null/vull. Not doing something like this will result in libraries chock full of atrocious defaults, which would be an absolutely dreadful outcome. We don't want some poor soul to have to write yet another date and time library, with awful defaults, just to get the benefits of flattening. So, no I don't think that valhalla generics are more important than getting the basic model for NoGoodDefault values right - we can wait for the generics, but we can never fix a broken fundamental core design. > The ref-favoring model exists to support _compatible migration_ for classes like Optional I think you already know that I think LocalDate should simply become flattened when valhalla arrives. I don't think asking developers to write LocalDate.val to get flattening is acceptable. Stephen From brian.goetz at oracle.com Sat Mar 20 01:54:53 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 19 Mar 2021 21:54:53 -0400 Subject: Questions on default values In-Reply-To: References: <3D227EB1-4D86-4F97-BFCB-A5949C63A717@oracle.com> <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> <3f14381c-1df6-9a15-a466-b8d311923af5@oracle.com> <67B8DCE1-A166-493D-9934-C9E79BCDF9E8@oracle.com> Message-ID: > ....broken fundamental core design. There's no call for this sort of hyperbole.? Not helpful. From brian.goetz at oracle.com Sat Mar 20 02:01:24 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 19 Mar 2021 22:01:24 -0400 Subject: New candidate JEP: 401: Primitive Objects (Preview) In-Reply-To: References: <20210317214943.085423DBBFE@eggemoggin.niobe.net> Message-ID: > When reading the proposal I see that in the feature we will get code like: > > Optional.val findUser(...) This is not what we anticipate.? I would expect that for migrated types, public interfaces would continue to use Optional (alias for Optional.ref); we'd mostly only see Optional.val inside of private implementation, where things actually hit the heap.? The primitive widening and reference conversions will make up the difference. From scolebourne at joda.org Sat Mar 20 08:40:00 2021 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 20 Mar 2021 08:40:00 +0000 Subject: New candidate JEP: 401: Primitive Objects (Preview) In-Reply-To: References: <20210317214943.085423DBBFE@eggemoggin.niobe.net> Message-ID: On Sat, 20 Mar 2021 at 02:02, Brian Goetz wrote: > > When reading the proposal I see that in the feature we will get code like: > > > > Optional.val findUser(...) > > This is not what we anticipate. I would expect that for migrated types, > public interfaces would continue to use Optional (alias for > Optional.ref); we'd mostly only see Optional.val inside of private > implementation, where things actually hit the heap. Why do you anticipate that? The messaging I see is: Optional = old, slow, memory-hop Optional.val = new, fast, flattened and as such, I would naturally use Optional.val in the API methods. Stephen From jespersm at openjdk.java.net Sat Mar 20 11:56:08 2021 From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=) Date: Sat, 20 Mar 2021 11:56:08 GMT Subject: [lworld] RFR: 8263900: [lworld] Make .default a separate node type in the parser. Message-ID: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> To prepare for making .default a poly expression and to implement further logic, .default-expressions should be split off as a separate AST node. ------------- Commit messages: - Make .default a separate node type in the parser. Changes: https://git.openjdk.java.net/valhalla/pull/370/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=370&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263900 Stats: 238 lines in 17 files changed: 200 ins; 27 del; 11 mod Patch: https://git.openjdk.java.net/valhalla/pull/370.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/370/head:pull/370 PR: https://git.openjdk.java.net/valhalla/pull/370 From jespersm at openjdk.java.net Sat Mar 20 11:59:52 2021 From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=) Date: Sat, 20 Mar 2021 11:59:52 GMT Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly expression. In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 12:25:36 GMT, Maurizio Cimadamore wrote: >> Nice work - it's a very nice cleanup of the code base! I like how the code that was previously scattered in several places now can just move where it belongs. >> >> Functionality-wise, I'm not sure this supports poly expressions yet - e.g. I see that you set the polyKind tag correctly, but I'm afraid that this along is not sufficient to support stuff like: >> >> List ls = List.default; >> >> or: >> >> void m(List ls) { ... } >> >> m(List.default) >> >> I think you might be led to believe that the current impl is doing the right thing - but my feeling is that javac might be tricking you: if the expected type is e.g. `List` but the qualifier of the default expression is `List`, the compiler will check (as per checkId) that List <: List - which is true by subtyping conversion. I don't think there is any inference going on, in other words. You might try debugging and looking at the type of the expression that comes out of checkId. >> >> Anyway, even if this works and I did miss something, I don't see how this approach can scale to default expression passed as method arguments - given that in that case there is no `pt()`. To add support for that you need to add another case/node in `ArgumentAttr` (see what's been done for anonymous inner classes - this should be simpler as there's no constructor call). >> >> In other words, you want Attr.visitApply to treat your default expression method argument in a special way - by creating what we call a "deferred type" - that is a type that is not fully inferred until _after_ overload resolution (when you DO know the pt()). >> >> One possibility would be to push this change as is - as the refactoring part is really good - and maybe issue raw type warning when generic types are involved, or when default expressions are used in method context. And then in another, separate PR we can refine what happens in truly poly cases. > > So, I debugged what happens in case where we have > > `List ls = List.default` > > What I missed is that we create a variable symbol for `default` which has the right type (from the expected type) - so the expression is correctly typed as `List`. But this seems to happen "just because" the compiler detects that the expected type has same base class as the default expression type. Then, the check performed by `checkId` is always vacuously satisfied, given that we're passing in a synthetic variable whose type is the same as the expected one. > > Counter example: > > interface Foo extends List { } > ... > List ls = Foo.default; // still ok, type is `Foo` > > This example is more complex, for two reasons: > > * in this case, Foo is a sub-interface, so the trick of saying "if base class is the same just use the expected type" doesn't work. In fact the compiler types this with `Foo` - which is a raw type > * in this particular instance, the code should not even be allowed - because the constraint on the `Foo` type parameter are incompatible with those of the expected type List (X must extend Number). > > All this stuff needs to work correctly if we want to claim that default expressions are true poly expressions. @mcimadamore : I've opened https://bugs.openjdk.java.net/browse/JDK-8263900 for the refactoring alone. I'm not totally confident that all the checks in Attr are syntactically possible, and should likely be turned into assertions. So this PR is temporarily on hold, awaiting merge of #370 ------------- PR: https://git.openjdk.java.net/valhalla/pull/369 From brian.goetz at oracle.com Sat Mar 20 13:04:00 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 20 Mar 2021 09:04:00 -0400 Subject: New candidate JEP: 401: Primitive Objects (Preview) In-Reply-To: References: <20210317214943.085423DBBFE@eggemoggin.niobe.net> Message-ID: <5ad289b0-194c-f35c-480a-1c15f2d3660a@oracle.com> > The messaging I see is: > Optional = old, slow, memory-hop > Optional.val = new, fast, flattened This is a somewhat cartoonish simplification of the messaging. Simplifications are great for understanding the broad goals, and as cartoonish simplifications go, it's accurate enough, but we should be aware of when those simplifications start to get in the way. Migration is a a more advanced use case, and requires a more refined perspective, because you're trading off more things and making finer sub-distinctions within the cost model. This illustrates one of the hazards of our approach; to justify such a big change to the platform, we have to at least have a credible story to fill in all the corner cases, but what then invariably happens is that minority features invariably command much more attention than they should.? (This is in part because, if you've not spent thousands of hours swimming in this, it's not yet obvious what is tail and what is dog, and also, the tail is usually where the ugliest syntax lies, which invariably attracts our attention.) >? and as such, I would naturally use Optional.val in the API methods. I think you need to consider that your intuitions of what you would "naturally" do are not yet informed by any actual experience with this programming model, and perhaps you should ascribe a little less confidence to what you would "naturally" do when confronted with a more subtle challenge like this. More inquiry, less certainty. On 3/20/2021 4:40 AM, Stephen Colebourne wrote: > On Sat, 20 Mar 2021 at 02:02, Brian Goetz wrote: >>> When reading the proposal I see that in the feature we will get code like: >>> >>> Optional.val findUser(...) >> This is not what we anticipate. I would expect that for migrated types, >> public interfaces would continue to use Optional (alias for >> Optional.ref); we'd mostly only see Optional.val inside of private >> implementation, where things actually hit the heap. > Why do you anticipate that? > > The messaging I see is: > Optional = old, slow, memory-hop > Optional.val = new, fast, flattened > and as such, I would naturally use Optional.val in the API methods. > > Stephen From sadayapalam at openjdk.java.net Mon Mar 22 10:39:55 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Mon, 22 Mar 2021 10:39:55 GMT Subject: [lworld] RFR: 8263568: [lworld] Fix residual reference to 'value' In-Reply-To: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> References: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> Message-ID: On Mon, 15 Mar 2021 02:29:48 GMT, Yi Yang wrote: > javap tool is still outputting primitive type class modifiers as `value` class, it looks like we should tweak this. > > (Actually, I'm wondering what's the meaning of 'native' for fields that annotated with ACC_PRIMITIVE in flagToModifier? Should we remove it and change the `case 0x100` to `case ACC_PRIMITIVE` so that IDE will help us find all references if we want to do some code refactor in the future?) > > > Thanks, > Yang Thanks for the patch, I will review it tomorrow and help take it forward ------------- PR: https://git.openjdk.java.net/valhalla/pull/368 From sadayapalam at openjdk.java.net Mon Mar 22 12:04:52 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Mon, 22 Mar 2021 12:04:52 GMT Subject: [lworld] RFR: 8263900: [lworld] Make .default a separate node type in the parser. In-Reply-To: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> References: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> Message-ID: On Sat, 20 Mar 2021 11:36:44 GMT, Jesper Steen M?ller wrote: > To prepare for making .default a poly expression and to implement further logic, .default-expressions should be split off as a separate AST node. Thanks Jesper, I will review this one and help you take it forward. ------------- PR: https://git.openjdk.java.net/valhalla/pull/370 From rriggs at openjdk.java.net Mon Mar 22 13:21:52 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 22 Mar 2021 13:21:52 GMT Subject: [lworld] RFR: 8263568: [lworld] Fix residual reference to 'value' In-Reply-To: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> References: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> Message-ID: On Mon, 15 Mar 2021 02:29:48 GMT, Yi Yang wrote: > javap tool is still outputting primitive type class modifiers as `value` class, it looks like we should tweak this. > > (Actually, I'm wondering what's the meaning of 'native' for fields that annotated with ACC_PRIMITIVE in flagToModifier? Should we remove it and change the `case 0x100` to `case ACC_PRIMITIVE` so that IDE will help us find all references if we want to do some code refactor in the future?) > > > Thanks, > Yang Thanks for fixing the oversight. ------------- Marked as reviewed by rriggs (Committer). PR: https://git.openjdk.java.net/valhalla/pull/368 From ngasson at openjdk.java.net Tue Mar 23 04:13:59 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 23 Mar 2021 04:13:59 GMT Subject: [lworld] RFR: 8258038: [AARCH64] [lworld] Fix inline type implementation In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 10:14:52 GMT, Tobias Hartmann wrote: >> This patch updates the original AArch64 lworld port from December 2019 to match the x86 C1/C2/interpreter changes since then. It doesn't support InlineTypePassFieldsAsArgs or InlineTypeReturnedAsFields: this can be added later. >> >> Known issues: >> >> * compiler/valhalla/inlinetypes/TestLWorld test9 fails with an internal C2 error: >> >> # Internal Error (/home/nicgas01/valhalla/src/hotspot/share/opto/buildOopMap.cpp:360), pid=2011, tid=2025 >> # assert(false) failed: there should be a oop in OopMap instead of a live raw oop at safepoint >> >> I haven't investigated this but it doesn't seem to be related to any of the platform specific code. I'll make a separate JBS issue for it. >> >> * compiler/valhalla/inlinetypes/TestArrays.java and TestNullableArrays.java fail some sub-tests with: >> >> stderr: [OpenJDK 64-Bit Server VM warning: InlineTypePassFieldsAsArgs is not supported on this platform >> OpenJDK 64-Bit Server VM warning: InlineTypeReturnedAsFields is not supported on this platform >> Exception in thread "main" java.lang.RuntimeException: Graph for 'TestNullableArrays::test1' contains different number of match nodes (expected 1 but got 0): >> : expected 1 to equal 0 >> at jdk.test.lib.Asserts.fail(Asserts.java:594) >> at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >> at jdk.test.lib.Asserts.assertEQ(Asserts.java:178) >> at compiler.valhalla.inlinetypes.InlineTypeTest.parseOutput(InlineTypeTest.java:600) >> at compiler.valhalla.inlinetypes.InlineTypeTest.execute_vm(InlineTypeTest.java:482) >> at compiler.valhalla.inlinetypes.InlineTypeTest.run(InlineTypeTest.java:436) >> at compiler.valhalla.inlinetypes.TestNullableArrays.main(TestNullableArrays.java:58) >> ] >> >> I think this is related to not implementing passing/returning fields. >> >> * compiler/valhalla/inlinetypes/TestBufferTearing.java fails intermittently. I haven't investigated this and will make a separate JBS issue for it. >> >> This patch includes two changes that I also submitted to openjdk/jdk: >> * https://github.com/openjdk/jdk/commit/f7e0a09802f74 >> * https://github.com/openjdk/jdk/commit/be67aaabe63a > > Great work! This looks good to me. Thanks for the review @TobiHartmann. Would you mind sponsoring this as I'm not a valhalla committer? ------------- PR: https://git.openjdk.java.net/valhalla/pull/353 From sadayapalam at openjdk.java.net Tue Mar 23 08:05:57 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Tue, 23 Mar 2021 08:05:57 GMT Subject: [lworld] RFR: 8263568: [lworld] Fix residual reference to 'value' In-Reply-To: References: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> Message-ID: <2FNc0yVROFiPPdWNAgs7H3E7cCSzOM9coy4e6xXi6PU=.50a374a6-8a82-400f-83e1-2ff3491a6633@github.com> On Mon, 22 Mar 2021 13:18:44 GMT, Roger Riggs wrote: >> javap tool is still outputting primitive type class modifiers as `value` class, it looks like we should tweak this. >> >> (Actually, I'm wondering what's the meaning of 'native' for fields that annotated with ACC_PRIMITIVE in flagToModifier? Should we remove it and change the `case 0x100` to `case ACC_PRIMITIVE` so that IDE will help us find all references if we want to do some code refactor in the future?) >> >> >> Thanks, >> Yang > > Thanks for fixing the oversight. A clarification on the Access flag encoding value 0x100: On jdk mainline 0x100 is ACC_NATIVE used to flag native *methods*. (does not apply to or make sense for fields) On Valhalla, this flag is overloaded to mean ACC_PRIMITIVE for classes and till https://bugs.openjdk.java.net/browse/JDK-8212792 pulled the plug was also overloaded for ACC_FLATTENABLE to flag fields that carried the flattenability hint. Post https://bugs.openjdk.java.net/browse/JDK-8212792, ACC_FLATTENABLE is gone and we have only two overloads ACC_NATIVE and ACC_PRIMITIVE. So the proposed patch looks good, but the 0x100 cannot be replaced with ACC_PRIMITIVE without some loss of readability. ------------- PR: https://git.openjdk.java.net/valhalla/pull/368 From sadayapalam at openjdk.java.net Tue Mar 23 08:33:59 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Tue, 23 Mar 2021 08:33:59 GMT Subject: [lworld] RFR: 8263568: [lworld] Fix residual reference to 'value' In-Reply-To: <2FNc0yVROFiPPdWNAgs7H3E7cCSzOM9coy4e6xXi6PU=.50a374a6-8a82-400f-83e1-2ff3491a6633@github.com> References: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> <2FNc0yVROFiPPdWNAgs7H3E7cCSzOM9coy4e6xXi6PU=.50a374a6-8a82-400f-83e1-2ff3491a6633@github.com> Message-ID: On Tue, 23 Mar 2021 08:02:51 GMT, Srikanth Adayapalam wrote: >> Thanks for fixing the oversight. > > A clarification on the Access flag encoding value 0x100: > > On jdk mainline 0x100 is ACC_NATIVE used to flag native *methods*. (does not apply to or make sense for fields) > > On Valhalla, this flag is overloaded to mean ACC_PRIMITIVE for classes and till https://bugs.openjdk.java.net/browse/JDK-8212792 pulled the plug was also overloaded for ACC_FLATTENABLE to flag fields that carried the flattenability hint. > > Post https://bugs.openjdk.java.net/browse/JDK-8212792, ACC_FLATTENABLE is gone and we have only two overloads > ACC_NATIVE and ACC_PRIMITIVE. > > So the proposed patch looks good, but the 0x100 cannot be replaced with ACC_PRIMITIVE without some loss of readability. (There is some loss of readability already - we should add a comment next to the case 0x100: to call out the variants. That is better than inventing a name like ACC_NATIVE_OR_PRIMITIVE - I will follow up on that) ------------- PR: https://git.openjdk.java.net/valhalla/pull/368 From thartmann at openjdk.java.net Tue Mar 23 09:23:56 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 23 Mar 2021 09:23:56 GMT Subject: [lworld] RFR: 8258038: [AARCH64] [lworld] Fix inline type implementation In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 04:11:21 GMT, Nick Gasson wrote: >> Great work! This looks good to me. > > Thanks for the review @TobiHartmann. Would you mind sponsoring this as I'm not a valhalla committer? Sure! ------------- PR: https://git.openjdk.java.net/valhalla/pull/353 From ngasson at openjdk.java.net Tue Mar 23 09:23:57 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 23 Mar 2021 09:23:57 GMT Subject: [lworld] Integrated: 8258038: [AARCH64] [lworld] Fix inline type implementation In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 09:53:44 GMT, Nick Gasson wrote: > This patch updates the original AArch64 lworld port from December 2019 to match the x86 C1/C2/interpreter changes since then. It doesn't support InlineTypePassFieldsAsArgs or InlineTypeReturnedAsFields: this can be added later. > > Known issues: > > * compiler/valhalla/inlinetypes/TestLWorld test9 fails with an internal C2 error: > > # Internal Error (/home/nicgas01/valhalla/src/hotspot/share/opto/buildOopMap.cpp:360), pid=2011, tid=2025 > # assert(false) failed: there should be a oop in OopMap instead of a live raw oop at safepoint > > I haven't investigated this but it doesn't seem to be related to any of the platform specific code. I'll make a separate JBS issue for it. > > * compiler/valhalla/inlinetypes/TestArrays.java and TestNullableArrays.java fail some sub-tests with: > > stderr: [OpenJDK 64-Bit Server VM warning: InlineTypePassFieldsAsArgs is not supported on this platform > OpenJDK 64-Bit Server VM warning: InlineTypeReturnedAsFields is not supported on this platform > Exception in thread "main" java.lang.RuntimeException: Graph for 'TestNullableArrays::test1' contains different number of match nodes (expected 1 but got 0): > : expected 1 to equal 0 > at jdk.test.lib.Asserts.fail(Asserts.java:594) > at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) > at jdk.test.lib.Asserts.assertEQ(Asserts.java:178) > at compiler.valhalla.inlinetypes.InlineTypeTest.parseOutput(InlineTypeTest.java:600) > at compiler.valhalla.inlinetypes.InlineTypeTest.execute_vm(InlineTypeTest.java:482) > at compiler.valhalla.inlinetypes.InlineTypeTest.run(InlineTypeTest.java:436) > at compiler.valhalla.inlinetypes.TestNullableArrays.main(TestNullableArrays.java:58) > ] > > I think this is related to not implementing passing/returning fields. > > * compiler/valhalla/inlinetypes/TestBufferTearing.java fails intermittently. I haven't investigated this and will make a separate JBS issue for it. > > This patch includes two changes that I also submitted to openjdk/jdk: > * https://github.com/openjdk/jdk/commit/f7e0a09802f74 > * https://github.com/openjdk/jdk/commit/be67aaabe63a This pull request has now been integrated. Changeset: ff70e7d8 Author: Nick Gasson Committer: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/ff70e7d8 Stats: 1418 lines in 21 files changed: 820 ins; 270 del; 328 mod 8258038: [AARCH64] [lworld] Fix inline type implementation Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/valhalla/pull/353 From sadayapalam at openjdk.java.net Tue Mar 23 10:01:52 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Tue, 23 Mar 2021 10:01:52 GMT Subject: [lworld] RFR: 8263568: [lworld] Fix residual reference to 'value' In-Reply-To: References: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> <2FNc0yVROFiPPdWNAgs7H3E7cCSzOM9coy4e6xXi6PU=.50a374a6-8a82-400f-83e1-2ff3491a6633@github.com> Message-ID: On Tue, 23 Mar 2021 08:31:16 GMT, Srikanth Adayapalam wrote: >> A clarification on the Access flag encoding value 0x100: >> >> On jdk mainline 0x100 is ACC_NATIVE used to flag native *methods*. (does not apply to or make sense for fields) >> >> On Valhalla, this flag is overloaded to mean ACC_PRIMITIVE for classes and till https://bugs.openjdk.java.net/browse/JDK-8212792 pulled the plug was also overloaded for ACC_FLATTENABLE to flag fields that carried the flattenability hint. >> >> Post https://bugs.openjdk.java.net/browse/JDK-8212792, ACC_FLATTENABLE is gone and we have only two overloads >> ACC_NATIVE and ACC_PRIMITIVE. >> >> So the proposed patch looks good, but the 0x100 cannot be replaced with ACC_PRIMITIVE without some loss of readability. > > (There is some loss of readability already - we should add a comment next to the case 0x100: to call out the variants. That is better than inventing a name like ACC_NATIVE_OR_PRIMITIVE - I will follow up on that) Hello! Can you please make these two changes ? (1) This patch is "failing" one langtools test - test/langtools/tools/javac/valhalla/lworld-values/QTypeTest.java The fix is simple, to replace value with primitive in the javap output verified by that test (2) Could you add a comment next to the case 0x100: // ACC_NATIVE or ACC_PRIMITIVE Thanks! ------------- PR: https://git.openjdk.java.net/valhalla/pull/368 From sadayapalam at openjdk.java.net Tue Mar 23 10:50:55 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Tue, 23 Mar 2021 10:50:55 GMT Subject: [lworld] RFR: 8263900: [lworld] Make .default a separate node type in the parser. In-Reply-To: References: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> Message-ID: On Mon, 22 Mar 2021 12:02:12 GMT, Srikanth Adayapalam wrote: >> To prepare for making .default a poly expression and to implement further logic, .default-expressions should be split off as a separate AST node. > > Thanks Jesper, I will review this one and help you take it forward. I have made one high level pass over the changes, more verifying on the boiler plate parts. Need to delve deeper in Attr, Gen, Parser, TransValues, will do this tomorrow. Here are some comments so far: (1) Is DefaultExpression better named as DefaultInstance or DefaultValue ?? (2) Should com.sun.tools.javac.tree.JCTree.JCDefaultExpression#getClazz - for consistency sake return JCExpression ?? (compare similar cases in JCTree) (3) Do we need a visitor in SourceComputer in CRTable.java ?? ------------- PR: https://git.openjdk.java.net/valhalla/pull/370 From yyang at openjdk.java.net Tue Mar 23 11:21:12 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 23 Mar 2021 11:21:12 GMT Subject: [lworld] RFR: 8263568: [lworld] Fix residual reference to 'value' [v2] In-Reply-To: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> References: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> Message-ID: > javap tool is still outputting primitive type class modifiers as `value` class, it looks like we should tweak this. > > (Actually, I'm wondering what's the meaning of 'native' for fields that annotated with ACC_PRIMITIVE in flagToModifier? Should we remove it and change the `case 0x100` to `case ACC_PRIMITIVE` so that IDE will help us find all references if we want to do some code refactor in the future?) > > > Thanks, > Yang Yi Yang has updated the pull request incrementally with one additional commit since the last revision: fix test; add more comment ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/368/files - new: https://git.openjdk.java.net/valhalla/pull/368/files/5640dc86..a20c7458 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=368&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=368&range=00-01 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/368.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/368/head:pull/368 PR: https://git.openjdk.java.net/valhalla/pull/368 From yyang at openjdk.java.net Tue Mar 23 11:21:12 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 23 Mar 2021 11:21:12 GMT Subject: [lworld] RFR: 8263568: [lworld] Fix residual reference to 'value' [v2] In-Reply-To: References: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> <2FNc0yVROFiPPdWNAgs7H3E7cCSzOM9coy4e6xXi6PU=.50a374a6-8a82-400f-83e1-2ff3491a6633@github.com> Message-ID: On Tue, 23 Mar 2021 09:58:38 GMT, Srikanth Adayapalam wrote: > Hello! > > Can you please make these two changes ? > > (1) This patch is "failing" one langtools test - test/langtools/tools/javac/valhalla/lworld-values/QTypeTest.java > The fix is simple, to replace value with primitive in the javap output verified by that test > > (2) Could you add a comment next to the case 0x100: // ACC_NATIVE or ACC_PRIMITIVE > > Thanks! I've changed the test case and add this comment. Thanks~ Yang ------------- PR: https://git.openjdk.java.net/valhalla/pull/368 From nlisker at gmail.com Tue Mar 23 18:18:09 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 23 Mar 2021 20:18:09 +0200 Subject: Memory consumption of anonymous classes vs. concrete subclass Message-ID: Hi, In JavaFX we have classes of the form abstract class SomeObjectProperty { abstract String getName(); abstract Object getBean(); } And a concrete class SimpleSomeObjectProperty extends SomeObjectProperty { String name; Object bean; SimpleSomeObjectProperty(String name, Object bean) { this.name = name; this.bean = bean; } @Override abstract String getName() { return name; } @Override abstract Object getBean() { return bean; } } When we want to use a SomeObjectProperty, we usually use an anonymous subclass: SomeObjectProperty prop = new SomeObjectProperty() { @Override public Object getBean() { return ThisClass.this; } @Override public String getName() { return "prop "; } } The reason being memory consumption. The anonymous class takes less memory because it holds less references. The amount varies depending on the number of fields and their getters (in this case we had 2, but it could be more), but we have done tests that show the memory footprint difference. However, this is much less readable obviously and much longer. Since JavaFX uses these properties extensively, the memory issue is significant and the readability issue is prominent. I want the best of both worlds - more readable with less memory. I would think that under the hood something could be done to optimize this code since effectively it does the same. Is it possible to do something about this? - Nir From david.holmes at oracle.com Wed Mar 24 04:00:08 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Mar 2021 14:00:08 +1000 Subject: Memory consumption of anonymous classes vs. concrete subclass In-Reply-To: References: Message-ID: <23b9cdc5-10c9-e0eb-521e-6dac34d49f4f@oracle.com> Hi Nir, On 24/03/2021 4:18 am, Nir Lisker wrote: > Hi, > > In JavaFX we have classes of the form > > abstract class SomeObjectProperty { > > abstract String getName(); > abstract Object getBean(); > } > > And a concrete > > class SimpleSomeObjectProperty extends SomeObjectProperty { > > String name; > Object bean; > > SimpleSomeObjectProperty(String name, Object bean) { > this.name = name; > this.bean = bean; > } > > @Override > abstract String getName() { return name; } > > @Override > abstract Object getBean() { return bean; } > } > > When we want to use a SomeObjectProperty, we usually use an > anonymous subclass: > > SomeObjectProperty prop = new SomeObjectProperty() { > > @Override > public Object getBean() { > return ThisClass.this; What role does ThisClass play here? > } > > @Override > public String getName() { > return "prop "; > } > } > > The reason being memory consumption. The anonymous class takes less memory > because it holds less references. The amount varies depending on the number > of fields and their getters (in this case we had 2, but it could be more), > but we have done tests that show the memory footprint difference. However, > this is much less readable obviously and much longer. > Since JavaFX uses these properties extensively, the memory issue is > significant and the readability issue is prominent. > > I want the best of both worlds - more readable with less memory. I would > think that under the hood something could be done to optimize this code > since effectively it does the same. Is it possible to do something about > this? But the code is not effectively the same. The concrete class is a general class that can be instantiated multiple times for different beans and names - hence the fields are needed to store them. The anonymous class is for a singleton instance hard-wired to return one bean and one name. You could define a named class, specific to a given property, with no fields and which was also hard-wired the same way. Cheers, David > - Nir > From sadayapalam at openjdk.java.net Wed Mar 24 06:18:55 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 24 Mar 2021 06:18:55 GMT Subject: [lworld] RFR: 8263568: [lworld] Fix residual reference to 'value' [v2] In-Reply-To: References: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> Message-ID: <_e6SGeylIkivz7TLY24aZeBrEeGC92DzG-UoDYIQy7o=.fc3c669e-91ca-481a-af76-095e01aadcb2@github.com> On Tue, 23 Mar 2021 11:21:12 GMT, Yi Yang wrote: >> javap tool is still outputting primitive type class modifiers as `value` class, it looks like we should tweak this. >> >> (Actually, I'm wondering what's the meaning of 'native' for fields that annotated with ACC_PRIMITIVE in flagToModifier? Should we remove it and change the `case 0x100` to `case ACC_PRIMITIVE` so that IDE will help us find all references if we want to do some code refactor in the future?) >> >> >> Thanks, >> Yang > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > fix test; add more comment Changes look good. Thanks! ------------- Marked as reviewed by sadayapalam (Committer). PR: https://git.openjdk.java.net/valhalla/pull/368 From sadayapalam at openjdk.java.net Wed Mar 24 06:21:57 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 24 Mar 2021 06:21:57 GMT Subject: [lworld] RFR: 8263568: [lworld] Fix residual reference to 'value' [v2] In-Reply-To: <_e6SGeylIkivz7TLY24aZeBrEeGC92DzG-UoDYIQy7o=.fc3c669e-91ca-481a-af76-095e01aadcb2@github.com> References: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> <_e6SGeylIkivz7TLY24aZeBrEeGC92DzG-UoDYIQy7o=.fc3c669e-91ca-481a-af76-095e01aadcb2@github.com> Message-ID: On Wed, 24 Mar 2021 06:16:16 GMT, Srikanth Adayapalam wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix test; add more comment > > Changes look good. Thanks! Hello Yang, I think the process is for you to issue an integrate command followed by a sponsor command by me. Thanks for looking into this. ------------- PR: https://git.openjdk.java.net/valhalla/pull/368 From yyang at openjdk.java.net Wed Mar 24 06:38:55 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 24 Mar 2021 06:38:55 GMT Subject: [lworld] RFR: 8263568: [lworld] Fix residual reference to 'value' [v2] In-Reply-To: References: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> Message-ID: On Mon, 22 Mar 2021 13:18:44 GMT, Roger Riggs wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix test; add more comment > > Thanks for fixing the oversight. Sure, thanks @RogerRiggs @sadayapalam for the review! ------------- PR: https://git.openjdk.java.net/valhalla/pull/368 From yyang at openjdk.java.net Wed Mar 24 07:05:00 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 24 Mar 2021 07:05:00 GMT Subject: [lworld] Integrated: 8263568: [lworld] Fix residual reference to 'value' In-Reply-To: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> References: <3JNQcWnS7DIbRNWcM0cjKG0SeAlxboiAOnpFK96Iy7Y=.4a19fb9f-fc4d-4f09-b65c-4fe8e49321e3@github.com> Message-ID: <_4CzozjR7AgBLhjGu1HKFRXWE1M7ZMP151txvJckVnQ=.529760aa-01b8-41d3-bf2c-d004b89c7936@github.com> On Mon, 15 Mar 2021 02:29:48 GMT, Yi Yang wrote: > javap tool is still outputting primitive type class modifiers as `value` class, it looks like we should tweak this. > > (Actually, I'm wondering what's the meaning of 'native' for fields that annotated with ACC_PRIMITIVE in flagToModifier? Should we remove it and change the `case 0x100` to `case ACC_PRIMITIVE` so that IDE will help us find all references if we want to do some code refactor in the future?) > > > Thanks, > Yang This pull request has now been integrated. Changeset: 94c281e2 Author: Yi Yang Committer: Srikanth Adayapalam URL: https://git.openjdk.java.net/valhalla/commit/94c281e2 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod 8263568: [lworld] Fix residual reference to 'value' Reviewed-by: rriggs, sadayapalam ------------- PR: https://git.openjdk.java.net/valhalla/pull/368 From sadayapalam at openjdk.java.net Wed Mar 24 10:30:57 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 24 Mar 2021 10:30:57 GMT Subject: [lworld] RFR: 8263900: [lworld] Make .default a separate node type in the parser. In-Reply-To: References: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> Message-ID: On Tue, 23 Mar 2021 10:47:34 GMT, Srikanth Adayapalam wrote: >> Thanks Jesper, I will review this one and help you take it forward. > > I have made one high level pass over the changes, more verifying on the boiler plate parts. Need to delve deeper in Attr, Gen, Parser, TransValues, will do this tomorrow. > > Here are some comments so far: > > (1) Is DefaultExpression better named as DefaultInstance or DefaultValue ?? > (2) Should com.sun.tools.javac.tree.JCTree.JCDefaultExpression#getClazz - for consistency sake return JCExpression ?? > (compare similar cases in JCTree) > (3) Do we need a visitor in SourceComputer in CRTable.java ?? Here are cumulative comments: (1) Is DefaultExpression better named as DefaultInstance or even better DefaultValue ?? (2) Should com.sun.tools.javac.tree.JCTree.JCDefaultExpression#getClazz - for consistency sake return JCExpression ?? (compare similar cases in JCTree) (3) Should JCDefaultExpression#getClazz be named getType() a la JCTypeCast, JCNewArray, JCVariableDecl, JCInstanceof ... (4) Do we need a visitor in SourceComputer in CRTable.java ?? (5) Attr.java:4464: reference to .default needs to be removed from comment (6) Attr.visitDefaultExpression: sitesym seems to be unused variable declaration. (7) This program: primitive class X { Object o2 = java.util.default; } generates this strange error: error: package java does not exist Object o2 = java.util.default; ^ 1 error (That it emits the same message without the patch notwithstanding) I think we should attribute the clazz as a TYP_PCK and for package case emit an error. (8) com.sun.source.util.TreeScanner#visitDefaultExpression: Eliminate the local and directly return ? Let me know if you have any questions/clarifications. Thanks for your effort, this looks very promising prework for the poly expr typing task ------------- PR: https://git.openjdk.java.net/valhalla/pull/370 From jespersm at openjdk.java.net Wed Mar 24 19:56:03 2021 From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=) Date: Wed, 24 Mar 2021 19:56:03 GMT Subject: [lworld] RFR: 8263900: [lworld] Make .default a separate node type in the parser. In-Reply-To: References: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> Message-ID: On Wed, 24 Mar 2021 10:28:28 GMT, Srikanth Adayapalam wrote: >> I have made one high level pass over the changes, more verifying on the boiler plate parts. Need to delve deeper in Attr, Gen, Parser, TransValues, will do this tomorrow. >> >> Here are some comments so far: >> >> (1) Is DefaultExpression better named as DefaultInstance or DefaultValue ?? >> (2) Should com.sun.tools.javac.tree.JCTree.JCDefaultExpression#getClazz - for consistency sake return JCExpression ?? >> (compare similar cases in JCTree) >> (3) Do we need a visitor in SourceComputer in CRTable.java ?? > > Here are cumulative comments: > > (1) Is DefaultExpression better named as DefaultInstance or even better DefaultValue ?? > (2) Should com.sun.tools.javac.tree.JCTree.JCDefaultExpression#getClazz - for consistency sake return JCExpression ?? > (compare similar cases in JCTree) > (3) Should JCDefaultExpression#getClazz be named getType() a la JCTypeCast, JCNewArray, JCVariableDecl, JCInstanceof ... > (4) Do we need a visitor in SourceComputer in CRTable.java ?? > (5) Attr.java:4464: reference to .default needs to be removed from comment > (6) Attr.visitDefaultExpression: sitesym seems to be unused variable declaration. > (7) This program: > primitive class X { > Object o2 = java.util.default; > } > > generates this strange error: > error: package java does not exist > Object o2 = java.util.default; > ^ > 1 error > (That it emits the same message without the patch notwithstanding) > > I think we should attribute the clazz as a TYP_PCK and for package case emit an error. > (8) com.sun.source.util.TreeScanner#visitDefaultExpression: Eliminate the local and directly return ? > > Let me know if you have any questions/clarifications. > > Thanks for your effort, this looks very promising prework for the poly expr typing task Regarding (7), I hit that earlier as well - but it is a entirely seperate bug, also available in the released product: % javac -version javac 16 % cat X.java public class X { void x() { Class c = java.lang.class; } } % javac X.java X.java:3: error: package java does not exist Class c = java.lang.class; ^ 1 error I get the same confusing error with e.g. "new java.lang()" This bug goes back to at least Java 11, but Java 8 u232 appears to get it right, explaining that there's no java.lang class. I'm guessing it may have come in with Jigsaw. While I might be able to fix this locally, I think it should really be addressed in the main repo first. I tried finding the bug for it, but didn't find it -- would you like me to report it? ------------- PR: https://git.openjdk.java.net/valhalla/pull/370 From jespersm at openjdk.java.net Wed Mar 24 20:46:40 2021 From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=) Date: Wed, 24 Mar 2021 20:46:40 GMT Subject: [lworld] RFR: 8263900: [lworld] Make .default a separate node type in the parser. [v2] In-Reply-To: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> References: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> Message-ID: <_Mw05pEvU0ix9XUBfCzIRddDobeZw_xAa4hyOcdvxjs=.6485feca-b26d-4b12-bb06-3285df51b0a3@github.com> > To prepare for making .default a poly expression and to implement further logic, .default-expressions should be split off as a separate AST node. Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision: Corrected as per Srikanth's review: (1) Renamed DefaultExpression etc. to DefaultValue (and DEFAULT_EXPRESSION to DEFAULT_VALUE) (2) and (3) getClazz is now getType and returns JCExpression (4) Relevant visitor added to SourceComputer (5), (6), and (8) cleaned up (7) has not been addressed, as it appears to be an unrelated bug. ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/370/files - new: https://git.openjdk.java.net/valhalla/pull/370/files/dd883c15..adc1372f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=370&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=370&range=00-01 Stats: 47 lines in 17 files changed: 7 ins; 3 del; 37 mod Patch: https://git.openjdk.java.net/valhalla/pull/370.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/370/head:pull/370 PR: https://git.openjdk.java.net/valhalla/pull/370 From jespersm at openjdk.java.net Wed Mar 24 20:51:31 2021 From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=) Date: Wed, 24 Mar 2021 20:51:31 GMT Subject: [lworld] RFR: 8263900: [lworld] Make .default a separate node type in the parser. [v3] In-Reply-To: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> References: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> Message-ID: <6ceibQW6XPNGcLb7XJJJUnJ6MHcB3skzswNwrx1vqt8=.79c3138f-3e14-43de-b8cf-866f876af77e@github.com> > To prepare for making .default a poly expression and to implement further logic, .default-expressions should be split off as a separate AST node. Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision: Spaces again = face+palm. ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/370/files - new: https://git.openjdk.java.net/valhalla/pull/370/files/adc1372f..0341e68c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=370&range=02 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=370&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/370.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/370/head:pull/370 PR: https://git.openjdk.java.net/valhalla/pull/370 From sadayapalam at openjdk.java.net Thu Mar 25 06:08:03 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Thu, 25 Mar 2021 06:08:03 GMT Subject: [lworld] RFR: 8263900: [lworld] Make .default a separate node type in the parser. In-Reply-To: References: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> Message-ID: On Wed, 24 Mar 2021 19:53:24 GMT, Jesper Steen M?ller wrote: > Regarding (7), I hit that earlier as well - but it is a entirely seperate bug, also available in the released product: [...] > While I might be able to fix this locally, I think it should really be addressed in the main repo first. I tried finding the bug for it, but didn't find it -- would you like me to report it? I agree this should be addressed in mainline first, yes please, could you raise a defect report for that ? Thanks! ------------- PR: https://git.openjdk.java.net/valhalla/pull/370 From sadayapalam at openjdk.java.net Thu Mar 25 06:20:00 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Thu, 25 Mar 2021 06:20:00 GMT Subject: [lworld] RFR: 8263900: [lworld] Make .default a separate node type in the parser. In-Reply-To: References: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> Message-ID: On Thu, 25 Mar 2021 06:05:27 GMT, Srikanth Adayapalam wrote: > > Regarding (7), I hit that earlier as well - but it is a entirely seperate bug, also available in the released product: > > [...] > > > While I might be able to fix this locally, I think it should really be addressed in the main repo first. I tried finding the bug for it, but didn't find it -- would you like me to report it? > > I agree this should be addressed in mainline first, yes please, could you raise a defect report for that ? Thanks! Actually, I think with your work to split Foo.default away from JCFieldAccess, this should be fixed independently in both mainline (for java.lang.class example you report) and in Valhalla for java.lang.default case we are discussing. With the code split, fixing mainline won't automatically fix Valhalla issue with java.lang.default. However, I am fine with that being handled on a separate ticket by itself without blocking or side tracking this PR/RFR and also the work on treating .default as a poly expression. ------------- PR: https://git.openjdk.java.net/valhalla/pull/370 From sadayapalam at openjdk.java.net Thu Mar 25 07:43:02 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Thu, 25 Mar 2021 07:43:02 GMT Subject: [lworld] RFR: 8263900: [lworld] Make .default a separate node type in the parser. [v3] In-Reply-To: <6ceibQW6XPNGcLb7XJJJUnJ6MHcB3skzswNwrx1vqt8=.79c3138f-3e14-43de-b8cf-866f876af77e@github.com> References: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> <6ceibQW6XPNGcLb7XJJJUnJ6MHcB3skzswNwrx1vqt8=.79c3138f-3e14-43de-b8cf-866f876af77e@github.com> Message-ID: On Wed, 24 Mar 2021 20:51:31 GMT, Jesper Steen M?ller wrote: >> To prepare for making .default a poly expression and to implement further logic, .default-expressions should be split off as a separate AST node. > > Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision: > > Spaces again = face+palm. Looks good Jesper, Can you issue an /integrate command and I will follow it up with /sponsor Thanks! ------------- Marked as reviewed by sadayapalam (Committer). PR: https://git.openjdk.java.net/valhalla/pull/370 From jespersm at openjdk.java.net Thu Mar 25 07:47:50 2021 From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=) Date: Thu, 25 Mar 2021 07:47:50 GMT Subject: [lworld] Integrated: 8263900: [lworld] Make .default a separate node type in the parser. In-Reply-To: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> References: <-9H6uB6qbIloZrgblo5XI5NDk1zpgXeXxDIZJutBndI=.ef31103e-be81-4e4e-99eb-6f7d2d71dca3@github.com> Message-ID: On Sat, 20 Mar 2021 11:36:44 GMT, Jesper Steen M?ller wrote: > To prepare for making .default a poly expression and to implement further logic, .default-expressions should be split off as a separate AST node. This pull request has now been integrated. Changeset: 91c49e4f Author: Jesper Steen M?ller Committer: Srikanth Adayapalam URL: https://git.openjdk.java.net/valhalla/commit/91c49e4f Stats: 245 lines in 18 files changed: 205 ins; 28 del; 12 mod 8263900: [lworld] Make .default a separate node type in the parser. Reviewed-by: sadayapalam ------------- PR: https://git.openjdk.java.net/valhalla/pull/370 From yyang at openjdk.java.net Thu Mar 25 09:02:13 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 25 Mar 2021 09:02:13 GMT Subject: [lworld] RFR: 8262831: [lworld] C2 compilation fails with assert "should be addp but is Phi" Message-ID: Hi, Can I have a review of this bug fix? The following test case is crashed at `(5)`: void test(MyValue[] array) { for (int i = 0; i < 10; ++i) { for (int j = 0; j < 10; ++j) { (1) iField = 6; (2) } (3) for (int j = 0; j < 2; ++j) { iField += array[0].b; } MyValue[] array2 = {new MyValue()}; (4) c = array[0]; (5) // hit the assertion array2[0] = t; (6) } } I did some investigations. C2 wants to check whether there are other Mem nodes between `(4)` and `(6)` that read or write the array2, because it hopes to merge `(4)` and `(6)` into an InitializeNode. If it finds that there are any reads or writes, such as LoadI in `(5)`, then its Address input must be an AddPNode. But in fact, it may be a PhiNode, so an assertion is hit. ![crash1](https://user-images.githubusercontent.com/5010047/112446079-c977b180-8d8a-11eb-9d75-3c0dd7487e58.jpg) Why does PhiNode appear on (5) as the input of LoadINode? Because the loop unrolling (PhaseIdealLoop::do_unroll) occurred in `(1)-(3)`, it produced a cloned node of the parameter array(not as straightforward as I said, actually it's a CastPPNode which produced via extra steps), and then the parameter array and the cloned nodes were merged, thus a PhiNode node appeared. ![crash2](https://user-images.githubusercontent.com/5010047/112446126-d5637380-8d8a-11eb-834e-7b62d03acd25.jpg) Thanks Tobias for pointing out that this scenario is not reproducible in mainline JDK because we can't perform such aggressive scalarization for non-inline types. So we'd better fix it in Valhalla for now. Thanks! Yang ------------- Commit messages: - fix c2 crash Changes: https://git.openjdk.java.net/valhalla/pull/371/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=371&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262831 Stats: 31 lines in 2 files changed: 30 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/371.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/371/head:pull/371 PR: https://git.openjdk.java.net/valhalla/pull/371 From jespersm at openjdk.java.net Fri Mar 26 08:00:50 2021 From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=) Date: Fri, 26 Mar 2021 08:00:50 GMT Subject: [lworld] RFR: 8264216: [lworld] unknown.Class.default gives misleading compilation error Message-ID: Make the compilation error for `somepkgname.UnknownClass.default` as informative as `UnknownClass.default`. ------------- Commit messages: - Tabs -> spaces - 8264216: unknown.Class.default gives misleading compilation error Changes: https://git.openjdk.java.net/valhalla/pull/372/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=372&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264216 Stats: 25 lines in 3 files changed: 23 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/372.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/372/head:pull/372 PR: https://git.openjdk.java.net/valhalla/pull/372 From nlisker at gmail.com Fri Mar 26 13:41:46 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 26 Mar 2021 16:41:46 +0300 Subject: Memory consumption of anonymous classes vs. concrete subclass In-Reply-To: <23b9cdc5-10c9-e0eb-521e-6dac34d49f4f@oracle.com> References: <23b9cdc5-10c9-e0eb-521e-6dac34d49f4f@oracle.com> Message-ID: Hi David, Thanks for the reply. What role does ThisClass play here? > It's the enclosing class of `SomeObjectProperty prop`. It should have been a placeholder for some Object. But the code is not effectively the same. The concrete class is a > general class that can be instantiated multiple times for different > beans and names - hence the fields are needed to store them. The > anonymous class is for a singleton instance hard-wired to return one > bean and one name. You could define a named class, specific to a given > property, with no fields and which was also hard-wired the same way. > When I instantiate either of these classes, at the end of the day, I want to return 2 constant values - the bean and the name. The concrete class is immutable (no setters, and I should have put the fields as private final), so once I create an instance of it, it is also hard-wired to return 2 specific values. Another way to phrase my question is: is there a mechanism in which I can create these anonymous classes by specifying the only important information - the value of those 2 fields - without taking readability punishment. Maybe this thought experiment would help me: *what if* when I instantiate the concrete class, it is converted in the background into the memory model of the abstract class. What breaks in this case considering that they both need to hold 2 constant values? Thanks, Nir On Wed, Mar 24, 2021 at 6:00 AM David Holmes wrote: > Hi Nir, > > On 24/03/2021 4:18 am, Nir Lisker wrote: > > Hi, > > > > In JavaFX we have classes of the form > > > > abstract class SomeObjectProperty { > > > > abstract String getName(); > > abstract Object getBean(); > > } > > > > And a concrete > > > > class SimpleSomeObjectProperty extends SomeObjectProperty { > > > > String name; > > Object bean; > > > > SimpleSomeObjectProperty(String name, Object bean) { > > this.name = name; > > this.bean = bean; > > } > > > > @Override > > abstract String getName() { return name; } > > > > @Override > > abstract Object getBean() { return bean; } > > } > > > > When we want to use a SomeObjectProperty, we usually use an > > anonymous subclass: > > > > SomeObjectProperty prop = new SomeObjectProperty() { > > > > @Override > > public Object getBean() { > > return ThisClass.this; > > What role does ThisClass play here? > > > } > > > > @Override > > public String getName() { > > return "prop "; > > } > > } > > > > The reason being memory consumption. The anonymous class takes less > memory > > because it holds less references. The amount varies depending on the > number > > of fields and their getters (in this case we had 2, but it could be > more), > > but we have done tests that show the memory footprint difference. > However, > > this is much less readable obviously and much longer. > > Since JavaFX uses these properties extensively, the memory issue is > > significant and the readability issue is prominent. > > > > I want the best of both worlds - more readable with less memory. I would > > think that under the hood something could be done to optimize this code > > since effectively it does the same. Is it possible to do something about > > this? > > But the code is not effectively the same. The concrete class is a > general class that can be instantiated multiple times for different > beans and names - hence the fields are needed to store them. The > anonymous class is for a singleton instance hard-wired to return one > bean and one name. You could define a named class, specific to a given > property, with no fields and which was also hard-wired the same way. > > Cheers, > David > > > - Nir > > > From jesper at selskabet.org Fri Mar 26 15:44:55 2021 From: jesper at selskabet.org (=?utf-8?Q?Jesper_Steen_M=C3=B8ller?=) Date: Fri, 26 Mar 2021 16:44:55 +0100 Subject: Memory consumption of anonymous classes vs. concrete subclass In-Reply-To: References: <23b9cdc5-10c9-e0eb-521e-6dac34d49f4f@oracle.com> Message-ID: Hi Nir and list (I'm sorry if I'm over-explaining this, but it's an interesting issue -- maybe the details would interest others, too) Solutions for right now: In your example, you're building an anonymous class, but it still holds a reference (to ThisClass.this) whereas SimpleSomeObjectProperty needs to store two, one for each field. With the current 16 byte object header in OpenJDK, the effective difference is a jump from 20 and 24 bytes (or 24 and 32 on heaps without compressed OOPS). Perhaps you're better off making a flyweight cache or something similar, since you know best what the intended call pattern is. Another approach would be to change the abstract class into a functional interface and then harness the power of lambdas and let hotspots' magic powers do the heavy lifting: @FunctionalInterface public interface SomeObjectProperty { Pair getBeanInfo(); default String getName() { return getBeanInfo().getKey(); }; default Object getBean() { return getBeanInfo().getValue(); }; } Then your anonymous class usage would become a bit more elegant: SomeObjectProperty prop = () -> new Pair<>("prop ", ThisClass.this); To guess the weight of the underlying lambda proxy, inspect the generated lambda implementation method in the enclosing class. In this case, it's: private javafx.util.Pair lambda$0(); Lambda method is not static: This means that this is captured, which is clear from the lambda expression. The lambda proxy object would simply capture the this-reference and call the lambda getBeanInfo into the generated lambda class. No parameters on the lambda implementation method: This means no further values are stored in the lambda proxy object. Overhead of the pair workaround: I'm assuming that in the worst case, the Pairs would get collected easily from the eden space, and in the best case, hotspot would conclude that the Pair doesn't escape, and avoid allocating it altogether, and inline and optimize out the unneeded assignments. See below for possible other solutions: > On 26 Mar 2021, at 14.41, Nir Lisker > wrote: > > Hi David, > > Thanks for the reply. > > What role does ThisClass play here? >> > > It's the enclosing class of `SomeObjectProperty prop`. It should have been > a placeholder for some Object. > > But the code is not effectively the same. The concrete class is a >> general class that can be instantiated multiple times for different >> beans and names - hence the fields are needed to store them. The >> anonymous class is for a singleton instance hard-wired to return one >> bean and one name. You could define a named class, specific to a given >> property, with no fields and which was also hard-wired the same way. >> > > When I instantiate either of these classes, at the end of the day, I want > to return 2 constant values - the bean and the name. Nitpicking: Actually, ThisClass.this is not constant across all instances of the anonymous class (so it tracks the ThisClass it was instantiated in), so there still needs to be that one reference. If each ThisClass instance needs to give out many such identical SomeObjectProperty instances, it really should cache it instead. > The concrete class is > immutable (no setters, and I should have put the fields as private final), > so once I create an instance of it, it is also hard-wired to return 2 > specific values. > Another way to phrase my question is: is there a mechanism in which I can > create these anonymous classes by specifying the only important > information - the value of those 2 fields - without taking readability > punishment. > Maybe this thought experiment would help me: *what if* when I instantiate > the concrete class, it is converted in the background into the memory model > of the abstract class. What breaks in this case considering that they both > need to hold 2 constant values? I guess theoretically, a future JVM could do this for immutable instances (records), by recording instantiation counts by each field (or combination of fields) as const-candidates, and slicing out new class variations for hot candidates. But that seems very impractical and far fetched, and perhaps not what you meant. It's perhaps be a better idea to allow the runtime to produce a flyweight pattern for classes frequently moved from eden space to older generations, and de-dup'ing those instances. You'd have to abandon object identity, which is guaranteed in your outlined solution, but I can't tell from context if it important. More to convention, a future Java *could* have constant value parameters (like C++ and Rust): class SimpleSomeObjectProperty extends SomeObjectProperty { Object bean; SimpleSomeObjectProperty(Object bean) { this.bean = bean; } @Override abstract String getName() { return S; } @Override abstract Object getBean() { return bean; } } Your ThisClass could then do "SomeObjectProperty prop = make SimpleSomeObjectProperty<"prop ">(this)" Each such specialisation site would carry a constant space+time cost of creating a new version of the methods affected, and likely an extra layer of dispatch for each 'getName' call. And it would require some person-years of investment into the JVM and javac ;-) -Jesper From fparain at openjdk.java.net Fri Mar 26 20:08:47 2021 From: fparain at openjdk.java.net (Frederic Parain) Date: Fri, 26 Mar 2021 20:08:47 GMT Subject: Integrated: Add flag to control use of type restrictions + test fixes Message-ID: Add a VM flag to control use of type restrictions + test fixes ------------- Commit messages: - Add flag to control use of type restrictions + test fixes Changes: https://git.openjdk.java.net/valhalla/pull/373/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=373&range=00 Stats: 34 lines in 5 files changed: 9 ins; 6 del; 19 mod Patch: https://git.openjdk.java.net/valhalla/pull/373.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/373/head:pull/373 PR: https://git.openjdk.java.net/valhalla/pull/373 From fparain at openjdk.java.net Fri Mar 26 20:08:47 2021 From: fparain at openjdk.java.net (Frederic Parain) Date: Fri, 26 Mar 2021 20:08:47 GMT Subject: Integrated: Add flag to control use of type restrictions + test fixes In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 20:03:09 GMT, Frederic Parain wrote: > Add a VM flag to control use of type restrictions + test fixes This pull request has now been integrated. Changeset: f5e92bd6 Author: Frederic Parain URL: https://git.openjdk.java.net/valhalla/commit/f5e92bd6 Stats: 34 lines in 5 files changed: 9 ins; 6 del; 19 mod Add flag to control use of type restrictions + test fixes ------------- PR: https://git.openjdk.java.net/valhalla/pull/373 From sadayapalam at openjdk.java.net Mon Mar 29 04:22:53 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Mon, 29 Mar 2021 04:22:53 GMT Subject: [lworld] RFR: 8264216: [lworld] unknown.Class.default gives misleading compilation error In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 07:49:37 GMT, Jesper Steen M?ller wrote: > Make the compilation error for `somepkgname.UnknownClass.default` as informative as `UnknownClass.default`. Thanks Jesper, I offer to be the reviewer and sponsor for this. Will study this later today and share any comments. ------------- PR: https://git.openjdk.java.net/valhalla/pull/372 From thartmann at openjdk.java.net Mon Mar 29 12:33:41 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 29 Mar 2021 12:33:41 GMT Subject: [lworld] RFR: 8262831: [lworld] C2 compilation fails with assert "should be addp but is Phi" In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 08:55:40 GMT, Yi Yang wrote: > Hi, > > Can I have a review of this bug fix? > > The following test case is crashed at `(5)`: > void test(MyValue[] array) { > for (int i = 0; i < 10; ++i) { > for (int j = 0; j < 10; ++j) { (1) > iField = 6; (2) > } (3) > for (int j = 0; j < 2; ++j) { > iField += array[0].b; > } > MyValue[] array2 = {new MyValue()}; (4) > c = array[0]; (5) // hit the assertion > array2[0] = t; (6) > } > } > I did some investigations. C2 wants to check whether there are other Mem nodes between `(4)` and `(6)` that read or write the array2, because it hopes to merge `(4)` and `(6)` into an InitializeNode. If it finds that there are any reads or writes, such as LoadI in `(5)`, then its Address input must be an AddPNode. But in fact, it may be a PhiNode, so an assertion is hit. > > ![crash1](https://user-images.githubusercontent.com/5010047/112446079-c977b180-8d8a-11eb-9d75-3c0dd7487e58.jpg) > > Why does PhiNode appear on (5) as the input of LoadINode? Because the loop unrolling (PhaseIdealLoop::do_unroll) occurred in `(1)-(3)`, it produced a cloned node of the parameter array(not as straightforward as I said, actually it's a CastPPNode which produced via extra steps), and then the parameter array and the cloned nodes were merged, thus a PhiNode node appeared. > > ![crash2](https://user-images.githubusercontent.com/5010047/112446126-d5637380-8d8a-11eb-834e-7b62d03acd25.jpg) > > Thanks Tobias for pointing out that this scenario is not reproducible in mainline JDK because we can't perform such aggressive scalarization for non-inline types. So we'd better fix it in Valhalla for now. > > Thanks! > Yang Looks good to me. Thanks for fixing. src/hotspot/share/opto/memnode.cpp line 3926: > 3924: Node* base = other_adr; > 3925: if (base->is_Phi()) { > 3926: // In rare case, base may be a PhiNode and it may reads `it may reads` -> `it may read` ------------- Marked as reviewed by thartmann (Committer). PR: https://git.openjdk.java.net/valhalla/pull/371 From yyang at openjdk.java.net Mon Mar 29 14:42:06 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 29 Mar 2021 14:42:06 GMT Subject: [lworld] RFR: 8262831: [lworld] C2 compilation fails with assert "should be addp but is Phi" [v2] In-Reply-To: References: Message-ID: > Hi, > > Can I have a review of this bug fix? > > The following test case is crashed at `(5)`: > void test(MyValue[] array) { > for (int i = 0; i < 10; ++i) { > for (int j = 0; j < 10; ++j) { (1) > iField = 6; (2) > } (3) > for (int j = 0; j < 2; ++j) { > iField += array[0].b; > } > MyValue[] array2 = {new MyValue()}; (4) > c = array[0]; (5) // hit the assertion > array2[0] = t; (6) > } > } > I did some investigations. C2 wants to check whether there are other Mem nodes between `(4)` and `(6)` that read or write the array2, because it hopes to merge `(4)` and `(6)` into an InitializeNode. If it finds that there are any reads or writes, such as LoadI in `(5)`, then its Address input must be an AddPNode. But in fact, it may be a PhiNode, so an assertion is hit. > > ![crash1](https://user-images.githubusercontent.com/5010047/112446079-c977b180-8d8a-11eb-9d75-3c0dd7487e58.jpg) > > Why does PhiNode appear on (5) as the input of LoadINode? Because the loop unrolling (PhaseIdealLoop::do_unroll) occurred in `(1)-(3)`, it produced a cloned node of the parameter array(not as straightforward as I said, actually it's a CastPPNode which produced via extra steps), and then the parameter array and the cloned nodes were merged, thus a PhiNode node appeared. > > ![crash2](https://user-images.githubusercontent.com/5010047/112446126-d5637380-8d8a-11eb-834e-7b62d03acd25.jpg) > > Thanks Tobias for pointing out that this scenario is not reproducible in mainline JDK because we can't perform such aggressive scalarization for non-inline types. So we'd better fix it in Valhalla for now. > > Thanks! > Yang Yi Yang has updated the pull request incrementally with one additional commit since the last revision: syntax error ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/371/files - new: https://git.openjdk.java.net/valhalla/pull/371/files/57704eaf..0a5b6345 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=371&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=371&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/371.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/371/head:pull/371 PR: https://git.openjdk.java.net/valhalla/pull/371 From yyang at openjdk.java.net Mon Mar 29 14:42:09 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 29 Mar 2021 14:42:09 GMT Subject: [lworld] RFR: 8262831: [lworld] C2 compilation fails with assert "should be addp but is Phi" [v2] In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 12:31:00 GMT, Tobias Hartmann wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> syntax error > > Looks good to me. Thanks for fixing. Thanks Tobias for the review! ------------- PR: https://git.openjdk.java.net/valhalla/pull/371 From david.simms at oracle.com Mon Mar 29 17:30:50 2021 From: david.simms at oracle.com (David Simms) Date: Mon, 29 Mar 2021 19:30:50 +0200 Subject: Result: New Valhalla Committer: Vicente Romero Message-ID: Voting for Vicente Romero [1] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. David Simms [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2021-March/008718.html From yyang at openjdk.java.net Tue Mar 30 05:45:51 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 30 Mar 2021 05:45:51 GMT Subject: [lworld] Integrated: 8262831: [lworld] C2 compilation fails with assert "should be addp but is Phi" In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 08:55:40 GMT, Yi Yang wrote: > Hi, > > Can I have a review of this bug fix? > > The following test case is crashed at `(5)`: > void test(MyValue[] array) { > for (int i = 0; i < 10; ++i) { > for (int j = 0; j < 10; ++j) { (1) > iField = 6; (2) > } (3) > for (int j = 0; j < 2; ++j) { > iField += array[0].b; > } > MyValue[] array2 = {new MyValue()}; (4) > c = array[0]; (5) // hit the assertion > array2[0] = t; (6) > } > } > I did some investigations. C2 wants to check whether there are other Mem nodes between `(4)` and `(6)` that read or write the array2, because it hopes to merge `(4)` and `(6)` into an InitializeNode. If it finds that there are any reads or writes, such as LoadI in `(5)`, then its Address input must be an AddPNode. But in fact, it may be a PhiNode, so an assertion is hit. > > ![crash1](https://user-images.githubusercontent.com/5010047/112446079-c977b180-8d8a-11eb-9d75-3c0dd7487e58.jpg) > > Why does PhiNode appear on (5) as the input of LoadINode? Because the loop unrolling (PhaseIdealLoop::do_unroll) occurred in `(1)-(3)`, it produced a cloned node of the parameter array(not as straightforward as I said, actually it's a CastPPNode which produced via extra steps), and then the parameter array and the cloned nodes were merged, thus a PhiNode node appeared. > > ![crash2](https://user-images.githubusercontent.com/5010047/112446126-d5637380-8d8a-11eb-834e-7b62d03acd25.jpg) > > Thanks Tobias for pointing out that this scenario is not reproducible in mainline JDK because we can't perform such aggressive scalarization for non-inline types. So we'd better fix it in Valhalla for now. > > Thanks! > Yang This pull request has now been integrated. Changeset: 226abe29 Author: Yi Yang Committer: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/226abe29 Stats: 31 lines in 2 files changed: 30 ins; 0 del; 1 mod 8262831: [lworld] C2 compilation fails with assert "should be addp but is Phi" Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/valhalla/pull/371 From nick.gasson at arm.com Tue Mar 30 10:41:12 2021 From: nick.gasson at arm.com (Nick Gasson) Date: Tue, 30 Mar 2021 18:41:12 +0800 Subject: Question about tearing and buffered primitive classes Message-ID: <85sg4csz3r.fsf@nicgas01-pc.shanghai.arm.com> Hi, There's one Valhalla test, TestBufferTearing.java, that fails frequently on AArch64 when MyValue.incrementAndCheck() is compiled by C1: java.lang.RuntimeException: Inconsistent field values: expected 0 to equal 675128 at jdk.test.lib.Asserts.fail(Asserts.java:594) at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) at jdk.test.lib.Asserts.assertEQ(Asserts.java:178) at compiler.valhalla.inlinetypes.MyValue.incrementAndCheck(TestBufferTearing.java:81) at compiler.valhalla.inlinetypes.TestBufferTearing$Runner.run(TestBufferTearing.java:124) This test sets -XX:InlineFieldMaxFlatSize=0 so MyValue is always passed around as a reference. C1 inserts a store-store barrier between zeroing the temporary object withfield allocates and initialising its fields. But there's no barrier between the field initialisation and the store that publishes the object (the store to test.vtField1 in TestBufferTearing::run()) so other threads can observe these stores out-of-order on a non-TSO system. An obvious fix is to stick a store-store barrier after every withfield: diff --git a/src/hotspot/share/c1/c1_GraphBuilder.cpp b/src/hotspot/share/c1/c1_GraphBuilder.cpp index 86610d15421b..ead767f596d7 100644 --- a/src/hotspot/share/c1/c1_GraphBuilder.cpp +++ b/src/hotspot/share/c1/c1_GraphBuilder.cpp @@ -2116,6 +2116,10 @@ void GraphBuilder::withfield(int field_index) StoreField* store = new StoreField(new_instance, offset_modify, field_modify, val, false, state_before, needs_patching); append(store); } + + // Ensure the stores which initialize the fields are visible before + // any subsequent store which publishes the object. + append(new MemBar(lir_membar_storestore)); } Dependencies* GraphBuilder::dependency_recorder() const { However based on my reading of the description in JDK-8237741 [1] this should only be necessary when the object is passed by invisible reference, not when it's actually flattened. In Tobias' fix for JDK-8238780 [2] a store-store barrier was added to C2's InlineTypeBaseNode::buffer() but I can't see where the equivalent "buffering" happens in C1. Furthermore I don't understand why we can't instead rely on the barrier that gets added before returning from a constructor that writes final fields? AIUI a primitive class's fields are always final and `this' can't escape its constructor so the effect should be the same as putting a barrier after each intermediate allocation inside the constructor. GraphBuilder::withfield() calls set_wrote_final() which is used for this purpose *but* in GraphBuilder::method_return() we don't set need_mem_bar because method()->is_object_constructor() is false for primitive class constructors. So a different patch that also fixes this test case is: diff --git a/src/hotspot/share/c1/c1_GraphBuilder.cpp b/src/hotspot/share/c1/c1_GraphBuilder.cpp index ead767f596d7..ac7e4ce5f06d 100644 --- a/src/hotspot/share/c1/c1_GraphBuilder.cpp +++ b/src/hotspot/share/c1/c1_GraphBuilder.cpp @@ -1617,7 +1617,7 @@ void GraphBuilder::method_return(Value x, bool ignore_return) { // The conditions for a memory barrier are described in Parse::do_exits(). bool need_mem_bar = false; - if (method()->is_object_constructor() && + if ((method()->is_object_constructor() || method()->is_static_init_factory()) && (scope()->wrote_final() || (AlwaysSafeConstructors && scope()->wrote_fields()) || (support_IRIW_for_not_multiple_copy_atomic_cpu && scope()->wrote_volatile()))) { Any pointers on the best way to solve this? -- Thanks, Nick [1] https://bugs.openjdk.java.net/browse/JDK-8237741 [2] http://hg.openjdk.java.net/valhalla/valhalla/rev/b018052fc8b1 From brian.goetz at oracle.com Tue Mar 30 13:34:42 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 30 Mar 2021 09:34:42 -0400 Subject: Fwd: Default values vs nulls In-Reply-To: <0d6c2cc2-21fb-a25c-3ea1-dcbb2409958f@hontvari.net> References: <0d6c2cc2-21fb-a25c-3ea1-dcbb2409958f@hontvari.net> Message-ID: Received in the -comments list. The synthetic value you are describing is what we have been calling (somewhat pejoratively) "vull"; a special sentinel for this value is uninitialized.? When you pull on the vull string for a bit, it becomes apparent you are creating a poor reinvention of null. -------- Forwarded Message -------- Subject: Default values vs nulls Date: Thu, 6 Aug 2020 11:04:21 +0200 From: Hontv?ri Attila To: valhalla-spec-comments at openjdk.java.net (resending, previous email had a confusing ending, ignore that) The currently discussed solutions to the problem of uninitialized bucket #3 values mostly seems like the following: the value set of the type is extended with a special value that throws an exception if somebody invokes a method on that, but instead of the name "null" it has a new name and syntax: "V.default". But if we take for example a LocalDate, it is a bit strange to say the fields with type LocalDate.val are initialized to "LocalDate.default", because that type doesn't have an acceptable default value: the variable just has no LocalDate value if somebody haven't set one, and null means exactly that. This creates a split between non-initialized reference types and inline types, which might be unneecessary. It might be worth to investigate Option J, that solves this by treating uninitialized default values as nulls, but hasn't got as much attention as some other options. From brian.goetz at oracle.com Tue Mar 30 13:42:03 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 30 Mar 2021 09:42:03 -0400 Subject: Fwd: Comment on "Revisiting default values" In-Reply-To: References: Message-ID: <36dad9b3-40b1-cfb4-9cb1-0be0b227ae42@oracle.com> Received on the -comments list. The optimization you describe here is what we have been referring to as using a "pivot field"; in some cases, you can strength-reduce the "are all fields the default" to a simpler "is this field the default" test.? The trick is identifying the pivot field.? There are two broad approaches: ?- Ask the programmer to nominate it. ?- Figure it out. The former has a terrible return-on-syntax; this is a micro-targeted feature that serves only as a hint to the optimizer.? This seems way below the threshold for a language feature (and, before anyone suggests "annotation", remember that annotations cannot drive language semantics.) The latter is possible; we'd have to detect that all constructors assign some specific field to a non-default value.? (This could be done either by the static or dynamic compilers.)? But, given that most constructor assignments are some form of ??? this.x = x where x is a parameter, we can't (without global analysis) determine if x is a non-default value.? So the only realistic patterns we could key off of are: ??? this.x = new Foo()? // new never evaluates to null or ??? if (x == null) throw;?? // more generally, the default value for the type of x ??? this.x = x; While we can of course do this, it's not clear how effective this will be for typical primitive classes.? Which is to say, its an optimization, sometimes it will work, but it won't make the costs go away in general. -------- Forwarded Message -------- Subject: Comment on "Revisiting default values" Date: Mon, 29 Mar 2021 22:55:05 +0200 From: Raffaello Giulietti To: valhalla-spec-comments at openjdk.java.net Hello, IMO the "zero means null" proposal in [1] for instances implementing NoGoodDefault is the most consistent with the usual way of thinking Java. Here's a possible way to slightly lower the cost of the check against the default (the "zero"). Of course, a default-hostile class always has proper instances in which at least one field (not necessarily the same in all instances) is "nonzero". Oftentimes, by design, a class mandates some specific field to be "nonzero" in every instance. For example, the month (or the day) in LocalDate should not be zero; name or type in DirectMethodHandleDescImpl must be non-null; e0 in List12 must not be null; etc. In such cases, once migrated to NoGoodDefault primitive classes, it suffices to check any of these fields for "zero" to witness the default value. That is, if such a field is "zero" then the instance is necessarily the unacceptable default. There's no need to compare all bits against "zero". If the user could annotate such fields with something like @NonDefault or @DefaultWitness, the vm could possibly perform better in some circumstances, particularly on "fat" instances. Greetings Raffaello ---- [1] https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2021-March/001486.html From thartmann at openjdk.java.net Tue Mar 30 14:05:41 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 30 Mar 2021 14:05:41 GMT Subject: [lworld] RFR: 8263441: [lworld] TestUnloadedInlineTypeField fails due to unexpected compilation level Message-ID: <2GLReAVs1L7ionhCwSZKM89UZurBflsg3eCRl54rydE=.fb072e69-b646-4ea8-888a-e9242f0615ef@github.com> Some of the unit tests trigger frequent recompilation that may lead to test failures because the `PerMethodRecompilationCutoff` is reached for the test method. The fix is to disable `PerMethodRecompilationCutoff` and `PerBytecodeRecompilationCutoff`. Best regards, Tobias ------------- Commit messages: - 8263441: [lworld] TestUnloadedInlineTypeField fails due to unexpected compilation level Changes: https://git.openjdk.java.net/valhalla/pull/374/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=374&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263441 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/374.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/374/head:pull/374 PR: https://git.openjdk.java.net/valhalla/pull/374 From thartmann at openjdk.java.net Tue Mar 30 14:18:36 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 30 Mar 2021 14:18:36 GMT Subject: [lworld] Integrated: 8263441: [lworld] TestUnloadedInlineTypeField fails due to unexpected compilation level In-Reply-To: <2GLReAVs1L7ionhCwSZKM89UZurBflsg3eCRl54rydE=.fb072e69-b646-4ea8-888a-e9242f0615ef@github.com> References: <2GLReAVs1L7ionhCwSZKM89UZurBflsg3eCRl54rydE=.fb072e69-b646-4ea8-888a-e9242f0615ef@github.com> Message-ID: On Tue, 30 Mar 2021 13:59:48 GMT, Tobias Hartmann wrote: > Some of the unit tests trigger frequent recompilation that may lead to test failures because the `PerMethodRecompilationCutoff` is reached for the test method. The fix is to disable `PerMethodRecompilationCutoff` and `PerBytecodeRecompilationCutoff`. > > Best regards, > Tobias This pull request has now been integrated. Changeset: 83d849f4 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/83d849f4 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8263441: [lworld] TestUnloadedInlineTypeField fails due to unexpected compilation level ------------- PR: https://git.openjdk.java.net/valhalla/pull/374 From sadayapalam at openjdk.java.net Wed Mar 31 09:42:24 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 31 Mar 2021 09:42:24 GMT Subject: [lworld] RFR: 8264216: [lworld] unknown.Class.default gives misleading compilation error In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 07:49:37 GMT, Jesper Steen M?ller wrote: > Make the compilation error for `somepkgname.UnknownClass.default` as informative as `UnknownClass.default`. Please fix the issues mentioned. Also confirm whether you have run all the tests. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 41: > 39: import com.sun.source.util.SimpleTreeVisitor; > 40: import com.sun.tools.javac.code.*; > 41: import com.sun.tools.javac.code.Kinds.KindName; This import looks unused ?? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4902: > 4900: Fragments.Location(Kinds.typeKindName(env.enclClass.type), env.enclClass.type, null))); > 4901: yield syms.errSymbol; > 4902: } Looks ok, inventing a new error message altogether (such as default cannot be applied to a package) looks too heavy a hammer. test/langtools/tools/javac/valhalla/lworld-values/UnknownTypeDefault.out line 3: > 1: UnknownTypeDefault.java:11:30: compiler.err.cant.resolve.location: kindname.class, Y, null, null, (compiler.misc.location: kindname.class, UnknownTypeDefault, null) > 2: UnknownTypeDefault.java:12:32: compiler.err.cant.resolve.location: kindname.class, y.Z, null, null, (compiler.misc.location: kindname.class, UnknownTypeDefault, null) > 3: 2 errors Are the co-ordinates of the error message correct ?? This test is failing for me as I see different column numbers than what you have mastered. ------------- Changes requested by sadayapalam (Committer). PR: https://git.openjdk.java.net/valhalla/pull/372 From sadayapalam at openjdk.java.net Wed Mar 31 12:37:46 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 31 Mar 2021 12:37:46 GMT Subject: [lworld] RFR: 8244227: [lworld] Explore an implementation where the reference projection and value projection types are backed by a single class symbol Message-ID: This PR overhauls the existing implementation/representation of reference projection types and the inline types so that both share the same underlying symbol, much like how an infinite family of parameterized types that originate from the same generic type are modelled using the same underlying symbol. ------------- Commit messages: - Various changes to handle projections sharing a symbol/not having their own symbols - Introducce another variant of Types.asSuper to operate on Type's so as not to confuse - Nestmates and innerclasses attribute generation, classfile creation, signature management ... - Genesis, construction, preservation and propagation of reference projection type - Get out of the business of having to maintain the doppleganger symbol in sync with original - In diagnostics and debug strings while mentioning projection types, use .ref/.val rather than $ref/$val Changes: https://git.openjdk.java.net/valhalla/pull/375/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=375&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244227 Stats: 540 lines in 28 files changed: 185 ins; 245 del; 110 mod Patch: https://git.openjdk.java.net/valhalla/pull/375.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/375/head:pull/375 PR: https://git.openjdk.java.net/valhalla/pull/375 From jespersm at openjdk.java.net Wed Mar 31 12:38:24 2021 From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=) Date: Wed, 31 Mar 2021 12:38:24 GMT Subject: [lworld] RFR: 8264216: [lworld] unknown.Class.default gives misleading compilation error In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 09:34:49 GMT, Srikanth Adayapalam wrote: >> Make the compilation error for `somepkgname.UnknownClass.default` as informative as `UnknownClass.default`. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 41: > >> 39: import com.sun.source.util.SimpleTreeVisitor; >> 40: import com.sun.tools.javac.code.*; >> 41: import com.sun.tools.javac.code.Kinds.KindName; > > This import looks unused ?? Ooopsie, I'll fix that. ------------- PR: https://git.openjdk.java.net/valhalla/pull/372 From sadayapalam at openjdk.java.net Wed Mar 31 12:47:32 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 31 Mar 2021 12:47:32 GMT Subject: [lworld] RFR: 8244227: [lworld] Explore an implementation where the reference projection and value projection types are backed by a single class symbol In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 12:32:04 GMT, Srikanth Adayapalam wrote: > This PR overhauls the existing implementation/representation of reference projection types and the inline types so that both share the same underlying symbol, much like how an infinite family of parameterized types that originate from the same generic type are modelled using the same underlying symbol. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 373: > 371: JCMethodDecl lambdaDecl = make.MethodDef(make.Modifiers(sym.flags_field), > 372: sym.name, > 373: make.QualIdent(lambdaType.getReturnType().tsym).setType(lambdaType.getReturnType()), Discussion item:This spot indicates one of the pain points in the new approach, There are lots of places where we construct fresh AST nodes from a symbol and in the process decorate the AST's type from what we see in the symbol. This is not a problem for parameterized types because the type arguments are erased by TransTypes anyway. But with Foo.ref and Foo.val sharing the same symbol, we will loose reference "projection'ness". I would like to discuss if there are mechanical ways to detect and prevent such loss of type information. ATM, I am dependent on tests breaking to expose such problems and this is dependent heavily on coverage and coverage is still in infancy ------------- PR: https://git.openjdk.java.net/valhalla/pull/375 From sadayapalam at openjdk.java.net Wed Mar 31 12:50:25 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 31 Mar 2021 12:50:25 GMT Subject: [lworld] RFR: 8244227: [lworld] Explore an implementation where the reference projection and value projection types are backed by a single class symbol In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 12:32:04 GMT, Srikanth Adayapalam wrote: > This PR overhauls the existing implementation/representation of reference projection types and the inline types so that both share the same underlying symbol, much like how an infinite family of parameterized types that originate from the same generic type are modelled using the same underlying symbol. src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1056: > 1054: this(outer, typarams, tsym, metadata, false); > 1055: } > 1056: I have rewired most of the constructor invocations to the new one which handles a reference projection flag parameter. A few call sites are still left in for the old constructors, these seem harmless. ------------- PR: https://git.openjdk.java.net/valhalla/pull/375 From sadayapalam at openjdk.java.net Wed Mar 31 12:55:24 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 31 Mar 2021 12:55:24 GMT Subject: [lworld] RFR: 8244227: [lworld] Explore an implementation where the reference projection and value projection types are backed by a single class symbol In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 12:32:04 GMT, Srikanth Adayapalam wrote: > This PR overhauls the existing implementation/representation of reference projection types and the inline types so that both share the same underlying symbol, much like how an infinite family of parameterized types that originate from the same generic type are modelled using the same underlying symbol. Here are some notes that should help in the review process. I have broken down the changes involved into six logical units each forming a separate commit. Of these, the very first ("In diagnostics and debug strings while mentioning projection types, use .ref/.val rather than $ref/$val") and perhaps even the second commit ("Get out of the business of having to maintain the doppleganger symbol in sync with original") can be skipped or cursorily glanced through. Real action starts at the third commit ("Genesis, construction, preservation and propagation of reference projection type") and proceeds through the next three commits. src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2208: > 2206: asSuper(t, s.tsym) : null; > 2207: } > 2208: Not all calls to the original method asSuper(Type, Symbol) have been rerouted to here. A few calls it appears should not be. I will add more analysis on why that is so later tomorrow. I haven't also fully studied whether asSub, asEnclosingSuper, asOuterSuper etc need similar variant, it seems not. This is to be studied and addressed in a follow up task. ------------- PR: https://git.openjdk.java.net/valhalla/pull/375 From jespersm at openjdk.java.net Wed Mar 31 12:58:28 2021 From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=) Date: Wed, 31 Mar 2021 12:58:28 GMT Subject: [lworld] RFR: 8264216: [lworld] unknown.Class.default gives misleading compilation error In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 09:38:13 GMT, Srikanth Adayapalam wrote: >> Make the compilation error for `somepkgname.UnknownClass.default` as informative as `UnknownClass.default`. > > test/langtools/tools/javac/valhalla/lworld-values/UnknownTypeDefault.out line 3: > >> 1: UnknownTypeDefault.java:11:30: compiler.err.cant.resolve.location: kindname.class, Y, null, null, (compiler.misc.location: kindname.class, UnknownTypeDefault, null) >> 2: UnknownTypeDefault.java:12:32: compiler.err.cant.resolve.location: kindname.class, y.Z, null, null, (compiler.misc.location: kindname.class, UnknownTypeDefault, null) >> 3: 2 errors > > Are the co-ordinates of the error message correct ?? This test is failing for me as I see different column numbers than what you have mastered. I submitted it first with tabs instead of spaces, and corrected the spaces without fixing the issue, assuming 4 space tabs. I should have caught this in the tier1 langtools test pipeline, I was just looking in the wrong place. ------------- PR: https://git.openjdk.java.net/valhalla/pull/372 From jespersm at openjdk.java.net Wed Mar 31 13:13:50 2021 From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=) Date: Wed, 31 Mar 2021 13:13:50 GMT Subject: [lworld] RFR: 8264216: [lworld] unknown.Class.default gives misleading compilation error [v2] In-Reply-To: References: Message-ID: <4If7lnUu6w6t8qkC7WImgBDWPdK4JVWLv2SWvCb_8_0=.c9583a58-9828-496f-8189-1d8037af953d@github.com> > Make the compilation error for `somepkgname.UnknownClass.default` as informative as `UnknownClass.default`. Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/372/files - new: https://git.openjdk.java.net/valhalla/pull/372/files/4a9c0118..94e65ef6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=372&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=372&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/372.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/372/head:pull/372 PR: https://git.openjdk.java.net/valhalla/pull/372 From sadayapalam at openjdk.java.net Wed Mar 31 15:40:31 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 31 Mar 2021 15:40:31 GMT Subject: [lworld] RFR: 8244227: [lworld] Explore an implementation where the reference projection and value projection types are backed by a single class symbol In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 12:53:12 GMT, Srikanth Adayapalam wrote: >> This PR overhauls the existing implementation/representation of reference projection types and the inline types so that both share the same underlying symbol, much like how an infinite family of parameterized types that originate from the same generic type are modelled using the same underlying symbol. > > Here are some notes that should help in the review process. I have broken down the changes involved into six logical units each forming a separate commit. Of these, the very first ("In diagnostics and debug strings while mentioning projection types, use .ref/.val rather than $ref/$val") and perhaps even the second commit ("Get out of the business of having to maintain the doppleganger symbol in sync with original") can be skipped or cursorily glanced through. > > Real action starts at the third commit ("Genesis, construction, preservation and propagation of reference projection type") and proceeds through the next three commits. Overall, I see two major challenges with the new approach (although it is simpler in many ways and has much to like about vis a vis what we have now): 1. Types.asSuper(Type, Symbol) would answer non-null for Foo.ref, Foo.val.tsym being passed in because they both have the same sym and deep down in Types.asSuper we return nonnull if the symbol is equal. So, I have to invent a version of Types.asSuper(Type, Type) instead and reroute the calls to that. However this was tricky in that there are places we do want asSuper to answer non-null when the Type is reference projection and the Symbol is primitive class. For example given Foo { void add(T) {} } a call to Types.memberType(Foo.ref, add(String)) internally results in a call to asSuper(Foo.ref, Foo) - 2. There are places where we go from Symbol -> AST using the TreeMaker, - these Tree factory methods internally set the AST node type from the symbol. This results in "reference projectionness" being lost. The problem is to mechanically identify the places where such loss may occur (and recover, which is easy to do). ATM, I fixed the places where the tests failed thereby indicating type loss. But this approach is heavily dependent on coverage being good, and our tests are still not super good there being a work in progress (See that 2 is not a problem for parameterized types because after TransType, type arguments are gone AND more importantly the erasure of all parameterized types of the same generic class is the same, whereas we want Foo.ref and Foo.val to share a symbol but erase differently.) ------------- PR: https://git.openjdk.java.net/valhalla/pull/375