From vladimir.kozlov at oracle.com Tue Nov 1 11:41:00 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Nov 2011 11:41:00 -0700 Subject: Request for reviews (M): 7059047: EA: can't find initializing store with several CheckCastPP Message-ID: <4EB03D3C.7000708@oracle.com> http://cr.openjdk.java.net/~kvn/7059047/webrev 7059047: EA: can't find initializing store with several CheckCastPP Added new escape state: ControlEscape. Use it instead of ArgEscape and (NoEscape && !_scalar_replaceable) in cases where not escaped objects can't be scalar replaced because of flow-insensitive analysis limitations. It is preparation for 7105605 changes. Split adjust_escape_state() method into two. New find_init_values() method is used to find fields initializing values for not escaped allocations. It is called before deferred edges are removed since it affects results. adjust_escape_state() now is called after all deferred edges are removed to get correct results. Factored out escape state propagation code into new method propagate_escape_state(). Removed methods is_scalar_replaceable() and hidden_alias() which are not used and corresponding fields in PointsToNode (which will reduce used memory). Tested with CTW, jtreg, NSK, refworkload. Thanks, Vladimir From tom.rodriguez at oracle.com Tue Nov 1 12:45:51 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 1 Nov 2011 12:45:51 -0700 Subject: Request for reviews (M): 7059047: EA: can't find initializing store with several CheckCastPP In-Reply-To: <4EB03D3C.7000708@oracle.com> References: <4EB03D3C.7000708@oracle.com> Message-ID: I'm not sure I follow the distinction that's being made with ControlEscape, or ArgEscape for that matter. They seem to be about what optimizations we can do on an object more than whether they are escaping or not, which makes the naming confusing. Or am I misunderstand what's happening? Is this how they would be translated? NoEscape == ScalarReplaceable ControlEscape == NonEscaping ArgEscape == LocallyEscaping GlobalEscape == GlobalEcaping Would be it be possible to come up with more descriptive names for these states? Why is has_non_escaping_obj assigned to twice? // mark all nodes reachable from ArgEscape nodes ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, &worklist, PointsToNode::ArgEscape); ! // mark all nodes reachable from ControlEscape nodes ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, &worklist, PointsToNode::ControlEscape); Should the second one be |=? Do we eliminate locking on ControlEscape objects? tom On Nov 1, 2011, at 11:41 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7059047/webrev > > 7059047: EA: can't find initializing store with several CheckCastPP > > Added new escape state: ControlEscape. Use it instead of ArgEscape and (NoEscape && !_scalar_replaceable) in cases where not escaped objects can't be scalar replaced because of flow-insensitive analysis limitations. It is preparation for 7105605 changes. > > Split adjust_escape_state() method into two. New find_init_values() method is used to find fields initializing values for not escaped allocations. It is called before deferred edges are removed since it affects results. adjust_escape_state() now is called after all deferred edges are removed to get correct results. > > Factored out escape state propagation code into new method propagate_escape_state(). > > Removed methods is_scalar_replaceable() and hidden_alias() which are not used and corresponding fields in PointsToNode (which will reduce used memory). > > Tested with CTW, jtreg, NSK, refworkload. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Nov 1 13:59:18 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Nov 2011 13:59:18 -0700 Subject: Request for reviews (M): 7059047: EA: can't find initializing store with several CheckCastPP In-Reply-To: References: <4EB03D3C.7000708@oracle.com> Message-ID: <4EB05DA6.60504@oracle.com> Thank you, Tom Tom Rodriguez wrote: > I'm not sure I follow the distinction that's being made with ControlEscape, or ArgEscape for that matter. They seem to be about what optimizations we can do on an object more than whether they are escaping or not, which makes the naming confusing. Or am I misunderstand what's happening? Is this how they would be translated? > > NoEscape == ScalarReplaceable > ControlEscape == NonEscaping > ArgEscape == LocallyEscaping > GlobalEscape == GlobalEcaping Your translation is correct. Yes, the states define optimizations we can do with objects. > Would be it be possible to come up with more descriptive names for these states? How about your translation names? > > Why is has_non_escaping_obj assigned to twice? > > // mark all nodes reachable from ArgEscape nodes > ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, &worklist, PointsToNode::ArgEscape); > > ! // mark all nodes reachable from ControlEscape nodes > ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, &worklist, PointsToNode::ControlEscape); > > Should the second one be |=? You are right. My bad. > > Do we eliminate locking on ControlEscape objects? Yes, the same as ArgEscape. I will add code for 7105605 to fold CmpP for NoEscape and ControlEscape objects. I don't think it will be safe to do for ArgEscape. An other optimization I am thinking for ControlEscape objects is eliminating loads from it as we do for ScalarReplaceable objects. Thanks, Vladimir > > tom > > On Nov 1, 2011, at 11:41 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7059047/webrev >> >> 7059047: EA: can't find initializing store with several CheckCastPP >> >> Added new escape state: ControlEscape. Use it instead of ArgEscape and (NoEscape && !_scalar_replaceable) in cases where not escaped objects can't be scalar replaced because of flow-insensitive analysis limitations. It is preparation for 7105605 changes. >> >> Split adjust_escape_state() method into two. New find_init_values() method is used to find fields initializing values for not escaped allocations. It is called before deferred edges are removed since it affects results. adjust_escape_state() now is called after all deferred edges are removed to get correct results. >> >> Factored out escape state propagation code into new method propagate_escape_state(). >> >> Removed methods is_scalar_replaceable() and hidden_alias() which are not used and corresponding fields in PointsToNode (which will reduce used memory). >> >> Tested with CTW, jtreg, NSK, refworkload. >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Tue Nov 1 14:21:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 1 Nov 2011 14:21:32 -0700 Subject: Request for reviews (M): 7059047: EA: can't find initializing store with several CheckCastPP In-Reply-To: <4EB05DA6.60504@oracle.com> References: <4EB03D3C.7000708@oracle.com> <4EB05DA6.60504@oracle.com> Message-ID: <38F4BC13-4733-44C0-BC40-96F9D82E53E5@oracle.com> On Nov 1, 2011, at 1:59 PM, Vladimir Kozlov wrote: > Thank you, Tom > > Tom Rodriguez wrote: >> I'm not sure I follow the distinction that's being made with ControlEscape, or ArgEscape for that matter. They seem to be about what optimizations we can do on an object more than whether they are escaping or not, which makes the naming confusing. Or am I misunderstand what's happening? Is this how they would be translated? >> NoEscape == ScalarReplaceable >> ControlEscape == NonEscaping >> ArgEscape == LocallyEscaping >> GlobalEscape == GlobalEcaping > > Your translation is correct. Yes, the states define optimizations we can do with objects. > >> Would be it be possible to come up with more descriptive names for these states? > > How about your translation names? I'm happy with them of course but I wasn't sure they were accurate. Some comments explaining the distinction would be helpful too. In thinking about this some more, I'm wondering whether it's right to introduce this new state. What was wrong with the old scalar_replaceable flag? It feels to me like we have two distinct axes that we're trying to shove into a single number, which complicates the terminology for it. > >> Why is has_non_escaping_obj assigned to twice? >> // mark all nodes reachable from ArgEscape nodes >> ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, &worklist, PointsToNode::ArgEscape); >> ! // mark all nodes reachable from ControlEscape nodes >> ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, &worklist, PointsToNode::ControlEscape); >> Should the second one be |=? > > You are right. My bad. > >> Do we eliminate locking on ControlEscape objects? > > Yes, the same as ArgEscape. > > I will add code for 7105605 to fold CmpP for NoEscape and ControlEscape objects. I don't think it will be safe to do for ArgEscape. Right, because ArgEscape means that we've lost track of identity because of aliasing? > > An other optimization I am thinking for ControlEscape objects is eliminating loads from it as we do for ScalarReplaceable objects. That seems good, though that might change how we name the states. NoEscape means all optimizations and elimination of allocation, ControlEscape just means we can't eliminate the allocation but we can do other allocations. Maybe the NoEscape shouldn't be renamed ScalarReplaceable then? tom > > Thanks, > Vladimir > >> tom >> On Nov 1, 2011, at 11:41 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7059047/webrev >>> >>> 7059047: EA: can't find initializing store with several CheckCastPP >>> >>> Added new escape state: ControlEscape. Use it instead of ArgEscape and (NoEscape && !_scalar_replaceable) in cases where not escaped objects can't be scalar replaced because of flow-insensitive analysis limitations. It is preparation for 7105605 changes. >>> >>> Split adjust_escape_state() method into two. New find_init_values() method is used to find fields initializing values for not escaped allocations. It is called before deferred edges are removed since it affects results. adjust_escape_state() now is called after all deferred edges are removed to get correct results. >>> >>> Factored out escape state propagation code into new method propagate_escape_state(). >>> >>> Removed methods is_scalar_replaceable() and hidden_alias() which are not used and corresponding fields in PointsToNode (which will reduce used memory). >>> >>> Tested with CTW, jtreg, NSK, refworkload. >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Tue Nov 1 17:58:24 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Nov 2011 17:58:24 -0700 Subject: Request for reviews (M): 7059047: EA: can't find initializing store with several CheckCastPP In-Reply-To: <38F4BC13-4733-44C0-BC40-96F9D82E53E5@oracle.com> References: <4EB03D3C.7000708@oracle.com> <4EB05DA6.60504@oracle.com> <38F4BC13-4733-44C0-BC40-96F9D82E53E5@oracle.com> Message-ID: <4EB095B0.4080409@oracle.com> Nothing was wrong with scalar_replaceable flag except it was not propagated to referenced objects so ArgEscape state was used in such cases. But I see what you are concern about. The escape state type should be pure escape state and applicable optimizations should be controlled by separate flag. OK, I returned back scalar_replaceable flag and 3 original escape states: http://cr.openjdk.java.net/~kvn/7059047/webrev.02 > Right, because ArgEscape means that we've lost track of identity because of aliasing? Correct. Thanks, Vladimir Tom Rodriguez wrote: > On Nov 1, 2011, at 1:59 PM, Vladimir Kozlov wrote: > >> Thank you, Tom >> >> Tom Rodriguez wrote: >>> I'm not sure I follow the distinction that's being made with ControlEscape, or ArgEscape for that matter. They seem to be about what optimizations we can do on an object more than whether they are escaping or not, which makes the naming confusing. Or am I misunderstand what's happening? Is this how they would be translated? >>> NoEscape == ScalarReplaceable >>> ControlEscape == NonEscaping >>> ArgEscape == LocallyEscaping >>> GlobalEscape == GlobalEcaping >> Your translation is correct. Yes, the states define optimizations we can do with objects. >> >>> Would be it be possible to come up with more descriptive names for these states? >> How about your translation names? > > I'm happy with them of course but I wasn't sure they were accurate. Some comments explaining the distinction would be helpful too. > > In thinking about this some more, I'm wondering whether it's right to introduce this new state. What was wrong with the old scalar_replaceable flag? It feels to me like we have two distinct axes that we're trying to shove into a single number, which complicates the terminology for it. > >>> Why is has_non_escaping_obj assigned to twice? >>> // mark all nodes reachable from ArgEscape nodes >>> ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, &worklist, PointsToNode::ArgEscape); >>> ! // mark all nodes reachable from ControlEscape nodes >>> ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, &worklist, PointsToNode::ControlEscape); >>> Should the second one be |=? >> You are right. My bad. >> >>> Do we eliminate locking on ControlEscape objects? >> Yes, the same as ArgEscape. >> >> I will add code for 7105605 to fold CmpP for NoEscape and ControlEscape objects. I don't think it will be safe to do for ArgEscape. > > Right, because ArgEscape means that we've lost track of identity because of aliasing? > >> An other optimization I am thinking for ControlEscape objects is eliminating loads from it as we do for ScalarReplaceable objects. > > That seems good, though that might change how we name the states. NoEscape means all optimizations and elimination of allocation, ControlEscape just means we can't eliminate the allocation but we can do other allocations. Maybe the NoEscape shouldn't be renamed ScalarReplaceable then? > > tom > >> Thanks, >> Vladimir >> >>> tom >>> On Nov 1, 2011, at 11:41 AM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7059047/webrev >>>> >>>> 7059047: EA: can't find initializing store with several CheckCastPP >>>> >>>> Added new escape state: ControlEscape. Use it instead of ArgEscape and (NoEscape && !_scalar_replaceable) in cases where not escaped objects can't be scalar replaced because of flow-insensitive analysis limitations. It is preparation for 7105605 changes. >>>> >>>> Split adjust_escape_state() method into two. New find_init_values() method is used to find fields initializing values for not escaped allocations. It is called before deferred edges are removed since it affects results. adjust_escape_state() now is called after all deferred edges are removed to get correct results. >>>> >>>> Factored out escape state propagation code into new method propagate_escape_state(). >>>> >>>> Removed methods is_scalar_replaceable() and hidden_alias() which are not used and corresponding fields in PointsToNode (which will reduce used memory). >>>> >>>> Tested with CTW, jtreg, NSK, refworkload. >>>> >>>> Thanks, >>>> Vladimir > From tom.rodriguez at oracle.com Tue Nov 1 20:32:28 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 1 Nov 2011 20:32:28 -0700 Subject: AMD64: JVM crashes during uncommon_trap_blob and deopt_blob In-Reply-To: <995C578C-FEDA-4313-A2FC-B2728F4AA216@oracle.com> References: <995C578C-FEDA-4313-A2FC-B2728F4AA216@oracle.com> Message-ID: <11377B22-1417-4542-B764-E19E157E9983@oracle.com> >> >> The fix aligns the stack pointer as required by x64 ABI before calling into the VM. It fixes the uncommon_trap_blob as well as the deopt_blob. Few adjustments have to be made: >> Since due to the aligned SP the runtime cannot easily retrieve the return PC any more we have to store it into the last java frame as well and adapt the call site's oop map accordingly. The deoptimization blob does SP-relative addressing after the runtime call, so we have to restore the unaligned SP before doing this using the stored value. > > Thanks for sending this in. I think your change looks good, though the imprecision of the last_pc slightly bugs me. We could conceivably fix it up after emitting the actual call but that seems too clever for this problem. I'll take your bits and run some of our deopt tests on it and see how it looks. I ran deoptimizealot testing on these changes along with an adhoc test to check for proper stack alignment. It failed immediately before you changes and passed with them. I'm going to go ahead and push your changes and I'll file a separate bug to add a more systematic check for proper alignment when coming in from generated code. We've mainly fixed these as we've found them but it should be cleaned up. A webrev with commit message is at http://cr.openjdk.java.net/~never/6636110. Thanks! tom > > tom > >> >> Best regards, >> Andreas >> >> > From andreas.schoesser at sap.com Wed Nov 2 02:59:02 2011 From: andreas.schoesser at sap.com (=?ISO-8859-1?Q?Andreas_Sch=F6sser?=) Date: Wed, 02 Nov 2011 10:59:02 +0100 Subject: AMD64: JVM crashes during uncommon_trap_blob and deopt_blob In-Reply-To: <11377B22-1417-4542-B764-E19E157E9983@oracle.com> References: <995C578C-FEDA-4313-A2FC-B2728F4AA216@oracle.com> <11377B22-1417-4542-B764-E19E157E9983@oracle.com> Message-ID: <4EB11466.1040703@sap.com> Hi Tom, thanks for checking and pushing this! Best regards, Andreas Am 02.11.2011 04:32, schrieb Tom Rodriguez: >>> >>> The fix aligns the stack pointer as required by x64 ABI before calling into the VM. It fixes the uncommon_trap_blob as well as the deopt_blob. Few adjustments have to be made: >>> Since due to the aligned SP the runtime cannot easily retrieve the return PC any more we have to store it into the last java frame as well and adapt the call site's oop map accordingly. The deoptimization blob does SP-relative addressing after the runtime call, so we have to restore the unaligned SP before doing this using the stored value. >> >> Thanks for sending this in. I think your change looks good, though the imprecision of the last_pc slightly bugs me. We could conceivably fix it up after emitting the actual call but that seems too clever for this problem. I'll take your bits and run some of our deopt tests on it and see how it looks. > > I ran deoptimizealot testing on these changes along with an adhoc test to check for proper stack alignment. It failed immediately before you changes and passed with them. I'm going to go ahead and push your changes and I'll file a separate bug to add a more systematic check for proper alignment when coming in from generated code. We've mainly fixed these as we've found them but it should be cleaned up. A webrev with commit message is at http://cr.openjdk.java.net/~never/6636110. Thanks! > > tom > >> >> tom >> >>> >>> Best regards, >>> Andreas >>> >>> >> > From christian.thalinger at oracle.com Wed Nov 2 07:03:33 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Nov 2011 15:03:33 +0100 Subject: Request for reviews (XS): 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result Message-ID: <82C62981-C163-412D-B99B-9A869DBA9A10@oracle.com> http://cr.openjdk.java.net/~twisti/7106774/ 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result Reviewed-by: The problem is in code which was added with 7090904 that checks if the call site is a method handle invoke. The new code uses Bytecode::code() and compares the result to Bytecodes values: if (cur.code() == Bytecodes::_invokedynamic || (cur.code() == Bytecodes::_invokevirtual && But an invokevirtual can be quickened so that the resulting Bytecode is a different one: (dbx) n t at 2 (l at 2) stopped in Deoptimization::fetch_unroll_info_helper at line 393 in file "deoptimization.cpp" 393 if (cur.code() == Bytecodes::_invokedynamic || (dbx) p cur.code() cur.code() = _fast_invokevfinal The fix is to use Bytecode_invoke::is_invokevirtual() and is_invokedynamic() which use Bytecode::java_code(). Tested with failing test case. src/share/vm/interpreter/bytecode.hpp src/share/vm/runtime/deoptimization.cpp From christian.thalinger at oracle.com Wed Nov 2 08:53:43 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Nov 2011 16:53:43 +0100 Subject: Request for reviews (XS): 7106944: assert(_pc == *pc_addr) failed may be too strong Message-ID: http://cr.openjdk.java.net/~twisti/7106944/ 7106944: assert(_pc == *pc_addr) failed may be too strong Reviewed-by: Sometimes we are already deoptimizing a frame when we request another deoptimization of the same frame. This makes the assert to fail. The fix is to add a check to the assert that the return address is the same that we are going to patch. src/cpu/x86/vm/frame_x86.cpp From tom.rodriguez at oracle.com Wed Nov 2 10:01:49 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 2 Nov 2011 10:01:49 -0700 Subject: Request for reviews (XS): 7106944: assert(_pc == *pc_addr) failed may be too strong In-Reply-To: References: Message-ID: <582E8EEB-2239-4850-8BDC-E6C065B1085B@oracle.com> Looks good. tom On Nov 2, 2011, at 8:53 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7106944/ > > 7106944: assert(_pc == *pc_addr) failed may be too strong > Reviewed-by: > > Sometimes we are already deoptimizing a frame when we request another > deoptimization of the same frame. This makes the assert to fail. > > The fix is to add a check to the assert that the return address is the > same that we are going to patch. > > src/cpu/x86/vm/frame_x86.cpp > From vladimir.kozlov at oracle.com Wed Nov 2 10:04:05 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Nov 2011 10:04:05 -0700 Subject: AMD64: JVM crashes during uncommon_trap_blob and deopt_blob In-Reply-To: <11377B22-1417-4542-B764-E19E157E9983@oracle.com> References: <995C578C-FEDA-4313-A2FC-B2728F4AA216@oracle.com> <11377B22-1417-4542-B764-E19E157E9983@oracle.com> Message-ID: <4EB17805.3060400@oracle.com> Tom, Changes look good. thanks, Vladimir On 11/1/11 8:32 PM, Tom Rodriguez wrote: >>> >>> The fix aligns the stack pointer as required by x64 ABI before calling into the VM. It fixes the uncommon_trap_blob as well as the deopt_blob. Few adjustments have to be made: >>> Since due to the aligned SP the runtime cannot easily retrieve the return PC any more we have to store it into the last java frame as well and adapt the call site's oop map accordingly. The deoptimization blob does SP-relative addressing after the runtime call, so we have to restore the unaligned SP before doing this using the stored value. >> >> Thanks for sending this in. I think your change looks good, though the imprecision of the last_pc slightly bugs me. We could conceivably fix it up after emitting the actual call but that seems too clever for this problem. I'll take your bits and run some of our deopt tests on it and see how it looks. > > I ran deoptimizealot testing on these changes along with an adhoc test to check for proper stack alignment. It failed immediately before you changes and passed with them. I'm going to go ahead and push your changes and I'll file a separate bug to add a more systematic check for proper alignment when coming in from generated code. We've mainly fixed these as we've found them but it should be cleaned up. A webrev with commit message is at http://cr.openjdk.java.net/~never/6636110. Thanks! > > tom > >> >> tom >> >>> >>> Best regards, >>> Andreas >>> >>> >> > From vladimir.kozlov at oracle.com Wed Nov 2 10:08:08 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Nov 2011 10:08:08 -0700 Subject: Request for reviews (XS): 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result In-Reply-To: <82C62981-C163-412D-B99B-9A869DBA9A10@oracle.com> References: <82C62981-C163-412D-B99B-9A869DBA9A10@oracle.com> Message-ID: <4EB178F8.2050403@oracle.com> Looks good. Vladimir On 11/2/11 7:03 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7106774/ > > 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result > Reviewed-by: > > The problem is in code which was added with 7090904 that checks if the > call site is a method handle invoke. The new code uses > Bytecode::code() and compares the result to Bytecodes values: > > if (cur.code() == Bytecodes::_invokedynamic || > (cur.code() == Bytecodes::_invokevirtual&& > > But an invokevirtual can be quickened so that the resulting Bytecode > is a different one: > > (dbx) n > t at 2 (l at 2) stopped in Deoptimization::fetch_unroll_info_helper at line 393 in file "deoptimization.cpp" > 393 if (cur.code() == Bytecodes::_invokedynamic || > (dbx) p cur.code() > cur.code() = _fast_invokevfinal > > The fix is to use Bytecode_invoke::is_invokevirtual() and > is_invokedynamic() which use Bytecode::java_code(). > > Tested with failing test case. > > src/share/vm/interpreter/bytecode.hpp > src/share/vm/runtime/deoptimization.cpp > From vladimir.kozlov at oracle.com Wed Nov 2 10:22:55 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Nov 2011 10:22:55 -0700 Subject: Request for reviews (XS): 7106944: assert(_pc == *pc_addr) failed may be too strong In-Reply-To: <582E8EEB-2239-4850-8BDC-E6C065B1085B@oracle.com> References: <582E8EEB-2239-4850-8BDC-E6C065B1085B@oracle.com> Message-ID: <4EB17C6F.2050000@oracle.com> Yes, it looks good. But, Christian, can you show (call stack?) how we endup deoptimizing twice? How we enter deoptimization code twice? Thanks, Vladimir On 11/2/11 10:01 AM, Tom Rodriguez wrote: > Looks good. > > tom > > On Nov 2, 2011, at 8:53 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7106944/ >> >> 7106944: assert(_pc == *pc_addr) failed may be too strong >> Reviewed-by: >> >> Sometimes we are already deoptimizing a frame when we request another >> deoptimization of the same frame. This makes the assert to fail. >> >> The fix is to add a check to the assert that the return address is the >> same that we are going to patch. >> >> src/cpu/x86/vm/frame_x86.cpp >> > From tom.rodriguez at oracle.com Wed Nov 2 12:26:10 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 2 Nov 2011 12:26:10 -0700 Subject: Request for reviews (XS): 7106944: assert(_pc == *pc_addr) failed may be too strong In-Reply-To: <4EB17C6F.2050000@oracle.com> References: <582E8EEB-2239-4850-8BDC-E6C065B1085B@oracle.com> <4EB17C6F.2050000@oracle.com> Message-ID: On Nov 2, 2011, at 10:22 AM, Vladimir Kozlov wrote: > Yes, it looks good. But, Christian, can you show (call stack?) how we endup deoptimizing twice? How we enter deoptimization code twice? I think it's biased locking revocation. Here's the assertion point: V [libjvm.so+0x2701328] void VMError::report(outputStream*)+0x8c8 V [libjvm.so+0x2702469] void VMError::report_and_die()+0x4fd V [libjvm.so+0xe869bf] void report_vm_error(const char*,int,const char*,const char*)+0x55f V [libjvm.so+0xff8666] void frame::patch_pc(Thread*,unsigned char*)+0xe6 V [libjvm.so+0xfe6e8d] void frame::deoptimize(JavaThread*)+0x361 V [libjvm.so+0xed9622] void Deoptimization::deoptimize_frame(JavaThread*,long*)+0x55e V [libjvm.so+0xa34674] void deopt_caller()+0x154 V [libjvm.so+0xa35974] void Runtime1::new_type_array(JavaThread*,klassOopDesc*,int)+0x3c4 deopt_caller has a check for the caller already being deopted: static bool caller_is_deopted() { JavaThread* thread = JavaThread::current(); RegisterMap reg_map(thread, false); frame runtime_frame = thread->last_frame(); frame caller_frame = runtime_frame.sender(®_map); assert(caller_frame.is_compiled_frame(), "must be compiled"); return caller_frame.is_deoptimized_frame(); } // Stress deoptimization static void deopt_caller() { if ( !caller_is_deopted()) { JavaThread* thread = JavaThread::current(); RegisterMap reg_map(thread, false); frame runtime_frame = thread->last_frame(); frame caller_frame = runtime_frame.sender(®_map); Deoptimization::deoptimize_frame(thread, caller_frame.id()); assert(caller_is_deopted(), "Must be deoptimized"); } } but down in deoptimize we may revoke biases at a safepoint: if (UseBiasedLocking) { revoke_biases_of_monitors(thread, fr, map); } deoptimize_single_frame(thread, fr); This allows a deopt to occur during the safepoint, after the initial guard. tom > > Thanks, > Vladimir > > On 11/2/11 10:01 AM, Tom Rodriguez wrote: >> Looks good. >> >> tom >> >> On Nov 2, 2011, at 8:53 AM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/7106944/ >>> >>> 7106944: assert(_pc == *pc_addr) failed may be too strong >>> Reviewed-by: >>> >>> Sometimes we are already deoptimizing a frame when we request another >>> deoptimization of the same frame. This makes the assert to fail. >>> >>> The fix is to add a check to the assert that the return address is the >>> same that we are going to patch. >>> >>> src/cpu/x86/vm/frame_x86.cpp >>> >> From vladimir.kozlov at oracle.com Wed Nov 2 12:54:58 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Nov 2011 12:54:58 -0700 Subject: Request for reviews (XS): 7106944: assert(_pc == *pc_addr) failed may be too strong In-Reply-To: References: <582E8EEB-2239-4850-8BDC-E6C065B1085B@oracle.com> <4EB17C6F.2050000@oracle.com> Message-ID: <4EB1A012.9080203@oracle.com> Should we then check that the frame is deoptimized already and bailout after revoke_biases_of_monitors() call? I surprise we did not hit any problems before by deoptimizing frame twice. Vladimir Tom Rodriguez wrote: > On Nov 2, 2011, at 10:22 AM, Vladimir Kozlov wrote: > >> Yes, it looks good. But, Christian, can you show (call stack?) how we endup deoptimizing twice? How we enter deoptimization code twice? > > I think it's biased locking revocation. Here's the assertion point: > > V [libjvm.so+0x2701328] void VMError::report(outputStream*)+0x8c8 > V [libjvm.so+0x2702469] void VMError::report_and_die()+0x4fd > V [libjvm.so+0xe869bf] void report_vm_error(const char*,int,const char*,const char*)+0x55f > V [libjvm.so+0xff8666] void frame::patch_pc(Thread*,unsigned char*)+0xe6 > V [libjvm.so+0xfe6e8d] void frame::deoptimize(JavaThread*)+0x361 > V [libjvm.so+0xed9622] void Deoptimization::deoptimize_frame(JavaThread*,long*)+0x55e > V [libjvm.so+0xa34674] void deopt_caller()+0x154 > V [libjvm.so+0xa35974] void Runtime1::new_type_array(JavaThread*,klassOopDesc*,int)+0x3c4 > > deopt_caller has a check for the caller already being deopted: > > static bool caller_is_deopted() { > JavaThread* thread = JavaThread::current(); > RegisterMap reg_map(thread, false); > frame runtime_frame = thread->last_frame(); > frame caller_frame = runtime_frame.sender(®_map); > assert(caller_frame.is_compiled_frame(), "must be compiled"); > return caller_frame.is_deoptimized_frame(); > } > > // Stress deoptimization > static void deopt_caller() { > if ( !caller_is_deopted()) { > JavaThread* thread = JavaThread::current(); > RegisterMap reg_map(thread, false); > frame runtime_frame = thread->last_frame(); > frame caller_frame = runtime_frame.sender(®_map); > Deoptimization::deoptimize_frame(thread, caller_frame.id()); > assert(caller_is_deopted(), "Must be deoptimized"); > } > } > > but down in deoptimize we may revoke biases at a safepoint: > > if (UseBiasedLocking) { > revoke_biases_of_monitors(thread, fr, map); > } > deoptimize_single_frame(thread, fr); > > This allows a deopt to occur during the safepoint, after the initial guard. > > tom > >> Thanks, >> Vladimir >> >> On 11/2/11 10:01 AM, Tom Rodriguez wrote: >>> Looks good. >>> >>> tom >>> >>> On Nov 2, 2011, at 8:53 AM, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/7106944/ >>>> >>>> 7106944: assert(_pc == *pc_addr) failed may be too strong >>>> Reviewed-by: >>>> >>>> Sometimes we are already deoptimizing a frame when we request another >>>> deoptimization of the same frame. This makes the assert to fail. >>>> >>>> The fix is to add a check to the assert that the return address is the >>>> same that we are going to patch. >>>> >>>> src/cpu/x86/vm/frame_x86.cpp >>>> > From tom.rodriguez at oracle.com Wed Nov 2 13:04:52 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 2 Nov 2011 13:04:52 -0700 Subject: Request for reviews (XS): 7106944: assert(_pc == *pc_addr) failed may be too strong In-Reply-To: <4EB1A012.9080203@oracle.com> References: <582E8EEB-2239-4850-8BDC-E6C065B1085B@oracle.com> <4EB17C6F.2050000@oracle.com> <4EB1A012.9080203@oracle.com> Message-ID: <08B8D2C2-7DF7-45F1-BF4C-9810E73B3C71@oracle.com> On Nov 2, 2011, at 12:54 PM, Vladimir Kozlov wrote: > Should we then check that the frame is deoptimized already and bailout after revoke_biases_of_monitors() call? I surprise we did not hit any problems before by deoptimizing frame twice. We could but I'm not sure I see the point. I think the existing guards are just about avoiding needless work more than anything. tom > > Vladimir > > Tom Rodriguez wrote: >> On Nov 2, 2011, at 10:22 AM, Vladimir Kozlov wrote: >>> Yes, it looks good. But, Christian, can you show (call stack?) how we endup deoptimizing twice? How we enter deoptimization code twice? >> I think it's biased locking revocation. Here's the assertion point: >> V [libjvm.so+0x2701328] void VMError::report(outputStream*)+0x8c8 >> V [libjvm.so+0x2702469] void VMError::report_and_die()+0x4fd >> V [libjvm.so+0xe869bf] void report_vm_error(const char*,int,const char*,const char*)+0x55f >> V [libjvm.so+0xff8666] void frame::patch_pc(Thread*,unsigned char*)+0xe6 >> V [libjvm.so+0xfe6e8d] void frame::deoptimize(JavaThread*)+0x361 >> V [libjvm.so+0xed9622] void Deoptimization::deoptimize_frame(JavaThread*,long*)+0x55e >> V [libjvm.so+0xa34674] void deopt_caller()+0x154 >> V [libjvm.so+0xa35974] void Runtime1::new_type_array(JavaThread*,klassOopDesc*,int)+0x3c4 >> deopt_caller has a check for the caller already being deopted: >> static bool caller_is_deopted() { >> JavaThread* thread = JavaThread::current(); >> RegisterMap reg_map(thread, false); >> frame runtime_frame = thread->last_frame(); >> frame caller_frame = runtime_frame.sender(®_map); >> assert(caller_frame.is_compiled_frame(), "must be compiled"); >> return caller_frame.is_deoptimized_frame(); >> } >> // Stress deoptimization static void deopt_caller() { >> if ( !caller_is_deopted()) { >> JavaThread* thread = JavaThread::current(); >> RegisterMap reg_map(thread, false); >> frame runtime_frame = thread->last_frame(); >> frame caller_frame = runtime_frame.sender(®_map); >> Deoptimization::deoptimize_frame(thread, caller_frame.id()); >> assert(caller_is_deopted(), "Must be deoptimized"); >> } >> } >> but down in deoptimize we may revoke biases at a safepoint: >> if (UseBiasedLocking) { >> revoke_biases_of_monitors(thread, fr, map); >> } >> deoptimize_single_frame(thread, fr); >> This allows a deopt to occur during the safepoint, after the initial guard. >> tom >>> Thanks, >>> Vladimir >>> >>> On 11/2/11 10:01 AM, Tom Rodriguez wrote: >>>> Looks good. >>>> >>>> tom >>>> >>>> On Nov 2, 2011, at 8:53 AM, Christian Thalinger wrote: >>>> >>>>> http://cr.openjdk.java.net/~twisti/7106944/ >>>>> >>>>> 7106944: assert(_pc == *pc_addr) failed may be too strong >>>>> Reviewed-by: >>>>> >>>>> Sometimes we are already deoptimizing a frame when we request another >>>>> deoptimization of the same frame. This makes the assert to fail. >>>>> >>>>> The fix is to add a check to the assert that the return address is the >>>>> same that we are going to patch. >>>>> >>>>> src/cpu/x86/vm/frame_x86.cpp >>>>> From vladimir.kozlov at oracle.com Wed Nov 2 13:09:11 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Nov 2011 13:09:11 -0700 Subject: Request for reviews (XS): 7106944: assert(_pc == *pc_addr) failed may be too strong In-Reply-To: <08B8D2C2-7DF7-45F1-BF4C-9810E73B3C71@oracle.com> References: <582E8EEB-2239-4850-8BDC-E6C065B1085B@oracle.com> <4EB17C6F.2050000@oracle.com> <4EB1A012.9080203@oracle.com> <08B8D2C2-7DF7-45F1-BF4C-9810E73B3C71@oracle.com> Message-ID: <4EB1A367.2020908@oracle.com> I see, the only work frame::deoptimize() does is patching PC. OK then. Thanks, Vladimir Tom Rodriguez wrote: > On Nov 2, 2011, at 12:54 PM, Vladimir Kozlov wrote: > >> Should we then check that the frame is deoptimized already and bailout after revoke_biases_of_monitors() call? I surprise we did not hit any problems before by deoptimizing frame twice. > > We could but I'm not sure I see the point. I think the existing guards are just about avoiding needless work more than anything. > > tom > >> Vladimir >> >> Tom Rodriguez wrote: >>> On Nov 2, 2011, at 10:22 AM, Vladimir Kozlov wrote: >>>> Yes, it looks good. But, Christian, can you show (call stack?) how we endup deoptimizing twice? How we enter deoptimization code twice? >>> I think it's biased locking revocation. Here's the assertion point: >>> V [libjvm.so+0x2701328] void VMError::report(outputStream*)+0x8c8 >>> V [libjvm.so+0x2702469] void VMError::report_and_die()+0x4fd >>> V [libjvm.so+0xe869bf] void report_vm_error(const char*,int,const char*,const char*)+0x55f >>> V [libjvm.so+0xff8666] void frame::patch_pc(Thread*,unsigned char*)+0xe6 >>> V [libjvm.so+0xfe6e8d] void frame::deoptimize(JavaThread*)+0x361 >>> V [libjvm.so+0xed9622] void Deoptimization::deoptimize_frame(JavaThread*,long*)+0x55e >>> V [libjvm.so+0xa34674] void deopt_caller()+0x154 >>> V [libjvm.so+0xa35974] void Runtime1::new_type_array(JavaThread*,klassOopDesc*,int)+0x3c4 >>> deopt_caller has a check for the caller already being deopted: >>> static bool caller_is_deopted() { >>> JavaThread* thread = JavaThread::current(); >>> RegisterMap reg_map(thread, false); >>> frame runtime_frame = thread->last_frame(); >>> frame caller_frame = runtime_frame.sender(®_map); >>> assert(caller_frame.is_compiled_frame(), "must be compiled"); >>> return caller_frame.is_deoptimized_frame(); >>> } >>> // Stress deoptimization static void deopt_caller() { >>> if ( !caller_is_deopted()) { >>> JavaThread* thread = JavaThread::current(); >>> RegisterMap reg_map(thread, false); >>> frame runtime_frame = thread->last_frame(); >>> frame caller_frame = runtime_frame.sender(®_map); >>> Deoptimization::deoptimize_frame(thread, caller_frame.id()); >>> assert(caller_is_deopted(), "Must be deoptimized"); >>> } >>> } >>> but down in deoptimize we may revoke biases at a safepoint: >>> if (UseBiasedLocking) { >>> revoke_biases_of_monitors(thread, fr, map); >>> } >>> deoptimize_single_frame(thread, fr); >>> This allows a deopt to occur during the safepoint, after the initial guard. >>> tom >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/2/11 10:01 AM, Tom Rodriguez wrote: >>>>> Looks good. >>>>> >>>>> tom >>>>> >>>>> On Nov 2, 2011, at 8:53 AM, Christian Thalinger wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~twisti/7106944/ >>>>>> >>>>>> 7106944: assert(_pc == *pc_addr) failed may be too strong >>>>>> Reviewed-by: >>>>>> >>>>>> Sometimes we are already deoptimizing a frame when we request another >>>>>> deoptimization of the same frame. This makes the assert to fail. >>>>>> >>>>>> The fix is to add a check to the assert that the return address is the >>>>>> same that we are going to patch. >>>>>> >>>>>> src/cpu/x86/vm/frame_x86.cpp >>>>>> > From christian.thalinger at oracle.com Thu Nov 3 01:40:29 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Nov 2011 09:40:29 +0100 Subject: Request for reviews (XS): 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result In-Reply-To: <4EB178F8.2050403@oracle.com> References: <82C62981-C163-412D-B99B-9A869DBA9A10@oracle.com> <4EB178F8.2050403@oracle.com> Message-ID: Thank you, Vladimir. -- Chris On Nov 2, 2011, at 6:08 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 11/2/11 7:03 AM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7106774/ >> >> 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result >> Reviewed-by: >> >> The problem is in code which was added with 7090904 that checks if the >> call site is a method handle invoke. The new code uses >> Bytecode::code() and compares the result to Bytecodes values: >> >> if (cur.code() == Bytecodes::_invokedynamic || >> (cur.code() == Bytecodes::_invokevirtual&& >> >> But an invokevirtual can be quickened so that the resulting Bytecode >> is a different one: >> >> (dbx) n >> t at 2 (l at 2) stopped in Deoptimization::fetch_unroll_info_helper at line 393 in file "deoptimization.cpp" >> 393 if (cur.code() == Bytecodes::_invokedynamic || >> (dbx) p cur.code() >> cur.code() = _fast_invokevfinal >> >> The fix is to use Bytecode_invoke::is_invokevirtual() and >> is_invokedynamic() which use Bytecode::java_code(). >> >> Tested with failing test case. >> >> src/share/vm/interpreter/bytecode.hpp >> src/share/vm/runtime/deoptimization.cpp >> From christian.thalinger at oracle.com Thu Nov 3 01:43:46 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Nov 2011 09:43:46 +0100 Subject: Request for reviews (XS): 7106944: assert(_pc == *pc_addr) failed may be too strong In-Reply-To: <4EB1A367.2020908@oracle.com> References: <582E8EEB-2239-4850-8BDC-E6C065B1085B@oracle.com> <4EB17C6F.2050000@oracle.com> <4EB1A012.9080203@oracle.com> <08B8D2C2-7DF7-45F1-BF4C-9810E73B3C71@oracle.com> <4EB1A367.2020908@oracle.com> Message-ID: <356B1EE8-CE92-4DE8-B5BA-90320785DBE0@oracle.com> Thank you, Tom and Vladimir. -- Chris On Nov 2, 2011, at 9:09 PM, Vladimir Kozlov wrote: > I see, the only work frame::deoptimize() does is patching PC. OK then. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Nov 2, 2011, at 12:54 PM, Vladimir Kozlov wrote: >>> Should we then check that the frame is deoptimized already and bailout after revoke_biases_of_monitors() call? I surprise we did not hit any problems before by deoptimizing frame twice. >> We could but I'm not sure I see the point. I think the existing guards are just about avoiding needless work more than anything. >> tom >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> On Nov 2, 2011, at 10:22 AM, Vladimir Kozlov wrote: >>>>> Yes, it looks good. But, Christian, can you show (call stack?) how we endup deoptimizing twice? How we enter deoptimization code twice? >>>> I think it's biased locking revocation. Here's the assertion point: >>>> V [libjvm.so+0x2701328] void VMError::report(outputStream*)+0x8c8 >>>> V [libjvm.so+0x2702469] void VMError::report_and_die()+0x4fd >>>> V [libjvm.so+0xe869bf] void report_vm_error(const char*,int,const char*,const char*)+0x55f >>>> V [libjvm.so+0xff8666] void frame::patch_pc(Thread*,unsigned char*)+0xe6 >>>> V [libjvm.so+0xfe6e8d] void frame::deoptimize(JavaThread*)+0x361 >>>> V [libjvm.so+0xed9622] void Deoptimization::deoptimize_frame(JavaThread*,long*)+0x55e >>>> V [libjvm.so+0xa34674] void deopt_caller()+0x154 >>>> V [libjvm.so+0xa35974] void Runtime1::new_type_array(JavaThread*,klassOopDesc*,int)+0x3c4 >>>> deopt_caller has a check for the caller already being deopted: >>>> static bool caller_is_deopted() { >>>> JavaThread* thread = JavaThread::current(); >>>> RegisterMap reg_map(thread, false); >>>> frame runtime_frame = thread->last_frame(); >>>> frame caller_frame = runtime_frame.sender(®_map); >>>> assert(caller_frame.is_compiled_frame(), "must be compiled"); >>>> return caller_frame.is_deoptimized_frame(); >>>> } >>>> // Stress deoptimization static void deopt_caller() { >>>> if ( !caller_is_deopted()) { >>>> JavaThread* thread = JavaThread::current(); >>>> RegisterMap reg_map(thread, false); >>>> frame runtime_frame = thread->last_frame(); >>>> frame caller_frame = runtime_frame.sender(®_map); >>>> Deoptimization::deoptimize_frame(thread, caller_frame.id()); >>>> assert(caller_is_deopted(), "Must be deoptimized"); >>>> } >>>> } >>>> but down in deoptimize we may revoke biases at a safepoint: >>>> if (UseBiasedLocking) { >>>> revoke_biases_of_monitors(thread, fr, map); >>>> } >>>> deoptimize_single_frame(thread, fr); >>>> This allows a deopt to occur during the safepoint, after the initial guard. >>>> tom >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/2/11 10:01 AM, Tom Rodriguez wrote: >>>>>> Looks good. >>>>>> >>>>>> tom >>>>>> >>>>>> On Nov 2, 2011, at 8:53 AM, Christian Thalinger wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/7106944/ >>>>>>> >>>>>>> 7106944: assert(_pc == *pc_addr) failed may be too strong >>>>>>> Reviewed-by: >>>>>>> >>>>>>> Sometimes we are already deoptimizing a frame when we request another >>>>>>> deoptimization of the same frame. This makes the assert to fail. >>>>>>> >>>>>>> The fix is to add a check to the assert that the return address is the >>>>>>> same that we are going to patch. >>>>>>> >>>>>>> src/cpu/x86/vm/frame_x86.cpp >>>>>>> From christian.thalinger at oracle.com Thu Nov 3 04:05:44 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 03 Nov 2011 11:05:44 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result Message-ID: <20111103110554.ABCE347219@hg.openjdk.java.net> Changeset: e342a5110bed Author: twisti Date: 2011-11-03 01:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e342a5110bed 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result Reviewed-by: kvn ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/runtime/deoptimization.cpp From christian.thalinger at oracle.com Thu Nov 3 08:40:06 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 03 Nov 2011 15:40:06 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7106944: assert(_pc == *pc_addr) failed may be too strong Message-ID: <20111103154016.209304721C@hg.openjdk.java.net> Changeset: 448691f285a5 Author: twisti Date: 2011-11-03 04:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/448691f285a5 7106944: assert(_pc == *pc_addr) failed may be too strong Reviewed-by: kvn, never ! src/cpu/x86/vm/frame_x86.cpp From tom.rodriguez at oracle.com Thu Nov 3 16:51:42 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 3 Nov 2011 16:51:42 -0700 Subject: review for 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer Message-ID: http://cr.openjdk.java.net/~never/7104960 73 lines changed: 42 ins; 6 del; 25 mod; 14873 unchg 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer Reviewed-by: The code buffers on limits on sparc didn't properly account for space required then the code cache and libjvm.so were farther apart than an int so it would slightly overflow it's buffer. It would crash because the CodeCache became corrupted instead of reporting that it overflowed. I modified the overflow detection logic to work even in product. It doesn't check on every operation as it does in debug mode, it just vierifies at the end that it hasn't overflowed. I also extended the ForceUnreachable logic to work on sparc and turned it into a diagnostic so it can be tested in product. I added logging code to report buffer usage and reset the values on sparc and x86. If left about 4k of buffer in product mode and 20k in debug mode. From tom.rodriguez at oracle.com Thu Nov 3 17:03:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 3 Nov 2011 17:03:32 -0700 Subject: review for 7108242: jinfo -permstat shouldn't report interned strings as part of perm Message-ID: http://cr.openjdk.java.net/~never/7108242 38 lines changed: 0 ins; 38 del; 0 mod; 279 unchg 7108242: jinfo -permstat shouldn't report interned strings as part of perm Reviewed-by: jinfo -permstat still reports interned strings as part of the perm gen which is no longer true. It should be dropped. From vladimir.kozlov at oracle.com Thu Nov 3 17:06:42 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Nov 2011 17:06:42 -0700 Subject: review for 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer In-Reply-To: References: Message-ID: <4EB32C92.3060506@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7104960 > 73 lines changed: 42 ins; 6 del; 25 mod; 14873 unchg > > 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer > Reviewed-by: > > The code buffers on limits on sparc didn't properly account for space > required then the code cache and libjvm.so were farther apart than an > int so it would slightly overflow it's buffer. It would crash because > the CodeCache became corrupted instead of reporting that it > overflowed. I modified the overflow detection logic to work even in > product. It doesn't check on every operation as it does in debug > mode, it just vierifies at the end that it hasn't overflowed. I also > extended the ForceUnreachable logic to work on sparc and turned it > into a diagnostic so it can be tested in product. I added logging > code to report buffer usage and reset the values on sparc and x86. If > left about 4k of buffer in product mode and 20k in debug mode. > From vladimir.kozlov at oracle.com Thu Nov 3 17:11:50 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Nov 2011 17:11:50 -0700 Subject: review for 7108242: jinfo -permstat shouldn't report interned strings as part of perm In-Reply-To: References: Message-ID: <4EB32DC6.8010302@oracle.com> Can you move it to HeapSummary.java? Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7108242 > 38 lines changed: 0 ins; 38 del; 0 mod; 279 unchg > > 7108242: jinfo -permstat shouldn't report interned strings as part of perm > Reviewed-by: > > jinfo -permstat still reports interned strings as part of the perm gen > which is no longer true. It should be dropped. > From schlosna at gmail.com Thu Nov 3 18:09:02 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Thu, 3 Nov 2011 21:09:02 -0400 Subject: review for 7108242: jinfo -permstat shouldn't report interned strings as part of perm In-Reply-To: <4EB32DC6.8010302@oracle.com> References: <4EB32DC6.8010302@oracle.com> Message-ID: > Tom Rodriguez wrote: > jinfo -permstat still reports interned strings as part of the perm gen > which is no longer true. ?It should be dropped. Out of curiosity, is there any way to determine the size of the interned strings now that they are no longer in PermGen? I assume that since 6962931 [1] with interned strings moving to the regular heap there isn't any way to compute the size of interned strings other than through a heap dump where they would show up like any other String, but I'd just like to confirm. Thanks, Dave [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6962931 From john.r.rose at oracle.com Thu Nov 3 22:49:49 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 3 Nov 2011 22:49:49 -0700 Subject: review for 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer In-Reply-To: References: Message-ID: <3D364F31-0BE4-4B41-B10C-31DA9B67D843@oracle.com> That's good. The xtty output should delimit the attribute values with single quotes: - xtty->print_cr(" required then the code cache and libjvm.so were farther apart than an > int so it would slightly overflow it's buffer. It would crash because > the CodeCache became corrupted instead of reporting that it > overflowed. I modified the overflow detection logic to work even in > product. It doesn't check on every operation as it does in debug > mode, it just vierifies at the end that it hasn't overflowed. I also > extended the ForceUnreachable logic to work on sparc and turned it > into a diagnostic so it can be tested in product. I added logging > code to report buffer usage and reset the values on sparc and x86. If > left about 4k of buffer in product mode and 20k in debug mode. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111103/2152da62/attachment.html From rednaxelafx at gmail.com Fri Nov 4 00:37:23 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 4 Nov 2011 15:37:23 +0800 Subject: review for 7108242: jinfo -permstat shouldn't report interned strings as part of perm In-Reply-To: References: <4EB32DC6.8010302@oracle.com> Message-ID: Hi David, FYI: I'm not sure what's the best way to expose the stats of interned strings, but from an implementation perspective, the size of interned strings can easily be determined by scanning the StringTable in HotSpot. It can be done from both inside the HotSpot VM itself; or from the Serviceability Agent (via sun.jvm.hotspot.memory.StringTable). The StringTable data structure keeps **references** (*oop*s) to the interned *String* objects, instead the *String*s themselves. It doesn't really matter whether or not the Strings are in PermGen or not. The table itself was never stored in the GC heap; instead it's a part of the GC root set. Regards, Kris Mok On Fri, Nov 4, 2011 at 9:09 AM, David Schlosnagle wrote: > > Tom Rodriguez wrote: > > jinfo -permstat still reports interned strings as part of the perm gen > > which is no longer true. It should be dropped. > > Out of curiosity, is there any way to determine the size of the > interned strings now that they are no longer in PermGen? I assume that > since 6962931 [1] with interned strings moving to the regular heap > there isn't any way to compute the size of interned strings other than > through a heap dump where they would show up like any other String, > but I'd just like to confirm. > > Thanks, > Dave > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6962931 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111104/39bea86e/attachment.html From christian.thalinger at oracle.com Fri Nov 4 02:16:23 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Nov 2011 10:16:23 +0100 Subject: review for 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer In-Reply-To: References: Message-ID: Looks good. -- Chris On Nov 4, 2011, at 12:51 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7104960 > 73 lines changed: 42 ins; 6 del; 25 mod; 14873 unchg > > 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer > Reviewed-by: > > The code buffers on limits on sparc didn't properly account for space > required then the code cache and libjvm.so were farther apart than an > int so it would slightly overflow it's buffer. It would crash because > the CodeCache became corrupted instead of reporting that it > overflowed. I modified the overflow detection logic to work even in > product. It doesn't check on every operation as it does in debug > mode, it just vierifies at the end that it hasn't overflowed. I also > extended the ForceUnreachable logic to work on sparc and turned it > into a diagnostic so it can be tested in product. I added logging > code to report buffer usage and reset the values on sparc and x86. If > left about 4k of buffer in product mode and 20k in debug mode. > From christian.thalinger at oracle.com Fri Nov 4 03:35:15 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Nov 2011 11:35:15 +0100 Subject: Request for reviews (S): 7097546: Optimize use of CMOVE instructions In-Reply-To: <4EA1FF06.3040906@oracle.com> References: <4EA1FF06.3040906@oracle.com> Message-ID: On Oct 22, 2011, at 1:23 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7097546/webrev > > 7097546: Optimize use of CMOVE instructions > > Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Don't generated CMoveD/CmoveF: it is expensive to compute both float/double values + cmove. Note, on x86 when SSE>=2 (all modern cpus) CMoveD/CMoveF mach instructions are implemented as jmp+move. Don't generated CMove when BlockLayoutByFrequency optimization moves infrequent branch from hot path. Added Cmove mach instructions with jmp+move to x86 when there is no HW cmove instruction. > > Main part of changes in loopopts.cpp is coding style correction. > > Print size of compiled method and compilation time when PrintCompilation and PrintInlining are specified on command line. I thought first to print it with just PrintCompilation but it will double output. I kind of missed this but could we print this only with Verbose or WizardMode? It makes the output more difficult to read. -- Chris > > No effect on refworkload but it will help later for 6890673 fix. Verified with microbenchmark I wrote (attached to the bug report). > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Fri Nov 4 08:33:34 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Nov 2011 08:33:34 -0700 Subject: Request for reviews (S): 7097546: Optimize use of CMOVE instructions In-Reply-To: References: <4EA1FF06.3040906@oracle.com> Message-ID: <4EB405CE.3020707@oracle.com> I want this info in product VM also but Verbose and WizardMode are debug flags. You can use 1 compiler thread to get more linear output. Vladimir On 11/4/11 3:35 AM, Christian Thalinger wrote: > > On Oct 22, 2011, at 1:23 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7097546/webrev >> >> 7097546: Optimize use of CMOVE instructions >> >> Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Don't generated CMoveD/CmoveF: it is expensive to compute both float/double values + cmove. Note, on x86 when SSE>=2 (all modern cpus) CMoveD/CMoveF mach instructions are implemented as jmp+move. Don't generated CMove when BlockLayoutByFrequency optimization moves infrequent branch from hot path. Added Cmove mach instructions with jmp+move to x86 when there is no HW cmove instruction. >> >> Main part of changes in loopopts.cpp is coding style correction. >> >> Print size of compiled method and compilation time when PrintCompilation and PrintInlining are specified on command line. I thought first to print it with just PrintCompilation but it will double output. > > I kind of missed this but could we print this only with Verbose or WizardMode? It makes the output more difficult to read. > > -- Chris > >> >> No effect on refworkload but it will help later for 6890673 fix. Verified with microbenchmark I wrote (attached to the bug report). >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Fri Nov 4 08:51:02 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Nov 2011 08:51:02 -0700 Subject: Request for reviews (S): 7097546: Optimize use of CMOVE instructions In-Reply-To: <4EB405CE.3020707@oracle.com> References: <4EA1FF06.3040906@oracle.com> <4EB405CE.3020707@oracle.com> Message-ID: <4EB409E6.8000106@oracle.com> I poked around for flags and the only reasonable candidate is PrintCompilation2. I will see what I can do with it. Vladimir On 11/4/11 8:33 AM, Vladimir Kozlov wrote: > I want this info in product VM also but Verbose and WizardMode are debug flags. You can use 1 compiler thread to get > more linear output. > > Vladimir > > On 11/4/11 3:35 AM, Christian Thalinger wrote: >> >> On Oct 22, 2011, at 1:23 AM, Vladimir Kozlov wrote: >> >>> http://cr.openjdk.java.net/~kvn/7097546/webrev >>> >>> 7097546: Optimize use of CMOVE instructions >>> >>> Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Don't generated >>> CMoveD/CmoveF: it is expensive to compute both float/double values + cmove. Note, on x86 when SSE>=2 (all modern >>> cpus) CMoveD/CMoveF mach instructions are implemented as jmp+move. Don't generated CMove when BlockLayoutByFrequency >>> optimization moves infrequent branch from hot path. Added Cmove mach instructions with jmp+move to x86 when there is >>> no HW cmove instruction. >>> >>> Main part of changes in loopopts.cpp is coding style correction. >>> >>> Print size of compiled method and compilation time when PrintCompilation and PrintInlining are specified on command >>> line. I thought first to print it with just PrintCompilation but it will double output. >> >> I kind of missed this but could we print this only with Verbose or WizardMode? It makes the output more difficult to >> read. >> >> -- Chris >> >>> >>> No effect on refworkload but it will help later for 6890673 fix. Verified with microbenchmark I wrote (attached to >>> the bug report). >>> >>> Thanks, >>> Vladimir >> From tom.rodriguez at oracle.com Fri Nov 4 10:25:47 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Nov 2011 10:25:47 -0700 Subject: review for 7108242: jinfo -permstat shouldn't report interned strings as part of perm In-Reply-To: References: <4EB32DC6.8010302@oracle.com> Message-ID: That's right. The code will properly report the space taken by interned strings but it's inappropriate to report it as part of the -permstat output. tom On Nov 4, 2011, at 12:37 AM, Krystal Mok wrote: > Hi David, > > FYI: > > I'm not sure what's the best way to expose the stats of interned strings, but from an implementation perspective, the size of interned strings can easily be determined by scanning the StringTable in HotSpot. It can be done from both inside the HotSpot VM itself; or from the Serviceability Agent (via sun.jvm.hotspot.memory.StringTable). > > The StringTable data structure keeps **references** (oops) to the interned String objects, instead the Strings themselves. It doesn't really matter whether or not the Strings are in PermGen or not. The table itself was never stored in the GC heap; instead it's a part of the GC root set. > > Regards, > Kris Mok > > On Fri, Nov 4, 2011 at 9:09 AM, David Schlosnagle wrote: > > Tom Rodriguez wrote: > > jinfo -permstat still reports interned strings as part of the perm gen > > which is no longer true. It should be dropped. > > Out of curiosity, is there any way to determine the size of the > interned strings now that they are no longer in PermGen? I assume that > since 6962931 [1] with interned strings moving to the regular heap > there isn't any way to compute the size of interned strings other than > through a heap dump where they would show up like any other String, > but I'd just like to confirm. > > Thanks, > Dave > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6962931 > From tom.rodriguez at oracle.com Fri Nov 4 10:29:57 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Nov 2011 10:29:57 -0700 Subject: review for 7108242: jinfo -permstat shouldn't report interned strings as part of perm In-Reply-To: <4EB32DC6.8010302@oracle.com> References: <4EB32DC6.8010302@oracle.com> Message-ID: <64DBAADB-7443-4A95-9AF1-B577F5DB5F00@oracle.com> That seems like a reasonable place to move it. I'll do that and send out a new webrev. tom On Nov 3, 2011, at 5:11 PM, Vladimir Kozlov wrote: > Can you move it to HeapSummary.java? > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7108242 >> 38 lines changed: 0 ins; 38 del; 0 mod; 279 unchg >> 7108242: jinfo -permstat shouldn't report interned strings as part of perm >> Reviewed-by: >> jinfo -permstat still reports interned strings as part of the perm gen >> which is no longer true. It should be dropped. From tom.rodriguez at oracle.com Fri Nov 4 10:54:05 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Nov 2011 10:54:05 -0700 Subject: review for 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer In-Reply-To: <3D364F31-0BE4-4B41-B10C-31DA9B67D843@oracle.com> References: <3D364F31-0BE4-4B41-B10C-31DA9B67D843@oracle.com> Message-ID: On Nov 3, 2011, at 10:49 PM, John Rose wrote: > That's good. > > The xtty output should delimit the attribute values with single quotes: > > - xtty->print_cr(" > Perhaps the xml-spewing code should be a method on CodeBuffer itself, so we can log other such bits (stub routines, interpreter, adapters) when we feel like it. That's a good idea. I may add a few others if it's easy. tom > > -- John > > On Nov 3, 2011, at 4:51 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/7104960 >> 73 lines changed: 42 ins; 6 del; 25 mod; 14873 unchg >> >> 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer >> Reviewed-by: >> >> The code buffers on limits on sparc didn't properly account for space >> required then the code cache and libjvm.so were farther apart than an >> int so it would slightly overflow it's buffer. It would crash because >> the CodeCache became corrupted instead of reporting that it >> overflowed. I modified the overflow detection logic to work even in >> product. It doesn't check on every operation as it does in debug >> mode, it just vierifies at the end that it hasn't overflowed. I also >> extended the ForceUnreachable logic to work on sparc and turned it >> into a diagnostic so it can be tested in product. I added logging >> code to report buffer usage and reset the values on sparc and x86. If >> left about 4k of buffer in product mode and 20k in debug mode. >> > From dean.long at oracle.com Fri Nov 4 12:00:50 2011 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 4 Nov 2011 12:00:50 -0700 (PDT) Subject: Auto Reply: hotspot-compiler-dev Digest, Vol 54, Issue 7 Message-ID: <29bf69fd-bb2c-4be8-8543-eccc1561b746@default> This is an auto-replied message. I am out of the office right now. From tom.rodriguez at oracle.com Fri Nov 4 13:08:29 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Nov 2011 13:08:29 -0700 Subject: review for 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer In-Reply-To: References: <3D364F31-0BE4-4B41-B10C-31DA9B67D843@oracle.com> Message-ID: On Nov 4, 2011, at 10:54 AM, Tom Rodriguez wrote: > > On Nov 3, 2011, at 10:49 PM, John Rose wrote: > >> That's good. >> >> The xtty output should delimit the attribute values with single quotes: >> >> - xtty->print_cr(" >> >> Perhaps the xml-spewing code should be a method on CodeBuffer itself, so we can log other such bits (stub routines, interpreter, adapters) when we feel like it. > > That's a good idea. I may add a few others if it's easy. I added log_sections_sizes. It would be nice if this were all a lot more automatic but we'd have to rearrange CodeBuffer and friends to do it. tom > > tom > >> >> -- John >> >> On Nov 3, 2011, at 4:51 PM, Tom Rodriguez wrote: >> >>> http://cr.openjdk.java.net/~never/7104960 >>> 73 lines changed: 42 ins; 6 del; 25 mod; 14873 unchg >>> >>> 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer >>> Reviewed-by: >>> >>> The code buffers on limits on sparc didn't properly account for space >>> required then the code cache and libjvm.so were farther apart than an >>> int so it would slightly overflow it's buffer. It would crash because >>> the CodeCache became corrupted instead of reporting that it >>> overflowed. I modified the overflow detection logic to work even in >>> product. It doesn't check on every operation as it does in debug >>> mode, it just vierifies at the end that it hasn't overflowed. I also >>> extended the ForceUnreachable logic to work on sparc and turned it >>> into a diagnostic so it can be tested in product. I added logging >>> code to report buffer usage and reset the values on sparc and x86. If >>> left about 4k of buffer in product mode and 20k in debug mode. >>> >> > From tom.rodriguez at oracle.com Fri Nov 4 13:09:08 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Nov 2011 13:09:08 -0700 Subject: review for 7108242: jinfo -permstat shouldn't report interned strings as part of perm In-Reply-To: <64DBAADB-7443-4A95-9AF1-B577F5DB5F00@oracle.com> References: <4EB32DC6.8010302@oracle.com> <64DBAADB-7443-4A95-9AF1-B577F5DB5F00@oracle.com> Message-ID: <0BE10A4A-E5B1-46FE-BBB8-B63FC92E248C@oracle.com> On Nov 4, 2011, at 10:29 AM, Tom Rodriguez wrote: > That seems like a reasonable place to move it. I'll do that and send out a new webrev. I've moved it into HeapSummary.java so it will now be reported as part of jmap -heap. tom Parallel GC with 8 thread(s) Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 1073741824 (1024.0MB) NewSize = 1048576 (1.0MB) MaxNewSize = 4294901760 (4095.9375MB) OldSize = 4194304 (4.0MB) NewRatio = 2 SurvivorRatio = 8 PermSize = 16777216 (16.0MB) MaxPermSize = 67108864 (64.0MB) Heap Usage: PS Young Generation Eden Space: capacity = 17301504 (16.5MB) used = 346136 (0.33010101318359375MB) free = 16955368 (16.169898986816406MB) 2.0006122011126894% used From Space: capacity = 2883584 (2.75MB) used = 0 (0.0MB) free = 2883584 (2.75MB) 0.0% used To Space: capacity = 2883584 (2.75MB) used = 0 (0.0MB) free = 2883584 (2.75MB) 0.0% used PS Old Generation capacity = 44040192 (42.0MB) used = 0 (0.0MB) free = 44040192 (42.0MB) 0.0% used PS Perm Generation capacity = 16777216 (16.0MB) used = 1952152 (1.8617172241210938MB) free = 14825064 (14.138282775878906MB) 11.635732650756836% used 613 interned Strings occupying 37008 bytes. > > tom > > On Nov 3, 2011, at 5:11 PM, Vladimir Kozlov wrote: > >> Can you move it to HeapSummary.java? >> >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7108242 >>> 38 lines changed: 0 ins; 38 del; 0 mod; 279 unchg >>> 7108242: jinfo -permstat shouldn't report interned strings as part of perm >>> Reviewed-by: >>> jinfo -permstat still reports interned strings as part of the perm gen >>> which is no longer true. It should be dropped. > From vladimir.kozlov at oracle.com Fri Nov 4 13:59:59 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Nov 2011 13:59:59 -0700 Subject: review for 7108242: jinfo -permstat shouldn't report interned strings as part of perm In-Reply-To: <0BE10A4A-E5B1-46FE-BBB8-B63FC92E248C@oracle.com> References: <4EB32DC6.8010302@oracle.com> <64DBAADB-7443-4A95-9AF1-B577F5DB5F00@oracle.com> <0BE10A4A-E5B1-46FE-BBB8-B63FC92E248C@oracle.com> Message-ID: <4EB4524F.6060202@oracle.com> Thank you, Tom this looks good Vladimir Tom Rodriguez wrote: > On Nov 4, 2011, at 10:29 AM, Tom Rodriguez wrote: > >> That seems like a reasonable place to move it. I'll do that and send out a new webrev. > > I've moved it into HeapSummary.java so it will now be reported as part of jmap -heap. > > tom > > Parallel GC with 8 thread(s) > > Heap Configuration: > MinHeapFreeRatio = 40 > MaxHeapFreeRatio = 70 > MaxHeapSize = 1073741824 (1024.0MB) > NewSize = 1048576 (1.0MB) > MaxNewSize = 4294901760 (4095.9375MB) > OldSize = 4194304 (4.0MB) > NewRatio = 2 > SurvivorRatio = 8 > PermSize = 16777216 (16.0MB) > MaxPermSize = 67108864 (64.0MB) > > Heap Usage: > PS Young Generation > Eden Space: > capacity = 17301504 (16.5MB) > used = 346136 (0.33010101318359375MB) > free = 16955368 (16.169898986816406MB) > 2.0006122011126894% used > From Space: > capacity = 2883584 (2.75MB) > used = 0 (0.0MB) > free = 2883584 (2.75MB) > 0.0% used > To Space: > capacity = 2883584 (2.75MB) > used = 0 (0.0MB) > free = 2883584 (2.75MB) > 0.0% used > PS Old Generation > capacity = 44040192 (42.0MB) > used = 0 (0.0MB) > free = 44040192 (42.0MB) > 0.0% used > PS Perm Generation > capacity = 16777216 (16.0MB) > used = 1952152 (1.8617172241210938MB) > free = 14825064 (14.138282775878906MB) > 11.635732650756836% used > > 613 interned Strings occupying 37008 bytes. > >> tom >> >> On Nov 3, 2011, at 5:11 PM, Vladimir Kozlov wrote: >> >>> Can you move it to HeapSummary.java? >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7108242 >>>> 38 lines changed: 0 ins; 38 del; 0 mod; 279 unchg >>>> 7108242: jinfo -permstat shouldn't report interned strings as part of perm >>>> Reviewed-by: >>>> jinfo -permstat still reports interned strings as part of the perm gen >>>> which is no longer true. It should be dropped. > From tom.rodriguez at oracle.com Fri Nov 4 14:03:56 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Nov 2011 14:03:56 -0700 Subject: review for 7108242: jinfo -permstat shouldn't report interned strings as part of perm In-Reply-To: <4EB4524F.6060202@oracle.com> References: <4EB32DC6.8010302@oracle.com> <64DBAADB-7443-4A95-9AF1-B577F5DB5F00@oracle.com> <0BE10A4A-E5B1-46FE-BBB8-B63FC92E248C@oracle.com> <4EB4524F.6060202@oracle.com> Message-ID: Thanks. tom On Nov 4, 2011, at 1:59 PM, Vladimir Kozlov wrote: > Thank you, Tom > > this looks good > > Vladimir > > Tom Rodriguez wrote: >> On Nov 4, 2011, at 10:29 AM, Tom Rodriguez wrote: >>> That seems like a reasonable place to move it. I'll do that and send out a new webrev. >> I've moved it into HeapSummary.java so it will now be reported as part of jmap -heap. >> tom >> Parallel GC with 8 thread(s) >> Heap Configuration: >> MinHeapFreeRatio = 40 >> MaxHeapFreeRatio = 70 >> MaxHeapSize = 1073741824 (1024.0MB) >> NewSize = 1048576 (1.0MB) >> MaxNewSize = 4294901760 (4095.9375MB) >> OldSize = 4194304 (4.0MB) >> NewRatio = 2 >> SurvivorRatio = 8 >> PermSize = 16777216 (16.0MB) >> MaxPermSize = 67108864 (64.0MB) >> Heap Usage: >> PS Young Generation >> Eden Space: >> capacity = 17301504 (16.5MB) >> used = 346136 (0.33010101318359375MB) >> free = 16955368 (16.169898986816406MB) >> 2.0006122011126894% used >> From Space: >> capacity = 2883584 (2.75MB) >> used = 0 (0.0MB) >> free = 2883584 (2.75MB) >> 0.0% used >> To Space: >> capacity = 2883584 (2.75MB) >> used = 0 (0.0MB) >> free = 2883584 (2.75MB) >> 0.0% used >> PS Old Generation >> capacity = 44040192 (42.0MB) >> used = 0 (0.0MB) >> free = 44040192 (42.0MB) >> 0.0% used >> PS Perm Generation >> capacity = 16777216 (16.0MB) >> used = 1952152 (1.8617172241210938MB) >> free = 14825064 (14.138282775878906MB) >> 11.635732650756836% used >> 613 interned Strings occupying 37008 bytes. >>> tom >>> >>> On Nov 3, 2011, at 5:11 PM, Vladimir Kozlov wrote: >>> >>>> Can you move it to HeapSummary.java? >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/7108242 >>>>> 38 lines changed: 0 ins; 38 del; 0 mod; 279 unchg >>>>> 7108242: jinfo -permstat shouldn't report interned strings as part of perm >>>>> Reviewed-by: >>>>> jinfo -permstat still reports interned strings as part of the perm gen >>>>> which is no longer true. It should be dropped. From tom.rodriguez at oracle.com Fri Nov 4 19:20:26 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 05 Nov 2011 02:20:26 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 6636110: unaligned stackpointer leads to crash during deoptimization Message-ID: <20111105022030.A95A64724A@hg.openjdk.java.net> Changeset: 1feb272af3a7 Author: never Date: 2011-11-04 13:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1feb272af3a7 6636110: unaligned stackpointer leads to crash during deoptimization Reviewed-by: never, kvn Contributed-by: Andreas Schoesser ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp From john.r.rose at oracle.com Fri Nov 4 22:47:52 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 4 Nov 2011 22:47:52 -0700 Subject: review for 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer In-Reply-To: References: <3D364F31-0BE4-4B41-B10C-31DA9B67D843@oracle.com> Message-ID: On Nov 4, 2011, at 1:08 PM, Tom Rodriguez wrote: > I added log_sections_sizes. It would be nice if this were all a lot more automatic but we'd have to rearrange CodeBuffer and friends to do it. Ship it! -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111104/3e19b8c6/attachment.html From christian.thalinger at oracle.com Mon Nov 7 02:26:11 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Nov 2011 11:26:11 +0100 Subject: review for 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer In-Reply-To: References: <3D364F31-0BE4-4B41-B10C-31DA9B67D843@oracle.com> Message-ID: <006ACE3A-97A7-4711-825E-69BCB966F414@oracle.com> Still looks good. -- Chris On Nov 4, 2011, at 9:08 PM, Tom Rodriguez wrote: > > On Nov 4, 2011, at 10:54 AM, Tom Rodriguez wrote: > >> >> On Nov 3, 2011, at 10:49 PM, John Rose wrote: >> >>> That's good. >>> >>> The xtty output should delimit the attribute values with single quotes: >>> >>> - xtty->print_cr(" > I also wasn't terminating one of the elements correctly. I ran an xml parser over the output to confirm that was syntactically well formed. > >> >>> >>> Perhaps the xml-spewing code should be a method on CodeBuffer itself, so we can log other such bits (stub routines, interpreter, adapters) when we feel like it. >> >> That's a good idea. I may add a few others if it's easy. > > I added log_sections_sizes. It would be nice if this were all a lot more automatic but we'd have to rearrange CodeBuffer and friends to do it. > > tom > >> >> tom >> >>> >>> -- John >>> >>> On Nov 3, 2011, at 4:51 PM, Tom Rodriguez wrote: >>> >>>> http://cr.openjdk.java.net/~never/7104960 >>>> 73 lines changed: 42 ins; 6 del; 25 mod; 14873 unchg >>>> >>>> 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer >>>> Reviewed-by: >>>> >>>> The code buffers on limits on sparc didn't properly account for space >>>> required then the code cache and libjvm.so were farther apart than an >>>> int so it would slightly overflow it's buffer. It would crash because >>>> the CodeCache became corrupted instead of reporting that it >>>> overflowed. I modified the overflow detection logic to work even in >>>> product. It doesn't check on every operation as it does in debug >>>> mode, it just vierifies at the end that it hasn't overflowed. I also >>>> extended the ForceUnreachable logic to work on sparc and turned it >>>> into a diagnostic so it can be tested in product. I added logging >>>> code to report buffer usage and reset the values on sparc and x86. If >>>> left about 4k of buffer in product mode and 20k in debug mode. >>>> >>> >> > From christian.thalinger at oracle.com Mon Nov 7 02:27:31 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Nov 2011 11:27:31 +0100 Subject: review for 7108242: jinfo -permstat shouldn't report interned strings as part of perm In-Reply-To: <0BE10A4A-E5B1-46FE-BBB8-B63FC92E248C@oracle.com> References: <4EB32DC6.8010302@oracle.com> <64DBAADB-7443-4A95-9AF1-B577F5DB5F00@oracle.com> <0BE10A4A-E5B1-46FE-BBB8-B63FC92E248C@oracle.com> Message-ID: <4A2F32C1-6181-4156-8DAB-EF4AD6746421@oracle.com> Looks good. -- Chris On Nov 4, 2011, at 9:09 PM, Tom Rodriguez wrote: > > On Nov 4, 2011, at 10:29 AM, Tom Rodriguez wrote: > >> That seems like a reasonable place to move it. I'll do that and send out a new webrev. > > I've moved it into HeapSummary.java so it will now be reported as part of jmap -heap. > > tom > > Parallel GC with 8 thread(s) > > Heap Configuration: > MinHeapFreeRatio = 40 > MaxHeapFreeRatio = 70 > MaxHeapSize = 1073741824 (1024.0MB) > NewSize = 1048576 (1.0MB) > MaxNewSize = 4294901760 (4095.9375MB) > OldSize = 4194304 (4.0MB) > NewRatio = 2 > SurvivorRatio = 8 > PermSize = 16777216 (16.0MB) > MaxPermSize = 67108864 (64.0MB) > > Heap Usage: > PS Young Generation > Eden Space: > capacity = 17301504 (16.5MB) > used = 346136 (0.33010101318359375MB) > free = 16955368 (16.169898986816406MB) > 2.0006122011126894% used > From Space: > capacity = 2883584 (2.75MB) > used = 0 (0.0MB) > free = 2883584 (2.75MB) > 0.0% used > To Space: > capacity = 2883584 (2.75MB) > used = 0 (0.0MB) > free = 2883584 (2.75MB) > 0.0% used > PS Old Generation > capacity = 44040192 (42.0MB) > used = 0 (0.0MB) > free = 44040192 (42.0MB) > 0.0% used > PS Perm Generation > capacity = 16777216 (16.0MB) > used = 1952152 (1.8617172241210938MB) > free = 14825064 (14.138282775878906MB) > 11.635732650756836% used > > 613 interned Strings occupying 37008 bytes. > >> >> tom >> >> On Nov 3, 2011, at 5:11 PM, Vladimir Kozlov wrote: >> >>> Can you move it to HeapSummary.java? >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7108242 >>>> 38 lines changed: 0 ins; 38 del; 0 mod; 279 unchg >>>> 7108242: jinfo -permstat shouldn't report interned strings as part of perm >>>> Reviewed-by: >>>> jinfo -permstat still reports interned strings as part of the perm gen >>>> which is no longer true. It should be dropped. >> > From Ulf.Zibis at gmx.de Mon Nov 7 03:40:55 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 07 Nov 2011 12:40:55 +0100 Subject: Who is on Dedoxx? Message-ID: <4EB7C3C7.6070001@gmx.de> Hi all, I want to know, if there are any members of the list participating on the Devoxx Conference next week. Thanks for your response, -Ulf From vladimir.kozlov at oracle.com Mon Nov 7 12:37:39 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Nov 2011 12:37:39 -0800 Subject: Request for reviews (M): 7059047: EA: can't find initializing store with several CheckCastPP In-Reply-To: <4EB095B0.4080409@oracle.com> References: <4EB03D3C.7000708@oracle.com> <4EB05DA6.60504@oracle.com> <38F4BC13-4733-44C0-BC40-96F9D82E53E5@oracle.com> <4EB095B0.4080409@oracle.com> Message-ID: <4EB84193.6050403@oracle.com> Tom, Could you look on this update? webrev.02 vs original webrev difference: http://cr.openjdk.java.net/~kvn/7059047/webrev.update Thanks, Vladimir Vladimir Kozlov wrote: > Nothing was wrong with scalar_replaceable flag except it was not > propagated to referenced objects so ArgEscape state was used in such cases. > > But I see what you are concern about. The escape state type should be > pure escape state and applicable optimizations should be controlled by > separate flag. OK, I returned back scalar_replaceable flag and 3 > original escape states: > > http://cr.openjdk.java.net/~kvn/7059047/webrev.02 > > > Right, because ArgEscape means that we've lost track of identity > because of aliasing? > > Correct. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Nov 1, 2011, at 1:59 PM, Vladimir Kozlov wrote: >> >>> Thank you, Tom >>> >>> Tom Rodriguez wrote: >>>> I'm not sure I follow the distinction that's being made with >>>> ControlEscape, or ArgEscape for that matter. They seem to be about >>>> what optimizations we can do on an object more than whether they are >>>> escaping or not, which makes the naming confusing. Or am I >>>> misunderstand what's happening? Is this how they would be translated? >>>> NoEscape == ScalarReplaceable >>>> ControlEscape == NonEscaping >>>> ArgEscape == LocallyEscaping >>>> GlobalEscape == GlobalEcaping >>> Your translation is correct. Yes, the states define optimizations we >>> can do with objects. >>> >>>> Would be it be possible to come up with more descriptive names for >>>> these states? >>> How about your translation names? >> >> I'm happy with them of course but I wasn't sure they were accurate. >> Some comments explaining the distinction would be helpful too. >> >> In thinking about this some more, I'm wondering whether it's right to >> introduce this new state. What was wrong with the old >> scalar_replaceable flag? It feels to me like we have two distinct >> axes that we're trying to shove into a single number, which >> complicates the terminology for it. >> >>>> Why is has_non_escaping_obj assigned to twice? >>>> // mark all nodes reachable from ArgEscape nodes >>>> ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, >>>> &worklist, PointsToNode::ArgEscape); >>>> ! // mark all nodes reachable from ControlEscape nodes >>>> ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, >>>> &worklist, PointsToNode::ControlEscape); >>>> Should the second one be |=? >>> You are right. My bad. >>> >>>> Do we eliminate locking on ControlEscape objects? >>> Yes, the same as ArgEscape. >>> >>> I will add code for 7105605 to fold CmpP for NoEscape and >>> ControlEscape objects. I don't think it will be safe to do for >>> ArgEscape. >> >> Right, because ArgEscape means that we've lost track of identity >> because of aliasing? >> >>> An other optimization I am thinking for ControlEscape objects is >>> eliminating loads from it as we do for ScalarReplaceable objects. >> >> That seems good, though that might change how we name the states. >> NoEscape means all optimizations and elimination of allocation, >> ControlEscape just means we can't eliminate the allocation but we can >> do other allocations. Maybe the NoEscape shouldn't be renamed >> ScalarReplaceable then? >> >> tom >> >>> Thanks, >>> Vladimir >>> >>>> tom >>>> On Nov 1, 2011, at 11:41 AM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7059047/webrev >>>>> >>>>> 7059047: EA: can't find initializing store with several CheckCastPP >>>>> >>>>> Added new escape state: ControlEscape. Use it instead of ArgEscape >>>>> and (NoEscape && !_scalar_replaceable) in cases where not escaped >>>>> objects can't be scalar replaced because of flow-insensitive >>>>> analysis limitations. It is preparation for 7105605 changes. >>>>> >>>>> Split adjust_escape_state() method into two. New find_init_values() >>>>> method is used to find fields initializing values for not escaped >>>>> allocations. It is called before deferred edges are removed since >>>>> it affects results. adjust_escape_state() now is called after all >>>>> deferred edges are removed to get correct results. >>>>> >>>>> Factored out escape state propagation code into new method >>>>> propagate_escape_state(). >>>>> >>>>> Removed methods is_scalar_replaceable() and hidden_alias() which >>>>> are not used and corresponding fields in PointsToNode (which will >>>>> reduce used memory). >>>>> >>>>> Tested with CTW, jtreg, NSK, refworkload. >>>>> >>>>> Thanks, >>>>> Vladimir >> From tom.rodriguez at oracle.com Mon Nov 7 12:47:19 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 7 Nov 2011 12:47:19 -0800 Subject: Request for reviews (M): 7059047: EA: can't find initializing store with several CheckCastPP In-Reply-To: <4EB84193.6050403@oracle.com> References: <4EB03D3C.7000708@oracle.com> <4EB05DA6.60504@oracle.com> <38F4BC13-4733-44C0-BC40-96F9D82E53E5@oracle.com> <4EB095B0.4080409@oracle.com> <4EB84193.6050403@oracle.com> Message-ID: <2713EF26-2D8D-4603-A304-8595DF05A36C@oracle.com> On Nov 7, 2011, at 12:37 PM, Vladimir Kozlov wrote: > Tom, > > Could you look on this update? webrev.02 vs original webrev difference: > > http://cr.openjdk.java.net/~kvn/7059047/webrev.update Yes, that looks good. tom > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> Nothing was wrong with scalar_replaceable flag except it was not propagated to referenced objects so ArgEscape state was used in such cases. >> But I see what you are concern about. The escape state type should be pure escape state and applicable optimizations should be controlled by separate flag. OK, I returned back scalar_replaceable flag and 3 original escape states: >> http://cr.openjdk.java.net/~kvn/7059047/webrev.02 >> > Right, because ArgEscape means that we've lost track of identity because of aliasing? >> Correct. >> Thanks, >> Vladimir >> Tom Rodriguez wrote: >>> On Nov 1, 2011, at 1:59 PM, Vladimir Kozlov wrote: >>> >>>> Thank you, Tom >>>> >>>> Tom Rodriguez wrote: >>>>> I'm not sure I follow the distinction that's being made with ControlEscape, or ArgEscape for that matter. They seem to be about what optimizations we can do on an object more than whether they are escaping or not, which makes the naming confusing. Or am I misunderstand what's happening? Is this how they would be translated? >>>>> NoEscape == ScalarReplaceable >>>>> ControlEscape == NonEscaping >>>>> ArgEscape == LocallyEscaping >>>>> GlobalEscape == GlobalEcaping >>>> Your translation is correct. Yes, the states define optimizations we can do with objects. >>>> >>>>> Would be it be possible to come up with more descriptive names for these states? >>>> How about your translation names? >>> >>> I'm happy with them of course but I wasn't sure they were accurate. Some comments explaining the distinction would be helpful too. >>> >>> In thinking about this some more, I'm wondering whether it's right to introduce this new state. What was wrong with the old scalar_replaceable flag? It feels to me like we have two distinct axes that we're trying to shove into a single number, which complicates the terminology for it. >>> >>>>> Why is has_non_escaping_obj assigned to twice? >>>>> // mark all nodes reachable from ArgEscape nodes >>>>> ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, &worklist, PointsToNode::ArgEscape); >>>>> ! // mark all nodes reachable from ControlEscape nodes >>>>> ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, &worklist, PointsToNode::ControlEscape); >>>>> Should the second one be |=? >>>> You are right. My bad. >>>> >>>>> Do we eliminate locking on ControlEscape objects? >>>> Yes, the same as ArgEscape. >>>> >>>> I will add code for 7105605 to fold CmpP for NoEscape and ControlEscape objects. I don't think it will be safe to do for ArgEscape. >>> >>> Right, because ArgEscape means that we've lost track of identity because of aliasing? >>> >>>> An other optimization I am thinking for ControlEscape objects is eliminating loads from it as we do for ScalarReplaceable objects. >>> >>> That seems good, though that might change how we name the states. NoEscape means all optimizations and elimination of allocation, ControlEscape just means we can't eliminate the allocation but we can do other allocations. Maybe the NoEscape shouldn't be renamed ScalarReplaceable then? >>> >>> tom >>> >>>> Thanks, >>>> Vladimir >>>> >>>>> tom >>>>> On Nov 1, 2011, at 11:41 AM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/7059047/webrev >>>>>> >>>>>> 7059047: EA: can't find initializing store with several CheckCastPP >>>>>> >>>>>> Added new escape state: ControlEscape. Use it instead of ArgEscape and (NoEscape && !_scalar_replaceable) in cases where not escaped objects can't be scalar replaced because of flow-insensitive analysis limitations. It is preparation for 7105605 changes. >>>>>> >>>>>> Split adjust_escape_state() method into two. New find_init_values() method is used to find fields initializing values for not escaped allocations. It is called before deferred edges are removed since it affects results. adjust_escape_state() now is called after all deferred edges are removed to get correct results. >>>>>> >>>>>> Factored out escape state propagation code into new method propagate_escape_state(). >>>>>> >>>>>> Removed methods is_scalar_replaceable() and hidden_alias() which are not used and corresponding fields in PointsToNode (which will reduce used memory). >>>>>> >>>>>> Tested with CTW, jtreg, NSK, refworkload. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>> From vladimir.kozlov at oracle.com Mon Nov 7 13:34:01 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Nov 2011 13:34:01 -0800 Subject: Request for reviews (M): 7059047: EA: can't find initializing store with several CheckCastPP In-Reply-To: <2713EF26-2D8D-4603-A304-8595DF05A36C@oracle.com> References: <4EB03D3C.7000708@oracle.com> <4EB05DA6.60504@oracle.com> <38F4BC13-4733-44C0-BC40-96F9D82E53E5@oracle.com> <4EB095B0.4080409@oracle.com> <4EB84193.6050403@oracle.com> <2713EF26-2D8D-4603-A304-8595DF05A36C@oracle.com> Message-ID: <4EB84EC9.1060405@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > On Nov 7, 2011, at 12:37 PM, Vladimir Kozlov wrote: > >> Tom, >> >> Could you look on this update? webrev.02 vs original webrev difference: >> >> http://cr.openjdk.java.net/~kvn/7059047/webrev.update > > Yes, that looks good. > > tom > > >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> Nothing was wrong with scalar_replaceable flag except it was not propagated to referenced objects so ArgEscape state was used in such cases. >>> But I see what you are concern about. The escape state type should be pure escape state and applicable optimizations should be controlled by separate flag. OK, I returned back scalar_replaceable flag and 3 original escape states: >>> http://cr.openjdk.java.net/~kvn/7059047/webrev.02 >>>> Right, because ArgEscape means that we've lost track of identity because of aliasing? >>> Correct. >>> Thanks, >>> Vladimir >>> Tom Rodriguez wrote: >>>> On Nov 1, 2011, at 1:59 PM, Vladimir Kozlov wrote: >>>> >>>>> Thank you, Tom >>>>> >>>>> Tom Rodriguez wrote: >>>>>> I'm not sure I follow the distinction that's being made with ControlEscape, or ArgEscape for that matter. They seem to be about what optimizations we can do on an object more than whether they are escaping or not, which makes the naming confusing. Or am I misunderstand what's happening? Is this how they would be translated? >>>>>> NoEscape == ScalarReplaceable >>>>>> ControlEscape == NonEscaping >>>>>> ArgEscape == LocallyEscaping >>>>>> GlobalEscape == GlobalEcaping >>>>> Your translation is correct. Yes, the states define optimizations we can do with objects. >>>>> >>>>>> Would be it be possible to come up with more descriptive names for these states? >>>>> How about your translation names? >>>> I'm happy with them of course but I wasn't sure they were accurate. Some comments explaining the distinction would be helpful too. >>>> >>>> In thinking about this some more, I'm wondering whether it's right to introduce this new state. What was wrong with the old scalar_replaceable flag? It feels to me like we have two distinct axes that we're trying to shove into a single number, which complicates the terminology for it. >>>> >>>>>> Why is has_non_escaping_obj assigned to twice? >>>>>> // mark all nodes reachable from ArgEscape nodes >>>>>> ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, &worklist, PointsToNode::ArgEscape); >>>>>> ! // mark all nodes reachable from ControlEscape nodes >>>>>> ! has_non_escaping_obj = propagate_escape_state(&cg_worklist, &worklist, PointsToNode::ControlEscape); >>>>>> Should the second one be |=? >>>>> You are right. My bad. >>>>> >>>>>> Do we eliminate locking on ControlEscape objects? >>>>> Yes, the same as ArgEscape. >>>>> >>>>> I will add code for 7105605 to fold CmpP for NoEscape and ControlEscape objects. I don't think it will be safe to do for ArgEscape. >>>> Right, because ArgEscape means that we've lost track of identity because of aliasing? >>>> >>>>> An other optimization I am thinking for ControlEscape objects is eliminating loads from it as we do for ScalarReplaceable objects. >>>> That seems good, though that might change how we name the states. NoEscape means all optimizations and elimination of allocation, ControlEscape just means we can't eliminate the allocation but we can do other allocations. Maybe the NoEscape shouldn't be renamed ScalarReplaceable then? >>>> >>>> tom >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> tom >>>>>> On Nov 1, 2011, at 11:41 AM, Vladimir Kozlov wrote: >>>>>>> http://cr.openjdk.java.net/~kvn/7059047/webrev >>>>>>> >>>>>>> 7059047: EA: can't find initializing store with several CheckCastPP >>>>>>> >>>>>>> Added new escape state: ControlEscape. Use it instead of ArgEscape and (NoEscape && !_scalar_replaceable) in cases where not escaped objects can't be scalar replaced because of flow-insensitive analysis limitations. It is preparation for 7105605 changes. >>>>>>> >>>>>>> Split adjust_escape_state() method into two. New find_init_values() method is used to find fields initializing values for not escaped allocations. It is called before deferred edges are removed since it affects results. adjust_escape_state() now is called after all deferred edges are removed to get correct results. >>>>>>> >>>>>>> Factored out escape state propagation code into new method propagate_escape_state(). >>>>>>> >>>>>>> Removed methods is_scalar_replaceable() and hidden_alias() which are not used and corresponding fields in PointsToNode (which will reduce used memory). >>>>>>> >>>>>>> Tested with CTW, jtreg, NSK, refworkload. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir > From vladimir.kozlov at oracle.com Mon Nov 7 15:43:55 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Nov 2011 15:43:55 -0800 Subject: Request for reviews (M): 7107042: assert(no_dead_loop) failed: dead loop detected Message-ID: <4EB86D3B.6050207@oracle.com> http://cr.openjdk.java.net/~kvn/7107042/webrev 7107042: assert(no_dead_loop) failed: dead loop detected Late inlining and IGVN may cut off part of ideal graph which become dead. But dead code may stay in graph and still be reachable from data nodes (for example constants). Region::Ideal() has code to kill not reachable from method's start dead code if Region node has only one input (second input path was cut off). But it can't eliminate a Region node which has two or more live inputs which are loop's back edges. EA may create dead loop Phi nodes if a scalar replaceable allocation is referenced inside such dead loops. Used dead nodes elimination code in PhaseIdealLoop before executing EA. But do not execute any loop optimizations to avoid ideal graph reshaping before EA. Also removed dead nodes from macro_nodes list in remove_useless_nodes(). During testing I hit several other problems and fixed them: Added missed failing() check after each late inline. Added missed parenthesis for Verbose output of CMOVE nodes. A switch value for indirect jumps could be shared but the matcher's code which detects it was skipped since incorrect state (Visit instead of Pre_Visit) was used. Split instance field load through Phi optimization was executed before Phi node is processed. Use PrintCompilation2 instead of PrintInlining flag to print compilation data after compilation is finished. Change PrintCompilation2 to diagnostic flag and replace it in previous usage (only one) with WizardMode flag. Tested with CTW, jtreg, NSK, refworkload. Thanks, Vladimir From vladimir.kozlov at oracle.com Mon Nov 7 16:49:14 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 08 Nov 2011 00:49:14 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7059047: EA: can't find initializing store with several CheckCastPP Message-ID: <20111108004918.3BAC747285@hg.openjdk.java.net> Changeset: 59e515ee9354 Author: kvn Date: 2011-11-07 14:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/59e515ee9354 7059047: EA: can't find initializing store with several CheckCastPP Summary: Split adjust_escape_state() method into two methods to find initializing stores. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp From vladimir.kozlov at oracle.com Mon Nov 7 17:55:24 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Nov 2011 17:55:24 -0800 Subject: review for 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer In-Reply-To: <006ACE3A-97A7-4711-825E-69BCB966F414@oracle.com> References: <3D364F31-0BE4-4B41-B10C-31DA9B67D843@oracle.com> <006ACE3A-97A7-4711-825E-69BCB966F414@oracle.com> Message-ID: <4EB88C0C.4060007@oracle.com> Yes, it is good. Vladimir Christian Thalinger wrote: > Still looks good. -- Chris > > On Nov 4, 2011, at 9:08 PM, Tom Rodriguez wrote: > >> On Nov 4, 2011, at 10:54 AM, Tom Rodriguez wrote: >> >>> On Nov 3, 2011, at 10:49 PM, John Rose wrote: >>> >>>> That's good. >>>> >>>> The xtty output should delimit the attribute values with single quotes: >>>> >>>> - xtty->print_cr("> I also wasn't terminating one of the elements correctly. I ran an xml parser over the output to confirm that was syntactically well formed. >> >>>> Perhaps the xml-spewing code should be a method on CodeBuffer itself, so we can log other such bits (stub routines, interpreter, adapters) when we feel like it. >>> That's a good idea. I may add a few others if it's easy. >> I added log_sections_sizes. It would be nice if this were all a lot more automatic but we'd have to rearrange CodeBuffer and friends to do it. >> >> tom >> >>> tom >>> >>>> -- John >>>> >>>> On Nov 3, 2011, at 4:51 PM, Tom Rodriguez wrote: >>>> >>>>> http://cr.openjdk.java.net/~never/7104960 >>>>> 73 lines changed: 42 ins; 6 del; 25 mod; 14873 unchg >>>>> >>>>> 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer >>>>> Reviewed-by: >>>>> >>>>> The code buffers on limits on sparc didn't properly account for space >>>>> required then the code cache and libjvm.so were farther apart than an >>>>> int so it would slightly overflow it's buffer. It would crash because >>>>> the CodeCache became corrupted instead of reporting that it >>>>> overflowed. I modified the overflow detection logic to work even in >>>>> product. It doesn't check on every operation as it does in debug >>>>> mode, it just vierifies at the end that it hasn't overflowed. I also >>>>> extended the ForceUnreachable logic to work on sparc and turned it >>>>> into a diagnostic so it can be tested in product. I added logging >>>>> code to report buffer usage and reset the values on sparc and x86. If >>>>> left about 4k of buffer in product mode and 20k in debug mode. >>>>> > From christian.thalinger at oracle.com Tue Nov 8 03:57:29 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Nov 2011 12:57:29 +0100 Subject: Request for reviews (XS): 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use Message-ID: http://cr.openjdk.java.net/~twisti/7087727/ 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use Reviewed-by: The flag setting ScavengeRootsInCode=2 causes the JIT to inline more constants. This is generally a good thing for performance, but can cause bugs in compiled code. The test case has a code pattern that looks similar to the selectAlternative idiom but boils down to a different invoke bytecode (invokevirtual in that case). The current code in PredictedDynamicCallGenerator::generate checks for invokespecial (which is used by selectAlternative) and so code for invokedynamic is generated (in non-debug builds) which eventually leads to a crash. src/share/vm/opto/callGenerator.cpp From christian.thalinger at oracle.com Tue Nov 8 06:31:14 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Nov 2011 15:31:14 +0100 Subject: Request for review (L): 7003454: order constants in constant table by number of references in code Message-ID: <9C9BF4BD-7CD5-4517-B629-D92629999D56@oracle.com> http://cr.openjdk.java.net/~twisti/7003454/ 7003454: order constants in constant table by number of references in code Reviewed-by: Order constants in constant table by frequencies of references in code and set constant table base that offsets to these frequently used constants fit into the displacement range of load instructions. src/share/vm/adlc/adlparse.cpp src/share/vm/adlc/output_c.cpp src/share/vm/asm/assembler.hpp src/share/vm/opto/compile.cpp src/share/vm/opto/compile.hpp src/share/vm/opto/machnode.cpp src/share/vm/opto/matcher.hpp src/cpu/sparc/vm/sparc.ad src/cpu/x86/vm/x86_32.ad src/cpu/x86/vm/x86_64.ad src/cpu/sparc/vm/assembler_sparc.hpp src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp src/cpu/sparc/vm/methodHandles_sparc.cpp src/cpu/sparc/vm/sharedRuntime_sparc.cpp src/cpu/sparc/vm/vtableStubs_sparc.cpp src/cpu/x86/vm/assembler_x86.hpp src/cpu/x86/vm/stubGenerator_x86_64.cpp From tom.rodriguez at oracle.com Tue Nov 8 09:15:25 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 8 Nov 2011 09:15:25 -0800 Subject: Request for reviews (XS): 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use In-Reply-To: References: Message-ID: Looks good. tom On Nov 8, 2011, at 3:57 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7087727/ > > 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use > Reviewed-by: > > The flag setting ScavengeRootsInCode=2 causes the JIT to inline more > constants. This is generally a good thing for performance, but can > cause bugs in compiled code. > > The test case has a code pattern that looks similar to the > selectAlternative idiom but boils down to a different invoke bytecode > (invokevirtual in that case). The current code in > PredictedDynamicCallGenerator::generate checks for invokespecial > (which is used by selectAlternative) and so code for invokedynamic is > generated (in non-debug builds) which eventually leads to a crash. > > src/share/vm/opto/callGenerator.cpp > From vladimir.kozlov at oracle.com Tue Nov 8 10:12:10 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Nov 2011 10:12:10 -0800 Subject: Request for reviews (XS): 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use In-Reply-To: References: Message-ID: <4EB970FA.4010003@oracle.com> Christian, You recently fixed other code to avoid check bytecode directly. So should you use is_method_handle_invoke() here? Or it is not correct for this place? Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7087727/ > > 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use > Reviewed-by: > > The flag setting ScavengeRootsInCode=2 causes the JIT to inline more > constants. This is generally a good thing for performance, but can > cause bugs in compiled code. > > The test case has a code pattern that looks similar to the > selectAlternative idiom but boils down to a different invoke bytecode > (invokevirtual in that case). The current code in > PredictedDynamicCallGenerator::generate checks for invokespecial > (which is used by selectAlternative) and so code for invokedynamic is > generated (in non-debug builds) which eventually leads to a crash. > > src/share/vm/opto/callGenerator.cpp > From christian.thalinger at oracle.com Tue Nov 8 10:24:53 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Nov 2011 19:24:53 +0100 Subject: Request for reviews (XS): 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use In-Reply-To: <4EB970FA.4010003@oracle.com> References: <4EB970FA.4010003@oracle.com> Message-ID: On Nov 8, 2011, at 7:12 PM, Vladimir Kozlov wrote: > Christian, > > You recently fixed other code to avoid check bytecode directly. So should you use is_method_handle_invoke() here? Or it is not correct for this place? I wanted to do that but then I noticed that there is no easy way to get a methodHandle out of a ciMethod and left it as it is. If you know of a good way let me know and I will change it. -- Chris > > Thanks, > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7087727/ >> 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use >> Reviewed-by: >> The flag setting ScavengeRootsInCode=2 causes the JIT to inline more >> constants. This is generally a good thing for performance, but can >> cause bugs in compiled code. >> The test case has a code pattern that looks similar to the >> selectAlternative idiom but boils down to a different invoke bytecode >> (invokevirtual in that case). The current code in >> PredictedDynamicCallGenerator::generate checks for invokespecial >> (which is used by selectAlternative) and so code for invokedynamic is >> generated (in non-debug builds) which eventually leads to a crash. >> src/share/vm/opto/callGenerator.cpp From tom.rodriguez at oracle.com Tue Nov 8 10:52:36 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 8 Nov 2011 10:52:36 -0800 Subject: Request for reviews (XS): 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use In-Reply-To: References: <4EB970FA.4010003@oracle.com> Message-ID: <8E0AD952-B7AD-44C5-8231-8FBA0C83031F@oracle.com> On Nov 8, 2011, at 10:24 AM, Christian Thalinger wrote: > > On Nov 8, 2011, at 7:12 PM, Vladimir Kozlov wrote: > >> Christian, >> >> You recently fixed other code to avoid check bytecode directly. So should you use is_method_handle_invoke() here? Or it is not correct for this place? > > I wanted to do that but then I noticed that there is no easy way to get a methodHandle out of a ciMethod and left it as it is. If you know of a good way let me know and I will change it. I don't think you want to use is_method_handle_invoke in this code. It's explicitly interested in what kind of call site is being used so that it can emit the proper kind of guard. In the failing case what invoke bytecode is being used? invokevirtual? Why would some call sites that invoke an MH used invokevirtual and others use invokespecial? tom > > -- Chris > >> >> Thanks, >> Vladimir >> >> Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7087727/ >>> 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use >>> Reviewed-by: >>> The flag setting ScavengeRootsInCode=2 causes the JIT to inline more >>> constants. This is generally a good thing for performance, but can >>> cause bugs in compiled code. >>> The test case has a code pattern that looks similar to the >>> selectAlternative idiom but boils down to a different invoke bytecode >>> (invokevirtual in that case). The current code in >>> PredictedDynamicCallGenerator::generate checks for invokespecial >>> (which is used by selectAlternative) and so code for invokedynamic is >>> generated (in non-debug builds) which eventually leads to a crash. >>> src/share/vm/opto/callGenerator.cpp > From john.r.rose at oracle.com Tue Nov 8 12:14:17 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 8 Nov 2011 12:14:17 -0800 Subject: Request for reviews (XS): 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use In-Reply-To: <8E0AD952-B7AD-44C5-8231-8FBA0C83031F@oracle.com> References: <4EB970FA.4010003@oracle.com> <8E0AD952-B7AD-44C5-8231-8FBA0C83031F@oracle.com> Message-ID: On Nov 8, 2011, at 10:52 AM, Tom Rodriguez wrote: > Why would some call sites that invoke an MH used invokevirtual and others use invokespecial? That depends partly on where the MH constant originally came from, whether it was findVirtual, findStatic, or findSpecial. The bytecode probably came from MethodHandleChain::set_last_method. The change looks good. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111108/2ebe3e94/attachment.html From christian.thalinger at oracle.com Tue Nov 8 12:18:29 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Nov 2011 21:18:29 +0100 Subject: Request for reviews (XS): 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use In-Reply-To: <8E0AD952-B7AD-44C5-8231-8FBA0C83031F@oracle.com> References: <4EB970FA.4010003@oracle.com> <8E0AD952-B7AD-44C5-8231-8FBA0C83031F@oracle.com> Message-ID: <3B0581BE-11F5-469B-95B0-45D75B64C471@oracle.com> On Nov 8, 2011, at 7:52 PM, Tom Rodriguez wrote: > > On Nov 8, 2011, at 10:24 AM, Christian Thalinger wrote: > >> >> On Nov 8, 2011, at 7:12 PM, Vladimir Kozlov wrote: >> >>> Christian, >>> >>> You recently fixed other code to avoid check bytecode directly. So should you use is_method_handle_invoke() here? Or it is not correct for this place? >> >> I wanted to do that but then I noticed that there is no easy way to get a methodHandle out of a ciMethod and left it as it is. If you know of a good way let me know and I will change it. > > I don't think you want to use is_method_handle_invoke in this code. It's explicitly interested in what kind of call site is being used so that it can emit the proper kind of guard. Yeah, right. I just wanted to use Bytecode_invoke::is_invokedynamic. -- Chris > > In the failing case what invoke bytecode is being used? invokevirtual? Why would some call sites that invoke an MH used invokevirtual and others use invokespecial? > > tom > >> >> -- Chris >> >>> >>> Thanks, >>> Vladimir >>> >>> Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/7087727/ >>>> 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use >>>> Reviewed-by: >>>> The flag setting ScavengeRootsInCode=2 causes the JIT to inline more >>>> constants. This is generally a good thing for performance, but can >>>> cause bugs in compiled code. >>>> The test case has a code pattern that looks similar to the >>>> selectAlternative idiom but boils down to a different invoke bytecode >>>> (invokevirtual in that case). The current code in >>>> PredictedDynamicCallGenerator::generate checks for invokespecial >>>> (which is used by selectAlternative) and so code for invokedynamic is >>>> generated (in non-debug builds) which eventually leads to a crash. >>>> src/share/vm/opto/callGenerator.cpp >> > From vladimir.kozlov at oracle.com Tue Nov 8 12:33:36 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Nov 2011 12:33:36 -0800 Subject: Request for review (L): 7003454: order constants in constant table by number of references in code In-Reply-To: <9C9BF4BD-7CD5-4517-B629-D92629999D56@oracle.com> References: <9C9BF4BD-7CD5-4517-B629-D92629999D56@oracle.com> Message-ID: <4EB99220.2040401@oracle.com> Christian, assembler.hpp: I don't think we should have separate methods is_simmX() and min_simmX() for cases when it is used only one or 2 times. I would leave only frequently used one (min_simm13() is used only 3 times so it could be removed also): static int min_simm13() { return min_simm(13); } static bool is_simm13(intptr_t x) { return is_simm(x, 13); } static bool is_simm16(intptr_t x) { return is_simm(x, 16); } static bool is_simm32(intptr_t x) { return is_simm(x, 32); } compile.hpp: add parenthesis around (++_nof_jump_tables): + float next_jump_table_freq() { return -1.0f * ++_nof_jump_tables; } compile.cpp: will you hit next assert if you have several jump-tables?: + else assert(!found_void, "wrong sorting"); Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7003454/ > > 7003454: order constants in constant table by number of references in code > Reviewed-by: > > Order constants in constant table by frequencies of references in code > and set constant table base that offsets to these frequently used > constants fit into the displacement range of load instructions. > > src/share/vm/adlc/adlparse.cpp > src/share/vm/adlc/output_c.cpp > src/share/vm/asm/assembler.hpp > src/share/vm/opto/compile.cpp > src/share/vm/opto/compile.hpp > src/share/vm/opto/machnode.cpp > src/share/vm/opto/matcher.hpp > src/cpu/sparc/vm/sparc.ad > src/cpu/x86/vm/x86_32.ad > src/cpu/x86/vm/x86_64.ad > src/cpu/sparc/vm/assembler_sparc.hpp > src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp > src/cpu/sparc/vm/methodHandles_sparc.cpp > src/cpu/sparc/vm/sharedRuntime_sparc.cpp > src/cpu/sparc/vm/vtableStubs_sparc.cpp > src/cpu/x86/vm/assembler_x86.hpp > src/cpu/x86/vm/stubGenerator_x86_64.cpp > From vladimir.kozlov at oracle.com Tue Nov 8 12:35:42 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Nov 2011 12:35:42 -0800 Subject: Request for reviews (XS): 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use In-Reply-To: <3B0581BE-11F5-469B-95B0-45D75B64C471@oracle.com> References: <4EB970FA.4010003@oracle.com> <8E0AD952-B7AD-44C5-8231-8FBA0C83031F@oracle.com> <3B0581BE-11F5-469B-95B0-45D75B64C471@oracle.com> Message-ID: <4EB9929E.4060601@oracle.com> OK. Vladimir Christian Thalinger wrote: > On Nov 8, 2011, at 7:52 PM, Tom Rodriguez wrote: > >> On Nov 8, 2011, at 10:24 AM, Christian Thalinger wrote: >> >>> On Nov 8, 2011, at 7:12 PM, Vladimir Kozlov wrote: >>> >>>> Christian, >>>> >>>> You recently fixed other code to avoid check bytecode directly. So should you use is_method_handle_invoke() here? Or it is not correct for this place? >>> I wanted to do that but then I noticed that there is no easy way to get a methodHandle out of a ciMethod and left it as it is. If you know of a good way let me know and I will change it. >> I don't think you want to use is_method_handle_invoke in this code. It's explicitly interested in what kind of call site is being used so that it can emit the proper kind of guard. > > Yeah, right. I just wanted to use Bytecode_invoke::is_invokedynamic. > > -- Chris > >> In the failing case what invoke bytecode is being used? invokevirtual? Why would some call sites that invoke an MH used invokevirtual and others use invokespecial? >> >> tom >> >>> -- Chris >>> >>>> Thanks, >>>> Vladimir >>>> >>>> Christian Thalinger wrote: >>>>> http://cr.openjdk.java.net/~twisti/7087727/ >>>>> 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use >>>>> Reviewed-by: >>>>> The flag setting ScavengeRootsInCode=2 causes the JIT to inline more >>>>> constants. This is generally a good thing for performance, but can >>>>> cause bugs in compiled code. >>>>> The test case has a code pattern that looks similar to the >>>>> selectAlternative idiom but boils down to a different invoke bytecode >>>>> (invokevirtual in that case). The current code in >>>>> PredictedDynamicCallGenerator::generate checks for invokespecial >>>>> (which is used by selectAlternative) and so code for invokedynamic is >>>>> generated (in non-debug builds) which eventually leads to a crash. >>>>> src/share/vm/opto/callGenerator.cpp > From tom.rodriguez at oracle.com Tue Nov 8 16:18:15 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 09 Nov 2011 00:18:15 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer Message-ID: <20111109001817.E3435472A0@hg.openjdk.java.net> Changeset: 44ce519bc3d1 Author: never Date: 2011-11-08 10:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/44ce519bc3d1 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer Reviewed-by: kvn, jrose, twisti ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp From tom.rodriguez at oracle.com Tue Nov 8 18:02:13 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 8 Nov 2011 18:02:13 -0800 Subject: Request for review (L): 7003454: order constants in constant table by number of references in code In-Reply-To: <9C9BF4BD-7CD5-4517-B629-D92629999D56@oracle.com> References: <9C9BF4BD-7CD5-4517-B629-D92629999D56@oracle.com> Message-ID: Looks good. tom On Nov 8, 2011, at 6:31 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7003454/ > > 7003454: order constants in constant table by number of references in code > Reviewed-by: > > Order constants in constant table by frequencies of references in code > and set constant table base that offsets to these frequently used > constants fit into the displacement range of load instructions. > > src/share/vm/adlc/adlparse.cpp > src/share/vm/adlc/output_c.cpp > src/share/vm/asm/assembler.hpp > src/share/vm/opto/compile.cpp > src/share/vm/opto/compile.hpp > src/share/vm/opto/machnode.cpp > src/share/vm/opto/matcher.hpp > src/cpu/sparc/vm/sparc.ad > src/cpu/x86/vm/x86_32.ad > src/cpu/x86/vm/x86_64.ad > src/cpu/sparc/vm/assembler_sparc.hpp > src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp > src/cpu/sparc/vm/methodHandles_sparc.cpp > src/cpu/sparc/vm/sharedRuntime_sparc.cpp > src/cpu/sparc/vm/vtableStubs_sparc.cpp > src/cpu/x86/vm/assembler_x86.hpp > src/cpu/x86/vm/stubGenerator_x86_64.cpp > From tom.rodriguez at oracle.com Tue Nov 8 19:38:08 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 09 Nov 2011 03:38:08 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7105305: assert check_method_context proper context Message-ID: <20111109033810.DE41E472A3@hg.openjdk.java.net> Changeset: c9a03402fe56 Author: never Date: 2011-11-08 17:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c9a03402fe56 7105305: assert check_method_context proper context Reviewed-by: jrose, kvn ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/constantPoolKlass.cpp From vladimir.kozlov at oracle.com Tue Nov 8 20:13:24 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Nov 2011 20:13:24 -0800 Subject: Request for reviews (S): 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot Message-ID: <4EB9FDE4.8060202@oracle.com> http://cr.openjdk.java.net/~kvn/7109887/webrev 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot In changes for 7081933 I forgot to zero array when compiled code is deoptimized. Tested with failed test. Thanks, Vladimir From vladimir.kozlov at oracle.com Tue Nov 8 20:27:40 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Nov 2011 20:27:40 -0800 Subject: Request for reviews (M): 7105605: Use EA info to optimize pointers compare Message-ID: <4EBA013C.7020704@oracle.com> http://cr.openjdk.java.net/~kvn/7105605/webrev 7105605: Use EA info to optimize pointers compare EA Connection Graph can help to optimize pointers compare for non escaping allocations. Tested with CTW, jtreg, NSK, refworkload. Thanks, Vladimir From tom.rodriguez at oracle.com Tue Nov 8 20:58:17 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 8 Nov 2011 20:58:17 -0800 Subject: Request for reviews (M): 7107042: assert(no_dead_loop) failed: dead loop detected In-Reply-To: <4EB86D3B.6050207@oracle.com> References: <4EB86D3B.6050207@oracle.com> Message-ID: <417F7FEA-CEC9-47EA-A162-DAAD145F1F8C@oracle.com> Looks good. tom On Nov 7, 2011, at 3:43 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7107042/webrev > > 7107042: assert(no_dead_loop) failed: dead loop detected > > Late inlining and IGVN may cut off part of ideal graph which become dead. But dead code may stay in graph and still be reachable from data nodes (for example constants). Region::Ideal() has code to kill not reachable from method's start dead code if Region node has only one input (second input path was cut off). But it can't eliminate a Region node which has two or more live inputs which are loop's back edges. EA may create dead loop Phi nodes if a scalar replaceable allocation is referenced inside such dead loops. > > Used dead nodes elimination code in PhaseIdealLoop before executing EA. But do not execute any loop optimizations to avoid ideal graph reshaping before EA. > > Also removed dead nodes from macro_nodes list in remove_useless_nodes(). > > > During testing I hit several other problems and fixed them: > > Added missed failing() check after each late inline. > > Added missed parenthesis for Verbose output of CMOVE nodes. > > A switch value for indirect jumps could be shared but the matcher's code which detects it was skipped since incorrect state (Visit instead of Pre_Visit) was used. > > Split instance field load through Phi optimization was executed before Phi node is processed. > > Use PrintCompilation2 instead of PrintInlining flag to print compilation data after compilation is finished. Change PrintCompilation2 to diagnostic flag and replace it in previous usage (only one) with WizardMode flag. > > Tested with CTW, jtreg, NSK, refworkload. > > Thanks, > Vladimir From tom.rodriguez at oracle.com Tue Nov 8 21:06:00 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 8 Nov 2011 21:06:00 -0800 Subject: Request for reviews (S): 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot In-Reply-To: <4EB9FDE4.8060202@oracle.com> References: <4EB9FDE4.8060202@oracle.com> Message-ID: <2CEC1503-BC9F-41D8-9EBC-959C4CB62468@oracle.com> Looks good. tom On Nov 8, 2011, at 8:13 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7109887/webrev > > 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot > > In changes for 7081933 I forgot to zero array when compiled code is deoptimized. > > Tested with failed test. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Nov 8 21:53:09 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Nov 2011 21:53:09 -0800 Subject: Request for reviews (S): 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot In-Reply-To: <2CEC1503-BC9F-41D8-9EBC-959C4CB62468@oracle.com> References: <4EB9FDE4.8060202@oracle.com> <2CEC1503-BC9F-41D8-9EBC-959C4CB62468@oracle.com> Message-ID: <4EBA1545.1050304@oracle.com> Thank you, Tom, for reviews. Vladimir On 11/8/11 9:06 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Nov 8, 2011, at 8:13 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7109887/webrev >> >> 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot >> >> In changes for 7081933 I forgot to zero array when compiled code is deoptimized. >> >> Tested with failed test. >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Tue Nov 8 23:37:32 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 09 Nov 2011 07:37:32 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7108242: jinfo -permstat shouldn't report interned strings as part of perm Message-ID: <20111109073734.1AD16472A4@hg.openjdk.java.net> Changeset: e3e363b2bf19 Author: never Date: 2011-11-08 20:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e3e363b2bf19 7108242: jinfo -permstat shouldn't report interned strings as part of perm Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java From christian.thalinger at oracle.com Wed Nov 9 01:45:54 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Nov 2011 10:45:54 +0100 Subject: Request for review (L): 7003454: order constants in constant table by number of references in code In-Reply-To: <4EB99220.2040401@oracle.com> References: <9C9BF4BD-7CD5-4517-B629-D92629999D56@oracle.com> <4EB99220.2040401@oracle.com> Message-ID: <26B669D3-A61F-4CA6-875D-D0D249B015AB@oracle.com> On Nov 8, 2011, at 9:33 PM, Vladimir Kozlov wrote: > Christian, > > assembler.hpp: > > I don't think we should have separate methods is_simmX() and min_simmX() for cases when it is used only one or 2 times. I would leave only frequently used one (min_simm13() is used only 3 times so it could be removed also): > > static int min_simm13() { return min_simm(13); } > > static bool is_simm13(intptr_t x) { return is_simm(x, 13); } > static bool is_simm16(intptr_t x) { return is_simm(x, 16); } > static bool is_simm32(intptr_t x) { return is_simm(x, 32); } My reasoning was that defining them doesn't really hurt because they are very small and inlined and the usage is slightly shorter and better to read (in my opinion). Maybe others are used more often in the future but if the defines are not there nobody will reuse them :-) > > compile.hpp: > > add parenthesis around (++_nof_jump_tables): > > + float next_jump_table_freq() { return -1.0f * ++_nof_jump_tables; } Done. > > compile.cpp: > > will you hit next assert if you have several jump-tables?: > > + else assert(!found_void, "wrong sorting"); No. All jump-table entries should have been sorted to the end of _constants so when we first hit a T_VOID entry we set found_void to true and only hit T_VOID's after that. If there is something else after a T_VOID the assert triggers. -- Chris > > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7003454/ >> 7003454: order constants in constant table by number of references in code >> Reviewed-by: >> Order constants in constant table by frequencies of references in code >> and set constant table base that offsets to these frequently used >> constants fit into the displacement range of load instructions. >> src/share/vm/adlc/adlparse.cpp >> src/share/vm/adlc/output_c.cpp >> src/share/vm/asm/assembler.hpp >> src/share/vm/opto/compile.cpp >> src/share/vm/opto/compile.hpp >> src/share/vm/opto/machnode.cpp >> src/share/vm/opto/matcher.hpp >> src/cpu/sparc/vm/sparc.ad >> src/cpu/x86/vm/x86_32.ad >> src/cpu/x86/vm/x86_64.ad >> src/cpu/sparc/vm/assembler_sparc.hpp >> src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp >> src/cpu/sparc/vm/methodHandles_sparc.cpp >> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >> src/cpu/sparc/vm/vtableStubs_sparc.cpp >> src/cpu/x86/vm/assembler_x86.hpp >> src/cpu/x86/vm/stubGenerator_x86_64.cpp From christian.thalinger at oracle.com Wed Nov 9 01:47:50 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Nov 2011 10:47:50 +0100 Subject: Request for reviews (M): 7107042: assert(no_dead_loop) failed: dead loop detected In-Reply-To: <4EB86D3B.6050207@oracle.com> References: <4EB86D3B.6050207@oracle.com> Message-ID: <3B8247EA-3975-4F3C-8D9E-A72D1782A738@oracle.com> On Nov 8, 2011, at 12:43 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7107042/webrev > > 7107042: assert(no_dead_loop) failed: dead loop detected > > Late inlining and IGVN may cut off part of ideal graph which become dead. But dead code may stay in graph and still be reachable from data nodes (for example constants). Region::Ideal() has code to kill not reachable from method's start dead code if Region node has only one input (second input path was cut off). But it can't eliminate a Region node which has two or more live inputs which are loop's back edges. EA may create dead loop Phi nodes if a scalar replaceable allocation is referenced inside such dead loops. > > Used dead nodes elimination code in PhaseIdealLoop before executing EA. But do not execute any loop optimizations to avoid ideal graph reshaping before EA. > > Also removed dead nodes from macro_nodes list in remove_useless_nodes(). > > > During testing I hit several other problems and fixed them: > > Added missed failing() check after each late inline. > > Added missed parenthesis for Verbose output of CMOVE nodes. > > A switch value for indirect jumps could be shared but the matcher's code which detects it was skipped since incorrect state (Visit instead of Pre_Visit) was used. > > Split instance field load through Phi optimization was executed before Phi node is processed. > > Use PrintCompilation2 instead of PrintInlining flag to print compilation data after compilation is finished. Change PrintCompilation2 to diagnostic flag and replace it in previous usage (only one) with WizardMode flag. Thanks for changing that. -- Chris > > Tested with CTW, jtreg, NSK, refworkload. > > Thanks, > Vladimir From christian.thalinger at oracle.com Wed Nov 9 02:13:58 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Nov 2011 11:13:58 +0100 Subject: Request for reviews (S): 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot In-Reply-To: <4EB9FDE4.8060202@oracle.com> References: <4EB9FDE4.8060202@oracle.com> Message-ID: Looks good. Just a question: is there no method that zeroes an array? -- Chris On Nov 9, 2011, at 5:13 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7109887/webrev > > 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot > > In changes for 7081933 I forgot to zero array when compiled code is deoptimized. > > Tested with failed test. > > Thanks, > Vladimir From christian.thalinger at oracle.com Wed Nov 9 02:29:52 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Nov 2011 11:29:52 +0100 Subject: Request for reviews (M): 7105605: Use EA info to optimize pointers compare In-Reply-To: <4EBA013C.7020704@oracle.com> References: <4EBA013C.7020704@oracle.com> Message-ID: On Nov 9, 2011, at 5:27 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7105605/webrev src/share/vm/opto/escape.cpp: You should set _pcmp_neq and _pcmp_eq to NULL in the ConnectionGraph constructor. ConnectionGraph::do_analysis: + Node* pcmp_neq = OptimizePtrCompare ? igvn->makecon(TypeInt::CC_GT) : NULL; + Node* pcmp_eq = OptimizePtrCompare ? igvn->makecon(TypeInt::CC_EQ) : NULL; Are these two also added for the same reason as the comment says? // Add ConP#NULL and ConN#NULL nodes before ConnectionGraph construction // to create space for them in ConnectionGraph::_nodes[]. Weird. ConnectionGraph::optimize_ptr_compare: Is it intentional that the variables are called "has_unknow_obj1" instead of "unknown"? Otherwise this looks good, as far as I can tell. -- Chris > > 7105605: Use EA info to optimize pointers compare > > EA Connection Graph can help to optimize pointers compare for non escaping allocations. > > Tested with CTW, jtreg, NSK, refworkload. > > Thanks, > Vladimir From christian.thalinger at oracle.com Wed Nov 9 02:51:04 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 09 Nov 2011 10:51:04 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use Message-ID: <20111109105106.18D0E472A9@hg.openjdk.java.net> Changeset: 83d0b5cd1438 Author: twisti Date: 2011-11-09 00:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/83d0b5cd1438 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use Reviewed-by: jrose, kvn, never ! src/share/vm/opto/callGenerator.cpp From christian.thalinger at oracle.com Wed Nov 9 04:38:01 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Nov 2011 13:38:01 +0100 Subject: Request for reviews (M): 7107042: assert(no_dead_loop) failed: dead loop detected In-Reply-To: <3B8247EA-3975-4F3C-8D9E-A72D1782A738@oracle.com> References: <4EB86D3B.6050207@oracle.com> <3B8247EA-3975-4F3C-8D9E-A72D1782A738@oracle.com> Message-ID: On Nov 9, 2011, at 10:47 AM, Christian Thalinger wrote: > > On Nov 8, 2011, at 12:43 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7107042/webrev >> >> 7107042: assert(no_dead_loop) failed: dead loop detected >> >> Late inlining and IGVN may cut off part of ideal graph which become dead. But dead code may stay in graph and still be reachable from data nodes (for example constants). Region::Ideal() has code to kill not reachable from method's start dead code if Region node has only one input (second input path was cut off). But it can't eliminate a Region node which has two or more live inputs which are loop's back edges. EA may create dead loop Phi nodes if a scalar replaceable allocation is referenced inside such dead loops. >> >> Used dead nodes elimination code in PhaseIdealLoop before executing EA. But do not execute any loop optimizations to avoid ideal graph reshaping before EA. >> >> Also removed dead nodes from macro_nodes list in remove_useless_nodes(). >> >> >> During testing I hit several other problems and fixed them: >> >> Added missed failing() check after each late inline. >> >> Added missed parenthesis for Verbose output of CMOVE nodes. >> >> A switch value for indirect jumps could be shared but the matcher's code which detects it was skipped since incorrect state (Visit instead of Pre_Visit) was used. >> >> Split instance field load through Phi optimization was executed before Phi node is processed. >> >> Use PrintCompilation2 instead of PrintInlining flag to print compilation data after compilation is finished. Change PrintCompilation2 to diagnostic flag and replace it in previous usage (only one) with WizardMode flag. > > Thanks for changing that. -- Chris Hold the push! There is a problem with that code and it would be good if we could fix it with this change: 7109987: SIGSEGV in nmethod::total_size The suggested fix is to check for task->code(): - tty->print_cr("size: %d time: %d inlined: %d bytes", task->code()->total_size(), time.milliseconds(), task->num_inlined_bytecodes()); + tty->print_cr("size: %d time: %d inlined: %d bytes", (task->code() == NULL) ? 0 : task->code()->total_size(), time.milliseconds(), task->num_inlined_bytecodes()); Could you add that and close the CR as a duplicate? -- Chris > >> >> Tested with CTW, jtreg, NSK, refworkload. >> >> Thanks, >> Vladimir > From christian.thalinger at oracle.com Wed Nov 9 05:31:03 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Nov 2011 14:31:03 +0100 Subject: Request for review (XS): 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not Message-ID: <64DF9BDB-7C30-44AC-A87C-946A7A27E91B@oracle.com> http://cr.openjdk.java.net/~twisti/7108383/ 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not Reviewed-by: The problem is that the code in PredictedDynamicCallGenerator::generate assumes that the generation of the slow path always succeeds. This might not be the case when we hit the node limit while generating the slow path. The suggested fix is to remove the assert and return on failed slow path generations. I also applied the fix to PredictedCallGenerator::generate because I think it can also happen there. src/share/vm/opto/callGenerator.cpp From vladimir.kozlov at oracle.com Wed Nov 9 06:11:31 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Nov 2011 06:11:31 -0800 Subject: Request for reviews (S): 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot In-Reply-To: References: <4EB9FDE4.8060202@oracle.com> Message-ID: <4EBA8A13.6080009@oracle.com> Thank you, Christian Christian Thalinger wrote: > Looks good. Just a question: is there no method that zeroes an array? I only know CollectedHeap::init_obj() but it will zero array's length and we need to avoid it since GC already known about this array (from thread->vm_result()). Thanks, Vladimir > > -- Chris > > On Nov 9, 2011, at 5:13 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7109887/webrev >> >> 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot >> >> In changes for 7081933 I forgot to zero array when compiled code is deoptimized. >> >> Tested with failed test. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Wed Nov 9 06:23:06 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Nov 2011 06:23:06 -0800 Subject: Request for review (L): 7003454: order constants in constant table by number of references in code In-Reply-To: <26B669D3-A61F-4CA6-875D-D0D249B015AB@oracle.com> References: <9C9BF4BD-7CD5-4517-B629-D92629999D56@oracle.com> <4EB99220.2040401@oracle.com> <26B669D3-A61F-4CA6-875D-D0D249B015AB@oracle.com> Message-ID: <4EBA8CCA.5090503@oracle.com> >> will you hit next assert if you have several jump-tables?: >> >> + else assert(!found_void, "wrong sorting"); > > No. All jump-table entries should have been sorted to the end of _constants so when we first hit a T_VOID entry we set found_void to true and only hit T_VOID's after that. If there is something else after a T_VOID the assert triggers. Sorry, I was confused by code layout. Could you put it on separate lines?: + if (con.type() == T_VOID) + found_void = true; // jump tables + else + assert(!found_void, "wrong sorting"); Changes are good. Thanks, Vladimir Christian Thalinger wrote: > On Nov 8, 2011, at 9:33 PM, Vladimir Kozlov wrote: > >> Christian, >> >> assembler.hpp: >> >> I don't think we should have separate methods is_simmX() and min_simmX() for cases when it is used only one or 2 times. I would leave only frequently used one (min_simm13() is used only 3 times so it could be removed also): >> >> static int min_simm13() { return min_simm(13); } >> >> static bool is_simm13(intptr_t x) { return is_simm(x, 13); } >> static bool is_simm16(intptr_t x) { return is_simm(x, 16); } >> static bool is_simm32(intptr_t x) { return is_simm(x, 32); } > > My reasoning was that defining them doesn't really hurt because they are very small and inlined and the usage is slightly shorter and better to read (in my opinion). Maybe others are used more often in the future but if the defines are not there nobody will reuse them :-) > >> compile.hpp: >> >> add parenthesis around (++_nof_jump_tables): >> >> + float next_jump_table_freq() { return -1.0f * ++_nof_jump_tables; } > > Done. > >> compile.cpp: >> >> will you hit next assert if you have several jump-tables?: >> >> + else assert(!found_void, "wrong sorting"); > > No. All jump-table entries should have been sorted to the end of _constants so when we first hit a T_VOID entry we set found_void to true and only hit T_VOID's after that. If there is something else after a T_VOID the assert triggers. > > -- Chris > >> Vladimir >> >> Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7003454/ >>> 7003454: order constants in constant table by number of references in code >>> Reviewed-by: >>> Order constants in constant table by frequencies of references in code >>> and set constant table base that offsets to these frequently used >>> constants fit into the displacement range of load instructions. >>> src/share/vm/adlc/adlparse.cpp >>> src/share/vm/adlc/output_c.cpp >>> src/share/vm/asm/assembler.hpp >>> src/share/vm/opto/compile.cpp >>> src/share/vm/opto/compile.hpp >>> src/share/vm/opto/machnode.cpp >>> src/share/vm/opto/matcher.hpp >>> src/cpu/sparc/vm/sparc.ad >>> src/cpu/x86/vm/x86_32.ad >>> src/cpu/x86/vm/x86_64.ad >>> src/cpu/sparc/vm/assembler_sparc.hpp >>> src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp >>> src/cpu/sparc/vm/methodHandles_sparc.cpp >>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >>> src/cpu/sparc/vm/vtableStubs_sparc.cpp >>> src/cpu/x86/vm/assembler_x86.hpp >>> src/cpu/x86/vm/stubGenerator_x86_64.cpp > From christian.thalinger at oracle.com Wed Nov 9 06:30:13 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Nov 2011 15:30:13 +0100 Subject: Request for review (L): 7003454: order constants in constant table by number of references in code In-Reply-To: <4EBA8CCA.5090503@oracle.com> References: <9C9BF4BD-7CD5-4517-B629-D92629999D56@oracle.com> <4EB99220.2040401@oracle.com> <26B669D3-A61F-4CA6-875D-D0D249B015AB@oracle.com> <4EBA8CCA.5090503@oracle.com> Message-ID: <399EDDBA-3E82-44A6-89F9-74C720B28519@oracle.com> On Nov 9, 2011, at 3:23 PM, Vladimir Kozlov wrote: > >> will you hit next assert if you have several jump-tables?: > >> > >> + else assert(!found_void, "wrong sorting"); > > > > No. All jump-table entries should have been sorted to the end of _constants so when we first hit a T_VOID entry we set found_void to true and only hit T_VOID's after that. If there is something else after a T_VOID the assert triggers. > > Sorry, I was confused by code layout. Could you put it on separate lines?: > > + if (con.type() == T_VOID) > + found_void = true; // jump tables > + else > + assert(!found_void, "wrong sorting"); Sure. > > > Changes are good. Thank you, Tom and Vladimir, for the review. -- Chris > > Thanks, > Vladimir > > Christian Thalinger wrote: >> On Nov 8, 2011, at 9:33 PM, Vladimir Kozlov wrote: >>> Christian, >>> >>> assembler.hpp: >>> >>> I don't think we should have separate methods is_simmX() and min_simmX() for cases when it is used only one or 2 times. I would leave only frequently used one (min_simm13() is used only 3 times so it could be removed also): >>> >>> static int min_simm13() { return min_simm(13); } >>> >>> static bool is_simm13(intptr_t x) { return is_simm(x, 13); } >>> static bool is_simm16(intptr_t x) { return is_simm(x, 16); } >>> static bool is_simm32(intptr_t x) { return is_simm(x, 32); } >> My reasoning was that defining them doesn't really hurt because they are very small and inlined and the usage is slightly shorter and better to read (in my opinion). Maybe others are used more often in the future but if the defines are not there nobody will reuse them :-) >>> compile.hpp: >>> >>> add parenthesis around (++_nof_jump_tables): >>> >>> + float next_jump_table_freq() { return -1.0f * ++_nof_jump_tables; } >> Done. >>> compile.cpp: >>> >>> will you hit next assert if you have several jump-tables?: >>> >>> + else assert(!found_void, "wrong sorting"); >> No. All jump-table entries should have been sorted to the end of _constants so when we first hit a T_VOID entry we set found_void to true and only hit T_VOID's after that. If there is something else after a T_VOID the assert triggers. >> -- Chris >>> Vladimir >>> >>> Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/7003454/ >>>> 7003454: order constants in constant table by number of references in code >>>> Reviewed-by: >>>> Order constants in constant table by frequencies of references in code >>>> and set constant table base that offsets to these frequently used >>>> constants fit into the displacement range of load instructions. >>>> src/share/vm/adlc/adlparse.cpp >>>> src/share/vm/adlc/output_c.cpp >>>> src/share/vm/asm/assembler.hpp >>>> src/share/vm/opto/compile.cpp >>>> src/share/vm/opto/compile.hpp >>>> src/share/vm/opto/machnode.cpp >>>> src/share/vm/opto/matcher.hpp >>>> src/cpu/sparc/vm/sparc.ad >>>> src/cpu/x86/vm/x86_32.ad >>>> src/cpu/x86/vm/x86_64.ad >>>> src/cpu/sparc/vm/assembler_sparc.hpp >>>> src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp >>>> src/cpu/sparc/vm/methodHandles_sparc.cpp >>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >>>> src/cpu/sparc/vm/vtableStubs_sparc.cpp >>>> src/cpu/x86/vm/assembler_x86.hpp >>>> src/cpu/x86/vm/stubGenerator_x86_64.cpp From christian.thalinger at oracle.com Wed Nov 9 06:31:14 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Nov 2011 15:31:14 +0100 Subject: Request for reviews (S): 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot In-Reply-To: <4EBA8A13.6080009@oracle.com> References: <4EB9FDE4.8060202@oracle.com> <4EBA8A13.6080009@oracle.com> Message-ID: On Nov 9, 2011, at 3:11 PM, Vladimir Kozlov wrote: > Thank you, Christian > > Christian Thalinger wrote: >> Looks good. Just a question: is there no method that zeroes an array? > > I only know CollectedHeap::init_obj() but it will zero array's length and we need to avoid it since GC already known about this array (from thread->vm_result()). I saw CollectedHeap::init_obj() but I was curious if there is something else I missed. Thanks. -- Chris > > Thanks, > Vladimir > >> -- Chris >> On Nov 9, 2011, at 5:13 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7109887/webrev >>> >>> 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot >>> >>> In changes for 7081933 I forgot to zero array when compiled code is deoptimized. >>> >>> Tested with failed test. >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Wed Nov 9 07:15:58 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Nov 2011 07:15:58 -0800 Subject: Request for review (XS): 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not In-Reply-To: <64DF9BDB-7C30-44AC-A87C-946A7A27E91B@oracle.com> References: <64DF9BDB-7C30-44AC-A87C-946A7A27E91B@oracle.com> Message-ID: <4EBA992E.4040302@oracle.com> Why not generate direct call as we do we for hot call? Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7108383/ > > 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not > Reviewed-by: > > The problem is that the code in > PredictedDynamicCallGenerator::generate assumes that the generation of > the slow path always succeeds. This might not be the case when we hit > the node limit while generating the slow path. > > The suggested fix is to remove the assert and return on failed slow > path generations. > > I also applied the fix to PredictedCallGenerator::generate because I > think it can also happen there. > > src/share/vm/opto/callGenerator.cpp > From vladimir.kozlov at oracle.com Wed Nov 9 07:58:48 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Nov 2011 07:58:48 -0800 Subject: Request for reviews (M): 7105605: Use EA info to optimize pointers compare In-Reply-To: References: <4EBA013C.7020704@oracle.com> Message-ID: <4EBAA338.6050907@oracle.com> Thank you, Christian Christian Thalinger wrote: > On Nov 9, 2011, at 5:27 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7105605/webrev > > src/share/vm/opto/escape.cpp: > > You should set _pcmp_neq and _pcmp_eq to NULL in the ConnectionGraph constructor. Done. I also added assert in optimize_ptr_compare() to check that OptimizePtrCompare is set. > > ConnectionGraph::do_analysis: > > + Node* pcmp_neq = OptimizePtrCompare ? igvn->makecon(TypeInt::CC_GT) : NULL; > + Node* pcmp_eq = OptimizePtrCompare ? igvn->makecon(TypeInt::CC_EQ) : NULL; > > Are these two also added for the same reason as the comment says? > > // Add ConP#NULL and ConN#NULL nodes before ConnectionGraph construction > // to create space for them in ConnectionGraph::_nodes[]. > > Weird. In general sense they don't need to be created before ConnectionGraph construction since they are not oops and not part of constructed graph. But EA have several checks that C->_unique stays the same during graph construction and they will fail if pcmp_* nodes are added lazily. > > ConnectionGraph::optimize_ptr_compare: > > Is it intentional that the variables are called "has_unknow_obj1" instead of "unknown"? Typo and terrible name. I renamed it to set1_has_unknown_ptr. And renamed has_null_ptr1 to set1_has_null_ptr. > > Otherwise this looks good, as far as I can tell. Thanks, Vladimir > > -- Chris > >> 7105605: Use EA info to optimize pointers compare >> >> EA Connection Graph can help to optimize pointers compare for non escaping allocations. >> >> Tested with CTW, jtreg, NSK, refworkload. >> >> Thanks, >> Vladimir > From christian.thalinger at oracle.com Wed Nov 9 08:05:32 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Nov 2011 17:05:32 +0100 Subject: Request for reviews (M): 7105605: Use EA info to optimize pointers compare In-Reply-To: <4EBAA338.6050907@oracle.com> References: <4EBA013C.7020704@oracle.com> <4EBAA338.6050907@oracle.com> Message-ID: <31A5AFF1-F2F7-4287-8B2A-084D6AA00DA2@oracle.com> On Nov 9, 2011, at 4:58 PM, Vladimir Kozlov wrote: > Thank you, Christian > > Christian Thalinger wrote: >> On Nov 9, 2011, at 5:27 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7105605/webrev >> src/share/vm/opto/escape.cpp: >> You should set _pcmp_neq and _pcmp_eq to NULL in the ConnectionGraph constructor. > > Done. I also added assert in optimize_ptr_compare() to check that OptimizePtrCompare is set. > >> ConnectionGraph::do_analysis: >> + Node* pcmp_neq = OptimizePtrCompare ? igvn->makecon(TypeInt::CC_GT) : NULL; >> + Node* pcmp_eq = OptimizePtrCompare ? igvn->makecon(TypeInt::CC_EQ) : NULL; >> Are these two also added for the same reason as the comment says? >> // Add ConP#NULL and ConN#NULL nodes before ConnectionGraph construction >> // to create space for them in ConnectionGraph::_nodes[]. >> Weird. > > In general sense they don't need to be created before ConnectionGraph construction since they are not oops and not part of constructed graph. But EA have several checks that C->_unique stays the same during graph construction and they will fail if pcmp_* nodes are added lazily. I see. Thanks for the explanation. > >> ConnectionGraph::optimize_ptr_compare: >> Is it intentional that the variables are called "has_unknow_obj1" instead of "unknown"? > > Typo and terrible name. I renamed it to set1_has_unknown_ptr. And renamed has_null_ptr1 to set1_has_null_ptr. Better :-) -- Chris > >> Otherwise this looks good, as far as I can tell. > > Thanks, > Vladimir > >> -- Chris >>> 7105605: Use EA info to optimize pointers compare >>> >>> EA Connection Graph can help to optimize pointers compare for non escaping allocations. >>> >>> Tested with CTW, jtreg, NSK, refworkload. >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Wed Nov 9 08:12:33 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Nov 2011 08:12:33 -0800 Subject: Request for reviews (M): 7105605: Use EA info to optimize pointers compare In-Reply-To: <31A5AFF1-F2F7-4287-8B2A-084D6AA00DA2@oracle.com> References: <4EBA013C.7020704@oracle.com> <4EBAA338.6050907@oracle.com> <31A5AFF1-F2F7-4287-8B2A-084D6AA00DA2@oracle.com> Message-ID: <4EBAA671.4070603@oracle.com> >> In general sense they don't need to be created before ConnectionGraph construction since they are not oops and not part of constructed graph. But EA have several checks that C->_unique stays the same during graph construction and they will fail if pcmp_* nodes are added lazily. > > I see. Thanks for the explanation. I am taking this back. They are used only after Connection Graph construction so they don't need to be pregenerated. I will change this code and run tests to verify. Thanks again. Vladimir Christian Thalinger wrote: > On Nov 9, 2011, at 4:58 PM, Vladimir Kozlov wrote: > >> Thank you, Christian >> >> Christian Thalinger wrote: >>> On Nov 9, 2011, at 5:27 AM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7105605/webrev >>> src/share/vm/opto/escape.cpp: >>> You should set _pcmp_neq and _pcmp_eq to NULL in the ConnectionGraph constructor. >> Done. I also added assert in optimize_ptr_compare() to check that OptimizePtrCompare is set. >> >>> ConnectionGraph::do_analysis: >>> + Node* pcmp_neq = OptimizePtrCompare ? igvn->makecon(TypeInt::CC_GT) : NULL; >>> + Node* pcmp_eq = OptimizePtrCompare ? igvn->makecon(TypeInt::CC_EQ) : NULL; >>> Are these two also added for the same reason as the comment says? >>> // Add ConP#NULL and ConN#NULL nodes before ConnectionGraph construction >>> // to create space for them in ConnectionGraph::_nodes[]. >>> Weird. >> In general sense they don't need to be created before ConnectionGraph construction since they are not oops and not part of constructed graph. But EA have several checks that C->_unique stays the same during graph construction and they will fail if pcmp_* nodes are added lazily. > > I see. Thanks for the explanation. > >>> ConnectionGraph::optimize_ptr_compare: >>> Is it intentional that the variables are called "has_unknow_obj1" instead of "unknown"? >> Typo and terrible name. I renamed it to set1_has_unknown_ptr. And renamed has_null_ptr1 to set1_has_null_ptr. > > Better :-) > > -- Chris > >>> Otherwise this looks good, as far as I can tell. >> Thanks, >> Vladimir >> >>> -- Chris >>>> 7105605: Use EA info to optimize pointers compare >>>> >>>> EA Connection Graph can help to optimize pointers compare for non escaping allocations. >>>> >>>> Tested with CTW, jtreg, NSK, refworkload. >>>> >>>> Thanks, >>>> Vladimir > From vladimir.kozlov at oracle.com Wed Nov 9 08:42:09 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 09 Nov 2011 16:42:09 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot Message-ID: <20111109164213.C90ED472AB@hg.openjdk.java.net> Changeset: 7e0e43cf86d6 Author: kvn Date: 2011-11-09 06:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7e0e43cf86d6 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot Summary: zero array when compiled code is deoptimized. Reviewed-by: never, twisti ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp From tom.rodriguez at oracle.com Wed Nov 9 09:41:48 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 9 Nov 2011 09:41:48 -0800 Subject: Request for review (XS): 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not In-Reply-To: <64DF9BDB-7C30-44AC-A87C-946A7A27E91B@oracle.com> References: <64DF9BDB-7C30-44AC-A87C-946A7A27E91B@oracle.com> Message-ID: <7F916F0D-B81C-4B4F-8DEA-C3380DDCDE41@oracle.com> looks ok. tom On Nov 9, 2011, at 5:31 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7108383/ > > 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not > Reviewed-by: > > The problem is that the code in > PredictedDynamicCallGenerator::generate assumes that the generation of > the slow path always succeeds. This might not be the case when we hit > the node limit while generating the slow path. > > The suggested fix is to remove the assert and return on failed slow > path generations. > > I also applied the fix to PredictedCallGenerator::generate because I > think it can also happen there. > > src/share/vm/opto/callGenerator.cpp > From tom.rodriguez at oracle.com Wed Nov 9 10:06:31 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 9 Nov 2011 10:06:31 -0800 Subject: Request for reviews (M): 7105605: Use EA info to optimize pointers compare In-Reply-To: <4EBA013C.7020704@oracle.com> References: <4EBA013C.7020704@oracle.com> Message-ID: <05D42008-A273-4E81-9D6D-4FA6B1D2720B@oracle.com> I like the renaming you did in optimize_ptr_compare. This comment: + // Check if one set has only not escaping allocations. seems like it needs more detail explaining why that's important. I presume it's because if they are all non-escaping then they must be disjoint from the other set. Is that right? Does the _scalar_replaceable flag change any of this? I thought if that was false then we might lose track of the identity of the object. How effective is this at eliminating compares? Is it useful even if there aren't non-escaping object? tom On Nov 8, 2011, at 8:27 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7105605/webrev > > 7105605: Use EA info to optimize pointers compare > > EA Connection Graph can help to optimize pointers compare for non escaping allocations. > > Tested with CTW, jtreg, NSK, refworkload. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Nov 9 11:27:51 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Nov 2011 11:27:51 -0800 Subject: Request for reviews (M): 7105605: Use EA info to optimize pointers compare In-Reply-To: <05D42008-A273-4E81-9D6D-4FA6B1D2720B@oracle.com> References: <4EBA013C.7020704@oracle.com> <05D42008-A273-4E81-9D6D-4FA6B1D2720B@oracle.com> Message-ID: <4EBAD437.3070504@oracle.com> Thank you, Tom Tom Rodriguez wrote: > I like the renaming you did in optimize_ptr_compare. This comment: > > + // Check if one set has only not escaping allocations. > > seems like it needs more detail explaining why that's important. I presume it's because if they are all non-escaping then they must be disjoint from the other set. Is that right? There is explicit disjoint check (!ptset1.disjoint(ptset2)) before that code. It guaranties that not escaping allocations from one set are not present in second set. And they did not lost their identity since they did not escape. > Does the _scalar_replaceable flag change any of this? I thought if that was false then we might lose track of the identity of the object. No, if Connection Graph is correct. I actually hit problem today with OSR state loads which were not marked as loads of unknown object. The condition "set has only not escaping allocations" means java code merged only non escaping allocations and Connection Graph knowns which allocations. > > How effective is this at eliminating compares? Is it useful even if there aren't non-escaping object? Unfortunately I don't see improvement in refworkload. I added test case which shows that this optimization eliminates next check in HashMap.get(): (k = e.key) == key But in JBB it is already eliminated by EliminateAutoBox optimization. Thanks, Vladimir > > tom > > On Nov 8, 2011, at 8:27 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7105605/webrev >> >> 7105605: Use EA info to optimize pointers compare >> >> EA Connection Graph can help to optimize pointers compare for non escaping allocations. >> >> Tested with CTW, jtreg, NSK, refworkload. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Wed Nov 9 12:50:49 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 09 Nov 2011 20:50:49 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7107042: assert(no_dead_loop) failed: dead loop detected Message-ID: <20111109205053.653C2472B0@hg.openjdk.java.net> Changeset: 670a74b863fc Author: kvn Date: 2011-11-09 07:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/670a74b863fc 7107042: assert(no_dead_loop) failed: dead loop detected Summary: Use dead nodes elimination code in PhaseIdealLoop before executing EA. Reviewed-by: never, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/runtime/globals.hpp From christian.thalinger at oracle.com Thu Nov 10 03:28:38 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Nov 2011 12:28:38 +0100 Subject: Request for review (XS): 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not In-Reply-To: <4EBA992E.4040302@oracle.com> References: <64DF9BDB-7C30-44AC-A87C-946A7A27E91B@oracle.com> <4EBA992E.4040302@oracle.com> Message-ID: <20F584B3-2522-4A24-9300-832C875E704F@oracle.com> On Nov 9, 2011, at 4:15 PM, Vladimir Kozlov wrote: > Why not generate direct call as we do we for hot call? I had a small chat with John about that yesterday. Maybe moving the logic into its own function that returns a direct/dynamic call instead of null when the inlining fails is in general a good idea (especially for the selectAlternative idiom). I updated the webrev with that code. But in this particular case it doesn't help since we are so close (or already over) the threshold cliff that it fails anyway. Let me know what you think. -- Chris > > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7108383/ >> 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not >> Reviewed-by: >> The problem is that the code in >> PredictedDynamicCallGenerator::generate assumes that the generation of >> the slow path always succeeds. This might not be the case when we hit >> the node limit while generating the slow path. >> The suggested fix is to remove the assert and return on failed slow >> path generations. >> I also applied the fix to PredictedCallGenerator::generate because I >> think it can also happen there. >> src/share/vm/opto/callGenerator.cpp From sebastian.sickelmann at gmx.de Thu Nov 10 06:14:23 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Thu, 10 Nov 2011 15:14:23 +0100 Subject: Accessing Annotations Message-ID: <4EBBDC3F.1060000@gmx.de> Hi, i actually explore how i could implement "Removing public fields without breaking binary compatibility"[0][1][2] inside of the vm. In [0] i made an early prototype with annotations and class-weaving(changing) at load-time. Now i want to shift this prototype to an inside-the-vm implementation. The first place i ran into is the verifier. Here i need to return true if there is are methods annotated with the new AccessorMethod-Annotation (which i made part of java/lang in my private openjdk clone). Just for completeness: the methods parameters and return value must fit to the expected field (said in other words "one get and one set method"). I tried to hack on Reflection::verify_field_access and added something like this[3] to access the methods and their annotations. I tried it in various ways (and after some errors on my side) i get an typeArrayOop/typeArrayKlass which i think i can access the annotations. Asking the typeArrayKlass for its name/external-name/dimensions answers [B/[B/1 which seems to be an one-dimensional byte-array. Is this the structure of the RuntimeVisibleAnnotation described in class-file-spec[4]? Must i access its byte content and parse it, or have i missed an "annotationKlass" impl? If i first must implement such a annotationKlass-implementation. Is there a good starting for this? Some hints to get me working on this again would be fine. Kind regards Sebastian [0] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-October/000199.html [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-September/007676.html [2] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ [3] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/compatiblefieldaccess/question1-2011-11-10/index.html [4] http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf From christian.thalinger at oracle.com Thu Nov 10 08:02:16 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 10 Nov 2011 16:02:16 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 27 new changesets Message-ID: <20111110160317.B6878472EC@hg.openjdk.java.net> Changeset: ec4b032a4977 Author: tonyp Date: 2011-10-13 13:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ec4b032a4977 7098085: G1: partially-young GCs not initiated under certain circumstances Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: 074f0252cc13 Author: tonyp Date: 2011-10-14 11:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/074f0252cc13 7088680: G1: Cleanup in the G1CollectorPolicy class Summary: Removed unused fields and methods, removed the G1CollectoryPolicy_BestRegionsFirst class and folded its functionality into the G1CollectorPolicy class. Reviewed-by: ysr, brutisso, jcoomes ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/memory/universe.cpp Changeset: bf2d2b8b1726 Author: johnc Date: 2011-10-17 09:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bf2d2b8b1726 7095243: Disambiguate ReferenceProcessor::_discoveredSoftRefs Summary: Add a new, separate, pointer to the base of the array of discovered reference lists and use this new pointer in places where we iterate over the entire array. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: 647872693572 Author: tonyp Date: 2011-10-21 07:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/647872693572 Merge Changeset: 3170e4044f2d Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3170e4044f2d Added tag jdk8-b10 for changeset d815de2e85e5 ! .hgtags Changeset: 4d3850d9d326 Author: jcoomes Date: 2011-10-21 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4d3850d9d326 Merge - make/templates/bsd-header Changeset: 4538caeef7b6 Author: jcoomes Date: 2011-10-21 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4538caeef7b6 Added tag hs23-b03 for changeset 4d3850d9d326 ! .hgtags Changeset: c9d25d93ddfe Author: jcoomes Date: 2011-10-21 16:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c9d25d93ddfe 7103619: Bump the hs23 build number to 04 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5e5d4821bf07 Author: brutisso Date: 2011-10-20 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5e5d4821bf07 7097516: G1: assert(0<= from_card && from_card ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/gcc.make ! make/windows/makefiles/vm.make - src/share/vm/precompiled.hpp + src/share/vm/precompiled/precompiled.hpp Changeset: ddb34559f9a7 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ddb34559f9a7 Added tag jdk8-b12 for changeset 1d3900713a67 ! .hgtags Changeset: 3e609627e780 Author: jcoomes Date: 2011-11-04 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3e609627e780 Merge - src/share/vm/precompiled.hpp Changeset: b92ca8e229d2 Author: jcoomes Date: 2011-11-04 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b92ca8e229d2 Added tag hs23-b05 for changeset 3e609627e780 ! .hgtags Changeset: 869804b759e7 Author: jcoomes Date: 2011-11-04 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/869804b759e7 7108553: Bump the hs23 build number to 06 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 78bef05801ca Author: twisti Date: 2011-11-10 04:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78bef05801ca Merge - src/share/vm/precompiled.hpp ! src/share/vm/runtime/globals.hpp From vladimir.kozlov at oracle.com Thu Nov 10 09:00:23 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Nov 2011 09:00:23 -0800 Subject: Request for review (XS): 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not In-Reply-To: <20F584B3-2522-4A24-9300-832C875E704F@oracle.com> References: <64DF9BDB-7C30-44AC-A87C-946A7A27E91B@oracle.com> <4EBA992E.4040302@oracle.com> <20F584B3-2522-4A24-9300-832C875E704F@oracle.com> Message-ID: <4EBC0327.6050108@oracle.com> You can check failing() and return NULL in that case (most cases) otherwise generate direct call if inlining failed for an other reason. I still do not get why hot path do not do it, it also can fail because of nodes threshold. Vladimir On 11/10/11 3:28 AM, Christian Thalinger wrote: > > On Nov 9, 2011, at 4:15 PM, Vladimir Kozlov wrote: > >> Why not generate direct call as we do we for hot call? > > I had a small chat with John about that yesterday. Maybe moving the logic into its own function that returns a direct/dynamic call instead of null when the inlining fails is in general a good idea (especially for the selectAlternative idiom). I updated the webrev with that code. > > But in this particular case it doesn't help since we are so close (or already over) the threshold cliff that it fails anyway. Let me know what you think. > > -- Chris > > >> >> Vladimir >> >> Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7108383/ >>> 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not >>> Reviewed-by: >>> The problem is that the code in >>> PredictedDynamicCallGenerator::generate assumes that the generation of >>> the slow path always succeeds. This might not be the case when we hit >>> the node limit while generating the slow path. >>> The suggested fix is to remove the assert and return on failed slow >>> path generations. >>> I also applied the fix to PredictedCallGenerator::generate because I >>> think it can also happen there. >>> src/share/vm/opto/callGenerator.cpp > From tom.rodriguez at oracle.com Thu Nov 10 11:25:43 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 10 Nov 2011 11:25:43 -0800 Subject: Request for reviews (M): 7105605: Use EA info to optimize pointers compare In-Reply-To: <4EBAD437.3070504@oracle.com> References: <4EBA013C.7020704@oracle.com> <05D42008-A273-4E81-9D6D-4FA6B1D2720B@oracle.com> <4EBAD437.3070504@oracle.com> Message-ID: On Nov 9, 2011, at 11:27 AM, Vladimir Kozlov wrote: > Thank you, Tom > > Tom Rodriguez wrote: >> I like the renaming you did in optimize_ptr_compare. This comment: >> + // Check if one set has only not escaping allocations. >> seems like it needs more detail explaining why that's important. I presume it's because if they are all non-escaping then they must be disjoint from the other set. Is that right? > > There is explicit disjoint check (!ptset1.disjoint(ptset2)) before that code. It guaranties that not escaping allocations from one set are not present in second set. And they did not lost their identity since they did not escape. Then I'm unclear what this logic is trying to capture. Can you give me an example? tom > >> Does the _scalar_replaceable flag change any of this? I thought if that was false then we might lose track of the identity of the object. > > No, if Connection Graph is correct. I actually hit problem today with OSR state loads which were not marked as loads of unknown object. > > The condition "set has only not escaping allocations" means java code merged only non escaping allocations and Connection Graph knowns which allocations. > >> How effective is this at eliminating compares? Is it useful even if there aren't non-escaping object? > > Unfortunately I don't see improvement in refworkload. I added test case which shows that this optimization eliminates next check in HashMap.get(): > (k = e.key) == key > > But in JBB it is already eliminated by EliminateAutoBox optimization. > > Thanks, > Vladimir > >> tom >> On Nov 8, 2011, at 8:27 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7105605/webrev >>> >>> 7105605: Use EA info to optimize pointers compare >>> >>> EA Connection Graph can help to optimize pointers compare for non escaping allocations. >>> >>> Tested with CTW, jtreg, NSK, refworkload. >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Thu Nov 10 13:14:47 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Nov 2011 13:14:47 -0800 Subject: Request for reviews (M): 7105605: Use EA info to optimize pointers compare In-Reply-To: References: <4EBA013C.7020704@oracle.com> <05D42008-A273-4E81-9D6D-4FA6B1D2720B@oracle.com> <4EBAD437.3070504@oracle.com> Message-ID: <4EBC3EC7.4020609@oracle.com> intelsdv39% cat A.java public class A { A next; // Use -XX:CompileCommand=exclude,A.foo static void foo(A a, int x) { if (x > 0) { a.next = null; } } static int test(int x) { A a0 = new A(); // argument escape A a1 = new A(); // argument escape A a2 = new A(); // not escaping but not scalar replaceable A a3 = new A(); // not escaping but not scalar replaceable if (x > 0) { a0.next = a1; a2 = a3; } foo(a0, x); // Do not inline if (a2 == a3) { // Can not eliminate return 3; } if (a0.next == a1) { // Can not eliminate return 1; } if (a0.next == a2) { // Can eliminate!!! return 2; } return 0; } public static void main(String args[]) { int x = 0; for (int i=0; i<10000; i++) { x = test(i&1); } } } intelsdv39% gamma -Xbatch -XX:+OptimizePtrCompare -XX:+PrintCompilation -XX:CICompilerCount=1 -XX:+PrintOptimizePtrCompare -XX:+Verbose -XX:CompileCommand=exclude,A.foo A Using java runtime at: /export/kvn/jdk7u2/jre VM option '+OptimizePtrCompare' VM option '+PrintCompilation' VM option 'CICompilerCount=1' VM option '+PrintOptimizePtrCompare' VM option '+Verbose' VM option 'CompileCommand=exclude,A.foo' CompilerOracle: exclude A.foo 875 1 b java.lang.Object:: (1 bytes) 915 2 b A:: (5 bytes) java.lang.Object:: (1 bytes) 921 3 b A::test (80 bytes) A:: (5 bytes) java.lang.Object:: (1 bytes) A:: (5 bytes) java.lang.Object:: (1 bytes) A:: (5 bytes) java.lang.Object:: (1 bytes) A:: (5 bytes) java.lang.Object:: (1 bytes) ++++ Replaced: 312 CmpP(296,272) --> NotEQ 272 Phi === 258 215 161 [[ 287 273 312 305 319 ]] Oop:A:NotNull:exact * !jvms: A::test @ bci:45 296 LoadP === _ 276 260 [[ 305 297 319 312 ]] @A:BotPTR+8 *, name=next, idx=4; Oop:A:BotPTR * !jvms: A::test @ bci:59 312 CmpP === _ 296 272 [[ 313 ]] Type:int:-1..1 !jvms: A::test @ bci:73 ### Excluding compile: static A::foo Tom Rodriguez wrote: > On Nov 9, 2011, at 11:27 AM, Vladimir Kozlov wrote: > >> Thank you, Tom >> >> Tom Rodriguez wrote: >>> I like the renaming you did in optimize_ptr_compare. This comment: >>> + // Check if one set has only not escaping allocations. >>> seems like it needs more detail explaining why that's important. I presume it's because if they are all non-escaping then they must be disjoint from the other set. Is that right? >> There is explicit disjoint check (!ptset1.disjoint(ptset2)) before that code. It guaranties that not escaping allocations from one set are not present in second set. And they did not lost their identity since they did not escape. > > Then I'm unclear what this logic is trying to capture. Can you give me an example? > > tom > >>> Does the _scalar_replaceable flag change any of this? I thought if that was false then we might lose track of the identity of the object. >> No, if Connection Graph is correct. I actually hit problem today with OSR state loads which were not marked as loads of unknown object. >> >> The condition "set has only not escaping allocations" means java code merged only non escaping allocations and Connection Graph knowns which allocations. >> >>> How effective is this at eliminating compares? Is it useful even if there aren't non-escaping object? >> Unfortunately I don't see improvement in refworkload. I added test case which shows that this optimization eliminates next check in HashMap.get(): >> (k = e.key) == key >> >> But in JBB it is already eliminated by EliminateAutoBox optimization. >> >> Thanks, >> Vladimir >> >>> tom >>> On Nov 8, 2011, at 8:27 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7105605/webrev >>>> >>>> 7105605: Use EA info to optimize pointers compare >>>> >>>> EA Connection Graph can help to optimize pointers compare for non escaping allocations. >>>> >>>> Tested with CTW, jtreg, NSK, refworkload. >>>> >>>> Thanks, >>>> Vladimir > From vladimir.kozlov at oracle.com Thu Nov 10 19:05:24 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Nov 2011 19:05:24 -0800 Subject: Request for reviews (XS): 7110586: C2 generates incorrect results Message-ID: <4EBC90F4.7000900@oracle.com> http://cr.openjdk.java.net/~kvn/7110586/webrev 7110586: C2 generates incorrect results Regression after 5091921 fix. Exact limit of empty loop calculated incorrectly. Added regression test. Thanks, Vladimir From igor.veresov at oracle.com Thu Nov 10 19:29:18 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 10 Nov 2011 19:29:18 -0800 Subject: Request for reviews (XS): 7110586: C2 generates incorrect results In-Reply-To: <4EBC90F4.7000900@oracle.com> References: <4EBC90F4.7000900@oracle.com> Message-ID: Looks good! igor On Thursday, November 10, 2011 at 7:05 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7110586/webrev > > 7110586: C2 generates incorrect results > > Regression after 5091921 fix. Exact limit of empty loop calculated incorrectly. > > Added regression test. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Nov 10 19:28:26 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Nov 2011 19:28:26 -0800 Subject: Request for reviews (XS): 7110586: C2 generates incorrect results In-Reply-To: References: <4EBC90F4.7000900@oracle.com> Message-ID: <4EBC965A.3020007@oracle.com> Thank you, Igor Vladimir Igor Veresov wrote: > Looks good! > > igor > > > On Thursday, November 10, 2011 at 7:05 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7110586/webrev >> >> 7110586: C2 generates incorrect results >> >> Regression after 5091921 fix. Exact limit of empty loop calculated incorrectly. >> >> Added regression test. >> >> Thanks, >> Vladimir > > > From tom.rodriguez at oracle.com Thu Nov 10 19:42:37 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 10 Nov 2011 19:42:37 -0800 Subject: Request for reviews (XS): 7110586: C2 generates incorrect results In-Reply-To: <4EBC90F4.7000900@oracle.com> References: <4EBC90F4.7000900@oracle.com> Message-ID: Looks good. tom On Nov 10, 2011, at 7:05 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7110586/webrev > > 7110586: C2 generates incorrect results > > Regression after 5091921 fix. Exact limit of empty loop calculated incorrectly. > > Added regression test. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Nov 10 19:40:15 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Nov 2011 19:40:15 -0800 Subject: Request for reviews (XS): 7110586: C2 generates incorrect results In-Reply-To: References: <4EBC90F4.7000900@oracle.com> Message-ID: <4EBC991F.50603@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Nov 10, 2011, at 7:05 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7110586/webrev >> >> 7110586: C2 generates incorrect results >> >> Regression after 5091921 fix. Exact limit of empty loop calculated incorrectly. >> >> Added regression test. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Thu Nov 10 23:29:50 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Nov 2011 07:29:50 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7110586: C2 generates incorrect results Message-ID: <20111111072953.25E7147310@hg.openjdk.java.net> Changeset: e8fdaf4a66cb Author: kvn Date: 2011-11-10 20:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e8fdaf4a66cb 7110586: C2 generates incorrect results Summary: Exact limit of empty loop calculated incorrectly. Reviewed-by: iveresov, never ! src/share/vm/opto/loopnode.cpp + test/compiler/7110586/Test7110586.java From tom.rodriguez at oracle.com Fri Nov 11 12:50:59 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 11 Nov 2011 12:50:59 -0800 Subject: review for 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable Message-ID: http://cr.openjdk.java.net/~never/7110489 44 lines changed: 24 ins; 18 del; 2 mod; 13050 unchg 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable Reviewed-by: The ForceUnreachable flag hadn't been tested broadly on x64 and in this particular failure, there's a mismatch between is_polling_page_far and reachable which causes the assertion failure. I also lowered the buffer limit of x64 too much which resulted in failures so I've raised the limit back up to 120000 for debug x64. The method handle adapters lazily generated so only actual method handles tests verify that the buffer was properly generated. I modified the JVM to force the generation during bootstrap and ran it through JPRT with +ForceUnreachable. This exposed a separate problem in the arraycopy stubs on windows where the rscratch1 (r10) is being used to preseve rsi and the increment of the copy counters can blow it away if the counter isn't reachable. I fixed this be reordering the counter updates to be after the restore of rsi. From vladimir.kozlov at oracle.com Fri Nov 11 13:30:06 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Nov 2011 13:30:06 -0800 Subject: review for 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable In-Reply-To: References: Message-ID: <4EBD93DE.4060405@oracle.com> Looks good. Thanks, vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7110489 > 44 lines changed: 24 ins; 18 del; 2 mod; 13050 unchg > > 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable > Reviewed-by: > > The ForceUnreachable flag hadn't been tested broadly on x64 and in > this particular failure, there's a mismatch between > is_polling_page_far and reachable which causes the assertion failure. > I also lowered the buffer limit of x64 too much which resulted in > failures so I've raised the limit back up to 120000 for debug x64. > The method handle adapters lazily generated so only actual method > handles tests verify that the buffer was properly generated. I > modified the JVM to force the generation during bootstrap and ran it > through JPRT with +ForceUnreachable. This exposed a separate problem > in the arraycopy stubs on windows where the rscratch1 (r10) is being > used to preseve rsi and the increment of the copy counters can blow it > away if the counter isn't reachable. I fixed this be reordering the > counter updates to be after the restore of rsi. > From igor.veresov at oracle.com Fri Nov 11 16:36:16 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 11 Nov 2011 16:36:16 -0800 Subject: review for 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable In-Reply-To: References: Message-ID: <799C2467DF1E4E248D5390709683DEBC@oracle.com> Looks good. igor On Friday, November 11, 2011 at 12:50 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7110489 > 44 lines changed: 24 ins; 18 del; 2 mod; 13050 unchg > > 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable > Reviewed-by: > > The ForceUnreachable flag hadn't been tested broadly on x64 and in > this particular failure, there's a mismatch between > is_polling_page_far and reachable which causes the assertion failure. > I also lowered the buffer limit of x64 too much which resulted in > failures so I've raised the limit back up to 120000 for debug x64. > The method handle adapters lazily generated so only actual method > handles tests verify that the buffer was properly generated. I > modified the JVM to force the generation during bootstrap and ran it > through JPRT with +ForceUnreachable. This exposed a separate problem > in the arraycopy stubs on windows where the rscratch1 (r10) is being > used to preseve rsi and the increment of the copy counters can blow it > away if the counter isn't reachable. I fixed this be reordering the > counter updates to be after the restore of rsi. From sebastian.sickelmann at gmx.de Sun Nov 13 20:18:33 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Mon, 14 Nov 2011 05:18:33 +0100 Subject: Accessing Annotations In-Reply-To: <4EBBDC3F.1060000@gmx.de> References: <4EBBDC3F.1060000@gmx.de> Message-ID: <4EC09699.8090702@gmx.de> Hi, i unfortunatly send my previous mail to hs-comp-dev but i think it should be hs-runtime-dev. So crossposting hs-comp-dev here to end the thread and move to hs-runtime-dev. I found the a part of the answer by myself. The bytes of the typeArray are exactly the bytes after the attribute_length field in RuntimeVisibleAnnotations_attribute from Classfile-Spec. RuntimeVisibleAnnotations_attribute { u2 attribute_name_index; u4 attribute_length; u2 num_annotations; annotation annotations[num_annotations]; } I checked the indices it with the constant-pool and it matches exactly with my expectations. The second-part of my question is still unanswered and i hope to get some hint. I want to implement a class that helps me processing the annotation(type-array), my idea is to create a annotationKlass class so that i can code something like this: annotationKlass::cast(typeArrayOop annotationTypeArray) and some accessory methods to easiliy work with annotations inside the vm. Or is there any implementation that does the annotation access-part that i haven't found yet? -- Sebastian Am 10.11.2011 15:14, schrieb Sebastian Sickelmann: > Hi, > > i actually explore how i could implement > "Removing public fields without breaking binary > compatibility"[0][1][2] inside of the vm. > > In [0] i made an early prototype with annotations and > class-weaving(changing) at load-time. > Now i want to shift this prototype to an inside-the-vm implementation. > > The first place i ran into is the verifier. Here i need to return true > if there is are methods > annotated with the new AccessorMethod-Annotation (which i made part of > java/lang in my > private openjdk clone). Just for completeness: the methods parameters > and return value must > fit to the expected field (said in other words "one get and one set > method"). > > I tried to hack on Reflection::verify_field_access and added something > like this[3] to access the > methods and their annotations. I tried it in various ways (and after > some errors on my side) i > get an typeArrayOop/typeArrayKlass which i think i can access the > annotations. Asking the > typeArrayKlass for its name/external-name/dimensions answers [B/[B/1 > which seems to be an > one-dimensional byte-array. Is this the structure of the > RuntimeVisibleAnnotation described in > class-file-spec[4]? > > > Must i access its byte content and parse it, or have i missed an > "annotationKlass" impl? > > If i first must implement such a annotationKlass-implementation. Is > there a good starting for this? > > > Some hints to get me working on this again would be fine. > > Kind regards > Sebastian > > [0] > http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-October/000199.html > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-September/007676.html > > [2] > http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ > [3] > http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/compatiblefieldaccess/question1-2011-11-10/index.html > [4] > http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf From christian.thalinger at oracle.com Mon Nov 14 01:19:28 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Nov 2011 10:19:28 +0100 Subject: review for 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable In-Reply-To: References: Message-ID: Looks good. -- Chris On Nov 11, 2011, at 9:50 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7110489 > 44 lines changed: 24 ins; 18 del; 2 mod; 13050 unchg > > 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable > Reviewed-by: > > The ForceUnreachable flag hadn't been tested broadly on x64 and in > this particular failure, there's a mismatch between > is_polling_page_far and reachable which causes the assertion failure. > I also lowered the buffer limit of x64 too much which resulted in > failures so I've raised the limit back up to 120000 for debug x64. > The method handle adapters lazily generated so only actual method > handles tests verify that the buffer was properly generated. I > modified the JVM to force the generation during bootstrap and ran it > through JPRT with +ForceUnreachable. This exposed a separate problem > in the arraycopy stubs on windows where the rscratch1 (r10) is being > used to preseve rsi and the increment of the copy counters can blow it > away if the counter isn't reachable. I fixed this be reordering the > counter updates to be after the restore of rsi. > From vladimir.kozlov at oracle.com Mon Nov 14 18:28:23 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Nov 2011 18:28:23 -0800 Subject: Request for reviews (M): 6890673: Eliminate allocations immediately after EA Message-ID: <4EC1CE47.9060300@oracle.com> http://cr.openjdk.java.net/~kvn/6890673/webrev 6890673: Eliminate allocations immediately after EA Currently non-escaping allocations and corresponding locks are eliminated during macro nodes expansion after all ideal and loop optimizations which may prevent to do more aggressive (loop and split-if) optimizations. Try to eliminate allocations and related locks immediately after escape analysis. Move elimination code into new separate method PhaseMacroExpand::eliminate_macro_nodes(). The main problem was that SafePointScalarObject may be referenced by several safepoints which were cloned, for example, during loop unswitch. As result current checks that SPSO should be pinned and at the same block as safepoint failed. Nothing is wrong to have one SPSO node be referenced by several cloned safepoints since SPSO contains only class information and index of safepoin's debug info edge which should stay the same for cloned safepoints. The solution is to removed pinned attribute from SPSO node, use Root as control edge and add hash(), cmp() to not allow value-numbering of these nodes. Removed SPSO asserts in block.cpp and the rest is mostly code style clean up. Locks eliminated by "lock coarsening" optimization are treated differently during elimination since corresponding outer locks should stay. Such locks marked by "_coarsened" flag. EA should clean this flag for locks which could be eliminated because corresponding object does not escape. Don't bail out from build_and_optimize() until dead code is eliminated when it is called before EA even if there are no loops or there are only irreducible loops. Added missing (in(0)->is_top()) checks after remove_dead_region() calls. Thanks, Vladimir From vladimir.kozlov at oracle.com Mon Nov 14 20:56:25 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 15 Nov 2011 04:56:25 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7105605: Use EA info to optimize pointers compare Message-ID: <20111115045632.4209D47360@hg.openjdk.java.net> Changeset: 8c57262447d3 Author: kvn Date: 2011-11-14 18:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8c57262447d3 7105605: Use EA info to optimize pointers compare Summary: optimize pointers compare using EA information. Reviewed-by: never, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp From tom.rodriguez at oracle.com Tue Nov 15 13:42:23 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 15 Nov 2011 13:42:23 -0800 Subject: review for 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable In-Reply-To: References: Message-ID: <2DC7D7C1-3087-4D35-9042-C3B54530CF19@oracle.com> Thanks Vladimir, Igor and Chris. tom On Nov 14, 2011, at 1:19 AM, Christian Thalinger wrote: > Looks good. -- Chris > > On Nov 11, 2011, at 9:50 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/7110489 >> 44 lines changed: 24 ins; 18 del; 2 mod; 13050 unchg >> >> 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable >> Reviewed-by: >> >> The ForceUnreachable flag hadn't been tested broadly on x64 and in >> this particular failure, there's a mismatch between >> is_polling_page_far and reachable which causes the assertion failure. >> I also lowered the buffer limit of x64 too much which resulted in >> failures so I've raised the limit back up to 120000 for debug x64. >> The method handle adapters lazily generated so only actual method >> handles tests verify that the buffer was properly generated. I >> modified the JVM to force the generation during bootstrap and ran it >> through JPRT with +ForceUnreachable. This exposed a separate problem >> in the arraycopy stubs on windows where the rscratch1 (r10) is being >> used to preseve rsi and the increment of the copy counters can blow it >> away if the counter isn't reachable. I fixed this be reordering the >> counter updates to be after the restore of rsi. >> > From tom.rodriguez at oracle.com Tue Nov 15 14:30:33 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 15 Nov 2011 14:30:33 -0800 Subject: Request for reviews (M): 6890673: Eliminate allocations immediately after EA In-Reply-To: <4EC1CE47.9060300@oracle.com> References: <4EC1CE47.9060300@oracle.com> Message-ID: <0173C11D-5CC1-4EB7-9100-4AA262B5A3D6@oracle.com> On Nov 14, 2011, at 6:28 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6890673/webrev > > 6890673: Eliminate allocations immediately after EA > > Currently non-escaping allocations and corresponding locks are eliminated during macro nodes expansion after all ideal and loop optimizations which may prevent to do more aggressive (loop and split-if) optimizations. > > Try to eliminate allocations and related locks immediately after escape analysis. Move elimination code into new separate method PhaseMacroExpand::eliminate_macro_nodes(). > > The main problem was that SafePointScalarObject may be referenced by several safepoints which were cloned, for example, during loop unswitch. As result current checks that SPSO should be pinned and at the same block as safepoint failed. Nothing is wrong to have one SPSO node be referenced by several cloned safepoints since SPSO contains only class information and index of safepoin's debug info edge which should stay the same for cloned safepoints. The solution is to removed pinned attribute from SPSO node, use Root as control edge and add hash(), cmp() to not allow value-numbering of these nodes. > > Removed SPSO asserts in block.cpp and the rest is mostly code style clean up. > > Locks eliminated by "lock coarsening" optimization are treated differently during elimination since corresponding outer locks should stay. Such locks marked by "_coarsened" flag. EA should clean this flag for locks which could be eliminated because corresponding object does not escape. > > Don't bail out from build_and_optimize() until dead code is eliminated when it is called before EA even if there are no loops or there are only irreducible loops. > > Added missing (in(0)->is_top()) checks after remove_dead_region() calls. Should this idiom: if( in(0) && remove_dead_region(phase, can_reshape) ) return this; // Don't bother trying to transform a dead node if( in(0) && in(0)->is_top() ) return NULL; be handled in a more systematic way instead of being sprinkled about? There are many Ideal functions that consist only of the first part which says that me that it's really part of the code transform loop instead of being a responsibility of Ideal itself. Maybe that's for a more broad cleanup in the future. Otherwise it looks good. tom > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Nov 15 14:48:59 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Nov 2011 14:48:59 -0800 Subject: Request for reviews (M): 6890673: Eliminate allocations immediately after EA In-Reply-To: <0173C11D-5CC1-4EB7-9100-4AA262B5A3D6@oracle.com> References: <4EC1CE47.9060300@oracle.com> <0173C11D-5CC1-4EB7-9100-4AA262B5A3D6@oracle.com> Message-ID: <4EC2EC5B.9070106@oracle.com> Thank you, Tom I filed RFE 7112269: cleanup remove_dead_region() usage I agree that it should be called and checked for TOP in PhaseGVN::transform_no_reclaim() and PhaseIterGVN::transform_old() to be consistent for all ideal nodes. Thanks, Vladimir Tom Rodriguez wrote: > On Nov 14, 2011, at 6:28 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6890673/webrev >> >> 6890673: Eliminate allocations immediately after EA >> >> Currently non-escaping allocations and corresponding locks are eliminated during macro nodes expansion after all ideal and loop optimizations which may prevent to do more aggressive (loop and split-if) optimizations. >> >> Try to eliminate allocations and related locks immediately after escape analysis. Move elimination code into new separate method PhaseMacroExpand::eliminate_macro_nodes(). >> >> The main problem was that SafePointScalarObject may be referenced by several safepoints which were cloned, for example, during loop unswitch. As result current checks that SPSO should be pinned and at the same block as safepoint failed. Nothing is wrong to have one SPSO node be referenced by several cloned safepoints since SPSO contains only class information and index of safepoin's debug info edge which should stay the same for cloned safepoints. The solution is to removed pinned attribute from SPSO node, use Root as control edge and add hash(), cmp() to not allow value-numbering of these nodes. >> >> Removed SPSO asserts in block.cpp and the rest is mostly code style clean up. >> >> Locks eliminated by "lock coarsening" optimization are treated differently during elimination since corresponding outer locks should stay. Such locks marked by "_coarsened" flag. EA should clean this flag for locks which could be eliminated because corresponding object does not escape. >> >> Don't bail out from build_and_optimize() until dead code is eliminated when it is called before EA even if there are no loops or there are only irreducible loops. >> >> Added missing (in(0)->is_top()) checks after remove_dead_region() calls. > > Should this idiom: > > if( in(0) && remove_dead_region(phase, can_reshape) ) return this; > // Don't bother trying to transform a dead node > if( in(0) && in(0)->is_top() ) return NULL; > > be handled in a more systematic way instead of being sprinkled about? There are many Ideal functions that consist only of the first part which says that me that it's really part of the code transform loop instead of being a responsibility of Ideal itself. Maybe that's for a more broad cleanup in the future. > > Otherwise it looks good. > > tom > >> Thanks, >> Vladimir > From christian.thalinger at oracle.com Wed Nov 16 05:45:39 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Nov 2011 14:45:39 +0100 Subject: Request for review (XS): 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not In-Reply-To: <4EBC0327.6050108@oracle.com> References: <64DF9BDB-7C30-44AC-A87C-946A7A27E91B@oracle.com> <4EBA992E.4040302@oracle.com> <20F584B3-2522-4A24-9300-832C875E704F@oracle.com> <4EBC0327.6050108@oracle.com> Message-ID: <314B5A61-6260-4B6F-9A3C-30DCF3D28D2F@oracle.com> On Nov 10, 2011, at 6:00 PM, Vladimir Kozlov wrote: > You can check failing() and return NULL in that case (most cases) Done. > otherwise generate direct call if inlining failed for an other reason. I still do not get why hot path do not do it, it also can fail because of nodes threshold. The direct call is now generated by CallGenerator::for_method_handle_call. Before we were just returning NULL if the inlining failed. -- Chris > > Vladimir > > On 11/10/11 3:28 AM, Christian Thalinger wrote: >> >> On Nov 9, 2011, at 4:15 PM, Vladimir Kozlov wrote: >> >>> Why not generate direct call as we do we for hot call? >> >> I had a small chat with John about that yesterday. Maybe moving the logic into its own function that returns a direct/dynamic call instead of null when the inlining fails is in general a good idea (especially for the selectAlternative idiom). I updated the webrev with that code. >> >> But in this particular case it doesn't help since we are so close (or already over) the threshold cliff that it fails anyway. Let me know what you think. >> >> -- Chris >> >> >>> >>> Vladimir >>> >>> Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/7108383/ >>>> 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not >>>> Reviewed-by: >>>> The problem is that the code in >>>> PredictedDynamicCallGenerator::generate assumes that the generation of >>>> the slow path always succeeds. This might not be the case when we hit >>>> the node limit while generating the slow path. >>>> The suggested fix is to remove the assert and return on failed slow >>>> path generations. >>>> I also applied the fix to PredictedCallGenerator::generate because I >>>> think it can also happen there. >>>> src/share/vm/opto/callGenerator.cpp >> From christian.thalinger at oracle.com Wed Nov 16 06:08:41 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 16 Nov 2011 14:08:41 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7003454: order constants in constant table by number of references in code Message-ID: <20111116140847.77C0A47390@hg.openjdk.java.net> Changeset: 6729bbc1fcd6 Author: twisti Date: 2011-11-16 01:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6729bbc1fcd6 7003454: order constants in constant table by number of references in code Reviewed-by: kvn, never, bdelsart ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/matcher.hpp From christian.thalinger at oracle.com Wed Nov 16 08:21:21 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Nov 2011 17:21:21 +0100 Subject: Request for reviews (XXS): 7110058: change default for ScavengeRootsInCode to 2 Message-ID: <52B41FA4-A43B-41EC-ACEB-106DD5BCC5D1@oracle.com> http://cr.openjdk.java.net/~twisti/7110058/ 7110058: change default for ScavengeRootsInCode to 2 Reviewed-by: The flag setting ScavengeRootsInCode=2 causes the JIT to inline more constants. This is generally a good thing for performance. Tested with JPRT jobs on all three queues, DaCapo, refworkload reference_server, JRuby test suite, Seph test suite. src/share/vm/runtime/globals.hpp From vladimir.kozlov at oracle.com Wed Nov 16 08:27:15 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Nov 2011 08:27:15 -0800 Subject: Request for review (XS): 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not In-Reply-To: <314B5A61-6260-4B6F-9A3C-30DCF3D28D2F@oracle.com> References: <64DF9BDB-7C30-44AC-A87C-946A7A27E91B@oracle.com> <4EBA992E.4040302@oracle.com> <20F584B3-2522-4A24-9300-832C875E704F@oracle.com> <4EBC0327.6050108@oracle.com> <314B5A61-6260-4B6F-9A3C-30DCF3D28D2F@oracle.com> Message-ID: <4EC3E463.9080101@oracle.com> Good. Vladimir On 11/16/11 5:45 AM, Christian Thalinger wrote: > > On Nov 10, 2011, at 6:00 PM, Vladimir Kozlov wrote: > >> You can check failing() and return NULL in that case (most cases) > > Done. > >> otherwise generate direct call if inlining failed for an other reason. I still do not get why hot path do not do it, it also can fail because of nodes threshold. > > The direct call is now generated by CallGenerator::for_method_handle_call. Before we were just returning NULL if the inlining failed. > > -- Chris > >> >> Vladimir >> >> On 11/10/11 3:28 AM, Christian Thalinger wrote: >>> >>> On Nov 9, 2011, at 4:15 PM, Vladimir Kozlov wrote: >>> >>>> Why not generate direct call as we do we for hot call? >>> >>> I had a small chat with John about that yesterday. Maybe moving the logic into its own function that returns a direct/dynamic call instead of null when the inlining fails is in general a good idea (especially for the selectAlternative idiom). I updated the webrev with that code. >>> >>> But in this particular case it doesn't help since we are so close (or already over) the threshold cliff that it fails anyway. Let me know what you think. >>> >>> -- Chris >>> >>> >>>> >>>> Vladimir >>>> >>>> Christian Thalinger wrote: >>>>> http://cr.openjdk.java.net/~twisti/7108383/ >>>>> 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not >>>>> Reviewed-by: >>>>> The problem is that the code in >>>>> PredictedDynamicCallGenerator::generate assumes that the generation of >>>>> the slow path always succeeds. This might not be the case when we hit >>>>> the node limit while generating the slow path. >>>>> The suggested fix is to remove the assert and return on failed slow >>>>> path generations. >>>>> I also applied the fix to PredictedCallGenerator::generate because I >>>>> think it can also happen there. >>>>> src/share/vm/opto/callGenerator.cpp >>> > From christian.thalinger at oracle.com Wed Nov 16 08:28:17 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Nov 2011 17:28:17 +0100 Subject: Request for review (XS): 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not In-Reply-To: <4EC3E463.9080101@oracle.com> References: <64DF9BDB-7C30-44AC-A87C-946A7A27E91B@oracle.com> <4EBA992E.4040302@oracle.com> <20F584B3-2522-4A24-9300-832C875E704F@oracle.com> <4EBC0327.6050108@oracle.com> <314B5A61-6260-4B6F-9A3C-30DCF3D28D2F@oracle.com> <4EC3E463.9080101@oracle.com> Message-ID: <01D056DA-231B-4A77-91B3-CD4EAFFC3E97@oracle.com> Thank you, Vladimir. -- Chris On Nov 16, 2011, at 5:27 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 11/16/11 5:45 AM, Christian Thalinger wrote: >> >> On Nov 10, 2011, at 6:00 PM, Vladimir Kozlov wrote: >> >>> You can check failing() and return NULL in that case (most cases) >> >> Done. >> >>> otherwise generate direct call if inlining failed for an other reason. I still do not get why hot path do not do it, it also can fail because of nodes threshold. >> >> The direct call is now generated by CallGenerator::for_method_handle_call. Before we were just returning NULL if the inlining failed. >> >> -- Chris >> >>> >>> Vladimir >>> >>> On 11/10/11 3:28 AM, Christian Thalinger wrote: >>>> >>>> On Nov 9, 2011, at 4:15 PM, Vladimir Kozlov wrote: >>>> >>>>> Why not generate direct call as we do we for hot call? >>>> >>>> I had a small chat with John about that yesterday. Maybe moving the logic into its own function that returns a direct/dynamic call instead of null when the inlining fails is in general a good idea (especially for the selectAlternative idiom). I updated the webrev with that code. >>>> >>>> But in this particular case it doesn't help since we are so close (or already over) the threshold cliff that it fails anyway. Let me know what you think. >>>> >>>> -- Chris >>>> >>>> >>>>> >>>>> Vladimir >>>>> >>>>> Christian Thalinger wrote: >>>>>> http://cr.openjdk.java.net/~twisti/7108383/ >>>>>> 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not >>>>>> Reviewed-by: >>>>>> The problem is that the code in >>>>>> PredictedDynamicCallGenerator::generate assumes that the generation of >>>>>> the slow path always succeeds. This might not be the case when we hit >>>>>> the node limit while generating the slow path. >>>>>> The suggested fix is to remove the assert and return on failed slow >>>>>> path generations. >>>>>> I also applied the fix to PredictedCallGenerator::generate because I >>>>>> think it can also happen there. >>>>>> src/share/vm/opto/callGenerator.cpp >>>> >> From vladimir.kozlov at oracle.com Wed Nov 16 08:36:42 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Nov 2011 08:36:42 -0800 Subject: Request for reviews (XXS): 7110058: change default for ScavengeRootsInCode to 2 In-Reply-To: <52B41FA4-A43B-41EC-ACEB-106DD5BCC5D1@oracle.com> References: <52B41FA4-A43B-41EC-ACEB-106DD5BCC5D1@oracle.com> Message-ID: <4EC3E69A.3030204@oracle.com> Good. Vladimir On 11/16/11 8:21 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7110058/ > > 7110058: change default for ScavengeRootsInCode to 2 > Reviewed-by: > > The flag setting ScavengeRootsInCode=2 causes the JIT to inline more > constants. This is generally a good thing for performance. > > Tested with JPRT jobs on all three queues, DaCapo, refworkload > reference_server, JRuby test suite, Seph test suite. > > src/share/vm/runtime/globals.hpp > From yang02.wang at sap.com Wed Nov 16 09:04:02 2011 From: yang02.wang at sap.com (Wang, Yang) Date: Wed, 16 Nov 2011 18:04:02 +0100 Subject: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter Message-ID: Hi folks, We found two problems during throwing an StackOverflow exception from interpreter. 1. Before preparing to throw a StackOverflow exception, the last Java frame is set to the current sp. This is problematic when the StackOverflow is thrown on top of c2i adapter. Solution : the real caller frame(unextended sp) should be set as last Java frame. 2. When Garbage collection happens during throwing StackOverflow exception, and callee-saved register(or "never-saved" register which behaves alike) happens to be an OOP, GC is unable to locate the OOP in C frame(generated by VM calls), and hence fails to process the OOP. Solution : We build a runtime stub frame before doing a VM call, which guarantees the location of Callee-saved registers are always recognizable by GC. Detailed descriptions and tests could be found in webrev http://www.sapjvm.com/yw/webrevs/StackOverflow_GC_Crash/ I don't have a bugID yet. Please kindly open one bug for this issue. Thanks, Yang Yang Wang Software Engineer TIP Core AS&VM Technology (AG) SAP JVM JIT Compiler SAP AG Dietmar-Hopp-Allee 16 69190 Walldorf, Germany T +49 6227 7-50320 F +49 6227 78-48541 Email : yang02.wang at sap.com www.sap.com Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111116/09a4b016/attachment.html From tom.rodriguez at oracle.com Wed Nov 16 10:48:27 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Nov 2011 10:48:27 -0800 Subject: Request for reviews (XXS): 7110058: change default for ScavengeRootsInCode to 2 In-Reply-To: <52B41FA4-A43B-41EC-ACEB-106DD5BCC5D1@oracle.com> References: <52B41FA4-A43B-41EC-ACEB-106DD5BCC5D1@oracle.com> Message-ID: <339F32B6-DE41-4E95-8BE2-79391052C6D8@oracle.com> Looks good. tom On Nov 16, 2011, at 8:21 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7110058/ > > 7110058: change default for ScavengeRootsInCode to 2 > Reviewed-by: > > The flag setting ScavengeRootsInCode=2 causes the JIT to inline more > constants. This is generally a good thing for performance. > > Tested with JPRT jobs on all three queues, DaCapo, refworkload > reference_server, JRuby test suite, Seph test suite. > > src/share/vm/runtime/globals.hpp > From vladimir.kozlov at oracle.com Wed Nov 16 11:24:10 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 16 Nov 2011 19:24:10 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 6890673: Eliminate allocations immediately after EA Message-ID: <20111116192414.0144B47392@hg.openjdk.java.net> Changeset: 1bd45abaa507 Author: kvn Date: 2011-11-16 09:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1bd45abaa507 6890673: Eliminate allocations immediately after EA Summary: Try to eliminate allocations and related locks immediately after escape analysis. Reviewed-by: never ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp From igor.veresov at oracle.com Wed Nov 16 12:14:28 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 16 Nov 2011 12:14:28 -0800 Subject: review(S): 7112085: =?utf-8?Q?assert(fr.interpreter=5Fframe=5Fexpression=5Fstack=5Fsize()=3D=3D0)_?=failed: only handle empty stacks Message-ID: <35027F1D7DA34D16BAC651AE406EBCC8@oracle.com> The runtime call to the policy from the inlinee invocation had an incorrect jvm state. As a result the bytecode preceding the invoke of the inlinee was executed twice in case we deoptimized. Since it's currently not quite easy to set the reexecute flag in C1, I moved the notification call into the preamble of the inlinee so that I could use InvocationEntryBci in the state specification, which would deopt correctly. Also made some minor changes to printing of tiered events. Webrev: http://cr.openjdk.java.net/~iveresov/7112085/webrev.00/ Thanks!igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111116/2f6f8950/attachment.html From vladimir.kozlov at oracle.com Wed Nov 16 12:46:18 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Nov 2011 12:46:18 -0800 Subject: review(S): 7112085: assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks In-Reply-To: <35027F1D7DA34D16BAC651AE406EBCC8@oracle.com> References: <35027F1D7DA34D16BAC651AE406EBCC8@oracle.com> Message-ID: <4EC4211A.1000508@oracle.com> Looks good. Did it pass all compiler regression tests with -XX:+TieredCompilation -XX:+DeoptimizeALot? Thanks, Vladimir Igor Veresov wrote: > The runtime call to the policy from the inlinee invocation had an > incorrect jvm state. As a result the bytecode preceding the invoke of > the inlinee was executed twice in case we deoptimized. Since it's > currently not quite easy to set the reexecute flag in C1, I moved the > notification call into the preamble of the inlinee so that I could use > InvocationEntryBci in the state specification, which would deopt correctly. > > Also made some minor changes to printing of tiered events. > > Webrev: http://cr.openjdk.java.net/~iveresov/7112085/webrev.00/ > > Thanks! > igor > From igor.veresov at oracle.com Wed Nov 16 15:18:06 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 16 Nov 2011 15:18:06 -0800 Subject: review(S): 7112085: =?utf-8?Q?assert(fr.interpreter=5Fframe=5Fexpression=5Fstack=5Fsize()=3D=3D0)_?=failed: only handle empty stacks In-Reply-To: <4EC4211A.1000508@oracle.com> References: <35027F1D7DA34D16BAC651AE406EBCC8@oracle.com> <4EC4211A.1000508@oracle.com> Message-ID: On Wednesday, November 16, 2011 at 12:46 PM, Vladimir Kozlov wrote: > Looks good. > Thank you. > > Did it pass all compiler regression tests with -XX:+TieredCompilation > -XX:+DeoptimizeALot? > Yes. I just reran the tests again to make sure. I also noticed a problem with the test for 6792161. It increases the inlining size so much that it makes the fastdebug C1 very slow. I'll have to investigate why, but for now I decide to increase the timeout. Webrev updated. igor > > Thanks, > Vladimir > > Igor Veresov wrote: > > The runtime call to the policy from the inlinee invocation had an > > incorrect jvm state. As a result the bytecode preceding the invoke of > > the inlinee was executed twice in case we deoptimized. Since it's > > currently not quite easy to set the reexecute flag in C1, I moved the > > notification call into the preamble of the inlinee so that I could use > > InvocationEntryBci in the state specification, which would deopt correctly. > > > > Also made some minor changes to printing of tiered events. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7112085/webrev.00/ > > > > Thanks! > > igor > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111116/4a4060c9/attachment.html From vladimir.kozlov at oracle.com Wed Nov 16 15:19:09 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Nov 2011 15:19:09 -0800 Subject: review(S): 7112085: assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks In-Reply-To: References: <35027F1D7DA34D16BAC651AE406EBCC8@oracle.com> <4EC4211A.1000508@oracle.com> Message-ID: <4EC444ED.5050502@oracle.com> Thank you, Igor Vladimir Igor Veresov wrote: > On Wednesday, November 16, 2011 at 12:46 PM, Vladimir Kozlov wrote: >> Looks good. >> > Thank you. >> Did it pass all compiler regression tests with -XX:+TieredCompilation >> -XX:+DeoptimizeALot? >> > Yes. I just reran the tests again to make sure. I also noticed a problem > with the test for 6792161. It increases the inlining size so much that > it makes the fastdebug C1 very slow. I'll have to investigate why, but > for now I decide to increase the timeout. Webrev updated. > > igor > >> Thanks, >> Vladimir >> >> Igor Veresov wrote: >>> The runtime call to the policy from the inlinee invocation had an >>> incorrect jvm state. As a result the bytecode preceding the invoke of >>> the inlinee was executed twice in case we deoptimized. Since it's >>> currently not quite easy to set the reexecute flag in C1, I moved the >>> notification call into the preamble of the inlinee so that I could use >>> InvocationEntryBci in the state specification, which would deopt >>> correctly. >>> >>> Also made some minor changes to printing of tiered events. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/7112085/webrev.00/ >>> >>> Thanks! >>> igor > From tom.rodriguez at oracle.com Wed Nov 16 16:55:19 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Nov 2011 16:55:19 -0800 Subject: review(S): 7112085: assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks In-Reply-To: References: <35027F1D7DA34D16BAC651AE406EBCC8@oracle.com> <4EC4211A.1000508@oracle.com> Message-ID: <5AB05023-7BC6-4ACE-87A9-61B9AE415897@oracle.com> Looks good. tom On Nov 16, 2011, at 3:18 PM, Igor Veresov wrote: > On Wednesday, November 16, 2011 at 12:46 PM, Vladimir Kozlov wrote: >> Looks good. >> > Thank you. >> Did it pass all compiler regression tests with -XX:+TieredCompilation >> -XX:+DeoptimizeALot? >> > Yes. I just reran the tests again to make sure. I also noticed a problem with the test for 6792161. It increases the inlining size so much that it makes the fastdebug C1 very slow. I'll have to investigate why, but for now I decide to increase the timeout. Webrev updated. > > igor > >> Thanks, >> Vladimir >> >> Igor Veresov wrote: >>> The runtime call to the policy from the inlinee invocation had an >>> incorrect jvm state. As a result the bytecode preceding the invoke of >>> the inlinee was executed twice in case we deoptimized. Since it's >>> currently not quite easy to set the reexecute flag in C1, I moved the >>> notification call into the preamble of the inlinee so that I could use >>> InvocationEntryBci in the state specification, which would deopt correctly. >>> >>> Also made some minor changes to printing of tiered events. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/7112085/webrev.00/ >>> >>> Thanks! >>> igor > From igor.veresov at oracle.com Wed Nov 16 17:01:48 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 16 Nov 2011 17:01:48 -0800 Subject: review(S): 7112085: =?utf-8?Q?assert(fr.interpreter=5Fframe=5Fexpression=5Fstack=5Fsize()=3D=3D0)_?=failed: only handle empty stacks In-Reply-To: <5AB05023-7BC6-4ACE-87A9-61B9AE415897@oracle.com> References: <35027F1D7DA34D16BAC651AE406EBCC8@oracle.com> <4EC4211A.1000508@oracle.com> <5AB05023-7BC6-4ACE-87A9-61B9AE415897@oracle.com> Message-ID: <7799D61EB7224855964EEDA1E7E925B7@oracle.com> Thanks Vladimir and Tom! igor On Wednesday, November 16, 2011 at 4:55 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Nov 16, 2011, at 3:18 PM, Igor Veresov wrote: > > > On Wednesday, November 16, 2011 at 12:46 PM, Vladimir Kozlov wrote: > > > Looks good. > > > > Thank you. > > > Did it pass all compiler regression tests with -XX:+TieredCompilation > > > -XX:+DeoptimizeALot? > > > > > > > Yes. I just reran the tests again to make sure. I also noticed a problem with the test for 6792161. It increases the inlining size so much that it makes the fastdebug C1 very slow. I'll have to investigate why, but for now I decide to increase the timeout. Webrev updated. > > > > igor > > > > > Thanks, > > > Vladimir > > > > > > Igor Veresov wrote: > > > > The runtime call to the policy from the inlinee invocation had an > > > > incorrect jvm state. As a result the bytecode preceding the invoke of > > > > the inlinee was executed twice in case we deoptimized. Since it's > > > > currently not quite easy to set the reexecute flag in C1, I moved the > > > > notification call into the preamble of the inlinee so that I could use > > > > InvocationEntryBci in the state specification, which would deopt correctly. > > > > > > > > Also made some minor changes to printing of tiered events. > > > > > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7112085/webrev.00/ > > > > > > > > Thanks! > > > > igor > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111116/9baa58aa/attachment-0001.html From igor.veresov at oracle.com Wed Nov 16 22:25:15 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 17 Nov 2011 06:25:15 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7112085: assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks Message-ID: <20111117062519.8BB77473AE@hg.openjdk.java.net> Changeset: 973293defacd Author: iveresov Date: 2011-11-16 19:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/973293defacd 7112085: assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks Summary: Move the inlinee invoke notification callback into inlinee preamble Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp ! test/compiler/6792161/Test6792161.java From christian.thalinger at oracle.com Thu Nov 17 08:11:54 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 17 Nov 2011 16:11:54 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not Message-ID: <20111117161159.E0B21473B4@hg.openjdk.java.net> Changeset: a04a201f0f5a Author: twisti Date: 2011-11-17 04:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a04a201f0f5a 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not Reviewed-by: kvn, never ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp From vladimir.kozlov at oracle.com Fri Nov 18 11:51:06 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Nov 2011 11:51:06 -0800 Subject: Request for reviews (M): 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE Message-ID: <4EC6B72A.3020307@oracle.com> http://cr.openjdk.java.net/~kvn/7112478/webrev 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE 7105605 optimization is good stress test for EA :) Added missing edges from arraycopy's destination fields to fields of source object. Mark source object as global escape if we are not sure that all edges are created. EA bytecode analyzer gives incorrect information about returned object if there were state merges with processed block. Also call's result missed reference to returned arguments and unknown object when not only arguments is returned. Added missing reference to NULL from array elements with OffsetBot offset. Make sure that LocalVar and Field have edge to at least unknown object before removing deferred edges from the graph. Moved escaped state propagation code to execute it after Connection Graph is completed and skip the rest of code if all objects globally escaped. Also added accessors to check for null and unknown pointers. And don't add fields edges to NULL pointer object. Tested with CTW, nsk, compiler regression tests, failed java/util tests Thanks, Vladimir From tom.rodriguez at oracle.com Sat Nov 19 01:15:17 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 19 Nov 2011 09:15:17 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable Message-ID: <20111119091523.8B730473F1@hg.openjdk.java.net> Changeset: 59bc0d4d9ea3 Author: never Date: 2011-11-18 10:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/59bc0d4d9ea3 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable Reviewed-by: kvn, iveresov, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp From christian.thalinger at oracle.com Mon Nov 21 00:56:23 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 21 Nov 2011 09:56:23 +0100 Subject: Request for reviews (XXS): 7110058: change default for ScavengeRootsInCode to 2 In-Reply-To: <339F32B6-DE41-4E95-8BE2-79391052C6D8@oracle.com> References: <52B41FA4-A43B-41EC-ACEB-106DD5BCC5D1@oracle.com> <339F32B6-DE41-4E95-8BE2-79391052C6D8@oracle.com> Message-ID: Thank you, Vladimir and Tom. -- Chris On Nov 16, 2011, at 7:48 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Nov 16, 2011, at 8:21 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7110058/ >> >> 7110058: change default for ScavengeRootsInCode to 2 >> Reviewed-by: >> >> The flag setting ScavengeRootsInCode=2 causes the JIT to inline more >> constants. This is generally a good thing for performance. >> >> Tested with JPRT jobs on all three queues, DaCapo, refworkload >> reference_server, JRuby test suite, Seph test suite. >> >> src/share/vm/runtime/globals.hpp >> > From christian.thalinger at oracle.com Mon Nov 21 01:12:43 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 21 Nov 2011 10:12:43 +0100 Subject: Request for reviews (M): 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE In-Reply-To: <4EC6B72A.3020307@oracle.com> References: <4EC6B72A.3020307@oracle.com> Message-ID: <34651FE4-7DFE-4FF8-B28F-32FD9577D788@oracle.com> src/share/vm/opto/escape.cpp: + // always add reference to NULL since we don't + // known which element if referenced. I think this should be "know which element is referenced." - add_edge_from_fields(pt, _phantom_object, Type::OffsetBot); + add_edge_from_fields(pt, _phantom_object, Type::OffsetTop); This change is correct? I didn't see anything obviously wrong but I can't tell if the new code works as it should. -- Chris On Nov 18, 2011, at 8:51 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7112478/webrev > > 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE > > 7105605 optimization is good stress test for EA :) > > Added missing edges from arraycopy's destination fields to fields of source object. Mark source object as global escape if we are not sure that all edges are created. > > EA bytecode analyzer gives incorrect information about returned object if there were state merges with processed block. Also call's result missed reference to returned arguments and unknown object when not only arguments is returned. > > Added missing reference to NULL from array elements with OffsetBot offset. > > Make sure that LocalVar and Field have edge to at least unknown object before removing deferred edges from the graph. > > Moved escaped state propagation code to execute it after Connection Graph is completed and skip the rest of code if all objects globally escaped. > > Also added accessors to check for null and unknown pointers. And don't add fields edges to NULL pointer object. > > Tested with CTW, nsk, compiler regression tests, failed java/util tests > > Thanks, > Vladimir From christian.thalinger at oracle.com Mon Nov 21 03:05:41 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 21 Nov 2011 11:05:41 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7110058: change default for ScavengeRootsInCode to 2 Message-ID: <20111121110549.3391A4740A@hg.openjdk.java.net> Changeset: 7793051af7d6 Author: twisti Date: 2011-11-21 00:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7793051af7d6 7110058: change default for ScavengeRootsInCode to 2 Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp From roland.westrelin at oracle.com Mon Nov 21 07:36:04 2011 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Mon, 21 Nov 2011 15:36:04 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7077312: Provide a CALL effect for instruct declaration in the ad file Message-ID: <20111121153608.F03FB47412@hg.openjdk.java.net> Changeset: f03a3c8bd5e5 Author: roland Date: 2011-09-14 09:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f03a3c8bd5e5 7077312: Provide a CALL effect for instruct declaration in the ad file Summary: abstracted way to declare that the MachNode has the effect of a call (kills caller save registers, preserves callee save registers) Reviewed-by: twisti, never ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp From vladimir.kozlov at oracle.com Mon Nov 21 21:47:10 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Nov 2011 21:47:10 -0800 Subject: Request for reviews (M): 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE In-Reply-To: <34651FE4-7DFE-4FF8-B28F-32FD9577D788@oracle.com> References: <4EC6B72A.3020307@oracle.com> <34651FE4-7DFE-4FF8-B28F-32FD9577D788@oracle.com> Message-ID: <4ECB375E.1030409@oracle.com> Thank you, Christian On 11/21/2011 1:12 AM, Christian Thalinger wrote: > src/share/vm/opto/escape.cpp: > > + // always add reference to NULL since we don't > + // known which element if referenced. > > I think this should be "know which element is referenced." Yes, it is typo. > > - add_edge_from_fields(pt, _phantom_object, Type::OffsetBot); > + add_edge_from_fields(pt, _phantom_object, Type::OffsetTop); > > This change is correct? It is intentional. It is special case to indicate that values in fields escaped during call. There is new code in add_edge_from_fields() which checks this value and convert offset back to Bottom. > > I didn't see anything obviously wrong but I can't tell if the new code works as it should. Thanks, Vladimir > > -- Chris > > On Nov 18, 2011, at 8:51 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7112478/webrev >> >> 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE >> >> 7105605 optimization is good stress test for EA :) >> >> Added missing edges from arraycopy's destination fields to fields of source object. Mark source object as global escape if we are not sure that all edges are created. >> >> EA bytecode analyzer gives incorrect information about returned object if there were state merges with processed block. Also call's result missed reference to returned arguments and unknown object when not only arguments is returned. >> >> Added missing reference to NULL from array elements with OffsetBot offset. >> >> Make sure that LocalVar and Field have edge to at least unknown object before removing deferred edges from the graph. >> >> Moved escaped state propagation code to execute it after Connection Graph is completed and skip the rest of code if all objects globally escaped. >> >> Also added accessors to check for null and unknown pointers. And don't add fields edges to NULL pointer object. >> >> Tested with CTW, nsk, compiler regression tests, failed java/util tests >> >> Thanks, >> Vladimir > From roland.westrelin at oracle.com Tue Nov 22 06:32:08 2011 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Tue, 22 Nov 2011 14:32:08 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7090968: Allow adlc register class to depend on runtime conditions Message-ID: <20111122143226.40EBF47426@hg.openjdk.java.net> Changeset: db2e64ca2d5a Author: roland Date: 2011-11-22 09:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/db2e64ca2d5a 7090968: Allow adlc register class to depend on runtime conditions Summary: allow reg_class definition as a function. Reviewed-by: kvn, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formsopt.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/matcher.hpp From tom.rodriguez at oracle.com Tue Nov 22 08:44:51 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 22 Nov 2011 08:44:51 -0800 Subject: type oddity Message-ID: <2860ECE2-F7C0-4309-8327-DC1C1D10D817@oracle.com> While looking into a failure in the metadata repo I noticed this code in flatten_alias_type: // Klass pointers to object array klasses need some flattening const TypeKlassPtr *tk = tj->isa_klassptr(); if( tk ) { // If we are referencing a field within a Klass, we need // to assume the worst case of an Object. Both exact and // inexact types must flatten to the same alias class. // Since the flattened result for a klass is defined to be // precisely java.lang.Object, use a constant ptr. if ( offset == Type::OffsetBot || (offset >= 0 && (size_t)offset < sizeof(Klass)) ) { tj = tk = TypeKlassPtr::make(TypePtr::Constant, TypeKlassPtr::OBJECT->klass(), offset); } It's followed by a couple checks for specific fields where the PTR is changes to NotNull for just those offsets. It seems odd to me that Constant is used here since we're flattening a non constant type into a constant one for some fields but not for others. We end up with a constant class for things like the java_mirror field which seems wrong: precise klass java/lang/Object: 0x08142438:Constant:exact+64 * For objArrayKlass we convert it back to NotNull. The comment explaining why Constant is used doesn't really make sense either. Anyone know why it's done this way? tom From tom.rodriguez at oracle.com Tue Nov 22 08:58:54 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 22 Nov 2011 08:58:54 -0800 Subject: Request for reviews (M): 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE In-Reply-To: <4EC6B72A.3020307@oracle.com> References: <4EC6B72A.3020307@oracle.com> Message-ID: <46529EA4-AA1C-4F0A-B5D4-0DB10977F20D@oracle.com> escape.cpp: typo "element if referenced" typo "regardless its escape state" otherwise I think it looks ok. tom On Nov 18, 2011, at 11:51 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7112478/webrev > > 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE > > 7105605 optimization is good stress test for EA :) > > Added missing edges from arraycopy's destination fields to fields of source object. Mark source object as global escape if we are not sure that all edges are created. > > EA bytecode analyzer gives incorrect information about returned object if there were state merges with processed block. Also call's result missed reference to returned arguments and unknown object when not only arguments is returned. > > Added missing reference to NULL from array elements with OffsetBot offset. > > Make sure that LocalVar and Field have edge to at least unknown object before removing deferred edges from the graph. > > Moved escaped state propagation code to execute it after Connection Graph is completed and skip the rest of code if all objects globally escaped. > > Also added accessors to check for null and unknown pointers. And don't add fields edges to NULL pointer object. > > Tested with CTW, nsk, compiler regression tests, failed java/util tests > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Nov 22 16:32:45 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Nov 2011 16:32:45 -0800 Subject: Request for reviews (M): 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE In-Reply-To: <46529EA4-AA1C-4F0A-B5D4-0DB10977F20D@oracle.com> References: <4EC6B72A.3020307@oracle.com> <46529EA4-AA1C-4F0A-B5D4-0DB10977F20D@oracle.com> Message-ID: <4ECC3F2D.7090300@oracle.com> Thank you, Tom Vladimir On 11/22/2011 8:58 AM, Tom Rodriguez wrote: > escape.cpp: > > typo "element if referenced" > > typo "regardless its escape state" > > otherwise I think it looks ok. > > tom > > On Nov 18, 2011, at 11:51 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7112478/webrev >> >> 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE >> >> 7105605 optimization is good stress test for EA :) >> >> Added missing edges from arraycopy's destination fields to fields of source object. Mark source object as global escape if we are not sure that all edges are created. >> >> EA bytecode analyzer gives incorrect information about returned object if there were state merges with processed block. Also call's result missed reference to returned arguments and unknown object when not only arguments is returned. >> >> Added missing reference to NULL from array elements with OffsetBot offset. >> >> Make sure that LocalVar and Field have edge to at least unknown object before removing deferred edges from the graph. >> >> Moved escaped state propagation code to execute it after Connection Graph is completed and skip the rest of code if all objects globally escaped. >> >> Also added accessors to check for null and unknown pointers. And don't add fields edges to NULL pointer object. >> >> Tested with CTW, nsk, compiler regression tests, failed java/util tests >> >> Thanks, >> Vladimir > From john.coomes at oracle.com Thu Nov 24 20:35:51 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:35:51 +0000 Subject: hg: hsx/hotspot-comp: 8 new changesets Message-ID: <20111125043552.55AB447446@hg.openjdk.java.net> Changeset: 26fb81a1e9ce Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/26fb81a1e9ce Added tag jdk8-b12 for changeset 8e2104d565ba ! .hgtags Changeset: 8da26d5c32a7 Author: katleman Date: 2011-11-10 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8da26d5c32a7 Added tag jdk8-b13 for changeset 26fb81a1e9ce ! .hgtags Changeset: a62a0f35eb9c Author: asaha Date: 2011-06-27 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/a62a0f35eb9c Merge Changeset: f9b3e6b2aa2c Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/f9b3e6b2aa2c Merge Changeset: ea2ab83ce564 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/ea2ab83ce564 Merge Changeset: 8f525559ae73 Author: asaha Date: 2011-11-07 21:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8f525559ae73 Merge Changeset: 23aa7f2c80a2 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/23aa7f2c80a2 Merge Changeset: a4f28069d44a Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/a4f28069d44a Added tag jdk8-b14 for changeset 23aa7f2c80a2 ! .hgtags From john.coomes at oracle.com Thu Nov 24 20:36:03 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:36:03 +0000 Subject: hg: hsx/hotspot-comp/corba: 9 new changesets Message-ID: <20111125043610.1578947447@hg.openjdk.java.net> Changeset: 5b9d9b839d3d Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/5b9d9b839d3d Added tag jdk8-b12 for changeset 31d70911b712 ! .hgtags Changeset: 6f601a737e0f Author: katleman Date: 2011-11-10 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/6f601a737e0f Added tag jdk8-b13 for changeset 5b9d9b839d3d ! .hgtags Changeset: d84682019b5f Author: asaha Date: 2011-06-27 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/d84682019b5f Merge Changeset: 9c20c1e7cdd9 Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/9c20c1e7cdd9 Merge Changeset: cb5aec0570a5 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/cb5aec0570a5 Merge Changeset: 21369018a679 Author: mbankal Date: 2011-08-09 05:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/21369018a679 7055902: Oracle Java IIOP Deserialization Type Confusion Remote Code Execution Vulnerability Reviewed-by: coffeys ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: 058c18d237a9 Author: asaha Date: 2011-11-07 21:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/058c18d237a9 Merge Changeset: e59c47de1ad8 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/e59c47de1ad8 Merge Changeset: 99925e8d1b86 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/99925e8d1b86 Added tag jdk8-b14 for changeset e59c47de1ad8 ! .hgtags From john.coomes at oracle.com Thu Nov 24 20:36:19 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:36:19 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 8 new changesets Message-ID: <20111125043619.AD39347448@hg.openjdk.java.net> Changeset: bcc739229f63 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/bcc739229f63 Added tag jdk8-b12 for changeset ca977d167697 ! .hgtags Changeset: e7172d80a8f4 Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/e7172d80a8f4 Added tag jdk8-b13 for changeset bcc739229f63 ! .hgtags Changeset: 7adf14d6060c Author: asaha Date: 2011-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/7adf14d6060c Merge Changeset: d239aa024b6e Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/d239aa024b6e Merge Changeset: eca33f89c823 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/eca33f89c823 Merge Changeset: 0ed9ae36ee2a Author: asaha Date: 2011-11-07 21:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/0ed9ae36ee2a Merge Changeset: 9d0c9d638757 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/9d0c9d638757 Merge Changeset: 804f666d6d44 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/804f666d6d44 Added tag jdk8-b14 for changeset 9d0c9d638757 ! .hgtags From john.coomes at oracle.com Thu Nov 24 20:36:29 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:36:29 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 10 new changesets Message-ID: <20111125043629.5854D47449@hg.openjdk.java.net> Changeset: adf2a6b5fde1 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/adf2a6b5fde1 Added tag jdk8-b12 for changeset e6eed2ff5d5f ! .hgtags Changeset: f502a343a92e Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/f502a343a92e Added tag jdk8-b13 for changeset adf2a6b5fde1 ! .hgtags Changeset: 75a652e72489 Author: asaha Date: 2011-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/75a652e72489 Merge Changeset: b058cae6fd3b Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/b058cae6fd3b Merge Changeset: 61c046c6895a Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/61c046c6895a Merge Changeset: 9e82b46cd4fa Author: asaha Date: 2011-07-25 11:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/9e82b46cd4fa 7046794: Configurable behavior for server-side stacktraces Reviewed-by: ramap ! jaxws.properties Changeset: c78fccb01d4e Author: asaha Date: 2011-11-07 21:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/c78fccb01d4e Merge Changeset: cae6db74d6af Author: asaha Date: 2011-11-10 13:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/cae6db74d6af 7110676: Update jaf source download url for jaxws Reviewed-by: ramap ! jaxws.properties Changeset: 54c4bf4b83ec Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/54c4bf4b83ec Merge Changeset: c9ab96ff23d5 Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/c9ab96ff23d5 Added tag jdk8-b14 for changeset 54c4bf4b83ec ! .hgtags From john.coomes at oracle.com Thu Nov 24 20:39:05 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Nov 2011 04:39:05 +0000 Subject: hg: hsx/hotspot-comp/jdk: 94 new changesets Message-ID: <20111125051031.4F2F147457@hg.openjdk.java.net> Changeset: 7746eb8c610b Author: bae Date: 2011-10-17 15:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7746eb8c610b 6997116: The case automatically failed due to java.lang.ClassCastException. Reviewed-by: jgodinez, prr ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java + test/sun/java2d/DirectX/DrawBitmaskToSurfaceTest.java Changeset: a7a001378444 Author: jgodinez Date: 2011-10-24 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a7a001378444 6604109: javax.print.PrintServiceLookup.lookupPrintServices fails SOMETIMES for Cups Reviewed-by: bae, prr ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: 8f9b0629d088 Author: lana Date: 2011-10-25 21:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8f9b0629d088 Merge Changeset: 2b27e14a4c82 Author: vinnie Date: 2011-10-13 12:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2b27e14a4c82 7099228: Use a PKCS11 config attribute to control encoding of an EC point Reviewed-by: valeriep, mullan ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! test/ProblemList.txt Changeset: 01615d3e74ed Author: mullan Date: 2011-10-13 13:50 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/01615d3e74ed 6953295: Move few sun.security.{util, x509, pkcs} classes used by keytool/jarsigner to another package Reviewed-by: mchung ! make/sun/security/other/Makefile - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java + src/share/classes/sun/security/pkcs10/PKCS10.java + src/share/classes/sun/security/pkcs10/PKCS10Attribute.java + src/share/classes/sun/security/pkcs10/PKCS10Attributes.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java + src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStore.java + src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStoreHelper.java + src/share/classes/sun/security/tools/CertAndKeyGen.java ! src/share/classes/sun/security/tools/KeyTool.java + src/share/classes/sun/security/tools/PathList.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 04ecbd2bcf5a Author: mullan Date: 2011-10-13 13:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/04ecbd2bcf5a Merge Changeset: 6cb07b35acf5 Author: weijun Date: 2011-10-17 17:11 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6cb07b35acf5 7099399: cannot deal with CRL file larger than 16MB Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/provider/X509Factory.java + test/sun/security/provider/X509Factory/BigCRL.java Changeset: 9bf526cc4046 Author: mullan Date: 2011-10-18 10:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9bf526cc4046 7092897: sun.security.util.Cache should be generified Reviewed-by: xuelei ! src/share/classes/sun/security/pkcs11/KeyCache.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/X509CertificatePair.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/util/Cache.java Changeset: f566cd364a90 Author: mullan Date: 2011-10-18 10:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f566cd364a90 Merge ! src/share/classes/sun/security/provider/X509Factory.java Changeset: 8640b7185be1 Author: wetmore Date: 2011-10-18 11:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8640b7185be1 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine Reviewed-by: xuelei, weijun, asaha ! src/share/classes/sun/security/ssl/CipherBox.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java Changeset: 57eb9136b73b Author: mullan Date: 2011-10-19 10:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/57eb9136b73b 7102686: Restructure timestamp code so that jars and modules can more easily share the same code Reviewed-by: mchung ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/timestamp/HttpTimestamper.java ! src/share/classes/sun/security/timestamp/TSRequest.java ! src/share/classes/sun/security/timestamp/TSResponse.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/TimestampedSigner.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java Changeset: 15078025eed9 Author: mullan Date: 2011-10-19 10:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/15078025eed9 Merge Changeset: c5c91589b126 Author: mduigou Date: 2011-10-19 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c5c91589b126 5029031: Add Collections.checkedQueue() Reviewed-by: mduigou Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/CheckedQueue.java Changeset: 634cd6f050ba Author: chegar Date: 2011-10-20 09:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/634cd6f050ba 7102704: test/java/net/DatagramSocket/ChangingAddress.java failing Reviewed-by: chegar Contributed-by: kurchi.subhra.hazra at oracle.com - test/java/net/DatagramSocket/ChangingAddress.java Changeset: 2d89c3f74aa5 Author: michaelm Date: 2011-10-20 09:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2d89c3f74aa5 7102665: Move tests to Problemlist Reviewed-by: chegar, alanb ! test/ProblemList.txt Changeset: 52c2dd336207 Author: michaelm Date: 2011-10-20 09:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/52c2dd336207 Merge - test/java/net/DatagramSocket/ChangingAddress.java Changeset: c3da0672a882 Author: ngmr Date: 2011-10-13 12:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c3da0672a882 7100054: (porting) Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Summary: Use POSIX defined includes for unistd.h and fcntl.h Reviewed-by: dholmes, alanb, chegar, ngmr Contributed-by: Charles Lee ! src/solaris/native/sun/nio/fs/genSolarisConstants.c ! src/solaris/native/sun/nio/fs/genUnixConstants.c Changeset: d979afceb792 Author: peytoia Date: 2011-10-21 15:56 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d979afceb792 7103108: (tz) Support tzdata2011l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: db9e246c651e Author: peytoia Date: 2011-10-21 18:01 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/db9e246c651e 7103405: Correct display names for Pacific/Apia timezone Reviewed-by: okutsu ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 3f391e649ccb Author: chegar Date: 2011-10-24 20:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3f391e649ccb 7104209: Cleanup and remove librmi (native library) Reviewed-by: mduigou, alanb ! make/java/java/mapfile-vers ! make/sun/rmi/rmi/Makefile - make/sun/rmi/rmi/mapfile-vers ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/native/java/io/ObjectInputStream.c ! src/share/native/sun/misc/VM.c - src/share/native/sun/rmi/server/MarshalInputStream.c Changeset: b375523d6037 Author: chegar Date: 2011-10-24 21:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b375523d6037 7103549: Remove dependencies on libjava and libjvm from security libraries Reviewed-by: vinnie, ohair, alanb, dholmes ! make/com/sun/security/auth/module/Makefile ! make/common/Defs.gmk ! make/common/Library.gmk ! make/sun/security/ec/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/security/smartcardio/Makefile ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c ! src/windows/native/sun/security/pkcs11/j2secmod_md.c Changeset: 72666cd49ac3 Author: alanb Date: 2011-10-25 09:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/72666cd49ac3 7104577: Changes for 7104209 cause many RMI tests to fail Reviewed-by: chegar ! src/share/classes/sun/rmi/server/MarshalInputStream.java Changeset: 7814800c64bd Author: lana Date: 2011-10-25 21:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7814800c64bd Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 09fd2067f715 Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/09fd2067f715 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: d636e737c478 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d636e737c478 Added tag jdk8-b12 for changeset 09fd2067f715 ! .hgtags Changeset: bfd720647db2 Author: yhuang Date: 2011-10-31 20:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bfd720647db2 7077119: remove past transition dates from CurrencyData.properties file Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! test/java/util/Currency/CurrencyTest.java ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt Changeset: cfc6fd491b97 Author: yhuang Date: 2011-10-31 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cfc6fd491b97 6755060: Collator.compare() does not compare correctly for the Thai locale Reviewed-by: naoto ! src/share/classes/sun/text/resources/CollationData_th.java + test/sun/text/resources/Collator/Bug6755060.java Changeset: 0549410acf26 Author: yhuang Date: 2011-10-31 21:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0549410acf26 Merge Changeset: f3227efde13d Author: yhuang Date: 2011-10-31 21:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f3227efde13d 7101495: In Latvia first day of week is Monday Reviewed-by: naoto, peytoia ! src/share/classes/sun/util/resources/CalendarData_lv.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: ab837acc60fb Author: yhuang Date: 2011-10-31 21:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ab837acc60fb Merge Changeset: 631ee738378a Author: mfang Date: 2011-11-03 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/631ee738378a Merge Changeset: 94e5604022fa Author: ngmr Date: 2011-09-15 19:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/94e5604022fa 6988099: jvmti demos missing Publisher (COMPANY resource) in dlls/exes on windows Summary: Add creation/linking of resource data to link step for demos on Windows Reviewed-by: dcubed, zgu, ngmr, ohair Contributed-by: Sean Chou ! make/common/Demo.gmk Changeset: 5791714b9472 Author: ohair Date: 2011-11-04 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5791714b9472 Merge Changeset: 4cb2e8679b27 Author: katleman Date: 2011-11-09 13:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4cb2e8679b27 Merge Changeset: 52bd7fc8fcb0 Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/52bd7fc8fcb0 Added tag jdk8-b13 for changeset 4cb2e8679b27 ! .hgtags Changeset: 9de1dbf8c9be Author: lana Date: 2011-10-26 17:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9de1dbf8c9be Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: 76defa20906a Author: ngmr Date: 2011-09-23 15:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/76defa20906a 7105640: Unix printing does not check the result of exec'd lpr/lp command Summary: Add checking, exception for spool process failure Reviewed-by: prr, jgodinez Contributed-by: Neil Richards ! src/share/classes/sun/print/PSPrinterJob.java ! src/solaris/classes/sun/print/UnixPrintJob.java Changeset: 4544585a3cea Author: lana Date: 2011-11-05 14:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4544585a3cea Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: aa3f5117c485 Author: rupashka Date: 2011-10-17 15:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/aa3f5117c485 7099251: javax.swing.text.html.HTMLDocument.insertAfterStart(null, something) throws NPE Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 4f74e3fdf86b Author: rupashka Date: 2011-10-17 16:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4f74e3fdf86b 7100004: javax.swing.JTable.setAutoCreateRowSorter(boolean autoCreateRowSorter) should mention default value Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/javax/swing/JTable.java Changeset: f1dbc62c7c6d Author: rupashka Date: 2011-10-17 17:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f1dbc62c7c6d 7077293: javax/swing/JComponent/4337267/bug4337267.java failed on windows 2003 Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: a2f5d7049258 Author: dbuck Date: 2011-10-17 19:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a2f5d7049258 6887286: StackOverflowError at sun.awt.image.ImageWatched$WeakLink.isWatcher Summary: Fixed OffScreenImageSource to call imageComplete() with SINGLEFAMEDONE, not STATICIMAGEDONE. This fixed memory leak (that caused SOFE when we use recursion to iterate over linked list). Reviewed-by: bae ! src/share/classes/sun/awt/image/OffScreenImageSource.java Changeset: 7636a62aba7e Author: anthony Date: 2011-11-01 18:01 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7636a62aba7e 7104625: sun.awt.X11.XEvent is creating 600 MB of char[] for no good reason Summary: Wrap logging calls with if(){} statements Reviewed-by: anthony, son Contributed-by: Federico Tello Gentile ! src/solaris/classes/sun/awt/X11/XComponentPeer.java Changeset: ac55f169fadd Author: anthony Date: 2011-11-01 18:03 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ac55f169fadd 7105529: XAWT: Optimize getFieldsAsString() methods generated by WrapperGenerator Summary: Replace string concatenation with StringBuilder.append() Reviewed-by: anthony, son Contributed-by: Federico Tello Gentile ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java Changeset: 41610a897379 Author: rupashka Date: 2011-11-02 14:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/41610a897379 6624077: Regression test fails: closed/javax/swing/ToolTipManager/6256140/bug6256140.java Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/ToolTipManager/Test6256140.java Changeset: 8068f1584715 Author: mrkam Date: 2011-11-02 17:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8068f1584715 7074853: TransparentRuler demos Readme should mention the correct jar file name Reviewed-by: rupashka ! src/share/demo/jfc/TransparentRuler/README.txt Changeset: 323f6d046cc9 Author: rupashka Date: 2011-11-02 23:53 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/323f6d046cc9 7049024: DnD fails with JTextArea and JTextField Reviewed-by: rupashka Contributed-by: Sean Chou ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/JTextArea/7049024/bug7049024.java Changeset: 7c29751a9331 Author: rupashka Date: 2011-11-03 14:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7c29751a9331 6955919: Intermittent ClassCastException in bug4492274 test Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JEditorPane/4492274/bug4492274.java + test/javax/swing/JEditorPane/4492274/test.html Changeset: 1c0624d9a2b6 Author: ngmr Date: 2011-10-13 13:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1c0624d9a2b6 7107957: AWT: Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Summary: Use POSIX defined includes for unistd.h and fcntl.h Reviewed-by: anthony, ngmr Contributed-by: Charles Lee ! src/solaris/native/sun/awt/splashscreen/splashscreen_config.h Changeset: adb31ff942ef Author: rupashka Date: 2011-11-07 16:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/adb31ff942ef 7080203: JTree.getSelectionPaths() now returns empty array instead of null Reviewed-by: malenkov ! src/share/classes/javax/swing/JTree.java Changeset: d219e0b11327 Author: lana Date: 2011-11-07 10:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d219e0b11327 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: f8a3dff76b48 Author: rupashka Date: 2011-11-08 14:36 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f8a3dff76b48 7107585: Test incorrect calculate position of object on frame Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JSlider/6348946/bug6348946.java Changeset: af4fb33fca29 Author: lana Date: 2011-11-08 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/af4fb33fca29 Merge Changeset: 88a260444e4d Author: chegar Date: 2011-10-26 13:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/88a260444e4d 7104650: rawtype warnings in several net, nio and security source files Summary: Also reviewed by Ulf.Zibis at gmx.de Reviewed-by: mcimadamore, alanb, dholmes ! make/sun/net/Makefile ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/security/Security.java ! src/share/classes/sun/nio/ch/Util.java Changeset: 0d371f2911a1 Author: peytoia Date: 2011-10-26 22:16 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0d371f2911a1 7090046: Lots of invalid link in java.text.BreakIterator comments Reviewed-by: okutsu ! src/share/classes/java/text/BreakIterator.java Changeset: 291b55aa9b1e Author: lana Date: 2011-10-25 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/291b55aa9b1e Merge - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 64faf533b99d Author: lana Date: 2011-10-26 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/64faf533b99d Merge Changeset: 449113aea001 Author: weijun Date: 2011-10-27 17:23 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/449113aea001 7104161: test/sun/tools/jinfo/Basic.sh fails on Ubuntu Reviewed-by: alanb ! test/sun/tools/jinfo/Basic.sh Changeset: 64ccf18bbad5 Author: coffeys Date: 2011-10-27 10:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/64ccf18bbad5 7099658: Properties.loadFromXML fails with ClassCastException Reviewed-by: alanb, mchung ! src/share/classes/sun/util/xml/XMLUtils.java Changeset: 56cc907fc8dc Author: mullan Date: 2011-10-27 10:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/56cc907fc8dc 7094155: JSR105 code throws javax.xml.crypto.URIReferenceException when running into Java 7 VM Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! test/javax/xml/crypto/dsig/GenerationTests.java Changeset: 8cd2e3b8127a Author: mullan Date: 2011-10-27 11:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8cd2e3b8127a Merge - make/sun/rmi/rmi/mapfile-vers - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c Changeset: 6e59c482e9b8 Author: xuelei Date: 2011-10-28 07:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6e59c482e9b8 7105940: Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore Reviewed-by: weijun ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java Changeset: bb2b9a8b6e77 Author: alanb Date: 2011-10-30 14:53 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bb2b9a8b6e77 7103889: (fs) Reduce String concatenation when iterating over directory Reviewed-by: alanb Contributed-by: mike.skells at talk21.com ! src/share/classes/java/nio/file/Files.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsPathParser.java Changeset: 30900a1a9cfc Author: xuelei Date: 2011-10-30 20:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/30900a1a9cfc 7106277: Brokenness in the seqNumberOverflow of MAC Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/MAC.java Changeset: 8681362a2f04 Author: wetmore Date: 2011-10-31 11:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8681362a2f04 7105780: Add SSLSocket client/SSLEngine server to templates directory Reviewed-by: xuelei + test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: b60e88ef5d8d Author: wetmore Date: 2011-10-31 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b60e88ef5d8d 7053252: New regression test does not compile on windows-amd64 Reviewed-by: valeriep ! test/ProblemList.txt ! test/sun/security/pkcs11/Provider/Absolute.java Changeset: 5f2838744544 Author: ysr Date: 2011-10-31 17:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5f2838744544 4243978: (ref) Race condition in Reference.enqueue() 4268317: (ref) Reference.isEnqueued() can return true when instance not enqueued Summary: The reference handler now declares, and assumes, that the discovered field, rather than the next field, is (to be) used to link the entries in the pending list, thus allowing a reference object to be safely enqueued even while it is in the pending state. Also added slightly modified regression tests from the two bug reports. Reviewed-by: mchung, alanb, jcoomes ! src/share/classes/java/lang/ref/Reference.java ! src/share/javavm/export/jvm.h ! src/share/native/common/jdk_util.c + test/java/lang/ref/ReferenceEnqueue.java + test/java/lang/ref/ReferenceEnqueuePending.java Changeset: 2f2f56ac8b82 Author: mduigou Date: 2011-11-03 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2f2f56ac8b82 4533691: Add Collections.emptySortedSet() Reviewed-by: mduigou, alanb, dholmes Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/EmptySortedSet.java Changeset: ead9dabe8c75 Author: lana Date: 2011-11-05 00:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ead9dabe8c75 Merge Changeset: 417d91754849 Author: sherman Date: 2011-11-07 13:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/417d91754849 7096080: UTF8 update and new CESU-8 charset 7082884: Incorrect UTF8 conversion for sequence ED 31 7082883: Incorrect UTF8 conversion for sequence fc 80 80 8f bf bf Summary: Updated UTF8 and added CESU-8 to following the latest Standard Reviewed-by: alanb ! make/java/nio/FILES_java.gmk + src/share/classes/sun/nio/cs/CESU_8.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/standard-charsets ! test/java/nio/charset/coders/Errors.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/TestStringCodingUTF8.java ! test/sun/nio/cs/TestUTF8.java Changeset: 0bb498332894 Author: lana Date: 2011-11-08 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0bb498332894 Merge Changeset: 51db54a3b953 Author: lana Date: 2011-11-14 18:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/51db54a3b953 Merge Changeset: 3b2128c89361 Author: alanb Date: 2011-06-15 14:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3b2128c89361 7000600: InputStream.skip() makes sensitive data accessible to malicious code Reviewed-by: hawtin, chegar ! src/share/classes/java/io/InputStream.java Changeset: 06e0d91548b3 Author: anthony Date: 2011-06-21 20:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/06e0d91548b3 7022113: Security icon can be moved behind the window using the com.sun.SecurityWarning.setPosition() method Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Window.cpp Changeset: d32b75c73389 Author: alanb Date: 2011-06-27 20:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d32b75c73389 7059259: (process) ProcessBuilder.start permission check should be improved when redirecting output to append Reviewed-by: hawtin ! src/windows/classes/java/lang/ProcessImpl.java Changeset: 446b13a08aca Author: asaha Date: 2011-06-27 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/446b13a08aca Merge Changeset: 4fdd1a44e846 Author: asaha Date: 2011-06-27 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4fdd1a44e846 Merge Changeset: 3e42f7893861 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3e42f7893861 Merge Changeset: f578448792b9 Author: ksrini Date: 2011-07-15 13:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f578448792b9 7057857: SIGSEGV [libunpack.so] store_Utf8_char(signed char*, unsigned short) in java.util.jar.pack200 Reviewed-by: jrose, asaha, hawtin ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.h Changeset: 4b20375fe623 Author: asaha Date: 2011-07-19 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4b20375fe623 Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: bc9c70e57f62 Author: asaha Date: 2011-07-20 09:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bc9c70e57f62 7032417: Fix for 6981922 does not address multiple VM case Reviewed-by: michaelm ! src/share/classes/sun/net/ResourceManager.java Changeset: a7177942302f Author: asaha Date: 2011-07-20 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a7177942302f 7023640: calculation for malloc size in TransformHelper.c could overflow an integer Reviewed-by: flar ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: 6c76f2a49061 Author: denis Date: 2011-07-22 21:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6c76f2a49061 7019773: AWTKeyStroke.ctor is a mutable static Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: b25558c39ffc Author: smarks Date: 2011-08-30 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b25558c39ffc 7077466: fix for RMI DGC Reviewed-by: valeriep ! src/share/classes/sun/rmi/server/UnicastServerRef.java Changeset: efd8035f3d14 Author: smarks Date: 2011-08-30 17:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/efd8035f3d14 7083012: fix for RMI Registry Reviewed-by: jdn, valeriep ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java Changeset: 27bda11f1330 Author: smarks Date: 2011-09-21 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/27bda11f1330 7092186: adjust package access in rmiregistry Reviewed-by: asaha, coffeys ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! test/sun/tools/jstatd/jstatdExternalRegistry.sh Changeset: 42eb725f739c Author: xuelei Date: 2011-09-29 17:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/42eb725f739c 7064341: jsse/runtime security problem Reviewed-by: wetmore ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java Changeset: 53a16cf28db3 Author: xuelei Date: 2011-09-30 18:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/53a16cf28db3 7096936: issue in jsse/runtime 7096937: TEST: com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java need modification as a result of TLS fix Reviewed-by: wetmore, jdn, xuelei ! src/share/classes/com/sun/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java Changeset: 27a8f4fc555a Author: asaha Date: 2011-11-14 11:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/27a8f4fc555a Merge ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java ! test/sun/tools/jstatd/jstatdExternalRegistry.sh Changeset: 99632935785e Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/99632935785e Merge Changeset: 00e2c88e2234 Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/00e2c88e2234 Added tag jdk8-b14 for changeset 99632935785e ! .hgtags Changeset: 2a147f854257 Author: twisti Date: 2011-11-02 02:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2a147f854257 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Reviewed-by: jrose, never ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + test/java/lang/invoke/CallSiteTest.java Changeset: 5c34ed65176e Author: twisti Date: 2011-11-09 00:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5c34ed65176e 7109063: JSR 292: fix for 7085860 is incomplete Reviewed-by: iveresov, alanb, jrose ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/ProblemList.txt ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java Changeset: bdb2d63c176c Author: jcoomes Date: 2011-11-18 16:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bdb2d63c176c Merge ! test/ProblemList.txt From manojo10386 at gmail.com Fri Nov 25 02:08:45 2011 From: manojo10386 at gmail.com (Manohar Jonnalagedda) Date: Fri, 25 Nov 2011 11:08:45 +0100 Subject: Proper usage of -XX:+PrintIdeal (xpost from hotspot-dev) Message-ID: Hello all, I posted this topic on hotspot-dev, but I was advised to post this here as well : http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-November/004772.html . I am new to using the debug features of hotspot, and was interested in checking out the graph of a program that I wrote. The program contains a method 'methodA' which I would like to inspect in terms of optimizations performed. I verified using the PrintCompilation (and PrintAssembly) flag that it was indeed JIT compiled. (20.0-b17 of the fastdebug build) When I use the PrintIdeal flags, however, my output xml files do not contain any mention of this method. Here is the command I use : $JAVA_HOME/bin/java -verbose:gc -server -d64 -XX:+UseCompressedOops -XX:+DoEscapeAnalysis -XX:PrintIdealGraphLevel=1 -XX:PrintIdealGraphFile="file.xml" -XX:+PrintIdeal $JAVA_OPTS "$@" I have two output files, file.xml and file1.xml, and neither contain the method I am looking for. I only have details for 4 methods, one of them being a decodeArrayLoop and the others being methods from the API (file input and string manipulation methods). Is it possible that methodA would not be JIT compiled following the extra instrumentation overhead? Thanks a lot for your help, Manohar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111125/7bd55b5d/attachment.html From vladimir.kozlov at oracle.com Mon Nov 28 10:40:13 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Nov 2011 10:40:13 -0800 Subject: type oddity In-Reply-To: <2860ECE2-F7C0-4309-8327-DC1C1D10D817@oracle.com> References: <2860ECE2-F7C0-4309-8327-DC1C1D10D817@oracle.com> Message-ID: <4ED3D58D.1030904@oracle.com> This changes were made for next bug. Bug report has explanation. 4933273: Flattened alias type for [KlassPtr + offset] must be consistent Vladimir Tom Rodriguez wrote: > While looking into a failure in the metadata repo I noticed this code in flatten_alias_type: > > // Klass pointers to object array klasses need some flattening > const TypeKlassPtr *tk = tj->isa_klassptr(); > if( tk ) { > // If we are referencing a field within a Klass, we need > // to assume the worst case of an Object. Both exact and > // inexact types must flatten to the same alias class. > // Since the flattened result for a klass is defined to be > // precisely java.lang.Object, use a constant ptr. > if ( offset == Type::OffsetBot || (offset >= 0 && (size_t)offset < sizeof(Klass)) ) { > > tj = tk = TypeKlassPtr::make(TypePtr::Constant, > TypeKlassPtr::OBJECT->klass(), > offset); > } > > It's followed by a couple checks for specific fields where the PTR is changes to NotNull for just those offsets. It seems odd to me that Constant is used here since we're flattening a non constant type into a constant one for some fields but not for others. We end up with a constant class for things like the java_mirror field which seems wrong: > > precise klass java/lang/Object: 0x08142438:Constant:exact+64 * > > For objArrayKlass we convert it back to NotNull. The comment explaining why Constant is used doesn't really make sense either. Anyone know why it's done this way? > > tom From tom.rodriguez at oracle.com Mon Nov 28 11:01:01 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 28 Nov 2011 11:01:01 -0800 Subject: type oddity In-Reply-To: <4ED3D58D.1030904@oracle.com> References: <2860ECE2-F7C0-4309-8327-DC1C1D10D817@oracle.com> <4ED3D58D.1030904@oracle.com> Message-ID: <4029DB5C-5293-4F65-A558-A790D2E350F4@oracle.com> On Nov 28, 2011, at 10:40 AM, Vladimir Kozlov wrote: > This changes were made for next bug. Bug report has explanation. > > 4933273: Flattened alias type for [KlassPtr + offset] must be consistent The explanation in there all makes sense. The original bug was that it was using the incoming ptr instead of picking a single PTR for the flattening. Picking Constant instead of NotNull doesn't make any sense though since it results in a more precise type than is probably warranted. Functionally I think it makes little difference unless we try to assume that because the type of the AddP was precise that we could read through a constant. Anyway, thanks for the history pointer. Dean sent me that too. tom > > Vladimir > > Tom Rodriguez wrote: >> While looking into a failure in the metadata repo I noticed this code in flatten_alias_type: >> // Klass pointers to object array klasses need some flattening const TypeKlassPtr *tk = tj->isa_klassptr(); >> if( tk ) { >> // If we are referencing a field within a Klass, we need // to assume the worst case of an Object. Both exact and // inexact types must flatten to the same alias class. // Since the flattened result for a klass is defined to be // precisely java.lang.Object, use a constant ptr. if ( offset == Type::OffsetBot || (offset >= 0 && (size_t)offset < sizeof(Klass)) ) { >> tj = tk = TypeKlassPtr::make(TypePtr::Constant, >> TypeKlassPtr::OBJECT->klass(), >> offset); >> } >> It's followed by a couple checks for specific fields where the PTR is changes to NotNull for just those offsets. It seems odd to me that Constant is used here since we're flattening a non constant type into a constant one for some fields but not for others. We end up with a constant class for things like the java_mirror field which seems wrong: >> precise klass java/lang/Object: 0x08142438:Constant:exact+64 * >> For objArrayKlass we convert it back to NotNull. The comment explaining why Constant is used doesn't really make sense either. Anyone know why it's done this way? >> tom From vladimir.kozlov at oracle.com Mon Nov 28 18:22:23 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 29 Nov 2011 02:22:23 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE Message-ID: <20111129022226.0DA6F4747F@hg.openjdk.java.net> Changeset: cc81b9c09bbb Author: kvn Date: 2011-11-28 15:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cc81b9c09bbb 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE Summary: Fixed several EA issues with Connection Graph construction. Reviewed-by: never, twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp From igor.veresov at oracle.com Wed Nov 30 14:27:32 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Nov 2011 14:27:32 -0800 Subject: review(XS): 7116795: Tiered: enable by default for server Message-ID: <6CA73E974AEB4169A881E6A0652DE902@oracle.com> This switches tiered mode on by default for server. Webrev: http://cr.openjdk.java.net/~iveresov/7116795/webrev.00/ Thanks!igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111130/3c844eb8/attachment.html From vladimir.kozlov at oracle.com Wed Nov 30 17:01:39 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Nov 2011 17:01:39 -0800 Subject: review(XS): 7116795: Tiered: enable by default for server In-Reply-To: <6CA73E974AEB4169A881E6A0652DE902@oracle.com> References: <6CA73E974AEB4169A881E6A0652DE902@oracle.com> Message-ID: <4ED6D1F3.1090000@oracle.com> Good. Vladimir Igor Veresov wrote: > This switches tiered mode on by default for server. > > Webrev: http://cr.openjdk.java.net/~iveresov/7116795/webrev.00/ > > Thanks! > igor > From tom.rodriguez at oracle.com Wed Nov 30 17:09:31 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 30 Nov 2011 17:09:31 -0800 Subject: review(XS): 7116795: Tiered: enable by default for server In-Reply-To: <6CA73E974AEB4169A881E6A0652DE902@oracle.com> References: <6CA73E974AEB4169A881E6A0652DE902@oracle.com> Message-ID: <54386771-010F-4671-841D-6C4C1721D22E@oracle.com> Does JPRT already know the nontiered target? Otherwise it looks fine. tom On Nov 30, 2011, at 2:27 PM, Igor Veresov wrote: > This switches tiered mode on by default for server. > > Webrev: http://cr.openjdk.java.net/~iveresov/7116795/webrev.00/ > > Thanks! > igor > From igor.veresov at oracle.com Wed Nov 30 17:13:57 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Nov 2011 17:13:57 -0800 Subject: review(XS): 7116795: Tiered: enable by default for server In-Reply-To: <54386771-010F-4671-841D-6C4C1721D22E@oracle.com> References: <6CA73E974AEB4169A881E6A0652DE902@oracle.com> <54386771-010F-4671-841D-6C4C1721D22E@oracle.com> Message-ID: Yes, it does. I did a test run. Thanks! igor On Wednesday, November 30, 2011 at 5:09 PM, Tom Rodriguez wrote: > Does JPRT already know the nontiered target? Otherwise it looks fine. > > tom > > On Nov 30, 2011, at 2:27 PM, Igor Veresov wrote: > > > This switches tiered mode on by default for server. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7116795/webrev.00/ > > > > Thanks! > > igor > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111130/0af1a219/attachment.html From igor.veresov at oracle.com Wed Nov 30 17:14:17 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Nov 2011 17:14:17 -0800 Subject: review(XS): 7116795: Tiered: enable by default for server In-Reply-To: <4ED6D1F3.1090000@oracle.com> References: <6CA73E974AEB4169A881E6A0652DE902@oracle.com> <4ED6D1F3.1090000@oracle.com> Message-ID: Thanks Azeem, Vladimir and Tom! igor On Wednesday, November 30, 2011 at 5:01 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > Igor Veresov wrote: > > This switches tiered mode on by default for server. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7116795/webrev.00/ > > > > Thanks! > > igor > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111130/c4d4f926/attachment.html From igor.veresov at oracle.com Wed Nov 30 21:30:07 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 01 Dec 2011 05:30:07 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7116795: Tiered: enable by default for server Message-ID: <20111201053009.4A7A3474E0@hg.openjdk.java.net> Changeset: 97825a4f7369 Author: iveresov Date: 2011-11-30 17:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/97825a4f7369 7116795: Tiered: enable by default for server Summary: Enable tiered compilation on server VM by default Reviewed-by: kvn, never ! make/jprt.properties ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp