From kirk at kodewerk.com Fri Jul 1 07:18:33 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Fri, 1 Jul 2011 16:18:33 +0200 Subject: review(XS): 7058689 Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods In-Reply-To: <4E04B25A.8060701@oracle.com> References: <4E03D6D8.7010308@oracle.com> <4E04B25A.8060701@oracle.com> Message-ID: <6944CFAB-3F10-4D86-953B-51D59CF205B2@kodewerk.com> Hi, I'm experiencing this problem in the JVM. There is enough swap so the message is mysterious. We're going to look at the code cache so I don't have information about it currently. This error happen regularly and it happens when a method (random method) is being compiled. This is a 32 bit 1.6.0_16 running Weblogic (10.3b). Nothing in the bug database rings a bell. # java.lang.OutOfMemoryError: requested 1108064 bytes for Chunk::new. Out of swap space? # # Internal Error (allocation.cpp:215), pid=16887, tid=32 # Error: Chunk::new --------------- T H R E A D --------------- Current thread (0x016eb500): JavaThread "CompilerThread0" daemon [_thread_in_native, id=32, stack(0x68e00000,0x68e80000)] Stack: [0x68e00000,0x68e80000], sp=0x68e7d908, free space=502k Current CompileTask: C2:8228 ! oracle.jdbc.driver.PhysicalConnection.readConnectionProperties(Ljava/lang/String;Ljava/util/Properties;)V (5038 bytes) Regards, Kirk From igor.veresov at oracle.com Fri Jul 1 12:55:39 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 01 Jul 2011 12:55:39 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E08FA79.3040608@oracle.com> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> Message-ID: <4E0E263B.4060705@oracle.com> Following the advise of John Rose I made arguments transfer via java array for arrays with > 5 dimensions. Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.02/ igor On 6/27/11 2:47 PM, Igor Veresov wrote: > Thanks for the review, Tom! > I'll try to implement the vararg calls. > > igor > > On 6/27/11 1:41 PM, Tom Rodriguez wrote: >> Is there any easy way to just make C2 support a varargs style call for >> multianewarray? C1 just does a funny calling convention where it >> passes a pointer a stack allocated array which is obviously possible >> with C2 though we don't have anything like it right now. I can see how >> to do this by cons'ing up type signatures as need with extra count and >> pointer arguments and then modifying the c_calling_convention to >> switch to the stack only calling convention after the first two. The >> only extra trick would be getting the address of the stack arguments >> into the call when it's converted into a MachCall. We don't really >> have a way to express that using MachNodes since stack slots are >> virtual are that point. Maybe it could simply be handled at the ad >> file level. >> >> So something like a new MachCallRuntimeVarargsNode with an index >> indicating which argument is the last real one, the >> c_calling_convention modified to take an index indicating when it >> should force a switch to stack only, and the ins_encode for that match >> inserting the right address computation for the address. Is that too >> complex for the limited benefit? Maybe compared to the complexity of >> the existing machinery, it's not too bad. >> >> As far as your webrev, I don't think you want to do this: >> >> + if (per_bc_reason == Reason_unhandled) { >> + make_not_compilable = true; >> + } >> >> There are other uses of Reason_unhandled and it's not clear the >> stopping compilation is the right action for those other cases. Maybe >> you need another action? Or maybe the actions need to be interpreted >> specially for Reason_unhandled. Doing a make_not_entrant doesn't seem >> like the right action for some of the other Reason_unhandleds. >> >> I do like the trap_state changes if it allows us to move >> Reason_loop_predicate and Reason_loop_limit_check into the per bci >> section. >> >> tom >> >> On Jun 27, 2011, at 12:07 PM, Igor Veresov wrote: >> >>> Problem: multinewarray with>= 6 dimensions is not supported by c2 and >>> is plugged with uncommon trap. When executed in the main code path >>> this yields performance far worse than even interpreter. >>> >>> Solution: Count these traps per bci and when the number exceeds >>> PerBytecodeTrapLimit make it not compilable. With tiered it would >>> result in recompilation at level 1 (pure C1), with regular scheme the >>> method will continue in the interpreter. >>> >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.00/ >>> >>> >>> Thanks, >>> igor >> > From igor.veresov at oracle.com Fri Jul 1 13:02:04 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 01 Jul 2011 20:02:04 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110701200207.D9A7F470F5@hg.openjdk.java.net> Changeset: 6f6e91603a45 Author: iveresov Date: 2011-07-01 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6f6e91603a45 7058689: Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods Summary: Take into account current state of profiling before believing that existing higher level versions are valid Reviewed-by: kvn, never ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp Changeset: 2c359f27615c Author: iveresov Date: 2011-07-01 10:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2c359f27615c 7057120: Tiered: Allow C1 to inline methods with loops Summary: Recompile the enclosing methods without inlining of the method that has OSRed to level 4 or recompile the enclosing method at level 4. Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp From vladimir.kozlov at oracle.com Fri Jul 1 13:26:16 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 01 Jul 2011 13:26:16 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E0E263B.4060705@oracle.com> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> Message-ID: <4E0E2D68.40706@oracle.com> Typo: dimention should be dimension. Wrap new java dimension allocation into PreserveReexecuteState scope and restore stack. Vladimir Igor Veresov wrote: > Following the advise of John Rose I made arguments transfer via java > array for arrays with > 5 dimensions. > > Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.02/ > > igor > > > On 6/27/11 2:47 PM, Igor Veresov wrote: >> Thanks for the review, Tom! >> I'll try to implement the vararg calls. >> >> igor >> >> On 6/27/11 1:41 PM, Tom Rodriguez wrote: >>> Is there any easy way to just make C2 support a varargs style call for >>> multianewarray? C1 just does a funny calling convention where it >>> passes a pointer a stack allocated array which is obviously possible >>> with C2 though we don't have anything like it right now. I can see how >>> to do this by cons'ing up type signatures as need with extra count and >>> pointer arguments and then modifying the c_calling_convention to >>> switch to the stack only calling convention after the first two. The >>> only extra trick would be getting the address of the stack arguments >>> into the call when it's converted into a MachCall. We don't really >>> have a way to express that using MachNodes since stack slots are >>> virtual are that point. Maybe it could simply be handled at the ad >>> file level. >>> >>> So something like a new MachCallRuntimeVarargsNode with an index >>> indicating which argument is the last real one, the >>> c_calling_convention modified to take an index indicating when it >>> should force a switch to stack only, and the ins_encode for that match >>> inserting the right address computation for the address. Is that too >>> complex for the limited benefit? Maybe compared to the complexity of >>> the existing machinery, it's not too bad. >>> >>> As far as your webrev, I don't think you want to do this: >>> >>> + if (per_bc_reason == Reason_unhandled) { >>> + make_not_compilable = true; >>> + } >>> >>> There are other uses of Reason_unhandled and it's not clear the >>> stopping compilation is the right action for those other cases. Maybe >>> you need another action? Or maybe the actions need to be interpreted >>> specially for Reason_unhandled. Doing a make_not_entrant doesn't seem >>> like the right action for some of the other Reason_unhandleds. >>> >>> I do like the trap_state changes if it allows us to move >>> Reason_loop_predicate and Reason_loop_limit_check into the per bci >>> section. >>> >>> tom >>> >>> On Jun 27, 2011, at 12:07 PM, Igor Veresov wrote: >>> >>>> Problem: multinewarray with>= 6 dimensions is not supported by c2 and >>>> is plugged with uncommon trap. When executed in the main code path >>>> this yields performance far worse than even interpreter. >>>> >>>> Solution: Count these traps per bci and when the number exceeds >>>> PerBytecodeTrapLimit make it not compilable. With tiered it would >>>> result in recompilation at level 1 (pure C1), with regular scheme the >>>> method will continue in the interpreter. >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.00/ >>>> >>>> >>>> Thanks, >>>> igor >>> >> > From john.r.rose at oracle.com Fri Jul 1 13:50:31 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 1 Jul 2011 13:50:31 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E0E2D68.40706@oracle.com> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> <4E0E2D68.40706@oracle.com> Message-ID: On Jul 1, 2011, at 1:26 PM, Vladimir Kozlov wrote: > Wrap new java dimension allocation into PreserveReexecuteState scope and restore stack. Is this in case the initial allocation deoptimizes (due to some external event)? I suppose that should be tested with DeoptimizeALot. Igor, the extraction from the dope array bothers me: + jint *j_dims = (jint*)dims->base(T_INT); + jint *c_dims = NEW_RESOURCE_ARRAY(jint, len); + memcpy(c_dims, j_dims, sizeof(jint)*len); It is correct, but I'd rather see more use of Hotspot machinery, with stronger typing: + jint *j_dims = typeArrayOop(dims)->int_at_addr(0); + jint *c_dims = NEW_RESOURCE_ARRAY(jint, len); + Copy::conjoint_jints_atomic(c_dims, j_dims, sizeof(jint)*len); Note that Copy::* strongly outnumbers memcpy in the opto directory. The distinction is mostly stylistic, but Copy:: is more strongly typed in this case. (In other uses, Copy:: is more explicit and careful about some of the things we need to care about, such as overlaps and word-tearing.) Also, use is_typeArray instead of is_array in the previous assert. That will make the cast to typeArrayOop safe. -- John From Peter.B.Kessler at Oracle.COM Fri Jul 1 14:01:02 2011 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Fri, 01 Jul 2011 14:01:02 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E0E263B.4060705@oracle.com> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> Message-ID: <4E0E358E.7010900@Oracle.COM> In src/share/vm/opto/parse3.cpp:478, you took out the default for the switch, which used to catch the case where ndimensions==1 and call ShouldNotReachHere(). Now, if ndimension==1 you will go to the new OptoRuntime::multianewarrayN_* methods. I think that will work (but I haven't checked carefully), but I wonder if that's what you intended, or if we shouldn't send that case to new_array, or call ShouldNotReachHere because something really is wrong in that case? I understand the principle of least change, especially at this point a release, but do we really still need the special cases for arrays of 2, 3, 4, and 5 dimensions? Should there be another bug to clean those up later. They are extra code to maintain. I don't know the opto/runtime style, but there sure seems to be a lot of copying of the array dimensions. Could you make up the jint array early and just pass that around, or do you need the Node array of intcon's. (E.g., do you need them for the type mechanisms?) This is more a question for my understanding than a comment on your code. ... peter On 20110701 12:55 PM, Igor Veresov wrote: > Following the advise of John Rose I made arguments transfer via java array for arrays with > 5 dimensions. > > Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.02/ > > igor > > > On 6/27/11 2:47 PM, Igor Veresov wrote: >> Thanks for the review, Tom! >> I'll try to implement the vararg calls. >> >> igor >> >> On 6/27/11 1:41 PM, Tom Rodriguez wrote: >>> Is there any easy way to just make C2 support a varargs style call for >>> multianewarray? C1 just does a funny calling convention where it >>> passes a pointer a stack allocated array which is obviously possible >>> with C2 though we don't have anything like it right now. I can see how >>> to do this by cons'ing up type signatures as need with extra count and >>> pointer arguments and then modifying the c_calling_convention to >>> switch to the stack only calling convention after the first two. The >>> only extra trick would be getting the address of the stack arguments >>> into the call when it's converted into a MachCall. We don't really >>> have a way to express that using MachNodes since stack slots are >>> virtual are that point. Maybe it could simply be handled at the ad >>> file level. >>> >>> So something like a new MachCallRuntimeVarargsNode with an index >>> indicating which argument is the last real one, the >>> c_calling_convention modified to take an index indicating when it >>> should force a switch to stack only, and the ins_encode for that match >>> inserting the right address computation for the address. Is that too >>> complex for the limited benefit? Maybe compared to the complexity of >>> the existing machinery, it's not too bad. >>> >>> As far as your webrev, I don't think you want to do this: >>> >>> + if (per_bc_reason == Reason_unhandled) { >>> + make_not_compilable = true; >>> + } >>> >>> There are other uses of Reason_unhandled and it's not clear the >>> stopping compilation is the right action for those other cases. Maybe >>> you need another action? Or maybe the actions need to be interpreted >>> specially for Reason_unhandled. Doing a make_not_entrant doesn't seem >>> like the right action for some of the other Reason_unhandleds. >>> >>> I do like the trap_state changes if it allows us to move >>> Reason_loop_predicate and Reason_loop_limit_check into the per bci >>> section. >>> >>> tom >>> >>> On Jun 27, 2011, at 12:07 PM, Igor Veresov wrote: >>> >>>> Problem: multinewarray with>= 6 dimensions is not supported by c2 and >>>> is plugged with uncommon trap. When executed in the main code path >>>> this yields performance far worse than even interpreter. >>>> >>>> Solution: Count these traps per bci and when the number exceeds >>>> PerBytecodeTrapLimit make it not compilable. With tiered it would >>>> result in recompilation at level 1 (pure C1), with regular scheme the >>>> method will continue in the interpreter. >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.00/ >>>> >>>> >>>> Thanks, >>>> igor >>> >> > From vladimir.kozlov at oracle.com Fri Jul 1 14:00:13 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 01 Jul 2011 14:00:13 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> <4E0E2D68.40706@oracle.com> Message-ID: <4E0E355D.3050502@oracle.com> John Rose wrote: > On Jul 1, 2011, at 1:26 PM, Vladimir Kozlov wrote: > >> Wrap new java dimension allocation into PreserveReexecuteState scope and restore stack. > > Is this in case the initial allocation deoptimizes (due to some external event)? I suppose that should be tested with DeoptimizeALot. The allocation of dimension array may go slow path (no space left in TLAB) into runtime and on return the method could be deoptimized so we need restore stack so that interpreter can reexecute multinewarray allocation. There are several places where we do this already (for example, around the call to expand_multianewarray()). And yes, it should be tested with DeoptimizeALot. Vladimir > > Igor, the extraction from the dope array bothers me: > + jint *j_dims = (jint*)dims->base(T_INT); > + jint *c_dims = NEW_RESOURCE_ARRAY(jint, len); > + memcpy(c_dims, j_dims, sizeof(jint)*len); > > It is correct, but I'd rather see more use of Hotspot machinery, with stronger typing: > + jint *j_dims = typeArrayOop(dims)->int_at_addr(0); > + jint *c_dims = NEW_RESOURCE_ARRAY(jint, len); > + Copy::conjoint_jints_atomic(c_dims, j_dims, sizeof(jint)*len); > > Note that Copy::* strongly outnumbers memcpy in the opto directory. The distinction is mostly stylistic, but Copy:: is more strongly typed in this case. > > (In other uses, Copy:: is more explicit and careful about some of the things we need to care about, such as overlaps and word-tearing.) > > Also, use is_typeArray instead of is_array in the previous assert. That will make the cast to typeArrayOop safe. > > -- John From john.r.rose at oracle.com Fri Jul 1 14:08:52 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 1 Jul 2011 14:08:52 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E0E358E.7010900@Oracle.COM> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> <4E0E358E.7010900@Oracle.COM> Message-ID: On Jul 1, 2011, at 2:01 PM, Peter B. Kessler wrote: > I don't know the opto/runtime style, but there sure seems to be a lot of copying of the array dimensions. Could you make up the jint array early and just pass that around, or do you need the Node array of intcon's. (E.g., do you need them for the type mechanisms?) This is more a question for my understanding than a comment on your code. That was the first thought, but C2 is not cooperative about allocating arrays in the stack frame. It wants to treat the stack frame as a sea of virtual registers. The workaround for that limitation is to use Java varargs instead of C varargs. Yes, that requires extra copying, but it is a trivial amount of copying compared to the size of almost any rank-6 array you can imagine creating. At least some of the lower-rank cases (2..5) cover the case of a small low-rank array, for which the allocation of a Java dope vector would be a significant overhead. Good catch about the rank-1 case. That should still be a ShouldNotReachHere. -- John From vladimir.kozlov at oracle.com Fri Jul 1 14:09:04 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 01 Jul 2011 14:09:04 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E0E358E.7010900@Oracle.COM> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> <4E0E358E.7010900@Oracle.COM> Message-ID: <4E0E3770.1040409@oracle.com> Peter B. Kessler wrote: > In src/share/vm/opto/parse3.cpp:478, you took out the default for the > switch, which used to catch the case where ndimensions==1 and call > ShouldNotReachHere(). Now, if ndimension==1 you will go to the new > OptoRuntime::multianewarrayN_* methods. I think that will work (but I > haven't checked carefully), but I wonder if that's what you intended, or > if we shouldn't send that case to new_array, or call ShouldNotReachHere > because something really is wrong in that case? The code at line 448 process ndimensions==1 arrays. > > I understand the principle of least change, especially at this point a > release, but do we really still need the special cases for arrays of 2, > 3, 4, and 5 dimensions? Should there be another bug to clean those up > later. They are extra code to maintain. New code allocate new java array so it is slower and can trigger other events (more GC collections) than previous code so we decided to keep it. Vladimir > > I don't know the opto/runtime style, but there sure seems to be a lot of > copying of the array dimensions. Could you make up the jint array early > and just pass that around, or do you need the Node array of intcon's. > (E.g., do you need them for the type mechanisms?) This is more a > question for my understanding than a comment on your code. > > ... peter > > On 20110701 12:55 PM, Igor Veresov wrote: >> Following the advise of John Rose I made arguments transfer via java >> array for arrays with > 5 dimensions. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.02/ >> >> igor >> >> >> On 6/27/11 2:47 PM, Igor Veresov wrote: >>> Thanks for the review, Tom! >>> I'll try to implement the vararg calls. >>> >>> igor >>> >>> On 6/27/11 1:41 PM, Tom Rodriguez wrote: >>>> Is there any easy way to just make C2 support a varargs style call for >>>> multianewarray? C1 just does a funny calling convention where it >>>> passes a pointer a stack allocated array which is obviously possible >>>> with C2 though we don't have anything like it right now. I can see how >>>> to do this by cons'ing up type signatures as need with extra count and >>>> pointer arguments and then modifying the c_calling_convention to >>>> switch to the stack only calling convention after the first two. The >>>> only extra trick would be getting the address of the stack arguments >>>> into the call when it's converted into a MachCall. We don't really >>>> have a way to express that using MachNodes since stack slots are >>>> virtual are that point. Maybe it could simply be handled at the ad >>>> file level. >>>> >>>> So something like a new MachCallRuntimeVarargsNode with an index >>>> indicating which argument is the last real one, the >>>> c_calling_convention modified to take an index indicating when it >>>> should force a switch to stack only, and the ins_encode for that match >>>> inserting the right address computation for the address. Is that too >>>> complex for the limited benefit? Maybe compared to the complexity of >>>> the existing machinery, it's not too bad. >>>> >>>> As far as your webrev, I don't think you want to do this: >>>> >>>> + if (per_bc_reason == Reason_unhandled) { >>>> + make_not_compilable = true; >>>> + } >>>> >>>> There are other uses of Reason_unhandled and it's not clear the >>>> stopping compilation is the right action for those other cases. Maybe >>>> you need another action? Or maybe the actions need to be interpreted >>>> specially for Reason_unhandled. Doing a make_not_entrant doesn't seem >>>> like the right action for some of the other Reason_unhandleds. >>>> >>>> I do like the trap_state changes if it allows us to move >>>> Reason_loop_predicate and Reason_loop_limit_check into the per bci >>>> section. >>>> >>>> tom >>>> >>>> On Jun 27, 2011, at 12:07 PM, Igor Veresov wrote: >>>> >>>>> Problem: multinewarray with>= 6 dimensions is not supported by c2 and >>>>> is plugged with uncommon trap. When executed in the main code path >>>>> this yields performance far worse than even interpreter. >>>>> >>>>> Solution: Count these traps per bci and when the number exceeds >>>>> PerBytecodeTrapLimit make it not compilable. With tiered it would >>>>> result in recompilation at level 1 (pure C1), with regular scheme the >>>>> method will continue in the interpreter. >>>>> >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> igor >>>> >>> >> > From john.r.rose at oracle.com Fri Jul 1 14:16:01 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 1 Jul 2011 14:16:01 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E0E3770.1040409@oracle.com> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> <4E0E358E.7010900@Oracle.COM> <4E0E3770.1040409@oracle.com> Message-ID: <962C2BA2-EB41-4378-BEFD-F38B69419715@oracle.com> On Jul 1, 2011, at 2:09 PM, Vladimir Kozlov wrote: > The code at line 448 process ndimensions==1 arrays. (In parse3.cpp.) Yes, and that logic also handles small higher-dimensional arrays, like new int[1][1][1]. As an author of it, I find it a pleasantly bewildering bundle of tactics. -- John From tom.rodriguez at oracle.com Fri Jul 1 14:21:57 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 1 Jul 2011 14:21:57 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> <4E0E358E.7010900@Oracle.COM> Message-ID: <17F22BBA-90D1-4D87-8D24-D9DE7FEF23CD@oracle.com> On Jul 1, 2011, at 2:08 PM, John Rose wrote: > On Jul 1, 2011, at 2:01 PM, Peter B. Kessler wrote: > >> I don't know the opto/runtime style, but there sure seems to be a lot of copying of the array dimensions. Could you make up the jint array early and just pass that around, or do you need the Node array of intcon's. (E.g., do you need them for the type mechanisms?) This is more a question for my understanding than a comment on your code. > > That was the first thought, but C2 is not cooperative about allocating arrays in the stack frame. It wants to treat the stack frame as a sea of virtual registers. I don't think it would be hard to add a StackAllocateNode that allocated a contiguous chunk in the frame. I think we've had a wish for it before but it seemed like more work than we really wanted for something that's as rare as then 6+D arrays. tom > > The workaround for that limitation is to use Java varargs instead of C varargs. Yes, that requires extra copying, but it is a trivial amount of copying compared to the size of almost any rank-6 array you can imagine creating. > > At least some of the lower-rank cases (2..5) cover the case of a small low-rank array, for which the allocation of a Java dope vector would be a significant overhead. > > Good catch about the rank-1 case. That should still be a ShouldNotReachHere. > > -- John > From igor.veresov at oracle.com Fri Jul 1 14:43:08 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 01 Jul 2011 14:43:08 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E0E355D.3050502@oracle.com> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> <4E0E2D68.40706@oracle.com> <4E0E355D.3050502@oracle.com> Message-ID: <4E0E3F6C.4060108@oracle.com> John, Vladimir, Peter, Thank you for your comments. I've made the changes and tested with my microbenchmark and DeoptimizeALot. Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.03/ Thanks! igor On 7/1/11 2:00 PM, Vladimir Kozlov wrote: > John Rose wrote: >> On Jul 1, 2011, at 1:26 PM, Vladimir Kozlov wrote: >> >>> Wrap new java dimension allocation into PreserveReexecuteState scope >>> and restore stack. >> >> Is this in case the initial allocation deoptimizes (due to some >> external event)? I suppose that should be tested with DeoptimizeALot. > > The allocation of dimension array may go slow path (no space left in > TLAB) into runtime and on return the method could be deoptimized so we > need restore stack so that interpreter can reexecute multinewarray > allocation. There are several places where we do this already (for > example, around the call to expand_multianewarray()). > > And yes, it should be tested with DeoptimizeALot. > > Vladimir > >> >> Igor, the extraction from the dope array bothers me: >> + jint *j_dims = (jint*)dims->base(T_INT); >> + jint *c_dims = NEW_RESOURCE_ARRAY(jint, len); >> + memcpy(c_dims, j_dims, sizeof(jint)*len); >> >> It is correct, but I'd rather see more use of Hotspot machinery, with >> stronger typing: >> + jint *j_dims = typeArrayOop(dims)->int_at_addr(0); >> + jint *c_dims = NEW_RESOURCE_ARRAY(jint, len); >> + Copy::conjoint_jints_atomic(c_dims, j_dims, sizeof(jint)*len); >> >> Note that Copy::* strongly outnumbers memcpy in the opto directory. >> The distinction is mostly stylistic, but Copy:: is more strongly typed >> in this case. >> >> (In other uses, Copy:: is more explicit and careful about some of the >> things we need to care about, such as overlaps and word-tearing.) >> >> Also, use is_typeArray instead of is_array in the previous assert. >> That will make the cast to typeArrayOop safe. >> >> -- John From vladimir.kozlov at oracle.com Fri Jul 1 14:48:37 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 01 Jul 2011 14:48:37 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E0E3F6C.4060108@oracle.com> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> <4E0E2D68.40706@oracle.com> <4E0E355D.3050502@oracle.com> <4E0E3F6C.4060108@oracle.com> Message-ID: <4E0E40B5.90209@oracle.com> Looks good. Thanks, Vladimir Igor Veresov wrote: > John, Vladimir, Peter, > > Thank you for your comments. > I've made the changes and tested with my microbenchmark and DeoptimizeALot. > > Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.03/ > > Thanks! > igor > > On 7/1/11 2:00 PM, Vladimir Kozlov wrote: >> John Rose wrote: >>> On Jul 1, 2011, at 1:26 PM, Vladimir Kozlov wrote: >>> >>>> Wrap new java dimension allocation into PreserveReexecuteState scope >>>> and restore stack. >>> >>> Is this in case the initial allocation deoptimizes (due to some >>> external event)? I suppose that should be tested with DeoptimizeALot. >> >> The allocation of dimension array may go slow path (no space left in >> TLAB) into runtime and on return the method could be deoptimized so we >> need restore stack so that interpreter can reexecute multinewarray >> allocation. There are several places where we do this already (for >> example, around the call to expand_multianewarray()). >> >> And yes, it should be tested with DeoptimizeALot. >> >> Vladimir >> >>> >>> Igor, the extraction from the dope array bothers me: >>> + jint *j_dims = (jint*)dims->base(T_INT); >>> + jint *c_dims = NEW_RESOURCE_ARRAY(jint, len); >>> + memcpy(c_dims, j_dims, sizeof(jint)*len); >>> >>> It is correct, but I'd rather see more use of Hotspot machinery, with >>> stronger typing: >>> + jint *j_dims = typeArrayOop(dims)->int_at_addr(0); >>> + jint *c_dims = NEW_RESOURCE_ARRAY(jint, len); >>> + Copy::conjoint_jints_atomic(c_dims, j_dims, sizeof(jint)*len); >>> >>> Note that Copy::* strongly outnumbers memcpy in the opto directory. >>> The distinction is mostly stylistic, but Copy:: is more strongly typed >>> in this case. >>> >>> (In other uses, Copy:: is more explicit and careful about some of the >>> things we need to care about, such as overlaps and word-tearing.) >>> >>> Also, use is_typeArray instead of is_array in the previous assert. >>> That will make the cast to typeArrayOop safe. >>> >>> -- John > From john.r.rose at oracle.com Fri Jul 1 14:54:35 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 1 Jul 2011 14:54:35 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E0E40B5.90209@oracle.com> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> <4E0E2D68.40706@oracle.com> <4E0E355D.3050502@oracle.com> <4E0E3F6C.4060108@oracle.com> <4E0E40B5.90209@oracle.com> Message-ID: <42760652-73F1-4C2E-986B-17AE9169271D@oracle.com> On Jul 1, 2011, at 2:48 PM, Vladimir Kozlov wrote: > Looks good. I agree. Thanks for fixing this. -- John From tom.rodriguez at oracle.com Fri Jul 1 15:42:36 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 1 Jul 2011 15:42:36 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E0E3F6C.4060108@oracle.com> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> <4E0E2D68.40706@oracle.com> <4E0E355D.3050502@oracle.com> <4E0E3F6C.4060108@oracle.com> Message-ID: <3D628A67-9203-4D32-B987-57DAD6B90DC9@oracle.com> That looks good. tom On Jul 1, 2011, at 2:43 PM, Igor Veresov wrote: > John, Vladimir, Peter, > > Thank you for your comments. > I've made the changes and tested with my microbenchmark and DeoptimizeALot. > > Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.03/ > > Thanks! > igor > > On 7/1/11 2:00 PM, Vladimir Kozlov wrote: >> John Rose wrote: >>> On Jul 1, 2011, at 1:26 PM, Vladimir Kozlov wrote: >>> >>>> Wrap new java dimension allocation into PreserveReexecuteState scope >>>> and restore stack. >>> >>> Is this in case the initial allocation deoptimizes (due to some >>> external event)? I suppose that should be tested with DeoptimizeALot. >> >> The allocation of dimension array may go slow path (no space left in >> TLAB) into runtime and on return the method could be deoptimized so we >> need restore stack so that interpreter can reexecute multinewarray >> allocation. There are several places where we do this already (for >> example, around the call to expand_multianewarray()). >> >> And yes, it should be tested with DeoptimizeALot. >> >> Vladimir >> >>> >>> Igor, the extraction from the dope array bothers me: >>> + jint *j_dims = (jint*)dims->base(T_INT); >>> + jint *c_dims = NEW_RESOURCE_ARRAY(jint, len); >>> + memcpy(c_dims, j_dims, sizeof(jint)*len); >>> >>> It is correct, but I'd rather see more use of Hotspot machinery, with >>> stronger typing: >>> + jint *j_dims = typeArrayOop(dims)->int_at_addr(0); >>> + jint *c_dims = NEW_RESOURCE_ARRAY(jint, len); >>> + Copy::conjoint_jints_atomic(c_dims, j_dims, sizeof(jint)*len); >>> >>> Note that Copy::* strongly outnumbers memcpy in the opto directory. >>> The distinction is mostly stylistic, but Copy:: is more strongly typed >>> in this case. >>> >>> (In other uses, Copy:: is more explicit and careful about some of the >>> things we need to care about, such as overlaps and word-tearing.) >>> >>> Also, use is_typeArray instead of is_array in the previous assert. >>> That will make the cast to typeArrayOop safe. >>> >>> -- John > From Peter.B.Kessler at Oracle.COM Fri Jul 1 16:30:31 2011 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Fri, 01 Jul 2011 16:30:31 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <4E0E3F6C.4060108@oracle.com> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> <4E0E2D68.40706@oracle.com> <4E0E355D.3050502@oracle.com> <4E0E3F6C.4060108@oracle.com> Message-ID: <4E0E5897.7010706@Oracle.COM> Looks good to me. ... peter On 20110701 2:43 PM, Igor Veresov wrote: > John, Vladimir, Peter, > > Thank you for your comments. > I've made the changes and tested with my microbenchmark and DeoptimizeALot. > > Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.03/ > > Thanks! > igor > > On 7/1/11 2:00 PM, Vladimir Kozlov wrote: >> John Rose wrote: >>> On Jul 1, 2011, at 1:26 PM, Vladimir Kozlov wrote: >>> >>>> Wrap new java dimension allocation into PreserveReexecuteState scope >>>> and restore stack. >>> >>> Is this in case the initial allocation deoptimizes (due to some >>> external event)? I suppose that should be tested with DeoptimizeALot. >> >> The allocation of dimension array may go slow path (no space left in >> TLAB) into runtime and on return the method could be deoptimized so we >> need restore stack so that interpreter can reexecute multinewarray >> allocation. There are several places where we do this already (for >> example, around the call to expand_multianewarray()). >> >> And yes, it should be tested with DeoptimizeALot. >> >> Vladimir >> >>> >>> Igor, the extraction from the dope array bothers me: >>> + jint *j_dims = (jint*)dims->base(T_INT); >>> + jint *c_dims = NEW_RESOURCE_ARRAY(jint, len); >>> + memcpy(c_dims, j_dims, sizeof(jint)*len); >>> >>> It is correct, but I'd rather see more use of Hotspot machinery, with >>> stronger typing: >>> + jint *j_dims = typeArrayOop(dims)->int_at_addr(0); >>> + jint *c_dims = NEW_RESOURCE_ARRAY(jint, len); >>> + Copy::conjoint_jints_atomic(c_dims, j_dims, sizeof(jint)*len); >>> >>> Note that Copy::* strongly outnumbers memcpy in the opto directory. >>> The distinction is mostly stylistic, but Copy:: is more strongly typed >>> in this case. >>> >>> (In other uses, Copy:: is more explicit and careful about some of the >>> things we need to care about, such as overlaps and word-tearing.) >>> >>> Also, use is_typeArray instead of is_array in the previous assert. >>> That will make the cast to typeArrayOop safe. >>> >>> -- John > From igor.veresov at oracle.com Fri Jul 1 23:02:44 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 01 Jul 2011 23:02:44 -0700 Subject: review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler In-Reply-To: <42760652-73F1-4C2E-986B-17AE9169271D@oracle.com> References: <4E08D4FA.9070004@oracle.com> <7526C6BD-9DFC-4C46-B7E0-11D163CA2B11@oracle.com> <4E08FA79.3040608@oracle.com> <4E0E263B.4060705@oracle.com> <4E0E2D68.40706@oracle.com> <4E0E355D.3050502@oracle.com> <4E0E3F6C.4060108@oracle.com> <4E0E40B5.90209@oracle.com> <42760652-73F1-4C2E-986B-17AE9169271D@oracle.com> Message-ID: <4E0EB484.9020802@oracle.com> Tom, Vladimir, John and Peter, Thanks for the reviews! igor On 7/1/11 2:54 PM, John Rose wrote: > On Jul 1, 2011, at 2:48 PM, Vladimir Kozlov wrote: > >> Looks good. > > I agree. Thanks for fixing this. -- John From tom.rodriguez at oracle.com Tue Jul 5 13:46:51 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 5 Jul 2011 13:46:51 -0700 Subject: review for 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes Message-ID: <3D4AD60E-613E-40FD-99F3-5322D2343BC5@oracle.com> http://cr.openjdk.java.net/~never/7062856 29 lines changed: 27 ins; 0 del; 2 mod; 487 unchg 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes Summary: do explicit lookup emulating old LD_LIBRARY_PATH search Reviewed-by: Changes to launcher in the JDK7 removed the default setting of LD_LIBRARY_PATH which was being used to find the disassembler. I added explicit logic to perform a lookup equivalent to the previous behaviour. Tested with truss to confirm search paths and PrintNMethods. I also fixed an annoyance where every separate invocation of the disassembler emitted the "Disassembling ..." message so that it would only print it again if it changed. From vladimir.kozlov at oracle.com Tue Jul 5 15:01:33 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Jul 2011 15:01:33 -0700 (PDT) Subject: review for 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes In-Reply-To: <3D4AD60E-613E-40FD-99F3-5322D2343BC5@oracle.com> References: <3D4AD60E-613E-40FD-99F3-5322D2343BC5@oracle.com> Message-ID: <4E1389BD.2050906@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7062856 > 29 lines changed: 27 ins; 0 del; 2 mod; 487 unchg > > 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes > Summary: do explicit lookup emulating old LD_LIBRARY_PATH search > Reviewed-by: > > Changes to launcher in the JDK7 removed the default setting of > LD_LIBRARY_PATH which was being used to find the disassembler. I > added explicit logic to perform a lookup equivalent to the previous > behaviour. Tested with truss to confirm search paths and > PrintNMethods. > > I also fixed an annoyance where every separate invocation of the > disassembler emitted the "Disassembling ..." message so that it would > only print it again if it changed. > From john.r.rose at oracle.com Tue Jul 5 15:15:28 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 5 Jul 2011 15:15:28 -0700 Subject: review for 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes In-Reply-To: <4E1389BD.2050906@oracle.com> References: <3D4AD60E-613E-40FD-99F3-5322D2343BC5@oracle.com> <4E1389BD.2050906@oracle.com> Message-ID: <8A3362CD-82B5-43A7-8A00-12D3D5438673@oracle.com> Good. Thanks for fixing that. Instead of the comment "First try libhsdis for compatibility" I suggest laying out the whole search path, something like the following. // Search for several paths derived from libjvm, in this order: // 1. /jre/lib///libhsdis.so // 2. /jre/lib///hsdis.so // 3. /jre/lib//hsdis.so // 4. hsdis.so (no path) -- John On Jul 5, 2011, at 3:01 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7062856 >> 29 lines changed: 27 ins; 0 del; 2 mod; 487 unchg >> >> 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes >> Summary: do explicit lookup emulating old LD_LIBRARY_PATH search -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110705/f89e7a71/attachment.html From tom.rodriguez at oracle.com Tue Jul 5 15:36:05 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 5 Jul 2011 15:36:05 -0700 Subject: review for 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes In-Reply-To: <8A3362CD-82B5-43A7-8A00-12D3D5438673@oracle.com> References: <3D4AD60E-613E-40FD-99F3-5322D2343BC5@oracle.com> <4E1389BD.2050906@oracle.com> <8A3362CD-82B5-43A7-8A00-12D3D5438673@oracle.com> Message-ID: Yes that's better. I changed it slightly and copied the different step comments to the appropriate places. It's slightly verbose but very explicit. tom diff -r de6a837d75cf src/share/vm/compiler/disassembler.cpp --- a/src/share/vm/compiler/disassembler.cpp +++ b/src/share/vm/compiler/disassembler.cpp @@ -78,21 +78,46 @@ char buf[JVM_MAXPATHLEN]; os::jvm_path(buf, sizeof(buf)); int jvm_offset = -1; + int lib_offset = -1; { // Match "jvm[^/]*" in jvm_path. const char* base = buf; const char* p = strrchr(buf, '/'); + if (p != NULL) lib_offset = p - base + 1; p = strstr(p ? p : base, "jvm"); if (p != NULL) jvm_offset = p - base; } + // Find the disassembler shared library. + // Search for several paths derived from libjvm, in this order: + // 1. /jre/lib///libhsdis-.so (for compatibility) + // 2. /jre/lib///hsdis-.so + // 3. /jre/lib//hsdis-.so + // 4. hsdis-.so (using LD_LIBRARY_PATH) if (jvm_offset >= 0) { - // Find the disassembler next to libjvm.so. + // 1. /jre/lib///libhsdis-.so strcpy(&buf[jvm_offset], hsdis_library_name); strcat(&buf[jvm_offset], os::dll_file_extension()); _library = os::dll_load(buf, ebuf, sizeof ebuf); + if (_library == NULL) { + // 2. /jre/lib///hsdis-.so + strcpy(&buf[lib_offset], hsdis_library_name); + strcat(&buf[lib_offset], os::dll_file_extension()); + _library = os::dll_load(buf, ebuf, sizeof ebuf); + } + if (_library == NULL) { + // 3. /jre/lib//hsdis-.so + buf[lib_offset - 1] = '\0'; + const char* p = strrchr(buf, '/'); + if (p != NULL) { + lib_offset = p - buf + 1; + strcpy(&buf[lib_offset], hsdis_library_name); + strcat(&buf[lib_offset], os::dll_file_extension()); + _library = os::dll_load(buf, ebuf, sizeof ebuf); + } + } } if (_library == NULL) { - // Try a free-floating lookup. + // 4. hsdis-.so (using LD_LIBRARY_PATH) strcpy(&buf[0], hsdis_library_name); strcat(&buf[0], os::dll_file_extension()); _library = os::dll_load(buf, ebuf, sizeof ebuf); tom On Jul 5, 2011, at 3:15 PM, John Rose wrote: > Good. Thanks for fixing that. > > Instead of the comment "First try libhsdis for compatibility" I suggest laying out the whole search path, something like the following. > > // Search for several paths derived from libjvm, in this order: > // 1. /jre/lib///libhsdis.so > // 2. /jre/lib///hsdis.so > // 3. /jre/lib//hsdis.so > // 4. hsdis.so (no path) > > -- John > > On Jul 5, 2011, at 3:01 PM, Vladimir Kozlov wrote: > >> Looks good. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7062856 >>> 29 lines changed: 27 ins; 0 del; 2 mod; 487 unchg >>> >>> 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes >>> Summary: do explicit lookup emulating old LD_LIBRARY_PATH search > From john.r.rose at oracle.com Tue Jul 5 15:41:57 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 05 Jul 2011 22:41:57 +0000 Subject: hg: hsx/hotspot-comp/jdk: 7054590: (JSR-292) MethodHandleProxies.asInterfaceInstance() accepts private/protected nested interfaces Message-ID: <20110705224250.169EC471DE@hg.openjdk.java.net> Changeset: 6444b0a364d7 Author: jrose Date: 2011-06-14 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6444b0a364d7 7054590: (JSR-292) MethodHandleProxies.asInterfaceInstance() accepts private/protected nested interfaces Summary: fix non-compliant logic in MethodHandleProxies, fix invalid private classes in MethodHandlesTest Reviewed-by: twisti, never ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! test/java/lang/invoke/MethodHandlesTest.java From vladimir.kozlov at oracle.com Tue Jul 5 15:43:32 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Jul 2011 15:43:32 -0700 Subject: review for 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes In-Reply-To: References: <3D4AD60E-613E-40FD-99F3-5322D2343BC5@oracle.com> <4E1389BD.2050906@oracle.com> <8A3362CD-82B5-43A7-8A00-12D3D5438673@oracle.com> Message-ID: <4E139394.2070807@oracle.com> Good. Vladimir Tom Rodriguez wrote: > Yes that's better. I changed it slightly and copied the different step comments to the appropriate places. It's slightly verbose but very explicit. > > tom > > diff -r de6a837d75cf src/share/vm/compiler/disassembler.cpp > --- a/src/share/vm/compiler/disassembler.cpp > +++ b/src/share/vm/compiler/disassembler.cpp > @@ -78,21 +78,46 @@ > char buf[JVM_MAXPATHLEN]; > os::jvm_path(buf, sizeof(buf)); > int jvm_offset = -1; > + int lib_offset = -1; > { > // Match "jvm[^/]*" in jvm_path. > const char* base = buf; > const char* p = strrchr(buf, '/'); > + if (p != NULL) lib_offset = p - base + 1; > p = strstr(p ? p : base, "jvm"); > if (p != NULL) jvm_offset = p - base; > } > + // Find the disassembler shared library. > + // Search for several paths derived from libjvm, in this order: > + // 1. /jre/lib///libhsdis-.so (for compatibility) > + // 2. /jre/lib///hsdis-.so > + // 3. /jre/lib//hsdis-.so > + // 4. hsdis-.so (using LD_LIBRARY_PATH) > if (jvm_offset >= 0) { > - // Find the disassembler next to libjvm.so. > + // 1. /jre/lib///libhsdis-.so > strcpy(&buf[jvm_offset], hsdis_library_name); > strcat(&buf[jvm_offset], os::dll_file_extension()); > _library = os::dll_load(buf, ebuf, sizeof ebuf); > + if (_library == NULL) { > + // 2. /jre/lib///hsdis-.so > + strcpy(&buf[lib_offset], hsdis_library_name); > + strcat(&buf[lib_offset], os::dll_file_extension()); > + _library = os::dll_load(buf, ebuf, sizeof ebuf); > + } > + if (_library == NULL) { > + // 3. /jre/lib//hsdis-.so > + buf[lib_offset - 1] = '\0'; > + const char* p = strrchr(buf, '/'); > + if (p != NULL) { > + lib_offset = p - buf + 1; > + strcpy(&buf[lib_offset], hsdis_library_name); > + strcat(&buf[lib_offset], os::dll_file_extension()); > + _library = os::dll_load(buf, ebuf, sizeof ebuf); > + } > + } > } > if (_library == NULL) { > - // Try a free-floating lookup. > + // 4. hsdis-.so (using LD_LIBRARY_PATH) > strcpy(&buf[0], hsdis_library_name); > strcat(&buf[0], os::dll_file_extension()); > _library = os::dll_load(buf, ebuf, sizeof ebuf); > tom > > On Jul 5, 2011, at 3:15 PM, John Rose wrote: > >> Good. Thanks for fixing that. >> >> Instead of the comment "First try libhsdis for compatibility" I suggest laying out the whole search path, something like the following. >> >> // Search for several paths derived from libjvm, in this order: >> // 1. /jre/lib///libhsdis.so >> // 2. /jre/lib///hsdis.so >> // 3. /jre/lib//hsdis.so >> // 4. hsdis.so (no path) >> >> -- John >> >> On Jul 5, 2011, at 3:01 PM, Vladimir Kozlov wrote: >> >>> Looks good. >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7062856 >>>> 29 lines changed: 27 ins; 0 del; 2 mod; 487 unchg >>>> >>>> 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes >>>> Summary: do explicit lookup emulating old LD_LIBRARY_PATH search > From john.r.rose at oracle.com Tue Jul 5 15:45:19 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 5 Jul 2011 15:45:19 -0700 Subject: review for 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes In-Reply-To: References: <3D4AD60E-613E-40FD-99F3-5322D2343BC5@oracle.com> <4E1389BD.2050906@oracle.com> <8A3362CD-82B5-43A7-8A00-12D3D5438673@oracle.com> Message-ID: I like it. -- John On Jul 5, 2011, at 3:36 PM, Tom Rodriguez wrote: > Yes that's better. I changed it slightly and copied the different step comments to the appropriate places. It's slightly verbose but very explicit. From tom.rodriguez at oracle.com Tue Jul 5 15:50:12 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 5 Jul 2011 15:50:12 -0700 Subject: review for 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes In-Reply-To: References: <3D4AD60E-613E-40FD-99F3-5322D2343BC5@oracle.com> <4E1389BD.2050906@oracle.com> <8A3362CD-82B5-43A7-8A00-12D3D5438673@oracle.com> Message-ID: <5FDF21D9-5474-4761-96FC-CE2ED8D8AFC2@oracle.com> Thanks John and Vladimir. tom On Jul 5, 2011, at 3:45 PM, John Rose wrote: > I like it. -- John > > On Jul 5, 2011, at 3:36 PM, Tom Rodriguez wrote: > >> Yes that's better. I changed it slightly and copied the different step comments to the appropriate places. It's slightly verbose but very explicit. > From john.r.rose at oracle.com Tue Jul 5 17:01:17 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 5 Jul 2011 17:01:17 -0700 Subject: review request (M): 6983728: JSR 292 remove argument count limitations In-Reply-To: <557B6AB7-51FD-468B-808B-370F54013E71@oracle.com> References: <557B6AB7-51FD-468B-808B-370F54013E71@oracle.com> Message-ID: <017BF07C-4E49-4FD5-A64D-67A2602D2C23@oracle.com> This is a follow-up to a pre-review in May. http://cr.openjdk.java.net/~jrose/6983728/webrev.01/ Diffs since May are trivial: http://cr.openjdk.java.net/~jrose/6983728/01-after-00.diff This is for after JDK 7. -- John On May 17, 2011, at 5:07 AM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/6983728/webrev.00/ > > 6983728: JSR 292 remove argument count limitations > Summary: Remove workarounds and limitations from before 6939861. > Reviewed-by: ? > > Remove test exclusions from MethodHandlesTest (key unit test), and extend argument counts of test cases. > > Remove the following files, which were workarounds for the lack of ricochet frames: > FilterGeneric.java FilterOneArgument.java FromGeneric.java SpreadGeneric.java ToGeneric.java > > Note: These changes assume a full port of 6939861. This is true of x86 at present; SPARC is following. This change will not be done until after SPARC stabilizes. From tom.rodriguez at oracle.com Tue Jul 5 17:09:39 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 5 Jul 2011 17:09:39 -0700 Subject: review request (M): 6983728: JSR 292 remove argument count limitations In-Reply-To: <017BF07C-4E49-4FD5-A64D-67A2602D2C23@oracle.com> References: <557B6AB7-51FD-468B-808B-370F54013E71@oracle.com> <017BF07C-4E49-4FD5-A64D-67A2602D2C23@oracle.com> Message-ID: <58BD01EB-8C00-4F34-A59C-42415B812338@oracle.com> Still looks good. tom On Jul 5, 2011, at 5:01 PM, John Rose wrote: > This is a follow-up to a pre-review in May. > http://cr.openjdk.java.net/~jrose/6983728/webrev.01/ > > Diffs since May are trivial: > http://cr.openjdk.java.net/~jrose/6983728/01-after-00.diff > > This is for after JDK 7. > > -- John > > On May 17, 2011, at 5:07 AM, John Rose wrote: > >> http://cr.openjdk.java.net/~jrose/6983728/webrev.00/ >> >> 6983728: JSR 292 remove argument count limitations >> Summary: Remove workarounds and limitations from before 6939861. >> Reviewed-by: ? >> >> Remove test exclusions from MethodHandlesTest (key unit test), and extend argument counts of test cases. >> >> Remove the following files, which were workarounds for the lack of ricochet frames: >> FilterGeneric.java FilterOneArgument.java FromGeneric.java SpreadGeneric.java ToGeneric.java >> >> Note: These changes assume a full port of 6939861. This is true of x86 at present; SPARC is following. This change will not be done until after SPARC stabilizes. > From john.r.rose at oracle.com Tue Jul 5 17:24:30 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 5 Jul 2011 17:24:30 -0700 Subject: review request (M): 6983728: JSR 292 remove argument count limitations In-Reply-To: <58BD01EB-8C00-4F34-A59C-42415B812338@oracle.com> References: <557B6AB7-51FD-468B-808B-370F54013E71@oracle.com> <017BF07C-4E49-4FD5-A64D-67A2602D2C23@oracle.com> <58BD01EB-8C00-4F34-A59C-42415B812338@oracle.com> Message-ID: <0371BA5B-1FE4-416F-8ABD-01AD0D223C00@oracle.com> Thanks, Tom. -- John (on my iPhone) On Jul 5, 2011, at 5:09 PM, Tom Rodriguez wrote: > Still looks good. > > tom > > On Jul 5, 2011, at 5:01 PM, John Rose wrote: > >> This is a follow-up to a pre-review in May. >> http://cr.openjdk.java.net/~jrose/6983728/webrev.01/ >> >> Diffs since May are trivial: >> http://cr.openjdk.java.net/~jrose/6983728/01-after-00.diff >> >> This is for after JDK 7. >> >> -- John >> >> On May 17, 2011, at 5:07 AM, John Rose wrote: >> >>> http://cr.openjdk.java.net/~jrose/6983728/webrev.00/ >>> >>> 6983728: JSR 292 remove argument count limitations >>> Summary: Remove workarounds and limitations from before 6939861. >>> Reviewed-by: ? >>> >>> Remove test exclusions from MethodHandlesTest (key unit test), and extend argument counts of test cases. >>> >>> Remove the following files, which were workarounds for the lack of ricochet frames: >>> FilterGeneric.java FilterOneArgument.java FromGeneric.java SpreadGeneric.java ToGeneric.java >>> >>> Note: These changes assume a full port of 6939861. This is true of x86 at present; SPARC is following. This change will not be done until after SPARC stabilizes. >> > From tom.rodriguez at oracle.com Tue Jul 5 20:40:38 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 06 Jul 2011 03:40:38 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 6478991: C1 NullCheckEliminator yields incorrect exceptions Message-ID: <20110706034044.08F25471EB@hg.openjdk.java.net> Changeset: 15559220ce79 Author: never Date: 2011-07-05 16:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/15559220ce79 6478991: C1 NullCheckEliminator yields incorrect exceptions Reviewed-by: twisti, iveresov ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/6478991/NullCheckTest.java From christian.thalinger at oracle.com Wed Jul 6 01:23:58 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 6 Jul 2011 10:23:58 +0200 Subject: review request (M): 6983728: JSR 292 remove argument count limitations In-Reply-To: <017BF07C-4E49-4FD5-A64D-67A2602D2C23@oracle.com> References: <557B6AB7-51FD-468B-808B-370F54013E71@oracle.com> <017BF07C-4E49-4FD5-A64D-67A2602D2C23@oracle.com> Message-ID: <62B39321-1432-4B59-92D0-F8F71191B68F@oracle.com> On Jul 6, 2011, at 2:01 AM, John Rose wrote: > This is a follow-up to a pre-review in May. > http://cr.openjdk.java.net/~jrose/6983728/webrev.01/ > > Diffs since May are trivial: > http://cr.openjdk.java.net/~jrose/6983728/01-after-00.diff > > This is for after JDK 7. Looks good. -- Christian From jantz.michael at gmail.com Wed Jul 6 13:49:10 2011 From: jantz.michael at gmail.com (Michael Jantz) Date: Wed, 6 Jul 2011 15:49:10 -0500 Subject: Help understanding server compiler's register allocator Message-ID: Hello, I'm a student researcher and I'd like to use the Hotspot server compiler for a project I'm working on this summer. I'm having some trouble understanding exactly how the register allocation algorithm is working. Specifically, I'd like to know more about the MachSpillCopy nodes. It looks like these are introduced by the Split routine to split register live ranges in order to reduce register pressure and to eventually allow a complete coloring of the register live range interference graph. My first question is: Is this always correct? Do these nodes have any other purpose? Also, do these nodes correspond directly to copy instructions (i.e. register to register moves) in the final generated code? Finally, are there any other materials for helping me to understand the intermediate representations used in this compiler? Thanks, Michael Jantz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110706/f5c75576/attachment.html From tom.rodriguez at oracle.com Wed Jul 6 15:06:26 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 06 Jul 2011 22:06:26 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7061101: adlc should complain about mixing block and expression forms of ins_encode Message-ID: <20110706220633.57FAC47220@hg.openjdk.java.net> Changeset: fe240d87c6ec Author: never Date: 2011-07-06 09:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fe240d87c6ec 7061101: adlc should complain about mixing block and expression forms of ins_encode Reviewed-by: kvn ! src/share/vm/adlc/adlparse.cpp From vladimir.kozlov at oracle.com Wed Jul 6 16:04:42 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Jul 2011 16:04:42 -0700 Subject: Request for reviews (M): 7059034: Use movxtod/movdtox on T4 Message-ID: <4E14EA0A.8080802@oracle.com> http://cr.openjdk.java.net/~kvn/7059034/webrev Fixed 7059034: Use movxtod/movdtox on T4 Currently VM uses stack to move data between general and float registers on Sparc. Use new VIS3 mov instructions on T4 for such moves. I removed R_F30,R_F31 from dflt_low_reg since they used as temps (see line 412). Also fixed float<->integer conversion instructions since they used incorrect Width for float register encoding. For example, encoding failed for next instr ftoi(FloatRegisterImpl::D,F4,F1) and fitof(FloatRegisterImpl::D,F1,F8). Tested with CTW, nsk. I attached microbenchmark test to the bug report. From christian.thalinger at oracle.com Thu Jul 7 03:24:43 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 7 Jul 2011 12:24:43 +0200 Subject: Request for reviews (M): 7059034: Use movxtod/movdtox on T4 In-Reply-To: <4E14EA0A.8080802@oracle.com> References: <4E14EA0A.8080802@oracle.com> Message-ID: On Jul 7, 2011, at 1:04 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7059034/webrev > > Fixed 7059034: Use movxtod/movdtox on T4 > > Currently VM uses stack to move data between general and float registers on Sparc. Use new VIS3 mov instructions on T4 for such moves. > > I removed R_F30,R_F31 from dflt_low_reg since they used as temps (see line 412). > Also fixed float<->integer conversion instructions since they used incorrect Width for float register encoding. For example, encoding failed for next instr ftoi(FloatRegisterImpl::D,F4,F1) and fitof(FloatRegisterImpl::D,F1,F8). > > Tested with CTW, nsk. > I attached microbenchmark test to the bug report. I see you did some spaces cleanup in sparc.ad. Could you also do that with the new code you add to src/cpu/sparc/vm/vm_version_sparc.cpp? E.g. if( x ) => if (x) and UseVIS=x => UseVIS = x. Otherwise this looks good. -- Christian From tom.rodriguez at oracle.com Thu Jul 7 03:45:09 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 07 Jul 2011 10:45:09 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes Message-ID: <20110707104516.1BDDB4724A@hg.openjdk.java.net> Changeset: 3e23978ea0c3 Author: never Date: 2011-07-06 18:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3e23978ea0c3 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes Summary: do explicit lookup emulating old LD_LIBRARY_PATH search Reviewed-by: kvn, jrose ! src/share/tools/hsdis/README ! src/share/vm/compiler/disassembler.cpp From vladimir.kozlov at oracle.com Thu Jul 7 09:01:37 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Jul 2011 09:01:37 -0700 Subject: Request for reviews (M): 7059034: Use movxtod/movdtox on T4 In-Reply-To: References: <4E14EA0A.8080802@oracle.com> Message-ID: <4E15D861.1080109@oracle.com> Thank you, Christian Yes, I will definitely fix it. thanks, Vladimir On 7/7/11 3:24 AM, Christian Thalinger wrote: > On Jul 7, 2011, at 1:04 AM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/7059034/webrev >> >> Fixed 7059034: Use movxtod/movdtox on T4 >> >> Currently VM uses stack to move data between general and float registers on Sparc. Use new VIS3 mov instructions on T4 for such moves. >> >> I removed R_F30,R_F31 from dflt_low_reg since they used as temps (see line 412). >> Also fixed float<->integer conversion instructions since they used incorrect Width for float register encoding. For example, encoding failed for next instr ftoi(FloatRegisterImpl::D,F4,F1) and fitof(FloatRegisterImpl::D,F1,F8). >> >> Tested with CTW, nsk. >> I attached microbenchmark test to the bug report. > > I see you did some spaces cleanup in sparc.ad. Could you also do that with the new code you add to src/cpu/sparc/vm/vm_version_sparc.cpp? E.g. if( x ) => if (x) and UseVIS=x => UseVIS = x. > > Otherwise this looks good. > > -- Christian From tom.rodriguez at oracle.com Thu Jul 7 09:22:27 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 7 Jul 2011 09:22:27 -0700 (PDT) Subject: Request for reviews (M): 7059034: Use movxtod/movdtox on T4 In-Reply-To: <4E14EA0A.8080802@oracle.com> References: <4E14EA0A.8080802@oracle.com> Message-ID: <7E88D62C-A1E6-4E8D-9B50-334B9748FBB9@oracle.com> These look good. tom On Jul 6, 2011, at 4:04 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7059034/webrev > > Fixed 7059034: Use movxtod/movdtox on T4 > > Currently VM uses stack to move data between general and float registers on Sparc. Use new VIS3 mov instructions on T4 for such moves. > > I removed R_F30,R_F31 from dflt_low_reg since they used as temps (see line 412). > Also fixed float<->integer conversion instructions since they used incorrect Width for float register encoding. For example, encoding failed for next instr ftoi(FloatRegisterImpl::D,F4,F1) and fitof(FloatRegisterImpl::D,F1,F8). > > Tested with CTW, nsk. > I attached microbenchmark test to the bug report. From vladimir.kozlov at oracle.com Thu Jul 7 09:37:18 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Jul 2011 09:37:18 -0700 Subject: Request for reviews (M): 7059034: Use movxtod/movdtox on T4 In-Reply-To: <7E88D62C-A1E6-4E8D-9B50-334B9748FBB9@oracle.com> References: <4E14EA0A.8080802@oracle.com> <7E88D62C-A1E6-4E8D-9B50-334B9748FBB9@oracle.com> Message-ID: <4E15E0BE.1030708@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > These look good. > > tom > > On Jul 6, 2011, at 4:04 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7059034/webrev >> >> Fixed 7059034: Use movxtod/movdtox on T4 >> >> Currently VM uses stack to move data between general and float registers on Sparc. Use new VIS3 mov instructions on T4 for such moves. >> >> I removed R_F30,R_F31 from dflt_low_reg since they used as temps (see line 412). >> Also fixed float<->integer conversion instructions since they used incorrect Width for float register encoding. For example, encoding failed for next instr ftoi(FloatRegisterImpl::D,F4,F1) and fitof(FloatRegisterImpl::D,F1,F8). >> >> Tested with CTW, nsk. >> I attached microbenchmark test to the bug report. > From vladimir.kozlov at oracle.com Thu Jul 7 17:44:03 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 08 Jul 2011 00:44:03 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 22 new changesets Message-ID: <20110708004443.78F7047271@hg.openjdk.java.net> Changeset: e2af886d540b Author: trims Date: 2011-07-01 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e2af886d540b 7061691: Fork HS21 to HS22 - renumber Minor and build numbers of JVM Summary: Update the Minor and Build numbers for HS22 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1e3493ac2d11 Author: ysr Date: 2011-05-27 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1e3493ac2d11 7048342: CMS: eob == _limit || fc->isFree() failed: Only a free chunk should allow us to cross over the limit Summary: The freeness bit was being cleared in debug code when it shouldn't have been. Also removed unused FreeChunk methods linkAfterNonNull and clearPrev. Reviewed-by: brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp Changeset: 5c0a3c1858b1 Author: ysr Date: 2011-06-02 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5c0a3c1858b1 7048782: CMS: assert(last_chunk_index_to_check<= last_chunk_index) failed: parCardTableModRefBS.cpp:359 Summary: The LNC array is sized before the start of a scavenge, while the heap may expand during a scavenge. With CMS, the last block of an arbitrary suffice of the LNC array may expand due to coalition with the expansion delta. We now take care not to attempt access past the end of the LNC array. LNC array code will be cleaned up and suitably encapsulated as part of the forthcoming performance RFE 7043675. Reviewed-by: brutisso ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp Changeset: e66f38dd58a9 Author: ysr Date: 2011-06-08 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e66f38dd58a9 Merge Changeset: 053d84a76d3d Author: tonyp Date: 2011-06-08 15:31 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/053d84a76d3d 7032531: G1: enhance GC logging to include more accurate eden / survivor size transitions Summary: This changeset extends the logging information generated by +PrintGCDetails to also print out separate size transitions for the eden, survivors, and old regions. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: ae5b2f1dcf12 Author: tonyp Date: 2011-06-08 21:48 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ae5b2f1dcf12 7045662: G1: OopsInHeapRegionClosure::set_region() should not be virtual Summary: make the method non-virtual, remove five unused closures, and fix a couple of copyright typos. Reviewed-by: stefank, johnc, poonam ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: c3f1170908be Author: tonyp Date: 2011-06-10 13:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c3f1170908be 7045330: G1: Simplify/fix the HeapRegionSeq class 7042285: G1: native memory leak during humongous object allocation 6804436: G1: heap region indices should be size_t Summary: A series of fixes and improvements to the HeapRegionSeq class: a) replace the _regions growable array with a standard C array, b) avoid de-allocating / re-allocating HeapRegion instances when the heap shrinks / grows (fix for 7042285), c) introduce fast method to map address to HeapRegion via a "biased" array pointer, d) embed the _hrs object in G1CollectedHeap, instead of pointing to it via an indirection, e) assume that all the regions added to the HeapRegionSeq instance are contiguous, f) replace int's with size_t's for indexes (and expand that to HeapRegion as part of 6804436), g) remove unnecessary / unused methods, h) rename a couple of fields (_alloc_search_start and _seq_bottom), i) fix iterate_from() not to always start from index 0 irrespective of the region passed to it, j) add a verification method to check the HeapRegionSeq assumptions, k) always call the wrappers for _hrs.iterate(), _hrs_length(), and _hrs.at() from G1CollectedHeap, not those methods di rectly, and l) unify the code that expands the sequence (by either re-using or creating a new HeapRegion) and make it robust wrt to a HeapRegion allocation failing. Reviewed-by: stefank, johnc, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp Changeset: 2a241e764894 Author: minqi Date: 2011-06-10 15:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2a241e764894 6941923: RFE: Handling large log files produced by long running Java Applications Summary: supply optinal flags to realize gc log rotation Reviewed-by: ysr, jwilhelm ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/gc/6941923/test6941923.sh Changeset: 42df21744b50 Author: minqi Date: 2011-06-10 15:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/42df21744b50 Merge Changeset: ef2d1b8f2dd4 Author: ysr Date: 2011-06-13 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ef2d1b8f2dd4 7051430: CMS: ongoing CMS cycle should terminate abruptly to allow prompt JVM termination at exit Summary: It turns out that there is no need to explicitly stop CMS since the JVM is taken down at a terminal safepoint during which CMS threads are (terminally) inactive. This will need to be revised if and when we evolve in the future to a point where we allow JVM reincarnation in the same process, but those changes will be much more sweeping than just terminating CMS threads. The unused ::stop() methods will be removed in a separate CR. Also include in this CR is the fix for a small typo in the spelling of UseGCLogFileRotation in a message in arguments.cpp, brought to our attention by Rainer Jung and reviewed by minqi. Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 74cd10898bea Author: brutisso Date: 2011-06-13 13:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/74cd10898bea 6918185: Remove unused code for lost card-marking optimization in BacktraceBuilder Summary: Removed dead code Reviewed-by: ysr, coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp Changeset: 842b840e67db Author: tonyp Date: 2011-06-14 10:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/842b840e67db 7046558: G1: concurrent marking optimizations Summary: Some optimizations to improve the concurrent marking phase: specialize the main oop closure, make sure a few methods in the fast path are properly inlined, a few more bits and pieces, and some cosmetic fixes. Reviewed-by: stefank, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp + src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/utilities/bitMap.hpp Changeset: 6747fd0512e0 Author: johnc Date: 2011-06-14 11:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6747fd0512e0 7004681: G1: Extend marking verification to Full GCs Summary: Perform a heap verification after the first phase of G1's full GC using objects' mark words to determine liveness. The third parameter of the heap verification routines, which was used in G1 to determine which marking bitmap to use in liveness calculations, has been changed from a boolean to an enum with values defined for using the mark word, and the 'prev' and 'next' bitmaps. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp Changeset: 5130fa1b24f1 Author: johnc Date: 2011-06-15 10:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5130fa1b24f1 7045751: G1: +ExplicitGCInvokesConcurrent causes excessive single region evacuation pauses Summary: When ExplicitGCInvokesConcurrent is enabled, do not perform an evacuation pause if a marking cycle is already in progress and block the requesting thread until the marking cycle completes. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c9ca3f51cf41 Author: tonyp Date: 2011-06-16 15:51 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c9ca3f51cf41 6994322: Remove the is_tlab and is_noref / is_large_noref parameters from the CollectedHeap Summary: Remove two unused parameters from the mem_allocate() method and update its uses accordingly. Reviewed-by: stefank, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/oops/typeArrayKlass.cpp Changeset: f75137faa7fe Author: ysr Date: 2011-06-20 09:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f75137faa7fe 6916968: CMS: freeList.cpp:304 assert(_allocation_stats.prevSweep() + ..., "Conservation Principle") Summary: Fix assert and adjust demand volume computation by adding missing factor. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp Changeset: 23d434c6290d Author: tonyp Date: 2011-06-20 22:03 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/23d434c6290d 7055073: G1: code cleanup in the concurrentMark.* files Summary: Only cosmetic changes to make the concurrentMark.* more consistent, code-style-wise, with the rest of the codebase. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp Changeset: e8b0b0392037 Author: tonyp Date: 2011-06-21 15:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e8b0b0392037 7046182: G1: remove unnecessary iterations over the collection set Summary: Remove two unnecessary iterations over the collection set which are supposed to prepare the RSet's of the CSet regions for parallel iterations (we'll make sure this is done incrementally). I'll piggyback on this CR the removal of the G1_REM_SET_LOGGING code. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 5f6f2615433a Author: tonyp Date: 2011-06-24 12:38 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5f6f2615433a 7049999: G1: Make the G1PrintHeapRegions output consistent and complete Summary: Extend and make more consistent the output from the G1PrintHeapRegions flag. Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp + src/share/vm/gc_implementation/g1/g1HRPrinter.cpp + src/share/vm/gc_implementation/g1/g1HRPrinter.hpp Changeset: 04760e41b01e Author: brutisso Date: 2011-06-28 14:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/04760e41b01e 7016112: CMS: crash during promotion testing Summary: Also reviewed by mikael.gerdin at oracle.com; stdlib:qsort() does byte-by-byte swapping on Windows. This leads to pointer shearing. Fix is to implement a quicksort that does full pointer updates. Reviewed-by: never, coleenp, ysr ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp + src/share/vm/utilities/quickSort.cpp + src/share/vm/utilities/quickSort.hpp Changeset: 4bf3cbef0b3e Author: jcoomes Date: 2011-07-06 08:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4bf3cbef0b3e Merge ! src/share/vm/oops/methodOop.cpp ! src/share/vm/runtime/globals.hpp Changeset: b16582d6c7db Author: kvn Date: 2011-07-07 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b16582d6c7db Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp From vladimir.kozlov at oracle.com Fri Jul 8 11:55:58 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 08 Jul 2011 18:55:58 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7059034: Use movxtod/movdtox on T4 Message-ID: <20110708185601.C8C85472AF@hg.openjdk.java.net> Changeset: faa472957b38 Author: kvn Date: 2011-07-08 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/faa472957b38 7059034: Use movxtod/movdtox on T4 Summary: Use new VIS3 mov instructions on T4 for move data between general and float registers. Reviewed-by: never, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/runtime/globals.hpp From tom.rodriguez at oracle.com Fri Jul 8 13:10:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 8 Jul 2011 13:10:32 -0700 Subject: review for 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods Message-ID: <6FC4D868-6EC6-4DE5-92C4-A55B42AF3CFE@oracle.com> http://cr.openjdk.java.net/~never/6990212 154 lines changed: 117 ins; 19 del; 18 mod; 5215 unchg 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods Summary: check for single stepping when dispatching invokes from method handles Reviewed-by: Single stepping and method entry events requires some machinery in the interpreter to make sure that we never jump into compiled code but the method handle invoke path doesn't have that code. The fix is to reintroduce the required check and dispatch to the interpreted entry in that case. Tested with failing test cases from report plus a simple test case to exercise the MH raiseException path since I had to rewrite the arugment passing there. From tom.rodriguez at oracle.com Fri Jul 8 15:21:45 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 8 Jul 2011 15:21:45 -0700 Subject: review for 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods In-Reply-To: <6FC4D868-6EC6-4DE5-92C4-A55B42AF3CFE@oracle.com> References: <6FC4D868-6EC6-4DE5-92C4-A55B42AF3CFE@oracle.com> Message-ID: <25A1B825-BC91-4F1E-B7B1-C8E507F8EA34@oracle.com> Coleen point out that it's confusing to reuse the name jump_from_interpreted since we're not really in the interpreter. I've changed it to jump_from_method_handle and left that note that it parallels jump_from_interpreted. tom On Jul 8, 2011, at 1:10 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6990212 > 154 lines changed: 117 ins; 19 del; 18 mod; 5215 unchg > > 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods > Summary: check for single stepping when dispatching invokes from method handles > Reviewed-by: > > Single stepping and method entry events requires some machinery in the > interpreter to make sure that we never jump into compiled code but the > method handle invoke path doesn't have that code. The fix is to > reintroduce the required check and dispatch to the interpreted entry > in that case. Tested with failing test cases from report plus a > simple test case to exercise the MH raiseException path since I had to > rewrite the arugment passing there. > From tom.rodriguez at oracle.com Fri Jul 8 15:23:17 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 8 Jul 2011 15:23:17 -0700 Subject: review for 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries Message-ID: http://cr.openjdk.java.net/~never/7012081 564 lines changed: 285 ins; 193 del; 86 mod; 7784 unchg 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries Summary: Reviewed-by: There we a bunch of changes to the constant pool and bytecode classes which were never reflected in the SA so it would break when looking at classes using 292 features. The fix is simply to make the SA code mirror the JVM code again. Primarily this was the code dealing with the size of index values for various bytecodes. The generateOopMap.cpp change is purely a formatting change to make it more regular. After these changes some of the tests still fail but this is because of test bugs that will be fixed separately. Tested with failing tests including the tmtools and sajdi suites which exercises the SA extensively. From vladimir.kozlov at oracle.com Fri Jul 8 16:31:23 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Jul 2011 16:31:23 -0700 Subject: review for 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods In-Reply-To: <25A1B825-BC91-4F1E-B7B1-C8E507F8EA34@oracle.com> References: <6FC4D868-6EC6-4DE5-92C4-A55B42AF3CFE@oracle.com> <25A1B825-BC91-4F1E-B7B1-C8E507F8EA34@oracle.com> Message-ID: <4E17934B.3030205@oracle.com> methodHandles_x86.cpp + // Is a cmpl faster (ce ^ ? cmpb() instruction is shorter since immediate is one byte. Also you can use short jccb instead of jcc here. I know it is just copied from other place. May be we should change it there also. methodHandles_sparc.cpp missing delay slot: + __ jump_indirect_to(Address(method, methodOopDesc::interpreter_entry_offset()), temp); + __ bind(skip_compiled_code); Vladimir Tom Rodriguez wrote: > Coleen point out that it's confusing to reuse the name jump_from_interpreted since we're not really in the interpreter. I've changed it to jump_from_method_handle and left that note that it parallels jump_from_interpreted. > > tom > > On Jul 8, 2011, at 1:10 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/6990212 >> 154 lines changed: 117 ins; 19 del; 18 mod; 5215 unchg >> >> 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods >> Summary: check for single stepping when dispatching invokes from method handles >> Reviewed-by: >> >> Single stepping and method entry events requires some machinery in the >> interpreter to make sure that we never jump into compiled code but the >> method handle invoke path doesn't have that code. The fix is to >> reintroduce the required check and dispatch to the interpreted entry >> in that case. Tested with failing test cases from report plus a >> simple test case to exercise the MH raiseException path since I had to >> rewrite the arugment passing there. >> > From vladimir.kozlov at oracle.com Fri Jul 8 16:41:37 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Jul 2011 16:41:37 -0700 Subject: review for 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries In-Reply-To: References: Message-ID: <4E1795B1.8000403@oracle.com> Seems good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7012081 > 564 lines changed: 285 ins; 193 del; 86 mod; 7784 unchg > > 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries > Summary: > Reviewed-by: > > There we a bunch of changes to the constant pool and bytecode classes > which were never reflected in the SA so it would break when looking at > classes using 292 features. The fix is simply to make the SA code > mirror the JVM code again. Primarily this was the code dealing with > the size of index values for various bytecodes. The > generateOopMap.cpp change is purely a formatting change to make it > more regular. After these changes some of the tests still fail but > this is because of test bugs that will be fixed separately. Tested > with failing tests including the tmtools and sajdi suites which > exercises the SA extensively. > From igor.veresov at oracle.com Fri Jul 8 17:58:39 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sat, 09 Jul 2011 00:58:39 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7058510: multinewarray with 6 dimensions uncommon traps in server compiler Message-ID: <20110709005842.9F9F1472C2@hg.openjdk.java.net> Changeset: 263247c478c5 Author: iveresov Date: 2011-07-08 15:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/263247c478c5 7058510: multinewarray with 6 dimensions uncommon traps in server compiler Summary: Pass arguments to runtime via java array for arrays with > 5 dimensions Reviewed-by: never, kvn, jrose, pbk ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp From Dmitry.Samersoff at oracle.com Sat Jul 9 01:30:34 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 09 Jul 2011 12:30:34 +0400 Subject: review for 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods In-Reply-To: <6FC4D868-6EC6-4DE5-92C4-A55B42AF3CFE@oracle.com> References: <6FC4D868-6EC6-4DE5-92C4-A55B42AF3CFE@oracle.com> Message-ID: <4E1811AA.3020700@oracle.com> Tom, methodHandles_x86.cpp: Do we need const and assignment here? 1185 const Register rax_pc = rax; 1186 __ pop(rax_pc); // caller PC Otherwise looks good for me. -Dmitry On 2011-07-09 00:10, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6990212 > 154 lines changed: 117 ins; 19 del; 18 mod; 5215 unchg > > 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods > Summary: check for single stepping when dispatching invokes from method handles > Reviewed-by: > > Single stepping and method entry events requires some machinery in the > interpreter to make sure that we never jump into compiled code but the > method handle invoke path doesn't have that code. The fix is to > reintroduce the required check and dispatch to the interpreted entry > in that case. Tested with failing test cases from report plus a > simple test case to exercise the MH raiseException path since I had to > rewrite the arugment passing there. > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From christian.thalinger at oracle.com Mon Jul 11 00:57:46 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 11 Jul 2011 09:57:46 +0200 Subject: review for 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries In-Reply-To: References: Message-ID: <562F7E5C-4EA6-42CE-8164-BB932CAA15B0@oracle.com> On Jul 9, 2011, at 12:23 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7012081 > 564 lines changed: 285 ins; 193 del; 86 mod; 7784 unchg > > 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries > Summary: > Reviewed-by: > > There we a bunch of changes to the constant pool and bytecode classes > which were never reflected in the SA so it would break when looking at > classes using 292 features. The fix is simply to make the SA code > mirror the JVM code again. Primarily this was the code dealing with > the size of index values for various bytecodes. The > generateOopMap.cpp change is purely a formatting change to make it > more regular. After these changes some of the tests still fail but > this is because of test bugs that will be fixed separately. Tested > with failing tests including the tmtools and sajdi suites which > exercises the SA extensively. agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java: Is the debugging code in isValid intentional? Otherwise looks good. -- Christian From christian.thalinger at oracle.com Mon Jul 11 08:43:41 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 11 Jul 2011 17:43:41 +0200 Subject: review for 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods In-Reply-To: <25A1B825-BC91-4F1E-B7B1-C8E507F8EA34@oracle.com> References: <6FC4D868-6EC6-4DE5-92C4-A55B42AF3CFE@oracle.com> <25A1B825-BC91-4F1E-B7B1-C8E507F8EA34@oracle.com> Message-ID: <839E75F4-67A3-4C3B-AD06-9985EB762357@oracle.com> On Jul 9, 2011, at 12:21 AM, Tom Rodriguez wrote: > Coleen point out that it's confusing to reuse the name jump_from_interpreted since we're not really in the interpreter. I've changed it to jump_from_method_handle and left that note that it parallels jump_from_interpreted. This looks good. Although I'm a little worried about the raise_exception changes on SPARC. In the past I had various crashes with versions that used the interpreter stack to pass the arguments. That's why I changed it to the simpler, more reliable current version (which uses the compiler calling convention). Maybe I got adjust_SP_and_Gargs_down_by_slots right and there is no problem now. Just to be sure I'm currently running JRuby's benchmarks (my memory tells me that I had the crashes with these benchmarks) on two different SPARC boxes. I'll let you know when they are finished. -- Christian > > tom > > On Jul 8, 2011, at 1:10 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/6990212 >> 154 lines changed: 117 ins; 19 del; 18 mod; 5215 unchg >> >> 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods >> Summary: check for single stepping when dispatching invokes from method handles >> Reviewed-by: >> >> Single stepping and method entry events requires some machinery in the >> interpreter to make sure that we never jump into compiled code but the >> method handle invoke path doesn't have that code. The fix is to >> reintroduce the required check and dispatch to the interpreted entry >> in that case. Tested with failing test cases from report plus a >> simple test case to exercise the MH raiseException path since I had to >> rewrite the arugment passing there. From christian.thalinger at oracle.com Mon Jul 11 09:18:09 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 11 Jul 2011 18:18:09 +0200 Subject: review for 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods In-Reply-To: <839E75F4-67A3-4C3B-AD06-9985EB762357@oracle.com> References: <6FC4D868-6EC6-4DE5-92C4-A55B42AF3CFE@oracle.com> <25A1B825-BC91-4F1E-B7B1-C8E507F8EA34@oracle.com> <839E75F4-67A3-4C3B-AD06-9985EB762357@oracle.com> Message-ID: On Jul 11, 2011, at 5:43 PM, Christian Thalinger wrote: > On Jul 9, 2011, at 12:21 AM, Tom Rodriguez wrote: >> Coleen point out that it's confusing to reuse the name jump_from_interpreted since we're not really in the interpreter. I've changed it to jump_from_method_handle and left that note that it parallels jump_from_interpreted. > > This looks good. Looking at it again I think the SPARC code is wrong: + const Address interp_only(G2_thread, JavaThread::interp_only_mode_offset()); + __ ld(interp_only, temp); + __ tst(temp); + __ br(Assembler::notZero, true, Assembler::pn, skip_compiled_code); + __ delayed()->nop(); + __ jump_indirect_to(Address(method, methodOopDesc::interpreter_entry_offset()), temp); + __ bind(skip_compiled_code); It should be: + __ br(Assembler::zero, false, Assembler::pt, run_compiled_code); -- Christian From tom.rodriguez at oracle.com Mon Jul 11 10:50:14 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 11 Jul 2011 10:50:14 -0700 Subject: review for 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries In-Reply-To: <562F7E5C-4EA6-42CE-8164-BB932CAA15B0@oracle.com> References: <562F7E5C-4EA6-42CE-8164-BB932CAA15B0@oracle.com> Message-ID: <9F0E6F0D-B508-4F78-91DF-4FBCA49BB285@oracle.com> On Jul 11, 2011, at 12:57 AM, Christian Thalinger wrote: > On Jul 9, 2011, at 12:23 AM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7012081 >> 564 lines changed: 285 ins; 193 del; 86 mod; 7784 unchg >> >> 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries >> Summary: >> Reviewed-by: >> >> There we a bunch of changes to the constant pool and bytecode classes >> which were never reflected in the SA so it would break when looking at >> classes using 292 features. The fix is simply to make the SA code >> mirror the JVM code again. Primarily this was the code dealing with >> the size of index values for various bytecodes. The >> generateOopMap.cpp change is purely a formatting change to make it >> more regular. After these changes some of the tests still fail but >> this is because of test bugs that will be fixed separately. Tested >> with failing tests including the tmtools and sajdi suites which >> exercises the SA extensively. > > agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java: > > Is the debugging code in isValid intentional? No. Thanks for catching that. I've fixed it. tom > > Otherwise looks good. > > -- Christian From tom.rodriguez at oracle.com Mon Jul 11 11:01:13 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 11 Jul 2011 11:01:13 -0700 Subject: review for 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods In-Reply-To: References: <6FC4D868-6EC6-4DE5-92C4-A55B42AF3CFE@oracle.com> <25A1B825-BC91-4F1E-B7B1-C8E507F8EA34@oracle.com> <839E75F4-67A3-4C3B-AD06-9985EB762357@oracle.com> Message-ID: On Jul 11, 2011, at 9:18 AM, Christian Thalinger wrote: > On Jul 11, 2011, at 5:43 PM, Christian Thalinger wrote: >> On Jul 9, 2011, at 12:21 AM, Tom Rodriguez wrote: >>> Coleen point out that it's confusing to reuse the name jump_from_interpreted since we're not really in the interpreter. I've changed it to jump_from_method_handle and left that note that it parallels jump_from_interpreted. >> >> This looks good. > > Looking at it again I think the SPARC code is wrong: You're right. The original code was more clever and in simplifying it I reversed it. I realized after Vladimir's comment that I hadn't run my tests on sparc, though I would have sworn I had. Anyway, I'm going to make it look more like the original code and run my tests to make sure it's all working properly on sparc. Thanks! tom > > + const Address interp_only(G2_thread, JavaThread::interp_only_mode_offset()); > + __ ld(interp_only, temp); > + __ tst(temp); > + __ br(Assembler::notZero, true, Assembler::pn, skip_compiled_code); > + __ delayed()->nop(); > + __ jump_indirect_to(Address(method, methodOopDesc::interpreter_entry_offset()), temp); > + __ bind(skip_compiled_code); > > It should be: > > + __ br(Assembler::zero, false, Assembler::pt, run_compiled_code); > > -- Christian From xerxes at zafena.se Tue Jul 12 07:46:39 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Tue, 12 Jul 2011 16:46:39 +0200 Subject: Review Request: zero-methodHandle 7009923-regression Message-ID: <4E1C5E4F.1080307@zafena.se> Hi all! Zero FTBFS after the recent 7009923 JSR292 fixes like this: openjdk/hotspot/src/cpu/zero/vm/stack_zero.cpp:72: error: no matching function for call to 'Exceptions::throw_stack_overflow_exception(JavaThread*&, const char [110], int)' openjdk/hotspot/src/share/vm/utilities/exceptions.hpp:147: note: candidates are: static void Exceptions::throw_stack_overflow_exception(Thread*, const char*, int, methodHandle) make[7]: *** [stack_zero.o] Error 1 This webrev updates Zero to handle the Exceptions::throw_stack_overflow_exception API change. http://labb.zafena.se/openjdk/zero-methodHandle-7009923-regression/ Summary of changes: 2 lines changed: 1 ins; 0 del; 1 mod; 87 unchg I don't have a bug id for this. I have signed the SCA. http://sca.java.net/CA_signatories.htm Cheers Xerxes From xerxes at zafena.se Tue Jul 12 08:26:54 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Tue, 12 Jul 2011 17:26:54 +0200 Subject: Review Request: IA32 Hotspot FTBFS 7009309-regression Message-ID: <4E1C67BE.6040407@zafena.se> Hi all! Hotspot FTBFS on IA32 after the recent 7009309 JSR292 fix. The 7009309 JSR292 fix http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/638119ce7cfd removed the StubRoutines::x86 class. This webrev unbreak IA32 Hotspot builds by removing remaining use of StubRoutines::x86. http://labb.zafena.se/openjdk/hotspot-ia32-StubRoutines::x86-7009309-regression/ Summary of changes: 1 line changed: 0 ins; 1 del; 0 mod; 2507 unchg I don't have a bug id for this. I have signed the SCA. http://sca.java.net/CA_signatories.htm This bug was first observed as icedtea PR757. http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=757 Cheers Xerxes From christian.thalinger at oracle.com Tue Jul 12 09:38:31 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 12 Jul 2011 18:38:31 +0200 Subject: review for 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods In-Reply-To: <839E75F4-67A3-4C3B-AD06-9985EB762357@oracle.com> References: <6FC4D868-6EC6-4DE5-92C4-A55B42AF3CFE@oracle.com> <25A1B825-BC91-4F1E-B7B1-C8E507F8EA34@oracle.com> <839E75F4-67A3-4C3B-AD06-9985EB762357@oracle.com> Message-ID: <9E4737BC-6971-42B4-B9B4-C5BC9A2FCA1C@oracle.com> On Jul 11, 2011, at 5:43 PM, Christian Thalinger wrote: > On Jul 9, 2011, at 12:21 AM, Tom Rodriguez wrote: >> Coleen point out that it's confusing to reuse the name jump_from_interpreted since we're not really in the interpreter. I've changed it to jump_from_method_handle and left that note that it parallels jump_from_interpreted. > > This looks good. Although I'm a little worried about the raise_exception changes on SPARC. In the past I had various crashes with versions that used the interpreter stack to pass the arguments. That's why I changed it to the simpler, more reliable current version (which uses the compiler calling convention). Maybe I got adjust_SP_and_Gargs_down_by_slots right and there is no problem now. > > Just to be sure I'm currently running JRuby's benchmarks (my memory tells me that I had the crashes with these benchmarks) on two different SPARC boxes. I'll let you know when they are finished. Sorry, it took a little longer to run them because one of the benchmarks (bench_full_load_path.rb) does not finish (it hangs around doing nothing). Anyway, all others look good. -- Christian From john.r.rose at oracle.com Tue Jul 12 12:30:14 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 12 Jul 2011 12:30:14 -0700 Subject: Review Request: IA32 Hotspot FTBFS 7009309-regression In-Reply-To: <4E1C67BE.6040407@zafena.se> References: <4E1C67BE.6040407@zafena.se> Message-ID: <8A234386-0E3F-4555-873B-B39EBB9A1877@oracle.com> I filed a bug and pushed your patches into mlvm. http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-zero-7066143.patch -- John On Jul 12, 2011, at 8:26 AM, Xerxes R?nby wrote: > Hi all! > > Hotspot FTBFS on IA32 after the recent 7009309 JSR292 fix. > The 7009309 JSR292 fix http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/638119ce7cfd > removed the StubRoutines::x86 class. > This webrev unbreak IA32 Hotspot builds by removing remaining use of > StubRoutines::x86. > > http://labb.zafena.se/openjdk/hotspot-ia32-StubRoutines::x86-7009309-regression/ > Summary of changes: 1 line changed: 0 ins; 1 del; 0 mod; 2507 unchg > > I don't have a bug id for this. > > I have signed the SCA. > http://sca.java.net/CA_signatories.htm > > This bug was first observed as icedtea PR757. > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=757 > > Cheers > Xerxes From john.r.rose at oracle.com Tue Jul 12 16:20:04 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 12 Jul 2011 16:20:04 -0700 Subject: review for 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries In-Reply-To: <9F0E6F0D-B508-4F78-91DF-4FBCA49BB285@oracle.com> References: <562F7E5C-4EA6-42CE-8164-BB932CAA15B0@oracle.com> <9F0E6F0D-B508-4F78-91DF-4FBCA49BB285@oracle.com> Message-ID: <840A5AEB-221C-498F-9FB7-83B0F826E71E@oracle.com> On Jul 11, 2011, at 10:50 AM, Tom Rodriguez wrote: >> Is the debugging code in isValid intentional? > > No. Thanks for catching that. I've fixed it. In that function there is a new line; is it really needed? || ctag.isMethodHandle() || ctag.isMethodType() + || ctag.isMethod() || ctag.isInt() || ctag.isFloat())? true: false; The rest of it looks fine. Some of the new Java code it resembles the corresponding C++ code, in that it seems like code that should be distrusted until it is fully exercised by tests. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110712/aef8a9b6/attachment.html From john.r.rose at oracle.com Tue Jul 12 16:48:25 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 12 Jul 2011 16:48:25 -0700 Subject: Review Request: zero-methodHandle 7009923-regression In-Reply-To: <4E1C5E4F.1080307@zafena.se> References: <4E1C5E4F.1080307@zafena.se> Message-ID: Reviewed. -- John On Jul 12, 2011, at 7:46 AM, Xerxes R?nby wrote: > Hi all! > > Zero FTBFS after the recent 7009923 JSR292 fixes like this: > openjdk/hotspot/src/cpu/zero/vm/stack_zero.cpp:72: > error: no matching function for call to > 'Exceptions::throw_stack_overflow_exception(JavaThread*&, const char [110], > int)' > openjdk/hotspot/src/share/vm/utilities/exceptions.hpp:147: > note: candidates are: static void > Exceptions::throw_stack_overflow_exception(Thread*, const char*, int, > methodHandle) > make[7]: *** [stack_zero.o] Error 1 > > This webrev updates Zero to handle the Exceptions::throw_stack_overflow_exception API change. > > http://labb.zafena.se/openjdk/zero-methodHandle-7009923-regression/ > Summary of changes: 2 lines changed: 1 ins; 0 del; 1 mod; 87 unchg > > I don't have a bug id for this. > > I have signed the SCA. > http://sca.java.net/CA_signatories.htm > > Cheers > Xerxes From tom.rodriguez at oracle.com Tue Jul 12 18:05:16 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 12 Jul 2011 18:05:16 -0700 Subject: review for 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries In-Reply-To: <840A5AEB-221C-498F-9FB7-83B0F826E71E@oracle.com> References: <562F7E5C-4EA6-42CE-8164-BB932CAA15B0@oracle.com> <9F0E6F0D-B508-4F78-91DF-4FBCA49BB285@oracle.com> <840A5AEB-221C-498F-9FB7-83B0F826E71E@oracle.com> Message-ID: On Jul 12, 2011, at 4:20 PM, John Rose wrote: > On Jul 11, 2011, at 10:50 AM, Tom Rodriguez wrote: > >>> Is the debugging code in isValid intentional? >> >> No. Thanks for catching that. I've fixed it. > > In that function there is a new line; is it really needed? > || ctag.isMethodHandle() || ctag.isMethodType() > + || ctag.isMethod() > || ctag.isInt() || ctag.isFloat())? true: false; Yes that was required for it to pass. Is that unexpected? This code has no parallel in the C++ code. > > > The rest of it looks fine. Thanks. > > Some of the new Java code it resembles the corresponding C++ code, in that it seems like code that should be distrusted until it is fully exercised by tests. What are you saying? tom > > -- John > > From john.r.rose at oracle.com Tue Jul 12 19:01:41 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 12 Jul 2011 19:01:41 -0700 Subject: review for 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries In-Reply-To: References: <562F7E5C-4EA6-42CE-8164-BB932CAA15B0@oracle.com> <9F0E6F0D-B508-4F78-91DF-4FBCA49BB285@oracle.com> <840A5AEB-221C-498F-9FB7-83B0F826E71E@oracle.com> Message-ID: <2F57587E-3A3B-4F08-9A13-618364ED4810@oracle.com> On Jul 12, 2011, at 6:05 PM, Tom Rodriguez wrote: > > Yes that was required for it to pass. Is that unexpected? This code has no parallel in the C++ code. Yes, I'm surprised that somebody is making a reference to a CONSTANT_Methodref from something related to ldc or a bootstrap method specifier (or some other constant-loading construct). >> >> >> The rest of it looks fine. > > Thanks. > >> >> Some of the new Java code it resembles the corresponding C++ code, in that it seems like code that should be distrusted until it is fully exercised by tests. > > What are you saying? I'm saying that it's fine, but since I did not mentally prove the change correct (which is possible sometimes), I'm relying on the testing to catch errors. -- John From john.r.rose at oracle.com Wed Jul 13 01:48:51 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 13 Jul 2011 08:48:51 +0000 Subject: hg: hsx/hotspot-comp/jdk: 125 new changesets Message-ID: <20110713091003.EDFF8473CE@hg.openjdk.java.net> Changeset: 3f760b347d3b Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3f760b347d3b 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: bc97b962330e Author: mfang Date: 2011-05-26 20:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bc97b962330e 7045184: GTK L&F doesn't have hotkeys in jdk7 b141, while b139 has. Reviewed-by: yhuang, ogino ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties Changeset: 6943c4d9caa3 Author: mfang Date: 2011-05-31 13:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6943c4d9caa3 Merge Changeset: 7c5bc5a807ee Author: dholmes Date: 2011-05-27 19:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7c5bc5a807ee 7024120: Verify reduced JRE contents for java 7 Summary: stripped all symbols from libs and executables to reduce JRE size. Restored missing classes needed to pass JCK in headless mode Reviewed-by: bobv, ohair ! make/common/Defs-embedded.gmk ! make/common/Release-embedded.gmk Changeset: f4895b3fe1be Author: dholmes Date: 2011-05-31 17:28 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f4895b3fe1be Merge Changeset: eab27338b3d9 Author: schien Date: 2011-06-01 11:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/eab27338b3d9 Merge Changeset: 8d91855a1f4e Author: prr Date: 2011-05-27 13:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8d91855a1f4e 7046587: Outlines in OTF/CFF fonts are misclassified as quadratic curves Reviewed-by: igor ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/NullFontScaler.java Changeset: 0b0b92707cf5 Author: bae Date: 2011-05-30 12:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0b0b92707cf5 7032904: XRender: Java2Demo : Infinite loop in Java_sun_java2d_loops_MaskBlit_MaskBlit on OEL 5.6 x64 Reviewed-by: prr ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 290daca0a693 Author: prr Date: 2011-05-30 22:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/290daca0a693 7049874: OpenJDK Build breakage fix: freetypescaler.c needs to match updated signature Reviewed-by: lana, igor ! src/share/native/sun/font/freetypeScaler.c Changeset: b351af09bfa3 Author: lana Date: 2011-06-02 13:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b351af09bfa3 Merge Changeset: d2081a1f417f Author: bagiras Date: 2011-05-27 11:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d2081a1f417f 7045174: Most of the tests in awt area fails with jdk 7b142 on windows with -Xcheck:jni Reviewed-by: art, denis ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 000a845b1e38 Author: denis Date: 2011-05-28 12:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/000a845b1e38 7046325: Broken links in java.awt.Toolkit's javadoc Reviewed-by: dav, yan ! src/share/classes/java/awt/Toolkit.java Changeset: eab94f59b6dc Author: dcherepanov Date: 2011-05-30 13:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/eab94f59b6dc 7045354: Korean IME's Hanja candidate window is not displayed on IMFDemo Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Component.cpp Changeset: f05164caa490 Author: serb Date: 2011-05-30 17:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f05164caa490 7045193: interactive JCK tests java_awt/interactive/FileDialogTests fail Reviewed-by: dcherepanov, dav, art, denis ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: b955226868af Author: lana Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b955226868af Merge Changeset: 1fbaf2b688a6 Author: rupashka Date: 2011-05-24 11:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1fbaf2b688a6 7045593: Possible Regression : JTextfield cursor placement behavior algorithm has changed. Reviewed-by: peterz ! src/share/classes/javax/swing/text/Utilities.java + test/javax/swing/text/Utilities/bug7045593.java Changeset: 442237d3ec2c Author: rupashka Date: 2011-05-28 11:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/442237d3ec2c 7048204: NPE from NimbusLookAndFeel.addDefault Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java + test/javax/swing/plaf/nimbus/Test7048204.java Changeset: 386516fdf40b Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/386516fdf40b Merge Changeset: 0a80650409e1 Author: mullan Date: 2011-05-24 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0a80650409e1 7044443: Permissions resolved incorrectly for jar protocol (Patch from bugs.openjdk.java.net) Reviewed-by: alanb, chegar Contributed-by: dbhole at redhat.com ! src/share/classes/sun/security/provider/PolicyFile.java + test/java/security/Policy/GetPermissions/JarURL.java Changeset: ace2dfdecda1 Author: mullan Date: 2011-05-24 14:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ace2dfdecda1 Merge Changeset: 70942be348af Author: jeff Date: 2011-05-27 15:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/70942be348af 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: b49a0af85821 Author: vinnie Date: 2011-05-30 16:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b49a0af85821 7049173: Replace the software license for ECC native code Reviewed-by: alanb ! src/share/native/sun/security/ec/impl/ec.c ! src/share/native/sun/security/ec/impl/ec.h ! src/share/native/sun/security/ec/impl/ec2.h ! src/share/native/sun/security/ec/impl/ec2_163.c ! src/share/native/sun/security/ec/impl/ec2_193.c ! src/share/native/sun/security/ec/impl/ec2_233.c ! src/share/native/sun/security/ec/impl/ec2_aff.c ! src/share/native/sun/security/ec/impl/ec2_mont.c ! src/share/native/sun/security/ec/impl/ec_naf.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/ecl-curve.h ! src/share/native/sun/security/ec/impl/ecl-exp.h ! src/share/native/sun/security/ec/impl/ecl-priv.h ! src/share/native/sun/security/ec/impl/ecl.c ! src/share/native/sun/security/ec/impl/ecl.h ! src/share/native/sun/security/ec/impl/ecl_curve.c ! src/share/native/sun/security/ec/impl/ecl_gf.c ! src/share/native/sun/security/ec/impl/ecl_mult.c ! src/share/native/sun/security/ec/impl/ecp.h ! src/share/native/sun/security/ec/impl/ecp_192.c ! src/share/native/sun/security/ec/impl/ecp_224.c ! src/share/native/sun/security/ec/impl/ecp_256.c ! src/share/native/sun/security/ec/impl/ecp_384.c ! src/share/native/sun/security/ec/impl/ecp_521.c ! src/share/native/sun/security/ec/impl/ecp_aff.c ! src/share/native/sun/security/ec/impl/ecp_jac.c ! src/share/native/sun/security/ec/impl/ecp_jm.c ! src/share/native/sun/security/ec/impl/ecp_mont.c ! src/share/native/sun/security/ec/impl/logtab.h ! src/share/native/sun/security/ec/impl/mp_gf2m-priv.h ! src/share/native/sun/security/ec/impl/mp_gf2m.c ! src/share/native/sun/security/ec/impl/mp_gf2m.h ! src/share/native/sun/security/ec/impl/mpi-config.h ! src/share/native/sun/security/ec/impl/mpi-priv.h ! src/share/native/sun/security/ec/impl/mpi.c ! src/share/native/sun/security/ec/impl/mpi.h ! src/share/native/sun/security/ec/impl/mplogic.c ! src/share/native/sun/security/ec/impl/mplogic.h ! src/share/native/sun/security/ec/impl/mpmontg.c ! src/share/native/sun/security/ec/impl/mpprime.h ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/ec/impl/secoidt.h Changeset: 4ed7c877a463 Author: michaelm Date: 2011-05-30 23:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4ed7c877a463 7042550: Reintegrate 6569621 Reviewed-by: chegar, alanb ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java + src/share/classes/sun/net/RegisteredDomain.java ! src/share/classes/sun/net/www/URLConnection.java ! src/share/classes/sun/net/www/http/HttpClient.java Changeset: c79a089ae13b Author: wetmore Date: 2011-05-31 12:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c79a089ae13b 7042097: JDK 7's Unlimited Cryptographic Policy bundle text files must be updated. Reviewed-by: valeriep ! make/javax/crypto/Makefile Changeset: a00f48c96345 Author: lancea Date: 2011-06-02 12:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a00f48c96345 7049107: Cannot call initCause() on BatchUpdateException Reviewed-by: darcy ! src/share/classes/java/sql/BatchUpdateException.java Changeset: 39de8937c1d8 Author: lana Date: 2011-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/39de8937c1d8 Merge Changeset: e8e6cdff5995 Author: trims Date: 2011-06-03 20:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e8e6cdff5995 Merge Changeset: 8f19b165347b Author: bae Date: 2011-06-04 23:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8f19b165347b 7042594: 3 testis api/java_awt/Color/ICC_ProfileRGB/index.html fail against RI b138 OEL6x64. Reviewed-by: prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java + test/sun/java2d/cmm/ProfileOp/SetDataTest.java Changeset: bbb4cef2208b Author: lana Date: 2011-06-04 17:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bbb4cef2208b Merge Changeset: 03a828e368ca Author: rupashka Date: 2011-06-04 01:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/03a828e368ca 6977587: GTK L&F: jnlp: java.io.IOException thrown when choosing more than 1 file in the dialog Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java Changeset: 6c9c55ae313b Author: lana Date: 2011-06-03 22:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6c9c55ae313b Merge Changeset: e81d259442ed Author: lana Date: 2011-06-04 17:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e81d259442ed Merge Changeset: 53d759eb580c Author: alanb Date: 2011-06-04 11:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/53d759eb580c 7050358: (fs spec) Path.toUri doesn't allow custom providers to use opaque URIs Reviewed-by: sherman ! src/share/classes/java/nio/file/Path.java Changeset: 49aef5a5416e Author: mullan Date: 2011-06-04 06:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/49aef5a5416e 7050329: test/java/security/Policy/GetPermissions/JarURL.java fails on Windows Reviewed-by: alanb ! test/java/security/Policy/GetPermissions/JarURL.java + test/java/security/Policy/GetPermissions/JarURL.policy Changeset: 1f39ca0b9598 Author: mullan Date: 2011-06-04 06:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1f39ca0b9598 Merge Changeset: 1e04b38b3824 Author: lana Date: 2011-06-04 17:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1e04b38b3824 Merge Changeset: 7a341c412ea9 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7a341c412ea9 Added tag jdk7-b145 for changeset 1e04b38b3824 ! .hgtags Changeset: e7493c32e598 Author: schien Date: 2011-06-08 10:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e7493c32e598 Merge Changeset: ae731399e525 Author: dav Date: 2011-06-07 22:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ae731399e525 7048568: Crash in Java_sun_awt_Win32GraphicsEnvironment_isVistaOS Reviewed-by: dcherepanov, art, amenkov ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp Changeset: f08fcae94813 Author: lana Date: 2011-06-10 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f08fcae94813 Merge Changeset: 6e961c328276 Author: michaelm Date: 2011-06-08 10:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6e961c328276 7050028: ISE "zip file closed" from JarURLConnection.getInputStream on JDK 7 when !useCaches Reviewed-by: chegar, alanb ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/B7050028.java Changeset: b6ced5ad7a62 Author: dwanvik Date: 2011-06-10 17:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b6ced5ad7a62 7046557: Changes to the Java DB README files in JDK7 Summary: Update /README.html with correct mention of Java DB, add JDK specific README files to /db and /demo/db. Reviewed-by: ohair ! make/common/Release.gmk Changeset: 646ab254ff80 Author: lana Date: 2011-06-10 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/646ab254ff80 Merge Changeset: aca0dc2b921c Author: weijun Date: 2011-02-09 11:50 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/aca0dc2b921c 6618658: Deserialization allows creation of mutable SignedObject Reviewed-by: hawtin, mullan ! src/share/classes/java/security/SignedObject.java + test/java/security/SignedObject/Correctness.java Changeset: df445f522425 Author: bae Date: 2011-02-17 12:21 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/df445f522425 7013519: [parfait] Integer overflows in 2D code Reviewed-by: prr, valeriep ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/font/layout/SunLayoutEngine.cpp Changeset: ccb2fcfb6d6b Author: chegar Date: 2011-02-18 13:31 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ccb2fcfb6d6b 7013969: NetworkInterface.toString can reveal bindings Reviewed-by: alanb, michaelm, hawtin ! src/share/classes/java/net/NetworkInterface.java Changeset: 026adaac71f1 Author: dcherepanov Date: 2011-02-25 15:54 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/026adaac71f1 7012520: Heap overflow vulnerability in FileDialog.show() Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: d489f00d6c65 Author: flar Date: 2011-03-02 05:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d489f00d6c65 7016495: Crash in Java 2D transforming an image with scale close to zero Reviewed-by: prr, bae ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/native/sun/java2d/loops/TransformHelper.c + test/java/awt/image/BufferedImage/TinyScale.java Changeset: fe27fe44ac51 Author: ksrini Date: 2011-03-03 14:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fe27fe44ac51 7016985: (launcher) implement safe secure dll loading Reviewed-by: mchung ! src/windows/bin/java_md.c Changeset: 0efa64f13302 Author: chegar Date: 2011-04-05 14:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0efa64f13302 7033865: JDK: Add private API for secure/restrictive loading of system dlls Reviewed-by: alanb ! src/share/native/common/jdk_util.h + src/solaris/native/common/jdk_util_md.h ! src/windows/native/common/jdk_util_md.c + src/windows/native/common/jdk_util_md.h Changeset: 67992a58bfba Author: ksrini Date: 2011-04-05 16:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/67992a58bfba 7032593: DLL_LOADING: Upgrade solution to 7016985 to reflect JDK7 solution Reviewed-by: mchung, asaha ! src/windows/bin/java_md.c Changeset: 7181441faf72 Author: dcherepanov Date: 2011-04-08 16:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7181441faf72 7003962: AWT: securely load DLLs and launch executables using fully qualified path Reviewed-by: art, bae, alanb ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h ! src/windows/native/sun/windows/DllUtil.cpp ! src/windows/native/sun/windows/DllUtil.h ! src/windows/native/sun/windows/ShellFolder2.cpp ! src/windows/native/sun/windows/ThemeReader.cpp ! src/windows/native/sun/windows/awt_Mlib.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/stdhdrs.h Changeset: 05a3923f516f Author: dcherepanov Date: 2011-04-08 17:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/05a3923f516f 7035077: Minor addition to the changes for 7003962 Reviewed-by: chegar ! src/windows/native/sun/windows/DllUtil.cpp Changeset: afcc1530e68b Author: asaha Date: 2011-04-08 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/afcc1530e68b Merge - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/MethodHandle.java - src/share/classes/java/dyn/MethodHandles.java - src/share/classes/java/dyn/MethodType.java - src/share/classes/java/dyn/MethodTypeForm.java - src/share/classes/java/dyn/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.java - src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/java/dyn/package-info.java - src/share/classes/sun/dyn/Access.java - src/share/classes/sun/dyn/AdapterMethodHandle.java - src/share/classes/sun/dyn/BoundMethodHandle.java - src/share/classes/sun/dyn/CallSiteImpl.java - src/share/classes/sun/dyn/DirectMethodHandle.java - src/share/classes/sun/dyn/FilterGeneric.java - src/share/classes/sun/dyn/FilterOneArgument.java - src/share/classes/sun/dyn/FromGeneric.java - src/share/classes/sun/dyn/InvokeGeneric.java - src/share/classes/sun/dyn/Invokers.java - src/share/classes/sun/dyn/MemberName.java - src/share/classes/sun/dyn/MethodHandleImpl.java - src/share/classes/sun/dyn/MethodHandleNatives.java - src/share/classes/sun/dyn/MethodTypeImpl.java - src/share/classes/sun/dyn/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.java - src/share/classes/sun/dyn/anon/AnonymousClassLoader.java - src/share/classes/sun/dyn/anon/ConstantPoolParser.java - src/share/classes/sun/dyn/anon/ConstantPoolPatch.java - src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java - src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java - src/share/classes/sun/dyn/empty/Empty.java - src/share/classes/sun/dyn/package-info.java - src/share/classes/sun/dyn/util/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.java - src/share/classes/sun/dyn/util/ValueConversions.java - src/share/classes/sun/dyn/util/VerifyAccess.java - src/share/classes/sun/dyn/util/VerifyType.java - src/share/classes/sun/dyn/util/Wrapper.java - src/share/classes/sun/dyn/util/package-info.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: 557bd9b5d92f Author: asaha Date: 2011-04-08 10:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/557bd9b5d92f Merge Changeset: e142148d8b54 Author: asaha Date: 2011-04-12 14:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e142148d8b54 Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java Changeset: 76e0e562b617 Author: dcherepanov Date: 2011-04-15 17:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/76e0e562b617 7036952: build warning after the changes for 7003962 Reviewed-by: art, bae ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h Changeset: f8eddc85cc02 Author: zgu Date: 2011-04-15 09:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f8eddc85cc02 7003964: SERV: securely load DLLs and launch executables using fully qualified path Summary: Linked in Windows libraries that are available on jdk7 supported platforms, and used GetModuleHandle instead of LoadLibrary for already loaded Dlls. Reviewed-by: dcubed, alanb ! make/com/sun/tools/attach/Makefile ! src/windows/classes/sun/tools/attach/WindowsAttachProvider.java ! src/windows/native/sun/tools/attach/WindowsAttachProvider.c ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c ! src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c ! src/windows/npt/npt_md.h Changeset: 0865aa0ad9b2 Author: zgu Date: 2011-04-19 10:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0865aa0ad9b2 Merge Changeset: 6f8a4d334fb2 Author: asaha Date: 2011-04-20 09:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6f8a4d334fb2 Merge ! make/com/sun/tools/attach/Makefile ! src/share/classes/java/net/NetworkInterface.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/windows/bin/java_md.c ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: f3645b5d6e62 Author: asaha Date: 2011-04-20 21:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f3645b5d6e62 Merge Changeset: b626f78c57e1 Author: asaha Date: 2011-04-21 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b626f78c57e1 Merge Changeset: cec45f3353be Author: asaha Date: 2011-04-21 08:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cec45f3353be Merge Changeset: 6133c9ee3a01 Author: asaha Date: 2011-04-21 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6133c9ee3a01 Merge Changeset: dd06e8d3da91 Author: asaha Date: 2011-04-21 15:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dd06e8d3da91 Merge Changeset: b2295905901a Author: asaha Date: 2011-04-21 16:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b2295905901a Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java Changeset: 3fedf261fb4f Author: valeriep Date: 2011-04-26 15:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3fedf261fb4f 7003952: SEC: securely load DLLs and launch executables using fully qualified path Summary: Enforce full path when specifying library locations. Reviewed-by: wetmore, ohair ! make/sun/security/pkcs11/Makefile ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/native/sun/security/pkcs11/j2secmod.c + test/sun/security/pkcs11/Provider/Absolute.cfg + test/sun/security/pkcs11/Provider/Absolute.java Changeset: 94ea3b8288f1 Author: alexp Date: 2011-05-04 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/94ea3b8288f1 7020198: ImageIcon creates Component with null acc Reviewed-by: rupashka, hawtin ! src/share/classes/javax/swing/ImageIcon.java Changeset: e6fdfb249e31 Author: asaha Date: 2011-05-04 16:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e6fdfb249e31 Merge - src/share/native/sun/font/layout/Features.h ! src/windows/native/sun/windows/awt_FileDialog.cpp - test/javax/swing/text/GlyphView/6539700/bug6539700.java Changeset: 49244980d692 Author: asaha Date: 2011-05-05 22:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/49244980d692 Merge - src/share/classes/sun/security/util/SignatureFileManifest.java Changeset: 647b031200f0 Author: asaha Date: 2011-05-06 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/647b031200f0 Merge Changeset: 92b5197e9ff5 Author: asaha Date: 2011-05-26 21:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/92b5197e9ff5 Merge ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp Changeset: cca9ea306c6e Author: asaha Date: 2011-05-26 21:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cca9ea306c6e Merge Changeset: dab3e66ebda7 Author: lana Date: 2011-06-06 19:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dab3e66ebda7 Merge Changeset: 9f17be5136d1 Author: wetmore Date: 2011-06-09 14:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9f17be5136d1 7052537: java/security/Security/NotInstalledProviders.java is causing -samevm tests to fail. Reviewed-by: valeriep, asaha, alanb ! test/java/security/Security/NoInstalledProviders.java Changeset: 4961be00d3b5 Author: lana Date: 2011-06-15 16:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4961be00d3b5 Merge Changeset: cf0632d2db2c Author: jrose Date: 2011-06-14 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cf0632d2db2c 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray Summary: Fix corner cases involving MethodHandles.permuteArguments with long or double argument lists. Reviewed-by: twisti, never ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/SwitchPoint.java + test/java/lang/invoke/PermuteArgsTest.java Changeset: a65fa0f6717e Author: trims Date: 2011-06-17 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a65fa0f6717e Merge Changeset: c46f97579fe6 Author: alanb Date: 2011-06-17 16:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c46f97579fe6 7055508: (aio) EXCEPTION_ACCESS_VIOLATION in AsynchronousSocketChannel.connect on Windows 7 Reviewed-by: chegar ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c Changeset: c102e1221afa Author: lana Date: 2011-06-17 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c102e1221afa Merge Changeset: 539e576793a8 Author: lana Date: 2011-06-18 10:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/539e576793a8 Merge Changeset: 7b4f4230fecf Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7b4f4230fecf Added tag jdk7-b146 for changeset 539e576793a8 ! .hgtags Changeset: f2928d86aab0 Author: schien Date: 2011-06-20 17:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f2928d86aab0 Merge Changeset: cfd7602f5c52 Author: jeff Date: 2011-06-22 10:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cfd7602f5c52 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: f097ca2434b1 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f097ca2434b1 Merge Changeset: 9b8c96f96a0f Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9b8c96f96a0f Added tag jdk7-b147 for changeset f097ca2434b1 ! .hgtags Changeset: fc350fd41f31 Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fc350fd41f31 Merge Changeset: 685a01aa8cd2 Author: prr Date: 2011-05-25 19:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/685a01aa8cd2 7044394: TrueTypeFont inner class DirectoryEntry should be static Reviewed-by: bae, jgodinez ! src/share/classes/sun/font/TrueTypeFont.java Changeset: 73d420a7199b Author: dlila Date: 2011-06-24 16:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/73d420a7199b 7049339: AnyBlit is broken with non-rectangular clips. Reviewed-by: flar ! src/share/classes/sun/java2d/loops/Blit.java + test/sun/java2d/loops/Bug7049339.java Changeset: bb481604e929 Author: lana Date: 2011-06-30 14:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bb481604e929 Merge Changeset: b8bcb12acea6 Author: weijun Date: 2011-05-27 09:01 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b8bcb12acea6 7048466: Move sun.misc.JavaxSecurityAuthKerberosAccess to sun.security.krb5 package Reviewed-by: weijun, alanb Contributed-by: Mandy Chung ! src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java ! src/share/classes/javax/security/auth/kerberos/KeyTab.java - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java + src/share/classes/sun/security/krb5/JavaxSecurityAuthKerberosAccess.java + src/share/classes/sun/security/krb5/KerberosSecrets.java Changeset: 0da0a4d22fba Author: dcubed Date: 2011-06-01 17:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0da0a4d22fba 7048308: 4/4 LoggingDeadlock3 test timeout is too small Summary: Change timeout for test from 15 seconds to 80 seconds. Reviewed-by: dholmes ! test/java/util/logging/LoggingDeadlock3.java Changeset: 4a221501079a Author: dcubed Date: 2011-06-01 17:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4a221501079a 7045594: 4/4 fix for 6977677 introduced a ResourceBundle race Summary: Fix Logger.getLogger() ResourceBundle name race. Reviewed-by: dholmes, mchung ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/LoggerResourceBundleRace.java + test/java/util/logging/RacingThreadsTest.java Changeset: 9b678733fa51 Author: weijun Date: 2011-06-08 14:01 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9b678733fa51 7043737: klist does not detect non-existing keytab Reviewed-by: valeriep ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java + test/sun/security/krb5/tools/ktmissing.sh Changeset: 958eea7dd46e Author: darcy Date: 2011-06-13 12:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/958eea7dd46e 7052122: Update JDK_MINOR_VERSION for JDK 8 Reviewed-by: mr, katleman ! make/common/shared/Defs.gmk ! make/docs/Makefile Changeset: 08fdfdb19ad6 Author: coffeys Date: 2011-06-14 18:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/08fdfdb19ad6 7049774: UID construction appears to hang if time changed backwards Reviewed-by: alanb, dholmes, chegar, mduigou ! src/share/classes/java/rmi/server/UID.java Changeset: 4e7a9fa84dea Author: darcy Date: 2011-06-14 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4e7a9fa84dea 7054669: javadoc warnings from java.awt.Toolkit Reviewed-by: anthony ! src/share/classes/java/awt/Toolkit.java Changeset: 33e6291f3251 Author: darcy Date: 2011-06-15 08:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/33e6291f3251 7041252: Use j.u.Objects.equals in security classes Reviewed-by: weijun ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/x509/DistributionPoint.java ! src/share/classes/sun/security/x509/DistributionPointName.java Changeset: 85480980cd5e Author: darcy Date: 2011-06-17 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/85480980cd5e 7021922: java.lang.annoation.IncompleteExceptions throws NPE when type is null Reviewed-by: alanb, forax ! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java + test/java/lang/annotation/TestIncompleteAnnotationExceptionNPE.java Changeset: e373b4c95b4b Author: ksrini Date: 2011-06-17 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e373b4c95b4b 7043125: TEST: tools/launcher/VersionCheck.java fails just against openjdk7 (b141 & b138-nightly) promoted Reviewed-by: darcy ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/VersionCheck.java Changeset: b29888e74be3 Author: alanb Date: 2011-06-19 11:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b29888e74be3 7056489: test/com/sun/jndi/ldap/ReadTimeoutTest.java hangs or times out Reviewed-by: forax, vinnie ! test/ProblemList.txt ! test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 82706552f7a3 Author: weijun Date: 2011-06-20 17:38 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/82706552f7a3 7054428: test/java/security/SecureClassLoader/DefineClassByteBuffer.java error Reviewed-by: alanb ! test/ProblemList.txt ! test/java/security/SecureClassLoader/DefineClassByteBuffer.java Changeset: 411d02c13385 Author: dl Date: 2011-06-20 12:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/411d02c13385 7051516: ThreadLocalRandom seed is never initialized so all instances generate the same sequence Reviewed-by: chegar, dholmes, mduigou ! src/share/classes/java/util/Random.java Changeset: a015dda3bdc6 Author: weijun Date: 2011-06-20 19:17 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a015dda3bdc6 7054918: jdk_security1 test target cleanup Reviewed-by: alanb, smarks, vinnie ! test/ProblemList.txt ! test/java/security/BasicPermission/PermClass.java ! test/java/security/BasicPermission/SerialVersion.java ! test/java/security/KeyFactory/Failover.java ! test/java/security/KeyPairGenerator/Failover.java ! test/java/security/Provider/ChangeProviders.java ! test/java/security/Provider/GetInstance.java ! test/java/security/Provider/RemoveProvider.java ! test/java/security/Provider/Turkish.java ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/NoInstalledProviders.java ! test/java/security/Security/SynchronizedAccess.java ! test/java/security/Security/removing/RemoveProviders.java ! test/java/security/UnresolvedPermission/Equals.java ! test/java/security/spec/EllipticCurveMatch.java + test/java/security/testlibrary/ProvidersSnapshot.java Changeset: 3c8f939ced1c Author: darcy Date: 2011-06-20 17:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3c8f939ced1c 7055295: (reflect) add conventional constructor to GenericSignatureFormatError Reviewed-by: lancea, mduigou ! src/share/classes/java/lang/reflect/GenericSignatureFormatError.java Changeset: 70f14c2db078 Author: alanb Date: 2011-06-21 16:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/70f14c2db078 7056815: test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh times out intermittently on busy machine Reviewed-by: mchung ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh Changeset: 0bde4bed86e5 Author: alanb Date: 2011-06-22 15:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0bde4bed86e5 7056447: test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java fails in agentvm Reviewed-by: emcmanus ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java Changeset: febb7f557135 Author: weijun Date: 2011-06-23 09:27 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/febb7f557135 7055362: jdk_security2 test target cleanup Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt ! test/com/sun/crypto/provider/Cipher/DES/Sealtest.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEP_KAT.java ! test/javax/crypto/EncryptedPrivateKeyInfo/GetKeySpecException.java ! test/javax/crypto/JceSecurity/SunJCE_BC_LoadOrdering.java Changeset: 3b7193ab0d87 Author: xuelei Date: 2011-06-22 19:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3b7193ab0d87 6952814: sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java failing in PIT Reviewed-by: alanb - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: 57265bf4b36b Author: xuelei Date: 2011-06-22 21:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/57265bf4b36b 7058271: Remove InterruptedIO.java record from ProblemList.txt Reviewed-by: weijun ! test/ProblemList.txt Changeset: 6b2c14dfe9b9 Author: chegar Date: 2011-06-23 13:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6b2c14dfe9b9 7057935: com/sun/nio/sctp tests should be moved out of jdk_nio and into their own target, jdk_sctp Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt Changeset: ae7211979179 Author: chegar Date: 2011-06-23 13:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ae7211979179 7021010: java/lang/Thread/ThreadStateTest.java fails intermittently Reviewed-by: dholmes, alanb, mchung ! test/ProblemList.txt ! test/java/lang/Thread/ThreadStateTest.java Changeset: cd7adb545f71 Author: xuelei Date: 2011-06-23 04:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cd7adb545f71 7057022: test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java has invalid jtreg tags Reviewed-by: weijun ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java Changeset: 151756a4037b Author: darcy Date: 2011-06-23 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/151756a4037b 6253144: Long narrowing conversion should describe the algorithm used and implied "risks" Reviewed-by: mduigou, alanb ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Number.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java Changeset: 5838c5bd185d Author: lana Date: 2011-06-22 23:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5838c5bd185d Merge ! src/share/classes/java/awt/Toolkit.java ! test/java/security/Security/NoInstalledProviders.java Changeset: 5dedb265ba3e Author: lana Date: 2011-06-23 14:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5dedb265ba3e Merge Changeset: b037a8bc1be8 Author: lana Date: 2011-06-23 17:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b037a8bc1be8 Merge Changeset: 0ad50d4ed1cf Author: alanb Date: 2011-06-24 19:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0ad50d4ed1cf 6965150: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Basic.java takes too long Reviewed-by: chegar ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java Changeset: 113c75db6c8b Author: michaelm Date: 2011-06-27 12:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/113c75db6c8b 7059777: Remove lang tests from Problemlist.txt Reviewed-by: alanb ! test/ProblemList.txt Changeset: a053c28304e8 Author: ksrini Date: 2011-06-27 12:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a053c28304e8 7046007: (launcher) Improve usage information for -verbose option Reviewed-by: darcy, alanb ! src/share/classes/sun/launcher/resources/launcher.properties Changeset: 3abc52f0a4dc Author: dholmes Date: 2011-06-27 20:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3abc52f0a4dc 7039182: PPC: NIO: java.io.IOException: Invalid argument in sun.nio.ch.FileDispatcherImpl.read0 Summary: Allow platform specific files to be located at build time instead of generating them Reviewed-by: alanb, ohair ! make/common/Defs-embedded.gmk ! make/java/nio/Makefile Changeset: 7b5a0a141b8b Author: michaelm Date: 2011-06-28 10:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7b5a0a141b8b 7058832: com/sun/net/httpserver/bugs/B6373555.java failing intermittently Reviewed-by: alanb ! test/com/sun/net/httpserver/bugs/B6373555.java Changeset: 585cc4a4528d Author: michaelm Date: 2011-06-28 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/585cc4a4528d Merge Changeset: 9bcf6217a374 Author: lana Date: 2011-06-30 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9bcf6217a374 Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: 5f3cd0cbad56 Author: jrose Date: 2011-07-13 01:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5f3cd0cbad56 Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java From vladimir.kozlov at oracle.com Wed Jul 13 15:43:03 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 13 Jul 2011 22:43:03 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 9 new changesets Message-ID: <20110713224322.DF608473F2@hg.openjdk.java.net> Changeset: 7d9e451f5416 Author: jcoomes Date: 2011-07-06 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7d9e451f5416 7061187: need some includes for arm/ppc Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/runtime/atomic.cpp Changeset: eb94b7226b7a Author: jcoomes Date: 2011-07-06 12:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/eb94b7226b7a 7061192: option handling adjustments for oracle and embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 65dba8692db7 Author: jcoomes Date: 2011-07-06 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/65dba8692db7 7061197: ThreadLocalStorage sp map table should be optional Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.hpp Changeset: 48048b59a551 Author: jcoomes Date: 2011-07-06 12:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/48048b59a551 7061204: clean the chunk table synchronously in embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: bf6481e5f96d Author: jcoomes Date: 2011-07-06 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bf6481e5f96d 7061225: os::print_cpu_info() should support os-specific data Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 8a4fc2990229 Author: jcoomes Date: 2011-07-07 15:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8a4fc2990229 7053189: remove some unnecessary platform-dependent includes Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp Changeset: b0b8491925fe Author: jcoomes Date: 2011-07-11 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b0b8491925fe 7061212: use o/s low memory notification in embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os/linux/vm/os_linux.cpp Changeset: 0defeba52583 Author: jcoomes Date: 2011-07-12 16:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0defeba52583 Merge Changeset: 1f4f4ae84625 Author: kvn Date: 2011-07-13 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1f4f4ae84625 Merge ! src/share/vm/runtime/globals.hpp From igor.veresov at oracle.com Wed Jul 13 18:49:02 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 13 Jul 2011 18:49:02 -0700 Subject: request(S): 7066339: Tiered: policy should make consistent decisions about osr levels Message-ID: <4E1E4B0E.5080201@oracle.com> After my fix for 7058689 it is possible that the AdvancedThresholdPolicy will make a different decision as to what compilation level for osr is appropriate in loop_event() and call_event() from what happens in method_back_branch_event(). In method_back_branch_event() in case the OSR compilation level is CompLevel_limited_profile we change it to CompLevel_full_profile but we don't do the same in call_event() and loop_event() to determine whether the existing OSR methods are current. The solution would be to move this level fixup in form of disabling the tier 3 delay feedback in common() for OSRs. There was also bad interaction between the in-queue level change optimization with TieredStopAtLevel option set to 3, which caused compilation loops between level 2 and 3. Now it will be disabled if TieredStopAtLevel < 4. Also moved handling of TieredStopAtLevel to common(), because when it was in compile() it could lead to unnecessary OSR compiles with TieredStopAtLevel < 4. Webrev: http://cr.openjdk.java.net/~iveresov/7066339/webrev.00/ Thanks, igor From vladimir.kozlov at oracle.com Wed Jul 13 20:44:37 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Jul 2011 20:44:37 -0700 Subject: Request for reviews (L): 7063628: Use cbcond on T4 Message-ID: <4E1E6625.4030301@oracle.com> http://cr.openjdk.java.net/~kvn/7063628/webrev Fixed 7063628: Use cbcond on T4 Added new MacroAssembler instructions cmp_and_br() and old branch instructions are modified to use cbcond on T4 if distance is small (2K bytes). Most of the rest changes are usage of these new branch instructions in Interpreter and C1. The prototype was done by Tom and I took some of his additional fixes. The formssel.cpp change is a bug fix where the MatchNode equality test wasn't recursing so it would mistakenly return true for complex matches. Added a fake label for branches generated in temp buffer by MachNode::emit_size(), added assert into .ad files to check label. There was problem in is_in_wdisp16_range() (and in initial implementation of use_cbc()) which calls target(L) before emitting branch. Non-bound (forward branch) labels record current pc() as a branch address and later try to patch instruction (which could be 'cmp') at that address. Removed unused code in check_klass_subtype_fast_path(). Modified vm_version string: has_ prefix is removed and only v8 or v9 will be printed as well only niagara_plus or niagara. Tested on T4 with CTW, nsk, VM and java invoke regression tests. From christian.thalinger at oracle.com Thu Jul 14 06:24:28 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 14 Jul 2011 15:24:28 +0200 Subject: Request for reviews (L): 7063628: Use cbcond on T4 In-Reply-To: <4E1E6625.4030301@oracle.com> References: <4E1E6625.4030301@oracle.com> Message-ID: On Jul 14, 2011, at 5:44 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7063628/webrev > > Fixed 7063628: Use cbcond on T4 > > Added new MacroAssembler instructions cmp_and_br() and old branch instructions are modified to use cbcond on T4 if distance is small (2K bytes). Most of the rest changes are usage of these new branch instructions in Interpreter and C1. > > The prototype was done by Tom and I took some of his additional fixes. The formssel.cpp change is a bug fix where the MatchNode equality test wasn't recursing so it would mistakenly return true for complex matches. Added a fake label for branches generated in temp buffer by MachNode::emit_size(), added assert into .ad files to check label. > > There was problem in is_in_wdisp16_range() (and in initial implementation of use_cbc()) which calls target(L) before emitting branch. Non-bound (forward branch) labels record current pc() as a branch address and later try to patch instruction (which could be 'cmp') at that address. > > Removed unused code in check_klass_subtype_fast_path(). > > Modified vm_version string: has_ prefix is removed and only v8 or v9 will be printed as well only niagara_plus or niagara. > > Tested on T4 with CTW, nsk, VM and java invoke regression tests. src/cpu/sparc/vm/assembler_sparc.hpp: - void br_zero( Condition c, bool a, Predict p, Register s1, Label& L); + // compares register with zero (32 bit) and branches (V9 and V8 instructions) + void br_zero ( Register s1, Label& L ); Why did you remove the annul and predict argument while you left it with br_null/br_notnull? Maybe we should add default arguments for these: + void br_zero(Register s1, Label& L, bool a = false, Predict p = Assembler::pt); src/cpu/sparc/vm/assembler_sparc.cpp: - cmp(value_reg, top_reg_after_save); - br(Assembler::notEqual, false, Assembler::pn, not_same); - delayed()->nop(); + cmp_and_br(value_reg, top_reg_after_save, Assembler::notEqual, false, Assembler::pt, not_same); You changed the predict bit. Intentionally? Here too: - cmp(t1, t2); - br(Assembler::equal, false, Assembler::pt, ok); - delayed()->nop(); + cmp_and_br(t1, t2, Assembler::equal, false, Assembler::pn, ok); src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp: 2608 __ ba(*obj_is_null, false); 2609 __ delayed()->nop(); 2610 __ bind(not_null); 2611 } else { 2612 __ br_null(obj, false, Assembler::pn, *obj_is_null, false); 2613 __ delayed()->nop(); 2614 } Just a question: I guess you are using emit_delayed_nop = false here to not emit a cbcond instruction. What is the reason for this? There are also a couple of ba with a nop in the delay slot that use false. Otherwise this looks good. Nice cleanup! And thanks for enabling UseRDPCForConstantTableBase on T4s. -- Christian From vladimir.kozlov at oracle.com Thu Jul 14 09:47:20 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Jul 2011 09:47:20 -0700 Subject: Request for reviews (L): 7063628: Use cbcond on T4 In-Reply-To: References: <4E1E6625.4030301@oracle.com> Message-ID: <4E1F1D98.20809@oracle.com> Christian Thalinger wrote: > On Jul 14, 2011, at 5:44 AM, Vladimir Kozlov wrote: > > src/cpu/sparc/vm/assembler_sparc.hpp: > > - void br_zero( Condition c, bool a, Predict p, Register s1, Label& L); > + // compares register with zero (32 bit) and branches (V9 and V8 instructions) > + void br_zero ( Register s1, Label& L ); > > Why did you remove the annul and predict argument while you left it with br_null/br_notnull? Maybe we should add default arguments for these: > > + void br_zero(Register s1, Label& L, bool a = false, Predict p = Assembler::pt); In all usage cases annul was false but there were cases where predict was pn but those case had far label so I replaced them with normal code. But I agree that I should add default parameters. Done. > > > src/cpu/sparc/vm/assembler_sparc.cpp: > > - cmp(value_reg, top_reg_after_save); > - br(Assembler::notEqual, false, Assembler::pn, not_same); > - delayed()->nop(); > + cmp_and_br(value_reg, top_reg_after_save, Assembler::notEqual, false, Assembler::pt, not_same); > > You changed the predict bit. Intentionally? > > Here too: > > - cmp(t1, t2); > - br(Assembler::equal, false, Assembler::pt, ok); > - delayed()->nop(); > + cmp_and_br(t1, t2, Assembler::equal, false, Assembler::pn, ok); > copy-paste bug. Fixed. > > src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp: > > 2608 __ ba(*obj_is_null, false); > 2609 __ delayed()->nop(); > 2610 __ bind(not_null); > 2611 } else { > 2612 __ br_null(obj, false, Assembler::pn, *obj_is_null, false); > 2613 __ delayed()->nop(); > 2614 } > > Just a question: I guess you are using emit_delayed_nop = false here to not emit a cbcond instruction. What is the reason for this? There are also a couple of ba with a nop in the delay slot that use false. Correct. *obj_is_null is far label so I don't want to use cbcond. > > Otherwise this looks good. Nice cleanup! And thanks for enabling UseRDPCForConstantTableBase on T4s. > > -- Christian Thanks, Vladimir From tom.rodriguez at oracle.com Thu Jul 14 11:31:25 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 14 Jul 2011 11:31:25 -0700 Subject: Request for reviews (L): 7063628: Use cbcond on T4 In-Reply-To: <4E1E6625.4030301@oracle.com> References: <4E1E6625.4030301@oracle.com> Message-ID: <3A00B3E1-9E4F-4C49-9CDB-FD1AE7D2945D@oracle.com> assembler_sparc.hpp: If we wanted to be clever about the delay slot issue we could add an function like maybe_delayed() that would emit the instruction in a side buffer and place it in the right place for these instructions. Basically you could emit it as if it were not delayed and then move it into the delay slot if you actually have one. So instead of: __ br_null(G3_scratch, false, __ pt, skip_fixup, false); __ delayed()->ld_ptr(G5_method, in_bytes(methodOopDesc::interpreter_entry_offset()), G3_scratch); you do __ maybe_delayed()->ld_ptr(G5_method, in_bytes(methodOopDesc::interpreter_entry_offset()), G3_scratch); __ br_null(G3_scratch, false, __ pt, skip_fixup); It's a little tweaky but it would allow cbcond to be used in more places. You need some comments explaining when the instruction emits the delay slot for you. I would think this should only be done for names which are clearly not real instruction names. I don't like the extra argument that controls whether the delay slot is emitted or not. It's a bit mysterious in a casual reading. Maybe the false version should be _no_delay? I'm not sure how I'd want to this work but it seems a bit subtle at a first glance. Get rid of the emit_delayed_nop stuff in ba. It's just a confusing way to emit "br(always, false, pt, L)" so callers should just use that directly. Maybe instead of being called ba is should br_always so it's clear that it's a macro instruction. You can then leave the existing ba alone. cbc doesn't match the docs which use cbcond to refer to them generically. It's also slightly odd that the real instructions are called cwb and cxb but we don't have any way to emit those directly but I guess the generic forms take care of it. I'm not a huge fan of the instructions that take CC as an argument. I might prefer to see cwb, cxb and cb_ptr to cover the ptr_cc case but given the limited number of uses I can live with what you've done. Why did you remove the Condition argument from br_zero? It can work with the new encoding. c1_LIRAssembler_sparc.cpp: Why isn't this: ! __ ba(false, *update_done); ! __ ba(*update_done, false); __ delayed()->nop(); simply __ ba(*update_done); That actually applies to a bunch of other places too. sharedRuntime_sparc.cpp: I think the annulling here is wrong or at least meaningless. ! __ cmp_and_brx(temp_reg, G5_inline_cache_reg, Assembler::equal, true, Assembler::pt, L); __ brx(Assembler::equal, true, Assembler::pt, L); __ delayed()->nop(); cmp_and_brx shouldn't even have an annul argument. Actually none of these new macro instructions should. compile.cpp: + if (n->is_Branch() && n->as_Mach()->ideal_Opcode() != Op_Jump) { + // Fake label for branch instruction. + MacroAssembler masm(&buf); + Label fakeL; + masm.bind(fakeL); + n->as_Mach()->label_set(fakeL, 0); + } What guarantees do we get about the lifetime of the storage for fakeL since it doesn't appear to be used? I would assume that at a minimum it should be declared outside of the if. You can clean up all the "l ? (l->loc_pos() - (cbuf.insts_size() + 1)) : 0;" code in x86_*.ad after this fix too. We can even use the MacroAssembler for these instrutions now if we want to though that's probably for another day. Should labelOper::label have an assert that it's non-null when called? That would cover all the other asserts you added though I'm not sure it must be true. The overall change looks good. tom On Jul 13, 2011, at 8:44 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7063628/webrev > > Fixed 7063628: Use cbcond on T4 > > Added new MacroAssembler instructions cmp_and_br() and old branch instructions are modified to use cbcond on T4 if distance is small (2K bytes). Most of the rest changes are usage of these new branch instructions in Interpreter and C1. > > The prototype was done by Tom and I took some of his additional fixes. The formssel.cpp change is a bug fix where the MatchNode equality test wasn't recursing so it would mistakenly return true for complex matches. Added a fake label for branches generated in temp buffer by MachNode::emit_size(), added assert into .ad files to check label. > > There was problem in is_in_wdisp16_range() (and in initial implementation of use_cbc()) which calls target(L) before emitting branch. Non-bound (forward branch) labels record current pc() as a branch address and later try to patch instruction (which could be 'cmp') at that address. > > Removed unused code in check_klass_subtype_fast_path(). > > Modified vm_version string: has_ prefix is removed and only v8 or v9 will be printed as well only niagara_plus or niagara. > > Tested on T4 with CTW, nsk, VM and java invoke regression tests. From tom.rodriguez at oracle.com Thu Jul 14 11:52:00 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 14 Jul 2011 11:52:00 -0700 Subject: Request for reviews (L): 7063628: Use cbcond on T4 In-Reply-To: <3A00B3E1-9E4F-4C49-9CDB-FD1AE7D2945D@oracle.com> References: <4E1E6625.4030301@oracle.com> <3A00B3E1-9E4F-4C49-9CDB-FD1AE7D2945D@oracle.com> Message-ID: <4F6AE0D3-5EF6-4F7E-B158-57F21C7AF8AF@oracle.com> > > compile.cpp: > > + if (n->is_Branch() && n->as_Mach()->ideal_Opcode() != Op_Jump) { > + // Fake label for branch instruction. > + MacroAssembler masm(&buf); > + Label fakeL; > + masm.bind(fakeL); > + n->as_Mach()->label_set(fakeL, 0); > + } The label be cleared after doing the emit too so we don't end up with garbage in there. tom > > What guarantees do we get about the lifetime of the storage for fakeL since it doesn't appear to be used? I would assume that at a minimum it should be declared outside of the if. > > You can clean up all the "l ? (l->loc_pos() - (cbuf.insts_size() + 1)) : 0;" code in x86_*.ad after this fix too. We can even use the MacroAssembler for these instrutions now if we want to though that's probably for another day. > > Should labelOper::label have an assert that it's non-null when called? That would cover all the other asserts you added though I'm not sure it must be true. > > The overall change looks good. > > tom > > > On Jul 13, 2011, at 8:44 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7063628/webrev >> >> Fixed 7063628: Use cbcond on T4 >> >> Added new MacroAssembler instructions cmp_and_br() and old branch instructions are modified to use cbcond on T4 if distance is small (2K bytes). Most of the rest changes are usage of these new branch instructions in Interpreter and C1. >> >> The prototype was done by Tom and I took some of his additional fixes. The formssel.cpp change is a bug fix where the MatchNode equality test wasn't recursing so it would mistakenly return true for complex matches. Added a fake label for branches generated in temp buffer by MachNode::emit_size(), added assert into .ad files to check label. >> >> There was problem in is_in_wdisp16_range() (and in initial implementation of use_cbc()) which calls target(L) before emitting branch. Non-bound (forward branch) labels record current pc() as a branch address and later try to patch instruction (which could be 'cmp') at that address. >> >> Removed unused code in check_klass_subtype_fast_path(). >> >> Modified vm_version string: has_ prefix is removed and only v8 or v9 will be printed as well only niagara_plus or niagara. >> >> Tested on T4 with CTW, nsk, VM and java invoke regression tests. > From vladimir.kozlov at oracle.com Thu Jul 14 12:01:34 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Jul 2011 12:01:34 -0700 Subject: Request for reviews (S): 7067288: compiler regression test Test7052494 timeouts with client VM Message-ID: <4E1F3D0E.60002@oracle.com> http://cr.openjdk.java.net/~kvn/7067288/webrev Fixed 7067288: compiler regression test Test7052494 timeouts with client VM Test7052494.java has 2 test methods test5() and test6() which check empty loops compilation with rolling through MAXINT and MININT. Client VM does not eliminate such loops and as result the execution takes very long time. Test should be modified to reduce number of iterations in test5() and test6(). From tom.rodriguez at oracle.com Thu Jul 14 12:42:50 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 14 Jul 2011 12:42:50 -0700 Subject: request(S): 7066339: Tiered: policy should make consistent decisions about osr levels In-Reply-To: <4E1E4B0E.5080201@oracle.com> References: <4E1E4B0E.5080201@oracle.com> Message-ID: <777AE292-1046-4A7D-A22A-14B85A3CFC9E@oracle.com> Looks ok. tom On Jul 13, 2011, at 6:49 PM, Igor Veresov wrote: > After my fix for 7058689 it is possible that the AdvancedThresholdPolicy will make a different decision as to what compilation level for osr is appropriate in loop_event() and call_event() from what happens in method_back_branch_event(). In method_back_branch_event() in case the OSR compilation level is CompLevel_limited_profile we change it to CompLevel_full_profile but we don't do the same in call_event() and loop_event() to determine whether the existing OSR methods are current. The solution would be to move this level fixup in form of disabling the tier 3 delay feedback in common() for OSRs. > > There was also bad interaction between the in-queue level change optimization with TieredStopAtLevel option set to 3, which caused compilation loops between level 2 and 3. Now it will be disabled if TieredStopAtLevel < 4. > > Also moved handling of TieredStopAtLevel to common(), because when it was in compile() it could lead to unnecessary OSR compiles with TieredStopAtLevel < 4. > > Webrev: http://cr.openjdk.java.net/~iveresov/7066339/webrev.00/ > > Thanks, > igor From tom.rodriguez at oracle.com Thu Jul 14 12:45:51 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 14 Jul 2011 12:45:51 -0700 Subject: review for 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries In-Reply-To: <2F57587E-3A3B-4F08-9A13-618364ED4810@oracle.com> References: <562F7E5C-4EA6-42CE-8164-BB932CAA15B0@oracle.com> <9F0E6F0D-B508-4F78-91DF-4FBCA49BB285@oracle.com> <840A5AEB-221C-498F-9FB7-83B0F826E71E@oracle.com> <2F57587E-3A3B-4F08-9A13-618364ED4810@oracle.com> Message-ID: On Jul 12, 2011, at 7:01 PM, John Rose wrote: > On Jul 12, 2011, at 6:05 PM, Tom Rodriguez wrote: > >> >> Yes that was required for it to pass. Is that unexpected? This code has no parallel in the C++ code. > > Yes, I'm surprised that somebody is making a reference to a CONSTANT_Methodref from something related to ldc or a bootstrap method specifier (or some other constant-loading construct). I think I added that check during my testing before I'd worked out all the constant pool index issues. Now that they are resolved I removed that check and reran my tests and everything looks fine. Thanks for catching it. > >>> >>> >>> The rest of it looks fine. >> >> Thanks. >> >>> >>> Some of the new Java code it resembles the corresponding C++ code, in that it seems like code that should be distrusted until it is fully exercised by tests. >> >> What are you saying? > > I'm saying that it's fine, but since I did not mentally prove the change correct (which is possible sometimes), I'm relying on the testing to catch errors. I see. I really only changes places that were shown to be broken by testing so I think it's all been tested. That's part of the reason that I wanted it to look as close as possible to the C++ code so that we can assume correctness by equivalence. Thanks for the review. tom > > -- John From tom.rodriguez at oracle.com Thu Jul 14 12:49:38 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 14 Jul 2011 12:49:38 -0700 Subject: review for 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods In-Reply-To: <9E4737BC-6971-42B4-B9B4-C5BC9A2FCA1C@oracle.com> References: <6FC4D868-6EC6-4DE5-92C4-A55B42AF3CFE@oracle.com> <25A1B825-BC91-4F1E-B7B1-C8E507F8EA34@oracle.com> <839E75F4-67A3-4C3B-AD06-9985EB762357@oracle.com> <9E4737BC-6971-42B4-B9B4-C5BC9A2FCA1C@oracle.com> Message-ID: <8D08FBBE-B796-45C1-A8DC-626531ABD5C2@oracle.com> On Jul 12, 2011, at 9:38 AM, Christian Thalinger wrote: > On Jul 11, 2011, at 5:43 PM, Christian Thalinger wrote: >> On Jul 9, 2011, at 12:21 AM, Tom Rodriguez wrote: >>> Coleen point out that it's confusing to reuse the name jump_from_interpreted since we're not really in the interpreter. I've changed it to jump_from_method_handle and left that note that it parallels jump_from_interpreted. >> >> This looks good. Although I'm a little worried about the raise_exception changes on SPARC. In the past I had various crashes with versions that used the interpreter stack to pass the arguments. That's why I changed it to the simpler, more reliable current version (which uses the compiler calling convention). Maybe I got adjust_SP_and_Gargs_down_by_slots right and there is no problem now. >> >> Just to be sure I'm currently running JRuby's benchmarks (my memory tells me that I had the crashes with these benchmarks) on two different SPARC boxes. I'll let you know when they are finished. > > Sorry, it took a little longer to run them because one of the benchmarks (bench_full_load_path.rb) does not finish (it hangs around doing nothing). Anyway, all others look good. Thanks. I fixed the interp_only check to look more like the original code and reran the mlvm tests and they all look good. tom > > -- Christian From tom.rodriguez at oracle.com Thu Jul 14 12:51:02 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 14 Jul 2011 12:51:02 -0700 Subject: review for 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods In-Reply-To: <4E1811AA.3020700@oracle.com> References: <6FC4D868-6EC6-4DE5-92C4-A55B42AF3CFE@oracle.com> <4E1811AA.3020700@oracle.com> Message-ID: On Jul 9, 2011, at 1:30 AM, Dmitry Samersoff wrote: > Tom, > > methodHandles_x86.cpp: > > Do we need const and assignment here? > > 1185 const Register rax_pc = rax; > 1186 __ pop(rax_pc); // caller PC It's just a convenience name for a saved value. It was wrong before and I fixed it. Are you against that style? > > > Otherwise looks good for me. Thanks. tom > > -Dmitry > > On 2011-07-09 00:10, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6990212 >> 154 lines changed: 117 ins; 19 del; 18 mod; 5215 unchg >> >> 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods >> Summary: check for single stepping when dispatching invokes from method handles >> Reviewed-by: >> >> Single stepping and method entry events requires some machinery in the >> interpreter to make sure that we never jump into compiled code but the >> method handle invoke path doesn't have that code. The fix is to >> reintroduce the required check and dispatch to the interpreted entry >> in that case. Tested with failing test cases from report plus a >> simple test case to exercise the MH raiseException path since I had to >> rewrite the arugment passing there. >> > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... From tom.rodriguez at oracle.com Thu Jul 14 13:02:37 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 14 Jul 2011 13:02:37 -0700 Subject: Request for reviews (S): 7067288: compiler regression test Test7052494 timeouts with client VM In-Reply-To: <4E1F3D0E.60002@oracle.com> References: <4E1F3D0E.60002@oracle.com> Message-ID: <6A14475C-4A7B-4558-BC4A-3FDFE9B31A5C@oracle.com> Looks good. tom On Jul 14, 2011, at 12:01 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7067288/webrev > > Fixed 7067288: compiler regression test Test7052494 timeouts with client VM > > Test7052494.java has 2 test methods test5() and test6() which check empty loops compilation with rolling through MAXINT and MININT. Client VM does not eliminate such loops and as result the execution takes very long time. > > Test should be modified to reduce number of iterations in test5() and test6(). From igor.veresov at oracle.com Thu Jul 14 13:04:32 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 14 Jul 2011 13:04:32 -0700 Subject: request(S): 7066339: Tiered: policy should make consistent decisions about osr levels In-Reply-To: <777AE292-1046-4A7D-A22A-14B85A3CFC9E@oracle.com> References: <4E1E4B0E.5080201@oracle.com> <777AE292-1046-4A7D-A22A-14B85A3CFC9E@oracle.com> Message-ID: <4E1F4BD0.1000706@oracle.com> Thanks Vladimir and Tom! igor On 7/14/11 12:42 PM, Tom Rodriguez wrote: > Looks ok. > > tom > > On Jul 13, 2011, at 6:49 PM, Igor Veresov wrote: > >> After my fix for 7058689 it is possible that the AdvancedThresholdPolicy will make a different decision as to what compilation level for osr is appropriate in loop_event() and call_event() from what happens in method_back_branch_event(). In method_back_branch_event() in case the OSR compilation level is CompLevel_limited_profile we change it to CompLevel_full_profile but we don't do the same in call_event() and loop_event() to determine whether the existing OSR methods are current. The solution would be to move this level fixup in form of disabling the tier 3 delay feedback in common() for OSRs. >> >> There was also bad interaction between the in-queue level change optimization with TieredStopAtLevel option set to 3, which caused compilation loops between level 2 and 3. Now it will be disabled if TieredStopAtLevel< 4. >> >> Also moved handling of TieredStopAtLevel to common(), because when it was in compile() it could lead to unnecessary OSR compiles with TieredStopAtLevel< 4. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/7066339/webrev.00/ >> >> Thanks, >> igor > From igor.veresov at oracle.com Thu Jul 14 13:31:26 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 14 Jul 2011 13:31:26 -0700 Subject: Request for reviews (S): 7067288: compiler regression test Test7052494 timeouts with client VM In-Reply-To: <4E1F3D0E.60002@oracle.com> References: <4E1F3D0E.60002@oracle.com> Message-ID: <4E1F521E.3070600@oracle.com> Looks ok. igor On 7/14/11 12:01 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7067288/webrev > > Fixed 7067288: compiler regression test Test7052494 timeouts with client VM > > Test7052494.java has 2 test methods test5() and test6() which check > empty loops compilation with rolling through MAXINT and MININT. Client > VM does not eliminate such loops and as result the execution takes very > long time. > > Test should be modified to reduce number of iterations in test5() and > test6(). From vladimir.kozlov at oracle.com Thu Jul 14 14:39:05 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Jul 2011 14:39:05 -0700 Subject: Request for reviews (S): 7067288: compiler regression test Test7052494 timeouts with client VM In-Reply-To: <6A14475C-4A7B-4558-BC4A-3FDFE9B31A5C@oracle.com> References: <4E1F3D0E.60002@oracle.com> <6A14475C-4A7B-4558-BC4A-3FDFE9B31A5C@oracle.com> Message-ID: <4E1F61F9.8030707@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Jul 14, 2011, at 12:01 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7067288/webrev >> >> Fixed 7067288: compiler regression test Test7052494 timeouts with client VM >> >> Test7052494.java has 2 test methods test5() and test6() which check empty loops compilation with rolling through MAXINT and MININT. Client VM does not eliminate such loops and as result the execution takes very long time. >> >> Test should be modified to reduce number of iterations in test5() and test6(). > From vladimir.kozlov at oracle.com Thu Jul 14 15:27:51 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Jul 2011 15:27:51 -0700 Subject: Request for reviews (L): 7063628: Use cbcond on T4 In-Reply-To: <4F6AE0D3-5EF6-4F7E-B158-57F21C7AF8AF@oracle.com> References: <4E1E6625.4030301@oracle.com> <3A00B3E1-9E4F-4C49-9CDB-FD1AE7D2945D@oracle.com> <4F6AE0D3-5EF6-4F7E-B158-57F21C7AF8AF@oracle.com> Message-ID: <4E1F6D67.2090305@oracle.com> You are absolutely right. I will change the code to this: // Do the emission. + // Fake label for branch instructions. + MacroAssembler masm(&buf); + Label fakeL; + masm.bind(fakeL); + if (n->is_Branch() && n->as_Mach()->ideal_Opcode() != Op_Jump) { + n->as_Mach()->label_set(fakeL, 0); + } n->emit(buf, this->regalloc()); And I will move the assert into labelOper::label(). It works on x86 and sparc so I will remove asserts I added and I will cleanup "l ? (l->loc_pos()". Thanks, Vladimir Tom Rodriguez wrote: >> compile.cpp: >> >> + if (n->is_Branch() && n->as_Mach()->ideal_Opcode() != Op_Jump) { >> + // Fake label for branch instruction. >> + MacroAssembler masm(&buf); >> + Label fakeL; >> + masm.bind(fakeL); >> + n->as_Mach()->label_set(fakeL, 0); >> + } > > The label be cleared after doing the emit too so we don't end up with garbage in there. > > tom > >> What guarantees do we get about the lifetime of the storage for fakeL since it doesn't appear to be used? I would assume that at a minimum it should be declared outside of the if. >> >> You can clean up all the "l ? (l->loc_pos() - (cbuf.insts_size() + 1)) : 0;" code in x86_*.ad after this fix too. We can even use the MacroAssembler for these instrutions now if we want to though that's probably for another day. >> >> Should labelOper::label have an assert that it's non-null when called? That would cover all the other asserts you added though I'm not sure it must be true. >> >> The overall change looks good. >> >> tom >> >> >> On Jul 13, 2011, at 8:44 PM, Vladimir Kozlov wrote: >> >>> http://cr.openjdk.java.net/~kvn/7063628/webrev >>> >>> Fixed 7063628: Use cbcond on T4 >>> >>> Added new MacroAssembler instructions cmp_and_br() and old branch instructions are modified to use cbcond on T4 if distance is small (2K bytes). Most of the rest changes are usage of these new branch instructions in Interpreter and C1. >>> >>> The prototype was done by Tom and I took some of his additional fixes. The formssel.cpp change is a bug fix where the MatchNode equality test wasn't recursing so it would mistakenly return true for complex matches. Added a fake label for branches generated in temp buffer by MachNode::emit_size(), added assert into .ad files to check label. >>> >>> There was problem in is_in_wdisp16_range() (and in initial implementation of use_cbc()) which calls target(L) before emitting branch. Non-bound (forward branch) labels record current pc() as a branch address and later try to patch instruction (which could be 'cmp') at that address. >>> >>> Removed unused code in check_klass_subtype_fast_path(). >>> >>> Modified vm_version string: has_ prefix is removed and only v8 or v9 will be printed as well only niagara_plus or niagara. >>> >>> Tested on T4 with CTW, nsk, VM and java invoke regression tests. > From vladimir.kozlov at oracle.com Thu Jul 14 16:43:17 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Jul 2011 16:43:17 -0700 Subject: Request for reviews (L): 7063628: Use cbcond on T4 In-Reply-To: <3A00B3E1-9E4F-4C49-9CDB-FD1AE7D2945D@oracle.com> References: <4E1E6625.4030301@oracle.com> <3A00B3E1-9E4F-4C49-9CDB-FD1AE7D2945D@oracle.com> Message-ID: <4E1F7F15.3040501@oracle.com> Thank you, Tom Tom Rodriguez wrote: > assembler_sparc.hpp: > > If we wanted to be clever about the delay slot issue we could add an function like maybe_delayed() that would emit the instruction in a side buffer and place it in the right place for these instructions. Basically you could emit it as if it were not delayed and then move it into the delay slot if you actually have one. So instead of: > > __ br_null(G3_scratch, false, __ pt, skip_fixup, false); > __ delayed()->ld_ptr(G5_method, in_bytes(methodOopDesc::interpreter_entry_offset()), G3_scratch); > > you do > > __ maybe_delayed()->ld_ptr(G5_method, in_bytes(methodOopDesc::interpreter_entry_offset()), G3_scratch); > __ br_null(G3_scratch, false, __ pt, skip_fixup); > > It's a little tweaky but it would allow cbcond to be used in more places. I will file RFE for that. > > You need some comments explaining when the instruction emits the delay slot for you. I would think this should only be done for names which are clearly not real instruction names. I don't like the extra argument that controls whether the delay slot is emitted or not. It's a bit mysterious in a casual reading. Maybe the false version should be _no_delay? I'm not sure how I'd want to this work but it seems a bit subtle at a first glance. Originally I thought to add second version of macroassembler branch instructions with suffix _short. Then old instructions will stay the same and _short will generate cbcond or branch with delayed nop. But then I decided to go with passing additional flag. But I see what you mean, may be I should go to the original idea. > > Get rid of the emit_delayed_nop stuff in ba. It's just a confusing way to emit "br(always, false, pt, L)" so callers should just use that directly. Maybe instead of being called ba is should br_always so it's clear that it's a macro instruction. You can then leave the existing ba alone. I am also using emit_delayed_nop flag to control when cbcond could be emited. For the example bellow *update_done is in far distance but it is forward branch and during ba() generation the distance is unknown. In such case the distance set to 0 and cbcond will be emitted. I will leave the original ba and add new ba_short. > > cbc doesn't match the docs which use cbcond to refer to them generically. It's also slightly odd that the real instructions are called cwb and cxb but we don't have any way to emit those directly but I guess the generic forms take care of it. I'm not a huge fan of the instructions that take CC as an argument. I might prefer to see cwb, cxb and cb_ptr to cover the ptr_cc case but given the limited number of uses I can live with what you've done. > I will rename cbc to cbcond. > Why did you remove the Condition argument from br_zero? It can work with the new encoding. I think it is confusing to have name br_zero and have conditions. And in most cases it was indeed check for zero. With condition we need different name, I think: cmp_zero_and_br? > > c1_LIRAssembler_sparc.cpp: > > Why isn't this: > > ! __ ba(false, *update_done); > ! __ ba(*update_done, false); > __ delayed()->nop(); > > simply > > __ ba(*update_done); > > That actually applies to a bunch of other places too. I answered it above: emit_delayed_nop flag controls when cbcond is emited. > > sharedRuntime_sparc.cpp: > > I think the annulling here is wrong or at least meaningless. > > ! __ cmp_and_brx(temp_reg, G5_inline_cache_reg, Assembler::equal, true, Assembler::pt, L); > __ brx(Assembler::equal, true, Assembler::pt, L); > __ delayed()->nop(); Why? This code trys to not execute nop if branch is not taken. > > cmp_and_brx shouldn't even have an annul argument. Actually none of these new macro instructions should. Agree. Thanks, Vladimir > > compile.cpp: > > + if (n->is_Branch() && n->as_Mach()->ideal_Opcode() != Op_Jump) { > + // Fake label for branch instruction. > + MacroAssembler masm(&buf); > + Label fakeL; > + masm.bind(fakeL); > + n->as_Mach()->label_set(fakeL, 0); > + } > > What guarantees do we get about the lifetime of the storage for fakeL since it doesn't appear to be used? I would assume that at a minimum it should be declared outside of the if. > > You can clean up all the "l ? (l->loc_pos() - (cbuf.insts_size() + 1)) : 0;" code in x86_*.ad after this fix too. We can even use the MacroAssembler for these instrutions now if we want to though that's probably for another day. > > Should labelOper::label have an assert that it's non-null when called? That would cover all the other asserts you added though I'm not sure it must be true. > > The overall change looks good. > > tom > > > On Jul 13, 2011, at 8:44 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7063628/webrev >> >> Fixed 7063628: Use cbcond on T4 >> >> Added new MacroAssembler instructions cmp_and_br() and old branch instructions are modified to use cbcond on T4 if distance is small (2K bytes). Most of the rest changes are usage of these new branch instructions in Interpreter and C1. >> >> The prototype was done by Tom and I took some of his additional fixes. The formssel.cpp change is a bug fix where the MatchNode equality test wasn't recursing so it would mistakenly return true for complex matches. Added a fake label for branches generated in temp buffer by MachNode::emit_size(), added assert into .ad files to check label. >> >> There was problem in is_in_wdisp16_range() (and in initial implementation of use_cbc()) which calls target(L) before emitting branch. Non-bound (forward branch) labels record current pc() as a branch address and later try to patch instruction (which could be 'cmp') at that address. >> >> Removed unused code in check_klass_subtype_fast_path(). >> >> Modified vm_version string: has_ prefix is removed and only v8 or v9 will be printed as well only niagara_plus or niagara. >> >> Tested on T4 with CTW, nsk, VM and java invoke regression tests. > From tom.rodriguez at oracle.com Thu Jul 14 16:59:29 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 14 Jul 2011 16:59:29 -0700 Subject: Request for reviews (L): 7063628: Use cbcond on T4 In-Reply-To: <4E1F7F15.3040501@oracle.com> References: <4E1E6625.4030301@oracle.com> <3A00B3E1-9E4F-4C49-9CDB-FD1AE7D2945D@oracle.com> <4E1F7F15.3040501@oracle.com> Message-ID: On Jul 14, 2011, at 4:43 PM, Vladimir Kozlov wrote: > Thank you, Tom > > Tom Rodriguez wrote: >> assembler_sparc.hpp: >> If we wanted to be clever about the delay slot issue we could add an function like maybe_delayed() that would emit the instruction in a side buffer and place it in the right place for these instructions. Basically you could emit it as if it were not delayed and then move it into the delay slot if you actually have one. So instead of: >> __ br_null(G3_scratch, false, __ pt, skip_fixup, false); >> __ delayed()->ld_ptr(G5_method, in_bytes(methodOopDesc::interpreter_entry_offset()), G3_scratch); >> you do __ maybe_delayed()->ld_ptr(G5_method, in_bytes(methodOopDesc::interpreter_entry_offset()), G3_scratch); >> __ br_null(G3_scratch, false, __ pt, skip_fixup); >> It's a little tweaky but it would allow cbcond to be used in more places. > > I will file RFE for that. > >> You need some comments explaining when the instruction emits the delay slot for you. I would think this should only be done for names which are clearly not real instruction names. I don't like the extra argument that controls whether the delay slot is emitted or not. It's a bit mysterious in a casual reading. Maybe the false version should be _no_delay? I'm not sure how I'd want to this work but it seems a bit subtle at a first glance. > > Originally I thought to add second version of macroassembler branch instructions with suffix _short. Then old instructions will stay the same and _short will generate cbcond or branch with delayed nop. But then I decided to go with passing additional flag. But I see what you mean, may be I should go to the original idea. I think being a little more explicit is better. > >> Get rid of the emit_delayed_nop stuff in ba. It's just a confusing way to emit "br(always, false, pt, L)" so callers should just use that directly. Maybe instead of being called ba is should br_always so it's clear that it's a macro instruction. You can then leave the existing ba alone. > > I am also using emit_delayed_nop flag to control when cbcond could be emited. For the example bellow *update_done is in far distance but it is forward branch and during ba() generation the distance is unknown. In such case the distance set to 0 and cbcond will be emitted. > > I will leave the original ba and add new ba_short. Oh I see. Yes, a ba_short to parallel jccb would make sense. Is there benefit to a short form in other cases? > >> cbc doesn't match the docs which use cbcond to refer to them generically. It's also slightly odd that the real instructions are called cwb and cxb but we don't have any way to emit those directly but I guess the generic forms take care of it. I'm not a huge fan of the instructions that take CC as an argument. I might prefer to see cwb, cxb and cb_ptr to cover the ptr_cc case but given the limited number of uses I can live with what you've done. > > I will rename cbc to cbcond. > >> Why did you remove the Condition argument from br_zero? It can work with the new encoding. > > I think it is confusing to have name br_zero and have conditions. And in most cases it was indeed check for zero. With condition we need different name, I think: cmp_zero_and_br? I guess it was confusingly named. cmp_zero_and_br sounds good. > >> c1_LIRAssembler_sparc.cpp: >> Why isn't this: >> ! __ ba(false, *update_done); >> ! __ ba(*update_done, false); >> __ delayed()->nop(); >> simply >> __ ba(*update_done); >> That actually applies to a bunch of other places too. > > I answered it above: emit_delayed_nop flag controls when cbcond is emited. > >> sharedRuntime_sparc.cpp: >> I think the annulling here is wrong or at least meaningless. ! __ cmp_and_brx(temp_reg, G5_inline_cache_reg, Assembler::equal, true, Assembler::pt, L); >> __ brx(Assembler::equal, true, Assembler::pt, L); >> __ delayed()->nop(); > > Why? This code trys to not execute nop if branch is not taken. Annulling doesn't skip the execution, it just keeps the side effects from occurring. In either case it's meaningless when applied to a nop. It was probably just a copy/paste from some other place where it was meaningful. tom > >> cmp_and_brx shouldn't even have an annul argument. Actually none of these new macro instructions should. > > Agree. > > Thanks, > Vladimir > >> compile.cpp: >> + if (n->is_Branch() && n->as_Mach()->ideal_Opcode() != Op_Jump) { >> + // Fake label for branch instruction. >> + MacroAssembler masm(&buf); >> + Label fakeL; >> + masm.bind(fakeL); >> + n->as_Mach()->label_set(fakeL, 0); >> + } >> What guarantees do we get about the lifetime of the storage for fakeL since it doesn't appear to be used? I would assume that at a minimum it should be declared outside of the if. >> You can clean up all the "l ? (l->loc_pos() - (cbuf.insts_size() + 1)) : 0;" code in x86_*.ad after this fix too. We can even use the MacroAssembler for these instrutions now if we want to though that's probably for another day. >> Should labelOper::label have an assert that it's non-null when called? That would cover all the other asserts you added though I'm not sure it must be true. >> The overall change looks good. >> tom >> On Jul 13, 2011, at 8:44 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7063628/webrev >>> >>> Fixed 7063628: Use cbcond on T4 >>> >>> Added new MacroAssembler instructions cmp_and_br() and old branch instructions are modified to use cbcond on T4 if distance is small (2K bytes). Most of the rest changes are usage of these new branch instructions in Interpreter and C1. >>> >>> The prototype was done by Tom and I took some of his additional fixes. The formssel.cpp change is a bug fix where the MatchNode equality test wasn't recursing so it would mistakenly return true for complex matches. Added a fake label for branches generated in temp buffer by MachNode::emit_size(), added assert into .ad files to check label. >>> >>> There was problem in is_in_wdisp16_range() (and in initial implementation of use_cbc()) which calls target(L) before emitting branch. Non-bound (forward branch) labels record current pc() as a branch address and later try to patch instruction (which could be 'cmp') at that address. >>> >>> Removed unused code in check_klass_subtype_fast_path(). >>> >>> Modified vm_version string: has_ prefix is removed and only v8 or v9 will be printed as well only niagara_plus or niagara. >>> >>> Tested on T4 with CTW, nsk, VM and java invoke regression tests. From vladimir.kozlov at oracle.com Thu Jul 14 17:56:15 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 15 Jul 2011 00:56:15 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7067288: compiler regression test Test7052494 timeouts with client VM Message-ID: <20110715005619.A440647433@hg.openjdk.java.net> Changeset: 3fbb609d9e96 Author: kvn Date: 2011-07-14 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3fbb609d9e96 7067288: compiler regression test Test7052494 timeouts with client VM Summary: Test is modified to reduce number of iterations in test5() and test6(). Reviewed-by: never, iveresov ! test/compiler/7052494/Test7052494.java From ChrisPhi at LGonQn.Org Fri Jul 15 07:08:10 2011 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Fri, 15 Jul 2011 10:08:10 -0400 Subject: Review Request: zero/shark doesn't build after b147-fcs In-Reply-To: <4E1C5E4F.1080307@zafena.se> References: <4E1C5E4F.1080307@zafena.se> Message-ID: <4E2049CA.8060506@LGonQn.Org> Hi The following webrev's are for recent issues for zero/shark that stop it from building: http://lgonqn.org/temp/ChrisPhi/webrev-frame_zero.cpp-describe_pd_missing/ http://lgonqn.org/temp/ChrisPhi/webrev-sharedRuntime_zero.cpp-needs-rework-after-indy-reorg/ http://lgonqn.org/temp/ChrisPhi/webrev-sharkContext.hpp-typo-in-assert/ http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing/ The fixes from Xerxes R?nby , zero-methodHandle 7009923-regression and IA32 Hotspot FTBFS 7009309-regression are als required. These allow zero/shark to compile in product or debug for b147/fcs. There are still significant issues in shark beyond this and zero doesn't pass the invoke dynamic tests. Chris From gbenson at redhat.com Fri Jul 15 07:51:28 2011 From: gbenson at redhat.com (Gary Benson) Date: Fri, 15 Jul 2011 15:51:28 +0100 Subject: Review Request: zero/shark doesn't build after b147-fcs In-Reply-To: <4E2049CA.8060506@LGonQn.Org> References: <4E1C5E4F.1080307@zafena.se> <4E2049CA.8060506@LGonQn.Org> Message-ID: <20110715145127.GA3311@redhat.com> Chris Phillips wrote: > http://lgonqn.org/temp/ChrisPhi/webrev-sharkContext.hpp-typo-in-assert/ Nice catch :) > http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing/ You could probably make adapter_code_size be 0, or something small 1ike 1*k. Nothing will presumably be generated into these buffers after all? Cheers, Gary -- http://gbenson.net/ From tom.rodriguez at oracle.com Fri Jul 15 18:25:15 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 16 Jul 2011 01:25:15 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods Message-ID: <20110716012519.2CFC34747C@hg.openjdk.java.net> Changeset: 341a57af9b0a Author: never Date: 2011-07-15 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/341a57af9b0a 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods Summary: check for single stepping when dispatching invokes from method handles Reviewed-by: coleenp, twisti, kvn, dsamersoff ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp + test/compiler/6990212/Test6990212.java From vladimir.kozlov at oracle.com Fri Jul 15 19:21:33 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Jul 2011 19:21:33 -0700 Subject: Request for reviews (L): 7063628: Use cbcond on T4 In-Reply-To: References: <4E1E6625.4030301@oracle.com> <3A00B3E1-9E4F-4C49-9CDB-FD1AE7D2945D@oracle.com> <4E1F7F15.3040501@oracle.com> Message-ID: <4E20F5AD.3090406@oracle.com> I updated changes based on suggestions: http://cr.openjdk.java.net/~kvn/7063628/webrev vs previous webrev: http://cr.openjdk.java.net/~kvn/7063628/webrev.diff Restored original code for macroassembler branch instructions. Added new version of these instructions for short distance which can use cbcond. They have _short name suffix to indicate that. New instructions generate nop in delay slot if cbcond can't be used and they don't have annul parameter (not needed). Use original instructions if not nop instruction is needed in delay slot, I filed RFE 7067794 which will allow to avoid it. br_zero() code is restored and it is renamed to cmp_zero_and_br(). For short distance cmp_and_br_short(reg, 0, equal, pt, L) is used instead of br_zero(). Restored original code in br_on_reg_cond() instruction since in most cases it has filled delay slot. And I filed RFE 7066841 to replace this instruction since I think it is not safe. Thanks, Vladimir Tom Rodriguez wrote: > On Jul 14, 2011, at 4:43 PM, Vladimir Kozlov wrote: > >> Thank you, Tom >> >> Tom Rodriguez wrote: >>> assembler_sparc.hpp: >>> If we wanted to be clever about the delay slot issue we could add an function like maybe_delayed() that would emit the instruction in a side buffer and place it in the right place for these instructions. Basically you could emit it as if it were not delayed and then move it into the delay slot if you actually have one. So instead of: >>> __ br_null(G3_scratch, false, __ pt, skip_fixup, false); >>> __ delayed()->ld_ptr(G5_method, in_bytes(methodOopDesc::interpreter_entry_offset()), G3_scratch); >>> you do __ maybe_delayed()->ld_ptr(G5_method, in_bytes(methodOopDesc::interpreter_entry_offset()), G3_scratch); >>> __ br_null(G3_scratch, false, __ pt, skip_fixup); >>> It's a little tweaky but it would allow cbcond to be used in more places. >> I will file RFE for that. >> >>> You need some comments explaining when the instruction emits the delay slot for you. I would think this should only be done for names which are clearly not real instruction names. I don't like the extra argument that controls whether the delay slot is emitted or not. It's a bit mysterious in a casual reading. Maybe the false version should be _no_delay? I'm not sure how I'd want to this work but it seems a bit subtle at a first glance. >> Originally I thought to add second version of macroassembler branch instructions with suffix _short. Then old instructions will stay the same and _short will generate cbcond or branch with delayed nop. But then I decided to go with passing additional flag. But I see what you mean, may be I should go to the original idea. > > I think being a little more explicit is better. > >>> Get rid of the emit_delayed_nop stuff in ba. It's just a confusing way to emit "br(always, false, pt, L)" so callers should just use that directly. Maybe instead of being called ba is should br_always so it's clear that it's a macro instruction. You can then leave the existing ba alone. >> I am also using emit_delayed_nop flag to control when cbcond could be emited. For the example bellow *update_done is in far distance but it is forward branch and during ba() generation the distance is unknown. In such case the distance set to 0 and cbcond will be emitted. >> >> I will leave the original ba and add new ba_short. > > Oh I see. Yes, a ba_short to parallel jccb would make sense. Is there benefit to a short form in other cases? > >>> cbc doesn't match the docs which use cbcond to refer to them generically. It's also slightly odd that the real instructions are called cwb and cxb but we don't have any way to emit those directly but I guess the generic forms take care of it. I'm not a huge fan of the instructions that take CC as an argument. I might prefer to see cwb, cxb and cb_ptr to cover the ptr_cc case but given the limited number of uses I can live with what you've done. >> I will rename cbc to cbcond. >> >>> Why did you remove the Condition argument from br_zero? It can work with the new encoding. >> I think it is confusing to have name br_zero and have conditions. And in most cases it was indeed check for zero. With condition we need different name, I think: cmp_zero_and_br? > > I guess it was confusingly named. cmp_zero_and_br sounds good. > >>> c1_LIRAssembler_sparc.cpp: >>> Why isn't this: >>> ! __ ba(false, *update_done); >>> ! __ ba(*update_done, false); >>> __ delayed()->nop(); >>> simply >>> __ ba(*update_done); >>> That actually applies to a bunch of other places too. >> I answered it above: emit_delayed_nop flag controls when cbcond is emited. >> >>> sharedRuntime_sparc.cpp: >>> I think the annulling here is wrong or at least meaningless. ! __ cmp_and_brx(temp_reg, G5_inline_cache_reg, Assembler::equal, true, Assembler::pt, L); >>> __ brx(Assembler::equal, true, Assembler::pt, L); >>> __ delayed()->nop(); >> Why? This code trys to not execute nop if branch is not taken. > > Annulling doesn't skip the execution, it just keeps the side effects from occurring. In either case it's meaningless when applied to a nop. It was probably just a copy/paste from some other place where it was meaningful. > > tom > >>> cmp_and_brx shouldn't even have an annul argument. Actually none of these new macro instructions should. >> Agree. >> >> Thanks, >> Vladimir >> >>> compile.cpp: >>> + if (n->is_Branch() && n->as_Mach()->ideal_Opcode() != Op_Jump) { >>> + // Fake label for branch instruction. >>> + MacroAssembler masm(&buf); >>> + Label fakeL; >>> + masm.bind(fakeL); >>> + n->as_Mach()->label_set(fakeL, 0); >>> + } >>> What guarantees do we get about the lifetime of the storage for fakeL since it doesn't appear to be used? I would assume that at a minimum it should be declared outside of the if. >>> You can clean up all the "l ? (l->loc_pos() - (cbuf.insts_size() + 1)) : 0;" code in x86_*.ad after this fix too. We can even use the MacroAssembler for these instrutions now if we want to though that's probably for another day. >>> Should labelOper::label have an assert that it's non-null when called? That would cover all the other asserts you added though I'm not sure it must be true. >>> The overall change looks good. >>> tom >>> On Jul 13, 2011, at 8:44 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7063628/webrev >>>> >>>> Fixed 7063628: Use cbcond on T4 >>>> >>>> Added new MacroAssembler instructions cmp_and_br() and old branch instructions are modified to use cbcond on T4 if distance is small (2K bytes). Most of the rest changes are usage of these new branch instructions in Interpreter and C1. >>>> >>>> The prototype was done by Tom and I took some of his additional fixes. The formssel.cpp change is a bug fix where the MatchNode equality test wasn't recursing so it would mistakenly return true for complex matches. Added a fake label for branches generated in temp buffer by MachNode::emit_size(), added assert into .ad files to check label. >>>> >>>> There was problem in is_in_wdisp16_range() (and in initial implementation of use_cbc()) which calls target(L) before emitting branch. Non-bound (forward branch) labels record current pc() as a branch address and later try to patch instruction (which could be 'cmp') at that address. >>>> >>>> Removed unused code in check_klass_subtype_fast_path(). >>>> >>>> Modified vm_version string: has_ prefix is removed and only v8 or v9 will be printed as well only niagara_plus or niagara. >>>> >>>> Tested on T4 with CTW, nsk, VM and java invoke regression tests. > From john.r.rose at oracle.com Sat Jul 16 15:48:26 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 16 Jul 2011 22:48:26 +0000 Subject: hg: hsx/hotspot-comp/jdk: 3 new changesets Message-ID: <20110716224917.A3696474A9@hg.openjdk.java.net> Changeset: bfc5ec581c48 Author: jrose Date: 2011-07-16 15:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bfc5ec581c48 7058630: JSR 292 method handle proxy violates contract for Object methods Reviewed-by: never, twisti ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 668edf27e9c7 Author: jrose Date: 2011-07-16 15:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/668edf27e9c7 7058651: JSR 292 unit tests need a refresh Summary: Enhancements to unit tests. Reviewed-by: never, twisti ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/RicochetTest.java + test/java/lang/invoke/ThrowExceptionsTest.java Changeset: b42029cd1744 Author: jrose Date: 2011-07-16 15:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b42029cd1744 6983728: JSR 292 remove argument count limitations Summary: Remove workarounds and limitations from before 6939861. Reviewed-by: never ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/FilterGeneric.java - src/share/classes/java/lang/invoke/FilterOneArgument.java - src/share/classes/java/lang/invoke/FromGeneric.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java - src/share/classes/java/lang/invoke/SpreadGeneric.java - src/share/classes/java/lang/invoke/ToGeneric.java From igor.veresov at oracle.com Sun Jul 17 14:32:03 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Sun, 17 Jul 2011 14:32:03 -0700 Subject: request(S): 7066339: Tiered: policy should make consistent decisions about osr levels In-Reply-To: <4E1F4BD0.1000706@oracle.com> References: <4E1E4B0E.5080201@oracle.com> <777AE292-1046-4A7D-A22A-14B85A3CFC9E@oracle.com> <4E1F4BD0.1000706@oracle.com> Message-ID: <4E2354D3.5010405@oracle.com> I modified the fix a little bit. With -Xcomp we had inconsistent behavior with tiered and TieredStopAtLevel. Everything was compiled at level 3 regardless of TieredStopAtLevel flag value. I've added CompilationPolicy::initial_compile_level() to make it policy-dependent. Webrev: http://cr.openjdk.java.net/~iveresov/7066339/webrev.00/ Sorry for the noise. igor On 7/14/11 1:04 PM, Igor Veresov wrote: > Thanks Vladimir and Tom! > > igor > > > On 7/14/11 12:42 PM, Tom Rodriguez wrote: >> Looks ok. >> >> tom >> >> On Jul 13, 2011, at 6:49 PM, Igor Veresov wrote: >> >>> After my fix for 7058689 it is possible that the >>> AdvancedThresholdPolicy will make a different decision as to what >>> compilation level for osr is appropriate in loop_event() and >>> call_event() from what happens in method_back_branch_event(). In >>> method_back_branch_event() in case the OSR compilation level is >>> CompLevel_limited_profile we change it to CompLevel_full_profile but >>> we don't do the same in call_event() and loop_event() to determine >>> whether the existing OSR methods are current. The solution would be >>> to move this level fixup in form of disabling the tier 3 delay >>> feedback in common() for OSRs. >>> >>> There was also bad interaction between the in-queue level change >>> optimization with TieredStopAtLevel option set to 3, which caused >>> compilation loops between level 2 and 3. Now it will be disabled if >>> TieredStopAtLevel< 4. >>> >>> Also moved handling of TieredStopAtLevel to common(), because when it >>> was in compile() it could lead to unnecessary OSR compiles with >>> TieredStopAtLevel< 4. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/7066339/webrev.00/ >>> >>> Thanks, >>> igor >> > From roland.westrelin at oracle.com Tue Jul 19 03:39:34 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Jul 2011 12:39:34 +0200 Subject: proposed membar simplification in c2 Message-ID: To implement the java memory model, on a monitor operation, c2 currently adds a MemBarAcquire/MemBarRelease node after/before the monitor enter/exit. No membar instruction is emitted for these MemBarAcquire/MemBarRelease: in the ad file, Matcher::prior_fast_lock()/Matcher::post_fast_unlock() is used to detect a MemBarAcquire/MemBarRelease associated with a monitor enter/exit and to use an empty encoding. Matcher::post_fast_unlock() is broken with UseOptoBiasInlining: it never returns true. Rather than fix it, I suggest we use MemBarCPUOrder nodes instead of MemBarAcquire/MemBarRelease nodes on the monitor enter/exit code paths. That would have the same effect as MemBarAcquire/MemBarRelease with empty encodings and is straightforward. http://cr.openjdk.java.net/~roland/membar/webrev/ Roland. From vladimir.kozlov at oracle.com Tue Jul 19 10:33:55 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Jul 2011 10:33:55 -0700 Subject: proposed membar simplification in c2 In-Reply-To: References: Message-ID: <4E25C003.5030805@oracle.com> Roland, In general I like this idea since it is platform independent condition. There is code in macro.cpp which look for MemBarAcquire and MemBarRelease nodes to eliminate when eliminating locks and in memnode.cpp for scalar replaced object. And there is code in lcm.cpp which checks it also. I would suggest to add new membar nodes MemBarAcquireLock and MemBarReleaseLock instead of using MemBarCPUOrder. Related note: in .ad file we have to add opposite predicate on a second version of membar mach node, otherwise it will be always selected by DFA regardless predicate value: instruct membar_volatile() %{ match(MemBarVolatile); + predicate(!Matcher::post_store_load_barrier(n)); ins_cost(4*MEMORY_REF_COST); Vladimir Roland Westrelin wrote: > To implement the java memory model, on a monitor operation, c2 currently > adds a MemBarAcquire/MemBarRelease node after/before the monitor > enter/exit. No membar instruction is emitted for these > MemBarAcquire/MemBarRelease: in the ad file, > Matcher::prior_fast_lock()/Matcher::post_fast_unlock() is used to detect > a MemBarAcquire/MemBarRelease associated with a monitor enter/exit and > to use an empty encoding. > > Matcher::post_fast_unlock() is broken with UseOptoBiasInlining: it never > returns true. > > Rather than fix it, I suggest we use MemBarCPUOrder nodes instead of > MemBarAcquire/MemBarRelease nodes on the monitor enter/exit code paths. > That would have the same effect as MemBarAcquire/MemBarRelease with > empty encodings and is straightforward. > > http://cr.openjdk.java.net/~roland/membar/webrev/ > > Roland. From tom.rodriguez at oracle.com Wed Jul 20 09:58:03 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 20 Jul 2011 09:58:03 -0700 Subject: Request for reviews (L): 7063628: Use cbcond on T4 In-Reply-To: <4E20F5AD.3090406@oracle.com> References: <4E1E6625.4030301@oracle.com> <3A00B3E1-9E4F-4C49-9CDB-FD1AE7D2945D@oracle.com> <4E1F7F15.3040501@oracle.com> <4E20F5AD.3090406@oracle.com> Message-ID: Don't forget to clear the temporary label: + n->as_Mach()->label_set(fakeL, 0); Otherwise this looks good. tom On Jul 15, 2011, at 7:21 PM, Vladimir Kozlov wrote: > I updated changes based on suggestions: > > http://cr.openjdk.java.net/~kvn/7063628/webrev > > vs previous webrev: > > http://cr.openjdk.java.net/~kvn/7063628/webrev.diff > > Restored original code for macroassembler branch instructions. Added new version of these instructions for short distance which can use cbcond. They have _short name suffix to indicate that. New instructions generate nop in delay slot if cbcond can't be used and they don't have annul parameter (not needed). Use original instructions if not nop instruction is needed in delay slot, I filed RFE 7067794 which will allow to avoid it. > > br_zero() code is restored and it is renamed to cmp_zero_and_br(). For short distance cmp_and_br_short(reg, 0, equal, pt, L) is used instead of br_zero(). > > Restored original code in br_on_reg_cond() instruction since in most cases it has filled delay slot. And I filed RFE 7066841 to replace this instruction since I think it is not safe. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Jul 14, 2011, at 4:43 PM, Vladimir Kozlov wrote: >>> Thank you, Tom >>> >>> Tom Rodriguez wrote: >>>> assembler_sparc.hpp: >>>> If we wanted to be clever about the delay slot issue we could add an function like maybe_delayed() that would emit the instruction in a side buffer and place it in the right place for these instructions. Basically you could emit it as if it were not delayed and then move it into the delay slot if you actually have one. So instead of: >>>> __ br_null(G3_scratch, false, __ pt, skip_fixup, false); >>>> __ delayed()->ld_ptr(G5_method, in_bytes(methodOopDesc::interpreter_entry_offset()), G3_scratch); >>>> you do __ maybe_delayed()->ld_ptr(G5_method, in_bytes(methodOopDesc::interpreter_entry_offset()), G3_scratch); >>>> __ br_null(G3_scratch, false, __ pt, skip_fixup); >>>> It's a little tweaky but it would allow cbcond to be used in more places. >>> I will file RFE for that. >>> >>>> You need some comments explaining when the instruction emits the delay slot for you. I would think this should only be done for names which are clearly not real instruction names. I don't like the extra argument that controls whether the delay slot is emitted or not. It's a bit mysterious in a casual reading. Maybe the false version should be _no_delay? I'm not sure how I'd want to this work but it seems a bit subtle at a first glance. >>> Originally I thought to add second version of macroassembler branch instructions with suffix _short. Then old instructions will stay the same and _short will generate cbcond or branch with delayed nop. But then I decided to go with passing additional flag. But I see what you mean, may be I should go to the original idea. >> I think being a little more explicit is better. >>>> Get rid of the emit_delayed_nop stuff in ba. It's just a confusing way to emit "br(always, false, pt, L)" so callers should just use that directly. Maybe instead of being called ba is should br_always so it's clear that it's a macro instruction. You can then leave the existing ba alone. >>> I am also using emit_delayed_nop flag to control when cbcond could be emited. For the example bellow *update_done is in far distance but it is forward branch and during ba() generation the distance is unknown. In such case the distance set to 0 and cbcond will be emitted. >>> >>> I will leave the original ba and add new ba_short. >> Oh I see. Yes, a ba_short to parallel jccb would make sense. Is there benefit to a short form in other cases? >>>> cbc doesn't match the docs which use cbcond to refer to them generically. It's also slightly odd that the real instructions are called cwb and cxb but we don't have any way to emit those directly but I guess the generic forms take care of it. I'm not a huge fan of the instructions that take CC as an argument. I might prefer to see cwb, cxb and cb_ptr to cover the ptr_cc case but given the limited number of uses I can live with what you've done. >>> I will rename cbc to cbcond. >>> >>>> Why did you remove the Condition argument from br_zero? It can work with the new encoding. >>> I think it is confusing to have name br_zero and have conditions. And in most cases it was indeed check for zero. With condition we need different name, I think: cmp_zero_and_br? >> I guess it was confusingly named. cmp_zero_and_br sounds good. >>>> c1_LIRAssembler_sparc.cpp: >>>> Why isn't this: >>>> ! __ ba(false, *update_done); >>>> ! __ ba(*update_done, false); >>>> __ delayed()->nop(); >>>> simply >>>> __ ba(*update_done); >>>> That actually applies to a bunch of other places too. >>> I answered it above: emit_delayed_nop flag controls when cbcond is emited. >>> >>>> sharedRuntime_sparc.cpp: >>>> I think the annulling here is wrong or at least meaningless. ! __ cmp_and_brx(temp_reg, G5_inline_cache_reg, Assembler::equal, true, Assembler::pt, L); >>>> __ brx(Assembler::equal, true, Assembler::pt, L); >>>> __ delayed()->nop(); >>> Why? This code trys to not execute nop if branch is not taken. >> Annulling doesn't skip the execution, it just keeps the side effects from occurring. In either case it's meaningless when applied to a nop. It was probably just a copy/paste from some other place where it was meaningful. >> tom >>>> cmp_and_brx shouldn't even have an annul argument. Actually none of these new macro instructions should. >>> Agree. >>> >>> Thanks, >>> Vladimir >>> >>>> compile.cpp: >>>> + if (n->is_Branch() && n->as_Mach()->ideal_Opcode() != Op_Jump) { >>>> + // Fake label for branch instruction. >>>> + MacroAssembler masm(&buf); >>>> + Label fakeL; >>>> + masm.bind(fakeL); >>>> + n->as_Mach()->label_set(fakeL, 0); >>>> + } >>>> What guarantees do we get about the lifetime of the storage for fakeL since it doesn't appear to be used? I would assume that at a minimum it should be declared outside of the if. >>>> You can clean up all the "l ? (l->loc_pos() - (cbuf.insts_size() + 1)) : 0;" code in x86_*.ad after this fix too. We can even use the MacroAssembler for these instrutions now if we want to though that's probably for another day. >>>> Should labelOper::label have an assert that it's non-null when called? That would cover all the other asserts you added though I'm not sure it must be true. >>>> The overall change looks good. >>>> tom >>>> On Jul 13, 2011, at 8:44 PM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7063628/webrev >>>>> >>>>> Fixed 7063628: Use cbcond on T4 >>>>> >>>>> Added new MacroAssembler instructions cmp_and_br() and old branch instructions are modified to use cbcond on T4 if distance is small (2K bytes). Most of the rest changes are usage of these new branch instructions in Interpreter and C1. >>>>> >>>>> The prototype was done by Tom and I took some of his additional fixes. The formssel.cpp change is a bug fix where the MatchNode equality test wasn't recursing so it would mistakenly return true for complex matches. Added a fake label for branches generated in temp buffer by MachNode::emit_size(), added assert into .ad files to check label. >>>>> >>>>> There was problem in is_in_wdisp16_range() (and in initial implementation of use_cbc()) which calls target(L) before emitting branch. Non-bound (forward branch) labels record current pc() as a branch address and later try to patch instruction (which could be 'cmp') at that address. >>>>> >>>>> Removed unused code in check_klass_subtype_fast_path(). >>>>> >>>>> Modified vm_version string: has_ prefix is removed and only v8 or v9 will be printed as well only niagara_plus or niagara. >>>>> >>>>> Tested on T4 with CTW, nsk, VM and java invoke regression tests. From vladimir.kozlov at oracle.com Wed Jul 20 15:45:53 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Jul 2011 15:45:53 -0700 Subject: Request for reviews (M): 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post on T5440 Message-ID: <4E275AA1.9070600@oracle.com> http://cr.openjdk.java.net/~kvn/7068051/webrev Fixed 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post on T5440 Changes I did for 7004535 are incorrect. They do not take into account that cloning/moving predicates below merge points invalidate jvm states recorded in predicate's uncommon trap. Removed predicate cloning from loop peeling optimization and from split fall-in paths. But left it in loop unswitching code which is safe, I think. Don't allow split loop entry path in IGVN optimization for Phi nodes. And do not clone predicates below merge points in split-if optimization. Removed move_loop_predicate() and eliminate_loop_predicates() unused methods. Refworkload scores are not affected (sparc and x86). From igor.veresov at oracle.com Wed Jul 20 21:20:25 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 21 Jul 2011 04:20:25 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7066339: Tiered: policy should make consistent decisions about osr levels Message-ID: <20110721042030.A3D3847599@hg.openjdk.java.net> Changeset: 43f9d800f276 Author: iveresov Date: 2011-07-20 18:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/43f9d800f276 7066339: Tiered: policy should make consistent decisions about osr levels Summary: Added feedback disabling flag to common(), fixed handling of TieredStopAtLevel. Reviewed-by: kvn, never ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp From tom.rodriguez at oracle.com Thu Jul 21 10:47:08 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 21 Jul 2011 17:47:08 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries Message-ID: <20110721174713.BAE3B475B7@hg.openjdk.java.net> Changeset: 6a991dcb52bb Author: never Date: 2011-07-21 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6a991dcb52bb 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries Reviewed-by: kvn, twisti, jrose ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecode.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeStream.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWideable.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/oops/generateOopMap.cpp From vladimir.kozlov at oracle.com Thu Jul 21 16:57:59 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 21 Jul 2011 23:57:59 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7063628: Use cbcond on T4 Message-ID: <20110721235801.BE61C4762A@hg.openjdk.java.net> Changeset: 3d42f82cd811 Author: kvn Date: 2011-07-21 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3d42f82cd811 7063628: Use cbcond on T4 Summary: Add new short branch instruction to Hotspot sparc assembler. Reviewed-by: never, twisti, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreter_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/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/globals.hpp From roland.westrelin at oracle.com Fri Jul 22 03:10:43 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 22 Jul 2011 12:10:43 +0200 Subject: proposed membar simplification in c2 In-Reply-To: <4E25C003.5030805@oracle.com> References: <4E25C003.5030805@oracle.com> Message-ID: Hi Vladimir, Thanks for the comments. > In general I like this idea since it is platform independent condition. > > There is code in macro.cpp which look for MemBarAcquire and MemBarRelease nodes > to eliminate when eliminating locks and in memnode.cpp for scalar replaced > object. And there is code in lcm.cpp which checks it also. I would suggest to > add new membar nodes MemBarAcquireLock and MemBarReleaseLock instead of using > MemBarCPUOrder. Is this what you have in mind? http://cr.openjdk.java.net/~roland/membar/webrev.02/ > Related note: in .ad file we have to add opposite predicate on a second version > of membar mach node, otherwise it will be always selected by DFA regardless > predicate value: > > instruct membar_volatile() %{ > match(MemBarVolatile); > + predicate(!Matcher::post_store_load_barrier(n)); > ins_cost(4*MEMORY_REF_COST); The costs are not the same for membar_volatile (4*MEMORY_REF_COST) and unnecessary_membar_volatile (0) so that guarantees that unnecessary_membar_volatile is tried first and that when the predicate fails membar_volatile is chosen, right? Roland. From vladimir.kozlov at oracle.com Fri Jul 22 08:50:02 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Jul 2011 08:50:02 -0700 Subject: proposed membar simplification in c2 In-Reply-To: References: <4E25C003.5030805@oracle.com> Message-ID: <4E299C2A.6090802@oracle.com> On 7/22/11 3:10 AM, Roland Westrelin wrote: > > Hi Vladimir, > > Thanks for the comments. > >> In general I like this idea since it is platform independent condition. >> >> There is code in macro.cpp which look for MemBarAcquire and MemBarRelease nodes >> to eliminate when eliminating locks and in memnode.cpp for scalar replaced >> object. And there is code in lcm.cpp which checks it also. I would suggest to >> add new membar nodes MemBarAcquireLock and MemBarReleaseLock instead of using >> MemBarCPUOrder. > > Is this what you have in mind? > http://cr.openjdk.java.net/~roland/membar/webrev.02/ Yes, it is good. > >> Related note: in .ad file we have to add opposite predicate on a second version >> of membar mach node, otherwise it will be always selected by DFA regardless >> predicate value: >> >> instruct membar_volatile() %{ >> match(MemBarVolatile); >> + predicate(!Matcher::post_store_load_barrier(n)); >> ins_cost(4*MEMORY_REF_COST); > > The costs are not the same for membar_volatile (4*MEMORY_REF_COST) and unnecessary_membar_volatile (0) so that > guarantees that unnecessary_membar_volatile is tried first and that when the predicate fails membar_volatile is chosen, > right? Yes, you are right. Thanks, Vladimir > > Roland. From vladimir.kozlov at oracle.com Fri Jul 22 09:38:08 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Jul 2011 09:38:08 -0700 Subject: proposed membar simplification in c2 In-Reply-To: <4E299C2A.6090802@oracle.com> References: <4E25C003.5030805@oracle.com> <4E299C2A.6090802@oracle.com> Message-ID: <4E29A770.2070904@oracle.com> I looked on volatile load in LibraryCallKit::inline_unsafe_access() and the load is not passed to MemBarAcquire as we do in Parse::do_get_xxx(): if (is_volatile) { if (!is_store) insert_mem_bar(Op_MemBarAcquire); else insert_mem_bar(Op_MemBarVolatile); } Should we fix it also? Vladimir Vladimir Kozlov wrote: > On 7/22/11 3:10 AM, Roland Westrelin wrote: >> >> Hi Vladimir, >> >> Thanks for the comments. >> >>> In general I like this idea since it is platform independent condition. >>> >>> There is code in macro.cpp which look for MemBarAcquire and >>> MemBarRelease nodes >>> to eliminate when eliminating locks and in memnode.cpp for scalar >>> replaced >>> object. And there is code in lcm.cpp which checks it also. I would >>> suggest to >>> add new membar nodes MemBarAcquireLock and MemBarReleaseLock instead >>> of using >>> MemBarCPUOrder. >> >> Is this what you have in mind? >> http://cr.openjdk.java.net/~roland/membar/webrev.02/ > > Yes, it is good. > >> >>> Related note: in .ad file we have to add opposite predicate on a >>> second version >>> of membar mach node, otherwise it will be always selected by DFA >>> regardless >>> predicate value: >>> >>> instruct membar_volatile() %{ >>> match(MemBarVolatile); >>> + predicate(!Matcher::post_store_load_barrier(n)); >>> ins_cost(4*MEMORY_REF_COST); >> >> The costs are not the same for membar_volatile (4*MEMORY_REF_COST) and >> unnecessary_membar_volatile (0) so that >> guarantees that unnecessary_membar_volatile is tried first and that >> when the predicate fails membar_volatile is chosen, >> right? > > Yes, you are right. > > Thanks, > Vladimir > >> >> Roland. From vladimir.kozlov at oracle.com Fri Jul 22 11:06:55 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Jul 2011 11:06:55 -0700 Subject: Request for reviews (M): 7069452: Cleanup NodeFlags Message-ID: <4E29BC3F.5020703@oracle.com> http://cr.openjdk.java.net/~kvn/7069452/webrev Fixed 7069452: Cleanup NodeFlags We are almost out of bits (16) for Node::NodeFlags. I removed flags which duplicate information in Node::NodeClasses. is_Call() uses class_id check and is now valid only for ideal CallNode. is_Goto() checks ideal_opcode(). is_Vector() is replaced with check for Vector,VectorLoad,VectorStore classes. MachProjNode was added to class_id check to avoid calling Opcode() in many places. MulNode was removed from class_id since it was used only in one place. I removed all logic associated with is_pc_relative flag. It was only checked in one place during long to short branch replacement. I replaced it with check in adlc parser - short branches should be defined only for a branch to a label, which means branch with PC relative offset. To relay on developer to set ins_pc_relative() was mistake since it could be used in wrong places. For example, it was specified for table jumps, calls and FastLock/FastUnlock. From tom.rodriguez at oracle.com Fri Jul 22 15:20:34 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 22 Jul 2011 15:20:34 -0700 Subject: proposed membar simplification in c2 In-Reply-To: <4E29A770.2070904@oracle.com> References: <4E25C003.5030805@oracle.com> <4E299C2A.6090802@oracle.com> <4E29A770.2070904@oracle.com> Message-ID: <98EFB628-235B-4E8D-9E0A-6DE9450EA040@oracle.com> On Jul 22, 2011, at 9:38 AM, Vladimir Kozlov wrote: > I looked on volatile load in LibraryCallKit::inline_unsafe_access() and the load is not passed to MemBarAcquire as we do in Parse::do_get_xxx(): > > if (is_volatile) { > if (!is_store) > insert_mem_bar(Op_MemBarAcquire); > else > insert_mem_bar(Op_MemBarVolatile); > } > > Should we fix it also? I don't know if we want to fix it as part of Rolands changes but it does seem that both the MemBarAcquire and MemBarVolatile should be emitted the same as the bytecodes would have emitted them, with a precedence edge. tom > > Vladimir > > Vladimir Kozlov wrote: >> On 7/22/11 3:10 AM, Roland Westrelin wrote: >>> >>> Hi Vladimir, >>> >>> Thanks for the comments. >>> >>>> In general I like this idea since it is platform independent condition. >>>> >>>> There is code in macro.cpp which look for MemBarAcquire and MemBarRelease nodes >>>> to eliminate when eliminating locks and in memnode.cpp for scalar replaced >>>> object. And there is code in lcm.cpp which checks it also. I would suggest to >>>> add new membar nodes MemBarAcquireLock and MemBarReleaseLock instead of using >>>> MemBarCPUOrder. >>> >>> Is this what you have in mind? >>> http://cr.openjdk.java.net/~roland/membar/webrev.02/ >> Yes, it is good. >>> >>>> Related note: in .ad file we have to add opposite predicate on a second version >>>> of membar mach node, otherwise it will be always selected by DFA regardless >>>> predicate value: >>>> >>>> instruct membar_volatile() %{ >>>> match(MemBarVolatile); >>>> + predicate(!Matcher::post_store_load_barrier(n)); >>>> ins_cost(4*MEMORY_REF_COST); >>> >>> The costs are not the same for membar_volatile (4*MEMORY_REF_COST) and unnecessary_membar_volatile (0) so that >>> guarantees that unnecessary_membar_volatile is tried first and that when the predicate fails membar_volatile is chosen, >>> right? >> Yes, you are right. >> Thanks, >> Vladimir >>> >>> Roland. From tom.rodriguez at oracle.com Fri Jul 22 15:21:21 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 22 Jul 2011 15:21:21 -0700 Subject: proposed membar simplification in c2 In-Reply-To: References: <4E25C003.5030805@oracle.com> Message-ID: <82AE947F-0E5B-475C-84B2-49D9CB6F282A@oracle.com> On Jul 22, 2011, at 3:10 AM, Roland Westrelin wrote: > > Hi Vladimir, > > Thanks for the comments. > >> In general I like this idea since it is platform independent condition. >> >> There is code in macro.cpp which look for MemBarAcquire and MemBarRelease nodes >> to eliminate when eliminating locks and in memnode.cpp for scalar replaced >> object. And there is code in lcm.cpp which checks it also. I would suggest to >> add new membar nodes MemBarAcquireLock and MemBarReleaseLock instead of using >> MemBarCPUOrder. > > Is this what you have in mind? > http://cr.openjdk.java.net/~roland/membar/webrev.02/ That looks good. I think keeping the release/acquire distinction was a good idea for later optimization. tom > >> Related note: in .ad file we have to add opposite predicate on a second version >> of membar mach node, otherwise it will be always selected by DFA regardless >> predicate value: >> >> instruct membar_volatile() %{ >> match(MemBarVolatile); >> + predicate(!Matcher::post_store_load_barrier(n)); >> ins_cost(4*MEMORY_REF_COST); > > The costs are not the same for membar_volatile (4*MEMORY_REF_COST) and unnecessary_membar_volatile (0) so that guarantees that unnecessary_membar_volatile is tried first and that when the predicate fails membar_volatile is chosen, right? > > Roland. From volker.simonis at gmail.com Mon Jul 25 09:58:58 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Jul 2011 18:58:58 +0200 Subject: Request for review (S): 6865265 JVM crashes with "missing exception handler" error Message-ID: Although I've found a tiny test case for 6865265 and a small fix for the problem, I'm still not sure if my fix is complete. I would appreciate it very much if somebody could review my (somewhat lengthy) explanation for the fix and answer the two questions I encountered. Both, the explanation of the fix and the questions are in the webrev at: http://www.progdoc.de/webrev/6865265/ Regards, Volker From dawid.weiss at gmail.com Mon Jul 25 10:05:35 2011 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 25 Jul 2011 19:05:35 +0200 Subject: sigsegv on porter stemmer (Lucene, but also otherwise) Message-ID: Hello everyone, I am an Apache Lucene developer, we've been running tests with Java 1.7 and this came up: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134 Porter stemmer is pretty widely used for shallow NLP, not only in Lucene. It'd be interesting to hear from jit gurus what's causing this (the problem does not occur in 1.6). Thanks in advance, Dawid From vladimir.kozlov at oracle.com Mon Jul 25 10:49:56 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Jul 2011 10:49:56 -0700 Subject: sigsegv on porter stemmer (Lucene, but also otherwise) In-Reply-To: References: Message-ID: <4E2DACC4.4000306@oracle.com> Thank you very much, Dawid, for providing the test case. Bug was filed in wrong category so we did not know about it. I will work on it since it could be my changes in loop optimizations. Use next flag as workaround: -XX:-UseLoopPredicate Thanks, Vladimir Dawid Weiss wrote: > Hello everyone, > > I am an Apache Lucene developer, we've been running tests with Java > 1.7 and this came up: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134 > > Porter stemmer is pretty widely used for shallow NLP, not only in > Lucene. It'd be interesting to hear from jit gurus what's causing this > (the problem does not occur in 1.6). Thanks in advance, > > Dawid From vladimir.kozlov at oracle.com Mon Jul 25 11:19:32 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Jul 2011 11:19:32 -0700 Subject: Request for review (S): 6865265 JVM crashes with "missing exception handler" error In-Reply-To: <6C3604DF-B1DE-48C3-BAD6-6D9A50C1836B@oracle.com> References: <4E2DA45B.6040807@oracle.com> <6C3604DF-B1DE-48C3-BAD6-6D9A50C1836B@oracle.com> Message-ID: <4E2DB3B4.6040007@oracle.com> Resending to all. Keith McGuigan wrote: > > I think the code looks ok, but why not use a Handle for the > "original_exception" in runtime.cpp -- then you don't need to worry > about the GC case either. > > As to the question about the verifier comparing by name, this is correct > (in that this is what the verifier spec requires, IIRC), but intuitively > it makes sense anyway because the class's current class loader is the > initiating loader for any referenced class that might need to be > loaded. Thus two different references to classes with the same name > will always resolve to the same class implementation so a system > dictionary lookup is unnecessary. The verifier actively attempts to NOT > load or initialize classes when it can, but in some cases it must, > unfortunately. > > -- > - Keith > > > On Jul 25, 2011, at 1:14 PM, Vladimir Kozlov wrote: > >> Forwarding to RT since runtime code is also involved. >> >> Vladimir >> >> -------- Original Message -------- >> Subject: Request for review (S): 6865265 JVM crashes with "missing >> exception handler" error >> Date: Mon, 25 Jul 2011 18:58:58 +0200 >> From: Volker Simonis >> To: hotspot compiler >> >> Although I've found a tiny test case for 6865265 and a small fix for >> the problem, I'm still not sure if my fix is complete. >> >> I would appreciate it very much if somebody could review my (somewhat >> lengthy) explanation for the fix and answer the two questions I >> encountered. >> Both, the explanation of the fix and the questions are in the webrev at: >> >> http://www.progdoc.de/webrev/6865265/ >> >> Regards, >> Volker > From dawid.weiss at gmail.com Mon Jul 25 12:26:18 2011 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 25 Jul 2011 21:26:18 +0200 Subject: sigsegv on porter stemmer (Lucene, but also otherwise) In-Reply-To: <4E2DACC4.4000306@oracle.com> References: <4E2DACC4.4000306@oracle.com> Message-ID: Thanks for feedback and the workaround, Vladimir. The credits for finding the bug and reproducing it should go to Robert Muir and Uwe Schindler, I'm merely a messenger, but I had a feeling you'd be interested :) Dawid On Mon, Jul 25, 2011 at 7:49 PM, Vladimir Kozlov wrote: > Thank you very much, Dawid, for providing the test case. Bug was filed in > wrong category so we did not know about it. I will work on it since it could > be my changes in loop optimizations. Use next flag as workaround: > > -XX:-UseLoopPredicate > > Thanks, > Vladimir > > Dawid Weiss wrote: >> >> Hello everyone, >> >> I am an Apache Lucene developer, we've been running tests with Java >> 1.7 and this came up: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134 >> >> Porter stemmer is pretty widely used for shallow NLP, not only in >> Lucene. It'd be interesting to hear from jit gurus what's causing this >> (the problem does not occur in 1.6). Thanks in advance, >> >> Dawid > From uschindler at apache.org Mon Jul 25 12:51:33 2011 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 25 Jul 2011 21:51:33 +0200 Subject: sigsegv on porter stemmer (Lucene, but also otherwise) Message-ID: <008f01cc4b04$41cae4b0$c560ae10$@apache.org> Hi thanks for taking care! Thanks for the workaround. We already found another workaround to get this running in our 2-hourly Lucene builds at: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/ https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/ It would be nice if you could look into the console logs of the failed builds on Saturday - you can see the bug in the earlier builds only (with always different stack traces). We drilled it down to one method (not sure if this information clipped out of the bug report. We then disabled compilation for only this affected method, its PorterStemmer.ends(...): -XX:CompileCommand=exclude,org/apache/lucene/analysis/en/PorterStemmer,ends -XX:CompileCommand=exclude,org/apache/lucene/analysis/PorterStemmer,ends (we have different class names in stable 3.x branch and trunk). We also see other random test failures not happening with Java 5 and Java 6, it would be nice, if you could review, too. One big bug in loops affected also Java 1.6.0_18 (still not fixed): our DataInput.readVInt method was incorrectly compiled in the case that MappedByteBuffer.get()/lucene.DataInput.readByte() was inlined, leading to simply wrong results (the method returned a decoded integer that was different than expected results). See the unwinded loops in https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/src/java/org/apache /lucene/store/DataInput.java I hope this all helps you in finding more bad loop optimization bugs, all of those issues seem to be related to this special optimization in loops. The latest lucene builds also contains a failure in a test case only happening with Java 7 (not on every test run, so unreproducible). So it might be good for you to watch our Lucene builds also for other bugs. Some of the other developers already say, we should not trust any loops in java anymore and recommend not to use Java 7 with Apache Lucene/Solr, and that's bad news :( Thanks for the help, Uwe On Mon, Jul 25, 2011 at 7:49 PM, Vladimir Kozlov wrote: > Thank you very much, Dawid, for providing the test case. Bug was filed in > wrong category so we did not know about it. I will work on it since it could > be my changes in loop optimizations. Use next flag as workaround: > > -XX:-UseLoopPredicate > > Thanks, > Vladimir > > Dawid Weiss wrote: >> >> Hello everyone, >> >> I am an Apache Lucene developer, we've been running tests with Java >> 1.7 and this came up: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134 >> >> Porter stemmer is pretty widely used for shallow NLP, not only in >> Lucene. It'd be interesting to hear from jit gurus what's causing this >> (the problem does not occur in 1.6). Thanks in advance, >> >> Dawid ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ From vladimir.kozlov at oracle.com Mon Jul 25 15:06:02 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Jul 2011 15:06:02 -0700 Subject: sigsegv on porter stemmer (Lucene, but also otherwise) In-Reply-To: <008f01cc4b04$41cae4b0$c560ae10$@apache.org> References: <008f01cc4b04$41cae4b0$c560ae10$@apache.org> Message-ID: <4E2DE8CA.9060404@oracle.com> Thank you, Uwe I looked on logs and most of them, it seems, related to the problem described in your bug 7070134. And I looked on LUCENE-2975 which describes DataInput.readVInt() problem. It references Hotspot bug 5091921. The loop optimization changes I mentioned before were done to fix that bug so it should be fixed in jdk7. But, as we know now, those changes introduced several new problems, like yours 7070134. I am working on them. Regards, Vladimir Uwe Schindler wrote: > Hi thanks for taking care! > > Thanks for the workaround. We already found another workaround to get this > running in our 2-hourly Lucene builds at: > > https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/ > https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/ > > It would be nice if you could look into the console logs of the failed > builds on Saturday - you can see the bug in the earlier builds only (with > always different stack traces). We drilled it down to one method (not sure > if this information clipped out of the bug report. We then disabled > compilation for only this affected method, its PorterStemmer.ends(...): > > -XX:CompileCommand=exclude,org/apache/lucene/analysis/en/PorterStemmer,ends > -XX:CompileCommand=exclude,org/apache/lucene/analysis/PorterStemmer,ends > > (we have different class names in stable 3.x branch and trunk). > > We also see other random test failures not happening with Java 5 and Java 6, > it would be nice, if you could review, too. > > One big bug in loops affected also Java 1.6.0_18 (still not fixed): our > DataInput.readVInt method was incorrectly compiled in the case that > MappedByteBuffer.get()/lucene.DataInput.readByte() was inlined, leading to > simply wrong results (the method returned a decoded integer that was > different than expected results). See the unwinded loops in > https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/src/java/org/apache > /lucene/store/DataInput.java > > I hope this all helps you in finding more bad loop optimization bugs, all of > those issues seem to be related to this special optimization in loops. The > latest lucene builds also contains a failure in a test case only happening > with Java 7 (not on every test run, so unreproducible). So it might be good > for you to watch our Lucene builds also for other bugs. > > Some of the other developers already say, we should not trust any loops in > java anymore and recommend not to use Java 7 with Apache Lucene/Solr, and > that's bad news :( > > Thanks for the help, > Uwe > > On Mon, Jul 25, 2011 at 7:49 PM, Vladimir Kozlov > wrote: >> Thank you very much, Dawid, for providing the test case. Bug was filed in >> wrong category so we did not know about it. I will work on it since it > could >> be my changes in loop optimizations. Use next flag as workaround: >> >> -XX:-UseLoopPredicate >> >> Thanks, >> Vladimir >> >> Dawid Weiss wrote: >>> Hello everyone, >>> >>> I am an Apache Lucene developer, we've been running tests with Java >>> 1.7 and this came up: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134 >>> >>> Porter stemmer is pretty widely used for shallow NLP, not only in >>> Lucene. It'd be interesting to hear from jit gurus what's causing this >>> (the problem does not occur in 1.6). Thanks in advance, >>> >>> Dawid > > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > From christian.thalinger at oracle.com Tue Jul 26 07:47:58 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 26 Jul 2011 16:47:58 +0200 Subject: Review Request: zero/shark doesn't build after b147-fcs In-Reply-To: <4E2049CA.8060506@LGonQn.Org> References: <4E1C5E4F.1080307@zafena.se> <4E2049CA.8060506@LGonQn.Org> Message-ID: <5AF146A3-E2D2-4430-941B-437FA85A9515@oracle.com> I will take care of these patches and the ones Xerxes posted. -- Christian On Jul 15, 2011, at 4:08 PM, Chris Phillips wrote: > Hi > > The following webrev's are for recent issues for zero/shark > that stop it from building: > > http://lgonqn.org/temp/ChrisPhi/webrev-frame_zero.cpp-describe_pd_missing/ > > http://lgonqn.org/temp/ChrisPhi/webrev-sharedRuntime_zero.cpp-needs-rework-after-indy-reorg/ > > http://lgonqn.org/temp/ChrisPhi/webrev-sharkContext.hpp-typo-in-assert/ > > http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing/ > > The fixes from Xerxes R?nby , zero-methodHandle 7009923-regression > and IA32 Hotspot FTBFS 7009309-regression are als required. > > These allow zero/shark to compile in product or debug for b147/fcs. There > are still significant issues in shark beyond this > and zero doesn't pass the invoke dynamic tests. > > Chris > > From volker.simonis at gmail.com Tue Jul 26 10:20:49 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Jul 2011 19:20:49 +0200 Subject: Request for review (S): 6865265 JVM crashes with "missing exception handler" error In-Reply-To: <4E2DB3B4.6040007@oracle.com> References: <4E2DA45B.6040807@oracle.com> <6C3604DF-B1DE-48C3-BAD6-6D9A50C1836B@oracle.com> <4E2DB3B4.6040007@oracle.com> Message-ID: Hi, I've made "original_exception" a Handle as suggested by Keith. Here's the new webrev: http://www.progdoc.de/webrev/6865265.v2 Regarding Keith' comments about the verification process: he's right, 'VerificationType::is_reference_assignable_from()' loads both references with the same class loader (the initiating one in this case). Initially I though that verifying if an Exception class in the class file's exception table is "java.lang.Throwable" only by name may be not enough, because a custom system class loader could load a bogus Throwable class which is different from the one loaded by the boot class loader. But I've just verified that such a scenario is prohibited by 'ClassLoader.defineClass()' which is final and rejects the loading of classes from the 'java.' package. Regards, Volker On Mon, Jul 25, 2011 at 8:19 PM, Vladimir Kozlov wrote: > Resending to all. > > Keith McGuigan wrote: >> >> I think the code looks ok, but why not use a Handle for the >> "original_exception" in runtime.cpp -- then you don't need to worry about >> the GC case either. >> >> As to the question about the verifier comparing by name, this is correct >> (in that this is what the verifier spec requires, IIRC), but intuitively it >> makes sense anyway because the class's current class loader is the >> initiating loader for any referenced class that might need to be loaded. >> ?Thus two different references to classes with the same name will always >> resolve to the same class implementation so a system dictionary lookup is >> unnecessary. ?The verifier actively attempts to NOT load or initialize >> classes when it can, but in some cases it must, unfortunately. >> >> -- >> - Keith >> >> >> On Jul 25, 2011, at 1:14 PM, Vladimir Kozlov wrote: >> >>> Forwarding to RT since runtime code is also involved. >>> >>> Vladimir >>> >>> -------- Original Message -------- >>> Subject: Request for review (S): 6865265 JVM crashes with "missing >>> exception handler" error >>> Date: Mon, 25 Jul 2011 18:58:58 +0200 >>> From: Volker Simonis >>> To: hotspot compiler >>> >>> Although I've found a tiny test case for 6865265 and a small fix for >>> the problem, I'm still not sure if my fix is complete. >>> >>> I would appreciate it very much if somebody could review my (somewhat >>> lengthy) explanation for the fix and answer the two questions I >>> encountered. >>> Both, the explanation of the fix and the questions are in the webrev at: >>> >>> http://www.progdoc.de/webrev/6865265/ >>> >>> Regards, >>> Volker >> > From uschindler at apache.org Tue Jul 26 11:57:37 2011 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 26 Jul 2011 20:57:37 +0200 Subject: sigsegv on porter stemmer (Lucene, but also otherwise) In-Reply-To: <008f01cc4b04$41cae4b0$c560ae10$@apache.org> References: <008f01cc4b04$41cae4b0$c560ae10$@apache.org> Message-ID: <009701cc4bc5$e31386d0$a93a9470$@apache.org> Hi, With the help from Vladimir we patched our test platform and verified that the bug is fixed with Vladimirs latest patches (including already committed patches not available in the latest Java 7 developer preview), so thanks for that. I think you may post your patches for review here, we are happy! I was able to apply the patches to our Jenkins server's Java 7 preview installation, which runs on FreeBSD. I prepared a combined patch to be placed in the ports directory and recompiled the openjdk7 package. After restarting our Jenkins jobs, all was fine, even the other random test failures without SIGSEGV seem to be resolved (e.g. Lucene Faceting module caused broken index on disk). More information can also be found in Lucene's JIRA: https://issues.apache.org/jira/browse/LUCENE-3335 You can find the working builds here: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/, starting with build #27 (some builds still failed because of another bug in IBM's ICU when the default locale, which is randomly set by our test framework, contained one of the new Java 7 ones - we have now a workaround) We now hope, that Java 7 will not be released with that bugs, because quite a lot loops got miscompiled without the fixes, which will break lots of applications. We are afraid of people using Lucene/Solr with Oracle JDK 1.7.0_0 on July 28th and will corrupt their indexes. Is there a chance to get the fixes in or delay the release? Also it would be interesting to know how this affects JDK 1.6.0, because _26 did not seem to contain the broken original fix that caused the porter failure and 1.6.0 is still broken with our readVInt method. We hope the complete fix will be in _27. Finally, we have a list of all issues related to Java7, if you are interested: http://s.apache.org/Java7Failures Uwe > -----Original Message----- > From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot- > compiler-dev-bounces at openjdk.java.net] On Behalf Of Uwe Schindler > Sent: Monday, July 25, 2011 9:52 PM > To: vladimir.kozlov at oracle.com; hotspot-compiler-dev at openjdk.java.net > Subject: Re: sigsegv on porter stemmer (Lucene, but also otherwise) > > Hi thanks for taking care! > > Thanks for the workaround. We already found another workaround to get > this running in our 2-hourly Lucene builds at: > > https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/ > https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/ > > It would be nice if you could look into the console logs of the failed builds on > Saturday - you can see the bug in the earlier builds only (with always > different stack traces). We drilled it down to one method (not sure if this > information clipped out of the bug report. We then disabled compilation for > only this affected method, its PorterStemmer.ends(...): > > - > XX:CompileCommand=exclude,org/apache/lucene/analysis/en/PorterStem > mer,ends > - > XX:CompileCommand=exclude,org/apache/lucene/analysis/PorterStemmer, > ends > > (we have different class names in stable 3.x branch and trunk). > > We also see other random test failures not happening with Java 5 and Java 6, > it would be nice, if you could review, too. > > One big bug in loops affected also Java 1.6.0_18 (still not fixed): our > DataInput.readVInt method was incorrectly compiled in the case that > MappedByteBuffer.get()/lucene.DataInput.readByte() was inlined, leading > to simply wrong results (the method returned a decoded integer that was > different than expected results). See the unwinded loops in > https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/src/java/org/ap > ache > /lucene/store/DataInput.java > > I hope this all helps you in finding more bad loop optimization bugs, all of > those issues seem to be related to this special optimization in loops. The > latest lucene builds also contains a failure in a test case only happening with > Java 7 (not on every test run, so unreproducible). So it might be good for you > to watch our Lucene builds also for other bugs. > > Some of the other developers already say, we should not trust any loops in > java anymore and recommend not to use Java 7 with Apache Lucene/Solr, > and that's bad news :( > > Thanks for the help, > Uwe > > On Mon, Jul 25, 2011 at 7:49 PM, Vladimir Kozlov oracle.com> wrote: > > Thank you very much, Dawid, for providing the test case. Bug was filed > > in wrong category so we did not know about it. I will work on it since > > it > could > > be my changes in loop optimizations. Use next flag as workaround: > > > > -XX:-UseLoopPredicate > > > > Thanks, > > Vladimir > > > > Dawid Weiss wrote: > >> > >> Hello everyone, > >> > >> I am an Apache Lucene developer, we've been running tests with Java > >> 1.7 and this came up: > >> > >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134 > >> > >> Porter stemmer is pretty widely used for shallow NLP, not only in > >> Lucene. It'd be interesting to hear from jit gurus what's causing > >> this (the problem does not occur in 1.6). Thanks in advance, > >> > >> Dawid > > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ From vladimir.kozlov at oracle.com Tue Jul 26 12:44:22 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jul 2011 12:44:22 -0700 Subject: sigsegv on porter stemmer (Lucene, but also otherwise) In-Reply-To: <009701cc4bc5$e31386d0$a93a9470$@apache.org> References: <008f01cc4b04$41cae4b0$c560ae10$@apache.org> <009701cc4bc5$e31386d0$a93a9470$@apache.org> Message-ID: <4E2F1916.1070505@oracle.com> Thank you, Uwe I will send the patch for reviews shortly. About java 7 release. We are late to do any bugs fixes in GA which should happen soon. All loop optimization fixes will go definitely into jdk7 update 2. We will try to push them into update 1 (which is targeted only for security fixes) but we can't promise. There is going discussion about using current Hotspot VM in future jdk6 updates but there is no decision yet. Note: current Hotspot VM sources are targeted for JDK8 and jdk7 updates only. Regards, Vladimir Uwe Schindler wrote: > Hi, > > With the help from Vladimir we patched our test platform and verified that > the bug is fixed with Vladimirs latest patches (including already committed > patches not available in the latest Java 7 developer preview), so thanks for > that. I think you may post your patches for review here, we are happy! > > I was able to apply the patches to our Jenkins server's Java 7 preview > installation, which runs on FreeBSD. I prepared a combined patch to be > placed in the ports directory and recompiled the openjdk7 package. After > restarting our Jenkins jobs, all was fine, even the other random test > failures without SIGSEGV seem to be resolved (e.g. Lucene Faceting module > caused broken index on disk). More information can also be found in Lucene's > JIRA: https://issues.apache.org/jira/browse/LUCENE-3335 > > You can find the working builds here: > https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/, starting > with build #27 > (some builds still failed because of another bug in IBM's ICU when the > default locale, which is randomly set by our test framework, contained one > of the new Java 7 ones - we have now a workaround) > > We now hope, that Java 7 will not be released with that bugs, because quite > a lot loops got miscompiled without the fixes, which will break lots of > applications. We are afraid of people using Lucene/Solr with Oracle JDK > 1.7.0_0 on July 28th and will corrupt their indexes. Is there a chance to > get the fixes in or delay the release? > > Also it would be interesting to know how this affects JDK 1.6.0, because _26 > did not seem to contain the broken original fix that caused the porter > failure and 1.6.0 is still broken with our readVInt method. We hope the > complete fix will be in _27. > > Finally, we have a list of all issues related to Java7, if you are > interested: > http://s.apache.org/Java7Failures > > Uwe > >> -----Original Message----- >> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot- >> compiler-dev-bounces at openjdk.java.net] On Behalf Of Uwe Schindler >> Sent: Monday, July 25, 2011 9:52 PM >> To: vladimir.kozlov at oracle.com; hotspot-compiler-dev at openjdk.java.net >> Subject: Re: sigsegv on porter stemmer (Lucene, but also otherwise) >> >> Hi thanks for taking care! >> >> Thanks for the workaround. We already found another workaround to get >> this running in our 2-hourly Lucene builds at: >> >> https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/ >> https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/ >> >> It would be nice if you could look into the console logs of the failed > builds on >> Saturday - you can see the bug in the earlier builds only (with always >> different stack traces). We drilled it down to one method (not sure if > this >> information clipped out of the bug report. We then disabled compilation > for >> only this affected method, its PorterStemmer.ends(...): >> >> - >> XX:CompileCommand=exclude,org/apache/lucene/analysis/en/PorterStem >> mer,ends >> - >> XX:CompileCommand=exclude,org/apache/lucene/analysis/PorterStemmer, >> ends >> >> (we have different class names in stable 3.x branch and trunk). >> >> We also see other random test failures not happening with Java 5 and Java > 6, >> it would be nice, if you could review, too. >> >> One big bug in loops affected also Java 1.6.0_18 (still not fixed): our >> DataInput.readVInt method was incorrectly compiled in the case that >> MappedByteBuffer.get()/lucene.DataInput.readByte() was inlined, leading >> to simply wrong results (the method returned a decoded integer that was >> different than expected results). See the unwinded loops in >> https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/src/java/org/ap >> ache >> /lucene/store/DataInput.java >> >> I hope this all helps you in finding more bad loop optimization bugs, all > of >> those issues seem to be related to this special optimization in loops. The >> latest lucene builds also contains a failure in a test case only happening > with >> Java 7 (not on every test run, so unreproducible). So it might be good for > you >> to watch our Lucene builds also for other bugs. >> >> Some of the other developers already say, we should not trust any loops in >> java anymore and recommend not to use Java 7 with Apache Lucene/Solr, >> and that's bad news :( >> >> Thanks for the help, >> Uwe >> >> On Mon, Jul 25, 2011 at 7:49 PM, Vladimir Kozlov > oracle.com> wrote: >>> Thank you very much, Dawid, for providing the test case. Bug was filed >>> in wrong category so we did not know about it. I will work on it since >>> it >> could >>> be my changes in loop optimizations. Use next flag as workaround: >>> >>> -XX:-UseLoopPredicate >>> >>> Thanks, >>> Vladimir >>> >>> Dawid Weiss wrote: >>>> Hello everyone, >>>> >>>> I am an Apache Lucene developer, we've been running tests with Java >>>> 1.7 and this came up: >>>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134 >>>> >>>> Porter stemmer is pretty widely used for shallow NLP, not only in >>>> Lucene. It'd be interesting to hear from jit gurus what's causing >>>> this (the problem does not occur in 1.6). Thanks in advance, >>>> >>>> Dawid >> ----- >> Uwe Schindler >> uschindler at apache.org >> Apache Lucene PMC Member / Committer >> Bremen, Germany >> http://lucene.apache.org/ > > From vladimir.kozlov at oracle.com Tue Jul 26 13:09:26 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jul 2011 13:09:26 -0700 Subject: Request for reviews (M): 7070134: Hotspot crashes with sigsegv from PorterStemmer Message-ID: <4E2F1EF6.7060407@oracle.com> http://cr.openjdk.java.net/~kvn/7070134/webrev Fixed 7070134: Hotspot crashes with sigsegv from PorterStemmer It is an other case of "6831314: C2 may incorrectly change control of type nodes". Loop predicate RCE upper_bound check matches an other dominating RangeCheck and split_if optimization moves loads to dominating test. In the bug case (step4() method) two code branches have the same loads from the same array (b[]) and they are combined and moved above array's index check and above lower_bound predicate check. The fix is band-aid to not move data nodes which are attached to a predicate test to a dominating test. It is allowed to do that during loop peeling and loop predicates generation since they duplicate all checks. I also switched off predicate RCE optimization for counted loops with '!=' test since there is no guarantee that loop index will be in the range [init, limit) if init > limit. Added regression test. Refwokload (x64) shows no affect. From vladimir.kozlov at oracle.com Tue Jul 26 14:41:49 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jul 2011 14:41:49 -0700 Subject: Request for reviews (M): 7070134: Hotspot crashes with sigsegv from PorterStemmer In-Reply-To: <4E2F1EF6.7060407@oracle.com> References: <4E2F1EF6.7060407@oracle.com> Message-ID: <4E2F349D.90109@oracle.com> Additional note: the problem appeared before my loop optimization changes. It started after I enabled the code in memnode.cpp that treats fields of constant strings as constants (6942326 changes). In the bug case inlined method ends() has a loop with constant string's length as the limit. After changes in memnode.cpp the limit becomes constant and the loop is fully unrolled. As result loads which were in the loop can be moved to dominating test. Vladimir Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7070134/webrev > > Fixed 7070134: Hotspot crashes with sigsegv from PorterStemmer > > It is an other case of "6831314: C2 may incorrectly change control of > type nodes". Loop predicate RCE upper_bound check matches an other > dominating RangeCheck and split_if optimization moves loads to > dominating test. In the bug case (step4() method) two code branches have > the same loads from the same array (b[]) and they are combined and moved > above array's index check and above lower_bound predicate check. > > The fix is band-aid to not move data nodes which are attached to a > predicate test to a dominating test. It is allowed to do that during > loop peeling and loop predicates generation since they duplicate all > checks. I also switched off predicate RCE optimization for counted loops > with '!=' test since there is no guarantee that loop index will be in > the range [init, limit) if init > limit. > > Added regression test. Refwokload (x64) shows no affect. > > > From tom.rodriguez at oracle.com Tue Jul 26 15:47:48 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 26 Jul 2011 15:47:48 -0700 Subject: Request for reviews (M): 7070134: Hotspot crashes with sigsegv from PorterStemmer In-Reply-To: <4E2F1EF6.7060407@oracle.com> References: <4E2F1EF6.7060407@oracle.com> Message-ID: On Jul 26, 2011, at 1:09 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7070134/webrev > > Fixed 7070134: Hotspot crashes with sigsegv from PorterStemmer > > It is an other case of "6831314: C2 may incorrectly change control of type nodes". Loop predicate RCE upper_bound check matches an other dominating RangeCheck and split_if optimization moves loads to dominating test. In the bug case (step4() method) two code branches have the same loads from the same array (b[]) and they are combined and moved above array's index check and above lower_bound predicate check. > > The fix is band-aid to not move data nodes which are attached to a predicate test to a dominating test. It is allowed to do that during loop peeling and loop predicates generation since they duplicate all checks. I also switched off predicate RCE optimization for counted loops with '!=' test since there is no guarantee that loop index will be in the range [init, limit) if init > limit. > > Added regression test. Refwokload (x64) shows no affect. Why are the fixes in IfNode::dominated_by and PhaseIdealLoop::dominated_by different? IfNode just picks a different node but PhaseIdealLoop gives up. Can't PhaseIdealLoop pick a safe node? loopPredicate.cpp: Is this line really needed? ! Node* upper_bound_bol = rc_predicate(loop, ctrl, scale, offset, init, limit, stride, rng, true); ! Node* upper_bound_bol = rc_predicate(loop, lower_bound_proj, scale, offset, init, limit, stride, rng, true); I'm not against it since it's valid and maybe conceptually more correct but I'm unclear how it could have any effect on correctness. tom > > > From tom.rodriguez at oracle.com Tue Jul 26 16:26:02 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 26 Jul 2011 16:26:02 -0700 Subject: Request for reviews (M): 7069452: Cleanup NodeFlags In-Reply-To: <4E29BC3F.5020703@oracle.com> References: <4E29BC3F.5020703@oracle.com> Message-ID: So is_Goto returns false for GotoNode? That doesn't seem right. +bool Node::is_Goto() const { return is_Branch() && is_Mach() && (as_Mach()->ideal_Opcode() == Op_Goto); } why does this have an is_Branch test? Isn't testing the ideal_Opcode sufficient for the mach case? Flag_is_block_start seems to be minimally useful since it's only used to mark StartNode, at least as far as I can see. Flag_is_safepoint_node could probably be eliminated without too much work too. It's set for MachSafePointNode and cleared for MachCallLeaf. The adlc tries to clear it for FastUnlock but those inherit from MachNode, not MachSafePointNode so it seems slightly useless. tom On Jul 22, 2011, at 11:06 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7069452/webrev > > Fixed 7069452: Cleanup NodeFlags > > We are almost out of bits (16) for Node::NodeFlags. I removed flags which duplicate information in Node::NodeClasses. > is_Call() uses class_id check and is now valid only for ideal CallNode. > is_Goto() checks ideal_opcode(). > is_Vector() is replaced with check for Vector,VectorLoad,VectorStore classes. > MachProjNode was added to class_id check to avoid calling Opcode() in many places. MulNode was removed from class_id since it was used only in one place. > > I removed all logic associated with is_pc_relative flag. It was only checked in one place during long to short branch replacement. I replaced it with check in adlc parser - short branches should be defined only for a branch to a label, which means branch with PC relative offset. To relay on developer to set ins_pc_relative() was mistake since it could be used in wrong places. For example, it was specified for table jumps, calls and FastLock/FastUnlock. From tom.rodriguez at oracle.com Tue Jul 26 16:46:10 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 26 Jul 2011 16:46:10 -0700 Subject: review for 7071427: AdapterFingerPrint can hold 8 entries per int Message-ID: <593DAA5D-671E-40B9-9C9C-F3A36A409970@oracle.com> http://cr.openjdk.java.net/~never/7071427 6 lines changed: 1 ins; 0 del; 5 mod; 2907 unchg 7071427: AdapterFingerPrint can hold 8 entries per int Reviewed-by: While looking at another bug I noticed that the packed form of the AdapterFingerPrint was only using 16 bits of the full 32 so I fixed it. Tested with runThese. From vladimir.kozlov at oracle.com Tue Jul 26 16:49:51 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jul 2011 16:49:51 -0700 Subject: Request for reviews (M): 7070134: Hotspot crashes with sigsegv from PorterStemmer In-Reply-To: References: <4E2F1EF6.7060407@oracle.com> Message-ID: <4E2F529F.3060509@oracle.com> Thank you, Tom Tom Rodriguez wrote: > On Jul 26, 2011, at 1:09 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7070134/webrev >> >> Fixed 7070134: Hotspot crashes with sigsegv from PorterStemmer >> >> It is an other case of "6831314: C2 may incorrectly change control of type nodes". Loop predicate RCE upper_bound check matches an other dominating RangeCheck and split_if optimization moves loads to dominating test. In the bug case (step4() method) two code branches have the same loads from the same array (b[]) and they are combined and moved above array's index check and above lower_bound predicate check. >> >> The fix is band-aid to not move data nodes which are attached to a predicate test to a dominating test. It is allowed to do that during loop peeling and loop predicates generation since they duplicate all checks. I also switched off predicate RCE optimization for counted loops with '!=' test since there is no guarantee that loop index will be in the range [init, limit) if init > limit. >> >> Added regression test. Refwokload (x64) shows no affect. > > Why are the fixes in IfNode::dominated_by and PhaseIdealLoop::dominated_by different? IfNode just picks a different node but PhaseIdealLoop gives up. Can't PhaseIdealLoop pick a safe node? PhaseIdealLoop::dominated_by does not give up. Data nodes control edge will be changed to iff->in(0) later during Ideal transformation when this If node folds (since Bool node was replaced with constant). If you want, I can do it explicitly in dominated_by(): replace prevdom with iff->in(0). > > loopPredicate.cpp: > > Is this line really needed? > > ! Node* upper_bound_bol = rc_predicate(loop, ctrl, scale, offset, init, limit, stride, rng, true); > ! Node* upper_bound_bol = rc_predicate(loop, lower_bound_proj, scale, offset, init, limit, stride, rng, true); > > I'm not against it since it's valid and maybe conceptually more correct but I'm unclear how it could have any effect on correctness. I changed it just for that reason: it is conceptually more correct. But I agree, it is not needed. Vladimir > > tom > >> >> > From tom.rodriguez at oracle.com Tue Jul 26 16:59:09 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 26 Jul 2011 16:59:09 -0700 Subject: Request for reviews (M): 7070134: Hotspot crashes with sigsegv from PorterStemmer In-Reply-To: <4E2F529F.3060509@oracle.com> References: <4E2F1EF6.7060407@oracle.com> <4E2F529F.3060509@oracle.com> Message-ID: <943704EC-87D8-4251-8834-F307CB6DC058@oracle.com> On Jul 26, 2011, at 4:49 PM, Vladimir Kozlov wrote: > Thank you, Tom > > Tom Rodriguez wrote: >> On Jul 26, 2011, at 1:09 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7070134/webrev >>> >>> Fixed 7070134: Hotspot crashes with sigsegv from PorterStemmer >>> >>> It is an other case of "6831314: C2 may incorrectly change control of type nodes". Loop predicate RCE upper_bound check matches an other dominating RangeCheck and split_if optimization moves loads to dominating test. In the bug case (step4() method) two code branches have the same loads from the same array (b[]) and they are combined and moved above array's index check and above lower_bound predicate check. >>> >>> The fix is band-aid to not move data nodes which are attached to a predicate test to a dominating test. It is allowed to do that during loop peeling and loop predicates generation since they duplicate all checks. I also switched off predicate RCE optimization for counted loops with '!=' test since there is no guarantee that loop index will be in the range [init, limit) if init > limit. >>> >>> Added regression test. Refwokload (x64) shows no affect. >> Why are the fixes in IfNode::dominated_by and PhaseIdealLoop::dominated_by different? IfNode just picks a different node but PhaseIdealLoop gives up. Can't PhaseIdealLoop pick a safe node? > > PhaseIdealLoop::dominated_by does not give up. Data nodes control edge will be changed to iff->in(0) later during Ideal transformation when this If node folds (since Bool node was replaced with constant). If you want, I can do it explicitly in dominated_by(): replace prevdom with iff->in(0). Oh I see. I didn't follow it closely enough. I think it's fine like it is. > >> loopPredicate.cpp: >> Is this line really needed? >> ! Node* upper_bound_bol = rc_predicate(loop, ctrl, scale, offset, init, limit, stride, rng, true); >> ! Node* upper_bound_bol = rc_predicate(loop, lower_bound_proj, scale, offset, init, limit, stride, rng, true); >> I'm not against it since it's valid and maybe conceptually more correct but I'm unclear how it could have any effect on correctness. > > I changed it just for that reason: it is conceptually more correct. But I agree, it is not needed. OK. Look good. tom > > Vladimir > >> tom >>> >>> From tom.rodriguez at oracle.com Tue Jul 26 16:59:27 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 26 Jul 2011 16:59:27 -0700 Subject: review for 7060619: C1 should respect inline and dontinline directives from CompilerOracle Message-ID: <2C4D8B5C-C15D-425E-AFCC-1D27CAB4011A@oracle.com> http://cr.openjdk.java.net/~never/7060619 52 lines changed: 30 ins; 22 del; 0 mod; 3825 unchg 7060619: C1 should respect inline and dontinline directives from CompilerOracle Reviewed-by: This adds support for the inline and dontinline directives to C1. I moved several correctness guards further up so that only purely heuristic guards were at the end. Tested with various commands and PrintCompilation PrintInlining. From vladimir.kozlov at oracle.com Tue Jul 26 17:05:55 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jul 2011 17:05:55 -0700 Subject: Request for reviews (M): 7069452: Cleanup NodeFlags In-Reply-To: References: <4E29BC3F.5020703@oracle.com> Message-ID: <4E2F5663.40803@oracle.com> Tom Rodriguez wrote: > So is_Goto returns false for GotoNode? That doesn't seem right. It is used only for Mach nodes in block.cpp. > > +bool Node::is_Goto() const { return is_Branch() && is_Mach() && (as_Mach()->ideal_Opcode() == Op_Goto); } > > why does this have an is_Branch test? Isn't testing the ideal_Opcode sufficient for the mach case? is_Branch() is bits test and ideal_Opcode() is virtual call. So it is a little speedup. I can set is_Branch flag in ideal GotoNode and change is_Goto() to: bool Node::is_Goto() const { if (!is_Branch()) return false; if (is_Mach()) return (as_Mach()->ideal_Opcode() == Op_Goto); else return (Opcode() == Op_Goto); } I will look on Flag_is_block_start and Flag_is_safepoint_node. Thanks, Vladimir > > Flag_is_block_start seems to be minimally useful since it's only used to mark StartNode, at least as far as I can see. > > Flag_is_safepoint_node could probably be eliminated without too much work too. It's set for MachSafePointNode and cleared for MachCallLeaf. The adlc tries to clear it for FastUnlock but those inherit from MachNode, not MachSafePointNode so it seems slightly useless. > > tom > > On Jul 22, 2011, at 11:06 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7069452/webrev >> >> Fixed 7069452: Cleanup NodeFlags >> >> We are almost out of bits (16) for Node::NodeFlags. I removed flags which duplicate information in Node::NodeClasses. >> is_Call() uses class_id check and is now valid only for ideal CallNode. >> is_Goto() checks ideal_opcode(). >> is_Vector() is replaced with check for Vector,VectorLoad,VectorStore classes. >> MachProjNode was added to class_id check to avoid calling Opcode() in many places. MulNode was removed from class_id since it was used only in one place. >> >> I removed all logic associated with is_pc_relative flag. It was only checked in one place during long to short branch replacement. I replaced it with check in adlc parser - short branches should be defined only for a branch to a label, which means branch with PC relative offset. To relay on developer to set ins_pc_relative() was mistake since it could be used in wrong places. For example, it was specified for table jumps, calls and FastLock/FastUnlock. > From vladimir.kozlov at oracle.com Tue Jul 26 17:10:50 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jul 2011 17:10:50 -0700 Subject: Request for reviews (M): 7070134: Hotspot crashes with sigsegv from PorterStemmer In-Reply-To: <943704EC-87D8-4251-8834-F307CB6DC058@oracle.com> References: <4E2F1EF6.7060407@oracle.com> <4E2F529F.3060509@oracle.com> <943704EC-87D8-4251-8834-F307CB6DC058@oracle.com> Message-ID: <4E2F578A.2050508@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > On Jul 26, 2011, at 4:49 PM, Vladimir Kozlov wrote: > >> Thank you, Tom >> >> Tom Rodriguez wrote: >>> On Jul 26, 2011, at 1:09 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7070134/webrev >>>> >>>> Fixed 7070134: Hotspot crashes with sigsegv from PorterStemmer >>>> >>>> It is an other case of "6831314: C2 may incorrectly change control of type nodes". Loop predicate RCE upper_bound check matches an other dominating RangeCheck and split_if optimization moves loads to dominating test. In the bug case (step4() method) two code branches have the same loads from the same array (b[]) and they are combined and moved above array's index check and above lower_bound predicate check. >>>> >>>> The fix is band-aid to not move data nodes which are attached to a predicate test to a dominating test. It is allowed to do that during loop peeling and loop predicates generation since they duplicate all checks. I also switched off predicate RCE optimization for counted loops with '!=' test since there is no guarantee that loop index will be in the range [init, limit) if init > limit. >>>> >>>> Added regression test. Refwokload (x64) shows no affect. >>> Why are the fixes in IfNode::dominated_by and PhaseIdealLoop::dominated_by different? IfNode just picks a different node but PhaseIdealLoop gives up. Can't PhaseIdealLoop pick a safe node? >> PhaseIdealLoop::dominated_by does not give up. Data nodes control edge will be changed to iff->in(0) later during Ideal transformation when this If node folds (since Bool node was replaced with constant). If you want, I can do it explicitly in dominated_by(): replace prevdom with iff->in(0). > > Oh I see. I didn't follow it closely enough. I think it's fine like it is. > >>> loopPredicate.cpp: >>> Is this line really needed? >>> ! Node* upper_bound_bol = rc_predicate(loop, ctrl, scale, offset, init, limit, stride, rng, true); >>> ! Node* upper_bound_bol = rc_predicate(loop, lower_bound_proj, scale, offset, init, limit, stride, rng, true); >>> I'm not against it since it's valid and maybe conceptually more correct but I'm unclear how it could have any effect on correctness. >> I changed it just for that reason: it is conceptually more correct. But I agree, it is not needed. > > OK. Look good. > > tom > >> Vladimir >> >>> tom >>>> > From vladimir.kozlov at oracle.com Tue Jul 26 17:52:46 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jul 2011 17:52:46 -0700 Subject: review for 7060619: C1 should respect inline and dontinline directives from CompilerOracle In-Reply-To: <2C4D8B5C-C15D-425E-AFCC-1D27CAB4011A@oracle.com> References: <2C4D8B5C-C15D-425E-AFCC-1D27CAB4011A@oracle.com> Message-ID: <4E2F615E.4030909@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7060619 > 52 lines changed: 30 ins; 22 del; 0 mod; 3825 unchg > > 7060619: C1 should respect inline and dontinline directives from CompilerOracle > Reviewed-by: > > This adds support for the inline and dontinline directives to C1. I > moved several correctness guards further up so that only purely > heuristic guards were at the end. Tested with various commands and > PrintCompilation PrintInlining. > From tom.rodriguez at oracle.com Tue Jul 26 17:57:05 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 26 Jul 2011 17:57:05 -0700 Subject: Request for reviews (M): 7069452: Cleanup NodeFlags In-Reply-To: <4E2F5663.40803@oracle.com> References: <4E29BC3F.5020703@oracle.com> <4E2F5663.40803@oracle.com> Message-ID: <38EAC88D-1D00-494A-B03A-C36EDB1BE7BD@oracle.com> On Jul 26, 2011, at 5:05 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> So is_Goto returns false for GotoNode? That doesn't seem right. > > It is used only for Mach nodes in block.cpp. Then maybe it should be is_MachGoto or we should introduce a MachGotoNode. tom > >> +bool Node::is_Goto() const { return is_Branch() && is_Mach() && (as_Mach()->ideal_Opcode() == Op_Goto); } >> why does this have an is_Branch test? Isn't testing the ideal_Opcode sufficient for the mach case? > > is_Branch() is bits test and ideal_Opcode() is virtual call. So it is a little speedup. I can set is_Branch flag in ideal GotoNode and change is_Goto() to: > > bool Node::is_Goto() const { > if (!is_Branch()) return false; > if (is_Mach()) return (as_Mach()->ideal_Opcode() == Op_Goto); > else return (Opcode() == Op_Goto); > } > > > I will look on Flag_is_block_start and Flag_is_safepoint_node. > > Thanks, > Vladimir > >> Flag_is_block_start seems to be minimally useful since it's only used to mark StartNode, at least as far as I can see. >> Flag_is_safepoint_node could probably be eliminated without too much work too. It's set for MachSafePointNode and cleared for MachCallLeaf. The adlc tries to clear it for FastUnlock but those inherit from MachNode, not MachSafePointNode so it seems slightly useless. >> tom >> On Jul 22, 2011, at 11:06 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7069452/webrev >>> >>> Fixed 7069452: Cleanup NodeFlags >>> >>> We are almost out of bits (16) for Node::NodeFlags. I removed flags which duplicate information in Node::NodeClasses. >>> is_Call() uses class_id check and is now valid only for ideal CallNode. >>> is_Goto() checks ideal_opcode(). >>> is_Vector() is replaced with check for Vector,VectorLoad,VectorStore classes. >>> MachProjNode was added to class_id check to avoid calling Opcode() in many places. MulNode was removed from class_id since it was used only in one place. >>> >>> I removed all logic associated with is_pc_relative flag. It was only checked in one place during long to short branch replacement. I replaced it with check in adlc parser - short branches should be defined only for a branch to a label, which means branch with PC relative offset. To relay on developer to set ins_pc_relative() was mistake since it could be used in wrong places. For example, it was specified for table jumps, calls and FastLock/FastUnlock. From igor.veresov at oracle.com Tue Jul 26 17:59:25 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 26 Jul 2011 17:59:25 -0700 Subject: review for 7060619: C1 should respect inline and dontinline directives from CompilerOracle In-Reply-To: <2C4D8B5C-C15D-425E-AFCC-1D27CAB4011A@oracle.com> References: <2C4D8B5C-C15D-425E-AFCC-1D27CAB4011A@oracle.com> Message-ID: <4E2F62ED.3040808@oracle.com> Looks good! igor On 7/26/11 4:59 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7060619 > 52 lines changed: 30 ins; 22 del; 0 mod; 3825 unchg > > 7060619: C1 should respect inline and dontinline directives from CompilerOracle > Reviewed-by: > > This adds support for the inline and dontinline directives to C1. I > moved several correctness guards further up so that only purely > heuristic guards were at the end. Tested with various commands and > PrintCompilation PrintInlining. > From vladimir.kozlov at oracle.com Tue Jul 26 17:57:45 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jul 2011 17:57:45 -0700 Subject: review for 7071427: AdapterFingerPrint can hold 8 entries per int In-Reply-To: <593DAA5D-671E-40B9-9C9C-F3A36A409970@oracle.com> References: <593DAA5D-671E-40B9-9C9C-F3A36A409970@oracle.com> Message-ID: <4E2F6289.6070405@oracle.com> Good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7071427 > 6 lines changed: 1 ins; 0 del; 5 mod; 2907 unchg > > 7071427: AdapterFingerPrint can hold 8 entries per int > Reviewed-by: > > While looking at another bug I noticed that the packed form of the > AdapterFingerPrint was only using 16 bits of the full 32 so I fixed > it. Tested with runThese. > From vladimir.kozlov at oracle.com Tue Jul 26 19:47:53 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jul 2011 19:47:53 -0700 Subject: Request for reviews (M): 7069452: Cleanup NodeFlags In-Reply-To: <38EAC88D-1D00-494A-B03A-C36EDB1BE7BD@oracle.com> References: <4E29BC3F.5020703@oracle.com> <4E2F5663.40803@oracle.com> <38EAC88D-1D00-494A-B03A-C36EDB1BE7BD@oracle.com> Message-ID: <4E2F7C59.50408@oracle.com> I updated webrev. http://cr.openjdk.java.net/~kvn/7069452/webrev is_Goto() is replaced with class_id check is_MachGoto(), new MachGotoNode is added. Flag_is_block_start flag check replaced with is_Start() check. is_safepoint_node() check is replaced with !is_MachCallLeaf() check. Corresponding code in adlc is removed since it is not needed. Thanks, Vladimir Tom Rodriguez wrote: > On Jul 26, 2011, at 5:05 PM, Vladimir Kozlov wrote: > >> Tom Rodriguez wrote: >>> So is_Goto returns false for GotoNode? That doesn't seem right. >> It is used only for Mach nodes in block.cpp. > > Then maybe it should be is_MachGoto or we should introduce a MachGotoNode. > > tom > >>> +bool Node::is_Goto() const { return is_Branch() && is_Mach() && (as_Mach()->ideal_Opcode() == Op_Goto); } >>> why does this have an is_Branch test? Isn't testing the ideal_Opcode sufficient for the mach case? >> is_Branch() is bits test and ideal_Opcode() is virtual call. So it is a little speedup. I can set is_Branch flag in ideal GotoNode and change is_Goto() to: >> >> bool Node::is_Goto() const { >> if (!is_Branch()) return false; >> if (is_Mach()) return (as_Mach()->ideal_Opcode() == Op_Goto); >> else return (Opcode() == Op_Goto); >> } >> >> >> I will look on Flag_is_block_start and Flag_is_safepoint_node. >> >> Thanks, >> Vladimir >> >>> Flag_is_block_start seems to be minimally useful since it's only used to mark StartNode, at least as far as I can see. >>> Flag_is_safepoint_node could probably be eliminated without too much work too. It's set for MachSafePointNode and cleared for MachCallLeaf. The adlc tries to clear it for FastUnlock but those inherit from MachNode, not MachSafePointNode so it seems slightly useless. >>> tom >>> On Jul 22, 2011, at 11:06 AM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7069452/webrev >>>> >>>> Fixed 7069452: Cleanup NodeFlags >>>> >>>> We are almost out of bits (16) for Node::NodeFlags. I removed flags which duplicate information in Node::NodeClasses. >>>> is_Call() uses class_id check and is now valid only for ideal CallNode. >>>> is_Goto() checks ideal_opcode(). >>>> is_Vector() is replaced with check for Vector,VectorLoad,VectorStore classes. >>>> MachProjNode was added to class_id check to avoid calling Opcode() in many places. MulNode was removed from class_id since it was used only in one place. >>>> >>>> I removed all logic associated with is_pc_relative flag. It was only checked in one place during long to short branch replacement. I replaced it with check in adlc parser - short branches should be defined only for a branch to a label, which means branch with PC relative offset. To relay on developer to set ins_pc_relative() was mistake since it could be used in wrong places. For example, it was specified for table jumps, calls and FastLock/FastUnlock. > From vladimir.kozlov at oracle.com Wed Jul 27 00:18:32 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 27 Jul 2011 07:18:32 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7070134: Hotspot crashes with sigsegv from PorterStemmer Message-ID: <20110727071839.486904775F@hg.openjdk.java.net> Changeset: 4e761e7e6e12 Author: kvn Date: 2011-07-26 19:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4e761e7e6e12 7070134: Hotspot crashes with sigsegv from PorterStemmer Summary: Do not move data nodes which are attached to a predicate test to a dominating test. Reviewed-by: never ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp + test/compiler/7070134/Stemmer.java + test/compiler/7070134/Test7070134.sh + test/compiler/7070134/words From christian.thalinger at oracle.com Wed Jul 27 11:29:16 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 27 Jul 2011 20:29:16 +0200 Subject: Review Request: zero/shark doesn't build after b147-fcs In-Reply-To: <5AF146A3-E2D2-4430-941B-437FA85A9515@oracle.com> References: <4E1C5E4F.1080307@zafena.se> <4E2049CA.8060506@LGonQn.Org> <5AF146A3-E2D2-4430-941B-437FA85A9515@oracle.com> Message-ID: On Jul 26, 2011, at 4:47 PM, Christian Thalinger wrote: > I will take care of these patches and the ones Xerxes posted. I filed one CR for all patches: 7071823: Zero: zero/shark doesn't build after b147-fcs -- Christian > > -- Christian > > On Jul 15, 2011, at 4:08 PM, Chris Phillips wrote: > >> Hi >> >> The following webrev's are for recent issues for zero/shark >> that stop it from building: >> >> http://lgonqn.org/temp/ChrisPhi/webrev-frame_zero.cpp-describe_pd_missing/ >> >> http://lgonqn.org/temp/ChrisPhi/webrev-sharedRuntime_zero.cpp-needs-rework-after-indy-reorg/ >> >> http://lgonqn.org/temp/ChrisPhi/webrev-sharkContext.hpp-typo-in-assert/ >> >> http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing/ >> >> The fixes from Xerxes R?nby , zero-methodHandle 7009923-regression >> and IA32 Hotspot FTBFS 7009309-regression are als required. >> >> These allow zero/shark to compile in product or debug for b147/fcs. There >> are still significant issues in shark beyond this >> and zero doesn't pass the invoke dynamic tests. >> >> Chris >> >> > From christian.thalinger at oracle.com Wed Jul 27 11:31:05 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 27 Jul 2011 20:31:05 +0200 Subject: Review Request: zero/shark doesn't build after b147-fcs In-Reply-To: <20110715145127.GA3311@redhat.com> References: <4E1C5E4F.1080307@zafena.se> <4E2049CA.8060506@LGonQn.Org> <20110715145127.GA3311@redhat.com> Message-ID: On Jul 15, 2011, at 4:51 PM, Gary Benson wrote: > Chris Phillips wrote: >> http://lgonqn.org/temp/ChrisPhi/webrev-sharkContext.hpp-typo-in-assert/ > > Nice catch :) > >> http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing/ > > You could probably make adapter_code_size be 0, or something small > 1ike 1*k. Nothing will presumably be generated into these buffers > after all? Chris, can you update the webrev so I can be sure the change works? -- Christian > > Cheers, > Gary > > -- > http://gbenson.net/ From christian.thalinger at oracle.com Wed Jul 27 11:53:29 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 27 Jul 2011 20:53:29 +0200 Subject: Review Request: zero/shark doesn't build after b147-fcs In-Reply-To: <20110715145127.GA3311@redhat.com> References: <4E1C5E4F.1080307@zafena.se> <4E2049CA.8060506@LGonQn.Org> <20110715145127.GA3311@redhat.com> Message-ID: <7ADFDF69-ADDA-4B24-8F78-82D52F46FD2B@oracle.com> On Jul 15, 2011, at 4:51 PM, Gary Benson wrote: > Chris Phillips wrote: >> http://lgonqn.org/temp/ChrisPhi/webrev-sharkContext.hpp-typo-in-assert/ > > Nice catch :) > >> http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing/ > > You could probably make adapter_code_size be 0, or something small > 1ike 1*k. Nothing will presumably be generated into these buffers > after all? Gary, can I add you as a reviewer? -- Christian > > Cheers, > Gary > > -- > http://gbenson.net/ From tom.rodriguez at oracle.com Wed Jul 27 15:32:41 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 27 Jul 2011 15:32:41 -0700 Subject: Request for reviews (M): 7069452: Cleanup NodeFlags In-Reply-To: <4E2F7C59.50408@oracle.com> References: <4E29BC3F.5020703@oracle.com> <4E2F5663.40803@oracle.com> <38EAC88D-1D00-494A-B03A-C36EDB1BE7BD@oracle.com> <4E2F7C59.50408@oracle.com> Message-ID: <0DC82D07-ED48-4A2D-9C4C-59A64CE3FDE3@oracle.com> That looks good. It looks like we could expand the number of bits dedicated to the class_id if we wanted to. Would that allow us to have more complete coverage in the is_Node tests we provide? tom On Jul 26, 2011, at 7:47 PM, Vladimir Kozlov wrote: > I updated webrev. > > http://cr.openjdk.java.net/~kvn/7069452/webrev > > is_Goto() is replaced with class_id check is_MachGoto(), new MachGotoNode is added. > > Flag_is_block_start flag check replaced with is_Start() check. > > is_safepoint_node() check is replaced with !is_MachCallLeaf() check. Corresponding code in adlc is removed since it is not needed. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Jul 26, 2011, at 5:05 PM, Vladimir Kozlov wrote: >>> Tom Rodriguez wrote: >>>> So is_Goto returns false for GotoNode? That doesn't seem right. >>> It is used only for Mach nodes in block.cpp. >> Then maybe it should be is_MachGoto or we should introduce a MachGotoNode. >> tom >>>> +bool Node::is_Goto() const { return is_Branch() && is_Mach() && (as_Mach()->ideal_Opcode() == Op_Goto); } >>>> why does this have an is_Branch test? Isn't testing the ideal_Opcode sufficient for the mach case? >>> is_Branch() is bits test and ideal_Opcode() is virtual call. So it is a little speedup. I can set is_Branch flag in ideal GotoNode and change is_Goto() to: >>> >>> bool Node::is_Goto() const { >>> if (!is_Branch()) return false; >>> if (is_Mach()) return (as_Mach()->ideal_Opcode() == Op_Goto); >>> else return (Opcode() == Op_Goto); >>> } >>> >>> >>> I will look on Flag_is_block_start and Flag_is_safepoint_node. >>> >>> Thanks, >>> Vladimir >>> >>>> Flag_is_block_start seems to be minimally useful since it's only used to mark StartNode, at least as far as I can see. >>>> Flag_is_safepoint_node could probably be eliminated without too much work too. It's set for MachSafePointNode and cleared for MachCallLeaf. The adlc tries to clear it for FastUnlock but those inherit from MachNode, not MachSafePointNode so it seems slightly useless. >>>> tom >>>> On Jul 22, 2011, at 11:06 AM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7069452/webrev >>>>> >>>>> Fixed 7069452: Cleanup NodeFlags >>>>> >>>>> We are almost out of bits (16) for Node::NodeFlags. I removed flags which duplicate information in Node::NodeClasses. >>>>> is_Call() uses class_id check and is now valid only for ideal CallNode. >>>>> is_Goto() checks ideal_opcode(). >>>>> is_Vector() is replaced with check for Vector,VectorLoad,VectorStore classes. >>>>> MachProjNode was added to class_id check to avoid calling Opcode() in many places. MulNode was removed from class_id since it was used only in one place. >>>>> >>>>> I removed all logic associated with is_pc_relative flag. It was only checked in one place during long to short branch replacement. I replaced it with check in adlc parser - short branches should be defined only for a branch to a label, which means branch with PC relative offset. To relay on developer to set ins_pc_relative() was mistake since it could be used in wrong places. For example, it was specified for table jumps, calls and FastLock/FastUnlock. From tom.rodriguez at oracle.com Wed Jul 27 17:17:50 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 28 Jul 2011 00:17:50 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7071427: AdapterFingerPrint can hold 8 entries per int Message-ID: <20110728001756.7CCAF4778C@hg.openjdk.java.net> Changeset: 0f34fdee809e Author: never Date: 2011-07-27 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0f34fdee809e 7071427: AdapterFingerPrint can hold 8 entries per int Reviewed-by: kvn ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/sharedRuntime.cpp From vladimir.kozlov at oracle.com Wed Jul 27 17:20:53 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Jul 2011 17:20:53 -0700 Subject: Request for reviews (M): 7069452: Cleanup NodeFlags In-Reply-To: <0DC82D07-ED48-4A2D-9C4C-59A64CE3FDE3@oracle.com> References: <4E29BC3F.5020703@oracle.com> <4E2F5663.40803@oracle.com> <38EAC88D-1D00-494A-B03A-C36EDB1BE7BD@oracle.com> <4E2F7C59.50408@oracle.com> <0DC82D07-ED48-4A2D-9C4C-59A64CE3FDE3@oracle.com> Message-ID: <4E30AB65.8070705@oracle.com> Thank you, Tom Yes, we have few free bits in _flags now, but it does not mean we will have them tomorrow :) I will take one for next cbcond changes to mark avoid_back_to_back instructions. I don't think we need to cover all classes in class_id, we can use Opcode(). At the beginning I did profiling of Opcode() usage and replaced only hot ones with class_id check but now it is expanded for other usages. We still have space in class_id so I would not expand it now. Thanks, Vladimir Tom Rodriguez wrote: > That looks good. > > It looks like we could expand the number of bits dedicated to the class_id if we wanted to. Would that allow us to have more complete coverage in the is_Node tests we provide? > > tom > > On Jul 26, 2011, at 7:47 PM, Vladimir Kozlov wrote: > >> I updated webrev. >> >> http://cr.openjdk.java.net/~kvn/7069452/webrev >> >> is_Goto() is replaced with class_id check is_MachGoto(), new MachGotoNode is added. >> >> Flag_is_block_start flag check replaced with is_Start() check. >> >> is_safepoint_node() check is replaced with !is_MachCallLeaf() check. Corresponding code in adlc is removed since it is not needed. >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> On Jul 26, 2011, at 5:05 PM, Vladimir Kozlov wrote: >>>> Tom Rodriguez wrote: >>>>> So is_Goto returns false for GotoNode? That doesn't seem right. >>>> It is used only for Mach nodes in block.cpp. >>> Then maybe it should be is_MachGoto or we should introduce a MachGotoNode. >>> tom >>>>> +bool Node::is_Goto() const { return is_Branch() && is_Mach() && (as_Mach()->ideal_Opcode() == Op_Goto); } >>>>> why does this have an is_Branch test? Isn't testing the ideal_Opcode sufficient for the mach case? >>>> is_Branch() is bits test and ideal_Opcode() is virtual call. So it is a little speedup. I can set is_Branch flag in ideal GotoNode and change is_Goto() to: >>>> >>>> bool Node::is_Goto() const { >>>> if (!is_Branch()) return false; >>>> if (is_Mach()) return (as_Mach()->ideal_Opcode() == Op_Goto); >>>> else return (Opcode() == Op_Goto); >>>> } >>>> >>>> >>>> I will look on Flag_is_block_start and Flag_is_safepoint_node. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> Flag_is_block_start seems to be minimally useful since it's only used to mark StartNode, at least as far as I can see. >>>>> Flag_is_safepoint_node could probably be eliminated without too much work too. It's set for MachSafePointNode and cleared for MachCallLeaf. The adlc tries to clear it for FastUnlock but those inherit from MachNode, not MachSafePointNode so it seems slightly useless. >>>>> tom >>>>> On Jul 22, 2011, at 11:06 AM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/7069452/webrev >>>>>> >>>>>> Fixed 7069452: Cleanup NodeFlags >>>>>> >>>>>> We are almost out of bits (16) for Node::NodeFlags. I removed flags which duplicate information in Node::NodeClasses. >>>>>> is_Call() uses class_id check and is now valid only for ideal CallNode. >>>>>> is_Goto() checks ideal_opcode(). >>>>>> is_Vector() is replaced with check for Vector,VectorLoad,VectorStore classes. >>>>>> MachProjNode was added to class_id check to avoid calling Opcode() in many places. MulNode was removed from class_id since it was used only in one place. >>>>>> >>>>>> I removed all logic associated with is_pc_relative flag. It was only checked in one place during long to short branch replacement. I replaced it with check in adlc parser - short branches should be defined only for a branch to a label, which means branch with PC relative offset. To relay on developer to set ins_pc_relative() was mistake since it could be used in wrong places. For example, it was specified for table jumps, calls and FastLock/FastUnlock. > From vladimir.kozlov at oracle.com Wed Jul 27 22:52:09 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 28 Jul 2011 05:52:09 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7069452: Cleanup NodeFlags Message-ID: <20110728055215.6079147798@hg.openjdk.java.net> Changeset: c7b60b601eb4 Author: kvn Date: 2011-07-27 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c7b60b601eb4 7069452: Cleanup NodeFlags Summary: Remove flags which duplicate information in Node::NodeClasses. Reviewed-by: 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/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp From christian.thalinger at oracle.com Thu Jul 28 02:14:14 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 28 Jul 2011 11:14:14 +0200 Subject: Review Request: zero-methodHandle 7009923-regression In-Reply-To: References: <4E1C5E4F.1080307@zafena.se> Message-ID: On Jul 13, 2011, at 1:48 AM, John Rose wrote: > Reviewed. -- John Just for the record here is the webrev for 7066143: http://cr.openjdk.java.net/~twisti/7066143/ John has already reviewed the changes and I did too. I'm going to push this now. -- Christian > > On Jul 12, 2011, at 7:46 AM, Xerxes R?nby wrote: > >> Hi all! >> >> Zero FTBFS after the recent 7009923 JSR292 fixes like this: >> openjdk/hotspot/src/cpu/zero/vm/stack_zero.cpp:72: >> error: no matching function for call to >> 'Exceptions::throw_stack_overflow_exception(JavaThread*&, const char [110], >> int)' >> openjdk/hotspot/src/share/vm/utilities/exceptions.hpp:147: >> note: candidates are: static void >> Exceptions::throw_stack_overflow_exception(Thread*, const char*, int, >> methodHandle) >> make[7]: *** [stack_zero.o] Error 1 >> >> This webrev updates Zero to handle the Exceptions::throw_stack_overflow_exception API change. >> >> http://labb.zafena.se/openjdk/zero-methodHandle-7009923-regression/ >> Summary of changes: 2 lines changed: 1 ins; 0 del; 1 mod; 87 unchg >> >> I don't have a bug id for this. >> >> I have signed the SCA. >> http://sca.java.net/CA_signatories.htm >> >> Cheers >> Xerxes > From ChrisPhi at LGonQn.Org Thu Jul 28 04:25:58 2011 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Thu, 28 Jul 2011 07:25:58 -0400 Subject: Review Request: zero/shark doesn't build after b147-fcs In-Reply-To: References: <4E1C5E4F.1080307@zafena.se> <4E2049CA.8060506@LGonQn.Org> <20110715145127.GA3311@redhat.com> Message-ID: <4E314746.7030302@LGonQn.Org> Hi Christian, Hmm missed this yesterday, The webrev is updated... http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing++ Chris On 27/07/11 02:31 PM, Christian Thalinger wrote: > On Jul 15, 2011, at 4:51 PM, Gary Benson wrote: > >> Chris Phillips wrote: >>> http://lgonqn.org/temp/ChrisPhi/webrev-sharkContext.hpp-typo-in-assert/ >> Nice catch :) >> >>> http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing/ >> You could probably make adapter_code_size be 0, or something small >> 1ike 1*k. Nothing will presumably be generated into these buffers >> after all? > Chris, can you update the webrev so I can be sure the change works? > > -- Christian > >> Cheers, >> Gary >> >> -- >> http://gbenson.net/ > > From christian.thalinger at oracle.com Thu Jul 28 05:42:44 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 28 Jul 2011 12:42:44 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7066143: JSR 292: Zero support after regressions from 7009923 and 7009309 Message-ID: <20110728124246.B51E3477A6@hg.openjdk.java.net> Changeset: d17bd0b18663 Author: twisti Date: 2011-07-28 02:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d17bd0b18663 7066143: JSR 292: Zero support after regressions from 7009923 and 7009309 Reviewed-by: jrose, twisti Contributed-by: Xerxes Ranby ! src/cpu/zero/vm/stack_zero.cpp ! src/share/vm/runtime/vmStructs.cpp From christian.thalinger at oracle.com Thu Jul 28 06:17:12 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 28 Jul 2011 15:17:12 +0200 Subject: Review Request: zero/shark doesn't build after b147-fcs In-Reply-To: <4E314746.7030302@LGonQn.Org> References: <4E1C5E4F.1080307@zafena.se> <4E2049CA.8060506@LGonQn.Org> <20110715145127.GA3311@redhat.com> <4E314746.7030302@LGonQn.Org> Message-ID: <918FC260-6174-4F8D-81E9-E540E01FC339@oracle.com> On Jul 28, 2011, at 1:25 PM, Chris Phillips wrote: > Hi Christian, > > Hmm missed this yesterday, > The webrev is updated... > > http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing++ Thanks. Here is the combined webrev: http://cr.openjdk.java.net/~twisti/7071823/ I removed the #ifdef notdef'd code from sharedRuntime_zero.cpp because you really don't need it anymore. I suppose chphilli at redhat.com is your RedHat email address and you're submitting this as a RedHat employee (because of the OCA)? -- Christian > > > Chris > > On 27/07/11 02:31 PM, Christian Thalinger wrote: >> On Jul 15, 2011, at 4:51 PM, Gary Benson wrote: >> >>> Chris Phillips wrote: >>>> http://lgonqn.org/temp/ChrisPhi/webrev-sharkContext.hpp-typo-in-assert/ >>> Nice catch :) >>> >>>> http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing/ >>> You could probably make adapter_code_size be 0, or something small >>> 1ike 1*k. Nothing will presumably be generated into these buffers >>> after all? >> Chris, can you update the webrev so I can be sure the change works? >> >> -- Christian >> >>> Cheers, >>> Gary >>> >>> -- >>> http://gbenson.net/ >> >> > From ahughes at redhat.com Thu Jul 28 06:59:23 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 28 Jul 2011 14:59:23 +0100 Subject: Review Request: zero/shark doesn't build after b147-fcs In-Reply-To: <4E314746.7030302@LGonQn.Org> References: <4E1C5E4F.1080307@zafena.se> <4E2049CA.8060506@LGonQn.Org> <20110715145127.GA3311@redhat.com> <4E314746.7030302@LGonQn.Org> Message-ID: <20110728135923.GR22822@rivendell.middle-earth.co.uk> On 07:25 Thu 28 Jul , Chris Phillips wrote: > Hi Christian, > > Hmm missed this yesterday, > The webrev is updated... > > http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing++ > I can't view this. > > Chris > > On 27/07/11 02:31 PM, Christian Thalinger wrote: > > On Jul 15, 2011, at 4:51 PM, Gary Benson wrote: > > > >> Chris Phillips wrote: > >>> http://lgonqn.org/temp/ChrisPhi/webrev-sharkContext.hpp-typo-in-assert/ > >> Nice catch :) > >> > >>> http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing/ > >> You could probably make adapter_code_size be 0, or something small > >> 1ike 1*k. Nothing will presumably be generated into these buffers > >> after all? > > Chris, can you update the webrev so I can be sure the change works? > > > > -- Christian > > > >> Cheers, > >> Gary > >> > >> -- > >> http://gbenson.net/ > > > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From schlosna at gmail.com Thu Jul 28 07:06:09 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Thu, 28 Jul 2011 10:06:09 -0400 Subject: Review Request: zero/shark doesn't build after b147-fcs In-Reply-To: <20110728135923.GR22822@rivendell.middle-earth.co.uk> References: <4E1C5E4F.1080307@zafena.se> <4E2049CA.8060506@LGonQn.Org> <20110715145127.GA3311@redhat.com> <4E314746.7030302@LGonQn.Org> <20110728135923.GR22822@rivendell.middle-earth.co.uk> Message-ID: On Thu, Jul 28, 2011 at 9:59 AM, Dr Andrew John Hughes wrote: >> http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing++ >> > > I can't view this. > Looks like a missing trailing slash. This URL works for me: http://lgonqn.org/temp/ChrisPhi/webrev-methodHandles_zero.hpp-missing++/ - Dave From vladimir.kozlov at oracle.com Thu Jul 28 09:13:25 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Jul 2011 09:13:25 -0700 Subject: Request for reviews (M): 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post on T5440 In-Reply-To: <4E275AA1.9070600@oracle.com> References: <4E275AA1.9070600@oracle.com> Message-ID: <4E318AA5.5060902@oracle.com> I still need reviews for this. Thanks, Vladimir Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7068051/webrev > > Fixed 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post on T5440 > > Changes I did for 7004535 are incorrect. They do not take into account > that cloning/moving predicates below merge points invalidate jvm states > recorded in predicate's uncommon trap. Removed predicate cloning from > loop peeling optimization and from split fall-in paths. But left it in > loop unswitching code which is safe, I think. Don't allow split loop > entry path in IGVN optimization for Phi nodes. And do not clone > predicates below merge points in split-if optimization. Removed > move_loop_predicate() and eliminate_loop_predicates() unused methods. > > Refworkload scores are not affected (sparc and x86). From tom.rodriguez at oracle.com Thu Jul 28 16:47:05 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 28 Jul 2011 16:47:05 -0700 Subject: review for 7071307: MethodHandle bimorphic inlining should consider the frequency Message-ID: <97DD49F1-0A6B-4F0C-88EA-76C93D054007@oracle.com> http://cr.openjdk.java.net/~never/7071307 46 lines changed: 27 ins; 6 del; 13 mod; 3568 unchg 7071307: MethodHandle bimorphic inlining should consider the frequency Reviewed-by: The fix for 7050554 added a bimorphic inline path but didn't take into account the frequency of the guarding test. This ends up treating both sides of the if as equally frequent which can lead to over inlining and overflowing the method inlining limits. The fix is to grab the frequency from the If and apply that to the branches. This addresses a major source of overinlining that can result in bad performance with JSR 292. We may do a later extension to this to actually do per call chain profiling of selectAlternative but that's a more complicated fix. I also fixed a problem with the ideal graph printer where debug_orig printing would go into an infinite loop. Tested with jruby and vm.mlvm tests. From tom.rodriguez at oracle.com Thu Jul 28 17:04:28 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 28 Jul 2011 17:04:28 -0700 Subject: Request for reviews (M): 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post on T5440 In-Reply-To: <4E318AA5.5060902@oracle.com> References: <4E275AA1.9070600@oracle.com> <4E318AA5.5060902@oracle.com> Message-ID: <928AC07A-AEF2-48DD-BD66-3D0DF55965B1@oracle.com> I think this looks ok. tom On Jul 28, 2011, at 9:13 AM, Vladimir Kozlov wrote: > I still need reviews for this. > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/7068051/webrev >> Fixed 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post on T5440 >> Changes I did for 7004535 are incorrect. They do not take into account that cloning/moving predicates below merge points invalidate jvm states recorded in predicate's uncommon trap. Removed predicate cloning from loop peeling optimization and from split fall-in paths. But left it in loop unswitching code which is safe, I think. Don't allow split loop entry path in IGVN optimization for Phi nodes. And do not clone predicates below merge points in split-if optimization. Removed move_loop_predicate() and eliminate_loop_predicates() unused methods. >> Refworkload scores are not affected (sparc and x86). From vladimir.kozlov at oracle.com Thu Jul 28 18:03:33 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Jul 2011 18:03:33 -0700 Subject: review for 7071307: MethodHandle bimorphic inlining should consider the frequency In-Reply-To: <97DD49F1-0A6B-4F0C-88EA-76C93D054007@oracle.com> References: <97DD49F1-0A6B-4F0C-88EA-76C93D054007@oracle.com> Message-ID: <4E3206E5.6060508@oracle.com> Tom, I think you need to check which path has IfTrue project to apply probability from IfNode. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7071307 > 46 lines changed: 27 ins; 6 del; 13 mod; 3568 unchg > > 7071307: MethodHandle bimorphic inlining should consider the frequency > Reviewed-by: > > The fix for 7050554 added a bimorphic inline path but didn't take into > account the frequency of the guarding test. This ends up treating > both sides of the if as equally frequent which can lead to over > inlining and overflowing the method inlining limits. The fix is to > grab the frequency from the If and apply that to the branches. This > addresses a major source of overinlining that can result in bad > performance with JSR 292. We may do a later extension to this to > actually do per call chain profiling of selectAlternative but that's a > more complicated fix. > > I also fixed a problem with the ideal graph printer where debug_orig > printing would go into an infinite loop. > > Tested with jruby and vm.mlvm tests. > From vladimir.kozlov at oracle.com Thu Jul 28 18:05:14 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Jul 2011 18:05:14 -0700 Subject: Request for reviews (M): 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post on T5440 In-Reply-To: <928AC07A-AEF2-48DD-BD66-3D0DF55965B1@oracle.com> References: <4E275AA1.9070600@oracle.com> <4E318AA5.5060902@oracle.com> <928AC07A-AEF2-48DD-BD66-3D0DF55965B1@oracle.com> Message-ID: <4E32074A.9040201@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > I think this looks ok. > > tom > > On Jul 28, 2011, at 9:13 AM, Vladimir Kozlov wrote: > >> I still need reviews for this. >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7068051/webrev >>> Fixed 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post on T5440 >>> Changes I did for 7004535 are incorrect. They do not take into account that cloning/moving predicates below merge points invalidate jvm states recorded in predicate's uncommon trap. Removed predicate cloning from loop peeling optimization and from split fall-in paths. But left it in loop unswitching code which is safe, I think. Don't allow split loop entry path in IGVN optimization for Phi nodes. And do not clone predicates below merge points in split-if optimization. Removed move_loop_predicate() and eliminate_loop_predicates() unused methods. >>> Refworkload scores are not affected (sparc and x86). > From igor.veresov at oracle.com Thu Jul 28 18:22:59 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 28 Jul 2011 18:22:59 -0700 Subject: review for 7071307: MethodHandle bimorphic inlining should consider the frequency In-Reply-To: <97DD49F1-0A6B-4F0C-88EA-76C93D054007@oracle.com> References: <97DD49F1-0A6B-4F0C-88EA-76C93D054007@oracle.com> Message-ID: <4E320B73.6050003@oracle.com> Seems fine! igor On 7/28/11 4:47 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7071307 > 46 lines changed: 27 ins; 6 del; 13 mod; 3568 unchg > > 7071307: MethodHandle bimorphic inlining should consider the frequency > Reviewed-by: > > The fix for 7050554 added a bimorphic inline path but didn't take into > account the frequency of the guarding test. This ends up treating > both sides of the if as equally frequent which can lead to over > inlining and overflowing the method inlining limits. The fix is to > grab the frequency from the If and apply that to the branches. This > addresses a major source of overinlining that can result in bad > performance with JSR 292. We may do a later extension to this to > actually do per call chain profiling of selectAlternative but that's a > more complicated fix. > > I also fixed a problem with the ideal graph printer where debug_orig > printing would go into an infinite loop. > > Tested with jruby and vm.mlvm tests. > From tom.rodriguez at oracle.com Thu Jul 28 23:59:40 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 29 Jul 2011 06:59:40 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7060619: C1 should respect inline and dontinline directives from CompilerOracle Message-ID: <20110729065944.C2DDC477D7@hg.openjdk.java.net> Changeset: ce3e1d4dc416 Author: never Date: 2011-07-28 13:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ce3e1d4dc416 7060619: C1 should respect inline and dontinline directives from CompilerOracle Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp From tom.rodriguez at oracle.com Fri Jul 29 10:24:25 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 29 Jul 2011 10:24:25 -0700 Subject: review for 7071307: MethodHandle bimorphic inlining should consider the frequency In-Reply-To: <4E3206E5.6060508@oracle.com> References: <97DD49F1-0A6B-4F0C-88EA-76C93D054007@oracle.com> <4E3206E5.6060508@oracle.com> Message-ID: On Jul 28, 2011, at 6:03 PM, Vladimir Kozlov wrote: > Tom, > > I think you need to check which path has IfTrue project to apply probability from IfNode. I originally had code to do that but I convinced myself it wasn't needed though now I can't imagine what I was thinking. Currently these if's are all structured such that they don't need to be swapped but there's no reason they couldn't be. I've updated the webrev. tom > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7071307 >> 46 lines changed: 27 ins; 6 del; 13 mod; 3568 unchg >> 7071307: MethodHandle bimorphic inlining should consider the frequency >> Reviewed-by: >> The fix for 7050554 added a bimorphic inline path but didn't take into >> account the frequency of the guarding test. This ends up treating >> both sides of the if as equally frequent which can lead to over >> inlining and overflowing the method inlining limits. The fix is to >> grab the frequency from the If and apply that to the branches. This >> addresses a major source of overinlining that can result in bad >> performance with JSR 292. We may do a later extension to this to >> actually do per call chain profiling of selectAlternative but that's a >> more complicated fix. >> I also fixed a problem with the ideal graph printer where debug_orig >> printing would go into an infinite loop. >> Tested with jruby and vm.mlvm tests. From vladimir.kozlov at oracle.com Fri Jul 29 11:08:48 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Jul 2011 11:08:48 -0700 Subject: review for 7071307: MethodHandle bimorphic inlining should consider the frequency In-Reply-To: References: <97DD49F1-0A6B-4F0C-88EA-76C93D054007@oracle.com> <4E3206E5.6060508@oracle.com> Message-ID: <4E32F730.7030005@oracle.com> Tom, First, question: mh parameter passed to PredictedDynamicCallGenerator() is taking from method_handle->in(1) path, can in(2) has different mh? Next, cg1 should have higher prob to generated it first in the code (it is passed as if_hit into PredictedDynamicCallGenerator()). I think you need to do it like this: + float prob = PROB_FAIR; + int if_hit = 1; + Node* meth_region = method_handle->in(0); + if (meth_region->is_Region() && + meth_region->in(1)->is_Proj() && meth_region->in(2)->is_Proj() && + meth_region->in(1)->in(0) == meth_region->in(2)->in(0) && + meth_region->in(1)->in(0)->is_If()) { + // If diamond, so grab the probability of the test to drive the inlining below + prob = meth_region->in(1)->in(0)->as_If()->_prob; + if (meth_region->in(1)->is_IfFalse()) if_hit = 2; + } + // selectAlternative idiom merging two constant MethodHandles. // Generate a guard so that each can be inlined. We might want to // do more inputs at later point but this gets the most common // case. + if (prob < PROB_FAIR) { + // cg1 should have higher prob to generated it first in the code. + if_hit = 3-if_hit; + prob = 1.0 - prob; + } + CallGenerator* cg1 = for_method_handle_inline(method_handle->in(if_hit), jvms, caller, callee, profile.rescale(prob)); + CallGenerator* cg2 = for_method_handle_inline(method_handle->in(3-if_hit), jvms, caller, callee, profile.rescale(1.0 - prob)); + if (cg1 != NULL && cg2 != NULL) { Thanks, Vladimir Tom Rodriguez wrote: > On Jul 28, 2011, at 6:03 PM, Vladimir Kozlov wrote: > >> Tom, >> >> I think you need to check which path has IfTrue project to apply probability from IfNode. > > I originally had code to do that but I convinced myself it wasn't needed though now I can't imagine what I was thinking. Currently these if's are all structured such that they don't need to be swapped but there's no reason they couldn't be. I've updated the webrev. > > tom > >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7071307 >>> 46 lines changed: 27 ins; 6 del; 13 mod; 3568 unchg >>> 7071307: MethodHandle bimorphic inlining should consider the frequency >>> Reviewed-by: >>> The fix for 7050554 added a bimorphic inline path but didn't take into >>> account the frequency of the guarding test. This ends up treating >>> both sides of the if as equally frequent which can lead to over >>> inlining and overflowing the method inlining limits. The fix is to >>> grab the frequency from the If and apply that to the branches. This >>> addresses a major source of overinlining that can result in bad >>> performance with JSR 292. We may do a later extension to this to >>> actually do per call chain profiling of selectAlternative but that's a >>> more complicated fix. >>> I also fixed a problem with the ideal graph printer where debug_orig >>> printing would go into an infinite loop. >>> Tested with jruby and vm.mlvm tests. > From vladimir.kozlov at oracle.com Fri Jul 29 11:26:02 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Jul 2011 11:26:02 -0700 Subject: review for 7071307: MethodHandle bimorphic inlining should consider the frequency In-Reply-To: <4E32F730.7030005@oracle.com> References: <97DD49F1-0A6B-4F0C-88EA-76C93D054007@oracle.com> <4E3206E5.6060508@oracle.com> <4E32F730.7030005@oracle.com> Message-ID: <4E32FB3A.5010001@oracle.com> I just realized that your are generating diamond code and not bimorphic which has third failure path. And since you generate diamond it does not matter what probability of in(1) path. So the code you suggested will work. Sorry for the noise. Thanks, Vladimir Vladimir Kozlov wrote: > Tom, > > First, question: mh parameter passed to PredictedDynamicCallGenerator() > is taking from method_handle->in(1) path, can in(2) has different mh? > > Next, cg1 should have higher prob to generated it first in the code (it > is passed as if_hit into PredictedDynamicCallGenerator()). I think you > need to do it like this: > > + float prob = PROB_FAIR; > + int if_hit = 1; > + Node* meth_region = method_handle->in(0); > + if (meth_region->is_Region() && > + meth_region->in(1)->is_Proj() && meth_region->in(2)->is_Proj() && > + meth_region->in(1)->in(0) == meth_region->in(2)->in(0) && > + meth_region->in(1)->in(0)->is_If()) { > + // If diamond, so grab the probability of the test to drive the > inlining below > + prob = meth_region->in(1)->in(0)->as_If()->_prob; > + if (meth_region->in(1)->is_IfFalse()) if_hit = 2; > + } > + > // selectAlternative idiom merging two constant MethodHandles. > // Generate a guard so that each can be inlined. We might want to > // do more inputs at later point but this gets the most common > // case. > + if (prob < PROB_FAIR) { > + // cg1 should have higher prob to generated it first in the code. > + if_hit = 3-if_hit; > + prob = 1.0 - prob; > + } > + CallGenerator* cg1 = > for_method_handle_inline(method_handle->in(if_hit), jvms, caller, > callee, profile.rescale(prob)); > + CallGenerator* cg2 = > for_method_handle_inline(method_handle->in(3-if_hit), jvms, caller, > callee, profile.rescale(1.0 - prob)); > + if (cg1 != NULL && cg2 != NULL) { > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Jul 28, 2011, at 6:03 PM, Vladimir Kozlov wrote: >> >>> Tom, >>> >>> I think you need to check which path has IfTrue project to apply >>> probability from IfNode. >> >> I originally had code to do that but I convinced myself it wasn't >> needed though now I can't imagine what I was thinking. Currently >> these if's are all structured such that they don't need to be swapped >> but there's no reason they couldn't be. I've updated the webrev. >> >> tom >> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7071307 >>>> 46 lines changed: 27 ins; 6 del; 13 mod; 3568 unchg >>>> 7071307: MethodHandle bimorphic inlining should consider the frequency >>>> Reviewed-by: >>>> The fix for 7050554 added a bimorphic inline path but didn't take into >>>> account the frequency of the guarding test. This ends up treating >>>> both sides of the if as equally frequent which can lead to over >>>> inlining and overflowing the method inlining limits. The fix is to >>>> grab the frequency from the If and apply that to the branches. This >>>> addresses a major source of overinlining that can result in bad >>>> performance with JSR 292. We may do a later extension to this to >>>> actually do per call chain profiling of selectAlternative but that's a >>>> more complicated fix. >>>> I also fixed a problem with the ideal graph printer where debug_orig >>>> printing would go into an infinite loop. >>>> Tested with jruby and vm.mlvm tests. >> From tom.rodriguez at oracle.com Fri Jul 29 11:54:04 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 29 Jul 2011 11:54:04 -0700 Subject: review for 7071307: MethodHandle bimorphic inlining should consider the frequency In-Reply-To: <4E32FB3A.5010001@oracle.com> References: <97DD49F1-0A6B-4F0C-88EA-76C93D054007@oracle.com> <4E3206E5.6060508@oracle.com> <4E32F730.7030005@oracle.com> <4E32FB3A.5010001@oracle.com> Message-ID: On Jul 29, 2011, at 11:26 AM, Vladimir Kozlov wrote: > I just realized that your are generating diamond code and not bimorphic which has third failure path. And since you generate diamond it does not matter what probability of in(1) path. So the code you suggested will work. Sorry for the noise. I was just replying with that explanation. ;) Thanks. tom > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> Tom, >> First, question: mh parameter passed to PredictedDynamicCallGenerator() is taking from method_handle->in(1) path, can in(2) has different mh? >> Next, cg1 should have higher prob to generated it first in the code (it is passed as if_hit into PredictedDynamicCallGenerator()). I think you need to do it like this: >> + float prob = PROB_FAIR; >> + int if_hit = 1; >> + Node* meth_region = method_handle->in(0); >> + if (meth_region->is_Region() && >> + meth_region->in(1)->is_Proj() && meth_region->in(2)->is_Proj() && >> + meth_region->in(1)->in(0) == meth_region->in(2)->in(0) && >> + meth_region->in(1)->in(0)->is_If()) { >> + // If diamond, so grab the probability of the test to drive the inlining below >> + prob = meth_region->in(1)->in(0)->as_If()->_prob; >> + if (meth_region->in(1)->is_IfFalse()) if_hit = 2; >> + } >> + >> // selectAlternative idiom merging two constant MethodHandles. >> // Generate a guard so that each can be inlined. We might want to >> // do more inputs at later point but this gets the most common >> // case. >> + if (prob < PROB_FAIR) { >> + // cg1 should have higher prob to generated it first in the code. >> + if_hit = 3-if_hit; >> + prob = 1.0 - prob; >> + } >> + CallGenerator* cg1 = for_method_handle_inline(method_handle->in(if_hit), jvms, caller, callee, profile.rescale(prob)); >> + CallGenerator* cg2 = for_method_handle_inline(method_handle->in(3-if_hit), jvms, caller, callee, profile.rescale(1.0 - prob)); >> + if (cg1 != NULL && cg2 != NULL) { >> Thanks, >> Vladimir >> Tom Rodriguez wrote: >>> On Jul 28, 2011, at 6:03 PM, Vladimir Kozlov wrote: >>> >>>> Tom, >>>> >>>> I think you need to check which path has IfTrue project to apply probability from IfNode. >>> >>> I originally had code to do that but I convinced myself it wasn't needed though now I can't imagine what I was thinking. Currently these if's are all structured such that they don't need to be swapped but there's no reason they couldn't be. I've updated the webrev. >>> >>> tom >>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/7071307 >>>>> 46 lines changed: 27 ins; 6 del; 13 mod; 3568 unchg >>>>> 7071307: MethodHandle bimorphic inlining should consider the frequency >>>>> Reviewed-by: >>>>> The fix for 7050554 added a bimorphic inline path but didn't take into >>>>> account the frequency of the guarding test. This ends up treating >>>>> both sides of the if as equally frequent which can lead to over >>>>> inlining and overflowing the method inlining limits. The fix is to >>>>> grab the frequency from the If and apply that to the branches. This >>>>> addresses a major source of overinlining that can result in bad >>>>> performance with JSR 292. We may do a later extension to this to >>>>> actually do per call chain profiling of selectAlternative but that's a >>>>> more complicated fix. >>>>> I also fixed a problem with the ideal graph printer where debug_orig >>>>> printing would go into an infinite loop. >>>>> Tested with jruby and vm.mlvm tests. >>> From christian.thalinger at oracle.com Fri Jul 29 12:43:55 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 29 Jul 2011 21:43:55 +0200 Subject: review for 7071307: MethodHandle bimorphic inlining should consider the frequency In-Reply-To: References: <97DD49F1-0A6B-4F0C-88EA-76C93D054007@oracle.com> <4E3206E5.6060508@oracle.com> Message-ID: On Jul 29, 2011, at 7:24 PM, Tom Rodriguez wrote: > > On Jul 28, 2011, at 6:03 PM, Vladimir Kozlov wrote: > >> Tom, >> >> I think you need to check which path has IfTrue project to apply probability from IfNode. > > I originally had code to do that but I convinced myself it wasn't needed though now I can't imagine what I was thinking. Currently these if's are all structured such that they don't need to be swapped but there's no reason they couldn't be. I've updated the webrev. Looks good. -- Christian > > tom > >> >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7071307 >>> 46 lines changed: 27 ins; 6 del; 13 mod; 3568 unchg >>> 7071307: MethodHandle bimorphic inlining should consider the frequency >>> Reviewed-by: >>> The fix for 7050554 added a bimorphic inline path but didn't take into >>> account the frequency of the guarding test. This ends up treating >>> both sides of the if as equally frequent which can lead to over >>> inlining and overflowing the method inlining limits. The fix is to >>> grab the frequency from the If and apply that to the branches. This >>> addresses a major source of overinlining that can result in bad >>> performance with JSR 292. We may do a later extension to this to >>> actually do per call chain profiling of selectAlternative but that's a >>> more complicated fix. >>> I also fixed a problem with the ideal graph printer where debug_orig >>> printing would go into an infinite loop. >>> Tested with jruby and vm.mlvm tests. > From vladimir.kozlov at oracle.com Fri Jul 29 13:49:32 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 29 Jul 2011 20:49:32 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post Message-ID: <20110729204937.088F1477F7@hg.openjdk.java.net> Changeset: c96c3eb1efae Author: kvn Date: 2011-07-29 09:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c96c3eb1efae 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post Summary: Removed predicate cloning from loop peeling optimization and from split fall-in paths. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/phaseX.hpp