From Christian.Thalinger at Sun.COM Sun Aug 2 01:30:05 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sun, 02 Aug 2009 10:30:05 +0200 Subject: for review (L): 6858164: invokedynamic code needs some cleanup (post-6655638) In-Reply-To: <4A736584.8000307@sun.com> References: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> <4A736584.8000307@sun.com> Message-ID: <4A754E8D.9040302@Sun.COM> Vladimir Kozlov wrote: > Looks good. > > I am only concern about the changes "char*" to "const char*" > which could affect builds on linux. The change is actually for Linux GCC builds: http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-July/000833.html -- Christian From Vladimir.Kozlov at Sun.COM Mon Aug 3 10:35:48 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 03 Aug 2009 10:35:48 -0700 Subject: for review (L): 6858164: invokedynamic code needs some cleanup (post-6655638) In-Reply-To: <4A754E8D.9040302@Sun.COM> References: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> <4A736584.8000307@sun.com> <4A754E8D.9040302@Sun.COM> Message-ID: <4A771FF4.4040002@sun.com> OK. Vladimir Christian Thalinger wrote: > Vladimir Kozlov wrote: >> Looks good. >> >> I am only concern about the changes "char*" to "const char*" >> which could affect builds on linux. > > The change is actually for Linux GCC builds: > > http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-July/000833.html > > -- Christian From Changpeng.Fang at Sun.COM Tue Aug 4 09:00:26 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Tue, 04 Aug 2009 09:00:26 -0700 Subject: Request for reviews (XXS): 6868269 CompileTheWorld assertion failure introduced by the reexecute bit implementation In-Reply-To: <4A67796B.5050604@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> Message-ID: <4A785B1A.9010400@sun.com> http://cr.openjdk.java.net/~cfang/6868269/webrev.00/ Problem: For inline_native_clone, there are two exceptions with different reexecute states. This caused the assertion on JVMState::same_calls_as Solution: JVMState::same_calls_as was designed to verify the same method/bci pairs. The current implementation of reexecute logic does not require the same method/bci to have a single reexecute state, i.e. the implementer could change the reexecute state during the parsing of a bci. So the solution is simply remove the following line in JVMState::same_calls_as: - if (p->_reexecute != q->_reexecute) return false; Tests: JPRT, CompileTheWorld! Thanks, Changpeng From Vladimir.Kozlov at Sun.COM Tue Aug 4 09:55:03 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 04 Aug 2009 09:55:03 -0700 Subject: Request for reviews (XXS): 6868269 CompileTheWorld assertion failure introduced by the reexecute bit implementation In-Reply-To: <4A785B1A.9010400@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A785B1A.9010400@sun.com> Message-ID: <4A7867E7.4070307@sun.com> Good. Vladimir changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6868269/webrev.00/ > > Problem: For inline_native_clone, there are two exceptions with > different reexecute states. > This caused the assertion on JVMState::same_calls_as > > Solution: JVMState::same_calls_as was designed to verify the same > method/bci pairs. The current > implementation of reexecute logic does not require the same method/bci > to have a single reexecute > state, i.e. the implementer could change the reexecute state during the > parsing of a bci. > > So the solution is simply remove the following line in > JVMState::same_calls_as: > > - if (p->_reexecute != q->_reexecute) return false; > > > > Tests: JPRT, CompileTheWorld! > > > > Thanks, > > > Changpeng > From Thomas.Rodriguez at Sun.COM Tue Aug 4 10:14:56 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 04 Aug 2009 10:14:56 -0700 Subject: Request for reviews (XXS): 6868269 CompileTheWorld assertion failure introduced by the reexecute bit implementation In-Reply-To: <4A785B1A.9010400@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A785B1A.9010400@sun.com> Message-ID: <429DD743-6951-4351-BBA8-D59749899DAC@sun.com> Looks good. tom On Aug 4, 2009, at 9:00 AM, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6868269/webrev.00/ > > Problem: For inline_native_clone, there are two exceptions with > different reexecute states. > This caused the assertion on JVMState::same_calls_as > > Solution: JVMState::same_calls_as was designed to verify the same > method/bci pairs. The current > implementation of reexecute logic does not require the same method/ > bci to have a single reexecute > state, i.e. the implementer could change the reexecute state during > the parsing of a bci. > > So the solution is simply remove the following line in > JVMState::same_calls_as: > > - if (p->_reexecute != q->_reexecute) return false; > > > > Tests: JPRT, CompileTheWorld! > > > > Thanks, > > > Changpeng > From Vladimir.Kozlov at Sun.COM Tue Aug 4 10:17:55 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 04 Aug 2009 10:17:55 -0700 Subject: Request for reviews (XXS): 6868269 CompileTheWorld assertion failure introduced by the reexecute bit implementation In-Reply-To: <4A7867E7.4070307@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A785B1A.9010400@sun.com> <4A7867E7.4070307@sun.com> Message-ID: <4A786D43.3000205@sun.com> So after discussion with Changpeng I now understand what happened. The path which don't have reexecute state is uncommon trap in null_check_receiver() at the beginning of inline_native_clone() because it is not in the PreserveReexecuteState scope. So the other solution of this bug is including null_check_receiver() into the PreserveReexecuteState scope. Vladimir Vladimir Kozlov wrote: > Good. > > Vladimir > > changpeng fang - Sun Microsystems - Santa Clara United States wrote: >> http://cr.openjdk.java.net/~cfang/6868269/webrev.00/ >> >> Problem: For inline_native_clone, there are two exceptions with >> different reexecute states. >> This caused the assertion on JVMState::same_calls_as >> >> Solution: JVMState::same_calls_as was designed to verify the same >> method/bci pairs. The current >> implementation of reexecute logic does not require the same method/bci >> to have a single reexecute >> state, i.e. the implementer could change the reexecute state during >> the parsing of a bci. >> >> So the solution is simply remove the following line in >> JVMState::same_calls_as: >> >> - if (p->_reexecute != q->_reexecute) return false; >> >> >> >> Tests: JPRT, CompileTheWorld! >> >> >> >> Thanks, >> >> >> Changpeng >> From Thomas.Rodriguez at Sun.COM Tue Aug 4 10:56:15 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 04 Aug 2009 10:56:15 -0700 Subject: Request for reviews (XXS): 6868269 CompileTheWorld assertion failure introduced by the reexecute bit implementation In-Reply-To: <4A786D43.3000205@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A785B1A.9010400@sun.com> <4A7867E7.4070307@sun.com> <4A786D43.3000205@sun.com> Message-ID: <160646C6-BF9F-4B97-8CF8-5EADC6EBDA64@sun.com> That seems cleaner to me. tom On Aug 4, 2009, at 10:17 AM, Vladimir Kozlov wrote: > So after discussion with Changpeng I now understand what happened. > The path which don't have reexecute state is uncommon trap > in null_check_receiver() at the beginning of inline_native_clone() > because it is not in the PreserveReexecuteState scope. > So the other solution of this bug is including null_check_receiver() > into the PreserveReexecuteState scope. > > Vladimir > > Vladimir Kozlov wrote: >> Good. >> Vladimir >> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>> http://cr.openjdk.java.net/~cfang/6868269/webrev.00/ >>> >>> Problem: For inline_native_clone, there are two exceptions with >>> different reexecute states. >>> This caused the assertion on JVMState::same_calls_as >>> >>> Solution: JVMState::same_calls_as was designed to verify the same >>> method/bci pairs. The current >>> implementation of reexecute logic does not require the same method/ >>> bci to have a single reexecute >>> state, i.e. the implementer could change the reexecute state >>> during the parsing of a bci. >>> >>> So the solution is simply remove the following line in >>> JVMState::same_calls_as: >>> >>> - if (p->_reexecute != q->_reexecute) return false; >>> >>> >>> >>> Tests: JPRT, CompileTheWorld! >>> >>> >>> >>> Thanks, >>> >>> >>> Changpeng >>> From Vladimir.Kozlov at Sun.COM Tue Aug 4 16:03:20 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 04 Aug 2009 16:03:20 -0700 Subject: Request for reviews (XS): 6868486: timouts and outOfMemory in regression tests Message-ID: <4A78BE38.80504@sun.com> http://cr.openjdk.java.net/~kvn/6868486/webrev.00 Fixed 6868486: timouts and outOfMemory in regression tests Problem: Nightly testing uses some very old machines which are slow, have one cpu(core) and <= 1Gb memory. Such machines are not server class for VM so it use Serial GC which also slowdown execution time. Solution: Increase timeout for all bug's tests. Increase heap size for 6851282 test. Reviewed by: Fix verified (y/n): y, bug's tests Other testing: JPRT From John.Rose at Sun.COM Tue Aug 4 16:07:43 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 04 Aug 2009 16:07:43 -0700 Subject: review (XS) for 6868487: EnableInvokeDynamic and EnableMethodHandles should not be visible flags in JDK6 or JDK7 Message-ID: http://cr.openjdk.java.net/~jrose/6868487/webrev.00 6868487: EnableInvokeDynamic and EnableMethodHandles should not be visible flags in JDK6 or JDK7 Summary: switch them from product to experimental; 6817525 will toggle them and switch to diagnostic This tweaks the categorization for JSR 292 flags, so that they will not be public in JDK6. They won't be public in JDK7 either, though for the opposite reason: They will be on by default (that change is bug 6817525). -- John From Vladimir.Kozlov at Sun.COM Tue Aug 4 16:05:47 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 04 Aug 2009 16:05:47 -0700 Subject: review (XS) for 6868487: EnableInvokeDynamic and EnableMethodHandles should not be visible flags in JDK6 or JDK7 In-Reply-To: References: Message-ID: <4A78BECB.2070408@sun.com> Good. Vladimir John Rose wrote: > http://cr.openjdk.java.net/~jrose/6868487/webrev.00 > > 6868487: EnableInvokeDynamic and EnableMethodHandles should not be > visible flags in JDK6 or JDK7 > Summary: switch them from product to experimental; 6817525 will toggle > them and switch to diagnostic > > This tweaks the categorization for JSR 292 flags, so that they will not > be public in JDK6. They won't be public in JDK7 either, though for the > opposite reason: They will be on by default (that change is bug 6817525). > > -- John From Changpeng.Fang at Sun.COM Tue Aug 4 16:18:50 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Tue, 04 Aug 2009 16:18:50 -0700 Subject: Request for reviews (XS): 6868486: timouts and outOfMemory in regression tests In-Reply-To: <4A78BE38.80504@sun.com> References: <4A78BE38.80504@sun.com> Message-ID: <4A78C1DA.6050805@sun.com> On 08/04/09 16:03, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6868486/webrev.00 > Looks good! I guess the timeouts you specified are long enough for those tests to finish under normal cases. Changpeng > Fixed 6868486: timouts and outOfMemory in regression tests > > Problem: > Nightly testing uses some very old machines which are slow, > have one cpu(core) and <= 1Gb memory. > Such machines are not server class for VM so it use > Serial GC which also slowdown execution time. > > Solution: > Increase timeout for all bug's tests. > Increase heap size for 6851282 test. > > Reviewed by: > > Fix verified (y/n): y, bug's tests > > Other testing: > JPRT > From Thomas.Rodriguez at Sun.COM Tue Aug 4 16:19:32 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 04 Aug 2009 16:19:32 -0700 Subject: Request for reviews (XS): 6868486: timouts and outOfMemory in regression tests In-Reply-To: <4A78BE38.80504@sun.com> References: <4A78BE38.80504@sun.com> Message-ID: <412F9805-1F36-4A2A-A4AC-EE57899B67EA@sun.com> 10 - 15 minute runtimes are pretty long for tests that we're running as part of nightlies. Is it possible to make the tests run in less time? Ideally regression tests shouldn't take more than a minute or two. tom On Aug 4, 2009, at 4:03 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6868486/webrev.00 > > Fixed 6868486: timouts and outOfMemory in regression tests > > Problem: > Nightly testing uses some very old machines which are slow, > have one cpu(core) and <= 1Gb memory. > Such machines are not server class for VM so it use > Serial GC which also slowdown execution time. > > Solution: > Increase timeout for all bug's tests. > Increase heap size for 6851282 test. > > Reviewed by: > > Fix verified (y/n): y, bug's tests > > Other testing: > JPRT > From Changpeng.Fang at Sun.COM Tue Aug 4 16:28:31 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Tue, 04 Aug 2009 16:28:31 -0700 Subject: Request for reviews (XXS): 6868269 CompileTheWorld assertion failure introduced by the reexecute bit implementation In-Reply-To: <160646C6-BF9F-4B97-8CF8-5EADC6EBDA64@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A785B1A.9010400@sun.com> <4A7867E7.4070307@sun.com> <4A786D43.3000205@sun.com> <160646C6-BF9F-4B97-8CF8-5EADC6EBDA64@sun.com> Message-ID: <4A78C41F.6010701@sun.com> http://cr.openjdk.java.net/~cfang/6868269/webrev.00/ Done! I modified the implementation of reexecute bit for Object.clone and Arrays.copyOf intrinsics, and kept the assertion in JVMState::same_calls_as. This means we should expect only one reexecute state for a particular bci. Thanks, Changpeng On 08/04/09 10:56, Tom Rodriguez wrote: > That seems cleaner to me. > > tom > > On Aug 4, 2009, at 10:17 AM, Vladimir Kozlov wrote: > >> So after discussion with Changpeng I now understand what happened. >> The path which don't have reexecute state is uncommon trap >> in null_check_receiver() at the beginning of inline_native_clone() >> because it is not in the PreserveReexecuteState scope. >> So the other solution of this bug is including null_check_receiver() >> into the PreserveReexecuteState scope. >> >> Vladimir >> >> Vladimir Kozlov wrote: >>> Good. >>> Vladimir >>> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>>> http://cr.openjdk.java.net/~cfang/6868269/webrev.00/ >>>> >>>> Problem: For inline_native_clone, there are two exceptions with >>>> different reexecute states. >>>> This caused the assertion on JVMState::same_calls_as >>>> >>>> Solution: JVMState::same_calls_as was designed to verify the same >>>> method/bci pairs. The current >>>> implementation of reexecute logic does not require the same >>>> method/bci to have a single reexecute >>>> state, i.e. the implementer could change the reexecute state during >>>> the parsing of a bci. >>>> >>>> So the solution is simply remove the following line in >>>> JVMState::same_calls_as: >>>> >>>> - if (p->_reexecute != q->_reexecute) return false; >>>> >>>> >>>> >>>> Tests: JPRT, CompileTheWorld! >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Changpeng >>>> > From Changpeng.Fang at Sun.COM Tue Aug 4 16:31:09 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Tue, 04 Aug 2009 16:31:09 -0700 Subject: Request for reviews (XXS): 6868269 CompileTheWorld assertion failure introduced by the reexecute bit implementation In-Reply-To: <4A78C41F.6010701@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A785B1A.9010400@sun.com> <4A7867E7.4070307@sun.com> <4A786D43.3000205@sun.com> <160646C6-BF9F-4B97-8CF8-5EADC6EBDA64@sun.com> <4A78C41F.6010701@sun.com> Message-ID: <4A78C4BD.5040109@sun.com> Sorry, the updated webrev is http://cr.openjdk.java.net/~cfang/6868269/webrev.01/ Changpeng On 08/04/09 16:28, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6868269/webrev.00/ > > Done! I modified the implementation of reexecute bit for Object.clone > and Arrays.copyOf intrinsics, > and kept the assertion in JVMState::same_calls_as. This means we > should expect only one reexecute > state for a particular bci. > > Thanks, > > Changpeng > > > On 08/04/09 10:56, Tom Rodriguez wrote: >> That seems cleaner to me. >> >> tom >> >> On Aug 4, 2009, at 10:17 AM, Vladimir Kozlov wrote: >> >>> So after discussion with Changpeng I now understand what happened. >>> The path which don't have reexecute state is uncommon trap >>> in null_check_receiver() at the beginning of inline_native_clone() >>> because it is not in the PreserveReexecuteState scope. >>> So the other solution of this bug is including null_check_receiver() >>> into the PreserveReexecuteState scope. >>> >>> Vladimir >>> >>> Vladimir Kozlov wrote: >>>> Good. >>>> Vladimir >>>> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>>>> http://cr.openjdk.java.net/~cfang/6868269/webrev.00/ >>>>> >>>>> Problem: For inline_native_clone, there are two exceptions with >>>>> different reexecute states. >>>>> This caused the assertion on JVMState::same_calls_as >>>>> >>>>> Solution: JVMState::same_calls_as was designed to verify the same >>>>> method/bci pairs. The current >>>>> implementation of reexecute logic does not require the same >>>>> method/bci to have a single reexecute >>>>> state, i.e. the implementer could change the reexecute state >>>>> during the parsing of a bci. >>>>> >>>>> So the solution is simply remove the following line in >>>>> JVMState::same_calls_as: >>>>> >>>>> - if (p->_reexecute != q->_reexecute) return false; >>>>> >>>>> >>>>> >>>>> Tests: JPRT, CompileTheWorld! >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> Changpeng >>>>> >> > From Thomas.Rodriguez at Sun.COM Tue Aug 4 16:34:03 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 04 Aug 2009 16:34:03 -0700 Subject: Request for reviews (XXS): 6868269 CompileTheWorld assertion failure introduced by the reexecute bit implementation In-Reply-To: <4A78C4BD.5040109@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A785B1A.9010400@sun.com> <4A7867E7.4070307@sun.com> <4A786D43.3000205@sun.com> <160646C6-BF9F-4B97-8CF8-5EADC6EBDA64@sun.com> <4A78C41F.6010701@sun.com> <4A78C4BD.5040109@sun.com> Message-ID: looks good. tom On Aug 4, 2009, at 4:31 PM, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > Sorry, the updated webrev is http://cr.openjdk.java.net/~cfang/6868269/webrev.01/ > > Changpeng > > On 08/04/09 16:28, changpeng fang - Sun Microsystems - Santa Clara > United States wrote: >> http://cr.openjdk.java.net/~cfang/6868269/webrev.00/ >> >> Done! I modified the implementation of reexecute bit for >> Object.clone and Arrays.copyOf intrinsics, >> and kept the assertion in JVMState::same_calls_as. This means we >> should expect only one reexecute >> state for a particular bci. >> >> Thanks, >> >> Changpeng >> >> >> On 08/04/09 10:56, Tom Rodriguez wrote: >>> That seems cleaner to me. >>> >>> tom >>> >>> On Aug 4, 2009, at 10:17 AM, Vladimir Kozlov wrote: >>> >>>> So after discussion with Changpeng I now understand what happened. >>>> The path which don't have reexecute state is uncommon trap >>>> in null_check_receiver() at the beginning of inline_native_clone() >>>> because it is not in the PreserveReexecuteState scope. >>>> So the other solution of this bug is including >>>> null_check_receiver() >>>> into the PreserveReexecuteState scope. >>>> >>>> Vladimir >>>> >>>> Vladimir Kozlov wrote: >>>>> Good. >>>>> Vladimir >>>>> changpeng fang - Sun Microsystems - Santa Clara United States >>>>> wrote: >>>>>> http://cr.openjdk.java.net/~cfang/6868269/webrev.00/ >>>>>> >>>>>> Problem: For inline_native_clone, there are two exceptions with >>>>>> different reexecute states. >>>>>> This caused the assertion on JVMState::same_calls_as >>>>>> >>>>>> Solution: JVMState::same_calls_as was designed to verify the >>>>>> same method/bci pairs. The current >>>>>> implementation of reexecute logic does not require the same >>>>>> method/bci to have a single reexecute >>>>>> state, i.e. the implementer could change the reexecute state >>>>>> during the parsing of a bci. >>>>>> >>>>>> So the solution is simply remove the following line in >>>>>> JVMState::same_calls_as: >>>>>> >>>>>> - if (p->_reexecute != q->_reexecute) return false; >>>>>> >>>>>> >>>>>> >>>>>> Tests: JPRT, CompileTheWorld! >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> Changpeng >>>>>> >>> >> > From Vladimir.Kozlov at Sun.COM Tue Aug 4 16:34:20 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 04 Aug 2009 16:34:20 -0700 Subject: Request for reviews (XS): 6868486: timouts and outOfMemory in regression tests In-Reply-To: <412F9805-1F36-4A2A-A4AC-EE57899B67EA@sun.com> References: <4A78BE38.80504@sun.com> <412F9805-1F36-4A2A-A4AC-EE57899B67EA@sun.com> Message-ID: <4A78C57C.5020702@sun.com> % time bin/java -server -Xcomp -XX:-PrintVMOptions -XX:CompileThreshold=100 Test6559877 Checking all 1-byte combinations... Checking all 2-byte combinations... ................................................................ PASS 856.0u 3.0s 14:37 97% 0+0k 0+0io 0pf+0w It does class verification for bytecodes combinations (256x256 matrix) and it requires a new instance for each iteration. I don't see how we can improve it. I already using 100 as iteration count and CompileThreshold in 6826736 test. Note, it is 296 MHz US-II box. On new machines it takes about 1 min. Other tests take less then 1 min on new machines. Vladimir Tom Rodriguez wrote: > 10 - 15 minute runtimes are pretty long for tests that we're running as > part of nightlies. Is it possible to make the tests run in less time? > Ideally regression tests shouldn't take more than a minute or two. > > tom > > On Aug 4, 2009, at 4:03 PM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6868486/webrev.00 >> >> Fixed 6868486: timouts and outOfMemory in regression tests >> >> Problem: >> Nightly testing uses some very old machines which are slow, >> have one cpu(core) and <= 1Gb memory. >> Such machines are not server class for VM so it use >> Serial GC which also slowdown execution time. >> >> Solution: >> Increase timeout for all bug's tests. >> Increase heap size for 6851282 test. >> >> Reviewed by: >> >> Fix verified (y/n): y, bug's tests >> >> Other testing: >> JPRT >> > From Thomas.Rodriguez at Sun.COM Tue Aug 4 16:49:51 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 04 Aug 2009 16:49:51 -0700 Subject: Request for reviews (XS): 6868486: timouts and outOfMemory in regression tests In-Reply-To: <4A78C57C.5020702@sun.com> References: <4A78BE38.80504@sun.com> <412F9805-1F36-4A2A-A4AC-EE57899B67EA@sun.com> <4A78C57C.5020702@sun.com> Message-ID: <05D2E63B-CAF5-4C01-B8FE-001D1242AD1D@Sun.COM> Ok. I was just concerned that those were expected run times. I'm ok with the change. I don't see any way to improve Test6559877.java other than using multiple threads but I'm not sure it's worth it. tom On Aug 4, 2009, at 4:34 PM, Vladimir Kozlov wrote: > % time bin/java -server -Xcomp -XX:-PrintVMOptions - > XX:CompileThreshold=100 Test6559877 > Checking all 1-byte combinations... > Checking all 2-byte combinations... > ................................................................ > PASS > 856.0u 3.0s 14:37 97% 0+0k 0+0io 0pf+0w > > It does class verification for bytecodes combinations (256x256 matrix) > and it requires a new instance for each iteration. I don't see how > we can > improve it. > > I already using 100 as iteration count and CompileThreshold in > 6826736 test. > > Note, it is 296 MHz US-II box. On new machines it takes about 1 min. > Other tests take less then 1 min on new machines. > > Vladimir > > Tom Rodriguez wrote: >> 10 - 15 minute runtimes are pretty long for tests that we're >> running as part of nightlies. Is it possible to make the tests run >> in less time? Ideally regression tests shouldn't take more than a >> minute or two. >> tom >> On Aug 4, 2009, at 4:03 PM, Vladimir Kozlov wrote: >>> >>> http://cr.openjdk.java.net/~kvn/6868486/webrev.00 >>> >>> Fixed 6868486: timouts and outOfMemory in regression tests >>> >>> Problem: >>> Nightly testing uses some very old machines which are slow, >>> have one cpu(core) and <= 1Gb memory. >>> Such machines are not server class for VM so it use >>> Serial GC which also slowdown execution time. >>> >>> Solution: >>> Increase timeout for all bug's tests. >>> Increase heap size for 6851282 test. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, bug's tests >>> >>> Other testing: >>> JPRT >>> From Vladimir.Kozlov at Sun.COM Tue Aug 4 17:01:14 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 04 Aug 2009 17:01:14 -0700 Subject: Request for reviews (XS): 6868486: timouts and outOfMemory in regression tests In-Reply-To: <05D2E63B-CAF5-4C01-B8FE-001D1242AD1D@Sun.COM> References: <4A78BE38.80504@sun.com> <412F9805-1F36-4A2A-A4AC-EE57899B67EA@sun.com> <4A78C57C.5020702@sun.com> <05D2E63B-CAF5-4C01-B8FE-001D1242AD1D@Sun.COM> Message-ID: <4A78CBCA.4040900@sun.com> Thanks, Tom Vladimir Tom Rodriguez wrote: > Ok. I was just concerned that those were expected run times. I'm ok > with the change. I don't see any way to improve Test6559877.java other > than using multiple threads but I'm not sure it's worth it. > > tom > > On Aug 4, 2009, at 4:34 PM, Vladimir Kozlov wrote: > >> % time bin/java -server -Xcomp -XX:-PrintVMOptions >> -XX:CompileThreshold=100 Test6559877 >> Checking all 1-byte combinations... >> Checking all 2-byte combinations... >> ................................................................ >> PASS >> 856.0u 3.0s 14:37 97% 0+0k 0+0io 0pf+0w >> >> It does class verification for bytecodes combinations (256x256 matrix) >> and it requires a new instance for each iteration. I don't see how we can >> improve it. >> >> I already using 100 as iteration count and CompileThreshold in 6826736 >> test. >> >> Note, it is 296 MHz US-II box. On new machines it takes about 1 min. >> Other tests take less then 1 min on new machines. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> 10 - 15 minute runtimes are pretty long for tests that we're running >>> as part of nightlies. Is it possible to make the tests run in less >>> time? Ideally regression tests shouldn't take more than a minute or >>> two. >>> tom >>> On Aug 4, 2009, at 4:03 PM, Vladimir Kozlov wrote: >>>> >>>> http://cr.openjdk.java.net/~kvn/6868486/webrev.00 >>>> >>>> Fixed 6868486: timouts and outOfMemory in regression tests >>>> >>>> Problem: >>>> Nightly testing uses some very old machines which are slow, >>>> have one cpu(core) and <= 1Gb memory. >>>> Such machines are not server class for VM so it use >>>> Serial GC which also slowdown execution time. >>>> >>>> Solution: >>>> Increase timeout for all bug's tests. >>>> Increase heap size for 6851282 test. >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y, bug's tests >>>> >>>> Other testing: >>>> JPRT >>>> > From vladimir.kozlov at sun.com Tue Aug 4 21:16:28 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 05 Aug 2009 04:16:28 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6868486: timouts and outOfMemory in regression tests Message-ID: <20090805041636.2F838E13E@hg.openjdk.java.net> Changeset: 2b9164d13ce9 Author: kvn Date: 2009-08-04 17:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2b9164d13ce9 6868486: timouts and outOfMemory in regression tests Summary: Increase timeout for tests and heap size for 6851282 test. Reviewed-by: never, cfang ! test/compiler/6826736/Test.java ! test/compiler/6851282/Test.java From changpeng.fang at sun.com Wed Aug 5 03:24:45 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Wed, 05 Aug 2009 10:24:45 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6868269: CompileTheWorld assertion failure introduced by the reexecute bit implementation Message-ID: <20090805102456.261D2E154@hg.openjdk.java.net> Changeset: fc2281ddce3c Author: cfang Date: 2009-08-04 21:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fc2281ddce3c 6868269: CompileTheWorld assertion failure introduced by the reexecute bit implementation Summary: Improvement on reexecute implementation to fix the assertion failure Reviewed-by: kvn, never ! src/share/vm/opto/library_call.cpp From John.Rose at Sun.COM Wed Aug 5 16:53:16 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 05 Aug 2009 16:53:16 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: <4A73229F.9090903@sun.com> References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> <4A6D8B3D.6060704@Sun.COM> <4A73229F.9090903@sun.com> Message-ID: <94936B17-12A8-4C14-AF17-448A9AB33A2F@Sun.COM> On Jul 31, 2009, at 9:58 AM, Vladimir Kozlov wrote: > Could you rename non_perm_state_clean() to non_perm_not_marked() > or something otherwise the next code looks strange since > the non_perm_state is also used to flag "on list" state: > > + debug_only(cur->clear_non_perm_marked()); > + assert(cur->non_perm_state_clean(), ""); > + assert(cur->on_non_perm_list(), "else shouldn't be on this > list"); Done. Added a brief comment explaining the "not_" variation. + // N.B. there is no positive marked query, and we only use the not_marked query for asserts. > In nmethod.hpp could you move enum above its usage and use it in > on_non_perm_list()? Thanks; done. > Can you change the comment in parse3.cpp to next?: > > // cases: > // should_be_constant = (oop == null || oop in perm space || > NonPermCodeRefs >= 2) > // has_encoding = (should_be_constant || NonPermCodeRefs > == 1) > // Yes, done. (Except that I prefer NonPermCodeRefs >= 1 for the second equation.) > In globals.hpp it would be better to have "1: allow" on a separate > line. Fixed. Thanks! -- John From Y.S.Ramakrishna at Sun.COM Wed Aug 5 16:57:53 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Wed, 05 Aug 2009 16:57:53 -0700 Subject: request for review (m): 4957990: Perm heap bloat in JVM In-Reply-To: <4A7A17FB.20606@Sun.COM> References: <4A789E4C.20109@Sun.COM> <4A78A5DB.3040901@Sun.COM> <4A78E69C.4030604@sun.com> <4A78EDE3.1090703@sun.com> <4A7920B1.7010301@sun.com> <0AA576C1-BA1B-40EF-8ABA-B088C47E3D7B@sun.com> <4A79DBCF.6060506@Sun.COM> <4A79FF45.8060101@sun.com> <4A7A0D33.8030700@Sun.COM> <4A7A1232.7080802@Sun.COM> <287E57C2-5D3D-45C7-87C0-BBB1F5F6212D@Sun.COM> <4A7A17FB.20606@Sun.COM> Message-ID: <4A7A1C81.3020508@Sun.COM> Can there be a situation where an osr nmethod associated with a method oop gets unloaded while the method and its class are still alive? I see that happening with my workspace with the changes for 4957990 (yet to figure out why the osr nmethod was unloaded). Shortly after said unload, the sweeper flushes the nmethod, but the nmethod is still left linked off of the klass's _osr_nmethod_head list, and a subsequent invocation counter overflow at a bci does an osr nmethod lookup and falls foul of the flushed nmethod left in the instanceKlass's osr nmethod head. So I have two questions: (a) can an osr nmethod be unloaded while its klass is still alive ? (b) if the answer to (a) is yes, then we need to take special steps (not present in current code) to unlink said nmethod from the list of osr nmethods in its klass. Am I making sense? Otherwise i can provide more direct detail. (I am still digging to find out why we decided to unload the nmethod and will have more follow-up info in a subsequent email.) thanks. -- ramki From Thomas.Rodriguez at Sun.COM Wed Aug 5 18:15:09 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 05 Aug 2009 18:15:09 -0700 Subject: request for review (m): 4957990: Perm heap bloat in JVM In-Reply-To: <4A7A1C81.3020508@Sun.COM> References: <4A789E4C.20109@Sun.COM> <4A78A5DB.3040901@Sun.COM> <4A78E69C.4030604@sun.com> <4A78EDE3.1090703@sun.com> <4A7920B1.7010301@sun.com> <0AA576C1-BA1B-40EF-8ABA-B088C47E3D7B@sun.com> <4A79DBCF.6060506@Sun.COM> <4A79FF45.8060101@sun.com> <4A7A0D33.8030700@Sun.COM> <4A7A1232.7080802@Sun.COM> <287E57C2-5D3D-45C7-87C0-BBB1F5F6212D@Sun.COM> <4A7A17FB.20606@Sun.COM> <4A7A1C81.3020508@Sun.COM> Message-ID: My understanding was that OSR nmethods could/should only be reclaimed once the klass of their holder was unloaded. The reason for this is that the normal not_entrant sweeping logic isn't implemented safely for OSR methods so the sweeper can't safely reclaim them. If the klass itself is being reclaimed then it should be safe to reclaim the OSR nmethods. It's possible that we have a hole in the logic which doesn't account for dealing with unloaded OSR methods properly and you changes just make it more likely to happen. We either need to close the not_entrant hole for OSR nmethods, which isn't that hard, and then correct nmethod::make_unloaded to unlink the OSR nmethod or we have to make do_unloading disallow unloading for OSR nmethods is the methodOop is strongly reachable. tom On Aug 5, 2009, at 4:57 PM, Y.S.Ramakrishna at Sun.COM wrote: > > Can there be a situation where an osr nmethod associated > with a method oop gets unloaded while the method and its > class are still alive? I see that happening with my workspace > with the changes for 4957990 (yet to figure out why the osr > nmethod was unloaded). > > Shortly after said unload, the sweeper flushes the nmethod, > but the nmethod is still left linked off of the klass's > _osr_nmethod_head > list, and a subsequent invocation counter overflow at a bci does > an osr nmethod lookup and falls foul of the flushed nmethod left > in the instanceKlass's osr nmethod head. > > So I have two questions: > > (a) can an osr nmethod be unloaded while its klass is still alive ? > (b) if the answer to (a) is yes, then we need to take special steps > (not present in current code) to unlink said nmethod from the > list of osr nmethods in its klass. > > Am I making sense? Otherwise i can provide more direct detail. > (I am still digging to find out why we decided to unload the > nmethod and will have more follow-up info in a subsequent email.) > > thanks. > -- ramki From Y.S.Ramakrishna at Sun.COM Wed Aug 5 19:40:34 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Wed, 05 Aug 2009 19:40:34 -0700 Subject: request for review (m): 4957990: Perm heap bloat in JVM In-Reply-To: References: <4A789E4C.20109@Sun.COM> <4A78A5DB.3040901@Sun.COM> <4A78E69C.4030604@sun.com> <4A78EDE3.1090703@sun.com> <4A7920B1.7010301@sun.com> <0AA576C1-BA1B-40EF-8ABA-B088C47E3D7B@sun.com> <4A79DBCF.6060506@Sun.COM> <4A79FF45.8060101@sun.com> <4A7A0D33.8030700@Sun.COM> <4A7A1232.7080802@Sun.COM> <287E57C2-5D3D-45C7-87C0-BBB1F5F6212D@Sun.COM> <4A7A17FB.20606@Sun.COM> <4A7A1C81.3020508@Sun.COM> Message-ID: <4A7A42A2.70603@Sun.COM> Hi Tom -- Thanks for the explanation. I looked at the code some more (since the problem is difficult to reproduce at will). On 08/05/09 18:15, Tom Rodriguez wrote: > My understanding was that OSR nmethods could/should only be reclaimed > once the klass of their holder was unloaded. The reason for this is > that the normal not_entrant sweeping logic isn't implemented safely for > OSR methods so the sweeper can't safely reclaim them. If the klass > itself is being reclaimed then it should be safe to reclaim the OSR > nmethods. It's possible that we have a hole in the logic which doesn't > account for dealing with unloaded OSR methods properly and you changes > just make it more likely to happen. We either need to close the > not_entrant hole for OSR nmethods, which isn't that hard, and then > correct nmethod::make_unloaded to unlink the OSR nmethod or we have to > make do_unloading disallow unloading for OSR nmethods is the methodOop > is strongly reachable. Well, here's how the code currently looks to me: ... roughly speaking, if an nmethod (in the weak roots scan) is found to contain an unmarked oop, it seems to become immediately eligible for unloading (the reachability of its _method notwithstanding):- // This is called at the end of the strong tracing/marking phase of a // GC to unload an nmethod if it contains otherwise unreachable // oops. void nmethod::do_unloading(BoolObjectClosure* is_alive, OopClosure* keep_alive, bool unloading_occurred) { // Make sure the oop's ready to receive visitors assert(!is_zombie() && !is_unloaded(), "should not call follow on zombie or unloaded nmethod"); ... // Follow methodOop if (can_unload(is_alive, keep_alive, (oop*)&_method, unloading_occurred)) { return; } ... // Compiled code RelocIterator iter(this, low_boundary); while (iter.next()) { if (iter.type() == relocInfo::oop_type) { oop_Relocation* r = iter.oop_reloc(); // In this loop, we must only traverse those oops directly embedded in // the code. Other oops (oop_index>0) are seen as part of scopes_oops. assert(1 == (r->oop_is_immediate()) + (r->oop_addr() >= oops_begin() && r->oop_addr() < oops_end()), "oop must be found in exactly one place"); if (r->oop_is_immediate() && r->oop_value() != NULL) { if (can_unload(is_alive, keep_alive, r->oop_addr(), unloading_occurred)) { return; } } ... // Scopes for (oop* p = oops_begin(); p < oops_end(); p++) { if (*p == Universe::non_oop_word()) continue; // skip non-oops if (can_unload(is_alive, keep_alive, p, unloading_occurred)) { return; } } ... } Then:- // If this oop is not live, the nmethod can be unloaded. bool nmethod::can_unload(BoolObjectClosure* is_alive, OopClosure* keep_alive, oop* root, bool unloading_occurred) { assert(root != NULL, "just checking"); oop obj = *root; if (obj == NULL || is_alive->do_object_b(obj)) { return false; } if (obj->is_compiledICHolder()) { compiledICHolderOop cichk_oop = compiledICHolderOop(obj); if (is_alive->do_object_b( cichk_oop->holder_method()->method_holder()) && is_alive->do_object_b(cichk_oop->holder_klass())) { // The oop should be kept alive keep_alive->do_oop(root); return false; } } assert(unloading_occurred, "Inconsistency in unloading"); make_unloaded(is_alive, obj); return true; } Here we seem to have ended up with a scope oop that is not a CICHolder, so we call make_unloaded on the nmethod:- nmethod::CodeBlob::_name = 0xfed2f3e4 "nmethod" nmethod::CodeBlob::_size = 34300 nmethod::CodeBlob::_header_size = 184 nmethod::CodeBlob::_relocation_size = 2544 nmethod::CodeBlob::_instructions_offset = 2744 nmethod::CodeBlob::_frame_complete_offset = 16 nmethod::CodeBlob::_data_offset = 18188 nmethod::CodeBlob::_oops_offset = 33896 nmethod::CodeBlob::_oops_length = 101 nmethod::CodeBlob::_frame_size = 48 nmethod::CodeBlob::_oop_maps = 0x9f3188 nmethod::CodeBlob::_comments = { nmethod::CodeBlob::CodeComments::_comments = (nil) } nmethod::_method = 0xf5df2240 nmethod::_entry_bci = 221 nmethod::_link = (nil) nmethod::_compiler = 0x105030 nmethod::_exception_offset = 18160 nmethod::_deoptimize_offset = 18172 nmethod::_trap_offset = 0 nmethod::_stub_offset = 17240 nmethod::_consts_offset = 18188 nmethod::_scopes_data_offset = 18188 nmethod::_scopes_pcs_offset = 24836 nmethod::_dependencies_offset = 31724 nmethod::_handler_table_offset = 31748 nmethod::_nul_chk_table_offset = 33668 nmethod::_nmethod_end_offset = 33896 nmethod::_orig_pc_offset = 188 nmethod::_compile_id = 3 nmethod::_comp_level = 2 nmethod::_entry_point = 0xfb93c740 "\x91\xd0 ^P^G?\xff\xe0\xc0#\x80^C\x9d\xe3\xbf@\xea^F ^H\xec^F ^L\x90^P" nmethod::_verified_entry_point = 0xfb93c740 "\x91\xd0 ^P^G?\xff\xe0\xc0#\x80^C\x9d\xe3\xbf@\xea^F ^H\xec^F ^L\x90^P" nmethod::_osr_entry_point = 0xfb93c744 "^G?\xff\xe0\xc0#\x80^C\x9d\xe3\xbf@\xea^F ^H\xec^F ^L\x90^P" nmethod::flags = { nmethod::nmFlags::version = 0 nmethod::nmFlags::level = 0 nmethod::nmFlags::age = 0 nmethod::nmFlags::state = 0 nmethod::nmFlags::isUncommonRecompiled = 0 nmethod::nmFlags::isToBeRecompiled = 0 nmethod::nmFlags::hasFlushedDependencies = 0 nmethod::nmFlags::markedForReclamation = 0 nmethod::nmFlags::has_unsafe_access = 0 } nmethod::_markedForDeoptimization = false nmethod::_unload_reported = false nmethod::_has_debug_info = false nmethod::_lock_count = 0 nmethod::_stack_traversal_mark = 0 nmethod::_exception_cache = (nil) nmethod::_pc_desc_cache = { nmethod::PcDescCache::_last_pc_desc = 0xfb943268 nmethod::PcDescCache::_pc_descs = (0xfb942e00, 0xfb942cd4, 0xfb942cb0, 0xfb942c74) } nmethod::_compiled_synchronized_native_basic_lock_owner_sp_offset = { nmethod::ByteSize::_size = -1 } nmethod::_compiled_synchronized_native_basic_lock_sp_offset = { nmethod::ByteSize::_size = -1 } nmethod::_zombie_instruction_size = 12 We then go flush_dependencies as part of unloading it, but this does not seem to involve removing it from the osr_nmethod_head. ... then, once it's eligible for unloading, it's marked "unloaded", and the sweeper summarily flushes it without removing it from the osr_method_head:- ... } else if (nm->is_unloaded()) { // Unloaded code, just make it a zombie if (PrintMethodFlushing && Verbose) tty->print_cr("### Nmethod 0x%x (unloaded) being made zombie", nm); if (nm->is_osr_only_method()) { // No inline caches will ever point to osr methods, so we can just remove it nm->flush(); } else { nm->make_zombie(); _rescan = true; } ... Do you believe the hole here may be in the way the nmethod is being unloaded (perhaps flush_dependencies or related should unlink the nmethod from the osr method list) or that the criteria for unloading are here too weak and allowing a premature unload? thanks for all your help so far, and talk to you tomorrow. -- ramki PS: Given the nitty-gritty of this exchange, i am tempted to pull this from the O.J.N. list and take it off-line 1-on-1 with Tom. Let me know if you have read this far and want to be included in the conversation or want the lists to continue being copied. > > tom > > On Aug 5, 2009, at 4:57 PM, Y.S.Ramakrishna at Sun.COM wrote: > >> >> Can there be a situation where an osr nmethod associated >> with a method oop gets unloaded while the method and its >> class are still alive? I see that happening with my workspace >> with the changes for 4957990 (yet to figure out why the osr >> nmethod was unloaded). >> >> Shortly after said unload, the sweeper flushes the nmethod, >> but the nmethod is still left linked off of the klass's _osr_nmethod_head >> list, and a subsequent invocation counter overflow at a bci does >> an osr nmethod lookup and falls foul of the flushed nmethod left >> in the instanceKlass's osr nmethod head. >> >> So I have two questions: >> >> (a) can an osr nmethod be unloaded while its klass is still alive ? >> (b) if the answer to (a) is yes, then we need to take special steps >> (not present in current code) to unlink said nmethod from the >> list of osr nmethods in its klass. >> >> Am I making sense? Otherwise i can provide more direct detail. >> (I am still digging to find out why we decided to unload the >> nmethod and will have more follow-up info in a subsequent email.) >> >> thanks. >> -- ramki > From Thomas.Rodriguez at Sun.COM Wed Aug 5 19:57:01 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 05 Aug 2009 19:57:01 -0700 Subject: request for review (m): 4957990: Perm heap bloat in JVM In-Reply-To: References: <4A789E4C.20109@Sun.COM> <4A78A5DB.3040901@Sun.COM> <4A78E69C.4030604@sun.com> <4A78EDE3.1090703@sun.com> <4A7920B1.7010301@sun.com> <0AA576C1-BA1B-40EF-8ABA-B088C47E3D7B@sun.com> <4A79DBCF.6060506@Sun.COM> <4A79FF45.8060101@sun.com> <4A7A0D33.8030700@Sun.COM> <4A7A1232.7080802@Sun.COM> <287E57C2-5D3D-45C7-87C0-BBB1F5F6212D@Sun.COM> <4A7A17FB.20606@Sun.COM> <4A7A1C81.3020508@Sun.COM> Message-ID: <4A9428BE-AA39-49E7-B948-87650AC3A7B6@sun.com> After I wrote this I realized that this is a natural out growth of your fix. Without profiling information an nmethod should only refer to types which are statically reachable. Having the MDO act as a strong root would keep the nmethod from getting unloaded when using predicted call sites. Once the MDO is a weak root then the nmethod could want to be unloaded. I guess without your fix CHA could produce a case where an OSR nmethod would be unloaded without being unlinked from the OSR nmethod list but I'd have to think about that more. tom On Aug 5, 2009, at 6:15 PM, Tom Rodriguez wrote: > My understanding was that OSR nmethods could/should only be > reclaimed once the klass of their holder was unloaded. The reason > for this is that the normal not_entrant sweeping logic isn't > implemented safely for OSR methods so the sweeper can't safely > reclaim them. If the klass itself is being reclaimed then it should > be safe to reclaim the OSR nmethods. It's possible that we have a > hole in the logic which doesn't account for dealing with unloaded > OSR methods properly and you changes just make it more likely to > happen. We either need to close the not_entrant hole for OSR > nmethods, which isn't that hard, and then correct > nmethod::make_unloaded to unlink the OSR nmethod or we have to make > do_unloading disallow unloading for OSR nmethods is the methodOop is > strongly reachable. > > tom > > On Aug 5, 2009, at 4:57 PM, Y.S.Ramakrishna at Sun.COM wrote: > >> >> Can there be a situation where an osr nmethod associated >> with a method oop gets unloaded while the method and its >> class are still alive? I see that happening with my workspace >> with the changes for 4957990 (yet to figure out why the osr >> nmethod was unloaded). >> >> Shortly after said unload, the sweeper flushes the nmethod, >> but the nmethod is still left linked off of the klass's >> _osr_nmethod_head >> list, and a subsequent invocation counter overflow at a bci does >> an osr nmethod lookup and falls foul of the flushed nmethod left >> in the instanceKlass's osr nmethod head. >> >> So I have two questions: >> >> (a) can an osr nmethod be unloaded while its klass is still alive ? >> (b) if the answer to (a) is yes, then we need to take special steps >> (not present in current code) to unlink said nmethod from the >> list of osr nmethods in its klass. >> >> Am I making sense? Otherwise i can provide more direct detail. >> (I am still digging to find out why we decided to unload the >> nmethod and will have more follow-up info in a subsequent email.) >> >> thanks. >> -- ramki > From Y.S.Ramakrishna at Sun.COM Wed Aug 5 23:10:48 2009 From: Y.S.Ramakrishna at Sun.COM (Y. Srinivas Ramakrishna) Date: Wed, 05 Aug 2009 23:10:48 -0700 Subject: request for review (m): 4957990: Perm heap bloat in JVM In-Reply-To: <4A9428BE-AA39-49E7-B948-87650AC3A7B6@sun.com> References: <4A789E4C.20109@Sun.COM> <4A78A5DB.3040901@Sun.COM> <4A78E69C.4030604@sun.com> <4A78EDE3.1090703@sun.com> <4A7920B1.7010301@sun.com> <0AA576C1-BA1B-40EF-8ABA-B088C47E3D7B@sun.com> <4A79DBCF.6060506@Sun.COM> <4A79FF45.8060101@sun.com> <4A7A0D33.8030700@Sun.COM> <4A7A1232.7080802@Sun.COM> <287E57C2-5D3D-45C7-87C0-BBB1F5F6212D@Sun.COM> <4A7A17FB.20606@Sun.COM> <4A7A1C81.3020508@Sun.COM> <4A9428BE-AA39-49E7-B948-87650AC3A7B6@sun.com> Message-ID: <4A7A73E8.4020008@sun.com> Tom Rodriguez wrote: > After I wrote this I realized that this is a natural out growth of > your fix. Without profiling information an nmethod should only refer > to types which are statically reachable. Having the MDO act as a > strong root would keep the nmethod from getting unloaded when using > predicted call sites. Once the MDO is a weak root then the nmethod > could want to be unloaded. I guess without your fix CHA could produce > a case where an OSR nmethod would be unloaded without being unlinked > from the OSR nmethod list but I'd have to think about that more. So, Tom, is my understanding correct that the criteria for unloading of the nmethod are not too weak. Do you suggest that make_unloaded should just go unlink the nmethod from the osr list? I'll give that a try tonight and update later on how that looks wrt the current test, but let me know if i am misunderstanding and that would not be the correct way to fix this problem, thanks! -- ramki > > tom > > On Aug 5, 2009, at 6:15 PM, Tom Rodriguez wrote: > >> My understanding was that OSR nmethods could/should only be reclaimed >> once the klass of their holder was unloaded. The reason for this is >> that the normal not_entrant sweeping logic isn't implemented safely >> for OSR methods so the sweeper can't safely reclaim them. If the >> klass itself is being reclaimed then it should be safe to reclaim the >> OSR nmethods. It's possible that we have a hole in the logic which >> doesn't account for dealing with unloaded OSR methods properly and >> you changes just make it more likely to happen. We either need to >> close the not_entrant hole for OSR nmethods, which isn't that hard, >> and then correct nmethod::make_unloaded to unlink the OSR nmethod or >> we have to make do_unloading disallow unloading for OSR nmethods is >> the methodOop is strongly reachable. >> >> tom >> >> On Aug 5, 2009, at 4:57 PM, Y.S.Ramakrishna at Sun.COM wrote: >> >>> >>> Can there be a situation where an osr nmethod associated >>> with a method oop gets unloaded while the method and its >>> class are still alive? I see that happening with my workspace >>> with the changes for 4957990 (yet to figure out why the osr >>> nmethod was unloaded). >>> >>> Shortly after said unload, the sweeper flushes the nmethod, >>> but the nmethod is still left linked off of the klass's >>> _osr_nmethod_head >>> list, and a subsequent invocation counter overflow at a bci does >>> an osr nmethod lookup and falls foul of the flushed nmethod left >>> in the instanceKlass's osr nmethod head. >>> >>> So I have two questions: >>> >>> (a) can an osr nmethod be unloaded while its klass is still alive ? >>> (b) if the answer to (a) is yes, then we need to take special steps >>> (not present in current code) to unlink said nmethod from the >>> list of osr nmethods in its klass. >>> >>> Am I making sense? Otherwise i can provide more direct detail. >>> (I am still digging to find out why we decided to unload the >>> nmethod and will have more follow-up info in a subsequent email.) >>> >>> thanks. >>> -- ramki >> > From John.Coomes at sun.com Thu Aug 6 10:35:38 2009 From: John.Coomes at sun.com (John Coomes) Date: Thu, 6 Aug 2009 10:35:38 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <19058.9853.988064.242430@sun.com> References: <19058.9853.988064.242430@sun.com> Message-ID: <19067.5226.564655.492988@sun.com> John Coomes (John.Coomes at sun.com) wrote: > I'd appreciate some reviews of 6866585: debug code in ciObjectFactory > too slow for large objects. > > http://cr.openjdk.java.net/~jcoomes/6866585-ci-debug/ > > (The bug is not yet visible on bugs.sun.com; it should be sometime > soon.) > > Before the change, a fastdebug build took 6+ minutes to run the test; > now it takes a few seconds. > > Since I almost never touch compiler code, I'd also appreciate > recommendations for tests to run. Anyone? -John From vladimir.kozlov at sun.com Thu Aug 6 10:48:04 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 06 Aug 2009 17:48:04 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 27 new changesets Message-ID: <20090806174912.445F4E509@hg.openjdk.java.net> Changeset: 45d97a99715b Author: apetrusenko Date: 2009-07-22 02:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/45d97a99715b 6862661: G1: _gc_alloc_region_counts is not updated properly after 6604422 Summary: Implementation of RFE 6604422 (G1: re-use half-promoted regions) introduced incorrect _gc_alloc_region_counts updates which effectively disabled survivor spaces. Reviewed-by: johnc, jmasa, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 36b5611220a7 Author: ysr Date: 2009-07-22 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/36b5611220a7 6863216: Clean up debugging debris inadvertently pushed with 6700789 Summary: Anti-delta for debugging debris that was inadvertently pushed. Reviewed-by: kvn, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/opto/cfgnode.cpp Changeset: 0a83664f978b Author: ysr Date: 2009-07-24 12:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0a83664f978b Merge ! src/share/vm/opto/cfgnode.cpp Changeset: 57c71ad0341b Author: xdono Date: 2009-07-16 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/57c71ad0341b Added tag jdk7-b65 for changeset ba313800759b ! .hgtags Changeset: 1c2487639400 Author: trims Date: 2009-07-24 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1c2487639400 Merge Changeset: 3c0f72981560 Author: trims Date: 2009-07-24 16:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3c0f72981560 6864901: Bump the HS16 build number to 07 Summary: Update the HS16 build number to 07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 96e4ccadd5f6 Author: xdono Date: 2009-07-24 13:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/96e4ccadd5f6 Added tag jdk7-b66 for changeset 57c71ad0341b ! .hgtags Changeset: bd02caa94611 Author: xdono Date: 2009-07-28 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bd02caa94611 6862919: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 07/09 Reviewed-by: tbell, ohair ! agent/src/os/linux/Makefile ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java ! agent/src/share/classes/sun/jvm/hotspot/code/MonitorValue.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeValue.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ObjectReferenceImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ThreadReferenceImpl.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/CompiledVFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/InterpretedVFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/MonitorInfo.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/StackValue.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/StubRoutines.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Thread.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/tools/jcore/ByteCodeRewriter.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/tree/OopTreeNodeAdapter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaThread.java ! make/jprt.properties ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/sparcWorks.make ! make/windows/build_vm_def.sh ! make/windows/create.bat ! make/windows/get_msc_ver.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/makedeps.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/vm.make ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interpreterRT_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp ! src/share/tools/MakeDeps/BuildConfig.java ! src/share/tools/MakeDeps/WinGammaPlatformVC7.java ! src/share/tools/MakeDeps/WinGammaPlatformVC8.java ! src/share/tools/MakeDeps/WinGammaPlatformVC9.java ! src/share/tools/hsdis/Makefile ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c ! src/share/vm/adlc/adlc.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_jvmti ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/invocationCounter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/dtraceJSDT.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/hpi.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/orderAccess.cpp ! src/share/vm/runtime/orderAccess.hpp ! src/share/vm/runtime/stackValue.cpp ! src/share/vm/runtime/stackValue.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframe_hp.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/macros.hpp ! test/compiler/6772683/InterruptedTest.java ! test/compiler/6832293/Test.java ! test/runtime/6819213/TestBootNativeLibraryPath.java Changeset: 18f526145aea Author: trims Date: 2009-07-29 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/18f526145aea Merge ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/stackValue.cpp Changeset: 6a93908f268f Author: mchung Date: 2009-07-10 11:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6a93908f268f 6857194: Add hotspot perf counters to aid class loading performance measurement Summary: Add new jvmstat counters to measure detailed class loading time Reviewed-by: acorn, kamg ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/includeDB_core ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp Changeset: 1413494da700 Author: martin Date: 2009-06-29 14:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1413494da700 6850957: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit Summary: call report_java_out_of_memory("Requested array size exceeds VM limit") Reviewed-by: tbell, dholmes, alanb, ysr Contributed-by: jeremymanson at google.com ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp Changeset: 8c79517a9300 Author: poonam Date: 2009-07-16 18:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8c79517a9300 6840305: Discrepancy in system memory details (when 4G or greater) reported by JVM and Windows OS Summary: GlobalMemoryStatus() does not report correct memory usage when the system has more than 4gb of RAM. GlobalMemoryStatusEx() should be used in place of GlobalMemoryStatus(). Reviewed-by: kamg, coleenp ! src/os/windows/vm/os_windows.cpp Changeset: abe076e3636f Author: mchung Date: 2009-07-27 09:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/abe076e3636f 6864003: Modify JVM_FindClassFromBootLoader to return null if class not found Summary: JVM_FindClassFromBootLoader returns null if class not found Reviewed-by: acorn, alanb, dholmes ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 494244ae0171 Author: coleenp Date: 2009-07-27 17:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/494244ae0171 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/includeDB_core ! src/share/vm/oops/objArrayKlass.cpp Changeset: 2b4230d1e589 Author: dcubed Date: 2009-07-28 13:35 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2b4230d1e589 6862295: JDWP threadid changes during debugging session (leading to ingored breakpoints) Summary: Correctly count full GC operations for framework collectors. Add ForceFullGCJVMTIEpilogues as a future work around if needed. Reviewed-by: jcoomes, alanb, ysr ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/globals.hpp Changeset: 16c930df1e9b Author: dcubed Date: 2009-07-28 13:50 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/16c930df1e9b Merge ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/globals.hpp Changeset: 66b0f834a440 Author: coleenp Date: 2009-07-30 15:06 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/66b0f834a440 Merge ! src/share/vm/classfile/classLoader.cpp Changeset: 27f6a9b9c311 Author: tonyp Date: 2009-07-29 11:01 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/27f6a9b9c311 6864886: G1: rename -XX parameters related to update buffers Summary: renaming a couple of update buffer-related parameters to make them more understandable and consistent. Reviewed-by: iveresov, ysr ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/globals.hpp Changeset: 83b687ce3090 Author: tonyp Date: 2009-07-30 14:50 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/83b687ce3090 6866591: G1: print update buffer processing stats more often Summary: It adds parameter -XX:+G1SummarizeRSetStatsPeriod that causes update buffer processing information to be printed periodically. It also includes two small formatting changes. Reviewed-by: jmasa, jcoomes, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7f807f55161a Author: ysr Date: 2009-07-31 10:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7f807f55161a Merge ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/runtime/globals.hpp Changeset: 061cd4d965fc Author: jmasa Date: 2009-08-02 18:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/061cd4d965fc 6862534: -XX:NewRatio completely ignored when combined with -XX:+UseConcMarkSweepG Summary: Use NewRatio if it is explicitly set. Reviewed-by: ysr, jcoomes ! src/share/vm/runtime/arguments.cpp Changeset: ff004bcd2596 Author: jmasa Date: 2009-08-02 19:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ff004bcd2596 6843292: "Expect to be beyond new region unless impacting another region" assertion too strong Summary: In the assertion allow for collision with the guard page. Reviewed-by: tonyp, ysr, jcoomes ! src/share/vm/memory/cardTableModRefBS.cpp Changeset: 59726d16b30d Author: jmasa Date: 2009-08-02 22:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/59726d16b30d Merge Changeset: 15c5903cf9e1 Author: johnc Date: 2009-08-03 12:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/15c5903cf9e1 6865703: G1: Parallelize hot card cache cleanup Summary: Have the GC worker threads clear the hot card cache in parallel by having each worker thread claim a chunk of the card cache and process the cards in that chunk. The size of the chunks that each thread will claim is determined at VM initialization from the size of the card cache and the number of worker threads. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 6cb8e9df7174 Author: johnc Date: 2009-08-04 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6cb8e9df7174 6819077: G1: first GC thread coming late into the GC. Summary: The first worker thread is delayed when entering the GC because it clears the card count table that is used in identifying hot cards. Replace the card count table with a dynamically sized evicting hash table that includes an epoch based counter. Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: 703065c670fa Author: ysr Date: 2009-08-05 18:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/703065c670fa 6868991: JPRT: elide GCBasher_G1 test on winx64 until 6867250 is resolved Summary: JPRT: elide GCBasher_G1 test on winx64 until 6867250 is resolved Reviewed-by: jcoomes ! make/jprt.properties Changeset: 15bbd3f505c0 Author: kvn Date: 2009-08-06 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/15bbd3f505c0 Merge ! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframe_hp.cpp From John.Rose at Sun.COM Thu Aug 6 10:52:50 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 06 Aug 2009 10:52:50 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <19067.5226.564655.492988@sun.com> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> Message-ID: On Aug 6, 2009, at 10:35 AM, John Coomes wrote: > John Coomes (John.Coomes at sun.com) wrote: >> http://cr.openjdk.java.net/~jcoomes/6866585-ci-debug/ > > Anyone? I wrote that assert code. (I was on vacation when your review request went out. And thanks for the reminder!) The reason it's so thorough is not distrust of the local insertion- sort logic, but rather uncertainty about whether the GC will ever reorder perm-gen objects. The point of the exhaustive re-check of ordering is the paranoid suspicion that the GC might have changed the relative order of the oops on the _ci_objects list, thereby breaking the binary search logic. If that interaction between the CI and the GC were to happen, we'd have some badly intermittent and subtle bugs to deal with. I suggest factoring the deleted exhaustive check into a subroutine which walks the whole list and verifies that it is still in order. For maximum paranoid defensiveness, this should be done after every GC. Maybe a static variable that holds a GC tick can be used to short- circuit repeated checks on the same GC tick?? I don't mind putting it under a new flag, but make it diagnostic, so we want turn it on in the field if there are suspicious crashes. Sorry to make you wait for this! -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090806/a8d2be6e/attachment.html From Y.S.Ramakrishna at Sun.COM Thu Aug 6 11:00:22 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Thu, 06 Aug 2009 11:00:22 -0700 Subject: nmethod::is_osr_{only_}method()? Message-ID: <4A7B1A36.9050602@Sun.COM> Anyone know why we have both an is_osr_only_method() and is_osr_method(), since they are synonymous:- bool is_osr_method() const { return _entry_bci != InvocationEntryBci; } bool is_osr_only_method() const { return is_osr_method(); } (I see code that uses both variants, so am not sure if this was a historical distinction that is now obsolete?) thanks! -- ramki From John.Rose at Sun.COM Thu Aug 6 11:07:10 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 06 Aug 2009 11:07:10 -0700 Subject: nmethod::is_osr_{only_}method()? In-Reply-To: <4A7B1A36.9050602@Sun.COM> References: <4A7B1A36.9050602@Sun.COM> Message-ID: <29E7CA15-65B0-4F07-BA67-A4E4BB6408B3@sun.com> On Aug 6, 2009, at 11:00 AM, Y.S.Ramakrishna at Sun.COM wrote: > > Anyone know why we have both an is_osr_only_method() > and is_osr_method(), since they are synonymous:- IIRC, we have played with nmethods in C1 which had both the main entry points and pre-generated OSR entry points. > (I see code that uses both variants, so am not > sure if this was a historical distinction that is > now obsolete?) From Y.S.Ramakrishna at Sun.COM Thu Aug 6 11:07:55 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Thu, 06 Aug 2009 11:07:55 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> Message-ID: <4A7B1BFB.2090909@Sun.COM> Hi John (Rose) -- Current GCs in hotspot will never reorder perm gen objects. Of course having the check at every full gc seems fine in debug mode. The diagnostic mode may be paranoid given our current GC's, but is fine to have if you feel that would still be worthwhile. -- ramki On 08/06/09 10:52, John Rose wrote: > On Aug 6, 2009, at 10:35 AM, John Coomes wrote: > >> John Coomes (John.Coomes at sun.com ) wrote: >>> http://cr.openjdk.java.net/~jcoomes/6866585-ci-debug/ >> >> Anyone? > > I wrote that assert code. (I was on vacation when your review request > went out. And thanks for the reminder!) > > The reason it's so thorough is not distrust of the local insertion-sort > logic, but rather uncertainty about whether the GC will ever reorder > perm-gen objects. The point of the exhaustive re-check of ordering is > the paranoid suspicion that the GC might have changed the relative order > of the oops on the _ci_objects list, thereby breaking the binary search > logic. > > If that interaction between the CI and the GC were to happen, we'd have > some badly intermittent and subtle bugs to deal with. > > I suggest factoring the deleted exhaustive check into a subroutine which > walks the whole list and verifies that it is still in order. For > maximum paranoid defensiveness, this should be done after every GC. > Maybe a static variable that holds a GC tick can be used to > short-circuit repeated checks on the same GC tick?? > > I don't mind putting it under a new flag, but make it diagnostic, so we > want turn it on in the field if there are suspicious crashes. > > Sorry to make you wait for this! > > -- John From John.Rose at Sun.COM Thu Aug 6 11:13:12 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 06 Aug 2009 11:13:12 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <4A7B1BFB.2090909@Sun.COM> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> Message-ID: <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> On Aug 6, 2009, at 11:07 AM, Y.S.Ramakrishna at Sun.COM wrote: > Current GCs in hotspot will never reorder perm gen objects. And that's been true in all the years since we wrote the paranoid CI code. It's just waiting for that day when all its fears are justtified! :-) > Of course having the check at every full gc seems fine in debug > mode. The diagnostic mode may be paranoid given our current GC's, > but is fine to have if you feel that would still be worthwhile. Would it be possible to put the check into the GC epilogue? Probably not, since ciEnv guys are not statically allocated and not easy to enumerate (one per active compile-thread task). I guess I do like the idea of checking a GC tick counter from the CI, to throttle the paranoid check. Best of all would be to have some explicit linkage from the GC epilogue code to the CI, which somehow documents and enforces the order invariance. You can see why this is awkward: It is an invariant shared by the CI and the GC. -- John From Thomas.Rodriguez at Sun.COM Thu Aug 6 11:15:23 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 06 Aug 2009 11:15:23 -0700 Subject: nmethod::is_osr_{only_}method()? In-Reply-To: <29E7CA15-65B0-4F07-BA67-A4E4BB6408B3@sun.com> References: <4A7B1A36.9050602@Sun.COM> <29E7CA15-65B0-4F07-BA67-A4E4BB6408B3@sun.com> Message-ID: I think it's an artifact that could be removed. C1 OSR nmethods actually have a normal entry in addition to an OSR entry point but it's never used and we certainly don't expose that fact anywhere. tom On Aug 6, 2009, at 11:07 AM, John Rose wrote: > On Aug 6, 2009, at 11:00 AM, Y.S.Ramakrishna at Sun.COM wrote: > >> >> Anyone know why we have both an is_osr_only_method() >> and is_osr_method(), since they are synonymous:- > > IIRC, we have played with nmethods in C1 which had both the main > entry points and pre-generated OSR entry points. > >> (I see code that uses both variants, so am not >> sure if this was a historical distinction that is >> now obsolete?) > From Y.S.Ramakrishna at Sun.COM Thu Aug 6 11:27:09 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Thu, 06 Aug 2009 11:27:09 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> Message-ID: <4A7B207D.5000605@Sun.COM> On 08/06/09 11:13, John Rose wrote: > On Aug 6, 2009, at 11:07 AM, Y.S.Ramakrishna at Sun.COM wrote: > >> Current GCs in hotspot will never reorder perm gen objects. > > And that's been true in all the years since we wrote the paranoid CI > code. It's just waiting for that day when all its fears are > justtified! :-) Right; and the debug mode check should i think be sufficient to catch that; but yes who knows about how frequently that would happen in testing/debug mode, so perhaps having a diagnostic mode check would be OK, too. I yield :-) > >> Of course having the check at every full gc seems fine in debug >> mode. The diagnostic mode may be paranoid given our current GC's, >> but is fine to have if you feel that would still be worthwhile. > > Would it be possible to put the check into the GC epilogue? Probably > not, since ciEnv guys are not statically allocated and not easy to > enumerate (one per active compile-thread task). I guess I do like the > idea of checking a GC tick counter from the CI, to throttle the paranoid > check. Best of all would be to have some explicit linkage from the GC > epilogue code to the CI, which somehow documents and enforces the order > invariance. You can see why this is awkward: It is an invariant shared > by the CI and the GC. Yes, i agree, if it's one per active compile task, may be it's best to use yr strategy of eliding the check unless the full gc count changes. -- ramki > > -- John From Thomas.Rodriguez at Sun.COM Thu Aug 6 11:36:50 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 06 Aug 2009 11:36:50 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <4A7B207D.5000605@Sun.COM> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> Message-ID: >>> Would it be possible to put the check into the GC epilogue? >>> Probably not, since ciEnv guys are not statically allocated and >>> not easy to enumerate (one per active compile-thread task). I >>> guess I do like the idea of checking a GC tick counter from the >>> CI, to throttle the paranoid check. Best of all would be to have >>> some explicit linkage from the GC epilogue code to the CI, which >>> somehow documents and enforces the order invariance. You can see >>> why this is awkward: It is an invariant shared by the CI and the >>> GC. > > Yes, i agree, if it's one per active compile task, may be it's best > to use > yr strategy of eliding the check unless the full gc count changes. John, couldn't this strategy allow us to reunify the handling of oops into a single table instead of needing the NonPermOop stuff? If we simply re-sort the table when needed that code becomes simple again. It also makes us impervious to reordering concerns. tom > > -- ramki > >> -- John > From Keith.McGuigan at Sun.COM Thu Aug 6 11:46:37 2009 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Thu, 06 Aug 2009 14:46:37 -0400 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> Message-ID: <4A7B250D.5040408@sun.com> Tom Rodriguez wrote: >>>> Would it be possible to put the check into the GC epilogue? >>>> Probably not, since ciEnv guys are not statically allocated and not >>>> easy to enumerate (one per active compile-thread task). I guess I >>>> do like the idea of checking a GC tick counter from the CI, to >>>> throttle the paranoid check. Best of all would be to have some >>>> explicit linkage from the GC epilogue code to the CI, which somehow >>>> documents and enforces the order invariance. You can see why this >>>> is awkward: It is an invariant shared by the CI and the GC. >> >> Yes, i agree, if it's one per active compile task, may be it's best to >> use >> yr strategy of eliding the check unless the full gc count changes. > > John, couldn't this strategy allow us to reunify the handling of oops > into a single table instead of needing the NonPermOop stuff? If we > simply re-sort the table when needed that code becomes simple again. It > also makes us impervious to reordering concerns. Would that also be a step towards getting some of the stuff (namely symbols) out of perm gen? There's more to it than that, of course, but the ordering constraint by the compiler was one of the reasons for keeping them in perm gen. -- - Keith From Thomas.Rodriguez at Sun.COM Thu Aug 6 11:53:53 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 06 Aug 2009 11:53:53 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <4A7B250D.5040408@sun.com> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B250D.5040408@sun.com> Message-ID: On Aug 6, 2009, at 11:46 AM, Keith McGuigan wrote: > Tom Rodriguez wrote: >>>>> Would it be possible to put the check into the GC epilogue? >>>>> Probably not, since ciEnv guys are not statically allocated and >>>>> not easy to enumerate (one per active compile-thread task). I >>>>> guess I do like the idea of checking a GC tick counter from the >>>>> CI, to throttle the paranoid check. Best of all would be to >>>>> have some explicit linkage from the GC epilogue code to the CI, >>>>> which somehow documents and enforces the order invariance. You >>>>> can see why this is awkward: It is an invariant shared by the >>>>> CI and the GC. >>> >>> Yes, i agree, if it's one per active compile task, may be it's >>> best to use >>> yr strategy of eliding the check unless the full gc count changes. >> John, couldn't this strategy allow us to reunify the handling of >> oops into a single table instead of needing the NonPermOop stuff? >> If we simply re-sort the table when needed that code becomes simple >> again. It also makes us impervious to reordering concerns. > > Would that also be a step towards getting some of the stuff (namely > symbols) out of perm gen? There's more to it than that, of course, > but the ordering constraint by the compiler was one of the reasons > for keeping them in perm gen. I don't think the compiler was the main constraint for where symbols live and whether they can be reordered. I thought symbol and method lookup in the core of the VM relied on the ordering as well? See symbolOopDesc::fast_compare. Why would moving the symbols out of perm be a good idea? tom > > -- > - Keith From Y.S.Ramakrishna at Sun.COM Thu Aug 6 12:02:34 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Thu, 06 Aug 2009 12:02:34 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> Message-ID: <4A7B28CA.30806@Sun.COM> (Please take my comments with the requisite dose of salt because i know little about these CIObjects, so i may be talking nonsense in this context :-) How big could the (unified) table get? (Clearly in the case of the test that brought forth the problem it must become quite large, but perhaps that's an extreme case.) Still, I'd be wary of anything that requires a large table re-sort at each full gc, let alone at each scavenge... (BTW, what do you do with non-perm stuff today where order is not preserved across GCs? why not do that for all objects rather than rely on ordering for the perm subset?) Of course, if the table is small, may be my concern is moot. -- ramki On 08/06/09 11:36, Tom Rodriguez wrote: >>>> Would it be possible to put the check into the GC epilogue? >>>> Probably not, since ciEnv guys are not statically allocated and not >>>> easy to enumerate (one per active compile-thread task). I guess I >>>> do like the idea of checking a GC tick counter from the CI, to >>>> throttle the paranoid check. Best of all would be to have some >>>> explicit linkage from the GC epilogue code to the CI, which somehow >>>> documents and enforces the order invariance. You can see why this >>>> is awkward: It is an invariant shared by the CI and the GC. >> >> Yes, i agree, if it's one per active compile task, may be it's best to >> use >> yr strategy of eliding the check unless the full gc count changes. > > John, couldn't this strategy allow us to reunify the handling of oops > into a single table instead of needing the NonPermOop stuff? If we > simply re-sort the table when needed that code becomes simple again. It > also makes us impervious to reordering concerns. > > tom > >> >> -- ramki >> >>> -- John >> > From Thomas.Rodriguez at Sun.COM Thu Aug 6 12:24:16 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 06 Aug 2009 12:24:16 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <4A7B28CA.30806@Sun.COM> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B28CA.30806@Sun.COM> Message-ID: <36827419-C427-4F66-AC1F-0525093E40B3@sun.com> On Aug 6, 2009, at 12:02 PM, Y.S.Ramakrishna at Sun.COM wrote: > (Please take my comments with the requisite dose of salt because > i know little about these CIObjects, so i may be talking nonsense > in this context :-) > > How big could the (unified) table get? (Clearly in the case of the > test that > brought forth the problem it must become quite large, but perhaps > that's > an extreme case.) Still, I'd be wary of anything that > requires a large table re-sort at each full gc, let alone at each > scavenge... > (BTW, what do you do with non-perm stuff today where order is not > preserved > across GCs? why not do that for all objects rather than rely on > ordering > for the perm subset?) Of course, if the table is small, may be my > concern is moot. Size isn't the only determining factor. It would only have to re-sort if get was called and it might only resort if it fails the binary search lookup and a GC has happened since the last sort since it's likely that a GC doesn't change the order. The tables aren't huge, 10-100 elements normally I would guess. Anyway it seems manageable if we want it to be. tom > > -- ramki > > On 08/06/09 11:36, Tom Rodriguez wrote: >>>>> Would it be possible to put the check into the GC epilogue? >>>>> Probably not, since ciEnv guys are not statically allocated and >>>>> not easy to enumerate (one per active compile-thread task). I >>>>> guess I do like the idea of checking a GC tick counter from the >>>>> CI, to throttle the paranoid check. Best of all would be to >>>>> have some explicit linkage from the GC epilogue code to the CI, >>>>> which somehow documents and enforces the order invariance. You >>>>> can see why this is awkward: It is an invariant shared by the >>>>> CI and the GC. >>> >>> Yes, i agree, if it's one per active compile task, may be it's >>> best to use >>> yr strategy of eliding the check unless the full gc count changes. >> John, couldn't this strategy allow us to reunify the handling of >> oops into a single table instead of needing the NonPermOop stuff? >> If we simply re-sort the table when needed that code becomes simple >> again. It also makes us impervious to reordering concerns. >> tom >>> >>> -- ramki >>> >>>> -- John >>> > From Keith.McGuigan at Sun.COM Thu Aug 6 12:27:27 2009 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Thu, 06 Aug 2009 15:27:27 -0400 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B250D.5040408@sun.com> Message-ID: <4A7B2E9F.5010607@sun.com> Tom Rodriguez wrote: > I don't think the compiler was the main constraint for where symbols > live and whether they can be reordered. I thought symbol and method > lookup in the core of the VM relied on the ordering as well? See > symbolOopDesc::fast_compare. Why would moving the symbols out of perm > be a good idea? Yes, fast_compare() uses the ordering as well (and that too, could be rewritten). That's why I said there was more to it than just the CI. I'm not sure if moving symbols out of perm would be a splendid idea or not... just something I've been wanting to prototype. -- - Keith From John.Coomes at sun.com Thu Aug 6 14:15:22 2009 From: John.Coomes at sun.com (John Coomes) Date: Thu, 6 Aug 2009 14:15:22 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <4A7B28CA.30806@Sun.COM> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B28CA.30806@Sun.COM> Message-ID: <19067.18410.306822.942873@sun.com> Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) wrote: > (Please take my comments with the requisite dose of salt because > i know little about these CIObjects, so i may be talking nonsense > in this context :-) > > How big could the (unified) table get? (Clearly in the case of the test that > brought forth the problem it must become quite large, but perhaps that's > an extreme case.) Still, I'd be wary of anything that > requires a large table re-sort at each full gc, let alone at each scavenge... > (BTW, what do you do with non-perm stuff today where order is not preserved > across GCs? why not do that for all objects rather than rely on ordering > for the perm subset?) Of course, if the table is small, may be my concern is moot. FWIW, the current table gets to a little over 64K elements with my test case. get() is called 3 times at each value of length (from 1 - 64K+), and each call does two iterations over the table. It's a lot. Long term, I think the GC should notify the CI when perm gen objects may have been reordered. The CI should just record the notification, and later re-sort or do whatever is necessary on the next get()/insert()/whatever. As Ramki mentioned, none of our current GCs would have to do this, we just have to worry about future GCs. I think a reasonable solution would be to have current GCs do the (unnecessary) notification whenever perm gen is collected in debug builds. That would exercise the code without excessive overhead, and also document the dependency in the code. I would expect a new collector to start by cloning an existing collector. In the short-term, I just want to be able to check in my test case. How about if I restore the debugging code, but put it under control of the CIObjectFactoryVerify option? I'll also file a bug to capture the comments. -John > On 08/06/09 11:36, Tom Rodriguez wrote: > >>>> Would it be possible to put the check into the GC epilogue? > >>>> Probably not, since ciEnv guys are not statically allocated and not > >>>> easy to enumerate (one per active compile-thread task). I guess I > >>>> do like the idea of checking a GC tick counter from the CI, to > >>>> throttle the paranoid check. Best of all would be to have some > >>>> explicit linkage from the GC epilogue code to the CI, which somehow > >>>> documents and enforces the order invariance. You can see why this > >>>> is awkward: It is an invariant shared by the CI and the GC. > >> > >> Yes, i agree, if it's one per active compile task, may be it's best to > >> use > >> yr strategy of eliding the check unless the full gc count changes. > > > > John, couldn't this strategy allow us to reunify the handling of oops > > into a single table instead of needing the NonPermOop stuff? If we > > simply re-sort the table when needed that code becomes simple again. It > > also makes us impervious to reordering concerns. > > > > tom > > > >> > >> -- ramki > >> > >>> -- John > >> > > > From Thomas.Rodriguez at Sun.COM Thu Aug 6 14:28:23 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 06 Aug 2009 14:28:23 -0700 Subject: request for review (m): 4957990: Perm heap bloat in JVM In-Reply-To: <4A7A73E8.4020008@sun.com> References: <4A789E4C.20109@Sun.COM> <4A78A5DB.3040901@Sun.COM> <4A78E69C.4030604@sun.com> <4A78EDE3.1090703@sun.com> <4A7920B1.7010301@sun.com> <0AA576C1-BA1B-40EF-8ABA-B088C47E3D7B@sun.com> <4A79DBCF.6060506@Sun.COM> <4A79FF45.8060101@sun.com> <4A7A0D33.8030700@Sun.COM> <4A7A1232.7080802@Sun.COM> <287E57C2-5D3D-45C7-87C0-BBB1F5F6212D@Sun.COM> <4A7A17FB.20606@Sun.COM> <4A7A1C81.3020508@Sun.COM> <4A9428BE-AA39-49E7-B948-87650AC3A7B6@sun.com> <4A7A73E8.4020008@sun.com> Message-ID: On Aug 5, 2009, at 11:10 PM, Y. Srinivas Ramakrishna wrote: > Tom Rodriguez wrote: >> After I wrote this I realized that this is a natural out growth of >> your fix. Without profiling information an nmethod should only >> refer to types which are statically reachable. Having the MDO act >> as a strong root would keep the nmethod from getting unloaded when >> using predicted call sites. Once the MDO is a weak root then the >> nmethod could want to be unloaded. I guess without your fix CHA >> could produce a case where an OSR nmethod would be unloaded without >> being unlinked from the OSR nmethod list but I'd have to think >> about that more. > > So, Tom, is my understanding correct that the criteria for unloading > of the nmethod are not too > weak. Do you suggest that make_unloaded should just go unlink the > nmethod from the osr list? > I'll give that a try tonight and update later on how that looks wrt > the current test, > but let me know if i am misunderstanding and that would not be the > correct way to > fix this problem, We can't allow the sweeper to free an nmethod unless we are certain that it's impossible for new activations of that nmethod to form. Note this comment: void nmethod::make_not_entrant_or_zombie(int state) { assert(state == zombie || state == not_entrant, "must be zombie or not_entrant"); // Code for an on-stack-replacement nmethod is removed when a class gets unloaded. // They never become zombie/non-entrant, so the nmethod sweeper will never remove // them. Instead the entry_bci is set to InvalidOSREntryBci, so the osr nmethod // will never be used anymore. That the nmethods only gets removed when class unloading // happens, make life much simpler, since the nmethods are not just going to disappear // out of the blue. So I don't think reclamation of OSR nmethods in the current code is safe. I do believe that OSR nmethods could be reclaimed like other normal nmethods and I have an old webrev that illustrates this at http://javaweb.sfbay.sun.com/~never/webrev/osr . I think that the changes in the assembly code are unneeded since the requirement we're trying to enforce is that if an OSR nmethod becomes unloaded at a safepoint it won't be used for form a new activation which is accomplished by the interpeterRuntime.cpp changes. I'm not sure we want to include the reclaiming of OSR nmethods into hs16 at this point. So maybe OSR nmethods need to act as strong roots for now? tom > > thanks! > -- ramki >> >> tom >> >> On Aug 5, 2009, at 6:15 PM, Tom Rodriguez wrote: >> >>> My understanding was that OSR nmethods could/should only be >>> reclaimed once the klass of their holder was unloaded. The reason >>> for this is that the normal not_entrant sweeping logic isn't >>> implemented safely for OSR methods so the sweeper can't safely >>> reclaim them. If the klass itself is being reclaimed then it >>> should be safe to reclaim the OSR nmethods. It's possible that we >>> have a hole in the logic which doesn't account for dealing with >>> unloaded OSR methods properly and you changes just make it more >>> likely to happen. We either need to close the not_entrant hole >>> for OSR nmethods, which isn't that hard, and then correct >>> nmethod::make_unloaded to unlink the OSR nmethod or we have to >>> make do_unloading disallow unloading for OSR nmethods is the >>> methodOop is strongly reachable. >>> >>> tom >>> >>> On Aug 5, 2009, at 4:57 PM, Y.S.Ramakrishna at Sun.COM wrote: >>> >>>> >>>> Can there be a situation where an osr nmethod associated >>>> with a method oop gets unloaded while the method and its >>>> class are still alive? I see that happening with my workspace >>>> with the changes for 4957990 (yet to figure out why the osr >>>> nmethod was unloaded). >>>> >>>> Shortly after said unload, the sweeper flushes the nmethod, >>>> but the nmethod is still left linked off of the klass's >>>> _osr_nmethod_head >>>> list, and a subsequent invocation counter overflow at a bci does >>>> an osr nmethod lookup and falls foul of the flushed nmethod left >>>> in the instanceKlass's osr nmethod head. >>>> >>>> So I have two questions: >>>> >>>> (a) can an osr nmethod be unloaded while its klass is still alive ? >>>> (b) if the answer to (a) is yes, then we need to take special steps >>>> (not present in current code) to unlink said nmethod from the >>>> list of osr nmethods in its klass. >>>> >>>> Am I making sense? Otherwise i can provide more direct detail. >>>> (I am still digging to find out why we decided to unload the >>>> nmethod and will have more follow-up info in a subsequent email.) >>>> >>>> thanks. >>>> -- ramki >>> >> > From Thomas.Rodriguez at Sun.COM Thu Aug 6 14:37:27 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 06 Aug 2009 14:37:27 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <19067.18410.306822.942873@sun.com> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B28CA.30806@Sun.COM> <19067.18410.306822.942873@sun.com> Message-ID: I'm not against putting it under a flag but that just seems equivalent to deleting it. It's yet another flag no one knows about or uses. Could we just use CollectedHeap::total_collections as a counter guard for triggering the code, i.e. do a full verification or the sort order if the value changes? If we do that, I'd be fine with the spot verification you added on insert. If that won't work I guess putting it under a flag is acceptable. tom On Aug 6, 2009, at 2:15 PM, John Coomes wrote: > Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) wrote: >> (Please take my comments with the requisite dose of salt because >> i know little about these CIObjects, so i may be talking nonsense >> in this context :-) >> >> How big could the (unified) table get? (Clearly in the case of the >> test that >> brought forth the problem it must become quite large, but perhaps >> that's >> an extreme case.) Still, I'd be wary of anything that >> requires a large table re-sort at each full gc, let alone at each >> scavenge... >> (BTW, what do you do with non-perm stuff today where order is not >> preserved >> across GCs? why not do that for all objects rather than rely on >> ordering >> for the perm subset?) Of course, if the table is small, may be my >> concern is moot. > > FWIW, the current table gets to a little over 64K elements with my > test case. get() is called 3 times at each value of length (from 1 - > 64K+), and each call does two iterations over the table. It's a lot. > > Long term, I think the GC should notify the CI when perm gen objects > may have been reordered. The CI should just record the notification, > and later re-sort or do whatever is necessary on the next > get()/insert()/whatever. > > As Ramki mentioned, none of our current GCs would have to do this, we > just have to worry about future GCs. I think a reasonable solution > would be to have current GCs do the (unnecessary) notification > whenever perm gen is collected in debug builds. That would exercise > the code without excessive overhead, and also document the dependency > in the code. I would expect a new collector to start by cloning an > existing collector. > > In the short-term, I just want to be able to check in my test case. > How about if I restore the debugging code, but put it under control of > the CIObjectFactoryVerify option? > > I'll also file a bug to capture the comments. > > -John > >> On 08/06/09 11:36, Tom Rodriguez wrote: >>>>>> Would it be possible to put the check into the GC epilogue? >>>>>> Probably not, since ciEnv guys are not statically allocated and >>>>>> not >>>>>> easy to enumerate (one per active compile-thread task). I >>>>>> guess I >>>>>> do like the idea of checking a GC tick counter from the CI, to >>>>>> throttle the paranoid check. Best of all would be to have some >>>>>> explicit linkage from the GC epilogue code to the CI, which >>>>>> somehow >>>>>> documents and enforces the order invariance. You can see why >>>>>> this >>>>>> is awkward: It is an invariant shared by the CI and the GC. >>>> >>>> Yes, i agree, if it's one per active compile task, may be it's >>>> best to >>>> use >>>> yr strategy of eliding the check unless the full gc count changes. >>> >>> John, couldn't this strategy allow us to reunify the handling of >>> oops >>> into a single table instead of needing the NonPermOop stuff? If we >>> simply re-sort the table when needed that code becomes simple >>> again. It >>> also makes us impervious to reordering concerns. >>> >>> tom >>> >>>> >>>> -- ramki >>>> >>>>> -- John >>>> >>> >> > From John.Rose at Sun.COM Thu Aug 6 14:44:55 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 06 Aug 2009 14:44:55 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <19067.18410.306822.942873@sun.com> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B28CA.30806@Sun.COM> <19067.18410.306822.942873@sun.com> Message-ID: <29DCB7D3-F0F2-40C1-ABCB-3F826719E089@sun.com> On Aug 6, 2009, at 2:15 PM, John Coomes wrote: > In the short-term, I just want to be able to check in my test case. > How about if I restore the debugging code, but put it under control of > the CIObjectFactoryVerify option? > > I'll also file a bug to capture the comments. Good. I very much like Tom/Keith/Ramki's suggestions of simplifying the code and reducing perm. distinctions. This internal CI simplification is a natural add-on to my nonperm-6863023 work. Shall I roll it in, or make a separate bug? -- John From Y.S.Ramakrishna at Sun.COM Thu Aug 6 15:39:07 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Thu, 06 Aug 2009 15:39:07 -0700 Subject: request for review (m): 4957990: Perm heap bloat in JVM In-Reply-To: References: <4A789E4C.20109@Sun.COM> <4A78A5DB.3040901@Sun.COM> <4A78E69C.4030604@sun.com> <4A78EDE3.1090703@sun.com> <4A7920B1.7010301@sun.com> <0AA576C1-BA1B-40EF-8ABA-B088C47E3D7B@sun.com> <4A79DBCF.6060506@Sun.COM> <4A79FF45.8060101@sun.com> <4A7A0D33.8030700@Sun.COM> <4A7A1232.7080802@Sun.COM> <287E57C2-5D3D-45C7-87C0-BBB1F5F6212D@Sun.COM> <4A7A17FB.20606@Sun.COM> <4A7A1C81.3020508@Sun.COM> <4A9428BE-AA39-49E7-B948-87650AC3A7B6@sun.com> <4A7A73E8.4020008@sun.com> Message-ID: <4A7B5B8B.6080001@Sun.COM> On 08/06/09 14:28, Tom Rodriguez wrote: > > On Aug 5, 2009, at 11:10 PM, Y. Srinivas Ramakrishna wrote: > >> Tom Rodriguez wrote: >>> After I wrote this I realized that this is a natural out growth of >>> your fix. Without profiling information an nmethod should only refer >>> to types which are statically reachable. Having the MDO act as a >>> strong root would keep the nmethod from getting unloaded when using >>> predicted call sites. Once the MDO is a weak root then the nmethod >>> could want to be unloaded. I guess without your fix CHA could >>> produce a case where an OSR nmethod would be unloaded without being >>> unlinked from the OSR nmethod list but I'd have to think about that >>> more. >> >> So, Tom, is my understanding correct that the criteria for unloading >> of the nmethod are not too >> weak. Do you suggest that make_unloaded should just go unlink the >> nmethod from the osr list? >> I'll give that a try tonight and update later on how that looks wrt >> the current test, >> but let me know if i am misunderstanding and that would not be the >> correct way to >> fix this problem, Bummer! The "fix", of removing the osr method (and marking it non-entrant) when GC decides to unload it, was working really nicely with this test! (I was in the midst of running more extensive tests.) I was hoping you'd bless it! > > We can't allow the sweeper to free an nmethod unless we are certain that > it's impossible for new activations of that nmethod to form. Note this > comment: > > void nmethod::make_not_entrant_or_zombie(int state) { > assert(state == zombie || state == not_entrant, "must be zombie or > not_entrant"); > > // Code for an on-stack-replacement nmethod is removed when a class > gets unloaded. > // They never become zombie/non-entrant, so the nmethod sweeper will > never remove > // them. Instead the entry_bci is set to InvalidOSREntryBci, so the > osr nmethod > // will never be used anymore. That the nmethods only gets removed > when class unloading > // happens, make life much simpler, since the nmethods are not just > going to disappear > // out of the blue. > > So I don't think reclamation of OSR nmethods in the current code is > safe. I do believe that OSR nmethods could be reclaimed like other > normal nmethods and I have an old webrev that illustrates this at > http://javaweb.sfbay.sun.com/~never/webrev/osr. I think that the > changes in the assembly code are unneeded since the requirement we're > trying to enforce is that if an OSR nmethod becomes unloaded at a > safepoint it won't be used for form a new activation which is > accomplished by the interpeterRuntime.cpp changes. I'm not sure we want > to include the reclaiming of OSR nmethods into hs16 at this point. So > maybe OSR nmethods need to act as strong roots for now? I agree that it is too close to hs16b01 for this. However, we have a few weeks more for hs16, so i think this is a good opportunity to include the long-term fix of reclaiming OSR nmethods along the lines of yr webrev above and to roll it in with 4957990. If it passes muster we could consider putting it in hs16b2. I'll take this up with you offline. IMHO, I see little point in the interim step of making OSR methods always act as strong roots and never become eligible for reclamation. Naively, that would see to me to be almost worse than the original problem we were trying to fix in 4957990. -- ramki > > tom > >> >> thanks! >> -- ramki >>> >>> tom >>> >>> On Aug 5, 2009, at 6:15 PM, Tom Rodriguez wrote: >>> >>>> My understanding was that OSR nmethods could/should only be >>>> reclaimed once the klass of their holder was unloaded. The reason >>>> for this is that the normal not_entrant sweeping logic isn't >>>> implemented safely for OSR methods so the sweeper can't safely >>>> reclaim them. If the klass itself is being reclaimed then it should >>>> be safe to reclaim the OSR nmethods. It's possible that we have a >>>> hole in the logic which doesn't account for dealing with unloaded >>>> OSR methods properly and you changes just make it more likely to >>>> happen. We either need to close the not_entrant hole for OSR >>>> nmethods, which isn't that hard, and then correct >>>> nmethod::make_unloaded to unlink the OSR nmethod or we have to make >>>> do_unloading disallow unloading for OSR nmethods is the methodOop is >>>> strongly reachable. >>>> >>>> tom >>>> >>>> On Aug 5, 2009, at 4:57 PM, Y.S.Ramakrishna at Sun.COM wrote: >>>> >>>>> >>>>> Can there be a situation where an osr nmethod associated >>>>> with a method oop gets unloaded while the method and its >>>>> class are still alive? I see that happening with my workspace >>>>> with the changes for 4957990 (yet to figure out why the osr >>>>> nmethod was unloaded). >>>>> >>>>> Shortly after said unload, the sweeper flushes the nmethod, >>>>> but the nmethod is still left linked off of the klass's >>>>> _osr_nmethod_head >>>>> list, and a subsequent invocation counter overflow at a bci does >>>>> an osr nmethod lookup and falls foul of the flushed nmethod left >>>>> in the instanceKlass's osr nmethod head. >>>>> >>>>> So I have two questions: >>>>> >>>>> (a) can an osr nmethod be unloaded while its klass is still alive ? >>>>> (b) if the answer to (a) is yes, then we need to take special steps >>>>> (not present in current code) to unlink said nmethod from the >>>>> list of osr nmethods in its klass. >>>>> >>>>> Am I making sense? Otherwise i can provide more direct detail. >>>>> (I am still digging to find out why we decided to unload the >>>>> nmethod and will have more follow-up info in a subsequent email.) >>>>> >>>>> thanks. >>>>> -- ramki >>>> >>> >> > From thomas.rodriguez at sun.com Thu Aug 6 16:13:21 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 06 Aug 2009 23:13:21 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6868051: (SA) FreeChunk support for compressed oops is broken Message-ID: <20090806231327.06927E542@hg.openjdk.java.net> Changeset: ef671fb22f73 Author: never Date: 2009-08-06 12:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ef671fb22f73 6868051: (SA) FreeChunk support for compressed oops is broken Reviewed-by: kvn, dcubed ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeChunk.java From john.rose at sun.com Thu Aug 6 19:48:43 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 07 Aug 2009 02:48:43 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090807024855.4A100E608@hg.openjdk.java.net> Changeset: bd2b1f617a4e Author: jrose Date: 2009-08-06 14:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bd2b1f617a4e 6868487: EnableInvokeDynamic and EnableMethodHandles should not be visible flags in JDK6 or JDK7 Summary: switch them from product to experimental; 6817525 will toggle them and switch to diagnostic Reviewed-by: kvn ! src/share/vm/runtime/globals.hpp Changeset: 9c65a08a31a3 Author: jrose Date: 2009-08-06 16:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9c65a08a31a3 Merge From john.coomes at sun.com Thu Aug 6 21:48:26 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Aug 2009 04:48:26 +0000 Subject: hg: jdk7/hotspot-comp: 4 new changesets Message-ID: <20090807044827.4ACCAE69F@hg.openjdk.java.net> Changeset: 59c202ab8a94 Author: jjg Date: 2009-07-27 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/59c202ab8a94 6854244: change source/target used to compile JDK to 7 Reviewed-by: ohair ! make/README.pre-components Changeset: fbc75d7ed6dc Author: tbell Date: 2009-07-27 23:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/fbc75d7ed6dc Merge Changeset: e1b972ff53cd Author: tbell Date: 2009-07-30 23:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/e1b972ff53cd Merge Changeset: 82e6c820c51a Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/82e6c820c51a Added tag jdk7-b68 for changeset e1b972ff53cd ! .hgtags From john.coomes at sun.com Thu Aug 6 21:55:10 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Aug 2009 04:55:10 +0000 Subject: hg: jdk7/hotspot-comp/corba: 4 new changesets Message-ID: <20090807045514.E1B2CE6A4@hg.openjdk.java.net> Changeset: 2a160e4e0d06 Author: jjg Date: 2009-07-27 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/2a160e4e0d06 6854244: change source/target used to compile JDK to 7 Reviewed-by: ohair ! make/Makefile ! make/common/shared/Defs-java.gmk Changeset: ad500347ebc8 Author: tbell Date: 2009-07-27 23:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/ad500347ebc8 Merge Changeset: 5182bcc9c60c Author: tbell Date: 2009-07-30 23:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/5182bcc9c60c Merge ! make/Makefile ! make/common/shared/Defs-java.gmk Changeset: 8120d308ec4e Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/8120d308ec4e Added tag jdk7-b68 for changeset 5182bcc9c60c ! .hgtags From john.coomes at sun.com Thu Aug 6 22:06:19 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Aug 2009 05:06:19 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 4 new changesets Message-ID: <20090807050626.77F0AE6A9@hg.openjdk.java.net> Changeset: 59cdcbf2c10d Author: jjg Date: 2009-07-27 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/59cdcbf2c10d 6854244: change source/target used to compile JDK to 7 Reviewed-by: ohair ! make/build.properties Changeset: ef9c2dee8a40 Author: tbell Date: 2009-07-27 23:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/ef9c2dee8a40 Merge Changeset: 83b2a9331383 Author: tbell Date: 2009-07-30 23:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/83b2a9331383 Merge ! make/build.properties Changeset: a4ab0d6ded63 Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/a4ab0d6ded63 Added tag jdk7-b68 for changeset 83b2a9331383 ! .hgtags From john.coomes at sun.com Thu Aug 6 22:12:25 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Aug 2009 05:12:25 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 4 new changesets Message-ID: <20090807051232.60EB7E6AE@hg.openjdk.java.net> Changeset: c5dfd37d18a0 Author: jjg Date: 2009-07-27 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/c5dfd37d18a0 6854244: change source/target used to compile JDK to 7 Reviewed-by: ohair ! make/build.properties Changeset: a98e41351006 Author: tbell Date: 2009-07-27 23:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/a98e41351006 Merge Changeset: 845fa487f0f7 Author: tbell Date: 2009-07-30 23:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/845fa487f0f7 Merge ! make/build.properties Changeset: 3e64fdfb9291 Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/3e64fdfb9291 Added tag jdk7-b68 for changeset 845fa487f0f7 ! .hgtags From john.coomes at sun.com Thu Aug 6 22:20:31 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Aug 2009 05:20:31 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 45 new changesets Message-ID: <20090807053439.68E38E6B3@hg.openjdk.java.net> Changeset: aaf0cb20646e Author: darcy Date: 2009-07-15 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/aaf0cb20646e 6857789: (reflect) Create common superclass of reflective exceptions Reviewed-by: martin ! src/share/classes/java/lang/ClassNotFoundException.java ! src/share/classes/java/lang/IllegalAccessException.java ! src/share/classes/java/lang/InstantiationException.java ! src/share/classes/java/lang/NoSuchFieldException.java ! src/share/classes/java/lang/NoSuchMethodException.java + src/share/classes/java/lang/ReflectiveOperationException.java ! src/share/classes/java/lang/reflect/InvocationTargetException.java Changeset: 2a1b1075f583 Author: darcy Date: 2009-07-15 14:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2a1b1075f583 6463998: Undocumented NullPointerExeption from Float.parseFloat and Double.parseDouble Reviewed-by: lancea, iris ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java Changeset: 3acfd7c1f984 Author: tbell Date: 2009-07-17 09:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3acfd7c1f984 Merge Changeset: 1203425b5742 Author: mullan Date: 2009-07-20 17:16 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1203425b5742 6787645: CRL validation code should permit some clock skew when checking validity of CRLs Reviewed-by: vinnie ! src/share/classes/java/security/cert/CertPathHelperImpl.java ! src/share/classes/java/security/cert/X509CRLSelector.java ! src/share/classes/sun/security/provider/certpath/CertPathHelper.java ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 81e3117803a5 Author: weijun Date: 2009-07-22 16:39 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/81e3117803a5 6858589: more changes to Config on system properties Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! test/sun/security/krb5/ConfPlusProp.java Changeset: 8bb89d9fd061 Author: weijun Date: 2009-07-22 16:40 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8bb89d9fd061 6847026: keytool should be able to generate certreq and cert without subject name Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/keytool/emptysubject.sh Changeset: f4f55c2473b6 Author: weijun Date: 2009-07-22 16:40 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f4f55c2473b6 6854308: more ktab options Reviewed-by: mullan ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java Changeset: 29b076bfeafd Author: weijun Date: 2009-07-22 16:41 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/29b076bfeafd 6561126: keytool should use larger default keysize for keypairs Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/jarsigner/newsize7.sh + test/sun/security/tools/keytool/NewSize7.java Changeset: dba7dc47b78e Author: poonam Date: 2009-07-22 07:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dba7dc47b78e 6814140: deadlock due to synchronized demandLogger() code that locks ServerLogManager Summary: Making demandLogger() non-synchronized resolves the deadlock. Reviewed-by: dcubed ! src/share/classes/java/util/logging/LogManager.java Changeset: 645c1d0b9db9 Author: chegar Date: 2009-07-23 14:06 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/645c1d0b9db9 6863110: Newly connected/accepted SctpChannel should fire OP_READ if registered with a Selector Reviewed-by: jccollet ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java ! src/solaris/native/sun/nio/ch/SctpChannelImpl.c + test/com/sun/nio/sctp/SctpChannel/CommUp.java ! test/com/sun/nio/sctp/SctpMultiChannel/Branch.java ! test/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java Changeset: cd7758c85d13 Author: valeriep Date: 2009-07-22 17:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cd7758c85d13 6823905: crash in sun.security.pkcs11.wrapper.PKCS11.C_Sign during stress-test Summary: Initialize relevant return value to NULL Reviewed-by: vinnie ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h Changeset: 4b287af811ba Author: valeriep Date: 2009-07-23 12:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4b287af811ba Merge Changeset: abb221aa23e4 Author: martin Date: 2009-07-24 18:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/abb221aa23e4 6639443: Character.toCodePoint and Character.toSurrogates can be optimized Summary: rearranging code saves 5 bytes of bytecode Reviewed-by: sherman ! src/share/classes/java/lang/Character.java Changeset: e749fe2ed114 Author: martin Date: 2009-07-24 18:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e749fe2ed114 6639458: Improvements to Surrogate.java Summary: Optimize Surrogate.java Reviewed-by: sherman ! src/share/classes/sun/nio/cs/Surrogate.java Changeset: d78bfd73ee42 Author: xuelei Date: 2009-07-27 22:04 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d78bfd73ee42 6449574: Invalid ldap filter is accepted and processed Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/Filter.java + test/com/sun/jndi/ldap/BalancedParentheses.java Changeset: 3eb4506815b6 Author: alanb Date: 2009-07-27 18:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3eb4506815b6 6863864: (fs) Path.createSymbolicLink doesn't set directory flag when creating sym link to directory (win) Reviewed-by: sherman ! src/windows/classes/sun/nio/fs/WindowsPath.java ! test/java/nio/file/Path/Links.java Changeset: 6fcddeeadd8c Author: alanb Date: 2009-07-27 18:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6fcddeeadd8c 6863667: (ch) Several tests in java/nio/channels/* need to be updated after 6638712 Reviewed-by: mcimadamore ! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java ! test/java/nio/channels/AsynchronousChannelGroup/Identity.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java ! test/java/nio/channels/AsynchronousDatagramChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java Changeset: 74c4b8c743fb Author: alanb Date: 2009-07-27 19:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/74c4b8c743fb 6864319: (fs) Eliminate static dependency on fdopendir (lnx) Reviewed-by: martin ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c Changeset: 15878be84b9d Author: jjg Date: 2009-07-27 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/15878be84b9d 6854244: change source/target used to compile JDK to 7 Reviewed-by: ohair ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk ! make/java/dyn/Makefile Changeset: 056c8e724015 Author: xuelei Date: 2009-07-28 11:15 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/056c8e724015 6865482: test case BalancedParentheses.java is missing GPL header. Reviewed-by: weijun ! test/com/sun/jndi/ldap/BalancedParentheses.java Changeset: aed3ce4ba35b Author: tbell Date: 2009-07-27 23:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/aed3ce4ba35b Merge Changeset: 03b4ab24cd2a Author: jjg Date: 2009-07-29 12:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/03b4ab24cd2a 6865753: 6854244 breaks partial (jdk-only) builds Summary: Makefiles which set -target 5 now need to set -source 5 as well. Reviewed-by: wetmore, tbell ! make/com/sun/crypto/provider/Makefile ! make/javax/crypto/Makefile Changeset: 18fee5159090 Author: tbell Date: 2009-07-30 23:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/18fee5159090 Merge Changeset: f214db928124 Author: art Date: 2009-07-17 15:40 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f214db928124 6844297: java/awt/EventQueue/6638195/bug6638195.java test failed in jdk7 on Windows just on b59,passed on b57 Reviewed-by: bchristi, dcherepanov ! test/java/awt/EventQueue/6638195/bug6638195.java Changeset: 29a065ef8341 Author: dcherepanov Date: 2009-07-22 13:00 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/29a065ef8341 6859935: REGRESSION: Settings are missing in JCP/Advanced tab on windows Reviewed-by: art ! src/windows/classes/sun/awt/windows/WToolkit.java Changeset: ab4860d7cf28 Author: anthony Date: 2009-07-23 13:46 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ab4860d7cf28 6848424: java/awt/Frame/FrameSize/TestFrameSize.java needs improvement Summary: The test now thoroughly verifies the pack() method Reviewed-by: art, dcherepanov ! test/java/awt/Frame/FrameSize/TestFrameSize.java Changeset: 045c3f367b06 Author: dcherepanov Date: 2009-07-27 15:37 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/045c3f367b06 6856929: Frame is not getting resized using Robot in OpenSolaris and Ubuntu Reviewed-by: art, dav ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/native/sun/awt/awt_Robot.c Changeset: 2fb41bc4d896 Author: yan Date: 2009-07-27 23:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2fb41bc4d896 Merge Changeset: dfd0f4b7c7d1 Author: yan Date: 2009-07-29 00:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dfd0f4b7c7d1 Merge Changeset: b624f8613cc6 Author: gsm Date: 2009-07-15 19:05 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b624f8613cc6 6612541: api/javax_swing/text/LabelView/index.html#getXXX[LabelView0004] fails since JDK 7 b20 Reviewed-by: peterz ! src/share/classes/javax/swing/text/GlyphView.java Changeset: f727cac13697 Author: malenkov Date: 2009-07-16 20:12 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f727cac13697 6505027: terminateEditOnFocusLost making problems for table in JDesktopPane Reviewed-by: alexp ! src/share/classes/javax/swing/JInternalFrame.java + test/javax/swing/JInternalFrame/Test6505027.java Changeset: 59249ab7aa16 Author: peterz Date: 2009-07-17 15:25 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/59249ab7aa16 6387360: Usage of package-private class as a parameter of a method (javax.swing.text.ParagraphView) Reviewed-by: malenkov ! src/share/classes/javax/swing/text/ParagraphView.java Changeset: 4575323d917c Author: peterz Date: 2009-07-20 13:33 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4575323d917c 6857360: NimbusLAF: Menu indicator looks ugly with RTL orientation. Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/nimbus/NimbusIcon.java ! src/share/classes/sun/swing/MenuItemLayoutHelper.java Changeset: a2114bbf7f3e Author: peterz Date: 2009-07-20 13:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a2114bbf7f3e 6849331: Nimbus L&F: AbstractRegionPainter's paint context is not initialized Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java Changeset: 125eff6f653f Author: malenkov Date: 2009-07-22 12:21 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/125eff6f653f 6802868: JInternalFrame is not maximized when maximized parent frame. Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java + test/javax/swing/JInternalFrame/Test6802868.java Changeset: 9fc588f78952 Author: rupashka Date: 2009-07-23 17:56 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9fc588f78952 6460525: javax/swing/JFileChooser/6396844/TwentyThousandTest.java times out Reviewed-by: malenkov, peterz ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/sun/awt/shell/ShellFolder.java ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/share/classes/sun/swing/FilePane.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java Changeset: 5054103dc032 Author: naoto Date: 2009-06-30 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5054103dc032 6852429: IME should call ImmIsUIMessage() or DefWindowProc() when it receives WM_IME_SETCONTEX Reviewed-by: peytoia ! src/windows/native/sun/windows/awt_Component.cpp Changeset: 584fe3163de9 Author: naoto Date: 2009-07-23 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/584fe3163de9 Merge - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - src/share/classes/sun/swing/AccessibleMethod.java ! src/windows/native/sun/windows/awt_Component.cpp - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: 80d076251250 Author: yan Date: 2009-07-27 03:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/80d076251250 Merge Changeset: 0ab4157789d9 Author: malenkov Date: 2009-07-28 13:10 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0ab4157789d9 6864297: Right-to-left oriented JScrollPane is aligned to the wrong direction while resizing the container Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java + test/javax/swing/JScrollPane/Test6526631.java + test/javax/swing/SwingTest.java Changeset: 425fcb6d8af4 Author: yan Date: 2009-07-29 00:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/425fcb6d8af4 Merge - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java Changeset: a48b0984ef2e Author: yan Date: 2009-08-05 00:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a48b0984ef2e Merge - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java Changeset: fe61ef5aada9 Author: wetmore Date: 2009-08-03 18:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fe61ef5aada9 6647452: Remove obfuscation, framework and provider self-verification checking Reviewed-by: valeriep, vinnie ! make/com/sun/crypto/provider/Makefile ! make/javax/crypto/Defs-jce.gmk ! make/javax/crypto/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! src/share/classes/com/sun/crypto/provider/AESCipher.java ! src/share/classes/com/sun/crypto/provider/AESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/AESWrapCipher.java ! src/share/classes/com/sun/crypto/provider/ARCFOURCipher.java ! src/share/classes/com/sun/crypto/provider/BlowfishCipher.java ! src/share/classes/com/sun/crypto/provider/BlowfishKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESCipher.java ! src/share/classes/com/sun/crypto/provider/DESKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeCipher.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/com/sun/crypto/provider/DHKeyFactory.java ! src/share/classes/com/sun/crypto/provider/HmacCore.java ! src/share/classes/com/sun/crypto/provider/HmacMD5.java ! src/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java - src/share/classes/com/sun/crypto/provider/JarVerifier.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/PBEKeyFactory.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBKDF2HmacSHA1Factory.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/RC2Cipher.java ! src/share/classes/com/sun/crypto/provider/RSACipher.java ! src/share/classes/com/sun/crypto/provider/SslMacCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsRsaPremasterSecretGenerator.java ! src/share/classes/javax/crypto/JarVerifier.java ! src/share/classes/javax/crypto/JceSecurity.java - src/share/classes/sun/security/pkcs11/JarVerifier.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java - src/windows/classes/sun/security/mscapi/JarVerifier.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java Changeset: b23d905cb5d3 Author: xdono Date: 2009-08-05 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b23d905cb5d3 Merge - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java Changeset: 9ae4027c5fe1 Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9ae4027c5fe1 Added tag jdk7-b68 for changeset b23d905cb5d3 ! .hgtags From john.coomes at sun.com Thu Aug 6 22:50:00 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Aug 2009 05:50:00 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 12 new changesets Message-ID: <20090807055022.6FCBDE6C8@hg.openjdk.java.net> Changeset: ad07b7ea9685 Author: mcimadamore Date: 2009-07-15 10:25 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ad07b7ea9685 6846972: cannot access member of raw type when erasure change overriding into overloading Summary: fix of 6400189 caused a nasty problem in method resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/rawOverride/T6846972.java Changeset: 90d40dd5cfc7 Author: mcimadamore Date: 2009-07-15 17:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/90d40dd5cfc7 6860795: NullPointerException when compiling a negative java source Summary: Rich formatter shouldn't propagate visits on method symbols that have a null type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/Diagnostics/6860795/T6860795.java + test/tools/javac/Diagnostics/6860795/T6860795.out Changeset: 86ad2753f3be Author: tbell Date: 2009-07-17 09:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/86ad2753f3be Merge Changeset: 99b7a25185aa Author: jjg Date: 2009-07-23 11:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/99b7a25185aa 6863814: javap crashes when facing array class literals Reviewed-by: jjg Contributed-by: mali at csail.mit.edu ! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java + test/tools/javap/typeAnnotations/ArrayClassLiterals.java Changeset: 49387c1440d0 Author: jjg Date: 2009-07-23 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/49387c1440d0 6863914: bug number missing from test Reviewed-by: tbell ! test/tools/javap/typeAnnotations/ArrayClassLiterals.java Changeset: 631425840408 Author: jjg Date: 2009-07-24 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/631425840408 6863746: javap should not scan ct.sym by default Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/JavapFileManager.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java + test/tools/javap/T6863746.java Changeset: d043adadc8b6 Author: darcy Date: 2009-07-26 21:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d043adadc8b6 6381698: Warn of decommissioning of apt Reviewed-by: jjg ! make/build.properties ! src/share/classes/com/sun/mirror/apt/AnnotationProcessor.java ! src/share/classes/com/sun/mirror/apt/AnnotationProcessorEnvironment.java ! src/share/classes/com/sun/mirror/apt/AnnotationProcessorFactory.java ! src/share/classes/com/sun/mirror/apt/AnnotationProcessorListener.java ! src/share/classes/com/sun/mirror/apt/AnnotationProcessors.java ! src/share/classes/com/sun/mirror/apt/Filer.java ! src/share/classes/com/sun/mirror/apt/Messager.java ! src/share/classes/com/sun/mirror/apt/RoundCompleteEvent.java ! src/share/classes/com/sun/mirror/apt/RoundCompleteListener.java ! src/share/classes/com/sun/mirror/apt/RoundState.java + src/share/classes/com/sun/mirror/apt/package-info.java - src/share/classes/com/sun/mirror/apt/package.html ! src/share/classes/com/sun/mirror/declaration/AnnotationMirror.java ! src/share/classes/com/sun/mirror/declaration/AnnotationTypeDeclaration.java ! src/share/classes/com/sun/mirror/declaration/AnnotationTypeElementDeclaration.java ! src/share/classes/com/sun/mirror/declaration/AnnotationValue.java ! src/share/classes/com/sun/mirror/declaration/ClassDeclaration.java ! src/share/classes/com/sun/mirror/declaration/ConstructorDeclaration.java ! src/share/classes/com/sun/mirror/declaration/Declaration.java ! src/share/classes/com/sun/mirror/declaration/EnumConstantDeclaration.java ! src/share/classes/com/sun/mirror/declaration/EnumDeclaration.java ! src/share/classes/com/sun/mirror/declaration/ExecutableDeclaration.java ! src/share/classes/com/sun/mirror/declaration/FieldDeclaration.java ! src/share/classes/com/sun/mirror/declaration/InterfaceDeclaration.java ! src/share/classes/com/sun/mirror/declaration/MemberDeclaration.java ! src/share/classes/com/sun/mirror/declaration/MethodDeclaration.java ! src/share/classes/com/sun/mirror/declaration/Modifier.java ! src/share/classes/com/sun/mirror/declaration/PackageDeclaration.java ! src/share/classes/com/sun/mirror/declaration/ParameterDeclaration.java ! src/share/classes/com/sun/mirror/declaration/TypeDeclaration.java ! src/share/classes/com/sun/mirror/declaration/TypeParameterDeclaration.java + src/share/classes/com/sun/mirror/declaration/package-info.java - src/share/classes/com/sun/mirror/declaration/package.html ! src/share/classes/com/sun/mirror/type/AnnotationType.java ! src/share/classes/com/sun/mirror/type/ArrayType.java ! src/share/classes/com/sun/mirror/type/ClassType.java ! src/share/classes/com/sun/mirror/type/DeclaredType.java ! src/share/classes/com/sun/mirror/type/EnumType.java ! src/share/classes/com/sun/mirror/type/InterfaceType.java ! src/share/classes/com/sun/mirror/type/MirroredTypeException.java ! src/share/classes/com/sun/mirror/type/MirroredTypesException.java ! src/share/classes/com/sun/mirror/type/PrimitiveType.java ! src/share/classes/com/sun/mirror/type/ReferenceType.java ! src/share/classes/com/sun/mirror/type/TypeMirror.java ! src/share/classes/com/sun/mirror/type/TypeVariable.java ! src/share/classes/com/sun/mirror/type/VoidType.java ! src/share/classes/com/sun/mirror/type/WildcardType.java + src/share/classes/com/sun/mirror/type/package-info.java - src/share/classes/com/sun/mirror/type/package.html ! src/share/classes/com/sun/mirror/util/DeclarationFilter.java ! src/share/classes/com/sun/mirror/util/DeclarationScanner.java ! src/share/classes/com/sun/mirror/util/DeclarationVisitor.java ! src/share/classes/com/sun/mirror/util/DeclarationVisitors.java ! src/share/classes/com/sun/mirror/util/Declarations.java ! src/share/classes/com/sun/mirror/util/SimpleDeclarationVisitor.java ! src/share/classes/com/sun/mirror/util/SimpleTypeVisitor.java ! src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java ! src/share/classes/com/sun/mirror/util/SourcePosition.java ! src/share/classes/com/sun/mirror/util/TypeVisitor.java ! src/share/classes/com/sun/mirror/util/Types.java + src/share/classes/com/sun/mirror/util/package-info.java - src/share/classes/com/sun/mirror/util/package.html ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/comp/BootstrapAPF.java ! src/share/classes/com/sun/tools/apt/comp/PrintAP.java ! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/apt/mirror/AptEnv.java ! src/share/classes/com/sun/tools/apt/mirror/apt/AnnotationProcessorEnvironmentImpl.java ! src/share/classes/com/sun/tools/apt/mirror/apt/FilerImpl.java ! src/share/classes/com/sun/tools/apt/mirror/apt/MessagerImpl.java ! src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java ! src/share/classes/com/sun/tools/apt/mirror/apt/RoundStateImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationMirrorImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeElementDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/ClassDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/ConstructorDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationMaker.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/EnumConstantDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/EnumDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/ExecutableDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/FieldDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/InterfaceDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/MemberDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/MethodDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/PackageDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/ParameterDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/TypeDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/TypeParameterDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/AnnotationTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/ArrayTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/ClassTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/DeclaredTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/EnumTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/InterfaceTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/PrimitiveTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeMaker.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/VoidTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/WildcardTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/util/DeclarationsImpl.java ! src/share/classes/com/sun/tools/apt/mirror/util/SourcePositionImpl.java ! src/share/classes/com/sun/tools/apt/mirror/util/TypesImpl.java ! src/share/classes/com/sun/tools/apt/resources/apt.properties ! test/tools/apt/Basics/apt.sh ! test/tools/apt/Compile/compile.sh Changeset: cf08b64e87da Author: jjg Date: 2009-07-27 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/cf08b64e87da 6854244: change source/target used to compile JDK to 7 Reviewed-by: ohair ! make/build.properties Changeset: 7c2d6da61646 Author: jjg Date: 2009-07-27 19:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/7c2d6da61646 6865399: some javac files are missing Sun internal API comment Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/Formattable.java ! src/share/classes/com/sun/tools/javac/api/Messages.java ! src/share/classes/com/sun/tools/javac/code/BoundKind.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/FSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/RelativePath.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/ForwardingDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Warner.java Changeset: e4ce529b2249 Author: tbell Date: 2009-07-27 23:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e4ce529b2249 Merge - src/share/classes/com/sun/mirror/apt/package.html - src/share/classes/com/sun/mirror/declaration/package.html - src/share/classes/com/sun/mirror/type/package.html - src/share/classes/com/sun/mirror/util/package.html Changeset: 95c1212b07e3 Author: tbell Date: 2009-07-30 23:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/95c1212b07e3 Merge Changeset: ce9bcdcb7859 Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ce9bcdcb7859 Added tag jdk7-b68 for changeset 95c1212b07e3 ! .hgtags From John.Coomes at sun.com Fri Aug 7 13:04:11 2009 From: John.Coomes at sun.com (John Coomes) Date: Fri, 7 Aug 2009 13:04:11 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <29DCB7D3-F0F2-40C1-ABCB-3F826719E089@sun.com> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B28CA.30806@Sun.COM> <19067.18410.306822.942873@sun.com> <29DCB7D3-F0F2-40C1-ABCB-3F826719E089@sun.com> Message-ID: <19068.35003.68002.631632@sun.com> John Rose (John.Rose at Sun.COM) wrote: > On Aug 6, 2009, at 2:15 PM, John Coomes wrote: > > > In the short-term, I just want to be able to check in my test case. > > How about if I restore the debugging code, but put it under control of > > the CIObjectFactoryVerify option? > > > > I'll also file a bug to capture the comments. > > Good. I very much like Tom/Keith/Ramki's suggestions of simplifying > the code and reducing perm. distinctions. I interpret this as you're ok with putting the debugging code under control of the option for now, as long as I capture the discussion in a bug so it gets fixed properly. Tom, you didn't like the idea much. Since John is willing to fix it properly--are you ok with it now? > This internal CI simplification is a natural add-on to my > nonperm-6863023 work. Shall I roll it in, or make a separate bug? I'd think of your reviewers--what would be easier for them? IMHO, smaller is usually better. -John From Thomas.Rodriguez at Sun.COM Fri Aug 7 13:08:23 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 07 Aug 2009 13:08:23 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <19068.35003.68002.631632@sun.com> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B28CA.30806@Sun.COM> <19067.18410.306822.942873@sun.com> <29DCB7D3-F0F2-40C1-ABCB-3F826719E089@sun.com> <19068.35003.68002.631632@sun.com> Message-ID: <9A3ED5C6-EEAF-4998-861D-4BAA910DE69A@sun.com> Sure. tom On Aug 7, 2009, at 1:04 PM, John Coomes wrote: > John Rose (John.Rose at Sun.COM) wrote: >> On Aug 6, 2009, at 2:15 PM, John Coomes wrote: >> >>> In the short-term, I just want to be able to check in my test case. >>> How about if I restore the debugging code, but put it under >>> control of >>> the CIObjectFactoryVerify option? >>> >>> I'll also file a bug to capture the comments. >> >> Good. I very much like Tom/Keith/Ramki's suggestions of simplifying >> the code and reducing perm. distinctions. > > I interpret this as you're ok with putting the debugging code under > control of the option for now, as long as I capture the discussion in > a bug so it gets fixed properly. Tom, you didn't like the idea much. > Since John is willing to fix it properly--are you ok with it now? > >> This internal CI simplification is a natural add-on to my >> nonperm-6863023 work. Shall I roll it in, or make a separate bug? > > I'd think of your reviewers--what would be easier for them? IMHO, > smaller is usually better. > > -John > From John.Coomes at sun.com Mon Aug 10 12:28:53 2009 From: John.Coomes at sun.com (John Coomes) Date: Mon, 10 Aug 2009 12:28:53 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <19067.18410.306822.942873@sun.com> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B28CA.30806@Sun.COM> <19067.18410.306822.942873@sun.com> Message-ID: <19072.29941.938228.283288@sun.com> I (John.Coomes at sun.com) wrote: > ... > I'll also file a bug to capture the comments. The new bug is: 6870184 relax ciObjectFactory dependency on perm gen object order Should be visible on bugs.sun.com in a day or so. -John From John.Coomes at sun.com Mon Aug 10 12:32:16 2009 From: John.Coomes at sun.com (John Coomes) Date: Mon, 10 Aug 2009 12:32:16 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <9A3ED5C6-EEAF-4998-861D-4BAA910DE69A@sun.com> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B28CA.30806@Sun.COM> <19067.18410.306822.942873@sun.com> <29DCB7D3-F0F2-40C1-ABCB-3F826719E089@sun.com> <19068.35003.68002.631632@sun.com> <9A3ED5C6-EEAF-4998-861D-4BAA910DE69A@sun.com> Message-ID: <19072.30144.831718.687744@sun.com> Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: > Sure. Ok. I've updated the webrev at http://cr.openjdk.java.net/~jcoomes/6866585-ci-debug/ so the loops over the _ci_objects array in get() and insert() are all under control of the globals.hpp var CIObjectFactoryVerify. -John > On Aug 7, 2009, at 1:04 PM, John Coomes wrote: > > > John Rose (John.Rose at Sun.COM) wrote: > >> On Aug 6, 2009, at 2:15 PM, John Coomes wrote: > >> > >>> In the short-term, I just want to be able to check in my test case. > >>> How about if I restore the debugging code, but put it under > >>> control of > >>> the CIObjectFactoryVerify option? > >>> > >>> I'll also file a bug to capture the comments. > >> > >> Good. I very much like Tom/Keith/Ramki's suggestions of simplifying > >> the code and reducing perm. distinctions. > > > > I interpret this as you're ok with putting the debugging code under > > control of the option for now, as long as I capture the discussion in > > a bug so it gets fixed properly. Tom, you didn't like the idea much. > > Since John is willing to fix it properly--are you ok with it now? > > > >> This internal CI simplification is a natural add-on to my > >> nonperm-6863023 work. Shall I roll it in, or make a separate bug? > > > > I'd think of your reviewers--what would be easier for them? IMHO, > > smaller is usually better. > > > > -John > > > From Vladimir.Kozlov at Sun.COM Tue Aug 11 09:23:06 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 11 Aug 2009 09:23:06 -0700 Subject: Request for reviews (XS): 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop") Message-ID: <4A819AEA.6060603@sun.com> http://cr.openjdk.java.net/~kvn/6869822/webrev.00 Fixed 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop") Problem: The test uses -XX:HeapBaseMinAddress=32g flag to force heap allocation above 32g and get compressed oops with non zero base. In such case the finction Universe::preferred_heap_base() sets narrow_oop_shift to 3 and returns 0 as requested heap address. But with 0 requested address (default memory address request) OS still may allocate small heap bellow 4gb. And this will trigger the assert. Solution: Replace the assert with narrow_oop_shift set to 0. Also use specified on command line HeapBaseMinAddress value as heap base address for the first (from three) request. Reviewed by: Fix verified (y/n): y, bug's tests Other testing: JPRT From Thomas.Rodriguez at Sun.COM Tue Aug 11 09:41:17 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 11 Aug 2009 09:41:17 -0700 Subject: Request for reviews (XS): 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop") In-Reply-To: <4A819AEA.6060603@sun.com> References: <4A819AEA.6060603@sun.com> Message-ID: <7E748B3D-DDF1-40B3-AAC6-C43F13F937F6@sun.com> looks good. tom On Aug 11, 2009, at 9:23 AM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6869822/webrev.00 > > Fixed 6869822: assert(Universe::narrow_oop_shift() == 0,"use > unscaled narrow oop") > > Problem: > The test uses -XX:HeapBaseMinAddress=32g flag to force heap allocation > above 32g and get compressed oops with non zero base. > In such case the finction Universe::preferred_heap_base() sets > narrow_oop_shift to 3 and returns 0 as requested heap address. > But with 0 requested address (default memory address request) OS > still may > allocate small heap bellow 4gb. And this will trigger the assert. > > Solution: > Replace the assert with narrow_oop_shift set to 0. > Also use specified on command line HeapBaseMinAddress value as > heap base address for the first (from three) request. > > Reviewed by: > > Fix verified (y/n): y, bug's tests > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Tue Aug 11 10:01:23 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 11 Aug 2009 10:01:23 -0700 Subject: Request for reviews (XS): 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop") In-Reply-To: <7E748B3D-DDF1-40B3-AAC6-C43F13F937F6@sun.com> References: <4A819AEA.6060603@sun.com> <7E748B3D-DDF1-40B3-AAC6-C43F13F937F6@sun.com> Message-ID: <4A81A3E3.5020600@sun.com> Thanks, Tom Vladimir Tom Rodriguez wrote: > looks good. > > tom > > On Aug 11, 2009, at 9:23 AM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6869822/webrev.00 >> >> Fixed 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled >> narrow oop") >> >> Problem: >> The test uses -XX:HeapBaseMinAddress=32g flag to force heap allocation >> above 32g and get compressed oops with non zero base. >> In such case the finction Universe::preferred_heap_base() sets >> narrow_oop_shift to 3 and returns 0 as requested heap address. >> But with 0 requested address (default memory address request) OS still >> may >> allocate small heap bellow 4gb. And this will trigger the assert. >> >> Solution: >> Replace the assert with narrow_oop_shift set to 0. >> Also use specified on command line HeapBaseMinAddress value as >> heap base address for the first (from three) request. >> >> Reviewed by: >> >> Fix verified (y/n): y, bug's tests >> >> Other testing: >> JPRT >> > From John.Coomes at sun.com Tue Aug 11 10:20:14 2009 From: John.Coomes at sun.com (John Coomes) Date: Tue, 11 Aug 2009 10:20:14 -0700 Subject: Request for reviews (XS): 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop") In-Reply-To: <4A819AEA.6060603@sun.com> References: <4A819AEA.6060603@sun.com> Message-ID: <19073.43086.623127.161958@sun.com> Vladimir Kozlov (Vladimir.Kozlov at Sun.COM) wrote: > > http://cr.openjdk.java.net/~kvn/6869822/webrev.00 > > Fixed 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop") > > Problem: > The test uses -XX:HeapBaseMinAddress=32g flag to force heap allocation > above 32g and get compressed oops with non zero base. > In such case the finction Universe::preferred_heap_base() sets > narrow_oop_shift to 3 and returns 0 as requested heap address. > But with 0 requested address (default memory address request) OS still may > allocate small heap bellow 4gb. And this will trigger the assert. > > Solution: > Replace the assert with narrow_oop_shift set to 0. > Also use specified on command line HeapBaseMinAddress value as > heap base address for the first (from three) request. Looks good, modulo a couple of nits. Add { } for the body of the new if statement. Also the assignment base = NULL on line 776 is redundant (doesn't hurt, though). FWIW, if you put the new if statement towards the top, just after the assert that checks the mode, you wouldn't need the new "base" var. But either way is fine. -John From Thomas.Rodriguez at Sun.COM Tue Aug 11 10:40:19 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 11 Aug 2009 10:40:19 -0700 Subject: for review (L): 6858164: invokedynamic code needs some cleanup (post-6655638) In-Reply-To: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> References: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> Message-ID: <4C6FE1F1-EF30-479F-9974-FDD026F3DF0C@Sun.COM> This all looks fine to me. tom On Jul 23, 2009, at 2:24 AM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/6858164/vm-webrev.01/ > > Summary: These are fixes for method handles proper. > - correctly raises exceptions > - supports safe bitwise "raw" conversions (e.g., int -> void) > - fixes bugs (various, small) revealed by VerifyMethodHandles > - dead code is removed > - debugging support is improved > > Still to follow: > - more bug fixes to the invokedynamic instruction > - runtime simplification for invokedynamic > - compiler support for invokedynamic > - inlining of method handles > - API adjustments that affect the JVM (mainly, removing private > supertypes) > From Vladimir.Kozlov at Sun.COM Tue Aug 11 10:46:01 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 11 Aug 2009 10:46:01 -0700 Subject: Request for reviews (XS): 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop") In-Reply-To: <19073.43086.623127.161958@sun.com> References: <4A819AEA.6060603@sun.com> <19073.43086.623127.161958@sun.com> Message-ID: <4A81AE59.9080907@sun.com> Thank you, John I used your suggestion to move new check up: http://cr.openjdk.java.net/~kvn/6869822/webrev.01 Thanks, Vladimir John Coomes wrote: > Vladimir Kozlov (Vladimir.Kozlov at Sun.COM) wrote: >> Solution: >> Replace the assert with narrow_oop_shift set to 0. >> Also use specified on command line HeapBaseMinAddress value as >> heap base address for the first (from three) request. > > Looks good, modulo a couple of nits. Add { } for the body of the new > if statement. Also the assignment base = NULL on line 776 is > redundant (doesn't hurt, though). > > FWIW, if you put the new if statement towards the top, just after the > assert that checks the mode, you wouldn't need the new "base" var. > But either way is fine. > > -John > From Changpeng.Fang at Sun.COM Tue Aug 11 10:51:39 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Tue, 11 Aug 2009 10:51:39 -0700 Subject: Request for reviews (XS): 6829127: Deoptimization Failure on Specjvm98 _227_mtrt with -XX:+DeoptimizeALot since Hs11 b01 In-Reply-To: <4A819AEA.6060603@sun.com> References: <4A819AEA.6060603@sun.com> Message-ID: <4A81AFAB.9000900@sun.com> http://cr.openjdk.java.net/~cfang/6829127/webrev.00/ Fixed 6829127: Deoptimization Failure on Specjvm98 _227_mtrt with -XX:+DeoptimizeALot since Hs11 b01 Problem: The safepoint blob can be used in methods which are using the non standard control word for optimized float math. However, the non standard control word may leak out to other codes which will cause assertion failure in RegisterSaver::save_live_registers. Solution: We can deopt at a poll point with the non standard control word, so we make the deopt blob to not complain about the non standard word and set the standard control word after restore_result_registers in the deopt blob. Tests: specjvm98, specjvm2008 with -XX:+DeoptimizeALot Thanks, Changpeng From John.Coomes at sun.com Tue Aug 11 11:16:50 2009 From: John.Coomes at sun.com (John Coomes) Date: Tue, 11 Aug 2009 11:16:50 -0700 Subject: Request for reviews (XS): 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop") In-Reply-To: <4A81AE59.9080907@sun.com> References: <4A819AEA.6060603@sun.com> <19073.43086.623127.161958@sun.com> <4A81AE59.9080907@sun.com> Message-ID: <19073.46482.488506.411389@sun.com> Vladimir Kozlov (Vladimir.Kozlov at Sun.COM) wrote: > Thank you, John > > I used your suggestion to move new check up: > > http://cr.openjdk.java.net/~kvn/6869822/webrev.01 Looks good to me. -John > John Coomes wrote: > > Vladimir Kozlov (Vladimir.Kozlov at Sun.COM) wrote: > >> Solution: > >> Replace the assert with narrow_oop_shift set to 0. > >> Also use specified on command line HeapBaseMinAddress value as > >> heap base address for the first (from three) request. > > > > Looks good, modulo a couple of nits. Add { } for the body of the new > > if statement. Also the assignment base = NULL on line 776 is > > redundant (doesn't hurt, though). > > > > FWIW, if you put the new if statement towards the top, just after the > > assert that checks the mode, you wouldn't need the new "base" var. > > But either way is fine. > > > > -John > > From Thomas.Rodriguez at Sun.COM Tue Aug 11 11:31:08 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 11 Aug 2009 11:31:08 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> Message-ID: <7575205F-F595-4348-A57F-B226AADBEB50@sun.com> I don't really like the non_perm naming being baked into this. I expect at some point we'll want/need to fix this to have a more refined notion of whether the GC needs to scan the nmethods that won't be based on is_perm. I expect that a lot of nmethods will start ending up on the list and scanning a significant portion of the code cache twice for every scavenge seems like an overhead we'd want to avoid. Maybe scavengeable or some other more descriptive but less specific term would be better. If the GC interface provided a BoolObjectClosure to identify scavengable oops then we could use that to easily distinguish which ones need to be scanned. Minor nit: In the ad files could you write all the asserts in the same way: + assert(oop(d64)->is_oop() && (NonPermCodeRefs || oop(d64)->is_perm()), ciObject.cpp: I don't think I get the distinction between has_encoding and should_be_constant. I always thought has_encoding was a stupid name. Maybe has_encoding should be can_be_embedded and should_be_constant -> should_be_embedded. I guess should_be_constant is ok but then has_encoding should be can_be_constant. The relationship between these two should be clearer. What's the plan for this? I think we want to pick a default and stick with it. codecache.cpp: why isn't the logic for drop_non_perm_nmethod part of nmethod::flush instead of being buried in CodeCache::free? nmethod.hpp: The enum names shouldn't look like variable declarations. Remove the underscore. + enum { _npl_on_list = 0x01, _npl_marked = 0x10 }; nmethod.cpp: There are quite a few returns here... +bool nmethod::detect_non_perm_oops() { + DetectNonPerm detect_non_perm; + if (PrintRelocations) NOT_PRODUCT(detect_non_perm._print_nm = this); + oops_do(&detect_non_perm); + return detect_non_perm.detected_non_perm(); + return false; + return true; +} I don't think your marking changes are right. I think the new rule has to be that during a scavenge a the non-perm subset of nmethods are scanned as strong roots and during a full collection all nmethods are treated as weak roots as they are right now. We could make them be weak during a scavenge but then we'd need to perform the do_unloading/ make_unloaded logic during a scavenge and it seems like we should avoid that. Given this I think the call to non_perm_nmethod_oops_do in psMarkSweep is wrong since it makes them into strong roots. As far as I can tell the others are probably right though I don't claim to understand the layering in our gcs. tom On Jul 22, 2009, at 1:53 AM, John Rose wrote: > In order to inline method handles at invokedynamic instructions, it > is necessary to manipulate MethodHandle and CallSite constants from > generated code. Since these objects are created by ordinary user > code and subject to usual GC, they are not preallocated in the perm > gen. > > Currently compiled code requires that any oop embedded as an > instruction constant or any other nmethod part must be > OopDesc::is_perm. For example, internal method objects and classes > and interned strings are permanent so that they can be manipulated > from compiled code. > > This restriction is a bug for JSR 292. Luckily, there is a simple > fix. > > http://cr.openjdk.java.net/~jrose/6862576/webrev.00/ > From Thomas.Rodriguez at Sun.COM Tue Aug 11 11:33:03 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 11 Aug 2009 11:33:03 -0700 Subject: Request for reviews (XS): 6829127: Deoptimization Failure on Specjvm98 _227_mtrt with -XX:+DeoptimizeALot since Hs11 b01 In-Reply-To: <4A81AFAB.9000900@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> Message-ID: Looks good. Thanks for tracking this down. tom On Aug 11, 2009, at 10:51 AM, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6829127/webrev.00/ > > Fixed 6829127: Deoptimization Failure on Specjvm98 _227_mtrt with - > XX:+DeoptimizeALot since Hs11 b01 > > Problem: > The safepoint blob can be used in methods which are using the non > standard control word for optimized > float math. However, the non standard control word may leak out to > other codes which will cause assertion > failure in RegisterSaver::save_live_registers. > > Solution: > We can deopt at a poll point with the non standard control word, so > we make the deopt blob to not complain about > the non standard word and set the standard control word after > restore_result_registers in the deopt blob. > > Tests: specjvm98, specjvm2008 with -XX:+DeoptimizeALot > > > Thanks, > > Changpeng From Thomas.Rodriguez at Sun.COM Tue Aug 11 11:40:56 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 11 Aug 2009 11:40:56 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <19072.30144.831718.687744@sun.com> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B28CA.30806@Sun.COM> <19067.18410.306822.942873@sun.com> <29DCB7D3-F0F2-40C1-ABCB-3F826719E089@sun.com> <19068.35003.68002.631632@sun.com> <9A3ED5C6-EEAF-4998-861D-4BAA910DE69A@sun.com> <19072.30144.831718.687744@sun.com> Message-ID: Looks fine to me. tom On Aug 10, 2009, at 12:32 PM, John Coomes wrote: > Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: >> Sure. > > Ok. I've updated the webrev at > > http://cr.openjdk.java.net/~jcoomes/6866585-ci-debug/ > > so the loops over the _ci_objects array in get() and insert() are all > under control of the globals.hpp var CIObjectFactoryVerify. > > -John > >> On Aug 7, 2009, at 1:04 PM, John Coomes wrote: >> >>> John Rose (John.Rose at Sun.COM) wrote: >>>> On Aug 6, 2009, at 2:15 PM, John Coomes wrote: >>>> >>>>> In the short-term, I just want to be able to check in my test >>>>> case. >>>>> How about if I restore the debugging code, but put it under >>>>> control of >>>>> the CIObjectFactoryVerify option? >>>>> >>>>> I'll also file a bug to capture the comments. >>>> >>>> Good. I very much like Tom/Keith/Ramki's suggestions of >>>> simplifying >>>> the code and reducing perm. distinctions. >>> >>> I interpret this as you're ok with putting the debugging code under >>> control of the option for now, as long as I capture the discussion >>> in >>> a bug so it gets fixed properly. Tom, you didn't like the idea >>> much. >>> Since John is willing to fix it properly--are you ok with it now? >>> >>>> This internal CI simplification is a natural add-on to my >>>> nonperm-6863023 work. Shall I roll it in, or make a separate bug? >>> >>> I'd think of your reviewers--what would be easier for them? IMHO, >>> smaller is usually better. >>> >>> -John >>> >> > From John.Coomes at sun.com Tue Aug 11 11:57:14 2009 From: John.Coomes at sun.com (John Coomes) Date: Tue, 11 Aug 2009 11:57:14 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B28CA.30806@Sun.COM> <19067.18410.306822.942873@sun.com> <29DCB7D3-F0F2-40C1-ABCB-3F826719E089@sun.com> <19068.35003.68002.631632@sun.com> <9A3ED5C6-EEAF-4998-861D-4BAA910DE69A@sun.com> <19072.30144.831718.687744@sun.com> Message-ID: <19073.48906.929953.807359@sun.com> Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: > Looks fine to me. Many thanks. -John > On Aug 10, 2009, at 12:32 PM, John Coomes wrote: > > > Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: > >> Sure. > > > > Ok. I've updated the webrev at > > > > http://cr.openjdk.java.net/~jcoomes/6866585-ci-debug/ > > > > so the loops over the _ci_objects array in get() and insert() are all > > under control of the globals.hpp var CIObjectFactoryVerify. > > > > -John > > > >> On Aug 7, 2009, at 1:04 PM, John Coomes wrote: > >> > >>> John Rose (John.Rose at Sun.COM) wrote: > >>>> On Aug 6, 2009, at 2:15 PM, John Coomes wrote: > >>>> > >>>>> In the short-term, I just want to be able to check in my test > >>>>> case. > >>>>> How about if I restore the debugging code, but put it under > >>>>> control of > >>>>> the CIObjectFactoryVerify option? > >>>>> > >>>>> I'll also file a bug to capture the comments. > >>>> > >>>> Good. I very much like Tom/Keith/Ramki's suggestions of > >>>> simplifying > >>>> the code and reducing perm. distinctions. > >>> > >>> I interpret this as you're ok with putting the debugging code under > >>> control of the option for now, as long as I capture the discussion > >>> in > >>> a bug so it gets fixed properly. Tom, you didn't like the idea > >>> much. > >>> Since John is willing to fix it properly--are you ok with it now? > >>> > >>>> This internal CI simplification is a natural add-on to my > >>>> nonperm-6863023 work. Shall I roll it in, or make a separate bug? > >>> > >>> I'd think of your reviewers--what would be easier for them? IMHO, > >>> smaller is usually better. > >>> > >>> -John > >>> > >> > > > From Vladimir.Kozlov at Sun.COM Tue Aug 11 14:39:22 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 11 Aug 2009 14:39:22 -0700 Subject: Request for reviews (XS): 6829127: Deoptimization Failure on Specjvm98 _227_mtrt with -XX:+DeoptimizeALot since Hs11 b01 In-Reply-To: <4A81AFAB.9000900@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> Message-ID: <4A81E50A.20002@sun.com> Looks good. Vladimir changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6829127/webrev.00/ > > Fixed 6829127: Deoptimization Failure on Specjvm98 _227_mtrt with > -XX:+DeoptimizeALot since Hs11 b01 > > Problem: > The safepoint blob can be used in methods which are using the non > standard control word for optimized > float math. However, the non standard control word may leak out to other > codes which will cause assertion > failure in RegisterSaver::save_live_registers. > > Solution: > We can deopt at a poll point with the non standard control word, so we > make the deopt blob to not complain about > the non standard word and set the standard control word after > restore_result_registers in the deopt blob. > > Tests: specjvm98, specjvm2008 with -XX:+DeoptimizeALot > > > Thanks, > > Changpeng From Vladimir.Kozlov at Sun.COM Tue Aug 11 14:45:12 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 11 Aug 2009 14:45:12 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <19072.30144.831718.687744@sun.com> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B28CA.30806@Sun.COM> <19067.18410.306822.942873@sun.com> <29DCB7D3-F0F2-40C1-ABCB-3F826719E089@sun.com> <19068.35003.68002.631632@sun.com> <9A3ED5C6-EEAF-4998-861D-4BAA910DE69A@sun.com> <19072.30144.831718.687744@sun.com> Message-ID: <4A81E668.2050204@sun.com> John, Could you change the flag from develop to notproduct since it is only used in debug VM? A develop flag is still defined in product VM (as constant). Thanks, Vladimir John Coomes wrote: > Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: >> Sure. > > Ok. I've updated the webrev at > > http://cr.openjdk.java.net/~jcoomes/6866585-ci-debug/ > > so the loops over the _ci_objects array in get() and insert() are all > under control of the globals.hpp var CIObjectFactoryVerify. > > -John > >> On Aug 7, 2009, at 1:04 PM, John Coomes wrote: >> >>> John Rose (John.Rose at Sun.COM) wrote: >>>> On Aug 6, 2009, at 2:15 PM, John Coomes wrote: >>>> >>>>> In the short-term, I just want to be able to check in my test case. >>>>> How about if I restore the debugging code, but put it under >>>>> control of >>>>> the CIObjectFactoryVerify option? >>>>> >>>>> I'll also file a bug to capture the comments. >>>> Good. I very much like Tom/Keith/Ramki's suggestions of simplifying >>>> the code and reducing perm. distinctions. >>> I interpret this as you're ok with putting the debugging code under >>> control of the option for now, as long as I capture the discussion in >>> a bug so it gets fixed properly. Tom, you didn't like the idea much. >>> Since John is willing to fix it properly--are you ok with it now? >>> >>>> This internal CI simplification is a natural add-on to my >>>> nonperm-6863023 work. Shall I roll it in, or make a separate bug? >>> I'd think of your reviewers--what would be easier for them? IMHO, >>> smaller is usually better. >>> >>> -John >>> > From John.Coomes at sun.com Tue Aug 11 15:34:21 2009 From: John.Coomes at sun.com (John Coomes) Date: Tue, 11 Aug 2009 15:34:21 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow In-Reply-To: <4A81E668.2050204@sun.com> References: <19058.9853.988064.242430@sun.com> <19067.5226.564655.492988@sun.com> <4A7B1BFB.2090909@Sun.COM> <5183071C-06A7-4AFA-944C-774807D1813F@Sun.COM> <4A7B207D.5000605@Sun.COM> <4A7B28CA.30806@Sun.COM> <19067.18410.306822.942873@sun.com> <29DCB7D3-F0F2-40C1-ABCB-3F826719E089@sun.com> <19068.35003.68002.631632@sun.com> <9A3ED5C6-EEAF-4998-861D-4BAA910DE69A@sun.com> <19072.30144.831718.687744@sun.com> <4A81E668.2050204@sun.com> Message-ID: <19073.61933.384802.492264@sun.com> Vladimir Kozlov (Vladimir.Kozlov at Sun.COM) wrote: > John, > > Could you change the flag from develop to notproduct since > it is only used in debug VM? A develop flag is still defined > in product VM (as constant). Wow, learn something new every day :-). I never noticed notproduct before. I'll do that. Thanks for looking at it. -John > John Coomes wrote: > > Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: > >> Sure. > > > > Ok. I've updated the webrev at > > > > http://cr.openjdk.java.net/~jcoomes/6866585-ci-debug/ > > > > so the loops over the _ci_objects array in get() and insert() are all > > under control of the globals.hpp var CIObjectFactoryVerify. > > > > -John > > > >> On Aug 7, 2009, at 1:04 PM, John Coomes wrote: > >> > >>> John Rose (John.Rose at Sun.COM) wrote: > >>>> On Aug 6, 2009, at 2:15 PM, John Coomes wrote: > >>>> > >>>>> In the short-term, I just want to be able to check in my test case. > >>>>> How about if I restore the debugging code, but put it under > >>>>> control of > >>>>> the CIObjectFactoryVerify option? > >>>>> > >>>>> I'll also file a bug to capture the comments. > >>>> Good. I very much like Tom/Keith/Ramki's suggestions of simplifying > >>>> the code and reducing perm. distinctions. > >>> I interpret this as you're ok with putting the debugging code under > >>> control of the option for now, as long as I capture the discussion in > >>> a bug so it gets fixed properly. Tom, you didn't like the idea much. > >>> Since John is willing to fix it properly--are you ok with it now? > >>> > >>>> This internal CI simplification is a natural add-on to my > >>>> nonperm-6863023 work. Shall I roll it in, or make a separate bug? > >>> I'd think of your reviewers--what would be easier for them? IMHO, > >>> smaller is usually better. > >>> > >>> -John > >>> > > From Thomas.Rodriguez at Sun.COM Tue Aug 11 16:53:27 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 11 Aug 2009 16:53:27 -0700 Subject: review (S) for 6862863: C2 compiler fails in elide_copy() Message-ID: <953579FD-7AF4-486C-8F12-6ACB912F3548@Sun.COM> http://cr.openjdk.java.net/~never/6862863 From Vladimir.Kozlov at Sun.COM Tue Aug 11 21:49:03 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 11 Aug 2009 21:49:03 -0700 Subject: review (S) for 6862863: C2 compiler fails in elide_copy() In-Reply-To: <953579FD-7AF4-486C-8F12-6ACB912F3548@Sun.COM> References: <953579FD-7AF4-486C-8F12-6ACB912F3548@Sun.COM> Message-ID: <4A8249BF.9060101@sun.com> Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6862863 Few questions: Why yank_if_dead() checks only in(1) if it is also dead and not other inputs which could be dead also after old node is removed? should we fix it? Also from the current code it is not clear that at the end it does next for this nreg: regnd.map(nreg,n); value.map(nreg,val); (and corresponding nreg_lo mapping for register pair). May be it needs additional comment in your changes. Also in the new method you use "regnd->at(nreg)" when in other places regnd and value are passed as references and "regnd[nreg]". Can you do the same? Thanks, Vladimir From Thomas.Rodriguez at Sun.COM Wed Aug 12 11:26:08 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 12 Aug 2009 11:26:08 -0700 Subject: review (S) for 6862863: C2 compiler fails in elide_copy() In-Reply-To: <4A8249BF.9060101@sun.com> References: <953579FD-7AF4-486C-8F12-6ACB912F3548@Sun.COM> <4A8249BF.9060101@sun.com> Message-ID: <940ABA76-0DCE-4756-841E-183F21ABA259@Sun.COM> On Aug 11, 2009, at 9:49 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6862863 > > Few questions: > > Why yank_if_dead() checks only in(1) if it is also dead > and not other inputs which could be dead also after old > node is removed? should we fix it? It should never have more than 2 inputs and the control input is irrelevant. It's either a MachSpillCopy or a Con of some sort. Maybe there should be an assert for no more than 2 inputs? > Also from the current code it is not clear that at the end > it does next for this nreg: > > regnd.map(nreg,n); > value.map(nreg,val); > > (and corresponding nreg_lo mapping for register pair). > May be it needs additional comment in your changes. It's got a comment to that effect already. What kind of comment were you thinking? > Also in the new method you use "regnd->at(nreg)" > when in other places regnd and value are passed as > references and "regnd[nreg]". Can you do the same? The code uses a mix of NOde_List* and Node_List& which is pretty ugly. I'd copied the signature of yank_if_dead which was already using Node_List*. I can change it to Node_List& if you like it better. tom > > > Thanks, > Vladimir From Peter.Kessler at Sun.COM Wed Aug 12 11:40:36 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Wed, 12 Aug 2009 11:40:36 -0700 Subject: Complexity of control flow graphs? Message-ID: <4A830CA4.7090301@Sun.COM> Does anyone have a sense of the complexity of the control flow graphs seen by the HotSpot compiler? For example, how many nodes and edges are examined by PhaseCFG::Dominators (or PhaseIdealLoop::Dominators)? In light of http://jgaa.info/accepted/2006/GeorgiadisTarjanWerneck2006.10.1.pdf is there any point (other than reducing complexity!) in changing the LINK and EVAL methods to only do path compression, and not try to balance the trees used by LINK? Has anyone tried other dominator algorithms in there, e.g., http://www.cs.rice.edu/~keith/EMBED/dom.pdf to see if it matters? Thanks for any insights you have on this issue. ... peter From Thomas.Rodriguez at Sun.COM Wed Aug 12 11:40:58 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 12 Aug 2009 11:40:58 -0700 Subject: review (M) for 6862956: PhaseIdealLoop should have a CFG verification mode Message-ID: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> http://cr.openjdk.java.net/~never/6862956/ From Thomas.Rodriguez at Sun.COM Wed Aug 12 12:03:01 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 12 Aug 2009 12:03:01 -0700 Subject: Complexity of control flow graphs? In-Reply-To: <4A830CA4.7090301@Sun.COM> References: <4A830CA4.7090301@Sun.COM> Message-ID: <8B3274D4-290B-4399-8FAB-1299E8608BD4@sun.com> I don't think anyone has looked at this code in a long time. It's not the tallest nail compile time wise and we haven't seen any bugs so it's just been left alone. Why the interest? tom On Aug 12, 2009, at 11:40 AM, Peter B. Kessler wrote: > Does anyone have a sense of the complexity of the control flow > graphs seen by the HotSpot compiler? For example, how many nodes > and edges are examined by PhaseCFG::Dominators (or > PhaseIdealLoop::Dominators)? > > In light of > > http://jgaa.info/accepted/2006/GeorgiadisTarjanWerneck2006.10.1.pdf > > is there any point (other than reducing complexity!) in changing the > LINK and EVAL methods to only do path compression, and not try to > balance the trees used by LINK? > > Has anyone tried other dominator algorithms in there, e.g., > > http://www.cs.rice.edu/~keith/EMBED/dom.pdf > > to see if it matters? > > Thanks for any insights you have on this issue. > > ... peter From Vladimir.Kozlov at Sun.COM Wed Aug 12 12:11:39 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 12 Aug 2009 12:11:39 -0700 Subject: review (S) for 6862863: C2 compiler fails in elide_copy() In-Reply-To: <940ABA76-0DCE-4756-841E-183F21ABA259@Sun.COM> References: <953579FD-7AF4-486C-8F12-6ACB912F3548@Sun.COM> <4A8249BF.9060101@sun.com> <940ABA76-0DCE-4756-841E-183F21ABA259@Sun.COM> Message-ID: <4A8313EB.4010305@sun.com> Tom Rodriguez wrote: > > On Aug 11, 2009, at 9:49 PM, Vladimir Kozlov wrote: >> Why yank_if_dead() checks only in(1) if it is also dead >> and not other inputs which could be dead also after old >> node is removed? should we fix it? > > It should never have more than 2 inputs and the control input is > irrelevant. It's either a MachSpillCopy or a Con of some sort. Maybe > there should be an assert for no more than 2 inputs? The assert would be nice. > >> Also from the current code it is not clear that at the end >> it does next for this nreg: >> >> regnd.map(nreg,n); >> value.map(nreg,val); >> >> (and corresponding nreg_lo mapping for register pair). >> May be it needs additional comment in your changes. > > It's got a comment to that effect already. What kind of comment were > you thinking? Something like this: // Clear out a dead value mapped by the register to update // the register->node mapping even if 'n' defines the same value. > >> Also in the new method you use "regnd->at(nreg)" >> when in other places regnd and value are passed as >> references and "regnd[nreg]". Can you do the same? > > The code uses a mix of NOde_List* and Node_List& which is pretty ugly. > I'd copied the signature of yank_if_dead which was already using > Node_List*. I can change it to Node_List& if you like it better. yank_if_dead() uses (*regnd)[old_reg] I agree that it may be ugly but consistent. Vladimir > > tom > >> >> >> Thanks, >> Vladimir > From Vladimir.Kozlov at Sun.COM Wed Aug 12 12:53:11 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 12 Aug 2009 12:53:11 -0700 Subject: review (M) for 6862956: PhaseIdealLoop should have a CFG verification mode In-Reply-To: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> References: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> Message-ID: <4A831DA7.7050000@sun.com> Thank you, Tom, for doing this. Changes look good. Did you measure how much time compiler spends in the verification code (in PhaseIdealLoop::verify(igvn))? Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6862956/ From Thomas.Rodriguez at Sun.COM Wed Aug 12 13:02:57 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 12 Aug 2009 13:02:57 -0700 Subject: review (S) for 6862863: C2 compiler fails in elide_copy() In-Reply-To: <4A8313EB.4010305@sun.com> References: <953579FD-7AF4-486C-8F12-6ACB912F3548@Sun.COM> <4A8249BF.9060101@sun.com> <940ABA76-0DCE-4756-841E-183F21ABA259@Sun.COM> <4A8313EB.4010305@sun.com> Message-ID: <97DA006D-21DD-4D35-BEB5-FD864F32086E@Sun.COM> On Aug 12, 2009, at 12:11 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> On Aug 11, 2009, at 9:49 PM, Vladimir Kozlov wrote: >>> Why yank_if_dead() checks only in(1) if it is also dead >>> and not other inputs which could be dead also after old >>> node is removed? should we fix it? >> It should never have more than 2 inputs and the control input is >> irrelevant. It's either a MachSpillCopy or a Con of some sort. >> Maybe there should be an assert for no more than 2 inputs? > > The assert would be nice. I've added it. > >>> Also from the current code it is not clear that at the end >>> it does next for this nreg: >>> >>> regnd.map(nreg,n); >>> value.map(nreg,val); >>> >>> (and corresponding nreg_lo mapping for register pair). >>> May be it needs additional comment in your changes. >> It's got a comment to that effect already. What kind of comment >> were you thinking? > > Something like this: > > // Clear out a dead value mapped by the register to update > // the register->node mapping even if 'n' defines the same value. Where do you want this comment? >>> Also in the new method you use "regnd->at(nreg)" >>> when in other places regnd and value are passed as >>> references and "regnd[nreg]". Can you do the same? >> The code uses a mix of NOde_List* and Node_List& which is pretty >> ugly. I'd copied the signature of yank_if_dead which was already >> using Node_List*. I can change it to Node_List& if you like it >> better. > > yank_if_dead() uses (*regnd)[old_reg] > I agree that it may be ugly but consistent. I switched it to use Node_List&. tom > > Vladimir > >> tom >>> >>> >>> Thanks, >>> Vladimir From Thomas.Rodriguez at Sun.COM Wed Aug 12 13:14:37 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 12 Aug 2009 13:14:37 -0700 Subject: review (M) for 6862956: PhaseIdealLoop should have a CFG verification mode In-Reply-To: <4A831DA7.7050000@sun.com> References: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> <4A831DA7.7050000@sun.com> Message-ID: <42124C17-5AB8-4828-A0B4-15D7EE920EC7@Sun.COM> No I haven't. It's certainly not free. I can add some TracePhases and do some runs. I also moved the first verify into the preceeding block of PhaseIdealLoop passes so we aren't doing doing multiple verifies for code without loops. I'll get some numbers. tom On Aug 12, 2009, at 12:53 PM, Vladimir Kozlov wrote: > Thank you, Tom, for doing this. > > Changes look good. > Did you measure how much time compiler spends in the verification code > (in PhaseIdealLoop::verify(igvn))? > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6862956/ From Peter.Kessler at Sun.COM Wed Aug 12 13:22:50 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Wed, 12 Aug 2009 13:22:50 -0700 Subject: Complexity of control flow graphs? In-Reply-To: <8B3274D4-290B-4399-8FAB-1299E8608BD4@sun.com> References: <4A830CA4.7090301@Sun.COM> <8B3274D4-290B-4399-8FAB-1299E8608BD4@sun.com> Message-ID: <4A83249A.7060300@Sun.COM> Mostly, intellectual curiosity. More immediately, we are reusing the server compiler for something new and our constraints are different enough (way simpler) that we are thinking of rewriting the scheduler. So I was looking at how the current code works and where it might make sense to apply different assumptions or simplify things. The performance geek in me likes the trail from Lengauer-Tarjan from 1979 through Cooper-Harvey-Kennedy to Georgiadis-Tarjan-Werneck in 2006 as people learned what matters. My favorite quote is We have not included linear-time algorithms in our study; they are significantly more complex and thus unlikely to be faster than LT or SLT in practice. Maybe just knowing "It's not the tallest nail" is enough of an answer. Thanks. ... peter Tom Rodriguez wrote: > I don't think anyone has looked at this code in a long time. It's not > the tallest nail compile time wise and we haven't seen any bugs so it's > just been left alone. Why the interest? > > tom > > On Aug 12, 2009, at 11:40 AM, Peter B. Kessler wrote: > >> Does anyone have a sense of the complexity of the control flow graphs >> seen by the HotSpot compiler? For example, how many nodes and edges >> are examined by PhaseCFG::Dominators (or PhaseIdealLoop::Dominators)? >> >> In light of >> >> http://jgaa.info/accepted/2006/GeorgiadisTarjanWerneck2006.10.1.pdf >> >> is there any point (other than reducing complexity!) in changing the >> LINK and EVAL methods to only do path compression, and not try to >> balance the trees used by LINK? >> >> Has anyone tried other dominator algorithms in there, e.g., >> >> http://www.cs.rice.edu/~keith/EMBED/dom.pdf >> >> to see if it matters? >> >> Thanks for any insights you have on this issue. >> >> ... peter > From Thomas.Rodriguez at Sun.COM Wed Aug 12 13:55:54 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 12 Aug 2009 13:55:54 -0700 Subject: review (M) for 6862956: PhaseIdealLoop should have a CFG verification mode In-Reply-To: <42124C17-5AB8-4828-A0B4-15D7EE920EC7@Sun.COM> References: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> <4A831DA7.7050000@sun.com> <42124C17-5AB8-4828-A0B4-15D7EE920EC7@Sun.COM> Message-ID: <5B84FBAF-CFDB-42CD-A54C-F84F75D815E8@sun.com> On Aug 12, 2009, at 1:14 PM, Tom Rodriguez wrote: > No I haven't. It's certainly not free. I can add some TracePhases > and do some runs. I also moved the first verify into the preceeding > block of PhaseIdealLoop passes so we aren't doing doing multiple > verifies for code without loops. I'll get some numbers. I added another elapsedTimer and ran jbb fastdebug with -XX: +TimeCompiler on an 8 way 2.7Ghz opteron. It reports about .33 seconds spent in verify out of 19 seconds total. Seems pretty manageable. I've updated the webrev with the new timer code. tom Accumulated compiler times: --------------------------- Total compilation: 19.067 sec. method compilation : 19.057 sec/135529 bytes (7112 bytes per sec) stub compilation : 0.009 sec. Phases: parse : 4.822 sec optimizer : 2.652 sec iterGVN : 0.138 sec idealLoop : 1.456 sec idealLoopVerify: 0.332 sec ccp : 0.046 sec iterGVN2 : 0.164 sec graphReshape : 0.030 sec subtotal : 1.670 sec, 62.95 % matcher : 0.525 sec scheduler : 0.629 sec regalloc : 4.276 sec ctorChaitin : 0.002 sec buildIFG : 1.425 sec computeLive : 0.759 sec regAllocSplit: 1.260 sec postAllocCopyRemoval: 0.140 sec fixupSpills : 0.012 sec subtotal : 3.598 sec, 84.14 % macroExpand : 0.140 sec blockOrdering: 0.049 sec peephole : 0.007 sec codeGen : 4.347 sec install_code : 0.057 sec ------------ : ---------- total : 17.536 sec, 92.02 % output : 4.348 sec isched : 0.000 sec bldOopMaps: 0.088 sec > > tom > > On Aug 12, 2009, at 12:53 PM, Vladimir Kozlov wrote: > >> Thank you, Tom, for doing this. >> >> Changes look good. >> Did you measure how much time compiler spends in the verification >> code >> (in PhaseIdealLoop::verify(igvn))? >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6862956/ > From Vladimir.Kozlov at Sun.COM Wed Aug 12 13:52:57 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 12 Aug 2009 13:52:57 -0700 Subject: review (S) for 6862863: C2 compiler fails in elide_copy() In-Reply-To: <97DA006D-21DD-4D35-BEB5-FD864F32086E@Sun.COM> References: <953579FD-7AF4-486C-8F12-6ACB912F3548@Sun.COM> <4A8249BF.9060101@sun.com> <940ABA76-0DCE-4756-841E-183F21ABA259@Sun.COM> <4A8313EB.4010305@sun.com> <97DA006D-21DD-4D35-BEB5-FD864F32086E@Sun.COM> Message-ID: <4A832BA9.4030005@sun.com> Tom Rodriguez wrote: >>>> (and corresponding nreg_lo mapping for register pair). >>>> May be it needs additional comment in your changes. >>> It's got a comment to that effect already. What kind of comment were >>> you thinking? >> >> Something like this: >> >> // Clear out a dead value mapped by the register to update >> // the register->node mapping even if 'n' defines the same value. > > Where do you want this comment? > You can just update the new comment you added by replacing the first sentence ?: // Clear out a dead value before starting. Vladimir From Thomas.Rodriguez at Sun.COM Wed Aug 12 14:01:45 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 12 Aug 2009 14:01:45 -0700 Subject: review (S) for 6795465: Crash in assembler_sparc.cpp with client compiler on solaris-sparc Message-ID: <03145187-8EB5-487C-A1F2-0147F0B772C5@Sun.COM> http://cr.openjdk.java.net/~never/6795465 From Vladimir.Kozlov at Sun.COM Wed Aug 12 13:59:43 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 12 Aug 2009 13:59:43 -0700 Subject: review (M) for 6862956: PhaseIdealLoop should have a CFG verification mode In-Reply-To: <42124C17-5AB8-4828-A0B4-15D7EE920EC7@Sun.COM> References: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> <4A831DA7.7050000@sun.com> <42124C17-5AB8-4828-A0B4-15D7EE920EC7@Sun.COM> Message-ID: <4A832D3F.3010505@sun.com> Tom Rodriguez wrote: > No I haven't. It's certainly not free. I can add some TracePhases and > do some runs. I also moved the first verify into the preceeding block > of PhaseIdealLoop passes so we aren't doing doing multiple verifies for > code without loops. I'll get some numbers. Thanks you. I looked more and found that you miss break in the error case in verify_dominance(). Vladimir > > tom > > On Aug 12, 2009, at 12:53 PM, Vladimir Kozlov wrote: > >> Thank you, Tom, for doing this. >> >> Changes look good. >> Did you measure how much time compiler spends in the verification code >> (in PhaseIdealLoop::verify(igvn))? >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6862956/ > From Thomas.Rodriguez at Sun.COM Wed Aug 12 14:11:11 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 12 Aug 2009 14:11:11 -0700 Subject: review (M) for 6862956: PhaseIdealLoop should have a CFG verification mode In-Reply-To: <4A832D3F.3010505@sun.com> References: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> <4A831DA7.7050000@sun.com> <42124C17-5AB8-4828-A0B4-15D7EE920EC7@Sun.COM> <4A832D3F.3010505@sun.com> Message-ID: <1EA3F779-B67C-4573-AC53-9F1E0730C022@Sun.COM> On Aug 12, 2009, at 1:59 PM, Vladimir Kozlov wrote: > > Tom Rodriguez wrote: >> No I haven't. It's certainly not free. I can add some TracePhases >> and do some runs. I also moved the first verify into the >> preceeding block of PhaseIdealLoop passes so we aren't doing doing >> multiple verifies for code without loops. I'll get some numbers. > > Thanks you. > > I looked more and found that you miss break in the error case in > verify_dominance(). Right, otherwise we'll just assert in idom. Thanks. tom > > Vladimir > >> tom >> On Aug 12, 2009, at 12:53 PM, Vladimir Kozlov wrote: >>> Thank you, Tom, for doing this. >>> >>> Changes look good. >>> Did you measure how much time compiler spends in the verification >>> code >>> (in PhaseIdealLoop::verify(igvn))? >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6862956/ From Vladimir.Kozlov at Sun.COM Wed Aug 12 14:29:07 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 12 Aug 2009 14:29:07 -0700 Subject: review (M) for 6862956: PhaseIdealLoop should have a CFG verification mode In-Reply-To: <1EA3F779-B67C-4573-AC53-9F1E0730C022@Sun.COM> References: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> <4A831DA7.7050000@sun.com> <42124C17-5AB8-4828-A0B4-15D7EE920EC7@Sun.COM> <4A832D3F.3010505@sun.com> <1EA3F779-B67C-4573-AC53-9F1E0730C022@Sun.COM> Message-ID: <4A833423.20501@sun.com> Why you didn't place second verify() under if(loop_opts_cnt > 0)? Vladimir Tom Rodriguez wrote: > > On Aug 12, 2009, at 1:59 PM, Vladimir Kozlov wrote: > >> >> Tom Rodriguez wrote: >>> No I haven't. It's certainly not free. I can add some TracePhases >>> and do some runs. I also moved the first verify into the preceeding >>> block of PhaseIdealLoop passes so we aren't doing doing multiple >>> verifies for code without loops. I'll get some numbers. >> >> Thanks you. >> >> I looked more and found that you miss break in the error case in >> verify_dominance(). > > Right, otherwise we'll just assert in idom. Thanks. > > tom > >> >> Vladimir >> >>> tom >>> On Aug 12, 2009, at 12:53 PM, Vladimir Kozlov wrote: >>>> Thank you, Tom, for doing this. >>>> >>>> Changes look good. >>>> Did you measure how much time compiler spends in the verification code >>>> (in PhaseIdealLoop::verify(igvn))? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/6862956/ > From Vladimir.Kozlov at Sun.COM Wed Aug 12 14:37:30 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 12 Aug 2009 14:37:30 -0700 Subject: review (M) for 6862956: PhaseIdealLoop should have a CFG verification mode In-Reply-To: <4A833423.20501@sun.com> References: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> <4A831DA7.7050000@sun.com> <42124C17-5AB8-4828-A0B4-15D7EE920EC7@Sun.COM> <4A832D3F.3010505@sun.com> <1EA3F779-B67C-4573-AC53-9F1E0730C022@Sun.COM> <4A833423.20501@sun.com> Message-ID: <4A83361A.1000602@sun.com> So you want to do at least one dominator verification. Please, add the comment there. Vladimir Vladimir Kozlov wrote: > Why you didn't place second verify() under if(loop_opts_cnt > 0)? > > Vladimir > > Tom Rodriguez wrote: >> >> On Aug 12, 2009, at 1:59 PM, Vladimir Kozlov wrote: >> >>> >>> Tom Rodriguez wrote: >>>> No I haven't. It's certainly not free. I can add some TracePhases >>>> and do some runs. I also moved the first verify into the preceeding >>>> block of PhaseIdealLoop passes so we aren't doing doing multiple >>>> verifies for code without loops. I'll get some numbers. >>> >>> Thanks you. >>> >>> I looked more and found that you miss break in the error case in >>> verify_dominance(). >> >> Right, otherwise we'll just assert in idom. Thanks. >> >> tom >> >>> >>> Vladimir >>> >>>> tom >>>> On Aug 12, 2009, at 12:53 PM, Vladimir Kozlov wrote: >>>>> Thank you, Tom, for doing this. >>>>> >>>>> Changes look good. >>>>> Did you measure how much time compiler spends in the verification code >>>>> (in PhaseIdealLoop::verify(igvn))? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> http://cr.openjdk.java.net/~never/6862956/ >> From Thomas.Rodriguez at Sun.COM Wed Aug 12 15:01:11 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 12 Aug 2009 15:01:11 -0700 Subject: review (M) for 6862956: PhaseIdealLoop should have a CFG verification mode In-Reply-To: <4A83361A.1000602@sun.com> References: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> <4A831DA7.7050000@sun.com> <42124C17-5AB8-4828-A0B4-15D7EE920EC7@Sun.COM> <4A832D3F.3010505@sun.com> <1EA3F779-B67C-4573-AC53-9F1E0730C022@Sun.COM> <4A833423.20501@sun.com> <4A83361A.1000602@sun.com> Message-ID: <9AC524FC-2122-4D56-82CD-003F8A416971@Sun.COM> Done. tom On Aug 12, 2009, at 2:37 PM, Vladimir Kozlov wrote: > So you want to do at least one dominator verification. > Please, add the comment there. > > Vladimir > > Vladimir Kozlov wrote: >> Why you didn't place second verify() under if(loop_opts_cnt > 0)? >> Vladimir >> Tom Rodriguez wrote: >>> >>> On Aug 12, 2009, at 1:59 PM, Vladimir Kozlov wrote: >>> >>>> >>>> Tom Rodriguez wrote: >>>>> No I haven't. It's certainly not free. I can add some >>>>> TracePhases and do some runs. I also moved the first verify >>>>> into the preceeding block of PhaseIdealLoop passes so we aren't >>>>> doing doing multiple verifies for code without loops. I'll get >>>>> some numbers. >>>> >>>> Thanks you. >>>> >>>> I looked more and found that you miss break in the error case in >>>> verify_dominance(). >>> >>> Right, otherwise we'll just assert in idom. Thanks. >>> >>> tom >>> >>>> >>>> Vladimir >>>> >>>>> tom >>>>> On Aug 12, 2009, at 12:53 PM, Vladimir Kozlov wrote: >>>>>> Thank you, Tom, for doing this. >>>>>> >>>>>> Changes look good. >>>>>> Did you measure how much time compiler spends in the >>>>>> verification code >>>>>> (in PhaseIdealLoop::verify(igvn))? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> http://cr.openjdk.java.net/~never/6862956/ >>> From Vladimir.Kozlov at Sun.COM Wed Aug 12 15:07:32 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 12 Aug 2009 15:07:32 -0700 Subject: review (M) for 6862956: PhaseIdealLoop should have a CFG verification mode In-Reply-To: <9AC524FC-2122-4D56-82CD-003F8A416971@Sun.COM> References: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> <4A831DA7.7050000@sun.com> <42124C17-5AB8-4828-A0B4-15D7EE920EC7@Sun.COM> <4A832D3F.3010505@sun.com> <1EA3F779-B67C-4573-AC53-9F1E0730C022@Sun.COM> <4A833423.20501@sun.com> <4A83361A.1000602@sun.com> <9AC524FC-2122-4D56-82CD-003F8A416971@Sun.COM> Message-ID: <4A833D24.9030907@sun.com> OK. Looks good. Vladimir Tom Rodriguez wrote: > Done. > > tom > > On Aug 12, 2009, at 2:37 PM, Vladimir Kozlov wrote: > >> So you want to do at least one dominator verification. >> Please, add the comment there. >> >> Vladimir >> >> Vladimir Kozlov wrote: >>> Why you didn't place second verify() under if(loop_opts_cnt > 0)? >>> Vladimir >>> Tom Rodriguez wrote: >>>> >>>> On Aug 12, 2009, at 1:59 PM, Vladimir Kozlov wrote: >>>> >>>>> >>>>> Tom Rodriguez wrote: >>>>>> No I haven't. It's certainly not free. I can add some >>>>>> TracePhases and do some runs. I also moved the first verify into >>>>>> the preceeding block of PhaseIdealLoop passes so we aren't doing >>>>>> doing multiple verifies for code without loops. I'll get some >>>>>> numbers. >>>>> >>>>> Thanks you. >>>>> >>>>> I looked more and found that you miss break in the error case in >>>>> verify_dominance(). >>>> >>>> Right, otherwise we'll just assert in idom. Thanks. >>>> >>>> tom >>>> >>>>> >>>>> Vladimir >>>>> >>>>>> tom >>>>>> On Aug 12, 2009, at 12:53 PM, Vladimir Kozlov wrote: >>>>>>> Thank you, Tom, for doing this. >>>>>>> >>>>>>> Changes look good. >>>>>>> Did you measure how much time compiler spends in the verification >>>>>>> code >>>>>>> (in PhaseIdealLoop::verify(igvn))? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> http://cr.openjdk.java.net/~never/6862956/ >>>> > From Christian.Thalinger at Sun.COM Thu Aug 13 00:12:51 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 13 Aug 2009 09:12:51 +0200 Subject: review (M) for 6862956: PhaseIdealLoop should have a CFG verification mode In-Reply-To: <5B84FBAF-CFDB-42CD-A54C-F84F75D815E8@sun.com> References: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> <4A831DA7.7050000@sun.com> <42124C17-5AB8-4828-A0B4-15D7EE920EC7@Sun.COM> <5B84FBAF-CFDB-42CD-A54C-F84F75D815E8@sun.com> Message-ID: <4A83BCF3.40008@Sun.COM> Tom Rodriguez wrote: > Accumulated compiler times: > --------------------------- > Total compilation: 19.067 sec. > method compilation : 19.057 sec/135529 bytes (7112 bytes per sec) > stub compilation : 0.009 sec. > Phases: > parse : 4.822 sec > optimizer : 2.652 sec > iterGVN : 0.138 sec > idealLoop : 1.456 sec > idealLoopVerify: 0.332 sec > ccp : 0.046 sec > iterGVN2 : 0.164 sec > graphReshape : 0.030 sec > subtotal : 1.670 sec, 62.95 % > matcher : 0.525 sec > scheduler : 0.629 sec > regalloc : 4.276 sec > ctorChaitin : 0.002 sec > buildIFG : 1.425 sec > computeLive : 0.759 sec > regAllocSplit: 1.260 sec > postAllocCopyRemoval: 0.140 sec > fixupSpills : 0.012 sec > subtotal : 3.598 sec, 84.14 % > macroExpand : 0.140 sec > blockOrdering: 0.049 sec > peephole : 0.007 sec > codeGen : 4.347 sec > install_code : 0.057 sec > ------------ : ---------- > total : 17.536 sec, 92.02 % > output : 4.348 sec > isched : 0.000 sec > bldOopMaps: 0.088 sec The indent is a little confusing. It looks like idealLoopVerify is a compiler phase. -- Christian From Christian.Thalinger at Sun.COM Thu Aug 13 00:36:42 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 13 Aug 2009 09:36:42 +0200 Subject: review (S) for 6795465: Crash in assembler_sparc.cpp with client compiler on solaris-sparc In-Reply-To: <03145187-8EB5-487C-A1F2-0147F0B772C5@Sun.COM> References: <03145187-8EB5-487C-A1F2-0147F0B772C5@Sun.COM> Message-ID: <4A83C28A.80102@Sun.COM> Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6795465 c1_LIRGenerator_sparc.cpp: Why did you change the copyright back to 2008? - * Copyright 2005-2009 Sun Microsystems, Inc. All Rights Reserved. + * Copyright 2005-2008 Sun Microsystems, Inc. All Rights Reserved. Other files' copyright year should be updated too. Otherwise looks good. -- Christian From Changpeng.Fang at Sun.COM Thu Aug 13 08:52:17 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Thu, 13 Aug 2009 08:52:17 -0700 Subject: review (S) for 6795465: Crash in assembler_sparc.cpp with client compiler on solaris-sparc In-Reply-To: <03145187-8EB5-487C-A1F2-0147F0B772C5@Sun.COM> References: <03145187-8EB5-487C-A1F2-0147F0B772C5@Sun.COM> Message-ID: <4A8436B1.7010302@sun.com> On 08/12/09 14:01, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6795465 Looks good! Changpeng From Thomas.Rodriguez at Sun.COM Thu Aug 13 14:21:39 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 13 Aug 2009 14:21:39 -0700 Subject: review (S) for 6795465: Crash in assembler_sparc.cpp with client compiler on solaris-sparc In-Reply-To: <4A83C28A.80102@Sun.COM> References: <03145187-8EB5-487C-A1F2-0147F0B772C5@Sun.COM> <4A83C28A.80102@Sun.COM> Message-ID: I'm not sure why that happened. I've corrected the copyright on all the files that needed it. tom On Aug 13, 2009, at 12:36 AM, Christian Thalinger wrote: > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6795465 > > c1_LIRGenerator_sparc.cpp: > > Why did you change the copyright back to 2008? > > - * Copyright 2005-2009 Sun Microsystems, Inc. All Rights Reserved. > + * Copyright 2005-2008 Sun Microsystems, Inc. All Rights Reserved. > > Other files' copyright year should be updated too. > > Otherwise looks good. > > -- Christian From Thomas.Rodriguez at Sun.COM Thu Aug 13 16:44:48 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 13 Aug 2009 16:44:48 -0700 Subject: review (M) for 6862956: PhaseIdealLoop should have a CFG verification mode In-Reply-To: <4A83BCF3.40008@Sun.COM> References: <2341892B-7DA7-491A-95D3-12AFB2233613@sun.com> <4A831DA7.7050000@sun.com> <42124C17-5AB8-4828-A0B4-15D7EE920EC7@Sun.COM> <5B84FBAF-CFDB-42CD-A54C-F84F75D815E8@sun.com> <4A83BCF3.40008@Sun.COM> Message-ID: Yes, the indenting seems wrong. I've fixed it: Accumulated compiler times: --------------------------- Total compilation: 2.887 sec. method compilation : 2.874 sec/50848 bytes (17694 bytes per sec) stub compilation : 0.013 sec. Phases: parse : 0.847 sec optimizer : 0.624 sec iterGVN : 0.042 sec idealLoop : 0.284 sec idealLoopVerify: 0.101 sec ccp : 0.015 sec iterGVN2 : 0.027 sec graphReshape : 0.011 sec subtotal : 0.352 sec, 56.37 % matcher : 0.180 sec scheduler : 0.200 sec regalloc : 0.789 sec ctorChaitin : 0.001 sec buildIFG : 0.272 sec computeLive : 0.172 sec regAllocSplit : 0.141 sec postAllocCopyRemoval: 0.044 sec fixupSpills : 0.003 sec subtotal : 0.633 sec, 80.28 % macroExpand : 0.055 sec blockOrdering : 0.018 sec peephole : 0.002 sec codeGen : 0.146 sec install_code : 0.035 sec -------------- : ---------- total : 2.908 sec, 101.19 % output : 0.147 sec isched : 0.000 sec bldOopMaps : 0.028 sec tom On Aug 13, 2009, at 12:12 AM, Christian Thalinger wrote: > Tom Rodriguez wrote: >> Accumulated compiler times: >> --------------------------- >> Total compilation: 19.067 sec. >> method compilation : 19.057 sec/135529 bytes (7112 bytes per sec) >> stub compilation : 0.009 sec. >> Phases: >> parse : 4.822 sec >> optimizer : 2.652 sec >> iterGVN : 0.138 sec >> idealLoop : 1.456 sec >> idealLoopVerify: 0.332 sec >> ccp : 0.046 sec >> iterGVN2 : 0.164 sec >> graphReshape : 0.030 sec >> subtotal : 1.670 sec, 62.95 % >> matcher : 0.525 sec >> scheduler : 0.629 sec >> regalloc : 4.276 sec >> ctorChaitin : 0.002 sec >> buildIFG : 1.425 sec >> computeLive : 0.759 sec >> regAllocSplit: 1.260 sec >> postAllocCopyRemoval: 0.140 sec >> fixupSpills : 0.012 sec >> subtotal : 3.598 sec, 84.14 % >> macroExpand : 0.140 sec >> blockOrdering: 0.049 sec >> peephole : 0.007 sec >> codeGen : 4.347 sec >> install_code : 0.057 sec >> ------------ : ---------- >> total : 17.536 sec, 92.02 % >> output : 4.348 sec >> isched : 0.000 sec >> bldOopMaps: 0.088 sec > > The indent is a little confusing. It looks like idealLoopVerify is a > compiler phase. > > -- Christian From vladimir.kozlov at sun.com Thu Aug 13 19:03:11 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 14 Aug 2009 02:03:11 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 4 new changesets Message-ID: <20090814020326.12720ED63@hg.openjdk.java.net> Changeset: 3ee342e25e57 Author: jcoomes Date: 2009-08-05 12:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3ee342e25e57 6821693: 64-bit TaskQueue capacity still too small 6821507: Alignment problem in GC taskqueue Reviewed-by: tonyp, apetrusenko ! src/share/vm/utilities/taskqueue.hpp Changeset: b1773b9a2ca1 Author: ysr Date: 2009-08-09 17:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b1773b9a2ca1 Merge Changeset: b32a809aab08 Author: jcoomes Date: 2009-08-11 23:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b32a809aab08 6866585: debug code in ciObjectFactory too slow for large objects Reviewed-by: ysr, never, kvn ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/runtime/globals.hpp Changeset: 10d8c0d0d60e Author: jcoomes Date: 2009-08-12 14:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/10d8c0d0d60e 6867645: java -Xshare:dump failed - read only space too small Reviewed-by: iveresov, tonyp, ysr ! src/share/vm/runtime/globals.hpp From john.coomes at sun.com Thu Aug 13 21:30:08 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 14 Aug 2009 04:30:08 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b69 for changeset 82e6c820c51a Message-ID: <20090814043009.136BFED8C@hg.openjdk.java.net> Changeset: 51a71c2c4b80 Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/51a71c2c4b80 Added tag jdk7-b69 for changeset 82e6c820c51a ! .hgtags From john.coomes at sun.com Thu Aug 13 21:35:46 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 14 Aug 2009 04:35:46 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b69 for changeset 8120d308ec4e Message-ID: <20090814043547.D6094ED91@hg.openjdk.java.net> Changeset: 07b3e9ba5085 Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/07b3e9ba5085 Added tag jdk7-b69 for changeset 8120d308ec4e ! .hgtags From john.coomes at sun.com Thu Aug 13 21:46:01 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 14 Aug 2009 04:46:01 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b69 for changeset a4ab0d6ded63 Message-ID: <20090814044604.19DEBED96@hg.openjdk.java.net> Changeset: 8287833daabc Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/8287833daabc Added tag jdk7-b69 for changeset a4ab0d6ded63 ! .hgtags From john.coomes at sun.com Thu Aug 13 21:51:50 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 14 Aug 2009 04:51:50 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b69 for changeset 3e64fdfb9291 Message-ID: <20090814045152.C3C72ED9B@hg.openjdk.java.net> Changeset: 1041c9cce799 Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/1041c9cce799 Added tag jdk7-b69 for changeset 3e64fdfb9291 ! .hgtags From john.coomes at sun.com Thu Aug 13 21:57:51 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 14 Aug 2009 04:57:51 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 4 new changesets Message-ID: <20090814045909.64738EDA0@hg.openjdk.java.net> Changeset: 7e491e39ea0f Author: tbell Date: 2009-08-06 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7e491e39ea0f 6865853: Additional code changes needed to build deploy using WXP SP2 and Visual Studio 2008 Reviewed-by: ohair ! src/windows/native/sun/jkernel/kernel.cpp Changeset: 08baaf8638c9 Author: tbell Date: 2009-08-06 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/08baaf8638c9 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: 226b20019b1f Author: xdono Date: 2009-08-12 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/226b20019b1f Merge Changeset: 36c8ddbe9bc5 Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/36c8ddbe9bc5 Added tag jdk7-b69 for changeset 226b20019b1f ! .hgtags From john.coomes at sun.com Thu Aug 13 22:09:56 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 14 Aug 2009 05:09:56 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b69 for changeset ce9bcdcb7859 Message-ID: <20090814051001.49F25EDA5@hg.openjdk.java.net> Changeset: 4ac89259512f Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/4ac89259512f Added tag jdk7-b69 for changeset ce9bcdcb7859 ! .hgtags From thomas.rodriguez at sun.com Fri Aug 14 03:34:14 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Fri, 14 Aug 2009 10:34:14 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6862956: PhaseIdealLoop should have a CFG verification mode Message-ID: <20090814103421.7F252EDFB@hg.openjdk.java.net> Changeset: 046932b72aa2 Author: never Date: 2009-08-14 00:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/046932b72aa2 6862956: PhaseIdealLoop should have a CFG verification mode Reviewed-by: kvn, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp From rasbold at google.com Fri Aug 14 13:48:40 2009 From: rasbold at google.com (Chuck Rasbold) Date: Fri, 14 Aug 2009 13:48:40 -0700 Subject: stack frames Message-ID: <4149a0430908141348m8f87b0frd996138fbd7f5828@mail.gmail.com> A colleague asked me for a specification of HotSpot (actually, C2) stack frames. My JVM skills are a little rusty, and I realize that my knowledge is based more on experience, rather than a spec. Where are the most authoritative descriptions of the frame layout in HotSpot? Even if there is not one in the code, is there one in John Rose's HotSpot internals wiki? -- Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090814/d4c799a7/attachment.html From Changpeng.Fang at Sun.COM Fri Aug 14 14:50:25 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Fri, 14 Aug 2009 14:50:25 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <4A81AFAB.9000900@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> Message-ID: <4A85DC21.6060605@sun.com> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ Fixed 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) Problem: set_req_X will do dead code elimination if the original input has no other use. However, it is possible to have the current node (this) removed if a dead loop exists. So, dead code elimination in set_req_X is not safe, and may cause undesired consequences (like the segfault in 6866651) Solution: Instead of doing dead code elimination immediately in set_req_X, we put the dead node (original input) into the worklist, and the dead node will eventually be eliminated when it is its turn to be processed. In addition, before ideal transformations, we replace a node with a constant if we know it computes a constant to skip unneeded optimizations on this node. Tests: JPRT, CompileTheWorld, Test case in bug report (Test.java in webrev) Thanks, Changpeng From Vladimir.Kozlov at Sun.COM Fri Aug 14 15:09:29 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 14 Aug 2009 15:09:29 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <4A85DC21.6060605@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> Message-ID: <4A85E099.5040302@sun.com> Looks good. I would remove -server from the test options to run it with tested (client) VM instead of default VM. Thanks, Vladimir changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ > > Fixed 6866651: Regression: simple int sum crashes jvm (build > 1.6.0_14-b08 and 1.7.0-ea-b59) > > Problem: > set_req_X will do dead code elimination if the original input has no > other use. However, it is possible to > have the current node (this) removed if a dead loop exists. So, dead > code elimination in set_req_X is not > safe, and may cause undesired consequences (like the segfault in 6866651) > > Solution: > Instead of doing dead code elimination immediately in set_req_X, we put > the dead node (original input) into > the worklist, and the dead node will eventually be eliminated when it is > its turn to be processed. > > In addition, before ideal transformations, we replace a node with a > constant if we know it computes a constant > to skip unneeded optimizations on this node. > Tests: JPRT, CompileTheWorld, Test case in bug report (Test.java in webrev) > > Thanks, > > Changpeng From Thomas.Rodriguez at Sun.COM Fri Aug 14 15:34:32 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 14 Aug 2009 15:34:32 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <4A85DC21.6060605@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> Message-ID: Why are you including the first part in this fix? I don't see the motivation for that change. tom On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ > > Fixed 6866651: Regression: simple int sum crashes jvm (build > 1.6.0_14-b08 and 1.7.0-ea-b59) > > Problem: > set_req_X will do dead code elimination if the original input has no > other use. However, it is possible to > have the current node (this) removed if a dead loop exists. So, > dead code elimination in set_req_X is not > safe, and may cause undesired consequences (like the segfault in > 6866651) > > Solution: > Instead of doing dead code elimination immediately in set_req_X, we > put the dead node (original input) into > the worklist, and the dead node will eventually be eliminated when > it is its turn to be processed. > > In addition, before ideal transformations, we replace a node with a > constant if we know it computes a constant > to skip unneeded optimizations on this node. Tests: JPRT, > CompileTheWorld, Test case in bug report (Test.java in webrev) > > Thanks, > > Changpeng From Thomas.Rodriguez at Sun.COM Fri Aug 14 15:35:14 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 14 Aug 2009 15:35:14 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <4A85E099.5040302@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E099.5040302@sun.com> Message-ID: You also don't need the /othervm part. tom On Aug 14, 2009, at 3:09 PM, Vladimir Kozlov wrote: > Looks good. > > I would remove -server from the test options to run it with tested > (client) VM instead of default VM. > > Thanks, > Vladimir > > changpeng fang - Sun Microsystems - Santa Clara United States wrote: >> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >> Fixed 6866651: Regression: simple int sum crashes jvm (build >> 1.6.0_14-b08 and 1.7.0-ea-b59) >> Problem: >> set_req_X will do dead code elimination if the original input has >> no other use. However, it is possible to >> have the current node (this) removed if a dead loop exists. So, >> dead code elimination in set_req_X is not >> safe, and may cause undesired consequences (like the segfault in >> 6866651) >> Solution: >> Instead of doing dead code elimination immediately in set_req_X, we >> put the dead node (original input) into >> the worklist, and the dead node will eventually be eliminated when >> it is its turn to be processed. >> In addition, before ideal transformations, we replace a node with >> a constant if we know it computes a constant >> to skip unneeded optimizations on this node. >> Tests: JPRT, CompileTheWorld, Test case in bug report (Test.java in >> webrev) >> Thanks, >> Changpeng From Thomas.Rodriguez at Sun.COM Fri Aug 14 15:49:54 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 14 Aug 2009 15:49:54 -0700 Subject: stack frames In-Reply-To: <4149a0430908141348m8f87b0frd996138fbd7f5828@mail.gmail.com> References: <4149a0430908141348m8f87b0frd996138fbd7f5828@mail.gmail.com> Message-ID: <28ACC7CE-E2D0-4AD3-A556-085924046FB5@sun.com> I don't know that there's a specification of compiled frames anywhere. We generally use standard call and return sequences and construct our frames following the platform ABI, though on x86 we don't maintain ebp as the frame pointer but treat it as callee saved and store it in the standard place and use no other callee saved registers. The frame contains monitor records, spill slots and the outgoing argument area in that order. I think that's about the extent of what's specified. matcher.cpp contains all the frame layout logic for c2. tom On Aug 14, 2009, at 1:48 PM, Chuck Rasbold wrote: > A colleague asked me for a specification of HotSpot (actually, C2) > stack frames. > > My JVM skills are a little rusty, and I realize that my knowledge is > based more on experience, rather than a spec. > > Where are the most authoritative descriptions of the frame layout in > HotSpot? Even if there is not one in the code, is there one in John > Rose's HotSpot internals wiki? > > -- Chuck From Vladimir.Kozlov at Sun.COM Fri Aug 14 15:46:29 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 14 Aug 2009 15:46:29 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> Message-ID: <4A85E945.1020907@sun.com> I asked for it to short cut transformations when node's type is known const or top. Yes, it is not needed for the bug fix but it could reduce time spent in igvn.optimize(). Vladimir Tom Rodriguez wrote: > Why are you including the first part in this fix? I don't see the > motivation for that change. > > tom > > On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems - Santa > Clara United States wrote: > >> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >> >> Fixed 6866651: Regression: simple int sum crashes jvm (build >> 1.6.0_14-b08 and 1.7.0-ea-b59) >> >> Problem: >> set_req_X will do dead code elimination if the original input has no >> other use. However, it is possible to >> have the current node (this) removed if a dead loop exists. So, dead >> code elimination in set_req_X is not >> safe, and may cause undesired consequences (like the segfault in >> 6866651) >> >> Solution: >> Instead of doing dead code elimination immediately in set_req_X, we >> put the dead node (original input) into >> the worklist, and the dead node will eventually be eliminated when it >> is its turn to be processed. >> >> In addition, before ideal transformations, we replace a node with a >> constant if we know it computes a constant >> to skip unneeded optimizations on this node. Tests: JPRT, >> CompileTheWorld, Test case in bug report (Test.java in webrev) >> >> Thanks, >> >> Changpeng > From Changpeng.Fang at Sun.COM Fri Aug 14 15:59:21 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Fri, 14 Aug 2009 15:59:21 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> Message-ID: <4A85EC49.2020406@sun.com> On 08/14/09 15:34, Tom Rodriguez wrote: > Why are you including the first part in this fix? I don't see the > motivation for that change. > The motivation is to skip unnecessary optimizations. During work on this bug, I found cases like below. If we don't replace add with constant earlier, the ideal optimization will keep doing reassociation of the operands. const singleton \ / \ / add1 (singleton) \ const \ / \ / \ / add (singleton) Anyway, doing this should give us small benefit ( I could not see any side effect). Thanks, Changpeng > tom > > On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems - Santa > Clara United States wrote: > >> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >> >> Fixed 6866651: Regression: simple int sum crashes jvm (build >> 1.6.0_14-b08 and 1.7.0-ea-b59) >> >> Problem: >> set_req_X will do dead code elimination if the original input has no >> other use. However, it is possible to >> have the current node (this) removed if a dead loop exists. So, >> dead code elimination in set_req_X is not >> safe, and may cause undesired consequences (like the segfault in >> 6866651) >> >> Solution: >> Instead of doing dead code elimination immediately in set_req_X, we >> put the dead node (original input) into >> the worklist, and the dead node will eventually be eliminated when it >> is its turn to be processed. >> >> In addition, before ideal transformations, we replace a node with a >> constant if we know it computes a constant >> to skip unneeded optimizations on this node. Tests: JPRT, >> CompileTheWorld, Test case in bug report (Test.java in webrev) >> >> Thanks, >> >> Changpeng > From Thomas.Rodriguez at Sun.COM Fri Aug 14 16:19:14 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 14 Aug 2009 16:19:14 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <4A85E945.1020907@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E945.1020907@sun.com> Message-ID: I don't really like this code. My understanding is that this would only occur for nodes that are dead because of CCP. A dead node can only have dead users so doesn't calling add_users_to worklist on a dead node seem like a bad idea? If we want dead nodes from CCP to be cleaned up then shouldn't CCP be doing it? tom On Aug 14, 2009, at 3:46 PM, Vladimir Kozlov wrote: > I asked for it to short cut transformations when node's type is known > const or top. Yes, it is not needed for the bug fix but it could > reduce time spent in igvn.optimize(). > > Vladimir > > Tom Rodriguez wrote: >> Why are you including the first part in this fix? I don't see the >> motivation for that change. >> tom >> On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems - >> Santa Clara United States wrote: >>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>> >>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>> >>> Problem: >>> set_req_X will do dead code elimination if the original input has >>> no other use. However, it is possible to >>> have the current node (this) removed if a dead loop exists. So, >>> dead code elimination in set_req_X is not >>> safe, and may cause undesired consequences (like the segfault in >>> 6866651) >>> >>> Solution: >>> Instead of doing dead code elimination immediately in set_req_X, >>> we put the dead node (original input) into >>> the worklist, and the dead node will eventually be eliminated when >>> it is its turn to be processed. >>> >>> In addition, before ideal transformations, we replace a node with >>> a constant if we know it computes a constant >>> to skip unneeded optimizations on this node. Tests: JPRT, >>> CompileTheWorld, Test case in bug report (Test.java in webrev) >>> >>> Thanks, >>> >>> Changpeng From yamauchi at google.com Fri Aug 14 16:51:49 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Fri, 14 Aug 2009 16:51:49 -0700 Subject: stack frames In-Reply-To: <28ACC7CE-E2D0-4AD3-A556-085924046FB5@sun.com> References: <4149a0430908141348m8f87b0frd996138fbd7f5828@mail.gmail.com> <28ACC7CE-E2D0-4AD3-A556-085924046FB5@sun.com> Message-ID: Hi Tom, For C1, I found a picture in c1_FrameMap.hpp: // stack grow direction --> SP // +----------+---+----------+-------+------------------------+-----+ // |arguments | x | monitors | spill | reserved argument area | ABI | // +----------+---+----------+-------+------------------------+-----+ // // x = ABI area (SPARC) or return adress and link (i486) // ABI = ABI area (SPARC) or nothing (i486) Is that basically the same as what you described for C2 frames (i.e. do C1 and C2 have the same stack frame layout after all)? On x86, are the arguments passed via stack like the C calling convention (and how about floating point values)? Does a C2 frame have 'sender sp' as frame_x86.hpp says: public: enum { pc_return_offset = 0, // All frames link_offset = 0, return_addr_offset = 1, // non-interpreter frames sender_sp_offset = 2, or is it cruft? Also, if 'adapter frames' exist (eg from compiled -> interpreted and vice versa), what do they look like? Thanks, Hiroshi On Fri, Aug 14, 2009 at 3:49 PM, Tom Rodriguez wrote: > I don't know that there's a specification of compiled frames anywhere. ?We > generally use standard call and return sequences and construct our frames > following the platform ABI, though on x86 we don't maintain ebp as the frame > pointer but treat it as callee saved and store it in the standard place and > use no other callee saved registers. ?The frame contains monitor records, > spill slots and the outgoing argument area in that order. ?I think that's > about the extent of what's specified. ?matcher.cpp contains all the frame > layout logic for c2. > > tom > > On Aug 14, 2009, at 1:48 PM, Chuck Rasbold wrote: > >> A colleague asked me for a specification of HotSpot (actually, C2) stack >> frames. >> >> My JVM skills are a little rusty, and I realize that my knowledge is based >> more on experience, rather than a spec. >> >> Where are the most authoritative descriptions of the frame layout in >> HotSpot? ?Even if there is not one in the code, is there one in John Rose's >> HotSpot internals wiki? >> >> -- Chuck > > From Vladimir.Kozlov at Sun.COM Fri Aug 14 17:10:04 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 14 Aug 2009 17:10:04 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E945.1020907@sun.com> Message-ID: <4A85FCDC.3040903@sun.com> Tom Rodriguez wrote: > I don't really like this code. My understanding is that this would only > occur for nodes that are dead because of CCP. A dead node can only have It is not true. I thought the same before, then I added the check and hit immediately several cases when the node is alive and its type is constant: - CastII #int:1 after Parse because _gvn.set_type_bottom(ccast) in Parse::adjust_map_after_if(). - ConvI2L #long:1 in ConvI2LNode::Ideal() during next transform phase->transform( new (phase->C, 2) ConvI2LNode(y, TypeLong::make(rylo, ryhi, widen)) ) because y = #int:1 Vladimir > dead users so doesn't calling add_users_to worklist on a dead node seem > like a bad idea? If we want dead nodes from CCP to be cleaned up then > shouldn't CCP be doing it? > > tom > > On Aug 14, 2009, at 3:46 PM, Vladimir Kozlov wrote: > >> I asked for it to short cut transformations when node's type is known >> const or top. Yes, it is not needed for the bug fix but it could >> reduce time spent in igvn.optimize(). >> >> Vladimir >> >> Tom Rodriguez wrote: >>> Why are you including the first part in this fix? I don't see the >>> motivation for that change. >>> tom >>> On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems - >>> Santa Clara United States wrote: >>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>> >>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>> >>>> Problem: >>>> set_req_X will do dead code elimination if the original input has no >>>> other use. However, it is possible to >>>> have the current node (this) removed if a dead loop exists. So, >>>> dead code elimination in set_req_X is not >>>> safe, and may cause undesired consequences (like the segfault in >>>> 6866651) >>>> >>>> Solution: >>>> Instead of doing dead code elimination immediately in set_req_X, we >>>> put the dead node (original input) into >>>> the worklist, and the dead node will eventually be eliminated when >>>> it is its turn to be processed. >>>> >>>> In addition, before ideal transformations, we replace a node with a >>>> constant if we know it computes a constant >>>> to skip unneeded optimizations on this node. Tests: JPRT, >>>> CompileTheWorld, Test case in bug report (Test.java in webrev) >>>> >>>> Thanks, >>>> >>>> Changpeng > From Changpeng.Fang at Sun.COM Fri Aug 14 17:18:49 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Fri, 14 Aug 2009 17:18:49 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E945.1020907@sun.com> Message-ID: <4A85FEE9.3070302@sun.com> On 08/14/09 16:19, Tom Rodriguez wrote: > My understanding is that this would only occur for nodes that are dead > because of CCP. A dead node can only have dead users so doesn't > calling add_users_to worklist on a dead node seem like a bad idea? Do you mean we should not see a LIVE singleton (but !n->is_Con()) there? If it is the case, then we should not add the code. Thanks, Changpeng > > tom > > On Aug 14, 2009, at 3:46 PM, Vladimir Kozlov wrote: > >> I asked for it to short cut transformations when node's type is known >> const or top. Yes, it is not needed for the bug fix but it could >> reduce time spent in igvn.optimize(). >> >> Vladimir >> >> Tom Rodriguez wrote: >>> Why are you including the first part in this fix? I don't see the >>> motivation for that change. >>> tom >>> On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems - >>> Santa Clara United States wrote: >>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>> >>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>> >>>> Problem: >>>> set_req_X will do dead code elimination if the original input has >>>> no other use. However, it is possible to >>>> have the current node (this) removed if a dead loop exists. So, >>>> dead code elimination in set_req_X is not >>>> safe, and may cause undesired consequences (like the segfault in >>>> 6866651) >>>> >>>> Solution: >>>> Instead of doing dead code elimination immediately in set_req_X, we >>>> put the dead node (original input) into >>>> the worklist, and the dead node will eventually be eliminated when >>>> it is its turn to be processed. >>>> >>>> In addition, before ideal transformations, we replace a node with >>>> a constant if we know it computes a constant >>>> to skip unneeded optimizations on this node. Tests: JPRT, >>>> CompileTheWorld, Test case in bug report (Test.java in webrev) >>>> >>>> Thanks, >>>> >>>> Changpeng > From Thomas.Rodriguez at Sun.COM Fri Aug 14 17:30:54 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 14 Aug 2009 17:30:54 -0700 Subject: stack frames In-Reply-To: References: <4149a0430908141348m8f87b0frd996138fbd7f5828@mail.gmail.com> <28ACC7CE-E2D0-4AD3-A556-085924046FB5@sun.com> Message-ID: On Aug 14, 2009, at 4:51 PM, Hiroshi Yamauchi wrote: > Hi Tom, > > For C1, I found a picture in c1_FrameMap.hpp: > > // stack grow direction --> > SP > // +----------+---+----------+-------+------------------------+-----+ > // |arguments | x | monitors | spill | reserved argument area | ABI | > // +----------+---+----------+-------+------------------------+-----+ > // > // x = ABI area (SPARC) or return adress and link (i486) > // ABI = ABI area (SPARC) or nothing (i486) > > Is that basically the same as what you described for C2 frames (i.e. > do C1 and C2 have the same stack frame layout after all)? They are pretty much the same. You can have c1 and c2 generated frames on the stack in the same jvm and we don't have to treat them any differently. > On x86, are the arguments passed via stack like the C calling > convention (and how about floating point values)? The calling convention logic is in SharedRuntime::java_calling_convention and c1 and c2 use the same calling convention. On 32-bit x86, we pass the first 2 int/oop arguments in ecx and edx and up to 2 FP arguments in SSE registers with the rest on the stack. > > Does a C2 frame have 'sender sp' as frame_x86.hpp says: > > public: > enum { > pc_return_offset = 0, > // All frames > link_offset = 0, > return_addr_offset = 1, > // non-interpreter frames > sender_sp_offset = 2, The sender_sp offset is always the value of the callers ebp but with C2 ebp is an allocatable register. Stack walking should be done by asking the nmethod for it's frame_size and subtracting that from the current sp. We don't use sender_sp for stack walking compiled frames at all. > or is it cruft? > > Also, if 'adapter frames' exist (eg from compiled -> interpreted and > vice versa), what do they look like? As of 1.6 there are no adapter frames. We do have chunks of code for adapting calling conventions but they are required to operate as trampolines. There's a little bit of magic as well having to do with enlarging the callers frame to make space for stack arguments. tom > > Thanks, > Hiroshi > > On Fri, Aug 14, 2009 at 3:49 PM, Tom Rodriguez > wrote: >> I don't know that there's a specification of compiled frames >> anywhere. We >> generally use standard call and return sequences and construct our >> frames >> following the platform ABI, though on x86 we don't maintain ebp as >> the frame >> pointer but treat it as callee saved and store it in the standard >> place and >> use no other callee saved registers. The frame contains monitor >> records, >> spill slots and the outgoing argument area in that order. I think >> that's >> about the extent of what's specified. matcher.cpp contains all the >> frame >> layout logic for c2. >> >> tom >> >> On Aug 14, 2009, at 1:48 PM, Chuck Rasbold wrote: >> >>> A colleague asked me for a specification of HotSpot (actually, C2) >>> stack >>> frames. >>> >>> My JVM skills are a little rusty, and I realize that my knowledge >>> is based >>> more on experience, rather than a spec. >>> >>> Where are the most authoritative descriptions of the frame layout in >>> HotSpot? Even if there is not one in the code, is there one in >>> John Rose's >>> HotSpot internals wiki? >>> >>> -- Chuck >> >> From Thomas.Rodriguez at Sun.COM Fri Aug 14 17:36:48 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 14 Aug 2009 17:36:48 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <4A85FCDC.3040903@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E945.1020907@sun.com> <4A85FCDC.3040903@sun.com> Message-ID: <056CD9CA-7BA1-478F-AFFF-7AA0C037DFD6@Sun.COM> On Aug 14, 2009, at 5:10 PM, Vladimir Kozlov wrote: > > > Tom Rodriguez wrote: >> I don't really like this code. My understanding is that this would >> only occur for nodes that are dead because of CCP. A dead node can >> only have > > It is not true. I thought the same before, then I added the check > and hit > immediately several cases when the node is alive and its type is > constant: I saw that those were being handled as well but ignored them for this discussion since they don't seem to motivate this change. They would work just fine without this change. I don't think short circuiting the transforms of those nodes is worth duplicating the logic. tom > - CastII #int:1 after Parse because _gvn.set_type_bottom(ccast) in > Parse::adjust_map_after_if(). > - ConvI2L #long:1 in ConvI2LNode::Ideal() during next transform > phase->transform( new (phase->C, 2) ConvI2LNode(y, > TypeLong::make(rylo, ryhi, widen)) ) > because y = #int:1 > > Vladimir > >> dead users so doesn't calling add_users_to worklist on a dead node >> seem like a bad idea? If we want dead nodes from CCP to be cleaned >> up then shouldn't CCP be doing it? >> tom >> On Aug 14, 2009, at 3:46 PM, Vladimir Kozlov wrote: >>> I asked for it to short cut transformations when node's type is >>> known >>> const or top. Yes, it is not needed for the bug fix but it could >>> reduce time spent in igvn.optimize(). >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> Why are you including the first part in this fix? I don't see >>>> the motivation for that change. >>>> tom >>>> On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems - >>>> Santa Clara United States wrote: >>>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>>> >>>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>>> >>>>> Problem: >>>>> set_req_X will do dead code elimination if the original input >>>>> has no other use. However, it is possible to >>>>> have the current node (this) removed if a dead loop exists. >>>>> So, dead code elimination in set_req_X is not >>>>> safe, and may cause undesired consequences (like the segfault >>>>> in 6866651) >>>>> >>>>> Solution: >>>>> Instead of doing dead code elimination immediately in set_req_X, >>>>> we put the dead node (original input) into >>>>> the worklist, and the dead node will eventually be eliminated >>>>> when it is its turn to be processed. >>>>> >>>>> In addition, before ideal transformations, we replace a node >>>>> with a constant if we know it computes a constant >>>>> to skip unneeded optimizations on this node. Tests: JPRT, >>>>> CompileTheWorld, Test case in bug report (Test.java in webrev) >>>>> >>>>> Thanks, >>>>> >>>>> Changpeng From Thomas.Rodriguez at Sun.COM Fri Aug 14 17:48:39 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 14 Aug 2009 17:48:39 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <4A85FEE9.3070302@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E945.1020907@sun.com> <4A85FEE9.3070302@sun.com> Message-ID: <6728641C-9AC2-4F34-A333-69565B9269B4@Sun.COM> CCP does two passes. The first, analyze, is figuring out the type of a Node and the second, do_transform, is walking over the graph reachable from root and changing reachable nodes with constant types into constants. The second part can cause nodes to become unreachable. So you can end up with unreachable nodes with constant types and they still might be on the worklist. tom On Aug 14, 2009, at 5:18 PM, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > On 08/14/09 16:19, Tom Rodriguez wrote: >> My understanding is that this would only occur for nodes that are >> dead because of CCP. A dead node can only have dead users so >> doesn't calling add_users_to worklist on a dead node seem like a >> bad idea? > Do you mean we should not see a LIVE singleton (but !n->is_Con()) > there? > If it is the case, then we should not add the code. > > Thanks, > > Changpeng > > >> >> tom >> >> On Aug 14, 2009, at 3:46 PM, Vladimir Kozlov wrote: >> >>> I asked for it to short cut transformations when node's type is >>> known >>> const or top. Yes, it is not needed for the bug fix but it could >>> reduce time spent in igvn.optimize(). >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> Why are you including the first part in this fix? I don't see >>>> the motivation for that change. >>>> tom >>>> On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems - >>>> Santa Clara United States wrote: >>>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>>> >>>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>>> >>>>> Problem: >>>>> set_req_X will do dead code elimination if the original input >>>>> has no other use. However, it is possible to >>>>> have the current node (this) removed if a dead loop exists. >>>>> So, dead code elimination in set_req_X is not >>>>> safe, and may cause undesired consequences (like the segfault >>>>> in 6866651) >>>>> >>>>> Solution: >>>>> Instead of doing dead code elimination immediately in set_req_X, >>>>> we put the dead node (original input) into >>>>> the worklist, and the dead node will eventually be eliminated >>>>> when it is its turn to be processed. >>>>> >>>>> In addition, before ideal transformations, we replace a node >>>>> with a constant if we know it computes a constant >>>>> to skip unneeded optimizations on this node. Tests: JPRT, >>>>> CompileTheWorld, Test case in bug report (Test.java in webrev) >>>>> >>>>> Thanks, >>>>> >>>>> Changpeng >> > From vladimir.kozlov at sun.com Fri Aug 14 22:09:19 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Sat, 15 Aug 2009 05:09:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6869822: assert(Universe::narrow_oop_shift() == 0, "use unscaled narrow oop") Message-ID: <20090815050926.DB04CEEA0@hg.openjdk.java.net> Changeset: 1a81ea4b45d4 Author: kvn Date: 2009-08-14 12:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1a81ea4b45d4 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop") Summary: Replace the assert with narrow_oop_shift set to 0. Reviewed-by: never, jcoomes ! src/share/vm/memory/universe.cpp From thomas.rodriguez at sun.com Sat Aug 15 01:53:56 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Sat, 15 Aug 2009 08:53:56 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 3 new changesets Message-ID: <20090815085407.80B19EEA9@hg.openjdk.java.net> Changeset: a70508bb21c3 Author: never Date: 2009-08-14 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a70508bb21c3 6862863: C2 compiler fails in elide_copy() Reviewed-by: kvn ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: 55784fd95fe3 Author: never Date: 2009-08-14 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/55784fd95fe3 Merge Changeset: 7c14587118b3 Author: never Date: 2009-08-14 22:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7c14587118b3 Merge From Vladimir.Kozlov at Sun.COM Sat Aug 15 11:31:25 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Sat, 15 Aug 2009 11:31:25 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <056CD9CA-7BA1-478F-AFFF-7AA0C037DFD6@Sun.COM> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E945.1020907@sun.com> <4A85FCDC.3040903@sun.com> <056CD9CA-7BA1-478F-AFFF-7AA0C037DFD6@Sun.COM> Message-ID: <4A86FEFD.5000601@sun.com> OK. You convinced me. Vladimir Tom Rodriguez wrote: > > On Aug 14, 2009, at 5:10 PM, Vladimir Kozlov wrote: > >> >> >> Tom Rodriguez wrote: >>> I don't really like this code. My understanding is that this would >>> only occur for nodes that are dead because of CCP. A dead node can >>> only have >> >> It is not true. I thought the same before, then I added the check and hit >> immediately several cases when the node is alive and its type is >> constant: > > I saw that those were being handled as well but ignored them for this > discussion since they don't seem to motivate this change. They would > work just fine without this change. I don't think short circuiting the > transforms of those nodes is worth duplicating the logic. > > tom > >> - CastII #int:1 after Parse because _gvn.set_type_bottom(ccast) in >> Parse::adjust_map_after_if(). >> - ConvI2L #long:1 in ConvI2LNode::Ideal() during next transform >> phase->transform( new (phase->C, 2) ConvI2LNode(y, >> TypeLong::make(rylo, ryhi, widen)) ) >> because y = #int:1 >> >> Vladimir >> >>> dead users so doesn't calling add_users_to worklist on a dead node >>> seem like a bad idea? If we want dead nodes from CCP to be cleaned >>> up then shouldn't CCP be doing it? >>> tom >>> On Aug 14, 2009, at 3:46 PM, Vladimir Kozlov wrote: >>>> I asked for it to short cut transformations when node's type is known >>>> const or top. Yes, it is not needed for the bug fix but it could >>>> reduce time spent in igvn.optimize(). >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> Why are you including the first part in this fix? I don't see the >>>>> motivation for that change. >>>>> tom >>>>> On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems - >>>>> Santa Clara United States wrote: >>>>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>>>> >>>>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>>>> >>>>>> Problem: >>>>>> set_req_X will do dead code elimination if the original input has >>>>>> no other use. However, it is possible to >>>>>> have the current node (this) removed if a dead loop exists. So, >>>>>> dead code elimination in set_req_X is not >>>>>> safe, and may cause undesired consequences (like the segfault in >>>>>> 6866651) >>>>>> >>>>>> Solution: >>>>>> Instead of doing dead code elimination immediately in set_req_X, >>>>>> we put the dead node (original input) into >>>>>> the worklist, and the dead node will eventually be eliminated when >>>>>> it is its turn to be processed. >>>>>> >>>>>> In addition, before ideal transformations, we replace a node with >>>>>> a constant if we know it computes a constant >>>>>> to skip unneeded optimizations on this node. Tests: JPRT, >>>>>> CompileTheWorld, Test case in bug report (Test.java in webrev) >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Changpeng > From John.Coomes at sun.com Sat Aug 15 17:01:11 2009 From: John.Coomes at sun.com (John Coomes) Date: Sat, 15 Aug 2009 17:01:11 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E099.5040302@sun.com> Message-ID: <19079.19527.210393.892134@sun.com> Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: > You also don't need the /othervm part. Minor point, but isn't it polite to use /othervm for a test that could cause a crash? If it's run in the same vm, a crash would bring down the harness. -John > On Aug 14, 2009, at 3:09 PM, Vladimir Kozlov wrote: > > > Looks good. > > > > I would remove -server from the test options to run it with tested > > (client) VM instead of default VM. > > > > Thanks, > > Vladimir > > > > changpeng fang - Sun Microsystems - Santa Clara United States wrote: > >> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ > >> Fixed 6866651: Regression: simple int sum crashes jvm (build > >> 1.6.0_14-b08 and 1.7.0-ea-b59) > >> Problem: > >> set_req_X will do dead code elimination if the original input has > >> no other use. However, it is possible to > >> have the current node (this) removed if a dead loop exists. So, > >> dead code elimination in set_req_X is not > >> safe, and may cause undesired consequences (like the segfault in > >> 6866651) > >> Solution: > >> Instead of doing dead code elimination immediately in set_req_X, we > >> put the dead node (original input) into > >> the worklist, and the dead node will eventually be eliminated when > >> it is its turn to be processed. > >> In addition, before ideal transformations, we replace a node with > >> a constant if we know it computes a constant > >> to skip unneeded optimizations on this node. > >> Tests: JPRT, CompileTheWorld, Test case in bug report (Test.java in > >> webrev) > >> Thanks, > >> Changpeng > From Thomas.Rodriguez at Sun.COM Mon Aug 17 08:22:42 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 17 Aug 2009 08:22:42 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <19079.19527.210393.892134@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E099.5040302@sun.com> <19079.19527.210393.892134@sun.com> Message-ID: No regression test should crash unless there is a bug so I don't see that it makes much difference. The tests run more quickly without othervm so it's preferred not to use it. tom On Aug 15, 2009, at 5:01 PM, John Coomes wrote: > Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: >> You also don't need the /othervm part. > > Minor point, but isn't it polite to use /othervm for a test that could > cause a crash? If it's run in the same vm, a crash would bring down > the harness. > > -John > >> On Aug 14, 2009, at 3:09 PM, Vladimir Kozlov wrote: >> >>> Looks good. >>> >>> I would remove -server from the test options to run it with tested >>> (client) VM instead of default VM. >>> >>> Thanks, >>> Vladimir >>> >>> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>> Problem: >>>> set_req_X will do dead code elimination if the original input has >>>> no other use. However, it is possible to >>>> have the current node (this) removed if a dead loop exists. So, >>>> dead code elimination in set_req_X is not >>>> safe, and may cause undesired consequences (like the segfault in >>>> 6866651) >>>> Solution: >>>> Instead of doing dead code elimination immediately in set_req_X, we >>>> put the dead node (original input) into >>>> the worklist, and the dead node will eventually be eliminated when >>>> it is its turn to be processed. >>>> In addition, before ideal transformations, we replace a node with >>>> a constant if we know it computes a constant >>>> to skip unneeded optimizations on this node. >>>> Tests: JPRT, CompileTheWorld, Test case in bug report (Test.java in >>>> webrev) >>>> Thanks, >>>> Changpeng >> > From Changpeng.Fang at Sun.COM Mon Aug 17 08:38:15 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Mon, 17 Aug 2009 08:38:15 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E099.5040302@sun.com> <19079.19527.210393.892134@sun.com> Message-ID: <4A897967.9060701@sun.com> On 08/17/09 08:22, Tom Rodriguez wrote: > No regression test should crash unless there is a bug so I don't see > that it makes much difference. The tests run more quickly without > othervm so it's preferred not to use it. > So, should we do clean-up in test/compiler regression test suite? I have seen most of the tests use /othervm. Thanks, Changpeng > tom > > On Aug 15, 2009, at 5:01 PM, John Coomes wrote: > >> Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: >>> You also don't need the /othervm part. >> >> Minor point, but isn't it polite to use /othervm for a test that could >> cause a crash? If it's run in the same vm, a crash would bring down >> the harness. >> >> -John >> >>> On Aug 14, 2009, at 3:09 PM, Vladimir Kozlov wrote: >>> >>>> Looks good. >>>> >>>> I would remove -server from the test options to run it with tested >>>> (client) VM instead of default VM. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>>> Problem: >>>>> set_req_X will do dead code elimination if the original input has >>>>> no other use. However, it is possible to >>>>> have the current node (this) removed if a dead loop exists. So, >>>>> dead code elimination in set_req_X is not >>>>> safe, and may cause undesired consequences (like the segfault in >>>>> 6866651) >>>>> Solution: >>>>> Instead of doing dead code elimination immediately in set_req_X, we >>>>> put the dead node (original input) into >>>>> the worklist, and the dead node will eventually be eliminated when >>>>> it is its turn to be processed. >>>>> In addition, before ideal transformations, we replace a node with >>>>> a constant if we know it computes a constant >>>>> to skip unneeded optimizations on this node. >>>>> Tests: JPRT, CompileTheWorld, Test case in bug report (Test.java in >>>>> webrev) >>>>> Thanks, >>>>> Changpeng >>> >> > From Thomas.Rodriguez at Sun.COM Mon Aug 17 08:49:41 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 17 Aug 2009 08:49:41 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <4A897967.9060701@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E099.5040302@sun.com> <19079.19527.210393.892134@sun.com> <4A897967.9060701@sun.com> Message-ID: If it a test requires explicit options to fail then you have to use / othervm. I'm not sure it's worth going back and changing the existing tests, though I'm not against it. I think that when you write a test it would be preferred that it reproduces the bug without requiring any options. tom On Aug 17, 2009, at 8:38 AM, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > On 08/17/09 08:22, Tom Rodriguez wrote: >> No regression test should crash unless there is a bug so I don't >> see that it makes much difference. The tests run more quickly >> without othervm so it's preferred not to use it. >> > So, should we do clean-up in test/compiler regression test suite? I > have seen most of the tests use /othervm. > > Thanks, > > Changpeng > > >> tom >> >> On Aug 15, 2009, at 5:01 PM, John Coomes wrote: >> >>> Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: >>>> You also don't need the /othervm part. >>> >>> Minor point, but isn't it polite to use /othervm for a test that >>> could >>> cause a crash? If it's run in the same vm, a crash would bring down >>> the harness. >>> >>> -John >>> >>>> On Aug 14, 2009, at 3:09 PM, Vladimir Kozlov wrote: >>>> >>>>> Looks good. >>>>> >>>>> I would remove -server from the test options to run it with tested >>>>> (client) VM instead of default VM. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> changpeng fang - Sun Microsystems - Santa Clara United States >>>>> wrote: >>>>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>>>> Problem: >>>>>> set_req_X will do dead code elimination if the original input has >>>>>> no other use. However, it is possible to >>>>>> have the current node (this) removed if a dead loop exists. So, >>>>>> dead code elimination in set_req_X is not >>>>>> safe, and may cause undesired consequences (like the segfault in >>>>>> 6866651) >>>>>> Solution: >>>>>> Instead of doing dead code elimination immediately in >>>>>> set_req_X, we >>>>>> put the dead node (original input) into >>>>>> the worklist, and the dead node will eventually be eliminated >>>>>> when >>>>>> it is its turn to be processed. >>>>>> In addition, before ideal transformations, we replace a node >>>>>> with >>>>>> a constant if we know it computes a constant >>>>>> to skip unneeded optimizations on this node. >>>>>> Tests: JPRT, CompileTheWorld, Test case in bug report >>>>>> (Test.java in >>>>>> webrev) >>>>>> Thanks, >>>>>> Changpeng >>>> >>> >> > From Changpeng.Fang at Sun.COM Mon Aug 17 10:12:15 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Mon, 17 Aug 2009 10:12:15 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <4A86FEFD.5000601@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E945.1020907@sun.com> <4A85FCDC.3040903@sun.com> <056CD9CA-7BA1-478F-AFFF-7AA0C037DFD6@Sun.COM> <4A86FEFD.5000601@sun.com> Message-ID: <4A898F6F.3060709@sun.com> http://cr.openjdk.java.net/~cfang/6866651/webrev.01/ Ok, updated with the short cut transformation part removed. Also, for the regression test, we just use "@run main Test" to simplify the Test. Thanks, Changpeng On 08/15/09 11:31, Vladimir Kozlov wrote: > OK. You convinced me. > > Vladimir > > Tom Rodriguez wrote: >> >> On Aug 14, 2009, at 5:10 PM, Vladimir Kozlov wrote: >> >>> >>> >>> Tom Rodriguez wrote: >>>> I don't really like this code. My understanding is that this would >>>> only occur for nodes that are dead because of CCP. A dead node can >>>> only have >>> >>> It is not true. I thought the same before, then I added the check >>> and hit >>> immediately several cases when the node is alive and its type is >>> constant: >> >> I saw that those were being handled as well but ignored them for this >> discussion since they don't seem to motivate this change. They would >> work just fine without this change. I don't think short circuiting >> the transforms of those nodes is worth duplicating the logic. >> >> tom >> >>> - CastII #int:1 after Parse because _gvn.set_type_bottom(ccast) in >>> Parse::adjust_map_after_if(). >>> - ConvI2L #long:1 in ConvI2LNode::Ideal() during next transform >>> phase->transform( new (phase->C, 2) ConvI2LNode(y, >>> TypeLong::make(rylo, ryhi, widen)) ) >>> because y = #int:1 >>> >>> Vladimir >>> >>>> dead users so doesn't calling add_users_to worklist on a dead node >>>> seem like a bad idea? If we want dead nodes from CCP to be cleaned >>>> up then shouldn't CCP be doing it? >>>> tom >>>> On Aug 14, 2009, at 3:46 PM, Vladimir Kozlov wrote: >>>>> I asked for it to short cut transformations when node's type is known >>>>> const or top. Yes, it is not needed for the bug fix but it could >>>>> reduce time spent in igvn.optimize(). >>>>> >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> Why are you including the first part in this fix? I don't see >>>>>> the motivation for that change. >>>>>> tom >>>>>> On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems - >>>>>> Santa Clara United States wrote: >>>>>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>>>>> >>>>>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>>>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>>>>> >>>>>>> Problem: >>>>>>> set_req_X will do dead code elimination if the original input >>>>>>> has no other use. However, it is possible to >>>>>>> have the current node (this) removed if a dead loop exists. >>>>>>> So, dead code elimination in set_req_X is not >>>>>>> safe, and may cause undesired consequences (like the segfault >>>>>>> in 6866651) >>>>>>> >>>>>>> Solution: >>>>>>> Instead of doing dead code elimination immediately in set_req_X, >>>>>>> we put the dead node (original input) into >>>>>>> the worklist, and the dead node will eventually be eliminated >>>>>>> when it is its turn to be processed. >>>>>>> >>>>>>> In addition, before ideal transformations, we replace a node >>>>>>> with a constant if we know it computes a constant >>>>>>> to skip unneeded optimizations on this node. Tests: JPRT, >>>>>>> CompileTheWorld, Test case in bug report (Test.java in webrev) >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Changpeng >> From Vladimir.Kozlov at Sun.COM Mon Aug 17 10:16:09 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 17 Aug 2009 10:16:09 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <4A898F6F.3060709@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E945.1020907@sun.com> <4A85FCDC.3040903@sun.com> <056CD9CA-7BA1-478F-AFFF-7AA0C037DFD6@Sun.COM> <4A86FEFD.5000601@sun.com> <4A898F6F.3060709@sun.com> Message-ID: <4A899059.1080200@sun.com> Looks good. Vladimir changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6866651/webrev.01/ > > Ok, updated with the short cut transformation part removed. Also, > for the regression test, we just use "@run main Test" to simplify > the Test. > > Thanks, > > Changpeng > > > > On 08/15/09 11:31, Vladimir Kozlov wrote: >> OK. You convinced me. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> >>> On Aug 14, 2009, at 5:10 PM, Vladimir Kozlov wrote: >>> >>>> >>>> >>>> Tom Rodriguez wrote: >>>>> I don't really like this code. My understanding is that this would >>>>> only occur for nodes that are dead because of CCP. A dead node can >>>>> only have >>>> >>>> It is not true. I thought the same before, then I added the check >>>> and hit >>>> immediately several cases when the node is alive and its type is >>>> constant: >>> >>> I saw that those were being handled as well but ignored them for this >>> discussion since they don't seem to motivate this change. They would >>> work just fine without this change. I don't think short circuiting >>> the transforms of those nodes is worth duplicating the logic. >>> >>> tom >>> >>>> - CastII #int:1 after Parse because _gvn.set_type_bottom(ccast) in >>>> Parse::adjust_map_after_if(). >>>> - ConvI2L #long:1 in ConvI2LNode::Ideal() during next transform >>>> phase->transform( new (phase->C, 2) ConvI2LNode(y, >>>> TypeLong::make(rylo, ryhi, widen)) ) >>>> because y = #int:1 >>>> >>>> Vladimir >>>> >>>>> dead users so doesn't calling add_users_to worklist on a dead node >>>>> seem like a bad idea? If we want dead nodes from CCP to be cleaned >>>>> up then shouldn't CCP be doing it? >>>>> tom >>>>> On Aug 14, 2009, at 3:46 PM, Vladimir Kozlov wrote: >>>>>> I asked for it to short cut transformations when node's type is known >>>>>> const or top. Yes, it is not needed for the bug fix but it could >>>>>> reduce time spent in igvn.optimize(). >>>>>> >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> Why are you including the first part in this fix? I don't see >>>>>>> the motivation for that change. >>>>>>> tom >>>>>>> On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems - >>>>>>> Santa Clara United States wrote: >>>>>>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>>>>>> >>>>>>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>>>>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>>>>>> >>>>>>>> Problem: >>>>>>>> set_req_X will do dead code elimination if the original input >>>>>>>> has no other use. However, it is possible to >>>>>>>> have the current node (this) removed if a dead loop exists. >>>>>>>> So, dead code elimination in set_req_X is not >>>>>>>> safe, and may cause undesired consequences (like the segfault >>>>>>>> in 6866651) >>>>>>>> >>>>>>>> Solution: >>>>>>>> Instead of doing dead code elimination immediately in set_req_X, >>>>>>>> we put the dead node (original input) into >>>>>>>> the worklist, and the dead node will eventually be eliminated >>>>>>>> when it is its turn to be processed. >>>>>>>> >>>>>>>> In addition, before ideal transformations, we replace a node >>>>>>>> with a constant if we know it computes a constant >>>>>>>> to skip unneeded optimizations on this node. Tests: JPRT, >>>>>>>> CompileTheWorld, Test case in bug report (Test.java in webrev) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Changpeng >>> > From Thomas.Rodriguez at Sun.COM Mon Aug 17 10:31:11 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 17 Aug 2009 10:31:11 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <4A899059.1080200@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E945.1020907@sun.com> <4A85FCDC.3040903@sun.com> <056CD9CA-7BA1-478F-AFFF-7AA0C037DFD6@Sun.COM> <4A86FEFD.5000601@sun.com> <4A898F6F.3060709@sun.com> <4A899059.1080200@sun.com> Message-ID: <13A26518-8B7B-458E-BD85-E84D21A4F788@Sun.COM> Looks good. tom On Aug 17, 2009, at 10:16 AM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > changpeng fang - Sun Microsystems - Santa Clara United States wrote: >> http://cr.openjdk.java.net/~cfang/6866651/webrev.01/ >> Ok, updated with the short cut transformation part removed. Also, >> for the regression test, we just use "@run main Test" to simplify >> the Test. >> Thanks, >> Changpeng >> On 08/15/09 11:31, Vladimir Kozlov wrote: >>> OK. You convinced me. >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> >>>> On Aug 14, 2009, at 5:10 PM, Vladimir Kozlov wrote: >>>> >>>>> >>>>> >>>>> Tom Rodriguez wrote: >>>>>> I don't really like this code. My understanding is that this >>>>>> would only occur for nodes that are dead because of CCP. A >>>>>> dead node can only have >>>>> >>>>> It is not true. I thought the same before, then I added the >>>>> check and hit >>>>> immediately several cases when the node is alive and its type is >>>>> constant: >>>> >>>> I saw that those were being handled as well but ignored them for >>>> this discussion since they don't seem to motivate this change. >>>> They would work just fine without this change. I don't think >>>> short circuiting the transforms of those nodes is worth >>>> duplicating the logic. >>>> >>>> tom >>>> >>>>> - CastII #int:1 after Parse because _gvn.set_type_bottom(ccast) in >>>>> Parse::adjust_map_after_if(). >>>>> - ConvI2L #long:1 in ConvI2LNode::Ideal() during next transform >>>>> phase->transform( new (phase->C, 2) ConvI2LNode(y, >>>>> TypeLong::make(rylo, ryhi, widen)) ) >>>>> because y = #int:1 >>>>> >>>>> Vladimir >>>>> >>>>>> dead users so doesn't calling add_users_to worklist on a dead >>>>>> node seem like a bad idea? If we want dead nodes from CCP to >>>>>> be cleaned up then shouldn't CCP be doing it? >>>>>> tom >>>>>> On Aug 14, 2009, at 3:46 PM, Vladimir Kozlov wrote: >>>>>>> I asked for it to short cut transformations when node's type >>>>>>> is known >>>>>>> const or top. Yes, it is not needed for the bug fix but it could >>>>>>> reduce time spent in igvn.optimize(). >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> Why are you including the first part in this fix? I don't >>>>>>>> see the motivation for that change. >>>>>>>> tom >>>>>>>> On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun >>>>>>>> Microsystems - Santa Clara United States wrote: >>>>>>>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>>>>>>> >>>>>>>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>>>>>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>>>>>>> >>>>>>>>> Problem: >>>>>>>>> set_req_X will do dead code elimination if the original >>>>>>>>> input has no other use. However, it is possible to >>>>>>>>> have the current node (this) removed if a dead loop exists. >>>>>>>>> So, dead code elimination in set_req_X is not >>>>>>>>> safe, and may cause undesired consequences (like the >>>>>>>>> segfault in 6866651) >>>>>>>>> >>>>>>>>> Solution: >>>>>>>>> Instead of doing dead code elimination immediately in >>>>>>>>> set_req_X, we put the dead node (original input) into >>>>>>>>> the worklist, and the dead node will eventually be >>>>>>>>> eliminated when it is its turn to be processed. >>>>>>>>> >>>>>>>>> In addition, before ideal transformations, we replace a >>>>>>>>> node with a constant if we know it computes a constant >>>>>>>>> to skip unneeded optimizations on this node. Tests: JPRT, >>>>>>>>> CompileTheWorld, Test case in bug report (Test.java in webrev) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Changpeng >>>> From Thomas.Rodriguez at Sun.COM Mon Aug 17 10:36:17 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 17 Aug 2009 10:36:17 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <4A86FEFD.5000601@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E945.1020907@sun.com> <4A85FCDC.3040903@sun.com> <056CD9CA-7BA1-478F-AFFF-7AA0C037DFD6@Sun.COM> <4A86FEFD.5000601@sun.com> Message-ID: It occurred to me later that it also side steps the handling of dead control if you do it early. If the control of the cast has become top then we would replace it with the constant type instead of replacing it with top which doesn't seem right. tom On Aug 15, 2009, at 11:31 AM, Vladimir Kozlov wrote: > OK. You convinced me. > > Vladimir > > Tom Rodriguez wrote: >> On Aug 14, 2009, at 5:10 PM, Vladimir Kozlov wrote: >>> >>> >>> Tom Rodriguez wrote: >>>> I don't really like this code. My understanding is that this >>>> would only occur for nodes that are dead because of CCP. A dead >>>> node can only have >>> >>> It is not true. I thought the same before, then I added the check >>> and hit >>> immediately several cases when the node is alive and its type is >>> constant: >> I saw that those were being handled as well but ignored them for >> this discussion since they don't seem to motivate this change. >> They would work just fine without this change. I don't think short >> circuiting the transforms of those nodes is worth duplicating the >> logic. >> tom >>> - CastII #int:1 after Parse because _gvn.set_type_bottom(ccast) in >>> Parse::adjust_map_after_if(). >>> - ConvI2L #long:1 in ConvI2LNode::Ideal() during next transform >>> phase->transform( new (phase->C, 2) ConvI2LNode(y, >>> TypeLong::make(rylo, ryhi, widen)) ) >>> because y = #int:1 >>> >>> Vladimir >>> >>>> dead users so doesn't calling add_users_to worklist on a dead >>>> node seem like a bad idea? If we want dead nodes from CCP to be >>>> cleaned up then shouldn't CCP be doing it? >>>> tom >>>> On Aug 14, 2009, at 3:46 PM, Vladimir Kozlov wrote: >>>>> I asked for it to short cut transformations when node's type is >>>>> known >>>>> const or top. Yes, it is not needed for the bug fix but it could >>>>> reduce time spent in igvn.optimize(). >>>>> >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> Why are you including the first part in this fix? I don't see >>>>>> the motivation for that change. >>>>>> tom >>>>>> On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems >>>>>> - Santa Clara United States wrote: >>>>>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>>>>> >>>>>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>>>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>>>>> >>>>>>> Problem: >>>>>>> set_req_X will do dead code elimination if the original input >>>>>>> has no other use. However, it is possible to >>>>>>> have the current node (this) removed if a dead loop exists. >>>>>>> So, dead code elimination in set_req_X is not >>>>>>> safe, and may cause undesired consequences (like the segfault >>>>>>> in 6866651) >>>>>>> >>>>>>> Solution: >>>>>>> Instead of doing dead code elimination immediately in >>>>>>> set_req_X, we put the dead node (original input) into >>>>>>> the worklist, and the dead node will eventually be eliminated >>>>>>> when it is its turn to be processed. >>>>>>> >>>>>>> In addition, before ideal transformations, we replace a node >>>>>>> with a constant if we know it computes a constant >>>>>>> to skip unneeded optimizations on this node. Tests: JPRT, >>>>>>> CompileTheWorld, Test case in bug report (Test.java in webrev) >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Changpeng From Vladimir.Kozlov at Sun.COM Mon Aug 17 10:58:24 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 17 Aug 2009 10:58:24 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E945.1020907@sun.com> <4A85FCDC.3040903@sun.com> <056CD9CA-7BA1-478F-AFFF-7AA0C037DFD6@Sun.COM> <4A86FEFD.5000601@sun.com> Message-ID: <4A899A40.9060503@sun.com> Yes, you are right. Vladimir Tom Rodriguez wrote: > It occurred to me later that it also side steps the handling of dead > control if you do it early. If the control of the cast has become top > then we would replace it with the constant type instead of replacing it > with top which doesn't seem right. > > tom > > On Aug 15, 2009, at 11:31 AM, Vladimir Kozlov wrote: > >> OK. You convinced me. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> On Aug 14, 2009, at 5:10 PM, Vladimir Kozlov wrote: >>>> >>>> >>>> Tom Rodriguez wrote: >>>>> I don't really like this code. My understanding is that this would >>>>> only occur for nodes that are dead because of CCP. A dead node can >>>>> only have >>>> >>>> It is not true. I thought the same before, then I added the check >>>> and hit >>>> immediately several cases when the node is alive and its type is >>>> constant: >>> I saw that those were being handled as well but ignored them for this >>> discussion since they don't seem to motivate this change. They would >>> work just fine without this change. I don't think short circuiting >>> the transforms of those nodes is worth duplicating the logic. >>> tom >>>> - CastII #int:1 after Parse because _gvn.set_type_bottom(ccast) in >>>> Parse::adjust_map_after_if(). >>>> - ConvI2L #long:1 in ConvI2LNode::Ideal() during next transform >>>> phase->transform( new (phase->C, 2) ConvI2LNode(y, >>>> TypeLong::make(rylo, ryhi, widen)) ) >>>> because y = #int:1 >>>> >>>> Vladimir >>>> >>>>> dead users so doesn't calling add_users_to worklist on a dead node >>>>> seem like a bad idea? If we want dead nodes from CCP to be cleaned >>>>> up then shouldn't CCP be doing it? >>>>> tom >>>>> On Aug 14, 2009, at 3:46 PM, Vladimir Kozlov wrote: >>>>>> I asked for it to short cut transformations when node's type is known >>>>>> const or top. Yes, it is not needed for the bug fix but it could >>>>>> reduce time spent in igvn.optimize(). >>>>>> >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> Why are you including the first part in this fix? I don't see >>>>>>> the motivation for that change. >>>>>>> tom >>>>>>> On Aug 14, 2009, at 2:50 PM, changpeng fang - Sun Microsystems - >>>>>>> Santa Clara United States wrote: >>>>>>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>>>>>> >>>>>>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>>>>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>>>>>> >>>>>>>> Problem: >>>>>>>> set_req_X will do dead code elimination if the original input >>>>>>>> has no other use. However, it is possible to >>>>>>>> have the current node (this) removed if a dead loop exists. >>>>>>>> So, dead code elimination in set_req_X is not >>>>>>>> safe, and may cause undesired consequences (like the segfault >>>>>>>> in 6866651) >>>>>>>> >>>>>>>> Solution: >>>>>>>> Instead of doing dead code elimination immediately in set_req_X, >>>>>>>> we put the dead node (original input) into >>>>>>>> the worklist, and the dead node will eventually be eliminated >>>>>>>> when it is its turn to be processed. >>>>>>>> >>>>>>>> In addition, before ideal transformations, we replace a node >>>>>>>> with a constant if we know it computes a constant >>>>>>>> to skip unneeded optimizations on this node. Tests: JPRT, >>>>>>>> CompileTheWorld, Test case in bug report (Test.java in webrev) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Changpeng > From yamauchi at google.com Mon Aug 17 11:07:25 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Mon, 17 Aug 2009 11:07:25 -0700 Subject: stack frames In-Reply-To: References: <4149a0430908141348m8f87b0frd996138fbd7f5828@mail.gmail.com> <28ACC7CE-E2D0-4AD3-A556-085924046FB5@sun.com> Message-ID: Tom, Thanks a lot as always. That is very helpful. On Fri, Aug 14, 2009 at 5:30 PM, Tom Rodriguez wrote: > > On Aug 14, 2009, at 4:51 PM, Hiroshi Yamauchi wrote: > >> Hi Tom, >> >> For C1, I found a picture in c1_FrameMap.hpp: >> >> // ? stack grow direction --> >> SP >> // ?+----------+---+----------+-------+------------------------+-----+ >> // ?|arguments | x | monitors | spill | reserved argument area | ABI | >> // ?+----------+---+----------+-------+------------------------+-----+ >> // >> // ?x = ?ABI area (SPARC) or ?return adress and link (i486) >> // ?ABI ?= ABI area (SPARC) or nothing (i486) >> >> Is that basically the same as what you described for C2 frames (i.e. >> do C1 and C2 have the same stack frame layout after all)? > > They are pretty much the same. ?You can have c1 and c2 generated frames on > the stack in the same jvm and we don't have to treat them any differently. > >> On x86, are the arguments passed via stack like the C calling >> convention (and how about floating point values)? > > The calling convention logic is in SharedRuntime::java_calling_convention > and c1 and c2 use the same calling convention. ?On 32-bit x86, we pass the > first 2 int/oop arguments in ecx and edx and up to 2 FP arguments in SSE > registers with the rest on the stack. > >> >> Does a C2 frame have 'sender sp' as frame_x86.hpp says: >> >> public: >> ?enum { >> ? pc_return_offset ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? = ?0, >> ? // All frames >> ? link_offset ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?= ?0, >> ? return_addr_offset ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? = ?1, >> ? // non-interpreter frames >> ? sender_sp_offset ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? = ?2, > > The sender_sp offset is always the value of the callers ebp but with C2 ebp > is an allocatable register. ?Stack walking should be done by asking the > nmethod for it's frame_size and subtracting that from the current sp. ?We > don't use sender_sp for stack walking compiled frames at all. > >> or is it cruft? >> >> Also, if 'adapter frames' exist (eg from compiled -> interpreted and >> vice versa), what do they look like? > > As of 1.6 there are no adapter frames. ?We do have chunks of code for > adapting calling conventions but they are required to operate as > trampolines. ?There's a little bit of magic as well having to do with > enlarging the callers frame to make space for stack arguments. > > tom > >> >> Thanks, >> Hiroshi >> >> On Fri, Aug 14, 2009 at 3:49 PM, Tom Rodriguez >> wrote: >>> >>> I don't know that there's a specification of compiled frames anywhere. >>> ?We >>> generally use standard call and return sequences and construct our frames >>> following the platform ABI, though on x86 we don't maintain ebp as the >>> frame >>> pointer but treat it as callee saved and store it in the standard place >>> and >>> use no other callee saved registers. ?The frame contains monitor records, >>> spill slots and the outgoing argument area in that order. ?I think that's >>> about the extent of what's specified. ?matcher.cpp contains all the frame >>> layout logic for c2. >>> >>> tom >>> >>> On Aug 14, 2009, at 1:48 PM, Chuck Rasbold wrote: >>> >>>> A colleague asked me for a specification of HotSpot (actually, C2) stack >>>> frames. >>>> >>>> My JVM skills are a little rusty, and I realize that my knowledge is >>>> based >>>> more on experience, rather than a spec. >>>> >>>> Where are the most authoritative descriptions of the frame layout in >>>> HotSpot? ?Even if there is not one in the code, is there one in John >>>> Rose's >>>> HotSpot internals wiki? >>>> >>>> -- Chuck >>> >>> > > From changpeng.fang at sun.com Mon Aug 17 11:59:05 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Mon, 17 Aug 2009 18:59:05 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6829127: Deoptimization Failure on Specjvm98 _227_mtrt with -XX:+DeoptimizeALot since Hs11 b01 Message-ID: <20090817185912.B5959EF2D@hg.openjdk.java.net> Changeset: c8e2135f7e30 Author: cfang Date: 2009-08-17 09:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c8e2135f7e30 6829127: Deoptimization Failure on Specjvm98 _227_mtrt with -XX:+DeoptimizeALot since Hs11 b01 Summary: Make sure the control word is correct in deopt_blob after restore_result_registers Reviewed-by: kvn, never ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp From John.Coomes at sun.com Mon Aug 17 12:03:33 2009 From: John.Coomes at sun.com (John Coomes) Date: Mon, 17 Aug 2009 12:03:33 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E099.5040302@sun.com> <19079.19527.210393.892134@sun.com> Message-ID: <19081.43397.608798.948577@sun.com> Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: > No regression test should crash unless there is a bug so I don't see > that it makes much difference. The tests run more quickly without > othervm so it's preferred not to use it. It would make comparing old/new VMs a little easier, since they could use the same set of tests, which is what I usually do. I guess it's not hard to use separate testbases; just need to remember to do it. -John > On Aug 15, 2009, at 5:01 PM, John Coomes wrote: > > > Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: > >> You also don't need the /othervm part. > > > > Minor point, but isn't it polite to use /othervm for a test that could > > cause a crash? If it's run in the same vm, a crash would bring down > > the harness. > > > > -John > > > >> On Aug 14, 2009, at 3:09 PM, Vladimir Kozlov wrote: > >> > >>> Looks good. > >>> > >>> I would remove -server from the test options to run it with tested > >>> (client) VM instead of default VM. > >>> > >>> Thanks, > >>> Vladimir > >>> > >>> changpeng fang - Sun Microsystems - Santa Clara United States wrote: > >>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ > >>>> Fixed 6866651: Regression: simple int sum crashes jvm (build > >>>> 1.6.0_14-b08 and 1.7.0-ea-b59) > >>>> Problem: > >>>> set_req_X will do dead code elimination if the original input has > >>>> no other use. However, it is possible to > >>>> have the current node (this) removed if a dead loop exists. So, > >>>> dead code elimination in set_req_X is not > >>>> safe, and may cause undesired consequences (like the segfault in > >>>> 6866651) > >>>> Solution: > >>>> Instead of doing dead code elimination immediately in set_req_X, we > >>>> put the dead node (original input) into > >>>> the worklist, and the dead node will eventually be eliminated when > >>>> it is its turn to be processed. > >>>> In addition, before ideal transformations, we replace a node with > >>>> a constant if we know it computes a constant > >>>> to skip unneeded optimizations on this node. > >>>> Tests: JPRT, CompileTheWorld, Test case in bug report (Test.java in > >>>> webrev) > >>>> Thanks, > >>>> Changpeng > >> > > > From Thomas.Rodriguez at Sun.COM Mon Aug 17 12:21:09 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 17 Aug 2009 12:21:09 -0700 Subject: Request for reviews (XS): 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) In-Reply-To: <19081.43397.608798.948577@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A85DC21.6060605@sun.com> <4A85E099.5040302@sun.com> <19079.19527.210393.892134@sun.com> <19081.43397.608798.948577@sun.com> Message-ID: One way or another the harness has to be robust in the face of crashes so I don't see any argument for forcing the use of /othervm. Actually I think you can tell the harness to always run the tests in separate VM. tom On Aug 17, 2009, at 12:03 PM, John Coomes wrote: > Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: >> No regression test should crash unless there is a bug so I don't see >> that it makes much difference. The tests run more quickly without >> othervm so it's preferred not to use it. > > It would make comparing old/new VMs a little easier, since they could > use the same set of tests, which is what I usually do. I guess it's > not hard to use separate testbases; just need to remember to do it. > > -John > >> On Aug 15, 2009, at 5:01 PM, John Coomes wrote: >> >>> Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: >>>> You also don't need the /othervm part. >>> >>> Minor point, but isn't it polite to use /othervm for a test that >>> could >>> cause a crash? If it's run in the same vm, a crash would bring down >>> the harness. >>> >>> -John >>> >>>> On Aug 14, 2009, at 3:09 PM, Vladimir Kozlov wrote: >>>> >>>>> Looks good. >>>>> >>>>> I would remove -server from the test options to run it with tested >>>>> (client) VM instead of default VM. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> changpeng fang - Sun Microsystems - Santa Clara United States >>>>> wrote: >>>>>> http://cr.openjdk.java.net/~cfang/6866651/webrev.00/ >>>>>> Fixed 6866651: Regression: simple int sum crashes jvm (build >>>>>> 1.6.0_14-b08 and 1.7.0-ea-b59) >>>>>> Problem: >>>>>> set_req_X will do dead code elimination if the original input has >>>>>> no other use. However, it is possible to >>>>>> have the current node (this) removed if a dead loop exists. So, >>>>>> dead code elimination in set_req_X is not >>>>>> safe, and may cause undesired consequences (like the segfault in >>>>>> 6866651) >>>>>> Solution: >>>>>> Instead of doing dead code elimination immediately in >>>>>> set_req_X, we >>>>>> put the dead node (original input) into >>>>>> the worklist, and the dead node will eventually be eliminated >>>>>> when >>>>>> it is its turn to be processed. >>>>>> In addition, before ideal transformations, we replace a node >>>>>> with >>>>>> a constant if we know it computes a constant >>>>>> to skip unneeded optimizations on this node. >>>>>> Tests: JPRT, CompileTheWorld, Test case in bug report >>>>>> (Test.java in >>>>>> webrev) >>>>>> Thanks, >>>>>> Changpeng >>>> >>> >> > From changpeng.fang at sun.com Mon Aug 17 14:28:13 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Mon, 17 Aug 2009 21:28:13 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) Message-ID: <20090817212823.DACDDEF58@hg.openjdk.java.net> Changeset: 662f330d7275 Author: cfang Date: 2009-08-17 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/662f330d7275 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) Summary: delay dead code elimination in set_req_X to make it safe Reviewed-by: kvn, never ! src/share/vm/opto/phaseX.cpp + test/compiler/6866651/Test.java From thomas.rodriguez at sun.com Mon Aug 17 16:55:05 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Mon, 17 Aug 2009 23:55:05 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6795465: Crash in assembler_sparc.cpp with client compiler on solaris-sparc Message-ID: <20090817235513.40A1CEFBD@hg.openjdk.java.net> Changeset: d0acbc302e14 Author: never Date: 2009-08-17 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d0acbc302e14 6795465: Crash in assembler_sparc.cpp with client compiler on solaris-sparc Reviewed-by: twisti, cfang ! src/cpu/sparc/vm/c1_Defs_sparc.hpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/share/vm/includeDB_compiler1 + test/compiler/6795465/Test6795465.java From Vladimir.Kozlov at Sun.COM Tue Aug 18 14:35:12 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 18 Aug 2009 14:35:12 -0700 Subject: string methods intrinsics, place for checks Message-ID: <4A8B1E90.9070000@sun.com> I am modifying our string intrinsics to pass char[] pointers and counters instead of string oops to allow EA eliminate non-escaping string object (6827605). This will also allow to do some checks in ideal graph instead of in a mach node encoding. But it may affect ideal optimizations since it may complicate control flow. So I need your opinion where I should draw the line. For example, for String.equals() I compare counters in ideal but check it for 0 in mach (mach node needs only one counter) since == 0 is rare case. Thanks, Vladimir From Thomas.Rodriguez at Sun.COM Tue Aug 18 15:51:10 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 18 Aug 2009 15:51:10 -0700 Subject: string methods intrinsics, place for checks In-Reply-To: <4A8B1E90.9070000@sun.com> References: <4A8B1E90.9070000@sun.com> Message-ID: <536B6ABA-DE66-4AB4-A2E9-A01FD333A09A@sun.com> I don't know that there's a clear place to draw the line. I'd tend towards writing things in ideal if possible since that exposes it to optimization and reduces the amount of assembly. I'd probably have a stronger opinion about a more concrete example. tom On Aug 18, 2009, at 2:35 PM, Vladimir Kozlov wrote: > I am modifying our string intrinsics to pass char[] pointers and > counters instead of string oops to allow EA eliminate non-escaping > string object (6827605). This will also allow to do some checks > in ideal graph instead of in a mach node encoding. But it may affect > ideal optimizations since it may complicate control flow. > > So I need your opinion where I should draw the line. > > For example, for String.equals() I compare counters in ideal but > check it for 0 in mach (mach node needs only one counter) since > == 0 is rare case. > > Thanks, > Vladimir > > From Vladimir.Kozlov at Sun.COM Tue Aug 18 16:10:57 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 18 Aug 2009 16:10:57 -0700 Subject: string methods intrinsics, place for checks In-Reply-To: <536B6ABA-DE66-4AB4-A2E9-A01FD333A09A@sun.com> References: <4A8B1E90.9070000@sun.com> <536B6ABA-DE66-4AB4-A2E9-A01FD333A09A@sun.com> Message-ID: <4A8B3501.8030605@sun.com> I will send first draft tomorrow so you will see. An other question: should I add the check for argument->is_Con() (string constant) and load argument's parameters statically (as we do in indexOf intrinsic on not SSE42 path)? Or should I add the ideal optimization? Currently ideal optimizations do not convert loadI(AddP(ConP, 28)) to static load. Thanks, Vladimir Tom Rodriguez wrote: > I don't know that there's a clear place to draw the line. I'd tend > towards writing things in ideal if possible since that exposes it to > optimization and reduces the amount of assembly. I'd probably have a > stronger opinion about a more concrete example. > > tom > > On Aug 18, 2009, at 2:35 PM, Vladimir Kozlov wrote: > >> I am modifying our string intrinsics to pass char[] pointers and >> counters instead of string oops to allow EA eliminate non-escaping >> string object (6827605). This will also allow to do some checks >> in ideal graph instead of in a mach node encoding. But it may affect >> ideal optimizations since it may complicate control flow. >> >> So I need your opinion where I should draw the line. >> >> For example, for String.equals() I compare counters in ideal but >> check it for 0 in mach (mach node needs only one counter) since >> == 0 is rare case. >> >> Thanks, >> Vladimir >> >> > From Changpeng.Fang at Sun.COM Tue Aug 18 16:23:01 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Tue, 18 Aug 2009 16:23:01 -0700 Subject: reexecute bit in SA In-Reply-To: <536B6ABA-DE66-4AB4-A2E9-A01FD333A09A@sun.com> References: <4A8B1E90.9070000@sun.com> <536B6ABA-DE66-4AB4-A2E9-A01FD333A09A@sun.com> Message-ID: <4A8B37D5.1070007@sun.com> I added a reexecute bit field in the pcDesc. In the vm, the reexecute info is passed as an argument to describe_scope. I don't know how to do this in SA, i.e., how can the SA extracts the reexecute info from the VM? Can I simply ignore the newly added field in SA at this moment? Thanks, Changpeng From Thomas.Rodriguez at Sun.COM Tue Aug 18 18:55:52 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 18 Aug 2009 18:55:52 -0700 Subject: reexecute bit in SA In-Reply-To: <4A8B37D5.1070007@sun.com> References: <4A8B1E90.9070000@sun.com> <536B6ABA-DE66-4AB4-A2E9-A01FD333A09A@sun.com> <4A8B37D5.1070007@sun.com> Message-ID: <25061F1C-0EE7-4FA8-9985-C8886852231D@sun.com> You should at least add the new field to vmStructs.cpp. Search for the reference to _scope_decode_offset in that file and make a duplicate of that line that references the new field instead. If you want to fix PcDesc.java as well, again use the existing code in that file as a guide. tom On Aug 18, 2009, at 4:23 PM, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > I added a reexecute bit field in the pcDesc. In the vm, the > reexecute info is passed as an argument to describe_scope. > I don't know how to do this in SA, i.e., how can the SA extracts > the reexecute info from the VM? > Can I simply ignore the newly added field in SA at this moment? > > Thanks, > > Changpeng From Thomas.Rodriguez at Sun.COM Tue Aug 18 18:58:23 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 18 Aug 2009 18:58:23 -0700 Subject: string methods intrinsics, place for checks In-Reply-To: <4A8B3501.8030605@sun.com> References: <4A8B1E90.9070000@sun.com> <536B6ABA-DE66-4AB4-A2E9-A01FD333A09A@sun.com> <4A8B3501.8030605@sun.com> Message-ID: If you mean constant folding the loads of the final fields of a Constant string, I've got some changes for that coming. tom On Aug 18, 2009, at 4:10 PM, Vladimir Kozlov wrote: > I will send first draft tomorrow so you will see. > > An other question: should I add the check for argument->is_Con() > (string constant) and load argument's parameters statically > (as we do in indexOf intrinsic on not SSE42 path)? > > Or should I add the ideal optimization? > > Currently ideal optimizations do not convert loadI(AddP(ConP, 28)) > to static load. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> I don't know that there's a clear place to draw the line. I'd tend >> towards writing things in ideal if possible since that exposes it >> to optimization and reduces the amount of assembly. I'd probably >> have a stronger opinion about a more concrete example. >> tom >> On Aug 18, 2009, at 2:35 PM, Vladimir Kozlov wrote: >>> I am modifying our string intrinsics to pass char[] pointers and >>> counters instead of string oops to allow EA eliminate non-escaping >>> string object (6827605). This will also allow to do some checks >>> in ideal graph instead of in a mach node encoding. But it may affect >>> ideal optimizations since it may complicate control flow. >>> >>> So I need your opinion where I should draw the line. >>> >>> For example, for String.equals() I compare counters in ideal but >>> check it for 0 in mach (mach node needs only one counter) since >>> == 0 is rare case. >>> >>> Thanks, >>> Vladimir >>> >>> From Vladimir.Kozlov at Sun.COM Tue Aug 18 19:15:22 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 18 Aug 2009 19:15:22 -0700 Subject: string methods intrinsics, place for checks In-Reply-To: References: <4A8B1E90.9070000@sun.com> <536B6ABA-DE66-4AB4-A2E9-A01FD333A09A@sun.com> <4A8B3501.8030605@sun.com> Message-ID: <4A8B603A.9020703@sun.com> Tom Rodriguez wrote: > If you mean constant folding the loads of the final fields of a Constant > string, I've got some changes for that coming. Yes, I meant that. And here is the first draft for string intrinsics changes: http://cr.openjdk.java.net/~kvn/6827605/webrev.00 Vladimir > > tom > > On Aug 18, 2009, at 4:10 PM, Vladimir Kozlov wrote: > >> I will send first draft tomorrow so you will see. >> >> An other question: should I add the check for argument->is_Con() >> (string constant) and load argument's parameters statically >> (as we do in indexOf intrinsic on not SSE42 path)? >> >> Or should I add the ideal optimization? >> >> Currently ideal optimizations do not convert loadI(AddP(ConP, 28)) >> to static load. >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> I don't know that there's a clear place to draw the line. I'd tend >>> towards writing things in ideal if possible since that exposes it to >>> optimization and reduces the amount of assembly. I'd probably have a >>> stronger opinion about a more concrete example. >>> tom >>> On Aug 18, 2009, at 2:35 PM, Vladimir Kozlov wrote: >>>> I am modifying our string intrinsics to pass char[] pointers and >>>> counters instead of string oops to allow EA eliminate non-escaping >>>> string object (6827605). This will also allow to do some checks >>>> in ideal graph instead of in a mach node encoding. But it may affect >>>> ideal optimizations since it may complicate control flow. >>>> >>>> So I need your opinion where I should draw the line. >>>> >>>> For example, for String.equals() I compare counters in ideal but >>>> check it for 0 in mach (mach node needs only one counter) since >>>> == 0 is rare case. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> > From Changpeng.Fang at Sun.COM Wed Aug 19 10:55:59 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Wed, 19 Aug 2009 10:55:59 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A81AFAB.9000900@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> Message-ID: <4A8C3CAF.9070703@sun.com> http://cr.openjdk.java.net/~cfang/6873116/webrev.00/ Fixed 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit The implementation in this work is mostly from Christian's work on reexecute/mh bit changes. Problem: Current implementation of reexecute bit uses DebugInfoStreams to record the reexecute bit by compressing the reexecute bit into bci field. This makes the code look ugly (e.g.read_bci_and_reexecute(bool& reexecute). It also makes the future addition of debuginfo difficult. Solution: In this work, we use pcDesc to record the reexecute bit obtained from describe_scope, and then store the reexecute bit to scopeDesc when a scopeDesc object is created. Tests: JPRT, CompileTheWord, refworkload Thanks, Changpeng From Christian.Thalinger at Sun.COM Wed Aug 19 12:36:52 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 19 Aug 2009 21:36:52 +0200 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A8C3CAF.9070703@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> Message-ID: <4A8C5454.6050401@Sun.COM> changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6873116/webrev.00/ > > Fixed 6873116: Modify reexecute implementation to use pcDesc to record > the reexecute bit > > The implementation in this work is mostly from Christian's work on > reexecute/mh bit changes. > > Problem: > Current implementation of reexecute bit uses DebugInfoStreams to record > the reexecute bit by compressing the reexecute bit > into bci field. This makes the code look ugly > (e.g.read_bci_and_reexecute(bool& reexecute). It also makes the future > addition > of debuginfo difficult. > > Solution: > In this work, we use pcDesc to record the reexecute bit obtained from > describe_scope, and then store the reexecute bit to > scopeDesc when a scopeDesc object is created. > > Tests: > JPRT, CompileTheWord, refworkload Looks good. -- Christian From Vladimir.Kozlov at Sun.COM Wed Aug 19 12:36:58 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 19 Aug 2009 12:36:58 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A8C3CAF.9070703@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> Message-ID: <4A8C545A.9070100@sun.com> Looks good. Could you also fix the annoying problem in nodes dump: all nodes which have jvms info print reexecute bit value even if it is false: 9 Parm === 3 [[ 139 128 ]] ReturnAdr !jvms: Thread:: @ bci:-1 reexecute:false 8 Parm === 3 [[ 139 128 114 52 ]] FramePtr !jvms: Thread:: @ bci:-1 reexecute:false 117 Proj === 114 [[ 137 131 136 135 128 132 133 134 ]] #2 Memory: @BotPTR *+bot, idx=Bot; !jvms: Thread:: @ bci:45 reexecute:false 116 Proj === 114 [[ 128 120 130 125 ]] #1 !jvms: Thread:: @ bci:45 reexecute:false 121 CatchProj === 120 [[ 128 ]] #0 at bci -1 !jvms: Thread:: @ bci:45 reexecute:false Could you print just "reexecute" only when reexecute == true? Thanks, Vladimir changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6873116/webrev.00/ > > Fixed 6873116: Modify reexecute implementation to use pcDesc to record > the reexecute bit > > The implementation in this work is mostly from Christian's work on > reexecute/mh bit changes. > > Problem: > Current implementation of reexecute bit uses DebugInfoStreams to record > the reexecute bit by compressing the reexecute bit > into bci field. This makes the code look ugly > (e.g.read_bci_and_reexecute(bool& reexecute). It also makes the future > addition > of debuginfo difficult. > > Solution: > In this work, we use pcDesc to record the reexecute bit obtained from > describe_scope, and then store the reexecute bit to > scopeDesc when a scopeDesc object is created. > > Tests: > JPRT, CompileTheWord, refworkload > > Thanks, > > Changpeng > From Changpeng.Fang at Sun.COM Wed Aug 19 12:44:54 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Wed, 19 Aug 2009 12:44:54 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A8C545A.9070100@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A8C545A.9070100@sun.com> Message-ID: <4A8C5636.5020508@sun.com> On 08/19/09 12:36, Vladimir Kozlov wrote: > Looks good. > > Could you also fix the annoying problem in nodes dump: > all nodes which have jvms info print reexecute bit value > even if it is false: > > 9 Parm === 3 [[ 139 128 ]] ReturnAdr !jvms: Thread:: > @ bci:-1 reexecute:false > 8 Parm === 3 [[ 139 128 114 52 ]] FramePtr !jvms: > Thread:: @ bci:-1 reexecute:false > 117 Proj === 114 [[ 137 131 136 135 128 132 133 134 ]] > #2 Memory: @BotPTR *+bot, idx=Bot; !jvms: Thread:: @ bci:45 > reexecute:false > 116 Proj === 114 [[ 128 120 130 125 ]] #1 !jvms: > Thread:: @ bci:45 reexecute:false > 121 CatchProj === 120 [[ 128 ]] #0 at bci -1 !jvms: > Thread:: @ bci:45 reexecute:false > > Could you print just "reexecute" only when reexecute == true? > Thanks. I have also noticed this, and was waiting for somebody to complain :-) . I will make it the way you suggested. Thanks, Changpeng > Thanks, > Vladimir > > changpeng fang - Sun Microsystems - Santa Clara United States wrote: >> http://cr.openjdk.java.net/~cfang/6873116/webrev.00/ >> >> Fixed 6873116: Modify reexecute implementation to use pcDesc to >> record the reexecute bit >> >> The implementation in this work is mostly from Christian's work on >> reexecute/mh bit changes. >> >> Problem: >> Current implementation of reexecute bit uses DebugInfoStreams to >> record the reexecute bit by compressing the reexecute bit >> into bci field. This makes the code look ugly >> (e.g.read_bci_and_reexecute(bool& reexecute). It also makes the >> future addition >> of debuginfo difficult. >> >> Solution: >> In this work, we use pcDesc to record the reexecute bit obtained from >> describe_scope, and then store the reexecute bit to >> scopeDesc when a scopeDesc object is created. >> >> Tests: >> JPRT, CompileTheWord, refworkload >> >> Thanks, >> >> Changpeng >> From Thomas.Rodriguez at Sun.COM Wed Aug 19 13:26:32 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 19 Aug 2009 13:26:32 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A8C3CAF.9070703@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> Message-ID: This looks good. The SA fixes look right as well. The only suggestion I might make is to pass the PcDesc into the ScopeDesc constructor instead of passing in each of the arguments. It's ok the way it is but the arguments are just a mirror of PcDesc. By the way, does anyone know why the objects for EA are decoded eagerly instead of being decoded lazily like all the other debug info? That seems like unneeded overhead for most uses of ScopeDesc for stack walking. tom On Aug 19, 2009, at 10:55 AM, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6873116/webrev.00/ > > Fixed 6873116: Modify reexecute implementation to use pcDesc to > record the reexecute bit > > The implementation in this work is mostly from Christian's work on > reexecute/mh bit changes. > > Problem: > Current implementation of reexecute bit uses DebugInfoStreams to > record the reexecute bit by compressing the reexecute bit > into bci field. This makes the code look ugly > (e.g.read_bci_and_reexecute(bool& reexecute). It also makes the > future addition > of debuginfo difficult. > > Solution: > In this work, we use pcDesc to record the reexecute bit obtained > from describe_scope, and then store the reexecute bit to > scopeDesc when a scopeDesc object is created. > > Tests: > JPRT, CompileTheWord, refworkload > > Thanks, > > Changpeng > From Changpeng.Fang at Sun.COM Wed Aug 19 13:56:36 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Wed, 19 Aug 2009 13:56:36 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> Message-ID: <4A8C6704.6@sun.com> On 08/19/09 13:26, Tom Rodriguez wrote: > This looks good. The SA fixes look right as well. The only > suggestion I might make is to pass the PcDesc into the ScopeDesc > constructor instead of passing in each of the arguments. It's ok the > way it is but the arguments are just a mirror of PcDesc. > In way, the two constructors will be reduced to one. Can I use a default argument to specify "serialized_null" considering "avoid a .hpp-.hpp dependency" comment? // Constructor ScopeDesc(const nmethod* code, int decode_offset, int obj_decode_offset, bool reexecute); // Calls above, giving default value of "serialized_null" to the // "obj_decode_offset" argument. (We don't use a default argument to // avoid a .hpp-.hpp dependency.) ScopeDesc(const nmethod* code, int decode_offset, bool reexecute); Thanks, Changpeng > By the way, does anyone know why the objects for EA are decoded > eagerly instead of being decoded lazily like all the other debug > info? That seems like unneeded overhead for most uses of ScopeDesc > for stack walking. > > tom > > On Aug 19, 2009, at 10:55 AM, changpeng fang - Sun Microsystems - > Santa Clara United States wrote: > >> http://cr.openjdk.java.net/~cfang/6873116/webrev.00/ >> >> Fixed 6873116: Modify reexecute implementation to use pcDesc to >> record the reexecute bit >> >> The implementation in this work is mostly from Christian's work on >> reexecute/mh bit changes. >> >> Problem: >> Current implementation of reexecute bit uses DebugInfoStreams to >> record the reexecute bit by compressing the reexecute bit >> into bci field. This makes the code look ugly >> (e.g.read_bci_and_reexecute(bool& reexecute). It also makes the >> future addition >> of debuginfo difficult. >> >> Solution: >> In this work, we use pcDesc to record the reexecute bit obtained from >> describe_scope, and then store the reexecute bit to >> scopeDesc when a scopeDesc object is created. >> >> Tests: >> JPRT, CompileTheWord, refworkload >> >> Thanks, >> >> Changpeng >> > From Thomas.Rodriguez at Sun.COM Wed Aug 19 14:11:48 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 19 Aug 2009 14:11:48 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A8C6704.6@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A8C6704.6@sun.com> Message-ID: On Aug 19, 2009, at 1:56 PM, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > On 08/19/09 13:26, Tom Rodriguez wrote: >> This looks good. The SA fixes look right as well. The only >> suggestion I might make is to pass the PcDesc into the ScopeDesc >> constructor instead of passing in each of the arguments. It's ok >> the way it is but the arguments are just a mirror of PcDesc. >> > In way, the two constructors will be reduced to one. Can I use a > default argument to specify > "serialized_null" considering "avoid a .hpp-.hpp dependency" comment? The circularity is caused by SimpleScopeDesc which seems like variant of limited usefulness. I don't really understand the need for two ScopeDesc constructors here in the first place. The only difference between them is whether they decode the objects or not and that should probably be lazy, which would remove any difference in them. The second constructor is only used when decoding line numbers for JVMTI which seems like a strange place to worry about decoding the objects. Normal stack walking would probably prefer to skip this step too. Switching to lazy object decoding and having a single constructor taking a PcDesc seems better to me. I think we could get rid of SimpleScopeDesc too. It's only used in one place, nmethod::preserve_callee_argument_oops, which is only called in the rare instance where a GC is requested while a call site is being resolved. The performance difference between using a normal ScopeDesc and SimpleScopeDesc would be pretty minimal. tom > > // Constructor > ScopeDesc(const nmethod* code, int decode_offset, int > obj_decode_offset, bool reexecute); > > // Calls above, giving default value of "serialized_null" to the > // "obj_decode_offset" argument. (We don't use a default argument to > // avoid a .hpp-.hpp dependency.) > ScopeDesc(const nmethod* code, int decode_offset, bool reexecute); > > Thanks, > > Changpeng > > > >> By the way, does anyone know why the objects for EA are decoded >> eagerly instead of being decoded lazily like all the other debug >> info? That seems like unneeded overhead for most uses of ScopeDesc >> for stack walking. >> >> tom >> >> On Aug 19, 2009, at 10:55 AM, changpeng fang - Sun Microsystems - >> Santa Clara United States wrote: >> >>> http://cr.openjdk.java.net/~cfang/6873116/webrev.00/ >>> >>> Fixed 6873116: Modify reexecute implementation to use pcDesc to >>> record the reexecute bit >>> >>> The implementation in this work is mostly from Christian's work on >>> reexecute/mh bit changes. >>> >>> Problem: >>> Current implementation of reexecute bit uses DebugInfoStreams to >>> record the reexecute bit by compressing the reexecute bit >>> into bci field. This makes the code look ugly >>> (e.g.read_bci_and_reexecute(bool& reexecute). It also makes the >>> future addition >>> of debuginfo difficult. >>> >>> Solution: >>> In this work, we use pcDesc to record the reexecute bit obtained >>> from describe_scope, and then store the reexecute bit to >>> scopeDesc when a scopeDesc object is created. >>> >>> Tests: >>> JPRT, CompileTheWord, refworkload >>> >>> Thanks, >>> >>> Changpeng >>> >> > From Vladimir.Kozlov at Sun.COM Wed Aug 19 14:23:36 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 19 Aug 2009 14:23:36 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> Message-ID: <4A8C6D58.6090301@sun.com> Tom Rodriguez wrote: > By the way, does anyone know why the objects for EA are decoded eagerly > instead of being decoded lazily like all the other debug info? That > seems like unneeded overhead for most uses of ScopeDesc for stack walking. Do you mean the call to decode_object_values()? It is done only for top frame. But you are right that we may need to call it only when we need to decode narrow oop. I will look on it. Vladimir > > tom > From Vladimir.Kozlov at Sun.COM Wed Aug 19 14:31:53 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 19 Aug 2009 14:31:53 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A8C6D58.6090301@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A8C6D58.6090301@sun.com> Message-ID: <4A8C6F49.5050202@sun.com> Vladimir Kozlov wrote: > > Tom Rodriguez wrote: >> By the way, does anyone know why the objects for EA are decoded >> eagerly instead of being decoded lazily like all the other debug >> info? That seems like unneeded overhead for most uses of ScopeDesc >> for stack walking. > > Do you mean the call to decode_object_values()? > It is done only for top frame. > But you are right that we may need to call it only when we > need to decode narrow oop. I will look on it. ^ reallocate eliminated objects. My mind obsesses with compressed oops too much :) > > Vladimir > >> >> tom >> From Changpeng.Fang at Sun.COM Wed Aug 19 14:52:18 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Wed, 19 Aug 2009 14:52:18 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A8C6D58.6090301@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A8C6D58.6090301@sun.com> Message-ID: <4A8C7412.6020404@sun.com> Is this the approach to make it lazy? Thanks. -- Changpeng diff -r d0acbc302e14 src/share/vm/code/scopeDesc.cpp --- a/src/share/vm/code/scopeDesc.cpp Mon Aug 17 14:45:02 2009 -0700 +++ b/src/share/vm/code/scopeDesc.cpp Wed Aug 19 14:49:27 2009 -0700 @@ -90,16 +90,21 @@ GrowableArray* ScopeDesc::d GrowableArray* ScopeDesc::decode_object_values(int decode_offset) { if (decode_offset == DebugInformationRecorder::serialized_null) return NULL; - GrowableArray* result = new GrowableArray(); - DebugInfoReadStream* stream = new DebugInfoReadStream(_code, decode_offset, result); - int length = stream->read_int(); - for (int index = 0; index < length; index++) { - // Objects values are pushed to 'result' array during read so that - // object's fields could reference it (OBJECT_ID_CODE). - (void)ScopeValue::read_from(stream); +#ifdef COMPILER2 + if (DoEscapeAnalysis && EliminateAllocations) { + GrowableArray* result = new GrowableArray(); + DebugInfoReadStream* stream = new DebugInfoReadStream(_code, decode_offset, result); + int length = stream->read_int(); + for (int index = 0; index < length; index++) { + // Objects values are pushed to 'result' array during read so that + // object's fields could reference it (OBJECT_ID_CODE). + (void)ScopeValue::read_from(stream); + } + assert(result->length() == length, "inconsistent debug information"); + return result; } - assert(result->length() == length, "inconsistent debug information"); - return result; +#endif + return NULL; } > Tom Rodriguez wrote: >> By the way, does anyone know why the objects for EA are decoded >> eagerly instead of being decoded lazily like all the other debug >> info? That seems like unneeded overhead for most uses of ScopeDesc >> for stack walking. > > Do you mean the call to decode_object_values()? > It is done only for top frame. > But you are right that we may need to call it only when we > need to decode narrow oop. I will look on it. > > Vladimir > >> >> tom >> From Vladimir.Kozlov at Sun.COM Wed Aug 19 15:09:47 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 19 Aug 2009 15:09:47 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A8C7412.6020404@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A8C6D58.6090301@sun.com> <4A8C7412.6020404@sun.com> Message-ID: <4A8C782B.30605@sun.com> No. What Tom talks about is to do it only in Deoptimization::fetch_unroll_info_helper(). In other cases we will generate just empty ObjectValue(id). Vladimir changpeng fang - Sun Microsystems - Santa Clara United States wrote: > > Is this the approach to make it lazy? Thanks. -- Changpeng > > > diff -r d0acbc302e14 src/share/vm/code/scopeDesc.cpp > --- a/src/share/vm/code/scopeDesc.cpp Mon Aug 17 14:45:02 2009 -0700 > +++ b/src/share/vm/code/scopeDesc.cpp Wed Aug 19 14:49:27 2009 -0700 > @@ -90,16 +90,21 @@ GrowableArray* ScopeDesc::d > > GrowableArray* ScopeDesc::decode_object_values(int > decode_offset) { > if (decode_offset == DebugInformationRecorder::serialized_null) return > NULL; > - GrowableArray* result = new GrowableArray(); > - DebugInfoReadStream* stream = new DebugInfoReadStream(_code, > decode_offset, result); > - int length = stream->read_int(); > - for (int index = 0; index < length; index++) { > - // Objects values are pushed to 'result' array during read so that > - // object's fields could reference it (OBJECT_ID_CODE). > - (void)ScopeValue::read_from(stream); > +#ifdef COMPILER2 > + if (DoEscapeAnalysis && EliminateAllocations) { > + GrowableArray* result = new GrowableArray(); > + DebugInfoReadStream* stream = new DebugInfoReadStream(_code, > decode_offset, result); > + int length = stream->read_int(); > + for (int index = 0; index < length; index++) { > + // Objects values are pushed to 'result' array during read so that > + // object's fields could reference it (OBJECT_ID_CODE). > + (void)ScopeValue::read_from(stream); > + } > + assert(result->length() == length, "inconsistent debug information"); > + return result; > } > - assert(result->length() == length, "inconsistent debug information"); > - return result; > +#endif > + return NULL; > } > > > > > > > >> Tom Rodriguez wrote: >>> By the way, does anyone know why the objects for EA are decoded >>> eagerly instead of being decoded lazily like all the other debug >>> info? That seems like unneeded overhead for most uses of ScopeDesc >>> for stack walking. >> >> Do you mean the call to decode_object_values()? >> It is done only for top frame. >> But you are right that we may need to call it only when we >> need to decode narrow oop. I will look on it. >> >> Vladimir >> >>> >>> tom >>> > From Thomas.Rodriguez at Sun.COM Wed Aug 19 15:20:14 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 19 Aug 2009 15:20:14 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A8C782B.30605@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A8C6D58.6090301@sun.com> <4A8C7412.6020404@sun.com> <4A8C782B.30605@sun.com> Message-ID: <606DB492-1AD5-4489-9605-8414EFFD3268@Sun.COM> I figured it would look like the other lazy ones, i.e. record the offset in the constructor and do the decode in ScopeDesc::objects(). tom On Aug 19, 2009, at 3:09 PM, Vladimir Kozlov wrote: > No. What Tom talks about is to do it only in > Deoptimization::fetch_unroll_info_helper(). > In other cases we will generate just empty ObjectValue(id). > > Vladimir > > changpeng fang - Sun Microsystems - Santa Clara United States wrote: >> Is this the approach to make it lazy? Thanks. -- Changpeng >> diff -r d0acbc302e14 src/share/vm/code/scopeDesc.cpp >> --- a/src/share/vm/code/scopeDesc.cpp Mon Aug 17 14:45:02 2009 >> -0700 >> +++ b/src/share/vm/code/scopeDesc.cpp Wed Aug 19 14:49:27 2009 >> -0700 >> @@ -90,16 +90,21 @@ GrowableArray* ScopeDesc::d >> GrowableArray* ScopeDesc::decode_object_values(int >> decode_offset) { >> if (decode_offset == DebugInformationRecorder::serialized_null) >> return NULL; >> - GrowableArray* result = new >> GrowableArray(); >> - DebugInfoReadStream* stream = new DebugInfoReadStream(_code, >> decode_offset, result); >> - int length = stream->read_int(); >> - for (int index = 0; index < length; index++) { >> - // Objects values are pushed to 'result' array during read so >> that >> - // object's fields could reference it (OBJECT_ID_CODE). >> - (void)ScopeValue::read_from(stream); >> +#ifdef COMPILER2 >> + if (DoEscapeAnalysis && EliminateAllocations) { >> + GrowableArray* result = new >> GrowableArray(); >> + DebugInfoReadStream* stream = new DebugInfoReadStream(_code, >> decode_offset, result); >> + int length = stream->read_int(); >> + for (int index = 0; index < length; index++) { >> + // Objects values are pushed to 'result' array during read >> so that >> + // object's fields could reference it (OBJECT_ID_CODE). >> + (void)ScopeValue::read_from(stream); >> + } >> + assert(result->length() == length, "inconsistent debug >> information"); >> + return result; >> } >> - assert(result->length() == length, "inconsistent debug >> information"); >> - return result; >> +#endif >> + return NULL; >> } >>> Tom Rodriguez wrote: >>>> By the way, does anyone know why the objects for EA are decoded >>>> eagerly instead of being decoded lazily like all the other debug >>>> info? That seems like unneeded overhead for most uses of >>>> ScopeDesc for stack walking. >>> >>> Do you mean the call to decode_object_values()? >>> It is done only for top frame. >>> But you are right that we may need to call it only when we >>> need to decode narrow oop. I will look on it. >>> >>> Vladimir >>> >>>> >>>> tom >>>> From Vladimir.Kozlov at Sun.COM Wed Aug 19 15:17:17 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 19 Aug 2009 15:17:17 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A8C6704.6@sun.com> Message-ID: <4A8C79ED.40406@sun.com> Tom, I talked with Changpeng about this. I think lazy objects decoding will needs more work and testing. Can Changpeng push his changes as it is and I will file new RFI for lazy decoding and fix it? After that we will be able reduce ScopeDesc constructors. Thanks, Vladimir Tom Rodriguez wrote: > > On Aug 19, 2009, at 1:56 PM, changpeng fang - Sun Microsystems - Santa > Clara United States wrote: > >> On 08/19/09 13:26, Tom Rodriguez wrote: >>> This looks good. The SA fixes look right as well. The only >>> suggestion I might make is to pass the PcDesc into the ScopeDesc >>> constructor instead of passing in each of the arguments. It's ok the >>> way it is but the arguments are just a mirror of PcDesc. >>> >> In way, the two constructors will be reduced to one. Can I use a >> default argument to specify >> "serialized_null" considering "avoid a .hpp-.hpp dependency" comment? > > The circularity is caused by SimpleScopeDesc which seems like variant of > limited usefulness. I don't really understand the need for two > ScopeDesc constructors here in the first place. The only difference > between them is whether they decode the objects or not and that should > probably be lazy, which would remove any difference in them. The second > constructor is only used when decoding line numbers for JVMTI which > seems like a strange place to worry about decoding the objects. Normal > stack walking would probably prefer to skip this step too. Switching to > lazy object decoding and having a single constructor taking a PcDesc > seems better to me. I think we could get rid of SimpleScopeDesc too. > It's only used in one place, nmethod::preserve_callee_argument_oops, > which is only called in the rare instance where a GC is requested while > a call site is being resolved. The performance difference between using > a normal ScopeDesc and SimpleScopeDesc would be pretty minimal. > > tom > > > >> >> // Constructor >> ScopeDesc(const nmethod* code, int decode_offset, int >> obj_decode_offset, bool reexecute); >> >> // Calls above, giving default value of "serialized_null" to the >> // "obj_decode_offset" argument. (We don't use a default argument to >> // avoid a .hpp-.hpp dependency.) >> ScopeDesc(const nmethod* code, int decode_offset, bool reexecute); >> >> Thanks, >> >> Changpeng >> >> >> >>> By the way, does anyone know why the objects for EA are decoded >>> eagerly instead of being decoded lazily like all the other debug >>> info? That seems like unneeded overhead for most uses of ScopeDesc >>> for stack walking. >>> >>> tom >>> >>> On Aug 19, 2009, at 10:55 AM, changpeng fang - Sun Microsystems - >>> Santa Clara United States wrote: >>> >>>> http://cr.openjdk.java.net/~cfang/6873116/webrev.00/ >>>> >>>> Fixed 6873116: Modify reexecute implementation to use pcDesc to >>>> record the reexecute bit >>>> >>>> The implementation in this work is mostly from Christian's work on >>>> reexecute/mh bit changes. >>>> >>>> Problem: >>>> Current implementation of reexecute bit uses DebugInfoStreams to >>>> record the reexecute bit by compressing the reexecute bit >>>> into bci field. This makes the code look ugly >>>> (e.g.read_bci_and_reexecute(bool& reexecute). It also makes the >>>> future addition >>>> of debuginfo difficult. >>>> >>>> Solution: >>>> In this work, we use pcDesc to record the reexecute bit obtained >>>> from describe_scope, and then store the reexecute bit to >>>> scopeDesc when a scopeDesc object is created. >>>> >>>> Tests: >>>> JPRT, CompileTheWord, refworkload >>>> >>>> Thanks, >>>> >>>> Changpeng >>>> >>> >> > From Changpeng.Fang at Sun.COM Wed Aug 19 15:23:21 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Wed, 19 Aug 2009 15:23:21 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A8C782B.30605@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A8C6D58.6090301@sun.com> <4A8C7412.6020404@sun.com> <4A8C782B.30605@sun.com> Message-ID: <4A8C7B59.2020907@sun.com> On 08/19/09 15:09, Vladimir Kozlov wrote: > No. What Tom talks about is to do it only in > Deoptimization::fetch_unroll_info_helper(). > In other cases we will generate just empty ObjectValue(id). > Yes, I saw that only use: GrowableArray* objects = chunk->at(0)->scope()->objects(); Can we do it in this way: GrowableArray* objects = chunk->at(0)->scope()->decode_object_values(); i.e. we only decode the object when necessary, and don't do it in the constructor? Maybe we need to remember the offset. Thanks, Changpeng > Vladimir > > changpeng fang - Sun Microsystems - Santa Clara United States wrote: >> >> Is this the approach to make it lazy? Thanks. -- Changpeng >> >> >> diff -r d0acbc302e14 src/share/vm/code/scopeDesc.cpp >> --- a/src/share/vm/code/scopeDesc.cpp Mon Aug 17 14:45:02 2009 -0700 >> +++ b/src/share/vm/code/scopeDesc.cpp Wed Aug 19 14:49:27 2009 -0700 >> @@ -90,16 +90,21 @@ GrowableArray* ScopeDesc::d >> >> GrowableArray* ScopeDesc::decode_object_values(int >> decode_offset) { >> if (decode_offset == DebugInformationRecorder::serialized_null) >> return NULL; >> - GrowableArray* result = new >> GrowableArray(); >> - DebugInfoReadStream* stream = new DebugInfoReadStream(_code, >> decode_offset, result); >> - int length = stream->read_int(); >> - for (int index = 0; index < length; index++) { >> - // Objects values are pushed to 'result' array during read so that >> - // object's fields could reference it (OBJECT_ID_CODE). >> - (void)ScopeValue::read_from(stream); >> +#ifdef COMPILER2 >> + if (DoEscapeAnalysis && EliminateAllocations) { >> + GrowableArray* result = new >> GrowableArray(); >> + DebugInfoReadStream* stream = new DebugInfoReadStream(_code, >> decode_offset, result); >> + int length = stream->read_int(); >> + for (int index = 0; index < length; index++) { >> + // Objects values are pushed to 'result' array during read so >> that >> + // object's fields could reference it (OBJECT_ID_CODE). >> + (void)ScopeValue::read_from(stream); >> + } >> + assert(result->length() == length, "inconsistent debug >> information"); >> + return result; >> } >> - assert(result->length() == length, "inconsistent debug information"); >> - return result; >> +#endif >> + return NULL; >> } >> >> >> >> >> >> >> >>> Tom Rodriguez wrote: >>>> By the way, does anyone know why the objects for EA are decoded >>>> eagerly instead of being decoded lazily like all the other debug >>>> info? That seems like unneeded overhead for most uses of ScopeDesc >>>> for stack walking. >>> >>> Do you mean the call to decode_object_values()? >>> It is done only for top frame. >>> But you are right that we may need to call it only when we >>> need to decode narrow oop. I will look on it. >>> >>> Vladimir >>> >>>> >>>> tom >>>> >> From Vladimir.Kozlov at Sun.COM Wed Aug 19 15:22:59 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 19 Aug 2009 15:22:59 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A8C7B59.2020907@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A8C6D58.6090301@sun.com> <4A8C7412.6020404@sun.com> <4A8C782B.30605@sun.com> <4A8C7B59.2020907@sun.com> Message-ID: <4A8C7B43.9060807@sun.com> Currently I am not sure that it is the only place where we need object values. This is why I don't want to rush with this change. Vladimir changpeng fang - Sun Microsystems - Santa Clara United States wrote: > On 08/19/09 15:09, Vladimir Kozlov wrote: >> No. What Tom talks about is to do it only in >> Deoptimization::fetch_unroll_info_helper(). >> In other cases we will generate just empty ObjectValue(id). >> > Yes, I saw that only use: > GrowableArray* objects = chunk->at(0)->scope()->objects(); > > Can we do it in this way: > GrowableArray* objects = > chunk->at(0)->scope()->decode_object_values(); > i.e. we only decode the object when necessary, and don't do it in the > constructor? > Maybe we need to remember the offset. > > Thanks, > > Changpeng > > >> Vladimir >> >> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>> >>> Is this the approach to make it lazy? Thanks. -- Changpeng >>> >>> >>> diff -r d0acbc302e14 src/share/vm/code/scopeDesc.cpp >>> --- a/src/share/vm/code/scopeDesc.cpp Mon Aug 17 14:45:02 2009 -0700 >>> +++ b/src/share/vm/code/scopeDesc.cpp Wed Aug 19 14:49:27 2009 -0700 >>> @@ -90,16 +90,21 @@ GrowableArray* ScopeDesc::d >>> >>> GrowableArray* ScopeDesc::decode_object_values(int >>> decode_offset) { >>> if (decode_offset == DebugInformationRecorder::serialized_null) >>> return NULL; >>> - GrowableArray* result = new >>> GrowableArray(); >>> - DebugInfoReadStream* stream = new DebugInfoReadStream(_code, >>> decode_offset, result); >>> - int length = stream->read_int(); >>> - for (int index = 0; index < length; index++) { >>> - // Objects values are pushed to 'result' array during read so that >>> - // object's fields could reference it (OBJECT_ID_CODE). >>> - (void)ScopeValue::read_from(stream); >>> +#ifdef COMPILER2 >>> + if (DoEscapeAnalysis && EliminateAllocations) { >>> + GrowableArray* result = new >>> GrowableArray(); >>> + DebugInfoReadStream* stream = new DebugInfoReadStream(_code, >>> decode_offset, result); >>> + int length = stream->read_int(); >>> + for (int index = 0; index < length; index++) { >>> + // Objects values are pushed to 'result' array during read so >>> that >>> + // object's fields could reference it (OBJECT_ID_CODE). >>> + (void)ScopeValue::read_from(stream); >>> + } >>> + assert(result->length() == length, "inconsistent debug >>> information"); >>> + return result; >>> } >>> - assert(result->length() == length, "inconsistent debug information"); >>> - return result; >>> +#endif >>> + return NULL; >>> } >>> >>> >>> >>> >>> >>> >>> >>>> Tom Rodriguez wrote: >>>>> By the way, does anyone know why the objects for EA are decoded >>>>> eagerly instead of being decoded lazily like all the other debug >>>>> info? That seems like unneeded overhead for most uses of ScopeDesc >>>>> for stack walking. >>>> >>>> Do you mean the call to decode_object_values()? >>>> It is done only for top frame. >>>> But you are right that we may need to call it only when we >>>> need to decode narrow oop. I will look on it. >>>> >>>> Vladimir >>>> >>>>> >>>>> tom >>>>> >>> > From Thomas.Rodriguez at Sun.COM Wed Aug 19 15:57:38 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 19 Aug 2009 15:57:38 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: <4A8C7B43.9060807@sun.com> References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A8C6D58.6090301@sun.com> <4A8C7412.6020404@sun.com> <4A8C782B.30605@sun.com> <4A8C7B59.2020907@sun.com> <4A8C7B43.9060807@sun.com> Message-ID: The only use of the objects() method is in deopt so it seems pretty straightforwards but it doesn't have to happen now. However you want to handle it is fine. tom On Aug 19, 2009, at 3:22 PM, Vladimir Kozlov wrote: > Currently I am not sure that it is the only place where we need > object values. > This is why I don't want to rush with this change. > > Vladimir > > changpeng fang - Sun Microsystems - Santa Clara United States wrote: >> On 08/19/09 15:09, Vladimir Kozlov wrote: >>> No. What Tom talks about is to do it only in >>> Deoptimization::fetch_unroll_info_helper(). >>> In other cases we will generate just empty ObjectValue(id). >>> >> Yes, I saw that only use: >> GrowableArray* objects = chunk->at(0)->scope()- >> >objects(); >> Can we do it in this way: >> GrowableArray* objects = chunk->at(0)->scope()- >> >decode_object_values(); >> i.e. we only decode the object when necessary, and don't do it in >> the constructor? >> Maybe we need to remember the offset. >> Thanks, >> Changpeng >>> Vladimir >>> >>> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>>> >>>> Is this the approach to make it lazy? Thanks. -- Changpeng >>>> >>>> >>>> diff -r d0acbc302e14 src/share/vm/code/scopeDesc.cpp >>>> --- a/src/share/vm/code/scopeDesc.cpp Mon Aug 17 14:45:02 2009 >>>> -0700 >>>> +++ b/src/share/vm/code/scopeDesc.cpp Wed Aug 19 14:49:27 2009 >>>> -0700 >>>> @@ -90,16 +90,21 @@ GrowableArray* ScopeDesc::d >>>> >>>> GrowableArray* ScopeDesc::decode_object_values(int >>>> decode_offset) { >>>> if (decode_offset == DebugInformationRecorder::serialized_null) >>>> return NULL; >>>> - GrowableArray* result = new >>>> GrowableArray(); >>>> - DebugInfoReadStream* stream = new DebugInfoReadStream(_code, >>>> decode_offset, result); >>>> - int length = stream->read_int(); >>>> - for (int index = 0; index < length; index++) { >>>> - // Objects values are pushed to 'result' array during read >>>> so that >>>> - // object's fields could reference it (OBJECT_ID_CODE). >>>> - (void)ScopeValue::read_from(stream); >>>> +#ifdef COMPILER2 >>>> + if (DoEscapeAnalysis && EliminateAllocations) { >>>> + GrowableArray* result = new >>>> GrowableArray(); >>>> + DebugInfoReadStream* stream = new DebugInfoReadStream(_code, >>>> decode_offset, result); >>>> + int length = stream->read_int(); >>>> + for (int index = 0; index < length; index++) { >>>> + // Objects values are pushed to 'result' array during read >>>> so that >>>> + // object's fields could reference it (OBJECT_ID_CODE). >>>> + (void)ScopeValue::read_from(stream); >>>> + } >>>> + assert(result->length() == length, "inconsistent debug >>>> information"); >>>> + return result; >>>> } >>>> - assert(result->length() == length, "inconsistent debug >>>> information"); >>>> - return result; >>>> +#endif >>>> + return NULL; >>>> } >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Tom Rodriguez wrote: >>>>>> By the way, does anyone know why the objects for EA are decoded >>>>>> eagerly instead of being decoded lazily like all the other >>>>>> debug info? That seems like unneeded overhead for most uses of >>>>>> ScopeDesc for stack walking. >>>>> >>>>> Do you mean the call to decode_object_values()? >>>>> It is done only for top frame. >>>>> But you are right that we may need to call it only when we >>>>> need to decode narrow oop. I will look on it. >>>>> >>>>> Vladimir >>>>> >>>>>> >>>>>> tom >>>>>> >>>> From Changpeng.Fang at Sun.COM Wed Aug 19 15:59:56 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Wed, 19 Aug 2009 15:59:56 -0700 Subject: Request for reviews (M): 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit In-Reply-To: References: <4A819AEA.6060603@sun.com> <4A81AFAB.9000900@sun.com> <4A8C3CAF.9070703@sun.com> <4A8C6D58.6090301@sun.com> <4A8C7412.6020404@sun.com> <4A8C782B.30605@sun.com> <4A8C7B59.2020907@sun.com> <4A8C7B43.9060807@sun.com> Message-ID: <4A8C83EC.4030809@sun.com> I am doing this now, and will send out the webrev soon. Thanks, Changpeng On 08/19/09 15:57, Tom Rodriguez wrote: > The only use of the objects() method is in deopt so it seems pretty > straightforwards but it doesn't have to happen now. However you want > to handle it is fine. > > tom > > On Aug 19, 2009, at 3:22 PM, Vladimir Kozlov wrote: > >> Currently I am not sure that it is the only place where we need >> object values. >> This is why I don't want to rush with this change. >> >> Vladimir >> >> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>> On 08/19/09 15:09, Vladimir Kozlov wrote: >>>> No. What Tom talks about is to do it only in >>>> Deoptimization::fetch_unroll_info_helper(). >>>> In other cases we will generate just empty ObjectValue(id). >>>> >>> Yes, I saw that only use: >>> GrowableArray* objects = chunk->at(0)->scope()->objects(); >>> Can we do it in this way: >>> GrowableArray* objects = >>> chunk->at(0)->scope()->decode_object_values(); >>> i.e. we only decode the object when necessary, and don't do it in >>> the constructor? >>> Maybe we need to remember the offset. >>> Thanks, >>> Changpeng >>>> Vladimir >>>> >>>> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>>>> >>>>> Is this the approach to make it lazy? Thanks. -- Changpeng >>>>> >>>>> >>>>> diff -r d0acbc302e14 src/share/vm/code/scopeDesc.cpp >>>>> --- a/src/share/vm/code/scopeDesc.cpp Mon Aug 17 14:45:02 2009 >>>>> -0700 >>>>> +++ b/src/share/vm/code/scopeDesc.cpp Wed Aug 19 14:49:27 2009 >>>>> -0700 >>>>> @@ -90,16 +90,21 @@ GrowableArray* ScopeDesc::d >>>>> >>>>> GrowableArray* ScopeDesc::decode_object_values(int >>>>> decode_offset) { >>>>> if (decode_offset == DebugInformationRecorder::serialized_null) >>>>> return NULL; >>>>> - GrowableArray* result = new >>>>> GrowableArray(); >>>>> - DebugInfoReadStream* stream = new DebugInfoReadStream(_code, >>>>> decode_offset, result); >>>>> - int length = stream->read_int(); >>>>> - for (int index = 0; index < length; index++) { >>>>> - // Objects values are pushed to 'result' array during read so >>>>> that >>>>> - // object's fields could reference it (OBJECT_ID_CODE). >>>>> - (void)ScopeValue::read_from(stream); >>>>> +#ifdef COMPILER2 >>>>> + if (DoEscapeAnalysis && EliminateAllocations) { >>>>> + GrowableArray* result = new >>>>> GrowableArray(); >>>>> + DebugInfoReadStream* stream = new DebugInfoReadStream(_code, >>>>> decode_offset, result); >>>>> + int length = stream->read_int(); >>>>> + for (int index = 0; index < length; index++) { >>>>> + // Objects values are pushed to 'result' array during read >>>>> so that >>>>> + // object's fields could reference it (OBJECT_ID_CODE). >>>>> + (void)ScopeValue::read_from(stream); >>>>> + } >>>>> + assert(result->length() == length, "inconsistent debug >>>>> information"); >>>>> + return result; >>>>> } >>>>> - assert(result->length() == length, "inconsistent debug >>>>> information"); >>>>> - return result; >>>>> +#endif >>>>> + return NULL; >>>>> } >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> By the way, does anyone know why the objects for EA are decoded >>>>>>> eagerly instead of being decoded lazily like all the other debug >>>>>>> info? That seems like unneeded overhead for most uses of >>>>>>> ScopeDesc for stack walking. >>>>>> >>>>>> Do you mean the call to decode_object_values()? >>>>>> It is done only for top frame. >>>>>> But you are right that we may need to call it only when we >>>>>> need to decode narrow oop. I will look on it. >>>>>> >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> tom >>>>>>> >>>>> > From Thomas.Rodriguez at Sun.COM Wed Aug 19 16:17:30 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 19 Aug 2009 16:17:30 -0700 Subject: review (XS) for 6873777: FPU control word optimization still performed with SSE Message-ID: <7E7B57D3-A306-48AD-87E8-F95296A9788C@sun.com> http://cr.openjdk.java.net/~never/6873777 From Thomas.Rodriguez at Sun.COM Wed Aug 19 17:07:39 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 19 Aug 2009 17:07:39 -0700 Subject: string methods intrinsics, place for checks In-Reply-To: <4A8B603A.9020703@sun.com> References: <4A8B1E90.9070000@sun.com> <536B6ABA-DE66-4AB4-A2E9-A01FD333A09A@sun.com> <4A8B3501.8030605@sun.com> <4A8B603A.9020703@sun.com> Message-ID: I think the boundaries you do look fine and the code looks good. I think the argument order for StrComp and StrIndexOf should be based on the pairs, s1 c2 s2 c2, instead of pointers then counts. Otherwise it looks good. Any chance the x86 assembly could be moved out of the ad file into the shared part of assembler_x86? The code is almost exactly the same at least for StringEquals and StrComp and the differences could be papered over easily. Having one copy seems better. tom On Aug 18, 2009, at 7:15 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> If you mean constant folding the loads of the final fields of a >> Constant string, I've got some changes for that coming. > > Yes, I meant that. > > And here is the first draft for string intrinsics changes: > > http://cr.openjdk.java.net/~kvn/6827605/webrev.00 > > Vladimir > >> tom >> On Aug 18, 2009, at 4:10 PM, Vladimir Kozlov wrote: >>> I will send first draft tomorrow so you will see. >>> >>> An other question: should I add the check for argument->is_Con() >>> (string constant) and load argument's parameters statically >>> (as we do in indexOf intrinsic on not SSE42 path)? >>> >>> Or should I add the ideal optimization? >>> >>> Currently ideal optimizations do not convert loadI(AddP(ConP, 28)) >>> to static load. >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> I don't know that there's a clear place to draw the line. I'd >>>> tend towards writing things in ideal if possible since that >>>> exposes it to optimization and reduces the amount of assembly. >>>> I'd probably have a stronger opinion about a more concrete example. >>>> tom >>>> On Aug 18, 2009, at 2:35 PM, Vladimir Kozlov wrote: >>>>> I am modifying our string intrinsics to pass char[] pointers and >>>>> counters instead of string oops to allow EA eliminate non-escaping >>>>> string object (6827605). This will also allow to do some checks >>>>> in ideal graph instead of in a mach node encoding. But it may >>>>> affect >>>>> ideal optimizations since it may complicate control flow. >>>>> >>>>> So I need your opinion where I should draw the line. >>>>> >>>>> For example, for String.equals() I compare counters in ideal but >>>>> check it for 0 in mach (mach node needs only one counter) since >>>>> == 0 is rare case. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> From Vladimir.Kozlov at Sun.COM Wed Aug 19 17:21:58 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 19 Aug 2009 17:21:58 -0700 Subject: string methods intrinsics, place for checks In-Reply-To: References: <4A8B1E90.9070000@sun.com> <536B6ABA-DE66-4AB4-A2E9-A01FD333A09A@sun.com> <4A8B3501.8030605@sun.com> <4A8B603A.9020703@sun.com> Message-ID: <4A8C9726.7050009@sun.com> Thanks Tom Yes, I thought about combining assembler. I will do it. Vladimir Tom Rodriguez wrote: > I think the boundaries you do look fine and the code looks good. I > think the argument order for StrComp and StrIndexOf should be based on > the pairs, s1 c2 s2 c2, instead of pointers then counts. Otherwise it > looks good. > > Any chance the x86 assembly could be moved out of the ad file into the > shared part of assembler_x86? The code is almost exactly the same at > least for StringEquals and StrComp and the differences could be papered > over easily. Having one copy seems better. > > tom > > On Aug 18, 2009, at 7:15 PM, Vladimir Kozlov wrote: > >> Tom Rodriguez wrote: >>> If you mean constant folding the loads of the final fields of a >>> Constant string, I've got some changes for that coming. >> >> Yes, I meant that. >> >> And here is the first draft for string intrinsics changes: >> >> http://cr.openjdk.java.net/~kvn/6827605/webrev.00 >> >> Vladimir >> >>> tom >>> On Aug 18, 2009, at 4:10 PM, Vladimir Kozlov wrote: >>>> I will send first draft tomorrow so you will see. >>>> >>>> An other question: should I add the check for argument->is_Con() >>>> (string constant) and load argument's parameters statically >>>> (as we do in indexOf intrinsic on not SSE42 path)? >>>> >>>> Or should I add the ideal optimization? >>>> >>>> Currently ideal optimizations do not convert loadI(AddP(ConP, 28)) >>>> to static load. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> I don't know that there's a clear place to draw the line. I'd tend >>>>> towards writing things in ideal if possible since that exposes it >>>>> to optimization and reduces the amount of assembly. I'd probably >>>>> have a stronger opinion about a more concrete example. >>>>> tom >>>>> On Aug 18, 2009, at 2:35 PM, Vladimir Kozlov wrote: >>>>>> I am modifying our string intrinsics to pass char[] pointers and >>>>>> counters instead of string oops to allow EA eliminate non-escaping >>>>>> string object (6827605). This will also allow to do some checks >>>>>> in ideal graph instead of in a mach node encoding. But it may affect >>>>>> ideal optimizations since it may complicate control flow. >>>>>> >>>>>> So I need your opinion where I should draw the line. >>>>>> >>>>>> For example, for String.equals() I compare counters in ideal but >>>>>> check it for 0 in mach (mach node needs only one counter) since >>>>>> == 0 is rare case. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> > From Vladimir.Kozlov at Sun.COM Wed Aug 19 17:31:39 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 19 Aug 2009 17:31:39 -0700 Subject: Request for reviews (XS): 6873799 and 6873800 Message-ID: <4A8C996B.7060203@sun.com> I think EA and COOP are stable enough to enable them by default in HS17. I will do separate pushes to have separate build bundles. http://cr.openjdk.java.net/~kvn/6873799/webrev.00 http://cr.openjdk.java.net/~kvn/6873800/webrev.00 Fixed 6873799: enable escape analysis by default Fixed 6873800: enable compressed oops by default Reviewed by: Fix verified (y/n): y, JPRT JDK bootstrap build with both flags enabled Other testing: JPRT, CTW, Nightly testing with EA and COOP From Vladimir.Kozlov at Sun.COM Wed Aug 19 18:52:23 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 19 Aug 2009 18:52:23 -0700 Subject: review (XS) for 6873777: FPU control word optimization still performed with SSE In-Reply-To: <7E7B57D3-A306-48AD-87E8-F95296A9788C@sun.com> References: <7E7B57D3-A306-48AD-87E8-F95296A9788C@sun.com> Message-ID: <4A8CAC57.9050901@sun.com> Thanks Tom, I also saw this but put it on the bottom of my queue. Changes looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6873777 From Thomas.Rodriguez at Sun.COM Wed Aug 19 18:52:59 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 19 Aug 2009 18:52:59 -0700 Subject: Request for reviews (XS): 6873799 and 6873800 In-Reply-To: <4A8C996B.7060203@sun.com> References: <4A8C996B.7060203@sun.com> Message-ID: Ok. tom On Aug 19, 2009, at 5:31 PM, Vladimir Kozlov wrote: > I think EA and COOP are stable enough to enable them > by default in HS17. I will do separate pushes to have > separate build bundles. > > http://cr.openjdk.java.net/~kvn/6873799/webrev.00 > http://cr.openjdk.java.net/~kvn/6873800/webrev.00 > > Fixed 6873799: enable escape analysis by default > Fixed 6873800: enable compressed oops by default > > Reviewed by: > > Fix verified (y/n): y, JPRT JDK bootstrap build with both flags > enabled > > Other testing: > JPRT, CTW, Nightly testing with EA and COOP > > From thomas.rodriguez at sun.com Wed Aug 19 21:19:38 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 20 Aug 2009 04:19:38 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6873777: FPU control word optimization still performed with SSE Message-ID: <20090820041945.D7AB31213E@hg.openjdk.java.net> Changeset: cd18bd5e667c Author: never Date: 2009-08-19 18:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cd18bd5e667c 6873777: FPU control word optimization still performed with SSE Reviewed-by: kvn ! src/share/vm/opto/compile.cpp From vladimir.kozlov at sun.com Wed Aug 19 23:27:49 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 20 Aug 2009 06:27:49 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6873799: enable escape analysis by default Message-ID: <20090820062757.918BD12147@hg.openjdk.java.net> Changeset: 357d4e2eb4dd Author: kvn Date: 2009-08-19 19:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/357d4e2eb4dd 6873799: enable escape analysis by default Summary: enable escape analysis by default Reviewed-by: never ! src/share/vm/opto/c2_globals.hpp From aph at redhat.com Thu Aug 20 00:46:03 2009 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Aug 2009 08:46:03 +0100 Subject: Request for reviews (XS): 6873799 and 6873800 In-Reply-To: <4A8C996B.7060203@sun.com> References: <4A8C996B.7060203@sun.com> Message-ID: <4A8CFF3B.90903@redhat.com> Vladimir Kozlov wrote: > I think EA and COOP are stable enough to enable them > by default in HS17. I will do separate pushes to have > separate build bundles. > > http://cr.openjdk.java.net/~kvn/6873799/webrev.00 > http://cr.openjdk.java.net/~kvn/6873800/webrev.00 > > Fixed 6873799: enable escape analysis by default > Fixed 6873800: enable compressed oops by default That's interesting. So, even with the (small) extra effort needed to unpack a compressed oop, the memory saving means it's always a win? Andrew. From Christian.Thalinger at Sun.COM Thu Aug 20 01:18:36 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 20 Aug 2009 10:18:36 +0200 Subject: Request for reviews (XS): 6873799 and 6873800 In-Reply-To: <4A8CFF3B.90903@redhat.com> References: <4A8C996B.7060203@sun.com> <4A8CFF3B.90903@redhat.com> Message-ID: <4A8D06DC.5030407@Sun.COM> Andrew Haley wrote: > Vladimir Kozlov wrote: >> I think EA and COOP are stable enough to enable them >> by default in HS17. I will do separate pushes to have >> separate build bundles. >> >> http://cr.openjdk.java.net/~kvn/6873799/webrev.00 >> http://cr.openjdk.java.net/~kvn/6873800/webrev.00 >> >> Fixed 6873799: enable escape analysis by default >> Fixed 6873800: enable compressed oops by default > > That's interesting. So, even with the (small) extra effort needed to > unpack a compressed oop, the memory saving means it's always a win? Well, "always" is probably not true. But nowadays most applications rely heavily on memory throughput and it's definitely a win there. But sure Vladimir has some numbers when he wakes up. -- Christian From mlists at juma.me.uk Thu Aug 20 02:49:52 2009 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 20 Aug 2009 09:49:52 +0000 (UTC) Subject: Request for reviews (XS): 6873799 and 6873800 References: <4A8C996B.7060203@sun.com> <4A8CFF3B.90903@redhat.com> <4A8D06DC.5030407@Sun.COM> Message-ID: Hi, Christian Thalinger writes: > Well, "always" is probably not true. But nowadays most applications > rely heavily on memory throughput and it's definitely a win there. That has also been my experience when benchmarking an internal application. David Dagastine also wrote: "64-bit Compressed Oops Performance Optimization: 64-bit now surpasses 32-bit performance."[1] That's a bit vague, but it was common to see a small performance disadvantage for the 64-bit JVM versus the 32bit JVM when running some of the well known benchmarks, so compressed oops seems to be a win there too. > But sure Vladimir has some numbers when he wakes up. That would be interesting information. For what is worth, I think it's great that compressed oops and escape analysis will be enabled by default in HotSpot 17. Aside from performance improvement, the former has a significant effect in terms of memory usage (and we know that JVM needs all the help it can get there). The latter, on the other hand, helps with the excessive allocation (including boxing) that takes place in certain cases in Scala (my favoured programming language these days). Best, Ismael [1] http://blogs.sun.com/dagastine/entry/java_rocks_intel_nehalem1 From mlists at juma.me.uk Thu Aug 20 11:20:30 2009 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 20 Aug 2009 11:20:30 -0700 (PDT) Subject: Request for reviews (XS): 6873799 and 6873800 In-Reply-To: <4A8C996B.7060203@sun.com> References: <4A8C996B.7060203@sun.com> Message-ID: <25067204.post@talk.nabble.com> Hi Vladimir, Vladimir Kozlov-5 wrote: > > I think EA and COOP are stable enough to enable them > by default in HS17 Do you know if HS17 will eventually be included in a JDK6 release? Thanks, Ismael -- View this message in context: http://www.nabble.com/Request-for-reviews-%28XS%29%3A-6873799-and-6873800-tp25054248p25067204.html Sent from the OpenJDK Hotspot Compiler Development List mailing list archive at Nabble.com. From Vladimir.Kozlov at Sun.COM Thu Aug 20 11:31:40 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 20 Aug 2009 11:31:40 -0700 Subject: Request for reviews (XS): 6873799 and 6873800 In-Reply-To: <25067204.post@talk.nabble.com> References: <4A8C996B.7060203@sun.com> <25067204.post@talk.nabble.com> Message-ID: <4A8D968C.9050301@sun.com> Yes, eventually it will be in JDK6 update release. But currently I don't know which. Vladimir Ismael Juma wrote: > Hi Vladimir, > > > Vladimir Kozlov-5 wrote: >> I think EA and COOP are stable enough to enable them >> by default in HS17 > > Do you know if HS17 will eventually be included in a JDK6 release? > > Thanks, > Ismael From Vladimir.Kozlov at Sun.COM Thu Aug 20 11:49:08 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 20 Aug 2009 11:49:08 -0700 Subject: Request for reviews (XS): 6873799 and 6873800 In-Reply-To: <4A8D06DC.5030407@Sun.COM> References: <4A8C996B.7060203@sun.com> <4A8CFF3B.90903@redhat.com> <4A8D06DC.5030407@Sun.COM> Message-ID: <4A8D9AA4.2030302@sun.com> The main performance improvement of compressed oops came after next changes: 6791178: Specialize for zero as the compressed oop vm heap base If java heap (including perm gen) size is < 2Gb and OS allows to reserve the heap below 4Gb boundary no encoding/decoding needed since object pointers fit into 32-bit. So it is clear win. (low 2Gb of virtual address space is used for java launcher and malloc, also Win loads kernel libs there). If java heap < 30Gb only shift instruction is used for encoding/decoding. Look on the wiki page http://wikis.sun.com/display/HotSpotInternals for details on CompressedOops and other technologies Hotspot VM uses. Thanks, Vladimir Christian Thalinger wrote: > Andrew Haley wrote: >> Vladimir Kozlov wrote: >>> I think EA and COOP are stable enough to enable them >>> by default in HS17. I will do separate pushes to have >>> separate build bundles. >>> >>> http://cr.openjdk.java.net/~kvn/6873799/webrev.00 >>> http://cr.openjdk.java.net/~kvn/6873800/webrev.00 >>> >>> Fixed 6873799: enable escape analysis by default >>> Fixed 6873800: enable compressed oops by default >> That's interesting. So, even with the (small) extra effort needed to >> unpack a compressed oop, the memory saving means it's always a win? > > Well, "always" is probably not true. But nowadays most applications > rely heavily on memory throughput and it's definitely a win there. But > sure Vladimir has some numbers when he wakes up. > > -- Christian From changpeng.fang at sun.com Thu Aug 20 14:52:56 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Thu, 20 Aug 2009 21:52:56 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit Message-ID: <20090820215305.1EB50121AC@hg.openjdk.java.net> Changeset: 72088be4b386 Author: cfang Date: 2009-08-20 12:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/72088be4b386 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit Summary: use PcDesc to keep record of the reexecute bit instead of using DebugInfoStreams Reviewed-by: kvn, never, twisti ! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vmStructs.cpp From john.coomes at sun.com Thu Aug 20 22:02:02 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 21 Aug 2009 05:02:02 +0000 Subject: hg: jdk7/hotspot-comp: 4 new changesets Message-ID: <20090821050202.AA30B1221D@hg.openjdk.java.net> Changeset: 4cad5a3f5038 Author: asaha Date: 2009-08-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/4cad5a3f5038 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README Changeset: fb676d15f20f Author: asaha Date: 2009-08-10 10:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/fb676d15f20f Merge Changeset: 175cb3fe6159 Author: tbell Date: 2009-08-14 08:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/175cb3fe6159 Merge Changeset: de7a3e98c159 Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/de7a3e98c159 Added tag jdk7-b70 for changeset 175cb3fe6159 ! .hgtags From john.coomes at sun.com Thu Aug 20 22:08:04 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 21 Aug 2009 05:08:04 +0000 Subject: hg: jdk7/hotspot-comp/corba: 4 new changesets Message-ID: <20090821050808.5736712222@hg.openjdk.java.net> Changeset: f3f572ea0cf2 Author: asaha Date: 2009-08-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/f3f572ea0cf2 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README Changeset: 691649734a70 Author: asaha Date: 2009-08-10 10:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/691649734a70 Merge Changeset: 175bd6877954 Author: tbell Date: 2009-08-14 08:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/175bd6877954 Merge Changeset: 9f1959c73473 Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/9f1959c73473 Added tag jdk7-b70 for changeset 175bd6877954 ! .hgtags From john.coomes at sun.com Thu Aug 20 22:18:15 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 21 Aug 2009 05:18:15 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 11 new changesets Message-ID: <20090821051832.5C9AC12227@hg.openjdk.java.net> Changeset: 1687f5192ce7 Author: asaha Date: 2009-06-22 13:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/1687f5192ce7 6845701: Xerces2 Java XML library infinite loop with malformed XML input Reviewed-by: hawtin ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java Changeset: 1b3c6eec7d31 Author: asaha Date: 2009-06-30 16:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/1b3c6eec7d31 Merge Changeset: e8d3c15bb7f6 Author: asaha Date: 2009-07-06 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/e8d3c15bb7f6 Merge Changeset: 1c82b475604f Author: asaha Date: 2009-07-21 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/1c82b475604f Merge Changeset: fb3829850f08 Author: asaha Date: 2009-07-27 22:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/fb3829850f08 Merge Changeset: 66f9efcdd76c Author: asaha Date: 2009-08-03 12:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/66f9efcdd76c Merge Changeset: 16184436ba33 Author: asaha Date: 2009-08-06 22:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/16184436ba33 Merge Changeset: c7914d53581c Author: asaha Date: 2009-08-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/c7914d53581c 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README Changeset: deec13478962 Author: asaha Date: 2009-08-10 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/deec13478962 Merge Changeset: c83f0106b78a Author: tbell Date: 2009-08-14 08:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/c83f0106b78a Merge Changeset: ff94d8ce0dad Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/ff94d8ce0dad Added tag jdk7-b70 for changeset c83f0106b78a ! .hgtags From john.coomes at sun.com Thu Aug 20 22:34:51 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 21 Aug 2009 05:34:51 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 98 new changesets Message-ID: <20090821055700.C71EA12231@hg.openjdk.java.net> Changeset: 12e479399ced Author: dl Date: 2009-07-28 13:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/12e479399ced 6785442: ConcurrentLinkedQueue.remove() and poll() can both remove the same element 6493942: ConcurrentLinkedQueue.remove sometimes very slow Summary: new algorithm for handling concurrent linked lists Reviewed-by: martin ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java + test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java + test/java/util/concurrent/ConcurrentQueues/GCRetention.java + test/java/util/concurrent/ConcurrentQueues/LoopHelpers.java + test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java ! test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 49573ab3096a Author: dl Date: 2009-07-28 17:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/49573ab3096a 6805775: LinkedBlockingQueue Nodes should unlink themselves before becoming garbage 6815766: LinkedBlockingQueue's iterator can return null if drainTo(c) executes concurrently Summary: Faster, more correct. Use self-linking trick to avoid gc retention Reviewed-by: martin, dholmes ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! test/java/util/Collection/MOAT.java + test/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java + test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java Changeset: 8cabd2931621 Author: sherman Date: 2009-07-24 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8cabd2931621 5063507: (fmt) missing exception for "%#s" format specifier Summary: throw appropriate exception when necessary Reviewed-by: alanb ! src/share/classes/java/util/Formatter.java ! test/java/util/Formatter/Basic-X.java ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicBigInteger.java ! test/java/util/Formatter/BasicBoolean.java ! test/java/util/Formatter/BasicBooleanObject.java ! test/java/util/Formatter/BasicByte.java ! test/java/util/Formatter/BasicByteObject.java ! test/java/util/Formatter/BasicChar.java ! test/java/util/Formatter/BasicCharObject.java ! test/java/util/Formatter/BasicDateTime.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java ! test/java/util/Formatter/BasicInt.java ! test/java/util/Formatter/BasicIntObject.java ! test/java/util/Formatter/BasicLong.java ! test/java/util/Formatter/BasicLongObject.java ! test/java/util/Formatter/BasicShort.java ! test/java/util/Formatter/BasicShortObject.java Changeset: eb5173d782ca Author: sherman Date: 2009-07-24 11:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eb5173d782ca Merge Changeset: eb27b5587e18 Author: sherman Date: 2009-07-29 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eb27b5587e18 Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: 61d174a58edf Author: martin Date: 2009-07-29 13:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/61d174a58edf 6866554: Misc. javadoc warnings Reviewed-by: alanb ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/file/DirectoryStream.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/attribute/package-info.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java Changeset: bfd7abda8f79 Author: jjb Date: 2009-07-29 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bfd7abda8f79 6804124: Replace "modified mergesort" in java.util.Arrays.sort with timsort Summary: Easy port of timsort from android Reviewed-by: martin ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java + src/share/classes/java/util/ComparableTimSort.java + src/share/classes/java/util/TimSort.java + test/java/util/TimSort/ArrayBuilder.java + test/java/util/TimSort/README + test/java/util/TimSort/SortPerf.java + test/java/util/TimSort/Sorter.java Changeset: 15a7df80058e Author: martin Date: 2009-07-29 21:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/15a7df80058e 6866719: Rename execvpe to avoid symbol clash with glibc 2.10 Reviewed-by: darcy ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 0c58a7b6b978 Author: weijun Date: 2009-07-31 16:21 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0c58a7b6b978 6867231: Regression: jdk/test/sun/security/krb5/ConfPlusProp.java error against jdk7/pit/b68 Reviewed-by: xuelei ! test/sun/security/krb5/ConfPlusProp.java Changeset: e2d9696aa701 Author: alanb Date: 2009-07-31 08:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e2d9696aa701 6867101: Path.checkAccess fails with sharing violation on special files such as pagefile.sys Reviewed-by: sherman ! src/windows/classes/sun/nio/fs/WindowsConstants.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java ! test/java/nio/file/Path/Misc.java Changeset: d5ee8b871362 Author: alanb Date: 2009-07-31 08:45 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d5ee8b871362 6867244: Tests missing @run tag Reviewed-by: sherman ! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java ! test/java/nio/file/Files/ContentType.java Changeset: 160e02039cf7 Author: alanb Date: 2009-07-31 19:23 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/160e02039cf7 Merge Changeset: 358ec67d3252 Author: tbell Date: 2009-07-31 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/358ec67d3252 Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: 2536ab04dc68 Author: weijun Date: 2009-08-02 13:40 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2536ab04dc68 6867687: keytool's standard.sh test timeout sometimes Reviewed-by: xuelei ! test/sun/security/tools/keytool/standard.sh Changeset: 1c9cfd050949 Author: tbell Date: 2009-08-02 10:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1c9cfd050949 Merge Changeset: c390fd8fa885 Author: sherman Date: 2009-08-04 12:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c390fd8fa885 4116222: Errors in Arabic code-conversion tables, part II Summary: updated the IBM420 datatable Reviewed-by: alanb ! make/tools/CharsetMapping/IBM420.c2b ! make/tools/CharsetMapping/IBM420.map ! make/tools/CharsetMapping/IBM420.nr ! make/tools/src/build/tools/charsetmapping/GenerateSBCS.java Changeset: 55186701bdbc Author: martin Date: 2009-08-04 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/55186701bdbc 6868160: (process) Use vfork, not fork, on Linux to avoid swap exhaustion Summary: Boldly go where no jdk has dared go before Reviewed-by: michaelm ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: a789c68f1cf3 Author: martin Date: 2009-08-04 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a789c68f1cf3 6856590: (process) Use RESTARTABLE in UNIXProcess_md.c Summary: Wrap all system calls with RESTARTABLE Reviewed-by: michaelm ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 92394e48eed3 Author: dcubed Date: 2009-08-05 13:17 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/92394e48eed3 6868533: 3/4 JDI: remove '-source 1.5' and '-target 1.5' options from com.sun.jdi tests Summary: We are long past needing to make sure these tests can build on Tiger/JDK1.5.0. Reviewed-by: tbell ! test/com/sun/jdi/EnumTest.java ! test/com/sun/jdi/GenericsTest.java ! test/com/sun/jdi/JdbVarargsTest.sh ! test/com/sun/jdi/StepTest.java ! test/com/sun/jdi/UTF8Test.java ! test/com/sun/jdi/VarargsTest.java Changeset: 2aa570c01c69 Author: wetmore Date: 2009-08-06 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2aa570c01c69 6867657: Many JSN tests do not run under cygwin Reviewed-by: ohair ! test/java/net/Authenticator/B4933582.sh ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/net/Socket/OldSocketImpl.sh ! test/java/net/URL/B5086147.sh ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/security/auth/Subject/doAs/Test.sh ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/tools/jarsigner/AlgOptions.sh ! test/sun/security/tools/jarsigner/PercentSign.sh ! test/sun/security/tools/jarsigner/oldsig.sh ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/CloneKeyAskPassword.sh ! test/sun/security/tools/keytool/NoExtNPE.sh ! test/sun/security/tools/keytool/SecretKeyKS.sh ! test/sun/security/tools/keytool/StandardAlgName.sh ! test/sun/security/tools/keytool/i18n.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/resource.sh ! test/sun/security/tools/keytool/standard.sh Changeset: bc1deb18bfb1 Author: jrose Date: 2009-08-06 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bc1deb18bfb1 6838598: Legal notice repair: jdk/src/share/classes/sun/dyn/FilterGeneric.java Reviewed-by: xdono ! src/share/classes/sun/dyn/FilterGeneric.java Changeset: bf41e885717f Author: tbell Date: 2009-08-06 19:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bf41e885717f Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: 0d99696fec64 Author: chegar Date: 2009-08-07 10:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0d99696fec64 6826780: URLClassPath should use HashMap instead of HashMap Summary: Replace URL with a String representation. Reviewed-by: michaelm, jccollet ! make/sun/net/FILES_java.gmk ! src/share/classes/sun/misc/URLClassPath.java + src/share/classes/sun/net/util/URLUtil.java Changeset: 9424d836691f Author: chegar Date: 2009-08-07 10:51 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9424d836691f 6826801: JarFileFactory should not use HashMap Summary: Replace URL with a String representation. Reviewed-by: michaelm, jccollet ! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: c43105502f46 Author: malenkov Date: 2009-04-29 20:03 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c43105502f46 6660539: Introspector shares cache of mutable BeanInfo between AppContexts. Reviewed-by: peterz ! src/share/classes/java/beans/Introspector.java + test/java/beans/Introspector/Test6660539.java Changeset: 3aeaa5784b3a Author: malenkov Date: 2009-04-29 20:55 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3aeaa5784b3a 6777487: Encoder allows reading private variables with certain names Reviewed-by: peterz ! src/share/classes/java/beans/MetaData.java + test/java/beans/XMLEncoder/6777487/TestBox.java + test/java/beans/XMLEncoder/6777487/TestCheckedCollection.java + test/java/beans/XMLEncoder/6777487/TestCheckedList.java + test/java/beans/XMLEncoder/6777487/TestCheckedMap.java + test/java/beans/XMLEncoder/6777487/TestCheckedRandomAccessList.java + test/java/beans/XMLEncoder/6777487/TestCheckedSet.java + test/java/beans/XMLEncoder/6777487/TestCheckedSortedMap.java + test/java/beans/XMLEncoder/6777487/TestCheckedSortedSet.java + test/java/beans/XMLEncoder/6777487/TestEncoder.java + test/java/beans/XMLEncoder/6777487/TestEnumMap.java + test/java/beans/XMLEncoder/6777487/TestEnumSet.java Changeset: 903ce4bda292 Author: asaha Date: 2009-04-29 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/903ce4bda292 Merge Changeset: 5b166df43d63 Author: peterz Date: 2009-05-05 12:07 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5b166df43d63 6837293: Reapply fix for 6588003 to JDK7 Reviewed-by: alexp ! src/share/classes/javax/swing/text/LayoutQueue.java Changeset: ead34d1e3c9f Author: jccollet Date: 2009-05-05 11:02 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ead34d1e3c9f 6801497: Proxy is assumed to be immutable but is non-final Summary: Cloned the proxy instance when necessary Reviewed-by: chegar ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/URL.java Changeset: 38a0e21f345a Author: anthony Date: 2009-05-05 17:47 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/38a0e21f345a 6805231: Security Warning Icon is missing in Windows 2000 Prof from Jdk build 6u12 Summary: The icon becomes layered only when the fading-out effect is being performed. Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h Changeset: e0636bb69562 Author: anthony Date: 2009-05-05 17:56 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e0636bb69562 6818787: It is possible to reposition the security icon too far from the border of the window on X11 Summary: The constraints for the position of the icon are moved to the shared code Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Window.java ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 4b498e41c1c2 Author: art Date: 2009-05-06 15:17 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4b498e41c1c2 6656586: Cursor.predefined is protected static mutable (findbugs) Reviewed-by: hawtin, igor ! src/share/classes/java/awt/Cursor.java + test/java/awt/Cursor/PredefinedPrivate/PredefinedPrivate.java Changeset: a53a57a3260c Author: emcmanus Date: 2009-05-07 10:44 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a53a57a3260c 6736293: OpenType checks can be bypassed through finalizer resurrection Reviewed-by: hawtin ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenType.java Changeset: 7b50813648d8 Author: bae Date: 2009-05-08 15:38 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7b50813648d8 6656625: ImageReaderSpi.STANDARD_INPUT_TYPE/ImageWriterSpi.STANDARD_OUTPUT_TYPE are mutable static (findbugs) Reviewed-by: prr ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageWriterSpi.java ! src/share/classes/javax/imageio/spi/ImageReaderSpi.java ! src/share/classes/javax/imageio/spi/ImageWriterSpi.java Changeset: c6ea5b6c3a8d Author: bae Date: 2009-05-08 15:57 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c6ea5b6c3a8d 6657133: Mutable statics in imageio plugins (findbugs) Reviewed-by: prr ! src/share/classes/com/sun/imageio/stream/StreamCloser.java ! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java ! src/share/classes/javax/imageio/stream/FileCacheImageInputStream.java ! src/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 597377f1ee71 Author: bae Date: 2009-05-08 16:15 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/597377f1ee71 6823373: [ZDI-CAN-460] Java Web Start JPEG header parsing needs more scruity Reviewed-by: igor ! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c Changeset: 3de7b0daf355 Author: chegar Date: 2009-05-12 16:32 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3de7b0daf355 6801071: Remote sites can compromise user privacy and possibly hijack web sessions Reviewed-by: jccollet, hawtin ! make/sun/net/FILES_java.gmk ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/URL.java + src/share/classes/sun/net/ApplicationProxy.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 05200aff312e Author: amenkov Date: 2009-05-13 13:52 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/05200aff312e 6657625: RmfFileReader/StandardMidiFileWriter.types are public mutable statics (findbugs) Reviewed-by: hawtin ! src/share/classes/com/sun/media/sound/StandardMidiFileWriter.java Changeset: d09b81d1eb85 Author: amenkov Date: 2009-05-13 14:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d09b81d1eb85 6738524: JDK13Services allows read access to system properties from untrusted code Reviewed-by: hawtin ! src/share/classes/com/sun/media/sound/JDK13Services.java Changeset: 43ed4f9a781a Author: amenkov Date: 2009-05-13 14:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/43ed4f9a781a 6777448: JDK13Services.getProviders creates instances with full privileges [hawtin, alexp] Reviewed-by: hawtin, alexp ! src/share/classes/com/sun/media/sound/JSSecurityManager.java Changeset: ae62878e6eef Author: asaha Date: 2009-05-07 13:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ae62878e6eef Merge ! src/share/classes/java/awt/Window.java - src/share/native/sun/java2d/pipe/RenderBuffer.c ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h - test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java Changeset: bf002235470d Author: asaha Date: 2009-06-12 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bf002235470d Merge Changeset: 8156e661d016 Author: asaha Date: 2009-06-12 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8156e661d016 Merge ! src/share/classes/java/awt/Window.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java - src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/IBM1381.java - src/share/classes/sun/nio/cs/ext/IBM1383.java - src/share/classes/sun/nio/cs/ext/IBM930.java - src/share/classes/sun/nio/cs/ext/IBM933.java - src/share/classes/sun/nio/cs/ext/IBM935.java - src/share/classes/sun/nio/cs/ext/IBM937.java - src/share/classes/sun/nio/cs/ext/IBM939.java - src/share/classes/sun/nio/cs/ext/IBM942.java - src/share/classes/sun/nio/cs/ext/IBM943.java - src/share/classes/sun/nio/cs/ext/IBM948.java - src/share/classes/sun/nio/cs/ext/IBM949.java - src/share/classes/sun/nio/cs/ext/IBM950.java - src/share/classes/sun/nio/cs/ext/IBM970.java - src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h Changeset: f2d65a92ffb2 Author: malenkov Date: 2009-06-18 14:08 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f2d65a92ffb2 6660049: Synth Region.uiToRegionMap/lowerCaseNameMap are mutable statics Reviewed-by: hawtin ! src/share/classes/javax/swing/plaf/synth/Region.java + test/javax/swing/plaf/synth/Test6660049.java Changeset: a209372d6de8 Author: asaha Date: 2009-06-17 13:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a209372d6de8 Merge Changeset: 2f126d8c369d Author: asaha Date: 2009-06-18 22:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2f126d8c369d Merge Changeset: 94bd5497a0d3 Author: asaha Date: 2009-06-18 22:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/94bd5497a0d3 Merge Changeset: 75fe05d49f44 Author: asaha Date: 2009-06-22 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/75fe05d49f44 6656610: AccessibleResourceBundle.getContents exposes mutable static (findbugs) Reviewed-by: hawtin ! src/share/classes/javax/accessibility/AccessibleResourceBundle.java Changeset: ffb8e36b668c Author: mullan Date: 2009-06-23 13:54 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ffb8e36b668c 6824440: XML Signature HMAC issue Reviewed-by: asaha ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java + test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java + test/com/sun/org/apache/xml/internal/security/signature-enveloping-hmac-sha1-trunclen-0-attack.xml + test/com/sun/org/apache/xml/internal/security/signature-enveloping-hmac-sha1-trunclen-8-attack.xml ! test/javax/xml/crypto/dsig/GenerationTests.java ! test/javax/xml/crypto/dsig/ValidationTests.java + test/javax/xml/crypto/dsig/data/signature-enveloping-hmac-sha1-trunclen-0-attack.xml + test/javax/xml/crypto/dsig/data/signature-enveloping-hmac-sha1-trunclen-8-attack.xml Changeset: 7352778840c7 Author: ksrini Date: 2009-06-22 07:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7352778840c7 6830335: Java JAR Pack200 Decompression Integer Overflow Vulnerability Summary: Fixes a potential vulnerability in the unpack200 logic, by adding extra checks, a back-port. Reviewed-by: asaha ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: 043280e1fc76 Author: asaha Date: 2009-07-01 09:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/043280e1fc76 Merge ! make/sun/net/FILES_java.gmk ! src/share/classes/java/net/SocksSocketImpl.java - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: 46e4a2e56801 Author: asaha Date: 2009-07-06 11:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/46e4a2e56801 Merge ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h Changeset: e2726b43d1cc Author: mullan Date: 2009-07-08 16:57 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e2726b43d1cc 6858484: If an invalid HMAC XML Signature is validated, all subsequent valid HMAC signatures are invalid Reviewed-by: asaha ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java ! test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java + test/com/sun/org/apache/xml/internal/security/signature-enveloping-hmac-sha1.xml Changeset: 78a1ffa5a675 Author: asaha Date: 2009-07-08 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/78a1ffa5a675 Merge Changeset: 9b15d9813292 Author: asaha Date: 2009-07-08 14:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9b15d9813292 Merge Changeset: 537d8716d8cd Author: asaha Date: 2009-07-13 08:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/537d8716d8cd Merge Changeset: 599a7f770842 Author: asaha Date: 2009-07-15 10:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/599a7f770842 Merge Changeset: 97a5d7c6fbfb Author: vinnie Date: 2009-07-17 20:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/97a5d7c6fbfb 6657619: DnsContext.debug is public static mutable (findbugs) Reviewed-by: alanb ! src/share/classes/com/sun/jndi/dns/DnsContext.java + test/com/sun/jndi/dns/CheckAccess.java Changeset: df7d8ae860cf Author: vinnie Date: 2009-07-17 20:43 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/df7d8ae860cf 6657695: AbstractSaslImpl.logger is a static mutable (findbugs) Reviewed-by: alanb ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java + test/com/sun/security/sasl/util/CheckAccess.java Changeset: 83d1885b22d6 Author: asaha Date: 2009-07-21 13:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/83d1885b22d6 Merge ! src/share/classes/java/awt/Window.java ! src/share/classes/java/beans/MetaData.java - src/share/classes/sun/swing/AccessibleMethod.java Changeset: 14c81c80a7f3 Author: asaha Date: 2009-07-21 13:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/14c81c80a7f3 Merge Changeset: baec332a0ff4 Author: asaha Date: 2009-07-27 22:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/baec332a0ff4 Merge Changeset: ebc7d26588b8 Author: asaha Date: 2009-08-04 08:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ebc7d26588b8 Merge ! src/share/classes/java/awt/Window.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/MetaData.java - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: 6fe590dcc49c Author: asaha Date: 2009-08-05 14:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6fe590dcc49c Merge Changeset: c223ce2294c1 Author: asaha Date: 2009-08-06 22:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c223ce2294c1 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: 1774d87963ad Author: asaha Date: 2009-08-07 09:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1774d87963ad Merge ! make/sun/net/FILES_java.gmk Changeset: 88229bdd8aae Author: andrew Date: 2009-08-07 18:15 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/88229bdd8aae 6869697: Missing entry in makefiles for java/lang/ReflectiveOperationException.java Summary: Add new dependency explicitly so all compilers pick it up Reviewed-by: darcy, ohair ! make/java/java/FILES_java.gmk Changeset: 5439d705c04e Author: weijun Date: 2009-08-11 12:15 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5439d705c04e 6866479: libzip.so caused JVM to crash when running jarsigner Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java + test/sun/security/tools/jarsigner/samename.sh Changeset: c98d2798e16f Author: weijun Date: 2009-08-11 12:17 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c98d2798e16f 6710360: export Kerberos session key to applications Reviewed-by: valeriep + src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java + src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java + src/share/classes/com/sun/security/jgss/InquireType.java ! src/share/classes/sun/security/jgss/GSSContextImpl.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java ! src/share/classes/sun/security/tools/PolicyTool.java + test/com/sun/security/jgss/InquireSecContextPermissionCheck.java ! test/sun/security/krb5/auto/Context.java Changeset: 6db21e653d99 Author: weijun Date: 2009-08-11 12:20 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6db21e653d99 6821190: more InquireType values for ExtendedGSSContext Reviewed-by: valeriep + src/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java ! src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java ! src/share/classes/com/sun/security/jgss/InquireType.java ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/internal/AuthorizationData.java ! src/share/classes/sun/security/tools/PolicyTool.java ! test/sun/security/krb5/auto/Context.java Changeset: efe2d2a55b3b Author: weijun Date: 2009-08-11 15:36 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/efe2d2a55b3b 6868867: Test: sun/security/tools/keytool/standard.sh fails under windows/cygwin Reviewed-by: wetmore ! src/share/classes/sun/security/tools/KeyTool.java Changeset: aface89bfcf6 Author: xuelei Date: 2009-08-11 18:27 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/aface89bfcf6 6585239: Regression: 2 DNS tests fail with JDK 5.0u13 b01 and pass with 5.0u12fcs Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/dns/DnsContext.java Changeset: 5b5df0632ecf Author: alanb Date: 2009-08-11 12:37 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5b5df0632ecf 4516760: (so) Intermittent SocketException: Transport endpoint is not connected (lnx) Reviewed-by: sherman ! src/solaris/native/sun/nio/ch/Net.c ! test/java/nio/channels/SocketChannel/Shutdown.java Changeset: 18554eea6ce6 Author: alanb Date: 2009-08-11 12:38 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/18554eea6ce6 6867781: (file) Examples in javadoc use newFileAttributeView instead of getFileAttributeView Reviewed-by: sherman ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java Changeset: a9a5aabecc01 Author: alanb Date: 2009-08-11 12:49 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a9a5aabecc01 6865748: (file) SimpleFileVisitor methods ignore null arguments Reviewed-by: sherman ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! test/java/nio/file/Files/Misc.java Changeset: 8b97f8827d08 Author: asaha Date: 2009-08-07 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8b97f8827d08 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README Changeset: 1ec22dda0652 Author: asaha Date: 2009-08-10 09:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1ec22dda0652 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: 7681fa43d310 Author: asaha Date: 2009-08-11 08:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7681fa43d310 Merge Changeset: 1ff7163fc5f7 Author: vinnie Date: 2009-08-11 16:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1ff7163fc5f7 6840752: Provide out-of-the-box support for ECC algorithms Reviewed-by: alanb, mullan, wetmore ! make/sun/security/Makefile + make/sun/security/ec/FILES_c.gmk + make/sun/security/ec/Makefile + make/sun/security/ec/mapfile-vers ! make/sun/security/other/Makefile + src/share/classes/sun/security/ec/ECDHKeyAgreement.java + src/share/classes/sun/security/ec/ECDSASignature.java + src/share/classes/sun/security/ec/ECKeyPairGenerator.java + src/share/classes/sun/security/ec/SunEC.java + src/share/classes/sun/security/ec/SunECEntries.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows + src/share/native/sun/security/ec/ECC_JNI.cpp + src/share/native/sun/security/ec/ec.c + src/share/native/sun/security/ec/ec.h + src/share/native/sun/security/ec/ec2.h + src/share/native/sun/security/ec/ec2_163.c + src/share/native/sun/security/ec/ec2_193.c + src/share/native/sun/security/ec/ec2_233.c + src/share/native/sun/security/ec/ec2_aff.c + src/share/native/sun/security/ec/ec2_mont.c + src/share/native/sun/security/ec/ec_naf.c + src/share/native/sun/security/ec/ecc_impl.h + src/share/native/sun/security/ec/ecdecode.c + src/share/native/sun/security/ec/ecl-curve.h + src/share/native/sun/security/ec/ecl-exp.h + src/share/native/sun/security/ec/ecl-priv.h + src/share/native/sun/security/ec/ecl.c + src/share/native/sun/security/ec/ecl.h + src/share/native/sun/security/ec/ecl_curve.c + src/share/native/sun/security/ec/ecl_gf.c + src/share/native/sun/security/ec/ecl_mult.c + src/share/native/sun/security/ec/ecp.h + src/share/native/sun/security/ec/ecp_192.c + src/share/native/sun/security/ec/ecp_224.c + src/share/native/sun/security/ec/ecp_256.c + src/share/native/sun/security/ec/ecp_384.c + src/share/native/sun/security/ec/ecp_521.c + src/share/native/sun/security/ec/ecp_aff.c + src/share/native/sun/security/ec/ecp_jac.c + src/share/native/sun/security/ec/ecp_jm.c + src/share/native/sun/security/ec/ecp_mont.c + src/share/native/sun/security/ec/logtab.h + src/share/native/sun/security/ec/mp_gf2m-priv.h + src/share/native/sun/security/ec/mp_gf2m.c + src/share/native/sun/security/ec/mp_gf2m.h + src/share/native/sun/security/ec/mpi-config.h + src/share/native/sun/security/ec/mpi-priv.h + src/share/native/sun/security/ec/mpi.c + src/share/native/sun/security/ec/mpi.h + src/share/native/sun/security/ec/mplogic.c + src/share/native/sun/security/ec/mplogic.h + src/share/native/sun/security/ec/mpmontg.c + src/share/native/sun/security/ec/mpprime.h + src/share/native/sun/security/ec/oid.c + src/share/native/sun/security/ec/secitem.c + src/share/native/sun/security/ec/secoidt.h + test/sun/security/ec/TestEC.java + test/sun/security/ec/p12passwords.txt + test/sun/security/ec/pkcs12/secp256r1server-secp384r1ca.p12 + test/sun/security/ec/pkcs12/sect193r1server-rsa1024ca.p12 Changeset: 485d3eb9b50b Author: vinnie Date: 2009-08-11 16:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/485d3eb9b50b Merge Changeset: 95ae810b66fb Author: vinnie Date: 2009-08-11 17:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/95ae810b66fb Merge Changeset: 36e0f4e00f20 Author: dcubed Date: 2009-08-11 20:02 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/36e0f4e00f20 6870298: 4/4 fix minor typos in java/lang/instrument/Instrumentation.java Summary: Fix typos in the JavaDoc. Reviewed-by: tbell ! src/share/classes/java/lang/instrument/Instrumentation.java Changeset: 82b66d0368ff Author: dcubed Date: 2009-08-11 20:06 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/82b66d0368ff Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: abac33c4bd67 Author: tbell Date: 2009-08-14 08:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/abac33c4bd67 Merge Changeset: fb51d4974400 Author: uta Date: 2009-07-31 17:24 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fb51d4974400 6851688: Hung up in applet application Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: e6f6765a20f2 Author: yan Date: 2009-08-06 01:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e6f6765a20f2 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: e066c998e4f3 Author: yan Date: 2009-08-12 00:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e066c998e4f3 Merge Changeset: 4c6a5ea563ba Author: peytoia Date: 2009-07-30 14:45 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4c6a5ea563ba 6866243: Javadoc for java.lang.Character still refers to Unicode 4 instead of 5 Reviewed-by: okutsu ! src/share/classes/java/lang/Character.java Changeset: 389cecd0ca18 Author: malenkov Date: 2009-07-31 16:27 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/389cecd0ca18 6865565: Test failed: /test/closed/javax/swing/JInternalFrame/6325652/bug6325652.java Reviewed-by: peterz + test/javax/swing/JInternalFrame/Test6325652.java ! test/javax/swing/JInternalFrame/Test6505027.java ! test/javax/swing/JInternalFrame/Test6802868.java ! test/javax/swing/JScrollPane/Test6526631.java ! test/javax/swing/SwingTest.java Changeset: 23dfc2c451e3 Author: gsm Date: 2009-08-03 19:22 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/23dfc2c451e3 6539700: JTextPane line wrap radically different from previous versions in jre 1.5.0_10+ Reviewed-by: peterz ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/ParagraphView.java + test/javax/swing/text/GlyphView/6539700/bug6539700.java Changeset: e548894909dc Author: andrew Date: 2009-08-06 16:04 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e548894909dc 6593649: Word wrap broken for JTextArea Summary: Layout correctly resizes components based on actual dimensions of the window they are in. Reviewed-by: gsm Contributed-by: Lillian Angel ! src/share/classes/javax/swing/text/WrappedPlainView.java + test/javax/swing/JTextArea/Test6593649.java Changeset: 7f2d92517f09 Author: yan Date: 2009-08-07 02:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7f2d92517f09 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java ! src/share/classes/java/lang/Character.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: 082ffa4c6749 Author: malenkov Date: 2009-08-07 19:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/082ffa4c6749 6868189: Nested enum class with custom BeanInfo fails Reviewed-by: peterz ! src/share/classes/com/sun/beans/finder/BeanInfoFinder.java + test/java/beans/Introspector/Test6868189.java Changeset: 6794e1f16729 Author: rupashka Date: 2009-08-10 14:55 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6794e1f16729 6461173: One JCK test([NewFolderAction0001]) failed on Windows due to lack of PropertyPermission(s) Reviewed-by: peterz, malenkov ! src/share/classes/javax/swing/filechooser/FileSystemView.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java Changeset: 8e65977e4969 Author: alexp Date: 2009-08-10 16:29 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8e65977e4969 6822696: Integrating JXLayer component to Swing library Reviewed-by: peterz, art + src/share/classes/javax/swing/JLayer.java + src/share/classes/javax/swing/plaf/LayerUI.java + test/javax/swing/JLayer/SerializationTest/SerializationTest.java Changeset: 5ff018677b2d Author: yan Date: 2009-08-12 00:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5ff018677b2d Merge Changeset: 893bcca951b7 Author: yan Date: 2009-08-18 23:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/893bcca951b7 Merge Changeset: de49d1343d86 Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/de49d1343d86 Added tag jdk7-b70 for changeset 893bcca951b7 ! .hgtags From john.coomes at sun.com Thu Aug 20 23:11:01 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 21 Aug 2009 06:11:01 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 32 new changesets Message-ID: <20090821061155.484A112236@hg.openjdk.java.net> Changeset: 777a3efad0d5 Author: jjg Date: 2009-07-28 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/777a3efad0d5 6855990: javap InstructionDetailWriter should support new 308 annotations attribute Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java + src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java + test/tools/javap/typeAnnotations/T6855990.java Changeset: 85b317ac8a0c Author: jjg Date: 2009-07-28 11:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/85b317ac8a0c 6734068: Some variable length attributes set their size incorrectly. Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/classfile/CharacterRangeTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LineNumberTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LocalVariableTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LocalVariableTypeTable_attribute.java ! src/share/classes/com/sun/tools/classfile/ModuleExportTable_attribute.java ! src/share/classes/com/sun/tools/classfile/ModuleMemberTable_attribute.java Changeset: c2dfab9e2f39 Author: jjg Date: 2009-07-29 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c2dfab9e2f39 4777949: Javap Rewrite : Warn javap usage on package classes with simple name. Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/JavapFileManager.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties + test/tools/javap/T4777949.java Changeset: 85fecace920b Author: mcimadamore Date: 2009-07-30 10:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/85fecace920b 6827648: Extremely slow compilation time for visitor pattern code + generics Summary: Javac unnecessarily recomputates type-substitutions multiple times Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java Changeset: b1e027181dd4 Author: mcimadamore Date: 2009-07-30 10:30 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/b1e027181dd4 6862608: rich diagnostic sometimes contain wrong type variable numbering Summary: The rich formatter generates worng numbers for type-variables in where clauses Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/Diagnostics/6862608/T6862608a.java + test/tools/javac/Diagnostics/6862608/T6862608a.out + test/tools/javac/Diagnostics/6862608/T6862608b.java + test/tools/javac/Diagnostics/6862608/T6862608b.out Changeset: dd5c51734ad9 Author: mcimadamore Date: 2009-07-30 10:30 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/dd5c51734ad9 6864382: NPE in the rich formatter when processing an unattributed type-variable Summary: Unattributed type variable should not be accessed by the rich formatter when emitting where clauses Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/Diagnostics/6864382/T6864382.java + test/tools/javac/Diagnostics/6864382/T6864382.out Changeset: 6d0add6ad778 Author: mcimadamore Date: 2009-07-30 10:30 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6d0add6ad778 6861837: JCK compilation failures Summary: Type-annotations processing is accessing type info before they are available in MemberEnter Reviewed-by: jjg Contributed-by: mali at csail.mit.edu ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! test/tools/javac/typeAnnotations/InnerClass.java Changeset: 23505e6ea22d Author: jjg Date: 2009-07-30 07:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/23505e6ea22d 6866657: add byteLength method to primary classfile types Reviewed-by: mchung ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/Attributes.java ! src/share/classes/com/sun/tools/classfile/ClassFile.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/Field.java ! src/share/classes/com/sun/tools/classfile/Method.java + test/tools/javap/T6866657.java Changeset: e33efb09ed75 Author: jjg Date: 2009-07-30 09:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e33efb09ed75 4880672: javap does not output inner interfaces of an interface Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties + test/tools/javap/T4880672.java Changeset: dbf8a2816201 Author: tbell Date: 2009-07-31 17:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/dbf8a2816201 Merge Changeset: 743f17b55b44 Author: jjg Date: 2009-08-04 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/743f17b55b44 6867671: javap whitespace formatting issues Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/BasicWriter.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java Changeset: bc0b1f404c40 Author: jjg Date: 2009-08-05 07:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/bc0b1f404c40 6868553: 6867671 breaks some tests Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! test/tools/javac/code/ArrayClone.java ! test/tools/javap/4111861/T4111861.java ! test/tools/javap/T4884240.java ! test/tools/javap/T4975569.java ! test/tools/javap/stackmap/T6271292.sh Changeset: 526de25e0b28 Author: jjg Date: 2009-08-05 08:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/526de25e0b28 6729471: javap should accept class files on the command line Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/T6729471.java Changeset: b5ab848ba68f Author: tbell Date: 2009-08-06 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/b5ab848ba68f Merge Changeset: 160d7a994e69 Author: jjg Date: 2009-08-06 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/160d7a994e69 6858429: javap classfile library a minor bug Reviewed-by: ksrini ! src/share/classes/com/sun/tools/classfile/ClassWriter.java Changeset: 3e38c6da72ec Author: tbell Date: 2009-08-06 20:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/3e38c6da72ec Merge Changeset: cba827f72977 Author: jjg Date: 2009-08-08 17:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/cba827f72977 6868548: remove spurious ';' from after constant pool entries Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java ! test/tools/javac/code/ArrayClone.java Changeset: 961dc3acdb06 Author: jjg Date: 2009-08-08 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/961dc3acdb06 6868539: javap should use current names for constant pool tags Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java + test/tools/javap/T6868539.java Changeset: d5f6c475f475 Author: mcimadamore Date: 2009-08-11 01:11 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d5f6c475f475 6806876: ClassCastException occurs in assignment expressions without any heap pollutions Summary: intersection types should be considered as non-reifiable by javac Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/varargs/6806876/T6806876.java + test/tools/javac/varargs/6806876/T6806876.out Changeset: abe992640c5a Author: mcimadamore Date: 2009-08-11 01:12 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/abe992640c5a 6390045: Unexpected error "cannot access java.lang.Void" with '-target cldc1.0' with -source >=1.5 Summary: javac needs to synthetize a fake java.lang.Void symbol if one is not given on the classpath Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symtab.java + test/tools/javac/6390045/T6390045a.java + test/tools/javac/6390045/T6390045b.java Changeset: 62073a5becc5 Author: mcimadamore Date: 2009-08-11 01:12 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/62073a5becc5 6840059: regression: javac silently crashes when resolving erroneous anonymous inner constructor Summary: resolved an internal crash with constructor resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/6840059/T6840059.java + test/tools/javac/6840059/T6840059.out Changeset: 8227961c64d3 Author: mcimadamore Date: 2009-08-11 01:13 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/8227961c64d3 6521805: Regression: JDK5/JDK6 javac allows write access to outer class reference Summary: javac should warn/complain about identifiers with the same name as synthetic symbol Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/6521805/T6521805a.java + test/tools/javac/6521805/T6521805a_1.out + test/tools/javac/6521805/T6521805a_2.out + test/tools/javac/6521805/T6521805b.java + test/tools/javac/6521805/T6521805c.java + test/tools/javac/6521805/T6521805d.java + test/tools/javac/6521805/T6521805d.out + test/tools/javac/6521805/T6521805e.java + test/tools/javac/6521805/T6521805e.out + test/tools/javac/6521805/p/Outer.java + test/tools/javac/6521805/p/Sub.java ! test/tools/javac/6734819/T6734819a.out ! test/tools/javac/6734819/T6734819b.out ! test/tools/javac/policy/test2/byfile.AB.out ! test/tools/javac/policy/test2/bytodo.AB.out Changeset: 62fb6cafa93b Author: mcimadamore Date: 2009-08-11 01:13 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/62fb6cafa93b 6869075: regression: javac crashes when compiling compound string assignment with generics Summary: javac should not add syntehtic cast to the LHS of an assignment expression Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/generics/T6869075.java Changeset: 13902c0c9b83 Author: mcimadamore Date: 2009-08-11 01:14 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/13902c0c9b83 6569404: Cannot instantiate an inner class of a type variable Summary: javac is too strict in rejecting member selction from a type-var Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/typevars/6569404/T6569404a.java + test/tools/javac/generics/typevars/6569404/T6569404b.java + test/tools/javac/generics/typevars/6569404/T6569404b.out + test/tools/javac/generics/typevars/6569404/T6569404c.java Changeset: c4c424badb83 Author: mcimadamore Date: 2009-08-11 01:14 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c4c424badb83 6199153: Generic throws and overriding Summary: javac incorrectly rejects an uchecked overriding Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/OverrideChecks/6199153/T6199153.java + test/tools/javac/OverrideChecks/6199153/T6199153.out Changeset: 21f1d2462c7c Author: asaha Date: 2009-08-07 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/21f1d2462c7c 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README Changeset: 91852fb12e2e Author: asaha Date: 2009-08-10 09:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/91852fb12e2e Merge Changeset: 38f54dbd2e5b Author: asaha Date: 2009-08-11 08:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/38f54dbd2e5b Merge Changeset: beefdeb352e6 Author: jjg Date: 2009-08-11 14:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/beefdeb352e6 6870591: langtools build sets javac.bootclasspath incorrectly Reviewed-by: ohair ! make/build.xml Changeset: 5a26c8fd0830 Author: jjg Date: 2009-08-11 18:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/5a26c8fd0830 6870743: update comments in langtools/make/build.properties Reviewed-by: darcy ! make/build.properties Changeset: 97d06f3e8787 Author: tbell Date: 2009-08-14 08:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/97d06f3e8787 Merge Changeset: 6f07b50a8796 Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6f07b50a8796 Added tag jdk7-b70 for changeset 97d06f3e8787 ! .hgtags From john.coomes at sun.com Thu Aug 20 22:24:57 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 21 Aug 2009 05:24:57 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 5 new changesets Message-ID: <20090821052505.9CFDC1222C@hg.openjdk.java.net> Changeset: 860b95cc8d1d Author: asaha Date: 2009-08-07 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/860b95cc8d1d 6813167: 6u14 JAX-WS audit mutable static bugs 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README + jaxws.patch + patch.out ! src/share/classes/com/sun/codemodel/internal/JAnnotatable.java ! src/share/classes/com/sun/codemodel/internal/JAnnotationUse.java ! src/share/classes/com/sun/codemodel/internal/JAnnotationWriter.java ! src/share/classes/com/sun/codemodel/internal/JBlock.java ! src/share/classes/com/sun/codemodel/internal/JCommentPart.java ! src/share/classes/com/sun/codemodel/internal/JDirectClass.java ! src/share/classes/com/sun/codemodel/internal/JExpr.java ! src/share/classes/com/sun/codemodel/internal/JJavaName.java ! src/share/classes/com/sun/codemodel/internal/JMethod.java ! src/share/classes/com/sun/codemodel/internal/JPackage.java ! src/share/classes/com/sun/codemodel/internal/JTypeWildcard.java ! src/share/classes/com/sun/codemodel/internal/TypedAnnotationWriter.java - src/share/classes/com/sun/codemodel/internal/fmt/package.html ! src/share/classes/com/sun/codemodel/internal/package-info.java ! src/share/classes/com/sun/codemodel/internal/util/EncoderFactory.java ! src/share/classes/com/sun/codemodel/internal/util/MS1252Encoder.java ! src/share/classes/com/sun/codemodel/internal/writer/FilterCodeWriter.java + src/share/classes/com/sun/istack/internal/Builder.java ! src/share/classes/com/sun/istack/internal/Pool.java ! src/share/classes/com/sun/istack/internal/XMLStreamReaderToContentHandler.java + src/share/classes/com/sun/istack/internal/localization/Localizable.java + src/share/classes/com/sun/istack/internal/localization/LocalizableMessage.java + src/share/classes/com/sun/istack/internal/localization/LocalizableMessageFactory.java + src/share/classes/com/sun/istack/internal/localization/Localizer.java ! src/share/classes/com/sun/istack/internal/ws/AnnotationProcessorFactoryImpl.java ! src/share/classes/com/sun/tools/internal/jxc/ConfigReader.java ! src/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/jxc/Messages.java ! src/share/classes/com/sun/tools/internal/jxc/SchemaGenerator.java + src/share/classes/com/sun/tools/internal/jxc/SchemaGeneratorFacade.java ! src/share/classes/com/sun/tools/internal/jxc/apt/AnnotationParser.java ! src/share/classes/com/sun/tools/internal/jxc/apt/AnnotationProcessorFactoryImpl.java ! src/share/classes/com/sun/tools/internal/jxc/apt/Const.java ! src/share/classes/com/sun/tools/internal/jxc/apt/ErrorReceiverImpl.java ! src/share/classes/com/sun/tools/internal/jxc/apt/InlineAnnotationReaderImpl.java ! src/share/classes/com/sun/tools/internal/jxc/apt/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/jxc/apt/Messages.java ! src/share/classes/com/sun/tools/internal/jxc/apt/Options.java ! src/share/classes/com/sun/tools/internal/jxc/apt/SchemaGenerator.java ! src/share/classes/com/sun/tools/internal/jxc/gen/config/Classes.java ! src/share/classes/com/sun/tools/internal/jxc/gen/config/Config.java ! src/share/classes/com/sun/tools/internal/jxc/gen/config/Schema.java ! src/share/classes/com/sun/tools/internal/jxc/gen/config/config.xsd ! src/share/classes/com/sun/tools/internal/jxc/model/nav/APTNavigator.java ! src/share/classes/com/sun/tools/internal/ws/Invoker.java ! src/share/classes/com/sun/tools/internal/ws/api/TJavaGeneratorExtension.java + src/share/classes/com/sun/tools/internal/ws/api/WsgenExtension.java + src/share/classes/com/sun/tools/internal/ws/api/WsgenProtocol.java ! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtensible.java ! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtension.java ! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtensionHandler.java ! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLOperation.java ! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLParserContext.java ! src/share/classes/com/sun/tools/internal/ws/package-info.java ! src/share/classes/com/sun/tools/internal/ws/processor/generator/GeneratorBase.java ! src/share/classes/com/sun/tools/internal/ws/processor/generator/SeiGenerator.java ! src/share/classes/com/sun/tools/internal/ws/processor/generator/ServiceGenerator.java ! src/share/classes/com/sun/tools/internal/ws/processor/generator/W3CAddressingJavaGeneratorExtension.java ! src/share/classes/com/sun/tools/internal/ws/processor/model/Port.java ! src/share/classes/com/sun/tools/internal/ws/processor/model/java/JavaMethod.java ! src/share/classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBType.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceAP.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceVisitor.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceWrapperGenerator.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/wsdl/ConsoleErrorReporter.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/wsdl/PseudoSchemaBuilder.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/wsdl/WSDLModeler.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/wsdl/WSDLModelerBase.java ! src/share/classes/com/sun/tools/internal/ws/processor/util/ClassNameCollector.java ! src/share/classes/com/sun/tools/internal/ws/resources/GeneratorMessages.java ! src/share/classes/com/sun/tools/internal/ws/resources/ModelMessages.java ! src/share/classes/com/sun/tools/internal/ws/resources/ModelerMessages.java ! src/share/classes/com/sun/tools/internal/ws/resources/WebserviceapMessages.java ! src/share/classes/com/sun/tools/internal/ws/resources/WscompileMessages.java ! src/share/classes/com/sun/tools/internal/ws/resources/WsdlMessages.java ! src/share/classes/com/sun/tools/internal/ws/resources/configuration.properties ! src/share/classes/com/sun/tools/internal/ws/resources/generator.properties ! src/share/classes/com/sun/tools/internal/ws/resources/javacompiler.properties ! src/share/classes/com/sun/tools/internal/ws/resources/model.properties ! src/share/classes/com/sun/tools/internal/ws/resources/modeler.properties ! src/share/classes/com/sun/tools/internal/ws/resources/processor.properties ! src/share/classes/com/sun/tools/internal/ws/resources/util.properties ! src/share/classes/com/sun/tools/internal/ws/resources/webserviceap.properties ! src/share/classes/com/sun/tools/internal/ws/resources/wscompile.properties ! src/share/classes/com/sun/tools/internal/ws/resources/wsdl.properties ! src/share/classes/com/sun/tools/internal/ws/version.properties ! src/share/classes/com/sun/tools/internal/ws/wscompile/AbortException.java + src/share/classes/com/sun/tools/internal/ws/wscompile/AuthInfo.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/BadCommandLineException.java + src/share/classes/com/sun/tools/internal/ws/wscompile/DefaultAuthTester.java + src/share/classes/com/sun/tools/internal/ws/wscompile/DefaultAuthenticator.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/ErrorReceiver.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/ErrorReceiverFilter.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/JavaCompilerHelper.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/Options.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/WsgenOptions.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/WsimportListener.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/WsimportOptions.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/document/Message.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/document/jaxws/JAXWSBinding.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/framework/AbstractDocument.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/AbstractReferenceFinderImpl.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMBuilder.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMForest.java + src/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMForestParser.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMForestScanner.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/InternalizationLogic.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/Internalizer.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/MemberSubmissionAddressingExtensionHandler.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/MetadataFinder.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/NamespaceContextImpl.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/VersionChecker.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/W3CAddressingExtensionHandler.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WSDLInternalizationLogic.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WSDLParser.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WhitespaceStripper.java + src/share/classes/com/sun/tools/internal/xjc/ClassLoaderBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/Driver.java ! src/share/classes/com/sun/tools/internal/xjc/Language.java ! src/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/ModelLoader.java ! src/share/classes/com/sun/tools/internal/xjc/Options.java ! src/share/classes/com/sun/tools/internal/xjc/ProgressCodeWriter.java ! src/share/classes/com/sun/tools/internal/xjc/SchemaCache.java + src/share/classes/com/sun/tools/internal/xjc/XJCFacade.java ! src/share/classes/com/sun/tools/internal/xjc/XJCListener.java ! src/share/classes/com/sun/tools/internal/xjc/addon/at_generated/PluginImpl.java ! src/share/classes/com/sun/tools/internal/xjc/addon/code_injector/Const.java ! src/share/classes/com/sun/tools/internal/xjc/addon/code_injector/PluginImpl.java ! src/share/classes/com/sun/tools/internal/xjc/addon/episode/PluginImpl.java ! src/share/classes/com/sun/tools/internal/xjc/addon/episode/package-info.java ! src/share/classes/com/sun/tools/internal/xjc/api/ClassNameAllocator.java ! src/share/classes/com/sun/tools/internal/xjc/api/J2SJAXBModel.java ! src/share/classes/com/sun/tools/internal/xjc/api/Reference.java ! src/share/classes/com/sun/tools/internal/xjc/api/S2JJAXBModel.java ! src/share/classes/com/sun/tools/internal/xjc/api/SchemaCompiler.java ! src/share/classes/com/sun/tools/internal/xjc/api/SpecVersion.java ! src/share/classes/com/sun/tools/internal/xjc/api/TypeAndAnnotation.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/j2s/JAXBModelImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/j2s/JavaCompilerImpl.java - src/share/classes/com/sun/tools/internal/xjc/api/impl/j2s/Messages.java - src/share/classes/com/sun/tools/internal/xjc/api/impl/j2s/Messages.properties ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/AbstractMappingImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/BeanMappingImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/DowngradingErrorHandler.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/ElementAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/ElementCollectionAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/ElementMappingImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/ElementSingleAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/PropertyImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/SchemaCompilerImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/TypeAndAnnotationImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/package.html ! src/share/classes/com/sun/tools/internal/xjc/api/util/APTClassLoader.java ! src/share/classes/com/sun/tools/internal/xjc/api/util/FilerCodeWriter.java ! src/share/classes/com/sun/tools/internal/xjc/api/util/Messages.properties ! src/share/classes/com/sun/tools/internal/xjc/api/util/ToolsJarNotFoundException.java + src/share/classes/com/sun/tools/internal/xjc/generator/annotation/ri/OverrideAnnotationOfWriter.java ! src/share/classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefWriter.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/BeanGenerator.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/DualObjectFactoryGenerator.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/ElementOutlineImpl.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/ImplStructureStrategy.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/MethodWriter.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/ObjectFactoryGeneratorImpl.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/PrivateObjectFactoryGenerator.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/PublicObjectFactoryGenerator.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/AbstractField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/AbstractFieldWithVar.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/AbstractListField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/ArrayField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/ConstFieldRenderer.java + src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/ContentListField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/DefaultFieldRenderer.java + src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/DummyListField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/FieldRenderer.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/FieldRendererFactory.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/IsSetFieldRenderer.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/Messages.java + src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/NoExtendedContentField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/SingleField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/SinglePrimitiveAccessField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/UnboxedField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/UntypedListFieldRenderer.java ! src/share/classes/com/sun/tools/internal/xjc/generator/package-info.java ! src/share/classes/com/sun/tools/internal/xjc/model/AbstractCElement.java ! src/share/classes/com/sun/tools/internal/xjc/model/AbstractCTypeInfoImpl.java ! src/share/classes/com/sun/tools/internal/xjc/model/AutoClassNameAllocator.java ! src/share/classes/com/sun/tools/internal/xjc/model/CAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/model/CArrayInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CAttributePropertyInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CBuiltinLeafInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CClass.java ! src/share/classes/com/sun/tools/internal/xjc/model/CClassInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CClassInfoParent.java ! src/share/classes/com/sun/tools/internal/xjc/model/CClassRef.java ! src/share/classes/com/sun/tools/internal/xjc/model/CCustomizable.java ! src/share/classes/com/sun/tools/internal/xjc/model/CCustomizations.java ! src/share/classes/com/sun/tools/internal/xjc/model/CDefaultValue.java ! src/share/classes/com/sun/tools/internal/xjc/model/CElement.java ! src/share/classes/com/sun/tools/internal/xjc/model/CElementInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CElementPropertyInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CEnumConstant.java ! src/share/classes/com/sun/tools/internal/xjc/model/CNonElement.java ! src/share/classes/com/sun/tools/internal/xjc/model/CPluginCustomization.java ! src/share/classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CPropertyVisitor.java ! src/share/classes/com/sun/tools/internal/xjc/model/CReferencePropertyInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CSingleTypePropertyInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CTypeInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CTypeRef.java ! src/share/classes/com/sun/tools/internal/xjc/model/CValuePropertyInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CWildcardTypeInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/ClassNameAllocatorWrapper.java ! src/share/classes/com/sun/tools/internal/xjc/model/Model.java ! src/share/classes/com/sun/tools/internal/xjc/model/Populatable.java ! src/share/classes/com/sun/tools/internal/xjc/model/TypeUse.java ! src/share/classes/com/sun/tools/internal/xjc/model/TypeUseFactory.java ! src/share/classes/com/sun/tools/internal/xjc/model/TypeUseImpl.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/EagerNClass.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/EagerNType.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/NClass.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/NClassByJClass.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/NParameterizedType.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/NType.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/NavigatorImpl.java ! src/share/classes/com/sun/tools/internal/xjc/model/package-info.java ! src/share/classes/com/sun/tools/internal/xjc/outline/Aspect.java ! src/share/classes/com/sun/tools/internal/xjc/outline/ClassOutline.java ! src/share/classes/com/sun/tools/internal/xjc/outline/ElementOutline.java ! src/share/classes/com/sun/tools/internal/xjc/outline/EnumConstantOutline.java ! src/share/classes/com/sun/tools/internal/xjc/outline/EnumOutline.java ! src/share/classes/com/sun/tools/internal/xjc/package-info.java ! src/share/classes/com/sun/tools/internal/xjc/reader/AbstractExtensionBindingChecker.java ! src/share/classes/com/sun/tools/internal/xjc/reader/Const.java ! src/share/classes/com/sun/tools/internal/xjc/reader/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/ModelChecker.java ! src/share/classes/com/sun/tools/internal/xjc/reader/RawTypeSet.java ! src/share/classes/com/sun/tools/internal/xjc/reader/Ring.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/Block.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/Element.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/ModelGroup.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/Occurence.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/Term.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DOMBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DOMUtil.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DTDExtensionBindingChecker.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/bindingfile.rng ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/bindingfile.xsd ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/xjc.xsd ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Choice.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/ConnectedComponent.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Element.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/ElementSet.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/ElementSets.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Expression.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Graph.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/OneOrMore.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Sequence.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/SinkNode.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/SourceNode.java ! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/ContentHandlerNamespacePrefixAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/NamespaceContextImpl.java ! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/SCDBasedBindingSet.java ! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/WhitespaceStripper.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/BindStyle.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/ContentModelBinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/DatatypeLib.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/DefineFinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/NameCalculator.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGCompiler.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/RawTypeSetBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/TypePatternBinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/TypeUseBinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/Abstractifier.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BGMBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindBlue.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindGreen.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindPurple.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindRed.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindYellow.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindingComponent.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ClassBinderFilter.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/CollisionInfo.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ColorBinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/DefaultParticleBinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ExpressionBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ExpressionParticleBinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/GElement.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/GElementImpl.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/GWildcardElement.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/Messages.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/MultiplicityCounter.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/RawTypeSetBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/RefererFinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/SimpleTypeBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/UnusedCustomizationChecker.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/AnnotationParserFactoryImpl.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIConversion.java + src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIFactoryMethod.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIGlobalBinding.java + src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIInlineBinaryData.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIProperty.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIXDom.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIXPluginCustomization.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIXSubstitutable.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BindInfo.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/CollectionTypeAttribute.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/DomHandlerEx.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/EnumMemberMode.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/ForkingFilter.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/LocalScoping.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/OptionalPropertyMode.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/binding.rng ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/binding.xsd ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/package-info.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/package.html ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/xjc.xsd ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/xs.xsd + src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/AbstractExtendedComplexTypeBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/ChoiceContentComplexTypeBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/ComplexTypeBindingMode.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/ComplexTypeFieldBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/ExtendedComplexTypeBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/Messages.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MixedComplexTypeBuilder.java + src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MixedExtendedComplexTypeBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/RestrictedComplexTypeBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/LSInputSAXWrapper.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/runtime/JAXBContextFactory.java ! src/share/classes/com/sun/tools/internal/xjc/runtime/ZeroOneBooleanAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/util/ForkContentHandler.java ! src/share/classes/com/sun/tools/internal/xjc/util/ForkEntityResolver.java ! src/share/classes/com/sun/tools/internal/xjc/util/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/util/MimeTypeRange.java ! src/share/classes/com/sun/tools/internal/xjc/util/NamespaceContextAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/util/ReadOnlyAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/util/StringCutter.java ! src/share/classes/com/sun/tools/internal/xjc/util/SubtreeCutter.java ! src/share/classes/com/sun/xml/internal/bind/AccessorFactoryImpl.java ! src/share/classes/com/sun/xml/internal/bind/AnyTypeAdapter.java ! src/share/classes/com/sun/xml/internal/bind/CycleRecoverable.java ! src/share/classes/com/sun/xml/internal/bind/DatatypeConverterImpl.java ! src/share/classes/com/sun/xml/internal/bind/IDResolver.java ! src/share/classes/com/sun/xml/internal/bind/Locatable.java ! src/share/classes/com/sun/xml/internal/bind/Util.java ! src/share/classes/com/sun/xml/internal/bind/ValidationEventLocatorEx.java ! src/share/classes/com/sun/xml/internal/bind/XmlAccessorFactory.java + src/share/classes/com/sun/xml/internal/bind/annotation/OverrideAnnotationOf.java ! src/share/classes/com/sun/xml/internal/bind/annotation/XmlIsSet.java ! src/share/classes/com/sun/xml/internal/bind/annotation/XmlLocation.java ! src/share/classes/com/sun/xml/internal/bind/api/AccessorException.java ! src/share/classes/com/sun/xml/internal/bind/api/Bridge.java ! src/share/classes/com/sun/xml/internal/bind/api/BridgeContext.java ! src/share/classes/com/sun/xml/internal/bind/api/ClassResolver.java ! src/share/classes/com/sun/xml/internal/bind/api/CompositeStructure.java ! src/share/classes/com/sun/xml/internal/bind/api/ErrorListener.java ! src/share/classes/com/sun/xml/internal/bind/api/JAXBRIContext.java + src/share/classes/com/sun/xml/internal/bind/api/Messages.java + src/share/classes/com/sun/xml/internal/bind/api/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/api/RawAccessor.java ! src/share/classes/com/sun/xml/internal/bind/api/TypeReference.java ! src/share/classes/com/sun/xml/internal/bind/api/impl/NameConverter.java ! src/share/classes/com/sun/xml/internal/bind/api/impl/NameUtil.java ! src/share/classes/com/sun/xml/internal/bind/api/package-info.java ! src/share/classes/com/sun/xml/internal/bind/marshaller/DataWriter.java ! src/share/classes/com/sun/xml/internal/bind/marshaller/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/marshaller/MinimumEscapeHandler.java ! src/share/classes/com/sun/xml/internal/bind/marshaller/NamespacePrefixMapper.java ! src/share/classes/com/sun/xml/internal/bind/marshaller/XMLWriter.java ! src/share/classes/com/sun/xml/internal/bind/unmarshaller/DOMScanner.java ! src/share/classes/com/sun/xml/internal/bind/unmarshaller/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/unmarshaller/Patcher.java ! src/share/classes/com/sun/xml/internal/bind/util/AttributesImpl.java ! src/share/classes/com/sun/xml/internal/bind/util/ValidationEventLocatorExImpl.java ! src/share/classes/com/sun/xml/internal/bind/util/Which.java ! src/share/classes/com/sun/xml/internal/bind/v2/ClassFactory.java ! src/share/classes/com/sun/xml/internal/bind/v2/ContextFactory.java ! src/share/classes/com/sun/xml/internal/bind/v2/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/TODO.java ! src/share/classes/com/sun/xml/internal/bind/v2/bytecode/ClassTailor.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/AbstractInlineAnnotationReaderImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/AnnotationReader.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/AnnotationSource.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/ClassLocatable.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/FieldLocatable.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Init.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Locatable.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/LocatableAnnotation.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/MethodLocatable.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Quick.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/RuntimeAnnotationReader.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/RuntimeInlineAnnotationReader.java + src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaTypeQuick.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/Adapter.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ArrayInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/AttributePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/BuiltinLeafInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ClassInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/Element.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ElementInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ElementPropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/EnumConstant.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/EnumLeafInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ErrorHandler.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ID.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/LeafInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/MapPropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/MaybeElement.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/NonElement.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/NonElementRef.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/PropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/PropertyKind.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/Ref.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ReferencePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/RegistryInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/TypeInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/TypeInfoSet.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/TypeRef.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ValuePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/WildcardMode.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/WildcardTypeInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/package-info.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/AnyTypeImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ArrayInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/AttributePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/BuiltinLeafInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ClassInfoImpl.java + src/share/classes/com/sun/xml/internal/bind/v2/model/impl/DummyPropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ERPropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ElementPropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/EnumConstantImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/EnumLeafInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/FieldPropertySeed.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/GetterSetterPropertySeed.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/LeafInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/MapPropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/PropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/PropertySeed.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ReferencePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RegistryInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeAnyTypeImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeArrayInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeAttributePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeClassInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementPropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeEnumConstantImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeEnumLeafInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeMapPropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeModelBuilder.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeReferencePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeTypeInfoSetImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeTypeRefImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeValuePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/SingleTypePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/TypeInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/TypeInfoSetImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/TypeRefImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/Util.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ValuePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/GenericArrayTypeImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/Navigator.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/ParameterizedTypeImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/ReflectionNavigator.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/TypeVisitor.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/WildcardTypeImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeArrayInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeAttributePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeBuiltinLeafInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeClassInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElement.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementPropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeEnumLeafInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeLeafInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeMapPropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeNonElement.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeNonElementRef.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeReferencePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeInfoSet.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeRef.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeValuePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/package-info.java ! src/share/classes/com/sun/xml/internal/bind/v2/package-info.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/AnyTypeBeanInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/ArrayBeanInfoImpl.java + src/share/classes/com/sun/xml/internal/bind/v2/runtime/AttributeAccessor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/BinderImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/BridgeAdapter.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/BridgeContextImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/BridgeImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/ClassBeanInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/CompositeStructureBeanInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Coordinator.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/DomPostInitAction.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/ElementBeanInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/FilterTransducer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/IllegalAnnotationException.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/IllegalAnnotationsException.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/InlineBinaryTransducer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/InternalBridge.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/JaxBeanInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/LeafBeanInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/LifecycleMethods.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Location.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/MimeTypedTransducer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Name.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/NameBuilder.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/NameList.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/RuntimeUtil.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/SchemaTypeTransducer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/StAXPostInitAction.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/SwaRefAdapter.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Transducer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/ValueListBeanInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/XMLSerializer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/C14nXmlOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/DOMOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/Encoded.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/ForkXmlOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/InPlaceDOMOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/IndentingUTF8XmlOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/MTOMXmlOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/NamespaceContextImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/Pcdata.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/SAXOutput.java + src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XMLEventWriterOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XmlOutputAbstractImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/package-info.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayERProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayElementLeafProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayElementNodeProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayElementProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayReferenceNodeProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/AttributeProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ListElementProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/Property.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/PropertyFactory.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/PropertyImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/SingleElementLeafProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/SingleElementNodeProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/SingleReferenceNodeProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/StructureLoaderBuilder.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/TagAndType.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/UnmarshallerChain.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ValueProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/AdaptedAccessor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/AdaptedLister.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/DefaultTransducedAccessor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/ListIterator.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/ListTransducedAccessorImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/NullSafeAccessor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerBoolean.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerByte.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerCharacter.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerDouble.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerFloat.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerInteger.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerLong.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerShort.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/TransducedAccessor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/AccessorInjector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Bean.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Const.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Boolean.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Byte.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Character.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Double.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Float.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Integer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Long.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Ref.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Short.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Injector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Boolean.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Byte.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Character.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Double.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Float.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Integer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Long.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Ref.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Short.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedAccessorFactory.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedTransducedAccessorFactory.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Ref.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Boolean.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Byte.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Double.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Float.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Integer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Long.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Short.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Boolean.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Byte.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Double.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Float.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Integer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Long.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Short.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/AttributesEx.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/AttributesExImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Base64Data.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/ChildLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/DefaultIDResolver.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/DefaultValueLoaderDecorator.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Discarder.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/DomLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/FastInfosetConnector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/IntArrayData.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/IntData.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Intercepter.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/InterningXmlVisitor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LeafPropertyLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Loader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LocatorEx.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LocatorExWrapper.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/MTOMDecorator.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Patcher.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/ProxyLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Receiver.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/SAXConnector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Scope.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXConnector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXEventConnector.java + src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXExConnector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXStreamConnector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StructureLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/TagName.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/TextLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallerImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallingContext.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/ValuePropertyLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/WildcardLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XmlVisitor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XsiNilLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XsiTypeLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/FoolProofResolver.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/Form.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/GroupKind.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/MultiMap.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/Tree.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/XmlSchemaGenerator.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/episode/Bindings.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/episode/Klass.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/episode/SchemaBindings.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/episode/package-info.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/package-info.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ContentModelContainer.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Element.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Occurs.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Particle.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Schema.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleType.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Wildcard.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/ByteArrayOutputStreamEx.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/CollisionCheckStack.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/DataSourceSource.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/EditDistance.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/FatalAdapter.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/FlattenIterator.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/QNameMap.java + src/share/classes/com/sun/xml/internal/bind/v2/util/StackRecorder.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/TypeCast.java ! src/share/classes/com/sun/xml/internal/dtdparser/DTDParser.java ! src/share/classes/com/sun/xml/internal/dtdparser/resources/Messages.properties ! src/share/classes/com/sun/xml/internal/fastinfoset/AbstractResourceBundle.java ! src/share/classes/com/sun/xml/internal/fastinfoset/Decoder.java ! src/share/classes/com/sun/xml/internal/fastinfoset/DecoderStateTables.java ! src/share/classes/com/sun/xml/internal/fastinfoset/Encoder.java ! src/share/classes/com/sun/xml/internal/fastinfoset/algorithm/BuiltInEncodingAlgorithmFactory.java ! src/share/classes/com/sun/xml/internal/fastinfoset/algorithm/HexadecimalEncodingAlgorithm.java ! src/share/classes/com/sun/xml/internal/fastinfoset/algorithm/LongEncodingAlgorithm.java ! src/share/classes/com/sun/xml/internal/fastinfoset/algorithm/UUIDEncodingAlgorithm.java ! src/share/classes/com/sun/xml/internal/fastinfoset/dom/DOMDocumentParser.java ! src/share/classes/com/sun/xml/internal/fastinfoset/dom/DOMDocumentSerializer.java ! src/share/classes/com/sun/xml/internal/fastinfoset/org/apache/xerces/util/XMLChar.java ! src/share/classes/com/sun/xml/internal/fastinfoset/resources/ResourceBundle.properties ! src/share/classes/com/sun/xml/internal/fastinfoset/sax/AttributesHolder.java ! src/share/classes/com/sun/xml/internal/fastinfoset/sax/SAXDocumentParser.java ! src/share/classes/com/sun/xml/internal/fastinfoset/sax/SAXDocumentSerializer.java ! src/share/classes/com/sun/xml/internal/fastinfoset/sax/SAXDocumentSerializerWithPrefixMapping.java ! src/share/classes/com/sun/xml/internal/fastinfoset/stax/StAXDocumentParser.java ! src/share/classes/com/sun/xml/internal/fastinfoset/stax/StAXDocumentSerializer.java - src/share/classes/com/sun/xml/internal/fastinfoset/stax/events/StAXEventAllocator.java ! src/share/classes/com/sun/xml/internal/fastinfoset/tools/VocabularyGenerator.java ! src/share/classes/com/sun/xml/internal/fastinfoset/util/CharArrayIntMap.java ! src/share/classes/com/sun/xml/internal/fastinfoset/util/DuplicateAttributeVerifier.java ! src/share/classes/com/sun/xml/internal/fastinfoset/util/NamespaceContextImplementation.java ! src/share/classes/com/sun/xml/internal/fastinfoset/util/StringIntMap.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/SOAPExceptionImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnectionFactory.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/Envelope.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/FastInfosetDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/GifDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/JpegDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MultipartDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SAAJMetaFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocument.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentFragment.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPIOException.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPPartImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPVersionMismatchException.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/StringDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/XmlDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPFactoryDynamicImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPMessageFactoryDynamicImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CDATAImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CommentImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailEntryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementFactory.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/EnvelopeImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultElementImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderElementImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/TextImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/TreeException.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/name/NameImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Body1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/BodyElement1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Detail1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/DetailEntry1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Envelope1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/FaultElement1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/HeaderElement1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Message1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPFactory1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPMessageFactory1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/BodyElement1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Detail1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/DetailEntry1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Envelope1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/FaultElement1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Message1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPFactory1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPMessageFactory1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/Base64.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/ByteInputStream.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/ByteOutputStream.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/CharReader.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/CharWriter.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/FastInfosetReflection.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/FinalArrayList.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/JAXMStreamSource.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/JaxmURI.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/LogDomainConstants.