From tom.rodriguez at oracle.com Tue Mar 1 04:52:19 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 01 Mar 2011 12:52:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7023229: extraneous include of precompiled.hpp in hsdis.c Message-ID: <20110301125225.9701B47B74@hg.openjdk.java.net> Changeset: 50c0f22d6d0e Author: never Date: 2011-02-28 17:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/50c0f22d6d0e 7023229: extraneous include of precompiled.hpp in hsdis.c Reviewed-by: never, jrose Contributed-by: volker.simonis at gmail.com ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c From tom.rodriguez at oracle.com Tue Mar 1 10:32:29 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 1 Mar 2011 10:32:29 -0800 Subject: review (S) for 6965570: assert(!needs_patching && x->is_loaded(), "how do we know it's volatile if it's not loaded") Message-ID: http://cr.openjdk.java.net/~never/6965570 6965570: assert(!needs_patching && x->is_loaded(),"how do we know it's volatile if it's not loaded") Reviewed-by: During code generation for a volatile getfield in an outer class we've managed to resolve the inner class symbolically but the constant pool reference hasn't actually been resolved. This results in a field reference that should be patched so that the proper access checks are performed by constant pool resolution. In this case the field is volatile and LIRGenerator expects that if the class was loaded and we can see that's it actually volatile that a patch must not be needed. In debug mode this asserts but in product mode it generates code to uses max_jint for the field offset. The fix is to always respect the needs_patching flag. We could makes the patching machinery handle this more normally but that would complicate patching even more. It's a rare case so allowing deopt in Runtime1::patch_code to handle it is the easiest way to go. Part of the confusion stems from the is_loaded flag on AccessField which doesn't really mean what it says, so I've removed it and pushed all the needs_patching logic up into GraphBuilder. is_initialized() is similarly confusing since it really means does this static field need patching. I've eliminated that flag from AccessField and captured that logic in a new method that is used instead. Tested with runthese with and without PatchALot, ctw, and the nsk jvmti tests. From igor.veresov at oracle.com Tue Mar 1 11:25:31 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 01 Mar 2011 11:25:31 -0800 Subject: review (S) for 6965570: assert(!needs_patching && x->is_loaded(), "how do we know it's volatile if it's not loaded") In-Reply-To: <4176D8A3-4856-4B5C-A316-F17D6C720C30@oracle.com> References: <4176D8A3-4856-4B5C-A316-F17D6C720C30@oracle.com> Message-ID: <4D6D482B.7050908@oracle.com> Looks good. igor On 2/28/11 5:37 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6965570 > > 6965570: assert(!needs_patching&& x->is_loaded(),"how do we know it's volatile if it's not loaded") > Reviewed-by: > > During code generation for a volatile getfield in an outer class we've > managed to resolve the inner class symbolically but the constant pool > reference hasn't actually been resolved. This results in a field > reference that should be patched so that the proper access checks are > performed by constant pool resolution. In this case the field is > volatile and LIRGenerator expects that if the class was loaded and we > can see that's it actually volatile that a patch must not be needed. > In debug mode this asserts but in product mode it generates code to > uses max_jint for the field offset. The fix is to always respect the > needs_patching flag. We could makes the patching machinery handle > this more normally but that would complicate patching even more. It's > a rare case so allowing deopt in Runtime1::patch_code to handle it is > the easiest way to go. > > Part of the confusion stems from the is_loaded flag on AccessField > which doesn't really mean what it says, so I've removed it and pushed > all the needs_patching logic up into GraphBuilder. is_initialized() > is similarly confusing since it really means does this static field > need patching. I've eliminated that flag from AccessField and > captured that logic in a new method that is used instead. Tested with > runthese with and without PatchALot, ctw, and the nsk jvmti tests From igor.veresov at oracle.com Tue Mar 1 12:53:57 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 01 Mar 2011 12:53:57 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D6D55B6.8000904@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> <4D6D55B6.8000904@oracle.com> Message-ID: <4D6D5CE5.6070200@oracle.com> On 3/1/11 12:23 PM, Vladimir Kozlov wrote: > I have only comments about library_call.cpp: > > Why "false" in copy_to_clone()? It seems, you get double barriers in > this method as well: > 4085 /*dest_uninitialized*/false); It doesn't matter here, because we're treating it all as T_LONGs, so there's going to be no barriers. But for consistency I suppose it could be "true" here. > > > 4596 // so the the pre-barriers wouldn't peek into the old values. See > CR 6627983. > ^ 'the' 2 times ^ unitialized Fixed. Thanks! > 4597 const bool& dest_uninitialized = must_clear_dest; > ^ why reference? > John wanted a separate variable to inform arraycopy of whether the target is initialized. This variable should in fact follow the state of the must_clear_dest, so I decided to make it a reference, so that when must_clear_dest changes so does dest_uninitialized. If you don't like that I can make it a regular variable. Although I would rather just used must_clear_dest for everything and not replicate the state. Thanks, igor > The rest changes seems fine. > > Thanks, > Vladimir > > Igor Veresov wrote: >> John, all, >> >> I've updated the change, making corrections that John recommended. >> Also, now the decision about what to do with the barrier is deferred >> to the barrier emitting procedure. Thus, if a new pre-barrier is added >> that would need to do something even in case if the destination array >> is uninitialized it can be handled properly. >> >> New webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.01 >> >> Thanks, >> igor >> >> >> >> On 2/25/11 8:25 PM, Igor Veresov wrote: >>> I think my fix is not good enough for the case when we'll need >>> prebarriers that will not require the previous value and these could be >>> a reality in the future. So, it is generally incorrect to elide >>> prebarriers but is only ok for a specific flavor. I'm working to >>> alleviate this problem a little bit and will post the updated version >>> early next week. John, I will also address your recommendations. >>> >>> Thanks, >>> igor >>> >>> >>> On 2/24/11 6:28 PM, John Rose wrote: >>>> On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: >>>> >>>>> On 2/24/11 5:27 PM, John Rose wrote: >>>>>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>>>>> >>>>>> If it is simply foo(..., !must_clear_dest), it becomes hard for >>>>>> maintainers to see what the argument means. >>>>> >>>>> I can see your point but I just didn't want to introduce additional >>>>> clutter. For example generate_block_arraycopy() never requires >>>>> barrier suppression, so why do we need to add an argument there? >>>> >>>> There's not a strong need. An extra "true" or "false" would be a >>>> little clutter, but it would also hint to programmers what's going on. >>>> It's a esthetic call mostly... >>>> >>>> (Here's some meandering on the subject. While reading the code, if I >>>> am tracing the flow from caller definition to callee definition, when >>>> arguments are explicit I can observe them directly. But if they are >>>> defaulted, then I have to visit the callee's declaration as well. I >>>> have to visit three locations in the source instead of two. I >>>> personally find this awkward unless the meaning of the defaulted >>>> argument is immediately and intuitively obvious. In this case the >>>> meaning of the argument is subtly related to other parts of the >>>> system.) >>>> >>>>> From the debugging standpoint it's way better to emit a barrier than >>>>> not to. Missing barriers will be a nightmare to find. So, I'd rather >>>>> have a barrier erroneously emitted in some path by default, which >>>>> would make the marking crash almost immediately. >>>> >>>> Good point. >>>> >>>>> As for using !must_clear_dest as a gate, I thought it would more >>>>> clearly convey to the reader the reason why the barrier is suppressed >>>>> - because the dest array is not cleared and contains garbage, so the >>>>> reader won't have to go back to see in which cases use_pre_barrier is >>>>> set. Perhaps I should add more comments. >>>> >>>> The bug number would help a lot, I think. It's a subtle interaction >>>> between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 >>>> invariants. >>>> >>>>>> In the stub generator the optional boolean is OK as is, although I >>>>>> generally prefer optional booleans to default to 'false'. Given the >>>>>> way the bug is structured, I keep wanting to call it >>>>>> 'suppress_pre_barrier', meaning "just this once, trust me when I >>>>>> tell you not to emit the pre-barrier, if there is one." >>>>>> >>>>> >>>>> That's pretty much equivalent. I don't have strong feelings about >>>>> this and will change it if you think it's more readable. >>>> >>>> I do think it would be more readable. It could be just an old Lisper >>>> bias, though: Optional arguments default to NULL, which is the false >>>> value in Lisp. >>>> >>>> -- John >>> >> From vladimir.kozlov at oracle.com Tue Mar 1 12:23:18 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Mar 2011 12:23:18 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D6C5EF1.70801@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> Message-ID: <4D6D55B6.8000904@oracle.com> I have only comments about library_call.cpp: Why "false" in copy_to_clone()? It seems, you get double barriers in this method as well: 4085 /*dest_uninitialized*/false); 4596 // so the the pre-barriers wouldn't peek into the old values. See CR 6627983. ^ 'the' 2 times ^ unitialized 4597 const bool& dest_uninitialized = must_clear_dest; ^ why reference? The rest changes seems fine. Thanks, Vladimir Igor Veresov wrote: > John, all, > > I've updated the change, making corrections that John recommended. Also, > now the decision about what to do with the barrier is deferred to the > barrier emitting procedure. Thus, if a new pre-barrier is added that > would need to do something even in case if the destination array is > uninitialized it can be handled properly. > > New webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.01 > > Thanks, > igor > > > > On 2/25/11 8:25 PM, Igor Veresov wrote: >> I think my fix is not good enough for the case when we'll need >> prebarriers that will not require the previous value and these could be >> a reality in the future. So, it is generally incorrect to elide >> prebarriers but is only ok for a specific flavor. I'm working to >> alleviate this problem a little bit and will post the updated version >> early next week. John, I will also address your recommendations. >> >> Thanks, >> igor >> >> >> On 2/24/11 6:28 PM, John Rose wrote: >>> On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: >>> >>>> On 2/24/11 5:27 PM, John Rose wrote: >>>>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>>>> >>>>> If it is simply foo(..., !must_clear_dest), it becomes hard for >>>>> maintainers to see what the argument means. >>>> >>>> I can see your point but I just didn't want to introduce additional >>>> clutter. For example generate_block_arraycopy() never requires >>>> barrier suppression, so why do we need to add an argument there? >>> >>> There's not a strong need. An extra "true" or "false" would be a >>> little clutter, but it would also hint to programmers what's going on. >>> It's a esthetic call mostly... >>> >>> (Here's some meandering on the subject. While reading the code, if I >>> am tracing the flow from caller definition to callee definition, when >>> arguments are explicit I can observe them directly. But if they are >>> defaulted, then I have to visit the callee's declaration as well. I >>> have to visit three locations in the source instead of two. I >>> personally find this awkward unless the meaning of the defaulted >>> argument is immediately and intuitively obvious. In this case the >>> meaning of the argument is subtly related to other parts of the system.) >>> >>>> From the debugging standpoint it's way better to emit a barrier than >>>> not to. Missing barriers will be a nightmare to find. So, I'd rather >>>> have a barrier erroneously emitted in some path by default, which >>>> would make the marking crash almost immediately. >>> >>> Good point. >>> >>>> As for using !must_clear_dest as a gate, I thought it would more >>>> clearly convey to the reader the reason why the barrier is suppressed >>>> - because the dest array is not cleared and contains garbage, so the >>>> reader won't have to go back to see in which cases use_pre_barrier is >>>> set. Perhaps I should add more comments. >>> >>> The bug number would help a lot, I think. It's a subtle interaction >>> between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 >>> invariants. >>> >>>>> In the stub generator the optional boolean is OK as is, although I >>>>> generally prefer optional booleans to default to 'false'. Given the >>>>> way the bug is structured, I keep wanting to call it >>>>> 'suppress_pre_barrier', meaning "just this once, trust me when I >>>>> tell you not to emit the pre-barrier, if there is one." >>>>> >>>> >>>> That's pretty much equivalent. I don't have strong feelings about >>>> this and will change it if you think it's more readable. >>> >>> I do think it would be more readable. It could be just an old Lisper >>> bias, though: Optional arguments default to NULL, which is the false >>> value in Lisp. >>> >>> -- John >> > From tom.rodriguez at oracle.com Tue Mar 1 13:08:12 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 1 Mar 2011 13:08:12 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D6D5CE5.6070200@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> <4D6D55B6.8000904@oracle.com> <4D6D5CE5.6070200@oracle.com> Message-ID: <5DD47A92-E731-4FDD-821C-35BA5A1C8332@oracle.com> On Mar 1, 2011, at 12:53 PM, Igor Veresov wrote: > On 3/1/11 12:23 PM, Vladimir Kozlov wrote: >> I have only comments about library_call.cpp: >> >> Why "false" in copy_to_clone()? It seems, you get double barriers in >> this method as well: >> 4085 /*dest_uninitialized*/false); > > It doesn't matter here, because we're treating it all as T_LONGs, so there's going to be no barriers. But for consistency I suppose it could be "true" here. > >> >> >> 4596 // so the the pre-barriers wouldn't peek into the old values. See >> CR 6627983. >> ^ 'the' 2 times ^ unitialized > Fixed. Thanks! > >> 4597 const bool& dest_uninitialized = must_clear_dest; >> ^ why reference? >> > > John wanted a separate variable to inform arraycopy of whether the target is initialized. This variable should in fact follow the state of the must_clear_dest, so I decided to make it a reference, so that when must_clear_dest changes so does dest_uninitialized. If you don't like that I can make it a regular variable. > > Although I would rather just used must_clear_dest for everything and not replicate the state. no local variable references please. Just pass must_clear_dest or rename it to dest_uninitalized. tom > > > Thanks, > igor > > >> The rest changes seems fine. >> >> Thanks, >> Vladimir >> >> Igor Veresov wrote: >>> John, all, >>> >>> I've updated the change, making corrections that John recommended. >>> Also, now the decision about what to do with the barrier is deferred >>> to the barrier emitting procedure. Thus, if a new pre-barrier is added >>> that would need to do something even in case if the destination array >>> is uninitialized it can be handled properly. >>> >>> New webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.01 >>> >>> Thanks, >>> igor >>> >>> >>> >>> On 2/25/11 8:25 PM, Igor Veresov wrote: >>>> I think my fix is not good enough for the case when we'll need >>>> prebarriers that will not require the previous value and these could be >>>> a reality in the future. So, it is generally incorrect to elide >>>> prebarriers but is only ok for a specific flavor. I'm working to >>>> alleviate this problem a little bit and will post the updated version >>>> early next week. John, I will also address your recommendations. >>>> >>>> Thanks, >>>> igor >>>> >>>> >>>> On 2/24/11 6:28 PM, John Rose wrote: >>>>> On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: >>>>> >>>>>> On 2/24/11 5:27 PM, John Rose wrote: >>>>>>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>>>>>> >>>>>>> If it is simply foo(..., !must_clear_dest), it becomes hard for >>>>>>> maintainers to see what the argument means. >>>>>> >>>>>> I can see your point but I just didn't want to introduce additional >>>>>> clutter. For example generate_block_arraycopy() never requires >>>>>> barrier suppression, so why do we need to add an argument there? >>>>> >>>>> There's not a strong need. An extra "true" or "false" would be a >>>>> little clutter, but it would also hint to programmers what's going on. >>>>> It's a esthetic call mostly... >>>>> >>>>> (Here's some meandering on the subject. While reading the code, if I >>>>> am tracing the flow from caller definition to callee definition, when >>>>> arguments are explicit I can observe them directly. But if they are >>>>> defaulted, then I have to visit the callee's declaration as well. I >>>>> have to visit three locations in the source instead of two. I >>>>> personally find this awkward unless the meaning of the defaulted >>>>> argument is immediately and intuitively obvious. In this case the >>>>> meaning of the argument is subtly related to other parts of the >>>>> system.) >>>>> >>>>>> From the debugging standpoint it's way better to emit a barrier than >>>>>> not to. Missing barriers will be a nightmare to find. So, I'd rather >>>>>> have a barrier erroneously emitted in some path by default, which >>>>>> would make the marking crash almost immediately. >>>>> >>>>> Good point. >>>>> >>>>>> As for using !must_clear_dest as a gate, I thought it would more >>>>>> clearly convey to the reader the reason why the barrier is suppressed >>>>>> - because the dest array is not cleared and contains garbage, so the >>>>>> reader won't have to go back to see in which cases use_pre_barrier is >>>>>> set. Perhaps I should add more comments. >>>>> >>>>> The bug number would help a lot, I think. It's a subtle interaction >>>>> between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 >>>>> invariants. >>>>> >>>>>>> In the stub generator the optional boolean is OK as is, although I >>>>>>> generally prefer optional booleans to default to 'false'. Given the >>>>>>> way the bug is structured, I keep wanting to call it >>>>>>> 'suppress_pre_barrier', meaning "just this once, trust me when I >>>>>>> tell you not to emit the pre-barrier, if there is one." >>>>>>> >>>>>> >>>>>> That's pretty much equivalent. I don't have strong feelings about >>>>>> this and will change it if you think it's more readable. >>>>> >>>>> I do think it would be more readable. It could be just an old Lisper >>>>> bias, though: Optional arguments default to NULL, which is the false >>>>> value in Lisp. >>>>> >>>>> -- John >>>> >>> > From vladimir.kozlov at oracle.com Tue Mar 1 13:48:22 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Mar 2011 13:48:22 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D6D5CE5.6070200@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> <4D6D55B6.8000904@oracle.com> <4D6D5CE5.6070200@oracle.com> Message-ID: <4D6D69A6.8080906@oracle.com> OK. Vladimir Igor Veresov wrote: > On 3/1/11 12:23 PM, Vladimir Kozlov wrote: >> I have only comments about library_call.cpp: >> >> Why "false" in copy_to_clone()? It seems, you get double barriers in >> this method as well: >> 4085 /*dest_uninitialized*/false); > > It doesn't matter here, because we're treating it all as T_LONGs, so > there's going to be no barriers. But for consistency I suppose it could > be "true" here. > >> >> >> 4596 // so the the pre-barriers wouldn't peek into the old values. See >> CR 6627983. >> ^ 'the' 2 times ^ unitialized > Fixed. Thanks! > >> 4597 const bool& dest_uninitialized = must_clear_dest; >> ^ why reference? >> > > John wanted a separate variable to inform arraycopy of whether the > target is initialized. This variable should in fact follow the state of > the must_clear_dest, so I decided to make it a reference, so that when > must_clear_dest changes so does dest_uninitialized. If you don't like > that I can make it a regular variable. > > Although I would rather just used must_clear_dest for everything and not > replicate the state. > > > Thanks, > igor > > >> The rest changes seems fine. >> >> Thanks, >> Vladimir >> >> Igor Veresov wrote: >>> John, all, >>> >>> I've updated the change, making corrections that John recommended. >>> Also, now the decision about what to do with the barrier is deferred >>> to the barrier emitting procedure. Thus, if a new pre-barrier is added >>> that would need to do something even in case if the destination array >>> is uninitialized it can be handled properly. >>> >>> New webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.01 >>> >>> Thanks, >>> igor >>> >>> >>> >>> On 2/25/11 8:25 PM, Igor Veresov wrote: >>>> I think my fix is not good enough for the case when we'll need >>>> prebarriers that will not require the previous value and these could be >>>> a reality in the future. So, it is generally incorrect to elide >>>> prebarriers but is only ok for a specific flavor. I'm working to >>>> alleviate this problem a little bit and will post the updated version >>>> early next week. John, I will also address your recommendations. >>>> >>>> Thanks, >>>> igor >>>> >>>> >>>> On 2/24/11 6:28 PM, John Rose wrote: >>>>> On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: >>>>> >>>>>> On 2/24/11 5:27 PM, John Rose wrote: >>>>>>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>>>>>> >>>>>>> If it is simply foo(..., !must_clear_dest), it becomes hard for >>>>>>> maintainers to see what the argument means. >>>>>> >>>>>> I can see your point but I just didn't want to introduce additional >>>>>> clutter. For example generate_block_arraycopy() never requires >>>>>> barrier suppression, so why do we need to add an argument there? >>>>> >>>>> There's not a strong need. An extra "true" or "false" would be a >>>>> little clutter, but it would also hint to programmers what's going on. >>>>> It's a esthetic call mostly... >>>>> >>>>> (Here's some meandering on the subject. While reading the code, if I >>>>> am tracing the flow from caller definition to callee definition, when >>>>> arguments are explicit I can observe them directly. But if they are >>>>> defaulted, then I have to visit the callee's declaration as well. I >>>>> have to visit three locations in the source instead of two. I >>>>> personally find this awkward unless the meaning of the defaulted >>>>> argument is immediately and intuitively obvious. In this case the >>>>> meaning of the argument is subtly related to other parts of the >>>>> system.) >>>>> >>>>>> From the debugging standpoint it's way better to emit a barrier than >>>>>> not to. Missing barriers will be a nightmare to find. So, I'd rather >>>>>> have a barrier erroneously emitted in some path by default, which >>>>>> would make the marking crash almost immediately. >>>>> >>>>> Good point. >>>>> >>>>>> As for using !must_clear_dest as a gate, I thought it would more >>>>>> clearly convey to the reader the reason why the barrier is suppressed >>>>>> - because the dest array is not cleared and contains garbage, so the >>>>>> reader won't have to go back to see in which cases use_pre_barrier is >>>>>> set. Perhaps I should add more comments. >>>>> >>>>> The bug number would help a lot, I think. It's a subtle interaction >>>>> between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 >>>>> invariants. >>>>> >>>>>>> In the stub generator the optional boolean is OK as is, although I >>>>>>> generally prefer optional booleans to default to 'false'. Given the >>>>>>> way the bug is structured, I keep wanting to call it >>>>>>> 'suppress_pre_barrier', meaning "just this once, trust me when I >>>>>>> tell you not to emit the pre-barrier, if there is one." >>>>>>> >>>>>> >>>>>> That's pretty much equivalent. I don't have strong feelings about >>>>>> this and will change it if you think it's more readable. >>>>> >>>>> I do think it would be more readable. It could be just an old Lisper >>>>> bias, though: Optional arguments default to NULL, which is the false >>>>> value in Lisp. >>>>> >>>>> -- John >>>> >>> > From igor.veresov at oracle.com Tue Mar 1 13:53:51 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 01 Mar 2011 13:53:51 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <5DD47A92-E731-4FDD-821C-35BA5A1C8332@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> <4D6D55B6.8000904@oracle.com> <4D6D5CE5.6070200@oracle.com> <5DD47A92-E731-4FDD-821C-35BA5A1C8332@oracle.com> Message-ID: <4D6D6AEF.8000400@oracle.com> On 3/1/11 1:08 PM, Tom Rodriguez wrote: > > On Mar 1, 2011, at 12:53 PM, Igor Veresov wrote: > >> On 3/1/11 12:23 PM, Vladimir Kozlov wrote: >>> I have only comments about library_call.cpp: >>> >>> Why "false" in copy_to_clone()? It seems, you get double barriers in >>> this method as well: >>> 4085 /*dest_uninitialized*/false); >> >> It doesn't matter here, because we're treating it all as T_LONGs, so there's going to be no barriers. But for consistency I suppose it could be "true" here. >> >>> >>> >>> 4596 // so the the pre-barriers wouldn't peek into the old values. See >>> CR 6627983. >>> ^ 'the' 2 times ^ unitialized >> Fixed. Thanks! >> >>> 4597 const bool& dest_uninitialized = must_clear_dest; >>> ^ why reference? >>> >> >> John wanted a separate variable to inform arraycopy of whether the target is initialized. This variable should in fact follow the state of the must_clear_dest, so I decided to make it a reference, so that when must_clear_dest changes so does dest_uninitialized. If you don't like that I can make it a regular variable. >> >> Although I would rather just used must_clear_dest for everything and not replicate the state. > > no local variable references please. Just pass must_clear_dest or rename it to dest_uninitalized. Ok. igor > > tom > >> >> >> Thanks, >> igor >> >> >>> The rest changes seems fine. >>> >>> Thanks, >>> Vladimir >>> >>> Igor Veresov wrote: >>>> John, all, >>>> >>>> I've updated the change, making corrections that John recommended. >>>> Also, now the decision about what to do with the barrier is deferred >>>> to the barrier emitting procedure. Thus, if a new pre-barrier is added >>>> that would need to do something even in case if the destination array >>>> is uninitialized it can be handled properly. >>>> >>>> New webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.01 >>>> >>>> Thanks, >>>> igor >>>> >>>> >>>> >>>> On 2/25/11 8:25 PM, Igor Veresov wrote: >>>>> I think my fix is not good enough for the case when we'll need >>>>> prebarriers that will not require the previous value and these could be >>>>> a reality in the future. So, it is generally incorrect to elide >>>>> prebarriers but is only ok for a specific flavor. I'm working to >>>>> alleviate this problem a little bit and will post the updated version >>>>> early next week. John, I will also address your recommendations. >>>>> >>>>> Thanks, >>>>> igor >>>>> >>>>> >>>>> On 2/24/11 6:28 PM, John Rose wrote: >>>>>> On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: >>>>>> >>>>>>> On 2/24/11 5:27 PM, John Rose wrote: >>>>>>>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>>>>>>> >>>>>>>> If it is simply foo(..., !must_clear_dest), it becomes hard for >>>>>>>> maintainers to see what the argument means. >>>>>>> >>>>>>> I can see your point but I just didn't want to introduce additional >>>>>>> clutter. For example generate_block_arraycopy() never requires >>>>>>> barrier suppression, so why do we need to add an argument there? >>>>>> >>>>>> There's not a strong need. An extra "true" or "false" would be a >>>>>> little clutter, but it would also hint to programmers what's going on. >>>>>> It's a esthetic call mostly... >>>>>> >>>>>> (Here's some meandering on the subject. While reading the code, if I >>>>>> am tracing the flow from caller definition to callee definition, when >>>>>> arguments are explicit I can observe them directly. But if they are >>>>>> defaulted, then I have to visit the callee's declaration as well. I >>>>>> have to visit three locations in the source instead of two. I >>>>>> personally find this awkward unless the meaning of the defaulted >>>>>> argument is immediately and intuitively obvious. In this case the >>>>>> meaning of the argument is subtly related to other parts of the >>>>>> system.) >>>>>> >>>>>>> From the debugging standpoint it's way better to emit a barrier than >>>>>>> not to. Missing barriers will be a nightmare to find. So, I'd rather >>>>>>> have a barrier erroneously emitted in some path by default, which >>>>>>> would make the marking crash almost immediately. >>>>>> >>>>>> Good point. >>>>>> >>>>>>> As for using !must_clear_dest as a gate, I thought it would more >>>>>>> clearly convey to the reader the reason why the barrier is suppressed >>>>>>> - because the dest array is not cleared and contains garbage, so the >>>>>>> reader won't have to go back to see in which cases use_pre_barrier is >>>>>>> set. Perhaps I should add more comments. >>>>>> >>>>>> The bug number would help a lot, I think. It's a subtle interaction >>>>>> between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 >>>>>> invariants. >>>>>> >>>>>>>> In the stub generator the optional boolean is OK as is, although I >>>>>>>> generally prefer optional booleans to default to 'false'. Given the >>>>>>>> way the bug is structured, I keep wanting to call it >>>>>>>> 'suppress_pre_barrier', meaning "just this once, trust me when I >>>>>>>> tell you not to emit the pre-barrier, if there is one." >>>>>>>> >>>>>>> >>>>>>> That's pretty much equivalent. I don't have strong feelings about >>>>>>> this and will change it if you think it's more readable. >>>>>> >>>>>> I do think it would be more readable. It could be just an old Lisper >>>>>> bias, though: Optional arguments default to NULL, which is the false >>>>>> value in Lisp. >>>>>> >>>>>> -- John >>>>> >>>> >> > From igor.veresov at oracle.com Tue Mar 1 14:04:11 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 01 Mar 2011 14:04:11 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D6D6AEF.8000400@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> <4D6D55B6.8000904@oracle.com> <4D6D5CE5.6070200@oracle.com> <5DD47A92-E731-4FDD-821C-35BA5A1C8332@oracle.com> <4D6D6AEF.8000400@oracle.com> Message-ID: <4D6D6D5B.8070403@oracle.com> John, I'd like to rename must_clear_dest to dest_uninitialized and pass to arraycopy instead of introducing additional variables. What do you think? Here is the webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.02 Thanks, igor On 3/1/11 1:53 PM, Igor Veresov wrote: > On 3/1/11 1:08 PM, Tom Rodriguez wrote: >> >> On Mar 1, 2011, at 12:53 PM, Igor Veresov wrote: >> >>> On 3/1/11 12:23 PM, Vladimir Kozlov wrote: >>>> I have only comments about library_call.cpp: >>>> >>>> Why "false" in copy_to_clone()? It seems, you get double barriers in >>>> this method as well: >>>> 4085 /*dest_uninitialized*/false); >>> >>> It doesn't matter here, because we're treating it all as T_LONGs, so >>> there's going to be no barriers. But for consistency I suppose it >>> could be "true" here. >>> >>>> >>>> >>>> 4596 // so the the pre-barriers wouldn't peek into the old values. See >>>> CR 6627983. >>>> ^ 'the' 2 times ^ unitialized >>> Fixed. Thanks! >>> >>>> 4597 const bool& dest_uninitialized = must_clear_dest; >>>> ^ why reference? >>>> >>> >>> John wanted a separate variable to inform arraycopy of whether the >>> target is initialized. This variable should in fact follow the state >>> of the must_clear_dest, so I decided to make it a reference, so that >>> when must_clear_dest changes so does dest_uninitialized. If you don't >>> like that I can make it a regular variable. >>> >>> Although I would rather just used must_clear_dest for everything and >>> not replicate the state. >> >> no local variable references please. Just pass must_clear_dest or >> rename it to dest_uninitalized. > > Ok. > > igor > >> >> tom >> >>> >>> >>> Thanks, >>> igor >>> >>> >>>> The rest changes seems fine. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Igor Veresov wrote: >>>>> John, all, >>>>> >>>>> I've updated the change, making corrections that John recommended. >>>>> Also, now the decision about what to do with the barrier is deferred >>>>> to the barrier emitting procedure. Thus, if a new pre-barrier is added >>>>> that would need to do something even in case if the destination array >>>>> is uninitialized it can be handled properly. >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.01 >>>>> >>>>> Thanks, >>>>> igor >>>>> >>>>> >>>>> >>>>> On 2/25/11 8:25 PM, Igor Veresov wrote: >>>>>> I think my fix is not good enough for the case when we'll need >>>>>> prebarriers that will not require the previous value and these >>>>>> could be >>>>>> a reality in the future. So, it is generally incorrect to elide >>>>>> prebarriers but is only ok for a specific flavor. I'm working to >>>>>> alleviate this problem a little bit and will post the updated version >>>>>> early next week. John, I will also address your recommendations. >>>>>> >>>>>> Thanks, >>>>>> igor >>>>>> >>>>>> >>>>>> On 2/24/11 6:28 PM, John Rose wrote: >>>>>>> On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: >>>>>>> >>>>>>>> On 2/24/11 5:27 PM, John Rose wrote: >>>>>>>>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>>>>>>>> >>>>>>>>> If it is simply foo(..., !must_clear_dest), it becomes hard for >>>>>>>>> maintainers to see what the argument means. >>>>>>>> >>>>>>>> I can see your point but I just didn't want to introduce additional >>>>>>>> clutter. For example generate_block_arraycopy() never requires >>>>>>>> barrier suppression, so why do we need to add an argument there? >>>>>>> >>>>>>> There's not a strong need. An extra "true" or "false" would be a >>>>>>> little clutter, but it would also hint to programmers what's >>>>>>> going on. >>>>>>> It's a esthetic call mostly... >>>>>>> >>>>>>> (Here's some meandering on the subject. While reading the code, if I >>>>>>> am tracing the flow from caller definition to callee definition, >>>>>>> when >>>>>>> arguments are explicit I can observe them directly. But if they are >>>>>>> defaulted, then I have to visit the callee's declaration as well. I >>>>>>> have to visit three locations in the source instead of two. I >>>>>>> personally find this awkward unless the meaning of the defaulted >>>>>>> argument is immediately and intuitively obvious. In this case the >>>>>>> meaning of the argument is subtly related to other parts of the >>>>>>> system.) >>>>>>> >>>>>>>> From the debugging standpoint it's way better to emit a barrier >>>>>>>> than >>>>>>>> not to. Missing barriers will be a nightmare to find. So, I'd >>>>>>>> rather >>>>>>>> have a barrier erroneously emitted in some path by default, which >>>>>>>> would make the marking crash almost immediately. >>>>>>> >>>>>>> Good point. >>>>>>> >>>>>>>> As for using !must_clear_dest as a gate, I thought it would more >>>>>>>> clearly convey to the reader the reason why the barrier is >>>>>>>> suppressed >>>>>>>> - because the dest array is not cleared and contains garbage, so >>>>>>>> the >>>>>>>> reader won't have to go back to see in which cases >>>>>>>> use_pre_barrier is >>>>>>>> set. Perhaps I should add more comments. >>>>>>> >>>>>>> The bug number would help a lot, I think. It's a subtle interaction >>>>>>> between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 >>>>>>> invariants. >>>>>>> >>>>>>>>> In the stub generator the optional boolean is OK as is, although I >>>>>>>>> generally prefer optional booleans to default to 'false'. Given >>>>>>>>> the >>>>>>>>> way the bug is structured, I keep wanting to call it >>>>>>>>> 'suppress_pre_barrier', meaning "just this once, trust me when I >>>>>>>>> tell you not to emit the pre-barrier, if there is one." >>>>>>>>> >>>>>>>> >>>>>>>> That's pretty much equivalent. I don't have strong feelings about >>>>>>>> this and will change it if you think it's more readable. >>>>>>> >>>>>>> I do think it would be more readable. It could be just an old Lisper >>>>>>> bias, though: Optional arguments default to NULL, which is the false >>>>>>> value in Lisp. >>>>>>> >>>>>>> -- John >>>>>> >>>>> >>> >> > From tom.rodriguez at oracle.com Tue Mar 1 14:07:07 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 01 Mar 2011 22:07:07 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6725983: Assertion "method->method_holder())->is_not_initialized(), "method holder must be initialized" Message-ID: <20110301220709.0301A47B9C@hg.openjdk.java.net> Changeset: bc6b27fb3568 Author: never Date: 2011-03-01 10:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bc6b27fb3568 6725983: Assertion "method->method_holder())->is_not_initialized(),"method holder must be initialized" Reviewed-by: kvn, iveresov ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/runtime/globals.hpp From john.r.rose at oracle.com Tue Mar 1 14:05:50 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Mar 2011 14:05:50 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D6D6D5B.8070403@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> <4D6D55B6.8000904@oracle.com> <4D6D5CE5.6070200@oracle.com> <5DD47A92-E731-4FDD-821C-35BA5A1C8332@oracle.com> <4D6D6AEF.8000400@oracle.com> <4D6D6D5B.8070403@oracle.com> Message-ID: <94E31F64-C275-4583-B92F-85914A024860@oracle.com> Perfect. That reads very well. -- John On Mar 1, 2011, at 2:04 PM, Igor Veresov wrote: > John, > > I'd like to rename must_clear_dest to dest_uninitialized and pass to arraycopy instead of introducing additional variables. What do you think? > > Here is the webrev: > http://cr.openjdk.java.net/~iveresov/6627983/webrev.02 From igor.veresov at oracle.com Tue Mar 1 14:08:03 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 01 Mar 2011 14:08:03 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <94E31F64-C275-4583-B92F-85914A024860@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> <4D6D55B6.8000904@oracle.com> <4D6D5CE5.6070200@oracle.com> <5DD47A92-E731-4FDD-821C-35BA5A1C8332@oracle.com> <4D6D6AEF.8000400@oracle.com> <4D6D6D5B.8070403@oracle.com> <94E31F64-C275-4583-B92F-85914A024860@oracle.com> Message-ID: <4D6D6E43.6060401@oracle.com> Thanks John, Vladimir and Tom! igor On 3/1/11 2:05 PM, John Rose wrote: > Perfect. That reads very well. -- John > > On Mar 1, 2011, at 2:04 PM, Igor Veresov wrote: > >> John, >> >> I'd like to rename must_clear_dest to dest_uninitialized and pass to arraycopy instead of introducing additional variables. What do you think? >> >> Here is the webrev: >> http://cr.openjdk.java.net/~iveresov/6627983/webrev.02 > From vladimir.kozlov at oracle.com Tue Mar 1 14:33:41 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Mar 2011 14:33:41 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D6D6D5B.8070403@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> <4D6D55B6.8000904@oracle.com> <4D6D5CE5.6070200@oracle.com> <5DD47A92-E731-4FDD-821C-35BA5A1C8332@oracle.com> <4D6D6AEF.8000400@oracle.com> <4D6D6D5B.8070403@oracle.com> Message-ID: <4D6D7445.9060307@oracle.com> + // Also, if this flag is set we make sure that arraycopy intracts properly ^^^ Vladimir Igor Veresov wrote: > John, > > I'd like to rename must_clear_dest to dest_uninitialized and pass to > arraycopy instead of introducing additional variables. What do you think? > > Here is the webrev: > http://cr.openjdk.java.net/~iveresov/6627983/webrev.02 > > Thanks, > igor > > On 3/1/11 1:53 PM, Igor Veresov wrote: >> On 3/1/11 1:08 PM, Tom Rodriguez wrote: >>> >>> On Mar 1, 2011, at 12:53 PM, Igor Veresov wrote: >>> >>>> On 3/1/11 12:23 PM, Vladimir Kozlov wrote: >>>>> I have only comments about library_call.cpp: >>>>> >>>>> Why "false" in copy_to_clone()? It seems, you get double barriers in >>>>> this method as well: >>>>> 4085 /*dest_uninitialized*/false); >>>> >>>> It doesn't matter here, because we're treating it all as T_LONGs, so >>>> there's going to be no barriers. But for consistency I suppose it >>>> could be "true" here. >>>> >>>>> >>>>> >>>>> 4596 // so the the pre-barriers wouldn't peek into the old values. See >>>>> CR 6627983. >>>>> ^ 'the' 2 times ^ unitialized >>>> Fixed. Thanks! >>>> >>>>> 4597 const bool& dest_uninitialized = must_clear_dest; >>>>> ^ why reference? >>>>> >>>> >>>> John wanted a separate variable to inform arraycopy of whether the >>>> target is initialized. This variable should in fact follow the state >>>> of the must_clear_dest, so I decided to make it a reference, so that >>>> when must_clear_dest changes so does dest_uninitialized. If you don't >>>> like that I can make it a regular variable. >>>> >>>> Although I would rather just used must_clear_dest for everything and >>>> not replicate the state. >>> >>> no local variable references please. Just pass must_clear_dest or >>> rename it to dest_uninitalized. >> >> Ok. >> >> igor >> >>> >>> tom >>> >>>> >>>> >>>> Thanks, >>>> igor >>>> >>>> >>>>> The rest changes seems fine. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Igor Veresov wrote: >>>>>> John, all, >>>>>> >>>>>> I've updated the change, making corrections that John recommended. >>>>>> Also, now the decision about what to do with the barrier is deferred >>>>>> to the barrier emitting procedure. Thus, if a new pre-barrier is >>>>>> added >>>>>> that would need to do something even in case if the destination array >>>>>> is uninitialized it can be handled properly. >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.01 >>>>>> >>>>>> Thanks, >>>>>> igor >>>>>> >>>>>> >>>>>> >>>>>> On 2/25/11 8:25 PM, Igor Veresov wrote: >>>>>>> I think my fix is not good enough for the case when we'll need >>>>>>> prebarriers that will not require the previous value and these >>>>>>> could be >>>>>>> a reality in the future. So, it is generally incorrect to elide >>>>>>> prebarriers but is only ok for a specific flavor. I'm working to >>>>>>> alleviate this problem a little bit and will post the updated >>>>>>> version >>>>>>> early next week. John, I will also address your recommendations. >>>>>>> >>>>>>> Thanks, >>>>>>> igor >>>>>>> >>>>>>> >>>>>>> On 2/24/11 6:28 PM, John Rose wrote: >>>>>>>> On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: >>>>>>>> >>>>>>>>> On 2/24/11 5:27 PM, John Rose wrote: >>>>>>>>>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>>>>>>>>> >>>>>>>>>> If it is simply foo(..., !must_clear_dest), it becomes hard for >>>>>>>>>> maintainers to see what the argument means. >>>>>>>>> >>>>>>>>> I can see your point but I just didn't want to introduce >>>>>>>>> additional >>>>>>>>> clutter. For example generate_block_arraycopy() never requires >>>>>>>>> barrier suppression, so why do we need to add an argument there? >>>>>>>> >>>>>>>> There's not a strong need. An extra "true" or "false" would be a >>>>>>>> little clutter, but it would also hint to programmers what's >>>>>>>> going on. >>>>>>>> It's a esthetic call mostly... >>>>>>>> >>>>>>>> (Here's some meandering on the subject. While reading the code, >>>>>>>> if I >>>>>>>> am tracing the flow from caller definition to callee definition, >>>>>>>> when >>>>>>>> arguments are explicit I can observe them directly. But if they are >>>>>>>> defaulted, then I have to visit the callee's declaration as well. I >>>>>>>> have to visit three locations in the source instead of two. I >>>>>>>> personally find this awkward unless the meaning of the defaulted >>>>>>>> argument is immediately and intuitively obvious. In this case the >>>>>>>> meaning of the argument is subtly related to other parts of the >>>>>>>> system.) >>>>>>>> >>>>>>>>> From the debugging standpoint it's way better to emit a barrier >>>>>>>>> than >>>>>>>>> not to. Missing barriers will be a nightmare to find. So, I'd >>>>>>>>> rather >>>>>>>>> have a barrier erroneously emitted in some path by default, which >>>>>>>>> would make the marking crash almost immediately. >>>>>>>> >>>>>>>> Good point. >>>>>>>> >>>>>>>>> As for using !must_clear_dest as a gate, I thought it would more >>>>>>>>> clearly convey to the reader the reason why the barrier is >>>>>>>>> suppressed >>>>>>>>> - because the dest array is not cleared and contains garbage, so >>>>>>>>> the >>>>>>>>> reader won't have to go back to see in which cases >>>>>>>>> use_pre_barrier is >>>>>>>>> set. Perhaps I should add more comments. >>>>>>>> >>>>>>>> The bug number would help a lot, I think. It's a subtle interaction >>>>>>>> between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 >>>>>>>> invariants. >>>>>>>> >>>>>>>>>> In the stub generator the optional boolean is OK as is, >>>>>>>>>> although I >>>>>>>>>> generally prefer optional booleans to default to 'false'. Given >>>>>>>>>> the >>>>>>>>>> way the bug is structured, I keep wanting to call it >>>>>>>>>> 'suppress_pre_barrier', meaning "just this once, trust me when I >>>>>>>>>> tell you not to emit the pre-barrier, if there is one." >>>>>>>>>> >>>>>>>>> >>>>>>>>> That's pretty much equivalent. I don't have strong feelings about >>>>>>>>> this and will change it if you think it's more readable. >>>>>>>> >>>>>>>> I do think it would be more readable. It could be just an old >>>>>>>> Lisper >>>>>>>> bias, though: Optional arguments default to NULL, which is the >>>>>>>> false >>>>>>>> value in Lisp. >>>>>>>> >>>>>>>> -- John >>>>>>> >>>>>> >>>> >>> >> > From igor.veresov at oracle.com Tue Mar 1 14:42:52 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 01 Mar 2011 14:42:52 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D6D7445.9060307@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> <4D6D55B6.8000904@oracle.com> <4D6D5CE5.6070200@oracle.com> <5DD47A92-E731-4FDD-821C-35BA5A1C8332@oracle.com> <4D6D6AEF.8000400@oracle.com> <4D6D6D5B.8070403@oracle.com> <4D6D7445.9060307@oracle.com> Message-ID: <4D6D766C.1060300@oracle.com> On 3/1/11 2:33 PM, Vladimir Kozlov wrote: > + // Also, if this flag is set we make sure that arraycopy intracts > properly > ^^^ Thanks. igor > Vladimir > > Igor Veresov wrote: >> John, >> >> I'd like to rename must_clear_dest to dest_uninitialized and pass to >> arraycopy instead of introducing additional variables. What do you think? >> >> Here is the webrev: >> http://cr.openjdk.java.net/~iveresov/6627983/webrev.02 >> >> Thanks, >> igor >> >> On 3/1/11 1:53 PM, Igor Veresov wrote: >>> On 3/1/11 1:08 PM, Tom Rodriguez wrote: >>>> >>>> On Mar 1, 2011, at 12:53 PM, Igor Veresov wrote: >>>> >>>>> On 3/1/11 12:23 PM, Vladimir Kozlov wrote: >>>>>> I have only comments about library_call.cpp: >>>>>> >>>>>> Why "false" in copy_to_clone()? It seems, you get double barriers in >>>>>> this method as well: >>>>>> 4085 /*dest_uninitialized*/false); >>>>> >>>>> It doesn't matter here, because we're treating it all as T_LONGs, so >>>>> there's going to be no barriers. But for consistency I suppose it >>>>> could be "true" here. >>>>> >>>>>> >>>>>> >>>>>> 4596 // so the the pre-barriers wouldn't peek into the old values. >>>>>> See >>>>>> CR 6627983. >>>>>> ^ 'the' 2 times ^ unitialized >>>>> Fixed. Thanks! >>>>> >>>>>> 4597 const bool& dest_uninitialized = must_clear_dest; >>>>>> ^ why reference? >>>>>> >>>>> >>>>> John wanted a separate variable to inform arraycopy of whether the >>>>> target is initialized. This variable should in fact follow the state >>>>> of the must_clear_dest, so I decided to make it a reference, so that >>>>> when must_clear_dest changes so does dest_uninitialized. If you don't >>>>> like that I can make it a regular variable. >>>>> >>>>> Although I would rather just used must_clear_dest for everything and >>>>> not replicate the state. >>>> >>>> no local variable references please. Just pass must_clear_dest or >>>> rename it to dest_uninitalized. >>> >>> Ok. >>> >>> igor >>> >>>> >>>> tom >>>> >>>>> >>>>> >>>>> Thanks, >>>>> igor >>>>> >>>>> >>>>>> The rest changes seems fine. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Igor Veresov wrote: >>>>>>> John, all, >>>>>>> >>>>>>> I've updated the change, making corrections that John recommended. >>>>>>> Also, now the decision about what to do with the barrier is deferred >>>>>>> to the barrier emitting procedure. Thus, if a new pre-barrier is >>>>>>> added >>>>>>> that would need to do something even in case if the destination >>>>>>> array >>>>>>> is uninitialized it can be handled properly. >>>>>>> >>>>>>> New webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.01 >>>>>>> >>>>>>> Thanks, >>>>>>> igor >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2/25/11 8:25 PM, Igor Veresov wrote: >>>>>>>> I think my fix is not good enough for the case when we'll need >>>>>>>> prebarriers that will not require the previous value and these >>>>>>>> could be >>>>>>>> a reality in the future. So, it is generally incorrect to elide >>>>>>>> prebarriers but is only ok for a specific flavor. I'm working to >>>>>>>> alleviate this problem a little bit and will post the updated >>>>>>>> version >>>>>>>> early next week. John, I will also address your recommendations. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> igor >>>>>>>> >>>>>>>> >>>>>>>> On 2/24/11 6:28 PM, John Rose wrote: >>>>>>>>> On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: >>>>>>>>> >>>>>>>>>> On 2/24/11 5:27 PM, John Rose wrote: >>>>>>>>>>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>>>>>>>>>> >>>>>>>>>>> If it is simply foo(..., !must_clear_dest), it becomes hard for >>>>>>>>>>> maintainers to see what the argument means. >>>>>>>>>> >>>>>>>>>> I can see your point but I just didn't want to introduce >>>>>>>>>> additional >>>>>>>>>> clutter. For example generate_block_arraycopy() never requires >>>>>>>>>> barrier suppression, so why do we need to add an argument there? >>>>>>>>> >>>>>>>>> There's not a strong need. An extra "true" or "false" would be a >>>>>>>>> little clutter, but it would also hint to programmers what's >>>>>>>>> going on. >>>>>>>>> It's a esthetic call mostly... >>>>>>>>> >>>>>>>>> (Here's some meandering on the subject. While reading the code, >>>>>>>>> if I >>>>>>>>> am tracing the flow from caller definition to callee definition, >>>>>>>>> when >>>>>>>>> arguments are explicit I can observe them directly. But if they >>>>>>>>> are >>>>>>>>> defaulted, then I have to visit the callee's declaration as >>>>>>>>> well. I >>>>>>>>> have to visit three locations in the source instead of two. I >>>>>>>>> personally find this awkward unless the meaning of the defaulted >>>>>>>>> argument is immediately and intuitively obvious. In this case the >>>>>>>>> meaning of the argument is subtly related to other parts of the >>>>>>>>> system.) >>>>>>>>> >>>>>>>>>> From the debugging standpoint it's way better to emit a barrier >>>>>>>>>> than >>>>>>>>>> not to. Missing barriers will be a nightmare to find. So, I'd >>>>>>>>>> rather >>>>>>>>>> have a barrier erroneously emitted in some path by default, which >>>>>>>>>> would make the marking crash almost immediately. >>>>>>>>> >>>>>>>>> Good point. >>>>>>>>> >>>>>>>>>> As for using !must_clear_dest as a gate, I thought it would more >>>>>>>>>> clearly convey to the reader the reason why the barrier is >>>>>>>>>> suppressed >>>>>>>>>> - because the dest array is not cleared and contains garbage, so >>>>>>>>>> the >>>>>>>>>> reader won't have to go back to see in which cases >>>>>>>>>> use_pre_barrier is >>>>>>>>>> set. Perhaps I should add more comments. >>>>>>>>> >>>>>>>>> The bug number would help a lot, I think. It's a subtle >>>>>>>>> interaction >>>>>>>>> between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 >>>>>>>>> invariants. >>>>>>>>> >>>>>>>>>>> In the stub generator the optional boolean is OK as is, >>>>>>>>>>> although I >>>>>>>>>>> generally prefer optional booleans to default to 'false'. Given >>>>>>>>>>> the >>>>>>>>>>> way the bug is structured, I keep wanting to call it >>>>>>>>>>> 'suppress_pre_barrier', meaning "just this once, trust me when I >>>>>>>>>>> tell you not to emit the pre-barrier, if there is one." >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That's pretty much equivalent. I don't have strong feelings about >>>>>>>>>> this and will change it if you think it's more readable. >>>>>>>>> >>>>>>>>> I do think it would be more readable. It could be just an old >>>>>>>>> Lisper >>>>>>>>> bias, though: Optional arguments default to NULL, which is the >>>>>>>>> false >>>>>>>>> value in Lisp. >>>>>>>>> >>>>>>>>> -- John >>>>>>>> >>>>>>> >>>>> >>>> >>> >> From vladimir.kozlov at oracle.com Tue Mar 1 14:59:12 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Mar 2011 14:59:12 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D6D766C.1060300@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> <4D6D55B6.8000904@oracle.com> <4D6D5CE5.6070200@oracle.com> <5DD47A92-E731-4FDD-821C-35BA5A1C8332@oracle.com> <4D6D6AEF.8000400@oracle.com> <4D6D6D5B.8070403@oracle.com> <4D6D7445.9060307@oracle.com> <4D6D766C.1060300@oracle.com> Message-ID: <4D6D7A40.3010508@oracle.com> Igor, Should you also check G1DisablePreBarrier flag which is currently used only here?: src/share/vm/c1/c1_LIRGenerator.cpp: if (G1DisablePreBarrier) return; Vladimir Igor Veresov wrote: > On 3/1/11 2:33 PM, Vladimir Kozlov wrote: >> + // Also, if this flag is set we make sure that arraycopy intracts >> properly >> ^^^ > > Thanks. > > igor > >> Vladimir >> >> Igor Veresov wrote: >>> John, >>> >>> I'd like to rename must_clear_dest to dest_uninitialized and pass to >>> arraycopy instead of introducing additional variables. What do you >>> think? >>> >>> Here is the webrev: >>> http://cr.openjdk.java.net/~iveresov/6627983/webrev.02 >>> >>> Thanks, >>> igor >>> >>> On 3/1/11 1:53 PM, Igor Veresov wrote: >>>> On 3/1/11 1:08 PM, Tom Rodriguez wrote: >>>>> >>>>> On Mar 1, 2011, at 12:53 PM, Igor Veresov wrote: >>>>> >>>>>> On 3/1/11 12:23 PM, Vladimir Kozlov wrote: >>>>>>> I have only comments about library_call.cpp: >>>>>>> >>>>>>> Why "false" in copy_to_clone()? It seems, you get double barriers in >>>>>>> this method as well: >>>>>>> 4085 /*dest_uninitialized*/false); >>>>>> >>>>>> It doesn't matter here, because we're treating it all as T_LONGs, so >>>>>> there's going to be no barriers. But for consistency I suppose it >>>>>> could be "true" here. >>>>>> >>>>>>> >>>>>>> >>>>>>> 4596 // so the the pre-barriers wouldn't peek into the old values. >>>>>>> See >>>>>>> CR 6627983. >>>>>>> ^ 'the' 2 times ^ unitialized >>>>>> Fixed. Thanks! >>>>>> >>>>>>> 4597 const bool& dest_uninitialized = must_clear_dest; >>>>>>> ^ why reference? >>>>>>> >>>>>> >>>>>> John wanted a separate variable to inform arraycopy of whether the >>>>>> target is initialized. This variable should in fact follow the state >>>>>> of the must_clear_dest, so I decided to make it a reference, so that >>>>>> when must_clear_dest changes so does dest_uninitialized. If you don't >>>>>> like that I can make it a regular variable. >>>>>> >>>>>> Although I would rather just used must_clear_dest for everything and >>>>>> not replicate the state. >>>>> >>>>> no local variable references please. Just pass must_clear_dest or >>>>> rename it to dest_uninitalized. >>>> >>>> Ok. >>>> >>>> igor >>>> >>>>> >>>>> tom >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> igor >>>>>> >>>>>> >>>>>>> The rest changes seems fine. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> Igor Veresov wrote: >>>>>>>> John, all, >>>>>>>> >>>>>>>> I've updated the change, making corrections that John recommended. >>>>>>>> Also, now the decision about what to do with the barrier is >>>>>>>> deferred >>>>>>>> to the barrier emitting procedure. Thus, if a new pre-barrier is >>>>>>>> added >>>>>>>> that would need to do something even in case if the destination >>>>>>>> array >>>>>>>> is uninitialized it can be handled properly. >>>>>>>> >>>>>>>> New webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.01 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> igor >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2/25/11 8:25 PM, Igor Veresov wrote: >>>>>>>>> I think my fix is not good enough for the case when we'll need >>>>>>>>> prebarriers that will not require the previous value and these >>>>>>>>> could be >>>>>>>>> a reality in the future. So, it is generally incorrect to elide >>>>>>>>> prebarriers but is only ok for a specific flavor. I'm working to >>>>>>>>> alleviate this problem a little bit and will post the updated >>>>>>>>> version >>>>>>>>> early next week. John, I will also address your recommendations. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> igor >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/24/11 6:28 PM, John Rose wrote: >>>>>>>>>> On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: >>>>>>>>>> >>>>>>>>>>> On 2/24/11 5:27 PM, John Rose wrote: >>>>>>>>>>>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>>>>>>>>>>> >>>>>>>>>>>> If it is simply foo(..., !must_clear_dest), it becomes hard for >>>>>>>>>>>> maintainers to see what the argument means. >>>>>>>>>>> >>>>>>>>>>> I can see your point but I just didn't want to introduce >>>>>>>>>>> additional >>>>>>>>>>> clutter. For example generate_block_arraycopy() never requires >>>>>>>>>>> barrier suppression, so why do we need to add an argument there? >>>>>>>>>> >>>>>>>>>> There's not a strong need. An extra "true" or "false" would be a >>>>>>>>>> little clutter, but it would also hint to programmers what's >>>>>>>>>> going on. >>>>>>>>>> It's a esthetic call mostly... >>>>>>>>>> >>>>>>>>>> (Here's some meandering on the subject. While reading the code, >>>>>>>>>> if I >>>>>>>>>> am tracing the flow from caller definition to callee definition, >>>>>>>>>> when >>>>>>>>>> arguments are explicit I can observe them directly. But if they >>>>>>>>>> are >>>>>>>>>> defaulted, then I have to visit the callee's declaration as >>>>>>>>>> well. I >>>>>>>>>> have to visit three locations in the source instead of two. I >>>>>>>>>> personally find this awkward unless the meaning of the defaulted >>>>>>>>>> argument is immediately and intuitively obvious. In this case the >>>>>>>>>> meaning of the argument is subtly related to other parts of the >>>>>>>>>> system.) >>>>>>>>>> >>>>>>>>>>> From the debugging standpoint it's way better to emit a barrier >>>>>>>>>>> than >>>>>>>>>>> not to. Missing barriers will be a nightmare to find. So, I'd >>>>>>>>>>> rather >>>>>>>>>>> have a barrier erroneously emitted in some path by default, >>>>>>>>>>> which >>>>>>>>>>> would make the marking crash almost immediately. >>>>>>>>>> >>>>>>>>>> Good point. >>>>>>>>>> >>>>>>>>>>> As for using !must_clear_dest as a gate, I thought it would more >>>>>>>>>>> clearly convey to the reader the reason why the barrier is >>>>>>>>>>> suppressed >>>>>>>>>>> - because the dest array is not cleared and contains garbage, so >>>>>>>>>>> the >>>>>>>>>>> reader won't have to go back to see in which cases >>>>>>>>>>> use_pre_barrier is >>>>>>>>>>> set. Perhaps I should add more comments. >>>>>>>>>> >>>>>>>>>> The bug number would help a lot, I think. It's a subtle >>>>>>>>>> interaction >>>>>>>>>> between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 >>>>>>>>>> invariants. >>>>>>>>>> >>>>>>>>>>>> In the stub generator the optional boolean is OK as is, >>>>>>>>>>>> although I >>>>>>>>>>>> generally prefer optional booleans to default to 'false'. Given >>>>>>>>>>>> the >>>>>>>>>>>> way the bug is structured, I keep wanting to call it >>>>>>>>>>>> 'suppress_pre_barrier', meaning "just this once, trust me >>>>>>>>>>>> when I >>>>>>>>>>>> tell you not to emit the pre-barrier, if there is one." >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> That's pretty much equivalent. I don't have strong feelings >>>>>>>>>>> about >>>>>>>>>>> this and will change it if you think it's more readable. >>>>>>>>>> >>>>>>>>>> I do think it would be more readable. It could be just an old >>>>>>>>>> Lisper >>>>>>>>>> bias, though: Optional arguments default to NULL, which is the >>>>>>>>>> false >>>>>>>>>> value in Lisp. >>>>>>>>>> >>>>>>>>>> -- John >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> > From igor.veresov at oracle.com Tue Mar 1 15:18:39 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 01 Mar 2011 15:18:39 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D6D7A40.3010508@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> <4D6D55B6.8000904@oracle.com> <4D6D5CE5.6070200@oracle.com> <5DD47A92-E731-4FDD-821C-35BA5A1C8332@oracle.com> <4D6D6AEF.8000400@oracle.com> <4D6D6D5B.8070403@oracle.com> <4D6D7445.9060307@oracle.com> <4D6D766C.1060300@oracle.com> <4D6D7A40.3010508@oracle.com> Message-ID: <4D6D7ECF.4070800@oracle.com> On 3/1/11 2:59 PM, Vladimir Kozlov wrote: > Igor, > > Should you also check G1DisablePreBarrier flag which is currently used > only here?: > > src/share/vm/c1/c1_LIRGenerator.cpp: if (G1DisablePreBarrier) return; > Hm, it seems like a relatively meaningless C1 debugging flag (there's also G1DisablePostBarrier). It can only be useful just to check C1's output? G1 won't work without the barriers. igor > Vladimir > > Igor Veresov wrote: >> On 3/1/11 2:33 PM, Vladimir Kozlov wrote: >>> + // Also, if this flag is set we make sure that arraycopy intracts >>> properly >>> ^^^ >> >> Thanks. >> >> igor >> >>> Vladimir >>> >>> Igor Veresov wrote: >>>> John, >>>> >>>> I'd like to rename must_clear_dest to dest_uninitialized and pass to >>>> arraycopy instead of introducing additional variables. What do you >>>> think? >>>> >>>> Here is the webrev: >>>> http://cr.openjdk.java.net/~iveresov/6627983/webrev.02 >>>> >>>> Thanks, >>>> igor >>>> >>>> On 3/1/11 1:53 PM, Igor Veresov wrote: >>>>> On 3/1/11 1:08 PM, Tom Rodriguez wrote: >>>>>> >>>>>> On Mar 1, 2011, at 12:53 PM, Igor Veresov wrote: >>>>>> >>>>>>> On 3/1/11 12:23 PM, Vladimir Kozlov wrote: >>>>>>>> I have only comments about library_call.cpp: >>>>>>>> >>>>>>>> Why "false" in copy_to_clone()? It seems, you get double >>>>>>>> barriers in >>>>>>>> this method as well: >>>>>>>> 4085 /*dest_uninitialized*/false); >>>>>>> >>>>>>> It doesn't matter here, because we're treating it all as T_LONGs, so >>>>>>> there's going to be no barriers. But for consistency I suppose it >>>>>>> could be "true" here. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4596 // so the the pre-barriers wouldn't peek into the old values. >>>>>>>> See >>>>>>>> CR 6627983. >>>>>>>> ^ 'the' 2 times ^ unitialized >>>>>>> Fixed. Thanks! >>>>>>> >>>>>>>> 4597 const bool& dest_uninitialized = must_clear_dest; >>>>>>>> ^ why reference? >>>>>>>> >>>>>>> >>>>>>> John wanted a separate variable to inform arraycopy of whether the >>>>>>> target is initialized. This variable should in fact follow the state >>>>>>> of the must_clear_dest, so I decided to make it a reference, so that >>>>>>> when must_clear_dest changes so does dest_uninitialized. If you >>>>>>> don't >>>>>>> like that I can make it a regular variable. >>>>>>> >>>>>>> Although I would rather just used must_clear_dest for everything and >>>>>>> not replicate the state. >>>>>> >>>>>> no local variable references please. Just pass must_clear_dest or >>>>>> rename it to dest_uninitalized. >>>>> >>>>> Ok. >>>>> >>>>> igor >>>>> >>>>>> >>>>>> tom >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> igor >>>>>>> >>>>>>> >>>>>>>> The rest changes seems fine. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Igor Veresov wrote: >>>>>>>>> John, all, >>>>>>>>> >>>>>>>>> I've updated the change, making corrections that John recommended. >>>>>>>>> Also, now the decision about what to do with the barrier is >>>>>>>>> deferred >>>>>>>>> to the barrier emitting procedure. Thus, if a new pre-barrier is >>>>>>>>> added >>>>>>>>> that would need to do something even in case if the destination >>>>>>>>> array >>>>>>>>> is uninitialized it can be handled properly. >>>>>>>>> >>>>>>>>> New webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.01 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> igor >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/25/11 8:25 PM, Igor Veresov wrote: >>>>>>>>>> I think my fix is not good enough for the case when we'll need >>>>>>>>>> prebarriers that will not require the previous value and these >>>>>>>>>> could be >>>>>>>>>> a reality in the future. So, it is generally incorrect to elide >>>>>>>>>> prebarriers but is only ok for a specific flavor. I'm working to >>>>>>>>>> alleviate this problem a little bit and will post the updated >>>>>>>>>> version >>>>>>>>>> early next week. John, I will also address your recommendations. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> igor >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/24/11 6:28 PM, John Rose wrote: >>>>>>>>>>> On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: >>>>>>>>>>> >>>>>>>>>>>> On 2/24/11 5:27 PM, John Rose wrote: >>>>>>>>>>>>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> If it is simply foo(..., !must_clear_dest), it becomes hard >>>>>>>>>>>>> for >>>>>>>>>>>>> maintainers to see what the argument means. >>>>>>>>>>>> >>>>>>>>>>>> I can see your point but I just didn't want to introduce >>>>>>>>>>>> additional >>>>>>>>>>>> clutter. For example generate_block_arraycopy() never requires >>>>>>>>>>>> barrier suppression, so why do we need to add an argument >>>>>>>>>>>> there? >>>>>>>>>>> >>>>>>>>>>> There's not a strong need. An extra "true" or "false" would be a >>>>>>>>>>> little clutter, but it would also hint to programmers what's >>>>>>>>>>> going on. >>>>>>>>>>> It's a esthetic call mostly... >>>>>>>>>>> >>>>>>>>>>> (Here's some meandering on the subject. While reading the code, >>>>>>>>>>> if I >>>>>>>>>>> am tracing the flow from caller definition to callee definition, >>>>>>>>>>> when >>>>>>>>>>> arguments are explicit I can observe them directly. But if they >>>>>>>>>>> are >>>>>>>>>>> defaulted, then I have to visit the callee's declaration as >>>>>>>>>>> well. I >>>>>>>>>>> have to visit three locations in the source instead of two. I >>>>>>>>>>> personally find this awkward unless the meaning of the defaulted >>>>>>>>>>> argument is immediately and intuitively obvious. In this case >>>>>>>>>>> the >>>>>>>>>>> meaning of the argument is subtly related to other parts of the >>>>>>>>>>> system.) >>>>>>>>>>> >>>>>>>>>>>> From the debugging standpoint it's way better to emit a barrier >>>>>>>>>>>> than >>>>>>>>>>>> not to. Missing barriers will be a nightmare to find. So, I'd >>>>>>>>>>>> rather >>>>>>>>>>>> have a barrier erroneously emitted in some path by default, >>>>>>>>>>>> which >>>>>>>>>>>> would make the marking crash almost immediately. >>>>>>>>>>> >>>>>>>>>>> Good point. >>>>>>>>>>> >>>>>>>>>>>> As for using !must_clear_dest as a gate, I thought it would >>>>>>>>>>>> more >>>>>>>>>>>> clearly convey to the reader the reason why the barrier is >>>>>>>>>>>> suppressed >>>>>>>>>>>> - because the dest array is not cleared and contains >>>>>>>>>>>> garbage, so >>>>>>>>>>>> the >>>>>>>>>>>> reader won't have to go back to see in which cases >>>>>>>>>>>> use_pre_barrier is >>>>>>>>>>>> set. Perhaps I should add more comments. >>>>>>>>>>> >>>>>>>>>>> The bug number would help a lot, I think. It's a subtle >>>>>>>>>>> interaction >>>>>>>>>>> between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 >>>>>>>>>>> invariants. >>>>>>>>>>> >>>>>>>>>>>>> In the stub generator the optional boolean is OK as is, >>>>>>>>>>>>> although I >>>>>>>>>>>>> generally prefer optional booleans to default to 'false'. >>>>>>>>>>>>> Given >>>>>>>>>>>>> the >>>>>>>>>>>>> way the bug is structured, I keep wanting to call it >>>>>>>>>>>>> 'suppress_pre_barrier', meaning "just this once, trust me >>>>>>>>>>>>> when I >>>>>>>>>>>>> tell you not to emit the pre-barrier, if there is one." >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> That's pretty much equivalent. I don't have strong feelings >>>>>>>>>>>> about >>>>>>>>>>>> this and will change it if you think it's more readable. >>>>>>>>>>> >>>>>>>>>>> I do think it would be more readable. It could be just an old >>>>>>>>>>> Lisper >>>>>>>>>>> bias, though: Optional arguments default to NULL, which is the >>>>>>>>>>> false >>>>>>>>>>> value in Lisp. >>>>>>>>>>> >>>>>>>>>>> -- John >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From tom.rodriguez at oracle.com Tue Mar 1 15:39:38 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 1 Mar 2011 15:39:38 -0800 Subject: Request for review(M): 6627983: G1: Bad oop deference during marking In-Reply-To: <4D6D7ECF.4070800@oracle.com> References: <4D66C186.4070201@oracle.com> <967A23B9-F8D6-4D64-B53A-90AB4CFFCAEC@oracle.com> <4D66FCA3.2030700@oracle.com> <4D670DC6.7020409@oracle.com> <4D6880AA.6000700@oracle.com> <4D6C5EF1.70801@oracle.com> <4D6D55B6.8000904@oracle.com> <4D6D5CE5.6070200@oracle.com> <5DD47A92-E731-4FDD-821C-35BA5A1C8332@oracle.com> <4D6D6AEF.8000400@oracle.com> <4D6D6D5B.8070403@oracle.com> <4D6D7445.9060307@oracle.com> <4D6D766C.1060300@oracle.com> <4D6D7A40.3010508@oracle.com> <4D6D7ECF.4070800@oracle.com> Message-ID: <2A2A10C5-1BE8-4A94-92F9-12899BDAE851@oracle.com> I don't know why it's there but you can delete it if you want. tom On Mar 1, 2011, at 3:18 PM, Igor Veresov wrote: > On 3/1/11 2:59 PM, Vladimir Kozlov wrote: >> Igor, >> >> Should you also check G1DisablePreBarrier flag which is currently used >> only here?: >> >> src/share/vm/c1/c1_LIRGenerator.cpp: if (G1DisablePreBarrier) return; >> > > Hm, it seems like a relatively meaningless C1 debugging flag (there's also G1DisablePostBarrier). It can only be useful just to check C1's output? G1 won't work without the barriers. > > igor > >> Vladimir >> >> Igor Veresov wrote: >>> On 3/1/11 2:33 PM, Vladimir Kozlov wrote: >>>> + // Also, if this flag is set we make sure that arraycopy intracts >>>> properly >>>> ^^^ >>> >>> Thanks. >>> >>> igor >>> >>>> Vladimir >>>> >>>> Igor Veresov wrote: >>>>> John, >>>>> >>>>> I'd like to rename must_clear_dest to dest_uninitialized and pass to >>>>> arraycopy instead of introducing additional variables. What do you >>>>> think? >>>>> >>>>> Here is the webrev: >>>>> http://cr.openjdk.java.net/~iveresov/6627983/webrev.02 >>>>> >>>>> Thanks, >>>>> igor >>>>> >>>>> On 3/1/11 1:53 PM, Igor Veresov wrote: >>>>>> On 3/1/11 1:08 PM, Tom Rodriguez wrote: >>>>>>> >>>>>>> On Mar 1, 2011, at 12:53 PM, Igor Veresov wrote: >>>>>>> >>>>>>>> On 3/1/11 12:23 PM, Vladimir Kozlov wrote: >>>>>>>>> I have only comments about library_call.cpp: >>>>>>>>> >>>>>>>>> Why "false" in copy_to_clone()? It seems, you get double >>>>>>>>> barriers in >>>>>>>>> this method as well: >>>>>>>>> 4085 /*dest_uninitialized*/false); >>>>>>>> >>>>>>>> It doesn't matter here, because we're treating it all as T_LONGs, so >>>>>>>> there's going to be no barriers. But for consistency I suppose it >>>>>>>> could be "true" here. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 4596 // so the the pre-barriers wouldn't peek into the old values. >>>>>>>>> See >>>>>>>>> CR 6627983. >>>>>>>>> ^ 'the' 2 times ^ unitialized >>>>>>>> Fixed. Thanks! >>>>>>>> >>>>>>>>> 4597 const bool& dest_uninitialized = must_clear_dest; >>>>>>>>> ^ why reference? >>>>>>>>> >>>>>>>> >>>>>>>> John wanted a separate variable to inform arraycopy of whether the >>>>>>>> target is initialized. This variable should in fact follow the state >>>>>>>> of the must_clear_dest, so I decided to make it a reference, so that >>>>>>>> when must_clear_dest changes so does dest_uninitialized. If you >>>>>>>> don't >>>>>>>> like that I can make it a regular variable. >>>>>>>> >>>>>>>> Although I would rather just used must_clear_dest for everything and >>>>>>>> not replicate the state. >>>>>>> >>>>>>> no local variable references please. Just pass must_clear_dest or >>>>>>> rename it to dest_uninitalized. >>>>>> >>>>>> Ok. >>>>>> >>>>>> igor >>>>>> >>>>>>> >>>>>>> tom >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> igor >>>>>>>> >>>>>>>> >>>>>>>>> The rest changes seems fine. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> Igor Veresov wrote: >>>>>>>>>> John, all, >>>>>>>>>> >>>>>>>>>> I've updated the change, making corrections that John recommended. >>>>>>>>>> Also, now the decision about what to do with the barrier is >>>>>>>>>> deferred >>>>>>>>>> to the barrier emitting procedure. Thus, if a new pre-barrier is >>>>>>>>>> added >>>>>>>>>> that would need to do something even in case if the destination >>>>>>>>>> array >>>>>>>>>> is uninitialized it can be handled properly. >>>>>>>>>> >>>>>>>>>> New webrev: http://cr.openjdk.java.net/~iveresov/6627983/webrev.01 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> igor >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/25/11 8:25 PM, Igor Veresov wrote: >>>>>>>>>>> I think my fix is not good enough for the case when we'll need >>>>>>>>>>> prebarriers that will not require the previous value and these >>>>>>>>>>> could be >>>>>>>>>>> a reality in the future. So, it is generally incorrect to elide >>>>>>>>>>> prebarriers but is only ok for a specific flavor. I'm working to >>>>>>>>>>> alleviate this problem a little bit and will post the updated >>>>>>>>>>> version >>>>>>>>>>> early next week. John, I will also address your recommendations. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> igor >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2/24/11 6:28 PM, John Rose wrote: >>>>>>>>>>>> On Feb 24, 2011, at 6:02 PM, Igor Veresov wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 2/24/11 5:27 PM, John Rose wrote: >>>>>>>>>>>>>> On Feb 24, 2011, at 4:49 PM, Igor Veresov wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> If it is simply foo(..., !must_clear_dest), it becomes hard >>>>>>>>>>>>>> for >>>>>>>>>>>>>> maintainers to see what the argument means. >>>>>>>>>>>>> >>>>>>>>>>>>> I can see your point but I just didn't want to introduce >>>>>>>>>>>>> additional >>>>>>>>>>>>> clutter. For example generate_block_arraycopy() never requires >>>>>>>>>>>>> barrier suppression, so why do we need to add an argument >>>>>>>>>>>>> there? >>>>>>>>>>>> >>>>>>>>>>>> There's not a strong need. An extra "true" or "false" would be a >>>>>>>>>>>> little clutter, but it would also hint to programmers what's >>>>>>>>>>>> going on. >>>>>>>>>>>> It's a esthetic call mostly... >>>>>>>>>>>> >>>>>>>>>>>> (Here's some meandering on the subject. While reading the code, >>>>>>>>>>>> if I >>>>>>>>>>>> am tracing the flow from caller definition to callee definition, >>>>>>>>>>>> when >>>>>>>>>>>> arguments are explicit I can observe them directly. But if they >>>>>>>>>>>> are >>>>>>>>>>>> defaulted, then I have to visit the callee's declaration as >>>>>>>>>>>> well. I >>>>>>>>>>>> have to visit three locations in the source instead of two. I >>>>>>>>>>>> personally find this awkward unless the meaning of the defaulted >>>>>>>>>>>> argument is immediately and intuitively obvious. In this case >>>>>>>>>>>> the >>>>>>>>>>>> meaning of the argument is subtly related to other parts of the >>>>>>>>>>>> system.) >>>>>>>>>>>> >>>>>>>>>>>>> From the debugging standpoint it's way better to emit a barrier >>>>>>>>>>>>> than >>>>>>>>>>>>> not to. Missing barriers will be a nightmare to find. So, I'd >>>>>>>>>>>>> rather >>>>>>>>>>>>> have a barrier erroneously emitted in some path by default, >>>>>>>>>>>>> which >>>>>>>>>>>>> would make the marking crash almost immediately. >>>>>>>>>>>> >>>>>>>>>>>> Good point. >>>>>>>>>>>> >>>>>>>>>>>>> As for using !must_clear_dest as a gate, I thought it would >>>>>>>>>>>>> more >>>>>>>>>>>>> clearly convey to the reader the reason why the barrier is >>>>>>>>>>>>> suppressed >>>>>>>>>>>>> - because the dest array is not cleared and contains >>>>>>>>>>>>> garbage, so >>>>>>>>>>>>> the >>>>>>>>>>>>> reader won't have to go back to see in which cases >>>>>>>>>>>>> use_pre_barrier is >>>>>>>>>>>>> set. Perhaps I should add more comments. >>>>>>>>>>>> >>>>>>>>>>>> The bug number would help a lot, I think. It's a subtle >>>>>>>>>>>> interaction >>>>>>>>>>>> between (a) zeroing removal, (b) the arraycopy stubs, and (c) G1 >>>>>>>>>>>> invariants. >>>>>>>>>>>> >>>>>>>>>>>>>> In the stub generator the optional boolean is OK as is, >>>>>>>>>>>>>> although I >>>>>>>>>>>>>> generally prefer optional booleans to default to 'false'. >>>>>>>>>>>>>> Given >>>>>>>>>>>>>> the >>>>>>>>>>>>>> way the bug is structured, I keep wanting to call it >>>>>>>>>>>>>> 'suppress_pre_barrier', meaning "just this once, trust me >>>>>>>>>>>>>> when I >>>>>>>>>>>>>> tell you not to emit the pre-barrier, if there is one." >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> That's pretty much equivalent. I don't have strong feelings >>>>>>>>>>>>> about >>>>>>>>>>>>> this and will change it if you think it's more readable. >>>>>>>>>>>> >>>>>>>>>>>> I do think it would be more readable. It could be just an old >>>>>>>>>>>> Lisper >>>>>>>>>>>> bias, though: Optional arguments default to NULL, which is the >>>>>>>>>>>> false >>>>>>>>>>>> value in Lisp. >>>>>>>>>>>> >>>>>>>>>>>> -- John >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From igor.veresov at oracle.com Tue Mar 1 18:15:01 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 02 Mar 2011 02:15:01 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6627983: G1: Bad oop deference during marking Message-ID: <20110302021507.E691C47BAB@hg.openjdk.java.net> Changeset: 0ac769a57c64 Author: iveresov Date: 2011-03-01 14:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0ac769a57c64 6627983: G1: Bad oop deference during marking Summary: Bulk zeroing reduction didn't work with G1, because arraycopy would call pre-barriers on uninitialized oops. The solution is to have version of arraycopy stubs that don't have pre-barriers. Also refactored arraycopy stubs generation on SPARC to be more readable and reduced the number of stubs necessary in some cases. Reviewed-by: jrose, kvn, never ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp From vladimir.kozlov at oracle.com Wed Mar 2 10:52:05 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Mar 2011 10:52:05 -0800 Subject: Request for reviews (S): 6589823: Error: meet not symmetric Message-ID: <4D6E91D5.9040202@oracle.com> http://cr.openjdk.java.net/~kvn/6589823/webrev Fixed 6589823: Error: meet not symmetric The result of TypeAryPtr::meet() must fall to bottom if exact classes in upper lattice are not equal. From tom.rodriguez at oracle.com Wed Mar 2 15:08:54 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 2 Mar 2011 15:08:54 -0800 Subject: review (S) for 6965570: assert(!needs_patching && x->is_loaded(), "how do we know it's volatile if it's not loaded") In-Reply-To: <4D6D42AE.3000406@oracle.com> References: <4D6D42AE.3000406@oracle.com> Message-ID: <154D0252-EB2B-465C-91DA-BB819470296C@oracle.com> Thanks! tom On Mar 1, 2011, at 11:02 AM, Igor Veresov wrote: > Looks good. > > igor > > On 3/1/11 10:32 AM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6965570 >> >> 6965570: assert(!needs_patching&& x->is_loaded(),"how do we know it's volatile if it's not loaded") >> Reviewed-by: >> >> During code generation for a volatile getfield in an outer class we've >> managed to resolve the inner class symbolically but the constant pool >> reference hasn't actually been resolved. This results in a field >> reference that should be patched so that the proper access checks are >> performed by constant pool resolution. In this case the field is >> volatile and LIRGenerator expects that if the class was loaded and we >> can see that's it actually volatile that a patch must not be needed. >> In debug mode this asserts but in product mode it generates code to >> uses max_jint for the field offset. The fix is to always respect the >> needs_patching flag. We could makes the patching machinery handle >> this more normally but that would complicate patching even more. It's >> a rare case so allowing deopt in Runtime1::patch_code to handle it is >> the easiest way to go. >> >> Part of the confusion stems from the is_loaded flag on AccessField >> which doesn't really mean what it says, so I've removed it and pushed >> all the needs_patching logic up into GraphBuilder. is_initialized() >> is similarly confusing since it really means does this static field >> need patching. I've eliminated that flag from AccessField and >> captured that logic in a new method that is used instead. Tested with >> runthese with and without PatchALot, ctw, and the nsk jvmti tests. > From christian.thalinger at oracle.com Thu Mar 3 02:35:40 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Mar 2011 11:35:40 +0100 Subject: Request for review (L): 6839872: remove implementation inheritance from JSR 292 APIs Message-ID: http://cr.openjdk.java.net/~twisti/6839872/webrev.01/ 6839872: remove implementation inheritance from JSR 292 APIs Summary: Move all JSR 292 classes into the java.dyn package. Reviewed-by: Initial versions (including the preview in 7/M3) of the JSR 292 API use an undesirable technique for data structure factoring, implementation inheritance. The types MethodHandle and JavaMethodHandle both inherit from JVM-internal supertypes. The solution is to remove those private supertypes from those public types. This is the JVM part of 6839872. It adds support to the JVM to handle both namespaces, java.dyn/sun.dyn and java.dyn only. The support for the old namespace (AllowTransitionalJSR292) will be removed as soon as the related JDK changes appear in the repositories. From christian.thalinger at oracle.com Thu Mar 3 02:36:59 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Mar 2011 11:36:59 +0100 Subject: Request for review (XL): 7012648: move JSR 292 to package java.lang.invoke and adjust names Message-ID: http://cr.openjdk.java.net/~twisti/7012648/webrev.01/ 7012648: move JSR 292 to package java.lang.invoke and adjust names Summary: package and class renaming only; delete unused methods and classes Reviewed-by: At the request of the JDK7 Architect, the JSR 292 EG has agreed moving the API from the package java.dyn to the package java.lang.invoke. This is the JVM part of 7012648. The support for the old namespace (AllowTransitionalJSR292) will be removed as soon as the related JDK changes appear in the repositories. From dawid.weiss at gmail.com Thu Mar 3 04:39:44 2011 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 3 Mar 2011 13:39:44 +0100 Subject: Endless loops in computation code (1.6.0_22). Message-ID: Hi. We see an infrequent, but very annoying VM hangups in purely computational code, as in here: http://builds.carrot2.org/build/result/viewBuildResultsFailedTests.action?buildKey=JSA-JSAHEAD-JOB1&buildNumber=8 The loop in question is like this: for (c0 = ALPHABET_SIZE - 2, j = m; 0 < j; --c0) { for (c1 = ALPHABET_SIZE - 1; c0 < c1; j = i, --c1) { i = bucket_B[(c0) * ALPHABET_SIZE + (c1)]; if (1 < (j - i)) { ssSort(PAb, i, j, buf, bufsize, 2, n, SA[i] == (m - 1)); } } } Unfortunately I cannot provide an always-halting example, but the bug seems to be JVM-related because: 1) once the VM hangs in debugging mode, breaking out to the debugger and stepping through the code terminates normally (so a deopt. I assume), 2) the freeze is non-deterministic, while the test is (regardless of the 'randomness', it always starts from the same seed), 3) we could reproduce this occasionally under different VMs and different OSs (64-bit linux, 64-bit Windows). Has there been any bug in the JIT that might be causing this? Thanks for pointers if you recognize an evil code pattern above. Dawid P.S. The above code is a translation from another person's C snippet, so I can't easily explain why the loop is built this way or why c0 is passed between the inner and outer loop :). From christian.thalinger at oracle.com Thu Mar 3 02:36:59 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Mar 2011 11:36:59 +0100 Subject: Request for review (XL): 7012648: move JSR 292 to package java.lang.invoke and adjust names Message-ID: http://cr.openjdk.java.net/~twisti/7012648/webrev.01/ 7012648: move JSR 292 to package java.lang.invoke and adjust names Summary: package and class renaming only; delete unused methods and classes Reviewed-by: At the request of the JDK7 Architect, the JSR 292 EG has agreed moving the API from the package java.dyn to the package java.lang.invoke. This is the JVM part of 7012648. The support for the old namespace (AllowTransitionalJSR292) will be removed as soon as the related JDK changes appear in the repositories. From kirk at kodewerk.com Thu Mar 3 07:57:38 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Thu, 3 Mar 2011 16:57:38 +0100 Subject: inspecting the code cache Message-ID: Hi, What is the best way to inspect the contents of the code cache? I'm looking to see if a method that has been compiled has been evicted from the cache. Kind regards, Kirk From forax at univ-mlv.fr Thu Mar 3 08:07:11 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 03 Mar 2011 17:07:11 +0100 Subject: inspecting the code cache In-Reply-To: References: Message-ID: <4D6FBCAF.1030904@univ-mlv.fr> Le 03/03/2011 16:57, Charles K Pepperdine a ?crit : > Hi, > > What is the best way to inspect the contents of the code cache? I'm looking to see if a method that has been compiled has been evicted from the cache. > > Kind regards, > Kirk PrintCompilation prints this information but I supppose you already know that. R?mi From tom.rodriguez at oracle.com Thu Mar 3 10:08:23 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 3 Mar 2011 10:08:23 -0800 Subject: inspecting the code cache In-Reply-To: References: Message-ID: PrintCompilation will tell you if it's no longer being used. The "mande not entrant" messages mean that we will no longer call that method though it's possible that there are still existing activations. The "made zombie" message means that there are no activations. It will hang around for a little while in the code cache after that because the cleanup is asynchronous but no one will be using it anymore. tom On Mar 3, 2011, at 7:57 AM, Charles K Pepperdine wrote: > Hi, > > What is the best way to inspect the contents of the code cache? I'm looking to see if a method that has been compiled has been evicted from the cache. > > Kind regards, > Kirk From kirk at kodewerk.com Thu Mar 3 10:47:05 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Thu, 3 Mar 2011 19:47:05 +0100 Subject: inspecting the code cache In-Reply-To: References: Message-ID: <5691E1D8-D5A5-4AC0-9581-FABD6258B462@kodewerk.com> Hi, Thanks for that information. I've been using PrintCompilation to watch what was going on. I've gotten a question from a client that claims that a method had seemingly been squeezed out of the cache. I'm not sure what would cause a method to be squeezed out but I guess it would have to be made not entrant before hand. But that got me interested in poking about to see what information one could squeeze out of the JVM wrt the code cache. TIA, Kirk From tom.rodriguez at oracle.com Thu Mar 3 12:00:28 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 3 Mar 2011 12:00:28 -0800 Subject: inspecting the code cache In-Reply-To: <5691E1D8-D5A5-4AC0-9581-FABD6258B462@kodewerk.com> References: <5691E1D8-D5A5-4AC0-9581-FABD6258B462@kodewerk.com> Message-ID: <624C3862-AAF5-48E5-BE54-BC3FE8430668@oracle.com> On Mar 3, 2011, at 10:47 AM, Charles K Pepperdine wrote: > Hi, > > Thanks for that information. I've been using PrintCompilation to watch what was going on. I've gotten a question from a client that claims that a method had seemingly been squeezed out of the cache. I'm not sure what would cause a method to be squeezed out but I guess it would have to be made not entrant before hand. But that got me interested in poking about to see what information one could squeeze out of the JVM wrt the code cache. Code will never get "squeezed" out in the current system. We generate code as needed and only get rid of it when it gets invalidated or if it references classes which get unloaded. If the code cache fills up you might not be able to compile something that needs code though. tom > > TIA, > Kirk > From dmdabbs at gmail.com Thu Mar 3 12:07:47 2011 From: dmdabbs at gmail.com (David Dabbs) Date: Thu, 3 Mar 2011 14:07:47 -0600 Subject: inspecting the code cache In-Reply-To: <624C3862-AAF5-48E5-BE54-BC3FE8430668@oracle.com> References: <5691E1D8-D5A5-4AC0-9581-FABD6258B462@kodewerk.com> <624C3862-AAF5-48E5-BE54-BC3FE8430668@oracle.com> Message-ID: <008001cbd9de$ab149110$013db330$@com> > -----Original Message----- > From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot- > compiler-dev-bounces at openjdk.java.net] On Behalf Of Tom Rodriguez > Sent: Thursday, March 03, 2011 2:00 PM > To: Charles K Pepperdine > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: inspecting the code cache > > > On Mar 3, 2011, at 10:47 AM, Charles K Pepperdine wrote: > > > Hi, > > > > Thanks for that information. I've been using PrintCompilation to > watch what was going on. I've gotten a question from a client that > claims that a method had seemingly been squeezed out of the cache. I'm > not sure what would cause a method to be squeezed out but I guess it > would have to be made not entrant before hand. But that got me > interested in poking about to see what information one could squeeze > out of the JVM wrt the code cache. > > Code will never get "squeezed" out in the current system. We generate > code as needed and only get rid of it when it gets invalidated or if it > references classes which get unloaded. If the code cache fills up you > might not be able to compile something that needs code though. > > tom > > > > > > TIA, > > Kirk > > Does -XX:+UseCodeCacheFlushing enable this clearing of invalidated code? Or does that do something different? Thanks, David From tom.rodriguez at oracle.com Thu Mar 3 12:14:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 3 Mar 2011 12:14:32 -0800 Subject: inspecting the code cache In-Reply-To: <008001cbd9de$ab149110$013db330$@com> References: <5691E1D8-D5A5-4AC0-9581-FABD6258B462@kodewerk.com> <624C3862-AAF5-48E5-BE54-BC3FE8430668@oracle.com> <008001cbd9de$ab149110$013db330$@com> Message-ID: >>> Thanks for that information. I've been using PrintCompilation to >> watch what was going on. I've gotten a question from a client that >> claims that a method had seemingly been squeezed out of the cache. I'm >> not sure what would cause a method to be squeezed out but I guess it >> would have to be made not entrant before hand. But that got me >> interested in poking about to see what information one could squeeze >> out of the JVM wrt the code cache. >> >> Code will never get "squeezed" out in the current system. We generate >> code as needed and only get rid of it when it gets invalidated or if it >> references classes which get unloaded. If the code cache fills up you >> might not be able to compile something that needs code though. >> >> tom >> >> >>> >>> TIA, >>> Kirk >>> > > Does -XX:+UseCodeCacheFlushing enable this clearing of invalidated code? > Or does that do something different? No that's something different. The clearing of the code is done by something called the sweeper and you can't disable it. UseCodeCacheFlushing implements an LRU-ish policy for keeping the code cache from filling up. It's currently not enabled by default because we've seen some hard to track down problems when using it with very long running programs. They may not actually be the fault of the flushing itself but the extra pressure it puts on the concurrent sweeping that actually reclaims them. It should become the default once we track down the sweeping issue. tom > > > Thanks, > > David > > > From tom.rodriguez at oracle.com Thu Mar 3 12:37:57 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 3 Mar 2011 12:37:57 -0800 Subject: Endless loops in computation code (1.6.0_22). In-Reply-To: References: Message-ID: <7684FD62-77E8-476F-AD2F-479ACC66A79A@oracle.com> On Mar 3, 2011, at 4:39 AM, Dawid Weiss wrote: > Hi. We see an infrequent, but very annoying VM hangups in purely > computational code, as in here: > > http://builds.carrot2.org/build/result/viewBuildResultsFailedTests.action?buildKey=JSA-JSAHEAD-JOB1&buildNumber=8 > > The loop in question is like this: > > for (c0 = ALPHABET_SIZE - 2, j = m; 0 < j; --c0) > { > for (c1 = ALPHABET_SIZE - 1; c0 < c1; j = i, --c1) > { > i = bucket_B[(c0) * ALPHABET_SIZE + (c1)]; > if (1 < (j - i)) > { > ssSort(PAb, i, j, buf, bufsize, 2, n, SA[i] == (m - 1)); > } > } > } > > Unfortunately I cannot provide an always-halting example, but the bug > seems to be JVM-related because: > > 1) once the VM hangs in debugging mode, breaking out to the debugger > and stepping through the code terminates normally (so a deopt. I > assume), Is it hanging, as in making no progress, or not terminating? Does it terminate if given a lot more time? It's not GC bound? By debugger do you mean gdb or a Java debugger? tom > > 2) the freeze is non-deterministic, while the test is (regardless of > the 'randomness', it always starts from the same seed), > > 3) we could reproduce this occasionally under different VMs and > different OSs (64-bit linux, 64-bit Windows). > > Has there been any bug in the JIT that might be causing this? Thanks > for pointers if you recognize an evil code pattern above. > > Dawid > > P.S. The above code is a translation from another person's C snippet, > so I can't easily explain why the loop is built this way or why c0 is > passed between the inner and outer loop :). From dawid.weiss at gmail.com Thu Mar 3 12:53:01 2011 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 3 Mar 2011 21:53:01 +0100 Subject: Endless loops in computation code (1.6.0_22). In-Reply-To: <7684FD62-77E8-476F-AD2F-479ACC66A79A@oracle.com> References: <7684FD62-77E8-476F-AD2F-479ACC66A79A@oracle.com> Message-ID: Hi Tom. Apologies for not providing a broader context, it follows. > Is it hanging, as in making no progress, or not terminating? It is hanging as in: it consumes 100% of a single core, never terminates (when executed without debugging), in the debugging mode it does not terminate until a JVM breakpoint is set inside the loop below, then it breaks out to the debugger and you can step-by-step execute the code or re-run it and, magically, it will terminate. > Does it terminate if given a lot more time? It's not GC bound? By debugger do you mean gdb or a Java debugger? No, it never terminates... at least not in a reasonable time. Normally this loop ends in 2-3 seconds and when hung it does not terminate after 30 minutes or so (the longest we waited to kill it on the build server). To me It looks like it JITs into something that causes an endless loop. I also checked with jrockit and J9 and these never hung, so it's probably hotspot. Talking about the debugger, that was a Java debugger, I didn't inspect JIT dumps of what this method compiles to yet, didn't have the time and wanted to check if it's a known issue first. I'll try to reproduce it with JIT code dumps, I'll let you know if I succeed. Dawid On Thu, Mar 3, 2011 at 9:37 PM, Tom Rodriguez wrote: > > On Mar 3, 2011, at 4:39 AM, Dawid Weiss wrote: > > > Hi. We see an infrequent, but very annoying VM hangups in purely > > computational code, as in here: > > > > > http://builds.carrot2.org/build/result/viewBuildResultsFailedTests.action?buildKey=JSA-JSAHEAD-JOB1&buildNumber=8 > > > > The loop in question is like this: > > > > for (c0 = ALPHABET_SIZE - 2, j = m; 0 < j; --c0) > > { > > for (c1 = ALPHABET_SIZE - 1; c0 < c1; j = i, --c1) > > { > > i = bucket_B[(c0) * ALPHABET_SIZE + (c1)]; > > if (1 < (j - i)) > > { > > ssSort(PAb, i, j, buf, bufsize, 2, n, SA[i] == (m > - 1)); > > } > > } > > } > > > > Unfortunately I cannot provide an always-halting example, but the bug > > seems to be JVM-related because: > > > > 1) once the VM hangs in debugging mode, breaking out to the debugger > > and stepping through the code terminates normally (so a deopt. I > > assume), > > Is it hanging, as in making no progress, or not terminating? Does it > terminate if given a lot more time? It's not GC bound? By debugger do you > mean gdb or a Java debugger? > > tom > > > > > 2) the freeze is non-deterministic, while the test is (regardless of > > the 'randomness', it always starts from the same seed), > > > > 3) we could reproduce this occasionally under different VMs and > > different OSs (64-bit linux, 64-bit Windows). > > > > Has there been any bug in the JIT that might be causing this? Thanks > > for pointers if you recognize an evil code pattern above. > > > > Dawid > > > > P.S. The above code is a translation from another person's C snippet, > > so I can't easily explain why the loop is built this way or why c0 is > > passed between the inner and outer loop :). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110303/2168ff20/attachment.html From tom.rodriguez at oracle.com Thu Mar 3 13:18:54 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 3 Mar 2011 13:18:54 -0800 Subject: Endless loops in computation code (1.6.0_22). In-Reply-To: References: <7684FD62-77E8-476F-AD2F-479ACC66A79A@oracle.com> Message-ID: On Mar 3, 2011, at 12:53 PM, Dawid Weiss wrote: > > Hi Tom. > > Apologies for not providing a broader context, it follows. > > > Is it hanging, as in making no progress, or not terminating? > > It is hanging as in: it consumes 100% of a single core, never terminates (when executed without debugging), in the debugging mode it does not terminate until a JVM breakpoint is set inside the loop below, then it breaks out to the debugger and you can step-by-step execute the code or re-run it and, magically, it will terminate. Inserting the breakpoint would deopt the code and you'll resume in the interpreter so you'll end up avoiding the JITed code which presumably is where the bug is. > > > Does it terminate if given a lot more time? It's not GC bound? By debugger do you mean gdb or a Java debugger? > > No, it never terminates... at least not in a reasonable time. Normally this loop ends in 2-3 seconds and when hung it does not terminate after 30 minutes or so (the longest we waited to kill it on the build server). > > To me It looks like it JITs into something that causes an endless loop. I also checked with jrockit and J9 and these never hung, so it's probably hotspot. I agree. It sounds like we're screwing up the bounds somehow. Is there a jar file I can grab to run this test easily? tom > > Talking about the debugger, that was a Java debugger, I didn't inspect JIT dumps of what this method compiles to yet, didn't have the time and wanted to check if it's a known issue first. > > I'll try to reproduce it with JIT code dumps, I'll let you know if I succeed. > > Dawid > > On Thu, Mar 3, 2011 at 9:37 PM, Tom Rodriguez wrote: > > On Mar 3, 2011, at 4:39 AM, Dawid Weiss wrote: > > > Hi. We see an infrequent, but very annoying VM hangups in purely > > computational code, as in here: > > > > http://builds.carrot2.org/build/result/viewBuildResultsFailedTests.action?buildKey=JSA-JSAHEAD-JOB1&buildNumber=8 > > > > The loop in question is like this: > > > > for (c0 = ALPHABET_SIZE - 2, j = m; 0 < j; --c0) > > { > > for (c1 = ALPHABET_SIZE - 1; c0 < c1; j = i, --c1) > > { > > i = bucket_B[(c0) * ALPHABET_SIZE + (c1)]; > > if (1 < (j - i)) > > { > > ssSort(PAb, i, j, buf, bufsize, 2, n, SA[i] == (m - 1)); > > } > > } > > } > > > > Unfortunately I cannot provide an always-halting example, but the bug > > seems to be JVM-related because: > > > > 1) once the VM hangs in debugging mode, breaking out to the debugger > > and stepping through the code terminates normally (so a deopt. I > > assume), > > Is it hanging, as in making no progress, or not terminating? Does it terminate if given a lot more time? It's not GC bound? By debugger do you mean gdb or a Java debugger? > > tom > > > > > 2) the freeze is non-deterministic, while the test is (regardless of > > the 'randomness', it always starts from the same seed), > > > > 3) we could reproduce this occasionally under different VMs and > > different OSs (64-bit linux, 64-bit Windows). > > > > Has there been any bug in the JIT that might be causing this? Thanks > > for pointers if you recognize an evil code pattern above. > > > > Dawid > > > > P.S. The above code is a translation from another person's C snippet, > > so I can't easily explain why the loop is built this way or why c0 is > > passed between the inner and outer loop :). > > From dawid.weiss at gmail.com Thu Mar 3 13:39:27 2011 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 3 Mar 2011 22:39:27 +0100 Subject: Endless loops in computation code (1.6.0_22). In-Reply-To: References: <7684FD62-77E8-476F-AD2F-479ACC66A79A@oracle.com> Message-ID: > Inserting the breakpoint would deopt the code and you'll resume in the > interpreter so you'll end up avoiding the JITed code which presumably is > where the bug is. > Yep, I realize this is the case, I even mentioned it in my original post. Let me double check that we're not doing something non-deterministic first though... but if you'd like to try then... > I agree. It sounds like we're screwing up the bounds somehow. Is there a > jar file I can grab to run this test easily? > Mind this is happening infrequently (but on different machines, different OSs, etc.). Here's the procedure: git clone git at github.com:carrotsearch/jsuffixarrays.git cd jsuffixarrays # while (true)? { mvn test # } I've just done the above and it hung on the first execution... the next one it didn't, the third one it did again. So maybe it is happening more frequently than less. The JRE I did it on is: java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) But it applies to newer versions as well. The particular class that is causing this is DivSufSort (DivSufSortTest), but I don't know what causes this to happen, so I'd run all of them (these are parallel testng tests). I also didn't check with the trunk HotSpot, so it may be something that's already been fixed. Dawid -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110303/561776df/attachment.html From dawid.weiss at gmail.com Thu Mar 3 14:14:10 2011 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 3 Mar 2011 23:14:10 +0100 Subject: Endless loops in computation code (1.6.0_22). In-Reply-To: References: <7684FD62-77E8-476F-AD2F-479ACC66A79A@oracle.com> Message-ID: This must be a hotspot bug, Tom, it's insane. So. I've created a branch to run all the tests in sequence and dump loop counters to stdout. There's also -XX:PrintCompilation so that you can see what got compiled. So, do these: git pull git co JVM_BUG the problematic loop now looks like this: int c0, c1 = 0; // ... for (c0 = ALPHABET_SIZE - 2, j = m; 0 < j; --c0) { for (c1 = ALPHABET_SIZE - 1; c0 < c1; j = i, --c1) { System.err.println("C0: " + c0 + " C1: " + c1); i = bucket_B[(c0) * ALPHABET_SIZE + (c1)]; if (1 < (j - i)) { ssSort(PAb, i, j, buf, bufsize, 2, n, SA[i] == (m - 1)); } } } even not knowing what other elements are, c0 and c1 are local variables that are not modified anywhere inside the loop other than decremented on every loop run (inside and outside). The output is as one would expect, from the start: C0: 254 C1: 255 C0: 253 C1: 255 C0: 253 C1: 254 C0: 252 C1: 255 C0: 252 C1: 254 C0: 252 C1: 253 ... so both counters are decrement... until this happens (run 1): ... C0: 74 C1: 77 C0: 74 C1: 76 C0: 74 C1: 75 C0: 254 C1: 255 C0: 254 C1: 255 [forever] And run2, for example: ... C0: 68 C1: 70 C0: 68 C1: 69 C0: 254 C1: 255 C0: 254 C1: 255 C0: 254 C1: 255 note that counter values: C0: 254 C1: 255 are actually what it all started with, but why it'd never decrement again is beyond me. The compilation dump shows that nothing special happens before the code falls into an endless loop (I assume stdout writes are sequential when they go via Maven's test plugin, but don't know for sure). I also checked with: java version "1.7.0-ea" Java(TM) SE Runtime Environment (build 1.7.0-ea-b104) Java HotSpot(TM) 64-Bit Server VM (build 19.0-b05, mixed mode) and it exhibits the same problem. Sadly, I don't know how to use gdb to hack into a running VM instance to inspect what is actually happening, but if I can be of any further help, let me know. Dawid On Thu, Mar 3, 2011 at 10:39 PM, Dawid Weiss wrote: > > >> Inserting the breakpoint would deopt the code and you'll resume in the >> interpreter so you'll end up avoiding the JITed code which presumably is >> where the bug is. >> > > Yep, I realize this is the case, I even mentioned it in my original post. > Let me double check that we're not doing something non-deterministic first > though... but if you'd like to try then... > > >> I agree. It sounds like we're screwing up the bounds somehow. Is there a >> jar file I can grab to run this test easily? >> > > Mind this is happening infrequently (but on different machines, different > OSs, etc.). Here's the procedure: > > git clone git at github.com:carrotsearch/jsuffixarrays.git > cd jsuffixarrays > # while (true)? { > mvn test > # } > > I've just done the above and it hung on the first execution... the next one > it didn't, the third one it did again. So maybe it is happening more > frequently than less. The JRE I did it on is: > > java version "1.6.0_20" > Java(TM) SE Runtime Environment (build 1.6.0_20-b02) > Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) > > But it applies to newer versions as well. > > The particular class that is causing this is DivSufSort (DivSufSortTest), > but I don't know what causes this to happen, so I'd run all of them (these > are parallel testng tests). > > I also didn't check with the trunk HotSpot, so it may be something that's > already been fixed. > > Dawid > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110303/2ed06ca8/attachment.html From vladimir.kozlov at oracle.com Thu Mar 3 15:58:35 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Mar 2011 15:58:35 -0800 Subject: Request for review (L): 6839872: remove implementation inheritance from JSR 292 APIs In-Reply-To: References: Message-ID: <4D702B2B.3010201@oracle.com> Looks good to me. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6839872/webrev.01/ > > 6839872: remove implementation inheritance from JSR 292 APIs > Summary: Move all JSR 292 classes into the java.dyn package. > Reviewed-by: > > Initial versions (including the preview in 7/M3) of the JSR 292 API > use an undesirable technique for data structure factoring, > implementation inheritance. The types MethodHandle and > JavaMethodHandle both inherit from JVM-internal supertypes. > > The solution is to remove those private supertypes from those public > types. > > This is the JVM part of 6839872. It adds support to the JVM to handle > both namespaces, java.dyn/sun.dyn and java.dyn only. > > The support for the old namespace (AllowTransitionalJSR292) will be > removed as soon as the related JDK changes appear in the > repositories. From vladimir.kozlov at oracle.com Thu Mar 3 16:48:47 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Mar 2011 16:48:47 -0800 Subject: Request for review (XL): 7012648: move JSR 292 to package java.lang.invoke and adjust names In-Reply-To: References: Message-ID: <4D7036EF.8020504@oracle.com> systemDictionary.hpp: why switching back to sun.dyn?: - template(MethodHandleImpl_klass, java_dyn_MethodHandleImpl, Pre_JSR292) /* AllowTransitionalJSR292 ONLY */ \ + template(MethodHandleImpl_klass, sun_dyn_MethodHandleImpl, Opt) /* AllowTransitionalJSR292 ONLY */ \ methodHandleWalk.cpp: comment says "java.dyn" but should it be "java.lang.invoke"? : + if (m == NULL) + // sun.dyn.MethodHandleImpl not found, look for java.dyn.MethodHandleNatives: + m = vmIntrinsics::method_for(vmIntrinsics::_checkSpreadArgument_TRANS2); Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7012648/webrev.01/ > > 7012648: move JSR 292 to package java.lang.invoke and adjust names > Summary: package and class renaming only; delete unused methods and classes > Reviewed-by: > > At the request of the JDK7 Architect, the JSR 292 EG has agreed moving > the API from the package java.dyn to the package java.lang.invoke. > > This is the JVM part of 7012648. > > The support for the old namespace (AllowTransitionalJSR292) will be > removed as soon as the related JDK changes appear in the > repositories. From igor.veresov at oracle.com Thu Mar 3 17:51:28 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 03 Mar 2011 17:51:28 -0800 Subject: Request for review(M): 7020403: Add AdvancedCompilationPolicy for tiered Message-ID: <4D7045A0.3090908@oracle.com> This implements adaptive tiered compilation policy. Webrev: http://cr.openjdk.java.net/~iveresov/7020403/webrev.00/ Thanks, igor From tom.rodriguez at oracle.com Thu Mar 3 18:04:50 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 3 Mar 2011 18:04:50 -0800 Subject: Endless loops in computation code (1.6.0_22). In-Reply-To: References: <7684FD62-77E8-476F-AD2F-479ACC66A79A@oracle.com> Message-ID: <6844B58D-2A2A-4420-A5D9-A71AA4C3332C@oracle.com> After watching maven download jars for 10 minutes, it actually ran the test and reproduced it. I put together a little main to run the test manually and just reproduced it with -XX:+PrintCompilation. It hung right after it printed this: 3% org.jsuffixarrays.DivSufSort::sortTypeBstar @ 979 (1125 bytes) so it's possible it's a bug with with on stack replacement. I've reproduced it with the latest 1.7 as well so it's something we haven't seen before. I filed 7024475 for this and put you on the interest list. I can't reproduce it in 6u12 but I can in 6u14 so I think it appeared there. tom On Mar 3, 2011, at 2:14 PM, Dawid Weiss wrote: > > This must be a hotspot bug, Tom, it's insane. So. > > I've created a branch to run all the tests in sequence and dump loop counters to stdout. There's also -XX:PrintCompilation so that you can see what got compiled. So, do these: > > git pull > git co JVM_BUG > > the problematic loop now looks like this: > > int c0, c1 = 0; > // ... > for (c0 = ALPHABET_SIZE - 2, j = m; 0 < j; --c0) > { > for (c1 = ALPHABET_SIZE - 1; c0 < c1; j = i, --c1) > { > System.err.println("C0: " + c0 + " C1: " + c1); > i = bucket_B[(c0) * ALPHABET_SIZE + (c1)]; > if (1 < (j - i)) > { > ssSort(PAb, i, j, buf, bufsize, 2, n, SA[i] == (m - 1)); > } > } > } > > even not knowing what other elements are, c0 and c1 are local variables that are not modified anywhere inside the loop other than decremented on every loop run (inside and outside). The output is as one would expect, from the start: > > C0: 254 C1: 255 > C0: 253 C1: 255 > C0: 253 C1: 254 > C0: 252 C1: 255 > C0: 252 C1: 254 > C0: 252 C1: 253 > ... > > so both counters are decrement... until this happens (run 1): > > ... > C0: 74 C1: 77 > C0: 74 C1: 76 > C0: 74 C1: 75 > C0: 254 C1: 255 > C0: 254 C1: 255 > [forever] > > And run2, for example: > ... > C0: 68 C1: 70 > C0: 68 C1: 69 > C0: 254 C1: 255 > C0: 254 C1: 255 > C0: 254 C1: 255 > > note that counter values: > > C0: 254 C1: 255 > > are actually what it all started with, but why it'd never decrement again is beyond me. > > The compilation dump shows that nothing special happens before the code falls into an endless loop (I assume stdout writes are sequential when they go via Maven's test plugin, but don't know for sure). > > I also checked with: > > java version "1.7.0-ea" > Java(TM) SE Runtime Environment (build 1.7.0-ea-b104) > Java HotSpot(TM) 64-Bit Server VM (build 19.0-b05, mixed mode) > > and it exhibits the same problem. Sadly, I don't know how to use gdb to hack into a running VM instance to inspect what is actually happening, but if I can be of any further help, let me know. > > Dawid > > On Thu, Mar 3, 2011 at 10:39 PM, Dawid Weiss wrote: > > Inserting the breakpoint would deopt the code and you'll resume in the interpreter so you'll end up avoiding the JITed code which presumably is where the bug is. > > Yep, I realize this is the case, I even mentioned it in my original post. Let me double check that we're not doing something non-deterministic first though... but if you'd like to try then... > > I agree. It sounds like we're screwing up the bounds somehow. Is there a jar file I can grab to run this test easily? > > Mind this is happening infrequently (but on different machines, different OSs, etc.). Here's the procedure: > > git clone git at github.com:carrotsearch/jsuffixarrays.git > cd jsuffixarrays > # while (true)? { > mvn test > # } > > I've just done the above and it hung on the first execution... the next one it didn't, the third one it did again. So maybe it is happening more frequently than less. The JRE I did it on is: > > java version "1.6.0_20" > Java(TM) SE Runtime Environment (build 1.6.0_20-b02) > Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) > > But it applies to newer versions as well. > > The particular class that is causing this is DivSufSort (DivSufSortTest), but I don't know what causes this to happen, so I'd run all of them (these are parallel testng tests). > > I also didn't check with the trunk HotSpot, so it may be something that's already been fixed. > > Dawid > > From vladimir.kozlov at oracle.com Thu Mar 3 18:23:10 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Mar 2011 18:23:10 -0800 Subject: Request for review(M): 7020403: Add AdvancedCompilationPolicy for tiered In-Reply-To: <4D7045A0.3090908@oracle.com> References: <4D7045A0.3090908@oracle.com> Message-ID: <4D704D0E.80602@oracle.com> Good. Vladimir Igor Veresov wrote: > This implements adaptive tiered compilation policy. > > Webrev: http://cr.openjdk.java.net/~iveresov/7020403/webrev.00/ > > Thanks, > igor From john.coomes at oracle.com Thu Mar 3 20:39:14 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Mar 2011 04:39:14 +0000 Subject: hg: jdk7/hotspot-comp: 13 new changesets Message-ID: <20110304043915.25D0C47C5F@hg.openjdk.java.net> Changeset: 995077c73fbb Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/995077c73fbb Added tag jdk7-b130 for changeset cc58c11af154 ! .hgtags Changeset: 0fd0aeb592cb Author: jqzuo Date: 2010-12-09 10:58 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/0fd0aeb592cb Merge Changeset: 20955959b7b7 Author: jqzuo Date: 2010-12-22 15:55 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/20955959b7b7 Merge Changeset: 08fe18caf411 Author: jqzuo Date: 2011-01-10 13:45 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/08fe18caf411 Merge Changeset: aee1b0183364 Author: jqzuo Date: 2011-01-24 17:14 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/aee1b0183364 Merge Changeset: 12764a5a3aec Author: jqzuo Date: 2011-02-01 15:03 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/12764a5a3aec Merge Changeset: df3abd560cbd Author: jqzuo Date: 2011-02-09 16:05 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/df3abd560cbd Merge Changeset: e2370dfcc721 Author: paulk Date: 2011-02-14 14:29 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/e2370dfcc721 7019371: JDK7 is not building UPX. IFTW wrappers are not compressed. Reviewed-by: billyh, jqzuo ! make/deploy-rules.gmk Changeset: 5466f13d19be Author: jqzuo Date: 2011-02-21 14:18 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/5466f13d19be Merge Changeset: da55264ff2fb Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/da55264ff2fb 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 5d86d951426a Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/5d86d951426a Merge Changeset: 0f62a65fb666 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/0f62a65fb666 Added tag jdk7-b131 for changeset 5d86d951426a ! .hgtags Changeset: b1fafacc3040 Author: katleman Date: 2011-03-03 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/b1fafacc3040 Added tag jdk7-b132 for changeset 0f62a65fb666 ! .hgtags From john.coomes at oracle.com Thu Mar 3 20:39:23 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Mar 2011 04:39:23 +0000 Subject: hg: jdk7/hotspot-comp/corba: 9 new changesets Message-ID: <20110304043931.A871147C60@hg.openjdk.java.net> Changeset: 30ecf5c90a30 Author: mfang Date: 2011-02-10 11:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/30ecf5c90a30 7014477: pt_BR corba resource bundle is missing in jdk7 build Reviewed-by: ohair ! make/common/Defs.gmk Changeset: c08dff674e53 Author: mfang Date: 2011-02-10 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/c08dff674e53 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties Changeset: e0f0b358cd2c Author: mfang Date: 2011-02-11 22:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/e0f0b358cd2c Merge Changeset: 563a8f8b5be3 Author: mfang Date: 2011-02-11 23:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/563a8f8b5be3 Merge Changeset: 49a96611c870 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/49a96611c870 Added tag jdk7-b130 for changeset 563a8f8b5be3 ! .hgtags Changeset: a9335b646c1c Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/a9335b646c1c 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 9d6dd2cdfcb9 Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/9d6dd2cdfcb9 Merge Changeset: 1b1e75e8f476 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/1b1e75e8f476 Added tag jdk7-b131 for changeset 9d6dd2cdfcb9 ! .hgtags Changeset: 671fe2e623ff Author: katleman Date: 2011-03-03 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/671fe2e623ff Added tag jdk7-b132 for changeset 1b1e75e8f476 ! .hgtags From john.coomes at oracle.com Thu Mar 3 20:39:40 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Mar 2011 04:39:40 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 5 new changesets Message-ID: <20110304043940.E002447C61@hg.openjdk.java.net> Changeset: f2ad604323c0 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/f2ad604323c0 Added tag jdk7-b130 for changeset ab107c1bc4b9 ! .hgtags Changeset: a57220f22751 Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/a57220f22751 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: eab6f27131e4 Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/eab6f27131e4 Merge Changeset: abe04c59a556 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/abe04c59a556 Added tag jdk7-b131 for changeset eab6f27131e4 ! .hgtags Changeset: 8e1148c7911b Author: katleman Date: 2011-03-03 14:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/8e1148c7911b Added tag jdk7-b132 for changeset abe04c59a556 ! .hgtags From john.coomes at oracle.com Thu Mar 3 20:39:50 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Mar 2011 04:39:50 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 5 new changesets Message-ID: <20110304043950.6251747C62@hg.openjdk.java.net> Changeset: a8ffd75ad5df Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/a8ffd75ad5df Added tag jdk7-b130 for changeset ba1fac1c2083 ! .hgtags Changeset: 9e3904866cab Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/9e3904866cab 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 438abc0356cd Author: cl Date: 2011-02-23 15:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/438abc0356cd Merge Changeset: 0e57c3272d37 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/0e57c3272d37 Added tag jdk7-b131 for changeset 438abc0356cd ! .hgtags Changeset: 359d0c8c00a0 Author: katleman Date: 2011-03-03 14:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/359d0c8c00a0 Added tag jdk7-b132 for changeset 0e57c3272d37 ! .hgtags From tom.rodriguez at oracle.com Thu Mar 3 21:33:04 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 3 Mar 2011 21:33:04 -0800 Subject: Request for review(M): 7020403: Add AdvancedCompilationPolicy for tiered In-Reply-To: <4D7045A0.3090908@oracle.com> References: <4D7045A0.3090908@oracle.com> Message-ID: <9A5F9CFB-2988-4688-969E-C98E32B67641@oracle.com> Looks good. tom On Mar 3, 2011, at 5:51 PM, Igor Veresov wrote: > This implements adaptive tiered compilation policy. > > Webrev: http://cr.openjdk.java.net/~iveresov/7020403/webrev.00/ > > Thanks, > igor From john.coomes at oracle.com Thu Mar 3 20:46:58 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Mar 2011 04:46:58 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 149 new changesets Message-ID: <20110304051253.BC08947C6E@hg.openjdk.java.net> Changeset: bad0ddc6f573 Author: prr Date: 2011-01-26 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bad0ddc6f573 7014738: Update jdk repo application manifests with Windows 7 compatibility section. Reviewed-by: bae, igor ! src/windows/resource/java.manifest Changeset: d0e158473b6f Author: prr Date: 2011-01-26 13:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d0e158473b6f 6940890: Java doesn't pick up the correct fontconfig files in latest Solaris Next builds Reviewed-by: bae, igor ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java Changeset: 4cf20706dbfa Author: dlila Date: 2011-01-27 16:43 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4cf20706dbfa 4645692: solveCubic does not return all solutions. Summary: more robust solveCubic implementation. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java + test/java/awt/geom/CubicCurve2D/ContainsTest.java + test/java/awt/geom/CubicCurve2D/IntersectsTest.java + test/java/awt/geom/CubicCurve2D/SolveCubicTest.java Changeset: 21621a756b32 Author: lana Date: 2011-02-03 19:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/21621a756b32 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 5e624003e622 Author: dlila Date: 2011-02-08 09:22 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5e624003e622 7016856: dashing performance was reduced during latest changes to the OpenJDK rasterizer Summary: Optimized dashing, rasterizing, and the flow of transformed coordinates Reviewed-by: flar ! src/share/classes/sun/java2d/pisces/Curve.java ! src/share/classes/sun/java2d/pisces/Dasher.java ! src/share/classes/sun/java2d/pisces/Helpers.java ! src/share/classes/sun/java2d/pisces/PiscesCache.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java ! src/share/classes/sun/java2d/pisces/Renderer.java ! src/share/classes/sun/java2d/pisces/Stroker.java ! src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java Changeset: 577c5d930e44 Author: dav Date: 2011-01-25 15:33 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/577c5d930e44 6693961: cross-window focus transfer ability in the Focus Spec should be revised Reviewed-by: ant, art ! src/share/classes/java/awt/doc-files/FocusSpec.html Changeset: 5f3615691623 Author: dav Date: 2011-01-25 19:07 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5f3615691623 6431076: Cursor gets reset to text cursor in xawt TextArea when autoscrolling on append Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test.java + test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test1.java Changeset: 6fd2d28e66cd Author: denis Date: 2011-01-28 16:52 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6fd2d28e66cd 6340263: Regression testcase java/awt/dnd/DnDClipboardDeadlockTest throughs IOException: Owner timed out Reviewed-by: anthony, art ! src/solaris/classes/sun/awt/X11/XSelection.java Changeset: 9da15efec22b Author: andrew Date: 2011-02-01 17:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9da15efec22b 7015232: missing copyright header in CheckZOrderChange.java Summary: Add standard GPL header as on other tests Reviewed-by: anthony ! test/java/awt/Container/CheckZOrderChange/CheckZOrderChange.java Changeset: 3244848a4a2b Author: dav Date: 2011-02-04 17:32 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3244848a4a2b 6741526: KeyboardFocusManager.setDefaultFocusTraversalPolicy(FocusTraversalPolicy) affects created components Reviewed-by: ant, dcherepanov ! src/share/classes/java/awt/Window.java + test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_AWT.java + test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java Changeset: b5fc02e1a944 Author: lana Date: 2011-02-08 14:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b5fc02e1a944 Merge Changeset: 69fac04eda38 Author: rupashka Date: 2011-01-27 14:23 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/69fac04eda38 6902615: Method JTextComponent.getKeyStrokesForAction() throws StackOverflowError Reviewed-by: peterz ! src/share/classes/javax/swing/text/Keymap.java Changeset: ec066e903b84 Author: rupashka Date: 2011-01-27 14:33 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ec066e903b84 6935155: @since tag is missing in JTextComponent.save/restoreComposedText Reviewed-by: alexp ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 457f6b2cc155 Author: malenkov Date: 2011-01-31 21:22 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/457f6b2cc155 7001484: DOC: Method javax.swing.border.StrokeBorder.getBorderInsets() should specify how it converts float Reviewed-by: alexp ! src/share/classes/javax/swing/border/StrokeBorder.java Changeset: 020b4695370c Author: malenkov Date: 2011-01-31 21:31 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/020b4695370c 7001118: DOC: javax.swing.border.StrokeBorder.paintBorder() doesn't throw NPE in all specified cases Reviewed-by: alexp ! src/share/classes/javax/swing/border/StrokeBorder.java Changeset: 07bea0d4e454 Author: malenkov Date: 2011-01-31 21:49 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/07bea0d4e454 6999045: DOC: Unclear spec for BevelBorder constructor and BorderFactory factory method (colors switching) Reviewed-by: alexp ! src/share/classes/javax/swing/BorderFactory.java ! src/share/classes/javax/swing/border/BevelBorder.java Changeset: cbcd461067c5 Author: rupashka Date: 2011-02-02 18:37 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cbcd461067c5 6988168: Press the "Toggle Font" button.The size of the combo box didn't change. Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java Changeset: 6c4b6780ab20 Author: rupashka Date: 2011-02-02 18:41 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6c4b6780ab20 6988176: There is focus painted inside the button. Reviewed-by: alexp ! src/share/classes/sun/swing/WindowsPlacesBar.java Changeset: 057e9b837105 Author: rupashka Date: 2011-02-03 16:30 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/057e9b837105 7013453: BufferStrategyPaintManager.dispose will cause IllegalMonitorStateException in event thread Reviewed-by: alexp ! src/share/classes/javax/swing/BufferStrategyPaintManager.java + test/javax/swing/RepaintManager/7013453/bug7013453.java Changeset: 0fae79ec7248 Author: naoto Date: 2011-02-03 09:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0fae79ec7248 7013282: No appropriate CCC request for listed JDK 7 changes in java.util.spi package (b121) Reviewed-by: peytoia ! src/share/classes/java/util/spi/LocaleNameProvider.java Changeset: c7e368a95c75 Author: alexp Date: 2011-02-07 21:15 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c7e368a95c75 7016942: Revert a refactoring in TooltipManager to allow reflection hack Reviewed-by: rupashka ! src/share/classes/javax/swing/ToolTipManager.java Changeset: 989f6d3eee0d Author: alexp Date: 2011-02-07 21:34 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/989f6d3eee0d 6979537: closed/javax/swing/JSplitPane/UnitTest/UnitTest.java fails Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java Changeset: 842a0f8c89ea Author: naoto Date: 2011-02-08 09:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/842a0f8c89ea 7015500: Locale.toLanguageTag() uses "und" as lang subtag for private use only Locale Reviewed-by: srl ! src/share/classes/java/util/Locale.java ! src/share/classes/sun/util/locale/LanguageTag.java ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: d002fe0c57c5 Author: lana Date: 2011-02-08 14:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d002fe0c57c5 Merge Changeset: dbfc1e419cb2 Author: darcy Date: 2011-01-24 20:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dbfc1e419cb2 7006578: Project Coin: Retrofit JDK libraries with @SafeVarargs Reviewed-by: mduigou, alexp ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/sun/swing/AccumulativeRunnable.java Changeset: ae38d1374e31 Author: mullan Date: 2011-01-24 14:56 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ae38d1374e31 5001004: Required Security Algorithms need to be defined Reviewed-by: wetmore ! src/share/classes/java/security/AlgorithmParameterGenerator.java ! src/share/classes/java/security/AlgorithmParameters.java ! src/share/classes/java/security/KeyFactory.java ! src/share/classes/java/security/KeyPairGenerator.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/MessageDigest.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/SecureRandom.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/Signature.java ! src/share/classes/java/security/cert/CertPath.java ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertStore.java ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/CertificateFactorySpi.java ! src/share/classes/java/security/cert/package.html ! src/share/classes/java/security/package.html ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/ExemptionMechanism.java ! src/share/classes/javax/crypto/KeyAgreement.java ! src/share/classes/javax/crypto/KeyGenerator.java ! src/share/classes/javax/crypto/Mac.java ! src/share/classes/javax/crypto/SecretKeyFactory.java ! src/share/classes/javax/crypto/package.html ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/net/ssl/package.html ! src/share/classes/javax/security/auth/login/Configuration.java ! src/share/classes/javax/security/auth/login/package.html Changeset: b33e9b15835e Author: mullan Date: 2011-01-24 15:08 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b33e9b15835e Merge - make/common/internal/BinaryPlugs.gmk - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/classes/java/dyn/JavaMethodHandle.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java ! src/share/classes/java/security/Security.java ! src/share/classes/javax/net/ssl/SSLContext.java - src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/net/httpserver/SelectorCache.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java - test/sun/security/krb5/auto/basic.sh Changeset: 6ac9383640c6 Author: mullan Date: 2011-01-24 15:46 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6ac9383640c6 Merge Changeset: 6e7bed89ce84 Author: mullan Date: 2011-01-25 08:41 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6e7bed89ce84 Merge Changeset: bf1b937076db Author: alanb Date: 2011-01-26 18:01 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bf1b937076db 7012663: javadoc warning in javax.swing.JComponent and javax.swing.plaf.synth.SynthTextPaneUI Reviewed-by: alexp ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java Changeset: abab55565eda Author: darcy Date: 2011-01-26 12:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/abab55565eda 7013420: Project Coin: remove general expression support from try-with-resources statement Reviewed-by: alanb ! test/java/nio/channels/FileChannel/Truncate.java Changeset: 236e3f2d0a6b Author: alanb Date: 2011-01-28 09:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/236e3f2d0a6b 7006126: (fs) Updates to file system API (1/2011) Reviewed-by: chegar, sherman ! make/java/java/FILES_java.gmk ! make/java/nio/FILES_java.gmk ! make/mkdemo/Makefile ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/SerialCallbackContext.java - src/share/classes/java/io/TempFileHelper.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/SeekableByteChannel.java ! src/share/classes/java/nio/file/AccessMode.java + src/share/classes/java/nio/file/CopyMoveHelper.java ! src/share/classes/java/nio/file/CopyOption.java ! src/share/classes/java/nio/file/DirectoryStream.java - src/share/classes/java/nio/file/FileRef.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileSystems.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/FileVisitor.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/LinkOption.java ! src/share/classes/java/nio/file/LinkPermission.java ! src/share/classes/java/nio/file/OpenOption.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/PathMatcher.java ! src/share/classes/java/nio/file/Paths.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java + src/share/classes/java/nio/file/TempFileHelper.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchKey.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/attribute/AclEntry.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java - src/share/classes/java/nio/file/attribute/Attributes.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/DosFileAttributes.java ! src/share/classes/java/nio/file/attribute/FileAttribute.java ! src/share/classes/java/nio/file/attribute/FileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributes.java ! src/share/classes/java/nio/file/attribute/PosixFilePermission.java ! src/share/classes/java/nio/file/attribute/PosixFilePermissions.java ! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java ! src/share/classes/java/nio/file/attribute/package-info.java ! src/share/classes/java/nio/file/package-info.java ! src/share/classes/java/nio/file/spi/FileSystemProvider.java ! src/share/classes/java/nio/file/spi/FileTypeDetector.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/sun/nio/fs/AbstractAclFileAttributeView.java ! src/share/classes/sun/nio/fs/AbstractBasicFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractFileSystemProvider.java ! src/share/classes/sun/nio/fs/AbstractFileTypeDetector.java ! src/share/classes/sun/nio/fs/AbstractPath.java ! src/share/classes/sun/nio/fs/AbstractPoller.java ! src/share/classes/sun/nio/fs/AbstractUserDefinedFileAttributeView.java ! src/share/classes/sun/nio/fs/AbstractWatchKey.java ! src/share/classes/sun/nio/fs/AbstractWatchService.java ! src/share/classes/sun/nio/fs/DynamicFileAttributeView.java ! src/share/classes/sun/nio/fs/FileOwnerAttributeViewImpl.java ! src/share/classes/sun/nio/fs/PollingWatchService.java ! src/share/classes/sun/security/provider/SeedGenerator.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/sample/nio/file/AclEdit.java ! src/share/sample/nio/file/Chmod.java ! src/share/sample/nio/file/Copy.java ! src/share/sample/nio/file/DiskUsage.java ! src/share/sample/nio/file/FileType.java ! src/share/sample/nio/file/WatchDir.java ! src/share/sample/nio/file/Xdd.java ! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixCopyFile.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java ! src/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java ! src/windows/classes/sun/nio/fs/WindowsFileCopy.java ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/classes/sun/nio/fs/WindowsPathParser.java ! src/windows/classes/sun/nio/fs/WindowsSecurityDescriptor.java ! src/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java ! src/windows/classes/sun/nio/fs/WindowsWatchService.java ! test/demo/zipfs/basic.sh ! test/java/io/File/IsHidden.java ! test/java/io/File/SetAccess.java ! test/java/io/File/SymLinks.java ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/nio/channels/FileChannel/AtomicAppend.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/file/DirectoryStream/Basic.java ! test/java/nio/file/DirectoryStream/DriveLetter.java ! test/java/nio/file/DirectoryStream/SecureDS.java ! test/java/nio/file/FileStore/Basic.java + test/java/nio/file/Files/BytesAndLines.java + test/java/nio/file/Files/CheckPermissions.java - test/java/nio/file/Files/ContentType.java + test/java/nio/file/Files/CopyAndMove.java - test/java/nio/file/Files/CreateFileTree.java + test/java/nio/file/Files/DeleteOnClose.java + test/java/nio/file/Files/FileAttributes.java - test/java/nio/file/Files/ForceLoad.java + test/java/nio/file/Files/InterruptCopy.java + test/java/nio/file/Files/Links.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java ! test/java/nio/file/Files/Misc.java + test/java/nio/file/Files/PassThroughFileSystem.java - test/java/nio/file/Files/PrintFileTree.java + test/java/nio/file/Files/SBC.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java + test/java/nio/file/Files/TemporaryFiles.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java + test/java/nio/file/Files/delete_on_close.sh - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy + test/java/nio/file/Files/probeContentType/Basic.java + test/java/nio/file/Files/probeContentType/ForceLoad.java + test/java/nio/file/Files/probeContentType/META-INF/services/java.nio.file.spi.FileTypeDetector + test/java/nio/file/Files/probeContentType/SimpleFileTypeDetector.java + test/java/nio/file/Files/walkFileTree/CreateFileTree.java + test/java/nio/file/Files/walkFileTree/MaxDepth.java + test/java/nio/file/Files/walkFileTree/Nulls.java + test/java/nio/file/Files/walkFileTree/PrintFileTree.java + test/java/nio/file/Files/walkFileTree/SkipSiblings.java + test/java/nio/file/Files/walkFileTree/TerminateWalk.java + test/java/nio/file/Files/walkFileTree/WalkWithSecurity.java + test/java/nio/file/Files/walkFileTree/denyAll.policy + test/java/nio/file/Files/walkFileTree/grantAll.policy + test/java/nio/file/Files/walkFileTree/grantTopOnly.policy + test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java ! test/java/nio/file/Path/Misc.java - test/java/nio/file/Path/PassThroughFileSystem.java ! test/java/nio/file/Path/PathOps.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh ! test/java/nio/file/TestUtil.java ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/FileTreeModifier.java ! test/java/nio/file/WatchService/LotsOfEvents.java ! test/java/nio/file/WatchService/SensitivityModifier.java ! test/java/nio/file/attribute/AclFileAttributeView/Basic.java ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java ! test/java/nio/file/attribute/DosFileAttributeView/Basic.java - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java ! test/java/nio/file/attribute/FileTime/Basic.java ! test/java/nio/file/attribute/PosixFileAttributeView/Basic.java ! test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java ! test/java/nio/file/spi/SetDefaultProvider.java ! test/java/nio/file/spi/TestProvider.java Changeset: 60d347deb54d Author: alanb Date: 2011-01-28 09:31 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/60d347deb54d Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java ! test/demo/zipfs/basic.sh - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: dea360853f8b Author: alanb Date: 2011-01-28 13:26 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dea360853f8b 7015410: test/java/net/Socks/SocksProxyVersion.java needs to be updated due to 7013420 Reviewed-by: chegar ! test/java/net/Socks/SocksProxyVersion.java Changeset: d21a1ce074a7 Author: darcy Date: 2011-01-28 17:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d21a1ce074a7 7015156: Remove JSR 308 changes from core libraries Reviewed-by: mduigou ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/annotation/ElementType.java Changeset: f110edeb4428 Author: darcy Date: 2011-02-01 00:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f110edeb4428 7015827: Fix HTML validation issues in java.math package Reviewed-by: mduigou ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/RoundingMode.java Changeset: d4bc38aa7594 Author: xuelei Date: 2011-02-01 04:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d4bc38aa7594 7011497: new CertPathValidatorException.BasicReason enum constant for constrained algorithm Summary: add new BasicReason and improve trust anchor searching method during cert path validation Reviewed-by: mullan ! src/share/classes/java/security/cert/CertPathValidatorException.java + src/share/classes/sun/security/provider/certpath/AdaptableX509CertSelector.java ! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java Changeset: 21d7cd823247 Author: sundar Date: 2011-02-01 21:00 +0530 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/21d7cd823247 7015908: 3 javax.script tests fail with openjdk build Reviewed-by: alanb ! test/javax/script/CauseExceptionTest.java ! test/javax/script/StringWriterPrintTest.java ! test/javax/script/UnescapedBracketRegExTest.java Changeset: 312dc0abb960 Author: sherman Date: 2011-02-01 14:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/312dc0abb960 7015391: (zipfs) Update zip provider for 1/2011 changes 7014948: (zipfs) ZipFileSystem.newFileSystem(Path...) should not throw FileSystemAlreadyExistsException 7015139: (zipfs) ZipPath.delete() should throw DirectoryNotEmptyException when handling "real, non-empty" dir Summary: zip filesystem provider update Reviewed-by: alanb ! make/mkdemo/Makefile ! src/share/demo/nio/zipfs/Demo.java ! src/share/demo/nio/zipfs/README.txt ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributeView.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java - src/share/demo/zipfs ! test/demo/zipfs/Basic.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 25462d7eee24 Author: briangoetz Date: 2011-02-02 13:13 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/25462d7eee24 7012540: java.util.Objects.nonNull() incorrectly named Reviewed-by: darcy, weijun ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/lang/StackTraceElement.java ! src/share/classes/java/nio/file/DirectoryIteratorException.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Objects.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! test/java/util/Objects/BasicObjectsTest.java Changeset: 3c86f24f7500 Author: chegar Date: 2011-02-03 10:10 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3c86f24f7500 7008595: Class loader leak caused by keepAliveTimer thread in KeepAliveCache Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java Changeset: dff9b6d18628 Author: coffeys Date: 2011-02-03 11:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dff9b6d18628 7016897: Copyright header correction : test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java Reviewed-by: vinnie ! test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java Changeset: 0f5dc2fc81b1 Author: chegar Date: 2011-02-03 11:56 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0f5dc2fc81b1 6887710: Jar index should avoid putting META-INF in the INDEX.LIST Reviewed-by: michaelm ! src/share/classes/sun/misc/JarIndex.java + test/sun/misc/JarIndex/metaInfFilenames/Basic.java + test/sun/misc/JarIndex/metaInfFilenames/jarA/META-INF/services/my.happy.land + test/sun/misc/JarIndex/metaInfFilenames/jarA/a/A.java + test/sun/misc/JarIndex/metaInfFilenames/jarA/com/message/spi/MessageService.java + test/sun/misc/JarIndex/metaInfFilenames/jarB/META-INF/JAVA2.DS + test/sun/misc/JarIndex/metaInfFilenames/jarB/META-INF/services/no.name.service + test/sun/misc/JarIndex/metaInfFilenames/jarB/b/B.java + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/fonts.mf + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/fonts/Company-corporate.ttf + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/fonts/kidpr.ttf + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/services/com.message.spi.MessageService + test/sun/misc/JarIndex/metaInfFilenames/jarC/my/impl/StandardMessageService.java Changeset: 68e3eba12afe Author: michaelm Date: 2011-02-03 12:57 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/68e3eba12afe 6751021: TEST_BUG: race condition in the test java/lang/Runtime/exec/Duped.java Reviewed-by: alanb ! test/java/lang/Runtime/exec/Duped.java Changeset: e2a182adb30f Author: alanb Date: 2011-02-03 13:37 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e2a182adb30f 7014794: (file) lookupPrincipalByGroupName fails to find large NIS groups Reviewed-by: chegar ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c Changeset: 515512634eb4 Author: vinnie Date: 2011-02-03 19:09 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/515512634eb4 6997561: A request for better error handling in JNDI Reviewed-by: robm ! src/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java + test/com/sun/jndi/ldap/LdapName/EmptyNameSearch.java Changeset: 035ecca4379c Author: sherman Date: 2011-02-03 13:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/035ecca4379c 7014645: Support perl style Unicode hex notation \x{...} Summary: Added the construct \x{...} for Unicode hex notation support Reviewed-by: alanb, okutsu ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: 3c1eca364cc7 Author: ksrini Date: 2011-02-03 15:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3c1eca364cc7 6968053: (launcher) hide exceptions under certain launcher failures Reviewed-by: mchung ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/misc/VM.java ! test/tools/launcher/Arrrghs.java Changeset: 1b5c838b8db8 Author: vinnie Date: 2011-02-04 00:33 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1b5c838b8db8 6989705: ECC security code native code compiler warnings Reviewed-by: alanb, ohair ! src/share/native/sun/security/ec/ECC_JNI.cpp ! 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: fed61c2f4d14 Author: vinnie Date: 2011-02-04 00:33 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fed61c2f4d14 Merge Changeset: 78fe1b7a9a1a Author: vinnie Date: 2011-02-04 09:52 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/78fe1b7a9a1a 7017176: Several JNDI tests are mssing GPL header Reviewed-by: alanb ! test/com/sun/jndi/ldap/LdapName/Case.java ! test/com/sun/jndi/ldap/LdapName/EmptyNameSearch.java ! test/com/sun/jndi/ldap/LdapName/UnescapeTest.java ! test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 9599534b1727 Author: lancea Date: 2011-02-04 09:07 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9599534b1727 7014095: Broken link in java.sql package specification Reviewed-by: alanb ! src/share/classes/java/sql/package.html Changeset: c5f953e920c6 Author: mduigou Date: 2011-02-04 12:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c5f953e920c6 7015783: Update JDK Netbeans projects to -source 1.7 Reviewed-by: darcy ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent Changeset: b8662dac7c91 Author: sherman Date: 2011-02-04 13:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b8662dac7c91 7005986: (zipfs) ZipPath.startsWith() fails because of the implementation of getName(index) Summary: Updated starsWith/endsWith to be consistent with default file system Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/basic.sh Changeset: a775b8d3fed0 Author: lana Date: 2011-02-04 17:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a775b8d3fed0 Merge - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties Changeset: b0bd638036bd Author: vinnie Date: 2011-02-07 09:11 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b0bd638036bd 7017486: Need synchronized access when flushing the LDAP request queue Reviewed-by: alanb ! src/share/classes/com/sun/jndi/ldap/Connection.java Changeset: f34dcfeecc8d Author: alanb Date: 2011-02-07 13:53 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f34dcfeecc8d 7012823: TEST_BUG: java/nio/MappedByteBuffer tests leave file mappingsthat prevent clean-up (win) Reviewed-by: forax ! test/java/nio/MappedByteBuffer/Force.java ! test/java/nio/MappedByteBuffer/ZeroMap.java Changeset: 32f1c5f67aae Author: alanb Date: 2011-02-07 13:55 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/32f1c5f67aae 7003155: (fs) Paths.get() does not handle escaped octets correctly Reviewed-by: sherman ! src/solaris/classes/sun/nio/fs/UnixUriUtils.java ! test/java/nio/file/Path/UriImportExport.java Changeset: 94bcd9aa2119 Author: chegar Date: 2011-02-07 14:08 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/94bcd9aa2119 7016898: PlainSocketImpl.fd is null on Windows Reviewed-by: alanb ! src/windows/classes/java/net/PlainSocketImpl.java Changeset: f9f321a7502c Author: alanb Date: 2011-02-07 18:01 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f9f321a7502c 7017454: Residual warnings in sun/nio/** and java/io native code (win64) Reviewed-by: chegar ! src/share/native/java/io/io_util.c ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/canonicalize_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/sun/nio/ch/Iocp.c ! src/windows/native/sun/nio/fs/RegistryFileTypeDetector.c ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c Changeset: 08e1914d5852 Author: alanb Date: 2011-02-07 18:02 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/08e1914d5852 Merge Changeset: 947ce00ed7a2 Author: alanb Date: 2011-02-08 15:50 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/947ce00ed7a2 7013585: Dual-pivot quicksort improvements for highly structured (nearly sorted) and data with small periods Reviewed-by: mduigou, alanb Contributed-by: vladimir.yaroslavskiy at oracle.com ! src/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/Sorting.java Changeset: 82c8c54ac1d5 Author: alanb Date: 2011-02-08 19:31 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/82c8c54ac1d5 4421494: infinite loop while parsing double literal Reviewed-by: darcy, alanb Contributed-by: dmitry.nadezhin at oracle.com ! src/share/classes/sun/misc/FloatingDecimal.java ! test/java/lang/Double/ParseDouble.java Changeset: 6661a1dfa369 Author: sherman Date: 2011-02-08 13:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6661a1dfa369 7017840: (zipfs) test/demo/zipfs/basic.sh needs to be updated due to 7013420 Summary: updated try-with-resourcse usage in test/demo code Reviewed-by: alanb ! src/share/demo/nio/zipfs/Demo.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 1899523d8f24 Author: lana Date: 2011-02-08 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1899523d8f24 Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: cd9a302f2806 Author: chegar Date: 2011-02-09 09:53 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cd9a302f2806 7013961: Threads attached via JNI attach prevent daemon ThreadGroups from being destroyed Reviewed-by: dholmes ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java Changeset: 6a274c4d3e00 Author: alanb Date: 2011-02-09 15:59 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6a274c4d3e00 7018258: Dual-pivot updates in 7013585 can fail with ArrayIndexOutOfBoundsException Reviewed-by: alanb Contributed-by: vladimir.yaroslavskiy at oracle.com ! src/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/Sorting.java Changeset: 37563c09305d Author: alanb Date: 2011-02-09 16:30 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/37563c09305d Merge Changeset: a8fcaf5097ec Author: lana Date: 2011-02-09 10:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a8fcaf5097ec Merge Changeset: 9d141e45ee4b Author: lana Date: 2011-02-14 16:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9d141e45ee4b Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: e4802c87e5c7 Author: herrick Date: 2011-02-09 09:19 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e4802c87e5c7 7016724: Remove sun.jkernel.* classes in JDK 7 Summary: Remove sun.jkernel.* classes in JDK 7 Reviewed-by: ohair, alanb, mchung ! make/modules/modules.config ! make/sun/Makefile - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/util/zip/ZipEntry.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java ! src/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java ! src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/tools/attach/HotSpotAttachProvider.java ! src/windows/bin/java_md.c - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc Changeset: dc909d130397 Author: herrick Date: 2011-02-09 09:32 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dc909d130397 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 4f84cda2a7d5 Author: igor Date: 2011-02-09 21:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4f84cda2a7d5 Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc Changeset: 802c085308bf Author: igor Date: 2011-02-15 19:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/802c085308bf Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: 7bb09178ffc7 Author: ohair Date: 2011-02-10 20:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7bb09178ffc7 7012644: Regression: jdk/make/common/shared/Defs-windows.gmk has problems on cygwin 7018835: Debug build issues in jdk makefiles Reviewed-by: ksrini ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Platform.gmk Changeset: 9478964f9425 Author: ohair Date: 2011-02-10 20:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9478964f9425 Merge Changeset: 71b52ce5f389 Author: mfang Date: 2011-02-10 20:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/71b52ce5f389 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ja.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_CN.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_es.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_it.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ja.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ko.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_sv.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ja.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_es.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_it.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_de.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_es.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_it.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties ! src/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_es.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_fr.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_it.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ko.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java ! src/share/classes/sun/awt/resources/awt_de.properties ! src/share/classes/sun/awt/resources/awt_es.properties ! src/share/classes/sun/awt/resources/awt_fr.properties ! src/share/classes/sun/awt/resources/awt_it.properties ! src/share/classes/sun/awt/resources/awt_ja.properties ! src/share/classes/sun/awt/resources/awt_ko.properties ! src/share/classes/sun/awt/resources/awt_pt_BR.properties ! src/share/classes/sun/awt/resources/awt_sv.properties ! src/share/classes/sun/awt/resources/awt_zh_CN.properties ! src/share/classes/sun/awt/resources/awt_zh_TW.properties ! src/share/classes/sun/management/resources/agent_de.properties ! src/share/classes/sun/management/resources/agent_es.properties ! src/share/classes/sun/management/resources/agent_fr.properties ! src/share/classes/sun/management/resources/agent_it.properties ! src/share/classes/sun/management/resources/agent_ja.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/management/resources/agent_pt_BR.properties ! src/share/classes/sun/management/resources/agent_sv.properties ! src/share/classes/sun/management/resources/agent_zh_CN.properties ! src/share/classes/sun/management/resources/agent_zh_TW.properties ! src/share/classes/sun/misc/resources/Messages_de.java ! src/share/classes/sun/misc/resources/Messages_es.java ! src/share/classes/sun/misc/resources/Messages_fr.java ! src/share/classes/sun/misc/resources/Messages_it.java ! src/share/classes/sun/misc/resources/Messages_ja.java ! src/share/classes/sun/misc/resources/Messages_ko.java ! src/share/classes/sun/misc/resources/Messages_pt_BR.java ! src/share/classes/sun/misc/resources/Messages_sv.java ! src/share/classes/sun/misc/resources/Messages_zh_CN.java ! src/share/classes/sun/misc/resources/Messages_zh_TW.java ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_ja.properties ! src/share/classes/sun/print/resources/serviceui_ko.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/share/classes/sun/print/resources/serviceui_zh_TW.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_es.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_fr.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_it.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ja.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ko.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_sv.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_CN.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_TW.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_es.properties ! src/share/classes/sun/rmi/server/resources/rmid_fr.properties ! src/share/classes/sun/rmi/server/resources/rmid_it.properties ! src/share/classes/sun/rmi/server/resources/rmid_ja.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties ! src/share/classes/sun/rmi/server/resources/rmid_sv.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_TW.properties ! src/share/classes/sun/security/tools/JarSignerResources_ja.java ! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_de.java ! src/share/classes/sun/security/util/AuthResources_es.java ! src/share/classes/sun/security/util/AuthResources_fr.java ! src/share/classes/sun/security/util/AuthResources_it.java ! src/share/classes/sun/security/util/AuthResources_ja.java ! src/share/classes/sun/security/util/AuthResources_ko.java ! src/share/classes/sun/security/util/AuthResources_pt_BR.java ! src/share/classes/sun/security/util/AuthResources_sv.java ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_ja.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_zh_CN.java ! src/share/classes/sun/tools/serialver/serialver_ja.properties ! src/share/classes/sun/tools/serialver/serialver_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_de.properties ! src/share/classes/sun/util/logging/resources/logging_es.properties ! src/share/classes/sun/util/logging/resources/logging_fr.properties ! src/share/classes/sun/util/logging/resources/logging_it.properties ! src/share/classes/sun/util/logging/resources/logging_ja.properties ! src/share/classes/sun/util/logging/resources/logging_ko.properties ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/logging/resources/logging_sv.properties ! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties ! src/share/demo/jfc/CodePointIM/resources/codepoint_ja.properties ! src/share/demo/jfc/CodePointIM/resources/codepoint_zh_CN.properties ! src/share/demo/jfc/Font2DTest/resources/TextResources_ja.properties ! src/share/demo/jfc/Font2DTest/resources/TextResources_zh_CN.properties ! src/share/demo/jfc/Notepad/resources/Notepad_ja.properties ! src/share/demo/jfc/Notepad/resources/Notepad_zh_CN.properties ! src/windows/classes/sun/awt/windows/awtLocalization_es.properties ! src/windows/classes/sun/awt/windows/awtLocalization_ja.properties ! src/windows/classes/sun/awt/windows/awtLocalization_ko.properties ! src/windows/classes/sun/awt/windows/awtLocalization_pt_BR.properties ! src/windows/classes/sun/awt/windows/awtLocalization_zh_CN.properties ! src/windows/classes/sun/awt/windows/awtLocalization_zh_TW.properties ! src/windows/native/sun/jkernel/kernel_de.rc ! src/windows/native/sun/jkernel/kernel_es.rc ! src/windows/native/sun/jkernel/kernel_fr.rc ! src/windows/native/sun/jkernel/kernel_it.rc ! src/windows/native/sun/jkernel/kernel_ja.rc ! src/windows/native/sun/jkernel/kernel_ko.rc ! src/windows/native/sun/jkernel/kernel_pt_BR.rc ! src/windows/native/sun/jkernel/kernel_sv.rc ! src/windows/native/sun/jkernel/kernel_zh.rc ! src/windows/native/sun/jkernel/kernel_zh_TW.rc Changeset: 8b6d1d96ef3d Author: mfang Date: 2011-02-11 22:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8b6d1d96ef3d Merge Changeset: 0eacbbc8e1fb Author: mfang Date: 2011-02-11 23:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0eacbbc8e1fb Merge Changeset: 780e53ad2896 Author: mfang Date: 2011-02-14 13:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/780e53ad2896 Merge Changeset: 5fab973e5a47 Author: ohair Date: 2011-02-15 12:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5fab973e5a47 Merge Changeset: bdc069d3f910 Author: ohair Date: 2011-02-15 20:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bdc069d3f910 Merge Changeset: 89055b6d9ae0 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/89055b6d9ae0 Added tag jdk7-b130 for changeset bdc069d3f910 ! .hgtags Changeset: 0355c60c2da4 Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0355c60c2da4 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 9b2631288894 Author: ohair Date: 2011-02-16 14:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9b2631288894 7010594: Add /SAFESEH to links on windows to verify safe exceptions Reviewed-by: alanb ! make/common/Defs-windows.gmk ! make/common/shared/Defs-windows.gmk Changeset: 5e09deee1967 Author: andrew Date: 2011-02-23 17:10 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5e09deee1967 7021314: Build should not install javaws man page Summary: Only install javaws.1 when not building OpenJDK Reviewed-by: alanb, ohair ! make/common/Release.gmk Changeset: 8ac52c85f9e9 Author: cl Date: 2011-02-23 15:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8ac52c85f9e9 Merge Changeset: 11c9a066a5a4 Author: cl Date: 2011-02-24 15:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/11c9a066a5a4 Added tag jdk7-b131 for changeset 8ac52c85f9e9 ! .hgtags Changeset: f6cd84cfed70 Author: trims Date: 2011-02-25 12:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f6cd84cfed70 Merge - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java Changeset: 7905b047a475 Author: prr Date: 2011-02-08 14:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7905b047a475 7006865: Regression: Corrupted output when printing images with bit depth of 4 Reviewed-by: bae, jgodinez ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java + test/java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java Changeset: d42ce0b309ae Author: bae Date: 2011-02-09 22:24 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d42ce0b309ae 6818960: ImageFetcher ( MediaTracker) Thread leak Reviewed-by: igor, prr ! src/share/classes/sun/awt/image/ImageFetcher.java ! src/share/classes/sun/awt/image/InputStreamImageSource.java Changeset: 37d20456c54c Author: ceisserer Date: 2011-02-09 14:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/37d20456c54c 7018387: Xrender pipeline may leak GC's Reviewed-by: prr ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java Changeset: bcf663c292ef Author: bae Date: 2011-02-10 13:44 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bcf663c292ef 6989774: imageio compiler warnings in native code Reviewed-by: igor, prr ! make/sun/jpeg/Makefile ! make/sun/jpeg/reorder-i586 ! make/sun/jpeg/reorder-sparc ! make/sun/jpeg/reorder-sparcv9 ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/image/jpeg/jdmarker.c ! src/share/native/sun/awt/image/jpeg/jmemmgr.c ! src/share/native/sun/awt/image/jpeg/jmemnobs.c ! src/share/native/sun/awt/image/jpeg/jmemsys.h ! src/share/native/sun/awt/image/jpeg/jpegdecoder.c ! src/share/native/sun/awt/image/jpeg/jpeglib.h Changeset: 1881764c4cdf Author: prr Date: 2011-02-11 10:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1881764c4cdf 7018364: XShmGetImage with image's > drawable's size causes BadMatch Reviewed-by: art, anthony Contributed-by: linuxhippy at gmail.com ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.h Changeset: b04dafeda706 Author: prr Date: 2011-02-16 15:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b04dafeda706 7019441: No lookup cache for internal composite font creation leads to java heap growth Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FontUtilities.java Changeset: e45f7d50dbc9 Author: bae Date: 2011-02-17 13:42 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e45f7d50dbc9 7018912: [parfait] potential buffer overruns in imageio jpeg Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: 810445ab3099 Author: prr Date: 2011-02-18 09:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/810445ab3099 6857592: Getting warning while moving or resizing the frame when component.printAll() is called on local JNI Reviewed-by: bae, flar ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp Changeset: 5d8cfcb9a4e8 Author: prr Date: 2011-02-18 09:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5d8cfcb9a4e8 7017637: closed/java/awt/font/StyledMetrics/BoldSpace.java failed : Space char should have 0 advance Reviewed-by: igor, jgodinez + test/java/awt/font/StyledMetrics/BoldSpace.java Changeset: 4c6500d20ebf Author: jgodinez Date: 2011-02-04 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4c6500d20ebf 7014796: Regression test java/awt/PrintJob/Text/stringwidth.sh cannot be terminated on Windows. Reviewed-by: prr ! test/java/awt/PrintJob/Text/StringWidth.java Changeset: 33cd780e8989 Author: jgodinez Date: 2011-02-04 11:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/33cd780e8989 6995147: Case needs to be update. ServiceDialogTest.java failed as compilation error. Reviewed-by: prr ! test/javax/print/attribute/ServiceDialogTest.java Changeset: 1d3f3c8d7ed5 Author: jgodinez Date: 2011-02-18 11:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1d3f3c8d7ed5 6722351: sun.print.Win32PrintService.initMedia() is slow Reviewed-by: igor, prr ! src/windows/classes/sun/print/Win32PrintService.java Changeset: 059b56058cad Author: jgodinez Date: 2011-02-18 12:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/059b56058cad Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 1acdde062e92 Author: jgodinez Date: 2011-02-18 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1acdde062e92 6850806: NPE exception throws in PrintServce.getSupportedAttributeValues Reviewed-by: igor, prr ! src/windows/classes/sun/print/Win32PrintService.java Changeset: fa6547fa57e6 Author: lana Date: 2011-02-21 14:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fa6547fa57e6 Merge Changeset: 5a6bd7df28b8 Author: lana Date: 2011-02-11 15:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5a6bd7df28b8 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 14d9e6af8889 Author: andrew Date: 2011-02-15 15:09 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/14d9e6af8889 7017581: missing copyright header in test/sun/java2d/pipe/RegionOps.java Reviewed-by: anthony ! test/sun/java2d/pipe/RegionOps.java Changeset: 7c98b6b4e8a7 Author: dav Date: 2011-02-16 01:12 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7c98b6b4e8a7 6994933: java.awt.Desktop feature is "intermittently" supported on Solaris. Really unexpected behavior. Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XDesktopPeer.java ! src/solaris/native/sun/xawt/awt_Desktop.c Changeset: 41da8f9ea83a Author: lana Date: 2011-02-21 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/41da8f9ea83a Merge Changeset: eeaad0d340b2 Author: peytoia Date: 2011-02-09 18:00 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eeaad0d340b2 7017800: (tz) Support tzdata2011b Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 493a9eeb9bca Author: alexp Date: 2011-02-10 21:36 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/493a9eeb9bca 6993171: JavaTest/JDK7b114 - no help text is shown for interview questions, JavaTest HANGS UP Reviewed-by: rupashka ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! test/javax/swing/JComponent/6989617/bug6989617.java Changeset: be8045e2d792 Author: lana Date: 2011-02-11 12:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/be8045e2d792 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 82f7b8f6b174 Author: alexp Date: 2011-02-15 16:40 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/82f7b8f6b174 6956842: BasicTreeUI.getPreferredSize(JComp c) is delegated to getPreferredSize(c, true) not (c, false) Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: be44bda15fcf Author: okutsu Date: 2011-02-16 16:51 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/be44bda15fcf 6936350: API clarification needed on useDaylightTime() for timezones that have defined usage dates Reviewed-by: peytoia ! src/share/classes/java/util/SimpleTimeZone.java ! src/share/classes/java/util/TimeZone.java + test/java/util/TimeZone/DaylightTimeTest.java Changeset: f326139e7fda Author: malenkov Date: 2011-02-16 18:32 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f326139e7fda 6980124: closed/javax/swing/plaf/synth/SynthPainter/unitTest/UnitTest.java fails Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java Changeset: 888baed5c55b Author: rupashka Date: 2011-02-18 00:16 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/888baed5c55b 7016693: javax/swing/JScrollBar/6542335/bug6542335.java failed on Ubuntu Reviewed-by: alexp ! test/javax/swing/JScrollBar/6542335/bug6542335.java Changeset: db0a6fd0fea9 Author: amenkov Date: 2011-02-18 13:21 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/db0a6fd0fea9 6801236: test closed/javax/sound/sampled/FileWriter/WaveBigEndian.java fails Reviewed-by: alexp ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.FormatConversionProvider Changeset: 64b4226f171f Author: amenkov Date: 2011-02-18 13:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/64b4226f171f 7000132: Misplaced description in javax.sound.sampled.AudioSystem.getTargetDataLine Reviewed-by: dav ! src/share/classes/javax/sound/sampled/AudioSystem.java Changeset: a93bb05d00fd Author: alexp Date: 2011-02-18 19:21 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a93bb05d00fd 6474153: LookAndFeel.makeKeyBindings(...) doesn't ignore last element in keyBindingList with odd size Reviewed-by: rupashka ! src/share/classes/javax/swing/LookAndFeel.java + test/javax/swing/LookAndFeel/6474153/bug6474153.java Changeset: 3772a3d90b40 Author: rupashka Date: 2011-02-18 20:09 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3772a3d90b40 6997102: Test case has hard code, so that applet thread threw exception Reviewed-by: alexp ! test/javax/swing/JFileChooser/6798062/bug6798062.html ! test/javax/swing/JFileChooser/6798062/bug6798062.java Changeset: 2cc71008b6db Author: lana Date: 2011-02-21 14:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2cc71008b6db Merge ! src/share/classes/javax/swing/JComponent.java Changeset: cfd397d86474 Author: sundar Date: 2011-02-11 10:38 +0530 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cfd397d86474 6604827: JavaDoc for ScriptEngineFactory.getMethodCallSyntax contains an error. Reviewed-by: mchung ! src/share/classes/javax/script/ScriptEngineFactory.java Changeset: 05a0271173a6 Author: ohair Date: 2011-02-10 20:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/05a0271173a6 Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: 1dc0c3021d13 Author: ohair Date: 2011-02-11 01:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1dc0c3021d13 Merge Changeset: 8711aedb08f2 Author: sherman Date: 2011-02-11 12:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8711aedb08f2 7007596: (zipfs) FileSystems.newFileSystem(FileRef...) always employs zipfs regardless the real Path type. Summary: updated newFileSystem() to throw UOE exception for non-zip/jar file Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 8860e17db3bd Author: weijun Date: 2011-02-12 05:09 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8860e17db3bd 6742654: Code insertion/replacement attacks against signed jars 6911041: JCK api/signaturetest tests fails for Mixed Code PIT builds (b91) for all trains 6921823: JarVerifier csdomain field not initialized 6921839: Update trusted.libraries list Reviewed-by: dgu ! make/java/security/Makefile ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/sun/misc/JarIndex.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java Changeset: de923c0ec3c4 Author: weijun Date: 2011-02-12 07:30 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/de923c0ec3c4 7016698: test sun/security/krb5/runNameEquals.sh failed on Ubuntu Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java Changeset: 21a1e86dedc2 Author: sherman Date: 2011-02-11 17:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/21a1e86dedc2 6996192: Console.readPassword race: input echo off must be prior to writing prompt Summary: To turn off echo before prompt Reviewed-by: alanb ! src/share/classes/java/io/Console.java Changeset: b04e86b3e27e Author: dcubed Date: 2011-02-14 09:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b04e86b3e27e 6637230: 2/3 jps doesn't work for application waiting for direct attach Summary: Properly handle exceptions thrown when querying a monitored VM. Reviewed-by: dsamersoff, swamyv ! src/share/classes/sun/tools/jps/Jps.java Changeset: fefc740bff52 Author: alanb Date: 2011-02-14 18:30 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fefc740bff52 7016704: TEST_BUG: java/nio/file/Files/walk_file_tree.sh fails with new version of find (lnx) Reviewed-by: forax ! test/java/nio/file/Files/walkFileTree/PrintFileTree.java Changeset: 28037efa90a3 Author: mduigou Date: 2011-02-14 10:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/28037efa90a3 6934356: Vector.writeObject() serialization may deadlock Summary: No longer synchronize on self while writing other objects. Reviewed-by: alanb, forax, mduigou, peterjones Contributed-by: Neil Richards ! src/share/classes/java/util/Vector.java + test/java/util/Vector/SerializationDeadlock.java + test/java/util/Vector/SimpleSerialization.java Changeset: 2633daa325ed Author: mduigou Date: 2011-02-14 10:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2633daa325ed Merge Changeset: 338c5b815ff2 Author: mduigou Date: 2011-02-14 11:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/338c5b815ff2 6927486: Hashtable writeObject() may deadlock Summary: Do not synchronize on self while writing hash table elements Reviewed-by: alanb, mduigou Contributed-by: Neil Richards ! src/share/classes/java/util/Hashtable.java + test/java/util/Hashtable/SerializationDeadlock.java + test/java/util/Hashtable/SimpleSerialization.java Changeset: 44c99f30f9df Author: xuelei Date: 2011-02-14 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/44c99f30f9df 7018897: CertPath validation cannot handle self-signed cert with bad KeyUsage Summary: Remove KeyUsage checking for trust anchors Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java Changeset: 9024288330c4 Author: weijun Date: 2011-02-15 12:11 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9024288330c4 7018928: test failure: sun/security/krb5/auto/SSL.java Reviewed-by: valeriep ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc3.java ! test/sun/security/krb5/auto/BadKdc4.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/IgnoreChannelBinding.java ! test/sun/security/krb5/auto/KerberosHashEqualsTest.java ! test/sun/security/krb5/auto/LifeTimeInSeconds.java ! test/sun/security/krb5/auto/LoginModuleOptions.java ! test/sun/security/krb5/auto/MaxRetries.java ! test/sun/security/krb5/auto/MoreKvno.java ! test/sun/security/krb5/auto/NewSalt.java ! test/sun/security/krb5/auto/NonMutualSpnego.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/SpnegoReqFlags.java ! test/sun/security/krb5/auto/Test5653.java Changeset: b578c9ccfb01 Author: lana Date: 2011-02-15 08:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b578c9ccfb01 Merge Changeset: afa89f8ab9c8 Author: chegar Date: 2011-02-16 12:38 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/afa89f8ab9c8 6562203: Thread doesn't terminate immediately if it was stopped before start Reviewed-by: dholmes, alanb ! src/share/classes/java/lang/Thread.java - test/java/lang/Thread/StopBeforeStart.java Changeset: dbc74475822f Author: sherman Date: 2011-02-16 11:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dbc74475822f 6999337: java.exe fails to start if some directory names in path to java binaries contain Russian characters Summary: updated to make sure the system properties are accessable by vm during initialization Reviewed-by: alanb, mchung ! src/share/classes/java/lang/System.java Changeset: 6e33b377aa6e Author: smarks Date: 2011-02-16 18:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6e33b377aa6e 7018392: update URLJarFile.java to use try-with-resources Reviewed-by: alanb, chegar, hawtin ! src/share/classes/sun/net/www/protocol/jar/URLJarFile.java Changeset: 15ef6cf616d6 Author: chegar Date: 2011-02-17 09:56 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/15ef6cf616d6 7017901: OOME in java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java Summary: Unbounded queues should be disabled in the test Reviewed-by: alanb ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java Changeset: 302877469037 Author: alanb Date: 2011-02-17 20:50 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/302877469037 6526860: (fc) FileChannel.position returns 0 when FileOutputStream opened in append mode Reviewed-by: forax ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! test/java/nio/channels/FileChannel/Position.java Changeset: a5861eb81f3c Author: alanb Date: 2011-02-17 20:53 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a5861eb81f3c Merge Changeset: dd143033cef1 Author: sundar Date: 2011-02-18 12:07 +0530 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dd143033cef1 7018459: javax.script code comments have issues with HTML4 validation and Accessibility compliance Reviewed-by: jjh ! src/share/classes/javax/script/ScriptEngineFactory.java Changeset: 5bf920749b97 Author: smarks Date: 2011-02-18 12:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5bf920749b97 7018385: update javax.sql classes to use try-with-resources Reviewed-by: alanb, lancea, darcy ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: 42e4205db024 Author: mduigou Date: 2011-02-21 13:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/42e4205db024 7001685: Renable EnumSetBash Test Reviewed-by: alanb, ohair, darcy ! test/ProblemList.txt Changeset: 3ebece41badd Author: lana Date: 2011-02-21 14:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3ebece41badd Merge - test/java/lang/Thread/StopBeforeStart.java Changeset: f046a44e92fd Author: jgodinez Date: 2011-02-24 15:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f046a44e92fd 7022228: JPRT failure: RuntimeException in SupportedMedia regression test Reviewed-by: igor, prr ! src/windows/classes/sun/print/Win32PrintService.java Changeset: 094c70388ab0 Author: lana Date: 2011-02-24 18:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/094c70388ab0 Merge - test/java/lang/Thread/StopBeforeStart.java Changeset: 6bbc7a473495 Author: lana Date: 2011-03-01 14:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6bbc7a473495 Merge - test/java/lang/Thread/StopBeforeStart.java Changeset: b88e4395c437 Author: katleman Date: 2011-03-03 14:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b88e4395c437 Added tag jdk7-b132 for changeset 6bbc7a473495 ! .hgtags From dawid.weiss at gmail.com Thu Mar 3 23:44:14 2011 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Fri, 4 Mar 2011 08:44:14 +0100 Subject: Endless loops in computation code (1.6.0_22). In-Reply-To: <6844B58D-2A2A-4420-A5D9-A71AA4C3332C@oracle.com> References: <7684FD62-77E8-476F-AD2F-479ACC66A79A@oracle.com> <6844B58D-2A2A-4420-A5D9-A71AA4C3332C@oracle.com> Message-ID: > After watching maven download jars for 10 minutes, it actually ran the test > and reproduced it. Ehm, I'm not a big fan of Maven myself, but trying to get used to what people use (and many people do use maven -- perhaps they need those 10 minutes to grab a coffee in the morning, don't know). > I put together a little main to run the test manually and just reproduced > it with -XX:+PrintCompilation. It hung right after it printed this: > > 3% org.jsuffixarrays.DivSufSort::sortTypeBstar @ 979 (1125 bytes) > Ok, so it must be Maven's test plugin messing with the stdout/stderr log order then. I'm glad you could reproduce it. > so it's possible it's a bug with with on stack replacement. I've > reproduced it with the latest 1.7 as well so it's something we haven't seen > before. I filed 7024475 for this and put you on the interest list. I can't > reproduce it in 6u12 but I can in 6u14 so I think it appeared there. > Great, thanks. I fiddled with that code a little bit moving loop counter increments here and there, but it seems to be fairly resilient to where they are (as long as the logic doesn't change). Interestingly, moving the sysout does seem to fix things (if you move it after the if in the inside loop). I appreciate your help, Tom. This is truly fascinating stuff. Dawid -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110304/8cc710f6/attachment.html From mlists at juma.me.uk Fri Mar 4 01:16:11 2011 From: mlists at juma.me.uk (Ismael Juma) Date: Fri, 4 Mar 2011 09:16:11 +0000 (UTC) Subject: ArrayList loop regression ? References: <4D6A9501.9050508@univ-mlv.fr> Message-ID: Hi Remi, R?mi Forax writes: > A student sent me a micro-benchmark that shows a regression in the way > hotspot compiles indexed loop on linux x64. Since this looks like a performance regression, maybe it's worth filing a bug so that it doesn't get lost? Best, Ismael From christian.thalinger at oracle.com Fri Mar 4 01:19:12 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Mar 2011 10:19:12 +0100 Subject: Request for review (L): 6839872: remove implementation inheritance from JSR 292 APIs In-Reply-To: <4D702B2B.3010201@oracle.com> References: <4D702B2B.3010201@oracle.com> Message-ID: <80626E35-A8D0-435F-8902-E2E714B604C1@oracle.com> On Mar 4, 2011, at 12:58 AM, Vladimir Kozlov wrote: > Looks good to me. Thank you, Vladimir. -- Christian > > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/6839872/webrev.01/ >> 6839872: remove implementation inheritance from JSR 292 APIs >> Summary: Move all JSR 292 classes into the java.dyn package. >> Reviewed-by: >> Initial versions (including the preview in 7/M3) of the JSR 292 API >> use an undesirable technique for data structure factoring, >> implementation inheritance. The types MethodHandle and >> JavaMethodHandle both inherit from JVM-internal supertypes. >> The solution is to remove those private supertypes from those public >> types. >> This is the JVM part of 6839872. It adds support to the JVM to handle >> both namespaces, java.dyn/sun.dyn and java.dyn only. >> The support for the old namespace (AllowTransitionalJSR292) will be >> removed as soon as the related JDK changes appear in the >> repositories. From christian.thalinger at oracle.com Fri Mar 4 01:47:15 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Mar 2011 10:47:15 +0100 Subject: Request for review (XL): 7012648: move JSR 292 to package java.lang.invoke and adjust names In-Reply-To: <4D7036EF.8020504@oracle.com> References: <4D7036EF.8020504@oracle.com> Message-ID: On Mar 4, 2011, at 1:48 AM, Vladimir Kozlov wrote: > systemDictionary.hpp: why switching back to sun.dyn?: > > - template(MethodHandleImpl_klass, java_dyn_MethodHandleImpl, Pre_JSR292) /* AllowTransitionalJSR292 ONLY */ \ > + template(MethodHandleImpl_klass, sun_dyn_MethodHandleImpl, Opt) /* AllowTransitionalJSR292 ONLY */ \ That's because MethodHandleImpl goes away with 7012648 and we just use sun_dyn_MethodHandleImpl. It doesn't matter what name it has, both packages (sun.dyn and java.dyn) are searched anyway. > > > methodHandleWalk.cpp: comment says "java.dyn" but should it be "java.lang.invoke"? : > > + if (m == NULL) > + // sun.dyn.MethodHandleImpl not found, look for java.dyn.MethodHandleNatives: > + m = vmIntrinsics::method_for(vmIntrinsics::_checkSpreadArgument_TRANS2); No, that's correct. checkSpreadArgument will be moved to java.dyn.MethodHandleNatives with 6839872 and finally to java.lang.invoke.MethodHandleNatives with 7012648. I know it's confusing but all this will go away, eventually. -- Christian > > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7012648/webrev.01/ >> 7012648: move JSR 292 to package java.lang.invoke and adjust names >> Summary: package and class renaming only; delete unused methods and classes >> Reviewed-by: >> At the request of the JDK7 Architect, the JSR 292 EG has agreed moving >> the API from the package java.dyn to the package java.lang.invoke. >> This is the JVM part of 7012648. >> The support for the old namespace (AllowTransitionalJSR292) will be >> removed as soon as the related JDK changes appear in the >> repositories. From vladimir.kozlov at oracle.com Fri Mar 4 05:28:24 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 04 Mar 2011 13:28:24 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 27 new changesets Message-ID: <20110304132915.0D5F247CC1@hg.openjdk.java.net> Changeset: 162b62460264 Author: dholmes Date: 2011-02-24 21:38 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/162b62460264 7021953: Remove flags from globals.hpp inadvertently dragged in by 7016023 Summary: removed erroneous flags Reviewed-by: kvn, dcubed ! src/share/vm/runtime/globals.hpp Changeset: cf16c93393f5 Author: rottenha Date: 2011-02-25 03:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cf16c93393f5 Merge ! src/share/vm/runtime/globals.hpp Changeset: 02f78cfa4656 Author: stefank Date: 2011-02-21 11:26 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/02f78cfa4656 7020992: jmm_DumpThreads should not allocate system object arrays outside the perm gen Summary: Allocate ordinary object arrays Reviewed-by: ysr, never, mchung ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/services/management.cpp Changeset: 8bbefb9743ae Author: tonyp Date: 2011-02-25 10:58 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8bbefb9743ae Merge Changeset: 76b97f73ee91 Author: tonyp Date: 2011-02-25 08:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/76b97f73ee91 Merge Changeset: 0a2ecf4cc384 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0a2ecf4cc384 Added tag jdk7-b130 for changeset e9aa2ca89ad6 ! .hgtags Changeset: cdef89d821bd Author: ohair Date: 2011-02-16 13:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cdef89d821bd 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 0aa3b4908911 Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0aa3b4908911 Merge Changeset: 2015d9b41531 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2015d9b41531 Added tag jdk7-b131 for changeset 0aa3b4908911 ! .hgtags Changeset: f3e07ceeaed9 Author: trims Date: 2011-02-25 11:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f3e07ceeaed9 Added tag hs21-b02 for changeset e9aa2ca89ad6 ! .hgtags Changeset: 5a4223160326 Author: trims Date: 2011-02-25 12:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5a4223160326 Merge - make/windows/platform_amd64 - make/windows/platform_i486 - make/windows/platform_ia64 - src/share/tools/ProjectCreator/Macro.java - src/share/tools/ProjectCreator/MacroDefinitions.java Changeset: 658d198b2e04 Author: trims Date: 2011-02-25 12:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/658d198b2e04 7022570: Bump the HS21 build number to 03 Summary: Update the HS21 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 7dc5384467e0 Author: coleenp Date: 2011-02-12 10:28 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7dc5384467e0 7022659: errorHandler doesn't compile without precompiled headers Summary: add proper includes in errorHandler.hpp Reviewed-by: phh, kamg ! src/share/vm/utilities/errorReporter.hpp Changeset: 0e531ab5ba04 Author: trims Date: 2011-03-01 11:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0e531ab5ba04 Merge Changeset: f91db74a6810 Author: kamg Date: 2011-02-26 13:33 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f91db74a6810 7017640: Fix for 6766644 deadlocks on some NSK tests when running with -Xcomp Summary: Dynamic-code generated events should be deferred and processed by service thread Reviewed-by: dsamersoff, dcubed ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp Changeset: da091bb67459 Author: sla Date: 2011-02-28 14:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/da091bb67459 7022037: Pause when exiting if debugger is attached on windows Reviewed-by: dsamersoff, kamg, hosterda ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/vmError.cpp Changeset: c1a6154012c8 Author: kamg Date: 2011-02-28 16:01 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c1a6154012c8 7020118: Alter frame assignability to allow for exception handler coverage of invokespecial Summary: Add special rule to allow assignment of frames with uninit flags set. Reviewed-by: never, coleenp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/verificationType.hpp Changeset: 23ae54207126 Author: rottenha Date: 2011-02-28 15:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/23ae54207126 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/os.hpp Changeset: cef8c988e7b8 Author: rottenha Date: 2011-02-28 22:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cef8c988e7b8 Merge Changeset: 5584e20db481 Author: sla Date: 2011-03-02 09:41 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5584e20db481 7023323: Build failure on VS2003: IsDebuggerPresent not found Summary: #define _WIN32_WINNT 0x500 Reviewed-by: ohrstrom, hosterda, coleenp ! src/os/windows/vm/os_windows.cpp Changeset: 4a9604cd7c5f Author: kamg Date: 2011-03-02 08:18 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4a9604cd7c5f 6878713: Verifier heap corruption, relating to backward jsrs Summary: Added overflow detection in arena Amalloc methods Reviewed-by: coleenp, phh ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp + test/runtime/6878713/Test6878713.sh + test/runtime/6878713/testcase.jar Changeset: 99bd05619fa4 Author: zgu Date: 2011-03-02 09:16 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/99bd05619fa4 7017110: Add /SAFESEH to links on windows 32bit to verify safe exceptions Summary: Ensure safe exception handler table is generated on Win32 binaries when compile with VS2010 Reviewed-by: acorn, coleenp, dcubed, sla, ohair ! make/windows/makefiles/compile.make ! make/windows/makefiles/launcher.make Changeset: a3c0ec0428a2 Author: zgu Date: 2011-03-02 16:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a3c0ec0428a2 Merge Changeset: 8c0d0510d36f Author: dcubed Date: 2011-03-03 09:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8c0d0510d36f Merge Changeset: 4e0069ff33df Author: johnc Date: 2011-02-28 09:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4e0069ff33df 7022200: G1: optimized build broken Summary: Make the G1 specific version of is_in_closed_subset() available in all builds. Reviewed-by: tonyp, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 11303bede852 Author: jcoomes Date: 2011-03-03 21:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/11303bede852 Merge Changeset: 8c9c9ee30d71 Author: kvn Date: 2011-03-03 23:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8c9c9ee30d71 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From vladimir.kozlov at oracle.com Fri Mar 4 08:33:16 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Mar 2011 08:33:16 -0800 Subject: Request for review (XL): 7012648: move JSR 292 to package java.lang.invoke and adjust names In-Reply-To: References: <4D7036EF.8020504@oracle.com> Message-ID: <4D71144C.9050105@oracle.com> OK. Vladimir On 3/4/11 1:47 AM, Christian Thalinger wrote: > On Mar 4, 2011, at 1:48 AM, Vladimir Kozlov wrote: >> systemDictionary.hpp: why switching back to sun.dyn?: >> >> - template(MethodHandleImpl_klass, java_dyn_MethodHandleImpl, Pre_JSR292) /* AllowTransitionalJSR292 ONLY */ \ >> + template(MethodHandleImpl_klass, sun_dyn_MethodHandleImpl, Opt) /* AllowTransitionalJSR292 ONLY */ \ > > That's because MethodHandleImpl goes away with 7012648 and we just use sun_dyn_MethodHandleImpl. It doesn't matter what name it has, both packages (sun.dyn and java.dyn) are searched anyway. > >> >> >> methodHandleWalk.cpp: comment says "java.dyn" but should it be "java.lang.invoke"? : >> >> + if (m == NULL) >> + // sun.dyn.MethodHandleImpl not found, look for java.dyn.MethodHandleNatives: >> + m = vmIntrinsics::method_for(vmIntrinsics::_checkSpreadArgument_TRANS2); > > No, that's correct. checkSpreadArgument will be moved to java.dyn.MethodHandleNatives with 6839872 and finally to java.lang.invoke.MethodHandleNatives with 7012648. > > I know it's confusing but all this will go away, eventually. > > -- Christian > >> >> Vladimir >> >> Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7012648/webrev.01/ >>> 7012648: move JSR 292 to package java.lang.invoke and adjust names >>> Summary: package and class renaming only; delete unused methods and classes >>> Reviewed-by: >>> At the request of the JDK7 Architect, the JSR 292 EG has agreed moving >>> the API from the package java.dyn to the package java.lang.invoke. >>> This is the JVM part of 7012648. >>> The support for the old namespace (AllowTransitionalJSR292) will be >>> removed as soon as the related JDK changes appear in the >>> repositories. > > From tom.rodriguez at oracle.com Fri Mar 4 12:32:51 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Mar 2011 12:32:51 -0800 Subject: ArrayList loop regression ? In-Reply-To: <4D6A9501.9050508@univ-mlv.fr> References: <4D6A9501.9050508@univ-mlv.fr> Message-ID: <3E7842DA-0BEC-4F2E-A235-CFBEDCF72251@oracle.com> On Feb 27, 2011, at 10:16 AM, R?mi Forax wrote: > A student sent me a micro-benchmark that shows a regression in the way > hotspot compiles indexed loop on linux x64. > > Basically jdk7: > java version "1.7.0-ea" > Java(TM) SE Runtime Environment (build 1.7.0-ea-b129) > Java HotSpot(TM) 64-Bit Server VM (build 21.0-b01, mixed mode) > is really slow compared to jdk6: > java version "1.6.0_21" > Java(TM) SE Runtime Environment (build 1.6.0_21-b06) > Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode) I'm seeing bimodal behaviour, even with 6u21. smite ~ % /java/re/jdk/1.6.0_21/latest/binaries/solaris-amd64/bin/java -server -Xbatch ArrayListIteration2 495000000 29346625 495000000 27204499 495000000 19873904 495000000 19784322 495000000 19766402 495000000 19774330 495000000 19826623 495000000 19786293 495000000 21203493 495000000 19809224 495000000 19812661 495000000 19794664 495000000 19752474 495000000 19798351 495000000 19836035 495000000 19734894 495000000 19869816 495000000 19742165 495000000 19724705 495000000 19826919 smite ~ % /java/re/jdk/1.6.0_21/latest/binaries/solaris-amd64/bin/java -server -Xbatch ArrayListIteration2 495000000 26317969 495000000 24463039 495000000 17135392 495000000 17036236 495000000 18216820 495000000 17632804 495000000 17067382 495000000 17020512 495000000 17044797 495000000 17111037 495000000 17056577 495000000 17338273 495000000 17874496 495000000 17690025 495000000 17061152 495000000 17039536 495000000 17097877 495000000 17053703 495000000 17086628 495000000 17308508 That 17 million score is the best I've seen on the particular machine I'm running on. I guess the gap is similar to what you are seeing. I see the same thing with every 6 and 7 release I've tried. I even see the bimodal scores with 1.5.0. I captured LogCompilation output for a fast and slow run and they performed exactly the same compiles with the same inlining so it's not obvious why one is faster than the other. I just captured PrintNMethods for slow and fast runs and they are _exactly_ the same, including register assignment and code location in memory. So the only thing left is the location of the Java objects in memory. The array is 10 million elements long which is pretty large. I'm running on an opteron which is NUMA so maybe sometime the memory ends up on a different board so sometimes the latency is higher? The array size is so large that's it's basically a memory bandwidth test. What kind of machines have you tested on? How does a smaller array iterated more times behave? tom > > [forax at localhost src]$ java -server -Xbatch ArrayListIteration2 > 495000000 23562949 > 495000000 28475066 > 495000000 10691187 > 495000000 17820582 > 495000000 17910601 > 495000000 17231943 > 495000000 17834819 > 495000000 17444713 > 495000000 17831591 > 495000000 17880947 > 495000000 17405874 > 495000000 17823323 > 495000000 17254145 > 495000000 17815812 > 495000000 17534777 > 495000000 17589371 > 495000000 17830668 > 495000000 17389534 > 495000000 17884535 > 495000000 17484575 > > [forax at localhost src]$ /usr/jdk/jdk1.6.0_21/bin/java -server -Xbatch ArrayListIteration2 > 495000000 28299043 > 495000000 23543527 > 495000000 11718848 > 495000000 12008201 > 495000000 12821666 > 495000000 11661011 > 495000000 12502804 > 495000000 11763580 > 495000000 11663503 > 495000000 12620776 > 495000000 11649228 > 495000000 12593051 > 495000000 11805152 > 495000000 11702461 > 495000000 12368391 > 495000000 11615139 > 495000000 12511620 > 495000000 11726843 > 495000000 11796660 > 495000000 12379443 > > I've also tested with an older 32bit VM that doesn't show any regression on 32bits : > java version "1.7.0-ea" > Java(TM) SE Runtime Environment (build 1.7.0-ea-b123) > Java HotSpot(TM) Server VM (build 20.0-b04, mixed mode) > > R?mi > > From igor.veresov at oracle.com Fri Mar 4 14:57:21 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 04 Mar 2011 14:57:21 -0800 Subject: Request for review(M): 7020403: Add AdvancedCompilationPolicy for tiered In-Reply-To: <9A5F9CFB-2988-4688-969E-C98E32B67641@oracle.com> References: <4D7045A0.3090908@oracle.com> <9A5F9CFB-2988-4688-969E-C98E32B67641@oracle.com> Message-ID: <4D716E51.1090709@oracle.com> Thanks Vladimir and Tom! On 3/3/11 9:33 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Mar 3, 2011, at 5:51 PM, Igor Veresov wrote: > >> This implements adaptive tiered compilation policy. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/7020403/webrev.00/ >> >> Thanks, >> igor > From forax at univ-mlv.fr Fri Mar 4 15:55:19 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 05 Mar 2011 00:55:19 +0100 Subject: ArrayList loop regression ? In-Reply-To: <3E7842DA-0BEC-4F2E-A235-CFBEDCF72251@oracle.com> References: <4D6A9501.9050508@univ-mlv.fr> <3E7842DA-0BEC-4F2E-A235-CFBEDCF72251@oracle.com> Message-ID: <4D717BE7.3080601@univ-mlv.fr> On 03/04/2011 09:32 PM, Tom Rodriguez wrote: > On Feb 27, 2011, at 10:16 AM, R?mi Forax wrote: > >> A student sent me a micro-benchmark that shows a regression in the way >> hotspot compiles indexed loop on linux x64. >> >> Basically jdk7: >> java version "1.7.0-ea" >> Java(TM) SE Runtime Environment (build 1.7.0-ea-b129) >> Java HotSpot(TM) 64-Bit Server VM (build 21.0-b01, mixed mode) >> is really slow compared to jdk6: >> java version "1.6.0_21" >> Java(TM) SE Runtime Environment (build 1.6.0_21-b06) >> Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode) > I'm seeing bimodal behaviour, even with 6u21. > > smite ~ % /java/re/jdk/1.6.0_21/latest/binaries/solaris-amd64/bin/java -server -Xbatch ArrayListIteration2 > 495000000 29346625 > 495000000 27204499 > 495000000 19873904 > 495000000 19784322 > 495000000 19766402 > 495000000 19774330 > 495000000 19826623 > 495000000 19786293 > 495000000 21203493 > 495000000 19809224 > 495000000 19812661 > 495000000 19794664 > 495000000 19752474 > 495000000 19798351 > 495000000 19836035 > 495000000 19734894 > 495000000 19869816 > 495000000 19742165 > 495000000 19724705 > 495000000 19826919 > smite ~ % /java/re/jdk/1.6.0_21/latest/binaries/solaris-amd64/bin/java -server -Xbatch ArrayListIteration2 > 495000000 26317969 > 495000000 24463039 > 495000000 17135392 > 495000000 17036236 > 495000000 18216820 > 495000000 17632804 > 495000000 17067382 > 495000000 17020512 > 495000000 17044797 > 495000000 17111037 > 495000000 17056577 > 495000000 17338273 > 495000000 17874496 > 495000000 17690025 > 495000000 17061152 > 495000000 17039536 > 495000000 17097877 > 495000000 17053703 > 495000000 17086628 > 495000000 17308508 > > That 17 million score is the best I've seen on the particular machine I'm running on. I guess the gap is similar to what you are seeing. I see the same thing with every 6 and 7 release I've tried. I even see the bimodal scores with 1.5.0. > > I captured LogCompilation output for a fast and slow run and they performed exactly the same compiles with the same inlining so it's not obvious why one is faster than the other. I just captured PrintNMethods for slow and fast runs and they are _exactly_ the same, including register assignment and code location in memory. So the only thing left is the location of the Java objects in memory. The array is 10 million elements long which is pretty large. I'm running on an opteron which is NUMA so maybe sometime the memory ends up on a different board so sometimes the latency is higher? The array size is so large that's it's basically a memory bandwidth test. What kind of machines have you tested on? Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz > How does a smaller array iterated more times behave? It works as expected. I have, yet again, to pach my abstract Von Neumann machine in my head. BTW, with JDK7, the performance of the loop with an iterator is really close to the one with an index. It's impressive. > tom Many thanks Tom. R?mi From forax at univ-mlv.fr Fri Mar 4 16:12:05 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sat, 05 Mar 2011 01:12:05 +0100 Subject: ArrayList loop regression ? In-Reply-To: References: <4D6A9501.9050508@univ-mlv.fr> Message-ID: <4D717FD5.6060904@univ-mlv.fr> On 03/04/2011 10:16 AM, Ismael Juma wrote: > Hi Remi, > > R?mi Forax writes: >> A student sent me a micro-benchmark that shows a regression in the way >> hotspot compiles indexed loop on linux x64. > Since this looks like a performance regression, maybe it's worth filing a bug so > that it doesn't get lost? > > Best, > Ismael > Thanks, what do you think about the answer of Tom. I wonder if it can explain another bimodal behaviour seen by Josh Bloch: http://parleys.com/d/2103 R?mi From tom.rodriguez at oracle.com Fri Mar 4 17:42:59 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Mar 2011 17:42:59 -0800 Subject: review (XS) for 7024866: # assert(limit == NULL || limit <= nm->code_end()) failed: in bounds Message-ID: <6E1F2CFA-3A08-4A64-846B-9C31694C76C6@oracle.com> http://cr.openjdk.java.net/~never/7024866 7024866: # assert(limit == NULL || limit <= nm->code_end()) failed: in bounds Reviewed-by: This appears to be a long standing issue that for some reason we never tripped across. If an address appears in the disassembly we check to see if it has relocInfo so we can print out the actual value. In this case a jmpq is right at the end of the code and it's encoded in a short fashion. The code that attempts to look up the oop does this: oop nmethod::embeddedOop_at(u_char* p) { RelocIterator iter(this, p, p + oopSize); and in this case p + oopSize is greater than code_end. The fix is use p + 1 as the end since we're really looking for a reloc at p. + 1 is the normal idiom for this in other places. Tested with -Xcomp -XX:+PrintNMethods which showed the failure previously From igor.veresov at oracle.com Fri Mar 4 17:59:38 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 04 Mar 2011 17:59:38 -0800 Subject: review (XS) for 7024866: # assert(limit == NULL || limit <= nm->code_end()) failed: in bounds In-Reply-To: <6E1F2CFA-3A08-4A64-846B-9C31694C76C6@oracle.com> References: <6E1F2CFA-3A08-4A64-846B-9C31694C76C6@oracle.com> Message-ID: <4D71990A.6040809@oracle.com> Looks good. igor On 3/4/11 5:42 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7024866 > > 7024866: # assert(limit == NULL || limit<= nm->code_end()) failed: in bounds > Reviewed-by: > > This appears to be a long standing issue that for some reason we never > tripped across. If an address appears in the disassembly we check to > see if it has relocInfo so we can print out the actual value. In this > case a jmpq is right at the end of the code and it's encoded in a > short fashion. The code that attempts to look up the oop does this: > > oop nmethod::embeddedOop_at(u_char* p) { > RelocIterator iter(this, p, p + oopSize); > > and in this case p + oopSize is greater than code_end. The fix is use > p + 1 as the end since we're really looking for a reloc at p. + 1 is > the normal idiom for this in other places. Tested with -Xcomp > -XX:+PrintNMethods which showed the failure previously From igor.veresov at oracle.com Fri Mar 4 21:11:51 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sat, 05 Mar 2011 05:11:51 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7020403: Add AdvancedCompilationPolicy for tiered Message-ID: <20110305051153.4512647D44@hg.openjdk.java.net> Changeset: 5d8f5a6dced7 Author: iveresov Date: 2011-03-04 15:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5d8f5a6dced7 7020403: Add AdvancedCompilationPolicy for tiered Summary: This implements adaptive tiered compilation policy. Reviewed-by: kvn, never ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.hpp + src/share/vm/runtime/advancedThresholdPolicy.cpp + src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/compilationPolicy.cpp From tom.rodriguez at oracle.com Sat Mar 5 00:42:56 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 05 Mar 2011 08:42:56 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110305084259.E5E7B47D5E@hg.openjdk.java.net> Changeset: 4cd9add59b1e Author: never Date: 2011-03-04 20:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4cd9add59b1e 7024866: # assert(limit == NULL || limit <= nm->code_end()) failed: in bounds Reviewed-by: kvn, iveresov ! src/share/vm/code/nmethod.cpp Changeset: 8ec5e1f45ea1 Author: never Date: 2011-03-04 22:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8ec5e1f45ea1 Merge From forax at univ-mlv.fr Sat Mar 5 01:24:25 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sat, 05 Mar 2011 10:24:25 +0100 Subject: ArrayList loop regression ? In-Reply-To: <4D717FD5.6060904@univ-mlv.fr> References: <4D6A9501.9050508@univ-mlv.fr> <4D717FD5.6060904@univ-mlv.fr> Message-ID: <4D720149.4020504@univ-mlv.fr> On 03/05/2011 01:12 AM, R?mi Forax wrote: > On 03/04/2011 10:16 AM, Ismael Juma wrote: >> Hi Remi, >> >> R?mi Forax writes: >>> A student sent me a micro-benchmark that shows a regression in the way >>> hotspot compiles indexed loop on linux x64. >> Since this looks like a performance regression, maybe it's worth >> filing a bug so >> that it doesn't get lost? >> >> Best, >> Ismael >> > > Thanks, > what do you think about the answer of Tom. > > I wonder if it can explain another bimodal behaviour seen by Josh Bloch: > http://parleys.com/d/2103 > > R?mi > oups, sorry. private email that goes public. R?mi From vladimir.kozlov at oracle.com Sat Mar 5 18:07:18 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sun, 06 Mar 2011 02:07:18 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6589823: Error: meet not symmetric Message-ID: <20110306020721.1AE8947DD3@hg.openjdk.java.net> Changeset: 8e72cd29b15d Author: kvn Date: 2011-03-05 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8e72cd29b15d 6589823: Error: meet not symmetric Summary: arrays pointers meet must fall to bottom if exact array klasses in upper lattice are not equal or super klass is exact. Reviewed-by: never ! src/share/vm/opto/type.cpp From tom.rodriguez at oracle.com Mon Mar 7 00:22:46 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Mon, 07 Mar 2011 08:22:46 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6965570: assert(!needs_patching && x->is_loaded(), "how do we know it's volatile if it's not loaded") Message-ID: <20110307082248.A6E8B47ECB@hg.openjdk.java.net> Changeset: 425688247f3d Author: never Date: 2011-03-06 22:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/425688247f3d 6965570: assert(!needs_patching && x->is_loaded(),"how do we know it's volatile if it's not loaded") Reviewed-by: iveresov ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_ValueMap.hpp From volker.simonis at gmail.com Mon Mar 7 07:18:31 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 7 Mar 2011 16:18:31 +0100 Subject: Assertion if using "-XX:+CITraceTypeFlow -XX:+Verbose" together Message-ID: If -XX:+CITraceTypeFlow is beeing used together with -XX:+Verbose in a debug build the VM asserts while trying to print the bytecodes of a dummy block. This can easily be fixed by suppressing the printing of bytecodes for dummy blocks: --- a/src/share/vm/ci/ciTypeFlow.cpp Thu Feb 10 16:24:29 2011 -0800 +++ b/src/share/vm/ci/ciTypeFlow.cpp Mon Mar 07 16:12:39 2011 +0100 @@ -1871,7 +1871,8 @@ // ------------------------------------------------------------------ // ciTypeFlow::Block::print_on void ciTypeFlow::Block::print_on(outputStream* st) const { - if ((Verbose || WizardMode)) { + if ((Verbose || WizardMode) && (limit() >= 0)) { + // Don't print 'dummy' blocks (i.e. blocks with limit() '-1') outer()->method()->print_codes_on(start(), limit(), st); } st->print_cr(" ==================================================== "); From tom.rodriguez at oracle.com Tue Mar 8 13:18:23 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 8 Mar 2011 13:18:23 -0800 Subject: Assertion if using "-XX:+CITraceTypeFlow -XX:+Verbose" together In-Reply-To: References: Message-ID: I created 7025708 to track this. I'll push it later today. Thanks! tom On Mar 7, 2011, at 7:18 AM, Volker Simonis wrote: > If -XX:+CITraceTypeFlow is beeing used together with -XX:+Verbose in a > debug build the VM asserts while trying to print the bytecodes of a > dummy block. > This can easily be fixed by suppressing the printing of bytecodes for > dummy blocks: > > --- a/src/share/vm/ci/ciTypeFlow.cpp Thu Feb 10 16:24:29 2011 -0800 > +++ b/src/share/vm/ci/ciTypeFlow.cpp Mon Mar 07 16:12:39 2011 +0100 > @@ -1871,7 +1871,8 @@ > // ------------------------------------------------------------------ > // ciTypeFlow::Block::print_on > void ciTypeFlow::Block::print_on(outputStream* st) const { > - if ((Verbose || WizardMode)) { > + if ((Verbose || WizardMode) && (limit() >= 0)) { > + // Don't print 'dummy' blocks (i.e. blocks with limit() '-1') > outer()->method()->print_codes_on(start(), limit(), st); > } > st->print_cr(" ==================================================== "); From vladimir.kozlov at oracle.com Tue Mar 8 15:53:18 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Mar 2011 15:53:18 -0800 Subject: Request for reviews (S): 7025742: Can not use CodeCache::unallocated_capacity() with fragmented CodeCache Message-ID: <4D76C16E.90509@oracle.com> http://cr.openjdk.java.net/~kvn/7025742/webrev Fixed 7025742: Can not use CodeCache::unallocated_capacity() with fragmented CodeCache CodeCache::unallocated_capacity() reports combined (not continues) free space. Use largest_free_block() instead of unallocated_capacity(). From tom.rodriguez at oracle.com Tue Mar 8 20:43:59 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 8 Mar 2011 20:43:59 -0800 Subject: Request for reviews (S): 7025742: Can not use CodeCache::unallocated_capacity() with fragmented CodeCache In-Reply-To: <4D76C16E.90509@oracle.com> References: <4D76C16E.90509@oracle.com> Message-ID: <38CF0D34-DEDA-4A90-AF15-7DFEBF16D001@oracle.com> That looks good. tom On Mar 8, 2011, at 3:53 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7025742/webrev > > Fixed 7025742: Can not use CodeCache::unallocated_capacity() with fragmented CodeCache > > CodeCache::unallocated_capacity() reports combined (not continues) free space. > > Use largest_free_block() instead of unallocated_capacity(). From vladimir.kozlov at oracle.com Tue Mar 8 20:48:10 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Mar 2011 20:48:10 -0800 Subject: Request for reviews (S): 7025742: Can not use CodeCache::unallocated_capacity() with fragmented CodeCache In-Reply-To: <38CF0D34-DEDA-4A90-AF15-7DFEBF16D001@oracle.com> References: <4D76C16E.90509@oracle.com> <38CF0D34-DEDA-4A90-AF15-7DFEBF16D001@oracle.com> Message-ID: <4D77068A.9080403@oracle.com> Thank you, Tom Vladimir On 3/8/11 8:43 PM, Tom Rodriguez wrote: > That looks good. > > tom > > On Mar 8, 2011, at 3:53 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7025742/webrev >> >> Fixed 7025742: Can not use CodeCache::unallocated_capacity() with fragmented CodeCache >> >> CodeCache::unallocated_capacity() reports combined (not continues) free space. >> >> Use largest_free_block() instead of unallocated_capacity(). > From igor.veresov at oracle.com Tue Mar 8 23:05:57 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 08 Mar 2011 23:05:57 -0800 Subject: Request for reviews (S): 7025742: Can not use CodeCache::unallocated_capacity() with fragmented CodeCache In-Reply-To: <4D76C16E.90509@oracle.com> References: <4D76C16E.90509@oracle.com> Message-ID: <4D7726D5.6040702@oracle.com> Looks good. igor On 3/8/11 3:53 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7025742/webrev > > Fixed 7025742: Can not use CodeCache::unallocated_capacity() with > fragmented CodeCache > > CodeCache::unallocated_capacity() reports combined (not continues) free > space. > > Use largest_free_block() instead of unallocated_capacity(). From bertrand.delsart at oracle.com Wed Mar 9 05:40:35 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 09 Mar 2011 14:40:35 +0100 Subject: Request for Review (XS): leverage shared x86-only deoptimization code Message-ID: <4D778353.2050900@oracle.com> Hi all, Here is a simple webrev to allow other platforms to benefit from shared code that was conditionally compiled only on x86 machines: http://cr.openjdk.java.net/~bdelsart/7025485/webrev.00/ This code had initially be modified by explicitly adding to the ifdef the platforms that required it. However, since the code is supposed to be harmless, it is cleaner and better in the long term to activate it by default for all future platforms. Bertrand. -- Bertrand Delsart, bertrand.delsart at oracle.com Sun-Oracle, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE Phone : +33 4 76 18 81 23 Fax : +33 4 76 18 88 88 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ChrisPhi at LGonQn.Org Wed Mar 9 06:15:50 2011 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Wed, 09 Mar 2011 09:15:50 -0500 Subject: Request for Review (XS): leverage shared x86-only deoptimization code In-Reply-To: <4D778353.2050900@oracle.com> References: <4D778353.2050900@oracle.com> Message-ID: <4D778B96.1050703@LGonQn.Org> Looks good, Chris On 09/03/11 08:40 AM, Bertrand Delsart wrote: > Hi all, > > Here is a simple webrev to allow other platforms to benefit from > shared code that was conditionally compiled only on x86 machines: > > http://cr.openjdk.java.net/~bdelsart/7025485/webrev.00/ > > This code had initially be modified by explicitly adding to the ifdef > the platforms that required it. However, since the code is supposed to > be harmless, it is cleaner and better in the long term to activate it > by default for all future platforms. > > Bertrand. From vladimir.kozlov at oracle.com Wed Mar 9 09:12:17 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Mar 2011 09:12:17 -0800 Subject: Request for reviews (S): 7025742: Can not use CodeCache::unallocated_capacity() with fragmented CodeCache In-Reply-To: <4D7726D5.6040702@oracle.com> References: <4D76C16E.90509@oracle.com> <4D7726D5.6040702@oracle.com> Message-ID: <4D77B4F1.3020806@oracle.com> Thank you Vladimir Igor Veresov wrote: > Looks good. > > igor > > On 3/8/11 3:53 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/7025742/webrev >> >> Fixed 7025742: Can not use CodeCache::unallocated_capacity() with >> fragmented CodeCache >> >> CodeCache::unallocated_capacity() reports combined (not continues) free >> space. >> >> Use largest_free_block() instead of unallocated_capacity(). > From tom.rodriguez at oracle.com Wed Mar 9 09:42:58 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 9 Mar 2011 09:42:58 -0800 Subject: Request for Review (XS): leverage shared x86-only deoptimization code In-Reply-To: <4D778353.2050900@oracle.com> References: <4D778353.2050900@oracle.com> Message-ID: <7062757C-A83D-4089-9BAF-A0907BB01ED0@oracle.com> You should move the initial_fp declaration up into the main section since it isn't an x86 temp anymore. I know this is a bit nit-picky, but I'd also prefer if the comments you updated just described what was being captured and why it might be needed instead of talking about the history. tom On Mar 9, 2011, at 5:40 AM, Bertrand Delsart wrote: > Hi all, > > Here is a simple webrev to allow other platforms to benefit from > shared code that was conditionally compiled only on x86 machines: > > http://cr.openjdk.java.net/~bdelsart/7025485/webrev.00/ > > This code had initially be modified by explicitly adding to the ifdef the platforms that required it. However, since the code is supposed to be harmless, it is cleaner and better in the long term to activate it by default for all future platforms. > > Bertrand. > -- > Bertrand Delsart, bertrand.delsart at oracle.com > Sun-Oracle, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE > Phone : +33 4 76 18 81 23 Fax : +33 4 76 18 88 88 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > NOTICE: This email message is for the sole use of the intended > recipient(s) and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or distribution > is prohibited. If you are not the intended recipient, please contact > the sender by reply email and destroy all copies of the original > message. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From vladimir.kozlov at oracle.com Wed Mar 9 11:29:03 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 09 Mar 2011 19:29:03 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7025742: Can not use CodeCache::unallocated_capacity() with fragmented CodeCache Message-ID: <20110309192905.B9FA147FFA@hg.openjdk.java.net> Changeset: 1c0cf339481b Author: kvn Date: 2011-03-09 09:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1c0cf339481b 7025742: Can not use CodeCache::unallocated_capacity() with fragmented CodeCache Summary: Use largest_free_block() instead of unallocated_capacity(). Reviewed-by: iveresov, never, ysr ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/sweeper.cpp From bertrand.delsart at oracle.com Thu Mar 10 04:23:46 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Thu, 10 Mar 2011 04:23:46 -0800 (PST) Subject: Request for Review (XS): leverage shared x86-only deoptimization code In-Reply-To: <7062757C-A83D-4089-9BAF-A0907BB01ED0@oracle.com> References: <4D778353.2050900@oracle.com> <7062757C-A83D-4089-9BAF-A0907BB01ED0@oracle.com> Message-ID: <4D78C2D2.9050005@oracle.com> Hi Tom, New webrev with the one line move you suggested and some changes in the comments: http://cr.openjdk.java.net/~bdelsart/7025485/webrev.01/ Comments were mainly to help the review. Now that it is done, since you prefer the history not to be kept in the files, I've removed all the history part of the old comment and only kept the first sentence, which explains what it does (adding the "On some platforms"): + // On some platforms, we need a way to pass fp to the unpacking code + // so the skeletal frames come out correct. If you'd like to use this push to complete the information, feel free to suggest additional comments that I will insert before pushing. Else, please confirm that I have your approval for the push. Thanks, Bertrand. On 03/ 9/11 06:42 PM, Tom Rodriguez wrote: > You should move the initial_fp declaration up into the main section since it isn't an x86 temp anymore. I know this is a bit nit-picky, but I'd also prefer if the comments you updated just described what was being captured and why it might be needed instead of talking about the history. > > tom > > On Mar 9, 2011, at 5:40 AM, Bertrand Delsart wrote: > >> Hi all, >> >> Here is a simple webrev to allow other platforms to benefit from >> shared code that was conditionally compiled only on x86 machines: >> >> http://cr.openjdk.java.net/~bdelsart/7025485/webrev.00/ >> >> This code had initially be modified by explicitly adding to the ifdef the platforms that required it. However, since the code is supposed to be harmless, it is cleaner and better in the long term to activate it by default for all future platforms. >> >> Bertrand. >> -- >> Bertrand Delsart, bertrand.delsart at oracle.com >> Sun-Oracle, 180 av. de l'Europe, ZIRST de Montbonnot, >> 38334 Saint Ismier, FRANCE >> Phone : +33 4 76 18 81 23 Fax : +33 4 76 18 88 88 >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> NOTICE: This email message is for the sole use of the intended >> recipient(s) and may contain confidential and privileged >> information. Any unauthorized review, use, disclosure or distribution >> is prohibited. If you are not the intended recipient, please contact >> the sender by reply email and destroy all copies of the original >> message. >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -- Bertrand Delsart, bertrand.delsart at oracle.com Sun-Oracle, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE Phone : +33 4 76 18 81 23 Fax : +33 4 76 18 88 88 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From tom.rodriguez at oracle.com Thu Mar 10 08:34:23 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 10 Mar 2011 08:34:23 -0800 Subject: Request for Review (XS): leverage shared x86-only deoptimization code In-Reply-To: <4D78C2D2.9050005@oracle.com> References: <4D778353.2050900@oracle.com> <7062757C-A83D-4089-9BAF-A0907BB01ED0@oracle.com> <4D78C2D2.9050005@oracle.com> Message-ID: Looks great. Thanks. tom On Mar 10, 2011, at 4:23 AM, Bertrand Delsart wrote: > Hi Tom, > > New webrev with the one line move you suggested and some changes in the > comments: > http://cr.openjdk.java.net/~bdelsart/7025485/webrev.01/ > > Comments were mainly to help the review. Now that it is done, since you > prefer the history not to be kept in the files, I've removed all the > history part of the old comment and only kept the first sentence, which > explains what it does (adding the "On some platforms"): > + // On some platforms, we need a way to pass fp to the unpacking code > + // so the skeletal frames come out correct. > > If you'd like to use this push to complete the information, feel free to > suggest additional comments that I will insert before pushing. Else, > please confirm that I have your approval for the push. > > Thanks, > > Bertrand. > > On 03/ 9/11 06:42 PM, Tom Rodriguez wrote: >> You should move the initial_fp declaration up into the main section since it isn't an x86 temp anymore. I know this is a bit nit-picky, but I'd also prefer if the comments you updated just described what was being captured and why it might be needed instead of talking about the history. >> >> tom >> >> On Mar 9, 2011, at 5:40 AM, Bertrand Delsart wrote: >> >>> Hi all, >>> >>> Here is a simple webrev to allow other platforms to benefit from >>> shared code that was conditionally compiled only on x86 machines: >>> >>> http://cr.openjdk.java.net/~bdelsart/7025485/webrev.00/ >>> >>> This code had initially be modified by explicitly adding to the ifdef the platforms that required it. However, since the code is supposed to be harmless, it is cleaner and better in the long term to activate it by default for all future platforms. >>> >>> Bertrand. >>> -- >>> Bertrand Delsart, bertrand.delsart at oracle.com >>> Sun-Oracle, 180 av. de l'Europe, ZIRST de Montbonnot, >>> 38334 Saint Ismier, FRANCE >>> Phone : +33 4 76 18 81 23 Fax : +33 4 76 18 88 88 >>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> NOTICE: This email message is for the sole use of the intended >>> recipient(s) and may contain confidential and privileged >>> information. Any unauthorized review, use, disclosure or distribution >>> is prohibited. If you are not the intended recipient, please contact >>> the sender by reply email and destroy all copies of the original >>> message. >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > > > -- > Bertrand Delsart, bertrand.delsart at oracle.com > Sun-Oracle, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE > Phone : +33 4 76 18 81 23 Fax : +33 4 76 18 88 88 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > NOTICE: This email message is for the sole use of the intended > recipient(s) and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or distribution > is prohibited. If you are not the intended recipient, please contact > the sender by reply email and destroy all copies of the original > message. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From bertrand.delsart at oracle.com Thu Mar 10 08:40:53 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Thu, 10 Mar 2011 17:40:53 +0100 Subject: Request for Review (XS): leverage shared x86-only deoptimization code In-Reply-To: References: <4D778353.2050900@oracle.com> <7062757C-A83D-4089-9BAF-A0907BB01ED0@oracle.com> <4D78C2D2.9050005@oracle.com> Message-ID: <4D78FF15.8040905@oracle.com> You're welcome. Thanks Tom and Chris. On 03/10/11 05:34 PM, Tom Rodriguez wrote: > Looks great. Thanks. > > tom -- Bertrand Delsart, bertrand.delsart at oracle.com Sun-Oracle, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE Phone : +33 4 76 18 81 23 Fax : +33 4 76 18 88 88 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From vladimir.kozlov at oracle.com Thu Mar 10 20:42:10 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Mar 2011 20:42:10 -0800 Subject: Request for reviews (XS): 7026631: field _klass is incorrectly set for dual type of TypeAryPtr::OOPS Message-ID: <4D79A822.6010704@oracle.com> http://cr.openjdk.java.net/~kvn/7026631/webrev Fixed 7026631: field _klass is incorrectly set for dual type of TypeAryPtr::OOPS TypeAryPtr::klass() method misses the check "this->dual() != TypeAryPtr::OOPS" and sets _klass field to dangling ciKlass pointer. As result VM crash when it tries to use this cached pointer during an other compilation. From john.coomes at oracle.com Thu Mar 10 20:44:05 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Mar 2011 04:44:05 +0000 Subject: hg: jdk7/hotspot-comp: 6 new changesets Message-ID: <20110311044405.8AEB64706E@hg.openjdk.java.net> Changeset: a1c8b847b753 Author: ohrstrom Date: 2011-02-28 10:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/a1c8b847b753 7021753: Add a build times report Summary: Report the build times at end of a jdkroot build. Reviewed-by: ohair ! Makefile ! make/Defs-internal.gmk ! make/corba-rules.gmk ! make/deploy-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jaxp-rules.gmk ! make/jaxws-rules.gmk ! make/jdk-rules.gmk ! make/langtools-rules.gmk ! make/sponsors-rules.gmk Changeset: 47ad81d343e8 Author: ohair Date: 2011-03-01 11:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/47ad81d343e8 7023111: Add webrev script to make/scripts Reviewed-by: darcy + make/scripts/webrev.ksh Changeset: 258b21c7f4af Author: ohair Date: 2011-03-01 11:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/258b21c7f4af Merge Changeset: 27384dd2d8ed Author: ohair Date: 2011-03-03 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/27384dd2d8ed Merge Changeset: c6f380693342 Author: ohair Date: 2011-03-09 16:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/c6f380693342 7026167: Broken fastdebug only build Reviewed-by: cl ! Makefile Changeset: ddc2fcb3682f Author: cl Date: 2011-03-10 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/ddc2fcb3682f Added tag jdk7-b133 for changeset c6f380693342 ! .hgtags From john.coomes at oracle.com Thu Mar 10 20:44:12 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Mar 2011 04:44:12 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b133 for changeset 671fe2e623ff Message-ID: <20110311044414.7DF3A4706F@hg.openjdk.java.net> Changeset: 918003855fa0 Author: cl Date: 2011-03-10 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/918003855fa0 Added tag jdk7-b133 for changeset 671fe2e623ff ! .hgtags From john.coomes at oracle.com Thu Mar 10 20:44:21 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Mar 2011 04:44:21 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b133 for changeset 8e1148c7911b Message-ID: <20110311044421.7470347070@hg.openjdk.java.net> Changeset: 2473f7027ac5 Author: cl Date: 2011-03-10 17:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/2473f7027ac5 Added tag jdk7-b133 for changeset 8e1148c7911b ! .hgtags From john.coomes at oracle.com Thu Mar 10 20:44:28 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Mar 2011 04:44:28 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b133 for changeset 359d0c8c00a0 Message-ID: <20110311044428.3923747071@hg.openjdk.java.net> Changeset: 8393aae2eb24 Author: cl Date: 2011-03-10 17:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/8393aae2eb24 Added tag jdk7-b133 for changeset 359d0c8c00a0 ! .hgtags From john.coomes at oracle.com Thu Mar 10 20:45:01 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Mar 2011 04:45:01 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 13 new changesets Message-ID: <20110311044740.C898447072@hg.openjdk.java.net> Changeset: 7931291bc5d3 Author: herrick Date: 2011-03-01 17:09 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7931291bc5d3 7021567: need to create jnlp javadoc for 64 bit bundles. Summary: need to create jnlp javadoc for 64 bit bundles. Reviewed-by: igor, ohair ! make/common/Release.gmk Changeset: c53711f82bfb Author: igor Date: 2011-03-08 14:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c53711f82bfb Merge - test/java/lang/Thread/StopBeforeStart.java Changeset: eb54e565c491 Author: ohair Date: 2011-02-26 09:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eb54e565c491 7016175: HTML generated from new JavaDoc has tags added from makefile Reviewed-by: jjg ! make/common/shared/Defs-javadoc.gmk ! make/docs/Makefile Changeset: 391a9ef69036 Author: ohair Date: 2011-02-26 10:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/391a9ef69036 Merge Changeset: e88c8381eaca Author: ohair Date: 2011-02-26 12:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e88c8381eaca 7022237: Fix use of \" in the new "release" file at the top of the install, windows issues Reviewed-by: ohrstrom ! make/common/Release.gmk Changeset: 123dd69407f9 Author: ohair Date: 2011-02-26 12:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/123dd69407f9 Merge Changeset: ed1d4691da29 Author: ohrstrom Date: 2011-02-28 10:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ed1d4691da29 7021753: Add a build times report Summary: Report the build times at end of a jdkroot build. Reviewed-by: ohair ! make/common/shared/Defs-utils.gmk Changeset: f32f0ae3d873 Author: ohair Date: 2011-03-02 12:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f32f0ae3d873 Merge Changeset: 869cba583dd4 Author: ohair Date: 2011-03-02 13:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/869cba583dd4 7020815: REBASE should not be required for windows jdk repo builds - can't build with VS 2010 Express Reviewed-by: prr ! make/common/shared/Defs-utils.gmk ! make/common/shared/Sanity.gmk Changeset: e5cd10425e7e Author: ohair Date: 2011-03-03 07:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e5cd10425e7e Merge - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java - test/java/lang/Thread/StopBeforeStart.java Changeset: c588355b5bb7 Author: ohair Date: 2011-03-03 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c588355b5bb7 Merge Changeset: 5e5f68a01d12 Author: ohair Date: 2011-03-08 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5e5f68a01d12 Merge ! make/common/Release.gmk Changeset: e947a98ea3c1 Author: cl Date: 2011-03-10 17:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e947a98ea3c1 Added tag jdk7-b133 for changeset 5e5f68a01d12 ! .hgtags From tom.rodriguez at oracle.com Thu Mar 10 20:48:45 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 10 Mar 2011 20:48:45 -0800 Subject: Request for reviews (XS): 7026631: field _klass is incorrectly set for dual type of TypeAryPtr::OOPS In-Reply-To: <4D79A822.6010704@oracle.com> References: <4D79A822.6010704@oracle.com> Message-ID: <689914D3-7039-45F8-AFF2-BBA671ED0E96@oracle.com> Looks good. tom On Mar 10, 2011, at 8:42 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7026631/webrev > > Fixed 7026631: field _klass is incorrectly set for dual type of TypeAryPtr::OOPS > > TypeAryPtr::klass() method misses the check "this->dual() != TypeAryPtr::OOPS" and sets _klass field to dangling ciKlass pointer. As result VM crash when it tries to use this cached pointer during an other compilation. From vladimir.kozlov at oracle.com Thu Mar 10 22:55:04 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Mar 2011 22:55:04 -0800 Subject: Request for reviews (XS): 7026631: field _klass is incorrectly set for dual type of TypeAryPtr::OOPS In-Reply-To: <689914D3-7039-45F8-AFF2-BBA671ED0E96@oracle.com> References: <4D79A822.6010704@oracle.com> <689914D3-7039-45F8-AFF2-BBA671ED0E96@oracle.com> Message-ID: <4D79C748.8030702@oracle.com> Thank you, Tom Vladimir On 3/10/11 8:48 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Mar 10, 2011, at 8:42 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7026631/webrev >> >> Fixed 7026631: field _klass is incorrectly set for dual type of TypeAryPtr::OOPS >> >> TypeAryPtr::klass() method misses the check "this->dual() != TypeAryPtr::OOPS" and sets _klass field to dangling ciKlass pointer. As result VM crash when it tries to use this cached pointer during an other compilation. > From vladimir.kozlov at oracle.com Fri Mar 11 10:20:39 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Mar 2011 18:20:39 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7026631: field _klass is incorrectly set for dual type of TypeAryPtr::OOPS Message-ID: <20110311182043.202B2470A2@hg.openjdk.java.net> Changeset: 83f08886981c Author: kvn Date: 2011-03-11 07:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/83f08886981c 7026631: field _klass is incorrectly set for dual type of TypeAryPtr::OOPS Summary: add missing check this->dual() != TypeAryPtr::OOPS into TypeAryPtr::klass(). Reviewed-by: never ! src/share/vm/opto/type.cpp From paul.hohensee at oracle.com Fri Mar 11 12:14:53 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 11 Mar 2011 15:14:53 -0500 Subject: Pls review 7023931 (S) Message-ID: <4D7A82BD.9060407@oracle.com> 7023931: PcDescCache::find_pc_desc should not write _last_pc_desc http://cr.openjdk.java.net/~phh/7023931/webrev.00/ The nmethod PcDescCache cached the last looked-up descriptor in a shared field called _last_pc_desc. This is fine in a single-threaded environment, but in a multi-threaded, multi-socket enviroment, frequent writes cause "block bouncing". I.e., the cache line containing _last_pc_desc is constantly being moved among the caches on different sockets. This process hurts stack walking performance, especially on multi-socket Intel systems. The fix is to eliminate _last_pc_desc and use _pcdescs[0] instead. The latter is written only once when it's added to the cache, avoiding the block bouncing issue. Use of _pcdescs[0] instead of _last_pc_desc means that there are slightly few "hits", but that doesn't seem to affect performance. Tested using SPECjvm2008's serial sub-benchmark and full nsks. Thanks, Paul From daniel.daugherty at oracle.com Fri Mar 11 12:37:36 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 11 Mar 2011 13:37:36 -0700 Subject: Pls review 7023931 (S) In-Reply-To: <4D7A82BD.9060407@oracle.com> References: <4D7A82BD.9060407@oracle.com> Message-ID: <4D7A8810.4040806@oracle.com> On 3/11/2011 1:14 PM, Paul Hohensee wrote: > 7023931: PcDescCache::find_pc_desc should not write _last_pc_desc > > http://cr.openjdk.java.net/~phh/7023931/webrev.00/ Thumbs up. src/share/vm/code/nmethod.hpp No comments. src/share/vm/code/nmethod.cpp No code comments. line 329 (new): Did you mean to change that ':' to '.' Dan > > The nmethod PcDescCache cached the last looked-up descriptor in a shared > field called _last_pc_desc. This is fine in a single-threaded > environment, > but in a multi-threaded, multi-socket enviroment, frequent writes cause > "block bouncing". I.e., the cache line containing _last_pc_desc is > constantly > being moved among the caches on different sockets. This process hurts > stack walking performance, especially on multi-socket Intel systems. > > The fix is to eliminate _last_pc_desc and use _pcdescs[0] instead. > The latter > is written only once when it's added to the cache, avoiding the block > bouncing issue. Use of _pcdescs[0] instead of _last_pc_desc means that > there are slightly few "hits", but that doesn't seem to affect > performance. > > Tested using SPECjvm2008's serial sub-benchmark and full nsks. > > Thanks, > > Paul > From paul.hohensee at oracle.com Fri Mar 11 12:51:22 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 11 Mar 2011 15:51:22 -0500 Subject: Pls review 7023931 (S) In-Reply-To: <4D7A8810.4040806@oracle.com> References: <4D7A82BD.9060407@oracle.com> <4D7A8810.4040806@oracle.com> Message-ID: <4D7A8B4A.4080309@oracle.com> Thanks, Dan, for the quick review. Yes, I meant to change it to ".". Seemed kinda wierd to be a ":" there. Paul On 3/11/11 3:37 PM, Daniel D. Daugherty wrote: > On 3/11/2011 1:14 PM, Paul Hohensee wrote: >> 7023931: PcDescCache::find_pc_desc should not write _last_pc_desc >> >> http://cr.openjdk.java.net/~phh/7023931/webrev.00/ > > Thumbs up. > > src/share/vm/code/nmethod.hpp > No comments. > > src/share/vm/code/nmethod.cpp > No code comments. > line 329 (new): Did you mean to change that ':' to '.' > > Dan > > >> >> The nmethod PcDescCache cached the last looked-up descriptor in a shared >> field called _last_pc_desc. This is fine in a single-threaded >> environment, >> but in a multi-threaded, multi-socket enviroment, frequent writes cause >> "block bouncing". I.e., the cache line containing _last_pc_desc is >> constantly >> being moved among the caches on different sockets. This process hurts >> stack walking performance, especially on multi-socket Intel systems. >> >> The fix is to eliminate _last_pc_desc and use _pcdescs[0] instead. >> The latter >> is written only once when it's added to the cache, avoiding the block >> bouncing issue. Use of _pcdescs[0] instead of _last_pc_desc means that >> there are slightly few "hits", but that doesn't seem to affect >> performance. >> >> Tested using SPECjvm2008's serial sub-benchmark and full nsks. >> >> Thanks, >> >> Paul >> From john.cuthbertson at oracle.com Fri Mar 11 17:34:50 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 11 Mar 2011 17:34:50 -0800 Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error Message-ID: <4D7ACDBA.7020003@oracle.com> Hi Everyone, I'm looking for a few of volunteers to review the changes that fix this assertion failure. The latest changes can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.3/ and include changes based upon earlier internal reviews. The earlier changes are also on cr.openjdk.java.net for reference. Background: The G1 garbage collector includes a concurrent marking algorithm that makes use of snapshot-at-the-beginning or SATB. With this algorithm the GC will mark all objects that are reachable at the start of marking; objects that are allocated since the start of marking are implicitly considered live. In order to populate the "snapshot" of the object graph that existed at the start of marking, G1 employs a write barrier. When an object is stored into another object's field the write-barrier records the previous value of that field as it was part of the "snapshot" and concurrent marking will trace the sub-graph that is reachable from this previous value. Unfortunately, in the presence of Reference objects, SATB might not be sufficient to mark a referent object as live. Consider that, at the start of marking, we have a weakly reachable object i.e. an object where the only pointer to that object. If the referent is obtained from the Reference object and stored to another object's field (making the referent now strongly reachable and hence live) the G1 write barrier will record the field's previous value but not the value of the referent. If the referent object is strongly reachable from some other object that will be traced by concurrent marking, _or_ there is a subsequent assignment to the field where we have written the referent (in which case we record the previous value - the referent - in an SATB buffer) then the referent will be marked live. Otherwise the referent will not be marked. That is the issue that was causing the failure in this CR. There was a Logger object that was only reachable through a WeakReference at the start of concurrent marking. During marking the Logger object is obtained from the WeakReference and stored into a field of a live object. The G1 write barrier recorded the previous value in the field (as it is part of the snapshot at the start of marking). Since there was no other assignment to the live object's field and there was no other strong reference to the Logger object, the Logger object was not marked. At the end of concurrent marking the Logger object was considered dead and the link between the WeakReference and the Logger was severed by clearing the referent field during reference processing. To solve this (entirely in Hotspot and causing a performance overhead for G1 only) it was decided that the best approach was to intrinsify the Reference.get() method in the JIT compilers and add new interpreter entry points so that the value in the referent field will be recorded in an SATB buffer by the G1 pre-barrier code. The changes for Zero and the C++ interpreters are place holder routines but should be straight forward to implement. None of the individual changes is large - they are just well distributed around the JVM. :) Testing: white box test; eyeballing the generated compiled and interpreter code; the failing Kitchensink big-app on x86 (32/64 bit), sparc (32/64 bit), Xint, Xcomp (client and server), with and without G1; the GC test suite with and without G1; and jprt. Thanks and regards, JohnC From john.r.rose at oracle.com Fri Mar 11 23:24:04 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 12 Mar 2011 07:24:04 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 11 new changesets Message-ID: <20110312072423.BC607470C3@hg.openjdk.java.net> Changeset: a8d643a4db47 Author: katleman Date: 2011-03-03 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a8d643a4db47 Added tag jdk7-b132 for changeset 0e531ab5ba04 ! .hgtags Changeset: 1b3a350709e4 Author: trims Date: 2011-03-03 15:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1b3a350709e4 Added tag hs21-b03 for changeset a8d643a4db47 ! .hgtags Changeset: 3e2b59ab2d07 Author: trims Date: 2011-03-04 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3e2b59ab2d07 Merge Changeset: 3c76374706ea Author: trims Date: 2011-03-04 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3c76374706ea 7024814: Bump the HS21 build number to 04 Summary: Update the HS21 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 9f44e9aad2d9 Author: coleenp Date: 2011-03-03 19:51 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9f44e9aad2d9 7022999: Can't build with FORCE_TIERED=0 Summary: Put UseFastLocking test under #ifdef COMPILER1 Reviewed-by: kvn, phh, never, dcubed ! src/share/vm/runtime/arguments.cpp Changeset: fbbeec6dad2d Author: coleenp Date: 2011-03-03 19:52 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fbbeec6dad2d 6512830: Error: assert(tag_at(which).is_unresolved_klass(), "Corrupted constant pool") Summary: Redefine classes copies the constant pool while the constant pool may be resolving strings or classes Reviewed-by: dcubed, dsamersoff, acorn ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: f767174aac14 Author: coleenp Date: 2011-03-03 19:53 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f767174aac14 7021653: Parfait issue in hotspot/src/share/vm/oops/methodDataOops.hpp Summary: Fix compilation error(s) Reviewed-by: kvn, phh, jcoomes, dholmes ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/runtime/os.cpp Changeset: dbad0519a1c4 Author: kamg Date: 2011-03-04 14:40 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dbad0519a1c4 6845426: non-static method with no args is called during the class initialization process Summary: Only call with ACC_STATIC for classfiles with version > 50 Reviewed-by: acorn, dholmes, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp Changeset: 0cd0a06d2535 Author: acorn Date: 2011-03-07 09:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0cd0a06d2535 Merge ! src/share/vm/runtime/arguments.cpp Changeset: df1347358fe6 Author: coleenp Date: 2011-03-07 16:03 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/df1347358fe6 7024584: Symbol printouts shouldnt be under PrintGCDetails Summary: Put symbol printing under Verbose and WizardMode so you can get this information if you really want it. Reviewed-by: phh, stefank, never, dholmes, jcoomes ! src/share/vm/classfile/symbolTable.cpp Changeset: 799d8ccf63cf Author: jrose Date: 2011-03-11 21:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/799d8ccf63cf Merge ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/arguments.cpp From john.r.rose at oracle.com Sat Mar 12 02:57:18 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 12 Mar 2011 10:57:18 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110312105724.75FA0470CB@hg.openjdk.java.net> Changeset: 72dee110246f Author: jrose Date: 2011-03-11 22:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/72dee110246f 6839872: remove implementation inheritance from JSR 292 APIs Summary: consolidate runtime support in java.dyn.MethodHandleNatives; include transitional compatibility logic Reviewed-by: twisti ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/globals.hpp Changeset: 8033953d67ff Author: jrose Date: 2011-03-11 22:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8033953d67ff 7012648: move JSR 292 to package java.lang.invoke and adjust names Summary: package and class renaming only; delete unused methods and classes Reviewed-by: twisti ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciCallSite.cpp ! src/share/vm/ci/ciCallSite.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/nativeLookup.cpp From vladimir.kozlov at oracle.com Mon Mar 14 14:54:12 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Mar 2011 14:54:12 -0700 Subject: Request for reviews (L): 7008866: Missing loop predicate for loop with multiple entries Message-ID: <4D7E8E84.6050303@oracle.com> It is the first of coming loop opts changes. No benchmarks performance improvement is expected since main loops in our benchmarks have predicates already. http://cr.openjdk.java.net/~kvn/7008866/webrev Fixed 7008866: Missing loop predicate for loop with multiple entries Synopsis is a little misleading since I don't mean irreducible loop entries (new code has a check to not add predicates to irreducible loops). I mean there could be several entry and backbranch paths to loop head. Currently loop predicates are generated when each backbranch path is parsed. Later in IdealLoopTree::beautify_loops() a merge region will be created if there are several entry paths separating predicates from the loop. As result those predicates will be removed. Add predicates when loop head bytecode is parsed instead of when back branch bytecode is parsed. All fall in paths will be merged already at this point and for back branches a new merge region is created. Add missing loop predicate when there are back branches to the method entry first bytecode. Add missing predicates for loops generated in Ideal graph, for example, for intrinsics. Rearrange some code to help next loop optimization changes. For example, in PhaseIdealLoop::is_counted_loop() move bailout checks before new ideal nodes are generated. Add new counted loop verification code. Perform local Ideal transformation for parallel induction variables replacement since in most cases they use the same stride (ratio == 1). In PhaseIdealLoop::split_thru_phi() don't move split node (or existing node returned by Identity()) inside a loop if all its uses are outside of this loop. Otherwise the node will be cloned for each outside use and this will mess up an external canonical counted loop if the node is loop's increment, for example. Preserve unswitch count when partial peel is executed and when a loop is converted to counted. Add debug flag TraceLoopOpts to show executed loop optimizations and also print whole loop tree at the beginning of each iteration of loop optimizations: PartialPeel Loop: N22966/N22965 Tested: ctw, nsk, jprt Ran refworkload on x86 - nor regression (or improvement). From christian.thalinger at oracle.com Tue Mar 15 06:35:47 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Mar 2011 14:35:47 +0100 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely Message-ID: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> http://cr.openjdk.java.net/~twisti/7022998/ 7022998: JSR 292 recursive method handle calls inline themselves infinitely Reviewed-by: Methods doing recursive method handle calls, like in JRuby's bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. This results in a huge method which hits compile thresholds and aborts inlining resulting in poor performance. The inlining logic needs to know about method handle call sites and search the call stack for recursive calls. This change also cleans up the PrintCompilation, PrintInlining and TraceTypeProfile output to be aligned since the tiered compilation changes added some additional output. src/share/vm/c1/c1_GraphBuilder.cpp src/share/vm/opto/bytecodeInfo.cpp src/share/vm/opto/doCall.cpp src/share/vm/runtime/sharedRuntime.cpp From christian.thalinger at oracle.com Tue Mar 15 07:19:02 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Mar 2011 15:19:02 +0100 Subject: Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc Message-ID: http://cr.openjdk.java.net/~twisti/7027232/ 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc Reviewed-by: After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on 32-bit SPARC. st_long uses STD on 32-bit SPARC and the LSW and MSW bits are not moved to the proper registers resulting in a wrong result. The fix is to use the correct registers for 32-bit big-endian and little-endian (just in case) SPARC. src/cpu/sparc/vm/methodHandles_sparc.cpp From vladimir.kozlov at oracle.com Tue Mar 15 09:57:40 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Mar 2011 09:57:40 -0700 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> Message-ID: <4D7F9A84.5080907@oracle.com> Christian, Instead of duplicating code in several places could you factor it in one method? sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. Main fix is fine. Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7022998/ > > 7022998: JSR 292 recursive method handle calls inline themselves infinitely > Reviewed-by: > > Methods doing recursive method handle calls, like in JRuby's > bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. > This results in a huge method which hits compile thresholds and aborts > inlining resulting in poor performance. > > The inlining logic needs to know about method handle call sites and > search the call stack for recursive calls. > > This change also cleans up the PrintCompilation, PrintInlining and > TraceTypeProfile output to be aligned since the tiered compilation > changes added some additional output. > > src/share/vm/c1/c1_GraphBuilder.cpp > src/share/vm/opto/bytecodeInfo.cpp > src/share/vm/opto/doCall.cpp > src/share/vm/runtime/sharedRuntime.cpp > From vladimir.kozlov at oracle.com Tue Mar 15 10:22:32 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Mar 2011 10:22:32 -0700 Subject: Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc In-Reply-To: References: Message-ID: <4D7FA058.4000208@oracle.com> Christian, We don't support little-endian SPARC, why add a code which will never be executed? On side note (RFE): we should officially drop v8 support (C2 does not support already, only C1). There are already several places where we use stx/ldx without check that it is v9 (yes, we still have an assert which is fine). Also std/ldd is emulated on modern SPARC and so is very slow. Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7027232/ > > 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc > Reviewed-by: > > After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on > 32-bit SPARC. st_long uses STD on 32-bit SPARC and the LSW and MSW > bits are not moved to the proper registers resulting in a wrong > result. > > The fix is to use the correct registers for 32-bit big-endian and > little-endian (just in case) SPARC. > > src/cpu/sparc/vm/methodHandles_sparc.cpp > From christian.thalinger at oracle.com Tue Mar 15 10:37:28 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Mar 2011 18:37:28 +0100 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <4D7F9A84.5080907@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> Message-ID: On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote: > Christian, > > Instead of duplicating code in several places could you factor it in one method? Actually I wanted to do that but I didn't know where to put the code. sharedRuntime? > > sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper? > > Main fix is fine. Okay. -- Christian > > Thanks, > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7022998/ >> 7022998: JSR 292 recursive method handle calls inline themselves infinitely >> Reviewed-by: >> Methods doing recursive method handle calls, like in JRuby's >> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. >> This results in a huge method which hits compile thresholds and aborts >> inlining resulting in poor performance. >> The inlining logic needs to know about method handle call sites and >> search the call stack for recursive calls. >> This change also cleans up the PrintCompilation, PrintInlining and >> TraceTypeProfile output to be aligned since the tiered compilation >> changes added some additional output. >> src/share/vm/c1/c1_GraphBuilder.cpp >> src/share/vm/opto/bytecodeInfo.cpp >> src/share/vm/opto/doCall.cpp >> src/share/vm/runtime/sharedRuntime.cpp From paul.hohensee at oracle.com Tue Mar 15 10:57:20 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 15 Mar 2011 13:57:20 -0400 Subject: Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc In-Reply-To: <4D7FA058.4000208@oracle.com> References: <4D7FA058.4000208@oracle.com> Message-ID: <4D7FA880.2060501@oracle.com> Would love to drop V8 support in C1, but as long as we ship the current version of Hotspot in jdk6, we can't do it. We're trying (and failing at the moment) to decommit from that, but imo we're going to be stuck with delivering the current jvm into the jdk6 train for a year at least. Paul On 3/15/11 1:22 PM, Vladimir Kozlov wrote: > Christian, > > We don't support little-endian SPARC, why add a code which will never > be executed? > > On side note (RFE): we should officially drop v8 support (C2 does not > support already, only C1). There are already several places where we > use stx/ldx without check that it is v9 (yes, we still have an assert > which is fine). Also std/ldd is emulated on modern SPARC and so is > very slow. > > Thanks, > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7027232/ >> >> 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc >> Reviewed-by: >> >> After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on >> 32-bit SPARC. st_long uses STD on 32-bit SPARC and the LSW and MSW >> bits are not moved to the proper registers resulting in a wrong >> result. >> >> The fix is to use the correct registers for 32-bit big-endian and >> little-endian (just in case) SPARC. >> >> src/cpu/sparc/vm/methodHandles_sparc.cpp >> From vladimir.kozlov at oracle.com Tue Mar 15 11:05:46 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Mar 2011 11:05:46 -0700 Subject: Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc In-Reply-To: <4D7FA058.4000208@oracle.com> References: <4D7FA058.4000208@oracle.com> Message-ID: <4D7FAA7A.7020207@oracle.com> Vladimir Kozlov wrote: > Christian, > > We don't support little-endian SPARC, why add a code which will never be > executed? > > On side note (RFE): we should officially drop v8 support (C2 does not > support already, only C1). There are already several places where we use > stx/ldx without check that it is v9 (yes, we still have an assert which > is fine). Also std/ldd is emulated on modern SPARC and so is very slow. Actually we already dropped v8 C1 compilation: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2bf529ef0adb The only problem is alignment of long values in 32 bit VM so we should be careful how we load and store them (note, java long fields are always aligned). Vladimir > > Thanks, > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7027232/ >> >> 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc >> Reviewed-by: >> >> After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on >> 32-bit SPARC. st_long uses STD on 32-bit SPARC and the LSW and MSW >> bits are not moved to the proper registers resulting in a wrong >> result. >> >> The fix is to use the correct registers for 32-bit big-endian and >> little-endian (just in case) SPARC. >> >> src/cpu/sparc/vm/methodHandles_sparc.cpp >> From vladimir.kozlov at oracle.com Tue Mar 15 11:41:00 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Mar 2011 11:41:00 -0700 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> Message-ID: <4D7FB2BC.409@oracle.com> Christian Thalinger wrote: > On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote: >> Christian, >> >> Instead of duplicating code in several places could you factor it in one method? > > Actually I wanted to do that but I didn't know where to put the code. sharedRuntime? May be a static method in CompileTask or AbstractCompiler since it is compilation information. > >> sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. > > Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper? I never saw nmethod::print_compilation using 'n' in output. But I assume it is the same. Vladimir > >> Main fix is fine. > > Okay. > > -- Christian > >> Thanks, >> Vladimir >> >> Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7022998/ >>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely >>> Reviewed-by: >>> Methods doing recursive method handle calls, like in JRuby's >>> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. >>> This results in a huge method which hits compile thresholds and aborts >>> inlining resulting in poor performance. >>> The inlining logic needs to know about method handle call sites and >>> search the call stack for recursive calls. >>> This change also cleans up the PrintCompilation, PrintInlining and >>> TraceTypeProfile output to be aligned since the tiered compilation >>> changes added some additional output. >>> src/share/vm/c1/c1_GraphBuilder.cpp >>> src/share/vm/opto/bytecodeInfo.cpp >>> src/share/vm/opto/doCall.cpp >>> src/share/vm/runtime/sharedRuntime.cpp > > From tom.rodriguez at oracle.com Wed Mar 16 10:35:02 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Mar 2011 10:35:02 -0700 Subject: ScavengeRootsInCode Message-ID: I was getting ready to finish my statics fields in Class changes when I hit a failure with jbb and CMS. I've tracked it down to a race in the machinery for updating oop relocations and the logic for making sure that a scavengable nmethod is only scanned once. During a scavenge an nmethod can be reached for scanning in two different ways, either as a live activation on some thread stack or during the scan of scavengeable nmethods. The scan of scavengeable nmethods does two things though. It does the oops_do for the nmethod and then it calls fix_oop_relocations to update the generated code to match the new oop values. The problem is that the scan of the thread stacks and the scan of the scavengable nmethods are performed concurrently so the stack scanning thread might claim the nmethod first but actually scan the nmethod after the call to fix_oop_relocations in the other thread, leaving the oops valid but the code stale. I think the logical place to move the fix_oop_relocations call is into nmethod::oops_do_marking_epilogue. Does this seem reasonable to anyone who understands the new nmethod scavenge code better than I do? It seems to work fine. Actually one thing I noticed is that the nmethod::oops_do_marking_prologue/epiloque logic is being called during full gcs which seems somewhat pointless to me since it mostly creates redundant work. Actually if it's really scanning the scavengable nmethods there then it's turning them into strong roots which is wrong. Only nmethods which are live on stack should be scanned as strong roots. Does anyone know why the test_set_oops_do_mark builds yet another linked list instead of just having a flag on the nmethod to indicate that it's claimed? It seems overly complicated. The contents of the list should be the same as the scavenge roots list and a simple flag would indicate whether it was marked or not. tom From y.s.ramakrishna at oracle.com Wed Mar 16 11:01:50 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Wed, 16 Mar 2011 11:01:50 -0700 Subject: ScavengeRootsInCode In-Reply-To: References: Message-ID: <4D80FB0E.8040205@oracle.com> Hi Tom -- A form of the strong-scanning problem for the nmethod scanning] code existed for a while, long preceding ScavengeRootsInCode, and was fixed a while ago so that the code-cache scanning did not inadvertently turn code-oops into strong refs. I can see that a parameter do_strong_roots_only now distinguishes the two types of scans: being true for the active nmethods on thread stacks scan and false for the code-cache scan of all nmethods, where the refs are treated weakly. I think that the list of scavengeable nmethod scanning should also be done weakly. I believe that would also take care of the synchronization issue that you ran into below, since there is in fact a synchronization barrier between the strong roots scan which must semantically strictly precede the weak scan. It would seem as though one should do the oop relocations during the second, weak scan? I don't know the answers to your other questions, but I am guessing John Rose would. -- ramki On 03/16/11 10:35, Tom Rodriguez wrote: > I was getting ready to finish my statics fields in Class changes when I hit a failure with jbb and CMS. I've tracked it down to a race in the machinery for updating oop relocations and the logic for making sure that a scavengable nmethod is only scanned once. During a scavenge an nmethod can be reached for scanning in two different ways, either as a live activation on some thread stack or during the scan of scavengeable nmethods. The scan of scavengeable nmethods does two things though. It does the oops_do for the nmethod and then it calls fix_oop_relocations to update the generated code to match the new oop values. The problem is that the scan of the thread stacks and the scan of the scavengable nmethods are performed concurrently so the stack scanning thread might claim the nmethod first but actually scan the nmethod after the call to fix_oop_relocations in the other thread, leaving the oops valid but the code stale. > > I think the logical place to move the fix_oop_relocations call is into nmethod::oops_do_marking_epilogue. Does this seem reasonable to anyone who understands the new nmethod scavenge code better than I do? It seems to work fine. > > Actually one thing I noticed is that the nmethod::oops_do_marking_prologue/epiloque logic is being called during full gcs which seems somewhat pointless to me since it mostly creates redundant work. Actually if it's really scanning the scavengable nmethods there then it's turning them into strong roots which is wrong. Only nmethods which are live on stack should be scanned as strong roots. > > Does anyone know why the test_set_oops_do_mark builds yet another linked list instead of just having a flag on the nmethod to indicate that it's claimed? It seems overly complicated. The contents of the list should be the same as the scavenge roots list and a simple flag would indicate whether it was marked or not. > > tom From tom.rodriguez at oracle.com Wed Mar 16 11:18:52 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Mar 2011 11:18:52 -0700 Subject: ScavengeRootsInCode In-Reply-To: <4D80FB0E.8040205@oracle.com> References: <4D80FB0E.8040205@oracle.com> Message-ID: <4D72F1C0-7AF0-4B40-9B68-AADF278F3DB1@oracle.com> On Mar 16, 2011, at 11:01 AM, Y. S. Ramakrishna wrote: > Hi Tom -- > > A form of the strong-scanning problem for the nmethod scanning] > code existed for a while, long preceding ScavengeRootsInCode, and > was fixed a while ago so that the code-cache scanning did not > inadvertently turn code-oops into strong refs. What issue do you mean? Not the MDO one? > I can see that > a parameter do_strong_roots_only now distinguishes the two types of scans: > being true for the active nmethods on thread stacks scan > and false for the code-cache scan of all nmethods, where the > refs are treated weakly. That flag only controls a very minor part of the weakness. Oops in the exception cache are weak because they can be dropped even if the nmethod is alive and those are the only oops that strong_roots_only controls. For all nmethods that don't have live activations, if any oop they reference isn't live after a strong scan then they will be unloaded. > I think that the list of scavengeable > nmethod scanning should also be done weakly. The list of scavengeable nmethods shouldn't be scanned at all during a full collection. The whole code cache is already scanned. By scanning it as strong root it can keep classes from being unloaded. Presumably over time nmethods will migrate off of the scavenge list but it's still incorrect. > I believe that would also take > care of the synchronization issue that you ran into below, > since there is in fact a synchronization > barrier between the strong roots scan which must semantically > strictly precede the weak scan. It would seem as though one > should do the oop relocations during the second, weak scan? There's no problem with full gc's because gc_epilogue fixes the oop relocations at the end. That also why scanning the scavengeable list is a total waste. Any work it does is a duplication of work that will be done anyway. tom > > I don't know the answers to your other questions, but I am guessing > John Rose would. > > -- ramki > > On 03/16/11 10:35, Tom Rodriguez wrote: >> I was getting ready to finish my statics fields in Class changes when I hit a failure with jbb and CMS. I've tracked it down to a race in the machinery for updating oop relocations and the logic for making sure that a scavengable nmethod is only scanned once. During a scavenge an nmethod can be reached for scanning in two different ways, either as a live activation on some thread stack or during the scan of scavengeable nmethods. The scan of scavengeable nmethods does two things though. It does the oops_do for the nmethod and then it calls fix_oop_relocations to update the generated code to match the new oop values. The problem is that the scan of the thread stacks and the scan of the scavengable nmethods are performed concurrently so the stack scanning thread might claim the nmethod first but actually scan the nmethod after the call to fix_oop_relocations in the other thread, leaving the oops valid but the code stale. >> I think the logical place to move the fix_oop_relocations call is into nmethod::oops_do_marking_epilogue. Does this seem reasonable to anyone who understands the new nmethod scavenge code better than I do? It seems to work fine. >> Actually one thing I noticed is that the nmethod::oops_do_marking_prologue/epiloque logic is being called during full gcs which seems somewhat pointless to me since it mostly creates redundant work. Actually if it's really scanning the scavengable nmethods there then it's turning them into strong roots which is wrong. Only nmethods which are live on stack should be scanned as strong roots. >> Does anyone know why the test_set_oops_do_mark builds yet another linked list instead of just having a flag on the nmethod to indicate that it's claimed? It seems overly complicated. The contents of the list should be the same as the scavenge roots list and a simple flag would indicate whether it was marked or not. >> tom From y.s.ramakrishna at oracle.com Wed Mar 16 11:33:31 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Wed, 16 Mar 2011 11:33:31 -0700 Subject: ScavengeRootsInCode In-Reply-To: <4D72F1C0-7AF0-4B40-9B68-AADF278F3DB1@oracle.com> References: <4D80FB0E.8040205@oracle.com> <4D72F1C0-7AF0-4B40-9B68-AADF278F3DB1@oracle.com> Message-ID: <4D81027B.5070808@oracle.com> On 03/16/11 11:18, Tom Rodriguez wrote: > On Mar 16, 2011, at 11:01 AM, Y. S. Ramakrishna wrote: > >> Hi Tom -- >> >> A form of the strong-scanning problem for the nmethod scanning] >> code existed for a while, long preceding ScavengeRootsInCode, and >> was fixed a while ago so that the code-cache scanning did not >> inadvertently turn code-oops into strong refs. > > What issue do you mean? Not the MDO one? No, i think this is older; lost in the fog of history, i guess, so "a while ago" probably gave the wrong impression. >> I can see that >> a parameter do_strong_roots_only now distinguishes the two types of scans: >> being true for the active nmethods on thread stacks scan >> and false for the code-cache scan of all nmethods, where the >> refs are treated weakly. > > That flag only controls a very minor part of the weakness. Oops in the exception cache are weak because they can be dropped even if the nmethod is alive and those are the only oops that strong_roots_only controls. For all nmethods that don't have live activations, if any oop they reference isn't live after a strong scan then they will be unloaded. > Sure, but see SharedHeap::process_weak_roots() where CodeCache::blobs_do() is called. Clearly any relocations (if i understand that term correctly) must strictly follow the strong marking, which should happen off of process_strong_roots(). >> I think that the list of scavengeable >> nmethod scanning should also be done weakly. > > The list of scavengeable nmethods shouldn't be scanned at all during a full collection. The whole code cache is already scanned. By scanning it as strong root it can keep classes from being unloaded. Presumably over time nmethods will migrate off of the scavenge list but it's still incorrect. > I agree. But I was getting (further above) on the sequencing problem that you brought up (at least as i understood it). >> I believe that would also take >> care of the synchronization issue that you ran into below, >> since there is in fact a synchronization >> barrier between the strong roots scan which must semantically >> strictly precede the weak scan. It would seem as though one >> should do the oop relocations during the second, weak scan? > > There's no problem with full gc's because gc_epilogue fixes the oop relocations at the end. That also why scanning the scavengeable list is a total waste. Any work it does is a duplication of work that will be done anyway. > Yes, duplicated work is bad. Doing it once at the right place is a good idea. Anyway, I should stop because I very briefly helped John Rose with this initially a long time ago, and the code has probably changed a lot since then and I haven't really kept up. -- ramki > tom > >> I don't know the answers to your other questions, but I am guessing >> John Rose would. >> >> -- ramki >> >> On 03/16/11 10:35, Tom Rodriguez wrote: >>> I was getting ready to finish my statics fields in Class changes when I hit a failure with jbb and CMS. I've tracked it down to a race in the machinery for updating oop relocations and the logic for making sure that a scavengable nmethod is only scanned once. During a scavenge an nmethod can be reached for scanning in two different ways, either as a live activation on some thread stack or during the scan of scavengeable nmethods. The scan of scavengeable nmethods does two things though. It does the oops_do for the nmethod and then it calls fix_oop_relocations to update the generated code to match the new oop values. The problem is that the scan of the thread stacks and the scan of the scavengable nmethods are performed concurrently so the stack scanning thread might claim the nmethod first but actually scan the nmethod after the call to fix_oop_relocations in the other thread, leaving the oops valid but the code stale. >>> I think the logical place to move the fix_oop_relocations call is into nmethod::oops_do_marking_epilogue. Does this seem reasonable to anyone who understands the new nmethod scavenge code better than I do? It seems to work fine. >>> Actually one thing I noticed is that the nmethod::oops_do_marking_prologue/epiloque logic is being called during full gcs which seems somewhat pointless to me since it mostly creates redundant work. Actually if it's really scanning the scavengable nmethods there then it's turning them into strong roots which is wrong. Only nmethods which are live on stack should be scanned as strong roots. >>> Does anyone know why the test_set_oops_do_mark builds yet another linked list instead of just having a flag on the nmethod to indicate that it's claimed? It seems overly complicated. The contents of the list should be the same as the scavenge roots list and a simple flag would indicate whether it was marked or not. >>> tom > From tom.deneau at amd.com Wed Mar 16 16:44:33 2011 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 16 Mar 2011 18:44:33 -0500 Subject: Review Request: Newer AMD Processor Prefetch Defaults Message-ID: <5EA33A275136844D843B73A29FB9A6A980304BFE@SAUSEXMBP01.amd.com> Hi all, Please review this patch which changes a flag default for some newer AMD processors. The webrev is at http://cr.openjdk.java.net/~tdeneau/bd-prefetch/webrev.01/ This new default has shown improvement across many workloads. I do not have a bug id for this. -- Tom Deneau, AMD From vladimir.kozlov at oracle.com Wed Mar 16 17:59:07 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Mar 2011 17:59:07 -0700 Subject: Review Request: Newer AMD Processor Prefetch Defaults In-Reply-To: <5EA33A275136844D843B73A29FB9A6A980304BFE@SAUSEXMBP01.amd.com> References: <5EA33A275136844D843B73A29FB9A6A980304BFE@SAUSEXMBP01.amd.com> Message-ID: <4D815CDB.8060703@oracle.com> Tom, I created next bug and your changes looks good. So hw prefetches become smart enough to replace sw prefetch? 7028394: Newer AMD Processor Prefetch Defaults Thanks, Vladimir Deneau, Tom wrote: > Hi all, > > Please review this patch which changes a flag default for some > newer AMD processors. The webrev is at > > http://cr.openjdk.java.net/~tdeneau/bd-prefetch/webrev.01/ > > This new default has shown improvement across many workloads. > I do not have a bug id for this. > > -- Tom Deneau, AMD > > From christian.thalinger at oracle.com Thu Mar 17 02:24:15 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Mar 2011 10:24:15 +0100 Subject: Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc In-Reply-To: <4D7FA058.4000208@oracle.com> References: <4D7FA058.4000208@oracle.com> Message-ID: <257D9E62-1674-4F0B-B9D3-E6F27962D97B@oracle.com> On Mar 15, 2011, at 6:22 PM, Vladimir Kozlov wrote: > Christian, > > We don't support little-endian SPARC, why add a code which will never be executed? I thought to be on the safe side if anyone ever wants to support it. Anyway, I removed it and updated the webrev. -- Christian > > On side note (RFE): we should officially drop v8 support (C2 does not support already, only C1). There are already several places where we use stx/ldx without check that it is v9 (yes, we still have an assert which is fine). Also std/ldd is emulated on modern SPARC and so is very slow. > > Thanks, > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7027232/ >> 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc >> Reviewed-by: >> After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on >> 32-bit SPARC. st_long uses STD on 32-bit SPARC and the LSW and MSW >> bits are not moved to the proper registers resulting in a wrong >> result. >> The fix is to use the correct registers for 32-bit big-endian and >> little-endian (just in case) SPARC. >> src/cpu/sparc/vm/methodHandles_sparc.cpp From christian.thalinger at oracle.com Thu Mar 17 04:25:12 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Mar 2011 12:25:12 +0100 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <4D7FB2BC.409@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> Message-ID: <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> On Mar 15, 2011, at 7:41 PM, Vladimir Kozlov wrote: > Christian Thalinger wrote: >> On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote: >>> Christian, >>> >>> Instead of duplicating code in several places could you factor it in one method? >> Actually I wanted to do that but I didn't know where to put the code. sharedRuntime? > > May be a static method in CompileTask or AbstractCompiler since it is compilation information. CompileTask seems suitable. I put a couple of static methods in there and the code is much cleaner now. I updated the webrev. > >>> sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. >> Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper? > > I never saw nmethod::print_compilation using 'n' in output. But I assume it is the same. So I'd say we just drop the "---" and use "n" as the indicator for a native method wrapper. -- Christian > > Vladimir > >>> Main fix is fine. >> Okay. >> -- Christian >>> Thanks, >>> Vladimir >>> >>> Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/7022998/ >>>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely >>>> Reviewed-by: >>>> Methods doing recursive method handle calls, like in JRuby's >>>> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. >>>> This results in a huge method which hits compile thresholds and aborts >>>> inlining resulting in poor performance. >>>> The inlining logic needs to know about method handle call sites and >>>> search the call stack for recursive calls. >>>> This change also cleans up the PrintCompilation, PrintInlining and >>>> TraceTypeProfile output to be aligned since the tiered compilation >>>> changes added some additional output. >>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>> src/share/vm/opto/bytecodeInfo.cpp >>>> src/share/vm/opto/doCall.cpp >>>> src/share/vm/runtime/sharedRuntime.cpp From vladimir.kozlov at oracle.com Thu Mar 17 09:56:34 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Mar 2011 09:56:34 -0700 Subject: Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc In-Reply-To: <257D9E62-1674-4F0B-B9D3-E6F27962D97B@oracle.com> References: <4D7FA058.4000208@oracle.com> <257D9E62-1674-4F0B-B9D3-E6F27962D97B@oracle.com> Message-ID: <4D823D42.5070307@oracle.com> Sorry for arguing about few lines but I think without renaming the code will be better (6 new lines instead of 7): + #ifdef _LP64 + __ ldsw(arg_lsw, O2_scratch); // Load LSW + #else + __ ldsw(arg_lsw, O3_scratch); // Load LSW + __ srlx(O3_scratch, BitsPerInt, O2_scratch)); // Move MSW value to lower 32-bits for STD + #endif __ st_long(O2_scratch, arg_msw); // Uses O2/O3 on !_LP64 Vladimir On 3/17/11 2:24 AM, Christian Thalinger wrote: > On Mar 15, 2011, at 6:22 PM, Vladimir Kozlov wrote: >> Christian, >> >> We don't support little-endian SPARC, why add a code which will never be executed? > > I thought to be on the safe side if anyone ever wants to support it. Anyway, I removed it and updated the webrev. > > -- Christian > >> >> On side note (RFE): we should officially drop v8 support (C2 does not support already, only C1). There are already several places where we use stx/ldx without check that it is v9 (yes, we still have an assert which is fine). Also std/ldd is emulated on modern SPARC and so is very slow. >> >> Thanks, >> Vladimir >> >> Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7027232/ >>> 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc >>> Reviewed-by: >>> After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on >>> 32-bit SPARC. st_long uses STD on 32-bit SPARC and the LSW and MSW >>> bits are not moved to the proper registers resulting in a wrong >>> result. >>> The fix is to use the correct registers for 32-bit big-endian and >>> little-endian (just in case) SPARC. >>> src/cpu/sparc/vm/methodHandles_sparc.cpp > > From tom.rodriguez at oracle.com Thu Mar 17 10:31:23 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 17 Mar 2011 10:31:23 -0700 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> Message-ID: On Mar 17, 2011, at 4:25 AM, Christian Thalinger wrote: > On Mar 15, 2011, at 7:41 PM, Vladimir Kozlov wrote: >> Christian Thalinger wrote: >>> On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote: >>>> Christian, >>>> >>>> Instead of duplicating code in several places could you factor it in one method? >>> Actually I wanted to do that but I didn't know where to put the code. sharedRuntime? >> >> May be a static method in CompileTask or AbstractCompiler since it is compilation information. > > CompileTask seems suitable. I put a couple of static methods in there and the code is much cleaner now. I updated the webrev. > >> >>>> sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. >>> Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper? >> >> I never saw nmethod::print_compilation using 'n' in output. But I assume it is the same. > > So I'd say we just drop the "---" and use "n" as the indicator for a native method wrapper. I'm not sure I understand this conversation. What --- are you dropping? n has always represented native wrappers. tom > > -- Christian > >> >> Vladimir >> >>>> Main fix is fine. >>> Okay. >>> -- Christian >>>> Thanks, >>>> Vladimir >>>> >>>> Christian Thalinger wrote: >>>>> http://cr.openjdk.java.net/~twisti/7022998/ >>>>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely >>>>> Reviewed-by: >>>>> Methods doing recursive method handle calls, like in JRuby's >>>>> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. >>>>> This results in a huge method which hits compile thresholds and aborts >>>>> inlining resulting in poor performance. >>>>> The inlining logic needs to know about method handle call sites and >>>>> search the call stack for recursive calls. >>>>> This change also cleans up the PrintCompilation, PrintInlining and >>>>> TraceTypeProfile output to be aligned since the tiered compilation >>>>> changes added some additional output. >>>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>>> src/share/vm/opto/bytecodeInfo.cpp >>>>> src/share/vm/opto/doCall.cpp >>>>> src/share/vm/runtime/sharedRuntime.cpp > > From tom.rodriguez at oracle.com Thu Mar 17 10:32:22 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 17 Mar 2011 10:32:22 -0700 Subject: Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc In-Reply-To: <257D9E62-1674-4F0B-B9D3-E6F27962D97B@oracle.com> References: <4D7FA058.4000208@oracle.com> <257D9E62-1674-4F0B-B9D3-E6F27962D97B@oracle.com> Message-ID: That looks ok. tom On Mar 17, 2011, at 2:24 AM, Christian Thalinger wrote: > On Mar 15, 2011, at 6:22 PM, Vladimir Kozlov wrote: >> Christian, >> >> We don't support little-endian SPARC, why add a code which will never be executed? > > I thought to be on the safe side if anyone ever wants to support it. Anyway, I removed it and updated the webrev. > > -- Christian > >> >> On side note (RFE): we should officially drop v8 support (C2 does not support already, only C1). There are already several places where we use stx/ldx without check that it is v9 (yes, we still have an assert which is fine). Also std/ldd is emulated on modern SPARC and so is very slow. >> >> Thanks, >> Vladimir >> >> Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7027232/ >>> 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc >>> Reviewed-by: >>> After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on >>> 32-bit SPARC. st_long uses STD on 32-bit SPARC and the LSW and MSW >>> bits are not moved to the proper registers resulting in a wrong >>> result. >>> The fix is to use the correct registers for 32-bit big-endian and >>> little-endian (just in case) SPARC. >>> src/cpu/sparc/vm/methodHandles_sparc.cpp > > From christian.thalinger at oracle.com Thu Mar 17 10:35:42 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Mar 2011 18:35:42 +0100 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> Message-ID: On Mar 17, 2011, at 6:31 PM, Tom Rodriguez wrote: > > On Mar 17, 2011, at 4:25 AM, Christian Thalinger wrote: > >> On Mar 15, 2011, at 7:41 PM, Vladimir Kozlov wrote: >>> Christian Thalinger wrote: >>>> On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote: >>>>> Christian, >>>>> >>>>> Instead of duplicating code in several places could you factor it in one method? >>>> Actually I wanted to do that but I didn't know where to put the code. sharedRuntime? >>> >>> May be a static method in CompileTask or AbstractCompiler since it is compilation information. >> >> CompileTask seems suitable. I put a couple of static methods in there and the code is much cleaner now. I updated the webrev. >> >>> >>>>> sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. >>>> Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper? >>> >>> I never saw nmethod::print_compilation using 'n' in output. But I assume it is the same. >> >> So I'd say we just drop the "---" and use "n" as the indicator for a native method wrapper. > > I'm not sure I understand this conversation. What --- are you dropping? Vladimir means the "---" which (I think) were originally a placeholder for the compile id. > n has always represented native wrappers. True. I missed that. -- Christian > > tom > >> >> -- Christian >> >>> >>> Vladimir >>> >>>>> Main fix is fine. >>>> Okay. >>>> -- Christian >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Christian Thalinger wrote: >>>>>> http://cr.openjdk.java.net/~twisti/7022998/ >>>>>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely >>>>>> Reviewed-by: >>>>>> Methods doing recursive method handle calls, like in JRuby's >>>>>> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. >>>>>> This results in a huge method which hits compile thresholds and aborts >>>>>> inlining resulting in poor performance. >>>>>> The inlining logic needs to know about method handle call sites and >>>>>> search the call stack for recursive calls. >>>>>> This change also cleans up the PrintCompilation, PrintInlining and >>>>>> TraceTypeProfile output to be aligned since the tiered compilation >>>>>> changes added some additional output. >>>>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>>>> src/share/vm/opto/bytecodeInfo.cpp >>>>>> src/share/vm/opto/doCall.cpp >>>>>> src/share/vm/runtime/sharedRuntime.cpp From christian.thalinger at oracle.com Thu Mar 17 10:36:33 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Mar 2011 18:36:33 +0100 Subject: Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc In-Reply-To: References: <4D7FA058.4000208@oracle.com> <257D9E62-1674-4F0B-B9D3-E6F27962D97B@oracle.com> Message-ID: On Mar 17, 2011, at 6:32 PM, Tom Rodriguez wrote: > That looks ok. Thank you, Tom. -- Christian > > tom > > On Mar 17, 2011, at 2:24 AM, Christian Thalinger wrote: > >> On Mar 15, 2011, at 6:22 PM, Vladimir Kozlov wrote: >>> Christian, >>> >>> We don't support little-endian SPARC, why add a code which will never be executed? >> >> I thought to be on the safe side if anyone ever wants to support it. Anyway, I removed it and updated the webrev. >> >> -- Christian >> >>> >>> On side note (RFE): we should officially drop v8 support (C2 does not support already, only C1). There are already several places where we use stx/ldx without check that it is v9 (yes, we still have an assert which is fine). Also std/ldd is emulated on modern SPARC and so is very slow. >>> >>> Thanks, >>> Vladimir >>> >>> Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/7027232/ >>>> 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc >>>> Reviewed-by: >>>> After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on >>>> 32-bit SPARC. st_long uses STD on 32-bit SPARC and the LSW and MSW >>>> bits are not moved to the proper registers resulting in a wrong >>>> result. >>>> The fix is to use the correct registers for 32-bit big-endian and >>>> little-endian (just in case) SPARC. >>>> src/cpu/sparc/vm/methodHandles_sparc.cpp From tom.rodriguez at oracle.com Thu Mar 17 10:36:42 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 17 Mar 2011 10:36:42 -0700 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> Message-ID: <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> On Mar 17, 2011, at 4:25 AM, Christian Thalinger wrote: > On Mar 15, 2011, at 7:41 PM, Vladimir Kozlov wrote: >> Christian Thalinger wrote: >>> On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote: >>>> Christian, >>>> >>>> Instead of duplicating code in several places could you factor it in one method? >>> Actually I wanted to do that but I didn't know where to put the code. sharedRuntime? >> >> May be a static method in CompileTask or AbstractCompiler since it is compilation information. > > CompileTask seems suitable. I put a couple of static methods in there and the code is much cleaner now. I updated the webrev. That looks better. Can bci really be -1 here? + if (bci != -1) st->print("@ %d ", bci); + else st->print("@ ? "); Shouldn't that just be an assert that bci != -1? tom > >> >>>> sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. >>> Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper? >> >> I never saw nmethod::print_compilation using 'n' in output. But I assume it is the same. > > So I'd say we just drop the "---" and use "n" as the indicator for a native method wrapper. > > -- Christian > >> >> Vladimir >> >>>> Main fix is fine. >>> Okay. >>> -- Christian >>>> Thanks, >>>> Vladimir >>>> >>>> Christian Thalinger wrote: >>>>> http://cr.openjdk.java.net/~twisti/7022998/ >>>>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely >>>>> Reviewed-by: >>>>> Methods doing recursive method handle calls, like in JRuby's >>>>> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. >>>>> This results in a huge method which hits compile thresholds and aborts >>>>> inlining resulting in poor performance. >>>>> The inlining logic needs to know about method handle call sites and >>>>> search the call stack for recursive calls. >>>>> This change also cleans up the PrintCompilation, PrintInlining and >>>>> TraceTypeProfile output to be aligned since the tiered compilation >>>>> changes added some additional output. >>>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>>> src/share/vm/opto/bytecodeInfo.cpp >>>>> src/share/vm/opto/doCall.cpp >>>>> src/share/vm/runtime/sharedRuntime.cpp > > From tom.rodriguez at oracle.com Thu Mar 17 10:44:08 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 17 Mar 2011 10:44:08 -0700 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> Message-ID: <81AA5242-435B-42AF-A8AB-4E18566D0DAC@oracle.com> On Mar 17, 2011, at 10:35 AM, Christian Thalinger wrote: > On Mar 17, 2011, at 6:31 PM, Tom Rodriguez wrote: >> >> On Mar 17, 2011, at 4:25 AM, Christian Thalinger wrote: >> >>> On Mar 15, 2011, at 7:41 PM, Vladimir Kozlov wrote: >>>> Christian Thalinger wrote: >>>>> On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote: >>>>>> Christian, >>>>>> >>>>>> Instead of duplicating code in several places could you factor it in one method? >>>>> Actually I wanted to do that but I didn't know where to put the code. sharedRuntime? >>>> >>>> May be a static method in CompileTask or AbstractCompiler since it is compilation information. >>> >>> CompileTask seems suitable. I put a couple of static methods in there and the code is much cleaner now. I updated the webrev. >>> >>>> >>>>>> sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. >>>>> Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper? >>>> >>>> I never saw nmethod::print_compilation using 'n' in output. But I assume it is the same. >>> >>> So I'd say we just drop the "---" and use "n" as the indicator for a native method wrapper. >> >> I'm not sure I understand this conversation. What --- are you dropping? > > Vladimir means the "---" which (I think) were originally a placeholder for the compile id. Oh, right. It would be nice if the formatting of the native wrapper wasn't so different from the regular compiles. We could actually assign them compile ids. It could be passed into create_native_wrapper and generated using assign_compile_id. That would also fix the weird usage of print_inlining to describe native wrappers in your webrev that I hadn't noticed before. You'd probably want to tweak the native wrapper nmethod constructor to take a compile_id again too. This change is spiraling a bit but I think it's a good cleanup of the output. tom > >> n has always represented native wrappers. > > True. I missed that. > > -- Christian > >> >> tom >> >>> >>> -- Christian >>> >>>> >>>> Vladimir >>>> >>>>>> Main fix is fine. >>>>> Okay. >>>>> -- Christian >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Christian Thalinger wrote: >>>>>>> http://cr.openjdk.java.net/~twisti/7022998/ >>>>>>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely >>>>>>> Reviewed-by: >>>>>>> Methods doing recursive method handle calls, like in JRuby's >>>>>>> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. >>>>>>> This results in a huge method which hits compile thresholds and aborts >>>>>>> inlining resulting in poor performance. >>>>>>> The inlining logic needs to know about method handle call sites and >>>>>>> search the call stack for recursive calls. >>>>>>> This change also cleans up the PrintCompilation, PrintInlining and >>>>>>> TraceTypeProfile output to be aligned since the tiered compilation >>>>>>> changes added some additional output. >>>>>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>>>>> src/share/vm/opto/bytecodeInfo.cpp >>>>>>> src/share/vm/opto/doCall.cpp >>>>>>> src/share/vm/runtime/sharedRuntime.cpp > > From christian.thalinger at oracle.com Thu Mar 17 10:46:54 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Mar 2011 18:46:54 +0100 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> Message-ID: <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> On Mar 17, 2011, at 6:36 PM, Tom Rodriguez wrote: > > On Mar 17, 2011, at 4:25 AM, Christian Thalinger wrote: > >> On Mar 15, 2011, at 7:41 PM, Vladimir Kozlov wrote: >>> Christian Thalinger wrote: >>>> On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote: >>>>> Christian, >>>>> >>>>> Instead of duplicating code in several places could you factor it in one method? >>>> Actually I wanted to do that but I didn't know where to put the code. sharedRuntime? >>> >>> May be a static method in CompileTask or AbstractCompiler since it is compilation information. >> >> CompileTask seems suitable. I put a couple of static methods in there and the code is much cleaner now. I updated the webrev. > > That looks better. Can bci really be -1 here? > > + if (bci != -1) st->print("@ %d ", bci); > + else st->print("@ ? "); > > Shouldn't that just be an assert that bci != -1? I use bci == -1 for the native wrapper case. I wanted to print something that indicates that the wrapper is "inlined", like: 1998 9 java.lang.String::indexOf (166 bytes) n @ ? java.lang.System::arraycopy (static) Is there a way to get the bci for such a wrapper? -- Christian > > tom > >> >>> >>>>> sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. >>>> Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper? >>> >>> I never saw nmethod::print_compilation using 'n' in output. But I assume it is the same. >> >> So I'd say we just drop the "---" and use "n" as the indicator for a native method wrapper. >> >> -- Christian >> >>> >>> Vladimir >>> >>>>> Main fix is fine. >>>> Okay. >>>> -- Christian >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Christian Thalinger wrote: >>>>>> http://cr.openjdk.java.net/~twisti/7022998/ >>>>>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely >>>>>> Reviewed-by: >>>>>> Methods doing recursive method handle calls, like in JRuby's >>>>>> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. >>>>>> This results in a huge method which hits compile thresholds and aborts >>>>>> inlining resulting in poor performance. >>>>>> The inlining logic needs to know about method handle call sites and >>>>>> search the call stack for recursive calls. >>>>>> This change also cleans up the PrintCompilation, PrintInlining and >>>>>> TraceTypeProfile output to be aligned since the tiered compilation >>>>>> changes added some additional output. >>>>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>>>> src/share/vm/opto/bytecodeInfo.cpp >>>>>> src/share/vm/opto/doCall.cpp >>>>>> src/share/vm/runtime/sharedRuntime.cpp From tom.rodriguez at oracle.com Thu Mar 17 10:53:21 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 17 Mar 2011 10:53:21 -0700 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> Message-ID: On Mar 17, 2011, at 10:46 AM, Christian Thalinger wrote: > On Mar 17, 2011, at 6:36 PM, Tom Rodriguez wrote: >> >> On Mar 17, 2011, at 4:25 AM, Christian Thalinger wrote: >> >>> On Mar 15, 2011, at 7:41 PM, Vladimir Kozlov wrote: >>>> Christian Thalinger wrote: >>>>> On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote: >>>>>> Christian, >>>>>> >>>>>> Instead of duplicating code in several places could you factor it in one method? >>>>> Actually I wanted to do that but I didn't know where to put the code. sharedRuntime? >>>> >>>> May be a static method in CompileTask or AbstractCompiler since it is compilation information. >>> >>> CompileTask seems suitable. I put a couple of static methods in there and the code is much cleaner now. I updated the webrev. >> >> That looks better. Can bci really be -1 here? >> >> + if (bci != -1) st->print("@ %d ", bci); >> + else st->print("@ ? "); >> >> Shouldn't that just be an assert that bci != -1? > > I use bci == -1 for the native wrapper case. I wanted to print something that indicates that the wrapper is "inlined", like: > > 1998 9 java.lang.String::indexOf (166 bytes) > n @ ? java.lang.System::arraycopy (static) > > Is there a way to get the bci for such a wrapper? Native wrappers are never inlined. That would be a intrinsic in the output you show above. Intrinsic inlining should always have a bci though. tom > > -- Christian > >> >> tom >> >>> >>>> >>>>>> sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. >>>>> Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper? >>>> >>>> I never saw nmethod::print_compilation using 'n' in output. But I assume it is the same. >>> >>> So I'd say we just drop the "---" and use "n" as the indicator for a native method wrapper. >>> >>> -- Christian >>> >>>> >>>> Vladimir >>>> >>>>>> Main fix is fine. >>>>> Okay. >>>>> -- Christian >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Christian Thalinger wrote: >>>>>>> http://cr.openjdk.java.net/~twisti/7022998/ >>>>>>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely >>>>>>> Reviewed-by: >>>>>>> Methods doing recursive method handle calls, like in JRuby's >>>>>>> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. >>>>>>> This results in a huge method which hits compile thresholds and aborts >>>>>>> inlining resulting in poor performance. >>>>>>> The inlining logic needs to know about method handle call sites and >>>>>>> search the call stack for recursive calls. >>>>>>> This change also cleans up the PrintCompilation, PrintInlining and >>>>>>> TraceTypeProfile output to be aligned since the tiered compilation >>>>>>> changes added some additional output. >>>>>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>>>>> src/share/vm/opto/bytecodeInfo.cpp >>>>>>> src/share/vm/opto/doCall.cpp >>>>>>> src/share/vm/runtime/sharedRuntime.cpp > > From christian.thalinger at oracle.com Thu Mar 17 11:00:05 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Mar 2011 19:00:05 +0100 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> Message-ID: <26256988-B1B9-4D29-8AA1-050F3D7A9147@oracle.com> On Mar 17, 2011, at 6:53 PM, Tom Rodriguez wrote: > > On Mar 17, 2011, at 10:46 AM, Christian Thalinger wrote: > >> On Mar 17, 2011, at 6:36 PM, Tom Rodriguez wrote: >>> >>> On Mar 17, 2011, at 4:25 AM, Christian Thalinger wrote: >>> >>>> On Mar 15, 2011, at 7:41 PM, Vladimir Kozlov wrote: >>>>> Christian Thalinger wrote: >>>>>> On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote: >>>>>>> Christian, >>>>>>> >>>>>>> Instead of duplicating code in several places could you factor it in one method? >>>>>> Actually I wanted to do that but I didn't know where to put the code. sharedRuntime? >>>>> >>>>> May be a static method in CompileTask or AbstractCompiler since it is compilation information. >>>> >>>> CompileTask seems suitable. I put a couple of static methods in there and the code is much cleaner now. I updated the webrev. >>> >>> That looks better. Can bci really be -1 here? >>> >>> + if (bci != -1) st->print("@ %d ", bci); >>> + else st->print("@ ? "); >>> >>> Shouldn't that just be an assert that bci != -1? >> >> I use bci == -1 for the native wrapper case. I wanted to print something that indicates that the wrapper is "inlined", like: >> >> 1998 9 java.lang.String::indexOf (166 bytes) >> n @ ? java.lang.System::arraycopy (static) >> >> Is there a way to get the bci for such a wrapper? > > Native wrappers are never inlined. That would be a intrinsic in the output you show above. Intrinsic inlining should always have a bci though. Ahh, right, I mixed them. When I'm already at it, should I change the intrinsic output too: Inlining intrinsic _min at bci:67 in sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (489 bytes) to fit into the inlining tree? -- Christian > > tom > >> >> -- Christian >> >>> >>> tom >>> >>>> >>>>> >>>>>>> sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. >>>>>> Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper? >>>>> >>>>> I never saw nmethod::print_compilation using 'n' in output. But I assume it is the same. >>>> >>>> So I'd say we just drop the "---" and use "n" as the indicator for a native method wrapper. >>>> >>>> -- Christian >>>> >>>>> >>>>> Vladimir >>>>> >>>>>>> Main fix is fine. >>>>>> Okay. >>>>>> -- Christian >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> Christian Thalinger wrote: >>>>>>>> http://cr.openjdk.java.net/~twisti/7022998/ >>>>>>>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely >>>>>>>> Reviewed-by: >>>>>>>> Methods doing recursive method handle calls, like in JRuby's >>>>>>>> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. >>>>>>>> This results in a huge method which hits compile thresholds and aborts >>>>>>>> inlining resulting in poor performance. >>>>>>>> The inlining logic needs to know about method handle call sites and >>>>>>>> search the call stack for recursive calls. >>>>>>>> This change also cleans up the PrintCompilation, PrintInlining and >>>>>>>> TraceTypeProfile output to be aligned since the tiered compilation >>>>>>>> changes added some additional output. >>>>>>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>>>>>> src/share/vm/opto/bytecodeInfo.cpp >>>>>>>> src/share/vm/opto/doCall.cpp >>>>>>>> src/share/vm/runtime/sharedRuntime.cpp From tom.rodriguez at oracle.com Thu Mar 17 11:19:31 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 17 Mar 2011 11:19:31 -0700 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <26256988-B1B9-4D29-8AA1-050F3D7A9147@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> <26256988-B1B9-4D29-8AA1-050F3D7A9147@oracle.com> Message-ID: <8822AEC2-212C-4ED1-BE34-A3B42E51BB27@oracle.com> On Mar 17, 2011, at 11:00 AM, Christian Thalinger wrote: > On Mar 17, 2011, at 6:53 PM, Tom Rodriguez wrote: >> >> On Mar 17, 2011, at 10:46 AM, Christian Thalinger wrote: >> >>> On Mar 17, 2011, at 6:36 PM, Tom Rodriguez wrote: >>>> >>>> On Mar 17, 2011, at 4:25 AM, Christian Thalinger wrote: >>>> >>>>> On Mar 15, 2011, at 7:41 PM, Vladimir Kozlov wrote: >>>>>> Christian Thalinger wrote: >>>>>>> On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote: >>>>>>>> Christian, >>>>>>>> >>>>>>>> Instead of duplicating code in several places could you factor it in one method? >>>>>>> Actually I wanted to do that but I didn't know where to put the code. sharedRuntime? >>>>>> >>>>>> May be a static method in CompileTask or AbstractCompiler since it is compilation information. >>>>> >>>>> CompileTask seems suitable. I put a couple of static methods in there and the code is much cleaner now. I updated the webrev. >>>> >>>> That looks better. Can bci really be -1 here? >>>> >>>> + if (bci != -1) st->print("@ %d ", bci); >>>> + else st->print("@ ? "); >>>> >>>> Shouldn't that just be an assert that bci != -1? >>> >>> I use bci == -1 for the native wrapper case. I wanted to print something that indicates that the wrapper is "inlined", like: >>> >>> 1998 9 java.lang.String::indexOf (166 bytes) >>> n @ ? java.lang.System::arraycopy (static) >>> >>> Is there a way to get the bci for such a wrapper? >> >> Native wrappers are never inlined. That would be a intrinsic in the output you show above. Intrinsic inlining should always have a bci though. > > Ahh, right, I mixed them. When I'm already at it, should I change the intrinsic output too: > > Inlining intrinsic _min at bci:67 in sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (489 bytes) > > to fit into the inlining tree? I wouldn't mind that. Something like the normal output but with "(intrinsic)" at the end? tom > > -- Christian > >> >> tom >> >>> >>> -- Christian >>> >>>> >>>> tom >>>> >>>>> >>>>>> >>>>>>>> sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. >>>>>>> Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper? >>>>>> >>>>>> I never saw nmethod::print_compilation using 'n' in output. But I assume it is the same. >>>>> >>>>> So I'd say we just drop the "---" and use "n" as the indicator for a native method wrapper. >>>>> >>>>> -- Christian >>>>> >>>>>> >>>>>> Vladimir >>>>>> >>>>>>>> Main fix is fine. >>>>>>> Okay. >>>>>>> -- Christian >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Christian Thalinger wrote: >>>>>>>>> http://cr.openjdk.java.net/~twisti/7022998/ >>>>>>>>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely >>>>>>>>> Reviewed-by: >>>>>>>>> Methods doing recursive method handle calls, like in JRuby's >>>>>>>>> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. >>>>>>>>> This results in a huge method which hits compile thresholds and aborts >>>>>>>>> inlining resulting in poor performance. >>>>>>>>> The inlining logic needs to know about method handle call sites and >>>>>>>>> search the call stack for recursive calls. >>>>>>>>> This change also cleans up the PrintCompilation, PrintInlining and >>>>>>>>> TraceTypeProfile output to be aligned since the tiered compilation >>>>>>>>> changes added some additional output. >>>>>>>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>>>>>>> src/share/vm/opto/bytecodeInfo.cpp >>>>>>>>> src/share/vm/opto/doCall.cpp >>>>>>>>> src/share/vm/runtime/sharedRuntime.cpp > > From vladimir.kozlov at oracle.com Thu Mar 17 11:38:07 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Mar 2011 11:38:07 -0700 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> Message-ID: <4D82550F.9050803@oracle.com> These methods names are confusing since they print only head of compilation lines and not method names. Could you add "_prefix", "_head" or something? I am not sure what you are doing with trace_type_profile(). Why you not print indent in trace_type_profile() with PrintOptoInlining? It did before. May be we should deprecate PrintOpto and PrintOptoInlining and use only PrintCompilation and PrintInlining so we do not need this special code. Vladimir Christian Thalinger wrote: > On Mar 15, 2011, at 7:41 PM, Vladimir Kozlov wrote: >> Christian Thalinger wrote: >>> On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote: >>>> Christian, >>>> >>>> Instead of duplicating code in several places could you factor it in one method? >>> Actually I wanted to do that but I didn't know where to put the code. sharedRuntime? >> May be a static method in CompileTask or AbstractCompiler since it is compilation information. > > CompileTask seems suitable. I put a couple of static methods in there and the code is much cleaner now. I updated the webrev. > >>>> sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation. >>> Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper? >> I never saw nmethod::print_compilation using 'n' in output. But I assume it is the same. > > So I'd say we just drop the "---" and use "n" as the indicator for a native method wrapper. > > -- Christian > >> Vladimir >> >>>> Main fix is fine. >>> Okay. >>> -- Christian >>>> Thanks, >>>> Vladimir >>>> >>>> Christian Thalinger wrote: >>>>> http://cr.openjdk.java.net/~twisti/7022998/ >>>>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely >>>>> Reviewed-by: >>>>> Methods doing recursive method handle calls, like in JRuby's >>>>> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely. >>>>> This results in a huge method which hits compile thresholds and aborts >>>>> inlining resulting in poor performance. >>>>> The inlining logic needs to know about method handle call sites and >>>>> search the call stack for recursive calls. >>>>> This change also cleans up the PrintCompilation, PrintInlining and >>>>> TraceTypeProfile output to be aligned since the tiered compilation >>>>> changes added some additional output. >>>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>>> src/share/vm/opto/bytecodeInfo.cpp >>>>> src/share/vm/opto/doCall.cpp >>>>> src/share/vm/runtime/sharedRuntime.cpp > > From tom.deneau at amd.com Thu Mar 17 13:04:33 2011 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 17 Mar 2011 15:04:33 -0500 Subject: Review Request: Newer AMD Processor Prefetch Defaults In-Reply-To: <4D815CDB.8060703@oracle.com> References: <5EA33A275136844D843B73A29FB9A6A980304BFE@SAUSEXMBP01.amd.com> <4D815CDB.8060703@oracle.com> Message-ID: <5EA33A275136844D843B73A29FB9A6A980304F34@SAUSEXMBP01.amd.com> Vladimir -- Yes, the hw prefetcher is more advanced. In the future we may find a sw prefetch strategy that adds something to the hw prefetcher but for now we do not have one and we wanted to make sure our current best default gets in for the April JDK7 hotspot snapshot freeze. On the topic of bug numbers, there will definitely be some other default flag changes (not related to prefetch). Our plan was to submit each one functional area separately. -- Tom -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, March 16, 2011 7:59 PM To: Deneau, Tom Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: Review Request: Newer AMD Processor Prefetch Defaults Tom, I created next bug and your changes looks good. So hw prefetches become smart enough to replace sw prefetch? 7028394: Newer AMD Processor Prefetch Defaults Thanks, Vladimir Deneau, Tom wrote: > Hi all, > > Please review this patch which changes a flag default for some > newer AMD processors. The webrev is at > > http://cr.openjdk.java.net/~tdeneau/bd-prefetch/webrev.01/ > > This new default has shown improvement across many workloads. > I do not have a bug id for this. > > -- Tom Deneau, AMD > > From vladimir.kozlov at oracle.com Thu Mar 17 13:32:37 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Mar 2011 13:32:37 -0700 Subject: Review Request: Newer AMD Processor Prefetch Defaults In-Reply-To: <5EA33A275136844D843B73A29FB9A6A980304F34@SAUSEXMBP01.amd.com> References: <5EA33A275136844D843B73A29FB9A6A980304BFE@SAUSEXMBP01.amd.com> <4D815CDB.8060703@oracle.com> <5EA33A275136844D843B73A29FB9A6A980304F34@SAUSEXMBP01.amd.com> Message-ID: <4D826FE5.9030600@oracle.com> Thank you, Tom I put your changes into queue to push into hotspot-comp/hotspot. Vladimir Deneau, Tom wrote: > Vladimir -- > > Yes, the hw prefetcher is more advanced. In the future we may find a sw > prefetch strategy that adds something to the hw prefetcher but for now we > do not have one and we wanted to make sure our current best default gets in > for the April JDK7 hotspot snapshot freeze. > > On the topic of bug numbers, there will definitely be some other default > flag changes (not related to prefetch). Our plan was to submit each one > functional area separately. > > -- Tom > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, March 16, 2011 7:59 PM > To: Deneau, Tom > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: Review Request: Newer AMD Processor Prefetch Defaults > > Tom, > > I created next bug and your changes looks good. So hw prefetches become smart > enough to replace sw prefetch? > > 7028394: Newer AMD Processor Prefetch Defaults > > Thanks, > Vladimir > > Deneau, Tom wrote: >> Hi all, >> >> Please review this patch which changes a flag default for some >> newer AMD processors. The webrev is at >> >> http://cr.openjdk.java.net/~tdeneau/bd-prefetch/webrev.01/ >> >> This new default has shown improvement across many workloads. >> I do not have a bug id for this. >> >> -- Tom Deneau, AMD >> >> > > From vladimir.kozlov at oracle.com Thu Mar 17 16:42:37 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 17 Mar 2011 23:42:37 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7028394: Newer AMD Processor Prefetch Defaults Message-ID: <20110317234241.12F4A47242@hg.openjdk.java.net> Changeset: 82de9bd880e3 Author: kvn Date: 2011-03-17 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/82de9bd880e3 7028394: Newer AMD Processor Prefetch Defaults Summary: This new default has shown improvement across many workloads. Reviewed-by: kvn Contributed-by: tom.deneau at amd.com ! src/cpu/x86/vm/vm_version_x86.cpp From john.r.rose at oracle.com Thu Mar 17 18:18:31 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 17 Mar 2011 18:18:31 -0700 Subject: review request (XS): 7011865: JSR 292 CTW fails: !THREAD->is_Compiler_thread() failed: Can not load classes with the Compiler thre Message-ID: <014D0E4B-AB97-404D-B47C-ACB7CC0564CE@oracle.com> http://cr.openjdk.java.net/~jrose/7011865/webrev.00/ This shows up in CompileTheWorld (stress testing). It backs off from an initialization path introduced in this change set: 6964498: JSR 292 invokedynamic sites need local bootstrap methods Thanks, -- John From vladimir.kozlov at oracle.com Thu Mar 17 18:21:54 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Mar 2011 18:21:54 -0700 Subject: review request (XS): 7011865: JSR 292 CTW fails: !THREAD->is_Compiler_thread() failed: Can not load classes with the Compiler thre In-Reply-To: <014D0E4B-AB97-404D-B47C-ACB7CC0564CE@oracle.com> References: <014D0E4B-AB97-404D-B47C-ACB7CC0564CE@oracle.com> Message-ID: <4D82B3B2.30207@oracle.com> Good. Vladimir John Rose wrote: > http://cr.openjdk.java.net/~jrose/7011865/webrev.00/ > > This shows up in CompileTheWorld (stress testing). It backs off from an initialization path introduced in this change set: > 6964498: JSR 292 invokedynamic sites need local bootstrap methods > > Thanks, > -- John From tom.rodriguez at oracle.com Thu Mar 17 18:24:50 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 17 Mar 2011 18:24:50 -0700 Subject: review request (XS): 7011865: JSR 292 CTW fails: !THREAD->is_Compiler_thread() failed: Can not load classes with the Compiler thre In-Reply-To: <014D0E4B-AB97-404D-B47C-ACB7CC0564CE@oracle.com> References: <014D0E4B-AB97-404D-B47C-ACB7CC0564CE@oracle.com> Message-ID: <5E439E07-BF7F-4303-9DEA-8F49BAE76728@oracle.com> Looks good. tom On Mar 17, 2011, at 6:18 PM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/7011865/webrev.00/ > > This shows up in CompileTheWorld (stress testing). It backs off from an initialization path introduced in this change set: > 6964498: JSR 292 invokedynamic sites need local bootstrap methods > > Thanks, > -- John From john.r.rose at oracle.com Thu Mar 17 18:25:29 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 17 Mar 2011 18:25:29 -0700 Subject: review request (XS): 7011865: JSR 292 CTW fails: !THREAD->is_Compiler_thread() failed: Can not load classes with the Compiler thre In-Reply-To: <5E439E07-BF7F-4303-9DEA-8F49BAE76728@oracle.com> References: <014D0E4B-AB97-404D-B47C-ACB7CC0564CE@oracle.com> <5E439E07-BF7F-4303-9DEA-8F49BAE76728@oracle.com> Message-ID: <4C397721-F35E-4F42-B8CE-60E0DCADC4D5@oracle.com> Thanks, guys! -- John On Mar 17, 2011, at 6:24 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Mar 17, 2011, at 6:18 PM, John Rose wrote: > >> http://cr.openjdk.java.net/~jrose/7011865/webrev.00/ >> >> This shows up in CompileTheWorld (stress testing). It backs off from an initialization path introduced in this change set: >> 6964498: JSR 292 invokedynamic sites need local bootstrap methods >> >> Thanks, >> -- John > From rose00 at mac.com Thu Mar 17 17:52:14 2011 From: rose00 at mac.com (John Rose) Date: Thu, 17 Mar 2011 17:52:14 -0700 Subject: review request (XS): 7011865: JSR 292 CTW fails: !THREAD->is_Compiler_thread() failed: Can not load classes with the Compiler thre Message-ID: http://cr.openjdk.java.net/~jrose/7011865/webrev.00/ This shows up in CompileTheWorld (stress testing). It backs off from an initialization path introduced in this change set: 6964498: JSR 292 invokedynamic sites need local bootstrap methods Thanks, -- John From john.coomes at oracle.com Thu Mar 17 20:37:39 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 Mar 2011 03:37:39 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b134 for changeset ddc2fcb3682f Message-ID: <20110318033739.D458047253@hg.openjdk.java.net> Changeset: 168d9382ebab Author: schien Date: 2011-03-17 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/168d9382ebab Added tag jdk7-b134 for changeset ddc2fcb3682f ! .hgtags From john.coomes at oracle.com Thu Mar 17 20:37:46 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 Mar 2011 03:37:46 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b134 for changeset 918003855fa0 Message-ID: <20110318033748.549A147254@hg.openjdk.java.net> Changeset: e0b72ae5dc5e Author: schien Date: 2011-03-17 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/e0b72ae5dc5e Added tag jdk7-b134 for changeset 918003855fa0 ! .hgtags From john.coomes at oracle.com Thu Mar 17 20:37:55 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 Mar 2011 03:37:55 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 7 new changesets Message-ID: <20110318033755.A0D8847255@hg.openjdk.java.net> Changeset: 877fd25c5a2f Author: ohair Date: 2011-03-02 12:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/877fd25c5a2f 7023289: jaxp 1.4.5 development jdk7 2nd integration Reviewed-by: joehw, mchung, alanb ! jaxp.properties Changeset: b693ccf23fb7 Author: lana Date: 2011-03-07 11:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/b693ccf23fb7 Merge Changeset: 02d4672e8c05 Author: lana Date: 2011-03-10 20:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/02d4672e8c05 Merge Changeset: e8be6b716643 Author: ohair Date: 2011-03-10 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/e8be6b716643 7025412: make381 issues with quotes in jdk/make/docs/Makefile and other places Reviewed-by: mchung ! make/Makefile Changeset: 1259c6d09d09 Author: mfang Date: 2011-03-14 12:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/1259c6d09d09 Merge Changeset: d56b326ae054 Author: ohair Date: 2011-03-15 15:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/d56b326ae054 Merge Changeset: 4aa9916693dc Author: schien Date: 2011-03-17 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/4aa9916693dc Added tag jdk7-b134 for changeset d56b326ae054 ! .hgtags From john.coomes at oracle.com Thu Mar 17 20:38:02 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 Mar 2011 03:38:02 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 3 new changesets Message-ID: <20110318033802.77B0747256@hg.openjdk.java.net> Changeset: ba12732b1453 Author: ohair Date: 2011-03-10 13:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/ba12732b1453 7025412: make381 issues with quotes in jdk/make/docs/Makefile and other places Reviewed-by: mchung ! make/Makefile Changeset: 545de8303fec Author: mfang Date: 2011-03-14 12:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/545de8303fec Merge Changeset: d5fc61f18043 Author: schien Date: 2011-03-17 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/d5fc61f18043 Added tag jdk7-b134 for changeset 545de8303fec ! .hgtags From john.coomes at oracle.com Thu Mar 17 20:41:28 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 Mar 2011 03:41:28 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 90 new changesets Message-ID: <20110318035722.E016D47261@hg.openjdk.java.net> Changeset: 864b669d54d8 Author: lana Date: 2011-02-21 19:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/864b669d54d8 Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/share/demo/zipfs - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: 196d6e802721 Author: prr Date: 2011-02-28 10:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/196d6e802721 7004728: [parfait] potential memory leaks in XRender code Reviewed-by: bae, ceisserer ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: bbbf427a9007 Author: ceisserer Date: 2011-03-01 14:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bbbf427a9007 6974985: Jave2Demo threw exceptions when xrender enabled in OEL5.5 Reviewed-by: prr ! make/sun/awt/mapfile-mawt-vers ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/java2d/x11/XRSurfaceData.c Changeset: 01dcb496946e Author: ceisserer Date: 2011-03-03 16:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/01dcb496946e 7023589: Xrender : NullPointerException in sun.font.XRGlyphCache.freeGlyphs running Java 2D demo Reviewed-by: prr ! src/share/classes/sun/font/StrikeCache.java ! src/solaris/classes/sun/font/XRGlyphCache.java Changeset: f82f0af7de5b Author: prr Date: 2011-03-04 15:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f82f0af7de5b 7023591: Xrender: java2D font demo - text highlighting tab content is black Reviewed-by: flar ! src/share/classes/sun/java2d/pipe/AAShapePipe.java Changeset: 1356371db8c9 Author: lana Date: 2011-03-06 23:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1356371db8c9 Merge - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java - test/java/lang/Thread/StopBeforeStart.java Changeset: df0de56682b7 Author: dcherepanov Date: 2011-02-24 13:01 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/df0de56682b7 6996708: The event on the tray icon does not trigger and there is no message printed. Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_TrayIcon.cpp Changeset: 75d8c1200df8 Author: dcherepanov Date: 2011-02-25 13:58 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/75d8c1200df8 7020522: Need to reapply the fix for 6664512 Reviewed-by: art, mchung ! src/share/classes/sun/util/logging/PlatformLogger.java Changeset: c27520009762 Author: dcherepanov Date: 2011-02-25 15:33 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c27520009762 7009114: GTK FileDialog lies about it's Bounds Reviewed-by: art, anthony ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.h Changeset: de0f2f8563eb Author: lana Date: 2011-02-26 23:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/de0f2f8563eb Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/share/demo/zipfs - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: 024d040af4a3 Author: anthony Date: 2011-03-01 13:49 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/024d040af4a3 7022488: The security warning may disappear unexpectedly Summary: Initialize the fullScreenExclusiveModeState flag in the AwtWindow constructor Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Window.cpp Changeset: b5e609488bc8 Author: dcherepanov Date: 2011-03-01 15:24 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b5e609488bc8 6826397: PIT : Frame System Menu is not seen for when ALT + Space Bar is pressed in jdk7 b55 build. Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h Changeset: 8cd20d3e5448 Author: lana Date: 2011-03-06 20:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8cd20d3e5448 Merge - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java - test/java/lang/Thread/StopBeforeStart.java Changeset: 333bd91466bd Author: lana Date: 2011-03-07 14:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/333bd91466bd Merge ! make/sun/xawt/mapfile-vers Changeset: f8fdf9bca159 Author: okutsu Date: 2011-02-22 14:51 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f8fdf9bca159 7010379: fontconfig update for RHEL 6 Reviewed-by: peytoia ! make/sun/awt/Makefile Changeset: 5957bd3cfdc3 Author: okutsu Date: 2011-02-23 14:09 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5957bd3cfdc3 6623219: Font.canDisplayUpTo does not work with supplementary characters Reviewed-by: prr, peytoia ! src/share/classes/java/awt/Font.java + test/java/awt/FontClass/SurrogateTest/SupplementaryCanDisplayUpToTest.java Changeset: 30d112b3b6f2 Author: okutsu Date: 2011-02-23 16:50 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/30d112b3b6f2 6955047: (tz) javadoc for TimeZone.getDisplayName(boolean daylight, int style, Locale locale) is not clear 7021680: (tz) daylight savings time should be daylight saving time Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/TimeZone.java Changeset: ff611d9474cb Author: okutsu Date: 2011-02-24 15:09 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ff611d9474cb 7021989: Missing observesDaylightTime override in ZoneInfo Reviewed-by: peytoia ! src/share/classes/sun/util/calendar/ZoneInfo.java Changeset: 01c752a48b51 Author: okutsu Date: 2011-02-24 16:29 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/01c752a48b51 6772689: java.sql.Date.valueOf("2042-10-xx").toString() wrong in some time zones Reviewed-by: peytoia ! src/share/classes/sun/util/calendar/ZoneInfo.java + test/java/util/TimeZone/Bug6772689.java Changeset: e390ce4509c6 Author: alexp Date: 2011-02-28 18:20 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e390ce4509c6 6826074: JScrollPane does not revalidate the component hierarchy after scrolling Reviewed-by: anthony ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/javax/swing/JViewport.java Changeset: 1ef5b85d41f2 Author: amenkov Date: 2011-02-28 18:36 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1ef5b85d41f2 7013521: AudioSystem.write for AIFF files closes source audio stream Reviewed-by: dav ! src/share/classes/com/sun/media/sound/AiffFileWriter.java ! src/share/classes/com/sun/media/sound/AuFileWriter.java ! src/share/classes/com/sun/media/sound/SunFileWriter.java ! src/share/classes/com/sun/media/sound/WaveFileWriter.java + test/javax/sound/sampled/FileWriter/WriterCloseInput.java Changeset: d4e3c1f2177a Author: amenkov Date: 2011-03-03 15:41 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d4e3c1f2177a 6938426: Concurrency bug in ALAW encoder causes random bursts of static/noise in output. Reviewed-by: stayer ! src/share/classes/com/sun/media/sound/AlawCodec.java + test/javax/sound/sampled/FileWriter/AlawEncoderSync.java Changeset: d3df100509ad Author: amenkov Date: 2011-03-03 15:45 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d3df100509ad 6801206: SoundTestSuite: test050 fails Reviewed-by: stayer ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java + test/javax/sound/sampled/Clip/ClipSetPos.java Changeset: 4e732aba71bf Author: amenkov Date: 2011-03-03 15:57 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4e732aba71bf 6660470: RealTimeSequencer incorrectly opens (implicitly) synthesizer Reviewed-by: stayer ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/share/classes/javax/sound/midi/MidiSystem.java + test/javax/sound/midi/Sequencer/SequencerImplicitSynthOpen.java Changeset: 67d4b2e2e5b1 Author: amenkov Date: 2011-03-03 16:40 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/67d4b2e2e5b1 6835393: MidiSystem fails to correctly read Sequence with SMPTE division Reviewed-by: stayer ! src/share/classes/com/sun/media/sound/StandardMidiFileReader.java + test/javax/sound/midi/File/SMPTESequence.java Changeset: 52bdb4237d5e Author: rupashka Date: 2011-03-03 17:47 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/52bdb4237d5e 6796710: Html content in JEditorPane is overlapping on swing components while resizing the application. Reviewed-by: alexp ! src/share/classes/javax/swing/text/html/CSSBorder.java + test/javax/swing/regtesthelpers/Util.java + test/javax/swing/text/CSSBorder/6796710/bug6796710.java Changeset: 7dfcf271b73b Author: alexp Date: 2011-03-03 18:23 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7dfcf271b73b 6653511: JComponent.safelyGetGraphics() may sometimes return null Reviewed-by: rupashka ! src/share/classes/javax/swing/JComponent.java Changeset: e4ca9353150a Author: alexp Date: 2011-03-03 18:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e4ca9353150a Merge Changeset: dc34da6a3fa1 Author: rupashka Date: 2011-03-05 18:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dc34da6a3fa1 6760148: Certain fonts are not correctly soft wrapped when using JTextComponent.print() Reviewed-by: peterz ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/WrappedPlainView.java Changeset: ca0f223b4be7 Author: lana Date: 2011-03-05 20:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ca0f223b4be7 Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java ! src/share/classes/javax/swing/JComponent.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/share/demo/zipfs - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc - test/java/lang/Thread/StopBeforeStart.java - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: e3a69b9be2b5 Author: lana Date: 2011-03-07 14:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e3a69b9be2b5 Merge Changeset: d26e79640fd4 Author: mduigou Date: 2011-02-21 14:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d26e79640fd4 7019705: Add -XX:+AggressiveOpts options to MOAT test Reviewed-by: alanb ! test/java/util/Collection/MOAT.java Changeset: dbdafe65af60 Author: alanb Date: 2011-02-21 13:54 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dbdafe65af60 7020517: (fs) FileStore.equals returns true if both volumes have the same serial number Reviewed-by: chegar ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! test/java/nio/file/FileStore/Basic.java Changeset: d7cb44a4d08a Author: alanb Date: 2011-02-22 10:19 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d7cb44a4d08a Merge Changeset: 9d8a0369b906 Author: alanb Date: 2011-02-22 12:04 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9d8a0369b906 7020888: (file) Miscellaneous and trivial clean-ups (typos and opportunities to use suppressed exceptions) Reviewed-by: mduigou, chegar ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FilterOutputStream.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/PushbackReader.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/file/CopyMoveHelper.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! test/java/lang/ProcessBuilder/Basic.java Changeset: bac152c6491a Author: alanb Date: 2011-02-22 14:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bac152c6491a 7021327: Changes for 7020888 included changes to other files in error Reviewed-by: chegar ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/FilterOutputStream.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/PushbackReader.java ! test/java/lang/ProcessBuilder/Basic.java Changeset: b853414b8eef Author: michaelm Date: 2011-02-22 14:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b853414b8eef 6702400: ChunkedInputStream expecting -1 from int read, but int->char comparision is wrong Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java Changeset: 75216854fb53 Author: valeriep Date: 2011-02-22 12:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/75216854fb53 6604496: Support for CKM_AES_CTR (counter mode) Summary: Enhanced SunPKCS11 provider to support AES/CTR/NoPadding transformation. Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java + src/share/classes/sun/security/pkcs11/wrapper/CK_AES_CTR_PARAMS.java ! src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c + src/share/native/sun/security/pkcs11/wrapper/pkcs-11v2-20a3.h ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! test/sun/security/pkcs11/Cipher/TestSymmCiphers.java ! test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java Changeset: 84e339f1033b Author: smarks Date: 2011-02-22 15:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/84e339f1033b 7021209: convert lang, math, util to use try-with-resources Reviewed-by: alanb, darcy, naoto ! src/share/classes/java/lang/Package.java ! src/share/classes/java/util/Currency.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! src/solaris/classes/java/util/prefs/FileSystemPreferences.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/Runtime/shutdown/ShutdownHooks.java ! test/java/lang/instrument/BootClassPath/Setup.java ! test/java/lang/instrument/ilib/Inject.java ! test/java/math/BigInteger/BigIntegerTest.java ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Formatter/FailingConstructors.java ! test/java/util/Locale/LocaleEnhanceTest.java ! test/java/util/ResourceBundle/Bug6204853.java ! test/java/util/Scanner/FailingConstructors.java Changeset: 892c3fc7249e Author: dl Date: 2011-02-23 14:56 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/892c3fc7249e 7017493: ConcurrentLinkedDeque: Unexpected initialization order can lead to crash due to use of Unsafe Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java Changeset: 744c2773e3f7 Author: lana Date: 2011-02-23 10:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/744c2773e3f7 Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: 0f0d6b8f98cc Author: wetmore Date: 2011-02-23 22:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0f0d6b8f98cc 6844879: Source distribution should be more robustly built without the security source distribution Reviewed-by: ohair ! make/common/shared/Defs-java.gmk Changeset: c2c8f9c38fd1 Author: chegar Date: 2011-02-24 12:57 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c2c8f9c38fd1 7020136: java/net/URLConnection/RedirectLimit.java fails intermittently Summary: Increase the socket timeout and clean up the test Reviewed-by: alanb ! test/java/net/URLConnection/RedirectLimit.java Changeset: 1f41e41ef2db Author: chegar Date: 2011-02-24 13:42 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1f41e41ef2db 6849693: index of fdTable should be less than num. of fdTable in jdk7 Reviewed-by: alanb ! src/solaris/native/java/net/linux_close.c Changeset: 51ef29aafc1b Author: michaelm Date: 2011-02-24 18:35 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/51ef29aafc1b 6835668: Use of /usr/include/linux/ files creates a dependence on kernel-headers Reviewed-by: chegar ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c Changeset: b74f1b830484 Author: smarks Date: 2011-02-24 22:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b74f1b830484 7022383: add reference to CR for ReadLongZipFileName test to problem list Reviewed-by: ohair ! test/ProblemList.txt Changeset: 32dc1cb2b995 Author: mchung Date: 2011-02-25 11:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/32dc1cb2b995 7021939: com.oracle.net is not a NON_CORE_PKGS Reviewed-by: ohair, alanb ! make/common/Release.gmk ! make/docs/NON_CORE_PKGS.gmk Changeset: 5dc98de2a35e Author: mchung Date: 2011-02-25 12:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5dc98de2a35e 7016707: Remove the BootClassLoaderHook for jkernel support Reviewed-by: alanb, ohair ! make/java/java/FILES_java.gmk ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/util/zip/ZipEntry.java - src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/misc/Launcher.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: 8887cb2f5d19 Author: smarks Date: 2011-02-25 02:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8887cb2f5d19 7021582: convert jar/zip code and tests to use try-with-resources Reviewed-by: alanb, dholmes, sherman ! src/share/classes/java/util/jar/JarFile.java ! test/java/util/jar/JarEntry/GetMethodsReturnClones.java ! test/java/util/jar/JarFile/ScanSignedJar.java ! test/java/util/zip/Available.java ! test/java/util/zip/FileBuilder.java ! test/java/util/zip/GZIP/Accordion.java ! test/java/util/zip/GZIP/GZIPInputStreamRead.java ! test/java/util/zip/InflateIn_DeflateOut.java ! test/java/util/zip/InfoZip.java ! test/java/util/zip/LargeZip.java ! test/java/util/zip/TestEmptyZip.java ! test/java/util/zip/ZipCoding.java ! test/java/util/zip/ZipFile/Assortment.java ! test/java/util/zip/ZipFile/Comment.java ! test/java/util/zip/ZipFile/CopyJar.java ! test/java/util/zip/ZipFile/CorruptedZipFiles.java ! test/java/util/zip/ZipFile/DeleteTempJar.java ! test/java/util/zip/ZipFile/EnumAfterClose.java ! test/java/util/zip/ZipFile/GetDirEntry.java ! test/java/util/zip/ZipFile/LargeZipFile.java ! test/java/util/zip/ZipFile/ManyEntries.java ! test/java/util/zip/ZipFile/ManyZipFiles.java ! test/java/util/zip/ZipFile/ReadAfterClose.java ! test/java/util/zip/ZipFile/ReadZip.java ! test/java/util/zip/ZipFile/ShortRead.java ! test/java/util/zip/zip.java Changeset: 29f25ba547fc Author: chegar Date: 2011-02-28 11:03 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/29f25ba547fc 7022269: clean up fscanf usage in Linux networking native code Reviewed-by: michaelm, alanb ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/net_util_md.c Changeset: a3b6c262195b Author: dholmes Date: 2011-02-28 06:40 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a3b6c262195b 7022386: gethostbyname_r needs a pointer aligned buffer passed to it Summary: Change buffer type to ensure pointer-alignment Reviewed-by: alanb, chegar ! src/solaris/native/java/net/Inet4AddressImpl.c Changeset: f4613b378874 Author: weijun Date: 2011-02-28 23:02 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f4613b378874 7021789: Remove jarsigner -crl option Reviewed-by: mullan ! src/share/classes/com/sun/jarsigner/ContentSignerParameters.java ! src/share/classes/java/security/CodeSigner.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/JarSignerResources.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/tools/TimestampedSigner.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! test/sun/security/tools/jarsigner/crl.sh Changeset: f8bf888edf20 Author: weijun Date: 2011-03-01 16:22 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f8bf888edf20 7020531: test: java/security/cert/CertificateFactory/openssl/OpenSSLCert.java file not closed after run Reviewed-by: alanb, smarks ! test/ProblemList.txt ! test/java/security/cert/CertificateFactory/openssl/OpenSSLCert.java ! test/sun/security/tools/keytool/NewSize7.java Changeset: b7e763a573a4 Author: alanb Date: 2011-03-01 12:03 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b7e763a573a4 7023034: Files.createTempDirectory((Path)null, "temp") does not throw NPE Reviewed-by: forax ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/TemporaryFiles.java Changeset: 98d2d57d9e73 Author: smarks Date: 2011-03-01 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/98d2d57d9e73 7022624: use try-with-resources in java.io tests Reviewed-by: alanb ! test/java/io/File/SetLastModified.java ! test/java/io/FileOutputStream/AtomicAppend.java ! test/java/io/OutputStreamWriter/Encode.java ! test/java/io/PrintStream/EncodingConstructor.java ! test/java/io/PrintStream/FailingConstructors.java ! test/java/io/Serializable/evolution/RenamePackage/install/SerialDriver.java ! test/java/io/Serializable/evolution/RenamePackage/test/SerialDriver.java Changeset: 895687e879ca Author: alanb Date: 2011-03-02 16:56 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/895687e879ca 7021987: native2ascii "file cannot be read" error message is broken Reviewed-by: lancea, mchung ! src/share/classes/sun/tools/native2ascii/Main.java ! test/sun/tools/native2ascii/Native2AsciiTests.sh Changeset: 75064373ed6b Author: michaelm Date: 2011-03-03 15:34 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/75064373ed6b 7018606: (process) test/java/lang/ProcessBuilder/Basic.java failing intermittently (win) Reviewed-by: alanb ! test/java/lang/ProcessBuilder/Basic.java Changeset: 7cfb0693eb33 Author: chegar Date: 2011-03-03 16:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7cfb0693eb33 7018137: HTML4 compliance issues Summary: move end list items tags to after nested list Reviewed-by: alanb ! src/share/classes/java/net/URI.java ! src/share/classes/java/net/package.html Changeset: 9b99a14375bc Author: chegar Date: 2011-03-03 16:48 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9b99a14375bc 6721694: java/lang/Thread/StartOOMTest.java fails with timeout or with crash Summary: the test is not suitable to be run automatically Reviewed-by: alanb ! test/java/lang/Thread/StartOOMTest.java Changeset: 732faed56eb0 Author: coffeys Date: 2011-03-03 16:51 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/732faed56eb0 6750362: Very large LDAP requests throw a OOM on LDAP servers which aren't aware of Paged Results Controls 6748156: add an new JNDI property to control the boolean flag WaitForReply Reviewed-by: vinnie, robm ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapRequest.java + test/com/sun/jndi/ldap/NoWaitForReplyTest.java Changeset: 0bd32f96187d Author: coffeys Date: 2011-03-03 17:00 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0bd32f96187d Merge Changeset: b645b5bc460b Author: michaelm Date: 2011-03-03 17:14 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b645b5bc460b 7024264: HttpURLConnection/NetPermission doc issue Reviewed-by: chegar ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/NetPermission.java Changeset: 6e596210bf01 Author: michaelm Date: 2011-03-03 17:16 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6e596210bf01 Merge Changeset: 2fb9e2d4ef46 Author: alanb Date: 2011-03-04 09:29 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2fb9e2d4ef46 6944810: (ch) Assert failure in sun.nio.ch.PendingIoCache.clearPendingIoMap [win] Reviewed-by: chegar ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/windows/classes/sun/nio/ch/PendingIoCache.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! test/ProblemList.txt Changeset: 259011d14d48 Author: alanb Date: 2011-03-04 09:33 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/259011d14d48 Merge Changeset: c4bd93431a20 Author: ksrini Date: 2011-03-04 09:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c4bd93431a20 7023963: (misc) fix diamond anon instances in the jdk Reviewed-by: alanb, mchung, mcimadamore, dholmes ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipDirectoryStream.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java Changeset: 90b7926884a8 Author: sherman Date: 2011-03-04 11:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/90b7926884a8 7023244: (zipfs) langtools CompileTest fails on read-only file system Summary: replaced checkAccess with Files.isWritable() Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java Changeset: 7b6ad3027f3d Author: alanb Date: 2011-03-04 21:26 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7b6ad3027f3d 7023403: (ch) sun.nio.ch.SolarisEventPort.startPoll failed with AssertionError Reviewed-by: forax ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java Changeset: 28bedf6eba87 Author: alanb Date: 2011-03-04 21:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/28bedf6eba87 Merge Changeset: 339342f311cc Author: coffeys Date: 2011-03-07 14:43 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/339342f311cc 7025105: TEST_BUG test/com/sun/jndi/ldap/NoWaitForReplyTest.java should be cleaned up Reviewed-by: alanb ! test/com/sun/jndi/ldap/NoWaitForReplyTest.java Changeset: bc0c58d65e97 Author: mullan Date: 2011-03-07 13:20 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bc0c58d65e97 7022467: SecretKeyFactory doesn't support algorithm "AES" on Windows and Linux Reviewed-by: wetmore, valeriep ! src/share/classes/javax/crypto/SecretKeyFactory.java Changeset: 62b0337d1369 Author: mullan Date: 2011-03-07 13:44 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/62b0337d1369 Merge Changeset: 6d5a992dbac2 Author: lana Date: 2011-03-07 11:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6d5a992dbac2 Merge ! make/common/Release.gmk - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java Changeset: a52da0bada39 Author: valeriep Date: 2011-03-07 14:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a52da0bada39 6994008: PKCS11 should support "RSA" and "RSA/ECB/NoPadding" ciphers Summary: Add support for RSA_X_509 mechanism and aliasing of "RSA" to "RSA/ECB/PKCS1Padding". Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! test/sun/security/pkcs11/Cipher/TestRSACipher.java ! test/sun/security/pkcs11/Cipher/TestRSACipherWrap.java + test/sun/security/pkcs11/Cipher/TestRawRSACipher.java Changeset: 0b6d82c838d4 Author: lana Date: 2011-03-07 14:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0b6d82c838d4 Merge - src/share/classes/sun/misc/BootClassLoaderHook.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: 663c7623b96b Author: alanb Date: 2011-03-08 10:32 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/663c7623b96b 7025468: Tests using diamond with anonymous inner classes needs to be reverted Reviewed-by: dholmes, forax ! test/java/nio/file/DirectoryStream/Basic.java ! test/java/util/PriorityQueue/NoNulls.java Changeset: c0bf0f19897a Author: lana Date: 2011-03-10 19:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c0bf0f19897a Merge Changeset: c975c4fbca20 Author: lana Date: 2011-03-10 20:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c975c4fbca20 Merge ! make/common/Release.gmk - src/share/classes/sun/misc/BootClassLoaderHook.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: 6aeed99af874 Author: mchung Date: 2011-03-09 23:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6aeed99af874 7025631: Remove the modules build support from jdk 7 Reviewed-by: alanb, ohair ! make/Makefile ! make/com/sun/crypto/provider/Makefile ! make/com/sun/java/pack/Makefile ! make/com/sun/java/pack/prop/Makefile ! make/com/sun/jndi/cosnaming/Makefile ! make/com/sun/jndi/dns/Makefile ! make/com/sun/jndi/ldap/Makefile ! make/com/sun/jndi/rmi/registry/Makefile ! make/com/sun/nio/sctp/Makefile ! make/com/sun/org/apache/xml/Makefile ! make/com/sun/rowset/Makefile ! make/com/sun/script/Makefile ! make/com/sun/security/auth/module/Makefile ! make/com/sun/servicetag/Makefile ! make/com/sun/tools/attach/Makefile ! make/common/Defs.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/Sanity.gmk ! make/common/Subdirs.gmk ! make/common/shared/Sanity.gmk ! make/java/awt/Makefile ! make/java/fdlibm/Makefile ! make/java/instrument/Makefile ! make/java/java/Makefile ! make/java/java_crw_demo/Makefile ! make/java/java_hprof_demo/Makefile ! make/java/jli/Makefile ! make/java/jvm/Makefile ! make/java/logging/Makefile ! make/java/main/java/Makefile ! make/java/main/javaw/Makefile ! make/java/management/Makefile ! make/java/net/Makefile ! make/java/nio/Makefile ! make/java/npt/Makefile ! make/java/redist/Makefile ! make/java/redist/fonts/Makefile ! make/java/redist/sajdi/Makefile ! make/java/security/Makefile ! make/java/sql/Makefile ! make/java/text/base/Makefile ! make/java/verify/Makefile ! make/java/zip/Makefile ! make/javax/crypto/Makefile ! make/javax/imageio/Makefile ! make/javax/print/Makefile ! make/javax/sound/Makefile ! make/javax/sound/jsoundalsa/Makefile ! make/javax/sound/jsoundds/Makefile ! make/javax/sql/Makefile ! make/javax/swing/Makefile ! make/javax/swing/plaf/Makefile ! make/jpda/back/Makefile ! make/jpda/transport/Makefile ! make/jpda/transport/shmem/Makefile ! make/jpda/transport/socket/Makefile ! make/jpda/tty/Makefile ! make/launchers/Makefile ! make/mkdemo/jvmti/Makefile ! make/mkdemo/management/Makefile ! make/mksample/dtrace/Makefile ! make/mksample/jmx/jmx-scandir/Makefile ! make/mksample/nbproject/Makefile ! make/mksample/nio/file/Makefile ! make/mksample/nio/multicast/Makefile ! make/mksample/nio/server/Makefile ! make/mksample/scripting/scriptpad/Makefile ! make/mksample/webservices/EbayClient/Makefile ! make/mksample/webservices/EbayServer/Makefile ! make/sun/applet/Makefile ! make/sun/awt/Makefile ! make/sun/cmm/Makefile ! make/sun/cmm/kcms/Makefile ! make/sun/cmm/lcms/Makefile ! make/sun/dcpr/Makefile ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/image/generic/Makefile ! make/sun/image/vis/Makefile ! make/sun/jar/Makefile ! make/sun/javazic/Makefile ! make/sun/jawt/Makefile ! make/sun/jconsole/Makefile ! make/sun/jdbc/Makefile ! make/sun/jdga/Makefile ! make/sun/jpeg/Makefile ! make/sun/launcher/Makefile ! make/sun/management/Makefile ! make/sun/native2ascii/Makefile ! make/sun/net/others/Makefile ! make/sun/net/spi/nameservice/dns/Makefile ! make/sun/nio/cs/Makefile ! make/sun/org/mozilla/javascript/Makefile ! make/sun/pisces/Makefile ! make/sun/rmi/cgi/Makefile ! make/sun/rmi/oldtools/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmi/Makefile ! make/sun/rmi/rmic/Makefile ! make/sun/rmi/rmid/Makefile ! make/sun/security/ec/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/security/smartcardio/Makefile ! make/sun/security/tools/Makefile ! make/sun/serialver/Makefile ! make/sun/splashscreen/Makefile ! make/sun/text/Makefile ! make/sun/tools/Makefile ! make/sun/tracing/dtrace/Makefile ! make/sun/xawt/Makefile Changeset: 1657b854c956 Author: mchung Date: 2011-03-09 23:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1657b854c956 7026228: Remove make/modules and make/common/Modules.gmk Reviewed-by: alanb, ohair - make/common/Modules.gmk - make/java/nio/mxbean/Makefile - make/modules/Makefile - make/modules/bootmodule.roots - make/modules/jdk7.depconfig - make/modules/modules.config - make/modules/modules.group - make/modules/optional.depconfig - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java Changeset: c28f5ac2d5f8 Author: ohair Date: 2011-03-10 14:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c28f5ac2d5f8 7025412: make381 issues with quotes in jdk/make/docs/Makefile and other places Reviewed-by: mchung, herrick ! make/common/shared/Defs-javadoc.gmk ! make/common/shared/Sanity.gmk ! make/docs/Makefile ! make/javax/crypto/Defs-jce.gmk Changeset: 38be400c2608 Author: asaha Date: 2011-03-09 16:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/38be400c2608 6908562: JFB Custom Revision Version Build/Makefile changes Reviewed-by: ohair, ksrini, katleman ! make/common/Release.gmk ! make/common/shared/Defs.gmk Changeset: fc680f496eaf Author: asaha Date: 2011-03-14 12:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fc680f496eaf Merge - make/common/Modules.gmk ! make/common/Release.gmk - make/java/nio/mxbean/Makefile - make/modules/Makefile - make/modules/bootmodule.roots - make/modules/jdk7.depconfig - make/modules/modules.config - make/modules/modules.group - make/modules/optional.depconfig - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java Changeset: b1215d1f015b Author: ohair Date: 2011-03-15 15:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b1215d1f015b Merge - make/common/Modules.gmk ! make/common/Release.gmk - make/java/nio/mxbean/Makefile - make/modules/Makefile - make/modules/bootmodule.roots - make/modules/jdk7.depconfig - make/modules/modules.config - make/modules/modules.group - make/modules/optional.depconfig - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java ! make/sun/awt/Makefile Changeset: 3de1fed4b9ec Author: ohair Date: 2011-03-15 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3de1fed4b9ec 6710813: SwingSet2 source display tabs do not work since JDK 7 b20 6685150: make/mkdemo/jpda/Makefile creates jpda.jar and src.zip instead of examples.jar Reviewed-by: prr ! make/common/Demo.gmk ! make/mkdemo/jfc/SwingSet2/Makefile ! make/mkdemo/jpda/Makefile Changeset: f5ecfc9e274c Author: ohair Date: 2011-03-15 23:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f5ecfc9e274c Merge - src/share/classes/sun/misc/BootClassLoaderHook.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: d6c6d9566126 Author: katleman Date: 2011-03-16 09:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d6c6d9566126 6973319: incorrect spec version in jdk 7 rt.jar manifest Reviewed-by: ohair ! make/tools/manifest.mf Changeset: 76a2ea69f47f Author: katleman Date: 2011-03-16 09:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/76a2ea69f47f 7022473: JDK7 still runs /etc/prtconf to find memory size Reviewed-by: ohair ! make/common/shared/Platform.gmk Changeset: 554adcfb615e Author: ohair Date: 2011-03-16 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/554adcfb615e 7027923: Disable VS2003 use in preparation for all VS2003 make logic removal Reviewed-by: prr ! make/common/shared/Compiler-msvc.gmk Changeset: 0653cab602f2 Author: schien Date: 2011-03-17 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0653cab602f2 Added tag jdk7-b134 for changeset 554adcfb615e ! .hgtags From john.r.rose at oracle.com Thu Mar 17 22:11:10 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 18 Mar 2011 05:11:10 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7011865: JSR 292 CTW fails: !THREAD->is_Compiler_thread() failed: Can not load classes with the Compiler thre Message-ID: <20110318051119.1DC7C47266@hg.openjdk.java.net> Changeset: d2134498fd3f Author: jrose Date: 2011-03-17 18:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d2134498fd3f 7011865: JSR 292 CTW fails: !THREAD->is_Compiler_thread() failed: Can not load classes with the Compiler thre Reviewed-by: kvn, never ! src/share/vm/interpreter/linkResolver.cpp From john.r.rose at oracle.com Fri Mar 18 00:17:29 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 18 Mar 2011 07:17:29 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 6839872: remove implementation inheritance from JSR 292 APIs Message-ID: <20110318071741.1B5A04726B@hg.openjdk.java.net> Changeset: 5acc8cf00539 Author: jrose Date: 2011-03-18 00:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5acc8cf00539 6839872: remove implementation inheritance from JSR 292 APIs Summary: move everything into a single package; remove all multi-package machinery Reviewed-by: twisti, forax + src/share/classes/java/dyn/AdapterMethodHandle.java + src/share/classes/java/dyn/BoundMethodHandle.java ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/ClassValue.java + src/share/classes/java/dyn/DirectMethodHandle.java + src/share/classes/java/dyn/FilterGeneric.java + src/share/classes/java/dyn/FilterOneArgument.java + src/share/classes/java/dyn/FromGeneric.java ! src/share/classes/java/dyn/InvokeDynamic.java + src/share/classes/java/dyn/InvokeGeneric.java + src/share/classes/java/dyn/Invokers.java ! src/share/classes/java/dyn/Linkage.java + src/share/classes/java/dyn/MemberName.java ! src/share/classes/java/dyn/MethodHandle.java + src/share/classes/java/dyn/MethodHandleImpl.java + src/share/classes/java/dyn/MethodHandleNatives.java + src/share/classes/java/dyn/MethodHandleStatics.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/SpreadGeneric.java + src/share/classes/java/dyn/ToGeneric.java ! src/share/classes/java/dyn/VolatileCallSite.java ! src/share/classes/java/dyn/WrongMethodTypeException.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/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java + test/java/dyn/6987555/Test6987555.java + test/java/dyn/6991596/Test6991596.java ! test/java/dyn/MethodTypeTest.java From christian.thalinger at oracle.com Fri Mar 18 09:18:07 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Mar 2011 17:18:07 +0100 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <8822AEC2-212C-4ED1-BE34-A3B42E51BB27@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> <26256988-B1B9-4D29-8AA1-050F3D7A9147@oracle.com> <8822AEC2-212C-4ED1-BE34-A3B42E51BB27@oracle.com> Message-ID: <941F1787-3730-40B3-B4FE-5D50E5DCF408@oracle.com> On Mar 17, 2011, at 7:19 PM, Tom Rodriguez wrote: >>> Native wrappers are never inlined. That would be a intrinsic in the output you show above. Intrinsic inlining should always have a bci though. >> >> Ahh, right, I mixed them. When I'm already at it, should I change the intrinsic output too: >> >> Inlining intrinsic _min at bci:67 in sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (489 bytes) >> >> to fit into the inlining tree? > > I wouldn't mind that. Something like the normal output but with "(intrinsic)" at the end? Alright, I changed a lot more than I wanted to but now it seems much better and clearer, at least to me. I removed nmethod::print_compilation completely (which was called from CompileTask::print_compilation) and moved all printing logic into CompileTask. http://cr.openjdk.java.net/~twisti/7022998/ Some output looks a little different now, like instrinsics (as we talked about): 1111 3 java.lang.String::lastIndexOf (68 bytes) @ 26 java.lang.Math::min (11 bytes) (intrinsic) To be able to remove some utterly complex code (the title code from nmethod::print_compilation), made_not_entrant and made_zombie messages are now printed and the end of the line (like all other status messages). Additionally I added a status flag (e = not entrant, z = zombie): 4006 150 z 4 java.lang.String::equals (88 bytes) made zombie 4565 121 e 3 java.util.HashMap::get (79 bytes) made not entrant Type profile output looks like: @ 121 java.util.HashMap::addEntry (58 bytes) inline (hot) \-> TypeProfile (6020/6257 counts) = java/util/HashMap or: @ 89 java.util.LinkedHashMap$Entry::recordAccess (35 bytes) inline (hot) \-> TypeProfile (13/131 counts) = java/util/LinkedHashMap$Entry \-> TypeProfile (118/131 counts) = java/util/HashMap$Entry Native wrapper compiles now look like this (I print a "-" instead of the compile level for tiered): 2077 0 n - java.lang.System::nanoTime (0 bytes) (static) But the output might look a little odd since the native wrapper output may be between compile output and inline output looking like the native wrapper has an inlinee: 2102 69 3 java.lang.CharacterDataLatin1::toUpperCaseEx (71 bytes) 2102 0 n - sun.misc.Unsafe::compareAndSwapInt (0 bytes) @ 4 java.lang.CharacterDataLatin1::getProperties (11 bytes) About the compile id for native wrappers, assign_compile_id has an assert: assert(!method->is_native(), "no longer compile natives"); So either we remove that assert or we don't assign a compile id to native wrapper compiles. Let me know what you think. -- Christian PS: The original bug fix is still in there :-) From christian.thalinger at oracle.com Fri Mar 18 09:35:06 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Mar 2011 17:35:06 +0100 Subject: Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc In-Reply-To: <4D823D42.5070307@oracle.com> References: <4D7FA058.4000208@oracle.com> <257D9E62-1674-4F0B-B9D3-E6F27962D97B@oracle.com> <4D823D42.5070307@oracle.com> Message-ID: <436C2BD2-CF53-4446-8DD9-AA5F5AACADC8@oracle.com> On Mar 17, 2011, at 5:56 PM, Vladimir Kozlov wrote: > Sorry for arguing about few lines but I think without renaming the code will be better (6 new lines instead of 7): > > + #ifdef _LP64 > + __ ldsw(arg_lsw, O2_scratch); // Load LSW > + #else > + __ ldsw(arg_lsw, O3_scratch); // Load LSW > + __ srlx(O3_scratch, BitsPerInt, O2_scratch)); // Move MSW value to lower 32-bits for STD > + #endif > __ st_long(O2_scratch, arg_msw); // Uses O2/O3 on !_LP64 Alright. I changed my code. Okay to push? -- Christian > > Vladimir > > On 3/17/11 2:24 AM, Christian Thalinger wrote: >> On Mar 15, 2011, at 6:22 PM, Vladimir Kozlov wrote: >>> Christian, >>> >>> We don't support little-endian SPARC, why add a code which will never be executed? >> >> I thought to be on the safe side if anyone ever wants to support it. Anyway, I removed it and updated the webrev. >> >> -- Christian >> >>> >>> On side note (RFE): we should officially drop v8 support (C2 does not support already, only C1). There are already several places where we use stx/ldx without check that it is v9 (yes, we still have an assert which is fine). Also std/ldd is emulated on modern SPARC and so is very slow. >>> >>> Thanks, >>> Vladimir >>> >>> Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/7027232/ >>>> 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc >>>> Reviewed-by: >>>> After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on >>>> 32-bit SPARC. st_long uses STD on 32-bit SPARC and the LSW and MSW >>>> bits are not moved to the proper registers resulting in a wrong >>>> result. >>>> The fix is to use the correct registers for 32-bit big-endian and >>>> little-endian (just in case) SPARC. >>>> src/cpu/sparc/vm/methodHandles_sparc.cpp From vladimir.kozlov at oracle.com Fri Mar 18 09:44:41 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Mar 2011 09:44:41 -0700 Subject: Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc In-Reply-To: <436C2BD2-CF53-4446-8DD9-AA5F5AACADC8@oracle.com> References: <4D7FA058.4000208@oracle.com> <257D9E62-1674-4F0B-B9D3-E6F27962D97B@oracle.com> <4D823D42.5070307@oracle.com> <436C2BD2-CF53-4446-8DD9-AA5F5AACADC8@oracle.com> Message-ID: <4D838BF9.5050203@oracle.com> Yes, thank you Christian Vladimir Christian Thalinger wrote: > On Mar 17, 2011, at 5:56 PM, Vladimir Kozlov wrote: >> Sorry for arguing about few lines but I think without renaming the code will be better (6 new lines instead of 7): >> >> + #ifdef _LP64 >> + __ ldsw(arg_lsw, O2_scratch); // Load LSW >> + #else >> + __ ldsw(arg_lsw, O3_scratch); // Load LSW >> + __ srlx(O3_scratch, BitsPerInt, O2_scratch)); // Move MSW value to lower 32-bits for STD >> + #endif >> __ st_long(O2_scratch, arg_msw); // Uses O2/O3 on !_LP64 > > Alright. I changed my code. Okay to push? > > -- Christian > >> Vladimir >> >> On 3/17/11 2:24 AM, Christian Thalinger wrote: >>> On Mar 15, 2011, at 6:22 PM, Vladimir Kozlov wrote: >>>> Christian, >>>> >>>> We don't support little-endian SPARC, why add a code which will never be executed? >>> I thought to be on the safe side if anyone ever wants to support it. Anyway, I removed it and updated the webrev. >>> >>> -- Christian >>> >>>> On side note (RFE): we should officially drop v8 support (C2 does not support already, only C1). There are already several places where we use stx/ldx without check that it is v9 (yes, we still have an assert which is fine). Also std/ldd is emulated on modern SPARC and so is very slow. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Christian Thalinger wrote: >>>>> http://cr.openjdk.java.net/~twisti/7027232/ >>>>> 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc >>>>> Reviewed-by: >>>>> After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on >>>>> 32-bit SPARC. st_long uses STD on 32-bit SPARC and the LSW and MSW >>>>> bits are not moved to the proper registers resulting in a wrong >>>>> result. >>>>> The fix is to use the correct registers for 32-bit big-endian and >>>>> little-endian (just in case) SPARC. >>>>> src/cpu/sparc/vm/methodHandles_sparc.cpp > > From vladimir.kozlov at oracle.com Fri Mar 18 09:51:42 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Mar 2011 09:51:42 -0700 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <941F1787-3730-40B3-B4FE-5D50E5DCF408@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> <26256988-B1B9-4D29-8AA1-050F3D7A9147@oracle.com> <8822AEC2-212C-4ED1-BE34-A3B42E51BB27@oracle.com> <941F1787-3730-40B3-B4FE-5D50E5DCF408@oracle.com> Message-ID: <4D838D9E.9010009@oracle.com> I like these changes :) Thank you for doing this. Remove the assert. Why you got compile_id 0 for native wrapper? Thanks, Vladimir Christian Thalinger wrote: > On Mar 17, 2011, at 7:19 PM, Tom Rodriguez wrote: >>>> Native wrappers are never inlined. That would be a intrinsic in the output you show above. Intrinsic inlining should always have a bci though. >>> Ahh, right, I mixed them. When I'm already at it, should I change the intrinsic output too: >>> >>> Inlining intrinsic _min at bci:67 in sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (489 bytes) >>> >>> to fit into the inlining tree? >> I wouldn't mind that. Something like the normal output but with "(intrinsic)" at the end? > > Alright, I changed a lot more than I wanted to but now it seems much better and clearer, at least to me. > > I removed nmethod::print_compilation completely (which was called from CompileTask::print_compilation) and moved all printing logic into CompileTask. > > http://cr.openjdk.java.net/~twisti/7022998/ > > Some output looks a little different now, like instrinsics (as we talked about): > > 1111 3 java.lang.String::lastIndexOf (68 bytes) > @ 26 java.lang.Math::min (11 bytes) (intrinsic) > > To be able to remove some utterly complex code (the title code from nmethod::print_compilation), made_not_entrant and made_zombie messages are now printed and the end of the line (like all other status messages). Additionally I added a status flag (e = not entrant, z = zombie): > > 4006 150 z 4 java.lang.String::equals (88 bytes) made zombie > 4565 121 e 3 java.util.HashMap::get (79 bytes) made not entrant > > Type profile output looks like: > > @ 121 java.util.HashMap::addEntry (58 bytes) inline (hot) > \-> TypeProfile (6020/6257 counts) = java/util/HashMap > > or: > > @ 89 java.util.LinkedHashMap$Entry::recordAccess (35 bytes) inline (hot) > \-> TypeProfile (13/131 counts) = java/util/LinkedHashMap$Entry > \-> TypeProfile (118/131 counts) = java/util/HashMap$Entry > > Native wrapper compiles now look like this (I print a "-" instead of the compile level for tiered): > > 2077 0 n - java.lang.System::nanoTime (0 bytes) (static) > > But the output might look a little odd since the native wrapper output may be between compile output and inline output looking like the native wrapper has an inlinee: > > 2102 69 3 java.lang.CharacterDataLatin1::toUpperCaseEx (71 bytes) > 2102 0 n - sun.misc.Unsafe::compareAndSwapInt (0 bytes) > @ 4 java.lang.CharacterDataLatin1::getProperties (11 bytes) > > About the compile id for native wrappers, assign_compile_id has an assert: > > assert(!method->is_native(), "no longer compile natives"); > > So either we remove that assert or we don't assign a compile id to native wrapper compiles. > > Let me know what you think. > > -- Christian > > PS: The original bug fix is still in there :-) From tom.rodriguez at oracle.com Fri Mar 18 10:03:16 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 18 Mar 2011 10:03:16 -0700 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <941F1787-3730-40B3-B4FE-5D50E5DCF408@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> <26256988-B1B9-4D29-8AA1-050F3D7A9147@oracle.com> <8822AEC2-212C-4ED1-BE34-A3B42E51BB27@oracle.com> <941F1787-3730-40B3-B4FE-5D50E5DCF408@oracle.com> Message-ID: <6D91E87F-B862-4E8C-8AFF-4BB9DBF71BF6@oracle.com> compileBroker.hpp: You can't call get_methodOop here. + static void print_inlining(ciMethod* method, int inline_level, int bci, const char* msg = NULL) { + print_inlining(tty, method->get_methodOop(), inline_level, bci, msg); + } since you are in native mode. You have to transition to VM or you have rearrange it so that you can use the ciMethod methods to unpack it directly. You might be able to get away with templating it since I think ciMethod and methodOop have similar calling interfaces. compileBroker.cpp: I think you can just lock MethodCompileQueue_lock directly instead of indirecting through the queue. Remove the is_native assert. I don't like the z/e flag since we already print the whole thing follow it. Overall it looks very good. tom On Mar 18, 2011, at 9:18 AM, Christian Thalinger wrote: > On Mar 17, 2011, at 7:19 PM, Tom Rodriguez wrote: >>>> Native wrappers are never inlined. That would be a intrinsic in the output you show above. Intrinsic inlining should always have a bci though. >>> >>> Ahh, right, I mixed them. When I'm already at it, should I change the intrinsic output too: >>> >>> Inlining intrinsic _min at bci:67 in sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (489 bytes) >>> >>> to fit into the inlining tree? >> >> I wouldn't mind that. Something like the normal output but with "(intrinsic)" at the end? > > Alright, I changed a lot more than I wanted to but now it seems much better and clearer, at least to me. > > I removed nmethod::print_compilation completely (which was called from CompileTask::print_compilation) and moved all printing logic into CompileTask. > > http://cr.openjdk.java.net/~twisti/7022998/ > > Some output looks a little different now, like instrinsics (as we talked about): > > 1111 3 java.lang.String::lastIndexOf (68 bytes) > @ 26 java.lang.Math::min (11 bytes) (intrinsic) > > To be able to remove some utterly complex code (the title code from nmethod::print_compilation), made_not_entrant and made_zombie messages are now printed and the end of the line (like all other status messages). Additionally I added a status flag (e = not entrant, z = zombie): > > 4006 150 z 4 java.lang.String::equals (88 bytes) made zombie > 4565 121 e 3 java.util.HashMap::get (79 bytes) made not entrant > > Type profile output looks like: > > @ 121 java.util.HashMap::addEntry (58 bytes) inline (hot) > \-> TypeProfile (6020/6257 counts) = java/util/HashMap > > or: > > @ 89 java.util.LinkedHashMap$Entry::recordAccess (35 bytes) inline (hot) > \-> TypeProfile (13/131 counts) = java/util/LinkedHashMap$Entry > \-> TypeProfile (118/131 counts) = java/util/HashMap$Entry > > Native wrapper compiles now look like this (I print a "-" instead of the compile level for tiered): > > 2077 0 n - java.lang.System::nanoTime (0 bytes) (static) > > But the output might look a little odd since the native wrapper output may be between compile output and inline output looking like the native wrapper has an inlinee: > > 2102 69 3 java.lang.CharacterDataLatin1::toUpperCaseEx (71 bytes) > 2102 0 n - sun.misc.Unsafe::compareAndSwapInt (0 bytes) > @ 4 java.lang.CharacterDataLatin1::getProperties (11 bytes) > > About the compile id for native wrappers, assign_compile_id has an assert: > > assert(!method->is_native(), "no longer compile natives"); > > So either we remove that assert or we don't assign a compile id to native wrapper compiles. > > Let me know what you think. > > -- Christian > > PS: The original bug fix is still in there :-) From tom.rodriguez at oracle.com Fri Mar 18 10:03:41 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 18 Mar 2011 10:03:41 -0700 Subject: Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc In-Reply-To: <4D838BF9.5050203@oracle.com> References: <4D7FA058.4000208@oracle.com> <257D9E62-1674-4F0B-B9D3-E6F27962D97B@oracle.com> <4D823D42.5070307@oracle.com> <436C2BD2-CF53-4446-8DD9-AA5F5AACADC8@oracle.com> <4D838BF9.5050203@oracle.com> Message-ID: Yes looks good. tom On Mar 18, 2011, at 9:44 AM, Vladimir Kozlov wrote: > Yes, thank you Christian > > Vladimir > > Christian Thalinger wrote: >> On Mar 17, 2011, at 5:56 PM, Vladimir Kozlov wrote: >>> Sorry for arguing about few lines but I think without renaming the code will be better (6 new lines instead of 7): >>> >>> + #ifdef _LP64 >>> + __ ldsw(arg_lsw, O2_scratch); // Load LSW >>> + #else >>> + __ ldsw(arg_lsw, O3_scratch); // Load LSW >>> + __ srlx(O3_scratch, BitsPerInt, O2_scratch)); // Move MSW value to lower 32-bits for STD >>> + #endif >>> __ st_long(O2_scratch, arg_msw); // Uses O2/O3 on !_LP64 >> Alright. I changed my code. Okay to push? >> -- Christian >>> Vladimir >>> >>> On 3/17/11 2:24 AM, Christian Thalinger wrote: >>>> On Mar 15, 2011, at 6:22 PM, Vladimir Kozlov wrote: >>>>> Christian, >>>>> >>>>> We don't support little-endian SPARC, why add a code which will never be executed? >>>> I thought to be on the safe side if anyone ever wants to support it. Anyway, I removed it and updated the webrev. >>>> >>>> -- Christian >>>> >>>>> On side note (RFE): we should officially drop v8 support (C2 does not support already, only C1). There are already several places where we use stx/ldx without check that it is v9 (yes, we still have an assert which is fine). Also std/ldd is emulated on modern SPARC and so is very slow. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Christian Thalinger wrote: >>>>>> http://cr.openjdk.java.net/~twisti/7027232/ >>>>>> 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc >>>>>> Reviewed-by: >>>>>> After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on >>>>>> 32-bit SPARC. st_long uses STD on 32-bit SPARC and the LSW and MSW >>>>>> bits are not moved to the proper registers resulting in a wrong >>>>>> result. >>>>>> The fix is to use the correct registers for 32-bit big-endian and >>>>>> little-endian (just in case) SPARC. >>>>>> src/cpu/sparc/vm/methodHandles_sparc.cpp From christian.thalinger at oracle.com Fri Mar 18 10:13:32 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Mar 2011 18:13:32 +0100 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <4D838D9E.9010009@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> <26256988-B1B9-4D29-8AA1-050F3D7A9147@oracle.com> <8822AEC2-212C-4ED1-BE34-A3B42E51BB27@oracle.com> <941F1787-3730-40B3-B4FE-5D50E5DCF408@oracle.com> <4D838D9E.9010009@oracle.com> Message-ID: On Mar 18, 2011, at 5:51 PM, Vladimir Kozlov wrote: > I like these changes :) Thank you for doing this. > > Remove the assert. Why you got compile_id 0 for native wrapper? That was before I commented the assert, I just assigned 0. I just did an additional change: we can print the native wrapper after it was created and use the print_compilation method that takes an nmethod. Then we can remove this version: static void print_compilation(outputStream* st, methodOop method, int compile_id, const char* msg = NULL) { webrev updated. -- Christian > > Thanks, > Vladimir > > Christian Thalinger wrote: >> On Mar 17, 2011, at 7:19 PM, Tom Rodriguez wrote: >>>>> Native wrappers are never inlined. That would be a intrinsic in the output you show above. Intrinsic inlining should always have a bci though. >>>> Ahh, right, I mixed them. When I'm already at it, should I change the intrinsic output too: >>>> >>>> Inlining intrinsic _min at bci:67 in sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (489 bytes) >>>> >>>> to fit into the inlining tree? >>> I wouldn't mind that. Something like the normal output but with "(intrinsic)" at the end? >> Alright, I changed a lot more than I wanted to but now it seems much better and clearer, at least to me. >> I removed nmethod::print_compilation completely (which was called from CompileTask::print_compilation) and moved all printing logic into CompileTask. >> http://cr.openjdk.java.net/~twisti/7022998/ >> Some output looks a little different now, like instrinsics (as we talked about): >> 1111 3 java.lang.String::lastIndexOf (68 bytes) >> @ 26 java.lang.Math::min (11 bytes) (intrinsic) >> To be able to remove some utterly complex code (the title code from nmethod::print_compilation), made_not_entrant and made_zombie messages are now printed and the end of the line (like all other status messages). Additionally I added a status flag (e = not entrant, z = zombie): >> 4006 150 z 4 java.lang.String::equals (88 bytes) made zombie >> 4565 121 e 3 java.util.HashMap::get (79 bytes) made not entrant >> Type profile output looks like: >> @ 121 java.util.HashMap::addEntry (58 bytes) inline (hot) >> \-> TypeProfile (6020/6257 counts) = java/util/HashMap >> or: >> @ 89 java.util.LinkedHashMap$Entry::recordAccess (35 bytes) inline (hot) >> \-> TypeProfile (13/131 counts) = java/util/LinkedHashMap$Entry >> \-> TypeProfile (118/131 counts) = java/util/HashMap$Entry >> Native wrapper compiles now look like this (I print a "-" instead of the compile level for tiered): >> 2077 0 n - java.lang.System::nanoTime (0 bytes) (static) >> But the output might look a little odd since the native wrapper output may be between compile output and inline output looking like the native wrapper has an inlinee: >> 2102 69 3 java.lang.CharacterDataLatin1::toUpperCaseEx (71 bytes) >> 2102 0 n - sun.misc.Unsafe::compareAndSwapInt (0 bytes) @ 4 java.lang.CharacterDataLatin1::getProperties (11 bytes) >> About the compile id for native wrappers, assign_compile_id has an assert: >> assert(!method->is_native(), "no longer compile natives"); So either we remove that assert or we don't assign a compile id to native wrapper compiles. >> Let me know what you think. >> -- Christian >> PS: The original bug fix is still in there :-) From christian.thalinger at oracle.com Fri Mar 18 10:28:08 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Mar 2011 18:28:08 +0100 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <6D91E87F-B862-4E8C-8AFF-4BB9DBF71BF6@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> <26256988-B1B9-4D29-8AA1-050F3D7A9147@oracle.com> <8822AEC2-212C-4ED1-BE34-A3B42E51BB27@oracle.com> <941F1787-3730-40B3-B4FE-5D50E5DCF408@oracle.com> <6D91E87F-B862-4E8C-8AFF-4BB9DBF71BF6@oracle.com> Message-ID: <4B75B758-4722-49ED-8305-C69E39D36618@oracle.com> On Mar 18, 2011, at 6:03 PM, Tom Rodriguez wrote: > compileBroker.hpp: > > You can't call get_methodOop here. > > + static void print_inlining(ciMethod* method, int inline_level, int bci, const char* msg = NULL) { > + print_inlining(tty, method->get_methodOop(), inline_level, bci, msg); > + } > > since you are in native mode. You have to transition to VM or you have rearrange it so that you can use the ciMethod methods to unpack it directly. You might be able to get away with templating it since I think ciMethod and methodOop have similar calling interfaces. I thought I get into trouble using methodOop directly here. Templating is a good idea but there is a small difference: methodOopDesc::has_exception_handler vs. ciMethod::has_exception_handlers > > compileBroker.cpp: > > I think you can just lock MethodCompileQueue_lock directly instead of indirecting through the queue. OK. > > Remove the is_native assert. OK. > > I don't like the z/e flag since we already print the whole thing follow it. How about removing the following output? The z/e flag is better to see than some unaligned output at the end of the line. -- Christian > > Overall it looks very good. > > tom > > On Mar 18, 2011, at 9:18 AM, Christian Thalinger wrote: > >> On Mar 17, 2011, at 7:19 PM, Tom Rodriguez wrote: >>>>> Native wrappers are never inlined. That would be a intrinsic in the output you show above. Intrinsic inlining should always have a bci though. >>>> >>>> Ahh, right, I mixed them. When I'm already at it, should I change the intrinsic output too: >>>> >>>> Inlining intrinsic _min at bci:67 in sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (489 bytes) >>>> >>>> to fit into the inlining tree? >>> >>> I wouldn't mind that. Something like the normal output but with "(intrinsic)" at the end? >> >> Alright, I changed a lot more than I wanted to but now it seems much better and clearer, at least to me. >> >> I removed nmethod::print_compilation completely (which was called from CompileTask::print_compilation) and moved all printing logic into CompileTask. >> >> http://cr.openjdk.java.net/~twisti/7022998/ >> >> Some output looks a little different now, like instrinsics (as we talked about): >> >> 1111 3 java.lang.String::lastIndexOf (68 bytes) >> @ 26 java.lang.Math::min (11 bytes) (intrinsic) >> >> To be able to remove some utterly complex code (the title code from nmethod::print_compilation), made_not_entrant and made_zombie messages are now printed and the end of the line (like all other status messages). Additionally I added a status flag (e = not entrant, z = zombie): >> >> 4006 150 z 4 java.lang.String::equals (88 bytes) made zombie >> 4565 121 e 3 java.util.HashMap::get (79 bytes) made not entrant >> >> Type profile output looks like: >> >> @ 121 java.util.HashMap::addEntry (58 bytes) inline (hot) >> \-> TypeProfile (6020/6257 counts) = java/util/HashMap >> >> or: >> >> @ 89 java.util.LinkedHashMap$Entry::recordAccess (35 bytes) inline (hot) >> \-> TypeProfile (13/131 counts) = java/util/LinkedHashMap$Entry >> \-> TypeProfile (118/131 counts) = java/util/HashMap$Entry >> >> Native wrapper compiles now look like this (I print a "-" instead of the compile level for tiered): >> >> 2077 0 n - java.lang.System::nanoTime (0 bytes) (static) >> >> But the output might look a little odd since the native wrapper output may be between compile output and inline output looking like the native wrapper has an inlinee: >> >> 2102 69 3 java.lang.CharacterDataLatin1::toUpperCaseEx (71 bytes) >> 2102 0 n - sun.misc.Unsafe::compareAndSwapInt (0 bytes) >> @ 4 java.lang.CharacterDataLatin1::getProperties (11 bytes) >> >> About the compile id for native wrappers, assign_compile_id has an assert: >> >> assert(!method->is_native(), "no longer compile natives"); >> >> So either we remove that assert or we don't assign a compile id to native wrapper compiles. >> >> Let me know what you think. >> >> -- Christian >> >> PS: The original bug fix is still in there :-) From christian.thalinger at oracle.com Fri Mar 18 10:29:31 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Mar 2011 18:29:31 +0100 Subject: Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc In-Reply-To: References: <4D7FA058.4000208@oracle.com> <257D9E62-1674-4F0B-B9D3-E6F27962D97B@oracle.com> <4D823D42.5070307@oracle.com> <436C2BD2-CF53-4446-8DD9-AA5F5AACADC8@oracle.com> <4D838BF9.5050203@oracle.com> Message-ID: <6B445F76-95A1-4608-8889-BA4DEB5D017C@oracle.com> Thank you both for the review. -- Christian On Mar 18, 2011, at 6:03 PM, Tom Rodriguez wrote: > Yes looks good. > > tom > > On Mar 18, 2011, at 9:44 AM, Vladimir Kozlov wrote: > >> Yes, thank you Christian >> >> Vladimir >> >> Christian Thalinger wrote: >>> On Mar 17, 2011, at 5:56 PM, Vladimir Kozlov wrote: >>>> Sorry for arguing about few lines but I think without renaming the code will be better (6 new lines instead of 7): >>>> >>>> + #ifdef _LP64 >>>> + __ ldsw(arg_lsw, O2_scratch); // Load LSW >>>> + #else >>>> + __ ldsw(arg_lsw, O3_scratch); // Load LSW >>>> + __ srlx(O3_scratch, BitsPerInt, O2_scratch)); // Move MSW value to lower 32-bits for STD >>>> + #endif >>>> __ st_long(O2_scratch, arg_msw); // Uses O2/O3 on !_LP64 >>> Alright. I changed my code. Okay to push? >>> -- Christian >>>> Vladimir >>>> >>>> On 3/17/11 2:24 AM, Christian Thalinger wrote: >>>>> On Mar 15, 2011, at 6:22 PM, Vladimir Kozlov wrote: >>>>>> Christian, >>>>>> >>>>>> We don't support little-endian SPARC, why add a code which will never be executed? >>>>> I thought to be on the safe side if anyone ever wants to support it. Anyway, I removed it and updated the webrev. >>>>> >>>>> -- Christian >>>>> >>>>>> On side note (RFE): we should officially drop v8 support (C2 does not support already, only C1). There are already several places where we use stx/ldx without check that it is v9 (yes, we still have an assert which is fine). Also std/ldd is emulated on modern SPARC and so is very slow. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Christian Thalinger wrote: >>>>>>> http://cr.openjdk.java.net/~twisti/7027232/ >>>>>>> 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc >>>>>>> Reviewed-by: >>>>>>> After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on >>>>>>> 32-bit SPARC. st_long uses STD on 32-bit SPARC and the LSW and MSW >>>>>>> bits are not moved to the proper registers resulting in a wrong >>>>>>> result. >>>>>>> The fix is to use the correct registers for 32-bit big-endian and >>>>>>> little-endian (just in case) SPARC. >>>>>>> src/cpu/sparc/vm/methodHandles_sparc.cpp From vladimir.kozlov at oracle.com Fri Mar 18 10:34:00 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Mar 2011 10:34:00 -0700 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> <26256988-B1B9-4D29-8AA1-050F3D7A9147@oracle.com> <8822AEC2-212C-4ED1-BE34-A3B42E51BB27@oracle.com> <941F1787-3730-40B3-B4FE-5D50E5DCF408@oracle.com> <4D838D9E.9010009@oracle.com> Message-ID: <4D839788.7070606@oracle.com> OK. Vladimir Christian Thalinger wrote: > On Mar 18, 2011, at 5:51 PM, Vladimir Kozlov wrote: >> I like these changes :) Thank you for doing this. >> >> Remove the assert. Why you got compile_id 0 for native wrapper? > > That was before I commented the assert, I just assigned 0. > > I just did an additional change: we can print the native wrapper after it was created and use the print_compilation method that takes an nmethod. Then we can remove this version: > > static void print_compilation(outputStream* st, methodOop method, int compile_id, const char* msg = NULL) { > > webrev updated. > > -- Christian > >> Thanks, >> Vladimir >> >> Christian Thalinger wrote: >>> On Mar 17, 2011, at 7:19 PM, Tom Rodriguez wrote: >>>>>> Native wrappers are never inlined. That would be a intrinsic in the output you show above. Intrinsic inlining should always have a bci though. >>>>> Ahh, right, I mixed them. When I'm already at it, should I change the intrinsic output too: >>>>> >>>>> Inlining intrinsic _min at bci:67 in sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (489 bytes) >>>>> >>>>> to fit into the inlining tree? >>>> I wouldn't mind that. Something like the normal output but with "(intrinsic)" at the end? >>> Alright, I changed a lot more than I wanted to but now it seems much better and clearer, at least to me. >>> I removed nmethod::print_compilation completely (which was called from CompileTask::print_compilation) and moved all printing logic into CompileTask. >>> http://cr.openjdk.java.net/~twisti/7022998/ >>> Some output looks a little different now, like instrinsics (as we talked about): >>> 1111 3 java.lang.String::lastIndexOf (68 bytes) >>> @ 26 java.lang.Math::min (11 bytes) (intrinsic) >>> To be able to remove some utterly complex code (the title code from nmethod::print_compilation), made_not_entrant and made_zombie messages are now printed and the end of the line (like all other status messages). Additionally I added a status flag (e = not entrant, z = zombie): >>> 4006 150 z 4 java.lang.String::equals (88 bytes) made zombie >>> 4565 121 e 3 java.util.HashMap::get (79 bytes) made not entrant >>> Type profile output looks like: >>> @ 121 java.util.HashMap::addEntry (58 bytes) inline (hot) >>> \-> TypeProfile (6020/6257 counts) = java/util/HashMap >>> or: >>> @ 89 java.util.LinkedHashMap$Entry::recordAccess (35 bytes) inline (hot) >>> \-> TypeProfile (13/131 counts) = java/util/LinkedHashMap$Entry >>> \-> TypeProfile (118/131 counts) = java/util/HashMap$Entry >>> Native wrapper compiles now look like this (I print a "-" instead of the compile level for tiered): >>> 2077 0 n - java.lang.System::nanoTime (0 bytes) (static) >>> But the output might look a little odd since the native wrapper output may be between compile output and inline output looking like the native wrapper has an inlinee: >>> 2102 69 3 java.lang.CharacterDataLatin1::toUpperCaseEx (71 bytes) >>> 2102 0 n - sun.misc.Unsafe::compareAndSwapInt (0 bytes) @ 4 java.lang.CharacterDataLatin1::getProperties (11 bytes) >>> About the compile id for native wrappers, assign_compile_id has an assert: >>> assert(!method->is_native(), "no longer compile natives"); So either we remove that assert or we don't assign a compile id to native wrapper compiles. >>> Let me know what you think. >>> -- Christian >>> PS: The original bug fix is still in there :-) > > From vladimir.kozlov at oracle.com Fri Mar 18 10:41:22 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Mar 2011 10:41:22 -0700 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <4B75B758-4722-49ED-8305-C69E39D36618@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> <26256988-B1B9-4D29-8AA1-050F3D7A9147@oracle.com> <8822AEC2-212C-4ED1-BE34-A3B42E51BB27@oracle.com> <941F1787-3730-40B3-B4FE-5D50E5DCF408@oracle.com> <6D91E87F-B862-4E8C-8AFF-4BB9DBF71BF6@oracle.com> <4B75B758-4722-49ED-8305-C69E39D36618@oracle.com> Message-ID: <4D839942.6080501@oracle.com> I would better keep "made zombie" and "made not entrant" than new z/e flags. Vladimir Christian Thalinger wrote: > On Mar 18, 2011, at 6:03 PM, Tom Rodriguez wrote: >> compileBroker.hpp: >> >> You can't call get_methodOop here. >> >> + static void print_inlining(ciMethod* method, int inline_level, int bci, const char* msg = NULL) { >> + print_inlining(tty, method->get_methodOop(), inline_level, bci, msg); >> + } >> >> since you are in native mode. You have to transition to VM or you have rearrange it so that you can use the ciMethod methods to unpack it directly. You might be able to get away with templating it since I think ciMethod and methodOop have similar calling interfaces. > > I thought I get into trouble using methodOop directly here. Templating is a good idea but there is a small difference: > > methodOopDesc::has_exception_handler > > vs. > > ciMethod::has_exception_handlers > >> compileBroker.cpp: >> >> I think you can just lock MethodCompileQueue_lock directly instead of indirecting through the queue. > > OK. > >> Remove the is_native assert. > > OK. > >> I don't like the z/e flag since we already print the whole thing follow it. > > How about removing the following output? The z/e flag is better to see than some unaligned output at the end of the line. > > -- Christian > >> Overall it looks very good. >> >> tom >> >> On Mar 18, 2011, at 9:18 AM, Christian Thalinger wrote: >> >>> On Mar 17, 2011, at 7:19 PM, Tom Rodriguez wrote: >>>>>> Native wrappers are never inlined. That would be a intrinsic in the output you show above. Intrinsic inlining should always have a bci though. >>>>> Ahh, right, I mixed them. When I'm already at it, should I change the intrinsic output too: >>>>> >>>>> Inlining intrinsic _min at bci:67 in sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (489 bytes) >>>>> >>>>> to fit into the inlining tree? >>>> I wouldn't mind that. Something like the normal output but with "(intrinsic)" at the end? >>> Alright, I changed a lot more than I wanted to but now it seems much better and clearer, at least to me. >>> >>> I removed nmethod::print_compilation completely (which was called from CompileTask::print_compilation) and moved all printing logic into CompileTask. >>> >>> http://cr.openjdk.java.net/~twisti/7022998/ >>> >>> Some output looks a little different now, like instrinsics (as we talked about): >>> >>> 1111 3 java.lang.String::lastIndexOf (68 bytes) >>> @ 26 java.lang.Math::min (11 bytes) (intrinsic) >>> >>> To be able to remove some utterly complex code (the title code from nmethod::print_compilation), made_not_entrant and made_zombie messages are now printed and the end of the line (like all other status messages). Additionally I added a status flag (e = not entrant, z = zombie): >>> >>> 4006 150 z 4 java.lang.String::equals (88 bytes) made zombie >>> 4565 121 e 3 java.util.HashMap::get (79 bytes) made not entrant >>> >>> Type profile output looks like: >>> >>> @ 121 java.util.HashMap::addEntry (58 bytes) inline (hot) >>> \-> TypeProfile (6020/6257 counts) = java/util/HashMap >>> >>> or: >>> >>> @ 89 java.util.LinkedHashMap$Entry::recordAccess (35 bytes) inline (hot) >>> \-> TypeProfile (13/131 counts) = java/util/LinkedHashMap$Entry >>> \-> TypeProfile (118/131 counts) = java/util/HashMap$Entry >>> >>> Native wrapper compiles now look like this (I print a "-" instead of the compile level for tiered): >>> >>> 2077 0 n - java.lang.System::nanoTime (0 bytes) (static) >>> >>> But the output might look a little odd since the native wrapper output may be between compile output and inline output looking like the native wrapper has an inlinee: >>> >>> 2102 69 3 java.lang.CharacterDataLatin1::toUpperCaseEx (71 bytes) >>> 2102 0 n - sun.misc.Unsafe::compareAndSwapInt (0 bytes) >>> @ 4 java.lang.CharacterDataLatin1::getProperties (11 bytes) >>> >>> About the compile id for native wrappers, assign_compile_id has an assert: >>> >>> assert(!method->is_native(), "no longer compile natives"); >>> >>> So either we remove that assert or we don't assign a compile id to native wrapper compiles. >>> >>> Let me know what you think. >>> >>> -- Christian >>> >>> PS: The original bug fix is still in there :-) > > From christian.thalinger at oracle.com Fri Mar 18 10:46:22 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Mar 2011 18:46:22 +0100 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <4B75B758-4722-49ED-8305-C69E39D36618@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> <26256988-B1B9-4D29-8AA1-050F3D7A9147@oracle.com> <8822AEC2-212C-4ED1-BE34-A3B42E51BB27@oracle.com> <941F1787-3730-40B3-B4FE-5D50E5DCF408@oracle.com> <6D91E87F-B862-4E8C-8AFF-4BB9DBF71BF6@oracle.com> <4B75B758-4722-49ED-8305-C69E39D36618@oracle.com> Message-ID: <20F3B416-8677-4113-AE48-08DB65430B62@oracle.com> On Mar 18, 2011, at 6:28 PM, Christian Thalinger wrote: > On Mar 18, 2011, at 6:03 PM, Tom Rodriguez wrote: >> compileBroker.hpp: >> >> You can't call get_methodOop here. >> >> + static void print_inlining(ciMethod* method, int inline_level, int bci, const char* msg = NULL) { >> + print_inlining(tty, method->get_methodOop(), inline_level, bci, msg); >> + } >> >> since you are in native mode. You have to transition to VM or you have rearrange it so that you can use the ciMethod methods to unpack it directly. You might be able to get away with templating it since I think ciMethod and methodOop have similar calling interfaces. > > I thought I get into trouble using methodOop directly here. Templating is a good idea but there is a small difference: > > methodOopDesc::has_exception_handler > > vs. > > ciMethod::has_exception_handlers Wait! We don't need a version that takes a methodOop, it's never called. We can use ciMethod instead. -- Christian From christian.thalinger at oracle.com Fri Mar 18 10:48:14 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Mar 2011 18:48:14 +0100 Subject: Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely In-Reply-To: <4D839942.6080501@oracle.com> References: <2E012F22-3B93-491B-9B06-A7E0042AB612@oracle.com> <4D7F9A84.5080907@oracle.com> <4D7FB2BC.409@oracle.com> <993787CB-45CD-4633-80B5-0CE815CEFBCC@oracle.com> <004FA2A8-E5F4-439D-B853-CA29427B97D3@oracle.com> <6DC16D10-0C5D-4C28-9767-F8C2A1BA52A2@oracle.com> <26256988-B1B9-4D29-8AA1-050F3D7A9147@oracle.com> <8822AEC2-212C-4ED1-BE34-A3B42E51BB27@oracle.com> <941F1787-3730-40B3-B4FE-5D50E5DCF408@oracle.com> <6D91E87F-B862-4E8C-8AFF-4BB9DBF71BF6@oracle.com> <4B75B758-4722-49ED-8305-C69E39D36618@oracle.com> <4D839942.6080501@oracle.com> Message-ID: On Mar 18, 2011, at 6:41 PM, Vladimir Kozlov wrote: > I would better keep "made zombie" and "made not entrant" than new z/e flags. Alright. I removed them. -- Christian > > Vladimir > > Christian Thalinger wrote: >> On Mar 18, 2011, at 6:03 PM, Tom Rodriguez wrote: >>> compileBroker.hpp: >>> >>> You can't call get_methodOop here. >>> >>> + static void print_inlining(ciMethod* method, int inline_level, int bci, const char* msg = NULL) { >>> + print_inlining(tty, method->get_methodOop(), inline_level, bci, msg); >>> + } >>> >>> since you are in native mode. You have to transition to VM or you have rearrange it so that you can use the ciMethod methods to unpack it directly. You might be able to get away with templating it since I think ciMethod and methodOop have similar calling interfaces. >> I thought I get into trouble using methodOop directly here. Templating is a good idea but there is a small difference: >> methodOopDesc::has_exception_handler >> vs. >> ciMethod::has_exception_handlers >>> compileBroker.cpp: >>> >>> I think you can just lock MethodCompileQueue_lock directly instead of indirecting through the queue. >> OK. >>> Remove the is_native assert. >> OK. >>> I don't like the z/e flag since we already print the whole thing follow it. >> How about removing the following output? The z/e flag is better to see than some unaligned output at the end of the line. >> -- Christian >>> Overall it looks very good. >>> >>> tom >>> >>> On Mar 18, 2011, at 9:18 AM, Christian Thalinger wrote: >>> >>>> On Mar 17, 2011, at 7:19 PM, Tom Rodriguez wrote: >>>>>>> Native wrappers are never inlined. That would be a intrinsic in the output you show above. Intrinsic inlining should always have a bci though. >>>>>> Ahh, right, I mixed them. When I'm already at it, should I change the intrinsic output too: >>>>>> >>>>>> Inlining intrinsic _min at bci:67 in sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (489 bytes) >>>>>> >>>>>> to fit into the inlining tree? >>>>> I wouldn't mind that. Something like the normal output but with "(intrinsic)" at the end? >>>> Alright, I changed a lot more than I wanted to but now it seems much better and clearer, at least to me. >>>> >>>> I removed nmethod::print_compilation completely (which was called from CompileTask::print_compilation) and moved all printing logic into CompileTask. >>>> >>>> http://cr.openjdk.java.net/~twisti/7022998/ >>>> >>>> Some output looks a little different now, like instrinsics (as we talked about): >>>> >>>> 1111 3 java.lang.String::lastIndexOf (68 bytes) >>>> @ 26 java.lang.Math::min (11 bytes) (intrinsic) >>>> >>>> To be able to remove some utterly complex code (the title code from nmethod::print_compilation), made_not_entrant and made_zombie messages are now printed and the end of the line (like all other status messages). Additionally I added a status flag (e = not entrant, z = zombie): >>>> >>>> 4006 150 z 4 java.lang.String::equals (88 bytes) made zombie >>>> 4565 121 e 3 java.util.HashMap::get (79 bytes) made not entrant >>>> >>>> Type profile output looks like: >>>> >>>> @ 121 java.util.HashMap::addEntry (58 bytes) inline (hot) >>>> \-> TypeProfile (6020/6257 counts) = java/util/HashMap >>>> >>>> or: >>>> >>>> @ 89 java.util.LinkedHashMap$Entry::recordAccess (35 bytes) inline (hot) >>>> \-> TypeProfile (13/131 counts) = java/util/LinkedHashMap$Entry >>>> \-> TypeProfile (118/131 counts) = java/util/HashMap$Entry >>>> >>>> Native wrapper compiles now look like this (I print a "-" instead of the compile level for tiered): >>>> >>>> 2077 0 n - java.lang.System::nanoTime (0 bytes) (static) >>>> >>>> But the output might look a little odd since the native wrapper output may be between compile output and inline output looking like the native wrapper has an inlinee: >>>> >>>> 2102 69 3 java.lang.CharacterDataLatin1::toUpperCaseEx (71 bytes) >>>> 2102 0 n - sun.misc.Unsafe::compareAndSwapInt (0 bytes) @ 4 java.lang.CharacterDataLatin1::getProperties (11 bytes) >>>> >>>> About the compile id for native wrappers, assign_compile_id has an assert: >>>> >>>> assert(!method->is_native(), "no longer compile natives"); >>>> So either we remove that assert or we don't assign a compile id to native wrapper compiles. >>>> >>>> Let me know what you think. >>>> >>>> -- Christian >>>> >>>> PS: The original bug fix is still in there :-) From tom.rodriguez at oracle.com Fri Mar 18 16:19:46 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 18 Mar 2011 16:19:46 -0700 Subject: Request for reviews (L): 7008866: Missing loop predicate for loop with multiple entries In-Reply-To: <4D7E8E84.6050303@oracle.com> References: <4D7E8E84.6050303@oracle.com> Message-ID: <4D8F6FAE-C3CF-4F63-9982-A5E304CDFA87@oracle.com> is_canonical_counted reads weird. Maybe is_valid_counted_loop? Do the intrinsics really benefit from having predicates? Most those assume that Strings are well formed and don't have range checks. If you have the urge, a lot of the code that simply moved could have its "if( " whitespace corrected. loopnode.cpp: Is this no longer needed or did it more somewhere? _igvn.hash_delete(phi); phi->set_req_X( LoopNode::LoopBackControl, incr, &_igvn ); // If phi type is more restrictive than Int, raise to // Int to prevent (almost) infinite recursion in igvn // which can only handle integer types for constants or minint..maxint. if (!TypeInt::INT->higher_equal(phi->bottom_type())) { Node* nphi = PhiNode::make(phi->in(0), phi->in(LoopNode::EntryControl), TypeInt::INT); nphi->set_req(LoopNode::LoopBackControl, phi->in(LoopNode::LoopBackControl)); nphi = _igvn.register_new_node_with_optimizer(nphi); set_ctrl(nphi, get_ctrl(phi)); + nphi->set_req(LoopNode::LoopBackControl, incr); loopTransform.cpp: ! if (must_reason_predicate) { ! if (reason != Deoptimization::Reason_none) { Shouldn't that really be reason == Deoptimization::Reason_predicate? That the only one that expects the opaque node. Why does create_new_if_for_predicate have the two extra arguments? They are always passed as NULL, Deoptimization::Reason_predicate. Overall it looks fine to me. That factoring and sharing of logic is a nice improvement. tom On Mar 14, 2011, at 2:54 PM, Vladimir Kozlov wrote: > It is the first of coming loop opts changes. No benchmarks performance improvement is expected since main loops in our benchmarks have predicates already. > > http://cr.openjdk.java.net/~kvn/7008866/webrev > > Fixed 7008866: Missing loop predicate for loop with multiple entries > > Synopsis is a little misleading since I don't mean irreducible loop entries > (new code has a check to not add predicates to irreducible loops). I mean there > could be several entry and backbranch paths to loop head. > > Currently loop predicates are generated when each backbranch path is parsed. Later in IdealLoopTree::beautify_loops() a merge region will be created if there are several entry paths separating predicates from the loop. As result those predicates will be removed. > > Add predicates when loop head bytecode is parsed instead of when back branch > bytecode is parsed. All fall in paths will be merged already at this point and > for back branches a new merge region is created. > > Add missing loop predicate when there are back branches to the method entry > first bytecode. > > Add missing predicates for loops generated in Ideal graph, for example, for > intrinsics. > > Rearrange some code to help next loop optimization changes. For example, in > PhaseIdealLoop::is_counted_loop() move bailout checks before new ideal nodes are > generated. Add new counted loop verification code. > > Perform local Ideal transformation for parallel induction variables replacement > since in most cases they use the same stride (ratio == 1). > > In PhaseIdealLoop::split_thru_phi() don't move split node (or existing node > returned by Identity()) inside a loop if all its uses are outside of this loop. > Otherwise the node will be cloned for each outside use and this will mess up an > external canonical counted loop if the node is loop's increment, for example. > > Preserve unswitch count when partial peel is executed and when a loop is > converted to counted. > > Add debug flag TraceLoopOpts to show executed loop optimizations and also print > whole loop tree at the beginning of each iteration of loop optimizations: > > PartialPeel Loop: N22966/N22965 > > Tested: ctw, nsk, jprt > Ran refworkload on x86 - nor regression (or improvement). > From vladimir.kozlov at oracle.com Fri Mar 18 17:00:16 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Mar 2011 17:00:16 -0700 Subject: Request for reviews (L): 7008866: Missing loop predicate for loop with multiple entries In-Reply-To: <4D8F6FAE-C3CF-4F63-9982-A5E304CDFA87@oracle.com> References: <4D7E8E84.6050303@oracle.com> <4D8F6FAE-C3CF-4F63-9982-A5E304CDFA87@oracle.com> Message-ID: <4D83F210.6010900@oracle.com> Tom Rodriguez wrote: > is_canonical_counted reads weird. Maybe is_valid_counted_loop? OK. > > Do the intrinsics really benefit from having predicates? Most those assume that Strings are well formed and don't have range checks. For loop limit check fix I will use the same mechanism. So each loop should have a predicate, otherwise it will not be converted into CountedLoop since we can't insert a predicate check during ideal graph transformation (they are added during parsing to get correct jvm state). > > If you have the urge, a lot of the code that simply moved could have its "if( " whitespace corrected. You mean, to use "if (a) {" instead of "if( a )" ? OK. I am actually thinking to move all predicate code into separate file loopPredicate.cpp in predicates cloning changes. > > loopnode.cpp: > > Is this no longer needed or did it more somewhere? > > _igvn.hash_delete(phi); > phi->set_req_X( LoopNode::LoopBackControl, incr, &_igvn ); > > // If phi type is more restrictive than Int, raise to > // Int to prevent (almost) infinite recursion in igvn > // which can only handle integer types for constants or minint..maxint. > if (!TypeInt::INT->higher_equal(phi->bottom_type())) { > Node* nphi = PhiNode::make(phi->in(0), phi->in(LoopNode::EntryControl), TypeInt::INT); > nphi->set_req(LoopNode::LoopBackControl, phi->in(LoopNode::LoopBackControl)); > nphi = _igvn.register_new_node_with_optimizer(nphi); > set_ctrl(nphi, get_ctrl(phi)); > + nphi->set_req(LoopNode::LoopBackControl, incr); I want to avoid side effects of set_req_X() call so I am always replacing old phi with new one: + Node* nphi = PhiNode::make(x, init_trip, TypeInt::INT); + nphi = _igvn.register_new_node_with_optimizer(nphi); + set_ctrl(nphi, get_ctrl(phi)); > > loopTransform.cpp: > > ! if (must_reason_predicate) { > ! if (reason != Deoptimization::Reason_none) { > > Shouldn't that really be reason == Deoptimization::Reason_predicate? That the only one that expects the opaque node. Limit check will have different reason Deoptimization::Reason_loop_limit_check and I want to reuse this code for it. > > Why does create_new_if_for_predicate have the two extra arguments? They are always passed as NULL, Deoptimization::Reason_predicate. They will be used for predicates cloning and loop limit check. I am sorry, I cut these changes from much larger changes which include all work I did before. This is why they have this code. > > Overall it looks fine to me. That factoring and sharing of logic is a nice improvement. I also wanted to share range check code from do_range_check() and rc_predicate() but I need more time for it. Thanks, Vladimir > > tom > > On Mar 14, 2011, at 2:54 PM, Vladimir Kozlov wrote: > >> It is the first of coming loop opts changes. No benchmarks performance improvement is expected since main loops in our benchmarks have predicates already. >> >> http://cr.openjdk.java.net/~kvn/7008866/webrev >> >> Fixed 7008866: Missing loop predicate for loop with multiple entries >> >> Synopsis is a little misleading since I don't mean irreducible loop entries >> (new code has a check to not add predicates to irreducible loops). I mean there >> could be several entry and backbranch paths to loop head. >> >> Currently loop predicates are generated when each backbranch path is parsed. Later in IdealLoopTree::beautify_loops() a merge region will be created if there are several entry paths separating predicates from the loop. As result those predicates will be removed. >> >> Add predicates when loop head bytecode is parsed instead of when back branch >> bytecode is parsed. All fall in paths will be merged already at this point and >> for back branches a new merge region is created. >> >> Add missing loop predicate when there are back branches to the method entry >> first bytecode. >> >> Add missing predicates for loops generated in Ideal graph, for example, for >> intrinsics. >> >> Rearrange some code to help next loop optimization changes. For example, in >> PhaseIdealLoop::is_counted_loop() move bailout checks before new ideal nodes are >> generated. Add new counted loop verification code. >> >> Perform local Ideal transformation for parallel induction variables replacement >> since in most cases they use the same stride (ratio == 1). >> >> In PhaseIdealLoop::split_thru_phi() don't move split node (or existing node >> returned by Identity()) inside a loop if all its uses are outside of this loop. >> Otherwise the node will be cloned for each outside use and this will mess up an >> external canonical counted loop if the node is loop's increment, for example. >> >> Preserve unswitch count when partial peel is executed and when a loop is >> converted to counted. >> >> Add debug flag TraceLoopOpts to show executed loop optimizations and also print >> whole loop tree at the beginning of each iteration of loop optimizations: >> >> PartialPeel Loop: N22966/N22965 >> >> Tested: ctw, nsk, jprt >> Ran refworkload on x86 - nor regression (or improvement). >> > From tom.rodriguez at oracle.com Fri Mar 18 17:03:38 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 18 Mar 2011 17:03:38 -0700 Subject: Request for reviews (L): 7008866: Missing loop predicate for loop with multiple entries In-Reply-To: <4D83F210.6010900@oracle.com> References: <4D7E8E84.6050303@oracle.com> <4D8F6FAE-C3CF-4F63-9982-A5E304CDFA87@oracle.com> <4D83F210.6010900@oracle.com> Message-ID: <4130AA3E-74CF-4016-9BE3-D787A503CAD8@oracle.com> On Mar 18, 2011, at 5:00 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> is_canonical_counted reads weird. Maybe is_valid_counted_loop? > > OK. > >> Do the intrinsics really benefit from having predicates? Most those assume that Strings are well formed and don't have range checks. > > For loop limit check fix I will use the same mechanism. So each loop should have a predicate, otherwise it will not be converted into CountedLoop since we can't insert a predicate check during ideal graph transformation (they are added during parsing to get correct jvm state). Ok. > >> If you have the urge, a lot of the code that simply moved could have its "if( " whitespace corrected. > > You mean, to use "if (a) {" instead of "if( a )" ? OK. I am actually thinking to move all predicate code into separate file loopPredicate.cpp in predicates cloning changes. Yes. That sounds good. > >> loopnode.cpp: >> Is this no longer needed or did it more somewhere? >> _igvn.hash_delete(phi); >> phi->set_req_X( LoopNode::LoopBackControl, incr, &_igvn ); >> // If phi type is more restrictive than Int, raise to >> // Int to prevent (almost) infinite recursion in igvn >> // which can only handle integer types for constants or minint..maxint. >> if (!TypeInt::INT->higher_equal(phi->bottom_type())) { >> Node* nphi = PhiNode::make(phi->in(0), phi->in(LoopNode::EntryControl), TypeInt::INT); >> nphi->set_req(LoopNode::LoopBackControl, phi->in(LoopNode::LoopBackControl)); >> nphi = _igvn.register_new_node_with_optimizer(nphi); >> set_ctrl(nphi, get_ctrl(phi)); >> + nphi->set_req(LoopNode::LoopBackControl, incr); > > I want to avoid side effects of set_req_X() call so I am always replacing old phi with new one: > > + Node* nphi = PhiNode::make(x, init_trip, TypeInt::INT); > + nphi = _igvn.register_new_node_with_optimizer(nphi); > + set_ctrl(nphi, get_ctrl(phi)); Ok, I missed the earlier wide type. > >> loopTransform.cpp: >> ! if (must_reason_predicate) { >> ! if (reason != Deoptimization::Reason_none) { >> Shouldn't that really be reason == Deoptimization::Reason_predicate? That the only one that expects the opaque node. > > Limit check will have different reason Deoptimization::Reason_loop_limit_check and I want to reuse this code for it. Ok. > >> Why does create_new_if_for_predicate have the two extra arguments? They are always passed as NULL, Deoptimization::Reason_predicate. > > They will be used for predicates cloning and loop limit check. I am sorry, I cut these changes from much larger changes which include all work I did before. This is why they have this code. That's fine. > >> Overall it looks fine to me. That factoring and sharing of logic is a nice improvement. > > I also wanted to share range check code from do_range_check() and rc_predicate() but I need more time for it. Smaller pieces at a time is probably best. Looks good. tom > > Thanks, > Vladimir > >> tom >> On Mar 14, 2011, at 2:54 PM, Vladimir Kozlov wrote: >>> It is the first of coming loop opts changes. No benchmarks performance improvement is expected since main loops in our benchmarks have predicates already. >>> >>> http://cr.openjdk.java.net/~kvn/7008866/webrev >>> >>> Fixed 7008866: Missing loop predicate for loop with multiple entries >>> >>> Synopsis is a little misleading since I don't mean irreducible loop entries >>> (new code has a check to not add predicates to irreducible loops). I mean there >>> could be several entry and backbranch paths to loop head. >>> >>> Currently loop predicates are generated when each backbranch path is parsed. Later in IdealLoopTree::beautify_loops() a merge region will be created if there are several entry paths separating predicates from the loop. As result those predicates will be removed. >>> >>> Add predicates when loop head bytecode is parsed instead of when back branch >>> bytecode is parsed. All fall in paths will be merged already at this point and >>> for back branches a new merge region is created. >>> >>> Add missing loop predicate when there are back branches to the method entry >>> first bytecode. >>> >>> Add missing predicates for loops generated in Ideal graph, for example, for >>> intrinsics. >>> >>> Rearrange some code to help next loop optimization changes. For example, in >>> PhaseIdealLoop::is_counted_loop() move bailout checks before new ideal nodes are >>> generated. Add new counted loop verification code. >>> >>> Perform local Ideal transformation for parallel induction variables replacement >>> since in most cases they use the same stride (ratio == 1). >>> >>> In PhaseIdealLoop::split_thru_phi() don't move split node (or existing node >>> returned by Identity()) inside a loop if all its uses are outside of this loop. >>> Otherwise the node will be cloned for each outside use and this will mess up an >>> external canonical counted loop if the node is loop's increment, for example. >>> >>> Preserve unswitch count when partial peel is executed and when a loop is >>> converted to counted. >>> >>> Add debug flag TraceLoopOpts to show executed loop optimizations and also print >>> whole loop tree at the beginning of each iteration of loop optimizations: >>> >>> PartialPeel Loop: N22966/N22965 >>> >>> Tested: ctw, nsk, jprt >>> Ran refworkload on x86 - nor regression (or improvement). >>> From christian.thalinger at oracle.com Fri Mar 18 21:17:02 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 19 Mar 2011 04:17:02 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 14 new changesets Message-ID: <20110319041733.3E742472A6@hg.openjdk.java.net> Changeset: 70b50ac7e2af Author: cl Date: 2011-03-10 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/70b50ac7e2af Added tag jdk7-b133 for changeset 1b3a350709e4 ! .hgtags Changeset: 447e6faab4a8 Author: trims Date: 2011-03-11 11:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/447e6faab4a8 Merge Changeset: 02e6fc2effd8 Author: trims Date: 2011-03-11 22:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/02e6fc2effd8 Merge Changeset: 4f148718983e Author: bdelsart Date: 2011-03-10 17:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4f148718983e 7025485: leverage shared x86-only deoptimization code Summary: removed an ifdef IA32 around harmless code useful for some ports Reviewed-by: chrisphi, never ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp Changeset: 3d5a546351ef Author: phh Date: 2011-03-11 16:09 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3d5a546351ef 7023931: PcDescCache::find_pc_desc should not write _last_pc_desc Summary: Remove _last_pc_desc and use pcdescs[0] instead. Reviewed-by: dcubed, coleenp, ysr ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp Changeset: 4775a1e3e923 Author: acorn Date: 2011-03-14 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4775a1e3e923 Merge Changeset: 216d916d5c12 Author: dcubed Date: 2011-03-15 06:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/216d916d5c12 7024234: 2/3 jvmti tests fail assert(!_oops_are_stale) failed: oops are stale on Win-AMD64 Summary: Move initialization of the '_instance' field to avoid race with ServiceThread start. Reviewed-by: dholmes, kamg, never, dsamersoff, ysr, coleenp, acorn ! src/share/vm/runtime/serviceThread.cpp Changeset: 46a56fac55c7 Author: dcubed Date: 2011-03-15 06:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/46a56fac55c7 7024970: 2/3 assert(ServiceThread::is_service_thread(Thread::current())) failed: Service thread must post enqueue Summary: Change nmethod_lock() to also prevent zombification of the nmethod. CompiledMethodUnload events also need to lock the nmethod. Clean ups in nmethod::make_not_entrant_or_zombie() Reviewed-by: dholmes, kamg, never, dsamersoff, ysr, coleenp, acorn ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp Changeset: 65f880e2869b Author: dcubed Date: 2011-03-15 06:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/65f880e2869b Merge ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp Changeset: 8a3f8defe568 Author: coleenp Date: 2011-03-16 14:57 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8a3f8defe568 7019165: Incorrect symbols in pstack output after SymbolTable changes Summary: And out lsb which is set for symbols in constant pool slots to distinguish them from strings Reviewed-by: phh, dholmes, never, dcubed ! src/os/solaris/dtrace/libjvm_db.c Changeset: b9684d5ccb52 Author: vladidan Date: 2011-03-10 14:56 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b9684d5ccb52 7011490: Wrong computation results in Test6880034 Summary: incorrect handling of c2i deoptimization on little endian architectures Reviewed-by: never ! src/share/vm/c1/c1_LinearScan.cpp Changeset: bc57bfb5bfad Author: vladidan Date: 2011-03-16 10:47 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bc57bfb5bfad Merge Changeset: 2074c95f707e Author: vladidan Date: 2011-03-16 23:45 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2074c95f707e Merge Changeset: fc5ebbb2d1a8 Author: twisti Date: 2011-03-18 01:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fc5ebbb2d1a8 Merge ! src/share/vm/code/nmethod.cpp From mlists at juma.me.uk Sun Mar 20 07:48:12 2011 From: mlists at juma.me.uk (Ismael Juma) Date: Sun, 20 Mar 2011 14:48:12 +0000 (UTC) Subject: Bug 5091921: Sign flip issues in loop optimizer Message-ID: Hi, I came across a Lucene issue where it would read an index incorrectly due to a HotSpot bug[1]. In the issue tracker, they refer to two unfixed bugs in the Sun bug tracker: 5091921[2] and 7024475[3]. I am interested in the former because it was filed in 2004 and it has a number of duplicates (the most recent of which was filed last month - 7020614[4]). It seems pretty nasty and easy to reproduce with many isolated test cases, so I was wondering why it has remained unfixed for so long. Did it just fall through the cracks, is it complicated to fix or something else? Best, Ismael [1] https://issues.apache.org/jira/browse/LUCENE-2975 (hotspot bug in readvint gives wrong results) [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5091921 [3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7024475 [4] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7020614 From christian.thalinger at oracle.com Mon Mar 21 04:57:06 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 21 Mar 2011 11:57:06 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc Message-ID: <20110321115713.5809D4733C@hg.openjdk.java.net> Changeset: 3ef1a1866a60 Author: twisti Date: 2011-03-21 02:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3ef1a1866a60 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc Reviewed-by: kvn, never ! src/cpu/sparc/vm/methodHandles_sparc.cpp From roland.westrelin at oracle.com Mon Mar 21 08:51:02 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 21 Mar 2011 16:51:02 +0100 Subject: Request for review (M): 7029017 Additional architecture support for c2 compiler Message-ID: http://cr.openjdk.java.net/~roland/7029017/webrev.00/ Main changes are: - Enables cross building of a c2 VM. - Support masking of shift counts when the processor architecture mandates it. Roland. From vladimir.kozlov at oracle.com Mon Mar 21 09:40:13 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Mar 2011 09:40:13 -0700 Subject: Bug 5091921: Sign flip issues in loop optimizer In-Reply-To: References: Message-ID: <4D877F6D.6030807@oracle.com> Hi Ismael, It did not "fall through the cracks". We gave it relatively low priority since, as easy to reproduce it, it is also easy to avoid it by modifying java program. There were several attempts to fix it but they were not finished. The main problem is a performance regression associated with the fix since it is in the core of our loop optimizations. It is also complicated since, as 5091921 shows, there are several related problems which should be fixed. Recently we decided to accept the performance regression and fix it: currently the bug is targeted for jdk 7 release but I can't comment when exactly it will be fixed. Vladimir Ismael Juma wrote: > Hi, > > I came across a Lucene issue where it would read an index incorrectly due to a > HotSpot bug[1]. In the issue tracker, they refer to two unfixed bugs in the > Sun bug tracker: 5091921[2] and 7024475[3]. > > I am interested in the former because it was filed in 2004 and it has a number > of duplicates (the most recent of which was filed last month - 7020614[4]). It > seems pretty nasty and easy to reproduce with many isolated test cases, so I > was wondering why it has remained unfixed for so long. Did it just fall > through the cracks, is it complicated to fix or something else? > > Best, > Ismael > > [1] https://issues.apache.org/jira/browse/LUCENE-2975 (hotspot bug in readvint > gives wrong results) > [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5091921 > [3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7024475 > [4] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7020614 > > From dawid.weiss at gmail.com Mon Mar 21 09:51:06 2011 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 21 Mar 2011 17:51:06 +0100 Subject: Bug 5091921: Sign flip issues in loop optimizer In-Reply-To: <4D877F6D.6030807@oracle.com> References: <4D877F6D.6030807@oracle.com> Message-ID: > since, as easy to reproduce it, it is also easy to avoid it by modifying > java program. Can you expand on this, please? While the issue in Lucene could be worked around by manually unrolling the loop, I don't see a trivial fix for the case I was hitting, where was a nesting of two loops with correlated counters. Dawid From vladimir.kozlov at oracle.com Mon Mar 21 09:55:59 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Mar 2011 09:55:59 -0700 Subject: Request for review (M): 7029017 Additional architecture support for c2 compiler In-Reply-To: References: Message-ID: <4D87831F.6020500@oracle.com> Roland, Did you consider to use Matcher property instead of new flag and new ideal node code? See how we do Matcher::clone_shift_expressions. Vladimir Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7029017/webrev.00/ > > Main changes are: > - Enables cross building of a c2 VM. > - Support masking of shift counts when the processor architecture > mandates it. > > Roland. From vladimir.kozlov at oracle.com Mon Mar 21 10:03:42 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Mar 2011 10:03:42 -0700 Subject: Bug 5091921: Sign flip issues in loop optimizer In-Reply-To: References: <4D877F6D.6030807@oracle.com> Message-ID: <4D8784EE.6060804@oracle.com> Dawid, your problem (7024475), it seems, is not related to the sign flip problem. It is a regression after 6384206 changes in 6u14, as Tom pointed. The sign flip problem exists from day one of Hotspot VM. Vladimir Dawid Weiss wrote: >> since, as easy to reproduce it, it is also easy to avoid it by modifying >> java program. > > Can you expand on this, please? While the issue in Lucene could be > worked around by manually unrolling the loop, I don't see a trivial > fix for the case I was hitting, where was a nesting of two loops with > correlated counters. > > Dawid From mlists at juma.me.uk Mon Mar 21 10:10:00 2011 From: mlists at juma.me.uk (Ismael Juma) Date: Mon, 21 Mar 2011 17:10:00 +0000 (UTC) Subject: Bug 5091921: Sign flip issues in loop optimizer References: <4D877F6D.6030807@oracle.com> Message-ID: Hi Vladimir, Vladimir Kozlov writes: > Recently we decided to accept the performance regression and fix it: > currently the bug is targeted for jdk 7 release but I can't comment > when exactly it will be fixed. Thank you for the explanation and I'm happy with your decision to fix it for JDK 7. Best, Ismael From roland.westrelin at oracle.com Mon Mar 21 10:37:03 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 21 Mar 2011 18:37:03 +0100 Subject: Request for review (M): 7029017 Additional architecture support for c2 compiler In-Reply-To: <4D87831F.6020500@oracle.com> References: <4D87831F.6020500@oracle.com> Message-ID: Hi Vladimir, > Did you consider to use Matcher property instead of new flag and new ideal node > code? See how we do Matcher::clone_shift_expressions. I would like the extra and operations to be optimized out when possible. That won't happen if I do the work at the matcher level, right? Roland. From john.r.rose at oracle.com Mon Mar 21 11:43:07 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 21 Mar 2011 11:43:07 -0700 Subject: Request for review (M): 7029017 Additional architecture support for c2 compiler In-Reply-To: References: <4D87831F.6020500@oracle.com> Message-ID: <61D15EFF-4125-4A7A-9787-F2FEA34B97D3@oracle.com> On Mar 21, 2011, at 10:37 AM, Roland Westrelin wrote: > Hi Vladimir, > >> Did you consider to use Matcher property instead of new flag and new ideal node >> code? See how we do Matcher::clone_shift_expressions. > > I would like the extra and operations to be optimized out when possible. That won't happen if I do the work at the matcher level, right? See if you can fold the And node into the Shift node in the matcher, like the matcher folds the shift and add into the addressing mode. -- John From dawid.weiss at gmail.com Mon Mar 21 13:34:48 2011 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 21 Mar 2011 21:34:48 +0100 Subject: Bug 5091921: Sign flip issues in loop optimizer In-Reply-To: <4D8784EE.6060804@oracle.com> References: <4D877F6D.6030807@oracle.com> <4D8784EE.6060804@oracle.com> Message-ID: Ah, clear now. Thanks Vladimir. Dawid On Mon, Mar 21, 2011 at 6:03 PM, Vladimir Kozlov wrote: > Dawid, > > your problem (7024475), it seems, is not related to the sign flip problem. > It is a regression after 6384206 changes in 6u14, as Tom pointed. > The sign flip problem exists from day one of Hotspot VM. > > Vladimir > > Dawid Weiss wrote: >>> >>> since, as easy to reproduce it, it is also easy to avoid it by modifying >>> java program. >> >> Can you expand on this, please? While the issue in Lucene could be >> worked around by manually unrolling the loop, I don't see a trivial >> fix for the case I was hitting, where was a nesting of two loops with >> correlated counters. >> >> Dawid > From tom.rodriguez at oracle.com Mon Mar 21 14:06:10 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 21 Mar 2011 14:06:10 -0700 Subject: Bug 5091921: Sign flip issues in loop optimizer In-Reply-To: References: <4D877F6D.6030807@oracle.com> <4D8784EE.6060804@oracle.com> Message-ID: Yes, there's no indication that 7024475 is related to the sign flip issue. I've been working on other issues for the last week but I'm back looking at this. I can see that the outer loop bound is getting getting reset to its initial value when we start the OSR code. I'm still tracking down why it occurs. tom On Mar 21, 2011, at 1:34 PM, Dawid Weiss wrote: > Ah, clear now. Thanks Vladimir. > > Dawid > > On Mon, Mar 21, 2011 at 6:03 PM, Vladimir Kozlov > wrote: >> Dawid, >> >> your problem (7024475), it seems, is not related to the sign flip problem. >> It is a regression after 6384206 changes in 6u14, as Tom pointed. >> The sign flip problem exists from day one of Hotspot VM. >> >> Vladimir >> >> Dawid Weiss wrote: >>>> >>>> since, as easy to reproduce it, it is also easy to avoid it by modifying >>>> java program. >>> >>> Can you expand on this, please? While the issue in Lucene could be >>> worked around by manually unrolling the loop, I don't see a trivial >>> fix for the case I was hitting, where was a nesting of two loops with >>> correlated counters. >>> >>> Dawid >> From vladimir.kozlov at oracle.com Mon Mar 21 14:34:58 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Mar 2011 14:34:58 -0700 Subject: Request for review (M): 7029017 Additional architecture support for c2 compiler In-Reply-To: References: <4D87831F.6020500@oracle.com> Message-ID: <4D87C482.3090705@oracle.com> What I meant is: in your platform .ad file you asign 'true' and in others 'false': const bool Matcher::need_masked_shift_count = true; in matchser.hpp: + static const bool need_masked_shift_count; in mulnode.cpp: + if (Matcher::need_masked_shift_count) { I am concern about masking during ideal transformation. It affects all platforms and you will convert a negative value to positive which may produce a different result since it may affect some ideal transformations. I would suggest to do it in .ad file. instruct sarI_reg_imm(iRegI dst, iRegI src1, immI src2) %{ match(Set dst (RShiftI src1 src2)); format %{ "SRA $src1,$src2,$dst" %} ins_encode %{ int shift = ($src2$$constant) & (BitsPerInt - 1); __ sra($src1$$Register, shift, $dst$$Register); %} ins_pipe(ialu_reg_imm); %} And for variable shift you can use predicate in .ad file to avoid AND: // Version without AND instruct sarI_reg_reg(iRegI dst, iRegI src1, iRegI src2) %{ predicate(n->in(2)->is_shift(BitsPerInt - 1)); // Version with AND instruct sarI_reg_reg(iRegI dst, iRegI src1, iRegI src2) %{ predicate(!n->in(2)->is_shift(BitsPerInt - 1)); match(Set dst (RShiftI src1 src2)); and in node.hpp is_shift(int mask) { const TypeInt* t = find_int_type(); return (t != NULL) && t->_lo >= 0 && t->_hi <= mask; } Here are few comments for future C2 code modification. Don't do assignment in the condition code: + const TypeInt *t; + // avoid infinite loop of shift transformations + if( !(t = phase->type(in2)->isa_int()) || t->_lo < 0 || t->_hi > m ) { Use "if (a)" spacing instead of "if( a )". Also you should not modify dead node, it is useless: - if( t == Type::TOP ) return NULL; // Right input is dead + if( t == Type::TOP ) return do_mask_shift(phase, BitsPerInt - 1); // Right input is dead Vladimir Roland Westrelin wrote: > Hi Vladimir, > >> Did you consider to use Matcher property instead of new flag and new >> ideal node >> code? See how we do Matcher::clone_shift_expressions. > > I would like the extra and operations to be optimized out when possible. > That won't happen if I do the work at the matcher level, right? > > Roland. From vladimir.kozlov at oracle.com Mon Mar 21 15:06:53 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Mon, 21 Mar 2011 22:06:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7008866: Missing loop predicate for loop with multiple entries Message-ID: <20110321220657.5550A47356@hg.openjdk.java.net> Changeset: 9dc311b8473e Author: kvn Date: 2011-03-21 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9dc311b8473e 7008866: Missing loop predicate for loop with multiple entries Summary: Add predicates when loop head bytecode is parsed instead of when back branch bytecode is parsed. Reviewed-by: never ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/library_call.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/loopopts.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/stringopts.cpp From john.r.rose at oracle.com Wed Mar 23 02:16:37 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 23 Mar 2011 02:16:37 -0700 Subject: review request (L): 7012648/JDK: move JSR 292 to package java.lang.invoke and adjust names References: <1BEDF2ED-23BE-4883-A4BB-F488C37627DB@oracle.com> Message-ID: <3E542667-3B82-4B12-A2C4-C5C31B98FCE7@oracle.com> The package rename work is done in the JVM; this is the review for the JDK code and documentation. -- John Begin forwarded message: From: John Rose Date: March 23, 2011 2:10:52 AM PDT To: Da Vinci Machine Project Subject: review request (L): 7012648/JDK: move JSR 292 to package java.lang.invoke and adjust names Reply-To: Da Vinci Machine Project http://cr.openjdk.java.net/~jrose/7012648/webrev.jdk.00/ Summary: JDK code for package and class renaming from java.dyn to java.lang.invoke. Includes certain other small changes: - move remaining (miscellaneous) contents of sun.dyn to sun.invoke - make minor revisions to documentation during Public Review - remove the out-of-scope term "SAM type" from documentation and code - delete unused methods and classes - make minor (API-invisible) code cleanups The non-renaming changes may be viewed separately here: http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-rename-7012648.2.patch This change set is for the JDK repository, specifically: http://hg.openjdk.java.net/jdk7/hotspot/jdk A previous coordinated change set for the JVM, also marked with bug 7012648, is about to be promoted (jdk7-b135). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110323/9b1093f4/attachment.html From gbenson at redhat.com Wed Mar 23 04:52:10 2011 From: gbenson at redhat.com (Gary Benson) Date: Wed, 23 Mar 2011 11:52:10 +0000 Subject: Review Request: Zero tweak Message-ID: <20110323115209.GB3353@redhat.com> Hi all, IcedTea contains a now-unmaintained ARM-specific interpreter. Part of that interpreter was accidentally incorporated in one of the webrevs when Zero was initially imported. It does not correctly limit its behaviour to only when the ARM interpreter is enabled, with the potential to cause infinite loops and other tricky to debug issues. This webrev removes this code: http://cr.openjdk.java.net/~gbenson/zero-tweak/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From christian.thalinger at oracle.com Wed Mar 23 06:22:44 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 23 Mar 2011 14:22:44 +0100 Subject: Review Request: Zero tweak In-Reply-To: <20110323115209.GB3353@redhat.com> References: <20110323115209.GB3353@redhat.com> Message-ID: <630159F5-A096-4494-9228-8ABD01520868@oracle.com> On Mar 23, 2011, at 12:52 PM, Gary Benson wrote: > Hi all, > > IcedTea contains a now-unmaintained ARM-specific interpreter. > Part of that interpreter was accidentally incorporated in one > of the webrevs when Zero was initially imported. It does not > correctly limit its behaviour to only when the ARM interpreter > is enabled, with the potential to cause infinite loops and > other tricky to debug issues. This webrev removes this code: > > http://cr.openjdk.java.net/~gbenson/zero-tweak/ > > I don't have a bug id for this. 7030207: Zero tweak to remove accidentally incorporated code The change looks good. I will push it via JPRT. -- Christian From gbenson at redhat.com Wed Mar 23 06:27:11 2011 From: gbenson at redhat.com (Gary Benson) Date: Wed, 23 Mar 2011 13:27:11 +0000 Subject: Review Request: Zero tweak In-Reply-To: <630159F5-A096-4494-9228-8ABD01520868@oracle.com> References: <20110323115209.GB3353@redhat.com> <630159F5-A096-4494-9228-8ABD01520868@oracle.com> Message-ID: <20110323132711.GC3353@redhat.com> Christian Thalinger wrote: > On Mar 23, 2011, at 12:52 PM, Gary Benson wrote: > > IcedTea contains a now-unmaintained ARM-specific interpreter. > > Part of that interpreter was accidentally incorporated in one > > of the webrevs when Zero was initially imported. It does not > > correctly limit its behaviour to only when the ARM interpreter > > is enabled, with the potential to cause infinite loops and > > other tricky to debug issues. This webrev removes this code: > > > > http://cr.openjdk.java.net/~gbenson/zero-tweak/ > > > > I don't have a bug id for this. > > 7030207: Zero tweak to remove accidentally incorporated code > > The change looks good. I will push it via JPRT. Thank you. Cheers, Gary -- http://gbenson.net/ From vladimir.kozlov at oracle.com Wed Mar 23 12:45:39 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Mar 2011 12:45:39 -0700 Subject: Request for review (M): 7029017 Additional architecture support for c2 compiler In-Reply-To: <4D87C482.3090705@oracle.com> References: <4D87831F.6020500@oracle.com> <4D87C482.3090705@oracle.com> Message-ID: <4D8A4DE3.5090400@oracle.com> Here is another suggestion for you. Use final_graph_reshaping to mask shift count (in final_graph_reshaping_impl()): case Op_LShiftI: case Op_RShiftI: case Op_URShiftI: case Op_LShiftL: case Op_RShiftL: case Op_URShiftL: if (Matcher::need_masked_shift_count) { Node* in2 = n->in(2); juint mask = (n->bottom_type() == TypeInt::INT) ? (BitsPerInt - 1) : (BitsPerLong - 1); const TypeInt* t = in2->find_int_type(); if (t != NULL && t->is_con()) { juint shift = t->get_con(); if (shift > mask) { // Unsigned cmp Compile* C = Compile::current(); n->set_req(2, ConNode::make(C, TypeInt::make(shift & mask))); } } else { if (t == NULL || t->_lo < 0 || t->_hi > mask) { Compile* C = Compile::current(); Node* shift = new (C, 3) AndINode(in2, ConNode::make(C, TypeInt::make(mask))); n->set_req(2, shift); } } if (in2->outcnt() == 0) { // Remove dead node in2->disconnect_inputs(NULL); } } break; Vladimir Vladimir Kozlov wrote: > What I meant is: > > in your platform .ad file you asign 'true' and in others 'false': > > const bool Matcher::need_masked_shift_count = true; > > in matchser.hpp: > > + static const bool need_masked_shift_count; > > in mulnode.cpp: > > + if (Matcher::need_masked_shift_count) { > > > I am concern about masking during ideal transformation. It affects all > platforms and you will convert a negative value to positive which may > produce a different result since it may affect some ideal > transformations. I would suggest to do it in .ad file. > > instruct sarI_reg_imm(iRegI dst, iRegI src1, immI src2) %{ > match(Set dst (RShiftI src1 src2)); > format %{ "SRA $src1,$src2,$dst" %} > ins_encode %{ > int shift = ($src2$$constant) & (BitsPerInt - 1); > __ sra($src1$$Register, shift, $dst$$Register); > %} > ins_pipe(ialu_reg_imm); > %} > > > And for variable shift you can use predicate in .ad file to avoid AND: > > // Version without AND > instruct sarI_reg_reg(iRegI dst, iRegI src1, iRegI src2) %{ > predicate(n->in(2)->is_shift(BitsPerInt - 1)); > > // Version with AND > instruct sarI_reg_reg(iRegI dst, iRegI src1, iRegI src2) %{ > predicate(!n->in(2)->is_shift(BitsPerInt - 1)); > match(Set dst (RShiftI src1 src2)); > > and in node.hpp > > is_shift(int mask) { > const TypeInt* t = find_int_type(); > return (t != NULL) && t->_lo >= 0 && t->_hi <= mask; > } > > > Here are few comments for future C2 code modification. > Don't do assignment in the condition code: > > + const TypeInt *t; > + // avoid infinite loop of shift transformations > + if( !(t = phase->type(in2)->isa_int()) || t->_lo < 0 || t->_hi > m ) { > > Use "if (a)" spacing instead of "if( a )". > > Also you should not modify dead node, it is useless: > > - if( t == Type::TOP ) return NULL; // Right input is dead > + if( t == Type::TOP ) return do_mask_shift(phase, BitsPerInt - 1); // > Right input is dead > > > Vladimir > > Roland Westrelin wrote: >> Hi Vladimir, >> >>> Did you consider to use Matcher property instead of new flag and new >>> ideal node >>> code? See how we do Matcher::clone_shift_expressions. >> >> I would like the extra and operations to be optimized out when >> possible. That won't happen if I do the work at the matcher level, right? >> >> Roland. From john.r.rose at oracle.com Wed Mar 23 23:59:57 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 24 Mar 2011 06:59:57 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 7012648: move JSR 292 to package java.lang.invoke and adjust names Message-ID: <20110324070035.F3AD347411@hg.openjdk.java.net> Changeset: 9c1e4e0ab69f Author: jrose Date: 2011-03-23 23:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9c1e4e0ab69f 7012648: move JSR 292 to package java.lang.invoke and adjust names Summary: package and class renaming only; delete unused methods and classes; add @since tags; no code changes Reviewed-by: twisti ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk ! make/java/Makefile - make/java/dyn/Makefile + make/java/invoke/Makefile - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/package-info.java + src/share/classes/java/lang/BootstrapMethodError.java ! src/share/classes/java/lang/ClassValue.java < src/share/classes/java/dyn/ClassValue.java ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java < src/share/classes/java/dyn/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java < src/share/classes/java/dyn/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java < src/share/classes/java/dyn/CallSite.java + src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java < src/share/classes/java/dyn/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/FilterGeneric.java < src/share/classes/java/dyn/FilterGeneric.java ! src/share/classes/java/lang/invoke/FilterOneArgument.java < src/share/classes/java/dyn/FilterOneArgument.java ! src/share/classes/java/lang/invoke/FromGeneric.java < src/share/classes/java/dyn/FromGeneric.java ! src/share/classes/java/lang/invoke/InvokeDynamic.java < src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/lang/invoke/InvokeGeneric.java < src/share/classes/java/dyn/InvokeGeneric.java ! src/share/classes/java/lang/invoke/Invokers.java < src/share/classes/java/dyn/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java < src/share/classes/java/dyn/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java < src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java < src/share/classes/java/dyn/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java < src/share/classes/java/dyn/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java < src/share/classes/java/dyn/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java < src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java < src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java < src/share/classes/java/dyn/MethodTypeForm.java ! src/share/classes/java/lang/invoke/MutableCallSite.java < src/share/classes/java/dyn/MutableCallSite.java ! src/share/classes/java/lang/invoke/SpreadGeneric.java < src/share/classes/java/dyn/SpreadGeneric.java + src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/java/lang/invoke/ToGeneric.java < src/share/classes/java/dyn/ToGeneric.java ! src/share/classes/java/lang/invoke/VolatileCallSite.java < src/share/classes/java/dyn/VolatileCallSite.java ! src/share/classes/java/lang/invoke/WrongMethodTypeException.java < src/share/classes/java/dyn/WrongMethodTypeException.java + src/share/classes/java/lang/invoke/package-info.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/VerifyType.java - src/share/classes/sun/dyn/util/Wrapper.java - src/share/classes/sun/dyn/util/package-info.java + src/share/classes/sun/invoke/WrapperInstance.java + src/share/classes/sun/invoke/anon/AnonymousClassLoader.java + src/share/classes/sun/invoke/anon/ConstantPoolParser.java + src/share/classes/sun/invoke/anon/ConstantPoolPatch.java + src/share/classes/sun/invoke/anon/ConstantPoolVisitor.java + src/share/classes/sun/invoke/anon/InvalidConstantPoolFormatException.java + src/share/classes/sun/invoke/empty/Empty.java + src/share/classes/sun/invoke/package-info.java + src/share/classes/sun/invoke/util/BytecodeDescriptor.java + src/share/classes/sun/invoke/util/BytecodeName.java ! src/share/classes/sun/invoke/util/ValueConversions.java < src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java < src/share/classes/sun/dyn/util/VerifyAccess.java + src/share/classes/sun/invoke/util/VerifyType.java + src/share/classes/sun/invoke/util/Wrapper.java + src/share/classes/sun/invoke/util/package-info.java ! src/share/native/common/check_code.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/indify/Indify.java ! test/java/lang/invoke/6987555/Test6987555.java < test/java/dyn/6987555/Test6987555.java ! test/java/lang/invoke/6991596/Test6991596.java < test/java/dyn/6991596/Test6991596.java + test/java/lang/invoke/ClassValueTest.java + test/java/lang/invoke/InvokeDynamicPrintArgs.java + test/java/lang/invoke/InvokeGenericTest.java + test/java/lang/invoke/JavaDocExamplesTest.java + test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java < test/java/dyn/MethodTypeTest.java + test/java/lang/invoke/indify/Indify.java From roland.westrelin at oracle.com Thu Mar 24 09:03:15 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 24 Mar 2011 17:03:15 +0100 Subject: Request for review (M): 7029017 Additional architecture support for c2 compiler In-Reply-To: <4D8A4DE3.5090400@oracle.com> References: <4D87831F.6020500@oracle.com> <4D87C482.3090705@oracle.com> <4D8A4DE3.5090400@oracle.com> Message-ID: > Here is another suggestion for you. Use final_graph_reshaping to mask shift > count (in final_graph_reshaping_impl()): Thanks Vladimir. Here is a new webrev: http://cr.openjdk.java.net/~roland/7029017/webrev.01/ Roland. From john.r.rose at oracle.com Thu Mar 24 11:03:33 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 24 Mar 2011 18:03:33 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 15 new changesets Message-ID: <20110324180630.B2E4947435@hg.openjdk.java.net> Changeset: 1c7cac250f71 Author: asaha Date: 2011-03-21 21:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1c7cac250f71 7029704: JFB: Refix JFB Custom Revision Version Build/Makefile changes Reviewed-by: mr, ohair ! make/common/Defs.gmk ! make/common/Release.gmk Changeset: e390396bc938 Author: katakai Date: 2011-02-26 03:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e390396bc938 6998391: Serbian (Latin) locale support Reviewed-by: naoto ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! src/share/classes/java/text/SimpleDateFormat.java + src/share/classes/sun/text/resources/CollationData_sr_Latn.java + src/share/classes/sun/text/resources/FormatData_sr_Latn.java + src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java + src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java + src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java + src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties + src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties + src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties + src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties + src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties + src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties ! src/share/classes/sun/util/resources/LocaleData.java + src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 0fc1f64bbd73 Author: mfang Date: 2011-03-04 14:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0fc1f64bbd73 Merge - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java - test/java/lang/Thread/StopBeforeStart.java Changeset: a574a067d85a Author: mfang Date: 2011-03-05 14:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a574a067d85a 7016542: NLS: obsolete resources in MsgAppletViewer.java should be removed Reviewed-by: igor ! src/share/classes/sun/applet/resources/MsgAppletViewer.java Changeset: c3c9fda4591e Author: mfang Date: 2011-03-07 12:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c3c9fda4591e 7025267: NLS: t13y fix for 7021689 [ja] Notepad demo throws NPE Reviewed-by: ogino ! src/share/demo/jfc/Notepad/resources/Notepad.properties ! src/share/demo/jfc/Notepad/resources/Notepad_ja.properties ! src/share/demo/jfc/Notepad/resources/Notepad_zh_CN.properties Changeset: 9e4d258ac919 Author: mfang Date: 2011-03-07 12:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9e4d258ac919 7021693: [ja, zh_CN] jconsole throws exception and fail to start in ja and zh_CN locales Reviewed-by: ogino ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java Changeset: abe08bf657e3 Author: mfang Date: 2011-03-07 12:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/abe08bf657e3 7025303: NLS: t13y fix for 7021691 Most log level words are not translated in java logging Reviewed-by: yhuang ! src/share/classes/sun/util/logging/resources/logging.properties Changeset: 21737a3e16fb Author: mfang Date: 2011-03-09 14:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/21737a3e16fb Merge Changeset: 5ed7b3d84957 Author: yhuang Date: 2011-03-11 05:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5ed7b3d84957 7019267: Currency Display Names are not localized into pt_BR. Reviewed-by: naoto ! make/java/util/FILES_properties.gmk + src/share/classes/sun/util/resources/CurrencyNames_pt.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: e64ef0cd99ad Author: yhuang Date: 2011-03-11 05:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e64ef0cd99ad Merge Changeset: af4793ab50fb Author: mfang Date: 2011-03-19 19:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/af4793ab50fb Merge - make/common/Modules.gmk - make/java/nio/mxbean/Makefile - make/modules/Makefile - make/modules/bootmodule.roots - make/modules/jdk7.depconfig - make/modules/modules.config - make/modules/modules.group - make/modules/optional.depconfig - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java - src/share/classes/sun/misc/BootClassLoaderHook.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: 258072f4db19 Author: yhuang Date: 2011-03-20 23:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/258072f4db19 7020960: CurrencyNames_sr_RS.properties is missing. Reviewed-by: naoto ! make/java/util/FILES_properties.gmk + src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: f9d15fd48919 Author: mfang Date: 2011-03-21 11:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f9d15fd48919 Merge Changeset: d8ced728159f Author: mfang Date: 2011-03-22 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d8ced728159f Merge Changeset: 4770b99ba850 Author: jrose Date: 2011-03-24 00:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4770b99ba850 Merge ! make/common/Release.gmk - 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 - 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 From tom.rodriguez at oracle.com Thu Mar 24 12:33:51 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 24 Mar 2011 12:33:51 -0700 Subject: Request for review (M): 7029017 Additional architecture support for c2 compiler In-Reply-To: References: <4D87831F.6020500@oracle.com> <4D87C482.3090705@oracle.com> <4D8A4DE3.5090400@oracle.com> Message-ID: <3E8185EF-4AE8-4F9D-A0FF-BFF476A837DC@oracle.com> Looks good. tom On Mar 24, 2011, at 9:03 AM, Roland Westrelin wrote: > >> Here is another suggestion for you. Use final_graph_reshaping to mask shift >> count (in final_graph_reshaping_impl()): > > Thanks Vladimir. > Here is a new webrev: > > http://cr.openjdk.java.net/~roland/7029017/webrev.01/ > > Roland. From tom.rodriguez at oracle.com Thu Mar 24 14:53:09 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 24 Mar 2011 14:53:09 -0700 Subject: Endless loops in computation code (1.6.0_22). In-Reply-To: References: <7684FD62-77E8-476F-AD2F-479ACC66A79A@oracle.com> <6844B58D-2A2A-4420-A5D9-A71AA4C3332C@oracle.com> Message-ID: <9C75054E-68AA-46C3-8E77-B729048091B2@oracle.com> I finally tracked down this bug and it's an new issue. There's an optimization that replaces empty loops with the final index they compute and it assumes that the loop already has a zero trip guard so that if we enter the loop we will go around the loop at least once. For your complex loop combined with an OSR compile we get the right set of conditions for this. This causes the loop to produce an incorrect value and resets the bounds of the iteration. I simplified your original loop quite a bit and then Vladimir was able to build a really simple version of it. I modified those bytecodes to be OSR like, taking all locals as incoming arguments and jumping to the OSR bci, and then used jode to produce source from those bytecodes. That gave me this loop: static void test(Test test, int i, int c0, int j, int c1) { for (;;) { if (c1 > c0) { if (c0 > 253) { throw new InternalError("c0 = " + c0); } int index = c0 * 256 + c1; if (index == -1) return; i = bucket_B[index]; if (1 < j - i && test != null) x1 = 0; j = i; c1--; } else { c0--; if (j <= 0) break; c1 = 255; } } } which shows the bug in every 1.6.0 release in both OSR and non-OSR compiles. The bug report has the full test in it. The fix is simply to ensure that this code has a zero trip guard, probably by reusing do_peeling to build one. That produces a redundant test in the common case where there's already a guard though I suspect we can optimize that away. As far as a workaround for your code, I'm not sure what to suggest. I'll see if I can come up with something. tom On Mar 3, 2011, at 11:44 PM, Dawid Weiss wrote: > > After watching maven download jars for 10 minutes, it actually ran the test and reproduced it. > > Ehm, I'm not a big fan of Maven myself, but trying to get used to what people use (and many people do use maven -- perhaps they need those 10 minutes to grab a coffee in the morning, don't know). > > I put together a little main to run the test manually and just reproduced it with -XX:+PrintCompilation. It hung right after it printed this: > > 3% org.jsuffixarrays.DivSufSort::sortTypeBstar @ 979 (1125 bytes) > > Ok, so it must be Maven's test plugin messing with the stdout/stderr log order then. I'm glad you could reproduce it. > > so it's possible it's a bug with with on stack replacement. I've reproduced it with the latest 1.7 as well so it's something we haven't seen before. I filed 7024475 for this and put you on the interest list. I can't reproduce it in 6u12 but I can in 6u14 so I think it appeared there. > > Great, thanks. I fiddled with that code a little bit moving loop counter increments here and there, but it seems to be fairly resilient to where they are (as long as the logic doesn't change). Interestingly, moving the sysout does seem to fix things (if you move it after the if in the inside loop). > > I appreciate your help, Tom. This is truly fascinating stuff. > Dawid > > From vladimir.kozlov at oracle.com Thu Mar 24 19:07:54 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Mar 2011 19:07:54 -0700 Subject: Request for reviews (L): 7004535: Clone loop predicates when loop is cloned Message-ID: <4D8BF8FA.9030600@oracle.com> Second loop opts changes. http://cr.openjdk.java.net/~kvn/7004535/webrev Fixed 7004535: Clone loop predicates when loop is cloned Currently loop predicates generated during parsing could be separated from loops when loops are cloned. As result such predicates are removed. There could be more optimization opportunities if loop predicates are also cloned in such situations. Loop predicate code become big so I moved it into new file loopPredicate.cpp. I separated the cloning code for IdealLoop and IterGVN. The generated Ideal code is the same but registration of new Ideal nodes is different enough to have separate methods, I think. I welcome any suggestions to improve this code. Keep loop predicates after CCP and perform optimizations with them until no more loop optimizations could be done. After that switch them off and do more loop optimizations. VectorNode missed size_of() method as result it was cloned incorrectly. Added TraceLoopOpts outputs I missed in previous changes. Tested: ctw, nsk, jprt From christian.thalinger at oracle.com Thu Mar 24 19:11:35 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 25 Mar 2011 02:11:35 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7029805: JSR 292 compiler/6991596/Test6991596.java fails in nightly Message-ID: <20110325021143.D6BDD4745A@hg.openjdk.java.net> Changeset: 0a5d9566b8a4 Author: twisti Date: 2011-03-23 04:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0a5d9566b8a4 7029805: JSR 292 compiler/6991596/Test6991596.java fails in nightly Summary: Both JSR 292 compiler tests were moved with 6839872 to the jdk repository Reviewed-by: never - test/compiler/6987555/Test6987555.java - test/compiler/6991596/Test6991596.java From christian.thalinger at oracle.com Thu Mar 24 23:25:56 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 25 Mar 2011 06:25:56 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110325062600.1C6BC47466@hg.openjdk.java.net> Changeset: 151da0c145a8 Author: twisti Date: 2011-03-24 02:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/151da0c145a8 7030207: Zero tweak to remove accidentally incorporated code Summary: IcedTea contains a now-unmaintained ARM-specific interpreter and part of that interpreter was accidentally incorporated in one of the webrevs when Zero was initially imported. Reviewed-by: twisti Contributed-by: Gary Benson ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: b868d9928221 Author: twisti Date: 2011-03-24 23:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b868d9928221 Merge - test/compiler/6987555/Test6987555.java - test/compiler/6991596/Test6991596.java From dawid.weiss at gmail.com Fri Mar 25 01:01:55 2011 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Fri, 25 Mar 2011 09:01:55 +0100 Subject: Endless loops in computation code (1.6.0_22). In-Reply-To: <9C75054E-68AA-46C3-8E77-B729048091B2@oracle.com> References: <7684FD62-77E8-476F-AD2F-479ACC66A79A@oracle.com> <6844B58D-2A2A-4420-A5D9-A71AA4C3332C@oracle.com> <9C75054E-68AA-46C3-8E77-B729048091B2@oracle.com> Message-ID: Thanks Tom (and Vladimir). Although I must say even though the explanation seems to be in plain English I will need to digest it a little bit to understand it :) Is the full test showing this somewhere in OpenJDK codebase? As for a workaround to the original code: this is not anything critical (just a toy algorithmic project), so you don't need to bother thinking of a workaround. If it was something that we could trivially fix, fine, but if not -- so be it, no problem. Dawid 2011/3/24 Tom Rodriguez > I finally tracked down this bug and it's an new issue. There's an > optimization that replaces empty loops with the final index they compute and > it assumes that the loop already has a zero trip guard so that if we enter > the loop we will go around the loop at least once. For your complex loop > combined with an OSR compile we get the right set of conditions for this. > This causes the loop to produce an incorrect value and resets the bounds of > the iteration. > > I simplified your original loop quite a bit and then Vladimir was able to > build a really simple version of it. I modified those bytecodes to be OSR > like, taking all locals as incoming arguments and jumping to the OSR bci, > and then used jode to produce source from those bytecodes. That gave me > this loop: > > static void test(Test test, int i, int c0, int j, int c1) { > for (;;) { > if (c1 > c0) { > if (c0 > 253) { > throw new InternalError("c0 = " + c0); > } > int index = c0 * 256 + c1; > if (index == -1) return; > i = bucket_B[index]; > if (1 < j - i && test != null) > x1 = 0; > j = i; > c1--; > } else { > c0--; > if (j <= 0) > break; > c1 = 255; > } > } > } > > which shows the bug in every 1.6.0 release in both OSR and non-OSR > compiles. The bug report has the full test in it. The fix is simply to > ensure that this code has a zero trip guard, probably by reusing do_peeling > to build one. That produces a redundant test in the common case where > there's already a guard though I suspect we can optimize that away. > > As far as a workaround for your code, I'm not sure what to suggest. I'll > see if I can come up with something. > > tom > > On Mar 3, 2011, at 11:44 PM, Dawid Weiss wrote: > > > > > After watching maven download jars for 10 minutes, it actually ran the > test and reproduced it. > > > > Ehm, I'm not a big fan of Maven myself, but trying to get used to what > people use (and many people do use maven -- perhaps they need those 10 > minutes to grab a coffee in the morning, don't know). > > > > I put together a little main to run the test manually and just > reproduced it with -XX:+PrintCompilation. It hung right after it printed > this: > > > > 3% org.jsuffixarrays.DivSufSort::sortTypeBstar @ 979 (1125 bytes) > > > > Ok, so it must be Maven's test plugin messing with the stdout/stderr log > order then. I'm glad you could reproduce it. > > > > so it's possible it's a bug with with on stack replacement. I've > reproduced it with the latest 1.7 as well so it's something we haven't seen > before. I filed 7024475 for this and put you on the interest list. I can't > reproduce it in 6u12 but I can in 6u14 so I think it appeared there. > > > > Great, thanks. I fiddled with that code a little bit moving loop counter > increments here and there, but it seems to be fairly resilient to where they > are (as long as the logic doesn't change). Interestingly, moving the sysout > does seem to fix things (if you move it after the if in the inside loop). > > > > I appreciate your help, Tom. This is truly fascinating stuff. > > Dawid > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110325/bc4c9e7a/attachment-0001.html From tom.rodriguez at oracle.com Fri Mar 25 11:37:51 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Mar 2011 11:37:51 -0700 Subject: review (XS) for 6478991: C1 NullCheckEliminator yields incorrect exceptions Message-ID: <2CB16D5E-3B3E-4791-B356-6DC5613DCF94@oracle.com> http://cr.openjdk.java.net/~never/6478991 6478991: C1 NullCheckEliminator yields incorrect exceptions Reviewed-by: checkcast can trap so don't allow explicit null checks to be folded into instructions that follow it. Tested with new test case. From tom.rodriguez at oracle.com Fri Mar 25 11:42:29 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Mar 2011 11:42:29 -0700 Subject: review (M) for 7024475: loop doesn't terminate when compiled Message-ID: http://cr.openjdk.java.net/~never/7024475 7024475: loop doesn't terminate when compiled Reviewed-by: The code which replaces an empty loop with the final computed value only works correctly if the the loop is guaranteed to execute once since it replaces the conditionally executed loop body with a value. Loop transformations like peeling generally result in zero trip guards being generated but they aren't required to be there. The fix is to make sure we have a guard by peeling the loop first. This results in a small redundant test in some cases. I added a check for obvious ones, which occurred in scimark SOR. Main and post loops are constructed with zero trip guards so I assume one exists in those cases. Tested with new test case, original failing program, refworkload and full CTW. I also improved a few debugging features. Node::find could get into an infinite loop walking debug_orig, so it should be check for a cycle. I made some other efficiency improvements before I realized that the problem was a cycle. I went ahead and kept those changes. IdealGraphPrinter should print out a few more debug fields and should dump the block structure if it exists. I changed the printing after beautify loops so it only happens once instead of after each recursive call. I added an OSROnlyBCI flag to control which OSR bcis can be compiled. I changed the assert in loop verification to allow verifying when the igvn worklist isn't empty. From tom.rodriguez at oracle.com Fri Mar 25 11:55:20 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Mar 2011 11:55:20 -0700 Subject: Endless loops in computation code (1.6.0_22). In-Reply-To: References: <7684FD62-77E8-476F-AD2F-479ACC66A79A@oracle.com> <6844B58D-2A2A-4420-A5D9-A71AA4C3332C@oracle.com> <9C75054E-68AA-46C3-8E77-B729048091B2@oracle.com> Message-ID: <5724F79D-C687-4DA8-8C1F-85F77B2D37DF@oracle.com> On Mar 25, 2011, at 1:01 AM, Dawid Weiss wrote: > > Thanks Tom (and Vladimir). Although I must say even though the explanation seems to be in plain English I will need to digest it a little bit to understand it :) Yes it looks like English but it's really jargon. The optimizer often wants loops that are shaped like: if (guard) { do { } while (test); The guard piece is a zero trip test since it skips over the loop if it won't execute at all. The space between the if and the do is a useful place to put things that are loop invariant but only need to be computed if you actually enter the loop which is why we like this structure. The remove empty loop code was replacing the loop with the result it produced but that's only valid if it already has a zero trip guard. Pretty much all the time it does but in this case it didn't. Note that neither your original program nor the test case have an obvious empty loop. In both cases it results from optimizations on the original loop > Is the full test showing this somewhere in OpenJDK codebase? It's in the bug report and I made a regression test for it which I included in my fix. http://cr.openjdk.java.net/~never/7024475/raw_files/new/test/compiler/7024475/Test7024475.java > > As for a workaround to the original code: this is not anything critical (just a toy algorithmic project), so you don't need to bother thinking of a workaround. If it was something that we could trivially fix, fine, but if not -- so be it, no problem. Ok. tom > > Dawid > > 2011/3/24 Tom Rodriguez > I finally tracked down this bug and it's an new issue. There's an optimization that replaces empty loops with the final index they compute and it assumes that the loop already has a zero trip guard so that if we enter the loop we will go around the loop at least once. For your complex loop combined with an OSR compile we get the right set of conditions for this. This causes the loop to produce an incorrect value and resets the bounds of the iteration. > > I simplified your original loop quite a bit and then Vladimir was able to build a really simple version of it. I modified those bytecodes to be OSR like, taking all locals as incoming arguments and jumping to the OSR bci, and then used jode to produce source from those bytecodes. That gave me this loop: > > static void test(Test test, int i, int c0, int j, int c1) { > for (;;) { > if (c1 > c0) { > if (c0 > 253) { > throw new InternalError("c0 = " + c0); > } > int index = c0 * 256 + c1; > if (index == -1) return; > i = bucket_B[index]; > if (1 < j - i && test != null) > x1 = 0; > j = i; > c1--; > } else { > c0--; > if (j <= 0) > break; > c1 = 255; > } > } > } > > which shows the bug in every 1.6.0 release in both OSR and non-OSR compiles. The bug report has the full test in it. The fix is simply to ensure that this code has a zero trip guard, probably by reusing do_peeling to build one. That produces a redundant test in the common case where there's already a guard though I suspect we can optimize that away. > > As far as a workaround for your code, I'm not sure what to suggest. I'll see if I can come up with something. > > tom > > On Mar 3, 2011, at 11:44 PM, Dawid Weiss wrote: > > > > > After watching maven download jars for 10 minutes, it actually ran the test and reproduced it. > > > > Ehm, I'm not a big fan of Maven myself, but trying to get used to what people use (and many people do use maven -- perhaps they need those 10 minutes to grab a coffee in the morning, don't know). > > > > I put together a little main to run the test manually and just reproduced it with -XX:+PrintCompilation. It hung right after it printed this: > > > > 3% org.jsuffixarrays.DivSufSort::sortTypeBstar @ 979 (1125 bytes) > > > > Ok, so it must be Maven's test plugin messing with the stdout/stderr log order then. I'm glad you could reproduce it. > > > > so it's possible it's a bug with with on stack replacement. I've reproduced it with the latest 1.7 as well so it's something we haven't seen before. I filed 7024475 for this and put you on the interest list. I can't reproduce it in 6u12 but I can in 6u14 so I think it appeared there. > > > > Great, thanks. I fiddled with that code a little bit moving loop counter increments here and there, but it seems to be fairly resilient to where they are (as long as the logic doesn't change). Interestingly, moving the sysout does seem to fix things (if you move it after the if in the inside loop). > > > > I appreciate your help, Tom. This is truly fascinating stuff. > > Dawid > > > > > > From igor.veresov at oracle.com Fri Mar 25 12:34:13 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 25 Mar 2011 12:34:13 -0700 Subject: Request for review(M): 6964776: c2 should ensure the polling page is reachable on 64 bit Message-ID: <4D8CEE35.1010707@oracle.com> C1 and C2 could only use rip-relative addressing when emitting the page-polling code, which limited the distance from the code cache to the polling page is more than 2G (doesn't fit in a signed 32bit displacement). The solution in this case is to materialize the absolute pointer to the polling page in a register first, as we do on SPARC. Webrev: http://cr.openjdk.java.net/~iveresov/6964776/webrev.00/ Thanks, igor From vladimir.kozlov at oracle.com Fri Mar 25 12:53:37 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Mar 2011 12:53:37 -0700 Subject: review (M) for 7024475: loop doesn't terminate when compiled In-Reply-To: References: Message-ID: <4D8CF2C1.8020408@oracle.com> Add comment that guard is generated explicitly for main and post loops: + bool needs_guard = !cl->is_main_loop && !cl->is_post_loop(); + if (bol->is_Bool() && bol->as_Bool()->_test._test == BoolTest::lt) { should be: + if (bol->is_Bool() && bol->as_Bool()->_test._test == + cl->loopexit()->test_trip()) { I will modify this code to skip cloned predicates for 7004535. I think we need RFE to cleanup PrintOpto. I never used it since I thought it is duplicate of PrintCompilation. And thank you for fixing find()! I also saw that it spend a lot of time in old_arena()->contains(n) when you have big graph. And we need this check only after Matcher, during Optimize we have only one arena. It would be nice to avoid call to noninlined contains() with a simple check. Also we pass VectorSets as references but inside find_recur() we take pointer, why not just pass pointers? Why default value OSROnlyBCI is -1? I think it should be 0 since 0 should not be used as compile_id. Otherwise it is confusing: based on the flag's comment it loops like you always exclude first OSR compilation. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7024475 > > 7024475: loop doesn't terminate when compiled > Reviewed-by: > > The code which replaces an empty loop with the final computed value > only works correctly if the the loop is guaranteed to execute once > since it replaces the conditionally executed loop body with a value. > Loop transformations like peeling generally result in zero trip guards > being generated but they aren't required to be there. The fix is to > make sure we have a guard by peeling the loop first. This results in > a small redundant test in some cases. I added a check for obvious > ones, which occurred in scimark SOR. Main and post loops are > constructed with zero trip guards so I assume one exists in those > cases. Tested with new test case, original failing program, > refworkload and full CTW. > > I also improved a few debugging features. Node::find could get into > an infinite loop walking debug_orig, so it should be check for a > cycle. I made some other efficiency improvements before I realized > that the problem was a cycle. I went ahead and kept those changes. > IdealGraphPrinter should print out a few more debug fields and should > dump the block structure if it exists. I changed the printing after > beautify loops so it only happens once instead of after each recursive > call. I added an OSROnlyBCI flag to control which OSR bcis can be > compiled. I changed the assert in loop verification to allow verifying > when the igvn worklist isn't empty. From john.coomes at oracle.com Fri Mar 25 13:03:58 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Mar 2011 20:03:58 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 26 new changesets Message-ID: <20110325200444.039534749B@hg.openjdk.java.net> Changeset: 1216415d8e35 Author: tonyp Date: 2011-03-04 17:13 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1216415d8e35 7014923: G1: code cleanup Summary: Some G1 code cleanup. Reviewed-by: johnc, jcoomes, jwilhelm ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! 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/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: a2c2eac1ca62 Author: jcoomes Date: 2011-03-06 11:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a2c2eac1ca62 7018056: large pages not always enabled by default Reviewed-by: phh, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp Changeset: c93aa6caa02f Author: brutisso Date: 2011-03-03 22:58 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c93aa6caa02f 7022943: G1: improve logging to avoid interleaved numbers Summary: Introduced buffered loggging to make sure that log lines are logged one line at a time Reviewed-by: stefank, johnc, dsamersoff ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 04d1138b4cce Author: brutisso Date: 2011-03-03 11:35 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/04d1138b4cce 7023747: G1: too strict assert in RefineRecordRefsIntoCSCardTableEntryClosure::do_card_ptr in g1RemSet.cpp Summary: Made sure that the assert looks at ParallelGCThreads. Reviewed-by: stefank, tonyp, jwilhelm, johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: a181f3a124dd Author: ysr Date: 2011-03-14 21:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a181f3a124dd 6987703: iCMS: Intermittent hang with gc/gctests/CallGC/CallGC01 and +ExplicitGCInvokesConcurrent Summary: Count enable_icms() and disable_icms() events so as to prevent inteference between concurrent calls, which can cause the iCMS thread to be left stranded in icms_wait() with an unserviced request and no young allocations to unwedge it. Reviewed-by: jcoomes, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.hpp Changeset: 1fb790245268 Author: jwilhelm Date: 2011-03-11 16:35 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1fb790245268 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. Summary: Check that -XX:ParGCArrayScanChunk has a value larger than zero. Reviewed-by: johnc, jmasa, ysr ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 1abd292f8c38 Author: jwilhelm Date: 2011-03-15 09:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1abd292f8c38 Merge Changeset: dde920245681 Author: ysr Date: 2011-03-16 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dde920245681 6896099: Integrate CMS heap ergo with default heap sizing ergo 6627787: CMS: JVM refuses to start up with -Xms16m -Xmx16m 7000125: CMS: Anti-monotone young gen sizing with respect to maximum whole heap size specification 7027529: CMS: retire CMSUseOldDefaults flag Summary: Simplify CMS heap sizing code, relying on ergonomic initial sizing consistent with other collectors for the most part, controlling only young gen sizing to rein in pause times. Make CMS young gen sizing default statically cpu-dependant. Remove inconsistencies wrt generation sizing and policy code, allowing for the fixing for 6627787 and 7000125. For 7027529, retire the flag CMSUseOldDefaults which had been introduced as a bridge from JDK 5 to JDK 6 a number of years ago. Reviewed-by: brutisso, poonam ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 92da084fefc9 Author: ysr Date: 2011-03-17 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/92da084fefc9 6668573: CMS: reference processing crash if ParallelCMSThreads > ParallelGCThreads Summary: Use _max_num_q = max(discovery_degree, processing_degree), and let balance_queues() redistribute from discovery_degree to processing_degree of queues. This should also allow a more dynamic and flexible parallelism policy in the future. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 048f98400b8e Author: jcoomes Date: 2011-03-18 09:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/048f98400b8e Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2707f76d15e3 Author: schien Date: 2011-03-17 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2707f76d15e3 Added tag jdk7-b134 for changeset 447e6faab4a8 ! .hgtags Changeset: fc1b183bfc0a Author: trims Date: 2011-03-17 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fc1b183bfc0a Added tag hs21-b04 for changeset 3c76374706ea ! .hgtags Changeset: e97ad5d5c990 Author: trims Date: 2011-03-18 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e97ad5d5c990 Merge Changeset: b898f0fc3ced Author: trims Date: 2011-03-18 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b898f0fc3ced 7028846: Bump the HS21 build number to 05 Summary: Update the HS21 build number to 05 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d673ef06fe96 Author: never Date: 2011-03-18 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d673ef06fe96 7028374: race in fix_oop_relocations for scavengeable nmethods Reviewed-by: kvn ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/memory/universe.cpp Changeset: c7f3d0b4570f Author: never Date: 2011-03-18 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c7f3d0b4570f 7017732: move static fields into Class to prepare for perm gen removal Reviewed-by: kvn, coleenp, twisti, stefank ! agent/src/share/classes/sun/jvm/hotspot/jdi/FieldImpl.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/IntField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/test/jdi/sasanity.sh ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/dump_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciCPCache.cpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciInstance.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp + src/share/vm/oops/instanceMirrorKlass.cpp + src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/shark/sharkNativeWrapper.cpp Changeset: 57552dca1708 Author: never Date: 2011-03-21 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/57552dca1708 7029509: nightly failures after static fields in Class Reviewed-by: kvn ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/services/heapDumper.cpp Changeset: 924777755fad Author: jcoomes Date: 2011-03-21 18:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/924777755fad 6962930: make the string table size configurable Reviewed-by: never, phh, stefank, kamg, dholmes, coleenp ! agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b099aaf51bf8 Author: jcoomes Date: 2011-03-22 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b099aaf51bf8 6962931: move interned strings out of the perm gen Reviewed-by: never, coleenp, ysr, jwilhelm ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/globals.hpp Changeset: 32f7097f9d8f Author: never Date: 2011-03-23 10:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/32f7097f9d8f 7030300: more nightly failures after statics in Class changes Reviewed-by: iveresov, jcoomes, dcubed ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp Changeset: f195ebb181b8 Author: jcoomes Date: 2011-03-24 23:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f195ebb181b8 Merge Changeset: 0e3ed5a14f73 Author: jcoomes Date: 2011-03-24 23:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0e3ed5a14f73 Merge ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/stringopts.cpp - test/compiler/6987555/Test6987555.java - test/compiler/6991596/Test6991596.java Changeset: 083f13976b51 Author: dholmes Date: 2011-03-21 22:16 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/083f13976b51 6535709: interrupt of wait()ing thread isn't triggerring InterruptedException - test intwait3 Summary: only clear the interrupt state if we will report that it was set Reviewed-by: dcubed, alanb, phh, coleenp, dice ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fc416c2556ec Author: mchung Date: 2011-03-22 18:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fc416c2556ec 7025628: Remove the temporary hack added for jdk modularization in hotspot Summary: Removed Reviewed-by: ohair, coleenp ! src/share/vm/runtime/os.cpp Changeset: 006b3750a4d4 Author: jcoomes Date: 2011-03-24 23:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/006b3750a4d4 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: f731b22cd52d Author: jcoomes Date: 2011-03-24 23:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f731b22cd52d Merge ! src/share/vm/interpreter/bytecodeInterpreter.cpp From tom.rodriguez at oracle.com Fri Mar 25 13:06:56 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Mar 2011 13:06:56 -0700 Subject: review (M) for 7024475: loop doesn't terminate when compiled In-Reply-To: <4D8CF2C1.8020408@oracle.com> References: <4D8CF2C1.8020408@oracle.com> Message-ID: On Mar 25, 2011, at 12:53 PM, Vladimir Kozlov wrote: > Add comment that guard is generated explicitly for main and post loops: > > + bool needs_guard = !cl->is_main_loop && !cl->is_post_loop(); > Ok. > > + if (bol->is_Bool() && bol->as_Bool()->_test._test == BoolTest::lt) { > > should be: > > + if (bol->is_Bool() && bol->as_Bool()->_test._test == > + cl->loopexit()->test_trip()) { Ok. > > I will modify this code to skip cloned predicates for 7004535. > > I think we need RFE to cleanup PrintOpto. I never used it since I thought it is duplicate of PrintCompilation. Me either. It always seemed like just a random collection of printing code. > > And thank you for fixing find()! I also saw that it spend a lot of time in old_arena()->contains(n) when you have big graph. And we need this check only after Matcher, during Optimize we have only one arena. It would be nice to avoid call to noninlined contains() with a simple check. That's why I switched to old_arena instead of node_arena. It starts out empty so the check is faster. The inlining is only a minor difference I think though. > Also we pass VectorSets as references but inside find_recur() we take pointer, why not just pass pointers? I considered fixing that so I will go ahead. I've updated the webrev with these changes. > > Why default value OSROnlyBCI is -1? I think it should be 0 since 0 should not be used as compile_id. Otherwise it is confusing: based on the flag's comment it loops like you always exclude first OSR compilation. It's a bci not a compile_id. Given that I accept both negative and postive values there aren't any good values, though I guess max int would work. That's why I check FLAG_IS_DEFAULT to determine whether to check the value. I know it's kind of odd but I couldn't see a better way. Maybe it should operate like DeoptimizeOnlyAt instead: char buffer[8]; jio_snprintf(buffer, sizeof(buffer), "%d", sd->bci()); size_t len = strlen(buffer); const char * found = strstr(DeoptimizeOnlyAt, buffer); while (found != NULL) { if ((found[len] == ',' || found[len] == '\n' || found[len] == '\0') && (found == DeoptimizeOnlyAt || found[-1] == ',' || found[-1] == '\n')) { // Check that the bci found is bracketed by terminators. break; } found = strstr(found + 1, buffer); } That allows specifying multiple bcis. I'd also considered adding an option directive so you could say something like: -XX:CompileCommand=option,Test,test,OSROnlyBCI=49,600 to restrict it to a specific method too. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7024475 >> 7024475: loop doesn't terminate when compiled >> Reviewed-by: >> The code which replaces an empty loop with the final computed value >> only works correctly if the the loop is guaranteed to execute once >> since it replaces the conditionally executed loop body with a value. >> Loop transformations like peeling generally result in zero trip guards >> being generated but they aren't required to be there. The fix is to >> make sure we have a guard by peeling the loop first. This results in >> a small redundant test in some cases. I added a check for obvious >> ones, which occurred in scimark SOR. Main and post loops are >> constructed with zero trip guards so I assume one exists in those >> cases. Tested with new test case, original failing program, >> refworkload and full CTW. >> I also improved a few debugging features. Node::find could get into >> an infinite loop walking debug_orig, so it should be check for a >> cycle. I made some other efficiency improvements before I realized >> that the problem was a cycle. I went ahead and kept those changes. >> IdealGraphPrinter should print out a few more debug fields and should >> dump the block structure if it exists. I changed the printing after >> beautify loops so it only happens once instead of after each recursive >> call. I added an OSROnlyBCI flag to control which OSR bcis can be >> compiled. I changed the assert in loop verification to allow verifying >> when the igvn worklist isn't empty. From tom.rodriguez at oracle.com Fri Mar 25 13:38:03 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Mar 2011 13:38:03 -0700 Subject: Subject text Message-ID: 6378256: Performance problem with System.identityHashCode in client compiler Reviewed-by: The hashCode for an object can often be grabbed directly from the header instead of going into the runtime and C1 has an existing optimization for Object.hashCode. System.identityHashCode is the same as calling Object.hashCode directly and should have the same optimization. The fix is to use the same trick for identityHashCode as is being used for Object.hashCode with the addition of a null check. Doing this is 10 times faster. Tested with test case from report. I also added an implementation for x86_64 which is just a straight copy of the x86_32 code. I put it under !TIERED since in the tiered world the extra code just makes the C2 version slightly slower. As an aside, C2 implements Object.hashCode using a vtable check to deal with the potential overloading. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110325/dd62cbc0/attachment.html From tom.rodriguez at oracle.com Fri Mar 25 13:38:04 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Mar 2011 13:38:04 -0700 Subject: Subject text Message-ID: <06BC7B3C-346A-4205-8830-2FA05F784481@oracle.com> 6378256: Performance problem with System.identityHashCode in client compiler Reviewed-by: The hashCode for an object can often be grabbed directly from the header instead of going into the runtime and C1 has an existing optimization for Object.hashCode. System.identityHashCode is the same as calling Object.hashCode directly and should have the same optimization. The fix is to use the same trick for identityHashCode as is being used for Object.hashCode with the addition of a null check. Doing this is 10 times faster. Tested with test case from report. I also added an implementation for x86_64 which is just a straight copy of the x86_32 code. I put it under !TIERED since in the tiered world the extra code just makes the C2 version slightly slower. As an aside, C2 implements Object.hashCode using a vtable check to deal with the potential overloading. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110325/72cee263/attachment.html From tom.rodriguez at oracle.com Fri Mar 25 13:39:08 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Mar 2011 13:39:08 -0700 Subject: Subject text In-Reply-To: <06BC7B3C-346A-4205-8830-2FA05F784481@oracle.com> References: <06BC7B3C-346A-4205-8830-2FA05F784481@oracle.com> Message-ID: Accidentally pushed send too early. Ignore for now. tom On Mar 25, 2011, at 1:38 PM, Tom Rodriguez wrote: > 6378256: Performance problem with System.identityHashCode in client compiler > Reviewed-by: > > The hashCode for an object can often be grabbed directly from the > header instead of going into the runtime and C1 has an existing > optimization for Object.hashCode. System.identityHashCode is the same > as calling Object.hashCode directly and should have the same > optimization. The fix is to use the same trick for identityHashCode > as is being used for Object.hashCode with the addition of a null > check. Doing this is 10 times faster. Tested with test case from > report. I also added an implementation for x86_64 which is just a > straight copy of the x86_32 code. I put it under !TIERED since in the > tiered world the extra code just makes the C2 version slightly slower. > > As an aside, C2 implements Object.hashCode using a vtable check to deal > with the potential overloading. > From igor.veresov at oracle.com Fri Mar 25 13:58:52 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 25 Mar 2011 13:58:52 -0700 Subject: review (XS) for 6478991: C1 NullCheckEliminator yields incorrect exceptions In-Reply-To: <2CB16D5E-3B3E-4791-B356-6DC5613DCF94@oracle.com> References: <2CB16D5E-3B3E-4791-B356-6DC5613DCF94@oracle.com> Message-ID: <4D8D020C.1090508@oracle.com> Looks good. igor On 3/25/11 11:37 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6478991 > > 6478991: C1 NullCheckEliminator yields incorrect exceptions > Reviewed-by: > > checkcast can trap so don't allow explicit null checks to be folded into > instructions that follow it. Tested with new test case. From vladimir.kozlov at oracle.com Fri Mar 25 14:04:38 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Mar 2011 14:04:38 -0700 Subject: review (M) for 7024475: loop doesn't terminate when compiled In-Reply-To: References: <4D8CF2C1.8020408@oracle.com> Message-ID: <4D8D0366.3020405@oracle.com> It looks good. Sorry, I somehow thought OSROnlyBCI is compile_id, if it is bci then -1 is fine. And I did not realized that you switched to old_arena() check, nice change. Thanks, Vladimir Tom Rodriguez wrote: > On Mar 25, 2011, at 12:53 PM, Vladimir Kozlov wrote: > >> Add comment that guard is generated explicitly for main and post loops: >> >> + bool needs_guard = !cl->is_main_loop && !cl->is_post_loop(); >> > > Ok. > >> + if (bol->is_Bool() && bol->as_Bool()->_test._test == BoolTest::lt) { >> >> should be: >> >> + if (bol->is_Bool() && bol->as_Bool()->_test._test == >> + cl->loopexit()->test_trip()) { > > Ok. > >> I will modify this code to skip cloned predicates for 7004535. >> >> I think we need RFE to cleanup PrintOpto. I never used it since I thought it is duplicate of PrintCompilation. > > Me either. It always seemed like just a random collection of printing code. > >> And thank you for fixing find()! I also saw that it spend a lot of time in old_arena()->contains(n) when you have big graph. And we need this check only after Matcher, during Optimize we have only one arena. It would be nice to avoid call to noninlined contains() with a simple check. > > That's why I switched to old_arena instead of node_arena. It starts out empty so the check is faster. The inlining is only a minor difference I think though. > >> Also we pass VectorSets as references but inside find_recur() we take pointer, why not just pass pointers? > > I considered fixing that so I will go ahead. I've updated the webrev with these changes. > >> Why default value OSROnlyBCI is -1? I think it should be 0 since 0 should not be used as compile_id. Otherwise it is confusing: based on the flag's comment it loops like you always exclude first OSR compilation. > > It's a bci not a compile_id. Given that I accept both negative and postive values there aren't any good values, though I guess max int would work. That's why I check FLAG_IS_DEFAULT to determine whether to check the value. I know it's kind of odd but I couldn't see a better way. Maybe it should operate like DeoptimizeOnlyAt instead: > > char buffer[8]; > jio_snprintf(buffer, sizeof(buffer), "%d", sd->bci()); > size_t len = strlen(buffer); > const char * found = strstr(DeoptimizeOnlyAt, buffer); > while (found != NULL) { > if ((found[len] == ',' || found[len] == '\n' || found[len] == '\0') && > (found == DeoptimizeOnlyAt || found[-1] == ',' || found[-1] == '\n')) { > // Check that the bci found is bracketed by terminators. > break; > } > found = strstr(found + 1, buffer); > } > > That allows specifying multiple bcis. I'd also considered adding an option directive so you could say something like: > > -XX:CompileCommand=option,Test,test,OSROnlyBCI=49,600 > > to restrict it to a specific method too. > > tom > >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7024475 >>> 7024475: loop doesn't terminate when compiled >>> Reviewed-by: >>> The code which replaces an empty loop with the final computed value >>> only works correctly if the the loop is guaranteed to execute once >>> since it replaces the conditionally executed loop body with a value. >>> Loop transformations like peeling generally result in zero trip guards >>> being generated but they aren't required to be there. The fix is to >>> make sure we have a guard by peeling the loop first. This results in >>> a small redundant test in some cases. I added a check for obvious >>> ones, which occurred in scimark SOR. Main and post loops are >>> constructed with zero trip guards so I assume one exists in those >>> cases. Tested with new test case, original failing program, >>> refworkload and full CTW. >>> I also improved a few debugging features. Node::find could get into >>> an infinite loop walking debug_orig, so it should be check for a >>> cycle. I made some other efficiency improvements before I realized >>> that the problem was a cycle. I went ahead and kept those changes. >>> IdealGraphPrinter should print out a few more debug fields and should >>> dump the block structure if it exists. I changed the printing after >>> beautify loops so it only happens once instead of after each recursive >>> call. I added an OSROnlyBCI flag to control which OSR bcis can be >>> compiled. I changed the assert in loop verification to allow verifying >>> when the igvn worklist isn't empty. > From tom.rodriguez at oracle.com Fri Mar 25 16:38:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Mar 2011 16:38:32 -0700 Subject: Request for review(M): 6964776: c2 should ensure the polling page is reachable on 64 bit In-Reply-To: <4D8CEE35.1010707@oracle.com> References: <4D8CEE35.1010707@oracle.com> Message-ID: <127E92DB-C6B0-477D-A7C8-BBAC25CB7261@oracle.com> I think this looks good. Could you put a small comment on use the using directive to note that it's there to reexport the other testl variants hidden by the override? tom On Mar 25, 2011, at 12:34 PM, Igor Veresov wrote: > C1 and C2 could only use rip-relative addressing when emitting the page-polling code, which limited the distance from the code cache to the polling page is more than 2G (doesn't fit in a signed 32bit displacement). The solution in this case is to materialize the absolute pointer to the polling page in a register first, as we do on SPARC. > > Webrev: http://cr.openjdk.java.net/~iveresov/6964776/webrev.00/ > > Thanks, > igor From tom.rodriguez at oracle.com Fri Mar 25 16:38:46 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Mar 2011 16:38:46 -0700 Subject: review (M) for 7024475: loop doesn't terminate when compiled In-Reply-To: <4D8D0366.3020405@oracle.com> References: <4D8CF2C1.8020408@oracle.com> <4D8D0366.3020405@oracle.com> Message-ID: <32005C15-1445-40E9-AB4C-2DDC3F777BF3@oracle.com> Thanks! tom On Mar 25, 2011, at 2:04 PM, Vladimir Kozlov wrote: > It looks good. > > Sorry, I somehow thought OSROnlyBCI is compile_id, if it is bci then -1 is fine. And I did not realized that you switched to old_arena() check, nice change. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Mar 25, 2011, at 12:53 PM, Vladimir Kozlov wrote: >>> Add comment that guard is generated explicitly for main and post loops: >>> >>> + bool needs_guard = !cl->is_main_loop && !cl->is_post_loop(); >>> >> Ok. >>> + if (bol->is_Bool() && bol->as_Bool()->_test._test == BoolTest::lt) { >>> >>> should be: >>> >>> + if (bol->is_Bool() && bol->as_Bool()->_test._test == >>> + cl->loopexit()->test_trip()) { >> Ok. >>> I will modify this code to skip cloned predicates for 7004535. >>> >>> I think we need RFE to cleanup PrintOpto. I never used it since I thought it is duplicate of PrintCompilation. >> Me either. It always seemed like just a random collection of printing code. >>> And thank you for fixing find()! I also saw that it spend a lot of time in old_arena()->contains(n) when you have big graph. And we need this check only after Matcher, during Optimize we have only one arena. It would be nice to avoid call to noninlined contains() with a simple check. >> That's why I switched to old_arena instead of node_arena. It starts out empty so the check is faster. The inlining is only a minor difference I think though. >>> Also we pass VectorSets as references but inside find_recur() we take pointer, why not just pass pointers? >> I considered fixing that so I will go ahead. I've updated the webrev with these changes. >>> Why default value OSROnlyBCI is -1? I think it should be 0 since 0 should not be used as compile_id. Otherwise it is confusing: based on the flag's comment it loops like you always exclude first OSR compilation. >> It's a bci not a compile_id. Given that I accept both negative and postive values there aren't any good values, though I guess max int would work. That's why I check FLAG_IS_DEFAULT to determine whether to check the value. I know it's kind of odd but I couldn't see a better way. Maybe it should operate like DeoptimizeOnlyAt instead: >> char buffer[8]; >> jio_snprintf(buffer, sizeof(buffer), "%d", sd->bci()); >> size_t len = strlen(buffer); >> const char * found = strstr(DeoptimizeOnlyAt, buffer); >> while (found != NULL) { >> if ((found[len] == ',' || found[len] == '\n' || found[len] == '\0') && >> (found == DeoptimizeOnlyAt || found[-1] == ',' || found[-1] == '\n')) { >> // Check that the bci found is bracketed by terminators. >> break; >> } >> found = strstr(found + 1, buffer); >> } >> That allows specifying multiple bcis. I'd also considered adding an option directive so you could say something like: >> -XX:CompileCommand=option,Test,test,OSROnlyBCI=49,600 >> to restrict it to a specific method too. >> tom >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7024475 >>>> 7024475: loop doesn't terminate when compiled >>>> Reviewed-by: >>>> The code which replaces an empty loop with the final computed value >>>> only works correctly if the the loop is guaranteed to execute once >>>> since it replaces the conditionally executed loop body with a value. >>>> Loop transformations like peeling generally result in zero trip guards >>>> being generated but they aren't required to be there. The fix is to >>>> make sure we have a guard by peeling the loop first. This results in >>>> a small redundant test in some cases. I added a check for obvious >>>> ones, which occurred in scimark SOR. Main and post loops are >>>> constructed with zero trip guards so I assume one exists in those >>>> cases. Tested with new test case, original failing program, >>>> refworkload and full CTW. >>>> I also improved a few debugging features. Node::find could get into >>>> an infinite loop walking debug_orig, so it should be check for a >>>> cycle. I made some other efficiency improvements before I realized >>>> that the problem was a cycle. I went ahead and kept those changes. >>>> IdealGraphPrinter should print out a few more debug fields and should >>>> dump the block structure if it exists. I changed the printing after >>>> beautify loops so it only happens once instead of after each recursive >>>> call. I added an OSROnlyBCI flag to control which OSR bcis can be >>>> compiled. I changed the assert in loop verification to allow verifying >>>> when the igvn worklist isn't empty. From igor.veresov at oracle.com Fri Mar 25 17:12:01 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 25 Mar 2011 17:12:01 -0700 Subject: Request for review(M): 6964776: c2 should ensure the polling page is reachable on 64 bit In-Reply-To: <127E92DB-C6B0-477D-A7C8-BBAC25CB7261@oracle.com> References: <4D8CEE35.1010707@oracle.com> <127E92DB-C6B0-477D-A7C8-BBAC25CB7261@oracle.com> Message-ID: <4D8D2F51.2050709@oracle.com> On 3/25/11 4:38 PM, Tom Rodriguez wrote: > I think this looks good. Thanks! > Could you put a small comment on use the using directive to note that it's there to reexport the other testl variants hidden by the override? Sure, updated. igor > > tom > > On Mar 25, 2011, at 12:34 PM, Igor Veresov wrote: > >> C1 and C2 could only use rip-relative addressing when emitting the page-polling code, which limited the distance from the code cache to the polling page is more than 2G (doesn't fit in a signed 32bit displacement). The solution in this case is to materialize the absolute pointer to the polling page in a register first, as we do on SPARC. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6964776/webrev.00/ >> >> Thanks, >> igor > From tom.rodriguez at oracle.com Fri Mar 25 17:18:24 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Mar 2011 17:18:24 -0700 Subject: Request for review(M): 6964776: c2 should ensure the polling page is reachable on 64 bit In-Reply-To: <4D8D2F51.2050709@oracle.com> References: <4D8CEE35.1010707@oracle.com> <127E92DB-C6B0-477D-A7C8-BBAC25CB7261@oracle.com> <4D8D2F51.2050709@oracle.com> Message-ID: <28038E1D-86A0-469E-9FAB-354EB53EF79F@oracle.com> Looks good. tom On Mar 25, 2011, at 5:12 PM, Igor Veresov wrote: > On 3/25/11 4:38 PM, Tom Rodriguez wrote: >> I think this looks good. > Thanks! >> Could you put a small comment on use the using directive to note that it's there to reexport the other testl variants hidden by the override? > Sure, updated. > > igor >> >> tom >> >> On Mar 25, 2011, at 12:34 PM, Igor Veresov wrote: >> >>> C1 and C2 could only use rip-relative addressing when emitting the page-polling code, which limited the distance from the code cache to the polling page is more than 2G (doesn't fit in a signed 32bit displacement). The solution in this case is to materialize the absolute pointer to the polling page in a register first, as we do on SPARC. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/6964776/webrev.00/ >>> >>> Thanks, >>> igor >> > From vladimir.kozlov at oracle.com Fri Mar 25 17:31:36 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Mar 2011 17:31:36 -0700 Subject: Request for review(M): 6964776: c2 should ensure the polling page is reachable on 64 bit In-Reply-To: <4D8CEE35.1010707@oracle.com> References: <4D8CEE35.1010707@oracle.com> Message-ID: <4D8D33E8.4000404@oracle.com> x86_64.ad: + // It does it the polling page is more than disp32 away. --- // It needs it when polling page is more than disp32 away. Usually predicate is first in instructions definitions. Vladimir Igor Veresov wrote: > C1 and C2 could only use rip-relative addressing when emitting the > page-polling code, which limited the distance from the code cache to the > polling page is more than 2G (doesn't fit in a signed 32bit > displacement). The solution in this case is to materialize the absolute > pointer to the polling page in a register first, as we do on SPARC. > > Webrev: http://cr.openjdk.java.net/~iveresov/6964776/webrev.00/ > > Thanks, > igor From tom.rodriguez at oracle.com Fri Mar 25 17:35:06 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 26 Mar 2011 00:35:06 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110326003511.C70A0474AA@hg.openjdk.java.net> Changeset: 322a41ec766c Author: never Date: 2011-03-25 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/322a41ec766c 7025708: Assertion if using "-XX:+CITraceTypeFlow -XX:+Verbose" together Reviewed-by: never Contributed-by: volker.simonis at gmail.com ! src/share/vm/ci/ciTypeFlow.cpp Changeset: b2949bf39900 Author: never Date: 2011-03-25 18:19 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b2949bf39900 Merge From igor.veresov at oracle.com Fri Mar 25 19:48:01 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 25 Mar 2011 19:48:01 -0700 Subject: Request for review(M): 6964776: c2 should ensure the polling page is reachable on 64 bit In-Reply-To: <4D8D33E8.4000404@oracle.com> References: <4D8CEE35.1010707@oracle.com> <4D8D33E8.4000404@oracle.com> Message-ID: <4D8D53E1.7080501@oracle.com> On 3/25/11 5:31 PM, Vladimir Kozlov wrote: > x86_64.ad: > + // It does it the polling page is more than disp32 away. > --- > // It needs it when polling page is more than disp32 away. Ah, typo, thanks! Actually I meant "it does _if_ the polling page ..." be a continuation of the previous comment line. > > Usually predicate is first in instructions definitions. All fixed and updated. igor > > Vladimir > > Igor Veresov wrote: >> C1 and C2 could only use rip-relative addressing when emitting the >> page-polling code, which limited the distance from the code cache to >> the polling page is more than 2G (doesn't fit in a signed 32bit >> displacement). The solution in this case is to materialize the >> absolute pointer to the polling page in a register first, as we do on >> SPARC. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6964776/webrev.00/ >> >> Thanks, >> igor From vladimir.kozlov at oracle.com Fri Mar 25 20:10:32 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Mar 2011 20:10:32 -0700 Subject: Request for review(M): 6964776: c2 should ensure the polling page is reachable on 64 bit In-Reply-To: <4D8D53E1.7080501@oracle.com> References: <4D8CEE35.1010707@oracle.com> <4D8D33E8.4000404@oracle.com> <4D8D53E1.7080501@oracle.com> Message-ID: <4D8D5928.5010303@oracle.com> Good. Vladimir On 3/25/11 7:48 PM, Igor Veresov wrote: > On 3/25/11 5:31 PM, Vladimir Kozlov wrote: >> x86_64.ad: >> + // It does it the polling page is more than disp32 away. >> --- >> // It needs it when polling page is more than disp32 away. > > Ah, typo, thanks! Actually I meant "it does _if_ the polling page ..." be a continuation of the previous comment line. > >> >> Usually predicate is first in instructions definitions. > > All fixed and updated. > > igor > >> >> Vladimir >> >> Igor Veresov wrote: >>> C1 and C2 could only use rip-relative addressing when emitting the >>> page-polling code, which limited the distance from the code cache to >>> the polling page is more than 2G (doesn't fit in a signed 32bit >>> displacement). The solution in this case is to materialize the >>> absolute pointer to the polling page in a register first, as we do on >>> SPARC. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/6964776/webrev.00/ >>> >>> Thanks, >>> igor > From igor.veresov at oracle.com Fri Mar 25 21:15:59 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 25 Mar 2011 21:15:59 -0700 Subject: Request for review(M): 6964776: c2 should ensure the polling page is reachable on 64 bit In-Reply-To: <4D8D5928.5010303@oracle.com> References: <4D8CEE35.1010707@oracle.com> <4D8D33E8.4000404@oracle.com> <4D8D53E1.7080501@oracle.com> <4D8D5928.5010303@oracle.com> Message-ID: <4D8D687F.6030002@oracle.com> Thanks Vladimir and Tom! On 3/25/11 8:10 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 3/25/11 7:48 PM, Igor Veresov wrote: >> On 3/25/11 5:31 PM, Vladimir Kozlov wrote: >>> x86_64.ad: >>> + // It does it the polling page is more than disp32 away. >>> --- >>> // It needs it when polling page is more than disp32 away. >> >> Ah, typo, thanks! Actually I meant "it does _if_ the polling page ..." >> be a continuation of the previous comment line. >> >>> >>> Usually predicate is first in instructions definitions. >> >> All fixed and updated. >> >> igor >> >>> >>> Vladimir >>> >>> Igor Veresov wrote: >>>> C1 and C2 could only use rip-relative addressing when emitting the >>>> page-polling code, which limited the distance from the code cache to >>>> the polling page is more than 2G (doesn't fit in a signed 32bit >>>> displacement). The solution in this case is to materialize the >>>> absolute pointer to the polling page in a register first, as we do on >>>> SPARC. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/6964776/webrev.00/ >>>> >>>> Thanks, >>>> igor >> From dawid.weiss at gmail.com Sat Mar 26 02:39:58 2011 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Sat, 26 Mar 2011 10:39:58 +0100 Subject: Endless loops in computation code (1.6.0_22). In-Reply-To: <5724F79D-C687-4DA8-8C1F-85F77B2D37DF@oracle.com> References: <7684FD62-77E8-476F-AD2F-479ACC66A79A@oracle.com> <6844B58D-2A2A-4420-A5D9-A71AA4C3332C@oracle.com> <9C75054E-68AA-46C3-8E77-B729048091B2@oracle.com> <5724F79D-C687-4DA8-8C1F-85F77B2D37DF@oracle.com> Message-ID: > [snip] code was replacing the loop with the result it produced but that's only valid if it already has a zero trip guard. ?Pretty much all the time it does but in this case it didn't. Ok, clear -- thanks. > Note that neither your original program nor the test case have an obvious empty loop. ?In both cases it results from optimizations on the original loop These transformations that happen at the graph level are quite magical. I wonder how long does it take for the a-ha moment when you grasp what's going on in the jit/ optimizer code -- I looked at it a few times and it's still magic to me. Anyway, an interesting social-research problem: isn't it intriguing that a loop optimizer bug would not manifest itself more frequently given the number of lines of code in Java out there in the world? I mean: even if the probability of hitting this is very close to zero, multiplied by the number of Java code lines should bring it to attention earlier... unless Java coding patterns are stone-carved in people's minds without them being aware of this fact (this particular snippet was rewritten from the C world). This made me think if a random code fuzzifier executed on two different JVMs would bring more of such highlights to our attention (by comparing the results, or stack snapshots?). This has been done for detecting JavaScript/ browser exploits and worked wonders -- can't remember the pointer off the top of my head, but shouldn't be too hard to find. Interesting. > It's in the bug report and I made a regression test for it which I included in my fix. ?http://cr.openjdk.java.net/~never/7024475/raw_files/new/test/compiler/7024475/Test7024475.java I played with it a little bit wondering what's the minimal set of clauses that would show this behavior. Randomly fuzzifying the code here and there I could bring it down to this: public class Test7024475 { static int x1; static void test(int i, int c0, int j, int c1) { for (;;) { if (c1 > c0) { if (c0 > 253) { throw new InternalError("c0 = " + c0); } if (1 < j - i) x1 = 0; j = i; c1--; } else { c0--; if (j <= 0) break; c1 = 255; } } } public static void main(String args[]) { Test7024475 t = new Test7024475(); for (int n = 0; n < 100000; n++) { test(2, 85, 1, 134); } } } Removing anything from here on either changes the logic of the program or doesn't cause the buggy optimization to happen. More precisely, removing if (1 < j - i) x1 = 0; still causes InternalError to occur, but it takes a much longer time (in seconds as opposed to nearly immediately). Dawid From tom.rodriguez at oracle.com Sat Mar 26 08:28:59 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sat, 26 Mar 2011 15:28:59 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7022204: LogFile wildcarding should use %p instead of star Message-ID: <20110326152903.129A1474CC@hg.openjdk.java.net> Changeset: 29524004ce17 Author: never Date: 2011-03-25 18:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/29524004ce17 7022204: LogFile wildcarding should use %p instead of star Reviewed-by: coleenp, jrose ! src/share/vm/utilities/ostream.cpp From roland.westrelin at oracle.com Sat Mar 26 10:30:40 2011 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Sat, 26 Mar 2011 17:30:40 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110326173045.86FDE474D1@hg.openjdk.java.net> Changeset: 7e88bdae86ec Author: roland Date: 2011-03-25 09:35 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7e88bdae86ec 7029017: Additional architecture support for c2 compiler Summary: Enables cross building of a c2 VM. Support masking of shift counts when the processor architecture mandates it. Reviewed-by: kvn, never ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/main.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp Changeset: 244bf8afbbd3 Author: roland Date: 2011-03-26 08:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/244bf8afbbd3 Merge From tom.rodriguez at oracle.com Sun Mar 27 02:17:53 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Sun, 27 Mar 2011 09:17:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7024475: loop doesn't terminate when compiled Message-ID: <20110327091755.56D8E474F1@hg.openjdk.java.net> Changeset: 1927db75dd85 Author: never Date: 2011-03-27 00:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1927db75dd85 7024475: loop doesn't terminate when compiled Reviewed-by: kvn ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/runtime/globals.hpp + test/compiler/7024475/Test7024475.java From igor.veresov at oracle.com Sun Mar 27 22:48:49 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Mon, 28 Mar 2011 05:48:49 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6964776: c2 should ensure the polling page is reachable on 64 bit Message-ID: <20110328054855.BE85F47528@hg.openjdk.java.net> Changeset: b40d4fa697bf Author: iveresov Date: 2011-03-27 13:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b40d4fa697bf 6964776: c2 should ensure the polling page is reachable on 64 bit Summary: Materialize the pointer to the polling page in a register instead of using rip-relative addressing when the distance from the code cache is larger than disp32. Reviewed-by: never, kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/x86_64.ad From christian.thalinger at oracle.com Mon Mar 28 01:41:29 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 28 Mar 2011 10:41:29 +0200 Subject: review (XS) for 6478991: C1 NullCheckEliminator yields incorrect exceptions In-Reply-To: <2CB16D5E-3B3E-4791-B356-6DC5613DCF94@oracle.com> References: <2CB16D5E-3B3E-4791-B356-6DC5613DCF94@oracle.com> Message-ID: <20ED65E2-2BBC-45A4-9227-E56326C3052C@oracle.com> On Mar 25, 2011, at 7:37 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6478991 > > 6478991: C1 NullCheckEliminator yields incorrect exceptions > Reviewed-by: > > checkcast can trap so don't allow explicit null checks to be folded into > instructions that follow it. Tested with new test case. The testcase misses the -Xcomp flag. -- Christian From christian.thalinger at oracle.com Mon Mar 28 06:11:57 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 28 Mar 2011 13:11:57 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7022998: JSR 292 recursive method handle calls inline themselves infinitely Message-ID: <20110328131159.2EA0B4753B@hg.openjdk.java.net> Changeset: 3d58a4983660 Author: twisti Date: 2011-03-28 03:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3d58a4983660 7022998: JSR 292 recursive method handle calls inline themselves infinitely Reviewed-by: never, kvn ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp From john.cuthbertson at oracle.com Mon Mar 28 10:35:28 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 28 Mar 2011 10:35:28 -0700 Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error In-Reply-To: <4D7ACDBA.7020003@oracle.com> References: <4D7ACDBA.7020003@oracle.com> Message-ID: <4D90C6E0.9000901@oracle.com> Hi Everyone, A new webrev with changes based upon comments from Tom can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.4/. The latest changes include inserting a suitably guarded barrier call in case the referent field of a Reference object is being read/fetched using JNI, reflection, or Unsafe. Thanks, JohnC On 3/11/2011 5:34 PM, John Cuthbertson wrote: > Hi Everyone, > > I'm looking for a few of volunteers to review the changes that fix > this assertion failure. The latest changes can be found at: > http://cr.openjdk.java.net/~johnc/7009266/webrev.3/ and include > changes based upon earlier internal reviews. The earlier changes are > also on cr.openjdk.java.net for reference. > > Background: > The G1 garbage collector includes a concurrent marking algorithm that > makes use of snapshot-at-the-beginning or SATB. With this algorithm > the GC will mark all objects that are reachable at the start of > marking; objects that are allocated since the start of marking are > implicitly considered live. In order to populate the "snapshot" of the > object graph that existed at the start of marking, G1 employs a write > barrier. When an object is stored into another object's field the > write-barrier records the previous value of that field as it was part > of the "snapshot" and concurrent marking will trace the sub-graph that > is reachable from this previous value. > > Unfortunately, in the presence of Reference objects, SATB might not be > sufficient to mark a referent object as live. Consider that, at the > start of marking, we have a weakly reachable object i.e. an object > where the only pointer to that object. If the referent is obtained > from the Reference object and stored to another object's field (making > the referent now strongly reachable and hence live) the G1 write > barrier will record the field's previous value but not the value of > the referent. > > If the referent object is strongly reachable from some other object > that will be traced by concurrent marking, _or_ there is a subsequent > assignment to the field where we have written the referent (in which > case we record the previous value - the referent - in an SATB buffer) > then the referent will be marked live. Otherwise the referent will not > be marked. > > That is the issue that was causing the failure in this CR. There was a > Logger object that was only reachable through a WeakReference at the > start of concurrent marking. During marking the Logger object is > obtained from the WeakReference and stored into a field of a live > object. The G1 write barrier recorded the previous value in the field > (as it is part of the snapshot at the start of marking). Since there > was no other assignment to the live object's field and there was no > other strong reference to the Logger object, the Logger object was not > marked. At the end of concurrent marking the Logger object was > considered dead and the link between the WeakReference and the Logger > was severed by clearing the referent field during reference processing. > > To solve this (entirely in Hotspot and causing a performance overhead > for G1 only) it was decided that the best approach was to intrinsify > the Reference.get() method in the JIT compilers and add new > interpreter entry points so that the value in the referent field will > be recorded in an SATB buffer by the G1 pre-barrier code. > > The changes for Zero and the C++ interpreters are place holder > routines but should be straight forward to implement. > > None of the individual changes is large - they are just well > distributed around the JVM. :) > > Testing: white box test; eyeballing the generated compiled and > interpreter code; the failing Kitchensink big-app on x86 (32/64 bit), > sparc (32/64 bit), Xint, Xcomp (client and server), with and without > G1; the GC test suite with and without G1; and jprt. > > Thanks and regards, > > JohnC From vladimir.kozlov at oracle.com Mon Mar 28 12:09:26 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Mar 2011 12:09:26 -0700 Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error In-Reply-To: <4D90C6E0.9000901@oracle.com> References: <4D7ACDBA.7020003@oracle.com> <4D90C6E0.9000901@oracle.com> Message-ID: <4D90DCE6.3000804@oracle.com> You need to regenerated webrev since callGenerator.hpp and callGenerator.cpp are empty now. unsafe.cpp: + // We could be accessing the the referent field in a reference ^ Why you are not using update_barrier_set_pre (as in Unsafe_CompareAndSwapObject)? you left test outputs: + tty->print_cr("####### Unsafe_GetObject: offset = " INTX_FORMAT, offset); tty->print_cr("####### Unsafe_GetObject: need a G1 barrier"); Vladimir John Cuthbertson wrote: > Hi Everyone, > > A new webrev with changes based upon comments from Tom can be found at: > http://cr.openjdk.java.net/~johnc/7009266/webrev.4/. > > The latest changes include inserting a suitably guarded barrier call in > case the referent field of a Reference object is being read/fetched > using JNI, reflection, or Unsafe. > > Thanks, > > JohnC > > On 3/11/2011 5:34 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> I'm looking for a few of volunteers to review the changes that fix >> this assertion failure. The latest changes can be found at: >> http://cr.openjdk.java.net/~johnc/7009266/webrev.3/ and include >> changes based upon earlier internal reviews. The earlier changes are >> also on cr.openjdk.java.net for reference. >> >> Background: >> The G1 garbage collector includes a concurrent marking algorithm that >> makes use of snapshot-at-the-beginning or SATB. With this algorithm >> the GC will mark all objects that are reachable at the start of >> marking; objects that are allocated since the start of marking are >> implicitly considered live. In order to populate the "snapshot" of the >> object graph that existed at the start of marking, G1 employs a write >> barrier. When an object is stored into another object's field the >> write-barrier records the previous value of that field as it was part >> of the "snapshot" and concurrent marking will trace the sub-graph that >> is reachable from this previous value. >> >> Unfortunately, in the presence of Reference objects, SATB might not be >> sufficient to mark a referent object as live. Consider that, at the >> start of marking, we have a weakly reachable object i.e. an object >> where the only pointer to that object. If the referent is obtained >> from the Reference object and stored to another object's field (making >> the referent now strongly reachable and hence live) the G1 write >> barrier will record the field's previous value but not the value of >> the referent. >> >> If the referent object is strongly reachable from some other object >> that will be traced by concurrent marking, _or_ there is a subsequent >> assignment to the field where we have written the referent (in which >> case we record the previous value - the referent - in an SATB buffer) >> then the referent will be marked live. Otherwise the referent will not >> be marked. >> >> That is the issue that was causing the failure in this CR. There was a >> Logger object that was only reachable through a WeakReference at the >> start of concurrent marking. During marking the Logger object is >> obtained from the WeakReference and stored into a field of a live >> object. The G1 write barrier recorded the previous value in the field >> (as it is part of the snapshot at the start of marking). Since there >> was no other assignment to the live object's field and there was no >> other strong reference to the Logger object, the Logger object was not >> marked. At the end of concurrent marking the Logger object was >> considered dead and the link between the WeakReference and the Logger >> was severed by clearing the referent field during reference processing. >> >> To solve this (entirely in Hotspot and causing a performance overhead >> for G1 only) it was decided that the best approach was to intrinsify >> the Reference.get() method in the JIT compilers and add new >> interpreter entry points so that the value in the referent field will >> be recorded in an SATB buffer by the G1 pre-barrier code. >> >> The changes for Zero and the C++ interpreters are place holder >> routines but should be straight forward to implement. >> >> None of the individual changes is large - they are just well >> distributed around the JVM. :) >> >> Testing: white box test; eyeballing the generated compiled and >> interpreter code; the failing Kitchensink big-app on x86 (32/64 bit), >> sparc (32/64 bit), Xint, Xcomp (client and server), with and without >> G1; the GC test suite with and without G1; and jprt. >> >> Thanks and regards, >> >> JohnC > From john.cuthbertson at oracle.com Mon Mar 28 12:41:54 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 28 Mar 2011 12:41:54 -0700 Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error In-Reply-To: <4D90DCE6.3000804@oracle.com> References: <4D7ACDBA.7020003@oracle.com> <4D90C6E0.9000901@oracle.com> <4D90DCE6.3000804@oracle.com> Message-ID: <4D90E482.4050402@oracle.com> Hi Vladimir, On 03/28/11 12:09, Vladimir Kozlov wrote: > You need to regenerated webrev since callGenerator.hpp and > callGenerator.cpp are empty now. OK. I'll make the changes and re-generate > > unsafe.cpp: > + // We could be accessing the the referent field in a reference > ^ > Oops. > Why you are not using update_barrier_set_pre (as in > Unsafe_CompareAndSwapObject)? I didn't know it existed. I'll take a look and see if it's suitable. > > you left test outputs: > + tty->print_cr("####### Unsafe_GetObject: offset = " INTX_FORMAT, > offset); > tty->print_cr("####### Unsafe_GetObject: need a G1 barrier"); > Oops again. I thought I caught all of these. Thanks, JohnC From tom.rodriguez at oracle.com Mon Mar 28 13:00:24 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 28 Mar 2011 13:00:24 -0700 Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error In-Reply-To: <4D90C6E0.9000901@oracle.com> References: <4D7ACDBA.7020003@oracle.com> <4D90C6E0.9000901@oracle.com> Message-ID: <316080F8-7FC4-4CCA-AFE0-915E09FD1BDE@oracle.com> c1_LIRGenerator.cpp: you can't write the branches as you've done them. The register allocator only understands block based control flow and the special case of CodeStubs. It's a limitation of the LIR that unfortunately isn't checked for by any existing asserts. It will work until the allocator decides to place a spill in the middle of your control flow. So you either need to write the guard in the high level IR during parsing or you need to implement it in assembly in a stub on the side. You should also try to constant fold some of these tests by hand since the LIR won't do that for you and in 99.99% of the cases they won't be needed. library_call.cpp: Can you put in the some guards to skip the code generation in cases where it's obviously not needed? Otherwise we're generating a bunch of goo during parsing that we'll just have to optimize away. Something like: TypeX* otype = offset->find_intptr_t_type(); if (otype != NULL && otype->is_con() && otype->get_con() != java_lang_ref_Reference::_reference_offset) { // Constant offset but not the reference_offset so just return return; } TypeOopPtr* btype = base_oop->isa_oop_ptr(); if (btype != NULL && btype->isa_ary_ptr()) { // Array type so nothing to do return; } will filter most uses out completely. Testing for TypeInstPtr would be slightly more complicated though I think something like if (byte->isa_instr_ptr() && !byte->isa_inst_ptr()->klass->is_subtype_of(env()->Reference_klass()) && !env()->Reference_klass()->is_subtype_of(byte->isa_instptr()->klass()) { return; } would work. Actually I don't think you should be testing against reference_type since we can't statically optimize those checks. A regular instance of check can be optimized away if have good type information for the object. Other than the constant formation it's no more expensive than the check you wrote. tom On Mar 28, 2011, at 10:35 AM, John Cuthbertson wrote: > Hi Everyone, > > A new webrev with changes based upon comments from Tom can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.4/. > > The latest changes include inserting a suitably guarded barrier call in case the referent field of a Reference object is being read/fetched using JNI, reflection, or Unsafe. > > Thanks, > > JohnC > > On 3/11/2011 5:34 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> I'm looking for a few of volunteers to review the changes that fix this assertion failure. The latest changes can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.3/ and include changes based upon earlier internal reviews. The earlier changes are also on cr.openjdk.java.net for reference. >> >> Background: >> The G1 garbage collector includes a concurrent marking algorithm that makes use of snapshot-at-the-beginning or SATB. With this algorithm the GC will mark all objects that are reachable at the start of marking; objects that are allocated since the start of marking are implicitly considered live. In order to populate the "snapshot" of the object graph that existed at the start of marking, G1 employs a write barrier. When an object is stored into another object's field the write-barrier records the previous value of that field as it was part of the "snapshot" and concurrent marking will trace the sub-graph that is reachable from this previous value. >> >> Unfortunately, in the presence of Reference objects, SATB might not be sufficient to mark a referent object as live. Consider that, at the start of marking, we have a weakly reachable object i.e. an object where the only pointer to that object. If the referent is obtained from the Reference object and stored to another object's field (making the referent now strongly reachable and hence live) the G1 write barrier will record the field's previous value but not the value of the referent. >> >> If the referent object is strongly reachable from some other object that will be traced by concurrent marking, _or_ there is a subsequent assignment to the field where we have written the referent (in which case we record the previous value - the referent - in an SATB buffer) then the referent will be marked live. Otherwise the referent will not be marked. >> >> That is the issue that was causing the failure in this CR. There was a Logger object that was only reachable through a WeakReference at the start of concurrent marking. During marking the Logger object is obtained from the WeakReference and stored into a field of a live object. The G1 write barrier recorded the previous value in the field (as it is part of the snapshot at the start of marking). Since there was no other assignment to the live object's field and there was no other strong reference to the Logger object, the Logger object was not marked. At the end of concurrent marking the Logger object was considered dead and the link between the WeakReference and the Logger was severed by clearing the referent field during reference processing. >> >> To solve this (entirely in Hotspot and causing a performance overhead for G1 only) it was decided that the best approach was to intrinsify the Reference.get() method in the JIT compilers and add new interpreter entry points so that the value in the referent field will be recorded in an SATB buffer by the G1 pre-barrier code. >> >> The changes for Zero and the C++ interpreters are place holder routines but should be straight forward to implement. >> >> None of the individual changes is large - they are just well distributed around the JVM. :) >> >> Testing: white box test; eyeballing the generated compiled and interpreter code; the failing Kitchensink big-app on x86 (32/64 bit), sparc (32/64 bit), Xint, Xcomp (client and server), with and without G1; the GC test suite with and without G1; and jprt. >> >> Thanks and regards, >> >> JohnC > From tom.rodriguez at oracle.com Mon Mar 28 13:33:55 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 28 Mar 2011 13:33:55 -0700 Subject: review (XS) for 6478991: C1 NullCheckEliminator yields incorrect exceptions In-Reply-To: <20ED65E2-2BBC-45A4-9227-E56326C3052C@oracle.com> References: <2CB16D5E-3B3E-4791-B356-6DC5613DCF94@oracle.com> <20ED65E2-2BBC-45A4-9227-E56326C3052C@oracle.com> Message-ID: <1CA29B58-A538-4805-9DF0-A126AD2A1BDB@oracle.com> Oops. I'll fix that in another putback. It's also full of ^M which I will fix as well. Thanks. tom On Mar 28, 2011, at 1:41 AM, Christian Thalinger wrote: > On Mar 25, 2011, at 7:37 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6478991 >> >> 6478991: C1 NullCheckEliminator yields incorrect exceptions >> Reviewed-by: >> >> checkcast can trap so don't allow explicit null checks to be folded into >> instructions that follow it. Tested with new test case. > > The testcase misses the -Xcomp flag. > > -- Christian From vladimir.kozlov at oracle.com Mon Mar 28 17:06:34 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Mar 2011 17:06:34 -0700 Subject: Request for reviews (L): 7004535: Clone loop predicates when loop is cloned In-Reply-To: <4D8BF8FA.9030600@oracle.com> References: <4D8BF8FA.9030600@oracle.com> Message-ID: <4D91228A.5040409@oracle.com> I still need reviews for this. I merged with latest changes and added new method skip_loop_predicates() used in policy_do_remove_empty_loop(). http://cr.openjdk.java.net/~kvn/7004535/webrev.01 Thanks, Vladimir Vladimir Kozlov wrote: > Second loop opts changes. > > http://cr.openjdk.java.net/~kvn/7004535/webrev > > Fixed 7004535: Clone loop predicates when loop is cloned > > Currently loop predicates generated during parsing could be separated > from loops when loops are cloned. As result such predicates are removed. > There could be more optimization opportunities if loop predicates are > also cloned in such situations. > > Loop predicate code become big so I moved it into new file > loopPredicate.cpp. > > I separated the cloning code for IdealLoop and IterGVN. The generated Ideal > code is the same but registration of new Ideal nodes is different enough to > have separate methods, I think. I welcome any suggestions to improve > this code. > > Keep loop predicates after CCP and perform optimizations with them until > no more > loop optimizations could be done. After that switch them off and do more > loop > optimizations. > > VectorNode missed size_of() method as result it was cloned incorrectly. > > Added TraceLoopOpts outputs I missed in previous changes. > > Tested: ctw, nsk, jprt > From tom.rodriguez at oracle.com Mon Mar 28 23:20:46 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 28 Mar 2011 23:20:46 -0700 Subject: Request for reviews (L): 7004535: Clone loop predicates when loop is cloned In-Reply-To: <4D91228A.5040409@oracle.com> References: <4D8BF8FA.9030600@oracle.com> <4D91228A.5040409@oracle.com> Message-ID: ifnode.cpp: This appears to be unused. + bool counted_loop = r->is_CountedLoop(); loopUnswitch.cpp: ! // endif predicat [clone] Unused? + bool counted_loop = head->is_CountedLoop(); How does the code in loopPredicate.cpp compare to what was originally in loopTransform.cpp? Are there changes or is it a straight copy? tom On Mar 28, 2011, at 5:06 PM, Vladimir Kozlov wrote: > I still need reviews for this. I merged with latest changes and added new method skip_loop_predicates() used in policy_do_remove_empty_loop(). > > http://cr.openjdk.java.net/~kvn/7004535/webrev.01 > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> Second loop opts changes. >> http://cr.openjdk.java.net/~kvn/7004535/webrev >> Fixed 7004535: Clone loop predicates when loop is cloned >> Currently loop predicates generated during parsing could be separated from loops when loops are cloned. As result such predicates are removed. There could be more optimization opportunities if loop predicates are also cloned in such situations. >> Loop predicate code become big so I moved it into new file loopPredicate.cpp. >> I separated the cloning code for IdealLoop and IterGVN. The generated Ideal >> code is the same but registration of new Ideal nodes is different enough to >> have separate methods, I think. I welcome any suggestions to improve this code. >> Keep loop predicates after CCP and perform optimizations with them until no more >> loop optimizations could be done. After that switch them off and do more loop >> optimizations. >> VectorNode missed size_of() method as result it was cloned incorrectly. >> Added TraceLoopOpts outputs I missed in previous changes. >> Tested: ctw, nsk, jprt From MASLOWSC at cboe.com Tue Mar 29 05:53:21 2011 From: MASLOWSC at cboe.com (Maslowski, Chuck) Date: Tue, 29 Mar 2011 07:53:21 -0500 Subject: FW: your hotspot tools Message-ID: <77CD7119E037BE4C89E11C7FC6EC7DF60ACB3C7F@MSMAIL.cboent.cboe.com> Sent from my IPhone -----Original Message----- From: Maslowski, Chuck Sent: Monday, March 28, 2011 03:51 PM Central Standard Time To: 'tom.rodriguez at oracle.com' Subject: your hotspot tools Tom, Was reading through your articles on the Sun Wiki. In light of OpenJDK 7 Build 135 / HS 21, are there any updates to your posted LogCompilation analyzer or articles ? We need to get a rather detailed analysis going for our application server process, to figure out why / why not certain methods are not compiled, and why uncommon traps are hit We also know what methods eventually get compiled when the standard usage thresholds are hit Question ? Is there a way to ?force? compilation of specific methods at VM initialization time? This would be in the context of a ?product? build. Thank you, Chuck Maslowski CBOE Reference: http://wikis.sun.com/display/HotSpotInternals/LogCompilation+tool http://wikis.sun.com/display/HotSpotInternals/LogCompilation+overview -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110329/c71e7d14/attachment.html From vladimir.kozlov at oracle.com Tue Mar 29 09:33:33 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Mar 2011 09:33:33 -0700 Subject: Request for reviews (L): 7004535: Clone loop predicates when loop is cloned In-Reply-To: References: <4D8BF8FA.9030600@oracle.com> <4D91228A.5040409@oracle.com> Message-ID: <4D9209DD.3040007@oracle.com> Thank you, Tom Tom Rodriguez wrote: > ifnode.cpp: > This appears to be unused. > + bool counted_loop = r->is_CountedLoop(); Remoived. > loopUnswitch.cpp: > ! // endif predicat [clone] Fixed. > Unused? > + bool counted_loop = head->is_CountedLoop(); Remoived. > > How does the code in loopPredicate.cpp compare to what was originally in loopTransform.cpp? Are there changes or is it a straight copy? No, I added a lot to do cloning. Here are diffs vs loopTransform.cpp: http://cr.openjdk.java.net/~kvn/7004535_1/webrev/ Vladimir > > tom > > > On Mar 28, 2011, at 5:06 PM, Vladimir Kozlov wrote: > >> I still need reviews for this. I merged with latest changes and added new method skip_loop_predicates() used in policy_do_remove_empty_loop(). >> >> http://cr.openjdk.java.net/~kvn/7004535/webrev.01 >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> Second loop opts changes. >>> http://cr.openjdk.java.net/~kvn/7004535/webrev >>> Fixed 7004535: Clone loop predicates when loop is cloned >>> Currently loop predicates generated during parsing could be separated from loops when loops are cloned. As result such predicates are removed. There could be more optimization opportunities if loop predicates are also cloned in such situations. >>> Loop predicate code become big so I moved it into new file loopPredicate.cpp. >>> I separated the cloning code for IdealLoop and IterGVN. The generated Ideal >>> code is the same but registration of new Ideal nodes is different enough to >>> have separate methods, I think. I welcome any suggestions to improve this code. >>> Keep loop predicates after CCP and perform optimizations with them until no more >>> loop optimizations could be done. After that switch them off and do more loop >>> optimizations. >>> VectorNode missed size_of() method as result it was cloned incorrectly. >>> Added TraceLoopOpts outputs I missed in previous changes. >>> Tested: ctw, nsk, jprt > From vladimir.kozlov at oracle.com Tue Mar 29 11:23:59 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 29 Mar 2011 18:23:59 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7032133: Enable sse4.2 for new AMD processors Message-ID: <20110329182405.3113847586@hg.openjdk.java.net> Changeset: a988a7bb3b8a Author: kvn Date: 2011-03-29 09:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a988a7bb3b8a 7032133: Enable sse4.2 for new AMD processors Summary: New AMD processors support sse4.2. Enable corresponding instructions in Hotspot. Reviewed-by: kvn Contributed-by: eric.caspole at amd.com ! src/cpu/x86/vm/vm_version_x86.cpp From igor.veresov at oracle.com Tue Mar 29 11:35:35 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 29 Mar 2011 11:35:35 -0700 Subject: review(XS) 6741940: Nonvolatile XMM registers not preserved across JNI calls Message-ID: <4D922677.4040906@oracle.com> We need to preserve xmm6-xmm15 to comply with win64 ABI when doing C->Java calls. Webrev: http://cr.openjdk.java.net/~iveresov/6741940/webrev.00/ Thanks, igor From vladimir.kozlov at oracle.com Tue Mar 29 15:07:14 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Mar 2011 15:07:14 -0700 Subject: Request for reviews (M): 7029152: Ideal nodes for String intrinsics miss memory edge optimization Message-ID: <4D925812.4030204@oracle.com> Second loop opts changes. http://cr.openjdk.java.net/~kvn/7029152 Fixed 7029152: Ideal nodes for String intrinsics miss memory edge optimization Superword optimization assumes that only Load nodes in loop or MergeMem outside of loop could reference Store nodes. In bug case the loop has MergeMem nodes used by StrIndexOf nodes which cause the failure: # assert(out == prev || prev == NULL) failed: no branches off of store slice) Added base class StrIntrinsicNode for String intrinsics nodes. In Ideal() method look for TypeAryPtr::CHARS memory slice if memory is MergeMem. Do not unroll a loop with String intrinsics code. String intrinsics are large and have loops. Added regression test. From igor.veresov at oracle.com Tue Mar 29 19:38:53 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 30 Mar 2011 02:38:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6741940: Nonvolatile XMM registers not preserved across JNI calls Message-ID: <20110330023900.6D9EE475B8@hg.openjdk.java.net> Changeset: b1c22848507b Author: iveresov Date: 2011-03-29 17:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b1c22848507b 6741940: Nonvolatile XMM registers not preserved across JNI calls Summary: Save xmm6-xmm15 in call stub on win64 Reviewed-by: kvn, never ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp From igor.veresov at oracle.com Tue Mar 29 21:49:54 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 29 Mar 2011 21:49:54 -0700 Subject: review(XXS): 7026307: DEBUG MESSAGE: broken null klass on amd64 Message-ID: <4D92B672.7070903@oracle.com> I made a copy-paste error while refactoring for 7020521, in stubGenerator_x86_64.cpp: address generate_generic_copy(const char *name, address byte_copy_entry, address short_copy_entry, address int_copy_entry, address long_copy_entry, address oop_copy_entry, address checkcast_copy_entry) The order of arguments is wrong, entry_oop_arraycopy and entry_jlong_arraycopy should be swapped like on other architectures. With compressed oops this would cause stomping, among other things, which was caught in nighlies. Webrev: http://cr.openjdk.java.net/~iveresov/7026307/webrev.00/ Testing: Failing nightly test. Thanks, igor From tom.rodriguez at oracle.com Tue Mar 29 22:01:27 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 29 Mar 2011 22:01:27 -0700 Subject: review(XXS): 7026307: DEBUG MESSAGE: broken null klass on amd64 In-Reply-To: <4D92B672.7070903@oracle.com> References: <4D92B672.7070903@oracle.com> Message-ID: <81D443F3-B569-497F-AD90-61EFF7DB90E8@oracle.com> Looks good. tom On Mar 29, 2011, at 9:49 PM, Igor Veresov wrote: > I made a copy-paste error while refactoring for 7020521, in stubGenerator_x86_64.cpp: > address generate_generic_copy(const char *name, > address byte_copy_entry, address short_copy_entry, > address int_copy_entry, address long_copy_entry, > address oop_copy_entry, address checkcast_copy_entry) > > The order of arguments is wrong, entry_oop_arraycopy and entry_jlong_arraycopy should be swapped like on other architectures. With compressed oops this would cause stomping, among other things, which was caught in nighlies. > > Webrev: http://cr.openjdk.java.net/~iveresov/7026307/webrev.00/ > > Testing: Failing nightly test. > > > Thanks, > igor From vladimir.kozlov at oracle.com Tue Mar 29 22:20:56 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Mar 2011 22:20:56 -0700 Subject: review(XXS): 7026307: DEBUG MESSAGE: broken null klass on amd64 In-Reply-To: <4D92B672.7070903@oracle.com> References: <4D92B672.7070903@oracle.com> Message-ID: <4D92BDB8.3040406@oracle.com> Good. Vladimir On 3/29/11 9:49 PM, Igor Veresov wrote: > I made a copy-paste error while refactoring for 7020521, in stubGenerator_x86_64.cpp: > address generate_generic_copy(const char *name, > address byte_copy_entry, address short_copy_entry, > address int_copy_entry, address long_copy_entry, > address oop_copy_entry, address checkcast_copy_entry) > > The order of arguments is wrong, entry_oop_arraycopy and entry_jlong_arraycopy should be swapped like on other > architectures. With compressed oops this would cause stomping, among other things, which was caught in nighlies. > > Webrev: http://cr.openjdk.java.net/~iveresov/7026307/webrev.00/ > > Testing: Failing nightly test. > > > Thanks, > igor From igor.veresov at oracle.com Tue Mar 29 22:21:16 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 29 Mar 2011 22:21:16 -0700 Subject: review(XXS): 7026307: DEBUG MESSAGE: broken null klass on amd64 In-Reply-To: <4D92BDB8.3040406@oracle.com> References: <4D92B672.7070903@oracle.com> <4D92BDB8.3040406@oracle.com> Message-ID: <4D92BDCC.1090808@oracle.com> Thanks Tom and Vladimir! igor On 3/29/11 10:20 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 3/29/11 9:49 PM, Igor Veresov wrote: >> I made a copy-paste error while refactoring for 7020521, in >> stubGenerator_x86_64.cpp: >> address generate_generic_copy(const char *name, >> address byte_copy_entry, address short_copy_entry, >> address int_copy_entry, address long_copy_entry, >> address oop_copy_entry, address checkcast_copy_entry) >> >> The order of arguments is wrong, entry_oop_arraycopy and >> entry_jlong_arraycopy should be swapped like on other >> architectures. With compressed oops this would cause stomping, among >> other things, which was caught in nighlies. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/7026307/webrev.00/ >> >> Testing: Failing nightly test. >> >> >> Thanks, >> igor From igor.veresov at oracle.com Tue Mar 29 22:46:36 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 29 Mar 2011 22:46:36 -0700 Subject: review(XXS): 7026307: DEBUG MESSAGE: broken null klass on amd64 In-Reply-To: <4D92BDB8.3040406@oracle.com> References: <4D92B672.7070903@oracle.com> <4D92BDB8.3040406@oracle.com> Message-ID: <4D92C3BC.90307@oracle.com> Thanks Tom and Vladimir! igor On 3/29/11 10:20 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 3/29/11 9:49 PM, Igor Veresov wrote: >> I made a copy-paste error while refactoring for 7020521, in >> stubGenerator_x86_64.cpp: >> address generate_generic_copy(const char *name, >> address byte_copy_entry, address short_copy_entry, >> address int_copy_entry, address long_copy_entry, >> address oop_copy_entry, address checkcast_copy_entry) >> >> The order of arguments is wrong, entry_oop_arraycopy and >> entry_jlong_arraycopy should be swapped like on other >> architectures. With compressed oops this would cause stomping, among >> other things, which was caught in nighlies. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/7026307/webrev.00/ >> >> Testing: Failing nightly test. >> >> >> Thanks, >> igor From tom.rodriguez at oracle.com Wed Mar 30 03:45:57 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 30 Mar 2011 10:45:57 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7032306: Fastdebug build failure on Solaris with SS11 compilers Message-ID: <20110330104604.C58E047622@hg.openjdk.java.net> Changeset: 2cd0180da6e1 Author: never Date: 2011-03-29 22:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2cd0180da6e1 7032306: Fastdebug build failure on Solaris with SS11 compilers Reviewed-by: kvn, iveresov ! src/share/vm/oops/instanceKlass.cpp From gbenson at redhat.com Wed Mar 30 03:52:02 2011 From: gbenson at redhat.com (Gary Benson) Date: Wed, 30 Mar 2011 11:52:02 +0100 Subject: Review Request: Zero and Shark fixes Message-ID: <20110330105202.GB8648@redhat.com> Hi all, This webrev contains a bunch of fixes for Zero and Shark: http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ Firstly, changes to tiered compilation required fixes to allow Shark to build. Secondly, my fix for 7030207 uncovered a bug in the C++ interpreter where finalizers were not being registered. I can split the webrev into two if you'd like. I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From gnu_andrew at member.fsf.org Wed Mar 30 04:03:49 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Wed, 30 Mar 2011 12:03:49 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110330105202.GB8648@redhat.com> References: <20110330105202.GB8648@redhat.com> Message-ID: On 30 March 2011 11:52, Gary Benson wrote: > Hi all, > > This webrev contains a bunch of fixes for Zero and Shark: > > ?http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ > > Firstly, changes to tiered compilation required fixes to allow > Shark to build. This change was added to IcedTea6 prior to 1.10 as the bug is present in hs20. I'm surprised you've only just hit it. > Secondly, my fix for 7030207 uncovered a bug in > the C++ interpreter where finalizers were not being registered. > I can split the webrev into two if you'd like. > There seem to also be copyright changes here too, and the STDC_LIMIT_MACROS also in IcedTea. I'd prefer all of these weren't bundled together in one changeset. > I don't have a bug id for this. > > 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 the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From christian.thalinger at oracle.com Wed Mar 30 04:16:50 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Mar 2011 13:16:50 +0200 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110330105202.GB8648@redhat.com> References: <20110330105202.GB8648@redhat.com> Message-ID: <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> On Mar 30, 2011, at 12:52 PM, Gary Benson wrote: > Hi all, > > This webrev contains a bunch of fixes for Zero and Shark: > > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ > > Firstly, changes to tiered compilation required fixes to allow > Shark to build. Secondly, my fix for 7030207 uncovered a bug in > the C++ interpreter where finalizers were not being registered. > I can split the webrev into two if you'd like. hotspot/src/share/vm/compiler/compileBroker.cpp: - if (compiler(comp_level)->is_c2()) { + if (compiler(comp_level)->is_c2() || compiler(comp_level)->is_c2()) { That seems to be a typo or leftover. -- Christian From gbenson at redhat.com Wed Mar 30 04:51:26 2011 From: gbenson at redhat.com (Gary Benson) Date: Wed, 30 Mar 2011 12:51:26 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> Message-ID: <20110330115126.GC8648@redhat.com> Christian Thalinger wrote: > On Mar 30, 2011, at 12:52 PM, Gary Benson wrote: > > This webrev contains a bunch of fixes for Zero and Shark: > > > > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ > > > > Firstly, changes to tiered compilation required fixes to allow > > Shark to build. Secondly, my fix for 7030207 uncovered a bug in > > the C++ interpreter where finalizers were not being registered. > > I can split the webrev into two if you'd like. > > hotspot/src/share/vm/compiler/compileBroker.cpp: > > - if (compiler(comp_level)->is_c2()) { > + if (compiler(comp_level)->is_c2() || compiler(comp_level)->is_c2()) { > > That seems to be a typo or leftover. Ah, well spotted, the second should be is_shark. Would you like me to remake the webrev? Cheers, Gary -- http://gbenson.net/ From gnu_andrew at member.fsf.org Wed Mar 30 05:24:11 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Wed, 30 Mar 2011 13:24:11 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110330115126.GC8648@redhat.com> References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> Message-ID: On 30 March 2011 12:51, Gary Benson wrote: > Christian Thalinger wrote: >> On Mar 30, 2011, at 12:52 PM, Gary Benson wrote: >> > This webrev contains a bunch of fixes for Zero and Shark: >> > >> > ?http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ >> > >> > Firstly, changes to tiered compilation required fixes to allow >> > Shark to build. ?Secondly, my fix for 7030207 uncovered a bug in >> > the C++ interpreter where finalizers were not being registered. >> > I can split the webrev into two if you'd like. >> >> hotspot/src/share/vm/compiler/compileBroker.cpp: >> >> - ?if (compiler(comp_level)->is_c2()) { >> + ?if (compiler(comp_level)->is_c2() || compiler(comp_level)->is_c2()) { >> >> That seems to be a typo or leftover. > > Ah, well spotted, the second should be is_shark. > > Would you like me to remake the webrev? > Yes, please also split this up so it's easier to backport. > 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 the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From gbenson at redhat.com Wed Mar 30 05:35:31 2011 From: gbenson at redhat.com (Gary Benson) Date: Wed, 30 Mar 2011 13:35:31 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> Message-ID: <20110330123530.GD8648@redhat.com> Dr Andrew John Hughes wrote: > On 30 March 2011 12:51, Gary Benson wrote: > > Christian Thalinger wrote: > > > On Mar 30, 2011, at 12:52 PM, Gary Benson wrote: > > > > This webrev contains a bunch of fixes for Zero and Shark: > > > > > > > > ?http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ > > > > > > > > Firstly, changes to tiered compilation required fixes to allow > > > > Shark to build. ?Secondly, my fix for 7030207 uncovered a bug > > > > in the C++ interpreter where finalizers were not being > > > > registered. I can split the webrev into two if you'd like. > > > > > > hotspot/src/share/vm/compiler/compileBroker.cpp: > > > > > > - ?if (compiler(comp_level)->is_c2()) { > > > + ?if (compiler(comp_level)->is_c2() || compiler(comp_level)->is_c2()) { > > > > > > That seems to be a typo or leftover. > > > > Ah, well spotted, the second should be is_shark. > > > > Would you like me to remake the webrev? > > Yes, please also split this up so it's easier to backport. Whether I split it is up to twisti. I don't want to jam their testing thing all afternoon with six tiny patches... Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Wed Mar 30 05:45:37 2011 From: gbenson at redhat.com (Gary Benson) Date: Wed, 30 Mar 2011 13:45:37 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20110330105202.GB8648@redhat.com> Message-ID: <20110330124537.GE8648@redhat.com> Dr Andrew John Hughes wrote: > On 30 March 2011 11:52, Gary Benson wrote: > > This webrev contains a bunch of fixes for Zero and Shark: > > > > ?http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ > > > > Firstly, changes to tiered compilation required fixes to allow > > Shark to build. > > This change was added to IcedTea6 prior to 1.10 as the bug is > present in hs20. I'm surprised you've only just hit it. I'm not 100% sure which individual changeset broke things, so I can't say. Maybe nobody built Shark for a while? > > Secondly, my fix for 7030207 uncovered a bug in the C++ > > interpreter where finalizers were not being registered. > > I can split the webrev into two if you'd like. > > There seem to also be copyright changes here too... Yes, I updated the copyright years on the files I changed. > ...and the STDC_LIMIT_MACROS also in IcedTea. Why wasn't it upstreamed? Cheers, Gary -- http://gbenson.net/ From igor.veresov at oracle.com Wed Mar 30 05:46:32 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 30 Mar 2011 12:46:32 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110330124636.5D08B47627@hg.openjdk.java.net> Changeset: 348c0df561a9 Author: iveresov Date: 2011-03-29 22:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/348c0df561a9 7026307: DEBUG MESSAGE: broken null klass on amd64 Summary: Correct typo introduces in 7020521 Reviewed-by: never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: fe1dbd98e18f Author: iveresov Date: 2011-03-30 03:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fe1dbd98e18f Merge From christian.thalinger at oracle.com Wed Mar 30 05:46:37 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Mar 2011 14:46:37 +0200 Subject: Request for review (S): 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 Message-ID: <0B6ADFC2-6DEC-4BFC-994E-EFB1F1B04D0B@oracle.com> http://cr.openjdk.java.net/~twisti/7032388/ 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 Summary: 6919934 added some unguarded cmov instructions which hit a guarantee on older hardware. Reviewed-by: 6919934 added some unguarded cmov instructions which hit a guarantee on older hardware (pre-i686). The fix is to either guard the added cmov instructions with a supports_cmov() or let the cmov instruction decide itself if the hardware supports cmov and if not use a branch-mov idiom. I chose the latter. src/cpu/x86/vm/assembler_x86.cpp src/cpu/x86/vm/assembler_x86.hpp src/cpu/x86/vm/c1_LIRAssembler_x86.cpp src/cpu/x86/vm/c1_Runtime1_x86.cpp src/cpu/x86/vm/templateTable_x86_32.cpp From christian.thalinger at oracle.com Wed Mar 30 05:48:51 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Mar 2011 14:48:51 +0200 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110330115126.GC8648@redhat.com> References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> Message-ID: On Mar 30, 2011, at 1:51 PM, Gary Benson wrote: > Christian Thalinger wrote: >> On Mar 30, 2011, at 12:52 PM, Gary Benson wrote: >>> This webrev contains a bunch of fixes for Zero and Shark: >>> >>> http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ >>> >>> Firstly, changes to tiered compilation required fixes to allow >>> Shark to build. Secondly, my fix for 7030207 uncovered a bug in >>> the C++ interpreter where finalizers were not being registered. >>> I can split the webrev into two if you'd like. >> >> hotspot/src/share/vm/compiler/compileBroker.cpp: >> >> - if (compiler(comp_level)->is_c2()) { >> + if (compiler(comp_level)->is_c2() || compiler(comp_level)->is_c2()) { >> >> That seems to be a typo or leftover. > > Ah, well spotted, the second should be is_shark. > > Would you like me to remake the webrev? No, it's okay. -- Christian From gbenson at redhat.com Wed Mar 30 05:51:23 2011 From: gbenson at redhat.com (Gary Benson) Date: Wed, 30 Mar 2011 13:51:23 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> Message-ID: <20110330125123.GF8648@redhat.com> Christian Thalinger wrote: > On Mar 30, 2011, at 1:51 PM, Gary Benson wrote: > > Christian Thalinger wrote: > > > On Mar 30, 2011, at 12:52 PM, Gary Benson wrote: > > > > This webrev contains a bunch of fixes for Zero and Shark: > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ > > > > > > > > Firstly, changes to tiered compilation required fixes to allow > > > > Shark to build. Secondly, my fix for 7030207 uncovered a bug > > > > in the C++ interpreter where finalizers were not being > > > > registered. I can split the webrev into two if you'd like. > > > > > > hotspot/src/share/vm/compiler/compileBroker.cpp: > > > > > > - if (compiler(comp_level)->is_c2()) { > > > + if (compiler(comp_level)->is_c2() || compiler(comp_level)->is_c2()) { > > > > > > That seems to be a typo or leftover. > > > > Ah, well spotted, the second should be is_shark. > > > > Would you like me to remake the webrev? > > No, it's okay. -- Christian Awesome, thanks. Cheers, Gary -- http://gbenson.net/ From christian.thalinger at oracle.com Wed Mar 30 06:29:15 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Mar 2011 15:29:15 +0200 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110330125123.GF8648@redhat.com> References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> <20110330125123.GF8648@redhat.com> Message-ID: <52EAE38E-8104-42D0-89C4-848F4C7CEFDA@oracle.com> On Mar 30, 2011, at 2:51 PM, Gary Benson wrote: > Christian Thalinger wrote: >> On Mar 30, 2011, at 1:51 PM, Gary Benson wrote: >>> Christian Thalinger wrote: >>>> On Mar 30, 2011, at 12:52 PM, Gary Benson wrote: >>>>> This webrev contains a bunch of fixes for Zero and Shark: >>>>> >>>>> http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ >>>>> >>>>> Firstly, changes to tiered compilation required fixes to allow >>>>> Shark to build. Secondly, my fix for 7030207 uncovered a bug >>>>> in the C++ interpreter where finalizers were not being >>>>> registered. I can split the webrev into two if you'd like. >>>> >>>> hotspot/src/share/vm/compiler/compileBroker.cpp: >>>> >>>> - if (compiler(comp_level)->is_c2()) { >>>> + if (compiler(comp_level)->is_c2() || compiler(comp_level)->is_c2()) { >>>> >>>> That seems to be a typo or leftover. >>> >>> Ah, well spotted, the second should be is_shark. >>> >>> Would you like me to remake the webrev? >> >> No, it's okay. -- Christian > > Awesome, thanks. 7032458: Zero and Shark fixes -- Christian From gnu_andrew at member.fsf.org Wed Mar 30 07:11:08 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Wed, 30 Mar 2011 15:11:08 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110330123530.GD8648@redhat.com> References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> Message-ID: On 30 March 2011 13:35, Gary Benson wrote: > Dr Andrew John Hughes wrote: >> On 30 March 2011 12:51, Gary Benson wrote: >> > Christian Thalinger wrote: >> > > On Mar 30, 2011, at 12:52 PM, Gary Benson wrote: >> > > > This webrev contains a bunch of fixes for Zero and Shark: >> > > > >> > > > ?http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ >> > > > >> > > > Firstly, changes to tiered compilation required fixes to allow >> > > > Shark to build. ?Secondly, my fix for 7030207 uncovered a bug >> > > > in the C++ interpreter where finalizers were not being >> > > > registered. ?I can split the webrev into two if you'd like. >> > > >> > > hotspot/src/share/vm/compiler/compileBroker.cpp: >> > > >> > > - ?if (compiler(comp_level)->is_c2()) { >> > > + ?if (compiler(comp_level)->is_c2() || compiler(comp_level)->is_c2()) { >> > > >> > > That seems to be a typo or leftover. >> > >> > Ah, well spotted, the second should be is_shark. >> > >> > Would you like me to remake the webrev? >> >> Yes, please also split this up so it's easier to backport. > > Whether I split it is up to twisti. ?I don't want to jam their > testing thing all afternoon with six tiny patches... > Sorry, I was under the impression this was a Free Software project with equal input from everybody. It would have helped backporting to OpenJDK6 to have this split, but now we'll have to do this again from scratch. > 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 the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From christian.thalinger at oracle.com Wed Mar 30 07:21:00 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Mar 2011 16:21:00 +0200 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> Message-ID: <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> On Mar 30, 2011, at 4:11 PM, Dr Andrew John Hughes wrote: > On 30 March 2011 13:35, Gary Benson wrote: >> Dr Andrew John Hughes wrote: >>> On 30 March 2011 12:51, Gary Benson wrote: >>>> Christian Thalinger wrote: >>>>> On Mar 30, 2011, at 12:52 PM, Gary Benson wrote: >>>>>> This webrev contains a bunch of fixes for Zero and Shark: >>>>>> >>>>>> http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ >>>>>> >>>>>> Firstly, changes to tiered compilation required fixes to allow >>>>>> Shark to build. Secondly, my fix for 7030207 uncovered a bug >>>>>> in the C++ interpreter where finalizers were not being >>>>>> registered. I can split the webrev into two if you'd like. >>>>> >>>>> hotspot/src/share/vm/compiler/compileBroker.cpp: >>>>> >>>>> - if (compiler(comp_level)->is_c2()) { >>>>> + if (compiler(comp_level)->is_c2() || compiler(comp_level)->is_c2()) { >>>>> >>>>> That seems to be a typo or leftover. >>>> >>>> Ah, well spotted, the second should be is_shark. >>>> >>>> Would you like me to remake the webrev? >>> >>> Yes, please also split this up so it's easier to backport. >> >> Whether I split it is up to twisti. I don't want to jam their >> testing thing all afternoon with six tiny patches... >> > > Sorry, I was under the impression this was a Free Software project > with equal input from everybody. > It would have helped backporting to OpenJDK6 to have this split, but > now we'll have to do this again from scratch. Nothing's pushed yet so we still can talk about and change it. What exactly do you want to split? -- Christian From gnu_andrew at member.fsf.org Wed Mar 30 07:28:57 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Wed, 30 Mar 2011 15:28:57 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110330124537.GE8648@redhat.com> References: <20110330105202.GB8648@redhat.com> <20110330124537.GE8648@redhat.com> Message-ID: On 30 March 2011 13:45, Gary Benson wrote: > Dr Andrew John Hughes wrote: >> On 30 March 2011 11:52, Gary Benson wrote: >> > This webrev contains a bunch of fixes for Zero and Shark: >> > >> > ?http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04/ >> > >> > Firstly, changes to tiered compilation required fixes to allow >> > Shark to build. >> >> This change was added to IcedTea6 prior to 1.10 as the bug is >> present in hs20. ?I'm surprised you've only just hit it. > > I'm not 100% sure which individual changeset broke things, so > I can't say. ?Maybe nobody built Shark for a while? > We hit it as soon as the hs20 stable tree became available and was used in IcedTea6. I mentioned it to you on IRC at the time, but you showed no intention of fixing it. So I ended up doing it. I thought you were working directly on OpenJDK7 now and thus would have caught it much earlier. The changeset is: changeset: 1932:f95d63e2154a user: stefank date: Tue Nov 23 13:22:55 2010 -0800 summary: 6989984: Use standard include model for Hospot and it's a simple mistake. This line: +CORE_PATHS := $(shell find $(GAMMADIR)/src/share/vm/* -type d \! \( -name adlc -o -name c1 -o -name gc_implementation -o -name opto -o -name shark -o -name libadt \)) filters shark material out of CORE_PATHS, but none of the lines below add it back in. So the files are never compiled. >> > Secondly, my fix for 7030207 uncovered a bug in the C++ >> > interpreter where finalizers were not being registered. >> > I can split the webrev into two if you'd like. >> >> There seem to also be copyright changes here too... > > Yes, I updated the copyright years on the files I changed. > Ok, I thought there were some files with only copyright changes but, on second reading, there does appear to be single line code changes there too. >> ...and the STDC_LIMIT_MACROS also in IcedTea. > > Why wasn't it upstreamed? Both were on my list to do, but I don't have infinite time. IcedTea6 takes priority over OpenJDK7 which won't be released for at least another six months. That's not to mean that no-one else could have upstreamed the changes. I seem to be pretty much the only person who bothers to most of the time. > > 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 the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From gnu_andrew at member.fsf.org Wed Mar 30 07:38:54 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Wed, 30 Mar 2011 15:38:54 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> Message-ID: On 30 March 2011 15:21, Christian Thalinger wrote: > Nothing's pushed yet so we still can talk about and change it. ?What exactly do you want to split? > > -- Christian Thanks. From the webrev, there seem to be at least three changes: 1. Makefile changes which make sure the Shark files are once again compiled (and which I believe would need to be reviewed by Kelly anyway) 2. The trivial #ifndef addition which fixes a regression introduced by the recent HotSpot security fix. 3. The fix for the bug Gary mentioned which appears to mean API changes (I don't completely understand this bit). The first two have been tested in IcedTea6 and correspond to regressions introduced by identifiable changesets. I'm not sure of the impact of the third. The hs20 stable branch needs 1. but does not need 2. at present as it doesn't have the security fix to my knowledge. I'd prefer they were added separately, but I could live with 1 & 2 being combined, provided the security fix went into OpenJDK6 first. The build changes do need to be reviewed by Kelly: http://mail.openjdk.java.net/pipermail/build-dev/2011-February/004034.html so it would make sense to have 1 separate in that respect. I would definitely like to see 3 separated as it's new and (AFAIK) largely untested. Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From christian.thalinger at oracle.com Wed Mar 30 07:49:27 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Mar 2011 16:49:27 +0200 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> Message-ID: On Mar 30, 2011, at 4:38 PM, Dr Andrew John Hughes wrote: > On 30 March 2011 15:21, Christian Thalinger > wrote: > >> Nothing's pushed yet so we still can talk about and change it. What exactly do you want to split? >> >> -- Christian > > Thanks. From the webrev, there seem to be at least three changes: > > 1. Makefile changes which make sure the Shark files are once again > compiled (and which I believe would need to be reviewed by Kelly > anyway) > 2. The trivial #ifndef addition which fixes a regression introduced by > the recent HotSpot security fix. > 3. The fix for the bug Gary mentioned which appears to mean API > changes (I don't completely understand this bit). > > The first two have been tested in IcedTea6 and correspond to > regressions introduced by identifiable changesets. > I'm not sure of the impact of the third. > > The hs20 stable branch needs 1. but does not need 2. at present as it > doesn't have the security fix to my knowledge. > I'd prefer they were added separately, but I could live with 1 & 2 > being combined, provided the security fix went into OpenJDK6 first. > The build changes do need to be reviewed by Kelly: > http://mail.openjdk.java.net/pipermail/build-dev/2011-February/004034.html > so it would make sense to have 1 separate in that respect. > > I would definitely like to see 3 separated as it's new and (AFAIK) > largely untested. Alright, let's split the work :-) Andrew, can you take care of 1. and send it to build-dev? I take the rest of the patch (2. and 3.) and push it as the one CR I created. I don't think it makes much sense to have an extra CR for 2. Andrew, what change caused 2.? -- Christian From gbenson at redhat.com Wed Mar 30 07:55:24 2011 From: gbenson at redhat.com (Gary Benson) Date: Wed, 30 Mar 2011 15:55:24 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> Message-ID: <20110330145524.GG8648@redhat.com> Christian Thalinger wrote: > On Mar 30, 2011, at 4:38 PM, Dr Andrew John Hughes wrote: > > On 30 March 2011 15:21, Christian Thalinger > > wrote: > > > Nothing's pushed yet so we still can talk about and change it. > > > What exactly do you want to split? > > > > > > -- Christian > > > > Thanks. From the webrev, there seem to be at least three changes: > > > > 1. Makefile changes which make sure the Shark files are once again > > compiled (and which I believe would need to be reviewed by Kelly > > anyway) > > 2. The trivial #ifndef addition which fixes a regression > > introduced by the recent HotSpot security fix. > > 3. The fix for the bug Gary mentioned which appears to mean API > > changes (I don't completely understand this bit). > > > > The first two have been tested in IcedTea6 and correspond to > > regressions introduced by identifiable changesets. > > I'm not sure of the impact of the third. > > > > The hs20 stable branch needs 1. but does not need 2. at present > > as it doesn't have the security fix to my knowledge. > > I'd prefer they were added separately, but I could live with 1 & 2 > > being combined, provided the security fix went into OpenJDK6 first. > > The build changes do need to be reviewed by Kelly: > > http://mail.openjdk.java.net/pipermail/build-dev/2011-February/004034.html > > so it would make sense to have 1 separate in that respect. > > > > I would definitely like to see 3 separated as it's new and (AFAIK) > > largely untested. > > Alright, let's split the work :-) > > Andrew, can you take care of 1. and send it to build-dev? I take > the rest of the patch (2. and 3.) and push it as the one CR I > created. I don't think it makes much sense to have an extra CR for > 2. Would you like me to make new webrevs? Cheers, Gary -- http://gbenson.net/ From christian.thalinger at oracle.com Wed Mar 30 07:58:58 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Mar 2011 16:58:58 +0200 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110330145524.GG8648@redhat.com> References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> <20110330145524.GG8648@redhat.com> Message-ID: <5CD03827-E730-4CFB-A044-DA555167B10A@oracle.com> On Mar 30, 2011, at 4:55 PM, Gary Benson wrote: > Christian Thalinger wrote: >> On Mar 30, 2011, at 4:38 PM, Dr Andrew John Hughes wrote: >>> On 30 March 2011 15:21, Christian Thalinger >>> wrote: >>>> Nothing's pushed yet so we still can talk about and change it. >>>> What exactly do you want to split? >>>> >>>> -- Christian >>> >>> Thanks. From the webrev, there seem to be at least three changes: >>> >>> 1. Makefile changes which make sure the Shark files are once again >>> compiled (and which I believe would need to be reviewed by Kelly >>> anyway) >>> 2. The trivial #ifndef addition which fixes a regression >>> introduced by the recent HotSpot security fix. >>> 3. The fix for the bug Gary mentioned which appears to mean API >>> changes (I don't completely understand this bit). >>> >>> The first two have been tested in IcedTea6 and correspond to >>> regressions introduced by identifiable changesets. >>> I'm not sure of the impact of the third. >>> >>> The hs20 stable branch needs 1. but does not need 2. at present >>> as it doesn't have the security fix to my knowledge. >>> I'd prefer they were added separately, but I could live with 1 & 2 >>> being combined, provided the security fix went into OpenJDK6 first. >>> The build changes do need to be reviewed by Kelly: >>> http://mail.openjdk.java.net/pipermail/build-dev/2011-February/004034.html >>> so it would make sense to have 1 separate in that respect. >>> >>> I would definitely like to see 3 separated as it's new and (AFAIK) >>> largely untested. >> >> Alright, let's split the work :-) >> >> Andrew, can you take care of 1. and send it to build-dev? I take >> the rest of the patch (2. and 3.) and push it as the one CR I >> created. I don't think it makes much sense to have an extra CR for >> 2. > > Would you like me to make new webrevs? Yes, that would be good for the record and to put URL into the CR. -- Christian From tom.rodriguez at oracle.com Wed Mar 30 08:07:54 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 30 Mar 2011 08:07:54 -0700 Subject: Request for review (S): 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 In-Reply-To: <0B6ADFC2-6DEC-4BFC-994E-EFB1F1B04D0B@oracle.com> References: <0B6ADFC2-6DEC-4BFC-994E-EFB1F1B04D0B@oracle.com> Message-ID: <52D2C427-6320-4981-8014-7F8F0F859719@oracle.com> Looks good. tom On Mar 30, 2011, at 5:46 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7032388/ > > 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 > Summary: 6919934 added some unguarded cmov instructions which hit a guarantee on older hardware. > Reviewed-by: > > 6919934 added some unguarded cmov instructions which hit a guarantee > on older hardware (pre-i686). > > The fix is to either guard the added cmov instructions with a > supports_cmov() or let the cmov instruction decide itself if the > hardware supports cmov and if not use a branch-mov idiom. I chose the > latter. > > src/cpu/x86/vm/assembler_x86.cpp > src/cpu/x86/vm/assembler_x86.hpp > src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > src/cpu/x86/vm/c1_Runtime1_x86.cpp > src/cpu/x86/vm/templateTable_x86_32.cpp > From gbenson at redhat.com Wed Mar 30 08:16:17 2011 From: gbenson at redhat.com (Gary Benson) Date: Wed, 30 Mar 2011 16:16:17 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <5CD03827-E730-4CFB-A044-DA555167B10A@oracle.com> References: <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> <20110330145524.GG8648@redhat.com> <5CD03827-E730-4CFB-A044-DA555167B10A@oracle.com> Message-ID: <20110330151617.GH8648@redhat.com> Christian Thalinger wrote: > On Mar 30, 2011, at 4:55 PM, Gary Benson wrote: > > Christian Thalinger wrote: > > > Andrew, can you take care of 1. and send it to build-dev? > > > I take the rest of the patch (2. and 3.) and push it as > > > the one CR I created. I don't think it makes much sense > > > to have an extra CR for 2. > > > > Would you like me to make new webrevs? > > Yes, that would be good for the record and to put URL into > the CR. http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/ is the build fixes, for Andrew. http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-2/ is everything else, for you. Cheers, Gary -- http://gbenson.net/ From gnu_andrew at member.fsf.org Wed Mar 30 09:11:22 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Wed, 30 Mar 2011 17:11:22 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> Message-ID: On 30 March 2011 15:49, Christian Thalinger wrote: > On Mar 30, 2011, at 4:38 PM, Dr Andrew John Hughes wrote: >> On 30 March 2011 15:21, Christian Thalinger >> wrote: >> >>> Nothing's pushed yet so we still can talk about and change it. ?What exactly do you want to split? >>> >>> -- Christian >> >> Thanks. ?From the webrev, there seem to be at least three changes: >> >> 1. Makefile changes which make sure the Shark files are once again >> compiled (and which I believe would need to be reviewed by Kelly >> anyway) >> 2. The trivial #ifndef addition which fixes a regression introduced by >> the recent HotSpot security fix. >> 3. The fix for the bug Gary mentioned which appears to mean API >> changes (I don't completely understand this bit). >> >> The first two have been tested in IcedTea6 and correspond to >> regressions introduced by identifiable changesets. >> I'm not sure of the impact of the third. >> >> The hs20 stable branch needs 1. ?but does not need 2. at present as it >> doesn't have the security fix to my knowledge. >> I'd prefer they were added separately, but I could live with 1 & 2 >> being combined, provided the security fix went into OpenJDK6 first. >> The build changes do need to be reviewed by Kelly: >> http://mail.openjdk.java.net/pipermail/build-dev/2011-February/004034.html >> so it would make sense to have 1 separate in that respect. >> >> I would definitely like to see 3 separated as it's new and (AFAIK) >> largely untested. > > Alright, let's split the work :-) > > Andrew, can you take care of 1. and send it to build-dev? ?I take the rest of the patch (2. and 3.) and push it as the one CR I created. ?I don't think it makes much sense to have an extra CR for 2. > I'm happy to handle 1 (as I say, I was going to get around to it anyway). I would prefer 2 was as without it, Shark is currently broken in OpenJDK6. 1 won't be an issue until hs20 is imported into OpenJDK6. I don't know enough about 3, which is why I'm sceptical about including that in a fix for a current Shark build failure in OpenJDK6. So if you do combine them, I'll probably split them for 6 anyway, to be on the safe side. > Andrew, what change caused 2.? This one: changeset: 2002:a6f5011d46a9 parent: 1999:2c8e1acf0433 user: kamg date: Mon Jan 31 15:17:26 2011 -0500 summary: 6878713: Verifier heap corruption, relating to backward jsrs http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/a6f5011d46a9 due to: diff -r 2c8e1acf0433 -r a6f5011d46a9 src/share/vm/utilities/globalDefinitions_gcc.hpp --- a/src/share/vm/utilities/globalDefinitions_gcc.hpp Wed Jan 12 13:59:18 2011 -0800 +++ b/src/share/vm/utilities/globalDefinitions_gcc.hpp Mon Jan 31 15:17:26 2011 -0500 @@ -72,6 +72,7 @@ # endif #ifdef LINUX +#define __STDC_LIMIT_MACROS It was fixed by Mark Wielaard in IcedTea when the security fixes were added, but not upstreamed. > > -- Christian -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From gnu_andrew at member.fsf.org Wed Mar 30 09:30:12 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Wed, 30 Mar 2011 17:30:12 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110330151617.GH8648@redhat.com> References: <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> <20110330145524.GG8648@redhat.com> <5CD03827-E730-4CFB-A044-DA555167B10A@oracle.com> <20110330151617.GH8648@redhat.com> Message-ID: On 30 March 2011 16:16, Gary Benson wrote: > Christian Thalinger wrote: >> On Mar 30, 2011, at 4:55 PM, Gary Benson wrote: >> > Christian Thalinger wrote: >> > > Andrew, can you take care of 1. and send it to build-dev? >> > > I take the rest of the patch (2. and 3.) and push it as >> > > the one CR I created. ?I don't think it makes much sense >> > > to have an extra CR for 2. >> > >> > Would you like me to make new webrevs? >> >> Yes, that would be good for the record and to put URL into >> the CR. > > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/ > ?is the build fixes, for Andrew. > Thanks. http://mail.openjdk.java.net/pipermail/build-dev/2011-March/004369.html Assuming you came up with this change and didn't see the one in IcedTea, it's interesting that they are virtually identical. > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-2/ > ?is everything else, for you. > > 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 the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From tom.rodriguez at oracle.com Wed Mar 30 10:50:54 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 30 Mar 2011 10:50:54 -0700 Subject: Request for reviews (L): 7004535: Clone loop predicates when loop is cloned In-Reply-To: <4D9209DD.3040007@oracle.com> References: <4D8BF8FA.9030600@oracle.com> <4D91228A.5040409@oracle.com> <4D9209DD.3040007@oracle.com> Message-ID: <0C65D9C1-A571-481C-8E29-5EBC365C20CA@oracle.com> Why are the extra checks being removed? - if (out == NULL || out->is_Root() || out->is_Start()) return false; Are you just filtering those later along with other non Regions? Why not just use the ifdef ASSERT version all the time instead of having two copies? + #ifdef ASSERT + if (is_uncommon_trap_proj(other_proj, reason)) { + assert(reason == Deoptimization::Reason_none || + Compile::current()->is_predicate_opaq(iff->in(1)->in(1)), "should be on the list"); + return true; + } + return false; + #else return is_uncommon_trap_proj(other_proj, reason); + #endif Could you use a better variable name than "pj", maybe proj_index. Extra declaration of predicate. + Node* PhaseIdealLoop::skip_loop_predicates(Node* entry) { + Node* predicate = NULL; + if (UseLoopPredicate) { + Node* predicate = The rest looks fine. tom On Mar 29, 2011, at 9:33 AM, Vladimir Kozlov wrote: > Thank you, Tom > > Tom Rodriguez wrote: >> ifnode.cpp: >> This appears to be unused. >> + bool counted_loop = r->is_CountedLoop(); > > Remoived. > >> loopUnswitch.cpp: >> ! // endif predicat [clone] > > Fixed. > >> Unused? >> + bool counted_loop = head->is_CountedLoop(); > > Remoived. > >> How does the code in loopPredicate.cpp compare to what was originally in loopTransform.cpp? Are there changes or is it a straight copy? > > No, I added a lot to do cloning. Here are diffs vs loopTransform.cpp: > > http://cr.openjdk.java.net/~kvn/7004535_1/webrev/ > > Vladimir > >> tom >> On Mar 28, 2011, at 5:06 PM, Vladimir Kozlov wrote: >>> I still need reviews for this. I merged with latest changes and added new method skip_loop_predicates() used in policy_do_remove_empty_loop(). >>> >>> http://cr.openjdk.java.net/~kvn/7004535/webrev.01 >>> >>> Thanks, >>> Vladimir >>> >>> Vladimir Kozlov wrote: >>>> Second loop opts changes. >>>> http://cr.openjdk.java.net/~kvn/7004535/webrev >>>> Fixed 7004535: Clone loop predicates when loop is cloned >>>> Currently loop predicates generated during parsing could be separated from loops when loops are cloned. As result such predicates are removed. There could be more optimization opportunities if loop predicates are also cloned in such situations. >>>> Loop predicate code become big so I moved it into new file loopPredicate.cpp. >>>> I separated the cloning code for IdealLoop and IterGVN. The generated Ideal >>>> code is the same but registration of new Ideal nodes is different enough to >>>> have separate methods, I think. I welcome any suggestions to improve this code. >>>> Keep loop predicates after CCP and perform optimizations with them until no more >>>> loop optimizations could be done. After that switch them off and do more loop >>>> optimizations. >>>> VectorNode missed size_of() method as result it was cloned incorrectly. >>>> Added TraceLoopOpts outputs I missed in previous changes. >>>> Tested: ctw, nsk, jprt From vladimir.kozlov at oracle.com Wed Mar 30 11:09:55 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2011 11:09:55 -0700 Subject: Request for reviews (L): 7004535: Clone loop predicates when loop is cloned In-Reply-To: <0C65D9C1-A571-481C-8E29-5EBC365C20CA@oracle.com> References: <4D8BF8FA.9030600@oracle.com> <4D91228A.5040409@oracle.com> <4D9209DD.3040007@oracle.com> <0C65D9C1-A571-481C-8E29-5EBC365C20CA@oracle.com> Message-ID: <4D9371F3.9000909@oracle.com> Tom Rodriguez wrote: > Why are the extra checks being removed? > > - if (out == NULL || out->is_Root() || out->is_Start()) > return false; > > Are you just filtering those later along with other non Regions? Yes, I assume only regions are expected on the path to uncommon trap calls. So I replaced checks for Root and Start with check for Region below otherwise it does more scanning than needed in false case: + if (out->Opcode() != Op_Region) + return false; > > Why not just use the ifdef ASSERT version all the time instead of having two copies? OK. > > + #ifdef ASSERT > + if (is_uncommon_trap_proj(other_proj, reason)) { > + assert(reason == Deoptimization::Reason_none || > + Compile::current()->is_predicate_opaq(iff->in(1)->in(1)), "should be on the list"); > + return true; > + } > + return false; > + #else > return is_uncommon_trap_proj(other_proj, reason); > + #endif > > Could you use a better variable name than "pj", maybe proj_index. OK. > > Extra declaration of predicate. > > + Node* PhaseIdealLoop::skip_loop_predicates(Node* entry) { > + Node* predicate = NULL; > + if (UseLoopPredicate) { > + Node* predicate = Fixed. > > The rest looks fine. Thank you, Tom Vladimir > > tom > > On Mar 29, 2011, at 9:33 AM, Vladimir Kozlov wrote: > >> Thank you, Tom >> >> Tom Rodriguez wrote: >>> ifnode.cpp: >>> This appears to be unused. >>> + bool counted_loop = r->is_CountedLoop(); >> Remoived. >> >>> loopUnswitch.cpp: >>> ! // endif predicat [clone] >> Fixed. >> >>> Unused? >>> + bool counted_loop = head->is_CountedLoop(); >> Remoived. >> >>> How does the code in loopPredicate.cpp compare to what was originally in loopTransform.cpp? Are there changes or is it a straight copy? >> No, I added a lot to do cloning. Here are diffs vs loopTransform.cpp: >> >> http://cr.openjdk.java.net/~kvn/7004535_1/webrev/ >> >> Vladimir >> >>> tom >>> On Mar 28, 2011, at 5:06 PM, Vladimir Kozlov wrote: >>>> I still need reviews for this. I merged with latest changes and added new method skip_loop_predicates() used in policy_do_remove_empty_loop(). >>>> >>>> http://cr.openjdk.java.net/~kvn/7004535/webrev.01 >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Vladimir Kozlov wrote: >>>>> Second loop opts changes. >>>>> http://cr.openjdk.java.net/~kvn/7004535/webrev >>>>> Fixed 7004535: Clone loop predicates when loop is cloned >>>>> Currently loop predicates generated during parsing could be separated from loops when loops are cloned. As result such predicates are removed. There could be more optimization opportunities if loop predicates are also cloned in such situations. >>>>> Loop predicate code become big so I moved it into new file loopPredicate.cpp. >>>>> I separated the cloning code for IdealLoop and IterGVN. The generated Ideal >>>>> code is the same but registration of new Ideal nodes is different enough to >>>>> have separate methods, I think. I welcome any suggestions to improve this code. >>>>> Keep loop predicates after CCP and perform optimizations with them until no more >>>>> loop optimizations could be done. After that switch them off and do more loop >>>>> optimizations. >>>>> VectorNode missed size_of() method as result it was cloned incorrectly. >>>>> Added TraceLoopOpts outputs I missed in previous changes. >>>>> Tested: ctw, nsk, jprt > From igor.veresov at oracle.com Wed Mar 30 11:13:40 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Mar 2011 11:13:40 -0700 Subject: Request for review (S): 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 In-Reply-To: <0B6ADFC2-6DEC-4BFC-994E-EFB1F1B04D0B@oracle.com> References: <0B6ADFC2-6DEC-4BFC-994E-EFB1F1B04D0B@oracle.com> Message-ID: <4D9372D4.7060107@oracle.com> Looks good. igor On 3/30/11 5:46 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7032388/ > > 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 > Summary: 6919934 added some unguarded cmov instructions which hit a guarantee on older hardware. > Reviewed-by: > > 6919934 added some unguarded cmov instructions which hit a guarantee > on older hardware (pre-i686). > > The fix is to either guard the added cmov instructions with a > supports_cmov() or let the cmov instruction decide itself if the > hardware supports cmov and if not use a branch-mov idiom. I chose the > latter. > > src/cpu/x86/vm/assembler_x86.cpp > src/cpu/x86/vm/assembler_x86.hpp > src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > src/cpu/x86/vm/c1_Runtime1_x86.cpp > src/cpu/x86/vm/templateTable_x86_32.cpp > From vladimir.kozlov at oracle.com Wed Mar 30 11:30:16 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2011 11:30:16 -0700 Subject: Request for reviews (M): 7029152: Ideal nodes for String intrinsics miss memory edge optimization Message-ID: <4D9376B8.6040502@oracle.com> Sorry if you got 2 copies, I send it yesterday but did not get it back. So I resending it. http://cr.openjdk.java.net/~kvn/7029152 Fixed 7029152: Ideal nodes for String intrinsics miss memory edge optimization Superword optimization assumes that only Load nodes in loop or MergeMem outside of loop could reference Store nodes. In bug case the loop has MergeMem nodes used by StrIndexOf nodes which cause the failure: # assert(out == prev || prev == NULL) failed: no branches off of store slice) Added base class StrIntrinsicNode for String intrinsics nodes. In Ideal() method look for TypeAryPtr::CHARS memory slice if memory is MergeMem. Do not unroll a loop with String intrinsics code. String intrinsics are large and have loops. Added regression test. From christian.thalinger at oracle.com Wed Mar 30 11:30:52 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Mar 2011 20:30:52 +0200 Subject: Request for review (S): 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 In-Reply-To: <4D934F07.6060301@oracle.com> References: <0B6ADFC2-6DEC-4BFC-994E-EFB1F1B04D0B@oracle.com> <4D934F07.6060301@oracle.com> Message-ID: <88CC2B5C-7059-494C-9585-7CA81761BA3C@oracle.com> I made two small changes that Paul suggested since #ifdefs are bad and cmovptr makes more sense in the context. -- Christian On Mar 30, 2011, at 5:40 PM, Paul Hohensee wrote: > Couple of small comments. > > In assembler_x86.cpp, I'd removed the #ifdef _LP64 and have supports_cmov > be the condition that determines whether or not to emit the cmov. Every 64-bit > chip supports cmov, so supports_cmov will return true on every 64-bit platform. > > In templateTable_x86_32.cpp, you use cmov, which you've made an alias for > cmovptr in assembler_x86.hpp. I'd get use cmovptr directly here instead, > esp. since cmpptr is used just before it. > > Paul > > On 3/30/11 8:46 AM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7032388/ >> >> 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 >> Summary: 6919934 added some unguarded cmov instructions which hit a guarantee on older hardware. >> Reviewed-by: >> >> 6919934 added some unguarded cmov instructions which hit a guarantee >> on older hardware (pre-i686). >> >> The fix is to either guard the added cmov instructions with a >> supports_cmov() or let the cmov instruction decide itself if the >> hardware supports cmov and if not use a branch-mov idiom. I chose the >> latter. >> >> src/cpu/x86/vm/assembler_x86.cpp >> src/cpu/x86/vm/assembler_x86.hpp >> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >> src/cpu/x86/vm/c1_Runtime1_x86.cpp >> src/cpu/x86/vm/templateTable_x86_32.cpp From vladimir.kozlov at oracle.com Wed Mar 30 11:34:58 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2011 11:34:58 -0700 Subject: Request for reviews (M): 7032314: Allow to generate CallLeafNoFPNode in IdealKit Message-ID: <4D9377D2.9030403@oracle.com> http://cr.openjdk.java.net/~kvn/7032314/webrev Fixed 7032314: Allow to generate CallLeafNoFPNode in IdealKit Added CallLeafNoFPNode generation to IdealKit. Added i_o synchronization. Consolidated synchronization code for IdealKit and graphKit. From vladimir.kozlov at oracle.com Wed Mar 30 11:36:06 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2011 11:36:06 -0700 Subject: Request for review (S): 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 In-Reply-To: <88CC2B5C-7059-494C-9585-7CA81761BA3C@oracle.com> References: <0B6ADFC2-6DEC-4BFC-994E-EFB1F1B04D0B@oracle.com> <4D934F07.6060301@oracle.com> <88CC2B5C-7059-494C-9585-7CA81761BA3C@oracle.com> Message-ID: <4D937816.3080109@oracle.com> Good. Vladimir Christian Thalinger wrote: > I made two small changes that Paul suggested since #ifdefs are bad and cmovptr makes more sense in the context. > > -- Christian > > On Mar 30, 2011, at 5:40 PM, Paul Hohensee wrote: >> Couple of small comments. >> >> In assembler_x86.cpp, I'd removed the #ifdef _LP64 and have supports_cmov >> be the condition that determines whether or not to emit the cmov. Every 64-bit >> chip supports cmov, so supports_cmov will return true on every 64-bit platform. >> >> In templateTable_x86_32.cpp, you use cmov, which you've made an alias for >> cmovptr in assembler_x86.hpp. I'd get use cmovptr directly here instead, >> esp. since cmpptr is used just before it. >> >> Paul >> >> On 3/30/11 8:46 AM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7032388/ >>> >>> 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 >>> Summary: 6919934 added some unguarded cmov instructions which hit a guarantee on older hardware. >>> Reviewed-by: >>> >>> 6919934 added some unguarded cmov instructions which hit a guarantee >>> on older hardware (pre-i686). >>> >>> The fix is to either guard the added cmov instructions with a >>> supports_cmov() or let the cmov instruction decide itself if the >>> hardware supports cmov and if not use a branch-mov idiom. I chose the >>> latter. >>> >>> src/cpu/x86/vm/assembler_x86.cpp >>> src/cpu/x86/vm/assembler_x86.hpp >>> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >>> src/cpu/x86/vm/c1_Runtime1_x86.cpp >>> src/cpu/x86/vm/templateTable_x86_32.cpp > > From tom.rodriguez at oracle.com Wed Mar 30 12:05:20 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 30 Mar 2011 19:05:20 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue Message-ID: <20110330190522.9297147639@hg.openjdk.java.net> Changeset: 63997f575155 Author: never Date: 2011-03-30 07:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/63997f575155 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue Reviewed-by: kvn, dcubed ! agent/src/share/classes/sun/jvm/hotspot/jdi/ClassObjectReferenceImpl.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/oops/InstanceMirrorKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java + agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFactoryImpl.java ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/runtime/vmStructs.cpp From igor.veresov at oracle.com Wed Mar 30 12:34:57 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Mar 2011 12:34:57 -0700 Subject: Request for review (S): 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 In-Reply-To: <88CC2B5C-7059-494C-9585-7CA81761BA3C@oracle.com> References: <0B6ADFC2-6DEC-4BFC-994E-EFB1F1B04D0B@oracle.com> <4D934F07.6060301@oracle.com> <88CC2B5C-7059-494C-9585-7CA81761BA3C@oracle.com> Message-ID: <4D9385E1.6050807@oracle.com> Still looks good. igor On 3/30/11 11:30 AM, Christian Thalinger wrote: > I made two small changes that Paul suggested since #ifdefs are bad and cmovptr makes more sense in the context. > > -- Christian > > On Mar 30, 2011, at 5:40 PM, Paul Hohensee wrote: >> Couple of small comments. >> >> In assembler_x86.cpp, I'd removed the #ifdef _LP64 and have supports_cmov >> be the condition that determines whether or not to emit the cmov. Every 64-bit >> chip supports cmov, so supports_cmov will return true on every 64-bit platform. >> >> In templateTable_x86_32.cpp, you use cmov, which you've made an alias for >> cmovptr in assembler_x86.hpp. I'd get use cmovptr directly here instead, >> esp. since cmpptr is used just before it. >> >> Paul >> >> On 3/30/11 8:46 AM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7032388/ >>> >>> 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 >>> Summary: 6919934 added some unguarded cmov instructions which hit a guarantee on older hardware. >>> Reviewed-by: >>> >>> 6919934 added some unguarded cmov instructions which hit a guarantee >>> on older hardware (pre-i686). >>> >>> The fix is to either guard the added cmov instructions with a >>> supports_cmov() or let the cmov instruction decide itself if the >>> hardware supports cmov and if not use a branch-mov idiom. I chose the >>> latter. >>> >>> src/cpu/x86/vm/assembler_x86.cpp >>> src/cpu/x86/vm/assembler_x86.hpp >>> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >>> src/cpu/x86/vm/c1_Runtime1_x86.cpp >>> src/cpu/x86/vm/templateTable_x86_32.cpp > > From tom.rodriguez at oracle.com Wed Mar 30 13:22:59 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 30 Mar 2011 13:22:59 -0700 Subject: Request for reviews (M): 7032314: Allow to generate CallLeafNoFPNode in IdealKit In-Reply-To: <4D9377D2.9030403@oracle.com> References: <4D9377D2.9030403@oracle.com> Message-ID: Thanks for bringing this over. The only thing I don't like is the extra arg to sync_kit though I don't have any good suggestions for making it nicer. Maybe the existing sync_kit should be sync_and_drain with sync_kit skipping the drain? Anyway, maybe the flag is fine. However you want to handle it is ok with me. tom On Mar 30, 2011, at 11:34 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7032314/webrev > > Fixed 7032314: Allow to generate CallLeafNoFPNode in IdealKit > > Added CallLeafNoFPNode generation to IdealKit. Added i_o synchronization. > Consolidated synchronization code for IdealKit and graphKit. > From vladimir.kozlov at oracle.com Wed Mar 30 13:45:05 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2011 13:45:05 -0700 Subject: Request for reviews (M): 7032314: Allow to generate CallLeafNoFPNode in IdealKit In-Reply-To: References: <4D9377D2.9030403@oracle.com> Message-ID: <4D939651.7000402@oracle.com> Thank you, Tom I am fine to have a separate final sync method since I am touching all places where it is used anyway. How about this? void GraphKit::sync_kit(IdealKit& ideal) { set_all_memory(__ merged_memory()); set_i_o(__ i_o()); set_control(__ ctrl()); } void GraphKit::final_sync(IdealKit& ideal) { // Final sync IdealKit and graphKit. __ drain_delay_transform(); sync_kit(ideal); } Vladimir Tom Rodriguez wrote: > Thanks for bringing this over. The only thing I don't like is the extra arg to sync_kit though I don't have any good suggestions for making it nicer. Maybe the existing sync_kit should be sync_and_drain with sync_kit skipping the drain? Anyway, maybe the flag is fine. However you want to handle it is ok with me. > > tom > > On Mar 30, 2011, at 11:34 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7032314/webrev >> >> Fixed 7032314: Allow to generate CallLeafNoFPNode in IdealKit >> >> Added CallLeafNoFPNode generation to IdealKit. Added i_o synchronization. >> Consolidated synchronization code for IdealKit and graphKit. >> > From igor.veresov at oracle.com Wed Mar 30 14:15:29 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Mar 2011 14:15:29 -0700 Subject: review(XXS) 6564610: assert(UseCompiler || CompileTheWorld, "UseCompiler should be set by now.") Message-ID: <4D939D71.3020908@oracle.com> The assert mentioned in the bug synopsis is sometimes observed when the code cache gets full. What happens is a race between a check for UseCompiler in NonTieredCompPolicy::event() and checks in asserts in method_invocation_event() and method_back_branch_event(). The value of UseCompiler can change in-between. It is wrong to assert that UseCompiler is set or not because it can change asynchronously at any point. The solution is to remove the asserts. Webrev: http://cr.openjdk.java.net/~iveresov/6564610/webrev.00/ Thanks, igor From paul.hohensee at oracle.com Wed Mar 30 14:22:55 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 30 Mar 2011 17:22:55 -0400 Subject: Request for review (S): 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 In-Reply-To: <4D9385E1.6050807@oracle.com> References: <0B6ADFC2-6DEC-4BFC-994E-EFB1F1B04D0B@oracle.com> <4D934F07.6060301@oracle.com> <88CC2B5C-7059-494C-9585-7CA81761BA3C@oracle.com> <4D9385E1.6050807@oracle.com> Message-ID: <4D939F2F.9040000@oracle.com> Yes. Paul On 3/30/11 3:34 PM, Igor Veresov wrote: > Still looks good. > > igor > > On 3/30/11 11:30 AM, Christian Thalinger wrote: >> I made two small changes that Paul suggested since #ifdefs are bad >> and cmovptr makes more sense in the context. >> >> -- Christian >> >> On Mar 30, 2011, at 5:40 PM, Paul Hohensee wrote: >>> Couple of small comments. >>> >>> In assembler_x86.cpp, I'd removed the #ifdef _LP64 and have >>> supports_cmov >>> be the condition that determines whether or not to emit the cmov. >>> Every 64-bit >>> chip supports cmov, so supports_cmov will return true on every >>> 64-bit platform. >>> >>> In templateTable_x86_32.cpp, you use cmov, which you've made an >>> alias for >>> cmovptr in assembler_x86.hpp. I'd get use cmovptr directly here >>> instead, >>> esp. since cmpptr is used just before it. >>> >>> Paul >>> >>> On 3/30/11 8:46 AM, Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/7032388/ >>>> >>>> 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal >>>> instruction on i586 after 6919934 >>>> Summary: 6919934 added some unguarded cmov instructions which hit a >>>> guarantee on older hardware. >>>> Reviewed-by: >>>> >>>> 6919934 added some unguarded cmov instructions which hit a guarantee >>>> on older hardware (pre-i686). >>>> >>>> The fix is to either guard the added cmov instructions with a >>>> supports_cmov() or let the cmov instruction decide itself if the >>>> hardware supports cmov and if not use a branch-mov idiom. I chose the >>>> latter. >>>> >>>> src/cpu/x86/vm/assembler_x86.cpp >>>> src/cpu/x86/vm/assembler_x86.hpp >>>> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >>>> src/cpu/x86/vm/c1_Runtime1_x86.cpp >>>> src/cpu/x86/vm/templateTable_x86_32.cpp >> >> > From tom.rodriguez at oracle.com Wed Mar 30 14:59:33 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 30 Mar 2011 14:59:33 -0700 Subject: review(XXS) 6564610: assert(UseCompiler || CompileTheWorld, "UseCompiler should be set by now.") In-Reply-To: <4D939D71.3020908@oracle.com> References: <4D939D71.3020908@oracle.com> Message-ID: I suspected that they should just be deleted. Looks good. tom On Mar 30, 2011, at 2:15 PM, Igor Veresov wrote: > The assert mentioned in the bug synopsis is sometimes observed when the code cache gets full. What happens is a race between a check for UseCompiler in NonTieredCompPolicy::event() and checks in asserts in method_invocation_event() and method_back_branch_event(). The value of UseCompiler can change in-between. It is wrong to assert that UseCompiler is set or not because it can change asynchronously at any point. The solution is to remove the asserts. > > Webrev: http://cr.openjdk.java.net/~iveresov/6564610/webrev.00/ > > > Thanks, > igor From vladimir.kozlov at oracle.com Wed Mar 30 15:02:38 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2011 15:02:38 -0700 Subject: review(XXS) 6564610: assert(UseCompiler || CompileTheWorld, "UseCompiler should be set by now.") In-Reply-To: <4D939D71.3020908@oracle.com> References: <4D939D71.3020908@oracle.com> Message-ID: <4D93A87E.1000101@oracle.com> Looks good. Vladimir Igor Veresov wrote: > The assert mentioned in the bug synopsis is sometimes observed when the > code cache gets full. What happens is a race between a check for > UseCompiler in NonTieredCompPolicy::event() and checks in asserts in > method_invocation_event() and method_back_branch_event(). The value of > UseCompiler can change in-between. It is wrong to assert that > UseCompiler is set or not because it can change asynchronously at any > point. The solution is to remove the asserts. > > Webrev: http://cr.openjdk.java.net/~iveresov/6564610/webrev.00/ > > > Thanks, > igor From igor.veresov at oracle.com Wed Mar 30 15:09:04 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Mar 2011 15:09:04 -0700 Subject: review(XXS) 6564610: assert(UseCompiler || CompileTheWorld, "UseCompiler should be set by now.") In-Reply-To: <4D93A87E.1000101@oracle.com> References: <4D939D71.3020908@oracle.com> <4D93A87E.1000101@oracle.com> Message-ID: <4D93AA00.6020103@oracle.com> Thanks Tom and Vladimir! igor On 3/30/11 3:02 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > Igor Veresov wrote: >> The assert mentioned in the bug synopsis is sometimes observed when >> the code cache gets full. What happens is a race between a check for >> UseCompiler in NonTieredCompPolicy::event() and checks in asserts in >> method_invocation_event() and method_back_branch_event(). The value of >> UseCompiler can change in-between. It is wrong to assert that >> UseCompiler is set or not because it can change asynchronously at any >> point. The solution is to remove the asserts. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6564610/webrev.00/ >> >> >> Thanks, >> igor From tom.rodriguez at oracle.com Wed Mar 30 16:46:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 30 Mar 2011 16:46:32 -0700 Subject: review for 7029167: add support for conditional card marks Message-ID: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> http://cr.openjdk.java.net/~never/7029167 7029167: add support for conditional card marks Reviewed-by: Repeated updates to the card table can be a source of contention on multiprocessor machines that can greatly inhibit scalability. This adds support in C2 for conditional card marks. Tested with jbb and CTW. At some point this should be turned on automatically when multi socket machines are detected but that's covered under another bug as is C1 support. From tom.rodriguez at oracle.com Wed Mar 30 16:46:44 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 30 Mar 2011 16:46:44 -0700 Subject: review for 6385687: UseFastEmptyMethods/UseFastAccessorMethods considered harmful Message-ID: <2D4D5C48-35D5-4813-9DF6-37CDCAE96CE0@oracle.com> http://cr.openjdk.java.net/~never/6385687 6385687: UseFastEmptyMethods/UseFastAccessorMethods considered harmful Reviewed-by: While running various benchmarks, it was noticed that the use of UseFastEmptyMethods/UseFastAccessorMethods can cause us to skip compiling these methods because the fast versions don't have invocation counters. This can create severe performance anomalies if the empty or accessor methods don't get inlined since we'll always transition to the interpreter to execute this trivial code. This commonly occurs at call sites that are truly polymorphic. We could conceivably add invocation counter updates to these methods but that simply makes them less fast and requires more changes. So it's more straightforward to simply disable them by default. We could turn them on for -Xint mode or we could delete the fast accessor machinery completely. It really only helps with raw interpreter performance. Tested with jbb and grindermark. From vladimir.kozlov at oracle.com Wed Mar 30 17:03:02 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2011 17:03:02 -0700 Subject: review for 7029167: add support for conditional card marks In-Reply-To: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> References: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> Message-ID: <4D93C4B6.4060005@oracle.com> Tom, what about arraycopy stubs? Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7029167 > > 7029167: add support for conditional card marks > Reviewed-by: > > Repeated updates to the card table can be a source of contention on > multiprocessor machines that can greatly inhibit scalability. This > adds support in C2 for conditional card marks. Tested with jbb and > CTW. At some point this should be turned on automatically when multi > socket machines are detected but that's covered under another bug as > is C1 support. > From tom.rodriguez at oracle.com Wed Mar 30 17:10:56 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 30 Mar 2011 17:10:56 -0700 Subject: review for 7029167: add support for conditional card marks In-Reply-To: <4D93C4B6.4060005@oracle.com> References: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> <4D93C4B6.4060005@oracle.com> Message-ID: On Mar 30, 2011, at 5:03 PM, Vladimir Kozlov wrote: > Tom, > > what about arraycopy stubs? I don't think they are necessary. This is really about the performance of concurrent algorithms that are doing a lot of field updates, not eliminating all redundant card marks. tom > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7029167 >> 7029167: add support for conditional card marks >> Reviewed-by: >> Repeated updates to the card table can be a source of contention on >> multiprocessor machines that can greatly inhibit scalability. This >> adds support in C2 for conditional card marks. Tested with jbb and >> CTW. At some point this should be turned on automatically when multi >> socket machines are detected but that's covered under another bug as >> is C1 support. From john.r.rose at oracle.com Wed Mar 30 17:13:07 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 30 Mar 2011 17:13:07 -0700 Subject: review for 6385687: UseFastEmptyMethods/UseFastAccessorMethods considered harmful In-Reply-To: <2D4D5C48-35D5-4813-9DF6-37CDCAE96CE0@oracle.com> References: <2D4D5C48-35D5-4813-9DF6-37CDCAE96CE0@oracle.com> Message-ID: <763AAF61-2928-4902-B0C2-07AB5BD59E5B@oracle.com> Good. -- John On Mar 30, 2011, at 4:46 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6385687 > > 6385687: UseFastEmptyMethods/UseFastAccessorMethods considered harmful > Reviewed-by: > > While running various benchmarks, it was noticed that the use of > UseFastEmptyMethods/UseFastAccessorMethods can cause us to skip > compiling these methods because the fast versions don't have > invocation counters. This can create severe performance anomalies if > the empty or accessor methods don't get inlined since we'll always > transition to the interpreter to execute this trivial code. This > commonly occurs at call sites that are truly polymorphic. We could > conceivably add invocation counter updates to these methods but that > simply makes them less fast and requires more changes. So it's more > straightforward to simply disable them by default. We could turn them > on for -Xint mode or we could delete the fast accessor machinery > completely. It really only helps with raw interpreter performance. > Tested with jbb and grindermark. > From vladimir.kozlov at oracle.com Wed Mar 30 17:18:20 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2011 17:18:20 -0700 Subject: review for 6385687: UseFastEmptyMethods/UseFastAccessorMethods considered harmful In-Reply-To: <2D4D5C48-35D5-4813-9DF6-37CDCAE96CE0@oracle.com> References: <2D4D5C48-35D5-4813-9DF6-37CDCAE96CE0@oracle.com> Message-ID: <4D93C84C.5000008@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6385687 > > 6385687: UseFastEmptyMethods/UseFastAccessorMethods considered harmful > Reviewed-by: > > While running various benchmarks, it was noticed that the use of > UseFastEmptyMethods/UseFastAccessorMethods can cause us to skip > compiling these methods because the fast versions don't have > invocation counters. This can create severe performance anomalies if > the empty or accessor methods don't get inlined since we'll always > transition to the interpreter to execute this trivial code. This > commonly occurs at call sites that are truly polymorphic. We could > conceivably add invocation counter updates to these methods but that > simply makes them less fast and requires more changes. So it's more > straightforward to simply disable them by default. We could turn them > on for -Xint mode or we could delete the fast accessor machinery > completely. It really only helps with raw interpreter performance. > Tested with jbb and grindermark. > From vladimir.kozlov at oracle.com Wed Mar 30 17:24:55 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2011 17:24:55 -0700 Subject: review for 7029167: add support for conditional card marks In-Reply-To: References: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> <4D93C4B6.4060005@oracle.com> Message-ID: <4D93C9D7.5050905@oracle.com> Looks good then. We may need to switch it ON for Nightly testing. Vladimir. Tom Rodriguez wrote: > On Mar 30, 2011, at 5:03 PM, Vladimir Kozlov wrote: > >> Tom, >> >> what about arraycopy stubs? > > I don't think they are necessary. This is really about the performance of concurrent algorithms that are doing a lot of field updates, not eliminating all redundant card marks. > > tom > >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7029167 >>> 7029167: add support for conditional card marks >>> Reviewed-by: >>> Repeated updates to the card table can be a source of contention on >>> multiprocessor machines that can greatly inhibit scalability. This >>> adds support in C2 for conditional card marks. Tested with jbb and >>> CTW. At some point this should be turned on automatically when multi >>> socket machines are detected but that's covered under another bug as >>> is C1 support. > From igor.veresov at oracle.com Wed Mar 30 17:25:55 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Mar 2011 17:25:55 -0700 Subject: review for 7029167: add support for conditional card marks In-Reply-To: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> References: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> Message-ID: <4D93CA13.2070805@oracle.com> Looks good. Could you use CardTableModRefBS::dirty_card_val() instead of 0? I know we use just zero already in many places, but I'm fresh from barrier experimentation and it would've been much nicer if we used symbolic names. igor On 3/30/11 4:46 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7029167 > > 7029167: add support for conditional card marks > Reviewed-by: > > Repeated updates to the card table can be a source of contention on > multiprocessor machines that can greatly inhibit scalability. This > adds support in C2 for conditional card marks. Tested with jbb and > CTW. At some point this should be turned on automatically when multi > socket machines are detected but that's covered under another bug as > is C1 support. > From john.r.rose at oracle.com Wed Mar 30 17:30:22 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 30 Mar 2011 17:30:22 -0700 Subject: review for 7029167: add support for conditional card marks In-Reply-To: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> References: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> Message-ID: <12FEDB04-2B3C-4E2C-92BD-6181AD4B6217@oracle.com> Your comment mentions ldsb/ldub, but I think it is about ldsw/lduw. (I think you'll get lduw from the LoadI, and whether that turns into a brnz depends on the vagaries of can_branch_register in sparc.ad.) I spot-checked other places where card marks are processed in opto, and saw no problems. Reviewed. -- John On Mar 30, 2011, at 4:46 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7029167 > > 7029167: add support for conditional card marks > Reviewed-by: > > Repeated updates to the card table can be a source of contention on > multiprocessor machines that can greatly inhibit scalability. This > adds support in C2 for conditional card marks. Tested with jbb and > CTW. At some point this should be turned on automatically when multi > socket machines are detected but that's covered under another bug as > is C1 support. > From tom.rodriguez at oracle.com Wed Mar 30 17:33:03 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 30 Mar 2011 17:33:03 -0700 Subject: review for 7029167: add support for conditional card marks In-Reply-To: <4D93CA13.2070805@oracle.com> References: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> <4D93CA13.2070805@oracle.com> Message-ID: <88D6385E-01D6-450C-849E-8DFF7DAAB990@oracle.com> On Mar 30, 2011, at 5:25 PM, Igor Veresov wrote: > Looks good. Thanks! > Could you use CardTableModRefBS::dirty_card_val() instead of 0? I know we use just zero already in many places, but I'm fresh from barrier experimentation and it would've been much nicer if we used symbolic names. I'd rather not. If we really want to use dirty_card_val then it should be done everywhere as its own change instead of just patching part of C2. tom > > > igor > > On 3/30/11 4:46 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7029167 >> >> 7029167: add support for conditional card marks >> Reviewed-by: >> >> Repeated updates to the card table can be a source of contention on >> multiprocessor machines that can greatly inhibit scalability. This >> adds support in C2 for conditional card marks. Tested with jbb and >> CTW. At some point this should be turned on automatically when multi >> socket machines are detected but that's covered under another bug as >> is C1 support. >> > From igor.veresov at oracle.com Wed Mar 30 17:35:54 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Mar 2011 17:35:54 -0700 Subject: review for 7029167: add support for conditional card marks In-Reply-To: <88D6385E-01D6-450C-849E-8DFF7DAAB990@oracle.com> References: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> <4D93CA13.2070805@oracle.com> <88D6385E-01D6-450C-849E-8DFF7DAAB990@oracle.com> Message-ID: <4D93CC6A.2030808@oracle.com> On 3/30/11 5:33 PM, Tom Rodriguez wrote: > > On Mar 30, 2011, at 5:25 PM, Igor Veresov wrote: > >> Looks good. > > Thanks! > >> Could you use CardTableModRefBS::dirty_card_val() instead of 0? I know we use just zero already in many places, but I'm fresh from barrier experimentation and it would've been much nicer if we used symbolic names. > > I'd rather not. If we really want to use dirty_card_val then it should be done everywhere as its own change instead of just patching part of C2. > May be a comment then, saying that ConI(0) represents dirty_card ? Just for the sake of future grepping? igor > tom > >> >> >> igor >> >> On 3/30/11 4:46 PM, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7029167 >>> >>> 7029167: add support for conditional card marks >>> Reviewed-by: >>> >>> Repeated updates to the card table can be a source of contention on >>> multiprocessor machines that can greatly inhibit scalability. This >>> adds support in C2 for conditional card marks. Tested with jbb and >>> CTW. At some point this should be turned on automatically when multi >>> socket machines are detected but that's covered under another bug as >>> is C1 support. >>> >> > From tom.rodriguez at oracle.com Wed Mar 30 17:38:57 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 30 Mar 2011 17:38:57 -0700 Subject: review for 7029167: add support for conditional card marks In-Reply-To: <4D93CC6A.2030808@oracle.com> References: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> <4D93CA13.2070805@oracle.com> <88D6385E-01D6-450C-849E-8DFF7DAAB990@oracle.com> <4D93CC6A.2030808@oracle.com> Message-ID: <3C3D8E53-8527-4959-B7D3-9AB6BB0460B5@oracle.com> On Mar 30, 2011, at 5:35 PM, Igor Veresov wrote: > On 3/30/11 5:33 PM, Tom Rodriguez wrote: >> >> On Mar 30, 2011, at 5:25 PM, Igor Veresov wrote: >> >>> Looks good. >> >> Thanks! >> >>> Could you use CardTableModRefBS::dirty_card_val() instead of 0? I know we use just zero already in many places, but I'm fresh from barrier experimentation and it would've been much nicer if we used symbolic names. >> >> I'd rather not. If we really want to use dirty_card_val then it should be done everywhere as its own change instead of just patching part of C2. >> > > May be a comment then, saying that ConI(0) represents dirty_card ? Just for the sake of future grepping? Ok. BasicType bt = T_BYTE; Node* zero = __ ConI(0); // Dirty card value if (UseCondCardMark) { tom > > igor > >> tom >> >>> >>> >>> igor >>> >>> On 3/30/11 4:46 PM, Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7029167 >>>> >>>> 7029167: add support for conditional card marks >>>> Reviewed-by: >>>> >>>> Repeated updates to the card table can be a source of contention on >>>> multiprocessor machines that can greatly inhibit scalability. This >>>> adds support in C2 for conditional card marks. Tested with jbb and >>>> CTW. At some point this should be turned on automatically when multi >>>> socket machines are detected but that's covered under another bug as >>>> is C1 support. >>>> >>> >> > From igor.veresov at oracle.com Wed Mar 30 17:40:39 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Mar 2011 17:40:39 -0700 Subject: review for 7029167: add support for conditional card marks In-Reply-To: <3C3D8E53-8527-4959-B7D3-9AB6BB0460B5@oracle.com> References: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> <4D93CA13.2070805@oracle.com> <88D6385E-01D6-450C-849E-8DFF7DAAB990@oracle.com> <4D93CC6A.2030808@oracle.com> <3C3D8E53-8527-4959-B7D3-9AB6BB0460B5@oracle.com> Message-ID: <4D93CD87.708@oracle.com> Thanks! igor On 3/30/11 5:38 PM, Tom Rodriguez wrote: > > On Mar 30, 2011, at 5:35 PM, Igor Veresov wrote: > >> On 3/30/11 5:33 PM, Tom Rodriguez wrote: >>> >>> On Mar 30, 2011, at 5:25 PM, Igor Veresov wrote: >>> >>>> Looks good. >>> >>> Thanks! >>> >>>> Could you use CardTableModRefBS::dirty_card_val() instead of 0? I know we use just zero already in many places, but I'm fresh from barrier experimentation and it would've been much nicer if we used symbolic names. >>> >>> I'd rather not. If we really want to use dirty_card_val then it should be done everywhere as its own change instead of just patching part of C2. >>> >> >> May be a comment then, saying that ConI(0) represents dirty_card ? Just for the sake of future grepping? > > Ok. > > BasicType bt = T_BYTE; > Node* zero = __ ConI(0); // Dirty card value > > if (UseCondCardMark) { > > tom > >> >> igor >> >>> tom >>> >>>> >>>> >>>> igor >>>> >>>> On 3/30/11 4:46 PM, Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/7029167 >>>>> >>>>> 7029167: add support for conditional card marks >>>>> Reviewed-by: >>>>> >>>>> Repeated updates to the card table can be a source of contention on >>>>> multiprocessor machines that can greatly inhibit scalability. This >>>>> adds support in C2 for conditional card marks. Tested with jbb and >>>>> CTW. At some point this should be turned on automatically when multi >>>>> socket machines are detected but that's covered under another bug as >>>>> is C1 support. >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Wed Mar 30 17:46:23 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 31 Mar 2011 00:46:23 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7029152: Ideal nodes for String intrinsics miss memory edge optimization Message-ID: <20110331004625.8039847647@hg.openjdk.java.net> Changeset: f9424955eb18 Author: kvn Date: 2011-03-30 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f9424955eb18 7029152: Ideal nodes for String intrinsics miss memory edge optimization Summary: In Ideal() method of String intrinsics nodes look for TypeAryPtr::CHARS memory slice if memory is MergeMem. Do not unroll a loop with String intrinsics code. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/7029152/Test.java From tom.rodriguez at oracle.com Wed Mar 30 18:00:47 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 30 Mar 2011 18:00:47 -0700 Subject: review for 7029167: add support for conditional card marks In-Reply-To: <12FEDB04-2B3C-4E2C-92BD-6181AD4B6217@oracle.com> References: <5E6E9B0F-D380-4C32-8467-B46236289258@oracle.com> <12FEDB04-2B3C-4E2C-92BD-6181AD4B6217@oracle.com> Message-ID: On Mar 30, 2011, at 5:30 PM, John Rose wrote: > Your comment mentions ldsb/ldub, but I think it is about ldsw/lduw. Actually that's an ancient comment from Steve Goldman who originally wrote this for Doug many moons ago. It really will be an ldsb. The result is typed TypeInt::INT but the basic type is T_BYTE. I'll correct the result type to be TypeInt::BYTE since that's what it really is. I'm going to delete the language about what we'd like to see on sparc too since that seems extraneous to me. It know looks like this: if (UseCondCardMark) { // The classic GC reference write barrier is typically implemented // as a store into the global card mark table. Unfortunately // unconditional stores can result in false sharing and excessive // coherence traffic as well as false transactional aborts. // UseCondCardMark enables MP "polite" conditional card mark // stores. In theory we could relax the load from ctrl() to // no_ctrl, but that doesn't buy much latitude. Node* card_val = __ load( __ ctrl(), card_adr, TypeInt::BYTE, bt, adr_type); __ if_then(card_val, BoolTest::ne, zero); } > > (I think you'll get lduw from the LoadI, and whether that turns into a brnz depends on the vagaries of can_branch_register in sparc.ad.) We don't use can_branch_register at all right now because we can't handle the short branches it produces. We'll fix that in a bit though. > > I spot-checked other places where card marks are processed in opto, and saw no problems. Thanks! tom > > Reviewed. > > -- John > > On Mar 30, 2011, at 4:46 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/7029167 >> >> 7029167: add support for conditional card marks >> Reviewed-by: >> >> Repeated updates to the card table can be a source of contention on >> multiprocessor machines that can greatly inhibit scalability. This >> adds support in C2 for conditional card marks. Tested with jbb and >> CTW. At some point this should be turned on automatically when multi >> socket machines are detected but that's covered under another bug as >> is C1 support. >> > From vladimir.kozlov at oracle.com Wed Mar 30 20:10:25 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2011 20:10:25 -0700 Subject: review(XS) 7032696: Fix for 7029152 broke VM Message-ID: <4D93F0A1.7040509@oracle.com> http://cr.openjdk.java.net/~kvn/7032696/webrev Fixed: 7032696: Fix for 7029152 broke VM StrIntrinsicNode::Ideal() should not optimize memory during Parse. Tested with full CTW. From igor.veresov at oracle.com Wed Mar 30 20:49:50 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 31 Mar 2011 03:49:50 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110331034953.CA74B47652@hg.openjdk.java.net> Changeset: e2eb7f986c64 Author: iveresov Date: 2011-03-30 15:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e2eb7f986c64 6564610: assert(UseCompiler || CompileTheWorld, "UseCompiler should be set by now.") Summary: Remove invalid asserts Reviewed-by: never, kvn ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 9d343b8113db Author: iveresov Date: 2011-03-30 18:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9d343b8113db Merge From christian.thalinger at oracle.com Wed Mar 30 23:58:10 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 31 Mar 2011 08:58:10 +0200 Subject: Request for review (S): 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 In-Reply-To: <4D939F2F.9040000@oracle.com> References: <0B6ADFC2-6DEC-4BFC-994E-EFB1F1B04D0B@oracle.com> <4D934F07.6060301@oracle.com> <88CC2B5C-7059-494C-9585-7CA81761BA3C@oracle.com> <4D9385E1.6050807@oracle.com> <4D939F2F.9040000@oracle.com> Message-ID: <0685E972-2D38-4B1D-90CA-8040573F3DEB@oracle.com> Thank you, Tom, Igor, Vladimir and Paul. -- Christian On Mar 30, 2011, at 11:22 PM, Paul Hohensee wrote: > Yes. > > Paul > > On 3/30/11 3:34 PM, Igor Veresov wrote: >> Still looks good. >> >> igor >> >> On 3/30/11 11:30 AM, Christian Thalinger wrote: >>> I made two small changes that Paul suggested since #ifdefs are bad and cmovptr makes more sense in the context. >>> >>> -- Christian >>> >>> On Mar 30, 2011, at 5:40 PM, Paul Hohensee wrote: >>>> Couple of small comments. >>>> >>>> In assembler_x86.cpp, I'd removed the #ifdef _LP64 and have supports_cmov >>>> be the condition that determines whether or not to emit the cmov. Every 64-bit >>>> chip supports cmov, so supports_cmov will return true on every 64-bit platform. >>>> >>>> In templateTable_x86_32.cpp, you use cmov, which you've made an alias for >>>> cmovptr in assembler_x86.hpp. I'd get use cmovptr directly here instead, >>>> esp. since cmpptr is used just before it. >>>> >>>> Paul >>>> >>>> On 3/30/11 8:46 AM, Christian Thalinger wrote: >>>>> http://cr.openjdk.java.net/~twisti/7032388/ >>>>> >>>>> 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 >>>>> Summary: 6919934 added some unguarded cmov instructions which hit a guarantee on older hardware. >>>>> Reviewed-by: >>>>> >>>>> 6919934 added some unguarded cmov instructions which hit a guarantee >>>>> on older hardware (pre-i686). >>>>> >>>>> The fix is to either guard the added cmov instructions with a >>>>> supports_cmov() or let the cmov instruction decide itself if the >>>>> hardware supports cmov and if not use a branch-mov idiom. I chose the >>>>> latter. >>>>> >>>>> src/cpu/x86/vm/assembler_x86.cpp >>>>> src/cpu/x86/vm/assembler_x86.hpp >>>>> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >>>>> src/cpu/x86/vm/c1_Runtime1_x86.cpp >>>>> src/cpu/x86/vm/templateTable_x86_32.cpp From gbenson at redhat.com Thu Mar 31 02:21:26 2011 From: gbenson at redhat.com (Gary Benson) Date: Thu, 31 Mar 2011 10:21:26 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> Message-ID: <20110331092125.GA3884@redhat.com> Dr Andrew John Hughes wrote: > On 30 March 2011 15:49, Christian Thalinger > wrote: > > On Mar 30, 2011, at 4:38 PM, Dr Andrew John Hughes wrote: > > > 1. Makefile changes which make sure the Shark files are once > > > again compiled (and which I believe would need to be reviewed > > > by Kelly anyway) > > > 2. The trivial #ifndef addition which fixes a regression > > > introduced by the recent HotSpot security fix. > > > 3. The fix for the bug Gary mentioned which appears to mean > > > API changes (I don't completely understand this bit). > > > > > > The first two have been tested in IcedTea6 and correspond to > > > regressions introduced by identifiable changesets. > > > I'm not sure of the impact of the third. ... > > Alright, let's split the work :-) > > > > Andrew, can you take care of 1. and send it to build-dev? ?I take > > the rest of the patch (2. and 3.) and push it as the one CR I > > created. ?I don't think it makes much sense to have an extra CR > > for 2. > > I'm happy to handle 1 (as I say, I was going to get around to it > anyway). I would prefer 2 was as without it, Shark is currently > broken in OpenJDK6. 1 won't be an issue until hs20 is imported into > OpenJDK6. I don't know enough about 3, which is why I'm sceptical > about including that in a fix for a current Shark build failure in > OpenJDK6. So if you do combine them, I'll probably split them for > 6 anyway, to be on the safe side. Ok, I looked a little further into 3. The root cause was this: changeset: 1611:136b78722a08 user: jrose date: Wed Jun 09 18:50:45 2010 -0700 summary: 6939203: JSR 292 needs method handle constants It two new internal instructions, _fast_aldc and _fast_aldc_w, but it added them *before* _return_register_finalizer, which broke the instructions table in bytecodeInterpreter.cpp. It meant that when the C++ interpreter saw _return_register_finalizer it would execute opc_default, which should have thrown an error but for the piece of the ARM interpreter which hid the error by rewriting the instruction to a plain _return. I didn't see it before because I was doing debug builds, and the C++ interpreter only uses the instructions table for product builds. The bottom line is, if you see _fast_aldc in bytecodes.hpp then Zero won't work correctly without this patch. Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Thu Mar 31 02:26:24 2011 From: gbenson at redhat.com (Gary Benson) Date: Thu, 31 Mar 2011 10:26:24 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> <20110330145524.GG8648@redhat.com> <5CD03827-E730-4CFB-A044-DA555167B10A@oracle.com> <20110330151617.GH8648@redhat.com> Message-ID: <20110331092624.GB3884@redhat.com> Dr Andrew John Hughes wrote: > On 30 March 2011 16:16, Gary Benson wrote: > > Christian Thalinger wrote: > > > On Mar 30, 2011, at 4:55 PM, Gary Benson wrote: > > > > Christian Thalinger wrote: > > > > > Andrew, can you take care of 1. and send it to build-dev? > > > > > I take the rest of the patch (2. and 3.) and push it as > > > > > the one CR I created. ?I don't think it makes much sense > > > > > to have an extra CR for 2. > > > > > > > > Would you like me to make new webrevs? > > > > > > Yes, that would be good for the record and to put URL into > > > the CR. > > > > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/ > > ?is the build fixes, for Andrew. > > Thanks. http://mail.openjdk.java.net/pipermail/build-dev/2011-March/004369.html Thanks. > Assuming you came up with this change and didn't see the one in > IcedTea, it's interesting that they are virtually identical. I didn't see it, but it's the logical way to do it given how it's done for the other cases. What's with the launcher.make changes in that patch? I've not seen that before. Cheers, Gary -- http://gbenson.net/ From christian.thalinger at oracle.com Thu Mar 31 02:30:12 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 31 Mar 2011 09:30:12 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 Message-ID: <20110331093020.5D5F347671@hg.openjdk.java.net> Changeset: 09f96c3ff1ad Author: twisti Date: 2011-03-31 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/09f96c3ff1ad 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 Summary: 6919934 added some unguarded cmov instructions which hit a guarantee on older hardware. Reviewed-by: never, iveresov, kvn, phh ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp From christian.thalinger at oracle.com Thu Mar 31 05:18:54 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 31 Mar 2011 12:18:54 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6817525: turn on method handle functionality by default for JSR 292 Message-ID: <20110331121901.8D83D47677@hg.openjdk.java.net> Changeset: 38fea01eb669 Author: twisti Date: 2011-03-31 02:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/38fea01eb669 6817525: turn on method handle functionality by default for JSR 292 Summary: After appropriate testing, we need to turn on EnableMethodHandles and EnableInvokeDynamic by default. Reviewed-by: never, kvn, jrose, phh ! 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/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp From vladimir.kozlov at oracle.com Thu Mar 31 09:51:42 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Mar 2011 09:51:42 -0700 Subject: review(XS) 7032696: Fix for 7029152 broke VM In-Reply-To: <4D93F0A1.7040509@oracle.com> References: <4D93F0A1.7040509@oracle.com> Message-ID: <4D94B11E.4020907@oracle.com> I updated webrev. As John pointed me, Ideal() should return 'this' when memory is updated. I also added a band-aid for one iteration loops problem which causes the second failure in the bug report. I have RFE 7004555 to fix it. Vladimir Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7032696/webrev > > Fixed: 7032696: Fix for 7029152 broke VM > > StrIntrinsicNode::Ideal() should not optimize memory during Parse. > > Tested with full CTW. From gnu_andrew at member.fsf.org Thu Mar 31 09:58:04 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Thu, 31 Mar 2011 17:58:04 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110331092125.GA3884@redhat.com> References: <20110330105202.GB8648@redhat.com> <4112538F-38BD-4152-9F8A-04A9F0AD9DF5@oracle.com> <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> <20110331092125.GA3884@redhat.com> Message-ID: On 31/03/2011, Gary Benson wrote: > Dr Andrew John Hughes wrote: >> On 30 March 2011 15:49, Christian Thalinger >> wrote: >> > On Mar 30, 2011, at 4:38 PM, Dr Andrew John Hughes wrote: >> > > 1. Makefile changes which make sure the Shark files are once >> > > again compiled (and which I believe would need to be reviewed >> > > by Kelly anyway) >> > > 2. The trivial #ifndef addition which fixes a regression >> > > introduced by the recent HotSpot security fix. >> > > 3. The fix for the bug Gary mentioned which appears to mean >> > > API changes (I don't completely understand this bit). >> > > >> > > The first two have been tested in IcedTea6 and correspond to >> > > regressions introduced by identifiable changesets. >> > > I'm not sure of the impact of the third. > ... >> > Alright, let's split the work :-) >> > >> > Andrew, can you take care of 1. and send it to build-dev? I take >> > the rest of the patch (2. and 3.) and push it as the one CR I >> > created. I don't think it makes much sense to have an extra CR >> > for 2. >> >> I'm happy to handle 1 (as I say, I was going to get around to it >> anyway). I would prefer 2 was as without it, Shark is currently >> broken in OpenJDK6. 1 won't be an issue until hs20 is imported into >> OpenJDK6. I don't know enough about 3, which is why I'm sceptical >> about including that in a fix for a current Shark build failure in >> OpenJDK6. So if you do combine them, I'll probably split them for >> 6 anyway, to be on the safe side. > > Ok, I looked a little further into 3. The root cause was this: > > changeset: 1611:136b78722a08 > user: jrose > date: Wed Jun 09 18:50:45 2010 -0700 > summary: 6939203: JSR 292 needs method handle constants > > It two new internal instructions, _fast_aldc and _fast_aldc_w, but > it added them *before* _return_register_finalizer, which broke the > instructions table in bytecodeInterpreter.cpp. It meant that when > the C++ interpreter saw _return_register_finalizer it would execute > opc_default, which should have thrown an error but for the piece of > the ARM interpreter which hid the error by rewriting the instruction > to a plain _return. I didn't see it before because I was doing > debug builds, and the C++ interpreter only uses the instructions > table for product builds. > > The bottom line is, if you see _fast_aldc in bytecodes.hpp then Zero > won't work correctly without this patch. > > Cheers, > Gary > > -- > http://gbenson.net/ > Ok, that change is in hs19 and thus OpenJDK6 already: $ hg log -R ../../jdk6/hotspot -k 6939203 changeset: 1805:136b78722a08 parent: 1795:49fac4acd688 user: jrose date: Wed Jun 09 18:50:45 2010 -0700 summary: 6939203: JSR 292 needs method handle constants I'm still wary that the fix is untested, but my main worry (that it fixed a newer change that wasn't in hs20) is alleviated. If Zero is broken without this, it needs to go in the 1.9 (hs19 non-default), 1.10 (hs19 default, hs20 non-default) and HEAD (hs20 default, hs19 non-default) branches of IcedTea6. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gbenson at redhat.com Thu Mar 31 10:26:45 2011 From: gbenson at redhat.com (Gary Benson) Date: Thu, 31 Mar 2011 18:26:45 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> <20110331092125.GA3884@redhat.com> Message-ID: <20110331172645.GE3884@redhat.com> Dr Andrew John Hughes wrote: > On 31/03/2011, Gary Benson wrote: > > Ok, I looked a little further into 3. The root cause was this: > > > > changeset: 1611:136b78722a08 > > user: jrose > > date: Wed Jun 09 18:50:45 2010 -0700 > > summary: 6939203: JSR 292 needs method handle constants > > > > It two new internal instructions, _fast_aldc and _fast_aldc_w, but > > it added them *before* _return_register_finalizer, which broke the > > instructions table in bytecodeInterpreter.cpp. It meant that when > > the C++ interpreter saw _return_register_finalizer it would > > execute opc_default, which should have thrown an error but for the > > piece of the ARM interpreter which hid the error by rewriting the > > instruction to a plain _return. I didn't see it before because I > > was doing debug builds, and the C++ interpreter only uses the > > instructions table for product builds. > > > > The bottom line is, if you see _fast_aldc in bytecodes.hpp then > > Zero won't work correctly without this patch. > > Ok, that change is in hs19 and thus OpenJDK6 already: > > $ hg log -R ../../jdk6/hotspot -k 6939203 > changeset: 1805:136b78722a08 > parent: 1795:49fac4acd688 > user: jrose > date: Wed Jun 09 18:50:45 2010 -0700 > summary: 6939203: JSR 292 needs method handle constants > > I'm still wary that the fix is untested, but my main worry (that > it fixed a newer change that wasn't in hs20) is alleviated. > > If Zero is broken without this, it needs to go in the 1.9 (hs19 > non-default), 1.10 (hs19 default, hs20 non-default) and HEAD (hs20 > default, hs19 non-default) branches of IcedTea6. If it really is in there (ie bytecodes.hpp contains _fast_aldc) then removing the ARM interpreter rewrite will cause the VM to instantly abort. Removal of the ARM interpreter rewrite is not necessary for this fix to work, but it'd be nice if it doesn't break other stuff. The fact this bug has persisted for so long is because the ARM interpreter code has hidden it. Cheers, Gary -- http://gbenson.net/ From gnu_andrew at member.fsf.org Thu Mar 31 11:20:05 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Thu, 31 Mar 2011 19:20:05 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110331172645.GE3884@redhat.com> References: <20110330115126.GC8648@redhat.com> <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> <20110331092125.GA3884@redhat.com> <20110331172645.GE3884@redhat.com> Message-ID: Errr... what ARM interpreter rewrite? On 31/03/2011, Gary Benson wrote: > Dr Andrew John Hughes wrote: >> On 31/03/2011, Gary Benson wrote: >> > Ok, I looked a little further into 3. The root cause was this: >> > >> > changeset: 1611:136b78722a08 >> > user: jrose >> > date: Wed Jun 09 18:50:45 2010 -0700 >> > summary: 6939203: JSR 292 needs method handle constants >> > >> > It two new internal instructions, _fast_aldc and _fast_aldc_w, but >> > it added them *before* _return_register_finalizer, which broke the >> > instructions table in bytecodeInterpreter.cpp. It meant that when >> > the C++ interpreter saw _return_register_finalizer it would >> > execute opc_default, which should have thrown an error but for the >> > piece of the ARM interpreter which hid the error by rewriting the >> > instruction to a plain _return. I didn't see it before because I >> > was doing debug builds, and the C++ interpreter only uses the >> > instructions table for product builds. >> > >> > The bottom line is, if you see _fast_aldc in bytecodes.hpp then >> > Zero won't work correctly without this patch. >> >> Ok, that change is in hs19 and thus OpenJDK6 already: >> >> $ hg log -R ../../jdk6/hotspot -k 6939203 >> changeset: 1805:136b78722a08 >> parent: 1795:49fac4acd688 >> user: jrose >> date: Wed Jun 09 18:50:45 2010 -0700 >> summary: 6939203: JSR 292 needs method handle constants >> >> I'm still wary that the fix is untested, but my main worry (that >> it fixed a newer change that wasn't in hs20) is alleviated. >> >> If Zero is broken without this, it needs to go in the 1.9 (hs19 >> non-default), 1.10 (hs19 default, hs20 non-default) and HEAD (hs20 >> default, hs19 non-default) branches of IcedTea6. > > If it really is in there (ie bytecodes.hpp contains _fast_aldc) then > removing the ARM interpreter rewrite will cause the VM to instantly > abort. > > Removal of the ARM interpreter rewrite is not necessary for this fix > to work, but it'd be nice if it doesn't break other stuff. The fact > this bug has persisted for so long is because the ARM interpreter > code has hidden it. > > 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 the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Thu Mar 31 11:24:41 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 31 Mar 2011 19:24:41 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20110330123530.GD8648@redhat.com> <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> <20110331092125.GA3884@redhat.com> <20110331172645.GE3884@redhat.com> Message-ID: <20110331182441.GD6143@rivendell.middle-earth.co.uk> On 19:20 Thu 31 Mar , Dr Andrew John Hughes wrote: > Errr... what ARM interpreter rewrite? > > On 31/03/2011, Gary Benson wrote: > > Dr Andrew John Hughes wrote: > >> On 31/03/2011, Gary Benson wrote: > >> > Ok, I looked a little further into 3. The root cause was this: > >> > > >> > changeset: 1611:136b78722a08 > >> > user: jrose > >> > date: Wed Jun 09 18:50:45 2010 -0700 > >> > summary: 6939203: JSR 292 needs method handle constants > >> > > >> > It two new internal instructions, _fast_aldc and _fast_aldc_w, but > >> > it added them *before* _return_register_finalizer, which broke the > >> > instructions table in bytecodeInterpreter.cpp. It meant that when > >> > the C++ interpreter saw _return_register_finalizer it would > >> > execute opc_default, which should have thrown an error but for the > >> > piece of the ARM interpreter which hid the error by rewriting the > >> > instruction to a plain _return. I didn't see it before because I > >> > was doing debug builds, and the C++ interpreter only uses the > >> > instructions table for product builds. > >> > > >> > The bottom line is, if you see _fast_aldc in bytecodes.hpp then > >> > Zero won't work correctly without this patch. > >> > >> Ok, that change is in hs19 and thus OpenJDK6 already: > >> > >> $ hg log -R ../../jdk6/hotspot -k 6939203 > >> changeset: 1805:136b78722a08 > >> parent: 1795:49fac4acd688 > >> user: jrose > >> date: Wed Jun 09 18:50:45 2010 -0700 > >> summary: 6939203: JSR 292 needs method handle constants > >> > >> I'm still wary that the fix is untested, but my main worry (that > >> it fixed a newer change that wasn't in hs20) is alleviated. > >> > >> If Zero is broken without this, it needs to go in the 1.9 (hs19 > >> non-default), 1.10 (hs19 default, hs20 non-default) and HEAD (hs20 > >> default, hs19 non-default) branches of IcedTea6. > > > > If it really is in there (ie bytecodes.hpp contains _fast_aldc) then > > removing the ARM interpreter rewrite will cause the VM to instantly > > abort. > > > > Removal of the ARM interpreter rewrite is not necessary for this fix > > to work, but it'd be nice if it doesn't break other stuff. The fact > > this bug has persisted for so long is because the ARM interpreter > > code has hidden it. > > > > Cheers, > > Gary > > > > -- > > http://gbenson.net/ > > Sorry for the top-post; stupid broken Gmail client... Didn't realise I had this mail in my RH inbox too. -- 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 tom.rodriguez at oracle.com Thu Mar 31 12:41:14 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 12:41:14 -0700 Subject: possible CMS problem with C2 Message-ID: While looking at the code we generate for a simple program I noticed that we were eliminating card marks with CMS in a illegal fashion. For this simple program: public class test { static Object a1; static Object a2; static Object a3; public static void main(String[] args) { a1 = args; a2 = args; a3 = args; } } we generate this: 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 000 SAVE R_SP,-72,R_SP 004 SET precise klass test: 0x00843a50:Constant:exact *,R_L0 !ptr 00c + SET 0xf92d4000,R_L2 !ptr 010 + STW R_I0,[R_L0 + #352] ! ptr ! Field test.a3 014 + STW R_I0,[R_L0 + #348] ! ptr ! Field test.a2 018 + SRL R_L0,#9,R_L1 ! Cast ptr R_L0 to int and shift 01c STW R_I0,[R_L0 + #344] ! ptr ! Field test.a1 020 + STB #0,[R_L2 + R_L1] ! CMS card-mark byte 0 024 SETHI #PollAddr,L0 ! Load Polling address LDUW [L0],G0 !Poll for Safepointing RET RESTORE 034 + ! return 034 which happens to be ok because the STB happens last but we don't actually have enough dependences to ensure that we get this schedule. We emit 3 separate StoreCMs for each field references and each one has a dependence on the store that it covers. What's going wrong is that we're allowing StoreCM to participate in the the store elimination in StoreNode::Ideal so we end up with this: 45 StoreP === 5 7 44 10 [[ 16 50 ]] @precise klass test: 0x00843a50:Constant:exact+352 *, name=a3, idx=6; Memory: @precise klass test: 0 x00843a50:Constant:exact+352 *, name=a3, idx=6; !jvms: test::main @ bci:9 36 StoreP === 5 7 35 10 [[ 16 ]] @precise klass test: 0x00843a50:Constant:exact+348 *, name=a2, idx=5; Memory: @precise klass test: 0x008 43a50:Constant:exact+348 *, name=a2, idx=5; !jvms: test::main @ bci:5 25 StoreP === 5 7 24 10 [[ 16 ]] @precise klass test: 0x00843a50:Constant:exact+344 *, name=a1, idx=4; Memory: @precise klass test: 0x008 43a50:Constant:exact+344 *, name=a1, idx=4; !jvms: test::main @ bci:1 50 StoreCM === 5 7 31 23 45 [[ 16 ]] @rawptr:BotPTR, idx=Raw; Memory: @rawptr:BotPTR, idx=Raw; !jvms: test::main @ bci:9 The store to a3 has a StoreCM and it has killed the StoreCMs for a1 and a2 but it doesn't have a dependence on it. Since the slices are independent the a3 operations could be scheduled before the store to a1 and a2. It may be that this is rare in practice and/or the local schedule tends to put the StoreCM last but it's clearly wrong. G1 is safe from this because the StoreCMs are never close enough to be eliminated. It's easy to fix but it might hurt CMS performance a bit. It could also be done safely if the StoreCM could have dependences on multiple stores but since it's not using normal precedence edges I'm not sure how this would be implemented. Does this sound like any issues that have been seen in the past? tom From tom.rodriguez at oracle.com Thu Mar 31 13:17:08 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 13:17:08 -0700 Subject: review(XS) 7032696: Fix for 7029152 broke VM In-Reply-To: <4D94B11E.4020907@oracle.com> References: <4D93F0A1.7040509@oracle.com> <4D94B11E.4020907@oracle.com> Message-ID: <080AA43B-C688-401E-A85A-34ED59F5880B@oracle.com> Ok. tom On Mar 31, 2011, at 9:51 AM, Vladimir Kozlov wrote: > I updated webrev. As John pointed me, Ideal() should return 'this' when memory is updated. I also added a band-aid for one iteration loops problem which causes the second failure in the bug report. I have RFE 7004555 to fix it. > > Vladimir > > Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/7032696/webrev >> Fixed: 7032696: Fix for 7029152 broke VM >> StrIntrinsicNode::Ideal() should not optimize memory during Parse. >> Tested with full CTW. From vladimir.kozlov at oracle.com Thu Mar 31 13:23:17 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Mar 2011 13:23:17 -0700 Subject: review(XS) 7032696: Fix for 7029152 broke VM In-Reply-To: <080AA43B-C688-401E-A85A-34ED59F5880B@oracle.com> References: <4D93F0A1.7040509@oracle.com> <4D94B11E.4020907@oracle.com> <080AA43B-C688-401E-A85A-34ED59F5880B@oracle.com> Message-ID: <4D94E2B5.9060703@oracle.com> thank you, Tom Vladimir Tom Rodriguez wrote: > Ok. > > tom > > On Mar 31, 2011, at 9:51 AM, Vladimir Kozlov wrote: > >> I updated webrev. As John pointed me, Ideal() should return 'this' when memory is updated. I also added a band-aid for one iteration loops problem which causes the second failure in the bug report. I have RFE 7004555 to fix it. >> >> Vladimir >> >> Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7032696/webrev >>> Fixed: 7032696: Fix for 7029152 broke VM >>> StrIntrinsicNode::Ideal() should not optimize memory during Parse. >>> Tested with full CTW. > From y.s.ramakrishna at oracle.com Thu Mar 31 13:52:30 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Thu, 31 Mar 2011 13:52:30 -0700 Subject: possible CMS problem with C2 In-Reply-To: References: Message-ID: <4D94E98E.1010806@oracle.com> Hi Tom -- On 03/31/11 12:41, Tom Rodriguez wrote: > While looking at the code we generate for a simple program I noticed that we were eliminating card marks with CMS in a illegal fashion. For this simple program: > > public class test { > static Object a1; > static Object a2; > static Object a3; > public static void main(String[] args) { > a1 = args; > a2 = args; > a3 = args; > } > } > > we generate this: > > 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 > 000 SAVE R_SP,-72,R_SP > 004 SET precise klass test: 0x00843a50:Constant:exact *,R_L0 !ptr > 00c + SET 0xf92d4000,R_L2 !ptr > 010 + STW R_I0,[R_L0 + #352] ! ptr ! Field test.a3 > 014 + STW R_I0,[R_L0 + #348] ! ptr ! Field test.a2 > 018 + SRL R_L0,#9,R_L1 ! Cast ptr R_L0 to int and shift > 01c STW R_I0,[R_L0 + #344] ! ptr ! Field test.a1 > 020 + STB #0,[R_L2 + R_L1] ! CMS card-mark byte 0 > 024 SETHI #PollAddr,L0 ! Load Polling address > LDUW [L0],G0 !Poll for Safepointing > RET > RESTORE > 034 + ! return > 034 > > which happens to be ok because the STB happens last but we don't actually have enough dependences to ensure that we get this schedule. We emit 3 separate StoreCMs for each field references and each one has a dependence on the store that it covers. What's going wrong is that we're allowing StoreCM to participate in the the store elimination in StoreNode::Ideal so we end up with this: > > 45 StoreP === 5 7 44 10 [[ 16 50 ]] @precise klass test: 0x00843a50:Constant:exact+352 *, name=a3, idx=6; Memory: @precise klass test: 0 > x00843a50:Constant:exact+352 *, name=a3, idx=6; !jvms: test::main @ bci:9 > 36 StoreP === 5 7 35 10 [[ 16 ]] @precise klass test: 0x00843a50:Constant:exact+348 *, name=a2, idx=5; Memory: @precise klass test: 0x008 > 43a50:Constant:exact+348 *, name=a2, idx=5; !jvms: test::main @ bci:5 > 25 StoreP === 5 7 24 10 [[ 16 ]] @precise klass test: 0x00843a50:Constant:exact+344 *, name=a1, idx=4; Memory: @precise klass test: 0x008 > 43a50:Constant:exact+344 *, name=a1, idx=4; !jvms: test::main @ bci:1 > 50 StoreCM === 5 7 31 23 45 [[ 16 ]] @rawptr:BotPTR, idx=Raw; Memory: @rawptr:BotPTR, idx=Raw; !jvms: test::main @ bci:9 > > The store to a3 has a StoreCM and it has killed the StoreCMs for a1 and a2 but it doesn't have a dependence on it. Since the slices are independent the a3 operations could be scheduled before the store to a1 and a2. It may be that this is rare in practice and/or the local schedule tends to put the StoreCM last but it's clearly wrong. G1 is safe from this because the StoreCMs are never close enough to be eliminated. > > It's easy to fix but it might hurt CMS performance a bit. It could also be done safely if the StoreCM could have dependences on multiple stores but since it's not using normal precedence edges I'm not sure how this would be implemented. > > Does this sound like any issues that have been seen in the past? If it's been seen in the past, it has never been identified as stemming from this kind of optimization / missing dependencies. I have heard people (Vladimir, Igor, John Cuthbertson) express the lack of confidence in the existence of sufficient dependencies in some of the card-mark eliminations before. There was a time way back when Mike Paleczny and Ross Knippel had fixed issues stemming from illegal (for CMS) elision of card-marks in the case of CMS, and we had also taken care to add some missing ones in the runtime for perm objects, but this one is new to me. Yes, please fix this; even though i imagine this will be rare because (1) such scheduling may be rare (2) it's only when this intersects with precleaning that this would manifest, and if CMS collections are infrequent, the error will be rare (3) the lack of a card-mark for the elided/rescheduled stores may be masked by a different store to an adjacent object, making an actual crash rarer still. But still, thanks for finding the issue and fixing it! It would be interesting to see how much of a difference in performance the new previously missing dependencies will make to real codes/workloads. -- ramki > > tom From vladimir.kozlov at oracle.com Thu Mar 31 14:03:44 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Mar 2011 14:03:44 -0700 Subject: possible CMS problem with C2 In-Reply-To: <4D94E98E.1010806@oracle.com> References: <4D94E98E.1010806@oracle.com> Message-ID: <4D94EC30.9030301@oracle.com> Tom, Why it is matter when we mark card for this object? There is no safepoint in between. Could you or Ramki explain? Thanks, Vladimir Y. S. Ramakrishna wrote: > Hi Tom -- > > On 03/31/11 12:41, Tom Rodriguez wrote: >> While looking at the code we generate for a simple program I noticed >> that we were eliminating card marks with CMS in a illegal fashion. >> For this simple program: >> >> public class test { >> static Object a1; >> static Object a2; >> static Object a3; >> public static void main(String[] args) { >> a1 = args; >> a2 = args; >> a3 = args; >> } >> } >> >> we generate this: >> >> 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 >> 000 SAVE R_SP,-72,R_SP >> 004 SET precise klass test: 0x00843a50:Constant:exact >> *,R_L0 !ptr >> 00c + SET 0xf92d4000,R_L2 !ptr >> 010 + STW R_I0,[R_L0 + #352] ! ptr ! Field test.a3 >> 014 + STW R_I0,[R_L0 + #348] ! ptr ! Field test.a2 >> 018 + SRL R_L0,#9,R_L1 ! Cast ptr R_L0 to int and shift >> 01c STW R_I0,[R_L0 + #344] ! ptr ! Field test.a1 >> 020 + STB #0,[R_L2 + R_L1] ! CMS card-mark byte 0 >> 024 SETHI #PollAddr,L0 ! Load Polling address >> LDUW [L0],G0 !Poll for Safepointing >> RET >> RESTORE >> 034 + ! return >> 034 >> >> which happens to be ok because the STB happens last but we don't >> actually have enough dependences to ensure that we get this schedule. >> We emit 3 separate StoreCMs for each field references and each one has >> a dependence on the store that it covers. What's going wrong is that >> we're allowing StoreCM to participate in the the store elimination in >> StoreNode::Ideal so we end up with this: >> >> 45 StoreP === 5 7 44 10 [[ 16 50 ]] @precise klass test: >> 0x00843a50:Constant:exact+352 *, name=a3, idx=6; Memory: @precise >> klass test: 0 >> x00843a50:Constant:exact+352 *, name=a3, idx=6; !jvms: test::main @ bci:9 >> 36 StoreP === 5 7 35 10 [[ 16 ]] @precise klass test: >> 0x00843a50:Constant:exact+348 *, name=a2, idx=5; Memory: @precise >> klass test: 0x008 >> 43a50:Constant:exact+348 *, name=a2, idx=5; !jvms: test::main @ bci:5 >> 25 StoreP === 5 7 24 10 [[ 16 ]] @precise klass test: >> 0x00843a50:Constant:exact+344 *, name=a1, idx=4; Memory: @precise >> klass test: 0x008 >> 43a50:Constant:exact+344 *, name=a1, idx=4; !jvms: test::main @ bci:1 >> 50 StoreCM === 5 7 31 23 45 [[ 16 ]] @rawptr:BotPTR, >> idx=Raw; Memory: @rawptr:BotPTR, idx=Raw; !jvms: test::main @ bci:9 >> >> The store to a3 has a StoreCM and it has killed the StoreCMs for a1 >> and a2 but it doesn't have a dependence on it. Since the slices are >> independent the a3 operations could be scheduled before the store to >> a1 and a2. It may be that this is rare in practice and/or the local >> schedule tends to put the StoreCM last but it's clearly wrong. G1 is >> safe from this because the StoreCMs are never close enough to be >> eliminated. >> >> It's easy to fix but it might hurt CMS performance a bit. It could >> also be done safely if the StoreCM could have dependences on multiple >> stores but since it's not using normal precedence edges I'm not sure >> how this would be implemented. >> >> Does this sound like any issues that have been seen in the past? > > If it's been seen in the past, it has never been identified > as stemming from this kind of optimization / missing dependencies. > I have heard people (Vladimir, Igor, John Cuthbertson) express the lack of > confidence in the existence of sufficient dependencies in some of the > card-mark eliminations before. > > There was a time way back when Mike Paleczny and Ross Knippel > had fixed issues stemming from illegal (for CMS) elision of card-marks > in the case of CMS, and we had also taken care to add some > missing ones in the runtime for perm objects, but this > one is new to me. > > Yes, please fix this; even though i imagine this will be rare > because (1) such scheduling may be rare (2) it's only when this > intersects with precleaning that this would manifest, and if > CMS collections are infrequent, the error will be rare (3) the > lack of a card-mark for the elided/rescheduled stores may be > masked by a different store to an adjacent object, making an > actual crash rarer still. But still, thanks for finding the > issue and fixing it! It would be interesting to see how much > of a difference in performance the new previously missing > dependencies will make to real codes/workloads. > > -- ramki > >> >> tom From tom.rodriguez at oracle.com Thu Mar 31 14:17:19 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 14:17:19 -0700 Subject: possible CMS problem with C2 In-Reply-To: <4D94EC30.9030301@oracle.com> References: <4D94E98E.1010806@oracle.com> <4D94EC30.9030301@oracle.com> Message-ID: On Mar 31, 2011, at 2:03 PM, Vladimir Kozlov wrote: > Tom, > > Why it is matter when we mark card for this object? There is no safepoint in between. Could you or Ramki explain? Scanning is done concurrently with CMS so it's required that if you see a dirty card that you have also seen all updates within that card so the card update most follow the store. Otherwise you'd never know if you are done with that card. G1 has the same requirement. tom > > Thanks, > Vladimir > > Y. S. Ramakrishna wrote: >> Hi Tom -- >> On 03/31/11 12:41, Tom Rodriguez wrote: >>> While looking at the code we generate for a simple program I noticed that we were eliminating card marks with CMS in a illegal fashion. For this simple program: >>> >>> public class test { >>> static Object a1; >>> static Object a2; >>> static Object a3; >>> public static void main(String[] args) { >>> a1 = args; >>> a2 = args; >>> a3 = args; >>> } >>> } >>> >>> we generate this: >>> >>> 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 >>> 000 SAVE R_SP,-72,R_SP >>> 004 SET precise klass test: 0x00843a50:Constant:exact *,R_L0 !ptr >>> 00c + SET 0xf92d4000,R_L2 !ptr >>> 010 + STW R_I0,[R_L0 + #352] ! ptr ! Field test.a3 >>> 014 + STW R_I0,[R_L0 + #348] ! ptr ! Field test.a2 >>> 018 + SRL R_L0,#9,R_L1 ! Cast ptr R_L0 to int and shift >>> 01c STW R_I0,[R_L0 + #344] ! ptr ! Field test.a1 >>> 020 + STB #0,[R_L2 + R_L1] ! CMS card-mark byte 0 >>> 024 SETHI #PollAddr,L0 ! Load Polling address >>> LDUW [L0],G0 !Poll for Safepointing >>> RET >>> RESTORE >>> 034 + ! return >>> 034 >>> >>> which happens to be ok because the STB happens last but we don't actually have enough dependences to ensure that we get this schedule. We emit 3 separate StoreCMs for each field references and each one has a dependence on the store that it covers. What's going wrong is that we're allowing StoreCM to participate in the the store elimination in StoreNode::Ideal so we end up with this: >>> >>> 45 StoreP === 5 7 44 10 [[ 16 50 ]] @precise klass test: 0x00843a50:Constant:exact+352 *, name=a3, idx=6; Memory: @precise klass test: 0 >>> x00843a50:Constant:exact+352 *, name=a3, idx=6; !jvms: test::main @ bci:9 >>> 36 StoreP === 5 7 35 10 [[ 16 ]] @precise klass test: 0x00843a50:Constant:exact+348 *, name=a2, idx=5; Memory: @precise klass test: 0x008 >>> 43a50:Constant:exact+348 *, name=a2, idx=5; !jvms: test::main @ bci:5 >>> 25 StoreP === 5 7 24 10 [[ 16 ]] @precise klass test: 0x00843a50:Constant:exact+344 *, name=a1, idx=4; Memory: @precise klass test: 0x008 >>> 43a50:Constant:exact+344 *, name=a1, idx=4; !jvms: test::main @ bci:1 >>> 50 StoreCM === 5 7 31 23 45 [[ 16 ]] @rawptr:BotPTR, idx=Raw; Memory: @rawptr:BotPTR, idx=Raw; !jvms: test::main @ bci:9 >>> >>> The store to a3 has a StoreCM and it has killed the StoreCMs for a1 and a2 but it doesn't have a dependence on it. Since the slices are independent the a3 operations could be scheduled before the store to a1 and a2. It may be that this is rare in practice and/or the local schedule tends to put the StoreCM last but it's clearly wrong. G1 is safe from this because the StoreCMs are never close enough to be eliminated. >>> >>> It's easy to fix but it might hurt CMS performance a bit. It could also be done safely if the StoreCM could have dependences on multiple stores but since it's not using normal precedence edges I'm not sure how this would be implemented. >>> >>> Does this sound like any issues that have been seen in the past? >> If it's been seen in the past, it has never been identified >> as stemming from this kind of optimization / missing dependencies. >> I have heard people (Vladimir, Igor, John Cuthbertson) express the lack of >> confidence in the existence of sufficient dependencies in some of the >> card-mark eliminations before. >> There was a time way back when Mike Paleczny and Ross Knippel >> had fixed issues stemming from illegal (for CMS) elision of card-marks >> in the case of CMS, and we had also taken care to add some >> missing ones in the runtime for perm objects, but this >> one is new to me. >> Yes, please fix this; even though i imagine this will be rare >> because (1) such scheduling may be rare (2) it's only when this >> intersects with precleaning that this would manifest, and if >> CMS collections are infrequent, the error will be rare (3) the >> lack of a card-mark for the elided/rescheduled stores may be >> masked by a different store to an adjacent object, making an >> actual crash rarer still. But still, thanks for finding the >> issue and fixing it! It would be interesting to see how much >> of a difference in performance the new previously missing >> dependencies will make to real codes/workloads. >> -- ramki >>> >>> tom From tom.rodriguez at oracle.com Thu Mar 31 14:17:52 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 14:17:52 -0700 Subject: possible CMS problem with C2 In-Reply-To: <4D94E98E.1010806@oracle.com> References: <4D94E98E.1010806@oracle.com> Message-ID: <4811D9BE-A164-4F5D-B291-F9EAE89ED032@oracle.com> I filed 7032963 for this. tom On Mar 31, 2011, at 1:52 PM, Y. S. Ramakrishna wrote: > Hi Tom -- > > On 03/31/11 12:41, Tom Rodriguez wrote: >> While looking at the code we generate for a simple program I noticed that we were eliminating card marks with CMS in a illegal fashion. For this simple program: >> public class test { >> static Object a1; >> static Object a2; >> static Object a3; >> public static void main(String[] args) { >> a1 = args; >> a2 = args; >> a3 = args; >> } >> } >> we generate this: >> 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 >> 000 SAVE R_SP,-72,R_SP >> 004 SET precise klass test: 0x00843a50:Constant:exact *,R_L0 !ptr >> 00c + SET 0xf92d4000,R_L2 !ptr >> 010 + STW R_I0,[R_L0 + #352] ! ptr ! Field test.a3 >> 014 + STW R_I0,[R_L0 + #348] ! ptr ! Field test.a2 >> 018 + SRL R_L0,#9,R_L1 ! Cast ptr R_L0 to int and shift >> 01c STW R_I0,[R_L0 + #344] ! ptr ! Field test.a1 >> 020 + STB #0,[R_L2 + R_L1] ! CMS card-mark byte 0 >> 024 SETHI #PollAddr,L0 ! Load Polling address >> LDUW [L0],G0 !Poll for Safepointing >> RET >> RESTORE >> 034 + ! return >> 034 >> which happens to be ok because the STB happens last but we don't actually have enough dependences to ensure that we get this schedule. We emit 3 separate StoreCMs for each field references and each one has a dependence on the store that it covers. What's going wrong is that we're allowing StoreCM to participate in the the store elimination in StoreNode::Ideal so we end up with this: >> 45 StoreP === 5 7 44 10 [[ 16 50 ]] @precise klass test: 0x00843a50:Constant:exact+352 *, name=a3, idx=6; Memory: @precise klass test: 0 >> x00843a50:Constant:exact+352 *, name=a3, idx=6; !jvms: test::main @ bci:9 >> 36 StoreP === 5 7 35 10 [[ 16 ]] @precise klass test: 0x00843a50:Constant:exact+348 *, name=a2, idx=5; Memory: @precise klass test: 0x008 >> 43a50:Constant:exact+348 *, name=a2, idx=5; !jvms: test::main @ bci:5 >> 25 StoreP === 5 7 24 10 [[ 16 ]] @precise klass test: 0x00843a50:Constant:exact+344 *, name=a1, idx=4; Memory: @precise klass test: 0x008 >> 43a50:Constant:exact+344 *, name=a1, idx=4; !jvms: test::main @ bci:1 >> 50 StoreCM === 5 7 31 23 45 [[ 16 ]] @rawptr:BotPTR, idx=Raw; Memory: @rawptr:BotPTR, idx=Raw; !jvms: test::main @ bci:9 >> The store to a3 has a StoreCM and it has killed the StoreCMs for a1 and a2 but it doesn't have a dependence on it. Since the slices are independent the a3 operations could be scheduled before the store to a1 and a2. It may be that this is rare in practice and/or the local schedule tends to put the StoreCM last but it's clearly wrong. G1 is safe from this because the StoreCMs are never close enough to be eliminated. >> It's easy to fix but it might hurt CMS performance a bit. It could also be done safely if the StoreCM could have dependences on multiple stores but since it's not using normal precedence edges I'm not sure how this would be implemented. >> Does this sound like any issues that have been seen in the past? > > If it's been seen in the past, it has never been identified > as stemming from this kind of optimization / missing dependencies. > I have heard people (Vladimir, Igor, John Cuthbertson) express the lack of > confidence in the existence of sufficient dependencies in some of the > card-mark eliminations before. > > There was a time way back when Mike Paleczny and Ross Knippel > had fixed issues stemming from illegal (for CMS) elision of card-marks > in the case of CMS, and we had also taken care to add some > missing ones in the runtime for perm objects, but this > one is new to me. > > Yes, please fix this; even though i imagine this will be rare > because (1) such scheduling may be rare (2) it's only when this > intersects with precleaning that this would manifest, and if > CMS collections are infrequent, the error will be rare (3) the > lack of a card-mark for the elided/rescheduled stores may be > masked by a different store to an adjacent object, making an > actual crash rarer still. But still, thanks for finding the > issue and fixing it! It would be interesting to see how much > of a difference in performance the new previously missing > dependencies will make to real codes/workloads. > > -- ramki > >> tom From vladimir.kozlov at oracle.com Thu Mar 31 14:22:30 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Mar 2011 14:22:30 -0700 Subject: possible CMS problem with C2 In-Reply-To: References: <4D94E98E.1010806@oracle.com> <4D94EC30.9030301@oracle.com> Message-ID: <4D94F096.4020606@oracle.com> Got it. thanks, Vladimir Tom Rodriguez wrote: > On Mar 31, 2011, at 2:03 PM, Vladimir Kozlov wrote: > >> Tom, >> >> Why it is matter when we mark card for this object? There is no safepoint in between. Could you or Ramki explain? > > Scanning is done concurrently with CMS so it's required that if you see a dirty card that you have also seen all updates within that card so the card update most follow the store. Otherwise you'd never know if you are done with that card. G1 has the same requirement. > > tom > >> Thanks, >> Vladimir >> >> Y. S. Ramakrishna wrote: >>> Hi Tom -- >>> On 03/31/11 12:41, Tom Rodriguez wrote: >>>> While looking at the code we generate for a simple program I noticed that we were eliminating card marks with CMS in a illegal fashion. For this simple program: >>>> >>>> public class test { >>>> static Object a1; >>>> static Object a2; >>>> static Object a3; >>>> public static void main(String[] args) { >>>> a1 = args; >>>> a2 = args; >>>> a3 = args; >>>> } >>>> } >>>> >>>> we generate this: >>>> >>>> 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 >>>> 000 SAVE R_SP,-72,R_SP >>>> 004 SET precise klass test: 0x00843a50:Constant:exact *,R_L0 !ptr >>>> 00c + SET 0xf92d4000,R_L2 !ptr >>>> 010 + STW R_I0,[R_L0 + #352] ! ptr ! Field test.a3 >>>> 014 + STW R_I0,[R_L0 + #348] ! ptr ! Field test.a2 >>>> 018 + SRL R_L0,#9,R_L1 ! Cast ptr R_L0 to int and shift >>>> 01c STW R_I0,[R_L0 + #344] ! ptr ! Field test.a1 >>>> 020 + STB #0,[R_L2 + R_L1] ! CMS card-mark byte 0 >>>> 024 SETHI #PollAddr,L0 ! Load Polling address >>>> LDUW [L0],G0 !Poll for Safepointing >>>> RET >>>> RESTORE >>>> 034 + ! return >>>> 034 >>>> >>>> which happens to be ok because the STB happens last but we don't actually have enough dependences to ensure that we get this schedule. We emit 3 separate StoreCMs for each field references and each one has a dependence on the store that it covers. What's going wrong is that we're allowing StoreCM to participate in the the store elimination in StoreNode::Ideal so we end up with this: >>>> >>>> 45 StoreP === 5 7 44 10 [[ 16 50 ]] @precise klass test: 0x00843a50:Constant:exact+352 *, name=a3, idx=6; Memory: @precise klass test: 0 >>>> x00843a50:Constant:exact+352 *, name=a3, idx=6; !jvms: test::main @ bci:9 >>>> 36 StoreP === 5 7 35 10 [[ 16 ]] @precise klass test: 0x00843a50:Constant:exact+348 *, name=a2, idx=5; Memory: @precise klass test: 0x008 >>>> 43a50:Constant:exact+348 *, name=a2, idx=5; !jvms: test::main @ bci:5 >>>> 25 StoreP === 5 7 24 10 [[ 16 ]] @precise klass test: 0x00843a50:Constant:exact+344 *, name=a1, idx=4; Memory: @precise klass test: 0x008 >>>> 43a50:Constant:exact+344 *, name=a1, idx=4; !jvms: test::main @ bci:1 >>>> 50 StoreCM === 5 7 31 23 45 [[ 16 ]] @rawptr:BotPTR, idx=Raw; Memory: @rawptr:BotPTR, idx=Raw; !jvms: test::main @ bci:9 >>>> >>>> The store to a3 has a StoreCM and it has killed the StoreCMs for a1 and a2 but it doesn't have a dependence on it. Since the slices are independent the a3 operations could be scheduled before the store to a1 and a2. It may be that this is rare in practice and/or the local schedule tends to put the StoreCM last but it's clearly wrong. G1 is safe from this because the StoreCMs are never close enough to be eliminated. >>>> >>>> It's easy to fix but it might hurt CMS performance a bit. It could also be done safely if the StoreCM could have dependences on multiple stores but since it's not using normal precedence edges I'm not sure how this would be implemented. >>>> >>>> Does this sound like any issues that have been seen in the past? >>> If it's been seen in the past, it has never been identified >>> as stemming from this kind of optimization / missing dependencies. >>> I have heard people (Vladimir, Igor, John Cuthbertson) express the lack of >>> confidence in the existence of sufficient dependencies in some of the >>> card-mark eliminations before. >>> There was a time way back when Mike Paleczny and Ross Knippel >>> had fixed issues stemming from illegal (for CMS) elision of card-marks >>> in the case of CMS, and we had also taken care to add some >>> missing ones in the runtime for perm objects, but this >>> one is new to me. >>> Yes, please fix this; even though i imagine this will be rare >>> because (1) such scheduling may be rare (2) it's only when this >>> intersects with precleaning that this would manifest, and if >>> CMS collections are infrequent, the error will be rare (3) the >>> lack of a card-mark for the elided/rescheduled stores may be >>> masked by a different store to an adjacent object, making an >>> actual crash rarer still. But still, thanks for finding the >>> issue and fixing it! It would be interesting to see how much >>> of a difference in performance the new previously missing >>> dependencies will make to real codes/workloads. >>> -- ramki >>>> tom > From vladimir.kozlov at oracle.com Thu Mar 31 14:38:33 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Mar 2011 14:38:33 -0700 Subject: Request for reviews (XS): 7032849: 7022998 changes broke hs_err compile task print Message-ID: <4D94F459.4020600@oracle.com> http://cr.openjdk.java.net/~kvn/7032849/webrev Fixed 7032849: 7022998 changes broke hs_err compile task print Initialize the time stamp on ostream used for dumping. From tom.rodriguez at oracle.com Thu Mar 31 15:00:30 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 15:00:30 -0700 Subject: Request for reviews (XS): 7032849: 7022998 changes broke hs_err compile task print In-Reply-To: <4D94F459.4020600@oracle.com> References: <4D94F459.4020600@oracle.com> Message-ID: Don't you just want to update it to the current time with update()? tom On Mar 31, 2011, at 2:38 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7032849/webrev > > Fixed 7032849: 7022998 changes broke hs_err compile task print > > Initialize the time stamp on ostream used for dumping. From vladimir.kozlov at oracle.com Thu Mar 31 15:18:02 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Mar 2011 15:18:02 -0700 Subject: Request for reviews (XS): 7032849: 7022998 changes broke hs_err compile task print In-Reply-To: References: <4D94F459.4020600@oracle.com> Message-ID: <4D94FD9A.8060105@oracle.com> No. 0 (I can use 1) means it is from the start of VM. This value (_counter) is subtracted from elapsed time in TimeStamp::milliseconds() used by print compilation: void TimeStamp::update_to(jlong ticks) { _counter = ticks; if (_counter == 0) _counter = 1; assert(is_updated(), "must not look clear"); } jlong TimeStamp::milliseconds() const { assert(is_updated(), "must not be clear"); jlong new_count = os::elapsed_counter(); jlong count = new_count - _counter; Vladimir Tom Rodriguez wrote: > Don't you just want to update it to the current time with update()? > > tom > > On Mar 31, 2011, at 2:38 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7032849/webrev >> >> Fixed 7032849: 7022998 changes broke hs_err compile task print >> >> Initialize the time stamp on ostream used for dumping. > From vladimir.kozlov at oracle.com Thu Mar 31 15:27:03 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 31 Mar 2011 22:27:03 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7032696: Fix for 7029152 broke VM Message-ID: <20110331222706.3B7D947693@hg.openjdk.java.net> Changeset: cb162b348743 Author: kvn Date: 2011-03-31 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cb162b348743 7032696: Fix for 7029152 broke VM Summary: StrIntrinsicNode::Ideal() should not optimize memory during Parse. Reviewed-by: jrose, never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/memnode.cpp From tom.rodriguez at oracle.com Thu Mar 31 15:55:31 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 15:55:31 -0700 Subject: Request for reviews (XS): 7032849: 7022998 changes broke hs_err compile task print In-Reply-To: <4D94FD9A.8060105@oracle.com> References: <4D94F459.4020600@oracle.com> <4D94FD9A.8060105@oracle.com> Message-ID: <0DE881F4-CB13-4685-AA7D-C0CC5D221A0A@oracle.com> Oh ok. That's an interesting API. ;) Why do we allows time stamps that aren't relative to the start of the VM? The ostream constructor should always init _stamp using update_to(0) which would allow us to get rid of all the places where we explicitly reset the stamp to 0: /Users/never/ws/hs/src/share/vm/utilities/ostream.cpp:733: tty->time_stamp().update_to(1); /Users/never/ws/hs/src/share/vm/utilities/ostream.cpp:748: gclog->time_stamp().update_to(tty->time_stamp().ticks()); /Users/never/ws/hs/src/share/vm/utilities/xmlstream.cpp:55: _out->time_stamp().update_to(1); Actually why doesn't TimeStamp just default to that? Anyone who wants something different should have to ask for it. Anyway, that's probably a cleanup for another day. Maybe your change should be part of staticBufferStream instead? tom On Mar 31, 2011, at 3:18 PM, Vladimir Kozlov wrote: > No. 0 (I can use 1) means it is from the start of VM. This value (_counter) is subtracted from elapsed time in TimeStamp::milliseconds() used by print compilation: > > void TimeStamp::update_to(jlong ticks) { > _counter = ticks; > if (_counter == 0) _counter = 1; > assert(is_updated(), "must not look clear"); > } > > jlong TimeStamp::milliseconds() const { > assert(is_updated(), "must not be clear"); > > jlong new_count = os::elapsed_counter(); > jlong count = new_count - _counter; > > Vladimir > > Tom Rodriguez wrote: >> Don't you just want to update it to the current time with update()? >> tom >> On Mar 31, 2011, at 2:38 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7032849/webrev >>> >>> Fixed 7032849: 7022998 changes broke hs_err compile task print >>> >>> Initialize the time stamp on ostream used for dumping. From vladimir.kozlov at oracle.com Thu Mar 31 16:22:38 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Mar 2011 16:22:38 -0700 Subject: Request for reviews (XS): 7032849: 7022998 changes broke hs_err compile task print In-Reply-To: <0DE881F4-CB13-4685-AA7D-C0CC5D221A0A@oracle.com> References: <4D94F459.4020600@oracle.com> <4D94FD9A.8060105@oracle.com> <0DE881F4-CB13-4685-AA7D-C0CC5D221A0A@oracle.com> Message-ID: <4D950CBE.5060406@oracle.com> Agree. I moved the fix into staticBufferStream constructor. http://cr.openjdk.java.net/~kvn/7032849/webrev Vladimir Tom Rodriguez wrote: > Oh ok. That's an interesting API. ;) Why do we allows time stamps that aren't relative to the start of the VM? The ostream constructor should always init _stamp using update_to(0) which would allow us to get rid of all the places where we explicitly reset the stamp to 0: > > /Users/never/ws/hs/src/share/vm/utilities/ostream.cpp:733: tty->time_stamp().update_to(1); > /Users/never/ws/hs/src/share/vm/utilities/ostream.cpp:748: gclog->time_stamp().update_to(tty->time_stamp().ticks()); > /Users/never/ws/hs/src/share/vm/utilities/xmlstream.cpp:55: _out->time_stamp().update_to(1); > > Actually why doesn't TimeStamp just default to that? Anyone who wants something different should have to ask for it. Anyway, that's probably a cleanup for another day. > > Maybe your change should be part of staticBufferStream instead? > > tom > > On Mar 31, 2011, at 3:18 PM, Vladimir Kozlov wrote: > >> No. 0 (I can use 1) means it is from the start of VM. This value (_counter) is subtracted from elapsed time in TimeStamp::milliseconds() used by print compilation: >> >> void TimeStamp::update_to(jlong ticks) { >> _counter = ticks; >> if (_counter == 0) _counter = 1; >> assert(is_updated(), "must not look clear"); >> } >> >> jlong TimeStamp::milliseconds() const { >> assert(is_updated(), "must not be clear"); >> >> jlong new_count = os::elapsed_counter(); >> jlong count = new_count - _counter; >> >> Vladimir >> >> Tom Rodriguez wrote: >>> Don't you just want to update it to the current time with update()? >>> tom >>> On Mar 31, 2011, at 2:38 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7032849/webrev >>>> >>>> Fixed 7032849: 7022998 changes broke hs_err compile task print >>>> >>>> Initialize the time stamp on ostream used for dumping. > From tom.rodriguez at oracle.com Thu Mar 31 16:53:04 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 16:53:04 -0700 Subject: Request for reviews (XS): 7032849: 7022998 changes broke hs_err compile task print In-Reply-To: <4D950CBE.5060406@oracle.com> References: <4D94F459.4020600@oracle.com> <4D94FD9A.8060105@oracle.com> <0DE881F4-CB13-4685-AA7D-C0CC5D221A0A@oracle.com> <4D950CBE.5060406@oracle.com> Message-ID: <3A19D7BB-0995-4789-9393-FBFCA82A2948@oracle.com> Looks good. tom On Mar 31, 2011, at 4:22 PM, Vladimir Kozlov wrote: > Agree. I moved the fix into staticBufferStream constructor. > > http://cr.openjdk.java.net/~kvn/7032849/webrev > > Vladimir > > Tom Rodriguez wrote: >> Oh ok. That's an interesting API. ;) Why do we allows time stamps that aren't relative to the start of the VM? The ostream constructor should always init _stamp using update_to(0) which would allow us to get rid of all the places where we explicitly reset the stamp to 0: >> /Users/never/ws/hs/src/share/vm/utilities/ostream.cpp:733: tty->time_stamp().update_to(1); >> /Users/never/ws/hs/src/share/vm/utilities/ostream.cpp:748: gclog->time_stamp().update_to(tty->time_stamp().ticks()); >> /Users/never/ws/hs/src/share/vm/utilities/xmlstream.cpp:55: _out->time_stamp().update_to(1); >> Actually why doesn't TimeStamp just default to that? Anyone who wants something different should have to ask for it. Anyway, that's probably a cleanup for another day. >> Maybe your change should be part of staticBufferStream instead? >> tom >> On Mar 31, 2011, at 3:18 PM, Vladimir Kozlov wrote: >>> No. 0 (I can use 1) means it is from the start of VM. This value (_counter) is subtracted from elapsed time in TimeStamp::milliseconds() used by print compilation: >>> >>> void TimeStamp::update_to(jlong ticks) { >>> _counter = ticks; >>> if (_counter == 0) _counter = 1; >>> assert(is_updated(), "must not look clear"); >>> } >>> >>> jlong TimeStamp::milliseconds() const { >>> assert(is_updated(), "must not be clear"); >>> >>> jlong new_count = os::elapsed_counter(); >>> jlong count = new_count - _counter; >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> Don't you just want to update it to the current time with update()? >>>> tom >>>> On Mar 31, 2011, at 2:38 PM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7032849/webrev >>>>> >>>>> Fixed 7032849: 7022998 changes broke hs_err compile task print >>>>> >>>>> Initialize the time stamp on ostream used for dumping. From vladimir.kozlov at oracle.com Thu Mar 31 16:53:30 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Mar 2011 16:53:30 -0700 Subject: Request for reviews (XS): 7032849: 7022998 changes broke hs_err compile task print In-Reply-To: <3A19D7BB-0995-4789-9393-FBFCA82A2948@oracle.com> References: <4D94F459.4020600@oracle.com> <4D94FD9A.8060105@oracle.com> <0DE881F4-CB13-4685-AA7D-C0CC5D221A0A@oracle.com> <4D950CBE.5060406@oracle.com> <3A19D7BB-0995-4789-9393-FBFCA82A2948@oracle.com> Message-ID: <4D9513FA.9090700@oracle.com> Thanks Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Mar 31, 2011, at 4:22 PM, Vladimir Kozlov wrote: > >> Agree. I moved the fix into staticBufferStream constructor. >> >> http://cr.openjdk.java.net/~kvn/7032849/webrev >> >> Vladimir >> >> Tom Rodriguez wrote: >>> Oh ok. That's an interesting API. ;) Why do we allows time stamps that aren't relative to the start of the VM? The ostream constructor should always init _stamp using update_to(0) which would allow us to get rid of all the places where we explicitly reset the stamp to 0: >>> /Users/never/ws/hs/src/share/vm/utilities/ostream.cpp:733: tty->time_stamp().update_to(1); >>> /Users/never/ws/hs/src/share/vm/utilities/ostream.cpp:748: gclog->time_stamp().update_to(tty->time_stamp().ticks()); >>> /Users/never/ws/hs/src/share/vm/utilities/xmlstream.cpp:55: _out->time_stamp().update_to(1); >>> Actually why doesn't TimeStamp just default to that? Anyone who wants something different should have to ask for it. Anyway, that's probably a cleanup for another day. >>> Maybe your change should be part of staticBufferStream instead? >>> tom >>> On Mar 31, 2011, at 3:18 PM, Vladimir Kozlov wrote: >>>> No. 0 (I can use 1) means it is from the start of VM. This value (_counter) is subtracted from elapsed time in TimeStamp::milliseconds() used by print compilation: >>>> >>>> void TimeStamp::update_to(jlong ticks) { >>>> _counter = ticks; >>>> if (_counter == 0) _counter = 1; >>>> assert(is_updated(), "must not look clear"); >>>> } >>>> >>>> jlong TimeStamp::milliseconds() const { >>>> assert(is_updated(), "must not be clear"); >>>> >>>> jlong new_count = os::elapsed_counter(); >>>> jlong count = new_count - _counter; >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> Don't you just want to update it to the current time with update()? >>>>> tom >>>>> On Mar 31, 2011, at 2:38 PM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/7032849/webrev >>>>>> >>>>>> Fixed 7032849: 7022998 changes broke hs_err compile task print >>>>>> >>>>>> Initialize the time stamp on ostream used for dumping. > From tom.rodriguez at oracle.com Thu Mar 31 17:28:53 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 01 Apr 2011 00:28:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20110401002857.835DA47699@hg.openjdk.java.net> Changeset: 352622fd140a Author: never Date: 2011-03-31 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/352622fd140a 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests Reviewed-by: kvn, kamg, jcoomes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/memory/dump.cpp Changeset: 2a5104162671 Author: never Date: 2011-03-31 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2a5104162671 Merge From tom.rodriguez at oracle.com Thu Mar 31 17:57:41 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 17:57:41 -0700 Subject: possible CMS problem with C2 In-Reply-To: <4811D9BE-A164-4F5D-B291-F9EAE89ED032@oracle.com> References: <4D94E98E.1010806@oracle.com> <4811D9BE-A164-4F5D-B291-F9EAE89ED032@oracle.com> Message-ID: To close the loop on this, here's at least one case of this I found with a little awkery and inspection: 00c B1: # B151 B2 <- BLOCK HEAD IS JUNK Freq: 1 00c ! stack bang SAVE R_SP,-112,R_SP 018 SET 0xf92d4000,R_L1 !ptr 01c + STW R_I3,[R_I0 + #20] ! ptr ! Field spec/benchmarks/_213_javac/FieldDefinition.documentation 020 SRL R_I0,#9,R_L0 ! Cast ptr R_I0 to int and shift 024 + STB #0,[R_L1 + R_L0] ! CMS card-mark byte 0 028 LDUW [R_SP + #188],R_L0 ! spill 02c + STW R_L0,[R_I0 + #28] ! ptr ! Field spec/benchmarks/_213_javac/FieldDefinition.value 030 LDUW [R_SP + #184],R_L1 ! spill 034 + STW R_L1,[R_I0 + #24] ! ptr ! Field spec/benchmarks/_213_javac/FieldDefinition.exp 038 LDUW [R_SP + #176],R_L7 ! spill 03c + STW R_L7,[R_I0 + #36] ! ptr ! Field spec/benchmarks/_213_javac/FieldDefinition.name 040 + STW R_I5,[R_I0 + #16] ! ptr ! Field spec/benchmarks/_213_javac/FieldDefinition.type 044 + STW R_I4,[R_I0 + #12] ! Field spec/benchmarks/_213_javac/FieldDefinition.modifiers 048 STW R_I2,[R_SP + #96] ! spill 04c + STW R_I2,[R_I0 + #32] ! ptr ! Field spec/benchmarks/_213_javac/FieldDefinition.clazz 050 STW R_I1,[R_SP + #92] ! spill 054 + STW R_I1,[R_I0 + #8] ! Field spec/benchmarks/_213_javac/FieldDefinition.where 058 LDUW [R_I5 + #8],R_L1 ! int ! Field spec/benchmarks/_213_javac/Type.typeCode 05c NullCheck R_I5 If we don't eliminate any of the StoreCMs this code looks like this: 00c B1: # B152 B2 <- BLOCK HEAD IS JUNK Freq: 1 00c ! stack bang SAVE R_SP,-112,R_SP 018 SET 0xb53d2000,R_L2 !ptr 01c + SRL R_I0,#9,R_L1 ! Cast ptr R_I0 to int and shift 020 STW R_I2,[R_I0 + #32] ! ptr ! Field spec/benchmarks/_213_javac/FieldDefinition.clazz 024 + ADD R_L2,R_L1,R_L0 028 STW R_I5,[R_I0 + #16] ! ptr ! Field spec/benchmarks/_213_javac/FieldDefinition.type 02c + STB #0,[R_L0] ! CMS card-mark byte 0 030 LDUW [R_SP + #176],R_L3 ! spill 034 + STW R_L3,[R_I0 + #36] ! ptr ! Field spec/benchmarks/_213_javac/FieldDefinition.name 038 + STB #0,[R_L0] ! CMS card-mark byte 0 03c LDUW [R_SP + #184],R_L2 ! spill 040 + STW R_L2,[R_I0 + #24] ! ptr ! Field spec/benchmarks/_213_javac/FieldDefinition.exp 044 + STB #0,[R_L0] ! CMS card-mark byte 0 048 LDUW [R_SP + #188],R_L1 ! spill 04c + STW R_L1,[R_I0 + #28] ! ptr ! Field spec/benchmarks/_213_javac/FieldDefinition.value 050 + STB #0,[R_L0] ! CMS card-mark byte 0 054 + STW R_I3,[R_I0 + #20] ! ptr ! Field spec/benchmarks/_213_javac/FieldDefinition.documentation 058 + STB #0,[R_L0] ! CMS card-mark byte 0 05c + STB #0,[R_L0] ! CMS card-mark byte 0 060 STW R_I1,[R_SP + #92] ! spill 064 + STW R_I1,[R_I0 + #8] ! Field spec/benchmarks/_213_javac/FieldDefinition.where 068 STW R_I2,[R_SP + #96] ! spill 06c + STW R_I4,[R_I0 + #12] ! Field spec/benchmarks/_213_javac/FieldDefinition.modifiers 070 LDUW [R_I5 + #8],R_L1 ! int ! Field spec/benchmarks/_213_javac/Type.typeCode 074 NullCheck R_I5 So it definitely occurs in the wild. I think we're going to need to optimize away the redundant ones since they appear to be fairly common. II see how to do it during final_graph_reshape so that we can accumulate the dependences and place the single one where it should go. tom On Mar 31, 2011, at 2:17 PM, Tom Rodriguez wrote: > I filed 7032963 for this. > > tom > > On Mar 31, 2011, at 1:52 PM, Y. S. Ramakrishna wrote: > >> Hi Tom -- >> >> On 03/31/11 12:41, Tom Rodriguez wrote: >>> While looking at the code we generate for a simple program I noticed that we were eliminating card marks with CMS in a illegal fashion. For this simple program: >>> public class test { >>> static Object a1; >>> static Object a2; >>> static Object a3; >>> public static void main(String[] args) { >>> a1 = args; >>> a2 = args; >>> a3 = args; >>> } >>> } >>> we generate this: >>> 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 >>> 000 SAVE R_SP,-72,R_SP >>> 004 SET precise klass test: 0x00843a50:Constant:exact *,R_L0 !ptr >>> 00c + SET 0xf92d4000,R_L2 !ptr >>> 010 + STW R_I0,[R_L0 + #352] ! ptr ! Field test.a3 >>> 014 + STW R_I0,[R_L0 + #348] ! ptr ! Field test.a2 >>> 018 + SRL R_L0,#9,R_L1 ! Cast ptr R_L0 to int and shift >>> 01c STW R_I0,[R_L0 + #344] ! ptr ! Field test.a1 >>> 020 + STB #0,[R_L2 + R_L1] ! CMS card-mark byte 0 >>> 024 SETHI #PollAddr,L0 ! Load Polling address >>> LDUW [L0],G0 !Poll for Safepointing >>> RET >>> RESTORE >>> 034 + ! return >>> 034 >>> which happens to be ok because the STB happens last but we don't actually have enough dependences to ensure that we get this schedule. We emit 3 separate StoreCMs for each field references and each one has a dependence on the store that it covers. What's going wrong is that we're allowing StoreCM to participate in the the store elimination in StoreNode::Ideal so we end up with this: >>> 45 StoreP === 5 7 44 10 [[ 16 50 ]] @precise klass test: 0x00843a50:Constant:exact+352 *, name=a3, idx=6; Memory: @precise klass test: 0 >>> x00843a50:Constant:exact+352 *, name=a3, idx=6; !jvms: test::main @ bci:9 >>> 36 StoreP === 5 7 35 10 [[ 16 ]] @precise klass test: 0x00843a50:Constant:exact+348 *, name=a2, idx=5; Memory: @precise klass test: 0x008 >>> 43a50:Constant:exact+348 *, name=a2, idx=5; !jvms: test::main @ bci:5 >>> 25 StoreP === 5 7 24 10 [[ 16 ]] @precise klass test: 0x00843a50:Constant:exact+344 *, name=a1, idx=4; Memory: @precise klass test: 0x008 >>> 43a50:Constant:exact+344 *, name=a1, idx=4; !jvms: test::main @ bci:1 >>> 50 StoreCM === 5 7 31 23 45 [[ 16 ]] @rawptr:BotPTR, idx=Raw; Memory: @rawptr:BotPTR, idx=Raw; !jvms: test::main @ bci:9 >>> The store to a3 has a StoreCM and it has killed the StoreCMs for a1 and a2 but it doesn't have a dependence on it. Since the slices are independent the a3 operations could be scheduled before the store to a1 and a2. It may be that this is rare in practice and/or the local schedule tends to put the StoreCM last but it's clearly wrong. G1 is safe from this because the StoreCMs are never close enough to be eliminated. >>> It's easy to fix but it might hurt CMS performance a bit. It could also be done safely if the StoreCM could have dependences on multiple stores but since it's not using normal precedence edges I'm not sure how this would be implemented. >>> Does this sound like any issues that have been seen in the past? >> >> If it's been seen in the past, it has never been identified >> as stemming from this kind of optimization / missing dependencies. >> I have heard people (Vladimir, Igor, John Cuthbertson) express the lack of >> confidence in the existence of sufficient dependencies in some of the >> card-mark eliminations before. >> >> There was a time way back when Mike Paleczny and Ross Knippel >> had fixed issues stemming from illegal (for CMS) elision of card-marks >> in the case of CMS, and we had also taken care to add some >> missing ones in the runtime for perm objects, but this >> one is new to me. >> >> Yes, please fix this; even though i imagine this will be rare >> because (1) such scheduling may be rare (2) it's only when this >> intersects with precleaning that this would manifest, and if >> CMS collections are infrequent, the error will be rare (3) the >> lack of a card-mark for the elided/rescheduled stores may be >> masked by a different store to an adjacent object, making an >> actual crash rarer still. But still, thanks for finding the >> issue and fixing it! It would be interesting to see how much >> of a difference in performance the new previously missing >> dependencies will make to real codes/workloads. >> >> -- ramki >> >>> tom > From vladimir.kozlov at oracle.com Thu Mar 31 19:31:30 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 01 Apr 2011 02:31:30 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7032849: 7022998 changes broke hs_err compile task print Message-ID: <20110401023141.75FDF476A3@hg.openjdk.java.net> Changeset: 8010c8c623ac Author: kvn Date: 2011-03-31 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8010c8c623ac 7032849: 7022998 changes broke hs_err compile task print Summary: Initialize the time stamp on ostream used for hs_err dumping. Reviewed-by: never ! src/share/vm/utilities/ostream.cpp From tom.rodriguez at oracle.com Thu Mar 31 20:57:57 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 20:57:57 -0700 Subject: review (XS) for 7026957: assert(type2aelembytes(store->as_Mem()->memory_type(), true) == 1 << shift->in(2)->get_int()) failed Message-ID: <3F0BE80A-3ECE-4409-9748-8B98E423183D@oracle.com> http://cr.openjdk.java.net/~never/7026957 7026957: assert(type2aelembytes(store->as_Mem()->memory_type(), true) == 1 << shift->in(2)->get_int()) failed Reviewed-by: The assert that checks that the shift matches the store size should really be a test and bailout if they don't match. Tested with failing test from report. From john.r.rose at oracle.com Thu Mar 31 21:08:00 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 31 Mar 2011 21:08:00 -0700 Subject: review (XS) for 7026957: assert(type2aelembytes(store->as_Mem()->memory_type(), true) == 1 << shift->in(2)->get_int()) failed In-Reply-To: <3F0BE80A-3ECE-4409-9748-8B98E423183D@oracle.com> References: <3F0BE80A-3ECE-4409-9748-8B98E423183D@oracle.com> Message-ID: Reviewed. (Consider parenthesizing the "<<" expression.) -- John On Mar 31, 2011, at 8:57 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7026957 > > 7026957: assert(type2aelembytes(store->as_Mem()->memory_type(), true) == 1 << shift->in(2)->get_int()) failed > Reviewed-by: > > The assert that checks that the shift matches the store size should > really be a test and bailout if they don't match. Tested with failing > test from report. > From vladimir.kozlov at oracle.com Thu Mar 31 21:10:28 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Mar 2011 21:10:28 -0700 Subject: review (XS) for 7026957: assert(type2aelembytes(store->as_Mem()->memory_type(), true) == 1 << shift->in(2)->get_int()) failed In-Reply-To: <3F0BE80A-3ECE-4409-9748-8B98E423183D@oracle.com> References: <3F0BE80A-3ECE-4409-9748-8B98E423183D@oracle.com> Message-ID: <4D955034.7030008@oracle.com> Good. Vladimir On 3/31/11 8:57 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7026957 > > 7026957: assert(type2aelembytes(store->as_Mem()->memory_type(), true) == 1<< shift->in(2)->get_int()) failed > Reviewed-by: > > The assert that checks that the shift matches the store size should > really be a test and bailout if they don't match. Tested with failing > test from report. > From tom.rodriguez at oracle.com Thu Mar 31 21:18:02 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 21:18:02 -0700 Subject: review (XS) for 7026957: assert(type2aelembytes(store->as_Mem()->memory_type(), true) == 1 << shift->in(2)->get_int()) failed In-Reply-To: References: <3F0BE80A-3ECE-4409-9748-8B98E423183D@oracle.com> Message-ID: On Mar 31, 2011, at 9:08 PM, John Rose wrote: > Reviewed. (Consider parenthesizing the "<<" expression.) -- John Done. Thanks John and Vladimir. tom > > On Mar 31, 2011, at 8:57 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/7026957 >> >> 7026957: assert(type2aelembytes(store->as_Mem()->memory_type(), true) == 1 << shift->in(2)->get_int()) failed >> Reviewed-by: >> >> The assert that checks that the shift matches the store size should >> really be a test and bailout if they don't match. Tested with failing >> test from report. >> >