From vladimir.x.ivanov at oracle.com Wed Aug 1 09:23:41 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 01 Aug 2012 20:23:41 +0400 Subject: Request for reviews (S): 7188227: VM should recognize M-series SPARC In-Reply-To: <5018ADBA.6020203@oracle.com> References: <5018ADBA.6020203@oracle.com> Message-ID: <5019580D.8030305@oracle.com> Looks good. Best regards, Vladimir Ivanov On 08/01/12 08:16, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7188227/webrev > > 7188227: VM should recognize M-series SPARC > > Hotspot tunes some flags and settings (number of GC threads and other) > for T-series SPARCs. VM checks kstat data to recognize T-series but it > does not check for M-series for which the same tuning should be done. > > Thanks, > Vladimir From roland.westrelin at oracle.com Wed Aug 1 09:52:29 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 01 Aug 2012 09:52:29 -0700 Subject: Request for reviews (S): 7188227: VM should recognize M-series SPARC In-Reply-To: <5018ADBA.6020203@oracle.com> References: <5018ADBA.6020203@oracle.com> Message-ID: <877gtih7w2.fsf@oracle.com> > http://cr.openjdk.java.net/~kvn/7188227/webrev > > 7188227: VM should recognize M-series SPARC It looks good. Roland. From vladimir.kozlov at oracle.com Wed Aug 1 10:00:00 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Aug 2012 10:00:00 -0700 Subject: Request for reviews (S): 7188227: VM should recognize M-series SPARC In-Reply-To: <5019580D.8030305@oracle.com> References: <5018ADBA.6020203@oracle.com> <5019580D.8030305@oracle.com> Message-ID: <50196090.90203@oracle.com> Thank you, Vladimir Vladimir Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 08/01/12 08:16, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/7188227/webrev >> >> 7188227: VM should recognize M-series SPARC >> >> Hotspot tunes some flags and settings (number of GC threads and other) >> for T-series SPARCs. VM checks kstat data to recognize T-series but it >> does not check for M-series for which the same tuning should be done. >> >> Thanks, >> Vladimir From vladimir.kozlov at oracle.com Wed Aug 1 10:00:32 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Aug 2012 10:00:32 -0700 Subject: Request for reviews (S): 7188227: VM should recognize M-series SPARC In-Reply-To: <877gtih7w2.fsf@oracle.com> References: <5018ADBA.6020203@oracle.com> <877gtih7w2.fsf@oracle.com> Message-ID: <501960B0.8030209@oracle.com> Thank you, Roland Vladimir Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/7188227/webrev >> >> 7188227: VM should recognize M-series SPARC > > It looks good. > > Roland. From christian.thalinger at oracle.com Wed Aug 1 13:14:18 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 1 Aug 2012 13:14:18 -0700 Subject: Request for reviews (XXS): 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 Message-ID: <0CC8BB47-F52A-4673-BF0D-30AB3535D5F1@oracle.com> [This was already reviewed for 7187290 but I missed this change while integrating.] http://cr.openjdk.java.net/~twisti/7188276 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 Reviewed-by: kvn, jrose src/share/vm/opto/doCall.cpp From vladimir.kozlov at oracle.com Wed Aug 1 14:06:45 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Aug 2012 14:06:45 -0700 Subject: Request for reviews (XXS): 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 In-Reply-To: <0CC8BB47-F52A-4673-BF0D-30AB3535D5F1@oracle.com> References: <0CC8BB47-F52A-4673-BF0D-30AB3535D5F1@oracle.com> Message-ID: <50199A65.2030203@oracle.com> Looks good. Vladimir Christian Thalinger wrote: > [This was already reviewed for 7187290 but I missed this change while integrating.] > > http://cr.openjdk.java.net/~twisti/7188276 > > 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 > Reviewed-by: kvn, jrose > > src/share/vm/opto/doCall.cpp > From christian.thalinger at oracle.com Wed Aug 1 17:44:02 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 02 Aug 2012 00:44:02 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20120802004408.E7FE647300@hg.openjdk.java.net> Changeset: 8cb110fd7627 Author: kvn Date: 2012-08-01 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8cb110fd7627 7188227: VM should recognize M-series SPARC Summary: Check kstat data for SPARC-M. Reviewed-by: roland ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: b72784e722ff Author: twisti Date: 2012-08-01 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b72784e722ff 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 Reviewed-by: kvn, jrose ! src/share/vm/opto/doCall.cpp From roland.westrelin at oracle.com Thu Aug 2 12:32:28 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 02 Aug 2012 12:32:28 -0700 Subject: Request for reviews (L): 6340864: Implement vectorization optimizations in hotspot-server In-Reply-To: <5011EC16.4030900@oracle.com> References: <5009DF55.2050708@oracle.com> <5011EC16.4030900@oracle.com> Message-ID: <876291qecz.fsf@oracle.com> > I updated webrev: > > http://cr.openjdk.java.net/~kvn/6340864/webrev.01 AFAICT, it looks good. Roland. From vladimir.kozlov at oracle.com Thu Aug 2 12:32:52 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 02 Aug 2012 12:32:52 -0700 Subject: Request for reviews (L): 6340864: Implement vectorization optimizations in hotspot-server In-Reply-To: <876291qecz.fsf@oracle.com> References: <5009DF55.2050708@oracle.com> <5011EC16.4030900@oracle.com> <876291qecz.fsf@oracle.com> Message-ID: <501AD5E4.3000300@oracle.com> Thank you, Roland Vladimir Roland Westrelin wrote: >> I updated webrev: >> >> http://cr.openjdk.java.net/~kvn/6340864/webrev.01 > > AFAICT, it looks good. > > Roland. From chunt at salesforce.com Fri Aug 3 10:28:38 2012 From: chunt at salesforce.com (Charlie Hunt) Date: Fri, 3 Aug 2012 10:28:38 -0700 Subject: CompileThreshold & BackEdgeThreshold question(s) Message-ID: <5E3C9B25-796D-4848-87E0-A56C218EE2AA@salesforce.com> Could someone offer a "10,000 ft" explanation of CompileThreshold and BackEdgeThreshold, how they relate to each other, (if at all), and how they differ? For the Server compiler, of course. ;-) thanks, charlie From vitalyd at gmail.com Fri Aug 3 11:07:44 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 3 Aug 2012 14:07:44 -0400 Subject: CompileThreshold & BackEdgeThreshold question(s) In-Reply-To: <5E3C9B25-796D-4848-87E0-A56C218EE2AA@salesforce.com> References: <5E3C9B25-796D-4848-87E0-A56C218EE2AA@salesforce.com> Message-ID: Hi Charlie, CompileThreshold (10k by default for server) is the number of times a method must be hit before it's considered "hot" and thus eligible for compilation. BackedgeThreshold is similar, but counts loop counters. In other words, a method may only get hit a few times but if it runs a long loop (many iterations), the loop becomes eligible for on-stack replacement compilation (OSR). That's how I understand it, but I'm sure someone can correct me or provide more details. Vitaly Sent from my phone On Aug 3, 2012 1:29 PM, "Charlie Hunt" wrote: > Could someone offer a "10,000 ft" explanation of CompileThreshold and > BackEdgeThreshold, how they relate to each other, (if at all), and how they > differ? > > For the Server compiler, of course. ;-) > > thanks, > > charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120803/20deaef9/attachment.html From vladimir.kozlov at oracle.com Fri Aug 3 11:28:24 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Aug 2012 11:28:24 -0700 Subject: CompileThreshold & BackEdgeThreshold question(s) In-Reply-To: <5E3C9B25-796D-4848-87E0-A56C218EE2AA@salesforce.com> References: <5E3C9B25-796D-4848-87E0-A56C218EE2AA@salesforce.com> Message-ID: <501C1848.4010202@oracle.com> Backedge threshold (back branch count limit) is used to trigger OSR compilation for hot loops. BackEdgeThreshold is dead flag, was never used. Tiered compilation uses Tier*BackEdgeThreshold flags in jdk 7update and jdk8 and they are set in globals*.hpp files. In non tiered case we use OnStackReplacePercentage to calculate backedge count limit for OSR compilation: InterpreterBackwardBranchLimit = (CompileThreshold * OnStackReplacePercentage) / 100; and define_pd_global(intx, OnStackReplacePercentage, 140); so InterpreterBackwardBranchLimit = 14000 when CompileThreshold = 10000. Vladimir Charlie Hunt wrote: > Could someone offer a "10,000 ft" explanation of CompileThreshold and BackEdgeThreshold, how they relate to each other, (if at all), and how they differ? > > For the Server compiler, of course. ;-) > > thanks, > > charlie From iggy.veresov at gmail.com Fri Aug 3 11:34:43 2012 From: iggy.veresov at gmail.com (Igor Veresov) Date: Fri, 3 Aug 2012 11:34:43 -0700 Subject: CompileThreshold & BackEdgeThreshold question(s) In-Reply-To: <5E3C9B25-796D-4848-87E0-A56C218EE2AA@salesforce.com> References: <5E3C9B25-796D-4848-87E0-A56C218EE2AA@salesforce.com> Message-ID: <554DF37B-71E5-485A-901C-601D82AE8650@gmail.com> Each method has two counters in a methodOop. One that counts invocations (method entries), the other one counts the number of backward branches taken within this method (loop iterations). For non-tiered policy a method is compiled if the inv_count > CompileThreshold, an OSR will happen if inv_count + bb_count > BackEdgeThreshold on a backward branch. Profiling will start at 33% of these values (InterpreterProfilePercentage). Also keep in mind that for non-tiered policy all these counters are decayed at each safepoint. So there's an invocation frequency limit below which a method will never get compiled. For tiered it's a bit more complicated. ;) igor On Aug 3, 2012, at 10:28 AM, Charlie Hunt wrote: > Could someone offer a "10,000 ft" explanation of CompileThreshold and BackEdgeThreshold, how they relate to each other, (if at all), and how they differ? > > For the Server compiler, of course. ;-) > > thanks, > > charlie From kirk at kodewerk.com Fri Aug 3 11:38:35 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 3 Aug 2012 20:38:35 +0200 Subject: CompileThreshold & BackEdgeThreshold question(s) In-Reply-To: <554DF37B-71E5-485A-901C-601D82AE8650@gmail.com> References: <5E3C9B25-796D-4848-87E0-A56C218EE2AA@salesforce.com> <554DF37B-71E5-485A-901C-601D82AE8650@gmail.com> Message-ID: <73A6A094-3AA9-4580-84AB-B679C2946D13@kodewerk.com> On 2012-08-03, at 8:34 PM, Igor Veresov wrote: > Each method has two counters in a methodOop. One that counts invocations (method entries), the other one counts the number of backward branches taken within this method (loop iterations). what happens if the method contains two (or more) loops? They both use the same counter? I guess for an OSR it doesn't matter which loop is holding things up. > For non-tiered policy a method is compiled if the inv_count > CompileThreshold, an OSR will happen if inv_count + bb_count > BackEdgeThreshold on a backward branch. Profiling will start at 33% of these values (InterpreterProfilePercentage). > > Also keep in mind that for non-tiered policy all these counters are decayed at each safepoint. So there's an invocation frequency limit below which a method will never get compiled. > > For tiered it's a bit more complicated. ;) oh then don't stop there.... :-) Kirk From rednaxelafx at gmail.com Fri Aug 3 11:53:34 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sat, 4 Aug 2012 02:53:34 +0800 Subject: CompileThreshold & BackEdgeThreshold question(s) In-Reply-To: <73A6A094-3AA9-4580-84AB-B679C2946D13@kodewerk.com> References: <5E3C9B25-796D-4848-87E0-A56C218EE2AA@salesforce.com> <554DF37B-71E5-485A-901C-601D82AE8650@gmail.com> <73A6A094-3AA9-4580-84AB-B679C2946D13@kodewerk.com> Message-ID: On Sat, Aug 4, 2012 at 2:38 AM, Kirk Pepperdine wrote: > > On 2012-08-03, at 8:34 PM, Igor Veresov wrote: > > > Each method has two counters in a methodOop. One that counts invocations > (method entries), the other one counts the number of backward branches > taken within this method (loop iterations). > > what happens if the method contains two (or more) loops? They both use the > same counter? I guess for an OSR it doesn't matter which loop is holding > things up. > > > For non-tiered policy a method is compiled if the inv_count > > CompileThreshold, an OSR will happen if inv_count + bb_count > > BackEdgeThreshold on a backward branch. Profiling will start at 33% of > these values (InterpreterProfilePercentage). > > > Just a nitpick: Actually for non-tiered policy, a standad compilation is triggered on method entry when inv_count + bb_count >= CompileThreshold (the inv_count is incremented first before checking the sum of the two counters against CompileThreshold). And an OSR is triggered when inv_count + bb_count >= InterpreterBackwardBranchLimit. On non-tiered Server VM, this threshold is calculated from: InterpreterBackwardBranchLimit = (CompileThreshold * (OnStackReplacePercentage - InterpreterProfilePercentage)) / 100; > > Also keep in mind that for non-tiered policy all these counters are > decayed at each safepoint. So there's an invocation frequency limit below > which a method will never get compiled. > > > Yes. But the only real-world cases I've seen that get affected by this behavior are microbenchmarks, especially ones that delibrately trigger GCs (by excessive allocation or by System.gc()). > > For tiered it's a bit more complicated. ;) > > oh then don't stop there.... :-) > It's going to involve a lot of details to explain tiered...can't stay on 10,000 ft for that one :-) Perhaps this would help a little: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/b72784e722ff/src/share/vm/runtime/advancedThresholdPolicy.cpp , line 282. - Kris > > Kirk > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120804/dbe52af2/attachment-0001.html From iggy.veresov at gmail.com Fri Aug 3 11:56:28 2012 From: iggy.veresov at gmail.com (Igor Veresov) Date: Fri, 3 Aug 2012 11:56:28 -0700 Subject: CompileThreshold & BackEdgeThreshold question(s) In-Reply-To: <73A6A094-3AA9-4580-84AB-B679C2946D13@kodewerk.com> References: <5E3C9B25-796D-4848-87E0-A56C218EE2AA@salesforce.com> <554DF37B-71E5-485A-901C-601D82AE8650@gmail.com> <73A6A094-3AA9-4580-84AB-B679C2946D13@kodewerk.com> Message-ID: <8EF0A1C5-3962-40DB-9833-B4AB3C2F05A8@gmail.com> On Aug 3, 2012, at 11:38 AM, Kirk Pepperdine wrote: > > On 2012-08-03, at 8:34 PM, Igor Veresov wrote: > >> Each method has two counters in a methodOop. One that counts invocations (method entries), the other one counts the number of backward branches taken within this method (loop iterations). > > what happens if the method contains two (or more) loops? They both use the same counter? I guess for an OSR it doesn't matter which loop is holding things up. Yup. So, it's actually a bit of a gamble, you can end up with multiple OSR compiles (each of which will only support entry if a method is currently at a specific bci). This is true for the tiered policy too. But there's no lock-free way of doing that differently. > >> For non-tiered policy a method is compiled if the inv_count > CompileThreshold, an OSR will happen if inv_count + bb_count > BackEdgeThreshold on a backward branch. Profiling will start at 33% of these values (InterpreterProfilePercentage). >> Oops, just looked at source, I lied here. Non-tiered will do a normal compiler when inv_count + bb_count > CompileThreshould, so there's also a sum of these counters there. >> Also keep in mind that for non-tiered policy all these counters are decayed at each safepoint. So there's an invocation frequency limit below which a method will never get compiled. >> >> For tiered it's a bit more complicated. ;) > > oh then don't stop there.... :-) That's a lot to type? :) Basically the thresholds are dynamic. And the predicates are more involved. Can I just point to you to a big fat comment at the top of this file, since I've already done the typing once: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/b72784e722ff/src/share/vm/runtime/advancedThresholdPolicy.hpp Also, I'm not sure if it's mentioned in the comments, but tiered doesn't have the counter decay. Instead, there's another subsystem in hotspot now, that is called the "code cache flushing" that would GC methods that haven't been used for a while. igor > > Kirk > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120803/ba5d2469/attachment.html From chunt at salesforce.com Fri Aug 3 12:01:06 2012 From: chunt at salesforce.com (Charlie Hunt) Date: Fri, 3 Aug 2012 12:01:06 -0700 Subject: CompileThreshold & BackEdgeThreshold question(s) In-Reply-To: <8EF0A1C5-3962-40DB-9833-B4AB3C2F05A8@gmail.com> References: <5E3C9B25-796D-4848-87E0-A56C218EE2AA@salesforce.com> <554DF37B-71E5-485A-901C-601D82AE8650@gmail.com> <73A6A094-3AA9-4580-84AB-B679C2946D13@kodewerk.com> <8EF0A1C5-3962-40DB-9833-B4AB3C2F05A8@gmail.com> Message-ID: <44664F55-366A-42EC-A16F-486E9DB0D6EE@salesforce.com> Igor, et.al. Exactly what I was looking for! You just saved me a *lot* of time looking at (and figuring out) compiler code. :-) Much appreciated! charlie ... On Aug 3, 2012, at 1:56 PM, Igor Veresov wrote: On Aug 3, 2012, at 11:38 AM, Kirk Pepperdine wrote: On 2012-08-03, at 8:34 PM, Igor Veresov > wrote: Each method has two counters in a methodOop. One that counts invocations (method entries), the other one counts the number of backward branches taken within this method (loop iterations). what happens if the method contains two (or more) loops? They both use the same counter? I guess for an OSR it doesn't matter which loop is holding things up. Yup. So, it's actually a bit of a gamble, you can end up with multiple OSR compiles (each of which will only support entry if a method is currently at a specific bci). This is true for the tiered policy too. But there's no lock-free way of doing that differently. For non-tiered policy a method is compiled if the inv_count > CompileThreshold, an OSR will happen if inv_count + bb_count > BackEdgeThreshold on a backward branch. Profiling will start at 33% of these values (InterpreterProfilePercentage). Oops, just looked at source, I lied here. Non-tiered will do a normal compiler when inv_count + bb_count > CompileThreshould, so there's also a sum of these counters there. Also keep in mind that for non-tiered policy all these counters are decayed at each safepoint. So there's an invocation frequency limit below which a method will never get compiled. For tiered it's a bit more complicated. ;) oh then don't stop there.... :-) That's a lot to type? :) Basically the thresholds are dynamic. And the predicates are more involved. Can I just point to you to a big fat comment at the top of this file, since I've already done the typing once: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/b72784e722ff/src/share/vm/runtime/advancedThresholdPolicy.hpp Also, I'm not sure if it's mentioned in the comments, but tiered doesn't have the counter decay. Instead, there's another subsystem in hotspot now, that is called the "code cache flushing" that would GC methods that haven't been used for a while. igor Kirk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120803/ef6e0352/attachment.html From kirk at kodewerk.com Fri Aug 3 12:02:32 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 3 Aug 2012 21:02:32 +0200 Subject: CompileThreshold & BackEdgeThreshold question(s) In-Reply-To: <8EF0A1C5-3962-40DB-9833-B4AB3C2F05A8@gmail.com> References: <5E3C9B25-796D-4848-87E0-A56C218EE2AA@salesforce.com> <554DF37B-71E5-485A-901C-601D82AE8650@gmail.com> <73A6A094-3AA9-4580-84AB-B679C2946D13@kodewerk.com> <8EF0A1C5-3962-40DB-9833-B4AB3C2F05A8@gmail.com> Message-ID: <794B9D77-C036-48CA-9177-AA9BF0C7CA28@kodewerk.com> >>> >> >> oh then don't stop there.... :-) > That's a lot to type? :) Basically the thresholds are dynamic. And the predicates are more involved. > > Can I just point to you to a big fat comment at the top of this file, since I've already done the typing once: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/b72784e722ff/src/share/vm/runtime/advancedThresholdPolicy.hpp > > Also, I'm not sure if it's mentioned in the comments, but tiered doesn't have the counter decay. Instead, there's another subsystem in hotspot now, that is called the "code cache flushing" that would GC methods that haven't been used for a while. Thanks for the link.. and I've seen hints of code cache flushing but didn't quite dig into what the actual mechanics or thresholds were. Kirk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120803/b20df1ac/attachment.html From christian.thalinger at oracle.com Fri Aug 3 12:20:42 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 3 Aug 2012 12:20:42 -0700 Subject: Request for reviews (M): 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Message-ID: <105CEFCE-B2FA-4F6F-85CC-583007C82669@oracle.com> http://cr.openjdk.java.net/~twisti/7188911 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: More problems found during nightly testing need to be fixed. hotspot/src/share/vm/interpreter/linkResolver.cpp hotspot/src/share/vm/oops/methodOop.hpp hotspot/src/share/vm/prims/jvm.cpp hotspot/src/share/vm/utilities/exceptions.cpp hotspot/src/share/vm/utilities/exceptions.hpp jdk/src/share/classes/java/lang/invoke/BoundMethodHandle.java From vladimir.kozlov at oracle.com Fri Aug 3 12:45:39 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Aug 2012 12:45:39 -0700 Subject: Request for reviews (M): 7188911: nightly failures after JSR 292 lazy method handle update (round 2) In-Reply-To: <105CEFCE-B2FA-4F6F-85CC-583007C82669@oracle.com> References: <105CEFCE-B2FA-4F6F-85CC-583007C82669@oracle.com> Message-ID: <501C2A63.8000209@oracle.com> Seems good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7188911 > > 7188911: nightly failures after JSR 292 lazy method handle update (round 2) > Reviewed-by: > > More problems found during nightly testing need to be fixed. > > hotspot/src/share/vm/interpreter/linkResolver.cpp > hotspot/src/share/vm/oops/methodOop.hpp > hotspot/src/share/vm/prims/jvm.cpp > hotspot/src/share/vm/utilities/exceptions.cpp > hotspot/src/share/vm/utilities/exceptions.hpp > jdk/src/share/classes/java/lang/invoke/BoundMethodHandle.java > From yumin.qi at oracle.com Mon Aug 6 14:40:14 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Mon, 06 Aug 2012 14:40:14 -0700 Subject: RFR: 6830717: replay of compilations would help with debugging Message-ID: <502039BE.6090108@oracle.com> Hi, Please give your comments of the changes about 6830717: replay of compilations would help with debugging. http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 Sometime jvm crashes in the process of compilation or in compiled method. To reproduce the compilation process in debug JVM is helpful for quickly identifying root cause. To do recompilation, we collect data by using of SA (Serviceability Agent) to extract application and system class data from core file. Those information includes nmethod, methodOop, methodDataOop, instanceKlass and corresponding ci counterparts. With reconfiguring similar (not exactly same) compiling environment as in the core file, try to compile again the failed java methods. contributed by Tom R (never). webrev: http://cr.openjdk.java.net/~minqi/6830717/ Thanks Yumin From roland.westrelin at oracle.com Mon Aug 6 18:29:54 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 06 Aug 2012 18:29:54 -0700 Subject: RFR(S) 7171824: assert(_offset >= 1) failed: illegal call to offset() Message-ID: <87zk67bib1.fsf@oracle.com> http://cr.openjdk.java.net/~roland/7171824/webrev.00/ Global/local value numbering, when it processes a StoreField, must kill every matching LoadField that are stored in the value numbering's hash table. A matching LoadField loads a field that has the same holder and offset (a LoadField is in the hash table only if it has a known offset). In this failure, the StoreField is at an unknown offset (-1) but it has the same holder as a LoadField. The LoadField and the StoreField are not accessed from a class with the same class loader/protection domain. So for the LoadField both holder and offset are known while for the StoreField the holder is known but the offset is set to -1 because the field access is not known to be ok under the protection domain. Given the offset of the StoreField is unknown during value numbering, all LoadFields with the same holder as the StoreField should be killed. Roland. From yumin.qi at oracle.com Mon Aug 6 17:28:40 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Mon, 06 Aug 2012 17:28:40 -0700 Subject: RFR: 6830717: replay of compilations would help with debugging Message-ID: <50206138.8060001@oracle.com> Hi, Please give your comments of the changes about 6830717: replay of compilations would help with debugging. http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 Sometime jvm crashes in the process of compilation or in compiled method. To reproduce the compilation process in debug JVM is helpful for quickly identifying root cause. To do recompilation, we collect data by using of SA (Serviceability Agent) to extract application and system class data from core file. Those information includes nmethod, methodOop, methodDataOop, instanceKlass and corresponding ci counterparts. With reconfiguring similar (not exactly same) compiling environment as in the core file, try to compile again the failed java methods. contributed by Tom R (never). webrev: http://cr.openjdk.java.net/~minqi/6830717/ Thanks Yumin From christian.thalinger at oracle.com Tue Aug 7 13:44:09 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 7 Aug 2012 13:44:09 -0700 Subject: Request for reviews (M): 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Message-ID: <5E30BE9B-9C41-439F-B445-85249C3312EB@oracle.com> http://cr.openjdk.java.net/~twisti/7188911 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: More problems found during nightly testing need to be fixed. hotspot/src/share/vm/classfile/verifier.cpp hotspot/src/share/vm/classfile/vmSymbols.hpp hotspot/src/share/vm/interpreter/linkResolver.cpp hotspot/src/share/vm/oops/methodOop.hpp hotspot/src/share/vm/prims/jvm.cpp hotspot/src/share/vm/prims/methodHandles.cpp hotspot/src/share/vm/prims/nativeLookup.cpp hotspot/src/share/vm/runtime/sharedRuntime.cpp hotspot/src/share/vm/runtime/sharedRuntime.hpp hotspot/src/share/vm/utilities/exceptions.cpp hotspot/src/share/vm/utilities/exceptions.hpp jdk/src/share/classes/java/lang/invoke/BoundMethodHandle.java jdk/src/share/classes/java/lang/invoke/MemberName.java From christian.thalinger at oracle.com Tue Aug 7 22:26:37 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 08 Aug 2012 05:26:37 +0000 Subject: hg: hsx/hotspot-comp/jdk: 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Message-ID: <20120808052702.116CF4740D@hg.openjdk.java.net> Changeset: 64e24cc8e009 Author: twisti Date: 2012-08-07 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/64e24cc8e009 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java From christian.thalinger at oracle.com Tue Aug 7 22:27:12 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 08 Aug 2012 05:27:12 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Message-ID: <20120808052716.E6A504740E@hg.openjdk.java.net> Changeset: 93c71eb28866 Author: twisti Date: 2012-08-07 14:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/93c71eb28866 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp From vladimir.kozlov at oracle.com Wed Aug 8 10:11:31 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 08 Aug 2012 10:11:31 -0700 Subject: RFR: 6830717: replay of compilations would help with debugging In-Reply-To: <502039BE.6090108@oracle.com> References: <502039BE.6090108@oracle.com> Message-ID: <50229DC3.5080004@oracle.com> This looks good. Small note: I don't see skip_Replay variable usage in other places. Yumin, could you add replay to C1 compilations as next step? Thanks, Vladimir yumin.qi at oracle.com wrote: > Hi, > > Please give your comments of the changes about > 6830717: replay of compilations would help with debugging. > http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 > > Sometime jvm crashes in the process of compilation or in compiled > method. To reproduce the compilation process in debug JVM is helpful for > quickly identifying root cause. > To do recompilation, we collect data by using of SA (Serviceability > Agent) to extract application and system class data from core file. > Those information includes nmethod, methodOop, methodDataOop, > instanceKlass and corresponding ci counterparts. > With reconfiguring similar (not exactly same) compiling environment as > in the core file, try to compile again the failed java methods. > > contributed by Tom R (never). webrev: > > http://cr.openjdk.java.net/~minqi/6830717/ > > > Thanks > Yumin From roland.westrelin at oracle.com Wed Aug 8 10:29:29 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 08 Aug 2012 10:29:29 -0700 Subject: RFR: 6830717: replay of compilations would help with debugging In-Reply-To: <502039BE.6090108@oracle.com> References: <502039BE.6090108@oracle.com> Message-ID: <87lihpb8cm.fsf@oracle.com> > Please give your comments of the changes about > 6830717: replay of compilations would help with debugging. > http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 It looks good to me. Roland. From roland.westrelin at oracle.com Thu Aug 9 11:00:58 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 09 Aug 2012 11:00:58 -0700 Subject: review request: 7184394: add intrinsics to use AES instructions In-Reply-To: References: <500451D3.5080802@oracle.com> <5004667C.5020503@oracle.com> <5008930F.8060105@oracle.com> <5011C967.1060304@oracle.com> Message-ID: <877gt8aqsl.fsf@oracle.com> Hi Tom, > http://cr.openjdk.java.net/~tdeneau/aes-intrinsics/webrev.04 > > has been posted which addresses the issues that Vladimir raised. In callGenerator.cpp, this should go away: 966 // Vladimir said to remove this check 967 if (false && kit.stopped()) { 968 // Receiver's null check or other exception. 969 return kit.transfer_exceptions_into_jvms(); 970 } In library_call.cpp, typos: 5784 // the psuedo code we want to emulate with this predicate is: 5811 // we want to an instanceof comparison against the AESCrypt class Also, it looks like this should go away as well: 5840 if (false) { 5841 // src and dest are arrays. 5842 const Type* src_type = src->Value(&_gvn); 5843 const Type* dest_type = dest->Value(&_gvn); 5844 const TypeAryPtr* top_src = src_type->isa_aryptr(); 5845 const TypeAryPtr* top_dest = dest_type->isa_aryptr(); 5846 assert (top_src != NULL && top_src->klass() != NULL 5847 && top_dest != NULL && top_dest->klass() != NULL, "args are strange"); 5848 } Otherwise, I think it'ok to me. Roland. From vladimir.kozlov at oracle.com Thu Aug 9 13:37:38 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Aug 2012 13:37:38 -0700 Subject: RFR(S) 7171824: assert(_offset >= 1) failed: illegal call to offset() In-Reply-To: <87zk67bib1.fsf@oracle.com> References: <87zk67bib1.fsf@oracle.com> Message-ID: <50241F92.8050508@oracle.com> This looks good. Please, coordinate the push with Christian. Thanks, Vladimir Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7171824/webrev.00/ > > Global/local value numbering, when it processes a StoreField, must kill > every matching LoadField that are stored in the value numbering's hash > table. A matching LoadField loads a field that has the same holder and > offset (a LoadField is in the hash table only if it has a known offset). > > In this failure, the StoreField is at an unknown offset (-1) but it has > the same holder as a LoadField. The LoadField and the StoreField are not > accessed from a class with the same class loader/protection domain. So > for the LoadField both holder and offset are known while for the > StoreField the holder is known but the offset is set to -1 because the > field access is not known to be ok under the protection domain. > > Given the offset of the StoreField is unknown during value numbering, > all LoadFields with the same holder as the StoreField should be killed. > > Roland. From christian.thalinger at oracle.com Thu Aug 9 17:48:05 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 10 Aug 2012 00:48:05 +0000 Subject: hg: hsx/hotspot-comp/jdk: 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize Message-ID: <20120810004848.BDA9A47456@hg.openjdk.java.net> Changeset: e1d063685dc8 Author: twisti Date: 2012-08-09 15:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e1d063685dc8 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java From vladimir.kozlov at oracle.com Thu Aug 9 18:34:22 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Aug 2012 18:34:22 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops Message-ID: <5024651E.6040707@oracle.com> http://cr.openjdk.java.net/~kvn/7190310/webrev 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops Add acquire membar after load from Reference.referent field to prevent commoning of loads across safepoint since GC can change its value. Thanks, Vladimir From david.holmes at oracle.com Thu Aug 9 18:52:54 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Aug 2012 11:52:54 +1000 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <5024651E.6040707@oracle.com> References: <5024651E.6040707@oracle.com> Message-ID: <50246976.9040003@oracle.com> On 10/08/2012 11:34 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7190310/webrev > > 7190310: Inlining WeakReference.get(), and hoisting $referent may lead > to non-terminating loops > > Add acquire membar after load from Reference.referent field to prevent > commoning of loads across safepoint since GC can change its value. Wow that was quick! :) My only comment (not being a compiler expert) is that it would appear that we are now inserting read barriers with all GC's not just G1. What kind of impact will that have on performance under the other GC's? Thanks, David > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Aug 9 19:15:11 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Aug 2012 19:15:11 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <50246976.9040003@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> Message-ID: <50246EAF.3000801@oracle.com> Thanks, David pre_barrier() methods don't generate code for other GCs. But I forgot to put UseG1GC guard around "new G1UnsafeGetObjSATBBarrierStub" in c1_LIRGenerator.cpp. Thanks, Vladimir On 8/9/12 6:52 PM, David Holmes wrote: > On 10/08/2012 11:34 AM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/7190310/webrev >> >> 7190310: Inlining WeakReference.get(), and hoisting $referent may lead >> to non-terminating loops >> >> Add acquire membar after load from Reference.referent field to prevent >> commoning of loads across safepoint since GC can change its value. > > Wow that was quick! :) > > My only comment (not being a compiler expert) is that it would appear that we are now inserting read barriers with all > GC's not just G1. What kind of impact will that have on performance under the other GC's? > > Thanks, > David > >> Thanks, >> Vladimir From aleksey.shipilev at oracle.com Thu Aug 9 22:33:23 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 10 Aug 2012 09:33:23 +0400 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <5024651E.6040707@oracle.com> References: <5024651E.6040707@oracle.com> Message-ID: <50249D23.50102@oracle.com> On 08/10/2012 05:34 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7190310/webrev > > 7190310: Inlining WeakReference.get(), and hoisting $referent may lead > to non-terminating loops > > Add acquire membar after load from Reference.referent field to prevent > commoning of loads across safepoint since GC can change its value. Cool! Code looks fine. Let me check the disassembly and the effects for the original testcase. -Aleksey. From aleksey.shipilev at oracle.com Thu Aug 9 23:01:07 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 10 Aug 2012 10:01:07 +0400 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <50249D23.50102@oracle.com> References: <5024651E.6040707@oracle.com> <50249D23.50102@oracle.com> Message-ID: <5024A3A3.5070904@oracle.com> On 08/10/2012 09:33 AM, Aleksey Shipilev wrote: > On 08/10/2012 05:34 AM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/7190310/webrev >> >> 7190310: Inlining WeakReference.get(), and hoisting $referent may lead >> to non-terminating loops >> >> Add acquire membar after load from Reference.referent field to prevent >> commoning of loads across safepoint since GC can change its value. > > Cool! Code looks fine. Let me check the disassembly and the effects for > the original testcase. Confirmed. $referent is not commoned from the busy loop, and the expected behavior is now hapenning in C2. Thanks! -Aleksey. From christian.thalinger at oracle.com Fri Aug 10 09:01:49 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 10 Aug 2012 09:01:49 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <50246EAF.3000801@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> Message-ID: <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> On Aug 9, 2012, at 7:15 PM, Vladimir Kozlov wrote: > Thanks, David > > pre_barrier() methods don't generate code for other GCs. But I forgot to put UseG1GC guard around "new G1UnsafeGetObjSATBBarrierStub" in c1_LIRGenerator.cpp. Did you update the webrev? -- Chris > > Thanks, > Vladimir > > On 8/9/12 6:52 PM, David Holmes wrote: >> On 10/08/2012 11:34 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7190310/webrev >>> >>> 7190310: Inlining WeakReference.get(), and hoisting $referent may lead >>> to non-terminating loops >>> >>> Add acquire membar after load from Reference.referent field to prevent >>> commoning of loads across safepoint since GC can change its value. >> >> Wow that was quick! :) >> >> My only comment (not being a compiler expert) is that it would appear that we are now inserting read barriers with all >> GC's not just G1. What kind of impact will that have on performance under the other GC's? >> >> Thanks, >> David >> >>> Thanks, >>> Vladimir From christian.thalinger at oracle.com Fri Aug 10 09:09:00 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 10 Aug 2012 09:09:00 -0700 Subject: RFR(S) 7171824: assert(_offset >= 1) failed: illegal call to offset() In-Reply-To: <87zk67bib1.fsf@oracle.com> References: <87zk67bib1.fsf@oracle.com> Message-ID: <5A8918E8-F272-42E7-80A8-985EB6E49A8B@oracle.com> Looks good. Could you move the all_offsets after the compare: + && (all_offsets || lf->field()->offset() == field->offset()); It would be easier to read. -- Chris On Aug 6, 2012, at 6:29 PM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/7171824/webrev.00/ > > Global/local value numbering, when it processes a StoreField, must kill > every matching LoadField that are stored in the value numbering's hash > table. A matching LoadField loads a field that has the same holder and > offset (a LoadField is in the hash table only if it has a known offset). > > In this failure, the StoreField is at an unknown offset (-1) but it has > the same holder as a LoadField. The LoadField and the StoreField are not > accessed from a class with the same class loader/protection domain. So > for the LoadField both holder and offset are known while for the > StoreField the holder is known but the offset is set to -1 because the > field access is not known to be ok under the protection domain. > > Given the offset of the StoreField is unknown during value numbering, > all LoadFields with the same holder as the StoreField should be killed. > > Roland. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120810/21f84095/attachment-0001.html From vladimir.kozlov at oracle.com Fri Aug 10 10:09:31 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Aug 2012 10:09:31 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> Message-ID: <5025404B.6070305@oracle.com> Christian Thalinger wrote: > On Aug 9, 2012, at 7:15 PM, Vladimir Kozlov wrote: > >> Thanks, David >> >> pre_barrier() methods don't generate code for other GCs. But I forgot to put UseG1GC guard around "new G1UnsafeGetObjSATBBarrierStub" in c1_LIRGenerator.cpp. > > Did you update the webrev? -- Chris Not yet. I want to rewrite that code (which use G1UnsafeGetObjSATBBarrierStub). Vladimir > >> Thanks, >> Vladimir >> >> On 8/9/12 6:52 PM, David Holmes wrote: >>> On 10/08/2012 11:34 AM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7190310/webrev >>>> >>>> 7190310: Inlining WeakReference.get(), and hoisting $referent may lead >>>> to non-terminating loops >>>> >>>> Add acquire membar after load from Reference.referent field to prevent >>>> commoning of loads across safepoint since GC can change its value. >>> Wow that was quick! :) >>> >>> My only comment (not being a compiler expert) is that it would appear that we are now inserting read barriers with all >>> GC's not just G1. What kind of impact will that have on performance under the other GC's? >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Vladimir From eric.caspole at amd.com Mon Aug 13 10:15:03 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 13 Aug 2012 13:15:03 -0400 Subject: review request: 7184394: add intrinsics to use AES instructions In-Reply-To: <877gt8aqsl.fsf@oracle.com> References: <500451D3.5080802@oracle.com> <5004667C.5020503@oracle.com> <5008930F.8060105@oracle.com> <5011C967.1060304@oracle.com> <877gt8aqsl.fsf@oracle.com> Message-ID: <952D2337-5D8A-4C45-9D20-78DAA3C1C151@amd.com> Hi Roland and Vladimir, Tom is on vacation for another week so I updated the AES webrev code according to your comments, so we don't miss out on any deadlines or testing opportunities. http://cr.openjdk.java.net/~ecaspole/tom_aes/webrev/ Let us know what you think. Thanks, Eric On Aug 9, 2012, at 2:00 PM, Roland Westrelin wrote: > > Hi Tom, > >> http://cr.openjdk.java.net/~tdeneau/aes-intrinsics/webrev.04 >> >> has been posted which addresses the issues that Vladimir raised. > > In callGenerator.cpp, this should go away: > > 966 // Vladimir said to remove this check > 967 if (false && kit.stopped()) { > 968 // Receiver's null check or other exception. > 969 return kit.transfer_exceptions_into_jvms(); > 970 } > > In library_call.cpp, typos: > > 5784 // the psuedo code we want to emulate with this predicate is: > > 5811 // we want to an instanceof comparison against the AESCrypt > class > > Also, it looks like this should go away as well: > > 5840 if (false) { > 5841 // src and dest are arrays. > 5842 const Type* src_type = src->Value(&_gvn); > 5843 const Type* dest_type = dest->Value(&_gvn); > 5844 const TypeAryPtr* top_src = src_type->isa_aryptr(); > 5845 const TypeAryPtr* top_dest = dest_type->isa_aryptr(); > 5846 assert (top_src != NULL && top_src->klass() != NULL > 5847 && top_dest != NULL && top_dest->klass() != NULL, > "args are strange"); > 5848 } > > Otherwise, I think it'ok to me. > > Roland. > From Eric.Caspole at amd.com Mon Aug 13 11:45:41 2012 From: Eric.Caspole at amd.com (Eric Caspole) Date: Mon, 13 Aug 2012 14:45:41 -0400 Subject: "optimized" build is broken - SequenceGenerator build error Message-ID: <18FA5334-21AB-4D0A-99BC-E05B707D1491@amd.com> Hi, It looks like the "optimized" build is broken right now in hotspot- comp, some things are DEBUG_ONLY and some are NOT_PRODUCT not all in unison, as far as I can tell. Regards, Eric src/share/vm/services/memPtr.hpp:54: DEBUG_ONLY(static jint max_seq_num() { return _max_seq_number; }) /home/ecaspole/views/hotspot/src/share/vm/services/memTracker.cpp: In static member function ?static void MemTracker::print_tracker_stats (outputStream*)?: /home/ecaspole/views/hotspot/src/share/vm/services/memTracker.cpp: 602:46: error: ?max_seq_num? is not a member of ?SequenceGenerator? make[4]: *** [memTracker.o] Error 1 make[4]: *** Waiting for unfinished jobs.... make[4]: Leaving directory `/home/ecaspole/views/hotspot/build/linux/ linux_amd64_compiler2/optimized' make[3]: *** [the_vm] Error 2 make[3]: Leaving directory `/home/ecaspole/views/hotspot/build/linux/ linux_amd64_compiler2/optimized' make[2]: *** [optimized] Error 2 make[2]: Leaving directory `/home/ecaspole/views/hotspot/build/linux' make[1]: *** [generic_build2] Error 2 make[1]: Leaving directory `/home/ecaspole/views/hotspot/make' make: *** [optimized] Error 2 From christian.thalinger at oracle.com Mon Aug 13 15:22:05 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 13 Aug 2012 15:22:05 -0700 Subject: review request: 7184394: add intrinsics to use AES instructions In-Reply-To: <952D2337-5D8A-4C45-9D20-78DAA3C1C151@amd.com> References: <500451D3.5080802@oracle.com> <5004667C.5020503@oracle.com> <5008930F.8060105@oracle.com> <5011C967.1060304@oracle.com> <877gt8aqsl.fsf@oracle.com> <952D2337-5D8A-4C45-9D20-78DAA3C1C151@amd.com> Message-ID: <068AE61F-CBA3-491E-A8BF-9BC7B4C96C2A@oracle.com> On Aug 13, 2012, at 10:15 AM, Eric Caspole wrote: > Hi Roland and Vladimir, > Tom is on vacation for another week so I updated the AES webrev code according to your comments, so we don't miss out on any deadlines or testing opportunities. > > http://cr.openjdk.java.net/~ecaspole/tom_aes/webrev/ src/cpu/x86/vm/stubGenerator_x86_32.cpp: + void loadKey(XMMRegister xmmdst, Register key, int ofst, XMMRegister xmm_shuf_mask=NULL) { + void aesencKey(XMMRegister xmmdst, XMMRegister xmmtmp, Register key, int ofst, XMMRegister xmm_shuf_mask=NULL) { + void aesdecKey(XMMRegister xmmdst, XMMRegister xmmtmp, Register key, int ofst, XMMRegister xmm_shuf_mask=NULL) { Can we use non-camel case names for these methods? + for (int ofst = 0x10; ofst <= 0x90; ofst += 0x10) { I guess ofst means offset. If so, could we rename it? + __ jcc(Assembler::notEqual,L_singleBlock_loopTop_192); + for (int rnum = XMM_REG_NUM_KEY_FIRST + 1; rnum <= XMM_REG_NUM_KEY_LAST; rnum++) { Spacing is sometimes odd (no space, two spaces). src/cpu/x86/vm/vm_version_x86.cpp: 474 // Use AES instructions if available. 475 if (supports_aes()) { 476 if (FLAG_IS_DEFAULT(UseAES)) { 477 UseAES = true; 478 } 479 } else if (UseAES) { 480 if (!FLAG_IS_DEFAULT(UseAES)) 481 warning("AES instructions not available on this CPU"); 482 FLAG_SET_DEFAULT(UseAES, false); 483 } 484 485 // The AES intrinsic stubs require AES instruction support (of course) 486 // but also require AVX mode for misaligned SSE access 487 if (UseAES && (UseAVX > 0)) { 488 if (FLAG_IS_DEFAULT(UseAESIntrinsics)) { 489 UseAESIntrinsics = true; 490 } 491 } else if (UseAESIntrinsics) { 492 if (!FLAG_IS_DEFAULT(UseAESIntrinsics)) 493 warning("AES intrinsics not available on this CPU"); 494 FLAG_SET_DEFAULT(UseAESIntrinsics, false); 495 } 496 The indentation is off. src/share/vm/classfile/vmSymbols.hpp: 722 /* support for com.sum.crypto.provider.AESCrypt and some of its callers */ \ 723 do_class(com_sun_crypto_provider_aescrypt, "com/sun/crypto/provider/AESCrypt") \ 724 do_intrinsic(_aescrypt_encryptBlock, com_sun_crypto_provider_aescrypt, encryptBlock_name, byteArray_int_byteArray_int_signature, F_R) \ 725 do_intrinsic(_aescrypt_decryptBlock, com_sun_crypto_provider_aescrypt, decryptBlock_name, byteArray_int_byteArray_int_signature, F_R) \ 726 do_name( encryptBlock_name, "encryptBlock") \ 727 do_name( decryptBlock_name, "decryptBlock") \ 728 do_signature(byteArray_int_byteArray_int_signature, "([BI[BI)V") \ 729 \ 730 do_class(com_sun_crypto_provider_cipherBlockChaining, "com/sun/crypto/provider/CipherBlockChaining") \ 731 do_intrinsic(_cipherBlockChaining_encryptAESCrypt, com_sun_crypto_provider_cipherBlockChaining, encrypt_name, byteArray_int_int_byteArray_int_signature, F_R) \ 732 do_intrinsic(_cipherBlockChaining_decryptAESCrypt, com_sun_crypto_provider_cipherBlockChaining, decrypt_name, byteArray_int_int_byteArray_int_signature, F_R) \ 733 do_name( encrypt_name, "encrypt") \ 734 do_name( decrypt_name, "decrypt") \ 735 do_signature(byteArray_int_int_byteArray_int_signature, "([BII[BI)V") \ Same here. We try to keep them aligned for better readability: src/share/vm/oops/methodOop.cpp: + strcmp(instanceKlass::cast(holder)->class_loader()->klass()->klass_part()->external_name(), "sun.misc.Launcher$ExtClassLoader") != 0) I think we should define a vmSymbol for the class loader name and do a pointer compare. I don't like the strcmp here. src/share/vm/opto/escape.cpp: + char str[200]; + sprintf(str, "EA: unexpected CallLeaf %s", call->as_CallLeaf()->_name); + assert(false, str); You should use err_msg_res and guarantee here like: + guarantee(err_msg_res("EA: unexpected CallLeaf %s", call->as_CallLeaf()->_name)); Otherwise this looks good. -- Chris > > Let us know what you think. > Thanks, > Eric > > On Aug 9, 2012, at 2:00 PM, Roland Westrelin wrote: > >> >> Hi Tom, >> >>> http://cr.openjdk.java.net/~tdeneau/aes-intrinsics/webrev.04 >>> >>> has been posted which addresses the issues that Vladimir raised. >> >> In callGenerator.cpp, this should go away: >> >> 966 // Vladimir said to remove this check >> 967 if (false && kit.stopped()) { >> 968 // Receiver's null check or other exception. >> 969 return kit.transfer_exceptions_into_jvms(); >> 970 } >> >> In library_call.cpp, typos: >> >> 5784 // the psuedo code we want to emulate with this predicate is: >> >> 5811 // we want to an instanceof comparison against the AESCrypt class >> >> Also, it looks like this should go away as well: >> >> 5840 if (false) { >> 5841 // src and dest are arrays. >> 5842 const Type* src_type = src->Value(&_gvn); >> 5843 const Type* dest_type = dest->Value(&_gvn); >> 5844 const TypeAryPtr* top_src = src_type->isa_aryptr(); >> 5845 const TypeAryPtr* top_dest = dest_type->isa_aryptr(); >> 5846 assert (top_src != NULL && top_src->klass() != NULL >> 5847 && top_dest != NULL && top_dest->klass() != NULL, "args are strange"); >> 5848 } >> >> Otherwise, I think it'ok to me. >> >> Roland. >> > > From christian.thalinger at oracle.com Mon Aug 13 17:02:36 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 13 Aug 2012 17:02:36 -0700 Subject: RFR: 6830717: replay of compilations would help with debugging In-Reply-To: <502039BE.6090108@oracle.com> References: <502039BE.6090108@oracle.com> Message-ID: <73AAAA90-0AFC-4F91-9BBF-A71BC3924735@oracle.com> On Aug 6, 2012, at 2:40 PM, yumin.qi at oracle.com wrote: > Hi, > > Please give your comments of the changes about > 6830717: replay of compilations would help with debugging. > http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 > > Sometime jvm crashes in the process of compilation or in compiled method. To reproduce the compilation process in debug JVM is helpful for quickly identifying root cause. > To do recompilation, we collect data by using of SA (Serviceability Agent) to extract application and system class data from core file. Those information includes nmethod, methodOop, methodDataOop, instanceKlass and corresponding ci counterparts. > With reconfiguring similar (not exactly same) compiling environment as in the core file, try to compile again the failed java methods. > > contributed by Tom R (never). webrev: > > http://cr.openjdk.java.net/~minqi/6830717/ src/share/vm/ci/ciReplay.cpp: 603 if (strcmp(field_signature, "[B") == 0) { 604 oop value = oopFactory::new_byteArray(length, CHECK); 605 java_mirror->obj_field_put(fd.offset(), value); 606 } else if (strcmp(field_signature, "[Z") == 0) { 607 oop value = oopFactory::new_boolArray(length, CHECK); 608 java_mirror->obj_field_put(fd.offset(), value); 609 } else if (strcmp(field_signature, "[C") == 0) { 610 oop value = oopFactory::new_charArray(length, CHECK); 611 java_mirror->obj_field_put(fd.offset(), value); 612 } else if (strcmp(field_signature, "[S") == 0) { 613 oop value = oopFactory::new_shortArray(length, CHECK); 614 java_mirror->obj_field_put(fd.offset(), value); 615 } else if (strcmp(field_signature, "[F") == 0) { 616 oop value = oopFactory::new_singleArray(length, CHECK); 617 java_mirror->obj_field_put(fd.offset(), value); 618 } else if (strcmp(field_signature, "[D") == 0) { 619 oop value = oopFactory::new_doubleArray(length, CHECK); 620 java_mirror->obj_field_put(fd.offset(), value); 621 } else if (strcmp(field_signature, "[I") == 0) { 622 oop value = oopFactory::new_intArray(length, CHECK); 623 java_mirror->obj_field_put(fd.offset(), value); 624 } else if (strcmp(field_signature, "[J") == 0) { 625 oop value = oopFactory::new_longArray(length, CHECK); 626 java_mirror->obj_field_put(fd.offset(), value); 627 } else if (field_signature[0] == '[' && field_signature[1] == 'L') { Can't we switch on the second character? And move this call: 630 java_mirror->obj_field_put(fd.offset(), value); out of the switch? 637 if (strcmp(field_signature, "I") == 0) { 638 int value = atoi(string_value); 639 java_mirror->int_field_put(fd.offset(), value); 640 } else if (strcmp(field_signature, "B") == 0) { 641 int value = atoi(string_value); 642 java_mirror->byte_field_put(fd.offset(), value); 643 } else if (strcmp(field_signature, "C") == 0) { 644 int value = atoi(string_value); 645 java_mirror->char_field_put(fd.offset(), value); 646 } else if (strcmp(field_signature, "S") == 0) { 647 int value = atoi(string_value); 648 java_mirror->short_field_put(fd.offset(), value); 649 } else if (strcmp(field_signature, "Z") == 0) { 650 int value = atol(string_value); 651 java_mirror->bool_field_put(fd.offset(), value); 652 } else if (strcmp(field_signature, "J") == 0) { 653 jlong value; 654 if (sscanf(string_value, INT64_FORMAT, &value) != 1) { 655 fprintf(stderr, "Error parsing long: %s\n", string_value); 656 return; 657 } 658 java_mirror->long_field_put(fd.offset(), value); 659 } else if (strcmp(field_signature, "F") == 0) { 660 float value = atof(string_value); 661 java_mirror->float_field_put(fd.offset(), value); 662 } else if (strcmp(field_signature, "D") == 0) { 663 double value = atof(string_value); 664 java_mirror->double_field_put(fd.offset(), value); 665 } else if (strcmp(field_signature, "Ljava/lang/String;") == 0) { 666 Handle value = java_lang_String::create_from_str(string_value, CHECK); 667 java_mirror->obj_field_put(fd.offset(), value()); 668 } else if (field_signature[0] == 'L') { Same here (not the put though)? Otherwise it looks good. -- Chris > > Thanks > Yumin From yumin.qi at oracle.com Wed Aug 8 10:30:27 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Wed, 08 Aug 2012 10:30:27 -0700 Subject: RFR: 6830717: replay of compilations would help with debugging In-Reply-To: <50229DC3.5080004@oracle.com> References: <502039BE.6090108@oracle.com> <50229DC3.5080004@oracle.com> Message-ID: <5022A233.4030308@oracle.com> Thanks. On 8/8/2012 10:11 AM, Vladimir Kozlov wrote: > This looks good. Small note: I don't see skip_Replay variable usage in > other places. > > Yumin, could you add replay to C1 compilations as next step? > I could do, file a bug and assign it to serviceability team --- if it assigned to me. It will be a low priority as I can see. If you want to assign this to your new hire, it is OK to me too. --Yumin From christian.thalinger at oracle.com Mon Aug 13 12:52:39 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 13 Aug 2012 12:52:39 -0700 Subject: "optimized" build is broken - SequenceGenerator build error In-Reply-To: <18FA5334-21AB-4D0A-99BC-E05B707D1491@amd.com> References: <18FA5334-21AB-4D0A-99BC-E05B707D1491@amd.com> Message-ID: [Forwarding to hotspot-dev, bcc'ing hotspot-compiler-dev.] On Aug 13, 2012, at 11:45 AM, Eric Caspole wrote: > Hi, > It looks like the "optimized" build is broken right now in hotspot-comp, some things are DEBUG_ONLY and some are NOT_PRODUCT not all in unison, as far as I can tell. > Regards, > Eric > > > src/share/vm/services/memPtr.hpp:54: DEBUG_ONLY(static jint max_seq_num() { return _max_seq_number; }) > > > /home/ecaspole/views/hotspot/src/share/vm/services/memTracker.cpp: In static member function ?static void MemTracker::print_tracker_stats(outputStream*)?: > /home/ecaspole/views/hotspot/src/share/vm/services/memTracker.cpp:602:46: error: ?max_seq_num? is not a member of ?SequenceGenerator? > make[4]: *** [memTracker.o] Error 1 > make[4]: *** Waiting for unfinished jobs.... > make[4]: Leaving directory `/home/ecaspole/views/hotspot/build/linux/linux_amd64_compiler2/optimized' > make[3]: *** [the_vm] Error 2 > make[3]: Leaving directory `/home/ecaspole/views/hotspot/build/linux/linux_amd64_compiler2/optimized' > make[2]: *** [optimized] Error 2 > make[2]: Leaving directory `/home/ecaspole/views/hotspot/build/linux' > make[1]: *** [generic_build2] Error 2 > make[1]: Leaving directory `/home/ecaspole/views/hotspot/make' > make: *** [optimized] Error 2 > > From christian.thalinger at oracle.com Mon Aug 13 18:57:55 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 14 Aug 2012 01:57:55 +0000 Subject: hg: hsx/hotspot-comp: 14 new changesets Message-ID: <20120814015756.D046C47505@hg.openjdk.java.net> Changeset: c8d320b48626 Author: erikj Date: 2012-07-03 16:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/c8d320b48626 7181504: Update of latest build-infra Makefiles Reviewed-by: ohair ! common/autoconf/autogen.sh ! common/autoconf/build-aux/config.guess ! common/autoconf/builddeps.conf.example ! common/autoconf/builddeps.m4 ! common/autoconf/configure ! common/autoconf/configure.ac - common/autoconf/cores.m4 ! common/autoconf/help.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/bin/compareimage.sh ! common/bin/diffexec.sh ! common/bin/diffjarzip.sh ! common/bin/difflib.sh ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk - common/makefiles/RMICompile.gmk Changeset: 3156dff953b1 Author: erikj Date: 2012-07-05 18:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/3156dff953b1 7182051: Update of latest build-infra Makefiles (missing files) Reviewed-by: ohair + common/autoconf/basics.m4 + common/autoconf/boot-jdk.m4 + common/autoconf/build-aux/autoconf-config.guess + common/autoconf/build-performance.m4 + common/autoconf/generated-configure.sh + common/autoconf/jdk-options.m4 + common/autoconf/libraries.m4 + common/autoconf/source-dirs.m4 + common/autoconf/spec.sh.in + common/autoconf/toolchain.m4 + common/bin/compare-objects.sh ! common/makefiles/IdlCompilation.gmk + common/makefiles/MakeHelpers.gmk ! common/makefiles/NativeCompilation.gmk + common/makefiles/RMICompilation.gmk Changeset: 1dcb4b7b9373 Author: katleman Date: 2012-07-11 16:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/1dcb4b7b9373 Merge - common/autoconf/cores.m4 - common/makefiles/RMICompile.gmk Changeset: aaae5471808d Author: katleman Date: 2012-07-12 16:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/aaae5471808d Added tag jdk8-b47 for changeset 1dcb4b7b9373 ! .hgtags Changeset: ba77d95ed219 Author: ohair Date: 2012-07-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/ba77d95ed219 7184406: Adjust get_source/hgforest script to allow for trailing // characters Reviewed-by: tbell ! make/scripts/hgforest.sh Changeset: 3f6c72d1c2a6 Author: katleman Date: 2012-07-18 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/3f6c72d1c2a6 Merge Changeset: 969c75896558 Author: cl Date: 2012-07-23 12:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/969c75896558 Added tag jdk8-b48 for changeset 3f6c72d1c2a6 ! .hgtags Changeset: 0562a97bd601 Author: vinnie Date: 2012-07-16 22:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/0562a97bd601 6880559: Enable PKCS11 64-bit windows builds Reviewed-by: valeriep ! THIRD_PARTY_README Changeset: c88aceaf2f3f Author: lana Date: 2012-07-16 17:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/c88aceaf2f3f Merge - common/autoconf/cores.m4 - common/makefiles/RMICompile.gmk Changeset: 36998bc84cff Author: lana Date: 2012-07-18 16:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/36998bc84cff Merge Changeset: c97b99424815 Author: lana Date: 2012-07-24 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/c97b99424815 Merge Changeset: 2fd67618b9a3 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/2fd67618b9a3 Added tag jdk8-b49 for changeset c97b99424815 ! .hgtags Changeset: 57c0aee73090 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/57c0aee73090 Added tag jdk8-b50 for changeset 2fd67618b9a3 ! .hgtags Changeset: 8d24def5ceb3 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8d24def5ceb3 Added tag jdk8-b51 for changeset 57c0aee73090 ! .hgtags From christian.thalinger at oracle.com Mon Aug 13 19:00:13 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 14 Aug 2012 02:00:13 +0000 Subject: hg: hsx/hotspot-comp/jdk: 115 new changesets Message-ID: <20120814021954.0B00547506@hg.openjdk.java.net> Changeset: 9881db0a65bf Author: prr Date: 2012-06-26 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9881db0a65bf 7145771: [macosx] CreateFont/Register.java test fails because of cached results of getAllFonts() Reviewed-by: igor, flar ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java Changeset: c689cc1ef29a Author: prr Date: 2012-06-26 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c689cc1ef29a 7176447: Lunix/Solaris fontpath.c : double free(family) Reviewed-by: igor, flar ! src/solaris/native/sun/awt/fontpath.c Changeset: ad126e65ccc5 Author: prr Date: 2012-06-26 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ad126e65ccc5 7164282: check for NULL return from malloc is testing wrong variable name. Reviewed-by: igor, flar ! src/windows/native/sun/font/lcdglyph.c Changeset: c960cb8d0f8b Author: lana Date: 2012-06-27 18:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c960cb8d0f8b Merge Changeset: 8e6b8a676596 Author: lana Date: 2012-07-03 20:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8e6b8a676596 Merge Changeset: 7d1eae258183 Author: serb Date: 2012-06-26 13:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7d1eae258183 7142091: [macosx] RFE: Refactoring of peer initialization/disposing Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWButtonPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWChoicePeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: c66b34ec39c3 Author: bagiras Date: 2012-06-26 16:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c66b34ec39c3 7024749: JDK7 b131---a crash in: Java_sun_awt_windows_ThemeReader_isGetThemeTransitionDurationDefined+0x75 Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp + test/java/awt/Frame/7024749/bug7024749.java Changeset: 6d37b95f0555 Author: anthony Date: 2012-06-26 17:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6d37b95f0555 7124326: [macosx] An issue similar to autoshutdown one in two AppContexts situation. Summary: Don't add SystemTrayPeer to the peers map Reviewed-by: art, leonidr ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: 7cadd5bb6983 Author: lana Date: 2012-06-27 12:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7cadd5bb6983 Merge Changeset: 85f72a4f5f68 Author: rupashka Date: 2012-06-28 14:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/85f72a4f5f68 7169111: Unreadable menu bar with Ambiance theme in GTK L&F Reviewed-by: kizune ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyleFactory.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java Changeset: 8a284872ee2d Author: lana Date: 2012-07-03 20:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8a284872ee2d Merge Changeset: ff0da4ea08a2 Author: robm Date: 2012-06-26 13:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ff0da4ea08a2 4244896: (process) Provide System.getPid(), System.killProcess(String pid) Reviewed-by: alanb ! src/share/classes/java/lang/Process.java ! src/solaris/classes/java/lang/UNIXProcess.java.bsd ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/solaris/native/java/lang/UNIXProcess_md.c ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/native/java/lang/ProcessImpl_md.c ! test/java/lang/ProcessBuilder/Basic.java + test/java/lang/ProcessBuilder/DestroyTest.java Changeset: 94b525ce3653 Author: dholmes Date: 2012-06-27 01:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/94b525ce3653 7161229: PriorityBlockingQueue keeps hard reference to last removed element Reviewed-by: dholmes, forax, alanb Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! test/java/util/concurrent/BlockingQueue/LastElement.java Changeset: 7e9a7400329b Author: lana Date: 2012-06-26 22:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7e9a7400329b Merge Changeset: 2bba577b8ab8 Author: lana Date: 2012-06-27 00:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2bba577b8ab8 Merge Changeset: 612e56cf284c Author: coffeys Date: 2012-06-27 21:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/612e56cf284c 6893617: JDK 6 CNCtx always uses the default ORB Reviewed-by: lancea ! src/share/classes/com/sun/jndi/cosnaming/CNCtx.java Changeset: 819258b5002e Author: sherman Date: 2012-06-28 22:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/819258b5002e 7175845: jar uf changes file permissions unexpectedly 7177216: native2ascii changes file permissions of input file Summary: undo the File.createTempFile change in jar and native2ascii Reviewed-by: asaha ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/native2ascii/Main.java + test/sun/tools/native2ascii/Permission.java + test/tools/jar/UpdateJar.java Changeset: 9e15068b6946 Author: jgish Date: 2012-06-29 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9e15068b6946 7100996: (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads Summary: add usage note to clarify thread safety Reviewed-by: briangoetz, mduigou Contributed-by: jim.gish at oracle.com ! src/share/classes/java/lang/StringBuffer.java Changeset: 9df29b658145 Author: smarks Date: 2012-06-29 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9df29b658145 7170938: (str) incorrect wording in doc for String.subSequence Reviewed-by: forax, mduigou Contributed-by: Joe Bowbeer ! src/share/classes/java/lang/String.java Changeset: ecc5dd3790a1 Author: robm Date: 2012-07-02 19:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ecc5dd3790a1 7174887: Deadlock in jndi ldap connection cleanup Reviewed-by: xuelei ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java Changeset: b2fc66012451 Author: smarks Date: 2012-07-02 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b2fc66012451 7176907: additional warnings cleanup in java.util, java.util.regexp, java.util.zip Reviewed-by: forax, khazra, smarks Contributed-by: Mani Sarkar ! src/share/classes/java/util/InvalidPropertiesFormatException.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/GZIPInputStream.java Changeset: d375ea39ce9c Author: mullan Date: 2012-07-03 14:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d375ea39ce9c 7133344: Document the java.security.properties system property feature in the java.security file Reviewed-by: hawtin, mullan, weijun Contributed-by: jason.uh at oracle.com ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 8ccbd5aabeab Author: lana Date: 2012-07-03 18:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8ccbd5aabeab Merge Changeset: 3ae91286f313 Author: xuelei Date: 2012-07-03 20:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3ae91286f313 7180038: regression test failure, SSLEngineBadBufferArrayAccess.java Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java Changeset: d828938945af Author: lana Date: 2012-07-03 20:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d828938945af Merge Changeset: 9957b4759354 Author: lana Date: 2012-07-10 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9957b4759354 Merge Changeset: 6df318863178 Author: erikj Date: 2012-07-03 16:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6df318863178 7181504: Update of latest build-infra Makefiles Reviewed-by: ohair ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CopySamples.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataFontConfig.gmk ! makefiles/GendataHtml32dtd.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateData.gmk ! makefiles/GenerateJavaSources.gmk ! makefiles/GensrcBuffer.gmk ! makefiles/GensrcIcons.gmk + makefiles/GensrcJObjC.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk + makefiles/Import.gmk - makefiles/LegacyMakefiles.gmk ! makefiles/Makefile - makefiles/OldImages.gmk ! makefiles/Tools.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy ! makefiles/mapfiles/libjava/mapfile-vers ! makefiles/mapfiles/libjfr/mapfile-vers ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-solaris - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: 8cb908672d9e Author: erikj Date: 2012-07-03 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8cb908672d9e 7181508: Remove GenerateNativeHeader on awt java file Reviewed-by: ohair ! src/share/classes/java/awt/image/DirectColorModel.java ! src/share/classes/sun/awt/CharsetString.java ! src/share/classes/sun/java2d/pipe/RegionIterator.java ! src/share/native/sun/awt/image/cvutils/img_globals.c Changeset: 6cd68b7bd962 Author: erikj Date: 2012-07-03 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6cd68b7bd962 7181501: Add some GenerateNativeHeader annotations and misc Mac adjustments to makefiles Reviewed-by: ohair ! src/macosx/native/jobjc/build.xml ! src/macosx/native/jobjc/src/core/PrimitiveCoder.hs ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/FrameworkClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Clazz.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/ComplexCoderDescriptor.java Changeset: 5b0f880eb154 Author: ohair Date: 2012-07-05 13:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5b0f880eb154 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: 00b22b23269a Author: katleman Date: 2012-07-11 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/00b22b23269a Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: 3e4ab821f461 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3e4ab821f461 Added tag jdk8-b47 for changeset 00b22b23269a ! .hgtags Changeset: 09a79167142c Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/09a79167142c Added tag jdk8-b48 for changeset 3e4ab821f461 ! .hgtags Changeset: a18a547546a4 Author: prr Date: 2012-07-12 16:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a18a547546a4 7183458: Metrics of space character in algorithmically emboldened font have changed in JDK 7. Reviewed-by: igor, jgodinez + test/java/awt/FontMetrics/StyledSpaceAdvance.java Changeset: 9f21c95bfbc1 Author: lana Date: 2012-07-16 16:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9f21c95bfbc1 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: ab0b2720a756 Author: prr Date: 2012-07-17 16:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ab0b2720a756 7183251: Netbeans editor renders text wrong on JDK 7u6 build 17 Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunLayoutEngine.java Changeset: f1a90ee31b38 Author: serb Date: 2012-07-04 14:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f1a90ee31b38 7124244: [macosx] Shaped windows support Reviewed-by: anthony, art ! src/macosx/classes/sun/java2d/opengl/CGLLayer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWRepaintArea.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTWindow.m ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 80c592c9458e Author: serb Date: 2012-07-04 15:36 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/80c592c9458e 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar Reviewed-by: anthony, art ! src/macosx/classes/com/apple/laf/AquaPanelUI.java ! src/macosx/classes/com/apple/laf/AquaRootPaneUI.java ! src/macosx/classes/com/apple/laf/AquaToolBarUI.java ! src/macosx/classes/com/apple/laf/AquaUtils.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/share/classes/javax/swing/JViewport.java Changeset: 911195d40b89 Author: anthony Date: 2012-07-06 14:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/911195d40b89 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 Summary: Avoid unnecessary changes to the extended state Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java + test/java/awt/Frame/HideMaximized/HideMaximized.java Changeset: 4d750ca79fb7 Author: ptisnovs Date: 2012-07-12 16:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4d750ca79fb7 7022041: TitleBorder Null Pointer Exception Summary: Added check if getTitleFont() and getTitleColor() don't return null Reviewed-by: alexsch ! src/share/classes/javax/swing/border/TitledBorder.java + test/javax/swing/border/Test7022041.java Changeset: 4624486823a7 Author: serb Date: 2012-07-16 14:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4624486823a7 7181438: [OGL] Incorrect alpha used, during blit from SW to the texture. Reviewed-by: prr, campbell ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c + test/sun/java2d/OpenGL/bug7181438.java Changeset: c277657e5e10 Author: serb Date: 2012-07-16 14:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c277657e5e10 7170657: [macosx] There seems to be no keyboard/mouse action to select non-contiguous items in List Reviewed-by: rupashka ! src/share/classes/javax/swing/SwingUtilities.java + test/javax/swing/SwingUtilities/7170657/bug7170657.java Changeset: 6d9ea8c91808 Author: lana Date: 2012-07-16 14:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6d9ea8c91808 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: 08842f8ce960 Author: bagiras Date: 2012-07-17 12:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/08842f8ce960 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater Reviewed-by: anthony, ant ! src/share/classes/sun/awt/SunToolkit.java Changeset: 8a90db6c4d77 Author: alexsch Date: 2012-07-18 18:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8a90db6c4d77 7182902: [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 Reviewed-by: bae, kizune ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/native/sun/awt/CGraphicsDevice.m Changeset: 86ca943c120b Author: lana Date: 2012-07-18 16:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/86ca943c120b Merge Changeset: 97eb7a4b1fdd Author: smarks Date: 2012-07-05 15:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/97eb7a4b1fdd 6948101: java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently Reviewed-by: dholmes, smarks Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/rmi/transport/pinLastArguments/PinLastArguments.java Changeset: 4ad204cc7433 Author: smarks Date: 2012-07-05 15:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4ad204cc7433 7123972: test/java/lang/annotation/loaderLeak/Main.java fails intermittently Reviewed-by: dholmes, smarks Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/lang/annotation/loaderLeak/Main.java Changeset: 15a6b0bceb1e Author: zhouyx Date: 2012-07-06 10:36 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/15a6b0bceb1e 7181353: Update error message to distinguish native OOM and java OOM in net Reviewed-by: chegar ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c Changeset: 516e0c884af2 Author: robm Date: 2012-07-09 22:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/516e0c884af2 7179305: (fs) Method name sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled Reviewed-by: dholmes, chegar ! 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/SolarisUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixCopyFile.java ! src/solaris/classes/sun/nio/fs/UnixException.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixPath.java Changeset: 79b63e8eceda Author: weijun Date: 2012-07-11 17:10 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/79b63e8eceda 6966259: Make PrincipalName and Realm immutable Reviewed-by: xuelei ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbAppMessage.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbException.java ! src/share/classes/sun/security/krb5/KrbKdcRep.java ! src/share/classes/sun/security/krb5/KrbPriv.java ! src/share/classes/sun/security/krb5/KrbSafe.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/RealmException.java - src/share/classes/sun/security/krb5/ServiceName.java ! src/share/classes/sun/security/krb5/internal/ASRep.java ! src/share/classes/sun/security/krb5/internal/Authenticator.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/EncASRepPart.java ! src/share/classes/sun/security/krb5/internal/EncKDCRepPart.java ! src/share/classes/sun/security/krb5/internal/EncTGSRepPart.java ! src/share/classes/sun/security/krb5/internal/EncTicketPart.java ! src/share/classes/sun/security/krb5/internal/KDCRep.java ! src/share/classes/sun/security/krb5/internal/KDCReqBody.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/share/classes/sun/security/krb5/internal/TGSRep.java ! src/share/classes/sun/security/krb5/internal/Ticket.java ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! src/share/classes/sun/security/krb5/internal/ccache/CredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ccache/MemoryCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! src/windows/classes/sun/security/krb5/internal/tools/KinitOptions.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! src/windows/native/sun/security/krb5/NativeCreds.c - test/sun/security/krb5/ServiceNameClone.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/name/Constructors.java + test/sun/security/krb5/name/empty.conf + test/sun/security/krb5/name/krb5.conf Changeset: e9461aeff91f Author: khazra Date: 2012-07-13 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e9461aeff91f 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node Summary: Change native code to convey to Java code whether a new node was added Reviewed-by: alanb, chegar ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/native/java/util/MacOSXPreferencesFile.m + test/java/util/prefs/AddNodeChangeListener.java Changeset: 9e5150e8bcf5 Author: ksrini Date: 2012-07-14 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9e5150e8bcf5 7184145: (pack200) pack200 --repack throws NullPointerException when JAR file specified without path Reviewed-by: alanb, sherman ! src/share/classes/com/sun/java/util/jar/pack/Driver.java + test/tools/pack200/RepackTest.java Changeset: 5cee646eaaa7 Author: vinnie Date: 2012-07-16 22:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5cee646eaaa7 6880559: Enable PKCS11 64-bit windows builds Reviewed-by: valeriep ! THIRD_PARTY_README ! make/sun/security/Makefile ! test/sun/security/pkcs11/PKCS11Test.java + test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.chk + test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.chk + test/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.chk + test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.chk + test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nss3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.chk + test/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.chk + test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/ssl3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/ssl3.lib + test/sun/security/pkcs11/nss/src/MD5SUMS + test/sun/security/pkcs11/nss/src/SHA1SUMS + test/sun/security/pkcs11/nss/src/nss-3.13.1.tar.gz Changeset: 1469be7182b4 Author: khazra Date: 2012-07-16 16:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1469be7182b4 7177045: Rework the TestProviderLeak.java regression test, it is too fragile to low memory errors. Summary: Increase Xmx to 20 MB and add mechanisms to eat up most of the JVM free memory. Reviewed-by: wetmore Contributed-by: dan.xu at oracle.com ! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java Changeset: e2d265c9b592 Author: weijun Date: 2012-07-17 11:28 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e2d265c9b592 7183203: ShortRSAKeynnn.sh tests intermittent failure Reviewed-by: xuelei ! test/sun/security/mscapi/ShortRSAKey1024.sh - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 2a39c98c1241 Author: weijun Date: 2012-07-17 11:57 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2a39c98c1241 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified Reviewed-by: mullan ! test/sun/security/util/Oid/S11N.sh Changeset: 7b5e4a64368a Author: lana Date: 2012-07-16 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7b5e4a64368a Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: c7e3106e455a Author: lana Date: 2012-07-16 22:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c7e3106e455a Merge - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: b6f78869c66d Author: dmocek Date: 2012-07-17 11:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b6f78869c66d 7142596: RMI JPRT tests are failing Summary: Changed RMI tests to use random port numbers for the RMI Registry and RMID so the tests can be run concurrently without test failures due to tests using the same port numbers. Reviewed-by: smarks, alanb Contributed-by: olivier.lagneau at oracle.com ! test/ProblemList.txt ! test/TEST.ROOT ! test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java ! test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java ! test/java/rmi/Naming/LookupNameWithColon.java ! test/java/rmi/Naming/RmiIsNoScheme.java ! test/java/rmi/Naming/UnderscoreHost.java ! test/java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java ! test/java/rmi/activation/Activatable/checkActivateRef/security.policy ! test/java/rmi/activation/Activatable/checkAnnotations/security.policy ! test/java/rmi/activation/Activatable/checkImplClassLoader/security.policy ! test/java/rmi/activation/Activatable/checkRegisterInLog/security.policy ! test/java/rmi/activation/Activatable/createPrivateActivable/security.policy ! test/java/rmi/activation/Activatable/downloadParameterClass/security.policy ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/security.policy ! test/java/rmi/activation/Activatable/extLoadedImpl/security.policy ! test/java/rmi/activation/Activatable/forceLogSnapshot/security.policy ! test/java/rmi/activation/Activatable/inactiveGroup/security.policy ! test/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java ! test/java/rmi/activation/Activatable/nestedActivate/security.policy ! test/java/rmi/activation/Activatable/nonExistentActivatable/security.policy ! test/java/rmi/activation/Activatable/restartCrashedService/security.policy ! test/java/rmi/activation/Activatable/restartLatecomer/security.policy ! test/java/rmi/activation/Activatable/restartService/security.policy ! test/java/rmi/activation/Activatable/shutdownGracefully/security.policy ! test/java/rmi/activation/Activatable/unregisterInactive/security.policy ! test/java/rmi/activation/ActivateFailedException/activateFails/security.policy ! test/java/rmi/activation/ActivationSystem/activeGroup/security.policy ! test/java/rmi/activation/ActivationSystem/modifyDescriptor/security.policy ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy ! test/java/rmi/activation/CommandEnvironment/SetChildEnv.java ! test/java/rmi/activation/CommandEnvironment/security.policy ! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/activation/rmidViaInheritedChannel/rmid.security.policy ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java ! test/java/rmi/registry/emptyName/EmptyName.java ! test/java/rmi/registry/interfaceHash/InterfaceHash.java ! test/java/rmi/registry/multipleRegistries/MultipleRegistries.java ! test/java/rmi/registry/readTest/readTest.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/registry/reexport/Reexport.java ! test/java/rmi/reliability/juicer/AppleUserImpl.java ! test/java/rmi/reliability/juicer/ApplicationServer.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/EchoImpl.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/security.policy ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/HelloImpl.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/security.policy ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/EchoImpl.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/security.policy ! test/java/rmi/server/RemoteServer/AddrInUse.java ! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/KeepAliveDuringCall.java ! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/ShutdownImpl.java ! test/java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java ! test/java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java ! test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java ! test/java/rmi/server/Unreferenced/leaseCheckInterval/SelfTerminator.java ! test/java/rmi/server/Unreferenced/unreferencedContext/UnreferencedContext.java ! test/java/rmi/server/useCustomRef/UseCustomRef.java ! test/java/rmi/server/useCustomRef/security.policy ! test/java/rmi/testlibrary/ActivationLibrary.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/testlibrary/RegistryRunner.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/java/rmi/testlibrary/TestLibrary.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkFQDN/CheckFQDNClient.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/java/rmi/transport/checkLeaseInfoLeak/LeaseLeakClient.java ! test/java/rmi/transport/checkLeaseInfoLeak/security.policy ! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java ! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java ! test/java/rmi/transport/dgcDeadLock/TestImpl.java ! test/java/rmi/transport/handshakeFailure/HandshakeFailure.java ! test/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java ! test/java/rmi/transport/httpSocket/HttpSocketTest.java ! test/java/rmi/transport/httpSocket/security.policy ! test/java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java ! test/java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java ! test/java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java ! test/sun/rmi/rmic/newrmic/equivalence/AppleUserImpl.java ! test/sun/rmi/rmic/newrmic/equivalence/run.sh ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java ! test/sun/rmi/transport/proxy/EagerHttpFallback.java ! test/sun/rmi/transport/tcp/DeadCachedConnection.java Changeset: c76ad79a5a2f Author: sherman Date: 2012-07-17 19:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c76ad79a5a2f 7183053: Optimize DoubleByte charset for String.getBytes()/new String(byte[]) Summary: DoubleByte implements sun/nio.cs/ArrayDe/Encoder interface Reviewed-by: alanb ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java ! test/sun/nio/cs/StrCodingBenchmark.java + test/sun/nio/cs/StrCodingBenchmarkDB.java ! test/sun/nio/cs/TestStringCoding.java Changeset: 89129c0737f1 Author: dmocek Date: 2012-07-18 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/89129c0737f1 7184943: fix failing test com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java 7184946: fix failing test com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java Reviewed-by: smarks ! test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java ! test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java Changeset: 7bd32bfc0539 Author: michaelm Date: 2012-07-18 18:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7bd32bfc0539 7183292: HttpURLConnection.getHeaderFields() throws IllegalArgumentException: Illegal cookie name Reviewed-by: khazra, chegar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java + test/java/net/HttpCookie/IllegalCookieNameTest.java Changeset: 255c2c63697e Author: lana Date: 2012-07-18 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/255c2c63697e Merge - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 51707c3b75c0 Author: lana Date: 2012-07-24 11:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/51707c3b75c0 Merge Changeset: e4bae5c53fca Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e4bae5c53fca Added tag jdk8-b49 for changeset 51707c3b75c0 ! .hgtags Changeset: 79c9847d4a5f Author: katleman Date: 2012-08-02 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/79c9847d4a5f Added tag jdk8-b50 for changeset e4bae5c53fca ! .hgtags Changeset: 28665fa73b4a Author: rupashka Date: 2012-07-19 19:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/28665fa73b4a 7124330: [macosx] javax.swing.JComboBox throws unexpected ClassCastException Reviewed-by: kizune ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java Changeset: b1c5e4a843f3 Author: leonidr Date: 2012-07-19 19:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b1c5e4a843f3 7181027: [macosx] Unable to use headless mode Reviewed-by: anthony ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/solaris/native/java/lang/java_props_md.c Changeset: f04d8dee2da9 Author: alexsch Date: 2012-07-23 17:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f04d8dee2da9 7185512: The printout doesn't match image on screen. Reviewed-by: serb, bagiras ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h Changeset: 8a5a71e853ed Author: alexsch Date: 2012-07-24 16:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8a5a71e853ed 7129800: [macosx] Regression test OverrideRedirectWindowActivationTest fails due to timing issue Reviewed-by: rupashka + test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: 3502753a9d66 Author: rupashka Date: 2012-07-25 13:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3502753a9d66 7167780: Hang javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests Reviewed-by: alexsch ! src/share/classes/javax/swing/TimerQueue.java Changeset: 1a410846d85b Author: malenkov Date: 2012-07-25 19:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1a410846d85b 4650871: Classes in sunw.* should be removed from workspace and rt.jar Reviewed-by: art, rupashka ! make/Makefile ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk - make/sunw/Makefile ! makefiles/CreateJars.gmk ! makefiles/docs/CORE_PKGS.gmk ! src/share/classes/sun/misc/MetaIndex.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: 80b1ecc79852 Author: denis Date: 2012-07-27 19:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/80b1ecc79852 7149068: java/awt/Window/Grab/GrabTest.java failed Reviewed-by: art, ant + test/java/awt/Window/Grab/GrabTest.java Changeset: 1579507a736f Author: lana Date: 2012-07-27 22:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1579507a736f Merge - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 1abb270d9038 Author: malenkov Date: 2012-07-30 13:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1abb270d9038 7187618: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Performance/Test7122740.java + test/java/beans/Performance/Test7184799.java Changeset: 896322c6f35f Author: alexsch Date: 2012-07-30 14:31 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/896322c6f35f 7184365: closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails Reviewed-by: serb, bagiras ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/share/classes/java/awt/TextComponent.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest.java Changeset: 773474da570b Author: khazra Date: 2012-07-18 15:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/773474da570b 7185051: Remove TestProviderLeak.java from the ProblemList Summary: Remove TestProviderLeak.java from jdk test problem list. Reviewed-by: khazra Contributed-by: dan.xu at oracle.com ! test/ProblemList.txt Changeset: 2c2e4ecc8f7e Author: chegar Date: 2012-07-19 18:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2c2e4ecc8f7e 7081476: test/java/net/InetSocketAddress/B6469803.java failing intermittently Reviewed-by: chegar Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/net/DatagramPacket/ReuseBuf.java Changeset: 84cd98a5641c Author: sherman Date: 2012-07-19 21:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/84cd98a5641c 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X Summary: to support Unicode nfd/nfc file path on Macos Reviewed-by: alanb ! make/java/nio/Makefile ! src/share/native/java/io/io_util.h ! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MacOSXFileSystem.java + src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h + src/solaris/native/sun/nio/fs/MacOSXNativeDispatcher.c + test/java/io/File/MacPathTest.java + test/java/io/File/MacPathTest.sh + test/java/nio/file/Path/MacPathTest.java + test/java/nio/file/Path/MacPathTest.sh Changeset: 5dc3f32c0d26 Author: weijun Date: 2012-07-21 19:56 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5dc3f32c0d26 7180907: Jarsigner -verify fails if rsa file used sha-256 with authenticated attributes Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 7e49c6f7507e Author: weijun Date: 2012-07-21 19:56 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7e49c6f7507e 7178649: TEST BUG: BadKdc3.java needs improvement to ignore the unlikely but possible timeout Reviewed-by: xuelei ! test/sun/security/krb5/auto/BadKdc.java ! 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 Changeset: 11d5ddc6a6d4 Author: alanb Date: 2012-07-22 20:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/11d5ddc6a6d4 6633549: (dc) Include-mode filtering of IPv6 sources does not block datagrams on Linux Reviewed-by: chegar ! src/solaris/native/sun/nio/ch/DatagramDispatcher.c ! src/solaris/native/sun/nio/ch/Net.c ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java Changeset: f7731fc8c98a Author: weijun Date: 2012-07-24 09:20 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f7731fc8c98a 7179796: GSSExceptionImpl outputs duplicate mech oid Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java Changeset: e0e7cc711bda Author: xuelei Date: 2012-07-24 03:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e0e7cc711bda 7185576: Need to consider the connection timeout at test/com/sun/jndi/ldap/InvalidLdapFilters.java Reviewed-by: vinnie ! test/com/sun/jndi/ldap/InvalidLdapFilters.java Changeset: a18f2806bef2 Author: sherman Date: 2012-07-24 12:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a18f2806bef2 6653797: Reimplement JDK charset repository charsets.jar Summary: Migrated all jis based charsets to new implementation Reviewed-by: okutsu ! make/java/nio/FILES_java.gmk ! make/java/sun_nio/FILES_java.gmk ! make/sun/nio/cs/FILES_java.gmk ! make/tools/CharsetMapping/DoubleByte-X.java.template + make/tools/CharsetMapping/JIS_X_0201.c2b ! make/tools/CharsetMapping/JIS_X_0201.map + make/tools/CharsetMapping/JIS_X_0208.map + make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b + make/tools/CharsetMapping/JIS_X_0208_MS5022X.map + make/tools/CharsetMapping/JIS_X_0208_MS932.map + make/tools/CharsetMapping/JIS_X_0208_MS932.nr + make/tools/CharsetMapping/JIS_X_0208_Solaris.map + make/tools/CharsetMapping/JIS_X_0208_Solaris.nr + make/tools/CharsetMapping/JIS_X_0212.map + make/tools/CharsetMapping/JIS_X_0212_MS5022X.map + make/tools/CharsetMapping/JIS_X_0212_Solaris.map + make/tools/CharsetMapping/JIS_X_0212_Solaris.nr + make/tools/CharsetMapping/PCK.c2b + make/tools/CharsetMapping/PCK.map + make/tools/CharsetMapping/PCK.nr + make/tools/CharsetMapping/SJIS.c2b + make/tools/CharsetMapping/SJIS.map ! make/tools/CharsetMapping/dbcs ! make/tools/CharsetMapping/extsbcs ! make/tools/src/build/tools/charsetmapping/DBCS.java ! make/tools/src/build/tools/charsetmapping/SBCS.java ! src/share/classes/sun/nio/cs/SingleByte.java - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/IBM834.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java ! src/share/classes/sun/nio/cs/ext/MS50220.java ! src/share/classes/sun/nio/cs/ext/MS50221.java ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java ! src/solaris/classes/sun/awt/motif/X11JIS0201.java ! src/solaris/classes/sun/awt/motif/X11JIS0208.java ! src/solaris/classes/sun/awt/motif/X11JIS0212.java ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/sun/nio/cs/OLD/DoubleByteDecoder.java ! test/sun/nio/cs/OLD/DoubleByteEncoder.java + test/sun/nio/cs/OLD/EUC_JP_LINUX_OLD.java + test/sun/nio/cs/OLD/EUC_JP_OLD.java + test/sun/nio/cs/OLD/EUC_JP_Open_OLD.java + test/sun/nio/cs/OLD/JIS_X_0201_OLD.java + test/sun/nio/cs/OLD/JIS_X_0208_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0208_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0208_OLD.java + test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0212_OLD.java + test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Encoder.java ! test/sun/nio/cs/OLD/MS932_OLD.java + test/sun/nio/cs/OLD/PCK_OLD.java + test/sun/nio/cs/OLD/SJIS_OLD.java + test/sun/nio/cs/OLD/SingleByteDecoder.java + test/sun/nio/cs/OLD/SingleByteEncoder.java ! test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/TestX11JIS0201.java Changeset: 74ceda3a98a0 Author: khazra Date: 2012-07-24 13:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/74ceda3a98a0 7184287: (prefs) BackingStoreException when calling flush on root node[macosx] Summary: Change implementation to enable user without administrative privileges to call flush Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! test/ProblemList.txt Changeset: 42eac77355d2 Author: sherman Date: 2012-07-25 12:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/42eac77355d2 7186829: test/sun/nio/cs/OLD/JIS_X_0201_OLD.java failed in jdk8 TL nightly build Summary: fixed the test case Reviewed-by: alanb ! test/sun/nio/cs/OLD/JIS_X_0201_OLD.java Changeset: f267302093d4 Author: weijun Date: 2012-07-26 20:38 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f267302093d4 7187051: ShortRSAKeynnn.sh tests should do cleanup before start test Reviewed-by: xuelei ! test/sun/security/mscapi/ShortRSAKey1024.sh Changeset: 35fec642fd32 Author: coffeys Date: 2012-07-26 22:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/35fec642fd32 7179879: SSLSocket connect times out instead of throwing socket closed exception Reviewed-by: xuelei, chegar ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 018e555a7a07 Author: dmocek Date: 2012-07-27 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/018e555a7a07 7186111: fix bugs in java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup Reviewed-by: smarks, jgish ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy Changeset: a093f6247b52 Author: lana Date: 2012-07-27 22:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a093f6247b52 Merge Changeset: 78644d4a9a32 Author: dxu Date: 2012-07-30 04:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/78644d4a9a32 7185340: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Leaky.java failing intermittently [win] Reviewed-by: alanb ! test/java/nio/channels/AsynchronousSocketChannel/Leaky.java Changeset: 38263aa28324 Author: michaelm Date: 2012-07-30 22:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/38263aa28324 7120665: Change Java SE spec so that external networking not required Reviewed-by: alanb ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/package.html Changeset: b08697af1c56 Author: lana Date: 2012-07-31 18:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b08697af1c56 Merge - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java Changeset: e865efbc7105 Author: lana Date: 2012-08-06 15:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e865efbc7105 Merge - make/sunw/Makefile - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: b3b0d75cb117 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b3b0d75cb117 Added tag jdk8-b51 for changeset e865efbc7105 ! .hgtags Changeset: 21c590fdc8cb Author: mullan Date: 2012-08-01 11:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/21c590fdc8cb 7179715: OCSP revocation checking fails if the signer certificate is identified using the key ID Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 9a5a3741bac9 Author: mullan Date: 2012-08-01 11:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9a5a3741bac9 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 184da100cf45 Author: jgish Date: 2012-07-27 16:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/184da100cf45 6914123: (str) Missing synchronization in java.lang.String#contentEquals(CharSequence) Summary: Change contentEquals( CharSequence cs ) to do synchronization if cs is a StringBuffer Reviewed-by: mduigou Contributed-by: Jim Gish ! src/share/classes/java/lang/String.java Changeset: 75bda37d0337 Author: omajid Date: 2012-08-01 22:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/75bda37d0337 6844255: Potential stack corruption in GetJavaProperties Summary: Use dynamically allocated buffers for temp and encoding. Reviewed-by: alanb, andrew ! src/solaris/native/java/lang/java_props_md.c Changeset: b0bfa441d70f Author: mullan Date: 2012-08-02 10:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b0bfa441d70f 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) Reviewed-by: mullan, xuelei, weijun Contributed-by: jason.uh at oracle.com ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java + test/sun/security/x509/X509CRLImpl/Verify.java + test/sun/security/x509/X509CertImpl/Verify.java Changeset: 4e8bafdcefda Author: mullan Date: 2012-08-02 10:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4e8bafdcefda Merge Changeset: 8a82e5f9c47f Author: dmocek Date: 2012-08-02 18:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8a82e5f9c47f 7187876: ClassCastException in TCPTransport.executeAcceptLoop Reviewed-by: dholmes, smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java Changeset: 1468b0af0d06 Author: sherman Date: 2012-08-03 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1468b0af0d06 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native Summary: re-implemented getBytesRead/Writtten() at java level Reviewed-by: andrew, alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/zlib-1.2.5/compress.c ! src/share/native/java/util/zip/zlib-1.2.5/inflate.c ! src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java ! src/share/native/java/util/zip/zlib-1.2.5/zlib.h + test/java/util/zip/TotalInOut.java Changeset: 3521fcad4b5f Author: ksrini Date: 2012-07-31 06:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3521fcad4b5f 7188114: (launcher) need an alternate command line parser for Windows Reviewed-by: darcy, dholmes, jjh Contributed-by: akhil.arora at oracle.com + src/windows/bin/cmdtoargs.c Changeset: 2dd41a2dfe54 Author: ksrini Date: 2012-07-31 06:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2dd41a2dfe54 7146424: Wildcard expansion for single entry classpath Reviewed-by: dholmes, darcy, jjh, sherman ! make/common/Program.gmk ! make/java/jli/Makefile ! make/java/jli/mapfile-vers ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/jli_util.c ! src/share/bin/jli_util.h ! src/share/bin/main.c ! src/share/bin/wildcard.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties - src/solaris/bin/java_md.c ! src/solaris/bin/java_md_common.c ! src/windows/bin/java_md.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java ! test/tools/launcher/ToolsOpts.java Changeset: e0ef14d89741 Author: alanb Date: 2012-08-07 12:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e0ef14d89741 7076644: TEST_BUG: test/java/io/File/Basic.java fails with cygwin Reviewed-by: alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/io/File/basic.sh Changeset: b0d6552ba301 Author: lana Date: 2012-08-07 20:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b0d6552ba301 Merge - make/sunw/Makefile - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java ! src/solaris/native/java/lang/java_props_md.c Changeset: d87e86aaf2b3 Author: andrew Date: 2012-08-08 12:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d87e86aaf2b3 7189533: GetJavaProperties should free temporary file if subsequent allocations fails Summary: Add missing calls to free Reviewed-by: alanb, dholmes, sherman ! src/solaris/native/java/lang/java_props_md.c Changeset: a50e92a980a5 Author: alanb Date: 2012-08-08 15:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a50e92a980a5 7189886: (aio) Add test coverage for AsynchronousChannelGroup.withThreadPool Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java Changeset: a44671e0b6d7 Author: ksrini Date: 2012-08-08 09:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a44671e0b6d7 7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes Reviewed-by: darcy, jgish ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: bf85c3ab2637 Author: dsamersoff Date: 2012-08-09 14:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bf85c3ab2637 7183753: [TEST] Some colon in the diff for this test Summary: Reference output file contains extra colon Reviewed-by: sspitsyn, mgronlun ! test/sun/tools/jcmd/help_help.out Changeset: da8649489aff Author: lana Date: 2012-08-10 10:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/da8649489aff Merge Changeset: 865c411ebcae Author: twisti Date: 2012-08-10 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/865c411ebcae Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java From christian.thalinger at oracle.com Mon Aug 13 19:20:00 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 14 Aug 2012 02:20:00 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 12 new changesets Message-ID: <20120814022033.E0E0647507@hg.openjdk.java.net> Changeset: 7920ead2cc75 Author: joehw Date: 2012-06-26 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/7920ead2cc75 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException Summary: skip the added international character handling for general paths Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java Changeset: 219e720a1baa Author: lana Date: 2012-06-26 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/219e720a1baa Merge Changeset: 9cb8be5e6119 Author: lana Date: 2012-07-03 18:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/9cb8be5e6119 Merge Changeset: 404521944ac9 Author: lana Date: 2012-07-10 11:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/404521944ac9 Merge Changeset: 1c88da9a1365 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/1c88da9a1365 Added tag jdk8-b47 for changeset 404521944ac9 ! .hgtags Changeset: a7e6e1048e4c Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/a7e6e1048e4c Added tag jdk8-b48 for changeset 1c88da9a1365 ! .hgtags Changeset: 6e444b892c99 Author: joehw Date: 2012-07-12 21:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/6e444b892c99 7183760: DocumentBuilder.parse(String uri) is not IPv6 enabled Summary: removing the hack of using escapeNonUSAscii. this is the same patch as 7166896 for 7u8. Reviewed-by: psandoz, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java Changeset: df4092828362 Author: lana Date: 2012-07-16 17:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/df4092828362 Merge Changeset: f81e981eca7b Author: lana Date: 2012-07-24 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/f81e981eca7b Merge Changeset: 2791ec55f66b Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/2791ec55f66b Added tag jdk8-b49 for changeset f81e981eca7b ! .hgtags Changeset: dc1ea77ed9d9 Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/dc1ea77ed9d9 Added tag jdk8-b50 for changeset 2791ec55f66b ! .hgtags Changeset: bd3c00d57614 Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/bd3c00d57614 Added tag jdk8-b51 for changeset dc1ea77ed9d9 ! .hgtags From christian.thalinger at oracle.com Mon Aug 13 19:20:41 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 14 Aug 2012 02:20:41 +0000 Subject: hg: hsx/hotspot-comp/corba: 8 new changesets Message-ID: <20120814022047.1D58E47508@hg.openjdk.java.net> Changeset: 47adb42076f1 Author: coffeys Date: 2012-06-27 21:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/47adb42076f1 7162902: Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8 Reviewed-by: lancea ! src/share/classes/com/sun/corba/se/impl/encoding/CachedCodeBase.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PIHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PINoOpHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/monitoring/MonitoringManagerFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/monitoring/MonitoringManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/WorkQueueImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaMessageMediatorImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/corba/se/spi/monitoring/MonitoringManager.java ! src/share/classes/com/sun/corba/se/spi/monitoring/MonitoringManagerFactory.java ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java ! src/share/classes/com/sun/corba/se/spi/orbutil/threadpool/ThreadPool.java ! src/share/classes/com/sun/corba/se/spi/orbutil/threadpool/ThreadPoolManager.java ! src/share/classes/com/sun/corba/se/spi/protocol/PIHandler.java ! src/share/classes/com/sun/corba/se/spi/protocol/RequestDispatcherRegistry.java Changeset: 666efea2df67 Author: lana Date: 2012-07-03 18:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/666efea2df67 Merge Changeset: 21e46ea21c6a Author: lana Date: 2012-07-10 11:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/21e46ea21c6a Merge Changeset: 7e2b179a5b4d Author: katleman Date: 2012-07-12 16:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/7e2b179a5b4d Added tag jdk8-b47 for changeset 21e46ea21c6a ! .hgtags Changeset: fe44e58a6bdb Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/fe44e58a6bdb Added tag jdk8-b48 for changeset 7e2b179a5b4d ! .hgtags Changeset: d20d9eb9f093 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/d20d9eb9f093 Added tag jdk8-b49 for changeset fe44e58a6bdb ! .hgtags Changeset: 9b0f841ca9f7 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/9b0f841ca9f7 Added tag jdk8-b50 for changeset d20d9eb9f093 ! .hgtags Changeset: 80689ff9cb49 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/80689ff9cb49 Added tag jdk8-b51 for changeset 9b0f841ca9f7 ! .hgtags From christian.thalinger at oracle.com Mon Aug 13 19:20:53 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 14 Aug 2012 02:20:53 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 5 new changesets Message-ID: <20120814022106.C0CF047509@hg.openjdk.java.net> Changeset: efb564de8a8e Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/efb564de8a8e Added tag jdk8-b47 for changeset fe6a060afc40 ! .hgtags Changeset: b48865af8ac5 Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/b48865af8ac5 Added tag jdk8-b48 for changeset efb564de8a8e ! .hgtags Changeset: bdab72e87b83 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/bdab72e87b83 Added tag jdk8-b49 for changeset b48865af8ac5 ! .hgtags Changeset: 1a70b6333ebe Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/1a70b6333ebe Added tag jdk8-b50 for changeset bdab72e87b83 ! .hgtags Changeset: f62bc618122e Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/f62bc618122e Added tag jdk8-b51 for changeset 1a70b6333ebe ! .hgtags From christian.thalinger at oracle.com Mon Aug 13 19:21:25 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 14 Aug 2012 02:21:25 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 25 new changesets Message-ID: <20120814022217.1A2EB4750A@hg.openjdk.java.net> Changeset: ea926f2921d6 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ea926f2921d6 Added tag jdk8-b49 for changeset e3619706a725 ! .hgtags Changeset: fe94b4e7212b Author: asaha Date: 2012-07-23 14:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fe94b4e7212b 7185550: TEST: runtime/7020373/Test7020373.sh fails because there is no test/runtime/7020373/testcase.jar Reviewed-by: coleenp ! test/runtime/7020373/Test7020373.sh + test/runtime/7020373/testcase.jar Changeset: 43541217e9f7 Author: jiangli Date: 2012-07-26 17:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/43541217e9f7 7187046: Crash in ClassFileParser on solaris-ia32 during RetransformClasses. Summary: Lower compiler optimization level when compiling jvmtiClassFileReconstituter.cpp as a workaround for the solaris x86 5.10 cc bug. Reviewed-by: kvn, coleenp ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make Changeset: 611e8a669a2c Author: dlong Date: 2012-07-16 15:31 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/611e8a669a2c 7147464: Java crashed while executing method with over 8k of dneg operations Summary: replace recursive method with iterative Reviewed-by: kvn, twisti Contributed-by: dean.long at oracle.com ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp Changeset: a93a6d2c9e6c Author: jiangli Date: 2012-07-24 13:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a93a6d2c9e6c Merge Changeset: bcd1b9d98558 Author: jiangli Date: 2012-07-26 16:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bcd1b9d98558 Merge Changeset: 72e0362c3f0c Author: amurillo Date: 2012-07-27 12:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/72e0362c3f0c Merge ! .hgtags - test/runtime/6294277/Test6294277.sh Changeset: 58f237a9e83a Author: amurillo Date: 2012-07-27 12:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/58f237a9e83a Added tag hs24-b18 for changeset 72e0362c3f0c ! .hgtags Changeset: c01c8e05ec8c Author: katleman Date: 2012-08-02 15:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c01c8e05ec8c Added tag jdk8-b50 for changeset 58f237a9e83a ! .hgtags Changeset: 86a687be3f02 Author: amurillo Date: 2012-07-27 16:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/86a687be3f02 7187463: new hotspot build - hs24-b19 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 594dff5e3c2e Author: johnc Date: 2012-07-17 11:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/594dff5e3c2e 7173712: G1: Duplicated code in G1UpdateRSOrPushRefOopClosure::do_oop_nv() Summary: Duplicated code from G1RemSet::par_write_ref() inlined into G1UpdateRSOrPushRefOopClosure::do_oop_nv() was showing up in profiles with a fairly high amount of CPU time. Manually inline the main part of G1RemSet::par_write_ref() to eliminate the code duplication. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: d42fe3c3001d Author: johnc Date: 2012-07-17 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d42fe3c3001d 7184772: G1: Incorrect assert in HeapRegionLinkedList::add_as_head() Summary: Assertion incorrectly checks that _head is NULL and should be checking that _tail is NULL instead. Reviewed-by: johnc Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp Changeset: db823a892a55 Author: johnc Date: 2012-07-17 12:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/db823a892a55 7182260: G1: Fine grain RSet freeing bottleneck Summary: Chain the fine grain PerRegionTables in an individual RSet together and free them in bulk using a single operation. Reviewed-by: johnc, brutisso Contributed-by: Thomas Schatzl ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: a2f7274eb6ef Author: tonyp Date: 2012-07-19 15:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a2f7274eb6ef 7114678: G1: various small fixes, code cleanup, and refactoring Summary: Various cleanups as a prelude to introducing iterators for HeapRegions. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.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 Changeset: 113f4c73df61 Author: jmasa Date: 2012-07-24 14:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/113f4c73df61 Merge Changeset: 3080f4743cf2 Author: jmasa Date: 2012-07-26 23:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3080f4743cf2 Merge Changeset: ff58dfd5b977 Author: jmasa Date: 2012-07-27 21:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ff58dfd5b977 Merge Changeset: 3b01d0321dfa Author: zgu Date: 2012-07-30 10:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3b01d0321dfa 7186778: MachO decoder implementation for MacOSX Summary: Implementation of decoder for Apple's MacOSX. The implementation is based on the patch provided by Kevin Walls. Reviewed-by: coleenp, kamg, kevinw ! src/os/bsd/vm/decoder_machO.cpp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp Changeset: 4bfef6df8881 Author: zgu Date: 2012-07-30 07:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4bfef6df8881 Merge Changeset: 5e2dc722e70d Author: andrew Date: 2012-07-31 16:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5e2dc722e70d 7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 Summary: Templates need this object if not using template parameter in call Reviewed-by: coleenp, kamg, dholmes ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: e37a5219e297 Author: dcubed Date: 2012-07-31 18:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e37a5219e297 Merge Changeset: 3b3ad1642970 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3b3ad1642970 Merge Changeset: 663fc23da8d5 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/663fc23da8d5 Added tag hs24-b19 for changeset 3b3ad1642970 ! .hgtags Changeset: abc951e44e1b Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/abc951e44e1b Added tag jdk8-b51 for changeset 663fc23da8d5 ! .hgtags Changeset: ee7edf31f688 Author: twisti Date: 2012-08-10 15:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ee7edf31f688 Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/phaseX.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp From christian.thalinger at oracle.com Mon Aug 13 19:22:30 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 14 Aug 2012 02:22:30 +0000 Subject: hg: hsx/hotspot-comp/langtools: 16 new changesets Message-ID: <20120814022307.24AAB4750B@hg.openjdk.java.net> Changeset: 01d9911df25d Author: erikj Date: 2012-06-28 14:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/01d9911df25d 7180594: Fix GenStubs in langtools for build-infra builds Reviewed-by: ohair ! make/tools/genstubs/GenStubs.java Changeset: 7e6be2f239c9 Author: ohair Date: 2012-07-08 20:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/7e6be2f239c9 Merge Changeset: afb0a5231557 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/afb0a5231557 Added tag jdk8-b47 for changeset 7e6be2f239c9 ! .hgtags Changeset: 9ee07e5dc0e2 Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9ee07e5dc0e2 Added tag jdk8-b48 for changeset afb0a5231557 ! .hgtags Changeset: 934a89402f85 Author: mcimadamore Date: 2012-07-13 12:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/934a89402f85 7181578: javac reports uninitialized variable with nested try...finally blocks Summary: regression introduced in refactoring of Flow.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/DefiniteAssignment/T7181578.java Changeset: 1f8fc9e50a1f Author: lana Date: 2012-07-16 17:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1f8fc9e50a1f Merge Changeset: c72c164ced67 Author: lana Date: 2012-07-24 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c72c164ced67 Merge Changeset: b2d8a270f5f2 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b2d8a270f5f2 Added tag jdk8-b49 for changeset c72c164ced67 ! .hgtags Changeset: c4cd4cab2220 Author: katleman Date: 2012-08-02 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c4cd4cab2220 Added tag jdk8-b50 for changeset b2d8a270f5f2 ! .hgtags Changeset: 23032c78b2d1 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/23032c78b2d1 Added tag jdk8-b51 for changeset c4cd4cab2220 ! .hgtags Changeset: cddc2c894cc6 Author: mcimadamore Date: 2012-08-02 18:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/cddc2c894cc6 7175911: Simplify error reporting API in Check.CheckContext interface Summary: Make error messages generated during Check.checkType more uniform and more scalable Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/6979683/TestCast6979683_BAD34.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD35.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD36.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD37.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD38.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD39.java.errlog ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/OverrideChecks/6400189/T6400189a.out ! test/tools/javac/OverrideChecks/6400189/T6400189b.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel1.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel2.out ! test/tools/javac/T6326754.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/cast/6270087/T6270087neg.out ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/cast/6932571/T6932571neg.out ! test/tools/javac/cast/7005095/T7005095neg.out ! test/tools/javac/cast/7005671/T7005671.out ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java ! test/tools/javac/diags/examples/InconvertibleTypes.java ! test/tools/javac/diags/examples/InferNoConformingAssignment.java ! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java ! test/tools/javac/diags/examples/InferredDoNotConformToLower.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PossibleLossPrecision.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/6207386/T6207386.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/diamond/neg/Neg10.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/inference/7086586/T7086586.out ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/generics/rawOverride/7062745/T7062745neg.out ! test/tools/javac/generics/wildcards/6886247/T6886247_2.out ! test/tools/javac/multicatch/Neg06.out ! test/tools/javac/multicatch/Neg07.out ! test/tools/javac/types/CastObjectToPrimitiveTest.out ! test/tools/javac/varargs/6313164/T6313164.out ! test/tools/javac/varargs/7097436/T7097436.out Changeset: e5cf1569d3a4 Author: mcimadamore Date: 2012-08-02 18:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e5cf1569d3a4 7175538: Integrate efectively final check with DA/DU analysis Summary: Allow generalized effectively-final analysis for all local variables Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java + test/tools/javac/lambda/EffectivelyFinalTest.java + test/tools/javac/lambda/EffectivelyFinalTest01.out + test/tools/javac/lambda/EffectivelyFinalTest02.out Changeset: 2d75e7c952b8 Author: mcimadamore Date: 2012-08-02 18:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2d75e7c952b8 7187104: Inference cleanup: remove redundant exception classes in Infer.java Summary: Remove unused exception classes in Infer.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java Changeset: cfa70d7ac944 Author: lana Date: 2012-08-07 20:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/cfa70d7ac944 Merge Changeset: f071cd32d297 Author: sundar Date: 2012-08-08 22:17 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f071cd32d297 7178324: Crash when compiling for(i : x) try(AutoCloseable x = ...) {} Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/TryWithResources/T7178324.java Changeset: 1d2db0e5eabc Author: lana Date: 2012-08-10 10:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1d2db0e5eabc Merge From vladimir.kozlov at oracle.com Wed Aug 15 16:26:39 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Aug 2012 16:26:39 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <5025404B.6070305@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> Message-ID: <502C302F.7000708@oracle.com> I updated webrev: http://cr.openjdk.java.net/~kvn/7190310/webrev.01 During testing I found several problem with code for unsafe.getObject() intrinsic code in both: C1 and C2. I moved some checks in C1 from G1UnsafeGetObjSATBBarrierStub stub into shared code and also added static klass analysis to avoid generation of G1/membar code if klass is not Reference or Object. In C2 I hit bad graph problem because If node's projections in insert_pre_barrier() were not put on IGVN worklist. I added jtreg tests (thanks to John Cuthbertson for unsafe test which I extended). Tested with CTW and Kitchensink with C1, C2, tiered. Thanks, Vladimir Vladimir Kozlov wrote: > Christian Thalinger wrote: >> On Aug 9, 2012, at 7:15 PM, Vladimir Kozlov >> wrote: >> >>> Thanks, David >>> >>> pre_barrier() methods don't generate code for other GCs. But I forgot >>> to put UseG1GC guard around "new G1UnsafeGetObjSATBBarrierStub" in >>> c1_LIRGenerator.cpp. >> >> Did you update the webrev? -- Chris > > Not yet. I want to rewrite that code (which use > G1UnsafeGetObjSATBBarrierStub). > > Vladimir > >> >>> Thanks, >>> Vladimir >>> >>> On 8/9/12 6:52 PM, David Holmes wrote: >>>> On 10/08/2012 11:34 AM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7190310/webrev >>>>> >>>>> 7190310: Inlining WeakReference.get(), and hoisting $referent may lead >>>>> to non-terminating loops >>>>> >>>>> Add acquire membar after load from Reference.referent field to prevent >>>>> commoning of loads across safepoint since GC can change its value. >>>> Wow that was quick! :) >>>> >>>> My only comment (not being a compiler expert) is that it would >>>> appear that we are now inserting read barriers with all >>>> GC's not just G1. What kind of impact will that have on performance >>>> under the other GC's? >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Vladimir From christian.thalinger at oracle.com Wed Aug 15 17:44:59 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 15 Aug 2012 17:44:59 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502C302F.7000708@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> Message-ID: <0540E4F4-64AA-4856-8E8E-1694246CDC6E@oracle.com> On Aug 15, 2012, at 4:26 PM, Vladimir Kozlov wrote: > I updated webrev: > > http://cr.openjdk.java.net/~kvn/7190310/webrev.01 > > During testing I found several problem with code for unsafe.getObject() intrinsic code in both: C1 and C2. I moved some checks in C1 from G1UnsafeGetObjSATBBarrierStub stub into shared code and also added static klass analysis to avoid generation of G1/membar code if klass is not Reference or Object. In C2 I hit bad graph problem because If node's projections in insert_pre_barrier() were not put on IGVN worklist. > > I added jtreg tests (thanks to John Cuthbertson for unsafe test which I extended). > > Tested with CTW and Kitchensink with C1, C2, tiered. Looks good. -- Chris > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> Christian Thalinger wrote: >>> On Aug 9, 2012, at 7:15 PM, Vladimir Kozlov wrote: >>> >>>> Thanks, David >>>> >>>> pre_barrier() methods don't generate code for other GCs. But I forgot to put UseG1GC guard around "new G1UnsafeGetObjSATBBarrierStub" in c1_LIRGenerator.cpp. >>> >>> Did you update the webrev? -- Chris >> Not yet. I want to rewrite that code (which use G1UnsafeGetObjSATBBarrierStub). >> Vladimir >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/9/12 6:52 PM, David Holmes wrote: >>>>> On 10/08/2012 11:34 AM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/7190310/webrev >>>>>> >>>>>> 7190310: Inlining WeakReference.get(), and hoisting $referent may lead >>>>>> to non-terminating loops >>>>>> >>>>>> Add acquire membar after load from Reference.referent field to prevent >>>>>> commoning of loads across safepoint since GC can change its value. >>>>> Wow that was quick! :) >>>>> >>>>> My only comment (not being a compiler expert) is that it would appear that we are now inserting read barriers with all >>>>> GC's not just G1. What kind of impact will that have on performance under the other GC's? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Vladimir From vladimir.kozlov at oracle.com Wed Aug 15 17:45:39 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Aug 2012 17:45:39 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <0540E4F4-64AA-4856-8E8E-1694246CDC6E@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <0540E4F4-64AA-4856-8E8E-1694246CDC6E@oracle.com> Message-ID: <502C42B3.9090800@oracle.com> Thank you, Christian Vladimir Christian Thalinger wrote: > On Aug 15, 2012, at 4:26 PM, Vladimir Kozlov wrote: > >> I updated webrev: >> >> http://cr.openjdk.java.net/~kvn/7190310/webrev.01 >> >> During testing I found several problem with code for unsafe.getObject() intrinsic code in both: C1 and C2. I moved some checks in C1 from G1UnsafeGetObjSATBBarrierStub stub into shared code and also added static klass analysis to avoid generation of G1/membar code if klass is not Reference or Object. In C2 I hit bad graph problem because If node's projections in insert_pre_barrier() were not put on IGVN worklist. >> >> I added jtreg tests (thanks to John Cuthbertson for unsafe test which I extended). >> >> Tested with CTW and Kitchensink with C1, C2, tiered. > > Looks good. > > -- Chris > >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> Christian Thalinger wrote: >>>> On Aug 9, 2012, at 7:15 PM, Vladimir Kozlov wrote: >>>> >>>>> Thanks, David >>>>> >>>>> pre_barrier() methods don't generate code for other GCs. But I forgot to put UseG1GC guard around "new G1UnsafeGetObjSATBBarrierStub" in c1_LIRGenerator.cpp. >>>> Did you update the webrev? -- Chris >>> Not yet. I want to rewrite that code (which use G1UnsafeGetObjSATBBarrierStub). >>> Vladimir >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 8/9/12 6:52 PM, David Holmes wrote: >>>>>> On 10/08/2012 11:34 AM, Vladimir Kozlov wrote: >>>>>>> http://cr.openjdk.java.net/~kvn/7190310/webrev >>>>>>> >>>>>>> 7190310: Inlining WeakReference.get(), and hoisting $referent may lead >>>>>>> to non-terminating loops >>>>>>> >>>>>>> Add acquire membar after load from Reference.referent field to prevent >>>>>>> commoning of loads across safepoint since GC can change its value. >>>>>> Wow that was quick! :) >>>>>> >>>>>> My only comment (not being a compiler expert) is that it would appear that we are now inserting read barriers with all >>>>>> GC's not just G1. What kind of impact will that have on performance under the other GC's? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Vladimir > From roland.westrelin at oracle.com Thu Aug 16 00:59:10 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 16 Aug 2012 09:59:10 +0200 Subject: RFR(S) 7171824: assert(_offset >= 1) failed: illegal call to offset() In-Reply-To: <5A8918E8-F272-42E7-80A8-985EB6E49A8B@oracle.com> References: <87zk67bib1.fsf@oracle.com> <5A8918E8-F272-42E7-80A8-985EB6E49A8B@oracle.com> Message-ID: <5C435A85-D938-4C40-B2F8-93B1745C39E9@oracle.com> Hi Chris, > Looks good. Could you move the all_offsets after the compare: > + && (all_offsets || lf->field()->offset() == field->offset()); > It would be easier to read. Do you mean: (lf->field()->offset() == field->offset() || all_offsets) ? That wouldn't work. The all_offsets must shortcut so that the lf->field()->offset() == field->offset() test isn' run. Otherwise, the assert(_offset >= 1) will trigger when _offset = -1 in the call to offset() which may happen when all_offsets is true. Roland. From roland.westrelin at oracle.com Thu Aug 16 00:59:54 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 16 Aug 2012 09:59:54 +0200 Subject: RFR(S) 7171824: assert(_offset >= 1) failed: illegal call to offset() In-Reply-To: <50241F92.8050508@oracle.com> References: <87zk67bib1.fsf@oracle.com> <50241F92.8050508@oracle.com> Message-ID: <7473AFBF-35BD-4078-8BE1-B4A04A81E0B9@oracle.com> Vladimir, > This looks good. Thanks for the review. Roland. From roland.westrelin at oracle.com Thu Aug 16 02:08:41 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 16 Aug 2012 11:08:41 +0200 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502C302F.7000708@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> Message-ID: <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> Hi Vladimir, > I updated webrev: > > http://cr.openjdk.java.net/~kvn/7190310/webrev.01 > > During testing I found several problem with code for unsafe.getObject() intrinsic code in both: C1 and C2. I moved some checks in C1 from G1UnsafeGetObjSATBBarrierStub stub into shared code and also added static klass analysis to avoid generation of G1/membar code if klass is not Reference or Object. In C2 I hit bad graph problem because If node's projections in insert_pre_barrier() were not put on IGVN worklist. > > I added jtreg tests (thanks to John Cuthbertson for unsafe test which I extended). > > Tested with CTW and Kitchensink with C1, C2, tiered. The c1 side doesn't look right to me. insert_mem_bar(Op_MemBarCPUOrder) is not the same as __ membar_acquire(). __ membar_acquire() actually emits instructions on some platforms. Also, optimizations in c1 are performed at the HIR level. So adding the barrier at the LIR won't prevent any further optimization. Can this problem actually happen with c1? Roland. From david.holmes at oracle.com Thu Aug 16 03:46:38 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Aug 2012 20:46:38 +1000 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> Message-ID: <502CCF8E.6020303@oracle.com> On 16/08/2012 7:08 PM, Roland Westrelin wrote: > Hi Vladimir, > >> I updated webrev: >> >> http://cr.openjdk.java.net/~kvn/7190310/webrev.01 >> >> During testing I found several problem with code for unsafe.getObject() intrinsic code in both: C1 and C2. I moved some checks in C1 from G1UnsafeGetObjSATBBarrierStub stub into shared code and also added static klass analysis to avoid generation of G1/membar code if klass is not Reference or Object. In C2 I hit bad graph problem because If node's projections in insert_pre_barrier() were not put on IGVN worklist. >> >> I added jtreg tests (thanks to John Cuthbertson for unsafe test which I extended). >> >> Tested with CTW and Kitchensink with C1, C2, tiered. > > The c1 side doesn't look right to me. > > insert_mem_bar(Op_MemBarCPUOrder) is not the same as __ membar_acquire(). __ membar_acquire() actually emits instructions on some platforms. Also, optimizations in c1 are performed at the HIR level. So adding the barrier at the LIR won't prevent any further optimization. Not that I know much about C1 but the problem with C2 was purely a compiler issue, hoisting the load. There should not be any need to emit actual architectural level memory barriers here. David ----- > Can this problem actually happen with c1? > > Roland. From vitalyd at gmail.com Thu Aug 16 05:14:14 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 16 Aug 2012 08:14:14 -0400 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502CCF8E.6020303@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502CCF8E.6020303@oracle.com> Message-ID: I agree, I don't think any cpu order/fence is needed here. Roland, what scenario are you envisioning that would require a load fence at the CPU level? Thanks Sent from my phone On Aug 16, 2012 6:47 AM, "David Holmes" wrote: > On 16/08/2012 7:08 PM, Roland Westrelin wrote: > >> Hi Vladimir, >> >> I updated webrev: >>> >>> http://cr.openjdk.java.net/~**kvn/7190310/webrev.01 >>> >>> During testing I found several problem with code for unsafe.getObject() >>> intrinsic code in both: C1 and C2. I moved some checks in C1 from >>> G1UnsafeGetObjSATBBarrierStub stub into shared code and also added static >>> klass analysis to avoid generation of G1/membar code if klass is not >>> Reference or Object. In C2 I hit bad graph problem because If node's >>> projections in insert_pre_barrier() were not put on IGVN worklist. >>> >>> I added jtreg tests (thanks to John Cuthbertson for unsafe test which I >>> extended). >>> >>> Tested with CTW and Kitchensink with C1, C2, tiered. >>> >> >> The c1 side doesn't look right to me. >> >> insert_mem_bar(Op_**MemBarCPUOrder) is not the same as __ >> membar_acquire(). __ membar_acquire() actually emits instructions on some >> platforms. Also, optimizations in c1 are performed at the HIR level. So >> adding the barrier at the LIR won't prevent any further optimization. >> > > Not that I know much about C1 but the problem with C2 was purely a > compiler issue, hoisting the load. There should not be any need to emit > actual architectural level memory barriers here. > > David > ----- > > Can this problem actually happen with c1? >> >> Roland. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120816/04696792/attachment-0001.html From vitalyd at gmail.com Thu Aug 16 05:19:57 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 16 Aug 2012 08:19:57 -0400 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502CCF8E.6020303@oracle.com> Message-ID: Sorry, David corrected me - my question is for Vladimir not Roland. :) sorry guys Sent from my phone On Aug 16, 2012 8:14 AM, "Vitaly Davidovich" wrote: > I agree, I don't think any cpu order/fence is needed here. > > Roland, what scenario are you envisioning that would require a load fence > at the CPU level? > > Thanks > > Sent from my phone > On Aug 16, 2012 6:47 AM, "David Holmes" wrote: > >> On 16/08/2012 7:08 PM, Roland Westrelin wrote: >> >>> Hi Vladimir, >>> >>> I updated webrev: >>>> >>>> http://cr.openjdk.java.net/~**kvn/7190310/webrev.01 >>>> >>>> During testing I found several problem with code for unsafe.getObject() >>>> intrinsic code in both: C1 and C2. I moved some checks in C1 from >>>> G1UnsafeGetObjSATBBarrierStub stub into shared code and also added static >>>> klass analysis to avoid generation of G1/membar code if klass is not >>>> Reference or Object. In C2 I hit bad graph problem because If node's >>>> projections in insert_pre_barrier() were not put on IGVN worklist. >>>> >>>> I added jtreg tests (thanks to John Cuthbertson for unsafe test which I >>>> extended). >>>> >>>> Tested with CTW and Kitchensink with C1, C2, tiered. >>>> >>> >>> The c1 side doesn't look right to me. >>> >>> insert_mem_bar(Op_**MemBarCPUOrder) is not the same as __ >>> membar_acquire(). __ membar_acquire() actually emits instructions on some >>> platforms. Also, optimizations in c1 are performed at the HIR level. So >>> adding the barrier at the LIR won't prevent any further optimization. >>> >> >> Not that I know much about C1 but the problem with C2 was purely a >> compiler issue, hoisting the load. There should not be any need to emit >> actual architectural level memory barriers here. >> >> David >> ----- >> >> Can this problem actually happen with c1? >>> >>> Roland. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120816/d3a73ae5/attachment.html From vitalyd at gmail.com Thu Aug 16 05:31:19 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 16 Aug 2012 08:31:19 -0400 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502CCF8E.6020303@oracle.com> Message-ID: Actually, maybe this is because code is shared with G1 SATB pre barrier, which probably does need ordering here of the load. Sent from my phone On Aug 16, 2012 8:19 AM, "Vitaly Davidovich" wrote: > Sorry, David corrected me - my question is for Vladimir not Roland. :) > sorry guys > > Sent from my phone > On Aug 16, 2012 8:14 AM, "Vitaly Davidovich" wrote: > >> I agree, I don't think any cpu order/fence is needed here. >> >> Roland, what scenario are you envisioning that would require a load fence >> at the CPU level? >> >> Thanks >> >> Sent from my phone >> On Aug 16, 2012 6:47 AM, "David Holmes" wrote: >> >>> On 16/08/2012 7:08 PM, Roland Westrelin wrote: >>> >>>> Hi Vladimir, >>>> >>>> I updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~**kvn/7190310/webrev.01 >>>>> >>>>> During testing I found several problem with code for >>>>> unsafe.getObject() intrinsic code in both: C1 and C2. I moved some checks >>>>> in C1 from G1UnsafeGetObjSATBBarrierStub stub into shared code and also >>>>> added static klass analysis to avoid generation of G1/membar code if klass >>>>> is not Reference or Object. In C2 I hit bad graph problem because If node's >>>>> projections in insert_pre_barrier() were not put on IGVN worklist. >>>>> >>>>> I added jtreg tests (thanks to John Cuthbertson for unsafe test which >>>>> I extended). >>>>> >>>>> Tested with CTW and Kitchensink with C1, C2, tiered. >>>>> >>>> >>>> The c1 side doesn't look right to me. >>>> >>>> insert_mem_bar(Op_**MemBarCPUOrder) is not the same as __ >>>> membar_acquire(). __ membar_acquire() actually emits instructions on some >>>> platforms. Also, optimizations in c1 are performed at the HIR level. So >>>> adding the barrier at the LIR won't prevent any further optimization. >>>> >>> >>> Not that I know much about C1 but the problem with C2 was purely a >>> compiler issue, hoisting the load. There should not be any need to emit >>> actual architectural level memory barriers here. >>> >>> David >>> ----- >>> >>> Can this problem actually happen with c1? >>>> >>>> Roland. >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120816/37986f03/attachment.html From eric.caspole at amd.com Thu Aug 16 07:11:00 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Thu, 16 Aug 2012 10:11:00 -0400 Subject: review request: 7184394: add intrinsics to use AES instructions In-Reply-To: <068AE61F-CBA3-491E-A8BF-9BC7B4C96C2A@oracle.com> References: <500451D3.5080802@oracle.com> <5004667C.5020503@oracle.com> <5008930F.8060105@oracle.com> <5011C967.1060304@oracle.com> <877gt8aqsl.fsf@oracle.com> <952D2337-5D8A-4C45-9D20-78DAA3C1C151@amd.com> <068AE61F-CBA3-491E-A8BF-9BC7B4C96C2A@oracle.com> Message-ID: Hi Christian, I think I addressed all your comments and fixed the funny spacing. Here is the update: http://cr.openjdk.java.net/~ecaspole/tom_aes/webrev.01/ Regards, Eric On Aug 13, 2012, at 6:22 PM, Christian Thalinger wrote: > > On Aug 13, 2012, at 10:15 AM, Eric Caspole > wrote: > >> Hi Roland and Vladimir, >> Tom is on vacation for another week so I updated the AES webrev >> code according to your comments, so we don't miss out on any >> deadlines or testing opportunities. >> >> http://cr.openjdk.java.net/~ecaspole/tom_aes/webrev/ > > src/cpu/x86/vm/stubGenerator_x86_32.cpp: > > + void loadKey(XMMRegister xmmdst, Register key, int ofst, > XMMRegister xmm_shuf_mask=NULL) { > + void aesencKey(XMMRegister xmmdst, XMMRegister xmmtmp, Register > key, int ofst, XMMRegister xmm_shuf_mask=NULL) { > + void aesdecKey(XMMRegister xmmdst, XMMRegister xmmtmp, Register > key, int ofst, XMMRegister xmm_shuf_mask=NULL) { > > Can we use non-camel case names for these methods? > > + for (int ofst = 0x10; ofst <= 0x90; ofst += 0x10) { > > I guess ofst means offset. If so, could we rename it? > > + __ jcc(Assembler::notEqual,L_singleBlock_loopTop_192); > + for (int rnum = XMM_REG_NUM_KEY_FIRST + 1; rnum <= > XMM_REG_NUM_KEY_LAST; rnum++) { > > Spacing is sometimes odd (no space, two spaces). > > src/cpu/x86/vm/vm_version_x86.cpp: > > 474 // Use AES instructions if available. > 475 if (supports_aes()) { > 476 if (FLAG_IS_DEFAULT(UseAES)) { > 477 UseAES = true; > 478 } > 479 } else if (UseAES) { > 480 if (!FLAG_IS_DEFAULT(UseAES)) > 481 warning("AES instructions not available on this > CPU"); > 482 FLAG_SET_DEFAULT(UseAES, false); > 483 } > 484 > 485 // The AES intrinsic stubs require AES instruction support > (of course) > 486 // but also require AVX mode for misaligned SSE access > 487 if (UseAES && (UseAVX > 0)) { > 488 if (FLAG_IS_DEFAULT(UseAESIntrinsics)) { > 489 UseAESIntrinsics = true; > 490 } > 491 } else if (UseAESIntrinsics) { > 492 if (!FLAG_IS_DEFAULT(UseAESIntrinsics)) > 493 warning("AES intrinsics not available on this CPU"); > 494 FLAG_SET_DEFAULT(UseAESIntrinsics, false); > 495 } > 496 > > The indentation is off. > > src/share/vm/classfile/vmSymbols.hpp: > > 722 /* support for com.sum.crypto.provider.AESCrypt and some of > its callers */ \ > 723 do_class(com_sun_crypto_provider_aescrypt, "com/sun/ > crypto/provider/AESCrypt") \ > 724 do_intrinsic(_aescrypt_encryptBlock, > com_sun_crypto_provider_aescrypt, encryptBlock_name, > byteArray_int_byteArray_int_signature, F_R) \ > 725 do_intrinsic(_aescrypt_decryptBlock, > com_sun_crypto_provider_aescrypt, decryptBlock_name, > byteArray_int_byteArray_int_signature, F_R) \ > 726 do_name > ( encryptBlock_name, > "encryptBlock") \ > 727 do_name > ( decryptBlock_name, > "decryptBlock") \ > 728 do_signature > (byteArray_int_byteArray_int_signature, "([BI[BI) > V") \ > > 729 > \ > 730 do_class(com_sun_crypto_provider_cipherBlockChaining, > "com/sun/crypto/provider/CipherBlockChaining") \ > 731 do_intrinsic(_cipherBlockChaining_encryptAESCrypt, > com_sun_crypto_provider_cipherBlockChaining, encrypt_name, > byteArray_int_int_byteArray_int_signature, F_R) \ > 732 do_intrinsic(_cipherBlockChaining_decryptAESCrypt, > com_sun_crypto_provider_cipherBlockChaining, decrypt_name, > byteArray_int_int_byteArray_int_signature, F_R) \ > 733 do_name > ( encrypt_name, > "encrypt") \ > 734 do_name > ( decrypt_name, > "decrypt") \ > 735 do_signature > (byteArray_int_int_byteArray_int_signature, "([BII[BI) > V") \ > > Same here. We try to keep them aligned for better readability: > > src/share/vm/oops/methodOop.cpp: > > + strcmp(instanceKlass::cast(holder)->class_loader()->klass()- > >klass_part()->external_name(), "sun.misc.Launcher > $ExtClassLoader") != 0) > > I think we should define a vmSymbol for the class loader name and > do a pointer compare. I don't like the strcmp here. > > src/share/vm/opto/escape.cpp: > > + char str[200]; > + sprintf(str, "EA: unexpected CallLeaf %s", call- > >as_CallLeaf()->_name); > + assert(false, str); > > You should use err_msg_res and guarantee here like: > > + guarantee(err_msg_res("EA: unexpected CallLeaf %s", > call->as_CallLeaf()->_name)); > > Otherwise this looks good. > > -- Chris > >> >> Let us know what you think. >> Thanks, >> Eric >> >> On Aug 9, 2012, at 2:00 PM, Roland Westrelin wrote: >> >>> >>> Hi Tom, >>> >>>> http://cr.openjdk.java.net/~tdeneau/aes-intrinsics/webrev.04 >>>> >>>> has been posted which addresses the issues that Vladimir raised. >>> >>> In callGenerator.cpp, this should go away: >>> >>> 966 // Vladimir said to remove this check >>> 967 if (false && kit.stopped()) { >>> 968 // Receiver's null check or other exception. >>> 969 return kit.transfer_exceptions_into_jvms(); >>> 970 } >>> >>> In library_call.cpp, typos: >>> >>> 5784 // the psuedo code we want to emulate with this predicate is: >>> >>> 5811 // we want to an instanceof comparison against the >>> AESCrypt class >>> >>> Also, it looks like this should go away as well: >>> >>> 5840 if (false) { >>> 5841 // src and dest are arrays. >>> 5842 const Type* src_type = src->Value(&_gvn); >>> 5843 const Type* dest_type = dest->Value(&_gvn); >>> 5844 const TypeAryPtr* top_src = src_type->isa_aryptr(); >>> 5845 const TypeAryPtr* top_dest = dest_type->isa_aryptr(); >>> 5846 assert (top_src != NULL && top_src->klass() != NULL >>> 5847 && top_dest != NULL && top_dest->klass() != >>> NULL, "args are strange"); >>> 5848 } >>> >>> Otherwise, I think it'ok to me. >>> >>> Roland. >>> >> >> > > From christian.thalinger at oracle.com Thu Aug 16 08:27:43 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 16 Aug 2012 08:27:43 -0700 Subject: RFR(S) 7171824: assert(_offset >= 1) failed: illegal call to offset() In-Reply-To: <5C435A85-D938-4C40-B2F8-93B1745C39E9@oracle.com> References: <87zk67bib1.fsf@oracle.com> <5A8918E8-F272-42E7-80A8-985EB6E49A8B@oracle.com> <5C435A85-D938-4C40-B2F8-93B1745C39E9@oracle.com> Message-ID: On Aug 16, 2012, at 12:59 AM, Roland Westrelin wrote: > Hi Chris, > >> Looks good. Could you move the all_offsets after the compare: >> + && (all_offsets || lf->field()->offset() == field->offset()); >> It would be easier to read. > > Do you mean: > > (lf->field()->offset() == field->offset() || all_offsets) > > ? > > That wouldn't work. The all_offsets must shortcut so that the lf->field()->offset() == field->offset() test isn' run. Otherwise, the assert(_offset >= 1) will trigger when _offset = -1 in the call to offset() which may happen when all_offsets is true. Ah, I didn't look where the assert is. Sorry. -- Chris > > Roland. > > From vladimir.kozlov at oracle.com Thu Aug 16 09:14:19 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Aug 2012 09:14:19 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> Message-ID: <502D1C5B.3010307@oracle.com> Thank you, Roland On 8/16/12 2:08 AM, Roland Westrelin wrote: > Hi Vladimir, > >> I updated webrev: >> >> http://cr.openjdk.java.net/~kvn/7190310/webrev.01 >> >> During testing I found several problem with code for unsafe.getObject() intrinsic code in both: C1 and C2. I moved some checks in C1 from G1UnsafeGetObjSATBBarrierStub stub into shared code and also added static klass analysis to avoid generation of G1/membar code if klass is not Reference or Object. In C2 I hit bad graph problem because If node's projections in insert_pre_barrier() were not put on IGVN worklist. >> >> I added jtreg tests (thanks to John Cuthbertson for unsafe test which I extended). >> >> Tested with CTW and Kitchensink with C1, C2, tiered. > > The c1 side doesn't look right to me. It is nice to have C1 expert in our group :) > > insert_mem_bar(Op_MemBarCPUOrder) is not the same as __ membar_acquire(). __ membar_acquire() actually emits instructions on some platforms. I was not able to find in C1 a something which separates reads and prevents GVN to common them but does not generate actual asm code. > Also, optimizations in c1 are performed at the HIR level. So adding the barrier at the LIR won't prevent any further optimization. So how I do that? > > Can this problem actually happen with c1? In C2 two reads (one outside a loop and an other inside) have the same inputs so IGVN replace second with dominating one outside the loop. I don't know if C1 does it now but nothing prevents from this in a future when someone decide to add more optimization into C1. On other hand it is unsafe reads (in HIR level), I doubt it will be allowed to common unsafe reads. Thanks, Vladimir > > Roland. From roland.westrelin at oracle.com Thu Aug 16 09:44:39 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 16 Aug 2012 18:44:39 +0200 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502D1C5B.3010307@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> Message-ID: <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> > In C2 two reads (one outside a loop and an other inside) have the same inputs so IGVN replace second with dominating one outside the loop. I don't know if C1 does it now but nothing prevents from this in a future when someone decide to add more optimization into C1. On other hand it is unsafe reads (in HIR level), I doubt it will be allowed to common unsafe reads. GVN in c1 operates on the HIR. Reference.get() is inlined in the HIR as an Intrinsic instruction node. Intrinsic instructions do not participate in GVN (something you find out by looking at the Intrinsic definition in c1_Instruction.hpp and checking whether it uses one of the HASHING{1,2,3} macro). So no Intrinsic instruction will be eliminated by GVN. The other thing that could access the same field would be an UnsafeGetObject, right? GVN ignores this one as well. When LIR is built, the UnsafeGetObject and the Reference.get() Intrinsic nodes become loads. No optimizations are then applied so no load will go away. So to me, we are safe on the c1 side. Roland. From vladimir.kozlov at oracle.com Thu Aug 16 09:54:03 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Aug 2012 09:54:03 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502CCF8E.6020303@oracle.com> Message-ID: <502D25AB.2090107@oracle.com> You don't need cpu order as David said. I simple did not find "software barrier" in C1. But I may not need it, see my discussion with Roland. Vladimir Vitaly Davidovich wrote: > Actually, maybe this is because code is shared with G1 SATB pre barrier, > which probably does need ordering here of the load. > > Sent from my phone > > On Aug 16, 2012 8:19 AM, "Vitaly Davidovich" > wrote: > > Sorry, David corrected me - my question is for Vladimir not Roland. > :) sorry guys > > Sent from my phone > > On Aug 16, 2012 8:14 AM, "Vitaly Davidovich" > wrote: > > I agree, I don't think any cpu order/fence is needed here. > > Roland, what scenario are you envisioning that would require a > load fence at the CPU level? > > Thanks > > Sent from my phone > > On Aug 16, 2012 6:47 AM, "David Holmes" > wrote: > > On 16/08/2012 7:08 PM, Roland Westrelin wrote: > > Hi Vladimir, > > I updated webrev: > > http://cr.openjdk.java.net/~__kvn/7190310/webrev.01 > > > During testing I found several problem with code for > unsafe.getObject() intrinsic code in both: C1 and > C2. I moved some checks in C1 from > G1UnsafeGetObjSATBBarrierStub stub into shared code > and also added static klass analysis to avoid > generation of G1/membar code if klass is not > Reference or Object. In C2 I hit bad graph problem > because If node's projections in > insert_pre_barrier() were not put on IGVN worklist. > > I added jtreg tests (thanks to John Cuthbertson for > unsafe test which I extended). > > Tested with CTW and Kitchensink with C1, C2, tiered. > > > The c1 side doesn't look right to me. > > insert_mem_bar(Op___MemBarCPUOrder) is not the same as > __ membar_acquire(). __ membar_acquire() actually emits > instructions on some platforms. Also, optimizations in > c1 are performed at the HIR level. So adding the barrier > at the LIR won't prevent any further optimization. > > > Not that I know much about C1 but the problem with C2 was > purely a compiler issue, hoisting the load. There should not > be any need to emit actual architectural level memory > barriers here. > > David > ----- > > Can this problem actually happen with c1? > > Roland. > From vladimir.kozlov at oracle.com Thu Aug 16 10:05:11 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Aug 2012 10:05:11 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> Message-ID: <502D2847.1000301@oracle.com> Roland Westrelin wrote: >> In C2 two reads (one outside a loop and an other inside) have the same inputs so IGVN replace second with dominating one outside the loop. I don't know if C1 does it now but nothing prevents from this in a future when someone decide to add more optimization into C1. On other hand it is unsafe reads (in HIR level), I doubt it will be allowed to common unsafe reads. > > GVN in c1 operates on the HIR. Reference.get() is inlined in the HIR as an Intrinsic instruction node. Intrinsic instructions do not participate in GVN (something you find out by looking at the Intrinsic definition in c1_Instruction.hpp and checking whether it uses one of the HASHING{1,2,3} macro). So no Intrinsic instruction will be eliminated by GVN. Good, I was thinking the same. Just always (before it was only for G1) generating Reference.get() intrinsic will be enough. I will remove membar from there. > > The other thing that could access the same field would be an UnsafeGetObject, right? GVN ignores this one as well. Right only these 2 cases. > > When LIR is built, the UnsafeGetObject and the Reference.get() Intrinsic nodes become loads. No optimizations are then applied so no load will go away. I did not realized that UnsafeGetObject is like intrinsic node. > > So to me, we are safe on the c1 side. Good, then I don't need membar in do_UnsafeGetObject() also. What do you think about my move of some checks from G1 stub into do_UnsafeGetObject()? And about klass analysis there? Thanks, Vladimir > > Roland. From christian.thalinger at oracle.com Thu Aug 16 10:14:33 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 16 Aug 2012 10:14:33 -0700 Subject: review request: 7184394: add intrinsics to use AES instructions In-Reply-To: References: <500451D3.5080802@oracle.com> <5004667C.5020503@oracle.com> <5008930F.8060105@oracle.com> <5011C967.1060304@oracle.com> <877gt8aqsl.fsf@oracle.com> <952D2337-5D8A-4C45-9D20-78DAA3C1C151@amd.com> <068AE61F-CBA3-491E-A8BF-9BC7B4C96C2A@oracle.com> Message-ID: <965404F4-CE9A-4B07-8CFD-91EE9C6372DA@oracle.com> On Aug 16, 2012, at 7:11 AM, Eric Caspole wrote: > Hi Christian, > I think I addressed all your comments and fixed the funny spacing. Here is the update: > > http://cr.openjdk.java.net/~ecaspole/tom_aes/webrev.01/ Looks good. -- Chris > > Regards, > Eric > > > On Aug 13, 2012, at 6:22 PM, Christian Thalinger wrote: > >> >> On Aug 13, 2012, at 10:15 AM, Eric Caspole wrote: >> >>> Hi Roland and Vladimir, >>> Tom is on vacation for another week so I updated the AES webrev code according to your comments, so we don't miss out on any deadlines or testing opportunities. >>> >>> http://cr.openjdk.java.net/~ecaspole/tom_aes/webrev/ >> >> src/cpu/x86/vm/stubGenerator_x86_32.cpp: >> >> + void loadKey(XMMRegister xmmdst, Register key, int ofst, XMMRegister xmm_shuf_mask=NULL) { >> + void aesencKey(XMMRegister xmmdst, XMMRegister xmmtmp, Register key, int ofst, XMMRegister xmm_shuf_mask=NULL) { >> + void aesdecKey(XMMRegister xmmdst, XMMRegister xmmtmp, Register key, int ofst, XMMRegister xmm_shuf_mask=NULL) { >> >> Can we use non-camel case names for these methods? >> >> + for (int ofst = 0x10; ofst <= 0x90; ofst += 0x10) { >> >> I guess ofst means offset. If so, could we rename it? >> >> + __ jcc(Assembler::notEqual,L_singleBlock_loopTop_192); >> + for (int rnum = XMM_REG_NUM_KEY_FIRST + 1; rnum <= XMM_REG_NUM_KEY_LAST; rnum++) { >> >> Spacing is sometimes odd (no space, two spaces). >> >> src/cpu/x86/vm/vm_version_x86.cpp: >> >> 474 // Use AES instructions if available. >> 475 if (supports_aes()) { >> 476 if (FLAG_IS_DEFAULT(UseAES)) { >> 477 UseAES = true; >> 478 } >> 479 } else if (UseAES) { >> 480 if (!FLAG_IS_DEFAULT(UseAES)) >> 481 warning("AES instructions not available on this CPU"); >> 482 FLAG_SET_DEFAULT(UseAES, false); >> 483 } >> 484 >> 485 // The AES intrinsic stubs require AES instruction support (of course) >> 486 // but also require AVX mode for misaligned SSE access >> 487 if (UseAES && (UseAVX > 0)) { >> 488 if (FLAG_IS_DEFAULT(UseAESIntrinsics)) { >> 489 UseAESIntrinsics = true; >> 490 } >> 491 } else if (UseAESIntrinsics) { >> 492 if (!FLAG_IS_DEFAULT(UseAESIntrinsics)) >> 493 warning("AES intrinsics not available on this CPU"); >> 494 FLAG_SET_DEFAULT(UseAESIntrinsics, false); >> 495 } >> 496 >> >> The indentation is off. >> >> src/share/vm/classfile/vmSymbols.hpp: >> >> 722 /* support for com.sum.crypto.provider.AESCrypt and some of its callers */ \ >> 723 do_class(com_sun_crypto_provider_aescrypt, "com/sun/crypto/provider/AESCrypt") \ >> 724 do_intrinsic(_aescrypt_encryptBlock, com_sun_crypto_provider_aescrypt, encryptBlock_name, byteArray_int_byteArray_int_signature, F_R) \ >> 725 do_intrinsic(_aescrypt_decryptBlock, com_sun_crypto_provider_aescrypt, decryptBlock_name, byteArray_int_byteArray_int_signature, F_R) \ >> 726 do_name( encryptBlock_name, "encryptBlock") \ >> 727 do_name( decryptBlock_name, "decryptBlock") \ >> 728 do_signature(byteArray_int_byteArray_int_signature, "([BI[BI)V") \ >> 729 \ >> 730 do_class(com_sun_crypto_provider_cipherBlockChaining, "com/sun/crypto/provider/CipherBlockChaining") \ >> 731 do_intrinsic(_cipherBlockChaining_encryptAESCrypt, com_sun_crypto_provider_cipherBlockChaining, encrypt_name, byteArray_int_int_byteArray_int_signature, F_R) \ >> 732 do_intrinsic(_cipherBlockChaining_decryptAESCrypt, com_sun_crypto_provider_cipherBlockChaining, decrypt_name, byteArray_int_int_byteArray_int_signature, F_R) \ >> 733 do_name( encrypt_name, "encrypt") \ >> 734 do_name( decrypt_name, "decrypt") \ >> 735 do_signature(byteArray_int_int_byteArray_int_signature, "([BII[BI)V") \ >> >> Same here. We try to keep them aligned for better readability: >> >> src/share/vm/oops/methodOop.cpp: >> >> + strcmp(instanceKlass::cast(holder)->class_loader()->klass()->klass_part()->external_name(), "sun.misc.Launcher$ExtClassLoader") != 0) >> >> I think we should define a vmSymbol for the class loader name and do a pointer compare. I don't like the strcmp here. >> >> src/share/vm/opto/escape.cpp: >> >> + char str[200]; >> + sprintf(str, "EA: unexpected CallLeaf %s", call->as_CallLeaf()->_name); >> + assert(false, str); >> >> You should use err_msg_res and guarantee here like: >> >> + guarantee(err_msg_res("EA: unexpected CallLeaf %s", call->as_CallLeaf()->_name)); >> >> Otherwise this looks good. >> >> -- Chris >> >>> >>> Let us know what you think. >>> Thanks, >>> Eric >>> >>> On Aug 9, 2012, at 2:00 PM, Roland Westrelin wrote: >>> >>>> >>>> Hi Tom, >>>> >>>>> http://cr.openjdk.java.net/~tdeneau/aes-intrinsics/webrev.04 >>>>> >>>>> has been posted which addresses the issues that Vladimir raised. >>>> >>>> In callGenerator.cpp, this should go away: >>>> >>>> 966 // Vladimir said to remove this check >>>> 967 if (false && kit.stopped()) { >>>> 968 // Receiver's null check or other exception. >>>> 969 return kit.transfer_exceptions_into_jvms(); >>>> 970 } >>>> >>>> In library_call.cpp, typos: >>>> >>>> 5784 // the psuedo code we want to emulate with this predicate is: >>>> >>>> 5811 // we want to an instanceof comparison against the AESCrypt class >>>> >>>> Also, it looks like this should go away as well: >>>> >>>> 5840 if (false) { >>>> 5841 // src and dest are arrays. >>>> 5842 const Type* src_type = src->Value(&_gvn); >>>> 5843 const Type* dest_type = dest->Value(&_gvn); >>>> 5844 const TypeAryPtr* top_src = src_type->isa_aryptr(); >>>> 5845 const TypeAryPtr* top_dest = dest_type->isa_aryptr(); >>>> 5846 assert (top_src != NULL && top_src->klass() != NULL >>>> 5847 && top_dest != NULL && top_dest->klass() != NULL, "args are strange"); >>>> 5848 } >>>> >>>> Otherwise, I think it'ok to me. >>>> >>>> Roland. >>>> >>> >>> >> >> > > From vladimir.kozlov at oracle.com Thu Aug 16 15:58:31 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Aug 2012 15:58:31 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502D2847.1000301@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> Message-ID: <502D7B17.4010201@oracle.com> http://cr.openjdk.java.net/~kvn/7190310/webrev.02 I updated changes as discussed here. I removed membar generation in C1 code because intrinsic nodes and not optimized by C1 GVN. I kept my klass analysis changes in C1 and checks move from G1 stub. Thanks, Vladimir Vladimir Kozlov wrote: > Roland Westrelin wrote: >>> In C2 two reads (one outside a loop and an other inside) have the >>> same inputs so IGVN replace second with dominating one outside the >>> loop. I don't know if C1 does it now but nothing prevents from this >>> in a future when someone decide to add more optimization into C1. On >>> other hand it is unsafe reads (in HIR level), I doubt it will be >>> allowed to common unsafe reads. >> >> GVN in c1 operates on the HIR. Reference.get() is inlined in the HIR >> as an Intrinsic instruction node. Intrinsic instructions do not >> participate in GVN (something you find out by looking at the Intrinsic >> definition in c1_Instruction.hpp and checking whether it uses one of >> the HASHING{1,2,3} macro). So no Intrinsic instruction will be >> eliminated by GVN. > > Good, I was thinking the same. Just always (before it was only for G1) > generating Reference.get() intrinsic will be enough. I will remove > membar from there. > >> >> The other thing that could access the same field would be an >> UnsafeGetObject, right? GVN ignores this one as well. > > Right only these 2 cases. > >> >> When LIR is built, the UnsafeGetObject and the Reference.get() >> Intrinsic nodes become loads. No optimizations are then applied so no >> load will go away. > > I did not realized that UnsafeGetObject is like intrinsic node. > >> >> So to me, we are safe on the c1 side. > > Good, then I don't need membar in do_UnsafeGetObject() also. > > What do you think about my move of some checks from G1 stub into > do_UnsafeGetObject()? And about klass analysis there? > > Thanks, > Vladimir > >> >> Roland. From john.coomes at oracle.com Thu Aug 16 20:38:49 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 03:38:49 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b52 for changeset 8d24def5ceb3 Message-ID: <20120817033849.BC64C47580@hg.openjdk.java.net> Changeset: febd7ff52800 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/febd7ff52800 Added tag jdk8-b52 for changeset 8d24def5ceb3 ! .hgtags From john.coomes at oracle.com Thu Aug 16 20:38:54 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 03:38:54 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b52 for changeset 80689ff9cb49 Message-ID: <20120817033856.2A60C47581@hg.openjdk.java.net> Changeset: 63aeb7a2472f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/63aeb7a2472f Added tag jdk8-b52 for changeset 80689ff9cb49 ! .hgtags From john.coomes at oracle.com Thu Aug 16 20:39:01 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 03:39:01 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b52 for changeset bd3c00d57614 Message-ID: <20120817033909.B732C47582@hg.openjdk.java.net> Changeset: 2c566f25c39f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/2c566f25c39f Added tag jdk8-b52 for changeset bd3c00d57614 ! .hgtags From john.coomes at oracle.com Thu Aug 16 20:39:14 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 03:39:14 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b52 for changeset f62bc618122e Message-ID: <20120817033919.E8AD547583@hg.openjdk.java.net> Changeset: 8a35fd644d3c Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/8a35fd644d3c Added tag jdk8-b52 for changeset f62bc618122e ! .hgtags From john.coomes at oracle.com Thu Aug 16 20:39:30 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 03:39:30 +0000 Subject: hg: hsx/hotspot-comp/jdk: 4 new changesets Message-ID: <20120817034047.8896847584@hg.openjdk.java.net> Changeset: 93ddd9560751 Author: youdwei Date: 2012-08-13 10:45 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/93ddd9560751 7189611: Venezuela current Currency should be Bs.F. Reviewed-by: okutsu ! src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 90a9acfde9e6 Author: mfang Date: 2012-08-13 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/90a9acfde9e6 Merge Changeset: e8569a473cee Author: katleman Date: 2012-08-15 18:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e8569a473cee Merge Changeset: 2c6933c5106b Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2c6933c5106b Added tag jdk8-b52 for changeset e8569a473cee ! .hgtags From john.coomes at oracle.com Thu Aug 16 20:41:55 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 03:41:55 +0000 Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b52 for changeset 1d2db0e5eabc Message-ID: <20120817034202.126C447585@hg.openjdk.java.net> Changeset: d3d0b9cd76e0 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d3d0b9cd76e0 Added tag jdk8-b52 for changeset 1d2db0e5eabc ! .hgtags From roland.westrelin at oracle.com Fri Aug 17 01:42:53 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 17 Aug 2012 10:42:53 +0200 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502D7B17.4010201@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> Message-ID: <4B88E78A-A185-431B-ADE1-D0241A7CEA3B@oracle.com> > http://cr.openjdk.java.net/~kvn/7190310/webrev.02 > > I updated changes as discussed here. I removed membar generation in C1 code because intrinsic nodes and not optimized by C1 GVN. > I kept my klass analysis changes in C1 and checks move from G1 stub. That looks good to me. Roland. From vladimir.kozlov at oracle.com Fri Aug 17 09:12:41 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Aug 2012 09:12:41 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <4B88E78A-A185-431B-ADE1-D0241A7CEA3B@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> <4B88E78A-A185-431B-ADE1-D0241A7CEA3B@oracle.com> Message-ID: <502E6D79.4080405@oracle.com> Thank you, Roland Vladimir Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/7190310/webrev.02 >> >> I updated changes as discussed here. I removed membar generation in C1 code because intrinsic nodes and not optimized by C1 GVN. >> I kept my klass analysis changes in C1 and checks move from G1 stub. > > That looks good to me. > > Roland. From christian.thalinger at oracle.com Fri Aug 17 11:21:48 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 17 Aug 2012 11:21:48 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502D7B17.4010201@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> Message-ID: <5D83519B-41D0-489B-8C2B-6870219FF348@oracle.com> Looks good. -- Chris On Aug 16, 2012, at 3:58 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7190310/webrev.02 > > I updated changes as discussed here. I removed membar generation in C1 code because intrinsic nodes and not optimized by C1 GVN. > I kept my klass analysis changes in C1 and checks move from G1 stub. > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> Roland Westrelin wrote: >>>> In C2 two reads (one outside a loop and an other inside) have the same inputs so IGVN replace second with dominating one outside the loop. I don't know if C1 does it now but nothing prevents from this in a future when someone decide to add more optimization into C1. On other hand it is unsafe reads (in HIR level), I doubt it will be allowed to common unsafe reads. >>> >>> GVN in c1 operates on the HIR. Reference.get() is inlined in the HIR as an Intrinsic instruction node. Intrinsic instructions do not participate in GVN (something you find out by looking at the Intrinsic definition in c1_Instruction.hpp and checking whether it uses one of the HASHING{1,2,3} macro). So no Intrinsic instruction will be eliminated by GVN. >> Good, I was thinking the same. Just always (before it was only for G1) generating Reference.get() intrinsic will be enough. I will remove membar from there. >>> >>> The other thing that could access the same field would be an UnsafeGetObject, right? GVN ignores this one as well. >> Right only these 2 cases. >>> >>> When LIR is built, the UnsafeGetObject and the Reference.get() Intrinsic nodes become loads. No optimizations are then applied so no load will go away. >> I did not realized that UnsafeGetObject is like intrinsic node. >>> >>> So to me, we are safe on the c1 side. >> Good, then I don't need membar in do_UnsafeGetObject() also. >> What do you think about my move of some checks from G1 stub into do_UnsafeGetObject()? And about klass analysis there? >> Thanks, >> Vladimir >>> >>> Roland. From vladimir.kozlov at oracle.com Fri Aug 17 11:26:20 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Aug 2012 11:26:20 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <5D83519B-41D0-489B-8C2B-6870219FF348@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> <5D83519B-41D0-489B-8C2B-6870219FF348@oracle.com> Message-ID: <502E8CCC.7060007@oracle.com> Thank you, Christian Vladimir Christian Thalinger wrote: > Looks good. -- Chris > > On Aug 16, 2012, at 3:58 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7190310/webrev.02 >> >> I updated changes as discussed here. I removed membar generation in C1 code because intrinsic nodes and not optimized by C1 GVN. >> I kept my klass analysis changes in C1 and checks move from G1 stub. >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> Roland Westrelin wrote: >>>>> In C2 two reads (one outside a loop and an other inside) have the same inputs so IGVN replace second with dominating one outside the loop. I don't know if C1 does it now but nothing prevents from this in a future when someone decide to add more optimization into C1. On other hand it is unsafe reads (in HIR level), I doubt it will be allowed to common unsafe reads. >>>> GVN in c1 operates on the HIR. Reference.get() is inlined in the HIR as an Intrinsic instruction node. Intrinsic instructions do not participate in GVN (something you find out by looking at the Intrinsic definition in c1_Instruction.hpp and checking whether it uses one of the HASHING{1,2,3} macro). So no Intrinsic instruction will be eliminated by GVN. >>> Good, I was thinking the same. Just always (before it was only for G1) generating Reference.get() intrinsic will be enough. I will remove membar from there. >>>> The other thing that could access the same field would be an UnsafeGetObject, right? GVN ignores this one as well. >>> Right only these 2 cases. >>>> When LIR is built, the UnsafeGetObject and the Reference.get() Intrinsic nodes become loads. No optimizations are then applied so no load will go away. >>> I did not realized that UnsafeGetObject is like intrinsic node. >>>> So to me, we are safe on the c1 side. >>> Good, then I don't need membar in do_UnsafeGetObject() also. >>> What do you think about my move of some checks from G1 stub into do_UnsafeGetObject()? And about klass analysis there? >>> Thanks, >>> Vladimir >>>> Roland. > From john.cuthbertson at oracle.com Fri Aug 17 11:50:17 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 17 Aug 2012 11:50:17 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502D7B17.4010201@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> Message-ID: <502E9269.9040501@oracle.com> Hi Vladimir, This looks good to me. I do, however, have one question. In LIRGenerator::do_UnsafeGetObject(), since you have moved a number of the filters into this routine, can we now call LirGenerator::pre_barrier() with NULL, reg, false, false, NULL) instead of instantiating G1UnsafeGetObjSATBBarrierStub - where reg is the result of get_Object_unsafe()? Moving the filters into the LIR have made this stub and the regular G1 pre-barrier stub very similar. That way we can remove the now unused G1UnsafeGetObjSATBBarrierStub. Thanks, JohnC On 08/16/12 15:58, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7190310/webrev.02 > > I updated changes as discussed here. I removed membar generation in C1 > code because intrinsic nodes and not optimized by C1 GVN. > I kept my klass analysis changes in C1 and checks move from G1 stub. > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> Roland Westrelin wrote: >>>> In C2 two reads (one outside a loop and an other inside) have the >>>> same inputs so IGVN replace second with dominating one outside the >>>> loop. I don't know if C1 does it now but nothing prevents from this >>>> in a future when someone decide to add more optimization into C1. >>>> On other hand it is unsafe reads (in HIR level), I doubt it will be >>>> allowed to common unsafe reads. >>> >>> GVN in c1 operates on the HIR. Reference.get() is inlined in the HIR >>> as an Intrinsic instruction node. Intrinsic instructions do not >>> participate in GVN (something you find out by looking at the >>> Intrinsic definition in c1_Instruction.hpp and checking whether it >>> uses one of the HASHING{1,2,3} macro). So no Intrinsic instruction >>> will be eliminated by GVN. >> >> Good, I was thinking the same. Just always (before it was only for >> G1) generating Reference.get() intrinsic will be enough. I will >> remove membar from there. >> >>> >>> The other thing that could access the same field would be an >>> UnsafeGetObject, right? GVN ignores this one as well. >> >> Right only these 2 cases. >> >>> >>> When LIR is built, the UnsafeGetObject and the Reference.get() >>> Intrinsic nodes become loads. No optimizations are then applied so >>> no load will go away. >> >> I did not realized that UnsafeGetObject is like intrinsic node. >> >>> >>> So to me, we are safe on the c1 side. >> >> Good, then I don't need membar in do_UnsafeGetObject() also. >> >> What do you think about my move of some checks from G1 stub into >> do_UnsafeGetObject()? And about klass analysis there? >> >> Thanks, >> Vladimir >> >>> >>> Roland. From vladimir.kozlov at oracle.com Fri Aug 17 11:59:09 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Aug 2012 11:59:09 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502E9269.9040501@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> <502E9269.9040501@oracle.com> Message-ID: <502E947D.9040305@oracle.com> Yes, I do like cleanup unused code :) I did suggested changes and verified generated asm code. Bug's tests passed. Here is updated (I hope final) webrev with C1 G1UnsafeGetObjSATBBarrierStub gone on all platforms: http://cr.openjdk.java.net/~kvn/7190310/webrev.03 Thanks, Vladimir John Cuthbertson wrote: > Hi Vladimir, > > This looks good to me. > > I do, however, have one question. In LIRGenerator::do_UnsafeGetObject(), > since you have moved a number of the filters into this routine, can we > now call LirGenerator::pre_barrier() with NULL, reg, false, false, NULL) > instead of instantiating G1UnsafeGetObjSATBBarrierStub - where reg is > the result of get_Object_unsafe()? Moving the filters into the LIR have > made this stub and the regular G1 pre-barrier stub very similar. That > way we can remove the now unused G1UnsafeGetObjSATBBarrierStub. > > Thanks, > > JohnC > > On 08/16/12 15:58, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/7190310/webrev.02 >> >> I updated changes as discussed here. I removed membar generation in C1 >> code because intrinsic nodes and not optimized by C1 GVN. >> I kept my klass analysis changes in C1 and checks move from G1 stub. >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> Roland Westrelin wrote: >>>>> In C2 two reads (one outside a loop and an other inside) have the >>>>> same inputs so IGVN replace second with dominating one outside the >>>>> loop. I don't know if C1 does it now but nothing prevents from this >>>>> in a future when someone decide to add more optimization into C1. >>>>> On other hand it is unsafe reads (in HIR level), I doubt it will be >>>>> allowed to common unsafe reads. >>>> >>>> GVN in c1 operates on the HIR. Reference.get() is inlined in the HIR >>>> as an Intrinsic instruction node. Intrinsic instructions do not >>>> participate in GVN (something you find out by looking at the >>>> Intrinsic definition in c1_Instruction.hpp and checking whether it >>>> uses one of the HASHING{1,2,3} macro). So no Intrinsic instruction >>>> will be eliminated by GVN. >>> >>> Good, I was thinking the same. Just always (before it was only for >>> G1) generating Reference.get() intrinsic will be enough. I will >>> remove membar from there. >>> >>>> >>>> The other thing that could access the same field would be an >>>> UnsafeGetObject, right? GVN ignores this one as well. >>> >>> Right only these 2 cases. >>> >>>> >>>> When LIR is built, the UnsafeGetObject and the Reference.get() >>>> Intrinsic nodes become loads. No optimizations are then applied so >>>> no load will go away. >>> >>> I did not realized that UnsafeGetObject is like intrinsic node. >>> >>>> >>>> So to me, we are safe on the c1 side. >>> >>> Good, then I don't need membar in do_UnsafeGetObject() also. >>> >>> What do you think about my move of some checks from G1 stub into >>> do_UnsafeGetObject()? And about klass analysis there? >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Roland. > From christian.thalinger at oracle.com Fri Aug 17 13:35:03 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 17 Aug 2012 13:35:03 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502E947D.9040305@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> <502E9269.9040501@oracle.com> <502E947D.9040305@oracle.com> Message-ID: <3E6A0DF7-929B-4C03-941B-2C2E8868A405@oracle.com> On Aug 17, 2012, at 11:59 AM, Vladimir Kozlov wrote: > Yes, I do like cleanup unused code :) > > I did suggested changes and verified generated asm code. Bug's tests passed. Here is updated (I hope final) webrev with C1 G1UnsafeGetObjSATBBarrierStub gone on all platforms: > > http://cr.openjdk.java.net/~kvn/7190310/webrev.03 Even better. -- Chris > > Thanks, > Vladimir > > John Cuthbertson wrote: >> Hi Vladimir, >> This looks good to me. >> I do, however, have one question. In LIRGenerator::do_UnsafeGetObject(), since you have moved a number of the filters into this routine, can we now call LirGenerator::pre_barrier() with NULL, reg, false, false, NULL) instead of instantiating G1UnsafeGetObjSATBBarrierStub - where reg is the result of get_Object_unsafe()? Moving the filters into the LIR have made this stub and the regular G1 pre-barrier stub very similar. That way we can remove the now unused G1UnsafeGetObjSATBBarrierStub. >> Thanks, >> JohnC >> On 08/16/12 15:58, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7190310/webrev.02 >>> >>> I updated changes as discussed here. I removed membar generation in C1 code because intrinsic nodes and not optimized by C1 GVN. >>> I kept my klass analysis changes in C1 and checks move from G1 stub. >>> >>> Thanks, >>> Vladimir >>> >>> Vladimir Kozlov wrote: >>>> Roland Westrelin wrote: >>>>>> In C2 two reads (one outside a loop and an other inside) have the same inputs so IGVN replace second with dominating one outside the loop. I don't know if C1 does it now but nothing prevents from this in a future when someone decide to add more optimization into C1. On other hand it is unsafe reads (in HIR level), I doubt it will be allowed to common unsafe reads. >>>>> >>>>> GVN in c1 operates on the HIR. Reference.get() is inlined in the HIR as an Intrinsic instruction node. Intrinsic instructions do not participate in GVN (something you find out by looking at the Intrinsic definition in c1_Instruction.hpp and checking whether it uses one of the HASHING{1,2,3} macro). So no Intrinsic instruction will be eliminated by GVN. >>>> >>>> Good, I was thinking the same. Just always (before it was only for G1) generating Reference.get() intrinsic will be enough. I will remove membar from there. >>>> >>>>> >>>>> The other thing that could access the same field would be an UnsafeGetObject, right? GVN ignores this one as well. >>>> >>>> Right only these 2 cases. >>>> >>>>> >>>>> When LIR is built, the UnsafeGetObject and the Reference.get() Intrinsic nodes become loads. No optimizations are then applied so no load will go away. >>>> >>>> I did not realized that UnsafeGetObject is like intrinsic node. >>>> >>>>> >>>>> So to me, we are safe on the c1 side. >>>> >>>> Good, then I don't need membar in do_UnsafeGetObject() also. >>>> >>>> What do you think about my move of some checks from G1 stub into do_UnsafeGetObject()? And about klass analysis there? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Roland. From john.cuthbertson at oracle.com Fri Aug 17 14:35:56 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 17 Aug 2012 14:35:56 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502E947D.9040305@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> <502E9269.9040501@oracle.com> <502E947D.9040305@oracle.com> Message-ID: <502EB93C.1020900@oracle.com> Hi Vladimir, Looks good. JohnC On 08/17/12 11:59, Vladimir Kozlov wrote: > Yes, I do like cleanup unused code :) > > I did suggested changes and verified generated asm code. Bug's tests > passed. Here is updated (I hope final) webrev with C1 > G1UnsafeGetObjSATBBarrierStub gone on all platforms: > > http://cr.openjdk.java.net/~kvn/7190310/webrev.03 > > Thanks, > Vladimir > > John Cuthbertson wrote: >> Hi Vladimir, >> >> This looks good to me. >> >> I do, however, have one question. In >> LIRGenerator::do_UnsafeGetObject(), since you have moved a number of >> the filters into this routine, can we now call >> LirGenerator::pre_barrier() with NULL, reg, false, false, NULL) >> instead of instantiating G1UnsafeGetObjSATBBarrierStub - where reg is >> the result of get_Object_unsafe()? Moving the filters into the LIR >> have made this stub and the regular G1 pre-barrier stub very similar. >> That way we can remove the now unused G1UnsafeGetObjSATBBarrierStub. >> >> Thanks, >> >> JohnC >> >> On 08/16/12 15:58, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7190310/webrev.02 >>> >>> I updated changes as discussed here. I removed membar generation in >>> C1 code because intrinsic nodes and not optimized by C1 GVN. >>> I kept my klass analysis changes in C1 and checks move from G1 stub. >>> >>> Thanks, >>> Vladimir >>> >>> Vladimir Kozlov wrote: >>>> Roland Westrelin wrote: >>>>>> In C2 two reads (one outside a loop and an other inside) have the >>>>>> same inputs so IGVN replace second with dominating one outside >>>>>> the loop. I don't know if C1 does it now but nothing prevents >>>>>> from this in a future when someone decide to add more >>>>>> optimization into C1. On other hand it is unsafe reads (in HIR >>>>>> level), I doubt it will be allowed to common unsafe reads. >>>>> >>>>> GVN in c1 operates on the HIR. Reference.get() is inlined in the >>>>> HIR as an Intrinsic instruction node. Intrinsic instructions do >>>>> not participate in GVN (something you find out by looking at the >>>>> Intrinsic definition in c1_Instruction.hpp and checking whether it >>>>> uses one of the HASHING{1,2,3} macro). So no Intrinsic instruction >>>>> will be eliminated by GVN. >>>> >>>> Good, I was thinking the same. Just always (before it was only for >>>> G1) generating Reference.get() intrinsic will be enough. I will >>>> remove membar from there. >>>> >>>>> >>>>> The other thing that could access the same field would be an >>>>> UnsafeGetObject, right? GVN ignores this one as well. >>>> >>>> Right only these 2 cases. >>>> >>>>> >>>>> When LIR is built, the UnsafeGetObject and the Reference.get() >>>>> Intrinsic nodes become loads. No optimizations are then applied so >>>>> no load will go away. >>>> >>>> I did not realized that UnsafeGetObject is like intrinsic node. >>>> >>>>> >>>>> So to me, we are safe on the c1 side. >>>> >>>> Good, then I don't need membar in do_UnsafeGetObject() also. >>>> >>>> What do you think about my move of some checks from G1 stub into >>>> do_UnsafeGetObject()? And about klass analysis there? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Roland. >> From vladimir.kozlov at oracle.com Fri Aug 17 14:57:01 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Aug 2012 14:57:01 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502EB93C.1020900@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> <502E9269.9040501@oracle.com> <502E947D.9040305@oracle.com> <502EB93C.1020900@oracle.com> Message-ID: <502EBE2D.3040401@oracle.com> Thank you, John Vladimir John Cuthbertson wrote: > Hi Vladimir, > > Looks good. > > JohnC > > On 08/17/12 11:59, Vladimir Kozlov wrote: >> Yes, I do like cleanup unused code :) >> >> I did suggested changes and verified generated asm code. Bug's tests >> passed. Here is updated (I hope final) webrev with C1 >> G1UnsafeGetObjSATBBarrierStub gone on all platforms: >> >> http://cr.openjdk.java.net/~kvn/7190310/webrev.03 >> >> Thanks, >> Vladimir >> >> John Cuthbertson wrote: >>> Hi Vladimir, >>> >>> This looks good to me. >>> >>> I do, however, have one question. In >>> LIRGenerator::do_UnsafeGetObject(), since you have moved a number of >>> the filters into this routine, can we now call >>> LirGenerator::pre_barrier() with NULL, reg, false, false, NULL) >>> instead of instantiating G1UnsafeGetObjSATBBarrierStub - where reg is >>> the result of get_Object_unsafe()? Moving the filters into the LIR >>> have made this stub and the regular G1 pre-barrier stub very similar. >>> That way we can remove the now unused G1UnsafeGetObjSATBBarrierStub. >>> >>> Thanks, >>> >>> JohnC >>> >>> On 08/16/12 15:58, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7190310/webrev.02 >>>> >>>> I updated changes as discussed here. I removed membar generation in >>>> C1 code because intrinsic nodes and not optimized by C1 GVN. >>>> I kept my klass analysis changes in C1 and checks move from G1 stub. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Vladimir Kozlov wrote: >>>>> Roland Westrelin wrote: >>>>>>> In C2 two reads (one outside a loop and an other inside) have the >>>>>>> same inputs so IGVN replace second with dominating one outside >>>>>>> the loop. I don't know if C1 does it now but nothing prevents >>>>>>> from this in a future when someone decide to add more >>>>>>> optimization into C1. On other hand it is unsafe reads (in HIR >>>>>>> level), I doubt it will be allowed to common unsafe reads. >>>>>> >>>>>> GVN in c1 operates on the HIR. Reference.get() is inlined in the >>>>>> HIR as an Intrinsic instruction node. Intrinsic instructions do >>>>>> not participate in GVN (something you find out by looking at the >>>>>> Intrinsic definition in c1_Instruction.hpp and checking whether it >>>>>> uses one of the HASHING{1,2,3} macro). So no Intrinsic instruction >>>>>> will be eliminated by GVN. >>>>> >>>>> Good, I was thinking the same. Just always (before it was only for >>>>> G1) generating Reference.get() intrinsic will be enough. I will >>>>> remove membar from there. >>>>> >>>>>> >>>>>> The other thing that could access the same field would be an >>>>>> UnsafeGetObject, right? GVN ignores this one as well. >>>>> >>>>> Right only these 2 cases. >>>>> >>>>>> >>>>>> When LIR is built, the UnsafeGetObject and the Reference.get() >>>>>> Intrinsic nodes become loads. No optimizations are then applied so >>>>>> no load will go away. >>>>> >>>>> I did not realized that UnsafeGetObject is like intrinsic node. >>>>> >>>>>> >>>>>> So to me, we are safe on the c1 side. >>>>> >>>>> Good, then I don't need membar in do_UnsafeGetObject() also. >>>>> >>>>> What do you think about my move of some checks from G1 stub into >>>>> do_UnsafeGetObject()? And about klass analysis there? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Roland. >>> > From alejandro.murillo at oracle.com Fri Aug 17 18:08:54 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 18 Aug 2012 01:08:54 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 5 new changesets Message-ID: <20120818010905.17240475BA@hg.openjdk.java.net> Changeset: ef437ea56651 Author: amurillo Date: 2012-08-03 13:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ef437ea56651 7189086: new hotspot build - hs24-b20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 4c8f2a12e757 Author: twisti Date: 2012-08-10 17:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4c8f2a12e757 Merge Changeset: 6d0436885201 Author: amurillo Date: 2012-08-10 23:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6d0436885201 Added tag hs24-b20 for changeset 4c8f2a12e757 ! .hgtags Changeset: 6898d85cf0bb Author: amurillo Date: 2012-08-10 23:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6898d85cf0bb 7190772: new hotspot build - hs24-b21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d5ec46c7da5c Author: amurillo Date: 2012-08-15 16:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d5ec46c7da5c 7191765: make jdk8 the default jprt release for hs24 Reviewed-by: jcoomes ! make/jprt.properties From christian.thalinger at oracle.com Fri Aug 17 18:17:03 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 17 Aug 2012 18:17:03 -0700 Subject: Request for reviews (S): 7192167: JSR 292: C1 has old broken code which needs to be removed Message-ID: http://cr.openjdk.java.net/~twisti/7192167 7192167: JSR 292: C1 has old broken code which needs to be removed Reviewed-by: Some code in C1 is still from the old JSR 292 implementation and is completely wrong. It works right now because we force all lambda form adapters to inline. When disabling inlining it fails immediately with SEGVs and friends. Additionally I removed some unused code in C2. src/share/vm/c1/c1_GraphBuilder.cpp src/share/vm/c1/c1_Instruction.cpp src/share/vm/c1/c1_LIRAssembler.cpp src/share/vm/c1/c1_LIRGenerator.cpp src/share/vm/opto/callGenerator.cpp From vladimir.kozlov at oracle.com Fri Aug 17 18:55:46 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Aug 2012 18:55:46 -0700 Subject: Request for reviews (S): 7192167: JSR 292: C1 has old broken code which needs to be removed In-Reply-To: References: Message-ID: <502EF622.5030300@oracle.com> This looks good. Vladimir On 8/17/12 6:17 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7192167 > > 7192167: JSR 292: C1 has old broken code which needs to be removed > Reviewed-by: > > Some code in C1 is still from the old JSR 292 implementation and is > completely wrong. It works right now because we force all lambda form > adapters to inline. When disabling inlining it fails immediately > with SEGVs and friends. > > Additionally I removed some unused code in C2. > > src/share/vm/c1/c1_GraphBuilder.cpp > src/share/vm/c1/c1_Instruction.cpp > src/share/vm/c1/c1_LIRAssembler.cpp > src/share/vm/c1/c1_LIRGenerator.cpp > src/share/vm/opto/callGenerator.cpp > From john.r.rose at oracle.com Sat Aug 18 15:12:24 2012 From: john.r.rose at oracle.com (John Rose) Date: Sat, 18 Aug 2012 15:12:24 -0700 Subject: Request for reviews (S): 7192167: JSR 292: C1 has old broken code which needs to be removed In-Reply-To: References: Message-ID: <2D2A947F-7D63-4251-AFFE-20A689D3C2EE@oracle.com> Looks good. What tests now pass and how did you test the change? -- John (on my iPhone) On Aug 17, 2012, at 6:17 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7192167 > > 7192167: JSR 292: C1 has old broken code which needs to be removed > Reviewed-by: > > Some code in C1 is still from the old JSR 292 implementation and is > completely wrong. It works right now because we force all lambda form > adapters to inline. When disabling inlining it fails immediately > with SEGVs and friends. > > Additionally I removed some unused code in C2. > > src/share/vm/c1/c1_GraphBuilder.cpp > src/share/vm/c1/c1_Instruction.cpp > src/share/vm/c1/c1_LIRAssembler.cpp > src/share/vm/c1/c1_LIRGenerator.cpp > src/share/vm/opto/callGenerator.cpp > From david.holmes at oracle.com Sun Aug 19 15:09:14 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Aug 2012 08:09:14 +1000 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502E947D.9040305@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> <502E9269.9040501@oracle.com> <502E947D.9040305@oracle.com> Message-ID: <5031640A.80603@oracle.com> Minor typo in src/share/vm/c1/c1_GraphBuilder.cpp 3073 // Also we need intrinsic to to prevent commoning reads from this field "to to" -> "to" David On 18/08/2012 4:59 AM, Vladimir Kozlov wrote: > Yes, I do like cleanup unused code :) > > I did suggested changes and verified generated asm code. Bug's tests > passed. Here is updated (I hope final) webrev with C1 > G1UnsafeGetObjSATBBarrierStub gone on all platforms: > > http://cr.openjdk.java.net/~kvn/7190310/webrev.03 > > Thanks, > Vladimir > > John Cuthbertson wrote: >> Hi Vladimir, >> >> This looks good to me. >> >> I do, however, have one question. In >> LIRGenerator::do_UnsafeGetObject(), since you have moved a number of >> the filters into this routine, can we now call >> LirGenerator::pre_barrier() with NULL, reg, false, false, NULL) >> instead of instantiating G1UnsafeGetObjSATBBarrierStub - where reg is >> the result of get_Object_unsafe()? Moving the filters into the LIR >> have made this stub and the regular G1 pre-barrier stub very similar. >> That way we can remove the now unused G1UnsafeGetObjSATBBarrierStub. >> >> Thanks, >> >> JohnC >> >> On 08/16/12 15:58, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7190310/webrev.02 >>> >>> I updated changes as discussed here. I removed membar generation in >>> C1 code because intrinsic nodes and not optimized by C1 GVN. >>> I kept my klass analysis changes in C1 and checks move from G1 stub. >>> >>> Thanks, >>> Vladimir >>> >>> Vladimir Kozlov wrote: >>>> Roland Westrelin wrote: >>>>>> In C2 two reads (one outside a loop and an other inside) have the >>>>>> same inputs so IGVN replace second with dominating one outside the >>>>>> loop. I don't know if C1 does it now but nothing prevents from >>>>>> this in a future when someone decide to add more optimization into >>>>>> C1. On other hand it is unsafe reads (in HIR level), I doubt it >>>>>> will be allowed to common unsafe reads. >>>>> >>>>> GVN in c1 operates on the HIR. Reference.get() is inlined in the >>>>> HIR as an Intrinsic instruction node. Intrinsic instructions do not >>>>> participate in GVN (something you find out by looking at the >>>>> Intrinsic definition in c1_Instruction.hpp and checking whether it >>>>> uses one of the HASHING{1,2,3} macro). So no Intrinsic instruction >>>>> will be eliminated by GVN. >>>> >>>> Good, I was thinking the same. Just always (before it was only for >>>> G1) generating Reference.get() intrinsic will be enough. I will >>>> remove membar from there. >>>> >>>>> >>>>> The other thing that could access the same field would be an >>>>> UnsafeGetObject, right? GVN ignores this one as well. >>>> >>>> Right only these 2 cases. >>>> >>>>> >>>>> When LIR is built, the UnsafeGetObject and the Reference.get() >>>>> Intrinsic nodes become loads. No optimizations are then applied so >>>>> no load will go away. >>>> >>>> I did not realized that UnsafeGetObject is like intrinsic node. >>>> >>>>> >>>>> So to me, we are safe on the c1 side. >>>> >>>> Good, then I don't need membar in do_UnsafeGetObject() also. >>>> >>>> What do you think about my move of some checks from G1 stub into >>>> do_UnsafeGetObject()? And about klass analysis there? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Roland. >> From roland.westrelin at oracle.com Mon Aug 20 00:36:11 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 20 Aug 2012 09:36:11 +0200 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <502E947D.9040305@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> <502E9269.9040501@oracle.com> <502E947D.9040305@oracle.com> Message-ID: > I did suggested changes and verified generated asm code. Bug's tests passed. Here is updated (I hope final) webrev with C1 G1UnsafeGetObjSATBBarrierStub gone on all platforms: > > http://cr.openjdk.java.net/~kvn/7190310/webrev.03 Looks good. Roland. From roland.westrelin at oracle.com Mon Aug 20 00:42:05 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 20 Aug 2012 09:42:05 +0200 Subject: Request for reviews (S): 7192167: JSR 292: C1 has old broken code which needs to be removed In-Reply-To: References: Message-ID: <74E77647-CAA3-4654-8E23-935DB742AEAD@oracle.com> > http://cr.openjdk.java.net/~twisti/7192167 > > 7192167: JSR 292: C1 has old broken code which needs to be removed Looks good. Roland. From vladimir.kozlov at oracle.com Mon Aug 20 09:17:20 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Aug 2012 09:17:20 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: <5031640A.80603@oracle.com> References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> <502E9269.9040501@oracle.com> <502E947D.9040305@oracle.com> <5031640A.80603@oracle.com> Message-ID: <50326310.2060505@oracle.com> Thank you, David David Holmes wrote: > Minor typo in src/share/vm/c1/c1_GraphBuilder.cpp Fixed. Thanks, Vladimir > > 3073 // Also we need intrinsic to to prevent commoning reads > from this field > > "to to" -> "to" > > David > > On 18/08/2012 4:59 AM, Vladimir Kozlov wrote: >> Yes, I do like cleanup unused code :) >> >> I did suggested changes and verified generated asm code. Bug's tests >> passed. Here is updated (I hope final) webrev with C1 >> G1UnsafeGetObjSATBBarrierStub gone on all platforms: >> >> http://cr.openjdk.java.net/~kvn/7190310/webrev.03 >> >> Thanks, >> Vladimir >> >> John Cuthbertson wrote: >>> Hi Vladimir, >>> >>> This looks good to me. >>> >>> I do, however, have one question. In >>> LIRGenerator::do_UnsafeGetObject(), since you have moved a number of >>> the filters into this routine, can we now call >>> LirGenerator::pre_barrier() with NULL, reg, false, false, NULL) >>> instead of instantiating G1UnsafeGetObjSATBBarrierStub - where reg is >>> the result of get_Object_unsafe()? Moving the filters into the LIR >>> have made this stub and the regular G1 pre-barrier stub very similar. >>> That way we can remove the now unused G1UnsafeGetObjSATBBarrierStub. >>> >>> Thanks, >>> >>> JohnC >>> >>> On 08/16/12 15:58, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7190310/webrev.02 >>>> >>>> I updated changes as discussed here. I removed membar generation in >>>> C1 code because intrinsic nodes and not optimized by C1 GVN. >>>> I kept my klass analysis changes in C1 and checks move from G1 stub. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Vladimir Kozlov wrote: >>>>> Roland Westrelin wrote: >>>>>>> In C2 two reads (one outside a loop and an other inside) have the >>>>>>> same inputs so IGVN replace second with dominating one outside the >>>>>>> loop. I don't know if C1 does it now but nothing prevents from >>>>>>> this in a future when someone decide to add more optimization into >>>>>>> C1. On other hand it is unsafe reads (in HIR level), I doubt it >>>>>>> will be allowed to common unsafe reads. >>>>>> >>>>>> GVN in c1 operates on the HIR. Reference.get() is inlined in the >>>>>> HIR as an Intrinsic instruction node. Intrinsic instructions do not >>>>>> participate in GVN (something you find out by looking at the >>>>>> Intrinsic definition in c1_Instruction.hpp and checking whether it >>>>>> uses one of the HASHING{1,2,3} macro). So no Intrinsic instruction >>>>>> will be eliminated by GVN. >>>>> >>>>> Good, I was thinking the same. Just always (before it was only for >>>>> G1) generating Reference.get() intrinsic will be enough. I will >>>>> remove membar from there. >>>>> >>>>>> >>>>>> The other thing that could access the same field would be an >>>>>> UnsafeGetObject, right? GVN ignores this one as well. >>>>> >>>>> Right only these 2 cases. >>>>> >>>>>> >>>>>> When LIR is built, the UnsafeGetObject and the Reference.get() >>>>>> Intrinsic nodes become loads. No optimizations are then applied so >>>>>> no load will go away. >>>>> >>>>> I did not realized that UnsafeGetObject is like intrinsic node. >>>>> >>>>>> >>>>>> So to me, we are safe on the c1 side. >>>>> >>>>> Good, then I don't need membar in do_UnsafeGetObject() also. >>>>> >>>>> What do you think about my move of some checks from G1 stub into >>>>> do_UnsafeGetObject()? And about klass analysis there? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Roland. >>> From vladimir.kozlov at oracle.com Mon Aug 20 09:18:09 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Aug 2012 09:18:09 -0700 Subject: Request for reviews (S): 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops In-Reply-To: References: <5024651E.6040707@oracle.com> <50246976.9040003@oracle.com> <50246EAF.3000801@oracle.com> <8228829C-E215-4E47-A146-FEDC247B6F08@oracle.com> <5025404B.6070305@oracle.com> <502C302F.7000708@oracle.com> <092303AC-639F-40B5-BD08-1FAE996632DE@oracle.com> <502D1C5B.3010307@oracle.com> <50C68795-4A94-4638-B090-D9C7BF876704@oracle.com> <502D2847.1000301@oracle.com> <502D7B17.4010201@oracle.com> <502E9269.9040501@oracle.com> <502E947D.9040305@oracle.com> Message-ID: <50326341.4080804@oracle.com> Thank you, Roland Vladimir Roland Westrelin wrote: >> I did suggested changes and verified generated asm code. Bug's tests passed. Here is updated (I hope final) webrev with C1 G1UnsafeGetObjSATBBarrierStub gone on all platforms: >> >> http://cr.openjdk.java.net/~kvn/7190310/webrev.03 > > Looks good. > > Roland. From christian.thalinger at oracle.com Mon Aug 20 09:51:08 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 20 Aug 2012 09:51:08 -0700 Subject: Request for reviews (S): 7192167: JSR 292: C1 has old broken code which needs to be removed In-Reply-To: <2D2A947F-7D63-4251-AFFE-20A689D3C2EE@oracle.com> References: <2D2A947F-7D63-4251-AFFE-20A689D3C2EE@oracle.com> Message-ID: On Aug 18, 2012, at 3:12 PM, John Rose wrote: > Looks good. What tests now pass and how did you test the change? There were no failing tests because the force inline hid it. I did testing with Nashorn and JRuby with -XX:-Inline. -- Chris > > -- John (on my iPhone) > > On Aug 17, 2012, at 6:17 PM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7192167 >> >> 7192167: JSR 292: C1 has old broken code which needs to be removed >> Reviewed-by: >> >> Some code in C1 is still from the old JSR 292 implementation and is >> completely wrong. It works right now because we force all lambda form >> adapters to inline. When disabling inlining it fails immediately >> with SEGVs and friends. >> >> Additionally I removed some unused code in C2. >> >> src/share/vm/c1/c1_GraphBuilder.cpp >> src/share/vm/c1/c1_Instruction.cpp >> src/share/vm/c1/c1_LIRAssembler.cpp >> src/share/vm/c1/c1_LIRGenerator.cpp >> src/share/vm/opto/callGenerator.cpp >> From john.r.rose at oracle.com Mon Aug 20 10:29:57 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 20 Aug 2012 10:29:57 -0700 Subject: Request for reviews (S): 7192167: JSR 292: C1 has old broken code which needs to be removed In-Reply-To: References: <2D2A947F-7D63-4251-AFFE-20A689D3C2EE@oracle.com> Message-ID: <6529614E-12E5-432F-BA68-55D092E68918@oracle.com> On Aug 20, 2012, at 9:51 AM, Christian Thalinger wrote: > On Aug 18, 2012, at 3:12 PM, John Rose wrote: > >> Looks good. What tests now pass and how did you test the change? > > There were no failing tests because the force inline hid it. I did testing with Nashorn and JRuby with -XX:-Inline. Good -XX:-Inline counts as a stress test. We should do it more often, since we know our code is sensitive to it. Let's add -XX:-Inline as an extra mode in one of our jtreg tests, such as MethodHandlesTest. This can be done by duplicating the @test block with the changed @run option. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120820/2a4e055b/attachment-0001.html From vladimir.kozlov at oracle.com Mon Aug 20 11:12:19 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Mon, 20 Aug 2012 18:12:19 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 6340864: Implement vectorization optimizations in hotspot-server Message-ID: <20120820181223.C1E1847647@hg.openjdk.java.net> Changeset: 006050192a5a Author: kvn Date: 2012-08-20 09:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/006050192a5a 6340864: Implement vectorization optimizations in hotspot-server Summary: Added asm encoding and mach nodes for vector arithmetic instructions on x86. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/6340864/TestByteVect.java + test/compiler/6340864/TestDoubleVect.java + test/compiler/6340864/TestFloatVect.java + test/compiler/6340864/TestIntVect.java + test/compiler/6340864/TestLongVect.java + test/compiler/6340864/TestShortVect.java From christian.thalinger at oracle.com Mon Aug 20 11:22:56 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 20 Aug 2012 11:22:56 -0700 Subject: Request for reviews (S): 7192167: JSR 292: C1 has old broken code which needs to be removed In-Reply-To: <6529614E-12E5-432F-BA68-55D092E68918@oracle.com> References: <2D2A947F-7D63-4251-AFFE-20A689D3C2EE@oracle.com> <6529614E-12E5-432F-BA68-55D092E68918@oracle.com> Message-ID: On Aug 20, 2012, at 10:29 AM, John Rose wrote: > On Aug 20, 2012, at 9:51 AM, Christian Thalinger wrote: > >> On Aug 18, 2012, at 3:12 PM, John Rose wrote: >> >>> Looks good. What tests now pass and how did you test the change? >> >> There were no failing tests because the force inline hid it. I did testing with Nashorn and JRuby with -XX:-Inline. > > Good -XX:-Inline counts as a stress test. We should do it more often, since we know our code is sensitive to it. > > Let's add -XX:-Inline as an extra mode in one of our jtreg tests, such as MethodHandlesTest. This can be done by duplicating the @test block with the changed @run option. Good idea. We need to fix some other tests anyway to cut run time a bit. Then we can add this too. -- Chris > > ? John From vladimir.kozlov at oracle.com Mon Aug 20 12:52:38 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Mon, 20 Aug 2012 19:52:38 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops Message-ID: <20120820195242.98DC54764A@hg.openjdk.java.net> Changeset: 09aad8452938 Author: kvn Date: 2012-08-20 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/09aad8452938 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops Summary: In C2 add software membar after load from Reference.referent field to prevent commoning of loads across safepoint since GC can change its value. In C1 always generate Reference.get() intrinsic. Reviewed-by: roland, twisti, dholmes, johnc ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/7190310/Test7190310.java + test/compiler/7190310/Test7190310_unsafe.java From christian.thalinger at oracle.com Mon Aug 20 19:39:10 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 21 Aug 2012 02:39:10 +0000 Subject: hg: hsx/hotspot-comp/jdk: 7191102: nightly failures after JSR 292 lazy method handle update (round 3) Message-ID: <20120821023958.BC79147652@hg.openjdk.java.net> Changeset: a4f0043a5621 Author: jrose Date: 2012-08-17 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a4f0043a5621 7191102: nightly failures after JSR 292 lazy method handle update (round 3) Reviewed-by: twisti, kvn ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/WrongMethodTypeException.java ! src/share/classes/sun/invoke/util/ValueConversions.java + test/java/lang/invoke/BigArityTest.java - test/java/lang/invoke/MaxTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/RicochetTest.java ! test/sun/invoke/util/ValueConversionsTest.java From vladimir.kozlov at oracle.com Tue Aug 21 11:29:33 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Aug 2012 11:29:33 -0700 Subject: Request for reviews (XS): 7192964: assert(false) failed: bad AD file Message-ID: <5033D38D.5010408@oracle.com> http://cr.openjdk.java.net/~kvn/7192964/webrev 7192964: assert(false) failed: bad AD file Shifts with loop variant counts "a[i]=1< References: <5033D38D.5010408@oracle.com> Message-ID: <5033ED8E.3060509@oracle.com> Hi Vladimir, Looks good to me. Some minor comments below: superword.cpp, line 1058, It wasn't immediately obvious to me why in_bb(p0->in(2)) makes the shift's count a loop variant. Let's see if my understanding is correct: It relies on the fact that SuperWord::_bb is the entire loop body and there's no control flow in it, so that, if a value is produced outside this basic block, it must be loop invariant. I'm okay with the change as-is, but it'd be better is this kind of usage is factored out into a helper function with comments. P.S. (Not directly related to this change) Reading through the code, there are two occurrences of a typo in vectornode.cpp, line 183 and 185, "invarient" -> invariant. Could that be fixed as well? Regards, Kris On 08/22/2012 02:29 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7192964/webrev > > 7192964: assert(false) failed: bad AD file > > Shifts with loop variant counts "a[i]=1< vectorized since hw does not support it. > > Thanks, > Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120822/377973b3/attachment.html From christian.thalinger at oracle.com Tue Aug 21 13:49:49 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 21 Aug 2012 20:49:49 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7192167: JSR 292: C1 has old broken code which needs to be removed Message-ID: <20120821204955.2AB7B4766E@hg.openjdk.java.net> Changeset: 7a302948f5a4 Author: twisti Date: 2012-08-21 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7a302948f5a4 7192167: JSR 292: C1 has old broken code which needs to be removed Reviewed-by: kvn, roland, jrose ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/callGenerator.cpp From vladimir.kozlov at oracle.com Tue Aug 21 14:17:51 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Aug 2012 14:17:51 -0700 Subject: Request for reviews (XS): 7192964: assert(false) failed: bad AD file In-Reply-To: <5033ED8E.3060509@oracle.com> References: <5033D38D.5010408@oracle.com> <5033ED8E.3060509@oracle.com> Message-ID: <5033FAFF.8030103@oracle.com> Thank you, Kris I wish you become official Reviewer soon :) Krystal Mo wrote: > > Hi Vladimir, > > Looks good to me. Some minor comments below: > > superword.cpp, line 1058, > > It wasn't immediately obvious to me why > > in_bb(p0->in(2)) > > makes the shift's count a loop variant. > Let's see if my understanding is correct: It relies on the fact that > SuperWord::_bb is the entire loop body and there's no control flow in > it, so that, if a value is produced outside this basic block, it must be > loop invariant. That is correct. We vectorize only unrolled "main" counted loops which have only one exit at the end. So all data nodes between loop->head() and loop->tail() (CountedLoopNode and CountedLoopEndNode nodes) which have loop's head as associated control (PhaseIdealLoop::get_ctrl(n) == loop->head()) are considered inside loop and could be vectorized. in_bb() means "in basic block". > > I'm okay with the change as-is, but it'd be better is this kind of usage > is factored out into a helper function with comments. I will leave renaming and factoring for later. I have 3 others vectors bugs to fix today :) > > P.S. (Not directly related to this change) > Reading through the code, there are two occurrences of a typo in > vectornode.cpp, line 183 and 185, "invarient" -> invariant. Could that > be fixed as well? Done. Thanks, Vladimir > > Regards, > Kris > > On 08/22/2012 02:29 AM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/7192964/webrev >> >> 7192964: assert(false) failed: bad AD file >> >> Shifts with loop variant counts "a[i]=1<> vectorized since hw does not support it. >> >> Thanks, >> Vladimir > From christian.thalinger at oracle.com Tue Aug 21 14:43:29 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 21 Aug 2012 14:43:29 -0700 Subject: Request for reviews (XS): 7192964: assert(false) failed: bad AD file In-Reply-To: <5033D38D.5010408@oracle.com> References: <5033D38D.5010408@oracle.com> Message-ID: Looks good. -- Chris On Aug 21, 2012, at 11:29 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7192964/webrev > > 7192964: assert(false) failed: bad AD file > > Shifts with loop variant counts "a[i]=1< > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Aug 21 14:38:24 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Aug 2012 14:38:24 -0700 Subject: Request for reviews (XS): 7192964: assert(false) failed: bad AD file In-Reply-To: References: <5033D38D.5010408@oracle.com> Message-ID: <5033FFD0.6070708@oracle.com> Thank you, Christian Vladimir Christian Thalinger wrote: > Looks good. -- Chris > > On Aug 21, 2012, at 11:29 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7192964/webrev >> >> 7192964: assert(false) failed: bad AD file >> >> Shifts with loop variant counts "a[i]=1<> >> Thanks, >> Vladimir > From krystal.mo at oracle.com Tue Aug 21 14:54:51 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Wed, 22 Aug 2012 05:54:51 +0800 Subject: Request for reviews (XS): 7192964: assert(false) failed: bad AD file In-Reply-To: <5033FAFF.8030103@oracle.com> References: <5033D38D.5010408@oracle.com> <5033ED8E.3060509@oracle.com> <5033FAFF.8030103@oracle.com> Message-ID: <503403AB.8060009@oracle.com> On 08/22/2012 05:17 AM, Vladimir Kozlov wrote: > Thank you, Kris > > I wish you become official Reviewer soon :) > Thanks. Me too :-) I'll be working towards that. > Krystal Mo wrote: >> >> Hi Vladimir, >> >> Looks good to me. Some minor comments below: >> >> superword.cpp, line 1058, >> >> It wasn't immediately obvious to me why >> >> in_bb(p0->in(2)) >> >> makes the shift's count a loop variant. >> Let's see if my understanding is correct: It relies on the fact that >> SuperWord::_bb is the entire loop body and there's no control flow in >> it, so that, if a value is produced outside this basic block, it must >> be loop invariant. > > That is correct. We vectorize only unrolled "main" counted loops which > have only one exit at the end. So all data nodes between loop->head() > and loop->tail() (CountedLoopNode and CountedLoopEndNode nodes) which > have loop's head as associated control (PhaseIdealLoop::get_ctrl(n) == > loop->head()) are considered inside loop and could be vectorized. > in_bb() means "in basic block". > >> >> I'm okay with the change as-is, but it'd be better is this kind of >> usage is factored out into a helper function with comments. > > I will leave renaming and factoring for later. I have 3 others vectors > bugs to fix today :) > Yes, I'm fine with that. >> >> P.S. (Not directly related to this change) >> Reading through the code, there are two occurrences of a typo in >> vectornode.cpp, line 183 and 185, "invarient" -> invariant. Could >> that be fixed as well? > > Done. > Thanks, Kris > Thanks, > Vladimir > >> >> Regards, >> Kris >> >> On 08/22/2012 02:29 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7192964/webrev >>> >>> 7192964: assert(false) failed: bad AD file >>> >>> Shifts with loop variant counts "a[i]=1<>> vectorized since hw does not support it. >>> >>> Thanks, >>> Vladimir >> From vladimir.kozlov at oracle.com Tue Aug 21 17:17:37 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 22 Aug 2012 00:17:37 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7192964: assert(false) failed: bad AD file Message-ID: <20120822001742.6BF1147673@hg.openjdk.java.net> Changeset: 4b0d6fd74911 Author: kvn Date: 2012-08-21 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4b0d6fd74911 7192964: assert(false) failed: bad AD file Summary: Shifts with loop variant counts "a[i]=1< Hi hotspot team, While profiling a customer app, I saw "nmethod::is_zombie() const" surprisingly high in the profile. It turns out that is_zombie() is virtual in CodeBlob, so it is always a call. But there is only one "guarantee" in CodeCache that takes advantage of the virtualness that can be coded around. I have a simple microbenchmark, attached, mimicking the real app, attached, where "nmethod::is_zombie() const" is exercised due to frequent stack-walking. This webrev removes is_zombie as a virtual call so it can be inlined, and improves the performance of the microbenchmark by a few percent. http://cr.openjdk.java.net/~ecaspole/inline_zombie_check/webrev.00/ Regards, Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: StreamChicken.java Type: application/octet-stream Size: 3718 bytes Desc: StreamChicken.java Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120822/ec678855/StreamChicken-0001.java -------------- next part -------------- A non-text attachment was scrubbed... Name: Chicken.java Type: application/octet-stream Size: 103 bytes Desc: Chicken.java Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120822/ec678855/Chicken-0001.java From anantiitrke at gmail.com Tue Aug 21 09:29:55 2012 From: anantiitrke at gmail.com (Ashish Saxena) Date: Tue, 21 Aug 2012 21:59:55 +0530 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation Message-ID: Hi Team, In our Java 64 bit application, we are observing that JIT Compiler is allocating about 10 anonymous blocks of 64 MB each as soon as it begins compilation. Due to these extra native memory the Resident set size (RSS) of the linux process goes upto 2 GB. I have xmx setting of 1 GB and PermGen of 128 MB. So, i expect the JVM Process to use nearly 1GB + 128 MB + JVM ovehead = 1.2 GB However, the value is 2 GB. On looking at the pmap output, it shows that this high memory it shows many 64 MB Blocks. To identify the cause of these blocks, we tried different JVM JIT Compiler related options. On using -Xcomp to statically compile the application, RSS is 1.2 GB and only 1 anon block of 65 MB is seen in pmap output. Code Cache size is around 15 MB only. Why JIT is having so much overhead ? Is it the Data Cache ? I think it is usually a subset of CodeCache. Note: this behaviour is seen on all updates of JVM 1.6 and 1.7. Thanks, Ashish Anant Saxena From azeem.jiva at oracle.com Wed Aug 22 08:29:17 2012 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Wed, 22 Aug 2012 10:29:17 -0500 Subject: Possible to inline is_zombie check? In-Reply-To: <9582B7F1-8609-4A8C-95EC-234AF7DA6B34@amd.com> References: <9582B7F1-8609-4A8C-95EC-234AF7DA6B34@amd.com> Message-ID: <5034FACD.7040809@oracle.com> The change itself looks OK, although a little more detail in the performance gains would be useful. How many times did you run it? What's the STD DEV. Did you calculate a Student's TTest on it to see if the gains were consistent? What system did you run on? 64bit? 32bit? Azeem Jiva @javawithjiva On 08/22/2012 09:57 AM, Eric Caspole wrote: > Hi hotspot team, > While profiling a customer app, I saw "nmethod::is_zombie() const" > surprisingly high in the profile. It turns out that is_zombie() is > virtual in CodeBlob, so it is always a call. But there is only one > "guarantee" in CodeCache that takes advantage of the virtualness that > can be coded around. > > I have a simple microbenchmark, attached, mimicking the real app, > attached, where "nmethod::is_zombie() const" is exercised due to > frequent stack-walking. This webrev removes is_zombie as a virtual > call so it can be inlined, and improves the performance of the > microbenchmark by a few percent. > > http://cr.openjdk.java.net/~ecaspole/inline_zombie_check/webrev.00/ > > Regards, > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120822/2c5e7b1d/attachment.html From aph at redhat.com Wed Aug 22 08:33:53 2012 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Aug 2012 16:33:53 +0100 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation In-Reply-To: References: Message-ID: <5034FBE1.2090308@redhat.com> On 08/21/2012 05:29 PM, Ashish Saxena wrote: > In our Java 64 bit application, we are observing that JIT Compiler is > allocating about 10 anonymous blocks of 64 MB each as soon as it > begins compilation. Due to these extra native memory the Resident set > size (RSS) of the linux process goes upto 2 GB. I have xmx setting of > 1 GB and PermGen of 128 MB. So, i expect the JVM Process to use > nearly 1GB + 128 MB + JVM ovehead = 1.2 GB However, the value is 2 > GB. On looking at the pmap output, it shows that this high memory it > shows many 64 MB Blocks. > To identify the cause of these blocks, we tried different JVM JIT > Compiler related options. On using -Xcomp to statically compile the > application, RSS is 1.2 GB and only 1 anon block of 65 MB is seen in > pmap output. > Code Cache size is around 15 MB only. Why JIT is having so much > overhead ? Is it the Data Cache ? I think it is usually a subset of > CodeCache. > > Note: this behaviour is seen on all updates of JVM 1.6 and 1.7. If this is Linux, these are thread-local C heaps. They are 64M in size, and you'll get one for each thread. Andrew. From anantiitrke at gmail.com Wed Aug 22 09:26:01 2012 From: anantiitrke at gmail.com (Ashish Saxena) Date: Wed, 22 Aug 2012 21:56:01 +0530 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation In-Reply-To: <5034FBE1.2090308@redhat.com> References: <5034FBE1.2090308@redhat.com> Message-ID: I doubt if this is thread local memory area, for this disappears when moving to interpreted mode(-Xint) or static compilation mode (-Xcomp). Moreover, this occurs when JIT Compiler tries to do optimizations related to inlining. On disabling the inling optimizations using -XX:-Inline the 64 MB blocks disappears. Moreover, why would thread local area be so large ... 64 MB when thread stack size is usually 1 MB. Any thoughts ? Thanks, Ashish > On 08/21/2012 05:29 PM, Ashish Saxena wrote: > >> In our Java 64 bit application, we are observing that JIT Compiler is >> allocating about 10 anonymous blocks of 64 MB each as soon as it >> begins compilation. Due to these extra native memory the Resident set >> size (RSS) of the linux process goes upto 2 GB. I have xmx setting of >> 1 GB and PermGen of 128 MB. So, i expect the JVM Process to use >> nearly 1GB + 128 MB + JVM ovehead = 1.2 GB However, the value is 2 >> GB. On looking at the pmap output, it shows that this high memory it >> shows many 64 MB Blocks. >> To identify the cause of these blocks, we tried different JVM JIT >> Compiler related options. On using -Xcomp to statically compile the >> application, RSS is 1.2 GB and only 1 anon block of 65 MB is seen in >> pmap output. >> Code Cache size is around 15 MB only. Why JIT is having so much >> overhead ? Is it the Data Cache ? I think it is usually a subset of >> CodeCache. >> >> Note: this behaviour is seen on all updates of JVM 1.6 and 1.7. > > If this is Linux, these are thread-local C heaps. They are 64M in size, > and you'll get one for each thread. > > Andrew. > > From aph at redhat.com Wed Aug 22 09:33:16 2012 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Aug 2012 17:33:16 +0100 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation In-Reply-To: References: <5034FBE1.2090308@redhat.com> Message-ID: <503509CC.5060303@redhat.com> On 08/22/2012 05:26 PM, Ashish Saxena wrote: > I doubt if this is thread local memory area, for this disappears when > moving to interpreted mode(-Xint) or static compilation mode (-Xcomp). > Moreover, this occurs when JIT Compiler tries to do optimizations > related to inlining. On disabling the inling optimizations using > -XX:-Inline the 64 MB blocks disappears. Point taken. I would expect to see those 64M blocks on 64-bit systems, and I would expect to see about ten of them, but it's unconnected with JIT compilation. > Moreover, why would thread local area be so large ... 64 MB when > thread stack size is usually 1 MB. Any thoughts ? That's because address space is almost free on 64-bit systems: the C heap might as well allocate a block of address space to make malloc() extra fast. Andrew. From vitalyd at gmail.com Wed Aug 22 09:36:19 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 22 Aug 2012 12:36:19 -0400 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation In-Reply-To: <503509CC.5060303@redhat.com> References: <5034FBE1.2090308@redhat.com> <503509CC.5060303@redhat.com> Message-ID: Reserving a 64mb private heap sounds fine on 64bit, but it sounds like that memory is being committed since RSS goes up? Sent from my phone On Aug 22, 2012 12:34 PM, "Andrew Haley" wrote: > On 08/22/2012 05:26 PM, Ashish Saxena wrote: > > I doubt if this is thread local memory area, for this disappears when > > moving to interpreted mode(-Xint) or static compilation mode (-Xcomp). > > Moreover, this occurs when JIT Compiler tries to do optimizations > > related to inlining. On disabling the inling optimizations using > > -XX:-Inline the 64 MB blocks disappears. > > Point taken. I would expect to see those 64M blocks on 64-bit systems, > and I would expect to see about ten of them, but it's unconnected with > JIT compilation. > > > Moreover, why would thread local area be so large ... 64 MB when > > thread stack size is usually 1 MB. Any thoughts ? > > That's because address space is almost free on 64-bit systems: the C > heap might as well allocate a block of address space to make malloc() > extra fast. > > Andrew. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120822/232a7fd8/attachment.html From roland.westrelin at oracle.com Wed Aug 22 10:32:56 2012 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Wed, 22 Aug 2012 17:32:56 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7171824: assert(_offset >= 1) failed: illegal call to offset() Message-ID: <20120822173302.A4F234768B@hg.openjdk.java.net> Changeset: 0bfcb7a3e12d Author: roland Date: 2012-08-22 14:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0bfcb7a3e12d 7171824: assert(_offset >= 1) failed: illegal call to offset() Summary: C1 value numbering hits unloaded klass. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp From vladimir.kozlov at oracle.com Wed Aug 22 10:32:22 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Aug 2012 10:32:22 -0700 Subject: Request for reviews (M): 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' Message-ID: <503517A6.1010109@oracle.com> http://cr.openjdk.java.net/~kvn/7192963/webrev 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' An other variant of shifts with loop variant counts: "a[i]=1< References: <5034FBE1.2090308@redhat.com> <503509CC.5060303@redhat.com> Message-ID: <503518E6.1090404@redhat.com> On 08/22/2012 05:36 PM, Vitaly Davidovich wrote: > Reserving a 64mb private heap sounds fine on 64bit, but it sounds like that > memory is being committed since RSS goes up? Maybe, maybe not. We don't know that those 64M blocks are committed. All I'm saying is that I have a suspicion that I know what they are. Andrew. From christian.thalinger at oracle.com Wed Aug 22 11:21:09 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 22 Aug 2012 11:21:09 -0700 Subject: Request for reviews (M): 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' In-Reply-To: <503517A6.1010109@oracle.com> References: <503517A6.1010109@oracle.com> Message-ID: <46AF74EC-1C79-4EE2-99F4-33E3BEFA4DA0@oracle.com> The changes look good. I just have two small requests: src/share/vm/opto/superword.cpp: + Node* pi = p->at(i); + Node* def = pi->in(idx); + if (p0_def != def) Could you rename def to pi_def? src/share/vm/opto/vectornode.cpp: While we are already touching almost all occurences of PackNode::binaryTreePack could we rename it to PackNode::binary_tree_pack? -- Chris On Aug 22, 2012, at 10:32 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7192963/webrev > > 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' > > An other variant of shifts with loop variant counts: "a[i]=1< > The fix is to not vectorize shift instructions if count is not the same for all shifts and if count is vector. Note, I removed the changes for previous 7192964 fix since it was not precise and current fix cover 7192964 case (I verified). > Also fixed Pack node generation, number of inputs should be 2 at the creation otherwise it gives the bug's assert. > > I did some refactoring. Moved and renamed SuperWord::vector_opd_range() to VectorNode::vector_operands(). Opcode checks of supported nodes are done in vectornode.cpp. Also this method was incorrect - it had only one LShiftI opcode listed. And I added other supported nodes. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Aug 22 11:20:28 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Aug 2012 11:20:28 -0700 Subject: Request for reviews (M): 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' In-Reply-To: <46AF74EC-1C79-4EE2-99F4-33E3BEFA4DA0@oracle.com> References: <503517A6.1010109@oracle.com> <46AF74EC-1C79-4EE2-99F4-33E3BEFA4DA0@oracle.com> Message-ID: <503522EC.10806@oracle.com> thank you, Christian Christian Thalinger wrote: > The changes look good. I just have two small requests: > > src/share/vm/opto/superword.cpp: > > + Node* pi = p->at(i); > + Node* def = pi->in(idx); > + if (p0_def != def) > > Could you rename def to pi_def? Done. > > src/share/vm/opto/vectornode.cpp: > > While we are already touching almost all occurences of PackNode::binaryTreePack could we rename it to PackNode::binary_tree_pack? Agree and done. Thanks, Vladimir > > -- Chris > > On Aug 22, 2012, at 10:32 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7192963/webrev >> >> 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' >> >> An other variant of shifts with loop variant counts: "a[i]=1<> >> The fix is to not vectorize shift instructions if count is not the same for all shifts and if count is vector. Note, I removed the changes for previous 7192964 fix since it was not precise and current fix cover 7192964 case (I verified). >> Also fixed Pack node generation, number of inputs should be 2 at the creation otherwise it gives the bug's assert. >> >> I did some refactoring. Moved and renamed SuperWord::vector_opd_range() to VectorNode::vector_operands(). Opcode checks of supported nodes are done in vectornode.cpp. Also this method was incorrect - it had only one LShiftI opcode listed. And I added other supported nodes. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Wed Aug 22 14:33:30 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 22 Aug 2012 21:33:30 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' Message-ID: <20120822213334.BE2024768F@hg.openjdk.java.net> Changeset: 5af51c882207 Author: kvn Date: 2012-08-22 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5af51c882207 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' Summary: Fixed Pack node generation. Not vectorize shift instructions if count is not the same for all shifts and if count is vector. Reviewed-by: twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/7192963/TestByteVect.java + test/compiler/7192963/TestDoubleVect.java + test/compiler/7192963/TestFloatVect.java + test/compiler/7192963/TestIntVect.java + test/compiler/7192963/TestLongVect.java + test/compiler/7192963/TestShortVect.java From vladimir.kozlov at oracle.com Wed Aug 22 15:20:58 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Aug 2012 15:20:58 -0700 Subject: Request for reviews (S): 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets Message-ID: <50355B4A.2050209@oracle.com> http://cr.openjdk.java.net/~kvn/7192965/webrev 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets Bias coloring in RA does not work for vectors with size > 64 bits, it only works for pairs (64 bits). Change pair check to vector check. I did small refactoring and added comment. Tested with failing test. Thanks, Vladimir From john.r.rose at oracle.com Wed Aug 22 15:46:13 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 22 Aug 2012 15:46:13 -0700 Subject: Request for reviews (S): 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets In-Reply-To: <50355B4A.2050209@oracle.com> References: <50355B4A.2050209@oracle.com> Message-ID: On Aug 22, 2012, at 3:20 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7192965/webrev > > 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets > > Bias coloring in RA does not work for vectors with size > 64 bits, it only works for pairs (64 bits). > Change pair check to vector check. I did small refactoring and added comment. > > Tested with failing test. > > Thanks, > Vladimir It is a good cleanup as well as a bug fix. Suggestion: Make the new function static, to encourage inlining and keep the global name space tidier. I suppose this logic applies to stack slot coloring. If so, will there be similar problems with overlapping allocations of spill slots? For example, stack[20..21] might be allocated for a double spill, while stack[20..23] is allocated for a quad spill. I hope we detect interference between those allocations by setting all four bits 20..23 when building interference bit-masks. ? John From christian.thalinger at oracle.com Wed Aug 22 15:53:20 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 22 Aug 2012 15:53:20 -0700 Subject: Request for reviews (S): 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets In-Reply-To: <50355B4A.2050209@oracle.com> References: <50355B4A.2050209@oracle.com> Message-ID: On Aug 22, 2012, at 3:20 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7192965/webrev > > 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets > > Bias coloring in RA does not work for vectors with size > 64 bits, it only works for pairs (64 bits). > Change pair check to vector check. I did small refactoring and added comment. > > Tested with failing test. src/share/vm/opto/chaitin.cpp: + bool is_legal_reg(LRG &lrg, OptoReg::Name reg, int chunk) { Should it be a static method? -- Chris > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Aug 22 15:52:25 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Aug 2012 15:52:25 -0700 Subject: Request for reviews (S): 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets In-Reply-To: References: <50355B4A.2050209@oracle.com> Message-ID: <503562A9.7030703@oracle.com> Thank you, Christian Yes, I forgot to add "static". Fixed. Thanks, Vladimir Christian Thalinger wrote: > On Aug 22, 2012, at 3:20 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7192965/webrev >> >> 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets >> >> Bias coloring in RA does not work for vectors with size > 64 bits, it only works for pairs (64 bits). >> Change pair check to vector check. I did small refactoring and added comment. >> >> Tested with failing test. > > src/share/vm/opto/chaitin.cpp: > > + bool is_legal_reg(LRG &lrg, OptoReg::Name reg, int chunk) { > > Should it be a static method? > > -- Chris > >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Wed Aug 22 15:56:44 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Aug 2012 15:56:44 -0700 Subject: Request for reviews (S): 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets In-Reply-To: References: <50355B4A.2050209@oracle.com> Message-ID: <503563AC.8000801@oracle.com> Thank you, John John Rose wrote: > On Aug 22, 2012, at 3:20 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7192965/webrev >> > > Suggestion: Make the new function static, to encourage inlining and keep the global name space tidier. Yes, I forgot to add "static" keyword. Fixed. > I suppose this logic applies to stack slot coloring. If so, will there be similar problems with overlapping allocations of spill slots? For example, stack[20..21] might be allocated for a double spill, while stack[20..23] is allocated for a quad spill. I hope we detect interference between those allocations by setting all four bits 20..23 when building interference bit-masks. We do mark all bits for vectors and do clear to sets. But I will check it anyway. Thanks, Vladimir > > ? John From vladimir.kozlov at oracle.com Wed Aug 22 20:29:02 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Aug 2012 20:29:02 -0700 Subject: Request for reviews (S): 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets In-Reply-To: <503563AC.8000801@oracle.com> References: <50355B4A.2050209@oracle.com> <503563AC.8000801@oracle.com> Message-ID: <5035A37E.5020500@oracle.com> http://cr.openjdk.java.net/~kvn/7192965/webrev.01 I looked and the same code for coloring is used for stack. Offset by chunks are used to map to stack instead of real registers: CHUNK_SIZE = RM_SIZE*_WordBits. We have a little dangerous place when the RA result is stored into _node_regs[] array used by following code generation. And it is array of registers pairs. It is fine for asm generation since only first register is used for encoding. But for ScheduleAndBundle code use both registers from pairs to detect dependences in blocks. And it is also fine since scheduling is done only on SPARC which have only 64bit vectors (pairs) but I added an assert anyway. And I did additional small cleanup to replace _node_regs[i].set_pair(hi, lo) with set_pair(i, hi, lo) to avoid direct reference of _node_regs[]. Thanks, Vladimir Vladimir Kozlov wrote: > Thank you, John > > John Rose wrote: >> On Aug 22, 2012, at 3:20 PM, Vladimir Kozlov wrote: >> >>> http://cr.openjdk.java.net/~kvn/7192965/webrev >>> >> >> Suggestion: Make the new function static, to encourage inlining and >> keep the global name space tidier. > > Yes, I forgot to add "static" keyword. Fixed. > >> I suppose this logic applies to stack slot coloring. If so, will >> there be similar problems with overlapping allocations of spill >> slots? For example, stack[20..21] might be allocated for a double >> spill, while stack[20..23] is allocated for a quad spill. I hope we >> detect interference between those allocations by setting all four bits >> 20..23 when building interference bit-masks. > > We do mark all bits for vectors and do clear to sets. But I will check > it anyway. > > Thanks, > Vladimir > >> >> ? John From john.r.rose at oracle.com Wed Aug 22 23:05:54 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 22 Aug 2012 23:05:54 -0700 Subject: Request for reviews (S): 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets In-Reply-To: <5035A37E.5020500@oracle.com> References: <50355B4A.2050209@oracle.com> <503563AC.8000801@oracle.com> <5035A37E.5020500@oracle.com> Message-ID: <1AA8975E-603C-46C0-9972-CE194641C1E1@oracle.com> Yes; that's better. ? John On Aug 22, 2012, at 8:29 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7192965/webrev.01 > > I looked and the same code for coloring is used for stack. Offset by chunks are used to map to stack instead of real registers: CHUNK_SIZE = RM_SIZE*_WordBits. > > We have a little dangerous place when the RA result is stored into _node_regs[] array used by following code generation. And it is array of registers pairs. It is fine for asm generation since only first register is used for encoding. But for ScheduleAndBundle code use both registers from pairs to detect dependences in blocks. And it is also fine since scheduling is done only on SPARC which have only 64bit vectors (pairs) but I added an assert anyway. > > And I did additional small cleanup to replace _node_regs[i].set_pair(hi, lo) with set_pair(i, hi, lo) to avoid direct reference of _node_regs[]. > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> Thank you, John >> John Rose wrote: >>> On Aug 22, 2012, at 3:20 PM, Vladimir Kozlov wrote: >>> >>>> http://cr.openjdk.java.net/~kvn/7192965/webrev >>>> >>> >>> Suggestion: Make the new function static, to encourage inlining and keep the global name space tidier. >> Yes, I forgot to add "static" keyword. Fixed. >>> I suppose this logic applies to stack slot coloring. If so, will there be similar problems with overlapping allocations of spill slots? For example, stack[20..21] might be allocated for a double spill, while stack[20..23] is allocated for a quad spill. I hope we detect interference between those allocations by setting all four bits 20..23 when building interference bit-masks. >> We do mark all bits for vectors and do clear to sets. But I will check it anyway. >> Thanks, >> Vladimir >>> >>> ? John From xerox.time.tech at gmail.com Thu Aug 23 09:21:04 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 23 Aug 2012 09:21:04 -0700 Subject: profile interpreter and JIT Message-ID: I want to measure the amount of time spend in the interpreter and the JIT in hotspot. since the interpreter is dynamically generated when the VM starts. how can one get that statistics. maybe oprofile can do that, but does not the interpreter need to register the generated interpreter routine with the profiler ? is this code in hotspot ? Xin From krystal.mo at oracle.com Thu Aug 23 10:29:04 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Fri, 24 Aug 2012 01:29:04 +0800 Subject: profile interpreter and JIT In-Reply-To: References: Message-ID: <50366860.1040900@oracle.com> Hi Xin, There's a JVMTI event that does the trick: DynamicCodeGenerated http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#DynamicCodeGenerated Use it to do whatever registration needed. - Kris On 2012/8/24 0:21, Xin Tong wrote: > I want to measure the amount of time spend in the interpreter and the > JIT in hotspot. since the interpreter is dynamically generated when > the VM starts. how can one get that statistics. maybe oprofile can do > that, but does not the interpreter need to register the generated > interpreter routine with the profiler ? is this code in hotspot ? > > Xin From aph at redhat.com Thu Aug 23 11:01:00 2012 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Aug 2012 19:01:00 +0100 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation In-Reply-To: References: <5034FBE1.2090308@redhat.com> <503509CC.5060303@redhat.com> <503518E6.1090404@redhat.com> Message-ID: <50366FDC.3000102@redhat.com> On 08/23/2012 06:32 PM, Ashish Saxena wrote: > These 64 MB blocks are committed and marked dirty and actually using > the RAM.. Hence the conern. Interesting. Out of interest, how exactly do you know that? > As Andrew pointed, may be it is due to > some c-heap allocation specific to 64 bit systems.... but under what > circumstances do these blocks get allocated ? Which JVM Component / > Subcomponent is responsible for these extra memory blocks ? > > Based on test and JVM options I mentioned above, it seems that these > gets allocated whenever JVM gets into JIT mode for the first time (may > be, may be not) ... but which JVM sub component is responsible for > this memory overhead ? At this point, I'd just use GDB to break when the blocks are allocated. Assuming this is Linux... Andrew. From vladimir.kozlov at oracle.com Thu Aug 23 11:14:28 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Aug 2012 18:14:28 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets Message-ID: <20120823181432.C32C2476B3@hg.openjdk.java.net> Changeset: f7cd53cedd78 Author: kvn Date: 2012-08-23 09:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f7cd53cedd78 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets Summary: Change pair check to vector check in RA bias coloring code. Reviewed-by: jrose, twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/output.cpp From anantiitrke at gmail.com Thu Aug 23 10:32:30 2012 From: anantiitrke at gmail.com (Ashish Saxena) Date: Thu, 23 Aug 2012 23:02:30 +0530 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation In-Reply-To: <503518E6.1090404@redhat.com> References: <5034FBE1.2090308@redhat.com> <503509CC.5060303@redhat.com> <503518E6.1090404@redhat.com> Message-ID: These 64 MB blocks are committed and marked dirty and actually using the RAM.. Hence the conern. As Andrew pointed, may be it is due to some c-heap allocation specific to 64 bit systems.... but under what circumstances do these blocks get allocated ? Which JVM Component / Subcomponent is responsible for these extra memory blocks ? Based on test and JVM options I mentioned above, it seems that these gets allocated whenever JVM gets into JIT mode for the first time (may be, may be not) ... but which JVM sub component is responsible for this memory overhead ? Thanks, Ashish On Wed, Aug 22, 2012 at 11:07 PM, Andrew Haley wrote: > On 08/22/2012 05:36 PM, Vitaly Davidovich wrote: >> Reserving a 64mb private heap sounds fine on 64bit, but it sounds like that >> memory is being committed since RSS goes up? > > Maybe, maybe not. We don't know that those 64M blocks are committed. All I'm > saying is that I have a suspicion that I know what they are. > > Andrew. > From xerox.time.tech at gmail.com Thu Aug 23 11:55:27 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 23 Aug 2012 11:55:27 -0700 Subject: profile interpreter and JIT In-Reply-To: <50366860.1040900@oracle.com> References: <50366860.1040900@oracle.com> Message-ID: this code is not used to register the interpreter routines right now. is it ? Xin On Thu, Aug 23, 2012 at 10:29 AM, Krystal Mo wrote: > Hi Xin, > > There's a JVMTI event that does the trick: DynamicCodeGenerated > http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#DynamicCodeGenerated > Use it to do whatever registration needed. > > - Kris > > > On 2012/8/24 0:21, Xin Tong wrote: >> >> I want to measure the amount of time spend in the interpreter and the >> JIT in hotspot. since the interpreter is dynamically generated when >> the VM starts. how can one get that statistics. maybe oprofile can do >> that, but does not the interpreter need to register the generated >> interpreter routine with the profiler ? is this code in hotspot ? >> >> Xin From vladimir.kozlov at oracle.com Thu Aug 23 12:06:41 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Aug 2012 12:06:41 -0700 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation In-Reply-To: References: <5034FBE1.2090308@redhat.com> <503509CC.5060303@redhat.com> <503518E6.1090404@redhat.com> Message-ID: <50367F41.2090307@oracle.com> Ashish, It could be related to 7148109. Register Allocator may consume a lot of memory for particular shape of code. You can also check if this memory reservation happens during JIT compilation. Run with "-Xbatch -XX:CICompilerCount=1 -XX:+PrintCompilation". Only one compiler thread will run and it will print which method is compiled. This way you can find which method compilation triggers it if it is really JIT. Regards, Vladimir Ashish Saxena wrote: > These 64 MB blocks are committed and marked dirty and actually using > the RAM.. Hence the conern. As Andrew pointed, may be it is due to > some c-heap allocation specific to 64 bit systems.... but under what > circumstances do these blocks get allocated ? Which JVM Component / > Subcomponent is responsible for these extra memory blocks ? > > Based on test and JVM options I mentioned above, it seems that these > gets allocated whenever JVM gets into JIT mode for the first time (may > be, may be not) ... but which JVM sub component is responsible for > this memory overhead ? > > Thanks, > Ashish > > On Wed, Aug 22, 2012 at 11:07 PM, Andrew Haley wrote: >> On 08/22/2012 05:36 PM, Vitaly Davidovich wrote: >>> Reserving a 64mb private heap sounds fine on 64bit, but it sounds like that >>> memory is being committed since RSS goes up? >> Maybe, maybe not. We don't know that those 64M blocks are committed. All I'm >> saying is that I have a suspicion that I know what they are. >> >> Andrew. >> From christian.thalinger at oracle.com Thu Aug 23 12:38:34 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 23 Aug 2012 12:38:34 -0700 Subject: profile interpreter and JIT In-Reply-To: References: <50366860.1040900@oracle.com> Message-ID: On Aug 23, 2012, at 11:55 AM, Xin Tong wrote: > this code is not used to register the interpreter routines right now. is it ? I don't quite understand. What exactly do you want to measure? Do you mean time that is spent in the various bytecode templates in the interpreter? -- Chris > > Xin > > > On Thu, Aug 23, 2012 at 10:29 AM, Krystal Mo wrote: >> Hi Xin, >> >> There's a JVMTI event that does the trick: DynamicCodeGenerated >> http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#DynamicCodeGenerated >> Use it to do whatever registration needed. >> >> - Kris >> >> >> On 2012/8/24 0:21, Xin Tong wrote: >>> >>> I want to measure the amount of time spend in the interpreter and the >>> JIT in hotspot. since the interpreter is dynamically generated when >>> the VM starts. how can one get that statistics. maybe oprofile can do >>> that, but does not the interpreter need to register the generated >>> interpreter routine with the profiler ? is this code in hotspot ? >>> >>> Xin From rednaxelafx at gmail.com Thu Aug 23 13:20:18 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 24 Aug 2012 04:20:18 +0800 Subject: profile interpreter and JIT In-Reply-To: References: <50366860.1040900@oracle.com> Message-ID: The DynamicCodeGenerated event is for ALL dynamically generated code that are not compiled Java methods. Its counterpart for compiled Java methods is the CompiledMethodLoad event. Both event are implemented and functioning in HotSpot VM. Oprofile uses both of these events for "JIT" support (where the term "JIT" actually stands for all dynamically generated code). And, just as Christian asked, what exactly is it that you're trying to measure? Just in case: HotSpot VM's implementation of the DynamicCodeGenerated event takes all of the dynamically generated interpreter code as a whole, under the name "Interpreter"; it doesn't provide enough detail for you to differentiate between the bytecode handlers. - Kris On Fri, Aug 24, 2012 at 2:55 AM, Xin Tong wrote: > this code is not used to register the interpreter routines right now. is > it ? > > Xin > > > On Thu, Aug 23, 2012 at 10:29 AM, Krystal Mo > wrote: > > Hi Xin, > > > > There's a JVMTI event that does the trick: DynamicCodeGenerated > > > http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#DynamicCodeGenerated > > Use it to do whatever registration needed. > > > > - Kris > > > > > > On 2012/8/24 0:21, Xin Tong wrote: > >> > >> I want to measure the amount of time spend in the interpreter and the > >> JIT in hotspot. since the interpreter is dynamically generated when > >> the VM starts. how can one get that statistics. maybe oprofile can do > >> that, but does not the interpreter need to register the generated > >> interpreter routine with the profiler ? is this code in hotspot ? > >> > >> Xin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120824/a23f5e2d/attachment.html From xerox.time.tech at gmail.com Thu Aug 23 15:55:12 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 23 Aug 2012 15:55:12 -0700 Subject: profile interpreter and JIT In-Reply-To: References: <50366860.1040900@oracle.com> Message-ID: On Thu, Aug 23, 2012 at 1:20 PM, Krystal Mok wrote: > The DynamicCodeGenerated event is for ALL dynamically generated code that > are not compiled Java methods. > Its counterpart for compiled Java methods is the CompiledMethodLoad event. > Both event are implemented and functioning in HotSpot VM. Oprofile uses both > of these events for "JIT" support (where the term "JIT" actually stands for > all dynamically generated code). > > And, just as Christian asked, what exactly is it that you're trying to > measure? > > Just in case: HotSpot VM's implementation of the DynamicCodeGenerated event > takes all of the dynamically generated interpreter code as a whole, under > the name "Interpreter"; it doesn't provide enough detail for you to > differentiate between the bytecode handlers. This is what i wanted. Thanks Xin > > - Kris > > > On Fri, Aug 24, 2012 at 2:55 AM, Xin Tong wrote: >> >> this code is not used to register the interpreter routines right now. is >> it ? >> >> Xin >> >> >> On Thu, Aug 23, 2012 at 10:29 AM, Krystal Mo >> wrote: >> > Hi Xin, >> > >> > There's a JVMTI event that does the trick: DynamicCodeGenerated >> > >> > http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#DynamicCodeGenerated >> > Use it to do whatever registration needed. >> > >> > - Kris >> > >> > >> > On 2012/8/24 0:21, Xin Tong wrote: >> >> >> >> I want to measure the amount of time spend in the interpreter and the >> >> JIT in hotspot. since the interpreter is dynamically generated when >> >> the VM starts. how can one get that statistics. maybe oprofile can do >> >> that, but does not the interpreter need to register the generated >> >> interpreter routine with the profiler ? is this code in hotspot ? >> >> >> >> Xin > > From vladimir.kozlov at oracle.com Fri Aug 24 14:30:24 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Aug 2012 14:30:24 -0700 Subject: Request for reviews (S): 7148109: C2 compiler consumes too much heap resources Message-ID: <5037F270.6020702@oracle.com> http://cr.openjdk.java.net/~kvn/7148109/webrev 7148109: C2 compiler consumes too much heap resources RA may use a lot of native memory when C2 compiles big method with a lot of branches and simultaneous live date. For each (spill, split) cycle RA allocates arrays in Split() method with size "sizeof(p*)*num_blocks*spill_cnt" and does not free resource on method exit. With _num_blocks == 1000 and spill_cnt == 500 RA will use more then 5Mb of additional native memory for each cycle. RA will do up to 24 cycles before bailout so it can consume more then 100Mb by one C2 compiler thread. Add split_arena to allocate these arrays and free them on method's exit. Thanks, Vladimir From christian.thalinger at oracle.com Fri Aug 24 14:58:22 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 24 Aug 2012 14:58:22 -0700 Subject: Request for reviews (S): 7148109: C2 compiler consumes too much heap resources In-Reply-To: <5037F270.6020702@oracle.com> References: <5037F270.6020702@oracle.com> Message-ID: Looks good. -- Chris On Aug 24, 2012, at 2:30 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7148109/webrev > > 7148109: C2 compiler consumes too much heap resources > > RA may use a lot of native memory when C2 compiles big method with a lot of branches and simultaneous live date. For each (spill, split) cycle RA allocates arrays in Split() method with size "sizeof(p*)*num_blocks*spill_cnt" and does not free resource on method exit. With _num_blocks == 1000 and spill_cnt == 500 > RA will use more then 5Mb of additional native memory for each cycle. RA will do up to 24 cycles before bailout so it can consume more then 100Mb by one C2 compiler thread. > > Add split_arena to allocate these arrays and free them on method's exit. > > Thanks, > Vladimir From christian.thalinger at oracle.com Fri Aug 24 16:07:57 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 24 Aug 2012 16:07:57 -0700 Subject: Request for reviews (L): 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites Message-ID: <70714701-5A10-4F15-A7C9-1791C51B6843@oracle.com> http://cr.openjdk.java.net/~twisti/7192406 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites Reviewed-by: When invokedynamic and invokehandle call sites are linked the target is a method handle adapter (static method) with a type erased signature. This also means the return type of the method is now java.lang.Object while in reality it's a more concrete type. In certain situations with inlining this can cause type mismatches. This also fixes a problem in constant pool cache where taking a lock might result in problems on Solaris. Additionally I changed GraphKit::compute_stack_effects to check if it was called from LibraryCallKit instead of passing in a flag which is very error prone. src/share/vm/c1/c1_GraphBuilder.cpp src/share/vm/c1/c1_GraphBuilder.hpp src/share/vm/ci/bcEscapeAnalyzer.cpp src/share/vm/ci/ciEnv.cpp src/share/vm/ci/ciEnv.hpp src/share/vm/ci/ciMethod.cpp src/share/vm/ci/ciStreams.cpp src/share/vm/ci/ciStreams.hpp src/share/vm/ci/ciTypeFlow.cpp src/share/vm/interpreter/bytecodes.hpp src/share/vm/oops/cpCacheOop.cpp src/share/vm/opto/doCall.cpp src/share/vm/opto/graphKit.cpp src/share/vm/opto/graphKit.hpp src/share/vm/opto/library_call.cpp src/share/vm/opto/parse1.cpp From vladimir.kozlov at oracle.com Fri Aug 24 16:41:00 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Aug 2012 16:41:00 -0700 Subject: Request for reviews (S): 7148109: C2 compiler consumes too much heap resources In-Reply-To: References: <5037F270.6020702@oracle.com> Message-ID: <5038110C.9000103@oracle.com> Thanks, Christian Vladimir On 8/24/12 2:58 PM, Christian Thalinger wrote: > Looks good. -- Chris > > On Aug 24, 2012, at 2:30 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7148109/webrev >> >> 7148109: C2 compiler consumes too much heap resources >> >> RA may use a lot of native memory when C2 compiles big method with a lot of branches and simultaneous live date. For each (spill, split) cycle RA allocates arrays in Split() method with size "sizeof(p*)*num_blocks*spill_cnt" and does not free resource on method exit. With _num_blocks == 1000 and spill_cnt == 500 >> RA will use more then 5Mb of additional native memory for each cycle. RA will do up to 24 cycles before bailout so it can consume more then 100Mb by one C2 compiler thread. >> >> Add split_arena to allocate these arrays and free them on method's exit. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Fri Aug 24 17:22:49 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Aug 2012 17:22:49 -0700 Subject: Request for reviews (L): 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites In-Reply-To: <70714701-5A10-4F15-A7C9-1791C51B6843@oracle.com> References: <70714701-5A10-4F15-A7C9-1791C51B6843@oracle.com> Message-ID: <50381AD9.2010907@oracle.com> On 8/24/12 4:07 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7192406 > > 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites > Reviewed-by: > > When invokedynamic and invokehandle call sites are linked the target is a > method handle adapter (static method) with a type erased signature. This > also means the return type of the method is now java.lang.Object while in > reality it's a more concrete type. > > In certain situations with inlining this can cause type mismatches. > > This also fixes a problem in constant pool cache where taking a lock might > result in problems on Solaris. > > Additionally I changed GraphKit::compute_stack_effects to check if it was > called from LibraryCallKit instead of passing in a flag which is very > error prone. What if in a future we may need to call it from LibraryCallKit *before* invoke? The rest changes look fine. thanks, Vladimir > > src/share/vm/c1/c1_GraphBuilder.cpp > src/share/vm/c1/c1_GraphBuilder.hpp > src/share/vm/ci/bcEscapeAnalyzer.cpp > src/share/vm/ci/ciEnv.cpp > src/share/vm/ci/ciEnv.hpp > src/share/vm/ci/ciMethod.cpp > src/share/vm/ci/ciStreams.cpp > src/share/vm/ci/ciStreams.hpp > src/share/vm/ci/ciTypeFlow.cpp > src/share/vm/interpreter/bytecodes.hpp > src/share/vm/oops/cpCacheOop.cpp > src/share/vm/opto/doCall.cpp > src/share/vm/opto/graphKit.cpp > src/share/vm/opto/graphKit.hpp > src/share/vm/opto/library_call.cpp > src/share/vm/opto/parse1.cpp > From alejandro.murillo at oracle.com Fri Aug 24 22:49:08 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 25 Aug 2012 05:49:08 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 25 new changesets Message-ID: <20120825055001.EFBE747701@hg.openjdk.java.net> Changeset: 54240c1b8e87 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/54240c1b8e87 Added tag jdk8-b52 for changeset 6d0436885201 ! .hgtags Changeset: de2aa86e037d Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/de2aa86e037d Added tag jdk8-b53 for changeset 54240c1b8e87 ! .hgtags Changeset: aaf61e68b255 Author: johnc Date: 2012-08-06 12:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aaf61e68b255 6818524: G1: use ergonomic resizing of PLABs Summary: Employ PLABStats instances to record information about survivor and old PLABs, and use the recorded stats to adjust the sizes of survivor and old PLABS. Reviewed-by: johnc, ysr Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/precompiled/precompiled.hpp Changeset: eff5d59db7e1 Author: amurillo Date: 2012-08-07 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/eff5d59db7e1 7189729: jprt.properties should include release jdk7u8 Reviewed-by: jcoomes ! make/jprt.properties Changeset: 3958f0acde31 Author: amurillo Date: 2012-08-17 15:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3958f0acde31 Merge ! make/jprt.properties - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: 6acee021f5ac Author: coleenp Date: 2012-08-01 16:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6acee021f5ac 7129723: MAC: Some regression tests need to recognize Mac OS X platform Summary: Add Darwin like Linux to shell scripts Reviewed-by: kvn, kamg, dholmes ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 4acebbe310e1 Author: zgu Date: 2012-08-01 17:19 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4acebbe310e1 7185614: NMT ON: "check by caller" assertion failed on nsk ThreadMXBean test 7187429: NMT ON: Merge failure should cause NMT to shutdown Summary: Fixed NMT assertion failures Reviewed-by: acorn, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTracker.hpp Changeset: b27675afea11 Author: zgu Date: 2012-08-01 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b27675afea11 Merge Changeset: 8e69438de9c6 Author: zgu Date: 2012-08-01 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8e69438de9c6 Merge Changeset: 282abd0fd878 Author: dcubed Date: 2012-08-02 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/282abd0fd878 7188168: 7071904 broke the DEBUG_BINARIES option on Linux Summary: Change DEBUG_BINARIES option logic to be more clear. Reviewed-by: fparain, andrew ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make Changeset: 0d8e265ba727 Author: dcubed Date: 2012-08-03 18:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0d8e265ba727 7181175: Enable builds on Windows with MinGW/MSYS Summary: This fix is the minimum number of Makefile changes to enable building HotSpot with MinGW/MSYS Reviewed-by: jcoomes, dcubed, tbell, ohair Contributed-by: volker.simonis at gmail.com ! make/windows/makefiles/defs.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/shared.make Changeset: c3c2141203e7 Author: dcubed Date: 2012-08-06 09:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c3c2141203e7 Merge Changeset: 4ee06e614636 Author: kamg Date: 2012-08-06 15:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4ee06e614636 7116786: RFE: Detailed information on VerifyErrors Summary: Provide additional detail in VerifyError messages Reviewed-by: sspitsyn, acorn ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/runtime/7116786/Test7116786.java + test/runtime/7116786/testcases.jar Changeset: 98625323d3a3 Author: tbell Date: 2012-08-10 23:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/98625323d3a3 7190512: Fix for 7181175 broke hotspot/make/windows/create.bat builds Summary: Add some quotes around the classpath in the project file rule. Reviewed-by: dcubed ! make/windows/projectfiles/common/Makefile Changeset: e5bf1c79ed5b Author: zgu Date: 2012-08-14 13:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e5bf1c79ed5b 7191124: Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT Summary: Updated all related variables and methods to use NOT_PRODUCT macros Reviewed-by: coleenp, acorn, kvn ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memPtrArray.hpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp Changeset: fce6d7280776 Author: dcubed Date: 2012-08-17 11:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fce6d7280776 Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/globals.hpp Changeset: b63c0564035a Author: dcubed Date: 2012-08-21 19:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b63c0564035a Merge Changeset: f99a36499b8c Author: johnc Date: 2012-08-21 10:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f99a36499b8c 7192128: G1: Extend fix for 6948537 to G1's BOT Summary: G1 does not appear to be immune to the issue described in CR 6948537 and increasing the size of old-generation PLABs appears to increase the liklihood of seeing the issue. Extend the fix for 6948537 to G1's BlockOffsetTable. Reviewed-by: brutisso, jmasa ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 7383557659bd Author: johnc Date: 2012-08-21 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7383557659bd 7185699: G1: Prediction model discrepancies Summary: Correct the result value of G1CollectedHeap::pending_card_num(). Change the code that calculates the GC efficiency of a non-young heap region to use historical data from mixed GCs and the actual number of live bytes when predicting how long it would take to collect the region. Changes were also reviewed by Thomas Schatzl. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 3650da95d2ee Author: brutisso Date: 2012-08-23 05:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3650da95d2ee 7193157: G1: Make some develpflags available in product builds Summary: Also reviewed by: vitalyd at gmail.com. Make G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, G1OldCSetRegionLiveThresholdPercent and G1OldCSetRegionThresholdPercent experimental flags Reviewed-by: ysr, johnc, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ce0254b13eb8 Author: brutisso Date: 2012-08-24 09:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ce0254b13eb8 Merge Changeset: c32dee9b8023 Author: twisti Date: 2012-08-24 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c32dee9b8023 Merge Changeset: 9e3ae661284d Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9e3ae661284d Merge - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: e8fb566b9466 Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e8fb566b9466 Added tag hs24-b21 for changeset 9e3ae661284d ! .hgtags Changeset: 153776c4cb6f Author: amurillo Date: 2012-08-24 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/153776c4cb6f 7194004: new hotspot build - hs24-b22 Reviewed-by: jcoomes ! make/hotspot_version From anantiitrke at gmail.com Mon Aug 27 08:28:06 2012 From: anantiitrke at gmail.com (Ashish Saxena) Date: Mon, 27 Aug 2012 20:58:06 +0530 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation In-Reply-To: <50367F41.2090307@oracle.com> References: <5034FBE1.2090308@redhat.com> <503509CC.5060303@redhat.com> <503518E6.1090404@redhat.com> <50367F41.2090307@oracle.com> Message-ID: Vladimir, I tried running the application with the JVM Options you provided and 64 MB blocks occurs printing the compilation of methods. However, compilation output shows too many methods getting compiled and not a single huge method. I believe global inling is happening here. As you pointed out, it could be due to register allocator spilling during inlining optimizations during JIT Compilation for particular shape of code. Observation in support of above reason : - 64 MB blocks doesn't occurs with inlining disabled (-XX:-Inline) Open questions : - Why are all blocks (c-heap) nearly 64 MB in size ? Can you please point me to code .. can't find it in chaitin.cpp ? - Why this issue doesn't appear on 32 bit JVM ? Are register allocator code different for 32 bit JVM. Since 32 bit JVM have half the registers compared with 64 bit JVM, register allocator spilling should be more prominent in 32 bit JVM. Are there any Java coding guidelines/observations which can help in writing code that doesn't trigger register spilling ? Similarly are there sample code that can deliberately cause register to spill and show excessive memory usage ? Thanks and Regards, Ashish On Fri, Aug 24, 2012 at 12:36 AM, Vladimir Kozlov wrote: > Ashish, > > It could be related to 7148109. Register Allocator may consume a lot of > memory for particular shape of code. > > You can also check if this memory reservation happens during JIT > compilation. Run with "-Xbatch -XX:CICompilerCount=1 -XX:+PrintCompilation". > Only one compiler thread will run and it will print which method is > compiled. This way you can find which method compilation triggers it if it > is really JIT. > > Regards, > Vladimir > > > Ashish Saxena wrote: >> >> These 64 MB blocks are committed and marked dirty and actually using >> the RAM.. Hence the conern. As Andrew pointed, may be it is due to >> some c-heap allocation specific to 64 bit systems.... but under what >> circumstances do these blocks get allocated ? Which JVM Component / >> Subcomponent is responsible for these extra memory blocks ? >> >> Based on test and JVM options I mentioned above, it seems that these >> gets allocated whenever JVM gets into JIT mode for the first time (may >> be, may be not) ... but which JVM sub component is responsible for >> this memory overhead ? >> >> Thanks, >> Ashish >> >> On Wed, Aug 22, 2012 at 11:07 PM, Andrew Haley wrote: >>> >>> On 08/22/2012 05:36 PM, Vitaly Davidovich wrote: >>>> >>>> Reserving a 64mb private heap sounds fine on 64bit, but it sounds like >>>> that >>>> memory is being committed since RSS goes up? >>> >>> Maybe, maybe not. We don't know that those 64M blocks are committed. >>> All I'm >>> saying is that I have a suspicion that I know what they are. >>> >>> Andrew. >>> > From christian.thalinger at oracle.com Mon Aug 27 09:47:53 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Aug 2012 09:47:53 -0700 Subject: Request for reviews (L): 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites In-Reply-To: <50381AD9.2010907@oracle.com> References: <70714701-5A10-4F15-A7C9-1791C51B6843@oracle.com> <50381AD9.2010907@oracle.com> Message-ID: On Aug 24, 2012, at 5:22 PM, Vladimir Kozlov wrote: > On 8/24/12 4:07 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7192406 >> >> 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites >> Reviewed-by: >> >> When invokedynamic and invokehandle call sites are linked the target is a >> method handle adapter (static method) with a type erased signature. This >> also means the return type of the method is now java.lang.Object while in >> reality it's a more concrete type. >> >> In certain situations with inlining this can cause type mismatches. >> >> This also fixes a problem in constant pool cache where taking a lock might >> result in problems on Solaris. >> >> Additionally I changed GraphKit::compute_stack_effects to check if it was >> called from LibraryCallKit instead of passing in a flag which is very >> error prone. > > What if in a future we may need to call it from LibraryCallKit *before* invoke? That's the only solution I could come up with right now. The problem are uncommon traps. These can be called from anywhere (parse, intrinsics, etc.) and it's difficult to have the additional parameter (which tells you before or after) always right. Maybe I should move this fix to a separate bug and try to write test cases. But it will not cover future additions. -- Chris > > The rest changes look fine. > > thanks, > Vladimir > >> >> src/share/vm/c1/c1_GraphBuilder.cpp >> src/share/vm/c1/c1_GraphBuilder.hpp >> src/share/vm/ci/bcEscapeAnalyzer.cpp >> src/share/vm/ci/ciEnv.cpp >> src/share/vm/ci/ciEnv.hpp >> src/share/vm/ci/ciMethod.cpp >> src/share/vm/ci/ciStreams.cpp >> src/share/vm/ci/ciStreams.hpp >> src/share/vm/ci/ciTypeFlow.cpp >> src/share/vm/interpreter/bytecodes.hpp >> src/share/vm/oops/cpCacheOop.cpp >> src/share/vm/opto/doCall.cpp >> src/share/vm/opto/graphKit.cpp >> src/share/vm/opto/graphKit.hpp >> src/share/vm/opto/library_call.cpp >> src/share/vm/opto/parse1.cpp >> From vladimir.kozlov at oracle.com Mon Aug 27 11:12:28 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Aug 2012 11:12:28 -0700 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation In-Reply-To: References: <5034FBE1.2090308@redhat.com> <503509CC.5060303@redhat.com> <503518E6.1090404@redhat.com> <50367F41.2090307@oracle.com> Message-ID: <503BB88C.3090009@oracle.com> Ashish, I sent webrev for 7148109 fix last week and I am going to push it today: http://cr.openjdk.java.net/~kvn/7148109/webrev.01 Ashish Saxena wrote: > Vladimir, > > I tried running the application with the JVM Options you provided and > 64 MB blocks occurs printing the compilation of methods. However, > compilation output shows too many methods getting compiled and not a It is normal, it means you have a lot of hot methods. > single huge method. I believe global inling is happening here. > > As you pointed out, it could be due to register allocator spilling > during inlining optimizations during JIT Compilation for particular > shape of code. > > Observation in support of above reason : > - 64 MB blocks doesn't occurs with inlining disabled (-XX:-Inline) > > Open questions : > - Why are all blocks (c-heap) nearly 64 MB in size ? Can you please > point me to code .. can't find it in chaitin.cpp ? RA do several attempts (iterations) to allocate as much live values on registers as possible. For each (spill, split) cycle RA allocates few arrays in Split() method with size "sizeof(ptr*)*num_blocks*spill_cnt" and does not free resource on method exit. If spill_cnt stays about the same for 10 iterations you observed, then you will have the same total allocation size. > - Why this issue doesn't appear on 32 bit JVM ? Are register allocator > code different for 32 bit JVM. Since 32 bit JVM have half the > registers compared with 64 bit JVM, register allocator spilling should > be more prominent in 32 bit JVM. Two possibilities. One, most probable, the inlining is different because generated code size is different in 32 bit VM (more spills on stack, more instructions for '64 bit' integer arithmetic and other). And JIT inlining heuristic avoids inlining of method which already have big compiled code. So "deadly" code pattern did not happen. You can play with flag -XX:InlineSmallCode= (default is 1000) to see if it will affect your compilation. Warning: it is our internal flag which was tunned for best performance of most applications. If you change it, it may affect your application performance. An other possibility, RA may be able finish job in one or two iteration because only few registers are available (most live values are kept on stack). But then you should still see one or two 32Mb blocks allocated in native memory. > > Are there any Java coding guidelines/observations which can help in > writing code that doesn't trigger register spilling ? RA will always spill unless a hardware (cpu) has a LOT more registers than x86. One suggestion would be to not pre-load a value which is used only later and does not change in between. > Similarly are there sample code that can deliberately cause register > to spill and show excessive memory usage ? It is a rare case. We never got a small test case. Regards, Vladimir > > Thanks and Regards, > Ashish > > On Fri, Aug 24, 2012 at 12:36 AM, Vladimir Kozlov > wrote: >> Ashish, >> >> It could be related to 7148109. Register Allocator may consume a lot of >> memory for particular shape of code. >> >> You can also check if this memory reservation happens during JIT >> compilation. Run with "-Xbatch -XX:CICompilerCount=1 -XX:+PrintCompilation". >> Only one compiler thread will run and it will print which method is >> compiled. This way you can find which method compilation triggers it if it >> is really JIT. >> >> Regards, >> Vladimir >> >> >> Ashish Saxena wrote: >>> These 64 MB blocks are committed and marked dirty and actually using >>> the RAM.. Hence the conern. As Andrew pointed, may be it is due to >>> some c-heap allocation specific to 64 bit systems.... but under what >>> circumstances do these blocks get allocated ? Which JVM Component / >>> Subcomponent is responsible for these extra memory blocks ? >>> >>> Based on test and JVM options I mentioned above, it seems that these >>> gets allocated whenever JVM gets into JIT mode for the first time (may >>> be, may be not) ... but which JVM sub component is responsible for >>> this memory overhead ? >>> >>> Thanks, >>> Ashish >>> >>> On Wed, Aug 22, 2012 at 11:07 PM, Andrew Haley wrote: >>>> On 08/22/2012 05:36 PM, Vitaly Davidovich wrote: >>>>> Reserving a 64mb private heap sounds fine on 64bit, but it sounds like >>>>> that >>>>> memory is being committed since RSS goes up? >>>> Maybe, maybe not. We don't know that those 64M blocks are committed. >>>> All I'm >>>> saying is that I have a suspicion that I know what they are. >>>> >>>> Andrew. >>>> From vladimir.kozlov at oracle.com Mon Aug 27 11:40:29 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Mon, 27 Aug 2012 18:40:29 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7148109: C2 compiler consumes too much heap resources Message-ID: <20120827184032.186584774B@hg.openjdk.java.net> Changeset: a1c7f6472621 Author: kvn Date: 2012-08-27 09:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a1c7f6472621 7148109: C2 compiler consumes too much heap resources Summary: Add split_arena to allocate temporary arrays in PhaseChaitin::Split() and free them on method's exit. Reviewed-by: twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/reg_split.cpp From yumin.qi at oracle.com Mon Aug 27 14:07:31 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 27 Aug 2012 14:07:31 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly Message-ID: <503BE193.6090807@oracle.com> Hi, all Can I have you code review of 6879063: SA should use hsdis for disassembly http://cr.openjdk.java.net/~minqi/6879063 The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. Tested by dumping full assembly from core files. Reviewed-by: Contributed-by: Tom R (never) Thanks Yumin Qi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120827/28fbbcd2/attachment.html From christian.thalinger at oracle.com Mon Aug 27 14:43:58 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Aug 2012 14:43:58 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503BE193.6090807@oracle.com> References: <503BE193.6090807@oracle.com> Message-ID: <96CEE190-ECC8-40DF-A811-2CA07DDCA1D2@oracle.com> On Aug 27, 2012, at 2:07 PM, Yumin Qi wrote: > Hi, all > > Can I have you code review of > 6879063: SA should use hsdis for disassembly > > http://cr.openjdk.java.net/~minqi/6879063 > > The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). > > All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. > > Tested by dumping full assembly from core files. > > Reviewed-by: > Contributed-by: Tom R (never) src/share/tools/hsdis/hsdis.c: Maybe decode_instructions should call decode_instructions_virtual. agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java: + String cpu = VM.getVM().getCPU(); + if (cpu.equals("sparc")) { + if (VM.getVM().isLP64()) { + libname = "hsdis-sparcv9"; + options = "v9only"; + } else { + libname = "hsdis-sparc"; + } + } else if (cpu.equals("x86")) { + libname = "hsdis-i386"; + } else if (cpu.equals("amd64")) { + libname = "hsdis-amd64"; + } else if (cpu.equals("ia64")) { + libname = "hsdis-ia64"; + } Should we use some default libname here like: libname = "hsdis-" + cpu; so we cover other architectures too (and only special-case sparc, x86, ...)? Otherwise it looks good. -- Chris > > Thanks > Yumin Qi > From christian.thalinger at oracle.com Mon Aug 27 16:31:55 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Aug 2012 16:31:55 -0700 Subject: Request for reviews (L): 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites In-Reply-To: References: <70714701-5A10-4F15-A7C9-1791C51B6843@oracle.com> <50381AD9.2010907@oracle.com> Message-ID: <64CD9D73-3233-4F4E-A199-8A49BFB132E4@oracle.com> On Aug 27, 2012, at 9:47 AM, Christian Thalinger wrote: > > On Aug 24, 2012, at 5:22 PM, Vladimir Kozlov wrote: > >> On 8/24/12 4:07 PM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7192406 >>> >>> 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites >>> Reviewed-by: >>> >>> When invokedynamic and invokehandle call sites are linked the target is a >>> method handle adapter (static method) with a type erased signature. This >>> also means the return type of the method is now java.lang.Object while in >>> reality it's a more concrete type. >>> >>> In certain situations with inlining this can cause type mismatches. >>> >>> This also fixes a problem in constant pool cache where taking a lock might >>> result in problems on Solaris. >>> >>> Additionally I changed GraphKit::compute_stack_effects to check if it was >>> called from LibraryCallKit instead of passing in a flag which is very >>> error prone. >> >> What if in a future we may need to call it from LibraryCallKit *before* invoke? > > That's the only solution I could come up with right now. The problem are uncommon traps. These can be called from anywhere (parse, intrinsics, etc.) and it's difficult to have the additional parameter (which tells you before or after) always right. > > Maybe I should move this fix to a separate bug and try to write test cases. But it will not cover future additions. After some discussion I'm removing this fix and file a separate bug for it. I'm also removing the CP cache fix since I hit the guarantee in one of my test runs. -- Chris > > -- Chris > >> >> The rest changes look fine. >> >> thanks, >> Vladimir >> >>> >>> src/share/vm/c1/c1_GraphBuilder.cpp >>> src/share/vm/c1/c1_GraphBuilder.hpp >>> src/share/vm/ci/bcEscapeAnalyzer.cpp >>> src/share/vm/ci/ciEnv.cpp >>> src/share/vm/ci/ciEnv.hpp >>> src/share/vm/ci/ciMethod.cpp >>> src/share/vm/ci/ciStreams.cpp >>> src/share/vm/ci/ciStreams.hpp >>> src/share/vm/ci/ciTypeFlow.cpp >>> src/share/vm/interpreter/bytecodes.hpp >>> src/share/vm/oops/cpCacheOop.cpp >>> src/share/vm/opto/doCall.cpp >>> src/share/vm/opto/graphKit.cpp >>> src/share/vm/opto/graphKit.hpp >>> src/share/vm/opto/library_call.cpp >>> src/share/vm/opto/parse1.cpp >>> From yumin.qi at oracle.com Mon Aug 27 17:22:18 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 27 Aug 2012 17:22:18 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <96CEE190-ECC8-40DF-A811-2CA07DDCA1D2@oracle.com> References: <503BE193.6090807@oracle.com> <96CEE190-ECC8-40DF-A811-2CA07DDCA1D2@oracle.com> Message-ID: <503C0F3A.2000506@oracle.com> Thanks. I will modify like that. By the way, missed one file, will add and resend out the modified version. make/solaris/makefiles/sa.make Thanks Yumin On 2012/8/27 14:43, Christian Thalinger wrote: > On Aug 27, 2012, at 2:07 PM, Yumin Qi wrote: > >> Hi, all >> >> Can I have you code review of >> 6879063: SA should use hsdis for disassembly >> >> http://cr.openjdk.java.net/~minqi/6879063 >> >> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >> >> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >> >> Tested by dumping full assembly from core files. >> >> Reviewed-by: >> Contributed-by: Tom R (never) > src/share/tools/hsdis/hsdis.c: > > Maybe decode_instructions should call decode_instructions_virtual. > > agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java: > > + String cpu = VM.getVM().getCPU(); > + if (cpu.equals("sparc")) { > + if (VM.getVM().isLP64()) { > + libname = "hsdis-sparcv9"; > + options = "v9only"; > + } else { > + libname = "hsdis-sparc"; > + } > + } else if (cpu.equals("x86")) { > + libname = "hsdis-i386"; > + } else if (cpu.equals("amd64")) { > + libname = "hsdis-amd64"; > + } else if (cpu.equals("ia64")) { > + libname = "hsdis-ia64"; > + } > > Should we use some default libname here like: > > libname = "hsdis-" + cpu; > > so we cover other architectures too (and only special-case sparc, x86, ...)? > > Otherwise it looks good. > > -- Chris > >> Thanks >> Yumin Qi >> From christian.thalinger at oracle.com Mon Aug 27 17:33:53 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 28 Aug 2012 00:33:53 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 6677625: Move platform specific flags from globals.hpp to globals_.hpp Message-ID: <20120828003358.23ECF47761@hg.openjdk.java.net> Changeset: a5dd6e3ef9f3 Author: twisti Date: 2012-08-27 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a5dd6e3ef9f3 6677625: Move platform specific flags from globals.hpp to globals_.hpp Reviewed-by: kvn, dholmes, coleenp Contributed-by: Tao Mao ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp From vladimir.x.ivanov at oracle.com Tue Aug 28 03:19:27 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 Aug 2012 14:19:27 +0400 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503BE193.6090807@oracle.com> References: <503BE193.6090807@oracle.com> Message-ID: <503C9B2F.8000402@oracle.com> Yumin, Nice work! Since you touch src/share/tools/hsdis/Makefile, can you fix the following typo as well? --- a/src/share/tools/hsdis/Makefile Fri Aug 24 16:23:59 2012 -0700 +++ b/src/share/tools/hsdis/Makefile Tue Aug 28 14:16:07 2012 +0400 @@ -118,7 +118,7 @@ BINUTILSDIR = $(shell cd $(BINUTILS);pwd) endif -CPPFLAGS += -I$(BINUTILSDIR)/include -I$(BINUTILS)/bfd -I$(TARGET_DIR)/bfd +CPPFLAGS += -I$(BINUTILSDIR)/include -I$(BINUTILSDIR)/bfd -I$(TARGET_DIR)/bfd CPPFLAGS += -DLIBARCH_$(LIBARCH) -DLIBARCH=\"$(LIBARCH)\" -DLIB_EXT=\"$(LIB_EXT)\" TARGET_DIR = build/$(OS)-$(JDKARCH) Best regards, Vladimir Ivanov On 08/28/12 01:07, Yumin Qi wrote: > Hi, all > > Can I have you code review of > 6879063: SA should use hsdis for disassembly > > http://cr.openjdk.java.net/~minqi/6879063 > > > The SA has Java based disassemblers for x86 and sparc but amd64. > Instead of porting to amd64 we should switch over to using hsdis for it > like the JVM does. This requires a new entry point into hsdis, > decode_instructions_virtual, which separates the address of the code > being disassembled from the buffer containing the code. The existing > uses of decode_instructions have been updated to use the new interface > and SA Disassembler has Java native methods that call into hsdis and > call back up to Java to perform the disassembly. Also changed makefile > for hsdis build for both(i386/amd64). > > All the old disassembler logic was deleted since it's incompatible > with the new disassembly interface. Also deleted are dbx based SA > interface and few other dead files. > > Tested by dumping full assembly from core files. > > Reviewed-by: > Contributed-by: Tom R (never) > > Thanks > Yumin Qi > From yumin.qi at oracle.com Tue Aug 28 08:47:57 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Tue, 28 Aug 2012 08:47:57 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503C9B2F.8000402@oracle.com> References: <503BE193.6090807@oracle.com> <503C9B2F.8000402@oracle.com> Message-ID: <503CE82D.4090601@oracle.com> Thanks. Will do. Yumin On 8/28/2012 3:19 AM, Vladimir Ivanov wrote: > Yumin, > > Nice work! > > Since you touch src/share/tools/hsdis/Makefile, can you fix the > following typo as well? > > --- a/src/share/tools/hsdis/Makefile Fri Aug 24 16:23:59 2012 -0700 > +++ b/src/share/tools/hsdis/Makefile Tue Aug 28 14:16:07 2012 +0400 > @@ -118,7 +118,7 @@ > BINUTILSDIR = $(shell cd $(BINUTILS);pwd) > endif > > -CPPFLAGS += -I$(BINUTILSDIR)/include -I$(BINUTILS)/bfd > -I$(TARGET_DIR)/bfd > +CPPFLAGS += -I$(BINUTILSDIR)/include -I$(BINUTILSDIR)/bfd > -I$(TARGET_DIR)/bfd > CPPFLAGS += -DLIBARCH_$(LIBARCH) -DLIBARCH=\"$(LIBARCH)\" > -DLIB_EXT=\"$(LIB_EXT)\" > > TARGET_DIR = build/$(OS)-$(JDKARCH) > > Best regards, > Vladimir Ivanov > > On 08/28/12 01:07, Yumin Qi wrote: >> Hi, all >> >> Can I have you code review of >> 6879063: SA should use hsdis for disassembly >> >> http://cr.openjdk.java.net/~minqi/6879063 >> >> >> The SA has Java based disassemblers for x86 and sparc but amd64. >> Instead of porting to amd64 we should switch over to using hsdis for it >> like the JVM does. This requires a new entry point into hsdis, >> decode_instructions_virtual, which separates the address of the code >> being disassembled from the buffer containing the code. The existing >> uses of decode_instructions have been updated to use the new interface >> and SA Disassembler has Java native methods that call into hsdis and >> call back up to Java to perform the disassembly. Also changed makefile >> for hsdis build for both(i386/amd64). >> >> All the old disassembler logic was deleted since it's incompatible >> with the new disassembly interface. Also deleted are dbx based SA >> interface and few other dead files. >> >> Tested by dumping full assembly from core files. >> >> Reviewed-by: >> Contributed-by: Tom R (never) >> >> Thanks >> Yumin Qi >> From yumin.qi at oracle.com Tue Aug 28 08:56:12 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Tue, 28 Aug 2012 08:56:12 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> References: <503BE193.6090807@oracle.com> <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> Message-ID: <503CEA1C.6030004@oracle.com> Thanks. On 8/28/2012 2:12 AM, Staffan Larsen wrote: > Thanks for picking up Tom's work and completing it. Anything that > removes 20k lines of code must be good :-) > > Is there a way we can write a jtreg test for this? Either by debugging > a live JVM or a core file? Having a test would be very helpful, > although it may be impossible because of the requirement to download > and build binutils. Any other way we can add automatic testing for this? > If it is possible, will be under anther id --- that is no less work for live process and core file stuff. I will investigate that possibility. > What platforms have you done manual testing on? > Solaris and Linux > I noticed that the makefile changes are missing from the bsd makefiles. > Yes. > Unrelated comment: we should remove the ia64 code from SA... > This should be removed since we no longer support ia64 and the also the code is dead too. --Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120828/9ddad9aa/attachment.html From christian.thalinger at oracle.com Tue Aug 28 13:01:23 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Aug 2012 13:01:23 -0700 Subject: Request for reviews (L): 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites In-Reply-To: <64CD9D73-3233-4F4E-A199-8A49BFB132E4@oracle.com> References: <70714701-5A10-4F15-A7C9-1791C51B6843@oracle.com> <50381AD9.2010907@oracle.com> <64CD9D73-3233-4F4E-A199-8A49BFB132E4@oracle.com> Message-ID: On Aug 27, 2012, at 4:31 PM, Christian Thalinger wrote: > > On Aug 27, 2012, at 9:47 AM, Christian Thalinger wrote: > >> >> On Aug 24, 2012, at 5:22 PM, Vladimir Kozlov wrote: >> >>> On 8/24/12 4:07 PM, Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/7192406 >>>> >>>> 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites >>>> Reviewed-by: >>>> >>>> When invokedynamic and invokehandle call sites are linked the target is a >>>> method handle adapter (static method) with a type erased signature. This >>>> also means the return type of the method is now java.lang.Object while in >>>> reality it's a more concrete type. >>>> >>>> In certain situations with inlining this can cause type mismatches. >>>> >>>> This also fixes a problem in constant pool cache where taking a lock might >>>> result in problems on Solaris. >>>> >>>> Additionally I changed GraphKit::compute_stack_effects to check if it was >>>> called from LibraryCallKit instead of passing in a flag which is very >>>> error prone. >>> >>> What if in a future we may need to call it from LibraryCallKit *before* invoke? >> >> That's the only solution I could come up with right now. The problem are uncommon traps. These can be called from anywhere (parse, intrinsics, etc.) and it's difficult to have the additional parameter (which tells you before or after) always right. >> >> Maybe I should move this fix to a separate bug and try to write test cases. But it will not cover future additions. > > After some discussion I'm removing this fix and file a separate bug for it. I'm also removing the CP cache fix since I hit the guarantee in one of my test runs. I updated the webrev and filed: 7194647: JSR 292: GraphKit::compute_stack_effects needs to be aware of appendix and MemberName arguments -- Chris > > -- Chris > >> >> -- Chris >> >>> >>> The rest changes look fine. >>> >>> thanks, >>> Vladimir >>> >>>> >>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>> src/share/vm/c1/c1_GraphBuilder.hpp >>>> src/share/vm/ci/bcEscapeAnalyzer.cpp >>>> src/share/vm/ci/ciEnv.cpp >>>> src/share/vm/ci/ciEnv.hpp >>>> src/share/vm/ci/ciMethod.cpp >>>> src/share/vm/ci/ciStreams.cpp >>>> src/share/vm/ci/ciStreams.hpp >>>> src/share/vm/ci/ciTypeFlow.cpp >>>> src/share/vm/interpreter/bytecodes.hpp >>>> src/share/vm/oops/cpCacheOop.cpp >>>> src/share/vm/opto/doCall.cpp >>>> src/share/vm/opto/graphKit.cpp >>>> src/share/vm/opto/graphKit.hpp >>>> src/share/vm/opto/library_call.cpp >>>> src/share/vm/opto/parse1.cpp >>>> > From christian.thalinger at oracle.com Tue Aug 28 14:36:23 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 28 Aug 2012 21:36:23 +0000 Subject: hg: hsx/hotspot-comp/jdk: 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa Message-ID: <20120828213711.BC1984778B@hg.openjdk.java.net> Changeset: a43f1cd05776 Author: jrose Date: 2012-08-28 13:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a43f1cd05776 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa Reviewed-by: kvn, twisti ! src/share/classes/java/lang/invoke/MemberName.java From christian.thalinger at oracle.com Tue Aug 28 14:58:35 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 28 Aug 2012 21:58:35 +0000 Subject: hg: hsx/hotspot-comp/jdk: 7194662: JSR 292: PermuteArgsTest times out in nightly test runs Message-ID: <20120828215854.D91EB4778C@hg.openjdk.java.net> Changeset: 59231f2cb6e1 Author: twisti Date: 2012-08-28 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/59231f2cb6e1 7194662: JSR 292: PermuteArgsTest times out in nightly test runs Reviewed-by: kvn ! test/java/lang/invoke/PermuteArgsTest.java From vladimir.kozlov at oracle.com Tue Aug 28 15:09:52 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Aug 2012 15:09:52 -0700 Subject: Request for reviews (L): 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites In-Reply-To: References: <70714701-5A10-4F15-A7C9-1791C51B6843@oracle.com> <50381AD9.2010907@oracle.com> <64CD9D73-3233-4F4E-A199-8A49BFB132E4@oracle.com> Message-ID: <503D41B0.1090108@oracle.com> Please add assert(declared_signature != NULL) after get_method() calls. Thanks, Vladimir Christian Thalinger wrote: > On Aug 27, 2012, at 4:31 PM, Christian Thalinger wrote: > >> On Aug 27, 2012, at 9:47 AM, Christian Thalinger wrote: >> >>> On Aug 24, 2012, at 5:22 PM, Vladimir Kozlov wrote: >>> >>>> On 8/24/12 4:07 PM, Christian Thalinger wrote: >>>>> http://cr.openjdk.java.net/~twisti/7192406 >>>>> >>>>> 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites >>>>> Reviewed-by: >>>>> >>>>> When invokedynamic and invokehandle call sites are linked the target is a >>>>> method handle adapter (static method) with a type erased signature. This >>>>> also means the return type of the method is now java.lang.Object while in >>>>> reality it's a more concrete type. >>>>> >>>>> In certain situations with inlining this can cause type mismatches. >>>>> >>>>> This also fixes a problem in constant pool cache where taking a lock might >>>>> result in problems on Solaris. >>>>> >>>>> Additionally I changed GraphKit::compute_stack_effects to check if it was >>>>> called from LibraryCallKit instead of passing in a flag which is very >>>>> error prone. >>>> What if in a future we may need to call it from LibraryCallKit *before* invoke? >>> That's the only solution I could come up with right now. The problem are uncommon traps. These can be called from anywhere (parse, intrinsics, etc.) and it's difficult to have the additional parameter (which tells you before or after) always right. >>> >>> Maybe I should move this fix to a separate bug and try to write test cases. But it will not cover future additions. >> After some discussion I'm removing this fix and file a separate bug for it. I'm also removing the CP cache fix since I hit the guarantee in one of my test runs. > > I updated the webrev and filed: > > 7194647: JSR 292: GraphKit::compute_stack_effects needs to be aware of appendix and MemberName arguments > > -- Chris > >> -- Chris >> >>> -- Chris >>> >>>> The rest changes look fine. >>>> >>>> thanks, >>>> Vladimir >>>> >>>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>>> src/share/vm/c1/c1_GraphBuilder.hpp >>>>> src/share/vm/ci/bcEscapeAnalyzer.cpp >>>>> src/share/vm/ci/ciEnv.cpp >>>>> src/share/vm/ci/ciEnv.hpp >>>>> src/share/vm/ci/ciMethod.cpp >>>>> src/share/vm/ci/ciStreams.cpp >>>>> src/share/vm/ci/ciStreams.hpp >>>>> src/share/vm/ci/ciTypeFlow.cpp >>>>> src/share/vm/interpreter/bytecodes.hpp >>>>> src/share/vm/oops/cpCacheOop.cpp >>>>> src/share/vm/opto/doCall.cpp >>>>> src/share/vm/opto/graphKit.cpp >>>>> src/share/vm/opto/graphKit.hpp >>>>> src/share/vm/opto/library_call.cpp >>>>> src/share/vm/opto/parse1.cpp >>>>> > From christian.thalinger at oracle.com Tue Aug 28 15:23:45 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Aug 2012 15:23:45 -0700 Subject: Request for reviews (L): 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites In-Reply-To: <503D41B0.1090108@oracle.com> References: <70714701-5A10-4F15-A7C9-1791C51B6843@oracle.com> <50381AD9.2010907@oracle.com> <64CD9D73-3233-4F4E-A199-8A49BFB132E4@oracle.com> <503D41B0.1090108@oracle.com> Message-ID: <17A130A0-0845-426D-9C1B-3E7217BC966A@oracle.com> On Aug 28, 2012, at 3:09 PM, Vladimir Kozlov wrote: > Please add assert(declared_signature != NULL) after get_method() calls. Done. -- Chris > > Thanks, > Vladimir > > Christian Thalinger wrote: >> On Aug 27, 2012, at 4:31 PM, Christian Thalinger wrote: >>> On Aug 27, 2012, at 9:47 AM, Christian Thalinger wrote: >>> >>>> On Aug 24, 2012, at 5:22 PM, Vladimir Kozlov wrote: >>>> >>>>> On 8/24/12 4:07 PM, Christian Thalinger wrote: >>>>>> http://cr.openjdk.java.net/~twisti/7192406 >>>>>> >>>>>> 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites >>>>>> Reviewed-by: >>>>>> >>>>>> When invokedynamic and invokehandle call sites are linked the target is a >>>>>> method handle adapter (static method) with a type erased signature. This >>>>>> also means the return type of the method is now java.lang.Object while in >>>>>> reality it's a more concrete type. >>>>>> >>>>>> In certain situations with inlining this can cause type mismatches. >>>>>> >>>>>> This also fixes a problem in constant pool cache where taking a lock might >>>>>> result in problems on Solaris. >>>>>> >>>>>> Additionally I changed GraphKit::compute_stack_effects to check if it was >>>>>> called from LibraryCallKit instead of passing in a flag which is very >>>>>> error prone. >>>>> What if in a future we may need to call it from LibraryCallKit *before* invoke? >>>> That's the only solution I could come up with right now. The problem are uncommon traps. These can be called from anywhere (parse, intrinsics, etc.) and it's difficult to have the additional parameter (which tells you before or after) always right. >>>> >>>> Maybe I should move this fix to a separate bug and try to write test cases. But it will not cover future additions. >>> After some discussion I'm removing this fix and file a separate bug for it. I'm also removing the CP cache fix since I hit the guarantee in one of my test runs. >> I updated the webrev and filed: >> 7194647: JSR 292: GraphKit::compute_stack_effects needs to be aware of appendix and MemberName arguments >> -- Chris >>> -- Chris >>> >>>> -- Chris >>>> >>>>> The rest changes look fine. >>>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>>>> src/share/vm/c1/c1_GraphBuilder.hpp >>>>>> src/share/vm/ci/bcEscapeAnalyzer.cpp >>>>>> src/share/vm/ci/ciEnv.cpp >>>>>> src/share/vm/ci/ciEnv.hpp >>>>>> src/share/vm/ci/ciMethod.cpp >>>>>> src/share/vm/ci/ciStreams.cpp >>>>>> src/share/vm/ci/ciStreams.hpp >>>>>> src/share/vm/ci/ciTypeFlow.cpp >>>>>> src/share/vm/interpreter/bytecodes.hpp >>>>>> src/share/vm/oops/cpCacheOop.cpp >>>>>> src/share/vm/opto/doCall.cpp >>>>>> src/share/vm/opto/graphKit.cpp >>>>>> src/share/vm/opto/graphKit.hpp >>>>>> src/share/vm/opto/library_call.cpp >>>>>> src/share/vm/opto/parse1.cpp >>>>>> From vladimir.kozlov at oracle.com Tue Aug 28 15:19:26 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Aug 2012 15:19:26 -0700 Subject: Request for reviews (L): 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites In-Reply-To: <17A130A0-0845-426D-9C1B-3E7217BC966A@oracle.com> References: <70714701-5A10-4F15-A7C9-1791C51B6843@oracle.com> <50381AD9.2010907@oracle.com> <64CD9D73-3233-4F4E-A199-8A49BFB132E4@oracle.com> <503D41B0.1090108@oracle.com> <17A130A0-0845-426D-9C1B-3E7217BC966A@oracle.com> Message-ID: <503D43EE.4040703@oracle.com> Good. Vladimir Christian Thalinger wrote: > On Aug 28, 2012, at 3:09 PM, Vladimir Kozlov wrote: > >> Please add assert(declared_signature != NULL) after get_method() calls. > > Done. -- Chris > >> Thanks, >> Vladimir >> >> Christian Thalinger wrote: >>> On Aug 27, 2012, at 4:31 PM, Christian Thalinger wrote: >>>> On Aug 27, 2012, at 9:47 AM, Christian Thalinger wrote: >>>> >>>>> On Aug 24, 2012, at 5:22 PM, Vladimir Kozlov wrote: >>>>> >>>>>> On 8/24/12 4:07 PM, Christian Thalinger wrote: >>>>>>> http://cr.openjdk.java.net/~twisti/7192406 >>>>>>> >>>>>>> 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites >>>>>>> Reviewed-by: >>>>>>> >>>>>>> When invokedynamic and invokehandle call sites are linked the target is a >>>>>>> method handle adapter (static method) with a type erased signature. This >>>>>>> also means the return type of the method is now java.lang.Object while in >>>>>>> reality it's a more concrete type. >>>>>>> >>>>>>> In certain situations with inlining this can cause type mismatches. >>>>>>> >>>>>>> This also fixes a problem in constant pool cache where taking a lock might >>>>>>> result in problems on Solaris. >>>>>>> >>>>>>> Additionally I changed GraphKit::compute_stack_effects to check if it was >>>>>>> called from LibraryCallKit instead of passing in a flag which is very >>>>>>> error prone. >>>>>> What if in a future we may need to call it from LibraryCallKit *before* invoke? >>>>> That's the only solution I could come up with right now. The problem are uncommon traps. These can be called from anywhere (parse, intrinsics, etc.) and it's difficult to have the additional parameter (which tells you before or after) always right. >>>>> >>>>> Maybe I should move this fix to a separate bug and try to write test cases. But it will not cover future additions. >>>> After some discussion I'm removing this fix and file a separate bug for it. I'm also removing the CP cache fix since I hit the guarantee in one of my test runs. >>> I updated the webrev and filed: >>> 7194647: JSR 292: GraphKit::compute_stack_effects needs to be aware of appendix and MemberName arguments >>> -- Chris >>>> -- Chris >>>> >>>>> -- Chris >>>>> >>>>>> The rest changes look fine. >>>>>> >>>>>> thanks, >>>>>> Vladimir >>>>>> >>>>>>> src/share/vm/c1/c1_GraphBuilder.cpp >>>>>>> src/share/vm/c1/c1_GraphBuilder.hpp >>>>>>> src/share/vm/ci/bcEscapeAnalyzer.cpp >>>>>>> src/share/vm/ci/ciEnv.cpp >>>>>>> src/share/vm/ci/ciEnv.hpp >>>>>>> src/share/vm/ci/ciMethod.cpp >>>>>>> src/share/vm/ci/ciStreams.cpp >>>>>>> src/share/vm/ci/ciStreams.hpp >>>>>>> src/share/vm/ci/ciTypeFlow.cpp >>>>>>> src/share/vm/interpreter/bytecodes.hpp >>>>>>> src/share/vm/oops/cpCacheOop.cpp >>>>>>> src/share/vm/opto/doCall.cpp >>>>>>> src/share/vm/opto/graphKit.cpp >>>>>>> src/share/vm/opto/graphKit.hpp >>>>>>> src/share/vm/opto/library_call.cpp >>>>>>> src/share/vm/opto/parse1.cpp >>>>>>> > From yumin.qi at oracle.com Tue Aug 28 16:48:28 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 28 Aug 2012 16:48:28 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503BE193.6090807@oracle.com> References: <503BE193.6090807@oracle.com> Message-ID: <503D58CC.9090806@oracle.com> Hi, all Updated with feedback suggestions. Please have a look again at the same link. Thanks Yumin On 2012/8/27 14:07, Yumin Qi wrote: > Hi, all > > Can I have you code review of > 6879063: SA should use hsdis for disassembly > > http://cr.openjdk.java.net/~minqi/6879063 > > > The SA has Java based disassemblers for x86 and sparc but amd64. > Instead of porting to amd64 we should switch over to using hsdis for > it like the JVM does. This requires a new entry point into hsdis, > decode_instructions_virtual, which separates the address of the code > being disassembled from the buffer containing the code. The existing > uses of decode_instructions have been updated to use the new interface > and SA Disassembler has Java native methods that call into hsdis and > call back up to Java to perform the disassembly. Also changed makefile > for hsdis build for both(i386/amd64). > > All the old disassembler logic was deleted since it's incompatible > with the new disassembly interface. Also deleted are dbx based SA > interface and few other dead files. > > Tested by dumping full assembly from core files. > > Reviewed-by: > Contributed-by: Tom R (never) > > Thanks > Yumin Qi > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120828/3428ba46/attachment-0001.html From vladimir.kozlov at oracle.com Tue Aug 28 17:35:29 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Aug 2012 17:35:29 -0700 Subject: Request for reviews (M): 7160161: Missed safepoint in non-Counted loop Message-ID: <503D63D1.6000302@oracle.com> http://cr.openjdk.java.net/~kvn/7160161/webrev 7160161: Missed safepoint in non-Counted loop Loop peeling optimization removes needed safepoints from peeled iteration of inner non-counted loop during OSR compilation. As result the path without safepoints is created in outer loop. Do not remove safepoints during peeling optimization. Improve the code in IdealLoopTree::counted_loop() to eliminate all others safepoints in a loop (but not in this loop's nested loops) which have a safepoint on dominating path. Tested with provided test case, CTW, jtreg Compiler. Did analysis of code generated for nested loops which are not counted. Thanks, Vladimir From christian.thalinger at oracle.com Tue Aug 28 17:48:49 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 29 Aug 2012 00:48:49 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites Message-ID: <20120829004853.A2D4A4778F@hg.openjdk.java.net> Changeset: 7f813940ac35 Author: twisti Date: 2012-08-28 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7f813940ac35 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp From christian.thalinger at oracle.com Tue Aug 28 17:54:21 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Aug 2012 17:54:21 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503D58CC.9090806@oracle.com> References: <503BE193.6090807@oracle.com> <503D58CC.9090806@oracle.com> Message-ID: Looks good. -- Chris On Aug 28, 2012, at 4:48 PM, Yumin Qi wrote: > Hi, all > > Updated with feedback suggestions. Please have a look again at the same link. > > Thanks > Yumin > > > > > On 2012/8/27 14:07, Yumin Qi wrote: >> Hi, all >> >> Can I have you code review of >> 6879063: SA should use hsdis for disassembly >> >> http://cr.openjdk.java.net/~minqi/6879063 >> >> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >> >> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >> >> Tested by dumping full assembly from core files. >> >> Reviewed-by: >> Contributed-by: Tom R (never) >> >> Thanks >> Yumin Qi >> From yumin.qi at oracle.com Tue Aug 28 20:23:56 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 28 Aug 2012 20:23:56 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: References: <503BE193.6090807@oracle.com> <503D58CC.9090806@oracle.com> Message-ID: <503D8B4C.7020805@oracle.com> Chris, Now I updated hsdis Makefile, remove platforms related to ppc (not in open). Thanks Yumin On 2012/8/28 17:54, Christian Thalinger wrote: > Looks good. -- Chris > > On Aug 28, 2012, at 4:48 PM, Yumin Qi wrote: > >> Hi, all >> >> Updated with feedback suggestions. Please have a look again at the same link. >> >> Thanks >> Yumin >> >> >> >> >> On 2012/8/27 14:07, Yumin Qi wrote: >>> Hi, all >>> >>> Can I have you code review of >>> 6879063: SA should use hsdis for disassembly >>> >>> http://cr.openjdk.java.net/~minqi/6879063 >>> >>> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >>> >>> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >>> >>> Tested by dumping full assembly from core files. >>> >>> Reviewed-by: >>> Contributed-by: Tom R (never) >>> >>> Thanks >>> Yumin Qi >>> From yumin.qi at oracle.com Wed Aug 29 07:01:10 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 29 Aug 2012 07:01:10 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: References: <503BE193.6090807@oracle.com> <503D58CC.9090806@oracle.com> Message-ID: <503E20A6.8090909@oracle.com> This version of webrev diff is messed up. Please ignore it. Will let you know when it is OK. Thanks for the suggestion I will test on Windows and OS X. Thanks Yumin On 2012/8/28 23:08, Staffan Larsen wrote: > Yumin, > > The bsd makefiles are still not updated as far as I can see. I think > this should be tested on OS X and Windows as well as Linux and Solaris > before it goes in. > > Thanks, > /Staffan > > > > On 29 aug 2012, at 01:48, Yumin Qi > wrote: > >> Hi, all >> >> Updated with feedback suggestions. Please have a look again at the >> same link. >> >> Thanks >> Yumin >> >> >> >> >> On 2012/8/27 14:07, Yumin Qi wrote: >>> Hi, all >>> >>> Can I have you code review of >>> 6879063: SA should use hsdis for disassembly >>> >>> http://cr.openjdk.java.net/~minqi/6879063 >>> >>> >>> The SA has Java based disassemblers for x86 and sparc but amd64. >>> Instead of porting to amd64 we should switch over to using hsdis for >>> it like the JVM does. This requires a new entry point into hsdis, >>> decode_instructions_virtual, which separates the address of the code >>> being disassembled from the buffer containing the code. The >>> existing uses of decode_instructions have been updated to use the >>> new interface and SA Disassembler has Java native methods that call >>> into hsdis and call back up to Java to perform the disassembly. Also >>> changed makefile for hsdis build for both(i386/amd64). >>> >>> All the old disassembler logic was deleted since it's incompatible >>> with the new disassembly interface. Also deleted are dbx based SA >>> interface and few other dead files. >>> >>> Tested by dumping full assembly from core files. >>> >>> Reviewed-by: >>> Contributed-by: Tom R (never) >>> >>> Thanks >>> Yumin Qi >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120829/69471f31/attachment.html From smourachov at gmail.com Tue Aug 28 20:49:08 2012 From: smourachov at gmail.com (Serguei Mourachov) Date: Tue, 28 Aug 2012 20:49:08 -0700 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation Message-ID: <503D9134.5020001@gmail.com> That could also be a result of glibc bug http://sourceware.org/bugzilla/show_bug.cgi?id=11261 what is fixed only in RHEL/CentOS 6, I think: http://sourceware.org/bugzilla/show_bug.cgi?id=13071 From our experience, setting MALLOC_ARENA_MAX=1 on RHEL/CentOS 5 should help, unless you are heavily calling malloc from your app using JNI or Unsafe. Serguei Mourachov From staffan.larsen at oracle.com Tue Aug 28 23:08:52 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 29 Aug 2012 08:08:52 +0200 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503D58CC.9090806@oracle.com> References: <503BE193.6090807@oracle.com> <503D58CC.9090806@oracle.com> Message-ID: Yumin, The bsd makefiles are still not updated as far as I can see. I think this should be tested on OS X and Windows as well as Linux and Solaris before it goes in. Thanks, /Staffan On 29 aug 2012, at 01:48, Yumin Qi wrote: > Hi, all > > Updated with feedback suggestions. Please have a look again at the same link. > > Thanks > Yumin > > > > > On 2012/8/27 14:07, Yumin Qi wrote: >> >> Hi, all >> >> Can I have you code review of >> 6879063: SA should use hsdis for disassembly >> >> http://cr.openjdk.java.net/~minqi/6879063 >> >> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >> >> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >> >> Tested by dumping full assembly from core files. >> >> Reviewed-by: >> Contributed-by: Tom R (never) >> >> Thanks >> Yumin Qi >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120829/44e4c949/attachment-0001.html From aph at redhat.com Wed Aug 29 08:30:01 2012 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Aug 2012 16:30:01 +0100 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation In-Reply-To: <503D9134.5020001@gmail.com> References: <503D9134.5020001@gmail.com> Message-ID: <503E3579.70501@redhat.com> On 08/29/2012 04:49 AM, Serguei Mourachov wrote: > That could also be a result of glibc bug > http://sourceware.org/bugzilla/show_bug.cgi?id=11261 That one is not a bug, as Ulrich explains. It's a misunderstanding of what is supposed tp happen. Andrew. From smourachov at gmail.com Wed Aug 29 09:05:33 2012 From: smourachov at gmail.com (Serguei Mourachov) Date: Wed, 29 Aug 2012 09:05:33 -0700 Subject: Java 64 bit consumes excessive native memory (c-heap) due to JIT Compilation In-Reply-To: <503E3579.70501@redhat.com> References: <503D9134.5020001@gmail.com> <503E3579.70501@redhat.com> Message-ID: <503E3DCD.6030005@gmail.com> On 29-Aug-2012 08:30, Andrew Haley wrote: > On 08/29/2012 04:49 AM, Serguei Mourachov wrote: >> That could also be a result of glibc bug >> http://sourceware.org/bugzilla/show_bug.cgi?id=11261 > That one is not a bug, as Ulrich explains. It's a misunderstanding > of what is supposed tp happen. > > Andrew. > Right, actually I meant the MALLOC_ARENA_MAX race condition issue. We have observed behavior similar to what Ashish has described in two occasions. In first case it was jdk6 running on RHEL 5, at that time we could not figure out real cause of the problem and just switched to jdk7, that apparently is using somewhat different memory allocation strategy. Second case was about our code running on jdk7 and calling malloc/free using Unsafe from multiple threads, in that case we had to switch to RHEL6 and start using MALLOC_ARENA_MAX=1. After we found actual source of the our problems , we switched the first application to use MALLOC_ARENA_MAX=1 on jdk7/RHEL5 and we saw some substantial reduce in memory consumption as well, but not as significant as in our second case. Serguei Mourachov From christian.thalinger at oracle.com Wed Aug 29 12:03:01 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 29 Aug 2012 12:03:01 -0700 Subject: Request for reviews (M): 7160161: Missed safepoint in non-Counted loop In-Reply-To: <503D63D1.6000302@oracle.com> References: <503D63D1.6000302@oracle.com> Message-ID: Looks good. -- Chris On Aug 28, 2012, at 5:35 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7160161/webrev > > 7160161: Missed safepoint in non-Counted loop > > Loop peeling optimization removes needed safepoints from peeled iteration of inner non-counted loop during OSR compilation. As result the path without safepoints is created in outer loop. > > Do not remove safepoints during peeling optimization. Improve the code in IdealLoopTree::counted_loop() to eliminate all others safepoints in a loop (but not in this loop's nested loops) which have a safepoint on dominating path. > > Tested with provided test case, CTW, jtreg Compiler. Did analysis of code generated for nested loops which are not counted. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Aug 29 12:11:46 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Aug 2012 12:11:46 -0700 Subject: Request for reviews (M): 7160161: Missed safepoint in non-Counted loop In-Reply-To: References: <503D63D1.6000302@oracle.com> Message-ID: <503E6972.3050909@oracle.com> Thank you, Christian Vladimir Christian Thalinger wrote: > Looks good. -- Chris > > On Aug 28, 2012, at 5:35 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7160161/webrev >> >> 7160161: Missed safepoint in non-Counted loop >> >> Loop peeling optimization removes needed safepoints from peeled iteration of inner non-counted loop during OSR compilation. As result the path without safepoints is created in outer loop. >> >> Do not remove safepoints during peeling optimization. Improve the code in IdealLoopTree::counted_loop() to eliminate all others safepoints in a loop (but not in this loop's nested loops) which have a safepoint on dominating path. >> >> Tested with provided test case, CTW, jtreg Compiler. Did analysis of code generated for nested loops which are not counted. >> >> Thanks, >> Vladimir > From kelly.ohair at oracle.com Wed Aug 29 10:22:16 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 29 Aug 2012 10:22:16 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> References: <503BE193.6090807@oracle.com> <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> Message-ID: <6C7642AF-853F-4EAD-B68A-50F5BE076448@oracle.com> Makefiles buried in the src tree have a good chance of being completely ignored by the new build-infra project. We need some very solid control over all Makefiles used in the build process. The only exceptions have been test, sample, and demo makefiles, which are not used in the jdk build process. So if these Makefiles are used in the normal hotspot build process, it would be much much better if they were moved into the make directory with the rest of the makefiles. -kto On Aug 28, 2012, at 2:12 AM, Staffan Larsen wrote: > Thanks for picking up Tom's work and completing it. Anything that removes 20k lines of code must be good :-) > > Is there a way we can write a jtreg test for this? Either by debugging a live JVM or a core file? Having a test would be very helpful, although it may be impossible because of the requirement to download and build binutils. Any other way we can add automatic testing for this? > > What platforms have you done manual testing on? > > I noticed that the makefile changes are missing from the bsd makefiles. > > Unrelated comment: we should remove the ia64 code from SA... > > Thanks, > /Staffan > > On 27 aug 2012, at 23:07, Yumin Qi wrote: > >> Hi, all >> >> Can I have you code review of >> 6879063: SA should use hsdis for disassembly >> >> http://cr.openjdk.java.net/~minqi/6879063 >> >> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >> >> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >> >> Tested by dumping full assembly from core files. >> >> Reviewed-by: >> Contributed-by: Tom R (never) >> >> Thanks >> Yumin Qi >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120829/8e7f7d6f/attachment.html From coleen.phillimore at oracle.com Wed Aug 29 13:57:50 2012 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 29 Aug 2012 20:57:50 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7191926: Remove MKS dependency in Hotspot regression tests Message-ID: <20120829205752.E21D6477C8@hg.openjdk.java.net> Changeset: 83b6305a5638 Author: coleenp Date: 2012-08-29 14:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/83b6305a5638 7191926: Remove MKS dependency in Hotspot regression tests Summary: Add case for CYGWIN in .sh files. Reviewed-by: coleenp, kvn Contributed-by: pavel.punegov at oracle.com ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/7020373/Test7020373.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh From vladimir.kozlov at oracle.com Wed Aug 29 16:17:07 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 29 Aug 2012 23:17:07 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7160161: Missed safepoint in non-Counted loop Message-ID: <20120829231712.7B6E9477DC@hg.openjdk.java.net> Changeset: 0acd345fd810 Author: kvn Date: 2012-08-29 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0acd345fd810 7160161: Missed safepoint in non-Counted loop Summary: Do not remove safepoints during peeling optimization. Reviewed-by: twisti ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp From staffan.larsen at oracle.com Thu Aug 30 00:34:58 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 30 Aug 2012 09:34:58 +0200 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <6C7642AF-853F-4EAD-B68A-50F5BE076448@oracle.com> References: <503BE193.6090807@oracle.com> <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> <6C7642AF-853F-4EAD-B68A-50F5BE076448@oracle.com> Message-ID: <8C6F70C2-3F50-48DB-9388-33AE8A8CD79B@oracle.com> My understanding is that the makefiles in the agent/make are not used by normal build. Normal builds use make//makefiles/sa.make. It's unclear to me why the files under agent/make exist at all (except for historical reasons). /Staffan On 29 aug 2012, at 19:22, Kelly O'Hair wrote: > Makefiles buried in the src tree have a good chance of being completely ignored by the new build-infra project. > > We need some very solid control over all Makefiles used in the build process. > The only exceptions have been test, sample, and demo makefiles, which are not used in the jdk build process. > > So if these Makefiles are used in the normal hotspot build process, it would be much much better if they > were moved into the make directory with the rest of the makefiles. > > -kto > > On Aug 28, 2012, at 2:12 AM, Staffan Larsen wrote: > >> Thanks for picking up Tom's work and completing it. Anything that removes 20k lines of code must be good :-) >> >> Is there a way we can write a jtreg test for this? Either by debugging a live JVM or a core file? Having a test would be very helpful, although it may be impossible because of the requirement to download and build binutils. Any other way we can add automatic testing for this? >> >> What platforms have you done manual testing on? >> >> I noticed that the makefile changes are missing from the bsd makefiles. >> >> Unrelated comment: we should remove the ia64 code from SA... >> >> Thanks, >> /Staffan >> >> On 27 aug 2012, at 23:07, Yumin Qi wrote: >> >>> Hi, all >>> >>> Can I have you code review of >>> 6879063: SA should use hsdis for disassembly >>> >>> http://cr.openjdk.java.net/~minqi/6879063 >>> >>> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >>> >>> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >>> >>> Tested by dumping full assembly from core files. >>> >>> Reviewed-by: >>> Contributed-by: Tom R (never) >>> >>> Thanks >>> Yumin Qi >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120830/e9dbfb0c/attachment.html From yumin.qi at oracle.com Thu Aug 30 09:02:49 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 30 Aug 2012 09:02:49 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <8C6F70C2-3F50-48DB-9388-33AE8A8CD79B@oracle.com> References: <503BE193.6090807@oracle.com> <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> <6C7642AF-853F-4EAD-B68A-50F5BE076448@oracle.com> <8C6F70C2-3F50-48DB-9388-33AE8A8CD79B@oracle.com> Message-ID: <503F8EA9.7080805@oracle.com> You are right, agent/make is historic make for engineers who only want build SA alone. Certainly they can do this by make -f sa.make from different platform locations. But that is only for building sa-jdi.jar, for build libsaproc, they have to build after whole hotspot built. In hotspot build the building order is sa-jdi.jar, libjvm, libsaproc. I think to build libsaproc, we can do make -f saproc.make But I never try that. Thanks Yumin On 2012/8/30 0:34, Staffan Larsen wrote: > My understanding is that the makefiles in the agent/make are not used > by normal build. Normal builds use make//makefiles/sa.make. > It's unclear to me why the files under agent/make exist at all (except > for historical reasons). > > /Staffan > > On 29 aug 2012, at 19:22, Kelly O'Hair > wrote: > >> Makefiles buried in the src tree have a good chance of being >> completely ignored by the new build-infra project. >> >> We need some very solid control over all Makefiles used in the build >> process. >> The only exceptions have been test, sample, and demo makefiles, which >> are not used in the jdk build process. >> >> So if these Makefiles are used in the normal hotspot build process, >> it would be much much better if they >> were moved into the make directory with the rest of the makefiles. >> >> -kto >> >> On Aug 28, 2012, at 2:12 AM, Staffan Larsen wrote: >> >>> Thanks for picking up Tom's work and completing it. Anything that >>> removes 20k lines of code must be good :-) >>> >>> Is there a way we can write a jtreg test for this? Either by >>> debugging a live JVM or a core file? Having a test would be very >>> helpful, although it may be impossible because of the requirement to >>> download and build binutils. Any other way we can add automatic >>> testing for this? >>> >>> What platforms have you done manual testing on? >>> >>> I noticed that the makefile changes are missing from the bsd makefiles. >>> >>> Unrelated comment: we should remove the ia64 code from SA... >>> >>> Thanks, >>> /Staffan >>> >>> On 27 aug 2012, at 23:07, Yumin Qi >> > wrote: >>> >>>> Hi, all >>>> >>>> Can I have you code review of >>>> 6879063: SA should use hsdis for disassembly >>>> >>>> http://cr.openjdk.java.net/~minqi/6879063 >>>> >>>> >>>> The SA has Java based disassemblers for x86 and sparc but amd64. >>>> Instead of porting to amd64 we should switch over to using hsdis >>>> for it like the JVM does. This requires a new entry point into >>>> hsdis, decode_instructions_virtual, which separates the address of >>>> the code being disassembled from the buffer containing the code. >>>> The existing uses of decode_instructions have been updated to use >>>> the new interface and SA Disassembler has Java native methods that >>>> call into hsdis and call back up to Java to perform the >>>> disassembly. Also changed makefile for hsdis build for >>>> both(i386/amd64). >>>> >>>> All the old disassembler logic was deleted since it's >>>> incompatible with the new disassembly interface. Also deleted are >>>> dbx based SA interface and few other dead files. >>>> >>>> Tested by dumping full assembly from core files. >>>> >>>> Reviewed-by: >>>> Contributed-by: Tom R (never) >>>> >>>> Thanks >>>> Yumin Qi >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120830/0b65cf62/attachment-0001.html From john.coomes at oracle.com Fri Aug 31 20:10:45 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 01 Sep 2012 03:10:45 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 17 new changesets Message-ID: <20120901031122.7115447850@hg.openjdk.java.net> Changeset: 3b77f0c58018 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3b77f0c58018 Added tag jdk8-b54 for changeset e8fb566b9466 ! .hgtags Changeset: be82ef218872 Author: sla Date: 2012-08-22 10:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be82ef218872 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X Reviewed-by: dholmes, dsamersoff, nloodin ! src/os/posix/launcher/launcher.script Changeset: b3602ff9c1b8 Author: dcubed Date: 2012-08-24 19:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b3602ff9c1b8 Merge Changeset: bb3f6194fedb Author: brutisso Date: 2012-08-23 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bb3f6194fedb 7178363: G1: Remove the serial code for PrintGCDetails and make it a special case of the parallel code Summary: Also reviewed by vitalyd at gmail.com. Introduced the WorkerDataArray class. Fixed some minor logging bugs. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/runtime/arguments.cpp Changeset: c9814fadeb38 Author: johnc Date: 2012-08-28 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c9814fadeb38 7041879: G1: introduce stress testing parameter to cause frequent evacuation failures Summary: Add the flags G1EvacuationFailureALot flag (and supporting flags) to force trigger evacuation failures. The support flags control how often to trigger an evacuation failure and during which types of evacuation pause. This functionality is analogous to that of PromotionFailureALot for the other collectors. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: fa9253dcd4df Author: johnc Date: 2012-08-29 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fa9253dcd4df 7194409: os::javaTimeNanos() shows hot on CPU_CLK_UNHALTED profiles Summary: Add inline directives to os::Linux::supports_monotonic_clock() and os::Bsd::supports_monotonic_clock(). Reviewed-by: johnc, azeemj, mikael Contributed-by: Brandon Mitchell ! src/os/bsd/vm/os_bsd.hpp ! src/os/linux/vm/os_linux.hpp Changeset: 220b59f8413f Author: brutisso Date: 2012-08-31 08:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/220b59f8413f Merge Changeset: 4d318b1e73ca Author: twisti Date: 2012-08-31 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4d318b1e73ca Merge Changeset: 0771839a29ab Author: jprovino Date: 2012-08-08 15:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0771839a29ab 7153374: ARM ONLY .. linking problem with new compilers.. Need to use -fPIC Summary: add "arm" to the list of processors that need -fPIC Reviewed-by: vladidan, dholmes ! make/pic.make Changeset: 892ec0920ccd Author: vladidan Date: 2012-08-08 16:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/892ec0920ccd Merge Changeset: e2cc1fe53845 Author: amurillo Date: 2012-08-17 16:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e2cc1fe53845 Merge Changeset: a9fed06c01d2 Author: bpittore Date: 2012-08-30 11:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a9fed06c01d2 7154641: Servicability agent should work on platforms other than x86, sparc Summary: Added capability to load support classes for other cpus Reviewed-by: coleenp, bobv, sla Contributed-by: Bill Pittore ! agent/make/saenv.sh ! agent/make/start-debug-server-proc.sh ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/libproc.h ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/amd64/AMD64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/ia64/IA64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/sparc/SPARCThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/x86/X86ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java + agent/src/share/classes/sun/jvm/hotspot/utilities/AltPlatformInfo.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/defs.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! src/share/vm/runtime/vmStructs.cpp Changeset: 6dcb17434873 Author: jiangli Date: 2012-08-31 14:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6dcb17434873 Merge Changeset: 1eb74cd5994b Author: jiangli Date: 2012-08-31 12:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1eb74cd5994b Merge Changeset: 09ea7e0752b3 Author: jcoomes Date: 2012-08-31 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/09ea7e0752b3 Merge Changeset: af0c8a080851 Author: jcoomes Date: 2012-08-31 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/af0c8a080851 Added tag hs24-b22 for changeset 09ea7e0752b3 ! .hgtags Changeset: 36d1d483d5d6 Author: jcoomes Date: 2012-08-31 16:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/36d1d483d5d6 7195615: new hotspot build - hs25-b01 Reviewed-by: johnc ! make/hotspot_version