From Christian.Thalinger at Sun.COM Mon Feb 2 03:01:19 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 02 Feb 2009 12:01:19 +0100 Subject: long_by_long_mulhi() rewritten and commented Message-ID: <1233572479.3982.29.camel@localhost.localdomain> Hi! While looking at 6795362, I tried to understand what the code in long_by_long_mulhi() does and I rewrote it with a lot more comments (plus original code from Hacker's Delight). I'd like to commit this one but I'm not sure if there might be a copyright problem. Would it be okay to open a new CR and commit it? -- Christian --- 6795362.3b5ac9e7e6ea/src/share/vm/opto/divnode.cpp 2009-02-02 11:56:15.694744045 +0100 +++ /export/home/twisti/hotspot-comp/6795362/src/share/vm/opto/divnode.cpp 2009-02-02 11:55:20.837538078 +0100 @@ -252,34 +252,62 @@ static Node *long_by_long_mulhi( PhaseGV return new (phase->C, 3) MulHiLNode(dividend, v); } - const int N = 64; - - Node *u_hi = phase->transform(new (phase->C, 3) RShiftLNode(dividend, phase->intcon(N / 2))); - Node *u_lo = phase->transform(new (phase->C, 3) AndLNode(dividend, phase->longcon(0xFFFFFFFF))); + // Taken from Hacker's Delight, Fig. 8-2. Multiply high signed. + // (http://www.hackersdelight.org/HDcode/mulhs.c) + // + // int mulhs(int u, int v) { + // unsigned u0, v0, w0; + // int u1, v1, w1, w2, t; + // + // u0 = u & 0xFFFF; u1 = u >> 16; + // v0 = v & 0xFFFF; v1 = v >> 16; + // w0 = u0*v0; + // t = u1*v0 + (w0 >> 16); + // w1 = t & 0xFFFF; + // w2 = t >> 16; + // w1 = u0*v1 + w1; + // return u1*v1 + w2 + (w1 >> 16); + // } - Node *v_hi = phase->longcon(magic_const >> N/2); - Node *v_lo = phase->longcon(magic_const & 0XFFFFFFFF); + const int N = 64; - Node *hihi_product = phase->transform(new (phase->C, 3) MulLNode(u_hi, v_hi)); - Node *hilo_product = phase->transform(new (phase->C, 3) MulLNode(u_hi, v_lo)); - Node *lohi_product = phase->transform(new (phase->C, 3) MulLNode(u_lo, v_hi)); - Node *lolo_product = phase->transform(new (phase->C, 3) MulLNode(u_lo, v_lo)); - - Node *t1 = phase->transform(new (phase->C, 3) URShiftLNode(lolo_product, phase->intcon(N / 2))); - Node *t2 = phase->transform(new (phase->C, 3) AddLNode(hilo_product, t1)); - - // Construct both t3 and t4 before transforming so t2 doesn't go dead - // prematurely. - Node *t3 = new (phase->C, 3) RShiftLNode(t2, phase->intcon(N / 2)); - Node *t4 = new (phase->C, 3) AndLNode(t2, phase->longcon(0xFFFFFFFF)); - t3 = phase->transform(t3); - t4 = phase->transform(t4); - - Node *t5 = phase->transform(new (phase->C, 3) AddLNode(t4, lohi_product)); - Node *t6 = phase->transform(new (phase->C, 3) RShiftLNode(t5, phase->intcon(N / 2))); - Node *t7 = phase->transform(new (phase->C, 3) AddLNode(t3, hihi_product)); + // u0 = u & 0xFFFF; u1 = u >> 16; + Node *u0 = phase->transform(new (phase->C, 3) AndLNode(dividend, phase->longcon(0xFFFFFFFF))); + Node *u1 = phase->transform(new (phase->C, 3) RShiftLNode(dividend, phase->intcon(N / 2))); + + // v0 = v & 0xFFFF; v1 = v >> 16; + Node *v0 = phase->longcon(magic_const & 0xFFFFFFFF); + Node *v1 = phase->longcon(magic_const >> N / 2); + + // w0 = u0*v0; + Node *w0 = phase->transform(new (phase->C, 3) MulLNode(u0, v0)); + + // t = u1*v0 + (w0 >> 16); + Node *u1v0 = phase->transform(new (phase->C, 3) MulLNode(u1, v0)); + Node *temp = phase->transform(new (phase->C, 3) URShiftLNode(w0, phase->intcon(N / 2))); + Node *t = phase->transform(new (phase->C, 3) AddLNode(u1v0, temp)); + + // w1 = t & 0xFFFF; + Node *w1 = new (phase->C, 3) AndLNode(t, phase->longcon(0xFFFFFFFF)); + + // w2 = t >> 16; + Node *w2 = new (phase->C, 3) RShiftLNode(t, phase->intcon(N / 2)); + + // 6732154: Construct both w1 and w2 before transforming, so t + // doesn't go dead prematurely. + w1 = phase->transform(w1); + w2 = phase->transform(w2); + + // w1 = u0*v1 + w1; + Node *u0v1 = phase->transform(new (phase->C, 3) MulLNode(u0, v1)); + w1 = phase->transform(new (phase->C, 3) AddLNode(u0v1, w1)); + + // return u1*v1 + w2 + (w1 >> 16); + Node *u1v1 = phase->transform(new (phase->C, 3) MulLNode(u1, v1)); + Node *temp1 = phase->transform(new (phase->C, 3) AddLNode(u1v1, w2)); + Node *temp2 = phase->transform(new (phase->C, 3) RShiftLNode(w1, phase->intcon(N / 2))); - return new (phase->C, 3) AddLNode(t7, t6); + return new (phase->C, 3) AddLNode(temp1, temp2); } From Christian.Thalinger at Sun.COM Mon Feb 2 03:22:52 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 02 Feb 2009 12:22:52 +0100 Subject: Request for review (S): 6795362: 32bit server compiler leads to wrong results on solaris-x86 Message-ID: <1233573772.3982.30.camel@localhost.localdomain> http://webrev.invokedynamic.info/twisti/6795362/ From rasbold at google.com Mon Feb 2 08:42:22 2009 From: rasbold at google.com (Chuck Rasbold) Date: Mon, 2 Feb 2009 08:42:22 -0800 Subject: long_by_long_mulhi() rewritten and commented In-Reply-To: <1233572479.3982.29.camel@localhost.localdomain> References: <1233572479.3982.29.camel@localhost.localdomain> Message-ID: <4149a0430902020842k72be098ds20450eeece376062@mail.gmail.com> Christian - I think your suggested change with attribution to Hacker's Delight is a good idea. C2 already references that source elsewhere. I would change the constants in the comments to match those used in the building the ideal graph. Then note in a single place that you adjusted Warren's algorithm to 64 bits. -- Chuck On Mon, Feb 2, 2009 at 3:01 AM, Christian Thalinger wrote: > Hi! > > While looking at 6795362, I tried to understand what the code in > long_by_long_mulhi() does and I rewrote it with a lot more comments > (plus original code from Hacker's Delight). > > I'd like to commit this one but I'm not sure if there might be a > copyright problem. > > Would it be okay to open a new CR and commit it? > > -- Christian > > > --- 6795362.3b5ac9e7e6ea/src/share/vm/opto/divnode.cpp 2009-02-02 11:56:15.694744045 +0100 > +++ /export/home/twisti/hotspot-comp/6795362/src/share/vm/opto/divnode.cpp 2009-02-02 11:55:20.837538078 +0100 > @@ -252,34 +252,62 @@ static Node *long_by_long_mulhi( PhaseGV > return new (phase->C, 3) MulHiLNode(dividend, v); > } > > - const int N = 64; > - > - Node *u_hi = phase->transform(new (phase->C, 3) RShiftLNode(dividend, phase->intcon(N / 2))); > - Node *u_lo = phase->transform(new (phase->C, 3) AndLNode(dividend, phase->longcon(0xFFFFFFFF))); > + // Taken from Hacker's Delight, Fig. 8-2. Multiply high signed. > + // (http://www.hackersdelight.org/HDcode/mulhs.c) > + // > + // int mulhs(int u, int v) { > + // unsigned u0, v0, w0; > + // int u1, v1, w1, w2, t; > + // > + // u0 = u & 0xFFFF; u1 = u >> 16; > + // v0 = v & 0xFFFF; v1 = v >> 16; > + // w0 = u0*v0; > + // t = u1*v0 + (w0 >> 16); > + // w1 = t & 0xFFFF; > + // w2 = t >> 16; > + // w1 = u0*v1 + w1; > + // return u1*v1 + w2 + (w1 >> 16); > + // } > > - Node *v_hi = phase->longcon(magic_const >> N/2); > - Node *v_lo = phase->longcon(magic_const & 0XFFFFFFFF); > + const int N = 64; > > - Node *hihi_product = phase->transform(new (phase->C, 3) MulLNode(u_hi, v_hi)); > - Node *hilo_product = phase->transform(new (phase->C, 3) MulLNode(u_hi, v_lo)); > - Node *lohi_product = phase->transform(new (phase->C, 3) MulLNode(u_lo, v_hi)); > - Node *lolo_product = phase->transform(new (phase->C, 3) MulLNode(u_lo, v_lo)); > - > - Node *t1 = phase->transform(new (phase->C, 3) URShiftLNode(lolo_product, phase->intcon(N / 2))); > - Node *t2 = phase->transform(new (phase->C, 3) AddLNode(hilo_product, t1)); > - > - // Construct both t3 and t4 before transforming so t2 doesn't go dead > - // prematurely. > - Node *t3 = new (phase->C, 3) RShiftLNode(t2, phase->intcon(N / 2)); > - Node *t4 = new (phase->C, 3) AndLNode(t2, phase->longcon(0xFFFFFFFF)); > - t3 = phase->transform(t3); > - t4 = phase->transform(t4); > - > - Node *t5 = phase->transform(new (phase->C, 3) AddLNode(t4, lohi_product)); > - Node *t6 = phase->transform(new (phase->C, 3) RShiftLNode(t5, phase->intcon(N / 2))); > - Node *t7 = phase->transform(new (phase->C, 3) AddLNode(t3, hihi_product)); > + // u0 = u & 0xFFFF; u1 = u >> 16; > + Node *u0 = phase->transform(new (phase->C, 3) AndLNode(dividend, phase->longcon(0xFFFFFFFF))); > + Node *u1 = phase->transform(new (phase->C, 3) RShiftLNode(dividend, phase->intcon(N / 2))); > + > + // v0 = v & 0xFFFF; v1 = v >> 16; > + Node *v0 = phase->longcon(magic_const & 0xFFFFFFFF); > + Node *v1 = phase->longcon(magic_const >> N / 2); > + > + // w0 = u0*v0; > + Node *w0 = phase->transform(new (phase->C, 3) MulLNode(u0, v0)); > + > + // t = u1*v0 + (w0 >> 16); > + Node *u1v0 = phase->transform(new (phase->C, 3) MulLNode(u1, v0)); > + Node *temp = phase->transform(new (phase->C, 3) URShiftLNode(w0, phase->intcon(N / 2))); > + Node *t = phase->transform(new (phase->C, 3) AddLNode(u1v0, temp)); > + > + // w1 = t & 0xFFFF; > + Node *w1 = new (phase->C, 3) AndLNode(t, phase->longcon(0xFFFFFFFF)); > + > + // w2 = t >> 16; > + Node *w2 = new (phase->C, 3) RShiftLNode(t, phase->intcon(N / 2)); > + > + // 6732154: Construct both w1 and w2 before transforming, so t > + // doesn't go dead prematurely. > + w1 = phase->transform(w1); > + w2 = phase->transform(w2); > + > + // w1 = u0*v1 + w1; > + Node *u0v1 = phase->transform(new (phase->C, 3) MulLNode(u0, v1)); > + w1 = phase->transform(new (phase->C, 3) AddLNode(u0v1, w1)); > + > + // return u1*v1 + w2 + (w1 >> 16); > + Node *u1v1 = phase->transform(new (phase->C, 3) MulLNode(u1, v1)); > + Node *temp1 = phase->transform(new (phase->C, 3) AddLNode(u1v1, w2)); > + Node *temp2 = phase->transform(new (phase->C, 3) RShiftLNode(w1, phase->intcon(N / 2))); > > - return new (phase->C, 3) AddLNode(t7, t6); > + return new (phase->C, 3) AddLNode(temp1, temp2); > } > > > > > From Christian.Thalinger at Sun.COM Mon Feb 2 08:54:05 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 02 Feb 2009 17:54:05 +0100 Subject: long_by_long_mulhi() rewritten and commented In-Reply-To: <4149a0430902020842k72be098ds20450eeece376062@mail.gmail.com> References: <1233572479.3982.29.camel@localhost.localdomain> <4149a0430902020842k72be098ds20450eeece376062@mail.gmail.com> Message-ID: <1233593646.3982.59.camel@localhost.localdomain> On Mon, 2009-02-02 at 08:42 -0800, Chuck Rasbold wrote: > Christian - > > I think your suggested change with attribution to Hacker's Delight is > a good idea. C2 already references that source elsewhere. Good. > > I would change the constants in the comments to match those used in > the building the ideal graph. Then note in a single place that you > adjusted Warren's algorithm to 64 bits. Yeah. Andrew Haley also said today on IRC that it's a bit confusing. Should I create a CR, make the changes and upload a webrev? -- Christian From rasbold at google.com Mon Feb 2 08:59:39 2009 From: rasbold at google.com (Chuck Rasbold) Date: Mon, 2 Feb 2009 08:59:39 -0800 Subject: long_by_long_mulhi() rewritten and commented In-Reply-To: <1233593646.3982.59.camel@localhost.localdomain> References: <1233572479.3982.29.camel@localhost.localdomain> <4149a0430902020842k72be098ds20450eeece376062@mail.gmail.com> <1233593646.3982.59.camel@localhost.localdomain> Message-ID: <4149a0430902020859h59e7a76ayaca6686412ae8f78@mail.gmail.com> Sure. If you create the CR, I'll review the webrev. -- Chuck On Mon, Feb 2, 2009 at 8:54 AM, Christian Thalinger wrote: > On Mon, 2009-02-02 at 08:42 -0800, Chuck Rasbold wrote: >> Christian - >> >> I think your suggested change with attribution to Hacker's Delight is >> a good idea. C2 already references that source elsewhere. > > Good. > >> >> I would change the constants in the comments to match those used in >> the building the ideal graph. Then note in a single place that you >> adjusted Warren's algorithm to 64 bits. > > Yeah. Andrew Haley also said today on IRC that it's a bit confusing. > Should I create a CR, make the changes and upload a webrev? > > -- Christian > > From Christian.Thalinger at Sun.COM Mon Feb 2 09:40:22 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 02 Feb 2009 18:40:22 +0100 Subject: Request for review (XS): 6800154: Add comments to long_by_long_mulhi() for better understandability Message-ID: <1233596422.3982.60.camel@localhost.localdomain> http://webrev.invokedynamic.info/twisti/6800154/ From Ulf.Zibis at gmx.de Mon Feb 2 14:35:20 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 02 Feb 2009 23:35:20 +0100 Subject: Strange speed dependency Message-ID: <49877528.3000105@gmx.de> Hi all, I have experienced a strange speed dependency of HotSpot compiled code after little change in code, which is not part of the "hot" loop. Is there any explanation for this behavior? Code before little change: class UTF_8_new extends Unicode { // .... private static CoderResult malformed(ByteBuffer src, int sp, CharBuffer dst, int dp, int nb) { src.position(sp -= nb - src.arrayOffset()); CoderResult cr = malformedN(src, nb); updatePositions(src, sp, dst, dp); return cr; } // .... while (sp < sl) { // .... int b2 = sa[sp++]; int b3 = sa[sp++]; int b4 = sa[sp++]; if (isMalformed4(b1, b2)) return malformed(src, sp-2, dst, dp, 2); if (isNotContinuation(b3)) return malformed(src, sp-1, dst, dp, 3); if (isNotContinuation(b4)) return malformed(src, sp, dst, dp, 4); if (dp >= dl - 1) return overflow(src, sp-4, dst, dp); int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ 0x00381f80; // .... } The above code has following output (note gain against UTF_8_70$Decoder): time for sun.nio.cs.UTF_8_60$Decoder: 2701 ms time for sun.nio.cs.UTF_8_70$Decoder: 1984 ms time for sun.nio.cs.UTF_8_new$Decoder: 1720 ms // gain: 264 ms time for sun.nio.cs.UTF_8_last$Decoder: 2110 ms Following small code change made the "hot" part of the loop much slower: class UTF_8_new extends Unicode { // .... private static CoderResult malformed(ByteBuffer src, int sp, CharBuffer dst, int dp, int nb) { src.position(sp - src.arrayOffset()); // removed subtraction of nb CoderResult cr = malformedN(src, nb); updatePositions(src, sp, dst, dp); return cr; } // .... while (sp < sl) { // .... int b2 = sa[sp++]; int b3 = sa[sp++]; int b4 = sa[sp++]; if (isMalformed4(b1, b2)) return malformed(src, sp-4, dst, dp, 2); if (isNotContinuation(b3)) return malformed(src, sp-4, dst, dp, 3); if (isNotContinuation(b4)) return malformed(src, sp-4, dst, dp, 4); if (dp >= dl - 1) return overflow(src, sp-4, dst, dp); int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ 0x00381f80; // .... } time for sun.nio.cs.UTF_8_60$Decoder: 2731 ms time for sun.nio.cs.UTF_8_70$Decoder: 1981 ms time for sun.nio.cs.UTF_8_new$Decoder: 1872 ms // gain: 109 ms time for sun.nio.cs.UTF_8_last$Decoder: 2094 ms For complete sources compare following revisions (... and run UTF_8Benchmark.java ): https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=613 https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=614 -Ulf From martinrb at google.com Mon Feb 2 15:02:37 2009 From: martinrb at google.com (Martin Buchholz) Date: Mon, 2 Feb 2009 15:02:37 -0800 Subject: Strange speed dependency In-Reply-To: <49877528.3000105@gmx.de> References: <49877528.3000105@gmx.de> Message-ID: <1ccfd1c10902021502h2671e07tda39b4d0b3aef18a@mail.gmail.com> Ulf, the new UTF_8 decoder in very recent jdks is much faster, and the primary trick that was used to achieve that was reducing the size of the bytecode in the hot methods and moving cold code to separate methods. Martin On Mon, Feb 2, 2009 at 14:35, Ulf Zibis wrote: > Hi all, > > I have experienced a strange speed dependency of HotSpot compiled code after > little change in code, which is not part of the "hot" loop. > Is there any explanation for this behavior? > > Code before little change: > > class UTF_8_new extends Unicode { > > // .... > > private static CoderResult malformed(ByteBuffer src, int sp, > CharBuffer dst, int dp, int nb) { > src.position(sp -= nb - src.arrayOffset()); > CoderResult cr = malformedN(src, nb); > updatePositions(src, sp, dst, dp); > return cr; > } > > // .... > > while (sp < sl) { > // .... > int b2 = sa[sp++]; > int b3 = sa[sp++]; > int b4 = sa[sp++]; > if (isMalformed4(b1, b2)) > return malformed(src, sp-2, dst, dp, 2); > if (isNotContinuation(b3)) > return malformed(src, sp-1, dst, dp, 3); > if (isNotContinuation(b4)) > return malformed(src, sp, dst, dp, 4); > if (dp >= dl - 1) > return overflow(src, sp-4, dst, dp); > int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ > 0x00381f80; > // .... > } > > The above code has following output (note gain against UTF_8_70$Decoder): > time for sun.nio.cs.UTF_8_60$Decoder: 2701 ms > time for sun.nio.cs.UTF_8_70$Decoder: 1984 ms > time for sun.nio.cs.UTF_8_new$Decoder: 1720 ms // gain: 264 ms > time for sun.nio.cs.UTF_8_last$Decoder: 2110 ms > > > Following small code change made the "hot" part of the loop much slower: > > class UTF_8_new extends Unicode { > > // .... > > private static CoderResult malformed(ByteBuffer src, int sp, > CharBuffer dst, int dp, int nb) { > src.position(sp - src.arrayOffset()); // removed subtraction of > nb > CoderResult cr = malformedN(src, nb); > updatePositions(src, sp, dst, dp); > return cr; > } > > // .... > > while (sp < sl) { > // .... > int b2 = sa[sp++]; > int b3 = sa[sp++]; > int b4 = sa[sp++]; > if (isMalformed4(b1, b2)) > return malformed(src, sp-4, dst, dp, 2); > if (isNotContinuation(b3)) > return malformed(src, sp-4, dst, dp, 3); > if (isNotContinuation(b4)) > return malformed(src, sp-4, dst, dp, 4); > if (dp >= dl - 1) > return overflow(src, sp-4, dst, dp); > int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ > 0x00381f80; > // .... > } > > time for sun.nio.cs.UTF_8_60$Decoder: 2731 ms > time for sun.nio.cs.UTF_8_70$Decoder: 1981 ms > time for sun.nio.cs.UTF_8_new$Decoder: 1872 ms // gain: 109 ms > time for sun.nio.cs.UTF_8_last$Decoder: 2094 ms > > For complete sources compare following revisions (... and run > UTF_8Benchmark.java ): > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=613 > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=614 > > > -Ulf > > > > From John.Rose at Sun.COM Mon Feb 2 15:05:22 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 02 Feb 2009 15:05:22 -0800 Subject: long_by_long_mulhi() rewritten and commented In-Reply-To: <4149a0430902020859h59e7a76ayaca6686412ae8f78@mail.gmail.com> References: <1233572479.3982.29.camel@localhost.localdomain> <4149a0430902020842k72be098ds20450eeece376062@mail.gmail.com> <1233593646.3982.59.camel@localhost.localdomain> <4149a0430902020859h59e7a76ayaca6686412ae8f78@mail.gmail.com> Message-ID: (Should have CC-ed the list...) Begin forwarded message: From: John Rose Date: February 2, 2009 2:54:51 PM PST To: Christian Thalinger Subject: Re: Request for review (XS): 6800154: Add comments to long_by_long_mulhi() for better understandability On Feb 2, 2009, at 9:40 AM, Christian Thalinger wrote: > http://webrev.invokedynamic.info/twisti/6800154/ A couple of comments: > + Node *v1 = phase->longcon(magic_const >> N / 2); should be: > + Node* v1 = phase->longcon(magic_const >> (N / 2)); We use parens liberally, especially when the operator precedences are not from simple algebra. Also (this is more of a judgement call for you) when renovating code, I suggest moving toward the majority style "T* " instead of "T *", the latter of which is peculiar to old opto code. I spot-checked the details, but did not prove equivalence. I would run a few test cases before and after the change, and look at the disassembled code to be sure all is well. Nice rewrite; thanks. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090202/11d3f18b/attachment.html From Thomas.Rodriguez at Sun.COM Mon Feb 2 16:44:37 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 02 Feb 2009 16:44:37 -0800 Subject: review (XS) for 6798785 Message-ID: <7503B943-9508-49BB-85AC-8AFD6D0C0344@Sun.COM> http://webrev.invokedynamic.info/never/6798785 From Ulf.Zibis at gmx.de Mon Feb 2 17:03:31 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 03 Feb 2009 02:03:31 +0100 Subject: Strange speed dependency In-Reply-To: <1ccfd1c10902021502h2671e07tda39b4d0b3aef18a@mail.gmail.com> References: <49877528.3000105@gmx.de> <1ccfd1c10902021502h2671e07tda39b4d0b3aef18a@mail.gmail.com> Message-ID: <498797E3.5040602@gmx.de> Martin, the reason for my post was to give the HotSpot guys some hint for additional enhancement. BTW, I have used the recent UTF_8 decoder for my reference. ... But I have experienced some errors: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795537 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6798514 Most of them I have repaired yet, and fortunately I could enhance the speed by another ~20 % (on my machine, should be evaluated). -Ulf Am 03.02.2009 00:02, Martin Buchholz schrieb: > Ulf, the new UTF_8 decoder in very recent jdks is much faster, > and the primary trick that was used to achieve that > was reducing the size of the bytecode in the hot methods > and moving cold code to separate methods. > > Martin > > On Mon, Feb 2, 2009 at 14:35, Ulf Zibis wrote: > >> Hi all, >> >> I have experienced a strange speed dependency of HotSpot compiled code after >> little change in code, which is not part of the "hot" loop. >> Is there any explanation for this behavior? >> >> Code before little change: >> >> class UTF_8_new extends Unicode { >> >> // .... >> >> private static CoderResult malformed(ByteBuffer src, int sp, >> CharBuffer dst, int dp, int nb) { >> src.position(sp -= nb - src.arrayOffset()); >> CoderResult cr = malformedN(src, nb); >> updatePositions(src, sp, dst, dp); >> return cr; >> } >> >> // .... >> >> while (sp < sl) { >> // .... >> int b2 = sa[sp++]; >> int b3 = sa[sp++]; >> int b4 = sa[sp++]; >> if (isMalformed4(b1, b2)) >> return malformed(src, sp-2, dst, dp, 2); >> if (isNotContinuation(b3)) >> return malformed(src, sp-1, dst, dp, 3); >> if (isNotContinuation(b4)) >> return malformed(src, sp, dst, dp, 4); >> if (dp >= dl - 1) >> return overflow(src, sp-4, dst, dp); >> int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ >> 0x00381f80; >> // .... >> } >> >> The above code has following output (note gain against UTF_8_70$Decoder): >> time for sun.nio.cs.UTF_8_60$Decoder: 2701 ms >> time for sun.nio.cs.UTF_8_70$Decoder: 1984 ms >> time for sun.nio.cs.UTF_8_new$Decoder: 1720 ms // gain: 264 ms >> time for sun.nio.cs.UTF_8_last$Decoder: 2110 ms >> >> >> Following small code change made the "hot" part of the loop much slower: >> >> class UTF_8_new extends Unicode { >> >> // .... >> >> private static CoderResult malformed(ByteBuffer src, int sp, >> CharBuffer dst, int dp, int nb) { >> src.position(sp - src.arrayOffset()); // removed subtraction of >> nb >> CoderResult cr = malformedN(src, nb); >> updatePositions(src, sp, dst, dp); >> return cr; >> } >> >> // .... >> >> while (sp < sl) { >> // .... >> int b2 = sa[sp++]; >> int b3 = sa[sp++]; >> int b4 = sa[sp++]; >> if (isMalformed4(b1, b2)) >> return malformed(src, sp-4, dst, dp, 2); >> if (isNotContinuation(b3)) >> return malformed(src, sp-4, dst, dp, 3); >> if (isNotContinuation(b4)) >> return malformed(src, sp-4, dst, dp, 4); >> if (dp >= dl - 1) >> return overflow(src, sp-4, dst, dp); >> int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ >> 0x00381f80; >> // .... >> } >> >> time for sun.nio.cs.UTF_8_60$Decoder: 2731 ms >> time for sun.nio.cs.UTF_8_70$Decoder: 1981 ms >> time for sun.nio.cs.UTF_8_new$Decoder: 1872 ms // gain: 109 ms >> time for sun.nio.cs.UTF_8_last$Decoder: 2094 ms >> >> For complete sources compare following revisions (... and run >> UTF_8Benchmark.java ): >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=613 >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=614 >> >> >> -Ulf >> >> >> >> >> > > > From Thomas.Rodriguez at Sun.COM Mon Feb 2 17:04:51 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 02 Feb 2009 17:04:51 -0800 Subject: review (XS) for 6782260 Message-ID: http://webrev.invokedynamic.info/never/6782260 From Thomas.Rodriguez at Sun.COM Mon Feb 2 18:59:04 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 02 Feb 2009 18:59:04 -0800 Subject: simple mercurial tricks Message-ID: I just figured out a couple simple mercurial tricks that I thought I'd share. The first is using the mercurial tags to figure out which hotspot build went into a particular jdk build. The basic form is this: hg cat -r tag make/hotspot_version | grep HS_ where tag is one of the jdk7-b* tags that RE puts on the build. For instance % hg cat -r jdk7-b39 make/hotspot_version | grep HS_ HS_MAJOR_VER=14 HS_MINOR_VER=0 HS_BUILD_NUMBER=06 So jdk7-b39 has hs14.0-b06 in it. You can do something similar with the web interface using URLs like this: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/jdk7-b39/make/hotspot_version Obviously the hotspot_version file contents are only meaningful at the pointer the promotion was made so you can't get a direct mapping from a changeset to the particular build it went into. The other trick requires a mercurial extension called nearest from http://freehg.org/u/morisgi/nearest . Basically it finds the immediately dominating tag for a particular revision. It can also find the post dominating tag, which lets you directly query which jdk build a particular fix went into. % hg log -r 8261ee795323 changeset: 333:8261ee795323 user: rasbold date: Wed Sep 17 08:29:17 2008 -0700 summary: 6711100: 64bit fastdebug server vm crashes with assert(_base == Int,"Not an Int") % hg nearest --contains 8261ee795323 jdk7 -b39-21 So 8261ee795323 is 21 changesets before the changeset tagged with jdk7- b39, so 6711100 was fixed in hs14-b06 which is in jdk7-b39. There are other ways to find the answer to these questions but I think asking the repo directly is more reliable and often more convenient. I've only played with the nearest extensions lightly but I didn't see any way to ask this question with existing commands and it seems to work ok. tom From rgougol at gmail.com Mon Feb 2 21:39:23 2009 From: rgougol at gmail.com (Rouhollah Gougol) Date: Mon, 2 Feb 2009 21:39:23 -0800 Subject: Backward Branch Counts Message-ID: Hello everybody, Would somebody describe to me the why backward branches of a method for OnStackReplacement are counted differently when the ProfileInterpreter is enabled from when ProfileInterpreter is false. When NOT profiling the interpreter, like in x86_32 client compiler, HotSpot adds the method invocation count of a given method to the total number of the backward branches within the method and compare the sum with InvocationCounter::InterpreterBackwardBranchLimit. When profiling the interpreter, HotSpot, using the method, InterpreterMacroAssembler::profile_taken_branch, counts the total number of branches and compares it with the same backward branch threshold as the former approach. So WHY, when ProfileInterptere == true, Hotspot adds both forward and backward branches and the method, profile_taken_branch does not exclude forward braches? AND WHY, ProfileInterpreter==true, HotSpot does not add the number of backward branches to the method invocation count? Lots of Thanks in advance for any feedback. Sincerely, R. Gougol -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090202/f9cd5761/attachment.html From Christian.Thalinger at Sun.COM Mon Feb 2 23:55:26 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 03 Feb 2009 08:55:26 +0100 Subject: long_by_long_mulhi() rewritten and commented In-Reply-To: References: <1233572479.3982.29.camel@localhost.localdomain> <4149a0430902020842k72be098ds20450eeece376062@mail.gmail.com> <1233593646.3982.59.camel@localhost.localdomain> <4149a0430902020859h59e7a76ayaca6686412ae8f78@mail.gmail.com> Message-ID: <1233647726.3982.70.camel@localhost.localdomain> On Mon, 2009-02-02 at 15:05 -0800, John Rose wrote: > A couple of comments: > > + Node *v1 = phase->longcon(magic_const >> N / 2); > > should be: > > + Node* v1 = phase->longcon(magic_const >> (N / 2)); > > We use parens liberally, especially when the operator precedences are > not from simple algebra. Good point. > > Also (this is more of a judgement call for you) when renovating code, > I suggest moving toward the majority style "T* " instead of "T *", the > latter of which is peculiar to old opto code. Normally I use T* but I thought HotSpot code does it differently. I will change that and use it from now on. > > I spot-checked the details, but did not prove equivalence. I would > run a few test cases before and after the change, and look at the > disassembled code to be sure all is well. Yeah, I will run some tests in a minute. -- Christian From Christian.Thalinger at Sun.COM Tue Feb 3 04:21:17 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 03 Feb 2009 12:21:17 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6795362: 32bit server compiler leads to wrong results on solaris-x86 Message-ID: <20090203122119.A641B126D8@hg.openjdk.java.net> Changeset: 7628781568e1 Author: twisti Date: 2009-02-03 01:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7628781568e1 6795362: 32bit server compiler leads to wrong results on solaris-x86 Summary: The C2 compiler leads to wrong results on solaris-i486 (32-bit) for a testcase given in the CR. Reviewed-by: never, rasbold ! src/share/vm/opto/mulnode.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/compiler/6795362/Test6795362.java From Christian.Thalinger at Sun.COM Tue Feb 3 08:46:16 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 03 Feb 2009 17:46:16 +0100 Subject: loadUB2L: SPARC vs. x86 (6797305) Message-ID: <1233679576.3982.119.camel@localhost.localdomain> Hi all! While working on 6797305 it looked more closely at the AD files and I saw that there is already some kind of unsigned byte load to long (loadUBL) on SPARC: match(Set dst (AndL (ConvI2L (LoadB mem)) bytemask)); But it's a bit different than the (commented) one on x86: match(Set dst (ConvI2L (AndI (LoadB mem) bytemask))); The SPARC one matches code like: ((long) ba[0]) & 0xFF; while the x86 one matches: (long) (ba[0] & 0xFF); I wonder if the SPARC one is a common pattern and has been added intentional. I'd guess that the x86 one is more common. My patch will change the match to: match(Set dst (ConvI2L (LoadUB mem))); what is more easy to transform in the ideal graph. So the question is, which one of the two should we optimize? Or even both of them? -- Christian From Thomas.Rodriguez at Sun.COM Tue Feb 3 11:08:25 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 03 Feb 2009 11:08:25 -0800 Subject: loadUB2L: SPARC vs. x86 (6797305) In-Reply-To: <1233679576.3982.119.camel@localhost.localdomain> References: <1233679576.3982.119.camel@localhost.localdomain> Message-ID: <6E2C5598-80C7-4E66-8013-5A5CDF762FE9@sun.com> I think either one could occur as a result of inlining. I suspect the sparc version is really from ba[0] & 0xffL. I'd probably do both though. In general there isn't a lot of uniformity in which patterns like this are matched in the different ad files and it might be nice to fix that. I think I have a few lying around in a workspace that I could dig out. We might consider improving some of our Ideal methods to canonicalize these patterns with the assumption that the AD file will match them. It just occurred to me that the part of the original problem that motivated introducing LoadUB could be solved by changes in the Matcher::find_shared logic. That logic is responsible for finding Nodes in the graph that have to be matched into a register because there are multiple users. In the original example of (StoreC mem2 addr2 (AndI (LoadB mem1 addr1) (ConI 0xff))) the AndI and the LoadB only have only a single user so they aren't forced into a register but the logic in the matcher that checks the memory breaks that match at the LoadB forcing it into a register. If we modified find_shared to check for the idioms we want to support it could mark the AndI as shared which would start the match where we want and there would be no memory problems. There was some other problem with control edges on other nodes that was breaking the match but maybe those could be resolved as well. tom On Feb 3, 2009, at 8:46 AM, Christian Thalinger wrote: > Hi all! > > While working on 6797305 it looked more closely at the AD files and I > saw that there is already some kind of unsigned byte load to long > (loadUBL) on SPARC: > > match(Set dst (AndL (ConvI2L (LoadB mem)) bytemask)); > > But it's a bit different than the (commented) one on x86: > > match(Set dst (ConvI2L (AndI (LoadB mem) bytemask))); > > The SPARC one matches code like: > > ((long) ba[0]) & 0xFF; > > while the x86 one matches: > > (long) (ba[0] & 0xFF); > > I wonder if the SPARC one is a common pattern and has been added > intentional. I'd guess that the x86 one is more common. > > My patch will change the match to: > > match(Set dst (ConvI2L (LoadUB mem))); > > what is more easy to transform in the ideal graph. > > So the question is, which one of the two should we optimize? Or even > both of them? > > -- Christian > From Christian.Thalinger at Sun.COM Tue Feb 3 12:50:22 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 03 Feb 2009 20:50:22 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6799452: HotSpot tests Makefile should take care of ALT_SLASH_JAVA Message-ID: <20090203205024.66810126F1@hg.openjdk.java.net> Changeset: b79faa366fbd Author: twisti Date: 2009-02-03 08:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b79faa366fbd 6799452: HotSpot tests Makefile should take care of ALT_SLASH_JAVA Summary: The HotSpot tests Makefile has a hardcoded SLASH_JAVA which makes it difficult to run the tests on non-Sun build machines which do not have a /java infrastructure. Reviewed-by: kamg ! test/Makefile From Thomas.Rodriguez at Sun.COM Tue Feb 3 17:27:05 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 03 Feb 2009 17:27:05 -0800 Subject: SafePointNodes and raw memory Message-ID: <809A39D2-FECB-4567-ADC9-84977C178B6D@Sun.COM> I was very surprised today to discover that SafePointNodes don't create a new raw memory state. Does anyone know the history of this? This breaks any piece of code using raw memory that relies on memory dependence for proper evaluation order which is a pretty basic assumption of ideal. The G1 pre barriers are broken at least partly for this reason. tom From thomas.rodriguez at sun.com Tue Feb 3 20:29:13 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 04 Feb 2009 04:29:13 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6782260: Memory leak in CodeBuffer::create_patch_overflow Message-ID: <20090204042915.64D6A12719@hg.openjdk.java.net> Changeset: 5bfdb08ea692 Author: never Date: 2009-02-03 18:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5bfdb08ea692 6782260: Memory leak in CodeBuffer::create_patch_overflow Reviewed-by: phh, kvn ! src/share/vm/asm/codeBuffer.cpp From Ulf.Zibis at gmx.de Wed Feb 4 00:59:19 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 04 Feb 2009 09:59:19 +0100 Subject: loadUB2L: SPARC vs. x86 (6797305) In-Reply-To: <1233679576.3982.119.camel@localhost.localdomain> References: <1233679576.3982.119.camel@localhost.localdomain> Message-ID: <498958E7.7020408@gmx.de> I think, ((long) ba[0]) & 0xFF; is bad coding style, and maybe should be optimized by javac. So +1 for preferring x86 pattern, or both. -Ulf Am 03.02.2009 17:46, Christian Thalinger schrieb: > Hi all! > > While working on 6797305 it looked more closely at the AD files and I > saw that there is already some kind of unsigned byte load to long > (loadUBL) on SPARC: > > match(Set dst (AndL (ConvI2L (LoadB mem)) bytemask)); > > But it's a bit different than the (commented) one on x86: > > match(Set dst (ConvI2L (AndI (LoadB mem) bytemask))); > > The SPARC one matches code like: > > ((long) ba[0]) & 0xFF; > > while the x86 one matches: > > (long) (ba[0] & 0xFF); > > I wonder if the SPARC one is a common pattern and has been added > intentional. I'd guess that the x86 one is more common. > > My patch will change the match to: > > match(Set dst (ConvI2L (LoadUB mem))); > > what is more easy to transform in the ideal graph. > > So the question is, which one of the two should we optimize? Or even > both of them? > > -- Christian > > > From Christian.Thalinger at Sun.COM Wed Feb 4 10:19:29 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 04 Feb 2009 19:19:29 +0100 Subject: Request for review (XS): 6800154: Add comments to long_by_long_mulhi() for better understandability In-Reply-To: <1233596422.3982.60.camel@localhost.localdomain> References: <1233596422.3982.60.camel@localhost.localdomain> Message-ID: <1233771569.1536.19.camel@localhost.localdomain> On Mon, 2009-02-02 at 18:40 +0100, Christian Thalinger wrote: > http://webrev.invokedynamic.info/twisti/6800154/ I have uploaded a new version of the patch which includes a testcase. -- Christian From Vladimir.Kozlov at Sun.COM Wed Feb 4 11:28:43 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 04 Feb 2009 11:28:43 -0800 Subject: Request for review (XS): 6800154: Add comments to long_by_long_mulhi() for better understandability In-Reply-To: <1233771569.1536.19.camel@localhost.localdomain> References: <1233596422.3982.60.camel@localhost.localdomain> <1233771569.1536.19.camel@localhost.localdomain> Message-ID: <4989EC6B.5040306@sun.com> Christian, Looks good. Thanks, Vladimir Christian Thalinger wrote: > On Mon, 2009-02-02 at 18:40 +0100, Christian Thalinger wrote: >> http://webrev.invokedynamic.info/twisti/6800154/ > > I have uploaded a new version of the patch which includes a testcase. > > -- Christian > From Ulf.Zibis at gmx.de Wed Feb 4 11:50:44 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 04 Feb 2009 20:50:44 +0100 Subject: Strange speed dependency; help needed for benchmark, please In-Reply-To: <49877528.3000105@gmx.de> References: <49877528.3000105@gmx.de> Message-ID: <4989F193.1020807@gmx.de> Hi, I experience very much different mutually contradictory times running my UTF-8 benchmark https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/UTF_8Benchmark.java?diff_format=s&rev=620&view=markup for only 1 code unit pattern _against_ running for all code unit patterns: selected pattern 4 time for sun.nio.cs.UTF_8_60$Decoder: 2851 ms time for sun.nio.cs.UTF_8_70$Decoder: 2501 ms time for sun.nio.cs.UTF_8_last$Decoder: 2310 ms time for sun.nio.cs.UTF_8_new$Decoder: 2048 ms selected all patterns (SRC_BUF = -1) time for sun.nio.cs.UTF_8_60$Decoder: 4951 4925 5351 4531 5269 4686 ms time for sun.nio.cs.UTF_8_70$Decoder: 476 3066 4815 3921 4907 3369 ms time for sun.nio.cs.UTF_8_last$Decoder: 560 3237 4539 4575 4772 3334 ms time for sun.nio.cs.UTF_8_new$Decoder: 531 3642 4741 4462 5497 3742 ms The absolute difference can be explained very simply: I am running the tests on a mobile machine (notebook), so during heavy test, CPU is getting hot, and is down-clocked automatically by power management. ... but I don't have any explanation for the relative differences (compare "pattern 4"-run against 2nd last column from "all patterns"-run). In the 1st run UTF_8_new$Decoder is much faster than recent JDK7 UTF_8_70$Decoder: 2048 ms ./. 2501 ms, but not in 2nd run: 5497 ms ./. 4907 ms. Also I experience significant differences, when I change the chronological order of the tested decoders, see line 29... : int dec = 0; // change process order of decoders for different results: decoders[dec++] = new UTF_8_60().newDecoder(); decoders[dec++] = new UTF_8_70().newDecoder(); decoders[dec++] = new UTF_8_last().newDecoder(); decoders[dec++] = new UTF_8_new().newDecoder(); .... So can anybody please run my benchmark on a stable-clock machine and check also for different process order of decoders. If I'm not wrong, you only need to download: UTF_8_60, UTF_8_70, UTF_8_last, UTF_8_new and UTF_8Benchmark from: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=620#dirlist Very much thanks for your help, -Ulf Am 02.02.2009 23:35, Ulf Zibis schrieb: > Hi all, > > I have experienced a strange speed dependency of HotSpot compiled code > after little change in code, which is not part of the "hot" loop. > Is there any explanation for this behavior? > > Code before little change: > > class UTF_8_new extends Unicode { > > // .... > > private static CoderResult malformed(ByteBuffer src, int sp, > CharBuffer dst, int dp, > int nb) { > src.position(sp -= nb - src.arrayOffset()); > CoderResult cr = malformedN(src, nb); > updatePositions(src, sp, dst, dp); > return cr; > } > > // .... > > while (sp < sl) { > // .... > int b2 = sa[sp++]; > int b3 = sa[sp++]; > int b4 = sa[sp++]; > if (isMalformed4(b1, b2)) > return malformed(src, sp-2, dst, dp, 2); > if (isNotContinuation(b3)) > return malformed(src, sp-1, dst, dp, 3); > if (isNotContinuation(b4)) > return malformed(src, sp, dst, dp, 4); > if (dp >= dl - 1) > return overflow(src, sp-4, dst, dp); > int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 > ^ 0x00381f80; > // .... > } > > The above code has following output (note gain against UTF_8_70$Decoder): > time for sun.nio.cs.UTF_8_60$Decoder: 2701 ms > time for sun.nio.cs.UTF_8_70$Decoder: 1984 ms > time for sun.nio.cs.UTF_8_new$Decoder: 1720 ms // gain: 264 ms > time for sun.nio.cs.UTF_8_last$Decoder: 2110 ms > > > Following small code change made the "hot" part of the loop much slower: > > class UTF_8_new extends Unicode { > > // .... > > private static CoderResult malformed(ByteBuffer src, int sp, > CharBuffer dst, int dp, > int nb) { > src.position(sp - src.arrayOffset()); // removed > subtraction of nb > CoderResult cr = malformedN(src, nb); > updatePositions(src, sp, dst, dp); > return cr; > } > > // .... > > while (sp < sl) { > // .... > int b2 = sa[sp++]; > int b3 = sa[sp++]; > int b4 = sa[sp++]; > if (isMalformed4(b1, b2)) > return malformed(src, sp-4, dst, dp, 2); > if (isNotContinuation(b3)) > return malformed(src, sp-4, dst, dp, 3); > if (isNotContinuation(b4)) > return malformed(src, sp-4, dst, dp, 4); > if (dp >= dl - 1) > return overflow(src, sp-4, dst, dp); > int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 > ^ 0x00381f80; > // .... > } > > time for sun.nio.cs.UTF_8_60$Decoder: 2731 ms > time for sun.nio.cs.UTF_8_70$Decoder: 1981 ms > time for sun.nio.cs.UTF_8_new$Decoder: 1872 ms // gain: 109 ms > time for sun.nio.cs.UTF_8_last$Decoder: 2094 ms > > For complete sources compare following revisions (... and run > UTF_8Benchmark.java ): > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=613 > > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=614 > > > > -Ulf > > > > From thomas.rodriguez at sun.com Wed Feb 4 14:08:08 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 04 Feb 2009 22:08:08 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6798785: Crash in OopFlow::build_oop_map: incorrect comparison of 64bit pointers Message-ID: <20090204220810.93B5C12B1E@hg.openjdk.java.net> Changeset: 1580954e694c Author: never Date: 2009-02-04 11:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1580954e694c 6798785: Crash in OopFlow::build_oop_map: incorrect comparison of 64bit pointers Reviewed-by: phh, kvn ! src/share/vm/adlc/dict2.cpp ! src/share/vm/libadt/dict.cpp From Thomas.Rodriguez at Sun.COM Wed Feb 4 16:16:03 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 04 Feb 2009 16:16:03 -0800 Subject: review (S) for 6442502 Message-ID: http://webrev.invokedynamic.info/never/6442502 From Thomas.Rodriguez at Sun.COM Wed Feb 4 17:02:14 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 04 Feb 2009 17:02:14 -0800 Subject: review (S) for 6793828 Message-ID: http://webrev.invokedynamic.info/never/6793828/ From John.Rose at Sun.COM Wed Feb 4 17:30:56 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 04 Feb 2009 17:30:56 -0800 Subject: review (S) for 6793828 In-Reply-To: References: Message-ID: <89A83F42-5102-44E7-830D-BD0E7F5385AA@sun.com> Reviewed. I agree that it's surprising that safepoints don't modify raw memory. A pure safepoint cannot change managed pointers (as far as the compiler can see) so I would think that it would modify *only* raw memory. I don't remember how we got to this design... -- John On Feb 4, 2009, at 5:02 PM, Tom Rodriguez wrote: > http://webrev.invokedynamic.info/never/6793828/ From Vladimir.Kozlov at Sun.COM Wed Feb 4 17:49:39 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 04 Feb 2009 17:49:39 -0800 Subject: review (S) for 6793828 In-Reply-To: References: Message-ID: <498A45B3.2030409@sun.com> Tom, switch next lines since all_controls_dominate() is expensive method: ! && all_controls_dominate(base, phase->C->start()) ! && phase->C->get_alias_index(phase->type(address)->is_ptr()) != Compile::AliasIdxRaw) { thanks, Vladimir Tom Rodriguez wrote: > http://webrev.invokedynamic.info/never/6793828/ From Thomas.Rodriguez at Sun.COM Wed Feb 4 18:21:36 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 04 Feb 2009 18:21:36 -0800 Subject: review (S) for 6793828 In-Reply-To: <498A45B3.2030409@sun.com> References: <498A45B3.2030409@sun.com> Message-ID: I'm not sure it matters since I think it rarely triggers but I'm happy to switch it. tom On Feb 4, 2009, at 5:49 PM, Vladimir Kozlov wrote: > Tom, > > switch next lines since all_controls_dominate() is expensive method: > > ! && all_controls_dominate(base, phase->C->start()) > ! && phase->C->get_alias_index(phase->type(address)- > >is_ptr()) != Compile::AliasIdxRaw) { > > thanks, > Vladimir > > Tom Rodriguez wrote: >> http://webrev.invokedynamic.info/never/6793828/ From Vladimir.Kozlov at Sun.COM Wed Feb 4 18:19:09 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 04 Feb 2009 18:19:09 -0800 Subject: review (S) for 6442502 In-Reply-To: References: Message-ID: <498A4C9D.8020406@sun.com> Tom, null() is defined as zerocon(T_OBJECT) but basic type for TypeRawPtr is T_ADDRESS. To be consistent use zerocon(T_ADDRESS) instead of null(). Thanks, Vladimir Tom Rodriguez wrote: > http://webrev.invokedynamic.info/never/6442502 From Vladimir.Kozlov at Sun.COM Wed Feb 4 18:20:49 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 04 Feb 2009 18:20:49 -0800 Subject: review (S) for 6793828 In-Reply-To: References: <498A45B3.2030409@sun.com> Message-ID: <498A4D01.203@sun.com> Thanks, Vladimir Tom Rodriguez wrote: > I'm not sure it matters since I think it rarely triggers but I'm happy > to switch it. > > tom > > On Feb 4, 2009, at 5:49 PM, Vladimir Kozlov wrote: > >> Tom, >> >> switch next lines since all_controls_dominate() is expensive method: >> >> ! && all_controls_dominate(base, phase->C->start()) >> ! && phase->C->get_alias_index(phase->type(address)->is_ptr()) >> != Compile::AliasIdxRaw) { >> >> thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://webrev.invokedynamic.info/never/6793828/ > From Thomas.Rodriguez at Sun.COM Wed Feb 4 18:25:46 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 04 Feb 2009 18:25:46 -0800 Subject: review (S) for 6793828 In-Reply-To: <89A83F42-5102-44E7-830D-BD0E7F5385AA@sun.com> References: <89A83F42-5102-44E7-830D-BD0E7F5385AA@sun.com> Message-ID: <56E88B1C-901B-4BD3-9E6F-AEE5B534B41E@Sun.COM> On Feb 4, 2009, at 5:30 PM, John Rose wrote: > Reviewed. > > I agree that it's surprising that safepoints don't modify raw > memory. A pure safepoint cannot change managed pointers (as far as > the compiler can see) so I would think that it would modify *only* > raw memory. I don't remember how we got to this design... I suspect that all our other uses of raw memory are pretty tightly control dependent so they don't trip on this. I know that Steve had a lot of trouble getting the G1 writer barrier to work correctly because of issues like this though it's somewhat amazing we didn't actually hit it before. Steve also has some work with conditional card marks that important for the scalability of oop related concurrent access. There were some problems there having to do with improving our ability to elide repeated card marks to reduce any overhead of conditional card marks and getting the memory deps right was part of the issue. I suspect if we want to do conditional card marks effectively we'll need to fix SafePointNodes to produce a new raw memory. tom > > > -- John > > On Feb 4, 2009, at 5:02 PM, Tom Rodriguez wrote: > >> http://webrev.invokedynamic.info/never/6793828/ > From Thomas.Rodriguez at Sun.COM Wed Feb 4 19:07:06 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 04 Feb 2009 19:07:06 -0800 Subject: review (S) for 6442502 In-Reply-To: <498A4C9D.8020406@sun.com> References: <498A4C9D.8020406@sun.com> Message-ID: There's only one kind of NULL in the type system and that's TypePtr::NULL_PTR which is what null() returns for every kind of pointer. It seems obfuscating to use something other than null() in that case doesn't it? tom On Feb 4, 2009, at 6:19 PM, Vladimir Kozlov wrote: > Tom, > > null() is defined as zerocon(T_OBJECT) but > basic type for TypeRawPtr is T_ADDRESS. > To be consistent use zerocon(T_ADDRESS) instead of null(). > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://webrev.invokedynamic.info/never/6442502 From Vladimir.Kozlov at Sun.COM Wed Feb 4 19:17:38 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 04 Feb 2009 19:17:38 -0800 Subject: review (S) for 6442502 In-Reply-To: References: <498A4C9D.8020406@sun.com> Message-ID: <498A5A52.6060705@sun.com> Actually all ptr types will produce the same zerocon since all have the same zero_type: _zero_type[T_OBJECT] = TypePtr::NULL_PTR; _zero_type[T_ARRAY] = TypePtr::NULL_PTR; // null array is null oop _zero_type[T_ADDRESS] = TypePtr::NULL_PTR; // raw pointers use the same null So you are right, you can use null(). Thanks, Vladimir Tom Rodriguez wrote: > There's only one kind of NULL in the type system and that's > TypePtr::NULL_PTR which is what null() returns for every kind of > pointer. It seems obfuscating to use something other than null() in > that case doesn't it? > > tom > > On Feb 4, 2009, at 6:19 PM, Vladimir Kozlov wrote: > >> Tom, >> >> null() is defined as zerocon(T_OBJECT) but >> basic type for TypeRawPtr is T_ADDRESS. >> To be consistent use zerocon(T_ADDRESS) instead of null(). >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://webrev.invokedynamic.info/never/6442502 > From Christian.Thalinger at Sun.COM Wed Feb 4 23:55:53 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 05 Feb 2009 08:55:53 +0100 Subject: Strange speed dependency; help needed for benchmark, please In-Reply-To: <4989F193.1020807@gmx.de> References: <49877528.3000105@gmx.de> <4989F193.1020807@gmx.de> Message-ID: <1233820553.1536.28.camel@localhost.localdomain> On Wed, 2009-02-04 at 20:50 +0100, Ulf Zibis wrote: > Hi, > > I experience very much different mutually contradictory times running my > UTF-8 benchmark > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/UTF_8Benchmark.java?diff_format=s&rev=620&view=markup > for only 1 code unit pattern _against_ running for all code unit patterns: > > selected pattern 4 > time for sun.nio.cs.UTF_8_60$Decoder: 2851 ms > time for sun.nio.cs.UTF_8_70$Decoder: 2501 ms > time for sun.nio.cs.UTF_8_last$Decoder: 2310 ms > time for sun.nio.cs.UTF_8_new$Decoder: 2048 ms This is solaris-amd64: $ gamma -Xbootclasspath/a:. sun/nio/cs/UTF_8Benchmark time for warm up 1: 2455 ms time for warm up 2: 1150 ms time for warm up 3: 1151 ms time for warm up 4: 1180 ms time for sun.nio.cs.UTF_8_60$Decoder: 1553 ms time for sun.nio.cs.UTF_8_70$Decoder: 836 ms time for sun.nio.cs.UTF_8_last$Decoder: 746 ms time for sun.nio.cs.UTF_8_new$Decoder: 943 ms last warm up ./. test loops: 1.1573023 > > selected all patterns (SRC_BUF = -1) > time for sun.nio.cs.UTF_8_60$Decoder: 4951 4925 5351 4531 5269 4686 ms > time for sun.nio.cs.UTF_8_70$Decoder: 476 3066 4815 3921 4907 3369 ms > time for sun.nio.cs.UTF_8_last$Decoder: 560 3237 4539 4575 4772 3334 ms > time for sun.nio.cs.UTF_8_new$Decoder: 531 3642 4741 4462 5497 3742 ms $ gamma -Xbootclasspath/a:. sun/nio/cs/UTF_8Benchmark time for warm up 1: 3942 ms time for warm up 2: 2394 ms time for warm up 3: 2409 ms time for warm up 4: 2388 ms time for sun.nio.cs.UTF_8_60$Decoder: 859 854 2134 1694 2049 1044 ms time for sun.nio.cs.UTF_8_70$Decoder: 290 781 1933 1448 2010 900 ms time for sun.nio.cs.UTF_8_last$Decoder: 414 681 1462 1452 1524 765 ms time for sun.nio.cs.UTF_8_new$Decoder: 396 686 2291 1500 1760 876 ms last warm up ./. test loops: 1.9226139 > Also I experience significant differences, when I change the > chronological order of the tested decoders, see line 29... : > int dec = 0; // change process order of decoders for different > results: > decoders[dec++] = new UTF_8_60().newDecoder(); > decoders[dec++] = new UTF_8_70().newDecoder(); > decoders[dec++] = new UTF_8_last().newDecoder(); > decoders[dec++] = new UTF_8_new().newDecoder(); $ gamma -Xbootclasspath/a:. sun/nio/cs/UTF_8Benchmark time for warm up 1: 2569 ms time for warm up 2: 1140 ms time for warm up 3: 1143 ms time for warm up 4: 1176 ms time for sun.nio.cs.UTF_8_new$Decoder: 745 ms time for sun.nio.cs.UTF_8_60$Decoder: 1536 ms time for sun.nio.cs.UTF_8_last$Decoder: 1001 ms time for sun.nio.cs.UTF_8_70$Decoder: 747 ms last warm up ./. test loops: 1.166911 $ gamma -Xbootclasspath/a:. sun/nio/cs/UTF_8Benchmark time for warm up 1: 4145 ms time for warm up 2: 2598 ms time for warm up 3: 2606 ms time for warm up 4: 2651 ms time for sun.nio.cs.UTF_8_new$Decoder: 388 1822 1210 1368 912 1775 ms time for sun.nio.cs.UTF_8_60$Decoder: 738 733 2558 1988 2203 1035 ms time for sun.nio.cs.UTF_8_last$Decoder: 421 685 2154 1967 1731 844 ms time for sun.nio.cs.UTF_8_70$Decoder: 289 781 2364 1444 2010 947 ms last warm up ./. test loops: 1.9654278 Hope that helps. -- Christian From John.Rose at Sun.COM Thu Feb 5 00:24:16 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 05 Feb 2009 00:24:16 -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: 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). Although it is not JVM code, I have posted FYI a draft of the Java code which works on top of the JVM changes here: http://webrev.invokedynamic.info/jrose/6655638.jdk/ (as a webrev) http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth.patch (original in the mlvm patch repo) For convenient browsing and review, javadoc extracted from those Java sources is here: http://webrev.invokedynamic.info/jrose/6655638.meth.jdoc/ This API is not yet official. Comments would be welcome! -- John From thomas.rodriguez at sun.com Thu Feb 5 01:40:23 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 05 Feb 2009 09:40:23 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6442502: assert(bits, "Use TypePtr for NULL") on linux-x86 Message-ID: <20090205094026.91A3512B60@hg.openjdk.java.net> Changeset: 1b9fc6e3171b Author: never Date: 2009-02-04 23:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1b9fc6e3171b 6442502: assert(bits,"Use TypePtr for NULL") on linux-x86 Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp From Ulf.Zibis at gmx.de Thu Feb 5 03:30:32 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 05 Feb 2009 12:30:32 +0100 Subject: Strange speed dependency; help needed for benchmark, please In-Reply-To: <1233820553.1536.28.camel@localhost.localdomain> References: <49877528.3000105@gmx.de> <4989F193.1020807@gmx.de> <1233820553.1536.28.camel@localhost.localdomain> Message-ID: <498ACDD8.7070403@gmx.de> Am 05.02.2009 08:55, Christian Thalinger schrieb: > On Wed, 2009-02-04 at 20:50 +0100, Ulf Zibis wrote: > >> Hi, >> >> I experience very much different mutually contradictory times running my >> UTF-8 benchmark >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/UTF_8Benchmark.java?diff_format=s&rev=620&view=markup >> for only 1 code unit pattern _against_ running for all code unit patterns: >> >> selected pattern 4 >> time for sun.nio.cs.UTF_8_60$Decoder: 2851 ms >> time for sun.nio.cs.UTF_8_70$Decoder: 2501 ms >> time for sun.nio.cs.UTF_8_last$Decoder: 2310 ms >> time for sun.nio.cs.UTF_8_new$Decoder: 2048 ms >> > > This is solaris-amd64: > > $ gamma -Xbootclasspath/a:. sun/nio/cs/UTF_8Benchmark > time for warm up 1: 2455 ms > time for warm up 2: 1150 ms > time for warm up 3: 1151 ms > time for warm up 4: 1180 ms > time for sun.nio.cs.UTF_8_60$Decoder: 1553 ms > time for sun.nio.cs.UTF_8_70$Decoder: 836 ms > time for sun.nio.cs.UTF_8_last$Decoder: 746 ms > time for sun.nio.cs.UTF_8_new$Decoder: 943 ms > last warm up ./. test loops: 1.1573023 > > >> selected all patterns (SRC_BUF = -1) >> time for sun.nio.cs.UTF_8_60$Decoder: 4951 4925 5351 4531 5269 4686 ms >> time for sun.nio.cs.UTF_8_70$Decoder: 476 3066 4815 3921 4907 3369 ms >> time for sun.nio.cs.UTF_8_last$Decoder: 560 3237 4539 4575 4772 3334 ms >> time for sun.nio.cs.UTF_8_new$Decoder: 531 3642 4741 4462 5497 3742 ms >> > > $ gamma -Xbootclasspath/a:. sun/nio/cs/UTF_8Benchmark > time for warm up 1: 3942 ms > time for warm up 2: 2394 ms > time for warm up 3: 2409 ms > time for warm up 4: 2388 ms > time for sun.nio.cs.UTF_8_60$Decoder: 859 854 2134 1694 2049 1044 ms > time for sun.nio.cs.UTF_8_70$Decoder: 290 781 1933 1448 2010 900 ms > time for sun.nio.cs.UTF_8_last$Decoder: 414 681 1462 1452 1524 765 ms > time for sun.nio.cs.UTF_8_new$Decoder: 396 686 2291 1500 1760 876 ms > last warm up ./. test loops: 1.9226139 > > >> Also I experience significant differences, when I change the >> chronological order of the tested decoders, see line 29... : >> int dec = 0; // change process order of decoders for different >> results: >> decoders[dec++] = new UTF_8_60().newDecoder(); >> decoders[dec++] = new UTF_8_70().newDecoder(); >> decoders[dec++] = new UTF_8_last().newDecoder(); >> decoders[dec++] = new UTF_8_new().newDecoder(); >> > > $ gamma -Xbootclasspath/a:. sun/nio/cs/UTF_8Benchmark > time for warm up 1: 2569 ms > time for warm up 2: 1140 ms > time for warm up 3: 1143 ms > time for warm up 4: 1176 ms > time for sun.nio.cs.UTF_8_new$Decoder: 745 ms > time for sun.nio.cs.UTF_8_60$Decoder: 1536 ms > time for sun.nio.cs.UTF_8_last$Decoder: 1001 ms > time for sun.nio.cs.UTF_8_70$Decoder: 747 ms > last warm up ./. test loops: 1.166911 > > $ gamma -Xbootclasspath/a:. sun/nio/cs/UTF_8Benchmark > time for warm up 1: 4145 ms > time for warm up 2: 2598 ms > time for warm up 3: 2606 ms > time for warm up 4: 2651 ms > time for sun.nio.cs.UTF_8_new$Decoder: 388 1822 1210 1368 912 1775 ms > time for sun.nio.cs.UTF_8_60$Decoder: 738 733 2558 1988 2203 1035 ms > time for sun.nio.cs.UTF_8_last$Decoder: 421 685 2154 1967 1731 844 ms > time for sun.nio.cs.UTF_8_70$Decoder: 289 781 2364 1444 2010 947 ms > last warm up ./. test loops: 1.9654278 > > Hope that helps. > > -- Christian > > Yes, that helps. Very much thanks, Christian. First I can see, that your machine also is becoming slower, if running all 6 patterns (compare warmup times), but I wonder, that test loops become 1.9 faster later. Cold you set WARMUP_LOOPS = 16 once, to see, if there is a 2nd acceleration later from HotSpot compiler? There are 3 factors, that have significant influence on the benchmark relative times: 1.) amount of different source patterns in test: e.g.: in case of only testing pattern 4, UTF_8_70$Decoder is twice faster then UTF_8_60$Decoder, but not in case of testing all 6 patterns: 836 ./. 1553 ms vs. 2010 ./. 2049 ms 2.) chronological order of the tested decoders: e.g.: if UTF_8_new$Decoder is in last position, it's much slower than UTF_8_last$Decoder, but vice versa, if in 1st position: 943 ./. 746 ms vs. 745 ./. 1001 ms 3.) type of CPU, machine and OS: e.g.: ASCII only loop is 10 times faster on [Intel Pentium M, Centrino, Windows], but only 2 on [amd64, ?, Solaris], other benchmark times, e.g. on pattern 4, differ up to factor 2. ... so it is very difficult to check out, which of my 4 alternatives (+ XOR ./. ADD in uc calculation; + order of uc calculation ./. overflow check) in UTF_8_new$Decoder is the best for real world case, because they also behave completely different against the 3 factors mentioned above. ... plus not to forget, that in real world case a single byte sequence will only be decoded once, so it won't reside in L1 or L2 CPU cache, and additionally it's length would be much shorter (1..50 in most cases, entire texts should be rare against single words and short phrases). Do you have any idea, how to come closer to best choice ??? Thanks in advance, -Ulf From Christian.Thalinger at Sun.COM Thu Feb 5 04:44:29 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 05 Feb 2009 13:44:29 +0100 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: <1233837869.1536.183.camel@localhost.localdomain> On Tue, 2009-01-20 at 02:53 -0800, John Rose wrote: > Please give it a look. I'm trying to understand it but it's really huge. src/share/vm/runtime/globals.hpp: + product(bool, MethodHandleSupport, false, \ + "support method handles (true by default under JSR 292") \ There's a missing ) before the closing ". src/share/vm/runtime/sharedRuntime.hpp: ! static char* generate_class_cast_message(const char* name, const char* klass); ! static char* generate_class_cast_message(const char* name, const char* klass, + const char* gripe = " cannot be cast to "); name and klass have a @param comment but gripe does not. src/cpu/sparc/vm/methodHandles_sparc.cpp (I know SPARC does not work yet): 75 // fetch the MethodType from the method handle into G5_method_type 76 { 77 Register tem = G5_method; 78 for (int* pchase = methodOopDesc::method_type_pointer_chase(); (*pchase) != -1; pchase++) { 79 __ ld_ptr(tem, *pchase, G5_method_type); 80 tem = G5_method_type; // yes, it's the same register... 81 } 82 } What size can *pchase be? Is it possibly too large for ld_ptr? 116 // - rax: method handle type (already checked at call site, then unused) 117 // - rsi: sender SP (must preserve) 118 // - rdx: garbage temp, can blow away Wrong register names. I'm not finished yet, will continue later... -- Christian From Vladimir.Kozlov at Sun.COM Thu Feb 5 10:38:40 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 05 Feb 2009 10:38:40 -0800 Subject: Request for reviews (S): 6799693: Server compiler leads to data corruption when expression throws an Exception Message-ID: <498B3230.4000101@sun.com> http://webrev.invokedynamic.info/kvn/6799693/index.html Fixed 6799693: Server compiler leads to data corruption when expression throws an Exception Problem: Both 6799693 and 6795161 bugs has the same cause. A store can flow below the call on the slow path of an allocation since an allocation consumes only raw memory slice. As result when exception happened during the allocation call the value of store's memory slice is incorrect. Solution: Use merged memory state for an allocation's slow path and raw memory for the fast path. Reviewed by: Fix verified (y/n): y, bugs test cases Other testing: JPRT From Vladimir.Kozlov at Sun.COM Thu Feb 5 11:41:20 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 05 Feb 2009 11:41:20 -0800 Subject: Request for reviews (S): 6788376: allow to ignore unrecognized VM options Message-ID: <498B40E0.1010202@sun.com> It was finally approved by CCC so I'm resending it before the push. http://webrev.invokedynamic.info/kvn/6788376/index.html Fixed 6788376: allow to ignore unrecognized VM options Problem: Hotspot has flags which could be unavailable in different VM versions (server vs client, product vs debug). It complicates VM testing. Solution: Add new product flag -XX:+IgnoreUnrecognizedVMOptions to allow ignore unrecognized VM options and execute a java program. By default it is off. Add the flag to the test compiler/6775880/Test.java to run it with product VM (DeoptimizeALot flag is the debug flag unavailable in product VM). Reviewed by: ysr, xlu Fix verified (y/n): y Other testing: JPRT From Thomas.Rodriguez at Sun.COM Thu Feb 5 12:27:04 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 05 Feb 2009 12:27:04 -0800 Subject: Request for reviews (S): 6799693: Server compiler leads to data corruption when expression throws an Exception In-Reply-To: <498B3230.4000101@sun.com> References: <498B3230.4000101@sun.com> Message-ID: <2519DCD9-2D17-4C0D-AD9F-BB55045E6816@sun.com> I think this looks good. I'm not sure why we bother trying to use the raw memory in the slow path though. It doesn't improve anything about the code generation. I'm fine with keeping it as you've changed it. tom On Feb 5, 2009, at 10:38 AM, Vladimir Kozlov wrote: > > http://webrev.invokedynamic.info/kvn/6799693/index.html > > Fixed 6799693: Server compiler leads to data corruption when > expression throws an Exception > > Problem: > Both 6799693 and 6795161 bugs has the same cause. > A store can flow below the call on the slow path of an allocation > since an allocation consumes only raw memory slice. > As result when exception happened during the allocation call > the value of store's memory slice is incorrect. > > Solution: > Use merged memory state for an allocation's slow path > and raw memory for the fast path. > > Reviewed by: > > Fix verified (y/n): y, bugs test cases > > Other testing: > JPRT > From vladimir.kozlov at sun.com Thu Feb 5 16:32:45 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 06 Feb 2009 00:32:45 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6788376: allow to ignore unrecognized VM options Message-ID: <20090206003248.3021012C2A@hg.openjdk.java.net> Changeset: 323728917cf4 Author: kvn Date: 2009-02-05 13:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/323728917cf4 6788376: allow to ignore unrecognized VM options Summary: Add new product flag -XX:+IgnoreUnrecognizedVMOptions Reviewed-by: ysr, xlu ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! test/compiler/6775880/Test.java From vladimir.kozlov at sun.com Thu Feb 5 18:54:09 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 06 Feb 2009 02:54:09 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6799693: Server compiler leads to data corruption when expression throws an Exception Message-ID: <20090206025411.ABB0F12C67@hg.openjdk.java.net> Changeset: 7fe62bb75bf4 Author: kvn Date: 2009-02-05 14:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7fe62bb75bf4 6799693: Server compiler leads to data corruption when expression throws an Exception Summary: Use merged memory state for an allocation's slow path. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp + test/compiler/6795161/Test.java + test/compiler/6799693/Test.java From Christian.Thalinger at Sun.COM Fri Feb 6 04:08:15 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 06 Feb 2009 13:08:15 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1232561508.10525.194.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> <1232116144.1361.93.camel@localhost.localdomain> <1232485964.453.5.camel@localhost.localdomain> <1232561508.10525.194.camel@localhost.localdomain> Message-ID: <1233922095.1536.264.camel@localhost.localdomain> On Wed, 2009-01-21 at 19:11 +0100, Christian Thalinger wrote: > You were absolutely right. Simply summing up the bytes as unsigned > values is 22% faster. > > I hope I can try it on a SPARC box soon. I got a bit side-tracked but I'm still on it. Unfortunately my quota in sfbay exceeded and I can't provide more test results, but at least I've implemented unsigned load instructions on SPARC and ran the DecoderBenchmark (btw. the builds are debug builds, but it shouldn't make any difference): $ gamma DecoderBenchmark time for warm up 1: 30589 ms time for warm up 2: 28152 ms time for warm up 3: 28127 ms time for warm up 4: 28127 ms time for map[a & 0xFF]: 28083 ms time for map[a + 0x80]: 28084 ms time for inlined map[a & 0xFF]: 28082 ms time for inlined map[a + 0x80]: 28082 ms test loops ./. last warm up: 0.9984195 So, yes, the +0x80 trick is now superfluous. Now let's see what the numbers are on x86 (solaris-amd64): $ gamma DecoderBenchmark time for warm up 1: 1790 ms time for warm up 2: 1509 ms time for warm up 3: 1431 ms time for warm up 4: 1441 ms time for map[a & 0xFF]: 1732 ms time for map[a + 0x80]: 1439 ms time for inlined map[a & 0xFF]: 1733 ms time for inlined map[a + 0x80]: 1431 ms test loops ./. last warm up: 1.0987756 The generated code is almost the same for both methods: & 0xFF: 0a0 B5: # B5 B6 <- B4 B5 Loop: B5-B5 inner stride: not constant main of N16 Freq: 4.27176e+09 0a0 movslq RAX, R9 # i2l 0a3 movq R10, R11 # spill 0a6 addq R10, RAX # ptr 0a9 movzbl R14, [R10 + #31 (8-bit)] # ubyte 0ae movzbl R13, [R10 + #30 (8-bit)] # ubyte 0b3 movzbl RBX, [R10 + #29 (8-bit)] # ubyte 0b8 movzbl RDI, [R10 + #28 (8-bit)] # ubyte 0bd movzbl RSI, [R10 + #27 (8-bit)] # ubyte 0c2 movzbl RDX, [R10 + #26 (8-bit)] # ubyte 0c7 movzbl RBP, [R10 + #25 (8-bit)] # ubyte 0cc movzbl R10, [R10 + #24 (8-bit)] # ubyte 0d1 movzwl R10, [RCX + #24 + R10 << #1] # ushort/char 0d7 movw [R8 + #24 + RAX << #1], R10 # char/short 0dd movzwl R10, [RCX + #24 + RBP << #1] # ushort/char 0e3 movw [R8 + #26 + RAX << #1], R10 # char/short 0e9 movzwl RDX, [RCX + #24 + RDX << #1] # ushort/char 0ee movw [R8 + #28 + RAX << #1], RDX # char/short 0f4 movzwl RSI, [RCX + #24 + RSI << #1] # ushort/char 0f9 movw [R8 + #30 + RAX << #1], RSI # char/short 0ff movzwl RDI, [RCX + #24 + RDI << #1] # ushort/char 104 movw [R8 + #32 + RAX << #1], RDI # char/short 10a movzwl RBX, [RCX + #24 + RBX << #1] # ushort/char 10f movw [R8 + #34 + RAX << #1], RBX # char/short 115 movzwl RBX, [RCX + #24 + R13 << #1] # ushort/char 11b movw [R8 + #36 + RAX << #1], RBX # char/short 121 movzwl RBX, [RCX + #24 + R14 << #1] # ushort/char 127 movw [R8 + #38 + RAX << #1], RBX # char/short 12d addl R9, #8 # int 131 cmpl R9, #16377 138 jl B5 # loop end P=0.999943 C=1740800.000000 So I'd say this is more or less optimal code. + 0x80: 1d0 B12: # B12 B13 <- B11 B12 Loop: B12-B12 inner stride: not constant main of N173 Freq: 4.10656e+09 1d0 movslq RBX, R10 # i2l 1d3 movsbq RDI, [R11 + #24 + RBX] # byte -> long 1d9 movsbq RDX, [R11 + #31 + RBX] # byte -> long 1df movzwl RDI, [RCX + #280 + RDI << #1] # ushort/char 1e7 movw [R8 + #24 + RBX << #1], RDI # char/short 1ed movsbq RAX, [R11 + #30 + RBX] # byte -> long 1f3 movsbq RBP, [R11 + #29 + RBX] # byte -> long 1f9 movsbq R13, [R11 + #28 + RBX] # byte -> long 1ff movsbq R14, [R11 + #27 + RBX] # byte -> long 205 movsbq RSI, [R11 + #26 + RBX] # byte -> long 20b movsbq RDI, [R11 + #25 + RBX] # byte -> long 211 movzwl RDI, [RCX + #280 + RDI << #1] # ushort/char 219 movw [R8 + #26 + RBX << #1], RDI # char/short 21f movzwl RSI, [RCX + #280 + RSI << #1] # ushort/char 227 movw [R8 + #28 + RBX << #1], RSI # char/short 22d movzwl RDI, [RCX + #280 + R14 << #1] # ushort/char 236 movw [R8 + #30 + RBX << #1], RDI # char/short 23c movzwl RSI, [RCX + #280 + R13 << #1] # ushort/char 245 movw [R8 + #32 + RBX << #1], RSI # char/short 24b movzwl RDI, [RCX + #280 + RBP << #1] # ushort/char 253 movw [R8 + #34 + RBX << #1], RDI # char/short 259 movzwl RSI, [RCX + #280 + RAX << #1] # ushort/char 261 movw [R8 + #36 + RBX << #1], RSI # char/short 267 movzwl RDX, [RCX + #280 + RDX << #1] # ushort/char 26f movw [R8 + #38 + RBX << #1], RDX # char/short 275 addl R10, #8 # int 279 cmpl R10, #16377 280 jl B12 # loop end P=0.999940 C=1445888.000000 It's slightly better code and that's probably why it's faster. But instruction-selection wise it's optimal code in both cases. I just wonder why there is a I2L conversion in the first listing even the loop variable in both listings is an integer register. Also interesting is the fact that in the first listing the unsigned byte values are loaded with a normal register loads: 0xfffffd7ffa306d89: movzbl 0x1f(%r10),%r14d 0xfffffd7ffa306d8e: movzbl 0x1e(%r10),%r13d 0xfffffd7ffa306d93: movzbl 0x1d(%r10),%ebx 0xfffffd7ffa306d98: movzbl 0x1c(%r10),%edi 0xfffffd7ffa306d9d: movzbl 0x1b(%r10),%esi 0xfffffd7ffa306da2: movzbl 0x1a(%r10),%edx 0xfffffd7ffa306da7: movzbl 0x19(%r10),%ebp 0xfffffd7ffa306dac: movzbl 0x18(%r10),%r10d but in the second (faster) listing the loads are indexed loads: 0xfffffd7ffa306ecd: movsbq 0x1e(%r11,%rbx,1),%rax 0xfffffd7ffa306ed3: movsbq 0x1d(%r11,%rbx,1),%rbp 0xfffffd7ffa306ed9: movsbq 0x1c(%r11,%rbx,1),%r13 0xfffffd7ffa306edf: movsbq 0x1b(%r11,%rbx,1),%r14 0xfffffd7ffa306ee5: movsbq 0x1a(%r11,%rbx,1),%rsi 0xfffffd7ffa306eeb: movsbq 0x19(%r11,%rbx,1),%rdi Register allocation? -- Christian From Changpeng.Fang at Sun.COM Fri Feb 6 08:52:48 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Fri, 06 Feb 2009 08:52:48 -0800 Subject: Request for reviews (L): 6761600: Use SSE 4.2 In STTNI Intrinsics In-Reply-To: <496FD74F.9070009@sun.com> References: <496FD74F.9070009@sun.com> Message-ID: <498C6AE0.4010006@Sun.COM> http://webrev.invokedynamic.info/cfang/6761600/index.html Works on 6761600 : Use SSE 4.2 in intrinsics for String.compareTo(), String.equals(), String.indexOf() and Arrays.equals(), among which, String.equals() and String.indexOf() are intrinsified for the first time. Problem: Use SSE 4.2 instructions for STTNI intrinsics for for Nehalem improvements Solution: Implemented both 32 and 64-bit versions for X86. Introduced a new flag UseSSE42Intrinsics, with the default TRUE on systems that support SSE4.2 (false otherwise). Reviewed by: Fix verified (y/n): y Other testing: JPRT, From Vladimir.Kozlov at Sun.COM Fri Feb 6 10:22:24 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 06 Feb 2009 10:22:24 -0800 Subject: Request for reviews (L): 6761600: Use SSE 4.2 In STTNI Intrinsics In-Reply-To: <498C6AE0.4010006@Sun.COM> References: <496FD74F.9070009@sun.com> <498C6AE0.4010006@Sun.COM> Message-ID: <498C7FE0.5020200@sun.com> Changpeng, Good work. src/cpu/x86/vm/assembler_x86.cpp: Remove Macro NOT_LP64() around asserts in new instructions. VM_Version::supports_sse4_2() should be checked on LP64 also since not all 64-bits CPUs support it. src/cpu/x86/vm/vm_version_x86_32.cpp: src/cpu/x86/vm/vm_version_x86_64.cpp: Remove UseUnalignedLoadStores check in the next code, it is not needed and it is wrong to have it since it depends on UseXMMForArrayCopy flag. The top check supports_sse4_2() && supports_ht() is enough for movdqu verification. + if(FLAG_IS_DEFAULT(UseSSE42Intrinsics) && + UseUnalignedLoadStores){ //sse42 intrinsics depend on movdqu + UseSSE42Intrinsics = true; } In both x86_32.ad and x86_64.ad try to use short forward branches masm.jccb() starting from the bottom of the assembler code. Then try to use all intrinsics with all flags variations and revert back to long jump those branches VM will complain about. cpu/x86/vm/x86_32.ad: align comments: ! masm.andl(rsi, 0xfffffff8); // rsi holds the vector count ! masm.andl(rdi, 0x00000007); // rdi holds the tail count In enc_String_Equals() and enc_String_IndexOf() use movptr() for value_offset. src/share/vm/adlc/formssel.cpp: Missing checks for AryEq. src/share/vm/classfile/vmSymbols.hpp: Remove empty after indexOf_name since equals() also j.l.String method: do_name( indexOf_name, "indexOf") + do_intrinsic(_equals, java_lang_String, equals_name, object_boolean_signature, F_R) src/share/vm/opto/library_call.cpp: Add that it because spec allow to specify NULL as argument: + //should not do null check for argument for string_equals. Remove next line + //argument = do_null_check(argument, T_OBJECT); Thanks, Vladimir Changpeng Fang wrote: > http://webrev.invokedynamic.info/cfang/6761600/index.html > > Works on 6761600 : Use SSE 4.2 in intrinsics for String.compareTo(), > String.equals(), String.indexOf() and Arrays.equals(), among which, > String.equals() and String.indexOf() are intrinsified for the first time. > > Problem: Use SSE 4.2 instructions for STTNI intrinsics for for Nehalem > improvements > > Solution: > Implemented both 32 and 64-bit versions for X86. Introduced a new > flag UseSSE42Intrinsics, with the default TRUE on systems that support > SSE4.2 (false otherwise). > > Reviewed by: > > Fix verified (y/n): y > > Other testing: JPRT, > > From Vladimir.Kozlov at Sun.COM Fri Feb 6 10:35:11 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 06 Feb 2009 10:35:11 -0800 Subject: Request for reviews (S): 6791852: assert(b->_nodes[insidx] == n,"got insidx set incorrectly") Message-ID: <498C82DF.8060409@sun.com> http://cr.openjdk.java.net/~kvn/6791852/webrev.00 Fixed 6791852: assert(b->_nodes[insidx] == n,"got insidx set incorrectly") Problem: The code in PhaseChaitin::Split() in the part "Handle Crossing HRP Boundry" expects that a new MachSpillCopy node is inserted before the current node. After 6782232 fix it is not true if the current node is CreateEx. Solution: Remove the original fix for 6782232 in PhaseChaitin::insert_proj(). Move the CreateEx up before each round of IFG construction to produce correct interference graph. Move verification checks in chaitin after IFG construction. Add additional check into PhaseCFG::verify(). Fix check in PhaseChaitin::verify_base_ptrs(). Reviewed by: Fix verified (y/n): y, bug's test case Other testing: JPRT, CTW (with -XX:+VerifyRegisterAllocator) From Paul.Hohensee at Sun.COM Fri Feb 6 11:03:17 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 06 Feb 2009 14:03:17 -0500 Subject: Request for reviews (S): 6791852: assert(b->_nodes[insidx] == n,"got insidx set incorrectly") In-Reply-To: <498C82DF.8060409@sun.com> References: <498C82DF.8060409@sun.com> Message-ID: <498C8975.30308@sun.com> I'd put #ifdef ASSERT around all the code in block.cpp to make sure the compiler elides it for product and optimized vms. The verification code in chaitin.cpp seems pretty similar in a lot of places. Any way to factor it? You might change the code in live.cpp from if (!check->is_Proj() && !(check->is_Mach() ... )) to if (check->is_Proj() || (check->is_Mach() ... )) I.e., prefer positive rather than negative (use of '!') tests. Easier on the brain. :) Paul Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6791852/webrev.00 > > Fixed 6791852: assert(b->_nodes[insidx] == n,"got insidx set > incorrectly") > > Problem: > The code in PhaseChaitin::Split() in the part "Handle Crossing HRP > Boundry" > expects that a new MachSpillCopy node is inserted before the current > node. > After 6782232 fix it is not true if the current node is CreateEx. > > Solution: > Remove the original fix for 6782232 in PhaseChaitin::insert_proj(). > Move the CreateEx up before each round of IFG construction to produce > correct interference graph. > Move verification checks in chaitin after IFG construction. > Add additional check into PhaseCFG::verify(). > Fix check in PhaseChaitin::verify_base_ptrs(). > > Reviewed by: > > Fix verified (y/n): y, bug's test case > > Other testing: > JPRT, CTW (with -XX:+VerifyRegisterAllocator) > From Thomas.Rodriguez at Sun.COM Fri Feb 6 11:31:56 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 06 Feb 2009 11:31:56 -0800 Subject: Request for reviews (S): 6791852: assert(b->_nodes[insidx] == n,"got insidx set incorrectly") In-Reply-To: <498C82DF.8060409@sun.com> References: <498C82DF.8060409@sun.com> Message-ID: ifg.cpp: I think I would have preferred if this were simply done as part of the backwards walk during ifg construction, so that there's no extra work. This adds an extra pass over every block that almost never does anything. I guess it's more clear this way. The loop bounds are a little strange. I think it should either be + for( uint insidx = last_phi + 1; insidx < last_inst; insidx++ ) { + Node *ex = b->_nodes[insidx]; + if( ex->is_Mach() && + ex->as_Mach()->ideal_Opcode() == Op_CreateEx ) { + b->_nodes.remove(insidx); + b->_nodes.insert(last_phi, ex); + break; + } + } or + for( uint insidx = last_phi; insidx < last_inst; insidx++ ) { + Node *ex = b->_nodes[insidx]; + if (ex->is_Mach() && + ex->as_Mach()->ideal_Opcode() == Op_CreateEx ) { + if( insidx > last_phi) { + b->_nodes.remove(insidx); + b->_nodes.insert(last_phi, ex); + } + break; + } + } Actually what about this: for( uint insidx = last_phi; insidx < last_inst; insidx++ ) { Node *ex = b->_nodes[insidx]; if (ex->is_SpillCopy()) continue; if (insidx > last_phi && ex->is_Mach() && ex->as_Mach()->ideal_Opcode() == Op_CreateEx) { // If the CreateEx isn't above all the MachSpillCopies // then move it to the top b->_nodes.remove(insidx); b->_nodes.insert(last_phi, ex); } // Stop once a CreateEx or any other node is found break; } This way we only scan as much as needed. Can you correct the name of last_phi? It's described as the index of that last_phi but it's actually the index of the first node after the phis. Maybe first_inst instead? Otherwise it looks good. tom On Feb 6, 2009, at 10:35 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6791852/webrev.00 > > Fixed 6791852: assert(b->_nodes[insidx] == n,"got insidx set > incorrectly") > > Problem: > The code in PhaseChaitin::Split() in the part "Handle Crossing HRP > Boundry" > expects that a new MachSpillCopy node is inserted before the current > node. > After 6782232 fix it is not true if the current node is CreateEx. > > Solution: > Remove the original fix for 6782232 in PhaseChaitin::insert_proj(). > Move the CreateEx up before each round of IFG construction to produce > correct interference graph. > Move verification checks in chaitin after IFG construction. > Add additional check into PhaseCFG::verify(). > Fix check in PhaseChaitin::verify_base_ptrs(). > > Reviewed by: > > Fix verified (y/n): y, bug's test case > > Other testing: > JPRT, CTW (with -XX:+VerifyRegisterAllocator) > From Vladimir.Kozlov at Sun.COM Fri Feb 6 11:37:35 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 06 Feb 2009 11:37:35 -0800 Subject: Request for reviews (S): 6791852: assert(b->_nodes[insidx] == n,"got insidx set incorrectly") In-Reply-To: References: <498C82DF.8060409@sun.com> Message-ID: <498C917F.5020104@sun.com> Thanks, Tom I will use the last one with is_SpillCopy() check. and I will rename the variable. Thanks, Vladimir Tom Rodriguez wrote: > ifg.cpp: > > I think I would have preferred if this were simply done as part of the > backwards walk during ifg construction, so that there's no extra work. > This adds an extra pass over every block that almost never does > anything. I guess it's more clear this way. > > The loop bounds are a little strange. I think it should either be > > + for( uint insidx = last_phi + 1; insidx < last_inst; insidx++ ) { > + Node *ex = b->_nodes[insidx]; > + if( ex->is_Mach() && > + ex->as_Mach()->ideal_Opcode() == Op_CreateEx ) { > + b->_nodes.remove(insidx); > + b->_nodes.insert(last_phi, ex); > + break; > + } > + } > > or > > + for( uint insidx = last_phi; insidx < last_inst; insidx++ ) { > + Node *ex = b->_nodes[insidx]; > + if (ex->is_Mach() && > + ex->as_Mach()->ideal_Opcode() == Op_CreateEx ) { > + if( insidx > last_phi) { > + b->_nodes.remove(insidx); > + b->_nodes.insert(last_phi, ex); > + } > + break; > + } > + } > > Actually what about this: > > for( uint insidx = last_phi; insidx < last_inst; insidx++ ) { > Node *ex = b->_nodes[insidx]; > if (ex->is_SpillCopy()) continue; > if (insidx > last_phi && ex->is_Mach() && > ex->as_Mach()->ideal_Opcode() == Op_CreateEx) { > // If the CreateEx isn't above all the MachSpillCopies > // then move it to the top > b->_nodes.remove(insidx); > b->_nodes.insert(last_phi, ex); > } > // Stop once a CreateEx or any other node is found > break; > } > > This way we only scan as much as needed. > > Can you correct the name of last_phi? It's described as the index of > that last_phi but it's actually the index of the first node after the > phis. Maybe first_inst instead? > > Otherwise it looks good. > > tom > > On Feb 6, 2009, at 10:35 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6791852/webrev.00 >> >> Fixed 6791852: assert(b->_nodes[insidx] == n,"got insidx set >> incorrectly") >> >> Problem: >> The code in PhaseChaitin::Split() in the part "Handle Crossing HRP >> Boundry" >> expects that a new MachSpillCopy node is inserted before the current >> node. >> After 6782232 fix it is not true if the current node is CreateEx. >> >> Solution: >> Remove the original fix for 6782232 in PhaseChaitin::insert_proj(). >> Move the CreateEx up before each round of IFG construction to produce >> correct interference graph. >> Move verification checks in chaitin after IFG construction. >> Add additional check into PhaseCFG::verify(). >> Fix check in PhaseChaitin::verify_base_ptrs(). >> >> Reviewed by: >> >> Fix verified (y/n): y, bug's test case >> >> Other testing: >> JPRT, CTW (with -XX:+VerifyRegisterAllocator) >> > From john.coomes at sun.com Fri Feb 6 11:43:09 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Feb 2009 19:43:09 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b46 for changeset e8a2a4d18777 Message-ID: <20090206194309.57CD0D027@hg.openjdk.java.net> Changeset: d7744e86dedc Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/d7744e86dedc Added tag jdk7-b46 for changeset e8a2a4d18777 ! .hgtags From john.coomes at sun.com Fri Feb 6 11:46:08 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Feb 2009 19:46:08 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b46 for changeset 1691dbfc08f8 Message-ID: <20090206194609.ECC5BD033@hg.openjdk.java.net> Changeset: 167ad0164301 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/167ad0164301 Added tag jdk7-b46 for changeset 1691dbfc08f8 ! .hgtags From John.Rose at Sun.COM Thu Feb 5 21:15:42 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 05 Feb 2009 21:15:42 -0800 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: <1233837869.1536.183.camel@localhost.localdomain> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <1233837869.1536.183.camel@localhost.localdomain> Message-ID: <0EF34FD6-6689-4653-883B-065AE4B3C43D@Sun.COM> On Feb 5, 2009, at 4:44 AM, Christian Thalinger wrote: > src/share/vm/runtime/globals.hpp: > > + product(bool, MethodHandleSupport, > false, \ > + "support method handles (true by default under JSR > 292") \ > > There's a missing ) before the closing ". Thanks; fixed. > src/share/vm/runtime/sharedRuntime.hpp: > > ! static char* generate_class_cast_message(const char* name, const > char* klass); > ! static char* generate_class_cast_message(const char* name, const > char* klass, > + const char* gripe = " > cannot be cast to "); > > name and klass have a @param comment but gripe does not. Fixed. > src/cpu/sparc/vm/methodHandles_sparc.cpp (I know SPARC does not work > yet): > > 75 // fetch the MethodType from the method handle into > G5_method_type > 76 { > 77 Register tem = G5_method; > 78 for (int* pchase = > methodOopDesc::method_type_pointer_chase(); (*pchase) != -1; pchase+ > +) { > 79 __ ld_ptr(tem, *pchase, G5_method_type); > 80 tem = G5_method_type; // yes, it's the same > register... > 81 } > 82 } > > What size can *pchase be? Is it possibly too large for ld_ptr? It's a small offset (part of a pointer-chase). We can portably assume it is suitable as a pointer displacement, and is never larger than offset_t. We use ints like that countless places in hotspot, so I don't think a comment is needed here. However, I changed it to a jint; that will make it more definite. > 116 // - rax: method handle type (already checked at call site, then > unused) > 117 // - rsi: sender SP (must preserve) > 118 // - rdx: garbage temp, can blow away > > Wrong register names. Heh; thanks. > I'm not finished yet, will continue later... Thanks! Even if you find something after the stuff is committed, I'll be very happy to fix it. -- John From john.coomes at sun.com Fri Feb 6 11:50:49 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Feb 2009 19:50:49 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b46 for changeset b2271877894a Message-ID: <20090206195051.90EEAD038@hg.openjdk.java.net> Changeset: d711ad1954b2 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/d711ad1954b2 Added tag jdk7-b46 for changeset b2271877894a ! .hgtags From john.coomes at sun.com Fri Feb 6 11:53:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Feb 2009 19:53:21 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b46 for changeset af4a3eeb7812 Message-ID: <20090206195323.B4A32D03D@hg.openjdk.java.net> Changeset: 223011570edb Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/223011570edb Added tag jdk7-b46 for changeset af4a3eeb7812 ! .hgtags From John.Rose at Sun.COM Fri Feb 6 12:00:51 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 06 Feb 2009 12:00:51 -0800 Subject: Request for reviews (L): 6761600: Use SSE 4.2 In STTNI Intrinsics In-Reply-To: <498C7FE0.5020200@sun.com> References: <496FD74F.9070009@sun.com> <498C6AE0.4010006@Sun.COM> <498C7FE0.5020200@sun.com> Message-ID: On Feb 6, 2009, at 10:22 AM, Vladimir Kozlov wrote: > src/share/vm/classfile/vmSymbols.hpp: > Remove empty after indexOf_name since equals() also j.l.String method: > do_name( indexOf_name, "indexOf") > > + do_intrinsic(_equals, java_lang_String, equals_name, > object_boolean_signature, F_R) It's a minor point, but since indexOf_name and equals_name are shared by more than one instrinsic, they could be grouped with other shared names, like invoke_name and get_name. Look for the string "defined above" in the header file for more info. -- John From john.coomes at sun.com Fri Feb 6 11:57:47 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Feb 2009 19:57:47 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 40 new changesets Message-ID: <20090206200549.3C2F4D042@hg.openjdk.java.net> Changeset: 13d7e2477737 Author: sherman Date: 2009-01-13 09:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/13d7e2477737 6332094: "jar t" and "jar x" should use ZipFile, not ZipInputStream Summary: To use ZipFile for jar "t" and "x" to boost performance Reviewed-by: martin, alanb ! src/share/classes/sun/tools/jar/Main.java Changeset: 8c1c6e11204b Author: chegar Date: 2009-01-14 17:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8c1c6e11204b 6755782: It is not clear how DatagramSocket deals with broadcast enabling/disabling Reviewed-by: jccollet ! src/share/classes/java/net/DatagramSocket.java Changeset: 7f6969c09075 Author: darcy Date: 2009-01-14 16:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7f6969c09075 6792545: Typo in java.util.Collection JavaDoc 6655123: Incorrect ref to The Art of Computer Programming in doc for java.util.Random Summary: Fix a pair of typos. Reviewed-by: jjg ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Random.java Changeset: 9260d9bd0843 Author: weijun Date: 2009-01-19 18:49 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9260d9bd0843 6793475: krb5.ini not found on some Windows Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Config.java ! src/windows/native/sun/security/krb5/WindowsDirectory.c Changeset: 1f751a9f7052 Author: mchung Date: 2009-01-20 13:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1f751a9f7052 6793429: Use compiled properties instead of plain properties for resource file Summary: Rename the variables in Resources.gmk to make compiled properties more explicit Reviewed-by: naoto, yhuang ! make/com/sun/org/apache/xml/Makefile ! make/com/sun/rowset/Makefile ! make/common/internal/Resources.gmk ! make/sun/launcher/Makefile ! make/sun/rmi/oldtools/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmic/Makefile ! make/sun/rmi/rmid/Makefile ! make/sun/serialver/Makefile Changeset: 42f8dea1b865 Author: mchung Date: 2009-01-20 13:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/42f8dea1b865 6769976: (fc) FileChannelImpl.isAMappedBufferField not used Summary: Remove the FileChannelImpl.isAMappedBufferField field Reviewed-by: alanb ! src/share/classes/sun/nio/ch/FileChannelImpl.java Changeset: 7fa0a7a3c080 Author: mchung Date: 2009-01-20 16:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7fa0a7a3c080 Merge Changeset: 63f8707112be Author: sherman Date: 2009-01-22 20:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/63f8707112be 6476425: (fmt)java.util.Formatter.print() throws IllegalArgumentException on large BigDecima Summary: Correct the wrong calculation of "precision" in certain circumstances. Reviewed-by: darcy, alanb ! src/share/classes/java/util/Formatter.java ! test/java/util/Formatter/Basic-X.java ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicBigInteger.java ! test/java/util/Formatter/BasicBoolean.java ! test/java/util/Formatter/BasicBooleanObject.java ! test/java/util/Formatter/BasicByte.java ! test/java/util/Formatter/BasicByteObject.java ! test/java/util/Formatter/BasicChar.java ! test/java/util/Formatter/BasicCharObject.java ! test/java/util/Formatter/BasicDateTime.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java ! test/java/util/Formatter/BasicInt.java ! test/java/util/Formatter/BasicIntObject.java ! test/java/util/Formatter/BasicLong.java ! test/java/util/Formatter/BasicLongObject.java ! test/java/util/Formatter/BasicShort.java ! test/java/util/Formatter/BasicShortObject.java ! test/java/util/Formatter/genBasic.sh Changeset: cb641d17bbb3 Author: darcy Date: 2009-01-23 10:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cb641d17bbb3 6604864: Double.valueOf(String) does not specify behaviour for overflow and underflow Reviewed-by: emcmanus ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java Changeset: 175b6adf65b3 Author: tbell Date: 2009-01-24 16:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/175b6adf65b3 Merge Changeset: f3ad2ee4600b Author: darcy Date: 2009-01-26 19:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f3ad2ee4600b 6601457: Move wrapper class tests from closed to open 6601458: Move java.math tests from closed to open 6740185: Move java/lang/annotations tests to open 6759433: Move Math and StrictMath regression tests from closed to open Summary: Move some more regression tests to the open Reviewed-by: jjg + test/java/lang/Boolean/Factory.java + test/java/lang/Boolean/GetBoolean.java + test/java/lang/Boolean/MakeBooleanComparable.java + test/java/lang/Boolean/ParseBoolean.java + test/java/lang/Byte/Decode.java + test/java/lang/Double/BitwiseConversion.java + test/java/lang/Double/Constants.java + test/java/lang/Double/Extrema.java + test/java/lang/Double/NaNInfinityParsing.java + test/java/lang/Double/ParseDouble.java + test/java/lang/Double/ParseHexFloatingPoint.java + test/java/lang/Double/ToHexString.java + test/java/lang/Float/BitwiseConversion.java + test/java/lang/Float/Constants.java + test/java/lang/Float/Extrema.java + test/java/lang/Float/NaNInfinityParsing.java + test/java/lang/Float/ParseFloat.java + test/java/lang/Integer/BitTwiddle.java + test/java/lang/Integer/Decode.java + test/java/lang/Integer/GetInteger.java + test/java/lang/Integer/ParsingTest.java + test/java/lang/Long/BitTwiddle.java + test/java/lang/Long/Decode.java + test/java/lang/Long/GetLong.java + test/java/lang/Long/ParsingTest.java + test/java/lang/Math/AbsPositiveZero.java + test/java/lang/Math/Atan2Tests.java + test/java/lang/Math/CubeRootTests.java + test/java/lang/Math/Expm1Tests.java + test/java/lang/Math/HyperbolicTests.java + test/java/lang/Math/HypotTests.java + test/java/lang/Math/IeeeRecommendedTests.java + test/java/lang/Math/Log10Tests.java + test/java/lang/Math/Log1pTests.java + test/java/lang/Math/MinMax.java + test/java/lang/Math/PowTests.java + test/java/lang/Math/Rint.java + test/java/lang/Math/TanTests.java + test/java/lang/Math/Tests.java + test/java/lang/Short/ByteSwap.java + test/java/lang/Short/Decode.java + test/java/lang/StrictMath/CubeRootTests.java + test/java/lang/StrictMath/Expm1Tests.java + test/java/lang/StrictMath/HyperbolicTests.java + test/java/lang/StrictMath/HypotTests.java + test/java/lang/StrictMath/Log10Tests.java + test/java/lang/StrictMath/Log1pTests.java + test/java/lang/StrictMath/Tests.java + test/java/lang/ToString.java + test/java/lang/annotation/AnnotationTypeMismatchException/FoundType.java + test/java/lang/annotation/Missing/A.java + test/java/lang/annotation/Missing/B.java + test/java/lang/annotation/Missing/C.java + test/java/lang/annotation/Missing/D.java + test/java/lang/annotation/Missing/Marker.java + test/java/lang/annotation/Missing/Missing.java + test/java/lang/annotation/Missing/MissingTest.java + test/java/lang/annotation/Missing/MissingWrapper.java + test/java/lang/annotation/PackageMain.java + test/java/lang/annotation/RecursiveAnnotation.java + test/java/lang/annotation/UnitTest.java + test/java/lang/annotation/loaderLeak/A.java + test/java/lang/annotation/loaderLeak/B.java + test/java/lang/annotation/loaderLeak/C.java + test/java/lang/annotation/loaderLeak/LoaderLeak.sh + test/java/lang/annotation/loaderLeak/Main.java + test/java/lang/annotation/package-info.java + test/java/math/BigDecimal/AddTests.java + test/java/math/BigDecimal/CompareToTests.java + test/java/math/BigDecimal/Constructor.java + test/java/math/BigDecimal/DivideTests.java + test/java/math/BigDecimal/FloatDoubleValueTests.java + test/java/math/BigDecimal/IntegralDivisionTests.java + test/java/math/BigDecimal/NegateTests.java + test/java/math/BigDecimal/PowTests.java + test/java/math/BigDecimal/RoundingTests.java + test/java/math/BigDecimal/ScaleByPowerOfTenTests.java + test/java/math/BigDecimal/SerializationTests.java + test/java/math/BigDecimal/StringConstructor.java + test/java/math/BigDecimal/StrippingZerosTest.java + test/java/math/BigDecimal/ToPlainStringTests.java + test/java/math/BigDecimal/ZeroScalingTests.java + test/java/math/BigInteger/BigIntegerTest.java + test/java/math/BigInteger/ModPow.java + test/java/math/BigInteger/ModPow65537.java + test/java/math/BigInteger/ModPowPowersof2.java + test/java/math/BigInteger/OperatorNpeTests.java + test/java/math/BigInteger/ProbablePrime.java + test/java/math/BigInteger/StringConstructor.java + test/java/math/BigInteger/UnicodeConstructor.java + test/java/math/RoundingMode/RoundingModeTests.java Changeset: 2113813eda62 Author: tbell Date: 2009-01-29 21:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2113813eda62 Merge Changeset: 443db0030323 Author: peytoia Date: 2008-10-02 15:54 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/443db0030323 6645263: (cal) Calendar throw java.lang.IllegalArgumentException: WEEK_OF_MONTH Reviewed-by: okutsu ! src/share/classes/java/util/Calendar.java + test/java/util/Calendar/Bug6645263.java Changeset: 7f4488e9ba24 Author: peytoia Date: 2008-10-03 15:54 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7f4488e9ba24 6683975: [fmt-da] Regression: Java 6 returns English DateFormatPatterns for Thai locale Reviewed-by: okutsu ! src/share/classes/sun/text/resources/FormatData_th.java + test/java/text/Format/DateFormat/Bug6683975.java Changeset: f71879c0999f Author: naoto Date: 2008-10-06 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f71879c0999f 6706382: jdk/test/java/util/Locale/data/deflocale.sol10 has incorrect legal notice Reviewed-by: okutsu ! test/java/util/Locale/data/deflocale.sol10 Changeset: a9be64f0ad3e Author: peytoia Date: 2008-10-07 18:25 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a9be64f0ad3e 6756569: (tz) Support tzdata2008g Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/southamerica Changeset: 7560426ed283 Author: rkennke Date: 2008-10-15 15:55 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7560426ed283 6759311: RepaintManager casts Tookit to SunToolkit without instanceof check Summary: Check type of Toolkit before casting. Reviewed-by: alexp ! src/share/classes/javax/swing/RepaintManager.java Changeset: 244f62312fec Author: peytoia Date: 2008-10-16 14:00 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/244f62312fec 6758988: (tz) Support tzdata2008h Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab Changeset: 8ea49fa4c2f7 Author: peytoia Date: 2008-10-17 13:34 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8ea49fa4c2f7 6759521: Move Bidi test programs from closed to open. Reviewed-by: okutsu + test/java/text/Bidi/BidiBug.java + test/java/text/Bidi/BidiEmbeddingTest.java + test/java/text/Bidi/BidiSurrogateTest.java Changeset: 3bc97f84a8aa Author: lana Date: 2008-10-17 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3bc97f84a8aa Merge - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/README-builds.html - make/README.html - make/THIRD_PARTY_README - src/share/classes/java/nio/channels/package.html - src/share/classes/sun/nio/ch/OptionAdaptor.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h - src/solaris/classes/sun/awt/motif/MButtonPeer.java - src/solaris/classes/sun/awt/motif/MCanvasPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxPeer.java - src/solaris/classes/sun/awt/motif/MChoicePeer.java - src/solaris/classes/sun/awt/motif/MComponentPeer.java - src/solaris/classes/sun/awt/motif/MCustomCursor.java - src/solaris/classes/sun/awt/motif/MDataTransferer.java - src/solaris/classes/sun/awt/motif/MDialogPeer.java - src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java - src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java - src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java - src/solaris/classes/sun/awt/motif/MFileDialogPeer.java - src/solaris/classes/sun/awt/motif/MFramePeer.java - src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java - src/solaris/classes/sun/awt/motif/MInputMethod.java - src/solaris/classes/sun/awt/motif/MInputMethodControl.java - src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java - src/solaris/classes/sun/awt/motif/MLabelPeer.java - src/solaris/classes/sun/awt/motif/MListPeer.java - src/solaris/classes/sun/awt/motif/MMenuBarPeer.java - src/solaris/classes/sun/awt/motif/MMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MMenuPeer.java - src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java - src/solaris/classes/sun/awt/motif/MPanelPeer.java - src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java - src/solaris/classes/sun/awt/motif/MRobotPeer.java - src/solaris/classes/sun/awt/motif/MScrollPanePeer.java - src/solaris/classes/sun/awt/motif/MScrollbarPeer.java - src/solaris/classes/sun/awt/motif/MTextAreaPeer.java - src/solaris/classes/sun/awt/motif/MTextFieldPeer.java - src/solaris/classes/sun/awt/motif/MWindowPeer.java - src/solaris/classes/sun/awt/motif/X11Clipboard.java - src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/X11Selection.java - src/solaris/classes/sun/awt/motif/X11SelectionHolder.java - src/solaris/javavm/include/typedefs_md.h - src/solaris/native/sun/awt/awt_Button.c - src/solaris/native/sun/awt/awt_Canvas.c - src/solaris/native/sun/awt/awt_Checkbox.c - src/solaris/native/sun/awt/awt_Choice12.c - src/solaris/native/sun/awt/awt_Choice21.c - src/solaris/native/sun/awt/awt_Component.c - src/solaris/native/sun/awt/awt_Cursor.c - src/solaris/native/sun/awt/awt_DataTransferer.c - src/solaris/native/sun/awt/awt_DataTransferer.h - src/solaris/native/sun/awt/awt_FileDialog.c - src/solaris/native/sun/awt/awt_GlobalCursorManager.c - src/solaris/native/sun/awt/awt_KeyboardFocusManager.c - src/solaris/native/sun/awt/awt_Label.c - src/solaris/native/sun/awt/awt_List.c - src/solaris/native/sun/awt/awt_Menu.c - src/solaris/native/sun/awt/awt_Menu.h - src/solaris/native/sun/awt/awt_MenuBar.c - src/solaris/native/sun/awt/awt_MenuBar.h - src/solaris/native/sun/awt/awt_MenuComponent.c - src/solaris/native/sun/awt/awt_MenuItem.c - src/solaris/native/sun/awt/awt_PopupMenu.c - src/solaris/native/sun/awt/awt_ScrollPane.c - src/solaris/native/sun/awt/awt_Scrollbar.c - src/solaris/native/sun/awt/awt_Selection.c - src/solaris/native/sun/awt/awt_TextArea.c - src/solaris/native/sun/awt/awt_TextArea.h - src/solaris/native/sun/awt/awt_TextField.c - src/solaris/native/sun/awt/awt_TextField.h - src/solaris/native/sun/awt/awt_TopLevel.c - src/solaris/native/sun/awt/awt_XmDnD.c - src/solaris/native/sun/awt/awt_XmDnD.h - src/solaris/native/sun/awt/awt_dnd.c - src/solaris/native/sun/awt/awt_dnd.h - src/solaris/native/sun/awt/awt_dnd_ds.c - src/solaris/native/sun/awt/awt_dnd_dt.c - src/solaris/native/sun/awt/awt_motif.c - src/solaris/native/sun/awt/awt_motif12.c - src/solaris/native/sun/awt/awt_motif21.c - src/solaris/native/sun/awt/awt_xembed.c - src/solaris/native/sun/awt/canvas.c - src/solaris/native/sun/awt/cursor.c - src/windows/javavm/include/typedefs_md.h Changeset: f67599e0ee33 Author: peytoia Date: 2008-10-30 13:12 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f67599e0ee33 6764308: (tz) Support tzdata2008i Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: f8461a705330 Author: rupashka Date: 2008-11-17 17:36 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f8461a705330 6771030: Code improvement and warnings removing from the com.sun.java.swing.plaf.gtk package Summary: Removed unnecessary castings and other warnings Reviewed-by: malenkov ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java ! src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Changeset: 6c5781fc3818 Author: peytoia Date: 2008-11-18 13:58 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6c5781fc3818 6769873: Regression test java/text/Date/DateFormat/Bug6683975.java started failing after DST ended. Reviewed-by: okutsu ! test/java/text/Format/DateFormat/Bug6683975.java Changeset: bdfe33408ed8 Author: peytoia Date: 2008-11-18 15:59 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bdfe33408ed8 6772646: Regression test java/text/Date/DateFormat/Bug4823811.java started failing after DST ended. Reviewed-by: okutsu ! test/java/text/Format/DateFormat/Bug4823811.java Changeset: 63e684c4ed2f Author: rupashka Date: 2008-11-25 16:42 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/63e684c4ed2f 6698013: JFileChooser can no longer navigate non-local file systems. Summary: ShellFolder is used only if possible Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/sun/swing/FilePane.java + test/javax/swing/JFileChooser/6698013/bug6698013.html + test/javax/swing/JFileChooser/6698013/bug6698013.java Changeset: be2b6b030a79 Author: rupashka Date: 2008-11-26 19:08 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/be2b6b030a79 6560349: REGRESSION :folder having ".lnk" in the name can not be opened by 5.0 and later versions Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java Changeset: 8b842701af50 Author: rupashka Date: 2008-11-26 19:38 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8b842701af50 6776856: Code with useShellFolder field shuold be simplify Reviewed-by: peterz ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/sun/swing/FilePane.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: 5784f5dfe3ac Author: rupashka Date: 2008-11-27 17:55 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5784f5dfe3ac 6776095: Code improvement and warnings removing from swing packages Reviewed-by: malenkov Contributed-by: Florian Brunner ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/javax/swing/colorchooser/DefaultColorSelectionModel.java ! src/share/classes/javax/swing/table/DefaultTableColumnModel.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/undo/CompoundEdit.java Changeset: 50a9a4db3500 Author: malenkov Date: 2008-12-22 17:42 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/50a9a4db3500 4864117: RFE: Make XMLDecoder API more reusable Reviewed-by: peterz, loneid - src/share/classes/com/sun/beans/ObjectHandler.java + src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java + src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java + src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java + src/share/classes/com/sun/beans/decoder/ByteElementHandler.java + src/share/classes/com/sun/beans/decoder/CharElementHandler.java + src/share/classes/com/sun/beans/decoder/ClassElementHandler.java + src/share/classes/com/sun/beans/decoder/DocumentHandler.java + src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java + src/share/classes/com/sun/beans/decoder/ElementHandler.java + src/share/classes/com/sun/beans/decoder/FalseElementHandler.java + src/share/classes/com/sun/beans/decoder/FieldElementHandler.java + src/share/classes/com/sun/beans/decoder/FloatElementHandler.java + src/share/classes/com/sun/beans/decoder/IntElementHandler.java + src/share/classes/com/sun/beans/decoder/JavaElementHandler.java + src/share/classes/com/sun/beans/decoder/LongElementHandler.java + src/share/classes/com/sun/beans/decoder/MethodElementHandler.java + src/share/classes/com/sun/beans/decoder/NewElementHandler.java + src/share/classes/com/sun/beans/decoder/NullElementHandler.java + src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java + src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java + src/share/classes/com/sun/beans/decoder/ShortElementHandler.java + src/share/classes/com/sun/beans/decoder/StringElementHandler.java + src/share/classes/com/sun/beans/decoder/TrueElementHandler.java + src/share/classes/com/sun/beans/decoder/ValueObject.java + src/share/classes/com/sun/beans/decoder/ValueObjectImpl.java + src/share/classes/com/sun/beans/decoder/VarElementHandler.java + src/share/classes/com/sun/beans/decoder/VoidElementHandler.java + src/share/classes/com/sun/beans/finder/AbstractFinder.java ! src/share/classes/com/sun/beans/finder/ClassFinder.java + src/share/classes/com/sun/beans/finder/ConstructorFinder.java + src/share/classes/com/sun/beans/finder/FieldFinder.java + src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/com/sun/beans/finder/PrimitiveTypeMap.java + src/share/classes/com/sun/beans/finder/PrimitiveWrapperMap.java + src/share/classes/com/sun/beans/finder/Signature.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/XMLDecoder.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java + test/java/beans/XMLDecoder/Test4864117.java ! test/java/beans/XMLDecoder/Test6341798.java + test/java/beans/XMLDecoder/spec/AbstractTest.java + test/java/beans/XMLDecoder/spec/TestArray.java + test/java/beans/XMLDecoder/spec/TestBoolean.java + test/java/beans/XMLDecoder/spec/TestByte.java + test/java/beans/XMLDecoder/spec/TestChar.java + test/java/beans/XMLDecoder/spec/TestClass.java + test/java/beans/XMLDecoder/spec/TestDouble.java + test/java/beans/XMLDecoder/spec/TestFalse.java + test/java/beans/XMLDecoder/spec/TestField.java + test/java/beans/XMLDecoder/spec/TestFloat.java + test/java/beans/XMLDecoder/spec/TestInt.java + test/java/beans/XMLDecoder/spec/TestJava.java + test/java/beans/XMLDecoder/spec/TestLong.java + test/java/beans/XMLDecoder/spec/TestMethod.java + test/java/beans/XMLDecoder/spec/TestNew.java + test/java/beans/XMLDecoder/spec/TestNull.java + test/java/beans/XMLDecoder/spec/TestObject.java + test/java/beans/XMLDecoder/spec/TestProperty.java + test/java/beans/XMLDecoder/spec/TestShort.java + test/java/beans/XMLDecoder/spec/TestString.java + test/java/beans/XMLDecoder/spec/TestTrue.java + test/java/beans/XMLDecoder/spec/TestVar.java Changeset: 2b8a0d8b5cbb Author: malenkov Date: 2008-12-25 20:43 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2b8a0d8b5cbb 6736248: EnumEditor bug. Class check incorrect Reviewed-by: rupashka, alexp ! src/share/classes/sun/beans/editors/EnumEditor.java + test/java/beans/PropertyEditor/TestEnumSubclass.java + test/java/beans/PropertyEditor/TestEnumSubclassJava.java + test/java/beans/PropertyEditor/TestEnumSubclassNull.java + test/java/beans/PropertyEditor/TestEnumSubclassValue.java Changeset: b06c29386f63 Author: amenkov Date: 2009-01-19 20:11 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b06c29386f63 6702956: OpenJDK: replace encumbered code (software synthesizer) 6717691: Update Gervill with post 1.0 fixes 6740210: Update Gervill with more post 1.0 fixes 6748247: Further update Gervill with still more post 1.0 fixes 6748251: Apply IcedTea midi sound patch 6758986: Gervill: Turn SoftJitterCorrector, SoftAudioPusher threads into a daemon threads Reviewed-by: ohair, darcy ! make/common/Release.gmk ! make/common/internal/BinaryPlugs.gmk ! make/javax/sound/Makefile - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java + src/share/classes/com/sun/media/sound/AudioFileSoundbankReader.java + src/share/classes/com/sun/media/sound/AudioFloatConverter.java + src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java + src/share/classes/com/sun/media/sound/AudioFloatInputStream.java + src/share/classes/com/sun/media/sound/AudioSynthesizer.java + src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java + src/share/classes/com/sun/media/sound/DLSInfo.java + src/share/classes/com/sun/media/sound/DLSInstrument.java + src/share/classes/com/sun/media/sound/DLSModulator.java + src/share/classes/com/sun/media/sound/DLSRegion.java + src/share/classes/com/sun/media/sound/DLSSample.java + src/share/classes/com/sun/media/sound/DLSSampleLoop.java + src/share/classes/com/sun/media/sound/DLSSampleOptions.java + src/share/classes/com/sun/media/sound/DLSSoundbank.java + src/share/classes/com/sun/media/sound/DLSSoundbankReader.java ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java + src/share/classes/com/sun/media/sound/EmergencySoundbank.java + src/share/classes/com/sun/media/sound/FFT.java + src/share/classes/com/sun/media/sound/InvalidDataException.java + src/share/classes/com/sun/media/sound/InvalidFormatException.java + src/share/classes/com/sun/media/sound/JARSoundbankReader.java + src/share/classes/com/sun/media/sound/ModelAbstractChannelMixer.java + src/share/classes/com/sun/media/sound/ModelAbstractOscillator.java + src/share/classes/com/sun/media/sound/ModelByteBuffer.java + src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java + src/share/classes/com/sun/media/sound/ModelChannelMixer.java + src/share/classes/com/sun/media/sound/ModelConnectionBlock.java + src/share/classes/com/sun/media/sound/ModelDestination.java + src/share/classes/com/sun/media/sound/ModelDirectedPlayer.java + src/share/classes/com/sun/media/sound/ModelDirector.java + src/share/classes/com/sun/media/sound/ModelIdentifier.java + src/share/classes/com/sun/media/sound/ModelInstrument.java + src/share/classes/com/sun/media/sound/ModelInstrumentComparator.java + src/share/classes/com/sun/media/sound/ModelMappedInstrument.java + src/share/classes/com/sun/media/sound/ModelOscillator.java + src/share/classes/com/sun/media/sound/ModelOscillatorStream.java + src/share/classes/com/sun/media/sound/ModelPatch.java + src/share/classes/com/sun/media/sound/ModelPerformer.java + src/share/classes/com/sun/media/sound/ModelSource.java + src/share/classes/com/sun/media/sound/ModelStandardDirector.java + src/share/classes/com/sun/media/sound/ModelStandardTransform.java + src/share/classes/com/sun/media/sound/ModelTransform.java + src/share/classes/com/sun/media/sound/ModelWavetable.java ! src/share/classes/com/sun/media/sound/Platform.java + src/share/classes/com/sun/media/sound/RIFFInvalidDataException.java + src/share/classes/com/sun/media/sound/RIFFInvalidFormatException.java + src/share/classes/com/sun/media/sound/RIFFReader.java + src/share/classes/com/sun/media/sound/RIFFWriter.java ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java + src/share/classes/com/sun/media/sound/SF2GlobalRegion.java + src/share/classes/com/sun/media/sound/SF2Instrument.java + src/share/classes/com/sun/media/sound/SF2InstrumentRegion.java + src/share/classes/com/sun/media/sound/SF2Layer.java + src/share/classes/com/sun/media/sound/SF2LayerRegion.java + src/share/classes/com/sun/media/sound/SF2Modulator.java + src/share/classes/com/sun/media/sound/SF2Region.java + src/share/classes/com/sun/media/sound/SF2Sample.java + src/share/classes/com/sun/media/sound/SF2Soundbank.java + src/share/classes/com/sun/media/sound/SF2SoundbankReader.java + src/share/classes/com/sun/media/sound/SimpleInstrument.java + src/share/classes/com/sun/media/sound/SimpleSoundbank.java + src/share/classes/com/sun/media/sound/SoftAbstractResampler.java + src/share/classes/com/sun/media/sound/SoftAudioBuffer.java + src/share/classes/com/sun/media/sound/SoftAudioProcessor.java + src/share/classes/com/sun/media/sound/SoftAudioPusher.java + src/share/classes/com/sun/media/sound/SoftChannel.java + src/share/classes/com/sun/media/sound/SoftChannelProxy.java + src/share/classes/com/sun/media/sound/SoftChorus.java + src/share/classes/com/sun/media/sound/SoftControl.java + src/share/classes/com/sun/media/sound/SoftCubicResampler.java + src/share/classes/com/sun/media/sound/SoftEnvelopeGenerator.java + src/share/classes/com/sun/media/sound/SoftFilter.java + src/share/classes/com/sun/media/sound/SoftInstrument.java + src/share/classes/com/sun/media/sound/SoftJitterCorrector.java + src/share/classes/com/sun/media/sound/SoftLanczosResampler.java + src/share/classes/com/sun/media/sound/SoftLimiter.java + src/share/classes/com/sun/media/sound/SoftLinearResampler.java + src/share/classes/com/sun/media/sound/SoftLinearResampler2.java + src/share/classes/com/sun/media/sound/SoftLowFrequencyOscillator.java + src/share/classes/com/sun/media/sound/SoftMainMixer.java + src/share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java + src/share/classes/com/sun/media/sound/SoftMixingClip.java + src/share/classes/com/sun/media/sound/SoftMixingDataLine.java + src/share/classes/com/sun/media/sound/SoftMixingMainMixer.java + src/share/classes/com/sun/media/sound/SoftMixingMixer.java + src/share/classes/com/sun/media/sound/SoftMixingMixerProvider.java + src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java + src/share/classes/com/sun/media/sound/SoftPerformer.java + src/share/classes/com/sun/media/sound/SoftPointResampler.java + src/share/classes/com/sun/media/sound/SoftProcess.java + src/share/classes/com/sun/media/sound/SoftProvider.java + src/share/classes/com/sun/media/sound/SoftReceiver.java + src/share/classes/com/sun/media/sound/SoftResampler.java + src/share/classes/com/sun/media/sound/SoftResamplerStreamer.java + src/share/classes/com/sun/media/sound/SoftReverb.java + src/share/classes/com/sun/media/sound/SoftShortMessage.java + src/share/classes/com/sun/media/sound/SoftSincResampler.java + src/share/classes/com/sun/media/sound/SoftSynthesizer.java + src/share/classes/com/sun/media/sound/SoftTuning.java + src/share/classes/com/sun/media/sound/SoftVoice.java + src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java + src/share/classes/com/sun/media/sound/WaveFloatFileReader.java + src/share/classes/com/sun/media/sound/WaveFloatFileWriter.java ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.MidiDeviceProvider ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.MidiFileReader ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.SoundbankReader ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.AudioFileReader ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.FormatConversionProvider ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.MixerProvider - src/share/lib/audio/soundbank.gm + test/javax/sound/midi/Gervill/AudioFloatConverter/GetFormat.java + test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Available.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Close.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFormat.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFrameLength.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/MarkSupported.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Read.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArray.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArrayIntInt.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Reset.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Skip.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankFile.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream2.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankUrl.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/ding.dls + test/javax/sound/midi/Gervill/EmergencySoundbank/TestCreateSoundbank.java + test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java + test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java + test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java + test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java + test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java + test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetAttenuation.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetChannels.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopLength.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopStart.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetPitchCorrection.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBuffer.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormatFloat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferFloat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Open.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Set8BitExtensionBuffer.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/SetLoopType.java + test/javax/sound/midi/Gervill/ModelDestination/NewModelDestination.java + test/javax/sound/midi/Gervill/ModelDestination/NewModelDestinationModelIdentifier.java + test/javax/sound/midi/Gervill/ModelDestination/SetIdentifier.java + test/javax/sound/midi/Gervill/ModelDestination/SetTransform.java + test/javax/sound/midi/Gervill/ModelIdentifier/EqualsObject.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierString.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringInt.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringString.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringStringInt.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetInstance.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetObject.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetVariable.java + test/javax/sound/midi/Gervill/ModelPerformer/GetOscillators.java + test/javax/sound/midi/Gervill/ModelPerformer/SetConnectionBlocks.java + test/javax/sound/midi/Gervill/ModelPerformer/SetDefaultConnectionsEnabled.java + test/javax/sound/midi/Gervill/ModelPerformer/SetExclusiveClass.java + test/javax/sound/midi/Gervill/ModelPerformer/SetKeyFrom.java + test/javax/sound/midi/Gervill/ModelPerformer/SetKeyTo.java + test/javax/sound/midi/Gervill/ModelPerformer/SetName.java + test/javax/sound/midi/Gervill/ModelPerformer/SetSelfNonExclusive.java + test/javax/sound/midi/Gervill/ModelPerformer/SetVelFrom.java + test/javax/sound/midi/Gervill/ModelPerformer/SetVelTo.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSource.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifier.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBoolean.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBoolean.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBooleanInt.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierModelTransform.java + test/javax/sound/midi/Gervill/ModelSource/SetIdentifier.java + test/javax/sound/midi/Gervill/ModelSource/SetTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBoolean.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBoolean.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBooleanInt.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetDirection.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetPolarity.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformAbsolute.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConcave.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConvex.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformLinear.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformSwitch.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java + test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java + test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java + test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java + test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankFile.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream2.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankUrl.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/ding.sf2 + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrument.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformer.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArray.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/Clear.java + test/javax/sound/midi/Gervill/SimpleInstrument/SetName.java + test/javax/sound/midi/Gervill/SimpleInstrument/SetPatch.java + test/javax/sound/midi/Gervill/SimpleSoundbank/AddInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/AddResource.java + test/javax/sound/midi/Gervill/SimpleSoundbank/GetInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/RemoveInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetDescription.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetName.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetVendor.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetVersion.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Array.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Clear.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Get.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/NewSoftAudioBuffer.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetFormat.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetPropertyInfo.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/Open.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/OpenStream.java + test/javax/sound/midi/Gervill/SoftChannel/AllNotesOff.java + test/javax/sound/midi/Gervill/SoftChannel/AllSoundOff.java + test/javax/sound/midi/Gervill/SoftChannel/ChannelPressure.java + test/javax/sound/midi/Gervill/SoftChannel/Controller.java + test/javax/sound/midi/Gervill/SoftChannel/LocalControl.java + test/javax/sound/midi/Gervill/SoftChannel/Mono.java + test/javax/sound/midi/Gervill/SoftChannel/Mute.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOff.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOff2.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOn.java + test/javax/sound/midi/Gervill/SoftChannel/Omni.java + test/javax/sound/midi/Gervill/SoftChannel/PitchBend.java + test/javax/sound/midi/Gervill/SoftChannel/PolyPressure.java + test/javax/sound/midi/Gervill/SoftChannel/ProgramChange.java + test/javax/sound/midi/Gervill/SoftChannel/ResetAllControllers.java + test/javax/sound/midi/Gervill/SoftChannel/SoftTestUtils.java + test/javax/sound/midi/Gervill/SoftChannel/Solo.java + test/javax/sound/midi/Gervill/SoftCubicResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal_mono.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive_mono.java + test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java + test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftProvider/GetDevice.java + test/javax/sound/midi/Gervill/SoftReceiver/Close.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ActiveSense.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_AllNotesOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_AllSoundOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ChannelPressure.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Controller.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Mono.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_AllChannels.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Delayed.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Multiple.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Omni.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_PitchBend.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_PolyPressure.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ProgramChange.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ResetAllControllers.java + test/javax/sound/midi/Gervill/SoftReceiver/SoftTestUtils.java + test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftSynthesizer/Close.java + test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetChannels.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetDefaultSoundbank.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetDeviceInfo.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetLatency.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxPolyphony.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxReceivers.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxTransmitters.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMicrosecondPosition.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver2.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceivers.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitter.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitters.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetVoiceStatus.java + test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java + test/javax/sound/midi/Gervill/SoftSynthesizer/IsOpen.java + test/javax/sound/midi/Gervill/SoftSynthesizer/IsSoundbankSupported.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java + test/javax/sound/midi/Gervill/SoftSynthesizer/OpenStream.java + test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/TestRender1.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/ding.sf2 + test/javax/sound/midi/Gervill/SoftSynthesizer/expresso.mid + test/javax/sound/midi/Gervill/SoftTuning/GetName.java + test/javax/sound/midi/Gervill/SoftTuning/GetTuning.java + test/javax/sound/midi/Gervill/SoftTuning/GetTuningInt.java + test/javax/sound/midi/Gervill/SoftTuning/Load1.java + test/javax/sound/midi/Gervill/SoftTuning/Load2.java + test/javax/sound/midi/Gervill/SoftTuning/Load4.java + test/javax/sound/midi/Gervill/SoftTuning/Load5.java + test/javax/sound/midi/Gervill/SoftTuning/Load6.java + test/javax/sound/midi/Gervill/SoftTuning/Load7.java + test/javax/sound/midi/Gervill/SoftTuning/Load8.java + test/javax/sound/midi/Gervill/SoftTuning/Load9.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuning.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningByteArray.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatch.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatchByteArray.java Changeset: cda097df492f Author: peterz Date: 2009-01-21 21:30 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cda097df492f 6792401: Windows LAF: ActiveWindowsIcon should not be greedy with fallback icon Summary: Fallback mechanism changed to use symbolic name instead of icon. Reviewed-by: igor, rupashka ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java Changeset: cf591ddc3456 Author: naoto Date: 2009-01-21 13:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cf591ddc3456 6627549: ISO 3166 code addition: Saint Barthelemy and Saint Martin 6786276: Locale.getISOCountries() still contains country code "CS" Reviewed-by: okutsu ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/LocaleNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Locale/LocaleTest.java ! test/sun/text/resources/LocaleData Changeset: f650e6e22c16 Author: malenkov Date: 2009-01-23 18:31 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f650e6e22c16 4222508: JColorChooser ignores setEnabled() function call Reviewed-by: peterz, rupashka ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java + test/javax/swing/JColorChooser/Test4222508.html + test/javax/swing/JColorChooser/Test4222508.java Changeset: d75ae3f11e01 Author: peytoia Date: 2009-01-26 09:19 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d75ae3f11e01 6796489: (tz) Support tzdata2009a Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: e02f2d591cd5 Author: malenkov Date: 2009-01-29 15:34 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e02f2d591cd5 6788531: java.beans.Statement imposes excessive access control Reviewed-by: peterz, rupashka ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/Statement.java + test/java/beans/EventHandler/Test6788531.java + test/java/beans/Statement/Test6788531.java Changeset: ff6633279632 Author: rupashka Date: 2009-01-29 19:06 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ff6633279632 6794836: BasicSliderUI throws NullPointerExc when JSlider maximum is Integer.MAX_VALUE Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6794836/bug6794836.java Changeset: 1f6ff90d9692 Author: lana Date: 2009-01-29 09:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1f6ff90d9692 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/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java - src/share/lib/audio/soundbank.gm Changeset: 4b03e27a4409 Author: lana Date: 2009-02-03 22:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4b03e27a4409 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 Changeset: b4ac413b1f12 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b4ac413b1f12 Added tag jdk7-b46 for changeset 4b03e27a4409 ! .hgtags From john.coomes at sun.com Fri Feb 6 12:16:04 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Feb 2009 20:16:04 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 16 new changesets Message-ID: <20090206201630.59EC4D047@hg.openjdk.java.net> Changeset: d79ad96ce47c Author: bpatel Date: 2009-01-15 17:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d79ad96ce47c 6786682: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - HTML tag should have lang attribute Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.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/util/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java + test/com/sun/javadoc/testHtmlTag/TestHtmlTag.java + test/com/sun/javadoc/testHtmlTag/pkg1/C1.java + test/com/sun/javadoc/testHtmlTag/pkg2/C2.java Changeset: 42f9d392159d Author: jjg Date: 2009-01-15 18:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/42f9d392159d 6794520: MessageRetriever should be upgraded to use varargs Object... Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: 18c433be7aa7 Author: darcy Date: 2009-01-16 14:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/18c433be7aa7 6583626: Improve serialization support in javax.lang.model.type exception classes Reviewed-by: jjg ! src/share/classes/javax/lang/model/type/MirroredTypeException.java ! src/share/classes/javax/lang/model/type/MirroredTypesException.java Changeset: d0b33fe8e710 Author: jjg Date: 2009-01-19 19:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d0b33fe8e710 6794959: add new switch -XDexpectKeys=key,key.... Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/T6794959.java Changeset: 83c59a9d4b94 Author: mcimadamore Date: 2009-01-20 17:49 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/83c59a9d4b94 6795580: parser confused by square brackets in qualified generic cast Summary: Parser rejects cast with qualified generic array types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/cast/6795580/T6795580.java + test/tools/javac/cast/6795580/T6795580.out Changeset: 1ca2dc8584e1 Author: mcimadamore Date: 2009-01-20 17:49 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/1ca2dc8584e1 6557199: Fails to reject bad override of generic method Summary: Javac does not correctly implement JLS3 8.4.5 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/rawOverride/6557199/T6557199.java + test/tools/javac/generics/rawOverride/6557199/T6557199.out Changeset: 1bf037016426 Author: jjg Date: 2009-01-20 15:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/1bf037016426 6794582: javadoc should read files using a FileManager Reviewed-by: darcy, bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.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/javadoc/ClassDocImpl.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/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/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java Changeset: b4b1f7732289 Author: jjg Date: 2009-01-20 18:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/b4b1f7732289 6795903: fix latent build warnings in langtools repository Reviewed-by: darcy ! make/build.properties ! 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/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/Messager.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 Changeset: d486ac6389d7 Author: jjg Date: 2009-01-21 08:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d486ac6389d7 6795030: Files in langtools build can be compiled ignoring java.home settings Reviewed-by: mcimadamore ! make/build.xml Changeset: e6dafbf35355 Author: jjg Date: 2009-01-22 15:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e6dafbf35355 6796965: dev-time wrapper script for javac broken Reviewed-by: ksrini ! make/build.xml Changeset: e3930187199c Author: jjg Date: 2009-01-23 11:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e3930187199c 6795365: NetBeans projects in langtools repository are not NB6.5-friendly Reviewed-by: mcimadamore ! make/README ! make/build.xml ! make/netbeans/README - make/netbeans/apt/README - make/netbeans/apt/build.xml - make/netbeans/apt/nbproject/project.xml - make/netbeans/common/shared.xml - make/netbeans/common/standard-context-menu-items-no-javadoc.ent - make/netbeans/common/standard-context-menu-items.ent - make/netbeans/common/standard-ide-actions-no-javadoc.ent - make/netbeans/common/standard-ide-actions.ent - make/netbeans/compiler/README - make/netbeans/compiler/build.xml - make/netbeans/compiler/nbproject/project.xml - make/netbeans/doclets/README - make/netbeans/doclets/build.xml - make/netbeans/doclets/nbproject/project.xml - make/netbeans/javadoc/README - make/netbeans/javadoc/build.xml - make/netbeans/javadoc/nbproject/project.xml - make/netbeans/javah/README - make/netbeans/javah/build.xml - make/netbeans/javah/nbproject/project.xml - make/netbeans/javap/README - make/netbeans/javap/build.xml - make/netbeans/javap/nbproject/project.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 Changeset: 3b2c55b7bd01 Author: tbell Date: 2009-01-24 11:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/3b2c55b7bd01 6797463: 6557199 breaks the jax-ws workspace Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java Changeset: 40fd14d94c3c Author: tbell Date: 2009-01-24 16:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/40fd14d94c3c Merge - make/netbeans/apt/README - make/netbeans/apt/build.xml - make/netbeans/apt/nbproject/project.xml - make/netbeans/common/shared.xml - make/netbeans/common/standard-context-menu-items-no-javadoc.ent - make/netbeans/common/standard-context-menu-items.ent - make/netbeans/common/standard-ide-actions-no-javadoc.ent - make/netbeans/common/standard-ide-actions.ent - make/netbeans/compiler/README - make/netbeans/compiler/build.xml - make/netbeans/compiler/nbproject/project.xml - make/netbeans/doclets/README - make/netbeans/doclets/build.xml - make/netbeans/doclets/nbproject/project.xml - make/netbeans/javadoc/README - make/netbeans/javadoc/build.xml - make/netbeans/javadoc/nbproject/project.xml - make/netbeans/javah/README - make/netbeans/javah/build.xml - make/netbeans/javah/nbproject/project.xml - make/netbeans/javap/README - make/netbeans/javap/build.xml - make/netbeans/javap/nbproject/project.xml Changeset: 0f922ff6968f Author: tbell Date: 2009-01-26 15:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/0f922ff6968f 6797871: Fix for 6797463 did not remove the jtreg tests, and it should have Reviewed-by: jjg - test/tools/javac/generics/rawOverride/6557199/T6557199.java - test/tools/javac/generics/rawOverride/6557199/T6557199.out Changeset: be546a6c08e3 Author: tbell Date: 2009-01-29 21:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/be546a6c08e3 Merge Changeset: 2b8f6bab2392 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/2b8f6bab2392 Added tag jdk7-b46 for changeset be546a6c08e3 ! .hgtags From Vladimir.Kozlov at Sun.COM Fri Feb 6 12:30:01 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 06 Feb 2009 12:30:01 -0800 Subject: Request for reviews (S): 6791852: assert(b->_nodes[insidx] == n,"got insidx set incorrectly") In-Reply-To: <498C82DF.8060409@sun.com> References: <498C82DF.8060409@sun.com> Message-ID: <498C9DC9.5010502@sun.com> I updated changes and webrev based on reviews: http://cr.openjdk.java.net/~kvn/6791852/webrev.01 Thanks, Vladimir Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6791852/webrev.00 > > Fixed 6791852: assert(b->_nodes[insidx] == n,"got insidx set incorrectly") > > Problem: > The code in PhaseChaitin::Split() in the part "Handle Crossing HRP Boundry" > expects that a new MachSpillCopy node is inserted before the current node. > After 6782232 fix it is not true if the current node is CreateEx. > > Solution: > Remove the original fix for 6782232 in PhaseChaitin::insert_proj(). > Move the CreateEx up before each round of IFG construction to produce > correct interference graph. > Move verification checks in chaitin after IFG construction. > Add additional check into PhaseCFG::verify(). > Fix check in PhaseChaitin::verify_base_ptrs(). > > Reviewed by: never, phh > > Fix verified (y/n): y, bug's test case > > Other testing: > JPRT, CTW (with -XX:+VerifyRegisterAllocator) > From Changpeng.Fang at Sun.COM Fri Feb 6 14:42:00 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Fri, 06 Feb 2009 14:42:00 -0800 Subject: Request for reviews (L): 6761600: Use SSE 4.2 In STTNI Intrinsics In-Reply-To: <498C7FE0.5020200@sun.com> References: <496FD74F.9070009@sun.com> <498C6AE0.4010006@Sun.COM> <498C7FE0.5020200@sun.com> Message-ID: <498CBCB8.8060604@Sun.COM> Thanks. I put the updated webrev in: http://cr.openjdk.java.net/~cfang/6761600/webrev/ and I am testing to adjust the masm.jccb stuff. Changpeng Vladimir Kozlov wrote: > Changpeng, > > Good work. > > src/cpu/x86/vm/assembler_x86.cpp: > Remove Macro NOT_LP64() around asserts in new instructions. > VM_Version::supports_sse4_2() should be checked on LP64 also > since not all 64-bits CPUs support it. > > > src/cpu/x86/vm/vm_version_x86_32.cpp: > src/cpu/x86/vm/vm_version_x86_64.cpp: > Remove UseUnalignedLoadStores check in the next code, > it is not needed and it is wrong to have it since it depends on > UseXMMForArrayCopy flag. The top check supports_sse4_2() && supports_ht() > is enough for movdqu verification. > > + if(FLAG_IS_DEFAULT(UseSSE42Intrinsics) && > + UseUnalignedLoadStores){ //sse42 intrinsics depend on movdqu > + UseSSE42Intrinsics = true; > } > > > In both x86_32.ad and x86_64.ad try to use short forward branches > masm.jccb() > starting from the bottom of the assembler code. Then try to use all > intrinsics with all flags variations and revert back to long jump > those branches > VM will complain about. > > > cpu/x86/vm/x86_32.ad: > align comments: > > ! masm.andl(rsi, 0xfffffff8); // rsi holds the vector count > ! masm.andl(rdi, 0x00000007); // rdi holds the tail count > > In enc_String_Equals() and enc_String_IndexOf() > use movptr() for value_offset. > > > src/share/vm/adlc/formssel.cpp: > Missing checks for AryEq. > > src/share/vm/classfile/vmSymbols.hpp: > Remove empty after indexOf_name since equals() also j.l.String method: > do_name( indexOf_name, "indexOf") > > > + do_intrinsic(_equals, java_lang_String, equals_name, > object_boolean_signature, F_R) > > > src/share/vm/opto/library_call.cpp: > Add that it because spec allow to specify NULL as argument: > + //should not do null check for argument for string_equals. > > Remove next line > + //argument = do_null_check(argument, T_OBJECT); > > Thanks, > Vladimir > > Changpeng Fang wrote: >> http://webrev.invokedynamic.info/cfang/6761600/index.html >> >> Works on 6761600 : Use SSE 4.2 in intrinsics for String.compareTo(), >> String.equals(), String.indexOf() and Arrays.equals(), among which, >> String.equals() and String.indexOf() are intrinsified for the first >> time. >> >> Problem: Use SSE 4.2 instructions for STTNI intrinsics for for Nehalem >> improvements >> >> Solution: >> Implemented both 32 and 64-bit versions for X86. Introduced a new >> flag UseSSE42Intrinsics, with the default TRUE on systems that support >> SSE4.2 (false otherwise). >> >> Reviewed by: >> >> Fix verified (y/n): y >> >> Other testing: JPRT, >> >> From Thomas.Rodriguez at Sun.COM Fri Feb 6 15:52:36 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 06 Feb 2009 15:52:36 -0800 Subject: Request for reviews (L): 6761600: Use SSE 4.2 In STTNI Intrinsics In-Reply-To: <498CBCB8.8060604@Sun.COM> References: <496FD74F.9070009@sun.com> <498C6AE0.4010006@Sun.COM> <498C7FE0.5020200@sun.com> <498CBCB8.8060604@Sun.COM> Message-ID: <1CBFFA46-1DDE-4AFC-BE9A-F7A1077809CE@sun.com> Why is UseSSE42Intrinsics conditional on supports_ht()? Isn't supports_sse4_2() sufficient? Also the setting for UseSSE42Intrinsics should take into account whether UseSSE >= 4 instead of having to test for it everywhere with (UseSSE >= 4 && UseSSE42Intrinsics). In the ad file changes you don't need to force regXD6 and regXD7 for temps. Declare them as regXD and use the TEMP effect instead of the KILL effect. A TEMP is a synthetic input that interferes with the other inputs but not the output. As long as the TEMP and the result are different register classes then there's no problem. You should also have different variants for UseSSE42Intrinsics and ! UseSSE42Intrinsics. The !UseSSE42Intrinsics don't use or need the regXDs right? The string_indexOf triggering criteria in library_call.cpp seems wrong since it skips the optimization for constant strings in preference for the SSE4.2 version. The constant string seems like it should be preferred shouldn't it? As an aside, when writing enc_class functions it's better to pass in the operands instead of assuming the register usage in the enc_class function, in the style of the enc_Array_Equals versions. It's also nicer to have names for registers instead of just using raw register names everywhere. This all makes it easier to read and easier to change register assignments. These intrinsics end up using a lot of bound registers because we don't have a way to express that the inputs interfere with the output. Otherwise we could use unbound masks for all these inputs and likely would generate better code. Someday I'll add this feature. Note that the types mentioned in the enc_class declaration are completely meaningless. They are ignored by the adlc since enc_classes are handled like C macros, as as pure textual substitution. Otherwise this looks good to me. tom On Feb 6, 2009, at 2:42 PM, Changpeng Fang wrote: > Thanks. I put the updated webrev in: > http://cr.openjdk.java.net/~cfang/6761600/webrev/ > > and I am testing to adjust the masm.jccb stuff. > > Changpeng > > > Vladimir Kozlov wrote: >> Changpeng, >> >> Good work. >> >> src/cpu/x86/vm/assembler_x86.cpp: >> Remove Macro NOT_LP64() around asserts in new instructions. >> VM_Version::supports_sse4_2() should be checked on LP64 also >> since not all 64-bits CPUs support it. >> >> >> src/cpu/x86/vm/vm_version_x86_32.cpp: >> src/cpu/x86/vm/vm_version_x86_64.cpp: >> Remove UseUnalignedLoadStores check in the next code, >> it is not needed and it is wrong to have it since it depends on >> UseXMMForArrayCopy flag. The top check supports_sse4_2() && >> supports_ht() >> is enough for movdqu verification. >> >> + if(FLAG_IS_DEFAULT(UseSSE42Intrinsics) && >> + UseUnalignedLoadStores){ //sse42 intrinsics depend on >> movdqu >> + UseSSE42Intrinsics = true; >> } >> >> >> In both x86_32.ad and x86_64.ad try to use short forward branches >> masm.jccb() >> starting from the bottom of the assembler code. Then try to use all >> intrinsics with all flags variations and revert back to long jump >> those branches >> VM will complain about. >> >> >> cpu/x86/vm/x86_32.ad: >> align comments: >> >> ! masm.andl(rsi, 0xfffffff8); // rsi holds the vector count >> ! masm.andl(rdi, 0x00000007); // rdi holds the tail count >> >> In enc_String_Equals() and enc_String_IndexOf() >> use movptr() for value_offset. >> >> >> src/share/vm/adlc/formssel.cpp: >> Missing checks for AryEq. >> >> src/share/vm/classfile/vmSymbols.hpp: >> Remove empty after indexOf_name since equals() also j.l.String >> method: >> do_name( indexOf_name, "indexOf") >> >> >> + do_intrinsic(_equals, java_lang_String, equals_name, >> object_boolean_signature, F_R) >> >> >> src/share/vm/opto/library_call.cpp: >> Add that it because spec allow to specify NULL as argument: >> + //should not do null check for argument for string_equals. >> >> Remove next line >> + //argument = do_null_check(argument, T_OBJECT); >> >> Thanks, >> Vladimir >> >> Changpeng Fang wrote: >>> http://webrev.invokedynamic.info/cfang/6761600/index.html >>> >>> Works on 6761600 : Use SSE 4.2 in intrinsics for String.compareTo(), >>> String.equals(), String.indexOf() and Arrays.equals(), among which, >>> String.equals() and String.indexOf() are intrinsified for the >>> first time. >>> >>> Problem: Use SSE 4.2 instructions for STTNI intrinsics for for >>> Nehalem >>> improvements >>> >>> Solution: >>> Implemented both 32 and 64-bit versions for X86. Introduced a >>> new >>> flag UseSSE42Intrinsics, with the default TRUE on systems that >>> support >>> SSE4.2 (false otherwise). >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y >>> >>> Other testing: JPRT, >>> >>> > From Vladimir.Kozlov at Sun.COM Fri Feb 6 15:58:59 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 06 Feb 2009 15:58:59 -0800 Subject: Request for reviews (L): 6761600: Use SSE 4.2 In STTNI Intrinsics In-Reply-To: <498CBCB8.8060604@Sun.COM> References: <496FD74F.9070009@sun.com> <498C6AE0.4010006@Sun.COM> <498C7FE0.5020200@sun.com> <498CBCB8.8060604@Sun.COM> Message-ID: <498CCEC3.1020808@sun.com> Looks good. Vladimir Changpeng Fang wrote: > Thanks. I put the updated webrev in: > http://cr.openjdk.java.net/~cfang/6761600/webrev/ > > and I am testing to adjust the masm.jccb stuff. > > Changpeng > > > Vladimir Kozlov wrote: >> Changpeng, >> >> Good work. >> >> src/cpu/x86/vm/assembler_x86.cpp: >> Remove Macro NOT_LP64() around asserts in new instructions. >> VM_Version::supports_sse4_2() should be checked on LP64 also >> since not all 64-bits CPUs support it. >> >> >> src/cpu/x86/vm/vm_version_x86_32.cpp: >> src/cpu/x86/vm/vm_version_x86_64.cpp: >> Remove UseUnalignedLoadStores check in the next code, >> it is not needed and it is wrong to have it since it depends on >> UseXMMForArrayCopy flag. The top check supports_sse4_2() && supports_ht() >> is enough for movdqu verification. >> >> + if(FLAG_IS_DEFAULT(UseSSE42Intrinsics) && >> + UseUnalignedLoadStores){ //sse42 intrinsics depend on movdqu >> + UseSSE42Intrinsics = true; >> } >> >> >> In both x86_32.ad and x86_64.ad try to use short forward branches >> masm.jccb() >> starting from the bottom of the assembler code. Then try to use all >> intrinsics with all flags variations and revert back to long jump >> those branches >> VM will complain about. >> >> >> cpu/x86/vm/x86_32.ad: >> align comments: >> >> ! masm.andl(rsi, 0xfffffff8); // rsi holds the vector count >> ! masm.andl(rdi, 0x00000007); // rdi holds the tail count >> >> In enc_String_Equals() and enc_String_IndexOf() >> use movptr() for value_offset. >> >> >> src/share/vm/adlc/formssel.cpp: >> Missing checks for AryEq. >> >> src/share/vm/classfile/vmSymbols.hpp: >> Remove empty after indexOf_name since equals() also j.l.String method: >> do_name( indexOf_name, "indexOf") >> >> >> + do_intrinsic(_equals, java_lang_String, equals_name, >> object_boolean_signature, F_R) >> >> >> src/share/vm/opto/library_call.cpp: >> Add that it because spec allow to specify NULL as argument: >> + //should not do null check for argument for string_equals. >> >> Remove next line >> + //argument = do_null_check(argument, T_OBJECT); >> >> Thanks, >> Vladimir >> >> Changpeng Fang wrote: >>> http://webrev.invokedynamic.info/cfang/6761600/index.html >>> >>> Works on 6761600 : Use SSE 4.2 in intrinsics for String.compareTo(), >>> String.equals(), String.indexOf() and Arrays.equals(), among which, >>> String.equals() and String.indexOf() are intrinsified for the first >>> time. >>> >>> Problem: Use SSE 4.2 instructions for STTNI intrinsics for for Nehalem >>> improvements >>> >>> Solution: >>> Implemented both 32 and 64-bit versions for X86. Introduced a new >>> flag UseSSE42Intrinsics, with the default TRUE on systems that support >>> SSE4.2 (false otherwise). >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y >>> >>> Other testing: JPRT, >>> >>> > From vladimir.kozlov at sun.com Fri Feb 6 16:54:24 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Sat, 07 Feb 2009 00:54:24 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6791852: assert(b->_nodes[insidx] == n, "got insidx set incorrectly") Message-ID: <20090207005426.2DC1CD0E3@hg.openjdk.java.net> Changeset: 91263420e1c6 Author: kvn Date: 2009-02-06 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/91263420e1c6 6791852: assert(b->_nodes[insidx] == n,"got insidx set incorrectly") Summary: Move the CreateEx up before each round of IFG construction Reviewed-by: never, phh ! src/share/vm/opto/block.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/reg_split.cpp From Changpeng.Fang at Sun.COM Fri Feb 6 17:07:42 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Fri, 06 Feb 2009 17:07:42 -0800 Subject: Request for reviews (L): 6761600: Use SSE 4.2 In STTNI Intrinsics In-Reply-To: <1CBFFA46-1DDE-4AFC-BE9A-F7A1077809CE@sun.com> References: <496FD74F.9070009@sun.com> <498C6AE0.4010006@Sun.COM> <498C7FE0.5020200@sun.com> <498CBCB8.8060604@Sun.COM> <1CBFFA46-1DDE-4AFC-BE9A-F7A1077809CE@sun.com> Message-ID: <498CDEDE.5030408@Sun.COM> Tom Rodriguez wrote: > The string_indexOf triggering criteria in library_call.cpp seems wrong > since it skips the optimization for constant strings in preference for > the SSE4.2 version. The constant string seems like it should be > preferred shouldn't it? > I doubt about the constant string optimizations. I experiments on simple case shows even though both strings are constant, SSE4.2 version still performs better (It should not be the case). As a result, constant string optimizations for indexof may not be performed as expected. Would you please point out where is this constant optimization? Thanks, Changpeng. From Thomas.Rodriguez at Sun.COM Fri Feb 6 17:34:04 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 06 Feb 2009 17:34:04 -0800 Subject: Request for reviews (L): 6761600: Use SSE 4.2 In STTNI Intrinsics In-Reply-To: <498CDEDE.5030408@Sun.COM> References: <496FD74F.9070009@sun.com> <498C6AE0.4010006@Sun.COM> <498C7FE0.5020200@sun.com> <498CBCB8.8060604@Sun.COM> <1CBFFA46-1DDE-4AFC-BE9A-F7A1077809CE@sun.com> <498CDEDE.5030408@Sun.COM> Message-ID: <109FF820-AEB8-4FD5-88D4-7330BCA09A20@Sun.COM> On Feb 6, 2009, at 5:07 PM, Changpeng Fang wrote: > Tom Rodriguez wrote: >> The string_indexOf triggering criteria in library_call.cpp seems >> wrong since it skips the optimization for constant strings in >> preference for the SSE4.2 version. The constant string seems like >> it should be preferred shouldn't it? >> > I doubt about the constant string optimizations. I experiments on > simple case shows even though > both strings are constant, SSE4.2 version still performs better (It > should not be the case). As a result, > constant string optimizations for indexof may not be performed as > expected. > > Would you please point out where is this constant optimization? > Thanks, It's the existing LibraryCallKit::inline_string_indexOf implementation. It's only used if the argument is a constant string. If you've benchmarked it and it's always faster to use the SSE4.2 version that's fine. tom > > > Changpeng. From Thomas.Rodriguez at Sun.COM Fri Feb 6 17:40:46 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 06 Feb 2009 17:40:46 -0800 Subject: Request for reviews (L): 6761600: Use SSE 4.2 In STTNI Intrinsics In-Reply-To: <109FF820-AEB8-4FD5-88D4-7330BCA09A20@Sun.COM> References: <496FD74F.9070009@sun.com> <498C6AE0.4010006@Sun.COM> <498C7FE0.5020200@sun.com> <498CBCB8.8060604@Sun.COM> <1CBFFA46-1DDE-4AFC-BE9A-F7A1077809CE@sun.com> <498CDEDE.5030408@Sun.COM> <109FF820-AEB8-4FD5-88D4-7330BCA09A20@Sun.COM> Message-ID: >> Would you please point out where is this constant optimization? >> Thanks, > > It's the existing LibraryCallKit::inline_string_indexOf > implementation. It's only used if the argument is a constant > string. If you've benchmarked it and it's always faster to use the > SSE4.2 version that's fine. Actually it occurs to me that the new SSE4.2 indexOf is improperly gated on is_Con() // don't intrinsify is argument isn't a constant string. if (!argument->is_Con()) { return false; } This occurs near the top which means that the SSE4.2 version will never be used on non-constant strings even though it will work correctly with them. I think you need to rearrange the tests. tom > > > tom > >> >> >> Changpeng. > From Changpeng.Fang at Sun.COM Fri Feb 6 23:36:58 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Fri, 06 Feb 2009 23:36:58 -0800 Subject: Request for reviews (L): 6761600: Use SSE 4.2 In STTNI Intrinsics In-Reply-To: References: <496FD74F.9070009@sun.com> <498C6AE0.4010006@Sun.COM> <498C7FE0.5020200@sun.com> <498CBCB8.8060604@Sun.COM> <1CBFFA46-1DDE-4AFC-BE9A-F7A1077809CE@sun.com> <498CDEDE.5030408@Sun.COM> <109FF820-AEB8-4FD5-88D4-7330BCA09A20@Sun.COM> Message-ID: <498D3A1A.6050601@sun.com> Hello, Tom: Got it! I will rewrite inline_string_indexOf to make SSE4.2 version apply to both constant and non-constant strings. Again, for constant argument string, SSE4.2 version always outperforms the original one in library_call. cpp, at least according to my experiments. Thanks and Have a wonderful vacation! Changpeng Tom Rodriguez wrote: >>> Would you please point out where is this constant optimization? Thanks, >> >> It's the existing LibraryCallKit::inline_string_indexOf >> implementation. It's only used if the argument is a constant >> string. If you've benchmarked it and it's always faster to use the >> SSE4.2 version that's fine. > > Actually it occurs to me that the new SSE4.2 indexOf is improperly > gated on is_Con() > > // don't intrinsify is argument isn't a constant string. > if (!argument->is_Con()) { > return false; > } > > This occurs near the top which means that the SSE4.2 version will > never be used on non-constant strings even though it will work > correctly with them. I think you need to rearrange the tests. > > tom > >> >> >> tom >> >>> >>> >>> Changpeng. >> > From Changpeng.Fang at Sun.COM Tue Feb 10 11:46:01 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Tue, 10 Feb 2009 11:46:01 -0800 Subject: Request for reviews (L): 6761600: Use SSE 4.2 In STTNI Intrinsics In-Reply-To: <1CBFFA46-1DDE-4AFC-BE9A-F7A1077809CE@sun.com> References: <496FD74F.9070009@sun.com> <498C6AE0.4010006@Sun.COM> <498C7FE0.5020200@sun.com> <498CBCB8.8060604@Sun.COM> <1CBFFA46-1DDE-4AFC-BE9A-F7A1077809CE@sun.com> Message-ID: <4991D979.6090209@Sun.COM> The updated version of webrev has been posted at: http://cr.openjdk.java.net/~cfang/6761600/webrev.01 Tom Rodriguez wrote: > Why is UseSSE42Intrinsics conditional on supports_ht()? Isn't > supports_sse4_2() sufficient? Also the setting for UseSSE42Intrinsics > should take into account whether UseSSE >= 4 instead of having to test > for it everywhere with (UseSSE >= 4 && UseSSE42Intrinsics). Use supports_ht() and UseSSE >=4 to set UseSSE42Intrinsics. > In the ad file changes you don't need to force regXD6 and regXD7 for > temps. Declare them as regXD and use the TEMP effect instead of the > KILL effect. A TEMP is a synthetic input that interferes with the > other inputs but not the output. As long as the TEMP and the result > are different register classes then there's no problem. You should > also have different variants for UseSSE42Intrinsics and > !UseSSE42Intrinsics. The !UseSSE42Intrinsics don't use or need the > regXDs right? > Use TEMP effect instead of KILL effect for the two temporary xmm registers. > The string_indexOf triggering criteria in library_call.cpp seems wrong > since it skips the optimization for constant strings in preference for > the SSE4.2 version. The constant string seems like it should be > preferred shouldn't it? > Now String.indexOf SSE42 intrinsic could accept non-constant argument. > As an aside, when writing enc_class functions it's better to pass in > the operands instead of assuming the register usage in the enc_class > function, in the style of the enc_Array_Equals versions. It's also > nicer to have names for registers instead of just using raw register > names everywhere. This all makes it easier to read and easier to > change register assignments. These intrinsics end up using a lot of > bound registers because we don't have a way to express that the inputs > interfere with the output. Otherwise we could use unbound masks for > all these inputs and likely would generate better code. Someday I'll > add this feature. > > Note that the types mentioned in the enc_class declaration are > completely meaningless. They are ignored by the adlc since > enc_classes are handled like C macros, as as pure textual substitution. > I noticed that for the following case, tmp4Reg and resultReg turn out to be the same raw register (thus interfere each other): **rdx_RegI tmp4, rbx_RegI result** *+ Register tmp4Reg = as_Register($tmp4$$reg);* *+ Register resultReg = as_Register($result$$reg);* I am not sure whether result register can also be used as an temporary register in the intrinsic body, or not. > Otherwise this looks good to me. > Thanks, Changpeng > > tom > > On Feb 6, 2009, at 2:42 PM, Changpeng Fang wrote: > >> Thanks. I put the updated webrev in: >> http://cr.openjdk.java.net/~cfang/6761600/webrev/ >> >> and I am testing to adjust the masm.jccb stuff. >> >> Changpeng >> >> >> Vladimir Kozlov wrote: >>> Changpeng, >>> >>> Good work. >>> >>> src/cpu/x86/vm/assembler_x86.cpp: >>> Remove Macro NOT_LP64() around asserts in new instructions. >>> VM_Version::supports_sse4_2() should be checked on LP64 also >>> since not all 64-bits CPUs support it. >>> >>> >>> src/cpu/x86/vm/vm_version_x86_32.cpp: >>> src/cpu/x86/vm/vm_version_x86_64.cpp: >>> Remove UseUnalignedLoadStores check in the next code, >>> it is not needed and it is wrong to have it since it depends on >>> UseXMMForArrayCopy flag. The top check supports_sse4_2() && >>> supports_ht() >>> is enough for movdqu verification. >>> >>> + if(FLAG_IS_DEFAULT(UseSSE42Intrinsics) && >>> + UseUnalignedLoadStores){ //sse42 intrinsics depend on >>> movdqu >>> + UseSSE42Intrinsics = true; >>> } >>> >>> >>> In both x86_32.ad and x86_64.ad try to use short forward branches >>> masm.jccb() >>> starting from the bottom of the assembler code. Then try to use all >>> intrinsics with all flags variations and revert back to long jump >>> those branches >>> VM will complain about. >>> >>> >>> cpu/x86/vm/x86_32.ad: >>> align comments: >>> >>> ! masm.andl(rsi, 0xfffffff8); // rsi holds the vector count >>> ! masm.andl(rdi, 0x00000007); // rdi holds the tail count >>> >>> In enc_String_Equals() and enc_String_IndexOf() >>> use movptr() for value_offset. >>> >>> >>> src/share/vm/adlc/formssel.cpp: >>> Missing checks for AryEq. >>> >>> src/share/vm/classfile/vmSymbols.hpp: >>> Remove empty after indexOf_name since equals() also j.l.String method: >>> do_name( indexOf_name, "indexOf") >>> >>> >>> + do_intrinsic(_equals, java_lang_String, equals_name, >>> object_boolean_signature, F_R) >>> >>> >>> src/share/vm/opto/library_call.cpp: >>> Add that it because spec allow to specify NULL as argument: >>> + //should not do null check for argument for string_equals. >>> >>> Remove next line >>> + //argument = do_null_check(argument, T_OBJECT); >>> >>> Thanks, >>> Vladimir >>> >>> Changpeng Fang wrote: >>>> http://webrev.invokedynamic.info/cfang/6761600/index.html >>>> >>>> Works on 6761600 : Use SSE 4.2 in intrinsics for String.compareTo(), >>>> String.equals(), String.indexOf() and Arrays.equals(), among which, >>>> String.equals() and String.indexOf() are intrinsified for the first >>>> time. >>>> >>>> Problem: Use SSE 4.2 instructions for STTNI intrinsics for for Nehalem >>>> improvements >>>> >>>> Solution: >>>> Implemented both 32 and 64-bit versions for X86. Introduced a new >>>> flag UseSSE42Intrinsics, with the default TRUE on systems that >>>> support >>>> SSE4.2 (false otherwise). >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y >>>> >>>> Other testing: JPRT, >>>> >>>> >> > From Christian.Thalinger at Sun.COM Wed Feb 11 08:35:38 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 11 Feb 2009 17:35:38 +0100 Subject: SPARC: unsigned vs. signed int loads Message-ID: <1234370138.24951.41.camel@localhost.localdomain> Hi all! Still working on 6797305, I recently was looking (again) closer at the load instructions in sparc.ad and I noticed that byte and short loads do a sign extend (ldsb and ldsh) while int loads do not (lduw). In CACAO we did fully 64-bit signed extended loads on Alpha and SPARC64 so we could omit I2L conversions. Is there a reason why HotSpot does zero-extended int loads? -- Christian From Paul.Hohensee at Sun.COM Wed Feb 11 08:41:44 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 11 Feb 2009 11:41:44 -0500 Subject: SPARC: unsigned vs. signed int loads In-Reply-To: <1234370138.24951.41.camel@localhost.localdomain> References: <1234370138.24951.41.camel@localhost.localdomain> Message-ID: <4992FFC8.2030300@sun.com> Signed loads require a shifter or mux in the load path, so they can cost an extra cycle. I think we also use ldub for boolean loads. paul Christian Thalinger wrote: > Hi all! > > Still working on 6797305, I recently was looking (again) closer at the > load instructions in sparc.ad and I noticed that byte and short loads do > a sign extend (ldsb and ldsh) while int loads do not (lduw). > > In CACAO we did fully 64-bit signed extended loads on Alpha and SPARC64 > so we could omit I2L conversions. > > Is there a reason why HotSpot does zero-extended int loads? > > -- Christian > > From Christian.Thalinger at Sun.COM Wed Feb 11 09:02:13 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 11 Feb 2009 18:02:13 +0100 Subject: SPARC: unsigned vs. signed int loads In-Reply-To: <4992FFC8.2030300@sun.com> References: <1234370138.24951.41.camel@localhost.localdomain> <4992FFC8.2030300@sun.com> Message-ID: <1234371733.24951.44.camel@localhost.localdomain> On Wed, 2009-02-11 at 11:41 -0500, Paul Hohensee wrote: > Signed loads require a shifter or mux in the load path, so they can cost > an extra cycle. > > I think we also use ldub for boolean loads. Ahh, I see. So it seems that lduw is used to "optimize" the load, but that's not possible for byte and short loads because they have to be sign-extended and there is no ldsb-up-to-32-bit. But I doubt that would be faster than a shift to 64-bit. -- Christian From John.Rose at Sun.COM Wed Feb 11 11:56:36 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 11 Feb 2009 11:56:36 -0800 Subject: SPARC: unsigned vs. signed int loads In-Reply-To: <1234370138.24951.41.camel@localhost.localdomain> References: <1234370138.24951.41.camel@localhost.localdomain> Message-ID: On Feb 11, 2009, at 8:35 AM, Christian Thalinger wrote: > Is there a reason why HotSpot does zero-extended int loads? As Paul said there's a cycle savings on some systems--on SPARC. The register allocator is able to express "useful payload in low 32 bits, garbage in upper 32 bits", as a consequence of its using a 32- bit unit of storage uniformly. (The 64-bit registers are pairs of allocator units, on all CPUs.) This is the normal state for a C2 register on a mixed 32/64 system (i.e., SPARC V8plus). Intel systems are either all-32-bit or all-64-bit, so the distinction is less interesting here, I guess. -- John P.S. This touches on why 128-bit vectors are a tricky addition, as I pointed out earlier. From Christian.Thalinger at Sun.COM Thu Feb 12 08:55:59 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 12 Feb 2009 17:55:59 +0100 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: <1234457759.24951.390.camel@localhost.localdomain> On Tue, 2009-01-20 at 02:53 -0800, John Rose wrote: > Please give it a look. I have now reviewed all files. At least I tried to understand what's happening but methodHandles.{cpp,hpp} is too much, sorry. src/share/vm/classfile/classFileParser.cpp: ClassFileParser::java_dyn_MethodHandle_fix_pre() (*fields_ptr) is used 7 times, readability would be much better if that value would be assigned to a local variable. src/share/vm/oops/instanceKlass.cpp: instanceKlass::is_same_package_member_impl + klassOop next = outer1->compute_enclosing_class(ignore_name, CHECK_(false)); + klassOop next = outer2->compute_enclosing_class(ignore_name, CHECK_(false)); There is a define CHECK_false for CHECK_(false). src/share/vm/prims/methodHandles.cpp: void MethodHandles::set_enabled(bool z) { This method can also disable the method handle, right? Wouldn't it be clearer if there is a set_enabled() (or enable()) and a set_disabled() (disable()) method (without an argument)? Typo in line 538: // which refers dirctly to JVM internals. void MethodHandles::expand_MemberName(Handle mname, int suppress, TRAPS) { //Handle name = java_lang_String::create_from_symbol(m->name(), CHECK); Handle name = StringTable::intern(m->name(), CHECK); Is that intentional? -- Christian From John.Rose at Sun.COM Thu Feb 12 14:41:48 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 12 Feb 2009 14:41:48 -0800 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: <1234457759.24951.390.camel@localhost.localdomain> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <1234457759.24951.390.camel@localhost.localdomain> Message-ID: On Feb 12, 2009, at 8:55 AM, Christian Thalinger wrote: > On Tue, 2009-01-20 at 02:53 -0800, John Rose wrote: >> Please give it a look. > > I have now reviewed all files. At least I tried to understand what's > happening but methodHandles.{cpp,hpp} is too much, sorry. > > src/share/vm/classfile/classFileParser.cpp: > > ClassFileParser::java_dyn_MethodHandle_fix_pre() > > (*fields_ptr) is used 7 times, readability would be much better if > that > value would be assigned to a local variable. Yes, I wouldn't have done it that way, except that I'm following the lead of existing code (java_lang_ref_Reference_fix_pre). Shall we leave it as-is, or fix both? I could bind a local variable like this: typeArrayHandle& fields = (*fields_ptr); > src/share/vm/oops/instanceKlass.cpp: > > instanceKlass::is_same_package_member_impl > > + klassOop next = outer1->compute_enclosing_class(ignore_name, > CHECK_(false)); > + klassOop next = outer2->compute_enclosing_class(ignore_name, > CHECK_(false)); > > There is a define CHECK_false for CHECK_(false). Thanks. > src/share/vm/prims/methodHandles.cpp: > > void MethodHandles::set_enabled(bool z) { > > This method can also disable the method handle, right? Wouldn't it be > clearer if there is a set_enabled() (or enable()) and a set_disabled() > (disable()) method (without an argument)? This is a recurrent issue with boolean accessors. Hotspot internal APIs are strongly regular in their use of this pattern for property access: T foo(); void set_foo(T x); If T is bool, sometimes we have irregularity in the setter name: void set_foo(bool x); void set_is_foo(bool x); void set_has_foo(bool x); It is less common to split a boolean setter in two as you suggest: T is_foo(); void set_foo(); void clear_foo(); There are cases where the setting is a state transition, as with CompileTask::mark_complete with CT::is_complete. In such cases, there are two accessor functions, so the split seems natural. Some classes have the full three-way pattern, as with JavaThread::is_suspend_equivalent. That introduces three functions where two will do about as well. I guess I prefer not to use the three-way scheme, since it requires a little too much inventiveness in picking positive and negative versions of a property name (e.g., enable vs. disable, set vs. clear). It makes it harder for non-English-speakers to read the sources, and I'm thinking, of course, of /bin/grep. :-) I prefer the present formulation as simplest and most neutral in connotations. But if there's a strong reason to change it in this case, I'll do it. > Typo in line 538: > // which refers dirctly to JVM internals. Thanks. > void MethodHandles::expand_MemberName(Handle mname, int suppress, > TRAPS) { > > //Handle name = java_lang_String::create_from_symbol(m- > >name(), CHECK); > Handle name = StringTable::intern(m->name(), CHECK); > > Is that intentional? Yes. I'll comment it better. Thanks! -- John From Christian.Thalinger at Sun.COM Fri Feb 13 00:13:08 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 13 Feb 2009 09:13:08 +0100 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <1234457759.24951.390.camel@localhost.localdomain> Message-ID: <1234512788.24951.399.camel@localhost.localdomain> On Thu, 2009-02-12 at 14:41 -0800, John Rose wrote: > On Feb 12, 2009, at 8:55 AM, Christian Thalinger wrote: > > > On Tue, 2009-01-20 at 02:53 -0800, John Rose wrote: > >> Please give it a look. > > > > I have now reviewed all files. At least I tried to understand what's > > happening but methodHandles.{cpp,hpp} is too much, sorry. > > > > src/share/vm/classfile/classFileParser.cpp: > > > > ClassFileParser::java_dyn_MethodHandle_fix_pre() > > > > (*fields_ptr) is used 7 times, readability would be much better if > > that > > value would be assigned to a local variable. > > Yes, I wouldn't have done it that way, except that I'm following the > lead of existing code (java_lang_ref_Reference_fix_pre). Shall we > leave it as-is, or fix both? I could bind a local variable like this: > typeArrayHandle& fields = (*fields_ptr); I would fix both, but... > > src/share/vm/prims/methodHandles.cpp: > > > > void MethodHandles::set_enabled(bool z) { > > > > This method can also disable the method handle, right? Wouldn't it be > > clearer if there is a set_enabled() (or enable()) and a set_disabled() > > (disable()) method (without an argument)? > > This is a recurrent issue with boolean accessors. Hotspot internal > APIs are strongly regular in their use of this pattern for property > access: > T foo(); > void set_foo(T x); > > If T is bool, sometimes we have irregularity in the setter name: > void set_foo(bool x); > void set_is_foo(bool x); > void set_has_foo(bool x); > > It is less common to split a boolean setter in two as you suggest: > T is_foo(); > void set_foo(); > void clear_foo(); > > There are cases where the setting is a state transition, as with > CompileTask::mark_complete with CT::is_complete. In such cases, there > are two accessor functions, so the split seems natural. > > Some classes have the full three-way pattern, as with > JavaThread::is_suspend_equivalent. That introduces three functions > where two will do about as well. > > I guess I prefer not to use the three-way scheme, since it requires a > little too much inventiveness in picking positive and negative > versions of a property name (e.g., enable vs. disable, set vs. > clear). It makes it harder for non-English-speakers to read the > sources, and I'm thinking, of course, of /bin/grep. :-) > > I prefer the present formulation as simplest and most neutral in > connotations. But if there's a strong reason to change it in this > case, I'll do it. Not that I know of. I was just proposing. -- Christian From Christian.Thalinger at Sun.COM Fri Feb 13 05:50:35 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 13 Feb 2009 14:50:35 +0100 Subject: Request for review (XS): 6800154: Add comments to long_by_long_mulhi() for better understandability In-Reply-To: <1233771569.1536.19.camel@localhost.localdomain> References: <1233596422.3982.60.camel@localhost.localdomain> <1233771569.1536.19.camel@localhost.localdomain> Message-ID: <1234533035.6347.7.camel@localhost.localdomain> On Wed, 2009-02-04 at 19:19 +0100, Christian Thalinger wrote: > On Mon, 2009-02-02 at 18:40 +0100, Christian Thalinger wrote: > > http://webrev.invokedynamic.info/twisti/6800154/ > > I have uploaded a new version of the patch which includes a testcase. A last version of the patch: http://cr.openjdk.java.net/~twisti/6800154/webrev.00/ Only the test changed. Actually I wanted to integrate the test from Chuck Rasbold for 6603011 but I had problems with that. I try to move that test into the open. I think it's okay to push the changeset as the patch hasn't changed. -- Christian From Vladimir.Kozlov at Sun.COM Fri Feb 13 08:06:01 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 13 Feb 2009 08:06:01 -0800 Subject: Request for review (XS): 6800154: Add comments to long_by_long_mulhi() for better understandability In-Reply-To: <1234533035.6347.7.camel@localhost.localdomain> References: <1233596422.3982.60.camel@localhost.localdomain> <1233771569.1536.19.camel@localhost.localdomain> <1234533035.6347.7.camel@localhost.localdomain> Message-ID: <49959A69.7080803@sun.com> Looks good. What the problem with Chuck's test you have? To move a test to open I would create new directory test/compiler/6603011 for it and replace the copyright head in the test source. Vladimir Christian Thalinger wrote: > On Wed, 2009-02-04 at 19:19 +0100, Christian Thalinger wrote: >> On Mon, 2009-02-02 at 18:40 +0100, Christian Thalinger wrote: >>> http://webrev.invokedynamic.info/twisti/6800154/ >> I have uploaded a new version of the patch which includes a testcase. > > A last version of the patch: > > http://cr.openjdk.java.net/~twisti/6800154/webrev.00/ > > Only the test changed. Actually I wanted to integrate the test from > Chuck Rasbold for 6603011 but I had problems with that. I try to move > that test into the open. > > I think it's okay to push the changeset as the patch hasn't changed. > > -- Christian > From Christian.Thalinger at Sun.COM Fri Feb 13 08:15:19 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 13 Feb 2009 17:15:19 +0100 Subject: Request for review (XS): 6800154: Add comments to long_by_long_mulhi() for better understandability In-Reply-To: <49959A69.7080803@sun.com> References: <1233596422.3982.60.camel@localhost.localdomain> <1233771569.1536.19.camel@localhost.localdomain> <1234533035.6347.7.camel@localhost.localdomain> <49959A69.7080803@sun.com> Message-ID: <1234541719.6347.15.camel@localhost.localdomain> On Fri, 2009-02-13 at 08:06 -0800, Vladimir Kozlov wrote: > Looks good. > > What the problem with Chuck's test you have? It didn't work for some corner-cases I wanted to add and I didn't want to spend too much time on it. > > To move a test to open I would create new > directory test/compiler/6603011 for it and replace > the copyright head in the test source. Under what CR should I commit it? -- Christian From Vladimir.Kozlov at Sun.COM Fri Feb 13 08:34:34 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 13 Feb 2009 08:34:34 -0800 Subject: Request for review (XS): 6800154: Add comments to long_by_long_mulhi() for better understandability In-Reply-To: <1234541719.6347.15.camel@localhost.localdomain> References: <1233596422.3982.60.camel@localhost.localdomain> <1233771569.1536.19.camel@localhost.localdomain> <1234533035.6347.7.camel@localhost.localdomain> <49959A69.7080803@sun.com> <1234541719.6347.15.camel@localhost.localdomain> Message-ID: <4995A11A.8040602@sun.com> Why not to add it to this push (6800154)? In the bug report (6800154) add a comment to explain what you did with the test. I think it should be enough. Vladimir Christian Thalinger wrote: > On Fri, 2009-02-13 at 08:06 -0800, Vladimir Kozlov wrote: >> Looks good. >> >> What the problem with Chuck's test you have? > > It didn't work for some corner-cases I wanted to add and I didn't want > to spend too much time on it. > >> To move a test to open I would create new >> directory test/compiler/6603011 for it and replace >> the copyright head in the test source. > > Under what CR should I commit it? > > -- Christian > From Christian.Thalinger at Sun.COM Fri Feb 13 08:39:28 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 13 Feb 2009 17:39:28 +0100 Subject: Request for review (XS): 6800154: Add comments to long_by_long_mulhi() for better understandability In-Reply-To: <4995A11A.8040602@sun.com> References: <1233596422.3982.60.camel@localhost.localdomain> <1233771569.1536.19.camel@localhost.localdomain> <1234533035.6347.7.camel@localhost.localdomain> <49959A69.7080803@sun.com> <1234541719.6347.15.camel@localhost.localdomain> <4995A11A.8040602@sun.com> Message-ID: <1234543168.6347.16.camel@localhost.localdomain> On Fri, 2009-02-13 at 08:34 -0800, Vladimir Kozlov wrote: > Why not to add it to this push (6800154)? > > In the bug report (6800154) add a comment to explain > what you did with the test. I think it should be enough. Great! I will add it and push it. -- Christian From John.Rose at Sun.COM Fri Feb 13 12:28:31 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 13 Feb 2009 12:28:31 -0800 Subject: for review (XXL): 6655638 method handles for invokedynamic In-Reply-To: <1234512788.24951.399.camel@localhost.localdomain> References: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> <1234457759.24951.390.camel@localhost.localdomain> <1234512788.24951.399.camel@localhost.localdomain> Message-ID: On Feb 13, 2009, at 12:13 AM, Christian Thalinger wrote: > On Thu, 2009-02-12 at 14:41 -0800, John Rose wrote: >> Yes, I wouldn't have done it that way, except that I'm following the >> lead of existing code (java_lang_ref_Reference_fix_pre). Shall we >> leave it as-is, or fix both? I could bind a local variable like >> this: >> typeArrayHandle& fields = (*fields_ptr); > > I would fix both, but... I'll fix both, but back out if someone complains. In general, I try to apply cleanups as I go through the code, but if I'm not touching a method at all I won't go into it just for cleanups. This is a marginal case; I'll do it. I recommend this policy for cleanups for the team in general, since (a) the code is mature and therefore has lots of oddities to improve, yet (b) we don't want to risk needless merge conficts by primping otherwise unchanged lines. At this point I know I'm inviting a whole new thread of conversation. So, having gotten the attention of code artistes like me, I'll direct you here: http://wikis.sun.com/display/HotSpotInternals/StyleGuide >> I prefer the present formulation as simplest and most neutral in >> connotations. But if there's a strong reason to change it in this >> case, I'll do it. > > Not that I know of. I was just proposing. Part of growing a hotspot coder community is making explicit and public what has been implicit and/or Sun-internal so far. Such suggestions help to do so... Thanks, -- John From Christian.Thalinger at Sun.COM Mon Feb 16 02:58:54 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 16 Feb 2009 11:58:54 +0100 Subject: Request for review (S): 6805724: ModLNode::Ideal() generates functionally incorrect graph when divisor is any (2^k-1) constant. Message-ID: <1234781934.11228.7.camel@localhost.localdomain> http://cr.openjdk.java.net/~twisti/6805724/webrev.00/ From Christian.Thalinger at Sun.COM Mon Feb 16 03:30:12 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 16 Feb 2009 11:30:12 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6800154: Add comments to long_by_long_mulhi() for better understandability Message-ID: <20090216113014.57D1AD904@hg.openjdk.java.net> Changeset: bbef4344adb2 Author: twisti Date: 2009-02-13 09:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bbef4344adb2 6800154: Add comments to long_by_long_mulhi() for better understandability Summary: This patch adds a comment pointing to the Hacker's Delight version of the algorithm plus a verbatim copy of it. Furthermore it adds inline comments. Reviewed-by: kvn, jrose ! src/share/vm/opto/divnode.cpp + test/compiler/6603011/Test.java + test/compiler/6800154/Test6800154.java From john.coomes at sun.com Mon Feb 16 03:32:52 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 16 Feb 2009 11:32:52 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b47 for changeset d7744e86dedc Message-ID: <20090216113252.4943DD90B@hg.openjdk.java.net> Changeset: 4ae9f4bfdb98 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/4ae9f4bfdb98 Added tag jdk7-b47 for changeset d7744e86dedc ! .hgtags From john.coomes at sun.com Mon Feb 16 03:35:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 16 Feb 2009 11:35:21 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b47 for changeset 167ad0164301 Message-ID: <20090216113523.351C4D910@hg.openjdk.java.net> Changeset: 0be222241fd4 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/0be222241fd4 Added tag jdk7-b47 for changeset 167ad0164301 ! .hgtags From john.coomes at sun.com Mon Feb 16 03:38:17 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 16 Feb 2009 11:38:17 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b47 for changeset d711ad1954b2 Message-ID: <20090216113820.4FE71D915@hg.openjdk.java.net> Changeset: 39de90eb4822 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/39de90eb4822 Added tag jdk7-b47 for changeset d711ad1954b2 ! .hgtags From john.coomes at sun.com Mon Feb 16 03:40:52 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 16 Feb 2009 11:40:52 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b47 for changeset 223011570edb Message-ID: <20090216114054.7720CD91A@hg.openjdk.java.net> Changeset: 01e5dd31d0c1 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/01e5dd31d0c1 Added tag jdk7-b47 for changeset 223011570edb ! .hgtags From john.coomes at sun.com Mon Feb 16 03:43:28 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 16 Feb 2009 11:43:28 +0000 Subject: hg: jdk7/hotspot-comp/jdk: Added tag jdk7-b47 for changeset b4ac413b1f12 Message-ID: <20090216114406.D7E86D91F@hg.openjdk.java.net> Changeset: 2ab03c2f814b Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2ab03c2f814b Added tag jdk7-b47 for changeset b4ac413b1f12 ! .hgtags From john.coomes at sun.com Mon Feb 16 03:47:28 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 16 Feb 2009 11:47:28 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b47 for changeset 2b8f6bab2392 Message-ID: <20090216114732.37612D924@hg.openjdk.java.net> Changeset: fedc96614330 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/fedc96614330 Added tag jdk7-b47 for changeset 2b8f6bab2392 ! .hgtags From Christian.Thalinger at Sun.COM Mon Feb 16 05:11:16 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 16 Feb 2009 14:11:16 +0100 Subject: Request for review (XS): 6805950: Typos in andL_rReg_imm instructions in x86_64.ad Message-ID: <1234789876.11228.8.camel@localhost.localdomain> http://cr.openjdk.java.net/~twisti/6805950/webrev.00/ From Christian.Thalinger at Sun.COM Mon Feb 16 07:14:05 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 16 Feb 2009 16:14:05 +0100 Subject: Request for review (S): 6805724: ModLNode::Ideal() generates functionally incorrect graph when divisor is any (2^k-1) constant. In-Reply-To: <4149a0430902160548r7fd41bd6y3d8026a0e2671eaa@mail.gmail.com> References: <1234781934.11228.7.camel@localhost.localdomain> <4149a0430902160548r7fd41bd6y3d8026a0e2671eaa@mail.gmail.com> Message-ID: <1234797245.11228.10.camel@localhost.localdomain> [Replying to the list just for the record.] On Mon, 2009-02-16 at 05:48 -0800, Chuck Rasbold wrote: > Looks good. > > On Mon, Feb 16, 2009 at 2:58 AM, Christian Thalinger > wrote: > > http://cr.openjdk.java.net/~twisti/6805724/webrev.00/ > > > > From Christian.Thalinger at Sun.COM Mon Feb 16 10:39:03 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 16 Feb 2009 18:39:03 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6805724: ModLNode::Ideal() generates functionally incorrect graph when divisor is any (2^k-1) constant. Message-ID: <20090216183909.41D80DA0A@hg.openjdk.java.net> Changeset: 30663ca5e8f4 Author: twisti Date: 2009-02-16 07:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/30663ca5e8f4 6805724: ModLNode::Ideal() generates functionally incorrect graph when divisor is any (2^k-1) constant. Summary: C2, ModLNode::Ideal() generates functionally incorrect graph when divisor is any (2^k-1) constant. Reviewed-by: rasbold ! src/share/vm/opto/divnode.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/compiler/6805724/Test6805724.java From Vladimir.Kozlov at Sun.COM Mon Feb 16 13:35:14 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 16 Feb 2009 13:35:14 -0800 Subject: Request for review (S): 6805724: ModLNode::Ideal() generates functionally incorrect graph when divisor is any (2^k-1) constant. In-Reply-To: <1234781934.11228.7.camel@localhost.localdomain> References: <1234781934.11228.7.camel@localhost.localdomain> Message-ID: <4999DC12.7090108@sun.com> Looks good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6805724/webrev.00/ > From Vladimir.Kozlov at Sun.COM Mon Feb 16 13:37:32 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 16 Feb 2009 13:37:32 -0800 Subject: Request for review (XS): 6805950: Typos in andL_rReg_imm instructions in x86_64.ad In-Reply-To: <1234789876.11228.8.camel@localhost.localdomain> References: <1234789876.11228.8.camel@localhost.localdomain> Message-ID: <4999DC9C.4000306@sun.com> Looks good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6805950/webrev.00/ > From Christian.Thalinger at Sun.COM Tue Feb 17 05:41:19 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 17 Feb 2009 13:41:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6805950: Typos in andL_rReg_imm instructions in x86_64.ad Message-ID: <20090217134124.06F37DA69@hg.openjdk.java.net> Changeset: 2cacccded90f Author: twisti Date: 2009-02-17 11:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2cacccded90f 6805950: Typos in andL_rReg_imm instructions in x86_64.ad Summary: There are two typos in andL_rReg_imm instructions in x86_64.ad. Reviewed-by: kvn ! src/cpu/x86/vm/x86_64.ad From vladimir.kozlov at sun.com Tue Feb 17 18:58:28 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 18 Feb 2009 02:58:28 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 40 new changesets Message-ID: <20090218025947.DE5A0DAF1@hg.openjdk.java.net> Changeset: dabd8d202164 Author: coleenp Date: 2008-12-23 06:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dabd8d202164 4997835: RFE: crash dump will only be created when running w/ -XX:+ShowMessageBoxOnError Summary: Using UseOSErrorReporting will provide both an hs_err file and a crash dump or debug launch and works better. Reviewed-by: xlu, acorn, poonam ! src/share/vm/utilities/vmError.cpp Changeset: db4caa99ef11 Author: xlu Date: 2008-12-24 13:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/db4caa99ef11 6787106: Hotspot 32 bit build fails on platforms having different definitions for intptr_t & int32_t Summary: Avoid casting between int32_t and intptr_t specifically for MasmAssembler::movptr in 32 bit platforms. Reviewed-by: jrose, kvn ! 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_32.hpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_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/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp Changeset: 2328d1d3f8cf Author: xlu Date: 2008-12-24 19:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2328d1d3f8cf 6781583: Hotspot build fails on linux 64 bit platform with gcc 4.3.2 Summary: Fixed the wrong cast between types since more restrictions are imposed by gcc 4.3.2 Reviewed-by: jcoomes, acorn, phh, never ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/os/linux/vm/os_linux.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/libadt/port.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/vmError.hpp Changeset: c81d2ef51ca3 Author: acorn Date: 2009-01-05 13:44 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c81d2ef51ca3 4670071: loadClassInternal is too restrictive. Summary: VM support for deadlock fix. Library fix in 4735126. See API proposal. Reviewed-by: dholmes, blacklion ! 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/runtime/globals.hpp Changeset: a0401dc51d0b Author: acorn Date: 2009-01-08 16:27 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a0401dc51d0b 6791656: nsk defclass0 asserts handles.hpp Reviewed-by: phh, xlu ! src/share/vm/classfile/systemDictionary.cpp Changeset: fc7ab6287598 Author: coleenp Date: 2009-01-09 14:39 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fc7ab6287598 Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/oops/constantPoolOop.cpp Changeset: e9be0e04635a Author: jmasa Date: 2009-01-06 07:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e9be0e04635a 6689653: JMapPerm fails with UseConcMarkSweepIncGC and compressed oops off Summary: Added safe_object_iterate() for use by JMapPerm. Reviewed-by: tonyp ! 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/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.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/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/services/heapDumper.cpp Changeset: 0af8b0718fc9 Author: jmasa Date: 2009-01-11 16:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0af8b0718fc9 6692899: CMS: many vm.parallel_class_loading tests fail with assert "missing Printezis mark" Summary: The CMS concurrent precleaning and concurrent marking phases should work around classes that are undergoing redefinition. Reviewed-by: ysr, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/space.cpp ! 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.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/prims/jvmtiRedefineClasses.cpp Changeset: 65de26b5ea82 Author: jcoomes Date: 2009-01-14 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/65de26b5ea82 Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 52a431267315 Author: coleenp Date: 2009-01-13 14:41 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/52a431267315 6791168: Fix invalid code in bytecodeInterpreter that can cause gcc ICE Summary: Fix compilation errors from latest gcc in CC_INTERP including offending missing void* cast. Reviewed-by: xlu ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp Changeset: 4db4e58c16bd Author: xlu Date: 2009-01-13 12:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4db4e58c16bd 6791815: Fix for 6471657 can cause deadlock on non-Solaris platforms when initializing direct buffer support Summary: Place the state transition inside the loop so that the VMThread could proceed for safepoint Reviewed-by: dholmes, never, acorn ! src/share/vm/prims/jni.cpp Changeset: 9250583801d2 Author: xlu Date: 2009-01-13 12:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9250583801d2 Merge Changeset: 2ddbaf7b8e1c Author: xlu Date: 2009-01-13 14:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2ddbaf7b8e1c Merge Changeset: c9004fe53695 Author: xlu Date: 2009-01-13 17:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c9004fe53695 6792301: StackAlignmentInBytes not honored for compiled native methods Summary: Fixed the stack misalignment when generate_native_wrapper is called. Reviewed-by: never, kamg, kvn, phh ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: f6c0827e5919 Author: coleenp Date: 2009-01-15 12:44 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f6c0827e5919 Merge Changeset: 818efdefcc99 Author: tonyp Date: 2009-01-16 13:02 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/818efdefcc99 6484956: G1: improve evacuation pause efficiency Summary: A bunch of performance optimizations to decrease GC pause times in G1. Reviewed-by: apetrusenko, jmasa, iveresov ! 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/g1OopClosures.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/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_shared Changeset: 2b1de1db9a9d Author: jcoomes Date: 2009-01-21 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2b1de1db9a9d Merge Changeset: 37b3ca071522 Author: coleenp Date: 2009-01-14 20:14 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/37b3ca071522 6793825: Missing include dependancies for GCC without predefined headers Summary: With predefined headers off for gcc, some .inline.hpp files aren't included to make definition visible for inline functions Reviewed-by: jcoomes, xlu ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_parNew ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features Changeset: 8db2b3e46c38 Author: swamyv Date: 2009-01-14 19:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8db2b3e46c38 6786948: SA on core file fails on solaris-amd64 if vm started with -XX:+StartAttachListener Reviewed-by: jjh, dcubed ! agent/src/os/linux/ps_core.c ! agent/src/os/solaris/proc/saproc.cpp Changeset: fc14734c5aec Author: swamyv Date: 2009-01-15 13:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fc14734c5aec Merge Changeset: 40ee984935b9 Author: phh Date: 2009-01-21 11:14 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/40ee984935b9 6792705: Add JAR file to bootclasspath when using AggressiveOpts Summary: During argument processing, add alt-rt.jar to the bootclasspath between bootclasspath/p and default elements. Reviewed-by: xlu, coleenp ! src/share/vm/runtime/arguments.cpp Changeset: 99c597293e35 Author: coleenp Date: 2009-01-23 10:41 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/99c597293e35 Merge ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: dc3ad84615cf Author: xlu Date: 2009-01-26 12:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dc3ad84615cf 6795913: A few remaining wrong casts need to be fixed for building hotspot successfully on Mac OS. Summary: Use NULL_WORD in the places where intptr_t is expected due to incompatible types between intptr_t & int32_t Reviewed-by: phh, coleenp, never ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp Changeset: 5cfd8d19e546 Author: ysr Date: 2009-01-26 12:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5cfd8d19e546 6786503: Overflow list performance can be improved Summary: Avoid overflow list walk in CMS & ParNew when it is unnecessary. Fix a couple of correctness issues, including a C-heap leak, in ParNew at the intersection of promotion failure, work queue overflow and object array chunking. Add stress testing option and related assertion checking. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_parNew ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4e400c36026f Author: iveresov Date: 2009-01-27 18:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4e400c36026f 6783381: NUMA allocator: don't pretouch eden space with UseNUMA Summary: Moved pretouching to MutableSpace. Also MutableSpace now turns on page interleaving for the region it covers. Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.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/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 Changeset: 5b39c489c39d Author: ysr Date: 2009-01-29 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5b39c489c39d Merge ! src/share/vm/gc_implementation/includeDB_gc_parNew Changeset: 809e899c638b Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/809e899c638b Added tag jdk7-b43 for changeset fc6a5ae3fef5 ! .hgtags Changeset: 945bf7540697 Author: xdono Date: 2009-01-22 14:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/945bf7540697 Added tag jdk7-b44 for changeset 809e899c638b ! .hgtags Changeset: 16bb38eeda35 Author: xdono Date: 2009-01-29 13:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/16bb38eeda35 Added tag jdk7-b45 for changeset 945bf7540697 ! .hgtags Changeset: 3f844a28c5f4 Author: trims Date: 2009-01-30 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3f844a28c5f4 Merge Changeset: 23673011938d Author: ysr Date: 2009-01-30 14:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/23673011938d 6787254: Work queue capacity can be increased substantially on some platforms Summary: Increased the default and maximum size of the CMS marking stack and the size of the parallel workers' work queues in 64-bit mode. The latter was accomplished by an increase in the width of the Taskqueue's Age struct and its Tag field in 64-bit mode. Reviewed-by: jmasa, tonyp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 9a25e0c45327 Author: jmasa Date: 2009-01-31 00:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9a25e0c45327 6792421: assert(_bitMap->isMarked(addr+size-1),inconsistent Printezis mark) Summary: The CMS concurrent precleaning and concurrent marking phases should work around classes that are undergoing redefinition. Reviewed-by: ysr, tonyp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/cpCacheOop.hpp Changeset: a268411445d9 Author: ysr Date: 2009-02-04 15:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a268411445d9 Merge Changeset: 82a980778b92 Author: never Date: 2009-02-05 11:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/82a980778b92 6793828: G1: invariant: queues are empty when activated Reviewed-by: jrose, kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/memnode.cpp Changeset: 58054a18d735 Author: apetrusenko Date: 2009-02-06 01:38 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/58054a18d735 6484959: G1: introduce survivor spaces 6797754: G1: combined bugfix Summary: Implemented a policy to control G1 survivor space parameters. Reviewed-by: tonyp, iveresov ! 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/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/gc_implementation/shared/ageTable.hpp Changeset: 05c6d52fa7a9 Author: jmasa Date: 2009-02-08 13:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/05c6d52fa7a9 6690928: Use spinning in combination with yields for workstealing termination. Summary: Substitute a spin loop for most calls to yield() to reduce the stress on the system. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 1e458753107d Author: apetrusenko Date: 2009-02-09 17:33 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1e458753107d 6802413: G1: G1FixedSurvivorSpaceSize should be converted into regions in calculate_survivors_policy() Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 773234c55e8c Author: ysr Date: 2009-02-09 12:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/773234c55e8c 6800586: -XX:+PrintGCDateStamps is using mt-unsafe localtime function Summary: replaced localtime() with localtime_r() on Solaris and Linux. Reviewed-by: apetrusenko, dholmes, jmasa ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: fe3d7c11b4b7 Author: apetrusenko Date: 2009-02-10 18:39 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fe3d7c11b4b7 6700941: G1: allocation spec missing for some G1 classes Reviewed-by: tonyp ! 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/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/utilities/workgroup.hpp Changeset: dca06e7f503d Author: kvn Date: 2009-02-17 14:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dca06e7f503d Merge ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/globalDefinitions.hpp From Thomas.Rodriguez at Sun.COM Tue Feb 17 20:11:34 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 17 Feb 2009 20:11:34 -0800 Subject: SPARC: unsigned vs. signed int loads In-Reply-To: <4992FFC8.2030300@sun.com> References: <1234370138.24951.41.camel@localhost.localdomain> <4992FFC8.2030300@sun.com> Message-ID: <267636E9-FFD7-4F1E-8B56-CCE8CF8C7F1F@sun.com> On Feb 11, 2009, at 8:41 AM, Paul Hohensee wrote: > Signed loads require a shifter or mux in the load path, so they can > cost an extra cycle. > > I think we also use ldub for boolean loads. We don't but we should. A LoadB variant with a lower cost and this predicate: predicate(n->bottom_type() == TypeInt::BOOL); would work great. tom > > > paul > > Christian Thalinger wrote: >> Hi all! >> >> Still working on 6797305, I recently was looking (again) closer at >> the >> load instructions in sparc.ad and I noticed that byte and short >> loads do >> a sign extend (ldsb and ldsh) while int loads do not (lduw). >> >> In CACAO we did fully 64-bit signed extended loads on Alpha and >> SPARC64 >> so we could omit I2L conversions. >> >> Is there a reason why HotSpot does zero-extended int loads? >> >> -- Christian >> >> From John.Rose at Sun.COM Tue Feb 17 20:38:34 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 17 Feb 2009 20:38:34 -0800 Subject: SPARC: unsigned vs. signed int loads In-Reply-To: <267636E9-FFD7-4F1E-8B56-CCE8CF8C7F1F@sun.com> References: <1234370138.24951.41.camel@localhost.localdomain> <4992FFC8.2030300@sun.com> <267636E9-FFD7-4F1E-8B56-CCE8CF8C7F1F@sun.com> Message-ID: <09E901DD-9ED0-4BAD-A326-F16BB737AEE0@sun.com> On Feb 17, 2009, at 8:11 PM, Tom Rodriguez wrote: > > predicate(n->bottom_type() == TypeInt::BOOL); > Or more generally, n->bottom_type()->as_int()->_lo >= 0. -- John From Christian.Thalinger at Sun.COM Tue Feb 17 23:51:56 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 18 Feb 2009 08:51:56 +0100 Subject: SPARC: unsigned vs. signed int loads In-Reply-To: <09E901DD-9ED0-4BAD-A326-F16BB737AEE0@sun.com> References: <1234370138.24951.41.camel@localhost.localdomain> <4992FFC8.2030300@sun.com> <267636E9-FFD7-4F1E-8B56-CCE8CF8C7F1F@sun.com> <09E901DD-9ED0-4BAD-A326-F16BB737AEE0@sun.com> Message-ID: <1234943516.5094.5.camel@localhost.localdomain> On Tue, 2009-02-17 at 20:38 -0800, John Rose wrote: > On Feb 17, 2009, at 8:11 PM, Tom Rodriguez wrote: > > > > predicate(n->bottom_type() == TypeInt::BOOL); > > > > Or more generally, n->bottom_type()->as_int()->_lo >= 0. Sorry, I don't understand. What does this predicate (or both) check for? And where should it be, in loadB or loadUB? -- Christian From John.Rose at Sun.COM Wed Feb 18 00:50:09 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 18 Feb 2009 00:50:09 -0800 Subject: SPARC: unsigned vs. signed int loads In-Reply-To: <1234943516.5094.5.camel@localhost.localdomain> References: <1234370138.24951.41.camel@localhost.localdomain> <4992FFC8.2030300@sun.com> <267636E9-FFD7-4F1E-8B56-CCE8CF8C7F1F@sun.com> <09E901DD-9ED0-4BAD-A326-F16BB737AEE0@sun.com> <1234943516.5094.5.camel@localhost.localdomain> Message-ID: On Feb 17, 2009, at 11:51 PM, Christian Thalinger wrote: >> Or more generally, n->bottom_type()->as_int()->_lo >= 0. > > Sorry, I don't understand. What does this predicate (or both) check > for? And where should it be, in loadB or loadUB? In practice, the only types the LoadB node will have are [-128..127] and [0..1], in which case bottom_type() == TypeInt::BOOL works just fine. But here are some of the interesting details behind that predicate: A TypeInt (from opto/type.hpp) has _hi and _lo fields, which give the inclusive bounds to that type. If TypeInt::_lo >= 0, then the type has no negative values, and hence does not need sign extension. If you are loading a byte, you also need to check that TypeInt::_hi < 128. Finally, the sketch above is incomplete, since the bottom_type in general will need to be tested whether it is in fact a TypeInt, using isa_int. A local subroutine within the AD file could work: // t is an int type, positive, and fits in the given # of bits without overflow static bool is_positive(const Type* t, int bits) { const TypeInt* ti = t->isa_int(); return ti != NULL && ti->_lo >= 0 && ((-1 << (bits-1)) & ti->_hi) == 0; } If the type of a load matches that predicate, then you know that the high-order bit is zero, and loadB can be strength-reduced to loadUB. That's the explanation. -- John From Thomas.Rodriguez at Sun.COM Wed Feb 18 11:16:06 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 18 Feb 2009 11:16:06 -0800 Subject: SPARC: unsigned vs. signed int loads In-Reply-To: <1234943516.5094.5.camel@localhost.localdomain> References: <1234370138.24951.41.camel@localhost.localdomain> <4992FFC8.2030300@sun.com> <267636E9-FFD7-4F1E-8B56-CCE8CF8C7F1F@sun.com> <09E901DD-9ED0-4BAD-A326-F16BB737AEE0@sun.com> <1234943516.5094.5.camel@localhost.localdomain> Message-ID: <91E8CB76-4642-47D7-9407-51B0739D3E31@Sun.COM> Actually once we have LoadUBNode then all T_BOOLEAN loads should be emitting those directly instead of relying ad tricks. tom On Feb 17, 2009, at 11:51 PM, Christian Thalinger wrote: > On Tue, 2009-02-17 at 20:38 -0800, John Rose wrote: >> On Feb 17, 2009, at 8:11 PM, Tom Rodriguez wrote: >>> >>> predicate(n->bottom_type() == TypeInt::BOOL); >>> >> >> Or more generally, n->bottom_type()->as_int()->_lo >= 0. > > Sorry, I don't understand. What does this predicate (or both) check > for? And where should it be, in loadB or loadUB? > > -- Christian > From Vladimir.Kozlov at Sun.COM Wed Feb 18 12:13:03 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 18 Feb 2009 12:13:03 -0800 Subject: Request for reviews (XS): 6807084: AutoBox elimination is broken with compressed oops Message-ID: <499C6BCF.7010904@sun.com> http://cr.openjdk.java.net/~kvn/6807084/webrev.00 Fixed 6807084: AutoBox elimination is broken with compressed oops Problem: AutoBox elimination code looks for an Integer object load from AutoBox cache array in ideal graph and expects LoadP nodes. With compressed oops it gets DecodeN( LoadN ) instead of LoadP and bails out. Solution: Add checks for DecodeN nodes into AutoBox elimination code. Reviewed by: Fix verified (y/n): y, generated code Other testing: JPRT, CTW (with -XX:+UseCompressedOops -XX:+AggressiveOpts) From Thomas.Rodriguez at Sun.COM Wed Feb 18 13:24:15 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 18 Feb 2009 13:24:15 -0800 Subject: Request for reviews (XS): 6807084: AutoBox elimination is broken with compressed oops In-Reply-To: <499C6BCF.7010904@sun.com> References: <499C6BCF.7010904@sun.com> Message-ID: <535CCD9F-ABC0-4E0A-934B-4EC4421B64AC@sun.com> Looks ok. tom On Feb 18, 2009, at 12:13 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6807084/webrev.00 > > Fixed 6807084: AutoBox elimination is broken with compressed oops > > Problem: > AutoBox elimination code looks for an Integer object load from > AutoBox cache array in ideal graph and expects LoadP nodes. > With compressed oops it gets DecodeN( LoadN ) instead of LoadP > and bails out. > > Solution: > Add checks for DecodeN nodes into AutoBox elimination code. > > Reviewed by: > > Fix verified (y/n): y, generated code > > Other testing: > JPRT, CTW (with -XX:+UseCompressedOops -XX:+AggressiveOpts) > From Vladimir.Kozlov at Sun.COM Wed Feb 18 15:04:33 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 18 Feb 2009 15:04:33 -0800 Subject: Request for reviews (S): 6791572: assert("duplicating node that's already been matched") Message-ID: <499C9401.90108@sun.com> http://cr.openjdk.java.net/~kvn/6791572/webrev.00 Fixed 6791572: assert("duplicating node that's already been matched") Problem: AddP, LShiftX nodes and their inputs are marked as visited on x86 during the first address expression processing. AddP, LShiftX inputs will be not marked as shared since AddP, LShiftX will be marked as shared first. And this causes the problem since after AddP, LShiftX are folded into address expressions their inputs will be shared by several address expressions. Solution: Delay marking nodes as visited if they are inputs to an address expression. Reviewed by: Fix verified (y/n): y, test case Other testing: JPRT From vladimir.kozlov at sun.com Wed Feb 18 17:24:25 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 19 Feb 2009 01:24:25 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6807084: AutoBox elimination is broken with compressed oops Message-ID: <20090219012431.47E8EDB77@hg.openjdk.java.net> Changeset: 5d75ab5f6698 Author: kvn Date: 2009-02-18 13:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5d75ab5f6698 6807084: AutoBox elimination is broken with compressed oops Summary: Add checks for DecodeN nodes into AutoBox elimination code. Reviewed-by: never ! src/share/vm/opto/memnode.cpp From Vladimir.Kozlov at Sun.COM Wed Feb 18 18:50:29 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 18 Feb 2009 18:50:29 -0800 Subject: Request for reviews (S): 6802499: EA: assert(false,"unknown node on this path") Message-ID: <499CC8F5.1060904@sun.com> http://cr.openjdk.java.net/~kvn/6802499/webrev.00 Fixed 6802499: EA: assert(false,"unknown node on this path") Problem: Escape analysis code miss checks for SCMemProj node when working memory edges. Solution: Add missing checks for SCMemProj node. Note: object should not be scalar replaceable if a LoadStore node access its field, the corresponding check done during ConnectionGraph construction. Reviewed by: Fix verified (y/n): y, test case Other testing: JPRT, CTW (with -XX:+DoEscapeAnalysis) From Thomas.Rodriguez at Sun.COM Thu Feb 19 15:51:13 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 19 Feb 2009 15:51:13 -0800 Subject: Request for reviews (S): 6802499: EA: assert(false,"unknown node on this path") In-Reply-To: <499CC8F5.1060904@sun.com> References: <499CC8F5.1060904@sun.com> Message-ID: <860819C8-39C9-4BA4-8867-CF4961C51EBB@sun.com> Looks good. tom On Feb 18, 2009, at 6:50 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6802499/webrev.00 > > Fixed 6802499: EA: assert(false,"unknown node on this path") > > Problem: > Escape analysis code miss checks for SCMemProj node > when working memory edges. > > Solution: > Add missing checks for SCMemProj node. > > Note: object should not be scalar replaceable if a LoadStore > node access its field, the corresponding check done during > ConnectionGraph construction. > > Reviewed by: > > Fix verified (y/n): y, test case > > Other testing: > JPRT, CTW (with -XX:+DoEscapeAnalysis) > From Vladimir.Kozlov at Sun.COM Thu Feb 19 18:57:24 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 19 Feb 2009 18:57:24 -0800 Subject: Request for reviews (S): 6791572: assert("duplicating node that's already been matched") In-Reply-To: <499C9401.90108@sun.com> References: <499C9401.90108@sun.com> Message-ID: <499E1C14.6090408@sun.com> I updated the fix after discussion with Tom. http://cr.openjdk.java.net/~kvn/6791572/webrev.01 Thanks, Vladimir Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6791572/webrev.00 > > Fixed 6791572: assert("duplicating node that's already been matched") > > Problem: > AddP, LShiftX nodes and their inputs are marked as visited > on x86 during the first address expression processing. > AddP, LShiftX inputs will be not marked as shared since > AddP, LShiftX will be marked as shared first. > And this causes the problem since after AddP, LShiftX > are folded into address expressions their inputs > will be shared by several address expressions. > > Solution: > Delay marking nodes as visited if they are inputs > to an address expression. > > Reviewed by: > > Fix verified (y/n): y, test case > > Other testing: > JPRT > From vladimir.kozlov at sun.com Thu Feb 19 21:23:29 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 20 Feb 2009 05:23:29 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6802499: EA: assert(false, "unknown node on this path") Message-ID: <20090220052335.7E896DC45@hg.openjdk.java.net> Changeset: 49a36a80b0c7 Author: kvn Date: 2009-02-19 17:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/49a36a80b0c7 6802499: EA: assert(false,"unknown node on this path") Summary: Add missing checks for SCMemProj node in Escape analysis code. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp From Christian.Thalinger at Sun.COM Fri Feb 20 02:56:10 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 20 Feb 2009 11:56:10 +0100 Subject: SPARC: unsigned vs. signed int loads In-Reply-To: References: <1234370138.24951.41.camel@localhost.localdomain> <4992FFC8.2030300@sun.com> <267636E9-FFD7-4F1E-8B56-CCE8CF8C7F1F@sun.com> <09E901DD-9ED0-4BAD-A326-F16BB737AEE0@sun.com> <1234943516.5094.5.camel@localhost.localdomain> Message-ID: <1235127370.11128.12.camel@localhost.localdomain> On Wed, 2009-02-18 at 00:50 -0800, John Rose wrote: > If the type of a load matches that predicate, then you know that the > high-order bit is zero, and loadB can be strength-reduced to loadUB. > > That's the explanation. Thanks. Now it's clear. -- Christian From Christian.Thalinger at Sun.COM Fri Feb 20 02:57:09 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 20 Feb 2009 11:57:09 +0100 Subject: SPARC: unsigned vs. signed int loads In-Reply-To: <91E8CB76-4642-47D7-9407-51B0739D3E31@Sun.COM> References: <1234370138.24951.41.camel@localhost.localdomain> <4992FFC8.2030300@sun.com> <267636E9-FFD7-4F1E-8B56-CCE8CF8C7F1F@sun.com> <09E901DD-9ED0-4BAD-A326-F16BB737AEE0@sun.com> <1234943516.5094.5.camel@localhost.localdomain> <91E8CB76-4642-47D7-9407-51B0739D3E31@Sun.COM> Message-ID: <1235127429.11128.13.camel@localhost.localdomain> On Wed, 2009-02-18 at 11:16 -0800, Tom Rodriguez wrote: > Actually once we have LoadUBNode then all T_BOOLEAN loads should be > emitting those directly instead of relying ad tricks. Great. I'm already finishing up my patch and will post a webrev soon. I just want to be sure that I don't miss a case. -- Christian From Thomas.Rodriguez at Sun.COM Fri Feb 20 13:42:32 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 20 Feb 2009 13:42:32 -0800 Subject: Request for reviews (S): 6791572: assert("duplicating node that's already been matched") In-Reply-To: <499E1C14.6090408@sun.com> References: <499C9401.90108@sun.com> <499E1C14.6090408@sun.com> Message-ID: <4D6EE161-9D9F-4A0F-A9BA-F31B19FE0AEE@sun.com> This looks good to me. I think it properly captures the constraint that multiple uses from address expressions don't require marking as shared but if there are both address and non-address uses then it must be marked shared. tom On Feb 19, 2009, at 6:57 PM, Vladimir Kozlov wrote: > I updated the fix after discussion with Tom. > > http://cr.openjdk.java.net/~kvn/6791572/webrev.01 > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6791572/webrev.00 >> Fixed 6791572: assert("duplicating node that's already been matched") >> Problem: >> AddP, LShiftX nodes and their inputs are marked as visited >> on x86 during the first address expression processing. >> AddP, LShiftX inputs will be not marked as shared since >> AddP, LShiftX will be marked as shared first. >> And this causes the problem since after AddP, LShiftX >> are folded into address expressions their inputs >> will be shared by several address expressions. >> Solution: >> Delay marking nodes as visited if they are inputs >> to an address expression. >> Reviewed by: >> Fix verified (y/n): y, test case >> Other testing: >> JPRT From Thomas.Rodriguez at Sun.COM Fri Feb 20 15:16:02 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 20 Feb 2009 15:16:02 -0800 Subject: review (M) for 6807963: need tool to make sense of LogCompilaton output Message-ID: <6096E0DD-3BF8-4199-806F-5758AD30407D@Sun.COM> http://cr.openjdk.java.net/~never/6807963/ From john.coomes at sun.com Fri Feb 20 16:38:53 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 21 Feb 2009 00:38:53 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b48 for changeset 4ae9f4bfdb98 Message-ID: <20090221003853.87AD4DCB7@hg.openjdk.java.net> Changeset: aee93a8992d2 Author: xdono Date: 2009-02-19 14:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/aee93a8992d2 Added tag jdk7-b48 for changeset 4ae9f4bfdb98 ! .hgtags From john.coomes at sun.com Fri Feb 20 16:41:36 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 21 Feb 2009 00:41:36 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b48 for changeset 0be222241fd4 Message-ID: <20090221004138.7C33EDCBE@hg.openjdk.java.net> Changeset: d70978bc64bc Author: xdono Date: 2009-02-19 14:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/d70978bc64bc Added tag jdk7-b48 for changeset 0be222241fd4 ! .hgtags From john.coomes at sun.com Fri Feb 20 16:48:00 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 21 Feb 2009 00:48:00 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b48 for changeset 39de90eb4822 Message-ID: <20090221004803.728F4DCC3@hg.openjdk.java.net> Changeset: 5c1f24531903 Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/5c1f24531903 Added tag jdk7-b48 for changeset 39de90eb4822 ! .hgtags From john.coomes at sun.com Fri Feb 20 16:50:50 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 21 Feb 2009 00:50:50 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b48 for changeset 01e5dd31d0c1 Message-ID: <20090221005052.8C92CDCC8@hg.openjdk.java.net> Changeset: 18ca864890f3 Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/18ca864890f3 Added tag jdk7-b48 for changeset 01e5dd31d0c1 ! .hgtags From john.coomes at sun.com Fri Feb 20 16:56:41 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 21 Feb 2009 00:56:41 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 50 new changesets Message-ID: <20090221010809.F0B98DCCD@hg.openjdk.java.net> Changeset: 53d9259661c3 Author: jccollet Date: 2009-01-27 11:36 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/53d9259661c3 6790677: java.net.HttpCookie.parse(String) should ignore unrecognized attributes, RFC2965 Summary: Changed code not to throw an exception on unknown attributes Reviewed-by: chegar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java Changeset: 6eac3829cb41 Author: martin Date: 2009-01-27 15:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6eac3829cb41 6797480: Remove synchronization bottleneck in logger Reviewed-by: swamyv Contributed-by: jeremymanson at google.com ! src/share/classes/java/util/logging/Logger.java Changeset: c2d2185a79dd Author: darcy Date: 2009-01-28 10:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c2d2185a79dd 6704655: Test test/java/lang/reflect/Generics/Probe.java fails under OpenJDK Reviewed-by: ksrini ! test/java/lang/reflect/Generics/Probe.java Changeset: 1ebbc958f06a Author: darcy Date: 2009-01-28 12:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1ebbc958f06a 6719182: update legal notice in java/lang/instrument/package.html Reviewed-by: jjh ! src/share/classes/java/lang/instrument/package.html Changeset: 6607850bd7fc Author: martin Date: 2009-01-28 14:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6607850bd7fc 6798822: (process) Non-portable use of isdigit in src/solaris/native/java/lang/UNIXProcess_md.c Reviewed-by: alanb Contributed-by: christos at zoulas.com ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 7241bd422542 Author: darcy Date: 2009-01-29 09:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7241bd422542 6239194: Object.hashCode() should reference System.identityHashCode() Reviewed-by: emcmanus ! src/share/classes/java/lang/Object.java Changeset: ff9ad99b63cc Author: darcy Date: 2009-01-29 13:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ff9ad99b63cc 6327048: Enum javadoc could link to JLS 6653154: Exception message for bad Enum.valueOf has spurious "class" Reviewed-by: emcmanus ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/annotation/Annotation.java + test/java/lang/Enum/ValueOf.java Changeset: 483e5c97d438 Author: darcy Date: 2009-01-30 12:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/483e5c97d438 6799343: (fmt) java.util.Formatter uses plainlink instead of linkplain Reviewed-by: alanb ! src/share/classes/java/util/Formatter.java Changeset: d6881542bfef Author: michaelm Date: 2009-01-30 22:05 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d6881542bfef 4167874: URL-downloaded jar files can consume all available file descriptors Summary: added close method to URLClassLoader Reviewed-by: alanb ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/closetest/CloseTest.java + test/java/net/URLClassLoader/closetest/README + test/java/net/URLClassLoader/closetest/build.sh + test/java/net/URLClassLoader/closetest/serverRoot/Test.java + test/java/net/URLClassLoader/closetest/test1/com/foo/Resource1 + test/java/net/URLClassLoader/closetest/test1/com/foo/Resource2 + test/java/net/URLClassLoader/closetest/test1/com/foo/TestClass.java + test/java/net/URLClassLoader/closetest/test1/com/foo/TestClass1.java + test/java/net/URLClassLoader/closetest/test2/com/foo/Resource1 + test/java/net/URLClassLoader/closetest/test2/com/foo/Resource2 + test/java/net/URLClassLoader/closetest/test2/com/foo/TestClass.java + test/java/net/URLClassLoader/closetest/test2/com/foo/TestClass1.java Changeset: 0a05a2632a81 Author: michaelm Date: 2009-01-30 22:27 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0a05a2632a81 Merge Changeset: 948c504d6ef7 Author: darcy Date: 2009-01-30 15:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/948c504d6ef7 6799462: Minor typo (wrong word) in JavaDoc for InputStream.read(byte[] b) method Reviewed-by: sherman, martin ! src/share/classes/java/io/InputStream.java Changeset: f9cf49b7b248 Author: tbell Date: 2009-01-30 23:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f9cf49b7b248 Merge Changeset: 886a56291f1c Author: tbell Date: 2009-02-05 09:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/886a56291f1c 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 Changeset: 6c5d04d1eff4 Author: jccollet Date: 2009-02-02 16:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6c5d04d1eff4 6791927: Wrong Locale in HttpCookie::expiryDate2DeltaSeconds Summary: Force Locale.US when parsing the cookie expiration date. Reviewed-by: chegar ! src/share/classes/java/net/HttpCookie.java + test/java/net/CookieHandler/B6791927.java Changeset: dbb82636df41 Author: weijun Date: 2009-02-03 09:38 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dbb82636df41 6552334: Enable DNS in Kerberos by default Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KrbServiceLocator.java ! test/sun/security/krb5/DnsFallback.java Changeset: ca32af4c0ea5 Author: weijun Date: 2009-02-03 09:38 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ca32af4c0ea5 6785456: Read Kerberos setting from Windows environment variables Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java Changeset: 050da121df16 Author: darcy Date: 2009-02-03 16:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/050da121df16 6548433: (enum spec) java.lang.Enum docs should explain about values() and valueOf(String) Reviewed-by: martin ! src/share/classes/java/lang/Enum.java Changeset: a96a1f0edeeb Author: xuelei Date: 2009-02-04 19:10 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a96a1f0edeeb 6782783: regtest HttpsURLConnection/B6216082.java throws ClosedByInterruptException Summary: make the test robust Reviewed-by: weijun ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java Changeset: 61ee91f965ac Author: jccollet Date: 2009-02-04 14:15 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/61ee91f965ac 6585546: Please update API doc for java.net.CookieManager Summary: Trivial doc updates Reviewed-by: chegar ! src/share/classes/java/net/CookieManager.java Changeset: c87205c0e215 Author: tbell Date: 2009-02-05 09:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c87205c0e215 Merge Changeset: 2753acfbf013 Author: tbell Date: 2009-02-06 09:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2753acfbf013 Merge Changeset: 14681728d6af Author: tbell Date: 2009-02-17 09:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/14681728d6af Merge Changeset: 75755e92430c Author: art Date: 2008-08-26 13:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/75755e92430c 6585765: RFE: Remove Unicows-related code from AWT 6733976: VS2008 errors compiling AWT files - explicit casts need to be added 6728735: VS2008 errors compiling UnicowsLoader.h and fatal error in awtmsg.h Summary: Unicows-related and Win95/98/Me-related code is removed Reviewed-by: uta, tdv ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/Makefile ! make/sun/awt/make.depend ! make/sun/jawt/make.depend ! make/sun/splashscreen/Makefile ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/awt/splashscreen/splashscreen_sys.c ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DRenderQueue.cpp ! src/windows/native/sun/java2d/d3d/D3DRenderer.cpp ! src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp ! src/windows/native/sun/java2d/windows/WindowsFlags.cpp ! src/windows/native/sun/windows/ComCtl32Util.cpp ! src/windows/native/sun/windows/ComCtl32Util.h ! src/windows/native/sun/windows/Devices.cpp ! src/windows/native/sun/windows/Devices.h ! src/windows/native/sun/windows/GDIHashtable.cpp ! src/windows/native/sun/windows/GDIHashtable.h ! src/windows/native/sun/windows/ShellFolder2.cpp - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_Button.cpp ! src/windows/native/sun/windows/awt_Checkbox.cpp ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Color.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Cursor.cpp ! src/windows/native/sun/windows/awt_Cursor.h ! src/windows/native/sun/windows/awt_DataTransferer.cpp ! src/windows/native/sun/windows/awt_Desktop.cpp ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_DnDDT.cpp ! src/windows/native/sun/windows/awt_DrawingSurface.cpp ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_FileDialog.h ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_Font.h ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.h ! src/windows/native/sun/windows/awt_List.cpp - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h ! src/windows/native/sun/windows/awt_MenuItem.cpp - src/windows/native/sun/windows/awt_Multimon.h ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Palette.cpp ! src/windows/native/sun/windows/awt_PopupMenu.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp ! src/windows/native/sun/windows/awt_PrintDialog.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_ScrollPane.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextArea.h ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h ! src/windows/native/sun/windows/awt_TextField.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_TrayIcon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h ! src/windows/native/sun/windows/awt_Win32GraphicsConfig.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.h ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awt_Window.cpp - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h ! src/windows/native/sun/windows/awtmsg.h ! src/windows/native/sun/windows/jawt.cpp Changeset: 95a618c79382 Author: art Date: 2008-08-26 16:31 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/95a618c79382 6741364: Some input method problems after the fix for 6585765 Summary: the fix for 6585765 is corrected Reviewed-by: uta ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.h Changeset: 39c8e06919a9 Author: art Date: 2008-09-01 17:41 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/39c8e06919a9 6707023: Chenese Characters in JTextPane Cause Pane to Hang Summary: input method events are dispatched to correct AppContext Reviewed-by: naoto, yan ! src/windows/classes/sun/awt/windows/WInputMethod.java Changeset: b942efbc1c72 Author: dav Date: 2008-09-04 17:20 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b942efbc1c72 6738181: api/java_awt/Toolkit/index.html#GetAWTEventListeners Fails with:empty array returned unexpectedly Summary: redirect getAWTEventListeners(long l) from Headless to underlying toolkit. Reviewed-by: art ! src/share/classes/sun/awt/HeadlessToolkit.java + test/java/awt/Toolkit/Headless/AWTEventListener/AWTListener.java Changeset: f0ce5b54bd90 Author: dav Date: 2008-09-04 17:24 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f0ce5b54bd90 Merge - 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: 31a7769b5fd1 Author: martin Date: 2008-09-08 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/31a7769b5fd1 6744609: Disable MMX support when building libpng library Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux Reviewed-by: anthony, art ! make/sun/splashscreen/Makefile Changeset: fd13d8cce933 Author: dcherepanov Date: 2008-09-10 15:02 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fd13d8cce933 6743433: IM candidate window is not shown until window is deactivated and reactivated again Summary: OpenCandidateWindow procedure should directly call ::DefWindowProc Reviewed-by: art ! src/windows/native/sun/windows/awt_Component.cpp Changeset: b0c557c745e8 Author: art Date: 2008-09-11 10:38 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b0c557c745e8 6727884: Some Uncaught Exceptions are no longer getting sent to the Uncaught Exception Handlers Reviewed-by: anthony, dav ! src/share/classes/java/awt/EventDispatchThread.java + test/java/awt/EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java Changeset: 3b9a288d7ddb Author: dav Date: 2008-09-16 12:17 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3b9a288d7ddb 6315717: Support for mouse with multiple scroll wheels and 4 or more buttons Summary: implementation of the more mouse buttons support Reviewed-by: art, dcherepanov ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/doc-files/DesktopProperties.html ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/peer/RobotPeer.java ! src/share/classes/sun/awt/HeadlessToolkit.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/native/sun/awt/awt_Robot.c ! src/windows/classes/sun/awt/windows/WRobotPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Robot.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_TrayIcon.cpp + test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java + test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java + test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java + test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java + test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java + test/java/awt/Robot/ManualInstructions/ManualInstructions.java + test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java + test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java + test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java + test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java + test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java + test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java Changeset: 7e0533679ea1 Author: dav Date: 2008-09-29 14:54 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7e0533679ea1 6746212: Broken MouseEvents for TrayIcon Reviewed-by: dcherepanov, art ! src/windows/native/sun/windows/awt_TrayIcon.cpp Changeset: 672290c883fd Author: rkennke Date: 2008-09-29 20:16 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/672290c883fd 6749920: Cleanup AWT peer interfaces Summary: Remove duplicate and obsolete methods in the AWT peer interfaces. Reviewed-by: art, dav ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/peer/ChoicePeer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/peer/ContainerPeer.java ! src/share/classes/java/awt/peer/ListPeer.java ! src/share/classes/java/awt/peer/MenuItemPeer.java ! src/share/classes/java/awt/peer/TextAreaPeer.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/share/classes/java/awt/peer/TextFieldPeer.java ! src/share/classes/java/awt/peer/WindowPeer.java Changeset: 485e803c2d5a Author: dav Date: 2008-10-03 10:33 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/485e803c2d5a 6755110: Solaris build has corrupted with extra mouse buttons RFE Reviewed-by: yan ! src/solaris/native/sun/awt/awt_Robot.c Changeset: 5482ef16fe78 Author: yan Date: 2008-10-06 16:45 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5482ef16fe78 5100701: Toolkit.getLockingKeyState() does not work on XToolkit, but works on Motif Summary: Does not work on Motif but works on XToolkit now; implemented using XQueryPointer. Reviewed-by: anthony ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: ce224a356eb8 Author: dav Date: 2008-10-07 16:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ce224a356eb8 6750288: Regression after 6315717. ArrayIndexOutOfBoundsException. Reviewed-by: dcherepanov, denis ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 724eb9cbd3bb Author: dav Date: 2008-10-07 16:43 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/724eb9cbd3bb Merge ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: aed796ac3788 Author: dav Date: 2008-10-08 12:50 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/aed796ac3788 5076635: Double click speed is not honored in KDE linux Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XToolkit.java + test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.html + test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.java Changeset: 346127532313 Author: dav Date: 2008-10-08 13:01 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/346127532313 Merge - make/java/nio/spp.sh - make/tools/winver/Makefile - make/tools/winver/bin/winver.exe - make/tools/winver/src/StdAfx.cpp - make/tools/winver/src/StdAfx.h - make/tools/winver/src/winver.cpp - src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java - src/share/classes/javax/management/ToQueryString.java ! src/solaris/classes/sun/awt/X11/XToolkit.java - src/windows/classes/sun/java2d/d3d/D3DBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/DDBlitLoops.java - src/windows/classes/sun/java2d/windows/DDRenderer.java - src/windows/classes/sun/java2d/windows/DDScaleLoops.java - src/windows/classes/sun/java2d/windows/Win32OffScreenSurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceDataProxy.java - src/windows/classes/sun/java2d/windows/WinBackBuffer.java - src/windows/classes/sun/java2d/windows/WinBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/WinVolatileSurfaceManager.java - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.cpp - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.h - src/windows/native/sun/java2d/d3d/D3DTestRaster.h - src/windows/native/sun/java2d/d3d/D3DTextRenderer_md.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.h - src/windows/native/sun/java2d/windows/DDBlitLoops.cpp - src/windows/native/sun/java2d/windows/DDRenderer.cpp - src/windows/native/sun/java2d/windows/RegistryKey.cpp - src/windows/native/sun/java2d/windows/RegistryKey.h - src/windows/native/sun/java2d/windows/Win32OffScreenSurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.h - src/windows/native/sun/java2d/windows/WinBackBufferSurfaceData.cpp - src/windows/native/sun/java2d/windows/ddrawObject.cpp - src/windows/native/sun/java2d/windows/ddrawObject.h - src/windows/native/sun/java2d/windows/ddrawUtils.cpp - src/windows/native/sun/java2d/windows/ddrawUtils.h - src/windows/native/sun/java2d/windows/dxCapabilities.cpp - src/windows/native/sun/java2d/windows/dxCapabilities.h - src/windows/native/sun/java2d/windows/dxInit.cpp - src/windows/native/sun/java2d/windows/dxInit.h - 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: 0c515369b48b Author: lana Date: 2008-10-20 19:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0c515369b48b Merge - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/README-builds.html - make/README.html - make/THIRD_PARTY_README ! make/sun/awt/Makefile - make/tools/auto_multi/Makefile - make/tools/src/build/tools/automulti/AutoMulti.java - make/tools/src/build/tools/automulti/README.txt - make/tools/src/build/tools/automulti/TestALFGenerator.java - make/tools/src/build/tools/automulti/TestALFLookAndFeel.java ! src/share/classes/java/awt/EventDispatchThread.java - src/share/classes/java/nio/channels/package.html - src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java - src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java - src/share/classes/javax/swing/colorchooser/SyntheticImage.java - src/share/classes/org/jcp/xml/dsig/internal/package.html - src/share/classes/sun/launcher/LauncherHelp.java - src/share/classes/sun/nio/ch/OptionAdaptor.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h - src/solaris/javavm/include/typedefs_md.h - src/windows/javavm/include/typedefs_md.h ! src/windows/native/sun/windows/ComCtl32Util.cpp ! src/windows/native/sun/windows/ComCtl32Util.h ! src/windows/native/sun/windows/awt_TextArea.cpp - test/javax/swing/JFileChooser/4252173/bug4252173.java - test/javax/swing/JFileChooser/6524424/bug6524424.html - test/javax/swing/JFileChooser/6524424/bug6524424.java - test/sun/net/www/http/ChunkedInputStream/test.txt - test/tools/launcher/Arrrghs.sh Changeset: 7406833af6e4 Author: art Date: 2008-10-28 17:06 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7406833af6e4 6758673: WeakReference leak in Window.ownedWindowList Summary: WindowDisposerRecord parent field is correctly initialized Reviewed-by: dav, ant ! src/share/classes/java/awt/Window.java + test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java Changeset: 9daa41eca0d9 Author: art Date: 2008-11-26 16:25 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9daa41eca0d9 6699589: java/awt/EventQueue/PostEventOrderingTest.java fails Reviewed-by: dav, anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: d5bf2dd61ed5 Author: art Date: 2008-12-19 16:04 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d5bf2dd61ed5 6773985: OutOfMemory (PermGen space) under Linux / Firefox when switching bw. applets Summary: XEmbedClientHelper is uninstalled when its embedded frame is disposed. Reviewed-by: dcherepanov, ant ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java Changeset: 63d087cacbf9 Author: rkennke Date: 2009-01-13 20:04 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/63d087cacbf9 6792515: Specify awt peer's API Summary: Document AWT peer API. Reviewed-by: art, dav ! src/share/classes/java/awt/peer/ButtonPeer.java ! src/share/classes/java/awt/peer/CanvasPeer.java ! src/share/classes/java/awt/peer/CheckboxMenuItemPeer.java ! src/share/classes/java/awt/peer/CheckboxPeer.java ! src/share/classes/java/awt/peer/ChoicePeer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/peer/ContainerPeer.java ! src/share/classes/java/awt/peer/DesktopPeer.java ! src/share/classes/java/awt/peer/DialogPeer.java ! src/share/classes/java/awt/peer/FileDialogPeer.java ! src/share/classes/java/awt/peer/FontPeer.java ! src/share/classes/java/awt/peer/FramePeer.java ! src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java ! src/share/classes/java/awt/peer/LabelPeer.java ! src/share/classes/java/awt/peer/ListPeer.java ! src/share/classes/java/awt/peer/MenuBarPeer.java ! src/share/classes/java/awt/peer/MenuComponentPeer.java ! src/share/classes/java/awt/peer/MenuItemPeer.java ! src/share/classes/java/awt/peer/MenuPeer.java ! src/share/classes/java/awt/peer/MouseInfoPeer.java ! src/share/classes/java/awt/peer/PanelPeer.java ! src/share/classes/java/awt/peer/PopupMenuPeer.java ! src/share/classes/java/awt/peer/RobotPeer.java ! src/share/classes/java/awt/peer/ScrollPanePeer.java ! src/share/classes/java/awt/peer/ScrollbarPeer.java ! src/share/classes/java/awt/peer/SystemTrayPeer.java ! src/share/classes/java/awt/peer/TextAreaPeer.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/share/classes/java/awt/peer/TextFieldPeer.java ! src/share/classes/java/awt/peer/TrayIconPeer.java ! src/share/classes/java/awt/peer/WindowPeer.java Changeset: 127e3269ee1f Author: bae Date: 2009-01-20 19:51 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/127e3269ee1f 6551075: screenshot image taken through clipboard on W2K terminal server is shifted Reviewed-by: dav, uta ! src/windows/native/sun/windows/awt_DataTransferer.cpp Changeset: 9fa2e56c8a30 Author: art Date: 2009-01-29 14:58 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9fa2e56c8a30 6721088: Bad window size calculation after using pack() Reviewed-by: anthony Contributed-by: Omair Majid ! src/solaris/classes/sun/awt/X11/WindowDimensions.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java + test/java/awt/Frame/FrameSize/TestFrameSize.java Changeset: f36e9200cb85 Author: anthony Date: 2009-02-04 11:58 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f36e9200cb85 6797195: Forward-port enhancements for hw/lw mixing from 6u12 to 7 Reviewed-by: art, dcherepanov ! make/sun/awt/Makefile ! make/tools/sharing/classlist.linux ! make/tools/sharing/classlist.solaris ! make/tools/sharing/classlist.windows + src/share/classes/com/sun/awt/AWTUtilities.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/javax/swing/JRootPane.java + src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/java2d/pipe/Region.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/windows/awt_Component.cpp + test/java/awt/Mixing/HWDisappear.java + test/java/awt/Mixing/JButtonInGlassPane.java + test/java/awt/Mixing/LWComboBox.java + test/java/awt/Mixing/MixingOnShrinkingHWButton.java + test/java/awt/Mixing/NonOpaqueInternalFrame.java ! test/java/awt/Mixing/OpaqueTest.java ! test/java/awt/Mixing/OverlappingButtons.java Changeset: 8b96fb2d0c3a Author: lana Date: 2009-02-10 12:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8b96fb2d0c3a Merge ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/EventDispatchThread.java - 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: 5fbd9ea7def1 Author: lana Date: 2009-02-18 10:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5fbd9ea7def1 Merge - 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: 8311105ea7a3 Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8311105ea7a3 Added tag jdk7-b48 for changeset 5fbd9ea7def1 ! .hgtags From john.coomes at sun.com Fri Feb 20 17:18:53 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 21 Feb 2009 01:18:53 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 12 new changesets Message-ID: <20090221011913.978C3DCD2@hg.openjdk.java.net> Changeset: edb8d7985cfd Author: darcy Date: 2009-01-27 17:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/edb8d7985cfd 6707027: langtools/test/tools/javac/processing/model/testgetallmember/Main.java fails Reviewed-by: jjg ! test/tools/javac/processing/model/testgetallmembers/Main.java Changeset: 9199b9092f73 Author: jjg Date: 2009-01-27 18:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/9199b9092f73 6176978: current Javadoc's invocation and extension (Doclet) mechanisms are problematic Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java + test/tools/javadoc/6176978/T6176978.java + test/tools/javadoc/6176978/X.java Changeset: 1aa81917016a Author: mcimadamore Date: 2009-01-29 12:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/1aa81917016a 6315770: javac inference allows creation of strange types: Integer & Runnable Summary: Javac does not apply glb correctly as per JLS3 15.12.2.8 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6315770/T6315770.java + test/tools/javac/generics/inference/6315770/T6315770.out Changeset: 4542977c959e Author: mcimadamore Date: 2009-01-29 12:18 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/4542977c959e 6557182: Unchecked warning *and* inconvertible types Summary: Redundant warnings are generated when casting from intersection types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/6557182/T6557182.java + test/tools/javac/cast/6557182/T6557182.out Changeset: 79f2f2c7d846 Author: mcimadamore Date: 2009-01-29 12:19 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/79f2f2c7d846 6729401: Compiler error when using F-bounded generics with free type variables Summary: Javac applies wrong substitution to recursive type-variable bounds Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/6729401/T6729401.java Changeset: 49281ea88125 Author: tbell Date: 2009-01-30 23:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/49281ea88125 Merge Changeset: 638d5fbf5e78 Author: tbell Date: 2009-02-06 09:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/638d5fbf5e78 Merge Changeset: 9d541fd2916b Author: jjg Date: 2009-02-06 10:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/9d541fd2916b 6595666: fix -Werror Reviewed-by: mcimadamore ! 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/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/T6241723.out + test/tools/javac/T6595666.java ! test/tools/javac/depDocComment/DeprecatedDocComment.out Changeset: 58fcba61a77d Author: darcy Date: 2009-02-06 12:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/58fcba61a77d 6794071: Provide exception superclass for UnknownFooExceptions Reviewed-by: jjg + src/share/classes/javax/lang/model/UnknownEntityException.java ! src/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java ! src/share/classes/javax/lang/model/element/UnknownElementException.java ! src/share/classes/javax/lang/model/type/UnknownTypeException.java + test/tools/javac/processing/model/TestExceptions.java Changeset: 000d1e518bc5 Author: tbell Date: 2009-02-06 17:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/000d1e518bc5 Merge Changeset: c53007f34195 Author: tbell Date: 2009-02-17 09:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c53007f34195 Merge Changeset: d17d927ad9bd Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d17d927ad9bd Added tag jdk7-b48 for changeset c53007f34195 ! .hgtags From Christian.Thalinger at Sun.COM Sun Feb 22 09:48:33 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sun, 22 Feb 2009 18:48:33 +0100 Subject: emit_rm in MacroAssembler Message-ID: <1235324913.11128.37.camel@localhost.localdomain> Hi! What is the prefered way to do an emit_rm in the MacroAssembler? It seems there is no such method. Actually I'm searching for an equivalent of x86_32.ad's RegReg. -- Christian From Paul.Hohensee at Sun.COM Sun Feb 22 10:02:21 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Sun, 22 Feb 2009 13:02:21 -0500 Subject: emit_rm in MacroAssembler In-Reply-To: <1235324913.11128.37.camel@localhost.localdomain> References: <1235324913.11128.37.camel@localhost.localdomain> Message-ID: <49A1932D.2050301@sun.com> Take a look at emit_operand() in assembler_x86.cpp. It handles all rm variations, not just RegReg. Paul Christian Thalinger wrote: > Hi! > > What is the prefered way to do an emit_rm in the MacroAssembler? It > seems there is no such method. Actually I'm searching for an equivalent > of x86_32.ad's RegReg. > > -- Christian > > From Christian.Thalinger at Sun.COM Sun Feb 22 10:22:03 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sun, 22 Feb 2009 19:22:03 +0100 Subject: emit_rm in MacroAssembler In-Reply-To: <49A1932D.2050301@sun.com> References: <1235324913.11128.37.camel@localhost.localdomain> <49A1932D.2050301@sun.com> Message-ID: <1235326923.11128.39.camel@localhost.localdomain> On Sun, 2009-02-22 at 13:02 -0500, Paul Hohensee wrote: > Take a look at emit_operand() in assembler_x86.cpp. It handles all rm > variations, > not just RegReg. Hmm, I have already looked at them but I couldn't find a: emit_operand(Register, Register); Am I missing something here? -- Christian From Peter.Kessler at Sun.COM Mon Feb 23 11:07:28 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Mon, 23 Feb 2009 11:07:28 -0800 Subject: Patch for misleading comment in src/share/vm/opto/node.cpp Message-ID: <49A2F3F0.5010206@Sun.COM> This comment is so wrong as almost to qualify as malicious. Here's a patch that might help. src/share/vm/opto/node.cpp 971 // If you modify the 'this' pointer's inputs, you must use 'set_req' with 972 // def-use info. If you are making a new Node (either as the new root or 973 // some new internal piece) you must NOT use set_req with def-use info. 974 // You can make a new Node with either 'new' or 'clone'. In either case, 975 // def-use info is (correctly) not generated. 976 // Example: reshape "(X+3)+4" into "X+7": 977 // set_req(1,in(1)->in(1) /* grab X */, du /* must use DU on 'this' */); 978 // set_req(2,phase->intcon(7),du); 979 // return this; - 980 // Example: reshape "X*4" into "X<<1" - 981 // return new (C,3) LShiftINode( in(1), phase->intcon(1) ); + 980 // Example: reshape "X*4" into "X<<2" + 981 // return new (C,3) LShiftINode( in(1), phase->intcon(2) ); 982 // 983 // You must call 'phase->transform(X)' on any new Nodes X you make, except - 984 // for the returned root node. Example: reshape "X*31" with "(X<<5)-1". - 985 // Node *shift=phase->transform(new(C,3)LShiftINode(in(1),phase->intcon(5))); - 986 // return new (C,3) AddINode(shift, phase->intcon(-1)); + 984 // for the returned root node. Example: reshape "X*31" with "(X<<5)-X". + 985 // Node *shift=phase->transform(new(C,3)LShiftINode(in(1),phase->intcon(5))); + 986 // return new (C,3) SubINode(shift, phase->intcon(in(1))); The code *does* implement the transforms shown, but the transforms themselves are so wrong that it doesn't give me warm fuzzy feelings about trusting the author of this comment to transform my code. (And I have some worries about overflows and sign bits on the last transform, but I haven't checked them out.) ... peter From Peter.Kessler at Sun.COM Mon Feb 23 11:15:17 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Mon, 23 Feb 2009 11:15:17 -0800 Subject: Patch for misleading comment in src/share/vm/opto/node.cpp In-Reply-To: <49A2F3F0.5010206@Sun.COM> References: <49A2F3F0.5010206@Sun.COM> Message-ID: <49A2F5C5.1060102@Sun.COM> Peter B. Kessler wrote: > This comment is so wrong as almost to qualify as malicious. Here's a > patch that might help. > > src/share/vm/opto/node.cpp > > 971 // If you modify the 'this' pointer's inputs, you must use 'set_req' with > 972 // def-use info. If you are making a new Node (either as the new root or > 973 // some new internal piece) you must NOT use set_req with def-use info. > 974 // You can make a new Node with either 'new' or 'clone'. In either case, > 975 // def-use info is (correctly) not generated. > 976 // Example: reshape "(X+3)+4" into "X+7": > 977 // set_req(1,in(1)->in(1) /* grab X */, du /* must use DU on 'this' */); > 978 // set_req(2,phase->intcon(7),du); > 979 // return this; > - 980 // Example: reshape "X*4" into "X<<1" > - 981 // return new (C,3) LShiftINode( in(1), phase->intcon(1) ); > + 980 // Example: reshape "X*4" into "X<<2" > + 981 // return new (C,3) LShiftINode( in(1), phase->intcon(2) ); > 982 // > 983 // You must call 'phase->transform(X)' on any new Nodes X you make, except > - 984 // for the returned root node. Example: reshape "X*31" with "(X<<5)-1". > - 985 // Node *shift=phase->transform(new(C,3)LShiftINode(in(1),phase->intcon(5))); > - 986 // return new (C,3) AddINode(shift, phase->intcon(-1)); > + 984 // for the returned root node. Example: reshape "X*31" with "(X<<5)-X". > + 985 // Node *shift=phase->transform(new(C,3)LShiftINode(in(1),phase->intcon(5))); > + 986 // return new (C,3) SubINode(shift, phase->intcon(in(1))); This last line should probably be + 986 // return new (C,3) SubINode(shift, in(1)); but I admit I'm a noob in this part of the code. (Which is why I was reading the comments. :-) ... peter > The code *does* implement the transforms shown, but the transforms > themselves are so wrong that it doesn't give me warm fuzzy feelings > about trusting the author of this comment to transform my code. (And I > have some worries about overflows and sign bits on the last transform, > but I haven't checked them out.) > > ... peter From Thomas.Rodriguez at Sun.COM Mon Feb 23 11:26:58 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 23 Feb 2009 11:26:58 -0800 Subject: emit_rm in MacroAssembler In-Reply-To: <1235326923.11128.39.camel@localhost.localdomain> References: <1235324913.11128.37.camel@localhost.localdomain> <49A1932D.2050301@sun.com> <1235326923.11128.39.camel@localhost.localdomain> Message-ID: They aren't structured the same at all. I think you want something like this for the 64 bit reg/reg: emit_byte(0xF3); int encode = prefixq_and_encode(dst->encoding(), src->encoding()); emit_byte(0x0f); emit_byte(0xb8); emit_byte(0xc0 | encode); The prefix* family of functions take care of emitting the proper REXs and masking the registers down to 3 bits. Use the regular prefix_and_encode for popcntl. tom On Feb 22, 2009, at 10:22 AM, Christian Thalinger wrote: > On Sun, 2009-02-22 at 13:02 -0500, Paul Hohensee wrote: >> Take a look at emit_operand() in assembler_x86.cpp. It handles all >> rm >> variations, >> not just RegReg. > > Hmm, I have already looked at them but I couldn't find a: > > emit_operand(Register, Register); > > Am I missing something here? > > -- Christian > From Christian.Thalinger at Sun.COM Mon Feb 23 11:44:43 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 23 Feb 2009 20:44:43 +0100 Subject: emit_rm in MacroAssembler In-Reply-To: References: <1235324913.11128.37.camel@localhost.localdomain> <49A1932D.2050301@sun.com> <1235326923.11128.39.camel@localhost.localdomain> Message-ID: <1235418283.11128.113.camel@localhost.localdomain> On Mon, 2009-02-23 at 11:26 -0800, Tom Rodriguez wrote: > They aren't structured the same at all. I think you want something > like this for the 64 bit reg/reg: > > emit_byte(0xF3); > int encode = prefixq_and_encode(dst->encoding(), src->encoding()); > emit_byte(0x0f); > emit_byte(0xb8); > emit_byte(0xc0 | encode); > > The prefix* family of functions take care of emitting the proper REXs > and masking the registers down to 3 bits. Use the regular > prefix_and_encode for popcntl. That's almost exactly what I did: +void Assembler::popcntl(Register dst, Register src) { + //assert(VM_Version::supports_popcnt(), "must support"); + emit_byte(0xF3); + int encode = prefix_and_encode(dst->encoding(), src->encoding()); + emit_byte(0x0F); + emit_byte(0xB8); + emit_byte(encode); +} But your code emits the correct instruction :-) Shouldn't the 0xC0 part be in some kind of function? -- Christian From Thomas.Rodriguez at Sun.COM Mon Feb 23 11:56:05 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 23 Feb 2009 11:56:05 -0800 Subject: emit_rm in MacroAssembler In-Reply-To: <1235418283.11128.113.camel@localhost.localdomain> References: <1235324913.11128.37.camel@localhost.localdomain> <49A1932D.2050301@sun.com> <1235326923.11128.39.camel@localhost.localdomain> <1235418283.11128.113.camel@localhost.localdomain> Message-ID: It certainly could be factored differently. I've never been very happy with factoring strategy in the MacroAssembler. It would be nice if there was some fairly rote translation from the description in the manual to the source code you should write but that may just be dreaming. The tendency is to find a similar instruction and copy from that which is basically what I did. tom On Feb 23, 2009, at 11:44 AM, Christian Thalinger wrote: > On Mon, 2009-02-23 at 11:26 -0800, Tom Rodriguez wrote: >> They aren't structured the same at all. I think you want something >> like this for the 64 bit reg/reg: >> >> emit_byte(0xF3); >> int encode = prefixq_and_encode(dst->encoding(), src->encoding()); >> emit_byte(0x0f); >> emit_byte(0xb8); >> emit_byte(0xc0 | encode); >> >> The prefix* family of functions take care of emitting the proper REXs >> and masking the registers down to 3 bits. Use the regular >> prefix_and_encode for popcntl. > > That's almost exactly what I did: > > +void Assembler::popcntl(Register dst, Register src) { > + //assert(VM_Version::supports_popcnt(), "must support"); > + emit_byte(0xF3); > + int encode = prefix_and_encode(dst->encoding(), src->encoding()); > + emit_byte(0x0F); > + emit_byte(0xB8); > + emit_byte(encode); > +} > > But your code emits the correct instruction :-) Shouldn't the 0xC0 > part > be in some kind of function? > > -- Christian > From dawn2004 at gmail.com Mon Feb 23 13:24:17 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 23 Feb 2009 13:24:17 -0800 (PST) Subject: How to use cppInterpreter in Hotspot? Message-ID: <22170486.post@talk.nabble.com> Hello, If I hope hotspot only use cppInterpreter without using template interpreter, what shall I do? Thanks a lot! Du Li -- View this message in context: http://www.nabble.com/How-to-use-cppInterpreter-in-Hotspot--tp22170486p22170486.html Sent from the OpenJDK Hotspot Compiler Development List mailing list archive at Nabble.com. From Christian.Thalinger at Sun.COM Mon Feb 23 15:46:02 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 23 Feb 2009 23:46:02 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6808589: Merge vm_version_x86_{32, 64}.{cpp, hpp} Message-ID: <20090223234604.71128DEF1@hg.openjdk.java.net> Changeset: 22e09c0f4b47 Author: twisti Date: 2009-02-23 12:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/22e09c0f4b47 6808589: Merge vm_version_x86_{32,64}.{cpp,hpp} Summary: There is very much duplicated code in vm_version_x86_{32,64}.{cpp,hpp}. Refactoring these would help maintainability. Reviewed-by: kvn, never + src/cpu/x86/vm/vm_version_x86.cpp + src/cpu/x86/vm/vm_version_x86.hpp - 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/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp ! src/share/vm/includeDB_core From Coleen.Phillimore at Sun.COM Mon Feb 23 16:54:25 2009 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Mon, 23 Feb 2009 19:54:25 -0500 Subject: How to use cppInterpreter in Hotspot? In-Reply-To: <22170486.post@talk.nabble.com> References: <22170486.post@talk.nabble.com> Message-ID: <1235436865.7493.5.camel@phillimores> Build with CC_INTERP=1 as an option on the make command line. On Mon, 2009-02-23 at 13:24 -0800, Colin(Du Li) wrote: > Hello, > > If I hope hotspot only use cppInterpreter without using template > interpreter, what shall I do? > Thanks a lot! > > Du Li From vladimir.kozlov at sun.com Mon Feb 23 18:29:40 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 24 Feb 2009 02:29:40 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6791572: assert("duplicating node that's already been matched") Message-ID: <20090224022942.66F10DF11@hg.openjdk.java.net> Changeset: 6bea93606c11 Author: kvn Date: 2009-02-23 16:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6bea93606c11 6791572: assert("duplicating node that's already been matched") Summary: Mark inputs for an address expression as shared if there are other uses besides address expressions. Reviewed-by: never ! src/share/vm/opto/matcher.cpp From Christian.Thalinger at Sun.COM Tue Feb 24 00:32:45 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 24 Feb 2009 09:32:45 +0100 Subject: Patch for misleading comment in src/share/vm/opto/node.cpp In-Reply-To: <49A2F5C5.1060102@Sun.COM> References: <49A2F3F0.5010206@Sun.COM> <49A2F5C5.1060102@Sun.COM> Message-ID: <1235464365.11128.157.camel@localhost.localdomain> On Mon, 2009-02-23 at 11:15 -0800, Peter B. Kessler wrote: > Peter B. Kessler wrote: > > This comment is so wrong as almost to qualify as malicious. Here's a > > patch that might help. > > > > src/share/vm/opto/node.cpp > > > > 971 // If you modify the 'this' pointer's inputs, you must use 'set_req' with > > 972 // def-use info. If you are making a new Node (either as the new root or > > 973 // some new internal piece) you must NOT use set_req with def-use info. > > 974 // You can make a new Node with either 'new' or 'clone'. In either case, > > 975 // def-use info is (correctly) not generated. > > 976 // Example: reshape "(X+3)+4" into "X+7": > > 977 // set_req(1,in(1)->in(1) /* grab X */, du /* must use DU on 'this' */); > > 978 // set_req(2,phase->intcon(7),du); > > 979 // return this; > > - 980 // Example: reshape "X*4" into "X<<1" > > - 981 // return new (C,3) LShiftINode( in(1), phase->intcon(1) ); > > + 980 // Example: reshape "X*4" into "X<<2" > > + 981 // return new (C,3) LShiftINode( in(1), phase->intcon(2) ); > > 982 // > > 983 // You must call 'phase->transform(X)' on any new Nodes X you make, except > > - 984 // for the returned root node. Example: reshape "X*31" with "(X<<5)-1". > > - 985 // Node *shift=phase->transform(new(C,3)LShiftINode(in(1),phase->intcon(5))); > > - 986 // return new (C,3) AddINode(shift, phase->intcon(-1)); > > + 984 // for the returned root node. Example: reshape "X*31" with "(X<<5)-X". > > + 985 // Node *shift=phase->transform(new(C,3)LShiftINode(in(1),phase->intcon(5))); > > + 986 // return new (C,3) SubINode(shift, phase->intcon(in(1))); > > This last line should probably be > > + 986 // return new (C,3) SubINode(shift, in(1)); > > but I admit I'm a noob in this part of the code. (Which is why I was reading the comments. :-) I'm not an expert either but it looks good. I'm adding this one to my typos-repository. Thanks! -- Christian From dawn2004 at gmail.com Mon Feb 23 20:12:13 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 23 Feb 2009 20:12:13 -0800 (PST) Subject: How to use cppInterpreter in Hotspot? In-Reply-To: <1235436865.7493.5.camel@phillimores> References: <22170486.post@talk.nabble.com> <1235436865.7493.5.camel@phillimores> Message-ID: <22175514.post@talk.nabble.com> 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. Thanks again. Coleen Phillimore - Sun Microsystems wrote: > > > Build with CC_INTERP=1 as an option on the make command line. > > > On Mon, 2009-02-23 at 13:24 -0800, Colin(Du Li) wrote: >> Hello, >> >> If I hope hotspot only use cppInterpreter without using template >> interpreter, what shall I do? >> Thanks a lot! >> >> Du Li > > > -- View this message in context: http://www.nabble.com/How-to-use-cppInterpreter-in-Hotspot--tp22170486p22175514.html Sent from the OpenJDK Hotspot Compiler Development List mailing list archive at Nabble.com. From Christian.Thalinger at Sun.COM Tue Feb 24 06:27:52 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 24 Feb 2009 15:27:52 +0100 Subject: How to use cppInterpreter in Hotspot? In-Reply-To: <22175514.post@talk.nabble.com> References: <22170486.post@talk.nabble.com> <1235436865.7493.5.camel@phillimores> <22175514.post@talk.nabble.com> Message-ID: <1235485672.11128.189.camel@localhost.localdomain> 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 From Thomas.Rodriguez at Sun.COM Tue Feb 24 10:43:44 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 24 Feb 2009 10:43:44 -0800 Subject: Patch for misleading comment in src/share/vm/opto/node.cpp In-Reply-To: <1235464365.11128.157.camel@localhost.localdomain> References: <49A2F3F0.5010206@Sun.COM> <49A2F5C5.1060102@Sun.COM> <1235464365.11128.157.camel@localhost.localdomain> Message-ID: <48766DA7-1568-4F9B-B516-2579EB59D0A7@sun.com> On Feb 24, 2009, at 12:32 AM, Christian Thalinger wrote: > On Mon, 2009-02-23 at 11:15 -0800, Peter B. Kessler wrote: >> Peter B. Kessler wrote: >>> This comment is so wrong as almost to qualify as malicious. >>> Here's a >>> patch that might help. >>> >>> src/share/vm/opto/node.cpp >>> >>> 971 // If you modify the 'this' pointer's inputs, you must use >>> 'set_req' with >>> 972 // def-use info. If you are making a new Node (either as >>> the new root or >>> 973 // some new internal piece) you must NOT use set_req with >>> def-use info. >>> 974 // You can make a new Node with either 'new' or 'clone'. >>> In either case, >>> 975 // def-use info is (correctly) not generated. This piece isn't valid either. There's no separate du argument to any of the set functions anymore. tom >>> >>> 976 // Example: reshape "(X+3)+4" into "X+7": >>> 977 // set_req(1,in(1)->in(1) /* grab X */, du /* must use >>> DU on 'this' */); >>> 978 // set_req(2,phase->intcon(7),du); >>> 979 // return this; >>> - 980 // Example: reshape "X*4" into "X<<1" >>> - 981 // return new (C,3) LShiftINode( in(1), phase- >>> >intcon(1) ); >>> + 980 // Example: reshape "X*4" into "X<<2" >>> + 981 // return new (C,3) LShiftINode( in(1), phase- >>> >intcon(2) ); >>> 982 // >>> 983 // You must call 'phase->transform(X)' on any new Nodes X >>> you make, except >>> - 984 // for the returned root node. Example: reshape "X*31" >>> with "(X<<5)-1". >>> - 985 // Node *shift=phase->transform(new(C, >>> 3)LShiftINode(in(1),phase->intcon(5))); >>> - 986 // return new (C,3) AddINode(shift, phase->intcon(-1)); >>> + 984 // for the returned root node. Example: reshape "X*31" >>> with "(X<<5)-X". >>> + 985 // Node *shift=phase->transform(new(C, >>> 3)LShiftINode(in(1),phase->intcon(5))); >>> + 986 // return new (C,3) SubINode(shift, phase- >>> >intcon(in(1))); >> >> This last line should probably be >> >> + 986 // return new (C,3) SubINode(shift, in(1)); >> >> but I admit I'm a noob in this part of the code. (Which is why I >> was reading the comments. :-) > > I'm not an expert either but it looks good. I'm adding this one to my > typos-repository. Thanks! > > -- Christian > From Christian.Thalinger at Sun.COM Tue Feb 24 10:46:06 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 24 Feb 2009 19:46:06 +0100 Subject: Patch for misleading comment in src/share/vm/opto/node.cpp In-Reply-To: <48766DA7-1568-4F9B-B516-2579EB59D0A7@sun.com> References: <49A2F3F0.5010206@Sun.COM> <49A2F5C5.1060102@Sun.COM> <1235464365.11128.157.camel@localhost.localdomain> <48766DA7-1568-4F9B-B516-2579EB59D0A7@sun.com> Message-ID: <1235501166.11128.195.camel@localhost.localdomain> On Tue, 2009-02-24 at 10:43 -0800, Tom Rodriguez wrote: > On Feb 24, 2009, at 12:32 AM, Christian Thalinger wrote: > > > On Mon, 2009-02-23 at 11:15 -0800, Peter B. Kessler wrote: > >> Peter B. Kessler wrote: > >>> This comment is so wrong as almost to qualify as malicious. > >>> Here's a > >>> patch that might help. > >>> > >>> src/share/vm/opto/node.cpp > >>> > >>> 971 // If you modify the 'this' pointer's inputs, you must use > >>> 'set_req' with > >>> 972 // def-use info. If you are making a new Node (either as > >>> the new root or > >>> 973 // some new internal piece) you must NOT use set_req with > >>> def-use info. > >>> 974 // You can make a new Node with either 'new' or 'clone'. > >>> In either case, > >>> 975 // def-use info is (correctly) not generated. > > This piece isn't valid either. There's no separate du argument to any > of the set functions anymore. Remove all 5 lines? -- Christian From Thomas.Rodriguez at Sun.COM Tue Feb 24 10:53:25 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 24 Feb 2009 10:53:25 -0800 Subject: Patch for misleading comment in src/share/vm/opto/node.cpp In-Reply-To: <1235501166.11128.195.camel@localhost.localdomain> References: <49A2F3F0.5010206@Sun.COM> <49A2F5C5.1060102@Sun.COM> <1235464365.11128.157.camel@localhost.localdomain> <48766DA7-1568-4F9B-B516-2579EB59D0A7@sun.com> <1235501166.11128.195.camel@localhost.localdomain> Message-ID: On Feb 24, 2009, at 10:46 AM, Christian Thalinger wrote: > On Tue, 2009-02-24 at 10:43 -0800, Tom Rodriguez wrote: >> On Feb 24, 2009, at 12:32 AM, Christian Thalinger wrote: >> >>> On Mon, 2009-02-23 at 11:15 -0800, Peter B. Kessler wrote: >>>> Peter B. Kessler wrote: >>>>> This comment is so wrong as almost to qualify as malicious. >>>>> Here's a >>>>> patch that might help. >>>>> >>>>> src/share/vm/opto/node.cpp >>>>> >>>>> 971 // If you modify the 'this' pointer's inputs, you must use >>>>> 'set_req' with >>>>> 972 // def-use info. If you are making a new Node (either as >>>>> the new root or >>>>> 973 // some new internal piece) you must NOT use set_req with >>>>> def-use info. >>>>> 974 // You can make a new Node with either 'new' or 'clone'. >>>>> In either case, >>>>> 975 // def-use info is (correctly) not generated. >> >> This piece isn't valid either. There's no separate du argument to >> any >> of the set functions anymore. > > Remove all 5 lines? Maybe this? tom diff --git a/src/share/vm/opto/node.cpp b/src/share/vm/opto/node.cpp --- a/src/share/vm/opto/node.cpp +++ b/src/share/vm/opto/node.cpp @@ -968,14 +968,15 @@ const Type *Node::Value( PhaseTransform // Example: when reshape "(X+3)+4" into "X+7" you must leave the Node for // "X+3" unchanged in case it is shared. // -// If you modify the 'this' pointer's inputs, you must use 'set_req' with -// def-use info. If you are making a new Node (either as the new root or -// some new internal piece) you must NOT use set_req with def-use info. -// You can make a new Node with either 'new' or 'clone'. In either case, -// def-use info is (correctly) not generated. +// If you modify the 'this' pointer's inputs, you should use +// 'set_req'. If you are making a new Node (either as the new root or +// some new internal piece) you may use 'init_req' to set the initial +// value. You can make a new Node with either 'new' or 'clone'. In +// either case, def-use info is correctly maintained. +// // Example: reshape "(X+3)+4" into "X+7": -// set_req(1,in(1)->in(1) /* grab X */, du /* must use DU on 'this' */); -// set_req(2,phase->intcon(7),du); +// set_req(1,in(1)->in(1)); +// set_req(2,phase->intcon(7)); // return this; // Example: reshape "X*4" into "X<<1" // return new (C,3) LShiftINode( in(1), phase->intcon(1) ); > > > -- Christian > From Christian.Thalinger at Sun.COM Tue Feb 24 10:57:18 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 24 Feb 2009 19:57:18 +0100 Subject: Patch for misleading comment in src/share/vm/opto/node.cpp In-Reply-To: References: <49A2F3F0.5010206@Sun.COM> <49A2F5C5.1060102@Sun.COM> <1235464365.11128.157.camel@localhost.localdomain> <48766DA7-1568-4F9B-B516-2579EB59D0A7@sun.com> <1235501166.11128.195.camel@localhost.localdomain> Message-ID: <1235501838.11128.197.camel@localhost.localdomain> On Tue, 2009-02-24 at 10:53 -0800, Tom Rodriguez wrote: > >> This piece isn't valid either. There's no separate du argument to > >> any > >> of the set functions anymore. > > > > Remove all 5 lines? > > Maybe this? Looks good to me. If you like I can add it to my changes. I will shortly open a CR and push my findings. -- Christian From Thomas.Rodriguez at Sun.COM Tue Feb 24 14:02:12 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 24 Feb 2009 14:02:12 -0800 Subject: review (S) for 6805427: adlc compiler may generate incorrect machnode emission code Message-ID: <7E877828-E1DF-41C6-AD89-50AAD5D2C569@Sun.COM> http://cr.openjdk.java.net/~never/6805427 From Vladimir.Kozlov at Sun.COM Tue Feb 24 14:05:11 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 24 Feb 2009 14:05:11 -0800 Subject: review (S) for 6805427: adlc compiler may generate incorrect machnode emission code In-Reply-To: <7E877828-E1DF-41C6-AD89-50AAD5D2C569@Sun.COM> References: <7E877828-E1DF-41C6-AD89-50AAD5D2C569@Sun.COM> Message-ID: <49A46F17.6070303@sun.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6805427 > From vladimir.kozlov at sun.com Tue Feb 24 16:44:08 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 25 Feb 2009 00:44:08 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 3 new changesets Message-ID: <20090225004414.476CBE0E3@hg.openjdk.java.net> Changeset: 9e5a6ed08fc9 Author: jmasa Date: 2009-02-17 15:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9e5a6ed08fc9 6786346: intermittent Internal Error (src/share/vm/memory/cardTableModRefBS.cpp:226) Summary: Two assertions were incorrectly composed. Reviewed-by: tonyp ! src/share/vm/memory/cardTableModRefBS.cpp Changeset: a0576ae7045f Author: ysr Date: 2009-02-20 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a0576ae7045f Merge Changeset: e57b6f22d1f3 Author: kvn Date: 2009-02-24 09:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e57b6f22d1f3 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 From Christian.Thalinger at Sun.COM Wed Feb 25 00:15:46 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 25 Feb 2009 09:15:46 +0100 Subject: review (S) for 6805427: adlc compiler may generate incorrect machnode emission code In-Reply-To: <7E877828-E1DF-41C6-AD89-50AAD5D2C569@Sun.COM> References: <7E877828-E1DF-41C6-AD89-50AAD5D2C569@Sun.COM> Message-ID: <1235549746.11128.207.camel@localhost.localdomain> On Tue, 2009-02-24 at 14:02 -0800, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6805427 As far as I can tell this looks good. But I'm not an expert, so take it with a grain of salt. -- Christian From Azeem.Jiva at amd.com Wed Feb 25 05:53:54 2009 From: Azeem.Jiva at amd.com (Jiva, Azeem) Date: Wed, 25 Feb 2009 07:53:54 -0600 Subject: MFENCE vs. LOCK addl Message-ID: I was looking at memory barrier performance and noticed that HotSpot uses MFENCE as a memory barrier in 64bit mode. MFENCE is significantly slower than using a LOCKed instruction, since MFENCE is serializing (similar to CPUID). I'd like to recommend the following change: assembler_x86.cpp // Serializes memory. void Assembler::mfence() { // Memory barriers are only needed on multiprocessors if (os::is_MP()) { // All usable chips support "locked" instructions which suffice // as barriers, and are much faster than the alternative of // using cpuid or mfence instructions. We use here a locked add [esp],0. // This is conveniently otherwise a no-op except for blowing // flags (which we save and restore.) pushf(); // Save eflags register lock(); addl(Address(rsp, 0), 0);// Assert the lock# signal here popf(); // Restore eflags register } } Sorry it's not a diff, but I'm not setup with mercurial yet. Only application I've ran is SPECjbb2005, and there are no regressions or gains. Mostly because the generated code from SPECjbb2005 doesn't use MFENCE in any significant amount. -- Azeem Jiva AMD Java Labs T 512.602.0907 From Paul.Hohensee at Sun.COM Wed Feb 25 06:11:53 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 25 Feb 2009 09:11:53 -0500 Subject: MFENCE vs. LOCK addl In-Reply-To: References: Message-ID: <49A551A9.8090305@sun.com> What do pushf and popf cost? Do locked operations actually have 2-way barrier semantics from an external pov? Paul Jiva, Azeem wrote: > I was looking at memory barrier performance and noticed that HotSpot > uses MFENCE as a memory barrier in 64bit mode. MFENCE is significantly > slower than using a LOCKed instruction, since MFENCE is serializing > (similar to CPUID). I'd like to recommend the following change: > > assembler_x86.cpp > // Serializes memory. > void Assembler::mfence() { > // Memory barriers are only needed on multiprocessors > if (os::is_MP()) { > // All usable chips support "locked" instructions which suffice > // as barriers, and are much faster than the alternative of > // using cpuid or mfence instructions. We use here a locked add > [esp],0. > // This is conveniently otherwise a no-op except for blowing > // flags (which we save and restore.) > pushf(); // Save eflags register > lock(); > addl(Address(rsp, 0), 0);// Assert the lock# signal here > popf(); // Restore eflags register > > } > } > > > Sorry it's not a diff, but I'm not setup with mercurial yet. Only > application I've ran is SPECjbb2005, and there are no regressions or > gains. Mostly because the generated code from SPECjbb2005 doesn't use > MFENCE in any significant amount. > > -- > Azeem Jiva > AMD Java Labs > T 512.602.0907 > > > From Azeem.Jiva at amd.com Wed Feb 25 07:05:16 2009 From: Azeem.Jiva at amd.com (Jiva, Azeem) Date: Wed, 25 Feb 2009 09:05:16 -0600 Subject: MFENCE vs. LOCK addl In-Reply-To: <49A551A9.8090305@sun.com> References: <49A551A9.8090305@sun.com> Message-ID: Paul, Ahh right, I did some experiments with running MFENCE vs. LOCK ADDL and MFENCE vs. PUSH/LOCK ADDL/POPF and found that MFENCE is faster than PUSH/LOCK/POP but not faster than just using the LOCK instruction by itself. A nice optimization would be if the JVM could detect if the condition codes needed to be saved instead of saving them always. This is on AMD hardware, and other systems might have different performance issues. -- Azeem Jiva AMD Java Labs T 512.602.0907 > -----Original Message----- > From: Paul.Hohensee at Sun.COM [mailto:Paul.Hohensee at Sun.COM] > Sent: Wednesday, February 25, 2009 8:12 AM > To: Jiva, Azeem > Cc: hotspot compiler > Subject: Re: MFENCE vs. LOCK addl > > What do pushf and popf cost? Do locked operations actually have > 2-way barrier semantics from an external pov? > > Paul > > Jiva, Azeem wrote: > > I was looking at memory barrier performance and noticed that HotSpot > > uses MFENCE as a memory barrier in 64bit mode. MFENCE is significantly > > slower than using a LOCKed instruction, since MFENCE is serializing > > (similar to CPUID). I'd like to recommend the following change: > > > > assembler_x86.cpp > > // Serializes memory. > > void Assembler::mfence() { > > // Memory barriers are only needed on multiprocessors > > if (os::is_MP()) { > > // All usable chips support "locked" instructions which suffice > > // as barriers, and are much faster than the alternative of > > // using cpuid or mfence instructions. We use here a locked add > > [esp],0. > > // This is conveniently otherwise a no-op except for blowing > > // flags (which we save and restore.) > > pushf(); // Save eflags register > > lock(); > > addl(Address(rsp, 0), 0);// Assert the lock# signal here > > popf(); // Restore eflags register > > > > } > > } > > > > > > Sorry it's not a diff, but I'm not setup with mercurial yet. Only > > application I've ran is SPECjbb2005, and there are no regressions or > > gains. Mostly because the generated code from SPECjbb2005 doesn't use > > MFENCE in any significant amount. > > > > -- > > Azeem Jiva > > AMD Java Labs > > T 512.602.0907 > > > > > > From John.Rose at Sun.COM Wed Feb 25 11:57:52 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 25 Feb 2009 11:57:52 -0800 Subject: MFENCE vs. LOCK addl In-Reply-To: References: <49A551A9.8090305@sun.com> Message-ID: <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> What about XCHG? It doesn't set flags, and (as a bonus) it implies the effect of a LOCK prefix: push rax xchg rax pop rax -- John On Feb 25, 2009, at 7:05 AM, Jiva, Azeem wrote: > Paul, > Ahh right, I did some experiments with running MFENCE vs. LOCK ADDL > and MFENCE vs. PUSH/LOCK ADDL/POPF and found that MFENCE is faster > than > PUSH/LOCK/POP but not faster than just using the LOCK instruction by > itself. A nice optimization would be if the JVM could detect if the > condition codes needed to be saved instead of saving them always. > This > is on AMD hardware, and other systems might have different performance > issues. From Paul.Hohensee at Sun.COM Wed Feb 25 12:19:46 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 25 Feb 2009 15:19:46 -0500 Subject: MFENCE vs. LOCK addl In-Reply-To: <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> References: <49A551A9.8090305@sun.com> <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> Message-ID: <49A5A7E2.8060001@sun.com> Good idea. Can you try it, Azeem? Paul John Rose wrote: > What about XCHG? It doesn't set flags, and (as a bonus) it implies > the effect of a LOCK prefix: > push rax > xchg rax > pop rax > > -- John > > On Feb 25, 2009, at 7:05 AM, Jiva, Azeem wrote: > >> Paul, >> Ahh right, I did some experiments with running MFENCE vs. LOCK ADDL >> and MFENCE vs. PUSH/LOCK ADDL/POPF and found that MFENCE is faster than >> PUSH/LOCK/POP but not faster than just using the LOCK instruction by >> itself. A nice optimization would be if the JVM could detect if the >> condition codes needed to be saved instead of saving them always. This >> is on AMD hardware, and other systems might have different performance >> issues. > From Azeem.Jiva at amd.com Wed Feb 25 12:31:21 2009 From: Azeem.Jiva at amd.com (Jiva, Azeem) Date: Wed, 25 Feb 2009 14:31:21 -0600 Subject: MFENCE vs. LOCK addl In-Reply-To: <49A5A7E2.8060001@sun.com> References: <49A551A9.8090305@sun.com> <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> <49A5A7E2.8060001@sun.com> Message-ID: John, Paul -- Yeah I had tried that and was in the process of writing that up. It is better than an MFENCE and has the added benefit of not needing a system with SSE2+. I still don't have a good JVM case but the assembler run shows that it's faster than MFENCE. My na?ve change to assembler_x86.cpp: void Assembler::mfence() { // Memory barriers are only needed on multiprocessors if (os::is_MP()) { // All usable chips support "locked" instructions which suffice // as barriers, and are much faster than the alternative of // using cpuid instruction. We use here a xchg which is implicitly locked // This is conveniently otherwise a no-op except for blowing // rax (which we save and restore.) push(rax); // Store RAX register xchgl(rax, Address(rsp, 0)); pop(rax); // Restore RAX register } } -- Azeem Jiva AMD Java Labs T 512.602.0907 > -----Original Message----- > From: Paul.Hohensee at Sun.COM [mailto:Paul.Hohensee at Sun.COM] > Sent: Wednesday, February 25, 2009 2:20 PM > To: John Rose > Cc: Jiva, Azeem; hotspot compiler > Subject: Re: MFENCE vs. LOCK addl > > Good idea. Can you try it, Azeem? > > Paul > > John Rose wrote: > > What about XCHG? It doesn't set flags, and (as a bonus) it implies > > the effect of a LOCK prefix: > > push rax > > xchg rax > > pop rax > > > > -- John > > > > On Feb 25, 2009, at 7:05 AM, Jiva, Azeem wrote: > > > >> Paul, > >> Ahh right, I did some experiments with running MFENCE vs. LOCK ADDL > >> and MFENCE vs. PUSH/LOCK ADDL/POPF and found that MFENCE is faster > than > >> PUSH/LOCK/POP but not faster than just using the LOCK instruction by > >> itself. A nice optimization would be if the JVM could detect if the > >> condition codes needed to be saved instead of saving them always. This > >> is on AMD hardware, and other systems might have different > performance > >> issues. > > From Thomas.Rodriguez at Sun.COM Wed Feb 25 12:45:00 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 25 Feb 2009 12:45:00 -0800 Subject: MFENCE vs. LOCK addl In-Reply-To: References: <49A551A9.8090305@sun.com> <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> <49A5A7E2.8060001@sun.com> Message-ID: <9F69FDBF-2941-433A-938E-7D4B3399FF0A@sun.com> Assembler::mfence is used in places where optimizing it wouldn't seem to matter to me. As far as killing the condition flags go I don't think any piece of code which calls mfence cares. There are only about 5 calls which seems easy to audit. Avoiding push/pop at all seems much better to me. So if mfence is equivalent in power to any old locked instruction why is it so much more expensive? It seems like it either must be doing something more or it's a really crappy implementation. Are we sure the callers don't need the something more part? As an aside, it seems odd that something in the Assembler that's named after a real instruction would never actually emit that instruction. Shouldn't mfence emit mfence and all current callers call something else which might sometimes emit mfence? tom On Feb 25, 2009, at 12:31 PM, Jiva, Azeem wrote: > John, Paul -- > Yeah I had tried that and was in the process of writing that up. > It is better than an MFENCE and has the added benefit of not needing > a system with SSE2+. I still don't have a good JVM case but the > assembler run shows that it's faster than MFENCE. My na?ve change > to assembler_x86.cpp: > > void Assembler::mfence() { > // Memory barriers are only needed on multiprocessors > if (os::is_MP()) { > // All usable chips support "locked" instructions which suffice > // as barriers, and are much faster than the alternative of > // using cpuid instruction. We use here a xchg which is > implicitly locked > // This is conveniently otherwise a no-op except for blowing > // rax (which we save and restore.) > push(rax); // Store RAX register > xchgl(rax, Address(rsp, 0)); > pop(rax); // Restore RAX register > } > } > > -- > Azeem Jiva > AMD Java Labs > T 512.602.0907 > >> -----Original Message----- >> From: Paul.Hohensee at Sun.COM [mailto:Paul.Hohensee at Sun.COM] >> Sent: Wednesday, February 25, 2009 2:20 PM >> To: John Rose >> Cc: Jiva, Azeem; hotspot compiler >> Subject: Re: MFENCE vs. LOCK addl >> >> Good idea. Can you try it, Azeem? >> >> Paul >> >> John Rose wrote: >>> What about XCHG? It doesn't set flags, and (as a bonus) it implies >>> the effect of a LOCK prefix: >>> push rax >>> xchg rax >>> pop rax >>> >>> -- John >>> >>> On Feb 25, 2009, at 7:05 AM, Jiva, Azeem wrote: >>> >>>> Paul, >>>> Ahh right, I did some experiments with running MFENCE vs. LOCK ADDL >>>> and MFENCE vs. PUSH/LOCK ADDL/POPF and found that MFENCE is faster >> than >>>> PUSH/LOCK/POP but not faster than just using the LOCK instruction >>>> by >>>> itself. A nice optimization would be if the JVM could detect if >>>> the >>>> condition codes needed to be saved instead of saving them >>>> always. This >>>> is on AMD hardware, and other systems might have different >> performance >>>> issues. >>> > > From Paul.Hohensee at Sun.COM Wed Feb 25 12:53:45 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 25 Feb 2009 15:53:45 -0500 Subject: MFENCE vs. LOCK addl In-Reply-To: <9F69FDBF-2941-433A-938E-7D4B3399FF0A@sun.com> References: <49A551A9.8090305@sun.com> <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> <49A5A7E2.8060001@sun.com> <9F69FDBF-2941-433A-938E-7D4B3399FF0A@sun.com> Message-ID: <49A5AFD9.9070003@sun.com> The name 'mfence()' is an artifact. It means to do the equivalent of OrderAccess::fence(). Paul Tom Rodriguez wrote: > Assembler::mfence is used in places where optimizing it wouldn't seem > to matter to me. As far as killing the condition flags go I don't > think any piece of code which calls mfence cares. There are only > about 5 calls which seems easy to audit. Avoiding push/pop at all > seems much better to me. > > So if mfence is equivalent in power to any old locked instruction why > is it so much more expensive? It seems like it either must be doing > something more or it's a really crappy implementation. Are we sure > the callers don't need the something more part? > > As an aside, it seems odd that something in the Assembler that's named > after a real instruction would never actually emit that instruction. > Shouldn't mfence emit mfence and all current callers call something > else which might sometimes emit mfence? > > tom > > On Feb 25, 2009, at 12:31 PM, Jiva, Azeem wrote: > >> John, Paul -- >> Yeah I had tried that and was in the process of writing that up. It >> is better than an MFENCE and has the added benefit of not needing a >> system with SSE2+. I still don't have a good JVM case but the >> assembler run shows that it's faster than MFENCE. My na?ve change to >> assembler_x86.cpp: >> >> void Assembler::mfence() { >> // Memory barriers are only needed on multiprocessors >> if (os::is_MP()) { >> // All usable chips support "locked" instructions which suffice >> // as barriers, and are much faster than the alternative of >> // using cpuid instruction. We use here a xchg which is >> implicitly locked >> // This is conveniently otherwise a no-op except for blowing >> // rax (which we save and restore.) >> push(rax); // Store RAX register >> xchgl(rax, Address(rsp, 0)); >> pop(rax); // Restore RAX register >> } >> } >> >> -- >> Azeem Jiva >> AMD Java Labs >> T 512.602.0907 >> >>> -----Original Message----- >>> From: Paul.Hohensee at Sun.COM [mailto:Paul.Hohensee at Sun.COM] >>> Sent: Wednesday, February 25, 2009 2:20 PM >>> To: John Rose >>> Cc: Jiva, Azeem; hotspot compiler >>> Subject: Re: MFENCE vs. LOCK addl >>> >>> Good idea. Can you try it, Azeem? >>> >>> Paul >>> >>> John Rose wrote: >>>> What about XCHG? It doesn't set flags, and (as a bonus) it implies >>>> the effect of a LOCK prefix: >>>> push rax >>>> xchg rax >>>> pop rax >>>> >>>> -- John >>>> >>>> On Feb 25, 2009, at 7:05 AM, Jiva, Azeem wrote: >>>> >>>>> Paul, >>>>> Ahh right, I did some experiments with running MFENCE vs. LOCK ADDL >>>>> and MFENCE vs. PUSH/LOCK ADDL/POPF and found that MFENCE is faster >>> than >>>>> PUSH/LOCK/POP but not faster than just using the LOCK instruction by >>>>> itself. A nice optimization would be if the JVM could detect if the >>>>> condition codes needed to be saved instead of saving them >>>>> always. This >>>>> is on AMD hardware, and other systems might have different >>> performance >>>>> issues. >>>> >> >> > From thomas.rodriguez at sun.com Wed Feb 25 13:31:48 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 25 Feb 2009 21:31:48 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6805427: adlc compiler may generate incorrect machnode emission code Message-ID: <20090225213150.D8A2BE156@hg.openjdk.java.net> Changeset: 0ad1cb407fa1 Author: never Date: 2009-02-25 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0ad1cb407fa1 6805427: adlc compiler may generate incorrect machnode emission code Reviewed-by: kvn, twisti ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp From Thomas.Rodriguez at Sun.COM Wed Feb 25 14:36:12 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 25 Feb 2009 14:36:12 -0800 Subject: MFENCE vs. LOCK addl In-Reply-To: <49A5AFD9.9070003@sun.com> References: <49A551A9.8090305@sun.com> <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> <49A5A7E2.8060001@sun.com> <9F69FDBF-2941-433A-938E-7D4B3399FF0A@sun.com> <49A5AFD9.9070003@sun.com> Message-ID: <09E12B8E-253E-405B-97A5-3715287CFCC2@Sun.COM> Maybe at one point it was an artifact but there's actual a real mfence instruction. It seems like it needs to be renamed, particularly if it ever stops producing a real mfence. Things in Assembler are really just supposed to emit exactly what they say they are with no translation or optimization. MacroAssembler is where logic for choosing more optimal patterns should live. tom On Feb 25, 2009, at 12:53 PM, Paul Hohensee wrote: > The name 'mfence()' is an artifact. It means to do the equivalent > of OrderAccess::fence(). > > Paul > > Tom Rodriguez wrote: >> Assembler::mfence is used in places where optimizing it wouldn't >> seem to matter to me. As far as killing the condition flags go I >> don't think any piece of code which calls mfence cares. There are >> only about 5 calls which seems easy to audit. Avoiding push/pop at >> all seems much better to me. >> >> So if mfence is equivalent in power to any old locked instruction >> why is it so much more expensive? It seems like it either must be >> doing something more or it's a really crappy implementation. Are >> we sure the callers don't need the something more part? >> >> As an aside, it seems odd that something in the Assembler that's >> named after a real instruction would never actually emit that >> instruction. Shouldn't mfence emit mfence and all current callers >> call something else which might sometimes emit mfence? >> >> tom >> >> On Feb 25, 2009, at 12:31 PM, Jiva, Azeem wrote: >> >>> John, Paul -- >>> Yeah I had tried that and was in the process of writing that up. >>> It is better than an MFENCE and has the added benefit of not >>> needing a system with SSE2+. I still don't have a good JVM case >>> but the assembler run shows that it's faster than MFENCE. My >>> na?ve change to assembler_x86.cpp: >>> >>> void Assembler::mfence() { >>> // Memory barriers are only needed on multiprocessors >>> if (os::is_MP()) { >>> // All usable chips support "locked" instructions which suffice >>> // as barriers, and are much faster than the alternative of >>> // using cpuid instruction. We use here a xchg which is >>> implicitly locked >>> // This is conveniently otherwise a no-op except for blowing >>> // rax (which we save and restore.) >>> push(rax); // Store RAX register >>> xchgl(rax, Address(rsp, 0)); >>> pop(rax); // Restore RAX register >>> } >>> } >>> >>> -- >>> Azeem Jiva >>> AMD Java Labs >>> T 512.602.0907 >>> >>>> -----Original Message----- >>>> From: Paul.Hohensee at Sun.COM [mailto:Paul.Hohensee at Sun.COM] >>>> Sent: Wednesday, February 25, 2009 2:20 PM >>>> To: John Rose >>>> Cc: Jiva, Azeem; hotspot compiler >>>> Subject: Re: MFENCE vs. LOCK addl >>>> >>>> Good idea. Can you try it, Azeem? >>>> >>>> Paul >>>> >>>> John Rose wrote: >>>>> What about XCHG? It doesn't set flags, and (as a bonus) it >>>>> implies >>>>> the effect of a LOCK prefix: >>>>> push rax >>>>> xchg rax >>>>> pop rax >>>>> >>>>> -- John >>>>> >>>>> On Feb 25, 2009, at 7:05 AM, Jiva, Azeem wrote: >>>>> >>>>>> Paul, >>>>>> Ahh right, I did some experiments with running MFENCE vs. LOCK >>>>>> ADDL >>>>>> and MFENCE vs. PUSH/LOCK ADDL/POPF and found that MFENCE is >>>>>> faster >>>> than >>>>>> PUSH/LOCK/POP but not faster than just using the LOCK >>>>>> instruction by >>>>>> itself. A nice optimization would be if the JVM could detect >>>>>> if the >>>>>> condition codes needed to be saved instead of saving them >>>>>> always. This >>>>>> is on AMD hardware, and other systems might have different >>>> performance >>>>>> issues. >>>>> >>> >>> >> From John.Rose at Sun.COM Wed Feb 25 15:30:27 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 25 Feb 2009 15:30:27 -0800 Subject: MFENCE vs. LOCK addl In-Reply-To: <49A5AFD9.9070003@sun.com> References: <49A551A9.8090305@sun.com> <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> <49A5A7E2.8060001@sun.com> <9F69FDBF-2941-433A-938E-7D4B3399FF0A@sun.com> <49A5AFD9.9070003@sun.com> Message-ID: <65036D46-7169-42E9-A3A6-5A4C04B783FC@sun.com> Tom Rodriguez wrote: > Avoiding push/pop at all seems much better to me. Another way to avoid push/pop is to just double the xchgq/l: xchgq rax, (rsp, 0) xchgq rax, (rsp, 0) From Peter.Kessler at Sun.COM Wed Feb 25 15:39:54 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Wed, 25 Feb 2009 15:39:54 -0800 Subject: MFENCE vs. LOCK addl In-Reply-To: <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> References: <49A551A9.8090305@sun.com> <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> Message-ID: <49A5D6CA.8010801@Sun.COM> I think xchg only implies lock if one of the operands is in memory, but I'm looking at the Intel books, not the AMD ones. You only show one register operand, so it's hard to tell if you mean, for example, "lock; xchg rax, rax", which doesn't reference memory. If that's what you mean, I don't think you need the push/pop around the xchg, because rax will be unaffected by the xchg. Also note that "xchg rax, rax" is the encoding for the one-byte nop. Is the effect of the lock the same on a nop as it is for a real instruction, or is someone too clever for our purposes? You could choose to do a locked exchange of some other register with itself. ... peter John Rose wrote: > What about XCHG? It doesn't set flags, and (as a bonus) it implies the > effect of a LOCK prefix: > push rax > xchg rax > pop rax > > -- John > > On Feb 25, 2009, at 7:05 AM, Jiva, Azeem wrote: > >> Paul, >> Ahh right, I did some experiments with running MFENCE vs. LOCK ADDL >> and MFENCE vs. PUSH/LOCK ADDL/POPF and found that MFENCE is faster than >> PUSH/LOCK/POP but not faster than just using the LOCK instruction by >> itself. A nice optimization would be if the JVM could detect if the >> condition codes needed to be saved instead of saving them always. This >> is on AMD hardware, and other systems might have different performance >> issues. From John.Rose at Sun.COM Wed Feb 25 16:05:33 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 25 Feb 2009 16:05:33 -0800 Subject: MFENCE vs. LOCK addl In-Reply-To: <49A5D6CA.8010801@Sun.COM> References: <49A551A9.8090305@sun.com> <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> <49A5D6CA.8010801@Sun.COM> Message-ID: <3FF15F8C-B60C-4265-BCCA-D6ADD24F9CA9@Sun.COM> On Feb 25, 2009, at 3:39 PM, Peter B. Kessler wrote: > I think xchg only implies lock if one of the operands is in memory, > but I'm looking at the Intel books, not the AMD ones. > John Rose wrote: >> What about XCHG? It doesn't set flags, and (as a bonus) it implies >> the effect of a LOCK prefix: >> push rax >> xchg rax Oops, sorry; I meant xchg rax, Address(rsp, 0) >> pop rax From thomas.rodriguez at sun.com Wed Feb 25 18:33:04 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 26 Feb 2009 02:33:04 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6807963: need tool to make sense of LogCompilaton output Message-ID: <20090226023307.6B1C5E17B@hg.openjdk.java.net> Changeset: 07d449658fc7 Author: never Date: 2009-02-25 14:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/07d449658fc7 6807963: need tool to make sense of LogCompilaton output Reviewed-by: kvn + src/share/tools/LogCompilation/Makefile + src/share/tools/LogCompilation/README + src/share/tools/LogCompilation/manifest.mf + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/BasicLogEvent.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Compilation.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Constants.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCleanupReader.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogEvent.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/MakeNotEntrantEvent.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Method.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/NMethod.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/UncommonTrapEvent.java From Azeem.Jiva at amd.com Wed Feb 25 20:05:45 2009 From: Azeem.Jiva at amd.com (Jiva, Azeem) Date: Wed, 25 Feb 2009 22:05:45 -0600 Subject: MFENCE vs. LOCK addl References: <49A551A9.8090305@sun.com> <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> <49A5A7E2.8060001@sun.com> <9F69FDBF-2941-433A-938E-7D4B3399FF0A@sun.com> <49A5AFD9.9070003@sun.com> <65036D46-7169-42E9-A3A6-5A4C04B783FC@sun.com> Message-ID: Except that gets you two locked xchgs, which is slower than an mfence. My proposal is: push rax xchg rax, (rsp) pop rax -----Original Message----- From: John Rose [mailto:John.Rose at Sun.COM] Sent: Wed 2/25/2009 5:30 PM To: Paul Hohensee Cc: Tom Rodriguez; hotspot compiler; Jiva, Azeem Subject: Re: MFENCE vs. LOCK addl Tom Rodriguez wrote: > Avoiding push/pop at all seems much better to me. Another way to avoid push/pop is to just double the xchgq/l: xchgq rax, (rsp, 0) xchgq rax, (rsp, 0) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090225/ed87775a/attachment.html From Paul.Hohensee at Sun.COM Thu Feb 26 06:46:42 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Thu, 26 Feb 2009 09:46:42 -0500 Subject: MFENCE vs. LOCK addl In-Reply-To: <09E12B8E-253E-405B-97A5-3715287CFCC2@Sun.COM> References: <49A551A9.8090305@sun.com> <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> <49A5A7E2.8060001@sun.com> <9F69FDBF-2941-433A-938E-7D4B3399FF0A@sun.com> <49A5AFD9.9070003@sun.com> <09E12B8E-253E-405B-97A5-3715287CFCC2@Sun.COM> Message-ID: <49A6AB52.8020600@sun.com> In that case, moving it to MacroAssembler is the right thing to do. And rename it just "fence" or some such. Leave "mfence" in Assembler to unconditionally emit a real mfence instruction. Paul Tom Rodriguez wrote: > Maybe at one point it was an artifact but there's actual a real mfence > instruction. It seems like it needs to be renamed, particularly if it > ever stops producing a real mfence. Things in Assembler are really > just supposed to emit exactly what they say they are with no > translation or optimization. MacroAssembler is where logic for > choosing more optimal patterns should live. > > tom > > On Feb 25, 2009, at 12:53 PM, Paul Hohensee wrote: > >> The name 'mfence()' is an artifact. It means to do the equivalent of >> OrderAccess::fence(). >> >> Paul >> >> Tom Rodriguez wrote: >>> Assembler::mfence is used in places where optimizing it wouldn't >>> seem to matter to me. As far as killing the condition flags go I >>> don't think any piece of code which calls mfence cares. There are >>> only about 5 calls which seems easy to audit. Avoiding push/pop at >>> all seems much better to me. >>> >>> So if mfence is equivalent in power to any old locked instruction >>> why is it so much more expensive? It seems like it either must be >>> doing something more or it's a really crappy implementation. Are we >>> sure the callers don't need the something more part? >>> >>> As an aside, it seems odd that something in the Assembler that's >>> named after a real instruction would never actually emit that >>> instruction. Shouldn't mfence emit mfence and all current callers >>> call something else which might sometimes emit mfence? >>> >>> tom >>> >>> On Feb 25, 2009, at 12:31 PM, Jiva, Azeem wrote: >>> >>>> John, Paul -- >>>> Yeah I had tried that and was in the process of writing that up. >>>> It is better than an MFENCE and has the added benefit of not >>>> needing a system with SSE2+. I still don't have a good JVM case >>>> but the assembler run shows that it's faster than MFENCE. My na?ve >>>> change to assembler_x86.cpp: >>>> >>>> void Assembler::mfence() { >>>> // Memory barriers are only needed on multiprocessors >>>> if (os::is_MP()) { >>>> // All usable chips support "locked" instructions which suffice >>>> // as barriers, and are much faster than the alternative of >>>> // using cpuid instruction. We use here a xchg which is >>>> implicitly locked >>>> // This is conveniently otherwise a no-op except for blowing >>>> // rax (which we save and restore.) >>>> push(rax); // Store RAX register >>>> xchgl(rax, Address(rsp, 0)); >>>> pop(rax); // Restore RAX register >>>> } >>>> } >>>> >>>> -- >>>> Azeem Jiva >>>> AMD Java Labs >>>> T 512.602.0907 >>>> >>>>> -----Original Message----- >>>>> From: Paul.Hohensee at Sun.COM [mailto:Paul.Hohensee at Sun.COM] >>>>> Sent: Wednesday, February 25, 2009 2:20 PM >>>>> To: John Rose >>>>> Cc: Jiva, Azeem; hotspot compiler >>>>> Subject: Re: MFENCE vs. LOCK addl >>>>> >>>>> Good idea. Can you try it, Azeem? >>>>> >>>>> Paul >>>>> >>>>> John Rose wrote: >>>>>> What about XCHG? It doesn't set flags, and (as a bonus) it implies >>>>>> the effect of a LOCK prefix: >>>>>> push rax >>>>>> xchg rax >>>>>> pop rax >>>>>> >>>>>> -- John >>>>>> >>>>>> On Feb 25, 2009, at 7:05 AM, Jiva, Azeem wrote: >>>>>> >>>>>>> Paul, >>>>>>> Ahh right, I did some experiments with running MFENCE vs. LOCK ADDL >>>>>>> and MFENCE vs. PUSH/LOCK ADDL/POPF and found that MFENCE is faster >>>>> than >>>>>>> PUSH/LOCK/POP but not faster than just using the LOCK >>>>>>> instruction by >>>>>>> itself. A nice optimization would be if the JVM could detect if >>>>>>> the >>>>>>> condition codes needed to be saved instead of saving them >>>>>>> always. This >>>>>>> is on AMD hardware, and other systems might have different >>>>> performance >>>>>>> issues. >>>>>> >>>> >>>> >>> > From Paul.Hohensee at Sun.COM Thu Feb 26 07:20:39 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Thu, 26 Feb 2009 10:20:39 -0500 Subject: MFENCE vs. LOCK addl In-Reply-To: <49A5D6CA.8010801@Sun.COM> References: <49A551A9.8090305@sun.com> <311D7229-66CE-441D-A018-95B17EAAEF5E@sun.com> <49A5D6CA.8010801@Sun.COM> Message-ID: <49A6B347.2020003@sun.com> Yes, xchg only implies lock if one of the operands is in memory. Might also be restricted to the destination operand being in memory. AMD has to do the same thing as Intel, so the Intel books rule. Paul Peter B. Kessler wrote: > I think xchg only implies lock if one of the operands is in memory, > but I'm looking at the Intel books, not the AMD ones. You only show > one register operand, so it's hard to tell if you mean, for example, > "lock; xchg rax, rax", which doesn't reference memory. If that's what > you mean, I don't think you need the push/pop around the xchg, because > rax will be unaffected by the xchg. > > Also note that "xchg rax, rax" is the encoding for the one-byte nop. > Is the effect of the lock the same on a nop as it is for a real > instruction, or is someone too clever for our purposes? You could > choose to do a locked exchange of some other register with itself. > > ... peter > > John Rose wrote: >> What about XCHG? It doesn't set flags, and (as a bonus) it implies >> the effect of a LOCK prefix: >> push rax >> xchg rax >> pop rax >> >> -- John >> >> On Feb 25, 2009, at 7:05 AM, Jiva, Azeem wrote: >> >>> Paul, >>> Ahh right, I did some experiments with running MFENCE vs. LOCK ADDL >>> and MFENCE vs. PUSH/LOCK ADDL/POPF and found that MFENCE is faster than >>> PUSH/LOCK/POP but not faster than just using the LOCK instruction by >>> itself. A nice optimization would be if the JVM could detect if the >>> condition codes needed to be saved instead of saving them always. >>> This >>> is on AMD hardware, and other systems might have different performance >>> issues. From Christian.Thalinger at Sun.COM Thu Feb 26 08:41:20 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 26 Feb 2009 17:41:20 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class Message-ID: <1235666480.2004.256.camel@localhost.localdomain> http://cr.openjdk.java.net/~twisti/6797305/webrev.00/ Here is the (almost) final version of my unsigned load changes. I added enc_class functions for all load instructions on x86_32 and x86_64. Should I do the same for sparc too? -- Christian From Ulf.Zibis at gmx.de Thu Feb 26 09:00:28 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 26 Feb 2009 18:00:28 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1235666480.2004.256.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> Message-ID: <49A6CAAC.5050003@gmx.de> Christian, thanks for the news. Is LoadUB from array now as fast as the +0x80 trick ? -Ulf Am 26.02.2009 17:41, Christian Thalinger schrieb: > http://cr.openjdk.java.net/~twisti/6797305/webrev.00/ > > Here is the (almost) final version of my unsigned load changes. I added > enc_class functions for all load instructions on x86_32 and x86_64. > Should I do the same for sparc too? > > -- Christian > > > From Thomas.Rodriguez at Sun.COM Thu Feb 26 09:02:10 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 26 Feb 2009 09:02:10 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1235666480.2004.256.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> Message-ID: <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> I haven't looked through all your changes yet but instead of using enc_class you can directly embed the encoding in the instruction like this: +// Load Short (16bit signed) +instruct loadS(eRegI dst, memory mem) %{ + match(Set dst (LoadS mem)); + + ins_cost(125); + format %{ "MOVSX $dst,$mem\t# short" %} + + ins_encode %{ + Address Amem = Address::make_raw($mem$$base, $mem$$index, $mem$ $scale, $mem$$disp); + Register Rdst = as_Register($dst$$reg); + + __ movswl(Rdst, Amem); + %} + ins_pipe(ialu_reg_mem); +%} This style automatically creates a MacroAssembler for you so you can just use __ directly. You can also say $dst$$Register instead of as_Register($dst$$reg). I have some changes somewhere that adds support for $mem$$Address which would make it possible to simply have: inc_encode %{ __ movswl($dst$$Register, $mem$$Address) %} I think this style is a lot more readable than the enc_class stuff. As far as sparc goes I wouldn't mind if they were changed to use the MacroAssembler too. Someday we'd like to convert all the inc_encodes to use MacroAssembler. If we were really slick we could derive the format from the ins_encode block too but that's for another day. tom On Feb 26, 2009, at 8:41 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6797305/webrev.00/ > > Here is the (almost) final version of my unsigned load changes. I > added > enc_class functions for all load instructions on x86_32 and x86_64. > Should I do the same for sparc too? > > -- Christian > From Christian.Thalinger at Sun.COM Thu Feb 26 09:09:18 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 26 Feb 2009 18:09:18 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> Message-ID: <1235668158.2004.289.camel@localhost.localdomain> On Thu, 2009-02-26 at 09:02 -0800, Tom Rodriguez wrote: > I haven't looked through all your changes yet but instead of using > enc_class you can directly embed the encoding in the instruction like > this: > > +// Load Short (16bit signed) > +instruct loadS(eRegI dst, memory mem) %{ > + match(Set dst (LoadS mem)); > + > + ins_cost(125); > + format %{ "MOVSX $dst,$mem\t# short" %} > + > + ins_encode %{ > + Address Amem = Address::make_raw($mem$$base, $mem$$index, $mem$ > $scale, $mem$$disp); > + Register Rdst = as_Register($dst$$reg); > + > + __ movswl(Rdst, Amem); > + %} > + ins_pipe(ialu_reg_mem); > +%} > > This style automatically creates a MacroAssembler for you so you can > just use __ directly. You can also say $dst$$Register instead of > as_Register($dst$$reg). I have some changes somewhere that adds > support for $mem$$Address which would make it possible to simply have: > > inc_encode %{ > __ movswl($dst$$Register, $mem$$Address) > %} > > I think this style is a lot more readable than the enc_class stuff. Much better :-) I'll change that. > > As far as sparc goes I wouldn't mind if they were changed to use the > MacroAssembler too. Well, I could change that, at least for the loads. > Someday we'd like to convert all the inc_encodes > to use MacroAssembler. If we were really slick we could derive the > format from the ins_encode block too but that's for another day. Yeah, that would be nice too. -- Christian From Christian.Thalinger at Sun.COM Thu Feb 26 09:22:31 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 26 Feb 2009 18:22:31 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <49A6CAAC.5050003@gmx.de> References: <1235666480.2004.256.camel@localhost.localdomain> <49A6CAAC.5050003@gmx.de> Message-ID: <1235668951.2004.309.camel@localhost.localdomain> On Thu, 2009-02-26 at 18:00 +0100, Ulf Zibis wrote: > Christian, > > thanks for the news. > > Is LoadUB from array now as fast as the +0x80 trick ? Yes, at least on SPARC. On x86 your benchmarks may trick you as the slowdown is not from the load instruction but from loop unrolling and register pressure. I will look into this issue when I have finished this work (and that includes 5057225). --Christian From Vladimir.Kozlov at Sun.COM Thu Feb 26 10:15:20 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 26 Feb 2009 10:15:20 -0800 Subject: Request for reviews (S): 6809798: SafePointScalarObject node placed into incorrect block during GCM Message-ID: <49A6DC38.80000@sun.com> http://cr.openjdk.java.net/~kvn/6809798/webrev.00 Fixed 6809798: SafePointScalarObject node placed into incorrect block during GCM Problem: The main problem is that the control edge of a pinned node could be replaced during schedule_early after the pinned node scheduled into a block if the control node is a block projection. Also there were few places where the control edge of a SafePointScalarObject node was not adjusted correctly. Solution: Replace the control edge of a pinned node before scheduling. Adjust the control edge of a SafePointScalarObject when needed. Added few asserts to verify scheduling correctness for pinned nodes and SafePointScalarObject node. Reviewed by: Fix verified (y/n): y Other testing: JPRT, CTW (with -XX:+DoEscapeAnalysis) From Vladimir.Kozlov at Sun.COM Thu Feb 26 10:30:54 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 26 Feb 2009 10:30:54 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1235668158.2004.289.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235668158.2004.289.camel@localhost.localdomain> Message-ID: <49A6DFDE.7040709@sun.com> Looks good. I did not look on .ad files since you will rewrite them as Tom suggested. But the rest of changes are good. Thanks, Vladimir Christian Thalinger wrote: > On Thu, 2009-02-26 at 09:02 -0800, Tom Rodriguez wrote: >> I haven't looked through all your changes yet but instead of using >> enc_class you can directly embed the encoding in the instruction like >> this: >> >> +// Load Short (16bit signed) >> +instruct loadS(eRegI dst, memory mem) %{ >> + match(Set dst (LoadS mem)); >> + >> + ins_cost(125); >> + format %{ "MOVSX $dst,$mem\t# short" %} >> + >> + ins_encode %{ >> + Address Amem = Address::make_raw($mem$$base, $mem$$index, $mem$ >> $scale, $mem$$disp); >> + Register Rdst = as_Register($dst$$reg); >> + >> + __ movswl(Rdst, Amem); >> + %} >> + ins_pipe(ialu_reg_mem); >> +%} >> >> This style automatically creates a MacroAssembler for you so you can >> just use __ directly. You can also say $dst$$Register instead of >> as_Register($dst$$reg). I have some changes somewhere that adds >> support for $mem$$Address which would make it possible to simply have: >> >> inc_encode %{ >> __ movswl($dst$$Register, $mem$$Address) >> %} >> >> I think this style is a lot more readable than the enc_class stuff. > > Much better :-) I'll change that. > >> As far as sparc goes I wouldn't mind if they were changed to use the >> MacroAssembler too. > > Well, I could change that, at least for the loads. > >> Someday we'd like to convert all the inc_encodes >> to use MacroAssembler. If we were really slick we could derive the >> format from the ins_encode block too but that's for another day. > > Yeah, that would be nice too. > > -- Christian > From Thomas.Rodriguez at Sun.COM Thu Feb 26 10:51:30 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 26 Feb 2009 10:51:30 -0800 Subject: Request for reviews (S): 6809798: SafePointScalarObject node placed into incorrect block during GCM In-Reply-To: <49A6DC38.80000@sun.com> References: <49A6DC38.80000@sun.com> Message-ID: Were SafePointScalarObjectNodes the only one affected by this or will this change the schedule of other nodes? tom On Feb 26, 2009, at 10:15 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6809798/webrev.00 > > Fixed 6809798: SafePointScalarObject node placed into incorrect > block during GCM > > Problem: > The main problem is that the control edge of a pinned node > could be replaced during schedule_early after the pinned > node scheduled into a block if the control node is a block > projection. > Also there were few places where the control edge of > a SafePointScalarObject node was not adjusted correctly. > > Solution: > Replace the control edge of a pinned node before scheduling. > Adjust the control edge of a SafePointScalarObject when needed. > Added few asserts to verify scheduling correctness for > pinned nodes and SafePointScalarObject node. > > Reviewed by: > > Fix verified (y/n): y > > Other testing: > JPRT, CTW (with -XX:+DoEscapeAnalysis) > From Vladimir.Kozlov at Sun.COM Thu Feb 26 11:13:03 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 26 Feb 2009 11:13:03 -0800 Subject: Request for reviews (S): 6809798: SafePointScalarObject node placed into incorrect block during GCM In-Reply-To: References: <49A6DC38.80000@sun.com> Message-ID: <49A6E9BF.2030208@sun.com> I only saw asserts for SafePointScalarObjectNodes. But patching control edge of pinned nodes before scheduling affects all pinned nodes: safepoints, phis. And I think this change is correct for all pinned nodes. I actually was not able to catch the case were safepoint has block projection control to see what happened. In the bugs case it was scheduled correctly even with current code. But it could be the case when control was set differently for SFPT and SPSO nodes during IGVN in IfNode::dominated_by() which I fixed by SafePointScalarObjectNode::depends_only_on_test() const { return false; } Thanks, Vladimir Tom Rodriguez wrote: > Were SafePointScalarObjectNodes the only one affected by this or will > this change the schedule of other nodes? > > tom > > On Feb 26, 2009, at 10:15 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6809798/webrev.00 >> >> Fixed 6809798: SafePointScalarObject node placed into incorrect block >> during GCM >> >> Problem: >> The main problem is that the control edge of a pinned node >> could be replaced during schedule_early after the pinned >> node scheduled into a block if the control node is a block >> projection. >> Also there were few places where the control edge of >> a SafePointScalarObject node was not adjusted correctly. >> >> Solution: >> Replace the control edge of a pinned node before scheduling. >> Adjust the control edge of a SafePointScalarObject when needed. >> Added few asserts to verify scheduling correctness for >> pinned nodes and SafePointScalarObject node. >> >> Reviewed by: >> >> Fix verified (y/n): y >> >> Other testing: >> JPRT, CTW (with -XX:+DoEscapeAnalysis) >> > From Thomas.Rodriguez at Sun.COM Thu Feb 26 12:07:58 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 26 Feb 2009 12:07:58 -0800 Subject: Request for reviews (S): 6809798: SafePointScalarObject node placed into incorrect block during GCM In-Reply-To: <49A6E9BF.2030208@sun.com> References: <49A6DC38.80000@sun.com> <49A6E9BF.2030208@sun.com> Message-ID: <4577B60F-5019-4687-97E2-F42ECE46D860@Sun.COM> Ok. Since you've split the processing into a new method would you remove the copy of the comment about "Special control input processing" from the original location? Maybe a shorter comment like this: // Fixup some control. Constants without control get attached to root and // nodes that use is_block_proj() nodes should be attached to the region that // starts their block. Actually the existing comment for replace_block_proj_ctrl is pretty hard to read. How about: // Nodes that have is_block_proj() nodes as their control need to use // the appropriate Region for their actual block as their control since // the projection will be in a predecessor block. tom On Feb 26, 2009, at 11:13 AM, Vladimir Kozlov wrote: > I only saw asserts for SafePointScalarObjectNodes. > But patching control edge of pinned nodes before scheduling > affects all pinned nodes: safepoints, phis. > And I think this change is correct for all pinned nodes. > > I actually was not able to catch the case were > safepoint has block projection control to see what > happened. In the bugs case it was scheduled correctly > even with current code. But it could be the case > when control was set differently for SFPT and SPSO nodes > during IGVN in IfNode::dominated_by() which I fixed by > SafePointScalarObjectNode::depends_only_on_test() const { return > false; } > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> Were SafePointScalarObjectNodes the only one affected by this or >> will this change the schedule of other nodes? >> tom >> On Feb 26, 2009, at 10:15 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6809798/webrev.00 >>> >>> Fixed 6809798: SafePointScalarObject node placed into incorrect >>> block during GCM >>> >>> Problem: >>> The main problem is that the control edge of a pinned node >>> could be replaced during schedule_early after the pinned >>> node scheduled into a block if the control node is a block >>> projection. >>> Also there were few places where the control edge of >>> a SafePointScalarObject node was not adjusted correctly. >>> >>> Solution: >>> Replace the control edge of a pinned node before scheduling. >>> Adjust the control edge of a SafePointScalarObject when needed. >>> Added few asserts to verify scheduling correctness for >>> pinned nodes and SafePointScalarObject node. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y >>> >>> Other testing: >>> JPRT, CTW (with -XX:+DoEscapeAnalysis) >>> From Vladimir.Kozlov at Sun.COM Thu Feb 26 12:13:04 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 26 Feb 2009 12:13:04 -0800 Subject: Request for reviews (S): 6809798: SafePointScalarObject node placed into incorrect block during GCM In-Reply-To: <49A6E9BF.2030208@sun.com> References: <49A6DC38.80000@sun.com> <49A6E9BF.2030208@sun.com> Message-ID: <49A6F7D0.6030702@sun.com> I looked which nodes are pinned and all of them are CFG nodes except Phi and SafePointScalarObject. The block projection control edge of CFG nodes will be replaced with new Region nodes during PhaseCFG::build_cfg() before GCM. And Phi node can not have block projection control - only Region. Which leaves only SafePointScalarObject node we need to patch. I can add additional assert to verify this: void PhaseCFG::replace_block_proj_ctrl( Node *n ) { const Node *in0 = n->in(0); assert(in0 != NULL, "Only control-dependent"); const Node *p = in0->is_block_proj(); if (p != NULL && p != n) { // Control from a block projection? + assert(!n->pinned() || n->is_SafePointScalarObject(), "not SafePointScalarObject"); // Find trailing Region Vladimir Vladimir Kozlov wrote: > I only saw asserts for SafePointScalarObjectNodes. > But patching control edge of pinned nodes before scheduling > affects all pinned nodes: safepoints, phis. > And I think this change is correct for all pinned nodes. > > I actually was not able to catch the case were > safepoint has block projection control to see what > happened. In the bugs case it was scheduled correctly > even with current code. But it could be the case > when control was set differently for SFPT and SPSO nodes > during IGVN in IfNode::dominated_by() which I fixed by > SafePointScalarObjectNode::depends_only_on_test() const { return false; } > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> Were SafePointScalarObjectNodes the only one affected by this or will >> this change the schedule of other nodes? >> >> tom >> >> On Feb 26, 2009, at 10:15 AM, Vladimir Kozlov wrote: >> >>> http://cr.openjdk.java.net/~kvn/6809798/webrev.00 >>> >>> Fixed 6809798: SafePointScalarObject node placed into incorrect block >>> during GCM >>> >>> Problem: >>> The main problem is that the control edge of a pinned node >>> could be replaced during schedule_early after the pinned >>> node scheduled into a block if the control node is a block >>> projection. >>> Also there were few places where the control edge of >>> a SafePointScalarObject node was not adjusted correctly. >>> >>> Solution: >>> Replace the control edge of a pinned node before scheduling. >>> Adjust the control edge of a SafePointScalarObject when needed. >>> Added few asserts to verify scheduling correctness for >>> pinned nodes and SafePointScalarObject node. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y >>> >>> Other testing: >>> JPRT, CTW (with -XX:+DoEscapeAnalysis) >>> >> From Vladimir.Kozlov at Sun.COM Thu Feb 26 12:15:25 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 26 Feb 2009 12:15:25 -0800 Subject: Request for reviews (S): 6809798: SafePointScalarObject node placed into incorrect block during GCM In-Reply-To: <4577B60F-5019-4687-97E2-F42ECE46D860@Sun.COM> References: <49A6DC38.80000@sun.com> <49A6E9BF.2030208@sun.com> <4577B60F-5019-4687-97E2-F42ECE46D860@Sun.COM> Message-ID: <49A6F85D.5060000@sun.com> Thanks, Tom I will replace comments. Vladimir Tom Rodriguez wrote: > Ok. > > Since you've split the processing into a new method would you remove the > copy of the comment about "Special control input processing" from the > original location? Maybe a shorter comment like this: > > // Fixup some control. Constants without control get attached to root and > // nodes that use is_block_proj() nodes should be attached to the region > that > // starts their block. > > Actually the existing comment for replace_block_proj_ctrl is pretty hard > to read. How about: > > // Nodes that have is_block_proj() nodes as their control need to use > // the appropriate Region for their actual block as their control since > // the projection will be in a predecessor block. > > tom > > On Feb 26, 2009, at 11:13 AM, Vladimir Kozlov wrote: > >> I only saw asserts for SafePointScalarObjectNodes. >> But patching control edge of pinned nodes before scheduling >> affects all pinned nodes: safepoints, phis. >> And I think this change is correct for all pinned nodes. >> >> I actually was not able to catch the case were >> safepoint has block projection control to see what >> happened. In the bugs case it was scheduled correctly >> even with current code. But it could be the case >> when control was set differently for SFPT and SPSO nodes >> during IGVN in IfNode::dominated_by() which I fixed by >> SafePointScalarObjectNode::depends_only_on_test() const { return false; } >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> Were SafePointScalarObjectNodes the only one affected by this or will >>> this change the schedule of other nodes? >>> tom >>> On Feb 26, 2009, at 10:15 AM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/6809798/webrev.00 >>>> >>>> Fixed 6809798: SafePointScalarObject node placed into incorrect >>>> block during GCM >>>> >>>> Problem: >>>> The main problem is that the control edge of a pinned node >>>> could be replaced during schedule_early after the pinned >>>> node scheduled into a block if the control node is a block >>>> projection. >>>> Also there were few places where the control edge of >>>> a SafePointScalarObject node was not adjusted correctly. >>>> >>>> Solution: >>>> Replace the control edge of a pinned node before scheduling. >>>> Adjust the control edge of a SafePointScalarObject when needed. >>>> Added few asserts to verify scheduling correctness for >>>> pinned nodes and SafePointScalarObject node. >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y >>>> >>>> Other testing: >>>> JPRT, CTW (with -XX:+DoEscapeAnalysis) >>>> > From Vladimir.Kozlov at Sun.COM Thu Feb 26 14:23:25 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 26 Feb 2009 14:23:25 -0800 Subject: Request for reviews (S): 6809798: SafePointScalarObject node placed into incorrect block during GCM In-Reply-To: <49A6F7D0.6030702@sun.com> References: <49A6DC38.80000@sun.com> <49A6E9BF.2030208@sun.com> <49A6F7D0.6030702@sun.com> Message-ID: <49A7165D.5070207@sun.com> I changed comments as suggested, added the assert into replace_block_proj_ctrl() and ran CTW with -XX:+DoEscapeAnalysis. I did not get any failures. I updated webrev http://cr.openjdk.java.net/~kvn/6809798/webrev.01 and I will push the fix with Tom as reviewer. Thanks, Vladimir Vladimir Kozlov wrote: > I looked which nodes are pinned and all of them are CFG nodes > except Phi and SafePointScalarObject. > The block projection control edge of CFG nodes will be replaced > with new Region nodes during PhaseCFG::build_cfg() before GCM. > And Phi node can not have block projection control - only Region. > Which leaves only SafePointScalarObject node we need to patch. > > I can add additional assert to verify this: > > void PhaseCFG::replace_block_proj_ctrl( Node *n ) { > const Node *in0 = n->in(0); > assert(in0 != NULL, "Only control-dependent"); > const Node *p = in0->is_block_proj(); > if (p != NULL && p != n) { // Control from a block projection? > + assert(!n->pinned() || n->is_SafePointScalarObject(), "not > SafePointScalarObject"); > // Find trailing Region > > Vladimir > > Vladimir Kozlov wrote: >> I only saw asserts for SafePointScalarObjectNodes. >> But patching control edge of pinned nodes before scheduling >> affects all pinned nodes: safepoints, phis. >> And I think this change is correct for all pinned nodes. >> >> I actually was not able to catch the case were >> safepoint has block projection control to see what >> happened. In the bugs case it was scheduled correctly >> even with current code. But it could be the case >> when control was set differently for SFPT and SPSO nodes >> during IGVN in IfNode::dominated_by() which I fixed by >> SafePointScalarObjectNode::depends_only_on_test() const { return false; } >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> Were SafePointScalarObjectNodes the only one affected by this or will >>> this change the schedule of other nodes? >>> >>> tom >>> >>> On Feb 26, 2009, at 10:15 AM, Vladimir Kozlov wrote: >>> >>>> http://cr.openjdk.java.net/~kvn/6809798/webrev.00 >>>> >>>> Fixed 6809798: SafePointScalarObject node placed into incorrect >>>> block during GCM >>>> >>>> Problem: >>>> The main problem is that the control edge of a pinned node >>>> could be replaced during schedule_early after the pinned >>>> node scheduled into a block if the control node is a block >>>> projection. >>>> Also there were few places where the control edge of >>>> a SafePointScalarObject node was not adjusted correctly. >>>> >>>> Solution: >>>> Replace the control edge of a pinned node before scheduling. >>>> Adjust the control edge of a SafePointScalarObject when needed. >>>> Added few asserts to verify scheduling correctness for >>>> pinned nodes and SafePointScalarObject node. >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y >>>> >>>> Other testing: >>>> JPRT, CTW (with -XX:+DoEscapeAnalysis) >>>> >>> From Thomas.Rodriguez at Sun.COM Thu Feb 26 14:39:26 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 26 Feb 2009 14:39:26 -0800 Subject: review (XS) for 6810855: KILL vs. TEMP ordering restrictions are too strong Message-ID: <14AE2F9B-41D0-4299-91FA-98DFA53FE99C@sun.com> http://cr.openjdk.java.net/~never/6810855 From Vladimir.Kozlov at Sun.COM Thu Feb 26 14:46:23 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 26 Feb 2009 14:46:23 -0800 Subject: review (XS) for 6810855: KILL vs. TEMP ordering restrictions are too strong In-Reply-To: <14AE2F9B-41D0-4299-91FA-98DFA53FE99C@sun.com> References: <14AE2F9B-41D0-4299-91FA-98DFA53FE99C@sun.com> Message-ID: <49A71BBF.3090807@sun.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6810855 > From Changpeng.Fang at Sun.COM Thu Feb 26 15:42:02 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Thu, 26 Feb 2009 15:42:02 -0800 Subject: review (XS) for 6810855: KILL vs. TEMP ordering restrictions are too strong In-Reply-To: <14AE2F9B-41D0-4299-91FA-98DFA53FE99C@sun.com> References: <14AE2F9B-41D0-4299-91FA-98DFA53FE99C@sun.com> Message-ID: <49A728CA.5050507@Sun.COM> Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6810855 > It looks good and works as expected. Thanks. And I will update my work accordingly. Changpeng From vladimir.kozlov at sun.com Thu Feb 26 16:54:49 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 27 Feb 2009 00:54:49 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6809798: SafePointScalarObject node placed into incorrect block during GCM Message-ID: <20090227005451.B987EE250@hg.openjdk.java.net> Changeset: 523ded093c31 Author: kvn Date: 2009-02-26 14:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/523ded093c31 6809798: SafePointScalarObject node placed into incorrect block during GCM Summary: Replace the control edge of a pinned node before scheduling. Reviewed-by: never ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/macro.cpp From thomas.rodriguez at sun.com Thu Feb 26 20:05:50 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Fri, 27 Feb 2009 04:05:50 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6810855: KILL vs. TEMP ordering restrictions are too strong Message-ID: <20090227040552.1FB55E281@hg.openjdk.java.net> Changeset: ed6404fac86b Author: never Date: 2009-02-26 16:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ed6404fac86b 6810855: KILL vs. TEMP ordering restrictions are too strong Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp From john.coomes at sun.com Fri Feb 27 00:02:12 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 27 Feb 2009 08:02:12 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b49 for changeset aee93a8992d2 Message-ID: <20090227080212.C5EA5E310@hg.openjdk.java.net> Changeset: 5111e13e44e5 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/5111e13e44e5 Added tag jdk7-b49 for changeset aee93a8992d2 ! .hgtags From john.coomes at sun.com Fri Feb 27 00:04:57 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 27 Feb 2009 08:04:57 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b49 for changeset d70978bc64bc Message-ID: <20090227080458.F087CE315@hg.openjdk.java.net> Changeset: 0edbd0074b02 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/0edbd0074b02 Added tag jdk7-b49 for changeset d70978bc64bc ! .hgtags From john.coomes at sun.com Fri Feb 27 00:10:50 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 27 Feb 2009 08:10:50 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b49 for changeset 5c1f24531903 Message-ID: <20090227081052.8FE43E31A@hg.openjdk.java.net> Changeset: e8514e2be76d Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/e8514e2be76d Added tag jdk7-b49 for changeset 5c1f24531903 ! .hgtags From john.coomes at sun.com Fri Feb 27 00:13:35 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 27 Feb 2009 08:13:35 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b49 for changeset 18ca864890f3 Message-ID: <20090227081337.C1CCFE31F@hg.openjdk.java.net> Changeset: 5be52db581f1 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/5be52db581f1 Added tag jdk7-b49 for changeset 18ca864890f3 ! .hgtags From john.coomes at sun.com Fri Feb 27 00:16:22 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 27 Feb 2009 08:16:22 +0000 Subject: hg: jdk7/hotspot-comp/jdk: Added tag jdk7-b49 for changeset 8311105ea7a3 Message-ID: <20090227081655.95DA8E324@hg.openjdk.java.net> Changeset: 383d6bebfba6 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/383d6bebfba6 Added tag jdk7-b49 for changeset 8311105ea7a3 ! .hgtags From john.coomes at sun.com Fri Feb 27 00:24:59 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 27 Feb 2009 08:24:59 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b49 for changeset d17d927ad9bd Message-ID: <20090227082502.455F1E329@hg.openjdk.java.net> Changeset: cc69a0495ac5 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/cc69a0495ac5 Added tag jdk7-b49 for changeset d17d927ad9bd ! .hgtags From Christian.Thalinger at Sun.COM Fri Feb 27 04:35:19 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 27 Feb 2009 13:35:19 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> Message-ID: <1235738119.2004.1513.camel@localhost.localdomain> On Thu, 2009-02-26 at 09:02 -0800, Tom Rodriguez wrote: > I have some changes somewhere that adds > support for $mem$$Address which would make it possible to simply have: > > inc_encode %{ > __ movswl($dst$$Register, $mem$$Address) > %} I'd like to have these changes in. Are these in a commitable state or is there some work left to do? If there is some work left, I could look into it, if you don't have time. -- Christian From Christian.Thalinger at Sun.COM Fri Feb 27 06:16:28 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 27 Feb 2009 14:16:28 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6778669: Patch from Red Hat -- fixes compilation errors Message-ID: <20090227141630.8D5F8E38B@hg.openjdk.java.net> Changeset: dbbe28fc66b5 Author: twisti Date: 2009-02-27 03:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dbbe28fc66b5 6778669: Patch from Red Hat -- fixes compilation errors Summary: Some fixes which are required to build on recent GCCs. Reviewed-by: never, kvn Contributed-by: langel at redhat.com ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! src/share/vm/adlc/adlc.hpp ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formsopt.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/includeDB_core ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp From Christian.Thalinger at Sun.COM Fri Feb 27 08:07:35 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 27 Feb 2009 17:07:35 +0100 Subject: Request for reviews (S): 6809798: SafePointScalarObject node placed into incorrect block during GCM In-Reply-To: <49A7165D.5070207@sun.com> References: <49A6DC38.80000@sun.com> <49A6E9BF.2030208@sun.com> <49A6F7D0.6030702@sun.com> <49A7165D.5070207@sun.com> Message-ID: <1235750855.2004.1746.camel@localhost.localdomain> On Thu, 2009-02-26 at 14:23 -0800, Vladimir Kozlov wrote: > I changed comments as suggested, added the assert into > replace_block_proj_ctrl() and ran CTW with -XX:+DoEscapeAnalysis. > I did not get any failures. > > I updated webrev http://cr.openjdk.java.net/~kvn/6809798/webrev.01 > and I will push the fix with Tom as reviewer. Oh no! This small change: + void PhaseCFG::replace_block_proj_ctrl( Node *n ); broke compilation on recent GCCs again: src/share/vm/opto/block.hpp:350: error: extra qualification 'PhaseCFG::' on member 'replace_block_proj_ctrl' Unfortunately I have already pushed the changeset of 6778669. How should I proceed? Create a new CR for that or a sub-CR of 6778669 (however that works)? -- Christian From Vladimir.Kozlov at Sun.COM Fri Feb 27 08:09:44 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 27 Feb 2009 08:09:44 -0800 Subject: Request for reviews (S): 6809798: SafePointScalarObject node placed into incorrect block during GCM In-Reply-To: <1235750855.2004.1746.camel@localhost.localdomain> References: <49A6DC38.80000@sun.com> <49A6E9BF.2030208@sun.com> <49A6F7D0.6030702@sun.com> <49A7165D.5070207@sun.com> <1235750855.2004.1746.camel@localhost.localdomain> Message-ID: <49A81048.7060101@sun.com> Sorry about this. I will create new CR and do fix. Vladimir Christian Thalinger wrote: > On Thu, 2009-02-26 at 14:23 -0800, Vladimir Kozlov wrote: >> I changed comments as suggested, added the assert into >> replace_block_proj_ctrl() and ran CTW with -XX:+DoEscapeAnalysis. >> I did not get any failures. >> >> I updated webrev http://cr.openjdk.java.net/~kvn/6809798/webrev.01 >> and I will push the fix with Tom as reviewer. > > Oh no! This small change: > > + void PhaseCFG::replace_block_proj_ctrl( Node *n ); > > broke compilation on recent GCCs again: > > src/share/vm/opto/block.hpp:350: error: extra qualification 'PhaseCFG::' on member 'replace_block_proj_ctrl' > > Unfortunately I have already pushed the changeset of 6778669. How > should I proceed? Create a new CR for that or a sub-CR of 6778669 > (however that works)? > > -- Christian > From Christian.Thalinger at Sun.COM Fri Feb 27 08:15:25 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 27 Feb 2009 17:15:25 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> Message-ID: <1235751325.2004.1761.camel@localhost.localdomain> On Thu, 2009-02-26 at 09:02 -0800, Tom Rodriguez wrote: > As far as sparc goes I wouldn't mind if they were changed to use the > MacroAssembler too. Someday we'd like to convert all the inc_encodes > to use MacroAssembler. Hmm, I don't know how to do it properly on SPARC. There are only two (three) versions of emit functions: ldsb( Register s1, Register s2, Register d) ldsb( Register s1, int simm13a, Register d) (And this one: ldsb( const Address& a, Register d, int offset ) ) I tried something like that: ins_encode %{ __ ldsb($mem$$base$$Register, $mem$$disp, $dst$$Register); %} but that does work (I know the $$Register is wrong). The question is: would it be correct to use $mem$$base and $mem$$disp and assume $mem $$index and $mem$$scale are zero or not used? -- Christian From Christian.Thalinger at Sun.COM Fri Feb 27 08:16:38 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 27 Feb 2009 17:16:38 +0100 Subject: Request for reviews (S): 6809798: SafePointScalarObject node placed into incorrect block during GCM In-Reply-To: <49A81048.7060101@sun.com> References: <49A6DC38.80000@sun.com> <49A6E9BF.2030208@sun.com> <49A6F7D0.6030702@sun.com> <49A7165D.5070207@sun.com> <1235750855.2004.1746.camel@localhost.localdomain> <49A81048.7060101@sun.com> Message-ID: <1235751398.2004.1763.camel@localhost.localdomain> On Fri, 2009-02-27 at 08:09 -0800, Vladimir Kozlov wrote: > Sorry about this. I will create new CR and do fix. Thanks! -- Christian From Vladimir.Kozlov at Sun.COM Fri Feb 27 08:19:07 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 27 Feb 2009 08:19:07 -0800 Subject: Request for reviews (XS): 6811267: Fix for 6809798 broke linux build Message-ID: <49A8127B.3020004@sun.com> http://cr.openjdk.java.net/~kvn/6811267/webrev.00 Fixed 6811267: Fix for 6809798 broke linux build Problem: Including class in method's declaration broke compilation on recent GCC. Solution: Fix declaration. Reviewed by: Fix verified (y/n): n Other testing: JPRT From Christian.Thalinger at Sun.COM Fri Feb 27 08:34:53 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 27 Feb 2009 17:34:53 +0100 Subject: Request for reviews (XS): 6811267: Fix for 6809798 broke linux build In-Reply-To: <49A8127B.3020004@sun.com> References: <49A8127B.3020004@sun.com> Message-ID: <1235752493.2004.1790.camel@localhost.localdomain> On Fri, 2009-02-27 at 08:19 -0800, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6811267/webrev.00 > > Fixed 6811267: Fix for 6809798 broke linux build Looks good. Andrew John Hughes verified that it works. -- Christian From James.Melvin at Sun.COM Fri Feb 27 08:39:02 2009 From: James.Melvin at Sun.COM (James Melvin) Date: Fri, 27 Feb 2009 11:39:02 -0500 Subject: Request for reviews (XS): 6811267: Fix for 6809798 broke linux build In-Reply-To: <1235752493.2004.1790.camel@localhost.localdomain> References: <49A8127B.3020004@sun.com> <1235752493.2004.1790.camel@localhost.localdomain> Message-ID: <49A81726.7010900@sun.com> This exercise brings up an interesting point. Is there a way to amend JPRT or another process to test build submissions against a logical range of compiler versions? Any ideas to resolve this with process? - Jim Christian Thalinger wrote: > On Fri, 2009-02-27 at 08:19 -0800, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6811267/webrev.00 >> >> Fixed 6811267: Fix for 6809798 broke linux build > > Looks good. Andrew John Hughes verified that it works. > > -- Christian > From Thomas.Rodriguez at Sun.COM Fri Feb 27 09:21:57 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 27 Feb 2009 09:21:57 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1235738119.2004.1513.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235738119.2004.1513.camel@localhost.localdomain> Message-ID: I was actually going to clean them up and send them out for review, though if you want to include them I can just send them to you. They're relatively small. tom On Feb 27, 2009, at 4:35 AM, Christian Thalinger wrote: > On Thu, 2009-02-26 at 09:02 -0800, Tom Rodriguez wrote: >> I have some changes somewhere that adds >> support for $mem$$Address which would make it possible to simply >> have: >> >> inc_encode %{ >> __ movswl($dst$$Register, $mem$$Address) >> %} > > I'd like to have these changes in. Are these in a commitable state or > is there some work left to do? If there is some work left, I could > look > into it, if you don't have time. > > -- Christian > From Christian.Thalinger at Sun.COM Fri Feb 27 09:28:30 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 27 Feb 2009 18:28:30 +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> <1235738119.2004.1513.camel@localhost.localdomain> Message-ID: <1235755710.2004.1854.camel@localhost.localdomain> On Fri, 2009-02-27 at 09:21 -0800, Tom Rodriguez wrote: > I was actually going to clean them up and send them out for review, > though if you want to include them I can just send them to you. > They're relatively small. As you like. If you have something better to do, please feel free to push them over to me :-) -- Christian From Thomas.Rodriguez at Sun.COM Fri Feb 27 09:59:22 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 27 Feb 2009 09:59:22 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1235738119.2004.1513.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235738119.2004.1513.camel@localhost.localdomain> Message-ID: <78C0AA27-E692-4BCE-8865-6CB9D064B081@Sun.COM> Check out http://cr.openjdk.java.net/~never/address. Ignore the cmpl changes as they are part of something else. Basically the adlc assumes that there's a function called Address::make_raw defined somewhere which produces the appropriate thing. Sparc doesn't really use Address the way that x86 does so it's less useful there, unless some more serious changes were made to the sparc assembler. It's not that hard to cope without it on sparc. tom On Feb 27, 2009, at 4:35 AM, Christian Thalinger wrote: > On Thu, 2009-02-26 at 09:02 -0800, Tom Rodriguez wrote: >> I have some changes somewhere that adds >> support for $mem$$Address which would make it possible to simply >> have: >> >> inc_encode %{ >> __ movswl($dst$$Register, $mem$$Address) >> %} > > I'd like to have these changes in. Are these in a commitable state or > is there some work left to do? If there is some work left, I could > look > into it, if you don't have time. > > -- Christian > From Thomas.Rodriguez at Sun.COM Fri Feb 27 10:06:06 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 27 Feb 2009 10:06:06 -0800 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <1235751325.2004.1761.camel@localhost.localdomain> References: <1235666480.2004.256.camel@localhost.localdomain> <7EF791B5-FDF8-4A67-B44D-55CC1B868D43@sun.com> <1235751325.2004.1761.camel@localhost.localdomain> Message-ID: <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@Sun.COM> Basically you have to distinguish the two modes by hand. Check out the loadN instruct definition. Does $mem$$base$$Register not work? tom On Feb 27, 2009, at 8:15 AM, Christian Thalinger wrote: > On Thu, 2009-02-26 at 09:02 -0800, Tom Rodriguez wrote: >> As far as sparc goes I wouldn't mind if they were changed to use the >> MacroAssembler too. Someday we'd like to convert all the inc_encodes >> to use MacroAssembler. > > Hmm, I don't know how to do it properly on SPARC. There are only two > (three) versions of emit functions: > > ldsb( Register s1, Register s2, Register d) > ldsb( Register s1, int simm13a, Register d) > > (And this one: > > ldsb( const Address& a, Register d, int offset ) > ) > > I tried something like that: > > ins_encode %{ > __ ldsb($mem$$base$$Register, $mem$$disp, $dst$$Register); > %} > > but that does work (I know the $$Register is wrong). The question is: > would it be correct to use $mem$$base and $mem$$disp and assume $mem > $$index and $mem$$scale are zero or not used? > > -- Christian > From vladimir.kozlov at sun.com Fri Feb 27 11:13:18 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 27 Feb 2009 19:13:18 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6811267: Fix for 6809798 broke linux build Message-ID: <20090227191320.4DC05E3AB@hg.openjdk.java.net> Changeset: ec59443af135 Author: kvn Date: 2009-02-27 08:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ec59443af135 6811267: Fix for 6809798 broke linux build Summary: Fix method's declaration. Reviewed-by: phh, twisti ! src/share/vm/opto/block.hpp From Christian.Thalinger at Sun.COM Fri Feb 27 13:34:56 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 27 Feb 2009 22:34:56 +0100 Subject: Request for review (L): 6797305: Add LoadUB and LoadUI opcode class In-Reply-To: <6BFB78E8-9CE1-47B0-9ABC-6309914AD506@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> Message-ID: <1235770496.2004.2104.camel@localhost.localdomain> 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. > Does $mem$$base$$Register not work? No, because it generates: opnd_array(1)->base(ra_,this,idx1)->as_Register(ra_,this,idx1) and base() already returns an int. -- Christian From Thomas.Rodriguez at Sun.COM Fri Feb 27 14:26:56 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 27 Feb 2009 14:26:56 -0800 Subject: review (XS) for 6811384: MacroAssembler::serialize_memory may touch next page on amd64 Message-ID: <46F4688E-36FA-4232-98E5-5BFB18D26D91@Sun.COM> http://cr.openjdk.java.net/~never/6811384 From Thomas.Rodriguez at Sun.COM Fri Feb 27 14:58:31 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 27 Feb 2009 14:58:31 -0800 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: <323398B3-5BE1-415D-8E4B-0073BD434683@Sun.COM> On Feb 27, 2009, at 1:34 PM, 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. > >> Does $mem$$base$$Register not work? > > No, because it generates: > > opnd_array(1)->base(ra_,this,idx1)->as_Register(ra_,this,idx1) > > and base() already returns an int. 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. tom > > > -- Christian > From Christian.Thalinger at Sun.COM Fri Feb 27 16:05:40 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Sat, 28 Feb 2009 00:05:40 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6810672: Comment typos Message-ID: <20090228000548.84FD0E45C@hg.openjdk.java.net> Changeset: 98cb887364d3 Author: twisti Date: 2009-02-27 13:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/98cb887364d3 6810672: Comment typos Summary: I have collected some typos I have found while looking at the code. Reviewed-by: kvn, never ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.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/os/linux/launcher/java.c ! src/os/linux/launcher/java_md.h ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/launcher/java.c ! src/os/solaris/launcher/java_md.h ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/tools/MakeDeps/Database.java ! src/share/vm/adlc/Doc/Syntax.doc ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/dict2.hpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsGCAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp ! src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/cppInterpreterGenerator.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterGenerator.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/libadt/dict.cpp ! src/share/vm/libadt/dict.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/permGen.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/machnode.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/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/extendedPC.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/orderAccess.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/threadCritical.hpp ! src/share/vm/utilities/globalDefinitions.hpp From Christian.Thalinger at Sun.COM Sat Feb 28 01:30:30 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sat, 28 Feb 2009 10:30:30 +0100 Subject: review (XS) for 6811384: MacroAssembler::serialize_memory may touch next page on amd64 In-Reply-To: <46F4688E-36FA-4232-98E5-5BFB18D26D91@Sun.COM> References: <46F4688E-36FA-4232-98E5-5BFB18D26D91@Sun.COM> Message-ID: <1235813430.2004.2820.camel@localhost.localdomain> On Fri, 2009-02-27 at 14:26 -0800, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6811384 Looks good. -- Christian