From tom.rodriguez at oracle.com Wed Sep 1 05:09:13 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 01 Sep 2010 12:09:13 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 12 new changesets Message-ID: <20100901120933.CA6D9475C4@hg.openjdk.java.net> Changeset: c7004d700b49 Author: dholmes Date: 2010-08-25 21:29 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c7004d700b49 6978641: Fix for 6929067 introduces additional overhead in thread creation/termination paths Summary: Disable stack bounds checks in product mode other than for the initial thread Reviewed-by: coleenp, jcoomes, aph ! src/os/linux/vm/os_linux.cpp Changeset: 2528b5bd749c Author: kamg Date: 2010-08-27 15:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2528b5bd749c 6980262: Memory leak when exception is thrown in static initializer Summary: Use resource memory instead of c-heap for the exception message Reviewed-by: phh, jmasa ! src/share/vm/oops/instanceKlass.cpp Changeset: 8397081c7ac1 Author: dcubed Date: 2010-08-27 21:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8397081c7ac1 Merge Changeset: bba76f745fe6 Author: ysr Date: 2010-08-23 17:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bba76f745fe6 6910183: CMS: assert(_index < capacity(),"_index out of bounds") Summary: Weakened a too-strong, off-by-one assert; added code to keep track of and report any overflows at appropriate level of verbosity. Reviewed-by: jcoomes, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: e967bad2a9ab Author: tonyp Date: 2010-08-25 08:44 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e967bad2a9ab 6941275: G1: The MemoryPools are incorrectly supported for G1 Summary: The way we were caluclating the max value meant that it might fluctuate during the run and this broke some assumptions inside the MBeans framework. This change sets the max value of each pool to -1, which means undefined according to the spec. Reviewed-by: mchung, johnc ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: 8e5955ddf8e4 Author: jcoomes Date: 2010-08-25 14:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8e5955ddf8e4 6978300: G1: debug builds crash if ParallelGCThreads==0 Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 21c29458b334 Author: kevinw Date: 2010-08-27 16:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/21c29458b334 6980392: TEST_BUG: gc/6581734/Test6581734.java has typo Summary: simple correction in testcase Reviewed-by: mchung ! test/gc/6581734/Test6581734.java Changeset: 1c63587d925b Author: tonyp Date: 2010-08-27 13:34 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1c63587d925b 6980206: G1: assert(has_undefined_max_size, "Undefined max size"); Summary: An assert in the management.cpp is too strong and assumes the max size is always defined on memory pools, even when we don't need to use it. Reviewed-by: mchung, johnc ! src/share/vm/services/management.cpp Changeset: af586a7893cf Author: tonyp Date: 2010-08-27 10:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/af586a7893cf Merge Changeset: 75107ee8712f Author: tonyp Date: 2010-08-30 13:00 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/75107ee8712f Merge Changeset: f208bf19192d Author: tonyp Date: 2010-08-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f208bf19192d Merge Changeset: dee553c74493 Author: never Date: 2010-09-01 00:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dee553c74493 Merge From tom.rodriguez at oracle.com Wed Sep 1 19:56:30 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Sep 2010 19:56:30 -0700 Subject: review (XS) for 6981773: incorrect fill value with OptimizeFill Message-ID: http://cr.openjdk.java.net/~never/6981773 6981773: incorrect fill value with OptimizeFill Reviewed-by: The sparc assembly for the new fill logic doesn't fully initialize the value register in the check_fill_8_bytes path resulting in incorrectly filled arrays for certain lengths. Tested with failing tests from nightly. src/cpu/sparc/vm/stubGenerator_sparc.cpp From vladimir.kozlov at oracle.com Wed Sep 1 20:49:26 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Sep 2010 20:49:26 -0700 Subject: review (XS) for 6981773: incorrect fill value with OptimizeFill In-Reply-To: References: Message-ID: <4C7F1EC6.7080701@oracle.com> Looks good. Vladimir On 9/1/10 7:56 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6981773 > > 6981773: incorrect fill value with OptimizeFill > Reviewed-by: > > The sparc assembly for the new fill logic doesn't fully initialize the > value register in the check_fill_8_bytes path resulting in > incorrectly filled arrays for certain lengths. Tested with failing > tests from nightly. > > src/cpu/sparc/vm/stubGenerator_sparc.cpp From christian.thalinger at oracle.com Thu Sep 2 00:01:02 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 02 Sep 2010 09:01:02 +0200 Subject: review (XS) for 6981773: incorrect fill value with OptimizeFill In-Reply-To: References: Message-ID: <1283410862.16375.416.camel@macbook> On Wed, 2010-09-01 at 19:56 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6981773 > > 6981773: incorrect fill value with OptimizeFill > Reviewed-by: > > The sparc assembly for the new fill logic doesn't fully initialize the > value register in the check_fill_8_bytes path resulting in > incorrectly filled arrays for certain lengths. Tested with failing > tests from nightly. > > src/cpu/sparc/vm/stubGenerator_sparc.cpp Looks good. -- Christian From tom.rodriguez at oracle.com Fri Sep 3 00:50:22 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 03 Sep 2010 07:50:22 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6981773: incorrect fill value with OptimizeFill Message-ID: <20100903075030.4BEF6476AB@hg.openjdk.java.net> Changeset: f353275af40e Author: never Date: 2010-09-02 11:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f353275af40e 6981773: incorrect fill value with OptimizeFill Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/stubGenerator_sparc.cpp From tom.rodriguez at oracle.com Fri Sep 3 12:23:57 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 3 Sep 2010 12:23:57 -0700 Subject: review (S) for 6982370: SIGBUS in jbyte_fill Message-ID: http://cr.openjdk.java.net/~never/6982370 6982370: SIGBUS in jbyte_fill Summary: Reviewed-by: In the new fill routines copy less than 8 bytes long skip over the main code and go the final cleanup stage. On sparc this isn't right since it still hasn't accounted for alignment. The fix is to have a special path for handling that. The code doesn't crash on 32 bit sparc because handling of misaligned stores seems to be enabled. Additionally I noticed a problem with the logic for clearing the high bits of a short value. The logic I wrote works correctly for clean ints but doesn't work for 64 bit signed extended ints resulting in invalid fill values in some cases. Tested with failing nightly and new test case to exercise the various alignments. From vladimir.kozlov at oracle.com Fri Sep 3 13:11:18 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Sep 2010 13:11:18 -0700 Subject: review (S) for 6982370: SIGBUS in jbyte_fill In-Reply-To: References: Message-ID: <4C815666.9000703@oracle.com> Tom, Did you run your new test on x86 (32- and 64-bit)? I don't see that O4 and O5 are used after you save 'to', 'count'. Could you use shifts?: __ sllx(O3, 60, O3); __ srlx(O3, 60, O3); instead of: 1641 __ set(0xffff, O3); << 2 instructions 1642 __ and3(value, O3, value); Tom, sorry I don't like your changes which increase the code. How about this: __ BIND(L_fill_4_bytes); __ brx(Assembler::zero, false, Assembler::pt, L_fill_2_bytes); if (t == T_BYTE || t == T_SHORT) { __ delayed()->andcc(count, 1<<(shift-1), G0); + if (t == T_SHORT) { + __ sth(value, to, 0); + __ sth(value, to, 2); + } else { + __ stb(value, to, 0); + __ stb(value, to, 1); + __ stb(value, to, 2); + __ stb(value, to, 3); + } } else { __ delayed()->nop(); + __ stw(value, to, 0); } - __ stw(value, to, 0); if (t == T_BYTE || t == T_SHORT) { __ inc(to, 4); // fill trailing 2 bytes __ andcc(count, 1<<(shift-1), G0); // in delay slot of branches __ BIND(L_fill_2_bytes); __ brx(Assembler::zero, false, Assembler::pt, L_fill_byte); __ delayed()->andcc(count, 1, count); - __ sth(value, to, 0); if (t == T_BYTE) { + __ stb(value, to, 0); + __ stb(value, to, 1); __ inc(to, 2); // fill trailing byte __ andcc(count, 1, count); // in delay slot of branches __ BIND(L_fill_byte); __ brx(Assembler::zero, false, Assembler::pt, L_exit); __ delayed()->nop(); __ stb(value, to, 0); } else { + __ sth(value, to, 0); __ BIND(L_fill_byte); } } else { __ BIND(L_fill_2_bytes); } __ BIND(L_exit); Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6982370 > > 6982370: SIGBUS in jbyte_fill > Summary: > Reviewed-by: > > In the new fill routines copy less than 8 bytes long skip over the > main code and go the final cleanup stage. On sparc this isn't right > since it still hasn't accounted for alignment. The fix is to have a > special path for handling that. The code doesn't crash on 32 bit > sparc because handling of misaligned stores seems to be enabled. > Additionally I noticed a problem with the logic for clearing the high > bits of a short value. The logic I wrote works correctly for clean > ints but doesn't work for 64 bit signed extended ints resulting in > invalid fill values in some cases. Tested with failing nightly and > new test case to exercise the various alignments. From tom.rodriguez at oracle.com Fri Sep 3 13:21:28 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 3 Sep 2010 13:21:28 -0700 Subject: review (S) for 6982370: SIGBUS in jbyte_fill In-Reply-To: <4C815666.9000703@oracle.com> References: <4C815666.9000703@oracle.com> Message-ID: <200ACE2D-9084-4E10-BE3A-E31E8DD9CA44@oracle.com> On Sep 3, 2010, at 1:11 PM, Vladimir Kozlov wrote: > Tom, > > Did you run your new test on x86 (32- and 64-bit)? Yes I did. > > I don't see that O4 and O5 are used after you save 'to', 'count'. Sorry that was some debug code I left behind. > > Could you use shifts?: > > __ sllx(O3, 60, O3); > __ srlx(O3, 60, O3); Yep. You mean 48 don't you? > > instead of: > > 1641 __ set(0xffff, O3); << 2 instructions > 1642 __ and3(value, O3, value); > > Tom, sorry I don't like your changes which increase the code. The normal path doesn't have to split the loads since it knows they are aligned so it seems like a waste to emit extra stores there just so it can be used in the case where it's very small. I could consolidate the slow path more but I don't want to make the main path slower. tom > How about this: > > __ BIND(L_fill_4_bytes); > __ brx(Assembler::zero, false, Assembler::pt, L_fill_2_bytes); > if (t == T_BYTE || t == T_SHORT) { > __ delayed()->andcc(count, 1<<(shift-1), G0); > + if (t == T_SHORT) { > + __ sth(value, to, 0); > + __ sth(value, to, 2); > + } else { > + __ stb(value, to, 0); > + __ stb(value, to, 1); > + __ stb(value, to, 2); > + __ stb(value, to, 3); > + } > } else { > __ delayed()->nop(); > + __ stw(value, to, 0); > } > - __ stw(value, to, 0); > if (t == T_BYTE || t == T_SHORT) { > __ inc(to, 4); > // fill trailing 2 bytes > __ andcc(count, 1<<(shift-1), G0); // in delay slot of branches > __ BIND(L_fill_2_bytes); > __ brx(Assembler::zero, false, Assembler::pt, L_fill_byte); > __ delayed()->andcc(count, 1, count); > - __ sth(value, to, 0); > if (t == T_BYTE) { > + __ stb(value, to, 0); > + __ stb(value, to, 1); > __ inc(to, 2); > // fill trailing byte > __ andcc(count, 1, count); // in delay slot of branches > __ BIND(L_fill_byte); > __ brx(Assembler::zero, false, Assembler::pt, L_exit); > __ delayed()->nop(); > __ stb(value, to, 0); > } else { > + __ sth(value, to, 0); > __ BIND(L_fill_byte); > } > } else { > __ BIND(L_fill_2_bytes); > } > __ BIND(L_exit); > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6982370 >> 6982370: SIGBUS in jbyte_fill >> Summary: >> Reviewed-by: >> In the new fill routines copy less than 8 bytes long skip over the >> main code and go the final cleanup stage. On sparc this isn't right >> since it still hasn't accounted for alignment. The fix is to have a >> special path for handling that. The code doesn't crash on 32 bit >> sparc because handling of misaligned stores seems to be enabled. >> Additionally I noticed a problem with the logic for clearing the high >> bits of a short value. The logic I wrote works correctly for clean >> ints but doesn't work for 64 bit signed extended ints resulting in >> invalid fill values in some cases. Tested with failing nightly and >> new test case to exercise the various alignments. From vladimir.kozlov at oracle.com Fri Sep 3 13:25:24 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Sep 2010 13:25:24 -0700 Subject: review (S) for 6982370: SIGBUS in jbyte_fill In-Reply-To: <200ACE2D-9084-4E10-BE3A-E31E8DD9CA44@oracle.com> References: <4C815666.9000703@oracle.com> <200ACE2D-9084-4E10-BE3A-E31E8DD9CA44@oracle.com> Message-ID: <4C8159B4.6040308@oracle.com> Tom Rodriguez wrote: >> Could you use shifts?: >> >> __ sllx(O3, 60, O3); >> __ srlx(O3, 60, O3); > > Yep. You mean 48 don't you? Yes, sorry mmy mistake. > >> instead of: >> >> 1641 __ set(0xffff, O3); << 2 instructions >> 1642 __ and3(value, O3, value); >> >> Tom, sorry I don't like your changes which increase the code. > > The normal path doesn't have to split the loads since it knows they are aligned so it seems like a waste to emit extra stores there just so it can be used in the case where it's very small. I could consolidate the slow path more but I don't want to make the main path slower. OK, I got it. Now I agree with your code. It is good to go. Thanks, Vladimir > > tom > >> How about this: >> >> __ BIND(L_fill_4_bytes); >> __ brx(Assembler::zero, false, Assembler::pt, L_fill_2_bytes); >> if (t == T_BYTE || t == T_SHORT) { >> __ delayed()->andcc(count, 1<<(shift-1), G0); >> + if (t == T_SHORT) { >> + __ sth(value, to, 0); >> + __ sth(value, to, 2); >> + } else { >> + __ stb(value, to, 0); >> + __ stb(value, to, 1); >> + __ stb(value, to, 2); >> + __ stb(value, to, 3); >> + } >> } else { >> __ delayed()->nop(); >> + __ stw(value, to, 0); >> } >> - __ stw(value, to, 0); >> if (t == T_BYTE || t == T_SHORT) { >> __ inc(to, 4); >> // fill trailing 2 bytes >> __ andcc(count, 1<<(shift-1), G0); // in delay slot of branches >> __ BIND(L_fill_2_bytes); >> __ brx(Assembler::zero, false, Assembler::pt, L_fill_byte); >> __ delayed()->andcc(count, 1, count); >> - __ sth(value, to, 0); >> if (t == T_BYTE) { >> + __ stb(value, to, 0); >> + __ stb(value, to, 1); >> __ inc(to, 2); >> // fill trailing byte >> __ andcc(count, 1, count); // in delay slot of branches >> __ BIND(L_fill_byte); >> __ brx(Assembler::zero, false, Assembler::pt, L_exit); >> __ delayed()->nop(); >> __ stb(value, to, 0); >> } else { >> + __ sth(value, to, 0); >> __ BIND(L_fill_byte); >> } >> } else { >> __ BIND(L_fill_2_bytes); >> } >> __ BIND(L_exit); >> >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6982370 >>> 6982370: SIGBUS in jbyte_fill >>> Summary: >>> Reviewed-by: >>> In the new fill routines copy less than 8 bytes long skip over the >>> main code and go the final cleanup stage. On sparc this isn't right >>> since it still hasn't accounted for alignment. The fix is to have a >>> special path for handling that. The code doesn't crash on 32 bit >>> sparc because handling of misaligned stores seems to be enabled. >>> Additionally I noticed a problem with the logic for clearing the high >>> bits of a short value. The logic I wrote works correctly for clean >>> ints but doesn't work for 64 bit signed extended ints resulting in >>> invalid fill values in some cases. Tested with failing nightly and >>> new test case to exercise the various alignments. > From tom.rodriguez at oracle.com Fri Sep 3 13:29:43 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 3 Sep 2010 13:29:43 -0700 Subject: review (S) for 6982370: SIGBUS in jbyte_fill In-Reply-To: <4C8159B4.6040308@oracle.com> References: <4C815666.9000703@oracle.com> <200ACE2D-9084-4E10-BE3A-E31E8DD9CA44@oracle.com> <4C8159B4.6040308@oracle.com> Message-ID: <0C9AE09E-1785-4B75-8D89-E2BEEA7EA85C@oracle.com> Thanks. I've updated the webrev and rerun the test. tom On Sep 3, 2010, at 1:25 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >>> Could you use shifts?: >>> >>> __ sllx(O3, 60, O3); >>> __ srlx(O3, 60, O3); >> Yep. You mean 48 don't you? > > Yes, sorry mmy mistake. > >>> instead of: >>> >>> 1641 __ set(0xffff, O3); << 2 instructions >>> 1642 __ and3(value, O3, value); >>> >>> Tom, sorry I don't like your changes which increase the code. >> The normal path doesn't have to split the loads since it knows they are aligned so it seems like a waste to emit extra stores there just so it can be used in the case where it's very small. I could consolidate the slow path more but I don't want to make the main path slower. > > OK, I got it. Now I agree with your code. It is good to go. > > Thanks, > Vladimir > >> tom >>> How about this: >>> >>> __ BIND(L_fill_4_bytes); >>> __ brx(Assembler::zero, false, Assembler::pt, L_fill_2_bytes); >>> if (t == T_BYTE || t == T_SHORT) { >>> __ delayed()->andcc(count, 1<<(shift-1), G0); >>> + if (t == T_SHORT) { >>> + __ sth(value, to, 0); >>> + __ sth(value, to, 2); >>> + } else { >>> + __ stb(value, to, 0); >>> + __ stb(value, to, 1); >>> + __ stb(value, to, 2); >>> + __ stb(value, to, 3); >>> + } >>> } else { >>> __ delayed()->nop(); >>> + __ stw(value, to, 0); >>> } >>> - __ stw(value, to, 0); >>> if (t == T_BYTE || t == T_SHORT) { >>> __ inc(to, 4); >>> // fill trailing 2 bytes >>> __ andcc(count, 1<<(shift-1), G0); // in delay slot of branches >>> __ BIND(L_fill_2_bytes); >>> __ brx(Assembler::zero, false, Assembler::pt, L_fill_byte); >>> __ delayed()->andcc(count, 1, count); >>> - __ sth(value, to, 0); >>> if (t == T_BYTE) { >>> + __ stb(value, to, 0); >>> + __ stb(value, to, 1); >>> __ inc(to, 2); >>> // fill trailing byte >>> __ andcc(count, 1, count); // in delay slot of branches >>> __ BIND(L_fill_byte); >>> __ brx(Assembler::zero, false, Assembler::pt, L_exit); >>> __ delayed()->nop(); >>> __ stb(value, to, 0); >>> } else { >>> + __ sth(value, to, 0); >>> __ BIND(L_fill_byte); >>> } >>> } else { >>> __ BIND(L_fill_2_bytes); >>> } >>> __ BIND(L_exit); >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6982370 >>>> 6982370: SIGBUS in jbyte_fill >>>> Summary: >>>> Reviewed-by: >>>> In the new fill routines copy less than 8 bytes long skip over the >>>> main code and go the final cleanup stage. On sparc this isn't right >>>> since it still hasn't accounted for alignment. The fix is to have a >>>> special path for handling that. The code doesn't crash on 32 bit >>>> sparc because handling of misaligned stores seems to be enabled. >>>> Additionally I noticed a problem with the logic for clearing the high >>>> bits of a short value. The logic I wrote works correctly for clean >>>> ints but doesn't work for 64 bit signed extended ints resulting in >>>> invalid fill values in some cases. Tested with failing nightly and >>>> new test case to exercise the various alignments. From vladimir.kozlov at oracle.com Fri Sep 3 14:37:00 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Sep 2010 14:37:00 -0700 Subject: review (S) for 6982370: SIGBUS in jbyte_fill In-Reply-To: <0C9AE09E-1785-4B75-8D89-E2BEEA7EA85C@oracle.com> References: <4C815666.9000703@oracle.com> <200ACE2D-9084-4E10-BE3A-E31E8DD9CA44@oracle.com> <4C8159B4.6040308@oracle.com> <0C9AE09E-1785-4B75-8D89-E2BEEA7EA85C@oracle.com> Message-ID: <4C816A7C.7070009@oracle.com> Good. Vladimir Tom Rodriguez wrote: > Thanks. I've updated the webrev and rerun the test. > > tom > > On Sep 3, 2010, at 1:25 PM, Vladimir Kozlov wrote: > >> Tom Rodriguez wrote: >>>> Could you use shifts?: >>>> >>>> __ sllx(O3, 60, O3); >>>> __ srlx(O3, 60, O3); >>> Yep. You mean 48 don't you? >> Yes, sorry mmy mistake. >> >>>> instead of: >>>> >>>> 1641 __ set(0xffff, O3); << 2 instructions >>>> 1642 __ and3(value, O3, value); >>>> >>>> Tom, sorry I don't like your changes which increase the code. >>> The normal path doesn't have to split the loads since it knows they are aligned so it seems like a waste to emit extra stores there just so it can be used in the case where it's very small. I could consolidate the slow path more but I don't want to make the main path slower. >> OK, I got it. Now I agree with your code. It is good to go. >> >> Thanks, >> Vladimir >> >>> tom >>>> How about this: >>>> >>>> __ BIND(L_fill_4_bytes); >>>> __ brx(Assembler::zero, false, Assembler::pt, L_fill_2_bytes); >>>> if (t == T_BYTE || t == T_SHORT) { >>>> __ delayed()->andcc(count, 1<<(shift-1), G0); >>>> + if (t == T_SHORT) { >>>> + __ sth(value, to, 0); >>>> + __ sth(value, to, 2); >>>> + } else { >>>> + __ stb(value, to, 0); >>>> + __ stb(value, to, 1); >>>> + __ stb(value, to, 2); >>>> + __ stb(value, to, 3); >>>> + } >>>> } else { >>>> __ delayed()->nop(); >>>> + __ stw(value, to, 0); >>>> } >>>> - __ stw(value, to, 0); >>>> if (t == T_BYTE || t == T_SHORT) { >>>> __ inc(to, 4); >>>> // fill trailing 2 bytes >>>> __ andcc(count, 1<<(shift-1), G0); // in delay slot of branches >>>> __ BIND(L_fill_2_bytes); >>>> __ brx(Assembler::zero, false, Assembler::pt, L_fill_byte); >>>> __ delayed()->andcc(count, 1, count); >>>> - __ sth(value, to, 0); >>>> if (t == T_BYTE) { >>>> + __ stb(value, to, 0); >>>> + __ stb(value, to, 1); >>>> __ inc(to, 2); >>>> // fill trailing byte >>>> __ andcc(count, 1, count); // in delay slot of branches >>>> __ BIND(L_fill_byte); >>>> __ brx(Assembler::zero, false, Assembler::pt, L_exit); >>>> __ delayed()->nop(); >>>> __ stb(value, to, 0); >>>> } else { >>>> + __ sth(value, to, 0); >>>> __ BIND(L_fill_byte); >>>> } >>>> } else { >>>> __ BIND(L_fill_2_bytes); >>>> } >>>> __ BIND(L_exit); >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/6982370 >>>>> 6982370: SIGBUS in jbyte_fill >>>>> Summary: >>>>> Reviewed-by: >>>>> In the new fill routines copy less than 8 bytes long skip over the >>>>> main code and go the final cleanup stage. On sparc this isn't right >>>>> since it still hasn't accounted for alignment. The fix is to have a >>>>> special path for handling that. The code doesn't crash on 32 bit >>>>> sparc because handling of misaligned stores seems to be enabled. >>>>> Additionally I noticed a problem with the logic for clearing the high >>>>> bits of a short value. The logic I wrote works correctly for clean >>>>> ints but doesn't work for 64 bit signed extended ints resulting in >>>>> invalid fill values in some cases. Tested with failing nightly and >>>>> new test case to exercise the various alignments. > From rasbold at google.com Fri Sep 3 14:48:14 2010 From: rasbold at google.com (Chuck Rasbold) Date: Fri, 3 Sep 2010 14:48:14 -0700 Subject: LogCompilation and OnError Message-ID: Currently, if the VM aborts, LogCompilation files are flushed and closed as a result of a call to ostream_abort() in os::shutdown(). I'd like the LogCompilation files flushed a little earlier, ideally, immediately before OnError commands are processed in vmError::report_and_die(). Has this been investigated before? Any concerns about moving the call to ostream_abort from the os specific files into vmError.cpp? -- Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100903/1c26e7f7/attachment.html From john.r.rose at oracle.com Fri Sep 3 14:53:15 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 3 Sep 2010 14:53:15 -0700 Subject: LogCompilation and OnError In-Reply-To: References: Message-ID: On Sep 3, 2010, at 2:48 PM, Chuck Rasbold wrote: > Currently, if the VM aborts, LogCompilation files are flushed and closed as a result of a call to ostream_abort() in os::shutdown(). > > I'd like the LogCompilation files flushed a little earlier, ideally, immediately before OnError commands are processed in vmError::report_and_die(). > > Has this been investigated before? Any concerns about moving the call to ostream_abort from the os specific files into vmError.cpp? I don't think so. It seems like flushing those buffers is a low-risk thing to do, and so could be done earlier during crash dumping. The thing to avoid is causing an already-crashing JVM to crash even more, by trying to traverse broken data structures. There is some logic called "STEP" in vmError.cpp which tries each dump phase at most once. The buffer flushing (even though it is not likely to fail) should probably be covered by that logic. -- John From tom.rodriguez at oracle.com Fri Sep 3 17:37:50 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 3 Sep 2010 17:37:50 -0700 Subject: review (S) for 6965815: OptimizeStringConcat: assert(!q->is_MergeMem()) failed with specjbb2000 Message-ID: <085CBB4B-6E96-4FBA-842B-CD28A668C4EB@oracle.com> http://cr.openjdk.java.net/~never/6965815 6965815: OptimizeStringConcat: assert(!q->is_MergeMem()) failed with specjbb2000 Reviewed-by: OptimizeStringConcat does a bunch of graph surgery to stitch an inlined call into the graph after normal inlining has completed. Because of this it can create some unexpected patterns. In this case the final memory state of an inline results in a MergeMem that gathers all the memory effects and inside replace_call it replaces the old call memory projection. In the failing case one of the users of that memory is also a MergeMem which results in a MergeMem feeding a MergeMem which can make the system unhappy. The fix is detect this pattern after replacing the call and call transform to allow the optimizer to clean it up. Tested with failing test from report and a case that Vladimir found. I also ran full CTW and with OptimizerStringConcat and it all looks good. From vladimir.kozlov at oracle.com Fri Sep 3 17:41:55 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Sep 2010 17:41:55 -0700 Subject: review (S) for 6965815: OptimizeStringConcat: assert(!q->is_MergeMem()) failed with specjbb2000 In-Reply-To: <085CBB4B-6E96-4FBA-842B-CD28A668C4EB@oracle.com> References: <085CBB4B-6E96-4FBA-842B-CD28A668C4EB@oracle.com> Message-ID: <4C8195D3.4090705@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6965815 > > 6965815: OptimizeStringConcat: assert(!q->is_MergeMem()) failed with specjbb2000 > Reviewed-by: > > OptimizeStringConcat does a bunch of graph surgery to stitch an > inlined call into the graph after normal inlining has completed. > Because of this it can create some unexpected patterns. In this case > the final memory state of an inline results in a MergeMem that gathers > all the memory effects and inside replace_call it replaces the old > call memory projection. In the failing case one of the users of that > memory is also a MergeMem which results in a MergeMem feeding a > MergeMem which can make the system unhappy. The fix is detect this > pattern after replacing the call and call transform to allow the > optimizer to clean it up. Tested with failing test from report and a > case that Vladimir found. I also ran full CTW and with > OptimizerStringConcat and it all looks good. From igor.veresov at oracle.com Fri Sep 3 20:30:16 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sat, 04 Sep 2010 03:30:16 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6953144: Tiered compilation Message-ID: <20100904033018.E2D9C476EA@hg.openjdk.java.net> Changeset: d5d065957597 Author: iveresov Date: 2010-09-03 17:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d5d065957597 6953144: Tiered compilation Summary: Infrastructure for tiered compilation support (interpreter + c1 + c2) for 32 and 64 bit. Simple tiered policy implementation. Reviewed-by: kvn, never, phh, twisti ! make/linux/Makefile ! make/solaris/Makefile + make/solaris/makefiles/reorder_TIERED_sparcv9 ! make/windows/build.make ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.hpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/invocationCounter.cpp ! src/share/vm/interpreter/invocationCounter.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/dtraceJSDT.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp + src/share/vm/runtime/simpleThresholdPolicy.cpp + src/share/vm/runtime/simpleThresholdPolicy.hpp + src/share/vm/runtime/simpleThresholdPolicy.inline.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/macros.hpp From john.r.rose at oracle.com Sun Sep 5 00:00:14 2010 From: john.r.rose at oracle.com (John Rose) Date: Sun, 5 Sep 2010 00:00:14 -0700 Subject: Request for review (L): 6964498: JSR 292 invokedynamic sites need local bootstrap methods In-Reply-To: References: Message-ID: <3A3A79AC-377C-429F-A08D-3327AC851C37@oracle.com> Over the next week or two I am pushing a series of JDK changes for the JSR 292 API. Like previous changes, many are coordinated with JVM changes. Some are purely Java changes. The JVM changes for 6964498 were pushed 7 weeks ago. Here are the associated JDK changes: http://cr.openjdk.java.net/~jrose/6964498/jdk-webrev.01 There are other changes mixed with this, and more to come also. -- John From john.r.rose at oracle.com Sun Sep 5 00:01:49 2010 From: john.r.rose at oracle.com (John Rose) Date: Sun, 5 Sep 2010 00:01:49 -0700 Subject: Request for review (M): 6980096: JSR 292 reflective lookup should throw checked exceptions In-Reply-To: References: Message-ID: <55E59039-DA4B-410E-A38F-979E47175369@oracle.com> This one changes method handle lookups to throw checked exceptions: http://cr.openjdk.java.net/~jrose/6980096/webrev.00/ -- John From john.r.rose at oracle.com Sun Sep 5 00:04:31 2010 From: john.r.rose at oracle.com (John Rose) Date: Sun, 5 Sep 2010 00:04:31 -0700 Subject: Request for review (S): 6953246: JSR 292 should support SAM conversion Message-ID: <5C3F9187-F3D4-4681-97BE-A8D669FBCCD3@oracle.com> One important API point in MethodHandles: A SAM constructor for method handles. http://cr.openjdk.java.net/~jrose/6953246/webrev.00/ From forax at univ-mlv.fr Sun Sep 5 06:37:51 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 05 Sep 2010 15:37:51 +0200 Subject: Request for review (S): 6953246: JSR 292 should support SAM conversion In-Reply-To: <5C3F9187-F3D4-4681-97BE-A8D669FBCCD3@oracle.com> References: <5C3F9187-F3D4-4681-97BE-A8D669FBCCD3@oracle.com> Message-ID: <4C839D2F.4030904@univ-mlv.fr> Le 05/09/2010 09:04, John Rose a ?crit : > One important API point in MethodHandles: A SAM constructor for method handles. > > http://cr.openjdk.java.net/~jrose/6953246/webrev.00/ > > The answer to the question "Should we delegate equals/hashCode to the targets?" The answer is no ! hashcode should be System.identityHashCode(proxy) equals should be proxy == args[0] and toString() should returns getClass().getName() + '@' + Integer.toHexString(hashCode()). i.e the proxy must simulate the fact that the SAM inherits from java.lang.Object. R?mi From forax at univ-mlv.fr Sun Sep 5 09:44:36 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 05 Sep 2010 18:44:36 +0200 Subject: hg: jdk7/hotspot-comp/hotspot: 6953144: Tiered compilation In-Reply-To: <20100904033018.E2D9C476EA@hg.openjdk.java.net> References: <20100904033018.E2D9C476EA@hg.openjdk.java.net> Message-ID: <4C83C8F4.2080900@univ-mlv.fr> Wow, great ! It works better than previous code. I've tested with eclipse (3.7M1 on linux) and it crashes after one hour, I was not able to reproduce it :( I have put the crash log as attachment, perhaps you can found the issue. R?mi Le 04/09/2010 05:30, igor.veresov at oracle.com a ?crit : > Changeset: d5d065957597 > Author: iveresov > Date: 2010-09-03 17:51 -0700 > URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d5d065957597 > > 6953144: Tiered compilation > Summary: Infrastructure for tiered compilation support (interpreter + c1 + c2) for 32 and 64 bit. Simple tiered policy implementation. > Reviewed-by: kvn, never, phh, twisti > > ! make/linux/Makefile > ! make/solaris/Makefile > + make/solaris/makefiles/reorder_TIERED_sparcv9 > ! make/windows/build.make > ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp > ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp > ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp > ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp > ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp > ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp > ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp > ! src/cpu/sparc/vm/c1_globals_sparc.hpp > ! src/cpu/sparc/vm/c2_globals_sparc.hpp > ! src/cpu/sparc/vm/interp_masm_sparc.cpp > ! src/cpu/sparc/vm/interp_masm_sparc.hpp > ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp > ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp > ! src/cpu/sparc/vm/templateTable_sparc.cpp > ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp > ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > ! src/cpu/x86/vm/c1_LIRAssembler_x86.hpp > ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp > ! src/cpu/x86/vm/c1_Runtime1_x86.cpp > ! src/cpu/x86/vm/c1_globals_x86.hpp > ! src/cpu/x86/vm/c2_globals_x86.hpp > ! src/cpu/x86/vm/interp_masm_x86_32.cpp > ! src/cpu/x86/vm/interp_masm_x86_32.hpp > ! src/cpu/x86/vm/interp_masm_x86_64.cpp > ! src/cpu/x86/vm/interp_masm_x86_64.hpp > ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp > ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp > ! src/cpu/x86/vm/templateTable_x86_32.cpp > ! src/cpu/x86/vm/templateTable_x86_64.cpp > ! src/cpu/x86/vm/vtableStubs_x86_64.cpp > ! src/share/vm/c1/c1_Canonicalizer.cpp > ! src/share/vm/c1/c1_Canonicalizer.hpp > ! src/share/vm/c1/c1_CodeStubs.hpp > ! src/share/vm/c1/c1_Compilation.cpp > ! src/share/vm/c1/c1_Compilation.hpp > ! src/share/vm/c1/c1_Compiler.hpp > ! src/share/vm/c1/c1_GraphBuilder.cpp > ! src/share/vm/c1/c1_GraphBuilder.hpp > ! src/share/vm/c1/c1_IR.cpp > ! src/share/vm/c1/c1_Instruction.cpp > ! src/share/vm/c1/c1_Instruction.hpp > ! src/share/vm/c1/c1_InstructionPrinter.cpp > ! src/share/vm/c1/c1_InstructionPrinter.hpp > ! src/share/vm/c1/c1_LIR.cpp > ! src/share/vm/c1/c1_LIR.hpp > ! src/share/vm/c1/c1_LIRAssembler.cpp > ! src/share/vm/c1/c1_LIRAssembler.hpp > ! src/share/vm/c1/c1_LIRGenerator.cpp > ! src/share/vm/c1/c1_LIRGenerator.hpp > ! src/share/vm/c1/c1_Optimizer.cpp > ! src/share/vm/c1/c1_Runtime1.cpp > ! src/share/vm/c1/c1_Runtime1.hpp > ! src/share/vm/c1/c1_ValueMap.hpp > ! src/share/vm/c1/c1_globals.hpp > ! src/share/vm/ci/ciEnv.cpp > ! src/share/vm/ci/ciMethod.cpp > ! src/share/vm/ci/ciMethod.hpp > ! src/share/vm/ci/ciMethodData.cpp > ! src/share/vm/ci/ciMethodData.hpp > ! src/share/vm/classfile/classLoader.cpp > ! src/share/vm/code/nmethod.cpp > ! src/share/vm/code/nmethod.hpp > ! src/share/vm/compiler/compileBroker.cpp > ! src/share/vm/compiler/compileBroker.hpp > ! src/share/vm/includeDB_compiler1 > ! src/share/vm/includeDB_compiler2 > ! src/share/vm/includeDB_core > ! src/share/vm/interpreter/interpreterRuntime.cpp > ! src/share/vm/interpreter/invocationCounter.cpp > ! src/share/vm/interpreter/invocationCounter.hpp > ! src/share/vm/interpreter/linkResolver.cpp > ! src/share/vm/oops/instanceKlass.cpp > ! src/share/vm/oops/instanceKlass.hpp > ! src/share/vm/oops/methodDataOop.cpp > ! src/share/vm/oops/methodDataOop.hpp > ! src/share/vm/oops/methodKlass.cpp > ! src/share/vm/oops/methodOop.cpp > ! src/share/vm/oops/methodOop.hpp > ! src/share/vm/opto/bytecodeInfo.cpp > ! src/share/vm/opto/compile.cpp > ! src/share/vm/prims/methodHandleWalk.cpp > ! src/share/vm/runtime/arguments.cpp > ! src/share/vm/runtime/arguments.hpp > ! src/share/vm/runtime/compilationPolicy.cpp > ! src/share/vm/runtime/compilationPolicy.hpp > ! src/share/vm/runtime/deoptimization.cpp > ! src/share/vm/runtime/deoptimization.hpp > ! src/share/vm/runtime/dtraceJSDT.cpp > ! src/share/vm/runtime/globals.hpp > ! src/share/vm/runtime/java.cpp > ! src/share/vm/runtime/javaCalls.cpp > ! src/share/vm/runtime/safepoint.cpp > ! src/share/vm/runtime/safepoint.hpp > + src/share/vm/runtime/simpleThresholdPolicy.cpp > + src/share/vm/runtime/simpleThresholdPolicy.hpp > + src/share/vm/runtime/simpleThresholdPolicy.inline.hpp > ! src/share/vm/runtime/sweeper.cpp > ! src/share/vm/utilities/accessFlags.hpp > ! src/share/vm/utilities/globalDefinitions.hpp > ! src/share/vm/utilities/macros.hpp > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid1335.log Url: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100905/52065d23/attachment-0001.ksh From christian.thalinger at oracle.com Tue Sep 7 02:03:33 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 07 Sep 2010 11:03:33 +0200 Subject: Request for review (L): 6964498: JSR 292 invokedynamic sites need local bootstrap methods In-Reply-To: <3A3A79AC-377C-429F-A08D-3327AC851C37@oracle.com> References: <3A3A79AC-377C-429F-A08D-3327AC851C37@oracle.com> Message-ID: <1283850213.16375.494.camel@macbook> On Sun, 2010-09-05 at 00:00 -0700, John Rose wrote: > The JVM changes for 6964498 were pushed 7 weeks ago. Here are the > associated JDK changes: > > http://cr.openjdk.java.net/~jrose/6964498/jdk-webrev.01 src/share/classes/java/dyn/CallSite.java: 39 * operations are attempted), the call site msut be linked to Typo. src/share/classes/java/dyn/package-info.java: 203 * After resolution, the linkage process mail fail in a variety of ways. Typo. src/share/classes/java/dyn/Dependency.java: 41 /** Make a new, unique dependency which has no relation to any class. 42 * The string is used solely by the {@code toString} method, but should be 43 * something that conveys the purpose of this dependency. 44 */ Hmm. Dependency extends Object and I don't see a toString method. Otherwise looks good. -- Christian From christian.thalinger at oracle.com Tue Sep 7 02:43:56 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 07 Sep 2010 11:43:56 +0200 Subject: Request for review (M): 6980096: JSR 292 reflective lookup should throw checked exceptions In-Reply-To: <55E59039-DA4B-410E-A38F-979E47175369@oracle.com> References: <55E59039-DA4B-410E-A38F-979E47175369@oracle.com> Message-ID: <1283852636.16375.532.camel@macbook> On Sun, 2010-09-05 at 00:01 -0700, John Rose wrote: > This one changes method handle lookups to throw checked exceptions: > > http://cr.openjdk.java.net/~jrose/6980096/webrev.00/ src/share/classes/java/dyn/MethodHandles.java: 167 * The class implies a maximum level of access permission, 168 * but the permissions may be additionally limited by the bitmask 169 * {@ #lookupModes}, which controls whether 170 */ It seems there is some text missing. Otherwise looks good. -- Christian From christian.thalinger at oracle.com Tue Sep 7 02:50:24 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 07 Sep 2010 11:50:24 +0200 Subject: Request for review (S): 6953246: JSR 292 should support SAM conversion In-Reply-To: <5C3F9187-F3D4-4681-97BE-A8D669FBCCD3@oracle.com> References: <5C3F9187-F3D4-4681-97BE-A8D669FBCCD3@oracle.com> Message-ID: <1283853024.16375.539.camel@macbook> On Sun, 2010-09-05 at 00:04 -0700, John Rose wrote: > One important API point in MethodHandles: A SAM constructor for method handles. > > http://cr.openjdk.java.net/~jrose/6953246/webrev.00/ Looks good. -- Christian From tom.rodriguez at oracle.com Tue Sep 7 10:32:37 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 7 Sep 2010 10:32:37 -0700 Subject: review (XS) for 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled Message-ID: <7E3DA3E0-5B25-4A56-8CE3-64098D99015C@oracle.com> http://cr.openjdk.java.net/~never/6982533 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled Reviewed-by: The logic for matching a byte fill is missing a check for the use of the index. It normally happens as part of the check for a shift expression but since a byte array doesn't have a shift the check is missed. The fix is to make the index check explicit. The reason it didn't always crash was because of differences in heap size caused by ergonomics. With a 16m heap it crashes on any machine. Tested with failing test case. src/share/vm/opto/loopTransform.cpp From vladimir.kozlov at oracle.com Tue Sep 7 10:49:51 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 07 Sep 2010 10:49:51 -0700 Subject: review (XS) for 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled In-Reply-To: <7E3DA3E0-5B25-4A56-8CE3-64098D99015C@oracle.com> References: <7E3DA3E0-5B25-4A56-8CE3-64098D99015C@oracle.com> Message-ID: <4C867B3F.8020006@oracle.com> Looks good but could we also check (in assert?) that address type is array pointer? Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6982533 > > 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled > Reviewed-by: > > The logic for matching a byte fill is missing a check for the use of > the index. It normally happens as part of the check for a shift > expression but since a byte array doesn't have a shift the check is > missed. The fix is to make the index check explicit. The reason it > didn't always crash was because of differences in heap size caused by > ergonomics. With a 16m heap it crashes on any machine. Tested with > failing test case. > > src/share/vm/opto/loopTransform.cpp From tom.rodriguez at oracle.com Tue Sep 7 11:05:05 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 7 Sep 2010 11:05:05 -0700 Subject: review (XS) for 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled In-Reply-To: <4C867B3F.8020006@oracle.com> References: <7E3DA3E0-5B25-4A56-8CE3-64098D99015C@oracle.com> <4C867B3F.8020006@oracle.com> Message-ID: <9646089D-098D-41CB-82FB-205D492B6B1D@oracle.com> On Sep 7, 2010, at 10:49 AM, Vladimir Kozlov wrote: > Looks good but could we also check (in assert?) that address type is array pointer? I considered adding that as an early check but I wanted an explicit check that we found the index to confirm the shape of the address expression. I could add an early weed out test: --- a/src/share/vm/opto/loopTransform.cpp Fri Sep 03 13:31:03 2010 -0700 +++ b/src/share/vm/opto/loopTransform.cpp Tue Sep 07 11:04:07 2010 -0700 @@ -2417,6 +2417,8 @@ bool PhaseIdealLoop::match_fill_loop(Ide Node* value = n->in(MemNode::ValueIn); if (!lpt->is_invariant(value)) { msg = "variant store value"; + } else if (!_igvn.type(n->in(MemNode::Address))->isa_aryptr()) { + msg = "not array address"; } store = n; store_value = value; tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6982533 >> 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled >> Reviewed-by: >> The logic for matching a byte fill is missing a check for the use of >> the index. It normally happens as part of the check for a shift >> expression but since a byte array doesn't have a shift the check is >> missed. The fix is to make the index check explicit. The reason it >> didn't always crash was because of differences in heap size caused by >> ergonomics. With a 16m heap it crashes on any machine. Tested with >> failing test case. >> src/share/vm/opto/loopTransform.cpp From vladimir.kozlov at oracle.com Tue Sep 7 11:22:11 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 07 Sep 2010 11:22:11 -0700 Subject: review (XS) for 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled In-Reply-To: <9646089D-098D-41CB-82FB-205D492B6B1D@oracle.com> References: <7E3DA3E0-5B25-4A56-8CE3-64098D99015C@oracle.com> <4C867B3F.8020006@oracle.com> <9646089D-098D-41CB-82FB-205D492B6B1D@oracle.com> Message-ID: <4C8682D3.9020606@oracle.com> Tom, I am fine with your index explicit check, I only want an additional check for array ptr and your suggestion is good. Your current changes look good. Thanks, Vladimir Tom Rodriguez wrote: > On Sep 7, 2010, at 10:49 AM, Vladimir Kozlov wrote: > >> Looks good but could we also check (in assert?) that address type is array pointer? > > I considered adding that as an early check but I wanted an explicit check that we found the index to confirm the shape of the address expression. I could add an early weed out test: > > --- a/src/share/vm/opto/loopTransform.cpp Fri Sep 03 13:31:03 2010 -0700 > +++ b/src/share/vm/opto/loopTransform.cpp Tue Sep 07 11:04:07 2010 -0700 > @@ -2417,6 +2417,8 @@ bool PhaseIdealLoop::match_fill_loop(Ide > Node* value = n->in(MemNode::ValueIn); > if (!lpt->is_invariant(value)) { > msg = "variant store value"; > + } else if (!_igvn.type(n->in(MemNode::Address))->isa_aryptr()) { > + msg = "not array address"; > } > store = n; > store_value = value; > > tom > >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6982533 >>> 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled >>> Reviewed-by: >>> The logic for matching a byte fill is missing a check for the use of >>> the index. It normally happens as part of the check for a shift >>> expression but since a byte array doesn't have a shift the check is >>> missed. The fix is to make the index check explicit. The reason it >>> didn't always crash was because of differences in heap size caused by >>> ergonomics. With a 16m heap it crashes on any machine. Tested with >>> failing test case. >>> src/share/vm/opto/loopTransform.cpp > From tom.rodriguez at oracle.com Tue Sep 7 11:24:45 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 7 Sep 2010 11:24:45 -0700 Subject: review (XS) for 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled In-Reply-To: <4C8682D3.9020606@oracle.com> References: <7E3DA3E0-5B25-4A56-8CE3-64098D99015C@oracle.com> <4C867B3F.8020006@oracle.com> <9646089D-098D-41CB-82FB-205D492B6B1D@oracle.com> <4C8682D3.9020606@oracle.com> Message-ID: <840E78DA-A8AF-4C84-9DFE-A2C42A2C3829@oracle.com> On Sep 7, 2010, at 11:22 AM, Vladimir Kozlov wrote: > Tom, > > I am fine with your index explicit check, I only want an additional check for array ptr and your suggestion is good. Thanks! tom > > Your current changes look good. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Sep 7, 2010, at 10:49 AM, Vladimir Kozlov wrote: >>> Looks good but could we also check (in assert?) that address type is array pointer? >> I considered adding that as an early check but I wanted an explicit check that we found the index to confirm the shape of the address expression. I could add an early weed out test: >> --- a/src/share/vm/opto/loopTransform.cpp Fri Sep 03 13:31:03 2010 -0700 +++ b/src/share/vm/opto/loopTransform.cpp Tue Sep 07 11:04:07 2010 -0700 @@ -2417,6 +2417,8 @@ bool PhaseIdealLoop::match_fill_loop(Ide >> Node* value = n->in(MemNode::ValueIn); if (!lpt->is_invariant(value)) { msg = "variant store value"; + } else if (!_igvn.type(n->in(MemNode::Address))->isa_aryptr()) { + msg = "not array address"; } store = n; store_value = value; tom >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6982533 >>>> 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled >>>> Reviewed-by: >>>> The logic for matching a byte fill is missing a check for the use of >>>> the index. It normally happens as part of the check for a shift >>>> expression but since a byte array doesn't have a shift the check is >>>> missed. The fix is to make the index check explicit. The reason it >>>> didn't always crash was because of differences in heap size caused by >>>> ergonomics. With a 16m heap it crashes on any machine. Tested with >>>> failing test case. >>>> src/share/vm/opto/loopTransform.cpp From igor.veresov at oracle.com Tue Sep 7 12:49:54 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 07 Sep 2010 12:49:54 -0700 Subject: Request for review(XXS): 6982921: assert(_entry_bci != InvocationEntryBci) failed: wrong kind of nmethod Message-ID: <4C869762.1080509@oracle.com> Assertion fails during print compilation because nmethod::print_on() calls osr_entry_bci() without checking that the method is an osr method. The fix adds an appropriate check. Webrev: http://cr.openjdk.java.net/~iveresov/6982921/webrev.00/ Thanks, igor From tom.rodriguez at oracle.com Tue Sep 7 12:52:18 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 7 Sep 2010 12:52:18 -0700 Subject: Request for review(XXS): 6982921: assert(_entry_bci != InvocationEntryBci) failed: wrong kind of nmethod In-Reply-To: <4C869762.1080509@oracle.com> References: <4C869762.1080509@oracle.com> Message-ID: Looks good. tom On Sep 7, 2010, at 12:49 PM, Igor Veresov wrote: > Assertion fails during print compilation because nmethod::print_on() calls osr_entry_bci() without checking that the method is an osr method. > The fix adds an appropriate check. > > > Webrev: http://cr.openjdk.java.net/~iveresov/6982921/webrev.00/ > > > Thanks, > igor From christian.thalinger at Oracle.com Tue Sep 7 13:01:00 2010 From: christian.thalinger at Oracle.com (Christian Thalinger) Date: Tue, 07 Sep 2010 22:01:00 +0200 Subject: Request for review(XXS): 6982921: assert(_entry_bci != InvocationEntryBci) failed: wrong kind of nmethod In-Reply-To: <4C869762.1080509@oracle.com> References: <4C869762.1080509@oracle.com> Message-ID: <1283889660.24114.4.camel@macbook> On Tue, 2010-09-07 at 12:49 -0700, Igor Veresov wrote: > Assertion fails during print compilation because nmethod::print_on() > calls osr_entry_bci() without checking that the method is an osr method. > The fix adds an appropriate check. > > > Webrev: http://cr.openjdk.java.net/~iveresov/6982921/webrev.00/ Looks good. I wonder why I never hit that assert before. -- Christian From john.r.rose at oracle.com Tue Sep 7 14:17:01 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 7 Sep 2010 14:17:01 -0700 Subject: Request for review (L): 6964498: JSR 292 invokedynamic sites need local bootstrap methods In-Reply-To: <1283850213.16375.494.camel@macbook> References: <3A3A79AC-377C-429F-A08D-3327AC851C37@oracle.com> <1283850213.16375.494.camel@macbook> Message-ID: <09C404C5-7C68-4582-93F9-1298B9FA3B60@oracle.com> On Sep 7, 2010, at 2:03 AM, Christian Thalinger wrote: > On Sun, 2010-09-05 at 00:00 -0700, John Rose wrote: >> The JVM changes for 6964498 were pushed 7 weeks ago. Here are the >> associated JDK changes: >> >> http://cr.openjdk.java.net/~jrose/6964498/jdk-webrev.01 > > src/share/classes/java/dyn/CallSite.java: > > 39 * operations are attempted), the call site msut be linked to > > Typo. > > src/share/classes/java/dyn/package-info.java: > > 203 * After resolution, the linkage process mail fail in a variety of ways. > > Typo. Thanks; fixed. > src/share/classes/java/dyn/Dependency.java: > > 41 /** Make a new, unique dependency which has no relation to any class. > 42 * The string is used solely by the {@code toString} method, but should be > 43 * something that conveys the purpose of this dependency. > 44 */ > > Hmm. Dependency extends Object and I don't see a toString method. Thanks. I moved the dependency stuff into its own webrev; review request forthcoming. BTW, this is Reference Implementation work in parallel with the EG discussions. As the EG discussions converge there will of course be more adjustments. I have filed an omnibus bug to handle a round of miscellaneous changes: 6981777 implement JSR 292 EG adjustments from summer 2010. The current series of reviews is grouped by functional feature. -- John From john.r.rose at oracle.com Tue Sep 7 14:27:40 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 7 Sep 2010 14:27:40 -0700 Subject: Request for review (M): 6980096: JSR 292 reflective lookup should throw checked exceptions In-Reply-To: <1283852636.16375.532.camel@macbook> References: <55E59039-DA4B-410E-A38F-979E47175369@oracle.com> <1283852636.16375.532.camel@macbook> Message-ID: <323ED0B7-623E-46D7-9CF6-F78A0B34BBE0@oracle.com> On Sep 7, 2010, at 2:43 AM, Christian Thalinger wrote: > On Sun, 2010-09-05 at 00:01 -0700, John Rose wrote: >> This one changes method handle lookups to throw checked exceptions: >> >> http://cr.openjdk.java.net/~jrose/6980096/webrev.00/ > > src/share/classes/java/dyn/MethodHandles.java: > > 167 * The class implies a maximum level of access permission, > 168 * but the permissions may be additionally limited by the bitmask > 169 * {@ #lookupModes}, which controls whether > 170 */ > > It seems there is some text missing. Thanks for catching that. * {@link #lookupModes}, which controls whether non-public members * can be accessed. -- John From cnutter at engineyard.com Tue Sep 7 14:35:33 2010 From: cnutter at engineyard.com (Charles Nutter) Date: Tue, 7 Sep 2010 21:35:33 +0000 Subject: Static method market not entrant? Message-ID: I've been working on JRuby performance lately and ran into a peculiar situation. I have a static utility method in JRuby that checks whether a given object's class is the same as the when the compiler optimized it. So for a snippit of code like this: def foo bar end def bar # whatever end After running for some time, the "foo" call will be compiled, the compiler will see that the "bar" call has a cached method handle, and it will emit both a dynamic call and a static-typed call plus guard. The static-typed call looks like this: ALOAD 8 LDC 446 INVOKESTATIC org/jruby/javasupport/util/RuntimeHelpers.isGenerationEqual (Lorg/jruby/runtime/builtin/IRubyObject;I)Z IFNE L2 ALOAD 8 CHECKCAST org/jruby/RubyFixnum ALOAD 1 LDC 1 INVOKEVIRTUAL org/jruby/RubyFixnum.op_plus (Lorg/jruby/runtime/ThreadContext;J)Lorg/jruby/runtime/builtin/IRubyObject; And the isGenerationEqual method looks like this: public static boolean isGenerationEqual(IRubyObject object, int generation) { return object.getMetaClass().getCacheToken() == generation; } While running benchmarks, I noticed a peculiar thing happening. For "fib", the method JITs in JRuby very quickly and is soon after JITed by Hotspot. But later compiles cause "fib" to get deoptimized and marked not-entrant. Around the same time, isGenerationEqual gets marked not entrant. Unfortunately, when fib re-optimizes, it does so without inlining the isGenerationEqual call, and I can see that where it was inlined before, it now actually does a CALL in assembly. Manually inlining the same bytecode everywhere isGenerationEqual would be called does not seem to be subject to the same effect. Any thoughts? The only theory I have is that early in optimization Hotspot sees that the target object type (IRubyObject object in the method def) is the same, and so it optimizes based on that. Later, as other compiled methods start to hit this code, the tyoe of "object" changes. But the logic behind the scenes should be identical in every case... IRubyObject.getMetaClass() only has one final implementation on org.jruby.RubyBasicObject, and getCacheToken() has only one final implementation on org.jruby.RubyModule, which simply returns an int field. So I'm stumped why at least isGenerationEqual would not inline in all cases. - Charlie From headius at headius.com Tue Sep 7 14:44:29 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 7 Sep 2010 21:44:29 +0000 Subject: Small static method marked not entrant, inlining reversed? Message-ID: I've been working on JRuby performance lately and ran into a peculiar situation. I have a static utility method in JRuby that checks whether a given object's class is the same as the when the compiler optimized it. So for a snippit of code like this: def foo bar end def bar # whatever end After running for some time, the "foo" call will be compiled, the compiler will see that the "bar" call has a cached method handle, and it will emit both a dynamic call and a static-typed call plus guard. The static-typed call looks like this: ALOAD 8 LDC 446 INVOKESTATIC org/jruby/javasupport/util/RuntimeHelpers.isGenerationEqual (Lorg/jruby/runtime/builtin/IRubyObject;I)Z IFNE L2 ALOAD 8 CHECKCAST org/jruby/RubyFixnum ALOAD 1 LDC 1 INVOKEVIRTUAL org/jruby/RubyFixnum.op_plus (Lorg/jruby/runtime/ThreadContext;J)Lorg/jruby/runtime/builtin/IRubyObject; And the isGenerationEqual method looks like this: public static boolean isGenerationEqual(IRubyObject object, int generation) { return object.getMetaClass().getCacheToken() == generation; } While running benchmarks, I noticed a peculiar thing happening. For "fib", the method JITs in JRuby very quickly and is soon after JITed by Hotspot. But later compiles cause "fib" to get deoptimized and marked not-entrant. Around the same time, isGenerationEqual gets marked not entrant. Unfortunately, when fib re-optimizes, it does so without inlining the isGenerationEqual call, and I can see that where it was inlined before, it now actually does a CALL in assembly. Manually inlining the same bytecode everywhere isGenerationEqual would be called does not seem to be subject to the same effect. Any thoughts? The only theory I have is that early in optimization Hotspot sees that the target object type (IRubyObject object in the method def) is the same, and so it optimizes based on that. Later, as other compiled methods start to hit this code, the tyoe of "object" changes. But the logic behind the scenes should be identical in every case... IRubyObject.getMetaClass() only has one final implementation on org.jruby.RubyBasicObject, and getCacheToken() has only one final implementation on org.jruby.RubyModule, which simply returns an int field. So I'm stumped why at least isGenerationEqual would not inline in all cases. - Charlie From tom.rodriguez at oracle.com Tue Sep 7 17:04:43 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 7 Sep 2010 17:04:43 -0700 Subject: Small static method marked not entrant, inlining reversed? In-Reply-To: References: Message-ID: <18A6B79F-F944-46CD-8D98-B65E6C32C2D1@oracle.com> Did you run with -XX:+PrintInlining? That will report why we didn't inline. tom On Sep 7, 2010, at 2:44 PM, Charles Oliver Nutter wrote: > I've been working on JRuby performance lately and ran into a peculiar situation. > > I have a static utility method in JRuby that checks whether a given > object's class is the same as the when the compiler optimized it. So > for a snippit of code like this: > > def foo > bar > end > > def bar > # whatever > end > > After running for some time, the "foo" call will be compiled, the > compiler will see that the "bar" call has a cached method handle, and > it will emit both a dynamic call and a static-typed call plus guard. > The static-typed call looks like this: > > ALOAD 8 > LDC 446 > INVOKESTATIC > org/jruby/javasupport/util/RuntimeHelpers.isGenerationEqual > (Lorg/jruby/runtime/builtin/IRubyObject;I)Z > IFNE L2 > ALOAD 8 > CHECKCAST org/jruby/RubyFixnum > ALOAD 1 > LDC 1 > INVOKEVIRTUAL org/jruby/RubyFixnum.op_plus > (Lorg/jruby/runtime/ThreadContext;J)Lorg/jruby/runtime/builtin/IRubyObject; > > And the isGenerationEqual method looks like this: > > public static boolean isGenerationEqual(IRubyObject object, int > generation) { > return object.getMetaClass().getCacheToken() == generation; > } > > While running benchmarks, I noticed a peculiar thing happening. For > "fib", the method JITs in JRuby very quickly and is soon after JITed > by Hotspot. But later compiles cause "fib" to get deoptimized and > marked not-entrant. Around the same time, isGenerationEqual gets > marked not entrant. Unfortunately, when fib re-optimizes, it does so > without inlining the isGenerationEqual call, and I can see that where > it was inlined before, it now actually does a CALL in assembly. > > Manually inlining the same bytecode everywhere isGenerationEqual would > be called does not seem to be subject to the same effect. > > Any thoughts? The only theory I have is that early in optimization > Hotspot sees that the target object type (IRubyObject object in the > method def) is the same, and so it optimizes based on that. Later, as > other compiled methods start to hit this code, the tyoe of "object" > changes. But the logic behind the scenes should be identical in every > case... IRubyObject.getMetaClass() only has one final implementation > on org.jruby.RubyBasicObject, and getCacheToken() has only one final > implementation on org.jruby.RubyModule, which simply returns an int > field. > > So I'm stumped why at least isGenerationEqual would not inline in all cases. > > - Charlie From igor.veresov at oracle.com Tue Sep 7 17:11:13 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 08 Sep 2010 00:11:13 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6982921: assert(_entry_bci != InvocationEntryBci) failed: wrong kind of nmethod Message-ID: <20100908001114.E6522477C0@hg.openjdk.java.net> Changeset: ac4f710073ed Author: iveresov Date: 2010-09-07 14:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ac4f710073ed 6982921: assert(_entry_bci != InvocationEntryBci) failed: wrong kind of nmethod Summary: Assertion fails during print compilation because nmethod::print_on() calls osr_entry_bci() without checking that the method is an osr method. The fix adds an appropriate check. Reviewed-by: never, twisti ! src/share/vm/code/nmethod.cpp From headius at headius.com Tue Sep 7 23:34:10 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 8 Sep 2010 06:34:10 +0000 Subject: Small static method marked not entrant, inlining reversed? In-Reply-To: <18A6B79F-F944-46CD-8D98-B65E6C32C2D1@oracle.com> References: <18A6B79F-F944-46CD-8D98-B65E6C32C2D1@oracle.com> Message-ID: I'll give that a shot, Tom, thanks. Should have thought of it myself. On Wed, Sep 8, 2010 at 12:04 AM, Tom Rodriguez wrote: > Did you run with -XX:+PrintInlining? ?That will report why we didn't inline. > > tom > > On Sep 7, 2010, at 2:44 PM, Charles Oliver Nutter wrote: > >> I've been working on JRuby performance lately and ran into a peculiar situation. >> >> I have a static utility method in JRuby that checks whether a given >> object's class is the same as the when the compiler optimized it. So >> for a snippit of code like this: >> >> def foo >> ?bar >> end >> >> def bar >> ?# whatever >> end >> >> After running for some time, the "foo" call will be compiled, the >> compiler will see that the "bar" call has a cached method handle, and >> it will emit both a dynamic call and a static-typed call plus guard. >> The static-typed call looks like this: >> >> ? ?ALOAD 8 >> ? ?LDC 446 >> ? ?INVOKESTATIC >> org/jruby/javasupport/util/RuntimeHelpers.isGenerationEqual >> (Lorg/jruby/runtime/builtin/IRubyObject;I)Z >> ? ?IFNE L2 >> ? ?ALOAD 8 >> ? ?CHECKCAST org/jruby/RubyFixnum >> ? ?ALOAD 1 >> ? ?LDC 1 >> ? ?INVOKEVIRTUAL org/jruby/RubyFixnum.op_plus >> (Lorg/jruby/runtime/ThreadContext;J)Lorg/jruby/runtime/builtin/IRubyObject; >> >> And the isGenerationEqual method looks like this: >> >> ? ?public static boolean isGenerationEqual(IRubyObject object, int >> generation) { >> ? ? ? ?return object.getMetaClass().getCacheToken() == generation; >> ? ?} >> >> While running benchmarks, I noticed a peculiar thing happening. For >> "fib", the method JITs in JRuby very quickly and is soon after JITed >> by Hotspot. But later compiles cause "fib" to get deoptimized and >> marked not-entrant. Around the same time, isGenerationEqual gets >> marked not entrant. Unfortunately, when fib re-optimizes, it does so >> without inlining the isGenerationEqual call, and I can see that where >> it was inlined before, it now actually does a CALL in assembly. >> >> Manually inlining the same bytecode everywhere isGenerationEqual would >> be called does not seem to be subject to the same effect. >> >> Any thoughts? The only theory I have is that early in optimization >> Hotspot sees that the target object type (IRubyObject object in the >> method def) is the same, and so it optimizes based on that. Later, as >> other compiled methods start to hit this code, the tyoe of "object" >> changes. But the logic behind the scenes should be identical in every >> case... IRubyObject.getMetaClass() only has one final implementation >> on org.jruby.RubyBasicObject, and getCacheToken() has only one final >> implementation on org.jruby.RubyModule, which simply returns an int >> field. >> >> So I'm stumped why at least isGenerationEqual would not inline in all cases. >> >> - Charlie > > From headius at headius.com Wed Sep 8 00:03:10 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 8 Sep 2010 07:03:10 +0000 Subject: Small static method marked not entrant, inlining reversed? In-Reply-To: References: <18A6B79F-F944-46CD-8D98-B65E6C32C2D1@oracle.com> Message-ID: Ok, I have some additional evidence. The __file__ method that contains the jitted code body is jitted by hotspot initially and things I expected to inline inline correctly. 31 ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ (442 bytes) Later another recompilation forces __file__ to be recompiled...it's around the 50th iteration of the benchmark, at which point all the benchmark library's code is jitted by JRuby. 31 make_not_entrant Immediately after this, it appears that calls to isGenerationEqual are detected to be bimorphic, and so hotspot considers recompiling them as well. 25 uncommon trap bimorphic maybe_recompile @1 org/jruby/javasupport/util/RuntimeHelpers isGenerationEqual (Lorg/jruby/runtime/builtin/IRubyObject;I)Z A type profile inside the isGenerationEqual call site looks like this in both the before and after case @ 62 org.jruby.javasupport.util.RuntimeHelpers::isGenerationEqual (19 bytes) @ 1 org.jruby.runtime.builtin.IRubyObject::getMetaClass (0 bytes) type profile org/jruby/runtime/builtin/IRubyObject -> org/jruby/RubyFixnum (71%) ...but it does appear to inline according to this output :( All occurrences of isGenerationEqual in the PrintInlining output are inlined. So why do I see CALLs in the assembly? More information: The recursive calls to the method appear to never inline, probably because the method body is too large based on this logging output. It's not ideal, since in Ruby terms this is a pretty small method...but I guess I'm stuck here: @ 115 ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ hot method too big I remember tweaking various flags and getting "fib" to inline multiple levels deep, but I generally had to bump up several flags (MaxInlineSize, InlineSmallCode, MaxInlineLevel, and even a "max node count" flag I dug out of the Hotspot sources). Here's part of the PrintAssembly showing the calls to isGenerationEqual: (type checks to see which of the two bimorphic targets it's seeing) 0x028614bd: cmp ecx, 'org/jruby/RubyFixnum' ; {oop('org/jruby/RubyFixnum')} 0x028614c3: jz 0x028614da 0x028614c5: cmp ecx, 'org/jruby/RubyObject' ; {oop('org/jruby/RubyObject')} 0x028614cb: jnz 0x02861b55 (the RubyFixnum branch with all of isGenerationEqual and its component calls inlined) 0x028614da: mov ebp, [ebx+0xC] ;*synchronization entry ; - org.jruby.javasupport.util.RuntimeHelpers::isGenerationEqual at -1 (line 1863) ; - ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 11 (line 4) 0x028614dd: mov ebx, [ebp+0x18] ; implicit exception: dispatches to 0x028620ed 0x028614e0: cmp ebx, 0x000001f3 0x028614e6: jz 0x02861b11 ;*if_icmpne ; - org.jruby.javasupport.util.RuntimeHelpers::isGenerationEqual at 10 (line 1863) ; - ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 11 (line 4) (subsequent casting to RubyFixnum and direct invocation of op_lt, the Java implementation of Fixnum#<) 0x028614ec: cmp ecx, 'org/jruby/RubyFixnum' ; {oop('org/jruby/RubyFixnum')} 0x028614f2: jnz 0x02862081 ;*checkcast ; - ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 19 (line 4) 0x028614f8: mov ebx, [edx+0x28] ;*getfield runtime ; - org.jruby.runtime.ThreadContext::getRuntime at 1 (line 147) ; - org.jruby.RubyFixnum::op_lt at 1 (line 888) ; - ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 26 (line 4) ; implicit exception: dispatches to 0x028620fd And the same sequence in the second compilation of __file__: (Perhaps the problem here is actually getMetaClass()? It shows as inlining based on the type profile information in LogCompilation, so why wouldn't it be inlined here? There's a single, final implementation on RubyBasicObject that both RubyObject and RubyFixnum share.) 0x0286e4f6: mov ecx, [esp+0x44] 0x0286e4fa: mov eax, -1 ; {oop(NULL)} 0x0286e4ff: call 0x0282d2a0 ; OopMap{[64]=Oop [68]=Oop [16]=Oop [24]=Oop off=36} ;*invokeinterface getMetaClass ; - org.jruby.javasupport.util.RuntimeHelpers::isGenerationEqual at 1 (line 1863) ; - ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 11 (line 4) ; {virtual_call} 0x0286e504: mov ebx, [eax+0x18] ; implicit exception: dispatches to 0x0286efc9 0x0286e507: cmp ebx, 0x000001f3 0x0286e50d: jz 0x0286ea7f ;*if_icmpne ; - org.jruby.javasupport.util.RuntimeHelpers::isGenerationEqual at 10 (line 1863) ; - ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 11 (line 4) 0x0286e513: mov eax, [esp+0x44] 0x0286e517: mov ebx, [eax+0x4] ; implicit exception: dispatches to 0x0286efd9 0x0286e51a: mov [esp+0x44], ebx 0x0286e51e: cmp ebx, 'org/jruby/RubyFixnum' ; {oop('org/jruby/RubyFixnum')} 0x0286e524: jnz 0x0286ef5d ;*checkcast ; - ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 19 (line 4) So is it defeating the inlining of getMetaClass() that the IRubyObject passed in is of two different types, even though getMetaClass comes from their common superclass? In other words, if Hotspot encounters an invokeinterface with two different types with a shared hierarchy and a single implementation of that interface method...why does it fail to inline that method? It seems like a case against using invokeinterface if at all possible, even against a shared class hierarchy. - Charlie On Wed, Sep 8, 2010 at 6:34 AM, Charles Oliver Nutter wrote: > I'll give that a shot, Tom, thanks. Should have thought of it myself. > > On Wed, Sep 8, 2010 at 12:04 AM, Tom Rodriguez wrote: >> Did you run with -XX:+PrintInlining? ?That will report why we didn't inline. >> >> tom >> >> On Sep 7, 2010, at 2:44 PM, Charles Oliver Nutter wrote: >> >>> I've been working on JRuby performance lately and ran into a peculiar situation. >>> >>> I have a static utility method in JRuby that checks whether a given >>> object's class is the same as the when the compiler optimized it. So >>> for a snippit of code like this: >>> >>> def foo >>> ?bar >>> end >>> >>> def bar >>> ?# whatever >>> end >>> >>> After running for some time, the "foo" call will be compiled, the >>> compiler will see that the "bar" call has a cached method handle, and >>> it will emit both a dynamic call and a static-typed call plus guard. >>> The static-typed call looks like this: >>> >>> ? ?ALOAD 8 >>> ? ?LDC 446 >>> ? ?INVOKESTATIC >>> org/jruby/javasupport/util/RuntimeHelpers.isGenerationEqual >>> (Lorg/jruby/runtime/builtin/IRubyObject;I)Z >>> ? ?IFNE L2 >>> ? ?ALOAD 8 >>> ? ?CHECKCAST org/jruby/RubyFixnum >>> ? ?ALOAD 1 >>> ? ?LDC 1 >>> ? ?INVOKEVIRTUAL org/jruby/RubyFixnum.op_plus >>> (Lorg/jruby/runtime/ThreadContext;J)Lorg/jruby/runtime/builtin/IRubyObject; >>> >>> And the isGenerationEqual method looks like this: >>> >>> ? ?public static boolean isGenerationEqual(IRubyObject object, int >>> generation) { >>> ? ? ? ?return object.getMetaClass().getCacheToken() == generation; >>> ? ?} >>> >>> While running benchmarks, I noticed a peculiar thing happening. For >>> "fib", the method JITs in JRuby very quickly and is soon after JITed >>> by Hotspot. But later compiles cause "fib" to get deoptimized and >>> marked not-entrant. Around the same time, isGenerationEqual gets >>> marked not entrant. Unfortunately, when fib re-optimizes, it does so >>> without inlining the isGenerationEqual call, and I can see that where >>> it was inlined before, it now actually does a CALL in assembly. >>> >>> Manually inlining the same bytecode everywhere isGenerationEqual would >>> be called does not seem to be subject to the same effect. >>> >>> Any thoughts? The only theory I have is that early in optimization >>> Hotspot sees that the target object type (IRubyObject object in the >>> method def) is the same, and so it optimizes based on that. Later, as >>> other compiled methods start to hit this code, the tyoe of "object" >>> changes. But the logic behind the scenes should be identical in every >>> case... IRubyObject.getMetaClass() only has one final implementation >>> on org.jruby.RubyBasicObject, and getCacheToken() has only one final >>> implementation on org.jruby.RubyModule, which simply returns an int >>> field. >>> >>> So I'm stumped why at least isGenerationEqual would not inline in all cases. >>> >>> - Charlie >> >> > From headius at headius.com Wed Sep 8 00:08:50 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 8 Sep 2010 07:08:50 +0000 Subject: Small static method marked not entrant, inlining reversed? In-Reply-To: References: <18A6B79F-F944-46CD-8D98-B65E6C32C2D1@oracle.com> Message-ID: Well, this is a frustrating discovery. Hotspot seems to have a lot of trouble with invokeinterface versus casting to a concrete type and using invokevirtual. Modifying isGenerationEqual to do this instead seems to avoid the deoptimization: public static boolean isGenerationEqual(IRubyObject object, int generation) { return ((RubyBasicObject)object).getMetaClass().getCacheToken() == generation; } There may be a future where an IRubyObject enters JRuby and does not extend RubyBasicObject, but for now this cast should succeed every time. But the same goes for the invokeinterface path, where both RubyObject and RubyFixnum inherit the same getMetaClass implementation from RubyBasicObject. Why is Hotspot able to cope with the cast+invokevirtual when it can't cope with invokeinterface always resolving to the same method? - Charlie On Wed, Sep 8, 2010 at 7:03 AM, Charles Oliver Nutter wrote: > Ok, I have some additional evidence. > > The __file__ method that contains the jitted code body is jitted by > hotspot initially and things I expected to inline inline correctly. > > 31 ? ?ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ > (442 bytes) > > Later another recompilation forces __file__ to be recompiled...it's > around the 50th iteration of the benchmark, at which point all the > benchmark library's code is jitted by JRuby. > > 31 make_not_entrant > > Immediately after this, it appears that calls to isGenerationEqual are > detected to be bimorphic, and so hotspot considers recompiling them as > well. > > 25 uncommon trap bimorphic maybe_recompile > ?@1 org/jruby/javasupport/util/RuntimeHelpers isGenerationEqual > (Lorg/jruby/runtime/builtin/IRubyObject;I)Z > > A type profile inside the isGenerationEqual call site looks like this > in both the before and after case > > ? ?@ 62 org.jruby.javasupport.util.RuntimeHelpers::isGenerationEqual (19 bytes) > ? ? ?@ 1 org.jruby.runtime.builtin.IRubyObject::getMetaClass (0 bytes) > ? ? ? type profile org/jruby/runtime/builtin/IRubyObject -> > org/jruby/RubyFixnum (71%) > > ...but it does appear to inline according to this output :( All > occurrences of isGenerationEqual in the PrintInlining output are > inlined. So why do I see CALLs in the assembly? > > More information: The recursive calls to the method appear to never > inline, probably because the method body is too large based on this > logging output. It's not ideal, since in Ruby terms this is a pretty > small method...but I guess I'm stuck here: > > ? ?@ 115 ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ > hot method too big > > I remember tweaking various flags and getting "fib" to inline multiple > levels deep, but I generally had to bump up several flags > (MaxInlineSize, InlineSmallCode, MaxInlineLevel, and even a "max node > count" flag I dug out of the Hotspot sources). > > Here's part of the PrintAssembly showing the calls to isGenerationEqual: > > (type checks to see which of the two bimorphic targets it's seeing) > ?0x028614bd: cmp ? ? ? ecx, 'org/jruby/RubyFixnum' > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {oop('org/jruby/RubyFixnum')} > ?0x028614c3: jz ? ? ? ?0x028614da > ?0x028614c5: cmp ? ? ? ecx, 'org/jruby/RubyObject' > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {oop('org/jruby/RubyObject')} > ?0x028614cb: jnz ? ? ? 0x02861b55 > > (the RubyFixnum branch with all of isGenerationEqual and its component > calls inlined) > ?0x028614da: mov ? ? ? ebp, [ebx+0xC] ?;*synchronization entry > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > org.jruby.javasupport.util.RuntimeHelpers::isGenerationEqual at -1 (line > 1863) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 11 > (line 4) > ?0x028614dd: mov ? ? ? ebx, [ebp+0x18] ?; implicit exception: dispatches to > 0x028620ed > ?0x028614e0: cmp ? ? ? ebx, 0x000001f3 > ?0x028614e6: jz ? ? ? ?0x02861b11 ? ? ?;*if_icmpne > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > org.jruby.javasupport.util.RuntimeHelpers::isGenerationEqual at 10 (line > 1863) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 11 > (line 4) > > (subsequent casting to RubyFixnum and direct invocation of op_lt, the > Java implementation of Fixnum#<) > ?0x028614ec: cmp ? ? ? ecx, 'org/jruby/RubyFixnum' > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {oop('org/jruby/RubyFixnum')} > ?0x028614f2: jnz ? ? ? 0x02862081 ? ? ?;*checkcast > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 19 > (line 4) > ?0x028614f8: mov ? ? ? ebx, [edx+0x28] ?;*getfield runtime > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > org.jruby.runtime.ThreadContext::getRuntime at 1 (line 147) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > org.jruby.RubyFixnum::op_lt at 1 (line 888) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 26 > (line 4) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; implicit exception: > dispatches to 0x028620fd > > And the same sequence in the second compilation of __file__: > > (Perhaps the problem here is actually getMetaClass()? It shows as > inlining based on the type profile information in LogCompilation, so > why wouldn't it be inlined here? There's a single, final > implementation on RubyBasicObject that both RubyObject and RubyFixnum > share.) > ?0x0286e4f6: mov ? ? ? ecx, [esp+0x44] > ?0x0286e4fa: mov ? ? ? eax, -1 ? ? ? ? ; ? {oop(NULL)} > ?0x0286e4ff: call ? ? ?0x0282d2a0 ? ? ?; OopMap{[64]=Oop [68]=Oop [16]=Oop > [24]=Oop off=36} > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?;*invokeinterface getMetaClass > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > org.jruby.javasupport.util.RuntimeHelpers::isGenerationEqual at 1 (line > 1863) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 11 > (line 4) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {virtual_call} > ?0x0286e504: mov ? ? ? ebx, [eax+0x18] ?; implicit exception: dispatches to > 0x0286efc9 > ?0x0286e507: cmp ? ? ? ebx, 0x000001f3 > ?0x0286e50d: jz ? ? ? ?0x0286ea7f ? ? ?;*if_icmpne > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > org.jruby.javasupport.util.RuntimeHelpers::isGenerationEqual at 10 (line > 1863) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 11 > (line 4) > ?0x0286e513: mov ? ? ? eax, [esp+0x44] > ?0x0286e517: mov ? ? ? ebx, [eax+0x4] ?; implicit exception: dispatches to 0x0286efd9 > ?0x0286e51a: mov ? ? ? [esp+0x44], ebx > ?0x0286e51e: cmp ? ? ? ebx, 'org/jruby/RubyFixnum' > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; ? {oop('org/jruby/RubyFixnum')} > ?0x0286e524: jnz ? ? ? 0x0286ef5d ? ? ?;*checkcast > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?; - > ruby.jit.fib_ruby_5EC86D8D24F89CAF26F0CBEA2FBDA4ED21326951::__file__ at 19 > (line 4) > > So is it defeating the inlining of getMetaClass() that the IRubyObject > passed in is of two different types, even though getMetaClass comes > from their common superclass? In other words, if Hotspot encounters an > invokeinterface with two different types with a shared hierarchy and a > single implementation of that interface method...why does it fail to > inline that method? It seems like a case against using invokeinterface > if at all possible, even against a shared class hierarchy. > > - Charlie > > On Wed, Sep 8, 2010 at 6:34 AM, Charles Oliver Nutter > wrote: >> I'll give that a shot, Tom, thanks. Should have thought of it myself. >> >> On Wed, Sep 8, 2010 at 12:04 AM, Tom Rodriguez wrote: >>> Did you run with -XX:+PrintInlining? ?That will report why we didn't inline. >>> >>> tom >>> >>> On Sep 7, 2010, at 2:44 PM, Charles Oliver Nutter wrote: >>> >>>> I've been working on JRuby performance lately and ran into a peculiar situation. >>>> >>>> I have a static utility method in JRuby that checks whether a given >>>> object's class is the same as the when the compiler optimized it. So >>>> for a snippit of code like this: >>>> >>>> def foo >>>> ?bar >>>> end >>>> >>>> def bar >>>> ?# whatever >>>> end >>>> >>>> After running for some time, the "foo" call will be compiled, the >>>> compiler will see that the "bar" call has a cached method handle, and >>>> it will emit both a dynamic call and a static-typed call plus guard. >>>> The static-typed call looks like this: >>>> >>>> ? ?ALOAD 8 >>>> ? ?LDC 446 >>>> ? ?INVOKESTATIC >>>> org/jruby/javasupport/util/RuntimeHelpers.isGenerationEqual >>>> (Lorg/jruby/runtime/builtin/IRubyObject;I)Z >>>> ? ?IFNE L2 >>>> ? ?ALOAD 8 >>>> ? ?CHECKCAST org/jruby/RubyFixnum >>>> ? ?ALOAD 1 >>>> ? ?LDC 1 >>>> ? ?INVOKEVIRTUAL org/jruby/RubyFixnum.op_plus >>>> (Lorg/jruby/runtime/ThreadContext;J)Lorg/jruby/runtime/builtin/IRubyObject; >>>> >>>> And the isGenerationEqual method looks like this: >>>> >>>> ? ?public static boolean isGenerationEqual(IRubyObject object, int >>>> generation) { >>>> ? ? ? ?return object.getMetaClass().getCacheToken() == generation; >>>> ? ?} >>>> >>>> While running benchmarks, I noticed a peculiar thing happening. For >>>> "fib", the method JITs in JRuby very quickly and is soon after JITed >>>> by Hotspot. But later compiles cause "fib" to get deoptimized and >>>> marked not-entrant. Around the same time, isGenerationEqual gets >>>> marked not entrant. Unfortunately, when fib re-optimizes, it does so >>>> without inlining the isGenerationEqual call, and I can see that where >>>> it was inlined before, it now actually does a CALL in assembly. >>>> >>>> Manually inlining the same bytecode everywhere isGenerationEqual would >>>> be called does not seem to be subject to the same effect. >>>> >>>> Any thoughts? The only theory I have is that early in optimization >>>> Hotspot sees that the target object type (IRubyObject object in the >>>> method def) is the same, and so it optimizes based on that. Later, as >>>> other compiled methods start to hit this code, the tyoe of "object" >>>> changes. But the logic behind the scenes should be identical in every >>>> case... IRubyObject.getMetaClass() only has one final implementation >>>> on org.jruby.RubyBasicObject, and getCacheToken() has only one final >>>> implementation on org.jruby.RubyModule, which simply returns an int >>>> field. >>>> >>>> So I'm stumped why at least isGenerationEqual would not inline in all cases. >>>> >>>> - Charlie >>> >>> >> > From john.r.rose at oracle.com Wed Sep 8 00:10:33 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 8 Sep 2010 00:10:33 -0700 Subject: [jvm-l] Re: Small static method marked not entrant, inlining reversed? In-Reply-To: References: <18A6B79F-F944-46CD-8D98-B65E6C32C2D1@oracle.com> Message-ID: <51D5688C-4D91-47A3-9033-1F77B47060DC@oracle.com> On Sep 7, 2010, at 11:34 PM, Charles Oliver Nutter wrote: > I'll give that a shot, Tom, thanks. Should have thought of it myself. Also, to make the compiler really spill its guts, try +LogCompilation (google for the wiki page that discusses it). Your prejudice against "fat" bytecodes corresponds somewhat to the HotSpot inlining heuristics. HotSpot strongly prefers to inline small methods, and the algorithm has a non-linear side to it. Two cold methods of 30 bytecodes each are much more likely to get inlined than one method of 60 bytecodes. Likewise for a hot call to two methods of 300 bytecodes each. (Smoothing out these heuristics would be a great post-graduate thesis, IMO.) For an example of experimenting with the inlining heuristics see: http://blogs.sun.com/jrose/entry/an_experiment_with_generic_arithmetic http://blogs.sun.com/jrose/resource/jsr292/SumWithIndy.zip Any such use of the tuning flags must be regarded as purely experimental, but tuning experiments can lead to real improvements. -- John P.S One recent change (to type profiles, not inlining heuristics) was motivated by a performance tuning exercise similar to the present one: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b29a725c43c The improvement is to collect type profiles up at the 'if' instead of down at the cast in idioms like this: if (x instanceof C) ((C)x).somethingFast(); else MyRuntime.somethingSlow(x); With a successful type profile, this will be able to collapse like this: if (x.getClass() != C42.class) trap(); inline C42.somethingFast(x); HotSpot was already collecting type profiles at the cast and the invokevirtual, but not at the instanceof. From headius at headius.com Wed Sep 8 00:20:29 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 8 Sep 2010 07:20:29 +0000 Subject: [jvm-l] Re: Small static method marked not entrant, inlining reversed? In-Reply-To: <51D5688C-4D91-47A3-9033-1F77B47060DC@oracle.com> References: <18A6B79F-F944-46CD-8D98-B65E6C32C2D1@oracle.com> <51D5688C-4D91-47A3-9033-1F77B47060DC@oracle.com> Message-ID: On Wed, Sep 8, 2010 at 7:10 AM, John Rose wrote: > Also, to make the compiler really spill its guts, try +LogCompilation (google for the wiki page that discusses it). For whatever reaons, PrintInlining wouldn't show anything but intrinsics. Perhaps it's my build. I opted to use LogCompilation instead. > Your prejudice against "fat" bytecodes corresponds somewhat to the HotSpot inlining heuristics. ?HotSpot strongly prefers to inline small methods, and the algorithm has a non-linear side to it. ?Two cold methods of 30 bytecodes each are much more likely to get inlined than one method of 60 bytecodes. ? Likewise for a hot call to two methods of 300 bytecodes each. I do a periodic survey of LogCompilation output for key parts of JRuby (like the parser) to ensure we haven't grown any methods beyond various inlining budgets. You get the idea pretty quickly that Hotspot hates big method bodies... > For an example of experimenting with the inlining heuristics see: > ?http://blogs.sun.com/jrose/entry/an_experiment_with_generic_arithmetic > ?http://blogs.sun.com/jrose/resource/jsr292/SumWithIndy.zip > > Any such use of the tuning flags must be regarded as purely experimental, but tuning experiments can lead to real improvements. I'll give that another read. I feel like the logic I have in place for inserting direct static (typed) invocations to "hot" methods at a JRuby call site is a good step forward, but the bytecode size increase is a harsh mistress. Add to that this seeming problem with inlining a bimorphic invokeinterface (that's actually monomorphic from the base implementation) and you have a very frustrated JRuby compiler writer. > P.S One recent change (to type profiles, not inlining heuristics) was motivated by a performance tuning exercise similar to the present one: > ?http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b29a725c43c > > The improvement is to collect type profiles up at the 'if' instead of down at the cast in idioms like this: > ?if (x instanceof C) > ? ?((C)x).somethingFast(); > ?else > ? ?MyRuntime.somethingSlow(x); > > With a successful type profile, this will be able to collapse like this: > ?if (x.getClass() != C42.class) ?trap(); > ?inline C42.somethingFast(x); > > HotSpot was already collecting type profiles at the cast and the invokevirtual, but not at the instanceof. How about at an invokeinterface? It appears to collect type profiles, but for only resolving to the immediate types, and not the actual method-to-be-invoked or the common superclass of both that actually provides the implementation... At this point I'm also not above exploring C2, if it's possible to localize this case to something I can consume. I'll have a gander at your patches in the morning. - Charlie From john.r.rose at oracle.com Wed Sep 8 00:22:53 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 8 Sep 2010 00:22:53 -0700 Subject: [jvm-l] Re: Small static method marked not entrant, inlining reversed? In-Reply-To: References: <18A6B79F-F944-46CD-8D98-B65E6C32C2D1@oracle.com> Message-ID: <4BA99DCA-C49A-4162-A5DA-B73A15412139@oracle.com> On Sep 8, 2010, at 12:08 AM, Charles Oliver Nutter wrote: > Why is Hotspot able to cope with the > cast+invokevirtual when it can't cope with invokeinterface always > resolving to the same method? Here's a possible answer, which could lead to JVM tweaks or bug fixes: Class hierarchy analysis allows devirtualization of the call, but only if the receiver is a real class. The JVM keeps some records about implementors of interfaces, but I don't think the compiler connects all the dots properly. Note that if the call site is monomorphic then class hierarchy analysis doesn't apply at all, and calls are trivially devirtualized, since the receiver is an "exact" type (not quantified over a set of subtypes). This happens whether the receiver is a class or interface. But our current type profiles don't scale well beyond one or two exact types. So a test case for this theory would have to make a call site which witnesses multiple receiver types but where all the types resolve to a common method (and that method has a single definition within the set of the receiver's subtypes). And the set of subtypes would have to be bounded by an interface, not a class. -- John From john.r.rose at oracle.com Wed Sep 8 00:29:45 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 8 Sep 2010 00:29:45 -0700 Subject: [jvm-l] Re: Small static method marked not entrant, inlining reversed? In-Reply-To: References: <18A6B79F-F944-46CD-8D98-B65E6C32C2D1@oracle.com> <51D5688C-4D91-47A3-9033-1F77B47060DC@oracle.com> Message-ID: <08FEFA4F-6F71-4E88-9649-48D2FFD093BE@oracle.com> On Sep 8, 2010, at 12:20 AM, Charles Oliver Nutter wrote: > How about at an invokeinterface? It appears to collect type profiles, > but for only resolving to the immediate types, and not the actual > method-to-be-invoked or the common superclass of both that actually > provides the implementation... That's exactly right. Sounds like CHA (class hierarchy analysis) under interfaces would bail you out, at least until you created too many (>1 or >2) disjoint IRubyObject implementations. A related problem may be either (a) the type profile doesn't collect general-enough information or (b) we don't have enough type profile points to collect specific-enough information. We can fix (a) by collecting ever fancier profile information or (b) by splitting profile points during inlining in early tiers. (Or (c) use an explicitly controlled templating mechanism like anonymous classes. That may prematurely multiply bytecodes, though.) -- John From headius at headius.com Wed Sep 8 05:43:44 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 8 Sep 2010 12:43:44 +0000 Subject: [jvm-l] Re: Small static method marked not entrant, inlining reversed? In-Reply-To: <08FEFA4F-6F71-4E88-9649-48D2FFD093BE@oracle.com> References: <18A6B79F-F944-46CD-8D98-B65E6C32C2D1@oracle.com> <51D5688C-4D91-47A3-9033-1F77B47060DC@oracle.com> <08FEFA4F-6F71-4E88-9649-48D2FFD093BE@oracle.com> Message-ID: On Wed, Sep 8, 2010 at 2:29 AM, John Rose wrote: > That's exactly right. ?Sounds like CHA (class hierarchy analysis) under interfaces would bail you out, at least until you created too many (>1 or >2) disjoint IRubyObject implementations. Yes, it sounds like exactly what I want. I'm guessing this is a "nice to have but not currently being worked" sort of problem, but it seems like a very generally-applicable improvement to Hotspot, since it's probably common (this would be easy to measure) to have an invokeinterface that receives multiple types but those types' implementations of that interface mostly boil down to the same superclass. As far as I understand it, it would help any case where you've extended an existing type but pass it around via some superclass's interface. A simple analysis could be done quickly too: resolve the type profile to the actual implementer of the interface, rather than to the exact type. Since invokeinterface knows what interface it's looking for, it could do a quick hierarchy scan to find the class that first claims to implement it. Generally when extending a class that already implements an interface, you don't re-add "implements", so this would work in a high percentage of cases. Does the type profile at present support resolving to a superclass, or does it only support resolving to an object's exact class? > A related problem may be either (a) the type profile doesn't collect general-enough information or (b) we don't have enough type profile points to collect specific-enough information. ?We can fix (a) by collecting ever fancier profile information or (b) by splitting profile points during inlining in early tiers. (a) could be the "find real implementer" above as a short-term improvement, and later "find common superclass that implements the target signature". I assume the latter already works because the following also avoids the deopt I saw: public static boolean isGenerationEqual(IRubyObject object, int generation) { return ((RubyObject)object).getMetaClass().getCacheToken() == generation; } Presumably the type profile here is able to handle arbitrarily many subclasses of RubyObject. The above code really ought to optimize (at least in my case) the same as: public static boolean isGenerationEqual(IRubyObject object, int generation) { return object.getMetaClass().getCacheToken() == generation; } I would love to see that happen (and I'm willing to help, after the necessary C2 learning period!), but for now I'll have to make some hard decisions in the JRuby codebase and compiler :( > (Or (c) use an explicitly controlled templating mechanism like anonymous classes. ?That may prematurely multiply bytecodes, though.) By this you mean using a class template to specialize a piece of code to a common superclass *before* passing it to the optimizer? For what it's worth, the following code is only slightly slower than the fastest non-hacked implementation and not subject to the deoptimization: public static boolean isGenerationEqual(IRubyObject object, int generation) { RubyClass metaClass; if (object instanceof RubyBasicObject) { metaClass = ((RubyBasicObject)object).getMetaClass(); } else { metaClass = object.getMetaClass(); } return metaClass.getCacheToken() == generation; } But I may end up having the JRuby compiler do this since in order to do a direct (non-dynamic) call it has to cast to a concrete type anyway. - Charlie From john.coomes at oracle.com Wed Sep 8 15:38:48 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 08 Sep 2010 22:38:48 +0000 Subject: hg: jdk7/hotspot-comp: 9 new changesets Message-ID: <20100908223848.32CBC477FA@hg.openjdk.java.net> Changeset: 86a3df41c0c7 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/86a3df41c0c7 Added tag jdk7-b102 for changeset a136a51f5113 ! .hgtags Changeset: f1ba69da5003 Author: ohair Date: 2010-07-26 14:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/f1ba69da5003 6972274: Fix the use of egrep -ci in the top level makefile sanity checks Reviewed-by: prr ! make/sanity-rules.gmk Changeset: be2aedc4e3b1 Author: mikejwre Date: 2010-07-28 21:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/be2aedc4e3b1 Merge Changeset: f8be576feefc Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/f8be576feefc Added tag jdk7-b103 for changeset be2aedc4e3b1 ! .hgtags Changeset: 9f96a4269d77 Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/9f96a4269d77 Added tag jdk7-b104 for changeset f8be576feefc ! .hgtags Changeset: 43096cccf1ce Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/43096cccf1ce Added tag jdk7-b105 for changeset 9f96a4269d77 ! .hgtags Changeset: 7d396ad455c3 Author: cl Date: 2010-08-19 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/7d396ad455c3 Added tag jdk7-b106 for changeset 43096cccf1ce ! .hgtags Changeset: 140fdef4ddf5 Author: cl Date: 2010-08-26 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/140fdef4ddf5 Added tag jdk7-b107 for changeset 7d396ad455c3 ! .hgtags Changeset: 0df9c57eb80d Author: cl Date: 2010-09-03 12:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/0df9c57eb80d Added tag jdk7-b108 for changeset 140fdef4ddf5 ! .hgtags From john.coomes at oracle.com Wed Sep 8 15:38:54 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 08 Sep 2010 22:38:54 +0000 Subject: hg: jdk7/hotspot-comp/corba: 7 new changesets Message-ID: <20100908223901.0CA9E477FB@hg.openjdk.java.net> Changeset: 11e7678c3eb1 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/11e7678c3eb1 Added tag jdk7-b102 for changeset 78561a957790 ! .hgtags Changeset: 9607213481d4 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/9607213481d4 Added tag jdk7-b103 for changeset 11e7678c3eb1 ! .hgtags Changeset: 6f21b030092f Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/6f21b030092f Added tag jdk7-b104 for changeset 9607213481d4 ! .hgtags Changeset: 519daea48888 Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/519daea48888 Added tag jdk7-b105 for changeset 6f21b030092f ! .hgtags Changeset: 232adb83eae8 Author: cl Date: 2010-08-19 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/232adb83eae8 Added tag jdk7-b106 for changeset 519daea48888 ! .hgtags Changeset: 8d810527b499 Author: cl Date: 2010-08-26 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/8d810527b499 Added tag jdk7-b107 for changeset 232adb83eae8 ! .hgtags Changeset: 74d57b218468 Author: cl Date: 2010-09-03 12:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/74d57b218468 Added tag jdk7-b108 for changeset 8d810527b499 ! .hgtags From john.coomes at oracle.com Wed Sep 8 15:42:23 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 08 Sep 2010 22:42:23 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 7 new changesets Message-ID: <20100908224223.69FCE477FC@hg.openjdk.java.net> Changeset: b7722e878864 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/b7722e878864 Added tag jdk7-b102 for changeset 15573625af97 ! .hgtags Changeset: d42c4acb6424 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/d42c4acb6424 Added tag jdk7-b103 for changeset b7722e878864 ! .hgtags Changeset: 3233b9a4c12e Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/3233b9a4c12e Added tag jdk7-b104 for changeset d42c4acb6424 ! .hgtags Changeset: 5ba8469212a6 Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/5ba8469212a6 Added tag jdk7-b105 for changeset 3233b9a4c12e ! .hgtags Changeset: 20ee37c1372a Author: cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/20ee37c1372a Added tag jdk7-b106 for changeset 5ba8469212a6 ! .hgtags Changeset: 7d379f8934ca Author: cl Date: 2010-08-26 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/7d379f8934ca Added tag jdk7-b107 for changeset 20ee37c1372a ! .hgtags Changeset: 840d6acde4e8 Author: cl Date: 2010-09-03 12:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/840d6acde4e8 Added tag jdk7-b108 for changeset 7d379f8934ca ! .hgtags From john.coomes at oracle.com Wed Sep 8 15:42:29 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 08 Sep 2010 22:42:29 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 7 new changesets Message-ID: <20100908224230.121AB477FD@hg.openjdk.java.net> Changeset: 267386d6b923 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/267386d6b923 Added tag jdk7-b102 for changeset d8580443d181 ! .hgtags Changeset: bbc4cce6c20a Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/bbc4cce6c20a Added tag jdk7-b103 for changeset 267386d6b923 ! .hgtags Changeset: 39eb4f3031f4 Author: cl Date: 2010-08-06 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/39eb4f3031f4 Added tag jdk7-b104 for changeset bbc4cce6c20a ! .hgtags Changeset: bc45ccc5bcca Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/bc45ccc5bcca Added tag jdk7-b105 for changeset 39eb4f3031f4 ! .hgtags Changeset: 017612ea6af4 Author: cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/017612ea6af4 Added tag jdk7-b106 for changeset bc45ccc5bcca ! .hgtags Changeset: b1ca39340238 Author: cl Date: 2010-08-26 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/b1ca39340238 Added tag jdk7-b107 for changeset 017612ea6af4 ! .hgtags Changeset: ef7838f988c5 Author: cl Date: 2010-09-03 12:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/ef7838f988c5 Added tag jdk7-b108 for changeset b1ca39340238 ! .hgtags From john.coomes at oracle.com Wed Sep 8 15:44:47 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 08 Sep 2010 22:44:47 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 94 new changesets Message-ID: <20100908230016.7315D47801@hg.openjdk.java.net> Changeset: 6488b70a23cc Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6488b70a23cc Added tag jdk7-b102 for changeset 13029a61b16b ! .hgtags Changeset: b839344245a9 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b839344245a9 Added tag jdk7-b103 for changeset 6488b70a23cc ! .hgtags Changeset: 6950da80c75c Author: ohair Date: 2010-08-02 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6950da80c75c 6973616: Update minimum boot jdk from 1.5 to 1.6 Reviewed-by: igor, jjg ! make/common/shared/Defs-versions.gmk Changeset: dd48c78218a7 Author: ohair Date: 2010-08-02 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dd48c78218a7 6971426: jdk/make/docs docs target does not work on windows Reviewed-by: igor, jjg ! make/docs/Makefile Changeset: f46ec75b1663 Author: ohair Date: 2010-08-03 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f46ec75b1663 6974239: Correct reference to jdk document site in javadoc Reviewed-by: skannan ! make/docs/Makefile Changeset: 1a92820132a0 Author: cl Date: 2010-08-04 22:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1a92820132a0 Merge Changeset: d967f8507d9d Author: cl Date: 2010-08-06 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d967f8507d9d Added tag jdk7-b104 for changeset 1a92820132a0 ! .hgtags Changeset: 539528c5d395 Author: lana Date: 2010-07-14 09:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/539528c5d395 Merge Changeset: cf0c23a99823 Author: lana Date: 2010-07-29 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cf0c23a99823 Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: c6f443c3d96a Author: lana Date: 2010-08-02 19:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c6f443c3d96a Merge Changeset: c38803ce0560 Author: uta Date: 2010-07-23 18:59 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c38803ce0560 6969851: VM hangs/crashes in FileDialog test (VS2008/2010 build) Reviewed-by: prr, art ! src/windows/native/sun/windows/awt.h Changeset: 9bb8d5c093fc Author: lana Date: 2010-07-29 13:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9bb8d5c093fc Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: 8a72583dc41d Author: lana Date: 2010-08-02 19:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8a72583dc41d Merge Changeset: 65403b9bcb58 Author: peterz Date: 2010-07-13 17:26 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/65403b9bcb58 6462562: InternationalFormatter inserts text incorrectly 6578432: Currency format instance does not work with Swing's NumberFormatter Reviewed-by: rupashka ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/InternationalFormatter.java + test/javax/swing/JFormattedTextField/Test6462562.java Changeset: a0d7b76abcd3 Author: alexp Date: 2010-07-29 19:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a0d7b76abcd3 4743225: Size of JComboBox list is wrong when list is populated via PopupMenuListener Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java + test/javax/swing/JComboBox/4743225/bug4743225.java Changeset: 0e8acbf12695 Author: lana Date: 2010-07-29 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0e8acbf12695 Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: 951e46d93af0 Author: malenkov Date: 2010-07-30 19:21 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/951e46d93af0 6199676: REGRESSION: ColorChooser loses preview when change LandF in Java5 Reviewed-by: alexp, peterz ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java + test/javax/swing/JColorChooser/Test6199676.java Changeset: f40de306ab66 Author: malenkov Date: 2010-07-30 19:40 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f40de306ab66 6972468: Security manager should be used for tests in java/beans/XMLEncoder Reviewed-by: peterz ! test/java/beans/XMLEncoder/Test4631471.java ! test/java/beans/XMLEncoder/Test4903007.java ! test/java/beans/XMLEncoder/javax_swing_JLayeredPane.java Changeset: ce1e26600ab7 Author: lana Date: 2010-08-02 19:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ce1e26600ab7 Merge Changeset: 25050030a320 Author: dsamersoff Date: 2010-07-13 15:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/25050030a320 6964714: NetworkInterface getInetAddresses enumerates IPv6 addresses if java.net.preferIPvStack property set Summary: User can disable ipv6 explicitly, have to check it Reviewed-by: chegar, alanb ! src/solaris/native/java/net/NetworkInterface.c + test/java/net/NetworkInterface/IPv4Only.java Changeset: f3a4c1947fd1 Author: weijun Date: 2010-07-13 20:27 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f3a4c1947fd1 6670889: Keystore created under Hindi Locale causing ArrayIndexOutOfBoundsException Reviewed-by: chegar ! src/share/classes/sun/security/util/DerOutputStream.java + test/sun/security/util/DerOutputStream/LocaleInTime.java Changeset: ab65f46ae092 Author: darcy Date: 2010-07-15 18:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ab65f46ae092 6963622: Project Coin: Refinements to suppressed exceptions Reviewed-by: alanb, forax, jjb ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Throwable.java ! test/java/lang/Throwable/SuppressedExceptions.java Changeset: a3747592bdf7 Author: sherman Date: 2010-07-16 16:45 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a3747592bdf7 6964313: Find sun/nio/cs/ext issue with CreateSymbols, then move sun/nio/cs/ext to charset.jar Summary: Removed the duplicate sun.nio.cs.ext entries from rt.jar and moved X11 charsets into charsets.jar Reviewed-by: ohair ! make/common/Release.gmk ! make/sun/nio/cs/Makefile Changeset: 9a1bd20fc71c Author: weijun Date: 2010-07-19 10:02 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9a1bd20fc71c 6969683: Generify ResolverConfiguration codes Reviewed-by: alanb, chegar ! src/share/classes/com/sun/jndi/dns/DnsContextFactory.java ! src/share/classes/sun/net/dns/ResolverConfiguration.java ! src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java Changeset: 4022e0c84507 Author: weijun Date: 2010-07-19 10:02 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4022e0c84507 6969292: make DNS lookup for realm/kdc really work Reviewed-by: alanb, valeriep ! src/share/classes/sun/security/krb5/Config.java Changeset: 9d1994d53a67 Author: mullan Date: 2010-07-20 10:41 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9d1994d53a67 6870553: X509Certificate.getSigAlgName method description uses non-standard algorithm name as example Reviewed-by: xuelei ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java Changeset: 58f325ba3e27 Author: chegar Date: 2010-07-21 13:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/58f325ba3e27 6969395: TEST_BUG: Tests in java/net sun/net problems Reviewed-by: alanb ! test/ProblemList.txt ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test11.java ! test/com/sun/net/httpserver/Test12.java ! test/com/sun/net/httpserver/Test13.java ! test/com/sun/net/httpserver/Test6a.java ! test/com/sun/net/httpserver/Test7a.java ! test/com/sun/net/httpserver/Test8a.java ! test/com/sun/net/httpserver/Test9.java ! test/com/sun/net/httpserver/Test9a.java ! test/com/sun/net/httpserver/bugs/B6361557.java ! test/com/sun/net/httpserver/bugs/B6373555.java ! test/java/net/DatagramSocket/DatagramTimeout.java ! test/java/net/DatagramSocket/SendSize.java ! test/java/net/Inet6Address/B6558853.java ! test/java/net/Inet6Address/serialize/Serialize.java ! test/java/net/InetAddress/CheckJNI.java ! test/java/net/MulticastSocket/SetOutgoingIf.java ! test/java/net/ResponseCache/B6181108.java ! test/java/net/ResponseCache/ResponseCacheTest.java ! test/java/net/ResponseCache/getResponseCode.java - test/java/net/Socket/AccurateTimeout.java ! test/java/net/Socket/CloseAvailable.java ! test/java/net/Socket/DeadlockTest.java ! test/java/net/Socket/LingerTest.java ! test/java/net/Socket/LinkLocal.java ! test/java/net/Socket/ProxyCons.java ! test/java/net/Socket/ReadTimeout.java ! test/java/net/Socket/SetReceiveBufferSize.java ! test/java/net/Socket/SetSoLinger.java ! test/java/net/Socket/ShutdownBoth.java ! test/java/net/Socket/SoTimeout.java ! test/java/net/Socket/Timeout.java ! test/java/net/Socket/UrgentDataTest.java ! test/java/net/Socket/asyncClose/BrokenPipe.java ! test/java/net/Socket/setReuseAddress/Restart.java ! test/java/net/SocketInputStream/SocketClosedException.java ! test/java/net/SocketInputStream/SocketTimeout.java ! test/java/net/URL/GetContent.java ! test/java/net/URLClassLoader/ClassLoad.java ! test/java/net/URLConnection/DisconnectAfterEOF.java ! test/java/net/URLConnection/HandleContentTypeWithAttrs.java ! test/java/net/URLConnection/HttpContinueStackOverflow.java ! test/java/net/URLConnection/Redirect307Test.java ! test/java/net/URLConnection/RedirectLimit.java ! test/java/net/URLConnection/ResendPostBody.java ! test/java/net/URLConnection/SetIfModifiedSince.java ! test/java/net/URLConnection/TimeoutTest.java ! test/java/net/URLConnection/URLConnectionHeaders.java ! test/java/net/URLConnection/ZeroContentLength.java ! test/java/net/ipv6tests/B6521014.java ! test/java/net/ipv6tests/TcpTest.java ! test/java/net/ipv6tests/Tests.java ! test/sun/net/ftp/FtpGetContent.java ! test/sun/net/ftp/FtpURL.java ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/ChunkedOutputStream/Test.java ! test/sun/net/www/http/HttpClient/B6726695.java ! test/sun/net/www/http/HttpClient/MultiThreadTest.java ! test/sun/net/www/http/HttpClient/ProxyTest.java ! test/sun/net/www/http/KeepAliveCache/KeepAliveTimerThread.java ! test/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java ! test/sun/net/www/httptest/HttpServer.java ! test/sun/net/www/protocol/http/DigestTest.java Changeset: f90999d7c404 Author: chegar Date: 2010-07-21 13:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f90999d7c404 6970262: TEST_BUG: test/java/net/NetworkInterface/IPv4Only.java has wrong test name in @run tag Reviewed-by: alanb, dsamersoff ! test/java/net/NetworkInterface/IPv4Only.java Changeset: 3902c742b5b1 Author: alanb Date: 2010-07-21 18:08 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3902c742b5b1 6963907: (so) Socket adapter need to implement sendUrgentData Reviewed-by: chegar ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/solaris/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/native/sun/nio/ch/SocketChannelImpl.c + test/java/nio/channels/SocketChannel/OutOfBand.java Changeset: d899526a187a Author: dcubed Date: 2010-07-21 16:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d899526a187a 6941287: 4/4 jrunscriptTest.sh test does not work right under Cygwin Summary: Add golden_diff variable for doing proper golden file diffs on Cygwin. Reviewed-by: ohair, dholmes ! test/sun/tools/jrunscript/common.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh Changeset: 946236dc5c96 Author: dcubed Date: 2010-07-21 16:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/946236dc5c96 6962804: 4/4 ShellScaffold tests can fail without a specific reason Summary: Add more diagnostics for failures. Only copy target file in grepForString when NL is missing. Reviewed-by: ohair, dholmes ! test/com/sun/jdi/ShellScaffold.sh Changeset: 9cb77130999f Author: dcubed Date: 2010-07-21 17:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9cb77130999f 6964018: 3/4 AnonLoggerWeakRefLeak and LoggerWeakRefLeak can fail in JPRT Summary: Refactor test/sun/tools/common/* code and refactor AnonLoggerWeakRefLeak and LoggerWeakRefLeak to use it. Reviewed-by: ohair, alanb ! test/java/util/logging/AnonLoggerWeakRefLeak.java ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.java ! test/java/util/logging/LoggerWeakRefLeak.sh ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/common/CommonSetup.sh + test/sun/tools/common/CommonTests.sh ! test/sun/tools/common/ShutdownSimpleApplication.java ! test/sun/tools/common/SimpleApplication.java + test/sun/tools/common/SleeperApplication.java ! test/sun/tools/jhat/ParseTest.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/jmap/Basic.sh ! test/sun/tools/jstack/Basic.sh Changeset: 748f004aeb5c Author: vinnie Date: 2010-07-23 17:41 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/748f004aeb5c 6676075: RegistryContext (com.sun.jndi.url.rmi.rmiURLContext) coding problem Reviewed-by: mullan ! src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java + test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java Changeset: 56217857ccd7 Author: xuelei Date: 2010-07-24 22:59 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/56217857ccd7 6867345: Turkish regional options cause NPE in sun.security.x509.AlgorithmId.algOID Reviewed-by: mullan, weijun ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/pkcs/PKCS9Attribute.java ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/x509/AVA.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! src/share/classes/sun/security/x509/DNSName.java ! src/share/classes/sun/security/x509/RFC822Name.java + test/sun/security/x509/AlgorithmId/TurkishRegion.java Changeset: 402ff3e81922 Author: weijun Date: 2010-07-26 17:21 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/402ff3e81922 6972005: ConfPlusProp.java test failure when DNS has info for realm Reviewed-by: xuelei ! test/sun/security/krb5/ConfPlusProp.java ! test/sun/security/krb5/confplusprop.conf ! test/sun/security/krb5/confplusprop2.conf Changeset: db21b420d038 Author: martin Date: 2010-07-26 08:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/db21b420d038 6717780: (coll spec) LinkedList api documentation provides the wrong method name Summary: Cleanup by simply making Deque equal status with List Reviewed-by: darcy ! src/share/classes/java/util/LinkedList.java Changeset: 1bfa1c864553 Author: dcubed Date: 2010-07-26 09:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1bfa1c864553 6971847: 4/4 jmap '-histo:live' option is necessary for proper leak detection Summary: Add work around for 6971851. Abort if 'histo:live' option isn't supported. Reviewed-by: alanb, darcy ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.sh Changeset: 83be262e654c Author: xuelei Date: 2010-07-27 16:07 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/83be262e654c 6870947: 15 sec delay detecting "socket closed" condition when a TCP connection is reset by an LDAP server Reviewed-by: weijun ! src/share/classes/com/sun/jndi/ldap/Connection.java Changeset: 5ff8b884a92c Author: vinnie Date: 2010-07-27 11:40 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5ff8b884a92c 6972409: Cease emitting LDAP filter debug messages Reviewed-by: xuelei ! src/share/classes/com/sun/jndi/ldap/Filter.java Changeset: 24741c4bf300 Author: alanb Date: 2010-07-29 13:08 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/24741c4bf300 6934977: (bf) MappedByteBuffer.load can SIGBUS if file is truncated 6799037: (fs) MappedByteBuffer.load crash with unaligned file-mapping (sol) Reviewed-by: chegar, forax ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/MappedByteBuffer.java ! src/solaris/native/java/nio/MappedByteBuffer.c ! src/windows/native/java/nio/MappedByteBuffer.c ! test/java/nio/MappedByteBuffer/Basic.java + test/java/nio/MappedByteBuffer/Truncate.java Changeset: a8a79f5b669e Author: chegar Date: 2010-07-29 10:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a8a79f5b669e 6972374: NetworkInterface.getNetworkInterfaces throws "java.net.SocketException" on Solaris zone Reviewed-by: alanb, dsamersoff ! src/solaris/native/java/net/NetworkInterface.c Changeset: d82ed433304e Author: chegar Date: 2010-07-29 17:04 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d82ed433304e Merge Changeset: 48e6f4807e5f Author: lana Date: 2010-07-29 22:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/48e6f4807e5f Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 ! test/ProblemList.txt Changeset: 4d72d0ec83f5 Author: michaelm Date: 2010-07-30 18:16 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4d72d0ec83f5 6510892: com/sun/net/httpserver/bugs/B6361557.java fails Reviewed-by: chegar ! test/com/sun/net/httpserver/bugs/B6361557.java Changeset: 10e7e04d1e96 Author: lana Date: 2010-08-02 19:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/10e7e04d1e96 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: 3b0abcb51280 Author: lana Date: 2010-08-09 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3b0abcb51280 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: 9ad95be9deae Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9ad95be9deae Added tag jdk7-b105 for changeset 3b0abcb51280 ! .hgtags Changeset: f8bbf376595c Author: yhuang Date: 2010-08-11 02:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f8bbf376595c 6959252: convert the anonymous arrays to named arrays in Java List Resource files Reviewed-by: katakai, psun ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/sun/applet/resources/MsgAppletViewer.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii.java Changeset: 413cede85120 Author: yhuang Date: 2010-08-13 01:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/413cede85120 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: b91ef6b60f4e Author: cl Date: 2010-08-16 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b91ef6b60f4e Merge Changeset: 882103f334bb Author: cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/882103f334bb Added tag jdk7-b106 for changeset b91ef6b60f4e ! .hgtags Changeset: 17a5d84b7561 Author: cl Date: 2010-08-26 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/17a5d84b7561 Added tag jdk7-b107 for changeset 882103f334bb ! .hgtags Changeset: d47bd9d94ba4 Author: dlila Date: 2010-08-10 13:19 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d47bd9d94ba4 6967436: lines longer than 2^15 can fill window. 6967433: dashed lines broken when using scaling transforms. Summary: converted pisces to floating point. Also, using better AA algorithm Reviewed-by: flar ! src/share/classes/sun/java2d/pisces/Dasher.java ! src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/java2d/pisces/PiscesMath.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/java2d/pisces/Renderer.java ! src/share/classes/sun/java2d/pisces/Stroker.java - src/share/classes/sun/java2d/pisces/Transform4.java Changeset: 4285edea9ddb Author: dlila Date: 2010-08-11 10:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4285edea9ddb 6976265: No STROKE_CONTROL Summary: implemented it in sun.java2d.pisces by adding a PathIterator. Reviewed-by: flar ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java Changeset: 0576f6cc0463 Author: lana Date: 2010-08-12 19:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0576f6cc0463 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: 654145d6560a Author: lana Date: 2010-08-23 19:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/654145d6560a Merge - src/share/classes/sun/java2d/pisces/PiscesMath.java - src/share/classes/sun/java2d/pisces/Transform4.java Changeset: d0e314d59f84 Author: malenkov Date: 2010-08-10 19:29 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d0e314d59f84 6960267: JTable.getRowHeight() returns value different from the specified default (16.0) with GTK L&F Reviewed-by: peterz ! src/share/classes/javax/swing/JTable.java Changeset: 58626b4eedcb Author: lana Date: 2010-08-12 11:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/58626b4eedcb Merge - test/java/net/Socket/AccurateTimeout.java Changeset: 23f72ec0d8e8 Author: peytoia Date: 2010-08-23 14:14 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/23f72ec0d8e8 6977550: (tz) Support tzdata2010l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: a18a82d2d506 Author: lana Date: 2010-08-23 19:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a18a82d2d506 Merge Changeset: 367b90ed38b1 Author: chegar Date: 2010-08-03 12:03 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/367b90ed38b1 6973030: NTLM proxy authentication fails with https Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java Changeset: a21c46dac6cf Author: mullan Date: 2010-08-03 09:39 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a21c46dac6cf 6653372: Error in java.security.KeyStore example code Reviewed-by: weijun ! src/share/classes/java/security/KeyStore.java Changeset: 2feeefb45a44 Author: mullan Date: 2010-08-03 09:55 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2feeefb45a44 Merge Changeset: 3b63e506b57e Author: martin Date: 2010-08-03 12:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3b63e506b57e 6955504: (str) String[Builder/Buffer].append(char[],int,int) throws OutOfMemoryError in b94 Summary: let arraycopy throw AIOOBE for invalid negative length Reviewed-by: chegar, forax ! src/share/classes/java/lang/AbstractStringBuilder.java Changeset: 188f156148ea Author: apangin Date: 2010-08-04 20:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/188f156148ea 6945961: SIGSEGV in memcpy() during class loading on linux-i586 Summary: Check the result of strchr() in Bytecode Verifier Reviewed-by: kamg, acorn ! src/share/native/common/check_code.c Changeset: d47f5dcda481 Author: dcubed Date: 2010-08-06 11:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d47f5dcda481 6962604: 3/3 Testcase sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh failure Summary: Disable MonitorVmStartTerminate.sh until 6543856 is fixed. Reviewed-by: ohair ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh Changeset: 3e239fe92832 Author: lancea Date: 2010-08-10 10:07 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3e239fe92832 6898593: java.sql.Date.valueOf no exception if date given is not in the JDBC date escape syntax Reviewed-by: minqi ! src/share/classes/java/sql/Date.java Changeset: 1f996198877b Author: chegar Date: 2010-08-10 17:30 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1f996198877b 6882910: Unexplained lack of IP4 network ability when transparent IP6 to IP4 is disabled. Reviewed-by: alanb ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c ! src/solaris/native/sun/nio/ch/Net.c Changeset: da5b67ac7755 Author: sherman Date: 2010-08-10 13:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/da5b67ac7755 6923794: About 40 JCK test case fail with AssertionError if -esa option is specified Summary: removed the assert Reviewed-by: alanb ! src/solaris/classes/java/io/UnixFileSystem.java ! src/windows/classes/java/io/Win32FileSystem.java Changeset: 11ee8b471f9c Author: alanb Date: 2010-08-12 19:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/11ee8b471f9c 6971825: (so) improve scatter/gather implementation Reviewed-by: chegar, sherman ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/IOVecWrapper.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/ch/Util.java Changeset: 389bc53d0945 Author: mchung Date: 2010-08-12 16:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/389bc53d0945 6973831: NPE when printing stack trace of OOME Summary: Initialize suppressedExceptions field to null Reviewed-by: briangoetz, dholmes, forax ! src/share/classes/java/lang/Throwable.java Changeset: cdd6d518f47e Author: mchung Date: 2010-08-12 16:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cdd6d518f47e Merge Changeset: 041997c49f15 Author: lana Date: 2010-08-12 19:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/041997c49f15 Merge Changeset: 0cdd73548292 Author: gbenson Date: 2010-08-13 22:26 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0cdd73548292 6976186: Integrate Shark Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure. Reviewed-by: ohair ! make/jdk_generic_profile.sh Changeset: 8329ebeabc10 Author: mchung Date: 2010-08-16 15:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8329ebeabc10 6921234: TEST_BUG: java/lang/ClassLoader/deadlock/TestCrossDelegate.sh needs to be modified for Cygwin Summary: Add check for CYGWIN Reviewed-by: ohair ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh Changeset: 42eaa082a4e6 Author: michaelm Date: 2010-08-17 14:49 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/42eaa082a4e6 6339649: URI.create should include a detail message when throwing IllegalArgumentException Summary: create enclosing exception with message of enclosed Reviewed-by: alanb, chegar ! src/share/classes/java/net/URI.java ! test/java/net/URI/Test.java Changeset: bfc3855a9341 Author: sherman Date: 2010-08-17 16:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bfc3855a9341 6969651: TEST_BUG: tools/jar/JarEntryTime.java failed on JDK7 when run on NFS Summary: changed to use more appropriate nfs file time Reviewed-by: martin ! test/tools/jar/JarEntryTime.java Changeset: 01dec49e95c4 Author: ohair Date: 2010-08-18 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/01dec49e95c4 6974005: Use of cygpath in Makefile logic needs to silence error messages Reviewed-by: mchung ! make/common/shared/Defs-windows.gmk Changeset: 42bfa43f2ae1 Author: ohair Date: 2010-08-18 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/42bfa43f2ae1 6932743: Makefiles not parsing version strings with - from uname -r Reviewed-by: mchung ! make/common/shared/Defs.gmk Changeset: 4abd65f04638 Author: weijun Date: 2010-08-19 11:26 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4abd65f04638 6976536: Solaris JREs do not have the krb5.kdc.bad.policy configured by default. Reviewed-by: valeriep ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows + test/sun/security/krb5/BadKdcDefaultValue.java Changeset: 95bb147c7c33 Author: weijun Date: 2010-08-19 12:24 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/95bb147c7c33 6921610: 1.6 update 17 and 18 throw java.lang.IndexOutOfBoundsException Reviewed-by: vinnie, xuelei ! src/share/classes/com/sun/jndi/ldap/Connection.java Changeset: 1ce9c1690080 Author: ksrini Date: 2010-08-19 14:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1ce9c1690080 6888127: java.util.jar.Pack200.Packer Memory Leak Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java + src/share/classes/com/sun/java/util/jar/pack/TLGlobals.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java Changeset: 16e43f336262 Author: ksrini Date: 2010-08-20 08:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/16e43f336262 6966737: (pack200) the pack200 regression tests need to be more robust. Reviewed-by: jrose, ohair + test/tools/pack200/CommandLineTests.java - test/tools/pack200/Pack200Simple.sh ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/PackageVersionTest.java ! test/tools/pack200/SegmentLimit.java + test/tools/pack200/Utils.java + test/tools/pack200/pack200-verifier/data/README + test/tools/pack200/pack200-verifier/data/golden.jar + test/tools/pack200/pack200-verifier/make/build.xml + test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/ClassCompare.java + test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/Globals.java + test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/JarFileCompare.java + test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/Main.java + test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/VerifyTreeSet.java + test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java + test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java + test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java + test/tools/pack200/pack200-verifier/src/xmlkit/CommandLineParser.java + test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java + test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java + test/tools/pack200/pack200-verifier/src/xmlkit/TokenList.java + test/tools/pack200/pack200-verifier/src/xmlkit/XMLKit.java Changeset: db1b7c10de61 Author: ksrini Date: 2010-08-20 08:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/db1b7c10de61 Merge Changeset: fd28003bc1d6 Author: chegar Date: 2010-08-23 14:35 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fd28003bc1d6 6968584: Thread should not be Cloneable Reviewed-by: dholmes ! src/share/classes/java/lang/Thread.java Changeset: 03218163f4d5 Author: chegar Date: 2010-08-23 16:27 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/03218163f4d5 6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe Reviewed-by: michaelm ! src/share/classes/java/net/HttpCookie.java Changeset: 47ab0dcec3e8 Author: alanb Date: 2010-08-23 17:11 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/47ab0dcec3e8 6978511: (file) Path.toRealPath should fail if not resolving links and file does not exist Reviewed-by: forax, chegar ! src/solaris/classes/sun/nio/fs/UnixPath.java ! test/java/nio/file/Path/Misc.java Changeset: f4a2b4e7a831 Author: alanb Date: 2010-08-23 17:35 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f4a2b4e7a831 6431344: (fc) FileChannel.transferTo() doesn't work if address space runs out Reviewed-by: forax, chegar ! src/share/classes/sun/nio/ch/FileChannelImpl.java Changeset: 6317f7e2c4fd Author: ksrini Date: 2010-08-23 08:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6317f7e2c4fd 6531345: Memory leak in unpack200 Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java + test/tools/pack200/UnpackerMemoryTest.java ! test/tools/pack200/Utils.java Changeset: cb67f0263bd4 Author: chegar Date: 2010-08-23 21:59 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cb67f0263bd4 6977851: NPE from FileURLConnection.connect Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/file/FileURLConnection.java + test/sun/net/www/protocol/file/DirPermissionDenied.java + test/sun/net/www/protocol/file/DirPermissionDenied.sh Changeset: 2585368bfc7c Author: ksrini Date: 2010-08-23 10:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2585368bfc7c 6969063: (pack200) The default value of Pack200.Packer.SEGMENT_LIMIT property is empty string instead of -1 Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java + test/tools/pack200/Pack200Props.java - test/tools/pack200/SegmentLimit.java Changeset: 732f59013e78 Author: ksrini Date: 2010-08-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/732f59013e78 6966740: (pack200) need to add the timezone regression test Reviewed-by: jrose + test/tools/pack200/TimeStamp.java ! test/tools/pack200/Utils.java Changeset: 62d37c19c213 Author: lana Date: 2010-08-23 19:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/62d37c19c213 Merge - test/tools/pack200/Pack200Simple.sh - test/tools/pack200/SegmentLimit.java Changeset: 043d2736d44c Author: lana Date: 2010-08-29 22:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/043d2736d44c Merge - src/share/classes/sun/java2d/pisces/PiscesMath.java - src/share/classes/sun/java2d/pisces/Transform4.java - test/tools/pack200/Pack200Simple.sh - test/tools/pack200/SegmentLimit.java From john.r.rose at oracle.com Wed Sep 8 18:47:06 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 09 Sep 2010 01:47:06 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 3 new changesets Message-ID: <20100909014736.F200647822@hg.openjdk.java.net> Changeset: 48f0b94573c8 Author: jrose Date: 2010-09-08 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/48f0b94573c8 6964498: JSR 292 invokedynamic sites need local bootstrap methods Summary: Add JVM_CONSTANT_InvokeDynamic records to constant pool to determine per-instruction BSMs; add MethodHandleProvider. Reviewed-by: twisti + src/share/classes/java/dyn/BootstrapMethod.java ! src/share/classes/java/dyn/CallSite.java + src/share/classes/java/dyn/ConstantCallSite.java ! src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/MethodHandle.java + src/share/classes/java/dyn/MethodHandleProvider.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! test/java/dyn/MethodHandlesTest.java Changeset: d30ca8bcad63 Author: jrose Date: 2010-09-08 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d30ca8bcad63 6980096: JSR 292 reflective lookup should throw checked exceptions Summary: Make NoAccessException be a checked exception. Also remove JavaMethodHandle. Reviewed-by: twisti ! src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/JavaMethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/dyn/NoAccessException.java ! src/share/classes/sun/dyn/BoundMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/Invokers.java + src/share/classes/sun/dyn/JavaMethodHandle.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/util/ValueConversions.java + test/java/dyn/JavaDocExamples.java ! test/java/dyn/MethodHandlesTest.java Changeset: 93f36769ecef Author: jrose Date: 2010-09-08 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/93f36769ecef 6953246: JSR 292 should support SAM conversion Summary: Conversion function MethodHandles.asInstance; initial slow implementation based on Proxy. Reviewed-by: twisti ! src/share/classes/java/dyn/MethodHandles.java ! test/java/dyn/MethodHandlesTest.java From john.r.rose at oracle.com Wed Sep 8 19:50:36 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 8 Sep 2010 19:50:36 -0700 Subject: [jvm-l] Re: Small static method marked not entrant, inlining reversed? In-Reply-To: References: <18A6B79F-F944-46CD-8D98-B65E6C32C2D1@oracle.com> <51D5688C-4D91-47A3-9033-1F77B47060DC@oracle.com> <08FEFA4F-6F71-4E88-9649-48D2FFD093BE@oracle.com> Message-ID: On Sep 8, 2010, at 5:43 AM, Charles Oliver Nutter wrote: > On Wed, Sep 8, 2010 at 2:29 AM, John Rose wrote: >> That's exactly right. Sounds like CHA (class hierarchy analysis) under interfaces would bail you out, at least until you created too many (>1 or >2) disjoint IRubyObject implementations. > > Yes, it sounds like exactly what I want. I'm guessing this is a "nice > to have but not currently being worked" sort of problem, but it seems > like a very generally-applicable improvement to Hotspot, since it's > probably common (this would be easy to measure) to have an > invokeinterface that receives multiple types but those types' > implementations of that interface mostly boil down to the same > superclass. As far as I understand it, it would help any case where > you've extended an existing type but pass it around via some > superclass's interface. > > A simple analysis could be done quickly too: resolve the type profile > to the actual implementer of the interface, rather than to the exact > type. Since invokeinterface knows what interface it's looking for, it > could do a quick hierarchy scan to find the class that first claims to > implement it. Generally when extending a class that already implements > an interface, you don't re-add "implements", so this would work in a > high percentage of cases. Does the type profile at present support > resolving to a superclass, or does it only support resolving to an > object's exact class? No, it only includes exact classes. To extend the profile would require detecting profile overflow and switching to an "inexact mode", and then teaching the optimizer to do useful stuff with those extra states. The code generation framework is already pretty good at building the required code shapes; the missing bit is optimization policy. This would be a good training project for someone that wanted to learn the system thoroughly. (He said, with a hopeful look.) >> A related problem may be either (a) the type profile doesn't collect general-enough information or (b) we don't have enough type profile points to collect specific-enough information. We can fix (a) by collecting ever fancier profile information or (b) by splitting profile points during inlining in early tiers. > > (a) could be the "find real implementer" above as a short-term > improvement, and later "find common superclass that implements the > target signature". I assume the latter already works because the > following also avoids the deopt I saw: > > public static boolean isGenerationEqual(IRubyObject object, int > generation) { > return ((RubyObject)object).getMetaClass().getCacheToken() == > generation; > } That works (I think) because getMetaClass is monomorphic in RubyObject, and CHA is designed to detect such conditions. If IRubyObject has just one implementor (RubyObject), we could do CHA on that implementor, and issue a dependency against new implementors of IRubyObject getting loaded. That would be a good starter project. > Presumably the type profile here is able to handle arbitrarily many > subclasses of RubyObject. The above code really ought to optimize (at > least in my case) the same as: No, the type profile is limited to -XX:TypeProfileWidth=2 distinct classes (with associated frequency counts). But CHA is not limited, since it doesn't have to record any history. > public static boolean isGenerationEqual(IRubyObject object, int > generation) { > return object.getMetaClass().getCacheToken() == generation; > } > > I would love to see that happen (and I'm willing to help, after the > necessary C2 learning period!), but for now I'll have to make some > hard decisions in the JRuby codebase and compiler :( > >> (Or (c) use an explicitly controlled templating mechanism like anonymous classes. That may prematurely multiply bytecodes, though.) > > By this you mean using a class template to specialize a piece of code > to a common superclass *before* passing it to the optimizer? Yes, and/or inlining at the bytecode level so as to "attract" more profiling information. Manual inlining is a desperation move, though. > For what it's worth, the following code is only slightly slower than > the fastest non-hacked implementation and not subject to the > deoptimization: > > public static boolean isGenerationEqual(IRubyObject object, int > generation) { > RubyClass metaClass; > if (object instanceof RubyBasicObject) { > metaClass = ((RubyBasicObject)object).getMetaClass(); > } else { > metaClass = object.getMetaClass(); > } > return metaClass.getCacheToken() == generation; > } Yes, that's what the JIT might produce if it had inexact profiles. (As I described before, in the next build or so 6912064 will make that 'instanceof' collect a new type profile. But it won't help you here, since your 'object' value is strongly polymorphic, even though the type varies under a nice bound of RubyBasicObject.) > But I may end up having the JRuby compiler do this since in order to > do a direct (non-dynamic) call it has to cast to a concrete type > anyway. I will follow this message up with a suggestion that goes in a different direction for managing metaclasses. -- John From tom.rodriguez at oracle.com Wed Sep 8 19:59:07 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 09 Sep 2010 02:59:07 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled Message-ID: <20100909025910.5728547829@hg.openjdk.java.net> Changeset: 5e4f03302987 Author: never Date: 2010-09-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5e4f03302987 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp From tom.rodriguez at oracle.com Thu Sep 9 01:41:31 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 09 Sep 2010 08:41:31 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6965815: OptimizeStringConcat: assert(!q->is_MergeMem()) failed with specjbb2000 Message-ID: <20100909084133.7FAB647839@hg.openjdk.java.net> Changeset: f9883ee8ce39 Author: never Date: 2010-09-08 20:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f9883ee8ce39 6965815: OptimizeStringConcat: assert(!q->is_MergeMem()) failed with specjbb2000 Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp From Christian.Thalinger at Sun.COM Thu Sep 9 04:12:03 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 09 Sep 2010 11:12:03 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20100909111209.DB53A47841@hg.openjdk.java.net> Changeset: 84713fd87632 Author: twisti Date: 2010-09-08 04:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/84713fd87632 6983073: fix compiler error with GCC 4.4 or newer on SPARC Reviewed-by: twisti Contributed-by: Matthias Klose ! src/cpu/sparc/vm/frame_sparc.hpp Changeset: 33a54060190d Author: twisti Date: 2010-09-09 01:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/33a54060190d Merge From christian.thalinger at oracle.com Thu Sep 9 08:50:21 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 09 Sep 2010 17:50:21 +0200 Subject: hg: jdk7/hotspot-comp/hotspot: 6953144: Tiered compilation In-Reply-To: <20100904033018.E2D9C476EA@hg.openjdk.java.net> References: <20100904033018.E2D9C476EA@hg.openjdk.java.net> Message-ID: <1284047421.6836.1.camel@macbook> On Sat, 2010-09-04 at 03:30 +0000, igor.veresov at oracle.com wrote: > Changeset: d5d065957597 > Author: iveresov > Date: 2010-09-03 17:51 -0700 > URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d5d065957597 > > 6953144: Tiered compilation > Summary: Infrastructure for tiered compilation support (interpreter + c1 + c2) for 32 and 64 bit. Simple tiered policy implementation. > Reviewed-by: kvn, never, phh, twisti Actually I don't understand why this happens for me with fastdebug and debug builds and it does not for JPRT: Compiling /home/twisti/hotspot-comp/hotspot/src/share/vm/runtime/java.cpp /home/twisti/hotspot-comp/hotspot/src/share/vm/runtime/java.cpp: In function 'void print_statistics()': /home/twisti/hotspot-comp/hotspot/src/share/vm/runtime/java.cpp:201: error: 'C1UpdateMethodData' was not declared in this scope -- Christian From john.coomes at oracle.com Thu Sep 9 09:03:02 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 09 Sep 2010 16:03:02 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 45 new changesets Message-ID: <20100909160424.D618F4784D@hg.openjdk.java.net> Changeset: bd85271c580c Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/bd85271c580c Added tag jdk7-b102 for changeset ff9c0a0bf7ed ! .hgtags Changeset: fc7219517ec1 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/fc7219517ec1 Added tag jdk7-b103 for changeset bd85271c580c ! .hgtags Changeset: 49489c1d8fae Author: cl Date: 2010-08-06 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/49489c1d8fae Added tag jdk7-b104 for changeset fc7219517ec1 ! .hgtags Changeset: a5454419dd46 Author: jjg Date: 2010-07-13 19:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/a5454419dd46 6966732: replace use of static Log.getLocalizedString with non-static alternative where possible Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java Changeset: 0e1fab5cffc8 Author: jjg Date: 2010-07-13 19:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/0e1fab5cffc8 6968434: test CheckResourceKeys fails on control builds Reviewed-by: darcy ! test/tools/javac/diags/CheckResourceKeys.java Changeset: e57b27703e8b Author: jjg Date: 2010-07-13 19:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e57b27703e8b 6968789: incorrect text in "diamond not supported" message Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: b49b0d72c071 Author: mcimadamore Date: 2010-07-15 16:31 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/b49b0d72c071 6967002: JDK7 b99 javac compilation error (java.lang.AssertionError) Summary: bug in JavacParser related to parsing of type annotations in varargs position Reviewed-by: jjg Contributed-by: mahmood at notnoop.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/typeAnnotations/6967002/T6967002.java + test/tools/javac/typeAnnotations/6967002/T6967002.out Changeset: 472e74211e11 Author: mcimadamore Date: 2010-07-15 16:31 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/472e74211e11 6964669: javac reports error on miranda methods Summary: synthetic name clash check should not apply to miranda methods Reviewed-by: jjg Contributed-by: tomas.zezula at sun.com ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/miranda/6964669/T6964669.java + test/tools/javac/miranda/6964669/pkg/A.java + test/tools/javac/miranda/6964669/pkg/B.java + test/tools/javac/miranda/6964669/pkg/C.java Changeset: 13354e1abba7 Author: darcy Date: 2010-07-16 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/13354e1abba7 6911256: Project Coin: Support Automatic Resource Management (ARM) blocks in the compiler 6964740: Project Coin: More tests for ARM compiler changes 6965277: Project Coin: Correctness issues in ARM implementation 6967065: add -Xlint warning category for Automatic Resource Management (ARM) Reviewed-by: jjb, darcy, mcimadamore, jjg, briangoetz Contributed-by: tball at google.com ! make/build.properties ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/Names.java + test/tools/javac/TryWithResources/ArmLint.java + test/tools/javac/TryWithResources/ArmLint.out + test/tools/javac/TryWithResources/BadTwr.java + test/tools/javac/TryWithResources/BadTwr.out + test/tools/javac/TryWithResources/BadTwrSyntax.java + test/tools/javac/TryWithResources/BadTwrSyntax.out + test/tools/javac/TryWithResources/DuplicateResource.java + test/tools/javac/TryWithResources/DuplicateResourceDecl.java + test/tools/javac/TryWithResources/DuplicateResourceDecl.out + test/tools/javac/TryWithResources/ImplicitFinal.java + test/tools/javac/TryWithResources/ImplicitFinal.out + test/tools/javac/TryWithResources/PlainTry.java + test/tools/javac/TryWithResources/PlainTry.out + test/tools/javac/TryWithResources/PlainTry6.out + test/tools/javac/TryWithResources/ResourceOutsideTry.java + test/tools/javac/TryWithResources/ResourceOutsideTry.out + test/tools/javac/TryWithResources/ResourceTypeVar.java + test/tools/javac/TryWithResources/TwrFlow.java + test/tools/javac/TryWithResources/TwrFlow.out + test/tools/javac/TryWithResources/TwrInference.java + test/tools/javac/TryWithResources/TwrIntersection.java + test/tools/javac/TryWithResources/TwrIntersection02.java + test/tools/javac/TryWithResources/TwrIntersection02.out + test/tools/javac/TryWithResources/TwrMultiCatch.java + test/tools/javac/TryWithResources/TwrOnNonResource.java + test/tools/javac/TryWithResources/TwrOnNonResource.out + test/tools/javac/TryWithResources/TwrTests.java + test/tools/javac/TryWithResources/WeirdTwr.java + test/tools/javac/processing/model/element/TestResourceVariable.java Changeset: 3640b60bd0f6 Author: jjg Date: 2010-07-22 11:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/3640b60bd0f6 6968063: provide examples of code that generate diagnostics Reviewed-by: mcimadamore ! make/build.xml + test/tools/javac/diags/CheckExamples.java + test/tools/javac/diags/Example.java + test/tools/javac/diags/FileManager.java + test/tools/javac/diags/HTMLWriter.java + test/tools/javac/diags/README.examples.txt + test/tools/javac/diags/RunExamples.java + test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/AbstractCantBeAccessed.java + test/tools/javac/diags/examples/AbstractCantBeInstantiated.java + test/tools/javac/diags/examples/AbstractMethodCantHaveBody.java + test/tools/javac/diags/examples/AlreadyDefined.java + test/tools/javac/diags/examples/AlreadyDefinedImport.java + test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java + test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java + test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java + test/tools/javac/diags/examples/AnnoNotApplicable.java + test/tools/javac/diags/examples/AnnoNotValidForType.java + test/tools/javac/diags/examples/AnnoValueMustBeAnnotation.java + test/tools/javac/diags/examples/AnnoValueMustBeClassLiteral.java + test/tools/javac/diags/examples/AnnosWithoutProcessors/AnnosWithoutProcessors.java + test/tools/javac/diags/examples/AnnosWithoutProcessors/processors/AnnoProc.java + test/tools/javac/diags/examples/AnnotationMissingValue.java + test/tools/javac/diags/examples/AnnotationMustBeNameValue.java + test/tools/javac/diags/examples/AnnotationsNotSupported.java + test/tools/javac/diags/examples/AnonClassImplInterfaceNoArgs.java + test/tools/javac/diags/examples/AnonClassImplInterfaceNoQualForNew.java + test/tools/javac/diags/examples/AnonClassImplInterfaceNoTypeArgs.java + test/tools/javac/diags/examples/AnonymousClass.java + test/tools/javac/diags/examples/ArrayAndVarargs.java + test/tools/javac/diags/examples/ArrayDimMissing.java + test/tools/javac/diags/examples/ArrayRequired.java + test/tools/javac/diags/examples/AssertAsIdentifier.java + test/tools/javac/diags/examples/AssertAsIdentifier2.java + test/tools/javac/diags/examples/AttrMustBeConstant.java + test/tools/javac/diags/examples/BadSourceFileHeader/BadSourceFileHeader.java + test/tools/javac/diags/examples/BadSourceFileHeader/sourcepath/p/A.java + test/tools/javac/diags/examples/BreakOutsideSwitchLoop.java + test/tools/javac/diags/examples/CallMustBeFirst.java + test/tools/javac/diags/examples/CannotCreateArrayWithTypeArgs.java + test/tools/javac/diags/examples/CantApplyDiamond.java + test/tools/javac/diags/examples/CantAssignToFinal.java + test/tools/javac/diags/examples/CantDeref.java + test/tools/javac/diags/examples/CantExtendIntfAnno.java + test/tools/javac/diags/examples/CantImplement.java + test/tools/javac/diags/examples/CantInheritDiffArg.java + test/tools/javac/diags/examples/CantRefBeforeConstr.java + test/tools/javac/diags/examples/CantResolve.java + test/tools/javac/diags/examples/CantResolveArgs.java + test/tools/javac/diags/examples/CantResolveArgsParams.java + test/tools/javac/diags/examples/CantResolveLocation.java + test/tools/javac/diags/examples/CantResolveLocationArgs.java + test/tools/javac/diags/examples/CantResolveLocationArgsParams.java + test/tools/javac/diags/examples/CantReturnValueForVoid.java + test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/diags/examples/ClashesWith.java + test/tools/javac/diags/examples/ClassCantWrite.java + test/tools/javac/diags/examples/ClassPublicInFile.java + test/tools/javac/diags/examples/ConcreteInheritanceConflict.java + test/tools/javac/diags/examples/ConstExprRequired.java + test/tools/javac/diags/examples/ConstantSVUID.java + test/tools/javac/diags/examples/ContinueOutsideLoop.java + test/tools/javac/diags/examples/CountError.java + test/tools/javac/diags/examples/CountErrorPlural.java + test/tools/javac/diags/examples/CountWarn.java + test/tools/javac/diags/examples/CountWarnPlural.java + test/tools/javac/diags/examples/CyclicAnnoElement.java + test/tools/javac/diags/examples/CyclicInheritance.java + test/tools/javac/diags/examples/DefaultAllowedInIntfAnnotationMember.java + test/tools/javac/diags/examples/DeprecatedFilename.java + test/tools/javac/diags/examples/DeprecatedFilenameAdditional.java + test/tools/javac/diags/examples/DeprecatedPlural/DeprecatedClass.java + test/tools/javac/diags/examples/DeprecatedPlural/DeprecatedFilename.java + test/tools/javac/diags/examples/DeprecatedPlural/DeprecatedPlural.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedClass.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedFilename.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedPlural.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedPluralAdditional.java + test/tools/javac/diags/examples/DiamondInvalidArg.java + test/tools/javac/diags/examples/DiamondInvalidArgs.java + test/tools/javac/diags/examples/DiamondNotSupported.java + test/tools/javac/diags/examples/DirPathElementNotFound.java + test/tools/javac/diags/examples/DivZero.java + test/tools/javac/diags/examples/DoesNotOverride.java + test/tools/javac/diags/examples/DoesntExist.java + test/tools/javac/diags/examples/DotClassExpected.java + test/tools/javac/diags/examples/DuplicateAnnotation.java + test/tools/javac/diags/examples/DuplicateAnnotationMemberValue.java + test/tools/javac/diags/examples/DuplicateCaseLabel.java + test/tools/javac/diags/examples/DuplicateClass.java + test/tools/javac/diags/examples/DuplicateDefaultLabel.java + test/tools/javac/diags/examples/ElseWithoutIf.java + test/tools/javac/diags/examples/EmptyBytecodeIdent.java + test/tools/javac/diags/examples/EmptyCharLiteral.java + test/tools/javac/diags/examples/EmptyIf.java + test/tools/javac/diags/examples/EnclClassRequired.java + test/tools/javac/diags/examples/EnumAnnoValueMustBeEnumConst.java + test/tools/javac/diags/examples/EnumAsIdentifier.java + test/tools/javac/diags/examples/EnumAsIdentifier2.java + test/tools/javac/diags/examples/EnumCantBeInstantiated.java + test/tools/javac/diags/examples/EnumConstRequired.java + test/tools/javac/diags/examples/EnumLabelUnqualified.java + test/tools/javac/diags/examples/EnumNoFinalize.java + test/tools/javac/diags/examples/EnumNoSubclassing.java + test/tools/javac/diags/examples/EnumTypesNotExtensible.java + test/tools/javac/diags/examples/EnumsMustBeStatic.java + test/tools/javac/diags/examples/EnumsNotSupported.java + test/tools/javac/diags/examples/ErrProcMessager/ErrProcMessager.java + test/tools/javac/diags/examples/ErrProcMessager/processors/AnnoProc.java + test/tools/javac/diags/examples/ErrSyntheticNameConflict.java + test/tools/javac/diags/examples/Error.java + test/tools/javac/diags/examples/ErrorReadingFile.java + test/tools/javac/diags/examples/ExceptAlreadyCaught.java + test/tools/javac/diags/examples/ExceptNeverThrown.java + test/tools/javac/diags/examples/Expected2.java + test/tools/javac/diags/examples/Expected3.java + test/tools/javac/diags/examples/FinalParamCantBeAssigned.java + test/tools/javac/diags/examples/FinallyCannotComplete.java + test/tools/javac/diags/examples/FinallyWithoutTry.java + test/tools/javac/diags/examples/FloatNumberTooLarge.java + test/tools/javac/diags/examples/FloatNumberTooSmall.java + test/tools/javac/diags/examples/ForeachNotApplicable.java + test/tools/javac/diags/examples/ForeachNotSupported.java + test/tools/javac/diags/examples/GenericArrayCreation.java + test/tools/javac/diags/examples/GenericThrowable.java + test/tools/javac/diags/examples/GenericsNotSupported.java + test/tools/javac/diags/examples/HasBeenDeprecated.java + test/tools/javac/diags/examples/IdentifierExpected.java + test/tools/javac/diags/examples/IllegalBytecodeIdentChar.java + test/tools/javac/diags/examples/IllegalChar.java + test/tools/javac/diags/examples/IllegalComboModifiers.java + test/tools/javac/diags/examples/IllegalEnumStaticRef.java + test/tools/javac/diags/examples/IllegalEscapeChar.java + test/tools/javac/diags/examples/IllegalForwardRef.java + test/tools/javac/diags/examples/IllegalInitializer.java + test/tools/javac/diags/examples/IllegalLineEndInCharLit.java + test/tools/javac/diags/examples/IllegalNonAsciiDigit.java + test/tools/javac/diags/examples/IllegalQualNotIcls.java + test/tools/javac/diags/examples/IllegalSelfRef.java + test/tools/javac/diags/examples/IllegalStartOfExpr.java + test/tools/javac/diags/examples/IllegalUnderscore.java + test/tools/javac/diags/examples/IllegalUnicodeEscape.java + test/tools/javac/diags/examples/ImportRequiresCanonical/ImportRequiresCanonical.java + test/tools/javac/diags/examples/ImportRequiresCanonical/p/Base.java + test/tools/javac/diags/examples/ImportRequiresCanonical/p/ExtendsBase.java + test/tools/javac/diags/examples/ImproperSVUID.java + test/tools/javac/diags/examples/ImproperTypeInnerRawParam.java + test/tools/javac/diags/examples/ImproperTypeParamMissing.java + test/tools/javac/diags/examples/IncomparableTypes.java + test/tools/javac/diags/examples/IncompatibleTypes1.java + test/tools/javac/diags/examples/InconvertibleTypes.java + test/tools/javac/diags/examples/InexactVarargsCall.java + test/tools/javac/diags/examples/InferredDoNotConformToBounds.java + test/tools/javac/diags/examples/InheritFromFinal.java + test/tools/javac/diags/examples/InitializerMustComplete.java + test/tools/javac/diags/examples/InnerClassCantHaveStatic.java + test/tools/javac/diags/examples/IntNumberTooLarge.java + test/tools/javac/diags/examples/InterfaceExpected.java + test/tools/javac/diags/examples/InterfaceNotAllowed.java + test/tools/javac/diags/examples/IntfAnnotationCantHaveTypeParams.java + test/tools/javac/diags/examples/IntfAnnotationMemberClash.java + test/tools/javac/diags/examples/IntfAnnotationsCantHaveParams.java + test/tools/javac/diags/examples/IntfAnnotationsCantHaveTypeParams.java + test/tools/javac/diags/examples/IntfMethodCantHaveBody.java + test/tools/javac/diags/examples/InvalidAnnoMemberType.java + test/tools/javac/diags/examples/InvalidBinaryNumber.java + test/tools/javac/diags/examples/InvalidHexNumber.java + test/tools/javac/diags/examples/InvalidInferredTypes.java + test/tools/javac/diags/examples/InvalidInstanceof.java + test/tools/javac/diags/examples/InvalidMethodDecl.java + test/tools/javac/diags/examples/KindnameClass.java + test/tools/javac/diags/examples/KindnameConstructor.java + test/tools/javac/diags/examples/KindnameMethod.java + test/tools/javac/diags/examples/KindnameVariable.java + test/tools/javac/diags/examples/LabelInUse.java + test/tools/javac/diags/examples/LocalEnum.java + test/tools/javac/diags/examples/LocalVarNeedsFinal.java + test/tools/javac/diags/examples/LongSVUID.java + test/tools/javac/diags/examples/MalformedFpLit.java + test/tools/javac/diags/examples/MalformedSupported/MalformedSupported.java + test/tools/javac/diags/examples/MalformedSupported/processors/AnnoProc.java + test/tools/javac/diags/examples/MethodDoesNotOverride.java + test/tools/javac/diags/examples/MightBeAssignedInLoop.java + test/tools/javac/diags/examples/MissingDeprecatedAnnotation.java + test/tools/javac/diags/examples/MissingMethodBody.java + test/tools/javac/diags/examples/MissingReturnStatement.java + test/tools/javac/diags/examples/MissingReturnValue.java + test/tools/javac/diags/examples/MissingSVUID.java + test/tools/javac/diags/examples/ModifierNotAllowed.java + test/tools/javac/diags/examples/MulticatchCantBeAssigned.java + test/tools/javac/diags/examples/MulticatchMustBeFinal.java + test/tools/javac/diags/examples/MulticatchNotSupported.java + test/tools/javac/diags/examples/NameClashSameErasure.java + test/tools/javac/diags/examples/NameClashSameErasureNoOverride.java + test/tools/javac/diags/examples/NativeMethodCantHaveBody.java + test/tools/javac/diags/examples/NeitherConditionalSubtype.java + test/tools/javac/diags/examples/NewNotAllowedInAnno.java + test/tools/javac/diags/examples/NoArgs.java + test/tools/javac/diags/examples/NoExplicitAnnoProcRequested.java + test/tools/javac/diags/examples/NoInterfaceExpected.java + test/tools/javac/diags/examples/NoInterfaceHere.java + test/tools/javac/diags/examples/NoJavaLang.java + test/tools/javac/diags/examples/NoSuperclass.java + test/tools/javac/diags/examples/NonStaticCantBeRef.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccess/NotDefAccessClassIntfCantAccess.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccess/p/C.java + test/tools/javac/diags/examples/NotDefPublicCantAccess/NotDefPublicCantAccess.java + test/tools/javac/diags/examples/NotDefPublicCantAccess/p/C.java + test/tools/javac/diags/examples/NotEnclClass.java + test/tools/javac/diags/examples/NotLoopLabel.java + test/tools/javac/diags/examples/NotWithinBounds.java + test/tools/javac/diags/examples/Note.java + test/tools/javac/diags/examples/NoteProcMessager/NoteProcMessager.java + test/tools/javac/diags/examples/NoteProcMessager/processors/AnnoProc.java + test/tools/javac/diags/examples/OperatorCantBeApplied.java + test/tools/javac/diags/examples/Orphaned.java + test/tools/javac/diags/examples/OverrideDoesntThrow.java + test/tools/javac/diags/examples/OverrideIncompatibleReturn.java + test/tools/javac/diags/examples/OverrideMeth.java + test/tools/javac/diags/examples/OverrideStatic.java + test/tools/javac/diags/examples/OverrideUncheckedReturn.java + test/tools/javac/diags/examples/OverrideUncheckedThrown.java + test/tools/javac/diags/examples/OverrideVarargsExtra.java + test/tools/javac/diags/examples/OverrideVarargsMissing.java + test/tools/javac/diags/examples/OverrideWeakerAccess.java + test/tools/javac/diags/examples/PackageAnnos.java + test/tools/javac/diags/examples/PackageInfoAlreadySeen/p/package-info.java + test/tools/javac/diags/examples/PackageInfoAlreadySeen/package-info.java + test/tools/javac/diags/examples/PathElementNotFound.java + test/tools/javac/diags/examples/PkgClashWithClass/p/q.java + test/tools/javac/diags/examples/PkgClashWithClass/p/q/C.java + test/tools/javac/diags/examples/PossibleFallThrough.java + test/tools/javac/diags/examples/PossibleLossPrecision.java + test/tools/javac/diags/examples/PrematureEOF.java + test/tools/javac/diags/examples/PrintProcessorInfo/PrintProcessorInfo.java + test/tools/javac/diags/examples/PrintProcessorInfo/processors/AnnoProc.java + test/tools/javac/diags/examples/PrintRounds/PrintRounds.java + test/tools/javac/diags/examples/PrintRounds/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcCantFindClass/ProcCantFindClass.java + test/tools/javac/diags/examples/ProcCantFindClass/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcFileReopening/ProcFileReopening.java + test/tools/javac/diags/examples/ProcFileReopening/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcIllegalFileName/ProcIllegalFileName.java + test/tools/javac/diags/examples/ProcIllegalFileName/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcIncompatibleSourceVersion/ProcIncompatibleSourceVersion.java + test/tools/javac/diags/examples/ProcIncompatibleSourceVersion/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcOnlyNoProcs.java + test/tools/javac/diags/examples/ProcPackageDoesNotExist/ProcPackageDoesNotExist.java + test/tools/javac/diags/examples/ProcPackageDoesNotExist/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcTypeRecreate/ProcTypeRecreate.java + test/tools/javac/diags/examples/ProcTypeRecreate/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUnclosedTypeFiles/ProcUnclosedTypeFiles.java + test/tools/javac/diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUseImplicit/ProcUseImplicit.java + test/tools/javac/diags/examples/ProcUseImplicit/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUseImplicit/sourcepath/p/SomeClass.java + test/tools/javac/diags/examples/ProcUseProcOrImplicit/ProcUseProcOrImplicit.java + test/tools/javac/diags/examples/ProcUseProcOrImplicit/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUseProcOrImplicit/sourcepath/p/SomeClass.java + test/tools/javac/diags/examples/ProcessorCantInstantiate/ProcessorCantInstantiate.java + test/tools/javac/diags/examples/ProcessorCantInstantiate/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcessorNotFound.java + test/tools/javac/diags/examples/ProcessorWrongType/ProcessorWrongType.java + test/tools/javac/diags/examples/ProcessorWrongType/processors/AnnoProc.java + test/tools/javac/diags/examples/QualifiedNewStaticClass.java + test/tools/javac/diags/examples/RawClassUse.java + test/tools/javac/diags/examples/RecursiveConstrInvocation.java + test/tools/javac/diags/examples/RedundantCast.java + test/tools/javac/diags/examples/RefAmbiguous.java + test/tools/javac/diags/examples/RepeatedAnnotationTarget.java + test/tools/javac/diags/examples/RepeatedInterface.java + test/tools/javac/diags/examples/RepeatedModifier.java + test/tools/javac/diags/examples/ReportAccess.java + test/tools/javac/diags/examples/ResourceClosed.java + test/tools/javac/diags/examples/ResourceMayNotBeAssigned.java + test/tools/javac/diags/examples/ResourceNotApplicableToType.java + test/tools/javac/diags/examples/ResourceNotReferenced.java + test/tools/javac/diags/examples/ReturnOutsideMethod.java + test/tools/javac/diags/examples/StaticImportNotSupported.java + test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/Other.java + test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/StaticImportOnlyClassesAndInterfaces.java + test/tools/javac/diags/examples/StaticNotQualifiedByType.java + test/tools/javac/diags/examples/StringConstRequired.java + test/tools/javac/diags/examples/StringSwitchNotSupported.java + test/tools/javac/diags/examples/SunApiFilename.java + test/tools/javac/diags/examples/SunApiFilenameAdditional.java + test/tools/javac/diags/examples/SunApiPlural/SunApiFilename.java + test/tools/javac/diags/examples/SunApiPlural/SunApiPlural.java + test/tools/javac/diags/examples/SunApiPluralAdditional/SunApiFilename.java + test/tools/javac/diags/examples/SunApiPluralAdditional/SunApiPlural.java + test/tools/javac/diags/examples/SunApiPluralAdditional/SunApiPluralAdditional.java + test/tools/javac/diags/examples/SunProprietary.java + test/tools/javac/diags/examples/SuperNotAllowedInEnum.java + test/tools/javac/diags/examples/ThrowsNotAllowedInAnno.java + test/tools/javac/diags/examples/TryResourceNotSupported.java + test/tools/javac/diags/examples/TryWithoutCatchOrFinally.java + test/tools/javac/diags/examples/TryWithoutCatchOrFinallyOrResource.java + test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java + test/tools/javac/diags/examples/TypeFoundRequired.java + test/tools/javac/diags/examples/TypeNoParams.java + test/tools/javac/diags/examples/TypeReqClassArray.java + test/tools/javac/diags/examples/TypeReqRef.java + test/tools/javac/diags/examples/TypeVarCantBeDeref.java + test/tools/javac/diags/examples/TypeVarMayNotBeFollowedByOtherBounds.java + test/tools/javac/diags/examples/TypesIncompatible.java + test/tools/javac/diags/examples/UncheckedAssign.java + test/tools/javac/diags/examples/UncheckedAssignToVar.java + test/tools/javac/diags/examples/UncheckedCall.java + test/tools/javac/diags/examples/UncheckedCast.java + test/tools/javac/diags/examples/UncheckedClash.java + test/tools/javac/diags/examples/UncheckedFilename.java + test/tools/javac/diags/examples/UncheckedFilenameAdditional.java + test/tools/javac/diags/examples/UncheckedGenericArrayCreation.java + test/tools/javac/diags/examples/UncheckedImplement.java + test/tools/javac/diags/examples/UncheckedMethodInvocation.java + test/tools/javac/diags/examples/UncheckedPlural/UncheckedFilename.java + test/tools/javac/diags/examples/UncheckedPlural/UncheckedPlural.java + test/tools/javac/diags/examples/UncheckedPluralAdditional/UncheckedFilename1.java + test/tools/javac/diags/examples/UncheckedPluralAdditional/UncheckedFilename2.java + test/tools/javac/diags/examples/UncheckedPluralAdditional/UncheckedPluralAdditional.java + test/tools/javac/diags/examples/UnclosedBytecodeIdent.java + test/tools/javac/diags/examples/UnclosedCharLiteral.java + test/tools/javac/diags/examples/UnclosedComment.java + test/tools/javac/diags/examples/UnclosedStringLiteral.java + test/tools/javac/diags/examples/UndefinedLabel.java + test/tools/javac/diags/examples/UndeterminedType1.java + test/tools/javac/diags/examples/UnmatchedProcessorOptions/UnmatchedProcessorOptions.java + test/tools/javac/diags/examples/UnmatchedProcessorOptions/processors/AnnoProc.java + test/tools/javac/diags/examples/UnnamedPackage.java + test/tools/javac/diags/examples/UnreachableStatement.java + test/tools/javac/diags/examples/UnreportedException.java + test/tools/javac/diags/examples/UnreportedExceptionDefaultConstructor.java + test/tools/javac/diags/examples/UnsupportedBinaryLiteral.java + test/tools/javac/diags/examples/UnsupportedEncoding.java + test/tools/javac/diags/examples/UnsupportedFpLit.java + test/tools/javac/diags/examples/UnsupportedUnderscoreLiteral.java + test/tools/javac/diags/examples/VarMightAlreadyBeAssigned.java + test/tools/javac/diags/examples/VarMightNotHaveBeenInitialized.java + test/tools/javac/diags/examples/VarargsClash.java + test/tools/javac/diags/examples/VarargsFilename.java + test/tools/javac/diags/examples/VarargsFilenameAdditional.java + test/tools/javac/diags/examples/VarargsImplement.java + test/tools/javac/diags/examples/VarargsNonReifiableType.java + test/tools/javac/diags/examples/VarargsNotSupported.java + test/tools/javac/diags/examples/VarargsOverride.java + test/tools/javac/diags/examples/VarargsPlural/VarargsFilename.java + test/tools/javac/diags/examples/VarargsPlural/VarargsPlural.java + test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsFilename.java + test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPlural.java + test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPluralAdditional.java + test/tools/javac/diags/examples/Verbose.java + test/tools/javac/diags/examples/VoidNotAllowed.java + test/tools/javac/diags/examples/WarnForwardRef.java + test/tools/javac/diags/examples/WarnProcMessager/WarnProcMessager.java + test/tools/javac/diags/examples/WarnProcMessager/processors/AnnoProc.java + test/tools/javac/diags/examples/WarnSelfRef.java + test/tools/javac/diags/examples/WarnSyntheticNameConflict.java + test/tools/javac/diags/examples/WarningAndWerror.java + test/tools/javac/diags/examples/WhereCaptured.java + test/tools/javac/diags/examples/WhereCaptured1.java + test/tools/javac/diags/examples/WhereIntersection.java + test/tools/javac/diags/examples/WhereTypeVar.java + test/tools/javac/diags/examples/WrongNumberTypeArgs.java Changeset: 4172cfff05f0 Author: jjg Date: 2010-07-26 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/4172cfff05f0 6971882: Remove -XDstdout from javac test Reviewed-by: darcy ! test/tools/javac/4980495/static/Test.java ! test/tools/javac/4980495/std/Test.java ! test/tools/javac/6304921/T6304921.java ! test/tools/javac/6330920/T6330920.java ! test/tools/javac/6491592/T6491592.java ! test/tools/javac/6717241/T6717241a.java ! test/tools/javac/6717241/T6717241b.java ! test/tools/javac/ClassFileModifiers/ClassModifiers.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java ! test/tools/javac/CyclicInheritance.java ! test/tools/javac/Digits.java ! test/tools/javac/ExtendArray.java ! test/tools/javac/ExtendsAccess/ExtendsAccess.java ! test/tools/javac/FloatingPointChanges/BadConstructorModifiers.java ! test/tools/javac/IllegalAnnotation.java ! test/tools/javac/InnerNamedConstant_2.java ! test/tools/javac/InterfaceMemberClassModifiers.java ! test/tools/javac/LocalClasses_2.java ! test/tools/javac/NameCollision.java ! test/tools/javac/NestedInnerClassNames.java ! test/tools/javac/NonStaticFieldExpr1.java ! test/tools/javac/NonStaticFieldExpr2.java ! test/tools/javac/NonStaticFieldExpr3.java ! test/tools/javac/OverridePosition.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_1.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_2.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_3.java ! test/tools/javac/StringsInSwitch/BadlyTypedLabel1.java ! test/tools/javac/StringsInSwitch/BadlyTypedLabel2.java ! test/tools/javac/StringsInSwitch/NonConstantLabel.java ! test/tools/javac/StringsInSwitch/RepeatedStringCaseLabels1.java ! test/tools/javac/StringsInSwitch/RepeatedStringCaseLabels2.java ! test/tools/javac/SynchronizedClass.java ! test/tools/javac/T4093617/T4093617.java ! test/tools/javac/T4906100.java ! test/tools/javac/T4994049/T4994049.java ! test/tools/javac/T5003235/T5003235a.java ! test/tools/javac/T5003235/T5003235b.java ! test/tools/javac/T5003235/T5003235c.java ! test/tools/javac/T5024091/T5024091.java ! test/tools/javac/T5048776.java ! test/tools/javac/T6214885.java ! test/tools/javac/T6224167.java ! test/tools/javac/T6227617.java ! test/tools/javac/T6230128.java ! test/tools/javac/T6231847.java ! test/tools/javac/T6241723.java ! test/tools/javac/T6245591.java ! test/tools/javac/T6247324.java ! test/tools/javac/T6394563.java ! test/tools/javac/annotations/6214965/T6214965.java ! test/tools/javac/annotations/6365854/T6365854.java ! test/tools/javac/danglingDep/DepX.java ! test/tools/javac/danglingDep/NoDepX.java ! test/tools/javac/danglingDep/Test1.java ! test/tools/javac/depDocComment/DeprecatedDocComment.java ! test/tools/javac/depDocComment/SuppressDeprecation.java ! test/tools/javac/depOverrides/annotation/Test1.java ! test/tools/javac/depOverrides/annotation/Test2.java ! test/tools/javac/depOverrides/annotation/Test3.java ! test/tools/javac/depOverrides/doccomment/Test1.java ! test/tools/javac/depOverrides/doccomment/Test2.java ! test/tools/javac/depOverrides/doccomment/Test3.java ! test/tools/javac/enum/6384542/T6384542.java ! test/tools/javac/enum/6384542/T6384542a.java ! test/tools/javac/enum/forwardRef/T6425594.java ! test/tools/javac/generics/5009937/T5009937.java ! test/tools/javac/generics/6207386/T6207386.java ! test/tools/javac/generics/6359951/T6359951.java ! test/tools/javac/generics/6677785/T6677785.java ! test/tools/javac/generics/6723444/T6723444.java ! test/tools/javac/generics/inference/6611449/T6611449.java ! test/tools/javac/generics/inference/6718364/T6718364.java ! test/tools/javac/generics/wildcards/6437894/T6437894.java ! test/tools/javac/lint/NoWarn.java ! test/tools/javac/mandatoryWarnings/deprecated/Test.java ! test/tools/javac/mandatoryWarnings/unchecked/Test.java ! test/tools/javac/miranda/T4666866.java ! test/tools/javac/missingSuperRecovery/MissingSuperRecovery.java ! test/tools/javac/policy/test1/Test1a.java ! test/tools/javac/policy/test2/Test.java ! test/tools/javac/positions/T6253161.java ! test/tools/javac/positions/T6253161a.java ! test/tools/javac/positions/T6264029.java ! test/tools/javac/processing/messager/6362067/T6362067.java ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess2.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess3.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess4.java ! test/tools/javac/rawDiags/Error.java ! test/tools/javac/rawDiags/Note.java ! test/tools/javac/rawDiags/Warning.java ! test/tools/javac/unicode/UnicodeNewline.java ! test/tools/javac/warnings/Deprecation.java ! test/tools/javac/warnings/DivZero.java ! test/tools/javac/warnings/FallThrough.java ! test/tools/javac/warnings/Unchecked.java Changeset: d1bd93028447 Author: jjg Date: 2010-07-26 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d1bd93028447 6957438: improve code for generating warning messages containing option names Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! test/tools/javac/diags/examples/CountWarn.java ! test/tools/javac/diags/examples/CountWarnPlural.java ! test/tools/javac/diags/examples/Error.java Changeset: b29160d1b3e0 Author: jjg Date: 2010-07-27 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/b29160d1b3e0 6972327: JCTree.pos incorrect for annotations without modifiers and package Reviewed-by: mcimadamore Contributed-by: jan.lahoda at sun.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/T6972327.java Changeset: ed354a00f76b Author: jjg Date: 2010-07-27 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ed354a00f76b 6403456: -Werror should work with annotation processing Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/werror/WError1.java + test/tools/javac/processing/werror/WError1.out + test/tools/javac/processing/werror/WErrorGen.java + test/tools/javac/processing/werror/WErrorGen.out + test/tools/javac/processing/werror/WErrorLast.java + test/tools/javac/processing/werror/WErrorLast.out Changeset: 36c4ec4525b4 Author: mcimadamore Date: 2010-07-29 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/36c4ec4525b4 6938454: Unable to determine generic type in program that compiles under Java 6 Summary: a redundant dubtyping check causes spurious inference failure Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6938454/T6938454a.java + test/tools/javac/generics/inference/6938454/T6938454b.java Changeset: e79e8efe1b3e Author: mcimadamore Date: 2010-07-29 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e79e8efe1b3e 6972747: CheckExamples fail when assertions are enabled Summary: The test calls the wrong version of JavacMessage constructor Reviewed-by: jjg ! test/tools/javac/diags/Example.java Changeset: 62f3f07002ea Author: mcimadamore Date: 2010-07-29 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/62f3f07002ea 6970833: Try-with-resource implementation throws an NPE during Flow analysis Summary: Updated logic not to rely upon Symbol.implementation (which check in superinterfaces) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/TryWithResources/ResourceInterface.java + test/tools/javac/TryWithResources/ResourceInterface.out Changeset: 4a7979c3ce15 Author: jjg Date: 2010-07-29 18:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/4a7979c3ce15 6972556: warning for using a file name instead of a binary name for Filer.createSourceFile Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ProcSuspiciousClassName/ProcSuspiciousClassName.java + test/tools/javac/diags/examples/ProcSuspiciousClassName/processors/AnnoProc.java Changeset: 8a5c98a695ae Author: jjg Date: 2010-07-29 19:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/8a5c98a695ae 6340549: javax.tools.JavaCompilerTool.getStandardFileManager().list() includes directories Reviewed-by: darcy + test/tools/javac/T6340549.java Changeset: 2cf925ad67ab Author: jjg Date: 2010-07-29 19:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/2cf925ad67ab 6966604: JavacFiler not correctly notified of lastRound Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/ProcFileCreateLastRound/ProcFileCreateLastRound.java + test/tools/javac/diags/examples/ProcFileCreateLastRound/processors/AnnoProc.java + test/tools/javac/processing/filer/TestLastRound.java + test/tools/javac/processing/filer/TestLastRound.out ! test/tools/javac/processing/werror/WErrorGen.java Changeset: 077eb94c912d Author: lana Date: 2010-07-29 22:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/077eb94c912d Merge Changeset: 38e2c23309f1 Author: darcy Date: 2010-08-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/38e2c23309f1 6971877: Project Coin: improve semantics of suppressed exceptions in try-with-resources Reviewed-by: jjb + test/tools/javac/TryWithResources/TwrSuppression.java Changeset: 6318230cdb82 Author: jjg Date: 2010-08-02 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6318230cdb82 6973626: test/tools/javac/processing/* tests fail with assertions enabled Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: 186feb2042f0 Author: lana Date: 2010-08-02 19:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/186feb2042f0 Merge Changeset: aaecac256d39 Author: lana Date: 2010-08-09 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/aaecac256d39 Merge Changeset: 112fcc00659d Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/112fcc00659d Added tag jdk7-b105 for changeset aaecac256d39 ! .hgtags Changeset: 2c1c657f69a4 Author: cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/2c1c657f69a4 Added tag jdk7-b106 for changeset 112fcc00659d ! .hgtags Changeset: a408ebb8b3d4 Author: cl Date: 2010-08-26 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/a408ebb8b3d4 Added tag jdk7-b107 for changeset 2c1c657f69a4 ! .hgtags Changeset: 0fe472f4a332 Author: mcimadamore Date: 2010-08-05 09:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/0fe472f4a332 6881115: javac permits nested anno w/o mandatory attrs => IncompleteAnnotationException Summary: default annotation value is not attributed Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/6881115/T6881115.java + test/tools/javac/annotations/6881115/T6881115.out Changeset: 237f3bd52242 Author: mcimadamore Date: 2010-08-05 09:45 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/237f3bd52242 6857948: Calling a constructor with a doubly bogus argument causes an internal error Summary: problem when constructor resolution returns an erroneous symbol Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/6857948/T6857948.java + test/tools/javac/6857948/T6857948.out Changeset: a2d8c7071f24 Author: mcimadamore Date: 2010-08-10 14:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/a2d8c7071f24 6975275: diamond implementation needs some cleanup Summary: resolution issues during diamond inference should be reported through Resolve.logResolveError() Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: ea1930f4b789 Author: mcimadamore Date: 2010-08-10 14:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ea1930f4b789 6975231: Regression test for 6881115 is failing with compiler output not matching expected output Summary: missing symbols are collected in an HashSet which doesn't preserve ordering 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/annotations/6881115/T6881115.out + test/tools/javac/diags/examples/AnnotationMissingValues1.java Changeset: c04ae2714f52 Author: lana Date: 2010-08-12 19:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c04ae2714f52 Merge Changeset: 27bae58329d5 Author: mcimadamore Date: 2010-08-16 14:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/27bae58329d5 6976649: javac does not enforce required annotation elements in arrays Summary: type annotation should take advantage of recursive annotation checking Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/annotations/6881115/T6881115.java ! test/tools/javac/annotations/6881115/T6881115.out ! test/tools/javac/annotations/pos/TrailingComma.java Changeset: dc550520ed6f Author: mcimadamore Date: 2010-08-16 14:58 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/dc550520ed6f 6369605: Unconstrained type variables fails to include bounds Summary: unconstrained type-variables with recursive bounds are not inferred properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/InvalidInferredTypes.java + test/tools/javac/generics/inference/6369605/T6369605a.java + test/tools/javac/generics/inference/6369605/T6369605b.java ! test/tools/javac/generics/inference/6638712/T6638712a.out Changeset: a31c511db424 Author: jjg Date: 2010-08-16 14:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/a31c511db424 6976833: options included twice in Example SimpleCompiler Reviewed-by: darcy ! test/tools/javac/diags/Example.java Changeset: c655e0280bdc Author: mcimadamore Date: 2010-08-19 11:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c655e0280bdc 6886247: regression: javac crashes with an assertion error in Attr.java Summary: capture conversion does not work on nested types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/wildcards/6886247/T6886247_1.java + test/tools/javac/generics/wildcards/6886247/T6886247_2.java + test/tools/javac/generics/wildcards/6886247/T6886247_2.out Changeset: d6fe0ea070aa Author: mcimadamore Date: 2010-08-19 11:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d6fe0ea070aa 6885255: Improve usability of raw warnings Summary: raw warnings should be disabled in (i) instanceof expressions and (ii) when java.lang.Class is not parameterized Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/warnings/6747671/T6747671.java ! test/tools/javac/warnings/6747671/T6747671.out + test/tools/javac/warnings/6885255/T6885255.java + test/tools/javac/warnings/6885255/T6885255.out Changeset: a75770c0d7f6 Author: mcimadamore Date: 2010-08-19 11:54 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/a75770c0d7f6 6977800: Regression: invalid resolution of supertype for local class Summary: resolution of superclass/superinterfaces in extends/implements clause skips local classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/T6977800.java ! test/tools/javac/generics/typevars/5060485/Compatibility.java + test/tools/javac/generics/typevars/5060485/Compatibility.out + test/tools/javac/generics/typevars/5060485/Compatibility02.java + test/tools/javac/generics/typevars/5060485/Compatibility02.out Changeset: 995bcdb9a41d Author: mcimadamore Date: 2010-08-23 16:59 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/995bcdb9a41d 6932571: Compiling Generics causing Inconvertible types Summary: Types.rewriteQuantifiers() does not work well with recursive type-variable bounds Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/6270087/T6270087.java + test/tools/javac/cast/6270087/T6270087neg.java + test/tools/javac/cast/6270087/T6270087neg.out + test/tools/javac/cast/6507317/T6507317.java + test/tools/javac/cast/6569057/T6569057.java + test/tools/javac/cast/6932571/T6932571a.java + test/tools/javac/cast/6932571/T6932571b.java + test/tools/javac/cast/6932571/T6932571neg.java + test/tools/javac/cast/6932571/T6932571neg.out Changeset: 594b3c2ef585 Author: mcimadamore Date: 2010-08-23 17:00 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/594b3c2ef585 6978574: return statement in try block with multi-catch causes ClassFormatError Summary: Wrong nested loops in Gen.java causes javac to generate bad bytecode Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/multicatch/T6978574.java Changeset: 6b95dd682538 Author: jjg Date: 2010-08-23 11:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6b95dd682538 6975005: improve JavacProcessingEnvironment.Round abstraction Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/T6358024.java ! test/tools/javac/T6403466.out ! test/tools/javac/processing/filer/TestLastRound.out Changeset: a626d8c1de6e Author: jjg Date: 2010-08-23 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/a626d8c1de6e 6976747: JCDiagnostic: replace "boolean mandatory" with new "Set" Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java Changeset: 0c81bff15ced Author: lana Date: 2010-08-23 19:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/0c81bff15ced Merge Changeset: ba774f919ad0 Author: lana Date: 2010-08-29 22:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ba774f919ad0 Merge From christian.thalinger at oracle.com Thu Sep 9 10:29:17 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 09 Sep 2010 19:29:17 +0200 Subject: hg: jdk7/hotspot-comp/hotspot: 6953144: Tiered compilation In-Reply-To: <1284047421.6836.1.camel@macbook> References: <20100904033018.E2D9C476EA@hg.openjdk.java.net> <1284047421.6836.1.camel@macbook> Message-ID: <1284053357.6836.3.camel@macbook> On Thu, 2010-09-09 at 17:50 +0200, Christian Thalinger wrote: > On Sat, 2010-09-04 at 03:30 +0000, igor.veresov at oracle.com wrote: > > Changeset: d5d065957597 > > Author: iveresov > > Date: 2010-09-03 17:51 -0700 > > URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d5d065957597 > > > > 6953144: Tiered compilation > > Summary: Infrastructure for tiered compilation support (interpreter + c1 + c2) for 32 and 64 bit. Simple tiered policy implementation. > > Reviewed-by: kvn, never, phh, twisti > > Actually I don't understand why this happens for me with fastdebug and > debug builds and it does not for JPRT: > > Compiling /home/twisti/hotspot-comp/hotspot/src/share/vm/runtime/java.cpp > /home/twisti/hotspot-comp/hotspot/src/share/vm/runtime/java.cpp: In function 'void print_statistics()': > /home/twisti/hotspot-comp/hotspot/src/share/vm/runtime/java.cpp:201: error: 'C1UpdateMethodData' was not declared in this scope Well, of course it was something pre-built (precompiled headers? But I thought that was fixed). After removing the build directory everything is fine. Sorry for the noise. -- Christian From Christian.Thalinger at Sun.COM Thu Sep 9 10:40:45 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 09 Sep 2010 17:40:45 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6934483: GCC 4.5 errors "suggest parentheses around something..." when compiling with -Werror and -Wall Message-ID: <20100909174047.3992F47851@hg.openjdk.java.net> Changeset: a83b0246bb77 Author: twisti Date: 2010-09-09 05:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a83b0246bb77 6934483: GCC 4.5 errors "suggest parentheses around something..." when compiling with -Werror and -Wall Summary: These are minor changes fixing compile failure when -Wall -Werror flags are used under gcc 4.5. Reviewed-by: twisti, kvn, rasbold Contributed-by: Pavel Tisnovsky ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/utilities/globalDefinitions.hpp From john.r.rose at oracle.com Fri Sep 10 01:47:45 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 10 Sep 2010 01:47:45 -0700 Subject: preliminary review (L): 6939861: JVM should handle more conversion operations Message-ID: This is the JVM infrastructure for pushing a stack frame *during* a method handle call, so that some sort of intermediate fixup operation can be done before completing the call. The requirement is that a recognizable stack frame be pushed during the intermediate fixup operation, so that if there is an exception, or a GC, or some other stack walk, the stack will be parsed properly. Crucially, the pending arguments must be recognized as managed pointers. This is a preliminary review, because it shows just the new stack frame type, rather than the use cases (which are forthcoming). 6939861: JVM should handle more conversion operations http://cr.openjdk.java.net/~jrose/6939861/webrev.00/ -- John From igor.veresov at oracle.com Fri Sep 10 16:24:04 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 10 Sep 2010 16:24:04 -0700 Subject: Request for review(M): 6919069: client compiler needs to capture more profile information for tiered work Message-ID: <4C8ABE14.6040306@oracle.com> Added profiling of instanceof and aastore. Webrev: http://cr.openjdk.java.net/~iveresov/6919069/webrev.00/ Thanks, igor From igor.veresov at oracle.com Fri Sep 10 19:37:16 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 10 Sep 2010 19:37:16 -0700 Subject: Request for review(XXS): 6984056: C1: incorrect code for integer constant addition on x64 Message-ID: <4C8AEB5C.20803@oracle.com> C1 generates incorrect code for addition of a constant to an int. Instead of emitting a 32bit arithmetic operation it does 64bit. That causes usage of the upper bits instead of overflowing, which causes incorrect results. Tested with the failing nightly test. Webrev: http://cr.openjdk.java.net/~iveresov/6984056/webrev.00/ Thanks, igor From vladimir.kozlov at oracle.com Fri Sep 10 20:03:58 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Sep 2010 20:03:58 -0700 Subject: Request for review(XXS): 6984056: C1: incorrect code for integer constant addition on x64 In-Reply-To: <4C8AEB5C.20803@oracle.com> References: <4C8AEB5C.20803@oracle.com> Message-ID: <4C8AF19E.6030702@oracle.com> Looks good. Vladimir On 9/10/10 7:37 PM, Igor Veresov wrote: > C1 generates incorrect code for addition of a constant to an int. Instead of emitting a 32bit arithmetic operation it > does 64bit. That causes usage of the upper bits instead of overflowing, which causes incorrect results. > > Tested with the failing nightly test. > > Webrev: http://cr.openjdk.java.net/~iveresov/6984056/webrev.00/ > > > Thanks, > igor From igor.veresov at oracle.com Sat Sep 11 00:14:14 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Sat, 11 Sep 2010 00:14:14 -0700 Subject: Request for review(XXS): 6984056: C1: incorrect code for integer constant addition on x64 In-Reply-To: <4C8AF19E.6030702@oracle.com> References: <4C8AEB5C.20803@oracle.com> <4C8AF19E.6030702@oracle.com> Message-ID: <4C8B2C46.1090700@oracle.com> Thanks, Vladimir! On 9/10/10 8:03 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 9/10/10 7:37 PM, Igor Veresov wrote: >> C1 generates incorrect code for addition of a constant to an int. >> Instead of emitting a 32bit arithmetic operation it >> does 64bit. That causes usage of the upper bits instead of >> overflowing, which causes incorrect results. >> >> Tested with the failing nightly test. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6984056/webrev.00/ >> >> >> Thanks, >> igor From igor.veresov at oracle.com Sat Sep 11 17:21:55 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sun, 12 Sep 2010 00:21:55 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6984056: C1: incorrect code for integer constant addition on x64 Message-ID: <20100912002157.944BB478EA@hg.openjdk.java.net> Changeset: 7f9553bedfd5 Author: iveresov Date: 2010-09-11 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7f9553bedfd5 6984056: C1: incorrect code for integer constant addition on x64 Summary: Fix add/sub of constants to ints on x64 Reviewed-by: kvn ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp From john.r.rose at oracle.com Sun Sep 12 03:11:22 2010 From: john.r.rose at oracle.com (John Rose) Date: Sun, 12 Sep 2010 03:11:22 -0700 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 Message-ID: 6981777: implement JSR 292 EG adjustments from summer 2010 Summary: Introduce one more constant pool type, CONSTANT_MethodApply. This JVM change implements a mechanism which supports computed constants and parameterized bootstrap methods: http://cr.openjdk.java.net/~jrose/6981777/webrev.00 The JVM change supplies a "hook" for memoizing library-defined constants in the constant pool. The actual semantics of the hook (which combines a "function" constant with an "argument" constant) will be defined by a JDK runtime routine which invokes the function on the argument if it is a unary function, and otherwise calls MethodHandles.bindTo, effectually treating the function as if it were curried. The code will be something like: apply(fun,arg) := fun.type.parameterCount == 1 ? fun.invokeGeneric(arg) : fun.bindTo(arg); Combined with the pre-existing CONSTANT_MethodHandle constant pool entries, this provides a way to get a wide variety of computed constants. Although it may seem odd to allow only one argument (and use the bindTo function to collect multiple arguments) this design matches better with the binary constant pool structure already commonly built into JVMs, including both the HotSpot and IBM JVMs. The JVM change includes logic to ensure that if the initial computation of a constant causes an exception, this exception will be uniformly thrown from all points where it is referenced. This logic applies to pre-existing constants also. Motivation: Parameterized bootstrap methods seem to be required for factoring closures and similar data structures into distinct static and dynamic specifications. The computed constants allow explicit one-time computation of static information, to be used by an ldc or a bootstrap method or both. Such "live constants" were a request from dynamic language implementors at the Summit. A key use case for one-time computation appears to be representation selection for closures. This is best done in a runtime (decoupled from the bytecode compiler), but should not be done on every closure creation. The invokedynamic instruction can use bootstrap methods with additional parameters supplied by this mechanism to combine prepared closure bodies with closure parameters. The same pattern can also be used by other language implementations which also need to combine static with dynamic data. -- John P.S. I expect one more significant JVM change coming this week: It is the hook for MethodHandles.invokeGeneric, which enables the JVM to perform dynamic argument transformations during method handle invocations. From john.r.rose at oracle.com Sun Sep 12 03:18:32 2010 From: john.r.rose at oracle.com (John Rose) Date: Sun, 12 Sep 2010 03:18:32 -0700 Subject: review request (L): 6939224 MethodHandle.invokeGeneric needs to perform the correct set of conversions Message-ID: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> 6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions Until now, the HotSpot JVM has conflated invokeExact with invokeGeneric. These changes, combined with forthcoming JDK runtime support changes, provide a hook for the JVM to perform on-the-fly argument conversions in invokeGeneric calls, as specified by the JSR 292 EG. http://cr.openjdk.java.net/~jrose/6939224/webrev.00/ This review is for the JDK parts, which (a) distinguishes correctly between the two invocation modes, and (b) performs an upcall to Java code when argument types need matching. -- John From David.Holmes at oracle.com Sun Sep 12 16:14:29 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 13 Sep 2010 09:14:29 +1000 Subject: help on instruction scheduling of hotspot jvm In-Reply-To: <29693457.post@talk.nabble.com> References: <29693457.post@talk.nabble.com> Message-ID: <4C8D5ED5.8080108@oracle.com> ddmetro said the following on 09/13/10 08:14: > I am working on multithreaded instruction scheduling on hotspot jvm. I have > built the source code, however I have the following doubts: > > 1. I tried to look into instruction scheduling pass of Hotspot, but couldn't > find any paper related to the same. Can you please direct me towards a paper > that talks about instruction scheduling and thread scheduling in hotspot > jvm. Don't know about instruction scheduling (which is a compiler issue) but thread scheduling is basically done using the OS default scheduling mechanism. There are some settings you can adjust to change this, and you can do things externally (ie run the JVM in particular scheduling class) but they are not recommended and need to be used with extreme care. Dave Dice has some blog articles on this: http://blogs.sun.com/dave/entry/java_thread_priority_revisted_in > 2. I executed an applet using the j2sdk image's appletviewer. However, I am > not able to get the starting point (main() method) for the same. Kindly > provide the starting point. Applets don't have a main() method. Applets are executed by a framework and it is the framework that has the main() method. You'd have to look at the AppletViewer class in this case. > 3. I am assuming that the instruction scheduling will be done by the server > side hotspot jvm and not the compiler (C2). Kindly confirm if my > understanding is correct. The Hotspot "server" VM is the Hotspot VM configured to run the C2 compiler. (The "client" VM runs the C1 compiler). Any instruction scheduling would be done by the compiler, but questions on this are better addressed to hotspot-compiler-dev - cc'ed. > Also, I tried to search for documentation that maps the different > phases(instruction scheduling, register allocation, etc) with the source > code classes. However I wasn't able to find one. Kindly direct me to such > documentation, if one exists. There is not a lot of documentation for hotspot internals in general. Again the compiler folk may be able to point you to documents or blog entries that discuss this. HTH David Holmes > Thanking You, > -Dhiraj. From dmdabbs at gmail.com Sun Sep 12 21:50:57 2010 From: dmdabbs at gmail.com (David Dabbs) Date: Sun, 12 Sep 2010 23:50:57 -0500 Subject: Question regarding the (x86) assembler's use of NOP Message-ID: <006301cb52ff$421ebd40$c65c37c0$@com> Hi. I've been trying to trace PrintAssembly output back to the HS assembler. I noticed that the NOP generation code differs from the Intel recommendations and was wondering if someone could comment on the discrepancies. Thanks, David The Intel Arch Optimization Guide recommends the following regarding NOPs: 3.5.1.8 Using NOPs Code generators generate a no-operation (NOP) to align instructions. Examples of NOPs of different lengths in 32-bit mode are shown below: 1-byte: XCHG EAX, EAX 2-byte: 66 NOP 3-byte: LEA REG, 0 (REG) (8-bit displacement) 4-byte: NOP DWORD PTR [EAX + 0] (8-bit displacement) 5-byte: NOP DWORD PTR [EAX + EAX*1 + 0] (8-bit displacement) 6-byte: LEA REG, 0 (REG) (32-bit displacement) 7-byte: NOP DWORD PTR [EAX + 0] (32-bit displacement) 8-byte: NOP DWORD PTR [EAX + EAX*1 + 0] (32-bit displacement) 9-byte: NOP WORD PTR [EAX + EAX*1 + 0] (32-bit displacement) These are all true NOPs, having no effect on the state of the machine except to advance the EIP. Because NOPs require hardware resources to decode and execute, use the fewest number to achieve the desired padding. The one byte NOP:[XCHG EAX,EAX] has special hardware support. Although it still consumes a ?op and its accompanying resources, the dependence upon the old value of EAX is removed. This ?op can be executed at the earliest possible opportunity, reducing the number of outstanding instructions and is the lowest cost NOP. The other NOPs have no special hardware support. Their input and output registers are interpreted by the hardware. Therefore, a code generator should arrange to use the register containing the oldest value as input, so that the NOP will dispatch and release RS resources at the earliest possible opportunity. Try to observe the following NOP generation priority. Select: * the smallest number of NOPs and pseudo-NOPs to provide the desired padding. * NOPs that are least likely to execute on slower execution unit clusters. * the register arguments of NOPs to reduce dependencies. // end Intel Arch --------------------------- The code in assembler_x86.cpp however issues NOPs using: void Assembler::nop(int i) { #ifdef ASSERT assert(i > 0, " "); // The fancy nops aren't currently recognized by debuggers making it a // pain to disassemble code while debugging. If asserts are on clearly // speed is not an issue so simply use the single byte traditional nop // to do alignment. for (; i > 0 ; i--) emit_byte(0x90); return; #endif // ASSERT if (UseAddressNop && VM_Version::is_intel()) { // // Using multi-bytes nops "0x0F 0x1F [address]" for Intel // 1: 0x90 // 2: 0x66 0x90 // 3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding) // 4: 0x0F 0x1F 0x40 0x00 // 5: 0x0F 0x1F 0x44 0x00 0x00 // 6: 0x66 0x0F 0x1F 0x44 0x00 0x00 // 7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 // 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 // 9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 // The rest coding is Intel specific - don't use consecutive address nops // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 while(i >= 15) { // For Intel don't generate consecutive addess nops (mix with regular nops) i -= 15; emit_byte(0x66); // size prefix emit_byte(0x66); // size prefix emit_byte(0x66); // size prefix addr_nop_8(); emit_byte(0x66); // size prefix emit_byte(0x66); // size prefix emit_byte(0x66); // size prefix emit_byte(0x90); // nop } switch (i) { case 14: emit_byte(0x66); // size prefix case 13: emit_byte(0x66); // size prefix case 12: addr_nop_8(); emit_byte(0x66); // size prefix emit_byte(0x66); // size prefix emit_byte(0x66); // size prefix emit_byte(0x90); // nop break; case 11: emit_byte(0x66); // size prefix case 10: emit_byte(0x66); // size prefix case 9: emit_byte(0x66); // size prefix case 8: addr_nop_8(); break; case 7: addr_nop_7(); break; case 6: emit_byte(0x66); // size prefix case 5: addr_nop_5(); break; case 4: addr_nop_4(); break; case 3: // Don't use "0x0F 0x1F 0x00" - need patching safe padding emit_byte(0x66); // size prefix case 2: emit_byte(0x66); // size prefix case 1: emit_byte(0x90); // nop break; default: assert(i == 0, " "); } return; } void Assembler::addr_nop_4() { // 4 bytes: NOP DWORD PTR [EAX+0] emit_byte(0x0F); emit_byte(0x1F); emit_byte(0x40); // emit_rm(cbuf, 0x1, EAX_enc, EAX_enc); emit_byte(0); // 8-bits offset (1 byte) } void Assembler::addr_nop_5() { // 5 bytes: NOP DWORD PTR [EAX+EAX*0+0] 8-bits offset emit_byte(0x0F); emit_byte(0x1F); emit_byte(0x44); // emit_rm(cbuf, 0x1, EAX_enc, 0x4); emit_byte(0x00); // emit_rm(cbuf, 0x0, EAX_enc, EAX_enc); emit_byte(0); // 8-bits offset (1 byte) } void Assembler::addr_nop_7() { // 7 bytes: NOP DWORD PTR [EAX+0] 32-bits offset emit_byte(0x0F); emit_byte(0x1F); emit_byte(0x80); // emit_rm(cbuf, 0x2, EAX_enc, EAX_enc); emit_long(0); // 32-bits offset (4 bytes) } void Assembler::addr_nop_8() { // 8 bytes: NOP DWORD PTR [EAX+EAX*0+0] 32-bits offset emit_byte(0x0F); emit_byte(0x1F); emit_byte(0x84); // emit_rm(cbuf, 0x2, EAX_enc, 0x4); emit_byte(0x00); // emit_rm(cbuf, 0x0, EAX_enc, EAX_enc); emit_long(0); // 32-bits offset (4 bytes) } From vladimir.kozlov at oracle.com Sun Sep 12 23:10:29 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 12 Sep 2010 23:10:29 -0700 Subject: Question regarding the (x86) assembler's use of NOP In-Reply-To: <006301cb52ff$421ebd40$c65c37c0$@com> References: <006301cb52ff$421ebd40$c65c37c0$@com> Message-ID: <4C8DC055.7030106@oracle.com> David, LEA NOPs have register dependency. '0x0F 0x1F' is fast multi-byte NOP: Intel? 64 and IA-32 Architectures Software Developer's Manual Volume 2B: Instruction Set Reference, N-Z Vladimir On 9/12/10 9:50 PM, David Dabbs wrote: > Hi. > > I've been trying to trace PrintAssembly output back to the HS assembler. > I noticed that the NOP generation code differs from the Intel > recommendations and was > wondering if someone could comment on the discrepancies. > > > Thanks, > > David > > > > The Intel Arch Optimization Guide recommends the following regarding NOPs: > > 3.5.1.8 Using NOPs > Code generators generate a no-operation (NOP) to align instructions. > Examples of NOPs of different lengths in 32-bit mode are shown below: > > 1-byte: XCHG EAX, EAX > 2-byte: 66 NOP > 3-byte: LEA REG, 0 (REG) (8-bit displacement) > 4-byte: NOP DWORD PTR [EAX + 0] (8-bit displacement) > 5-byte: NOP DWORD PTR [EAX + EAX*1 + 0] (8-bit displacement) > 6-byte: LEA REG, 0 (REG) (32-bit displacement) > 7-byte: NOP DWORD PTR [EAX + 0] (32-bit displacement) > 8-byte: NOP DWORD PTR [EAX + EAX*1 + 0] (32-bit displacement) > 9-byte: NOP WORD PTR [EAX + EAX*1 + 0] (32-bit displacement) > > These are all true NOPs, having no effect on the state of the machine except > to > advance the EIP. Because NOPs require hardware resources to decode and > execute, > use the fewest number to achieve the desired padding. > > The one byte NOP:[XCHG EAX,EAX] has special hardware support. Although it > still > consumes a ?op and its accompanying resources, the dependence upon the old > value > of EAX is removed. This ?op can be executed at the earliest possible > opportunity, > reducing the number of outstanding instructions and is the lowest cost NOP. > > The other NOPs have no special hardware support. Their input and output > registers > are interpreted by the hardware. Therefore, a code generator should arrange > to use > the register containing the oldest value as input, so that the NOP will > dispatch and > release RS resources at the earliest possible opportunity. > > Try to observe the following NOP generation priority. Select: > * the smallest number of NOPs and pseudo-NOPs to provide the desired > padding. > * NOPs that are least likely to execute on slower execution unit clusters. > * the register arguments of NOPs to reduce dependencies. > > // end Intel Arch --------------------------- > > > The code in assembler_x86.cpp however issues NOPs using: > > void Assembler::nop(int i) { > #ifdef ASSERT > assert(i> 0, " "); > // The fancy nops aren't currently recognized by debuggers making it a > // pain to disassemble code while debugging. If asserts are on clearly > // speed is not an issue so simply use the single byte traditional nop > // to do alignment. > > for (; i> 0 ; i--) emit_byte(0x90); > return; > > #endif // ASSERT > > if (UseAddressNop&& VM_Version::is_intel()) { > // > // Using multi-bytes nops "0x0F 0x1F [address]" for Intel > // 1: 0x90 > // 2: 0x66 0x90 > // 3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe > padding) > // 4: 0x0F 0x1F 0x40 0x00 > // 5: 0x0F 0x1F 0x44 0x00 0x00 > // 6: 0x66 0x0F 0x1F 0x44 0x00 0x00 > // 7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 > // 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > // 9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > > // The rest coding is Intel specific - don't use consecutive address > nops > > // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 > 0x90 > // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 > 0x66 0x90 > > while(i>= 15) { > // For Intel don't generate consecutive addess nops (mix with regular > nops) > i -= 15; > emit_byte(0x66); // size prefix > emit_byte(0x66); // size prefix > emit_byte(0x66); // size prefix > addr_nop_8(); > emit_byte(0x66); // size prefix > emit_byte(0x66); // size prefix > emit_byte(0x66); // size prefix > emit_byte(0x90); // nop > } > switch (i) { > case 14: > emit_byte(0x66); // size prefix > case 13: > emit_byte(0x66); // size prefix > case 12: > addr_nop_8(); > emit_byte(0x66); // size prefix > emit_byte(0x66); // size prefix > emit_byte(0x66); // size prefix > emit_byte(0x90); // nop > break; > case 11: > emit_byte(0x66); // size prefix > case 10: > emit_byte(0x66); // size prefix > case 9: > emit_byte(0x66); // size prefix > case 8: > addr_nop_8(); > break; > case 7: > addr_nop_7(); > break; > case 6: > emit_byte(0x66); // size prefix > case 5: > addr_nop_5(); > break; > case 4: > addr_nop_4(); > break; > case 3: > // Don't use "0x0F 0x1F 0x00" - need patching safe padding > emit_byte(0x66); // size prefix > case 2: > emit_byte(0x66); // size prefix > case 1: > emit_byte(0x90); // nop > break; > default: > assert(i == 0, " "); > } > return; > } > > > void Assembler::addr_nop_4() { > // 4 bytes: NOP DWORD PTR [EAX+0] > emit_byte(0x0F); > emit_byte(0x1F); > emit_byte(0x40); // emit_rm(cbuf, 0x1, EAX_enc, EAX_enc); > emit_byte(0); // 8-bits offset (1 byte) > } > > void Assembler::addr_nop_5() { > // 5 bytes: NOP DWORD PTR [EAX+EAX*0+0] 8-bits offset > emit_byte(0x0F); > emit_byte(0x1F); > emit_byte(0x44); // emit_rm(cbuf, 0x1, EAX_enc, 0x4); > emit_byte(0x00); // emit_rm(cbuf, 0x0, EAX_enc, EAX_enc); > emit_byte(0); // 8-bits offset (1 byte) > } > > void Assembler::addr_nop_7() { > // 7 bytes: NOP DWORD PTR [EAX+0] 32-bits offset > emit_byte(0x0F); > emit_byte(0x1F); > emit_byte(0x80); // emit_rm(cbuf, 0x2, EAX_enc, EAX_enc); > emit_long(0); // 32-bits offset (4 bytes) > } > > void Assembler::addr_nop_8() { > // 8 bytes: NOP DWORD PTR [EAX+EAX*0+0] 32-bits offset > emit_byte(0x0F); > emit_byte(0x1F); > emit_byte(0x84); // emit_rm(cbuf, 0x2, EAX_enc, 0x4); > emit_byte(0x00); // emit_rm(cbuf, 0x0, EAX_enc, EAX_enc); > emit_long(0); // 32-bits offset (4 bytes) > } > > > > From forax at univ-mlv.fr Sun Sep 12 23:58:09 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 13 Sep 2010 08:58:09 +0200 Subject: help on instruction scheduling of hotspot jvm In-Reply-To: <4C8D5ED5.8080108@oracle.com> References: <29693457.post@talk.nabble.com> <4C8D5ED5.8080108@oracle.com> Message-ID: <4C8DCB81.6090700@univ-mlv.fr> Le 13/09/2010 01:14, David Holmes a ?crit : > ddmetro said the following on 09/13/10 08:14: >> I am working on multithreaded instruction scheduling on hotspot jvm. >> I have >> built the source code, however I have the following doubts: >> >> 1. I tried to look into instruction scheduling pass of Hotspot, but >> couldn't >> find any paper related to the same. Can you please direct me towards >> a paper >> that talks about instruction scheduling and thread scheduling in hotspot >> jvm. > > Don't know about instruction scheduling (which is a compiler issue) > but thread scheduling is basically done using the OS default > scheduling mechanism. There are some settings you can adjust to change > this, and you can do things externally (ie run the JVM in particular > scheduling class) but they are not recommended and need to be used > with extreme care. Dave Dice has some blog articles on this: > > http://blogs.sun.com/dave/entry/java_thread_priority_revisted_in > >> 2. I executed an applet using the j2sdk image's appletviewer. >> However, I am >> not able to get the starting point (main() method) for the same. Kindly >> provide the starting point. > > Applets don't have a main() method. Applets are executed by a > framework and it is the framework that has the main() method. You'd > have to look at the AppletViewer class in this case. > >> 3. I am assuming that the instruction scheduling will be done by the >> server >> side hotspot jvm and not the compiler (C2). Kindly confirm if my >> understanding is correct. > > The Hotspot "server" VM is the Hotspot VM configured to run the C2 > compiler. (The "client" VM runs the C1 compiler). Any instruction > scheduling would be done by the compiler, but questions on this are > better addressed to hotspot-compiler-dev - cc'ed. > >> Also, I tried to search for documentation that maps the different >> phases(instruction scheduling, register allocation, etc) with the source >> code classes. However I wasn't able to find one. Kindly direct me to >> such >> documentation, if one exists. > > There is not a lot of documentation for hotspot internals in general. > Again the compiler folk may be able to point you to documents or blog > entries that discuss this. There is a wiki: http://wikis.sun.com/display/HotSpotInternals/Home > > HTH > > David Holmes > >> Thanking You, >> -Dhiraj. R?mi From oehrstroem at gmail.com Mon Sep 13 03:05:54 2010 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Mon, 13 Sep 2010 12:05:54 +0200 Subject: review request (L): 6939224 MethodHandle.invokeGeneric needs to perform the correct set of conversions In-Reply-To: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> References: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> Message-ID: Why do an upcall to Java? The conversions should be so simple that it should be possible to handle them in the interpreter. 2010/9/12 John Rose : > 6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions > > Until now, the HotSpot JVM has conflated invokeExact with invokeGeneric. ?These changes, combined with forthcoming JDK runtime support changes, provide a hook for the JVM to perform on-the-fly argument conversions in invokeGeneric calls, as specified by the JSR 292 EG. > > http://cr.openjdk.java.net/~jrose/6939224/webrev.00/ > > This review is for the JDK parts, which (a) distinguishes correctly between the two invocation modes, and (b) performs an upcall to Java code when argument types need matching. > > -- John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From tom.rodriguez at oracle.com Mon Sep 13 10:49:21 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 13 Sep 2010 10:49:21 -0700 Subject: Request for review(M): 6919069: client compiler needs to capture more profile information for tiered work In-Reply-To: <4C8ABE14.6040306@oracle.com> References: <4C8ABE14.6040306@oracle.com> Message-ID: Looks good. tom On Sep 10, 2010, at 4:24 PM, Igor Veresov wrote: > Added profiling of instanceof and aastore. > > Webrev: http://cr.openjdk.java.net/~iveresov/6919069/webrev.00/ > > Thanks, > igor From tom.rodriguez at oracle.com Mon Sep 13 10:54:32 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 13 Sep 2010 10:54:32 -0700 Subject: review request (L): 6939224 MethodHandle.invokeGeneric needs to perform the correct set of conversions In-Reply-To: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> References: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> Message-ID: <9519B010-6E61-4050-8B81-C13C80D788F2@oracle.com> Looks ok. tom On Sep 12, 2010, at 3:18 AM, John Rose wrote: > 6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions > > Until now, the HotSpot JVM has conflated invokeExact with invokeGeneric. These changes, combined with forthcoming JDK runtime support changes, provide a hook for the JVM to perform on-the-fly argument conversions in invokeGeneric calls, as specified by the JSR 292 EG. > > http://cr.openjdk.java.net/~jrose/6939224/webrev.00/ > > This review is for the JDK parts, which (a) distinguishes correctly between the two invocation modes, and (b) performs an upcall to Java code when argument types need matching. > > -- John > From igor.veresov at oracle.com Mon Sep 13 10:55:39 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 13 Sep 2010 10:55:39 -0700 Subject: Request for review(M): 6919069: client compiler needs to capture more profile information for tiered work In-Reply-To: References: <4C8ABE14.6040306@oracle.com> Message-ID: <4C8E659B.8050404@oracle.com> Thanks, Tom! igor On 9/13/10 10:49 AM, Tom Rodriguez wrote: > Looks good. > > tom > > On Sep 10, 2010, at 4:24 PM, Igor Veresov wrote: > >> Added profiling of instanceof and aastore. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6919069/webrev.00/ >> >> Thanks, >> igor > From tom.rodriguez at oracle.com Mon Sep 13 11:05:01 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 13 Sep 2010 11:05:01 -0700 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: References: Message-ID: Looks ok. tom On Sep 12, 2010, at 3:11 AM, John Rose wrote: > 6981777: implement JSR 292 EG adjustments from summer 2010 > Summary: Introduce one more constant pool type, CONSTANT_MethodApply. > > This JVM change implements a mechanism which supports computed constants and parameterized bootstrap methods: > http://cr.openjdk.java.net/~jrose/6981777/webrev.00 > > The JVM change supplies a "hook" for memoizing library-defined constants in the constant pool. > > The actual semantics of the hook (which combines a "function" constant with an "argument" constant) will be defined by a JDK runtime routine which invokes the function on the argument if it is a unary function, and otherwise calls MethodHandles.bindTo, effectually treating the function as if it were curried. The code will be something like: > apply(fun,arg) := fun.type.parameterCount == 1 ? fun.invokeGeneric(arg) : fun.bindTo(arg); > > Combined with the pre-existing CONSTANT_MethodHandle constant pool entries, this provides a way to get a wide variety of computed constants. > > Although it may seem odd to allow only one argument (and use the bindTo function to collect multiple arguments) this design matches better with the binary constant pool structure already commonly built into JVMs, including both the HotSpot and IBM JVMs. > > The JVM change includes logic to ensure that if the initial computation of a constant causes an exception, this exception will be uniformly thrown from all points where it is referenced. This logic applies to pre-existing constants also. > > Motivation: Parameterized bootstrap methods seem to be required for factoring closures and similar data structures into distinct static and dynamic specifications. The computed constants allow explicit one-time computation of static information, to be used by an ldc or a bootstrap method or both. Such "live constants" were a request from dynamic language implementors at the Summit. > > A key use case for one-time computation appears to be representation selection for closures. This is best done in a runtime (decoupled from the bytecode compiler), but should not be done on every closure creation. The invokedynamic instruction can use bootstrap methods with additional parameters supplied by this mechanism to combine prepared closure bodies with closure parameters. The same pattern can also be used by other language implementations which also need to combine static with dynamic data. > > -- John > > P.S. I expect one more significant JVM change coming this week: It is the hook for MethodHandles.invokeGeneric, which enables the JVM to perform dynamic argument transformations during method handle invocations. From john.r.rose at oracle.com Mon Sep 13 11:26:31 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Mon, 13 Sep 2010 11:26:31 -0700 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: References: Message-ID: <840414B7-90AB-46A0-BFCF-89DA4C60E092@oracle.com> Thanks, Tom. -- John (on my iPhone) On Sep 13, 2010, at 11:05 AM, Tom Rodriguez wrote: > Looks ok. > > tom > > On Sep 12, 2010, at 3:11 AM, John Rose wrote: > >> 6981777: implement JSR 292 EG adjustments from summer 2010 >> Summary: Introduce one more constant pool type, CONSTANT_MethodApply. >> >> This JVM change implements a mechanism which supports computed constants and parameterized bootstrap methods: >> http://cr.openjdk.java.net/~jrose/6981777/webrev.00 >> From john.r.rose at oracle.com Mon Sep 13 11:27:26 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Mon, 13 Sep 2010 11:27:26 -0700 Subject: review request (L): 6939224 MethodHandle.invokeGeneric needs to perform the correct set of conversions In-Reply-To: <9519B010-6E61-4050-8B81-C13C80D788F2@oracle.com> References: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> <9519B010-6E61-4050-8B81-C13C80D788F2@oracle.com> Message-ID: <8A0D6149-39B2-4EF3-AEE3-3613A66BFEA8@oracle.com> Thanks! -- John (on my iPhone) On Sep 13, 2010, at 10:54 AM, Tom Rodriguez wrote: > Looks ok. > > tom > > On Sep 12, 2010, at 3:18 AM, John Rose wrote: > >> 6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions >> >> Until now, the HotSpot JVM has conflated invokeExact with invokeGeneric. These changes, combined with forthcoming JDK runtime support changes, provide a hook for the JVM to perform on-the-fly argument conversions in invokeGeneric calls, as specified by the JSR 292 EG. >> >> http://cr.openjdk.java.net/~jrose/6939224/webrev.00/ >> >> This review is for the JDK parts, which (a) distinguishes correctly between the two invocation modes, and (b) performs an upcall to Java code when argument types need matching. >> >> -- John >> > From john.r.rose at oracle.com Mon Sep 13 11:36:10 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Mon, 13 Sep 2010 11:36:10 -0700 Subject: review request (L): 6939224 MethodHandle.invokeGeneric needs to perform the correct set of conversions In-Reply-To: References: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> Message-ID: There is no up-call. The JVM just tail-calls an adapter previously prepared by the JDK runtime. So the interpreter has no special paths other than the slow path with the tail call. I think your implementation put the adapter on a method header. I put it on the method type family (the "form"). -- John (on my iPhone) On Sep 13, 2010, at 3:05 AM, Fredrik ?hrstr?m wrote: > Why do an upcall to Java? The conversions should be so simple that it > should be possible to handle them in the interpreter. From john.r.rose at oracle.com Mon Sep 13 13:17:37 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 13 Sep 2010 13:17:37 -0700 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: References: Message-ID: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> Note: I just split the MethodApply part of this bug as its own bug; the new number is 6984311. -- John On Sep 12, 2010, at 3:11 AM, John Rose wrote: > 6981777: implement JSR 292 EG adjustments from summer 2010 > Summary: Introduce one more constant pool type, CONSTANT_MethodApply. > > This JVM change implements a mechanism which supports computed constants and parameterized bootstrap methods: > http://cr.openjdk.java.net/~jrose/6981777/webrev.00 From igor.veresov at oracle.com Mon Sep 13 14:18:27 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Mon, 13 Sep 2010 21:18:27 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6919069: client compiler needs to capture more profile information for tiered work Message-ID: <20100913211829.AF1434794F@hg.openjdk.java.net> Changeset: 3a294e483abc Author: iveresov Date: 2010-09-13 12:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3a294e483abc 6919069: client compiler needs to capture more profile information for tiered work Summary: Added profiling of instanceof and aastore. Reviewed-by: kvn, jrose, never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp From vladimir.kozlov at oracle.com Mon Sep 13 15:52:52 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Sep 2010 15:52:52 -0700 Subject: Request for reviews (XS): 6984346 and 6984348 Message-ID: <4C8EAB44.1060108@oracle.com> http://cr.openjdk.java.net/~kvn/6984346/webrev Fixed 6984346: Remove development code in type.hpp http://cr.openjdk.java.net/~kvn/6984348/webrev Fixed 6984348: Fix typo in escape.cpp Thanks, Vladimir From tom.rodriguez at oracle.com Mon Sep 13 16:43:48 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 13 Sep 2010 16:43:48 -0700 Subject: Request for reviews (XS): 6984346 and 6984348 In-Reply-To: <4C8EAB44.1060108@oracle.com> References: <4C8EAB44.1060108@oracle.com> Message-ID: They both look good. tom On Sep 13, 2010, at 3:52 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6984346/webrev > > Fixed 6984346: Remove development code in type.hpp > > http://cr.openjdk.java.net/~kvn/6984348/webrev > > Fixed 6984348: Fix typo in escape.cpp > > Thanks, > Vladimir > From vladimir.kozlov at oracle.com Mon Sep 13 16:43:30 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Sep 2010 16:43:30 -0700 Subject: Request for reviews (XS): 6984346 and 6984348 In-Reply-To: References: <4C8EAB44.1060108@oracle.com> Message-ID: <4C8EB722.40906@oracle.com> Thanks, Tom Vladimir Tom Rodriguez wrote: > They both look good. > > tom > > On Sep 13, 2010, at 3:52 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6984346/webrev >> >> Fixed 6984346: Remove development code in type.hpp >> >> http://cr.openjdk.java.net/~kvn/6984348/webrev >> >> Fixed 6984348: Fix typo in escape.cpp >> >> Thanks, >> Vladimir >> > From vladimir.kozlov at oracle.com Mon Sep 13 19:31:52 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 14 Sep 2010 02:31:52 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6984346: Remove development code in type.hpp Message-ID: <20100914023154.39F854795D@hg.openjdk.java.net> Changeset: d20603ee9e10 Author: kvn Date: 2010-09-13 16:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d20603ee9e10 6984346: Remove development code in type.hpp Summary: Remove code which use UseNewCode in type.hpp Reviewed-by: never ! src/share/vm/opto/type.hpp From john.r.rose at oracle.com Tue Sep 14 01:43:20 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 14 Sep 2010 08:43:20 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions Message-ID: <20100914084322.A09B14796B@hg.openjdk.java.net> Changeset: d257356e35f0 Author: jrose Date: 2010-09-13 23:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d257356e35f0 6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions Reviewed-by: never ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp From john.r.rose at oracle.com Tue Sep 14 01:44:21 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 14 Sep 2010 08:44:21 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 6982752: dynamic languages need to decorate types with runtime information Message-ID: <20100914084502.B1E484796D@hg.openjdk.java.net> Changeset: 4ed243e9e9d9 Author: jrose Date: 2010-09-14 01:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4ed243e9e9d9 6982752: dynamic languages need to decorate types with runtime information Summary: Add ClassValue Reviewed-by: twisti + src/share/classes/java/dyn/ClassValue.java + test/java/dyn/ClassValueTest.java From christian.thalinger at oracle.com Tue Sep 14 02:51:12 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 14 Sep 2010 11:51:12 +0200 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> References: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> Message-ID: <1284457872.9557.47.camel@macbook> On Mon, 2010-09-13 at 13:17 -0700, John Rose wrote: > Note: I just split the MethodApply part of this bug as its own bug; the new number is 6984311. > > -- John > > On Sep 12, 2010, at 3:11 AM, John Rose wrote: > > > 6981777: implement JSR 292 EG adjustments from summer 2010 > > Summary: Introduce one more constant pool type, CONSTANT_MethodApply. > > > > This JVM change implements a mechanism which supports computed constants and parameterized bootstrap methods: > > http://cr.openjdk.java.net/~jrose/6981777/webrev.00 > agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java src/share/vm/ci/ciObjectFactory.cpp: src/share/vm/ci/ciObjectFactory.hpp: src/share/vm/classfile/classFileParser.cpp: src/share/vm/classfile/systemDictionary.cpp: src/share/vm/memory/universe.hpp: src/share/vm/oops/constantPoolKlass.cp: src/share/vm/prims/jvm.h: src/share/vm/prims/methodComparator.hpp: src/share/vm/utilities/constantTag.cpp: src/share/vm/utilities/constantTag.hpp: Copyright year update missing. src/share/vm/prims/jvm.h: agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java: JVM_CONSTANT_MethodHandle = 15, // JSR 292 JVM_CONSTANT_MethodType = 16, // JSR 292 + JVM_CONSTANT_MethodApply = 18, // JSR 292 JVM_CONSTANT_InvokeDynamic = 17 // JSR 292 It's just a nit, but could you swap the numbers of the last two? That would require to revert this change: src/share/vm/utilities/constantTag.hpp: - (tag >= JVM_CONSTANT_MethodHandle && tag <= JVM_CONSTANT_InvokeDynamic) || + (tag >= JVM_CONSTANT_MethodHandle && tag <= JVM_CONSTANT_MethodApply) || src/cpu/x86/vm/templateTable_x86_32.cpp: Why do we need this change only on x86_32? Otherwise looks good. -- Christian From john.r.rose at oracle.com Tue Sep 14 03:27:22 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 14 Sep 2010 03:27:22 -0700 Subject: review request (L): 6939224 MethodHandle.invokeGeneric needs to perform the correct set of conversions In-Reply-To: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> References: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> Message-ID: This is the Java code which uses the new hook placed in hotspot under this same bug. http://cr.openjdk.java.net/~jrose/6939224/jdk-webrev.00/ -- John From tom.rodriguez at oracle.com Tue Sep 14 18:10:43 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 15 Sep 2010 01:10:43 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6982370: SIGBUS in jbyte_fill Message-ID: <20100915011049.79353479A3@hg.openjdk.java.net> Changeset: 065dd1ca3ab6 Author: never Date: 2010-09-14 14:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/065dd1ca3ab6 6982370: SIGBUS in jbyte_fill Reviewed-by: kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp + test/compiler/6982370/Test6982370.java From john.r.rose at oracle.com Tue Sep 14 19:55:26 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 14 Sep 2010 19:55:26 -0700 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: <1284457872.9557.47.camel@macbook> References: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> <1284457872.9557.47.camel@macbook> Message-ID: On Sep 14, 2010, at 2:51 AM, Christian Thalinger wrote: > On Mon, 2010-09-13 at 13:17 -0700, John Rose wrote: >> Note: I just split the MethodApply part of this bug as its own bug; the new number is 6984311. >> >> -- John >> >> On Sep 12, 2010, at 3:11 AM, John Rose wrote: >> >>> 6981777: implement JSR 292 EG adjustments from summer 2010 >>> Summary: Introduce one more constant pool type, CONSTANT_MethodApply. >>> >>> This JVM change implements a mechanism which supports computed constants and parameterized bootstrap methods: >>> http://cr.openjdk.java.net/~jrose/6981777/webrev.00 >> > > agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java > src/share/vm/ci/ciObjectFactory.cpp: > src/share/vm/ci/ciObjectFactory.hpp: > src/share/vm/classfile/classFileParser.cpp: > src/share/vm/classfile/systemDictionary.cpp: > src/share/vm/memory/universe.hpp: > src/share/vm/oops/constantPoolKlass.cp: > src/share/vm/prims/jvm.h: > src/share/vm/prims/methodComparator.hpp: > src/share/vm/utilities/constantTag.cpp: > src/share/vm/utilities/constantTag.hpp: > > Copyright year update missing. Thanks. I found a couple more, too. > src/share/vm/prims/jvm.h: > agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java: > > JVM_CONSTANT_MethodHandle = 15, // JSR 292 > JVM_CONSTANT_MethodType = 16, // JSR 292 > + JVM_CONSTANT_MethodApply = 18, // JSR 292 > JVM_CONSTANT_InvokeDynamic = 17 // JSR 292 > > It's just a nit, but could you swap the numbers of the last two? I agree it's annoying, but I'd rather not change a pre-existing number. If we change CONSTANT_InvokeDynamic it might pull the rug out from under an early adopter, although that constant itself is fairly new. I'll put the constant declarations in numerical order, at least. > That would require to revert this change: > src/share/vm/utilities/constantTag.hpp: > > - (tag >= JVM_CONSTANT_MethodHandle && tag <= JVM_CONSTANT_InvokeDynamic) || > + (tag >= JVM_CONSTANT_MethodHandle && tag <= JVM_CONSTANT_MethodApply) || > > src/cpu/x86/vm/templateTable_x86_32.cpp: > > Why do we need this change only on x86_32? Because I hadn't ported it yet. I just did. While I was at it I ported to sparc also. And I also rolled in the sparc code for the previous change (invokeGeneric). Here's the update: http://cr.openjdk.java.net/~jrose/6984311/webrev.01/ Note: I may ask for review of an alternative form of this change set, which uses N-ary instead of binary nodes in the constant pool. The EG is discussing both options. -- John > Otherwise looks good. > > -- Christian > From john.r.rose at oracle.com Wed Sep 15 01:22:41 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 15 Sep 2010 01:22:41 -0700 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: References: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> <1284457872.9557.47.camel@macbook> Message-ID: <51F2F4F8-45C4-4192-9239-AFAC62D8C85F@oracle.com> On Sep 14, 2010, at 7:55 PM, John Rose wrote: > Here's the update: > > http://cr.openjdk.java.net/~jrose/6984311/webrev.01/ > > Note: I may ask for review of an alternative form of this change set, which uses N-ary instead of binary nodes in the constant pool. The EG is discussing both options. I did the variation which supports N-ary MethodApply nodes. It is somewhat less natural than the binary MethodApply nodes, because constant pools contain mostly binary nodes, but it matches the meaning of the constants better to allow them to be N-ary. And the extra data structure is pretty simple. See what you think. http://cr.openjdk.java.net/~jrose/6984311/webrev.01.nary (These are only the diffs from the binary to the N-ary version.) -- John From vladimir.kozlov at oracle.com Wed Sep 15 01:42:20 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 15 Sep 2010 08:42:20 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6984368: Large default heap size does not allow to use zero based compressed oops Message-ID: <20100915084228.86419479B5@hg.openjdk.java.net> Changeset: a8b66e00933b Author: kvn Date: 2010-09-14 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a8b66e00933b 6984368: Large default heap size does not allow to use zero based compressed oops Summary: take into account HeapBaseMinAddress and round down MaxPermSize Reviewed-by: never ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp From forax at univ-mlv.fr Wed Sep 15 02:20:08 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 15 Sep 2010 11:20:08 +0200 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: <51F2F4F8-45C4-4192-9239-AFAC62D8C85F@oracle.com> References: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> <1284457872.9557.47.camel@macbook> <51F2F4F8-45C4-4192-9239-AFAC62D8C85F@oracle.com> Message-ID: <4C908FC8.2000604@univ-mlv.fr> Le 15/09/2010 10:22, John Rose a ?crit : > On Sep 14, 2010, at 7:55 PM, John Rose wrote: > > >> Here's the update: >> >> http://cr.openjdk.java.net/~jrose/6984311/webrev.01/ >> >> Note: I may ask for review of an alternative form of this change set, which uses N-ary instead of binary nodes in the constant pool. The EG is discussing both options. >> > I did the variation which supports N-ary MethodApply nodes. It is somewhat less natural than the binary MethodApply nodes, because constant pools contain mostly binary nodes, but it matches the meaning of the constants better to allow them to be N-ary. And the extra data structure is pretty simple. See what you think. > > http://cr.openjdk.java.net/~jrose/6984311/webrev.01.nary > > (These are only the diffs from the binary to the N-ary version.) > > -- John I prefer the N-ary version :) Questions: - Why having two constants InvokeDynamic and MethodApply in that case. Constant arguments are tied to a BSM. I don't think you can reuse array of arguments accross different BSMs. - Why argcount is stored using 2 bytes instead of one ? These arguments are arguments of a Java method (the BSM) which limit the number or argument to 255. R?mi From rasbold at google.com Wed Sep 15 10:17:56 2010 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 15 Sep 2010 10:17:56 -0700 Subject: Review request: flush the output streams before OnError commands Message-ID: I've found the LogCompilation files incomplete when a JIT crashes and OnError is used to move the files. http://cr.openjdk.java.net/~rasbold/OnError/webrev.00 NoBugId: Contributed-by: rasbold at google.com When the VM aborts, flush the output streams before OnError commands are processed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100915/dccb14d6/attachment.html From vladimir.kozlov at oracle.com Wed Sep 15 11:15:21 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Sep 2010 11:15:21 -0700 Subject: Updated request for reviews (S): 6984348 Message-ID: <4C910D39.40908@oracle.com> http://cr.openjdk.java.net/~kvn/6984348/webrev.01 Fixed 6984348: Fix typo in escape.cpp After fixing typo the assert produces false negative results. It does not take into account that Loads don't have output memory edge and Stores may have several memory users. I removed this code and added few asserts into move_inst_mem(). Tested with CTW and NSK. From vladimir.kozlov at oracle.com Wed Sep 15 11:38:44 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Sep 2010 11:38:44 -0700 Subject: Review request: flush the output streams before OnError commands In-Reply-To: References: Message-ID: <4C9112B4.1070703@oracle.com> When -XX:+SuppressFatalErrorMessage the log files will not be flushed. Vladimir Chuck Rasbold wrote: > I've found the LogCompilation files incomplete when a JIT crashes and > OnError is used to move the files. > > http://cr.openjdk.java.net/~rasbold/OnError/webrev.00 > > NoBugId: > Contributed-by: rasbold at google.com > > When the VM aborts, flush the output streams before OnError commands are > processed. > > From tom.rodriguez at oracle.com Wed Sep 15 12:04:44 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 15 Sep 2010 12:04:44 -0700 Subject: Updated request for reviews (S): 6984348 In-Reply-To: <4C910D39.40908@oracle.com> References: <4C910D39.40908@oracle.com> Message-ID: <09A4700D-23B0-48AC-A69A-62BF2F0197A5@oracle.com> Can you explain what problem the old code was checking for and how the new code handles that? If m == orig_mem why do we use find_inst_mem to look it up? Wouldn't it make more sense for find_inst_mem to be used only in the assert? tom On Sep 15, 2010, at 11:15 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6984348/webrev.01 > > Fixed 6984348: Fix typo in escape.cpp > > After fixing typo the assert produces false negative results. > It does not take into account that Loads don't have output > memory edge and Stores may have several memory users. > > I removed this code and added few asserts into move_inst_mem(). > > Tested with CTW and NSK. > From tom.rodriguez at oracle.com Wed Sep 15 12:52:40 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 15 Sep 2010 12:52:40 -0700 Subject: review (S) for 6984979: OptimizeFill misses some cases with an odd memory graph Message-ID: <29DB3F6F-FE66-4BEC-84F4-D3E396D110DC@oracle.com> http://cr.openjdk.java.net/~never/6984979 6984979: OptimizeFill misses some cases with an odd memory graph Reviewed-by: The logic for the new OptimizeFill code misses a case where the Phi usage is different than expected. Sometimes during transformation of the loop there are uses of the memory phi outside the loop. This appears to be a valid though slightly surprising structure but it interferes with the fill matching logic that assumes the store in the loop should be the only outgoing state. The fix is to allow the phi to be used outside the loop and replace it with the outgoing memory of the call to the fill. Tested with jbb, runthere and ctw. From rasbold at google.com Wed Sep 15 14:26:44 2010 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 15 Sep 2010 14:26:44 -0700 Subject: Review request: flush the output streams before OnError commands In-Reply-To: <4C9112B4.1070703@oracle.com> References: <4C9112B4.1070703@oracle.com> Message-ID: Thanks for looking at this. I'll admit I originally overlooked SuppressFatalErrorMessage, and I'm not familiar with conventional use of the option. After looking at it, the intent of that flag seems to be to avoid all post fatal error processing. See bug 6194668. Under that description, I would argue that flushing the streams is post-error processing, and my changes are in keeping with that. If you don't agree with me, do you think calling ostream_abort() before os::abort() is the right thing to do? My last preference would be to leave the calls in the OS specific shutdown routines. -- Chuck On Wed, Sep 15, 2010 at 11:38 AM, Vladimir Kozlov < vladimir.kozlov at oracle.com> wrote: > When -XX:+SuppressFatalErrorMessage the log files will not be flushed. > > Vladimir > > Chuck Rasbold wrote: > >> I've found the LogCompilation files incomplete when a JIT crashes and >> OnError is used to move the files. >> >> http://cr.openjdk.java.net/~rasbold/OnError/webrev.00 >> >> NoBugId: Contributed-by: rasbold at google.com >> >> >> When the VM aborts, flush the output streams before OnError commands are >> processed. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100915/7f98bd20/attachment.html From vladimir.kozlov at oracle.com Wed Sep 15 14:41:07 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Sep 2010 14:41:07 -0700 Subject: review (S) for 6984979: OptimizeFill misses some cases with an odd memory graph In-Reply-To: <29DB3F6F-FE66-4BEC-84F4-D3E396D110DC@oracle.com> References: <29DB3F6F-FE66-4BEC-84F4-D3E396D110DC@oracle.com> Message-ID: <4C913D73.4020800@oracle.com> Tom, Should we also check that n->is_Phi() && n->in(LoopNode::LoopBackControl) == store? Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6984979 > > 6984979: OptimizeFill misses some cases with an odd memory graph > Reviewed-by: > > The logic for the new OptimizeFill code misses a case where the Phi > usage is different than expected. Sometimes during transformation of > the loop there are uses of the memory phi outside the loop. This > appears to be a valid though slightly surprising structure but it > interferes with the fill matching logic that assumes the store in the > loop should be the only outgoing state. The fix is to allow the phi > to be used outside the loop and replace it with the outgoing memory of > the call to the fill. Tested with jbb, runthere and ctw. From tom.rodriguez at oracle.com Wed Sep 15 16:30:36 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 15 Sep 2010 16:30:36 -0700 Subject: review (S) for 6984979: OptimizeFill misses some cases with an odd memory graph In-Reply-To: <4C913D73.4020800@oracle.com> References: <29DB3F6F-FE66-4BEC-84F4-D3E396D110DC@oracle.com> <4C913D73.4020800@oracle.com> Message-ID: <1AE0D67C-F6A6-4570-8712-0D6CBF5F826D@oracle.com> I don't think it's possible for it to be structured any other way, but I can add that check to the initial sanity check of the store. I've updated the webrev. tom On Sep 15, 2010, at 2:41 PM, Vladimir Kozlov wrote: > Tom, > > Should we also check that n->is_Phi() && n->in(LoopNode::LoopBackControl) == store? > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6984979 >> 6984979: OptimizeFill misses some cases with an odd memory graph >> Reviewed-by: >> The logic for the new OptimizeFill code misses a case where the Phi >> usage is different than expected. Sometimes during transformation of >> the loop there are uses of the memory phi outside the loop. This >> appears to be a valid though slightly surprising structure but it >> interferes with the fill matching logic that assumes the store in the >> loop should be the only outgoing state. The fix is to allow the phi >> to be used outside the loop and replace it with the outgoing memory of >> the call to the fill. Tested with jbb, runthere and ctw. From vladimir.kozlov at oracle.com Wed Sep 15 16:39:59 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Sep 2010 16:39:59 -0700 Subject: Updated request for reviews (S): 6984348 In-Reply-To: <09A4700D-23B0-48AC-A69A-62BF2F0197A5@oracle.com> References: <4C910D39.40908@oracle.com> <09A4700D-23B0-48AC-A69A-62BF2F0197A5@oracle.com> Message-ID: <4C91594F.8060504@oracle.com> Tom Rodriguez wrote: > Can you explain what problem the old code was checking for and how the new code handles that? The code was added to catch situation similar to 6896727 where MergeMemory node general memory slice was not updated correctly since it was moved with moved store. The changes for 6896727 fixed it by moving store's users before the store change its memory (move_inst_mem() was added). The original check was added to verify that moved stores will be replaced by corresponding memory slice. But relaying on number of output edges for the check was not correct. New asserts verify that old_mem output edges were correctly updated. But looking on this more it could be not enough or even correct. Also missing (as before) checks for inputs update of non-instance Phis (Phase 4 first loop). > If m == orig_mem why do we use find_inst_mem to look it up? Wouldn't it make more sense for find_inst_mem to be used only in the assert? I am concern that could be cases when m != orig_mem. Consider the case when old_mem is a store into another instance. Then it will be not general memory slice. But I can't find such cases with testing. I need to spend more time on this. Thanks, Vladimir > > tom > > On Sep 15, 2010, at 11:15 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6984348/webrev.01 >> >> Fixed 6984348: Fix typo in escape.cpp >> >> After fixing typo the assert produces false negative results. >> It does not take into account that Loads don't have output >> memory edge and Stores may have several memory users. >> >> I removed this code and added few asserts into move_inst_mem(). >> >> Tested with CTW and NSK. >> > From vladimir.kozlov at oracle.com Wed Sep 15 16:42:18 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Sep 2010 16:42:18 -0700 Subject: review (S) for 6984979: OptimizeFill misses some cases with an odd memory graph In-Reply-To: <1AE0D67C-F6A6-4570-8712-0D6CBF5F826D@oracle.com> References: <29DB3F6F-FE66-4BEC-84F4-D3E396D110DC@oracle.com> <4C913D73.4020800@oracle.com> <1AE0D67C-F6A6-4570-8712-0D6CBF5F826D@oracle.com> Message-ID: <4C9159DA.2010809@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > I don't think it's possible for it to be structured any other way, but I can add that check to the initial sanity check of the store. I've updated the webrev. > > tom > > On Sep 15, 2010, at 2:41 PM, Vladimir Kozlov wrote: > >> Tom, >> >> Should we also check that n->is_Phi() && n->in(LoopNode::LoopBackControl) == store? >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6984979 >>> 6984979: OptimizeFill misses some cases with an odd memory graph >>> Reviewed-by: >>> The logic for the new OptimizeFill code misses a case where the Phi >>> usage is different than expected. Sometimes during transformation of >>> the loop there are uses of the memory phi outside the loop. This >>> appears to be a valid though slightly surprising structure but it >>> interferes with the fill matching logic that assumes the store in the >>> loop should be the only outgoing state. The fix is to allow the phi >>> to be used outside the loop and replace it with the outgoing memory of >>> the call to the fill. Tested with jbb, runthere and ctw. > From vladimir.kozlov at oracle.com Fri Sep 17 03:46:09 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 17 Sep 2010 10:46:09 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 18 new changesets Message-ID: <20100917104644.061A647A43@hg.openjdk.java.net> Changeset: 6ee479178066 Author: ikrylov Date: 2010-08-31 03:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6ee479178066 6979444: add command line option to print command line flags descriptions Summary: Implementation of a nonproduct boolean flag XX:PrintFlagsWithComments Reviewed-by: kamg, dholmes, dsamersoff ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/macros.hpp Changeset: 1ab9e2cbfa0e Author: kamg Date: 2010-09-03 14:47 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1ab9e2cbfa0e 6870851: Bad frame_chop in StackMapTable crashes JVM Summary: Must check locals for null when processing chop frame Reviewed-by: dholmes, dcubed ! src/share/vm/classfile/stackMapTable.cpp Changeset: 40d7b43b6fe0 Author: kamg Date: 2010-09-07 11:38 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/40d7b43b6fe0 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 07551f490c76 Author: kamg Date: 2010-09-07 11:50 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/07551f490c76 6982851: Add b107 machine classifications to jprt.properties file. Summary: See synopsis Reviewed-by: ohair ! make/jprt.properties Changeset: e44a93947ccb Author: cl Date: 2010-08-26 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e44a93947ccb Added tag jdk7-b107 for changeset bf496cbe9b74 ! .hgtags Changeset: 6c43216df135 Author: trims Date: 2010-08-31 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6c43216df135 Merge ! .hgtags Changeset: 0803c0f69b51 Author: trims Date: 2010-08-31 17:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0803c0f69b51 Added tag hs19-b06 for changeset 6c43216df135 ! .hgtags Changeset: 40b1534a1dab Author: trims Date: 2010-09-08 18:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/40b1534a1dab Merge Changeset: 93193e632121 Author: trims Date: 2010-09-08 18:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/93193e632121 6983320: Fork HS19 to HS20 - renumber Major and build numbers of JVM Summary: Update the Major and Build numbers for HS20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ea175c1b79ce Author: dcubed Date: 2010-09-08 08:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ea175c1b79ce 6561870: 3/3 Long javac compile lines fail due to command line length issues (agent compiles?) Summary: Use javac's @filename construct to avoid long compile lines Reviewed-by: ohair, twisti, never Contributed-by: doko at ubuntu.com ! make/linux/makefiles/sa.make ! make/solaris/makefiles/sa.make Changeset: 30f67acf635d Author: thurka Date: 2010-09-11 08:18 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/30f67acf635d 6765718: Indicate which thread throwing OOME when generating the heap dump at OOME Summary: Emit a fake frame that makes it look like the thread is in the OutOfMemoryError zero-parameter constructor Reviewed-by: dcubed ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/heapDumper.hpp ! src/share/vm/utilities/debug.cpp Changeset: 8a8a7a014a12 Author: kamg Date: 2010-09-13 07:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8a8a7a014a12 Merge Changeset: 179464550c7d Author: ysr Date: 2010-09-10 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/179464550c7d 6983930: CMS: Various small cleanups ca September 2010 Summary: Fixed comment/documentation typos; converted some guarantee()s to assert()s. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/runtime/globals.hpp Changeset: eeade8e89248 Author: ysr Date: 2010-09-11 11:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/eeade8e89248 Merge ! src/share/vm/runtime/globals.hpp Changeset: 6eddcbe17c83 Author: johnc Date: 2010-09-13 10:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6eddcbe17c83 6981746: G1: SEGV with -XX:+TraceGen0Time Summary: Pass correct value for length to NumberSeq constructor. Guard dereferences of "body_summary" pointer with a NULL check. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 432d823638f7 Author: jcoomes Date: 2010-09-15 10:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/432d823638f7 6985022: update make/jprt.properties for new jdk7 tools Reviewed-by: ohair, kvn ! make/jprt.properties Changeset: 97fbf5beff7b Author: johnc Date: 2010-09-16 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/97fbf5beff7b Merge Changeset: 18c378513575 Author: kvn Date: 2010-09-16 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/18c378513575 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/macros.hpp From forax at univ-mlv.fr Sat Sep 18 11:25:27 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 18 Sep 2010 20:25:27 +0200 Subject: More on: Small static method marked not entrant, inlining reversed? Message-ID: <4C950417.3030501@univ-mlv.fr> I take a little time to create a simple test case to reproduce a bug found by Charles Nutter with c2. see http://groups.google.com/group/jvm-languages/browse_thread/thread/6c9e05ecd28fdcd4# Here is the test case, There is 3 classes A, B, C that inherit from AbstractFoo that implements Foo. The method test do a virtual call to check() and because check() is implemented in AbstractFoo we expect that this call should be de-virtualized then inlined. c2 fails, foo.check() is compiled as a virtual call :( With c1, there is no problem, CHA works correctly. R?mi ------------------------------------------------------------------------------------------------ public class InlineTest { interface Foo { public boolean check(int generation); } static class AbstractFoo implements Foo { private final int value; protected AbstractFoo(int value) { this.value = value; } public boolean check(int generation) { return this.getClass().hashCode() - value == generation; } } static class A extends AbstractFoo { public A(int value) { super(value); } } static class B extends AbstractFoo { public B(int value) { super(value); } } static class C extends AbstractFoo { public C(int value) { super(value); } } private static final int CONST = A.class.hashCode(); private static int count; private static void test(Foo foo) { if (foo.check(0)) { count += 2; //System.out.println("foo"); } else { count += 1; //System.out.println("bar"); } } public static void main(String[] args) { Foo[] array = new Foo[100000]; int threshold = 20000; for(int i=0; i References: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> <1284457872.9557.47.camel@macbook> <51F2F4F8-45C4-4192-9239-AFAC62D8C85F@oracle.com> Message-ID: <1284969431.14822.2014.camel@macbook> On Wed, 2010-09-15 at 01:22 -0700, John Rose wrote: > On Sep 14, 2010, at 7:55 PM, John Rose wrote: > > > Here's the update: > > > > http://cr.openjdk.java.net/~jrose/6984311/webrev.01/ > > > > Note: I may ask for review of an alternative form of this change set, which uses N-ary instead of binary nodes in the constant pool. The EG is discussing both options. > > I did the variation which supports N-ary MethodApply nodes. It is somewhat less natural than the binary MethodApply nodes, because constant pools contain mostly binary nodes, but it matches the meaning of the constants better to allow them to be N-ary. And the extra data structure is pretty simple. See what you think. > > http://cr.openjdk.java.net/~jrose/6984311/webrev.01.nary > > (These are only the diffs from the binary to the N-ary version.) src/share/vm/classfile/classFileParser.cpp: + cfs->guarantee_more(3, CHECK); // operand_count, ..., tag/access_flags + u2 op_count = cfs->get_u2_fast(); + cfs->guarantee_more(2*op_count + 1, CHECK); I think the additional +1 is wrong as you check for 3 in the first guarantee_more. Otherwise it looks good. -- Christian From christian.thalinger at oracle.com Mon Sep 20 01:16:25 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 20 Sep 2010 10:16:25 +0200 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: References: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> <1284457872.9557.47.camel@macbook> Message-ID: <1284970585.14822.2034.camel@macbook> On Tue, 2010-09-14 at 19:55 -0700, John Rose wrote: > Here's the update: > > http://cr.openjdk.java.net/~jrose/6984311/webrev.01/ I looked closely at the SPARC changes and these look good. -- Christian From john.r.rose at oracle.com Mon Sep 20 02:25:42 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 20 Sep 2010 02:25:42 -0700 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: <1284969431.14822.2014.camel@macbook> References: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> <1284457872.9557.47.camel@macbook> <51F2F4F8-45C4-4192-9239-AFAC62D8C85F@oracle.com> <1284969431.14822.2014.camel@macbook> Message-ID: <3E9226B9-87BF-4A28-8005-1B00BDD3DFE9@oracle.com> On Sep 20, 2010, at 12:57 AM, Christian Thalinger wrote: > src/share/vm/classfile/classFileParser.cpp: > > + cfs->guarantee_more(3, CHECK); // operand_count, ..., tag/access_flags > + u2 op_count = cfs->get_u2_fast(); > + cfs->guarantee_more(2*op_count + 1, CHECK); > > I think the additional +1 is wrong as you check for 3 in the first > guarantee_more. Yes, but that 3 only assures the tag will be present if op_count==0. The way this big loop works is everybody has to ensure that the next guy's tag is already loaded. So almost every guarantee_more has to have a +1. -- John From christian.thalinger at oracle.com Mon Sep 20 03:31:02 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 20 Sep 2010 12:31:02 +0200 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: <3E9226B9-87BF-4A28-8005-1B00BDD3DFE9@oracle.com> References: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> <1284457872.9557.47.camel@macbook> <51F2F4F8-45C4-4192-9239-AFAC62D8C85F@oracle.com> <1284969431.14822.2014.camel@macbook> <3E9226B9-87BF-4A28-8005-1B00BDD3DFE9@oracle.com> Message-ID: <1284978662.14822.2171.camel@macbook> On Mon, 2010-09-20 at 02:25 -0700, John Rose wrote: > On Sep 20, 2010, at 12:57 AM, Christian Thalinger wrote: > > > src/share/vm/classfile/classFileParser.cpp: > > > > + cfs->guarantee_more(3, CHECK); // operand_count, ..., tag/access_flags > > + u2 op_count = cfs->get_u2_fast(); > > + cfs->guarantee_more(2*op_count + 1, CHECK); > > > > I think the additional +1 is wrong as you check for 3 in the first > > guarantee_more. > > Yes, but that 3 only assures the tag will be present if op_count==0. > The way this big loop works is everybody has to ensure that the next > guy's tag is already loaded. > So almost every guarantee_more has to have a +1. Makes sense. -- Christian From igor.veresov at oracle.com Mon Sep 20 19:50:17 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 20 Sep 2010 19:50:17 -0700 Subject: Request for review(S): 6986270: guarantee(*bcp != Bytecodes::_monitorenter || exec_mode != Deoptimization::Unpack_exception) fails Message-ID: <4C981D69.5060908@oracle.com> This guarantee should hold true for C2 but is not necessarily true for C1. The fix is to propagate the compiler type of the deopting method to vframeArrayElement::unpack_on_stack() and apply the guarantee only to c2-compiled methods. Webrev: http://cr.openjdk.java.net/~iveresov/6986270/webrev.00/ Thanks, igor From tom.rodriguez at oracle.com Mon Sep 20 23:48:37 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 21 Sep 2010 06:48:37 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6984979: OptimizeFill misses some cases with an odd memory graph Message-ID: <20100921064844.7D50C47B1A@hg.openjdk.java.net> Changeset: c77e8f982901 Author: never Date: 2010-09-15 20:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c77e8f982901 6984979: OptimizeFill misses some cases with an odd memory graph Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp From roland.westrelin at oracle.com Tue Sep 21 02:03:19 2010 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 21 Sep 2010 11:03:19 +0200 Subject: Request for reviews (L): 6986046 C1 ValueStack cleanup Message-ID: Cleanup contributed by Christian Wimmer to the C1 ValueStack. http://cr.openjdk.java.net/~roland/6986046/webrev.00/ Roland. From tom.rodriguez at oracle.com Tue Sep 21 12:35:56 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 21 Sep 2010 12:35:56 -0700 Subject: Request for review(S): 6986270: guarantee(*bcp != Bytecodes::_monitorenter || exec_mode != Deoptimization::Unpack_exception) fails In-Reply-To: <4C981D69.5060908@oracle.com> References: <4C981D69.5060908@oracle.com> Message-ID: <1F758CCE-1108-4579-B465-8BF3BC686AF8@oracle.com> It's a bit ugly but I don't see a simpler fix. Looks good. tom On Sep 20, 2010, at 7:50 PM, Igor Veresov wrote: > This guarantee should hold true for C2 but is not necessarily true for C1. The fix is to propagate the compiler type of the deopting method to vframeArrayElement::unpack_on_stack() and apply the guarantee only to c2-compiled methods. > > Webrev: http://cr.openjdk.java.net/~iveresov/6986270/webrev.00/ > > > Thanks, > igor From tom.rodriguez at oracle.com Tue Sep 21 12:48:44 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 21 Sep 2010 12:48:44 -0700 Subject: More on: Small static method marked not entrant, inlining reversed? In-Reply-To: <4C950417.3030501@univ-mlv.fr> References: <4C950417.3030501@univ-mlv.fr> Message-ID: <87FC3F7B-295E-42B7-B4F4-4B6791D7617A@oracle.com> Thanks for the test case. The reason it works well for C1 is that we have an explicit check for single implementor interfaces and insert an extra checkcast to confirm that the type really is the type we expect. The extra check is needed since interface types aren't actually checked by the verifier. In your example the extra check isn't actually needed since all array stores are actually type checked so any type loaded from the array must actually implement the interface. C2 generally relies on type profiling to get cases like this but since type profiling is tracking the type of the receiver instead of the actual method being invoked it doesn't handle this case that well. It's not hard to do something better for this case. I filed 6986483 for this. tom On Sep 18, 2010, at 11:25 AM, R?mi Forax wrote: > I take a little time to create a simple test case to reproduce a bug > found by Charles Nutter with c2. > see http://groups.google.com/group/jvm-languages/browse_thread/thread/6c9e05ecd28fdcd4# > > Here is the test case, > There is 3 classes A, B, C that inherit from AbstractFoo that implements Foo. > The method test do a virtual call to check() and because > check() is implemented in AbstractFoo we expect that this call should be > de-virtualized then inlined. > > c2 fails, foo.check() is compiled as a virtual call :( > With c1, there is no problem, CHA works correctly. > > R?mi > > ------------------------------------------------------------------------------------------------ > > public class InlineTest { > interface Foo { > public boolean check(int generation); > } > > static class AbstractFoo implements Foo { > private final int value; > > protected AbstractFoo(int value) { > this.value = value; > } > > public boolean check(int generation) { > return this.getClass().hashCode() - value == generation; > } > } > > static class A extends AbstractFoo { > public A(int value) { > super(value); > } > } > static class B extends AbstractFoo { > public B(int value) { > super(value); > } > } > static class C extends AbstractFoo { > public C(int value) { > super(value); > } > } > > private static final int CONST = A.class.hashCode(); > > private static int count; > > private static void test(Foo foo) { > if (foo.check(0)) { > count += 2; > //System.out.println("foo"); > } else { > count += 1; > //System.out.println("bar"); > } > } > > public static void main(String[] args) { > Foo[] array = new Foo[100000]; > int threshold = 20000; > for(int i=0; i array[i] = new A(CONST); > } > > for(int i=threshold; i array[i] = (i%2 == 0)? new B(0): new C(CONST); > } > > for(int i=0; i test(array[i]); > } > > System.out.println(count); > } > } From igor.veresov at oracle.com Tue Sep 21 13:29:39 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 21 Sep 2010 13:29:39 -0700 Subject: Request for review(S): 6986270: guarantee(*bcp != Bytecodes::_monitorenter || exec_mode != Deoptimization::Unpack_exception) fails In-Reply-To: <1F758CCE-1108-4579-B465-8BF3BC686AF8@oracle.com> References: <4C981D69.5060908@oracle.com> <1F758CCE-1108-4579-B465-8BF3BC686AF8@oracle.com> Message-ID: <4C9915B3.1000103@oracle.com> Thanks, Tom and John! igor On 9/21/10 12:35 PM, Tom Rodriguez wrote: > It's a bit ugly but I don't see a simpler fix. Looks good. > > tom > > On Sep 20, 2010, at 7:50 PM, Igor Veresov wrote: > >> This guarantee should hold true for C2 but is not necessarily true for C1. The fix is to propagate the compiler type of the deopting method to vframeArrayElement::unpack_on_stack() and apply the guarantee only to c2-compiled methods. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6986270/webrev.00/ >> >> >> Thanks, >> igor > From igor.veresov at oracle.com Tue Sep 21 17:57:13 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 22 Sep 2010 00:57:13 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6986270: guarantee(*bcp != Bytecodes::_monitorenter || exec_mode != Deoptimization::Unpack_exception) fails Message-ID: <20100922005717.1DDB347B42@hg.openjdk.java.net> Changeset: fd5d4527cdf5 Author: iveresov Date: 2010-09-21 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fd5d4527cdf5 6986270: guarantee(*bcp != Bytecodes::_monitorenter || exec_mode != Deoptimization::Unpack_exception) fails Summary: Propagate the compiler type of the deopting method to vframeArrayElement::unpack_on_stack() Reviewed-by: jrose, never ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframeArray.cpp From forax at univ-mlv.fr Wed Sep 22 02:30:39 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 22 Sep 2010 11:30:39 +0200 Subject: More on: Small static method marked not entrant, inlining reversed? In-Reply-To: <87FC3F7B-295E-42B7-B4F4-4B6791D7617A@oracle.com> References: <4C950417.3030501@univ-mlv.fr> <87FC3F7B-295E-42B7-B4F4-4B6791D7617A@oracle.com> Message-ID: <4C99CCBF.4080204@univ-mlv.fr> Le 21/09/2010 21:48, Tom Rodriguez a ?crit : > Thanks for the test case. The reason it works well for C1 is that we have an explicit check for single implementor interfaces and insert an extra checkcast to confirm that the type really is the type we expect. The extra check is needed since interface types aren't actually checked by the verifier. In your example the extra check isn't actually needed since all array stores are actually type checked so any type loaded from the array must actually implement the interface. C2 generally relies on type profiling to get cases like this but since type profiling is tracking the type of the receiver instead of the actual method being invoked it doesn't handle this case that well. It's not hard to do something better for this case. I filed 6986483 for this. > > tom > Thanks Tom, I know since a long time that the verifier doesn't check interface but I have discovered recently the runtime implication. I wonder if the fix can improve performance of benchmarks that use java.util collection, because this API uses a similar class hierarchy scheme. R?mi > On Sep 18, 2010, at 11:25 AM, R?mi Forax wrote: > > >> I take a little time to create a simple test case to reproduce a bug >> found by Charles Nutter with c2. >> see http://groups.google.com/group/jvm-languages/browse_thread/thread/6c9e05ecd28fdcd4# >> >> Here is the test case, >> There is 3 classes A, B, C that inherit from AbstractFoo that implements Foo. >> The method test do a virtual call to check() and because >> check() is implemented in AbstractFoo we expect that this call should be >> de-virtualized then inlined. >> >> c2 fails, foo.check() is compiled as a virtual call :( >> With c1, there is no problem, CHA works correctly. >> >> R?mi >> >> ------------------------------------------------------------------------------------------------ >> >> public class InlineTest { >> interface Foo { >> public boolean check(int generation); >> } >> >> static class AbstractFoo implements Foo { >> private final int value; >> >> protected AbstractFoo(int value) { >> this.value = value; >> } >> >> public boolean check(int generation) { >> return this.getClass().hashCode() - value == generation; >> } >> } >> >> static class A extends AbstractFoo { >> public A(int value) { >> super(value); >> } >> } >> static class B extends AbstractFoo { >> public B(int value) { >> super(value); >> } >> } >> static class C extends AbstractFoo { >> public C(int value) { >> super(value); >> } >> } >> >> private static final int CONST = A.class.hashCode(); >> >> private static int count; >> >> private static void test(Foo foo) { >> if (foo.check(0)) { >> count += 2; >> //System.out.println("foo"); >> } else { >> count += 1; >> //System.out.println("bar"); >> } >> } >> >> public static void main(String[] args) { >> Foo[] array = new Foo[100000]; >> int threshold = 20000; >> for(int i=0; i> array[i] = new A(CONST); >> } >> >> for(int i=threshold; i> array[i] = (i%2 == 0)? new B(0): new C(CONST); >> } >> >> for(int i=0; i> test(array[i]); >> } >> >> System.out.println(count); >> } >> } >> > From rasbold at google.com Wed Sep 22 09:47:57 2010 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 22 Sep 2010 09:47:57 -0700 Subject: 64 bit and safepoint polling Message-ID: In a 64 bit JVM, when the polling page is more than a 32 displacement from the codeCache, does the code generated by C2 for safepoint polling work correctly? If not, should there be a guarantee in JVM startup about the maximum displacement supported? -- Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100922/1c37e103/attachment.html From tom.rodriguez at oracle.com Wed Sep 22 10:15:00 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 10:15:00 -0700 Subject: 64 bit and safepoint polling In-Reply-To: References: Message-ID: <1E21E151-4D05-438A-96AA-F29F9BE9AF82@oracle.com> No it doesn't work correctly. I think I filed a bug about this a little while ago but I can't find it at the moment. The code should just be updated to handle it properly though we'd really like to ensure that it isn't far away since it makes the polling code sequence a lot worse. I'd considered something like allocating the polling page out of the code cache to make sure it's near but that doesn't work that well if we use large pages for the code cache. Maybe there's a way to make it work though. Have you hit this problem? tom On Sep 22, 2010, at 9:47 AM, Chuck Rasbold wrote: > In a 64 bit JVM, when the polling page is more than a 32 displacement from the codeCache, does the code generated by C2 for safepoint polling work correctly? > > If not, should there be a guarantee in JVM startup about the maximum displacement supported? > > -- Chuck From rasbold at google.com Wed Sep 22 10:34:21 2010 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 22 Sep 2010 10:34:21 -0700 Subject: 64 bit and safepoint polling In-Reply-To: <1E21E151-4D05-438A-96AA-F29F9BE9AF82@oracle.com> References: <1E21E151-4D05-438A-96AA-F29F9BE9AF82@oracle.com> Message-ID: I'm seeing a problem as a result of a collection of factors. We have an internal agent (on by default), on a particular Linux release, when running under make, provokes an odd memory pattern with a large displacement between the polling page and the CodeCache. So... Queens fails when the safepoint poll is executed. We haven't seen the problem under other circumstances, so it isn't a pressing need. But the Queens crashing is annoying and a guarantee would be nice. Orthogonally, the cause of the strange layout is of concern here. I also thought about moving the polling page into the code cache. Do you think a single large page will impact the code cache significantly? On Wed, Sep 22, 2010 at 10:15 AM, Tom Rodriguez wrote: > No it doesn't work correctly. I think I filed a bug about this a little > while ago but I can't find it at the moment. The code should just be > updated to handle it properly though we'd really like to ensure that it > isn't far away since it makes the polling code sequence a lot worse. I'd > considered something like allocating the polling page out of the code cache > to make sure it's near but that doesn't work that well if we use large pages > for the code cache. Maybe there's a way to make it work though. Have you > hit this problem? > > tom > > On Sep 22, 2010, at 9:47 AM, Chuck Rasbold wrote: > > > In a 64 bit JVM, when the polling page is more than a 32 displacement > from the codeCache, does the code generated by C2 for safepoint polling work > correctly? > > > > If not, should there be a guarantee in JVM startup about the maximum > displacement supported? > > > > -- Chuck > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100922/bf3ed8ac/attachment-0001.html From tom.rodriguez at oracle.com Wed Sep 22 10:36:18 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 10:36:18 -0700 Subject: review (S) for 6982537: Crash in Node*step_through_mergemem Message-ID: <1D24A95A-C3E7-411C-80FB-EE2788B9CDCD@oracle.com> http://cr.openjdk.java.net/~never/6982537 6982537: Crash in Node*step_through_mergemem Reviewed-by: Code which was examining the type of memory was attempting to introspect on the klass of TypeOopPtr but wasn't checking for NULL which led to crashes when it looked at a primitive array type. The fix is to check for NULL. I also updated similar code in escape.cpp and corrected variable names to match the types. Tested with failing test from bug report. src/share/vm/opto/memnode.cpp src/share/vm/opto/escape.cpp From tom.rodriguez at oracle.com Wed Sep 22 10:36:06 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 10:36:06 -0700 Subject: More on: Small static method marked not entrant, inlining reversed? In-Reply-To: <4C99CCBF.4080204@univ-mlv.fr> References: <4C950417.3030501@univ-mlv.fr> <87FC3F7B-295E-42B7-B4F4-4B6791D7617A@oracle.com> <4C99CCBF.4080204@univ-mlv.fr> Message-ID: On Sep 22, 2010, at 2:30 AM, R?mi Forax wrote: > Le 21/09/2010 21:48, Tom Rodriguez a ?crit : >> Thanks for the test case. The reason it works well for C1 is that we have an explicit check for single implementor interfaces and insert an extra checkcast to confirm that the type really is the type we expect. The extra check is needed since interface types aren't actually checked by the verifier. In your example the extra check isn't actually needed since all array stores are actually type checked so any type loaded from the array must actually implement the interface. C2 generally relies on type profiling to get cases like this but since type profiling is tracking the type of the receiver instead of the actual method being invoked it doesn't handle this case that well. It's not hard to do something better for this case. I filed 6986483 for this. >> >> tom >> > > Thanks Tom, > I know since a long time that the verifier doesn't check interface but > I have discovered recently the runtime implication. Yes it's a bummer. We've discussed improving C2s type system to handle interface types better since in some cases interfaces type can be trusted. Adding some static verification of interfaces would also allow us to trust them more which could help. > > I wonder if the fix can improve performance of benchmarks that use java.util collection, > because this API uses a similar class hierarchy scheme. There are normally more than 1 or 2 implementors of the collection interfaces so static information isn't as useful. Much of the time the existing type profiling works great because we're only seeing a single type but of course there are cases where it falls down. Analyzing the hierarchy of the types that show up in the type profile might allow us to do a slightly better job but I suspect we'd have to modify our profile collection to record more types or to record methods instead of classes if we want to handle more complex call sites. tom > > R?mi > >> On Sep 18, 2010, at 11:25 AM, R?mi Forax wrote: >> >> >>> I take a little time to create a simple test case to reproduce a bug >>> found by Charles Nutter with c2. >>> see http://groups.google.com/group/jvm-languages/browse_thread/thread/6c9e05ecd28fdcd4# >>> >>> Here is the test case, >>> There is 3 classes A, B, C that inherit from AbstractFoo that implements Foo. >>> The method test do a virtual call to check() and because >>> check() is implemented in AbstractFoo we expect that this call should be >>> de-virtualized then inlined. >>> >>> c2 fails, foo.check() is compiled as a virtual call :( >>> With c1, there is no problem, CHA works correctly. >>> >>> R?mi >>> >>> ------------------------------------------------------------------------------------------------ >>> >>> public class InlineTest { >>> interface Foo { >>> public boolean check(int generation); >>> } >>> >>> static class AbstractFoo implements Foo { >>> private final int value; >>> >>> protected AbstractFoo(int value) { >>> this.value = value; >>> } >>> >>> public boolean check(int generation) { >>> return this.getClass().hashCode() - value == generation; >>> } >>> } >>> >>> static class A extends AbstractFoo { >>> public A(int value) { >>> super(value); >>> } >>> } >>> static class B extends AbstractFoo { >>> public B(int value) { >>> super(value); >>> } >>> } >>> static class C extends AbstractFoo { >>> public C(int value) { >>> super(value); >>> } >>> } >>> >>> private static final int CONST = A.class.hashCode(); >>> >>> private static int count; >>> >>> private static void test(Foo foo) { >>> if (foo.check(0)) { >>> count += 2; >>> //System.out.println("foo"); >>> } else { >>> count += 1; >>> //System.out.println("bar"); >>> } >>> } >>> >>> public static void main(String[] args) { >>> Foo[] array = new Foo[100000]; >>> int threshold = 20000; >>> for(int i=0; i>> array[i] = new A(CONST); >>> } >>> >>> for(int i=threshold; i>> array[i] = (i%2 == 0)? new B(0): new C(CONST); >>> } >>> >>> for(int i=0; i>> test(array[i]); >>> } >>> >>> System.out.println(count); >>> } >>> } >>> >> > From tom.rodriguez at oracle.com Wed Sep 22 10:42:16 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 10:42:16 -0700 Subject: 64 bit and safepoint polling In-Reply-To: References: <1E21E151-4D05-438A-96AA-F29F9BE9AF82@oracle.com> Message-ID: <3E72A22B-CA26-47D2-82CC-7B23D38D86E1@oracle.com> On Sep 22, 2010, at 10:34 AM, Chuck Rasbold wrote: > I'm seeing a problem as a result of a collection of factors. We have an internal agent (on by default), on a particular Linux release, when running under make, provokes an odd memory pattern with a large displacement between the polling page and the CodeCache. So... Queens fails when the safepoint poll is executed. > > We haven't seen the problem under other circumstances, so it isn't a pressing need. But the Queens crashing is annoying and a guarantee would be nice. It does seem to be rare since we've only just seen a report of it and it's been a problem all along. I'll try to push out the fix sometime soon since it's an annoyance. > > Orthogonally, the cause of the strange layout is of concern here. > > I also thought about moving the polling page into the code cache. Do you think a single large page will impact the code cache significantly? It chews up physical memory for no good reason and large pages can be very large. I don't know what the large page support in the code cache is like though. Maybe we can tack a small page on at the end. tom > > > On Wed, Sep 22, 2010 at 10:15 AM, Tom Rodriguez wrote: > No it doesn't work correctly. I think I filed a bug about this a little while ago but I can't find it at the moment. The code should just be updated to handle it properly though we'd really like to ensure that it isn't far away since it makes the polling code sequence a lot worse. I'd considered something like allocating the polling page out of the code cache to make sure it's near but that doesn't work that well if we use large pages for the code cache. Maybe there's a way to make it work though. Have you hit this problem? > > tom > > On Sep 22, 2010, at 9:47 AM, Chuck Rasbold wrote: > > > In a 64 bit JVM, when the polling page is more than a 32 displacement from the codeCache, does the code generated by C2 for safepoint polling work correctly? > > > > If not, should there be a guarantee in JVM startup about the maximum displacement supported? > > > > -- Chuck > > From vladimir.kozlov at oracle.com Wed Sep 22 10:53:11 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Sep 2010 10:53:11 -0700 Subject: 64 bit and safepoint polling In-Reply-To: <3E72A22B-CA26-47D2-82CC-7B23D38D86E1@oracle.com> References: <1E21E151-4D05-438A-96AA-F29F9BE9AF82@oracle.com> <3E72A22B-CA26-47D2-82CC-7B23D38D86E1@oracle.com> Message-ID: <4C9A4287.5090805@oracle.com> I don't think you need to use large page for polling even if codecache use large pages. We do the same trick with perm gen and the rest of java heap where we use smaller page size for perm gen. Vladimir Tom Rodriguez wrote: > On Sep 22, 2010, at 10:34 AM, Chuck Rasbold wrote: > >> I'm seeing a problem as a result of a collection of factors. We have an internal agent (on by default), on a particular Linux release, when running under make, provokes an odd memory pattern with a large displacement between the polling page and the CodeCache. So... Queens fails when the safepoint poll is executed. >> >> We haven't seen the problem under other circumstances, so it isn't a pressing need. But the Queens crashing is annoying and a guarantee would be nice. > > It does seem to be rare since we've only just seen a report of it and it's been a problem all along. I'll try to push out the fix sometime soon since it's an annoyance. > >> Orthogonally, the cause of the strange layout is of concern here. >> >> I also thought about moving the polling page into the code cache. Do you think a single large page will impact the code cache significantly? > > It chews up physical memory for no good reason and large pages can be very large. I don't know what the large page support in the code cache is like though. Maybe we can tack a small page on at the end. > > tom > >> >> On Wed, Sep 22, 2010 at 10:15 AM, Tom Rodriguez wrote: >> No it doesn't work correctly. I think I filed a bug about this a little while ago but I can't find it at the moment. The code should just be updated to handle it properly though we'd really like to ensure that it isn't far away since it makes the polling code sequence a lot worse. I'd considered something like allocating the polling page out of the code cache to make sure it's near but that doesn't work that well if we use large pages for the code cache. Maybe there's a way to make it work though. Have you hit this problem? >> >> tom >> >> On Sep 22, 2010, at 9:47 AM, Chuck Rasbold wrote: >> >>> In a 64 bit JVM, when the polling page is more than a 32 displacement from the codeCache, does the code generated by C2 for safepoint polling work correctly? >>> >>> If not, should there be a guarantee in JVM startup about the maximum displacement supported? >>> >>> -- Chuck >> > From vladimir.kozlov at oracle.com Wed Sep 22 10:59:21 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Sep 2010 10:59:21 -0700 Subject: review (S) for 6982537: Crash in Node*step_through_mergemem In-Reply-To: <1D24A95A-C3E7-411C-80FB-EE2788B9CDCD@oracle.com> References: <1D24A95A-C3E7-411C-80FB-EE2788B9CDCD@oracle.com> Message-ID: <4C9A43F9.7040706@oracle.com> Thank you, Tom, for fixing this. Few notes. In escape.cpp TypeInstPtr was not renamed in the comment. Also check for "memcpy" is not related to this changes. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6982537 > > 6982537: Crash in Node*step_through_mergemem > Reviewed-by: > > Code which was examining the type of memory was attempting to > introspect on the klass of TypeOopPtr but wasn't checking for NULL > which led to crashes when it looked at a primitive array type. The > fix is to check for NULL. I also updated similar code in escape.cpp > and corrected variable names to match the types. Tested with failing > test from bug report. > > src/share/vm/opto/memnode.cpp > src/share/vm/opto/escape.cpp From forax at univ-mlv.fr Wed Sep 22 11:36:32 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 22 Sep 2010 20:36:32 +0200 Subject: More on: Small static method marked not entrant, inlining reversed? In-Reply-To: References: <4C950417.3030501@univ-mlv.fr> <87FC3F7B-295E-42B7-B4F4-4B6791D7617A@oracle.com> <4C99CCBF.4080204@univ-mlv.fr> Message-ID: <4C9A4CB0.50709@univ-mlv.fr> Le 22/09/2010 19:36, Tom Rodriguez a ?crit : > On Sep 22, 2010, at 2:30 AM, R?mi Forax wrote: > > >> Le 21/09/2010 21:48, Tom Rodriguez a ?crit : >> >>> Thanks for the test case. The reason it works well for C1 is that we have an explicit check for single implementor interfaces and insert an extra checkcast to confirm that the type really is the type we expect. The extra check is needed since interface types aren't actually checked by the verifier. In your example the extra check isn't actually needed since all array stores are actually type checked so any type loaded from the array must actually implement the interface. C2 generally relies on type profiling to get cases like this but since type profiling is tracking the type of the receiver instead of the actual method being invoked it doesn't handle this case that well. It's not hard to do something better for this case. I filed 6986483 for this. >>> >>> tom >>> >>> >> Thanks Tom, >> I know since a long time that the verifier doesn't check interface but >> I have discovered recently the runtime implication. >> > Yes it's a bummer. We've discussed improving C2s type system to handle interface types better since in some cases interfaces type can be trusted. Adding some static verification of interfaces would also allow us to trust them more which could help. > > >> I wonder if the fix can improve performance of benchmarks that use java.util collection, >> because this API uses a similar class hierarchy scheme. >> > There are normally more than 1 or 2 implementors of the collection interfaces so static information isn't as useful. Much of the time the existing type profiling works great because we're only seeing a single type but of course there are cases where it falls down. Yes but most of collections inherits from an abstract class, AbstractList, AbstractCollection etc, so even if there are more than 2 implementors, they can inherits from the same abstract class. > Analyzing the hierarchy of the types that show up in the type profile might allow us to do a slightly better job but I suspect we'd have to modify our profile collection to record more types or to record methods instead of classes if we want to handle more complex call sites. > You don't have to record methods if you maintain pointers from an abstract method and their implementations. If there is only one implementation, you even don't need to use type profiles. You can also improve type profiling if there are more than 2 types by trying to find if all types have a common supertype which is more precise that the receiver type. As I previously said, this is a common pattern when using collection. And when JITing, if all loaded subtypes of the common supertype have one implementation for the method declared at callsite, you can install an instanceof guard on that common supertype and safely inline the implementation. You also need to deopt if a new subtype is loaded with a new method implementation. > tom > > R?mi From tom.rodriguez at oracle.com Wed Sep 22 12:23:52 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 12:23:52 -0700 Subject: review (S) for 6982537: Crash in Node*step_through_mergemem In-Reply-To: <4C9A43F9.7040706@oracle.com> References: <1D24A95A-C3E7-411C-80FB-EE2788B9CDCD@oracle.com> <4C9A43F9.7040706@oracle.com> Message-ID: On Sep 22, 2010, at 10:59 AM, Vladimir Kozlov wrote: > Thank you, Tom, for fixing this. > > Few notes. > In escape.cpp TypeInstPtr was not renamed in the comment. > Also check for "memcpy" is not related to this changes. That was a mistake during transplantation. Fixed. tom > > Thanks, > Vladimir > > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6982537 >> 6982537: Crash in Node*step_through_mergemem >> Reviewed-by: >> Code which was examining the type of memory was attempting to >> introspect on the klass of TypeOopPtr but wasn't checking for NULL >> which led to crashes when it looked at a primitive array type. The >> fix is to check for NULL. I also updated similar code in escape.cpp >> and corrected variable names to match the types. Tested with failing >> test from bug report. >> src/share/vm/opto/memnode.cpp >> src/share/vm/opto/escape.cpp From vladimir.kozlov at oracle.com Wed Sep 22 12:26:12 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Sep 2010 12:26:12 -0700 Subject: review (S) for 6982537: Crash in Node*step_through_mergemem In-Reply-To: References: <1D24A95A-C3E7-411C-80FB-EE2788B9CDCD@oracle.com> <4C9A43F9.7040706@oracle.com> Message-ID: <4C9A5854.9040503@oracle.com> Looks good. Thanks, Vladimir Tom Rodriguez wrote: > On Sep 22, 2010, at 10:59 AM, Vladimir Kozlov wrote: > >> Thank you, Tom, for fixing this. >> >> Few notes. >> In escape.cpp TypeInstPtr was not renamed in the comment. >> Also check for "memcpy" is not related to this changes. > > That was a mistake during transplantation. Fixed. > > tom > >> Thanks, >> Vladimir >> >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6982537 >>> 6982537: Crash in Node*step_through_mergemem >>> Reviewed-by: >>> Code which was examining the type of memory was attempting to >>> introspect on the klass of TypeOopPtr but wasn't checking for NULL >>> which led to crashes when it looked at a primitive array type. The >>> fix is to check for NULL. I also updated similar code in escape.cpp >>> and corrected variable names to match the types. Tested with failing >>> test from bug report. >>> src/share/vm/opto/memnode.cpp >>> src/share/vm/opto/escape.cpp > From tom.rodriguez at oracle.com Wed Sep 22 13:10:45 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 13:10:45 -0700 Subject: review (S) for 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub Message-ID: http://cr.openjdk.java.net/~never/6986028 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub Reviewed-by: One of the places where a method is being matched wasn't checking the signature so it picked up an argument of the wrong type which resulted in errors when we tried to do math on it. I changed it to use the intrinsic id and fixed a couple others to also use the intrinsic id. I checked the other sites to make sure they were checking the signature as well and added non static as well. Tested with failing test from report. From tom.rodriguez at oracle.com Wed Sep 22 13:24:03 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 13:24:03 -0700 Subject: More on: Small static method marked not entrant, inlining reversed? In-Reply-To: <4C9A4CB0.50709@univ-mlv.fr> References: <4C950417.3030501@univ-mlv.fr> <87FC3F7B-295E-42B7-B4F4-4B6791D7617A@oracle.com> <4C99CCBF.4080204@univ-mlv.fr> <4C9A4CB0.50709@univ-mlv.fr> Message-ID: <8421E257-174F-4506-806E-CD6F5A5884F0@oracle.com> >> >>> I wonder if the fix can improve performance of benchmarks that use java.util collection, >>> because this API uses a similar class hierarchy scheme. >>> >> There are normally more than 1 or 2 implementors of the collection interfaces so static information isn't as useful. Much of the time the existing type profiling works great because we're only seeing a single type but of course there are cases where it falls down. > > Yes but most of collections inherits from an abstract class, AbstractList, AbstractCollection etc, > so even if there are more than 2 implementors, they can inherits from the same abstract class. Collections.java by itself contains 3 unique implementors of the each of the core collection interface to support checked, unmodifiable and synchronized variants. These are unrelated to the abstract classes you mention above. java.util.concurrent includes yet more unrelated variants. So looking at the hierarchy is of little use for most of those interface types. Anyway we can obviously do better than we are currently doing. tom > >> Analyzing the hierarchy of the types that show up in the type profile might allow us to do a slightly better job but I suspect we'd have to modify our profile collection to record more types or to record methods instead of classes if we want to handle more complex call sites. >> > > You don't have to record methods if you maintain pointers from an abstract method and their > implementations. If there is only one implementation, you even don't need to use > type profiles. > > You can also improve type profiling if there are more than 2 types > by trying to find if all types have a common supertype which is more > precise that the receiver type. > As I previously said, this is a common pattern when using collection. > > And when JITing, if all loaded subtypes of the common supertype > have one implementation for the method declared at callsite, > you can install an instanceof guard on that common supertype > and safely inline the implementation. You also need to deopt > if a new subtype is loaded with a new method implementation. > >> tom >> >> > > R?mi From christian.thalinger at oracle.com Wed Sep 22 13:25:28 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 22 Sep 2010 22:25:28 +0200 Subject: review (S) for 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub In-Reply-To: References: Message-ID: <1285187128.14822.3906.camel@macbook> On Wed, 2010-09-22 at 13:10 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6986028 > > 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub > Reviewed-by: > > One of the places where a method is being matched wasn't checking the > signature so it picked up an argument of the wrong type which resulted > in errors when we tried to do math on it. I changed it to use the > intrinsic id and fixed a couple others to also use the intrinsic id. > I checked the other sites to make sure they were checking the > signature as well and added non static as well. Tested with failing > test from report. Looks good. -- Christian From tom.rodriguez at oracle.com Wed Sep 22 13:34:41 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 13:34:41 -0700 Subject: 64 bit and safepoint polling In-Reply-To: <4C9A4287.5090805@oracle.com> References: <1E21E151-4D05-438A-96AA-F29F9BE9AF82@oracle.com> <3E72A22B-CA26-47D2-82CC-7B23D38D86E1@oracle.com> <4C9A4287.5090805@oracle.com> Message-ID: You think we can use the noaccess_prefix stuff to get the space we need? It looks like in some cases we will fall back to using large pages for the noaccess prefix. Am I reading that right? The logic in ReservedSpace is fairly complicated. tom On Sep 22, 2010, at 10:53 AM, Vladimir Kozlov wrote: > I don't think you need to use large page for polling even if codecache use large pages. > We do the same trick with perm gen and the rest of java heap where we use smaller page > size for perm gen. > > Vladimir > > Tom Rodriguez wrote: >> On Sep 22, 2010, at 10:34 AM, Chuck Rasbold wrote: >>> I'm seeing a problem as a result of a collection of factors. We have an internal agent (on by default), on a particular Linux release, when running under make, provokes an odd memory pattern with a large displacement between the polling page and the CodeCache. So... Queens fails when the safepoint poll is executed. >>> >>> We haven't seen the problem under other circumstances, so it isn't a pressing need. But the Queens crashing is annoying and a guarantee would be nice. >> It does seem to be rare since we've only just seen a report of it and it's been a problem all along. I'll try to push out the fix sometime soon since it's an annoyance. >>> Orthogonally, the cause of the strange layout is of concern here. >>> >>> I also thought about moving the polling page into the code cache. Do you think a single large page will impact the code cache significantly? >> It chews up physical memory for no good reason and large pages can be very large. I don't know what the large page support in the code cache is like though. Maybe we can tack a small page on at the end. >> tom >>> >>> On Wed, Sep 22, 2010 at 10:15 AM, Tom Rodriguez wrote: >>> No it doesn't work correctly. I think I filed a bug about this a little while ago but I can't find it at the moment. The code should just be updated to handle it properly though we'd really like to ensure that it isn't far away since it makes the polling code sequence a lot worse. I'd considered something like allocating the polling page out of the code cache to make sure it's near but that doesn't work that well if we use large pages for the code cache. Maybe there's a way to make it work though. Have you hit this problem? >>> >>> tom >>> >>> On Sep 22, 2010, at 9:47 AM, Chuck Rasbold wrote: >>> >>>> In a 64 bit JVM, when the polling page is more than a 32 displacement from the codeCache, does the code generated by C2 for safepoint polling work correctly? >>>> >>>> If not, should there be a guarantee in JVM startup about the maximum displacement supported? >>>> >>>> -- Chuck >>> From christian.thalinger at oracle.com Wed Sep 22 13:34:04 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 22 Sep 2010 22:34:04 +0200 Subject: review (S) for 6982537: Crash in Node*step_through_mergemem In-Reply-To: References: <1D24A95A-C3E7-411C-80FB-EE2788B9CDCD@oracle.com> <4C9A43F9.7040706@oracle.com> Message-ID: <1285187644.14822.3916.camel@macbook> On Wed, 2010-09-22 at 12:23 -0700, Tom Rodriguez wrote: > On Sep 22, 2010, at 10:59 AM, Vladimir Kozlov wrote: > > > Thank you, Tom, for fixing this. > > > > Few notes. > > In escape.cpp TypeInstPtr was not renamed in the comment. > > Also check for "memcpy" is not related to this changes. > > That was a mistake during transplantation. Fixed. Looks good. -- Christian From tom.rodriguez at oracle.com Wed Sep 22 13:34:57 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 13:34:57 -0700 Subject: review (S) for 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub In-Reply-To: <1285187128.14822.3906.camel@macbook> References: <1285187128.14822.3906.camel@macbook> Message-ID: Thanks! tom On Sep 22, 2010, at 1:25 PM, Christian Thalinger wrote: > On Wed, 2010-09-22 at 13:10 -0700, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6986028 >> >> 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub >> Reviewed-by: >> >> One of the places where a method is being matched wasn't checking the >> signature so it picked up an argument of the wrong type which resulted >> in errors when we tried to do math on it. I changed it to use the >> intrinsic id and fixed a couple others to also use the intrinsic id. >> I checked the other sites to make sure they were checking the >> signature as well and added non static as well. Tested with failing >> test from report. > > Looks good. -- Christian > From vladimir.kozlov at oracle.com Wed Sep 22 13:34:01 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Sep 2010 13:34:01 -0700 Subject: review (S) for 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub In-Reply-To: References: Message-ID: <4C9A6839.3040604@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6986028 > > 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub > Reviewed-by: > > One of the places where a method is being matched wasn't checking the > signature so it picked up an argument of the wrong type which resulted > in errors when we tried to do math on it. I changed it to use the > intrinsic id and fixed a couple others to also use the intrinsic id. > I checked the other sites to make sure they were checking the > signature as well and added non static as well. Tested with failing > test from report. From tom.rodriguez at oracle.com Wed Sep 22 13:41:26 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 13:41:26 -0700 Subject: Request for reviews (L): 6986046 C1 ValueStack cleanup In-Reply-To: References: Message-ID: <0C0D64FC-6B29-473C-911B-533F2D5B6A6E@oracle.com> Looks good. tom On Sep 21, 2010, at 2:03 AM, Roland Westrelin wrote: > > Cleanup contributed by Christian Wimmer to the C1 ValueStack. > > http://cr.openjdk.java.net/~roland/6986046/webrev.00/ > > Roland. From vladimir.kozlov at oracle.com Wed Sep 22 14:00:08 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Sep 2010 14:00:08 -0700 Subject: 64 bit and safepoint polling In-Reply-To: References: <1E21E151-4D05-438A-96AA-F29F9BE9AF82@oracle.com> <3E72A22B-CA26-47D2-82CC-7B23D38D86E1@oracle.com> <4C9A4287.5090805@oracle.com> Message-ID: <4C9A6E58.4010903@oracle.com> I mean we can first reserve memory for (codecache_size + 1) in large pages to get continues space. After that we can release first page and ask again to reserver small polling page at that released space. But windows may not allow to do it. Or we can simple ask (in a loop until we get it) OS to reserver small polling page after codecache at given address range which is not larger then 4Gb, we don't need to have this page on the border of codecache. Vladimir Tom Rodriguez wrote: > You think we can use the noaccess_prefix stuff to get the space we need? It looks like in some cases we will fall back to using large pages for the noaccess prefix. Am I reading that right? The logic in ReservedSpace is fairly complicated. > > tom > > On Sep 22, 2010, at 10:53 AM, Vladimir Kozlov wrote: > >> I don't think you need to use large page for polling even if codecache use large pages. >> We do the same trick with perm gen and the rest of java heap where we use smaller page >> size for perm gen. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> On Sep 22, 2010, at 10:34 AM, Chuck Rasbold wrote: >>>> I'm seeing a problem as a result of a collection of factors. We have an internal agent (on by default), on a particular Linux release, when running under make, provokes an odd memory pattern with a large displacement between the polling page and the CodeCache. So... Queens fails when the safepoint poll is executed. >>>> >>>> We haven't seen the problem under other circumstances, so it isn't a pressing need. But the Queens crashing is annoying and a guarantee would be nice. >>> It does seem to be rare since we've only just seen a report of it and it's been a problem all along. I'll try to push out the fix sometime soon since it's an annoyance. >>>> Orthogonally, the cause of the strange layout is of concern here. >>>> >>>> I also thought about moving the polling page into the code cache. Do you think a single large page will impact the code cache significantly? >>> It chews up physical memory for no good reason and large pages can be very large. I don't know what the large page support in the code cache is like though. Maybe we can tack a small page on at the end. >>> tom >>>> On Wed, Sep 22, 2010 at 10:15 AM, Tom Rodriguez wrote: >>>> No it doesn't work correctly. I think I filed a bug about this a little while ago but I can't find it at the moment. The code should just be updated to handle it properly though we'd really like to ensure that it isn't far away since it makes the polling code sequence a lot worse. I'd considered something like allocating the polling page out of the code cache to make sure it's near but that doesn't work that well if we use large pages for the code cache. Maybe there's a way to make it work though. Have you hit this problem? >>>> >>>> tom >>>> >>>> On Sep 22, 2010, at 9:47 AM, Chuck Rasbold wrote: >>>> >>>>> In a 64 bit JVM, when the polling page is more than a 32 displacement from the codeCache, does the code generated by C2 for safepoint polling work correctly? >>>>> >>>>> If not, should there be a guarantee in JVM startup about the maximum displacement supported? >>>>> >>>>> -- Chuck > From tom.rodriguez at oracle.com Wed Sep 22 14:34:23 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 14:34:23 -0700 Subject: review (S) for 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld Message-ID: http://cr.openjdk.java.net/~never/6972540 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld Reviewed-by: The fix 6932496 exposed T_ADDRESS as a constant so that deopt with jsr's could work properly. Since it didn't fully expose T_ADDRESS as a support lir type it create type mismatches that showed up in some complex cases. The fix is support T_ADDRESS in the LIR directly. Tested with full CTW. From vladimir.kozlov at oracle.com Wed Sep 22 14:46:00 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Sep 2010 14:46:00 -0700 Subject: review (S) for 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld In-Reply-To: References: Message-ID: <4C9A7918.7020908@oracle.com> Tom, Changes looks good. Did you test 64-bit C1 which could be affected by these changes? Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6972540 > > 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld > Reviewed-by: > > The fix 6932496 exposed T_ADDRESS as a constant so that deopt with > jsr's could work properly. Since it didn't fully expose T_ADDRESS as > a support lir type it create type mismatches that showed up in some > complex cases. The fix is support T_ADDRESS in the LIR directly. > Tested with full CTW. From tom.rodriguez at oracle.com Wed Sep 22 14:49:42 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 14:49:42 -0700 Subject: review (S) for 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld In-Reply-To: <4C9A7918.7020908@oracle.com> References: <4C9A7918.7020908@oracle.com> Message-ID: <936DCA98-94A0-442F-B38D-90CED69264E1@oracle.com> On Sep 22, 2010, at 2:46 PM, Vladimir Kozlov wrote: > Tom, > > Changes looks good. > Did you test 64-bit C1 which could be affected by these changes? No i didn't but it's really about abstract typing in the LIR and doesn't effect code generation. I can run CTW if you want. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6972540 >> 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld >> Reviewed-by: >> The fix 6932496 exposed T_ADDRESS as a constant so that deopt with >> jsr's could work properly. Since it didn't fully expose T_ADDRESS as >> a support lir type it create type mismatches that showed up in some >> complex cases. The fix is support T_ADDRESS in the LIR directly. >> Tested with full CTW. From vladimir.kozlov at oracle.com Wed Sep 22 15:20:24 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Sep 2010 15:20:24 -0700 Subject: review (S) for 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld In-Reply-To: <936DCA98-94A0-442F-B38D-90CED69264E1@oracle.com> References: <4C9A7918.7020908@oracle.com> <936DCA98-94A0-442F-B38D-90CED69264E1@oracle.com> Message-ID: <4C9A8128.9080302@oracle.com> I did not know that it doesn't effect code generation. Then it is good to push. Thanks, Vladimir Tom Rodriguez wrote: > On Sep 22, 2010, at 2:46 PM, Vladimir Kozlov wrote: > >> Tom, >> >> Changes looks good. >> Did you test 64-bit C1 which could be affected by these changes? > > No i didn't but it's really about abstract typing in the LIR and doesn't effect code generation. I can run CTW if you want. > > tom > >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6972540 >>> 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld >>> Reviewed-by: >>> The fix 6932496 exposed T_ADDRESS as a constant so that deopt with >>> jsr's could work properly. Since it didn't fully expose T_ADDRESS as >>> a support lir type it create type mismatches that showed up in some >>> complex cases. The fix is support T_ADDRESS in the LIR directly. >>> Tested with full CTW. > From tom.rodriguez at oracle.com Wed Sep 22 15:51:55 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 15:51:55 -0700 Subject: review (S) for 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld In-Reply-To: <4C9A8128.9080302@oracle.com> References: <4C9A7918.7020908@oracle.com> <936DCA98-94A0-442F-B38D-90CED69264E1@oracle.com> <4C9A8128.9080302@oracle.com> Message-ID: Actually I may retract this. I think there might be a simpler way to handle this by changing the original fix for 6932496. We used to just treat T_ADDRESS as T_INT but that didn't allow deopt to work correctly because T_ADDRESS is pointer sized because of the use of astore. It seems like we should just be able to treat it as T_LONG in 64 bit and have it all work out fine. I'd rather not introduce T_ADDRESS into LIR_Opr just for this. tom On Sep 22, 2010, at 3:20 PM, Vladimir Kozlov wrote: > I did not know that it doesn't effect code generation. > Then it is good to push. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Sep 22, 2010, at 2:46 PM, Vladimir Kozlov wrote: >>> Tom, >>> >>> Changes looks good. >>> Did you test 64-bit C1 which could be affected by these changes? >> No i didn't but it's really about abstract typing in the LIR and doesn't effect code generation. I can run CTW if you want. >> tom >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6972540 >>>> 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld >>>> Reviewed-by: >>>> The fix 6932496 exposed T_ADDRESS as a constant so that deopt with >>>> jsr's could work properly. Since it didn't fully expose T_ADDRESS as >>>> a support lir type it create type mismatches that showed up in some >>>> complex cases. The fix is support T_ADDRESS in the LIR directly. >>>> Tested with full CTW. From puzzlesdj at gmail.com Wed Sep 22 17:02:28 2010 From: puzzlesdj at gmail.com (ddmetro) Date: Wed, 22 Sep 2010 17:02:28 -0700 (PDT) Subject: help on starting point of hotspot jvm Message-ID: <29785128.post@talk.nabble.com> Hi All, 1. I am trying to figure out the starting point (file whose main() method is invoked), when the following command is issued: >java Testfile I tried adding printfs to '/home/dhiraj/hotspot/icedtea/icedtea6-1.8/openjdk/hotspot/src/os/linux/launcher/java.c', however after executing the following command, the printfs didn't appear >make hotspot Question: am i trying with the incorrect starting point? 2. When i add printfs to the hotspot files, and execute >make hotspot the printfs don't appear. The build happens successfully and the libjvm.so at '/openjdk/build/linux-i586/j2re-image/lib/i386/server' is updated. Question: kindly inform if i am missing out on anything here. 3. I am looking at instruction scheduling phase and came across compile.cpp and output.cpp classes at 'openjdk/hotspot/src/share/vm/opto/' location. Question: i am unable to figure out which class calls the 'Compile()' method of Compile class. kindly point out - what am i missing in here. 4. I am trying to relate thread scheduling and instruction scheduling (a thread calling DoScheduling() method per input file method) I tried looking into jvm_linux.cpp, os_linux.cpp and osThread_linux.hpp at '/openjdk/hotspot/src/os/linux/vm/' location. However, couldnt relate these files with a call to DoScheduling() method. Question: Kindly help me relate thread scheduling and instruction scheduling. Thanking You for your patience, -Dhiraj. -- View this message in context: http://old.nabble.com/help-on-starting-point-of-hotspot-jvm-tp29785128p29785128.html Sent from the OpenJDK Hotspot Compiler Development List mailing list archive at Nabble.com. From tom.rodriguez at oracle.com Wed Sep 22 17:15:40 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Sep 2010 17:15:40 -0700 Subject: review (S) for 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld In-Reply-To: References: <4C9A7918.7020908@oracle.com> <936DCA98-94A0-442F-B38D-90CED69264E1@oracle.com> <4C9A8128.9080302@oracle.com> Message-ID: <762153D7-82AF-4FBB-AA0C-652A18578986@oracle.com> I just realized why this doesn't work. T_LONG is two local slots but T_ADDRESS is only one so to deopt properly you need a single slot 64 bit value which is what T_ADDRESS ends up representing. So I'm sticking with the fix as reviewed. Thanks! tom On Sep 22, 2010, at 3:51 PM, Tom Rodriguez wrote: > Actually I may retract this. I think there might be a simpler way to handle this by changing the original fix for 6932496. We used to just treat T_ADDRESS as T_INT but that didn't allow deopt to work correctly because T_ADDRESS is pointer sized because of the use of astore. It seems like we should just be able to treat it as T_LONG in 64 bit and have it all work out fine. I'd rather not introduce T_ADDRESS into LIR_Opr just for this. > > tom > > On Sep 22, 2010, at 3:20 PM, Vladimir Kozlov wrote: > >> I did not know that it doesn't effect code generation. >> Then it is good to push. >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> On Sep 22, 2010, at 2:46 PM, Vladimir Kozlov wrote: >>>> Tom, >>>> >>>> Changes looks good. >>>> Did you test 64-bit C1 which could be affected by these changes? >>> No i didn't but it's really about abstract typing in the LIR and doesn't effect code generation. I can run CTW if you want. >>> tom >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/6972540 >>>>> 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld >>>>> Reviewed-by: >>>>> The fix 6932496 exposed T_ADDRESS as a constant so that deopt with >>>>> jsr's could work properly. Since it didn't fully expose T_ADDRESS as >>>>> a support lir type it create type mismatches that showed up in some >>>>> complex cases. The fix is support T_ADDRESS in the LIR directly. >>>>> Tested with full CTW. > From john.r.rose at oracle.com Wed Sep 22 19:06:32 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 22 Sep 2010 19:06:32 -0700 Subject: More on: Small static method marked not entrant, inlining reversed? In-Reply-To: <8421E257-174F-4506-806E-CD6F5A5884F0@oracle.com> References: <4C950417.3030501@univ-mlv.fr> <87FC3F7B-295E-42B7-B4F4-4B6791D7617A@oracle.com> <4C99CCBF.4080204@univ-mlv.fr> <4C9A4CB0.50709@univ-mlv.fr> <8421E257-174F-4506-806E-CD6F5A5884F0@oracle.com> Message-ID: <0B4AED03-8266-47D2-B743-D85D65C1CBF7@oracle.com> On Sep 22, 2010, at 1:24 PM, Tom Rodriguez wrote: > So looking at the hierarchy is of little use for most of those interface types. CHA starts with the scope type at a use point and tries to prove that there is only one method in the scope. Profiling starts with the set of concrete precise types at a use point and tries to prove that there is only one method. CHA starts with scope types (often abstract) and searches downward. A downward search from an interface fails (always?): this should be fixed. Profiling starts with concrete types and currently fails if there is upward movement required. This should be fixed. You guys are right that a more complex profiling mechanism would probably capture what's needed. Basically, if the profile overflows, it could summarize with approximate information. More subtly, we could also profile the target method(s) instead of the receiver class(es). The guard for that would require a vtable probe. -- John From tom.rodriguez at oracle.com Wed Sep 22 19:15:01 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 23 Sep 2010 02:15:01 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6982537: Crash in Node*step_through_mergemem Message-ID: <20100923021507.51B7F47B89@hg.openjdk.java.net> Changeset: 5867d89c129b Author: never Date: 2010-09-22 13:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5867d89c129b 6982537: Crash in Node*step_through_mergemem Reviewed-by: kvn ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/memnode.cpp From tom.rodriguez at oracle.com Wed Sep 22 23:26:52 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 23 Sep 2010 06:26:52 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld Message-ID: <20100923062654.7596747B94@hg.openjdk.java.net> Changeset: 87b64980e2f1 Author: never Date: 2010-09-22 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/87b64980e2f1 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld Reviewed-by: kvn ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp From forax at univ-mlv.fr Thu Sep 23 00:33:59 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 23 Sep 2010 09:33:59 +0200 Subject: More on: Small static method marked not entrant, inlining reversed? In-Reply-To: <8421E257-174F-4506-806E-CD6F5A5884F0@oracle.com> References: <4C950417.3030501@univ-mlv.fr> <87FC3F7B-295E-42B7-B4F4-4B6791D7617A@oracle.com> <4C99CCBF.4080204@univ-mlv.fr> <4C9A4CB0.50709@univ-mlv.fr> <8421E257-174F-4506-806E-CD6F5A5884F0@oracle.com> Message-ID: <4C9B02E7.7080000@univ-mlv.fr> Le 22/09/2010 22:24, Tom Rodriguez a ?crit : >>> >>>> I wonder if the fix can improve performance of benchmarks that use java.util collection, >>>> because this API uses a similar class hierarchy scheme. >>>> >>>> >>> There are normally more than 1 or 2 implementors of the collection interfaces so static information isn't as useful. Much of the time the existing type profiling works great because we're only seeing a single type but of course there are cases where it falls down. >>> >> Yes but most of collections inherits from an abstract class, AbstractList, AbstractCollection etc, >> so even if there are more than 2 implementors, they can inherits from the same abstract class. >> > Collections.java by itself contains 3 unique implementors of the each of the core collection interface to support checked, unmodifiable and synchronized variants. These are unrelated to the abstract classes you mention above. java.util.concurrent includes yet more unrelated variants. So looking at the hierarchy is of little use for most of those interface types. Anyway we can obviously do better than we are currently doing. > > tom > > You're right about checked, unmodifiable and synchronized, but checked and synchronized variants are rarely used and unmodifiable should inherit from their abstract counterparts. Also note that single and empty variants inherit from abstract versions. For java.util.concurrent classes, queues (exactly blocking queues) are used in a polymorphic way, the other classes like ConcurrentHashMap, CopyOnWriteArraySet, etc are rarely involved in a polymorphic callsite. R?mi From christian.thalinger at oracle.com Thu Sep 23 00:38:09 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 23 Sep 2010 09:38:09 +0200 Subject: help on starting point of hotspot jvm In-Reply-To: <29785128.post@talk.nabble.com> References: <29785128.post@talk.nabble.com> Message-ID: <1285227489.14822.4030.camel@macbook> On Wed, 2010-09-22 at 17:02 -0700, ddmetro wrote: > Hi All, > > 1. I am trying to figure out the starting point (file whose main() method is > invoked), when the following command is issued: > >java Testfile > I tried adding printfs to > '/home/dhiraj/hotspot/icedtea/icedtea6-1.8/openjdk/hotspot/src/os/linux/launcher/java.c', > however after executing the following command, the printfs didn't appear > >make hotspot > > Question: am i trying with the incorrect starting point? The source file mentioned above is the source for the development launcher called "gamma". The file you're searching for is part of JDK: jdk/src/share/bin/java.c > > 2. When i add printfs to the hotspot files, and execute > >make hotspot > the printfs don't appear. The build happens successfully and the libjvm.so > at '/openjdk/build/linux-i586/j2re-image/lib/i386/server' is updated. > > Question: kindly inform if i am missing out on anything here. That's too hard to answer. Maybe the code you're instrumenting is not executed at all, or you're probably running (by accident?) the client compiler, or... > > 3. I am looking at instruction scheduling phase and came across compile.cpp > and output.cpp classes at 'openjdk/hotspot/src/share/vm/opto/' location. > > Question: i am unable to figure out which class calls the 'Compile()' method > of Compile class. kindly point out - what am i missing in here. So you mean the Compile constructor? I think what you are searching for is: src/share/vm/opto/c2compiler.cpp:111 > > 4. I am trying to relate thread scheduling and instruction scheduling (a > thread calling DoScheduling() method per input file method) > I tried looking into jvm_linux.cpp, os_linux.cpp and osThread_linux.hpp at > '/openjdk/hotspot/src/os/linux/vm/' location. > However, couldnt relate these files with a call to DoScheduling() method. > > Question: Kindly help me relate thread scheduling and instruction > scheduling. I'm not sure I understand... -- Christian From forax at univ-mlv.fr Thu Sep 23 01:49:06 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 23 Sep 2010 10:49:06 +0200 Subject: More on: Small static method marked not entrant, inlining reversed? In-Reply-To: <0B4AED03-8266-47D2-B743-D85D65C1CBF7@oracle.com> References: <4C950417.3030501@univ-mlv.fr> <87FC3F7B-295E-42B7-B4F4-4B6791D7617A@oracle.com> <4C99CCBF.4080204@univ-mlv.fr> <4C9A4CB0.50709@univ-mlv.fr> <8421E257-174F-4506-806E-CD6F5A5884F0@oracle.com> <0B4AED03-8266-47D2-B743-D85D65C1CBF7@oracle.com> Message-ID: <4C9B1482.8020600@univ-mlv.fr> Le 23/09/2010 04:06, John Rose a ?crit : > On Sep 22, 2010, at 1:24 PM, Tom Rodriguez wrote: > > >> So looking at the hierarchy is of little use for most of those interface types. >> > CHA starts with the scope type at a use point and tries to prove that there is only one method in the scope. > > Profiling starts with the set of concrete precise types at a use point and tries to prove that there is only one method. > > CHA starts with scope types (often abstract) and searches downward. A downward search from an interface fails (always?): this should be fixed. > > Profiling starts with concrete types and currently fails if there is upward movement required. This should be fixed. > > You guys are right that a more complex profiling mechanism would probably capture what's needed. > > Basically, if the profile overflows, it could summarize with approximate information. > > More subtly, we could also profile the target method(s) instead of the receiver class(es). The guard for that would require a vtable probe. > I don't think you need to profile target method(s), you can compute them from profile types or from an approximate profile type (if you implement profile overflow) or even from the declared receiver type. You don't need to move upward, it can be simpler to gather all possible method implementations and If there is only one, you're done. If there is more than one, you can use the vtable probe or if the callsite is also megamorphic in term of method implementations, emit a vtable call. > -- John R?mi From tom.rodriguez at oracle.com Thu Sep 23 01:58:51 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 23 Sep 2010 08:58:51 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub Message-ID: <20100923085852.EA5B447B9B@hg.openjdk.java.net> Changeset: c40600e85311 Author: never Date: 2010-09-22 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c40600e85311 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub Reviewed-by: kvn, twisti ! src/share/vm/opto/stringopts.cpp From christian.thalinger at oracle.com Thu Sep 23 10:42:09 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 23 Sep 2010 19:42:09 +0200 Subject: Request for reviews (XS): 6986944: JSR 292 assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site Message-ID: <1285263729.15396.2.camel@macbook> http://cr.openjdk.java.net/~twisti/6986944/webrev.01/ 6986944: JSR 292 assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site Reviewed-by: The problem is that C1 calls ciMethod::is_method_handle_invoke in LIRGenerator::do_Invoke. When the target is not loaded yet but is a MH call site, the method returns false and it's not registered as a MH invoke. The fix is to restore the old logic, but only on the non-loaded path. Tested with MethodHandlesTest. This change also includes a build fix for newer GCCs. From tom.rodriguez at oracle.com Thu Sep 23 12:55:01 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 23 Sep 2010 12:55:01 -0700 Subject: Request for reviews (XS): 6986944: JSR 292 assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site In-Reply-To: <1285263729.15396.2.camel@macbook> References: <1285263729.15396.2.camel@macbook> Message-ID: <84C5279B-07B7-4579-B301-B660131A5CDC@oracle.com> Looks good. tom On Sep 23, 2010, at 10:42 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6986944/webrev.01/ > > 6986944: JSR 292 assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site > Reviewed-by: > > The problem is that C1 calls ciMethod::is_method_handle_invoke in > LIRGenerator::do_Invoke. When the target is not loaded yet but is a > MH call site, the method returns false and it's not registered as a MH > invoke. > > The fix is to restore the old logic, but only on the non-loaded path. > > Tested with MethodHandlesTest. > > This change also includes a build fix for newer GCCs. > > > From christian.thalinger at oracle.com Thu Sep 23 13:08:43 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 23 Sep 2010 22:08:43 +0200 Subject: Request for reviews (XS): 6986944: JSR 292 assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site In-Reply-To: <84C5279B-07B7-4579-B301-B660131A5CDC@oracle.com> References: <1285263729.15396.2.camel@macbook> <84C5279B-07B7-4579-B301-B660131A5CDC@oracle.com> Message-ID: <1285272523.15396.149.camel@macbook> On Thu, 2010-09-23 at 12:55 -0700, Tom Rodriguez wrote: > Looks good. Thanks, Tom. -- Christian From igor.veresov at oracle.com Thu Sep 23 22:34:20 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 23 Sep 2010 22:34:20 -0700 Subject: Request for review(XXS): 6987115: Non-tiered compilation policy creates unnecessary C1 threads Message-ID: <4C9C385C.4040805@oracle.com> I made an error while refactoring the old policy and as a result when running a tiered binary with tiered turned off it creates C1 threads that are not really needed. Webrev: http://cr.openjdk.java.net/~iveresov/6987115/webrev.00/ From Christian.Thalinger at Sun.COM Fri Sep 24 13:12:16 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 24 Sep 2010 20:12:16 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6986944: JSR 292 assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site Message-ID: <20100924201218.CA48647BF5@hg.openjdk.java.net> Changeset: c93c652551b5 Author: twisti Date: 2010-09-24 03:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c93c652551b5 6986944: JSR 292 assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site Reviewed-by: never, kvn ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/ci/ciMethod.cpp From roland.westrelin at sun.com Fri Sep 24 15:17:35 2010 From: roland.westrelin at sun.com (roland.westrelin at sun.com) Date: Fri, 24 Sep 2010 22:17:35 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20100924221739.661DC47BFC@hg.openjdk.java.net> Changeset: f02a8bbe6ed4 Author: roland Date: 2009-12-29 19:08 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f02a8bbe6ed4 6986046: C1 valuestack cleanup Summary: fixes an historical oddity in C1 with inlining where all of the expression stacks are kept in the topmost ValueStack instead of being in their respective ValueStacks. Reviewed-by: never Contributed-by: Christian Wimmer ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/includeDB_compiler1 Changeset: 861f533d12b0 Author: roland Date: 2010-09-24 13:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/861f533d12b0 Merge From headius at headius.com Sat Sep 25 00:50:59 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 25 Sep 2010 01:50:59 -0600 Subject: [jvm-l] More on: Small static method marked not entrant, inlining reversed? In-Reply-To: <4C950417.3030501@univ-mlv.fr> References: <4C950417.3030501@univ-mlv.fr> Message-ID: Thanks for a more complete example, R?mi :) Also interesting to find out that C1 handles the case better. So the manual workaround in my code (instanceof + cast) is only necessary on C2 :( - Charlie On Sat, Sep 18, 2010 at 12:25 PM, R?mi Forax wrote: > I take a little time to create a simple test case to reproduce a bug > found by Charles Nutter with c2. > see > http://groups.google.com/group/jvm-languages/browse_thread/thread/6c9e05ecd28fdcd4# > > Here is the test case, > There is 3 classes A, B, C that inherit from AbstractFoo that implements > Foo. > The method test do a virtual call to check() and because > check() is implemented in AbstractFoo we expect that this call should be > de-virtualized then inlined. > > c2 fails, foo.check() is compiled as a virtual call :( > With c1, there is no problem, CHA works correctly. > > R?mi > > ------------------------------------------------------------------------------------------------ > > public class InlineTest { > ?interface Foo { > ? ?public boolean check(int generation); > ?} > > ?static class AbstractFoo implements Foo { > ? ?private final int value; > > ? ?protected AbstractFoo(int value) { > ? ? ?this.value = value; > ? ?} > > ? ?public boolean check(int generation) { > ? ? ?return this.getClass().hashCode() - value == generation; > ? ?} > ?} > > ?static class A extends AbstractFoo { > ? ?public A(int value) { > ? ? ?super(value); > ? ?} > ?} > ?static class B extends AbstractFoo { > ? ?public B(int value) { > ? ? ?super(value); > ? ?} > ?} > ?static class C extends AbstractFoo { > ? ?public C(int value) { > ? ? ?super(value); > ? ?} > ?} > > ?private static final int CONST = A.class.hashCode(); > > ?private static int count; > > ?private static void test(Foo foo) { > ? ?if (foo.check(0)) { > ? ? ? ?count += 2; > ? ? ? ?//System.out.println("foo"); > ? ?} else { > ? ? ? ?count += 1; > ? ? ? ?//System.out.println("bar"); > ? ?} > ?} > > ?public static void main(String[] args) { > ? ?Foo[] array = new Foo[100000]; > ? ?int threshold = 20000; > ? ?for(int i=0; i ? ? ?array[i] = new A(CONST); > ? ?} > > ? ?for(int i=threshold; i ? ? ?array[i] = (i%2 == 0)? new B(0): new C(CONST); > ? ?} > > ? ?for(int i=0; i ? ? ?test(array[i]); > ? ?} > > ? ?System.out.println(count); > ?} > } > > -- > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to jvm-languages at googlegroups.com. > To unsubscribe from this group, send email to > jvm-languages+unsubscribe at googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > > From christian.thalinger at oracle.com Mon Sep 27 04:43:06 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Sep 2010 13:43:06 +0200 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC Message-ID: <1285587786.27094.109.camel@macbook> http://cr.openjdk.java.net/~twisti/6987555/webrev.01/ 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC Reviewed-by: On a big-endian SPARC machine an unboxed true boolean value looks like 0x01000000 but the shift is 31 bits, which results in a wrong value. The fix is to check for a boolean destination type before we do the shift and adjust the shift value. Tested with test.java.dyn.MethodHandlesTest. Additionally this change includes some SPARC-specific changes which were part of 6984311. From christian.thalinger at oracle.com Mon Sep 27 07:06:24 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Sep 2010 16:06:24 +0200 Subject: Request for review(XXS): 6987115: Non-tiered compilation policy creates unnecessary C1 threads In-Reply-To: <4C9C385C.4040805@oracle.com> References: <4C9C385C.4040805@oracle.com> Message-ID: <1285596384.27094.260.camel@macbook> On Thu, 2010-09-23 at 22:34 -0700, Igor Veresov wrote: > I made an error while refactoring the old policy and as a result when > running a tiered binary with tiered turned off it creates C1 threads > that are not really needed. > > > Webrev: http://cr.openjdk.java.net/~iveresov/6987115/webrev.00/ I think a comment would be nice to explain why the order is important. Without that it's hard to understand what's going on. -- Christian From christian.thalinger at oracle.com Mon Sep 27 07:06:24 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Sep 2010 16:06:24 +0200 Subject: Request for review(XXS): 6987115: Non-tiered compilation policy creates unnecessary C1 threads In-Reply-To: <4C9C385C.4040805@oracle.com> References: <4C9C385C.4040805@oracle.com> Message-ID: <1285596384.27094.260.camel@macbook> On Thu, 2010-09-23 at 22:34 -0700, Igor Veresov wrote: > I made an error while refactoring the old policy and as a result when > running a tiered binary with tiered turned off it creates C1 threads > that are not really needed. > > > Webrev: http://cr.openjdk.java.net/~iveresov/6987115/webrev.00/ I think a comment would be nice to explain why the order is important. Without that it's hard to understand what's going on. -- Christian From igor.veresov at oracle.com Mon Sep 27 11:04:40 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 27 Sep 2010 11:04:40 -0700 Subject: Request for review(XXS): 6987115: Non-tiered compilation policy creates unnecessary C1 threads In-Reply-To: <1285596384.27094.260.camel@macbook> References: <4C9C385C.4040805@oracle.com> <1285596384.27094.260.camel@macbook> Message-ID: <4CA0DCB8.5030504@oracle.com> On 9/27/10 7:06 AM, Christian Thalinger wrote: > On Thu, 2010-09-23 at 22:34 -0700, Igor Veresov wrote: >> I made an error while refactoring the old policy and as a result when >> running a tiered binary with tiered turned off it creates C1 threads >> that are not really needed. >> >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6987115/webrev.00/ > > I think a comment would be nice to explain why the order is important. > Without that it's hard to understand what's going on. > OK, done. Webrev updated in-place. igor From christian.thalinger at oracle.com Mon Sep 27 11:15:46 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Sep 2010 20:15:46 +0200 Subject: Request for review(XXS): 6987115: Non-tiered compilation policy creates unnecessary C1 threads In-Reply-To: <4CA0DCB8.5030504@oracle.com> References: <4C9C385C.4040805@oracle.com> <1285596384.27094.260.camel@macbook> <4CA0DCB8.5030504@oracle.com> Message-ID: <1285611346.27094.525.camel@macbook> On Mon, 2010-09-27 at 11:04 -0700, Igor Veresov wrote: > On 9/27/10 7:06 AM, Christian Thalinger wrote: > > On Thu, 2010-09-23 at 22:34 -0700, Igor Veresov wrote: > >> I made an error while refactoring the old policy and as a result when > >> running a tiered binary with tiered turned off it creates C1 threads > >> that are not really needed. > >> > >> > >> Webrev: http://cr.openjdk.java.net/~iveresov/6987115/webrev.00/ > > > > I think a comment would be nice to explain why the order is important. > > Without that it's hard to understand what's going on. > > > OK, done. Webrev updated in-place. Thanks, that helps a lot. -- Christian From igor.veresov at oracle.com Mon Sep 27 11:17:04 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 27 Sep 2010 11:17:04 -0700 Subject: Request for review(XXS): 6987115: Non-tiered compilation policy creates unnecessary C1 threads In-Reply-To: <1285611346.27094.525.camel@macbook> References: <4C9C385C.4040805@oracle.com> <1285596384.27094.260.camel@macbook> <4CA0DCB8.5030504@oracle.com> <1285611346.27094.525.camel@macbook> Message-ID: <4CA0DFA0.1010107@oracle.com> On 9/27/10 11:15 AM, Christian Thalinger wrote: > On Mon, 2010-09-27 at 11:04 -0700, Igor Veresov wrote: >> On 9/27/10 7:06 AM, Christian Thalinger wrote: >>> On Thu, 2010-09-23 at 22:34 -0700, Igor Veresov wrote: >>>> I made an error while refactoring the old policy and as a result when >>>> running a tiered binary with tiered turned off it creates C1 threads >>>> that are not really needed. >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/6987115/webrev.00/ >>> >>> I think a comment would be nice to explain why the order is important. >>> Without that it's hard to understand what's going on. >>> >> OK, done. Webrev updated in-place. > > Thanks, that helps a lot. -- Christian > Thanks, Christian! igor From tom.rodriguez at oracle.com Mon Sep 27 15:15:54 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 27 Sep 2010 15:15:54 -0700 Subject: review (XS) for 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified Message-ID: <1B857839-72C4-4EB0-8EBD-30AB7C89B4BE@oracle.com> http://cr.openjdk.java.net/~never/6987763 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified Reviewed-by: roland The fix for 6987763 aggressively kills unusable locals in ValueStacks and there's some special case logic to keep these locals alive for JVMTI. An assert that should have been relaxed was missed leading to lots of tests failing. The fix is to properly relax this assert. The original changes for 6987763 were tested with the nsk tests but we rearranged some code in what was thought to be a benign way and didn't rerun the tests which is why this was missed. I've rerun all the nsk JVMTI related tests and it looks good. From igor.veresov at oracle.com Mon Sep 27 15:20:35 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 27 Sep 2010 15:20:35 -0700 Subject: review (XS) for 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified In-Reply-To: <1B857839-72C4-4EB0-8EBD-30AB7C89B4BE@oracle.com> References: <1B857839-72C4-4EB0-8EBD-30AB7C89B4BE@oracle.com> Message-ID: <4CA118B3.3090009@oracle.com> Looks good. igor On 9/27/10 3:15 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6987763 > > 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified > Reviewed-by: roland > > The fix for 6987763 aggressively kills unusable locals in ValueStacks > and there's some special case logic to keep these locals alive for > JVMTI. An assert that should have been relaxed was missed leading to > lots of tests failing. The fix is to properly relax this assert. > > The original changes for 6987763 were tested with the nsk tests but we > rearranged some code in what was thought to be a benign way and didn't > rerun the tests which is why this was missed. I've rerun all the nsk > JVMTI related tests and it looks good. From vladimir.kozlov at oracle.com Mon Sep 27 15:18:59 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Sep 2010 15:18:59 -0700 Subject: review (XS) for 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified In-Reply-To: <1B857839-72C4-4EB0-8EBD-30AB7C89B4BE@oracle.com> References: <1B857839-72C4-4EB0-8EBD-30AB7C89B4BE@oracle.com> Message-ID: <4CA11853.7080009@oracle.com> Tom, could you put kind() == ExceptionState inside ()? Otherwise looks good. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6987763 > > 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified > Reviewed-by: roland > > The fix for 6987763 aggressively kills unusable locals in ValueStacks > and there's some special case logic to keep these locals alive for > JVMTI. An assert that should have been relaxed was missed leading to > lots of tests failing. The fix is to properly relax this assert. > > The original changes for 6987763 were tested with the nsk tests but we > rearranged some code in what was thought to be a benign way and didn't > rerun the tests which is why this was missed. I've rerun all the nsk > JVMTI related tests and it looks good. From tom.rodriguez at oracle.com Mon Sep 27 15:27:45 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 27 Sep 2010 15:27:45 -0700 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: <1285587786.27094.109.camel@macbook> References: <1285587786.27094.109.camel@macbook> Message-ID: Why is the shift 31 bits? T_BOOLEAN isn't a bit field, it's 8 bits wide in our implementation. tom On Sep 27, 2010, at 4:43 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6987555/webrev.01/ > > 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC > Reviewed-by: > > On a big-endian SPARC machine an unboxed true boolean value looks like > 0x01000000 but the shift is 31 bits, which results in a wrong value. > > The fix is to check for a boolean destination type before we do the > shift and adjust the shift value. > > Tested with test.java.dyn.MethodHandlesTest. > > Additionally this change includes some SPARC-specific changes which > were part of 6984311. > From tom.rodriguez at oracle.com Mon Sep 27 15:28:41 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 27 Sep 2010 15:28:41 -0700 Subject: review (XS) for 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified In-Reply-To: <4CA11853.7080009@oracle.com> References: <1B857839-72C4-4EB0-8EBD-30AB7C89B4BE@oracle.com> <4CA11853.7080009@oracle.com> Message-ID: <2ADA2DF4-DF7C-40A6-85C3-5FF5016EA778@oracle.com> On Sep 27, 2010, at 3:18 PM, Vladimir Kozlov wrote: > Tom, > > could you put kind() == ExceptionState inside ()? > Otherwise looks good. Sure. Thanks! tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6987763 >> 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified >> Reviewed-by: roland >> The fix for 6987763 aggressively kills unusable locals in ValueStacks >> and there's some special case logic to keep these locals alive for >> JVMTI. An assert that should have been relaxed was missed leading to >> lots of tests failing. The fix is to properly relax this assert. >> The original changes for 6987763 were tested with the nsk tests but we >> rearranged some code in what was thought to be a benign way and didn't >> rerun the tests which is why this was missed. I've rerun all the nsk >> JVMTI related tests and it looks good. From tom.rodriguez at oracle.com Mon Sep 27 15:28:51 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 27 Sep 2010 15:28:51 -0700 Subject: review (XS) for 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified In-Reply-To: <4CA118B3.3090009@oracle.com> References: <1B857839-72C4-4EB0-8EBD-30AB7C89B4BE@oracle.com> <4CA118B3.3090009@oracle.com> Message-ID: <542791D2-8B2D-47B8-9E69-A2E60825E60F@oracle.com> Thanks! tom On Sep 27, 2010, at 3:20 PM, Igor Veresov wrote: > Looks good. > > igor > > On 9/27/10 3:15 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6987763 >> >> 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified >> Reviewed-by: roland >> >> The fix for 6987763 aggressively kills unusable locals in ValueStacks >> and there's some special case logic to keep these locals alive for >> JVMTI. An assert that should have been relaxed was missed leading to >> lots of tests failing. The fix is to properly relax this assert. >> >> The original changes for 6987763 were tested with the nsk tests but we >> rearranged some code in what was thought to be a benign way and didn't >> rerun the tests which is why this was missed. I've rerun all the nsk >> JVMTI related tests and it looks good. > From igor.veresov at oracle.com Mon Sep 27 19:39:30 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 28 Sep 2010 02:39:30 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6987115: Non-tiered compilation policy creates unnecessary C1 threads Message-ID: <20100928023932.178E747CBC@hg.openjdk.java.net> Changeset: df015ec64052 Author: iveresov Date: 2010-09-27 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/df015ec64052 6987115: Non-tiered compilation policy creates unnecessary C1 threads Summary: Fixed NonTieredCompPolicy::compiler_count() to return correct thread count. Reviewed-by: twisti, kvn ! src/share/vm/runtime/compilationPolicy.cpp From tom.rodriguez at oracle.com Tue Sep 28 00:23:03 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 28 Sep 2010 07:23:03 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified Message-ID: <20100928072305.65D1447CCE@hg.openjdk.java.net> Changeset: 1375bc8922e4 Author: never Date: 2010-09-27 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1375bc8922e4 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified Reviewed-by: roland, kvn, iveresov ! src/share/vm/c1/c1_ValueStack.hpp From christian.thalinger at oracle.com Tue Sep 28 01:44:59 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Sep 2010 10:44:59 +0200 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: References: <1285587786.27094.109.camel@macbook> Message-ID: <1285663499.27094.865.camel@macbook> On Mon, 2010-09-27 at 15:27 -0700, Tom Rodriguez wrote: > Why is the shift 31 bits? T_BOOLEAN isn't a bit field, it's 8 bits > wide in our implementation. True, but the adapter can also do type conversion to sub-types. So we have to shift by 31 bits to get the actual boolean value. -- Christian From christian.thalinger at oracle.com Tue Sep 28 06:26:46 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Sep 2010 15:26:46 +0200 Subject: Request for reviews (S): 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument Message-ID: <1285680406.27094.1148.camel@macbook> http://cr.openjdk.java.net/~twisti/6987634/webrev.01/ 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument Reviewed-by: MethodHandle.invoke* are native methods. When the inlining logic in Compile::call_generator tries to inline these methods it fails because these methods don't have any bytecode. The fix is to move the logic that handles method handle invokes, which generates bytecodes for these methods, before the normal inlining logic. From tom.rodriguez at oracle.com Tue Sep 28 08:00:57 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 28 Sep 2010 08:00:57 -0700 Subject: Request for reviews (S): 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument In-Reply-To: <1285680406.27094.1148.camel@macbook> References: <1285680406.27094.1148.camel@macbook> Message-ID: <8E6994F1-D40D-4562-B808-DE15C9C59E8B@oracle.com> Looks good. tom On Sep 28, 2010, at 6:26 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6987634/webrev.01/ > > 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument > Reviewed-by: > > MethodHandle.invoke* are native methods. When the inlining logic in > Compile::call_generator tries to inline these methods it fails because > these methods don't have any bytecode. > > The fix is to move the logic that handles method handle invokes, which > generates bytecodes for these methods, before the normal inlining > logic. > From christian.thalinger at oracle.com Tue Sep 28 08:22:40 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Sep 2010 17:22:40 +0200 Subject: Request for reviews (S): 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument In-Reply-To: <8E6994F1-D40D-4562-B808-DE15C9C59E8B@oracle.com> References: <1285680406.27094.1148.camel@macbook> <8E6994F1-D40D-4562-B808-DE15C9C59E8B@oracle.com> Message-ID: <1285687360.27094.1289.camel@macbook> On Tue, 2010-09-28 at 08:00 -0700, Tom Rodriguez wrote: > Looks good. Thanks, Tom! -- Christian From vladimir.kozlov at oracle.com Tue Sep 28 09:54:14 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Sep 2010 09:54:14 -0700 Subject: Request for reviews (S): 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument In-Reply-To: <1285680406.27094.1148.camel@macbook> References: <1285680406.27094.1148.camel@macbook> Message-ID: <4CA21DB6.4040309@oracle.com> Good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6987634/webrev.01/ > > 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument > Reviewed-by: > > MethodHandle.invoke* are native methods. When the inlining logic in > Compile::call_generator tries to inline these methods it fails because > these methods don't have any bytecode. > > The fix is to move the logic that handles method handle invokes, which > generates bytecodes for these methods, before the normal inlining > logic. > From john.r.rose at oracle.com Tue Sep 28 12:58:55 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 28 Sep 2010 12:58:55 -0700 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: <1285587786.27094.109.camel@macbook> References: <1285587786.27094.109.camel@macbook> Message-ID: On Sep 27, 2010, at 4:43 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6987555/webrev.01/ > > 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC > Reviewed-by: There is an and3/cmp which uses the same value for both mask and test pattern. It happens to work, but I think you should use this value for the mask: (CONV_VMINFO_MASK << CONV_VMINFO_SHIFT) Also, the value BitsPerByte-1 looks pretty magic. For the sake of future readers, I suggest something more explicit: int old_shift = (boolean_shift & (BitsPerInt-1)); int new_shift = (BitsPerInt - BitsPerByte); // 0x01000000 => 0x00000001 __ delayed()->xor3(vminfo, old_shift ^ new_shift, vminfo); -- John From christian.thalinger at oracle.com Tue Sep 28 13:08:00 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Sep 2010 22:08:00 +0200 Subject: Request for reviews (S): 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument In-Reply-To: <4CA21DB6.4040309@oracle.com> References: <1285680406.27094.1148.camel@macbook> <4CA21DB6.4040309@oracle.com> Message-ID: <1285704480.27094.1607.camel@macbook> On Tue, 2010-09-28 at 09:54 -0700, Vladimir Kozlov wrote: > Good. Thanks, Vladimir! -- Christian From tom.rodriguez at oracle.com Tue Sep 28 14:04:35 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 28 Sep 2010 14:04:35 -0700 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: References: <1285587786.27094.109.camel@macbook> Message-ID: On Sep 28, 2010, at 12:58 PM, John Rose wrote: > On Sep 27, 2010, at 4:43 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/6987555/webrev.01/ >> >> 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC >> Reviewed-by: > > There is an and3/cmp which uses the same value for both mask and test pattern. > > It happens to work, but I think you should use this value for the mask: > (CONV_VMINFO_MASK << CONV_VMINFO_SHIFT) > > Also, the value BitsPerByte-1 looks pretty magic. For the sake of future readers, I suggest something more explicit: > int old_shift = (boolean_shift & (BitsPerInt-1)); > int new_shift = (BitsPerInt - BitsPerByte); // 0x01000000 => 0x00000001 > __ delayed()->xor3(vminfo, old_shift ^ new_shift, vminfo); That doesn't seem clearer to me. If the shift should be 24 then why isn't that the value in vminfo in the first place? That whole section of code is mysterious in terms of what cases it's actually supposed to handle and how. I've exchanged a bit of email with Christian about it and I think he's working on some tests to exercise these conversions more. What are the possible input and output types? Is it only the direct mappings between the boxed and unboxed forms, like Integer -> int, or can it do arbitrary conversions like Short -> byte? tom > > -- John From john.r.rose at oracle.com Tue Sep 28 16:25:32 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 28 Sep 2010 16:25:32 -0700 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: References: <1285587786.27094.109.camel@macbook> Message-ID: On Sep 28, 2010, at 2:04 PM, Tom Rodriguez wrote: > That doesn't seem clearer to me. If the shift should be 24 then why isn't that the value in vminfo in the first place? The adapter data are validated and adjusted by init_AdapterMethodHandle in methodHandles.cpp. I suppose the value could be set to 24 at that point, but it would have to be done by platform-specific code factored somehow into methodHandles_sparc.cpp. That value happens to be the number of insignificant bits (or padding bits) in the value, when it is viewed as embedded in a 32-bit Java int (and/or JVM stack slot). This is a platform-independent value. It might be clearer if it were the number of significant bits: 1 for boolean, 8 for byte, 16 for char and short. As it is, it is 31, 24, and 16 (respectively), which is more convenient for both Intel and SPARC. The agreement about this value is between methodHandles.cpp and methodHandles_.cpp. > That whole section of code is mysterious in terms of what cases it's actually supposed to handle and how. I've exchanged a bit of email with Christian about it and I think he's working on some tests to exercise these conversions more. What are the possible input and output types? Is it only the direct mappings between the boxed and unboxed forms, like Integer -> int, or can it do arbitrary conversions like Short -> byte? That code handles two kinds of conversions: from subword (16 bits or less) to int, and from box to primitive (32 bits or less). There is no short->byte, since an incoming short on the stack is always represented as an int slot. -- John From vladimir.kozlov at oracle.com Tue Sep 28 19:08:28 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Sep 2010 19:08:28 -0700 Subject: Request for reviews (S): 6916062: assert(_inserts <= _insert_limit, "hash table overflow") in NodeHash::hash_insert Message-ID: <4CA29F9C.8040407@oracle.com> http://cr.openjdk.java.net/~kvn/6916062/webrev.02 Fixed 6916062: assert(_inserts <= _insert_limit,"hash table overflow") in NodeHash::hash_insert Changes for 6711117 put a memory node back on IGVN worklist if address type does not match cached type in a hope that address nodes will be processed and the type will be updated. But it does not check that there are nodes on worklist which will trigger address processing. As result the memory node is pulled from and pushed on IGVN worklist infinitely. On each iteration NodeHash::_inserts value is incremented forcing hash table grow until integer value NodeHash::_max is overflow (became 0) which triggers bug's assert. I decided to go with simplest fix which is easy to backport and leave fixing address type inconsistency for later (I have bug 6715629). I also added asserts to catch such situations. Tested with failing case, CTW, JPRT. From tom.rodriguez at oracle.com Tue Sep 28 20:16:21 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 28 Sep 2010 20:16:21 -0700 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: References: <1285587786.27094.109.camel@macbook> Message-ID: <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> On Sep 28, 2010, at 4:25 PM, John Rose wrote: > On Sep 28, 2010, at 2:04 PM, Tom Rodriguez wrote: > >> That doesn't seem clearer to me. If the shift should be 24 then why isn't that the value in vminfo in the first place? > > The adapter data are validated and adjusted by init_AdapterMethodHandle in methodHandles.cpp. I suppose the value could be set to 24 at that point, but it would have to be done by platform-specific code factored somehow into methodHandles_sparc.cpp. > > That value happens to be the number of insignificant bits (or padding bits) in the value, when it is viewed as embedded in a 32-bit Java int (and/or JVM stack slot). This is a platform-independent value. Does the value have a purpose beyond driving this piece of logic? Maybe it's need to be platform dependent. That seems like a cleaner fix to me. > > It might be clearer if it were the number of significant bits: 1 for boolean, 8 for byte, 16 for char and short. As it is, it is 31, 24, and 16 (respectively), which is more convenient for both Intel and SPARC. The agreement about this value is between methodHandles.cpp and methodHandles_.cpp. > >> That whole section of code is mysterious in terms of what cases it's actually supposed to handle and how. I've exchanged a bit of email with Christian about it and I think he's working on some tests to exercise these conversions more. What are the possible input and output types? Is it only the direct mappings between the boxed and unboxed forms, like Integer -> int, or can it do arbitrary conversions like Short -> byte? > > > That code handles two kinds of conversions: from subword (16 bits or less) to int, and from box to primitive (32 bits or less). > > There is no short->byte, since an incoming short on the stack is always represented as an int slot. I meant unboxing a Short and turning it into a byte. Is something like that allowed or is it done in two stages using unboxi then i2i? tom > > -- John From john.r.rose at Oracle.Com Tue Sep 28 20:33:53 2010 From: john.r.rose at Oracle.Com (John Rose) Date: Tue, 28 Sep 2010 20:33:53 -0700 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> References: <1285587786.27094.109.camel@macbook> <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> Message-ID: On Sep 28, 2010, at 8:16 PM, Tom Rodriguez wrote: > Does the value have a purpose beyond driving this piece of logic? Maybe it's need to be platform dependent. That seems like a cleaner fix to me. Yes, that would be cleaner. Here's a curveball, though: I want to move that adapter-initializing logic into Java code. In there, it will be harder to manage platform-specific code. >> There is no short->byte, since an incoming short on the stack is always represented as an int slot. > > I meant unboxing a Short and turning it into a byte. Is something like that allowed or is it done in two stages using unboxi then i2i? Two stages. -- John From christian.thalinger at oracle.com Wed Sep 29 01:18:14 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 29 Sep 2010 10:18:14 +0200 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: References: <1285587786.27094.109.camel@macbook> <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> Message-ID: <1285748294.27094.1762.camel@macbook> On Tue, 2010-09-28 at 20:33 -0700, John Rose wrote: > > I meant unboxing a Short and turning it into a byte. Is something > like that allowed or is it done in two stages using unboxi then i2i? > > Two stages. Good to know. Actually I thought it's possible to do unboxing and type conversion in one step. That means that the proposed change works. But changing the shift for boolean to 24 should also work, since booleans use 1 byte. I'll try that. -- Christian From christian.thalinger at oracle.com Wed Sep 29 02:59:38 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 29 Sep 2010 11:59:38 +0200 Subject: Request for reviews (L): 6986046 C1 ValueStack cleanup In-Reply-To: <0C0D64FC-6B29-473C-911B-533F2D5B6A6E@oracle.com> References: <0C0D64FC-6B29-473C-911B-533F2D5B6A6E@oracle.com> Message-ID: <1285754378.27094.1868.camel@macbook> On Wed, 2010-09-22 at 13:41 -0700, Tom Rodriguez wrote: > Looks good. > > tom > > On Sep 21, 2010, at 2:03 AM, Roland Westrelin wrote: > > > > > Cleanup contributed by Christian Wimmer to the C1 ValueStack. > > > > http://cr.openjdk.java.net/~roland/6986046/webrev.00/ That change: src/share/vm/c1/c1_Instruction.hpp: - Instruction(ValueType* type, bool type_is_constant = false, bool create_hi = true) - : _bci(-99) - , _use_count(0) + Instruction(ValueType* type, ValueStack* state_before = NULL, bool type_is_constant = false, bool create_hi = true) + : _use_count(0) breaks: 1965 LEAF(OsrEntry, Instruction) 1966 public: 1967 // creation 1968 #ifdef _LP64 1969 OsrEntry() : Instruction(longType, false) { pin(); } 1970 #else 1971 OsrEntry() : Instruction(intType, false) { pin(); } 1972 #endif and: 1983 ExceptionObject() : Instruction(objectType, false) { Unfortunately only a very new GCC (gcc version 4.5.1 (Ubuntu 4.4.1-4ubuntu9)) complains about the error: src/share/vm/c1/c1_Instruction.hpp: In constructor ?OsrEntry::OsrEntry()?: src/share/vm/c1/c1_Instruction.hpp:1971:43: error: converting ?false? to pointer type for argument 2 of ?Instruction::Instruction(ValueType*, ValueStack*, bool, bool)? I'm not sure what the right fix is. Maybe only pass the type and leave the rest to the default values. -- Christian From roland.westrelin at oracle.com Wed Sep 29 03:09:02 2010 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 29 Sep 2010 12:09:02 +0200 Subject: Request for reviews (L): 6986046 C1 ValueStack cleanup In-Reply-To: <1285754378.27094.1868.camel@macbook> References: <0C0D64FC-6B29-473C-911B-533F2D5B6A6E@oracle.com> <1285754378.27094.1868.camel@macbook> Message-ID: Hi Christian, > I'm not sure what the right fix is. Maybe only pass the type and leave > the rest to the default values. I think it's the correct fix. Interesting that no other compiler complained about it. The create_hi argument in the Instruction constructor should be removed as well. It's useless now. I'll prepare the change. Roland. From Christian.Thalinger at Sun.COM Wed Sep 29 03:48:29 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 29 Sep 2010 10:48:29 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument Message-ID: <20100929104836.5F5C147D1B@hg.openjdk.java.net> Changeset: 8aa5fd5d2046 Author: twisti Date: 2010-09-29 00:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8aa5fd5d2046 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument Reviewed-by: never, kvn ! src/share/vm/opto/doCall.cpp From christian.thalinger at oracle.com Wed Sep 29 06:58:19 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 29 Sep 2010 15:58:19 +0200 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: <1285748294.27094.1762.camel@macbook> References: <1285587786.27094.109.camel@macbook> <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> <1285748294.27094.1762.camel@macbook> Message-ID: <1285768699.27094.2120.camel@macbook> On Wed, 2010-09-29 at 10:18 +0200, Christian Thalinger wrote: > On Tue, 2010-09-28 at 20:33 -0700, John Rose wrote: > > > I meant unboxing a Short and turning it into a byte. Is something > > like that allowed or is it done in two stages using unboxi then i2i? > > > > Two stages. > > Good to know. Actually I thought it's possible to do unboxing and type > conversion in one step. That means that the proposed change works. > > But changing the shift for boolean to 24 should also work, since > booleans use 1 byte. I'll try that. What about this one: diff -r 861f533d12b0 src/share/vm/prims/methodHandles.hpp --- a/src/share/vm/prims/methodHandles.hpp +++ b/src/share/vm/prims/methodHandles.hpp @@ -226,11 +226,12 @@ class MethodHandles: AllStatic { } enum { CONV_VMINFO_SIGN_FLAG = 0x80 }; + // Returns the number of insignificant bits (or padding bits). static int adapter_subword_vminfo(BasicType dest) { - if (dest == T_BOOLEAN) return (BitsPerInt - 1); - if (dest == T_CHAR) return (BitsPerInt - 16); - if (dest == T_BYTE) return (BitsPerInt - 8) | CONV_VMINFO_SIGN_FLAG; - if (dest == T_SHORT) return (BitsPerInt - 16) | CONV_VMINFO_SIGN_FLAG; + if (dest == T_BOOLEAN) return (BitsPerInt - BitsPerByte ); // boolean is implemented as 1 byte + if (dest == T_CHAR) return (BitsPerInt - BitsPerShort); + if (dest == T_BYTE) return (BitsPerInt - BitsPerByte ) | CONV_VMINFO_SIGN_FLAG; + if (dest == T_SHORT) return (BitsPerInt - BitsPerShort) | CONV_VMINFO_SIGN_FLAG; return 0; // case T_INT } // Here is the transformation the i2i adapter must perform: From igor.veresov at oracle.com Wed Sep 29 07:56:02 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 29 Sep 2010 07:56:02 -0700 Subject: Request for reviews (L): 6986046 C1 ValueStack cleanup In-Reply-To: References: <0C0D64FC-6B29-473C-911B-533F2D5B6A6E@oracle.com> <1285754378.27094.1868.camel@macbook> Message-ID: <4CA35382.6060909@oracle.com> This fix also didn't make the appropriate changes for the profiling code in C1 in a couple of places. Also I had to lower optimization level for c1_LinearScan.cpp on SunStudio when compiling for 64bit x86. I've seen it before - it seems to end up prematurely calling desctructors (of ResourceMark in this case). Anyway, I'll put out the change today that has the fixes and gets tiered working again. igor On 9/29/10 3:09 AM, Roland Westrelin wrote: > Hi Christian, > >> I'm not sure what the right fix is. Maybe only pass the type and leave >> the rest to the default values. > > I think it's the correct fix. Interesting that no other compiler > complained about it. The create_hi argument in the Instruction > constructor should be removed as well. It's useless now. > > I'll prepare the change. > > Roland. From john.r.rose at oracle.com Wed Sep 29 09:05:43 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 29 Sep 2010 09:05:43 -0700 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: <1285768699.27094.2120.camel@macbook> References: <1285587786.27094.109.camel@macbook> <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> <1285748294.27094.1762.camel@macbook> <1285768699.27094.2120.camel@macbook> Message-ID: <20727F33-914D-4937-87DB-7FE4C09295D9@oracle.com> On Sep 29, 2010, at 6:58 AM, Christian Thalinger wrote: >> But changing the shift for boolean to 24 should also work, since >> booleans use 1 byte. I'll try that. > > What about this one: That works for unboxi but pushes the bug to value conversion. The Java runtime assumes that a conversion to boolean performs (x&1). If you change that to (x&0xFF) you could begin to see illegal boolean values like 2. You can assume that a boxed boolean is already normalized to 0 or 1, so 24 is fine, but a value in a register can be anything. So for the i2i conversion that creates a boolean, we need to make sure that the assembly code refuses to produce anything other than 0 or 1. That's why the shift value is 31 currently. -- John From roland.westrelin at oracle.com Wed Sep 29 09:12:31 2010 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 29 Sep 2010 18:12:31 +0200 Subject: request review (XXS): 6988303: 6986046 breaks build with recent gcc Message-ID: This fixes the issue that Christian reported earlier today. http://cr.openjdk.java.net/~roland/6988303/webrev.00/ Roland. From tom.rodriguez at oracle.com Wed Sep 29 09:22:01 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 29 Sep 2010 09:22:01 -0700 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: <20727F33-914D-4937-87DB-7FE4C09295D9@oracle.com> References: <1285587786.27094.109.camel@macbook> <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> <1285748294.27094.1762.camel@macbook> <1285768699.27094.2120.camel@macbook> <20727F33-914D-4937-87DB-7FE4C09295D9@oracle.com> Message-ID: <342256CA-214E-4D57-8800-4847EC11908D@oracle.com> On Sep 29, 2010, at 9:05 AM, John Rose wrote: > On Sep 29, 2010, at 6:58 AM, Christian Thalinger wrote: > >>> But changing the shift for boolean to 24 should also work, since >>> booleans use 1 byte. I'll try that. >> >> What about this one: > > That works for unboxi but pushes the bug to value conversion. > > The Java runtime assumes that a conversion to boolean performs (x&1). If you change that to (x&0xFF) you could begin to see illegal boolean values like 2. > > You can assume that a boxed boolean is already normalized to 0 or 1, so 24 is fine, but a value in a register can be anything. > > So for the i2i conversion that creates a boolean, we need to make sure that the assembly code refuses to produce anything other than 0 or 1. That's why the shift value is 31 currently. Why aren't the values dependent on which operation is being performed then? tom > > -- John From tom.rodriguez at oracle.com Wed Sep 29 09:23:55 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 29 Sep 2010 09:23:55 -0700 (PDT) Subject: request review (XXS): 6988303: 6986046 breaks build with recent gcc In-Reply-To: References: Message-ID: Looks good. tom On Sep 29, 2010, at 9:12 AM, Roland Westrelin wrote: > This fixes the issue that Christian reported earlier today. > > http://cr.openjdk.java.net/~roland/6988303/webrev.00/ > > Roland. From vladimir.kozlov at oracle.com Wed Sep 29 09:35:18 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Sep 2010 09:35:18 -0700 Subject: request review (XXS): 6988303: 6986046 breaks build with recent gcc In-Reply-To: References: Message-ID: <4CA36AC6.30400@oracle.com> Looks good. Vladimir On 9/29/10 9:12 AM, Roland Westrelin wrote: > This fixes the issue that Christian reported earlier today. > > http://cr.openjdk.java.net/~roland/6988303/webrev.00/ > > Roland. From john.r.rose at oracle.com Wed Sep 29 09:40:18 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 29 Sep 2010 09:40:18 -0700 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: <342256CA-214E-4D57-8800-4847EC11908D@oracle.com> References: <1285587786.27094.109.camel@macbook> <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> <1285748294.27094.1762.camel@macbook> <1285768699.27094.2120.camel@macbook> <20727F33-914D-4937-87DB-7FE4C09295D9@oracle.com> <342256CA-214E-4D57-8800-4847EC11908D@oracle.com> Message-ID: <8B2D7285-416B-4590-A7B3-C5EF8AADC66F@oracle.com> On Sep 29, 2010, at 9:22 AM, Tom Rodriguez wrote: > Why aren't the values dependent on which operation is being performed then? They certainly can be. That will move the complication out of the assembly code. (And into methodHandles.cpp, with a new CPU-specific query, plus a new but useful distinction between value conversion and unboxing.) I'm fine with doing it either way. -- John From igor.veresov at oracle.com Wed Sep 29 10:40:31 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 29 Sep 2010 10:40:31 -0700 Subject: Request for review(S): 6988346: 6986046 breaks tiered Message-ID: <4CA37A0F.9020407@oracle.com> 6986046 introduced two problems that are covered by this CR: - the profiling code generation needs to be adjusted to use the new ValueStack implementation. - SunStudio S12u1 has problems with c1_LinearScan.cpp on 64bit x86, which results in incorrect code. The optimization level needs to temporarily lowered for this case. Webrev: http://cr.openjdk.java.net/~iveresov/6988346/webrev.00/ Thanks, igor From vladimir.kozlov at oracle.com Wed Sep 29 11:09:33 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Sep 2010 11:09:33 -0700 Subject: Request for review(S): 6988346: 6986046 breaks tiered In-Reply-To: <4CA37A0F.9020407@oracle.com> References: <4CA37A0F.9020407@oracle.com> Message-ID: <4CA380DD.70403@oracle.com> Looks good Vladimir On 9/29/10 10:40 AM, Igor Veresov wrote: > 6986046 introduced two problems that are covered by this CR: > - the profiling code generation needs to be adjusted to use the new ValueStack implementation. > - SunStudio S12u1 has problems with c1_LinearScan.cpp on 64bit x86, which results in incorrect code. The optimization > level needs to temporarily lowered for this case. > > Webrev: http://cr.openjdk.java.net/~iveresov/6988346/webrev.00/ > > > Thanks, > igor From tom.rodriguez at oracle.com Wed Sep 29 11:55:27 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 29 Sep 2010 11:55:27 -0700 Subject: Request for review(S): 6988346: 6986046 breaks tiered In-Reply-To: <4CA37A0F.9020407@oracle.com> References: <4CA37A0F.9020407@oracle.com> Message-ID: <4C216C94-BDCA-4BD6-ABF2-30A6F670B961@oracle.com> Looks good. tom On Sep 29, 2010, at 10:40 AM, Igor Veresov wrote: > 6986046 introduced two problems that are covered by this CR: > - the profiling code generation needs to be adjusted to use the new ValueStack implementation. > - SunStudio S12u1 has problems with c1_LinearScan.cpp on 64bit x86, which results in incorrect code. The optimization level needs to temporarily lowered for this case. > > Webrev: http://cr.openjdk.java.net/~iveresov/6988346/webrev.00/ > > > Thanks, > igor From tom.rodriguez at oracle.com Wed Sep 29 12:00:26 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 29 Sep 2010 12:00:26 -0700 Subject: Request for reviews (S): 6916062: assert(_inserts <= _insert_limit, "hash table overflow") in NodeHash::hash_insert In-Reply-To: <4CA29F9C.8040407@oracle.com> References: <4CA29F9C.8040407@oracle.com> Message-ID: <94915A77-392B-421B-BC30-2D7A5D6995EE@oracle.com> That seems fine for a backport. Maybe we should consider some product level code to bailout if we do too many rounds of IGVN? tom On Sep 28, 2010, at 7:08 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6916062/webrev.02 > > Fixed 6916062: assert(_inserts <= _insert_limit,"hash table overflow") in NodeHash::hash_insert > > Changes for 6711117 put a memory node back on IGVN > worklist if address type does not match cached type > in a hope that address nodes will be processed and > the type will be updated. But it does not check that > there are nodes on worklist which will trigger address > processing. As result the memory node is pulled from > and pushed on IGVN worklist infinitely. > On each iteration NodeHash::_inserts value is incremented > forcing hash table grow until integer value NodeHash::_max > is overflow (became 0) which triggers bug's assert. > > I decided to go with simplest fix which is easy to backport > and leave fixing address type inconsistency for later > (I have bug 6715629). > I also added asserts to catch such situations. > > Tested with failing case, CTW, JPRT. From vladimir.kozlov at oracle.com Wed Sep 29 12:14:08 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Sep 2010 12:14:08 -0700 Subject: Request for reviews (S): 6916062: assert(_inserts <= _insert_limit, "hash table overflow") in NodeHash::hash_insert In-Reply-To: <94915A77-392B-421B-BC30-2D7A5D6995EE@oracle.com> References: <4CA29F9C.8040407@oracle.com> <94915A77-392B-421B-BC30-2D7A5D6995EE@oracle.com> Message-ID: <4CA39000.1080601@oracle.com> Thank you, Tom On 9/29/10 12:00 PM, Tom Rodriguez wrote: > That seems fine for a backport. Maybe we should consider some product level code to bailout if we do too many rounds of IGVN? Yes, it is good idea to bailout. I will add it. Thanks, Vladimir > > tom > > On Sep 28, 2010, at 7:08 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6916062/webrev.02 >> >> Fixed 6916062: assert(_inserts<= _insert_limit,"hash table overflow") in NodeHash::hash_insert >> >> Changes for 6711117 put a memory node back on IGVN >> worklist if address type does not match cached type >> in a hope that address nodes will be processed and >> the type will be updated. But it does not check that >> there are nodes on worklist which will trigger address >> processing. As result the memory node is pulled from >> and pushed on IGVN worklist infinitely. >> On each iteration NodeHash::_inserts value is incremented >> forcing hash table grow until integer value NodeHash::_max >> is overflow (became 0) which triggers bug's assert. >> >> I decided to go with simplest fix which is easy to backport >> and leave fixing address type inconsistency for later >> (I have bug 6715629). >> I also added asserts to catch such situations. >> >> Tested with failing case, CTW, JPRT. > From igor.veresov at oracle.com Wed Sep 29 16:41:45 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 29 Sep 2010 16:41:45 -0700 Subject: Request for review(S): 6988346: 6986046 breaks tiered In-Reply-To: <4C216C94-BDCA-4BD6-ABF2-30A6F670B961@oracle.com> References: <4CA37A0F.9020407@oracle.com> <4C216C94-BDCA-4BD6-ABF2-30A6F670B961@oracle.com> Message-ID: <4CA3CEB9.8070909@oracle.com> Thanks Tom and Vladimir! On 9/29/10 11:55 AM, Tom Rodriguez wrote: > Looks good. > > tom > > On Sep 29, 2010, at 10:40 AM, Igor Veresov wrote: > >> 6986046 introduced two problems that are covered by this CR: >> - the profiling code generation needs to be adjusted to use the new ValueStack implementation. >> - SunStudio S12u1 has problems with c1_LinearScan.cpp on 64bit x86, which results in incorrect code. The optimization level needs to temporarily lowered for this case. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6988346/webrev.00/ >> >> >> Thanks, >> igor > From tom.rodriguez at oracle.com Wed Sep 29 18:21:51 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 29 Sep 2010 18:21:51 -0700 Subject: review (XS) for 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler Message-ID: <9E58B0A1-6C29-4F9B-9505-1248469022EA@oracle.com> http://cr.openjdk.java.net/~never/6988018 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler Reviewed-by: While rearranging code in 6939930 I started passing the wrong number of arguments to the dtrace_method_exit probes resulting in a crash. The fix is to pass the thread in addition to the method. Tested with failing test case. From tom.rodriguez at oracle.com Wed Sep 29 18:25:44 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 29 Sep 2010 18:25:44 -0700 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT Message-ID: http://cr.openjdk.java.net/~never/6968348 6968348: Byteswapped memory access can point to wrong location after JIT Reviewed-by: x86_64.ad has match rules for (Store (ReverseBytes val)) but the definition is buggy since the val can be used in address of the store. It also doesn't record that it changes the input value. The fix is to simply remove these rules since they are no better than what we'd get otherwise. x86_32.ad doesn't have these rules. sparc.ad does but it can generate better code for these forms because it can use the byte swapped ASI and doesn't have to modify the register before storing it. Tested with new test case. From keith.mcguigan at oracle.com Wed Sep 29 18:34:16 2010 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Wed, 29 Sep 2010 21:34:16 -0400 Subject: review (XS) for 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler In-Reply-To: <9E58B0A1-6C29-4F9B-9505-1248469022EA@oracle.com> References: <9E58B0A1-6C29-4F9B-9505-1248469022EA@oracle.com> Message-ID: <4CA3E918.5020207@oracle.com> Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6988018 > > 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler > Reviewed-by: > > While rearranging code in 6939930 I started passing the wrong number > of arguments to the dtrace_method_exit probes resulting in a crash. The > fix is to pass the thread in addition to the method. Tested with > failing test case. Looks good. -- - Keith From igor.veresov at oracle.com Wed Sep 29 18:35:04 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 29 Sep 2010 18:35:04 -0700 Subject: review (XS) for 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler In-Reply-To: <9E58B0A1-6C29-4F9B-9505-1248469022EA@oracle.com> References: <9E58B0A1-6C29-4F9B-9505-1248469022EA@oracle.com> Message-ID: <4CA3E948.7050903@oracle.com> Looks good. igor On 9/29/10 6:21 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6988018 > > 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler > Reviewed-by: > > While rearranging code in 6939930 I started passing the wrong number > of arguments to the dtrace_method_exit probes resulting in a crash. The > fix is to pass the thread in addition to the method. Tested with > failing test case. From igor.veresov at oracle.com Wed Sep 29 19:09:50 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 29 Sep 2010 19:09:50 -0700 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT In-Reply-To: References: Message-ID: <4CA3F16E.5050806@oracle.com> Looks good. igor On 9/29/10 6:25 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6968348 > > 6968348: Byteswapped memory access can point to wrong location after JIT > Reviewed-by: > > x86_64.ad has match rules for (Store (ReverseBytes val)) but the > definition is buggy since the val can be used in address of the store. > It also doesn't record that it changes the input value. The fix is to > simply remove these rules since they are no better than what we'd get > otherwise. x86_32.ad doesn't have these rules. sparc.ad does but it > can generate better code for these forms because it can use the byte > swapped ASI and doesn't have to modify the register before storing it. > Tested with new test case. From vladimir.kozlov at oracle.com Wed Sep 29 19:24:43 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Sep 2010 19:24:43 -0700 Subject: review (XS) for 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler In-Reply-To: <9E58B0A1-6C29-4F9B-9505-1248469022EA@oracle.com> References: <9E58B0A1-6C29-4F9B-9505-1248469022EA@oracle.com> Message-ID: <4CA3F4EB.2010104@oracle.com> Looks good. Vladimir On 9/29/10 6:21 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6988018 > > 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler > Reviewed-by: > > While rearranging code in 6939930 I started passing the wrong number > of arguments to the dtrace_method_exit probes resulting in a crash. The > fix is to pass the thread in addition to the method. Tested with > failing test case. From vladimir.kozlov at oracle.com Wed Sep 29 19:28:12 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Sep 2010 19:28:12 -0700 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT In-Reply-To: References: Message-ID: <4CA3F5BC.1040704@oracle.com> OK. Vladimir On 9/29/10 6:25 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6968348 > > 6968348: Byteswapped memory access can point to wrong location after JIT > Reviewed-by: > > x86_64.ad has match rules for (Store (ReverseBytes val)) but the > definition is buggy since the val can be used in address of the store. > It also doesn't record that it changes the input value. The fix is to > simply remove these rules since they are no better than what we'd get > otherwise. x86_32.ad doesn't have these rules. sparc.ad does but it > can generate better code for these forms because it can use the byte > swapped ASI and doesn't have to modify the register before storing it. > Tested with new test case. From roland.westrelin at sun.com Wed Sep 29 12:55:48 2010 From: roland.westrelin at sun.com (roland.westrelin at sun.com) Date: Wed, 29 Sep 2010 19:55:48 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6988303: 6986046 breaks build with recent gcc Message-ID: <20100929195550.ECEB347D2F@hg.openjdk.java.net> Changeset: ad0638ff8ea4 Author: roland Date: 2010-09-29 18:53 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ad0638ff8ea4 6988303: 6986046 breaks build with recent gcc Summary: fixes build break Reviewed-by: never, kvn ! src/share/vm/c1/c1_Instruction.hpp From y.s.ramakrishna at oracle.com Wed Sep 29 22:49:16 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Wed, 29 Sep 2010 22:49:16 -0700 Subject: Request for review(S): 6988346: 6986046 breaks tiered In-Reply-To: <4CA37A0F.9020407@oracle.com> References: <4CA37A0F.9020407@oracle.com> Message-ID: <4CA424DC.6090207@oracle.com> On 9/29/2010 10:40 AM, Igor Veresov wrote: ... > - SunStudio S12u1 has problems with c1_LinearScan.cpp on 64bit x86, which results in incorrect code. > The optimization level needs to temporarily lowered for this case. Has the bug been reported back to the SS folk? They cannot fix bugs that they might not know about :-) thanks. -- ramki From igor.veresov at oracle.com Wed Sep 29 23:03:02 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 29 Sep 2010 23:03:02 -0700 Subject: Request for review(S): 6988346: 6986046 breaks tiered In-Reply-To: <4CA424DC.6090207@oracle.com> References: <4CA37A0F.9020407@oracle.com> <4CA424DC.6090207@oracle.com> Message-ID: <4CA42816.8020807@oracle.com> Ramki, If I were able to reduce it to a reasonable test case I would've reported it. I didn't think it was practical to file it this way. igor On 9/29/10 10:49 PM, Y. Srinivas Ramakrishna wrote: > On 9/29/2010 10:40 AM, Igor Veresov wrote: > ... >> - SunStudio S12u1 has problems with c1_LinearScan.cpp on 64bit x86, >> which results in incorrect code. >> The optimization level needs to temporarily lowered for this case. > > Has the bug been reported back to the SS folk? They cannot fix bugs that > they > might not know about :-) > > thanks. > -- ramki From Ulf.Zibis at gmx.de Thu Sep 30 03:46:40 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 30 Sep 2010 12:46:40 +0200 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT In-Reply-To: References: Message-ID: <4CA46A90.2010401@gmx.de> Hi, I have run Test6968348.java on b104. It doesn't fail. Why? -Ulf Am 30.09.2010 03:25, schrieb Tom Rodriguez: > http://cr.openjdk.java.net/~never/6968348 > > 6968348: Byteswapped memory access can point to wrong location after JIT > Reviewed-by: > > x86_64.ad has match rules for (Store (ReverseBytes val)) but the > definition is buggy since the val can be used in address of the store. > It also doesn't record that it changes the input value. The fix is to > simply remove these rules since they are no better than what we'd get > otherwise. x86_32.ad doesn't have these rules. sparc.ad does but it > can generate better code for these forms because it can use the byte > swapped ASI and doesn't have to modify the register before storing it. > Tested with new test case. > From igor.veresov at oracle.com Thu Sep 30 04:14:53 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 30 Sep 2010 11:14:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6988346: 6986046 breaks tiered Message-ID: <20100930111501.1443A47D5E@hg.openjdk.java.net> Changeset: 80c9354976b0 Author: iveresov Date: 2010-09-29 16:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/80c9354976b0 6988346: 6986046 breaks tiered Summary: adjusted profiling code generation to use the new ValueStack implementation; lowered optimization level for c1_LinearScan.cpp on solaris x64. Reviewed-by: kvn, never ! make/solaris/makefiles/amd64.make ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp From christian.thalinger at oracle.com Thu Sep 30 05:04:20 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 30 Sep 2010 14:04:20 +0200 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT In-Reply-To: References: Message-ID: <1285848260.1834.5.camel@macbook> On Wed, 2010-09-29 at 18:25 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6968348 > > 6968348: Byteswapped memory access can point to wrong location after JIT > Reviewed-by: > > x86_64.ad has match rules for (Store (ReverseBytes val)) but the > definition is buggy since the val can be used in address of the store. > It also doesn't record that it changes the input value. The fix is to > simply remove these rules since they are no better than what we'd get > otherwise. x86_32.ad doesn't have these rules. sparc.ad does but it > can generate better code for these forms because it can use the byte > swapped ASI and doesn't have to modify the register before storing it. > Tested with new test case. Good. -- Christian From Ulf.Zibis at gmx.de Thu Sep 30 07:08:42 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 30 Sep 2010 16:08:42 +0200 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT In-Reply-To: References: Message-ID: <4CA499EA.7030103@gmx.de> - Why do you increment by 8 in the Test? - ARRAY_LONG_BASE_OFFSET in capital letters is misleading to the reader, as this variable is not a final constant. -Ulf Am 30.09.2010 03:25, schrieb Tom Rodriguez: > http://cr.openjdk.java.net/~never/6968348 > > 6968348: Byteswapped memory access can point to wrong location after JIT > Reviewed-by: > > x86_64.ad has match rules for (Store (ReverseBytes val)) but the > definition is buggy since the val can be used in address of the store. > It also doesn't record that it changes the input value. The fix is to > simply remove these rules since they are no better than what we'd get > otherwise. x86_32.ad doesn't have these rules. sparc.ad does but it > can generate better code for these forms because it can use the byte > swapped ASI and doesn't have to modify the register before storing it. > Tested with new test case. > From paul.hohensee at oracle.com Thu Sep 30 07:13:32 2010 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 30 Sep 2010 10:13:32 -0400 Subject: Request for review(S): 6988346: 6986046 breaks tiered In-Reply-To: <4CA42816.8020807@oracle.com> References: <4CA37A0F.9020407@oracle.com> <4CA424DC.6090207@oracle.com> <4CA42816.8020807@oracle.com> Message-ID: <4CA49B0C.9080308@oracle.com> Send them the preprocessed source, i.e., the output of CC -E or -P. You can get it by cd'ing to the product build directory, then saying make foo.i and send them foo.i. foo.i should be directly compilable: try it yourself to verify before you send it. Paul On 9/30/10 2:03 AM, Igor Veresov wrote: > Ramki, > > If I were able to reduce it to a reasonable test case I would've > reported it. I didn't think it was practical to file it this way. > > igor > > On 9/29/10 10:49 PM, Y. Srinivas Ramakrishna wrote: >> On 9/29/2010 10:40 AM, Igor Veresov wrote: >> ... >>> - SunStudio S12u1 has problems with c1_LinearScan.cpp on 64bit x86, >>> which results in incorrect code. >>> The optimization level needs to temporarily lowered for this case. >> >> Has the bug been reported back to the SS folk? They cannot fix bugs that >> they >> might not know about :-) >> >> thanks. >> -- ramki > From paul.hohensee at oracle.com Thu Sep 30 08:13:04 2010 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 30 Sep 2010 11:13:04 -0400 Subject: Request for review(S): 6988346: 6986046 breaks tiered In-Reply-To: <4CA49B0C.9080308@oracle.com> References: <4CA37A0F.9020407@oracle.com> <4CA424DC.6090207@oracle.com> <4CA42816.8020807@oracle.com> <4CA49B0C.9080308@oracle.com> Message-ID: <4CA4A900.3050308@oracle.com> Forgot to add the obvious: send them a .s file and point to the offending code. To get a .s file, just do in the product build directory make foo.s Paul On 9/30/10 10:13 AM, Paul Hohensee wrote: > Send them the preprocessed source, i.e., the output of CC -E or -P. > You can get > it by cd'ing to the product build directory, then saying > > make foo.i > > and send them foo.i. foo.i should be directly compilable: try it > yourself to verify > before you send it. > > Paul > > On 9/30/10 2:03 AM, Igor Veresov wrote: >> Ramki, >> >> If I were able to reduce it to a reasonable test case I would've >> reported it. I didn't think it was practical to file it this way. >> >> igor >> >> On 9/29/10 10:49 PM, Y. Srinivas Ramakrishna wrote: >>> On 9/29/2010 10:40 AM, Igor Veresov wrote: >>> ... >>>> - SunStudio S12u1 has problems with c1_LinearScan.cpp on 64bit x86, >>>> which results in incorrect code. >>>> The optimization level needs to temporarily lowered for this case. >>> >>> Has the bug been reported back to the SS folk? They cannot fix bugs >>> that >>> they >>> might not know about :-) >>> >>> thanks. >>> -- ramki >> From tom.rodriguez at oracle.com Thu Sep 30 10:25:06 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 30 Sep 2010 10:25:06 -0700 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT In-Reply-To: <4CA499EA.7030103@gmx.de> References: <4CA499EA.7030103@gmx.de> Message-ID: On Sep 30, 2010, at 7:08 AM, Ulf Zibis wrote: > - Why do you increment by 8 in the Test? Because i'm storing longs. unsafe operates on direct addresses. > - ARRAY_LONG_BASE_OFFSET in capital letters is misleading to the reader, as this variable is not a final constant. Ok. tom > > -Ulf > > > Am 30.09.2010 03:25, schrieb Tom Rodriguez: >> http://cr.openjdk.java.net/~never/6968348 >> >> 6968348: Byteswapped memory access can point to wrong location after JIT >> Reviewed-by: >> >> x86_64.ad has match rules for (Store (ReverseBytes val)) but the >> definition is buggy since the val can be used in address of the store. >> It also doesn't record that it changes the input value. The fix is to >> simply remove these rules since they are no better than what we'd get >> otherwise. x86_32.ad doesn't have these rules. sparc.ad does but it >> can generate better code for these forms because it can use the byte >> swapped ASI and doesn't have to modify the register before storing it. >> Tested with new test case. >> From tom.rodriguez at oracle.com Thu Sep 30 10:35:37 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 30 Sep 2010 10:35:37 -0700 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT In-Reply-To: <4CA46A90.2010401@gmx.de> References: <4CA46A90.2010401@gmx.de> Message-ID: <823F148D-87F1-40EB-81F0-DD9E65E4BB3D@oracle.com> It fails for me. % /java/re/jdk/1.7.0/promoted/all/b104/binaries/solaris-amd64/fastdebug/bin/java -d64 Test6968348# # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xfffffd7ff94f5983, pid=14046, tid=2 # # JRE version: 7.0 # Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b05-fastdebug mixed mode solaris-amd64 compressed oops) # Problematic frame: # J Test6968348.test()V # # An error report file with more information is saved as: # /export/ws/baseline/test/compiler/6968348/hs_err_pid14046.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Maybe you're running in an environment were it happens to hit in mapped memory. tom On Sep 30, 2010, at 3:46 AM, Ulf Zibis wrote: > Hi, > > I have run Test6968348.java on b104. > It doesn't fail. > Why? > > -Ulf > > > Am 30.09.2010 03:25, schrieb Tom Rodriguez: >> http://cr.openjdk.java.net/~never/6968348 >> >> 6968348: Byteswapped memory access can point to wrong location after JIT >> Reviewed-by: >> >> x86_64.ad has match rules for (Store (ReverseBytes val)) but the >> definition is buggy since the val can be used in address of the store. >> It also doesn't record that it changes the input value. The fix is to >> simply remove these rules since they are no better than what we'd get >> otherwise. x86_32.ad doesn't have these rules. sparc.ad does but it >> can generate better code for these forms because it can use the byte >> swapped ASI and doesn't have to modify the register before storing it. >> Tested with new test case. >> From christian.thalinger at oracle.com Thu Sep 30 10:45:42 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 30 Sep 2010 19:45:42 +0200 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: <8B2D7285-416B-4590-A7B3-C5EF8AADC66F@oracle.com> References: <1285587786.27094.109.camel@macbook> <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> <1285748294.27094.1762.camel@macbook> <1285768699.27094.2120.camel@macbook> <20727F33-914D-4937-87DB-7FE4C09295D9@oracle.com> <342256CA-214E-4D57-8800-4847EC11908D@oracle.com> <8B2D7285-416B-4590-A7B3-C5EF8AADC66F@oracle.com> Message-ID: <1285868742.1772.336.camel@macbook> On Wed, 2010-09-29 at 09:40 -0700, John Rose wrote: > On Sep 29, 2010, at 9:22 AM, Tom Rodriguez wrote: > > > Why aren't the values dependent on which operation is being performed then? > > They certainly can be. That will move the complication out of the > assembly code. (And into methodHandles.cpp, with a new CPU-specific > query, plus a new but useful distinction between value conversion and > unboxing.) I'm fine with doing it either way. I will look into that and try to come up with a new patch. -- Christian From vladimir.kozlov at oracle.com Thu Sep 30 12:00:25 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Sep 2010 12:00:25 -0700 Subject: Request for reviews (S): 6916062: assert(_inserts <= _insert_limit, "hash table overflow") in NodeHash::hash_insert In-Reply-To: <4CA39000.1080601@oracle.com> References: <4CA29F9C.8040407@oracle.com> <94915A77-392B-421B-BC30-2D7A5D6995EE@oracle.com> <4CA39000.1080601@oracle.com> Message-ID: <4CA4DE49.9080504@oracle.com> I updated changes with bailout from IGVM optimization loop: http://cr.openjdk.java.net/~kvn/6916062/webrev.03 Thanks, Vladimir On 9/29/10 12:14 PM, Vladimir Kozlov wrote: > Thank you, Tom > > On 9/29/10 12:00 PM, Tom Rodriguez wrote: >> That seems fine for a backport. Maybe we should consider some product level code to bailout if we do too many rounds >> of IGVN? > > Yes, it is good idea to bailout. I will add it. > > Thanks, > Vladimir > >> >> tom >> >> On Sep 28, 2010, at 7:08 PM, Vladimir Kozlov wrote: >> >>> http://cr.openjdk.java.net/~kvn/6916062/webrev.02 >>> >>> Fixed 6916062: assert(_inserts<= _insert_limit,"hash table overflow") in NodeHash::hash_insert >>> >>> Changes for 6711117 put a memory node back on IGVN >>> worklist if address type does not match cached type >>> in a hope that address nodes will be processed and >>> the type will be updated. But it does not check that >>> there are nodes on worklist which will trigger address >>> processing. As result the memory node is pulled from >>> and pushed on IGVN worklist infinitely. >>> On each iteration NodeHash::_inserts value is incremented >>> forcing hash table grow until integer value NodeHash::_max >>> is overflow (became 0) which triggers bug's assert. >>> >>> I decided to go with simplest fix which is easy to backport >>> and leave fixing address type inconsistency for later >>> (I have bug 6715629). >>> I also added asserts to catch such situations. >>> >>> Tested with failing case, CTW, JPRT. >> From tom.rodriguez at oracle.com Thu Sep 30 12:19:22 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 30 Sep 2010 12:19:22 -0700 Subject: Request for reviews (S): 6916062: assert(_inserts <= _insert_limit, "hash table overflow") in NodeHash::hash_insert In-Reply-To: <4CA4DE49.9080504@oracle.com> References: <4CA29F9C.8040407@oracle.com> <94915A77-392B-421B-BC30-2D7A5D6995EE@oracle.com> <4CA39000.1080601@oracle.com> <4CA4DE49.9080504@oracle.com> Message-ID: <0016149E-5E7A-49C4-9341-90DBEA0DE7A5@oracle.com> 1024 * unique seems like a high enough limit but did you check ctw to see if it ever triggers? Also would we handle a bailout here gracefully? It would be good to set the limit lower and make sure we handle it properly. I'd be curious to see some statistics on how many iterations we normally perform in that loop but maybe that's a question for another day. tom On Sep 30, 2010, at 12:00 PM, Vladimir Kozlov wrote: > I updated changes with bailout from IGVM optimization loop: > > http://cr.openjdk.java.net/~kvn/6916062/webrev.03 > > Thanks, > Vladimir > > On 9/29/10 12:14 PM, Vladimir Kozlov wrote: >> Thank you, Tom >> >> On 9/29/10 12:00 PM, Tom Rodriguez wrote: >>> That seems fine for a backport. Maybe we should consider some product level code to bailout if we do too many rounds >>> of IGVN? >> >> Yes, it is good idea to bailout. I will add it. >> >> Thanks, >> Vladimir >> >>> >>> tom >>> >>> On Sep 28, 2010, at 7:08 PM, Vladimir Kozlov wrote: >>> >>>> http://cr.openjdk.java.net/~kvn/6916062/webrev.02 >>>> >>>> Fixed 6916062: assert(_inserts<= _insert_limit,"hash table overflow") in NodeHash::hash_insert >>>> >>>> Changes for 6711117 put a memory node back on IGVN >>>> worklist if address type does not match cached type >>>> in a hope that address nodes will be processed and >>>> the type will be updated. But it does not check that >>>> there are nodes on worklist which will trigger address >>>> processing. As result the memory node is pulled from >>>> and pushed on IGVN worklist infinitely. >>>> On each iteration NodeHash::_inserts value is incremented >>>> forcing hash table grow until integer value NodeHash::_max >>>> is overflow (became 0) which triggers bug's assert. >>>> >>>> I decided to go with simplest fix which is easy to backport >>>> and leave fixing address type inconsistency for later >>>> (I have bug 6715629). >>>> I also added asserts to catch such situations. >>>> >>>> Tested with failing case, CTW, JPRT. >>> From vladimir.kozlov at oracle.com Thu Sep 30 12:54:33 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Sep 2010 12:54:33 -0700 Subject: Request for reviews (S): 6916062: assert(_inserts <= _insert_limit, "hash table overflow") in NodeHash::hash_insert In-Reply-To: <0016149E-5E7A-49C4-9341-90DBEA0DE7A5@oracle.com> References: <4CA29F9C.8040407@oracle.com> <94915A77-392B-421B-BC30-2D7A5D6995EE@oracle.com> <4CA39000.1080601@oracle.com> <4CA4DE49.9080504@oracle.com> <0016149E-5E7A-49C4-9341-90DBEA0DE7A5@oracle.com> Message-ID: <4CA4EAF9.2050607@oracle.com> I ran throw CTW previous code webrev.02 (only with assert fastdebug VM) and it is never triggered. It also passed nsk.stress testing. All exits from igvn.optimize() are checked with C->failing(). But I will check if it exit correctly with lower limit. Thanks, Vladimir On 9/30/10 12:19 PM, Tom Rodriguez wrote: > 1024 * unique seems like a high enough limit but did you check ctw to see if it ever triggers? Also would we handle a bailout here gracefully? It would be good to set the limit lower and make sure we handle it properly. I'd be curious to see some statistics on how many iterations we normally perform in that loop but maybe that's a question for another day. > > tom > > On Sep 30, 2010, at 12:00 PM, Vladimir Kozlov wrote: > >> I updated changes with bailout from IGVM optimization loop: >> >> http://cr.openjdk.java.net/~kvn/6916062/webrev.03 >> >> Thanks, >> Vladimir >> >> On 9/29/10 12:14 PM, Vladimir Kozlov wrote: >>> Thank you, Tom >>> >>> On 9/29/10 12:00 PM, Tom Rodriguez wrote: >>>> That seems fine for a backport. Maybe we should consider some product level code to bailout if we do too many rounds >>>> of IGVN? >>> >>> Yes, it is good idea to bailout. I will add it. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> tom >>>> >>>> On Sep 28, 2010, at 7:08 PM, Vladimir Kozlov wrote: >>>> >>>>> http://cr.openjdk.java.net/~kvn/6916062/webrev.02 >>>>> >>>>> Fixed 6916062: assert(_inserts<= _insert_limit,"hash table overflow") in NodeHash::hash_insert >>>>> >>>>> Changes for 6711117 put a memory node back on IGVN >>>>> worklist if address type does not match cached type >>>>> in a hope that address nodes will be processed and >>>>> the type will be updated. But it does not check that >>>>> there are nodes on worklist which will trigger address >>>>> processing. As result the memory node is pulled from >>>>> and pushed on IGVN worklist infinitely. >>>>> On each iteration NodeHash::_inserts value is incremented >>>>> forcing hash table grow until integer value NodeHash::_max >>>>> is overflow (became 0) which triggers bug's assert. >>>>> >>>>> I decided to go with simplest fix which is easy to backport >>>>> and leave fixing address type inconsistency for later >>>>> (I have bug 6715629). >>>>> I also added asserts to catch such situations. >>>>> >>>>> Tested with failing case, CTW, JPRT. >>>> > From Ulf.Zibis at gmx.de Thu Sep 30 14:53:20 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 30 Sep 2010 23:53:20 +0200 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT In-Reply-To: <823F148D-87F1-40EB-81F0-DD9E65E4BB3D@oracle.com> References: <4CA46A90.2010401@gmx.de> <823F148D-87F1-40EB-81F0-DD9E65E4BB3D@oracle.com> Message-ID: <4CA506D0.6070503@gmx.de> Ah, ok, I'm running on Intel 32-bit architecture. Is it ensured, that this test is always running on 64-bit architectures, but never on 32-bits? Thanks, -Ulf Am 30.09.2010 19:35, schrieb Tom Rodriguez: > It fails for me. > > % /java/re/jdk/1.7.0/promoted/all/b104/binaries/solaris-amd64/fastdebug/bin/java -d64 Test6968348# > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0xfffffd7ff94f5983, pid=14046, tid=2 > # > # JRE version: 7.0 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b05-fastdebug mixed mode solaris-amd64 compressed oops) > # Problematic frame: > # J Test6968348.test()V > # > # An error report file with more information is saved as: > # /export/ws/baseline/test/compiler/6968348/hs_err_pid14046.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > Maybe you're running in an environment were it happens to hit in mapped memory. > > tom > > On Sep 30, 2010, at 3:46 AM, Ulf Zibis wrote: > >> Hi, >> >> I have run Test6968348.java on b104. >> It doesn't fail. >> Why? >> >> -Ulf >> >> >> Am 30.09.2010 03:25, schrieb Tom Rodriguez: >>> http://cr.openjdk.java.net/~never/6968348 >>> >>> 6968348: Byteswapped memory access can point to wrong location after JIT >>> Reviewed-by: >>> >>> x86_64.ad has match rules for (Store (ReverseBytes val)) but the >>> definition is buggy since the val can be used in address of the store. >>> It also doesn't record that it changes the input value. The fix is to >>> simply remove these rules since they are no better than what we'd get >>> otherwise. x86_32.ad doesn't have these rules. sparc.ad does but it >>> can generate better code for these forms because it can use the byte >>> swapped ASI and doesn't have to modify the register before storing it. >>> Tested with new test case. >>> > From Ulf.Zibis at gmx.de Thu Sep 30 15:01:04 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 01 Oct 2010 00:01:04 +0200 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT In-Reply-To: References: <4CA499EA.7030103@gmx.de> Message-ID: <4CA508A0.6010806@gmx.de> Am 30.09.2010 19:25, schrieb Tom Rodriguez: > On Sep 30, 2010, at 7:08 AM, Ulf Zibis wrote: > >> - Why do you increment by 8 in the Test? > Because i'm storing longs. unsafe operates on direct addresses. Hm, but you are storing in a long[], not a byte[], or do I miss something? Will have an additional look at it tomorrow. >> - ARRAY_LONG_BASE_OFFSET in capital letters is misleading to the reader, as this variable is not a final constant. > Ok. I have an idea for an alternative. Are you interested? -Ulf From tom.rodriguez at oracle.com Thu Sep 30 15:10:03 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 30 Sep 2010 15:10:03 -0700 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT In-Reply-To: <4CA506D0.6070503@gmx.de> References: <4CA46A90.2010401@gmx.de> <823F148D-87F1-40EB-81F0-DD9E65E4BB3D@oracle.com> <4CA506D0.6070503@gmx.de> Message-ID: On Sep 30, 2010, at 2:53 PM, Ulf Zibis wrote: > Ah, ok, I'm running on Intel 32-bit architecture. > Is it ensured, that this test is always running on 64-bit architectures, but never on 32-bits? No. Why should it be? It's valid code whereever it runs and we run our tests on all architectures. tom > > Thanks, > > -Ulf > > > Am 30.09.2010 19:35, schrieb Tom Rodriguez: >> It fails for me. >> >> % /java/re/jdk/1.7.0/promoted/all/b104/binaries/solaris-amd64/fastdebug/bin/java -d64 Test6968348# >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0xfffffd7ff94f5983, pid=14046, tid=2 >> # >> # JRE version: 7.0 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b05-fastdebug mixed mode solaris-amd64 compressed oops) >> # Problematic frame: >> # J Test6968348.test()V >> # >> # An error report file with more information is saved as: >> # /export/ws/baseline/test/compiler/6968348/hs_err_pid14046.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> Maybe you're running in an environment were it happens to hit in mapped memory. >> >> tom >> >> On Sep 30, 2010, at 3:46 AM, Ulf Zibis wrote: >> >>> Hi, >>> >>> I have run Test6968348.java on b104. >>> It doesn't fail. >>> Why? >>> >>> -Ulf >>> >>> >>> Am 30.09.2010 03:25, schrieb Tom Rodriguez: >>>> http://cr.openjdk.java.net/~never/6968348 >>>> >>>> 6968348: Byteswapped memory access can point to wrong location after JIT >>>> Reviewed-by: >>>> >>>> x86_64.ad has match rules for (Store (ReverseBytes val)) but the >>>> definition is buggy since the val can be used in address of the store. >>>> It also doesn't record that it changes the input value. The fix is to >>>> simply remove these rules since they are no better than what we'd get >>>> otherwise. x86_32.ad doesn't have these rules. sparc.ad does but it >>>> can generate better code for these forms because it can use the byte >>>> swapped ASI and doesn't have to modify the register before storing it. >>>> Tested with new test case. >>>> >> From vladimir.kozlov at oracle.com Thu Sep 30 15:14:49 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Sep 2010 15:14:49 -0700 Subject: Request for reviews (S): 6916062: assert(_inserts <= _insert_limit, "hash table overflow") in NodeHash::hash_insert In-Reply-To: <4CA4EAF9.2050607@oracle.com> References: <4CA29F9C.8040407@oracle.com> <94915A77-392B-421B-BC30-2D7A5D6995EE@oracle.com> <4CA39000.1080601@oracle.com> <4CA4DE49.9080504@oracle.com> <0016149E-5E7A-49C4-9341-90DBEA0DE7A5@oracle.com> <4CA4EAF9.2050607@oracle.com> Message-ID: <4CA50BD9.6020601@oracle.com> I ran full CTW with 10*unique and did not get bailouts. Only when I used 2*unique I got 6 cases. I rerun them with product VM and they exited gracefully: 2234 COMPILE SKIPPED: infinite loop in PhaseIterGVN::optimize (not retryable) Vladimir On 9/30/10 12:54 PM, Vladimir Kozlov wrote: > I ran throw CTW previous code webrev.02 (only with assert fastdebug VM) and it is never triggered. It also passed > nsk.stress testing. All exits from igvn.optimize() are checked with C->failing(). But I will check if it exit > correctly with lower limit. > > Thanks, > Vladimir > > On 9/30/10 12:19 PM, Tom Rodriguez wrote: >> 1024 * unique seems like a high enough limit but did you check ctw to see if it ever triggers? Also would we handle a >> bailout here gracefully? It would be good to set the limit lower and make sure we handle it properly. I'd be curious >> to see some statistics on how many iterations we normally perform in that loop but maybe that's a question for another >> day. >> >> tom >> >> On Sep 30, 2010, at 12:00 PM, Vladimir Kozlov wrote: >> >>> I updated changes with bailout from IGVM optimization loop: >>> >>> http://cr.openjdk.java.net/~kvn/6916062/webrev.03 >>> >>> Thanks, >>> Vladimir >>> >>> On 9/29/10 12:14 PM, Vladimir Kozlov wrote: >>>> Thank you, Tom >>>> >>>> On 9/29/10 12:00 PM, Tom Rodriguez wrote: >>>>> That seems fine for a backport. Maybe we should consider some product level code to bailout if we do too many rounds >>>>> of IGVN? >>>> >>>> Yes, it is good idea to bailout. I will add it. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> tom >>>>> >>>>> On Sep 28, 2010, at 7:08 PM, Vladimir Kozlov wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~kvn/6916062/webrev.02 >>>>>> >>>>>> Fixed 6916062: assert(_inserts<= _insert_limit,"hash table overflow") in NodeHash::hash_insert >>>>>> >>>>>> Changes for 6711117 put a memory node back on IGVN >>>>>> worklist if address type does not match cached type >>>>>> in a hope that address nodes will be processed and >>>>>> the type will be updated. But it does not check that >>>>>> there are nodes on worklist which will trigger address >>>>>> processing. As result the memory node is pulled from >>>>>> and pushed on IGVN worklist infinitely. >>>>>> On each iteration NodeHash::_inserts value is incremented >>>>>> forcing hash table grow until integer value NodeHash::_max >>>>>> is overflow (became 0) which triggers bug's assert. >>>>>> >>>>>> I decided to go with simplest fix which is easy to backport >>>>>> and leave fixing address type inconsistency for later >>>>>> (I have bug 6715629). >>>>>> I also added asserts to catch such situations. >>>>>> >>>>>> Tested with failing case, CTW, JPRT. >>>>> >> From igor.veresov at oracle.com Thu Sep 30 15:17:56 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 30 Sep 2010 15:17:56 -0700 Subject: Request for review(XXS): 6988779: c1_LIRAssembler_x86.cpp crashes VS2010 compiler Message-ID: <4CA50C94.3060604@oracle.com> VS2010 compiler didn't like the code in c1_LIRAssember_x86.cpp. This change seems to make it happier. Webrev: http://cr.openjdk.java.net/~iveresov/6988779/webrev.00/ Thanks, igor From vladimir.kozlov at oracle.com Thu Sep 30 15:22:54 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Sep 2010 15:22:54 -0700 Subject: Request for review(XXS): 6988779: c1_LIRAssembler_x86.cpp crashes VS2010 compiler In-Reply-To: <4CA50C94.3060604@oracle.com> References: <4CA50C94.3060604@oracle.com> Message-ID: <4CA50DBE.6090207@oracle.com> Looks good. Vladimir On 9/30/10 3:17 PM, Igor Veresov wrote: > VS2010 compiler didn't like the code in c1_LIRAssember_x86.cpp. > This change seems to make it happier. > > Webrev: http://cr.openjdk.java.net/~iveresov/6988779/webrev.00/ > > Thanks, > igor From igor.veresov at oracle.com Thu Sep 30 15:26:17 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 30 Sep 2010 15:26:17 -0700 Subject: Request for review(XXS): 6988779: c1_LIRAssembler_x86.cpp crashes VS2010 compiler In-Reply-To: <4CA50DBE.6090207@oracle.com> References: <4CA50C94.3060604@oracle.com> <4CA50DBE.6090207@oracle.com> Message-ID: <4CA50E89.3030203@oracle.com> Thanks Vladimir, Paul, Ramki! On 9/30/10 3:22 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 9/30/10 3:17 PM, Igor Veresov wrote: >> VS2010 compiler didn't like the code in c1_LIRAssember_x86.cpp. >> This change seems to make it happier. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6988779/webrev.00/ >> >> Thanks, >> igor From tom.rodriguez at oracle.com Thu Sep 30 16:03:50 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 30 Sep 2010 16:03:50 -0700 Subject: Request for reviews (S): 6916062: assert(_inserts <= _insert_limit, "hash table overflow") in NodeHash::hash_insert In-Reply-To: <4CA50BD9.6020601@oracle.com> References: <4CA29F9C.8040407@oracle.com> <94915A77-392B-421B-BC30-2D7A5D6995EE@oracle.com> <4CA39000.1080601@oracle.com> <4CA4DE49.9080504@oracle.com> <0016149E-5E7A-49C4-9341-90DBEA0DE7A5@oracle.com> <4CA4EAF9.2050607@oracle.com> <4CA50BD9.6020601@oracle.com> Message-ID: <919B0BFA-DFCD-4E25-A7E1-69AFAF6FCE78@oracle.com> Excellent. That all looks great then. Maybe a limit of 16 * unique would be a better default instead of 1024? 1024 is ok as well though. tom On Sep 30, 2010, at 3:14 PM, Vladimir Kozlov wrote: > I ran full CTW with 10*unique and did not get bailouts. > Only when I used 2*unique I got 6 cases. I rerun them with product VM > and they exited gracefully: > > 2234 COMPILE SKIPPED: infinite loop in PhaseIterGVN::optimize (not retryable) > > Vladimir > > On 9/30/10 12:54 PM, Vladimir Kozlov wrote: >> I ran throw CTW previous code webrev.02 (only with assert fastdebug VM) and it is never triggered. It also passed >> nsk.stress testing. All exits from igvn.optimize() are checked with C->failing(). But I will check if it exit >> correctly with lower limit. >> >> Thanks, >> Vladimir >> >> On 9/30/10 12:19 PM, Tom Rodriguez wrote: >>> 1024 * unique seems like a high enough limit but did you check ctw to see if it ever triggers? Also would we handle a >>> bailout here gracefully? It would be good to set the limit lower and make sure we handle it properly. I'd be curious >>> to see some statistics on how many iterations we normally perform in that loop but maybe that's a question for another >>> day. >>> >>> tom >>> >>> On Sep 30, 2010, at 12:00 PM, Vladimir Kozlov wrote: >>> >>>> I updated changes with bailout from IGVM optimization loop: >>>> >>>> http://cr.openjdk.java.net/~kvn/6916062/webrev.03 >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/29/10 12:14 PM, Vladimir Kozlov wrote: >>>>> Thank you, Tom >>>>> >>>>> On 9/29/10 12:00 PM, Tom Rodriguez wrote: >>>>>> That seems fine for a backport. Maybe we should consider some product level code to bailout if we do too many rounds >>>>>> of IGVN? >>>>> >>>>> Yes, it is good idea to bailout. I will add it. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> tom >>>>>> >>>>>> On Sep 28, 2010, at 7:08 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~kvn/6916062/webrev.02 >>>>>>> >>>>>>> Fixed 6916062: assert(_inserts<= _insert_limit,"hash table overflow") in NodeHash::hash_insert >>>>>>> >>>>>>> Changes for 6711117 put a memory node back on IGVN >>>>>>> worklist if address type does not match cached type >>>>>>> in a hope that address nodes will be processed and >>>>>>> the type will be updated. But it does not check that >>>>>>> there are nodes on worklist which will trigger address >>>>>>> processing. As result the memory node is pulled from >>>>>>> and pushed on IGVN worklist infinitely. >>>>>>> On each iteration NodeHash::_inserts value is incremented >>>>>>> forcing hash table grow until integer value NodeHash::_max >>>>>>> is overflow (became 0) which triggers bug's assert. >>>>>>> >>>>>>> I decided to go with simplest fix which is easy to backport >>>>>>> and leave fixing address type inconsistency for later >>>>>>> (I have bug 6715629). >>>>>>> I also added asserts to catch such situations. >>>>>>> >>>>>>> Tested with failing case, CTW, JPRT. >>>>>> >>> From vladimir.kozlov at oracle.com Thu Sep 30 16:43:12 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Sep 2010 16:43:12 -0700 Subject: Request for reviews (S): 6916062: assert(_inserts <= _insert_limit, "hash table overflow") in NodeHash::hash_insert In-Reply-To: <919B0BFA-DFCD-4E25-A7E1-69AFAF6FCE78@oracle.com> References: <4CA29F9C.8040407@oracle.com> <94915A77-392B-421B-BC30-2D7A5D6995EE@oracle.com> <4CA39000.1080601@oracle.com> <4CA4DE49.9080504@oracle.com> <0016149E-5E7A-49C4-9341-90DBEA0DE7A5@oracle.com> <4CA4EAF9.2050607@oracle.com> <4CA50BD9.6020601@oracle.com> <919B0BFA-DFCD-4E25-A7E1-69AFAF6FCE78@oracle.com> Message-ID: <4CA52090.2070102@oracle.com> Thank you, Tom Vladimir On 9/30/10 4:03 PM, Tom Rodriguez wrote: > Excellent. That all looks great then. Maybe a limit of 16 * unique would be a better default instead of 1024? 1024 is ok as well though. > > tom > > On Sep 30, 2010, at 3:14 PM, Vladimir Kozlov wrote: > >> I ran full CTW with 10*unique and did not get bailouts. >> Only when I used 2*unique I got 6 cases. I rerun them with product VM >> and they exited gracefully: >> >> 2234 COMPILE SKIPPED: infinite loop in PhaseIterGVN::optimize (not retryable) >> >> Vladimir >> >> On 9/30/10 12:54 PM, Vladimir Kozlov wrote: >>> I ran throw CTW previous code webrev.02 (only with assert fastdebug VM) and it is never triggered. It also passed >>> nsk.stress testing. All exits from igvn.optimize() are checked with C->failing(). But I will check if it exit >>> correctly with lower limit. >>> >>> Thanks, >>> Vladimir >>> >>> On 9/30/10 12:19 PM, Tom Rodriguez wrote: >>>> 1024 * unique seems like a high enough limit but did you check ctw to see if it ever triggers? Also would we handle a >>>> bailout here gracefully? It would be good to set the limit lower and make sure we handle it properly. I'd be curious >>>> to see some statistics on how many iterations we normally perform in that loop but maybe that's a question for another >>>> day. >>>> >>>> tom >>>> >>>> On Sep 30, 2010, at 12:00 PM, Vladimir Kozlov wrote: >>>> >>>>> I updated changes with bailout from IGVM optimization loop: >>>>> >>>>> http://cr.openjdk.java.net/~kvn/6916062/webrev.03 >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/29/10 12:14 PM, Vladimir Kozlov wrote: >>>>>> Thank you, Tom >>>>>> >>>>>> On 9/29/10 12:00 PM, Tom Rodriguez wrote: >>>>>>> That seems fine for a backport. Maybe we should consider some product level code to bailout if we do too many rounds >>>>>>> of IGVN? >>>>>> >>>>>> Yes, it is good idea to bailout. I will add it. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> tom >>>>>>> >>>>>>> On Sep 28, 2010, at 7:08 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~kvn/6916062/webrev.02 >>>>>>>> >>>>>>>> Fixed 6916062: assert(_inserts<= _insert_limit,"hash table overflow") in NodeHash::hash_insert >>>>>>>> >>>>>>>> Changes for 6711117 put a memory node back on IGVN >>>>>>>> worklist if address type does not match cached type >>>>>>>> in a hope that address nodes will be processed and >>>>>>>> the type will be updated. But it does not check that >>>>>>>> there are nodes on worklist which will trigger address >>>>>>>> processing. As result the memory node is pulled from >>>>>>>> and pushed on IGVN worklist infinitely. >>>>>>>> On each iteration NodeHash::_inserts value is incremented >>>>>>>> forcing hash table grow until integer value NodeHash::_max >>>>>>>> is overflow (became 0) which triggers bug's assert. >>>>>>>> >>>>>>>> I decided to go with simplest fix which is easy to backport >>>>>>>> and leave fixing address type inconsistency for later >>>>>>>> (I have bug 6715629). >>>>>>>> I also added asserts to catch such situations. >>>>>>>> >>>>>>>> Tested with failing case, CTW, JPRT. >>>>>>> >>>> >