From thomas.rodriguez at sun.com Sun Mar 1 23:27:25 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Mon, 02 Mar 2009 07:27:25 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6811384: MacroAssembler::serialize_memory may touch next page on amd64 Message-ID: <20090302072730.B8852E58E@hg.openjdk.java.net> Changeset: 19962e74284f Author: never Date: 2009-03-01 20:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/19962e74284f 6811384: MacroAssembler::serialize_memory may touch next page on amd64 Reviewed-by: kvn, phh, twisti ! src/cpu/x86/vm/assembler_x86.cpp From Christian.Thalinger at Sun.COM Mon Mar 2 02:30:15 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 02 Mar 2009 11:30:15 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <323398B3-5BE1-415D-8E4B-0073BD434683@Sun.COM> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <323398B3-5BE1-415D-8E4B-0073BD434683@Sun.COM> Message-ID: <1235989815.2239.10.camel@localhost.localdomain> On Fri, 2009-02-27 at 14:58 -0800, Tom Rodriguez wrote: > I've added some more parsing lookahead to deal with this case properly > and updated the address webrev to include it. $mem$$base$$Register > and $mem$$index$$Register should now emit properly. Works great, thanks! Now there are only two small things left: - Something like $dst$$Register$high or $dst$$HighRegister for x86_32, so the long HIGH_FROM_LOW macro can be omitted. The same for $low would also be nice, just to make it more obvious. - Similar to the one above for $mem, e.g. $mem$$Address$high, for long memory accesses. Currently I'm using: ins_encode %{ Address Amemlo = Address::make_raw($mem$$base, $mem$$index, $mem$$scale, $mem$$disp, false); Address Amemhi = Address::make_raw($mem$$base, $mem$$index, $mem$$scale, $mem$$disp + 4, false); __ movl($dst$$Register, Amemlo); __ movl(HIGH_FROM_LOW($dst$$Register), Amemhi); %} I can try to add that functionality, but I wanted to ask if there is already something like that? -- Christian From Christian.Thalinger at Sun.COM Mon Mar 2 09:31:15 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 02 Mar 2009 18:31:15 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1235770496.2004.2104.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> Message-ID: <1236015075.2239.37.camel@localhost.localdomain> On Fri, 2009-02-27 at 22:34 +0100, Christian Thalinger wrote: > On Fri, 2009-02-27 at 10:06 -0800, Tom Rodriguez wrote: > > Basically you have to distinguish the two modes by hand. Check out > > the loadN instruct definition. > > Okay, I will have a look at it. Oops, I almost forgot to look at that. Adding that check to all other cases sounds not like a good idea. Two questions/solutions: 1. Can normal loads and stores be indexed? 2. What about adding load and store assembler instruction like on x86 with an Address argument, e.g. inline void lduw(Address a, Register d); The inline void lduw(const Address& a, Register d, int offset = 0); seems to be doing something different, although I don't know yet what. -- Christian From John.Rose at Sun.COM Mon Mar 2 09:34:39 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 02 Mar 2009 09:34:39 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1235989815.2239.10.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <323398B3-5BE1-415D-8E4B-0073BD434683@Sun.COM> <1235989815.2239.10.camel@localhost.localdomain> Message-ID: On Mar 2, 2009, at 2:30 AM, Christian Thalinger wrote: > - Similar to the one above for $mem, e.g. $mem$$Address$high, for long > memory accesses. Currently I'm using: Do be careful with the high/low terminology! That had gotten us into "endian" portability problems. I suggest sticking to first/second, which unlike high/low unambiguously refer to the lower address and the higher address. Of course, ADLC can make high/low be aliases for second/first on little endian systems and first/second on big endian systems. Even better would be avoiding high/low, because in different contexts those words can seem to refer to arithmetic significance or memory order, and only on little-endian systems do those concepts (accidentally) align. When talking about arithmetic significance, msw/lsw is probably better than high/low. For register contents, we already use high/low in some places, and it twists around our endian story, causing bugs when the system is changed. Those points are (loosely speaking) portability problems embedded in the system due to early sloppiness, since HotSpot was originally an x86-only system. Let's make it better over time. The "gold standard" would be to use a single terminology for word pairs that is consistent across memory and register values. Since memory values are copied around in the JVM more than they are used for 2s-complement arithmetic, first/second is far more helpful than msw/ lsw. And high/low is just ambiguous. -- John P.S. Someone might point out that registers don't live in memory, so my concern for using first/second for them is over-scrupulous. They'd be wrong, since the register allocator uses a common linearly addressed model for both machine registers and stack slots. This linear model is, in turn, used by the vframe code, which is responsible for unpacking and packing between stack frames and registers and heap structures. Adapter generation code also uses the unified numbering. Thus, registers, stack slots, and heap values are all manipulated in a common framework. The system goes slowly insane if you try to use different ordering conventions for those different categories of storage. Please trust me when I say we don't want to go there again. From Christian.Thalinger at Sun.COM Mon Mar 2 09:53:25 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 02 Mar 2009 18:53:25 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <323398B3-5BE1-415D-8E4B-0073BD434683@Sun.COM> <1235989815.2239.10.camel@localhost.localdomain> Message-ID: <1236016405.2239.42.camel@localhost.localdomain> On Mon, 2009-03-02 at 09:34 -0800, John Rose wrote: > On Mar 2, 2009, at 2:30 AM, Christian Thalinger wrote: > > > - Similar to the one above for $mem, e.g. $mem$$Address$high, for long > > memory accesses. Currently I'm using: > > Do be careful with the high/low terminology! That had gotten us into > "endian" portability problems. > > I suggest sticking to first/second, which unlike high/low > unambiguously refer to the lower address and the higher address. Of > course, ADLC can make high/low be aliases for second/first on little > endian systems and first/second on big endian systems. Even better > would be avoiding high/low, because in different contexts those words > can seem to refer to arithmetic significance or memory order, and only > on little-endian systems do those concepts (accidentally) align. When > talking about arithmetic significance, msw/lsw is probably better than > high/low. > > For register contents, we already use high/low in some places, and it > twists around our endian story, causing bugs when the system is > changed. Those points are (loosely speaking) portability problems > embedded in the system due to early sloppiness, since HotSpot was > originally an x86-only system. Let's make it better over time. > > The "gold standard" would be to use a single terminology for word > pairs that is consistent across memory and register values. Since > memory values are copied around in the JVM more than they are used for > 2s-complement arithmetic, first/second is far more helpful than msw/ > lsw. And high/low is just ambiguous. Thanks for pointing that out, and you're absolutely right. CACAO supported about 11 different architectures and I know what you mean by "endian portability problems". first/second is probably a bit more confusing when seen for the first time than lsw/msw would be, but I'm fine with the former too. Is there already something like first/second around? -- Christian From Vladimir.Kozlov at Sun.COM Mon Mar 2 17:34:53 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 02 Mar 2009 17:34:53 -0800 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> Message-ID: <49AC893D.5080609@sun.com> John, Since delayed_value implementation can be safely separated from the rest of your changes can you push it separately? Here is review for it. In general it is good. ------------------- Why you did not put class RegisterConstant into src/share/vm/asm/assembler.hpp? You can leave a comment where to look for it. ------------------- MacroAssembler::delayed_value() uses RegisterConstant constructors implicitly. Can you change it to explicit usage? ------------------- assembler_x86.cpp/MacroAssembler::load_sized_value() And you asked Christian don't use high/low words :) : 6251 // For case 8, caller is responsible for manually loading 6252 // the high word into another register. Also why you are using movptr() in the corresponding part in MethodHandles::generate_method_handle_stub() ?: 494 __ load_sized_value(rbx_temp, prim_value_addr, 495 type2aelembytes(arg_type), is_signed_subword_type(arg_type)); 496 __ movptr(Address(rax_argslot, 0), rbx_temp); 497 #ifndef _LP64 498 if (arg_slots == 2) { 499 __ movl(rbx_temp, prim_value_addr.plus_disp(wordSize)); 500 __ movptr(Address(rax_argslot, Interpreter::stackElementSize()), rbx_temp); 501 } 502 #endif //_LP64 And may be better use load_signed_short/load_unsigned_short names: 6261 case ~2: load_signed_word( dst, src ); break; 6262 case 2: load_unsigned_word( dst, src ); break; ------------------- assembler.cpp: We talked about to comment why DC_LIMIT = 20. ------------------- assembler.hpp: I think, instead of "// Use sparingly" it may be better to explain that is mostly used for java classes non-static field offsets (currently only for MethodHandle) when we need to generated assembler code before the class is loaded and field offsets are not known. Also that is why the value can't be 0 since an object has markword at 0 offset. 285 // The value zero (NULL) stands instead of a constant which is still uncomputed. 286 // Use sparingly. ------------------- Why the next method does not return intptr_t* also? static address* delayed_value_addr(address(*constant_fn)()); ------------------- The variable last_WrongMethodType_caller is declared but is not used: src/cpu/sparc/vm/interpreter_sparc.cpp ------------------- On x64 in 2 files in TemplateTable::prepare_invoke() why you changed movptr(recv to movl(recv / movq(recv ? Did you fix a problem? It should be separate bug in that case? ------------------- Thanks, Vladimir John Rose wrote: > This is part of the JVM side of the JSR 292 Reference Implementation. > It should have no effect on application execution, unless one of the new > flags is turned on (chiefly -XX:+MethodHandleSupport). > > Present limitations: > - It works only on x86/32. (No sparc, compressed oops, cpp interpreter.) > - There are no compiler optimizations. > - It is young code. There are bugs. But only when a new flag is > turned on. > > This review is for contents of meth.patch, to be pushed from mlvm to > http://hg.openjdk.java.net/jdk7/hotspot-comp-gate/hotspot . > > Here is the webrev for this review: > http://webrev.invokedynamic.info/jrose/6655638.meth/ > > Here is the mlvm patch where the code currently lives: > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/tip/meth.patch > > An earlier version of these changes pass JPRT; it is expected that at > most minor tweaks will be needed to push it through again. > > Even though they are large, the changes should also pass a simple visual > inspection, since all substantially new control paths are guarded by > tests of the new flags. > > Please give it a look. > > -- John > > P.S. Here are some relevant conversations about method handles and > invokedynamic: > http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000321.html > http://blogs.sun.com/jrose/entry/international_invokedynamic_day > http://blogs.sun.com/dannycoward/entry/firing_up_the_engines_for > > http://groups.google.com/group/jvm-languages/browse_thread/thread/a4b8a616eb987ca8 > > > P.P.S. The proposed JDK changes are independent. At present, you can > find them here, in patch and webrev formats: > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/tip/meth.proj.patch > http://webrev.invokedynamic.info/jrose/6655638.meth.proj/ > From Thomas.Rodriguez at Sun.COM Tue Mar 3 09:56:49 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 03 Mar 2009 09:56:49 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236015075.2239.37.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> Message-ID: <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> On Mar 2, 2009, at 9:31 AM, Christian Thalinger wrote: > On Fri, 2009-02-27 at 22:34 +0100, Christian Thalinger wrote: >> On Fri, 2009-02-27 at 10:06 -0800, Tom Rodriguez wrote: >>> Basically you have to distinguish the two modes by hand. Check out >>> the loadN instruct definition. >> >> Okay, I will have a look at it. > > Oops, I almost forgot to look at that. Adding that check to all other > cases sounds not like a good idea. Two questions/solutions: It is a little unsatisfying. Using the MacroAssembler on intel seems a little more important to me since the encodings are so complex and are easy to get wrong. > 1. Can normal loads and stores be indexed? Sparc only has reg,reg and reg/simm13 addressing modes and C2 will use whichever is appropriate. > 2. What about adding load and store assembler instruction like on x86 > with an Address argument, e.g. > > inline void lduw(Address a, Register d); We could, though fixing that along with what you are doing seems like loading more than want into your change. I'd leave the sparc encodings along for now and we can fix it later to support the Address stuff. > The > > inline void lduw(const Address& a, Register d, int offset = 0); > > seems to be doing something different, although I don't know yet what. I've never understood what the Address variants do in the sparc assembler. They're very strange. Any change to use Address more normally would require changing those too I think. tom > > > -- Christian > From Christian.Thalinger at Sun.COM Tue Mar 3 10:08:36 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 03 Mar 2009 19:08:36 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> Message-ID: <1236103716.2239.105.camel@localhost.localdomain> On Tue, 2009-03-03 at 09:56 -0800, Tom Rodriguez wrote: > > 2. What about adding load and store assembler instruction like on x86 > > with an Address argument, e.g. > > > > inline void lduw(Address a, Register d); > > We could, though fixing that along with what you are doing seems like > loading more than want into your change. I'd leave the sparc > encodings along for now and we can fix it later to support the Address > stuff. Yeah, I will do that. I will post a webrev later and open a new CR for the Address changes on SPARC. > > The > > > > inline void lduw(const Address& a, Register d, int offset = 0); > > > > seems to be doing something different, although I don't know yet what. > > I've never understood what the Address variants do in the sparc > assembler. They're very strange. Any change to use Address more > normally would require changing those too I think. :-) -- Christian From Thomas.Rodriguez at Sun.COM Tue Mar 3 10:13:21 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 03 Mar 2009 10:13:21 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1235989815.2239.10.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <323398B3-5BE1-415D-8E4B-0073BD434683@Sun.COM> <1235989815.2239.10.camel@localhost.localdomain> Message-ID: <83DA55DF-1B42-4EFC-B7D1-C69E02A932EA@Sun.COM> On Mar 2, 2009, at 2:30 AM, Christian Thalinger wrote: > On Fri, 2009-02-27 at 14:58 -0800, Tom Rodriguez wrote: >> I've added some more parsing lookahead to deal with this case >> properly >> and updated the address webrev to include it. $mem$$base$$Register >> and $mem$$index$$Register should now emit properly. > > Works great, thanks! Now there are only two small things left: > > - Something like $dst$$Register$high or $dst$$HighRegister for x86_32, > so the long HIGH_FROM_LOW macro can be omitted. The same for $low > would > also be nice, just to make it more obvious. The HIGH_FROM_LOW macro is dependent on the register encoding that x86_32.ad uses so it would need to be revisited. $$reg returns the encoding for the register and the ordering of the registers pairs in alloc_class chunk0 makes it so the encoding of the pairs matches this. So we end up emitting (opnd_array(0)->reg(ra_,this)+2) to produce the encoding. If we made something like $$second it should rely on the OptoReg numbering for this instead. Basically we should grab the next optoreg and ask for the encoding of that. So we would emit something like Matcher::_regEncode[_ra->get_reg_second(node)]. This could be wrapped up in MachOper::reg_second. > - Similar to the one above for $mem, e.g. $mem$$Address$high, for long > memory accesses. Currently I'm using: > > ins_encode %{ > Address Amemlo = Address::make_raw($mem$$base, $mem$$index, $mem$ > $scale, $mem$$disp, false); > Address Amemhi = Address::make_raw($mem$$base, $mem$$index, $mem$ > $scale, $mem$$disp + 4, false); > __ movl($dst$$Register, Amemlo); > __ movl(HIGH_FROM_LOW($dst$$Register), Amemhi); > %} I think that would be ok. tom > > > I can try to add that functionality, but I wanted to ask if there is > already something like that? > > -- Christian > From Christian.Thalinger at Sun.COM Tue Mar 3 13:10:17 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 03 Mar 2009 22:10:17 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236103716.2239.105.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> Message-ID: <1236114617.2239.111.camel@localhost.localdomain> On Tue, 2009-03-03 at 19:08 +0100, Christian Thalinger wrote: > Yeah, I will do that. I will post a webrev later and open a new CR for > the Address changes on SPARC. Here is the second version: http://cr.openjdk.java.net/~twisti/6797305/webrev.01/ -- Christian From vladimir.kozlov at sun.com Tue Mar 3 14:08:21 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 03 Mar 2009 22:08:21 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 18 new changesets Message-ID: <20090303220856.0A8FEE6B8@hg.openjdk.java.net> Changeset: ba02d80fc550 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ba02d80fc550 Added tag jdk7-b46 for changeset 16bb38eeda35 ! .hgtags Changeset: fcb923bad68e Author: trims Date: 2009-02-10 20:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fcb923bad68e Merge Changeset: bcb33806d186 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bcb33806d186 Added tag jdk7-b47 for changeset fcb923bad68e ! .hgtags Changeset: 6b7f6a17455e Author: trims Date: 2009-02-18 18:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6b7f6a17455e Merge Changeset: 1605bb4eb5a7 Author: trims Date: 2009-02-18 18:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1605bb4eb5a7 6807345: Bump HS15 build number to 02 Summary: Update the HS15 Build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ef3b3df478b9 Author: trims Date: 2009-02-25 22:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ef3b3df478b9 Merge - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp Changeset: 69c752d99841 Author: ohair Date: 2009-01-31 17:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/69c752d99841 6799141: Build with --hash-style=both so that binaries can work on SuSE 10 Reviewed-by: tbell ! make/linux/makefiles/gcc.make Changeset: 01ddca3f0730 Author: jcoomes Date: 2009-02-09 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/01ddca3f0730 Merge Changeset: 3264b1424f72 Author: apangin Date: 2009-02-15 20:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3264b1424f72 Merge Changeset: a53107650e8b Author: apangin Date: 2009-02-22 17:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a53107650e8b Merge Changeset: 82e4d969e7cb Author: ikrylov Date: 2009-02-19 04:54 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/82e4d969e7cb 6806046: Hotspot build error when compiled from Visual Studio Summary: Define HOTSPOT_LIB_ARCH in the preprocessor flags of the generated projects Reviewed-by: kamg, xlu ! src/share/tools/MakeDeps/BuildConfig.java Changeset: 1b68c738c0d9 Author: apangin Date: 2009-02-22 17:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1b68c738c0d9 Merge Changeset: 7898caac2071 Author: apangin Date: 2009-02-26 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7898caac2071 Merge - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp Changeset: 3698e8f47799 Author: tonyp Date: 2009-02-24 15:50 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3698e8f47799 6804746: G1: guarantee(variance() > -1.0,"variance should be >= 0") (due to evacuation failure) Summary: Under certain circumstances (evacuation failure) the pause time is not communicated to the policy and, as a result, the pause time field is not initialized properly. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 83ef1482304c Author: jmasa Date: 2009-02-24 22:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/83ef1482304c 6806226: Signed integer overflow in growable array code causes JVM crash Summary: Workaround the overflow by doing the intermediate calculations in an unsigned variable. Reviewed-by: ysr, jcoomes ! src/share/vm/utilities/growableArray.cpp Changeset: 59150d6667e1 Author: jmasa Date: 2009-02-24 22:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/59150d6667e1 Merge Changeset: 1fa16c3565be Author: ysr Date: 2009-02-27 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1fa16c3565be Merge Changeset: d8c7fa77a6dc Author: kvn Date: 2009-03-03 10:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d8c7fa77a6dc Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp From John.Rose at Sun.COM Tue Mar 3 18:53:28 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 03 Mar 2009 18:53:28 -0800 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: <49AC893D.5080609@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> Message-ID: <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> On Mar 2, 2009, at 5:34 PM, Vladimir Kozlov wrote: > Since delayed_value implementation can be safely separated > from the rest of your changes can you push it separately? > Here is review for it. In general it is good. > > ------------------- > Why you did not put class RegisterConstant into src/share/vm/asm/ > assembler.hpp? > You can leave a comment where to look for it. Good suggestion; this avoids silly code duplication. I wanted to move up the definition of Register, which is the same text on all architectures, but was afraid to perturb other ports, just for one little change. This would be a good thing to roll into a Steve G. type of refactoring cleanup. > ------------------- > MacroAssembler::delayed_value() uses RegisterConstant constructors > implicitly. Can you change it to explicit usage? Good idea. Done. (Although I thought it was cute. But cute doesn't pay for obscure.) > ------------------- > assembler_x86.cpp/MacroAssembler::load_sized_value() > > And you asked Christian don't use high/low words :) : > > 6251 // For case 8, caller is responsible for manually loading > 6252 // the high word into another register. Heh. s/high/second/. Thanks. > Also why you are using movptr() in the corresponding part in > MethodHandles::generate_method_handle_stub() ?: > > 494 __ load_sized_value(rbx_temp, prim_value_addr, > 495 type2aelembytes(arg_type), > is_signed_subword_type(arg_type)); > 496 __ movptr(Address(rax_argslot, 0), rbx_temp); > 497 #ifndef _LP64 > 498 if (arg_slots == 2) { > 499 __ movl(rbx_temp, prim_value_addr.plus_disp(wordSize)); > 500 __ movptr(Address(rax_argslot, > Interpreter::stackElementSize()), rbx_temp); > 501 } > 502 #endif //_LP64 The movptr on line 500 looks better as movl; changed. The movptr on line 496 is needed because interpreter stack slots are wordSize not jintSize. Does that answer your concern? > And may be better use load_signed_short/load_unsigned_short names: > > 6261 case ~2: load_signed_word( dst, src ); break; > 6262 case 2: load_unsigned_word( dst, src ); break; You know what, I'm going to fix that now. It's just confusing, and somebody has already left a comment to that effect in the code. It was called "word" because that's how the Intel assembler manual talks about 16-bit values, as in "movswl". But the term "word" in an identifier like "load_signed_word" is way out of context; no other part of assembler_x86.hpp uses "word" to mean 16 bits, and the term means "machine word size 32/64 bits" everywhere else in HotSpot. > ------------------- > assembler.cpp: > > We talked about to comment why DC_LIMIT = 20. Those comments are in now. > ------------------- > assembler.hpp: > > I think, instead of "// Use sparingly" it may be better to explain > that is mostly used for java classes non-static field offsets > (currently only for MethodHandle) when we need to generated assembler > code before the class is loaded and field offsets are not known. > Also that is why the value can't be 0 since an object has markword > at 0 offset. > > 285 // The value zero (NULL) stands instead of a constant which is > still uncomputed. > 286 // Use sparingly. Done. > ------------------- > Why the next method does not return intptr_t* also? > > static address* delayed_value_addr(address(*constant_fn)()); No good reason; I made them the same, and it simplified the code. > ------------------- > The variable last_WrongMethodType_caller is declared but is not used: > src/cpu/sparc/vm/interpreter_sparc.cpp Fixed. > ------------------- > On x64 in 2 files in TemplateTable::prepare_invoke() > why you changed movptr(recv to movl(recv / movq(recv ? > Did you fix a problem? It should be separate bug in that case? Good catch. I think that's the residue from some search/replace experiments I was doing. I removed the change. > ------------------- Thanks! -- John From Vladimir.Kozlov at Sun.COM Tue Mar 3 19:07:32 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 03 Mar 2009 19:07:32 -0800 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> Message-ID: <49ADF074.6070804@sun.com> John Rose wrote: > >> Also why you are using movptr() in the corresponding part in >> MethodHandles::generate_method_handle_stub() ?: >> >> 494 __ load_sized_value(rbx_temp, prim_value_addr, >> 495 type2aelembytes(arg_type), >> is_signed_subword_type(arg_type)); >> 496 __ movptr(Address(rax_argslot, 0), rbx_temp); >> 497 #ifndef _LP64 >> 498 if (arg_slots == 2) { >> 499 __ movl(rbx_temp, prim_value_addr.plus_disp(wordSize)); >> 500 __ movptr(Address(rax_argslot, >> Interpreter::stackElementSize()), rbx_temp); >> 501 } >> 502 #endif //_LP64 > > The movptr on line 500 looks better as movl; changed. > The movptr on line 496 is needed because interpreter stack slots are > wordSize not jintSize. > Does that answer your concern? Leave this code as it was. I was mistaking it for movoop. Thanks, Vladimir From vladimir.kozlov at sun.com Tue Mar 3 20:56:08 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 04 Mar 2009 04:56:08 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6812721: Block's frequency should not be NaN Message-ID: <20090304045610.45353E731@hg.openjdk.java.net> Changeset: 19f25e603e7b Author: kvn Date: 2009-03-03 18:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/19f25e603e7b 6812721: Block's frequency should not be NaN Summary: Set MIN_BLOCK_FREQUENCY block's frequency when calculated block's frequency is NaN Reviewed-by: never ! src/share/vm/opto/gcm.cpp From dawn2004 at gmail.com Wed Mar 4 10:40:14 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Wed, 4 Mar 2009 10:40:14 -0800 (PST) Subject: How to use cppInterpreter in Hotspot? In-Reply-To: <1235485672.11128.189.camel@localhost.localdomain> References: <22170486.post@talk.nabble.com> <1235436865.7493.5.camel@phillimores> <22175514.post@talk.nabble.com> <1235485672.11128.189.camel@localhost.localdomain> Message-ID: <22336444.post@talk.nabble.com> Hello, When I added CC_INTERP=1 as make option. I got following error : Linking vm... { \ echo Linking launcher...; \ \ gcc -m32 -march=i586 -Xlinker -O1 -m32 -march=i586 -export-dynamic -L `pwd` -o gamma launcher.o -ljvm -lm -ldl -lpthread; \ \ } Linking launcher... /home/dli/Hotspot/openjdk_b24/jdk7/build/openjdk7_full_debug/linux_i486_compiler2/jvmg/libjvm.so: undefined reference to `frame::set_interpreter_frame_sender_sp(int*)' /home/dli/Hotspot/openjdk_b24/jdk7/build/openjdk7_full_debug/linux_i486_compiler2/jvmg/libjvm.so: undefined reference to `methodOopDesc::set_result_index(BasicType)' /home/dli/Hotspot/openjdk_b24/jdk7/build/openjdk7_full_debug/linux_i486_compiler2/jvmg/libjvm.so: undefined reference to `frame::interpreter_frame_set_last_sp(int*)' /home/dli/Hotspot/openjdk_b24/jdk7/build/openjdk7_full_debug/linux_i486_compiler2/jvmg/libjvm.so: undefined reference to `frame::interpreter_frame_set_monitor_end(BasicObjectLock*)' /home/dli/Hotspot/openjdk_b24/jdk7/build/openjdk7_full_debug/linux_i486_compiler2/jvmg/libjvm.so: undefined reference to `CppInterpreter::contains(unsigned char*)' collect2: ld returned 1 exit status How can I fix it? Thanks a lot! Christian Thalinger-3 wrote: > > On Mon, 2009-02-23 at 20:12 -0800, Colin(Du Li) wrote: >> Hi, >> >> Thank you for your reply! >> I still have some questions. >> 1. Can c++ interpreter be used in product version? >> 2. Can c++ interpreter be used in 64 bit machine with Linux OS. > > Both answers should be yes. I don't see a reason why it shouldn't work. > Have you tried it? > > -- Christian > > > -- View this message in context: http://www.nabble.com/How-to-use-cppInterpreter-in-Hotspot--tp22170486p22336444.html Sent from the OpenJDK Hotspot Compiler Development List mailing list archive at Nabble.com. From Christian.Thalinger at Sun.COM Wed Mar 4 10:53:27 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 04 Mar 2009 19:53:27 +0100 Subject: How to use cppInterpreter in Hotspot? In-Reply-To: <22336444.post@talk.nabble.com> References: <22170486.post@talk.nabble.com> <1235436865.7493.5.camel@phillimores> <22175514.post@talk.nabble.com> <1235485672.11128.189.camel@localhost.localdomain> <22336444.post@talk.nabble.com> Message-ID: <1236192807.2239.170.camel@localhost.localdomain> On Wed, 2009-03-04 at 10:40 -0800, Colin(Du Li) wrote: > How can I fix it? I recently tried to build the C++ interpreter and it worked. You should try a more recent build than b24. If that fails too, please file a bug report. -- Christian From john.rose at sun.com Thu Mar 5 06:50:50 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Thu, 05 Mar 2009 14:50:50 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6812678: macro assembler needs delayed binding of a few constants (for 6655638) Message-ID: <20090305145052.9872BE7F4@hg.openjdk.java.net> Changeset: 56aae7be60d4 Author: jrose Date: 2009-03-04 09:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/56aae7be60d4 6812678: macro assembler needs delayed binding of a few constants (for 6655638) Summary: minor assembler enhancements preparing for method handles Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp From John.Rose at Sun.COM Thu Mar 5 17:54:04 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 05 Mar 2009 17:54:04 -0800 Subject: for review (M): 6812831 factor megamorphic invokeinterface (for 6655638) In-Reply-To: <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> Message-ID: <3E9D1DE4-B24C-4CF0-9D33-42B1F235D780@sun.com> In response to a review request (thanks, Vladimir!) I've split the refactoring of the itable lookup logic into a separate change request. Here it is; please (re-)review: http://cr.openjdk.java.net/~jrose/6812831/webrev It is a little different from the corresponding changes in the mega- review. I cleaned it up slightly, so that the interface search loop is tighter. (Should fit on an I$ line now.) I also make it work on x86 (32 and 64) and SPARC. -- John From John.Rose at Sun.COM Thu Mar 5 17:54:44 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 05 Mar 2009 17:54:44 -0800 Subject: Fwd: for review (M): 6812831 factor megamorphic invokeinterface (for 6655638) References: <55969927-E427-4C29-979B-6DE38F04E168@me.com> Message-ID: <87678A7A-CEA3-43A4-B8FA-C66CC1360C44@sun.com> I'm pushing method handles changes to JDK7 these days. Here's the first: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/56aae7be60d4 The next one is imminent; see review request below. This one refactors interface dispatching, so I don't need to write yet another copy of the same assembly code for method handles. The following one will refactor the assembly code generation of subtype checking logic (used in checkcast, instanceof, aastore, Class.isInstance, etc.). If you want to follow this activity, you may want to lurk on hotspot-compiler-dev at openjdk.java.net (CC-ed). Both of the latter changes should help with interface injection prototyping. (Hi, Tobias :-) -- John Begin forwarded message: From: John Rose Date: March 5, 2009 5:54:04 PM PST To: hotspot compiler Subject: for review (M): 6812831 factor megamorphic invokeinterface (for 6655638) In response to a review request (thanks, Vladimir!) I've split the refactoring of the itable lookup logic into a separate change request. Here it is; please (re-)review: http://cr.openjdk.java.net/~jrose/6812831/webrev It is a little different from the corresponding changes in the mega- review. I cleaned it up slightly, so that the interface search loop is tighter. (Should fit on an I$ line now.) I also make it work on x86 (32 and 64) and SPARC. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090305/44e8f25c/attachment.html From John.Rose at Sun.COM Thu Mar 5 21:06:42 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 05 Mar 2009 21:06:42 -0800 Subject: for review (M): 6812831 factor general subclass check (for 6655638) In-Reply-To: <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> Message-ID: Here is another review request similar to the previous: http://cr.openjdk.java.net/~jrose/6813212/webrev.00 It moves assembly code for subtyping from about 20 places in the source base to two places, one for sparc and one for x86. I will update this webrev after I clean out the subtype assembly code from the *.ad files. While doing this work, I encountered two or three small bugs in the assembly code, probably due to the fact that it was so hard to read and understand all 20 variations: 1. 32-bit instead of 64-bit comparison of pointers in C1 subtype code (c1_LIRAssembler_sparc.cpp). 2. Compare against wrong register in sparc stub generator (stubGenerator_sparc.cpp at cmp(super_klass, sc_offset)). 3. Wrong variable names in C1 slow-path code: subclass and superclass were swapped (c1_Runtime1_x86.cpp). None of these are very harmful, or we would have fixed them already. I think we know about number 1; it makes it hard to port C1 to LP64. Number 2 would make System.arraycopy wrongly throw a CCE if the target array element type is a secondary supertype and is *not* already cached on the element subtypes. I think I'll have to break this one out as a separate fix, so it can be backported. -- John From Thomas.Rodriguez at Sun.COM Thu Mar 5 22:36:35 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 05 Mar 2009 22:36:35 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236114617.2239.111.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> Message-ID: <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> Looks good to me. tom On Mar 3, 2009, at 1:10 PM, Christian Thalinger wrote: > On Tue, 2009-03-03 at 19:08 +0100, Christian Thalinger wrote: >> Yeah, I will do that. I will post a webrev later and open a new CR >> for >> the Address changes on SPARC. > > Here is the second version: > > http://cr.openjdk.java.net/~twisti/6797305/webrev.01/ > > -- Christian > From john.coomes at sun.com Fri Mar 6 00:22:09 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Mar 2009 08:22:09 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b50 for changeset 5111e13e44e5 Message-ID: <20090306082209.436EAE8B3@hg.openjdk.java.net> Changeset: 28ba432554f4 Author: xdono Date: 2009-03-05 09:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/28ba432554f4 Added tag jdk7-b50 for changeset 5111e13e44e5 ! .hgtags From john.coomes at sun.com Fri Mar 6 00:26:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Mar 2009 08:26:21 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b50 for changeset 0edbd0074b02 Message-ID: <20090306082623.48F43E8B8@hg.openjdk.java.net> Changeset: 12f178e7737f Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/12f178e7737f Added tag jdk7-b50 for changeset 0edbd0074b02 ! .hgtags From john.coomes at sun.com Fri Mar 6 00:33:41 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Mar 2009 08:33:41 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b50 for changeset e8514e2be76d Message-ID: <20090306083342.D07F9E8BD@hg.openjdk.java.net> Changeset: e2da22440463 Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/e2da22440463 Added tag jdk7-b50 for changeset e8514e2be76d ! .hgtags From john.coomes at sun.com Fri Mar 6 00:37:59 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Mar 2009 08:37:59 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b50 for changeset 5be52db581f1 Message-ID: <20090306083800.E89ADE8C2@hg.openjdk.java.net> Changeset: 3f309316d6bf Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/3f309316d6bf Added tag jdk7-b50 for changeset 5be52db581f1 ! .hgtags From Vladimir.Kozlov at Sun.COM Fri Mar 6 00:45:49 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 06 Mar 2009 00:45:49 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> Message-ID: <49B0E2BD.3090209@sun.com> Looks good. In x86_32.ad in loadB2L you need only 7 bits shift: SAR dst.hi, 7 and in loadS2L only 15 bits. Vladimir Tom Rodriguez wrote: > Looks good to me. > > tom > > On Mar 3, 2009, at 1:10 PM, Christian Thalinger wrote: > >> On Tue, 2009-03-03 at 19:08 +0100, Christian Thalinger wrote: >>> Yeah, I will do that. I will post a webrev later and open a new CR for >>> the Address changes on SPARC. >> >> Here is the second version: >> >> http://cr.openjdk.java.net/~twisti/6797305/webrev.01/ >> >> -- Christian >> > From john.coomes at sun.com Fri Mar 6 00:42:39 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Mar 2009 08:42:39 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 23 new changesets Message-ID: <20090306084726.EAE2DE8C7@hg.openjdk.java.net> Changeset: 40ce81649cd6 Author: poonam Date: 2009-02-10 03:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/40ce81649cd6 6755621: Include SA binaries into Windows JDK Summary: These changes will enable inclusion of sa-jdi.jar and sawindbg.dll into Windows JDK bundle. Reviewed-by: never, jjh, alanb ! make/common/Defs-windows.gmk Changeset: 043dfafc41a5 Author: chegar Date: 2009-02-11 13:16 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/043dfafc41a5 6799040: Portability issues in src/solaris/native/java/net/Inet4AddressImpl.c Reviewed-by: alanb Contributed-by: christos at zoulas.com ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: f06f30b29f36 Author: alanb Date: 2009-02-15 12:25 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f06f30b29f36 6781363: New I/O: Update socket-channel API to jsr203/nio2-b99 4313887: New I/O: Improved filesystem interface 4607272: New I/O: Support asynchronous I/O Reviewed-by: sherman, chegar ! make/docs/CORE_PKGS.gmk ! make/docs/NON_CORE_PKGS.gmk ! make/java/nio/Exportedfiles.gmk ! make/java/nio/FILES_c.gmk ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! make/mksample/nio/Makefile + make/mksample/nio/file/Makefile + src/share/classes/com/sun/nio/file/ExtendedCopyOption.java + src/share/classes/com/sun/nio/file/ExtendedOpenOption.java + src/share/classes/com/sun/nio/file/ExtendedWatchEventModifier.java + src/share/classes/com/sun/nio/file/SensitivityWatchEventModifier.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/net/StandardProtocolFamily.java ! src/share/classes/java/net/StandardSocketOption.java + src/share/classes/java/nio/channels/AsynchronousByteChannel.java + src/share/classes/java/nio/channels/AsynchronousChannel.java + src/share/classes/java/nio/channels/AsynchronousChannelGroup.java + src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java + src/share/classes/java/nio/channels/AsynchronousFileChannel.java + src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java + src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/Channels.java + src/share/classes/java/nio/channels/CompletionHandler.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/MembershipKey.java ! src/share/classes/java/nio/channels/MulticastChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java + src/share/classes/java/nio/channels/SeekableByteChannel.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/channels/exceptions ! src/share/classes/java/nio/channels/package-info.java + src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java ! src/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/share/classes/java/nio/channels/spi/package.html + src/share/classes/java/nio/file/AccessDeniedException.java + src/share/classes/java/nio/file/AccessMode.java + src/share/classes/java/nio/file/AtomicMoveNotSupportedException.java + src/share/classes/java/nio/file/ClosedDirectoryStreamException.java + src/share/classes/java/nio/file/ClosedFileSystemException.java + src/share/classes/java/nio/file/ClosedWatchServiceException.java + src/share/classes/java/nio/file/CopyOption.java + src/share/classes/java/nio/file/DirectoryNotEmptyException.java + src/share/classes/java/nio/file/DirectoryStream.java + src/share/classes/java/nio/file/DirectoryStreamFilters.java + src/share/classes/java/nio/file/FileAction.java + src/share/classes/java/nio/file/FileAlreadyExistsException.java + src/share/classes/java/nio/file/FileRef.java + src/share/classes/java/nio/file/FileStore.java + src/share/classes/java/nio/file/FileSystem.java + src/share/classes/java/nio/file/FileSystemAlreadyExistsException.java + src/share/classes/java/nio/file/FileSystemException.java + src/share/classes/java/nio/file/FileSystemNotFoundException.java + src/share/classes/java/nio/file/FileSystems.java + src/share/classes/java/nio/file/FileTreeWalker.java + src/share/classes/java/nio/file/FileVisitOption.java + src/share/classes/java/nio/file/FileVisitResult.java + src/share/classes/java/nio/file/FileVisitor.java + src/share/classes/java/nio/file/Files.java + src/share/classes/java/nio/file/InvalidPathException.java + src/share/classes/java/nio/file/LinkOption.java + src/share/classes/java/nio/file/LinkPermission.java + src/share/classes/java/nio/file/NoSuchFileException.java + src/share/classes/java/nio/file/NotDirectoryException.java + src/share/classes/java/nio/file/NotLinkException.java + src/share/classes/java/nio/file/OpenOption.java + src/share/classes/java/nio/file/Path.java + src/share/classes/java/nio/file/PathMatcher.java + src/share/classes/java/nio/file/Paths.java + src/share/classes/java/nio/file/ProviderMismatchException.java + src/share/classes/java/nio/file/ProviderNotFoundException.java + src/share/classes/java/nio/file/ReadOnlyFileSystemException.java + src/share/classes/java/nio/file/SecureDirectoryStream.java + src/share/classes/java/nio/file/SimpleFileVisitor.java + src/share/classes/java/nio/file/StandardCopyOption.java + src/share/classes/java/nio/file/StandardOpenOption.java + src/share/classes/java/nio/file/StandardWatchEventKind.java + src/share/classes/java/nio/file/WatchEvent.java + src/share/classes/java/nio/file/WatchKey.java + src/share/classes/java/nio/file/WatchService.java + src/share/classes/java/nio/file/Watchable.java + src/share/classes/java/nio/file/attribute/AclEntry.java + src/share/classes/java/nio/file/attribute/AclEntryFlag.java + src/share/classes/java/nio/file/attribute/AclEntryPermission.java + src/share/classes/java/nio/file/attribute/AclEntryType.java + src/share/classes/java/nio/file/attribute/AclFileAttributeView.java + src/share/classes/java/nio/file/attribute/AttributeView.java + src/share/classes/java/nio/file/attribute/Attributes.java + src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java + src/share/classes/java/nio/file/attribute/BasicFileAttributes.java + src/share/classes/java/nio/file/attribute/DosFileAttributeView.java + src/share/classes/java/nio/file/attribute/DosFileAttributes.java + src/share/classes/java/nio/file/attribute/FileAttribute.java + src/share/classes/java/nio/file/attribute/FileAttributeView.java + src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java + src/share/classes/java/nio/file/attribute/FileStoreAttributeView.java + src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java + src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java + src/share/classes/java/nio/file/attribute/GroupPrincipal.java + src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java + src/share/classes/java/nio/file/attribute/PosixFileAttributes.java + src/share/classes/java/nio/file/attribute/PosixFilePermission.java + src/share/classes/java/nio/file/attribute/PosixFilePermissions.java + src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java + src/share/classes/java/nio/file/attribute/UserPrincipal.java + src/share/classes/java/nio/file/attribute/UserPrincipalLookupService.java + src/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java + src/share/classes/java/nio/file/attribute/package-info.java + src/share/classes/java/nio/file/package-info.java + src/share/classes/java/nio/file/spi/AbstractPath.java + src/share/classes/java/nio/file/spi/FileSystemProvider.java + src/share/classes/java/nio/file/spi/FileTypeDetector.java + src/share/classes/java/nio/file/spi/package-info.java ! src/share/classes/java/util/Scanner.java + src/share/classes/sun/nio/ch/AbstractFuture.java + src/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java + src/share/classes/sun/nio/ch/AsynchronousFileChannelImpl.java + src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java + src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java + src/share/classes/sun/nio/ch/Cancellable.java + src/share/classes/sun/nio/ch/CompletedFuture.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/ExtendedSocketOption.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java + src/share/classes/sun/nio/ch/FileDispatcher.java ! src/share/classes/sun/nio/ch/FileLockImpl.java + src/share/classes/sun/nio/ch/FileLockTable.java + src/share/classes/sun/nio/ch/Groupable.java ! src/share/classes/sun/nio/ch/IOUtil.java + src/share/classes/sun/nio/ch/Invoker.java ! src/share/classes/sun/nio/ch/MembershipKeyImpl.java ! src/share/classes/sun/nio/ch/MembershipRegistry.java ! src/share/classes/sun/nio/ch/NativeThreadSet.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/OptionKey.java + src/share/classes/sun/nio/ch/PendingFuture.java ! src/share/classes/sun/nio/ch/Reflect.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java + src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java + src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java + src/share/classes/sun/nio/ch/ThreadPool.java ! src/share/classes/sun/nio/ch/Util.java + src/share/classes/sun/nio/fs/AbstractAclFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractBasicFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java + src/share/classes/sun/nio/fs/AbstractFileTypeDetector.java + src/share/classes/sun/nio/fs/AbstractPoller.java + src/share/classes/sun/nio/fs/AbstractUserDefinedFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractWatchKey.java + src/share/classes/sun/nio/fs/AbstractWatchService.java + src/share/classes/sun/nio/fs/Cancellable.java + src/share/classes/sun/nio/fs/FileOwnerAttributeViewImpl.java + src/share/classes/sun/nio/fs/Globs.java + src/share/classes/sun/nio/fs/MimeType.java + src/share/classes/sun/nio/fs/NativeBuffer.java + src/share/classes/sun/nio/fs/NativeBuffers.java + src/share/classes/sun/nio/fs/PollingWatchService.java + src/share/classes/sun/nio/fs/Reflect.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/native/sun/nio/ch/genSocketOptionRegistry.c + src/share/sample/nio/file/AclEdit.java + src/share/sample/nio/file/Chmod.java + src/share/sample/nio/file/Copy.java + src/share/sample/nio/file/DiskUsage.java + src/share/sample/nio/file/FileType.java + src/share/sample/nio/file/WatchDir.java + src/share/sample/nio/file/Xdd.java ! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java + src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java + src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java + src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java - src/solaris/classes/sun/nio/ch/FileDispatcher.java + src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java + src/solaris/classes/sun/nio/ch/LinuxAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/PollSelectorImpl.java + src/solaris/classes/sun/nio/ch/Port.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SocketDispatcher.java + src/solaris/classes/sun/nio/ch/SolarisAsynchronousChannelProvider.java + src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java + src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java + src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java + src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java + src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java + src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java + src/solaris/classes/sun/nio/fs/LinuxFileStore.java + src/solaris/classes/sun/nio/fs/LinuxFileSystem.java + src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java + src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java + src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java + src/solaris/classes/sun/nio/fs/LinuxWatchService.java + src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java + src/solaris/classes/sun/nio/fs/SolarisFileStore.java + src/solaris/classes/sun/nio/fs/SolarisFileSystem.java + src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java + src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java + src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java + src/solaris/classes/sun/nio/fs/SolarisWatchService.java + src/solaris/classes/sun/nio/fs/UnixChannelFactory.java + src/solaris/classes/sun/nio/fs/UnixCopyFile.java + src/solaris/classes/sun/nio/fs/UnixDirectoryStream.java + src/solaris/classes/sun/nio/fs/UnixException.java + src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java + src/solaris/classes/sun/nio/fs/UnixFileAttributes.java + src/solaris/classes/sun/nio/fs/UnixFileKey.java + src/solaris/classes/sun/nio/fs/UnixFileModeAttribute.java + src/solaris/classes/sun/nio/fs/UnixFileStore.java + src/solaris/classes/sun/nio/fs/UnixFileStoreAttributes.java + src/solaris/classes/sun/nio/fs/UnixFileSystem.java + src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java + src/solaris/classes/sun/nio/fs/UnixMountEntry.java + src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java + src/solaris/classes/sun/nio/fs/UnixPath.java + src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java + src/solaris/classes/sun/nio/fs/UnixUriUtils.java + src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java + src/solaris/native/sun/nio/ch/EPoll.c + src/solaris/native/sun/nio/ch/EPollPort.c ! src/solaris/native/sun/nio/ch/FileChannelImpl.c - src/solaris/native/sun/nio/ch/FileDispatcher.c + src/solaris/native/sun/nio/ch/FileDispatcherImpl.c ! src/solaris/native/sun/nio/ch/SocketDispatcher.c + src/solaris/native/sun/nio/ch/SolarisEventPort.c + src/solaris/native/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.c + src/solaris/native/sun/nio/ch/UnixAsynchronousSocketChannelImpl.c + src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c + src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c + src/solaris/native/sun/nio/fs/LinuxWatchService.c + src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c + src/solaris/native/sun/nio/fs/SolarisWatchService.c + src/solaris/native/sun/nio/fs/UnixCopyFile.c + src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c + src/solaris/native/sun/nio/fs/genSolarisConstants.c + src/solaris/native/sun/nio/fs/genUnixConstants.c + src/windows/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java - src/windows/classes/sun/nio/ch/FileDispatcher.java + src/windows/classes/sun/nio/ch/FileDispatcherImpl.java + src/windows/classes/sun/nio/ch/Iocp.java + src/windows/classes/sun/nio/ch/PendingIoCache.java + src/windows/classes/sun/nio/ch/WindowsAsynchronousChannelProvider.java + src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java + src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java + src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java + src/windows/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/windows/classes/sun/nio/fs/DefaultFileTypeDetector.java + src/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java + src/windows/classes/sun/nio/fs/WindowsAclFileAttributeView.java + src/windows/classes/sun/nio/fs/WindowsChannelFactory.java + src/windows/classes/sun/nio/fs/WindowsConstants.java + src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java + src/windows/classes/sun/nio/fs/WindowsException.java + src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java + src/windows/classes/sun/nio/fs/WindowsFileAttributes.java + src/windows/classes/sun/nio/fs/WindowsFileCopy.java + src/windows/classes/sun/nio/fs/WindowsFileStore.java + src/windows/classes/sun/nio/fs/WindowsFileSystem.java + src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java + src/windows/classes/sun/nio/fs/WindowsLinkSupport.java + src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java + src/windows/classes/sun/nio/fs/WindowsPath.java + src/windows/classes/sun/nio/fs/WindowsPathParser.java + src/windows/classes/sun/nio/fs/WindowsPathType.java + src/windows/classes/sun/nio/fs/WindowsSecurity.java + src/windows/classes/sun/nio/fs/WindowsSecurityDescriptor.java + src/windows/classes/sun/nio/fs/WindowsUriSupport.java + src/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java + src/windows/classes/sun/nio/fs/WindowsUserPrincipals.java + src/windows/classes/sun/nio/fs/WindowsWatchService.java ! src/windows/native/sun/nio/ch/FileChannelImpl.c - src/windows/native/sun/nio/ch/FileDispatcher.c + src/windows/native/sun/nio/ch/FileDispatcherImpl.c + src/windows/native/sun/nio/ch/Iocp.c + src/windows/native/sun/nio/ch/WindowsAsynchronousFileChannelImpl.c + src/windows/native/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.c + src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c + src/windows/native/sun/nio/fs/RegistryFileTypeDetector.c + src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c + test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java + test/java/nio/channels/AsynchronousChannelGroup/Attack.java + test/java/nio/channels/AsynchronousChannelGroup/BadProperties.java + test/java/nio/channels/AsynchronousChannelGroup/Basic.java + test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java + test/java/nio/channels/AsynchronousChannelGroup/Identity.java + test/java/nio/channels/AsynchronousChannelGroup/PrivilegedThreadFactory.java + test/java/nio/channels/AsynchronousChannelGroup/Restart.java + test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java + test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh + test/java/nio/channels/AsynchronousDatagramChannel/Basic.java + test/java/nio/channels/AsynchronousFileChannel/Basic.java + test/java/nio/channels/AsynchronousFileChannel/CustomThreadPool.java + test/java/nio/channels/AsynchronousFileChannel/Lock.java + test/java/nio/channels/AsynchronousFileChannel/MyThreadFactory.java + test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java + test/java/nio/channels/AsynchronousServerSocketChannel/WithSecurityManager.java + test/java/nio/channels/AsynchronousServerSocketChannel/java.policy.allow + test/java/nio/channels/AsynchronousServerSocketChannel/java.policy.deny + test/java/nio/channels/AsynchronousSocketChannel/Basic.java + test/java/nio/channels/AsynchronousSocketChannel/Leaky.java + test/java/nio/channels/Channels/Basic2.java ! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java ! test/java/nio/channels/etc/NetworkChannelTests.java + test/java/nio/channels/spi/AsynchronousChannelProvider/CheckProvider.java + test/java/nio/channels/spi/AsynchronousChannelProvider/META-INF/services/java.nio.channels.spi.AsynchronousChannelProvider + test/java/nio/channels/spi/AsynchronousChannelProvider/Provider1.java + test/java/nio/channels/spi/AsynchronousChannelProvider/Provider2.java + test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh + test/java/nio/file/DirectoryStream/Basic.java + test/java/nio/file/DirectoryStream/Filters.java + test/java/nio/file/DirectoryStream/SecureDS.java + test/java/nio/file/FileStore/Basic.java + test/java/nio/file/FileSystem/Basic.java + test/java/nio/file/Files/ContentType.java + test/java/nio/file/Files/CreateFileTree.java + test/java/nio/file/Files/ForceLoad.java + test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector + test/java/nio/file/Files/Misc.java + test/java/nio/file/Files/PrintFileTree.java + test/java/nio/file/Files/SimpleFileTypeDetector.java + test/java/nio/file/Files/SkipSiblings.java + test/java/nio/file/Files/TerminateWalk.java + test/java/nio/file/Files/content_type.sh + test/java/nio/file/Files/walk_file_tree.sh + test/java/nio/file/Path/CopyAndMove.java + test/java/nio/file/Path/DeleteOnClose.java + test/java/nio/file/Path/InterruptCopy.java + test/java/nio/file/Path/Links.java + test/java/nio/file/Path/Misc.java + test/java/nio/file/Path/PathOps.java + test/java/nio/file/Path/SBC.java + test/java/nio/file/Path/TemporaryFiles.java + test/java/nio/file/Path/UriImportExport.java + test/java/nio/file/Path/delete_on_close.sh + test/java/nio/file/Path/temporary_files.sh + test/java/nio/file/PathMatcher/Basic.java + test/java/nio/file/TestUtil.java + test/java/nio/file/WatchService/Basic.java + test/java/nio/file/WatchService/FileTreeModifier.java + test/java/nio/file/WatchService/SensitivityModifier.java + test/java/nio/file/WatchService/WithSecurityManager.java + test/java/nio/file/WatchService/denyAll.policy + test/java/nio/file/WatchService/grantDirAndOneLevel.policy + test/java/nio/file/WatchService/grantDirAndTree.policy + test/java/nio/file/WatchService/grantDirOnly.policy + test/java/nio/file/attribute/AclFileAttributeView/Basic.java + test/java/nio/file/attribute/Attributes/Basic.java + test/java/nio/file/attribute/BasicFileAttributeView/Basic.java + test/java/nio/file/attribute/DosFileAttributeView/Basic.java + test/java/nio/file/attribute/FileStoreAttributeView/Basic.java + test/java/nio/file/attribute/PosixFileAttributeView/Basic.java + test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java + test/java/nio/file/spi/SetDefaultProvider.java + test/java/nio/file/spi/TestProvider.java Changeset: f8a9a7aff362 Author: chegar Date: 2009-02-16 17:19 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f8a9a7aff362 6800805: java.net.NetworkInterface.getNetworkInterfaces() does not list IPv6 network interfaces correctly Reviewed-by: jccollet ! src/solaris/native/java/net/NetworkInterface.c Changeset: 1109646be6f6 Author: tbell Date: 2009-02-19 18:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1109646be6f6 Merge - src/solaris/classes/sun/nio/ch/FileDispatcher.java - src/solaris/native/sun/nio/ch/FileDispatcher.c - src/windows/classes/sun/nio/ch/FileDispatcher.java - src/windows/native/sun/nio/ch/FileDispatcher.c Changeset: a144afafb6fe Author: xuelei Date: 2009-02-20 12:50 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a144afafb6fe 4918870: Examine session cache implementation (sun.misc.Cache) Summary: replace sun.misc.Cache with sun.security.util.Cache Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/util/Cache.java Changeset: 6bdbb2f5c763 Author: xuelei Date: 2009-02-20 13:05 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6bdbb2f5c763 6697270: Inputstream dosent behave correct Summary: do not try to read zero byte from a InputStream, and do always return immediately for zero byte reading in a InputStream implementation. Reviewed-by: weijun ! src/share/classes/sun/security/ssl/AppInputStream.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/ByteBufferInputStream.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java Changeset: 7443278199cb Author: tbell Date: 2009-02-20 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7443278199cb Merge Changeset: 9b1bc2e28518 Author: weijun Date: 2009-02-23 10:03 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9b1bc2e28518 6535697: keytool can be more flexible on format of PEM-encoded X.509 certificates Reviewed-by: vinnie ! src/share/classes/sun/security/provider/X509Factory.java ! test/java/security/cert/CertificateFactory/BadX509CertData.java + test/java/security/cert/CertificateFactory/openssl/OpenSSLCert.java + test/java/security/cert/CertificateFactory/openssl/open + test/java/security/cert/CertificateFactory/openssl/pem Changeset: 33bc32405045 Author: weijun Date: 2009-02-23 10:04 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/33bc32405045 6789935: cross-realm capath search error Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Realm.java + test/sun/security/krb5/ParseCAPaths.java + test/sun/security/krb5/krb5-capaths.conf Changeset: ec98d5f9b338 Author: weijun Date: 2009-02-23 10:04 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ec98d5f9b338 6804045: DerValue does not accept empty OCTET STRING Reviewed-by: xuelei ! src/share/classes/sun/security/util/DerValue.java + test/sun/security/util/DerValue/EmptyValue.java Changeset: 8edcd68fb6ac Author: weijun Date: 2009-02-23 10:05 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8edcd68fb6ac 6803376: BasicConstraintsExtension does not encode when (ca==false && pathLen<0) Reviewed-by: xuelei ! src/share/classes/sun/security/x509/BasicConstraintsExtension.java + test/sun/security/x509/Extensions/BCNull.java Changeset: 90ab7b4891e3 Author: weijun Date: 2009-02-23 10:05 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/90ab7b4891e3 6780416: New keytool commands/options: -gencert, -printcertreq, -ext Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java ! src/share/classes/sun/security/x509/AccessDescription.java ! src/share/classes/sun/security/x509/AuthorityInfoAccessExtension.java ! src/share/classes/sun/security/x509/AuthorityKeyIdentifierExtension.java ! src/share/classes/sun/security/x509/CertAndKeyGen.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/IssuerAlternativeNameExtension.java ! src/share/classes/sun/security/x509/OIDMap.java + src/share/classes/sun/security/x509/SubjectInfoAccessExtension.java ! test/sun/security/tools/keytool/KeyToolTest.java ! test/sun/security/tools/keytool/autotest.sh + test/sun/security/tools/keytool/standard.sh Changeset: 2a7c1a997102 Author: xuelei Date: 2009-02-23 17:32 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2a7c1a997102 5067458: Loopback SSLSocketImpl createSocket is throwing an exception Summary: A null hostname should be regarded as a loopback address. Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLSocketImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/LoopbackSSLSocket.java Changeset: 0f4497002345 Author: chegar Date: 2009-02-23 10:36 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0f4497002345 6806649: synchronization bottleneck when constructing Thread subclasses Summary: Replace subclass audits synchronization with ConcurrentHashMap with weakly referenced Class keys Reviewed-by: peterjones, dholmes, martin ! src/share/classes/java/lang/Thread.java Changeset: 27e1141d436c Author: sherman Date: 2009-02-23 21:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/27e1141d436c 6350801: Add support for named (instead of numbered) capture groups in regular expression 6676425: Opensource unit/regression tests for java.util.regex Summary: Added "named capturing group" into regex. Moved most of reg/unit tests to openjdk. Reviewed-by: alanb, okutsu ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java + test/java/util/regex/BMPTestCases.txt + test/java/util/regex/RegExTest.java + test/java/util/regex/SupplementaryTestCases.txt + test/java/util/regex/TestCases.txt Changeset: 910f9cceb0f8 Author: alanb Date: 2009-02-24 09:11 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/910f9cceb0f8 6808647: (file) Paths.get("C:").newDirectoryStream() iterates over Path elements with additional slash [win] 6808648: (file) Files.walkFileTree should obtain file attributes during iteration [win] Reviewed-by: sherman ! make/java/nio/FILES_java.gmk ! src/share/classes/java/nio/file/FileTreeWalker.java + src/share/classes/sun/nio/fs/BasicFileAttributesHolder.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c + test/java/nio/file/DirectoryStream/DriveLetter.java Changeset: c7f39995fcf4 Author: alanb Date: 2009-02-24 11:31 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c7f39995fcf4 6809132: (file) Javadoc style and consistency issues Reviewed-by: vinnie Contributed-by: cquinn at google.com ! src/share/classes/java/nio/file/AccessDeniedException.java ! src/share/classes/java/nio/file/AtomicMoveNotSupportedException.java ! src/share/classes/java/nio/file/DirectoryNotEmptyException.java ! src/share/classes/java/nio/file/DirectoryStream.java ! src/share/classes/java/nio/file/DirectoryStreamFilters.java ! src/share/classes/java/nio/file/FileAction.java ! src/share/classes/java/nio/file/FileAlreadyExistsException.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileSystemAlreadyExistsException.java ! src/share/classes/java/nio/file/FileSystemException.java ! src/share/classes/java/nio/file/FileSystemNotFoundException.java ! src/share/classes/java/nio/file/FileSystems.java ! src/share/classes/java/nio/file/FileVisitor.java ! src/share/classes/java/nio/file/InvalidPathException.java ! src/share/classes/java/nio/file/LinkPermission.java ! src/share/classes/java/nio/file/NoSuchFileException.java ! src/share/classes/java/nio/file/NotDirectoryException.java ! src/share/classes/java/nio/file/NotLinkException.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/PathMatcher.java ! src/share/classes/java/nio/file/Paths.java ! src/share/classes/java/nio/file/ProviderMismatchException.java ! src/share/classes/java/nio/file/ProviderNotFoundException.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchKey.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/Watchable.java ! src/share/classes/java/nio/file/attribute/AclEntry.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/AttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/DosFileAttributes.java ! src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributes.java ! src/share/classes/java/nio/file/attribute/PosixFilePermissions.java ! src/share/classes/java/nio/file/attribute/UserPrincipalLookupService.java ! src/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java ! src/share/classes/java/nio/file/package-info.java Changeset: abe5e7125bd3 Author: alanb Date: 2009-02-24 11:33 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/abe5e7125bd3 Merge Changeset: dc237aecf7cf Author: kevinw Date: 2009-02-24 14:22 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dc237aecf7cf 6599383: Unable to open zip files more than 2GB in size Reviewed-by: alanb ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h + test/java/util/zip/ZipFile/LargeZipFile.java Changeset: 59e76cdc647a Author: tbell Date: 2009-02-27 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/59e76cdc647a Merge Changeset: 58ba2cd5a250 Author: alanb Date: 2009-03-01 14:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/58ba2cd5a250 6811578: genSolarisConstants.c should not require kernel patch to compile on Solaris 10 Reviewed-by: tbell ! src/solaris/native/sun/nio/fs/genSolarisConstants.c Changeset: e0a8a9ccc4a4 Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e0a8a9ccc4a4 Added tag jdk7-b50 for changeset 58ba2cd5a250 ! .hgtags From john.coomes at sun.com Fri Mar 6 00:57:50 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Mar 2009 08:57:50 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 8 new changesets Message-ID: <20090306085802.BDB20E8CC@hg.openjdk.java.net> Changeset: 6ada6122dd4f Author: mcimadamore Date: 2009-02-13 11:57 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6ada6122dd4f 6769027: Source line should be displayed immediately after the first diagnostic line Summary: Added support for customizing diagnostic output via API/command line flags Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/Messages.java ! src/share/classes/com/sun/tools/javac/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.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/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6668794/badClass/Test.java ! test/tools/javac/6668794/badSource/Test.out ! test/tools/javac/6758789/T6758789b.out + test/tools/javac/Diagnostics/6769027/T6769027.java + test/tools/javac/Diagnostics/6769027/tester.properties ! test/tools/javac/ExtendArray.out ! test/tools/javac/T5048776b.out ! test/tools/javac/T6214885a.out ! test/tools/javac/T6214885b.out ! test/tools/javac/T6230128.out ! test/tools/javac/annotations/6365854/test1.out ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/generics/6207386/T6207386.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6718364/T6718364.out ! test/tools/javac/generics/typevars/6680106/T6680106.out ! test/tools/javac/missingSuperRecovery/MissingSuperRecovery.out ! test/tools/javac/unicode/UnicodeNewline.out Changeset: d424ed561993 Author: bpatel Date: 2009-02-18 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d424ed561993 6802694: Javadoc doclet does not display deprecated information with -nocomment option for serialized form Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml + test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java + test/com/sun/javadoc/testSerializedFormDeprecationInfo/pkg1/C1.java + test/com/sun/javadoc/testSerializedFormDeprecationInfo/pkg1/C2.java + test/com/sun/javadoc/testSerializedFormDeprecationInfo/pkg1/C3.java Changeset: f4717c901346 Author: tbell Date: 2009-02-19 18:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/f4717c901346 Merge Changeset: dab918a1c907 Author: darcy Date: 2009-02-20 11:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/dab918a1c907 6460529: Provide mixin interfaces for getQualifiedName and getTypeParameters Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/element/PackageElement.java + src/share/classes/javax/lang/model/element/Parameterizable.java + src/share/classes/javax/lang/model/element/QualifiedNameable.java ! src/share/classes/javax/lang/model/element/TypeElement.java Changeset: c4d3cbe3765a Author: tbell Date: 2009-02-21 09:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c4d3cbe3765a Merge Changeset: 1a902c0eb3f9 Author: tbell Date: 2009-02-24 07:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/1a902c0eb3f9 Merge Changeset: 46f2f6ed96f1 Author: tbell Date: 2009-02-27 10:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/46f2f6ed96f1 Merge Changeset: 4b72dc8fc51e Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/4b72dc8fc51e Added tag jdk7-b50 for changeset 46f2f6ed96f1 ! .hgtags From gbenson at redhat.com Fri Mar 6 01:23:45 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 6 Mar 2009 09:23:45 +0000 Subject: Trap indices Message-ID: <20090306092345.GA3228@redhat.com> Hi all, When you create a trap, how is the trap index used? For Shark, I want to create a trap for non-final virtual calls where the callee's holder is not loaded (ie the vtable is set up) but what would be the correct index to create the trap with? The index of the callee in the caller's pool seems wrong, since that is probably loaded already at that time. Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Fri Mar 6 03:15:54 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 06 Mar 2009 12:15:54 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <49B0E2BD.3090209@sun.com> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> Message-ID: <1236338154.2239.775.camel@localhost.localdomain> On Fri, 2009-03-06 at 00:45 -0800, Vladimir Kozlov wrote: > Looks good. > > In x86_32.ad in loadB2L you need only 7 bits shift: SAR dst.hi, 7 > and in loadS2L only 15 bits. Right. I will change that and push the changeset. Thanks Vladimir! -- Christian From Ulf.Zibis at gmx.de Fri Mar 6 04:28:23 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 06 Mar 2009 13:28:23 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236338154.2239.775.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> Message-ID: <49B116E7.4090603@gmx.de> Hi Christian, just to be sure, if following is included in your fix: What's about: char c = (char)(b & 0xFF) char c = (char)(i & 0xFF) After optimization, it should be fast as or faster as char c = (char)b Goal: determination, if b is positive, becomes superfluous, so we could use { char c = (char)(i & 0xFF) } in any case without speed loss. Also consider: char c = (char)(i & 0xFFFF) char c = (char)(intarray[i] & 0xFFFF) -Ulf Am 06.03.2009 12:15, Christian Thalinger schrieb: > On Fri, 2009-03-06 at 00:45 -0800, Vladimir Kozlov wrote: > >> Looks good. >> >> In x86_32.ad in loadB2L you need only 7 bits shift: SAR dst.hi, 7 >> and in loadS2L only 15 bits. >> > > Right. I will change that and push the changeset. Thanks Vladimir! > > -- Christian > > > From Christian.Thalinger at Sun.COM Fri Mar 6 05:06:42 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 06 Mar 2009 14:06:42 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <49B116E7.4090603@gmx.de> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <49B116E7.4090603@gmx.de> Message-ID: <1236344803.2239.782.camel@localhost.localdomain> On Fri, 2009-03-06 at 13:28 +0100, Ulf Zibis wrote: > Hi Christian, > > just to be sure, if following is included in your fix: > > What's about: > char c = (char)(b & 0xFF) > char c = (char)(i & 0xFF) > After optimization, it should be fast as or faster as > char c = (char)b > Goal: determination, if b is positive, becomes superfluous, so we could use { char c = (char)(i & 0xFF) } in any case without speed loss. > > Also consider: > char c = (char)(i & 0xFFFF) Good point. This change only includes optimizations for array load operations. I will cover cases like above in a new CR (change request). > char c = (char)(intarray[i] & 0xFFFF) Another good point. The current load optimizations only cover widening, but no shortening. Looks like another CR. Please feel free to send me some of your common use cases. -- Christian From Ulf.Zibis at gmx.de Fri Mar 6 07:19:46 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 06 Mar 2009 16:19:46 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236344803.2239.782.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <49B116E7.4090603@gmx.de> <1236344803.2239.782.camel@localhost.localdomain> Message-ID: <49B13F12.50008@gmx.de> Am 06.03.2009 14:06, Christian Thalinger schrieb: > On Fri, 2009-03-06 at 13:28 +0100, Ulf Zibis wrote: > >> Hi Christian, >> >> just to be sure, if following is included in your fix: >> >> What's about: >> char c = (char)(b & 0xFF) >> char c = (char)(i & 0xFF) >> After optimization, it should be fast as or faster as >> char c = (char)b >> Goal: determination, if b is positive, becomes superfluous, so we could use { char c = (char)(i & 0xFF) } in any case without speed loss. >> >> Also consider: >> char c = (char)(i & 0xFFFF) >> > > Good point. This change only includes optimizations for array load > operations. I will cover cases like above in a new CR (change request). > > >> char c = (char)(intarray[i] & 0xFFFF) >> > > Another good point. The current load optimizations only cover widening, > but no shortening. Looks like another CR. > > Please feel free to send me some of your common use cases. > use cases: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/AsciiShortMapDecoder.java?rev=531&view=markup https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/AsciiDirtyShortMapDecoder.java?rev=571&view=markup public char decode(final byte inByte) throws UnmappableCharacterException, MalformedInputException { if (inByte >= 0) return (char)inByte; if (inByte >= b2cMapLimit) return (char)(inByte & 0xFF); return b2cMap[inByte & 0xFF]; } could be truncated to: public char decode(final byte inByte) throws UnmappableCharacterException, MalformedInputException { if (inByte >= b2cMapLimit) return (char)(inByte & 0xFF); return b2cMap[inByte & 0xFF]; } For the last case make a search for "& 0xFFFF" and "&0xFFFF" on /src/share/classes/, I've found 289 matches in 84 files. Not to forget: "0xFFFF &" and "0xFFFF&" or "0xFFFFFFFF", "255", "65535" and "4294967295" etc... Generally I think, it could be good idea, to scan hole JDK for places, where the LoadUB, LoadUI, etc. opcode classes come to acount, and throw out all special java-side optimizations, when fix of those CRs are submitted. -Ulf From Christian.Thalinger at Sun.COM Fri Mar 6 07:49:33 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 06 Mar 2009 16:49:33 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236338154.2239.775.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> Message-ID: <1236354573.2239.800.camel@localhost.localdomain> On Fri, 2009-03-06 at 12:15 +0100, Christian Thalinger wrote: > On Fri, 2009-03-06 at 00:45 -0800, Vladimir Kozlov wrote: > > Looks good. > > > > In x86_32.ad in loadB2L you need only 7 bits shift: SAR dst.hi, 7 > > and in loadS2L only 15 bits. > > Right. I will change that and push the changeset. Thanks Vladimir! Hmm, JPRT failed and it seems there is a matcher problem. It matches: match(Set dst (ConvI2L (LoadUB mem))); instead of: match(Set dst (ConvI2L src)); But there is no LoadUB node around. Are there any matcher restrictions that I don't know about? -- Christian From Thomas.Rodriguez at Sun.COM Fri Mar 6 09:22:47 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 06 Mar 2009 09:22:47 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236354573.2239.800.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> Message-ID: What does the failure output look like? tom On Mar 6, 2009, at 7:49 AM, Christian Thalinger wrote: > On Fri, 2009-03-06 at 12:15 +0100, Christian Thalinger wrote: >> On Fri, 2009-03-06 at 00:45 -0800, Vladimir Kozlov wrote: >>> Looks good. >>> >>> In x86_32.ad in loadB2L you need only 7 bits shift: SAR dst.hi, 7 >>> and in loadS2L only 15 bits. >> >> Right. I will change that and push the changeset. Thanks Vladimir! > > Hmm, JPRT failed and it seems there is a matcher problem. It matches: > > match(Set dst (ConvI2L (LoadUB mem))); > > instead of: > > match(Set dst (ConvI2L src)); > > But there is no LoadUB node around. Are there any matcher > restrictions > that I don't know about? > > -- Christian > From Christian.Thalinger at Sun.COM Fri Mar 6 09:31:28 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 06 Mar 2009 18:31:28 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> Message-ID: <1236360688.2239.806.camel@localhost.localdomain> On Fri, 2009-03-06 at 09:22 -0800, Tom Rodriguez wrote: > What does the failure output look like? Sorry, I'm not sure I understand. Do you mean what's the console output or the generated code? -- Christian From Vladimir.Kozlov at Sun.COM Fri Mar 6 09:38:46 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 06 Mar 2009 09:38:46 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> Message-ID: <49B15FA6.9080607@sun.com> Is this Is it possible that matcher is confused by the cost? You changed the cost of ConvI2L: instruct convI2L_reg( eRegL dst, eRegI src, eFlagsReg cr) %{ match(Set dst (ConvI2L src)); effect(KILL cr); + ins_cost(375); and cost of "ConvI2L (LoadUB" is lower: ! instruct loadUB2L(eRegL dst, memory mem) ! %{ ! match(Set dst (ConvI2L (LoadUB mem))); ! ! ins_cost(250); Vladimir Tom Rodriguez wrote: > What does the failure output look like? > > tom > > On Mar 6, 2009, at 7:49 AM, Christian Thalinger wrote: > >> On Fri, 2009-03-06 at 12:15 +0100, Christian Thalinger wrote: >>> On Fri, 2009-03-06 at 00:45 -0800, Vladimir Kozlov wrote: >>>> Looks good. >>>> >>>> In x86_32.ad in loadB2L you need only 7 bits shift: SAR dst.hi, 7 >>>> and in loadS2L only 15 bits. >>> >>> Right. I will change that and push the changeset. Thanks Vladimir! >> >> Hmm, JPRT failed and it seems there is a matcher problem. It matches: >> >> match(Set dst (ConvI2L (LoadUB mem))); >> >> instead of: >> >> match(Set dst (ConvI2L src)); >> >> But there is no LoadUB node around. Are there any matcher restrictions >> that I don't know about? >> >> -- Christian >> > From Christian.Thalinger at Sun.COM Fri Mar 6 09:46:07 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 06 Mar 2009 18:46:07 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <49B15FA6.9080607@sun.com> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> Message-ID: <1236361567.2239.809.camel@localhost.localdomain> On Fri, 2009-03-06 at 09:38 -0800, Vladimir Kozlov wrote: > Is this > > Is it possible that matcher is confused by the cost? > You changed the cost of ConvI2L: > > instruct convI2L_reg( eRegL dst, eRegI src, eFlagsReg cr) %{ > match(Set dst (ConvI2L src)); > effect(KILL cr); > + ins_cost(375); > > and cost of "ConvI2L (LoadUB" is lower: > > ! instruct loadUB2L(eRegL dst, memory mem) > ! %{ > ! match(Set dst (ConvI2L (LoadUB mem))); > ! > ! ins_cost(250); Ahh, sorry, I didn't mention that this happens on x86_64. I just wonder why the matcher matches the rule when there is no LoadB that could be matched. If I remove that instruction, then the next is matched: match(Set dst (ConvI2L (LoadUB mem))); -- Christian From Vladimir.Kozlov at Sun.COM Fri Mar 6 10:18:00 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 06 Mar 2009 10:18:00 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236361567.2239.809.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> Message-ID: <49B168D8.6000109@sun.com> Matcher definitely should not do this but it could be confused since all LoadB mem, LoadUB mem, LoadI mem produce the same RegI register and it takes first one defined in generated/adfiles/dfa_x86_64.cpp in State::_sub_Op_ConvI2L(const Node *n) method. Vladimir Christian Thalinger wrote: > On Fri, 2009-03-06 at 09:38 -0800, Vladimir Kozlov wrote: >> Is this >> >> Is it possible that matcher is confused by the cost? >> You changed the cost of ConvI2L: >> >> instruct convI2L_reg( eRegL dst, eRegI src, eFlagsReg cr) %{ >> match(Set dst (ConvI2L src)); >> effect(KILL cr); >> + ins_cost(375); >> >> and cost of "ConvI2L (LoadUB" is lower: >> >> ! instruct loadUB2L(eRegL dst, memory mem) >> ! %{ >> ! match(Set dst (ConvI2L (LoadUB mem))); >> ! >> ! ins_cost(250); > > Ahh, sorry, I didn't mention that this happens on x86_64. I just wonder > why the matcher matches the rule when there is no LoadB that could be > matched. If I remove that instruction, then the next is matched: > > match(Set dst (ConvI2L (LoadUB mem))); > > -- Christian > From Thomas.Rodriguez at Sun.COM Fri Mar 6 10:29:07 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 06 Mar 2009 10:29:07 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236361567.2239.809.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> Message-ID: <71147AE1-8977-4A35-9555-D844DAE04ED8@sun.com> I'm very confused by your explanation of what's going wrong. Originally you said: mm, JPRT failed and it seems there is a matcher problem. It matches: match(Set dst (ConvI2L (LoadUB mem))); instead of: match(Set dst (ConvI2L src)); But there is no LoadUB node around. Are there any matcher restrictions that I don't know about? But below you say that if you remove that instruction it matches the ConvI2L LoadUB pattern so which one did it do? Also what is "that instruction"? What kind of node is src if it's not a LoadUB? I really can't see the matcher matching the wrong node unless there are some problems with your adlc changes. Node matching is all driven by the Opcode(). tom On Mar 6, 2009, at 9:46 AM, Christian Thalinger wrote: > On Fri, 2009-03-06 at 09:38 -0800, Vladimir Kozlov wrote: >> Is this >> >> Is it possible that matcher is confused by the cost? >> You changed the cost of ConvI2L: >> >> instruct convI2L_reg( eRegL dst, eRegI src, eFlagsReg cr) %{ >> match(Set dst (ConvI2L src)); >> effect(KILL cr); >> + ins_cost(375); >> >> and cost of "ConvI2L (LoadUB" is lower: >> >> ! instruct loadUB2L(eRegL dst, memory mem) >> ! %{ >> ! match(Set dst (ConvI2L (LoadUB mem))); >> ! >> ! ins_cost(250); > > Ahh, sorry, I didn't mention that this happens on x86_64. I just > wonder > why the matcher matches the rule when there is no LoadB that could be > matched. If I remove that instruction, then the next is matched: > > match(Set dst (ConvI2L (LoadUB mem))); > > -- Christian > From Thomas.Rodriguez at Sun.COM Fri Mar 6 10:33:22 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 06 Mar 2009 10:33:22 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236361567.2239.809.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> Message-ID: <5E20BDA6-269B-40DD-94A4-A5DD23E55117@sun.com> If you want to see how it gets matched you can set breakpoints in the dfa code for the various node types. Do a case insensitive search for loadUB2L in dfa_x86_64.cpp to see all the matching machinery for it. If you set a breakpoint on the SET_VALID part you can call dump() on the State to see what dfa states it considered valid at the match point. I can take a look at the generated dfa if you like to see if there's anything weird about it. Could you send me a pointer to it? tom On Mar 6, 2009, at 9:46 AM, Christian Thalinger wrote: > On Fri, 2009-03-06 at 09:38 -0800, Vladimir Kozlov wrote: >> Is this >> >> Is it possible that matcher is confused by the cost? >> You changed the cost of ConvI2L: >> >> instruct convI2L_reg( eRegL dst, eRegI src, eFlagsReg cr) %{ >> match(Set dst (ConvI2L src)); >> effect(KILL cr); >> + ins_cost(375); >> >> and cost of "ConvI2L (LoadUB" is lower: >> >> ! instruct loadUB2L(eRegL dst, memory mem) >> ! %{ >> ! match(Set dst (ConvI2L (LoadUB mem))); >> ! >> ! ins_cost(250); > > Ahh, sorry, I didn't mention that this happens on x86_64. I just > wonder > why the matcher matches the rule when there is no LoadB that could be > matched. If I remove that instruction, then the next is matched: > > match(Set dst (ConvI2L (LoadUB mem))); > > -- Christian > From John.Rose at Sun.COM Fri Mar 6 10:57:33 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 06 Mar 2009 10:57:33 -0800 Subject: Trap indices In-Reply-To: <20090306092345.GA3228@redhat.com> References: <20090306092345.GA3228@redhat.com> Message-ID: <6C45E0CD-5D76-41C8-885A-94AAF7CA82AD@sun.com> If you are talking about the trap indexes in deoptimization.hpp, they are constant pool indexes in the caller. If the trap pertains to a constant in the caller's constant pool, this is the relevant information. Other kinds of traps have less informative markings, such as "unexpected type", "null check", etc. The method/bci is always available for inspection. -- John On Mar 6, 2009, at 1:23 AM, Gary Benson wrote: > Hi all, > > When you create a trap, how is the trap index used? For Shark, I want > to create a trap for non-final virtual calls where the callee's holder > is not loaded (ie the vtable is set up) but what would be the correct > index to create the trap with? The index of the callee in the > caller's pool seems wrong, since that is probably loaded already at > that time. > > Cheers, > Gary > > -- > http://gbenson.net/ From Christian.Thalinger at Sun.COM Fri Mar 6 11:00:20 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 06 Mar 2009 20:00:20 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <71147AE1-8977-4A35-9555-D844DAE04ED8@sun.com> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> <71147AE1-8977-4A35-9555-D844DAE04ED8@sun.com> Message-ID: <1236366020.2239.819.camel@localhost.localdomain> On Fri, 2009-03-06 at 10:29 -0800, Tom Rodriguez wrote: > I'm very confused by your explanation of what's going wrong. > Originally you said: Okay, sorry. Trying to rephrase. > > mm, JPRT failed and it seems there is a matcher problem. It matches: > > match(Set dst (ConvI2L (LoadUB mem))); > > instead of: > > match(Set dst (ConvI2L src)); > > But there is no LoadUB node around. Are there any matcher restrictions > that I don't know about? > > But below you say that if you remove that instruction it matches the > ConvI2L LoadUB pattern so which one did it do? Also what is "that > instruction"? What kind of node is src if it's not a LoadUB? It matches the loadB2L instruction in x86_64.ad and I meant loadB2L by "that instruction". But when I comment loadB2L it simply matches the next one, and that is loadUB2L. > What kind of node is src if it's not a LoadUB? Good question. The correct instruction generated by unmodified HotSpot is: 029 movslq R10, [RSP + #0 (32-bit)] # i2l and the corresponding store before is: 019 movl [rsp + #0], RSI # spill So I think src is a Param (if that's a valid node). -- Christian From Vladimir.Kozlov at Sun.COM Fri Mar 6 11:11:58 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 06 Mar 2009 11:11:58 -0800 Subject: for review (M): 6812831 factor megamorphic invokeinterface (for 6655638) In-Reply-To: <3E9D1DE4-B24C-4CF0-9D33-42B1F235D780@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> <3E9D1DE4-B24C-4CF0-9D33-42B1F235D780@sun.com> Message-ID: <49B1757E.3060008@sun.com> vtableStubs_sparc.cpp: Why you changed 2* to 6* for CompressedOops? There is only 1 load_klass and with CompressedOops it need only 2 additional instructions (shift;add) to decode it. - // save, ld, ld, sll, and, add, add, ld, cmp, br, add, ld, add, ld, ld, jmp, restore, sethi, jmpl, restore - const int basic = (20 LP64_ONLY(+ 6)) * BytesPerInstWord + - // shift;add for load_klass - (UseCompressedOops ? 2*BytesPerInstWord : 0); + const int basic = (28 LP64_ONLY(+ 6)) * BytesPerInstWord + + // shift;add for load_klass, decode, and encode + (UseCompressedOops ? 6*BytesPerInstWord : 0); vtableStubs_x86_32.cpp: Did your changes increase the size or it was wrong before? Or it is upper/rounded limit on the size? - return (DebugVtables ? 144 : 64) + (CountCompiledCalls ? 6 : 0); + return (DebugVtables ? 256 : 66) + (CountCompiledCalls ? 6 : 0); Otherwise looks good. Vladimir John Rose wrote: > In response to a review request (thanks, Vladimir!) I've split the > refactoring of the itable lookup logic into a separate change request. > > Here it is; please (re-)review: > http://cr.openjdk.java.net/~jrose/6812831/webrev > > It is a little different from the corresponding changes in the mega-review. > I cleaned it up slightly, so that the interface search loop is tighter. > (Should fit on an I$ line now.) > I also make it work on x86 (32 and 64) and SPARC. > > -- John From Christian.Thalinger at Sun.COM Fri Mar 6 11:31:29 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 06 Mar 2009 20:31:29 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <49B168D8.6000109@sun.com> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> <49B168D8.6000109@sun.com> Message-ID: <1236367889.2239.824.camel@localhost.localdomain> On Fri, 2009-03-06 at 10:18 -0800, Vladimir Kozlov wrote: > Matcher definitely should not do this but it could be confused since > all LoadB mem, LoadUB mem, LoadI mem produce the same RegI register > and it takes first one defined in generated/adfiles/dfa_x86_64.cpp > in State::_sub_Op_ConvI2L(const Node *n) method. Maybe the problem this (in ad_x86_64.hpp): class loadB2LNode : public MachNode { ... virtual int ideal_Opcode() const { return Op_ConvI2L; } But I'm just guessing... -- Christian From John.Rose at Sun.COM Fri Mar 6 11:35:53 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 06 Mar 2009 11:35:53 -0800 Subject: for review (M): 6812831 factor megamorphic invokeinterface (for 6655638) In-Reply-To: <49B1757E.3060008@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> <3E9D1DE4-B24C-4CF0-9D33-42B1F235D780@sun.com> <49B1757E.3060008@sun.com> Message-ID: On Mar 6, 2009, at 11:11 AM, Vladimir Kozlov wrote: > vtableStubs_sparc.cpp: > Why you changed 2* to 6* for CompressedOops? There is only 1 > load_klass > and with CompressedOops it need only 2 additional instructions > (shift;add) > to decode it. > > - // save, ld, ld, sll, and, add, add, ld, cmp, br, add, ld, > add, ld, ld, jmp, restore, sethi, jmpl, restore > - const int basic = (20 LP64_ONLY(+ 6)) * BytesPerInstWord + > - // shift;add for load_klass > - (UseCompressedOops ? 2*BytesPerInstWord : 0); > + const int basic = (28 LP64_ONLY(+ 6)) * BytesPerInstWord + > + // shift;add for load_klass, decode, and > encode > + (UseCompressedOops ? 6*BytesPerInstWord : 0); You are right. Frankly, I don't remember how that diff got in there; maybe just an excess of caution. I'll nuke it. > vtableStubs_x86_32.cpp: > Did your changes increase the size or it was wrong before? > Or it is upper/rounded limit on the size? > > - return (DebugVtables ? 144 : 64) + (CountCompiledCalls ? 6 : 0); > + return (DebugVtables ? 256 : 66) + (CountCompiledCalls ? 6 : 0); My changes increased the size slightly, because I peeled the loop a little bit for speed. I found those numbers (like 28, 66) by running with PrintMisc. The new print logic tells exactly how many instruction bytes are wasted. I aimed at a slop of 4 bytes, so as not to overflow when really large itable offsets are encountered. I'll note this in the comments before I push! Thanks, -- John From Thomas.Rodriguez at Sun.COM Fri Mar 6 11:57:06 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 06 Mar 2009 11:57:06 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236366020.2239.819.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> <71147AE1-8977-4A35-9555-D844DAE04ED8@sun.com> <1236366020.2239.819.camel@localhost.localdomain> Message-ID: >> Good question. The correct instruction generated by unmodified >> HotSpot > is: > > 029 movslq R10, [RSP + #0 (32-bit)] # i2l That looks like a cisc spill. The matcher and the adlc collaborate to identify pairs of instructions that do the same thing but where one takes a register and the other takes memory. Then if the register allocator needs to reload a value from stack it can use the memory version instead of inserting a real spill. I wonder if something is going wrong with the logic for identifying these. Where's your generated ad_x86_64.hpp? tom > > > and the corresponding store before is: > > 019 movl [rsp + #0], RSI # spill > > So I think src is a Param (if that's a valid node). > > -- Christian > From Thomas.Rodriguez at Sun.COM Fri Mar 6 12:19:54 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 06 Mar 2009 12:19:54 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236367889.2239.824.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> <49B168D8.6000109@sun.com> <1236367889.2239.824.camel@localhost.localdomain> Message-ID: I think the problem is in MatchNode::cisc_spill_match in formssel.cpp. It appears to be selecting these new instructions as cisc spill variants without checking that the intermediate load operations match the size of the spill operation. If you look in ad_x86_64.cpp it dumps a big list of the cisc spill variants and you can see that it's selecting the byte sized variant instead of the int sized one. Didn't you reorder the instruct definitions? I think the cisc spill matching selects the first one it sees and it's possible that now it's finding the LoadB variant. Anyway, I think cisc_spill_match should be fixed to handle this correctly. tom On Mar 6, 2009, at 11:31 AM, Christian Thalinger wrote: > On Fri, 2009-03-06 at 10:18 -0800, Vladimir Kozlov wrote: >> Matcher definitely should not do this but it could be confused since >> all LoadB mem, LoadUB mem, LoadI mem produce the same RegI register >> and it takes first one defined in generated/adfiles/dfa_x86_64.cpp >> in State::_sub_Op_ConvI2L(const Node *n) method. > > Maybe the problem this (in ad_x86_64.hpp): > > class loadB2LNode : public MachNode { > ... > virtual int ideal_Opcode() const { return Op_ConvI2L; } > > But I'm just guessing... > > -- Christian > From Christian.Thalinger at Sun.COM Fri Mar 6 12:31:49 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 06 Mar 2009 21:31:49 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> <49B168D8.6000109@sun.com> <1236367889.2239.824.camel@localhost.localdomain> Message-ID: <1236371509.2239.834.camel@localhost.localdomain> On Fri, 2009-03-06 at 12:19 -0800, Tom Rodriguez wrote: > I think the problem is in MatchNode::cisc_spill_match in > formssel.cpp. It appears to be selecting these new instructions as > cisc spill variants without checking that the intermediate load > operations match the size of the spill operation. If you look in > ad_x86_64.cpp it dumps a big list of the cisc spill variants and you > can see that it's selecting the byte sized variant instead of the int > sized one. It says: // convI2L_reg_reg can cisc-spill operand 1 to loadB2L and later: // Build CISC version of this instruction MachNode *convI2L_reg_regNode::cisc_version( int offset, Compile* C ) { loadB2LNode *node = new (C) loadB2LNode(); > > Didn't you reorder the instruct definitions? No, I just uncommented some of them. Maybe these have been commented because of this bug... > I think the cisc spill > matching selects the first one it sees and it's possible that now it's > finding the LoadB variant. Anyway, I think cisc_spill_match should be > fixed to handle this correctly. Do you think I can fix that or is it too complicated for a "beginner"? At least I will have a look at it. -- Christian From Thomas.Rodriguez at Sun.COM Fri Mar 6 13:34:58 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 06 Mar 2009 13:34:58 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236371509.2239.834.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> <49B168D8.6000109@sun.com> <1236367889.2239.824.camel@localhost.localdomain> <1236371509.2239.834.camel@localhost.localdomain> Message-ID: >> Didn't you reorder the instruct definitions? > > No, I just uncommented some of them. Maybe these have been commented > because of this bug... It's possible. The ConvI2L LoadI variant was the first and only one before your change but now it's not. > > >> I think the cisc spill >> matching selects the first one it sees and it's possible that now >> it's >> finding the LoadB variant. Anyway, I think cisc_spill_match should >> be >> fixed to handle this correctly. > > Do you think I can fix that or is it too complicated for a "beginner"? > At least I will have a look at it. You want this change: @@ -3431,10 +3431,16 @@ int MatchNode::cisc_spill_match(FormDict const InstructForm *form2_inst = form2 ? form2- >is_instruction() : NULL; const char *name_left = mRule2->_lChild ? mRule2->_lChild- >_opType : NULL; const char *name_right = mRule2->_rChild ? mRule2->_rChild- >_opType : NULL; + DataType data_type = Form::none; + if (form->is_operand()) { + // Make sure the loadX matches the type of the reg + data_type = form->ideal_to_Reg_type(form->is_operand()- >ideal_type(globals)); + } // Detect reg vs (loadX memory) if( form->is_cisc_reg(globals) && form2_inst - && (is_load_from_memory(mRule2->_opType) != Form::none) // reg vs. (load memory) + && data_type != Form::none + && (is_load_from_memory(mRule2->_opType) == data_type) // reg vs. (load memory) && (name_left != NULL) // NOT (load) && (name_right == NULL) ) { // NOT (load memory foo) const Form *form2_left = name_left ? globals[name_left] : NULL; This will verify that the ideal type of the register and the load operation are in agreement. tom > > > -- Christian > From Christian.Thalinger at Sun.COM Fri Mar 6 14:04:23 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 06 Mar 2009 23:04:23 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> <49B168D8.6000109@sun.com> <1236367889.2239.824.camel@localhost.localdomain> <1236371509.2239.834.camel@localhost.localdomain> Message-ID: <1236377063.2239.835.camel@localhost.localdomain> On Fri, 2009-03-06 at 13:34 -0800, Tom Rodriguez wrote: > This will verify that the ideal type of the register and the load > operation are in agreement. Yes, that fixes it. Thanks a lot! Should I integrate these changes into my patch and commit it or should we do another review round? -- Christian From Thomas.Rodriguez at Sun.COM Fri Mar 6 14:06:37 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 06 Mar 2009 14:06:37 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236377063.2239.835.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> <49B168D8.6000109@sun.com> <1236367889.2239.824.camel@localhost.localdomain> <1236371509.2239.834.camel@localhost.localdomain> Message-ID: I'm fine with you committing it, though could you check that the changes to cisc_spill_match don't change the result of any other cisc spill decisions on 32 bit intel? tom On Mar 6, 2009, at 2:04 PM, Christian Thalinger wrote: > On Fri, 2009-03-06 at 13:34 -0800, Tom Rodriguez wrote: >> This will verify that the ideal type of the register and the load >> operation are in agreement. > > Yes, that fixes it. Thanks a lot! Should I integrate these changes > into my patch and commit it or should we do another review round? > > -- Christian > From Vladimir.Kozlov at Sun.COM Fri Mar 6 14:05:05 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 06 Mar 2009 14:05:05 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: References: <1235666480.2004.256.camel@localhost.localdomain> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> <49B168D8.6000109@sun.com> <1236367889.2239.824.camel@localhost.localdomain> <1236371509.2239.834.camel@localhost.localdomain> Message-ID: <49B19E11.9000303@sun.com> I am fine also with this. Thanks, Vladimir Tom Rodriguez wrote: > I'm fine with you committing it, though could you check that the changes > to cisc_spill_match don't change the result of any other cisc spill > decisions on 32 bit intel? > > tom > > On Mar 6, 2009, at 2:04 PM, Christian Thalinger wrote: > >> On Fri, 2009-03-06 at 13:34 -0800, Tom Rodriguez wrote: >>> This will verify that the ideal type of the register and the load >>> operation are in agreement. >> >> Yes, that fixes it. Thanks a lot! Should I integrate these changes >> into my patch and commit it or should we do another review round? >> >> -- Christian >> > From Vladimir.Kozlov at Sun.COM Fri Mar 6 14:52:21 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 06 Mar 2009 14:52:21 -0800 Subject: for review (M): 6812831 factor general subclass check (for 6655638) In-Reply-To: References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> Message-ID: <49B1A925.1030304@sun.com> John, Looks good. I would suggest to run CTW to verify it. Use Tom's script ~never/bin/multictw which use all cpus. stubGenerator_x86_32.cpp: I think you should be careful with using forward jccb for L_fallthrough label separated by a big macro instruction check_klass_subtype_slow_pat(). Thanks, Vladimir John Rose wrote: > Here is another review request similar to the previous: > http://cr.openjdk.java.net/~jrose/6813212/webrev.00 > > It moves assembly code for subtyping from about 20 places in the source > base to two places, one for sparc and one for x86. > > I will update this webrev after I clean out the subtype assembly code > from the *.ad files. > > While doing this work, I encountered two or three small bugs in the > assembly code, probably due to the fact that it was so hard to read and > understand all 20 variations: > 1. 32-bit instead of 64-bit comparison of pointers in C1 subtype code > (c1_LIRAssembler_sparc.cpp). > 2. Compare against wrong register in sparc stub generator > (stubGenerator_sparc.cpp at cmp(super_klass, sc_offset)). > 3. Wrong variable names in C1 slow-path code: subclass and superclass > were swapped (c1_Runtime1_x86.cpp). > > None of these are very harmful, or we would have fixed them already. I > think we know about number 1; it makes it hard to port C1 to LP64. > Number 2 would make System.arraycopy wrongly throw a CCE if the target > array element type is a secondary supertype and is *not* already cached > on the element subtypes. I think I'll have to break this one out as a > separate fix, so it can be backported. > > -- John From Christian.Thalinger at Sun.COM Fri Mar 6 15:09:22 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sat, 07 Mar 2009 00:09:22 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> <49B168D8.6000109@sun.com> <1236367889.2239.824.camel@localhost.localdomain> <1236371509.2239.834.camel@localhost.localdomain> Message-ID: <1236380962.2239.836.camel@localhost.localdomain> On Fri, 2009-03-06 at 14:06 -0800, Tom Rodriguez wrote: > I'm fine with you committing it, though could you check that the > changes to cisc_spill_match don't change the result of any other cisc > spill decisions on 32 bit intel? Sure. I will have a look at this tomorrow. -- Christian From john.rose at sun.com Sat Mar 7 06:06:26 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Sat, 07 Mar 2009 14:06:26 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6812831: factor duplicated assembly code for megamorphic invokeinterface (for 6655638) Message-ID: <20090307140629.11814E9BA@hg.openjdk.java.net> Changeset: 9adddb8c0fc8 Author: jrose Date: 2009-03-06 21:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9adddb8c0fc8 6812831: factor duplicated assembly code for megamorphic invokeinterface (for 6655638) Summary: Code in vtableStubs and templateTable moved into MacroAssembler. Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp From John.Rose at Sun.COM Sat Mar 7 06:13:16 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 07 Mar 2009 06:13:16 -0800 Subject: for review (M): 6812831 factor general subclass check (for 6655638) In-Reply-To: <49B1A925.1030304@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> <49B1A925.1030304@sun.com> Message-ID: <114E16A2-2C97-48A2-8261-3744859531C6@Sun.COM> On Mar 6, 2009, at 2:52 PM, Vladimir Kozlov wrote: > Looks good. I would suggest to run CTW to verify it. > Use Tom's script ~never/bin/multictw which use all cpus. Good idea. I now have CTWs in progress on 4 CPU types (32/64 sparc/ x86). I'm also doing a trial JPRT run. > stubGenerator_x86_32.cpp: > I think you should be careful with using forward jccb for > L_fallthrough label separated by a big macro instruction > check_klass_subtype_slow_pat(). I see what you mean; you are right. I backed off on the jccb's in generate_type_check. After going over the code another time, and fixing the AD files, I have updated the webrev: http://cr.openjdk.java.net/~jrose/6813212/webrev.01/ http://cr.openjdk.java.net/~jrose/6813212/00-to-01.patch.txt Thanks for the reviews! -- John From John.Rose at Sun.COM Sat Mar 7 14:46:28 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 07 Mar 2009 14:46:28 -0800 Subject: for review (M): 6812831 factor general subclass check (for 6655638) In-Reply-To: References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> Message-ID: <70B93A42-0F56-4170-BA05-EDD20D328494@sun.com> On Mar 5, 2009, at 9:06 PM, John Rose wrote: > ... 2. Compare against wrong register in sparc stub generator > (stubGenerator_sparc.cpp at cmp(super_klass, sc_offset))... > > Number 2 would make System.arraycopy wrongly throw a CCE if the > target array element type is a secondary supertype and is *not* > already cached on the element subtypes. I think I'll have to break > this one out as a separate fix, so it can be backported. FTR, #2 is just a failed optimization in a corner case. No CCE thrown, no need to backport. When the fast loop gets the type test wrong, it just backs off to the slow (original) loop. -- John From John.Rose at Sun.COM Sun Mar 8 00:05:39 2009 From: John.Rose at Sun.COM (John Rose) Date: Sun, 08 Mar 2009 00:05:39 -0800 Subject: for (re-)review (M): 6814659: separable cleanups and subroutines for 6655638 In-Reply-To: <3E9D1DE4-B24C-4CF0-9D33-42B1F235D780@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> <3E9D1DE4-B24C-4CF0-9D33-42B1F235D780@sun.com> Message-ID: In order to reduce the size of my forthcoming method handles changeset, I have (at Vladimir's suggestion) pulled out chunks of independent changes this week. The four chunks amount to about 40% of the changes, and are more easily tested and reviewed in isolation. The fourth chunk 6814659 is the most miscellaneous. It is a bunch of changes that were necessary either for debugging method handles, or for supporting them. They can all be considered independently. Here are the changes: http://cr.openjdk.java.net/~jrose/6814659/webrev.00/ Not much review is necessary here, because these changes have already been reviewed as part of the larger changeset. The current draft of the big change is here: http://cr.openjdk.java.net/~jrose/6655638/webrev.00/ -- John P.S. For the record, here is the sequence: 1. 6812678: macro assembler needs delayed binding of a few constants (for 6655638) http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/56aae7be60d4 2. 6812831: factor duplicated assembly code for megamorphic invokeinterface (for 6655638) http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9adddb8c0fc8 3. 6812831 factor general subclass check (for 6655638) http://cr.openjdk.java.net/~jrose/6813212/webrev.01/ (not yet integrated) 4. 6814659: separable cleanups and subroutines for 6655638 http://cr.openjdk.java.net/~jrose/6814659/webrev.00/ (not yet integrated) 5. 6655638: dynamic languages need method handles http://cr.openjdk.java.net/~jrose/6655638/webrev.00/ (not yet integrated) And here are the patch file sizes (from my mq patch queue): 1178 5493 48571 asm-6812678.patch 979 5029 40958 ilookup-6812831.patch 1611 7834 70518 subtype-6813212.patch 1147 4962 48089 minor-6814659.patch 7274 33505 311948 meth.patch 12189 56823 520084 total -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090308/77984b03/attachment.html From Christian.Thalinger at Sun.COM Mon Mar 9 03:18:00 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 09 Mar 2009 11:18:00 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236380962.2239.836.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236103716.2239.105.camel@localhost.localdomain> <1236114617.2239.111.camel@localhost.localdomain> <3CFCFB5B-A357-4DA5-9CFF-529B805CF0A5@Sun.COM> <49B0E2BD.3090209@sun.com> <1236338154.2239.775.camel@localhost.localdomain> <1236354573.2239.800.camel@localhost.localdomain> <49B15FA6.9080607@sun.com> <1236361567.2239.809.camel@localhost.localdomain> <49B168D8.6000109@sun.com> <1236367889.2239.824.camel@localhost.localdomain> <1236371509.2239.834.camel@localhost.localdomain> <1236380962.2239.836.camel@localhost.localdomain> Message-ID: <1236593880.2239.841.camel@localhost.localdomain> On Sat, 2009-03-07 at 00:09 +0100, Christian Thalinger wrote: > On Fri, 2009-03-06 at 14:06 -0800, Tom Rodriguez wrote: > > I'm fine with you committing it, though could you check that the > > changes to cisc_spill_match don't change the result of any other cisc > > spill decisions on 32 bit intel? > > Sure. I will have a look at this tomorrow. Looks good. I will commit it now. -- Christian From Christian.Thalinger at Sun.COM Mon Mar 9 05:43:10 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 09 Mar 2009 12:43:10 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6797305: Add LoadUB and LoadUI opcode class Message-ID: <20090309124313.7DF3DEA42@hg.openjdk.java.net> Changeset: 337400e7a5dd Author: twisti Date: 2009-03-09 03:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/337400e7a5dd 6797305: Add LoadUB and LoadUI opcode class Summary: Add a LoadUB (unsigned byte) and LoadUI (unsigned int) opcode class so we have these load optimizations in the first place and do not need to handle them in the matcher. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/6797305/Test6797305.java From gbenson at redhat.com Mon Mar 9 08:08:02 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 9 Mar 2009 15:08:02 +0000 Subject: Trap indices In-Reply-To: <6C45E0CD-5D76-41C8-885A-94AAF7CA82AD@sun.com> References: <20090306092345.GA3228@redhat.com> <6C45E0CD-5D76-41C8-885A-94AAF7CA82AD@sun.com> Message-ID: <20090309150802.GB25077@redhat.com> Hi John, Thanks for that, that's exactly what I needed. Cheers, Gary John Rose wrote: > If you are talking about the trap indexes in deoptimization.hpp, > they are constant pool indexes in the caller. If the trap pertains > to a constant in the caller's constant pool, this is the relevant > information. Other kinds of traps have less informative markings, > such as "unexpected type", "null check", etc. The method/bci is > always available for inspection. > > -- John > > On Mar 6, 2009, at 1:23 AM, Gary Benson wrote: > > Hi all, > > > > When you create a trap, how is the trap index used? For Shark, > > I want to create a trap for non-final virtual calls where the > > callee's holder is not loaded (ie the vtable is set up) but what > > would be the correct index to create the trap with? The index > > of the callee in the caller's pool seems wrong, since that is > > probably loaded already at that time. > > > > Cheers, > > Gary > > > > -- > > http://gbenson.net/ -- http://gbenson.net/ From Vladimir.Kozlov at Sun.COM Mon Mar 9 08:24:08 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 09 Mar 2009 08:24:08 -0700 Subject: for (re-)review (M): 6814659: separable cleanups and subroutines for 6655638 In-Reply-To: References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> <3E9D1DE4-B24C-4CF0-9D33-42B1F235D780@sun.com> Message-ID: <49B53498.2020601@sun.com> John, something wrong with this webrev, diffs are reversed http://cr.openjdk.java.net/~jrose/6813212/webrev.01/ for example, in stubGenerator_sparc.cpp. And assembler_sparc.hpp, c1_LIRAssembler_sparc.cpp don't have diffs. Vladimir John Rose wrote: > In order to reduce the size of my forthcoming method handles changeset, > I have (at Vladimir's suggestion) pulled out chunks of independent > changes this week. The four chunks amount to about 40% of the changes, > and are more easily tested and reviewed in isolation. > > The fourth chunk 6814659 is the most miscellaneous. It is a bunch of > changes that were necessary either for debugging method handles, or for > supporting them. They can all be considered independently. > > Here are the changes: > http://cr.openjdk.java.net/~jrose/6814659/webrev.00/ > > Not much review is necessary here, because these changes have already > been reviewed as part of the larger changeset. > > The current draft of the big change is here: > http://cr.openjdk.java.net/~jrose/6655638/webrev.00/ > > -- John > > P.S. For the record, here is the sequence: > > 1. 6812678: macro assembler needs delayed binding of a few constants > (for 6655638) > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/56aae7be60d4 > > 2. 6812831: factor duplicated assembly code for megamorphic > invokeinterface (for 6655638) > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9adddb8c0fc8 > > 3. 6812831 factor general subclass check (for 6655638) > http://cr.openjdk.java.net/~jrose/6813212/webrev.01/ (not yet integrated) > > 4. 6814659: separable cleanups and subroutines for 6655638 > http://cr.openjdk.java.net/~jrose/6814659/webrev.00/ (not yet integrated) > > 5. 6655638: dynamic languages need method handles > http://cr.openjdk.java.net/~jrose/6655638/webrev.00/ (not yet integrated) > > And here are the patch file sizes (from my mq patch queue): > > 1178 5493 48571 asm-6812678.patch > 979 5029 40958 ilookup-6812831.patch > 1611 7834 70518 subtype-6813212.patch > 1147 4962 48089 minor-6814659.patch > 7274 33505 311948 meth.patch > 12189 56823 520084 total > From Christian.Thalinger at Sun.COM Mon Mar 9 11:15:38 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 09 Mar 2009 19:15:38 +0100 Subject: Request for reviews (S): 6814842: Load shortening optimizations Message-ID: <1236622538.2239.867.camel@localhost.localdomain> http://cr.openjdk.java.net/~twisti/6814842/webrev.00/ From Thomas.Rodriguez at Sun.COM Mon Mar 9 11:24:59 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 09 Mar 2009 11:24:59 -0700 Subject: Request for reviews (S): 6814842: Load shortening optimizations In-Reply-To: <1236622538.2239.867.camel@localhost.localdomain> References: <1236622538.2239.867.camel@localhost.localdomain> Message-ID: <9DE26A3F-F27B-4ADD-A33E-B15EA0C37233@sun.com> You can't simply replace a load of one size with a load of a different size without dealing with the endianness issue. Even if you deal with that, I also think there are issues with alias analysis understanding that a load at +3 within an int is in the same alias class as a load at +0. The current code assumes that operations start at the beginning of the field. I'm also not sure the rest of the system will be very happy with non-int loads on an int memory slice. I think a lot of testing would be required for such a change. tom On Mar 9, 2009, at 11:15 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6814842/webrev.00/ > From Christian.Thalinger at Sun.COM Mon Mar 9 11:41:17 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 09 Mar 2009 19:41:17 +0100 Subject: Request for reviews (S): 6814842: Load shortening optimizations In-Reply-To: <9DE26A3F-F27B-4ADD-A33E-B15EA0C37233@sun.com> References: <1236622538.2239.867.camel@localhost.localdomain> <9DE26A3F-F27B-4ADD-A33E-B15EA0C37233@sun.com> Message-ID: <1236624077.2239.873.camel@localhost.localdomain> On Mon, 2009-03-09 at 11:24 -0700, Tom Rodriguez wrote: > You can't simply replace a load of one size with a load of a different > size without dealing with the endianness issue. Yes, I don't deal with that right now. > Even if you deal with > that, I also think there are issues with alias analysis understanding > that a load at +3 within an int is in the same alias class as a load > at +0. The current code assumes that operations start at the > beginning of the field. I'm also not sure the rest of the system will > be very happy with non-int loads on an int memory slice. I think a > lot of testing would be required for such a change. I see. Sounds like too much work and possible problems for such a small (probably not very often applied) optimization. Should I drop it? -- Christian From John.Rose at Sun.COM Mon Mar 9 11:46:15 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 09 Mar 2009 11:46:15 -0700 Subject: for (re-)review (M): 6814659: separable cleanups and subroutines for 6655638 In-Reply-To: <49B53498.2020601@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> <3E9D1DE4-B24C-4CF0-9D33-42B1F235D780@sun.com> <49B53498.2020601@sun.com> Message-ID: On Mar 9, 2009, at 8:24 AM, Vladimir Kozlov wrote: > something wrong with this webrev, diffs are reversed > > http://cr.openjdk.java.net/~jrose/6813212/webrev.01/ Foo. I regenerated the webrev. It looks better now. -- John From Thomas.Rodriguez at Sun.COM Mon Mar 9 11:53:01 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 09 Mar 2009 11:53:01 -0700 Subject: Request for reviews (S): 6814842: Load shortening optimizations In-Reply-To: <1236624077.2239.873.camel@localhost.localdomain> References: <1236622538.2239.867.camel@localhost.localdomain> <9DE26A3F-F27B-4ADD-A33E-B15EA0C37233@sun.com> <1236624077.2239.873.camel@localhost.localdomain> Message-ID: <15D07FC0-4D0E-4234-8CFC-0C16A64ACA7E@Sun.COM> > I see. Sounds like too much work and possible problems for such a > small > (probably not very often applied) optimization. Should I drop it? I think the bang for the buck is low to change it at the ideal level. Can't this be addressed in the ad files? The adds to deal with endianness will get hidden in the encoding so it won't effect alias analysis. tom > > > -- Christian > From John.Rose at Sun.COM Mon Mar 9 12:09:26 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 09 Mar 2009 12:09:26 -0700 Subject: Request for reviews (S): 6814842: Load shortening optimizations In-Reply-To: <15D07FC0-4D0E-4234-8CFC-0C16A64ACA7E@Sun.COM> References: <1236622538.2239.867.camel@localhost.localdomain> <9DE26A3F-F27B-4ADD-A33E-B15EA0C37233@sun.com> <1236624077.2239.873.camel@localhost.localdomain> <15D07FC0-4D0E-4234-8CFC-0C16A64ACA7E@Sun.COM> Message-ID: <2F97CA36-8A17-4E3E-A8DF-E59F9A6464A0@sun.com> On Mar 9, 2009, at 11:53 AM, Tom Rodriguez wrote: >> I see. Sounds like too much work and possible problems for such a >> small >> (probably not very often applied) optimization. Should I drop it? > > I think the bang for the buck is low to change it at the ideal > level. Can't this be addressed in the ad files? The adds to deal > with endianness will get hidden in the encoding so it won't effect > alias analysis. We tried shortening 64- to 32-bit loads once, and we backed off. IIRC, there was an interaction with copy coalescing or some other post- match logic. I looked in the old teamware histories, but couldn't find evidence of it, so it's just a hazy memory of years ago. Load shortening might make sense very late, after register allocation, near post-allocation copy removal. At that point, you should be able to alter offsets also, so you are not limited just to the word or byte which happens to come first in the CPU's endian order. -- John From Christian.Thalinger at Sun.COM Mon Mar 9 12:23:30 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 09 Mar 2009 20:23:30 +0100 Subject: Request for reviews (S): 6814842: Load shortening optimizations In-Reply-To: <2F97CA36-8A17-4E3E-A8DF-E59F9A6464A0@sun.com> References: <1236622538.2239.867.camel@localhost.localdomain> <9DE26A3F-F27B-4ADD-A33E-B15EA0C37233@sun.com> <1236624077.2239.873.camel@localhost.localdomain> <15D07FC0-4D0E-4234-8CFC-0C16A64ACA7E@Sun.COM> <2F97CA36-8A17-4E3E-A8DF-E59F9A6464A0@sun.com> Message-ID: <1236626610.2239.880.camel@localhost.localdomain> On Mon, 2009-03-09 at 12:09 -0700, John Rose wrote: > On Mar 9, 2009, at 11:53 AM, Tom Rodriguez wrote: > > >> I see. Sounds like too much work and possible problems for such a > >> small > >> (probably not very often applied) optimization. Should I drop it? > > > > I think the bang for the buck is low to change it at the ideal > > level. Can't this be addressed in the ad files? The adds to deal > > with endianness will get hidden in the encoding so it won't effect > > alias analysis. > > We tried shortening 64- to 32-bit loads once, and we backed off. > IIRC, there was an interaction with copy coalescing or some other post- > match logic. I looked in the old teamware histories, but couldn't > find evidence of it, so it's just a hazy memory of years ago. > > Load shortening might make sense very late, after register allocation, > near post-allocation copy removal. At that point, you should be able > to alter offsets also, so you are not limited just to the word or byte > which happens to come first in the CPU's endian order. Well, to me anything sounds nicer than writing a bunch of AD instructs for every architecture, as the code boils down to existing instructs anyway. Of course I don't know where "that point" is and what I can do there :-) -- Christian From Thomas.Rodriguez at Sun.COM Mon Mar 9 12:28:24 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 09 Mar 2009 12:28:24 -0700 Subject: Request for reviews (S): 6814842: Load shortening optimizations In-Reply-To: <2F97CA36-8A17-4E3E-A8DF-E59F9A6464A0@sun.com> References: <1236622538.2239.867.camel@localhost.localdomain> <9DE26A3F-F27B-4ADD-A33E-B15EA0C37233@sun.com> <1236624077.2239.873.camel@localhost.localdomain> <15D07FC0-4D0E-4234-8CFC-0C16A64ACA7E@Sun.COM> <2F97CA36-8A17-4E3E-A8DF-E59F9A6464A0@sun.com> Message-ID: <93232D9C-9DAC-44BB-A00B-A66E0E4E6DA2@Sun.COM> >> I think the bang for the buck is low to change it at the ideal >> level. Can't this be addressed in the ad files? The adds to deal >> with endianness will get hidden in the encoding so it won't effect >> alias analysis. > > We tried shortening 64- to 32-bit loads once, and we backed off. > IIRC, there was an interaction with copy coalescing or some other > post-match logic. I looked in the old teamware histories, but > couldn't find evidence of it, so it's just a hazy memory of years ago. I can't see how it would interact with copy coalescing. It will screw anti-dep computations since stores to it and loads from it would be in different alias classes if the offset was exposed in the AddP expression. A shortening load and a store to the same location could be incorrectly scheduled because they would appear unrelated. I remember seeing a comment to that effect somewhere though I can't find it now. Actually you have to go back a bit to find it. From an older workspace: // Fold up with a prior LoadL: LoadL->ConvL2I ==> LoadI // Requires we understand the 'endianess' of Longs. if( andl_op == Op_LoadL ) { Node *adr = andl->in(MemNode::Address); // VM_LITTLE_ENDIAN is #defined appropriately in the Makefiles #ifndef VM_LITTLE_ENDIAN // The transformation can cause problems on BIG_ENDIAN architectures // where the jint is not the same address as the jlong. Specifically, we // will fail to insert an anti-dependence in GCM between the LoadI and a // subsequent StoreL because different memory offsets provoke // flatten_alias_type() into indicating two different types. See bug // 4755222. // Node *base = adr->is_AddP() ? adr->in(AddPNode::Base) : adr; // adr = phase->transform( new (phase->C, 4) AddPNode(base,adr,phase->MakeConX(sizeof(jint)))); return NULL; #else if (phase->C->alias_type(andl->adr_type())->is_volatile()) { // Picking up the low half by itself bypasses the atomic load and we could // end up with more than one non-atomic load. See bugs 4432655 and 4526490. // We could go to the trouble of iterating over andl's output edges and // punting only if there's more than one real use, but we don't bother. return NULL; } return new (phase->C, 3) LoadINode(andl- >in(MemNode::Control),andl->in(MemNode::Memory),adr, ((LoadLNode*)andl)->raw_adr_type()); #endif } In current builds this whole thing has been replaced with: // Disable optimization: LoadL->ConvL2I ==> LoadI. // It causes problems (sizes of Load and Store nodes do not match) // in objects initialization code and Escape Analysis. At the ideal level there's also the problem that the store_OpCode() method will no longer work match which is part of what's being referred to in the above comment I think. I suspect we could use an assert in the alias idx computation logic to barf if it sees offsets in the middle an existing field. > Load shortening might make sense very late, after register > allocation, near post-allocation copy removal. At that point, you > should be able to alter offsets also, so you are not limited just to > the word or byte which happens to come first in the CPU's endian > order. Doing it in the ad should be sufficient for hiding them. The offset would only be in the encoding and it's not possible to look inside the encoding. tom > -- John From Thomas.Rodriguez at Sun.COM Mon Mar 9 12:56:15 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 09 Mar 2009 12:56:15 -0700 Subject: Request for reviews (S): 6814842: Load shortening optimizations In-Reply-To: <1236626610.2239.880.camel@localhost.localdomain> References: <1236622538.2239.867.camel@localhost.localdomain> <9DE26A3F-F27B-4ADD-A33E-B15EA0C37233@sun.com> <1236624077.2239.873.camel@localhost.localdomain> <15D07FC0-4D0E-4234-8CFC-0C16A64ACA7E@Sun.COM> <2F97CA36-8A17-4E3E-A8DF-E59F9A6464A0@sun.com> <1236626610.2239.880.camel@localhost.localdomain> Message-ID: <6135256A-6222-4548-9C5C-530AC202E383@sun.com> >> Load shortening might make sense very late, after register >> allocation, >> near post-allocation copy removal. At that point, you should be able >> to alter offsets also, so you are not limited just to the word or >> byte >> which happens to come first in the CPU's endian order. > > Well, to me anything sounds nicer than writing a bunch of AD instructs > for every architecture, as the code boils down to existing instructs > anyway. Of course I don't know where "that point" is and what I can > do > there :-) The adlc does tend for more verboseness than I would really like. If there was more uniformity between declarations in our ad files I could imagine a shared ad file that would capture some of these special matches at a high level and rely either on well known expand rules or ins_encodings to do the final code emission though we might run up against type problems. In some cases it would be useful if a single instruct definition could include mutiple match rules though in that case you run into issues with type mismatches since some might use RegI and others RegL. If we could figure out a syntax for that I don't think it wouldn't be hard to implement at the bottom by just making variants of the original MachNode the way we do for commutative ops. Maybe if it were possible to declare instructs without specifying the register type and have the type be inferred from the types in the match rule we could write that cleanly. In general it would be good if the adlc understood the real types of the nodes in the graph at least so it could complain about mismatches. If it could use that to find the real operands to use would could write something more compact. Alternatively we could just make up a placeholder syntax for it. Maybe something like: instruct loadUB( dst, memory mem) %{ match(Set dst (LoadUB mem)); match(Set dst (ConvI2L (LoadUB mem))); ... %} This doesn't help with the load shortening on all platforms since some will need extra offsets to deal with endianness but if the encoding and format were the same you could use the same thing. > > > -- Christian > From Christian.Thalinger at Sun.COM Mon Mar 9 14:00:55 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 09 Mar 2009 22:00:55 +0100 Subject: Request for reviews (S): 6814842: Load shortening optimizations In-Reply-To: <6135256A-6222-4548-9C5C-530AC202E383@sun.com> References: <1236622538.2239.867.camel@localhost.localdomain> <9DE26A3F-F27B-4ADD-A33E-B15EA0C37233@sun.com> <1236624077.2239.873.camel@localhost.localdomain> <15D07FC0-4D0E-4234-8CFC-0C16A64ACA7E@Sun.COM> <2F97CA36-8A17-4E3E-A8DF-E59F9A6464A0@sun.com> <1236626610.2239.880.camel@localhost.localdomain> <6135256A-6222-4548-9C5C-530AC202E383@sun.com> Message-ID: <1236632455.2239.889.camel@localhost.localdomain> On Mon, 2009-03-09 at 12:56 -0700, Tom Rodriguez wrote: > The adlc does tend for more verboseness than I would really like. If > there was more uniformity between declarations in our ad files I could > imagine a shared ad file that would capture some of these special > matches at a high level and rely either on well known expand rules or > ins_encodings to do the final code emission though we might run up > against type problems. > > In some cases it would be useful if a single instruct definition could > include mutiple match rules though in that case you run into issues > with type mismatches since some might use RegI and others RegL. If we > could figure out a syntax for that I don't think it wouldn't be hard > to implement at the bottom by just making variants of the original > MachNode the way we do for commutative ops. > > Maybe if it were possible to declare instructs without specifying the > register type and have the type be inferred from the types in the > match rule we could write that cleanly. In general it would be good > if the adlc understood the real types of the nodes in the graph at > least so it could complain about mismatches. If it could use that to > find the real operands to use would could write something more > compact. Alternatively we could just make up a placeholder syntax for > it. Maybe something like: > > instruct loadUB( dst, memory mem) %{ > match(Set dst (LoadUB mem)); > match(Set dst (ConvI2L (LoadUB mem))); > > ... > %} > > This doesn't help with the load shortening on all platforms since some > will need extra offsets to deal with endianness but if the encoding > and format were the same you could use the same thing. That sounds like a really good idea. Having more than one match rule in an instruct would definitely help. I know very little about ADLC yet, but if there is time and need to enhance it, I'd volunteer to do that. -- Christian From Christian.Thalinger at Sun.COM Tue Mar 10 05:08:35 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 10 Mar 2009 13:08:35 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> Message-ID: <1236686915.2239.892.camel@localhost.localdomain> On Tue, 2009-03-03 at 09:56 -0800, Tom Rodriguez wrote: > > 2. What about adding load and store assembler instruction like on x86 > > with an Address argument, e.g. > > > > inline void lduw(Address a, Register d); > > We could, though fixing that along with what you are doing seems like > loading more than want into your change. I'd leave the sparc > encodings along for now and we can fix it later to support the Address > stuff. For the load shortening changes I'm currently doing it would be useful to have these. Can I add them under a new CR? -- Christian From Christian.Thalinger at Sun.COM Tue Mar 10 10:13:33 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 10 Mar 2009 18:13:33 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236686915.2239.892.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> Message-ID: <1236705213.2239.899.camel@localhost.localdomain> On Tue, 2009-03-10 at 13:08 +0100, Christian Thalinger wrote: > On Tue, 2009-03-03 at 09:56 -0800, Tom Rodriguez wrote: > > > 2. What about adding load and store assembler instruction like on x86 > > > with an Address argument, e.g. > > > > > > inline void lduw(Address a, Register d); > > > > We could, though fixing that along with what you are doing seems like > > loading more than want into your change. I'd leave the sparc > > encodings along for now and we can fix it later to support the Address > > stuff. > > For the load shortening changes I'm currently doing it would be useful > to have these. Can I add them under a new CR? ...at least I think this is the right way to get rid of stuff like: //%%% form3_mem_plus_4_reg is a hack--get rid of it enc_class form3_mem_plus_4_reg( memory mem, iRegI dst ) %{ guarantee($mem$$disp, "cannot offset a reg-reg operand by 4"); emit_form3_mem_reg(cbuf, this, $primary, -1, $mem$$base, $mem$$disp + 4, $mem$$index, $dst$$reg); %} But maybe there is another, better way that I don't know of. -- Christian From John.Rose at Sun.COM Tue Mar 10 10:26:21 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 10 Mar 2009 10:26:21 -0700 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236686915.2239.892.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> Message-ID: On Mar 10, 2009, at 5:08 AM, Christian Thalinger wrote: > For the load shortening changes I'm currently doing it would be useful > to have these. Can I add them under a new CR? There is something like that already in assembler_sparc.hpp: inline void lduw( const Address& a, Register d, int offset = 0 ); I thought you were talking about making Address easier to use...? If you just want to add a +4 offset, you can use the optional offset argument above. If you want to fold the offset into the Address itself, use Address::plus_disp (which is new). -- John From Christian.Thalinger at Sun.COM Tue Mar 10 10:46:17 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 10 Mar 2009 18:46:17 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> Message-ID: <1236707177.2239.904.camel@localhost.localdomain> On Tue, 2009-03-10 at 10:26 -0700, John Rose wrote: > On Mar 10, 2009, at 5:08 AM, Christian Thalinger wrote: > > > For the load shortening changes I'm currently doing it would be useful > > to have these. Can I add them under a new CR? > > There is something like that already in assembler_sparc.hpp: > inline void lduw( const Address& a, Register d, int offset = 0 ); > > I thought you were talking about making Address easier to use...? Right, and I didn't know if that is the same as on x86, is it? I was a bit confused because of the relocate() call. And do these functions handle reg-reg loads properly too? > If you just want to add a +4 offset, you can use the optional offset > argument above. Sounds good. > If you want to fold the offset into the Address itself, use > Address::plus_disp (which is new). Sounds good too. I will have a try. -- Christian From Peter.Kessler at Sun.COM Tue Mar 10 11:11:03 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Tue, 10 Mar 2009 11:11:03 -0700 Subject: Tradeoffs around Node::Opcode()? Message-ID: <49B6AD37.4060600@Sun.COM> A lot of things in class Node are organized around having a dense integer range to identify the Node. That's Node::Opcode(). I'm wondering about the engineering around that method. Node::Opcode() is a virtual call, to get from a Node instance to a piece of data on the Node subclass of the instance. An alternative would be to add a data field in Node to hold the opcode, and replace the virtual Node::Opcode() calls with an inline method to return the contents of that slot. That trades the virtual dispatch cost for each call with a space cost in each instance. Does anyone have any feeling about whether that's a good tradeoff? How often is Node::Opcode() called? What effect would it have to make it run faster? How important is it to minimize the size of Node instances? (There are other places where effort is expended to keep Node's small.) Thanks for any opinions on this. ... peter From Vladimir.Kozlov at Sun.COM Tue Mar 10 11:14:34 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 10 Mar 2009 11:14:34 -0700 Subject: Tradeoffs around Node::Opcode()? In-Reply-To: <49B6AD37.4060600@Sun.COM> References: <49B6AD37.4060600@Sun.COM> Message-ID: <49B6AE0A.8090302@sun.com> Peter, There is already such functionality exactly for such purpose. The field is jushort _class_id; which use enum NodeClasses and initializer in the constructors init_class_id(). Vladimir Peter B. Kessler wrote: > A lot of things in class Node are organized around having a dense > integer range to identify the Node. That's Node::Opcode(). > > I'm wondering about the engineering around that method. Node::Opcode() > is a virtual call, to get from a Node instance to a piece of data on the > Node subclass of the instance. An alternative would be to add a data > field in Node to hold the opcode, and replace the virtual Node::Opcode() > calls with an inline method to return the contents of that slot. That > trades the virtual dispatch cost for each call with a space cost in each > instance. > > Does anyone have any feeling about whether that's a good tradeoff? How > often is Node::Opcode() called? What effect would it have to make it > run faster? How important is it to minimize the size of Node > instances? (There are other places where effort is expended to keep > Node's small.) > > Thanks for any opinions on this. > > ... peter From John.Rose at Sun.COM Tue Mar 10 11:40:15 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 10 Mar 2009 11:40:15 -0700 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236707177.2239.904.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> <1236707177.2239.904.camel@localhost.localdomain> Message-ID: <086E4BBF-3EA8-4BE0-B10B-DD74C7C8F23B@Sun.COM> The sparc design for Address differs from x86 because there is no way to put a full-word displacement in, so there has to be provision for sethi, either automagically in a macro, or separately managed. The relocation provides consistency between the sethi and the simm13 field. The two disp fields provide support for (a) the sethi/simm13 usage, and (b) the actual simm13 field itself. The sparc Address is two things, a syntax for rs1+simm13, and (more usefully) a way for managing part of what Intel calls addresses (but not scaling and double register modes). With x64 we have a situation similar to sparc, since full 64-bit words don't fit into the addressing modes. (Except for the special case of lea, which requires a temp, much like sparc. See rscratch1 all over assembler_x86.cpp.) Steve G. split out AddressLiteral as a way of expressing a possible multi-instruction addressing mode. My new RegisterConstant stuff provides a way to build up address expressions by parts, emitting code only when necessary. The risc way, of course, is to build addressing modes with multiple instructions as necessary, while the Intel way is to have a powerful set of HW-supported addressing modes, which we express by Address. This frays a little around the edges when we get to x64. Maybe SPARC needs to change Address to rs1+{rs2,simm13} (i.e., Register, RegisterConstant) and have a new AddressLiteral subtype that manages the multi-instruction use cases. Not sure how to rationalize all this into correspondence, except by improving bit by bit as improvements occur to us. -- John On Mar 10, 2009, at 10:46 AM, Christian Thalinger wrote: > Right, and I didn't know if that is the same as on x86, is it? I > was a > bit confused because of the relocate() call. From Peter.Kessler at Sun.COM Tue Mar 10 12:11:32 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Tue, 10 Mar 2009 12:11:32 -0700 Subject: Tradeoffs around Node::Opcode()? In-Reply-To: <49B6AE0A.8090302@sun.com> References: <49B6AD37.4060600@Sun.COM> <49B6AE0A.8090302@sun.com> Message-ID: <49B6BB64.1080003@Sun.COM> Cool! Thanks. So much for engineering: we already have *both* the virtual dispatch *and* the data slot per instance. Oh, but those are only the class id's (e.g., Add), rather than the opcode (e.g., AddI). It's confusing that they are both referred to as Node "classes", e.g., in classes.hpp, opcodes.cpp, etc. So I guess that begs the question: why *isn't* there an _opcode field, initialized in the constructors, like (or instead of) _class_id? Why aren't the leaf classes (AddI, etc.) in the _class_id maps? (Other than that the _class_id maps want to fit in a jushort. :-) Couldn't one map (e.g., with a table) from an opcode to a _class_id, if one wanted to spend the time as opposed to the space? Would an inline method to access a _class_id table be faster than a virtual dispatch to Opcode()? A possible answer as to why it is the way it is: "History". I'm still trying to understand the tradeoffs between space and time. ... peter Vladimir Kozlov wrote: > Peter, > > There is already such functionality exactly for such purpose. > The field is jushort _class_id; which use enum NodeClasses > and initializer in the constructors init_class_id(). > > Vladimir > > Peter B. Kessler wrote: >> A lot of things in class Node are organized around having a dense >> integer range to identify the Node. That's Node::Opcode(). >> >> I'm wondering about the engineering around that method. >> Node::Opcode() is a virtual call, to get from a Node instance to a >> piece of data on the Node subclass of the instance. An alternative >> would be to add a data field in Node to hold the opcode, and replace >> the virtual Node::Opcode() calls with an inline method to return the >> contents of that slot. That trades the virtual dispatch cost for each >> call with a space cost in each instance. >> >> Does anyone have any feeling about whether that's a good tradeoff? >> How often is Node::Opcode() called? What effect would it have to make >> it run faster? How important is it to minimize the size of Node >> instances? (There are other places where effort is expended to keep >> Node's small.) >> >> Thanks for any opinions on this. >> >> ... peter From vladimir.kozlov at sun.com Tue Mar 10 12:23:56 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 10 Mar 2009 19:23:56 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 14 new changesets Message-ID: <20090310192422.69DD0EC35@hg.openjdk.java.net> Changeset: 0386097d43d8 Author: dcubed Date: 2009-03-02 13:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0386097d43d8 6700114: 3/4 Assertion (_thread->get_interp_only_mode() == 1,"leaving interp only when mode not one") Summary: Don't create JvmtiThreadState for an exiting JavaThread. Reviewed-by: coleenp, swamyv ! src/share/vm/prims/jvmtiThreadState.hpp Changeset: ea20d7ce26b0 Author: dcubed Date: 2009-03-02 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ea20d7ce26b0 6800721: 3/4 JavaThread::jvmti_thread_state() and JvmtiThreadState::state_for() robustness Summary: Check for NULL return values from jvmti_thread_state() and state_for() and return a JVM TI error code as appropriate. Reviewed-by: coleenp, swamyv ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/runtime/thread.hpp Changeset: 70998f2e05ef Author: dcubed Date: 2009-03-02 14:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/70998f2e05ef 6805864: 4/3 Problem with jvmti->redefineClasses: some methods don't get redefined Summary: Remove incorrect optimization in klassItable::adjust_method_entries(). Add RedefineClasses() tracing support for obsolete method entry. Reviewed-by: acorn, swamyv ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/includeDB_core ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 2f716c0acb64 Author: dcubed Date: 2009-03-02 14:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2f716c0acb64 6567360: 3/4 SIGBUS in jvmti RawMonitor magic check for unaligned bad monitor pointer Summary: Change JvmtiEnvBase::is_valid() and JvmtiRawMonitor::is_valid() to fetch the _magic fields via Bytes::get_native_u[248](). Reviewed-by: coleenp, swamyv ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp Changeset: afa80fa86d22 Author: dcubed Date: 2009-03-02 14:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/afa80fa86d22 Merge ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/includeDB_core ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 5caef2219893 Author: dcubed Date: 2009-03-02 16:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5caef2219893 Merge ! src/share/vm/includeDB_core Changeset: 3db67f76d308 Author: acorn Date: 2009-03-05 22:07 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3db67f76d308 Merge ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/includeDB_core ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: c6c601a0f2d6 Author: ysr Date: 2009-03-02 16:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c6c601a0f2d6 6797870: Add -XX:+{HeapDump,PrintClassHistogram}{Before,After}FullGC Summary: Call newly created CollectedHeap::dump_{pre,post}_full_gc before and after every stop-world full collection cycle on GenCollectedHeap and ParallelScavengeHeap. (Support for G1CollectedHeap forthcoming under CR 6810861.) Small modifications to existing heap dumping and class histogram implementation, especially to allow multiple on-the-fly histos/dumps by the VM thread during a single safepoint. Reviewed-by: jmasa, alanb, mchung ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_gc ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/heapDumper.hpp Changeset: 4f360ec815ba Author: iveresov Date: 2009-03-06 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4f360ec815ba 6720309: G1: don't synchronously update RSet during evacuation pauses 6720334: G1: don't update RSets of collection set regions during an evacuation pause Summary: Introduced a deferred update mechanism for delaying the rset updates during the collection pause Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 0db4adb6e914 Author: tonyp Date: 2009-03-07 11:07 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0db4adb6e914 6810698: G1: two small bugs in the sparse remembered sets Summary: The _expanded flag of the sparse RSets is not reset and this can leave a RSet in an inconsistent state if it is expanded more than once. Also, we should be iterating over the _cur, instead of the _next, sparse table Reviewed-by: apetrusenko, iveresov ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: ae1579717a57 Author: tonyp Date: 2009-03-07 11:07 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ae1579717a57 6812428: G1: Error: assert(ret || obj_in_cs(obj),"sanity") Summary: The length of the fast cset test vector is decided at the beginning of a GC, but more regions can be added during the GC. The simple fix is to set the length of the fast cset test vector to the max. Reviewed-by: iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 7ea5ca260b28 Author: tonyp Date: 2009-03-07 11:07 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7ea5ca260b28 6814467: G1: small fixes related to concurrent marking verboseness Summary: A few small fixes to remove some inconsistencies in the concurrent mark-related verbose GC output. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: bcedf688d882 Author: tonyp Date: 2009-03-09 11:32 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bcedf688d882 Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/os.cpp Changeset: 2f2f54ed12ce Author: kvn Date: 2009-03-10 08:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2f2f54ed12ce Merge ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp From Vladimir.Kozlov at Sun.COM Tue Mar 10 14:22:06 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 10 Mar 2009 14:22:06 -0700 Subject: Tradeoffs around Node::Opcode()? In-Reply-To: <49B6BB64.1080003@Sun.COM> References: <49B6AD37.4060600@Sun.COM> <49B6AE0A.8090302@sun.com> <49B6BB64.1080003@Sun.COM> Message-ID: <49B6D9FE.40700@sun.com> Yes, it is history :) The _opcode field will not work since subclasses will overwrite it. The _class_id field is not direct map to Opcode, it is bitmap: n->is_SafePoint() will be true for all ideal Call and SafePoint nodes, but n->Opcode() == Op_SafePoint only true for SafePointNode. So we need both. And yes, I want to fit in a jushort :-) When I did implementation of _class_id I was also concern about increasing Node size significantly so I decided to add only 4 bytes: 2 for class_id and 2 for flags. I also did profiling of Opcode() usage. So only hottest Opcode() calls were replaced with class_id code. Adding other nodes did not improve performance. Vladimir Peter B. Kessler wrote: > Cool! Thanks. So much for engineering: we already have *both* the > virtual dispatch *and* the data slot per instance. > > Oh, but those are only the class id's (e.g., Add), rather than the > opcode (e.g., AddI). It's confusing that they are both referred to as > Node "classes", e.g., in classes.hpp, opcodes.cpp, etc. > > So I guess that begs the question: why *isn't* there an _opcode field, > initialized in the constructors, like (or instead of) _class_id? Why > aren't the leaf classes (AddI, etc.) in the _class_id maps? (Other than > that the _class_id maps want to fit in a jushort. :-) Couldn't one map > (e.g., with a table) from an opcode to a _class_id, if one wanted to > spend the time as opposed to the space? Would an inline method to > access a _class_id table be faster than a virtual dispatch to Opcode()? > > A possible answer as to why it is the way it is: "History". > > I'm still trying to understand the tradeoffs between space and time. > > ... peter > > Vladimir Kozlov wrote: >> Peter, >> >> There is already such functionality exactly for such purpose. >> The field is jushort _class_id; which use enum NodeClasses >> and initializer in the constructors init_class_id(). >> >> Vladimir >> >> Peter B. Kessler wrote: >>> A lot of things in class Node are organized around having a dense >>> integer range to identify the Node. That's Node::Opcode(). >>> >>> I'm wondering about the engineering around that method. >>> Node::Opcode() is a virtual call, to get from a Node instance to a >>> piece of data on the Node subclass of the instance. An alternative >>> would be to add a data field in Node to hold the opcode, and replace >>> the virtual Node::Opcode() calls with an inline method to return the >>> contents of that slot. That trades the virtual dispatch cost for >>> each call with a space cost in each instance. >>> >>> Does anyone have any feeling about whether that's a good tradeoff? >>> How often is Node::Opcode() called? What effect would it have to >>> make it run faster? How important is it to minimize the size of Node >>> instances? (There are other places where effort is expended to keep >>> Node's small.) >>> >>> Thanks for any opinions on this. >>> >>> ... peter > From John.Rose at Sun.COM Tue Mar 10 15:48:02 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 10 Mar 2009 15:48:02 -0700 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> Message-ID: Thanks for the reviews so far. I've posted the remainder of meth.patch here: 6655638: dynamic languages need method handles http://cr.openjdk.java.net/~jrose/6655638/webrev.00/ (not yet integrated) (Long live cr.OJN! Goodbye webrev.invokedynamic.info.) Later today (probably) I will update the index page to have useful comments about how each file is changed. After responding to any further reviewer comments, I'll push the results. Because it's a large body of code, and it will help to have a record of what we do, let's keep review comments public. If the comments lead to large changes, I may have to ask for a re- review. If that happens, I'll publish at least a diff of webrev.N to webrev.N+1, maybe even a 2nd-order webrev, if I can figure out how. About self-review: I will be reviewing my own code, too, and if the review period is long enough, may wish to make amendments. I'll email a public comment if this seems necessary. (I've "discovered" that people don't like it when they encounter unexplained changes mid- review.) Meanwhile, I'm working on the same code that's being reviewed. For big reviews like this one, I'll try to keep separate workspaces for review and further engineering. (I wouldn't attempt this without hg/ MQ and Emacs diff-mode.) Therefore, if a review takes a long time (which this one has) it may be followed immediately by a second review cycle with a new bug ID, to push the adjustments separately. In fact, I'll allocate the bug ID now: 6815692: method handle code needs some cleanup (post-6655638) http://cr.openjdk.java.net/~jrose/6815692/webrev.00/ (not yet posted) As that settles down I will be asking for reviews on this next step: 6655646: dynamic languages need dynamically linked call sites http://cr.openjdk.java.net/~jrose/6655646/webrev.00/ (not yet posted) After that, there will be individual pushes for additional assembly code (x64 and/or sparc), compiler optimizations (2-3 steps there), and various smaller things like compressed oops and cppInterpreter support. And of course bug fixes and cleanups as needed. Onward! -- John On Jan 20, 2009, at 2:53 AM, John Rose wrote: > This is part of the JVM side of the JSR 292 Reference > Implementation. It should have no effect on application execution, > unless one of the new flags is turned on (chiefly -XX: > +MethodHandleSupport). > > Present limitations: > - It works only on x86/32. (No sparc, compressed oops, cpp > interpreter.) > - There are no compiler optimizations. > - It is young code. There are bugs. But only when a new flag is > turned on. > > This review is for contents of meth.patch, to be pushed from mlvm to http://hg.openjdk.java.net/jdk7/hotspot-comp-gate/hotspot > . > > Here is the webrev for this review: > http://webrev.invokedynamic.info/jrose/6655638.meth/ > > Here is the mlvm patch where the code currently lives: > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/tip/meth.patch > > An earlier version of these changes pass JPRT; it is expected that > at most minor tweaks will be needed to push it through again. > > Even though they are large, the changes should also pass a simple > visual inspection, since all substantially new control paths are > guarded by tests of the new flags. > > Please give it a look. > > -- John > > P.S. Here are some relevant conversations about method handles and > invokedynamic: > http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000321.html > http://blogs.sun.com/jrose/entry/international_invokedynamic_day > http://blogs.sun.com/dannycoward/entry/firing_up_the_engines_for > http://groups.google.com/group/jvm-languages/browse_thread/thread/a4b8a616eb987ca8 > > P.P.S. The proposed JDK changes are independent. At present, you > can find them here, in patch and webrev formats: > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/tip/meth.proj.patch > http://webrev.invokedynamic.info/jrose/6655638.meth.proj/ From Peter.Kessler at Sun.COM Tue Mar 10 17:14:02 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Tue, 10 Mar 2009 17:14:02 -0700 Subject: Tradeoffs around Node::Opcode()? In-Reply-To: <49B6D9FE.40700@sun.com> References: <49B6AD37.4060600@Sun.COM> <49B6AE0A.8090302@sun.com> <49B6BB64.1080003@Sun.COM> <49B6D9FE.40700@sun.com> Message-ID: <49B7024A.3000608@Sun.COM> Thanks for the answers. The _class_id field is extremely dense. It's sort of like a tree path (left or right child, and then a sibling count), but different. I like the idea of putting all the details about a class in the constructor for that class. I didn't understand why you say that a subclass would overwrite an _opcode field. If each AddI constructor initializes my proposed (const?) _opcode field in Node to Op_AddI, and if AddF initializes the _opcode field to Op_AddF, then who would overwrite it? Obviously node instances can't change their opcodes, or we wouldn't be able to use a virtual function for Opcode() now, unless we change the vtable for instances. Then there could be a map from Opcodes to what's now in _class_id and _flags. E.g., there would be a _class_id table someplace whose Op_AddI entry would contain Class_Add. As would the Op_AddF entry. But the Op_AddP index would would contain Class_AddP. Do the _flags fields change over the life of a Node instance? Or could those also be in a map indexed by Opcode? (Having separate maps from Opcode to other properties of the Node means that information about the Node subclass isn't visible in text of the subclass constructor. Sigh.) I hear from Chris Vick that making the edges between the nodes bi-directional, which increased the size of the Node instances, didn't have any noticeable effect on the space used collectively by the nodes during a compilation, and didn't have any effect on the speed of the compiler, except maybe to speed it up because traversals that used to be hard with one-way edges became easier with bi-directional edges. ... peter Vladimir Kozlov wrote: > Yes, it is history :) > > The _opcode field will not work since subclasses will overwrite it. > > The _class_id field is not direct map to Opcode, it is bitmap: > n->is_SafePoint() will be true for all ideal Call and SafePoint nodes, > but n->Opcode() == Op_SafePoint only true for SafePointNode. > So we need both. > > And yes, I want to fit in a jushort :-) > When I did implementation of _class_id I was also concern about > increasing Node size significantly so I decided to add only 4 bytes: > 2 for class_id and 2 for flags. > > I also did profiling of Opcode() usage. So only hottest Opcode() > calls were replaced with class_id code. Adding other nodes did not > improve performance. > > Vladimir > > Peter B. Kessler wrote: >> Cool! Thanks. So much for engineering: we already have *both* the >> virtual dispatch *and* the data slot per instance. >> >> Oh, but those are only the class id's (e.g., Add), rather than the >> opcode (e.g., AddI). It's confusing that they are both referred to as >> Node "classes", e.g., in classes.hpp, opcodes.cpp, etc. >> >> So I guess that begs the question: why *isn't* there an _opcode field, >> initialized in the constructors, like (or instead of) _class_id? Why >> aren't the leaf classes (AddI, etc.) in the _class_id maps? (Other >> than that the _class_id maps want to fit in a jushort. :-) Couldn't >> one map (e.g., with a table) from an opcode to a _class_id, if one >> wanted to spend the time as opposed to the space? Would an inline >> method to access a _class_id table be faster than a virtual dispatch >> to Opcode()? >> >> A possible answer as to why it is the way it is: "History". >> >> I'm still trying to understand the tradeoffs between space and time. >> >> ... peter >> >> Vladimir Kozlov wrote: >>> Peter, >>> >>> There is already such functionality exactly for such purpose. >>> The field is jushort _class_id; which use enum NodeClasses >>> and initializer in the constructors init_class_id(). >>> >>> Vladimir >>> >>> Peter B. Kessler wrote: >>>> A lot of things in class Node are organized around having a dense >>>> integer range to identify the Node. That's Node::Opcode(). >>>> >>>> I'm wondering about the engineering around that method. >>>> Node::Opcode() is a virtual call, to get from a Node instance to a >>>> piece of data on the Node subclass of the instance. An alternative >>>> would be to add a data field in Node to hold the opcode, and replace >>>> the virtual Node::Opcode() calls with an inline method to return the >>>> contents of that slot. That trades the virtual dispatch cost for >>>> each call with a space cost in each instance. >>>> >>>> Does anyone have any feeling about whether that's a good tradeoff? >>>> How often is Node::Opcode() called? What effect would it have to >>>> make it run faster? How important is it to minimize the size of >>>> Node instances? (There are other places where effort is expended to >>>> keep Node's small.) >>>> >>>> Thanks for any opinions on this. >>>> >>>> ... peter >> From Vladimir.Kozlov at Sun.COM Tue Mar 10 17:53:59 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 10 Mar 2009 17:53:59 -0700 Subject: Tradeoffs around Node::Opcode()? In-Reply-To: <49B7024A.3000608@Sun.COM> References: <49B6AD37.4060600@Sun.COM> <49B6AE0A.8090302@sun.com> <49B6BB64.1080003@Sun.COM> <49B6D9FE.40700@sun.com> <49B7024A.3000608@Sun.COM> Message-ID: <49B70BA7.2030008@sun.com> Peter, if you wish to add an additional field into Node you may instead extend _class_id field to 4 bytes to cover all classes and use it (n->class_id() == Node::Class_SafePoint) instead of (n->Opcode() == Op_SafePoint) Sorry, I forgot to mention that class_id can work as Opcode() also. The problems with this are, first, maintenance - you need to add several lines in node.hpp instead of one line in classes.hpp for each node, and, second, 32 bits could be not enough for all classes. I agree that it would be nice to remove virtual Opcode() method. Peter B. Kessler wrote: > Thanks for the answers. > > I didn't understand why you say that a subclass would overwrite an > _opcode field. If each AddI constructor initializes my proposed > (const?) _opcode field in Node to Op_AddI, and if AddF initializes the > _opcode field to Op_AddF, then who would overwrite it? Obviously node > instances can't change their opcodes, or we wouldn't be able to use a > virtual function for Opcode() now, unless we change the vtable for > instances. I meant super class and subclass, for example, Op_ConI will overwrite Op_Con: class ConNode : public TypeNode { public: ConNode( const Type *t ) : TypeNode(t,1) { init_req(0, (Node*)Compile::current()->root()); init_flags(Flag_is_Con); _opcode = Op_Con; } virtual int Opcode() const; ... class ConINode : public ConNode { public: ConINode( const TypeInt *t ) : ConNode(t) { _opcode = Op_ConI; } virtual int Opcode() const; > > Then there could be a map from Opcodes to what's now in _class_id and > _flags. E.g., there would be a _class_id table someplace whose Op_AddI > entry would contain Class_Add. As would the Op_AddF entry. But the > Op_AddP index would would contain Class_AddP. Do the _flags fields This approach requires 2 loads instead of current one to read _class_id. > change over the life of a Node instance? Or could those also be in a No, _flags field does not change over time. Vladimir > map indexed by Opcode? (Having separate maps from Opcode to other > properties of the Node means that information about the Node subclass > isn't visible in text of the subclass constructor. Sigh.) > > I hear from Chris Vick that making the edges between the nodes > bi-directional, which increased the size of the Node instances, didn't > have any noticeable effect on the space used collectively by the nodes > during a compilation, and didn't have any effect on the speed of the > compiler, except maybe to speed it up because traversals that used to be > hard with one-way edges became easier with bi-directional edges. > > ... peter > > Vladimir Kozlov wrote: >> Yes, it is history :) >> >> The _opcode field will not work since subclasses will overwrite it. >> >> The _class_id field is not direct map to Opcode, it is bitmap: >> n->is_SafePoint() will be true for all ideal Call and SafePoint nodes, >> but n->Opcode() == Op_SafePoint only true for SafePointNode. >> So we need both. >> >> And yes, I want to fit in a jushort :-) >> When I did implementation of _class_id I was also concern about >> increasing Node size significantly so I decided to add only 4 bytes: >> 2 for class_id and 2 for flags. >> >> I also did profiling of Opcode() usage. So only hottest Opcode() >> calls were replaced with class_id code. Adding other nodes did not >> improve performance. >> >> Vladimir >> >> Peter B. Kessler wrote: >>> Cool! Thanks. So much for engineering: we already have *both* the >>> virtual dispatch *and* the data slot per instance. >>> >>> Oh, but those are only the class id's (e.g., Add), rather than the >>> opcode (e.g., AddI). It's confusing that they are both referred to >>> as Node "classes", e.g., in classes.hpp, opcodes.cpp, etc. >>> >>> So I guess that begs the question: why *isn't* there an _opcode >>> field, initialized in the constructors, like (or instead of) >>> _class_id? Why aren't the leaf classes (AddI, etc.) in the _class_id >>> maps? (Other than that the _class_id maps want to fit in a jushort. >>> :-) Couldn't one map (e.g., with a table) from an opcode to a >>> _class_id, if one wanted to spend the time as opposed to the space? >>> Would an inline method to access a _class_id table be faster than a >>> virtual dispatch to Opcode()? >>> >>> A possible answer as to why it is the way it is: "History". >>> >>> I'm still trying to understand the tradeoffs between space and time. >>> >>> ... peter >>> >>> Vladimir Kozlov wrote: >>>> Peter, >>>> >>>> There is already such functionality exactly for such purpose. >>>> The field is jushort _class_id; which use enum NodeClasses >>>> and initializer in the constructors init_class_id(). >>>> >>>> Vladimir >>>> >>>> Peter B. Kessler wrote: >>>>> A lot of things in class Node are organized around having a dense >>>>> integer range to identify the Node. That's Node::Opcode(). >>>>> >>>>> I'm wondering about the engineering around that method. >>>>> Node::Opcode() is a virtual call, to get from a Node instance to a >>>>> piece of data on the Node subclass of the instance. An alternative >>>>> would be to add a data field in Node to hold the opcode, and >>>>> replace the virtual Node::Opcode() calls with an inline method to >>>>> return the contents of that slot. That trades the virtual dispatch >>>>> cost for each call with a space cost in each instance. >>>>> >>>>> Does anyone have any feeling about whether that's a good tradeoff? >>>>> How often is Node::Opcode() called? What effect would it have to >>>>> make it run faster? How important is it to minimize the size of >>>>> Node instances? (There are other places where effort is expended >>>>> to keep Node's small.) >>>>> >>>>> Thanks for any opinions on this. >>>>> >>>>> ... peter >>> > From Christian.Thalinger at Sun.COM Wed Mar 11 06:12:24 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 11 Mar 2009 14:12:24 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <086E4BBF-3EA8-4BE0-B10B-DD74C7C8F23B@Sun.COM> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> <1236707177.2239.904.camel@localhost.localdomain> <086E4BBF-3EA8-4BE0-B10B-DD74C7C8F23B@Sun.COM> Message-ID: <1236777144.2239.979.camel@localhost.localdomain> On Tue, 2009-03-10 at 11:40 -0700, John Rose wrote: > My new RegisterConstant stuff provides a way to build up address > expressions by parts, emitting code only when necessary. The risc > way, of course, is to build addressing modes with multiple > instructions as necessary, while the Intel way is to have a powerful > set of HW-supported addressing modes, which we express by Address. > This frays a little around the edges when we get to x64. > > Maybe SPARC needs to change Address to rs1+{rs2,simm13} (i.e., > Register, RegisterConstant) and have a new AddressLiteral subtype that > manages the multi-instruction use cases. > > Not sure how to rationalize all this into correspondence, except by > improving bit by bit as improvements occur to us. Maybe I missing something here, but would it be possible to have a: Address Address::make_raw(int base, int index, int scale, int disp, bool disp_is_oop) { function on SPARC too, so it's possible to use $mem$$Address in the AD file and let (Address src, Register dst)-signature functions decide which emit function to call? Furthermore we could assert on reg-reg forms that have a displacement set, which is obviously wrong. The only problem I see when using MacroAssembler instructions in sparc.ad is the VerifyOops check in emit_form3_mem_reg. Is that still used/necessary or can it be moved somewhere else? -- Christian From Christian.Thalinger at Sun.COM Wed Mar 11 10:46:15 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 11 Mar 2009 18:46:15 +0100 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> Message-ID: <1236793576.2239.1059.camel@localhost.localdomain> On Tue, 2009-03-10 at 15:48 -0700, John Rose wrote: > Thanks for the reviews so far. I've posted the remainder of > meth.patch here: > > 6655638: dynamic languages need method handles > http://cr.openjdk.java.net/~jrose/6655638/webrev.00/ (not yet > integrated) As always, I try to do a review. --- src/cpu/x86/vm/templateInterpreter_x86_32.cpp: - const int method_stack = (method->max_locals() + method->max_stack()) * + const int extra_stack = methodOopDesc::extra_stack(); + const int method_stack = (method->max_locals() + method->max_stack() + extra_stack) * Interpreter::stackElementWords(); - return overhead_size + method_stack + stub_code; + return overhead_size + method_stack + extra_stack + stub_code; Adding extra_stack a second time on return seems wrong. --- src/share/vm/runtime/globals.hpp: + product(bool, MethodHandleSupport, false, \ + "support method handles (true by default under JSR 292") \ Closing ) is missing in the description. --- src/share/vm/prims/methodHandles.cpp: 391 assert(methodOopDesc::invalid_vtable_index - 10 > VM_INDEX_UNINITIALIZED, "Java sentinel value"); At least to me it's not obvious why -10. 539 void MethodHandles::expand_MemberName(Handle mname, int suppress, TRAPS) { It seems suppress uses some hardcoded values. It would be better to use some defines or enum values. --- src/cpu/x86/vm/methodHandles_x86.cpp: 78 // rbx: methodOop 79 // rcx: receiver method handle (must load from sp[MethodTypeForm.vmslots]) 80 // rsi: sender SP (must preserve) 81 // rdx: garbage temp, blown away 82 83 Register rbx_method = rbx; 84 Register rcx_recv = rcx; 85 Register rax_mtype = rax; 86 Register rdx_temp = rdx; Seems the comments do not match the code, because rsi is not used in the code. --- One minor thing is that the copyright year is not updated in some (or all?) files. -- Christian From Thomas.Rodriguez at Sun.COM Wed Mar 11 10:53:20 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 11 Mar 2009 10:53:20 -0700 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236777144.2239.979.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> <1236707177.2239.904.camel@localhost.localdomain> <086E4BBF-3EA8-4BE0-B10B-DD74C7C8F23B@Sun.COM> <1236777144.2239.979.camel@localhost.localdomain> Message-ID: >> Not sure how to rationalize all this into correspondence, except by >> improving bit by bit as improvements occur to us. > > Maybe I missing something here, but would it be possible to have a: > > Address Address::make_raw(int base, int index, int scale, int disp, > bool disp_is_oop) { > > function on SPARC too, so it's possible to use $mem$$Address in the AD > file and let (Address src, Register dst)-signature functions decide > which emit function to call? Furthermore we could assert on reg-reg > forms that have a displacement set, which is obviously wrong. That what I was assuming we'd do. > The only problem I see when using MacroAssembler instructions in > sparc.ad is the VerifyOops check in emit_form3_mem_reg. Is that still > used/necessary or can it be moved somewhere else? I had no idea that sparc.ad even had support for VerifyOops. I'm not sure that logic that has to be preserved. It could be broken out separately as something that could be called from the ins_encode but I'm not really married to it. tom > > > -- Christian > From Christian.Thalinger at Sun.COM Wed Mar 11 11:01:59 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 11 Mar 2009 19:01:59 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> <1236707177.2239.904.camel@localhost.localdomain> <086E4BBF-3EA8-4BE0-B10B-DD74C7C8F23B@Sun.COM> <1236777144.2239.979.camel@localhost.localdomain> Message-ID: <1236794519.2239.1063.camel@localhost.localdomain> On Wed, 2009-03-11 at 10:53 -0700, Tom Rodriguez wrote: > >> Not sure how to rationalize all this into correspondence, except by > >> improving bit by bit as improvements occur to us. > > > > Maybe I missing something here, but would it be possible to have a: > > > > Address Address::make_raw(int base, int index, int scale, int disp, > > bool disp_is_oop) { > > > > function on SPARC too, so it's possible to use $mem$$Address in the AD > > file and let (Address src, Register dst)-signature functions decide > > which emit function to call? Furthermore we could assert on reg-reg > > forms that have a displacement set, which is obviously wrong. > > That what I was assuming we'd do. Should I go for it and post a webrev when I have something? > I had no idea that sparc.ad even had support for VerifyOops. I'm not > sure that logic that has to be preserved. It could be broken out > separately as something that could be called from the ins_encode but > I'm not really married to it. Hmm, it's in the repository since duke at 0. Anyone else who knows something about that? -- Christian From Thomas.Rodriguez at Sun.COM Wed Mar 11 13:35:34 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 11 Mar 2009 13:35:34 -0700 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236794519.2239.1063.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> <1236707177.2239.904.camel@localhost.localdomain> <086E4BBF-3EA8-4BE0-B10B-DD74C7C8F23B@Sun.COM> <1236777144.2239.979.camel@localhost.localdomain> <1236794519.2239.1063.camel@localhost.localdomain> Message-ID: > Should I go for it and post a webrev when I have something? Sure. >> I had no idea that sparc.ad even had support for VerifyOops. I'm not >> sure that logic that has to be preserved. It could be broken out >> separately as something that could be called from the ins_encode but >> I'm not really married to it. > > Hmm, it's in the repository since duke at 0. Anyone else who knows > something about that? I believe it's been there since the beginning, I'd just never noticed it. According to SCCS it goes back to 1998. tom > > > -- Christian > From John.Rose at Sun.COM Wed Mar 11 14:11:17 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 11 Mar 2009 14:11:17 -0700 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> <1236707177.2239.904.camel@localhost.localdomain> <086E4BBF-3EA8-4BE0-B10B-DD74C7C8F23B@Sun.COM> <1236777144.2239.979.camel@localhost.localdomain> <1236794519.2239.1063.camel@localhost.localdomain> Message-ID: On Mar 11, 2009, at 1:35 PM, Tom Rodriguez wrote: >> Hmm, it's in the repository since duke at 0. Anyone else who knows >> something about that? > > I believe it's been there since the beginning, I'd just never > noticed it. According to SCCS it goes back to 1998. I wrote it to help debug the sparc port. I don't think it has found many bugs since then. I suppose it could be retired, and resurrected easily enough if somebody wanted it. It certainly doesn't need to be in the AD file; it could be refactored (with some care) into assembler_sparc. -- John From Thomas.Rodriguez at Sun.COM Wed Mar 11 14:22:31 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 11 Mar 2009 14:22:31 -0700 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> <1236707177.2239.904.camel@localhost.localdomain> <086E4BBF-3EA8-4BE0-B10B-DD74C7C8F23B@Sun.COM> <1236777144.2239.979.camel@localhost.localdomain> <1236794519.2239.1063.camel@localhost.localdomain> Message-ID: On Mar 11, 2009, at 2:11 PM, John Rose wrote: > On Mar 11, 2009, at 1:35 PM, Tom Rodriguez wrote: > >>> Hmm, it's in the repository since duke at 0. Anyone else who knows >>> something about that? >> >> I believe it's been there since the beginning, I'd just never >> noticed it. According to SCCS it goes back to 1998. > > I wrote it to help debug the sparc port. I don't think it has found > many bugs since then. I suppose it could be retired, and > resurrected easily enough if somebody wanted it. It certainly > doesn't need to be in the AD file; it could be refactored (with some > care) into assembler_sparc. If we really wanted to support it would be nice to do so in a platform independent way. If it's good for one arch it's a good idea for all. tom > -- John From Christian.Thalinger at Sun.COM Wed Mar 11 16:43:22 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 11 Mar 2009 23:43:22 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6812587: Use auxv to determine SPARC hardware features on Solaris Message-ID: <20090311234331.18F0AECED@hg.openjdk.java.net> Changeset: 6af0a709d52b Author: twisti Date: 2009-03-11 14:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6af0a709d52b 6812587: Use auxv to determine SPARC hardware features on Solaris Summary: A similar function to getisax(2) should be used to determine all possible instruction set extensions. Reviewed-by: never, kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/includeDB_core From John.Rose at Sun.COM Wed Mar 11 18:13:29 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 11 Mar 2009 18:13:29 -0700 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> <1236707177.2239.904.camel@localhost.localdomain> <086E4BBF-3EA8-4BE0-B10B-DD74C7C8F23B@Sun.COM> <1236777144.2239.979.camel@localhost.localdomain> <1236794519.2239.1063.camel@localhost.localdomain> Message-ID: On Mar 11, 2009, at 2:22 PM, Tom Rodriguez wrote: > If we really wanted to support it would be nice to do so in a > platform independent way. If it's good for one arch it's a good > idea for all. True. It's not in the right place from that standpoint. Checks should be managed in output.cpp, or somewhere close to GC map generation. I don't object to nuking emit_form_foo. -- John From John.Rose at Sun.COM Wed Mar 11 19:04:27 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 11 Mar 2009 19:04:27 -0700 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236777144.2239.979.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> <1236707177.2239.904.camel@localhost.localdomain> <086E4BBF-3EA8-4BE0-B10B-DD74C7C8F23B@Sun.COM> <1236777144.2239.979.camel@localhost.localdomain> Message-ID: <6ED114A0-23F9-4B7D-B6D4-5B1DD9339B4D@Sun.COM> On Mar 11, 2009, at 6:12 AM, Christian Thalinger wrote: > Address Address::make_raw(int base, int index, int scale, int disp, > bool disp_is_oop) { > > function on SPARC too, so it's possible to use $mem$$Address in the AD > file and let (Address src, Register dst)-signature functions decide > which emit function to call? Furthermore we could assert on reg-reg > forms that have a displacement set, which is obviously wrong. The current class Address for sparc is designed to support manually specified helper instructions (sethi, etc.), unless the disp is simm13. For that reason, it provides much control, and is awkward to use when you don't want that much control. Adding in scale and index is a stretch away from what sparc does natively. If we want to make that truly work, we'll need an Address::_temp to specify the temp register (e.g., O7) to use for intermediate calculations. The AD file can use O7 uniformly. We already emit extra helper instructions behind the scenes in the AD file: see the role of O7 for non-simm13 offsets due to large stack frames. Here are some more thoughts about pseudo-addressing for sparc: If a function is named 'lduw' or some other sparc opcode, it should *not* emit helpers behind the scenes. That includes cases where scale>0, disp is not simm13, and (disp != 0 && index != noreg). We have a few automagic "helperized" pseudos, like 'load_contents'. (I don't like that name, because 'contents' is not descriptive enough. It is a pre-LP64 name choice, I think. Instead, I suggest 'load_uw' or some such.) If we want to use such pseudos more widely, we should name them more regularly, as 'load_sb', 'load_ptr', 'load_x' or some such. If we go that way, I hope the _hi, _hi32, _low32 can be persuaded to vanish. Address::_disp should be intptr_t not int. In that case, _scale>0 could make sense, as would reg+reg+disp modes. They would be mainly useful in hand-written code, since the C2 compiler will continue to control the formation of addresses in detail. > The only problem I see when using MacroAssembler instructions in > sparc.ad is the VerifyOops check in emit_form3_mem_reg. Is that still > used/necessary or can it be moved somewhere else? Go ahead and nuke that code for now. On Mar 10, 2009, at 10:46 AM, Christian Thalinger wrote: > On Tue, 2009-03-10 at 10:26 -0700, John Rose wrote: >> >> There is something like that already in assembler_sparc.hpp: >> inline void lduw( const Address& a, Register d, int offset = >> 0 ); >> >> I thought you were talking about making Address easier to use...? > > Right, and I didn't know if that is the same as on x86, is it? I > was a > bit confused because of the relocate() call. No it isn't helperized, so it only works for simm13 displacements. The relocate call emits a relocation for the simm13 field. If you supply a larger offset (or a real pointer!) you need to manually emit the right kind of sethi helper (for LP64 or !LP64). > And do these functions handle reg-reg loads properly too? > >> If you just want to add a +4 offset, you can use the optional offset >> argument above. > > Sounds good. > >> If you want to fold the offset into the Address itself, use >> Address::plus_disp (which is new). > > Sounds good too. I will have a try. Just adding Address::_index would be fine for those instructions. You could use the RegisterConstant overloadings to generate the code without adding more 'if' statements: inline void Assembler::lduw( const Address& a, Register d, int offset ) { relocate(a.rspec(offset)); lduw( a.base(), a.disp_or_index(offset), d ); } RegisterConstant Address::disp_or_index(int offset=0) { if (_index != noreg) { assert(_disp + offset == 0, "no reg+reg +disp"); return RegisterConstant(_index); } else return RegisterConstant(_disp + offset); } I hope this helps... -- John From Thomas.Rodriguez at Sun.COM Wed Mar 11 19:10:08 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 11 Mar 2009 19:10:08 -0700 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> Message-ID: <491E1E13-BE33-4096-873D-19BEEA5FE0D0@sun.com> I've done all the easy stuff and I'm onto the methodHandles* files but I thought I'd give you these first. MethodHandleSupport isn't a great flag name since it sounds like a thing. SupportMethodHandles, EnableMethodHandles or AllowMethodHandles would read better I think. cppInterpreter.cpp: method_entry(invoke_method) should be method_entry(method_handle) I think. assembler_sparc.cpp: I'd be tempted to put the delay slot nop in jump_to_method_handle_entry instead of expecting the caller to do it. Otherwise I think it needs to a comment mentioning the need to fill the delay. I know the other jump_to leave it up to the caller but they are all pretty much single instruction. jump_to_method_handle_entry does a bit of work. Either way is fine. interpreter_sparc.cpp: this is a pretty bizarre way to call throw_if_not_2 __ throw_if_not_x(Assembler::never, I know it's used in other places, I think it would be cleaner to just inline the needed throw_if_not_2 code. It's just 2 assembly instructions. I find the juxtaposition of if and never a little jarring when in fact it means always throw. stubGenerator_x86_32.cpp: What's this for: +#undef __ +#define __ _masm-> + dictionary.hpp: SymbolPropertyEntry and SymbolPropertyTable could use at least a small comment describing their intended purpose. javaClasses.cpp: all of the variants of this: + assert(Klass::cast(mname->klass())- >is_subclass_of(SystemDictionary::MemberName_klass()), "wrong type"); could simply be: assert(is_instance(mname), "wrong type"); methodOop.hpp: method_type_pointer_chase could use some comments. maybe a different name would be better since it's not actually a pointer chase but the offsets to use in a pointer chase. method_type_offsets_chain? What units is methodOopDesc::extra_stack() in? It says slots but to me that means slots in the vmreg/optoreg sense which is 32 bit words but I guess it means interpreter slots. It should have a more precise comment and maybe the name could reflect it somehow. I guess it's in the same units as max_stack and max_locals. Maybe extra_stack_entries() would get that across. The methodHandles part is to come. tom On Mar 10, 2009, at 3:48 PM, John Rose wrote: > Thanks for the reviews so far. I've posted the remainder of > meth.patch here: > > 6655638: dynamic languages need method handles > http://cr.openjdk.java.net/~jrose/6655638/webrev.00/ (not yet > integrated) > > (Long live cr.OJN! Goodbye webrev.invokedynamic.info.) > > Later today (probably) I will update the index page to have useful > comments about how each file is changed. > > After responding to any further reviewer comments, I'll push the > results. > > Because it's a large body of code, and it will help to have a record > of what we do, let's keep review comments public. > > If the comments lead to large changes, I may have to ask for a re- > review. If that happens, I'll publish at least a diff of webrev.N > to webrev.N+1, maybe even a 2nd-order webrev, if I can figure out how. > > About self-review: I will be reviewing my own code, too, and if the > review period is long enough, may wish to make amendments. I'll > email a public comment if this seems necessary. (I've "discovered" > that people don't like it when they encounter unexplained changes > mid-review.) > > Meanwhile, I'm working on the same code that's being reviewed. For > big reviews like this one, I'll try to keep separate workspaces for > review and further engineering. (I wouldn't attempt this without hg/ > MQ and Emacs diff-mode.) Therefore, if a review takes a long time > (which this one has) it may be followed immediately by a second > review cycle with a new bug ID, to push the adjustments separately. > In fact, I'll allocate the bug ID now: > > 6815692: method handle code needs some cleanup (post-6655638) > http://cr.openjdk.java.net/~jrose/6815692/webrev.00/ (not yet > posted) > > As that settles down I will be asking for reviews on this next step: > > 6655646: dynamic languages need dynamically linked call sites > http://cr.openjdk.java.net/~jrose/6655646/webrev.00/ (not yet > posted) > > After that, there will be individual pushes for additional assembly > code (x64 and/or sparc), compiler optimizations (2-3 steps there), > and various smaller things like compressed oops and cppInterpreter > support. And of course bug fixes and cleanups as needed. > > Onward! > > -- John > > On Jan 20, 2009, at 2:53 AM, John Rose wrote: > >> This is part of the JVM side of the JSR 292 Reference >> Implementation. It should have no effect on application execution, >> unless one of the new flags is turned on (chiefly -XX: >> +MethodHandleSupport). >> >> Present limitations: >> - It works only on x86/32. (No sparc, compressed oops, cpp >> interpreter.) >> - There are no compiler optimizations. >> - It is young code. There are bugs. But only when a new flag is >> turned on. >> >> This review is for contents of meth.patch, to be pushed from mlvm >> to http://hg.openjdk.java.net/jdk7/hotspot-comp-gate/hotspot . >> >> Here is the webrev for this review: >> http://webrev.invokedynamic.info/jrose/6655638.meth/ >> >> Here is the mlvm patch where the code currently lives: >> http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/tip/meth.patch >> >> An earlier version of these changes pass JPRT; it is expected that >> at most minor tweaks will be needed to push it through again. >> >> Even though they are large, the changes should also pass a simple >> visual inspection, since all substantially new control paths are >> guarded by tests of the new flags. >> >> Please give it a look. >> >> -- John >> >> P.S. Here are some relevant conversations about method handles and >> invokedynamic: >> http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000321.html >> http://blogs.sun.com/jrose/entry/international_invokedynamic_day >> http://blogs.sun.com/dannycoward/entry/firing_up_the_engines_for >> http://groups.google.com/group/jvm-languages/browse_thread/thread/a4b8a616eb987ca8 >> >> P.P.S. The proposed JDK changes are independent. At present, you >> can find them here, in patch and webrev formats: >> http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/tip/meth.proj.patch >> http://webrev.invokedynamic.info/jrose/6655638.meth.proj/ > From Thomas.Rodriguez at Sun.COM Wed Mar 11 19:16:47 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 11 Mar 2009 19:16:47 -0700 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <6ED114A0-23F9-4B7D-B6D4-5B1DD9339B4D@Sun.COM> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> <1235770496.2004.2104.camel@localhost.localdomain> <1236015075.2239.37.camel@localhost.localdomain> <0C717855-C782-49DA-8AD4-742BA9C9A47E@Sun.COM> <1236686915.2239.892.camel@localhost.localdomain> <1236707177.2239.904.camel@localhost.localdomain> <086E4BBF-3EA8-4BE0-B10B-DD74C7C8F23B@Sun.COM> <1236777144.2239.979.camel@localhost.localdomain> <6ED114A0-23F9-4B7D-B6D4-5B1DD9339B4D@Sun.COM> Message-ID: <514BC31A-D1D8-4510-AEAD-F19FCD5150C2@sun.com> > The current class Address for sparc is designed to support manually > specified helper instructions (sethi, etc.), unless the disp is > simm13. For that reason, it provides much control, and is awkward > to use when you don't want that much control. > > Adding in scale and index is a stretch away from what sparc does > natively. If we want to make that truly work, we'll need an > Address::_temp to specify the temp register (e.g., O7) to use for > intermediate calculations. The AD file can use O7 uniformly. I don't think we want to support magic in the Address form for use by the AD file since we can properly control the offset ranges we want to handle. Building a more general code generation facility to make it less error prone to write sparc assembler with unknown offsets is a separate activity and I wouldn't want to merge the two together. I think an Address form that handles only either reg/reg or reg/simm13 is all we should support. tom > We already emit extra helper instructions behind the scenes in the > AD file: see the role of O7 for non-simm13 offsets due to large > stack frames. > > Here are some more thoughts about pseudo-addressing for sparc: > > If a function is named 'lduw' or some other sparc opcode, it should > *not* emit helpers behind the scenes. That includes cases where > scale>0, disp is not simm13, and (disp != 0 && index != noreg). > > We have a few automagic "helperized" pseudos, like 'load_contents'. > (I don't like that name, because 'contents' is not descriptive > enough. It is a pre-LP64 name choice, I think. Instead, I suggest > 'load_uw' or some such.) If we want to use such pseudos more > widely, we should name them more regularly, as 'load_sb', > 'load_ptr', 'load_x' or some such. > > If we go that way, I hope the _hi, _hi32, _low32 can be persuaded to > vanish. Address::_disp should be intptr_t not int. > > In that case, _scale>0 could make sense, as would reg+reg+disp > modes. They would be mainly useful in hand-written code, since the > C2 compiler will continue to control the formation of addresses in > detail. > >> The only problem I see when using MacroAssembler instructions in >> sparc.ad is the VerifyOops check in emit_form3_mem_reg. Is that >> still >> used/necessary or can it be moved somewhere else? > > Go ahead and nuke that code for now. > > On Mar 10, 2009, at 10:46 AM, Christian Thalinger wrote: > >> On Tue, 2009-03-10 at 10:26 -0700, John Rose wrote: >>> >>> There is something like that already in assembler_sparc.hpp: >>> inline void lduw( const Address& a, Register d, int offset = >>> 0 ); >>> >>> I thought you were talking about making Address easier to use...? >> >> Right, and I didn't know if that is the same as on x86, is it? I >> was a >> bit confused because of the relocate() call. > > No it isn't helperized, so it only works for simm13 displacements. > The relocate call emits a relocation for the simm13 field. If you > supply a larger offset (or a real pointer!) you need to manually > emit the right kind of sethi helper (for LP64 or !LP64). > >> And do these functions handle reg-reg loads properly too? >> >>> If you just want to add a +4 offset, you can use the optional offset >>> argument above. >> >> Sounds good. >> >>> If you want to fold the offset into the Address itself, use >>> Address::plus_disp (which is new). >> >> Sounds good too. I will have a try. > > > Just adding Address::_index would be fine for those instructions. > You could use the RegisterConstant overloadings to generate the code > without adding more 'if' statements: > > inline void Assembler::lduw( const Address& a, Register d, int > offset ) { relocate(a.rspec(offset)); lduw( a.base(), > a.disp_or_index(offset), d ); } > > RegisterConstant Address::disp_or_index(int offset=0) { > if (_index != noreg) { assert(_disp + offset == 0, "no reg+reg > +disp"); return RegisterConstant(_index); } > else return RegisterConstant(_disp + offset); > } > > I hope this helps... > > -- John From Christian.Thalinger at Sun.COM Thu Mar 12 10:21:40 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 12 Mar 2009 18:21:40 +0100 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h Message-ID: <1236878500.1722.15.camel@localhost.localdomain> http://cr.openjdk.java.net/~twisti/6378821/webrev.00/ From Vladimir.Kozlov at Sun.COM Thu Mar 12 10:17:56 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 12 Mar 2009 10:17:56 -0700 Subject: Request for reviews (L): 6791178: Specialize for zero as the compressed oop vm heap base Message-ID: <49B943C4.8000806@sun.com> Sending to public. http://cr.openjdk.java.net/~kvn/6791178/webrev.07 Fixed 6791178: Specialize for zero as the compressed oop vm heap base The 64-bit VM with compressed oops uses an arbitrary address for the narrow oop base which is calculated as java heap base minus one (protected) page size for implicit NULL checks to work. This means a generic field reference is + ( << 3) + . If the narrow oop base can be made to be zero (the java heap doesn't actually have to start at offset zero), then a generic field reference can be just (, allowing to save the heap base add (current Register Allocator does not allow to save register). Also with zero base the null check of compressed oop is not needed. Current code for decoding compressed oops looks like this: if ( == NULL) = NULL else = + ( << 3) These checks and branches are killing the performance of compressed oops. With zero base the code is much simpler: = << 3 Also if heap size < 4Gb and it can be moved into low virtual address space then compressed oops can be used without encoding/decoding. This implementation tries to allocated java heap using different strategies based on the heap size and a platform it runs on. It tries first to allocate java heap below 4Gb to use compressed oops without decoding if heap size < 4Gb. If it fails or heap size > 4Gb it will try to allocate the heap below 32Gb to use zero based compressed oops. If this also fails it will switch to regular compressed oops with narrow oop base. The code is implemented for all GC. I added the code for G1 also but currently G1 does not support compressed oops. Fixed serviceability agent and dtrace to access new VM variables. Reviewed by: never, twisti, jcoomes, coleenp Fix verified (y/n): y Other testing: JPRT, JDK build, nsk sajdi (with compressed oops on by default) From Azeem.Jiva at amd.com Thu Mar 12 10:29:07 2009 From: Azeem.Jiva at amd.com (Jiva, Azeem) Date: Thu, 12 Mar 2009 12:29:07 -0500 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <1236878500.1722.15.camel@localhost.localdomain> References: <1236878500.1722.15.camel@localhost.localdomain> Message-ID: Christian, What sorts of gains are you seeing with this change? -- Azeem Jiva AMD Java Labs T 512.602.0907 > -----Original Message----- > From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot- > compiler-dev-bounces at openjdk.java.net] On Behalf Of Christian Thalinger > Sent: Thursday, March 12, 2009 12:22 PM > To: hotspot-compiler-dev > Subject: Request for review (L): 6378821: where available,bitCount() should > use POPC on SPARC processors and AMD+10h > > http://cr.openjdk.java.net/~twisti/6378821/webrev.00/ > From Vladimir.Kozlov at Sun.COM Thu Mar 12 10:35:33 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 12 Mar 2009 10:35:33 -0700 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <1236878500.1722.15.camel@localhost.localdomain> References: <1236878500.1722.15.camel@localhost.localdomain> Message-ID: <49B947E5.9050102@sun.com> Looks good. Add predicate to all new .ad instructions (x86 and sparc) predicate(UsePopCountInstruction); Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6378821/webrev.00/ > From Christian.Thalinger at Sun.COM Thu Mar 12 10:47:00 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 12 Mar 2009 18:47:00 +0100 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <49B947E5.9050102@sun.com> References: <1236878500.1722.15.camel@localhost.localdomain> <49B947E5.9050102@sun.com> Message-ID: <1236880020.1722.17.camel@localhost.localdomain> On Thu, 2009-03-12 at 10:35 -0700, Vladimir Kozlov wrote: > Looks good. > Add predicate to all new .ad instructions (x86 and sparc) > predicate(UsePopCountInstruction); Ahh, right. Will add that. Thanks. -- Christian From Thomas.Rodriguez at Sun.COM Thu Mar 12 12:01:04 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 12 Mar 2009 12:01:04 -0700 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <1236880020.1722.17.camel@localhost.localdomain> References: <1236878500.1722.15.camel@localhost.localdomain> <49B947E5.9050102@sun.com> <1236880020.1722.17.camel@localhost.localdomain> Message-ID: The node itself is predicated in the intrinsic logic so you don't really need it on each match. tom On Mar 12, 2009, at 10:47 AM, Christian Thalinger wrote: > On Thu, 2009-03-12 at 10:35 -0700, Vladimir Kozlov wrote: >> Looks good. >> Add predicate to all new .ad instructions (x86 and sparc) >> predicate(UsePopCountInstruction); > > Ahh, right. Will add that. Thanks. > > -- Christian > From Christian.Thalinger at Sun.COM Thu Mar 12 12:07:40 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 12 Mar 2009 20:07:40 +0100 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: References: <1236878500.1722.15.camel@localhost.localdomain> <49B947E5.9050102@sun.com> <1236880020.1722.17.camel@localhost.localdomain> Message-ID: <1236884860.1722.25.camel@localhost.localdomain> On Thu, 2009-03-12 at 12:01 -0700, Tom Rodriguez wrote: > The node itself is predicated in the intrinsic logic so you don't > really need it on each match. It shouldn't hurt to put the predicates in as it's obvious then in the AD files when these instructs are used, right? -- Christian From Thomas.Rodriguez at Sun.COM Thu Mar 12 12:08:35 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 12 Mar 2009 12:08:35 -0700 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <1236884860.1722.25.camel@localhost.localdomain> References: <1236878500.1722.15.camel@localhost.localdomain> <49B947E5.9050102@sun.com> <1236880020.1722.17.camel@localhost.localdomain> <1236884860.1722.25.camel@localhost.localdomain> Message-ID: <48DF9261-53E5-427C-9301-184C2D10EB79@Sun.COM> I agree it doesn't hurt if you want to put them in. tom On Mar 12, 2009, at 12:07 PM, Christian Thalinger wrote: > On Thu, 2009-03-12 at 12:01 -0700, Tom Rodriguez wrote: >> The node itself is predicated in the intrinsic logic so you don't >> really need it on each match. > > It shouldn't hurt to put the predicates in as it's obvious then in the > AD files when these instructs are used, right? > > -- Christian > From vladimir.kozlov at sun.com Thu Mar 12 13:05:36 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 12 Mar 2009 20:05:36 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6791178: Specialize for zero as the compressed oop vm heap base Message-ID: <20090312200547.D4175EDA9@hg.openjdk.java.net> Changeset: 660978a2a31a Author: kvn Date: 2009-03-12 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/660978a2a31a 6791178: Specialize for zero as the compressed oop vm heap base Summary: Use zero based compressed oops if java heap is below 32gb and unscaled compressed oops if java heap is below 4gb. Reviewed-by: never, twisti, jcoomes, coleenp ! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_64.ad ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/runtime/vmStructs.cpp From Christian.Thalinger at Sun.COM Thu Mar 12 14:01:20 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 12 Mar 2009 22:01:20 +0100 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: References: <1236878500.1722.15.camel@localhost.localdomain> Message-ID: <1236891680.1722.31.camel@localhost.localdomain> On Thu, 2009-03-12 at 12:29 -0500, Jiva, Azeem wrote: > Christian, > What sorts of gains are you seeing with this change? I have already added a micro-benchmark and some numbers to the CR[1]. I just moved it into public so it may take some time to show up on the website. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378821 -- Christian From Changpeng.Fang at Sun.COM Thu Mar 12 14:56:02 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Thu, 12 Mar 2009 14:56:02 -0700 Subject: Request for review (S): 6636138: UseSuperWord enabled failure Message-ID: <49B984F2.2060404@Sun.COM> This patch also fixes the problem in CR 6812207: Possible bug in a floating point (float) arithmetic in 32-bit server HotSpot http://cr.openjdk.java.net/~cfang/6636138/webrev.00/ The Problem: SuperWord scheduling ignored the memory dependence, and thus caused memory order violation and thus programs in CR 6636138 and CR 6812207 generated incorrect results. What in This Patch?: I have implemented a new superword scheduling approach to adjust the memory graph. For a store superword, we move all sandwitched memory operations outside the pack based on the dependence information. For a load superword, we use the latest memory state for the pack. Tests: JPRT scimark specjvm98 volano25 jetstream and test cases in CR 6636138 and CR 6812207, and several small self-developed cases. Thanks, Changpeng From Thomas.Rodriguez at Sun.COM Thu Mar 12 16:16:19 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 12 Mar 2009 16:16:19 -0700 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <1236878500.1722.15.camel@localhost.localdomain> References: <1236878500.1722.15.camel@localhost.localdomain> Message-ID: The PopCount nodes should only take one argument since they are never required to have control. I think there are problems with register usage with PopCountL in x86_32.ad. USEs (inputs) and TEMPs are guaranteed to be different registers but DEFs are not. KILLs and DEFs are guaranteed to be different. The model of register interference is like a single hardware instruction where all the effects occur simultaneously so the DEFs and USEs can't interfere. So for this: +instruct popCountL(eRegI dst, eRegL src, eRegI tmp, eFlagsReg cr) %{ + match(Set dst (PopCountL src)); + effect(KILL cr, TEMP tmp); dst isn't required to be different than src or tmp which will break you code generation. If you add TEMP dst to the effects then the register allocator will make the output interfere with the inputs so you can use it as a temp in the code generation. The memory one has the same problem. Otherwise this looks good. tom On Mar 12, 2009, at 10:21 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6378821/webrev.00/ > From Vladimir.Kozlov at Sun.COM Thu Mar 12 17:19:03 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 12 Mar 2009 17:19:03 -0700 Subject: for (re-)review (M): 6814659: separable cleanups and subroutines for 6655638 In-Reply-To: References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> <3E9D1DE4-B24C-4CF0-9D33-42B1F235D780@sun.com> Message-ID: <49B9A677.7010704@sun.com> About next: > 3. 6812831 factor general subclass check (for 6655638) > http://cr.openjdk.java.net/~jrose/6813212/webrev.01/ (not yet integrated) Assembler code on x86 and sparc looks good for me. General question: why we do next check in enc_PartialSubtypeCheck() // Compare super with sub directly, since super is not in its own SSA. // The compiler used to emit this test, but we fold it in here, // to allow platform-specific tweaking on sparc. __ cmpptr(Rrax, Rrsi); __ jcc(Assembler::equal, hit); and in Sparc::partial_subtype_check() // Compare super with sub directly, since super is not in its own SSA. // The compiler used to emit this test, but we fold it in here, // to increase overall code density, with no real loss of speed. { Label L; __ cmp(O1, O2); __ brx(Assembler::notEqual, false, Assembler::pt, L); __ delayed()->nop(); __ retl(); __ delayed()->addcc(G0,0,O0); // set Z flags, zero result __ bind(L); } When in GraphKit::gen_subtype_check we have the check contrary to the above comments: // Check for self. Very rare to get here, but its taken 1/3 the time. // No performance impact (too rare) but allows sharing of secondary arrays // which has some footprint reduction. Node *cmp3 = _gvn.transform( new (C, 3) CmpPNode( subklass, superklass ) ); Node *bol3 = _gvn.transform( new (C, 2) BoolNode( cmp3, BoolTest::eq ) ); IfNode *iff3 = create_and_xform_if( control(), bol3, PROB_LIKELY(0.36f), COUNT_UNKNOWN ); r_ok_subtype->init_req(2, _gvn.transform( new (C, 1) IfTrueNode ( iff3 ) ) ); set_control( _gvn.transform( new (C, 1) IfFalseNode( iff3 ) ) ); Next, why we keep generate_partial_subtype_check stub? The only place which calls it is sparc.ad: enc_class enc_PartialSubtypeCheck() %{ MacroAssembler _masm(&cbuf); __ call(StubRoutines::Sparc::partial_subtype_check(), relocInfo::runtime_call_type); __ delayed()->nop(); %} Is there a reason to keep the call instead of using your new macroassembler methods? assembler_x86.cpp check_klass_subtype_slow_path() Move next assert: + assert(secondary_supers_addr.base() != rax, "put sub_klass in another reg"); (why not assert(sub_klass != rax, "put sub_klass in another reg") ?) before this code: + if (super_klass != rax || UseCompressedOops) { + if (!IS_A_TEMP(rax)) { push(rax); pushed_rax = true; } + mov(rax, super_klass); + } Also sub_klass != rcx since rcx is destroyed by debug counter code. You changed encode_heap_oop(rax) to encode_heap_oop_not_null(rax). Can you give guaranty that super_klass value is not NULL for all cases? x86_64.ad, x86_32.ad You can remove the label 'cmiss' from enc_PartialSubtypeCheck. Thanks, Vladimir John Rose wrote: > In order to reduce the size of my forthcoming method handles changeset, > I have (at Vladimir's suggestion) pulled out chunks of independent > changes this week. The four chunks amount to about 40% of the changes, > and are more easily tested and reviewed in isolation. > > The fourth chunk 6814659 is the most miscellaneous. It is a bunch of > changes that were necessary either for debugging method handles, or for > supporting them. They can all be considered independently. > > Here are the changes: > http://cr.openjdk.java.net/~jrose/6814659/webrev.00/ > > Not much review is necessary here, because these changes have already > been reviewed as part of the larger changeset. > > The current draft of the big change is here: > http://cr.openjdk.java.net/~jrose/6655638/webrev.00/ > > -- John > > P.S. For the record, here is the sequence: > > 1. 6812678: macro assembler needs delayed binding of a few constants > (for 6655638) > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/56aae7be60d4 > > 2. 6812831: factor duplicated assembly code for megamorphic > invokeinterface (for 6655638) > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9adddb8c0fc8 > > 3. 6812831 factor general subclass check (for 6655638) > http://cr.openjdk.java.net/~jrose/6813212/webrev.01/ (not yet integrated) > > 4. 6814659: separable cleanups and subroutines for 6655638 > http://cr.openjdk.java.net/~jrose/6814659/webrev.00/ (not yet integrated) > > 5. 6655638: dynamic languages need method handles > http://cr.openjdk.java.net/~jrose/6655638/webrev.00/ (not yet integrated) > > And here are the patch file sizes (from my mq patch queue): > > 1178 5493 48571 asm-6812678.patch > 979 5029 40958 ilookup-6812831.patch > 1611 7834 70518 subtype-6813212.patch > 1147 4962 48089 minor-6814659.patch > 7274 33505 311948 meth.patch > 12189 56823 520084 total > From Christian.Thalinger at Sun.COM Fri Mar 13 07:34:20 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 13 Mar 2009 15:34:20 +0100 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: References: <1236878500.1722.15.camel@localhost.localdomain> Message-ID: <1236954860.1722.38.camel@localhost.localdomain> On Thu, 2009-03-12 at 16:16 -0700, Tom Rodriguez wrote: > The PopCount nodes should only take one argument since they are never > required to have control. > > I think there are problems with register usage with PopCountL in > x86_32.ad. USEs (inputs) and TEMPs are guaranteed to be different > registers but DEFs are not. KILLs and DEFs are guaranteed to be > different. The model of register interference is like a single > hardware instruction where all the effects occur simultaneously so the > DEFs and USEs can't interfere. So for this: > > +instruct popCountL(eRegI dst, eRegL src, eRegI tmp, eFlagsReg cr) %{ > + match(Set dst (PopCountL src)); > + effect(KILL cr, TEMP tmp); > > dst isn't required to be different than src or tmp which will break > you code generation. If you add TEMP dst to the effects then the > register allocator will make the output interfere with the inputs so > you can use it as a temp in the code generation. The memory one has > the same problem. I see. Thanks for the detailed explanation, I will fix that. -- Christian From Christian.Thalinger at Sun.COM Fri Mar 13 08:49:41 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 13 Mar 2009 16:49:41 +0100 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: References: <1236878500.1722.15.camel@localhost.localdomain> Message-ID: <1236959381.1722.48.camel@localhost.localdomain> On Thu, 2009-03-12 at 16:16 -0700, Tom Rodriguez wrote: > The PopCount nodes should only take one argument since they are never > required to have control. Hmm, I can't get it working properly. When I use: PopCountINode(Node* in1) : Node(in1) {} I get: # Internal Error (/home/ct232829/hotspot-comp/6378821/src/share/vm/opto/matcher.cpp:1375), pid=8595, tid=19 # Error: assert(false,"bad AD file") and I think I know why that happens. When I use: PopCountINode(Node* in1) : Node(0, in1) {} I have to use: push(_gvn.transform(new (C, 2) PopCountINode(pop()))); which is not very obvious to use 2 for the new call. Should I use the latter anyway? -- Christian From Thomas.Rodriguez at Sun.COM Fri Mar 13 09:32:06 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 13 Mar 2009 09:32:06 -0700 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <1236959381.1722.48.camel@localhost.localdomain> References: <1236878500.1722.15.camel@localhost.localdomain> <1236959381.1722.48.camel@localhost.localdomain> Message-ID: <95FB45D7-E88E-4111-860A-4029D7F4D498@Sun.COM> > and I think I know why that happens. When I use: > > PopCountINode(Node* in1) : Node(0, in1) {} > > I have to use: > > push(_gvn.transform(new (C, 2) PopCountINode(pop()))); > > which is not very obvious to use 2 for the new call. Should I use the > latter anyway? That's the style of other nodes of that don't require control. All the binary operators and many of the unary operators are like this and this one should follow that same style. tom > > > -- Christian > From Ulf.Zibis at gmx.de Fri Mar 13 09:43:37 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 13 Mar 2009 17:43:37 +0100 Subject: hg: jdk7/hotspot-comp/hotspot: 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <20090309124313.7DF3DEA42@hg.openjdk.java.net> References: <20090309124313.7DF3DEA42@hg.openjdk.java.net> Message-ID: <49BA8D39.5040409@gmx.de> Hi Christian, where can I find information, when this CR will be available in snapshot release? -Ulf Am 09.03.2009 13:43, Christian.Thalinger at Sun.COM schrieb: > Changeset: 337400e7a5dd > Author: twisti > Date: 2009-03-09 03:17 -0700 > URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/337400e7a5dd > > 6797305: Add LoadUB and LoadUI opcode class > Summary: Add a LoadUB (unsigned byte) and LoadUI (unsigned int) opcode class so we have these load optimizations in the first place and do not need to handle them in the matcher. > Reviewed-by: never, kvn > > ! src/cpu/sparc/vm/sparc.ad > ! src/cpu/x86/vm/assembler_x86.cpp > ! src/cpu/x86/vm/assembler_x86.hpp > ! src/cpu/x86/vm/x86_32.ad > ! src/cpu/x86/vm/x86_64.ad > ! src/share/vm/adlc/forms.cpp > ! src/share/vm/adlc/forms.hpp > ! src/share/vm/adlc/formssel.cpp > ! src/share/vm/adlc/output_c.cpp > ! src/share/vm/opto/classes.hpp > ! src/share/vm/opto/compile.cpp > ! src/share/vm/opto/memnode.cpp > ! src/share/vm/opto/memnode.hpp > ! src/share/vm/opto/mulnode.cpp > ! src/share/vm/opto/type.cpp > ! src/share/vm/opto/type.hpp > + test/compiler/6797305/Test6797305.java > > > From Peter.Kessler at Sun.COM Fri Mar 13 09:46:35 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Fri, 13 Mar 2009 09:46:35 -0700 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <95FB45D7-E88E-4111-860A-4029D7F4D498@Sun.COM> References: <1236878500.1722.15.camel@localhost.localdomain> <1236959381.1722.48.camel@localhost.localdomain> <95FB45D7-E88E-4111-860A-4029D7F4D498@Sun.COM> Message-ID: <49BA8DEB.3040800@Sun.COM> Some node subclasses have a static "make" factory method to hide the details of calling the placement new and remembering how many in's to specify. You might want to have one of those for PopCountINode. ... peter Tom Rodriguez wrote: >> and I think I know why that happens. When I use: >> >> PopCountINode(Node* in1) : Node(0, in1) {} >> >> I have to use: >> >> push(_gvn.transform(new (C, 2) PopCountINode(pop()))); >> >> which is not very obvious to use 2 for the new call. Should I use the >> latter anyway? > > That's the style of other nodes of that don't require control. All the > binary operators and many of the unary operators are like this and this > one should follow that same style. > > tom > >> >> >> -- Christian >> > From Christian.Thalinger at Sun.COM Fri Mar 13 09:53:38 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 13 Mar 2009 17:53:38 +0100 Subject: Request for review (L): 6378821: bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <95FB45D7-E88E-4111-860A-4029D7F4D498@Sun.COM> References: <1236878500.1722.15.camel@localhost.localdomain> <1236959381.1722.48.camel@localhost.localdomain> <95FB45D7-E88E-4111-860A-4029D7F4D498@Sun.COM> Message-ID: <1236963218.1722.56.camel@localhost.localdomain> On Fri, 2009-03-13 at 09:32 -0700, Tom Rodriguez wrote: > That's the style of other nodes of that don't require control. All > the binary operators and many of the unary operators are like this and > this one should follow that same style. Okay. Just a last quick review of my last changes and then I will push it: http://cr.openjdk.java.net/~twisti/6378821/webrev.01/ -- Christian From Christian.Thalinger at Sun.COM Fri Mar 13 10:01:32 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 13 Mar 2009 18:01:32 +0100 Subject: hg: jdk7/hotspot-comp/hotspot: 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <49BA8D39.5040409@gmx.de> References: <20090309124313.7DF3DEA42@hg.openjdk.java.net> <49BA8D39.5040409@gmx.de> Message-ID: <1236963692.1722.59.camel@localhost.localdomain> On Fri, 2009-03-13 at 17:43 +0100, Ulf Zibis wrote: > Hi Christian, > > where can I find information, when this CR will be available in snapshot > release? The changeset has been promoted to the hotspot repository[1] and is part of HS15 build 03, which will be included in JDK7 build 51. A build schedule can be found here[2]. [1] http://hg.openjdk.java.net/jdk7/hotspot/hotspot/shortlog [2] http://openjdk.java.net/projects/jdk7/builds/ -- Christian From Vladimir.Kozlov at Sun.COM Fri Mar 13 10:01:59 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 13 Mar 2009 10:01:59 -0700 Subject: Request for review (L): 6378821: bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <1236963218.1722.56.camel@localhost.localdomain> References: <1236878500.1722.15.camel@localhost.localdomain> <1236959381.1722.48.camel@localhost.localdomain> <95FB45D7-E88E-4111-860A-4029D7F4D498@Sun.COM> <1236963218.1722.56.camel@localhost.localdomain> Message-ID: <49BA9187.1010907@sun.com> Looks good. Vladimir Christian Thalinger wrote: > On Fri, 2009-03-13 at 09:32 -0700, Tom Rodriguez wrote: >> That's the style of other nodes of that don't require control. All >> the binary operators and many of the unary operators are like this and >> this one should follow that same style. > > Okay. Just a last quick review of my last changes and then I will push > it: > > http://cr.openjdk.java.net/~twisti/6378821/webrev.01/ > > -- Christian > From Christian.Thalinger at Sun.COM Fri Mar 13 10:07:46 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 13 Mar 2009 18:07:46 +0100 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <49BA8DEB.3040800@Sun.COM> References: <1236878500.1722.15.camel@localhost.localdomain> <1236959381.1722.48.camel@localhost.localdomain> <95FB45D7-E88E-4111-860A-4029D7F4D498@Sun.COM> <49BA8DEB.3040800@Sun.COM> Message-ID: <1236964066.1722.62.camel@localhost.localdomain> On Fri, 2009-03-13 at 09:46 -0700, Peter B. Kessler wrote: > Some node subclasses have a static "make" factory method to hide the > details of calling the placement new and remembering how many in's to > specify. You might want to have one of those for PopCountINode. Hmm, didn't know these methods exist. Is it common practice to use this method? -- Christian From Vladimir.Kozlov at Sun.COM Fri Mar 13 10:14:25 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 13 Mar 2009 10:14:25 -0700 Subject: Request for review (L): 6378821: where available, bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <1236964066.1722.62.camel@localhost.localdomain> References: <1236878500.1722.15.camel@localhost.localdomain> <1236959381.1722.48.camel@localhost.localdomain> <95FB45D7-E88E-4111-860A-4029D7F4D498@Sun.COM> <49BA8DEB.3040800@Sun.COM> <1236964066.1722.62.camel@localhost.localdomain> Message-ID: <49BA9471.3050608@sun.com> Usually we use it for several similar nodes, for example, ConNode::make. In the current case we have only 2 (I/L) nodes. I don't think we need make factory for them. Vladimir Christian Thalinger wrote: > On Fri, 2009-03-13 at 09:46 -0700, Peter B. Kessler wrote: >> Some node subclasses have a static "make" factory method to hide the >> details of calling the placement new and remembering how many in's to >> specify. You might want to have one of those for PopCountINode. > > Hmm, didn't know these methods exist. Is it common practice to use this > method? > > -- Christian > From Ulf.Zibis at gmx.de Fri Mar 13 10:57:58 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 13 Mar 2009 18:57:58 +0100 Subject: hg: jdk7/hotspot-comp/hotspot: 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1236963692.1722.59.camel@localhost.localdomain> References: <20090309124313.7DF3DEA42@hg.openjdk.java.net> <49BA8D39.5040409@gmx.de> <1236963692.1722.59.camel@localhost.localdomain> Message-ID: <49BA9EA6.4090205@gmx.de> Am 13.03.2009 18:01, Christian Thalinger schrieb: > On Fri, 2009-03-13 at 17:43 +0100, Ulf Zibis wrote: > >> Hi Christian, >> >> where can I find information, when this CR will be available in snapshot >> release? >> > > The changeset has been promoted to the hotspot repository[1] and is part > of HS15 build 03, which will be included in JDK7 build 51. A build > schedule can be found here[2]. > > [1] http://hg.openjdk.java.net/jdk7/hotspot/hotspot/shortlog > [2] http://openjdk.java.net/projects/jdk7/builds/ > Wow, that sounds great. It should be available today. (OK, maybe tomorrow) ;-) Much thanks for your answer, because I still feel unable to retrieve that information from [1] Regarding: if (inByte >= 0) return (char)inByte; else return (char)(inByte & 0xFF); I'm curious, if your CR would also result in some progress for that case. So I have expanded my benchmark test: import org.junit.*; /** * * @author Ulf Zibis */ public class DecoderBenchmark { static final char[] map = new char[256]; static final byte[] src = new byte[131072]; // exceed CPU L1-cache for real world constraint static final char[] dst = new char[131072]; // exceed CPU L1-cache for real world constraint static final int LOOPS = 125; // static final byte[] src = new byte[16384]; // don't exceed CPU L1-cache // static final char[] dst = new char[16384]; // don't exceed CPU L1-cache // static final int LOOPS = 1000; // static final byte[] src = new byte[2048]; // far below of exceeding CPU L1-cache // static final char[] dst = new char[2048]; // far below of exceeding CPU L1-cache // static final int LOOPS = 8000; static final int OUTER_LOOPS = 100; static final int WARMUP_LOOPS = 4; static final float WARMUP_RATIO = 0.10f; @Test public void foo() { // fill arrays, to force real memory load and prohibit HotSpot from just incrementing // (maybe candidate for sophisticated HotSpot optimization ;-) ) for (int i=0; i=0) ? (char)a : (char)(a&0xFF): "+time5/1000000+" ms"); System.out.println("time for inlined (char)a: "+itime3/1000000+" ms"); System.out.println("time for inlined (char)(a & 0xFF): "+itime4/1000000+" ms"); System.out.println("time for inlined (a>=0) ? (char)a : (char)(a&0xFF): "+itime5/1000000+" ms"); System.out.println("last warm up ./. test loops: " +(float)lastWarmUpTime/(time1+time2+itime1+itime2)/WARMUP_RATIO); } static void loop1(byte[] src, char[] dst) { for (int i=0; i= 0) dst[i] = (char)src[i]; else dst[i] = (char)(src[i] & 0xFF); } public static char decode1(byte a) { return map[a & 0xFF]; } public static char decode2(byte a) { return map[a + 0x80]; } public static char decode3(byte a) { return (char)a; } public static char decode4(byte a) { return (char)(a & 0xFF); } public static char decode5(byte a) { // seems to be not inlined, check with mostly positive src bytes if (a >= 0) return (char)a; else return (char)(a & 0xFF); } public static void main(String[] args) { DecoderBenchmark dbm = new DecoderBenchmark(); dbm.foo(); } } From Tim.Bell at Sun.COM Fri Mar 13 11:09:26 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Fri, 13 Mar 2009 11:09:26 -0700 Subject: hg: jdk7/hotspot-comp/hotspot: 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <49BA9EA6.4090205@gmx.de> References: <20090309124313.7DF3DEA42@hg.openjdk.java.net> <49BA8D39.5040409@gmx.de> <1236963692.1722.59.camel@localhost.localdomain> <49BA9EA6.4090205@gmx.de> Message-ID: <49BAA156.4080605@sun.com> Ulf Zibis wrote: >> [2] http://openjdk.java.net/projects/jdk7/builds/ >> > > Wow, that sounds great. It should be available today. (OK, maybe > tomorrow) ;-) Unfortunately I have to step in from the sidelines and say that schedule is out of date. Build 51 did not promote yesterday as published on the old calendar. Please refer to this email thread: http://mail.openjdk.java.net/pipermail/jdk7-gk/2009-March/000027.html The current plan will be for b51 to be held open one extra week. b51 should be promoted on the 19th of March. Tim -------- Original Message -------- Subject: status -- jdk 7 promotion on Thursday Date: Tue, 10 Mar 2009 07:28:52 -0700 From: Xiomara Jayasena To: jdk7-gk at openjdk.java.net Hi, FYI, if there are no code changes other than the copyright changes pushed to the JDK 7 master repos, there will be no jdk 7 promotion this Thursday 03/12/09. So far the integrators scheduled to integrate prior to Thursday this week will not be integrating. -Xiomara From Christian.Thalinger at Sun.COM Fri Mar 13 11:09:38 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 13 Mar 2009 19:09:38 +0100 Subject: hg: jdk7/hotspot-comp/hotspot: 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <49BA9EA6.4090205@gmx.de> References: <20090309124313.7DF3DEA42@hg.openjdk.java.net> <49BA8D39.5040409@gmx.de> <1236963692.1722.59.camel@localhost.localdomain> <49BA9EA6.4090205@gmx.de> Message-ID: <1236967778.1722.73.camel@localhost.localdomain> On Fri, 2009-03-13 at 18:57 +0100, Ulf Zibis wrote: > Regarding: > if (inByte >= 0) > return (char)inByte; > else > return (char)(inByte & 0xFF); > > I'm curious, if your CR would also result in some progress for that case. No. Currently I'm working on load shortening, like: char c = (char) (intarray[i] & 0xFFFF); The next thing on my TODO list will be to optimize widening conversions, but I haven't opened a CR yet. -- Christian From Thomas.Rodriguez at Sun.COM Fri Mar 13 11:36:35 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 13 Mar 2009 11:36:35 -0700 Subject: Request for review (L): 6378821: bitCount() should use POPC on SPARC processors and AMD+10h In-Reply-To: <1236963218.1722.56.camel@localhost.localdomain> References: <1236878500.1722.15.camel@localhost.localdomain> <1236959381.1722.48.camel@localhost.localdomain> <95FB45D7-E88E-4111-860A-4029D7F4D498@Sun.COM> <1236963218.1722.56.camel@localhost.localdomain> Message-ID: Looks good. tom On Mar 13, 2009, at 9:53 AM, Christian Thalinger wrote: > On Fri, 2009-03-13 at 09:32 -0700, Tom Rodriguez wrote: >> That's the style of other nodes of that don't require control. All >> the binary operators and many of the unary operators are like this >> and >> this one should follow that same style. > > Okay. Just a last quick review of my last changes and then I will > push > it: > > http://cr.openjdk.java.net/~twisti/6378821/webrev.01/ > > -- Christian > From Christian.Thalinger at Sun.COM Fri Mar 13 14:19:06 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 13 Mar 2009 21:19:06 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6378821: bitCount() should use POPC on SPARC processors and AMD+10h Message-ID: <20090313211913.326B7EEAD@hg.openjdk.java.net> Changeset: c771b7f43bbf Author: twisti Date: 2009-03-13 11:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c771b7f43bbf 6378821: bitCount() should use POPC on SPARC processors and AMD+10h Summary: bitCount() should use POPC on SPARC processors where POPC is implemented directly in hardware. Reviewed-by: kvn, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/globals.hpp + test/compiler/6378821/Test6378821.java From John.Rose at Sun.COM Fri Mar 13 19:43:21 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 13 Mar 2009 19:43:21 -0700 Subject: for (re-)review (M): 6814659: separable cleanups and subroutines for 6655638 In-Reply-To: <49B9A677.7010704@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> <3E9D1DE4-B24C-4CF0-9D33-42B1F235D780@sun.com> <49B9A677.7010704@sun.com> Message-ID: <221DB7BB-DB28-48F4-99E3-1C4FC0C72F9F@Sun.COM> On Mar 12, 2009, at 5:19 PM, Vladimir Kozlov wrote: > About next: > > > 3. 6812831 factor general subclass check (for 6655638) > > http://cr.openjdk.java.net/~jrose/6813212/webrev.01/ (not yet > integrated) > > Assembler code on x86 and sparc looks good for me. Great. It tests well on JPRT and CTW (all jars, several solaris configs in x86/sparc c1/c2 32/64). I am confident there are fewer bugs after the change than before, despite the amount of touches. > General question: why we do next check in enc_PartialSubtypeCheck() > > // Compare super with sub directly, since super is not in its own > SSA. > // The compiler used to emit this test, but we fold it in here, > // to allow platform-specific tweaking on sparc. > __ cmpptr(Rrax, Rrsi); > __ jcc(Assembler::equal, hit); > > and in Sparc::partial_subtype_check() > > // Compare super with sub directly, since super is not in its > own SSA. > // The compiler used to emit this test, but we fold it in here, > // to increase overall code density, with no real loss of speed. > { Label L; > __ cmp(O1, O2); > __ brx(Assembler::notEqual, false, Assembler::pt, L); > __ delayed()->nop(); > __ retl(); > __ delayed()->addcc(G0,0,O0); // set Z flags, zero result > __ bind(L); > } > > When in GraphKit::gen_subtype_check we have the check contrary to > the above > comments: > > // Check for self. Very rare to get here, but its taken 1/3 the > time. > // No performance impact (too rare) but allows sharing of secondary > arrays > // which has some footprint reduction. > Node *cmp3 = _gvn.transform( new (C, 3) CmpPNode( subklass, > superklass ) ); > Node *bol3 = _gvn.transform( new (C, 2) BoolNode( cmp3, > BoolTest::eq ) ); > IfNode *iff3 = create_and_xform_if( control(), bol3, > PROB_LIKELY(0.36f), COUNT_UNKNOWN ); > r_ok_subtype->init_req(2, _gvn.transform( new (C, 1) IfTrueNode > ( iff3 ) ) ); > set_control( _gvn.transform( new (C, 1) > IfFalseNode( iff3 ) ) ); It's an old piece of history, I guess, from when two engineers were working on one chunk of code. Thanks for asking. The extra self- check on the slow path apparently has been useless for years. So, I have removed those extra checks, of course after checking all the usages of PartialSubtypeCheck nodes on x86 and sparc. I put in new comments in graphKit and assembler_ explaining why the self-check is there, and why it comes in a different order in C2 than elsewhere. Nice! > Next, why we keep generate_partial_subtype_check stub? > The only place which calls it is sparc.ad: > > enc_class enc_PartialSubtypeCheck() %{ > MacroAssembler _masm(&cbuf); > __ call(StubRoutines::Sparc::partial_subtype_check(), > relocInfo::runtime_call_type); > __ delayed()->nop(); > %} > > Is there a reason to keep the call instead of using your new > macroassembler methods? Code density. The sparc loop is much bigger than the x86 loop, so we out-of-line it. The graphKit.cpp comments mention the issue of code size, and I improved them. > assembler_x86.cpp check_klass_subtype_slow_path() > Move next assert: > + assert(secondary_supers_addr.base() != rax, "put sub_klass in > another reg"); > (why not assert(sub_klass != rax, "put sub_klass in another reg") ?) > > before this code: > + if (super_klass != rax || UseCompressedOops) { > + if (!IS_A_TEMP(rax)) { push(rax); pushed_rax = true; } > + mov(rax, super_klass); > + } > > Also sub_klass != rcx since rcx is destroyed by debug counter code. Good call. Done. I put the checks just before the instructions which would kill sub_klass with a bad assignment, rather at the very top of the function, where it would be hard to see why those restrictions matter. > You changed encode_heap_oop(rax) to encode_heap_oop_not_null(rax). > Can you give guaranty that super_klass value is not NULL for all > cases? Yes, it would be fundamental system bug if we were to class-check against a null klassOop. I put an explanatory comment near the calls to encode_heap_oop_not_null. > x86_64.ad, x86_32.ad > You can remove the label 'cmiss' from enc_PartialSubtypeCheck. Done. I also removed the label 'hit' everywhere, since it is not used except by the self-checks, which I removed. I've updated the webrev: http://cr.openjdk.java.net/~jrose/6813212/webrev.02/ http://cr.openjdk.java.net/~jrose/6813212/01-to-02.patch.txt > Thanks, > Vladimir Many thanks! I owe you a drink of your favorite beverage. -- John From john.rose at sun.com Sat Mar 14 00:24:54 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Sat, 14 Mar 2009 07:24:54 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6813212: factor duplicated assembly code for general subclass check (for 6655638) Message-ID: <20090314072503.0E3A4EF39@hg.openjdk.java.net> Changeset: c517646eef23 Author: jrose Date: 2009-03-13 18:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c517646eef23 6813212: factor duplicated assembly code for general subclass check (for 6655638) Summary: Code in interp_masm, stubGenerator, c1_LIRAssembler, and AD files moved into MacroAssembler. Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/graphKit.cpp From John.Rose at Sun.COM Sat Mar 14 15:52:38 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 14 Mar 2009 15:52:38 -0700 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: <1236793576.2239.1059.camel@localhost.localdomain> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <1236793576.2239.1059.camel@localhost.localdomain> Message-ID: <05B8AAD9-79E7-4F0F-935C-9A6316D2D426@Sun.COM> On Mar 11, 2009, at 10:46 AM, Christian Thalinger wrote: > As always, I try to do a review. Thanks; more eyeballs on the code means better code. > + const int method_stack = (method->max_locals() + method- > >max_stack() + extra_stack) * > Interpreter::stackElementWords(); > - return overhead_size + method_stack + stub_code; > + return overhead_size + method_stack + extra_stack + stub_code; > > Adding extra_stack a second time on return seems wrong. Good catch. Would have broken the tagged-stack interpreter. > + product(bool, MethodHandleSupport, > false, \ > + "support method handles (true by default under JSR > 292") \ > > Closing ) is missing in the description. Fixed.) > 391 assert(methodOopDesc::invalid_vtable_index - 10 > > VM_INDEX_UNINITIALIZED, "Java sentinel value"); > > At least to me it's not obvious why -10. I added a comment. The idea is to not even come close to overlapping with methodOopDesc::VtableIndexFlag, so that the Java and JVM code bases can move slightly without running into each others sentinel values. I could have added another sentinel value to that enum, but then I'd have to couple it tightly with the method handle stuff, which means pushing the JVM's exact choice of value out to Java code. The present setup is kludgy, but highly unlikely to break, especially with that aggressive assert in place. > 539 void MethodHandles::expand_MemberName(Handle mname, int > suppress, TRAPS) { > > It seems suppress uses some hardcoded values. It would be better to > use > some defines or enum values. Good idea. > Seems the comments do not match the code, because rsi is not used in > the > code. rsi is used in the interpreter calling sequence (r13 for x64). I put a comment referring to the usage elsewhere, and mentioned r13. > One minor thing is that the copyright year is not updated in some (or > all?) files. Good point. That is often corrected as part of our release engineering. But I guess it's better to catch it early. Thanks. After I work over Tom's comments I'll repost the webrev. -- John From John.Rose at Sun.COM Sat Mar 14 18:20:08 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 14 Mar 2009 18:20:08 -0700 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: <491E1E13-BE33-4096-873D-19BEEA5FE0D0@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <491E1E13-BE33-4096-873D-19BEEA5FE0D0@sun.com> Message-ID: On Mar 11, 2009, at 7:10 PM, Tom Rodriguez wrote: > I've done all the easy stuff and I'm onto the methodHandles* files > but I thought I'd give you these first. Thank you! > MethodHandleSupport isn't a great flag name since it sounds like a > thing. SupportMethodHandles, EnableMethodHandles or > AllowMethodHandles would read better I think. OK: EnableMethodHandles it is. > method_entry(invoke_method) should be method_entry(method_handle) I > think. True. C++ interpreter support isn't in there yet. I have to look again at platforms not yet supported and comment out some of those tentative changes. > assembler_sparc.cpp: > > I'd be tempted to put the delay slot nop in > jump_to_method_handle_entry instead of expecting the caller to do > it. Otherwise I think it needs to a comment mentioning the need to > fill the delay. I know the other jump_to leave it up to the caller > but they are all pretty much single instruction. > jump_to_method_handle_entry does a bit of work. Either way is fine. You are right; it looks funny for a big macro to end with an unfilled delay slot. The other guys look like pseudo-instructions. I'll put the nop inside the macro, and later on if I ever get tempted to optimize it, I'll add an optional boolean: void jump_to_method_handle_entry(Register mh_reg, Register temp_reg, // pass true here if you don't want the final nop: bool caller_adds_delay_slot = false); jump_indirect_to is just slightly more like a pseudo-instruction, so let's leave it like jmp, jmpl, etc. > this is a pretty bizarre way to call throw_if_not_2 > > __ throw_if_not_x(Assembler::never, > > I know it's used in other places, I think it would be cleaner to > just inline the needed throw_if_not_2 code. It's just 2 assembly > instructions. I find the juxtaposition of if and never a little > jarring when in fact it means always throw. I like the way the "__ throw..." macros read. But for the 'always' case a naked jump is just as informative, given that the stub name has "throw" in it. > What's this for: > > +#undef __ > +#define __ _masm-> > + Leftovers from an earlier arrangement of the code. I nuked it. > SymbolPropertyEntry and SymbolPropertyTable could use at least a > small comment describing their intended purpose. Good idea; done. > all of the variants of this: > > + assert(Klass::cast(mname->klass())- > >is_subclass_of(SystemDictionary::MemberName_klass()), "wrong type"); > > could simply be: > > assert(is_instance(mname), "wrong type"); Thanks! Done, for several variants. > method_type_pointer_chase could use some comments. maybe a > different name would be better since it's not actually a pointer > chase but the offsets to use in a pointer chase. > method_type_offsets_chain? OK. > > What units is methodOopDesc::extra_stack() in? It says slots but to > me that means slots in the vmreg/optoreg sense which is 32 bit words > but I guess it means interpreter slots. It should have a more > precise comment and maybe the name could reflect it somehow. I > guess it's in the same units as max_stack and max_locals. Yes. "extra_stack" by analogy with "max_stack". > Maybe extra_stack_entries() would get that across. OK. This will make it clear, and give me a chance to go back and look for bugs: static int extra_stack_entries() { return EnableMethodHandles ? (int)MethodHandlePushLimit : 0; } static int extra_stack_words() { return extra_stack_entries() * Interpreter::stackElementSize(); } > > The methodHandles part is to come. Good deal. -- John From John.Rose at Sun.COM Sat Mar 14 19:05:30 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 14 Mar 2009 19:05:30 -0700 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: <491E1E13-BE33-4096-873D-19BEEA5FE0D0@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <491E1E13-BE33-4096-873D-19BEEA5FE0D0@sun.com> Message-ID: <732BC322-151C-4BB1-A8FC-4104C73CB8CF@Sun.COM> The file methodHandles.cpp is about 2300 LOC. I'm open to ideas (simple, please) for partitioning it before putback. One thought is moving the MemberName stuff into its own file; it is about 400 LOC, and may grow, especially if it becomes the infrastructure of a new MH-based implementation of reflection. The logic for adapter method handles is at least 400 LOC also. -- John From vladimir.kozlov at sun.com Mon Mar 16 17:37:47 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 17 Mar 2009 00:37:47 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6816308: Changes to allow builds with latest Windows SDK 6.1 on 64bit Windows 2003 Message-ID: <20090317003753.E549BE0BF@hg.openjdk.java.net> Changeset: c3a720eefe82 Author: kvn Date: 2009-03-16 15:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c3a720eefe82 6816308: Changes to allow builds with latest Windows SDK 6.1 on 64bit Windows 2003 Summary: Allow Hotspot builds with latest Windows SDK 6.1 on 64bit Windows 2003 Reviewed-by: ohair, tbell, jcoomes ! make/windows/get_msc_ver.sh ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/sanity.make ! src/cpu/x86/vm/interpreterRT_x86_64.cpp ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp ! src/share/vm/adlc/adlc.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp From John.Rose at Sun.COM Tue Mar 17 11:26:02 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 17 Mar 2009 11:26:02 -0700 Subject: cross-post of method handle review Message-ID: <9A42D4E3-F504-4C10-9382-076180F04A84@Sun.COM> The JSR 292 implementation work is happening in the compiler group, and reviews of the various parts may be viewed here on that group's public mailing list. Here is a recent message to the hotspot-compiler- dev giving a roadmap of recent and imminent commits: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2009-March/000826.html The webrevs currently under review are: 6814659: separable cleanups and subroutines for 6655638 http://cr.openjdk.java.net/~jrose/6814659/webrev.00/ 6655638: dynamic languages need method handles http://cr.openjdk.java.net/~jrose/6655638/webrev.00/ Beyond these, there will be a series of additional commits for the JSR 292 RI. I will CC this mailing list from time to time to remind members of this activity, and (of course) respond to messages here. But I do ask that any code reviewers use the hotspot-compiler-dev mailing list, to keep the engineering reviews in one place. Thanks, -- John From Vladimir.Kozlov at Sun.COM Tue Mar 17 21:38:59 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 17 Mar 2009 21:38:59 -0700 Subject: Request for reviews (S): 6772368: REGRESSION:tomcat crashed twice with JDK 7 Message-ID: <49C07AE3.5020405@sun.com> http://cr.openjdk.java.net/~kvn/6772368/webrev.00 Fixed 6772368: REGRESSION:tomcat crashed twice with JDK 7 Problem: The fix for 6621084 changed where we break block boundaries. Solution: Call make_block_at() with the original handler limits. Reviewed by: Fix verified (y/n): y, bug test prepared by Tom Other testing: JPRT From John.Rose at Sun.COM Wed Mar 18 11:05:19 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 18 Mar 2009 11:05:19 -0700 Subject: for (re-)review (M): 6814659: separable cleanups and subroutines for 6655638 In-Reply-To: <221DB7BB-DB28-48F4-99E3-1C4FC0C72F9F@Sun.COM> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> <3E9D1DE4-B24C-4CF0-9D33-42B1F235D780@sun.com> <49B9A677.7010704@sun.com> <221DB7BB-DB28-48F4-99E3-1C4FC0C72F9F@Sun.COM> Message-ID: <0B24EF23-64FF-41E3-9F3B-28A97357F70D@sun.com> I refreshed the webrev for the pre-method-handle cleanups, incorporating reviewer comments. http://cr.openjdk.java.net/~jrose/6814659/webrev.01/ http://cr.openjdk.java.net/~jrose/6814659/00-to-01.diff.txt Changes since webrev.00: - KlassHandles => SystemDictionaryHandles (never) - RegisterConstant => RegisterOrConstant (never) - delayed_value => delayed_value_impl, only the virtual overloading (jrose) - update copyright headers to 2009 (twisti) Also, the index page is reorganized and there are a few more explanatory comments here and there. -- John From Vladimir.Kozlov at Sun.COM Wed Mar 18 14:49:48 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 18 Mar 2009 14:49:48 -0700 Subject: Request for reviews (S): 6819176: Compressed oops causes assert(n != 0L,"Bad immediate dominator info.") Message-ID: <49C16C7C.3000203@sun.com> http://cr.openjdk.java.net/~kvn/6819176/webrev.00 Fixed 6819176: Compressed oops causes assert(n != 0L,"Bad immediate dominator info.") Problem: PhiNode::Ideal has very unsafe optimization which tries to move DecodeN through phi down in a hope that it could be consumed by an address expression or debug info. This optimization is incorrect since DecodeN is the type node and its type depends on the position in the graph. The assert is caused by this. Solution: Remove incorrect optimization. Reviewed by: Fix verified (y/n): y, bug test Other testing: JPRT From Vladimir.Kozlov at Sun.COM Wed Mar 18 15:50:08 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 18 Mar 2009 15:50:08 -0700 Subject: for (re-)review (M): 6814659: separable cleanups and subroutines for 6655638 In-Reply-To: <0B24EF23-64FF-41E3-9F3B-28A97357F70D@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <49AC893D.5080609@sun.com> <0B9D2B1A-BB61-4387-8866-FBC9EB036A53@Sun.COM> <3E9D1DE4-B24C-4CF0-9D33-42B1F235D780@sun.com> <49B9A677.7010704@sun.com> <221DB7BB-DB28-48F4-99E3-1C4FC0C72F9F@Sun.COM> <0B24EF23-64FF-41E3-9F3B-28A97357F70D@sun.com> Message-ID: <49C17AA0.7000702@sun.com> Looks good. Vladimir John Rose wrote: > I refreshed the webrev for the pre-method-handle cleanups, incorporating > reviewer comments. > http://cr.openjdk.java.net/~jrose/6814659/webrev.01/ > http://cr.openjdk.java.net/~jrose/6814659/00-to-01.diff.txt > > Changes since webrev.00: > - KlassHandles => SystemDictionaryHandles (never) > - RegisterConstant => RegisterOrConstant (never) > - delayed_value => delayed_value_impl, only the virtual overloading (jrose) > - update copyright headers to 2009 (twisti) > > Also, the index page is reorganized and there are a few more explanatory > comments here and there. > > -- John From Changpeng.Fang at Sun.COM Wed Mar 18 16:32:25 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Wed, 18 Mar 2009 16:32:25 -0700 Subject: Request for review (S): 6636138: UseSuperWord enabled failure In-Reply-To: <49B984F2.2060404@Sun.COM> References: <49B984F2.2060404@Sun.COM> Message-ID: <49C18489.7020003@Sun.COM> http://cr.openjdk.java.net/~cfang/6636138/webrev.01/ I add two small test case to help review (and updated webrev): ------------------------- Test1.java ------------------------- This test case shows the problem of superwordization of array copy. After unrolling, part of the loop look like: src[i] = i; dst[i] = 2; ref[i] = src[i]; // (1) src[i+1] = i+1; dst[i+1] = 2; ref[i+1] = src[i+1]; // (2) The loads src[i] and src[i+1] could be combined to use superword. We know src[i]'s memory input is dst[i] and src[i+1]'s memory input is dst[i+1]. The question is what's the memory state input for the corresponding superword load? The original approach used dst[i], which essentially move the superword load before the store[i+1], and thus generated the wrong value. My approach uses dst[i+1] which preserve the memory order. --------------------------- Test2.java --------------------------- This test case shows the problem of superwordization of stores. After unrolling, part of the loop look like: src[i] = src[i-1]; src[i-1] = invar; // (1) src[i-1] = src[i-2]; // where to schedule the store src[i-1] and load src[i-2] src[i-2] = invar; // (2) src[i-1] = invar and src[i-2] = invar can be combined to use superword store. The question is where to put the sandwitched src[i-1] = src[i-2] ? The original approach put all of them (src[i-1] and src[i-2]) before the superword and thus the src[i-1] was stored an incorrect value. My approach is based on dependence analysis. The result is the store src[i-1] is scheduled after the superword, and the load src[i-2] is scheduled before the superword. Thanks, Changpeng On 03/12/09 14:56, Changpeng Fang wrote: > This patch also fixes the problem in CR 6812207: Possible bug in a > floating point (float) arithmetic in 32-bit server HotSpot > > http://cr.openjdk.java.net/~cfang/6636138/webrev.00/ > > The Problem: > SuperWord scheduling ignored the memory dependence, and thus caused > memory order violation and thus > programs in CR 6636138 and CR 6812207 generated incorrect results. > > What in This Patch?: > I have implemented a new superword scheduling approach to adjust the > memory graph. For a store superword, > we move all sandwitched memory operations outside the pack based on > the dependence information. > For a load superword, we use the latest memory state for the pack. > > Tests: > JPRT scimark specjvm98 volano25 jetstream and test cases in CR > 6636138 and CR 6812207, and several small self-developed cases. > > > Thanks, > > Changpeng From vladimir.kozlov at sun.com Wed Mar 18 16:36:28 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 18 Mar 2009 23:36:28 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6772368: REGRESSION:tomcat crashed twice with JDK 7 Message-ID: <20090318233636.69CF8E2D4@hg.openjdk.java.net> Changeset: 039a914095f4 Author: kvn Date: 2009-03-18 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/039a914095f4 6772368: REGRESSION:tomcat crashed twice with JDK 7 Summary: Call make_block_at() with the original handler limits. Reviewed-by: never ! src/share/vm/ci/ciMethodBlocks.cpp From Vladimir.Kozlov at Sun.COM Wed Mar 18 18:15:33 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 18 Mar 2009 18:15:33 -0700 Subject: Request for review (S): 6636138: UseSuperWord enabled failure In-Reply-To: <49C18489.7020003@Sun.COM> References: <49B984F2.2060404@Sun.COM> <49C18489.7020003@Sun.COM> Message-ID: <49C19CB5.1000303@sun.com> Looks OK. Vladimir Changpeng Fang wrote: > http://cr.openjdk.java.net/~cfang/6636138/webrev.01/ > > I add two small test case to help review (and updated webrev): > ------------------------- > Test1.java > ------------------------- > This test case shows the problem of superwordization of array copy. > After unrolling, part > of the loop look like: > src[i] = i; > dst[i] = 2; > ref[i] = src[i]; // (1) > src[i+1] = i+1; > dst[i+1] = 2; > ref[i+1] = src[i+1]; // (2) > > The loads src[i] and src[i+1] could be combined to use superword. > We know src[i]'s memory input is dst[i] and src[i+1]'s memory input is > dst[i+1]. > The question is what's the memory state input for the corresponding > superword load? > The original approach used dst[i], which essentially move the superword > load before the store[i+1], > and thus generated the wrong value. > My approach uses dst[i+1] which preserve the memory order. > > --------------------------- > Test2.java > --------------------------- > This test case shows the problem of superwordization of stores. After > unrolling, part > of the loop look like: > src[i] = src[i-1]; > src[i-1] = invar; // (1) > src[i-1] = src[i-2]; // where to schedule the store src[i-1] and > load src[i-2] > src[i-2] = invar; // (2) > > src[i-1] = invar and src[i-2] = invar can be combined to use superword > store. The question is > where to put the sandwitched src[i-1] = src[i-2] ? > The original approach put all of them (src[i-1] and src[i-2]) before the > superword and thus the src[i-1] > was stored an incorrect value. > My approach is based on dependence analysis. The result is the store > src[i-1] is scheduled after the superword, > and the load src[i-2] is scheduled before the superword. > > > Thanks, > > Changpeng > > > > On 03/12/09 14:56, Changpeng Fang wrote: >> This patch also fixes the problem in CR 6812207: Possible bug in a >> floating point (float) arithmetic in 32-bit server HotSpot >> >> http://cr.openjdk.java.net/~cfang/6636138/webrev.00/ >> >> The Problem: >> SuperWord scheduling ignored the memory dependence, and thus caused >> memory order violation and thus >> programs in CR 6636138 and CR 6812207 generated incorrect results. >> >> What in This Patch?: >> I have implemented a new superword scheduling approach to adjust the >> memory graph. For a store superword, >> we move all sandwitched memory operations outside the pack based on >> the dependence information. >> For a load superword, we use the latest memory state for the pack. >> >> Tests: >> JPRT scimark specjvm98 volano25 jetstream and test cases in CR >> 6636138 and CR 6812207, and several small self-developed cases. >> >> >> Thanks, >> >> Changpeng > From gbenson at redhat.com Fri Mar 20 05:50:52 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 20 Mar 2009 08:50:52 -0400 Subject: Loop safepoints and backedge copies Message-ID: <20090320125051.GA30236@shell.devel.redhat.com> Hi all, I'm writing a compiler that uses the HotSpot's typeflow pass. Is it safe to say that for backwards branches (target bci <= current bci) you only need to insert a safepoint check when the block you are in is a backedge copy? Cheers, Gary -- http://gbenson.net/ From john.coomes at sun.com Thu Mar 19 21:28:27 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 20 Mar 2009 04:28:27 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 3 new changesets Message-ID: <20090320042832.78DDDE410@hg.openjdk.java.net> Changeset: d1525894c1a8 Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/d1525894c1a8 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! make/Makefile Changeset: 41a66a42791b Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/41a66a42791b Merge Changeset: e646890d18b7 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/e646890d18b7 Added tag jdk7-b51 for changeset 41a66a42791b ! .hgtags From john.coomes at sun.com Thu Mar 19 21:18:17 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 20 Mar 2009 04:18:17 +0000 Subject: hg: jdk7/hotspot-comp/corba: 11 new changesets Message-ID: <20090320041827.BEB27E402@hg.openjdk.java.net> Changeset: e2f388853a9d Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/e2f388853a9d 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! make/com/sun/corba/minclude/com_sun_corba_se_impl_dynamicany.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_encoding.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_ior.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_protocol.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_interceptor.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_monitoring.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_presentation_rmi.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_transport.jmk ! make/com/sun/corba/minclude/org_omg_CosNaming.jmk ! make/com/sun/corba/minclude/org_omg_DynamicAny.jmk ! make/com/sun/corba/minclude/org_omg_PortableInterceptor.jmk ! make/com/sun/corba/se/sources/Makefile ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs.gmk ! make/javax/xa/Makefile ! make/jprt.config ! make/org/omg/CORBA/Makefile ! src/share/classes/org/omg/CORBA/ir.idl ! src/share/classes/org/omg/DynamicAny/DynamicAny.idl Changeset: 3174f87bcd7c Author: xdono Date: 2009-03-09 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/3174f87bcd7c Merge Changeset: 9e6c48c2582d Author: jjg Date: 2009-02-26 18:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/9e6c48c2582d 6809563: corba build in JDK uses invalid bootclasspath for javah Reviewed-by: ohair ! make/common/shared/Defs-java.gmk Changeset: db35452e8965 Author: jjg Date: 2009-02-26 18:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/db35452e8965 6810915: Sun proprietary warnings in JDK build Reviewed-by: ohair ! make/Makefile ! make/common/shared/Defs-java.gmk Changeset: 082f59f5ac64 Author: tbell Date: 2009-03-02 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/082f59f5ac64 Merge Changeset: ec634b3aa302 Author: tbell Date: 2009-03-06 10:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/ec634b3aa302 Merge Changeset: c471ac1a1770 Author: tbell Date: 2009-03-09 23:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/c471ac1a1770 Merge Changeset: 53d5b45f73ab Author: ohair Date: 2009-03-11 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/53d5b45f73ab 6790292: BOOTDIR of jdk6 u12 will not work with jdk7 builds Reviewed-by: tbell ! make/common/Rules.gmk Changeset: 9c0cc0d0eca2 Author: ohair Date: 2009-03-11 17:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/9c0cc0d0eca2 6816311: Changes to allow builds with latest Windows SDK 6.1 on 64bit Windows 2003 Reviewed-by: tbell ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-windows.gmk ! src/windows/resource/version.rc Changeset: 3eb8f1047a74 Author: xdono Date: 2009-03-16 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/3eb8f1047a74 Merge Changeset: bec82237d694 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/bec82237d694 Added tag jdk7-b51 for changeset 3eb8f1047a74 ! .hgtags From john.coomes at sun.com Thu Mar 19 21:25:22 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 20 Mar 2009 04:25:22 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 3 new changesets Message-ID: <20090320042527.5E20BE40A@hg.openjdk.java.net> Changeset: 6698e1f801df Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/6698e1f801df 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! make/Makefile Changeset: ae890d80d5df Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/ae890d80d5df Merge Changeset: 69ad87dc25cb Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/69ad87dc25cb Added tag jdk7-b51 for changeset ae890d80d5df ! .hgtags From john.coomes at sun.com Thu Mar 19 21:15:16 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 20 Mar 2009 04:15:16 +0000 Subject: hg: jdk7/hotspot-comp: 6 new changesets Message-ID: <20090320041516.C5495E3FC@hg.openjdk.java.net> Changeset: 3398ae556a2a Author: ohair Date: 2009-01-31 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/3398ae556a2a 6791649: add "SKIP_MSIVAL2=true" to the Windows section of make/jprt.config Reviewed-by: tbell ! make/jdk-rules.gmk ! make/jprt.config ! make/jprt.gmk Changeset: a4fd1a33eb93 Author: xdono Date: 2009-02-27 15:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/a4fd1a33eb93 Merge Changeset: c2a7f3471532 Author: xdono Date: 2009-03-09 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/c2a7f3471532 Merge Changeset: 93c2600a45a4 Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/93c2600a45a4 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! Makefile ! make/Defs-internal.gmk ! make/jdk-rules.gmk ! make/jprt.config ! make/jprt.gmk Changeset: 0f0189d55ce4 Author: xdono Date: 2009-03-09 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/0f0189d55ce4 Merge Changeset: 4264c2fe6649 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/4264c2fe6649 Added tag jdk7-b51 for changeset 0f0189d55ce4 ! .hgtags From john.coomes at sun.com Thu Mar 19 21:32:46 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 20 Mar 2009 04:32:46 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 33 new changesets Message-ID: <20090320043929.E6FF6E41E@hg.openjdk.java.net> Changeset: 30bf00392b6d Author: ohair Date: 2009-01-31 17:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/30bf00392b6d 6799141: Build with --hash-style=both so that binaries can work on SuSE 10 Reviewed-by: tbell ! make/common/Defs-linux.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Compiler-sun.gmk + make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Platform.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk Changeset: dfb5a9a71c1c Author: xdono Date: 2009-02-27 15:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dfb5a9a71c1c Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java - src/share/lib/audio/soundbank.gm - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: d71e3cc6c4e7 Author: xdono Date: 2009-02-27 15:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d71e3cc6c4e7 Merge - src/solaris/classes/sun/nio/ch/FileDispatcher.java - src/solaris/native/sun/nio/ch/FileDispatcher.c - src/windows/classes/sun/nio/ch/FileDispatcher.java - src/windows/native/sun/nio/ch/FileDispatcher.c Changeset: abfccc052872 Author: xdono Date: 2009-03-03 15:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/abfccc052872 Merge Changeset: 83c0526fb9c9 Author: xdono Date: 2009-03-09 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/83c0526fb9c9 Merge Changeset: ca0976a15868 Author: xdono Date: 2009-03-09 13:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ca0976a15868 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/x509/AuthorityInfoAccessExtension.java ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h ! src/solaris/native/java/net/NetworkInterface.c Changeset: b1e3e3b8e6b2 Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b1e3e3b8e6b2 Merge Changeset: 266358f13a6f Author: dl Date: 2009-02-24 14:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/266358f13a6f 6803402: Race condition in AbstractQueuedSynchronizer Summary: Read fields in reverse initialization order Reviewed-by: martin ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java Changeset: f9c187839d72 Author: kevinw Date: 2009-02-24 19:03 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f9c187839d72 6809463: Missing license header in test LargeZipFile.java Reviewed-by: alanb ! test/java/util/zip/ZipFile/LargeZipFile.java Changeset: dde3fe2e8164 Author: kevinw Date: 2009-02-25 14:32 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dde3fe2e8164 Merge Changeset: 2fb53eb9df14 Author: mchung Date: 2009-02-26 14:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2fb53eb9df14 6801467: Defer get the launcher resource bundle until it's needed Summary: Lazily initialize the launcher resource bundle Reviewed-by: ksrini, darcy ! src/share/classes/sun/launcher/LauncherHelper.java Changeset: 4f0b6455a977 Author: jjg Date: 2009-02-26 18:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4f0b6455a977 6810915: Sun proprietary warnings in JDK build Reviewed-by: ohair ! make/common/shared/Defs-java.gmk ! make/docs/Makefile ! make/javax/swing/beaninfo/SwingBeans.gmk Changeset: de1d02ad2d1d Author: mchung Date: 2009-02-27 13:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/de1d02ad2d1d 6799689: Make sun.misc.FloatingDecimal.hexFloatPattern static field initialized lazily Summary: Lazily initialize the hexFloatPattern static field Reviewed-by: darcy ! src/share/classes/sun/misc/FloatingDecimal.java Changeset: 0da45c759116 Author: mchung Date: 2009-02-27 16:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0da45c759116 6809504: Remove enctype="text/xml" from the offline registration page Summary: Remove enctype="text/xml" from register.html and other localized versions Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/resources/register.html ! src/share/classes/com/sun/servicetag/resources/register_ja.html ! src/share/classes/com/sun/servicetag/resources/register_zh_CN.html Changeset: b656e842e1be Author: xuelei Date: 2009-03-02 23:17 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b656e842e1be 6549506: Specification of Permission.toString() method contradicts with JDK implementation Summary: update the spec, and add double quotes around component. Reviewed-by: weijun ! src/share/classes/java/security/Permission.java + test/java/security/Permission/ToString.java Changeset: 7546743f4cc0 Author: tbell Date: 2009-03-02 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7546743f4cc0 Merge Changeset: 07d2550f5c84 Author: mchung Date: 2009-03-03 19:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/07d2550f5c84 6799230: Lazily load java.lang.annotation.Annotation class Summary: Remove the static EMPTY_ANNOTATION_ARRAY field; add AnnotationParser.toArray method Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java Changeset: a8d9e8cb38bb Author: weijun Date: 2009-03-04 15:09 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a8d9e8cb38bb 6705872: SecureRandom number init is taking too long on a java.io.tmpdir with a large number of files. Reviewed-by: xuelei, alanb ! src/share/classes/sun/security/provider/SeedGenerator.java Changeset: 94d02968a504 Author: chegar Date: 2009-03-04 13:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/94d02968a504 6775145: ClassLoaderUtil.releaseLoader calls System.out.println ("classLoader = " + classLoader) Summary: Remove System.out debugging statements Reviewed-by: michaelm ! src/share/classes/sun/misc/ClassLoaderUtil.java Changeset: 03001e92d155 Author: chegar Date: 2009-03-04 13:36 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/03001e92d155 6737323: Typo in javadoc for SocketPermission Summary: Remove redundant line form class description Reviewed-by: jccollet ! src/share/classes/java/net/SocketPermission.java Changeset: 6568cd51ae12 Author: sherman Date: 2009-03-04 09:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6568cd51ae12 6812879: Excess code line in ArrayList method Summary: Removed the line of "oldData" which is no longer used. Reviewed-by: martin ! src/share/classes/java/util/ArrayList.java Changeset: 97da21737d9e Author: weijun Date: 2009-03-05 14:49 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/97da21737d9e 6813402: keytool cannot -printcert entries without extensions Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/keytool/NoExtNPE.sh Changeset: da9d0283a496 Author: valeriep Date: 2009-03-03 19:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/da9d0283a496 6812738: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes with PCKS11 provider Summary: Removed finalize() and add more error handling to native code Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h Changeset: 7b3cfde54812 Author: valeriep Date: 2009-03-05 11:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7b3cfde54812 Merge Changeset: 2b6cf18aeb6f Author: tbell Date: 2009-03-06 10:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2b6cf18aeb6f Merge Changeset: c769c46c27ce Author: mullan Date: 2009-03-09 09:46 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c769c46c27ce 6787130: java.policy file contains stale link to http://java.sun.com/notes Reviewed-by: weijun ! src/share/lib/security/java.policy Changeset: aa48deaf9af4 Author: mullan Date: 2009-03-09 09:56 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/aa48deaf9af4 Merge Changeset: 175504cc095d Author: tbell Date: 2009-03-09 23:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/175504cc095d Merge Changeset: 711a9fb838d1 Author: ohair Date: 2009-03-16 11:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/711a9fb838d1 6816311: Changes to allow builds with latest Windows SDK 6.1 on 64bit Windows 2003 Summary: These changes create a preference for the newer 6.1 SDK on Windows. Reviewed-by: tbell ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! src/windows/native/sun/windows/awt.rc ! src/windows/resource/version.rc Changeset: ece878b04159 Author: xdono Date: 2009-03-16 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ece878b04159 Merge Changeset: bdb4b0b28407 Author: ohair Date: 2009-03-17 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bdb4b0b28407 6818565: Regression with fix 6816311: COMPILER_VERSION -> REQUIRED_COMPILER_VERSION Reviewed-by: tbell - make/common/shared/Compiler.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs.gmk Changeset: fea0898259ae Author: ohair Date: 2009-03-17 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fea0898259ae Merge Changeset: bcbeadb4a5d7 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bcbeadb4a5d7 Added tag jdk7-b51 for changeset fea0898259ae ! .hgtags From vladimir.kozlov at sun.com Thu Mar 19 12:49:23 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 19 Mar 2009 19:49:23 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 22 new changesets Message-ID: <20090319195004.C0D9CE342@hg.openjdk.java.net> Changeset: 87fa6e083d82 Author: apetrusenko Date: 2009-03-10 00:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/87fa6e083d82 6760309: G1: update remembered sets during Full GCs Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: fcf566137dbf Author: tonyp Date: 2009-03-12 11:34 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fcf566137dbf Merge Changeset: d61c7c22b25c Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d61c7c22b25c Added tag jdk7-b48 for changeset bcb33806d186 ! .hgtags Changeset: 8b22ccb5aba2 Author: trims Date: 2009-02-25 23:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8b22ccb5aba2 Merge Changeset: dae503d9f04c Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dae503d9f04c Added tag jdk7-b49 for changeset 8b22ccb5aba2 ! .hgtags Changeset: 67f831f73d34 Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/67f831f73d34 Added tag jdk7-b50 for changeset dae503d9f04c ! .hgtags Changeset: f9d5cfc2afa2 Author: xdono Date: 2009-02-27 15:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f9d5cfc2afa2 Merge Changeset: f5eac45b1641 Author: xdono Date: 2009-03-09 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f5eac45b1641 Merge Changeset: 0fbdb4381b99 Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0fbdb4381b99 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! agent/src/os/linux/ps_core.c ! agent/src/os/solaris/proc/saproc.cpp ! make/hotspot_version ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/adlc.make ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.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/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/jni_x86.h ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classFileParser.cpp ! 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/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_shared ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/gc_implementation/shared/ageTable.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/includeDB_gc ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/libadt/dict.cpp ! src/share/vm/libadt/port.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp ! src/share/vm/utilities/workgroup.hpp ! test/Makefile ! test/compiler/6757316/Test6757316.java ! test/compiler/6758234/Test6758234.java ! test/compiler/6775880/Test.java ! test/compiler/6778657/Test.java Changeset: ce2272390558 Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ce2272390558 Merge Changeset: 7bb995fbd3c0 Author: trims Date: 2009-03-12 18:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7bb995fbd3c0 Merge ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_gc ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/libadt/dict.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: 2581d90c6c9b Author: trims Date: 2009-03-12 18:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2581d90c6c9b 6816970: Bump HS15 build number to 03 Summary: Update the HS15 Build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ec1a6dc46005 Author: iveresov Date: 2009-03-12 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ec1a6dc46005 6816433: Test G1 and ParOld in JPRT Reviewed-by: jmasa, never, ysr ! make/jprt.properties Changeset: 4018e98c778a Author: tonyp Date: 2009-03-13 16:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4018e98c778a Merge Changeset: 09f82af55c3e Author: ysr Date: 2009-03-13 13:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/09f82af55c3e 6808322: ParNew, CMS, G1: ParGCAllocBuffer overflow Summary: Correct the overflow check in ParGCAllocBuffer::allocate(); simplify ParGCAllocBuffer::undo_allocation(). Reviewed-by: apetrusenko, jcoomes, jmasa, minqi, phh, tonyp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: fe2441500281 Author: ysr Date: 2009-03-13 17:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fe2441500281 Merge Changeset: 6c4cea9bfa11 Author: tonyp Date: 2009-03-15 22:03 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6c4cea9bfa11 6604422: G1: re-use half-promoted regions 6728271: G1: Cleanup G1CollectedHeap::get_gc_alloc_regions() Summary: It allows the last half-full region to be allocated to during a GC to be reused during the next GC. Reviewed-by: apetrusenko, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 25e146966e7c Author: iveresov Date: 2009-03-16 08:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/25e146966e7c 6817419: G1: Enable extensive verification for humongous regions Summary: Enabled full verification for humongous regions. Also made sure that the VerifyAfterGC works with deferred updates and G1HRRSFlushLogBuffersOnVerify. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 2a5da27ccae9 Author: tonyp Date: 2009-03-16 10:52 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2a5da27ccae9 6816154: G1: introduce flags to enable/disable RSet updating and scanning Summary: Introduces two flags, -XX:-/+G1EnableParallelRSetUpdating and -XX:-/+G1EnableParallelRSetScanning, to turn on/off the "band aid" fix that serializes RSet updating / scanning during GCs. Reviewed-by: iveresov ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 922c573ea67d Author: iveresov Date: 2009-03-16 17:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/922c573ea67d 6815683: G1: SEGV during marking Summary: We should mark the regions that continue humongous regions as live if the first region is live. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: ba50942c8138 Author: tonyp Date: 2009-03-18 11:37 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ba50942c8138 Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: bd441136a5ce Author: kvn Date: 2009-03-19 09:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bd441136a5ce Merge ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/includeDB_core ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp From john.coomes at sun.com Thu Mar 19 21:48:55 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 20 Mar 2009 04:48:55 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 13 new changesets Message-ID: <20090320044916.F323FE42B@hg.openjdk.java.net> Changeset: 03bcd66bd8e7 Author: xdono Date: 2009-03-09 13:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/03bcd66bd8e7 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! make/build.properties ! make/build.xml ! make/netbeans/langtools/build.xml ! make/netbeans/langtools/nbproject/project.xml ! make/netbeans/langtools/nbproject/standard-context-menu-items.ent ! make/netbeans/langtools/nbproject/standard-ide-actions.ent ! make/tools/SelectTool/SelectToolTask.java ! src/share/classes/com/sun/tools/apt/comp/AnnotationProcessingError.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/comp/UsageMessageNeededException.java ! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java ! src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java ! src/share/classes/com/sun/tools/classfile/Annotation.java ! src/share/classes/com/sun/tools/classfile/AttributeException.java ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/ConstantPoolException.java ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/classfile/DescriptorException.java ! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/Messages.java ! src/share/classes/com/sun/tools/javac/code/Types.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/Infer.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javap/InternalError.java ! src/share/classes/sun/tools/javap/JavapPrinter.java ! test/tools/javac/6668794/badClass/Test.java ! test/tools/javac/cast/6558559/T6558559a.java ! test/tools/javac/cast/6558559/T6558559b.java ! test/tools/javac/cast/6665356/T6665356.java ! test/tools/javac/generics/6723444/T6723444.java ! test/tools/javac/generics/6729401/T6729401.java ! test/tools/javac/generics/rare/6665356/T6665356.java ! test/tools/javac/processing/model/testgetallmembers/Main.java ! test/tools/javadoc/6176978/T6176978.java ! test/tools/javadoc/6176978/X.java Changeset: 2c0076945b1a Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/2c0076945b1a Merge Changeset: 435d5d9bb87d Author: darcy Date: 2009-02-24 17:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/435d5d9bb87d 6501749: 6501749 Filer should state connection between created files and root elements Reviewed-by: jjg ! src/share/classes/javax/annotation/processing/Filer.java Changeset: 1fbc1cc6e260 Author: darcy Date: 2009-02-24 17:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/1fbc1cc6e260 6498938: Faulty comparison of TypeMirror objects in getElementsAnnotatedWith implementation Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java + test/tools/javac/processing/environment/round/Foo.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java Changeset: 5240b1120530 Author: bpatel Date: 2009-02-27 18:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/5240b1120530 6786690: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - DL tag and nesting issue Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHref/TestHref.java + test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C1.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C2.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C3.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C4.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C5.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testThrowsTag/TestThrowsTag.java Changeset: 2f4c4900ca2b Author: tbell Date: 2009-03-02 15:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/2f4c4900ca2b Merge Changeset: 850869f70213 Author: mcimadamore Date: 2009-03-05 17:24 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/850869f70213 6467183: javac fails to raise unchecked warning on cast of parameterized generic subclass Summary: cleanup code for generating unchecked cast warnings Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/6467183/T6467183a.java + test/tools/javac/cast/6467183/T6467183a.out + test/tools/javac/cast/6467183/T6467183b.java Changeset: 84a18d7da478 Author: mcimadamore Date: 2009-03-05 17:24 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/84a18d7da478 6804733: javac generates spourious diagnostics for ill-formed type-variable bounds Summary: fixed algorithm for checking cycles in typevar declarations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/typevars/6804733/T6804733.java + test/tools/javac/generics/typevars/6804733/T6804733.out Changeset: 9711a6c2db7e Author: mcimadamore Date: 2009-03-05 17:25 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/9711a6c2db7e 6807255: LineNumberTable wrong if enhanced-for-loops are used Summary: end position of iterable for-each loop was not set properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java Changeset: 86b60aa941c6 Author: mcimadamore Date: 2009-03-05 17:25 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/86b60aa941c6 6799605: Basic/Raw formatters should use type/symbol printer instead of toString() Summary: create new combo type/symbol visitor printer used by all diagnostic formatters Reviewed-by: jjg + src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Types.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/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java + test/tools/javac/Diagnostics/6799605/T6799605.java + test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/NestedInnerClassNames.out ! test/tools/javac/T6241723.out ! test/tools/javac/depDocComment/SuppressDeprecation.out ! test/tools/javac/mandatoryWarnings/deprecated/Test3.out ! test/tools/javac/mandatoryWarnings/deprecated/Test3b.out ! test/tools/javac/mandatoryWarnings/deprecated/Test4.out ! test/tools/javac/mandatoryWarnings/deprecated/Test4b.out ! test/tools/javac/mandatoryWarnings/deprecated/Test4c.out ! test/tools/javac/mandatoryWarnings/deprecated/Test4d.out ! test/tools/javac/positions/T6253161.out ! test/tools/javac/positions/T6253161a.out ! test/tools/javac/warnings/Deprecation.lintAll.out ! test/tools/javac/warnings/Deprecation.lintDeprecation.out Changeset: 6d00caa683b3 Author: tbell Date: 2009-03-06 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6d00caa683b3 Merge Changeset: 8c55d5b0ed71 Author: tbell Date: 2009-03-09 23:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/8c55d5b0ed71 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.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/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java Changeset: 29329051d483 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/29329051d483 Added tag jdk7-b51 for changeset 8c55d5b0ed71 ! .hgtags From Thomas.Rodriguez at Sun.COM Fri Mar 20 10:09:39 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 20 Mar 2009 10:09:39 -0700 Subject: Loop safepoints and backedge copies In-Reply-To: <20090320125051.GA30236@shell.devel.redhat.com> References: <20090320125051.GA30236@shell.devel.redhat.com> Message-ID: <8D2A975B-DAB3-422A-A98B-6C2E35283D51@sun.com> > I'm writing a compiler that uses the HotSpot's typeflow pass. > > Is it safe to say that for backwards branches (target bci <= current > bci) you only need to insert a safepoint check when the block you are > in is a backedge copy? The specific requirement is that any cycle in the control flow graph has to have a safepoint somewhere in it. The rule we use is that we emit a safepoint on any branch that may go backwards. A block in ciTypeFlow that is marked as a backedge_copy is actually the loop backedge of a zero trip loop so it should be possible to place your safepoint in that block. Unfortunately not all backedges are cloned so you can't simply restrict safepoint insertion to backedge_copy blocks. If you are worried about inserting useless safepoints you are probably better off having an optimization that removes useless ones. If a loop has a call in it then it doesn't need a separate safepoint poll and eliminating that is a good idea. Also any safepoint poll outside of a loop is useless. tom > > > Cheers, > Gary > > -- > http://gbenson.net/ From gbenson at redhat.com Fri Mar 20 12:01:30 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 20 Mar 2009 19:01:30 +0000 Subject: Loop safepoints and backedge copies In-Reply-To: <8D2A975B-DAB3-422A-A98B-6C2E35283D51@sun.com> References: <20090320125051.GA30236@shell.devel.redhat.com> <8D2A975B-DAB3-422A-A98B-6C2E35283D51@sun.com> Message-ID: <20090320190129.GA21401@redhat.com> Tom Rodriguez wrote: > > Is it safe to say that for backwards branches (target bci <= > > current bci) you only need to insert a safepoint check when the > > block you are in is a backedge copy? > > The specific requirement is that any cycle in the control flow graph > has to have a safepoint somewhere in it. The rule we use is that we > emit a safepoint on any branch that may go backwards. A block in > ciTypeFlow that is marked as a backedge_copy is actually the loop > backedge of a zero trip loop so it should be possible to place your > safepoint in that block. Unfortunately not all backedges are cloned > so you can't simply restrict safepoint insertion to backedge_copy > blocks. If you are worried about inserting useless safepoints you > are probably better off having an optimization that removes useless > ones. If a loop has a call in it then it doesn't need a separate > safepoint poll and eliminating that is a good idea. Also any > safepoint poll outside of a loop is useless. That's interesting, what is it that determines whether a backedge is cloned or not? And also, out of interest, what benefit does having the backedge copies bring? Cheers, Gary -- http://gbenson.net/ From Thomas.Rodriguez at Sun.COM Fri Mar 20 20:24:56 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 20 Mar 2009 20:24:56 -0700 Subject: review (XS) for 6805522 Message-ID: http://cr.openjdk.java.net/~never/6805522 From Vladimir.Kozlov at Sun.COM Fri Mar 20 21:34:24 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 20 Mar 2009 21:34:24 -0700 Subject: review (XS) for 6805522 In-Reply-To: References: Message-ID: <49C46E50.4090503@sun.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6805522 > From Vladimir.Kozlov at Sun.COM Fri Mar 20 23:31:01 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 20 Mar 2009 23:31:01 -0700 Subject: Request for reviews (S): 6820514: meet not symmetric failure in ctw Message-ID: <49C489A5.6000309@sun.com> http://cr.openjdk.java.net/~kvn/6820514/webrev.00 Fixed 6820514: meet not symmetric failure in ctw Problem: Missing instance_id meet for the case j.l.Object:NotNull meets unloaded instance klass. Solution: Add missing code. Reviewed by: Fix verified (y/n): y, ctw test from bug Other testing: JPRT From john.rose at sun.com Sat Mar 21 01:53:54 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Sat, 21 Mar 2009 08:53:54 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6814659: separable cleanups and subroutines for 6655638 Message-ID: <20090321085356.6A81BE664@hg.openjdk.java.net> Changeset: c89f86385056 Author: jrose Date: 2009-03-20 23:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c89f86385056 6814659: separable cleanups and subroutines for 6655638 Summary: preparatory but separable changes for method handles Reviewed-by: kvn, never ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp From John.Rose at Sun.COM Sat Mar 21 22:21:35 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 21 Mar 2009 22:21:35 -0700 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: <491E1E13-BE33-4096-873D-19BEEA5FE0D0@sun.com> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <491E1E13-BE33-4096-873D-19BEEA5FE0D0@sun.com> Message-ID: On Mar 11, 2009, at 7:10 PM, Tom Rodriguez wrote: > I've done all the easy stuff and I'm onto the methodHandles* files > but I thought I'd give you these first. I've updated the webrev to take your comments into account: http://cr.openjdk.java.net/~jrose/6655638/webrev.02/ This includes a simplification of some of the throw logic. I moved it into mH_.cpp where it belongs: http://cr.openjdk.java.net/~jrose/6655638/01-to-02-move-path-setup -- John From Thomas.Rodriguez at Sun.COM Mon Mar 23 13:07:57 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 23 Mar 2009 13:07:57 -0700 Subject: Request for reviews (S): 6820514: meet not symmetric failure in ctw In-Reply-To: <49C489A5.6000309@sun.com> References: <49C489A5.6000309@sun.com> Message-ID: There's a nice comment above this code and it would be nice if the table and code agreed in both order and results. // Meet unloaded class with java/lang/Object // // Meet // | Unloaded Class // Object | TOP | AnyNull | Constant | NotNull | BOTTOM | // =================================================================== // TOP | ..........................Unloaded......................| // AnyNull | U-AN |................Unloaded......................| // Constant | ... O-NN .................................. | O- BOT | // NotNull | ... O-NN .................................. | O- BOT | // BOTTOM | ........................Object- BOTTOM ..................| Your changes appear to make this line: // AnyNull | U-AN |................Unloaded......................| become // AnyNull |........................... U- AN ......................| The -AN part isn't quite true since we're returning the results of meet_ptr which uses the table below. AnyNull meeting NotNull returns NotNull. The Constant line in the comments seems to be wrong too. const TypePtr::PTR TypePtr::ptr_meet[TypePtr::lastPTR] [TypePtr::lastPTR] = { // TopPTR, AnyNull, Constant, Null, NotNull, BotPTR, { /* Top */ TopPTR, AnyNull, Constant, Null, NotNull, BotPTR,}, { /* AnyNull */ AnyNull, AnyNull, Constant, BotPTR, NotNull, BotPTR,}, { /* Constant*/ Constant, Constant, Constant, BotPTR, NotNull, BotPTR,}, { /* Null */ Null, BotPTR, BotPTR, Null, BotPTR, BotPTR,}, { /* NotNull */ NotNull, NotNull, NotNull, BotPTR, NotNull, BotPTR,}, { /* BotPTR */ BotPTR, BotPTR, BotPTR, BotPTR, BotPTR, BotPTR,} }; The code itself looks right to me after much rereading of the meet logic. tom On Mar 20, 2009, at 11:31 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6820514/webrev.00 > > Fixed 6820514: meet not symmetric failure in ctw > > Problem: > Missing instance_id meet for the case j.l.Object:NotNull meets > unloaded instance klass. > > Solution: > Add missing code. > > Reviewed by: > > Fix verified (y/n): y, ctw test from bug > > Other testing: > JPRT > From Thomas.Rodriguez at Sun.COM Mon Mar 23 13:39:59 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 23 Mar 2009 13:39:59 -0700 Subject: Loop safepoints and backedge copies In-Reply-To: <20090320190129.GA21401@redhat.com> References: <20090320125051.GA30236@shell.devel.redhat.com> <8D2A975B-DAB3-422A-A98B-6C2E35283D51@sun.com> <20090320190129.GA21401@redhat.com> Message-ID: > That's interesting, what is it that determines whether a backedge is > cloned or not? And also, out of interest, what benefit does having > the backedge copies bring? The cloning in ciTypeFLow is really just a helper to get loop shapes nicer at the beginning of parse. It's converting relatively simply loops into what's often called a zero trip loop, which is basically a guarded do/while. So this, which is just a translation of a for loop: int i = 0; while (i < n) { body(); i++; } becomes: int i = 0; if (i < n) { do { body(); i++; while (i < n); } The nice thing about this is that it provide a place for loop invariant values to be computed where it's guaranteed that you will execute the body at least one. In ciTypeFlow this is don't for simply loops only. Check out is_clonable_exit. tom > > > Cheers, > Gary > > -- > http://gbenson.net/ From Vladimir.Kozlov at Sun.COM Mon Mar 23 14:14:28 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 23 Mar 2009 14:14:28 -0700 Subject: Request for reviews (S): 6820514: meet not symmetric failure in ctw In-Reply-To: References: <49C489A5.6000309@sun.com> Message-ID: <49C7FBB4.3010605@sun.com> No, it is not true. The original comment's line is still true > // AnyNull | U-AN |................Unloaded......................| meet_ptr() maps almost everything to the original PRT: > // TopPTR, AnyNull, Constant, Null, NotNull, BotPTR, > { /* AnyNull */ AnyNull, AnyNull, Constant, BotPTR, NotNull, BotPTR,}, except TOP which corresponds to the special case in the code table and NULL which is not in the table. Vladimir Tom Rodriguez wrote: > There's a nice comment above this code and it would be nice if the table and code agreed in both order and results. > > // Meet unloaded class with java/lang/Object > // > // Meet > // | Unloaded Class > // Object | TOP | AnyNull | Constant | NotNull | BOTTOM | > // =================================================================== > // TOP | ..........................Unloaded......................| > // AnyNull | U-AN |................Unloaded......................| > // Constant | ... O-NN .................................. | O-BOT | > // NotNull | ... O-NN .................................. | O-BOT | > // BOTTOM | ........................Object-BOTTOM ..................| > > Your changes appear to make this line: > > // AnyNull | U-AN |................Unloaded......................| > > become > > // AnyNull |........................... U-AN ......................| > > The -AN part isn't quite true since we're returning the results of meet_ptr which uses the table below. AnyNull meeting NotNull returns NotNull. The Constant line in the comments seems to be wrong too. > > const TypePtr::PTR TypePtr::ptr_meet[TypePtr::lastPTR][TypePtr::lastPTR] = { > // TopPTR, AnyNull, Constant, Null, NotNull, BotPTR, > { /* Top */ TopPTR, AnyNull, Constant, Null, NotNull, BotPTR,}, > { /* AnyNull */ AnyNull, AnyNull, Constant, BotPTR, NotNull, BotPTR,}, > { /* Constant*/ Constant, Constant, Constant, BotPTR, NotNull, BotPTR,}, > { /* Null */ Null, BotPTR, BotPTR, Null, BotPTR, BotPTR,}, > { /* NotNull */ NotNull, NotNull, NotNull, BotPTR, NotNull, BotPTR,}, > { /* BotPTR */ BotPTR, BotPTR, BotPTR, BotPTR, BotPTR, BotPTR,} > }; > > The code itself looks right to me after much rereading of the meet logic. > > tom > > > On Mar 20, 2009, at 11:31 PM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6820514/webrev.00 >> >> Fixed 6820514: meet not symmetric failure in ctw >> >> Problem: >> Missing instance_id meet for the case j.l.Object:NotNull meets >> unloaded instance klass. >> >> Solution: >> Add missing code. >> >> Reviewed by: >> >> Fix verified (y/n): y, ctw test from bug >> >> Other testing: >> JPRT >> From Thomas.Rodriguez at Sun.COM Mon Mar 23 14:43:31 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 23 Mar 2009 14:43:31 -0700 Subject: Request for reviews (S): 6820514: meet not symmetric failure in ctw In-Reply-To: <49C7FBB4.3010605@sun.com> References: <49C489A5.6000309@sun.com> <49C7FBB4.3010605@sun.com> Message-ID: <0E3AF265-C12D-4BE2-9090-812540246840@Sun.COM> On Mar 23, 2009, at 2:14 PM, Vladimir Kozlov wrote: > No, it is not true. The original comment's line is still true Sorry, my original comment about what it changed it to was wrong. I'd rewritten this several times and forgot to correct that. The original comment was wrong and it's still wrong for your change. > > > > // AnyNull | U-AN > |................Unloaded......................| > > meet_ptr() maps almost everything to the original PRT: > > > // TopPTR, AnyNull, Constant, Null, NotNull, > BotPTR, > > { /* AnyNull */ AnyNull, AnyNull, Constant, BotPTR, NotNull, > BotPTR,}, Which means that the comment should be: >> // Object | TOP | AnyNull | Constant | NotNull | >> BOTTOM | >> // AnyNull |....... U-AN .........| U-Con | U-NN | >> U-Bot | The AnyNull case never returns unloaded unchanged, except for the AN/ AN case, and having the word unloaded in the table implies that it simply returns it. My comment about the Constant line can be ignored too since it ignores the results of the meet_ptr. I might like the code better is the meet_ptr call was moved to it's uses since it's commonly completely ignored. tom > > > except TOP which corresponds to the special case in the code table > and NULL which > is not in the table. > > Vladimir > > Tom Rodriguez wrote: >> There's a nice comment above this code and it would be nice if the >> table and code agreed in both order and results. >> // Meet unloaded class with java/lang/Object >> // >> // Meet >> // | Unloaded Class >> // Object | TOP | AnyNull | Constant | NotNull | >> BOTTOM | >> // >> =================================================================== >> // TOP >> | ..........................Unloaded......................| >> // AnyNull | U-AN >> |................Unloaded......................| >> // Constant | ... O-NN .................................. | >> O-BOT | >> // NotNull | ... O-NN .................................. | >> O-BOT | >> // BOTTOM | ........................Object- >> BOTTOM ..................| >> Your changes appear to make this line: >> // AnyNull | U-AN >> |................Unloaded......................| >> become >> // AnyNull |........................... U- >> AN ......................| >> The -AN part isn't quite true since we're returning the results of >> meet_ptr which uses the table below. AnyNull meeting NotNull >> returns NotNull. The Constant line in the comments seems to be >> wrong too. >> const TypePtr::PTR TypePtr::ptr_meet[TypePtr::lastPTR] >> [TypePtr::lastPTR] = { >> // TopPTR, AnyNull, Constant, Null, NotNull, >> BotPTR, >> { /* Top */ TopPTR, AnyNull, Constant, Null, NotNull, >> BotPTR,}, >> { /* AnyNull */ AnyNull, AnyNull, Constant, BotPTR, NotNull, >> BotPTR,}, >> { /* Constant*/ Constant, Constant, Constant, BotPTR, NotNull, >> BotPTR,}, >> { /* Null */ Null, BotPTR, BotPTR, Null, BotPTR, >> BotPTR,}, >> { /* NotNull */ NotNull, NotNull, NotNull, BotPTR, NotNull, >> BotPTR,}, >> { /* BotPTR */ BotPTR, BotPTR, BotPTR, BotPTR, BotPTR, >> BotPTR,} >> }; >> The code itself looks right to me after much rereading of the meet >> logic. >> tom >> On Mar 20, 2009, at 11:31 PM, Vladimir Kozlov wrote: >>> >>> http://cr.openjdk.java.net/~kvn/6820514/webrev.00 >>> >>> Fixed 6820514: meet not symmetric failure in ctw >>> >>> Problem: >>> Missing instance_id meet for the case j.l.Object:NotNull meets >>> unloaded instance klass. >>> >>> Solution: >>> Add missing code. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, ctw test from bug >>> >>> Other testing: >>> JPRT >>> From thomas.rodriguez at sun.com Mon Mar 23 16:35:05 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Mon, 23 Mar 2009 23:35:05 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6805522: Server VM fails with assertion (block1->start() != block2->start(), "successors have unique bcis") Message-ID: <20090323233509.817D6E756@hg.openjdk.java.net> Changeset: ebebd376f657 Author: never Date: 2009-03-23 13:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ebebd376f657 6805522: Server VM fails with assertion (block1->start() != block2->start(),"successors have unique bcis") Reviewed-by: kvn ! src/share/vm/ci/ciTypeFlow.cpp From Vladimir.Kozlov at Sun.COM Mon Mar 23 18:16:08 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 23 Mar 2009 18:16:08 -0700 Subject: Request for reviews (S): 6820514: meet not symmetric failure in ctw In-Reply-To: <0E3AF265-C12D-4BE2-9090-812540246840@Sun.COM> References: <49C489A5.6000309@sun.com> <49C7FBB4.3010605@sun.com> <0E3AF265-C12D-4BE2-9090-812540246840@Sun.COM> Message-ID: <49C83458.6010808@sun.com> Tom, Yes, you are right, the code for AnyNull case does not return the original "unloaded" type. It returns the meet type with meet PTR, offset and instance_id, "false" klass exactness and NULL for const_oop. The exactness and const_oop could be wrong. At the beginning I wanted just fix the "original" original source at the switch end and remove one which was added later. In this case it matches the comment and fix the bug without calling meet methods: assert(loaded->ptr() != TypePtr::Null, "insanity check"); // if( loaded->ptr() == TypePtr::TopPTR ) { return unloaded; } - else if (loaded->ptr() == TypePtr::AnyNull) { return TypeInstPtr::make( ptr, unloaded->klass() ); } else if (loaded->ptr() == TypePtr::BotPTR ) { return TypeInstPtr::BOTTOM; } else if (loaded->ptr() == TypePtr::Constant || loaded->ptr() == TypePtr::NotNull) { if (unloaded->ptr() == TypePtr::BotPTR ) { return TypeInstPtr::BOTTOM; } else { return TypeInstPtr::NOTNULL; } } - else if( unloaded->ptr() == TypePtr::TopPTR ) { return unloaded; } - + assert(loaded->ptr() == TypePtr::AnyNull, "insanity check"); + if( unloaded->ptr() != TypePtr::TopPTR ) { return unloaded; } return unloaded->cast_to_ptr_type(TypePtr::AnyNull)->is_instptr(); } But I am not sure it is correct. Note, the original check if( unloaded->ptr() == TypePtr::TopPTR ) was wrong, it should be "!=". Because of this bug, I think, the additional code (with the explicit AnyNull check) was added to fix it. Also I can't move meet_ptr() since it is also used below this code. Thanks, Vladimir Tom Rodriguez wrote: > On Mar 23, 2009, at 2:14 PM, Vladimir Kozlov wrote: > >> No, it is not true. The original comment's line is still true > > Sorry, my original comment about what it changed it to was wrong. I'd rewritten this several times and forgot to correct that. The original comment was wrong and it's still wrong for your change. > >> >> >> > // AnyNull | U-AN |................Unloaded......................| >> >> meet_ptr() maps almost everything to the original PRT: >> >> > // TopPTR, AnyNull, Constant, Null, NotNull, BotPTR, >> > { /* AnyNull */ AnyNull, AnyNull, Constant, BotPTR, NotNull, BotPTR,}, > > Which means that the comment should be: > >>> // Object | TOP | AnyNull | Constant | NotNull | BOTTOM | > >>> // AnyNull |....... U-AN .........| U-Con | U-NN | U-Bot | > > The AnyNull case never returns unloaded unchanged, except for the AN/AN case, and having the word unloaded in the table implies that it simply returns it. > > My comment about the Constant line can be ignored too since it ignores the results of the meet_ptr. I might like the code better is the meet_ptr call was moved to it's uses since it's commonly completely ignored. > > tom > >> >> >> except TOP which corresponds to the special case in the code table and NULL which >> is not in the table. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> There's a nice comment above this code and it would be nice if the table and code agreed in both order and results. >>> // Meet unloaded class with java/lang/Object >>> // >>> // Meet >>> // | Unloaded Class >>> // Object | TOP | AnyNull | Constant | NotNull | BOTTOM | >>> // =================================================================== >>> // TOP | ..........................Unloaded......................| >>> // AnyNull | U-AN |................Unloaded......................| >>> // Constant | ... O-NN .................................. | O-BOT | >>> // NotNull | ... O-NN .................................. | O-BOT | >>> // BOTTOM | ........................Object-BOTTOM ..................| >>> Your changes appear to make this line: >>> // AnyNull | U-AN |................Unloaded......................| >>> become >>> // AnyNull |........................... U-AN ......................| >>> The -AN part isn't quite true since we're returning the results of meet_ptr which uses the table below. AnyNull meeting NotNull returns NotNull. The Constant line in the comments seems to be wrong too. >>> const TypePtr::PTR TypePtr::ptr_meet[TypePtr::lastPTR][TypePtr::lastPTR] = { >>> // TopPTR, AnyNull, Constant, Null, NotNull, BotPTR, >>> { /* Top */ TopPTR, AnyNull, Constant, Null, NotNull, BotPTR,}, >>> { /* AnyNull */ AnyNull, AnyNull, Constant, BotPTR, NotNull, BotPTR,}, >>> { /* Constant*/ Constant, Constant, Constant, BotPTR, NotNull, BotPTR,}, >>> { /* Null */ Null, BotPTR, BotPTR, Null, BotPTR, BotPTR,}, >>> { /* NotNull */ NotNull, NotNull, NotNull, BotPTR, NotNull, BotPTR,}, >>> { /* BotPTR */ BotPTR, BotPTR, BotPTR, BotPTR, BotPTR, BotPTR,} >>> }; >>> The code itself looks right to me after much rereading of the meet logic. >>> tom >>> On Mar 20, 2009, at 11:31 PM, Vladimir Kozlov wrote: >>>> >>>> http://cr.openjdk.java.net/~kvn/6820514/webrev.00 >>>> >>>> Fixed 6820514: meet not symmetric failure in ctw >>>> >>>> Problem: >>>> Missing instance_id meet for the case j.l.Object:NotNull meets >>>> unloaded instance klass. >>>> >>>> Solution: >>>> Add missing code. >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y, ctw test from bug >>>> >>>> Other testing: >>>> JPRT >>>> From Thomas.Rodriguez at Sun.COM Mon Mar 23 19:24:17 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 23 Mar 2009 19:24:17 -0700 Subject: Request for reviews (S): 6820514: meet not symmetric failure in ctw In-Reply-To: <49C83458.6010808@sun.com> References: <49C489A5.6000309@sun.com> <49C7FBB4.3010605@sun.com> <0E3AF265-C12D-4BE2-9090-812540246840@Sun.COM> <49C83458.6010808@sun.com> Message-ID: This code seems like it should do exactly the same thing as the code which handles the normal loaded case comparing against a loaded j.l.O. Maybe you could take a copy of that code and plug in the types we know we have in xmeet_unloaded, and simplify the crap out of it based on loaded is j.l.O and unloaded is some unloaded thing and see what answer that produces. The other thing I noticed about this code is that it completely ignores the offset for xmeet_unloaded which may be ok, though it seems odd. xmeet_unloaded may be designed to produce conservative but correct answers so maybe the answer it produces is allowed to skew from what you'd expect. Maybe John has some history about how this should behave. I'd be tempted to compare a simplified version of a normal meet with a version of xmeet_unloaded that fixes just TopPtr test and see where it diverges. The core logic is well tested I think and applying it to the Object vs. unloaded case should lead to a correct answer. tom > Yes, you are right, the code for AnyNull case does not return > the original "unloaded" type. It returns the meet type with > meet PTR, offset and instance_id, "false" klass exactness and > NULL for const_oop. The exactness and const_oop could be wrong. > > > At the beginning I wanted just fix the "original" original source > at the switch end and remove one which was added later. > In this case it matches the comment and fix the bug without > calling meet methods: > > assert(loaded->ptr() != TypePtr::Null, "insanity check"); > // > if( loaded->ptr() == TypePtr::TopPTR ) { return unloaded; } > - else if (loaded->ptr() == TypePtr::AnyNull) { return > TypeInstPtr::make( ptr, unloaded->klass() ); } > else if (loaded->ptr() == TypePtr::BotPTR ) { return > TypeInstPtr::BOTTOM; } > else if (loaded->ptr() == TypePtr::Constant || loaded->ptr() > == TypePtr::NotNull) { > if (unloaded->ptr() == TypePtr::BotPTR ) { return > TypeInstPtr::BOTTOM; } > else { return > TypeInstPtr::NOTNULL; } > } > - else if( unloaded->ptr() == TypePtr::TopPTR ) { return > unloaded; } > - > + assert(loaded->ptr() == TypePtr::AnyNull, "insanity check"); > + if( unloaded->ptr() != TypePtr::TopPTR ) { return unloaded; } > return unloaded->cast_to_ptr_type(TypePtr::AnyNull)- > >is_instptr(); > } > > But I am not sure it is correct. > > Note, the original check if( unloaded->ptr() == TypePtr::TopPTR ) > was wrong, it should be "!=". Because of this bug, I think, > the additional code (with the explicit AnyNull check) was added > to fix it. > > Also I can't move meet_ptr() since it is also used below this code. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Mar 23, 2009, at 2:14 PM, Vladimir Kozlov wrote: >>> No, it is not true. The original comment's line is still true >> Sorry, my original comment about what it changed it to was wrong. >> I'd rewritten this several times and forgot to correct that. The >> original comment was wrong and it's still wrong for your change. >>> >>> >>> > // AnyNull | U-AN >>> |................Unloaded......................| >>> >>> meet_ptr() maps almost everything to the original PRT: >>> >>> > // TopPTR, AnyNull, Constant, Null, >>> NotNull, BotPTR, >>> > { /* AnyNull */ AnyNull, AnyNull, Constant, BotPTR, >>> NotNull, BotPTR,}, >> Which means that the comment should be: >>>> // Object | TOP | AnyNull | Constant | NotNull | >>>> BOTTOM | >>>> // AnyNull |....... U-AN .........| U-Con | U-NN | >>>> U-Bot | >> The AnyNull case never returns unloaded unchanged, except for the >> AN/AN case, and having the word unloaded in the table implies that >> it simply returns it. >> My comment about the Constant line can be ignored too since it >> ignores the results of the meet_ptr. I might like the code better >> is the meet_ptr call was moved to it's uses since it's commonly >> completely ignored. >> tom >>> >>> >>> except TOP which corresponds to the special case in the code table >>> and NULL which >>> is not in the table. >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> There's a nice comment above this code and it would be nice if >>>> the table and code agreed in both order and results. >>>> // Meet unloaded class with java/lang/Object >>>> // >>>> // Meet >>>> // | Unloaded Class >>>> // Object | TOP | AnyNull | Constant | NotNull | >>>> BOTTOM | >>>> // >>>> =================================================================== >>>> // TOP >>>> | ..........................Unloaded......................| >>>> // AnyNull | U-AN >>>> |................Unloaded......................| >>>> // Constant | ... O-NN .................................. | >>>> O-BOT | >>>> // NotNull | ... O-NN .................................. | >>>> O-BOT | >>>> // BOTTOM | ........................Object- >>>> BOTTOM ..................| >>>> Your changes appear to make this line: >>>> // AnyNull | U-AN >>>> |................Unloaded......................| >>>> become >>>> // AnyNull |........................... U- >>>> AN ......................| >>>> The -AN part isn't quite true since we're returning the results >>>> of meet_ptr which uses the table below. AnyNull meeting NotNull >>>> returns NotNull. The Constant line in the comments seems to be >>>> wrong too. >>>> const TypePtr::PTR TypePtr::ptr_meet[TypePtr::lastPTR] >>>> [TypePtr::lastPTR] = { >>>> // TopPTR, AnyNull, Constant, Null, NotNull, >>>> BotPTR, >>>> { /* Top */ TopPTR, AnyNull, Constant, Null, NotNull, >>>> BotPTR,}, >>>> { /* AnyNull */ AnyNull, AnyNull, Constant, BotPTR, NotNull, >>>> BotPTR,}, >>>> { /* Constant*/ Constant, Constant, Constant, BotPTR, NotNull, >>>> BotPTR,}, >>>> { /* Null */ Null, BotPTR, BotPTR, Null, BotPTR, >>>> BotPTR,}, >>>> { /* NotNull */ NotNull, NotNull, NotNull, BotPTR, NotNull, >>>> BotPTR,}, >>>> { /* BotPTR */ BotPTR, BotPTR, BotPTR, BotPTR, BotPTR, >>>> BotPTR,} >>>> }; >>>> The code itself looks right to me after much rereading of the >>>> meet logic. >>>> tom >>>> On Mar 20, 2009, at 11:31 PM, Vladimir Kozlov wrote: >>>>> >>>>> http://cr.openjdk.java.net/~kvn/6820514/webrev.00 >>>>> >>>>> Fixed 6820514: meet not symmetric failure in ctw >>>>> >>>>> Problem: >>>>> Missing instance_id meet for the case j.l.Object:NotNull meets >>>>> unloaded instance klass. >>>>> >>>>> Solution: >>>>> Add missing code. >>>>> >>>>> Reviewed by: >>>>> >>>>> Fix verified (y/n): y, ctw test from bug >>>>> >>>>> Other testing: >>>>> JPRT >>>>> From Thomas.Rodriguez at Sun.COM Tue Mar 24 12:29:42 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 24 Mar 2009 12:29:42 -0700 Subject: review (XS) for 6820510 Message-ID: <2089B6C9-C9FA-4EBD-B490-15D0C0AF94F6@sun.com> http://cr.openjdk.java.net/~never/6820510 From Vladimir.Kozlov at Sun.COM Tue Mar 24 13:32:32 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 24 Mar 2009 13:32:32 -0700 Subject: Request for reviews (S): 6810845: Performance regression in mpegaudio on x64 Message-ID: <49C94360.2010908@sun.com> http://cr.openjdk.java.net/~kvn/6810845/webrev.00 Fixed 6810845: Performance regression in mpegaudio on x64 Problem: Fix for 6743900 normalized blocks frequency with start block's frequency equals 1.0. This lowed frequencies in average. Register Allocator relay on these frequencies and in some places it has static values against which it compares frequencies. As result of 6743900 fix some of the code under the frequencies checks is not triggered. In this bug case the code which is not executed is spilling for debug info in uncommon blocks which prevents spilling in hot paths for long LRGs. And this causes performance regression. Solution: Use outer loop frequency in frequencies checks in RA instead of static values. Also add the check for uncommon blocks in some frequencies conditions. Also fixed performance issue with compressed oops to avoid converting to Bottom types of memory operations which use a compressed oop as base. Reviewed by: Fix verified (y/n): y, refworkload Other testing: JPRT From Vladimir.Kozlov at Sun.COM Tue Mar 24 13:33:04 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 24 Mar 2009 13:33:04 -0700 Subject: review (XS) for 6820510 In-Reply-To: <2089B6C9-C9FA-4EBD-B490-15D0C0AF94F6@sun.com> References: <2089B6C9-C9FA-4EBD-B490-15D0C0AF94F6@sun.com> Message-ID: <49C94380.8030709@sun.com> Looks good Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6820510 From changpeng.fang at sun.com Tue Mar 24 14:53:50 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Tue, 24 Mar 2009 21:53:50 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6636138: UseSuperWord enabled failure Message-ID: <20090324215354.4E688E88E@hg.openjdk.java.net> Changeset: 78af5ae8e731 Author: cfang Date: 2009-03-24 12:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/78af5ae8e731 6636138: UseSuperWord enabled failure Summary: Fixed SuperWord scheduling of memory operations. Reviewed-by: kvn, never ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp + test/compiler/6636138/Test1.java + test/compiler/6636138/Test2.java From thomas.rodriguez at sun.com Tue Mar 24 17:46:10 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 25 Mar 2009 00:46:10 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6820510: assertion failure with unloaded class in subnode.cpp Message-ID: <20090325004621.78365E942@hg.openjdk.java.net> Changeset: 90a66aa50514 Author: never Date: 2009-03-24 15:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/90a66aa50514 6820510: assertion failure with unloaded class in subnode.cpp Reviewed-by: kvn ! src/share/vm/opto/subnode.cpp From paul.hohensee at sun.com Tue Mar 24 23:09:34 2009 From: paul.hohensee at sun.com (paul.hohensee at sun.com) Date: Wed, 25 Mar 2009 06:09:34 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090325060949.97515E9A4@hg.openjdk.java.net> Changeset: eca19a8425b5 Author: phh Date: 2009-03-24 21:56 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/eca19a8425b5 6810653: Change String cache class used by Hotspot from String to StringValue Summary: Change create_vm() to load and initialize StringValue rather than String. Reviewed-by: kvn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/thread.cpp Changeset: c7bbabdcadfb Author: phh Date: 2009-03-24 19:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c7bbabdcadfb Merge From volker.simonis at gmail.com Wed Mar 25 01:52:47 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 25 Mar 2009 09:52:47 +0100 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets In-Reply-To: <20090325060949.97515E9A4@hg.openjdk.java.net> References: <20090325060949.97515E9A4@hg.openjdk.java.net> Message-ID: Just out of curiosity: what is "java/lang/StringValue"? I couldn't find it in the "hotspot-comp" repository under " jdk7/hotspot-comp/jdk/src/share/classes/java/lang" (nor in the "jdk7" or "tl" repos) . The bug 6810653 isn't public either, which is kind of funny, since the webrev is - but that's probably another, more general problem... Regards, Volker On 3/25/09, paul.hohensee at sun.com wrote: > Changeset: eca19a8425b5 > Author: phh > Date: 2009-03-24 21:56 -0400 > URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/eca19a8425b5 > > 6810653: Change String cache class used by Hotspot from String to StringValue > Summary: Change create_vm() to load and initialize StringValue rather than String. > Reviewed-by: kvn > > ! src/share/vm/classfile/vmSymbols.hpp > ! src/share/vm/runtime/thread.cpp > > Changeset: c7bbabdcadfb > Author: phh > Date: 2009-03-24 19:05 -0700 > URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c7bbabdcadfb > > Merge > > > From Paul.Hohensee at Sun.COM Wed Mar 25 07:13:19 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 25 Mar 2009 10:13:19 -0400 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets In-Reply-To: References: <20090325060949.97515E9A4@hg.openjdk.java.net> Message-ID: <49CA3BFF.3040001@sun.com> StringValue is a front-end cache for String(String) that's in 6u14. StringValue isn't forward-ported to jdk7 yet, but Hotspot has to work with both jdk6 and jdk7, hence the putback. The bug started out private because it was a competitive performance advantage issue. It's not anymore because jrockit uses one. Paul Volker Simonis wrote: > Just out of curiosity: what is "java/lang/StringValue"? I couldn't > find it in the "hotspot-comp" repository under " > jdk7/hotspot-comp/jdk/src/share/classes/java/lang" (nor in the "jdk7" > or "tl" repos) . The bug 6810653 isn't public either, which is kind of > funny, since the webrev is - but that's probably another, more general > problem... > > Regards, > Volker > > On 3/25/09, paul.hohensee at sun.com wrote: > >> Changeset: eca19a8425b5 >> Author: phh >> Date: 2009-03-24 21:56 -0400 >> URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/eca19a8425b5 >> >> 6810653: Change String cache class used by Hotspot from String to StringValue >> Summary: Change create_vm() to load and initialize StringValue rather than String. >> Reviewed-by: kvn >> >> ! src/share/vm/classfile/vmSymbols.hpp >> ! src/share/vm/runtime/thread.cpp >> >> Changeset: c7bbabdcadfb >> Author: phh >> Date: 2009-03-24 19:05 -0700 >> URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c7bbabdcadfb >> >> Merge >> >> >> >> From Christian.Thalinger at Sun.COM Wed Mar 25 15:25:26 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 25 Mar 2009 15:25:26 -0700 Subject: Request for review (XL): 6822110: Add AddressLiteral class on SPARC Message-ID: <6ee0975a6c70.49ca4ce6@sun.com> http://cr.openjdk.java.net/~twisti/6822110/webrev.00/ From Thomas.Rodriguez at Sun.COM Wed Mar 25 16:57:54 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 25 Mar 2009 16:57:54 -0700 Subject: review (S) for 6822204: volatile fences should prefer lock:addl to actual mfence instruction Message-ID: <2603080F-DEF8-4E6A-8A22-6D763C0D69F4@sun.com> http://cr.openjdk.java.net/~never/6822204 From Vladimir.Kozlov at Sun.COM Wed Mar 25 18:01:40 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 25 Mar 2009 18:01:40 -0700 Subject: review (S) for 6822204: volatile fences should prefer lock:addl to actual mfence instruction In-Reply-To: <2603080F-DEF8-4E6A-8A22-6D763C0D69F4@sun.com> References: <2603080F-DEF8-4E6A-8A22-6D763C0D69F4@sun.com> Message-ID: <49CAD3F4.5090601@sun.com> Looks good. To be consistent use "MEMBAR-volatile ! (empty encoding)" instead of ! } else { ! $$emit$$"# empty membar_volatile" ! } Typo in the comment orderAccess_windows_x86.inline.hpp: ! // Inline assmebly isn't supported so use a stub if it exists. It ^ Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6822204 > From Vladimir.Kozlov at Sun.COM Wed Mar 25 19:17:35 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 25 Mar 2009 19:17:35 -0700 Subject: Request for review (XL): 6822110: Add AddressLiteral class on SPARC In-Reply-To: <6ee0975a6c70.49ca4ce6@sun.com> References: <6ee0975a6c70.49ca4ce6@sun.com> Message-ID: <49CAE5BF.1000207@sun.com> I did not find anything alarming but could you wait a week for HS16? It is too large and will not be tested enough until HS15 is forked. You need to pull latest changesets: John changed RegisterConstant to RegisterOrConstant Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6822110/webrev.00/ From Christian.Thalinger at Sun.COM Wed Mar 25 21:11:25 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 25 Mar 2009 21:11:25 -0700 Subject: Request for reviews (S): 6810845: Performance regression in mpegaudio on x64 In-Reply-To: <49C94360.2010908@sun.com> References: <49C94360.2010908@sun.com> Message-ID: <1238040685.2697.2.camel@localhost.localdomain> On Tue, 2009-03-24 at 13:32 -0700, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6810845/webrev.00 > > Fixed 6810845: Performance regression in mpegaudio on x64 I looked at the webrev and it looks good, at least to me, but I don't know very much about GCM or the other code you touched. Only one thing jumped into my eye: // be conservative if we do not recognize the type if (tp == NULL) { + assert(false, "should not be here"); return TypePtr::BOTTOM; } But I guess not having the assert in a product build just means that it may produce worse code. -- Christian From Vladimir.Kozlov at Sun.COM Wed Mar 25 21:40:50 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 25 Mar 2009 21:40:50 -0700 Subject: Request for reviews (S): 6810845: Performance regression in mpegaudio on x64 In-Reply-To: <1238040685.2697.2.camel@localhost.localdomain> References: <49C94360.2010908@sun.com> <1238040685.2697.2.camel@localhost.localdomain> Message-ID: <49CB0752.7000202@sun.com> Thanks, Christian Yes, the code will be worse, that is all. The assert is only for catching such situations. Thanks, Vladimir Christian Thalinger wrote: > On Tue, 2009-03-24 at 13:32 -0700, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6810845/webrev.00 >> >> Fixed 6810845: Performance regression in mpegaudio on x64 > > I looked at the webrev and it looks good, at least to me, but I don't > know very much about GCM or the other code you touched. Only one thing > jumped into my eye: > > // be conservative if we do not recognize the type > if (tp == NULL) { > + assert(false, "should not be here"); > return TypePtr::BOTTOM; > } > > But I guess not having the assert in a product build just means that it > may produce worse code. > > -- Christian > From Christian.Thalinger at Sun.COM Wed Mar 25 22:18:21 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 25 Mar 2009 22:18:21 -0700 Subject: Request for review (XL): 6822110: Add AddressLiteral class on SPARC In-Reply-To: <49CAE5BF.1000207@sun.com> References: <6ee0975a6c70.49ca4ce6@sun.com> <49CAE5BF.1000207@sun.com> Message-ID: <1238044701.2697.7.camel@localhost.localdomain> On Wed, 2009-03-25 at 19:17 -0700, Vladimir Kozlov wrote: > I did not find anything alarming but could you wait a week > for HS16? It is too large and will not be tested enough > until HS15 is forked. Sure. Btw. JPRT just found a bug: # Internal Error (/tmp/jprt/P1/B/222822.ct232829/source/src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp:288), pid=4964, tid=6 # Error: assert(a_byte == *start++,"should be the same code") I will fix that tomorrow. > > You need to pull latest changesets: > John changed RegisterConstant to RegisterOrConstant Ahh, right. Thanks for reminding. -- Christian From Thomas.Rodriguez at Sun.COM Thu Mar 26 11:07:44 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 26 Mar 2009 11:07:44 -0700 Subject: review (S) for 6822204: volatile fences should prefer lock:addl to actual mfence instruction In-Reply-To: <49CAD3F4.5090601@sun.com> References: <2603080F-DEF8-4E6A-8A22-6D763C0D69F4@sun.com> <49CAD3F4.5090601@sun.com> Message-ID: Fixed. Thanks! tom On Mar 25, 2009, at 6:01 PM, Vladimir Kozlov wrote: > Looks good. > > To be consistent use "MEMBAR-volatile ! (empty encoding)" > instead of > > ! } else { > ! $$emit$$"# empty membar_volatile" > ! } > > Typo in the comment orderAccess_windows_x86.inline.hpp: > ! // Inline assmebly isn't supported so use a stub if it exists. It > ^ > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6822204 From Christian.Thalinger at Sun.COM Thu Mar 26 15:54:59 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 26 Mar 2009 15:54:59 -0700 Subject: review (S) for 6822204: volatile fences should prefer lock:addl to actual mfence instruction In-Reply-To: <2603080F-DEF8-4E6A-8A22-6D763C0D69F4@sun.com> References: <2603080F-DEF8-4E6A-8A22-6D763C0D69F4@sun.com> Message-ID: <1238108099.2697.19.camel@localhost.localdomain> On Wed, 2009-03-25 at 16:57 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6822204 Looks good to me. -- Christian From thomas.rodriguez at sun.com Thu Mar 26 17:06:42 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Fri, 27 Mar 2009 00:06:42 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090327000650.1FAC5EB04@hg.openjdk.java.net> Changeset: d0994e5bebce Author: never Date: 2009-03-26 14:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d0994e5bebce 6822204: volatile fences should prefer lock:addl to actual mfence instructions Reviewed-by: kvn, phh ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/linux_sparc/vm/os_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/orderAccess.cpp ! src/share/vm/runtime/orderAccess.hpp Changeset: afd8dfb5c2a6 Author: never Date: 2009-03-26 14:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/afd8dfb5c2a6 Merge From vladimir.kozlov at sun.com Thu Mar 26 18:20:57 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 27 Mar 2009 01:20:57 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6810845: Performance regression in mpegaudio on x64 Message-ID: <20090327012059.DD0BCEB48@hg.openjdk.java.net> Changeset: fbc12e71c476 Author: kvn Date: 2009-03-26 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fbc12e71c476 6810845: Performance regression in mpegaudio on x64 Summary: Used the outer loop frequency in frequencies checks in RA. Reviewed-by: never, twisti ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/machnode.cpp From Thomas.Rodriguez at Sun.COM Fri Mar 27 12:07:33 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 27 Mar 2009 12:07:33 -0700 Subject: review (XS) for 6822333: _call_stub_compiled_return address handling in SA is broken causing jstack to hang occasionally Message-ID: <9598BD11-0802-467B-82AB-B331FF8D4269@Sun.COM> http://cr.openjdk.java.net/~never/6822333 From Christian.Thalinger at Sun.COM Fri Mar 27 13:14:30 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 27 Mar 2009 13:14:30 -0700 Subject: review (XS) for 6822333: _call_stub_compiled_return address handling in SA is broken causing jstack to hang occasionally In-Reply-To: <9598BD11-0802-467B-82AB-B331FF8D4269@Sun.COM> References: <9598BD11-0802-467B-82AB-B331FF8D4269@Sun.COM> Message-ID: <1238184870.3798.5.camel@localhost.localdomain> On Fri, 2009-03-27 at 12:07 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6822333 Looks good. -- Christian From Christian.Thalinger at Sun.COM Fri Mar 27 16:26:00 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 27 Mar 2009 16:26:00 -0700 Subject: Request for review (XL): 6822110: Add AddressLiteral class on SPARC In-Reply-To: <1238044701.2697.7.camel@localhost.localdomain> References: <6ee0975a6c70.49ca4ce6@sun.com> <49CAE5BF.1000207@sun.com> <1238044701.2697.7.camel@localhost.localdomain> Message-ID: <1238196360.3798.8.camel@localhost.localdomain> On Wed, 2009-03-25 at 22:18 -0700, Christian Thalinger wrote: > > You need to pull latest changesets: > > John changed RegisterConstant to RegisterOrConstant > > Ahh, right. Thanks for reminding. Here is an updated version of the patch: http://cr.openjdk.java.net/~twisti/6822110/webrev.01/ -- Christian From thomas.rodriguez at sun.com Fri Mar 27 17:11:07 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Sat, 28 Mar 2009 00:11:07 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6822333: _call_stub_compiled_return address handling in SA is broken causing jstack to hang occasionally Message-ID: <20090328001113.66A31EBE9@hg.openjdk.java.net> Changeset: 4948e7dd28dc Author: never Date: 2009-03-27 14:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4948e7dd28dc 6822333: _call_stub_compiled_return address handling in SA is broken causing jstack to hang occasionally Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/runtime/StubRoutines.java From Vladimir.Kozlov at Sun.COM Mon Mar 30 18:26:26 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 30 Mar 2009 18:26:26 -0700 Subject: Request for reviews (S): 6821700: tune VM flags for peak performance Message-ID: <49D17142.5090500@sun.com> Sending to public before the push. http://cr.openjdk.java.net/~kvn/6821700/webrev.01 Fixed 6821700: tune VM flags for peak performance Problem: Tune C2 flags default values for peak performance. Solution: Change InlineSmallCode flag to platform specific and change its default value to 1500 on sparc (ran refworkload on N1, N2 and my station (US3), 32- and 64-bit VM). Changing FreqInlineSize default value had negative effects so I did not change it. Do not inline StringCache::profile() when strings caching is used since it runs only during an application startup. Reviewed by: never, phh, iveresov, jmasa, ysr Fix verified (y/n): y, refworkload Other testing: JPRT From Thomas.Rodriguez at Sun.COM Mon Mar 30 20:09:49 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 30 Mar 2009 20:09:49 -0700 Subject: Request for reviews (S): 6821700: tune VM flags for peak performance In-Reply-To: <49D17142.5090500@sun.com> References: <49D17142.5090500@sun.com> Message-ID: Looks good. tom On Mar 30, 2009, at 6:26 PM, Vladimir Kozlov wrote: > Sending to public before the push. > > http://cr.openjdk.java.net/~kvn/6821700/webrev.01 > > Fixed 6821700: tune VM flags for peak performance > > Problem: > Tune C2 flags default values for peak performance. > > Solution: > Change InlineSmallCode flag to platform specific and > change its default value to 1500 on sparc (ran refworkload > on N1, N2 and my station (US3), 32- and 64-bit VM). > Changing FreqInlineSize default value had negative > effects so I did not change it. > > Do not inline StringCache::profile() when strings caching > is used since it runs only during an application startup. > > Reviewed by: never, phh, iveresov, jmasa, ysr > > Fix verified (y/n): y, refworkload > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Mon Mar 30 20:07:04 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 30 Mar 2009 20:07:04 -0700 Subject: Request for reviews (S): 6821700: tune VM flags for peak performance In-Reply-To: References: <49D17142.5090500@sun.com> Message-ID: <49D188D8.7040805@sun.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Mar 30, 2009, at 6:26 PM, Vladimir Kozlov wrote: > >> Sending to public before the push. >> >> http://cr.openjdk.java.net/~kvn/6821700/webrev.01 >> >> Fixed 6821700: tune VM flags for peak performance >> >> Problem: >> Tune C2 flags default values for peak performance. >> >> Solution: >> Change InlineSmallCode flag to platform specific and >> change its default value to 1500 on sparc (ran refworkload >> on N1, N2 and my station (US3), 32- and 64-bit VM). >> Changing FreqInlineSize default value had negative >> effects so I did not change it. >> >> Do not inline StringCache::profile() when strings caching >> is used since it runs only during an application startup. >> >> Reviewed by: never, phh, iveresov, jmasa, ysr >> >> Fix verified (y/n): y, refworkload >> >> Other testing: >> JPRT >> > From vladimir.kozlov at sun.com Mon Mar 30 20:55:53 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 31 Mar 2009 03:55:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6821700: tune VM flags for peak performance Message-ID: <20090331035559.C9D76ECEF@hg.openjdk.java.net> Changeset: f6da6f0174ac Author: kvn Date: 2009-03-30 18:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f6da6f0174ac 6821700: tune VM flags for peak performance Summary: Tune C2 flags default values for performance. Reviewed-by: never, phh, iveresov, jmasa, ysr ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/runtime/globals.hpp From Thomas.Rodriguez at Sun.COM Tue Mar 31 12:54:55 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 31 Mar 2009 12:54:55 -0700 Subject: review (XS) for 6824463: deopt blob is testing wrong register on 64-bit x86 Message-ID: <14C253E6-2BA9-4BB5-9036-00D7F4F4CDB9@Sun.COM> http://cr.openjdk.java.net/~never/6824463 From John.Rose at Sun.COM Tue Mar 31 12:58:41 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 31 Mar 2009 12:58:41 -0700 Subject: review (XS) for 6824463: deopt blob is testing wrong register on 64-bit x86 In-Reply-To: <14C253E6-2BA9-4BB5-9036-00D7F4F4CDB9@Sun.COM> References: <14C253E6-2BA9-4BB5-9036-00D7F4F4CDB9@Sun.COM> Message-ID: <52DA9AC0-6D15-402D-ADCF-FBF1C2F0E286@sun.com> Yes, that's clearly correct, where it used to be (in hindsight) clearly wrong. -- John On Mar 31, 2009, at 12:54 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6824463 > From Thomas.Rodriguez at Sun.COM Tue Mar 31 13:08:43 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 31 Mar 2009 13:08:43 -0700 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> Message-ID: Most of my comments are below mostly about style and naming and could be addressed in later putbacks since this obviously isn't done. MethodEntry is too general of a name. Maybe you can come up with a better one. CHECK_UNHANDLED_OOPS might be worth running at some point. methodHandles.hpp: I'm not a big fan of formatting like this: if (mh.is_null() || target.is_null() || ! java_dyn_MethodHandle::is_instance(target())) { throw_InternalError(CHECK); } Could you format this and others normally? At most it saves one line. Also the throw_* functions seem a bit excessive. It also defeats the fact that the THROW macro records the line number of the throw point which can be handy for debugging. Do you distrust the THROW macro? Actually, with a smart enough compiler they could lead to unreachable code warnings since you're effectively writing this: { Exceptions::_throw_msg(THREAD_AND_LOCATION, name, NULL); return; } { report_should_not_reach_here (__FILE__, __LINE__); BREAKPOINT; } A lot of the methods take oop arguments but then immediately convert them into handles and have extra logic where the oop argument is nulled out for safety. Some even take a mix of handles and oops. Why not just use handles uniformly? adapter_conversion could use some asserts validating the encoding. When writing flags into the MembarName from access_flags().as_short() shouldn't you be masking them with JVM_RECOGNIZED_FIELD_MODIFIERS and JVM_RECOGNIZED_METHOD_MODIFIERS as appropriate? There are big chunks of VerifyMethodHandles code in the moddle of other logic and it might be nice if these were broken out so that main code would be more readable. I know in some cases that might be difficult but init_AdapterMethodHandle in particular has a chunk that might be movable. Could you make the natives entry points to make it clear that even though they are JVM_ENTRY they aren't actually JVM_ entry points? methodHandles_x86.cpp: The padding code in MethodEntry::start_compiled_entry could use a comment explaining that it's reserving space in the beginning for the Data field. The space before this trick feels a little too clever but I'm not totally against it. Don't do the (int32_t)NULL_WORD cast here: __ cmpptr(arg_slots.as_register(), (int32_t) NULL_WORD); In the add_arg_slots code shouldn't there be an assert in the if (TaggedStackInterpreter) piece that arg_slots is not a register since constant_arg_slots won't have a valid value in that case? In trace_method_handle_stub the format should be: printf("MH %s %p %p "INTX_FORMAT"\n", adaptername, mh, entry_sp, entry_sp - saved_sp); since entry_sp - saved_sp is an intptr_t. You might use PTR_FORMAT instead of %p since %p isn't consistently defined. Shouldn't these be movptr? __ movl(rax_klass, Address(rcx_recv, oopDesc::klass_offset_in_bytes())); __ movl(rdx_temp, Address(rdx_temp, oopDesc::klass_offset_in_bytes())); Are you going to delete any #if 0 pieces still lying around? What controls which values of the switch are valid in generate_method_handle_stub? There are quite a few that sum two values. Why is _adapter_opt_f2i commented out? a2l and a2i are strangely named and freaked me out at first but then I realized they are actually unbox operations. maybe unboxi and unboxl? tom On Mar 10, 2009, at 3:48 PM, John Rose wrote: > Thanks for the reviews so far. I've posted the remainder of > meth.patch here: > > 6655638: dynamic languages need method handles > http://cr.openjdk.java.net/~jrose/6655638/webrev.00/ (not yet > integrated) > > (Long live cr.OJN! Goodbye webrev.invokedynamic.info.) > > Later today (probably) I will update the index page to have useful > comments about how each file is changed. > > After responding to any further reviewer comments, I'll push the > results. > > Because it's a large body of code, and it will help to have a record > of what we do, let's keep review comments public. > > If the comments lead to large changes, I may have to ask for a re- > review. If that happens, I'll publish at least a diff of webrev.N > to webrev.N+1, maybe even a 2nd-order webrev, if I can figure out how. > > About self-review: I will be reviewing my own code, too, and if the > review period is long enough, may wish to make amendments. I'll > email a public comment if this seems necessary. (I've "discovered" > that people don't like it when they encounter unexplained changes > mid-review.) > > Meanwhile, I'm working on the same code that's being reviewed. For > big reviews like this one, I'll try to keep separate workspaces for > review and further engineering. (I wouldn't attempt this without hg/ > MQ and Emacs diff-mode.) Therefore, if a review takes a long time > (which this one has) it may be followed immediately by a second > review cycle with a new bug ID, to push the adjustments separately. > In fact, I'll allocate the bug ID now: > > 6815692: method handle code needs some cleanup (post-6655638) > http://cr.openjdk.java.net/~jrose/6815692/webrev.00/ (not yet > posted) > > As that settles down I will be asking for reviews on this next step: > > 6655646: dynamic languages need dynamically linked call sites > http://cr.openjdk.java.net/~jrose/6655646/webrev.00/ (not yet > posted) > > After that, there will be individual pushes for additional assembly > code (x64 and/or sparc), compiler optimizations (2-3 steps there), > and various smaller things like compressed oops and cppInterpreter > support. And of course bug fixes and cleanups as needed. > > Onward! > > -- John > > On Jan 20, 2009, at 2:53 AM, John Rose wrote: > >> This is part of the JVM side of the JSR 292 Reference >> Implementation. It should have no effect on application execution, >> unless one of the new flags is turned on (chiefly -XX: >> +MethodHandleSupport). >> >> Present limitations: >> - It works only on x86/32. (No sparc, compressed oops, cpp >> interpreter.) >> - There are no compiler optimizations. >> - It is young code. There are bugs. But only when a new flag is >> turned on. >> >> This review is for contents of meth.patch, to be pushed from mlvm >> to http://hg.openjdk.java.net/jdk7/hotspot-comp-gate/hotspot . >> >> Here is the webrev for this review: >> http://webrev.invokedynamic.info/jrose/6655638.meth/ >> >> Here is the mlvm patch where the code currently lives: >> http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/tip/meth.patch >> >> An earlier version of these changes pass JPRT; it is expected that >> at most minor tweaks will be needed to push it through again. >> >> Even though they are large, the changes should also pass a simple >> visual inspection, since all substantially new control paths are >> guarded by tests of the new flags. >> >> Please give it a look. >> >> -- John >> >> P.S. Here are some relevant conversations about method handles and >> invokedynamic: >> http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000321.html >> http://blogs.sun.com/jrose/entry/international_invokedynamic_day >> http://blogs.sun.com/dannycoward/entry/firing_up_the_engines_for >> http://groups.google.com/group/jvm-languages/browse_thread/thread/a4b8a616eb987ca8 >> >> P.P.S. The proposed JDK changes are independent. At present, you >> can find them here, in patch and webrev formats: >> http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/tip/meth.proj.patch >> http://webrev.invokedynamic.info/jrose/6655638.meth.proj/ > From Vladimir.Kozlov at Sun.COM Tue Mar 31 13:18:28 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 31 Mar 2009 13:18:28 -0700 Subject: review (XS) for 6824463: deopt blob is testing wrong register on 64-bit x86 In-Reply-To: <14C253E6-2BA9-4BB5-9036-00D7F4F4CDB9@Sun.COM> References: <14C253E6-2BA9-4BB5-9036-00D7F4F4CDB9@Sun.COM> Message-ID: <49D27A94.2090300@sun.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6824463 > From vladimir.kozlov at sun.com Tue Mar 31 13:40:50 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 31 Mar 2009 20:40:50 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 17 new changesets Message-ID: <20090331204127.018B5ED97@hg.openjdk.java.net> Changeset: 2314b7336582 Author: tonyp Date: 2009-03-21 22:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2314b7336582 6820321: G1: Error: guarantee(check_nums(total, n, parts), "all seq lengths should match") Summary: Small fixes to sort out some verbosegc-related incorrectness and a failure Reviewed-by: apetrusenko ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 59f139e8a8d1 Author: tonyp Date: 2009-03-25 10:36 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/59f139e8a8d1 Merge Changeset: 54782a4cd321 Author: poonam Date: 2009-03-15 18:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/54782a4cd321 6812971: SA: re-attaching to process fails Summary: After attaching, de-attaching SA from a process, the second time attach() call fails. This happens because in VM.initialize(), Universe does not get re-initialized before it is accessed. Reviewed-by: swamyv ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java Changeset: 8ce995316d10 Author: acorn Date: 2009-03-16 08:50 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8ce995316d10 Merge Changeset: 4aaa9f5e02a8 Author: acorn Date: 2009-03-18 17:20 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4aaa9f5e02a8 4766230: Hotspot vtable inconsistencies cause core dumps. 6579515. 6582242. Reviewed-by: kamg, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp Changeset: e55bcaf3a6a1 Author: acorn Date: 2009-03-20 11:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e55bcaf3a6a1 6819853: VM does not detect JDK which supports parallel class loaders Reviewed-by: coleenp, pbk, xlu, alanb ! src/share/vm/classfile/vmSymbols.hpp Changeset: c664a0794f85 Author: coleenp Date: 2009-03-20 22:08 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c664a0794f85 6805748: Assertion "don't reset to 0 -- could be mistaken for never-executed" in CompilationPolicy Summary: Resetting the invocation counter for a method invocation event was setting count to zero for CompileThreshold=1, making it look like a never executed method. Reviewed-by: phh, kamg, acorn, never ! src/share/vm/interpreter/invocationCounter.cpp Changeset: 60bfce711da4 Author: acorn Date: 2009-03-23 10:42 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/60bfce711da4 Merge ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/classfile/vmSymbols.hpp Changeset: 6bdd6923ba16 Author: coleenp Date: 2009-03-25 14:19 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6bdd6923ba16 6541756: Reduce executable C-heap Summary: Add executable parameters to reserve_memory and commit_memory to reduce executable memory to only the Code Heap. Reviewed-by: xlu, kvn, acorn ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 715dceaa89b7 Author: acorn Date: 2009-03-25 13:09 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/715dceaa89b7 6603316: Improve instrumentation for classes loaded at startup Reviewed-by: xlu, mchung ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp Changeset: fe62b51b93f4 Author: acorn Date: 2009-03-26 16:00 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fe62b51b93f4 Merge Changeset: 520d43965b1f Author: ikrylov Date: 2009-03-27 01:35 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/520d43965b1f 6812297: update project creation for Visual Studio 2005-2008 Summary: Add 2 news classes to create VC8 and VC9 projects Reviewed-by: apetrusenko, xlu ! make/windows/build_vm_def.sh ! make/windows/create.bat ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/makedeps.make ! make/windows/makefiles/rules.make ! src/share/tools/MakeDeps/WinGammaPlatformVC7.java + src/share/tools/MakeDeps/WinGammaPlatformVC8.java + src/share/tools/MakeDeps/WinGammaPlatformVC9.java ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 0aeec7d15d30 Author: acorn Date: 2009-03-27 14:35 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0aeec7d15d30 Merge Changeset: 1b1e8f1a4fe8 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1b1e8f1a4fe8 Added tag jdk7-b51 for changeset 2581d90c6c9b ! .hgtags Changeset: 00bcc4b01dde Author: trims Date: 2009-03-27 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/00bcc4b01dde Merge Changeset: 9ab385cb0c42 Author: trims Date: 2009-03-27 16:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9ab385cb0c42 6823377: Bump HS15 build number to 04 Summary: Update the HS15 Build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d3676b4cb78c Author: kvn Date: 2009-03-31 10:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d3676b4cb78c Merge ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/prims/jvm.cpp From Thomas.Rodriguez at Sun.COM Tue Mar 31 14:28:00 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 31 Mar 2009 14:28:00 -0700 Subject: Request for review (XL): 6822110: Add AddressLiteral class on SPARC In-Reply-To: <1238196360.3798.8.camel@localhost.localdomain> References: <6ee0975a6c70.49ca4ce6@sun.com> <49CAE5BF.1000207@sun.com> <1238044701.2697.7.camel@localhost.localdomain> <1238196360.3798.8.camel@localhost.localdomain> Message-ID: icBuffer_sparc.cpp: I believe we could the special reloc stuff completely here. Passing ForceRelocatable = true is useless assuming the rest of the comments are right about not needing a reloc at all. Could we remove the ForceRelocatable version of sethi completely in favor of requiring the use of AddressLiteral? interp_masp_sparc.cpp: you dropped the minus below: - Address d_save(FP, 0, -sizeof(jdouble) + STACK_BIAS); + Address d_save(FP, sizeof(jdouble) + STACK_BIAS); for this: Address lock_addr = Address( it should just be: Address lock_addr( assembler_sparc.hpp: why does load_contents take 2 registers? All uses pass the same thing for both. It should just assume the dest is the temp. Actually I think that's true of all the new ones that take both a temp and a dest. Otherwise I think this looks good. tom On Mar 27, 2009, at 4:26 PM, Christian Thalinger wrote: > On Wed, 2009-03-25 at 22:18 -0700, Christian Thalinger wrote: >>> You need to pull latest changesets: >>> John changed RegisterConstant to RegisterOrConstant >> >> Ahh, right. Thanks for reminding. > > Here is an updated version of the patch: > > http://cr.openjdk.java.net/~twisti/6822110/webrev.01/ > > -- Christian > From Thomas.Rodriguez at Sun.COM Tue Mar 31 14:30:53 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 31 Mar 2009 14:30:53 -0700 Subject: review (XS) for 6823454: Oop-typed loadP yields invalid pointer (0x1) on SPECjbb2005 at OSRed method entry Message-ID: <83EA37CA-8CCE-4C0E-A9B8-798CA90AE8AE@sun.com> http://cr.openjdk.java.net/~never/6823454 From John.Rose at Sun.COM Tue Mar 31 15:34:43 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 31 Mar 2009 15:34:43 -0700 Subject: review (XS) for 6823454: Oop-typed loadP yields invalid pointer (0x1) on SPECjbb2005 at OSRed method entry In-Reply-To: <83EA37CA-8CCE-4C0E-A9B8-798CA90AE8AE@sun.com> References: <83EA37CA-8CCE-4C0E-A9B8-798CA90AE8AE@sun.com> Message-ID: <73FD8009-1289-4587-93E2-D15EA360FA1B@sun.com> Looks good. -- John On Mar 31, 2009, at 2:30 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6823454 > From changpeng.fang at sun.com Tue Mar 31 19:17:38 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Wed, 01 Apr 2009 02:17:38 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6761600: Use sse 4.2 in intrinsics Message-ID: <20090401021749.B974FEE03@hg.openjdk.java.net> Changeset: fbde8ec322d0 Author: cfang Date: 2009-03-31 14:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fbde8ec322d0 6761600: Use sse 4.2 in intrinsics Summary: Use SSE 4.2 in intrinsics for String.{compareTo/equals/indexOf} and Arrays.equals. Reviewed-by: kvn, never, jrose ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From Vladimir.Kozlov at Sun.COM Tue Mar 31 21:11:19 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 31 Mar 2009 21:11:19 -0700 Subject: Request for reviews (XS): 6823453: DeoptimizeALot causes fastdebug server jvm to fail with assert(false,"unscheduable graph") Message-ID: <49D2E967.20808@sun.com> http://cr.openjdk.java.net/~kvn/6823453/webrev.00 Fixed 6823453: DeoptimizeALot causes fastdebug server jvm to fail with assert(false,"unscheduable graph") Problem: The code in GraphKit::new_array replaces a negative constant with 0 for all uses if it used as new array length. As result An incorrect ideal graph is generated as result. Solution: Don't replace constants. Added regression test. Reviewed by: Fix verified (y/n): y, bugs tests Other testing: JPRT From thomas.rodriguez at sun.com Tue Mar 31 21:49:20 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 01 Apr 2009 04:49:20 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090401044925.53515EE0E@hg.openjdk.java.net> Changeset: 69aefafe69c1 Author: never Date: 2009-03-31 15:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/69aefafe69c1 6824463: deopt blob is testing wrong register on 64-bit x86 Reviewed-by: jrose, phh, kvn ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: 90e3155a713d Author: never Date: 2009-03-31 19:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/90e3155a713d Merge From Vladimir.Kozlov at Sun.COM Tue Mar 31 22:24:05 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 31 Mar 2009 22:24:05 -0700 Subject: Request for reviews (XS): 6823453: DeoptimizeALot causes fastdebug server jvm to fail with assert(false,"unscheduable graph") In-Reply-To: <49D2E967.20808@sun.com> References: <49D2E967.20808@sun.com> Message-ID: <49D2FA75.1050501@sun.com> Sorry, the problem description should be: The code in GraphKit::new_array replaces a negative constant with TOP (CastII(-1)#0) for all uses if it is used as new array length. Incorrect ideal graph is generated as result. Thanks, Vladimir Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6823453/webrev.00 > > Fixed 6823453: DeoptimizeALot causes fastdebug server jvm to fail with > assert(false,"unscheduable graph") > > Problem: > The code in GraphKit::new_array replaces a negative constant > with 0 for all uses if it used as new array length. > As result An incorrect ideal graph is generated as result. > > Solution: > Don't replace constants. > Added regression test. > > Reviewed by: > > Fix verified (y/n): y, bugs tests > > Other testing: > JPRT > From John.Rose at Sun.COM Tue Mar 31 22:56:44 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 31 Mar 2009 22:56:44 -0700 Subject: Request for reviews (XS): 6823453: DeoptimizeALot causes fastdebug server jvm to fail with assert(false,"unscheduable graph") In-Reply-To: <49D2FA75.1050501@sun.com> References: <49D2E967.20808@sun.com> <49D2FA75.1050501@sun.com> Message-ID: On Mar 31, 2009, at 10:24 PM, Vladimir Kozlov wrote: > The code in GraphKit::new_array replaces a negative constant with > TOP (CastII(-1)#0) for all uses if it is used as new array length. > Incorrect ideal graph is generated as result. I think there the bug may still be present if length is not constant but in a negative range. Change new byte[(byte)1.0E10] to new byte[(byte)var_1 - 128] and see what happens. In that case, the type of length is int:[-256..-1], and your change will not have an effect. I think this might be a more robust version of your change: if (map()->find_edge(length) >= 0) { Node* ccast = alloc->make_ideal_length(ary_type, &_gvn); if (ccast != length) { _gvn.set_type_bottom(ccast); + if (!_gvn.type(ccast)->empty()) { record_for_igvn(ccast); replace_in_map(length, ccast); + } } (BTW, the logic of narrow_size_type is a little funky, since it returns 0 for top. That was fixing some other, similar bug, I think. But maybe it should have returned a sentinel value of -1 instead of 0. That would not be a point-fix.) -- John