From aaron.riekenberg at gmail.com Mon Nov 1 06:45:41 2010 From: aaron.riekenberg at gmail.com (Aaron Riekenberg) Date: Mon, 1 Nov 2010 08:45:41 -0500 Subject: [OpenJDK 2D-Dev] Are the Java2D OpenGL pipeline and JOGL integration still being supported? Message-ID: I've been using the Java2D OpenGL pipeline + JOGL 1.1.1a for about 18 months on a project where I do things like put GLJPanels in JInternalFrames and overlay other semi-transparent JInternalFrames over top of them. So far it's all been working great both on Windows and Linux with NVIDIA graphics cards. A couple of weeks ago NVIDIA released a new 260.xx series of drivers - 260.19.12 is the latest version for Linux and Ubuntu 10.10 comes with 260.19.06 now. This series of drivers significantly breaks the Java2D OpenGL pipeline. I get empty windows unless I set -Dsun.java2d.opengl.fbobject=false now, and the X server often crashes when a Java app using the OpenGL pipeline is closed. I posted a thread describing all this on the NVIDIA nvnews.net forum here: http://www.nvnews.net/vbulletin/showthread.php?t=156264 I think I've made some headway on the X server crashing problem, it seems any application creates a pbuffer and then exits has a good chance of crashing the X server with the 260.xx drivers. The other thing I've noticed of course is JOGL is no longer an officially supported Sun project, and development of JOGL 2 has been taken over by jogamp.org. They are releasing snapshot versions but in their current versions GLJPanel is "quite broken" (quoting a forum post) - I can confirm this is true, even when not using the Java2D OpenGL pipeline. It seems the only working ways to use JOGL 2 at this point is to use a GLCanvas with Swing/AWT, or to use their new NEWT GLWindow. Neither of these is a great option for integration with Swing components (particularly transparent swing components) - even with the new heavyweight/lightweight mixing improvements in 6u12 putting a semi-transparent lightweight component over a heavyweight component (ie GLCanvas) does not allow the heavyweight component to show through (http://java.sun.com/developer/technicalArticles/GUI/mixing_components/index.html). So all of this leaves me a bit uncertain about the future of the Java2D OpenGL pipeline + JOGL for OpenGL/Swing integration. From what I've read it seems folks like Chris Campbell (and probably others) did significant work with NVIDIA and ATI to try to get all the pieces actually working with their drivers. In this blog post Chris mentions a "basic acceptance test suite" for driver vendors to run to make sure the OpenGL pipeline works with new driver version (http://webcache.googleusercontent.com/search?q=cache:1wKVEmLPky8J:www.java.net/blog/2006/07/21/five-more-easy-pieces+5+more+easy+pieces+java2d&cd=1&hl=en&ct=clnk&gl=us). Unfortunately based on the 260.xx series it seems NVIDIA doesn't care to run this any more. Anyone have any thoughts on all this? Is anybody at Oracle still working on OpenGL in Java? Is the future of OpenGL/Swing integration really as dire as I am afraid it might be? Thanks, Aaron Riekenberg From dlila at redhat.com Mon Nov 1 15:13:50 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 1 Nov 2010 18:13:50 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1925649339.2011161288649522715.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <746965210.2011291288649630953.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. I implemented your bucket sort idea. I'm not just using the buckets to remove the y-sort. I use them in the iteration through the scanlines too. What happens is that on any iteration, the active list is the doubly linked list buckets[nextY-boundsMinY]. I did this because I thought less memory would need to be moved around compared to when we just kept the active list "pointers" in an array. For example, with doubly linked lists we can implement insertion sort with O(1) writes. With arrays we have to use O(n) writes. This also allows us to get rid of the the edgePtrs array. I ran some benchmarks, and unfortunately I was wrong, somehwere. All the tests are at least 10% slower than the insertion sort version of what we have now. I can't immediately see why this is. The only thing I can think of is that there are a lot of float -> int casts, but then again, I don't know how slow this operation is. It would be good if it's because of the casts because it would no longer be an issue when we convert to native. I alo made an unrelated change: I now find the orientation and update x0,y0 much earlier than we used to. The way I was doing it before was silly. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > Good news! > > On 10/28/2010 3:27 PM, Denis Lila wrote: > >> If we moved to a Curve class or some other way to > >> consolidate the 3 lists (may be easier in native code), this might > win > >> in more cases... > > > > Does that mean you no longer think we should flatten every curve as > soon > > as we get it? > > No, I was just discussion the feasibility of that one suggestion in > the > context of all of the possibilities of whether or not we took the > other > choices. If you think that flattening will pay off then we don't have > > to worry about the 3 lists. It was just that when I hacked it in, I > still had your 3 lists and so the pros and cons of horizontal edge > sorting were relative to that version of the renderer... > > ...jim -------------- next part -------------- A non-text attachment was scrubbed... Name: Renderer.java Type: text/x-java Size: 27189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20101101/4b9ed22d/Renderer.java From james.graham at oracle.com Mon Nov 1 18:08:11 2010 From: james.graham at oracle.com (Jim Graham) Date: Mon, 01 Nov 2010 18:08:11 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <746965210.2011291288649630953.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <746965210.2011291288649630953.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CCF647B.6040907@oracle.com> Hi Denis, A generic suggestion - make all of your classes final - that gives the compiler the maximum flexibility to inline any methods you write. With respect to the algorithm choices: I think they key is that the X sorting rarely has any work to do. The first test of "does this edge need to be swapped with the next lower edge" is probably 99.999% guaranteed to be false. Thus, trying to optimize anything else to simplify swapping is likely a step in the wrong direction. The casting may be hurting a bit more, and it is hurting on every access to an edge. I'm guessing the best model to use would be to write the code to assume no swapping is necessary at all. Get that code as simple and as fast as can be. Then add as little perturbation of that code to manage swapping when it is necessary, and that will likely be the optimal implementation. I think you could probably even do some benchmarking on a path that is carefully tested to process lots of edges without any X sorting and get that as fast as you can without any swap code, and then add the swap code that impacts the performance of that operation as little as possible. The key is that the swap code have as little impact on the performance of the case that never needs any swapping at all first and foremost - then make swapping faster within that constraint... ...jim On 11/1/10 3:13 PM, Denis Lila wrote: > Hi Jim. > > I implemented your bucket sort idea. I'm not just using the buckets > to remove the y-sort. I use them in the iteration through the scanlines > too. What happens is that on any iteration, the active list is the > doubly linked list buckets[nextY-boundsMinY]. I did this because I thought > less memory would need to be moved around compared to when we just kept > the active list "pointers" in an array. For example, with doubly linked > lists we can implement insertion sort with O(1) writes. With arrays we > have to use O(n) writes. This also allows us to get rid of the the edgePtrs > array. > > I ran some benchmarks, and unfortunately I was wrong, somehwere. All the tests > are at least 10% slower than the insertion sort version of what we have now. > I can't immediately see why this is. The only thing I can think of is that > there are a lot of float -> int casts, but then again, I don't know how > slow this operation is. It would be good if it's because of the casts because > it would no longer be an issue when we convert to native. > > I alo made an unrelated change: I now find the orientation and update x0,y0 > much earlier than we used to. The way I was doing it before was silly. > > Regards, > Denis. > > ----- "Jim Graham" wrote: > >> Hi Denis, >> >> Good news! >> >> On 10/28/2010 3:27 PM, Denis Lila wrote: >>>> If we moved to a Curve class or some other way to >>>> consolidate the 3 lists (may be easier in native code), this might >> win >>>> in more cases... >>> >>> Does that mean you no longer think we should flatten every curve as >> soon >>> as we get it? >> >> No, I was just discussion the feasibility of that one suggestion in >> the >> context of all of the possibilities of whether or not we took the >> other >> choices. If you think that flattening will pay off then we don't have >> >> to worry about the 3 lists. It was just that when I hacked it in, I >> still had your 3 lists and so the pros and cons of horizontal edge >> sorting were relative to that version of the renderer... >> >> ...jim From dlila at redhat.com Tue Nov 2 16:10:28 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 2 Nov 2010 19:10:28 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1602526756.2128731288738989849.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <949127986.2128921288739428968.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. I implemented a middle ground between what I sent yesterday and what we have now: using the array of linked lists only to replace the quicksort (I think this was your original suggestion). Unfortunately, this didn't work out (at least according to the benchmarks). Curves were no different than what we used to have, while the performance on lines (especially horizontal ones) decreased significantly. It's not obvious to me why this happened, so I think now I will put this type of optimization aside and convert to JNI, where profiling will be easier (for me - I haven't been able to make OProfile work for java yet). Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > A generic suggestion - make all of your classes final - that gives the > > compiler the maximum flexibility to inline any methods you write. > > With respect to the algorithm choices: > > I think they key is that the X sorting rarely has any work to do. The > > first test of "does this edge need to be swapped with the next lower > edge" is probably 99.999% guaranteed to be false. Thus, trying to > optimize anything else to simplify swapping is likely a step in the > wrong direction. > > The casting may be hurting a bit more, and it is hurting on every > access > to an edge. > > I'm guessing the best model to use would be to write the code to > assume > no swapping is necessary at all. Get that code as simple and as fast > as > can be. Then add as little perturbation of that code to manage > swapping > when it is necessary, and that will likely be the optimal > implementation. I think you could probably even do some benchmarking > on > a path that is carefully tested to process lots of edges without any X > > sorting and get that as fast as you can without any swap code, and > then > add the swap code that impacts the performance of that operation as > little as possible. The key is that the swap code have as little > impact > on the performance of the case that never needs any swapping at all > first and foremost - then make swapping faster within that > constraint... > > ...jim > > On 11/1/10 3:13 PM, Denis Lila wrote: > > Hi Jim. > > > > I implemented your bucket sort idea. I'm not just using the buckets > > to remove the y-sort. I use them in the iteration through the > scanlines > > too. What happens is that on any iteration, the active list is the > > doubly linked list buckets[nextY-boundsMinY]. I did this because I > thought > > less memory would need to be moved around compared to when we just > kept > > the active list "pointers" in an array. For example, with doubly > linked > > lists we can implement insertion sort with O(1) writes. With arrays > we > > have to use O(n) writes. This also allows us to get rid of the the > edgePtrs > > array. > > > > I ran some benchmarks, and unfortunately I was wrong, somehwere. All > the tests > > are at least 10% slower than the insertion sort version of what we > have now. > > I can't immediately see why this is. The only thing I can think of > is that > > there are a lot of float -> int casts, but then again, I don't know > how > > slow this operation is. It would be good if it's because of the > casts because > > it would no longer be an issue when we convert to native. > > > > I alo made an unrelated change: I now find the orientation and > update x0,y0 > > much earlier than we used to. The way I was doing it before was > silly. > > > > Regards, > > Denis. > > > > ----- "Jim Graham" wrote: > > > >> Hi Denis, > >> > >> Good news! > >> > >> On 10/28/2010 3:27 PM, Denis Lila wrote: > >>>> If we moved to a Curve class or some other way to > >>>> consolidate the 3 lists (may be easier in native code), this > might > >> win > >>>> in more cases... > >>> > >>> Does that mean you no longer think we should flatten every curve > as > >> soon > >>> as we get it? > >> > >> No, I was just discussion the feasibility of that one suggestion > in > >> the > >> context of all of the possibilities of whether or not we took the > >> other > >> choices. If you think that flattening will pay off then we don't > have > >> > >> to worry about the 3 lists. It was just that when I hacked it in, > I > >> still had your 3 lists and so the pros and cons of horizontal edge > >> sorting were relative to that version of the renderer... > >> > >> ...jim From james.graham at oracle.com Tue Nov 2 18:00:56 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 02 Nov 2010 18:00:56 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <949127986.2128921288739428968.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <949127986.2128921288739428968.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CD0B448.8030306@oracle.com> Hi Denis, I had a bit of luck with the following next() method: private int next() { // TODO: make function that convert from y value to bucket idx? int bucket = nextY - boundsMinY; for (int ecur = edgeBuckets[bucket]; ecur != NULL; ecur = (int)edges[ecur+NEXT]) { edgePtrs = LilaHelpers.widenArray(edgePtrs, edgeCount, 1); edgePtrs[edgeCount++] = ecur; // REMIND: Adjust start Y if necessary } int crossingCount = edgeCount; crossings = LilaHelpers.widenArray(crossings, 0, crossingCount); nextY++; for (int i = 0; i < edgeCount; i++) { int ecur = edgePtrs[i]; float curx = edges[ecur+CURX]; int cross = ((int) curx) << 1; edges[ecur+CURX] = curx + edges[ecur+SLOPE]; if (edges[ecur+OR] > 0) { cross |= 1; } int j = i; while (--j >= 0) { int jcross = crossings[j]; if (jcross <= cross) { break; } crossings[j+1] = jcross; edgePtrs[j+1] = edgePtrs[j]; } crossings[j+1] = cross; edgePtrs[j+1] = ecur; } int newCount = 0; for (int i = 0; i < edgeCount; i++) { int ecur = edgePtrs[i]; if (edges[ecur+YMAX] > nextY) { edgePtrs[newCount++] = ecur; } } edgeCount = newCount; return crossingCount; } This allowed me to: - delete a lot of the bucket helper functions. - get rid of the back pointers - pare an edge down to 5 values (YMAX, CURX, OR, SLOPE, and NEXT) I also used the following addLine() method: private void addLine(float x1, float y1, float x2, float y2, int or) { final int firstCrossing = (int)Math.max(Math.ceil(y1), boundsMinY); if (firstCrossing >= boundsMaxY) { return; } final int ptr = numEdges * SIZEOF_EDGE; final float slope = (x2 - x1) / (y2 - y1); edges = LilaHelpers.widenArray(edges, ptr, SIZEOF_EDGE); numEdges++; edges[ptr+OR] = or; edges[ptr+CURX] = x1 + (firstCrossing - y1) * slope; edges[ptr+SLOPE] = slope; edges[ptr+YMAX] = y2; final int bucketIdx = firstCrossing - boundsMinY; addEdgeToBucket(ptr, bucketIdx); } How does that fare for you? ...jim On 11/2/2010 4:10 PM, Denis Lila wrote: > Hi Jim. > > I implemented a middle ground between what I sent yesterday and > what we have now: using the array of linked lists only to replace > the quicksort (I think this was your original suggestion). > > Unfortunately, this didn't work out (at least according to the > benchmarks). Curves were no different than what we used to have, > while the performance on lines (especially horizontal ones) decreased > significantly. > > It's not obvious to me why this happened, so I think now I will put > this type of optimization aside and convert to JNI, where profiling > will be easier (for me - I haven't been able to make OProfile work > for java yet). > > Regards, > Denis. > > ----- "Jim Graham" wrote: > >> Hi Denis, >> >> A generic suggestion - make all of your classes final - that gives the >> >> compiler the maximum flexibility to inline any methods you write. >> >> With respect to the algorithm choices: >> >> I think they key is that the X sorting rarely has any work to do. The >> >> first test of "does this edge need to be swapped with the next lower >> edge" is probably 99.999% guaranteed to be false. Thus, trying to >> optimize anything else to simplify swapping is likely a step in the >> wrong direction. >> >> The casting may be hurting a bit more, and it is hurting on every >> access >> to an edge. >> >> I'm guessing the best model to use would be to write the code to >> assume >> no swapping is necessary at all. Get that code as simple and as fast >> as >> can be. Then add as little perturbation of that code to manage >> swapping >> when it is necessary, and that will likely be the optimal >> implementation. I think you could probably even do some benchmarking >> on >> a path that is carefully tested to process lots of edges without any X >> >> sorting and get that as fast as you can without any swap code, and >> then >> add the swap code that impacts the performance of that operation as >> little as possible. The key is that the swap code have as little >> impact >> on the performance of the case that never needs any swapping at all >> first and foremost - then make swapping faster within that >> constraint... >> >> ...jim >> >> On 11/1/10 3:13 PM, Denis Lila wrote: >>> Hi Jim. >>> >>> I implemented your bucket sort idea. I'm not just using the buckets >>> to remove the y-sort. I use them in the iteration through the >> scanlines >>> too. What happens is that on any iteration, the active list is the >>> doubly linked list buckets[nextY-boundsMinY]. I did this because I >> thought >>> less memory would need to be moved around compared to when we just >> kept >>> the active list "pointers" in an array. For example, with doubly >> linked >>> lists we can implement insertion sort with O(1) writes. With arrays >> we >>> have to use O(n) writes. This also allows us to get rid of the the >> edgePtrs >>> array. >>> >>> I ran some benchmarks, and unfortunately I was wrong, somehwere. All >> the tests >>> are at least 10% slower than the insertion sort version of what we >> have now. >>> I can't immediately see why this is. The only thing I can think of >> is that >>> there are a lot of float -> int casts, but then again, I don't know >> how >>> slow this operation is. It would be good if it's because of the >> casts because >>> it would no longer be an issue when we convert to native. >>> >>> I alo made an unrelated change: I now find the orientation and >> update x0,y0 >>> much earlier than we used to. The way I was doing it before was >> silly. >>> >>> Regards, >>> Denis. >>> >>> ----- "Jim Graham" wrote: >>> >>>> Hi Denis, >>>> >>>> Good news! >>>> >>>> On 10/28/2010 3:27 PM, Denis Lila wrote: >>>>>> If we moved to a Curve class or some other way to >>>>>> consolidate the 3 lists (may be easier in native code), this >> might >>>> win >>>>>> in more cases... >>>>> >>>>> Does that mean you no longer think we should flatten every curve >> as >>>> soon >>>>> as we get it? >>>> >>>> No, I was just discussion the feasibility of that one suggestion >> in >>>> the >>>> context of all of the possibilities of whether or not we took the >>>> other >>>> choices. If you think that flattening will pay off then we don't >> have >>>> >>>> to worry about the 3 lists. It was just that when I hacked it in, >> I >>>> still had your 3 lists and so the pros and cons of horizontal edge >>>> sorting were relative to that version of the renderer... >>>> >>>> ...jim From lana.steuck at oracle.com Wed Nov 3 08:19:35 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Nov 2010 15:19:35 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d: 10 new changesets Message-ID: <20101103151935.7D4634769C@hg.openjdk.java.net> Changeset: 1fa39984ba8c Author: igor Date: 2010-09-03 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/1fa39984ba8c 6978977: Productivity: use ant for java part of build Reviewed-by: mduigou, herrick, ohair, ngthomas ! .hgignore ! make/deploy-rules.gmk Changeset: 85736b9f2026 Author: herrick Date: 2010-09-17 07:08 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/rev/85736b9f2026 Merge Changeset: d4a7e4600b21 Author: herrick Date: 2010-09-17 07:10 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/rev/d4a7e4600b21 Merge Changeset: 810a461889ab Author: igor Date: 2010-09-28 10:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/810a461889ab 6982520: Move kernel to install ws Reviewed-by: herrick, billyh ! make/deploy-rules.gmk Changeset: 2a7813a9b529 Author: herrick Date: 2010-10-02 11:08 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/rev/2a7813a9b529 Merge Changeset: fd3a1c515903 Author: jqzuo Date: 2010-10-04 16:36 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/rev/fd3a1c515903 6983855: The jre combo bundle target needs to be added in the makefile Reviewed-by: billyh, paulk ! make/install-rules.gmk Changeset: 5cc9bb94398a Author: jqzuo Date: 2010-10-12 13:29 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/rev/5cc9bb94398a Merge Changeset: e8ebdf41b9c0 Author: jqzuo Date: 2010-10-18 11:13 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/rev/e8ebdf41b9c0 Merge Changeset: 94e9a1bfba8b Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/94e9a1bfba8b Added tag jdk7-b115 for changeset e8ebdf41b9c0 ! .hgtags Changeset: 7220e60b097f Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/7220e60b097f Added tag jdk7-b116 for changeset 94e9a1bfba8b ! .hgtags From lana.steuck at oracle.com Wed Nov 3 08:19:41 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Nov 2010 15:19:41 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/corba: 2 new changesets Message-ID: <20101103151943.B05034769D@hg.openjdk.java.net> Changeset: 98c028de4301 Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/98c028de4301 Added tag jdk7-b115 for changeset da7561d479e0 ! .hgtags Changeset: fa502e4834da Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/fa502e4834da Added tag jdk7-b116 for changeset 98c028de4301 ! .hgtags From lana.steuck at oracle.com Wed Nov 3 08:25:38 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Nov 2010 15:25:38 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: 47 new changesets Message-ID: <20101103152702.02E584769E@hg.openjdk.java.net> Changeset: 1c52033222eb Author: trims Date: 2010-10-01 18:04 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/1c52033222eb Added tag hs20-b01 for changeset 5511edd5d719 ! .hgtags Changeset: c77e8f982901 Author: never Date: 2010-09-15 20:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c77e8f982901 6984979: OptimizeFill misses some cases with an odd memory graph Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: fd5d4527cdf5 Author: iveresov Date: 2010-09-21 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/fd5d4527cdf5 6986270: guarantee(*bcp != Bytecodes::_monitorenter || exec_mode != Deoptimization::Unpack_exception) fails Summary: Propagate the compiler type of the deopting method to vframeArrayElement::unpack_on_stack() Reviewed-by: jrose, never ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 5867d89c129b Author: never Date: 2010-09-22 13:01 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/5867d89c129b 6982537: Crash in Node*step_through_mergemem Reviewed-by: kvn ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/memnode.cpp Changeset: 87b64980e2f1 Author: never Date: 2010-09-22 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/87b64980e2f1 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld Reviewed-by: kvn ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp Changeset: c40600e85311 Author: never Date: 2010-09-22 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c40600e85311 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub Reviewed-by: kvn, twisti ! src/share/vm/opto/stringopts.cpp Changeset: c93c652551b5 Author: twisti Date: 2010-09-24 03:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c93c652551b5 6986944: JSR 292 assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site Reviewed-by: never, kvn ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/ci/ciMethod.cpp Changeset: f02a8bbe6ed4 Author: roland Date: 2009-12-29 19:08 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f02a8bbe6ed4 6986046: C1 valuestack cleanup Summary: fixes an historical oddity in C1 with inlining where all of the expression stacks are kept in the topmost ValueStack instead of being in their respective ValueStacks. Reviewed-by: never Contributed-by: Christian Wimmer ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/includeDB_compiler1 Changeset: 861f533d12b0 Author: roland Date: 2010-09-24 13:14 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/861f533d12b0 Merge Changeset: df015ec64052 Author: iveresov Date: 2010-09-27 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/df015ec64052 6987115: Non-tiered compilation policy creates unnecessary C1 threads Summary: Fixed NonTieredCompPolicy::compiler_count() to return correct thread count. Reviewed-by: twisti, kvn ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 1375bc8922e4 Author: never Date: 2010-09-27 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/1375bc8922e4 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified Reviewed-by: roland, kvn, iveresov ! src/share/vm/c1/c1_ValueStack.hpp Changeset: 8aa5fd5d2046 Author: twisti Date: 2010-09-29 00:30 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/8aa5fd5d2046 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument Reviewed-by: never, kvn ! src/share/vm/opto/doCall.cpp Changeset: ad0638ff8ea4 Author: roland Date: 2010-09-29 18:53 +0200 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ad0638ff8ea4 6988303: 6986046 breaks build with recent gcc Summary: fixes build break Reviewed-by: never, kvn ! src/share/vm/c1/c1_Instruction.hpp Changeset: 80c9354976b0 Author: iveresov Date: 2010-09-29 16:53 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/80c9354976b0 6988346: 6986046 breaks tiered Summary: adjusted profiling code generation to use the new ValueStack implementation; lowered optimization level for c1_LinearScan.cpp on solaris x64. Reviewed-by: kvn, never ! make/solaris/makefiles/amd64.make ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 56601ef83436 Author: kvn Date: 2010-09-30 18:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/56601ef83436 6916062: assert(_inserts <= _insert_limit,"hash table overflow") in NodeHash::hash_insert Summary: Missing check for not empty worklist when puting memory node back on worklist and expecting address type update. Reviewed-by: never ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp Changeset: 52e82a6bedaf Author: never Date: 2010-10-04 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/52e82a6bedaf 6968348: Byteswapped memory access can point to wrong location after JIT Reviewed-by: twisti, kvn, iveresov ! src/cpu/x86/vm/x86_64.ad + test/compiler/6968348/Test6968348.java Changeset: 3f9a70eb8b1f Author: iveresov Date: 2010-10-05 00:19 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3f9a70eb8b1f 6989368: Regression in scimark2.MonteCarlo in jdk7_b112 on Linux Summary: Fix ciMethod::instructions_size() to return correct value Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp Changeset: fe08403130db Author: kvn Date: 2010-10-05 08:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/fe08403130db 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big Summary: Set upper limit 256 for ObjectAlignmentInBytes value. Reviewed-by: never, iveresov ! src/share/vm/runtime/arguments.cpp Changeset: a3f7f95b0165 Author: never Date: 2010-10-05 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a3f7f95b0165 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler Reviewed-by: iveresov, kvn, kamg ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: a50abfc67f31 Author: never Date: 2010-10-05 17:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a50abfc67f31 6989736: fix mapfile warnings on solaris Reviewed-by: kvn, iveresov, jcoomes ! make/linux/adlc_updater ! make/solaris/adlc_updater ! make/solaris/makefiles/reorder_COMPILER1_i486 ! make/solaris/makefiles/reorder_COMPILER1_sparc ! make/solaris/makefiles/reorder_TIERED_amd64 ! make/solaris/makefiles/reorder_TIERED_i486 ! make/solaris/makefiles/reorder_TIERED_sparc ! make/solaris/makefiles/reorder_TIERED_sparcv9 Changeset: 22e4420d19f7 Author: kvn Date: 2010-10-06 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/22e4420d19f7 Merge ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 8b10f48633dc Author: jmasa Date: 2010-09-20 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/8b10f48633dc 6984287: Regularize how GC parallel workers are specified. Summary: Associate number of GC workers with the workgang as opposed to the task. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 22cace5e30b5 Author: jcoomes Date: 2010-09-08 16:10 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/22cace5e30b5 6983296: build sanity checks for jdk7 should require SS12u1 Reviewed-by: ohair ! make/solaris/makefiles/sparcWorks.make Changeset: 4805b9f4779e Author: johnc Date: 2010-09-28 09:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/4805b9f4779e 6941395: G1: Use only lock-free versions of region stack push() and pop() Summary: Re-enable use of the lock-free versions of region stack push() and pop() by recording aborted regions in a thread-local structure, which are then processed when scanning of the region stack restarts. The previous locking versions of these routines are retained for diagnostic purposes. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 894b1d7c7e01 Author: jcoomes Date: 2010-09-28 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/894b1d7c7e01 6423256: GC stacks should use a better data structure 6942771: SEGV in ParScanThreadState::take_from_overflow_stack Reviewed-by: apetrusenko, ysr, pbk ! 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/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_serial ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + src/share/vm/utilities/stack.hpp + src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: c99c53f07c14 Author: ysr Date: 2010-09-29 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c99c53f07c14 6692906: CMS: parallel concurrent marking may be prone to hanging or stalling mutators for periods of time Summary: Inserted missing yield(check)s in closures used during the work-stealing phase of parallel concurrent marking, a missing synchronous yield-request in the cms perm gen allocation path, and a terminator-terminator for the offer_termination invocation that monitors the yield status of the concurrent marking task. Elaborated some documentation comments and made some task queue termination loop flags configurable at start-up to aid debugging in the field. Reviewed-by: jmasa, johnc, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 8f6f7587d292 Author: jcoomes Date: 2010-09-30 12:15 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/8f6f7587d292 6988678: fatal error deadlock handling was unintentionally disabled Reviewed-by: ysr ! src/share/vm/runtime/thread.cpp Changeset: e41cd7fd68a6 Author: ysr Date: 2010-10-01 16:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/e41cd7fd68a6 6794422: Perm gen expansion policy for concurrent collectors Summary: Concurrent collectors should expand the perm gen without a full STW GC, but possibly by triggering a concurrent collection. Temporary band-aid for G1 where no concurrent collection is kicked off since the perm gen is not collected concurrently. Reviewed-by: johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/permGen.hpp Changeset: 4e0094bc41fa Author: johnc Date: 2010-10-01 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/4e0094bc41fa 6983311: G1: LoopTest hangs when run with -XX:+ExplicitInvokesConcurrent Summary: Clear the concurrent marking "in progress" flag while the FullGCCount_lock is held. This avoids a race that can cause back to back System.gc() calls, when ExplicitGCInvokesConcurrent is enabled, to fail to initiate a marking cycle causing the requesting thread to hang. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 32a1f7bf0c21 Author: johnc Date: 2010-10-01 21:48 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/32a1f7bf0c21 Merge Changeset: 6e0aac35bfa9 Author: tonyp Date: 2010-10-01 16:43 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/6e0aac35bfa9 6980838: G1: guarantee(false) failed: thread has an unexpected active value in its SATB queue Summary: Under certain circumstances a safepoint could happen between a JavaThread object being created and that object being added to the Java threads list. This could cause the active field of that thread's SATB queue to get out-of-sync with respect to the other Java threads. The solution is to activate the SATB queue, when necessary, before adding the thread to the Java threads list, not when the JavaThread object is created. The changeset also includes a small fix to rename the surrogate locker thread from "Surrogate Locker Thread (CMS)" to "Surrogate Locker Thread (Concurrent GC)" since it's also used in G1. Reviewed-by: iveresov, ysr, johnc, jcoomes ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 0715f0cf171d Author: jcoomes Date: 2010-10-08 09:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/0715f0cf171d Merge ! src/share/vm/includeDB_core ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 75588558f1bf Author: never Date: 2010-10-07 21:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/75588558f1bf 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" Reviewed-by: kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/runtime.cpp Changeset: a222fcfba398 Author: twisti Date: 2010-10-08 02:42 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a222fcfba398 6990549: Zero and Shark fixes after 6978355 and 6953144 Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/interpreterRT_zero.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/shark/sharkCompiler.hpp Changeset: d55217dc206f Author: twisti Date: 2010-10-11 04:18 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/d55217dc206f 6829194: JSR 292 needs to support compressed oops Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/oop.inline.hpp Changeset: a932f331ef90 Author: twisti Date: 2010-10-12 02:21 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a932f331ef90 6991065: missed a review comment in 6829194 Reviewed-by: kvn ! src/share/vm/classfile/classFileParser.cpp Changeset: c393f046f4c5 Author: iveresov Date: 2010-10-12 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c393f046f4c5 6991512: G1 barriers fail with 64bit C1 Summary: Fix compare-and-swap intrinsic problem with G1 post-barriers and issue with branch ranges in G1 stubs on sparc Reviewed-by: never, kvn ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 5beba6174298 Author: twisti Date: 2010-10-13 01:19 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/5beba6174298 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC Reviewed-by: never, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp + test/compiler/6987555/Test6987555.java Changeset: ecca2e3e2767 Author: twisti Date: 2010-10-13 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ecca2e3e2767 Merge Changeset: 357451a9ae6a Author: roland Date: 2010-10-13 10:29 +0200 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/357451a9ae6a 6991211: assert failure on sparc: "can not have caller-save register operands at calls" Summary: fixes sparc only assert failure following 6972540 Reviewed-by: never ! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp Changeset: 94d77a279225 Author: roland Date: 2010-10-13 15:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/94d77a279225 Merge Changeset: b98784e85f71 Author: kvn Date: 2010-10-14 10:46 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b98784e85f71 Merge Changeset: 52f19c724d96 Author: trims Date: 2010-10-14 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/52f19c724d96 Merge ! .hgtags Changeset: 570870354f86 Author: trims Date: 2010-10-14 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/570870354f86 6992267: Bump the HS20 build number to 02 Summary: Update the HS20 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: bdbc48857210 Author: trims Date: 2010-10-20 16:49 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/bdbc48857210 Merge ! .hgtags Changeset: 96b3f2a7add0 Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/96b3f2a7add0 Added tag jdk7-b115 for changeset bdbc48857210 ! .hgtags Changeset: 806d0c037e6b Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/806d0c037e6b Added tag jdk7-b116 for changeset 96b3f2a7add0 ! .hgtags From lana.steuck at oracle.com Wed Nov 3 08:28:14 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Nov 2010 15:28:14 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: 2 new changesets Message-ID: <20101103152814.AD13F4769F@hg.openjdk.java.net> Changeset: f8d4e6c6cfce Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/f8d4e6c6cfce Added tag jdk7-b115 for changeset dc1612e1d3ac ! .hgtags Changeset: 9ee4d96e8934 Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/9ee4d96e8934 Added tag jdk7-b116 for changeset f8d4e6c6cfce ! .hgtags From lana.steuck at oracle.com Wed Nov 3 08:28:20 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Nov 2010 15:28:20 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: 2 new changesets Message-ID: <20101103152820.148B7476A0@hg.openjdk.java.net> Changeset: 376ac153078d Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/376ac153078d Added tag jdk7-b115 for changeset 824cc44bd6eb ! .hgtags Changeset: 1320fb3bb588 Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/1320fb3bb588 Added tag jdk7-b116 for changeset 376ac153078d ! .hgtags From lana.steuck at oracle.com Wed Nov 3 08:32:07 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Nov 2010 15:32:07 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 111 new changesets Message-ID: <20101103155002.EC331476A2@hg.openjdk.java.net> Changeset: f96548542368 Author: igor Date: 2010-08-12 23:21 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f96548542368 6976516: Add support for compiling deploy ws without compiling j2se Reviewed-by: herrick, ohair ! make/common/internal/Resources.gmk Changeset: 6841ece60936 Author: herrick Date: 2010-08-20 14:48 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6841ece60936 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: ea7e333308ed Author: igor Date: 2010-09-01 09:36 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ea7e333308ed 6981436: Variable gets hidden if Defs-javadoc is included Reviewed-by: ohair ! make/common/shared/Defs-javadoc.gmk ! make/docs/Makefile Changeset: 72136d9a079f Author: jqzuo Date: 2010-09-02 09:23 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/72136d9a079f Merge - src/share/classes/sun/java2d/pisces/PiscesMath.java - src/share/classes/sun/java2d/pisces/Transform4.java - test/tools/pack200/Pack200Simple.sh - test/tools/pack200/SegmentLimit.java Changeset: a7fa35166b92 Author: igor Date: 2010-09-07 11:24 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a7fa35166b92 6982774: HOTSPOT_IMPORT_PATH detection does not work as expected Reviewed-by: herrick, ohair ! make/common/shared/Defs.gmk Changeset: 0dc672582a47 Author: igor Date: 2010-09-07 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0dc672582a47 6982499: ant detection is fragile on windows. especially using cygwin Reviewed-by: ohair ! make/common/shared/Defs.gmk Changeset: af2d0f81e1ac Author: herrick Date: 2010-09-16 12:19 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/af2d0f81e1ac Merge Changeset: e463b0e829c8 Author: herrick Date: 2010-09-17 07:11 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e463b0e829c8 Merge Changeset: dc1bb8cf6ff6 Author: herrick Date: 2010-10-02 11:09 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/dc1bb8cf6ff6 Merge - src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java - src/share/native/sun/java2d/cmm/lcms/cmscam97.c - src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c - src/share/native/sun/java2d/cmm/lcms/icc34.h - src/share/native/sun/java2d/cmm/lcms/lcms.h - src/solaris/classes/sun/net/spi/SdpProvider.java - src/solaris/native/sun/net/spi/SdpProvider.c - test/java/util/Locale/data/deflocale.exe - test/java/util/Locale/data/deflocale.jds3 - test/java/util/Locale/data/deflocale.rhel4 - test/java/util/Locale/data/deflocale.winvista - test/java/util/Locale/data/deflocale.winxp - test/tools/launcher/VerifyExceptions.java Changeset: 0dcee22ced98 Author: jqzuo Date: 2010-10-12 13:34 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0dcee22ced98 Merge Changeset: 449bad8d67b5 Author: jqzuo Date: 2010-10-18 11:25 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/449bad8d67b5 Merge - make/common/Rules-SCCS.gmk ! make/common/shared/Defs.gmk - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 9c4165d5661c Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9c4165d5661c Added tag jdk7-b115 for changeset 449bad8d67b5 ! .hgtags Changeset: 1b658b8bd49d Author: art Date: 2010-10-05 18:12 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1b658b8bd49d 6829546: Modal dialog causes underlying parent JFrame to be set to "Always on top". Reviewed-by: anthony, dcherepanov ! src/windows/native/sun/windows/awt_Dialog.cpp + test/java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java Changeset: e804b396307b Author: art Date: 2010-10-05 18:13 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e804b396307b 6828273: javax/swing/system/6799345/TestShutdown.java test fails with RuntimeException. Reviewed-by: anthony, dcherepanov ! src/solaris/classes/sun/awt/X11/XToolkit.java ! test/javax/swing/system/6799345/TestShutdown.java Changeset: 16265781795b Author: art Date: 2010-10-06 16:42 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/16265781795b 6979541: closed/javax/swing/plaf/basic/AWTEventListenerLeak/AWTEventListenerLeak.java fails Reviewed-by: anthony, ant ! src/share/classes/sun/awt/SunToolkit.java Changeset: 335093475c11 Author: anthony Date: 2010-10-12 15:52 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/335093475c11 6895647: Frame may jump to an unpredicted location upon entering the non-opaque mode on X11 Summary: Make sure the size hints are set before mapping the window on the screen Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java + test/java/awt/Frame/FrameLocation/FrameLocation.java Changeset: a8bd5f04f4fb Author: anthony Date: 2010-10-12 18:20 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a8bd5f04f4fb 6990352: SplashScreen.getSplashScreen() does not return null for implicitly closed splash screen Summary: Mark the splash screen closed when it happens implicitly Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Window.java Changeset: 278bd32a15de Author: dav Date: 2010-10-13 17:03 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/278bd32a15de 6973199: java/awt/Robot/RobotWheelTest/RobotWheelTest.html failed on JDK7 b102 bug passed on b101 Reviewed-by: art, yan ! src/solaris/classes/sun/awt/X11/XWindow.java Changeset: c595c2730226 Author: art Date: 2010-10-14 14:07 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c595c2730226 6989721: awt native code compiler warnings Reviewed-by: yan, uta ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/native/sun/awt/libpng/pngrtran.c ! src/share/native/sun/awt/libpng/pngrutil.c ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/native/sun/awt/awt.h ! src/solaris/native/sun/awt/awt_DrawingSurface.c ! src/solaris/native/sun/awt/awt_InputMethod.c ! src/solaris/native/sun/awt/awt_Robot.c ! src/solaris/native/sun/awt/awt_UNIXToolkit.c ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/solaris/native/sun/xawt/awt_Desktop.c ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/awt_BitmapUtil.cpp ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_DrawingSurface.h ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 8022709a306d Author: dcherepanov Date: 2010-10-14 18:24 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8022709a306d 6991992: Need to forward-port AWT's part of the fix for 6691674 Reviewed-by: art ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/InfoWindow.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: f55be3060347 Author: anthony Date: 2010-10-14 18:59 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f55be3060347 6979568: Test failure: test\closed\java\awt\Component\VisibleHwInLwContTest\VisibleHwInLwContTest.html Summary: Extend iteration to this container in isRecursivelyVisibleUpToHeavyweightContainer() Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Container.java Changeset: b183180e8bb7 Author: dcherepanov Date: 2010-10-14 18:56 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b183180e8bb7 6838089: java.awt.Window.setOpacity() doesn't throw IllegalComponentStateException for two-display conf Reviewed-by: art, anthony ! src/share/classes/java/awt/Canvas.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java + test/java/awt/Multiscreen/TranslucencyThrowsExceptionWhenFullScreen/TranslucencyThrowsExceptionWhenFullScreen.java Changeset: 69eeb1cea943 Author: lana Date: 2010-10-17 19:43 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/69eeb1cea943 Merge - make/common/Rules-SCCS.gmk ! src/solaris/native/sun/awt/awt_InputMethod.c - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 70a695f74efb Author: lana Date: 2010-10-18 21:44 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/70a695f74efb Merge ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c Changeset: e26eef6ac0d6 Author: rupashka Date: 2010-10-07 12:48 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e26eef6ac0d6 6979793: closed/javax/swing/JFileChooser/6396844/TwentyThousandTest fails due FileNotFound exc. Reviewed-by: malenkov + test/javax/swing/JFileChooser/6396844/TwentyThousandTest.java Changeset: 93871607047a Author: amenkov Date: 2010-10-07 18:13 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/93871607047a 6984047: sound sources needs vendor rebranding changes (jdk7 only) Reviewed-by: ohair ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/share/classes/javax/sound/sampled/AudioSystem.java Changeset: 958ddd568d4e Author: amenkov Date: 2010-10-07 18:23 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/958ddd568d4e 6986335: 10 regtest failures (test/javax/sound/midi/Gervil) due AudioFloatConverter.PCM_FLOAT not found Reviewed-by: dav ! test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java Changeset: 940fed1764b4 Author: peytoia Date: 2010-10-08 09:50 +0900 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/940fed1764b4 6970930: RuleBasedCollator.compare(String,null) throws IAE (should be NPE) Reviewed-by: okutsu ! src/share/classes/java/text/RuleBasedCollator.java + test/java/text/Collator/Bug6970930.java Changeset: b2cfe62ef802 Author: naoto Date: 2010-10-12 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b2cfe62ef802 6989440: tomcat test from dacapo benchmark fails with ConcurrentModificationException Reviewed-by: okutsu Contributed-by: y.umaoka at gmail.com ! src/share/classes/sun/util/LocaleServiceProviderPool.java + test/java/util/Locale/Bug6989440.java Changeset: 23fd99021d35 Author: malenkov Date: 2010-10-13 15:18 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/23fd99021d35 6603635: links to tutorials broken in JTable API doc Reviewed-by: alexp ! src/share/classes/javax/swing/JTable.java Changeset: 1d56dff60eb1 Author: rupashka Date: 2010-10-14 13:33 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1d56dff60eb1 6984643: Unable to instantiate JFileChooser with a minimal BasicL&F descendant installed Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java + test/javax/swing/plaf/basic/Test6984643.java Changeset: d3c60dbfce57 Author: alexp Date: 2010-10-14 18:46 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d3c60dbfce57 6986385: JLayer should implement accessible interface Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java + test/javax/accessibility/6986385/bug6986385.java Changeset: cdbb6e073c60 Author: naoto Date: 2010-10-14 11:37 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/cdbb6e073c60 6575419: Solaris : XSetICFoucs is not called with Java application at appropriate timing Reviewed-by: okutsu ! src/solaris/classes/sun/awt/X11InputMethod.java Changeset: abc171d85be6 Author: naoto Date: 2010-10-14 12:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/abc171d85be6 6991013: Serialized form for java.util.Locale contains typos Reviewed-by: peytoia ! src/share/classes/java/util/Locale.java Changeset: 308130a84ab7 Author: okutsu Date: 2010-10-15 16:46 +0900 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/308130a84ab7 6638110: (tz) TimeZone.getDisplayName(...) spec is inconsistent with implementation for unavailable locales Reviewed-by: peytoia ! src/share/classes/java/util/TimeZone.java Changeset: bcb09768ba1e Author: lana Date: 2010-10-15 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/bcb09768ba1e Merge - make/common/Rules-SCCS.gmk - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 954b5eb4a256 Author: naoto Date: 2010-10-18 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/954b5eb4a256 6992272: I18N: Locale.getDisplayName() and toString() return empty if just script is set Reviewed-by: srl Contributed-by: y.umaoka at gmail.com ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: cf13977eb9c0 Author: lana Date: 2010-10-18 21:46 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/cf13977eb9c0 Merge Changeset: b468b20a98a8 Author: alanb Date: 2010-10-05 15:07 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b468b20a98a8 6987116: (so) test/java/nio/channels/SocketChannel/VectorIO.java failed on Solaris 11 Reviewed-by: forax ! test/java/nio/channels/SocketChannel/VectorIO.java Changeset: 0f23a139e819 Author: lancea Date: 2010-10-06 10:09 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0f23a139e819 6988310: SyncFactory.setLogger(Logger,Level) requires unspecified security permission Reviewed-by: darcy ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: 6fd4928b82a2 Author: lancea Date: 2010-10-06 10:11 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6fd4928b82a2 6988317: RowSetProvider.newFactory() may throw unspecified exception Reviewed-by: darcy ! src/share/classes/javax/sql/rowset/RowSetProvider.java Changeset: a6295291fab1 Author: darcy Date: 2010-10-06 21:55 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a6295291fab1 6917323: serializable classes in java.dyn do not specify serialVersionUIDs Reviewed-by: jrose ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/NoAccessException.java ! src/share/classes/java/dyn/WrongMethodTypeException.java ! src/share/classes/java/lang/LinkageError.java Changeset: a2b1ef1294c5 Author: alanb Date: 2010-10-07 10:35 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a2b1ef1294c5 6989903: (process) test/java/lang/ProcessBuilder/Basic.java failing with "Bad file number" (sol) Reviewed-by: ohair, chegar ! test/java/lang/ProcessBuilder/Basic.java Changeset: 871cffb21423 Author: alanb Date: 2010-10-07 14:36 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/871cffb21423 6989466: Miscellaneous compiler warnings in java/lang, java/util, java/io, sun/misc native code Reviewed-by: andrew, mchung, ohair ! src/share/native/common/jdk_util.c ! src/share/native/common/jni_util.c ! src/share/native/java/lang/Class.c ! src/share/native/java/lang/ClassLoader.c ! src/share/native/java/lang/System.c ! src/share/native/java/lang/fdlibm/include/fdlibm.h ! src/share/native/java/lang/reflect/Proxy.c ! src/share/native/java/nio/Bits.c ! src/share/native/sun/management/Flag.c ! src/share/native/sun/misc/VM.c ! src/share/native/sun/misc/VMSupport.c ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/canonicalize_md.c ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/sun/net/sdp/SdpSupport.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/ch/SctpNet.c ! src/solaris/native/sun/nio/ch/UnixAsynchronousSocketChannelImpl.c ! src/windows/native/common/jni_util_md.c ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/java/util/TimeZone_md.c ! src/windows/native/sun/nio/ch/ServerSocketChannelImpl.c ! src/windows/native/sun/nio/ch/WindowsSelectorImpl.c Changeset: efa8f714fffb Author: sherman Date: 2010-10-07 11:35 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/efa8f714fffb 6975829: Perf. of gzip in existing JDKs is too slower than in 1.3.1 Summary: Improved memory/buffer handling in Inflater.c Reviewed-by: alanb ! src/share/native/java/util/zip/Inflater.c Changeset: fd20568bebff Author: alanb Date: 2010-10-08 10:36 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fd20568bebff 6989116: (verifier) compiler warning messages Reviewed-by: kamg, ohair ! src/share/native/common/check_code.c Changeset: d122e96be7d2 Author: alanb Date: 2010-10-08 10:37 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d122e96be7d2 Merge Changeset: 63162f0e2609 Author: sherman Date: 2010-10-08 12:23 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/63162f0e2609 6990639: Fix for #6975829 breaks build Summary: define MIN2 micro Reviewed-by: alanb ! src/share/native/java/util/zip/Inflater.c Changeset: f0888585b6ff Author: alanb Date: 2010-10-11 09:17 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f0888585b6ff 6987154: HTML link to serialization guide is broken Reviewed-by: skannan ! src/share/classes/java/io/package.html Changeset: 0e3daaccfbdf Author: xuelei Date: 2010-06-12 00:42 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0e3daaccfbdf 6914943: Implement final TLS renegotiation fix Summary: RFC 5746 implementation Reviewed-by: wetmore, weijun ! src/share/classes/sun/security/ssl/Alerts.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/TestAllSuites.java ! test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java ! test/sun/security/ssl/sanity/interop/CipherTest.java Changeset: 5d7925b886b9 Author: asaha Date: 2010-06-13 07:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5d7925b886b9 Merge Changeset: 34080da7fab2 Author: asaha Date: 2010-06-15 08:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/34080da7fab2 Merge Changeset: 2bad540d9b5b Author: weijun Date: 2010-06-17 12:59 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2bad540d9b5b 6957564: Disclosure of DNS server IP address Reviewed-by: xuelei, chegar ! src/share/classes/com/sun/jndi/dns/DnsContextFactory.java Changeset: bdc6a3dc3e57 Author: weijun Date: 2010-06-17 12:59 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/bdc6a3dc3e57 6958060: Malformed AP-REQ crashes acceptor side Reviewed-by: valeriep, xuelei ! src/share/classes/sun/security/jgss/krb5/InitialToken.java Changeset: b9d3a1a8b682 Author: bae Date: 2010-06-18 13:18 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b9d3a1a8b682 6925710: IndexColorModel.finalize can be made to double free Reviewed-by: igor, prr, hawtin ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/sun/awt/image/BufImgSurfaceData.java ! src/share/native/sun/awt/image/BufImgSurfaceData.c Changeset: 9ed7ae1e911c Author: rupashka Date: 2010-06-21 16:47 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9ed7ae1e911c 6938813: Swing mutable statics Reviewed-by: peterz, alexp ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/parser/DTD.java ! src/share/classes/javax/swing/text/html/parser/ParserDelegator.java + test/javax/swing/Security/6938813/bug6938813.java Changeset: e06652744211 Author: asaha Date: 2010-06-24 10:56 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e06652744211 Merge - make/com/sun/inputmethods/Makefile - make/com/sun/inputmethods/indicim/Makefile - make/com/sun/inputmethods/thaiim/Makefile - src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariInputMethodDescriptor.java - src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariTables.java - src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethod.java - src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethodImpl.java - src/share/classes/com/sun/inputmethods/internal/indicim/java.awt.im.spi.InputMethodDescriptor - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_de.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_es.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_fr.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_it.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ja.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ko.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_sv.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_CN.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_TW.properties - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethod.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodDescriptor.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodImpl.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiRules.java - src/share/classes/com/sun/inputmethods/internal/thaiim/java.awt.im.spi.InputMethodDescriptor - src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties - src/share/classes/javax/swing/text/html/parser/html32.bdtd - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java Changeset: 505befdee800 Author: asaha Date: 2010-06-28 13:07 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/505befdee800 Merge Changeset: 5f50e564faa4 Author: bae Date: 2010-06-30 11:32 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5f50e564faa4 6963023: ZDI-CAN-809: Sun JRE JPEGImageWriter.writeImage Remote Code Execution Vulnerability Reviewed-by: prr ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: de8991ef7b1b Author: chegar Date: 2010-06-30 16:08 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/de8991ef7b1b 6926623: Thread clone issues Reviewed-by: hawtin ! src/share/classes/java/lang/Thread.java Changeset: b2e9e8d1805c Author: chegar Date: 2010-06-30 16:24 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b2e9e8d1805c Merge Changeset: 32cac17b629e Author: bae Date: 2010-07-01 12:04 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/32cac17b629e 6963489: ZDI-CAN-803: Sun JRE ICC Profile Device Information Tag Remote Code Execution Vulnerability Reviewed-by: prr ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c Changeset: 0dbecf98ed6d Author: asaha Date: 2010-07-01 08:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0dbecf98ed6d Merge - test/java/nio/charset/coders/Surrogate.java Changeset: f56ef0d441b0 Author: asaha Date: 2010-07-08 08:23 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f56ef0d441b0 Merge Changeset: 814604212cc1 Author: asaha Date: 2010-07-16 09:26 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/814604212cc1 Merge - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: e860d935e6e7 Author: michaelm Date: 2010-07-22 16:33 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e860d935e6e7 6952603: NetworkInterface reveals local network address to untrusted code Reviewed-by: chegar ! src/share/classes/java/net/NetworkInterface.java Changeset: e857e8316bf1 Author: michaelm Date: 2010-07-22 17:26 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e857e8316bf1 6952017: HttpURLConnection chunked encoding issue (Http request splitting) Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 9fa1f8b38b6f Author: chegar Date: 2010-08-11 09:32 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9fa1f8b38b6f 6974093: Thread.clone should NOT invoke addUnstarted on started threads Reviewed-by: dholmes, coffeys ! src/share/classes/java/lang/Thread.java Changeset: f5ed38dc8d36 Author: michaelm Date: 2010-09-16 08:08 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f5ed38dc8d36 6981426: limit use of TRACE method in HttpURLConnection Reviewed-by: chegar ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/NetPermission.java Changeset: e0806d924a42 Author: michaelm Date: 2010-09-16 09:22 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e0806d924a42 6980004: limit HTTP request cookie headers in HttpURLConnection 6961084: limit setting of some request headers in HttpURLConnection Reviewed-by: chegar ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 11a08845b979 Author: michaelm Date: 2010-09-23 03:22 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/11a08845b979 6986400: Change Cookie to Cookie2 in 6980004 fix Summary: fix error in previous fix for 6980004 Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 0f510337dadb Author: alexp Date: 2010-10-01 18:39 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0f510337dadb 6622002: UIDefault.ProxyLazyValue has unsafe reflection usage Reviewed-by: malenkov ! src/share/classes/javax/swing/UIDefaults.java + test/javax/swing/UIDefaults/6622002/bug6622002.java Changeset: 33cc629889bd Author: chegar Date: 2010-10-08 11:27 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/33cc629889bd Merge ! src/share/classes/com/sun/jndi/dns/DnsContextFactory.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/native/sun/awt/image/BufImgSurfaceData.c ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c Changeset: a50828844ccc Author: chegar Date: 2010-10-08 11:28 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a50828844ccc Merge Changeset: 78bbe8fce2d4 Author: chegar Date: 2010-10-11 10:55 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/78bbe8fce2d4 Merge Changeset: b444f86c4abe Author: mchung Date: 2010-10-11 20:22 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b444f86c4abe 6977738: Deadlock between java.lang.ClassLoader and java.util.Properties Reviewed-by: alanb, sherman, darcy, igor ! make/java/java/FILES_java.gmk ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/XMLUtils.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/sun/jkernel/DownloadManager.java ! src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/VM.java + test/java/lang/ClassLoader/deadlock/GetResource.java ! test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: 33cf668cc160 Author: sherman Date: 2010-10-11 22:32 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/33cf668cc160 6984046: java/jar jar/pack source needs vendor rebranding changes (jdk7 only) Summary: updated to use appropriate vendor name Reviewed-by: ohair, dholmes ! src/share/classes/sun/tools/jar/CommandLine.java ! test/tools/jar/UpdateManifest.java Changeset: b614af87d00f Author: alanb Date: 2010-10-12 08:49 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b614af87d00f 6728842: File.setReadOnly does not make a directory read-only (win) 6464744: java/io/File/SetAccess.java ignores sticky bit Reviewed-by: forax ! src/windows/native/java/io/WinNTFileSystem_md.c ! test/java/io/File/SetAccess.java ! test/java/io/File/SetReadOnly.java Changeset: 1d94b33a8f59 Author: alanb Date: 2010-10-12 09:46 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1d94b33a8f59 6983520: java/io/pathNames/GeneralWin32.java fails with jdk7-b108 (win) Reviewed-by: sherman ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/io/io_util_md.h ! test/java/io/pathNames/GeneralWin32.java Changeset: 4dbd83eb0250 Author: chegar Date: 2010-10-12 11:11 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4dbd83eb0250 6989690: java/net native code compiler warnings Reviewed-by: alanb ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/sun/net/spi/DefaultProxySelector.c Changeset: a4fd754f895d Author: chegar Date: 2010-10-12 17:01 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a4fd754f895d 6991300: MimeTable is unsafe Reviewed-by: alanb, michaelm ! src/share/classes/sun/net/www/MimeTable.java Changeset: df896f3e6651 Author: ksrini Date: 2010-10-07 14:35 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/df896f3e6651 6894719: (launcher)The option -no-jre-restrict-search is expected when -jre-no-restrict-search is documented. Reviewed-by: darcy ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! test/tools/launcher/Arrrghs.java Changeset: 5eb6755dde8e Author: ksrini Date: 2010-10-12 12:20 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5eb6755dde8e Merge Changeset: 1b430727f00d Author: valeriep Date: 2010-10-12 17:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1b430727f00d 6887853: javadoc for java.lang.Classloader should be more clear Summary: Updated the relevant javadoc description of java.lang.ClassLoader class w/ additional clarification. Reviewed-by: mullan ! src/share/classes/java/lang/ClassLoader.java Changeset: 5cd4f89b8339 Author: ksrini Date: 2010-10-14 09:36 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5cd4f89b8339 6991164: pack source needs vendor rebranding changes (jdk7 only) Reviewed-by: ohair, jrose ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! test/tools/pack200/PackageVersionTest.java Changeset: 2278f3ff5f95 Author: lana Date: 2010-10-13 17:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2278f3ff5f95 Merge Changeset: 078723d34a6c Author: lana Date: 2010-10-14 11:07 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/078723d34a6c Merge Changeset: 96d78263fdf7 Author: valeriep Date: 2010-10-14 17:59 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/96d78263fdf7 6988081: Use GetPrimitiveArrayCritical instead GetByteArray to Reduce allocation in some sunpkcs jni wrappers Summary: Changed to use GetPrimitiveArrayCritical for encryption and decryption. Reviewed-by: vinnie ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c Changeset: 6b4e02e3be8e Author: valeriep Date: 2010-10-14 18:01 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6b4e02e3be8e 6850402: Deadlock on sun.security.jca.ProviderConfig starting from jdk7-b55 Summary: Reduced the scope of locking Reviewed-by: vinnie ! src/share/classes/sun/security/jca/Providers.java Changeset: 4cf17a89ead9 Author: alanb Date: 2010-10-15 12:10 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4cf17a89ead9 6976036: Dual-pivot quicksort update (10/2010 tune-up) Reviewed-by: alanb Contributed-by: vladimir.yaroslavskiy at oracle.com ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/Sorting.java Changeset: f24699d8c892 Author: alanb Date: 2010-10-15 15:09 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f24699d8c892 6743526: (bf) -XX:MaxDirectMemorySize= limits memory usage rather than total capacity as intended Reviewed-by: chegar ! src/share/classes/java/nio/Bits.java + test/java/nio/Buffer/LimitDirectMemory.java + test/java/nio/Buffer/LimitDirectMemory.sh Changeset: 0fc51ca3467d Author: mullan Date: 2010-10-15 10:55 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0fc51ca3467d 6954275: XML signatures with reference data larger 16KB and cacheRef on fails to validate Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayOutputStream.java + test/com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayOutputStream/BufferOverflowTest.java Changeset: bca7bd9ebf10 Author: mullan Date: 2010-10-15 10:59 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/bca7bd9ebf10 Merge Changeset: 7eae3422704f Author: ksrini Date: 2010-10-14 14:41 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7eae3422704f 6982312: (pack200) pack200 fails with the jdk7 class files Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java + test/tools/pack200/AttributeTests.java + test/tools/pack200/dyn.jar Changeset: 56b9bc2a0752 Author: ksrini Date: 2010-10-14 14:55 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/56b9bc2a0752 6746111: Improve pack200 error message Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! test/tools/pack200/AttributeTests.java + test/tools/pack200/badattr.jar Changeset: b79600ecf0e4 Author: alanb Date: 2010-10-18 10:29 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b79600ecf0e4 4837564: (bf) Please make DirectByteBuffer performance enhancements Reviewed-by: chegar ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/sun/misc/VM.java ! test/java/nio/Buffer/LimitDirectMemory.sh Changeset: c64772f0492f Author: alanb Date: 2010-10-18 10:31 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c64772f0492f Merge Changeset: 0f5bab573e01 Author: mullan Date: 2010-10-18 09:00 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0f5bab573e01 6988599: CertificateRevokedException specifies name of authority but interacts with authority instance Reviewed-by: vinnie ! src/share/classes/java/security/cert/CertificateRevokedException.java Changeset: 537cf89b2f74 Author: mullan Date: 2010-10-18 09:05 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/537cf89b2f74 Merge Changeset: 5193b0c2baf0 Author: chegar Date: 2010-10-18 16:51 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5193b0c2baf0 6992545: FindBugs scan - Malicious code vulnerability Warnings in com.sun.net.httpserver.HttpsParameters.* Reviewed-by: alanb ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/com/sun/net/httpserver/Filter.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/HttpsParameters.java Changeset: 426e5f2dbea3 Author: coffeys Date: 2010-10-18 18:04 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/426e5f2dbea3 6974104: TEST: sun/nio/ch/6645197.java should be fixed in 1.5.0u25b05 and jdk6 workspace Reviewed-by: alanb + test/java/nio/channels/Selector/TemporarySelector.java Changeset: faccd8fcd36c Author: lana Date: 2010-10-18 21:50 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/faccd8fcd36c Merge Changeset: 4e04d1e8f533 Author: lana Date: 2010-10-21 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4e04d1e8f533 Merge Changeset: 5c761cdf28e8 Author: lana Date: 2010-10-21 17:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5c761cdf28e8 6993984: PIT: b116 - Many of the swing test are failing on Solaris Reviewed-by: anthony, prr ! src/share/classes/java/awt/event/InputEvent.java Changeset: f9dee02df0eb Author: lana Date: 2010-10-26 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f9dee02df0eb Merge Changeset: e45cac3fe09b Author: herrick Date: 2010-10-08 11:43 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e45cac3fe09b Merge Changeset: 7713900ff391 Author: igor Date: 2010-10-14 16:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7713900ff391 Merge - make/common/Rules-SCCS.gmk ! make/common/shared/Defs.gmk - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 7363e68ccce4 Author: herrick Date: 2010-10-16 12:17 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7363e68ccce4 Merge Changeset: 1657ed4e1d86 Author: jqzuo Date: 2010-10-26 19:48 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1657ed4e1d86 Merge Changeset: 3e6726bbf80a Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3e6726bbf80a Added tag jdk7-b116 for changeset 1657ed4e1d86 ! .hgtags Changeset: 4b09cad8528d Author: lana Date: 2010-11-02 22:15 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4b09cad8528d Merge ! src/windows/classes/sun/awt/windows/WWindowPeer.java From lana.steuck at oracle.com Wed Nov 3 08:51:42 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Nov 2010 15:51:42 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/langtools: 15 new changesets Message-ID: <20101103155213.EAFFE476A3@hg.openjdk.java.net> Changeset: b7f12ec175bb Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/b7f12ec175bb Added tag jdk7-b115 for changeset 01e8ac5fbefd ! .hgtags Changeset: 971c8132f5b2 Author: jjg Date: 2010-10-05 11:34 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/971c8132f5b2 6988836: A new JavacElements is created for each round of annotation processing Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/environment/round/TestContext.java Changeset: 33603a5fa84d Author: jjg Date: 2010-10-05 17:37 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/33603a5fa84d 6893932: javah help screen lists -h and -? but does not accept them Reviewed-by: darcy ! src/share/classes/com/sun/tools/javah/JavahTask.java + test/tools/javah/TestHelpOpts.java Changeset: c8b4a1e76089 Author: jjg Date: 2010-10-07 15:26 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/c8b4a1e76089 6990379: two examples fail under CheckExamples on Windows Reviewed-by: darcy ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/FileManager.java Changeset: 5b5d965900b8 Author: jjg Date: 2010-10-11 10:19 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/5b5d965900b8 6990390: javah -help produces help screen with extraneous output Reviewed-by: darcy ! src/share/classes/com/sun/tools/javah/resources/l10n.properties ! test/tools/javah/TestHelpOpts.java Changeset: 68cf07910d74 Author: jjg Date: 2010-10-12 12:55 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/68cf07910d74 6989457: javadoc test file test/tools/javadoc/T4994049/FileWithTabs.java probably does not Reviewed-by: mcimadamore ! test/tools/javadoc/T4994049/FileWithTabs.java ! test/tools/javadoc/T4994049/T4994049.java Changeset: 14a707f8ce84 Author: jjg Date: 2010-10-12 13:15 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/14a707f8ce84 6988407: javac crashes running processor on errant code; it used to print error message Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! test/tools/javac/api/6406133/Erroneous.java + test/tools/javac/processing/errors/TestParseErrors/ParseErrors.java + test/tools/javac/processing/errors/TestParseErrors/TestParseErrors.java + test/tools/javac/processing/errors/TestParseErrors/TestParseErrors.out Changeset: a1d31ab7b525 Author: jjg Date: 2010-10-12 13:19 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/a1d31ab7b525 4942232: missing param class processes without error Reviewed-by: darcy ! src/share/classes/com/sun/tools/javah/JNI.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Mangle.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/com/sun/tools/javah/resources/l10n.properties + test/tools/javah/4942232/ParamClassTest.java + test/tools/javah/4942232/Test.java Changeset: ea92d1e275b6 Author: jjg Date: 2010-10-12 14:22 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/ea92d1e275b6 6990133: AnnotationProxyMaker.ValueVisitor$1 contains non-transient non-serializable field Reviewed-by: darcy ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java Changeset: ee366cc698c0 Author: jjg Date: 2010-10-12 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/ee366cc698c0 6908476: test/tools/javac/T6705935.java fails if non-zip files found on platform class path Reviewed-by: darcy ! test/tools/javac/T6705935.java Changeset: 9bfb0e6fd526 Author: lana Date: 2010-10-13 17:52 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/9bfb0e6fd526 Merge Changeset: 493ecc8111ba Author: mcimadamore Date: 2010-10-18 19:14 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/493ecc8111ba 6991980: polymorphic signature calls don't share the same CP entries Summary: wrong use of attr env in Infer.java prevents sharing of CP entries for PS calls Reviewed-by: darcy, jrose ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/meth/TestCP.java Changeset: 2187e78b7980 Author: lana Date: 2010-10-18 21:50 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/2187e78b7980 Merge Changeset: 857bfcea3f30 Author: lana Date: 2010-10-26 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/857bfcea3f30 Merge Changeset: 2129a046f117 Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/2129a046f117 Added tag jdk7-b116 for changeset 857bfcea3f30 ! .hgtags From linuxhippy at gmail.com Thu Nov 4 09:20:25 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 4 Nov 2010 17:20:25 +0100 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <949127986.2128921288739428968.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1602526756.2128731288738989849.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <949127986.2128921288739428968.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: Hi Denis, > It's not obvious to me why this happened, so I think now I will put > this type of optimization aside and convert to JNI, I've only followed your discussion with Jim but skipped all the in-depth discussion. >From my prior experiences usually JNI is not woth the trouble, if you don't have a serious reason why using native code would have advantages (like the possibility of using SIMD or when value-types would be a huge benefit), it has its own performance pitfalls especially if the workload is small and things like Get*ArrayCritical cause scalability problems because they have to lock the GC. > where profiling > will be easier (for me - I haven't been able to make OProfile work > for java yet). Have you had a look at the Netbeans profiler? It supports sampling based testing to keep the influence of the profiler at a minimum. Thanks for working on this! - Clemens From james.graham at oracle.com Thu Nov 4 14:56:33 2010 From: james.graham at oracle.com (Jim Graham) Date: Thu, 04 Nov 2010 14:56:33 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: References: <1602526756.2128731288738989849.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <949127986.2128921288739428968.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CD32C11.3080502@oracle.com> Hi Denis, Also, I've gotten another 20% improvement out of the design with a few more tweaks. (Though I measured the 20% in the stripped down version that I'm prototyping with FX so I'm not sure how much of that 20% would show up through the layers of the 2D code. Overall, I've about doubled the frame rates of the prototype since your first drop that you checked in to the OpenJDK repository.) How about looking more at the stroking end of the process and I'll dig a little more into optimal rasterization code. I have a lot of experience with optimizing rasterizer code (and JNI if it comes to that), but very little with the curve manipulations involved in stroking (math is so *hard* at my age ;-)... ...jim On 11/4/2010 9:20 AM, Clemens Eisserer wrote: > Hi Denis, > >> It's not obvious to me why this happened, so I think now I will put >> this type of optimization aside and convert to JNI, > > I've only followed your discussion with Jim but skipped all the > in-depth discussion. >> From my prior experiences usually JNI is not woth the trouble, if you > don't have a serious reason why using native code would have > advantages (like the possibility of using SIMD or when value-types > would be a huge benefit), it has its own performance pitfalls > especially if the workload is small and things like Get*ArrayCritical > cause scalability problems because they have to lock the GC. > >> where profiling >> will be easier (for me - I haven't been able to make OProfile work >> for java yet). > > Have you had a look at the Netbeans profiler? It supports sampling > based testing to keep the influence of the profiler at a minimum. > > Thanks for working on this! > > - Clemens From dlila at redhat.com Mon Nov 8 06:34:14 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 8 Nov 2010 09:34:14 -0500 (EST) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <560388424.2549061289226567450.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <904191807.2549891289226854762.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Clemens. > I've only followed your discussion with Jim but skipped all the > in-depth discussion. > From my prior experiences usually JNI is not woth the trouble, if > you don't have a serious reason why using native code would have > advantages (like the possibility of using SIMD or when value-types > would be a huge benefit), it has its own performance pitfalls > especially if the workload is small and things like Get*ArrayCritical > cause scalability problems because they have to lock the GC. Well, Jim Graham said that a native version of the engine still runs a lot faster than the version with all my changes. That's why I thought it would be a good idea. Also, when not doing antialiasing we usually feed paths to native consumers, so I thought if pisces used JNI, we could reduce the java->C transitions five fold. But then I realized that with antialiasing the opposite would happen, so I'm not sure whether JNI is a good idea. > Have you had a look at the Netbeans profiler? It supports sampling > based testing to keep the influence of the profiler at a minimum. No, I don't use netbeans - it doesn't render underscores properly (although I think this is an openjdk bug). I'll try it out. > Thanks for working on this! It's been fun. Regards, Denis. ----- "Clemens Eisserer" wrote: > Hi Denis, > > > It's not obvious to me why this happened, so I think now I will put > > this type of optimization aside and convert to JNI, > > > > where profiling > > will be easier (for me - I haven't been able to make OProfile work > > for java yet). > > - Clemens From dlila at redhat.com Mon Nov 8 06:40:59 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 8 Nov 2010 09:40:59 -0500 (EST) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1001555633.2550311289226969583.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1008472919.2551111289227259506.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > Also, I've gotten another 20% improvement out of the design with a few > more tweaks. (Though I measured the 20% in the stripped down version > that I'm prototyping with FX so I'm not sure how much of that 20% > would show up through the layers of the 2D code. Overall, I've about > doubled the frame rates of the prototype since your first drop that you > checked in to the OpenJDK repository.) Can I see your new version? > How about looking more at the stroking end of the process and I'll dig > a little more into optimal rasterization code. I have a lot of > experience with optimizing rasterizer code (and JNI if it comes to that), but > very little with the curve manipulations involved in stroking (math is so > *hard* at my age ;-)... Sounds good. Have you implemented your idea of processing one pixel row at a time, as opposed to processing subpixel rows? If not, I could do that. Thanks, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > ...jim > > On 11/4/2010 9:20 AM, Clemens Eisserer wrote: > > Hi Denis, > > > >> It's not obvious to me why this happened, so I think now I will > put > >> this type of optimization aside and convert to JNI, > > > > I've only followed your discussion with Jim but skipped all the > > in-depth discussion. > >> From my prior experiences usually JNI is not woth the trouble, if > you > > don't have a serious reason why using native code would have > > advantages (like the possibility of using SIMD or when value-types > > would be a huge benefit), it has its own performance pitfalls > > especially if the workload is small and things like > Get*ArrayCritical > > cause scalability problems because they have to lock the GC. > > > >> where profiling > >> will be easier (for me - I haven't been able to make OProfile work > >> for java yet). > > > > Have you had a look at the Netbeans profiler? It supports sampling > > based testing to keep the influence of the profiler at a minimum. > > > > Thanks for working on this! > > > > - Clemens From neugens at limasoftware.net Mon Nov 8 08:08:22 2010 From: neugens at limasoftware.net (Mario Torre) Date: Mon, 08 Nov 2010 17:08:22 +0100 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <904191807.2549891289226854762.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <904191807.2549891289226854762.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1289232502.2244.4.camel@galactica> Il giorno lun, 08/11/2010 alle 09.34 -0500, Denis Lila ha scritto: > > Have you had a look at the Netbeans profiler? It supports sampling > > based testing to keep the influence of the profiler at a minimum. > > No, I don't use netbeans - it doesn't render underscores properly (although > I think this is an openjdk bug). I'll try it out. This has been fixed in OpenJDK 7, and should have been back ported to 6, not sure when the fix will be out. > > Thanks for working on this! yup :) Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From james.graham at oracle.com Mon Nov 8 10:49:02 2010 From: james.graham at oracle.com (Jim Graham) Date: Mon, 08 Nov 2010 10:49:02 -0800 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <904191807.2549891289226854762.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <904191807.2549891289226854762.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CD8461E.3060606@oracle.com> On 11/8/2010 6:34 AM, Denis Lila wrote: > Hi Clemens. > >> I've only followed your discussion with Jim but skipped all the >> in-depth discussion. >> From my prior experiences usually JNI is not woth the trouble, if >> you don't have a serious reason why using native code would have >> advantages (like the possibility of using SIMD or when value-types >> would be a huge benefit), it has its own performance pitfalls >> especially if the workload is small and things like Get*ArrayCritical >> cause scalability problems because they have to lock the GC. > > Well, Jim Graham said that a native version of the engine still runs > a lot faster than the version with all my changes. That's why I thought Actually, that report is old. I've now got the new Java version turning in double the frame rates of the old native version. > it would be a good idea. Also, when not doing antialiasing we usually > feed paths to native consumers, so I thought if pisces used JNI, we > could reduce the java->C transitions five fold. But then I realized that > with antialiasing the opposite would happen, so I'm not sure whether > JNI is a good idea. That's a good point that the other rasterizers will end up using this stroking engine and they are native. We can worry about cleaning that up later. JNI might eventually be a good idea, but lets fix the algorithm first and then worry about whether it will help this renderer or if we can make the interface to the other renderers simpler. ...jim From james.graham at oracle.com Mon Nov 8 10:57:10 2010 From: james.graham at oracle.com (Jim Graham) Date: Mon, 08 Nov 2010 10:57:10 -0800 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1008472919.2551111289227259506.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1008472919.2551111289227259506.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CD84806.6030402@oracle.com> It's still a work in progress, but I've cleaned up a lot of logic and made it faster in a number of ways. Note that I've abstracted out the cache stuff and created an "AlphaConsumer" interface which may evolve over time. In FX we actually consume alphas in larger chunks than the code in JDK which was driven by Ductus's 32x32 mandate, so I would have had to make completely incompatible changes to emitRow - so I moved it behind an interface. For the JDK code, if you want to integrate this version, I would have the cache implement the new interface and move your version of emitRow into the Cache object. I'd send you the new code for my AlphaConsumer, but it is incompatible with what you need to cache so it won't help you. You'll also need a bit of un-translation cleanup as we have mirrors of all of java.awt.geom with special new APIs that FX needs. ...jim On 11/8/2010 6:40 AM, Denis Lila wrote: > Hi Jim. > >> Also, I've gotten another 20% improvement out of the design with a few >> more tweaks. (Though I measured the 20% in the stripped down version >> that I'm prototyping with FX so I'm not sure how much of that 20% >> would show up through the layers of the 2D code. Overall, I've about >> doubled the frame rates of the prototype since your first drop that you >> checked in to the OpenJDK repository.) > > Can I see your new version? Attached. >> How about looking more at the stroking end of the process and I'll dig >> a little more into optimal rasterization code. I have a lot of >> experience with optimizing rasterizer code (and JNI if it comes to that), but >> very little with the curve manipulations involved in stroking (math is so >> *hard* at my age ;-)... > > Sounds good. Have you implemented your idea of processing one pixel row at a > time, as opposed to processing subpixel rows? If not, I could do that. Not yet. Right now I've gotten a lot of mileage out of a few tweaks of the bookkeeping of the sample-row-at-a-time version. I'm still mulling over exactly how to make that go faster. ...jim -------------- next part -------------- A non-text attachment was scrubbed... Name: AlphaConsumer.java Type: text/x-java Size: 386 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20101108/2ac62290/AlphaConsumer.java -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPiscesRenderer.java Type: text/x-java Size: 22742 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20101108/2ac62290/OpenPiscesRenderer.java From james.graham at oracle.com Mon Nov 8 11:06:38 2010 From: james.graham at oracle.com (Jim Graham) Date: Mon, 08 Nov 2010 11:06:38 -0800 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1008472919.2551111289227259506.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1008472919.2551111289227259506.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CD84A3E.9090800@oracle.com> A couple of questions about the code that I haven't touched... Is there some reason why the AFD for cubics doesn't have any tests for dddxy (the "constants" for its equations), but the AFD for quads is testing the ddxy on every loop? I know that these values do change when the AFD variables are doubled or halved, but why does the cubic version get away with only testing out to the n-1th order differences but the quad version has to test out to the nth order differences? Also, what is the value of breaking the pieces into monotonic segments prior to flattening? Is it simply amortizing the cost of determining if the segment is up or down? I guess this used to be done because we needed monotonic (in Y) curve segments since we did a top-down iteration across all segments, but now they aren't in the rasterization loop. If it is simply a performance issue then I may experiment with eliminating that stage and seeing if I can make it go faster overall. Finally, I discovered (while testing for other problems) that the curves are not truly monotonic after slicing them. I realized this years ago when I was writing my Area code (see sun.awt.geom.Curve) and put in tweaking code to make them monotonic after they were split. They are never off by more than a few bits, but you can't trust the curve splitting math to generate purely monotonic segments based on a t generated by some unrelated math. Sometimes the truly horizontal or vertical t value requires more precision than a float (or even a double) can provide and splitting at the highest representable float less than the t value produces a pair of curves on one side of the hill and splitting at the next float value (which is greater than the true t value) produces curves on the other side of the hill. Also, when the curve has been split a few times already, the t values loose accuracy with each split. This will all be moot if I can eliminate the splitting code from the renderer, but it may also play a factor in the stroke/dash code... ...jim From james.graham at oracle.com Mon Nov 8 11:22:18 2010 From: james.graham at oracle.com (Jim Graham) Date: Mon, 08 Nov 2010 11:22:18 -0800 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1008472919.2551111289227259506.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1008472919.2551111289227259506.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CD84DEA.5000406@oracle.com> Also, some things to note in the new version - things I had to "fix" not related to performance. In endRendering the pixel bounds of the edges needed to be computed and passed along to the next stage. Unfortunately the code in endRendering computed the sub-pixel bounds and then simply shifted them to get the pixel addresses of those bounds. For the bottom and right edges, this means that a ceiling operation was performed on the sub-pixel data, but a floor operation was performed on the conversion to pixel addresses. This means that the bottom few sub-pixel rows could have been sliced off in these calculations. I restructured the calculations there to make sure that it produced the pixel bounds of all of the subpixel rows. Also, I use a ceil() operation on the sub-pixel values because we really want to know what is the next sub-pixel sample row/column that we will cross and then get the (pixel) bounds of those sample row/columns. I think there may have been a couple of other places where the "which pixel are we on" code got sloppy along similar lines to the endRendering case. The conditions for sending the alphas for the last row changed a little. I need to have every row visited in my AlphaConsumer because it is cleaning out an alpha tile as it incorporates the new alphas. Thus, I needed the logic to call "getAndClear" even if there were no alphas to deliver. I don't think that change would have affected your version with the PiscesCache since you can just finalize the cache when the alphas are done and clearing the alphaRow[] array is irrelevant at that final stage. The way this works may change as I continue optimizing. ...jim On 11/8/2010 6:40 AM, Denis Lila wrote: > Hi Jim. > >> Also, I've gotten another 20% improvement out of the design with a few >> more tweaks. (Though I measured the 20% in the stripped down version >> that I'm prototyping with FX so I'm not sure how much of that 20% >> would show up through the layers of the 2D code. Overall, I've about >> doubled the frame rates of the prototype since your first drop that you >> checked in to the OpenJDK repository.) > > Can I see your new version? From dlila at redhat.com Mon Nov 8 14:39:03 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 8 Nov 2010 17:39:03 -0500 (EST) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1248262676.2628681289255577371.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <823836430.2629321289255943836.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > A couple of questions about the code that I haven't touched... > Is there some reason why the AFD for cubics doesn't have any tests for > dddxy (the "constants" for its equations), but the AFD for quads is > testing the ddxy on every loop? I know that these values do change > when the AFD variables are doubled or halved, but why does the cubic > version get away with only testing out to the n-1th order differences but the > quad version has to test out to the nth order differences? That's because I used to have only one AFD function that worked for both cubics and quadratics. It simply treated quadratics as cubics with the first coefficient 0. I decided to split them up because we might want to do different things for quadratics, but I didn't get around to doing any of them (yet) so that's why it is the way it is. > Also, what is the value of breaking the pieces into monotonic segments > prior to flattening? Is it simply amortizing the cost of determining > if the segment is up or down? I guess this used to be done because we > needed monotonic (in Y) curve segments since we did a top-down > iteration across all segments, but now they aren't in the rasterization loop. > If it is simply a performance issue then I may experiment with > eliminating that stage and seeing if I can make it go faster overall. Well, making them monotonic makes updating edgeM[in|ax][X|Y] more efficient. We only have to do the tests once per subdivided curve instead of once per line. Also it helps with making our lines have y2>y1. Without monotonicity we'd have to test each individual line, instead of just reversing the curve coordinate array. However, for the latter, all we need is monotonicity in Y. We should make some measurements to determine whether the above are enough to compensate for the subdivision costs. > Finally, I discovered (while testing for other problems) that the > curves are not truly monotonic after slicing them. I realized this years ago > when I was writing my Area code (see sun.awt.geom.Curve) and put in > tweaking code to make them monotonic after they were split. They are > never off by more than a few bits, but you can't trust the curve > splitting math to generate purely monotonic segments based on a t > generated by some unrelated math. Sometimes the truly horizontal or > vertical t value requires more precision than a float (or even a > double) can provide and splitting at the highest representable float less than > the t value produces a pair of curves on one side of the hill and > splitting at the next float value (which is greater than the true t > value) produces curves on the other side of the hill. Also, when the > curve has been split a few times already, the t values loose accuracy > with each split. This will all be moot if I can eliminate the > splitting code from the renderer, but it may also play a factor in the > stroke/dash > code... Making curves monotonic is only used for optimization purposes, so it can't see how it would affect rendering correctness. Regards, Denis. ----- "Jim Graham" wrote: > > ...jim From dlila at redhat.com Mon Nov 8 15:23:42 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 8 Nov 2010 18:23:42 -0500 (EST) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1678045424.2631311289258533720.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <983327256.2631441289258622330.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. I like the new Renderer, but I have a question about edgeBucketCount. As far as I can see it is only used so that we can tell whether any given bucket contains only edges that go all the way to the last (or beyond) scanline. Is this really common enough that we gain by treating it as a special case? Would it not be better to assume that every bucket needs pruning and save some memory (and possibly resulting in better cache performance)? Thanks, Denis. ----- "Jim Graham" wrote: > It's still a work in progress, but I've cleaned up a lot of logic and > > made it faster in a number of ways. Note that I've abstracted out the > > cache stuff and created an "AlphaConsumer" interface which may evolve > > over time. > > In FX we actually consume alphas in larger chunks than the code in JDK > > which was driven by Ductus's 32x32 mandate, so I would have had to > make > completely incompatible changes to emitRow - so I moved it behind an > interface. For the JDK code, if you want to integrate this version, I > > would have the cache implement the new interface and move your version > > of emitRow into the Cache object. I'd send you the new code for my > AlphaConsumer, but it is incompatible with what you need to cache so > it > won't help you. > > You'll also need a bit of un-translation cleanup as we have mirrors of > > all of java.awt.geom with special new APIs that FX needs. > > ...jim > > On 11/8/2010 6:40 AM, Denis Lila wrote: > > Hi Jim. > > > >> Also, I've gotten another 20% improvement out of the design with a > few > >> more tweaks. (Though I measured the 20% in the stripped down > version > >> that I'm prototyping with FX so I'm not sure how much of that 20% > >> would show up through the layers of the 2D code. Overall, I've > about > >> doubled the frame rates of the prototype since your first drop that > you > >> checked in to the OpenJDK repository.) > > > > Can I see your new version? > > Attached. > > >> How about looking more at the stroking end of the process and I'll > dig > >> a little more into optimal rasterization code. I have a lot of > >> experience with optimizing rasterizer code (and JNI if it comes to > that), but > >> very little with the curve manipulations involved in stroking (math > is so > >> *hard* at my age ;-)... > > > > Sounds good. Have you implemented your idea of processing one pixel > row at a > > time, as opposed to processing subpixel rows? If not, I could do > that. > > Not yet. Right now I've gotten a lot of mileage out of a few tweaks > of > the bookkeeping of the sample-row-at-a-time version. I'm still > mulling > over exactly how to make that go faster. > > ...jim From james.graham at oracle.com Mon Nov 8 15:32:49 2010 From: james.graham at oracle.com (Jim Graham) Date: Mon, 08 Nov 2010 15:32:49 -0800 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <823836430.2629321289255943836.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <823836430.2629321289255943836.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CD888A1.2080908@oracle.com> Hi Denis, On 11/8/2010 2:39 PM, Denis Lila wrote: >> Finally, I discovered (while testing for other problems) that the >> curves are not truly monotonic after slicing them. I realized this years ago >> when I was writing my Area code (see sun.awt.geom.Curve) and put in >> tweaking code to make them monotonic after they were split. They are >> never off by more than a few bits, but you can't trust the curve >> splitting math to generate purely monotonic segments based on a t >> generated by some unrelated math. Sometimes the truly horizontal or >> vertical t value requires more precision than a float (or even a >> double) can provide and splitting at the highest representable float less than >> the t value produces a pair of curves on one side of the hill and >> splitting at the next float value (which is greater than the true t >> value) produces curves on the other side of the hill. Also, when the >> curve has been split a few times already, the t values loose accuracy >> with each split. This will all be moot if I can eliminate the >> splitting code from the renderer, but it may also play a factor in the >> stroke/dash >> code... > > Making curves monotonic is only used for optimization purposes, > so it can't see how it would affect rendering correctness. All lines generated from a given "allegedly monotonic" curve are recorded with the same "or" (orientation) value. But, if the curves are not truly monotonic then it might be theoretically possible to generate a line that is backwards with respect to the expected orientation. It would then get recorded in the edges array with the wrong orientation and slope and then rasterization might unravel. Fortunately, the non-monotonicity is limited to a few bits of precision so this may never generate an errant edge in practice unless flattening gets really fine-grained... ...jim From james.graham at oracle.com Mon Nov 8 15:35:38 2010 From: james.graham at oracle.com (Jim Graham) Date: Mon, 08 Nov 2010 15:35:38 -0800 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <983327256.2631441289258622330.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <983327256.2631441289258622330.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CD8894A.1080007@oracle.com> Hi Denis, The problem is that pruning complicates the inner loop that advances the scanline and you can't tell without scanning every segment in play whether you need to do it in its own loop. Thus, for one of my test cases it was really expensive without some up front record of whether or not the pruning was needed. Also, I keep a count so I can amortize the "widenArray" call. Before I was calling "widen(..., 1)" inside the loop that drew new edges in from the bucket. I could also have added an additional loop to count the new edges, but that would have been expensive as well... ...jim On 11/8/2010 3:23 PM, Denis Lila wrote: > Hi Jim. > > I like the new Renderer, but I have a question about edgeBucketCount. > > As far as I can see it is only used so that we can tell whether > any given bucket contains only edges that go all the way to the last > (or beyond) scanline. Is this really common enough that we gain by > treating it as a special case? Would it not be better to assume that > every bucket needs pruning and save some memory (and possibly resulting > in better cache performance)? > > Thanks, > Denis. > > ----- "Jim Graham" wrote: > >> It's still a work in progress, but I've cleaned up a lot of logic and >> >> made it faster in a number of ways. Note that I've abstracted out the >> >> cache stuff and created an "AlphaConsumer" interface which may evolve >> >> over time. >> >> In FX we actually consume alphas in larger chunks than the code in JDK >> >> which was driven by Ductus's 32x32 mandate, so I would have had to >> make >> completely incompatible changes to emitRow - so I moved it behind an >> interface. For the JDK code, if you want to integrate this version, I >> >> would have the cache implement the new interface and move your version >> >> of emitRow into the Cache object. I'd send you the new code for my >> AlphaConsumer, but it is incompatible with what you need to cache so >> it >> won't help you. >> >> You'll also need a bit of un-translation cleanup as we have mirrors of >> >> all of java.awt.geom with special new APIs that FX needs. >> >> ...jim >> >> On 11/8/2010 6:40 AM, Denis Lila wrote: >>> Hi Jim. >>> >>>> Also, I've gotten another 20% improvement out of the design with a >> few >>>> more tweaks. (Though I measured the 20% in the stripped down >> version >>>> that I'm prototyping with FX so I'm not sure how much of that 20% >>>> would show up through the layers of the 2D code. Overall, I've >> about >>>> doubled the frame rates of the prototype since your first drop that >> you >>>> checked in to the OpenJDK repository.) >>> >>> Can I see your new version? >> >> Attached. >> >>>> How about looking more at the stroking end of the process and I'll >> dig >>>> a little more into optimal rasterization code. I have a lot of >>>> experience with optimizing rasterizer code (and JNI if it comes to >> that), but >>>> very little with the curve manipulations involved in stroking (math >> is so >>>> *hard* at my age ;-)... >>> >>> Sounds good. Have you implemented your idea of processing one pixel >> row at a >>> time, as opposed to processing subpixel rows? If not, I could do >> that. >> >> Not yet. Right now I've gotten a lot of mileage out of a few tweaks >> of >> the bookkeeping of the sample-row-at-a-time version. I'm still >> mulling >> over exactly how to make that go faster. >> >> ...jim From ulli at netcorner.org Tue Nov 9 02:48:48 2010 From: ulli at netcorner.org (Thorsten Jungblut) Date: Tue, 9 Nov 2010 11:48:48 +0100 (CET) Subject: [OpenJDK 2D-Dev] Review for patch at bug #100150 Message-ID: Hi, could someone please take a look at bug #100150? https://bugs.openjdk.java.net/show_bug.cgi?id=100150 Thanks Best regards Thorsten Jungblut From dlila at redhat.com Tue Nov 9 14:25:59 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 9 Nov 2010 17:25:59 -0500 (EST) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <4CD8894A.1080007@oracle.com> Message-ID: <1035811091.2791981289341559923.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > The problem is that pruning complicates the inner loop that advances > the scanline and you can't tell without scanning every segment in play > whether you need to do it in its own loop. Thus, for one of my test > cases it was really expensive without some up front record of whether > or not the pruning was needed. Ah, I see. I misunderstood this yesterday. I read the line as ...[firstCrossing - boundsMinY] |= 1 instead of ...[lastCrossing-boundsMinY] |= 1. My bad. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > Also, I keep a count so I can amortize the "widenArray" call. Before > I > was calling "widen(..., 1)" inside the loop that drew new edges in > from > the bucket. I could also have added an additional loop to count the > new > edges, but that would have been expensive as well... > > ...jim > > On 11/8/2010 3:23 PM, Denis Lila wrote: > > Hi Jim. > > > > I like the new Renderer, but I have a question about > edgeBucketCount. > > > > As far as I can see it is only used so that we can tell whether > > any given bucket contains only edges that go all the way to the > last > > (or beyond) scanline. Is this really common enough that we gain by > > treating it as a special case? Would it not be better to assume > that > > every bucket needs pruning and save some memory (and possibly > resulting > > in better cache performance)? > > > > Thanks, > > Denis. > > > > ----- "Jim Graham" wrote: > > > >> It's still a work in progress, but I've cleaned up a lot of logic > and > >> > >> made it faster in a number of ways. Note that I've abstracted out > the > >> > >> cache stuff and created an "AlphaConsumer" interface which may > evolve > >> > >> over time. > >> > >> In FX we actually consume alphas in larger chunks than the code in > JDK > >> > >> which was driven by Ductus's 32x32 mandate, so I would have had to > >> make > >> completely incompatible changes to emitRow - so I moved it behind > an > >> interface. For the JDK code, if you want to integrate this > version, I > >> > >> would have the cache implement the new interface and move your > version > >> > >> of emitRow into the Cache object. I'd send you the new code for > my > >> AlphaConsumer, but it is incompatible with what you need to cache > so > >> it > >> won't help you. > >> > >> You'll also need a bit of un-translation cleanup as we have mirrors > of > >> > >> all of java.awt.geom with special new APIs that FX needs. > >> > >> ...jim > >> > >> On 11/8/2010 6:40 AM, Denis Lila wrote: > >>> Hi Jim. > >>> > >>>> Also, I've gotten another 20% improvement out of the design with > a > >> few > >>>> more tweaks. (Though I measured the 20% in the stripped down > >> version > >>>> that I'm prototyping with FX so I'm not sure how much of that > 20% > >>>> would show up through the layers of the 2D code. Overall, I've > >> about > >>>> doubled the frame rates of the prototype since your first drop > that > >> you > >>>> checked in to the OpenJDK repository.) > >>> > >>> Can I see your new version? > >> > >> Attached. > >> > >>>> How about looking more at the stroking end of the process and > I'll > >> dig > >>>> a little more into optimal rasterization code. I have a lot of > >>>> experience with optimizing rasterizer code (and JNI if it comes > to > >> that), but > >>>> very little with the curve manipulations involved in stroking > (math > >> is so > >>>> *hard* at my age ;-)... > >>> > >>> Sounds good. Have you implemented your idea of processing one > pixel > >> row at a > >>> time, as opposed to processing subpixel rows? If not, I could do > >> that. > >> > >> Not yet. Right now I've gotten a lot of mileage out of a few > tweaks > >> of > >> the bookkeeping of the sample-row-at-a-time version. I'm still > >> mulling > >> over exactly how to make that go faster. > >> > >> ...jim From dlila at redhat.com Tue Nov 9 15:06:56 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 9 Nov 2010 18:06:56 -0500 (EST) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1786989624.2794261289343970001.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <2067510478.2794371289344016596.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > All lines generated from a given "allegedly monotonic" curve are > recorded with the same "or" (orientation) value. But, if the curves > are not truly monotonic then it might be theoretically possible to > generate a line that is backwards with respect to the expected orientation. It > would then get recorded in the edges array with the wrong orientation > and slope and then rasterization might unravel. I see. In that case, I think it's a good idea if we don't make curves "monotonic". I already did this, by moving the edgeMin/axX/Y handling and orientation computations in addLine. This did make it slower compared to the file you sent me, but only by very, very little. Curves were affected the most, and they were only 1% slower. I think we can handle this, especially since lines were about 1% faster. The code is also 70 lines shorter. The edgeM* members are used only so we don't have to iterate through every scanline if this is not necessary, and so that we can tell PiscesCache that the bounding box is smaller than what Renderer is given. However, now that we keep the bucket list, I think it would be more efficient if we got rid if EdgeM[in|ax]Y and simply computed the y bounds by looking at the head and tail of the bucket list. Also, perhaps we can keep track of edgeM[in|ax]X using the bounding boxes of curves, instead of the lines in the flattened curves. This would not be accurate, but I don't think it would affect rendering. It would simply result in a few more alpha boxes than necessary. I don't think these would be too bad, because mostly they're just going to be all 0 so they will be skipped because getTypicalAlpha() is now implemented. How do you think we should handle these 4 variables? Thank you, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > On 11/8/2010 2:39 PM, Denis Lila wrote: > >> Finally, I discovered (while testing for other problems) that the > >> curves are not truly monotonic after slicing them. I realized this > years ago > >> when I was writing my Area code (see sun.awt.geom.Curve) and put > in > >> tweaking code to make them monotonic after they were split. They > are > >> never off by more than a few bits, but you can't trust the curve > >> splitting math to generate purely monotonic segments based on a t > >> generated by some unrelated math. Sometimes the truly horizontal > or > >> vertical t value requires more precision than a float (or even a > >> double) can provide and splitting at the highest representable > float less than > >> the t value produces a pair of curves on one side of the hill and > >> splitting at the next float value (which is greater than the true > t > >> value) produces curves on the other side of the hill. Also, when > the > >> curve has been split a few times already, the t values loose > accuracy > >> with each split. This will all be moot if I can eliminate the > >> splitting code from the renderer, but it may also play a factor in > the > >> stroke/dash > >> code... > > > > Making curves monotonic is only used for optimization purposes, > > so it can't see how it would affect rendering correctness. > > Fortunately, the non-monotonicity is limited to a few bits of > precision > so this may never generate an errant edge in practice unless > flattening > gets really fine-grained... > > ...jim From dlila at redhat.com Tue Nov 9 15:26:39 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 9 Nov 2010 18:26:39 -0500 (EST) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <2067510478.2794371289344016596.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <127353870.2795351289345199853.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi again. I just thought of this: if we're really concerned about the accuracy of the edgeMinX edgeMaxX variables, we could find the curves' critical points and use them to compute the min/max X values. After all, we're creating (or rather "setting") the Curve objects anyway. This isn't as fast as using the bounding boxes, but it's close and much more accurate. Regards, Denis. ----- "Denis Lila" wrote: > Hi Jim. > > > All lines generated from a given "allegedly monotonic" curve are > > recorded with the same "or" (orientation) value. But, if the curves > > are not truly monotonic then it might be theoretically possible to > > generate a line that is backwards with respect to the expected > orientation. It > > would then get recorded in the edges array with the wrong > orientation > > and slope and then rasterization might unravel. > > I see. In that case, I think it's a good idea if we don't make curves > "monotonic". I already did this, by moving the edgeMin/axX/Y handling > and orientation computations in addLine. This did make it slower > compared > to the file you sent me, but only by very, very little. Curves were > affected the most, and they were only 1% slower. I think we can handle > this, especially since lines were about 1% faster. The code is also 70 > lines shorter. > > The edgeM* members are used only so we don't have to iterate through > every > scanline if this is not necessary, and so that we can tell PiscesCache > that the bounding box is smaller than what Renderer is given. However, > now > that we keep the bucket list, I think it would be more efficient if we > got rid if EdgeM[in|ax]Y and simply computed the y bounds by looking > at the > head and tail of the bucket list. > Also, perhaps we can keep track of edgeM[in|ax]X using the bounding > boxes > of curves, instead of the lines in the flattened curves. This would > not > be accurate, but I don't think it would affect rendering. It would > simply > result in a few more alpha boxes than necessary. I don't think these > would > be too bad, because mostly they're just going to be all 0 so they will > be skipped because getTypicalAlpha() is now implemented. > How do you think we should handle these 4 variables? > > Thank you, > Denis. > > ----- "Jim Graham" wrote: > > > Hi Denis, > > > > On 11/8/2010 2:39 PM, Denis Lila wrote: > > >> Finally, I discovered (while testing for other problems) that the > > >> curves are not truly monotonic after slicing them. I realized > this > > years ago > > >> when I was writing my Area code (see sun.awt.geom.Curve) and put > > in > > >> tweaking code to make them monotonic after they were split. They > > are > > >> never off by more than a few bits, but you can't trust the curve > > >> splitting math to generate purely monotonic segments based on a t > > >> generated by some unrelated math. Sometimes the truly horizontal > > or > > >> vertical t value requires more precision than a float (or even a > > >> double) can provide and splitting at the highest representable > > float less than > > >> the t value produces a pair of curves on one side of the hill and > > >> splitting at the next float value (which is greater than the true > > t > > >> value) produces curves on the other side of the hill. Also, when > > the > > >> curve has been split a few times already, the t values loose > > accuracy > > >> with each split. This will all be moot if I can eliminate the > > >> splitting code from the renderer, but it may also play a factor > in > > the > > >> stroke/dash > > >> code... > > > > > > Making curves monotonic is only used for optimization purposes, > > > so it can't see how it would affect rendering correctness. > > > > Fortunately, the non-monotonicity is limited to a few bits of > > precision > > so this may never generate an errant edge in practice unless > > flattening > > gets really fine-grained... > > > > ...jim From james.graham at oracle.com Tue Nov 9 15:43:55 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 09 Nov 2010 15:43:55 -0800 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <2067510478.2794371289344016596.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <2067510478.2794371289344016596.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CD9DCBB.30603@oracle.com> Hi Denis, On 11/9/2010 3:06 PM, Denis Lila wrote: > I see. In that case, I think it's a good idea if we don't make curves > "monotonic". I already did this, by moving the edgeMin/axX/Y handling > and orientation computations in addLine. This did make it slower compared > to the file you sent me, but only by very, very little. Curves were > affected the most, and they were only 1% slower. I think we can handle > this, especially since lines were about 1% faster. The code is also 70 > lines shorter. Did you have to modify the AFD code for this (in terms of changing their limit constants to get good results)? > The edgeM* members are used only so we don't have to iterate through every > scanline if this is not necessary, and so that we can tell PiscesCache > that the bounding box is smaller than what Renderer is given. However, now > that we keep the bucket list, I think it would be more efficient if we > got rid if EdgeM[in|ax]Y and simply computed the y bounds by looking at the > head and tail of the bucket list. That makes sense. We calculate that per-edge anyway so the edgeMy constants are redundant. > Also, perhaps we can keep track of edgeM[in|ax]X using the bounding boxes > of curves, instead of the lines in the flattened curves. This would not > be accurate, but I don't think it would affect rendering. It would simply > result in a few more alpha boxes than necessary. I don't think these would > be too bad, because mostly they're just going to be all 0 so they will > be skipped because getTypicalAlpha() is now implemented. > How do you think we should handle these 4 variables? I think this is probably OK, but let me play with it a bit and see what I come up with. For one thing, the extra "slop" may not be large enough to trigger a full tile of 0's - there would have to be 32-pixel borders for that to happen. If we get rid of the redundant edgeMy calculations then we might be able to do edgeMx calculations on each edge without losing any performance... ...jim From james.graham at oracle.com Tue Nov 9 18:30:42 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 09 Nov 2010 18:30:42 -0800 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <127353870.2795351289345199853.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <127353870.2795351289345199853.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CDA03D2.1070104@oracle.com> I ended up going with: - get rid of edgeMxy in all methods but addLine() - addLine computes min/max of first/lastScanline - addLine also computes min/max of x1,x2 values this turned out to be just about the same speed for my FX rendering version (which I believe is more sensitive than the way it is integrated into JDK, so it should be even less noticeable in JDK). It also paved the way for a couple of other optimizations that ended up netting about 1FPS for my current test case that I use so I'm happy for now. The code is a lot simpler now... ...jim On 11/9/2010 3:26 PM, Denis Lila wrote: > Hi again. > > I just thought of this: if we're really concerned about the accuracy > of the edgeMinX edgeMaxX variables, we could find the curves' > critical points and use them to compute the min/max X values. After all, > we're creating (or rather "setting") the Curve objects anyway. This isn't > as fast as using the bounding boxes, but it's close and much more accurate. > > Regards, > Denis. > > ----- "Denis Lila" wrote: > >> Hi Jim. >> >>> All lines generated from a given "allegedly monotonic" curve are >>> recorded with the same "or" (orientation) value. But, if the curves >>> are not truly monotonic then it might be theoretically possible to >>> generate a line that is backwards with respect to the expected >> orientation. It >>> would then get recorded in the edges array with the wrong >> orientation >>> and slope and then rasterization might unravel. >> >> I see. In that case, I think it's a good idea if we don't make curves >> "monotonic". I already did this, by moving the edgeMin/axX/Y handling >> and orientation computations in addLine. This did make it slower >> compared >> to the file you sent me, but only by very, very little. Curves were >> affected the most, and they were only 1% slower. I think we can handle >> this, especially since lines were about 1% faster. The code is also 70 >> lines shorter. >> >> The edgeM* members are used only so we don't have to iterate through >> every >> scanline if this is not necessary, and so that we can tell PiscesCache >> that the bounding box is smaller than what Renderer is given. However, >> now >> that we keep the bucket list, I think it would be more efficient if we >> got rid if EdgeM[in|ax]Y and simply computed the y bounds by looking >> at the >> head and tail of the bucket list. >> Also, perhaps we can keep track of edgeM[in|ax]X using the bounding >> boxes >> of curves, instead of the lines in the flattened curves. This would >> not >> be accurate, but I don't think it would affect rendering. It would >> simply >> result in a few more alpha boxes than necessary. I don't think these >> would >> be too bad, because mostly they're just going to be all 0 so they will >> be skipped because getTypicalAlpha() is now implemented. >> How do you think we should handle these 4 variables? >> >> Thank you, >> Denis. >> >> ----- "Jim Graham" wrote: >> >>> Hi Denis, >>> >>> On 11/8/2010 2:39 PM, Denis Lila wrote: >>>>> Finally, I discovered (while testing for other problems) that the >>>>> curves are not truly monotonic after slicing them. I realized >> this >>> years ago >>>>> when I was writing my Area code (see sun.awt.geom.Curve) and put >>> in >>>>> tweaking code to make them monotonic after they were split. They >>> are >>>>> never off by more than a few bits, but you can't trust the curve >>>>> splitting math to generate purely monotonic segments based on a t >>>>> generated by some unrelated math. Sometimes the truly horizontal >>> or >>>>> vertical t value requires more precision than a float (or even a >>>>> double) can provide and splitting at the highest representable >>> float less than >>>>> the t value produces a pair of curves on one side of the hill and >>>>> splitting at the next float value (which is greater than the true >>> t >>>>> value) produces curves on the other side of the hill. Also, when >>> the >>>>> curve has been split a few times already, the t values loose >>> accuracy >>>>> with each split. This will all be moot if I can eliminate the >>>>> splitting code from the renderer, but it may also play a factor >> in >>> the >>>>> stroke/dash >>>>> code... >>>> >>>> Making curves monotonic is only used for optimization purposes, >>>> so it can't see how it would affect rendering correctness. >>> >>> Fortunately, the non-monotonicity is limited to a few bits of >>> precision >>> so this may never generate an errant edge in practice unless >>> flattening >>> gets really fine-grained... >>> >>> ...jim From dlila at redhat.com Wed Nov 10 13:55:17 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 10 Nov 2010 16:55:17 -0500 (EST) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <4CD9DCBB.30603@oracle.com> Message-ID: <512286682.2887221289426117876.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > Did you have to modify the AFD code for this (in terms of changing > their limit constants to get good results)? No, I didn't. By handling non monotonic curves, the AFD algorithm is going through more iterations, but the only way in which this could be a problem is through accumulation of numerical inaccuracies, and I don't think we do enough iterations for this to start causing perceptible problems. I haven't noticed anything in all my testing. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > On 11/9/2010 3:06 PM, Denis Lila wrote: > > I see. In that case, I think it's a good idea if we don't make > curves > > "monotonic". I already did this, by moving the edgeMin/axX/Y > handling > > and orientation computations in addLine. This did make it slower > compared > > to the file you sent me, but only by very, very little. Curves were > > affected the most, and they were only 1% slower. I think we can > handle > > this, especially since lines were about 1% faster. The code is also > 70 > > lines shorter. > > > The edgeM* members are used only so we don't have to iterate through > every > > scanline if this is not necessary, and so that we can tell > PiscesCache > > that the bounding box is smaller than what Renderer is given. > However, now > > that we keep the bucket list, I think it would be more efficient if > we > > got rid if EdgeM[in|ax]Y and simply computed the y bounds by looking > at the > > head and tail of the bucket list. > > That makes sense. We calculate that per-edge anyway so the edgeMy > constants are redundant. > > > Also, perhaps we can keep track of edgeM[in|ax]X using the bounding > boxes > > of curves, instead of the lines in the flattened curves. This would > not > > be accurate, but I don't think it would affect rendering. It would > simply > > result in a few more alpha boxes than necessary. I don't think these > would > > be too bad, because mostly they're just going to be all 0 so they > will > > be skipped because getTypicalAlpha() is now implemented. > > How do you think we should handle these 4 variables? > > I think this is probably OK, but let me play with it a bit and see > what > I come up with. For one thing, the extra "slop" may not be large > enough > to trigger a full tile of 0's - there would have to be 32-pixel > borders > for that to happen. > > If we get rid of the redundant edgeMy calculations then we might be > able > to do edgeMx calculations on each edge without losing any > performance... > > ...jim From dlila at redhat.com Wed Nov 10 14:01:27 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 10 Nov 2010 17:01:27 -0500 (EST) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1704637635.2887631289426241643.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1468356815.2888091289426487225.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > - get rid of edgeMxy in all methods but addLine() > - addLine computes min/max of first/lastScanline > - addLine also computes min/max of x1,x2 values > > this turned out to be just about the same speed for my FX rendering > version (which I believe is more sensitive than the way it is > integrated > into JDK, so it should be even less noticeable in JDK). It also paved > the way for a couple of other optimizations that ended up netting > about 1FPS for my current test case that I use so I'm happy for now. > The code is a lot simpler now... I also implemented what you describe and those are exactly my results too. I implemented my ideas for optimizing edgeM[in|ax]Y too, but it turned out not to make any difference whatsoever. I should note that my benchmarks say the performance on horizontal lines has decreased by 32% compared to the version where we qsorted everything. The benchmark report says the overall performance has stayed the same because every test other than horizontal lines is performing better by about 2-6%. Regards, Denis. ----- "Jim Graham" wrote: > I ended up going with: > > ...jim > > On 11/9/2010 3:26 PM, Denis Lila wrote: > > Hi again. > > > > I just thought of this: if we're really concerned about the > accuracy > > of the edgeMinX edgeMaxX variables, we could find the curves' > > critical points and use them to compute the min/max X values. After > all, > > we're creating (or rather "setting") the Curve objects anyway. This > isn't > > as fast as using the bounding boxes, but it's close and much more > accurate. > > > > Regards, > > Denis. > > > > ----- "Denis Lila" wrote: > > > >> Hi Jim. > >> > >>> All lines generated from a given "allegedly monotonic" curve are > >>> recorded with the same "or" (orientation) value. But, if the > curves > >>> are not truly monotonic then it might be theoretically possible > to > >>> generate a line that is backwards with respect to the expected > >> orientation. It > >>> would then get recorded in the edges array with the wrong > >> orientation > >>> and slope and then rasterization might unravel. > >> > >> I see. In that case, I think it's a good idea if we don't make > curves > >> "monotonic". I already did this, by moving the edgeMin/axX/Y > handling > >> and orientation computations in addLine. This did make it slower > >> compared > >> to the file you sent me, but only by very, very little. Curves > were > >> affected the most, and they were only 1% slower. I think we can > handle > >> this, especially since lines were about 1% faster. The code is also > 70 > >> lines shorter. > >> > >> The edgeM* members are used only so we don't have to iterate > through > >> every > >> scanline if this is not necessary, and so that we can tell > PiscesCache > >> that the bounding box is smaller than what Renderer is given. > However, > >> now > >> that we keep the bucket list, I think it would be more efficient if > we > >> got rid if EdgeM[in|ax]Y and simply computed the y bounds by > looking > >> at the > >> head and tail of the bucket list. > >> Also, perhaps we can keep track of edgeM[in|ax]X using the > bounding > >> boxes > >> of curves, instead of the lines in the flattened curves. This > would > >> not > >> be accurate, but I don't think it would affect rendering. It would > >> simply > >> result in a few more alpha boxes than necessary. I don't think > these > >> would > >> be too bad, because mostly they're just going to be all 0 so they > will > >> be skipped because getTypicalAlpha() is now implemented. > >> How do you think we should handle these 4 variables? > >> > >> Thank you, > >> Denis. > >> > >> ----- "Jim Graham" wrote: > >> > >>> Hi Denis, > >>> > >>> On 11/8/2010 2:39 PM, Denis Lila wrote: > >>>>> Finally, I discovered (while testing for other problems) that > the > >>>>> curves are not truly monotonic after slicing them. I realized > >> this > >>> years ago > >>>>> when I was writing my Area code (see sun.awt.geom.Curve) and > put > >>> in > >>>>> tweaking code to make them monotonic after they were split. > They > >>> are > >>>>> never off by more than a few bits, but you can't trust the > curve > >>>>> splitting math to generate purely monotonic segments based on a > t > >>>>> generated by some unrelated math. Sometimes the truly > horizontal > >>> or > >>>>> vertical t value requires more precision than a float (or even > a > >>>>> double) can provide and splitting at the highest representable > >>> float less than > >>>>> the t value produces a pair of curves on one side of the hill > and > >>>>> splitting at the next float value (which is greater than the > true > >>> t > >>>>> value) produces curves on the other side of the hill. Also, > when > >>> the > >>>>> curve has been split a few times already, the t values loose > >>> accuracy > >>>>> with each split. This will all be moot if I can eliminate the > >>>>> splitting code from the renderer, but it may also play a factor > >> in > >>> the > >>>>> stroke/dash > >>>>> code... > >>>> > >>>> Making curves monotonic is only used for optimization purposes, > >>>> so it can't see how it would affect rendering correctness. > >>> > >>> Fortunately, the non-monotonicity is limited to a few bits of > >>> precision > >>> so this may never generate an errant edge in practice unless > >>> flattening > >>> gets really fine-grained... > >>> > >>> ...jim From james.graham at oracle.com Wed Nov 10 15:27:55 2010 From: james.graham at oracle.com (Jim Graham) Date: Wed, 10 Nov 2010 15:27:55 -0800 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1468356815.2888091289426487225.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1468356815.2888091289426487225.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CDB2A7B.9050402@oracle.com> FYI - we have a bug to integrate some optimizations from JDK6 for wide lines and transformed rectangles. In 6 I did some work a year ago or so to detect simply wide lines and transformed rectangles and to issue a "fillParallelogram" internal method. OGL and D3D can then implement these directly and I wrote new software loops for doing pgrams as well. We are right now going through our list or 6 bugs and integrating them into 7 so this code should get integrated in the next month or so. At that point I think that horizontal lines may be moot... ...jim On 11/10/2010 2:01 PM, Denis Lila wrote: > Hi Jim. > >> - get rid of edgeMxy in all methods but addLine() >> - addLine computes min/max of first/lastScanline >> - addLine also computes min/max of x1,x2 values >> >> this turned out to be just about the same speed for my FX rendering >> version (which I believe is more sensitive than the way it is >> integrated >> into JDK, so it should be even less noticeable in JDK). It also paved >> the way for a couple of other optimizations that ended up netting >> about 1FPS for my current test case that I use so I'm happy for now. >> The code is a lot simpler now... > > I also implemented what you describe and those are exactly my results too. > I implemented my ideas for optimizing edgeM[in|ax]Y too, but it turned out > not to make any difference whatsoever. > > I should note that my benchmarks say the performance on horizontal lines has > decreased by 32% compared to the version where we qsorted everything. The > benchmark report says the overall performance has stayed the same because > every test other than horizontal lines is performing better by about 2-6%. > > Regards, > Denis. > > ----- "Jim Graham" wrote: > >> I ended up going with: >> >> ...jim >> >> On 11/9/2010 3:26 PM, Denis Lila wrote: >>> Hi again. >>> >>> I just thought of this: if we're really concerned about the >> accuracy >>> of the edgeMinX edgeMaxX variables, we could find the curves' >>> critical points and use them to compute the min/max X values. After >> all, >>> we're creating (or rather "setting") the Curve objects anyway. This >> isn't >>> as fast as using the bounding boxes, but it's close and much more >> accurate. >>> >>> Regards, >>> Denis. >>> >>> ----- "Denis Lila" wrote: >>> >>>> Hi Jim. >>>> >>>>> All lines generated from a given "allegedly monotonic" curve are >>>>> recorded with the same "or" (orientation) value. But, if the >> curves >>>>> are not truly monotonic then it might be theoretically possible >> to >>>>> generate a line that is backwards with respect to the expected >>>> orientation. It >>>>> would then get recorded in the edges array with the wrong >>>> orientation >>>>> and slope and then rasterization might unravel. >>>> >>>> I see. In that case, I think it's a good idea if we don't make >> curves >>>> "monotonic". I already did this, by moving the edgeMin/axX/Y >> handling >>>> and orientation computations in addLine. This did make it slower >>>> compared >>>> to the file you sent me, but only by very, very little. Curves >> were >>>> affected the most, and they were only 1% slower. I think we can >> handle >>>> this, especially since lines were about 1% faster. The code is also >> 70 >>>> lines shorter. >>>> >>>> The edgeM* members are used only so we don't have to iterate >> through >>>> every >>>> scanline if this is not necessary, and so that we can tell >> PiscesCache >>>> that the bounding box is smaller than what Renderer is given. >> However, >>>> now >>>> that we keep the bucket list, I think it would be more efficient if >> we >>>> got rid if EdgeM[in|ax]Y and simply computed the y bounds by >> looking >>>> at the >>>> head and tail of the bucket list. >>>> Also, perhaps we can keep track of edgeM[in|ax]X using the >> bounding >>>> boxes >>>> of curves, instead of the lines in the flattened curves. This >> would >>>> not >>>> be accurate, but I don't think it would affect rendering. It would >>>> simply >>>> result in a few more alpha boxes than necessary. I don't think >> these >>>> would >>>> be too bad, because mostly they're just going to be all 0 so they >> will >>>> be skipped because getTypicalAlpha() is now implemented. >>>> How do you think we should handle these 4 variables? >>>> >>>> Thank you, >>>> Denis. >>>> >>>> ----- "Jim Graham" wrote: >>>> >>>>> Hi Denis, >>>>> >>>>> On 11/8/2010 2:39 PM, Denis Lila wrote: >>>>>>> Finally, I discovered (while testing for other problems) that >> the >>>>>>> curves are not truly monotonic after slicing them. I realized >>>> this >>>>> years ago >>>>>>> when I was writing my Area code (see sun.awt.geom.Curve) and >> put >>>>> in >>>>>>> tweaking code to make them monotonic after they were split. >> They >>>>> are >>>>>>> never off by more than a few bits, but you can't trust the >> curve >>>>>>> splitting math to generate purely monotonic segments based on a >> t >>>>>>> generated by some unrelated math. Sometimes the truly >> horizontal >>>>> or >>>>>>> vertical t value requires more precision than a float (or even >> a >>>>>>> double) can provide and splitting at the highest representable >>>>> float less than >>>>>>> the t value produces a pair of curves on one side of the hill >> and >>>>>>> splitting at the next float value (which is greater than the >> true >>>>> t >>>>>>> value) produces curves on the other side of the hill. Also, >> when >>>>> the >>>>>>> curve has been split a few times already, the t values loose >>>>> accuracy >>>>>>> with each split. This will all be moot if I can eliminate the >>>>>>> splitting code from the renderer, but it may also play a factor >>>> in >>>>> the >>>>>>> stroke/dash >>>>>>> code... >>>>>> >>>>>> Making curves monotonic is only used for optimization purposes, >>>>>> so it can't see how it would affect rendering correctness. >>>>> >>>>> Fortunately, the non-monotonicity is limited to a few bits of >>>>> precision >>>>> so this may never generate an errant edge in practice unless >>>>> flattening >>>>> gets really fine-grained... >>>>> >>>>> ...jim From lana.steuck at oracle.com Thu Nov 11 22:37:33 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Nov 2010 06:37:33 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/corba: 8 new changesets Message-ID: <20101112063738.C3E394791D@hg.openjdk.java.net> Changeset: 16adbe677ef8 Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/16adbe677ef8 Added tag jdk7-b117 for changeset fa502e4834da ! .hgtags Changeset: b2fff4b7e8cd Author: skoppar Date: 2010-09-24 22:42 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/b2fff4b7e8cd 6891766: Vulnerabilities in use of reflection in CORBA Reviewed-by: hawtin - src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/ValueHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/PrefixParserAction.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ObjectUtility.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelAcceptorImpl.java ! src/share/classes/com/sun/corba/se/spi/orb/OperationFactory.java ! src/share/classes/com/sun/corba/se/spi/orb/ParserImplBase.java Changeset: f3090f80102d Author: asaha Date: 2010-10-26 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/f3090f80102d Merge Changeset: 046be5aaff1c Author: asaha Date: 2010-10-31 22:10 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/046be5aaff1c 6996356: Changes for 6891766 break build Summary: JPRT build passed Reviewed-by: alanb ! make/com/sun/corba/minclude/com_sun_corba_se_impl_io.jmk Changeset: 76aeef3afc04 Author: alanb Date: 2010-11-02 18:27 +0000 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/76aeef3afc04 6996740: Yet more breakage caused by 6891766 Summary: Restore com.sun.corba.se.simpl.io.IIOPInputStream that 6891766 nuked in error Reviewed-by: asaha ! make/com/sun/corba/minclude/com_sun_corba_se_impl_io.jmk + src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: e5819cb9b15e Author: lana Date: 2010-11-02 18:39 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/e5819cb9b15e Merge ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: 42e77836fded Author: lana Date: 2010-11-09 22:48 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/42e77836fded Merge Changeset: 39829414ae31 Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/39829414ae31 Added tag jdk7-b118 for changeset 42e77836fded ! .hgtags From lana.steuck at oracle.com Thu Nov 11 22:38:06 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Nov 2010 06:38:06 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d: 2 new changesets Message-ID: <20101112063806.946954791E@hg.openjdk.java.net> Changeset: a12a9e78df8a Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/a12a9e78df8a Added tag jdk7-b117 for changeset 7220e60b097f ! .hgtags Changeset: 95f8f3994b9b Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/rev/95f8f3994b9b Added tag jdk7-b118 for changeset a12a9e78df8a ! .hgtags From lana.steuck at oracle.com Thu Nov 11 22:38:34 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Nov 2010 06:38:34 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: 36 new changesets Message-ID: <20101112063938.55A8D4791F@hg.openjdk.java.net> Changeset: 62aa74bafa73 Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/62aa74bafa73 Added tag jdk7-b117 for changeset 806d0c037e6b ! .hgtags Changeset: 08f0f4a3ddd6 Author: trims Date: 2010-11-04 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/08f0f4a3ddd6 Added tag hs20-b02 for changeset 52f19c724d96 ! .hgtags Changeset: c32059ef4dc0 Author: johnc Date: 2010-10-12 09:36 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c32059ef4dc0 6971296: G1: simplify G1RemSet class hierarchy Summary: Remove G1RemSet base class and StupidG1RemSet class; rename HRInto_G1RemSet to just G1RemSet. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: b14ec34b1e07 Author: jcoomes Date: 2010-10-12 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b14ec34b1e07 6989448: G1: refactor and simplify G1ParScanThreadState Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: ee813f7b46e4 Author: jcoomes Date: 2010-10-14 11:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ee813f7b46e4 Merge Changeset: dfb38ea7da17 Author: zgu Date: 2010-09-30 12:05 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/dfb38ea7da17 6988363: Rebrand vm vendor property settings (jdk7 only) Summary: Vendor properties should be initialized after JDK version is determined. Reviewed-by: kamg, ohair, dcubed, dholmes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp Changeset: 1c352af0135d Author: acorn Date: 2010-10-04 13:11 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/1c352af0135d 6763959: java.util.concurrent.locks.LockSupport.parkUntil(0) blocks forever Summary: Absolute time 0 needs to return immediately. Reviewed-by: phh, dcubed, dholmes ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 644f98c78e33 Author: acorn Date: 2010-10-04 10:08 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/644f98c78e33 Merge Changeset: b6aedd1acdc0 Author: coleenp Date: 2010-10-07 08:06 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b6aedd1acdc0 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong Summary: min_stack_allowed is a compile time constant and Stack*Pages are settable Reviewed-by: dholmes, kvn ! src/cpu/x86/vm/methodHandles_x86.cpp ! 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/arguments.cpp ! src/share/vm/utilities/exceptions.cpp Changeset: 3dc12ef8735e Author: bobv Date: 2010-10-07 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3dc12ef8735e 6989297: Integrate additional portability improvements Reviewed-by: vladidan, dholmes ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/os/linux/vm/attachListener_linux.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 7491c8b96111 Author: bobv Date: 2010-10-07 15:14 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7491c8b96111 Merge Changeset: c77b5c592eab Author: kamg Date: 2010-10-12 10:57 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c77b5c592eab 6392697: Additional flag needed to supress Hotspot warning messages Summary: Apply PrintJvmWarnings flag to all warnings Reviewed-by: coleenp, phh ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 75b0735b4d04 Author: acorn Date: 2010-10-13 11:46 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/75b0735b4d04 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: beba40b26a79 Author: acorn Date: 2010-10-15 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/beba40b26a79 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: 07a218de38cb Author: never Date: 2010-10-15 14:21 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/07a218de38cb 6992477: fix for 6991512 broke sparc barriers Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 75ab0162aa84 Author: never Date: 2010-10-18 09:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/75ab0162aa84 Merge Changeset: 4e22405d98d6 Author: iveresov Date: 2010-10-19 11:14 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/4e22405d98d6 6989669: Coops: -Xshare:dump causes crash Summary: Temporarily fix to disable compressed oops with CDS Reviewed-by: dholmes, twisti, kvn, never ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9eaf8ba53f3d Author: trims Date: 2010-10-20 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/9eaf8ba53f3d Merge Changeset: a4c7fe54bf3f Author: kamg Date: 2010-10-21 10:10 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a4c7fe54bf3f 6991315: RedefineClasses fails with java.lang.VerifyError Summary: Repair stackmap table attribute when relocating bytecode Reviewed-by: acorn, never + src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/includeDB_core ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/relocator.hpp Changeset: fa83ab460c54 Author: acorn Date: 2010-10-22 15:59 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/fa83ab460c54 6988353: refactor contended sync subsystem Summary: reduce complexity by factoring synchronizer.cpp Reviewed-by: dholmes, never, coleenp - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/includeDB_jvmti ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp + src/share/vm/prims/jvmtiRawMonitor.cpp + src/share/vm/prims/jvmtiRawMonitor.hpp + src/share/vm/runtime/basicLock.cpp + src/share/vm/runtime/basicLock.hpp ! src/share/vm/runtime/mutex.hpp + src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/objectMonitor.inline.hpp + src/share/vm/runtime/park.cpp + src/share/vm/runtime/park.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: a312a67b32ef Author: acorn Date: 2010-10-25 13:31 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a312a67b32ef Merge ! src/share/vm/includeDB_core Changeset: 60ce9dade348 Author: acorn Date: 2010-10-26 14:43 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/60ce9dade348 Merge Changeset: 6412b3805cd6 Author: kamg Date: 2010-10-26 14:08 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/6412b3805cd6 6891959: HotSpot should not throw ClassFormatError if a class has a field with '>' and/or '<' in its name Summary: Class file parser needs to look for and disallow '[' in names. Reviewed-by: coleenp, never ! src/share/vm/classfile/classFileParser.cpp Changeset: ee0d26abaad3 Author: kamg Date: 2010-10-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ee0d26abaad3 Merge Changeset: 35e4e086d5f5 Author: tonyp Date: 2010-10-14 10:38 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/35e4e086d5f5 6990359: G1: don't push a stolen entry on the taskqueue, deal with it directly Summary: When an entry is stolen, don't push it on the task queue but process it directly. Reviewed-by: iveresov, ysr, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 9f4848ebbabd Author: tonyp Date: 2010-10-15 17:26 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/9f4848ebbabd 6992189: G1: inconsistent base used in sparse rem set iterator Summary: The remembered set iterator for sparse tables incorrectly assumes that index 0 corresponds to the bottom of the heap, not address 0 as it is the case. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: a5c514e74487 Author: johnc Date: 2010-10-18 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a5c514e74487 6988458: G1: assert(mr.end() <= _cm->finger()) failed: otherwise the region shouldn't be on the stack Summary: The changes from 6941395 did not clear the CMTask::_aborted_region fields when concurrent marking aborted because of overflow. As a result, the next time around we could see a memory region whose start address was above the global finger and the assertion tripped. Moved the clearing of the aborted regions to ConcurrentMark::clear_marking_state, which is executed on all of the exit paths. Reviewed-by: tonyp, ysr, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 72a161e62cc4 Author: tonyp Date: 2010-10-16 17:12 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/72a161e62cc4 6991377: G1: race between concurrent refinement and humongous object allocation Summary: There is a race between the concurrent refinement threads and the humongous object allocation that can cause the concurrent refinement threads to corrupt the part of the BOT that it is being initialized by the humongous object allocation operation. The solution is to do the humongous object allocation in careful steps to ensure that the concurrent refinement threads always have a consistent view over the BOT, region contents, and top. The fix includes some very minor tidying up in sparsePRT. Reviewed-by: jcoomes, johnc, ysr ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: cd3ef3fd20dd Author: ysr Date: 2010-10-21 17:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/cd3ef3fd20dd 6992998: CMSWaitDuration=0 causes hangs with +ExplicitGCInvokesConcurrent Summary: Closed a timing hole during which concurrent full gc requests can be missed. The hole can increase the latency of the response to a full gc request by up to the value of CMSWaitDuration. If CMSWaitDuration=0 is, as currently, interpreted as an unbounded wait, suitable in certain tuning scenarios, the application can potentially hang. Made two obscure tunables, including CMSWaitDuration, manageable. Reviewed-by: jcoomes, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp Changeset: a7214d79fcf1 Author: ysr Date: 2010-10-23 23:03 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a7214d79fcf1 6896603: CMS/GCH: collection_attempt_is_safe() ergo should use more recent data Summary: Deprecated HandlePromotionFailure, removing the ability to turn off that feature, did away with one epoch look-ahead when deciding if a scavenge is likely to fail, relying on current data. Reviewed-by: jmasa, johnc, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.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/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: c766bae6c14d Author: ysr Date: 2010-10-28 14:46 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c766bae6c14d 6995045: assert(!gch->incremental_collection_failed()) failed: Error, defNewGeneration.cpp:827 Summary: Sharpened an assert, introduced in 6896603, that intended to check that the incremental_collection_failed() predicate on the heap was being reset "soon enough". Reviewed-by: jmasa ! src/share/vm/memory/defNewGeneration.cpp Changeset: f5c8d6e5bfee Author: jcoomes Date: 2010-11-01 10:49 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f5c8d6e5bfee Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9de67bf4244d Author: iveresov Date: 2010-11-02 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/9de67bf4244d 6996136: VM crash in src/share/vm/runtime/virtualspace.cpp:424 Summary: Turn CDS off if compressed oops is on Reviewed-by: ysr, kvn, jcoomes, phh ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 4ac698856c43 Author: trims Date: 2010-11-04 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/4ac698856c43 Merge - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp Changeset: 698b7b727e12 Author: trims Date: 2010-11-10 20:38 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/698b7b727e12 Merge ! .hgtags - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp Changeset: 3ef7426b4dea Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3ef7426b4dea Added tag jdk7-b118 for changeset 698b7b727e12 ! .hgtags From lana.steuck at oracle.com Thu Nov 11 22:40:05 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Nov 2010 06:40:05 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: 2 new changesets Message-ID: <20101112064005.DC59247920@hg.openjdk.java.net> Changeset: b2f6d9c4f12f Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/b2f6d9c4f12f Added tag jdk7-b117 for changeset 9ee4d96e8934 ! .hgtags Changeset: 9ee900f01c58 Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/9ee900f01c58 Added tag jdk7-b118 for changeset b2f6d9c4f12f ! .hgtags From lana.steuck at oracle.com Thu Nov 11 22:40:11 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Nov 2010 06:40:11 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: 2 new changesets Message-ID: <20101112064011.8509647921@hg.openjdk.java.net> Changeset: 19a2fab3f91a Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/19a2fab3f91a Added tag jdk7-b117 for changeset 1320fb3bb588 ! .hgtags Changeset: 41fa02b36637 Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/41fa02b36637 Added tag jdk7-b118 for changeset 19a2fab3f91a ! .hgtags From lana.steuck at oracle.com Thu Nov 11 22:44:08 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Nov 2010 06:44:08 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 64 new changesets Message-ID: <20101112065444.032B847923@hg.openjdk.java.net> Changeset: d87c1c06bbf9 Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d87c1c06bbf9 Added tag jdk7-b117 for changeset 3e6726bbf80a ! .hgtags Changeset: 1bebd1f9445b Author: katakai Date: 2010-11-07 19:48 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1bebd1f9445b 4225362: localized DateFormatSymbols for fr_FR is wrong Reviewed-by: yhuang, peytoia ! src/share/classes/sun/text/resources/FormatData_fr.java ! src/share/classes/sun/text/resources/FormatData_fr_BE.java ! src/share/classes/sun/text/resources/FormatData_fr_CA.java ! src/share/classes/sun/text/resources/FormatData_fr_CH.java ! test/sun/text/resources/LocaleData Changeset: 0660c48dd705 Author: yhuang Date: 2010-11-07 23:33 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0660c48dd705 Merge Changeset: 565be51eb60e Author: cl Date: 2010-11-09 11:45 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/565be51eb60e Merge Changeset: c63c38b956c7 Author: lana Date: 2010-11-02 12:24 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c63c38b956c7 Merge - src/share/classes/sun/java2d/pisces/LineSink.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: 90e394405356 Author: dav Date: 2010-10-22 12:46 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/90e394405356 6659228: GridBagConstraints API typo - 'ComponentOrienation' (missing t) 6210739: Need spec clarification of Scrollbar set/getVisibleAmount() Reviewed-by: anthony ! src/share/classes/java/awt/GridBagConstraints.java ! src/share/classes/java/awt/Scrollbar.java Changeset: 18ad61517761 Author: lana Date: 2010-10-28 15:46 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/18ad61517761 Merge Changeset: 2b466aaec7af Author: lana Date: 2010-11-02 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2b466aaec7af Merge Changeset: 4a29a9ff158c Author: okutsu Date: 2010-10-20 14:41 +0900 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4a29a9ff158c 6991380: (cal) Calendar.cachedLocaleData should be transitioned from Hashtable to ConcurrentHashMap 6560965: [Fmt-Da] defaultCenturyStart In SimpleDateFormat should be protected 6560980: [Fmt-Da] DateFormatSymbols.cacheLookup doesn't update cache correctly. Reviewed-by: naoto, peytoia ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/TimeZone.java Changeset: 1f45c4c1f3a7 Author: amenkov Date: 2010-10-20 15:08 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1f45c4c1f3a7 6867515: Reduce impact of D3D initializion on startup time 6891435: Improve D3D preloading 6946559: AWTToolKit thread crashes in JNU_GetEnv 6987967: D3D preloading thread should initialize COM Reviewed-by: igor, art, uta ! src/windows/bin/java_md.c ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.h ! src/windows/native/sun/java2d/windows/WindowsFlags.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: db2bc901c702 Author: alexp Date: 2010-10-20 19:37 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/db2bc901c702 6989617: Enable JComponent to control repaintings of its children Reviewed-by: rupashka ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/RepaintManager.java + test/javax/swing/JComponent/6989617/bug6989617.java Changeset: 64f599571511 Author: malenkov Date: 2010-10-21 20:41 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/64f599571511 4358979: javax.swing.border should have a DashedBorder Reviewed-by: flar, alexp ! src/share/classes/java/awt/BasicStroke.java ! src/share/classes/java/awt/GradientPaint.java ! src/share/classes/java/awt/LinearGradientPaint.java ! src/share/classes/java/awt/RadialGradientPaint.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/javax/swing/BorderFactory.java + src/share/classes/javax/swing/border/StrokeBorder.java + test/java/beans/XMLEncoder/java_awt_BasicStroke.java + test/java/beans/XMLEncoder/java_awt_GradientPaint.java + test/java/beans/XMLEncoder/java_awt_LinearGradientPaint.java + test/java/beans/XMLEncoder/java_awt_RadialGradientPaint.java + test/java/beans/XMLEncoder/java_awt_geom_AffineTransform.java + test/java/beans/XMLEncoder/javax_swing_border_StrokeBorder.java Changeset: 3e1415e9a52c Author: peterz Date: 2010-10-22 16:25 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3e1415e9a52c 6993140: protected constructor in javax.swing.plaf.synth.SynthTabbedPaneUI.SynthTabbedPaneUI is needed Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java Changeset: f52ad79e2826 Author: naoto Date: 2010-10-22 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f52ad79e2826 6993339: Bug4168625Test.java fails Reviewed-by: peytoia ! test/java/util/ResourceBundle/Bug4168625Test.java Changeset: a2c3278c377c Author: rupashka Date: 2010-10-25 18:25 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a2c3278c377c 6816582: WindowsFileChooserUI throws NullPointer when awt.useSystemAAFontSettings=false Reviewed-by: uta ! src/share/classes/java/awt/Toolkit.java Changeset: e650bbeab2f2 Author: rupashka Date: 2010-10-25 19:24 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e650bbeab2f2 6632810: javax.swing.plaf.basic.BasicScrollPaneUI.getBaseline(JComponent, int, int) doesn't throw NPE and IAE Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java + test/javax/swing/plaf/basic/BasicScrollPaneUI/Test6632810.java Changeset: eb466bafbc00 Author: rupashka Date: 2010-10-26 12:35 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/eb466bafbc00 6735286: javax.swing.DefaultTableCellRender.getTableCellRendererComponent() doesn't allow passing null Tables Reviewed-by: alexp ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java + test/javax/swing/JTable/6735286/bug6735286.java Changeset: de89eec422c3 Author: rupashka Date: 2010-10-29 04:24 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/de89eec422c3 6659894: JDialog instance returns unexpected GraphicsConfiguration Reviewed-by: alexp ! src/share/classes/javax/swing/JDialog.java Changeset: 30bc265fa0d0 Author: peytoia Date: 2010-11-02 15:08 +0900 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/30bc265fa0d0 6996686: (tz) Support tzdata2010o Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/zone.tab Changeset: e86aef08aa1f Author: rupashka Date: 2010-11-02 13:32 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e86aef08aa1f 6432566: Replace usage of StringBuffer with StringBuilder in Swing Reviewed-by: malenkov ! src/share/classes/javax/swing/DebugGraphics.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/TabSet.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/MinimalHTMLWriter.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/text/rtf/AbstractFilter.java Changeset: 12dc06e49f49 Author: amenkov Date: 2010-11-02 14:59 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/12dc06e49f49 6950553: Applet: IE process crash in OLE32.DLL when playing a sound Reviewed-by: poonam ! make/javax/sound/jsoundds/Makefile ! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_DirectSound.cpp Changeset: ff9d09604606 Author: amenkov Date: 2010-11-02 15:04 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ff9d09604606 Merge Changeset: e4d839f8dfee Author: naoto Date: 2010-11-02 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e4d839f8dfee 6989111: Incorrect default locale for New Zealand 6990452: Provide system properties for the user specified script 6992312: Currency becomes XXX if do not specify user.country.format Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java ! src/share/classes/sun/util/resources/LocaleNames.properties ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/java/lang/locale_str.h ! src/windows/classes/sun/awt/windows/WInputMethod.java ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/sun/windows/awt_InputMethod.cpp ! test/java/util/Locale/data/deflocale.rhel5 ! test/java/util/Locale/data/deflocale.rhel5.fmtasdefault ! test/java/util/Locale/data/deflocale.sol10 ! test/java/util/Locale/data/deflocale.sol10.fmtasdefault ! test/java/util/Locale/data/deflocale.win7 ! test/java/util/Locale/data/deflocale.win7.fmtasdefault Changeset: ea5fd0550613 Author: lana Date: 2010-11-02 12:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ea5fd0550613 Merge ! src/share/native/java/lang/System.c ! src/solaris/native/java/lang/java_props_md.c ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 617ada000804 Author: mchung Date: 2010-10-19 09:49 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/617ada000804 6992968: test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh should not hang Reviewed-by: alanb, dholmes ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh Changeset: c6320457db65 Author: mchung Date: 2010-10-19 10:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c6320457db65 6992121: StringBuilder.ensureCapacity(int minCap) throws OutOfMemoryError with minCap=Integer.MIN_VALUE Reviewed-by: dholmes, alanb ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Vector.java + test/java/lang/StringBuilder/EnsureCapacity.java + test/java/util/ArrayList/EnsureCapacity.java Changeset: d9057727e2fa Author: alanb Date: 2010-10-21 14:39 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d9057727e2fa 6993267: TEST_BUG: java/nio/file/Path/InterruptCopy.java fails intermittently (win) Reviewed-by: forax ! test/java/nio/file/Path/InterruptCopy.java Changeset: 70bf328b7c65 Author: chegar Date: 2010-10-21 16:49 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/70bf328b7c65 6993490: SocketTimeoutException on HTTP keep-alive connections Reviewed-by: michaelm ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/www/protocol/ftp/FtpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/sun/net/www/http/HttpClient/B6726695.java ! test/sun/net/www/http/KeepAliveCache/B5045306.java ! test/sun/net/www/protocol/http/ChunkedErrorStream.java Changeset: 19cbbf152335 Author: chegar Date: 2010-10-21 16:51 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/19cbbf152335 6992859: InetAddressCachePolicy.setIfNotSet() fails Reviewed-by: michaelm ! src/share/classes/sun/net/InetAddressCachePolicy.java Changeset: 549257d35662 Author: chegar Date: 2010-10-22 09:20 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/549257d35662 6947677: InetAddress.isReachable() throws "java.net.SocketException:Invalid argument" on Linux if run as root Reviewed-by: alanb ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 3740c2da7cc5 Author: alanb Date: 2010-10-22 17:40 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3740c2da7cc5 6816049: (bf) MappedByteBuffer.force() method does not flush data correctly Reviewed-by: chegar ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/java/nio/MappedByteBuffer.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/FileDispatcher.java ! src/share/classes/sun/nio/ch/Util.java ! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java ! src/solaris/native/java/nio/MappedByteBuffer.c ! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java ! src/windows/native/java/nio/MappedByteBuffer.c ! src/windows/native/sun/nio/ch/FileDispatcherImpl.c ! test/java/nio/MappedByteBuffer/Basic.java Changeset: 0fd9c87a9b7b Author: mchung Date: 2010-10-22 11:22 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0fd9c87a9b7b 6985460: PlatformLogger throws ArrayStoreException when j.u.logging is initialized Reviewed-by: dholmes ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/util/logging/PlatformLoggerTest.java + test/sun/util/logging/SourceClassName.java Changeset: 0b07344d5526 Author: chegar Date: 2010-10-22 20:27 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0b07344d5526 6994079: PlainSocketImpl should close the socket if it fails Reviewed-by: alanb ! src/share/classes/java/net/AbstractPlainSocketImpl.java Changeset: defd25291e27 Author: ksrini Date: 2010-10-25 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/defd25291e27 6989469: (launcher) compiler warnings in jli native code Reviewed-by: darcy, ohair, sherman ! src/share/bin/java.c ! src/share/bin/parse_manifest.c ! src/share/bin/wildcard.c ! src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c ! src/solaris/bin/java_md.c ! src/solaris/bin/jexec.c ! src/windows/bin/java_md.c Changeset: 613f1b310cdb Author: kamg Date: 2010-10-26 18:41 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/613f1b310cdb 6541462: outdated specification for CCC 6339875 Summary: Add documentation to java.lang.ClassLoader.defineClass() Reviewed-by: dcubed, darcy ! src/share/classes/java/lang/ClassLoader.java Changeset: 69646b4db21d Author: skoppar Date: 2010-09-28 01:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/69646b4db21d 6559775: Race allows defaultReadObject to be invoked instead of readFields during deserialization Reviewed-by: hawtin ! make/java/java/FILES_java.gmk ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java + src/share/classes/java/io/SerialCallbackContext.java + test/java/io/Serializable/6559775/README + test/java/io/Serializable/6559775/SerialRace.java + test/java/io/Serializable/6559775/SerialVictim.java + test/java/io/Serializable/6559775/Test6559775.sh Changeset: 2070c497e241 Author: skoppar Date: 2010-09-28 01:13 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2070c497e241 6966692: defaultReadObject can set a field multiple times Reviewed-by: hawtin ! src/share/classes/java/io/ObjectStreamClass.java + test/java/io/Serializable/6966692/Attack.java + test/java/io/Serializable/6966692/README + test/java/io/Serializable/6966692/Test6966692.sh + test/java/io/Serializable/6966692/Victim.java Changeset: 7f4006dec750 Author: asaha Date: 2010-10-11 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7f4006dec750 Merge - make/common/Rules-SCCS.gmk ! make/java/java/FILES_java.gmk - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 - src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java - src/share/classes/sun/java2d/pisces/PiscesMath.java - src/share/classes/sun/java2d/pisces/Transform4.java - src/share/native/sun/java2d/cmm/lcms/cmscam97.c - src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c - src/share/native/sun/java2d/cmm/lcms/icc34.h - src/share/native/sun/java2d/cmm/lcms/lcms.h - src/solaris/classes/sun/net/spi/SdpProvider.java - src/solaris/native/sun/net/spi/SdpProvider.c - test/java/net/Socket/AccurateTimeout.java - test/java/util/Locale/data/deflocale.exe - test/java/util/Locale/data/deflocale.jds3 - test/java/util/Locale/data/deflocale.rhel4 - test/java/util/Locale/data/deflocale.winvista - test/java/util/Locale/data/deflocale.winxp - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh - test/tools/launcher/VerifyExceptions.java - test/tools/pack200/Pack200Simple.sh - test/tools/pack200/SegmentLimit.java Changeset: 96c75aec5545 Author: asaha Date: 2010-10-27 13:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/96c75aec5545 Merge ! make/java/java/FILES_java.gmk - test/java/io/Serializable/6559775/README - test/java/io/Serializable/6559775/SerialRace.java - test/java/io/Serializable/6559775/SerialVictim.java - test/java/io/Serializable/6559775/Test6559775.sh - test/java/io/Serializable/6966692/Attack.java - test/java/io/Serializable/6966692/README - test/java/io/Serializable/6966692/Test6966692.sh - test/java/io/Serializable/6966692/Victim.java Changeset: 82eb9c5fa896 Author: asaha Date: 2010-10-27 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/82eb9c5fa896 6993206: Removing non-functional tests. Reviewed-by: mchung - test/java/io/Serializable/6559775/README - test/java/io/Serializable/6559775/SerialRace.java - test/java/io/Serializable/6559775/SerialVictim.java - test/java/io/Serializable/6559775/Test6559775.sh - test/java/io/Serializable/6966692/Attack.java - test/java/io/Serializable/6966692/README - test/java/io/Serializable/6966692/Test6966692.sh - test/java/io/Serializable/6966692/Victim.java Changeset: 72e09416a65d Author: asaha Date: 2010-10-27 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/72e09416a65d Merge Changeset: 4f91da528c68 Author: asaha Date: 2010-10-27 22:10 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4f91da528c68 Merge Changeset: dfce5a0cc460 Author: weijun Date: 2010-10-28 21:14 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/dfce5a0cc460 6950546: "ktab -d name etype" to "ktab -d name [-e etype] [kvno | all | old]" 6984764: kerberos fails if service side keytab is generated using JDK ktab Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/tools/KtabCheck.java + test/sun/security/krb5/tools/ktcheck.sh + test/sun/security/krb5/tools/onlythree.conf Changeset: 7fee717f4707 Author: emcmanus Date: 2010-10-29 12:35 +0200 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7fee717f4707 6984037: jmx/management rebranding vendor changes needed Reviewed-by: ohair ! make/netbeans/jmx/build.properties ! src/share/classes/com/sun/jmx/defaults/ServiceName.java ! src/share/classes/com/sun/jmx/snmp/ServiceName.java ! src/share/classes/com/sun/management/package.html ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/build.xml ! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java Changeset: 93cd7e89adb8 Author: xuelei Date: 2010-10-30 18:39 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/93cd7e89adb8 4873188: Support TLS 1.1 Reviewed-by: wetmore, weijun ! src/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsMasterSecretParameterSpec.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/Debug.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/ProtocolVersion.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! src/share/classes/sun/security/ssl/krb5/KerberosPreMasterSecret.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java + test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java + test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java + test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java + test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java + test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java ! test/sun/security/ssl/sanity/interop/CipherTest.java Changeset: d26730767789 Author: xuelei Date: 2010-11-01 07:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d26730767789 6792180: Enhance to reject weak algorithms or conform to crypto recommendations Reviewed-by: mullan, weijun, wetmore + src/share/classes/java/security/AlgorithmConstraints.java + src/share/classes/java/security/CryptoPrimitive.java ! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java + src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! src/share/classes/sun/security/validator/Validator.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 2eade65eab5b Author: ksrini Date: 2010-11-01 10:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2eade65eab5b 6995674: (launcher) make of jli fails on windows if directory exists Reviewed-by: darcy, ohair ! make/java/jli/Makefile Changeset: e95c7f8979ee Author: mchung Date: 2010-11-01 10:59 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e95c7f8979ee 6994413: JDK_GetVersionInfo0 only expects a two digit build number Reviewed-by: dholmes ! src/share/native/common/jdk_util.c + test/sun/misc/Version/Version.java Changeset: 9d6a9f65d2bf Author: xuelei Date: 2010-11-01 22:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9d6a9f65d2bf 6916074: Add support for TLS 1.2 6985179: To support Server Name Indication extension for JSSE client Summary: Introduces the algorithm constraints to support signature and hash algorithm selection. Includes contributions from wetmore and weijung. Reviewed-by: wetmore, weijun ! src/share/classes/com/sun/crypto/provider/AESCrypt.java ! src/share/classes/com/sun/crypto/provider/ARCFOURCipher.java ! src/share/classes/com/sun/crypto/provider/DESedeCipher.java ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/com/sun/crypto/provider/DHPublicKey.java ! src/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsRsaPremasterSecretGenerator.java + src/share/classes/javax/net/ssl/ExtendedSSLSession.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLServerSocket.java ! src/share/classes/javax/net/ssl/SSLSocket.java + src/share/classes/javax/net/ssl/X509ExtendedTrustManager.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/internal/spec/TlsMasterSecretParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsPrfParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsRsaPremasterSecretParameterSpec.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/rsa/RSASignature.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/ProtocolVersion.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java + src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java + src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java ! test/com/sun/crypto/provider/TLS/TestKeyMaterial.java ! test/com/sun/crypto/provider/TLS/TestMasterSecret.java ! test/com/sun/crypto/provider/TLS/TestPRF.java + test/com/sun/crypto/provider/TLS/TestPRF12.java ! test/com/sun/crypto/provider/TLS/TestPremaster.java ! test/com/sun/crypto/provider/TLS/Utils.java + test/com/sun/crypto/provider/TLS/prf12data.txt ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java ! test/sun/security/pkcs11/tls/TestKeyMaterial.java ! test/sun/security/pkcs11/tls/TestMasterSecret.java ! test/sun/security/pkcs11/tls/TestPRF.java ! test/sun/security/pkcs11/tls/TestPremaster.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/Basics.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/TestAllSuites.java ! test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java Changeset: 5a6c63deacf3 Author: alanb Date: 2010-11-02 10:05 +0000 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5a6c63deacf3 6993126: (aio) remove AsynchronousDatagramChannel Reviewed-by: chegar ! make/java/nio/FILES_java.gmk - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java ! src/solaris/classes/sun/nio/ch/LinuxAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/SolarisAsynchronousChannelProvider.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousChannelProvider.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java ! test/java/nio/channels/spi/AsynchronousChannelProvider/Provider1.java ! test/java/nio/channels/spi/AsynchronousChannelProvider/Provider2.java Changeset: 88462abbf774 Author: alanb Date: 2010-11-02 10:07 +0000 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/88462abbf774 6431343: (dc) DatagramChannel may not report its local address correctly after connect or disconnect Reviewed-by: chegar ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java + test/java/nio/channels/DatagramChannel/ChangingAddress.java Changeset: fdcb0f667b7d Author: alanb Date: 2010-11-02 10:15 +0000 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fdcb0f667b7d Merge Changeset: e127cb5c2fbd Author: vinnie Date: 2010-11-02 15:04 +0000 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e127cb5c2fbd 6945529: Apply fix for CR 6921001 to platform-specific java.security configuration files Reviewed-by: mullan ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 45601fbddedf Author: lana Date: 2010-11-02 19:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/45601fbddedf Merge - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java ! src/windows/bin/java_md.c - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java Changeset: ddb39b2582b1 Author: naoto Date: 2010-11-05 20:58 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ddb39b2582b1 6997928: LocaleCategory test fails with b118 PIT Reviewed-by: sherman ! test/java/util/Locale/LocaleCategory.java ! test/java/util/Locale/LocaleCategory.sh Changeset: bb30977193b0 Author: lana Date: 2010-11-09 22:53 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/bb30977193b0 Merge - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java - src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java Changeset: 48f0b94573c8 Author: jrose Date: 2010-09-08 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/48f0b94573c8 6964498: JSR 292 invokedynamic sites need local bootstrap methods Summary: Add JVM_CONSTANT_InvokeDynamic records to constant pool to determine per-instruction BSMs; add MethodHandleProvider. Reviewed-by: twisti + src/share/classes/java/dyn/BootstrapMethod.java ! src/share/classes/java/dyn/CallSite.java + src/share/classes/java/dyn/ConstantCallSite.java ! src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/MethodHandle.java + src/share/classes/java/dyn/MethodHandleProvider.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! test/java/dyn/MethodHandlesTest.java Changeset: d30ca8bcad63 Author: jrose Date: 2010-09-08 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d30ca8bcad63 6980096: JSR 292 reflective lookup should throw checked exceptions Summary: Make NoAccessException be a checked exception. Also remove JavaMethodHandle. Reviewed-by: twisti ! src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/JavaMethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/dyn/NoAccessException.java ! src/share/classes/sun/dyn/BoundMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/Invokers.java + src/share/classes/sun/dyn/JavaMethodHandle.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/util/ValueConversions.java + test/java/dyn/JavaDocExamples.java ! test/java/dyn/MethodHandlesTest.java Changeset: 93f36769ecef Author: jrose Date: 2010-09-08 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/93f36769ecef 6953246: JSR 292 should support SAM conversion Summary: Conversion function MethodHandles.asInstance; initial slow implementation based on Proxy. Reviewed-by: twisti ! src/share/classes/java/dyn/MethodHandles.java ! test/java/dyn/MethodHandlesTest.java Changeset: 4ed243e9e9d9 Author: jrose Date: 2010-09-14 01:42 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4ed243e9e9d9 6982752: dynamic languages need to decorate types with runtime information Summary: Add ClassValue Reviewed-by: twisti + src/share/classes/java/dyn/ClassValue.java + test/java/dyn/ClassValueTest.java Changeset: aec1afae879d Author: trims Date: 2010-11-04 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/aec1afae879d Merge - make/common/Rules-SCCS.gmk - src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/NoAccessException.java - src/share/native/sun/java2d/cmm/lcms/cmscam97.c - src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c - src/share/native/sun/java2d/cmm/lcms/icc34.h - src/share/native/sun/java2d/cmm/lcms/lcms.h - src/solaris/classes/sun/net/spi/SdpProvider.java - src/solaris/native/sun/net/spi/SdpProvider.c - test/java/util/Locale/data/deflocale.exe - test/java/util/Locale/data/deflocale.jds3 - test/java/util/Locale/data/deflocale.rhel4 - test/java/util/Locale/data/deflocale.winvista - test/java/util/Locale/data/deflocale.winxp - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh - test/tools/launcher/VerifyExceptions.java Changeset: b357910aa04a Author: trims Date: 2010-11-10 20:40 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b357910aa04a Merge - src/share/classes/java/dyn/JavaMethodHandle.java Changeset: ecab7eefb8f2 Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ecab7eefb8f2 Added tag jdk7-b118 for changeset b357910aa04a ! .hgtags Changeset: 0fc9955d603f Author: lana Date: 2010-11-11 18:46 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0fc9955d603f Merge - src/share/classes/java/dyn/JavaMethodHandle.java - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java From lana.steuck at oracle.com Thu Nov 11 22:58:41 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Nov 2010 06:58:41 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/langtools: 15 new changesets Message-ID: <20101112065912.5C55447924@hg.openjdk.java.net> Changeset: 5bb96781fb58 Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/5bb96781fb58 Added tag jdk7-b117 for changeset 2129a046f117 ! .hgtags Changeset: 5286a99de2e6 Author: sundar Date: 2010-10-19 11:47 +0530 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/5286a99de2e6 6551367: javadoc throws ClassCastException when an @link tries to reference constructor. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java + test/tools/javadoc/T6551367.java Changeset: 4851ff2ffc10 Author: jjg Date: 2010-10-19 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/4851ff2ffc10 6987760: remove 308 support from JDK7 Reviewed-by: darcy, mcimadamore - src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java - src/share/classes/com/sun/source/util/AbstractTypeProcessor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java - test/tools/javac/T6985181.java ! test/tools/javac/annotations/6881115/T6881115.java ! test/tools/javac/annotations/6881115/T6881115.out - test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/tree/TreePosTest.java - test/tools/javac/treeannotests/AnnoTreeTests.java - test/tools/javac/typeAnnotations/6967002/T6967002.java - test/tools/javac/typeAnnotations/6967002/T6967002.out - test/tools/javac/typeAnnotations/InnerClass.java - test/tools/javac/typeAnnotations/MultipleTargets.java - test/tools/javac/typeAnnotations/TypeParameterTarget.java - test/tools/javac/typeAnnotations/TypeUseTarget.java - test/tools/javac/typeAnnotations/attribution/Scopes.java - test/tools/javac/typeAnnotations/classfile/DeadCode.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.out - test/tools/javac/typeAnnotations/failures/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/IncompleteVararg.java - test/tools/javac/typeAnnotations/failures/IncompleteVararg.out - test/tools/javac/typeAnnotations/failures/IndexArray.java - test/tools/javac/typeAnnotations/failures/IndexArray.out - test/tools/javac/typeAnnotations/failures/LintCast.java - test/tools/javac/typeAnnotations/failures/LintCast.out - test/tools/javac/typeAnnotations/failures/OldArray.java - test/tools/javac/typeAnnotations/failures/Scopes.java - test/tools/javac/typeAnnotations/failures/Scopes.out - test/tools/javac/typeAnnotations/failures/StaticFields.java - test/tools/javac/typeAnnotations/failures/StaticFields.out - test/tools/javac/typeAnnotations/failures/StaticMethods.java - test/tools/javac/typeAnnotations/failures/StaticMethods.out - test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/target/Constructor.java - test/tools/javac/typeAnnotations/failures/target/Constructor.out - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out - test/tools/javac/typeAnnotations/failures/target/VoidMethod.java - test/tools/javac/typeAnnotations/failures/target/VoidMethod.out ! test/tools/javac/typeAnnotations/newlocations/BasicTest.java + test/tools/javac/typeAnnotations/newlocations/BasicTest.out - test/tools/javac/typeAnnotations/newlocations/ClassExtends.java - test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java - test/tools/javac/typeAnnotations/newlocations/ClassParameters.java - test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/Expressions.java - test/tools/javac/typeAnnotations/newlocations/Fields.java - test/tools/javac/typeAnnotations/newlocations/LocalVariables.java - test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Parameters.java - test/tools/javac/typeAnnotations/newlocations/Receivers.java - test/tools/javac/typeAnnotations/newlocations/Throws.java - test/tools/javac/typeAnnotations/newlocations/TypeCasts.java - test/tools/javac/typeAnnotations/newlocations/TypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Wildcards.java - test/tools/javap/typeAnnotations/ArrayClassLiterals.java - test/tools/javap/typeAnnotations/ArrayClassLiterals2.java - test/tools/javap/typeAnnotations/ClassLiterals.java - test/tools/javap/typeAnnotations/JSR175Annotations.java - test/tools/javap/typeAnnotations/NewArray.java - test/tools/javap/typeAnnotations/Presence.java - test/tools/javap/typeAnnotations/PresenceInner.java - test/tools/javap/typeAnnotations/T6855990.java - test/tools/javap/typeAnnotations/Visibility.java Changeset: 01eabcd240e9 Author: jjg Date: 2010-10-22 14:04 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/01eabcd240e9 6993301: catch parameters do not have correct kind (i.e. ElementKind.EXCEPTION_PARAMETER) Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/T6993301.java Changeset: 7755f47542a0 Author: jjg Date: 2010-10-26 14:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/7755f47542a0 6949587: rename "DisjointType" to "DisjunctType" Reviewed-by: mcimadamore - src/share/classes/com/sun/source/tree/DisjointTypeTree.java + src/share/classes/com/sun/source/tree/DisjunctiveTypeTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java Changeset: 601160d857ef Author: jjg Date: 2010-10-28 10:17 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/601160d857ef 6460352: Reintroduce Scope.dble Reviewed-by: mcimadamore, jjg Contributed-by: per.bothner at oracle.com ! src/share/classes/com/sun/tools/javac/code/Scope.java Changeset: 2974d3800eb1 Author: jjg Date: 2010-10-28 18:58 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/2974d3800eb1 6994946: option to specify only syntax errors as unrecoverable Reviewed-by: darcy, mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java + test/tools/javac/processing/6994946/SemanticErrorTest.1.out + test/tools/javac/processing/6994946/SemanticErrorTest.2.out + test/tools/javac/processing/6994946/SemanticErrorTest.java + test/tools/javac/processing/6994946/SyntaxErrorTest.java + test/tools/javac/processing/6994946/SyntaxErrorTest.out + test/tools/javac/processing/6994946/TestProcessor.java Changeset: 460b2f588d0d Author: jjg Date: 2010-10-29 12:47 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/460b2f588d0d 6993304: JavacTrees.getAttrContext not updated to Tree.Kind.{ANNOTATION_TYPE,ENUM,INTERFACE} Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java Changeset: 895bea45a3e8 Author: jjg Date: 2010-10-29 13:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/895bea45a3e8 6994608: javah no longer accepts parameter files as input Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/resources/l10n.properties + test/tools/javah/T6994608.java Changeset: 6ce6ee1b831a Author: jjg Date: 2010-11-01 19:28 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/6ce6ee1b831a 6996626: Scope fix issues for ImportScope Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Scope.java Changeset: 20659c8c917d Author: mcimadamore Date: 2010-11-02 12:00 +0000 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/20659c8c917d 6996415: Override bridges causes compiler-generated code to end up with synthetic infinite loop Summary: temporarily disable fix for override bridges (6337171) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! test/tools/javac/generics/OverrideBridge.java Changeset: fadc6d3e63f4 Author: mcimadamore Date: 2010-11-02 12:01 +0000 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/fadc6d3e63f4 6939780: add a warning to detect diamond sites Summary: added hidden compiler flag '-XDfindDiamond' to detect 'diamondifiable' sites Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/DiamondRedundantArgs.java + test/tools/javac/diags/examples/DiamondRedundantArgs1.java + test/tools/javac/generics/diamond/T6939780.java + test/tools/javac/generics/diamond/T6939780.out Changeset: 534afdc92cdc Author: lana Date: 2010-11-02 19:41 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/534afdc92cdc Merge - src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java - src/share/classes/com/sun/source/tree/DisjointTypeTree.java - src/share/classes/com/sun/source/util/AbstractTypeProcessor.java - test/tools/javac/T6985181.java - test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java - test/tools/javac/treeannotests/AnnoTreeTests.java - test/tools/javac/typeAnnotations/6967002/T6967002.java - test/tools/javac/typeAnnotations/6967002/T6967002.out - test/tools/javac/typeAnnotations/InnerClass.java - test/tools/javac/typeAnnotations/MultipleTargets.java - test/tools/javac/typeAnnotations/TypeParameterTarget.java - test/tools/javac/typeAnnotations/TypeUseTarget.java - test/tools/javac/typeAnnotations/attribution/Scopes.java - test/tools/javac/typeAnnotations/classfile/DeadCode.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.out - test/tools/javac/typeAnnotations/failures/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/IncompleteVararg.java - test/tools/javac/typeAnnotations/failures/IncompleteVararg.out - test/tools/javac/typeAnnotations/failures/IndexArray.java - test/tools/javac/typeAnnotations/failures/IndexArray.out - test/tools/javac/typeAnnotations/failures/LintCast.java - test/tools/javac/typeAnnotations/failures/LintCast.out - test/tools/javac/typeAnnotations/failures/OldArray.java - test/tools/javac/typeAnnotations/failures/Scopes.java - test/tools/javac/typeAnnotations/failures/Scopes.out - test/tools/javac/typeAnnotations/failures/StaticFields.java - test/tools/javac/typeAnnotations/failures/StaticFields.out - test/tools/javac/typeAnnotations/failures/StaticMethods.java - test/tools/javac/typeAnnotations/failures/StaticMethods.out - test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/target/Constructor.java - test/tools/javac/typeAnnotations/failures/target/Constructor.out - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out - test/tools/javac/typeAnnotations/failures/target/VoidMethod.java - test/tools/javac/typeAnnotations/failures/target/VoidMethod.out - test/tools/javac/typeAnnotations/newlocations/ClassExtends.java - test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java - test/tools/javac/typeAnnotations/newlocations/ClassParameters.java - test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/Expressions.java - test/tools/javac/typeAnnotations/newlocations/Fields.java - test/tools/javac/typeAnnotations/newlocations/LocalVariables.java - test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Parameters.java - test/tools/javac/typeAnnotations/newlocations/Receivers.java - test/tools/javac/typeAnnotations/newlocations/Throws.java - test/tools/javac/typeAnnotations/newlocations/TypeCasts.java - test/tools/javac/typeAnnotations/newlocations/TypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Wildcards.java - test/tools/javap/typeAnnotations/ArrayClassLiterals.java - test/tools/javap/typeAnnotations/ArrayClassLiterals2.java - test/tools/javap/typeAnnotations/ClassLiterals.java - test/tools/javap/typeAnnotations/JSR175Annotations.java - test/tools/javap/typeAnnotations/NewArray.java - test/tools/javap/typeAnnotations/Presence.java - test/tools/javap/typeAnnotations/PresenceInner.java - test/tools/javap/typeAnnotations/T6855990.java - test/tools/javap/typeAnnotations/Visibility.java Changeset: c491eec0acc7 Author: lana Date: 2010-11-09 22:54 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/c491eec0acc7 Merge - src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java - src/share/classes/com/sun/source/tree/DisjointTypeTree.java - src/share/classes/com/sun/source/util/AbstractTypeProcessor.java - test/tools/javac/T6985181.java - test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java - test/tools/javac/treeannotests/AnnoTreeTests.java - test/tools/javac/typeAnnotations/6967002/T6967002.java - test/tools/javac/typeAnnotations/6967002/T6967002.out - test/tools/javac/typeAnnotations/InnerClass.java - test/tools/javac/typeAnnotations/MultipleTargets.java - test/tools/javac/typeAnnotations/TypeParameterTarget.java - test/tools/javac/typeAnnotations/TypeUseTarget.java - test/tools/javac/typeAnnotations/attribution/Scopes.java - test/tools/javac/typeAnnotations/classfile/DeadCode.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.out - test/tools/javac/typeAnnotations/failures/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/IncompleteVararg.java - test/tools/javac/typeAnnotations/failures/IncompleteVararg.out - test/tools/javac/typeAnnotations/failures/IndexArray.java - test/tools/javac/typeAnnotations/failures/IndexArray.out - test/tools/javac/typeAnnotations/failures/LintCast.java - test/tools/javac/typeAnnotations/failures/LintCast.out - test/tools/javac/typeAnnotations/failures/OldArray.java - test/tools/javac/typeAnnotations/failures/Scopes.java - test/tools/javac/typeAnnotations/failures/Scopes.out - test/tools/javac/typeAnnotations/failures/StaticFields.java - test/tools/javac/typeAnnotations/failures/StaticFields.out - test/tools/javac/typeAnnotations/failures/StaticMethods.java - test/tools/javac/typeAnnotations/failures/StaticMethods.out - test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/target/Constructor.java - test/tools/javac/typeAnnotations/failures/target/Constructor.out - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out - test/tools/javac/typeAnnotations/failures/target/VoidMethod.java - test/tools/javac/typeAnnotations/failures/target/VoidMethod.out - test/tools/javac/typeAnnotations/newlocations/ClassExtends.java - test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java - test/tools/javac/typeAnnotations/newlocations/ClassParameters.java - test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/Expressions.java - test/tools/javac/typeAnnotations/newlocations/Fields.java - test/tools/javac/typeAnnotations/newlocations/LocalVariables.java - test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Parameters.java - test/tools/javac/typeAnnotations/newlocations/Receivers.java - test/tools/javac/typeAnnotations/newlocations/Throws.java - test/tools/javac/typeAnnotations/newlocations/TypeCasts.java - test/tools/javac/typeAnnotations/newlocations/TypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Wildcards.java - test/tools/javap/typeAnnotations/ArrayClassLiterals.java - test/tools/javap/typeAnnotations/ArrayClassLiterals2.java - test/tools/javap/typeAnnotations/ClassLiterals.java - test/tools/javap/typeAnnotations/JSR175Annotations.java - test/tools/javap/typeAnnotations/NewArray.java - test/tools/javap/typeAnnotations/Presence.java - test/tools/javap/typeAnnotations/PresenceInner.java - test/tools/javap/typeAnnotations/T6855990.java - test/tools/javap/typeAnnotations/Visibility.java Changeset: 814561077c44 Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/814561077c44 Added tag jdk7-b118 for changeset c491eec0acc7 ! .hgtags From linuxhippy at gmail.com Sat Nov 13 09:51:45 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 13 Nov 2010 18:51:45 +0100 Subject: [OpenJDK 2D-Dev] XShmGetImage with image's > drawable's size causes BadMatch Message-ID: Hi, I've recently encountered some BadMatch errors triggered by fallbacks. Those are caused by reading outside of surface bounds using the cached ShmPixmap. Testcase and patch attached. Running with -Dsun.awt.noisyerrorhandler=True the testcase causes a BadMatch: > Xerror BadMatch (invalid parameter attributes), XID 5000017, ser# 215 > Major opcode 139 //SHM > Minor opcode 4 //GetImage If a X11SDOps structure belongs to a pixmap I can directly use pmWidth/Height, but for windows I have to query the attributes width/height. Is there a better way to get window's width/height, maybe through some of AWT's structures? - Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: shmgetfix.patch Type: text/x-patch Size: 2947 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20101113/88683bbb/shmgetfix.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: ShmGetOOBTest.java Type: application/octet-stream Size: 496 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20101113/88683bbb/ShmGetOOBTest.java From n-roeser at gmx.net Mon Nov 15 14:01:58 2010 From: n-roeser at gmx.net (Nico R.) Date: Mon, 15 Nov 2010 23:01:58 +0100 Subject: [OpenJDK 2D-Dev] jdk6 and jdk7: wrong class cast in sun.print.IPPPrintService (in Solaris classes) Message-ID: <4CE1ADD6.80000@gmx.net> Hello! In sun.print.IPPPrintService.getIPPConnection(URL), there is a bug with class casting: see , lines 1556?1565 for JDK 6, and , lines 1563?1572 for JDK 7. The buggy code is: public static HttpURLConnection getIPPConnection(URL url) { HttpURLConnection connection; try { connection = (HttpURLConnection)url.openConnection(); } catch (java.io.IOException ioe) { return null; } if (!(connection instanceof HttpURLConnection)) { return null; } If the call to openConnection returns a FileURLConnection (as it does on my system), that cannot be cast to an HttpURLConnection. The instanceof check happens too late in the code. What to do: either * catch a ClassCastException and return null from the catch block, or * use a variable of type URLConnection to store the result from openConnection(), and cast it to HttpURLConnection /after/ the block with the instanceof check. The problem occurs, because there are URLs like "file:/dev/null" in the list or URLs to try. They are retrieved from sun.print.CUPSPrinter.getAllPrinters() via sun.print.UnixPrintServiceLookup.refreshServices(). I assume this happens for printers that were auto-detected (e.g. via ZeroConf etc.) some time ago, but are not accessible at the moment), but I am not sure about that. Perhaps the CUPS system is improperly configured, but this should not cause Java applications to throw ClassCastExceptions. Regards -- Nico From jennifer.godinez at sun.com Mon Nov 15 14:27:26 2010 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Mon, 15 Nov 2010 22:27:26 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6862652: A number of tests fail for some background Themes configured on Windows7 & Windows 2008R2 in 6u15 Message-ID: <20101115222746.EC85347A0D@hg.openjdk.java.net> Changeset: 809ec4b6eb88 Author: jgodinez Date: 2010-11-15 14:16 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/809ec4b6eb88 6862652: A number of tests fail for some background Themes configured on Windows7 & Windows 2008R2 in 6u15 Reviewed-by: igor, prr ! test/sun/java2d/GdiRendering/InsetClipping.java ! test/sun/java2d/SunGraphics2D/DrawImageBilinear.java ! test/sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java ! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java From jennifer.godinez at oracle.com Tue Nov 16 09:29:49 2010 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Tue, 16 Nov 2010 09:29:49 -0800 Subject: [OpenJDK 2D-Dev] jdk6 and jdk7: wrong class cast in sun.print.IPPPrintService (in Solaris classes) In-Reply-To: <4CE1ADD6.80000@gmx.net> References: <4CE1ADD6.80000@gmx.net> Message-ID: <4CE2BF8D.8040908@oracle.com> Hi Nico, In our code we only use http in getIPPConnection so we expect HttpURLConnection . If openConection is returning FileURLConnection then this looks like a bug and needs further investigation. Please file the bug at: http://bugreport.sun.com/bugreport/ Thank you. Jennifer Nico R. wrote: > Hello! > > In sun.print.IPPPrintService.getIPPConnection(URL), there is a bug with > class casting: see > > > , > lines 1556?1565 for JDK 6, > > and > > > , > lines 1563?1572 for JDK 7. > > The buggy code is: > > public static HttpURLConnection getIPPConnection(URL url) { > HttpURLConnection connection; > try { > connection = (HttpURLConnection)url.openConnection(); > } catch (java.io.IOException ioe) { > return null; > } > if (!(connection instanceof HttpURLConnection)) { > return null; > } > > If the call to openConnection returns a FileURLConnection (as it does on > my system), that cannot be cast to an HttpURLConnection. The instanceof > check happens too late in the code. > > What to do: either > * catch a ClassCastException and return null from the catch block, or > * use a variable of type URLConnection to store the result from > openConnection(), and cast it to HttpURLConnection /after/ the block > with the instanceof check. > > The problem occurs, because there are URLs like "file:/dev/null" in the > list or URLs to try. They are retrieved from > sun.print.CUPSPrinter.getAllPrinters() via > sun.print.UnixPrintServiceLookup.refreshServices(). > > I assume this happens for printers that were auto-detected (e.g. via > ZeroConf etc.) some time ago, but are not accessible at the moment), but > I am not sure about that. > > Perhaps the CUPS system is improperly configured, but this should not > cause Java applications to throw ClassCastExceptions. > > Regards > From n-roeser at gmx.net Tue Nov 16 14:11:11 2010 From: n-roeser at gmx.net (Nico R.) Date: Tue, 16 Nov 2010 23:11:11 +0100 Subject: [OpenJDK 2D-Dev] jdk6 and jdk7: wrong class cast in sun.print.IPPPrintService (in Solaris classes) In-Reply-To: <4CE2BF8D.8040908@oracle.com> References: <4CE1ADD6.80000@gmx.net> <4CE2BF8D.8040908@oracle.com> Message-ID: <4CE3017F.9000603@gmx.net> Hello! Jennifer Godinez wrote: > In our code we only use http in getIPPConnection so we expect > HttpURLConnection . This is true for the calls to getIPPConnection from the CUPSPrinter class, but not for all calls. See below. > If openConection is returning FileURLConnection > then this looks like a bug and needs further investigation. Some investigation is below. I assume it is sufficient to reconstruct what is happening. > Please > file the bug at: > > http://bugreport.sun.com/bugreport/ Unfortunately, I am not able to do this, because the bug reporting system does not work for me. (I?ve just sent a report about this problem using the contact form .) I?d appreciate it if you could report this bug instead. Here is some further investigation: It is not true that the code in OpenJDK always uses the "http" protocol. It may also use a protocol reported by CUPS for a printer, as explained by the following reverse call trace. IPPPrintService.getIPPConnection(URL) called by: CUPSPrinter.getAllPrinters() --> OK, always uses "http" protocol. CUPSPrinter.getDefaultPrinter() --> OK, always uses "http" protocol. IPPPrintService.initAttributes() --> uses same protocol as IPPPrintService.myURL IPPPrintService.isPostscript() --> uses same protocol as IPPPrintService.myURL URL IPPPrintService.myURL initialized by: IPPPrintService(String,URL) --> myURL is set to second parameter (url) IPPPrintService(String,String,boolean) --> if second parameter (uriStr) does not contain "ipp" and does not contain "http", then myURL will be constructed from a string which does not contain "http" (and may well be a "file" URL if the input starts with "file:") IPPPrintService(String,String,boolean) called by: UnixPrintServiceLookup.getDefaultPrintService() --> OK, always uses "http" URL UnixPrintServiceLookup.refreshServices() --> uses string from local variable printerURIs[] printerURIs[] (local variable in IPPPrintService(String,String,boolean)) initialized with value from: CUPSPrinter.getAllPrinters() --> returns String[] created from values from printerNames (local variable) printerNames (local variable in CUPSPrinter.getAllPrinters()) initialized from printer-uri-supported attribute values received from CUPS CUPS may report a "file" URL for a printer if, for example, /var/cache/cups/remote.cache (the file may be stored somewhere else, depending on your system/distribution/CUPS installation) contains a reference to "file:/dev/null". This is where the "file" URL originated on my test system. OpenJDK should be able to handle this properly, and it seems that someone already thought of implementing this, but introduced a bug here: In my original mail, I wrote: [?] >> The buggy code is: >> >> public static HttpURLConnection getIPPConnection(URL url) { >> HttpURLConnection connection; >> try { >> connection = (HttpURLConnection)url.openConnection(); >> } catch (java.io.IOException ioe) { >> return null; >> } >> if (!(connection instanceof HttpURLConnection)) { >> return null; >> } As I already explained, this code does not make sense: * if the class cast works, the block with ?instanceof? does not do anything; * if the class cast does not work, a ClassCastException is thrown, and the block with ?instanceof? is not executed at all. (A non-null reference read from a local variable is always instanceof the declared type of that variable, isn?t it?) If my explanations were not verbose enough, please tell me what to clarify further. Regards -- Nico From jennifer.godinez at oracle.com Tue Nov 16 15:39:30 2010 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Tue, 16 Nov 2010 15:39:30 -0800 Subject: [OpenJDK 2D-Dev] jdk6 and jdk7: wrong class cast in sun.print.IPPPrintService (in Solaris classes) In-Reply-To: <4CE3017F.9000603@gmx.net> References: <4CE1ADD6.80000@gmx.net> <4CE2BF8D.8040908@oracle.com> <4CE3017F.9000603@gmx.net> Message-ID: <4CE31632.2070900@oracle.com> Hi Nico, Thank you for the very thorough explanation. I will file the bug but I need the following information: OS JDKversion hardware CUPS version Thank you. Jennifer Nico R. wrote: > Hello! > > Jennifer Godinez wrote: > >> In our code we only use http in getIPPConnection so we expect >> HttpURLConnection . >> > > This is true for the calls to getIPPConnection from the CUPSPrinter > class, but not for all calls. See below. > > >> If openConection is returning FileURLConnection >> then this looks like a bug and needs further investigation. >> > > Some investigation is below. I assume it is sufficient to reconstruct > what is happening. > > >> Please >> file the bug at: >> >> http://bugreport.sun.com/bugreport/ >> > > Unfortunately, I am not able to do this, because the bug reporting > system does not work for me. (I?ve just sent a report about this problem > using the contact form > .) > > I?d appreciate it if you could report this bug instead. Here is some > further investigation: > > It is not true that the code in OpenJDK always uses the "http" protocol. > It may also use a protocol reported by CUPS for a printer, as explained > by the following reverse call trace. > > > IPPPrintService.getIPPConnection(URL) > called by: > CUPSPrinter.getAllPrinters() > --> OK, always uses "http" protocol. > CUPSPrinter.getDefaultPrinter() > --> OK, always uses "http" protocol. > > IPPPrintService.initAttributes() > --> uses same protocol as IPPPrintService.myURL > IPPPrintService.isPostscript() > --> uses same protocol as IPPPrintService.myURL > > > URL IPPPrintService.myURL > initialized by: > IPPPrintService(String,URL) > --> myURL is set to second parameter (url) > > IPPPrintService(String,String,boolean) > --> if second parameter (uriStr) does not contain "ipp" and does > not contain "http", then myURL will be constructed from a > string which does not contain "http" (and may well be a "file" > URL if the input starts with "file:") > > > IPPPrintService(String,String,boolean) > called by: > UnixPrintServiceLookup.getDefaultPrintService() > --> OK, always uses "http" URL > > UnixPrintServiceLookup.refreshServices() > --> uses string from local variable printerURIs[] > > > printerURIs[] (local variable in IPPPrintService(String,String,boolean)) > initialized with value from: > CUPSPrinter.getAllPrinters() > --> returns String[] created from values from printerNames (local > variable) > > > printerNames (local variable in CUPSPrinter.getAllPrinters()) > initialized from printer-uri-supported attribute values received from > CUPS > > > CUPS may report a "file" URL for a printer if, for example, > /var/cache/cups/remote.cache (the file may be stored somewhere else, > depending on your system/distribution/CUPS installation) contains a > reference to "file:/dev/null". This is where the "file" URL originated > on my test system. > > OpenJDK should be able to handle this properly, and it seems that > someone already thought of implementing this, but introduced a bug here: > > In my original mail, I wrote: > [?] > >>> The buggy code is: >>> >>> public static HttpURLConnection getIPPConnection(URL url) { >>> HttpURLConnection connection; >>> try { >>> connection = (HttpURLConnection)url.openConnection(); >>> } catch (java.io.IOException ioe) { >>> return null; >>> } >>> if (!(connection instanceof HttpURLConnection)) { >>> return null; >>> } >>> > > As I already explained, this code does not make sense: > > * if the class cast works, the block with ?instanceof? does not do anything; > > * if the class cast does not work, a ClassCastException is thrown, and > the block with ?instanceof? is not executed at all. > > (A non-null reference read from a local variable is always instanceof > the declared type of that variable, isn?t it?) > > If my explanations were not verbose enough, please tell me what to > clarify further. > > Regards > From n-roeser at gmx.net Wed Nov 17 02:53:49 2010 From: n-roeser at gmx.net (Nico R.) Date: Wed, 17 Nov 2010 11:53:49 +0100 Subject: [OpenJDK 2D-Dev] jdk6 and jdk7: wrong class cast in sun.print.IPPPrintService (in Solaris classes) In-Reply-To: <4CE31632.2070900@oracle.com> References: <4CE1ADD6.80000@gmx.net> <4CE2BF8D.8040908@oracle.com> <4CE3017F.9000603@gmx.net> <4CE31632.2070900@oracle.com> Message-ID: <4CE3B43D.30207@gmx.net> Hi, Jennifer Godinez wrote: > Thank you for the very thorough explanation. I will file the bug but I > need the following information: > OS Looks like this does not matter at all, as long as it runs CUPS. Anyway: Linux kernel (2.6.36-tuxonice) on a Gentoo system (Gentoo Base System release 2.0.1-r1) > JDKversion Reproduced with dev-java/icedtea-6.1.9.1 (USE="doc examples hs19 javascript nio2 nsplugin nss pulseaudio xrender -cacao -debug -elibc_FreeBSD -systemtap -zero"). Looks like it applies to current JDK6 or JDK7 revisions in hg, see my earlier mail. > hardware Irrelevant, this is a software problem. If it cannot be reproduced by adding printers or changing their availability, the method using the remote.cache file for CUPS can be used to simulate it. (You can also use the printers.conf configuration file for CUPS, it is usually placed in /etc/cups/.) See my earlier mail. > CUPS version net-print/cups-1.4.4-r2 You may want to have a look at , which describes that "file" URIs are legal in CUPS. Some further notes on CUPS device URIs: DeviceURIs can be "ipp" URIs, but also, for example, start with "usb://". As far as I can tell, OpenJDK does not support "usb" URIs, so the code I mentioned earlier throws an IOException, and the ClassCastException does not happen. "file" URIs /are/ supported by OpenJDK, so the ClassCastException is thrown. The build descriptions (ebuild files) for the mentioned Gentoo packages are available from . Please let us know the bug number after you?ve filed it. By the way, no need to Cc me, I?m a subscriber of this list. Thanks -- Nico From jennifer.godinez at oracle.com Wed Nov 17 11:28:13 2010 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Wed, 17 Nov 2010 11:28:13 -0800 Subject: [OpenJDK 2D-Dev] jdk6 and jdk7: wrong class cast in sun.print.IPPPrintService (in Solaris classes) In-Reply-To: <4CE3B43D.30207@gmx.net> References: <4CE1ADD6.80000@gmx.net> <4CE2BF8D.8040908@oracle.com> <4CE3017F.9000603@gmx.net> <4CE31632.2070900@oracle.com> <4CE3B43D.30207@gmx.net> Message-ID: <4CE42CCD.90802@oracle.com> Nico, The Bug ID is 7000940. Jennifer Nico R. wrote: > Hi, > > Jennifer Godinez wrote: > >> Thank you for the very thorough explanation. I will file the bug but I >> need the following information: >> OS >> > > Looks like this does not matter at all, as long as it runs CUPS. Anyway: > Linux kernel (2.6.36-tuxonice) on a Gentoo system (Gentoo Base System > release 2.0.1-r1) > > >> JDKversion >> > > Reproduced with dev-java/icedtea-6.1.9.1 (USE="doc examples hs19 > javascript nio2 nsplugin nss pulseaudio xrender -cacao -debug > -elibc_FreeBSD -systemtap -zero"). > > Looks like it applies to current JDK6 or JDK7 revisions in hg, see my > earlier mail. > > >> hardware >> > > Irrelevant, this is a software problem. > > If it cannot be reproduced by adding printers or changing their > availability, the method using the remote.cache file for CUPS can be > used to simulate it. (You can also use the printers.conf configuration > file for CUPS, it is usually placed in /etc/cups/.) See my earlier mail. > > >> CUPS version >> > > net-print/cups-1.4.4-r2 > > You may want to have a look at > , > which describes that "file" URIs are legal in CUPS. > > > Some further notes on CUPS device URIs: > > DeviceURIs can be "ipp" URIs, but also, for example, start with > "usb://". As far as I can tell, OpenJDK does not support "usb" URIs, so > the code I mentioned earlier throws an IOException, and the > ClassCastException does not happen. "file" URIs /are/ supported by > OpenJDK, so the ClassCastException is thrown. > > > The build descriptions (ebuild files) for the mentioned Gentoo packages > are available from > . > > > Please let us know the bug number after you?ve filed it. > > By the way, no need to Cc me, I?m a subscriber of this list. > > Thanks > From dlila at redhat.com Thu Nov 18 12:41:59 2010 From: dlila at redhat.com (Denis Lila) Date: Thu, 18 Nov 2010 15:41:59 -0500 (EST) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <655425797.692951290112908753.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1833836874.692971290112919793.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. I have a new webrev: http://icedtea.classpath.org/~dlila/webrevs/perfWebrev/webrev/ > How about looking more at the stroking end of the process and I'll dig > a little more into optimal rasterization code. I have a lot of > experience with optimizing rasterizer code (and JNI if it comes to that), but > very little with the curve manipulations involved in stroking (math is so > *hard* at my age ;-)... I tried to do this. I used the netbeans compiler, and it said that a large chunk of the time (about 12% is spent in curveTo). curveTo does almost nothing: it just packs up the curve array and delegates to somethingTo. This makes me think that there's not a whole lot that can be done to improve Stroker's performance (I'm ok with this, since J2DBench and Java2DDemo animation frame rates both say that non antialiased and non dashed performance is better than even closed source java). I did make one small change though: I inlined the calls to dxat, dyat, ddxat, ddyat in ROCsq because the profiler said that a lot of time was spent there. This made a surprisingly large difference (but still not that great overall). I also fixed the dashing performance degradation. I removed the binary sort, and am now using getCubicRoots to find the t where to split. Another hugely significant change was using Math.sqrt instead of Math.hypot in the implementation of Helpers.linelen. I had been meaning to do this for a while, since sqrt is about 100 times faster on my machine than hypot, but I didn't realize it would have such a large impact on dashing. Anyway, dashing is now much, much faster than before. It is even faster than the flattening version we used to use. The precision might not be as good as the current, slow implementation, but it's only noticeable for curves with a lot of acceleration, and even then only if you do a side by side comparison of the 2 implementations. The benchmarks display a 200%-500% improvement, so I think it is well worth it. Unfortunately curve dashing is still a bit slower than the closed source counterpart, but not by much. I also tweaked the AFD algorithm for quadratic curves. It's a bit faster now. A while ago you made a suggestion on how to improve anti aliasing performance: > Here are my thoughts: > > - Currently Renderer has more stages than we probably should have: > for (each full pixel row) { > for (each subpixel row) { > for (each curve on subpixel row) { > convert curve into crossing > crossing is (subpixelx:31 + dir:1) > } > sort crossings for subpixel row > apply wind rule and convert crossings into alpha deltas > } > convert alpha deltas into run lengths > } > for (each tile) { > convert run lengths into alphas > } > I'm thinking we should be able to get rid of a couple of those stages... > > - One alternate process would be: > (all work is done in the tail end of the cache itself) > for (each full pixel row) { > for (each curve on full pixel row) { > convert curve into N subpixel crossings > (subpixelx:28 + subpixelfracty:3 + dir:1) > } > } > sort all crossings for entire pixel row > maybe collapse raw crossings into modified accumulated crossings > record start of row in index array > for (each tile) { > convert raw or collapsed crossings directly into alphas > } > Note that we could simply leave the raw crossings in the cache and then > process them in the tile generator, but that would require more storage > in the cache since a given path would tend to have 8 different entries > as it crossed every subpixel row. If we collapse them, then we can sum > the entries for a given x coordinate into a single entry and store: > (pixelx:25 + coveragedelta:7) > where the coverage delta is a signed quantity up to N_SUBPIX^2 so it > uses the same storage we needed for the subpixel parts of both X and Y > plus the direction bit. It likely needs a paired value in the next x > pixel location just like our current "alpha deltas" needs as well. If > we wanted to optimize that then we could devote one more bit to "the > next pixel will consume all of the remainder of the N^2 coverage", but > there would be cases where that would not be true (such as if the pixel > row has only partial vertical coverage by the path). It's probably > simpler to just have deltas for every pixel. > > The storage here would likely be similar to the storage used for the > current cache since the current RLE cache uses 2 full ints to store a > coverage and a count. And in cases where we have one pixel taking up > partial coverage and the following pixel taking up the remainder of the > full coverage then we have 4 ints, but the "crossing delta" system would > only have 2 ints. I tried to implement something like this. What I did was: I reduce the length of the buckets array to have only one bucket per pixel row. I removed the array that kept track of how many lines were in each bucket. In next() I iterated through the bucket for the current pixel row. For each line, I iterated through all the scanlines in the current pixel row that it crossed. For each of those, I added a crossing (I still kept these sorted using insertion sort, although this might have hurt me - simply quicksorting all the crossings just before returning from next() might have been better). The format of the crossings was like so: the SUBPIXEL_Y_POSITIONS most insignificant bits were reserved for the y coordinate within the current pixel row of the crossing. The next most insignificant bit was for the orientation. The remaining bits were for the actual crossing value. I'm not sure if this is what you had in mind, but I abandoned this because the benchmarks showed a slow down. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > Also, I've gotten another 20% improvement out of the design with a few > > more tweaks. (Though I measured the 20% in the stripped down version > > that I'm prototyping with FX so I'm not sure how much of that 20% > would > show up through the layers of the 2D code. Overall, I've about > doubled > the frame rates of the prototype since your first drop that you > checked > in to the OpenJDK repository.) > > > ...jim > > On 11/4/2010 9:20 AM, Clemens Eisserer wrote: > > Hi Denis, > > > >> It's not obvious to me why this happened, so I think now I will > put > >> this type of optimization aside and convert to JNI, > > > > I've only followed your discussion with Jim but skipped all the > > in-depth discussion. > >> From my prior experiences usually JNI is not woth the trouble, if > you > > don't have a serious reason why using native code would have > > advantages (like the possibility of using SIMD or when value-types > > would be a huge benefit), it has its own performance pitfalls > > especially if the workload is small and things like > Get*ArrayCritical > > cause scalability problems because they have to lock the GC. > > > >> where profiling > >> will be easier (for me - I haven't been able to make OProfile work > >> for java yet). > > > > Have you had a look at the Netbeans profiler? It supports sampling > > based testing to keep the influence of the profiler at a minimum. > > > > Thanks for working on this! > > > > - Clemens From dlila at redhat.com Thu Nov 18 12:53:46 2010 From: dlila at redhat.com (Denis Lila) Date: Thu, 18 Nov 2010 15:53:46 -0500 (EST) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1621720730.694021290113617315.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <343717849.694101290113626403.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> A few corrections/completions: > I tried to do this. I used the netbeans compiler netbeans *profiler*. > I tried to implement something like this. What I did was: I reduce the > length of the buckets array to have only one bucket per pixel row. I removed > the array that kept track of how many lines were in each bucket. In next() > I iterated through the bucket for the current pixel row. For each line, I > iterated through all the scanlines in the current pixel row that it crossed. For each > of those, I added a crossing (I still kept these sorted using insertion sort, > although this might have hurt me - simply quicksorting all the crossings just before > returning from next() might have been better). The format of the crossings was like so: > the SUBPIXEL_Y_POSITIONS most insignificant bits were reserved for the > y coordinate within the current pixel row of the crossing. The next most > insignificant bit was for the orientation. The remaining bits were for the actual crossing > value. I neglected to mention how these crossings were used in _end_rendering(). I just unpack them and keep a float[] sums array of length SUBPIXEL_Y_POSITIONS. This replaces the sum variable. From here. So, if a crossing is on scanline i of the current pixel row, then sum[i] is used. Everything else is the same. Regards, Denis. ----- "Denis Lila" wrote: > Hi Jim. > > I have a new webrev: > http://icedtea.classpath.org/~dlila/webrevs/perfWebrev/webrev/ > From jennifer.godinez at sun.com Thu Nov 18 14:52:50 2010 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Thu, 18 Nov 2010 22:52:50 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6689925: Add transform attributes to the rendering tests in J2DBench Message-ID: <20101118225310.B4EAE47AD2@hg.openjdk.java.net> Changeset: 23a6ba383fd7 Author: jgodinez Date: 2010-11-18 14:44 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/23a6ba383fd7 6689925: Add transform attributes to the rendering tests in J2DBench Reviewed-by: flar, prr ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Option.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Result.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/GraphicsTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java From linuxhippy at gmail.com Fri Nov 19 06:42:40 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 19 Nov 2010 15:42:40 +0100 Subject: [OpenJDK 2D-Dev] Xrender GC leak fix Message-ID: Hi, The XRender pipeline was leaking GCs which are generated on the java-side. Instead of trying to clean it up at the java-level, I now simply use Java_sun_java2d_x11_XSurfaceData_XCreateGC which sets the javaGC field in xsdo, which is already freed automatically at surface-dispose time. Thanks, Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: gcleak.patch Type: text/x-patch Size: 594 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20101119/8b6ebd85/gcleak.patch